Deep Research Report · 2026

AI Agent Benchmark 对基础设施的启示与诉求
——从评估结果反推 Infra 架构设计

Benchmark 不是考卷，而是基础设施的《需求规格说明书》。每一个低分、每一次失败、每一笔成本，都在向底层系统提出明确的架构诉求。本报告基于 2024–2026 年全球 40+ 项 AI Agent 基准的论文、官方报告与发布资料，系统性反推基础设施必须提供的能力，并对比中国与海外大厂的 Infra 实践差异。

报告日期：2026 年 7 月 27 日 覆盖基准：40+ 项 核实引用：50 条（全部可在 arXiv / 官网检索） 语言：中文

执行摘要Executive Summary

2024–2026 年，AI Agent 基准从「单轮问答」演变为「真实环境、长时程、多工具、多智能体」的系统级考核，评测对象事实上已经从模型转向「模型＋脚手架＋基础设施」的整体。本报告逐章分析九类基准暴露的问题，得出五条核心结论：其一，环境即算力——SWE-Universe 将可验证环境扩展到 807,693 个[4]，OSWorld-Verified 通过 AWS 并行将全量评测压缩到 1 小时内[7]，沙盒集群的启动速度、镜像复用与调度效率已直接决定迭代速度；其二，评测权正在从学术榜转向生产榜——OpenAI 于 2026 年 2 月正式弃用被污染且 59.4% 难题测试有缺陷的 SWE-bench Verified[46]，中国大厂自研基准（SWE-Universe、EdgeBench、C³-Bench 等）成为生产落地的真实规格；其三，记忆正在从上下文窗口外迁为独立服务——BEAM（10M token）与 LongMemEval（1.5M token）证明纯上下文路线不可持续[9][10]；其四，安全评估驱动零信任架构——AgentDojo 中 GPT-4o 在攻击下效用从 69% 跌至 50%[25]，BenchJack 证明 10 个主流基准中 9 个可在不解题的情况下被刷到接近满分[43]；其五，评估基础设施本身成为核心竞争力——HAL 用 21,730 次 rollout、约 4 万美元完成三维分析[32]，没有规模化轨迹数据库与成本归因能力的团队将在 Agent 竞争中处于信息劣势。

807,693
SWE-Universe 可验证环境数，来自 52,960 个 GitHub 仓库 [4]
≈100% → <10%
BenchJack 审计下主流基准的可破解率，经 3 轮迭代修复后 [43]
12–72 小时
EdgeBench 单任务连续运行时长，长期学习评估的时代开启 [37]
21,730 次
HAL 的 rollout 规模，覆盖 9 模型 × 9 基准，总成本约 $40,000 [32]
10M token
BEAM 最长会话规模，1M 上下文模型+ RAG 依然随对话变长而失效 [9]
2.5B token
HAL 公开的 Agent 日志总量，轨迹数据成为新生产资料 [32]

调研方法与勘误声明Methodology & Corrections

本报告执行了多轮交叉检索，对全部拟引用论文逐一在 arXiv 原始页面核实编号、作者、机构与关键数字；对会议接收信息以论文自述与官方页面为准。为遵守「不编造、不造假」原则，凡无法独立核实的信息均明确标注，凡任务设定与事实不符之处均以勘误形式修正如下。文中量化标记分两类：实测表示直接来自论文/官方资料的数字；推导表示本报告基于工程经验给出的架构设计目标值，非论文结论。

⚠ 对研究任务书的四处事实勘误（均以可检索来源为准）

  • EcomBench 的归属：论文作者页明确标注为「Tongyi Lab, Alibaba Group」（阿里通义实验室）[40]，并非京东。京东真实的 Agent 基础设施实践是开源多智能体产品 JoyAgent-JDGenie（GAIA 验证集 75.15%）[45]，本报告第八章按事实归属分别撰写。
  • VoiceAgentEval 的归属：该基准由声网、美团、xbench 三方于 2026 年 2 月联合发布，其中 xbench 是红杉中国推出的基准工具而非美团自有平台；美团的核心贡献是 150 人设用户模拟器[14]。其 arXiv 版本（2510.21244）标题为 VoiceAgentEval，但正文以 OutboundEval 命名[13]。
  • C³-Bench 的会议信息：任务书标注「ICLR 2026」，本报告未能在公开渠道独立核实该接收信息，故统一按 arXiv 预印本（2505.18746，腾讯，2025 年 5 月）引用[19]。
  • QwenClawBench 的性质：该基准未见公开论文，仅作为阿里内部真实世界智能体基准出现在 Qwen3.6 发布对比中，属「自家模型自家测」的内部基准，其分数不应作为第三方客观指标引用。

阅读约定：2024 年及以前的基准标注 经典基准；2025–2026 年文献标注 最新。引用分数时均注明模型与脚手架配置背景；同一模型在不同脚手架下分数可相差 20–30 分（详见第七章 HAL 的三维分析[32]）。

第一章 执行环境层Execution Environment：代码与桌面 Agent 暴露的隔离、复现与规模化瓶颈

核心问题：代码 Agent 与桌面 Agent 的评估暴露了哪些环境隔离、复现性与规模化瓶颈？
核心洞察环境本身已成为一种「新型算力」。代码基准的竞争从「谁的分高」转向「谁能以最低成本、最高保真度、最大规模生产和运行可验证环境」；隔离级别、启动延迟与镜像复用率取代单卡算力，成为 Agent Infra 的一阶约束。

1.1Benchmark 问题分析

环境配置漂移是 SWE-bench 系列的「原罪」。SWE-bench（ICLR 2024，2,294 个真实 GitHub issue）经典基准[1] 的评分依赖在隔离容器中执行仓库测试套件；OpenAI 在发布 SWE-bench Verified 时明确指出三大系统性噪声：单元测试与 issue 无关、问题描述欠规范、以及「开发环境难以可靠搭建，导致正确答案被误判」[2]。2024 年 6 月，SWE-bench 官方在 OpenAI 支持下全面转向 Docker 容器化评测 harness，正是对依赖冲突、Python 版本与系统库差异的直接回应。2026 年 2 月，OpenAI 进一步审计其模型未能解决的 138 道最难题目，发现 59.4% 存在测试缺陷（拒绝了功能正确的补丁），加之全部 500 题均可被前沿模型逐字复述「金补丁」（训练污染），OpenAI 宣布停止报告 SWE-bench Verified 分数[46]。Scale AI 的 SWE-bench Pro（1,865 题、41 个仓库，Public 731 / Held-out 858 / Commercial 276 三分法）则把抗污染与工业级长链路任务作为设计目标，前沿模型得分仅约 23%–25%，区分度显著[3]。

规模化生产环境是下一个数量级战争。阿里 Qwen 团队的 SWE-Universe（arXiv:2602.02361，2026 年 2 月）最新[4] 从 GitHub 近五年约 3,330 万个 PR 中筛选约 100 万候选，用定制 MoE 构建模型（Qwen-Next-80A3，构建成功率 78.44%，超过 Claude-Opus-4.5 的 77.81%）自动合成 Docker 环境＋验证脚本，最终产出 807,693 个多语言可验证环境（52,960 个仓库、8 类语言）。论文披露的基础设施栈极具参考价值：每个构建任务分发到一台独立的阿里云 ECS 沙盒 VM，验证后的镜像推送到容器镜像服务（ACR）并利用 Docker 层缓存复用基础层以大幅压缩存储成本；整套流程由分布式长任务编排系统 MegaFlow 调度；环内 hacking 检测器即时拒绝 grep 字符串匹配式的「假验证器」，迭代自检将构建成功率从 82.6% 提升至 94%[4]。

终端与桌面环境把「副作用」与「实时性」推向前台。Terminal-Bench（Stanford/Laude Institute，arXiv:2601.11868）[5] 要求 Agent 在真实终端完成困难任务，命令执行的副作用（文件污染、网络外联、权限提升）要求沙盒具备不可变文件系统与最小权限网络策略。OSWorld（NeurIPS 2024，369 个真实计算机任务）经典基准[6] 及其 2025 年 7 月更新的 OSWorld-Verified 证明：桌面评测必须跑在完整 VM（VMware/VirtualBox/AWS/Azure/Docker 后端）中，Verified 版本通过 AWS 并行化把全量评测时间压缩到 1 小时以内[7]。Windows Agent Arena（Microsoft，2024，150+ 任务）经典基准[8] 则要求 Windows UI Automation 桥接与 Azure 虚拟机集成。值得注意的是，BenchJack 审计发现 OSWorld、WebArena 等环境型基准在修复前可被 100% 破解，修复信任边界（如不重置任意文件）后可降至 0%[43]——环境的安全设计与正确性设计同等重要。

1.2基础设施诉求

  • 推导沙盒冷启动 <5s（容器）、microVM 快照恢复 <1s：SWE 类评测单任务数十次容器重建，启动时间直接放大为评测周期；OSWorld-Verified 的 1 小时全量评测目标[7] 倒逼镜像预热池与按需快照。
  • 实测镜像分层存储与复用：SWE-Universe 以 Docker 层缓存复用公共基础层，是百万级镜像存储可行的前提[4]；推导重复层命中率应 >80%，存储按「基础层—语言层—仓库层—任务层」四级分层。
  • 推导隔离分级矩阵：只读评测用容器（gVisor/Kata）、有副作用执行用 microVM（Firecracker 级）、桌面与内核级操作用完整 VM；审计粒度从应用级日志下沉到 syscall 级（seccomp/auditd 全程留痕）。
  • 推导不可变文件系统＋出站网络白名单：针对 Terminal-Bench 暴露的文件污染与权限提升，评测沙盒默认只读根文件系统、tmpfs 可写层、评估后自动销毁并产出差异报告。
  • 推导GUI 流式通道端到端 <100ms：OSWorld/WAA 类桌面 Agent 需要 VNC/RDP 低延迟流、无障碍树（a11y-tree/UIA）与像素双通道观测，以及跨应用状态同步的一致性快照。
  • 实测验证器可信度工程：环内 hacking 检测（拒绝 grep 式假验证器）＋「bug 态必须失败、修复态必须通过」的双态自检是 SWE-Universe 将构建成功率从 82.6% 提到 94% 的关键机制[4]。

1.3大厂实践对比

