语言模型正改变软件构建与计算问题求解。编程智能体（coding agents）通过运行框架（harness）即管理模型工具、上下文与任务执行的系统来应用能力。模型提供核心智能，框架愈发关键于运用智能。选择智能体即选模型与框架。数百万人已用智能体，但框架影响不明。我们评估了七个模型与三种框架——克劳德代码（Claude Code）、代码命令行（Codex CLI）和派（Pi）——的 21 个模型-框架组合在 SWE-benc

语言模型正在改变我们构建软件与解决计算问题的方式。编码智能体通过脚手架（harness）将这些能力投入应用，脚手架是管理模型工具、上下文与任务执行的软件系统。模型提供核心智能，但脚手架对智能的有效运用日益关键。因此选择编码智能体意味着同时选模型和脚手架，即便表面只关注模型。

已有数百万人使用编码智能体，但脚手架选择的影响仍不明。换个脚手架能否让同一模型解决更多任务或降低成本？

我们在 SWE-bench Lite 与 Terminal-Bench 2.0 上评估了跨越 7 个模型和 3 个脚手架（Claude Code、Codex CLI、Pi）的 21 个模型–脚手架组合，揭示两个开源基准上的三个意外发现：

1. 脚手架选择对任务成功率影响小，但对成本影响显著。同一模型在最高 5 倍成本差下成功率相似。
2. 简单脚手架也有竞争力。Pi 这个最小化开源脚手架在成本与成功率上均可竞争。
3. 模型用别的脚手架可能比用自家的更好。你的 Claude 模型或许不需要 Claude Code。

下文逐一检视每项发现，并会公开分析轨迹。

图1. 平均 token 成本与成功率。阶梯线显示各成本水平下观察到的最高成功率（帕累托前沿）。用按钮比较模型与脚手架。

实验设置

我们比较 21 个模型–脚手架组合在同样从各基准随机抽取的 30 个任务上的表现：SWE-bench Lite 与 Terminal-Bench 2.0。每个组合每任务运行三次以捕捉波动。从各脚手架原生配置起步，选高努力设置，限定每次尝试最多 100 个智能体轮次控制成本。轮次与努力设置依各脚手架定义。用基准官方评估器测成功率。

测量细节：成本与成功率先在各任务三次尝试间平均，再在 30 任务间平均。用 10000 次 bootstrap 重采样估 95% 置信区间。token 成本采用 2026 年 9 月 1 日固定直连 API 价目表，跨脚手架同模型同价。

SWE-bench Lite 屏蔽容器外网，禁用 Claude Code 与 Codex 默认网页工具，API 请求层拒绝托管工具声明。

Pi 加两个包配置订阅密钥与控制轮次。Kimi K3 经 Fireworks AI 访问，三脚手架均用该模型原生单一思考模式。

发现 1/3：脚手架对成本的影响大于正确率

同一模型常以显著不同成本获相似成功率。GPT-5.6 Luna 两基准成本最低，Claude Fable 5 在 SWE-bench Lite 成功率最高。开源权重 Kimi K3 在 SWE-bench Lite 接近 GPT 5.6 Sol 的帕累托前沿，在 Terminal-Bench 2.0 略低于前沿。这些模型跨脚手架性能无显著差异。Claude Fable 5 在 Claude Code 解决 97.8% 尝试，Codex 与 Pi 均为 96.7%，但 Claude Code 成本约 Pi 两倍（$1.33 对 $0.67）。

Fable 5 在 Claude Code 成功率略高但成本两倍。成本差不限于此。共享模型上，Claude Code 在 SWE-bench Lite 成本约为 Pi 2.0 倍、Codex 1.6 倍；在 Terminal-Bench 2.0 约为 Pi 1.5 倍（几何平均）。同时脚手架对成功率平均影响在 SWE-bench Lite 内 ±2%，Terminal-Bench 2.0 约 ±5%。

因脚手架不同为同等质量多付费如同缴“脚手架税”。接受编码智能体默认脚手架而不比选，可能就在付隐藏税。模型评估应比较同模型跨常用脚手架的成本与成功率。

发现 2/3：简单脚手架也可以有竞争力

Pi 仅靠四个工具（read、write、edit、bash）就到达两基准的帕累托前沿。为理解脚手架设计如何影响支出，我们检视已完成尝试的成本、轮次数与初始上下文。

图2. 累计成本–成功曲线。将已完成尝试从最便宜到最贵排序，合并同成本，累加成本与成功，各除以尝试数。失败尝试增成本不增成功。曲线用九点移动平均。

智能体可能以相似轮次数产生显著不同成本。Fable 5 在 SWE-bench Lite 上 Pi 与 Claude Code 平均每尝试 15.4 与 15.3 轮，但 Claude Code 成本高约两倍，成功率仅增 1.1%。即每记录轮次开销更高（轮次定义跨脚手架不同）。

图3. SWE-bench Lite 首次主模型调用的上下文，均值±标准差。指令与工具 schema 长度以字符计。供应商报告输入 token 测总初始上下文。

