| 发布渠道:微信公众号 腾讯程序员 | 发布日期:2026-06-17 | 编译时间:2026-06-17 |
测评是 Agent 从 Demo 可用走向生产可靠必须跨过的门槛。 腾讯 TEG 网关测试团队给出”三类评分器 + 五大维度 + 5 步闭环”完整框架,核心理念是”Agent/Skill 设计阶段就要把 Trace 输出作为标准能力纳入,而非事后补救”。最反直觉的一条:过度触发比不触发更难发现,所以负向触发用例比正向触发更重要。
| 节点 | 一句话定义 | 关键洞察 |
|---|---|---|
| 三类评分器 | 确定性(代码判断)/ Rubric(模型按规则打分)/ 人工(校准) | 优先级:确定性 > Rubric > 人工;”能用代码判断的绝不用模型” |
| 五大评测维度 | 功能正确性 / 过程质量 / 效率成本 / 鲁棒性安全 / 体验对齐 | 5 个维度覆盖 Agent 全部风险面;不同维度用不同评分器 |
| 用例基线 Baseline | 单个用例执行 1 次后,经人工确认的预期过程和预期结果快照 | 后续每次执行都参考基线评分;基线变更触发用例集重审 |
| 结构化 Trace 输出 | 每行独立解析、可按 type 过滤工具调用或思维链 | 过程评测的前提;Agent/Skill 设计阶段就该纳入 |
| 三类 Agent 测评侧重 | 知识库问答类(Rubric)/ 功能工具类(过程对比)/ Skill 类(用例量最大) | 不同 Agent 类型,评分器选择 + 用例量 + 容忍阈值都不同 |
| 负向触发用例 | “什么时候不应该触发”的用例 | 防止”什么都触发”;只测正例,Agent 会学会走捷径 |
| 用例设计 5 步闭环 | 设计 → 评分规则 → 基线 → 执行 → 维护 | 实施层的标准 SOP,缺一环则评测体系不完整 |
| 稳定性评估 | 多轮执行(N 次)检测幻觉和不通过比例 | N 次中 1 次不通过即标为存在稳定性风险;阈值因 Agent 类型而异 |
1. 三大痛点 — 为什么 Agent 必须做测评。 (1) 非确定性:同 prompt 多次执行结果不同,”跑通一次”不代表”稳定能跑”;(2) 黑盒化:模型升级 / Prompt 微调 / 工具链变化都可能导致行为漂移,肉眼难以察觉;(3) 错误级联放大:Agent 的”自主行动链”导致单点错误会沿着链路放大,不像传统软件可以单点定位修复。反问:你的 Agent 现在处于”跑通一次就好”,还是”已有基线 + 评分规则 + 多轮验证”?
2. 三类评分器 + 优先级 — 不是所有评分都要 LLM 做。 确定性评分器(工具调用序列是否一致 / 产物文件是否存在 / token 数是否超标)、Rubric 评分器(模型按规则对比基线打分)、人工评分器(校准和模糊维度)。选择优先级:确定性 > Rubric > 人工——”能用代码判断的绝不用模型,必要时用模型,人工用于校准”。Seetong 借鉴:seetong-daily-briefing 的”反馈类型聚类 / 网络错误 -102 命中”完全可以用确定性评分器。
3. 五大维度 — 覆盖 Agent 全部风险面。 (1) 功能正确性:任务是否完成、产出是否符合预期;(2) 过程质量:工具调用序列是否合理、有无冗余、是否有幻觉;(3) 效率成本:token 数、调用次数、响应时间;(4) 鲁棒性安全:错误处理、边界输入、注入攻击;(5) 体验对齐:输出风格、人机交互、用户满意度。Seetong 借鉴:Seetong Skill 自进化现在只关注”成功率”,缺过程质量 + 鲁棒性 + 体验对齐。
4. 三类 Agent 侧重不同 — 没有一套通用评测。 知识库问答类(更依赖 Rubric 评分器判断回答质量、检测幻觉)、功能工具类(更关注过程对比——工具调用序列是否与基线一致)、Skill 类(用例量最大,需覆盖所有核心分支)。Seetong 借鉴:Seetong-KMP 跨端 Skill 是”功能工具类”,Seetong-TAPD 简报是”知识库问答类”,Seetong-Agent 漏洞归类是”Skill 类”,三者评分器选择不同。
5. 用例设计 5 步闭环 — 实施层 SOP。 3.1 设计测评用例集(覆盖所有核心分支路径)/ 3.2 设计评分规则(确定性规则 + Rubric 规则)/ 3.3 建立用例基线(人工确认的预期快照)/ 3.4 执行测评(自动化流水线)/ 3.5 维护用例集(Agent/Skill 变更 → 同步调整用例)。Seetong 借鉴:把这个 5 步闭环作为 Seetong 内部 Skill 上线的标准 SOP。
6. 负向触发用例 — 过度触发比不触发更难发现。 只测正例,Agent 可能学会”什么都触发”——过度触发比不触发难发现得多。Seetong 借鉴:每个 Skill 必须配”什么时候不应该触发”的负向用例(seetong-clarify 的”信息足够时不要澄清”就是负向用例;seetong-execute 的”任务不在能力范围时拒绝执行”也是)。
7. 用例基线 Baseline — 评测体系的锚点。 “单个用例执行 1 次后,经人工确认的预期过程和预期结果的快照”。后续每次执行都参考基线评分;基线变更触发用例集重审。Seetong 借鉴:seetong-daily-briefing 现在的”反馈清单”还不是”基线”,需要把”标准简报结构”沉淀为基线,作为后续改版对照锚点。
8. 结构化 Trace 输出 + 稳定性评估 — 工程落地的两件套。 Trace(执行轨迹)是 Agent 每一步工具调用、参数、返回值、思考过程的结构化日志,是过程评测的前提。操作:在 Agent/Skill 设计阶段就把 Trace 输出作为标准能力纳入,而非事后补救。稳定性评估:多轮执行(N 次)中只要 1 次不通过,就标记为存在稳定性风险;不通过比例阈值因 Agent 类型而异。Seetong 借鉴:Seetong skill 流程默认不输出 trace,需要补;worktree 模式可参考 Loonggg 2026-06。