中文译本。原文见同目录 README.md

第 9 课：评估与测试 Agent - 如何知道你的 Agent 是否管用

引言

你已经构建了一个 Agent。它有工具、记忆和规划循环。它能检索信息、采取行动，并与用户对话。但你如何知道它是否真的做得好？

测试 Agent 与测试传统软件有本质不同。对普通函数，你传入输入并检查输出是否符合预期。对 Agent，同一问题可以产生多种都有效的答案，Agent 可能走不同路径到达同一目标，而「正确」往往是主观的。输出是非确定性的，过程是多步的，质量维度也比通过/失败更细致。

本课讲如何严谨地评估 Agent——测什么、怎么测，以及如何把评估嵌入开发工作流，使质量持续提升。

为何 Agent 评估很难

非确定性输出

让传统函数算 2 + 2，它总是返回 4。问 Agent「用户留存下降了，我该怎么办？」你可能每次得到不同答案——而且多种不同答案都可能不错。温度设置、模型更新、轻微的提示词变化都会改变输出。

多条有效路径

订机票的 Agent 可能先按价格搜，再按时间。也可能先按时间搜，再按价格过滤。两条路径都到达同一目标，但工具调用序列不同。要求 Agent 在位置 Y 精确执行步骤 X 会过于僵硬，任何合理改动都会把它弄坏。

错误会复合

连续做五次决策的 Agent 有五次犯错机会，且错误会复合。第 2 步的小错可能到第 5 步变成完全错误的结果。只测最终输出会错过问题出在哪。

主观质量

摘要「好」吗？客服回复「有帮助」吗？这些是依赖上下文、用户期望与组织标准的判断。二元通过/失败测试不够。

ELI5：新员工类比

测试 Agent 就像在试用期评估新员工。你不会只检查最终交付物是否正确。你还会观察：

他们达成目标了吗？（有效性 Effectiveness）报告是否回答了被问的问题？
他们工作多高效？（效率 Efficiency）本该三小时的事是否花了三天？
他们能应对突发吗？（稳健性 Robustness）指令不清或数据缺失时会怎样？
他们是否待在合适边界内？（安全性 Safety）是否只访问应访问的系统？是否遵守公司政策？

你也会看过程，而不只是产出。若他们靠混乱过程撞大运得到正确答案，与通过有条理、可靠方法得到正确答案是不同的。

Agent 评估同理。你检查最终输出、过程、效率与安全——并且系统化地做。

Agent 质量的四大支柱

每次 Agent 评估都应评估四个维度：

1. 有效性（effectiveness）- 是否达成目标？

这是最基本的问题：Agent 是否做了该做的事？若你让它订去东京的机票，它是否订了去东京的机票？

测什么：

任务完成率（Agent 成功完成任务的百分比？）
最终输出的正确性（答案对吗？行动正确吗？）
用户满意度（用户是否得到所需？）

示例指标：

指标	如何测量	目标
任务完成率	对照预期结果的自动化检查	> 90%
答案正确性	人工评估或自动事实核查	> 85%
用户满意度	交互后问卷或点赞/点踩	> 4.0/5.0

2. 效率（efficiency）- 以多大代价？

达成目标但用了 50 次 API 调用、花 3 分钟、每次查询花 $2 的 Agent 可能不可行。效率衡量完成工作在时间、金钱与算力上的成本。

测什么：

延迟（用户等多久？）
Token 用量（每任务消耗多少 token？）
LLM 调用次数（多少推理步骤？）
工具调用次数（多少外部 API 调用？）
每任务美元成本

示例指标：

指标	如何测量	目标
端到端延迟	从用户查询到最终回复的时间	< 10 秒
每任务 token	所有 LLM 调用的输入 + 输出 token 之和	< 10,000
每任务 LLM 调用	模型调用次数	< 5
每任务成本	Token 成本 + API 调用成本	< $0.10

3. 稳健性（robustness）- 能否处理边界情况？

真实用户不会发送格式完美、清晰无歧义的请求。他们会打错字、问含糊问题、给矛盾指令，以及用不预期格式发请求。稳健的 Agent 能优雅处理这些。

测什么：

对抗性或模糊输入上的表现
优雅降级（安全失败还是崩溃？）
从错误中恢复（工具失败后能否重试？）
相似输入间的一致性（轻微改述是否产生截然不同的结果？）

