引言
在大模型的能力版图里，"推理"和"知识"长期是主角，而"工具调用"则被视为一个工程细节——似乎把 JSON Schema 喂给模型、让它吐回一段结构化 JSON 就够了。但随着 Agent 范式的崛起，这个看似平淡的接口层正在变成整个系统架构的应力集中点：一次 Agent 任务可能涉及数百轮工具调用，上下文膨胀到百万 token 级别，思考链需要跨轮累积，参数载荷里嵌套代码、正则、长文本。在这样的负载下，协议设计的任何细微缺陷都会被放大成性能塌陷。
DeepSeek-V4 技术报告在工具调用对话这部分有一些特殊的设计，恰好代表了当前工业界对上述问题的一次系统性回应。本文以横向对比 OpenAI Harmony、Claude、MiniMax-M2、GLM、MiMo、Kimi K2 等方案，从问题背景—协议—上下文—延迟—训练—推理六个层面展开，回答一个核心问题：在百万 token 上下文的 Agent 时代，工具调用对话应该怎么被设计？
第一章 问题背景
工具调用并非新概念。早期 ReAct 范式下，一次对话只有 1–3 次工具调用，参数简单，思考链短，任何一种格式都能勉强工作。但近两年出现了三次明显的负载跃迁：
调用次数指数增长。Terminal-Bench、SWE-Bench 上完整任务的平均交互步数从 10 级别涨到 500 级别。V4 论文披露其内部 code agent 评估框架"maximum number of interaction steps is set to 500, and the maximum context length is set to 512K tokens"。
参数载荷复杂度膨胀。工具参数不再是简单字符串，而是包含完整代码片段、多行 diff、带嵌套引号和反斜杠的正则表达式、Markdown 文档。JSON 转义因此成为高频踩雷点。
思考链跨轮累积需求。长程任务里第 N 轮决策依赖于前 N-1 轮全部推理。如果每次 user turn 都清空<think>内容，模型被迫每轮重新"热身"，token 浪费和推理不连贯同时发生。
这三次跃迁分别对应协议层、上下文层、延迟层三个工程痛点：
| 痛点 | 触发条件 | 代价 |
|---|---|---|
| JSON 转义失败 | 参数含引号、反斜杠、代码块 | 单次调用失败 → 整条轨迹回滚 |
| 思考链管理失当 | 新 user turn 清空历史<think> | 每轮重新 prefill，连贯性损失 |
| 辅助任务串行化 | 主模型回答前需判定意图/搜索/权威性 | 独立小模型 prefill → 高 TTFT |
第二章 协议层：|DSML|特殊 token 为何优于 JSON
V3.2 沿用主流的 JSON function calling，V4 则做了一次协议级重构，引入专用特殊 token|DSML|把工具调用封装成类 XML 块：
<|DSML|tool_calls> <|DSML|invoke> <|DSML|parameter string="true|false">$PARAM_VALUE</|DSML|parameter> </|DSML|invoke> </|DSML|tool_calls>这个设计蕴含三个工程判断：
判断一：边界从"语义匹配"提升到"词表匹配"。|DSML|是独立 token，解析器无需正则匹配<tool_call>这类字符串——只需检测 token ID，在 tokenizer 层消除歧义。
判断二：字符串与结构化参数双通道。string="true|false"属性区分两类：字符串原文写入不需转义；数字、布尔、数组、对象走 JSON。这是精妙的折中——保留 JSON 嵌套表达力，绕开字符串转义噩梦。
判断三：协议与思考模式硬绑定。系统提示规定：若thinking_mode触发，模型必须先在<think>...</think>内推理再输出工具调用。"思考—行动"时序写进协议本身。
同一调用在三种协议下的形态对比
假设调用run_code，参数code含双引号、反斜杠、换行：
DeepSeek-V4：
<|DSML|invoke> <|DSML|parameter string="true"> import re pattern = r"(\d+)\\s+(\"hello\")" print(re.findall(pattern, text)) </|DSML|parameter> </|DSML|invoke>Claude / GLM / MiMo（标准 JSON）：
{"name":"run_code","arguments":{"code":"import re\npattern = r\"(\\d+)\\\\s+(\\\"hello\\\")\"\nprint(...)"}}JSON 方案里反斜杠变成\\\\、内部引号变成\\\"——这是严格但易错的约束。V4 方案让code字段原文几乎原样出现，只需识别</|DSML|parameter>闭合。
