第 1 章第一部分：快速上手

Nexus 是什么

一句话定位、核心概念五件套、与同类框架的差异、执行流全景图

最后更新：2026年10月2日 Nexus 概述架构 Agent Framework TRAE Work DeepSWE Fable 5

一句话定位

Nexus 是一个面向研究场景的 Agent 编排框架。“研究场景”这三个字决定了它的设计取向——不是做一个通用的聊天机器人框架，而是要解决 RL 训练、SFT/RFT 数据生成、大规模 benchmark 评测中的实际工程问题。

这意味着它关心的事情和 LangChain / AutoGen 不太一样：

维度	通用 Agent 框架	Nexus
核心场景	应用构建、对话	评测、训练数据生成、RL
环境隔离	可选	核心能力（Docker/Nix 沙箱）
批量执行	通常不支持	原生支持（SQLite 后端 + 并发控制）
轨迹采集	事后日志	原生 Trace 体系 + Processor 插件
训练对接	无	HyTuner RL 集成
多 Benchmark	需自行适配	28 个内置 Task

核心概念

Nexus 的设计围绕五个核心抽象展开。理解它们的关系是使用框架的前提。

Task (async function)
  └─> ExecutionContext
      ├─> Agent
      │   └─> ToolExecutor
      │       ├─> LOCAL tools (直接执行)
      │       └─> RUNTIME tools (HTTP → sandbox server)
      └─> Runtime (隔离的沙箱环境)

Task：任务编排器

Task 是最外层的编排单元。它定义了一个具体的研究任务——比如”在 SWE-bench 上评测一个 Agent”或者”用 GSM8K 测试数学推理”。

Task 负责：

准备环境（设置 Runtime、加载数据）
调度 Agent 执行
收集结果并评分

在代码层面，Task 是一个 async 函数，接收 TaskRunInput 子类，返回 TaskRunOutput 子类：

@task_registry.register('swe_task')
async def run_swe_task(task_input: SwebenchTaskInput) -> SwebenchTaskOutput:
    ctx = require_context()
    agent_output = await task_input.run_agent(...)
    score = await evaluate(...)
    return SwebenchTaskOutput(score=score)

Agent：推理循环

Agent 实现具体的推理逻辑——调用 LLM、使用工具、迭代决策。Nexus 内置了 16 种 Agent，覆盖 tool-calling、代码修复、浏览器操作、搜索研究等多种范式。

Agent 同样是一个 async 函数：

@agent_registry.register('main_agent')
async def run_main_agent(agent_input: MainAgentInput) -> MainAgentOutput:
    ctx = require_context()
    client = ctx.openai_client
    # ... 推理循环 ...

Agent 和 Task 的关系：Task 编排 Agent，Agent 不知道自己被哪个 Task 调用。 这种解耦使得同一个 Agent 可以在不同 Task 中复用。

Tool：能力单元

Tool 是 Agent 可以调用的原子能力——执行命令、编辑文件、搜索网页、操作浏览器等。

关键设计：Tool 有两种执行位置。

LOCAL：在 Host 进程内直接执行（如 web search——需要 API key，不适合放在沙箱里）
RUNTIME：通过 HTTP 发送到沙箱内的 Runtime Server 执行（如 bash 命令——必须在隔离环境中）

@tool_registry.register('google_search', meta={
    'tool_type': 'local',
    'description': 'Search the web using Google',
})
async def google_search(params: SearchInput, context: ToolContext) -> ToolResponse:
    ...

Runtime：隔离的执行环境

Runtime 是 Agent 动作实际发生的地方——一个 Docker 容器、一个远端沙箱、甚至一台 Android 设备。

Runtime 的核心抽象是 invoke()——一个统一的远程调用原语：

runtime = await ctx.get_runtime()
result = await runtime.invoke('module.path::func_name', arg1, arg2)
# 或者用便捷方法
response = await runtime.run_command(command='ls -la')

Runtime 通过 RuntimeProvider 工厂创建。Nexus 内置 6 种 Provider：

Provider	底层环境	适合场景
`local`	当前进程	本地调试
`docker`	Docker 容器	本地开发
`gongfeng`	远端沙箱	生产评测
`ags`	腾讯云 AGS	云端弹性
`android_websocket`	Android 沙箱	移动端测试
`android_cloudtest`	真机云设备	真机交互

ExecutionContext：粘合剂

