如果你最近在关注 AI Agent 开发大概率会越来越频繁地撞见一个词Grader。它会出现在各种讨论里有人叫它评估器有人叫它裁判模型也有人直接把它理解成“AI 给 AI 打分”。刚开始接触时我其实没有太在意觉得不就是加一层校验吗后来发现不对。尤其是在看 swyx 这类长期泡在 AI 工程一线的开发者分享时能明显感觉到他们对 Grader 的痴迷程度远超一般工具。不是那种“这个库不错推荐一下”的兴奋而是反复拆解、讨论、重构甚至像是在“破解”一个还没被完全解开的难题。这种状态很容易让人好奇一个评分组件为什么值得这么较劲后来我想明白了一件事。他们痴迷的从来不是“打分”这个动作而是 AI Agent 开发里最要命的一个瓶颈——你靠什么来判断一个 Agent 真的好用这个判断机制的基础设施就是 Grader。它不是一个锦上添花的校验步骤而是一个决定 AI Agent 能不能从 demo 走向生产的核心关卡。这篇文章想顺着这条线索把“破解 Grader 的深层原因”拆开来看。我会先从 Grader 在 AI Agent 里的真实位置讲起再解释为什么人眼验收会失效然后给出一个可以用来落地的最小工作流最后聊清楚这个方案的边界和长期价值。1. 先搞明白Grader 到底在 AI Agent 里扮演什么1.1 从一句话任务到一个多步工作流评估复杂度完全变了早期用大模型很多人最熟悉的评估方式是人眼看输出。你给一段 prompt模型给一段回答你用自己的经验和判断力给结果打分。这在单轮问答、文本摘要、内容改写这类场景里基本够用。因为输入输出都短任务目标相对明确人眼判断的成本很低。但进入 AI Agent 场景后情况完全不同了。Agent 不是只回答一个问题它会被分配一个目标然后自主决定调用哪些工具、以什么顺序执行、在什么条件下停止。比如让一个 Agent 去“整理一批PDF文件提取里面的关键字段并按客户姓名生成索引”。这个任务里Agent 可能要读取文件、解析内容、调用模型做抽取、把结果写入表格甚至要在遇到格式异常时自己决定重试还是跳过。这时候你面对的结果不是一个答案而是一连串工具调用、中间状态和最终产物。人眼评估的复杂度开始指数级上升。你不光要看最终表格对不对还要判断过程是不是低效、有没有漏文件、有没有在某个工具上反复重试。过去可以“一眼看出问题”的评估方式在这里就失效了。Grader 解决的正是这个问题。它不是去替代人的主观判断而是把评估这件事变成可重复、可量化的程序逻辑。它像是一个专门负责检验的子系统在 Agent 执行完任务后根据预设标准给出判断结果是否合格、过程是否合理、哪一步出了问题。1.2 Grader 的本质是反馈闭环里的裁判如果想更直观地理解 Grader 的位置可以把它想象成一个团队里的质检员。你开发了一个 Agent本质上就是在培训一个“员工”。员工做完任务你得有人检查结果。这个检查者不能是员工自己否则很容易出现“我觉得我做得挺好”的自我评价偏差。它也不能完全靠管理者抽查因为任务数量变多之后人工根本看不过来。Grader 就是这个质检员。它接收 Agent 的最终输出有时也接收中间步骤然后按照一套明确的标准输出“通过”或“不通过”可能还会附带具体的改进建议。更重要的是这个质检结果会反馈到开发闭环里。你调整 prompt、修改工具配置、更换模型之后需要拿同一批样例重新跑一遍然后用 Grader 的评分来判断改动到底是变好了还是变差了。这就形成了一个反馈闭环Agent 执行任务 - Grader 评估结果 - 开发者根据评估修正系统 - 再次执行。没有这个闭环你每一次改动都只能凭感觉有了这个闭环迭代才有一个相对客观的参照物。这也是为什么我说 Grader 不只是工具而是基础设施。它承载的是 Agent 开发里的“可度量性”。没有度量就没有方向没有方向再强的模型也只是一个随机性很强的黑盒。1.3 为什么它会成为 swyx 这类 AI 痴迷者的焦点从 swyx 的讨论主线里能看到一个反复出现的信号他关心的不只是模型能做什么而是怎么把一个不可靠的大模型行为变成一个可控制、可迭代、可维护的工程系统。在 Agent 这个方向上最大的工程障碍就是评估也就是 Grader。你把任何 Agent 项目推到一定程度都会遇到同一个问题本地跑了几次效果不错但换了一批输入或多跑几轮之后结果开始漂移。这时候你发现自己很难判断是哪个环节出了问题。是 prompt 不够清晰是工具调用的边界没定义好还是模型在某些情况下根本不具备这个能力如果没有 Grader你就只能在“似乎好一点”“好像又不行了”这种感觉里打转。这对 demo 来说无所谓对生产系统是致命的。所以你会看到很多长期做 AI 工程的开发者都会把大量时间花在怎么设计 Grader 上。他们不是在追求一个打分工具而是在寻找一种让复杂 AI 系统收敛的方法论。破解 Grader表面上是在解决“如何评估 AI 输出”实际上是在解决“如何让 AI 开发从玄学变成工程”。2. 人眼验收为什么会失效2.1 单次生成可以靠人判断Agent 却需要持续判断很多人对 AI 评估的第一反应是让项目经理或领域专家抽看一下不就行了在小规模、低频场景里确实可以。你一周只跑十几个 Agent 任务每个任务花五分钟人工核对成本是可控的。但一旦任务量上来比如每天处理几百上千个需要 Agent 自动化的请求人工验收就变成了瓶颈。你不能让一个人为了检查 Agent 输出从早看到晚。更麻烦的是Agent 的任务往往是长链路、多分支的同一个任务会有很多种合法执行路径。人工判断时容易出现尺子不统一的问题这个人觉得没问题那个人觉得有瑕疵今天觉得可以通过明天觉得不够好。Grader 的价值在这里变得更加明确。它能提供一个稳定的判断标准。只要标准设定清楚了它对同一类输出的判断就是一致的。它不会因为中午没吃饭而脾气变差也不会因为任务量太大而漏看细节。它至少能保证“判断的稳定性”这是人工评估很难做到的地方。2.2 多步执行、中间状态、工具调用让结果变得不可见另一个更麻烦的问题是Agent 的很多决策动作并不直接体现在最终输出里。比如一个 Agent 在处理一个问题时先调用了一个搜索工具但没有找到有效信息于是又换了一个工具或者它连续重试了三次同一个接口最后用了一个不太规范的方式拿到了结果。这些过程如果只看最终输出完全看不到。那我为什么会说这类过程很关键因为它决定了 Agent 系统的稳定性、成本和可维护性。一个最终结果正确但过程反复失败的 Agent是不可信的。它可能在今天的输入上碰巧成功明天就崩溃。人工验收如果只看最终结果很难发现这类问题而 Grader 如果被设计为过程级评估就可以把这些中间状态纳入判断范围。这也是“破解”难点的一个重要来源你不仅要让 Grader 判断“结果对不对”还要让它判断“行为好不好”。前者相对容易因为大多数任务都有明确结果后者很难因为“好的行为”本身不是一个清晰边界它依赖于任务目标、工具约束和历史经验。2.3 非确定性让“凭感觉改 prompt”失效还有一个基本事实大模型生成是非确定性的。同一个 prompt同一份上下文在温度不为 0 时连续跑几次可能得到不同结果。这一下子击穿了很多人习惯的开发方式。不少开发者迭代 prompt 的方法是“我改一下跑一遍肉眼看结果”。这在单样本上还能用。但问题在于一次成功不能代表改动是有效的。它可能只是这一次随机命中了。你这次看到“效果变好了”可能只是运气真正的问题是你没办法判断整体分布变好了还是变差了。Grader 其实是在对抗这种非确定性。它把评估从“看一个样例”变成“跑一批样例”。你用一组覆盖典型输入的样本集让 Agent 跑完再由 Grader 批量打分。这样单次输出的随机波动会被平均掉。如果这一批样本的通过率从 70% 涨到了 85%你才有理由说这次改动确实有效。这也是为什么人们常说 AI Agent 开发最缺的不是模型能力而是可靠评估。越是不确定的系统就越需要一个确定性的观测工具。Grader 就是那面观察系统的镜子。3. 破解 Grader 的三个层次3.1 L1输出级评估先判断“结果合不合格”最基础的一层是直接对 Agent 的最终输出做检查。它的核心问题很朴素这个结果是不是符合要求输出级评估有几种常见实现方式。最简单的是规则判断比如检查输出是否包含某个必填字段、是否为空、长度是否满足下限、格式是否符合 JSON 结构。这种方案的优点是可解释性强、几乎零成本缺点是只能解决“硬约束”类问题无法判断语义质量。再往上是基于模型判断也就是常说的 LLM-as-Judge。你定义一个评分 prompt让一个模型根据标准去评估 Agent 的输出给出分数或通过/不通过。比如让 Agent 生成的客户摘要Grader 会被要求判断摘要里是否包含客户姓名、公司、最近联系时间、跟进建议信息是否有明显错误语言是否清晰。它能处理模糊的语义质量问题比正则表达式灵活得多。输出级评估适合大多数有明确交付物的 Agent 场景。先跑通这一层你就有了一个基础回归测试网。后续改动 prompt 或模型时用同一批样本跑一遍分数有没有变化会直接告诉你改动方向对不对。3.2 L2过程级评估检查 Agent 的推理和工具调用链路输出级评估能挡住“结果错了”的情况但挡不住“结果对了、过程乱七八糟”的情况。随着 Agent 系统复杂度提高过程级评估会变成刚需。过程级评估关注的是 Agent 在完成任务过程中做过的关键决策。它要看的东西包括Agent 是否在合适的节点调用了正确的工具工具参数传得对不对遇到错误时是否做了合理的重试会不会在同一个工具上反复打转是否有明显多余的步骤有没有在信息不足时强行输出答案。这类评估通常需要依赖 Agent 框架里的 trace 或日志信息。你需要把每一次工具调用的输入、输出、耗时、错误信息都记录下来然后让 Grader 基于这条执行轨迹做判断。比如你可以定义一个“是否有效使用工具”的标准如果 Agent 在搜索工具中没有得到结果但立即转向了另一个工具这就是合理行为如果它连续五次用不同关键词但同一个工具可能就是低效行为。过程级评估的难点不在写 prompt而在数据采集。如果 Agent 框架没有为你埋好 trace你连评估的材料都没有。所以从第一天开始就应该给 Agent 执行过程加日志。这不算额外成本但它会在后期决定你能不能做这层评估。3.3 L3系统级评估把 Grader 变成回归测试和迭代杠杆再往上一层是把 Grader 当作一个系统级工具来用。你会开始关注一个更宏观的问题整个 Agent 系统在真实环境里的表现是不是稳定系统级评估通常有几种指标任务成功率、平均耗时、工具调用次数、失败重试率、成本消耗。你会用一批历史真实请求作为回归集每次发布新版本前都跑一遍完整回归。Grader 不再只是看一两个结果而是汇总出一份质量报告告诉你哪个类型的问题变多了哪个环节的失败率上升了。这一层才是 Grader 真正体现长期价值的地方。一个人跑 demo 的时候不需要系统级评估但一个团队要上线 Agent 应用就需要一个能持续运行的评估管道。它会变成你发布流程里的 CI每次代码或 prompt 变更后自动执行输出一个可信的“是否可发布”信号。到这里Grader 就不再是一个附属于 Agent 的小组件而是 Agent 工程体系里的核心支柱。层次评估对象常用方法适用场景L1 输出级最终结果规则、正则、LLM-as-Judge有明确交付物结果可验证L2 过程级工具调用、推理轨迹trace 分析、过程打分多工具、多步骤的长链路 AgentL3 系统级整体稳定性回归集、通过率、成本指标上线后的持续迭代和版本发布4. 从想法到落地搭一套最小可用 Grader 流程4.1 先准备样本集而不是先调 prompt很多人搭建 Grader 时会犯一个顺序错误先写了一大段评估 prompt然后才开始找测试样例。我建议反过来。先准备样本集再设计评估标准最后再写评分逻辑。样本集不需要一开始就很大20 到 50 条就可以起步。关键是覆盖性好。你得把典型成功场景、容易出错的边界场景、明显不合格的场景都包含进去。比如一个“做会议纪要并输出行动项”的 Agent样本集应该包含正常会议、发言内容混乱的会议、有多个决策点的会议、没有明确行动项的会议。这样 Grader 才能学着分辨不同类型的结果。准备样本集时还有一个重要动作给每一条样本做标注。你可以为每条样本打一个标签通过 / 不通过或者 1 到 5 分并附上简短说明。标注这个过程本身就很有价值它会逼你先把“好”和“坏”的定义想清楚。如果你自己都说不清什么算好结果Grader 不可能替你想清楚。4.2 用 LLM-as-Judge 做一个最简单的判定示例这里给出一个很常见的最小实现思路用大模型充当裁判输入 Agent 的输出输出一个结构化判定结果。下面是一个示例结构不是具体某个项目的完整实现你可以根据自己场景改。import json from openai import OpenAI client OpenAI() judge_system_prompt 你是一个严格的输出质量评估器。你会收到一条 Agent 生成的会议行动项结果。 请根据以下标准进行评估 1. 所有行动项是否包含明确负责人。 2. 所有行动项是否包含可执行的下一步动作。 3. 行动项是否与原始会议内容一致没有明显遗漏或杜撰。 4. 输出格式是否符合 JSON 数组规范。 请输出 JSON格式如下 {pass: true/false, score: 0-10, issues: [问题1, 问题2]} def grade_output(agent_result_text): response client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: judge_system_prompt}, {role: user, content: fAgent输出\n{agent_result_text}} ], temperature0, response_format{type: json_object} ) return json.loads(response.choices[0].message.content)有几个细节需要注意。第一裁判模型的温度要设置为 0这样可以减少评分随机性。低温不代表绝对一致但能显著提高稳定度。第二评估标准要尽可能写成“是否式”或“可验证式”的句子而不是“回答是否合理”这种模糊表达。越具体模型越容易给出稳定判断。第三输出必须是结构化 JSON。这样你才能把结果汇总、统计和分析。4.3 批量执行、结果汇总、人工抽检的完整路径最小可用流程建议按四步走。第一步用你的 Agent 跑完样本集把每条样本对应的输出保存下来。不要边跑边删尽量保留原始输出。第二步用 Grader 批量对输出打分。这里建议逐条调用并把评分结果和 Agent 输出一一对应地落成一张表。字段可以包括样本 ID、期望标签、Grader 判定、分数、问题列表。第三步人工抽检 Grader 判定为“不通过”的样本确认是真问题还是误报。这个步骤很关键它能帮你了解 Grader 当前的有效性。第四步统计通过率、误报率、漏报率并决定是调整评估标准还是调整 Agent 的 prompt。注意不要一开始就把 Grader 的评分当成绝对真理。它更像是你的“自动化第一层筛选”。真正上线前还是要结合人工抽检来校准。4.4 一个可复用的排查顺序如果你发现 Grader 的评分结果和你的预期不一致先不要急着改评估 prompt。按下面这个顺序排查先看输入传给 Grader 的 Agent 输出是否完整有没有因为截断或格式化导致信息缺失。再看评估标准标准里是否存在模糊词比如“合理”“清晰”“正确”。如果有试着改写成可验证的布尔式描述。再看评分 prompt 的上下文模型是否理解了你要求的 JSON 格式有没有被过长的指令干扰。再看模型选择评分模型的智力水平是否匹配任务复杂度。如果一个非常复杂的语义判定任务用了一个小模型误判率会很高。最后看样本本身有没有可能样本标注就是错的。很多时候 Grader 的“误判”其实是样本标准本身就模糊。这套排查顺序能避免一个常见问题一遇到评分不对就反复改 prompt最后把 Grader 调成了一团乱麻。5. 破解 Grader 的边界以及它真正留下的东西5.1 Grader 不是万能裁判它需要一个“评估标准”讲了这么多 Grader 的价值我必须同时把它的边界说清楚。Grader 不是凭空产生判断能力的它背后得有一个明确的“评估标准”。这个标准的制定权仍然在人和业务手里。如果一个任务本身就没有清晰的目标比如“让 Agent 帮我写一段好听的开场白”“好听”的标准因人而异那 Grader 很难稳定工作。你可以让一个模型去打分但分数的含义会非常模糊。它可能只是在学习你的偏好样本而不是在判断一件客观正确的事。因此Grader 更适合目标相对明确、成功标准可以描述的任务。哪怕任务本身复杂比如“让 Agent 处理客户投诉邮件并给出跟进建议”你仍然可以把“是否识别了客户核心诉求”“是否给出了可操作方案”“语气是否合适”拆成几个子标准。只要标准可描述Grader 就能变得可依赖。如果任务目标极为主观我更建议把 Grader 当作一个辅助过滤器而不是最终裁决者。它可以帮你筛掉明显不合格的输出但最终判断还是要回到人。5.2 和人工评估的关系自动加人工抽检在实际工程里Grader 和人工评估不是替代关系而是配合关系。成熟的做法是Grader 负责全量初筛人工负责对关键样本和难点样本做抽检。这样做的好处很明显。全量初筛保证了覆盖面让你不会漏掉那些“明显不合格”的输出人工抽检保证了对模糊边界的掌控。你不需要让 Grader 做到 100% 准确只要它能稳定地把 80% 的低质量结果拦下来就已经产生了巨大价值。剩余 20% 的模糊地带交给人工去判断。这个思路也解释了为什么像 swyx 这类人会痴迷于 Grader。他们看重的不是“让 AI 完全替代人的判断”而是“把人的判断力沉淀成可复用的标准”。一旦你完成了这个沉淀AI Agent 开发就不再是一锤子买卖而是一个可以无限迭代的工程过程。5.3 长期价值从单次任务收敛到一套可持续迭代的工程方法最后想说的是破解 Grader 这件事真正留下的不是一个具体的评分工具而是一套工程思维。在 AI Agent 进入生产之前最大的风险是“你以为它可用但它只是碰巧在这个样本上可用”。Grader 把这种风险显性化了。它逼你定义什么是好结果逼你准备样本集逼你把每次迭代变得可观测、可回溯。这套方法的价值会随着你的 Agent 系统复杂度上升而不断放大。你今天可能只是给一个简单工具加了一层输出校验明天它就会发展成一套包含回归集、自动化评分、质量报告的完整评估体系。到那个时候你就不再是“调 prompt 的人”而是真正在建设 AI 工程系统的人。如果你现在手头正好在做一个 Agent 项目我给你的建议很简单先别急着加更多工具和模型花一个下午准备好十几条样本用一个最简单的 LLM-as-Judge 把 Grader 跑通。这个流程一旦转起来你对 Agent 的判断力会比过去清晰一个级别。swyx 的痴迷背后其实也是这样一条朴素的道路先让自己看得清系统在发生什么然后再去谈优化和控制。