外观
如何评估 Agent 的任务完成质量？
3 分钟速学卡
30 秒口述： 我会先把任务成功定义为可验证的最终状态，而不是模型自报“完成”，再从结果、过程、安全和效率四层评估 Agent。结果层看任务完成率和产物正确性，过程层看工具选择、参数、状态转移与恢复，安全层看越权和高风险动作，效率层看步数、延迟、Token、成本与人工接管。离线使用版本化任务集、确定性断言加人工/模型评审，线上用 Trace、失败分桶和抽样复核，并与单 Agent 或工作流基线做同条件对比。
- 本质： Agent 质量等于可验证结果、合理过程、安全边界和可接受成本的共同达成。
- 核心机制： 成功必须映射到外部真实状态；Trace 用于过程归因而非只做展示。
- 关键判断： Judge 需要人工校准；评测应与基线同条件比较并持续回归。
- 项目落地： 示例评测：工单 Agent 的成功条件是工单状态、必填字段和审批记录同时满足；同一任务集比较确定性工作流与 Agent 的成功率、P95 延迟、成本和人工接管率。
- 边界与坑： “看用户满意度就行。” 反馈稀疏且无法定位过程失败；“Agent 说完成就是成功。” 必须核验外部真实状态。
目录
面试官为什么问
考察指标口径、可验证终态、Trace 归因和从离线到线上闭环的能力。
小白先看懂
评价跑腿员不能只听他说“办好了”：要核对证件是否真的更新、路线是否合规、有没有泄露资料、花了多久和是否需要主管救场。
证件状态对应任务终态，路线记录对应 Trace，违规动作对应安全指标，时间费用对应效率。类比忽略了开放任务可能存在多个合格结果。
主题教学图片
图：教学图片｜如何评估 Agent 的任务完成质量？
替代文本： 围绕“如何评估 Agent 的任务完成质量？”组织的中文教学图，通过分区、箭头和标签解释核心机制。
读图结论： 不仅看做成没有，还要看怎么做、是否安全、代价多少。
这张图片用于建立主题机制的直觉。精确公式、参数、失败分支和事实边界仍以正文与 Mermaid 为准。
图片生成记录： model=gpt-image-2，generated=2026-07-15，prompt_version=v1，reviewed=2026-07-16，review_basis=user-confirmed；查看生成 Prompt。
图：架构｜Agent 四层评测与证据源
替代文本： 版本化任务集驱动 Agent 执行，最终状态断言评估结果，Trace 评估过程，安全规则评估越权，系统指标评估延迟成本，人工抽检校准开放任务。
图表加载中…
读图结论： Agent 评测必须把“是否完成”与“如何完成、是否安全、代价多少”一起纳入。
最终状态优先通过 API、数据库或文件校验；模型 Judge 适合语义质量，但需人工样本校准，不能替代确定性业务断言。
核心原理
任务完成率应先定义分母、验收门槛、时间窗口和分桶。轨迹指标不是越短越好：需要最少但充分的步骤；可记录无效工具率、重试率、恢复成功率和正确终止率。
项目和生产视角
示例评测： 工单 Agent 的成功条件是工单状态、必填字段和审批记录同时满足；同一任务集比较确定性工作流与 Agent 的成功率、P95 延迟、成本和人工接管率。没有运行数据时只报告评测设计。
线上将失败按规划、工具、权限、状态、恢复和评审误差分桶，代表性样本回灌前做去重、脱敏和版本标注。
常见错误回答
- “看用户满意度就行。” 反馈稀疏且无法定位过程失败。
- “Agent 说完成就是成功。” 必须核验外部真实状态。
- “步骤越少越好。” 可能省略必要验证或安全检查。
递进追问
- 如何为开放研究任务定义成功？
- 确定性断言与 LLM Judge 怎样分工？
- 如何避免评测集被 Prompt 或开发者污染？
- 多 Agent 的信用如何归因？
关联阅读
总结
一句话记忆： Agent 质量等于可验证结果、合理过程、安全边界和可接受成本的共同达成。
- 成功必须映射到外部真实状态；
- Trace 用于过程归因而非只做展示；
- Judge 需要人工校准；
- 评测应与基线同条件比较并持续回归。