ExecutionContext 是一个依赖注入容器，贯穿 Task → Agent → Tool 的整个调用链。它持有 Runtime 实例、LLM Client、Task 配置、共享状态等，通过 Python 的 ContextVar 机制实现协程安全的传播。

async with ExecutionContext(
    runtime_provider=provider,
    openai_clients={'main': client},
    task_name='swe_bench',
) as ctx:
    await task_fn(task_input)
# 退出时自动释放所有 Runtime

在 Task/Agent/Tool 内部，通过 require_context() 获取当前上下文。

Runner：入口

Runner 是把所有东西串起来的入口。它读取 YAML 配置文件，创建 ExecutionContext、OpenAI Client、RuntimeProvider，然后执行 Task。

nexus run-single config.yaml

这就是 Nexus 的全貌。接下来第 2 章，我们实际跑一个任务。

与同类框架的关系

三层生态对比

2026 年的 Agent 工具生态已从”几个实验项目”发展为 84+ 工具的成熟生态，分化为三层。Nexus 在其中的定位需要在这个分层中理解。

层级	代表项目	核心关注	MCP 原生
商业层	Copilot / Cursor / Trae SOLO	面向终端用户的 AI 编程产品	✅
SDK 层	OpenAI Agent SDK (19k★) / Claude Agent SDK / Google Agent SDK (18k★)	用 SDK 组装定制 Agent	✅
框架层	LangGraph (25k★) / CrewAI / AutoGen / PydanticAI / Smolagents	编排、状态流、多 Agent 协作	部分
研究层	Agent Canvas（原 OpenHands）/ SWE-Agent (14k★, 已被 mini-swe-agent 取代)	Coding Agent 研究与评测	部分
基础设施层	Nexus / Docker Sandboxes / Alibaba OpenSandbox	沙箱隔离 + 评测/训练 + 资源调度	部分

商业层解决”用户直接用”，SDK 层解决”怎么构建 Agent”，框架层解决”怎么编排 Agent”，研究层解决”怎么研究和评测 Agent”，基础设施层解决”Agent 在哪里安全运行”。Nexus 跨越研究层与基础设施层，独特定位是评测 + 训练一体化——从评测产出训练数据，从训练结果回到评测，形成闭环。

逐项对比

vs TRAE Work： TRAE Work 是字节跳动在 2026-06-09 将 TRAE SOLO 品牌升级后的产品（“The Real AI Enabler”），从单一编程 Agent 扩展为 Work / Code 双模式——Work 模式面向非开发角色（文档/数据/自动化），Code 模式保留 SOLO Coder（复杂编程）+ SOLO Builder（端到端应用）能力。三端协同（桌面 macOS/Windows + 网页 solo.trae.ai + 移动远程下发）+ Global Memory 跨端记忆 + 2026-06 v3.5.66 Hooks + v0.1.21 Design Mode（设计稿/自然语言批量编辑/设计系统管理/设计稿转代码）使 TRAE 跨越”编程工具”边界。代表商业层的”全场景使能”路线——用户无需理解代码即可完成从写文档到做设计到生成应用的完整工作流。Nexus 的”沙箱化 Agent 运行时”理念则面向研究与评测场景，关注可复现性和轨迹采集，而非端用户体验。两者服务于不同受众。

vs Agent Canvas（原 OpenHands）： OpenHands 已于 2026-08-05~07 正式更名 Agent Canvas，一周内连发 v1.10/1.11/1.12，新增三项关键能力：persistent memory（持久记忆）、live agent activity（实时 Agent 活动面板）、per-run cost（单次运行成本可视化）。Agent Canvas 已从 Coding Agent 演进为全功能 Agent 平台（Docker sandbox + browser + multi-agent delegation, SWE-bench Verified 67.2% with Sonnet 4.6，2026-04 公布）。

2026-09 更新：截至 2026-10-02 核，OpenHands 仓库的最新发布为 v1.24.0（2026-09-25），v1.17.0 于 2026-09-09 发布，v1.16.0 于 2026-08-27 发布——更名后（v1.12）至今已迭代 12 个版本。产品定位也从”Agent 平台”收敛为”自托管的开发者控制中心（self-hosted developer control center）“：核心卖点是通过 ACP 接入你已有的 harness（官方产品页列出 Claude Code / Codex / Gemini CLI / OpenHands Agent 四个），并明确写着”保留你原有的订阅与模型”（Keep your existing subscription and model）。另一处重要变化是 Docker 从必需变为可选（“No Docker required”）；官方另警告，无沙箱模式下 agent 拥有机器的完全控制权。

