最近要入职字节了，字节组里的内容可能会涉及到一些agent评测，我在美团做的也是工作流的相关内容，以我自己的视角来写一些对工作流评测的看法。
workflow/工具型 Agent 不是作文生成器，它更像一个“会调用工具的分布式系统”。你真正要测的是：任务闭环能力、过程可控性、异常可恢复性、安全边界、成本与性能。

这里我给出一套工程化、可落地的指标体系与测评方法，适用于：RAG agent、工具调用 agent、工作流编排 agent（workflow）、多轮对话 agent 等。

---

1. 先把测评对象说清楚：Agent 到底在“完成什么任务”

对 workflow agent 来说，最怕的不是“答得差”，而是“你根本不知道它算成功还是失败”。

在开始测评之前，为每一类任务写清楚：

• 输入规范：必填字段、可缺省字段、允许的自然语言表达范围
• 成功条件（硬验收）：能自动判定的完成条件
  例：创建工单成功 + 字段正确 + 返回工单ID；退款成功 + 账务一致 + 有审计记录
• 动作边界：允许做什么、不允许做什么（权限、审批、写操作范围）
• 可接受输出：格式、结构、引用要求（尤其 RAG）

如果你无法自动判断“这次是否完成任务”，后面所有分数都只是“感觉不错”。

---

2. 指标体系：别只看回答质量，要看“闭环 + 风险 + 成本”

2.1 任务结果层（Outcome）——“做成没”

核心指标：

• 任务成功率（Task Success Rate, TSR）：按明确成功条件判定
• 结果正确率 / 一致性：字段、数值、约束、业务口径是否正确
• 业务指标映射：例如降低人工进线率、提升转化率、减少工单流转时长等

测评方法：

• 给每类任务建立 自动验收器（verifier）：成功/失败/部分成功
• 定义硬性验收规则：不满足就 fail，别让“看起来差不多”过关

---

2.2 过程与推理层（Process）——“怎么做成的，有没有乱来”

对 workflow agent，这层比“语言好不好”更关键。

关键指标：

• 计划质量：步骤是否必要，顺序是否合理，是否遗漏关键步骤
• 工具调用正确率
  • Tool Precision：该调用才调用（不乱调用）
  • Tool Recall：需要调用就调用（不瞎猜）
• 参数正确率：API字段、ID、时间范围、权限参数是否正确
• 分支选择准确率（routing accuracy）：条件分支/路由是否走对
• 自我修复能力（Recovery）：失败后是否能重试、降级、换路径

测评方法：

• 打通 trace 记录：节点链路、工具调用、返回码、重试与fallback
• 给每个节点做 节点级断言（node-level assertions）
  例：检索节点必须返回≥K条候选且包含关键字段；写库节点必须返回200且落库可查

---

2.3 鲁棒性层（Robustness）——“脏输入、坏环境还能活吗”

关键指标：

• 异常输入鲁棒性：错别字、缺字段、矛盾信息、上下文污染
• 提示注入鲁棒性（prompt injection）：RAG内容/工具返回夹带恶意指令
• 工具故障鲁棒性：超时、500、限流、返回空、schema 变更
• 稳定性（Consistency）：同一输入多次运行波动（成功率、结果、路径）

测评方法：

• Fuzz / 变异测试：对同一用例做扰动（拼写、同义改写、字段缺失、顺序打乱）
• 故障注入（fault injection）：mock 工具超时/500/慢响应/空结果，观察是否按预期降级
• 多次运行统计：同一case跑 N 次，统计成功率方差与路径漂移

---

2.4 安全合规层（Safety & Compliance）——“别把公司送走”

关键指标：

• 越权与数据泄露：敏感信息、密钥、隐私是否外泄
• 策略遵循：是否遵循业务规则（审批、风控、退款改价等）
• 注入抵抗：能否识别并拒绝执行恶意指令
• 审计可追溯性：关键决策是否可追踪（触发者、数据来源、为何执行）

测评方法：

• 红队用例集：注入、社会工程、越权指令、数据外带（exfiltration）
• 权限矩阵：不同角色/租户/环境对同一任务的访问边界验证
• 输出扫描：敏感信息模式检测（token、手机号、证件号、access key等）+ DLP规则

---

2.5 性能成本层（Performance & Cost）——“跑得起吗”

关键指标：

