第 08 讲 | Agent 怎么评测和加护栏：从基准测试到生产防护

本节我们将掌握：
为什么传统 LLM 评测方法对 Agent 不适用
质量三件套：完成率、步骤准、幻觉率
效率三件套：死锁率、步数、成本
安全护栏：五道防线
评测 + 护栏的工程闭环

为什么 Agent 评测更难

传统 LLM 评测（GSM8K、MMLU 等）只测"最终答案对不对"。这对 Agent 远远不够——Agent 是多步轨迹 + 工具调用 + 环境交互：

答案对 ≠ 过程对：Agent 可能中间调了 10 次错误工具，碰巧蒙对
答案对 ≠ 能上线：走了弯路，成本是必要的 5-10 倍
Agent 有工具结果幻觉：工具返回 Y，Agent 复述成 Z，纯 LLM 没有这种问题
Agent 会跑飞：ReAct 类 Agent 在无合适 observation 时无限循环，纯 LLM 不会

demo 阶段没人关心评测和护栏，一上生产全是坑。这两件事是区分"只跑过 notebook"和"真布过产线"的分水岭。

2026 年的共识：Agent 评测 = 质量 + 效率。六个维度分两类：

质量三件套：完成率（终局）、步骤准（过程）、幻觉（归因）——干得对不对
效率三件套：死锁（稳）、步数（快）、成本（钱）——干得贵不贵

质量三件套：干得对不对

① 任务完成率（Task Success Rate）

最粗但也最硬的指标：成功数 / 总样本数。

"成功"的定义要看场景：研报生成 = 产出结构完整的就算成；代码 Agent = 单测全过才算成。

坑：粒度粗。完成率 80%，里面可能 30% 是靠运气蒙的、50% 是绕过去的，看不出来。所以要配合步骤准确率。

② 步骤准确率（Step Accuracy）

每步的 Action 选得对不对、参数填得对不对。

比如"搜竞品"这一步，选了 SearchTool 是对的，但参数里 company 拼错 → 这步算错。

评法：人工标轨迹 or 用裁判模型（GPT-4 标 Claude 的轨迹）。

③ 幻觉率（Hallucination Rate）

Agent 场景下幻觉有两个来源，比纯 LLM 多一种：

类型	说明	例子
推理幻觉	Thought 里胡说	"我已经查到了 X"——其实没查
工具结果幻觉	工具返回 Y，Agent 复述成 Z	工具说温度 35°，Agent 说"今天很凉快"

评测做法：关键事实做 attribution 追溯——最终答案里每个 claim 能不能链回某个 tool output 或 observation，链不回的就是幻觉嫌疑。RAG 场景尤其重要。

效率三件套：干得贵不贵、稳不稳

④ 循环 / 死锁概率

Agent 特有指标，纯 LLM 没有。

ReAct 跑飞了会"搜 A → 看了不对 → 换个说法再搜 A → 又不对"无限循环。评法：跑 N 个样本，统计"触发 max_step 还没 done"的比例。生产红线一般压在 <2%。

⑤ 平均执行步数

和延迟、成本、失败率都正相关。

好 Agent 不是步数越少越好，是"不该走的弯路少"——同样任务别人走 12 步我们走 8 步，且完成率不降，才是真优化。

常用来定位问题：某版 prompt 改完完成率没变但步数 +3 → 说明 Agent 犹豫了，可能 prompt 约束不清。

⑥ Token 成本

分项拆比总量有用：

Input token：上下文 + 工具 schema + 检索召回，压缩和分层注入在这里发力
Output token：模型生成的 Thought + Action，步数直接决定
Tool call 次数 × 单次工具返回长度（Observation 常常是大头）

生产监控必看：成本 / 成功任务数，不然月底账单炸。

安全护栏：Agent 比 Chatbot 多一层防护

Chatbot 的护栏只要管"输入输出"（用户输入违规？模型输出有毒？）。Agent 多了"执行过程"这一层——它会调工具、会循环、会越权删库，所以护栏得多一道。

循环检测与强制终止

三道防线，配合用：

防线	怎么拦	举例
硬上限	max_step / max_iter 兜底	LangGraph 的 recursion_limit
相似 Thought 去重	连续 N 步 embedding 相似度超阈值 → 砍	换了三种说法搜同一个东西
同 Action 重复计数	连续调同一工具、参数相近 → 砍	连续 3 次调 Search 搜类似关键词

被动等 max_step 不如主动检测——N=3 时就砍，比跑到 20 再停省成本也省用户时间。

越权操作拦截

Agent 生成了 rm -rf / 或 DROP TABLE users，沙箱没拦住就炸。做法分三层：

层级	管控方式
工具层	每个工具注册时声明"读写？删？网络？"权限标签
Agent 层	Agent 身份绑权限集（"研报 Agent"不能碰 DB 写操作）
调度层	dispatch 前做 policy check，不合规直接拒

内容安全过滤

Agent 场景多两个入口：

工具返回结果也要过审——比如搜索回来有违规内容，不能原样喂给 LLM 当 Observation
中间 Thought 不用审（内部流转），但最终要给用户的那段输出必须审

