第 19 章第二部分：核心组件深度解构

Agent 全景深潜与横向对比

深度解析 Nexus 所有 16 种内置 Agent 的实现机制、关键特性和适用场景，提供选型决策指南

最后更新：2026年10月6日 Nexus Agent 对比选型实现机制

为什么需要这章

第四章给了 Agent 全景图，第十七、十八章分别深入了 main_agent 和 Installed Agent 的实现。但当你真的要选 Agent 跑实验时，你需要一张更完整的对照表——不只是「适合什么任务」，而是「它的推理循环怎么写的、上下文怎么管的、工具怎么注册的、慢了卡了怎么调」。

这章把这 16 种 Agent 拆开，从实现层面做横向对比，最后给你一个选型决策树。

分类维度：不只是「四类」

第四章按使用场景分了四类，但实现层面更有意义的分类维度是：

维度	说明
推理范式	LLM loop（自循环）/ CLI 代理（转发）/ 单轮（无循环）
工具来源	框架注册 / 自带工具集 / 外部系统自带
上下文管理	手动压缩 / 自动 compaction / 不管理（外部系统管）
执行位置	Host 进程 / Runtime 沙箱 / 两者都有
并行 tool call	支持 / 不支持 / 取决于底层模型

第一类：通用 Tool-Calling Agent

main_agent

定位：默认 Agent，大多数任务的起点。

推理循环（ch17 详解）：

while iterations < max_iterations:
    messages = context.get_messages()
    response = llm_client.chat(messages, tools=schema)
    if response.stop_reason == "end_turn":
        return response.content
    # tool call
    for tool_call in response.tool_calls:
        result = execute_tool(tool_call)
        context.append(ToolMessage(result))

核心在 _call_llm_and_parse() 和 _handle_tool_calls() 两个方法。

关键实现特性：

工具过滤：agent_config.tools 列表直接控制哪些 tool schema 出现在 LLM 请求里。不在列表里的工具对 LLM 完全不可见。
并行 tool call：parallel_tool_calls 参数控制，设为 true 时 LLM 可以在一轮里发多个 tool call（需要模型支持，如 GPT-4o、Claude 3.5）。
上下文压缩：依赖 Context 层的 compaction（ch15），Agent 本身不主动管理。当 context_window - token_used < threshold 时触发。
工具输出截断：tool_output_truncation（默认 10000 tokens），超过的部分截断，防止单个工具输出撑爆上下文。
超时处理：observation_time_timeout（工具执行，默认 300s）和 inference_time_timeout（LLM 推理，默认 120s），超时后抛异常，Task 捕获后记为失败。

适合场景：绝大多数需要工具调用的任务；快速验证一个新 Task 是否可行。

不适合：需要大量代码操作的任务（用 swe_agent 或 codeact 更好）；需要在沙箱里跑第三方 Agent 的（用 Installed Agent）。

demo_agent

定位：教学用，展示如何写一个最小 Agent。

实现：main_agent 的极简版，固定 max_iterations=5，固定工具列表只有 python_code_interpreter，没有并行 tool call，没有复杂的错误处理。

关键价值：读它的源码是理解「怎么写一个 Agent」最快的方式，大约 80 行核心代码。

适合场景：学习框架；调试 Tool 的注册和执行是否正确。

toolcall_agent

定位：main_agent 的变体，基于 BaseAgent 框架实现标准 tool-calling 循环。

与 main_agent 的区别：

更简洁的循环实现，直接继承 BaseAgent
工具列表通过 tool_name_list 参数传入（而不是 agent_config.tools）
没有 parallel_tool_calls 参数（不支持并行）

实现关键：核心在 BaseAgent._run_agent() → 子类实现 _call_llm() 和 _execute_tool()。

适合场景：需要自定义工具组合，但不需要 main_agent 的全部复杂度时。

第二类：代码修复 Agent

swe_agent

定位：SWE-bench 风格任务的首选，针对代码仓库操作深度优化。

关键实现特性：

