在 Harness 系列前几篇中，我们依次拆解了架构设计、工具管理、记忆系统和长任务执行。如果把这五层 Harness 架构比作一辆车，前几层解决的是"怎么开起来"，但有一个核心问题一直没有正面回答：Agent 输出的东西，到底对不对？

这个问题比看起来难得多。

Agent 自己会说"任务完成了"。但在生产环境里，一个自信地输出了错误答案的 Agent，往往比一个显性报错的 Agent 危害更大，因为你根本不知道它出了问题。

如果没有专门的验证机制，错误不会被发现，只会被当作事实继续传递给下一步。到任务结束时，你拿到的是一个看起来合理、实际上已经在第 10 步偏离轨道的结果。

这就是 Harness 五层架构里 Evaluation 层要解决的问题：不让模型自己判断自己对不对，而是让「系统」来验证**。**

更准确地说：Evaluation 并不是在“判断对错”，而是在不确定环境中，为 Agent 提供持续的偏差检测与纠偏能力。

即：Evaluation 的本质，是在****控制系统的不确定性，而不是一次性的结果验证。

一、为什么不能让模型自己检查自己：3 个先天局限

很多团队在做 Agent 时，会把验证这件事交给模型本身：在 Prompt 里加一句"完成后请检查你的输出是否正确"，或者在循环里让模型自评一遍。

这种方式有一定作用，但在生产环境里并不可靠。原因有三个，都来自模型的先天局限，不是调教问题。

局限一：模型倾向于认可自己的输出。 模型生成了一个答案之后，再让它评估这个答案，它会倾向于维护而不是质疑。这不是模型的偷懒，而是生成式模型的工作机制，它在"上下文里已经有了这个答案"的基础上继续推理，自然会把它当作参考点。研究表明，模型在自我评估时的确认倾向显著高于由独立评估者评估。

局限二：模型没有领域基准。 模型不知道"正确"对你的具体业务意味着什么。它能判断语言是否通顺、逻辑是否自洽，但判断不了生成的 SQL 查询结果是否符合你的数据库 schema、生成的代码是否能通过测试、输出的合规文件是否满足监管要求。这些标准存在于系统里，不在模型的参数里。

局限三：错误传播会污染评估环境。 如果 Agent 在第 10 步产生了一个错误，到第 15 步做自我评估时，上下文里已经充满了基于这个错误构建的后续推理。模型不是在评估"原始输出是否正确"，而是在评估"后续推理是否与前面一致"，这两件事完全不同。

换句话说：让模型检查自己的输出，本质上是让病人给自己看诊**。** 有时有效，关键时刻不可依赖。

二、Harness Evaluation 的 3 种验证机制

在进入具体机制之前，可以先换一个视角看这个问题：所有验证机制，本质上都在回答一个问题：系统如何获得“正确性的参照”（Ground Truth）？

这是 Evaluation 层设计的核心认识论问题。不同验证机制之间最根本的差异，不是工具不同，而是建立 Ground Truth 的方式不同：

• 程序化验证：外部确定性 Ground Truth。"对"的定义被写进了系统（测试、规则、schema）
• 独立模型评估：近似 Ground Truth。另一个模型的判断代理真相
• 多 Agent 交叉评审：共识逼近 Ground Truth。多方意见收敛逼近真相

理解了这层，三种机制的选择逻辑就清晰了：越能得到确定性 Ground Truth，验证越可靠；越依赖"近似"或"共识"，可靠性就越依赖设计质量。

第一种：程序化验证（Programmatic Verification）

本质：从外部系统获取“确定性 Ground Truth”

这是最可靠、成本最低的验证方式。用确定性的规则或程序来判断输出是否正确，规则不会随机波动，结果是二元的：通过或不通过。

最典型的例子：在 AI 编程 Agent 里，自动运行单元测试。模型说"代码写好了"，系统的响应不是"好的，继续"，而是立刻运行测试套件。测试通过才算完成，测试失败就把具体的报错信息回传给模型。

Spotify 在大规模 PR 合并实践中的核心设计就是这一层：不让 Agent 自己宣布"修改完成"，而是由构建系统和 Maven 测试给出硬结果。这个设计让他们成功合并了 1500 多个 PR，核心是让验证标准从模型口头结论变成系统硬结果。

除了测试，程序化验证还包括：JSON schema 校验、数据格式检查、数值范围检验、API 返回码校验等。任何可以用规则描述的"正确性"，都应该优先用程序化验证。

程序化验证的局限是覆盖范围：它只能验证"可以被规则描述的正确性"。对于开放性的生成任务（内容质量、推理合理性、业务相关性），规则覆盖不到，就需要下面两种机制。