人工兜底触发（Human-in-the-Loop）

触发条件	说明
confidence 低	多个候选 action 的 logprob 差 < 阈值
敏感操作	发邮件、删数据、转账
retry N 次还失败	Agent 搞不定了
用户主动喊停	任何时候

LangGraph 的 interrupt() 就是干这个的——把 State 冻住等 human 改完再续跑。金融、医疗、法务类 Agent，human checkpoint 不是可选项，是合规项。

工具权限分级

级别	权限	示例
只读	默认可用	搜索、查询、读文件
写入需确认	需 human approve	发邮件、写 DB、提交 PR
高危禁用	除非白名单 Agent + 白名单场景	bash、删库、生产环境 API

和 MCP 配套：MCP Server 侧统一做鉴权，Agent 侧不操心"这个工具我能调几次"。

ORCHIDEAS 框架：Agentic AI 安全护栏的标准化参考

Cloud Security Alliance（CSA）2026 年提出了 ORCHIDEAS 框架，9 支柱专门针对 Agentic AI 系统的安全护栏：

支柱	含义	对应护栏
Observable（可观测）	Agent 行为全链路可追踪	循环检测、日志落盘
Responsible（负责任）	Agent 决策可解释、可归因	attribution 追溯、幻觉检测
Controllable（可控）	人随时可以介入	Human-in-the-Loop、中断恢复
Human-centric（以人为本）	Agent 服务于人，不替代人	人工兜底、审批流
Identity-aware（身份感知）	Agent 作为非人类身份管理	工具权限分级、MCP 鉴权
Dependable（可靠）	Agent 输出可预期、可复现	评测集回归、灰度发布
Ethical（伦理）	Agent 决策不违反伦理规范	内容安全过滤
Adaptive（自适应）	Agent 能从反馈中学习改进	Reflexion、持续评测
Secure（安全）	Agent 不引入安全漏洞	越权拦截、沙箱

这不是一个必须全量落地的 checklist，而是一个思考框架——设计护栏时，对照 9 个维度，看哪些已经覆盖、哪些还是盲区。

评测 + 护栏的工程闭环

这两件事不是孤立的，生产里是一套观测 → 评测 → 加护栏 → 再观测的循环：

LangSmith / Phoenix / AgentOps 打 trace
         ↓
看六个维度（哪类任务死锁多？哪步幻觉率高？）
         ↓
针对性加护栏（循环检测阈值调紧、某工具加 human approve）
         ↓
再跑评测，看死锁率↓、成本↓、完成率不动或↑

工具链：

平台	特点
LangSmith	LangChain 系标配，trace + 评测集 + 人工标注轨迹
Phoenix（Arize）	开源，语义聚类看"哪些 query 容易炸"很好用
AgentOps / Braintrust	Agent 专项观测，多 Agent 轨迹可视化

主流评测基准

GAIA（General AI Assistant Benchmark）

最权威的 Agent 基准测试之一，包含需要推理、工具使用和多步骤的真实问题。

2026 年的关键发现：

脚手架选择比模型选择更重要：同一模型不同脚手架，精度相差 28 个百分点
Plan-and-Execute 在困难任务上表现最优：配合 Gemini 取得了最高精度和最低成本
公开基准在饱和：模型分数越来越高，但生产故障反而在增加

其他基准

基准	评测什么	局限
WebArena	浏览器操作能力	只测网页交互，不测业务逻辑
AgentBench	多环境适应（OS、DB、Web）	学术场景为主
StableToolBench	工具调用能力	2026 AAAI 论文提出，专注工具调用

公开基准饱和后，人工专家评审变得不可替代——这是 Stanford HAI 2026 AI Index 的结论。基准刷到 90%+ 了，但生产环境还是频繁出问题，所以自定义评测集必须和生产场景一致。

多 Agent 系统的拆解评测

详见第 07 讲（多 Agent 协作）。多 Agent 的评测更难——不仅要测整体输出，还要测每个 Agent 的贡献。

多 Agent 流水线：Analyzer → Writer → Reviewer

── 整体评测 ───────────────────────────────────────────
输入：一份代码 PR
输出：审核报告
→ 报告质量：8/10

── 拆解评测 ───────────────────────────────────────────
Analyzer 输出：{ bugs: 2, security: 1 } → 召回率 70%（漏了 1 个安全漏洞）
Writer 输出：基于 Analyzer 的数据写了报告 → 文笔 8/10
Reviewer 输出：指出了 2 个报告问题 → 审查质量 7/10

→ 结论：瓶颈在 Analyzer，不是 Writer 或 Reviewer

拆解评测的价值：定位瓶颈。整体分数差，但不知道哪个 Agent 的锅——拆解后就一目了然。

研发过程视角：我们的 CI/CD 就是评测系统

详见第 03 讲（Agent 核心范式）至第 06 讲（Agent 核心支撑技术）中 Superpowers 的 TDD 和 Review 流程。从评测的视角看，这些流程本质上就是一套评测系统：