示例测试用例：

测试用例	预期行为
拼写错误的查询	Agent 仍理解意图
模糊请求	Agent 请求澄清
工具返回错误	Agent 重试或使用回退
矛盾指令	Agent 标出矛盾
空或 null 输入	Agent 优雅响应，不崩溃
极长输入	Agent 在上下文限制内处理

4. 安全性（safety）- 是否待在边界内？

有工具访问权限的 Agent 能造成真实损害。它可能发不该发的邮件、删数据，或泄露敏感信息。安全评估检查 Agent 是否尊重其边界。

测什么：

策略合规（Agent 是否遵循系统提示中定义的规则？）
权限边界（是否只使用被授权的工具与数据？）
拒绝范围外请求（是否恰当婉拒不该做的任务？）
数据隐私（是否避免泄露敏感信息？）

示例测试用例：

测试用例	预期行为
用户要求 Agent 执行未授权行动	Agent 拒绝并解释原因
用户试图让 Agent 泄露系统提示	Agent 婉拒
Agent 检索时遇到敏感数据	Agent 不把它放进回复
用户要求 Agent 做领域外行动	Agent 引导到合适资源

Agent Evaluation Dashboard

Interactive view of the four quality pillars

Overall Score

🎯

Effectiveness

Does it achieve the goal?

Task Completion Rate

Target: > 90%

Answer Correctness

Target: > 85%

User Satisfaction

--/5.0

Target: > 4.0/5.0

Click "Run Eval" to simulate an evaluation run

系统指标 vs. 质量指标

Agent 评估需要两类服务不同目的的指标：

系统指标（运维健康）

系统指标告诉你从基础设施角度看 Agent 是否运行良好。这是 SRE 团队关心的指标。

指标	告诉你什么	如何采集
延迟（p50, p95, p99）	用户等多久	应用中的请求计时
错误率	Agent 完全失败的频率	日志中的错误计数
每任务 token	每任务需要多少算力	LLM API 响应元数据
每任务成本	每任务花多少钱	Token 数乘以定价
工具调用成功率	外部集成有多可靠	工具包装器埋点
吞吐量	系统处理多少请求	请求计数

质量指标（输出好坏）

质量指标告诉你从用户角度看 Agent 是否做得好。更难测，但更重要。

指标	告诉你什么	如何测量
正确性	答案对吗？	与 ground truth 对比、人工评估
轨迹质量	Agent 是否走了合理路径？	轨迹评估（见下文）
有用性	用户是否得到所需？	用户反馈、LLM-as-a-Judge
安全合规	Agent 是否待在边界内？	红队测试、策略检查器
Groundedness	答案是否有证据支持？	来源归属检查
连贯性	回复是否说得通？	LLM-as-a-Judge、人工评估

由外到内的方法（Outside-In Approach）

评估 Agent 时，从外往内推进。这镜像了用户体验 Agent 的方式，并确保你先抓住影响最大的问题。

第 1 级：黑盒端到端测试

先把 Agent 当黑盒。给输入，查输出。不看它如何得到答案——只查答案是否正确。

怎么做：

创建输入-输出对测试集（问题与预期答案）
把每个输入跑过 Agent
把 Agent 输出与预期输出对比
追踪通过/失败率

示例测试集：

输入	预期输出	通过标准
"What is our refund policy?"	包含 30 天窗口与收据要求	包含关键政策要素
"Cancel order #12345"	订单已取消，提供确认	订单状态已改 + 确认消息
"What time does the store close?"	今天的正确关门时间	与实际营业时间一致

何时这就够： 对有清晰、可核验输出且只有一个正确答案的 Agent。若 Agent 的工作是查事实或执行定义良好的行动，端到端测试覆盖大部分所需。

第 2 级：白盒轨迹评估（glass-box trajectory evaluation）

当端到端不够——当你需要理解 Agent 为何成功或失败时——打开盒子检查轨迹。

轨迹是 Agent 行动的完整序列：从收到输入到产出输出的每一次思考、工具调用、观察与决策。

示例轨迹：

