大模型AI-Agent 评测

部分内容可能来自网络或者由AI生成。如有雷同纯属巧合仅供学习参考之用。Agent 评测全景从方法论到工程落地一份系统梳理 Agent 评测的技术文档为什么评、评什么、怎么评、如何工程化落地以及业界前沿与经典 Benchmark。摘要大模型让搭一个 Agent的门槛降到最低但一个残酷的现实是90% 的 Agent 开发时间花在评测和调优上而不是初始搭建上。Agent 与传统软件最大的不同在于三道门槛——非确定性同样输入不一定同样输出、黑盒化内部决策不透明、错误级联放大前一步小错会被后续放大。这决定了跑几条 case 感觉还行远远不够必须把不稳定的智能行为持续收敛成可发布的工程质量。本文的核心观点可以浓缩为几句话评测不是上线前的抽查而是嵌入研发全流程的持续实践CE/CD评测要分层能用脚本精确算的绝不用模型去估需要语义判断的才交给 LLM高风险的再交给人评测对象要从只看最终答案扩展到看整条执行轨迹评测体系最终沉淀下来的核心资产是评测数据集定义评什么和评测 Skill/Rubric定义怎么评而平台只是执行引擎。一、为什么 Agent 评测是真正的难题Harrison ChaseLangChain CEO反复强调Agent 评测是整个 AI 应用领域最大的未解决问题之一。吴恩达则更直接判断一个团队做 Agent 项目进展快慢不看用了什么新技术而看效果评估与错误分析的能力。没有评测体系时团队通常会陷入三种被动一次跑通不代表稳定可用每次改模型、改 Prompt、改工具参数都可能悄悄改坏原本好用的场景多步链路里前面一个小偏差会在后面被放大成错误结论。更隐蔽的是假阳性——最终答案看起来对但执行路径已经偏离或带风险这类问题在生产里迟早暴露。一套成熟的 Agent 评测体系至少要回答三类问题问题典型回答产出能力水位当前任务完成率、工具正确率、幻觉率、合规通过率是多少基线分数和趋势变更风险新版本是否优于旧版本哪些场景退化了回归报告和发布门禁优化方向失败集中在哪些能力域该由谁修、怎么修根因聚类和行动项Agent 评测 vs 传统软件测试维度传统软件测试Agent 评测确定性输入相同输出确定存在非确定性同一输入可能不同输出评测对象功能正确性能力、安全性、可靠性、可解释性等多维度测试方式单元测试、集成测试能力评测、回归评测、轨迹评测、交互质量评测评分方式通过 / 失败多维度评分、加权评分、LLM 评分一个绕不开的理论验证者定律Verifiers LawJason WeiOpenAI/Meta在 2025 年提出的验证者定律给出了理解评测困境的底层框架训练 AI 解决某个任务的难易程度和这个任务的可验证程度成正比。所有可解且易验证的任务最终都会被 AI 攻克。其中的关键是验证不对称性数独解题要 20 分钟、验证只要 2 秒高度不对称AI 进步飞快两个 900 位数相加计算和验证差不多费劲近乎对称事实核查一篇夹带大量引用的文章验证比写作更耗时反向不对称AI 进展缓慢。这解释了为什么 SWE-bench 能成为黄金标准——代码世界完美符合客观真相、快速验证、可规模化、低噪声、连续奖励五条标准也解释了为什么 DeepResearch、医疗等领域评测极其昂贵。同时要警惕 Goodhart 定律当一个指标变成目标它就不再是好指标。 MMLU 三年从天堑变入门考试、SWE-bench 一年分数翻倍都是 benchmark 被 RLVR可验证奖励强化学习快速攻克、逐渐无法区分真学会和学会考试的例证。二、评测什么粒度、质量属性与 Agent 类型2.1 两种粒度端到端 vs 中间过程端到端评测E2E是黑盒评测关注从用户输入到最终输出的整体表现用于验证业务需求、评估用户体验、建立质量基线是必选项。中间过程评测是白盒评测深入 Agent 内部的规划、执行、记忆、工具调用等模块需要访问执行日志和中间状态用于深度调试、性能优化、模块质量评估是可选项。二者关系是端到端发现问题中间过程定位到具体模块中间过程的改进最终体现在端到端结果提升上。2.2 五大质量属性质量属性定义关键指标准确性输出结果的正确程度正确率 正确数 / 总输出数可靠性多次运行的一致性与服务可用程度可用率、运行一致率、可复现率安全性运行过程是否存在安全风险敏感信息泄露率、恶意输入识别率效率响应速度与资源消耗平均响应时间 / P95 / P99、Token 消耗、QPS鲁棒性对异常输入、边界场景的处理能力异常输入处理成功率2.3 先分清 Agent 类型再定指标类型不分评测结果基本不可用。不同类型的 Agent 评测重点和参考 Benchmark 不同Agent 类型评测重点参考基准知识问答型准确性、忠实性、引用溯源RAG 指标、事实核验任务执行型工具选择、参数正确、状态变更τ-Bench、Trace 校验、数据库状态比对推理决策型推理过程、证据链、结论可信度轨迹评测、专家 Judge多轮对话型记忆、澄清、推进、情绪承接、人工接管User Simulator、Session 级评测编程型代码正确性、功能完整性、无副作用SWE-bench Verified、Terminal-Bench研究型有依据性、覆盖度、来源质量、综合性DeepResearch Bench、结构化质检GUI 型任务完成度、操作正确性、状态验证WebArena、OSWorld多 Agent 协作型路由、协同、交接、整体完成率子 Agent 评测 端到端评测2.4 对话型 Agent 的特殊性客服、导购、售后等对话型 Agent 不能只看单轮答案必须把整段会话是否解决问题作为主评判对象。它至少有五个特殊难点上下文依赖单轮 OK、整段像失忆、目标动态变化用户中途改需求、业务流程约束要按 SOP/合规话术推进、情绪与体验客诉时不能机械回答、人机协同该转人工时要转并带上问题摘要。正确做法是同时看 Turn单轮、Session整段、Trace轨迹、Outcome最终结果 四个层次而不是简单平均每轮分数。三、指标体系设计指标的作用是把业务目标和专家经验拆成可观察、可打分、可追踪的检查项。建议分五大类并按优先级用于不同场景P0 用于上线门禁不达标不能发P1 用于版本比较和工程优化P2 用于体验改善和长期观察。维度核心问题示例指标优先级功能正确性做对了吗任务完成率、答案准确率、工具调用准确率、参数正确率P0稳定性与安全会不会闯祸幻觉率、越界承诺、隐私泄露、拒答正确率P0过程质量路径合理吗计划质量、工具顺序、重试次数、无效步骤占比P1效率与成本划算吗平均轮次、耗时、Token 成本、工具调用次数P1体验与对齐用户感受好吗语气自然度、情绪承接、品牌风格、满意度P2设计三原则可量化每个指标有明确评分标准避免感觉好不好、可复现相同输入不同执行得到一致结果、可迭代指标随业务演进。评分需归一化到 [0,1]例如分制用Score(实际得分-1)/(N-1)、比例制直接取比例值、阈值制达标记 1.0 超标按梯度折算。3.1 一致性度量Passk vs Pass^k对任务执行型和生产级对话型 Agent要特别重视多次运行的一致性同一任务重复跑 N 次观察两类结果Passkk 次至少成功一次衡量能力上限——Agent 是否具备完成该任务的可能性。Pass^kk 次全部成功衡量稳定可靠性——生产系统支付、退款、合规、医疗更关心这个。用户不会接受多试几次总有一次成功。举例一个模型 Pass10 是 95% 但 Pass^10 只有 60%意味着它有 40% 概率在连续 10 次查询中至少犯一次错——对安全敏感应用不可接受。3.2 版本对比要做统计检验在版本对比场景不能把随机波动误判为能力变化。报告中建议同时给出关键指标的置信区间、与基线版本的显著性判断、最小可感知变化阈值提前定义至少提升多少才值得发布。门禁不只看差了多少还要看这个差异是否超过统计噪声。四、评分器Grader/Scorer三层评估体系不管评测哪个场景都遵循同一套分层方法论。核心原则一句话脚本产出事实LLM 基于事实判断。 能写成代码的确定性指标绝不让 LLM 去估算。┌─────────────────────────────────────────────────────────┐ │ 第一层 · 确定性计算规则/脚本 Scorer 覆盖 60-70% │ │ JSON Schema 校验、工具参数合法性、状态变更、敏感词 │ │ → 快速、便宜、可复现、零争议 │ ├─────────────────────────────────────────────────────────┤ │ 第二层 · 语义判断LLM-as-Judge切片评估 │ │ 相关性、完整性、情绪承接、策略合理性、事实忠实性 │ │ → 基于第一层产出的事实做判断而非凭空推理 │ ├─────────────────────────────────────────────────────────┤ │ 第三层 · 门禁Gate对抗性校验 │ │ 一致性门禁、置信度门禁、Schema 校验、边界校验 │ │ → 挑战 Agent 的输出不通过就拦截/重试/标记低置信 │ ├─────────────────────────────────────────────────────────┤ │ 第四层 · 人工抽检Human Scorer校准锚点 │ │ 高风险、低置信、规则与 Judge 冲突、业务口径未固化的样本 │ │ → 黄金标准反向校准 Judge 的 Prompt 和根因标签 │ └─────────────────────────────────────────────────────────┘三类评分器对比类型适用场景优点风险代码/规则 Scorer结构、字段、数值一致、工具状态、敏感词稳定、便宜、可复现覆盖不了复杂语义LLM-as-Judge相关性、完整性、情绪、策略、忠实性可扩展接近专家判断有偏差、会漂移、需校准Human Scorer业务口径未固化、高风险、争议 case最接近业务共识成本高、规模小4.1 LLM-as-Judge 的偏差与治理LLM-as-Judge 并非银弹。已知问题包括位置偏差倾向选先出现的答案、自我偏好倾向给自己风格的答案高分、长度偏差更长的回答获得更高分、校准困难不同 Prompt 下评分分布差异大。一个能用的 LLM Judge 至少需要明确的评分标准每档有可执行标准、输出 reason便于定位和 badcase 聚类、few-shot 示例含边界样本和判定 COT、周期性校准。缓解策略包括多轮投票、成对比较A vs B 且交换位置消除位置偏差、校准锚点、分层评测、引入多个不同 LLM 对抗打分。校准指标定期抽取 50-100 个判定案例交由领域专家盲审计算 Judge 与人类的一致性Cohens Kappa。Landis Koch (1977) 的经典分级可作行动依据Cohens Kappa (κ)一致性等级对应行动κ ≤ 0.20轻微评分标准存在严重歧义需重新设计0.21 – 0.40一般增加 few-shot、细化维度定义0.41 – 0.60中等可初步使用需频繁人工复核0.61 – 0.80显著可投入使用定期抽样复核0.81 – 1.00几乎完美可信赖地用于自动化评估业界共识Hamel HusainStart with assertions, graduate to LLM-as-Judge only when you must. 先从最简单的、基于断言的评测开始只有当简单方法不够用时才引入 LLM-as-Judge。同时建议先做 error analysis 再搭基础设施——每次重大改动后花 30 分钟人肉看 20-50 条输出往往比纠结技术栈选型更有价值。4.2 过程型 / 风险型检查抓假阳性对最终回复看起来对、但过程有问题的假阳性 case追加四类检查检查类型检查内容示例必要路径检查必须调用的工具/步骤是否出现退款结论前必须调用 order.query禁止路径检查禁止提前执行的动作/话术是否出现未确认订单状态就承诺一定退款证据一致性检查最终回复是否有 Trace 证据支持回复说已发货但 Trace 无查询记录风险信号检查高风险动作、敏感承诺、隐私暴露、接管缺失投诉升级未转人工评分结果不应只输出 pass/fail还应输出问题分类、问题现象、置信度、判定依据这样后续根因定位才能基于现象入口收敛候选模块。五、评测数据集建设评测集不是线上数据的随机抽样而是围绕高风险路径、关键逻辑和失败模式设计出来的质量资产。纯随机采样有明显幸存者偏差——正常流程占多数真正让 Agent 出错的边缘场景占比很低报告看起来不错但关键问题被漏掉。数据集四类来源来源说明价值注意点专家设计用例专家定义核心场景、期望行为、判分标准锚定业务共识作为基准数量不必大但要覆盖关键流程和高风险边界扩展用例基于专家用例扩展不同说法、边界、异常组合扩大覆盖面补长尾结构字段用规则语言表达用 LLM线上真实数据从真实对话、工单、执行记录抽取贴近真实分布按场景和风险分类抽样不能纯随机badcase 回流线上失败、人工质检问题回收成用例最贴近真实失败要沉淀失败原因和修复状态落地建议先做 50-200 条高质量 golden set基线集用于版本对比和发布门禁覆盖核心业务路径和高风险边界成熟后再扩展到分类采样集、长尾集、对抗集、线上回流集。用例数量可按 Agent 等级分档Agent 等级最低用例数场景覆盖要求P0≥ 100 条覆盖所有核心意图每个意图 ≥ 10 条P1≥ 50 条覆盖主要意图每个意图 ≥ 5 条P2≥ 20 条覆盖核心场景所有用例必须完成打标覆盖正常场景、边界场景和异常场景。历史 Bad Case 必须沉淀为评测用例。六、Badcase 分析与根因定位根因定位的核心是把错例稳定追到责任模块和可修复原因。端到端失败通常只是表象真正原因可能来自意图识别、上下文记忆、检索召回、工具选择、参数构造、业务规则理解、模型推理、回复生成、Guardrail 拦截或外部系统异常。RCA 通用链路先收集证据、再收敛范围、最后定责落盘① 证据汇总 → ② 范围收敛 → ③ 分模块诊断 → ④ 责任判定 → ⑤ 结构化落盘 按 traceId 问题现象×模块 逐模块读 规则模块结论 写入任务记录 汇总全链路日志 映射表缩圈 input/output 根因知识库定责 支持看板查询第二步范围收敛是关键——不要对全部模块无差别分析而是维护问题现象 × 功能模块映射表问题现象优先候选模块典型判断依据答非所问意图识别、Query 改写、知识筛选用户问题明确但回复偏题订单未澄清槽位抽取、上下文判断需要订单号时没追问或绑定错对象事实性错误FAQ 检索、知识筛选、回复生成知识库有正确信息但回复给出错误事实过度承诺风险识别、回复生成承诺超出权限或业务规则根因标签体系要稳定、可统计、能指向明确 ownerIntent 识别错误、Context 记忆错误、Retrieval 召回不足、Tool 选择错误、Tool 参数错误、Reasoning 错误、Policy/SOP 错误、Response 生成问题、System 异常。每类绑定解决角色运营可配置 / 算法需优化 / 工程需修复 / 业务需定口径并支持 badcase 聚类——同一根因、同一场景、同一工具的失败自动聚成问题簇报告里产出退款已发货场景中 Agent 23 次跳过订单状态校验主要集中在 v1.8 Prompt这样的可行动结论。七、Agent-as-Judge从函数调用到Agent 执行当评测对象是自由文本或复杂多步骤行动序列时纯 LLM-as-Judge 有四个结构性局限只能推理不能执行无法主动取文件、跑脚本、补证据、上下文是硬约束多文件信息一个 Prompt 装不下、多维度互相干扰一次调用评多维每个都马马虎虎、确定性指标不该用推理来做相似度、覆盖率有公式让 LLM 估算是误用。Agent-as-Judge 把评测流程的编排权从平台硬编码的 workflow 交给 Skill 文件让 Agent 在运行时自主执行。三个核心组件┌──────────────────────────────────────────────────────┐ │ Agent-as-Judge │ │ │ │ ┌────────────┐ ┌────────────┐ ┌─────────────┐ │ │ │ Sandbox │ │ Agent │ │ Skill │ │ │ │ 隔离执行环境 │◄─►│ 推理行动内核│◄─►│ Markdown 评测│ │ │ │ Bash/Python│ │ 多步决策 │ │ 逻辑载体 │ │ │ │ 文件系统 │ │ 异常处理 │ │ 可 diff/回滚 │ │ │ │ 用完即销毁 │ │ │ │ 能力可插拔 │ │ │ └────────────┘ └─────┬──────┘ └─────────────┘ │ │ │ │ │ ┌───────────┴───────────┐ │ │ │ SubAgent 多任务并行 │ │ │ │ 代码评审 / 知识召回 / │ │ │ │ 确定性指标脚本 分头干活 │ │ │ └───────────────────────┘ │ └──────────────────────────────────────────────────────┘SubAgent 并行的收益不只是省时间更重要的是把判断隔离开——每个 SubAgent 只处理一个窄问题上下文更干净、Prompt 更短、互相污染更少。复杂评测从一个模型憋出一个总分变成一组评测工程师分头干活再开会对结果。Skill 模式相比硬编码 workflow 的宽容度优势LLM-as-Judge 是一锤子买卖错了就是错了Agent-as-Judge 有试错空间——结果矛盾可以自查门禁不通过可以换路径。评测系统最重要的两样核心资产随之明确评测数据集定义评什么决定覆盖面上限 评测 Skill定义怎么评是可 diff、可 code review、可 rollback 的 Markdown 文件决定准确度和一致性。代价要认清慢沙箱冷启动 3-5 分钟单条样本 10-20 分钟、贵沙箱资源 多次 LLM API、Skill 工程是手艺活、Agent 行为有不确定性。什么时候用需要做点什么跑代码、查数据、对比文件才能给结论 → Agent-as-Judge看一眼就能判断文本流畅度、语法、情感分类→ LLM-as-Judge又快又便宜。八、工程落地全链路过程数据采集以 AgentScope 为例评测的前提是拿到 Agent 执行全链路的过程数据。AgentScope Java 框架基于 ReActAgent 范式将推理→行动→再推理循环抽象为 ReasoningPipeline 和 ActingPipeline 两条管线并在关键节点暴露 Hook 扩展点。核心设计原则是主链路零干扰Hook 只读事件数据不修改 Prompt/工具/Memory全局 try-catch 吞掉所有异常评测挂掉不能阻断 chat执行耗时相对 LLM 推理微乎其微。Hook 接口与生命周期事件public interface Hook { /** 优先级数值越小越先执行默认 100 */ int priority(); /** 事件处理入口返回 MonoT 支持响应式编排 */ T extends HookEvent MonoT onEvent(T event); } // 生命周期事件 // PreCallEvent —— 输入消息列表记录开始时间、提取用户输入 // PostReasoningEvent—— 推理消息Thinking/Text/ToolUse Block、Token 用量 // PreActingEvent —— 即将执行的工具工具名、参数、调用 ID开启计时 // PostActingEvent —— 工具 执行结果封装完整调用记录 // PostCallEvent —— 调用链路结束组装评测数据并投递 // ErrorEvent —— 异常信息标记后阻断上报统一的评测数据模型结构化封装供 Judge Model 评判Data public class LLmAsJudgeSyncMessage { private Msg currentMessage; // 当前用户输入 private ListMsg historyMessages; // 历史会话 private String sysPrompt; // 系统提示词 private ListSkill skillCandidates; // 挂载技能集评意图/技能选择合理性 private ListTool toolCandidates; // 挂载工具集 private String thoughts; // 思考过程思维链 private String knowledge; // 知识库内容评忠实性/幻觉 private ListToolCallRecord toolCalls; // 实际工具调用轨迹 private String output; // AI 最终回复 private Long firstTokenCostMs; // TTFT 首 Token 耗时 private Long totalCostMs; // 链路总耗时 private Long inputTokens, outputTokens, totalTokens; // Token 消耗 private String judgeScene; // 评测场景技能组合等效替代 }分场景采样控制成本一次调用加载的技能 ID 组合按字典序|拼接作为业务场景无技能加载则为 DEFAULT每个场景独立配置采样率通过配置中心动态调整、无需发布。这样既保证覆盖所有场景又控制评测成本private static boolean shouldSample(String scene) { int rate SystemSwitch.getEvalSamplingRateByScene(scene); if (rate 0) return false; if (rate 100) return true; return ThreadLocalRandom.current().nextInt(100) rate; }配套的六大评测维度覆盖理解→检索→执行→生成→安全→业务价值完整链路认知理解问题提取准确、意图/技能选择准确、检索推理知识准召率、是否幻觉、工具执行工具调用准确率、成功率、耗时、生成质量回复易读、指令遵从、安全围栏过度承诺检测、安全风险检测、业务端到端问题解决率、首字响应延迟。九、流量采集与回放解决评测环境稳定性Agent 评测有一个独特痛点上下文依赖的底层数据会变化。Agent 执行工具调用时查询单据数据而单据状态随业务流程不断变化待发货→已发货→已签收相同用例在不同时间执行会因数据状态不同产生不同结果导致评测结果不可复现。解法是流量录制 Mock 回放录制线上真实流量自动生成评测用例大幅降低构造成本把录制的方法调用输入输出作为 Mock 数据在评测时回放确保数据状态一致、结果稳定可复现。Mock 执行结果可视化为四种状态绿色成功且顺序正确、黄色成功但顺序不对、红色入参有误、灰色未执行便于排查 Agent 执行逻辑。十、经典 Benchmark 对照Benchmark场景主要测什么评分方式SWE-bench / Verified软件工程真实 GitHub issue 修复仓库测试通过率FAIL_TO_PASS PASS_TO_PASSTerminal-Bench命令行终端环境任务执行状态检查API-Bank / BFCLAPI/函数调用参数选择、调用顺序、结果处理JSON/调用精确匹配或执行结果WebArena真实网页任务多站点浏览、表单、购物环境最终状态与任务答案OSWorld桌面/操作系统GUI 操作、文件、应用工作流状态检查与任务完成率GAIA通用助手搜索、推理、多模态、工具组合最终答案准确率τ-bench / τ2-bench用户-工具多轮交互对话式业务流程、规则遵循用户模拟器 数据库状态AgentBench多环境 AgentWeb、数据库、命令行、游戏各环境成功率BrowseComp复杂搜索多网页浏览与约束验证答案约束核查DeepResearch Bench研究报告循证长报告事实性100 领域专家 RubricSWE-bench 之所以成为黄金标准正因为代码世界完美符合验证者定律的五条标准。其数据集结构清晰Input 是repo base_commit problem_statementExpected 是FAIL_TO_PASS PASS_TO_PASS两组需通过的单测评估器逻辑极简跑单测看红转绿但为不同 Repo 构建可运行的隔离环境不同语言、版本、依赖成本极高——这也印证了验证责任不会凭空消失只会被推到另一层。十一、前沿趋势Meta-Harness自进化评测如果 Agent 可以自我改进评测系统本身也应能自我进化。反馈循环为Agent 执行 → 轨迹采集 → 评测打分 → 优化器分析 → Agent 更新 → 再评测核心模块包括 Eval Engine、OptimizerDSPy/TextGrad、Test Case Evolver、Trace Store、Env Sandbox。SkillsBench把 Skill 作为独立变量评测过去 benchmark 把模型 Harness 提示词工具配置当整体只回答系统做得好不好却不回答Skill 本身是否真带来增益。SkillsBench 显式拆出 No Skills / Curated Skills / Self-Generated Skills 三种条件实验显示精选 Skill 把平均通过率从 33.9% 提升到 50.5%。关键新指标包括负迁移率多少任务加 Skill 后反而变差——并非所有 Skill 都正收益边界模糊的 Skill 会把原本做对的任务带偏。Rollout Cards可复现性标准只汇报成功率 80%会掩盖大量真相——模型是否在文本伪装安全却乱调工具、失败重试是否烧爆算力、长序列搜索是否在做无用功。执行轨迹记录才是 Agent 研究可复现性的基本度量单位。姚舜禹《AI 的下半场》评测与现实世界存在两个根本差异——评测假设 iid 独立同分布但真实任务是顺序解决、可积累熟悉度、评测假设自动化无人介入但真实 Agent 需与人持续交互。下半场需要的不是更难的考试而是让 Agent 作为实习生入职考察实际工作表现。十二、全链路闭环从 Bug 到生产反馈评测平台的终点不是报告而是把线上失败持续转化为可复用的研发资产。一条 badcase 至少可以生产三类反馈回归用例防止同类问题再现、Prompt/工具改进建议修复当前行为、业务规则/知识库修订修正源头。反馈生产要有入库标准不能把所有失败都无差别塞进回归集失败可复现、期望行为明确、根因标签清楚、样本有代表性、已完成脱敏。同时做样本治理避免回归集无限膨胀同簇样本保留代表例、P0/P1 长期保留、稳定多版本通过的低风险样本降级为抽样集。发布阶段要把离线门禁和线上灰度联动跟踪三类信号离线质量信号核心场景通过率、P0 风险数、线上体验信号转人工率、重复追问率、投诉率、业务结果信号任务完成率、工单闭环率。如果离线提升但线上关键信号恶化应触发回滚或降级。评测优化建议要落到明确 owner、修复动作和回归验证可分四个等级L0 只报告 → L1 生成工单带样本、Trace、owner、验收标准→ L2 生成配置建议可审阅的规则/知识/Prompt 变更→ L3 自动修复候选 PR仍需人审和回归。十三、接入 SOP五阶段阶段目标关键动作① 评测规划明确范围、维度、质量目标确定 Agent 等级P0/P1/P2、梳理场景意图、定义标签、确定裁判规则、设定指标基线② 评测接入完成平台注册和技术接入创建项目、注册 Agent、配置评测 API、定义标签、配置指标阈值、可选接入流量录制 SDK③ 用例建设建立满足覆盖度的用例基线流量录制 / Excel 导入 / 手动创建全部打标覆盖正常边界异常④ 评测执行验证 Agent 质量达标创建任务、执行、看结果与 Mock 日志、分析报告、问题修复、回归验证⑤ 持续保障建立常态化机制发布前必测、定期回归、增量用例补充、用例淘汰管理、覆盖度季度审查裁判规则选择速查意图识别 → 简单裁判「等于」结构化主答案 → 简单裁判「等于/部分包含」自然语言主答案 → LLM 裁判「文本相似度」关键信息提取 → 简单裁判「部分包含」布尔判断 → 简单裁判「等于」。十四、结语Agent 的开发本质上是一场与不确定性博弈的过程而评测是这场博弈中最关键、也最容易被低估的能力。几条务实共识值得反复强调探索阶段0→1用 vibes-based 快速试错足够优化阶段1→N必须建立系统化评测生产阶段需要全自动化流水线 在线监控能用脚本算的绝不用 LLM 估能自动化的绝不长期依赖人工人工只用于定标准、校准 Judge 和高风险终判评测不是项目交付物而是长期资产——用例库、Trace 库、根因标签库、修复建议库、Judge 校准集、回归集质量资产越厚Agent 迭代越不靠个人经验和临时救火。正如 Eugene Yan 所言Evals arent static artifacts or quick fixes; theyre practices that apply the scientific method. 好的评测体系是对可验证性边界的诚实承认也是让每一次 Agent 迭代都看得见质量变化的底层能力。参考来源Anthropic, Demystifying Evals for AI Agents / Building Effective Agents — anthropic.com/engineeringJason Wei, Asymmetry of Verification and Verifiers Law / Successful Language Model Evals — jasonwei.net/blogHamel Husain, Your AI Product Needs Evals / LLM Evals: Everything You Need to Know — hamel.devEugene Yan, An LLM-as-Judge Wont Save The Product / Task-Specific LLM Evals — eugeneyan.comZheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena, NeurIPS 2023Jimenez et al., SWE-bench: Can Language Models Resolve Real-World GitHub Issues?, ICLR 2024Bean et al., Measuring what Matters: Construct Validity in LLM Benchmarks, NeurIPS 2025姚舜禹, The Second Half — ysymyth.github.io/The-Second-HalfMASEval / SkillsBench / Rollout Cards — arXiv 2026