厂商环境基础设施实践可检索证据
阿里巴巴MegaFlow 分布式编排＋每任务独立 ECS 沙盒 VM＋ACR 镜像层缓存，支撑 807,693 环境构建与 50 万条成功轨迹（300 亿 token）的拒绝采样生产SWE-Universe 论文[4]
OpenAI推动 SWE-bench 全面 Docker 化；建立 500 题人工验证集；2026 年转向内部审计与弃用决策，并推荐 SWE-bench ProOpenAI 博客[2][46]
MicrosoftWindows Agent Arena 以 Azure VM 为评测底座，集成 Windows UIA 桥接WAA 论文[8]
学术界（xLang/Princeton 等）OSWorld 支持 VMware/VirtualBox/AWS/Azure/Docker 多后端；Verified 版 AWS 并行 <1 小时全量评测OSWorld 仓库与博客[6][7]
Princeton（HAL）标准化 harness 编排数百台 VM 并行评测，将评测周期从数周压缩到数小时HAL 论文[32]
关键引用：Jimenez et al., SWE-bench, ICLR 2024, arXiv:2310.06770 [1]；Chen et al., SWE-Universe, arXiv:2602.02361 [4]；Merrill et al., Terminal-Bench, arXiv:2601.11868 [5]；Xie et al., OSWorld, NeurIPS 2024, arXiv:2404.07972 [6]；Bonatti et al., Windows Agent Arena, arXiv:2409.08264 [8]。
图 1｜真实世界可验证 SWE 环境规模演进（对数坐标）。数据取自 SWE-Universe 论文 Figure 1[4]：SWE-bench 2,294 → SWE-Gym 2,438 → Multi-SWE-RL 4,723 → SWE-rebench 21,000 → DeepSeek-V3.2 24,667 → CWM 35,000 → MiMo-V2-Flash 90,000 → SWE-Universe 807,693。三年增长约 350 倍，环境生产能力成为核心竞争力。

第二章 推理与计算层Inference & Compute：长上下文、多模态与流式语音的引擎挑战

核心问题：长上下文、多模态、流式语音对推理引擎的架构挑战是什么？
核心洞察「把上下文窗口做大」在 1M token 量级之后边际收益急剧衰减：BEAM 显示 1M 上下文模型（含 RAG）随对话变长性能持续下滑[9]，LongMemEval_M 的 1.5M token 历史则直接超出任何窗口[10]。推理层的答案不是无限 prefill，而是 KV Cache 分层管理＋外部记忆＋流式流水线的系统工程。

2.1Benchmark 问题分析

超长记忆基准把 KV Cache 推到体系结构层面。BEAM（arXiv:2510.27246，2025 年 10 月）最新[9] 构建了 100 段最长 10M token 的连贯多主题会话与 2,000 个经验证问题，实验发现：即使拥有 1M token 上下文窗口的模型（无论是否叠加检索增强），性能都随对话增长而持续恶化；其配套 LIGHT 框架（情景记忆＋工作记忆＋草稿本三系统）相对最强基线平均提升 3.5%–12.69%。LongMemEval（ICLR 2025）[10] 以 500 个问题、S（约 115K token）/M（约 1.5M token）两档规模，考核信息抽取、多会话推理、知识更新、时间推理与拒答五项能力——其中「知识更新」直接要求系统处理同一事实的跨会话覆写，是 KV 驱逐策略与记忆一致性设计的试金石。这解释了为何 H2O（重点击中驱逐）[47]、StreamingLLM（注意力汇流）[48] 与 PagedAttention（分页式 KV 管理）[49] 成为长上下文服务化的基础组件。

多模态与语音把延迟预算切成毫秒级切片。VisualWebArena（ACL 2024，910 个视觉网页任务）经典基准[11] 与 OSWorld 要求 Agent 同时消费截图像素与结构化文本：视觉 token 的数量膨胀（高分辨率切分策略）直接冲击 prefill 成本与显存调度粒度。语音侧，声网×美团×xbench 的 VoiceAgentEval（2026 年 2 月发布）最新[14] 建立「文本＋语音」双维度评估：语音维度 15 项指标覆盖 ASR 准确率、响应延迟、打断成功率、音质与交互体验，其评测直接依托声网对话式 AI 引擎的真实运行平台采集[14]——这意味着流式 ASR→LLM→TTS 流水线的端到端延迟与中断处理已被纳入正式计分。

多步搜索的上下文爆炸重塑「长上下文 vs RAG」的边界。BrowseComp（OpenAI，2025，1,266 道需要多跳浏览才能回答的难题）[15] 类任务中，Agent 的浏览轨迹轻松超过 10 万 token；HAL 的日志分析还发现 Agent 会做出「去 HuggingFace 搜基准答案」等未预期行为[32]。推理引擎必须支持超长轨迹的增量 prefill 复用（前缀缓存）、轨迹级 KV 钉扎与驱逐，而非单请求视角的无状态调度。

2.2基础设施诉求

  • 推导KV Cache 三级存储（GPU HBM → CPU DRAM → SSD/远端）：PagedAttention 分页管理[49] ＋ H2O/StreamingLLM 驱逐策略[47][48]，目标 115K 级会话 prefill 复用命中率 >70%，长轨迹增量 prefill 成本下降一个数量级。
  • 推导前缀缓存与轨迹钉扎：BrowseComp 式多步搜索中，系统提示与已浏览页面 KV 应跨轮复用；Agent 工具调用的可预测短延迟可用于预判性缓存钉扎。
  • 推导视觉 token 压缩与显存细粒度调度：高分辨率截图按重要性切分与降采样，视觉编码与语言解码分池调度，单卡并发 GUI Agent 会话密度 ≥8。
  • 实测流式语音全链路指标入分：VoiceAgentEval 的 15 项语音指标（ASR 准确率、响应延迟、打断成功率等）已在真实 RTC 引擎上采集[14]；推导生产目标：端到端语音往返 <2s、打断响应 <300ms、中断后上下文无损恢复。
  • 推导长上下文 × RAG 混合路由：按查询类型在「全文注入 / 检索注入 / 记忆服务」三路间动态路由，BEAM 证明单一路线在 10M 规模下均失效[9]。

2.3大厂实践对比

路线代表实践证据与边界
上下文窗口扩张OpenAI / Google / Anthropic 持续扩大窗口（GPT、Gemini、Claude 系列），配合提示缓存折扣计费BEAM 证明 1M 窗口＋RAG 仍随对话变长退化[9]
推理引擎工程化vLLM PagedAttention 分页 KV 管理成为开源服务化事实标准[49]论文与开源生态可查
记忆外挂化BEAM 作者提出 LIGHT 三记忆系统，平均提升 3.5%–12.69%[9]；中国厂商普遍采用向量检索＋摘要分层（详见第四章）BEAM 论文
语音流水线声网对话式 AI 引擎承担 VoiceAgentEval 的真实运行评测平台，覆盖延迟、打断、音质采集[14]声网官方发布
训练-推理协同Moonshot Kimi K2：训练/推理双引擎同节点部署，Checkpoint Engine 分布式广播 30 秒完成 1T 参数热更新[44]K2 技术报告
关键引用：Tavakoli et al., BEAM, arXiv:2510.27246 [9]；Wu et al., LongMemEval, ICLR 2025, arXiv:2410.10813 [10]；Koh et al., VisualWebArena, ACL 2024, arXiv:2401.13649 [11]；Xu et al., VoiceAgentEval（OutboundEval）, arXiv:2510.21244 [13]；Wei et al., BrowseComp, arXiv:2504.12516 [15]。

第三章 工具与 API 网关层Tool & API Gateway：函数调用、状态化交互与工具供应链

核心问题：函数调用、客服场景、复杂工具关系对网关与编排引擎的诉求是什么？
核心洞察工具层评测的共同结论是：失败主因已从「不会调」转向「状态管理、依赖编排与供应链信任」。BFCL V4 把多轮状态与格式敏感性纳入计分[16]，τ²-bench 证明用户也能操作环境时性能显著下降[18]，C³-Bench 在 49 个主流 Agent 上系统暴露了工具依赖处理的缺陷[19]——网关必须从「转发器」升级为「有状态的编排与治理平面」。

3.1Benchmark 问题分析

函数调用的规模与形态同时膨胀。BFCL（Berkeley，Patil et al., ICML 2025）[16] 到 V4 已覆盖 Non-Live（1,150 例）、Live（1,381 例）、Multi-Turn（800 例，含 base/缺参/缺函数/长上下文四子集）与 Agentic（Web 搜索、记忆、格式敏感性）等维度，并在 2024 年 4 月率先把成本与延迟纳入榜单指标。ToolBench/ToolLLM（ICLR 2024）经典基准[20] 则从 RapidAPI 汇集 16,464 个真实 REST API（49 个类别），把「万级工具池中的检索—选择—调用」推为现实问题，直接要求网关具备限流（令牌桶/漏桶）与并发控制。

状态化交互是最难的一层。τ-bench（Sierra，arXiv:2406.12045）[17] 以航空与零售两个客服域、pass^k 指标（k 次独立试验全部成功的概率）度量策略一致性与状态可靠性；τ²-bench（arXiv:2506.07982）最新[18] 进一步把电信域建模为 Dec-POMDP 的双控环境——用户也通过工具修改共享世界状态，实验显示从「无用户」切换到「双控」后 Agent 性能显著下滑。这类基准要求网关维护会话状态机、补偿事务（undo/rollback）与领域策略引擎：策略违规不是模型问题而是系统缺位。C³-Bench（腾讯，arXiv:2505.18746）[19] 在 49 个主流 Agent 上用单变量分析拆解出三大失效源：复杂工具关系导航、关键隐藏信息处理、动态决策路径管理——工具依赖图执行引擎与工具发现治理成为明确诉求。

MCP 把工具生态变成供应链安全问题。MCPTox（中科大等，AAAI 2026，arXiv:2508.14925）最新[21] 在真实 MCP 服务器上系统评估工具投毒攻击：恶意服务器可通过工具描述注入操纵 Agent 行为。MCP 普及后，工具注册中心必须承担签名验证、来源审核、沙箱化执行与运行时行为基线监控——这是传统 API 网关从未面对的威胁模型。