Superpowers 阶段	对应的评测维度	怎么测
Spec 合规审查	结果正确性	实现是否覆盖所有需求条目
TDD	工具调用正确性	测试用例 = 预期行为，红灯 = 评测失败
代码质量审查	轨迹质量	代码是否走了最优路径，有没有冗余逻辑
Review 双轮审查	综合评分	规格合规 + 代码质量 + 安全

关键洞察：TDD 的红→绿→重构循环，本质上就是 Agent 评测中的"执行→评估→反思→重试"。我们用 pytest 跑测试、看 pass/fail、修代码、再跑——这和评测 Agent 轨迹、发现问题、优化策略的流程一模一样。

选型决策

架构师决策清单：
质量三件套：完成率、步骤准、幻觉率（attribution 追溯）
效率三件套：死锁率（<2%）、步数、成本/任务（分项拆）
循环检测三道防线：max_step 兜底 + 相似 Thought 去重 + 同 Action 重复计数
越权拦截分三层：工具层、Agent 层、调度层，高危操作必须 human approve
生产闭环：LangSmith / Phoenix 打 trace → 看短板 → 加护栏 → 再评测
拍板点：先跑评测集拿基线，上线后持续监控六维指标，异常自动告警

面试回答要点

Q：Agent 的评测你怎么做？和传统 LLM 评测有什么区别？

答（抓维度 + 讲工程）：

核心区别——传统 LLM 只测最终答案；Agent 评测必须测两层六维：质量类（完成率、步骤准、幻觉率）+ 效率类（死锁率、步数、Token 成本）。同一个 Agent 可能答案对但轨迹差（成本高 5 倍），这种不能上线。

护栏五件——循环检测、越权拦截、内容安全、人工兜底、工具分级。Chatbot 只管输入输出，Agent 多了"执行过程"防护。

生产体系——LangSmith / Phoenix 打 trace → 看六维短板 → 加对应护栏 → 再评测迭代。线上灰度发布 + 自动回滚是标配。

深度追问：

"多 Agent 怎么评测？" → 拆解评测：每个 Agent 独立评分，定位瓶颈。整体分数告诉我们"好不好"，拆解分数告诉我们"谁的锅"。
"循环检测只靠 max_step 够吗？" → 不够。max_step 是兜底不是治理。相似 Thought / 同 Action 重复计数能在 N=3 时就砍，比等到 max_step=20 再停省成本。
"Agent 幻觉率怎么评？" → attribution 追溯：最终答案每个 claim 链回 tool output / observation，链不回的就是幻觉嫌疑。RAG 场景尤其重要。

小结

Agent 评测两层六维：质量类（完成率、步骤准、幻觉率）+ 效率类（死锁率、步数、成本），只看最终答案不够
Agent 特有幻觉：推理幻觉 + 工具结果幻觉，attribution 追溯是核心手段
护栏比 Chatbot 多一层执行过程防护：循环检测三道防线、越权拦截三层、人工兜底、工具分级
生产闭环：观测 → 评测 → 加护栏 → 再观测，持续迭代

思考题

我们的团队上线了一个客服 Agent，GAIA 基准得分 92%，但用户投诉率 15%。从评测角度分析可能的原因。我们会怎么设计评测体系来发现并解决这个问题？（提示：基准和生产场景不一致、轨迹质量未评测、工具调用错误各是一种可能）
我们设计了一个 3-Agent 流水线（分析 → 生成 → 审核），整体输出质量评分 6/10。我们怎么定位是哪个 Agent 的瓶颈？定位后发现是分析 Agent 的召回率只有 60%，我们会先优化分析 Agent，还是加一个补充分析 Agent？为什么？
我们的 ReAct Agent 上线后，2% 的会话触发了 max_step 才停止。只靠 max_step 够吗？我们会加哪些主动检测机制？如果其中涉及发邮件的操作，我们会加什么护栏？

第 08 讲 | Agent 怎么评测和加护栏：从基准测试到生产防护 ​

为什么 Agent 评测更难 ​

质量三件套：干得对不对 ​

① 任务完成率（Task Success Rate） ​

② 步骤准确率（Step Accuracy） ​

③ 幻觉率（Hallucination Rate） ​

效率三件套：干得贵不贵、稳不稳 ​

④ 循环 / 死锁概率 ​

⑤ 平均执行步数 ​

⑥ Token 成本 ​

安全护栏：Agent 比 Chatbot 多一层防护 ​

循环检测与强制终止 ​

越权操作拦截 ​

内容安全过滤 ​

人工兜底触发（Human-in-the-Loop） ​

工具权限分级 ​

ORCHIDEAS 框架：Agentic AI 安全护栏的标准化参考 ​

评测 + 护栏的工程闭环 ​

主流评测基准 ​

GAIA（General AI Assistant Benchmark） ​

其他基准 ​

多 Agent 系统的拆解评测 ​

研发过程视角：我们的 CI/CD 就是评测系统 ​

选型决策 ​

面试回答要点 ​

小结 ​

思考题 ​