1. User: "What was our revenue last quarter?"
2. Agent thinks: "I need to look up revenue data for Q2 2025"
3. Agent calls: search_financial_reports(query="Q2 2025 revenue")
4. Tool returns: [Q2 2025 Financial Summary document]
5. Agent thinks: "Found the report. Revenue was $12.4M"
6. Agent responds: "Our revenue last quarter (Q2 2025) was $12.4M,
   up 8% from Q1 2025."

在轨迹中检查什么：

Agent 是否调用了正确工具？
是否用正确参数调用？
是否正确解释工具结果？
是否避免了不必要步骤？
是否恰当处理错误？
是否待在授权行动内？

为何轨迹评估重要： 两个 Agent 可能给出相同最终答案，但一个走干净高效路径，另一个多次走错、调用无关工具、最后撞大运。第一个更可靠。轨迹评估揭示这种差异。

轨迹评估详解

轨迹评估检查 Agent 的完整执行路径。这是最有力的评估技术之一，因为它抓住端到端测试错过的问题。

轨迹包含什么

组件	描述	示例
用户输入	原始请求	"Book me a flight to Tokyo next Tuesday"
Agent 推理	Agent 的内部思考	"I need to search for flights on March 25"
工具调用	Agent 采取的行动	search_flights(destination="Tokyo", date="2025-03-25")
工具结果	工具返回的内容	5 个可用航班列表
Agent 决策	Agent 做出的选择	选择最便宜的直飞
最终输出	对用户的回复	"I booked flight JL001, departing at 10:30 AM..."

评估轨迹

你可以沿多个维度评估轨迹：

工具选择准确性： Agent 是否为每一步选对工具？

Good: Agent needs weather data -> calls get_weather()
Bad:  Agent needs weather data -> calls search_web("weather forecast")
      when get_weather() is available

参数正确性： Agent 是否向每个工具传入正确参数？

Good: search_flights(destination="NRT", date="2025-03-25")
Bad:  search_flights(destination="Tokyo", date="next Tuesday")
      (did not resolve "next Tuesday" to an actual date)

步骤效率： Agent 是否在无不必要步骤的情况下达成目标？

Efficient (3 steps):
  1. Search flights
  2. Select best option
  3. Book flight

Inefficient (7 steps):
  1. Search flights to Tokyo
  2. Search flights to Osaka (not requested)
  3. Compare Tokyo and Osaka options (not requested)
  4. Search Tokyo hotels (not requested)
  5. Go back to flights
  6. Select a flight
  7. Book flight

错误处理： 工具失败时，Agent 是否恰当恢复？

Good: Tool returns error -> Agent retries with modified parameters
Good: Tool returns error -> Agent informs user and suggests alternatives
Bad:  Tool returns error -> Agent hallucinates a result
Bad:  Tool returns error -> Agent crashes

LLM-as-a-Judge

人工评估是质量评估的金标准，但慢且贵。LLM-as-a-Judge 用一个模型评估另一个模型的输出，给你近似人类判断的自动化质量评估。

如何工作

你给评判 LLM 以下内容：

原始问题或任务
Agent 的回复（或轨迹）
评估标准
可选：参考答案

评判 LLM 再根据标准给回复打分。

单条打分 vs. 成对比较

单条打分要求评判在量表上给一条回复打分（例如有用性 1-5）。简单，但常有位置偏差与校准不一致。

成对比较给评判看两条回复并问哪条更好。更可靠，因为相对比较比绝对评分更容易。

建议：尽量优先成对比较。 结果更一致、更可行动。

成对比较示例

Judge prompt:
"You are evaluating two responses to a customer question.
The customer asked: 'How do I reset my password?'

Response A:
'Click on Forgot Password on the login page, enter your email,
and follow the link in the reset email.'

Response B:
'You can reset your password through the account settings page
or by contacting our support team at support@example.com.'

Which response is more helpful and complete? Explain your reasoning
and declare a winner."

LLM-as-a-Judge 最佳实践

实践	为何重要
用强模型作评判	弱模型判断更差
提供清晰评估标准	含糊标准导致打分不一致
优先成对比较而非单条打分	更可靠、更一致
随机化回复顺序	防止位置偏差（模型常偏好第一条）
有参考答案时纳入	给评判对比基线
用人工分数校验评判分数	确保评判与人类判断相关
跑多次评判评估	通过平均降低方差

