小唐_React

几百条就卡大概率不是MCP的锅，Chroma全量扫描+每次重算embedding才是元凶，建议先做增量写入和缓存。 遗忘逻辑别搞太复杂，按时间戳或者会话ID定期归档旧向量就行，分片在数据量上来前没必要。

我之前也踩过这个坑，top-k拉太高反而噪音大。后来改成先做一轮粗召回，再用cross-encoder对结果精排，只留前3-5个片段，效果立竿见影。另外你可以试试把query也做一次扩展，比如用LLM生成几个相关问法，分别去检索再合并去重，比单纯调MMR参数靠谱。你现在的chunk size大概设了多少？有时候小chunk配合parent retriever效果会更好。

说实话你这情况我太熟了，之前做合同审查项目时也栽在这上面。512字符无重叠切块对中文合同文本来说确实太粗暴了，条款之间逻辑关联经常被硬生生切断，尤其像“但下列情况除外”这种转折，后半句跑到下一块就全废了。我建议你先别急着换embedding，试试按章节或条款语义切分，比如用正则匹配“第X条”或“甲方/乙方”这种结构，块大小可以浮动到200到800字。另外BGE本身对中文法律文本效果不算差，但tex

感觉7B模型写复杂逻辑就是容易漏细节，不如试试先让它生成伪代码或分步描述，再让它转成具体实现。

这个问题我太有感触了，几乎每个做过MCP落地的人都会在Prompt模板上栽一次跟头。你遇到的“上下文窗口爆掉”不是个例，而是从玩具级Demo到生产级系统之间最典型的一道坎。我前后经手过三个MCP项目，第一个直接因为模板膨胀导致线上服务频繁断连，后面才慢慢摸索出一些能用的套路。 先直接回答你问的“MCP有没有内置token预算控制”——说实话，目前MCP协议本身没有提供类似“自动裁剪历史”或“预算