• 端到端延迟（p50/p95/p99）：别看平均数自欺欺人
• 成本：token、工具调用次数、检索次数、外部API费用
• 吞吐与并发：并发下成功率是否下降、队列是否堆积
• 资源效率：重复检索、无效循环、无意义 tool-call

测评方法：

• 压测：不同并发下跑固定用例，观察延迟分布与失败类型
• 成本剖析：统计每节点 token/调用次数/耗时，定位“烧钱节点”

---

2.6 体验与可运营层（UX & Operability）——“能长期稳定跑吗”

关键指标：

• 可解释性：输出是否给出可验证依据/引用（尤其RAG）
• 可观测性：trace、日志、指标、告警是否完善
• 可维护性：流程/提示词/规则变更是否容易引入回归
• 回归风险：版本升级后成功率、成本、路径分布是否漂移

测评方法：

• 基线回归集 + 版本对比报告（diff report）
• 线上灰度/A-B：监控业务指标、安全指标与成本指标

---

3. Workflow Agent 的“专属必测点”（很多团队会漏掉）

1. 节点级正确性：每个节点有输入输出契约（schema），不符合直接 fail fast
2. 分支覆盖率：所有 if/else/路由必须被用例覆盖，否则上线等于开盲盒
3. 幂等性：重复触发不会重复扣费/重复下单/重复写库
4. 重试与退避：避免无限重试和雪崩（重试次数、间隔、熔断）
5. 回滚/补偿：写操作失败是否能补偿（事务/补偿任务）
6. 循环/卡死检测：最大步数、最大token、最大tool-call数的熔断限制

---

4. 测评落地流程：从“用例”到“门禁”的一条流水线

Step 0：定义任务验收标准（必须可自动判定）

• 每类任务明确成功条件与失败条件
• 明确动作边界与权限规则

Step 1：构建分层用例集（覆盖面 + 高价值失败）

建议至少包含：

• Happy path：标准成功流程
• 边界/异常：缺字段、冲突信息、极端数值
• 对抗/安全：注入、越权、诱导泄露
• 工具故障：超时/500/空结果/schema变更
• 长对话：多轮反复修改需求、上下文干扰
• 回归集：线上真实失败沉淀（最值钱）

别迷信“1000条随机用例”，一半是噪音；真正值钱的是 失败案例沉淀 + 可复现的回归集。

Step 2：建立自动验收器与打分器（Outcome + Process + Cost）

建议统一输出结构：

• outcome：success / partial / fail
• errors：失败原因枚举（参数错/工具错/分支错/幻觉/越权…）
• trace：节点序列 + tool-call 详情
• cost：token/调用次数/耗时/外部费用

Step 3：离线批跑 + 稳定性统计

• 每条 case 跑 N 次（3~10）
• 看：成功率均值、方差、失败类型分布、成本/延迟分布、路径漂移

Step 4：定位瓶颈并给出可行动改进

失败必须能落到“节点级归因”，否则只能开会聊天：

• 检索差：召回不足？排序差？query构造差？
• 工具差：schema不匹配？参数错？重试策略不对？
• 规划差：步骤遗漏？顺序错？循环？
• 安全差：注入没挡住？权限没校验？

Step 5：上线门禁（Gating）+ 上线后监控

门禁建议包含：

• 关键任务 TSR ≥ X
• 越权/泄露 = 0（硬门禁）
• p95 延迟 ≤ Y
• 单次成功成本 ≤ Z

线上监控重点：

• 成功率漂移与错误 TopN
• 工具失败率与重试率
• 成本异常（token/tool-call 暴涨通常是“开始瞎查”）
• 安全告警（注入命中、敏感信息命中）

---

5. 建议的“指标面板”（最小但很管用）

• Outcome：TSR、Partial Rate、可自动判定的幻觉率
• Process：Tool Precision/Recall、Branch Accuracy、Recovery Success
• Robustness：Fuzz 后 TSR、故障注入 TSR
• Safety：越权率、注入成功率、敏感泄露命中率
• Perf/Cost：p95延迟、平均token、平均tool-calls、单位成功成本（cost/success）

---

结语：把 Agent 当系统测，而不是当人测

workflow agent 今天像聪明助理，明天可能像会乱按按钮的小朋友——而且按钮还连着生产数据库。
测评要从“回答质量”升级为“验收 + 故障演练 + 回归门禁 + 线上监控”，才真的能上线、能长期跑。

---