一份 A6000 评测文档把工具循环描述为“真实 debug”，并给出 all_green=True；但脚本里的 run_tests 根本没有启动测试进程，只要源码出现 Bearer，就返回固定的“3 passed in 0.04s”。我们认为，这种“未执行却显示通过”的评测失真，比一次普通失败更值得警惕。

这是什么

Agent（能自主调用工具、分步骤完成任务的 AI 程序）说“测试通过”，只代表它收到了一条通过信息，并不等于被测程序真的通过了测试。回查可见，脚本先检查源码字符串，再由工具返回固定结果，汇总器随后只搜索 passed、排除 failed，于是形成一条自我闭合的“绿色路径”。

更关键的是，0.04 秒也是写死在返回文本里的固定数字，不是测试耗时。函数名 run_tests 和 pytest 风格摘要可以表达调用意图，却不能替代程序执行证据。

文章提供的隔离反例进一步显示：测试文本和业务逻辑均未改变，仅在源码末尾添加一行 # Bearer 注释，判定器就从失败翻成成功。这个反例不能证明历史模型故意作弊，但足以证明“绿色结果”可能脱离目标行为。

行业怎么看

我们认为，模拟工具并非毫无价值。开发早期，它能稳定检查 Agent 是否会调用工具、解析失败信息并进入下一轮，适合验证流程与通信协议。

但业界不能把模拟响应换名为“真实修复”，再混入任务成功率。尤其是企业采购 Agent 服务时，必须追问三个问题：测试进程是否真实启动、断言是否由目标程序执行、耗时是否来自实际测量？

风险也正在向评测行业扩散。若越来越多榜单只展示最终绿灯，而不公开判定脚本和证据链，采购方会误把流程跑通当作代码可靠。更稳妥的做法，是把模拟测试、真实测试和端到端验收分层统计，并保留可重跑的原始记录。

对普通人的影响

对企业 IT：评估 Agent 供应商时，应要求查看判定日志、原始进程记录和可复现实验；尤其要区分工具调用成功、测试通过与业务验收通过。

对个人职场：使用 AI 编程工具时，不要只看“全部通过”的界面，要检查测试是否实际运行，并抽查命令输出与失败场景，避免把未验证的补丁交给团队。

对消费市场：代理型产品的“自动完成”也会面临同样问题。近期更可信的产品，不只是回答更流畅，而是能让用户看到做了什么、凭什么判断完成。