字节笔记本
2026年10月24日 · 约 9 分钟读完
评估难题：怎么知道 Agent 好不好
本文是《从 0 写 Agent》系列第 44 章。这个系列基于开源项目 agents-go（OpenAI Agents SDK 的 Go 移植版），用 Go 从零实现一个生产级 Agent 运行时；本章讲「评估难题：怎么知道 Agent 好不好」。
你写了个 Agent，跑了几次感觉不错。但"感觉不错"不是评估，你怎么知道它对 1000 个不同的输入都能表现好？你怎么知道改了指令后是变好了还是变差了？
Agent 评估是工程化最难、也最被低估的问题。这一章讲为什么难，以及业界目前的实践方法。
引子：传统评估失效
传统软件的评估，测试覆盖率。写了 100 个单元测试全过，覆盖率 90%，你就有信心"代码是对的"。
Agent 不行。因为输出是概率性的（第 42 章），你没法写"输出必须等于 X"的断言。而且 Agent 的"好"是多维的，
- 正确性，答得对不对
- 效率，调了几次工具、花了几轮
- 安全，有没有做危险操作
- 体验，回答是否清晰、是否说人话
"好"是多维的，单一指标衡量不了。
为什么 Agent 评估难
难点一：输出非确定
同一个输入跑两次，输出可能不同。你测了一次"好"，不代表每次都好。
难点二：正确性主观
"这个分析报告写得好不好"，没有客观标准。不同人评判不同。
难点三：路径多样
同一个问题，Agent 可能用不同工具组合解决，调 A 再调 B，或调 C 再调 D。路径不同但结果都对，怎么评估"路径"？
难点四：长尾
Agent 可能在 95% 的情况表现好，但 5% 的边缘情况灾难性失败。你要测足够多的样本才能覆盖长尾。
业界实践：四种评估方法
方法一：回归测试集（离线 benchmark）
收集一批"已知好"的输入输出对，新版本跑这些输入，比较输出。
测试集：100 个 {输入, 期望特征} 对
新版本跑这 100 个输入
检查：输出是否仍然满足"期望特征""期望特征"不是精确输出（因为概率性），而是，
- 结构正确（是合法 JSON、有必需字段）
- 关键信息对（提到的数据正确）
- 安全合规（不含 PII、没做危险操作）
- 质量达标（由人或 LLM 评判）
agents-go 的 CollectingExporter（第 27 章）可以帮你收集 trace，作为测试集的基础。
方法二：LLM-as-Judge
用一个强模型评判另一个模型的输出质量。
// 评判 Agent 的输出
judgePrompt := `请给这个客服回答打分（1-10），标准：
- 准确性：信息对不对
- 完整性：有没有漏
- 语气：是否礼貌专业
Agent 的回答：{{output}}
用户的提问：{{input}}
打分：`
score := callLLM(judgePrompt)这呼应前面 SkillOpt 那篇，"用模型验证模型"是 Agent 评估的主流方法。 人评判太慢，LLM 评判可以规模化。
局限，评判模型本身可能不准。 通常用比被评 Agent 更强的模型当 judge（比如用 GPT-5 评判 GPT-4-mini 的输出）。
方法三：在线评测（A/B 测试）
真实用户使用，收集反馈。 比"离线评测"更真实，
- 用户点了"赞"还是"踩"
- 用户有没有重新提问（不满意才重问）
- 用户有没有手动修改 Agent 的输出
- 任务完成率（用户最终解决问题了吗）
在线评测最可信，但最贵、最慢。 通常是最后一步，离线评测通过了，再上线上 A/B。
方法四：自动化属性检查
不断言具体内容，断言"属性"，
// 属性检查（可自动化）
assert(validJSON(output)) // 是合法 JSON
assert(len(output) < maxLength) // 不超长
assert(!containsPII(output)) // 不含 PII
assert(toolCalls < maxTools) // 工具调用不过多
assert(duration < maxLatency) // 延迟不超标属性检查可以 CI 化，每次改 Agent 配置，自动跑属性检查。虽然不能保证"质量好"，但能保证"不出低级问题"。
设计权衡：评估的投入产出
评估方法从便宜到贵：
| 方法 | 成本 | 可信度 | 适合 |
|---|---|---|---|
| 属性检查 | 低 | 低（只查低级问题） | CI 自动化 |
| 回归测试集 | 中 | 中 | 版本对比 |
| LLM-as-Judge | 中 | 中-高 | 规模化质量评测 |
| 人工评测 | 高 | 高 | 关键场景 |
| 在线 A/B | 最高 | 最高 | 上线前最后验证 |
推荐组合，CI 跑属性检查 + 每次发版跑回归集 + LLM-as-Judge 定期评 + 关键更新做 A/B。
评估要测什么：多维指标
| 维度 | 指标 | 怎么测 |
|---|---|---|
| 正确性 | 答案对不对 | 人工/LLM judge |
| 工具效率 | 平均调几次工具 | trace 统计 |
| 成本 | 平均花多少 token | Usage 统计 |
| 延迟 | P50/P95/P99 响应时间 | trace 时间 |
| 安全 | 危险操作拦截率 | guardrail 触发统计 |
| 用户满意 | 点赞率/重问率 | 在线反馈 |
不要只测"正确性"。 一个"每次都对但调 20 次工具花 10 秒"的 Agent，用户体验极差。多维评估才全面。
agents-go 支持评估的特性
| 特性 | 怎么帮评估 |
|---|---|
| Tracing（第 25-27 章） | 完整执行轨迹，可统计工具次数、延迟 |
| Usage 记录 | token 消耗，成本评估 |
| CollectingExporter | 收集 trace 做测试集 |
| 结构化输出 | 输出可解析，便于属性检查 |
| Lifecycle Hooks | 每步记录，便于路径分析 |
agents-go 的可观测性设计，本身就是为评估打基础。 没有 trace，你连"Agent 调了几次工具"都不知道，评估无从谈起。
小结：评估是被低估的核心能力
读完这一章，你应该理解：
- Agent 评估难，非确定、主观、路径多样、长尾
- 四种方法，属性检查、回归集、LLM-judge、在线 A/B
- 多维指标，不只测正确性，还要测效率/成本/延迟/安全/满意
- agents-go 的可观测性是评估基础，trace/usage/hooks 支撑评估数据收集
核心洞察，"能评估"比"能跑"更难、更重要。 很多团队能做出"看起来不错的 Agent demo"，但无法评估"它到底有多好"，这导致不敢上生产。建立评估体系，是 Agent 从 demo 到生产的关键一跃。
Part VIII 回顾
第 41-44 章，从"怎么写"深入到"为什么有效"：
| 章节 | 主题 |
|---|---|
| 41 ReAct | Agent 的认知科学基础 |
| 42 概率性系统 | 给不确定性加边界 |
| 43 LLM 作为大脑 | 为什么 LLM 适合做决策核心 |
| 44 评估难题 | 怎么知道 Agent 好不好 |
理解了原理，你不仅能"写 Agent"，更能"判断 Agent 该不该用、用得好不好"。
下一篇
第 45 章，进入 Part IX 实战案例，从 0 写一个客服 Agent。把前面学的所有东西（循环、工具、Session、HITL、Guardrails）组合起来，做一个真实可用的客服系统。
本文是《从 0 写 Agent》系列第 44 章，案例代码基于开源项目 agents-go（OpenAI Agents SDK 的 Go 移植版）。全系列目录见总览。