脚手架税可能始于首次模型调用。七模型上 Claude Code 平均初始上下文超 Pi 10 倍，指令和工具 schema 更长。这会增加成本，尽管总支出还取决于缓存、生成 token 等。

Pi 与 Codex 的效果显示用现有模型做开源脚手架研究的机会。研究者无需专有脚手架或联合训练即可用 SOTA 编码脚手架。更丰富功能或对其他模型、工作负载有益。脚手架复杂性应视为经验权衡。

发现 3/3：模型在自家以外的脚手架也能有竞争力

供应商特定优化不保证最佳配对。供应商有时为自家环境优化模型：如 OpenAI 称 GPT-5-Codex 为 Codex 中软件工程优化。但在六个 Anthropic 和 OpenAI 模型及两基准上，替代脚手架在十二项比较中有九项取得最高观察成功率。

结果不限于 Opus 或 Claude Code。Sonnet 4.6 在 SWE-bench Lite 上 Codex 成功率 68.9% 对 Claude Code 66.7%，成本相似。GPT-5.6 Sol 在 Terminal-Bench 2.0 上 Pi 成功率 83.3% 对 Codex 78.9%，成本约半（$0.42 对 $0.76）。跨六模型两基准，替代脚手架在九/十二比较中最佳。

这表明模型能力兼容、可泛化至其他脚手架。尽管供应商报告优化自家环境，同供应商不保证最佳配对。实际问题仍是哪脚手架为给定模型与工作负载提供成本与成功率最佳平衡。

图4. 各模型在 Pi、Codex CLI、Claude Code 上每尝试平均 token 成本与成功率，须线为 95% 置信区间。绿框分别标出各模型最低成本与最高成功率。断成本条超出显示轴。

结尾笔记

同模型可以显著不同成本获相似成功率。测试的基准上，简单开源脚手架有竞争力，模型在自家外表现也好。只关注成功率时脚手架税易被忽视。

跨模型，Pi 和 Codex 常比 Claude Code 以更低成本获相似成功率。发现限于两开源基准，模型训练时可能见过。其他基准或工作负载或不同。

许多先前工作显示模型与系统配置共同选择的价值。编码智能体使用广泛，脚手架选择更迫切。下一步是在真实开发流中评估并自动选择脚手架，其中需求演变、开发者反馈、任务跨会话延伸。

更广泛看，所需脚手架取决于编码智能体角色。日常任务中，它们是模型智能的接口：管理上下文、访问工具、执行任务。模型更强时，所需脚手架可能减少。通用编码智能体应优先成本效率与可靠，因许多任务不需花哨附加功能。对于模型能力边界的难题（如科学发现），代理仍可从提供结构化引导的脚手架受益。脚手架研究可帮模型推知识边界。但用户不应自己配，应设想随任务自适应且通用的重定向脚手架。

多数人质疑提供商自有 harness 的臃肿溢价，认为轻量或自研 harness 更划算，少数人维护其安全对齐价值，同时不少意见指出并发与上下文策略比单纯对比 harness 更关键。

认为提供商自有 harness 收取了低效的“税”且差异被夸大

• 用户为 Claude Code 等臃肿系统提示买单，直接走 API 时其他 harness 更便宜；轻量或自研 wrapper 在同等模型下表现更好且易掌控，原生 harness 差异被高估（较多人） > 用户为 Claude Code 等臃肿的万能系统提示买单，若直接调用 API，几乎所有其他 harness 在成本上都更优。（@x312）

认为将额外开销称作“税”忽视了安全与对齐价值

• 原生 harness 额外重量主要为沙箱和安全对齐，Pi 省略防护才显快，把不安全转嫁为外部性，大企业为模糊安全买单是标准操作（少数人） > 把安全和对齐投入说成是税并不诚实，就像宣称把废物倒入海洋免费从而逃避处理税一样。（@jswelker）

认为单 harness 对比浅薄，上下文与执行模式才是成本关键

• 并发、子代理和多模型委派影响远大于原生指令；不同 harness 调用数相似但上下文消耗迥异；长任务中系统提示占比稀释使“税”不明显（较多人） > 最优 harness 使用并发和子代理且不绑定单一模型，单 harness 分析很浅薄，尽管“提供商优化不保证最佳配对”可能正确。（@Supermancho）

认为模型能力与原生工具匹配比 harness 本身更重要

• 新模型更擅长微调对应的原生工具，模型越聪明需指令越少；harness 主要防失败调用不影响智能上限，如同电工用现有工具干活（较多人） > 新模型更擅长原生 harness 工具调用，反而对形似默认工具的自定义工具表现更差，因此用模型微调对应的工具更重要。（@lukax）

有价值的补充

• 长视野任务中系统提示占比被稀释，所谓“税”在总成本中可能不明显。
• 社区缺乏可靠的 harness 基准测试，且常单一用 token 数衡量 Pi，忽视了防止错误编辑等鲁棒性维度。
• 自研轻量 harness 的小表面积有助于保留开发者对系统的理解和灵活适配工作流。