⚠️ star 数不要写死：本章此前写”GitHub 83k stars”，但 2026-09 三个来源分别给出 83k / 61.4k / 206k，差异过大、口径不明。本章改为不做定量陈述，读者如需该指标请以官方仓库当期数字为准。

值得记一笔的是：Agent Canvas 打出的”保留你原有的订阅与模型”与 Nexus 的”沙箱内安装 + LLM Proxy”路线，在用户主权上其实是一致的——两者都不强迫用户换模型或换账号。真正的差异只在可观测性：Nexus 要拿到 token 计数、轨迹与评分以支撑复现，Agent Canvas 只要能驱动起来。这个差异不是优劣，而是评测框架与生产力工具的目标函数不同。OpenHands 走生产路径——面向开发者日常编码；Nexus 走评测/训练路径——面向研究场景的批量评测和数据生成。 OpenHands v1.6.0 (2026-03-30) 引入 Planning Mode beta——Agent 写实现计划并暂停等待批准；v1.7.0 新增 SANDBOX_KVM_ENABLED 环境变量；2026-05-06 推出 Agent Control Plane (Enterprise)——工作流级最小权限控制、按工作流计费成本归因、完整行为日志；Software Agent SDK (Python, Apache 2.0) 提供 TaskToolSet 子代理框架。OpenHands 已在 H1 进入”研究→生产”完整路径。OpenHands 是 Nexus 内置的一种 Agent 选项（通过 codeact Agent 提供类似能力）。Nexus 用 Nix volume 挂载实现零构建，OpenHands 需要为每个基础镜像构建运行时镜像。

vs SWE-Agent：SWE-Agent 已分化为研究基准实现（minimal ACI, 14k★），其 mini-SWE-agent 100-LOC 变体常用于苹果对苹果的模型比较。 2026-06-12 之后 mini-swe-agent 进一步升级为 Artificial Analysis Coding Agent Index 的官方统一脚手架——所有 DeepSWE 排行榜上的模型都用 mini-swe-agent 跑，以确保跨模型对比的公平性。这意味着 mini-SWE-agent 已不仅是”社区标准”而是”行业指数标准”——所有新模型对比研究应直接用 mini-swe-agent 适配。Nexus 内置了 swe_agent Agent 和 swe_task Task，可以看作是”跑 SWE-Agent 生态的平台”。

vs LangChain / LangGraph：LangChain 是应用构建框架（SDK 层 + 框架层），Nexus 是研究评测框架（研究层 + 基础设施层）。LangChain 关心 chain 编排和 retrieval；Nexus 关心沙箱隔离、批量执行、轨迹采集。

vs verl (ByteDance)：verl 专注 RL 训练的异步编排；Nexus 更全面，覆盖评测 + 数据生成 + RL 训练对接。两者在 Agentic RL 场景有互补性。

vs Harbor： Harbor 是 Terminal-Bench 团队（Laude Institute）开源的评测 harness（github.com/harbor-framework/harbor，Apache-2.0，v0.24.0 / 2026-10-05，5955★ / 1961 forks，1445 个 py 文件）。它与 Nexus 不是”同类竞品”，而是同一条赛道上的不同层：Harbor 解决”把已有的 Agent 丢进已有的基准里跑出可比分数”，Nexus 解决”把 Agent / Tool / Task / Runtime 拆开重组，并顺带产出训练数据”。两者在评测执行 + rollout 产出上正面重叠，在其余处并不对称：

维度	Nexus	Harbor
Task 定义	命令式：7 文件 Python 模块（最小骨架 2 文件）	声明式：`task.toml` 一个文件写定难度 / 标签 / 双超时 / 资源配额
数据集规模	28 个内置 Task	`registry.json` 80 个数据集、数万 task（terminal-bench@2.0 89 个、code-contests 9644、kumo 5300），`adapters/` 另有 70+ 基准适配器
环境供给	6 个 Provider（其中 `gongfeng` / `ags` 为腾讯内部设施，外部读者不可复现）	40+ Environment（docker / daytona / modal / e2b / gke / ec2 / openshift / runloop / prime / skypilot …）
Agent 接入	4 个 Installed Agent（沙箱内装 CLI + LLM Proxy 代理）	48+ installed agent + `oracle`，且已实现 ACP（详见下文”Nexus 定位的行业参照”）
Nexus 独有	Android 真机（`android_websocket` / `android_cloudtest`）、16 个自研 Agent、上下文 Compaction、Tool 的 LOCAL/RUNTIME 双执行位	—

