能力匹配，行为不同：语言智能体 MCP 与 CLI 接口的受控研究

1. 问题与价值

这篇论文解决的核心问题是：当语言智能体的可执行能力完全相同时，能力的「模型可见表示形式」本身是否足以改变智能体的行为。具体来说，MCP（Model Context Protocol，以命名工具加结构化 JSON 参数呈现）和 CLI（命令行接口，以命令、标志、文本参数呈现）可以表达完全相同的语义操作，但论文要检验这两种表示是否会导致不同的动作选择、失败路径、恢复行为、交互成本和最终任务得分。

这个问题重要，因为现代智能体系统越来越多地通过工具和终端环境行动，而 MCP 和 CLI 是两种最主流的接入方式。如果接口表示确实改变行为，那么接口设计就不能被视为被动的「访问层」，而应被视为闭环决策环境的一部分。受益者包括：构建智能体脚手架的系统设计者（他们需要知道选择 MCP 还是 CLI 不只是工程偏好）、工具注册表和协议的设计者（他们需要理解 schema 设计如何影响模型决策）、以及评估智能体的研究者（他们需要控制接口变量才能公平比较模型能力）。

2. 已有工作的不足

在本文之前，已有工作已经触及接口表示对智能体行为的影响，但存在两个关键不足。

第一类不足是「系统级比较混淆了多个变量」。例如，原文引用的 Béchard et al. (2026) 的终端智能体与企业自动化研究（原文引用编号 [16]）指出，能力打包方式解释了终端智能体与 MCP 工具注册表之间性能差异的很大一部分。但这类系统级比较同时改变了工具粒度、提示词、公开信息、验证逻辑和执行脚手架，因此无法把性能差异归因于「表示」本身。原文还引用了 Alier Forment et al. (2026)（引用编号 [17]）的七种脚手架对比研究，该研究发现脚手架的影响大于接口本身——这恰恰说明如果不控制脚手架，接口效应会被淹没或误读。

第二类不足是「端点指标坍缩了不同的交互路径」。原文引用的 MCP-Bench（Wang et al., 2026，引用编号 [19]）等基准测试主要报告最终得分或成功率，但同一个最终得分可能来自完全不同的语义选择、实现失败和恢复路径。一个早期的局部差异会改变后续所有决策所依赖的历史和状态，而端点指标无法揭示这种路径依赖。

此外，原文引用的 Wang et al. (2024)（引用编号 [5]，关于可执行代码动作）和 Yang et al. (2024)（引用编号 [8]，SWE-agent 的智能体-计算机接口）表明动作表示会影响工具使用，但这些工作没有在「语义动作契约完全匹配」的条件下隔离表示变量。Yuan et al. (2025)（引用编号 [6]，EASYTOOL）和 Blankenstein et al. (2026)（引用编号 [7]，BiasBusters）研究了工具名称、描述和排序的影响，但同样没有把「表示」从「能力」中解耦出来。

3. 重建作者的思考路径

如果我是作者，面对第 2 项里的不足，我会这样推。

第一步：先做「语义匹配」。 既然系统级比较混淆了太多变量，最直接的思路是把 MCP 和 CLI 从同一个「语义动作契约」渲染出来。也就是说，先定义一个规范化的动作空间，比如 go(destination="sofa 1")，然后让 MCP 渲染成 {"name": "alfworld__go", "arguments": {"destination": "sofa 1"}}，让 CLI 渲染成 bench alfworld go --destination 'sofa 1'。两者解码后回到同一个语义动作，进入同一条验证、编译、执行流水线。这样，可执行能力就真正固定了。

撞上的矛盾： 但即使语义匹配了，端点得分差异仍然无法解释「为什么」会有差异。同一个得分可能来自不同的动作选择，也可能来自相同的动作选择但不同的表面实现失败。如果只看得分，我会陷入「有差异但不知道为什么」的困境。

