这一章是 第 19 章：评估与监控（Evaluation and Monitoring）。它讲的是：Agent 做出来以后，不能只看 demo 能不能跑，而要持续衡量它在真实环境里的表现，包括 效果、成本、延迟、工具调用、轨迹、合规、安全、漂移、异常行为 等。

和上一章第 18 章的关系是：

第 18 章：怎么给 Agent 加护栏，防止它乱来。 第 19 章：怎么知道 Agent 到底表现得好不好，护栏有没有生效，系统有没有变差。

所以这章更偏 工程化落地，不是单纯模型能力。

1. 这一章的核心问题

普通测试会问：

1

这个函数输出对不对？

但 Agent 评估要问的问题更多：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

它最终答案对不对？
它有没有用错工具？
它有没有多调用不必要的工具？
它有没有超时？
Token 成本高不高？
它有没有产生幻觉？
它有没有违反安全规则？
它有没有在多轮任务里偏离目标？
它在真实用户数据上表现有没有下降？
它和其他 Agent 协作是否顺畅？

所以 Agent 的评估不是简单的 “pass / fail”，而是一个持续监控体系。

文档开头说，本章聚焦智能体 有效性（effectiveness）、效率（efficiency） 和 合规性（compliance） 的持续测量，包括指标定义、反馈回路和报告系统，确保 Agent 在实际环境中的表现符合预期。

这句话很重要。

Agent 评估主要看三件事：

1
2
3

有效性：有没有完成任务
效率：有没有用合理成本完成任务
合规性：有没有安全、合规、按规则完成任务

2. 第 1 页图 1 怎么理解？

第 1 页图 1 是 评估与监控最佳实践（Monitoring and Evaluating Agent Performance），里面大概有五层：

1
2
3
4
5

1. 定义清晰、可衡量的目标和指标
2. 结合定量数据和定性数据
3. 定期、持续收集数据
4. 奖励和激励 Agent
5. 提供反馈和指导

这个图的意思是：评估不是最后随便跑几个样例，而是从一开始就要设计指标。

比如你做一个客服 Agent，不能只说“它回答得不错”，而要定义：

1
2
3
4
5
6
7

问题解决率是多少？
平均响应时间是多少？
转人工率是多少？
用户满意度是多少？
工具调用失败率是多少？
回答是否符合知识库？
是否有违规回答？

也就是说，评估要从主观感觉变成可量化指标。

3. 这一章的典型应用场景

文档列了几个场景，我帮你按工程意义重新整理一下。

3.1 生产环境性能追踪

生产环境性能追踪（Production Performance Tracking） 是指 Agent 上线后持续看指标。

比如客服 Agent：

1
2
3
4
5
6

解决率
响应时间
失败率
用户满意度
转人工率
平均 Token 成本

这和普通软件监控类似，但 Agent 多了“答案质量”和“推理行为”的问题。

3.2 A/B 测试优化

A/B 测试（A/B Testing） 是比较两个版本的 Agent。

比如：

版本 A 用 GPT-4o-mini。 版本 B 用 Gemini Flash。 或者：

版本 A 检索 top-3 文档。 版本 B 检索 top-8 文档。 或者：

版本 A 有 reflection。 版本 B 没有 reflection。

然后比较：

1
2
3
4
5
6

准确率
延迟
成本
用户满意度
工具调用次数
幻觉率

这就是把 Agent 优化从“我感觉这个 prompt 更好”变成数据驱动。

3.3 合规与安全审计

合规与安全审计（Compliance and Safety Auditing） 是检查 Agent 有没有遵守规则。

比如：

有没有提供不该提供的法律建议； 有没有泄露隐私； 有没有绕过安全策略； 有没有调用未授权工具； 有没有生成危险内容。

这和第 18 章护栏直接相关。

护栏是防线，评估与监控是检查防线是否有效。

3.4 漂移检测

漂移检测（Drift Detection） 是这一章很重要的概念。

Agent 上线时表现好，不代表三个月后还好。

可能原因有：

用户问题类型变了； 业务规则变了； 知识库变旧了； 外部环境变了； 模型版本变了； 工具 API 变了； 用户开始用新的攻击方式。

这会导致性能下降。

