背景
近期在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: exec
Input: {...}然而，在接下来的测试中，LLM居然开始误将这种新的格式作为工具调用的方法，继续在输出的content中写入这种内容。
但是，这也印证了问题的根本原因就在于：LLM误学习了历史工具调用格式。
问题处理
考虑到处理该问题会涉及到后端的turn_response管线的大改，因而我没有参与更改。只在项目仓库提了一个issue。在第二天下午，项目的开发者便根据此issue使用Codex予以修改了，具体修改可见PR。
其修改的大致思路为：不再将工具调用记录和其他文本一样转为string放入content里，而是以完整的调用结构化数据存放，与content分离。
进一步思考
为什么会发生这样的错误
在internal/pipeline/turn_response.go中可以看到，该Agent在把工具调用拼装入上下文的时候，会将其与其他对话上下文一起转换为下面的结构体：
go
type ContextMessage struct {
Role string `json:"role"`
Content string `json:"content"`
}在这个结构体中，工具调用也和其他聊天文本一样被压扁成string。但是为了表示不同，还会进一步写为这种xml格式。
可能因为项目在最初没有考虑到要将工具调用引入上下文，因而上下文消息只使用string来表示。但是后期引入工具调用上下文时，可能出于方便，没有同步修改消息结构。
关于issue #437
这个issue提出了一种解决方案，让Agent在收到LLM发来的消息的时候，扫描<tool_call ...>，并将其作为触发工具调用的符号。并且指出知名的Agent项目hermes-agent也是这么做的。
但是这种做法的缺陷在于：
<tool_call ...>本身就不应该是LLM触发工具调用的方式，强行兜底处理与项目设计意图相悖。
Agent可能会在不以触发工具调用为目的的时候发出<tool_call ...>，如引用历史工具调用记录。
为什么Hermes会使用这种方式来触发工具调用？
关于这点，我咨询GPT，其给出的答复是，Hermes本身就以在LLM返回的content中使用类似的XML标签来作为工具调用触发的标志。这与Memoh在发送的schema专门的tool_call结构中放入工具调用的内容的做法不一致。