背景

近期在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在把工具调用拼装入上下文的时候，会将其与其他对话上下文一起转换为下面的结构体：

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结构中放入工具调用的内容的做法不一致。