RECEIPT：衡量与修复 LLM 智能体在 Web 服务运维中的返回假设

LLM 智能体通过命令行操作 Web 基础设施，并依赖于一项返回假设，即每次工具调用都会在有限时间内返回，且其请求的操作已完成。然而，许多命令在执行操作前会先提出问题，而智能体的执行框架要么关闭程序的输入，要么将其作为无人键入的终端保持开启。输入关闭时，程序可能在未执行请求操作的情况下返回状态码 0。输入开启时，程序则会等待直至达到时限，使智能体付出时间和词元开销。据我们所知，本文首次对返回假设进行衡量与修复。我们收集了 91,469 次生产环境工具调用和 89,047 条公开的智能体轨迹，测试了 8 种广泛使用的执行框架如何启动命令，并构建了 Litmus 和 Tripwire：前者是包含 158 个经核验的命令行调用的目录，后者是包含 25 对任务的基准测试，每对任务的唯一区别在于执行请求的操作前是否需要回答问题。随后，我们提出 RECEIPT，它保持输入开启，通过系统调用读取每个进程正在等待的内容，并通过经过模型检验的协议将此状态返回给未经修改的智能体。在 Litmus 上，关闭输入会导致 11.5% 的受测调用在未执行请求操作的情况下返回状态码 0；而在未连接终端时，8 种执行框架中有 7 种会关闭输入。在普通终端中，一个无人回答的问题会使任务的词元用量增至 2.9 倍，而输入连接方式能使某个 LLM 在 8 个模型中的排名从第 7 位升至第 3 位。在 5 个 LLM 上，RECEIPT 将虚假成功声明减少了 73.5%，并在另一种执行框架上完成了全部 25 个需先回答问题的任务。因此，智能体的可靠性不仅取决于其 LLM，也取决于执行框架允许它观察到什么。智能体开发者应报告每次工具调用实际执行了什么，而不只是它如何结束；基准测试维护者则应在对 LLM 排名之前，固定并报告输入连接方式。