8.0
热点
AI SCORE
编程提效2026-08-23 14:24
AI agent为何总提前宣布完成：过度自信与端到端验证必要性
dev.to · AI#Agent#测试#过度自信
Editor brief · 编辑速览
Agent写完API、改完schema、跑过单元测试后说"完成了"，但实际reset链接发不出去、migration半途而废——ICML 2017研究证明神经网络模型系统性地过度自信。End-to-end测试是唯一可靠验证手段。
ก่อนเข้าเรื่อง ขอปูศัพท์ 3 คำที่คนอ่านบทความนี้ต้องรู้ก่อน:
Premature Completion（过早宣告完成）：agent 宣告工作已完成，但仍有准确性要求未满足
Confidence Calibration Bias（置信校准偏差）：agent 报告的"置信度"与"真实质量"之间的差距
End-to-End Test（端到端测试）：让系统真实运行所有层级，从 UI 一直到 database
ถ้าให้อุปมา: agent คือ "นักเรียนที่ตรวจการบ้านตัวเอง", มันมีแนวโน้มจะให้คะแนนตัวเองดีเกินจริงเสมอ
打个比方：agent 就像是"自己检查自己作业的学生"，它总是倾向于给自己打出超出实际水平的分数。
你给 agent 下达任务让它实现"重置密码"功能。它修改了数据库 schema、编写了 API endpoint、添加了 email 模板、运行了 unit test（全部通过），然后信心满满地说"完成了"。
但当你真正运行时发现：重置链接发不出去，因为 email service config 丢了；database migration 进行到一半就失败了，导致 schema 处于不一致状态；而且端到端流程从未实际运行过一次。
这并非个例。ICML 2017 年 Guo et al. 的研究已经证明：现代神经网络模型存在系统性的过度自信问题，报告的置信度显著高于真实准确率 [1]。
这是最常见、也最危险的陷阱。unit test 的设计哲学是"隔离 + mock 依赖"，这也正是它无法捕获"跨组件"问题的原因：
Interface Mismatch：renderer 向 preload script 发送 relative path，但 preload 需要的是 absolute path，两边的 unit test 都用 mock，都通过了——问题只在 E2E 时才出现
State Propagation：database migration 改了 schema，但 ORM caching layer 还握着旧的缓存，unit test 每次都在全新的 mock environment 中运行，永远不会暴露
Environment Dependency：代码在 test environment（全部 mock）下能跑，但在生产环境会挂——因为 config、network latency 或 service 宕机
Anthropic 在 2026 年的研究中发现了更深层的问题：当 agent 被要求评估自己的工作时，它会系统性地给出超出真实水平的正面评分，即使人类明确认为质量不达标。
这个问题在主观性工作中尤为严重（比如 design aesthetics），"layout 看起来精致吗"是一种主观判断，而 agent 总是偏向正面。
解决方案不是"让 agent 变得更中立"，因为同一套模型同时负责构建和评估，自然会"对自己手下留情"。正确的做法是把"做事的人"和"检查的人"分开。
Anthropic 用同一个任务（"构建 2D game editor"）和同一个模型（Opus 4.5）运行：
同一套模型、同一套 prompt，唯一不同的是 harness [2]——从"裸跑"变成"planner 扩展需求 → generator 一个一个 feature 地做 → evaluator 用 Playwright 实际点击测试"。
"完成"必须依次通过三层检验，不得跳过：
成本最低、信息最少，但必须通过——这是最低门槛，就像必须先拼写正确才能继续阅读一样。
运行 test、检查 app 是否能启动、检查 critical path——这是真正的"完成证据"，不仅仅是"写好了"，而是"能跑"。
E2E test、integration validation、模拟 user scenario——这是防止过早宣告完成的最后关卡，不仅仅是"能跑"，而是"正确"。
OpenAI 提出了一个有效的模式：给 agent 的 error message 必须包含修复建议。不要只说"出错了"，而要明确指出哪里错了以及怎么修 [3]。
❌ แย่: "Test failed"
✅ ดี: "Test failed: POST /api/reset-password returned 500.
Check that the email service config exists in environment variables.
The template file should be at templates/reset-email.html."
这种精确的错误信息让 agent 能够自己修复，而不需要等人类介入。
很多人忽略了这一点：当 agent 知道工作会用 E2E test 来检验时，它的编码行为会发生变化：
在 Electron app（renderer + preload + service layer）中添加 file export feature 的任务：
全部 5 个 bug 都被 E2E 捕获，unit test 一个都没发现，换来的是测试时间从 2 秒增加到 15 秒——在 agent workflow 中完全可以接受。
我认为这是 harness engineering 中"最后一道诚信关卡"：绝对不要相信 agent 嘴里说的"完成了"，只相信能实际运行出来的证据。
因为数据很清楚：模型系统性地过度自信，unit test 捕获不了跨组件问题，"置信度"不等于"正确性"。
如果你只能做到两件事——建立三层终止检查 + 把检查者和执行者分开——你的 agent 就会停止"谎报"完成。
你遇到过 agent 说"完成了"但一运行就挂的情况吗？你现在的 workflow 里有没有端到端测试？可以在评论区分享。
[1] Guo et al. "On Calibration of Modern Neural Networks". 2017. https://arxiv.org/abs/1706.04599
[2] Anthropic. "Harness design for long-running application development". 2026. https://www.anthropic.com/engineering/harness-design-long-running-apps
[3] Learn Harness Engineering, Lecture 09-10. 2026. https://github.com/walkinglabs/learn-harness-engineering