作者：Lingo　发布：2026-06-27　阅读时间：18 分钟

Coding Agent 分数上涨，测到的究竟是什么？

同一个模型换一套执行框架，软件工程 benchmark 可以明显上涨。反过来，模型权重已经更新，如果测试环境没有覆盖新能力，分数也可能不变。

所以，“新模型的 Coding 分数更高”不是一句完整的技术解释。外部看到的是模型、工具、推理预算和验证器共同产生的结果。若这些变量没有拆开，benchmark 上的提升很容易被全部记到模型权重名下。

分数怎样归因，还关系到一个更大的判断：Coding Agent 做对更多仓库任务，是否说明它更理解真实产品？答案取决于评测环境究竟要求它完成什么。

一个分数混合了哪些变量

可以把观测到的任务成功率记成：

C_{\mathrm{obs}} =G\!\left(\theta,b_{\mathrm{reason}},h_{\mathrm{agent}},n_{\mathrm{rollout}},e_{\mathrm{eval}}\right)

$\theta$ 是模型参数， $b_{\mathrm{reason}}$ 是推理预算， $h_{\mathrm{agent}}$ 表示工具和执行循环， $n_{\mathrm{rollout}}$ 是候选轨迹数量， $e_{\mathrm{eval}}$ 是测试环境。 $G$ 不是业界通用公式，只是把影响分数的变量写在一起。

右边任何一项变化， $C_{\mathrm{obs}}$ 都可能上升。模型可能真的学会了更好的代码模式，也可能只是获得更多尝试机会；工具把相关文件找得更准，或者 verifier 更善于从多份补丁中挑出能通过测试的一份，同样会提高最终成绩。

benchmark 仍然有价值。问题不在于分数不可信，而在于解释分数时必须保留实验条件。

训练怎样把工具使用带进模型

基础模型学习文本中的 token 分布。Coding Agent 的训练数据则可以保存整段交互：

\tau=(o_0,a_0,o_1,a_1,\ldots,o_T)

$o_t$ 是第 $t$ 步看到的 issue、文件内容或命令输出， $a_t$ 是随后打开文件、修改代码或运行测试的动作。成功轨迹可以用于监督微调，让相似上下文中的动作更容易再次出现。

强化学习进一步把执行结果写进奖励：

\max_\theta J(\theta) =\mathbb{E}_{\tau\sim\pi_\theta}[R(\tau)]

如果补丁通过测试时 $R(\tau)=1$ ，失败时为 0，训练就会提高成功轨迹的概率。难点在于一条轨迹可能包含几十次操作，最后的测试结果要怎样归因到前面的搜索和修改，这就是长轨迹中的信用分配。

StepCoder 在较短的代码生成任务上使用编译和单元测试作为反馈，并遮掉测试没有执行到的代码，避免把结果粗暴归给所有 token。它还清洗了 7,413 条 APPS+ 数据，因为原数据存在错误输出和无法编译的参考答案。执行奖励比语言偏好更接近程序事实，但奖励所依赖的数据和测试也必须先可靠。

SWE-Gym 把环境扩大到真实仓库。它包含 2,438 个带依赖、运行环境和单元测试的 Python 任务。研究者用这些任务训练软件工程 Agent，SWE-bench Verified 和 Lite 的解决率最多提高 19 个百分点；再加入从多条候选轨迹中选择的 verifier，Verified 成绩达到 32.0%。

SWE-Gym 的结果不能归给某一个单独部件。训练过的模型更会执行仓库任务，推理阶段的候选选择又带来额外增益。最终分数属于整套系统。

测试既是反馈，也是边界

可执行测试解决了一个重要问题：模型不能只写一段看起来合理的补丁，它必须让程序产生预期结果。

但测试不会检查没有写入断言的事实。一个退款 worker 可以通过所有单元测试，却仍然没有覆盖商家第 31 天转走余额以后由谁提供退款资金。这个业务问题跨过支付产品的期限和资金控制权，不会因为代码能够编译而自动进入奖励。