一句话概括：Harbor 是”基准 × Agent × 模型 × 环境”的笛卡尔积执行器，Nexus 是”Task 编排 Agent”的编程框架——前者把组合爆炸交给 CLI 参数，后者把组合逻辑交给写代码的人。因此”Nexus 只有 28 个 Task”不是能力不足，而是两种扩展方式的代价差异：Harbor 靠生态铺量，Nexus 靠编程表达力。真要比覆盖面对 Harbor 是不公平的，反过来拿”能不能编排任意 Agent 逻辑”比 Nexus 也对 Harbor 不公平。

⚠️ 上表 Harbor 侧全部数字核于 2026-10-10，且 Harbor 处于 v0.x 高频迭代（近两个月 v0.20→v0.24 共 5 个版本）。引用前请复核；尤其不要用本章数字去论证”Harbor 比 Nexus 强”——两者目标函数不同（见上一段）。

Agent 架构分类法共识

2026 年行业已就 Agent 架构分类形成四分法共识：

架构	核心思路	代表实现
Code-as-Action	Agent 直接生成/执行代码，代码即动作	OpenHands CodeAct, SWE-Agent
ACI (Agent-Computer Interface)	设计专用交互界面，Agent 通过 ACI 操作环境	SWE-Agent (original), Nexus
Plan-and-Execute	先规划后执行，规划器与执行器分离	LangGraph PlanExecute, Nexus planner Agent
Tool-Calling	LLM 通过结构化工具调用与外部交互	Claude Agent SDK, OpenAI Agent SDK

行业共识正在形成：架构选择比模型选择更重要。同样的模型在 Code-as-Action 架构下可能比 Tool-Calling 架构表现差 20%+，反之亦然。Nexus 的价值在于提供多种架构的统一评测框架，使架构对比成为可能。

这句定性判断在 2026 年已经有了实测支撑。

观测	分数	说明
同一 GPT-5.5 在 Terminal-Bench 2.0 上配三个不同 harness	84.7% / 83.1% / 82.2%	NexAU-AHE / Capy / Codex CLI
同一 Claude Opus 4.6 在两个 harness 下	76.4% / 75.3%	同一模型、两套脚手架
同一 Claude Opus 4.5 配三套 agent 系统（SWE-bench Pro）	50.2%–55.4%	Digital Applied 2026-06 分析，5.2 分全部来自脚手架

Scale AI 自己把 10–20 分的波动归因于 harness 选择。行业由此形成的买方结论是直白的：「在 agentic 基准上，你买的从来不是模型分数，而是模型 + 脚手架的分数。」

⚠️ 上表数字来自 2026-09 的多家二手榜单聚合与行业分析转述，非论文一手数据，且各自快照日期不同（Terminal-Bench 2.0 系退役版本）。引用时请按”截至 YYYY-MM-DD、来源 X”格式复核。

这段数据恰好解释了 Nexus 为什么把 Agent 与 Runtime Provider 解耦：当 harness 本身就值 10–20 分时，只有把 harness 固定成一个可替换、可审计的模块，“换模型再测一次”才是在比较模型——否则你测到的一直是脚手架。

基准演化与框架定位

⚠️ 基准饱和风险：SWE-bench Verified 已被 OpenAI Frontier Evals 团队 (2026.03) 宣布”实际上已饱和且高度被污染”，近 60% 问题存在测试缺陷，前沿模型分数超 90%。行业正转向 SWE-bench Pro 和 Terminal-Bench 2.0。

截至 2026 年 6 月，关键基准排名如下。

