论文揭示 LLM Agent 工具调用在执行路径中被改写，并提出 IntAct 修复方案

工具调用在经过执行路径的多跳传递时容易被无感篡改，导致执行动作偏离智能体意图，而现有基准与归因方法将此类路径故障误归咎于大模型。

• 执行路径引发意图执行偏离：智能体通过工具调用构建与运行软件，命令从框架出发，需经历参数序列化、宿主包装器、Shell解析、进程接口与目标解析器等多个跃点（Hop）。任一跃点均可能在未报错的情况下篡改调用文本或参数结构，导致受害系统执行非预期动作。
• 现有基准与归因方法的盲区：主流基准仅评估发出的调用或最终系统状态，默认命令均按原样执行；轨迹级归因方法仅审查调用文本和返回结果，无法观测各跃点实际接收的内容，从而将执行路径引入的失败误判为大模型的生成缺陷。
• 核心观察与级联遮蔽效应：作者发现，发生篡改的跃点会遮蔽其后续跃点的改动，部分路径故障在修复首个篡改跃点前完全不可见；此外，静默篡改导致模型执行错误操作，而带有误导性报错的显式失败则诱导模型篡改其本就正确的初始意图。
• 提出的协议与修复方案：论文定义了意图-执行对应性（IEC），提出无需实际执行即可逐跳捕获传输内容并由接收端解析器判定偏离的 IEC 协议，构建了评测基准 IEC-Bench，并提出了在特定跃点通过未解析通道安全传递调用的修复框架 IntAct。

现有研究主要围绕智能体轨迹层面的失败归因、自纠错重试以及针对特定单一跃点的拦截防御展开，未对命令执行路径的多跳过程建立无执行观测体系。

• 智能体评测与轨迹级归因研究：Who&When（Zhang et al., 2025）利用大模型裁判分析失败轨迹日志，判定责任智能体与步骤；Causal Agent Replay（Shah, 2026）通过在特定步骤反事实重放以定位责任步骤；Gupta et al.（2026）向智能体返回结构化执行反馈。作者指出，此类方法仅分析调用文本与返回结果，无法观察跃点间实际收到的载荷，导致裁判在路径故障上的归因一致性极低。
• 自纠错与环境扰动测试：Reflexion（Shinn et al., 2023）依赖环境反馈促使智能体反思并重试；ToolBench-X（Tian et al., 2026）向智能体注入显式的工具环境风险。作者指出，当执行路径产生误导性错误反馈时，单纯增加重试轮数无法修复路径层面的底层缺陷，反而成倍增加开销。
• 命令执行路径与安全防御研究：QuoteBench（Li et al., 2026）在56项任务上使用单参考路径（临时文件）记录包装器单跳表现；BatBadBut揭示了Windows批处理参数传递问题；Su and Wassermann（2006）、AgentSpec（Wang et al., 2026）及CARE（Zhang et al., 2026）等侧重注入检测与执行前校验。作者指出，此类安全分析主要关注调用是否允许执行，而非程序是否完整接收原始意图；QuoteBench仅覆盖单跳，无法检测进程接口等后续跃点的篡改。
• 基线方法与基准数据集：归因对比基线包括Who&When的3种大模型裁判（all-at-once、step-by-step、binary search）、Causal Agent Replay以及QuoteBench的fixed-reply replay；修复对比基线涵盖QuoteBench的临时文件与显式边界契约、Gupta et al.的结构化执行反馈、以及Reflexion自纠错；评估基准涵盖IEC-Bench、Terminal-Bench 2、Toolathlon、ToolHop、CLI-1M以及真实企业生产会话语料。
• 与本文工作的定位差异：作者称，本文区别于以往单跳或轨迹级工作，首次在不执行调用的前提下利用接收端官方解析器跨多跳度量意图-执行对应性，并揭示了多跳间的错误遮蔽特性。

论文提出 IEC 协议与 IntAct 框架，分别实现无需执行的跨跳偏离定位与针对特定跃点的通道渲染修复。

问题设定与形式化

• 意图-执行对应性（IEC）：将智能体在工具契约下发出的调用文本所指代的语义定义为预期动作 a。对包含 m 个跃点的执行路径 Pi = <b_1, ..., b_m>，每个跃点经历一侧序列化与接收侧解析，接收端解析出的动作记为 r_i。当且仅当所有跃点满足 r_i = a 时，称该路径满足对应性。
• 首个偏离跳定义：首个接收到与预期不同动作的跃点被定义为首个偏离跳（First Divergence）：

