换国产模型驱动Claude Code之后，Tool Use的格式转换到底可不可靠，DeepSeek或GLM在Claude Code的Agent循环里会不会因为工具调用协议不匹配而频繁空转或静默失败？

目录

一、导语：一次“看起来成功”的替换

很多团队做过这样一件事：把 Claude Code 的模型后端从 Anthropic 官方端点切到某个国产模型网关，改几行环境变量，跑一次 hello world 级别的任务，看到终端里文件被创建、命令被执行，于是判断“能用”。但真正进入多轮 Agent 循环之后，问题开始以极其隐蔽的方式出现：模型不再调用工具，而是用自然语言描述“我将要调用某个工具”；工具参数里多出一层 arguments 嵌套；本该失败的工具返回被当成成功继续推进；循环在没有任何异常日志的情况下原地打转直到 token 耗尽。

这类现象的共同特征是：系统没有崩溃，但系统没有前进。它既不是传统意义上的 bug，也不是模型能力不足的简单结论，而是发生在协议转换层的一种系统性语义损耗。本文要回答的核心问题只有一个：当 Agent 循环依赖的工具调用协议被翻译时，这种翻译在多大程度上是可靠的，失效又发生在哪些具体位置。

本文评述：把“换模型”理解为“换协议”而非“换端点”，是理解全部问题的起点。端点替换是一次性的配置动作，协议翻译则是每一轮对话都要重复执行的运行时行为，二者的可靠性要求不在同一个量级上。

二、背景与问题定义：两套工具调用协议的真实落差

2.1 什么是工具调用协议

工具调用协议（Tool Use Protocol）指模型与宿主程序之间，用于表达“我要调用哪个工具、传什么参数、结果如何回填”的一套结构化约定。它包含三个不可分割的部分：声明侧（工具 schema 如何描述给模型）、生成侧（模型如何输出调用意图）、回填侧（工具结果如何以模型可理解的形式送回上下文）。任何一侧的语义偏差都会在循环中被放大。

2.2 Anthropic 与 OpenAI 两套范式的结构性差异

Claude Code 的 Agent 循环建立在 Anthropic Messages API 之上，其工具调用以 tool_use / tool_result 内容块（content block）的形式内嵌在消息序列中；而 DeepSeek、GLM 等国产模型的主流接口大多兼容 OpenAI 风格的 function calling，工具调用以独立的 tool_calls 字段挂在 assistant 消息上。两者在数据模型上并非同构。

最关键的差异不在字段名，而在消息角色的组织方式。Anthropic 把工具调用视为 assistant 消息内容的一部分，工具结果作为 user 消息中的 tool_result 块回填；OpenAI 范式则引入独立的 tool 角色消息，通过 tool_call_id 做关联。这意味着一次转换不是简单的字段改名，而是消息序列拓扑结构的重排。

# Anthropic Messages 风格（Claude Code 原生）
user:      "读取 config.yaml 并修复端口冲突"
assistant: [text] "我先看下文件"
           [tool_use id=tu_01 name=read_file input={path:"config.yaml"}]
user:      [tool_result tool_use_id=tu_01] "port: 8080 ..."
assistant: [tool_use id=tu_02 name=edit_file input={...}]

# OpenAI function calling 风格（多数国产模型兼容）
user:      "读取 config.yaml 并修复端口冲突"
assistant: content="我先看下文件"
           tool_calls=[{id:"call_01", function:{name:"read_file",
                        arguments:"{\"path\":\"config.yaml\"}"}}]
tool:      tool_call_id="call_01" content="port: 8080 ..."
assistant: tool_calls=[{id:"call_02", ...}]

本文评述：注意 arguments 在 OpenAI 范式里是字符串而非对象，这一设计选择看似细节，实则是大量解析失败的源头——它要求模型生成合法 JSON 字符串，而字符串的转义、截断、嵌套都会引入新的失败面。

2.3 问题边界：本文讨论什么、不讨论什么

本文聚焦于协议转换层的可靠性，即模型输出到宿主执行之间的翻译正确性，不讨论模型本身的推理能力上限，也不讨论具体业务逻辑的正确性。换言之，即使模型“想对了”，转换层也可能让它“做错了”；反之，转换层无法弥补模型“想错了”。这个边界划分对后续归因至关重要。

三、分析主线：协议熵——转换损耗为什么会累积

为了给全文提供一条统一的分析主线，本文引入一个工作性概念：协议熵（Protocol Entropy）。它指在一次协议转换中，源协议语义无法被目标协议无损表达的程度。协议熵不是热力学量，而是一个工程度量：每一次字段映射、每一次角色重排、每一次类型转换，都会贡献一份不可逆的信息损耗。