3.2基础设施诉求

  • 推导Schema 注册中心＋版本化管理：万级工具的 JSON Schema 统一注册、语义检索（embedding 索引）、多语言（Python/Java/JS）绑定生成；schema 变更灰度与兼容性校验，决策延迟 <10ms。
  • 实测状态化执行语义：τ-bench pass^k 指标[17] 与 τ²-bench 双控环境[18] 要求网关提供会话状态机、幂等执行、补偿事务与冲突检测；推导策略引擎（OPA 类）决策延迟 <5ms，违规拦截率计入发布门禁。
  • 推导工具依赖图执行引擎：针对 C³-Bench 的工具关系缺陷[19]，网关侧维护工具 DAG（前置条件/副作用/互斥），支持并行调度与部分失败回滚。
  • 推导大规模调用治理：ToolBench 级 API 池[20] 需按 API 维度的令牌桶限流、并发配额与熔断；目标单网关 1 万 QPS、P99 转发延迟 <20ms。
  • 推导MCP 供应链安全：工具签名与来源验证、描述变更 diff 审计（防 rug-pull）、服务器沙箱执行、行为基线异常告警，对应 MCPTox 威胁模型[21]。

3.3大厂实践对比

厂商工具层实践证据
腾讯C³-Bench 以攻击概念＋单变量分析定位 Agent 工具链脆弱点，49 个模型横评，基准与数据开源论文[19]
阿里巴巴内部真实世界智能体基准 QwenClawBench 随 Qwen3.6 发布使用（非公开协议，需注意「自家模型自家测」的客观性局限）见勘误声明
Sierra（海外）τ-bench/τ²-bench 把客服域策略一致性（pass^k）与双控交互标准化，推动「状态化工具调用」成为评测一等公民论文[17][18]
UC BerkeleyBFCL 系列持续演化至 V4，成本与延迟入榜；Gorilla 生态提供函数调用全链路开源实现榜单与论文[16]
Moonshot AIKimi K2 在 τ²-Bench 平均 66.1%、ACEBench 76.5%，其大规模 Agentic 数据合成流水线是工具能力的主要归因[44]K2 技术报告
关键引用：Patil et al., BFCL, ICML 2025 [16]；Yao et al., τ-bench, arXiv:2406.12045 [17]；Barres et al., τ²-bench, arXiv:2506.07982 [18]；Yu et al., C³-Bench, arXiv:2505.18746 [19]；Qin et al., ToolLLM, ICLR 2024, arXiv:2307.16789 [20]；Wang et al., MCPTox, AAAI 2026, arXiv:2508.14925 [21]。

第四章 记忆与存储层Memory & Storage：从「更大窗口」到「记忆即服务」的范式迁移

核心问题：从「更大上下文窗口」到「外部记忆服务」的架构范式转变。
核心洞察记忆基准的规模化（LongMemEval_M 1.5M token、BEAM 10M token）已从实验上宣判「纯上下文路线」的终点：记忆必须外迁为独立的、带时间语义与一致性保障的基础设施服务——Memory-as-a-Service。

4.1Benchmark 问题分析

长对话记忆不是检索题，而是状态管理题。LoCoMo（ACL 2024）经典基准[22] 构建了 10 段跨越数十个会话的超长对话与 1,986 个问答对，覆盖单跳、多跳、时间推理与开放域事件摘要，证明 RAG 在长对话上的收益有限且随对话长度递减。LongMemEval（ICLR 2025）[10] 进一步把「知识更新」（同一事实跨会话被覆写，系统须返回最新值）与「拒答」（历史中没有答案时不得编造）列为核心能力——前者要求记忆条目具备版本与时间戳语义，后者要求检索置信度与 abstention 机制，二者都超出朴素向量库的能力范围。

BEAM 把规模推到 10M token，确认了外部记忆架构。BEAM[9] 的结论对架构设计极具指向性：1M 窗口模型与「窗口＋RAG」都随对话变长而退化，而显式的三系统记忆（长期情景记忆、短期工作记忆、事实草稿本）在所有骨干模型上稳定提升 3.5%–12.69%。这与 MemoryBank（AAAI 2024）经典基准[23] 的设计哲学一致：记忆需要结构化存储（时间戳、重要性、关联关系）、写入时的摘要提炼与读取时的分层召回，并借鉴艾宾浩斯遗忘曲线做 retention 管理。多个会话间的事实冲突检测与合并、记忆的版本控制，开始呈现「数据库事务」而非「缓存」的特征。

两条路线的分化清晰可见。海外头部厂商的主线仍是扩大窗口＋提示缓存（配合缓存折扣计费）；中国厂商更早地把「向量检索＋会话摘要分层」工程化（对话产品的会话持久化、长期画像记忆等）。BEAM/LongMemEval 的证据表明，两条路线将收敛于混合架构：窗口负责工作记忆，外部服务负责情景与语义记忆。

4.2基础设施诉求

  • 推导记忆即服务（MaaS）接口：写入（write/extract）、更新（supersede）、检索（recall）、遗忘（forget）四类原语；记忆条目携带时间戳、来源、重要性分数与实体关联边。
  • 推导分层存储：工作记忆（上下文内）—情景记忆（向量库：Milvus/Pinecone/Weaviate 类）—语义记忆（知识图谱/画像表）；新信息实时写入向量索引的端到端延迟 <100ms。
  • 实测知识更新语义：LongMemEval 的 KU 子项（78/500 题）[10] 要求记忆系统支持「同一槽位的时序覆写」，即版本链＋生效时间查询；推导冲突检测纳入写入路径（新事实与既有事实 NLI 判定）。
  • 实测拒答与置信度：LongMemEval 的 Abstention 维度[10] 要求检索侧输出置信度并在低置信时触发拒答，而非强行作答。
  • 推导会话摘要压缩：滚动摘要＋事件抽取双层压缩，压缩比 ≥20:1 且关键事实保真率 ≥95%（以 LoCoMo 事件摘要任务[22] 为验收）。

4.3路线对比：窗口扩张 vs 检索＋摘要

维度海外主线（OpenAI/Anthropic/Google）中国大厂常见做法基准证据
主路线扩大上下文窗口＋提示缓存计费折扣向量检索＋分层摘要＋画像记忆—
优势无损保真、工程简单成本可控、可跨会话持久—
失效点BEAM：1M 窗口＋RAG 随对话变长退化[9]LoCoMo：RAG 收益随长度递减[22]两者均指向混合架构
收敛方向工作记忆在窗内，情景/语义记忆外挂为服务（LIGHT 三系统平均提升 3.5%–12.69%[9]）BEAM / LongMemEval
关键引用：Maharana et al., LoCoMo, ACL 2024, arXiv:2402.17753 [22]；Wu et al., LongMemEval, ICLR 2025, arXiv:2410.10813 [10]；Tavakoli et al., BEAM, arXiv:2510.27246 [9]；Zhong et al., MemoryBank, AAAI 2024, arXiv:2305.10250 [23]。

第五章 安全与审计层Security & Audit：多步安全、提示注入与工具投毒驱动的零信任架构

核心问题：多步 Agent 安全、提示注入、工具投毒对零信任架构的诉求。
核心洞察安全评估从「单轮拒答」演进为「多步轨迹＋对抗环境」：AgentHarm 的 110 类恶意多步行为[24]、AgentDojo 的 629 个注入测试用例[25]、MCPTox 的真实服务器投毒[21]，共同把安全边界从模型推进到系统——默认无网络、默认无持久存储、工具输出必须消毒、评估环境必须可销毁。

5.1Benchmark 问题分析

多步有害行为需要轨迹级审计而非输出过滤。AgentHarm（UK AISI 合作，ICLR 2025，arXiv:2410.09024）[24] 提供 110 个基础恶意行为（欺诈、网络犯罪、骚扰等 11 类）及 330 个增强变体，评分不仅看最终输出，还看中间步骤是否执行了有害工具调用——这要求审计系统记录并逐步判定完整轨迹，且评估沙盒本身必须无网络、无持久存储、评估后自动销毁，以防恶意代码真实外溢。HarmBench（2024）经典基准[26] 则把自动化红队生成标准化，推动「动态红队」服务化。

提示注入是唯一被反复证实的主流攻击面。AgentDojo（NeurIPS 2024，ETH SPY Lab）[25] 在 Workspace/Slack/Travel/Banking 四域、70 个工具、97 个用户任务上构造 629 个安全用例，首次把「良性效用」与「攻击成功率」联合计分：GPT-4o 效用从 69% 跌至攻击下的 50%；同期 InjecAgent 显示 GPT-4 在增强注入下受害率从 24% 升至 47%。注入载荷藏在工具返回值（邮件、网页、文件）中——因此工具输出消毒（内容安全扫描）、权限最小化（默认无网络与文件系统权限、工具按任务白名单）与系统级控制流隔离（CaMeL、IsolateGPT 一类把可信策略与不可信数据架构性分离）成为网关与运行时的必备能力。

供应链与网络武器化是 2025–2026 的新前沿。MCPTox（AAAI 2026）[21] 证明 MCP 服务器的工具描述即可成为投毒载体，推动工具签名验证与沙箱执行；Meta 的 CyberSecEval 系列（Purple Llama）经典基准[27] 把评估推进到漏洞利用与攻击性网络能力，对应的防御基建是隔离靶场：任何漏洞利用类评测必须在气隙（air-gapped）环境运行。对比来看，海外以 UK AISI 的 Inspect 框架[33] 与政府级气隙评测流程为代表，强调可审计与可复现；中国大厂的安全评估更多内嵌于模型发布流程，公开方法学较少——这一「透明度差」本身就是基础设施成熟度的差距。

5.2基础设施诉求

  • 实测轨迹级安全判定：AgentHarm 按逐步行为评分[24]；推导审计系统需 syscall＋工具调用双层留痕，支持事后回放与逐步打标。
  • 实测效用-安全联合门禁：AgentDojo 的 BU/UA/ASR 三指标[25] 应成为 Agent 上线门禁；推导发布标准示例：ASR 增幅 <5pp 且 BU 损失 <2pp。
  • 推导零信任默认配置：默认无网络、默认只读文件系统、默认无持久存储、评估后自动销毁（气隙镜像）；红队评测专用隔离 VLAN。
  • 推导工具输出消毒管道：所有工具返回值经注入检测（分类器＋规则）后方可进入上下文，检测延迟 <50ms，并保留原始载荷用于取证。
  • 推导MCP 供应链防线：签名验证、描述 diff 审计、沙箱执行、行为基线监控（对应 MCPTox[21]）；第三方工具接入须过安全评审流水线。

