AgentBench / τ-bench：Agent 环境评测
AgentBench 和 τ-bench 的价值不在于给 agent 排名，而在于重新定义评测对象：agent 不是单轮回答器，而是由模型、工具、状态、用户交互、业务规则、异常恢复和审计证据组成的运行系统。评测必须覆盖 action-observation loop，而不是只看最终文本。
AgentBench / τ-bench / Agent Evaluation 解读
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 的评测组织方式 |
核心导读
AgentBench 和 τ-bench 的价值不在于给 agent 排名，而在于重新定义评测对象：agent 不是单轮回答器，而是由模型、工具、状态、用户交互、业务规则、异常恢复和审计证据组成的运行系统。评测必须覆盖 action-observation loop，而不是只看最终文本。
生产级 agent 需要在受控环境里证明会完成任务、遵守规则、保留证据，并在失败时安全退出。架构上要把 scenario library、tool sandbox、policy oracle、trace collector 和 metric engine 做成发布门禁，否则 benchmark 分数无法转化为上线信心。
1. 核心问题：Agent 评测不是 Chatbot 评测
普通聊天助手的评测通常关注：
- 回答是否正确。
- 是否有帮助。
- 是否有害。
- 是否 grounded。
Agent 评测要困难得多。因为 agent 不只是回答，它会在多轮交互中读取状态、调用工具、修改草稿、触发流程、等待用户补充信息，并受到业务规则约束。
企业 agent 的真实评测对象是：
Model + Prompt + Tools + Memory + Workflow + Policy + UI + Human Oversight
如果只评估最终回复，就会漏掉最重要的风险：
| 风险 | 例子 |
|---|---|
| 工具调用错误 | 查错客户、传错 case_id、使用错误日期 |
| 状态管理错误 | 用户改口后仍沿用旧约束 |
| 政策违规 | 未经审批关闭 alert、承诺退款、绕过 KYC |
| 权限泄露 | 把内部 notes 或 PII 输出给不该看到的人 |
| 异常恢复失败 | 工具超时后编造结果 |
| 审计证据不足 | 事后无法解释为什么做了某个动作 |
AgentBench 和 τ-bench 共同推动的方向，是把 agent 放入环境中评测，而不是只把 prompt 发给模型。
2. AgentBench 的贡献：环境化评测
AgentBench 把 LLM 作为 agent 放到多个环境里执行任务，例如 operating system、database、knowledge graph、web shopping、games、household tasks。
它对企业的启发不是照搬这些任务，而是理解“环境化评测”的必要性。
| Benchmark 思想 | 企业迁移 |
|---|---|
| agent interacts with environment | agent 与 CRM、case system、policy DB、payment tool 交互 |
| action changes state | 工单、草稿、审批状态、日志会变化 |
| success depends on sequence | 任务成功取决于多步调用顺序 |
| observation matters | 工具返回影响下一步计划 |
| measurable completion | 业务结果和合规结果都要可判定 |
这与传统 QA benchmark 很不同。一个模型能回答“如何处理支付争议”，不代表它能在真实流程中查交易、识别时限、读取商户证据、生成 dispute note、避免承诺退款、留下审计 trace。
AgentBench 的核心启发是：agent 能力必须在 action-observation loop 中评估。
3. τ-bench 的贡献：工具、用户和规则同时进入评测
τ-bench 更接近企业 agent 场景，因为它强调 tool-agent-user interaction。
一个真实任务通常同时包含：
- 用户目标。
- 多轮对话。
- 工具 API。
- 业务规则。
- 隐藏状态。
- 成功条件。
- 失败条件。
这对金融零售尤其关键。一个 customer service agent 可能需要同时满足客户想要退款、系统里交易状态、网络规则、客服权限、投诉升级规则和合规话术。
τ-bench 的元素可以迁移为：
| τ-bench 元素 | 金融零售映射 |
|---|---|
| User simulator | 客户、柜员、调查员、underwriter、主管 |
| Tool APIs | CRM、case、payment、policy、KYC、fraud、document tools |
| Policy | 合规、权限、审批、话术、产品规则 |
| Goal | 解决 dispute、完成 KYC、汇总 alert、生成草稿 |
| Evaluation | task success + policy compliance + trace completeness |
它提醒我们，agent 评测必须同时看“有没有完成任务”和“有没有用正确方式完成任务”。
4. 机制原理：企业 Agent Eval Stack
一个可落地的 agent eval stack 可以设计成：
Scenario Library
-> User Simulator
-> Tool Sandbox
-> Policy Oracle
-> Agent Runtime
-> Trace Collector
-> Metric Engine
-> Human Review Sample
-> Release Gate
4.1 Scenario Library
Scenario 是 agent eval 的基础资产。它不只是问题列表，而是包含初始状态、用户目标、工具约束、政策规则和预期结果的可执行场景。
一个场景应包含：
| Field | 内容 |
|---|---|
| scenario_id | aml_triage_001 |
| user role | investigator |
| user goal | triage alert and draft summary |
| initial state | customer profile、transactions、prior alerts |
| hidden facts | expected red flags or examiner-only facts |
| allowed tools | case_read、transaction_read、policy_search |
| forbidden actions | close case、submit SAR、freeze account |
| policy constraints | escalation、citation、approval |
| success criteria | summary covers key evidence and missing items |
| failure criteria | missed red flag、unauthorized action、unsupported claim |
高质量场景必须覆盖 happy path 之外的情况：信息缺失、用户改口、工具失败、政策冲突、权限不匹配、恶意输入和高风险升级。
4.2 User Simulator
User simulator 让 agent 经历多轮交互，而不是一次性拿到所有信息。它可以模拟客户提供模糊或错误信息、调查员逐步追问、underwriter 要求解释政策例外、用户改变目标、客户诱导 agent 绕过流程。没有 user simulator，评测很容易变成静态问答，无法发现状态管理和澄清能力问题。
4.3 Tool Sandbox
Agent eval 不能直接连生产系统。
Tool sandbox 需要提供 mock API、synthetic records、reversible state、deterministic responses、error injection、permission simulation 和 complete audit trace。它的目标不是做一个漂亮 demo，而是让每次评测可重复、可比较、不会污染真实数据。
4.4 Policy Oracle
Policy oracle 判断 agent 是否违反硬规则。
它不能只靠 LLM judge。金融零售中的很多规则必须确定性判断：
| Rule type | 示例 |
|---|---|
| Forbidden action | 不得自动关闭 AML alert |
| Permission | 当前角色不得读取某类 PII |
| Approval | 高风险冻结必须 supervisor approval |
| Citation | 政策结论必须有 active source |
| Customer promise | 不得承诺退款或贷款批准 |
| Data handling | 不得把内部 notes 输出给客户 |
LLM judge 可以评估摘要质量、语气和语义完整性，但硬规则应由规则引擎、expected state comparison 和人工抽样校准共同支撑。
5. 为什么有效：把“会聊天”转成“会完成受控工作流”
AgentBench / τ-bench 有效，是因为它们改变了评测单元。
单轮评测问的是：
Given input, is output good?
Agent 评测问的是：
Given a goal, tools, state, user behavior, and policies,
can the system reach an acceptable final state without unsafe actions?
这个差异非常重要。
一个 agent 可能最终回复写得很好，但中间调用了错误工具；也可能完成任务，但违反了审批规则；也可能遵守规则，但过度升级导致业务不可用。只有环境化评测才能暴露这些 trade-off。
指标也要从回答质量扩展到系统质量：
| 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 | 是否能审计 | 合规和事故复盘 |
6. 局限和误用
Agent eval 也有常见误区。
| 误用 | 问题 | 更稳妥做法 |
|---|---|---|
| 只用通用 benchmark | 与业务工具和政策脱节 | 建立领域 scenario library |
| 只看 task success | 可能用违规方式完成任务 | task success 和 policy compliance 同时 gate |
| 只靠 LLM-as-judge | 硬规则和权限无法稳定判断 | rule oracle + state comparison + SME sampling |
| 场景全是 happy path | 上线后被异常击穿 | 覆盖缺失、冲突、超时、恶意输入 |
| eval environment 与生产差异过大 | 评测结果不可迁移 | 共享 tool contract、policy rules、trace schema |
| 指标没有 release gate | 评估报告无法转决策 | 定义 pilot / release / rollback 条件 |
还要警惕“demo 成功幻觉”。一个 agent 在 5 个精心设计的问题上表现很好，不代表它能处理真实业务分布。高风险场景需要回归集、红队集、长尾异常和版本对比。
7. 架构和产品价值：Eval Environment 是上线基础设施
企业 agent eval environment 应与生产 runtime 解耦，但共享关键契约。
Eval Runner
-> Scenario Loader
-> User Simulator
-> Agent Runtime
-> Tool Sandbox
-> Policy Oracle
-> Trace Store
-> Metric Engine
-> Report Generator
关键设计：
| Design area | Requirement |
|---|---|
| Sandbox isolation | 不写生产系统、不接触真实 PII |
| Determinism | 关键场景可重复 |
| Tool contract | 与生产工具共享 schema 和 permission model |
| Trace schema | message、tool、state、policy、decision、version |
| Versioning | model、prompt、tool、scenario、eval version 全部记录 |
| Regression | 每次 release 与上一版本比较 |
| Failure triage | 自动标记 tool、policy、reasoning、retrieval、UX 问题 |
| Human review | 对高风险失败和 borderline pass 抽样 |
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% |
这些阈值不是通用真理，而是说明 agent release decision 必须有明确证据。上线不是“感觉差不多”，而是“在哪些场景、指标和风险接受条件下可以 pilot”。
8. 金融零售 Agent 场景库
一个作品级金融零售 agent eval pack 可以从以下场景开始：
| 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 |
8.1 AML Alert Triage
场景设计应包含客户 KYC、现金交易、历史 alert 和分支机构信息；user simulator 扮演调查员逐步询问 red flags；allowed tools 包括 transaction_read、customer_profile_read、policy_search；forbidden actions 包括 close_alert、submit_SAR；success criteria 是发现关键红旗、列出缺失证据、生成调查草稿。
评测重点不是文笔，而是是否覆盖关键证据、是否避免过度结论、是否正确触发 supervisor review。
8.2 Payment Dispute Agent
场景设计可以让用户声称未收到商品，工具返回交易、商户证据、物流状态和争议时限，用户中途要求“保证退款”。policy oracle 检查 agent 是否避免承诺退款，并是否按规则创建 dispute note。
这个场景能测试多轮状态、政策约束和客户沟通边界。
8.3 Credit Underwriting Assistant
场景设计可以设置申请材料缺少收入证明、DTI 接近阈值、用户要求解释是否能批准。agent 可以总结材料和政策，但不能批准、拒绝或生成不合规 adverse action reason。
评测重点是 evidence completeness、policy citation、human review trigger 和限制表达。
9. LLM-as-Judge 的边界
Agent eval 可以使用 LLM judge，但要明确边界。
| 适合 LLM judge | 不适合只靠 LLM judge |
|---|---|
| summary quality | 是否违规执行工具 |
| helpfulness | 权限泄露 |
| completeness 初筛 | 资金冻结、关闭账户、提交 SAR |
| tone and clarity | 法规硬规则 |
| semantic comparison | final state 是否被错误修改 |
推荐组合：
- hard rules 先行。
- expected final state comparison。
- LLM judge 做语义质量和解释质量。
- SME 抽样校准 judge。
- 监控 judge drift。
如果 judge 自身没有版本管理和回归测试，eval 系统也会变成新的不稳定点。
10. 学习验证
学完 AgentBench / τ-bench，不应只会说“agent 要测工具调用”。要能设计一个完整 eval environment。
建议产出五个 artifact：
| Artifact | 内容 |
|---|---|
| Agent Eval Scenario Pack | 20 个金融零售 agent 场景 |
| Tool Sandbox Spec | mock tools、state、error injection、permission simulation |
| Policy Oracle Matrix | allowed / forbidden actions、approval rules、citation rules |
| Agent Eval Dashboard | task success、policy compliance、tool accuracy、cost、latency |
| Release Gate Memo | 是否进入 pilot 的证据和限制 |
练习问题：
- 选一个 agent，写 5 个 normal cases 和 5 个 edge cases。
- 为其中一个场景定义 allowed tools、forbidden actions 和 expected final state。
- 设计一个 tool failure injection case，并说明如何区分 tool、reasoning、policy 和 UX failure。
- 解释为什么 task success 高但 policy violation 高时不能上线。
完成这些练习后，agent evaluation 就会从“跑几个测试问题”变成真正的上线决策体系。
SOTA 状态标注 (2026-07-01)
本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。