H_round = Σ ( w_i × loss_i ) + ε

其中：
  loss_i  = 第 i 类字段映射的语义损耗（0~1）
  w_i     = 该类字段在 Agent 循环中的权重
  ε       = 模型生成侧的随机性残差

关键性质：H_total ≈ n × H_round （n 为循环轮数）
—— 单轮损耗看似微小，多轮累积后呈线性放大

这个表达的价值不在于精确计算，而在于揭示一个反直觉的结论：协议转换的可靠性不能按单轮评估。单轮 2% 的失败率听起来可以接受，但在 30 轮的工具调用循环中，至少发生一次转换失败的概率约为 1-(0.98)^30 ≈ 45%。这正是“跑 demo 能用、跑长任务崩”的数学解释。

笔者认为：协议熵这个概念最大的实践意义，是把“偶发诡异问题”转化为“可预期的累积风险”。一旦接受损耗会累积，工程重心就会从“修 bug”转向“降低单轮损耗 + 增加循环级容错”，这是两种完全不同的治理姿态。

四、字段级拆解：从 tool_use 到 function calling 的映射表

要判断转换是否可靠，必须下沉到字段级。下表整理了 Anthropic 风格与 OpenAI 风格在工具调用相关字段上的对应关系，以及每一处映射的损耗风险等级（本文评述性评估，基于公开 API 文档的字段语义对比）。

这张表里最容易被低估的是最后一行：错误表达的语义不对称。Anthropic 范式有显式的 is_error 标记，模型能明确知道“这次工具调用失败了”；而 OpenAI 范式没有对应的标准字段，失败信息只能塞进内容字符串里。转换层若不做显式约定，模型会把错误文本当作正常结果继续推理——这正是静默失败的结构性根源。

本文评述：字段映射的难点从来不是“名字对不上”，而是“语义在目标协议里没有对应物”。is_error 的缺失就是典型：你无法用一个不存在的字段去表达一个必须表达的语义，只能在内容层做约定，而约定是软约束，模型可以不遵守。

五、六类失效模式：空转、静默失败与假成功

基于上述字段级落差，可以把转换层的失效归纳为六类。每一类都对应可识别的信号，也对应不同的修复策略。

5.1 模式一：调用意图降级为自然语言（空转主因）

模型在目标协议的训练/对齐中，可能更倾向于用自然语言描述动作，而非输出结构化 tool_calls。转换层看到的是纯文本，无法提取调用，于是把文本原样回填。Agent 循环继续，模型再次描述动作，再次无法执行——形成典型的空转。这类失效在日志里的特征是：assistant 消息 content 非空但 tool_calls 为空，且 content 中出现“我将调用”“接下来执行”等意图性表述。

5.2 模式二：arguments 字符串解析失败

当模型生成的 arguments 不是合法 JSON（常见于含引号、换行、中文标点的参数），转换层 JSON.parse 抛错。若转换层选择“吞掉异常并跳过该调用”，宿主看到的就是一次没有发生的工具调用，而模型以为它发生了。这是静默失败的经典形态。

5.3 模式三：参数双层嵌套

转换层若把已经解析好的对象再次 JSON.stringify 后塞进 arguments，或反向多做一次 parse，就会出现 {"arguments": "{\"path\": ...}"} 这样的嵌套。工具收到参数后字段缺失，返回错误，但错误又被模式四掩盖。

5.4 模式四：错误语义丢失（假成功）

工具执行失败，但转换层把错误信息作为普通文本回填，模型据此认为操作成功，继续下一步。整条任务链在错误的前提上推进，最终产出看似完整实则错误的结果。这类假成功比崩溃更危险，因为它不触发任何告警。

5.5 模式五：并行调用关联错乱

当模型一次返回多个 tool_calls，转换层需要为每个结果匹配正确的 tool_call_id。若 id 生成或映射有误，结果会串到错误的调用上，模型基于错误结果继续推理。这类失效在多工具协作场景（如同时读文件、跑命令、查网络）中概率显著上升。

5.6 模式六：停止原因误判导致循环终止或死循环

宿主依据 finish_reason 判断是否继续循环。若转换层把 tool_calls 误映射为 stop，循环提前终止；若把 stop 误映射为 tool_calls，宿主会等待一个不存在的工具结果，形成死循环。

模式              外部表现        日志信号                  修复方向
1 意图降级        空转            content非空/tool_calls空   提示词+格式约束
2 解析失败        静默跳过        parse异常被吞              严格校验+重试
3 双层嵌套        参数缺失        arguments含转义JSON        单次parse契约
4 错误丢失        假成功          is_error无对应字段         显式错误约定
5 关联错乱        结果串台        id不匹配/重复              id映射表校验
6 停止误判        早停/死循环     finish_reason异常          状态机校验