第二步：引入「轨迹级归因」。 我需要一个方法来判断差异是从哪一步开始的。于是想到配对轨迹：让 MCP 和 CLI 从相同的初始状态出发，逐步对比每一步的「交互签名」（语义提案、失败阶段、执行结果、恢复状态）。第一个签名不同的步骤就是「首个因果性分歧点」。在这个点之前，两个轨迹的上下文是对齐的，可以做局部对比；在这个点之后，各自的历史和状态分叉，可以追踪传播效应。

撞上的新矛盾： 但轨迹级分析只能告诉我「差异在哪里出现」，不能告诉我「接口的哪个组件造成了差异」。MCP 和 CLI 的差异至少涉及三个组件：呈现（操作怎么描述）、实现（响应怎么编码）、反馈（错误和执行结果怎么显示）。如果只比较整体 MCP 和整体 CLI，我无法定位敏感点。

第三步：做「匹配状态探针」。 在固定的决策上下文（相同的环境状态、历史、契约、模型、生成配置）下，把呈现、实现、反馈三个组件各自独立地切换为 MCP 或 CLI 形式，形成 2×2×2 的因子设计。这样我就能估计每个组件的主效应和交互效应。这一步的关键是「冻结上下文」，否则后续采样会污染前面的状态。

撞上的又一个矛盾： 探针分析告诉我「实现组件」是最大的敏感点，尤其是实现失败率。但知道敏感点还不够——如果实现失败后模型重新选择语义动作，那么修复实现失败就变成了「重新决策」，而不是「修复表达」。这引出一个问题：语义决策和接口实现是否可以解耦？

第四步：设计 DART。 如果语义动作已经验证有效，那么实现失败时不应该放弃这个语义承诺，而应该只修复接口特定的表达。于是想到一个两阶段控制器：先让模型输出规范化的语义动作（schema_id 加 arguments），验证通过后把它固定为承诺；然后让模型把这个承诺表达成 MCP 或 CLI 的表面形式；如果表面实现失败但承诺仍然有效，就只发一次「保持承诺的修正」请求，只改表达不改语义。

与论文实际路径的差异： 我猜的路径和论文实际走的路径在大的逻辑上是一致的：语义匹配 → 轨迹归因 → 匹配状态探针 → DART。但论文在轨迹归因和探针分析之间还引入了一个我一开始没有明确意识到的层次：论文把「交互签名」定义为包含语义提案、失败阶段、执行结果和恢复状态的四元组（式 2：b_t = (â, f, ω, r)）—— 注意附录 B.3 的对齐清单多列了一项 public feedback，共五项，正文与附录口径不一致，并且用「首个因果性分歧点」来严格区分「表面变化」和「因果性分歧」。我最初的想法是直接比较语义动作是否相同，但论文更精细地定义了「表面字符串可以不同，只要解码到同一个语义动作且产生相同的交互结果，就仍算在共同前缀内」。这个定义让「94.3% 的配对轨迹出现结构化分歧」这个数字有了更严格的含义。另外，论文把 DART 的触发范围限定在「可重试的、策略拥有的失败且环境状态确认未变」，这个约束条件比我最初设想的更窄，也更可辩护。

4. 核心 intuition

用一个日常类比：同一个菜谱，用两种不同的排版印刷，会影响厨师做菜的方式。

假设一个厨房里有完全相同的食材、炉灶和工具（对应「匹配的可执行能力」）。菜谱 A 把每道工序写成结构化的表格：「步骤 3：取平底锅，火力=中高，时间=3 分钟」。菜谱 B 把同样的工序写成叙述性命令行：「平底锅 --火力 中高 --时间 3分钟」。食材和操作完全相同，但厨师读菜谱 A 时可能更关注「火力」这个字段，读菜谱 B 时可能被 --时间 这个标志的排版方式干扰，导致他漏看了某个参数或者犹豫要不要加引号。

