[Design Discussion] enableToolCall=true 时 AI 文本中的 XML 工具标签是否应被执行

[CATMIAOZHI]

背景

#685 报告了 enableToolCall=true 时 AI 文本中的 XML 工具标签被 extractToolInvocations 提取执行的问题。经讨论，owner 确认当前行为是设计如此——XML toolcall 是项目的兼容协议，AI 输出的 XML toolcall 被执行是预期行为。

本 issue 不是 bug report，而是针对上述设计提出一个改进方向，供讨论。

设计问题

当前 enableToolCall 只控制 Provider 原生 tool call 与内部 XML 协议之间的转换，不影响执行层对 XML 的提取。这意味着：

• enableToolCall=true：Provider 原生 tool call 转成 XML 执行 ✅，AI 文本中的 XML 也被执行 ❌
• enableToolCall=false：AI 文本中的 XML 执行 ✅（唯一通道，合理）

两个通道并行，缺乏互斥语义。

建议的设计方向

enableToolCall 应作为通道选择开关：

enableToolCall	工具调用通道	AI 文本中的 XML
false	XML toolcall（唯一通道）	✅ 执行（预期行为，不变）
true	原生 function calling	❌ 不执行（走原生通道）

用户开启 enableToolCall=true 的意图是"走原生 function calling 通道"。此时 AI 在正文里解释工具格式、写代码示例时输出的 XML 不应被执行。

实测依据

在 enableToolCall=true 条件下，让 AI 原样重复一段 XML 工具标签文字，结果：系统将正文中的 XML 误识别为工具调用并尝试执行，报错 This tool is only available in...。AI 在 thinking 中正确理解了用户意图（"只要我重复文字，不是要我执行工具"），但执行层无法区分 XML 来源。

该问题在分析 Operit 工具调用机制时自然复现——AI 在正文中引用工具格式代码作为说明时触发了误执行。

PR #691 的评论区有实测对比截图（未修复版 vs 修复版）。

不涉及的部分

• 渲染层不讨论：AI 文本中的 XML 仍可渲染为工具调用卡片，视觉展示不改
• enableToolCall=false 行为不讨论：现有 XML toolcall 通道作为唯一通道，行为不变
• 不涉及具体实现方案：本 issue 仅讨论设计方向是否值得推进，实现细节在方向确认后再议

为什么单独开 issue

PR #691 和 #686 尝试在 bugfix 框架下推进修复，owner 正确指出这属于设计变更而非 bugfix。因此本 issue 作为 design discussion 单独提出，与 #685 的 bug 报告框架分开。

[luojiaping]

背景

#685 报告了 enableToolCall=true 时 AI 文本中的 XML 工具标签被 extractToolInvocations 提取执行的问题。经讨论，owner 确认当前行为是设计如此——XML toolcall 是项目的兼容协议，AI 输出的 XML toolcall 被执行是预期行为。

本 issue 不是 bug report，而是针对上述设计提出一个改进方向，供讨论。

设计问题

当前 enableToolCall 只控制 Provider 原生 tool call 与内部 XML 协议之间的转换，不影响执行层对 XML 的提取。这意味着：

• enableToolCall=true：Provider 原生 tool call 转成 XML 执行 ✅，AI 文本中的 XML 也被执行 ❌
• enableToolCall=false：AI 文本中的 XML 执行 ✅（唯一通道，合理）

两个通道并行，缺乏互斥语义。

建议的设计方向

enableToolCall 应作为通道选择开关：

enableToolCall 工具调用通道 AI 文本中的 XML
false XML toolcall（唯一通道） ✅ 执行（预期行为，不变）
true 原生 function calling ❌ 不执行（走原生通道）
用户开启 enableToolCall=true 的意图是"走原生 function calling 通道"。此时 AI 在正文里解释工具格式、写代码示例时输出的 XML 不应被执行。

实测依据

在 enableToolCall=true 条件下，让 AI 原样重复一段 XML 工具标签文字，结果：系统将正文中的 XML 误识别为工具调用并尝试执行，报错 This tool is only available in...。AI 在 thinking 中正确理解了用户意图（"只要我重复文字，不是要我执行工具"），但执行层无法区分 XML 来源。

该问题在分析 Operit 工具调用机制时自然复现——AI 在正文中引用工具格式代码作为说明时触发了误执行。

PR #691 的评论区有实测对比截图（未修复版 vs 修复版）。

不涉及的部分

• 渲染层不讨论：AI 文本中的 XML 仍可渲染为工具调用卡片，视觉展示不改
• enableToolCall=false 行为不讨论：现有 XML toolcall 通道作为唯一通道，行为不变
• 不涉及具体实现方案：本 issue 仅讨论设计方向是否值得推进，实现细节在方向确认后再议

为什么单独开 issue

PR #691 和 #686 尝试在 bugfix 框架下推进修复，owner 正确指出这属于设计变更而非 bugfix。因此本 issue 作为 design discussion 单独提出，与 #685 的 bug 报告框架分开。

感谢你把这个问题单独拆成 design discussion，也感谢你补充了复现、实测和方案对比。这个问题本身我认为是有讨论价值的：`enableToolCall=true` 时，正文 XML toolcall 是否还应该作为执行通道，确实属于工具调用协议语义的一部分。

