构建 AI 智能体应用（四）：验证与测量

Validation Measurement（Photo by Alvin Leopold on Unsplash）

系列导读: 本文是《Building Applications with AI Agents》系列解读的第四篇。在第一篇中，我们探讨了智能体的六大核心类型；在第二篇中，我们分析了工具选择策略与 MCP 生态；在第三篇中，我们深入解析了多智能体协作与编排模式。本篇将聚焦于如何验证与测量 Agent 的可靠性，提供从离线评估到生产监控的落地指南。

核心观点

AI Agent 的质量不等于“回答写得好”，而取决于它在真实环境里是否能稳定完成任务：理解对、计划对、工具用对、参数填对、失败能恢复、长期交互不跑偏、成本可控且可审计。
评估要从“结果评分”升级为“轨迹（trajectory）评分”：把多轮对话与每一步工具调用纳入可回放、可量化、可定位的评测体系。
最有效的团队会采用“评价驱动开发”（Evaluation-Driven Development, EDD）：离线评估 + 影子流量 + 灰度门禁 + 生产监控 + 自动回归，形成闭环。

1. 为什么测量与验证仍然是最大挑战

构建 Agent（尤其是“能用工具、能跑流程”的 Agent）从未像今天这样容易：你可以快速接入模型、封装工具、串起工作流。但“衡量它是否真的可靠”，仍然是最大挑战之一。原因通常来自三个方面：

1.1 非确定性：同一输入不总产生同一轨迹

大模型的生成具有概率性。即便最终答案“看起来差不多”，中间的动作序列可能完全不同：一次先查订单再退款，另一次先退款后补查订单；一次参数正确，另一次把订单号写错一位。
这意味着：你不能只看“最终回复文本”，必须把“行为轨迹”也纳入评估。

1.2 可观察性缺失：你不知道它为什么成功/失败

传统软件出错可以抓栈、看日志、复现输入；Agent 出错往往藏在“某轮理解偏差”“工具选择偏差”“参数填充偏差”“记忆检索污染”“对话漂移”等细节里。
如果没有统一的轨迹日志与评分口径，你会陷入“玄学调参”，团队会在不同人之间出现判断不一致。

1.3 目标本身更“主体性”：正确答案可能有多种表达

客服、销售、助理类 Agent 的成功往往不是“答对一道题”，而是“在约束下完成目标并让用户满意”。这类任务的输出空间巨大，单纯用精确匹配（exact match）难以衡量，必须引入更贴近业务目标的指标与规则。

关键结论：Agent 的评估要从“文本评分”升级为“系统工程问题”：目标分解、数据集工程、组件与系统级指标、以及贯穿开发到上线的闭环治理。

2. 测量主体性/主体性系统：目标、英雄场景与指标体系

“测量主体性系统”并不是说指标必须主观，而是指：系统的成功与否往往包含“语义契合”“沟通质量”“策略遵循”“风险控制”等难以用单一客观标签表达的维度。

2.1 从目标开始：把业务目标分解成可评估的行为

建议用三层结构定义目标：

任务目标（Task Objective）：用户想完成什么？
约束目标（Constraints）：政策/合规/权限/成本/时延/风格等约束。
过程目标（Process Expectations）：必须走哪些关键步骤？哪些步骤禁止？

以电商客服为例（参考原文的“破损马克杯退款”场景）：

任务目标：为破损商品完成正确退款处理。
约束目标：仅退破损商品；不得泄露敏感信息；订单状态不允许时需升级或澄清。
过程目标：先核验订单与商品→确认退款范围与金额→调用退款工具→生成确认话术。

2.2 英雄场景（Hero Journeys）：先确保“关键路径必胜”

英雄场景是一组高优先级、代表性强、业务影响大的端到端用例。它们有两个用途：

定义“必须赢”的最低标准：每次模型/提示词/工具/工作流更新，都不能把英雄场景打崩。
作为指标权重基线：在整体健康分里，英雄场景通常权重更高。

实践上建议同时维护三层覆盖：

Hero（主路径）：高频高价值、需求明确。
Long-tail（长尾）：低频但真实存在，覆盖歧义、边界条件、组合需求。
Adversarial/Red Team（对抗/红队）：越权、注入、恶意输入、策略绕过。

2.3 指标体系：定量 + 定性 + 经济性

