工具调用是否按预期执行？测量和修复LLM智能体中的意图执行对应关系

智能体构建于大语言模型 (LLM) 之上，通过工具调用构建和运行软件。呼叫通过多个跃点到达其程序，任何跃点都可以更改呼叫，恕不另行通知。当更改的呼叫失败时，智能体会重试正确的呼叫，这会花费用户的时间和金钱。基准测试和故障分析看不到变化，因为它们读取了调用及其结果，但没有读取跃点收到的内容。我们将意图执行对应（IEC）定义为执行的操作与工具合约下发出的调用表示的操作相匹配的属性。我们的协议观察每个跃点在不执行调用的情况下接收到的内容，并命名由接收者自己的解析器更改它的第一个跃点。然后，IntAct 以该跃点无法更改的形式传递呼叫，或者拒绝呼叫。我们根据实际使用中观察到的变化构建了 IEC-Bench，并在 4 个广泛使用的Harness的执行路径下建立了依赖调用链。在生产会话中的 47,828 个 shell 调用中，Claude Code 的 Bash 工具更改了 12.0% 的带有代码、转义序列或长文本的调用。对于 80.7% 的反斜杠已更改的调用，会运行错误的操作，而不会报告任何错误。所有10个测量的Harness都改变了呼叫。基于轨迹的判断将 95.1% 的生产故障归因于LLM，尽管其中一半以上是路径造成的。在 IEC-Bench 上，该路径将每个通过任务的token成本提高了 2.4 倍（最高 12.3 倍）。更改呼叫的一跳也会隐藏其后的更改，因此一条路径上 55.1% 的故障仅在其第一跳修复后才会出现。 IntAct 部署在商业产品中，通过更改调用可以恢复 79.2% 的故障。因此，Harness应逐跳设计和测试，以确保正确的呼叫按预期执行或被拒绝。