我想记录的不是内心独白
如果 Agent 修改了一个文件，记录“我已经思考并完成修复”没有什么用。更有用的是：原始目标、允许写入的文件、实际 diff、测试命令与返回结果，以及哪些行为还未验证。证据应尽量来自外部状态，而不是模型自己的宣称。
这里的账本不是要求暴露全部内部推理。它更像一份施工记录：谁动了哪块，依据是什么，出了问题可以从哪里退回。对浏览器操作也一样，点击按钮和服务器接受提交之间应留一个明确的核验步骤。
下一步想测什么
同一个任务给 Agent 多次执行，只看平均成功率会掩盖偶发的严重误操作。我会另记重复写入、误删、假阳性完成报告、人工接手耗时。工具超时和网页结构变化应被当作正常测试条件，而不是从展示录像里剪掉。
这只是评估框架草稿，还没有公开实验结果。等真的积累失败样本，再决定哪些错误值得通过模型、工具设计或权限边界分别解决。
先从一个小任务开始
假设 Agent 被要求给 README 增加一段安装说明。它需要确认项目真实使用的包管理器、修改目标文件、运行至少一项相关检查，再指出仍需人工确认的步骤。若最终回答说“已经部署成功”，而它其实只改了文档，这份账本应该立刻暴露出结论和证据不匹配。
另一个反例是重试：网络工具第一次超时，第二次返回成功，但第一次请求其实已经在服务端生效。没有请求标识和状态复核，Agent 可能把同一操作做两遍。对会写入外部系统的工具，防重复比“继续执行”更优先。