Kimi-Dev 使用真实测试训练 BugFixer，再把能力迁移到可以自由调用工具的 SWE-Agent。论文报告 pass@1 达到 48.6%，同时承认 TestWriter 会因复现覆盖不足产生假阳性。这个结果准确地说明了测试型奖励的边界：反馈可以很接近真实执行，测试覆盖仍然决定系统看得见哪些错误。

SWE-RL 选择了另一种权衡。它从 GitHub 软件演化记录中筛出大量 PR 种子，用模型补丁与真实 PR 的文本相似度代替完整执行环境。这使大规模训练更便宜，也引入了清楚的代理差异：补丁像历史修改，不等于补丁通过测试。

文本相似度、生成测试和真实执行环境没有谁在所有场景都最好。便宜的代理适合扩大数据规模，真实测试更接近运行结果，完整业务验收还需要把跨系统约束写进环境。评价一项训练方法时，应先看它的奖励究竟代表哪一层正确性。

同一权重换 harness，分数也会变化

模型厂商公布的系统卡提供了接近控制变量的例子。Claude Opus 4.8 在首份系统卡的 Terminal-Bench 2.1 上得到 74.6%；Anthropic 后来换用 mini-SWE-agent harness 重跑，同一模型得到 82.7%。权重没有随重跑改变，执行框架改变了。Claude Opus 4.8 System Card

另外两组公开对照把系统变量分得更开：

对照	公开的系统差异	Terminal-Bench 2.1
Mythos 5 / Fable 5	底层权重相同；Fable 增加安全分类和回退	88.0% / 84.3%
GPT-5.6 Sol / Ultra	单 Agent / 默认四个 Agent 并行	88.8% / 91.9%

Mythos 5 与 Fable 5 使用同一组底层权重。Fable 的安全分类器命中后会拒绝或回退到 Opus 4.8，评测中 20.9% 的 Fable 轨迹发生了这类事件。Claude Fable 5 & Claude Mythos 5 System Card 这组差异来自部署策略，不应解释成底层权重的 Coding 能力不同。

GPT-5.6 Ultra 默认让四个 Agent 并行，Sol 则是单 Agent。Ultra 的更高分至少有一部分来自更多计算和候选轨迹，不能全部记在模型参数上。GPT-5.6 发布说明、GPT-5.6 模型指南

上述系统卡能拆出权重以外的系统增益，不能反推出厂商没有公开的训练配方。系统卡没有公布完整数据集或奖励设计时，技术解析也应停在证据结束的位置。

模型升级以后，旧 Harness 必须重测

Harness 中的规则通常是在补偿某种已知失败。强制规划用于减少直接行动造成的偏离；定期重置上下文用于处理长历史中的遗忘；固定反思轮次假定额外自检的收益高于 token 和延迟成本。底层模型变化以后，这些假设不会自动继续成立。

可以把旧模型记为 $M_0$ ，新模型记为 $M_1$ ，精简 harness 记为 $H_0$ ，现有复杂 harness 记为 $H_1$ 。任务集、推理预算和 evaluator 保持不变，至少需要比较四组结果：

组合	要回答的问题
$S(M_0,H_0)$	旧模型离开补偿规则后的基线
$S(M_0,H_1)$	复杂 harness 对旧模型是否有帮助
$S(M_1,H_0)$	新模型在相同最小条件下提高了多少
$S(M_1,H_1)$	旧 harness 是否仍适合新模型

Harness 对某个模型的边际作用可以写成：

\Delta_H(M)=S(M,H_1)-S(M,H_0)

若 $\Delta_H(M_0)>0$ ，而 $\Delta_H(M_1)\leq 0$ ，这套规则曾经有用，现在已经没有正收益。一次成功案例不能完成这个判断。软件工程任务本身存在运行波动，任务还可能与训练材料重合，因此需要新鲜任务和重复运行。

平均成功率也不足以描述长期 coding。两个系统都可能完成八成任务，一个稳定失败在可回退的测试环节，另一个偶尔破坏工作树。ICML 2026 的 Agent 可靠性研究把一致性、扰动鲁棒性、可预测性和失败严重度从总体准确率中拆开。对 CLI Agent，还应记录人工介入、回滚、未验证跨度，以及失败后能否恢复到干净状态。