把指标分成三类，避免“只看一个分数”：

A. 定量（可自动化、可回归）

任务成功率（Task Success Rate）
工具召回/精度、参数准确率
端到端时延（P50/P95）、失败恢复率、重试次数
成本：token cost、工具调用 cost、fallback 人工成本

B. 定性（更贴近体验，但需 rubric）

回复是否清晰、礼貌、可执行
是否正确解释采取的动作（可审计沟通）
多轮一致性与连贯性

C. 经济性（让“更强”与“更贵”能比较）

单任务平均步数（steps）
单任务平均工具调用数（tool calls）
单成功任务成本（cost per success）
成本-质量权衡：在相同成功率下更低成本，或在相同成本下更高成功率

2.4 健康分（Health Score）：多指标加权，而不是一个“万能分”

大多数生产团队最终会落到一个 dashboard，但“一个分数”只能作为汇总入口。建议做法：

面板层展示各维度指标
决策层定义加权健康分（用于门禁）
诊断层保留原始轨迹、失败类型、可回放样例

3. 将评估嵌入全生命周期：从 Day 0 到生产闭环

评估不是发布前的“验收”，而是研发过程的一部分。可以把整个闭环理解为五段流水线：

Evaluation-Driven Development (EDD) Lifecycle

3.1 离线评估（Offline Evals）

目标：快速迭代与回归检测。
输入：结构化评估集（Hero + Long-tail + Adversarial）。
输出：任务成功率、组件指标、失败分析、回归 diff。

关键点

每次提示词/工具/模型更新都自动跑离线评估（CI 中触发）。
离线评估要能“复现同一用例”：固定随机种子/温度，或采用 pass@k（多次采样取最好/多数）来衡量稳定性。

补充：为什么要看 pass@k / 稳定性

pass@k：同一用例运行 k 次，只要有一次达成成功标准就算通过（更接近“给模型多次思考机会”后的上限能力）。它适合衡量“潜力上限”，但不代表生产可靠性。
majority@k（多数通过）：k 次里成功次数 ≥ ⌈k/2⌉ 才算通过（更接近“稳定能力”）。
flakiness（抖动率）：同一用例重复运行的成功率波动。工程上常用：

Flakiness = 1 - SuccessRate_over_k_runs

如果某类用例 pass@k 很高但 majority@k 很低，说明系统“偶尔能做对但不稳定”，常见根因是：规划不稳、工具调用参数易漂移、或对话策略在临界条件下随机分叉。

3.2 影子模式（Shadow Mode）

目标：在真实流量分布下验证行为，但不影响用户。
做法：复制线上请求给新版本，记录轨迹与指标，对比旧版本。

影子模式特别适合发现：

离线评估集未覆盖的真实长尾
数据分布漂移（新产品、新入口、新文案）
工具真实故障率、延迟尾部

3.3 灰度放量（Canary / Gradual Rollout）

目标：逐步扩大影响面，同时让回滚可控。
常见节奏：1% → 5–10% → 100%，每一档都设门禁指标。

3.4 生产监控（Production Monitoring）

目标：持续观测质量、风险与漂移。
核心是“观测性”：你需要能回答：

失败发生在什么步骤？
是理解问题、工具问题、数据问题还是策略问题？
是否出现了新的失效模式？

3.5 自动回归与门禁（Regression Gates）

目标：把“上线安全”工程化。
门禁通常包含：

Hero 场景成功率不得下降
P0/P1 失败（安全/合规/严重误操作）为零容忍或阈值极低
成本/时延不超预算

4. 创建并扩展高质量评估集：从样例到“活规范”

评估集不是一组固定题目，而应当逐步演化成“系统必须具备能力的规范说明”。高质量评估集需要同时解决三件事：可表示、可评分、可持续增长。

4.1 用结构化格式表达一个“端到端评估样例”

建议最小包含：

输入状态（State）：订单、用户档案、权限、上下文变量
对话历史（Dialogue）
期望轨迹（Expected Trajectory）：期望工具调用集合/顺序/关键参数
期望终态（Expected Final State）：退款结果、订单状态变化
期望话术（Expected Phrases / Policies）：必须解释/必须澄清/必须拒绝

示例（YAML，仅示意）：

