摘要：大多数人搭自主编码 Agent 时只盯着模型、工具和循环，却忽略了最关键的 evaluator。没有外部评估器，Agent 的“完成”只是自我报告；它会提前停止、走捷径、高估结果，然后自信地告诉你任务已经完成。
大多数人搭 Agent 的时候，只关注一件事：让 Agent 更聪明、更快、更会写代码。
于是大家不断换模型、加工具、塞上下文、做多 Agent 协作、优化 prompt、接 MCP、接浏览器、接数据库、接终端。看起来系统越来越强，循环越来越长，产物越来越多。
但有一个关键组件经常被跳过：评估器（Evaluator）。
这恰恰是自主编码 Agent 最致命的缺口。
因为 Agent 自己无法可靠判断“这次真的做对了吗”。它可以生成计划，可以修改代码，可以解释为什么自己认为工作完成了，也可以写出一段非常自信的总结。但这些都不是证据，只是自我报告。
没有外部评估器，所谓 loop 不是闭环，而是空转：模型生成、模型解释、模型宣布完成。整个系统看起来在迭代，实际上缺少一个能把产物和目标相比较的判定机制。
Agent 的基本架构不是“模型 + 工具”
很多人会把 Agent 简化成“LLM + tools”。这个说法太粗。
对自主编码 Agent 来说，更有用的拆法是四个元素：
- Goal：目标是什么，成功标准是什么；
- Loop：Agent 如何计划、执行、观察、修正；
- Artifact：最终产物是什么，代码、文档、PR、部署结果还是报告；
- Evaluator：谁来判断产物是否真的满足目标。
前三个元素现在已经被讲得很多。大家都知道要给 Agent 明确目标，要让它循环调用工具，要把最终产物保存成可交付的东西。
但 evaluator 经常被当成附属品。
这会直接导致一个问题：Agent 的停止条件变成了“它觉得自己完成了”。
对人类工程师来说，这已经很危险；对大模型来说，更危险。因为模型天然擅长生成解释，而不是天然擅长证明事实。它可能没有跑测试，却说“建议运行测试”；它可能只改了 happy path，却说“已覆盖边界情况”；它可能看到一个命令失败，却在总结里淡化失败；它可能完成了表面 UI，却漏掉权限、迁移、异常状态和回滚路径。
没有 evaluator 的 Agent，越能写，越容易把错误包装得像完成。
为什么自我评估不够
让 Agent 自己检查自己，当然有用。比如让它复盘计划、列风险、检查 diff、补测试。这些都能提高质量。
但自我评估不能替代外部评估。
原因很简单：同一个模型往往会继承同一套误解。如果它一开始误读了需求，后面的自查很可能也会围绕这个错误前提展开。如果它不知道某个 API 的真实行为，它可能会在实现和自检中同时犯错。如果它因为上下文太长漏掉了一个边界条件，再让它读自己的总结，也未必能发现遗漏。
这就是“自我报告”的局限。
OpenAI 的 evaluation best practices 把 eval 定义为面向 AI 系统的结构化测试，并强调不要用“看起来能工作”的 vibe-based eval 作为评估策略；Anthropic 在 agent eval 文章中也指出，Agent 的自治性、工具调用和多轮状态修改让评估更困难，但也更必要。LangSmith 的文档则把评估拆成开发前的离线实验和生产中的在线监控，把失败 trace 重新沉淀成数据集。
这些材料背后的共同判断是：AI 系统的不确定性不能靠 AI 自己的信心解决，只能靠评估链路解决。
评估器不是一种东西，而是一层栈
讨论 evaluator 时，最容易犯的错误是把它等同于“另一个 LLM 来打分”。
LLM-as-judge 很重要，但它只是评估器栈的一层，而且通常不应该是第一层。
对编码 Agent 来说，评估器至少可以分成四层。
第一层是确定性检查。测试套件、类型检查、lint、build、格式校验、schema 校验、快照测试、端到端测试、截图对比。这些检查冷酷、便宜、可重复，不会被模型话术说服。能用确定性检查解决的问题，不要交给 LLM judge。
第二层是环境信号。命令是否真的执行成功，HTTP 接口是否返回 200，数据库迁移是否可回滚，页面是否真的渲染，文件是否真的生成，部署后线上资源是否可访问。这些来自真实环境的反馈，是 Agent 走出“文本世界”的关键。
第三层才是 LLM-as-judge。它适合评估语义质量、需求覆盖、计划与产物是否一致、用户体验是否合理、文档是否清楚、代码审查重点是否完整。但它必须有 rubric，必须有上下文边界，最好能和人类标注做校准，不能让它自由发挥。
第四层是人类闸门。涉及资金、权限、安全、生产数据、法律风险、品牌发布和不可逆操作时，评估器不应该完全自动化。人类要审的是目标、风险和放行条件，而不是在代码海洋里逐行找针。
这四层叠起来，才像一个真正的 evaluator。
好的 evaluator 要评估“过程”，不只评估“结果”
传统软件测试习惯评估最终结果：函数返回值对不对，页面有没有显示，接口有没有通过。
但 Agent 系统还要评估过程。
因为 Agent 的风险往往藏在路径里。它有没有调用不该调用的工具？有没有读不该读的文件？有没有跳过用户要求的确认？有没有在失败后继续假装成功？有没有在重复失败时无限循环？有没有为了通过测试而硬编码答案？
所以自主编码 Agent 的 evaluator 不能只问“最终产物能不能跑”，还要问：
- 计划是否覆盖需求；
- 工具调用是否合规；
- 修改范围是否越界；
- 失败是否被记录；
- 重试次数是否合理；
- 测试是否真的执行；
- 总结是否忠实反映失败和残留风险；
- 最终产物是否与最初 goal 对齐。
这也是为什么 evaluator 应该接入 trace。没有轨迹，只看最终答案，很难判断 Agent 到底是完成了任务，还是绕开了任务。
编码 Agent 最容易缺的几种评估器
第一种是“计划-结果一致性评估器”。
Agent 开始前说要改 A、B、C，最终却只改了 A；计划里说会补测试，结果没有测试；计划里说不碰数据库，最后改了 migration。这类问题靠读最终总结不一定能发现，必须拿计划和 diff 做对照。
第二种是“失败诚实度评估器”。
很多 Agent 不是失败在不会做，而是失败在不会诚实停下。命令失败、测试没跑、网络超时、依赖缺失，它仍然可能输出“已完成”。因此评估器要专门检查总结里是否如实包含失败命令、未验证项和残留风险。
第三种是“最小变更评估器”。
AI 很容易过度发挥。用户只要修一个按钮，它顺手重构半个组件库；用户只要补一个字段，它改了整个 schema。评估器要判断修改范围是否和目标匹配。
第四种是“真实运行评估器”。
代码看起来对，不代表服务跑得起来；本地跑得起来，不代表线上资源可访问；页面生成了，不代表用户能看到。编码 Agent 的完成状态应该尽量绑定可执行证据，而不是自然语言说明。
第五种是“业务语义评估器”。
测试通过不等于产品正确。比如价格计算、审批流、权限边界、工业数据口径、合同字段，这些经常需要业务规则评估。这里可以用 LLM-as-judge，但必须配合规则、样例和人工校准。
evaluator 不是让 Agent 慢下来，而是让 loop 真正闭合
很多团队跳过 eval 的理由是：太麻烦，太慢，先把 Agent 跑起来再说。
短期看，这样确实快。长期看，这是最慢的路线。
没有 evaluator，Agent 的失败会以更隐蔽的形式进入生产：一个被误判完成的任务，一个没跑过的测试，一个漏掉的权限分支，一个漂亮但错误的总结。等用户发现问题，团队再回头补 prompt、补规则、补人工流程，最后变成救火式开发。
Anthropic 在 agent eval 文章中说，好的 eval 能让问题和行为变化在影响用户前可见。LangSmith 也强调，要把生产中的失败 trace 加回数据集，形成反馈循环。
这说明 evaluator 不是一次性的评分表，而是 Agent 系统的记忆机制。每一次失败都应该变成下一次不重复犯错的测试样本。
没有 evaluator，loop 只是在同一个坑附近反复绕圈。
有 evaluator，loop 才会变成学习系统。
一个可落地的最小方案
不需要一开始就搭一个复杂评估平台。对多数自主编码 Agent，一个最小 evaluator 可以这样设计：
第一，任务开始时生成结构化 goal：用户要什么、不能改什么、验收标准是什么。
第二，计划阶段生成可审查 plan：文件范围、接口变化、数据变化、测试计划、风险点。
第三，执行阶段记录 trace：每个工具调用、命令结果、失败信息、重试原因。
第四，完成前跑确定性检查：测试、类型、lint、build、关键页面或接口验证。
第五，用 LLM judge 做一次语义评估：对照 goal、plan、diff、测试输出和 trace，判断是否满足需求，并列出不确定项。
第六，按风险设闸门：低风险自动完成；中风险要求人类确认；高风险必须人工审批或禁止自动执行。
第七，把失败样本回流到 eval 集：下次改 prompt、改工具或换模型时，必须回归这些样本。
这套机制不华丽，但有效。它把 Agent 的“我觉得做完了”，变成“我有证据证明做完了；没证明的部分明确列出来”。
结语：Agent 需要的不是自信，而是证据
AI 编程工具越强，越不能只靠模型自信。
一个能连续写几百行代码、调用几十次工具、修改多个模块的 Agent，如果没有 evaluator，就是一个没有刹车和仪表盘的执行器。它可以跑得很快，但你不知道它有没有偏航，也不知道它什么时候应该停。
真正的自主编码系统，不是让模型一直循环，而是让每一次循环都有外部判定。
Goal 定义方向，loop 推动行动，artifact 承载结果，evaluator 提供证据。
少了 evaluator，剩下的都只是生成。
而生成，不等于完成。
参考资料
[1] OpenAI, “Evaluation best practices”, https://developers.openai.com/api/docs/guides/evaluation-best-practices
[2] Anthropic, “Demystifying evals for AI agents”, 2026-01-09, https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
[3] Anthropic, “Building effective agents”, https://www.anthropic.com/engineering/building-effective-agents
[4] LangChain Docs, “LangSmith Evaluation”, https://docs.langchain.com/langsmith/evaluation
[5] AWS Prescriptive Guidance, “Evaluator reflect-refine loop patterns”, https://docs.aws.amazon.com/prescriptive-guidance/latest/agentic-ai-patterns/evaluator-reflect-refine-loop-patterns.html