基准	最佳模型	分数	口径	快照日期	备注
SWE-bench Verified	Claude Mythos Preview	93.9%	厂商自报	2026-06	该基准已不再具有区分度——饱和+污染，仅供历史参照
SWE-bench Verified	Claude Opus 5	97%	第三方聚合站（自标 independent）	2026-10-01	头部 7 名挤在 3.6pp 内——见下方「补充限定」
SWE-bench Pro ⚠️	Claude Fable 5	80.3%	⚠️ 厂商自报（vendor-scaffold）	2026-06	2026-07-08 OpenAI 审计发现 ~30% 任务缺陷，已撤回推荐
SWE-bench Pro ⚠️	Claude Opus 4.8	69.2%	⚠️ 厂商自报（vendor-scaffold）	2026-06	⚠️ 本条及以下数据仅供历史参照——基准已被推荐者废弃
SWE-bench Pro ⚠️	GLM-5.2	62.1%	厂商自报	2026-06	开源/国产模型中的最佳表现（753B/40B MoE，MIT）
SWE-bench Pro ⚠️	MiniMax M3	59.0%	厂商自报	2026-06	开源/国产模型中的最佳表现（open-weight，$1.20）
SWE-bench Pro（Scale 标准化公开集）	Muse Spark 1.1	61.50% ± 3.10	✅ Scale SEAL 标准化公开集（731 题 / 41 仓库）	2026-09	同榜：gpt-5.4 (xHigh) 59.10 ± 3.56、Muse Spark 55.00 ± 3.60
SWE-bench Pro（Scale 私有商业集）	Muse Spark 1.1	51.50% ± 5.50	✅ Scale SEAL 标准化私有集	2026-09	同榜：claude-opus-4-6 (thinking) 47.10 ± 6.07、Muse Spark 44.70 ± 6.05
Vibe Code Bench	—	—	—	—	评测”氛围编程”——用户用自然语言描述需求，AI 端到端生成完整应用；与 SWE-bench 的 bug 修复场景形成互补
Terminal-Bench 2.0 ⚠️	GPT-5.5	82.7%	厂商发布时数字	2026 上半年	⚠️ 2.0 已退役，官方站现为 4.0；v2.0 三大升级：更难任务 / 严格评分 / 对抗性设置
Terminal-Bench 2.0 ⚠️	Opus 4.7	69.4%	第三方榜单快照	2026 上半年	⚠️ 同上，仅可与同版本数字比较
WebArena Verified	DeepSeek V3.2	74.3%	厂商自报	2026-06	428 可行任务子集，去除不可能完成的任务

⚠️ 口径不可混用（2026-09-13 核对）

上表中 80.3%（Fable 5）与 69.2%（Opus 4.8）是厂商自配脚手架跑出的数字；而同期 Scale AI 的 SWE-bench Pro 标准化公开集（731 题 / 41 仓库）榜首为 Muse Spark 1.1 61.50% ± 3.10，私有商业集榜首为 Muse Spark 1.1 51.50% ± 5.50（来源：Scale 官方榜单 scale.com/leaderboard/swe_bench_pro_public，2026-09-13 抓取）。

两组数字相差 19–29 分。一条实用的经验法则是：比 Scale 标准化榜高出 10–30 分的 SWE-bench Pro 分数，基本都是 vendor-scaffold 数。 混在一张表里会让读者系统性高估模型能力约 20 分——而本章正是用这张表论证基准演化与框架定位的，口径混乱会直接传染到 Nexus 的定位论述。

该法则已被后续数据独立验证（2026-10-02 核）：2026-10-01 的聚合站口径下 SWE-bench Pro 榜首为 Gemini 3 Pro 84.8%，同期 Scale SEAL 标准化公开集榜首仍为 Muse Spark 1.1 61.50%，差 23.3 个百分点，落在 10–30 分区间中部。

同业比较时只能同口径对同口径：厂商自报 vs 标准化公开集 vs 私有商业集，是三个不可互换的量。

📌 本章基准数字的三种口径（建议推广到本书所有含基准数字的章节）：① 厂商自报——厂商自配脚手架，数字最高，常见于发布会；② 标准化公开集——如 Scale SEAL，统一 harness 与评分，可横向比较；③ 第三方聚合站快照——依赖抓取时点，须标日期。三者不可互换，跨口径比较是行业评测报道最常见的错误。

2026-06 重大事件：