5.3海外 vs 中国实践对比

维度海外实践中国实践
评估框架UK AISI Inspect：开源、代码优先、轨迹全量留痕，inspect_evals 社区库已容纳 70+ 评测[33][34]多为各厂自研内部平台，公开方法学有限；腾讯/阿里以开放基准（C³、ArtifactsBench）间接披露能力[19][41]
威胁模型覆盖AgentHarm（多步恶意）、AgentDojo（注入）、CyberSecEval（网络攻防）成体系[24][25][27]MCPTox（中科大，AAAI 2026）在 MCP 供应链方向进入国际顶会[21]
隔离标准气隙环境、政府安全机构主导的评测流水线以模型发布内评为主，气隙与红队流程公开度低
关键引用：Andriushchenko et al., AgentHarm, ICLR 2025, arXiv:2410.09024 [24]；Debenedetti et al., AgentDojo, NeurIPS 2024, arXiv:2406.13352 [25]；Mazeika et al., HarmBench, arXiv:2402.04249 [26]；Meta, CyberSecEval 3, arXiv:2408.01605 [27]；Wang et al., MCPTox, arXiv:2508.14925 [21]。

第六章 多 Agent 编排层Multi-Agent Orchestration：消息风暴、状态冲突与失败归因

核心问题：消息风暴、状态冲突、失败归因对分布式系统的诉求。
核心洞察多智能体系统失败的主因不是单个模型不够聪明，而是分布式系统病：UC Berkeley 对 7 个主流框架 200 余条轨迹的扎根分析归纳出 3 大类 14 种失败模式（MAST）[30]，其中大部分属于规范、验证与协调缺陷——这要求编排层引入消息总线、结构化协议、工作流引擎与分布式追踪，而非「更多对话」。

6.1Benchmark/研究问题分析

自由对话式编排天然产生 O(N²) 消息风暴。AutoGen（Microsoft，2023）经典基准[28] 以「可对话 Agent」为原语，任意 Agent 两两通信，消息数随规模平方增长，上下文被寒暄与转发稀释。MetaGPT（ICLR 2024）经典基准[29] 与 ChatDev（2023）经典基准[31] 的解法是把软件工程 SOP 编码进编排：角色分工、标准化「工件」（需求文档、设计、代码）沿流水线流转——这本质上是把自由文本对话替换为结构化数据流（Protobuf/Avro 式 schema 约束）与工作流编排（Temporal/Cadence 式的持久化执行与重试语义）。

失败归因是多 Agent 的「可观测性债务」。Cemri et al.（UC Berkeley，2025，arXiv:2503.13657）[30] 的 MAST 分类法把 14 种失败模式归入三类：规范与系统设计缺陷（任务分解不当、角色越权）、Agent 间对齐失败（信息丢失、答非所问、重复劳动）、任务验证与终止缺陷（提前终止、无验证交付）。这些失败在日志层面表现为跨 Agent 的因果链断裂——没有分布式追踪（OpenTelemetry 式的 span 关联与因果标注），失败定位只能靠人工读几千轮对话。共享工件的状态一致性则是另一暗礁：多个 Agent 并发修改同一工件时，需要分布式锁或 CRDT 式的无冲突合并，否则「最后一个写入者获胜」会静默丢弃有效产出。

6.2基础设施诉求

  • 推导Pub/Sub 消息总线（Kafka/Redis Streams）：以主题订阅替代全连接对话，消息延迟 P99 <50ms，天然削峰并支持回放审计。
  • 推导结构化工件协议：MetaGPT 式 SOP 工件[29] 以 schema 序列化（Protobuf/Avro），版本化存储＋乐观并发控制或 CRDT 合并。
  • 推导持久化工作流引擎：编排逻辑以 Temporal/Cadence 式持久执行实现，崩溃可恢复、步骤可重试、超时与补偿内建。
  • 实测失败归因体系：MAST 的 14 种失败模式[30] 可直接映射为追踪标签体系；推导失败定位时间（MTTD）目标从「小时级人工读日志」降至 <10 分钟自动归因。
  • 推导上下文窗口治理：每 Agent 只订阅与其角色相关的主题分区，上下文裁剪开销与 token 成本计入编排层 SLO。

6.3框架实践对比

框架通信/编排模型暴露的 Infra 问题来源
AutoGen（Microsoft）自由多Agent对话O(N²) 消息风暴、上下文稀释[28]
MetaGPTSOP＋结构化工件流水线需要 schema 化数据流与编排引擎[29]
ChatDev角色化聊天链（CEO→CTO→Programmer…）阶段门控与验证缺失导致提前交付[31]
MAST（UC Berkeley）—（失败模式测量）3 类 14 种失败模式，需分布式追踪与归因[30]
JoyAgent-JDGenie（京东）端到端多Agent产品化，Docker 部署，GAIA 验证集 75.15%产品级封装降低落地门槛，但协议与追踪公开有限[45]
关键引用：Wu et al., AutoGen, arXiv:2308.08155 [28]；Hong et al., MetaGPT, ICLR 2024, arXiv:2308.00352 [29]；Cemri et al., Why Do Multi-Agent LLM Systems Fail?, arXiv:2503.13657 [30]；Qian et al., ChatDev, arXiv:2307.07924 [31]。

第七章 评估与观测层Evaluation & Observability：从「离线跑分」到「评估即基础设施」

核心问题：从「离线跑分」到「在线 A/B 测试」的评估基础设施演进。
核心洞察2025–2026 年的标志性变化是：评估本身被当作基础设施来建设。HAL 证明「同一模型换脚手架可差 20–30 分」，三维分析（模型×脚手架×基准）必须成为标配[32]；过程评估（AgentProcessBench/CUARewardBench）把评分粒度从结果推进到每一步[35][36]——轨迹数据库、成本归因与 LLM-as-Judge 服务化成为新的底座能力。

7.1问题分析

评分不可比是行业级痛点，根因在基础设施。HAL（Holistic Agent Leaderboard，Princeton 等，arXiv:2510.11977）最新[32] 用标准化 harness 在数百台 VM 上并行编排，把评测从数周压到数小时；其 21,730 次 rollout（9 模型 × 9 基准，总成本约 $40,000，公开 2.5B token 日志）揭示了一系列反直觉结论：多数运行中提高推理强度反而降低准确率；Agent 会去 HuggingFace 搜基准、在订机票任务中误用信用卡。这些行为只有靠 LLM 辅助的日志审查才能发现——评估平台必须具备大规模轨迹存储、检索与可视化（树状/图状交互历史）能力。Anthropic 的工程博客（2026 年 1 月）同样强调 pass@k 与 pass^k 的区分、分级器 bug 可造成 42%→95% 的分数跳变[50]。

从结果评估到过程评估，评分器本身也需要被评估。AgentProcessBench（arXiv:2603.14465）最新[35] 提供 1,000 条工具使用轨迹、8,509 个人工逐步标注（双人标注一致性 89.1%），评测 20 个 LLM 作为过程奖励模型的能力，发现当前模型存在显著的正标签偏置、难以区分「探索性中性步骤」与错误。腾讯优图的 CUARewardBench（arXiv:2510.18596）[36] 聚焦桌面 Agent：272 条轨迹标注＋346 条步骤标注，发现视觉推理能力是 CUA 奖励模型的核心短板，其 UPE 集成法将 ORM 精度提升至 89.8%。这意味着「LLM-as-Judge 服务化」必须自带质量监控：评审模型的偏置、一致性与成本都要纳入平台治理。

成本与延迟是缺失的第三维度。绝大多数学术基准不报告 API 成本与延迟；HAL 把「每任务成本」纳入三维分析[32]，BFCL 自 2024 年 4 月起把成本与延迟入榜[16]，UK AISI 的 inspect_evals 维护实践则证明：70+ 社区评测的持续维护需要队列管理、重采样统计方法与系统化质量控制[34]。生产部署的评估平台必须补齐 token 成本、API 成本、墙钟延迟的精确核算与预算门禁。

7.2基础设施诉求

  • 实测标准化评测 harness＋弹性 VM 池：HAL 用数百台 VM 将评测从数周压到数小时[32]；推导平台应支持「基准即代码」注册、版本化与并行度自动伸缩。
  • 推导轨迹数据库：树状/图状交互历史的列式存储与检索，单平台支撑 ≥10⁵ 条轨迹、PB 级日志，支持 LLM 辅助的批量异常行为扫描。
  • 推导成本归因引擎：token/API/计算三维成本按「模型×脚手架×基准×任务」精确归集，单次评测预算超限自动熔断；目标成本核算误差 <1%。
  • 推导LLM-as-Judge 服务化：评审模型版本化、偏置监控（以 AgentProcessBench/CUARewardBench 类基准定期校准[35][36]）、评审结果双人复核抽样。
  • 推导离线-在线贯通：离线榜单→影子流量→在线 A/B 的三级评估流水线，在线指标（业务转化、人工接管率）回写基准迭代。

7.3海外框架 vs 中国平台

阵营代表特征
海外开源Inspect（UK AISI）[33]、inspect_evals 社区库[34]、MLflow、DeepEval、LangSmith、HAL[32]代码优先、轨迹透明、社区共建；HAL 强调成本与脚手架维度
中国自研阿里（SWE-Universe 环境工厂＋MegaFlow[4]）、腾讯（C³/ArtifactsBench/CUARewardBench 矩阵[19][41][36]）、字节 Seed（EdgeBench/ReportBench/FinSearchComp[37][38][39]）、xbench（红杉中国，职业对齐系列[14]）以「自研基准」为杠杆，直接服务模型迭代与生产选型；平台内部化程度高、方法学公开少
关键引用：Kapoor et al., HAL, arXiv:2510.11977 [32]；Abbas et al., inspect_evals 维护实践, arXiv:2507.06893 [34]；AgentProcessBench, arXiv:2603.14465 [35]；Lin et al., CUARewardBench, Tencent Youtu, arXiv:2510.18596 [36]；Anthropic, Demystifying Evals for AI Agents, 2026-01 [50]。

