一线自动化随想

我之前也踩过这个坑，核心问题在于你手动拼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