Claude Fable 5 80.3% 史上最高 SWE-bench Pro（2026-06-09 发布， $10/$ 50 per 1M tokens，领先 Opus 4.8 约 11 分）。但 2026-06-12 因美国出口管制指令被暂停所有用户访问（无法按国籍实时门控），预计 2026-07-01 恢复美国用户——意味着 SWE-bench Pro 新榜首立刻不可访问。
Artificial Analysis 2026-06-12 移除 SWE-Bench Pro 从其 Coding Agent Index 和 Intelligence Index，替换为 DeepSWE。理由是 SWE-Bench Pro 容器含完整 git 历史（Opus 4.7 18% / Opus 4.6 25% 通过项通过 git log + git show 读取 gold commit）+ 验证器 8% 假阳性 / 24% 假阴性。替换后复合分变化：Codex+GPT-5.5 65→76（+11 分跃升），Opus 4.8 (max) 73，Fable 5 (max) 77（新榜首）。这一变化的行业意义：业界开始承认”前 SWE-bench 时代”的评测范式需要全面重写——基准不仅是”测试工具”，它是厂商做模型选型决策的依据。
OpenHands 同期达到 67.2% SWE-bench Verified with Sonnet 4.6——v1.6.0 Planning Mode beta（2026-03-30）+ v1.7.0 SANDBOX_KVM_ENABLED + 2026-05-06 Agent Control Plane (Enterprise) 形成”研究→生产”完整路径；mini-swe-agent 100-LOC 变体成为 Artificial Analysis Coding Agent Index 的统一脚手架。

2026-07 重大事件：OpenAI 双重撤退

OpenAI 正式撤回 SWE-bench Pro 推荐（2026-07-08）。OpenAI 对 Pro 的 731 道公开题进行全面审计——自动流水线标记 200 道异常（27.4%），5 名资深软件工程师人工复核标记 249 道存在根本缺陷（34.1%），综合结论约 30% 题目是废的。四类缺陷：过于严格的测试（功能正确但实现路径不符被拒）、题目描述不完整（隐藏测试需求无法从上下文推断）、测试覆盖不足（不完整修复也能通过）、误导性描述（指向错误代码位置）。典型案例：题目要求”单倍行距”，隐藏的测试用例实际检查”双倍行距”——按题目写的全挂，猜对潜规则的反而能过。

这是 SWE-bench 系列的”双重撤退”：2026-02 OpenAI 废弃 Verified（59.4% 高难度题存在污染/测试缺陷）→ 推荐 Pro → 2026-07 OpenAI 废弃 Pro（~30% 任务缺陷）→ 撤回推荐。同一组织在 5 个月内连续亲手废弃两个自己推荐的编码基准——评测信任危机从”第三方质疑”升级为”推荐者自我否定”。历史意义：这揭示了”从公开仓库 Issue/PR 构造评测任务”这一方法论的根本局限——不仅污染不可避免，任务质量本身也无法保证。

Databricks 同日发布内部代码库基准（2026-07-09）。基于数百万行生产代码库（Python/Go/TypeScript/Scala/Rust/Java 等 10+ 语言），从真实 PR 构造任务，无污染、密封 git 历史防作弊。关键发现：GLM 5.2 与 Opus 4.8 任务质量统计持平（成本 $1.28 vs$ 1.94/task）、Harness 效率差异超 2×、Token 价格 ≠ 任务成本。这代表产业界的新方向——当公共基准接连失效，“自建基准”从加分项变为必需品。Nexus 的 Task 模块架构天然支持企业快速自建此类基准。

提示：§Ch03 详细分析 DeepSWE 排行榜 v1.1v1（2026-06-20）数据、5.5× 代码行数压力、AA 替换的组织级意义。

Vibe Code Bench 代表了评测范式的新方向：不再只看”修复已有代码”，而是评估”从零生成完整应用”的能力。这与 Nexus 支持自定义 Task 的设计天然契合——接入新基准只需编写一个 Task 模块。

Terminal-Bench 系列凭借真实 shell 任务与对抗性设置，曾是 2026 年最可靠的 Agent 基准之一。但该系列迭代极快：2.0 已被 4.0 取代——tbench.ai 官方站现服务 Terminal-Bench 4.0（2026-09-13 核），Artificial Analysis 的 Intelligence Index 也已在其 v4.3 篮子中改用 v4.0；中间还出现过 2.1 与 3.0，AA 另采用 Terminal-Bench Hard 变体。本章出现的 2.0 数字都是退役仪器的历史快照，只能与同版本数字比较，不可与 4.0 数字并列。

WebArena Verified 通过去除不可能任务提升了评测效度，解决了原始 WebArena 中”模型无法完成的任务拖低分数但无关能力”的问题。

⚠️ SWE-bench Verified 的补充限定：该榜已发布的分数绝大多数为厂商自报、缺少独立验证——这比”饱和 + 污染”更能解释为什么其数字会随时间单调上飘。另需注意本书内部三处 SWE-bench Verified 数字并不一致（本章 93.9% / CCI Ch18 88.6% / 大模型全书 Ch11 96.4%），三者分处不同章节且快照日期不同，读者应各自按”截至 YYYY-MM-DD，来源 X”理解，不要当作同一个榜的同期对比。