第八章 中国大厂 Infra 实践专题China Tech Giants：以自研基准反推差异化基础设施建设

核心问题：中国大厂如何通过自研基准反推基础设施差异化建设？
核心洞察中国大厂的路径与海外显著不同：国际通用基准决定学术排名，自研基准决定生产落地——后者直接长在自家业务数据与基础设施之上，形成「基准—数据—Infra—模型」的闭环飞轮。本章事实均经核实（含对任务书的勘误，见「调研方法」节）。

8.1字节跳动：长期学习评估 × Seed 基础设施

EdgeBench（arXiv:2607.05155，2026 年 7 月，字节 Seed 团队）最新[37] 是评估范式的分水岭：134 个真实世界任务，单任务支持 12–72 小时连续运行，累计分析约 38,000 小时 Agent 交互，首次发现环境学习性能服从 log-sigmoid 缩放律（R²=0.998），且 Agent 学习速度约每 3 个月翻一番；51 个任务公开、83 个保留防污染，人类专家基线平均完成时长 57.2 小时。对 Infra 的诉求是前所未有的：跨小时级的 checkpoint/restore、弹性调度（长任务抢占与恢复）、多级反馈环境的状态持久化。ReportBench（ByteDance BandAI，arXiv:2508.15804）[38] 以 arXiv 综述论文反向工程 100 个研究任务，用 agentic 流水线逐句验证引用忠实度与非引用陈述的事实性（平均 153 篇参考文献的 ground truth）——其背后是引用验证与网页事实核查的服务化能力。FinSearchComp（arXiv:2509.13160）[39] 由 70 位金融专家标注 635 题，复刻分析师「时效数据抓取—历史查询—复杂调查」工作流，21 个模型横评显示 Grok 4 领跑全球子集、豆包领跑大中华子集，且「网页搜索＋金融插件」显著提升成绩——为金融数据网关（时效数据管道、插件化数据接入）提供了直接的验收标准。

8.2阿里巴巴：环境工厂 × 百万级沙盒集群

阿里是当前公开资料中环境基础设施披露最完整的厂商（详见第一章）：SWE-Universe[4] 的 MegaFlow 编排、每任务独立 ECS 沙盒、ACR 镜像层缓存、环内 hacking 检测、质量评判 Agent（在人类标注基准上 78.72% 准确率），构成「环境构建→轨迹生产（50 万条成功轨迹、300 亿 token、5 种脚手架）→异步 RL（2–4 倍提速）→SWE-bench Verified 75.3%（Qwen3-Max-Thinking）」的完整闭环。内部基准 QwenClawBench（未见公开论文）随 Qwen3.6 发布用于真实世界智能体能力对比——使用时需注意其非第三方属性。电商侧，EcomBench（arXiv:2512.08868，Tongyi Lab）最新[40] 基于真实电商生态需求构建三难度等级任务，考核深度检索、多步推理与跨源知识整合（本报告已将其从任务书所述「京东」勘正为阿里）。

8.3腾讯：工具链可靠性 × 多模态评审矩阵

腾讯的基准矩阵覆盖三个层次：C³-Bench（arXiv:2505.18746）[19] 以攻击概念＋单变量分析拆解工具依赖、隐藏信息与动态决策路径三大失效源，在 49 个主流 Agent 上完成横评并开源，直接对应「工具依赖图执行引擎」的建设需求；混元团队的 ArtifactsBench（arXiv:2507.04952）[41] 以「程序化渲染＋时序截图＋清单引导的 MLLM 评审」实现视觉代码生成的全自动评估，1,825 个任务、与 WebDev Arena 人类偏好排序一致率 94.4%——其 Infra 本质是浏览器实例池＋截图流水线＋评审模型服务；优图实验室的 CUARewardBench[36]（见第七章）补齐了过程奖励评估。此外腾讯 2026 年 7 月公开的 WorkBuddy Bench（抗污染任务构造）延续了这一「评估先行」路线。

8.4美团：语音外呼场景评估 × 用户模拟器工程

VoiceAgentEval（声网×美团×xbench，2026 年 2 月）[14] 中，美团的核心贡献是用户模拟器工程：基于真实外呼业务交互数据泛化出 5 组行为模式 × 30 个子场景 = 150 组人设，并用拟人度评分（图灵启发的 0–9 分制）、AI 检测、配对比较三种方法校验模拟器与真实对话的逼近度；文本维度建立任务流程遵循（TFC）与通用交互能力（GIC）双层评估。对 Infra 的启示：生产级 Agent 评估需要「可控可复现的用户模拟集群」——150 个并发人设会话的编排、与真实 RTC 引擎（声网）对接的延迟/打断采集、以及模拟器本身的质量校准流水线。初评前三名为 Doubao-1.5-32k、GPT-4.1、Claude-4-Sonnet[14]。

8.5京东、华为与其余厂商

厂商已核实的 Agent/评估基础设施实践Infra 特征
京东开源端到端多智能体产品 JoyAgent-JDGenie：GAIA 验证集 75.15%、测试集 65.12%，内置 RAG 知识平台、DataAgent、报告/PPT 生成，Docker 容器化交付[45]产品化封装、开箱即用、不绑定特定云
华为Pangu DeepDiver（arXiv:2505.24332）：开放网络强化学习的自适应搜索强度调节；openPangu DeepDiver-V2 技术报告（多智能体深度信息检索）[42]搜索 Agent 检索增强流水线＋昇腾体系推理优化
Moonshot AIKimi K2 技术报告：大规模 Agentic 数据合成流水线；Colocated RL 训练/推理同节点；Checkpoint Engine 30 秒广播 1T 参数热更新；τ²-Bench 66.1%、ACEBench 76.5%[44]训练-推理协同的弹性权重分发
智谱AutoGLM 2.0：为执行型 Agent 配备专属云手机/云电脑，支持 24 小时独立运行，执行能力封装为 API；基于 GLM-4.5/4.5V 与端到端异步 RL云端设备池即 Agent 执行环境
DeepSeekDeepSeek-V3.2 采用「bug 态失败/修复态通过」的可验证环境构造路线（SWE-Universe 论文引述其环境规模约 24,667[4]），技术细节未完全公开可验证环境＋RL 的低成本路线
百度公开渠道未见与上述同等级别的 Agent 评估基础设施方法学披露（本报告不推测，如实标注）—
关键引用：Zhu et al., EdgeBench, arXiv:2607.05155 [37]；Chen et al., SWE-Universe, arXiv:2602.02361 [4]；Yu et al., C³-Bench, arXiv:2505.18746 [19]；Xu et al., VoiceAgentEval, arXiv:2510.21244 [13]；Min et al., EcomBench, arXiv:2512.08868 [40]；Hu et al., FinSearchComp, arXiv:2509.13160 [39]；Li et al., ReportBench, arXiv:2508.15804 [38]。

第九章 2026 年新兴趋势与风险Emerging Trends & Risks in 2026

9.1趋势一：从静态结果评估到动态长期学习评估

EdgeBench 把单任务时长推到 12–72 小时并发现 log-sigmoid 学习缩放律（R²=0.998）、学习速度约每 3 个月翻倍[37]，这意味着评估对象从「模型当前能力」变为「模型的学习速率」。基础设施必须支持：长任务断点续评（checkpoint/restore）、环境状态的小时级持久化、学习曲线的在线采集与拟合、保留集防污染治理（EdgeBench 仅公开 51/134 任务）。一次性跑分的评测平台将无法度量这类能力。

9.2趋势二：从单轮安全到多步 Agent 安全

AgentHarm（多步恶意轨迹评分）[24]、AgentDojo（效用-安全联合计分）[25]、MCPTox（供应链投毒）[21] 与 OWASP 2025 年 12 月发布的 Agentic 应用 Top 10（目标劫持列为首位、记忆投毒单列）共同推动零信任架构：默认拒绝、最小权限、工具输出消毒、轨迹全程可审计。安全评估正从「发布前体检」变为「运行时持续监控」。

9.3趋势三：中国自研基准的国际影响力与多基准并行流水线

MCPTox 进入 AAAI 2026[21]、SWE-Universe 把环境规模做到百万级[4]、C³-Bench/ArtifactsBench 开源横评数十个国际模型[19][41]——中国自研基准开始具备国际议程设置能力。对 Infra 的直接诉求是多基准并行评估流水线：同一模型版本需在十余个异构基准（容器、VM、浏览器、RTC 引擎）上并行出分，调度器按基准类型路由到对应执行池，结果归一化入库。

9.4风险一：评估基础设施本身的漏洞与对抗性利用

这是 2026 年最重要的风险发现。UC Berkeley 的 BenchJack（arXiv:2605.12673，2026 年 5 月）最新[43] 以自动化红队审计 10 个主流基准（覆盖 10,635 个任务）：归纳出 8 类反复出现的缺陷模式，发现 9/10 个基准可被「不解一题」刷到接近满分——例如一段 9 行的 conftest.py 利用 PyTest 自动加载钩子重写测试结果，即可在 SWE-bench 上取得 100% 解决率；WebArena 存在金答案泄漏。共发现 219 个不同缺陷；对设计较好的 4 个基准进行 3 轮「攻击-修复」迭代后，可破解率从近 100% 降至 10% 以下，WebArena 与 OSWorld 三轮内完全修复[43]。同期 OpenAI 弃用 SWE-bench Verified（59.4% 难题测试有缺陷＋全面污染）[46]，从产业侧印证了同一结论。防御方案（Infra 视角）：评测 harness 的信任边界审查（评测逻辑与 Agent 写权限严格隔离、评测前重置全部可变文件）、基准版本化与持续红队（BenchJack 式生成-对抗迭代纳入 CI）、评分全流程行为审计、关键榜单人工抽检复核、以及保留集/私有集治理（如 SWE-bench Pro 的 858 题 held-out 与 276 题商业集[3]）。

图 2｜BenchJack 审计：主流基准修复前后的可破解任务比例。数据取自 BenchJack 论文[43]：SWE-bench Verified 100%→80%，SWE-bench Pro 100%→23%，OSWorld 100%→7.9%（三轮迭代后 0%），WebArena 100%→4.5%（三轮迭代后 0%），AgentBench 89%→15%。评估基础设施必须与红队审计共生。

