容器先跑起来的程序员

我也是被它乱改签名坑过，后来干脆把关键函数先写死再让它补，能老实不少。

你这问题挺典型的，我一开始也踩过。主Agent靠LLM自己判断该调谁，本质就是在赌它的意图识别准不准，prompt再怎么写也架不住输入稍微变个说法就飘。建议试试把路由逻辑单独拆出来，用规则或者一个小分类模型先定好“这任务该谁干”，主Agent只负责编排流程别让它自由发挥。另外子Agent的description写清楚边界，别让搜索Agent看起来也能总结，不然模型很容易串线。

固定256切太碎了，语义都断了，试试按标题或段落切，bge换指令版会好点。

试试把需求写进项目里的docs文件，每次让Agent先读再改，比纯对话靠谱多了。

可以试试在检索时按metadata强制过滤版本号，再配个时间戳排序，比你单纯调top-k靠谱。

我试过类似的情况，后来发现光给示例不够，得把数据格式和边界条件写死，比如列名、空值长什么样、异常值的判断标准，就差把CSV前几行贴进Prompt里了。另外别指望一次到位，先让它输出个框架，你再一步步追问“这个函数对全数字列怎么处理”，比要求它一次写全靠谱得多。还有个小技巧，明确告诉它“不要解释，直接给代码”，能过滤掉大半废话。你可以试试把需求拆成两个Prompt：先描述数据结构，再要求具体实现，效

本质区别就是MCP把检索逻辑和工具调用标准化了，省得每个agent自己写一遍，但并发一致性确实得靠server端自己扛。 说实话生产环境瓶颈多半在embedding生成和网络IO，rerank倒是次要的，得压测才能定。

我最近也在折腾这个，感触挺深的。感觉Prompt模板对输出质量的影响，有时候比换模型版本还大，尤其是角色设定那一块，加了“你是专业客服”确实能让语气稳下来，但一旦设定过于详细，比如连回答风格、长度、禁忌都写进去，模型就容易为了“表演”而编造细节，这个我踩过好几次坑。我现在基本是先用最简单的模板跑一遍baseline，比如就写“回答用户问题：xxx”，看看模型原生输出是什么水准，然后再一点点加约束，

这种问题太典型了，RAG翻车十有八九是检索召回和query意图不匹配。你试了chunk和embedding但可能漏了最关键的一点——Chroma默认的检索方式对短文本、术语密集的技术手册很不友好，稠密向量在细粒度匹配上天生弱于BM25。建议你先用Hybrid Search（稠密+稀疏）试试，或者给Chroma挂上稀疏索引插件，能立竿见影。另外检查一下你top-K取了多少段，有时候取太多反而被噪声带