⚠️ 另有 2026-09 的榜单聚合站快照把该榜首名记为 Claude Fable 5 95.0%（高于本章所记 93.9%）。该数字来自二手聚合站、非官方一手，且与该榜”几乎全部为厂商自报”的性质一致——数字单调上飘本身即是缺少独立验证的症状，不宜当作能力跃升的证据。

⚠️ 2026-10-01 快照：分数继续上飘，但头部离散度在收窄——这是”无区分度”的量化证据，不是能力跃升的证据。该日刷新时榜首为 Claude Opus 5 97%（聚合站标注 independent），其后 GPT-5.6 Sol 96.2%、Grok 4.6 95.6%、GLM-5.3 95.4%、GPT-5.6 Terra 95.4%、Claude Fable 5 95.0%、Kimi K3 93.4%——头部 7 名挤在 3.6 个百分点内。把三个快照按时间排开：93.9%（2026-06）→ 95.0%（2026-09）→ 97%（2026-10-01）。分数单调上飘与头部离散度收窄是同一批数据的两个侧面，正是”该基准已不再具有区分度”这一判断的量化形式。 ⚠️ 本条来源为第三方聚合站（tensorfeed.ai，页头自标 “Last refreshed 2026-10-01”，47 models），其 “independent” 标注是该站自标、非官方榜口径；本书将其单列为独立一行，不与 2026-06 的 93.9% 混用，也与上行「补充限定」中的跨章一致性提示并行存在。

2026-08/09 重大事件：新玩家与新基准

Muse Spark 现象：SWE-bench Pro 公开榜的榜首由一个未在榜单页面署名实验室的系统占据（Arena 与 llm-stats 把它归为 Meta）。榜首条目本身是 Muse Spark 1.1（61.50 ± 3.10，Scale 官方榜标签）；该系列另有 1.2（2026-08 见于 SWE-bench Verified 榜）与 1.3（2026-09-02 发布，2026-09-29 已在 DeepSWE 1.1 榜居首 75.4%）两个后续版本——“榜首条目”与”最新版本”是两件事，此前混写成了一句。这件事本身比分数更值得记：一个前沿编码榜单的榜首可以是一个出处不在页面上的系统——2026 年”分数”所附的元数据有多薄，这就是注脚。对 Nexus 这类评测框架的启示是：分数若不带可复现的 harness、口径与快照日期，它对读者的信息量接近于零。⚠️ 实验室归属是第三方推断，不是既定事实，请勿写成”Meta 的 Muse Spark”；1.2 / 1.3 的归属同样未经证实。
- 该系列从 1.1 迭代到 1.3 的过程中，“它属于哪家实验室”这一元数据始终未在榜单页面上署名——本章 2026-09 提出的”分数所附元数据有多薄”的问题，在版本迭代之后依然原封不动地存在。
GPT-5.6 Sol：Terminal-Bench 2.0 榜的 2026-09 快照首名为 91.9%（48 个模型已评）。⚠️ 这与本章上文所引 84.7%（o-mega 记录的 2.0 最终前五榜首，NexAU-AHE + GPT-5.5）不是同一天的榜单，两者不可在同一句里并列比较——正是本章要求标注快照日期的原因。
Epoch AI 的 MirrorCode（2026-08-03 公告）：Claude Fable 5 得 64%，而 GPT-5.6 Sol 仅 20%。同一对模型在 Terminal-Bench 与 MirrorCode 上的相对位次截然不同，再次印证”没有单一基准能代表 Agent 编码能力”。

Nexus 的价值不仅是”跑旧 benchmark”，更在于快速接入新 benchmark——元数据驱动的零导入发现机制（第 7 章详解）使接入新 benchmark 的成本极低。当基准演化时，写一个新 Task 模块就够了。

Nexus 定位的行业参照

2026 年 5-6 月，沙箱化 Agent 运行时领域出现了多个重要参照：

Docker Sandboxes microVM：Docker Desktop 4.58+ 引入 microVM 隔离沙箱，支持 Claude Code / Codex / Copilot / Gemini 等主流编程 Agent。Docker 的路线是从容器运行时向上扩展到 Agent 隔离；Nexus 则从评测框架向下延伸到沙箱管理。两者在”隔离的执行环境”上理念一致，但 Nexus 的 Nix-based 方案在零构建启动速度上有优势。

