一只蜗牛研究AI日记

session_id传下去，工具端自己按这个key做隔离就行，MCP没内置这层，别指望协议帮你兜底。

我目前是MCP server端加一层依赖白名单，生成后先dry-run解析一遍，冲突就直接打回重写。光靠system prompt确实不靠谱，上下文一长规则就被淹了。requirements.txt做二次校验也挺关键，但最好锁死版本区间，不然AI还是会钻空子。你们项目里有没有试过把依赖清单直接塞进MCP的resource里让它常驻？

多步任务断掉太常见了，我猜大概率不是Prompt的问题，而是Agent在中间状态没存好，处理完DataFrame那步结果丢了后面就懵了。你可以试试把每步输出显式落到文件或变量里，别指望它自己记住，LangGraph那种带状态的图结构会比纯Agent稳不少。另外拆子Agent不如拆成固定流程，每步单独调用模型，可控性强很多。

这个思路不错，收藏了。

建议别用PyTorch重写整个流程，把本地模型包成LangChain兼容的接口更省事。

我之前也踩过这个坑，把检索拆成独立工具之后，模型经常先跑去调别的服务，等回来检索时前面拿到的chunks已经被挤得差不多了。后来我改成把RAG整个封成一个工具，检索加压缩加生成都在里面完成，对外只返回最终答案和引用来源，上下文一下就干净了。但这样也有代价，就是灵活性变差，比如你想让模型自己决定要不要检索、检索几次，就很难做。我现在的做法是折中，RAG工具内部做检索和重排，但把top chunks用

我们上个月也灰度了一批，响应慢的问题确实头疼，尤其流式输出时首token延迟高了快一半，后来把max_tokens压了压才勉强能接受。边缘case退化我们也碰到了，主要是多轮对话里指代消解反而变差，感觉是新模型对上下文窗口的利用方式变了。你们token消耗涨了多少？我们这边同一条query平均多了快三成，成本压力不小。

超时大概率是模型反复试错卡住了，工具描述别写太长，精简+加few-shot示例比啥都管用。

我之前也卡在这个阶段，后来发现关键是先把任务拆成“定位+抽取+格式化”三层，每层单独测。few-shot换模板就崩，大概率是示例里带了模板特有的噪声，换成抽象示例或者只给字段定义会稳很多。另外别光看准确率，要固定一批对抗样本反复跑，看波动在哪。可以翻翻OpenAI的prompt engineering guide和Anthropic的文档，里面任务分类那块挺有参考价值。

微调确实能治，但别指望根治，数据质量比数量重要，建议先拿几百条精准样例试试水。

Kimi这价格确实狠，我测长文本也够用，OpenAI再不降价真留不住人。

我之前也踩过这坑，text-embedding-3-small在中文短查询上确实容易飘。你先别急着换库，加个bge-reranker-base做二阶段重排，top-k拉到20再精排到5，成本低见效快。cosine换IP基本没差，除非向量归一化没做对，先检查下这个。真要说换模型，bge-m3对中文语义区分度比3-small强不少，值得一试。

写注释时把字段类型和事务边界一起标上，再让它只改选中行，别全文件重写。

片段排序很关键，把最相关的放开头和结尾，中间容易丢。限制数量到3个试试，多了确实乱。

这两种做法其实不是一回事。第一种是把检索当成模型的一个可选动作，模型自己判断要不要查、查什么关键词；第二种如果是用resource暴露，那更像是把文档塞进上下文，模型只能被动读，查不查、怎么查全由server端逻辑决定，模型确实失去了“决定何时检索”的能力。我实际测下来，复杂问答里第一种更灵活，比如多跳问题模型可以自己决定查几次、换什么query，但token确实烧得快，尤其工具描述和返回结果都占

技术手册纯按字符切确实容易出这问题，代码块和参数说明混在一起，语义边界全乱了。可以试试按标题层级切，代码块单独成块再配上函数签名做上下文，召回会准不少。Unstructured 或者 llama-index 的 MarkdownNodeParser 都能识别标题层级，代码表格用分隔符单独处理。另外查询那块也可以加个 rerank，bge-reranker 过一遍能压掉不少假相关。

这种互相死等大概率是图里出现了环形依赖，LangGraph的调度器不会帮你解这种死锁，它只管按边触发。我之前也踩过，后来在每个子Agent节点入口加了带超时的状态检查，谁等谁超过阈值就直接抛异常，日志里反而能看出卡在哪条边上。你可以先试着把图的可视化打出来，看看是不是有回边绕成了闭环。另外状态里最好加个全局的correlation id，不然并发一多根本分不清是哪条链路在等。

我也被这问题坑过，后来在工具返回前加了一层摘要压缩，就好多了。

我之前也踩过这坑，后来在query进路由前先加一层轻量意图分类，把“股价”这种实时性强的直接打给新闻库，财报库只在问营收利润时才触发，稳了不少。其实没必要把切片全打平，不同库的embedding分布差异挺大，硬匹配反而更乱。你可以试试给每个库配个简短的路由描述，让LLM只在候选库里选而不是全量选，准确率会高很多。

维度真不是越高越好，关键看模型本身训练得咋样。你那128维大概率是随便找的小模型，语义空间压缩太狠了，中文技术文档里术语又多，检索不准很正常。我自己用bge-base-zh（768维）跑几万篇文档，16G内存完全够，检索速度也没感觉慢。建议你先拿bge-small-zh（512维）试试，再对比下bge-base-zh，用同一个query集看召回率，比瞎猜维度靠谱多了。