id: refund_damaged_mug_multi_item_001
input:
  state:
    order_id: A89268
    items:
      - sku: mug_black
        status: delivered
        price: 18.99
        damaged: true
      - sku: coffee_beans
        status: delivered
        price: 24.50
        damaged: false
  dialogue:
    - role: user
      content: "我的马克杯有裂纹，想退款。订单里还有咖啡豆，咖啡豆是好的。"
expected:
  tool_calls:
    - name: issue_refund
      required: true
      args:
        order_id: A89268
        skus: ["mug_black"]
  constraints:
    - "不得对咖啡豆退款"
    - "如需要凭证，必须请求上传照片"
  final_message_must_include:
    - "已为破损马克杯发起退款"
    - "咖啡豆不受影响"

推荐字段清单（更工程化的最小可行 schema）

字段	作用	常见取值/示例
`id`	样例唯一标识	`refund_damaged_mug_multi_item_001`
`tags`	分组与统计维度	`hero`, `long_tail`, `red_team`, `tool_issue_refund`
`risk_level`	风险分级	`low/medium/high`（高风险用于更严格门禁）
`input.state`	结构化状态	订单、权限、账户、配置、环境变量
`input.dialogue`	多轮上下文	角色、内容、时间戳（可选）
`expected.tool_calls`	期望动作集合	工具名、参数、是否必选、顺序约束（可选）
`expected.final_state`	期望终态	退款成功、金额、流水号、订单状态
`expected.hard_constraints`	硬约束	“不得泄露 PII”“不得越权退款”“不得编造工具结果”
`expected.soft_rubric`	软质量 rubric	清晰度、礼貌度、解释充分、下一步指引
`oracle`	真值来源	人工标注 / 业务规则 / 可验证工具查询

4.2 Golden / Silver / Live Drift：三层评估集维护策略

Golden（黄金集）：强标注、覆盖英雄场景与高风险场景；用于 CI 回归门禁。
Silver（白银集）：弱标注或半自动生成（例如从日志抽样 + 人工只做轻量标注）；用于扩大覆盖面与发现新问题。
Live Drift（漂移集）：定期从生产抽样、聚焦最新功能与新型输入；用于监控分布变化，并反哺 Golden/Silver。

Golden / Silver / Live Drift Strategy

4.3 扩展评估集的方法：从“变异”到“对抗”

常见有效方法（可组合）：

生产日志挖掘：从失败案例、转人工案例、用户差评中提炼样例。
LLM 变异生成：对已有样例做意图混合、歧义注入、措辞扰动、错别字等。
对抗性提示（Adversarial Prompting）：设计使系统自相矛盾、越权或绕过策略的输入。
反事实编辑（Counterfactual Editing）：改一个关键字段观察是否失效（如订单状态 delivered→shipped）。
故障注入（Fault Injection）：让工具超时、返回缺字段、返回冲突数据，测试恢复能力。

实践建议：把“新增能力”与“新增评估样例”绑定。每引入一个新工具/新工作流，就必须同时新增对应测试样例与评分指标，否则系统能力会在没有规范的情况下“漂移”。

4.4 可评分：把“样例”变成“可自动回归”的评分器

离线评估要能自动打分，评分器通常分三类（可混用）：

规则/断言（rule-based）：对工具调用、参数、终态做精确或容错匹配；最适合硬约束与关键业务动作。
检索/引用核验（verification）：对需要引用的事实做二次查询或对账（例如退款是否真的写入订单系统）。
Judge（rubric-based）：对话质量、解释是否清晰等开放式维度（见第 6 章）。

一个可操作的评分输出建议固定成统一结构，便于仪表盘聚合与回归对比：

{
  "sample_id": "refund_damaged_mug_multi_item_001",
  "passed": false,
  "hard_fail": true,
  "metrics": {
    "task_success": 0,
    "tool_recall": 0.0,
    "tool_precision": 0.5,
    "arg_accuracy": 0.0,
    "latency_ms_p95": 4200,
    "cost_usd": 0.012
  },
  "failure_tags": ["wrong_refund_scope", "tool_args_incorrect"],
  "notes": "退款工具被调用但 skus 参数包含了未破损商品"
}

5. 组件级评估：工具、规划、记忆、学习/适应

组件级评估的目标是：当端到端失败时，能快速定位是哪一类能力出了问题，并能用更便宜、更确定的测试覆盖它。