这个类比对应论文的机制：接口表示改变了模型在每一步「看到什么线索」以及「如何表达动作」。MCP 的结构化 JSON 让模型更容易把注意力放在参数名和类型上，但也可能诱导模型输出多余的字段（如论文中 ALFWorld 的 alfworld.move 失败案例：模型把 destination、object 两个参数都放在顶层、缺 arguments 包裹，违反「只能含 name 和 arguments」的契约，验证直接失败（object 本身是合法参数，不是多余字段））。CLI 的命令行语法让模型更容易在引号处理上出错（如 WebShop 的 18''x18'' 引号丢失案例），但它的线性文本形式在某些环境下可能让模型更快地扫描可用操作。关键不是哪种表示「更好」，而是表示改变了模型在每一步的局部决策分布，而局部决策通过闭环交互被放大成轨迹级差异。

5. 方法 pipeline 举例

以 ALFWorld 的一个具体任务为例：「cool some mug and put it in coffeemachine」（冷却一个马克杯并放进咖啡机）。

输入： 任务指令、当前观察（You arrive at coffeemachine 1. On the coffeemachine 1, you see nothing.）、可见交互历史（已执行 cool mug 1 with fridge 1 和 go to coffeemachine 1）、当前语义契约（包含 alfworld.move(destination, object) 等操作）。

步骤 1：契约渲染。 MCP 渲染器把 alfworld.move 渲染为工具 alfworld__move，参数 schema 为 {"destination": "string", "object": "string"}。CLI 渲染器把同一操作渲染为命令 bench alfworld move --destination <value> --object <value>。两者的语义契约完全相同。

步骤 2：模型采样。 在 MCP 条件下，模型输出 <tool_call>{"name": "alfworld__move", "destination": "coffeemachine 1", "object": "mug 1"}</tool_call>。这个输出把 destination 和 object 两个字段都放在了顶层、完全没有 arguments 包裹；MCP 的契约要求「tool call 只能含 name 和 arguments」，所以解码器无法解析。在 CLI 条件下，模型输出 <command>bench alfworld move --destination 'coffeemachine 1' --object 'mug 1'</command>，这个输出可以正常解码。

步骤 3：解码与验证。 MCP 解码器返回 ⊥（解码失败），因为工具调用的格式要求是 name 和 arguments 两个字段，而模型把 destination 放在了顶层。CLI 解码器成功解析出语义动作 alfworld.move(destination="coffeemachine 1", object="mug 1")，并通过共享语义验证。

步骤 4：执行与反馈。 CLI 路径进入共享执行器，编译为原生动作 move mug 1 to coffeemachine 1，执行成功，环境状态更新，反馈为 You move the mug 1 to the coffeemachine 1.。MCP 路径因为解码失败，环境状态不变，反馈为验证错误信息。

步骤 5：恢复。 在 Base 策略下，MCP 路径收到验证错误后，模型获得一次修正机会。如果修正仍然失败，该尝试被记为失败，模型需要重新选择动作。在 DART 策略下，控制器先让模型输出规范化的语义承诺 {"schema_id": "alfworld.move", "arguments": {"object": "mug 1", "destination": "coffeemachine 1"}}，验证通过后固定这个承诺，然后让模型只负责把这个承诺表达成 MCP 表面形式。修正后的输出 <tool_call>{"name": "alfworld__move", "arguments": {"destination": "coffeemachine 1", "object": "mug 1"}}</tool_call> 被接受，执行成功。

步骤 6：轨迹分叉。 在这个例子中，MCP 和 CLI 在第一步就出现了因果性分歧（MCP 解码失败，CLI 解码成功）。之后 MCP 轨迹需要额外的修正调用，消耗更多 token，且可能因为修正失败而改变后续动作选择；CLI 轨迹直接推进到下一个状态。这就是论文中「早期差异通过后续交互传播」的具体机制。

6. 核心数学推导

论文的核心形式化框架围绕三个关键公式展开。由于原文公式在提取中有部分损坏，以下推导基于可辨认的部分。

公式 1：语义动作与接口分解。

