“调用成功”和“任务完成”之间有一道缝

一个查天气的工具返回 200，Agent 随后把北京的温度写进上海行程；从接口日志看每一步都成功，从用户角度看任务失败。工具调用次数、思考字数和演示视频的流畅度，都不能自动证明目标达成。评价一个 Agent，我首先想知道它是否把观察结果和原来的问题对上了。

ReAct 的价值在于让推理与行动交替：动作取得新观察，观察再改变后续判断。但实际系统里还要补上“验证”这一环。模型说文件已修改，不等于磁盘上的文件正确；说网页已提交，不等于服务端接受；说引用来自资料，不等于资料真的支持那句话。

把每一步写成可以复盘的账本

我想用一个很朴素的记录格式：此步目标是什么、允许改动的范围是什么、采取了什么动作、看到了什么证据、还有什么没验证。它不像完整思维链那样试图记录所有“想法”，而是记录外部可核对的状态变化。这样出了错，才能定位是检索错、理解错、操作错，还是把未完成误报成完成。

例如修复一个仓库问题，最后至少要能指出修改文件、测试结果和仍未覆盖的边界。SWE-bench 把真实 issue 与代码仓库放在一起，正好说明“写出一段貌似合理的补丁”离“解决问题”还有距离。AgentBench 的交互环境则提醒我们：任务经常不是一道静态问答题。

失败样本比漂亮轨迹更值得读

Agent 很容易在前几步看起来聪明，后来逐渐偏题。一次错误检索被当作事实，下一轮计划就会建立在这个事实之上；中途工具超时若没有被识别，系统可能继续执行；失败后自动重试又可能造成重复写入。这里需要的不只是更强模型，还包括幂等动作、状态检查、停止条件和必要时交还给人的权限边界。

我更愿意做小而具体的评估：同一组任务反复跑，记录成功率之外的误操作次数、恢复成本和最终核查耗时。对个人项目来说，这比追一个总榜分数更能指导设计。本文谈的是一种评估视角，不声称我已经搭建过上述基准系统。

暂时的判断

Agent 的“自主”不应该理解成没人看得懂它做了什么。越能行动，越需要清晰的边界与证据：哪些步骤可以自动完成，哪些必须等待用户确认，哪些结果需要独立验证。真正可靠的体验，也许不是一步到位的魔术，而是出错时仍可解释、可停下、可接手。