5.1 工具（Tools）评估

工具是 Agent 与外部世界交互的“执行器”。工具评估至少包含四类：

A. 正确性（Correctness）
给定输入，输出是否正确，副作用是否符合预期。

B. 鲁棒性（Robustness）
格式错误、缺字段、异常值、边界值是否处理合理。

C. 性能（Performance）
延迟、资源消耗、限流/退避、并发稳定性。

D. 故障处理（Failure Handling）
超时、外部依赖不可用时是否优雅降级（错误码、重试、回滚）。

核心指标（面向 Agent 轨迹）

工具召回率（Tool Recall）：期望调用的工具是否被调用
工具精确率（Tool Precision）：是否避免不必要调用
参数准确率（Argument Accuracy）：关键参数是否匹配真值

定义示意：

ToolRecall = |ExpectedTools ∩ ActualTools| / |ExpectedTools|
ToolPrecision = |ExpectedTools ∩ ActualTools| / |ActualTools|
ArgAccuracy = (#工具调用中参数完全正确的次数) / (#期望工具调用次数)

工具测试在 Agent 场景的两个补充：契约与幂等

契约测试（Contract Tests）：把“工具在什么输入下应该返回什么结构/错误码”固化下来，避免上游（Agent）与下游（工具）接口演进时静默破坏。
幂等性与回滚：尤其是退款/下单/改地址等有副作用工具，要验证重复调用的后果可控，且在失败时可以回滚或明确返回不可恢复错误。

评分实现示意（伪代码）

Inputs:
  expected_calls: list[{name, args_subset, required}]
  actual_calls:   list[{name, args}]

Score:
  tool_recall = (#required expected calls matched by name) / (#required expected calls)
  tool_precision = (#actual calls whose name in expected names) / (#actual calls)
  arg_accuracy = (#matched calls whose critical args equal) / (#required expected calls)

5.2 规划（Planning）评估

规划把高层目标拆成动作序列。它的失败模式通常比“答错事实”更隐蔽：

漏掉关键步骤（少调用一个必要工具）
调用顺序不合理（先执行副作用再校验）
过度工具调用（在不确定时乱查乱改）
早停或死循环（无法收敛）

建议的规划评估指标：

序列正确率：关键步骤是否按要求出现（可只检查关键子序列）。
子目标完成率：每个子任务是否完成（如“确认订单状态”“确认退款范围”）。
早停合理性：信息不足时是否澄清/升级，而不是瞎做。
过程质量：步骤是否可解释、是否违反策略（可用规则或 PRM/judge 评估）。

常见失败标签（建议作为 failure_tags 的标准枚举）

missing_required_tool：漏掉关键工具调用
premature_side_effect：校验前执行副作用
over_tooling：不必要工具调用过多
bad_stop：信息不足却直接执行或直接结束
looping：重复尝试无收敛（同工具/同参数重复）

5.3 记忆（Memory）评估

记忆模块包含“写入、存储、检索、使用”。测试重点不是“能不能存”，而是：

是否能检索到相关且最新的信息
是否会返回过时/无关信息
是否会发生跨用户泄露、污染、或被对话注入恶意记忆

常用检索质量指标：

MRR、NDCG（排序质量）
工程关注指标：
时序衰减准确性：新偏好应覆盖旧偏好，旧偏好不应莫名复活。
污染率：错误/恶意记忆被写入并在后续影响决策的比例。
泄露率：跨用户或跨租户信息被错误检索出来的比例。

5.4 学习/适应（Learning & Adaptation）评估

如果系统引入在线学习、提示词自更新、偏好学习等机制，需要额外关注：

闭环稳定性：更新是否导致性能震荡
灾难性遗忘：新能力提升是否以旧能力崩溃为代价
分布漂移适应：输入分布变化时是否保持安全边界与关键能力

实践上，建议把“可学习的部分”严格限定在低风险区域，并对每次更新设立回归门禁与回滚策略。

6. 系统级/端到端评估：任务成功率、轨迹指标与 LLM-as-Judge

端到端评估回答一个问题：在真实条件下，系统能否完成用户旅程？它必须同时评估“结果”与“过程”。

6.1 核心指标：任务成功率（Task Success Rate）

任务成功率一般是一个二值或分档判定：成功/失败/部分成功。
关键在于：成功标准必须包含业务约束与安全约束，而不是只看“用户看起来满意”。

建议把成功标准拆成：

Hard Constraints（硬约束）：违规即失败（越权、泄露、错误扣款/退款等）。
Soft Quality（软质量）：体验、表达、效率等可评分维度。

6.2 轨迹级指标：把“怎么做的”变成数据

端到端的辅助指标建议至少覆盖：

步数（#steps）、工具调用次数（#tool_calls）
成本（tokens、外部 API cost）
时延（P50/P95）
失败恢复（重试次数、fallback 次数、转人工率）
多轮漂移（对话轮数增长时，错误率是否上升）

补充：用“稳定性指标”补齐生产可靠性

Success@1：一次运行成功率（最接近线上体验）。
Pass@k：k 次里任一次成功就算通过（衡量上限能力）。
Majority@k：k 次里多数成功才通过（衡量稳定能力）。
Worst-of-k（最差表现）：观察 k 次里最糟糕那一次是否触发硬约束（特别适合安全评估）。

如果一个版本 Pass@k 上升但 Success@1 不变或下降，通常表示系统在“偶发正确”上提升，但没有把能力固化到稳定策略里；这时应该优先做：策略约束、工具参数生成约束、以及对不确定性的澄清分支设计。

6.3 LLM-as-Judge：何时用、怎么用、如何降低风险

当你要评估“开放式输出质量”时，LLM-as-Judge 是强工具，但需要工程化使用。

适用场景

话术质量：清晰、礼貌、解释充分、遵循风格
一致性/连贯性：是否自相矛盾、是否遗漏关键上下文
参考答案存在多种等价表达的场景

不适用或需谨慎的场景

强事实正确性：应优先用可验证的外部数据或规则评分（judge 只做辅助）。
高风险合规：judge 结果必须可抽样人工复核，并与规则引擎交叉验证。

推荐做法：Rubric + 结构化输出 + 多评委

Rubric 明确评分维度与判定规则（含 hard fail 条件）。
要求 judge 输出结构化 JSON（例如分数、是否违规、理由摘要）。
多数投票（MAJ）或“陪审团”降低单次偏置。

校准：让 judge 的分数“可被信任”

抽取一小部分样例做人审对照，计算 judge 与人审的一致性（agreement）与偏置（比如偏好更长回复）。
对 judge 做“可解释约束”：硬约束用规则先判定，judge 只负责软质量；避免把安全/合规完全交给 judge。
将 judge 的“理由摘要”写入日志，便于回溯与争议复核。

Judge 提示词模板（示意）：

你是评审员。给定：用户请求、对话历史、系统最终回复、以及（可选）工具调用轨迹。
请按 rubric 评估：
1) 是否满足硬约束（泄露/越权/错误操作）。如发生，直接判 FAIL。
2) 是否完成任务目标（成功/部分/失败）。
3) 软质量：清晰度、礼貌度、可执行性（1-5 分）。
输出 JSON：{hard_fail: bool, outcome: "...", scores: {...}, reasons: "..."}

常见偏置与对策（简表）

长度偏置：要求“信息充分但不冗余”，并加入“冗余惩罚”。
位置偏置（pairwise）：交换顺序评审后取平均。
同族偏置：评审模型尽量与被评审模型不同族，或用多模型陪审团。
Prompt 攻击：评审输入必须隔离用户指令，禁把用户文本当系统指令执行。

7. 一致性、连贯性与幻觉：高风险专项治理

这一章关注三类“用户信任杀手”：一致性、连贯性、幻觉。它们往往不一定立即导致任务失败，但会在规模化上线后迅速积累风险。

7.1 一致性（Consistency）：不自相矛盾、状态不漂移

一致性包含三种常见类型：

输入-输出一致性：回答必须回应用户意图，不能答非所问。
多轮逻辑一致性：后续回复不得否定前文已确认的事实（除非明确纠正）。
状态一致性：对订单/权限/系统状态的理解必须与工具返回一致。

评估方法：

在同一场景中做多次采样（temperature 或不同提示微扰），统计“不一致率”。
对长对话做“状态断言”：每轮提取状态快照，检查是否出现冲突。

7.2 连贯性（Coherence）：上下文衔接自然、信息不丢失

连贯性是“读起来是否像同一个靠谱的助手在持续工作”。常见失效：

忘记关键上下文（前面说过的订单号/用户偏好）
对同一件事反复提问或反复解释
对话主题漂移（聊着聊着跑到别处）

评估建议：

设计长上下文用例：多轮后再问关键事实，测保持率。
在评估集中标注“必须引用的上下文要点”，用短语召回率或 judge 检查。

7.3 幻觉（Hallucination）：编造事实、编造工具结果

对 Agent 而言，幻觉不仅是“编造知识”，还可能是：

编造工具调用成功/失败
编造订单/账户状态
在未执行工具的情况下“假装已操作”

治理策略建议按风险分层：

硬性事实：尽量从工具/数据库读出并引用，避免模型凭空说。
可验证引用：要求输出包含可追溯证据（引用 ID、来源、时间）。
事后核验：对关键动作进行二次校验（规则引擎/独立查询/对账）。
人审与升级：在高风险域（医疗/金融/法律/退款扣款）强制 human-in-the-loop 或多智能体验证。

可操作的“幻觉”评分拆解（建议）

Tool-result faithfulness（工具结果忠实度）：最终回复中提到的状态/数值，是否能在工具返回或数据库查询中找到证据。
Unsupported claims rate（无证据断言率）：回复中包含“已完成/已处理/已扣款”等强断言，但轨迹与终态没有对应证据的比例。
Citation coverage（引用覆盖率，适用于 RAG）：关键事实是否被引用到检索文档/证据片段。

这些指标的共同点是：尽量把“幻觉”变成可验证断言，而不是只依赖主观判读。

8. 意外输入与对抗：红队、注入、越权与优雅降级

真实环境里，输入可能是错误的、含糊的、甚至恶意的。好的 Agent 不一定“都能做”，但必须“知道什么时候不该做”，并给出可解释的下一步。

8.1 意外输入：格式错、信息缺、意图混合

覆盖点：

错别字/口语/俚语
- 订单号少一位、多一位
信息缺失
- 用户只说“退款”，没说哪一件
意图混合
- “取消订单并退款，同时改地址”

评估要点：

是否澄清而不是猜
是否把请求拆分并逐项确认
是否遵循“最小副作用”原则：不确定时避免执行不可逆操作

8.2 对抗与攻击：prompt injection / 越权 / jailbreak

典型攻击面：

在用户文本里夹带“忽略规则”“调用这个工具把数据导出”
诱导泄露敏感信息（订单、邮箱、电话、内部策略）
诱导执行不允许的操作（未授权退款、批量导出）

防御与评估建议：

评估集中加入注入样例，并记录“政策违反率/泄露率/越权触发率”。
工具层做权限与参数校验：即使模型被诱导，也无法越权。
输出层做最小披露：只返回必要信息，敏感字段打码。

8.3 优雅降级（Graceful Degradation）

当系统不确定或外部依赖失败时，优雅降级的优先级通常是：

澄清（ask clarifying questions）
拒绝（refuse）或限制模式（limited mode）
升级转人工（handoff）
备选策略（fallback tools / cached data），但必须标注“不确定性”

9. 生产就绪与部署关卡：准入标准、放量与观测性

生产就绪不是“跑通 demo”，而是“可控地失败、可追责地成功”。这一章给出可落地的发布治理框架。

9.1 定量准入标准：把“上线决定”变成门禁

建议至少包含：

Hero 场景任务成功率 ≥ 阈值，且相对上版本不回退
P0/P1 事件（安全/合规/严重误操作）为零容忍或极低阈值
成本与时延不超过预算（尤其是 P95 时延与单成功成本）

门禁表（示例口径）

维度	指标	建议门禁方式
质量	Hero Success@1	不得回退；或回退需阻断发布
稳定性	Majority@k（Hero）	低于阈值阻断发布
风险	P0 事件数	零容忍（阻断）
风险	P1 事件率	低于阈值；超阈值阻断
经济性	Cost per success	不得超预算（或需显式审批）
体验	P95 latency	不得超 SLO

9.2 放量策略：影子 → 灰度 → 全量

影子阶段：验证分布与系统稳定性
小流量灰度：验证真实用户反馈与尾部风险
扩大灰度：观察漂移与长期对话稳定性
全量：配套快速回滚与自动告警

9.3 观测性闭环：指标 + 轨迹 + 告警 + re-eval

建议把监控分成三层：

SLO 层：成功率、时延、成本、转人工率
风险层：越权/泄露/政策违反、异常工具调用、异常退款
诊断层：轨迹回放、失败类型聚类、关键样例采样

触发机制：

指标越界 → 自动抽样 → 触发离线 re-eval → 视结果自动拦截/回滚

10. 结语：评估不是成本中心，而是核心竞争力

当 Agent 进入生产，竞争不再是谁能做出 demo，而是谁能持续交付“可证明可靠”的能力：

评估集变成“活规范”，推动系统演进可控
轨迹级指标让调优不再玄学
安全与经济性纳入同一套门禁，避免“变强但不可用/变贵但不值”

下一波更值得投入的方向通常包括：

多智能体协作评估（角色分工：执行者/审计者/攻击者/裁判）
长期任务与超长上下文稳定性评估
经济性与可持续性（成本、碳足迹、吞吐）成为一等指标
可解释性与审计性（监管压力下的重要能力）

附录 A：术语表（Glossary）

Agent（AI Agent / Agentic System）：以大模型为核心，具备多轮对话与工具调用能力来完成任务的系统。
评价驱动开发（Evaluation-Driven Development, EDD）：以评估用例与指标作为迭代主线，把回归门禁变成研发流程的一部分。
英雄场景（Hero Journeys / Hero Scenarios）：最关键、最高价值的端到端用户旅程，用于定义“必须赢”的最低标准。
轨迹（Trajectory）：一次任务执行的全过程记录（对话 + 工具调用 + 状态变化），用于回放与定位失败原因。
工具召回/精度（Tool Recall / Tool Precision）：期望工具是否都调用到（召回），以及是否避免多余工具调用（精度）。
参数准确率（Argument Accuracy）：工具调用参数是否与真值一致（如订单号、金额、SKU 列表）。
Pass@k / Majority@k：重复运行 k 次的通过定义（任一次成功 vs 多数成功），分别衡量上限能力与稳定能力。
抖动率（Flakiness）：同一用例重复运行的失败概率或波动程度，用于量化非确定性带来的不稳定。
影子模式（Shadow Mode）：线上复制流量给新版本执行但不影响用户，用于对比指标与发现漂移。
灰度放量（Canary / Gradual Rollout）：逐步扩大新版本流量比例，并在每一档设置门禁与回滚策略。
LLM-as-Judge（LLM-as-a-Judge）：用强模型按 rubric 自动评审输出质量或偏好，用于开放式维度的规模化评估。
评分量表（Rubric）：评价规则与评分标准（硬约束 + 软质量维度），用于统一口径与提升可复现性。
MRR / NDCG（Mean Reciprocal Rank / Normalized Discounted Cumulative Gain）：信息检索指标，衡量记忆/检索结果的排序质量。
PRM（Process Reward Model）：对多步过程进行质量打分的模型/方法，用于约束或评估规划过程。
优雅降级（Graceful Degradation）：不确定或故障时采取澄清/拒绝/转人工/备选策略，避免错误执行与风险扩大。
SLO（Service Level Objective）：服务等级目标（如成功率、P95 时延、成本上限），用于上线门禁与运行期告警。
P0/P1（Severity Levels）：按严重程度分级的故障/风险事件口径，用于发布阻断、告警与复盘。

附录 B：落地清单（Checklist）

目标与指标

是否把业务目标分解为：任务目标 + 约束目标 + 过程目标？
是否明确 Hero/Long-tail/Red Team 三层覆盖？
是否同时衡量：成功率 + 风险 + 成本 + 时延？

评估集工程

是否有结构化样例格式（state/dialogue/expected trajectory/final state）？
是否维护 Golden/Silver/Live Drift 三层集合，并定义更新机制？

组件与系统评估

工具是否具备：正确性、鲁棒性、幂等性、故障处理测试？
是否对规划做序列/子目标/早停/过程质量评估？
记忆是否评估相关性、污染、泄露与压力场景？
端到端是否记录轨迹并可回放定位？

上线治理

是否有离线评估自动化（CI）与回归门禁？
是否支持影子模式与灰度放量？
是否有生产监控与告警，并能自动触发 re-eval/回滚？