命令行智能体常把“没做”报成成功：Receipt 读取内核等待状态，把假成功从34次降到9次
核心概要
大语言模型智能体通过命令行操作 Web 服务时，默认每次工具调用都会在限定时间内返回且动作已完成；但许多命令会先提问，执行框架关闭输入时程序可能以状态0返回却没做请求的动作，保持输入打开时程序又会一直等到超时。Receipt 保持输入打开，从系统调用读出每个进程在等什么，并把这一状态交回未改动的智能体；在5个模型上，它把假成功从关闭输入时的34次降到9次，比普通终端少用24.4%的 token。
深度剖析
智能体的可靠性不只取决于大语言模型，也取决于执行框架让它看到什么：命令在无人应答时是否真的完成了请求的动作，此前并不在工具返回里体现。 此前基准只按最终状态打分，不记录进程在等什么；关闭输入时程序读到文件结束符便采用默认值，跳过动作也能返回状态0。 在158条会提问的命令行调用中，关闭输入使11.5%的调用以状态0返回而未执行请求的动作，8个执行框架中有7个在没有终端时关闭输入。
Receipt 不替智能体做决定，只把内核暴露的进程状态交回给它，让智能体自己判断命令是否还在等一个回答。 此前的检测器读输出文本或沉默，提示词模式会漏掉从未出现在输出里的提问，不活动看门狗则会终止仍在计算的命令。 在120条本地可运行、在终端下会等待的 Litmus 调用上，Receipt 报告了85.0%的等待且无误报，中位报告延迟1.1秒；在 mini-SWE-agent 中接入后，5个模型合计成功数从153升到176，假成功从34降到9。
在保留持久终端的执行框架里，输入、中断与报告的先后顺序需要被固定下来，否则智能体排队的下一次按键会被当成提问的答案。 原生 Terminus 2 在智能体选定的延迟后返回，下一次已排定的按键就成了回答；在迁移任务中它把排队的 cd 命令喂给脚本的提问并重建了数据库。 接入 Receipt 后，Terminus 2 完成全部25个陷阱任务且无假成功，原生版本完成17个，仅返回单行中断提示的消融版本完成20个。
启示与展望
已展示的范围是158条会提问的命令行调用、91,469次生产工具调用与89,047条公开轨迹上的测量，以及 mini-SWE-agent 前15对、Terminus 2 全部25对 Tripwire 任务上的修复效果；读者对象是构建和评测命令行智能体的工程师。检测器已作为可选功能进入商业智能体运行时，在 Windows 上每次调用检查中位耗时0.11毫秒、Linux 上0.54毫秒。
作者指出结论未必适用于其他执行框架和模型，因此测量覆盖23个执行框架与19个模型的公开轨迹，并在两种终端设计上运行 Tripwire；与检测器一同编写的基准可能偏向 Receipt，所以最后10对任务在检测器冻结后才写出。在终端下 Receipt 未报告的18次等待中，15次在它的启动方式下会退出或不再等待，3次是绘制进度指示的 npm 命令。