本文评述：六类模式并非独立，而是存在级联关系。模式二被吞掉后，模型以为调用成功，可能触发模式四；模式三导致参数错误，工具报错，又回到模式四。真正难排查的不是单一模式，而是多个模式叠加后形成的“看起来一切正常”的假象。

六、可观测性：如何在日志里抓到“没报错的错误”

静默失败的本质是“错误没有以错误的形式出现”，因此常规的异常监控抓不到它。需要在 Agent 循环层引入一组协议健康指标，把语义层面的异常转化为可告警的数值信号。

这组指标的设计原则是：每一个指标都对应一种失效模式，且都能在转换层内部低成本采集。它们不依赖模型自报，也不依赖工具返回值，而是直接观测协议流本身。本文评述：可观测性的价值在于把“玄学问题”变成“可归因的分布偏移”，一旦指标曲线出现拐点，就能快速定位是模型侧漂移还是转换层回归。

七、工程路径：最小可行适配层的设计与步骤

基于前文的失效分析，可以设计一个最小可行适配层（Minimal Viable Adapter，MVA）。它的目标不是追求零损耗，而是把损耗控制在可观测、可恢复的范围内。以下步骤按落地顺序排列。

步骤一：建立单一转换契约

明确规定 arguments 在转换层内部只 parse 一次、只 stringify 一次，并在边界处做类型断言。禁止在多个函数里反复 parse/stringify，这是模式三的根治手段。契约应写成可执行的类型定义，而非文档约定。

步骤二：显式错误通道

在回填工具结果时，统一采用带标记的包装格式，例如在内容前加 [TOOL_ERROR] 前缀，并在系统提示中告知模型该前缀的含义。这弥补了 OpenAI 范式缺失 is_error 的结构性缺陷。本文评述：软约定不如硬字段可靠，但在目标协议无对应字段时，软约定 + 提示词强化是当前最务实的折中。

步骤三：调用意图兜底解析

针对模式一，在转换层增加一个轻量兜底：当 tool_calls 为空但 content 中出现结构化意图（如 JSON 代码块、明确的函数名+参数描述）时，尝试提取并构造调用，同时记录“兜底命中”指标。兜底不是长久之计，但能显著降低空转率，为模型侧对齐争取时间。

步骤四：状态机校验

用显式状态机管理 Agent 循环的每个状态转移（等待模型→解析调用→执行工具→回填结果→再等待），每次转移前校验 finish_reason 与 tool_calls 的一致性。不一致则进入降级分支（重试、截断或人工介入），而非静默继续。

步骤五：id 映射表与并行安全

为每次调用维护一张 id 映射表，确保 tool_call_id 在请求与回填之间严格一一对应。并行调用时，结果回填顺序不影响正确性，但 id 必须精确。建议在回填前做一次全量 id 校验，不匹配即拒绝回填并重试。

function adaptToolCall(assistantMsg, toolRegistry) {
  const calls = assistantMsg.tool_calls ?? [];
  if (calls.length === 0) {
    const recovered = tryRecoverIntent(assistantMsg.content);
    if (recovered) { metrics.fallbackHit++; return [recovered]; }
    metrics.idleRounds++; return [];
  }
  return calls.map(c => {
    let args;
    try { args = JSON.parse(c.function.arguments); }
    catch (e) { metrics.parseFail++; return { error: "PARSE_FAIL", id: c.id }; }
    if (!validateSchema(args, toolRegistry[c.function.name])) {
      metrics.schemaFail++;
      return { error: "SCHEMA_FAIL", id: c.id };
    }
    return { id: c.id, name: c.function.name, args };
  });
}

function adaptToolResult(result, callId, isError) {
  const prefix = isError ? "[TOOL_ERROR] " : "";
  metrics.errorPassThrough += isError ? 1 : 0;
  return { role: "tool", tool_call_id: callId, content: prefix + result };
}

八、评测方法：构造可复现的工具调用压力集

要回答“到底可不可靠”，必须有可复现的评测。公开基准如 Berkeley Function Calling Leaderboard（BFCL）提供了函数调用能力的横向对比，但它主要评估单轮/少轮的调用正确性，对 Agent 多轮循环中的协议转换损耗覆盖不足。因此需要在公开基准之外，自建一套协议压力集。

8.1 压力集的设计维度

建议覆盖四个维度：参数复杂度（简单标量→嵌套对象→含特殊字符）、循环深度（1 轮→10 轮→30 轮）、并行度（单调用→多调用）、错误注入（工具正常→工具报错→工具超时）。每个维度组合成一个用例，记录六类失效模式各自的命中次数。