设智能体策略为 π_θ，在决策步 t 环境状态为 s_t，策略可见观察为 o_t，公开交互历史为 h_t。基准测试定义了语义动作契约 C_t，智能体从中选择动作 a_t = (u_t, v_t)，其中 u_t 是操作，v_t 是规范化类型化参数。两个提案 a 和 a' 语义等价（写作 a ≡sem a'）当且仅当它们指定相同的注册操作且规范化参数等价。

接口 I ∈ {MCP, CLI} 被分解为 I = (Φ_I, R_I, Ψ_I)，其中 R_I = (ρ_I, D_I)。Φ_I 是能力呈现，ρ_I 是响应协议，D_I 是接口特定解码器，Ψ_I 是反馈表示。给定模型可见输入 x_I^t = Φ_I(C_t, o_t, h_t)，模型采样 y_I^t ~ π_θ(· ∣ x_I^t)，解码器产生提案 â_I^t = D_I(y_I^t) ∈ A_{C_t}(s_t) ∪ {⊥}，其中 ⊥ 表示无法解码为注册语义动作的响应。

这个公式在算什么： 它把「接口」拆成三个可独立操作的组件，并定义了「解码失败」的形式化含义。这是后续匹配状态探针的数学基础。

公式 2：共享执行路径。

解码后的提案进入共享的语义验证 V、原生动作编译 K 和环境执行 E：

â_I^t → V,K → n_t → E → (s_{t+1}, ω_t)，z_I^t = Ψ_I(ω_t)

其中 n_t 是编译后的原生动作，ω_t 是执行结果，z_I^t 是接口特定的反馈表示。

这个公式在算什么： 它形式化地保证了「可执行能力匹配」——两个接口共享 V、K、E，只有 Φ、R、Ψ 不同。这是整个论文的对照实验设计的形式化表述。

公式 3：首个因果性分歧点。

定义交互签名 b_I^t = (â_I^t, f_I^t, ω_I^t, r_I^t)，包含语义提案、失败阶段、执行结果和恢复状态。b_I^t ≡ b_J^t 当且仅当语义提案等价且其余组件一致。首个因果性分歧点为：

t* = min{t ∣ b_MCP^t ≠ b_CLI^t}

没有这样的步骤的配对被记录为「无观察到的分歧」。

这个公式在算什么： 它定义了「轨迹从哪里开始真正分叉」的严格判据。在 t* 之前，两个轨迹的上下文对齐，支持匹配对比；在 t* 之后，各自的历史和状态分叉，后续差异表征下游传播。这是论文中「94.3% 的配对轨迹出现结构化分歧」这个统计量的定义基础。

公式 4：组件主效应。

在匹配状态探针中，令 ξ = (ξ_Φ, ξ_R, ξ_Ψ) ∈ {MCP, CLI}^3 表示分配给模型的呈现、实现和反馈形式。对于组件 k ∈ {Φ, R, Ψ}，令 ξ_{k←I} 表示把组件 k 替换为接口 I 的形式。组件主效应为：

Δ_k(d) = E_{ξ_{-k}} [ d(P_t^{ξ_{k←MCP}}, P_t^{ξ_{k←CLI}}) ]

其中 d 是注册的对比度量（如实现失败率差异），期望在其余组件的赋值上取平均。

这个公式在算什么： 它估计「在平均掉其他组件影响后，单独切换组件 k 从 CLI 到 MCP 会造成多大的行为变化」。这是论文中「实现组件产生最大局部偏移」这一结论的统计基础。

7. 实验设计

数据集： 三个交互式环境：ALFWorld（134 个任务，具身家务交互）、WebShop（100 个任务，目标导向的网页购物）、ScienceWorld（100 个任务，多步科学推理）。每个模型在三个环境上共产生 334 个任务（134+100+100=334），六个模型共 2,004 个配对 MCP-CLI episode。