FD(a, Π) = min{i ∣ r_i ≠ a} 公式表示路径中第一个破坏意图-执行对应性的跃点序号。偏离分为静默偏离（返回结果无报错）与显式偏离（返回解析或引号错误）。

• 四种篡改机制：作者归纳了跃点破坏调用的四种机制：引号二次解析消耗（quote consumption）、交互环境字面量二次展开（re-expansion）、运行环境导致的文本截断（truncation，如MSYS2环境截断与cmd.exe换行截断）、以及参数拆分或丢弃（arity change）。

见证机制：无需执行观测跃点

• 无害化替换探针：直接重新执行历史调用存在副作用且不可重复，见证机制（Witness）保留框架的启动配置，仅将实际执行命令的程序替换为捕获并报告所接收文本的探针。
• 环境与进程拦截：针对Bash，利用 BASH_ENV 环境变量在命令字符串执行前加载见证脚本；针对PowerShell追加启动，基于 powershell.exe 命令行规则计算解析脚本；在进程接口处，使用参数探针（argv probe）拦截原生程序接收的参数向量，并由 argv sentry 记录祖先进程以识别包装器结构；对结构化工具则记录工具函数实际绑定的参数值。

接收端解析与归因判定

• 自身解析器仲裁：不依赖字符串字面比对或LLM主观判定，而是直接调用跃点接收端的官方解析器解析语法结构（比较Bash的运算符、词法单元与heredoc，PowerShell的语法分析树，以及原生程序的参数向量），从而消除等价语法的误报。
• 显式故障归因流程：在禁用执行的前提下，首先由目标解释器解析智能体发出的原始文本，未通过语法解析则归因为大模型生成错误；若文本合法但见证探针捕获到的输入产生差异，或报错行号超出原始文本范围（源自包装器追加逻辑），则归因为路径错误；若文本完整传入但调用了深层解释器引发失败，则归因为嵌套跃点错误。

IntAct：指定跃点的通道渲染与安全拒绝

• 通道渲染机制：跃点篡改调用的根源在于对其文本进行了解析。IntAct将调用封装为该跃点不进行解析的物理通道（如source独立脚本文件、标准输入、Base64编码参数等），使跃点无法更改内容。
• 原生参数渲染规则：针对PowerShell 5.1向原生程序传递常数参数时的解析缺陷，IntAct对每个参数 s 实施专用转义渲染：

native(s) = \begin{cases} "" & s = \varepsilon \\ " esc(s) \beta(s) " & s \text{ 包含空白字符} \\ esc(s) & \text{其他} \end{cases} 公式中 esc 对双引号转义并成倍增加前导反斜杠，\beta(s) 则重复末尾的反斜杠以确保闭合引号保持定界符语义，交由C运行时解析恢复为原始参数 s。

• 多跳复合与安全拒绝：当路径包含多个篡改跃点时（如PowerShell追加启动同时存在包装器和进程接口问题），IntAct按逆序复合渲染（先完成进程接口渲染，再编码为-EncodedCommand参数交付包装器）。若调用文本超出目标通道的承载域（例如cmd.exe无法接收多行文本），IntAct在启动前直接拒绝执行并返回指明故障跃点的错误提示，杜绝未察觉的静默偏离。

实验涵盖真实生产会话回放、IEC-Bench 基准评测、故障注入与消融分析，证实所有被测框架均存在跃点篡改问题，而跳级修复能够挽回执行损失。

实验设置

• 被测模型：IEC-Bench主评测涵盖 qwen3-coder-plus（API）、Qwen2.5-Coder-32B、Qwen2.5-72B、Hermes-3-Llama-3.1-70B（Hermes-3，vLLM部署）；归因基线使用 Qwen2.5-72B 与 qwen3-coder-plus；修复恢复任务额外涵盖4家厂商的15个LLM。
• 数据集与语料：涵盖Windows企业生产语料（47,828个Shell调用，11,982个暴露调用）、Linux生产语料（71个会话）、IEC-Bench（67个模式对、10个多行程序、135个ToolHop链、46个Terminal-Bench 2任务）、Toolathlon、CLI-1M及203,710条公开轨迹。
• 执行框架与路径：涵盖10个框架（Claude Code、Codex、Qwen Code、OpenCode、DeepSeek Harness、Gemini CLI、Aider、OpenHands、SWE-ReX、Terminus-2）及18个MCP服务器，评测包含6种传输路径。
• 评测指标：changed-call rate（变更调用率）、静默变更比例、Pass@k（pass@1与pass@10）、每通过任务Token开销（Tokens per passed item）、成本比（cost ratio）、恢复率（Recovered pairs）、归因一致性Cohen's kappa、误确认率。
• 评审与真实标签：采用无执行见证者结合接收端解析器评判偏离；任务状态由不经Shell计算的预期状态Oracle比对；归因由2名标注人员依据规范双盲标注（kappa分别为0.79与0.89），不一致处以执行证据裁决。
• 重复设置：IEC-Bench主实验在 temperature=0 下单次评估（pass@1）；Reflexion与IntAct对比实验在10次试验下评估（pass@10）；恢复任务在 temperature=0.6 下每模型重复3次。