所以要监控：

1
2
3
4
5

回答准确率是否下降
用户投诉是否增加
检索命中率是否下降
工具失败率是否升高
输出相关性是否降低

这就是 概念漂移（Concept Drift） 或更广义的系统性能漂移。

3.5 异常行为检测

异常行为检测（Anomaly Detection） 是识别 Agent 的不正常行为。

比如：

突然大量调用某个工具； 一次对话里循环调用搜索； Token 消耗异常升高； 输出长度异常； 拒答率突然升高； 某类用户请求失败率突然增加； 调用了平时很少调用的高风险工具。

这些可能意味着：

系统 bug； 提示注入攻击； 工具接口异常； 模型行为变化； 路由策略出错。

所以 Agent 监控不仅是质量问题，也是安全问题。

4. 最基础的响应评估：准确率

文档先给了一个很简单的函数：

1
2

def evaluate_response_accuracy(agent_output: str, expected_output: str) -> float:
    return 1.0 if agent_output.strip().lower() == expected_output.strip().lower() else 0.0

这个函数只做严格字符串匹配。比如：

1
2

Agent 输出：The capital of France is Paris.
标准答案：Paris is the capital of France.

语义上是一样的，但严格匹配会判 0 分。文档也指出，这种方法无法识别语义等价，只适合非常简单的场景。

所以实际评估不能只靠完全匹配。

更常用的方法包括：

字符串相似度（String Similarity） 例如 Levenshtein 距离、Jaccard 相似度。

关键词匹配（Keyword Matching） 检查是否包含关键事实或关键字段。

语义相似度（Semantic Similarity） 用 embedding 向量计算余弦相似度。

LLM 评审（LLM-as-a-Judge） 让另一个模型根据评分标准评估回答。

RAG 指标（RAG Metrics） 比如答案是否忠于检索文档、是否相关、是否完整。

5. 为什么 Agent 不能只评估最终答案？

因为 Agent 不是普通问答模型，它有行动过程。

比如一个 Agent 最终答案对了，但过程可能很糟：

用了不该用的工具； 查了无权限数据； 调用了 10 次工具才完成； 中间产生了错误但刚好修正了； 成本过高； 违反了预期流程； 靠幻觉猜中答案。

所以 Agent 评估要看两层：

1
2

最终结果评估：答案是否正确
轨迹过程评估：过程是否合理

这就是后面讲的 智能体轨迹评估（Agent Trajectory Evaluation）。

6. 延迟监控：不是答对就够了

延迟（Latency） 指从用户发出请求到系统返回结果的时间。

对于 Agent 来说，延迟尤其重要，因为它可能多轮调用模型和工具：

1
2
3
4
5
6
7

LLM 思考
搜索工具
数据库查询
代码执行
反思
再次搜索
最终生成

每一步都增加时间。

文档说，实时或交互场景中延迟很关键，过高延迟会影响用户体验。实际应用中，延迟数据应该记录到结构化日志、时序数据库或可观测性平台，比如 Prometheus、Datadog、Splunk、Grafana Cloud 等。

你可以监控：

1
2
3
4
5
6
7

平均延迟
P50 延迟
P95 延迟
P99 延迟
每个工具调用耗时
每个模型调用耗时
端到端耗时

其中 P95 延迟（95th Percentile Latency） 很重要，表示 95% 请求都能在这个时间内完成。它比平均值更能反映用户体验。

7. Token 用量追踪：对应成本控制

文档给了一个 LLMInteractionMonitor 类，用来记录输入 Token 和输出 Token。它的示例只是用 split() 粗略统计，实际项目要用模型 API 返回的 token usage。

为什么要监控 Token？

因为 LLM 成本通常和 Token 数量相关。

Agent 容易 Token 爆炸，原因包括：

长上下文； 多轮对话； 多次工具调用； 反思步骤； 多 Agent 协作； RAG 检索塞入太多文档； 输出过长。

所以要监控：

1
2
3
4
5
6
7

input_tokens
output_tokens
total_tokens
cost_per_request
cost_per_user
cost_per_task
每个节点的 token 消耗

这和第 16 章 资源感知优化（Resource-Aware Optimization） 有直接关系。