模型： Qwen3-4B、Qwen3-8B、Qwen3-14B、Qwen3-32B、DeepSeek-v4-Flash、Gemini-2.5-Flash。前四个是本地 checkpoint，后两个是 API 绑定。

基线： Native 基准接口作为校准参考；CLI 和 MCP 是从共享语义契约渲染的对照条件。RQ4 中 Base 是协议匹配的普通策略，DART 是加入承诺保持控制器的干预条件。

指标： 主要指标是基准得分或成功率（ALFWorld 用任务成功率，WebShop 用原生奖励，ScienceWorld 用原生基准得分，后两者报告为 0-100 分）和每个任务的总计费模型 token 数。次要指标包括语义动作选择频率、失败阶段组成、恢复路径（重试接受率、后续任务成功率、重试 token 成本）、匹配状态探针的组件效应、首个因果性分歧点、分歧后轨迹行为。

消融： 匹配状态探针本身就是一种消融——它把接口分解为呈现、实现、反馈三个组件，通过 2×2×2 因子设计估计每个组件的主效应和交互效应。DART 的消融体现在触发结果分解：首次实现即接受、保持承诺修正后接受、释放回普通重试策略的比例，以及承诺、实现、修正各自的 token 消耗。

实验能否支撑结论： 实验设计在「语义匹配」这个核心控制上是扎实的——共享契约、共享验证、共享编译、共享执行，只变表示。匹配状态探针的因子设计也能有效定位组件敏感性。但有几个缺口：一是 DART 只在 Gemini-2.5-Flash 一个模型上评估，无法判断 DART 的收益是否跨模型泛化；二是匹配状态探针使用 T=0.6 采样而自然轨迹使用 T=0，两种温度下的行为分布可能不可直接比较；三是论文没有报告统计显著性检验的具体结果（如 p 值或效应量的置信区间是否排除零），只有 bootstrap 区间。

8. take-aways

• 接口表示在匹配能力下仍产生实质性端点差异。 例如 Qwen3-14B 在 ALFWorld 上 MCP 比 CLI 低 36.6 分（20.1 对 56.7），但在 WebShop 上 MCP 比 CLI 高 4.9 分（64.4 对 59.5）。方向和幅度都随模型-环境对变化。

• 实现组件是最大的局部敏感点。 在匹配状态探针中，实现组件的主效应在 ALFWorld/Qwen3-32B 上达到 84.4 个百分点的实现失败率差异，在 ScienceWorld/Qwen3-4B 上达到 72.9 个百分点。交互效应同样显著，如 WebShop/Qwen3-14B 的三向交互改变接纳率 37.8 个百分点。

• 轨迹分歧普遍且早期出现。 在 2,004 个配对轨迹中，1,889 个（94.3%）出现结构化分歧，首个分歧点出现在交互早期。语义动作差异是主导分歧类型，实现差异是反复出现的第二来源。

• DART 在所有六个评估设置中都提高了得分。 增益范围为 +0.8 到 +9.0 分（CLI/MCP 分别报告），且在 MCP 条件下同时降低了三个环境的 token 成本，降幅为 4.3k 到 27.1k token 每任务。

• DART 的触发干预高度集中在实现边界。 71-100% 的触发干预在首次实现时即被接纳，四个进入保持承诺修正机会的干预中有三个在单次修正后被接纳。

9. 最脆弱的假设

最脆弱的假设是：「语义动作契约」的规范化定义真正捕获了「可执行能力」的全部语义内容，因此 MCP 和 CLI 的差异可以纯粹归因于「表示」而非「能力」。

这个假设一旦倒塌，论文的核心归因就崩溃了。具体来说，如果 MCP 的结构化 JSON schema 和 CLI 的命令行语法在「信息内容」上并不完全等价——例如 JSON 的字段顺序、嵌套结构、类型标注可能传递了 CLI 的线性文本没有传递的语义线索，或者 CLI 的命令名和标志名在语言学上比 MCP 的工具名更透明——那么「匹配能力」就只是一个表面上的匹配，实际上两种接口暴露了不同的「信息可供性」。论文试图通过「共享语义契约」和「往返等价检查」来保证匹配，但往返等价只保证了「同一个语义动作可以被两种接口无损地编码和解码」，并没有保证「模型从两种接口中提取的信息是相同的」。