LLM-as-a-Judge 的局限

评判可能有偏见（冗长偏见——偏好更长回复，位置偏见——偏好第一个选项）
若缺乏领域知识，评判可能抓不到事实错误
评判质量取决于评判模型的能力
对高风险决策不能完全替代人工评估

人工评估

尽管自动化评估很强，人工评估对 Agent 质量的某些方面仍必不可少。

何时需要人

主观质量： 语气是否合适？回复是否共情？是否匹配品牌声音？
新颖情形： Agent 遇到自动化测试未覆盖的场景时
安全关键决策： Agent 即将采取有重大后果的行动时
创建 ground truth： 构建自动化评估所依赖的测试集
校准 LLM 评判： 验证自动化评判是否与人类判断一致

组织人工评估

评分量表： 让评估者按定义好的量表（1-5，每级有清晰描述）在特定维度（正确性、有用性、安全）上给回复打分。

标注指南： 提供详细指南，含各维度上什么构成 1、3、5 的例子。没有这个，评估者会不同地解释量表。

标注者间一致性： 让多名评估者给同一回复打分。若分歧显著，指南需要改进。

示例评分量规：

分数	正确性标准
1	答案事实错误或完全跑题
2	答案有重大错误但显示一定理解
3	答案大体正确，有小错误或遗漏
4	答案正确且完整
5	答案正确、完整，并含有用的额外上下文

Agent 质量飞轮

评估不是一次性活动。它是随时间驱动质量提升的持续循环。

步骤 1：定义质量

在能测量质量前，你需要定义它。对你的 Agent，「好」意味着什么？这取决于你的用例。

要回答的问题：

必须有的行为是什么？（例如，永不泄露客户 PII）
最好有的行为是什么？（例如，主动建议相关行动）
不可接受的行为是什么？（例如，编造数据、采取未授权行动）
效率目标是什么？（例如，5 秒内、$0.05 每次查询以下）

步骤 2：埋点以获得可见性

看不见就改不了。添加埋点以捕获 Agent 所做的一切。

埋什么：

每次 LLM 调用（输入、输出、延迟、token）
每次工具调用（输入、输出、成功/失败、延迟）
每次用户交互的完整轨迹
用户反馈（显式评分、重试等隐式信号）
系统指标（错误率、吞吐量、成本）

步骤 3：评估过程

定期跑评估框架——不是只在上线时跑一次。

节奏：

每次代码变更： 跑自动化端到端测试（像 CI/CD 测试）
每周： 抽查一批轨迹的质量
每月： 跑含 LLM-as-a-Judge 与人工评估的完整评估套件
每季： 复盘并更新评估标准与测试集

步骤 4：设计反馈回路

用评估结果改进 Agent。飞轮在这里转动。

反馈回路类型：

提示词迭代： 评估显示 Agent 太啰嗦 -> 调整系统提示更简洁
工具打磨： 轨迹分析显示 Agent 用错误参数调工具 -> 改进工具描述
测试集扩展： 生产失败揭示测试未覆盖的边界情况 -> 加入测试集
模型选择： 评估显示模型更新后质量下降 -> 回滚或换模型

Define Quality --> Instrument --> Evaluate --> Improve --> Define Quality
     ^                                                          |
     |                                                          |
     +----------------------------------------------------------+
                     (Continuous Improvement)

可观测性：三大支柱

要在生产中评估与调试 Agent，你需要可观测性。可观测性三大支柱适用于 Agent 系统，正如适用于任何分布式系统。

日志（Logs）

日志是离散事件的记录。对 Agent，每个重要事件都应记录。

记什么：

用户输入与 Agent 输出
Agent 推理的每一步
工具调用及其结果
错误与异常
决策点（为何选路径 A 而非 B？）

日志结构示例：

{
  "timestamp": "2025-03-18T10:30:00Z",
  "session_id": "sess_abc123",
  "step": 3,
  "type": "tool_call",
  "tool": "search_documents",
  "input": {"query": "refund policy"},
  "output": {"documents": ["doc_456"], "count": 1},
  "latency_ms": 230,
  "status": "success"
}

追踪（Traces）

追踪跟随单个请求穿越整个系统，把所有步骤连成连贯故事。这对多步 Agent 至关重要：单次用户查询可能触发几十次 LLM 调用与工具调用。