主结果

下表呈现3个LLM（Qwen2.5-Coder-32B、Qwen2.5-72B、Hermes-3）在不同启动路径与干预方法下的通过任务总数（据 Table 7）：

表格较宽，可左右滑动

• 启动路径拉低任务通过表现：作者指出，在包含调用变更的PowerShell追加启动下，3个LLM在未修复时的任务对通过数仅为26项，工具链通过数仅为9项；经IntAct单次修复后分别提升至127项与74项。
• IntAct在相同试验预算下优于自纠错基线：作者指出，在10次试验预算下，IntAct在所有Windows启动上的通过项数均高于Reflexion（例如追加启动的任务对达到181项，而Reflexion为50项），作者认为路径破坏无法单纯依赖智能体内在重试解决。
• 模型排名受执行路径扭曲并在修复后恢复：作者指出，在追加启动与单参数启动下，模型间原有的性能顺位发生倒挂，而在IntAct修复对应跃点后，模型的相对排序恢复到控制基准的水平。

真实生产会话与跨框架调用变更测量（RQ-1）

• 测试内容：在Windows与Linux生产语料、公共轨迹及16个MCP服务器上，通过见证机制测量工具调用在各跃点被篡改的频率与机制。
• 实验结果：在11,982个暴露的Windows调用中，1,199个发生变更（changed-call rate为10.0%，Table 2）；Claude Code的Bash工具在携带代码或长文本时变更率为12.0%（7,491个中有902个在宿主包装器被篡改）；反斜杠对被合并的663个调用中，535个在未报告任何错误的情况下静默执行错误动作（80.7%静默，Figure 3b）；10种被测框架和10个MCP服务器均出现调用变更。
• 作者解读：作者认为调用变更源自启动路径而非平台或模型本身，框架必须逐跳进行工程测试。

失败归因有效性与重放对比（RQ-3）

• 测试内容：在102个生产失败样本与115个文本对上，将IEC协议与Who&When的大模型裁判、QuoteBench的fixed-reply replay及消融变体进行对比。
• 实验结果：IEC协议在102个失败归因中与人工标注的一致性达 Cohen's kappa 0.77（正确识别54个路径失败，误判1个，Table 5）；Who&When裁判的kappa最高仅为0.04，且all-at-once裁判将97个失败直接归咎于模型；QuoteBench单参考路径仅检测出37.2%的路径损失（检测出包装器全部20个，进程接口48个检测出0个，Table 6）。
• 作者解读：作者指出轨迹记录未包含跃点实际接收的数据，轨迹级裁判因而产生系统性误归因；仅绕过单一跃点的参考路径无法检测其他跃点的损失。

固定动作回放下的损失恢复与消融（RQ-4）

• 测试内容：固定智能体发出的动作不变，在IEC-Bench上重放360个复现失败的任务对，评估IntAct在定名跃点修复后的恢复表现。
• 实验结果：发生调用变更的173个失败任务对中，IntAct恢复了137个（恢复率79.2%，Table 1）；未发生变更的187个失败任务对无一被恢复（Fisher精确检验 p < .001）；在追加启动中，仅修复进程接口恢复0个，仅修复包装器恢复31个，两跳均修复恢复69个（Figure 5a）。
• 作者解读：作者认为早期跃点会遮蔽后续跃点的篡改，复合路径必须按路径顺序修复每个被定名的跃点。

其他消融与分析