论文自己给出的证据：附录 C.2 的往返等价检查（公式 8 和 9）验证了「注册语义动作在渲染和解码后保持不变」，附录 C.3 给出了三个基准的具体映射。这些证据支持「可执行能力匹配」的技术层面，但没有直接测量「模型感知到的信息等价性」。匹配状态探针的交互效应（如三向交互改变接纳率 37.8 个百分点）实际上暗示组件之间不是简单加性的，这间接说明「表示」的各个维度在模型内部发生了复杂的交互，但论文没有进一步分析这种交互是否意味着「信息内容」的不等价。

10. 一周最小复现

目标： 复现论文最核心的结论——在匹配能力下，MCP 和 CLI 产生实质性端点差异，且实现组件是主要敏感点。

步骤：

1. 环境选择： 只做 ALFWorld，因为它有公开的、相对轻量的环境，且论文中 ALFWorld 的接口效应最大（Qwen3-14B 的 MCP-CLI 差异达 36.6 分）。

1. 模型选择： 用 Qwen3-8B 或 Qwen3-14B 的本地 checkpoint（24GB 显卡可以跑 8B 的 4-bit 量化版本，14B 需要更激进的量化或 offload）。如果显存不够，用 Qwen3-4B。

1. 契约构建： 从 ALFWorld 的当前可执行动作实例生成语义契约。MCP 渲染为 {"name": "alfworld__go", "arguments": {"destination": "desk 1"}}，CLI 渲染为 bench alfworld go --destination 'desk 1'。两者共享同一个验证器（检查操作名和参数是否在当前契约中）和同一个执行器（调用 ALFWorld 原生环境）。

1. 数据规模： 从 ALFWorld 的 134 个任务中随机抽 30-50 个任务（保持任务类型分布），每个任务在 MCP 和 CLI 条件下各跑 1 个 episode（温度 0）。如果时间允许，对每个任务跑 3 个 replicate 取平均。

1. 指标： 记录任务成功率、每个任务的总 token 数、失败阶段（解码失败、schema 失败、可用性失败、执行失败、生成失败、重试失败）。

1. 预期结果： 在 30-50 个任务上，MCP 和 CLI 的成功率差异应该达到 10-30 分的量级（具体取决于模型和任务抽样）。失败阶段组成应该显示 MCP 的解码失败率高于 CLI（因为 JSON 格式更容易出错），而 CLI 的引号处理失败率高于 MCP。总 token 数在 MCP 条件下应该更高（因为解码失败导致更多重试）。

1. 匹配状态探针（可选，如果时间允许）： 选 10 个固定的决策上下文，对每个上下文在 8 种组件组合下各采样 8 次（温度 0.6），估计实现组件的主效应。预期实现失败率差异在 30-80 个百分点之间。

关键风险： ALFWorld 环境的安装和契约构建需要处理大量边界情况（如对象名称的规范化、状态局部参数域的提取）。建议先用论文附录 C.3 的 ALFWorld 映射作为模板，只实现 go、move、take、open、close 五个最常用的操作，其余操作暂时跳过。

11. 反例设计

核心主张： 接口表示（MCP 对 CLI）在匹配可执行能力下会改变智能体的行为，且这种改变源于表示本身而非能力差异。

反例实验： 设计一个「表示盲化」测试。如果接口表示真的改变了行为，那么当模型无法区分 MCP 和 CLI 的表示差异时，行为差异应该消失。具体做法：