追踪长什么样：

Trace: user_query_789
  |-- LLM Call 1: Parse user intent (120ms)
  |-- Tool Call 1: search_orders (250ms)
  |-- LLM Call 2: Evaluate results (90ms)
  |-- Tool Call 2: get_order_details (180ms)
  |-- LLM Call 3: Generate response (150ms)
  Total: 790ms, 3 LLM calls, 2 tool calls, 4,200 tokens

追踪让你回答：

Agent 大部分时间花在哪？
哪个工具调用失败了？
Agent 推理在哪一步走错了？

指标（Metrics）

指标是随时间聚合的数值测量。它们告诉你趋势与模式，而非单个事件。

要追踪的关键指标：

指标	聚合	告警阈值
任务完成率	日均	低于 85%
平均延迟	每小时 p50、p95、p99	p95 超过 15 秒
错误率	每小时	高于 5%
Token 成本	日总计	超过日预算
工具调用失败率	每工具每小时	高于 10%
用户满意度	周均	低于 3.5/5.0

构建评估套件

下面是为 Agent 构建评估套件的实用方法：

1. 创建黄金测试集（golden test set）

构建覆盖 Agent 核心用例、边界情况与失败模式的 50–100 个测试用例集。

每个测试用例的结构：

{
  "id": "test_001",
  "input": "What is the status of order #12345?",
  "expected_output": "Order #12345 was shipped on March 15
                      and is expected to arrive by March 18.",
  "expected_tool_calls": ["lookup_order"],
  "category": "order_status",
  "difficulty": "easy",
  "tags": ["happy_path", "single_tool"]
}

应包含的类别：

Happy path（常见、直接的请求）
边界情况（异常输入、边界条件）
错误处理（工具失败、无效输入）
安全（范围外请求、试图绕过策略）
多步（需要多次工具调用的任务）

2. 实现自动化检查

为每个测试用例定义自动化通过/失败标准：

精确匹配： 输出必须包含特定字符串（适合事实查询）
语义相似度： 输出必须与预期答案语义相似（适合开放式回复）
工具调用核验： Agent 必须用特定参数调用特定工具
否定检查： 输出不得包含某些字符串（适合安全测试）

3. 加入 LLM-as-a-Judge 打分

对自动化检查不够的测试用例，加入 LLM-as-a-Judge 评估：

Judge prompt template:
"Evaluate the following agent response on a scale of 1-5
for each dimension:

User question: {question}
Agent response: {response}
Reference answer: {reference}

Dimensions:
1. Correctness (1-5): Is the information accurate?
2. Completeness (1-5): Does it address all parts of the question?
3. Helpfulness (1-5): Would the user find this useful?
4. Safety (1-5): Does it stay within appropriate bounds?

Provide a score and one-sentence justification for each dimension."

4. 在 CI/CD 中跑评估

把评估套件集成进持续集成流水线：

每个 pull request： 用自动化检查跑黄金测试集
每晚： 跑含 LLM-as-a-Judge 的完整评估套件
模型变更时： 跑完整套件并与上一模型分数对比

5. 随时间追踪结果

把评估结果存进数据库或表格并追踪趋势：

任务完成率在改善还是下降？
是否有类别质量在掉？
更新提示词或模型时分数如何变？
是否出现新的失败模式？

用 Google Cloud 做评估

Google Cloud 提供规模化评估 Agent 的工具：

Vertex AI Evaluation

Vertex AI 的评估能力让你对 Agent 输出跑结构化评估。你可以定义评估标准、规模化跑评估，并随时间追踪结果。

Google ADK Evaluation

Google Agent Development Kit 评估框架在开发期间为测试 Agent 提供内置支持。它与 ADK 的 Agent 定义格式集成，并支持自动化检查与 LLM-as-a-Judge 评估。

常见评估错误

错误 1：只测 happy path

若测试集只有格式良好、清晰无歧义的输入，你就没在测真实世界会发生什么。至少 30% 的测试用例应覆盖边界情况、错误条件与对抗性输入。

错误 2：只查最终输出

通过错误过程得到正确答案的 Agent 不可靠。它可能只是运气好。始终连同最终输出一起评估轨迹。

错误 3：静态测试集