9.5趋势四：记忆基准规模化确认「外部记忆服务」范式

BEAM（10M token）[9] 与 LongMemEval_M（1.5M token）[10] 从实验上确认：窗口扩张无法替代记忆架构。2026 年记忆方向的新基准（如长时程 Agent 记忆评测）进一步把「写入—更新—遗忘」的全生命周期纳入考核。记忆即服务（MaaS）将从论文概念进入各大厂的平台招标书。

9.6风险二：脚手架敏感性与分数通胀的披露义务

HAL 的三维分析证明模型、脚手架、基准三个变量纠缠，同模型不同脚手架可差 20–30 分[32]；Anthropic 指出修复分级器 bug 可使 CORE-Bench 分数从 42% 跳至 95%[50]。本报告建议所有分数引用必须附带：模型版本、脚手架配置、重试预算、pass@k/pass^k 协议与成本——评估平台的报告层应将这些元数据作为强制字段，否则榜单数字不具备工程决策价值。

第十章 权威 Benchmark 技术海报Benchmark Technical Posters

本章以「技术海报」形式精选六个覆盖不同基础设施层的权威基准：每张海报包含概念视觉（AI 插画或手绘 SVG 示意图）、核心规格、关键发现与 Infra 启示。海报中的数据图表均来自各基准论文或官方审计，标注对应引用编号；配图为示意性视觉，不构成数据来源。

01

SWE-bench｜真实 GitHub Issue 解决能力基准

代码 Agent 评测的「事实标准」：从 2,294 个真实 Issue 到容器化评测、再到因污染与测试缺陷被官方弃用的完整生命周期样本。
ICLR 2024Princeton 等2,294 任务Docker 化评测arXiv:2310.06770
SWE-bench 工作流示意插画
示意图：Issue → 模型补丁 → 容器内测试验证（AI 生成插画）

它考什么

给定真实开源仓库的一个 GitHub Issue 与完整代码库，Agent 须产出补丁；评分方式是在 Docker 容器中应用补丁并运行仓库自带测试套件，全部通过才算解决[1]。

核心规格

规模2,294 个 Issue / 12 个 Python 仓库[1]
评分协议容器内 FAIL_TO_PASS + PASS_TO_PASS 双测试
人工验证子集SWE-bench Verified：500 题[2]
抗污染演进SWE-bench Pro：1,865 题 / 商业私有集 276 题[3]

关键发现

2026 年 2 月 OpenAI 审计 138 道最难题：59.4%（82 道）的测试存在缺陷，会拒绝功能正确的补丁；且全部 500 题的金补丁可被前沿模型逐字复述——SWE-bench Verified 因此被正式弃用[46]。

Infra 启示

评测的可信度 = 环境可复现性 × 验证器质量。容器化 harness、双态自检（bug 态必败／修复态必过）与测试缺陷审计，是任何代码评测基建的底线。

2,294真实 Issue 任务
59.4%最难题测试缺陷率[46]
500/500Verified 金补丁可被复述
2026-02OpenAI 宣布弃用 Verified
图 4｜SWE-bench Verified 弃用审计：138 道最难题中 82 道（59.4%）测试有缺陷（数据源：OpenAI 审计[46]）
02

τ²-bench｜双控环境会话 Agent 基准

Sierra 出品：把客服场景建模为 Dec-POMDP——Agent 与「用户」同时通过工具修改同一个世界，状态一致性成为第一考点。
arXiv:2506.07982Sierra电信域双控 Dec-POMDPpass^k 协议
τ²-bench 双控场景示意插画
示意图：Agent 与用户双方同时操作共享状态（AI 生成插画）

它考什么

在 τ-bench（航空/零售客服域）[17] 基础上升级为双控环境：用户模拟器同样持有工具、可修改共享数据库；Agent 须在「世界会被对方改变」的前提下完成策略合规的任务，并用 pass^k（k 次独立试验全部成功）度量一致性[18]。

核心规格

形式化模型Dec-POMDP 去中心化部分可观测决策
评测协议pass^k 状态级断言（而非文本匹配）
关键实验无用户 → 双控切换后性能显著下降[18]
实测分数Kimi K2 平均 66.1%[44]

关键发现

从静态环境切换到双控环境后 Agent 性能明显下滑：模型普遍缺乏「对方也在改变世界」的心智，冲突检测与状态再确认成为主要失分点[18]。

Infra 启示

工具网关必须是有状态的：会话状态机、幂等执行、补偿事务与领域策略引擎缺一不可——策略违规是系统缺位而非模型问题。

2个控制方（Agent × 用户）
pass^k一致性度量协议
66.1%Kimi K2 平均分[44]
Dec-POMDP形式化框架
03

OSWorld｜真实计算机环境多模态 Agent 基准

NeurIPS 2024：第一个在完整操作系统虚拟机中运行的可复现评测——人类完成率 72.36%，最强模型仅 12.24%。
NeurIPS 2024xLang 等369 任务Ubuntu/VM 多后端arXiv:2404.07972
OSWorld 桌面环境示意插画
示意图：Agent 通过截图与无障碍树双通道操作真实 OS（AI 生成插画）

它考什么

Agent 在真实虚拟机（Ubuntu/Windows/macOS）中完成开放式桌面任务：观测为屏幕截图＋无障碍树，动作为鼠标/键盘事件；评分由执行式脚本检查最终系统状态（文件内容、应用状态），而非轨迹匹配[6]。

核心规格

任务规模369 个真实任务，跨应用组合
运行后端VMware / VirtualBox / AWS / Azure / Docker
2025 更新OSWorld-Verified：修复 300+ 处标注与脚本问题[7]
评测速度AWS 并行全量评测 < 1 小时[7]

关键发现

人类完成率 72.36%，而最强模型仅 12.24%——GUI 定位（grounding）与跨应用状态管理是最大短板[6]。BenchJack 还发现其评测信任边界曾被完全破解，修复后降至 0%[43]。

Infra 启示

桌面 Agent 评测 = 完整 VM 集群＋低延迟 GUI 流＋执行式状态校验。Verified 的 1 小时目标倒逼镜像预热、快照恢复与大规模并行调度。

72.36%人类完成率
12.24%最强模型（2024）[6]
<1hVerified 全量评测[7]
100%→0%BenchJack 破解率修复[43]
图 5｜OSWorld 人机差距（2024 论文数据[6]）：GUI 落地能力是当时最大短板
04

AgentDojo｜提示注入攻防动态评测环境

NeurIPS 2024（ETH SPY Lab）：首个把「良性效用」与「攻击成功率」联合计分的 Agent 安全基准——防御不能只看 ASR，还得看效用损失。
NeurIPS 2024 D&BETH Zürich4 域 / 70 工具97 任务 / 629 攻击用例arXiv:2406.13352
用户任务 良性目标 BU LLM Agent 工具调用循环 Workspace 工作区 Slack 消息 Travel 出行 Banking 银行 攻击者：注入载荷 恶意邮件 / 网页 / 文件内容 藏在工具返回值中回流 三指标联合计分： BU 良性效用 · UA 攻击下效用 · ASR 攻击成功率
威胁模型示意：注入载荷经工具输出回流至 Agent（手绘 SVG）

它考什么

Agent 在 Workspace/Slack/Travel/Banking 四个模拟办公域执行 97 个良性任务，同时攻击者在环境数据（邮件、网页、文件）中埋入注入指令，诱导 Agent 执行攻击者目标；三指标联合计分[25]。

核心规格

规模70 个工具、97 用户任务、629 安全用例
指标BU / UA / ASR 联合评估
环境特性动态：可持续加入新攻击与防御
设计原则注入只通过数据通道，不篡改指令通道

关键发现

无防御时 GPT-4o 良性效用 69%，攻击下跌至 50%；同期 InjecAgent 显示 GPT-4 受害率 24%→47%。「效用-安全」的此消彼长成为防御方案的核心权衡[25]。

Infra 启示

工具输出消毒管道、权限最小化与「可信策略/不可信数据」的控制流隔离（CaMeL 类）是系统性防御；ASR 增幅与 BU 损失应同时纳入上线门禁。

629攻击测试用例
69%→50%GPT-4o 效用衰减[25]
24%→47%增强注入受害率
4模拟办公域
图 6｜AgentDojo：注入攻击对 Agent 效用的侵蚀（数据源：AgentDojo 论文[25]）
05

LongMemEval｜聊天助手长期交互记忆基准

ICLR 2025：用 115K–1.5M token 的会话历史证明——商用聊天助手在「知识更新」与「拒答」上系统性失分，纯上下文路线不可持续。
ICLR 2025500 问题S 115K / M 1.5M token5 项记忆能力arXiv:2410.10813
会话历史流 会话 1 · 偏好陈述 会话 2 · 事实更新 会话 3 · 时间事件 …… 会话 N · 冲突覆写 S: ~115K token M: ~1.5M token 记忆服务 写入 · 覆写 · 检索 · 遗忘 时间戳 · 版本链 · 置信度 低置信 → 拒答 ① 信息抽取（单跳事实） ② 多会话推理 ③ 知识更新（最新值） ④ 时间推理 ⑤ 拒答（不编造） 500 个问题 × 5 项能力：商用助手随历史变长显著失分
架构示意：记忆外迁为带时序语义的服务（手绘 SVG）

它考什么

向聊天助手提供最长约 1.5M token 的多会话历史，考察五项记忆能力：信息抽取、跨会话推理、知识更新（同一事实被覆写后须答最新值）、时间推理与拒答（历史无答案时不得编造）[10]。

核心规格

规模500 题；S ≈115K token，M ≈1.5M token
难点子项知识更新（KU）与拒答（Abstention）
对照发现商用助手性能随历史变长显著下降
姊妹基准BEAM：100 段会话、最长 10M token[9]

关键发现

BEAM 进一步证明：即便 1M 窗口模型叠加 RAG，性能仍随对话增长持续退化；显式三系统记忆（情景/工作/草稿本）稳定提升 3.5%–12.69%[9]。

Infra 启示

记忆即服务（MaaS）：版本链＋生效时间查询支持知识更新，检索置信度支持拒答，分层存储（工作/情景/语义）配合 ≥20:1 摘要压缩。