第二种：独立模型评估（LLM-as-Judge）

本质：构造一个“近似 Ground Truth”

当输出质量无法用规则描述时，可以引入一个独立的评估模型对输出进行打分或判断。

关键词是"独立"：评估模型和执行模型是分开的，两者之间没有共享的上下文历史，评估模型只看最终输出，不知道执行过程怎么走的。这样的设计，是在用"第三方近似"替代"自我评估"，Ground Truth 的可靠性高于让执行模型自判，但仍然是近似而非确定。

评估模型通常会被给定一套评估标准：相关性是否达标、内容是否准确、格式是否符合要求、有没有幻觉内容。输出一个结构化的评分结果，系统再根据分数决定是通过、重试还是升级处理。

这种方式的优势是灵活：几乎任何类型的输出都可以被评估，不需要预定义规则。2026 年有研究显示，经过精心设计的 LLM-as-Judge 系统在评估质量上已经接近专业人类评审，速度和成本远低于人工审核。这种机制的本质，是用独立的评估视角来近似 Ground Truth，而不是让执行者自证清白。

局限是确定性不够：评估模型本身也可能出错，对于高风险输出不能完全依赖。

第三种：多 Agent 交叉评审（Multi-Agent Review）

本质：通过多次独立判断逼近“共识 Ground Truth”

对于高风险或复杂的输出，可以引入多个 Agent 相互验证。通过共识逼近 Ground Truth。

最简单的形式是辩论：两个 Agent 分别对同一个输出给出独立判断，再由第三个 Agent 综合两方意见得出结论。更复杂的形式是分工评审：一个 Agent 评估内容准确性，另一个评估格式合规性，第三个评估安全风险，最后合并所有评审结论。

2026 年初，一篇关于多 Agent 协作评估的论文（CollabEval）给出了数据：多 Agent 交叉评审在评估质量上显著优于单一模型评估，尤其在单个模型不确定或有偏差的情况下，多方意见的合并能有效提高准确率。单一评估者的判断偏差，在多方交叉中会被相互纠正，共识结果比任何单一判断都更接近真相。

这种方式的代价是成本高，相当于为了验证一个输出，要多跑几次模型推理。适合用在任务的关键节点，而不是每一步都做。

三种机制的选择逻辑

从 Ground Truth 的角度来看，三种机制的选择其实很简单：能得到确定性 Ground Truth 就用程序化验证，不能就退而求其次用LLMJudge，高风险场景再加 Multi-Agent 提高共识可靠性。 不是因为工具不同，而是因为你能获得的 Ground Truth 质量不同。

实际工程中的常见配置是：程序化验证作为基础防线，LLM-as-Judge 作为质量检查，关键节点触发多 Agent 评审。不是每一步都要三层全上，而是根据这一步的风险等级选择合适的验证强度。

三、4 个关键设计决策：让 Evaluation 层真正跑起来

理解了三种机制之后，更关键的问题是：在工程实践中，如何把 Evaluation 层设计正确。有 4 个决策经常决定 Evaluation 系统的成败。

这四个决策，本质上都在回答同一个问题：在成本约束下，如何最大程度地降低输出的不确定性。

程序化验证把不确定性压到接近零，但只能覆盖可规则化的场景；LLM Judge 覆盖面更宽，但不确定性更高；Multi-Agent 进一步降低不确定性，代价是成本急剧上升。每一个设计决策，都是在这个坐标系里找到最适合当前场景的平衡点。

决策一：在哪里验证

验证可以发生在三个粒度：单步验证、阶段验证、任务级验证。

单步验证是每一次工具调用后立即检查返回结果是否符合预期。这种方式能最快捕获错误，阻止错误传播。但如果每一步都做完整的模型评估，成本会很高。通常的做法是：单步做轻量的程序化验证（schema 检查、非空检查），阶段结束时做完整的质量评估。

阶段验证是在 Task Loop 的每个阶段完成后做一次整体评审，这一阶段的产出是否达到了预期目标，才能进入下一个阶段。这和 Task Loop 篇讲的阶段管理是直接配合的：每个阶段都有一道质量门禁（Quality Gate），不达标不放行。

（Harness Task Loop：「长任务」执行的 5 个核心机制与 4 条工程原则）

任务级验证是在整个任务结束后做最终验证。这是最后一道防线，但不应该是唯一的防线。如果前面没有中间验证，到最后才发现问题，修复成本极高。

结论：验证不是任务结束时才做的事，而是嵌入到执行流程每个关键节点的持续机制。

决策二：验证失败怎么处理