Alibaba OpenSandbox：Protocol-First K8s 池化调度方案，宣称 1000 实例 0.92 秒交付。OpenSandbox 解决的是”大规模 Agent 并发调度”问题，与 Nexus 的 gongfeng RuntimeProvider 定位相近，但走的是 K8s 原生路线而非应用层调度。对于需要千级并发的生产评测场景，OpenSandbox 的调度能力值得借鉴。

sandbox-agent / AgentBox SDK：开源社区实现了与 Nexus 类似的”沙箱 + LLM Proxy”架构。sandbox-agent 提供轻量级沙箱管理和 LLM 代理层；AgentBox SDK 则封装了完整的 Agent 开发工具链。这两个项目验证了 Nexus 架构方向的可行性，但都缺少评测/训练闭环能力。

ACP 协议（Agent Client Protocol）： Agent Canvas 通过 ACP（Agent Client Protocol） 协议驱动 Claude Code / Codex / Gemini CLI 等第三方 Agent。这代表了与 Nexus 不同的第三方 Agent 集成哲学——开放协议（ACP）vs 沙箱内安装（Installed Agent）：ACP 走”定义统一通信协议，让各 Agent 实现同一接口”的路线，Nexus 走”在沙箱内原样安装 Agent CLI + LLM Proxy 代理请求”的路线。前者降低接入成本但依赖协议生态共识，后者保持对 Agent 完整行为（token 计数、轨迹采集、评分）的可观测性，更契合研究场景的复现需求。两者并非互斥——Nexus 的 Installed Agent 适配器未来也可能通过 ACP 对接更多第三方 Agent。截至 2026-09，Agent Canvas 官方产品页已把 ACP 列为核心卖点并列出 4 个已支持的 harness（Claude Code / Codex / Gemini CLI / OpenHands Agent）——这说明本章 2026-08 提出的”开放协议 vs 沙箱内安装”之分，在一个月内已从业界动向变成产品现实：协议路线确实降低了接入成本，代价是可观测性。

2026-10 补：第二个样本否掉了”二选一”的 framing。 Harbor 同样实现了 ACP——src/harbor/agents/protocols/acp.py + acp_registry.py + acp_runner.py。但真正有信息量的是它两条路都走了：除了 agents/protocols/，它还有 48 个 agents/installed/ 适配器（沙箱内安装 CLI，与 Nexus 的 Installed Agent 是同一思路）。也就是说，协议路线与安装路线不是世代更替，而是可以按 Agent 逐个选择的两种接入成本：对实现了 ACP 的 Agent 走协议（便宜、接得快），对没实现的走安装（贵，但拿到完整的 token 计数与轨迹）。

这条对 Nexus 的含义是可操作的：若要扩大 Installed Agent 覆盖面，先补一条 ACP 通道比再写 N 个安装适配器更划算；代价是 ACP 通道下拿不到完整可观测性，而这正是 Harbor 把两条路都留着的原因——它既想要生态覆盖，又想要研究级复现。“未来也可能通过 ACP 对接”这句判断由此可以收紧：不是要不要做，而是哪一类 Agent 走哪条路。

MCP Atlas 与 Remote Labor Index（Scale Labs, 2026）：MCP Atlas 是首个对 MCP 工具使用给出标准化口径与置信区间的基准——榜首 Muse Spark 1.1 88.10 ± 1.95、claude-opus-5 (xhigh) 85.80 ± 2.10、gemini-3.5-flash (high) 83.60 ± 2.30。同站的 Remote Labor Index（RLI） 测”AI Agent 完成有经济价值的真实远程工作”，榜首 Fable-5 仅 15.80（Opus 4.8 8.33、Codex GPT-5.5 6.25）。

两者并列时最值得记的不是各自的榜首，而是这两个”第一名”差了 72 分：不同”Agent 能力”基准的绝对分数完全不在一个量级上。跨基准比较分数是没有意义的，跨基准比较”排名变化”才有意义。 这为第 3 章 Task 表里 mcp_benchmark 一行补上了此前完全没有的外部参照。

Nexus 的独特性：在这些参照中，Nexus 的独特定位不在于功能独特性——Docker 做沙箱、OpenSandbox 做调度、sandbox-agent 做代理——而在于源码级透明性：从 Task 定义到 Agent 执行到 Runtime 管理，所有环节都可审计、可复现、可定制。这种透明性对于研究场景至关重要——你需要知道分数是怎么来的，而不仅仅是一个数字。