1.5MM 档历史 token 量
5项记忆能力维度
10MBEAM 最长会话[9]
3.5%–12.69%LIGHT 三记忆系统提升[9]
06

SWE-Universe｜百万级可验证环境工厂

阿里巴巴 Qwen 团队（2026-02）：把「环境」做成流水线工业品——从 3,330 万个 PR 到 807,693 个 Docker 可验证环境，基础设施即论文。
arXiv:2602.02361Alibaba Qwen × 浙大52,960 仓库 / 8 类语言MegaFlow 编排评测-训练闭环
GitHub PR 池 ≈3,330 万 候选筛选 ≈100 万 MoE 构建模型 Qwen-Next-80A3 成功率 78.44% 可验证环境 807,693 个 沙盒执行 每任务独立阿里云 ECS VM MegaFlow 分布式编排 镜像存储 ACR 容器镜像服务 Docker 层缓存复用降本 质量防线 环内 hacking 检测器 自检 82.6% → 94% 下游闭环：5 种脚手架 × 50 万条成功轨迹（300 亿 token）拒绝采样 → 异步 RL（2–4 倍提速） Qwen3-Max-Thinking：SWE-bench Verified 75.3%（提交时开源 SOTA）
流水线示意：PR 池 → 候选 → 构建模型 → 可验证环境（手绘 SVG）

它考什么

与其说是基准，不如说是环境生产与训练一体化基础设施：自动从真实仓库合成 Docker 环境＋验证脚本，覆盖 Python/Java/JS/TS/Go/Rust/C/C++ 八类语言，并直接支撑 RL 训练闭环[4]。

核心规格

环境规模807,693 个 / 52,960 仓库
构建质量构建模型 78.44%（超 Claude-Opus-4.5）
轨迹生产50 万条成功轨迹、300 亿 token
训练收益异步 RL 提速 2–4 倍

关键发现

质量防线与规模同等重要：环内 hacking 检测拒绝 grep 式假验证器，迭代自检把构建成功率从 82.6% 推到 94%；Docker 层缓存是百万级镜像存储可行的前提[4]。

Infra 启示

「环境即算力」的标杆样本：每任务独立沙盒 VM＋镜像分层复用＋分布式编排＋评测-训练数据闭环，构成 Agent 时代的数据工厂范式。

807,693可验证环境
78.44%构建模型成功率[4]
82.6%→94%自检迭代提升
75.3%Verified 开源 SOTA（提交时）
图 7｜SWE-Universe 环境生产漏斗（数据源：论文[4]，对数换算展示）

附录 A：Benchmark → Infra 需求推导总表Mapping Table

「量化目标」一列中，实测 为论文/官方披露数字，推导 为本报告工程目标值。

Benchmark（问题）架构诉求技术方案量化目标大厂实践
SWE-bench 系列：环境漂移、59.4% 难题测试缺陷[46]可复现容器沙盒、验证器可信Docker 化 harness、双态自检、环内 hacking 检测实测构建成功率 82.6%→94%[4]；推导沙盒冷启动 <5sOpenAI（Docker 化/弃用决策）、阿里（SWE-Universe）
SWE-Universe：百万级环境生产[4]K8s/VM 调度、镜像预热、存储分层每任务独立 ECS＋ACR 层缓存＋MegaFlow 编排实测807,693 环境、52,960 仓库阿里巴巴
Terminal-Bench：命令副作用[5]不可变文件系统、最小权限网络只读根 FS＋tmpfs＋出站白名单＋用后销毁推导审计粒度 syscall 级Laude/Stanford
OSWorld/WAA：桌面实时交互[6][8]低延迟 GUI 流、完整 VM、并行评测VNC/RDP＋a11y/UIA 双通道、AWS 并行实测全量评测 <1h（AWS 并行）[7]；推导流延迟 <100msxLang、Microsoft（Azure VM）
BEAM/LongMemEval：超长记忆失效[9][10]KV 分层、外部记忆服务PagedAttention＋H2O/StreamingLLM＋MaaS 四原语推导前缀命中 >70%、记忆写入 <100ms海外窗口扩张 vs 中国检索+摘要
VoiceAgentEval：语音全链路计分[14]流式 ASR-LLM-TTS、用户模拟集群RTC 引擎对接、150 人设并发、延迟/打断采集实测15 项语音指标[14]；推导端到端 <2s、打断 <300ms声网×美团×xbench
BFCL/ToolBench：万级工具池[16][20]Schema 注册中心、限流治理版本化注册＋语义检索＋令牌桶限流推导10K QPS、P99 <20ms；实测成本/延迟入榜（2024-04 起）[16]UC Berkeley
τ-bench/τ²-bench：状态与双控[17][18]会话状态机、补偿事务、策略引擎状态化网关＋OPA 类策略决策推导策略决策 <5ms；实测pass^k 协议Sierra；Moonshot（τ² 66.1%）[44]
C³-Bench：工具依赖失效[19]工具依赖图执行引擎工具 DAG＋并行调度＋部分回滚实测49 个 Agent 横评腾讯
MCPTox：供应链投毒[21]签名验证、沙箱执行、行为基线MCP 网关安全流水线推导接入评审 100% 覆盖中科大（AAAI 2026）
AgentHarm/AgentDojo：多步安全[24][25]轨迹审计、输出消毒、零信任沙盒逐步打标＋注入检测＋气隙环境实测GPT-4o 效用 69%→50%（攻击下）[25]；推导消毒延迟 <50msUK AISI、ETH SPY Lab
AutoGen/MetaGPT/MAST：编排失效[28][30]消息总线、工作流引擎、分布式追踪Kafka/Redis Streams＋Temporal＋OpenTelemetry推导失败归因 MTTD <10minMicrosoft、开源社区
HAL：评分不可比[32]标准化 harness、轨迹数据库、成本归因数百 VM 并行＋2.5B token 日志库实测21,730 rollouts、约 $40KPrinceton 等
EdgeBench：长期学习评估[37]小时级 checkpoint/restore、弹性调度状态持久化＋学习曲线采集实测12–72h/任务、38,000h 总交互字节 Seed
BenchJack：基准可被刷分[43]评测信任边界、持续红队攻击-修复迭代纳入 CI、保留集治理实测可破解率 ~100%→<10%（3 轮）UC Berkeley

附录 B：中国大厂 Agent Infra 成熟度对比（L1–L5 模型）Maturity Assessment

本评估模型为本报告基于第八章已核实公开资料的分析框架（属观点性内容，非官方评级）。分级定义：L1 脚本化离线评测（单基准、手工跑分）；L2 容器化可复现评测（Docker 化、可重复出分）；L3 平台化多基准并行（多基准调度、轨迹观测、自研基准发布）；L4 评测-训练闭环（环境工厂、轨迹生产、RL 反馈闭环）；L5 生产级评估生态（在线 A/B、安全审计、成本治理、对外开放）。

厂商评级依据（均已核实）
阿里巴巴L4–L5SWE-Universe 环境工厂＋MegaFlow＋轨迹生产 50 万条＋异步 RL 闭环[4]；EcomBench[40]；内部基准伴随模型发布
字节跳动L4EdgeBench（12–72h 长期学习评估）[37]＋ReportBench 引用验证流水线[38]＋FinSearchComp 专家标注体系[39]；Seed 体系评测-训练联动
腾讯L3–L4C³-Bench[19]、ArtifactsBench 浏览器渲染评审流水线[41]、CUARewardBench 过程奖励[36]、WorkBuddy Bench 抗污染构造；基准矩阵完整但训练闭环披露较少
Moonshot AIL4K2：Agentic 数据合成流水线＋Colocated RL＋Checkpoint Engine 30s/1T 热更新[44]；未公开发布自研基准
美团L3VoiceAgentEval 用户模拟器工程（150 人设＋三种逼近度校验）[14]；场景化评估强，通用平台未公开
智谱L3AutoGLM 云手机/云电脑设备池＋异步 RL；评估方法学公开有限
华为L3Pangu DeepDiver 系列（开放网络 RL 搜索 Agent）[42]；昇腾推理优化体系
DeepSeekL3–L4V3.2 可验证环境路线（约 2.5 万环境[4]）＋RL；披露颗粒度低
京东L2–L3JoyAgent-JDGenie 产品化多智能体（GAIA 75.15%）[45]；评估基建未见系统披露
百度L2公开渠道未见同级方法学披露，按保守评级处理
图 3｜中国大厂 Agent Infra 能力画像（本报告分析框架，满分 5 分；依据附录 B 表内已核实公开资料打分，属观点性内容）。

