2026 年 7 月，六大前沿模型在 SWE-bench Verified 上的分数差距不超过 0.8 个百分点。Claude Opus 4.5 以 80.9% 领先，GPT-5.4 约 80.0% 垫底——在同一张榜单上，这 1.3 分的极差基本是统计噪声。
但如果把同一个 Claude Opus 4.5 放进不同的 agent 框架里跑 SWE-bench Pro，差距就拉开了：SEAL 标准化脚手架 45.9%，Cursor 50.2%，Auggie 51.8%，Claude Code 55.4%。同一个模型，9.5 个百分点的差距。
更极端的数据来自 Nate B. Jones 的文档：同一个 LLM，仅靠 harness 变化就可以在 coding benchmark 上从 42% 飙到 78%。36 个百分点的跃迁——模型没变，模型之外的什么东西变了。
这引出了一个 uncomfortable 的问题：当我们说"这个 agent 达到了 80% 的 SWE-bench 分数"时，这 80% 到底有多少来自模型本身，有多少来自工具设计，有多少来自系统提示词，有多少来自错误恢复策略？当前的基准测试不仅没有回答这个问题，甚至没有尝试去问。
分数的幻觉：Benchmark 的归因黑洞
SWE-bench 的设计假设是：给定一个模型和一个标准化的 agent harness，测出来的分数反映了模型的能力。但现实是，不存在"标准化"的 harness。
每一个跑在 SWE-bench 上的 agent——无论是 Claude Code、Codex CLI、OpenHands 还是 Auggie——都在用一个高度定制的脚手架。它们有不同的工具 schema、不同的上下文管理策略、不同的错误恢复机制、不同的系统提示词。SWE-bench 的分数是所有这些因素与模型能力混合后的产物，但榜单只显示了一个数字。
用 Particula 的分析来说："SWE-bench Pro 上，脚手架贡献了 22+ 分的差异，而前沿模型之间的差异只有大约 1 分。模型成了商品，harness 才是差异化来源。"
这不仅仅是 SWE-bench 的问题。GAIA benchmark 上，同一个 Claude Opus 4 在一个 agent 框架内得分 64.9%，在另一个框架内得分 57.6%——7 分的差距完全来自编排层。CLEAR 框架的研究更系统地揭示：企业 agent 系统在实验室基准分数和实际部署性能之间存在 37% 的差距，且成本变化高达 50 倍。
而这些差异的来源——工具设计、harness 架构、prompt 策略、记忆系统——在当前基准测试中完全不可见。
拆解 Agent：六大维度与它们的交互效应
要理解 Agent 能力的真正构成，必须将"模型 + 脚手架"这个黑箱拆开。以下是六个核心维度，按对 benchmark 分数的影响力排列，并说明它们之间的交互效应。
维度一：工具设计——最高杠杆，最深隐蔽
在所有非模型因素中，工具设计带来的分数波动最大。几个案例证明了这个维度的影响力：
Grok Code Fast：从 6.7% 到 68.3%。团队只做了一件事：修改编辑工具的输出格式。没有动模型、没有改 prompt、没有调训练数据。仅仅改变了工具如何把编辑结果传达给 LLM，带来了 10 倍的性能提升。
SWE-agent 的 ACI 设计。SWE-agent 的核心创新不是模型，不是 prompt，而是一个"Agent-Computer Interface"：一个 100 行的窗口化文件查看器、行级编辑工具和语法检查自动保存，将 SWE-bench 分数相较于裸 bash 工具大致翻倍。正如其文档所述："agent 没有变聪明，它只是住进了更好的房子。"
WarpGrep 搜索子 agent。在所有测试模型上增加 +2.1 到 +3.7 个 SWE-bench Pro 百分点，同时将完成时间缩短 28%、成本降低 15.6%。这个 YC 孵化的工具做了一件事：用 8 路并行 grep 替代了 agent 的串行文件搜索。
工具设计的核心原则不是"更多工具"，而是工具输出的格式、粒度和可操作性。一个好的工具让模型少犯错；一个差的工具让好模型看起来像个傻瓜。
维度二：Harness 架构——任务的分解与编排方式
Harness 回答了 agent 系统最基本的结构问题：是单 agent 循环还是多 agent 分工？是先规划后执行还是边想边做？如何跨会话传递状态？
Anthropic Labs 的实验提供了最好的对比。同样的 prompt（"创建一个 2D 复古游戏制作器"），单 agent 裸跑 20 分钟产出 $9 的代码——核心玩法功能根本跑不通，实体在屏幕上出现但不响应任何输入。而 Planner + Generator + Evaluator 三 agent 架构跑 6 小时、$200——16 个 feature、10 个 sprint、AI 辅助精灵生成器和关卡设计器，游戏可以实际游玩。
20 倍的成本，质的差异。
当 Opus 4.6 发布后，团队重新审视了 harness 的复杂性——"每一个 harness 组件都编码了一个关于模型不能独立完成什么的假设，而这些假设值得压力测试"——他们移除了 sprint 分解结构，因为更强的模型不再需要这种粒度的任务拆分。但 Planner 和 Evaluator 仍然保留了，因为它们分别解决"模型会欠范围"和"模型会自我欺骗"这两个独立于模型强度的问题。
这说明了一个深刻的原则：harness 不是越多越好，而是每一层都必须对应一个模型确实存在的能力缺口。当模型进化时，harness 应该收缩；当任务复杂度超出模型能力边界时，harness 应该扩展。
维度三：上下文工程——不只是 prompt，是状态管理
Meta Context Engineering（Ye et al., 2026，已被 ICML 2026 接收）将上下文组装定义为一个双层优化问题：meta-agent 驱动 skill 演化，base-agent 管理上下文优化。在 DeepSeek-V3.1 基础上，MCE 达到 89.1% 的平均相对改进，比之前的 SOTA 高出 18.4%。
这个结果说明了两件事：第一，上下文组装本身就可以被优化和自动化；第二，这种优化带来的收益可以与模型升级媲美甚至超越。
但上下文工程的范畴远不止 prompt template。LangChain 2026 年的立场是：上下文工程包括状态管理、摘要节点插入、工具输出压缩、记忆注入时机等一系列策略。Anthropic 的实践则揭示了"上下文焦虑"问题——Sonnet 4.5 会在接近上下文窗口限制时提前收尾，此时仅靠上下文压缩不够，需要上下文重置（清空窗口 + 结构化 handoff artifact）作为补充策略。
维度四：记忆机制——单次工具调用器 vs 长期协作者的门槛
Mem0 2026 年的报告给出了一个清晰的数据：结构化记忆相比全上下文提示，p95 延迟降低 91%，token 消耗减少 90%。SWE Context Bench 的结论更直接：Supermemory 达到 55.95% 的 FAIL_TO_PASS 测试率和 30.30% 的解决率，在所有评估的记忆系统中表现最优。
但记忆的真正瓶颈不是存储，而是检索。Memory for Autonomous LLM Agents（2026 综述）指出："RAG-based agent 在所有场景下都优于纯长上下文 baseline，但主要瓶颈已不再是存储——而是检索质量。"混合重排序可以将检索失败率从 35.3% 降到 11.4%。
这里有一个被低估的结论：长上下文窗口不能替代记忆。 200K token 的上下文窗口扩大了工作记忆，但不提供跨会话持久化存储。而且"存储更多"和"检索更准"是两个完全不同的工程问题。
维度五：错误恢复与自我纠错——高分数 agent 的秘密
Particula 的分析指出，高分数 agent 和低分数 agent 之间的核心差异"不是犯更少的错误，而是能从错误中恢复"。SWE-bench 上 42% 到 78% 的差距，很大程度上来自错误恢复逻辑。
Anthropic 的 harness 实验则暴露了更深层的问题：自我评估是 LLM 的固有弱点。"当被要求评估自己产出的工作时，agent 倾向于自信地赞美自己的工作——即使质量明显平庸。" 解决方案是将生成和评估分离为独立的 agent，并为评估 agent 专门调校使其保持怀疑态度。"调校一个独立的评估者使其保持批判性，比让生成者批判自己的工作要容易得多。"
维度六：系统提示词——边界定义者，不是能力放大器
系统提示词对 agent 的影响巨大——一个差的 prompt 可以毁掉一个好模型——但它的边际收益有明确的上限。一个完美的 prompt 不能让差模型变好。
Prompts 的核心功能不是"告诉模型怎么做"，而是定义 agent 的边界、约束和失败行为——何时承认不知道、何时停止、何时请求人类介入。这些决策定义了 agent 在真实环境中的可靠性。
但 prompt 的"不可见性"是一个严重问题：两个 agent 可能在 SWE-bench 上得分相同，但其系统提示词完全不同——一个被精心调校以在特定任务上表现出色，另一个则依赖通用指令。当前的基准测试完全无法区分这两种情况。
真正的行业瓶颈：闭源策略与不可复现的成功
如果上述分析成立，那么一个推论是：对 agent 能力进步贡献最大的因素——工具设计、harness 架构、上下文工程、错误恢复策略——恰恰是最不透明的。
Claude Code 是目前 SWE-bench Pro 上表现最好的 agent 脚手架（55.4%），但它的 harness 设计是一个黑箱。我们知道它有三层权限模型、有上下文压缩、有子 agent 系统，但我们不知道它的工具 schema 如何设计、它的系统提示词是什么、它的错误恢复策略如何运作。这些信息在 Anthropic 的博客中有零星透露，但远不足以让另一个团队复现。
同样，Cursor 的 agent 模式、Devin 的自主编码流水线、Augment 的 Auggie——这些都是闭源的。当一个团队在 SWE-bench 上取得了突破性分数，行业能学到的通常只有一个数字。
这不是一个学术问题。LangChain 2026 年调查显示 57% 的组织已经在生产环境中部署 agent，而他们面临的最大障碍就是质量。当最好的 agent 策略是不可见的、不可复现的、不可自由组合的，整个行业被迫在每个组织中重新发明轮子。
形成对比的是：模型层正在快速开放。 DeepSeek V4 Pro Max、Qwen3.7 Max、MiniMax M3 等开源权重模型已经在 SWE-bench Verified 上达到约 80.5%，与 Claude Opus 4.5 仅差不到 0.5 分。但开放模型 + 闭源 harness 的组合无法被独立评估，也无法被自由改进。
开源 harness 的进展也同样重要。OpenHands 在 18 个月内积累了超过 79K GitHub stars，数百贡献者来自 AMD、Apple、Google、Amazon、Netflix、NVIDIA。使用 Claude Sonnet 4.5 + extended thinking 达到 72% SWE-bench Verified。SWE-agent 则从一个研究项目演化为了被各大学广泛采用的评估 harness。
但开源 harness 与闭源 harness 之间的差距仍然显著——在 SWE-bench Pro 上，OpenHands 和 SWE-agent 落后于 Claude Code 和 Cursor。问题在于，我们不知道这个差距来自哪里：是工具设计？是上下文管理？是错误恢复？还是所有这些因素的组合？
行业需要什么：Agent 能力的归因基准
当前的基准测试回答的是："这个 agent 能解决多少问题？"
行业真正需要回答的是："这些问题的解决，分别归功于哪些组件？"
这需要的不是一个新 benchmark，而是一种新的评估方法论：
第一，组件化的消融测试。 将 agent 分解为可替换的模块——模型、工具集、系统提示词、harness 架构、记忆系统——然后逐一替换、测量每个模块的独立贡献。这类似于深度学习中的消融研究（ablation study），但需要在 agent 层面系统化。
第二，开源参考实现。 每一个 agent 策略的创新应该附带一个最小可复现实现。OpenHands 和 SWE-agent 已经证明了这是可行的。SWE-bench 的 mini-SWE-agent 标准化评估模式也走在正确的方向上——至少它确保了对比是在相同的工具约束下进行的。
第三，公开策略注册表。 工具 schema 设计、prompt 模板、错误恢复模式、上下文管理策略——这些应该像模型权重一样被记录、版本化、共享。这不需要公司公开其全部知识产权，但需要行业对"哪些信息构成可复现性"达成共识。
Meta Context Engineering（ICML 2026）的工作指向了一个可能的方向：将上下文工程本身变成一个可优化的、可量化的、可复现的过程。MCE 不仅在 benchmark 上达成了 SOTA，更重要的是它提供了一套方法论——双层优化、skill 演化、context artifact co-evolution——这些可以被其他团队独立复现和改进。
Anthropic 的 harness 设计工作也贡献了一个重要的元原则："当新模型到来时，重新审视你的 harness，移除那些不再承担负载的组件，并添加新的组件以达成之前不可能实现的更大能力。" 这个原则意味着 agent 工程不是一次性的架构决策，而是一个与模型能力共同演化的持续过程。但这个原则的前提是——你必须知道自己 harness 的每个组件分别贡献了什么。
这正是当前行业最缺乏的。
结语
2026 年，制作一个好的 agent 不再是关于"选择哪个模型"。六个前沿模型在 SWE-bench Verified 上的差距不足 1 分，而同一个模型换一套脚手架可以差出 36 分。
模型已经不再是瓶颈。真正阻塞行业进步的，是我们无法看到、无法分解、无法自由组合那些真正有效的 agent 策略。每一个在 benchmark 上取得突破的 agent 系统，其"配方"都被锁在闭源的 harness、未公开的 prompt 和定制的工具 schema 中。
这不是一个呼吁开源一切的天真论调。但行业需要一种新的共识：如果一个 agent 策略是有效的，它就必须是可被分解、可归因、可复现的。 否则，benchmark 分数就只是营销数字，而不是工程知识的积累。
当 57% 的组织已经将 agent 部署到生产环境，而质量是他们最大的障碍时，"这个 agent 得了多少分"已经不够了。我们需要知道："这个分数是从哪里来的？"
