一线自动化随想

工具调用这块我也有同感，之前用4.0做RAG加函数调用的链路，稍微多轮就很容易把参数拼错，尤其是嵌套JSON那种，简直灾难。4.5如果真能把状态保持做扎实，那对做Agent落地的团队来说比代码能力提升更值钱，毕竟代码生成现在大家差距在缩小，但工具链稳定性才是卡生产环境的关键。不过那个“一致性提升30%”我跟你一样持保留态度，这种指标太依赖评测集怎么设计了，如果都是偏结构化的任务，那提升可能来自后训

我也遇到过类似情况，Qwen2.5-Coder确实有种“防御性编程”的倾向，宁可mock满天飞也不愿意碰真实依赖。后来我把system prompt改成明确禁止mock数据库，并指定“用pytest.fixture + sqlite内存库”，才勉强稳住。温度0.2其实已经挺低了，再降可能影响生成多样性，感觉问题更多在提示词的约束力上。DeepSeek-Coder我没深度对比过，但它对集成测试的偏好

我之前也踩过这个坑，核心问题在于你手动拼batch时，图像和文本的tensor维度在最后一维上没对齐。建议把预处理逻辑全放进自定义Dataset的__getitem__里，用collate_fn统一处理，别在循环里临时拼。另外可以试试HuggingFace的datasets库，它自带map和batch处理，能自动处理不同模态的padding，内存爆掉多半是没做tokenize后的truncatio

我之前也卡在这块儿过，后来发现直接在Tool内部做重试是相对最省心的，因为LangChain的Agent本身对工具返回的异常处理并不智能，它只会把错误当作文本塞回给LLM，让模型自己猜下一步，这反而容易导致幻觉式的乱试。我自己是把重试逻辑封装在一个装饰器里，专门捕获超时和5xx错误，配合指数退避，效果比在Callback里做要干净得多。不过你提到的死循环问题确实存在，我建议一定要设置最大重试上限，

这问题我最近也踩过坑，MCP协议本身确实只定义了工具交互的格式，上下文隔离完全是应用层的事。官方文档里没给标准方案，所以别指望协议帮你解决。我现在是直接在MCP server里用一个ConcurrentHashMap，key是session_id，value是个自定义的Context对象，里面存了搜索历史、状态标记这些，每次工具调用先根据传入的session_id取上下文再执行逻辑。但要注意ses

这个坑我踩过好几回了，说说我现在的做法。top_k硬编码确实不靠谱，我后来改成基于token预算的动态截断——先算一下当前模型的最大上下文，再减去query和system prompt的token数，剩下的预算按比例分给历史记忆。比如我留30%给新对话，70%给记忆，然后从向量库里按相似度排序往回取，直到填满预算为止。 不过这里有个问题，Milvus返回的chunk大小不均匀，有的可能就几十to