2026 年 7 月，部分前沿模型在 SWE-bench Verified 上的公开成绩已接近 80%。例如，Claude Opus 4.5 为 80.9%，GPT-5.4 约为 80.0%，相差约 0.9 个百分点。是否存在显著差异，还需要看测试设置和结果的不确定性。
但如果把同一个 Claude Opus 4.5 放进不同的 agent 框架里跑 SWE-bench Pro，差距就拉开了：SEAL 标准化脚手架 45.9%，Cursor 50.2%，Auggie 51.8%，Claude Code 55.4%。同一个模型，9.5 个百分点的差距。
Particula 引用 Nate B. Jones 的另一组案例：同一个 LLM 更换运行框架后，编程测试成绩从 42% 提高到 78%，相差 36 个百分点。这个二手案例提示框架设计可能带来较大影响，但还需结合具体测试设置判断。
这提出了一个评估问题：当我们说"这个 agent 达到了 80% 的 SWE-bench 分数"时，这 80% 到底有多少来自模型本身，有多少来自工具设计，有多少来自系统提示词，有多少来自错误恢复策略？只看排行榜总分，无法回答这些因素各自贡献了多少。
排行榜总分同时包含模型、工具和运行框架的影响
SWE-bench 衡量系统解决软件问题的表现。要比较模型本身，需要固定运行框架（agent 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 策略、记忆系统——通常无法仅从总分中区分。
六类组件怎样影响编程 AI 的表现
要理解成绩从哪里来，需要分别检查模型及其运行系统。以下六类组件都可能影响测试表现，它们也会相互作用；不同研究的设置不同，不能据此直接排出统一的贡献大小。
工具设计：输出格式和搜索方式会影响模型能否正确操作
一些案例显示，工具设计会显著影响测试结果：
Grok Code Fast：从 6.7% 到 68.3%。据所引案例，团队修改了编辑工具的输出格式，没有更换模型、prompt 或训练数据，测试得分便达到原来的约 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 回答了 agent 系统最基本的结构问题：是单 agent 循环还是多 agent 分工？是先规划后执行还是边想边做？如何跨会话传递状态？
Anthropic Labs 报告过一组对比。同样的 prompt（"创建一个 2D 复古游戏制作器"），单 agent 运行 20 分钟、花费 $9 后，仍未实现可用的核心玩法：实体出现在屏幕上，却不响应输入。Planner + Generator + Evaluator 三 agent 架构则运行了 6 小时、花费 $200，完成 16 项功能、10 个开发阶段，以及 AI 辅助精灵生成器和关卡设计器，游戏可以实际游玩。
后一方案成本超过前者 20 倍，运行时间也更长，因此结果差异不能全部归因于分工架构。
当 Opus 4.6 发布后，团队重新审视了 harness 的复杂性——"每一个 harness 组件都编码了一个关于模型不能独立完成什么的假设，而这些假设值得压力测试"——他们移除了 sprint 分解结构，因为更强的模型不再需要这种粒度的任务拆分。但 Planner 和 Evaluator 仍然保留了，因为它们分别处理"模型容易缩小任务范围"和"模型容易高估自己的成果"这两个在实验中仍然存在的问题。
这提供了一项设计原则：harness 不是越多越好，而是每一层都必须对应一个模型确实存在的能力缺口。当模型进化时，harness 应该收缩；当任务复杂度超出模型能力边界时，harness 应该扩展。
上下文工程：决定模型何时读取状态、摘要和工具结果
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）作为补充策略。
记忆机制：跨任务保存信息，还要准确检索
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 的上下文窗口扩大了工作记忆，但不提供跨会话持久化存储。而且"存储更多"和"检索更准"是两个完全不同的工程问题。
错误恢复：让系统发现失败，并独立检查生成结果
Particula 的分析指出，高分数 agent 和低分数 agent 之间的核心差异"不是犯更少的错误，而是能从错误中恢复"。SWE-bench 上 42% 到 78% 的差距，很大程度上来自错误恢复逻辑。
Anthropic 的 harness 实验还发现，模型评估自己的产出时容易过于乐观。"当被要求评估自己产出的工作时，agent 倾向于自信地赞美自己的工作——即使质量明显平庸。" 解决方案是将生成和评估分离为独立的 agent，并为评估 agent 专门调校使其保持怀疑态度。"调校一个独立的评估者使其保持批判性，比让生成者批判自己的工作要容易得多。"
系统提示词：说明约束，以及何时停止或请求帮助
系统提示词会影响 agent 的行为，但效果仍受模型能力和任务条件限制。
提示词既可以指导执行步骤，也需要定义 agent 的边界、约束和失败行为——何时承认不知道、何时停止、何时请求人类介入。这些要求会影响 agent 在真实环境中的可靠性。
但 prompt 的"不可见性"是一个严重问题：两个 agent 可能在 SWE-bench 上得分相同，但其系统提示词完全不同——一个被精心调校以在特定任务上表现出色，另一个则依赖通用指令。仅看基准总分无法区分这两种情况。
闭源系统难以复现，外界难判断哪些设计带来提升
上述案例提示，工具设计、运行框架、上下文工程和错误恢复策略都可能显著影响表现，但公开程度不足时，外界难以验证各自的贡献。
Claude Code 在前述同模型 SWE-bench Pro 对比中得分最高（55.4%），但其完整运行系统并未随成绩一同公开。三层权限模型、上下文压缩、子 agent 系统，以及工具接口、系统提示词和错误恢复策略如何共同作用，都需要更多细节才能复现。Anthropic 博客介绍了其中部分设计，但这些说明还不等于完整参考实现。
同样，Cursor 的 agent 模式、Devin 的自主编码流水线、Augment 的 Auggie——这些都是闭源的。当一个团队在 SWE-bench 上取得了突破性分数，行业能学到的通常只有一个数字。
这一问题也影响实际部署。LangChain 2026 年调查显示 57% 的受访组织已经在生产环境中部署 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 分解为可替换的模块——模型、工具集、系统提示词、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 的每个组件分别贡献了什么。
只有明确每个组件的作用，才能判断哪些设计值得保留。
选模型之外，还需要理解运行系统怎样影响成绩
设计编程 agent，既要选择模型，也要检查运行系统。前述公开成绩中，有的模型分差不足 1 个百分点；Particula 引用的框架变化案例则报告了 36 个百分点的变化。但这些来自不同测试，不能直接用来比较模型与框架的贡献大小。
这些例子不足以说明模型已不再是瓶颈，但表明运行系统值得同等认真地评估。闭源框架、未公开的提示词和定制工具接口，会增加外部团队复现结果的难度。
更有帮助的做法是，为有效策略提供可拆解、可归因、可复现的证据。这样，benchmark 分数才能帮助其他团队判断改进是否适用于自己的系统。
对上述调查中已将 agent 部署到生产环境的 57% 受访组织而言，质量仍是主要难题。除了"这个 agent 得了多少分"，还需要知道："这个分数是从哪里来的？"