附录 C：参考文献References（全部经 arXiv/官网逐一核实，2026-07-27）

  1. [1] Jimenez, C. E., Yang, J., Wettig, A., et al. SWE-bench: Can Language Models Resolve Real-World GitHub Issues? ICLR 2024. arXiv:2310.06770. https://arxiv.org/abs/2310.06770
  2. [2] OpenAI & SWE-bench Team. Introducing SWE-bench Verified. 2024-08-13. https://openai.com/index/introducing-swe-bench-verified/
  3. [3] Scale AI. SWE-bench Pro（1,865 题/41 仓库；Public 731 / Held-out 858 / Commercial 276）. 2025. https://scale.com/leaderboard/swe_bench_pro
  4. [4] Chen, M., Zhang, L., Feng, Y., et al.（Qwen Team, Alibaba & 浙江大学）. SWE-Universe: Scale Real-World Verifiable Environments to Millions. arXiv:2602.02361, 2026-02. https://arxiv.org/abs/2602.02361
  5. [5] Merrill, M. A., Shaw, A. G., Carlini, N., et al.（Stanford / Laude Institute）. Terminal-Bench: Benchmarking Agents on Hard, Realistic Tasks in Command Line Interfaces. arXiv:2601.11868, 2026-01. https://arxiv.org/abs/2601.11868
  6. [6] Xie, T., Zhang, D., Chen, J., et al. OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments. NeurIPS 2024. arXiv:2404.07972. https://arxiv.org/abs/2404.07972
  7. [7] Xie, T., Yuan, M., Zhang, D., et al. Introducing OSWorld-Verified. xlang.ai, 2025-07-28. https://xlang.ai/blog/osworld-verified
  8. [8] Bonatti, R., Zhao, D., Bonacci, F., et al.（Microsoft）. Windows Agent Arena: Evaluating Multi-Modal OS Agents at Scale. arXiv:2409.08264, 2024. https://arxiv.org/abs/2409.08264
  9. [9] Tavakoli, M., et al. Beyond a Million Tokens: Benchmarking and Enhancing Long-Term Memory in LLMs（BEAM/LIGHT）. arXiv:2510.27246, 2025-10. https://arxiv.org/abs/2510.27246
  10. [10] Wu, D., et al. LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory. ICLR 2025. arXiv:2410.10813. https://arxiv.org/abs/2410.10813
  11. [11] Koh, J. Y., Lo, R., Jang, L., et al. VisualWebArena: Evaluating Multimodal Agents on Realistic Visual Web Tasks. ACL 2024. arXiv:2401.13649. https://arxiv.org/abs/2401.13649
  12. [12] Zhou, S., Xu, F. F., Zhu, H., et al. WebArena: A Realistic Web Environment for Building Autonomous Agents. ICLR 2024. arXiv:2307.13854. https://arxiv.org/abs/2307.13854
  13. [13] Xu, P., Li, S., Sun, A., et al. VoiceAgentEval（正文名 OutboundEval）: Expert-Level Intelligent Voice-Agent Evaluation of Xbench's Professional-Aligned Series. arXiv:2510.21244, 2025-10. https://arxiv.org/abs/2510.21244
  14. [14] 声网（Agora）× 美团 × xbench. VoiceAgentEval：AI 外呼智能体评测基准（六大业务领域/30 子场景/150 人设用户模拟器/语音 15 指标）. 2026-02. https://www.shengwang.cn/news/blogdetail/VoiceAgentEval/
  15. [15] Wei, J., et al.（OpenAI）. BrowseComp: A Benchmark for Browsing Agents. arXiv:2504.12516, 2025. https://arxiv.org/abs/2504.12516
  16. [16] Patil, S. G., Mao, H., Yan, F., et al.（UC Berkeley）. The Berkeley Function Calling Leaderboard (BFCL): From Tool Use to Agentic Evaluation. ICML 2025；V4 榜单持续更新. https://gorilla.cs.berkeley.edu/leaderboard.html
  17. [17] Yao, S., Shinn, N., Razavi, P., Narasimhan, K.（Sierra）. τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains. arXiv:2406.12045, 2024. https://arxiv.org/abs/2406.12045
  18. [18] Barres, V., Dong, H., et al.（Sierra）. τ²-Bench: Evaluating Conversational Agents in a Dual-Control Environment. arXiv:2506.07982, 2025-06. https://arxiv.org/abs/2506.07982
  19. [19] Yu, P., et al.（Tencent）. C³-Bench: The Things Real Disturbing LLM based Agent in Multi-Tasking. arXiv:2505.18746, 2025-05. https://arxiv.org/abs/2505.18746
  20. [20] Qin, Y., Liang, S., Ye, Y., et al. ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs（ToolBench）. ICLR 2024. arXiv:2307.16789. https://arxiv.org/abs/2307.16789
  21. [21] Wang, Z., Gao, Y., Wang, Y., et al. MCPTox: A Benchmark for Tool Poisoning Attack on Real-World MCP Servers. AAAI 2026. arXiv:2508.14925. https://arxiv.org/abs/2508.14925
  22. [22] Maharana, A., Lee, D.-H., Tulyakov, S., et al. Evaluating Very Long-Term Conversational Memory of LLM Agents（LoCoMo）. ACL 2024. arXiv:2402.17753. https://arxiv.org/abs/2402.17753
  23. [23] Zhong, W., Guo, L., Gao, Q., et al. MemoryBank: Enhancing Large Language Models with Long-Term Memory. AAAI 2024. arXiv:2305.10250. https://arxiv.org/abs/2305.10250
  24. [24] Andriushchenko, M., Souly, A., Dziemian, M., et al. AgentHarm: A Benchmark for Measuring Harmfulness of LLM Agents. ICLR 2025. arXiv:2410.09024. https://arxiv.org/abs/2410.09024
  25. [25] Debenedetti, E., Zhang, J., Balunović, M., et al.（ETH SPY Lab）. AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents. NeurIPS 2024 D&B. arXiv:2406.13352. https://arxiv.org/abs/2406.13352
  26. [26] Mazeika, M., Phan, L., Yin, X., et al. HarmBench: A Standardized Evaluation Framework for Automated Red Teaming and Robust Refusal. ICML 2024. arXiv:2402.04249. https://arxiv.org/abs/2402.04249
  27. [27] Wan, Y., et al.（Meta）. CyberSecEval 3: Towards Agentic and Contagious Cyber Security Evaluations（Purple Llama）. arXiv:2408.01605, 2024. https://arxiv.org/abs/2408.01605
  28. [28] Wu, Q., Bansal, G., Zhang, J., et al.（Microsoft）. AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation. arXiv:2308.08155, 2023. https://arxiv.org/abs/2308.08155
  29. [29] Hong, S., Zhuge, M., Chen, J., et al. MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework. ICLR 2024. arXiv:2308.00352. https://arxiv.org/abs/2308.00352
  30. [30] Cemri, M., Pan, M. Z., Yang, S., et al.（UC Berkeley）. Why Do Multi-Agent LLM Systems Fail?（MAST，14 种失败模式） arXiv:2503.13657, 2025. https://arxiv.org/abs/2503.13657
  31. [31] Qian, C., Cong, X., Liu, W., et al. Communicative Agents for Software Development（ChatDev）. ACL 2024. arXiv:2307.07924. https://arxiv.org/abs/2307.07924
  32. [32] Kapoor, S., Stroebl, B., Kirgis, P., et al.（Princeton 等）. Holistic Agent Leaderboard: The Missing Infrastructure for AI Agent Evaluation. arXiv:2510.11977, 2025-10. https://arxiv.org/abs/2510.11977
  33. [33] UK AI Security Institute. Inspect: An Open-Source Framework for Large Language Model Evaluations. 2024. https://inspect.ai-safety-institute.org.uk/
  34. [34] Abbas, A., Waggoner, C., Olive, J., et al. Developing and Maintaining an Open-Source Repository of AI Evaluations（inspect_evals，70+ 评测）. arXiv:2507.06893, 2025. https://arxiv.org/abs/2507.06893
  35. [35] AgentProcessBench: Diagnosing Step-Level Process Quality in Tool-Using Agents（1,000 轨迹/8,509 步标注/一致性 89.1%）. arXiv:2603.14465, 2026-03. https://arxiv.org/abs/2603.14465
  36. [36] Lin, H., Tan, X., Qin, Y., et al.（Tencent Youtu Lab）. CUARewardBench: A Benchmark for Evaluating Reward Models on Computer-using Agent. arXiv:2510.18596, 2025-10. https://arxiv.org/abs/2510.18596
  37. [37] Zhu, D., Zhou, X., Qin, S., et al.（字节跳动 Seed 等）. EdgeBench: Unveiling Scaling Laws of Learning from Real-World Environments. arXiv:2607.05155, 2026-07. https://arxiv.org/abs/2607.05155
  38. [38] Li, M., Zeng, Y., Cheng, Z., Ma, C., Jia, K.（ByteDance BandAI）. ReportBench: Evaluating Deep Research Agents via Academic Survey Tasks. arXiv:2508.15804, 2025-08. https://arxiv.org/abs/2508.15804
  39. [39] Hu, L., Jiao, J., Liu, J., et al.（ByteDance Seed 等）. FinSearchComp: Towards a Realistic, Expert-Level Evaluation of Financial Search and Reasoning. arXiv:2509.13160, 2025-09. https://arxiv.org/abs/2509.13160
  40. [40] Min, R., Qiao, Z., Xu, Z., et al.（Tongyi Lab, Alibaba Group）. EcomBench: Towards Holistic Evaluation of Foundation Agents in E-commerce. arXiv:2512.08868, 2025-12. https://arxiv.org/abs/2512.08868
  41. [41] Tencent Hunyuan Team. ArtifactsBench: Bridging the Visual-Interactive Gap in LLM Code Generation Evaluation. arXiv:2507.04952, 2025-07. https://arxiv.org/abs/2507.04952
  42. [42] Shi, W., Tan, H., Kuang, C., et al.（Huawei）. Pangu DeepDiver: Adaptive Search Intensity Scaling via Open-Web Reinforcement Learning. arXiv:2505.24332, 2025. https://arxiv.org/abs/2505.24332
  43. [43] Wang, H., Li, H., Mang, Q., Cheung, A., Sen, K., Song, D.（UC Berkeley）. Do Androids Dream of Breaking the Game? Systematically Auditing AI Agent Benchmarks with BenchJack. arXiv:2605.12673, 2026-05. https://arxiv.org/abs/2605.12673
  44. [44] Moonshot AI. Kimi K2: Open Agentic Intelligence（技术报告）（1.04T MoE；τ²-Bench 66.1%；Checkpoint Engine 30s/1T）. 2025-07. https://github.com/MoonshotAI/Kimi-K2
  45. [45] 京东. JoyAgent-JDGenie：开源端到端多智能体产品（GAIA 验证集 75.15%/测试集 65.12%）. https://github.com/jd-opensource/JoyAgent-JDGenie
  46. [46] OpenAI. Why SWE-bench Verified No Longer Measures Frontier Coding Capabilities. 2026-02-23. https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/
  47. [47] Zhang, Z., Sheng, Y., Zhou, T., et al. H₂O: Heavy-Hitter Oracle for Efficient Generative Inference of Large Language Models. NeurIPS 2023. arXiv:2306.14048. https://arxiv.org/abs/2306.14048
  48. [48] Xiao, G., Tian, Y., Chen, B., et al. Efficient Streaming Language Models with Attention Sinks（StreamingLLM）. ICLR 2024. arXiv:2309.17453. https://arxiv.org/abs/2309.17453
  49. [49] Kwon, W., Li, Z., Zhuang, S., et al. Efficient Memory Management for Large Language Model Serving with PagedAttention（vLLM）. SOSP 2023. arXiv:2309.06180. https://arxiv.org/abs/2309.06180
  50. [50] Anthropic. Demystifying Evals for AI Agents. Anthropic Engineering Blog, 2026-01. https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents