SWE-bench / WebArena / OSWorld：Agent 工程评测基准
SWE-bench、WebArena、OSWorld 和 GAIA 的共同价值不是给 agent 排名，而是把模型放进真实或近真实环境：它必须理解目标、读取状态、调用工具、修改环境、处理反馈、恢复错误并交付可验证结果。它们把“能聊天”与“能完成工作”分开评测。
SWE-bench / WebArena / OSWorld / GAIA 解读
Source Anchors
| Source | Link | 读它要抓住什么 |
|---|---|---|
| SWE-bench | https://www.swebench.com/ | 真实 GitHub issue、代码修改和测试通过评测 |
| SWE-bench GitHub | https://github.com/SWE-bench/SWE-bench | 任务数据和评测 harness |
| WebArena | https://webarena.dev/ | 真实网站环境中的 web agent 任务 |
| WebArena Paper | https://arxiv.org/abs/2307.13854 | web navigation、stateful tasks 和 environment evaluation |
| OSWorld | https://os-world.github.io/ | 桌面操作系统环境中的 multimodal agent benchmark |
| GAIA | https://arxiv.org/abs/2311.12983 | 通用助手的多工具、多步骤任务 |
| AgentBench | https://arxiv.org/abs/2308.03688 | 多环境 agent 评测框架 |
核心导读
SWE-bench、WebArena、OSWorld 和 GAIA 的共同价值不是给 agent 排名，而是把模型放进真实或近真实环境：它必须理解目标、读取状态、调用工具、修改环境、处理反馈、恢复错误并交付可验证结果。它们把“能聊天”与“能完成工作”分开评测。
这类 benchmark 的系统启发是，agent 能力由环境、任务、工具、状态和成功标准共同定义。架构上要关注可执行验证、环境隔离、隐藏测试、状态回滚、错误恢复和 trace 证据，而不是把最终回答当作完成证明。
1. 核心问题：聊天能力不等于任务完成能力
普通 LLM 评测经常看答案是否正确、文字是否流畅、是否安全拒答。Agent 评测要看的是另一类能力：模型能否在环境中完成一个带状态变化的目标。
一个 agent 任务通常包含：
Goal
-> Observe environment
-> Plan next action
-> Use tool / UI / code / browser
-> Environment changes
-> Observe result
-> Recover or continue
-> Finish with verifiable outcome
这比单轮问答难得多，因为失败可能发生在任何环节：
| 环节 | 失败方式 |
|---|---|
| 目标理解 | 把业务目标误解成文本摘要任务 |
| 状态读取 | 漏看页面状态、代码依赖、历史记录或权限限制 |
| 计划 | 步骤顺序错误，缺少验证或回滚 |
| 工具使用 | 点错按钮、改错文件、调用错误 API |
| 反馈处理 | 工具失败后继续编造成功 |
| 完成判断 | 未达到真实成功条件就宣称完成 |
真实环境 benchmark 的价值，是让这些失败暴露出来。
2. SWE-bench：结果必须通过真实测试
SWE-bench 用真实 GitHub issue 和 repository state 评估 agent 是否能修复代码。
任务链条是：
issue description
-> inspect repo
-> identify root cause
-> edit code
-> run or infer tests
-> submit patch
-> hidden / official tests evaluate
它的重要启发是：agent 输出不能只靠“看起来合理”的解释判分，而要通过环境验证。
SWE-bench 对企业 AI 的映射很直接：
| SWE-bench 对象 | 企业映射 |
|---|---|
| GitHub issue | 业务工单、客户问题、缺陷、合规需求 |
| Repository | 业务系统、流程、政策库、数据模型 |
| Patch | Agent 的具体变更或操作 |
| Test suite | 业务规则、回归测试、审批门禁 |
| Hidden tests | 未暴露给 agent 的生产边界案例 |
这说明 Agent 评测不能只评最终文本。只要 agent 会改变系统状态，就必须有可执行验证。
3. WebArena：网页任务暴露状态和交互复杂度
WebArena 把 agent 放进真实网站环境，让它完成跨页面、多步骤、状态依赖任务。
这类 benchmark 关注：
- 能否理解页面结构。
- 能否找到正确入口。
- 能否跨页面保持目标。
- 能否处理表单、列表、筛选、权限和结果确认。
- 能否识别完成状态。
企业里的对应场景很多：
| WebArena 能力 | 金融零售映射 |
|---|---|
| 导航多个页面 | 在 CRM、case system、knowledge base 之间切换 |
| 填写表单 | 创建工单、提交补件、更新 case fields |
| 状态确认 | 确认请求是否真的提交成功 |
| 权限处理 | 不越权读取或写入客户信息 |
| 多步骤目标 | 完成投诉处理、KYC remediation、支付争议初审 |
WebArena 提醒我们：UI agent 的风险不只是“回答错”，而是“在真实系统里点错、改错、提交错”。
4. OSWorld：桌面和多模态环境更接近真实工作
OSWorld 评估 agent 在桌面操作系统中的任务完成能力。它引入了更复杂的环境：
- 图形界面。
- 文件系统。
- 应用程序之间切换。
- 视觉理解。
- 长任务状态。
- 无结构化 API 的操作。
企业知识工作中，很多任务并没有干净 API。员工可能在 Excel、PDF、内部网页、邮件、工单系统和桌面应用之间切换。OSWorld 的启发是：如果 agent 要进入员工工作台，它必须处理混合界面和非理想环境。
但这也意味着更强控制需求：
| 风险 | 需要的控制 |
|---|---|
| 文件误操作 | sandbox、只读模式、确认步骤 |
| 敏感信息泄露 | 屏幕/文件权限、masking、日志治理 |
| 不可逆提交 | human approval、dry-run、undo |
| 观察错误 | visual grounding eval、UI state assertions |
| 长任务漂移 | checkpoint、step verification、timeout |
桌面 agent 能力越强，越需要操作系统级和应用级边界。
5. GAIA：通用助手任务是多能力组合
GAIA 关注多步骤、多工具、需要推理和外部信息的通用任务。它强调一个事实：真实助手任务不是单一能力，而是组合能力。
一个 GAIA 风格任务可能需要：
- 分解问题。
- 查找信息。
- 使用工具。
- 处理文件或网页。
- 进行推理。
- 校验答案。
- 给出最终结果。
对企业来说，这说明 agent eval 应该覆盖端到端任务，而不是只测某个工具调用是否成功。
例如“帮我准备某客户的续贷审查材料”可能包含：
- 读取客户账户和历史贷款。
- 检索当前政策。
- 检查缺失文件。
- 汇总风险指标。
- 生成审查材料草稿。
- 标出必须人工判断的事项。
- 不得自动做审批决定。
这不是一个 QA benchmark 能覆盖的。
6. Agent Benchmark 的设计模式
从这些 benchmark 可以抽象出一套企业 Agent 评测结构。
| 组成 | 含义 |
|---|---|
| Environment | agent 能观察和操作的系统、网页、代码库、桌面或 sandbox |
| Task goal | 明确的业务目标和约束 |
| Initial state | 环境起始状态、权限、数据版本 |
| Action space | agent 被允许的工具、点击、编辑、API |
| Observation | agent 每步能看到什么反馈 |
| Success condition | 如何客观判断完成 |
| Failure condition | 什么动作立即失败或触发升级 |
| Trace | 每步操作、工具调用、状态变化和输出 |
企业评测不能只写“让 agent 处理一个工单”。要把环境、动作和判分标准写清楚。
7. 为什么 benchmark 分数不能直接等于上线信心
公开 benchmark 有价值，但不能替代企业内部 release gate。
原因：
| 局限 | 企业影响 |
|---|---|
| 环境不同 | 公开网站/代码库不等于内部 CRM、core banking、case system |
| 成功标准不同 | benchmark 通过不代表满足合规、审计和客户权益要求 |
| 数据分布不同 | 内部流程、政策、产品和异常案例不同 |
| 权限模型不同 | 企业 agent 必须受 least privilege、SoD、人审控制 |
| 失败成本不同 | benchmark 失败只是扣分，生产失败可能影响客户和监管 |
| 可观测性不同 | 上线后必须有 replay、trace、incident 和 rollback |
因此，公开 benchmark 适合做能力理解和候选模型筛选。真正上线前必须建设自己的 task suite 和 sandbox。
8. 金融零售 Agent Eval 场景库
8.1 Payment Dispute Agent
任务：根据客户争议、交易记录、商户信息和政策，准备初审材料。
评测重点：
| 维度 | 成功标准 |
|---|---|
| Evidence collection | 找到交易、客户声明、商户响应、时限要求 |
| Policy application | 正确引用 chargeback 规则和例外 |
| Action boundary | 不自动退款、不关闭争议 |
| Output | 生成结构化初审摘要和缺失证据 |
| Escalation | 高风险或证据冲突时升级人工 |
8.2 KYC Operations Agent
任务：检查企业客户补件是否满足开户要求。
评测重点：
| 维度 | 成功标准 |
|---|---|
| Document recognition | 正确识别文件类型和版本 |
| Entity consistency | 法人、UBO、地址、注册号一致性 |
| Policy matching | 根据地区和客户类型匹配要求 |
| Communication draft | 只生成补件草稿，不直接发送 |
| Privacy | 不把敏感字段暴露到无关上下文 |
8.3 AML Investigation Agent
任务：辅助调查 alert，但不做最终 suspicious / not suspicious 决定。
评测重点：
| 维度 | 成功标准 |
|---|---|
| Case state reading | 正确读取 alert、交易、历史 case、客户画像 |
| Typology hypothesis | 提出有证据支持的假设和反证 |
| Tool use | 正确调用 graph、transaction、KYC、sanctions 工具 |
| Narrative draft | 不夸大，不补事实，不替代 investigator decision |
| Traceability | 每个结论都能追溯到 evidence |
9. Agent Release Gate
一个高风险 enterprise agent 的 release gate 至少包括：
| Gate | 要求 |
|---|---|
| Task success | 在内部 task suite 上达到最低成功率 |
| Critical failure | 零容忍动作不能发生，如越权写入、错误提交、泄露 |
| Recovery | 工具失败、权限不足、数据缺失时能停止或升级 |
| Trace quality | 每步工具调用和状态变化可 replay |
| Human handoff | 高风险状态下能交给人类并保留上下文 |
| Cost and latency | 在目标流量下满足预算和 SLO |
| Regression | prompt、模型、工具、UI 更新后重新跑关键任务 |
这里的 release gate 比普通 LLM eval 更接近软件系统验收，因为 agent 会改变环境。
10. 常见误读
| 误读 | 更准确的理解 |
|---|---|
| Agent benchmark 高就能上线 | 公开 benchmark 只能说明一般能力，不能证明内部流程安全 |
| Agent eval 就是最终答案评分 | 还要评估环境操作、状态变化、工具使用和恢复能力 |
| Web/desktop agent 只是 UX 增强 | 它可能执行真实业务动作，需要权限和审计 |
| 失败一次重试即可 | 重试可能重复提交、覆盖状态或扩大损害 |
| 只要加 human approval 就安全 | 人审需要完整 trace、差异高亮和明确责任边界 |
11. 学习验证
读完这组 benchmark 后，建议为一个金融零售 agent 写内部评测设计，而不是只记录公开榜单。
最小产物：
| 部分 | 内容 |
|---|---|
| Environment spec | agent 可访问的系统、工具、数据和权限 |
| Task suite | 20-50 个真实或合成任务，覆盖正常、异常和高风险路径 |
| Success oracle | 每个任务如何客观判断成功 |
| Critical failures | 哪些动作直接判失败 |
| Trace schema | 记录目标、观察、动作、工具、状态和最终输出 |
| Release gate | 成功率、零容忍失败、人工升级、成本和延迟门槛 |
| Regression plan | 模型、prompt、工具或 UI 变更后如何回归 |
真正掌握这些 benchmark 的标志，是能解释为什么 agent 的评测对象不是“回答”，而是“在受控环境中完成有状态任务的能力”。
SOTA 状态标注 (2026-07-01)
本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。