发现问题之后，系统有三种响应方式：自动重试、回滚到检查点、升级给人工。

自动重试适合明确的、有修复路径的错误：比如代码测试失败，把报错信息回传给模型让它重新修改。关键是要设定最大重试次数，避免进入无限重试循环，也要确保每次重试都把错误信息准确地反馈给模型，而不是让模型在不知道哪里错了的情况下瞎猜。

回滚到检查点适合无法通过重试修复的情况：当前的执行路径走进了死胡同，最好的办法是回到上一个干净的状态重新来过。这依赖 Task Loop 篇讲的检查点机制：没有检查点，就没有可回滚的状态。

升级给人工适合高风险或系统无法自主判断的情况：比如涉及不可逆操作的决策、超过重试次数仍然失败、或者验证结果本身存在歧义。这和 Task Loop 里的人机协作节点是同一套机制。

这三条路不是选一条，而是按顺序触发的升级链：先重试，重试不行回滚，回滚也不行才交给人。

决策三：验证结果怎么反馈给模型

验证不只是通过/不通过的判断，它的结果质量直接决定模型能否在下一步真正修复问题。

差的反馈：“验证失败，请重新生成。”。模型不知道哪里错了，只能随机尝试。

好的反馈：“第 3 步生成的 SQL 查询语法正确，但返回了空结果集。检查原因：表名 user_events 在当前数据库不存在，实际表名为 user_activity。”。模型有了明确的修复方向。

Evaluation 层输出的不是"错误"这个结论，而是足以驱动下一步修复的具体诊断。这要求验证系统在设计时就考虑"这条反馈信息传回给模型之后，模型能不能用它来修复"，而不只是"这个输出达标了吗"。

决策四：验证覆盖率 vs 成本的平衡

理论上，对每一步都做三层验证最可靠，但在实际工程中不现实：每多一次模型调用就多一份延迟和成本。

一个实用的分级策略是：根据每个步骤的风险等级和可逆程度来决定验证强度。可逆操作（读取、查询）用轻量验证；不可逆操作（写入、发送、执行）用重量验证。关键路径上的步骤投入更多验证资源，辅助性步骤降低验证成本。

另一个控制成本的方式是统计采样：不是每次都做 LLM 评估，而是对一定比例的输出做评估，用统计信号来判断系统整体的输出质量是否在可接受范围内。这类似于软件工程里的 A/B 测试逻辑：用样本推断总体，而不是检查每一个输出。

四、Evaluation 是 Harness 的"观测机制"

有一个来自控制论的经典原理：任何控制系统，都必须同时具备执行能力和观测能力。 没有观测，控制就是盲操作：你不知道系统当前的状态，就不知道下一步该怎么调整。

把这个视角放进 Harness 架构里，会发现一件很有意思的事：

前几层做的全是"执行"：Environment 层给 AI 一个可工作的世界，Tool 层给它行动能力，Control 层管理执行流程，Memory 层提供状态记忆。但这四层没有一层在回答"执行结果是不是正确的"。它们让 Agent 能做事，但不知道事情做得对不对。

Evaluation 层，就是整个系统的观测机制。 没有它，Harness 里有多少执行能力，就有多少不可见的风险。

这也解释了为什么不能仅靠模型自判：模型自判是执行层在自己观测自己，这在控制论里叫"缺乏独立性的观测"，系统性偏差无法被发现。Evaluation 层的独立性不是设计偏好，而是观测机制有效运作的前提条件。

Agent 系统本质上是一个不可完全观测的系统：每一步推理过程都是黑盒，错误会在内部传播和放大。Evaluation 层提供的，是这个系统有限但关键的可观测性窗口：不是让 Agent 变得完全透明，而是让关键节点的状态可以被检查和纠正。

最后

回到开头的问题：Agent 输出的东西，到底对不对？

模型说"完成了"，不算完成。测试通过了，才算完成。评估模型打了高分，才算可用。多 Agent 交叉审核没有异议，才算可以上生产。

这不是对模型能力的不信任，而是工程成熟度的体现。软件工程里从来没有"代码写完就上线"，有单元测试、有代码审查、有 CI/CD 流水线。Agent 系统走向生产，同样需要这套质量保障体系，只是形式不同。

所有验证设计，归根结底都在做同一件事：在成本约束下，尽可能压低系统输出的不确定性。 程序化验证是最便宜的降不确定性方式，LLM Judge 是中等成本的近似，Multi-Agent 是高成本的共识。三种机制不是平级的选项，而是不确定性控制强度的梯队。

模型决定 Agent 能做什么，而 Evaluation 决定你敢不敢让它真的去做。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】