8.2 数据预处理说明

本文引用的公开基准数据均来自各榜单官方发布页面，评测时间为 2024 年至 2025 年间。对于自建压力集，若使用模拟数据，需明确标注为“模拟数据”，并说明生成方式（如基于模板随机组合参数结构、固定随机种子以保证可复现）。所有用例应保存原始请求/响应日志，便于第三方复核。本文不虚构任何作者或团队的实验数据；凡涉及具体数值的整合分析，均在文中标注“整合数据”或“模拟数据”。

本文评述：评测协议转换可靠性时，最容易犯的错误是只测“成功路径”。真正决定长任务成败的是错误路径下的行为——工具报错时模型是否知情、解析失败时系统是否重试、并行结果是否串台。压力集的重心应放在错误注入维度。

九、案例与数据：公开基准与整合数据的解读

从公开信息看，DeepSeek 系列与 GLM 系列在函数调用能力上持续迭代。DeepSeek 在其 API 文档中提供了 OpenAI 兼容的函数调用接口，并在后续版本中强化了工具调用与 JSON 输出能力；GLM 系列同样提供 function calling 支持，并在部分版本中针对 Agent 场景做了优化。这些是“能力存在”的证据，但不等于“在 Claude Code 的协议转换下可靠”。

需要区分三个层次：模型原生调用能力（能否正确生成 tool_calls）、协议兼容性（字段是否对齐）、转换层实现质量（映射是否正确）。公开基准主要测第一层，而实际体验由三者共同决定。很多“换了模型就不好用”的反馈，归因到第一层是误判，问题往往在第二、三层。

本文评述：把归因拆成三层，能避免大量无效争论。社区里常见的“某模型工具调用不行”与“某网关转换有 bug”，往往描述的是同一现象的不同层次。只有分层定位，才能决定是换模型、改协议约定，还是修适配层代码。

十、对比与局限：国产模型的真实位置

客观地说，DeepSeek、GLM 等国产模型在工具调用上的进步是显著的，尤其在结构化输出、JSON 模式、多工具选择等方向上有明确的工程投入。但“能力进步”与“在特定 Agent 框架下的开箱即用”之间仍有距离，这个距离主要由协议差异和转换实现填充。

局限主要有三：其一，错误语义的表达在 OpenAI 范式下缺乏标准字段，任何实现都只能靠约定，可靠性有上限；其二，长循环下的分布漂移难以在单轮基准中体现，需要专门的压力测试；其三，框架侧的隐式假设（Claude Code 对 Anthropic 协议的深度依赖）使得转换层必须理解框架行为，而非只做字段翻译。

笔者认为：与其问“国产模型能不能驱动 Claude Code”，不如问“在什么转换实现质量下、跑多长的任务、能接受多高的失败率”。把问题参数化，才能得到有工程意义的答案；把问题口号化，只会陷入无休止的立场之争。

十一、结论与展望：把不确定性关进工程笼子

回到最初的问题：格式转换可靠吗？答案是有条件地可靠。在单轮、简单参数、无错误的场景下，主流转换实现基本可用；在多轮、复杂参数、错误注入的场景下，可靠性取决于适配层的设计质量与可观测性建设。空转与静默失败不是必然，但它们是协议熵累积到一定阈值后的自然结果，必须被工程手段主动管理。

可落地的行动清单：建立单一转换契约、显式错误通道、意图兜底、状态机校验、id 映射校验、六项协议健康指标、四维压力集。这七件事做完，绝大多数“诡异问题”会从不可解释变为可归因、可恢复。

展望未来，两个方向值得关注：一是模型侧对工具调用协议的原生对齐，若国产模型能在训练中直接覆盖 Anthropic 风格的内容块语义，转换损耗将大幅下降；二是框架侧的协议抽象，若 Agent 框架把工具调用抽象为与厂商无关的中间表示，转换层将从“翻译”变为“适配”，可靠性天花板会显著抬高。本文评述：在两者成熟之前，工程侧的可观测性与容错设计仍是性价比最高的投入。

十二、参考文献与拓展资源

12.1 主要参考文献（8 篇）

说明：本文参考文献与资料总计数不少于 60 篇，涵盖 Anthropic、OpenAI、DeepSeek、智谱等官方 API 文档、BFCL 等公开基准、ToolLLM/Toolformer 等工具调用研究，以及 2023–2025 年间的相关论文与工程博客，其中近三年（2023 年起）文献占比超过 50%。上文仅列出 8 篇主要参考文献，完整清单以原始文献为准。

12.2 拓展资源（教程与视频）

12.3 文章声明