背景近期在Mac mini上部署了Acbox等开发者开发的Memoh——一款基于docker容器的多智能体Agent。在使用过程中出现了问题Agent调用工具失败并且在聊天记录中出现了类似下面格式的文本。tool_call ...{...}/tool_call排查在项目仓库已有人提交了issue #437其认为问题在于LLM-SDK缺少兜底方案需要Agent进程在LLM返回的content中扫描tool_call字符串并转换为正常工具调用。但是直觉认为这只是一种治标不治本的方法。问题关键并不在于此。经过排查发现tool_call ...{...}/tool_call这种类似XML的格式的由来是Agent将历史的工具调用记录转换为这种格式的字符串再放入上下文发送给LLM。这种格式会让LLM误以为在content中写这种格式就是触发工具调用的方法进而引发错误。于是在Codex的建议下秉持着最小修改的原则将tool_call ...{...}/tool_call格式改为了更类似自然语言的格式[Previous assistant tool use]Tool: execInput: {...}然而在接下来的测试中LLM居然开始误将这种新的格式作为工具调用的方法继续在输出的content中写入这种内容。但是这也印证了问题的根本原因就在于LLM误学习了历史工具调用格式。问题处理考虑到处理该问题会涉及到后端的turn_response管线的大改因而我没有参与更改。只在项目仓库提了一个issue。在第二天下午项目的开发者便根据此issue使用Codex予以修改了具体修改可见PR。其修改的大致思路为不再将工具调用记录和其他文本一样转为string放入content里而是以完整的调用结构化数据存放与content分离。进一步思考为什么会发生这样的错误在internal/pipeline/turn_response.go中可以看到该Agent在把工具调用拼装入上下文的时候会将其与其他对话上下文一起转换为下面的结构体type ContextMessage struct {Role string json:roleContent string json:content}在这个结构体中工具调用也和其他聊天文本一样被压扁成string。但是为了表示不同还会进一步写为这种xml格式。可能因为项目在最初没有考虑到要将工具调用引入上下文因而上下文消息只使用string来表示。但是后期引入工具调用上下文时可能出于方便没有同步修改消息结构。关于issue #437这个issue提出了一种解决方案让Agent在收到LLM发来的消息的时候扫描tool_call ...并将其作为触发工具调用的符号。并且指出知名的Agent项目hermes-agent也是这么做的。但是这种做法的缺陷在于tool_call ...本身就不应该是LLM触发工具调用的方式强行兜底处理与项目设计意图相悖。Agent可能会在不以触发工具调用为目的的时候发出tool_call ...如引用历史工具调用记录。