我也想补充一下目前项目维护侧的现实情况，方便大家理解为什么我们会对 Operit 1 的行为变更比较谨慎。

现在 AA 主要精力在筹备 Operit 2全平台上线，Operit 1 这边大量 issue triage、用户反馈确认、bug 复现、PR 评估、兼容性判断，实际上都是在非常有限的维护精力下处理。最近 issue 数量刚从一百多条压到四十多条，很多问题还涉及不同模型、不同 Provider、不同 OpenAI-compatible 端点、不同版本历史行为之间的差异。这里面不少问题不是单点 bug，而是模型表现、Transformer 输出稳定性、兼容端点实现差异和项目历史协议叠加后的结果。你也可以看看最近的commit历史，如果是很好修复的，不会产生太大兼容性问题，我都会优先在24小时以内解决。

所以对 Operit 1 来说，我们现在会更倾向于优先处理几类问题：

1. 明确可复现、影响范围清晰的 bug
2. 不改变既有协议语义的小修复
3. 不会影响旧模型、旧对话、旧 Provider 行为的兼容性问题
4. 能够直接降低用户侧故障率的问题

而这个 issue 讨论的是更底层的协议语义：`enableToolCall=true` 是否应该让原生 function calling 与 XML toolcall 通道互斥。这个方向不是不能讨论，但它会影响 Operit 1 既有的 XML canonical form、历史消息、旧格式 toolcall、兼容端点，以及部分实际并不稳定支持原生 function calling 的模型。
你可以看一下issue #616 里面我做的一个合集，关于模型工具调用的问题，其实里面80%的解决方法都依赖模型厂商不断优化＋软件的herness工程优化。

换句话说，这不是一个“加一个判断就能安全修掉”的问题。它需要先确认设计边界，再确认是否要为 Operit 1 改变长期行为。如果现在直接在 Operit 1 里改，风险是修掉正文 XML 示例误执行的同时，破坏另一批模型和历史场景里的工具调用能力。

因此简而言之：

- 这个 issue 可以保留为设计讨论；
- 相关实测和方案对比我会记录下来；
- Operit 1 暂时不把它作为 设计方向 推进；
- 更完整的工具调用通道隔离、来源标记、历史消息结构化处理，建议放到 Operit 2 的工具协议设计里统一考虑。

这不是否定这个问题，而是基于当前维护压力和兼容风险做的取舍。现在 Operit 1 更需要稳定收敛，避免在协议层引入新的不确定性。

这个问题我会继续关注，但在 Operit 1 当前维护阶段，我会优先保证已有用户和已有模型配置不被新的协议语义变化影响。

而且我国产模型一般只用DeepSeek。选的provider也是内置的deepseek， Deepseek的工具调用能力个人感觉是不如gpt5.5的，不过我们在v4发布之后，我们也进行了一些优化，目前的工具调用链相对稳定。QQ群，频道，discord没有大范围的关于此问题的反馈。因为你我当时让你补充的测试信息让我感到很疑惑.①假设你是ollama本地部署glm 5.2，非原版16/8的话，低精度量化一定会显著下滑工具调用能力，结构化参数回传故障率翻倍，不是“轻微变差”，是直接影响Agent流程可用性，llama.cpp/Ollama底层无法在INT4/INT5低量化下完整兼容MTP；低精度权重会直接阉割MTP逻辑，多步骤Plan→Build循环、多工具连续调用直接崩盘，参数回传丢失上下文、历史工具入参。
1. 大量开发者issues反馈：Ollama拉取的glm5.2:q4版本做自动化Agent，Plan规划后Build环节参数全部丢失，无法传递Goal定义的约束参数；切换q6版本后问题90%修复。
​
2. llama.cpp社区评测：GLM5.2属于MoE稀疏专家模型，门控路由层权重对量化极其敏感，低bit量化会导致模型选错专家模块，而工具调用、结构化输出依赖专用专家层，精度一降直接失效。
​
3. 对比云服务火山引擎GLM5.2：云端是FP8半全精度，tool call经过官方微调优化；本地Ollama低量化版本丢失微调对齐权重，工具遵循能力大幅缩水
②如果你是智谱官方渠道的话，请选择智谱接口接入使用。我们进行了优化，如果还存在问题，我们会专门对此provider进行优化。
这个改动要测试大量的不同模型的实际调用体验，甚至还要考虑官方接口和中转接口

[CATMIAOZHI]

不是不是我走的是ollama cloud pro的订阅的glm5.2（不是本地部署，没有量化问题）我说的是工具解析的问题，这个在所有的模型，（开启了原生toolcall）都会有这个问题。
你可以测试一下，开启原生 toolcall，在聊天框里面发如下内容：

原样重复下面的文字
<tool name="search">
  <param name="query">测试</param>
</tool>

由于错误的工具调用解析，会导致这段本应作为普通文本重复的 XML 被识别为工具调用，从而进入错误/循环流程
我觉得现在模型的原生toolcall已经很好了，我在使用。deepseekv4pro的时候基本上没有工具调用失败，偶尔有错误（比如ai写参数写错了）也能很快自己修复，glm5.2的工具调用就更精确了。
我个人开发用的是deepseekv4pro，glm5.2，gpt5.5，我测试了这些模式上面的提示词都有这个问题，我认为这是一个设计问题