• 故障注入定位（168次注入）：30次发生接收变更的故障全部被首偏离跳准确定位（Figure 5b）。
• 文本变异检测（297个变体）：Bash执行产生差异的262个变体全部被语法比对检测出。
• 显式边界契约消融：Qwen2.5-Coder-32B在15个正则任务中因改用&&连接全部失败，通过数从50降至36。
• 证据回传消融：在工具结果中回传发送与接收文本后，Qwen2.5链路通过数无显著变化（p >= .500）。
• 单任务通过Token消耗：原始启动下通过任务的Token消耗为IntAct的2.4倍，追加启动链路上达到12.3倍。
• 智能体误确认率：在949次危险变体与多行程序失败运行中，智能体将665次误报为完成（70.1%）。

在固定动作回放下，发生调用变更的失败任务对中有36个未被IntAct恢复（Table 1相关讨论），其中22个失败于未发生篡改的动作，12个因收到误导性反馈而在重试中放弃，2个使用了超出渲染通道承载域的语法结构。

作者指出的后续方向主要集中在扩展终端键入测量与兼顾框架权限系统，而当前实验的覆盖范围受限于具备解析器的跃点类型与特定评测环境。

作者指出的局限与后续方向

• 交互式终端键入测量扩展（Section 8）：作者计划将测量扩展到直接向终端键入命令的执行框架中。
• 新启动方式适配（Section 8）：作者计划将测量扩展到本项研究完成之后出现的全新启动方式。
• 权限判定规则保持（Section 8）：作者指出，重写调用的修复机制必须保证框架的权限许可规则依然基于原始调用进行判定，正如其所发布的mod所实现的那样。
• 通道承载域限制与拒绝（Section 2.4）：作者指出，IntAct的渲染依赖物理通道的有效承载域，对于如cmd.exe遇到换行即终止这类无对应安全通道的调用，只能执行显式拒绝而无法传递。

实验覆盖范围

• 接收端解析器依赖：IEC协议仅覆盖了接收端具备语法解析器的跃点类型（如Bash、PowerShell及程序参数列表），未覆盖无解析器的非结构化接收端。
• 被测框架与平台环境：实验评估了10个编程智能体框架与18个MCP服务器，主要操作系统环境为Windows 11（配Git Bash与PowerShell 5.1）与部分Linux发行版。
• 基准评测模型数量：IEC-Bench全量基准测试覆盖了4个主测大语言模型（qwen3-coder-plus、Qwen2.5-Coder-32B、Qwen2.5-72B、Hermes-3-Llama-3.1-70B）。
• 生产语料采集范围：真实会话语料来源于单一企业的6名开发者在11周内产生的Windows调用（47,828个）及9名开发者的Linux调用，补充了2名外部开发者的留出数据。
• 超参数与步数预算：IEC-Bench评测中任务对限制为最多10步（单命令120秒），工具链限制为最多15步（60秒），主实验温度固定为0，论文未报告其他采样温度下的泛化表现。

• 研究定位：针对大语言模型智能体工具调用在底层执行路径中的保真度问题，论文界定了意图-执行对应性概念，提出了无执行偏离检测协议 IEC 与跳级修复框架 IntAct。
• 核心问题：命令在宿主包装器、Shell解析、进程接口等多跳传输中常遭隐蔽篡改，现有评测默认调用按原样执行，导致大量路径缺陷被系统性误归因于大语言模型。
• 方法设计：IEC协议利用无害见证探针与接收端自身解析器，在不执行命令的前提下定位首偏离跳；IntAct根据定名跃点采用无解析通道（如文件注入、参数转义、Base64编码）进行针对性渲染交付，或对超域调用予以安全拒绝。
• 关键实验结果：
  1. 生产会话中10.0%的暴露Shell调用被路径篡改，Claude Code的Bash工具在传输长文本或代码时篡改率达12.0%，且80.7%的反斜杠合并故障未报任何错误（Figure 3a、Figure 3b）。
  2. 传统轨迹评测将95.1%的生产失败误判为模型责任，而IEC协议与人工归因的一致性达到 Cohen's kappa 0.77（Table 5）。
  3. 在固定动作回放下，IntAct恢复了IEC-Bench中79.2%发生调用变更的失败任务（Table 1）；带智能体闭环测试中，将通过任务的平均Token消耗降低2.4倍（Table 7）。
• 作者结论与启示：作者认为工具调用能否正确执行主要取决于启动路径而非大模型本身，智能体框架必须按跃点顺序开展逐跳工程测试，同时基准评测应固定并报告启动路径以保证模型评分的公平性。