• 取论文中接口效应最大的设置（ALFWorld/Qwen3-14B，MCP 比 CLI 低 36.6 分）。
• 构造一个「混合表示」条件：在每一步，随机地把 MCP 和 CLI 的表面形式混合在一起，但保持语义契约和执行路径不变。例如，呈现用 MCP 的 JSON schema 格式，但实现要求用 CLI 的命令行语法；反馈用 CLI 的纯文本格式，但错误信息用 MCP 的结构化格式。
• 如果论文的核心主张成立，那么这种混合表示应该产生介于 MCP 和 CLI 之间的行为，因为模型仍然暴露在「某种表示」之下。
• 判据： 如果混合表示下的行为与 MCP 和 CLI 的行为在统计上不可区分（即混合表示没有产生任何新的行为模式，或者行为差异完全由「模型对特定格式的熟悉度」而非「表示本身」解释），那么论文的「表示是决策环境的一部分」这一主张就被削弱了。更强的反例判据：如果混合表示下的得分显著高于 MCP 和 CLI 两者中的任何一个，说明「表示差异」本身不是问题，而是「表示的不一致」或「模型对特定格式的过拟合」才是问题。

为什么这个实验能推翻核心主张： 论文的核心主张是「表示是决策环境的一部分」，暗示表示通过某种机制（如注意力分配、线索提取、表达难度）影响决策。如果混合表示没有产生可预测的行为变化，或者行为变化完全由「模型对格式的熟悉度」解释（即模型在训练数据中见过更多 JSON 或更多命令行），那么「表示」就不是一个独立的因果因素，而只是「训练数据分布」的代理变量。这会推翻论文的归因框架。

12. 落地判断

能否用于「抢占式 GPU 自托管 27B 模型做多智能体脚手架」： 可以，但需要谨慎。

怎么用： 如果你的多智能体脚手架中有一个「工具调用层」需要在 MCP 和 CLI 之间选择，这篇论文的建议是：不要只基于工程便利选择接口，而要把接口表示视为影响智能体行为的决策变量。具体来说：

• 如果你的 27B 模型在 JSON 格式的工具调用上频繁出现解码失败（如多余的顶层字段、参数嵌套错误），考虑用 DART 式的两阶段控制器：先让模型输出规范化的语义动作（schema_id 加 arguments），验证通过后再让模型把它表达成目标接口的表面形式。论文中 DART 在 MCP 条件下降低了 4.3k 到 27.1k token 每任务，这个节省在自托管场景下直接转化为更低的 GPU 占用时间。

• 如果你的任务涉及大量多词字符串参数（如文件名、路径、搜索查询），CLI 的引号处理可能成为主要失败源。论文中 WebShop 的 18''x18'' 案例表明，CLI 的 POSIX 引号规则对模型来说比 JSON 的转义规则更难处理。在这种情况下，MCP 的 JSON 表示可能更稳健。

成本量级： 以 27B 模型为例，如果使用 4-bit 量化，单张 24GB 显卡可以运行。DART 的额外成本是每次触发干预增加 2-3 次模型调用（语义选择、实现、可能的修正）。论文中 DART 的每次触发 token 使用在 4.0k 到 11.2k 之间（取决于环境和接口），其中承诺形成是最大组件。在自托管场景下，这意味着每次触发干预增加约 10-30 秒的 GPU 时间（假设 27B 模型在 24GB 显卡上的生成速度约为 20-40 token/秒）。如果触发频率不高（论文中 DART 只在可重试的、策略拥有的失败上触发），总成本增加是可控的。

最大的坑： 论文的 DART 评估只在 Gemini-2.5-Flash 一个模型上进行，而 Gemini-2.5-Flash 是一个 API 模型，其行为特征（尤其是对 JSON schema 的遵循能力）可能与自托管的 27B 模型差异很大。27B 模型在「语义选择」阶段可能无法稳定地输出规范化的 schema_id 加 arguments JSON，导致 DART 的承诺形成阶段频繁失败，从而退化为普通重试策略。在落地前，需要先在目标 27B 模型上验证「语义选择」阶段的解码成功率。如果这个成功率低于 80%，DART 的收益可能被承诺形成的额外 token 成本抵消。