自带工具集：str_replace_editor（精确文件编辑）、search_stateful/*（带状态的代码搜索）、python_code_interpreter。工具集在 Agent 内部硬编码，不通过 agent_config.tools 配置。
Prompt 工程：System prompt 包含详细的代码编辑指令，告诉 LLM 如何用 str_replace_editor 做精确替换（类似 Claude Code 的编辑范式）。
工作目录管理：固定 working_dir=/workspace/repo，Task 负责在运行前把代码仓库 clone 到这个位置。
迭代次数：默认 max_iterations=30，因为代码修复通常需要多轮调试。

与 main_agent + swe_tools 的区别：swe_agent 的 prompt 是针对代码修复调优过的，工具集是固定的最佳实践组合。用 main_agent 手动配 /tools: ["str_replace_editor", ...] 效果通常不如直接用 swe_agent。

适合场景：SWE-bench、任何需要在真实代码仓库上做修改的任务。

swe_agent 的演进：从专用工具到 bash-only

Princeton 团队官方网站（swe-agent.com）首行推荐 mini-swe-agent：“We recommend mini-swe-agent instead of SWE-agent.” SWE-agent 进入维护模式。mini-swe-agent 核心理念：随着 LLM 能力增强，精心设计的 ACI 工具不再是必要条件——仅 100 行 Python + bash-only 即可达 >74% SWE-bench Verified。被 Meta、NVIDIA、Essential AI、Anyscale 等采用（README 一手；IBM、Nebius 为二手来源）。

⚠️ 74% 的数字口径：这是 README 的一手数字，但随底层模型变化（README 同时给出「Gemini 3 Pro 配 mini-swe-agent 达 74%」）；官方网站 News 栏另有「100 行 Python 达 65% SWE-bench Verified」的历史条目。两者不同期、不同模型，不可混用，引用时须标明口径。

mini-swe-agent v2 分支更新：新增多语言支持（Python/JS/Go/Rust）、更复杂的仓库结构处理、改进的 diff 生成策略。从实验性工具升级为可持续维护的项目。当前版本 v2.4.6（PyPI，2026-07-23 发布；v2 提供官方 migration guide，v1 保留在独立分支）。这条”没变”本身也是一条信息：一个被官方网站首行推荐、被 Meta / NVIDIA / Anyscale 采用的项目，可以连续 2.5 个月不发版本。 对”用发布频率判断项目活跃度”这种常见启发式，这是个反例——它与 Ch18 里 TwillAI / agentbox-sdk 那两处”看似停更实为误判”的情形构成一对：发布频率既不能证明项目死了，也不能证明它活着，判断依据应当是 issue 响应、依赖更新与安全公告，不是版本号动了没有。

⚠️ 依赖链也是攻击面：mini-swe-agent 经 litellm 路由所有模型调用，团队曾标注 litellm 1.82.7 / 1.82.8 为受损版本（可能泄露 SSH key 与 API key），新版本已在依赖约束中屏蔽。以 Nexus Installed Agent 方式集成第三方 CLI 时，应锁定依赖版本——这是 Ch10 Runtime「凭证不落地」设计的一个外部佐证：Agent CLI 自身的依赖链同样是攻击面。（本条来自官方部署资料与仓库依赖约束，具体版本号以官方安全公告为准。）

⚠️ 「屏蔽已知坏版本」只能防住已经发生过的那一次，不是一套机制。 本轮回 PyPI 核得 litellm 已到 1.104.0（2026-10-03），距受损的 1.82.x 有 20 多个版本；以这个发布节奏，任何静态的坏版本名单在写下的那一刻就开始过期。因此本节的建议应改写为三项的组合，并把「屏蔽」降级为辅助手段：锁定版本（知道自己在跑什么）、订阅上游安全公告（知道什么时候该动）、定期复检（知道锁定是否已过期）。这与 Ch18 的「Installed Agent 的 CLI 版本必须锁定、升级前跑冒烟」是同一原则的两处表述——Ch18 那处针对的是 ANTHROPIC_BASE_URL 的逐版本兼容性面，此处针对的是依赖链，两者应保持一致。

这对 Nexus swe_agent 的影响：保留当前实现作为兼容，但可考虑新增 mini-swe-agent 风格的极简 Agent（无需 tool schema、线性消息历史、subprocess.run 独立执行）。

codeact

定位：实现 CodeAct 范式——「用 Python 代码作为 Action」，而不是预定义的 tool schema。

核心思想（来自 CodeAct 论文）：

与其让 LLM 调用 edit_file(path, old, new)，不如让 LLM 直接生成可执行的修改代码，在沙箱里 exec()。

实现关键：

自带 codeact_tools.py（39KB），实现了文件操作、搜索、终端控制等全套 Python 函数
LLM 的响应是一段 Python 代码（放在 action 字段里）
Runtime 执行这段代码，把 stdout/stderr 作为 observation 返回给 LLM
循环直到 LLM 输出 Final Answer

优势：表达能力远强于预定义 tool schema——可以用循环、条件、复杂逻辑。劣势：需要沙箱有 Python 执行环境；安全风险更高（LLM 生成的代码可能有害，但 Runtime 沙箱隔离了）。

适合场景：需要复杂逻辑的任务；预定义工具表达不出来的操作。

第三类：Installed Agent（外部 Agent 适配器）

这类 Agent 的核心思想：不重新实现，原样跑，只代理 LLM 请求。

claude_code / codex / gemini_cli / openclaw

共同机制（ch18 详解）：

在 Runtime 沙箱内安装 Agent CLI（npm install -g @anthropic-ai/claude-code 等）
启动 LLM Proxy Server（Host 侧，监听端口）
设置环境变量让 Agent CLI 的 API 请求指向 Proxy
运行 Agent CLI，它的所有 LLM 调用都被 Proxy 拦截并转发给 Host 的 OpenAI Client
Host 记录轨迹、计数 token

各 Agent 的差异：

Agent	CLI 安装命令	环境变量劫持	特点	CLI 版本快照（2026-09-17）
`claude_code`	`npm install -g @anthropic-ai/claude-code`	`ANTHROPIC_BASE_URL`, `ANTHROPIC_API_KEY`	自带文件编辑工具；模型支持面由 CLI 自行决定	2.1.274
`codex`	`npm install -g @openai/codex`	`OPENAI_BASE_URL`, `OPENAI_API_KEY`	OpenAI 官方 CLI；同上	0.154.0
`gemini_cli`	`npm install -g @google/gemini-cli`	`GEMINI_BASE_URL`, `GEMINI_API_KEY`	Google 官方 CLI；同上	0.60.0（GitHub 另有 nightly 标签，勿混用）
`openclaw`	`pip install openclaw`	`OPENCLAW_API_BASE`, `OPENCLAW_API_KEY`	腾讯内部 Agent，支持工具扩展	无公开版本号可核

⚠️ 本表原写「claude_code 支持 Claude 3.5/3.7」「codex 支持 o1/o3」「gemini_cli 支持 1.5/2.0」，这三个代际对应 2025 年产品线，已整体腐烂。 这类数字每轮扫描都会烂，故不再写死模型号，改为机制说明 + CLI 版本快照。

机制要点：Installed Agent 的模型支持面由被代理的 CLI 决定，不由 Nexus 决定。 这既是该模式的好处（模型能力自动跟随 CLI 演进）也是约束（想换模型只能升 CLI，Nexus 侧无法指定）。

关键实现细节：

安装失败处理：setup() 阶段检查 CLI 是否已安装，已安装则跳过（节省时间）
Proxy 端口冲突：每个 Installed Agent 实例需要独立端口，框架通过 find_free_port() 自动分配
超时：agent_config.timeout（默认 3600s），整个 Agent CLI 的运行时间
工作目录：agent_config.working_dir，Agent CLI 的启动目录

适合场景：

你想用这些成熟 Agent 的能力，但需要用 Nexus 的批量执行、评分、轨迹采集
你在对比不同 Agent 框架在同一个 Task 上的表现
你在研究这些 Agent 的推理轨迹（Nexus 的轨迹采集是统一的）

第四类：专用 Agent

browser_gym_agent

定位：浏览器操作任务（WebArena、BrowseComp、VisualWebArena）。

实现关键：

观察压缩：observation_type 参数
- axtree：Accessibility Tree（最常用，token 效率高）
- html：原始 HTML（token 消耗大，但信息最完整）
- screenshot：截图（多模态模型用）
增量观察：use_delta_observation: true 时，只返回 DOM 的变化部分（节省 token）
站点感知过滤：use_task_aware_filter: true 时，根据任务描述过滤掉无关的 DOM 元素
Action 类型：action_type: "bid" 用可交互元素的 bid ID；"coordinate" 用坐标；"code" 用代码生成操作

上下文管理：浏览器任务的上下文增长很快（每次观察可能 2000-5000 tokens），需要配合 compaction 策略。

适合场景：任何需要操作网页的任务；WebArena 等 benchmark。

search_agent / mm_search_agent

定位：信息检索任务。

search_agent：

工具集：google_search、visit、text_to_image_search
推理循环：搜索 → 访问结果 → 判断是否找到答案 → 继续搜索或结束
特点：实现了多轮搜索策略，会根据当前信息调整搜索 query

mm_search_agent（多模态搜索）：

额外工具：image_visit、image_to_image_search
可以「用图片搜索」和「搜索图片中的信息」
适合需要理解图片内容的检索任务

science_agent

定位：科学研究任务（如 SciBench、ScienceQA）。

特点：

工具集包含科学计算工具（python_code_interpreter 加上科学库）
System prompt 包含科学推理指令
通常配合 single_turn 或少量 iteration 使用（科学问题往往不需要复杂多轮）

terminus2

定位：终端操作任务，使用 XML 解析范式。

实现关键：

LLM 输出 XML 格式 action（<action type="...">...</action>）
Parser 解析 XML 得到要执行的操作
在 Runtime 执行，返回结果
特点：XML 比 JSON 更容易让 LLM 正确输出（ fewer syntax errors）

rondo_agent

定位：Rondo 范式（具体范式需查源码，推测是一种特定的推理循环设计）。

注：Rondo 范式的细节需要查 Nexus 源码确认，这里先留空。如果你能提供 Nexus 仓库的 Agent 源码路径，我可以补充完整。

single_turn

定位：单轮 LLM 调用，无工具，无循环。

实现：最简单——直接调用一次 LLM，返回结果。连 tool schema 都不传。

适合场景：不需要工具的任务；作为 baseline；快速测试 prompt 效果。

wide_agent（Ch20 详述）

定位：宽工具集 Agent，在 water_emergency 等复杂 Task 中使用。

特点：

工具集非常宽（可能 20+ 个工具），包括 MCP 接入的外部工具
支持并行 tool call（同时查多个信息源）
上下文管理更激进（因为工具多、轨迹长）
在 Ch20 的 water_emergency Case Study 里有完整的轨迹示例

横向对比矩阵

读数说明：下列矩阵共 17 行，含 rondo_agent 占位行（范式待确认）。正文与「架构映射」中的「16 种 Agent」不含该 Agent——16 = 17 − rondo_agent。

架构层分类

在实现维度对比之前，更值得理解的是 Agent 的架构选择——EVAL 报告将 10 个编码 Agent 归为四大架构：

架构	代表 Agent	核心思想	优势	劣势
Code-as-Action	codeact / OpenHands	Agent 写 Python 代码作为 Action	表达力最强，可写循环/条件	需沙箱执行，安全风险
Agent-Computer Interface	swe_agent / mini-swe-agent	自带专用工具集操作代码	精确控制，高效	工具设计决定上限
Plan-and-Execute	terminus2 / Devin	先规划再执行	长程任务更稳定	规划错误难回溯
Tool-Calling	main_agent / demo_agent	标准 function calling 循环	最通用，最灵活	依赖模型 tool-calling 能力

此外还有两种极端架构：

Agentless：无 Agent 循环，固定三阶段流水线（fault localization → patch generation → patch selection），成本极低
Moatless：极简上下文策略（只获取直接相关的代码位置），用 Haiku 4.5 达 35.9%——pass-rate-per-dollar 最优

📌 待补的最强证据（方向已登记，数字未采信）：本节这条论断目前靠的是三条间接证据（mini-swe-agent 用弱模型打高分、Moatless 用 Haiku 达 35.9%、Agentless 的静态分解）。有一条更直接的证据本轮未能回源——有研究报告称同一套模型权重在不同 agent harness 下完成率相差近一倍，这类对照把模型变量控制住了，是本论断迄今最干净的形式。⚠️ 该数字无编号无作者，本轮未取到一手源，只登记方向不作断言；可以安全引用的版本是：已有研究报告同权重跨 harness 的性能差可达倍数级。拿到编号后应替换掉现有的三条间接证据作为主依据。

架构选择比模型选择更重要。Nexus 的 16 种 Agent 映射：

Code-as-Action：codeact
Agent-Computer Interface：swe_agent
Plan-and-Execute：terminus2
Tool-Calling：main_agent、demo_agent、toolcall_agent、wide_agent、search_agent、mm_search_agent、science_agent、browser_gym_agent
CLI 代理（特殊）：claude_code、codex、gemini_cli、openclaw
无循环：single_turn

Agent	推理范式	工具数（典型）	并行 tool call	上下文压缩	典型 token/iter	适合任务类型
`main_agent`	LLM loop	可配置（3-10）	✅（可选）	Context 层 compaction	500-2000	通用
`demo_agent`	LLM loop	1（固定）	❌	无	~500	教学
`toolcall_agent`	LLM loop（BaseAgent）	可配置	❌	Context 层 compaction	500-1500	自定义工具组合
`swe_agent`	LLM loop	~5（固定最佳实践）	❌	Context 层 compaction	1000-3000	代码修复
`codeact`	Code-as-Action	全套 Python 函数	N/A（代码表达）	Context 层 compaction	500-2000（代码）+ 观察	复杂逻辑操作
`claude_code`	CLI 代理	Claude Code 自带	取决于 CLI	CLI 自己管	变量大	代码任务 + 轨迹研究
`codex`	CLI 代理	Codex 自带	取决于 CLI	CLI 自己管	变量大	代码任务（OpenAI 模型）
`gemini_cli`	CLI 代理	Gemini CLI 自带	取决于 CLI	CLI 自己管	变量大	代码任务（Google 模型）
`openclaw`	CLI 代理	OpenClaw 自带	取决于 CLI	CLI 自己管	变量大	腾讯内部场景
`browser_gym_agent`	LLM loop	~20（浏览器操作）	❌	观察压缩 + compaction	2000-5000（观察）+ 响应	网页操作
`search_agent`	LLM loop	~3（搜索相关）	✅（可选）	Context 层 compaction	500-1500	信息检索
`mm_search_agent`	LLM loop	~5（多模态搜索）	✅（可选）	Context 层 compaction	1000-2000	多模态检索
`science_agent`	LLM loop / single	~3（科学计算）	❌	Context 层 compaction	500-1500	科学推理
`terminus2`	XML Action loop	~10（终端操作）	❌	Context 层 compaction	500-1500	终端操作
`rondo_agent`	Rondo 范式	待确认	待确认	待确认	待确认	待确认
`single_turn`	单轮，无循环	0	N/A	N/A	~500	简单问答
`wide_agent`	LLM loop	20+（宽工具集）	✅	激进 compaction	1000-3000	复杂多工具任务

工具调用效率指标

MCPAgentBench（2026）首创效率指标，揭示了一个重要现象：基准得分高 ≠ 效率高。

TFS（Tool Finding Success）：Agent 找到正确工具的成功率
TEFS（Tool Execution Efficiency）：找到正确工具后成功执行的效率

部分 Agent 在基准任务上完成度高但 TFS 低（大量无效工具调用——如 50+ 次调用才找到正确工具），部分 Agent 完成度中等但 TFS 高（精准调用——仅需 10 次调用）。对于生产环境，后者往往更优（成本更低、延迟更小、更稳定）。

这对 Nexus 横向对比的启示：功能覆盖与调用效率是两个正交维度，选型时需要同时考虑。在工具数很多的 Agent（如 wide_agent 的 20+ 工具）中，TFS 尤为关键——工具越多，找到正确工具的难度越大。

选型决策树

你的任务需要工具调用吗？
├── 不需要 → single_turn
└── 需要
    ├── 任务涉及代码仓库修改？
    │   ├── 是 → swe_agent（首选）或 codeact（需要复杂逻辑时）
    │   └── 否
    │       ├── 任务涉及网页操作？
    │       │   ├── 是 → browser_gym_agent
    │       │   └── 否
    │       │       ├── 任务涉及信息搜索？
    │       │       │   ├── 是 → search_agent（纯文本）或 mm_search_agent（多模态）
    │       │       │   └── 否
    │       │       │       ├── 需要跑第三方 Agent CLI？（Claude Code/Codex/Gemini CLI）
    │       │       │       │   ├── 是 → 对应的 Installed Agent
    │       │       │       │   └── 否
    │       │       │       │       ├── 是否需要高效工具调用（低 TFS 成本）？
    │       │       │       │       │   ├── 是
    │       │       │       │       │   │   ├── 需要最高性价比（pass-rate-per-dollar 最优）？
    │       │       │       │       │   │   │   ├── 是 → 当前默认 Sonnet 档（`claude-sonnet-5-5`；1M 上下文，$2/$10 per Mtok，cache reads $0.20/Mtok）+ Moatless 极简上下文策略
    │       │       │       │       │   │   │   └── 否 → 工具数少的 Agent（main_agent + 精选工具）
    │       │       │       │       │   └── 否
    │       │       │       │       │       ├── 工具很多（20+）且任务复杂？
    │       │       │       │       │       │   ├── 是 → wide_agent
    │       │       │       │       │       │   └── 否 → main_agent（默认选择）
    │       │       │       └── 科学计算任务？ → science_agent

⚠️ 决策树里不要写相对成本比例。 本节原写「Sonnet 5 = 60% Opus 4.8 成本」——这类比例随每次代际更替失效：按当前公开价，Sonnet 档的 $2/$10 对 Opus 档的 $4/$20 是 50%（原写 60% 亦未注明来源与口径，可能是含缓存的 blended 价）。成本维度一律写绝对价格 + 抓取日期，比较交给读者。 本轮按官方 changelog 一手核定的两个档位是：claude-sonnet-5-5（2.1.284，2026-09-28 起为默认 Sonnet；1M 上下文，$2/$10 per Mtok，cache reads $0.20/Mtok）与 claude-opus-5-5（2.1.280，2026-09-22 起为默认 Opus；1M 上下文，$4/$20 per Mtok）。

性能特征（经验数据）

以下数据来自 Nexus 团队在各类 benchmark 上的运行经验（具体数值可能因版本和配置而异）：

Agent	平均 iteration 数	平均 token 消耗/实例	超时率
`main_agent`（默认配置）	5-15	5K-30K	< 5%
`swe_agent`（SWE-bench）	8-25	15K-80K	~10%
`browser_gym_agent`（WebArena）	5-20	20K-100K	~15%
`codeact`	3-10	8K-40K	< 5%
Installed Agent（Claude Code 等）	变量极大	变量极大	取决于 CLI

SWE-bench Verified 排名（2026 年 7 月）⚠️ 已饱和

⚠️ SWE-bench Verified 已于 2026 年 7 月中旬达 95.5% 饱和——不再能有效区分前沿模型。 Claude Mythos 5 95.5% vs Fable 5 95.0%，差距仅 2-3 题（run-to-run 方差级）。OpenAI 已停止报告 SWE-bench Verified 分数——前端评估团队确认模型可仅凭 Task ID 复现原始 Gold Patch，32.7% 成功补丁涉及答案泄露，76% 情况模型从训练数据记忆正确文件路径。剩余未解决任务超过 60% 是测试缺陷。

Agent/系统	SWE-bench Verified	底层模型	备注
Claude Mythos 5	95.5%	Mythos 5（ID Verified）	⚠️ 饱和：Fable 5 95.0%——差距仅 2-3 题
Claude Fable 5	95.0%	Fable 5（GA，ID Verified）	与 Mythos 5 同源权重，差异属统计噪声
Claude Opus 4.8	88.6%	Opus 4.8
Ornith-1.0	82.4%	Ornith-1.0 397B MoE	~~首个超越 Claude 的开源模型~~ ⚠️ 该标签已于 2026-10-06 撤下，理由见下
Claude Opus 4.7	~75%+	Opus 4.7
Claude Sonnet 5	~70%+（估计）	Sonnet 5（7/2 发布）	“中杯”最强 Agent

有效性判断：SWE-bench Verified 已完成其历史使命——当榜首差距缩至 2-3 题（< 1%），该基准不再能区分前沿模型。建议 Nexus 评测体系将 SWE-bench Verified 降级为”历史参考”指标，主线指标切换到 SWE-bench Pro/Live + ProgramBench + τ-bench 组合。

注：Fable 5 的 95.0% 为 vendor 自报（self-reported）口径，独立验证与 vendor 自报之间存在系统性差异——这进一步说明该基准已无法提供有效区分度。

⚠️ 2026-10-06 纠错：撤下「首个超越 Claude 的开源模型」这枚标签。

这是一枚会随时间自动失效的标签，而它已经失效了。它的成立依赖一个 2026-07 的横截面（彼时开源权重最好成绩约 82%，闭源在 95% 一带）；此后开源权重一侧持续上移，两侧差距已收窄到基准自身的测量噪声之内。更根本的问题是：这枚标签把”开源 vs 闭源”当成了一个有区分度的选型维度，而一旦两侧分数落在同一带，它就不再能指导选型。

本轮没有改写成一张新的榜单表，原因是本章 2026-09-17 刚立过一条规矩：不采信无法核实的榜单数字。本轮尝试取一手榜源未果——swebench.com 是 SPA，curl 只取到 2.9KB 导航壳，拿不到榜数据；聚合站给出的榜首分数互相能差 1 个百分点（同一模型一处 96.0%、一处 97.0%），按同一条规矩不予采信。因此在拿到 Scale 官方标准化榜或 vendor system card 之前，本节不更新具体分数。

可以现在就下的结论有两条，且都不依赖新分数：

选型维度应当换掉。 「开源 vs 闭源」在该基准上已无区分度，选型应转向成本、延迟与可部署性。判断依据不是新榜单，而是上面那张表自己的结论——榜首与第 5 名差 13 个百分点，其中 95.5% 与 95.0% 那两名只差 2-3 题。

饱和程度比原写的更严重。 榜首与靠后名次之间只剩几个百分点，而不同聚合站对同一模型的分数本身就能差 1 个百分点——测量噪声已经接近排名间距。这与上文「差距仅 2-3 题（run-to-run 方差级）」是同一结论的两个侧面：一个说模型间差得少，一个说测同样的东西都测不准。

📌 下轮复检项：取 Scale AI 官方 SWE-bench Verified 标准化榜（Bash Only 口径），把本节表格整体刷新；届时再判断是否可以把「开源权重已居榜首」写成断言。

ProgramBench：从”修补”到”构建”的评测维度

SWE-bench Verified 已被 OpenAI 确认饱和/污染（模型通过记忆补丁而非真正理解代码来获取高分）。ProgramBench（Meta FAIR + Stanford + Harvard）从另一维度评测 Agent 能力——测试从零构建程序的能力，而非修复已知 bug。

Agent/系统	SWE-bench Verified	ProgramBench	差距含义
所有前沿模型	40-68%	0%	“优秀补丁者/糟糕工程师”

ProgramBench 的所有前沿模型完成率均为 0%，验证了一个关键结论：能修好已知 bug ≠ 能从零构建功能。SWE-bench 测的是”修补能力”，ProgramBench 测的是”构建能力”——两者互补而非替代。

对于 Nexus 的评测体系设计，这意味着仅用 SWE-bench Verified 作为代码 Agent 的评测基准是不够的，需要同时考虑构建维度的评测。

SWE-bench Pro：后继者的方法论分歧

SWE-bench Pro 被设计为 Verified 的天然继承者——更长时程、更难仓库、私有子集防污染。但在 2026 年 7 月暴露了一个新问题：不同追踪器的结果相差 15 个百分点。GPT-5.6 Sol 在一个追踪器中以 64.6% 领先，Claude Fable 5 在另一个中以 80.0% 领先。这意味着即使买到了”更难”的题，评分框架的差异仍然可能淹没模型能力的差异。

截至 2026-08-13，SWE-bench Pro vendor aggregate 前列为：Claude Mythos 5 80.3%、Claude Fable 5 80.0%、Claude Opus 5 79.2%、Sakana Fugu-Ultra 73.7%、Claude Opus 4.8 69.2%、Qwen3.8 Max 67.7%、Grok 4.5 64.7%、GPT-5.6 Sol 64.6%、GLM-5.2 62.1%——前三已被 Claude Mythos/Fable/Opus 5 占据，开放权重最佳仍是 Qwen3.8 Max（67.7%）。

另一个方法论级争议点是数据质量：OpenAI 2026 年 7 月审计估计，SWE-bench Pro 731 任务公开拆分中约 30% 的任务损坏（broken），并撤回了此前「建议采纳该基准」的推荐。这与此前的「三家评分口径不一（59.1% vs 80.0% vs 47.1%）」叠加，进一步强化了「SWE-bench Pro 排名需谨慎解读」的结论。

2026-09-17 刷新——两个榜，别混池。 SWE-bench Pro 至少要区分两套互不可比的数字：

口径	榜首（2026-09-17 一手）	说明
Scale 官方公开榜（标准化脚手架）	Muse Spark 1.1：61.50 ± 3.10；gpt-5.4 (xHigh) 59.10 ± 3.56；Muse Spark 55.00 ± 3.60；claude-opus-4-6 (thinking) 51.90 ± 3.61；gemini-3.1-pro (thinking) 46.10 ± 3.60	统一 harness 下的 like-for-like 对照，官方给出 ±3.1~3.6 置信区间
Vendor aggregate（各家 system card 自报脚手架）	2026-08-13 快照为 Mythos 5 80.3% / Fable 5 80.0% / Opus 5 79.2%	见上文，与标准化榜差约 20 分

⚠️ 本轮扫描有聚合站给出「Claude Fable 5.1 81.2%（system card 2026-09-01）」，并另有一源给出 Gemini 3 Pro 84.8%。这两条本章不予采信：Scale 官方标准化榜（一手，2026-09-17）前列完全没有对应条目，且分值相差约 20 分，正是上表所说的口径差。

Pro 也出现饱和信号。 Scale 标准化榜上，第 1 名 61.50 ± 3.10 与第 3 名 55.00 ± 3.60 的置信区间大幅重叠；官方自己的观察也是「top models are clustered」「average scores alone don’t fully capture」稳定性差异。叠加 OpenAI 7 月审计的约 30% 任务损坏，本章的结论进一步强化：SWE-bench Pro 应与 Verified 一样降为「历史参考 + 趋势跟踪」，主线区分度交给 ProgramBench / τ²-bench（非饱和域）/ MultiChallenge。

对 Nexus 评测体系的影响：SWE-bench Pro 可以继续使用，但需要固定追踪器版本作为标准化基线，且不应将其作为唯一评测维度。

这一步官方已经替你做了一半：swebench.com 的 Official Leaderboards 中已设有独立的 Bash Only 榜，专门用于在不同实验室的自有脚手架之间做 like-for-like 对照。Nexus 若要发布可比分数，应优先跑 Bash Only 口径，而不是沿用各家 vendor 自报的 scaffold 分数。

配套必须澄清的一点：bash-only 是 agent 的属性，不是 benchmark 的属性。 评测 harness 只负责把你提交的 patch 跑一遍 FAIL_TO_PASS / PASS_TO_PASS；「只有一个 bash 工具」这个限制来自 mini-SWE-agent 这类 agent 自身。这条能顺带解释上文 64.6% 与 80.0% 这种量级的分歧从何而来。

建议搭配 SWE-bench-Live（动态实时评测）、τ-bench（多轮工具使用）和 MultiChallenge（指令保留+编辑）形成评测矩阵。SWE-bench-Live 目前 AMI Agent + Claude Opus 4.6 以 63.0% 领先（300 题有效集），代表了从静态数据集向动态实时评测的演进方向。

矩阵还应补两项，补的是区分度而不是覆盖面：

多语言：SWE-bench Multilingual 与 SWE-PolyBench Verified。前者在 SWE-bench 官方站面的 Benchmarks 导航中列为一等基准（本轮回站确认），后者在 AutoCompact（arXiv:2610.02163）中作为主基准之一出现。它们回答的是本节还没回答的问题：SWE-bench Verified 的分数能不能外推到非 Python 仓库。
长程：SWE-Marathon，以 matched progress 而非完成率衡量。它回答的是另一个问题：session 跑很久之后还能不能推进。与 Ch17「退出状态的完备性」互引——max_iterations 这类轮数上限在长程场景下语义不足，两处是同一个缺口。

对决策树里 swe_agent 分支的直接限定是：swe_agent 的工作目录与工具集默认面向单语言仓库，多语言任务应先在带多语言评测的基准上验证，不能拿 SWE-bench Verified 的分数直接外推。⚠️ 两个基准的具体构成与题量本轮未回源，此处只登记维度与来源。

推荐 τ 系列时不要只说分数——它的价值在 pass^k。 τ-bench 论文提出的核心指标是 pass^k：不问「这个任务完成率多少」，而问「同一个任务重复 k 次，是否每次都成功」。论文实测 gpt-4o 在 retail 域单次成功率不到 50%，而 pass^8 低于 25%——聚合分数会随 k 上升显著下降。

这对 Nexus 尤其关键：Ch21 的 RL 数据导出把整条轨迹的最终 reward 回传给每个决策点。若只用单次 pass 判定轨迹成败，会把高方差策略误判为可用策略，直接污染 RL 训练样本。建议在 rubric 中对关键决策点重复采样 k 次再定 reward，把 pass^k 作为 RL 数据准入的一道闸门。

⚠️ 另需注意 τ²-bench 的域间饱和差异：Telecom 域已接近饱和（多个模型并列 99% 量级），应选 retail / airline 等仍有区分度的域做评测。

上面那段 RL 数据准入建议与本条 ⚠️ 的置信度是分开的，别一起打折。 「关键决策点重复采样 k 次再定 reward」这条建议只依赖 pass^k 的方法论，而该方法论已回 τ-bench 论文（arXiv:2406.12045）摘要一手核实；它不依赖 Telecom 域的具体饱和分数，而那个分数至今仍是二手汇总站口径、未获核实。读者若只需要方法论，可以完全忽略本条 ⚠️ 里那个未核的数字。

降低 token 消耗的技巧：

开启 use_delta_observation（browser_gym_agent）
降低 tool_output_truncation
降低 max_iterations（配合 early stopping 策略）
用 observation_type: axtree 代替 html（browser 任务）

总结

Nexus 的 16 种 Agent 不是随意堆砌的——它们覆盖了从「教学示例」到「生产级代码修复」到「第三方 Agent 集成」的完整光谱。选 Agent 的核心原则是：

优先用专门针对你任务类型优化的 Agent（swe_agent for code，browser_gym_agent for web）
需要灵活性时用 main_agent，它的工具列表是可配置的
需要研究第三方 Agent 的推理轨迹时，用 Installed Agent 适配器
wide_agent 适合工具很多的复杂任务，但需要注意上下文管理

趋势：工具越少越好。mini-swe-agent 证明 bash-only 可达 74%+；Moatless 证明最小上下文策略的性价比最优；Agentless 证明无循环流水线在某些场景足够。Nexus 的 16 种 Agent 覆盖了从「极简」到「重量级」的完整光谱，但趋势是向极简方向演进——未来的 Agent 可能不再需要 20+ 个精心设计的工具，而是让更强的 LLM 用更少的工具完成更多。选型决策树应增加原则：先试 bash-only / 最小工具集，不够再加工具。

下一章（Ch20）用 water_emergency 这个真实 Task 走一遍 wide_agent 的完整执行轨迹。