如果你发现某个 Agent 节点 Token 消耗特别高，就要优化：

减少上下文； 压缩历史记忆； 减少检索文档数量； 换更便宜模型； 减少不必要 reflection； 设置最大输出长度。

8. LLM-as-a-Judge：用模型评估模型

这一章重点介绍了 LLM-as-a-Judge（LLM 作为评审者）。

它的作用是评估一些很难用规则判断的主观质量，比如：

有用性； 清晰度； 完整性； 相关性； 中立性； 逻辑性； 是否符合用户意图。

文档给了一个法律调查问卷评估的例子。它定义了一个评分标准 LEGAL_SURVEY_RUBRIC，要求模型从 5 个维度打分：清晰与精确、中立与无偏、相关性与聚焦、完整性、受众适配性，并输出 JSON。

也就是说，LLM Judge 的基本流程是：

1
2
3
4
5
6
7

待评估内容
  ↓
评分标准 Rubric
  ↓
评审模型
  ↓
结构化评分 JSON

这里的关键词是 评分标准（Rubric）。

LLM-as-a-Judge 不是让模型随便评价，而是要明确：

1
2
3
4
5
6

评什么？
每项几分？
什么叫好？
什么叫差？
输出格式是什么？
是否需要理由？

9. LLM-as-a-Judge 的优点和问题

文档后面有一个评估方法对比表：

这个表很重要。

LLM-as-a-Judge 的优点：

速度快； 成本比人工低； 能规模化； 适合主观质量评估； 可以输出结构化理由。

但它也有问题：

评审模型也会错； 可能偏向长答案； 可能偏向文风好的答案； 可能忽略事实细节； 可能被待评估内容影响； 不同模型评分标准不一致； 可能只看最终答案，忽略 Agent 过程。

所以实际系统里，LLM Judge 最好和人工抽检、自动指标、日志分析结合。

10. 智能体轨迹评估：这一章最重要的部分之一

智能体轨迹评估（Agent Trajectory Evaluation） 是评估 Agent 的行为路径。

普通模型评估只看：

1

输入 → 输出

Agent 评估还要看：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

输入
  ↓
中间思考 / 计划
  ↓
工具选择
  ↓
工具参数
  ↓
工具返回
  ↓
下一步决策
  ↓
最终输出

文档说，传统软件测试只能判断通过/失败，但 Agent 行为具有概率性，因此要定性分析最终输出和决策过程。轨迹评估包括决策质量、推理过程和最终结果。

比如一个客服 Agent 的理想轨迹是：

1
2
3
4
5
6
7
8
9

识别用户意图
  ↓
调用订单数据库
  ↓
检查订单状态
  ↓
生成解释
  ↓
必要时转人工

如果实际轨迹是：

1
2
3
4
5

识别用户意图
  ↓
直接编造订单状态
  ↓
生成答案

即使答案看起来流畅，也是不合格的。

11. 轨迹评估到底评什么？

可以评这些：

11.1 工具选择是否正确

比如用户问天气，应该调用天气工具，而不是通用知识模型。

1
2

正确：weather_tool
错误：web_search 或直接猜

11.2 工具调用顺序是否合理

比如旅行 Agent 应该先确认机票，再订酒店。

1
2

合理：查机票 → 查酒店 → 生成行程
不合理：先订酒店 → 再发现机票没有

11.3 工具参数是否正确

比如查询订单应该传当前用户 ID，而不是别人的 ID。

这和第 18 章工具参数校验相关。

11.4 是否有多余步骤

如果一个问题一次数据库查询就够了，Agent 却调用了 5 次搜索、3 次 LLM 反思，效率就很差。

11.5 是否陷入循环

比如一直搜索，一直反思，一直认为信息不足。

这对应你的“工程化踩坑：死循环”。

11.6 是否按计划执行

Planner 生成了计划，但 Executor 是否真的照做？

12. 轨迹评估的几种匹配方法

文档提到，可以把实际步骤和理想路径对比，方法包括精确匹配、顺序匹配、任意顺序匹配、查准率、查全率、单工具使用等。

我解释一下。

精确匹配

精确匹配（Exact Match） 要求实际轨迹和理想轨迹完全一样。

1
2

