AgentBench / τ-bench：Agent 环境评测
Agent evaluation 的核心变化:
AgentBench / τ-bench / Agent Evaluation 解读
面向对象: AI PM / AI BA / AI Architect / EvalOps / Agent Platform PM。 核心问题: Agent 评测不能只看单轮回答质量，而要评估多步任务、工具调用、状态管理、用户交互、规则遵守和业务结果。 学习目标: 能把 AgentBench、τ-bench 等 benchmark 思想迁移到企业 agent 的上线评测和作品集。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| AgentBench: Evaluating LLMs as Agents | https://arxiv.org/abs/2308.03688 | 理解 agent 在多环境任务中的系统评测 |
| τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains | https://arxiv.org/abs/2406.12045 | 理解工具、用户模拟、业务规则和多轮交互评测 |
| ReAct | https://arxiv.org/abs/2210.03629 | 理解 reasoning + action + observation 的 agent 基础 |
| HELM | https://crfm.stanford.edu/helm/latest/ | 借鉴 scenario/metric/adapter 的评测组织方式 |
Agent evaluation 的核心变化:
从“模型回答对不对”转向“系统能否在受控环境里完成真实工作流，并且不违反规则、不越权、不丢状态、可被审计”。
1. 为什么 Agent 评测更难
Chatbot 评测通常看:
- answer correctness。
- groundedness。
- helpfulness。
- safety。
Agent 评测还要看:
| 维度 | 问题 |
|---|---|
| Task completion | 是否完成业务任务 |
| Tool correctness | 是否调用正确工具和参数 |
| State tracking | 是否记住订单、case、客户、约束 |
| Policy compliance | 是否遵守业务规则 |
| Interaction quality | 是否会追问和澄清 |
| Recovery | 工具失败、用户改口、信息缺失时怎么办 |
| Cost/latency | 完成任务需要多少调用和时间 |
| Auditability | 是否留下足够 evidence |
企业 agent 的评测对象不是单个 model，而是:
Model + Prompt + Tools + Memory + Workflow + Policy + UI + Human Oversight
2. AgentBench 的启发
AgentBench 把 LLM 放到不同环境中测试 agent 能力，例如:
- operating system。
- database。
- knowledge graph。
- web shopping。
- games。
- household tasks。
它给企业的启发不是照搬任务，而是采用“环境化评测”:
| Benchmark 思想 | 企业迁移 |
|---|---|
| agent interacts with environment | agent 与 case system、CRM、policy DB、payment tool 交互 |
| action changes state | 工单、草稿、审批、日志会改变 |
| success depends on sequence | 不是单次 API，而是多步流程 |
| observation matters | 工具返回会影响下一步 |
| task completion measurable | 业务结果和合规结果都要可判定 |
3. τ-bench 的启发
τ-bench 强调 tool-agent-user interaction。
关键价值:
- 任务有真实业务规则。
- 用户会多轮交互。
- Agent 需要调用工具。
- 需要同时满足用户目标和 policy constraints。
这非常接近企业金融零售 agent:
| τ-bench 元素 | 金融零售映射 |
|---|---|
| User simulator | 客户、柜员、调查员、underwriter |
| Tool APIs | CRM、case、payment、policy、KYC、fraud tools |
| Policy | 合规、权限、审批、话术、产品规则 |
| Goal | 解决 dispute、完成 KYC、汇总 alert、生成草稿 |
| Evaluation | task success + policy compliance |
4. 企业 Agent Eval Stack
Scenario Library
-> User Simulator
-> Tool Sandbox
-> Policy Oracle
-> Agent Runtime
-> Trace Collector
-> Metric Computation
-> Human Review Sample
-> Release Gate
4.1 Scenario Library
场景必须覆盖:
- normal cases。
- edge cases。
- missing information。
- user changes intent。
- tool failure。
- permission mismatch。
- policy conflict。
- prompt injection。
- adversarial user。
- high-risk escalation。
4.2 Tool Sandbox
不要在真实系统里评测 agent。
需要:
- mock API。
- synthetic records。
- reversible state。
- deterministic tool responses。
- error injection。
- audit trace。
4.3 Policy Oracle
政策判定不能只靠 LLM judge。
可以组合:
- rule engine。
- expected final state。
- allowed / forbidden actions。
- SME labels。
- LLM judge as secondary reviewer。
5. 指标体系
| Metric | Definition | Why it matters |
|---|---|---|
| Task success rate | 完成目标的比例 | 基础效用 |
| Policy compliance rate | 未违反规则的比例 | 金融场景核心 |
| Tool call accuracy | 工具和参数是否正确 | 防操作错误 |
| State consistency | 多轮状态是否正确 | 防错客户/错 case |
| Clarification quality | 信息不足时是否追问 | 防猜测 |
| Recovery rate | 工具失败后是否恢复 | 稳定性 |
| HITL trigger precision | 该升级时升级，不该升级时不过度升级 | 控制效率和风险 |
| Cost per completed task | 完成一次任务的成本 | 平台经济性 |
| Latency per step | 每步耗时 | 用户体验 |
| Trace completeness | 是否能审计 | 合规和调试 |
Release Gate 示例
| Gate | Threshold |
|---|---|
| critical policy violation | 0 |
| permission leakage | 0 |
| high-risk action without approval | 0 |
| task success normal cases | >= 85% |
| tool call accuracy | >= 95% |
| trace completeness | >= 98% |
| unresolved tool failure | <= 2% |
6. PM 视角: Agent 产品指标
AI PM 不能只写:
提升效率。
要写:
| Product metric | Example |
|---|---|
| assisted completion | 调查员用 AI 完成初稿比例 |
| reviewer acceptance | 草稿被接受比例 |
| edit distance | 人工修改幅度 |
| cycle time | case 处理时间 |
| escalation accuracy | 高风险升级准确率 |
| trust calibration | 用户何时接受/拒绝 AI |
| adoption by segment | 新人/专家/主管使用差异 |
Product decision
| 如果 eval 显示 | PM 决策 |
|---|---|
| task success 高但 policy violation 高 | 不能上线，缩小 scope |
| policy safe 但 task success 低 | 做 copilot，不做 agent |
| cost per task 过高 | 降低 search/tool budget |
| expert 不采纳但新人采纳 | 重新定位培训或目标用户 |
| HITL 过度触发 | 调整 risk tier 和规则 |
7. BA 视角: Scenario Writing
BA 是 agent eval 的关键角色，因为场景来自业务流程。
Scenario Template
| Field | 内容 |
|---|---|
| scenario_id | aml_agent_001 |
| user role | investigator |
| user goal | triage alert and draft summary |
| initial state | customer profile, transactions, prior alerts |
| hidden facts | examiner-only expected facts |
| allowed tools | case_read, transaction_read, policy_search |
| forbidden actions | close case, submit SAR |
| policy constraints | high-risk escalation, citation required |
| success criteria | summary covers key evidence |
| failure criteria | missing red flag, unauthorized action |
BA 要避免只写 happy path。高价值场景通常是:
- 用户说错信息。
- 数据缺失。
- 工具超时。
- 政策冲突。
- 需要拒绝。
- 需要转人工。
8. 架构师视角: Eval Environment
参考架构
Eval Runner
-> Scenario Loader
-> User Simulator
-> Agent Runtime
-> Tool Sandbox
-> Policy Oracle
-> Trace Store
-> Metric Engine
-> Report Generator
关键设计
| Design area | Requirement |
|---|---|
| Sandbox isolation | 不能写生产系统 |
| Determinism | 关键场景可重复 |
| Trace schema | message、tool、state、policy、decision |
| Secret handling | eval 不泄露真实 PII |
| Versioning | model/prompt/tool/scenario/eval version |
| Regression | 每次 release 比较上一版本 |
| Failure triage | 自动标记 tool、policy、reasoning、retrieval、UX 问题 |
9. 金融零售 Agent 场景库
| Scenario | Agent task | Critical controls |
|---|---|---|
| AML alert triage | 汇总证据、生成调查计划 | 不关闭 alert、不提交 SAR |
| KYC onboarding | 检查材料、提出缺失项 | 不绕过 required docs |
| Payment dispute | 查证交易、生成 dispute note | 不承诺退款 |
| Credit underwriting | 汇总文件、生成 rationale | 不自动批准/拒绝 |
| Customer service | 回答政策、创建 case | 不误导销售、不泄露 PII |
| Fraud investigation | 串联账户和交易 | 高风险冻结必须审批 |
| Complaint handling | 分类、建议回复 | 合规话术和 SLA |
10. LLM-as-Judge 的边界
Agent eval 可以用 LLM judge，但不能只靠它。
| 适合 LLM judge | 不适合只靠 LLM judge |
|---|---|
| summary quality | 是否违规执行工具 |
| helpfulness | 权限泄露 |
| completeness 初筛 | 资金冻结/关闭账户 |
| tone | 法规硬规则 |
推荐:
- hard rules 先行。
- expected state comparison。
- LLM judge 做语义质量。
- SME 抽样校准。
- judge drift 也要监控。
11. 作品集输出
| Artifact | 内容 |
|---|---|
| Agent Eval Scenario Pack | 20 个金融零售 agent 场景 |
| Tool Sandbox Spec | mock tools、state、error injection |
| Policy Oracle Matrix | allowed/forbidden actions and rules |
| Agent Eval Dashboard | task success、policy compliance、tool accuracy、cost |
| Release Gate Memo | 是否进入 pilot 的证据 |
12. 面试表达
30 秒版本
Agent 评测不能只看回答是否好，而要看它在多轮任务中是否正确调用工具、维护状态、遵守政策、处理异常、触发人工审批并留下审计证据。AgentBench 和 τ-bench 的价值在于把评测放进环境和工作流里。
2 分钟版本
我会把企业 agent eval 设计成 scenario library、user simulator、tool sandbox、policy oracle、trace collector、metric engine 和 release gate。以 AML agent 为例，scenario 里要有客户画像、交易、prior alerts、allowed tools、forbidden actions、success criteria 和 failure criteria。指标包括 task success、policy compliance、tool call accuracy、state consistency、HITL trigger precision、cost、latency 和 trace completeness。高风险金融场景中，critical policy violation、permission leakage、high-risk action without approval 都必须是 0。
CTO 深挖
技术上要把 eval environment 和 production runtime 解耦，但共享 tool contract、policy rules 和 trace schema。这样 eval 才能真实反映生产行为，又不会污染生产数据。
BA 深挖
BA 的价值是把真实流程和异常转成可评测场景。没有高质量 scenario library，agent eval 就会停留在 demo 问答，无法证明系统能处理真实业务。
13. 复习问题
- Agent eval 和 chatbot eval 的核心差异是什么？
- 为什么 tool sandbox 是必须的？
- τ-bench 对企业 agent 有什么启发？
- Policy oracle 应该包含哪些硬规则？
- 哪些指标能证明 agent 可以进入 pilot？
- 为什么 task success 高不代表可以上线？
- 如何把 agent eval 结果讲给 PM、CTO、Risk 三类人？