通用智能体评估：首个跨架构跨模型跨基准的系统性研究 General Agent Evaluation
首个通用Agent系统评测：5架构×5模型×6基准的全因子实验
前置知识
ReAct Agent
ReAct（Reasoning + Acting）是一种将推理和行动交替进行的智能体架构范式。智能体在每一步先进行思维链推理（Thought），然后决定执行的动作（Action），观察环境返回的结果（Observation），再进入下一轮推理循环。这种设计让模型能够动态规划、根据中间结果调整策略，而非一次性生成完整方案。ReAct Short是其变体，增加了工具短列表（tool shortlisting）机制，在工具数量庞大时先筛选出最相关的工具子集再执行。
本文对比的五种智能体架构中有两种基于ReAct，理解其推理-行动循环机制是理解实验设计和结果差异的基础。
MCP（Model Context Protocol）
模型上下文协议（MCP）是一种标准化的智能体与工具环境交互协议，定义了模型如何发现、调用和管理外部工具。OpenAI Solo和Claude Code两种智能体架构原生支持MCP，通过该协议与基准测试环境对接。MCP的核心思想是将工具的描述、参数规范和调用接口统一化，使得不同来源的工具可以被任何支持MCP的智能体无缝使用。
MCP是本文讨论的多协议统一方案中的关键协议之一，理解它有助于理解为什么不同智能体架构在相同基准上表现差异巨大。
Schema Guard（模式守卫）
模式守卫是一种智能体内部的质量控制机制：当智能体尝试调用一个参数格式不正确的工具时，系统会检测到schema不匹配并反馈错误信息，允许智能体自我纠正后重试，而不是直接失败退出。本文发现排名前三的架构（OpenAI Solo、Claude Code、Smolagent）都内置了此机制，而ReAct系列则没有。
论文将schema guard识别为与高性能相关的关键架构组件之一，是理解'为什么某些架构表现更好'的核心线索。
Tool Shortlisting（工具短列表）
当环境中可用工具数量庞大时（如AppWorld有约468个工具），将所有工具描述一次性传给LLM会导致上下文过长、成本高昂甚至超出API限制。工具短列表机制通过某种筛选策略（如基于任务描述的相关性排序）预先选出最可能用到的工具子集，再将其暴露给智能体。本文中ReAct Short就是ReAct加上此机制的变体。
这是论文中唯一做了受控消融实验的架构组件，直接影响GPT 5.2在AppWorld上的表现（从0.00提升到0.22），是理解工具密集型环境中架构选择的关键。
Generality Sink（泛化陷阱）
本文提出的新概念，指开源权重模型在某些特定架构或基准上表现出灾难性失败的现象，而闭源前沿模型则不存在此问题。分为两类：架构陷阱（architecture sink），即同一模型在不同架构间表现从0.83暴跌到0.00；基准陷阱（benchmark sink），即所有架构搭配该模型都在特定基准上崩溃。以Kimi-K2.5在τ²-Bench-Telecom上为例，ReAct架构得分0.83而OpenAI Solo架构得分为0.00。
这是论文最重要的发现之一，揭示了开源模型与闭源模型之间的本质差距不仅在于平均性能，更在于对架构选择的敏感性。
Variance Decomposition with η²
方差分解是一种统计方法，用于量化不同因素对结果变异的贡献比例。本文使用 η² = Var(E[Y|X]) / Var(Y) 来衡量模型选择和架构选择各自解释了多少成功率方差。其中Y是单元格成功率，X是分组变量（模型或架构）。η²越大说明该因素对结果的影响越大。
论文用此方法得出'模型选择解释27.8%方差而架构仅解释0.5%'的核心结论，是理解全文最关键的定量分析工具。
研究动机
当前AI智能体评估体系存在两个根本性缺陷，严重阻碍了通用智能体的研究进展。首先是框架层面的碎片化问题：现有的评估工具如BrowserGym只支持Web交互协议，Harbor只支持CLI协议，即使是最成熟的Inspect框架也需要为每个基准手动配置工具集、沙箱和求解器。这意味着研究者无法将同一个智能体原封不动地放到不同基准上测试，每次适配都需要大量工程工作。其次是基准测试本身的封闭性问题：像SWE-Bench Verified、τ²-Bench等主流基准都采用定制化的通信协议，隐式假设智能体已经了解基准特定的目标和环境语义，不提供通用接口。这种双重壁垒导致了一个关键空白：至今没有任何研究系统地比较过同一个未经修改的智能体在多个异构基准上的表现，因此无法分离出智能体架构本身的贡献。现有工作如HAL、BrowserGym、Harbor各自在单一维度上做了整合，但都要求智能体或基准的一端做出妥协（见Table 1的五维对比）。
本文的目标是本文的直接目标是开展首个系统性的通用智能体评估研究，具体而言要在三个层面实现突破。第一，设计一个统一协议（Unified Protocol）作为智能体与基准之间的中间层，使得任意智能体可以用其原生协议（工具调用、MCP、代码生成、CLI）与任意基准交互，无需修改任何一方的实现。第二，构建一个评估框架Exgentic实现该协议，能够以黑盒方式执行原始智能体和原始基准，在隔离可复现的会话中运行。第三，发布首个公开的通用智能体排行榜（Open General Agent Leaderboard），覆盖5种智能体架构×5种骨干LLM×6种基准的全因子实验（共25个配置，每个基准100个任务，总评估成本约2万美元），为社区提供一个衡量通用智能体进步的公共参考点。
与已有工作不同的是，本文的独特切入角度在于将智能体评估从'单领域深度'转向'跨领域广度'的系统性比较。在此之前，即使是最全面的评估框架（如Inspect）也只是在基础设施层做了整合，但每个基准的适配仍然是手工的。本文提出的Unified Protocol是一个'窄腰'（narrow waist）设计：新增一个智能体或一个基准只需要适配Unified Protocol，而不需要适配所有基准或所有智能体。这使得评估可以真正覆盖异构协议——工具调用API（ReAct、τ²-Bench）、MCP（OpenAI Solo、Claude Code）、Python代码生成（Smolagent、AppWorld）、bash/CLI（Claude Code、SWE-Bench Verified）和对话消息（τ²-Bench）。这种设计让论文能够首次回答一个此前无法回答的问题：在控制了骨干模型和基准的条件下，智能体架构本身到底有多重要？
核心方法
本文的方法论可以分为三个层次理解。最底层是Unified Protocol的设计，这是一个从现有智能体和基准通信模式中归纳出的通用接口规范，用三个字段（task/context/actions）就能忠实表示任何可分解为离散动作的交互协议。中间层是Exgentic评估框架，它为每个基准和每个智能体分别编写Unified Protocol适配器，然后在隔离环境中以黑盒方式执行原始实现，编排器实例化对应的协议包装器并运行150个配置。最上层是实验设计，采用全因子设计覆盖5种架构×5种模型×6种基准，每个单元格使用100个任务（τ²-Bench航空子域50个），每任务最多100轮交互。关键的直觉是：通过将异构协议统一到同一个中间表示，就可以在完全相同的条件下比较不同智能体，消除了'适配工程差异'这个混淆变量。
本文的核心创新是Unified Protocol的'窄腰'架构设计，这与此前所有评估框架的本质区别在于：BrowserGym和Harbor强制智能体使用固定传输层（Web或CLI），实际上是评估了一个'削弱版'的智能体；AgentBeats和CUBE要求双方都绑定到特定传输协议；而Unified Protocol是一个忠实的中间层，它不替换任何一方的原生协议，而是作为翻译器在它们之间做语义保持的转换。每个Unified Protocol实例包含三个字段：task（任务描述，告诉智能体应该做什么）、context（上下文信息，提供完成任务所需的额外知识）、actions（可用动作集合，定义环境中所有可执行的操作及其参数类型和返回值）。此外，协议允许实现者可选地指定一个消息动作（向用户发送消息）和一个最终答案动作（向基准提交结果），以支持常见的交互模式。这种设计的精妙之处在于它是从现有协议中归纳而非外推的，因此保证了每个现有协议的语义都能被忠实表示。
方法步骤详情
方法的具体执行步骤如下。第一步是基准适配：对每个基准（BrowseComp+、τ²-Bench、SWE-Bench Verified、AppWorld），从参考智能体实现中推导出Unified Protocol接口，保留基准的预期语义。例如τ²-Bench原本使用Python API接收用户消息并返回工具调用，现在被映射为message action和Exgentic actions。SWE-Bench Verified原本需要生成代码补丁，现在被暴露为单一的bash动作。第二步是智能体适配：对每个智能体（ReAct、ReAct Short、Smolagent、OpenAI Solo、Claude Code），编写包装代码将其原生交互方式适配到Unified Protocol。例如ReAct通过LiteLLM的工具调用接口集成，Smolagent通过将基准动作暴露为Python函数集成，OpenAI Solo通过MCP适配器集成。第三步是执行与评估：Exgentic编排器为每个配置创建隔离的Docker容器会话，执行智能体与基准的交互，收集轨迹数据，使用各基准原始的成功率定义和评估程序计算结果。LLM采样使用各提供商的默认参数（温度、top-p、推理模式），避免超参数调优对比较的干扰。
技术新颖性
本文的技术新颖性体现在多个层面。首先是概念层面：提出了Unified Protocol作为评估领域的'窄腰'抽象，这是首个不绑定特定传输层的智能体-基准交互协议，使得'任何智能体评估任何基准'成为可能。其次是实证层面：这是首个对通用智能体进行全因子系统性研究的工作，此前没有任何论文同时控制了架构、模型和基准三个变量并做了完整的交叉比较。第三是发现层面：论文提出了'generality sink'这一新概念，揭示了开源模型特有的架构陷阱和基准陷阱现象。第四是分析层面：将ERRORMAP失败分析方法适配到智能体评估中，发现了27个失败类别，并证明虽然架构仅解释0.5%的成功率方差，但在失败模式上架构间的差异是统计显著的（χ²(196)=328.5, p<10⁻¹⁰, Cramér's V=0.17）。这种'聚合指标看不出差异但细粒度分析能发现差异'的发现本身就是方法论上的贡献。
实验结果
论文的核心发现可以归纳为五个方面。第一，通用智能体无需领域定制就能在所有测试领域取得有意义的表现：每个未经修改的智能体在软件工程、客户服务、技术支持、深度研究和个人助手六个基准上都产生了非平凡的性能，证明了通用智能体作为研究方向的可行性。第二，模型选择主导聚合方差但架构在特定条件下是决定性的：在15个闭源配置上方差分解显示模型选择解释27.8%的方差而架构仅解释0.5%（58倍差距），但在单一模型内架构选择可导致高达12个百分点的波动（Claude Opus 4.5配置中最佳0.73、最差0.61）。交互效应占5.4%，比架构主效应大一个数量级，说明最优架构选择取决于模型。第三，通用智能体在6个基准中的4个上与重度定制的领域专家表现无统计显著差异：SWE-Bench Verified上OpenAI Solo+Claude Opus 4.5得分0.81 vs 专家0.79，τ²-Bench-Airline上0.74 vs 0.73，AppWorld上0.70 vs 0.73。第四，开源权重模型表现出闭源模型不存在的'泛化陷阱'：Kimi-K2.5在τ²-Bench-Telecom上ReAct架构得0.83而OpenAI Solo架构得0.00（94%的Kimi-K2.5+自主架构τ²-Bench会话零步终止），DeepSeek-V3.2在AppWorld上所有架构最高仅0.13。第五，失败模式能区分聚合评分无法区分的架构差异：Claude Code和OpenAI Solo倾向于过早终止（Premature Termination），ReAct和ReAct Short倾向于跳过证据收集（Evidence Retrieval Omission），Smolagent以搜索恢复与适应失败（Search Recovery & Adaptation）为主。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| SWE-Bench Verified（软件工程） | 成功率 | 最佳配置 OpenAI Solo+Claude Opus 4.5: 0.81 | 领域专家最佳: 0.79 | 通用智能体略优，差距在采样噪声范围内 |
| BrowseComp+（深度研究） | 成功率 | 最佳配置 OpenAI Solo+Claude Opus 4.5: 0.68, Smolagent+Claude Opus 4.5: 0.70 | 领域专家最佳: 0.80 | 通用智能体落后约10-12pp，BrowseComp+是两个通用智能体落后的基准之一 |
| τ²-Bench-Airline（客户服务-航空） | 成功率 | 最佳配置 OpenAI Solo+Claude Opus 4.5: 0.74 | 领域专家最佳: 0.73 | 通用智能体与专家持平 |
| τ²-Bench-Retail（客户服务-零售） | 成功率 | 最佳配置 OpenAI Solo+Claude Opus 4.5: 0.85 | 领域专家最佳: 0.86 | 通用智能体与专家持平 |
| τ²-Bench-Telecom（客户服务-电信） | 成功率 | 最佳配置 Smolagent+Gemini 3: 0.88 | 领域专家最佳: 0.98 | 通用智能体落后约10pp，是两个通用智能体落后的基准之一 |
| AppWorld（个人助手） | 成功率 | 最佳配置 Smolagent+Claude Opus 4.5: 0.70 | 领域专家最佳: 0.73 | 通用智能体与专家持平，差距在采样噪声范围内 |
局限与改进
本文的局限性主要体现在以下几个方面。首先是评估规模的限制：由于成本约束（总评估成本约2万美元），实验仅覆盖5种LLM、5种智能体实现和6种基准，每基准100个任务。这意味着Wilson置信区间半宽达到±7-13个百分点，单个单元格的比较存在相当的不确定性。其次，实验仅测试了两个开源权重模型（DeepSeek-V3.2和Kimi-K2.5），'泛化陷阱'现象是否适用于更多开源模型尚属未知。第三，论文承认多模态和连续动作扩展在附录中讨论但未在主实验中实现，这意味着当前评估仅限于文本离散动作场景。第四，各基准使用默认LLM采样参数（温度、top-p等），虽然避免了超参数调优的混淆，但也意味着结果可能不反映各配置的最优表现。从笔者角度看，论文的一个隐含局限是Unified Protocol的忠实性依赖于适配器实现的质量——如果某个适配器引入了信息损失，那么该配置的结果就不可靠，但论文对此缺乏系统性的验证。此外，失败分析虽然揭示了架构间的差异，但27个失败类别的划分标准和人工标注的一致性报告不够充分。
独立分析的弱点
本文存在几个值得关注的弱点。第一，Unified Protocol的通用性假设值得商榷：论文声称该协议'从构造上保证了每个现有协议的语义都能被忠实表示'，但三个字段（task/context/actions）的极简设计可能无法捕获所有交互模式，例如需要持续监控或流式反馈的场景。改进方向是引入第四个字段如'constraints'或'state'来支持更丰富的交互语义。第二，开源模型的评估不够充分：仅测试了DeepSeek-V3.2和Kimi-K2.5两个开源模型，且两者都表现出泛化陷阱，但这可能是因为这两个模型本身的能力水平较低，而非开源模型的普遍特性。建议增加对Llama系列、Qwen系列等更多开源模型的测试。第三，成本效率分析的深度不足：论文报告了30倍的成本效率差异但未深入分析导致差异的具体因素（如重试次数、上下文长度、工具调用次数），改进方向是对成本做更细粒度的归因分析。第四，失败模式分析虽然有27个类别，但未提供类别间的层次关系或因果链，难以指导具体的架构改进。
未来方向
论文和基于其成果可以延伸出多个研究方向。作者明确提出的方向包括：训练模型在不同架构间保持一致的表现，使模型研究和智能体架构研究能够独立推进；开发新的智能体架构和组件，因为简单的schema guard和tool shortlisting就能显著提升性能；将成本效率作为第三个独立的优化轴。基于本文成果可延伸的方向包括：将Unified Protocol扩展到多模态场景（图像、视频、音频输入输出），这在论文附录中已有初步讨论；引入自适应架构选择机制，根据基准特征动态选择最优架构而非固定使用一种；将评估框架与自动化智能体设计（agent design automation）结合，利用失败模式分析的结果指导架构搜索；将排行榜扩展到更多语言和文化背景的任务上，因为当前基准主要是英文环境；研究'泛化陷阱'的成因机制，通过干预实验（如修改系统提示、调整工具描述格式）来定位导致开源模型失败的具体因素。
复现评估
本文在可复现性方面做得较好。论文明确声明代码、评估框架、排行榜和轨迹数据都发布在www.exgentic.ai上。实验设计强调隔离和可复现性：每个配置在独立的Docker容器中运行，Claude Code明确在容器中执行以确保隔离。LLM采样使用各提供商的默认参数，避免了隐藏的超参数选择。完整的运行配置随代码一起发布。然而，复现仍面临几个挑战：首先，总评估成本约2万美元，这对大多数研究团队来说是一笔不小的开支；其次，部分基准（如τ²-Bench）的模拟用户组件可能引入随机性，需要多次运行才能获得稳定估计；第三，Claude Code是闭源产品，版本更新可能导致行为变化，论文使用的是v2.1.7；第四，论文使用的模型版本（如Claude Opus 4.5、GPT 5.2、Gemini 3）都是特定时间点的快照，API更新后结果可能不同。总体而言，框架和协议设计是可复现的，但具体数值结果高度依赖于模型版本和API行为。
论文图表