理想：A → B → C
实际：A → B → C

才算对。

优点：严格。 缺点：太死板。

顺序匹配

顺序匹配（Order Match） 要求关键步骤顺序一致，但允许中间有额外步骤。

1
2

理想：A → B → C
实际：A → X → B → Y → C

可以算部分正确。

任意顺序匹配

任意顺序匹配（Any-order Match） 只关心有没有调用这些工具，不关心顺序。

1
2

理想工具：A, B, C
实际工具：B, A, C

也可以算对。

适合顺序不重要的任务。

查准率和查全率

查准率（Precision）：实际调用的工具里，有多少是应该调用的。 查全率（Recall）：应该调用的工具里，有多少被实际调用了。

比如理想工具是：

1

A, B, C

实际调用：

1

A, B, D

那么：

1
2

Precision = 2 / 3
Recall = 2 / 3

这适合评估工具调用质量。

13. 测试文件和 Evalset 文件

这一章提到 Google ADK 里两种评估文件：

测试文件（Test File） 评估集文件（Evalset File）

13.1 测试文件

测试文件通常是 JSON 格式，用于简单单次交互或简单会话。

适合开发阶段做单元测试。

比如你要测试：

用户问时间； Agent 是否调用了时间工具； 最终回答是否包含正确时间。

它通常包含：

1
2
3
4
5

用户请求
预期工具调用
智能体中间响应
最终回复
评估标准

13.2 Evalset 文件

Evalset File 用于更复杂的多轮会话和集成测试。

一个 evalset 可以包含多个 eval，每个 eval 是一个完整会话。

适合测试：

多轮对话； 多工具调用； 复杂任务流程； 多个 Agent 协作； 参考答案和轨迹。

简单说：

1
2

测试文件：适合小测试、单元测试
Evalset：适合复杂场景、集成测试

这和普通软件开发里的 unit test / integration test 很像。

14. 多智能体评估：不只看单个 Agent

文档强调，多智能体系统评估更复杂，因为要看协作。

例如旅行系统里有：

机票预订 Agent； 酒店预订 Agent； 餐厅预订 Agent； 总规划 Agent。

这时候不能只问每个 Agent 单独好不好，还要问：

信息有没有正确传递？ 顺序是否合理？ 有没有冲突？ 有没有重复工作？ 有没有选错 Agent？ 新增 Agent 后整体效果是否变好？

比如：

1
2

机票 Agent 查到目的地是 Tokyo
酒店 Agent 却订了 Osaka

单个 Agent 可能都“正常工作”，但系统协作失败。

所以多智能体评估要看：

1
2
3
4
5
6

任务分工
通信质量
状态共享
冲突处理
整体目标完成度
协作效率

这和的“多智能体协作”模块相关。

15. 从 Agent 到“承包商”：这一节比较抽象，但很有意思

文档后半部分讲了一个概念：把智能体从普通助手升级成高级 承包商（Contractor）。

这里不是传统意义上的外包公司，而是说：

Agent 不只是收到一句 prompt 就开始干活，而是先和用户形成一个明确的“合同”，规定任务范围、交付物、数据源、时间、成本、质量标准和验收方式。

这个概念的本质是：

1
2

从模糊 prompt
变成明确规格说明

普通 Agent 接到的是：

1

帮我分析欧洲市场销售。

承包商式 Agent 需要把任务明确成：

1
2
3
4
5
6
7

生成 20 页 PDF 报告
分析 2025 Q1 欧洲市场销售
包含 5 个数据可视化
与 2024 Q1 对比
评估供应链风险
使用指定数据源
截止时间为 X

文档说，“承包商”模型通过正式合同建立用户与 AI 的严密关系，合同详细规定任务、交付物、数据源、范围、成本和时限，结果可客观验证。

这其实是 Agent 工程化的一种方向：把需求变得可验证。

16. “承包商”模型的四个支柱

文档讲了四个支柱。

16.1 正式合同

正式合同（Formal Contract） 是任务的唯一真相来源。

它明确：

交付物是什么； 质量标准是什么； 数据源是什么； 范围边界是什么； 截止时间是什么； 成本限制是什么。

这比一句 prompt 可靠得多。

16.2 动态协商与反馈

动态协商（Dynamic Negotiation） 是指 Agent 不盲目执行，而是发现问题时先反馈。

比如用户要求使用一个它无法访问的数据库，Agent 应该说：

1

指定数据库不可用，请提供凭证，或批准使用公开数据库。

而不是直接编造数据。

这和第 18 章的安全和合规也有关。

16.3 质量导向的迭代执行

质量导向的迭代执行（Quality-Oriented Iterative Execution） 是指 Agent 在提交前自我验证。

比如代码生成任务：

生成多个方案； 运行单元测试； 比较性能； 检查安全性； 选择最优版本； 只提交通过验证的结果。

这就和第 17 章推理、自我纠错、代码执行结合起来了。

16.4 分层分解与子合同

分层分解（Hierarchical Decomposition） 和 子合同（Subcontracts） 是指复杂任务拆成多个可验证子任务。

比如开发电商 App：

1
2
3
4
5
6

主合同：开发电商移动应用
  ↓
子合同 1：设计 UI/UX
子合同 2：开发认证模块
子合同 3：创建产品数据库
子合同 4：集成支付网关

每个子合同都有自己的交付物、标准和验收方式。

这就是多 Agent 协作的一种更规范的表达。

17. 第 8 页图 2 怎么理解？

第 8 页图 2 是智能体间合同执行示例。图里大概包含：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

Contract Submitted
  ↓
Contract Assessment
  ↓
如果合同有问题 → Contract Revision
如果合同可接受 → Contract Execution
  ↓
Task Resolution
  ↓
Contract Deliverables

里面还有子合同生成、候选方案生成、候选评审、候选排序、候选演化等流程。

这张图表达的是：

Agent 不应该一拿到任务就直接做，而应该先评估合同是否可行。

比如：

任务是否明确？ 数据源是否可访问？ 时间和预算是否合理？ 交付物是否可验证？ 是否需要拆分子任务？ 是否要修改合同？

这就是比普通 prompt 更严谨的 Agent 工作流。

18. Google ADK 框架在这里做什么？

文档最后介绍了 Google ADK 的评估支持。它支持三种方式：

1
2
3

Web UI：交互式评估和数据集生成
pytest 集成：用于测试流水线
命令行 adk eval：用于自动化评估

18.1 Web UI

Web UI 适合交互式调试。

你可以和 Agent 对话，把会话保存成测试数据，观察每一步结果。

18.2 pytest 集成

pytest 集成 适合放进 CI/CD。

比如每次你改了 prompt、工具、路由逻辑，都自动跑一遍测试，看看有没有退化。

18.3 命令行 adk eval

adk eval 适合自动化评估和常规构建验证。

比如你有一批 evalset，每天或每次发布前跑一次，检查 Agent 表现。

这和普通软件工程里的自动化测试很类似。

19. 这一章和前几章的关系

这一章其实把前面很多东西串起来了。

和第 16 章资源感知优化的关系

第 16 章讲成本、延迟、资源。 第 19 章讲怎么监控这些指标。

比如：

1
2
3
4

Token 用量
响应延迟
工具调用次数
模型调用成本

这些都是资源感知优化的基础数据。

没有监控，就不知道该优化哪里。

和第 17 章推理技术的关系

第 17 章讲 CoT、ReAct、Reflection。 第 19 章讲怎么评估这些推理流程有没有真的带来提升。

比如：

加了 Reflection 后，准确率提高了吗？ 延迟增加了多少？ 成本增加了多少？ 工具调用有没有更合理？ 是否减少了幻觉？

和第 18 章护栏的关系

第 18 章讲安全机制。 第 19 章讲安全机制是否有效。

比如：

违规输出率是否下降？ Prompt Injection 是否被拦住？ 工具越权调用是否减少？ 误拒率是否过高？ 高风险操作是否都进入人工审核？

20. 这一章在面试题的位置

按照你给的截图，这章和这些模块更相关：

评估与全局观 直接有“量化评估体系、落地最大挑战”。这章就是直接对应这一块。

工程化踩坑 监控死循环、状态丢失、成本控制，和这章的轨迹评估、Token 追踪、延迟监控有关。

多智能体协作 这章讲了多智能体系统要评估协作、分工、通信、整体性能。