单条规则也可以单独核算。设 $r$ 是待评估规则， $C_r$ 是它引入的 token、延迟、信息损失和行动限制，并把这些成本换算到同一效用尺度：

V_r(M,D)=S(M,H\cup\{r\},D)-S(M,H,D)-C_r

当 $V_r(M,D)\leq 0$ ，应删除的是这条能力补偿规则，不是所有外部约束。Anthropic 的 Managed Agents 文章报告过一个具体案例：Sonnet 4.5 接近上下文上限时会提前收尾，系统为此强制重置；换成 Opus 4.5 后，重置只剩开销。文章没有公开完整任务分布和原始轨迹，不能证明其他模型也应取消重置。这个公开案例只说明，模型升级后有必要重新做消融。

Harness 里的规则至少分成三层：

层	作用	模型升级后的处理
能力补偿	强制分步、固定反思、定期重置、提示特定搜索套路	重新消融，没有边际收益就删
稳定接口	Session 日志、文件系统、工具协议、状态查询	保持简单，允许替换实现
治理边界	Sandbox、权限、测试门槛、审计、回滚	由操作风险决定，不能随模型分数自动放宽

更强的模型可能减少第一层规则。第三层有时反而更重要，因为模型能够执行的动作更多，错误动作的影响范围也更大。模型会写更好的代码，不能推出它已经获得部署、删除数据或改变业务权利的授权。

强化学习可能先改变概率分布

更高的 pass@1 还不一定意味着模型产生了训练前完全不存在的新推理方法。

NeurIPS 2025 的一项 RLVR 研究比较基础模型和强化学习模型在不同候选数量 $k$ 下的表现。强化学习模型在较小的 $k$ 下更容易采到正确答案；候选数量足够大时，基础模型反而覆盖更多正确路径。研究者据此认为，实验中的强化学习主要重新分配了已有路径的概率，没有稳定创造基础模型分布以外的新推理模式。Does Reinforcement Learning Really Incentivize Reasoning Capacity in LLMs Beyond the Base Model?

这项研究没有否定强化学习的价值。把正确路径从低概率位置推到一次采样就容易出现，本身就是实际能力提升。研究限制的是另一种说法：benchmark 上升不能自动证明模型内部获得了全新的通用理解。

Thinking vs. Doing 又把环境交互步数单独拿出来。模型先执行一步，读到结果，再决定是否换路。长任务表现改善可能来自参数中的知识，也可能来自更多观察环境的机会。比较模型权重时，harness、推理预算和候选次数应尽量固定。

Coding 能力不等于产品责任

Coding benchmark 衡量的是一个明确环境中的任务完成率。环境越接近真实仓库，分数越有工程意义；测试越完整，奖励越接近程序正确性。

业务责任仍然需要另一个条件：决定经营结果的事实必须进入任务。支付资格、资金控制期限、退款资金来源和产品负责人已经确认的权利，如果没有进入测试或验收，Agent 不会仅凭更高的 SWE-bench 分数自动遵守。

测试覆盖止于已经写入环境的目标，因此技术上正确的局部修改仍然可能伤害产品。测试告诉模型“补丁通过了”，却没有告诉模型这次修改是否取消了商家的审核权。verifier 能确认目标函数里的成功，不能替产品负责人定义目标函数之外的承诺。

评价 Coding Agent 时，最稳妥的说法应包含实验边界：哪个模型、哪套 harness、多少推理预算、尝试几次、由什么测试判定成功。离开这些条件，只剩一个百分比，很难知道能力究竟增长在哪里。

Skill 到底有没有用？一次没有提升的编程基准实验：公开 Skill benchmark 的结论并不一致。本文对照 SkillsBench、SWE-Skills-Bench 和困难编程任务实测，说明没有提升时应怎样解释结果。
CLI Agent 的长任务为什么越做越不可靠：CLI Agent 在长任务中失控，不是模型参数逐步变差，而是当前上下文偏离了项目的可验证状态。缩短未验证跨度，比单纯扩大窗口更重要。
中文“AI 味”是怎样被训练出来的？：为什么多种模型会反复写出相似的中文？本文从训练数据和偏好选择追溯原因，也说明标注外包、跨模型蒸馏的公开证据到哪里为止。