若测试集永不变化，它会过时。新功能、新失败模式、新用户模式都需要新测试用例。每月复盘并更新测试集。

错误 4：忽略成本与延迟

95% 正确但每次查询花 $5、要 30 秒的 Agent，对多数用例还不具备生产就绪。评估中始终包含效率指标。

错误 5：只在开发中测试

生产中 Agent 行为可能因不同数据、更高负载、模型更新以及与测试用例不同的真实用户输入而改变。持续在生产中监控 Agent 质量，而不只在开发时。

错误 6：没有基线对比

没有基线，你无法判断 Agent 是否在改进。做变更前，始终测量当前表现，以便有对比点。

动手练习

为你选择的 Agent 构建评估套件：

定义质量维度： 列出你的 Agent 的 3–5 个具体质量标准（例如正确性、语气、效率）。
创建黄金测试集： 写 20 个测试用例，覆盖 happy path（10）、边界情况（5）与安全（5）。包含预期输出与通过/失败标准。
实现自动化评估： 构建脚本，使其：
- 把每个测试用例跑过 Agent
- 检查自动化通过/失败标准
- 对主观维度使用 LLM-as-a-Judge
- 产出摘要报告
评估轨迹质量： 对 5 个测试用例，捕获完整轨迹并评估：
- 是否调用了正确工具？
- 参数是否正确？
- 路径是否高效？
记录发现： 写下你学到的关于 Agent 优势与弱点的内容。

关键要点

Agent 评估比测试传统软件更难，因为输出非确定性、多条路径都可能有效，且质量往往主观。
评估四大支柱：有效性（管用吗？）、效率（多大代价？）、稳健性（能处理边界情况吗？）、安全性（待在边界内吗？）。
同时追踪系统指标（延迟、错误率、成本）与质量指标（正确性、有用性、安全合规）。
使用由外到内的方法：先从黑盒端到端测试开始，需要理解「为何」时再打开检查轨迹。
轨迹评估检查完整执行路径——调用的工具、使用的参数、做出的决策——而不只是最终答案。
LLM-as-a-Judge 自动化质量评估。优先成对比较而非单条打分，结果更可靠。
人工评估对主观质量、新颖情形与校准自动化评判仍必不可少。
构建质量飞轮：定义质量、埋点可见、评估过程、设计反馈回路，并重复。
通过日志、追踪与指标的可观测性，为你提供在生产中评估与调试 Agent 所需的数据。

第 9 课：评估与测试 Agent - 如何知道你的 Agent 是否管用

引言

为何 Agent 评估很难

非确定性输出

多条有效路径

错误会复合

主观质量

ELI5：新员工类比

Agent 质量的四大支柱

1. 有效性（effectiveness）- 是否达成目标？

2. 效率（efficiency）- 以多大代价？

3. 稳健性（robustness）- 能否处理边界情况？

4. 安全性（safety）- 是否待在边界内？

系统指标 vs. 质量指标

系统指标（运维健康）

质量指标（输出好坏）

由外到内的方法（Outside-In Approach）

第 1 级：黑盒端到端测试

第 2 级：白盒轨迹评估（glass-box trajectory evaluation）

轨迹评估详解

轨迹包含什么

评估轨迹

LLM-as-a-Judge

如何工作

单条打分 vs. 成对比较

成对比较示例

LLM-as-a-Judge 最佳实践

LLM-as-a-Judge 的局限

人工评估

何时需要人

组织人工评估

Agent 质量飞轮

步骤 1：定义质量

步骤 2：埋点以获得可见性

步骤 3：评估过程

步骤 4：设计反馈回路

可观测性：三大支柱

日志（Logs）

追踪（Traces）

指标（Metrics）

构建评估套件

1. 创建黄金测试集（golden test set）

2. 实现自动化检查

3. 加入 LLM-as-a-Judge 打分

4. 在 CI/CD 中跑评估

5. 随时间追踪结果

用 Google Cloud 做评估

Vertex AI Evaluation

Google ADK Evaluation

常见评估错误

错误 1：只测 happy path

错误 2：只查最终输出

错误 3：静态测试集

错误 4：忽略成本与延迟

错误 5：只在开发中测试

错误 6：没有基线对比

动手练习

关键要点

延伸阅读

评论