业务 AI 工程分析 这章的 A/B 测试、生产监控、KPI、合规审计，和业务落地结合很强。

所以这一章比第 18 章更像的独立模块，尤其是“评估与全局观”。

21. 你需要掌握的核心指标

可以按 5 类记。

21.1 效果指标

1
2
3
4
5

准确率 Accuracy
任务完成率 Task Completion Rate
答案相关性 Relevance
事实一致性 Faithfulness
用户满意度 User Satisfaction

21.2 效率指标

1
2
3
4

响应延迟 Latency
工具调用次数 Tool Call Count
任务完成时间 Task Completion Time
吞吐量 Throughput

21.3 成本指标

1
2
3
4
5
6

输入 Token
输出 Token
总 Token
单次请求成本
单任务成本
模型调用次数

21.4 安全与合规指标

1
2
3
4
5
6

违规输出率
拒答率
误拒率 False Positive
漏拦率 False Negative
越权工具调用次数
人工审核触发率

21.5 轨迹指标

1
2
3
4
5
6

工具选择准确率
工具调用顺序匹配度
理想路径匹配度
循环次数
无效步骤比例
多 Agent 协作成功率

这些比单纯“回答准确率”更像 Agent 评估。

22. 如果你被问：如何评估一个 Agent？

可以这样回答：

我会从最终输出和执行过程两层评估。最终输出层看准确性、相关性、完整性、事实一致性和用户满意度；执行过程层看工具选择是否正确、调用顺序是否合理、参数是否正确、是否有无效步骤或死循环。同时还要监控延迟、Token 成本、工具失败率、安全违规率。对于主观质量，可以使用 LLM-as-a-Judge 配合人工抽检；对于生产环境，还要做 A/B 测试、漂移检测和异常监控。

这个回答就覆盖这章核心。

23. 如果你被问：LLM-as-a-Judge 有什么问题？

可以这样回答：

LLM-as-a-Judge 可扩展、成本低、适合评估有用性、清晰度、完整性等主观指标，但它本身也会出错，可能偏向长答案、忽略事实细节、受评分提示影响，甚至忽略 Agent 的中间轨迹。因此最好结合明确 rubric、结构化输出、人工抽检和自动化指标，不要把 LLM Judge 当成唯一真相。

24. 如果你被问：Agent 评估和普通模型评估有什么区别？

可以这样回答：

普通模型评估主要关注输入到输出的结果质量，而 Agent 评估还要关注过程。因为 Agent 会规划、调用工具、访问外部环境和多轮决策，所以需要评估轨迹，包括工具是否选对、参数是否正确、顺序是否合理、是否陷入循环、是否越权、成本和延迟是否可接受。也就是说，Agent 评估是结果评估加过程评估。

这句话很关键。

25. 最后总结

第 19 章的核心是：

Agent 上线后不能只靠感觉判断好坏，而要建立持续、多维度的评估与监控体系。

你真正需要记住的是：

1
2
3
4
5
6

结果要评估：答案是否正确、有用、相关
过程要评估：工具选择、调用顺序、轨迹是否合理
性能要监控：延迟、吞吐、错误率
成本要监控：Token、模型调用、工具调用
安全要监控：违规率、越权调用、人工审核
长期要监控：漂移、异常、版本退化

这一章最重要的关键词是：

评估与监控（Evaluation and Monitoring） 生产环境性能追踪（Production Performance Tracking） A/B 测试（A/B Testing） 合规与安全审计（Compliance and Safety Auditing） 漂移检测（Drift Detection） 异常行为检测（Anomaly Detection） 延迟监控（Latency Monitoring） Token 用量追踪（Token Usage Tracking） LLM-as-a-Judge（LLM 作为评审者） 评分标准（Rubric） 智能体轨迹评估（Agent Trajectory Evaluation） 测试文件（Test File） 评估集文件（Evalset File） 承包商智能体（Contractor Agent） 正式合同（Formal Contract）

这一章对你的价值很明确：它让你从“我会搭 Agent”升级到“我知道怎么判断 Agent 是否真的可靠、可控、可上线”。

推荐阅读

上一篇：

护栏与安全模式

下一篇：

优先级排序