SWE-1.7 的提升究竟来自哪里？
TL;DR
- 场景：Agent 模型从 A 换成 B 任务成功率上升时，团队常把增益直接记到新模型权重；SWE-1.7 是少有的"训练在 Devin Harness"案例------能否把它的提升归到裸模型，决定了迁移、复现和成本决策是否成立
- 结论：Agent 表现由模型检查点 + 后训练环境 + 运行时 Harness + 验证器 + 预算 五个变量共同生成；SWE-1.7 能证明"强底座 + 大规模 RL 在 Devin 内仍可获得系统级增量"，但不能证明"这些增量是脱离 Devin 仍完整的裸模型能力"
- 产出：5 个归因变量、5 段公开证据解读、4 组反事实受控替换测试（同模型换 Harness / 同 Harness 换模型 / 同轨迹换验证器 / 同任务换预算）、5 行投入决策矩阵、最低可行 3 步实验组合、12 行错误速查卡
版本矩阵
| 功能 / 事件 | 状态 | 说明 |
|---|---|---|
| SWE-1.7 官方发布 | ✅ 已验证 | Cognition 2026-07 博客：以 Kimi K2.7 为起点继续大规模 RL |
| SWE-1.7 基于 Kimi K2.7 继续训练 | ✅ 已验证 | Cognition 官方页：K2.7 已接受大量 RL 后训练；SWE-1.7 继续大规模 RL |
| Kimi K2.7 是 Moonshot 系列模型 | ✅ 已验证 | DataLearner 与 Moonshot 官网：K2.5（2026-01）/ K2.6（2026-04-21 GA，1T MoE 32B 激活，256K context）/ K2.7 Code（2026-06-15，Code 高速版同日） |
| Kimi K2.6 架构 1T MoE / 32B 激活 | ✅ 已验证 | CSDN 多源：1T MoE，32B 激活参数，256K Token 上下文 |
| Kimi K2.7 Code 高速版 180--260 Tokens/s | ✅ 已验证 | 腾讯新闻 2026-06-15：常规场景 180 t/s，短上下文 260 t/s |
| SWE-1.7 在 Devin Harness 中训练 | ✅ 已验证 | Cognition 官方页：直接在 Devin Harness 中训练 |
| SWE-1.7 官方数字：FrontierCode 1.1 Main 42.3% | ✅ 已验证 | Cognition 官方报告（mmx vision 读图与官方页一致） |
| SWE-1.7 官方数字：Terminal-Bench 2.1 81.5% | ✅ 已验证 | Cognition 官方报告 |
| SWE-1.7 官方数字：SWE-Bench Multilingual 77.8% | ✅ 已验证 | Cognition 官方报告 |
| FrontierCode 衡量代码可合并性 | ✅ 已验证 | Cognition 2026-06 FrontierCode 文章：评估"维护者会不会真的合并这个 PR"，而不只是"代码对不对" |
| FrontierCode 1.1（2026-07-07） | ✅ 已验证 | Cognition FrontierCode 1.1 博客：调整阻断条件与公平互联网使用规则 |
| SWE-1.7 评测：Anthropic 用 Claude Code | ✅ 已验证 | Cognition 官方评估方法：所有模型在最大推理能力下评估，Anthropic 用 Claude Code |
| SWE-1.7 评测：OpenAI 用 Codex | ✅ 已验证 | Cognition 官方评估方法：OpenAI 模型用 Codex |
| SWE-1.7 评测：其他模型用 Devin CLI | ✅ 已验证 | Cognition 官方评估方法：其他模型用 Devin CLI，超时 4h |
| 自压缩（Self-Compaction）作为长任务机制 | ✅ 已验证 | Cognition 官方页：Intelligent Self-Compaction for Long-Horizon Tasks，模型学到接近上下文边界时写摘要 |
| 自压缩与 alternating length penalty 结合 | ✅ 已验证 | Cognition 官方页：budget phases 惩罚超出 weighted cost function 的方案 |
| Meta Muse Spark 1.1 主从 Agent 与上下文管理 | ✅ 已验证 | Meta 官方与多源报道：2026-07-09 闭源多模态推理模型，主从 Agent、subagents.spawn_agent、context 容器等 |
| Cursor Grok 4.5 在 CursorBench 训练数据污染 | ✅ 已验证 | Cursor 官方说明：将 Grok 4.5 在 CursorBench 的结果排除 |
| SWE-1.7 之前的 SWE-1.5 | ✅ 已验证 | Cognition 2025-10-29：SWE-1.5 frontier-size 模型，已是 SWE-1.7 演进起点之一 |
| 跨 Harness、跨验证器、跨预算完整消融 | ❌ 不成立 | 公开材料未提供逐项消融；Cognition 同时提到训练稳定性、基础设施、数据质量、长任务技术 |
| 把厂商自报榜单直接当模型增量 | ❌ 不成立 | 不同模型使用不同 Agent 系统，不能拆出裸模型净贡献 |
一个团队把 Agent 模型从 A 换成 B，任务成功率明显上升，最容易出现的结论是：新模型的权重更强，所以换到任何系统里都能得到同样提升。
这个结论通常越过了最关键的一步：Agent 的表现不是由模型名单独决定的，而是由模型检查点、后训练环境、运行时 Harness、验证器、推理预算和任务分布共同产生。
SWE-1.7 是一个很适合拆解这个问题的案例。Cognition 公开说明，它以已经接受大量强化学习后训练的 Kimi K2.7 为起点，继续进行大规模 RL；同时，SWE-1.7 直接在 Devin Harness 中训练，并把长任务自压缩、训练稳定性、数据质量和评测方法一起纳入系统。1
所以它能支持一个重要判断：强底座在真实软件工程环境中继续后训练，仍可能获得明显的系统内增量。
但它不能单独支持另一个更强的判断：这些增量已经被证明属于脱离 Devin 后仍能完整保留的裸模型能力。
这两句话之间的差距，就是 Agent 能力归因真正需要解决的问题。
一、先明确五个归因变量
第一是模型检查点。它承载底座预训练、已有后训练以及本轮继续训练写入权重的策略。模型是否更会探索代码库、失败后恢复、调用工具验证假设，首先会体现在这里。
第二是训练环境与学习信号。模型看到什么任务、能调用哪些工具、奖励函数接受什么结果、验证器是否能识别投机解法，都会决定权重最终吸收什么行为。
第三是运行时 Harness。它向模型暴露工具、状态、沙箱、上下文压缩、超时、恢复和并发机制。模型学会的策略，如果找不到相应的接口，也可能无法执行。
第四是验证器。它定义什么算完成，也定义什么行为会被奖励。只检查测试是否变绿，和同时检查回归、范围、测试有效性与代码质量，是两套不同的能力定义。
第五是预算策略。Token、工具轮次、上下文窗口、超时和人工接管都会影响最终成功率。高预算下的成功，不等于固定成本下的优势。
归因时真正需要观察的不是模型名有没有变化，而是：
在固定其他条件后，替换其中一个对象，任务结果、行为轨迹和资源消耗发生了什么变化？
二、SWE-1.7 的公开证据能证明什么
1. 强底座仍有后训练空间
Cognition 将 SWE-1.7 描述为基于 Kimi K2.7 继续训练的系统。官方报告给出了它与 Kimi K2.7 Code 在 FrontierCode 1.1 Main、Terminal-Bench 2.1 和 SWE-Bench Multilingual 上的对比结果。1
这些数字是厂商自报结果，不能替代第三方复现。但它至少说明：在 Cognition 的训练与评测体系里，强底座并没有因为已经做过大量 RL，就自动失去继续获得增量的空间。
这里可以得出的结论是：后训练空间仍然存在。
不能得出的结论是：差值全部来自某一个 RL 算法、某一批数据或某一种模型内部能力。 Cognition 同时提到了训练稳定性、基础设施、数据质量和长任务技术，公开材料没有提供逐项消融。1
2. 训练发生在 Devin，而不是抽象的工具调用里
Cognition 明确写道，SWE-1.7 直接在 Devin Harness 中训练。模型学习到的行动策略，很可能与 Devin 的工具、沙箱、状态表达和长任务流程存在耦合。1
这种耦合不是缺陷。真实环境后训练的价值，恰恰在于模型学习什么时候先搜索，什么时候读更多文件，什么时候写小脚本验证语义，什么时候停止猜测，什么时候扩大调查范围。
但它会影响迁移。目标系统至少要核对：工具名称和参数语义、结果格式、文件与进程状态、失败恢复、上下文压缩和验证反馈是否足够相近。
因此，SWE-1.7 更稳妥的表述是：Cognition 在 Devin 所代表的软件工程环境中，把一个强底座继续训练成了更适合这类环境的 Agent 检查点。
3. 自压缩是模型策略与运行时协议的联合能力
自压缩不能简单归到模型或 Harness 的某一侧。
模型需要学会选择哪些状态必须保留、怎样写摘要、怎样从摘要恢复；运行时则需要检测上下文边界、触发压缩、保存原始状态，并把摘要作为新的工作上下文重新启动执行。1
只有前者，没有触发与恢复接口，自压缩不会自动发生；只有后者，没有经过相应训练的模型，摘要可能丢失约束，恢复后也可能重复工作。
Meta 对 Muse Spark 1.1 的公开描述也把主从 Agent、上下文管理和压缩策略放在同一系统边界里。4这说明部分过去由运行时编排的策略正在进入训练目标，但运行时仍然提供行动接口。
真正应该问的是：模型承担了多少信息选择与恢复策略，运行时承担了多少触发、持久化和重建职责；换掉其中一侧后，能力还能保留多少。
4. 验证器不只是测量工具，也是训练行为的来源
Cognition 将数据质量拆成验证器质量、任务难度和防作弊。训练任务要减少错误接受与错误拒绝，沙箱还要隔离评分路径，避免 Agent 直接利用答案或环境漏洞。1
这意味着 SWE-1.7 学到的"更彻底调查、主动验证、处理隐藏约束"，不只是模型规模自然增长，也可能来自训练环境反复拒绝表面正确但不完整的方案。
FrontierCode 的公开方法同时关注正确性、回归安全、测试质量、改动范围和代码质量；FrontierCode 1.1 还调整了阻断条件与公平互联网使用规则。23
所以 Agent 分数不是对模型能力的中性读数。验证器选择了哪些行为会被计为能力。
5. 榜单回答的是系统比较，不是裸模型消融
SWE-1.7 的评测中，不同模型可以使用各自适配的 Agent 系统：Anthropic 模型使用 Claude Code，OpenAI 模型使用 Codex，其他模型使用 Devin CLI。1
这种设置适合回答采购问题：哪个完整产品系统在我的任务上最好？但它不能直接回答归因问题：在固定 Harness、验证器和预算后，哪个模型检查点贡献了增量？
把第一类榜单直接用于第二类判断，会把产品适配、工具能力和预算差异错误记到模型权重名下。
三、四组反事实测试
测试 1：同模型换 Harness
固定模型检查点、任务、初始仓库、验证器和总预算，只替换 Devin 类 Harness 与目标自研 Harness。重点记录工具映射失败、结果格式误解、压缩恢复失败、人工接管、改动范围和墙钟时间。
如果优势在原生 Devin 中明显、换到目标 Harness 后大幅缩小，优先检查工具协议、状态表达和恢复接口，而不是直接判定模型宣传失真。
测试 2：同 Harness 换模型
固定 Harness、系统指令、工具、验证器、预算、任务和超时，只替换模型检查点。这是最接近业务采购的证据：如果新模型在固定环境中同时提高成功率、降低人工接管，且没有显著扩大范围或成本，升级才有直接依据。
测试 3：固定模型与 Harness，更换验证器
先对同一批轨迹做离线重评，分别使用功能测试验证器和同时检查回归、范围、测试有效性与质量的强验证器。
如果弱验证器通过、强验证器失败的比例很高，说明原指标主要奖励"测试变绿"。这时应该先补验证器和验收标准，而不是急着换模型。
测试 4：固定任务，改变预算与上下文策略
至少比较两个现实预算档位，记录成功率、单位成功成本、压缩恢复成功率、遗忘约束、循环次数、工具时间和 P95 时延。
如果优势只在高预算、长超时或原生压缩下成立，它仍可能是有价值的产品能力，但采购与架构决策必须把这些运行条件一起纳入。
四、实验结果如何决定下一笔投入
| 结果 | 更可能的瓶颈 | 投入方向 |
|---|---|---|
| 固定 Harness 后新模型稳定提升 | 模型检查点 | 升级模型或增加强模型路由 |
| 原生 Harness 强，目标 Harness 明显衰减 | 工具、状态或恢复适配 | 改 Harness、工具协议和压缩恢复 |
| 强验证器使成绩大幅下降 | 验证器定义过窄 | 补验证器和离线重评 |
| 提升只在高预算下出现 | 运行时计算与上下文策略 | 优化预算、压缩、缓存和升级条件 |
| 固定条件下没有稳定增量 | 榜单优势未迁移 | 保持现有模型，重新检查任务匹配 |
小团队不需要复刻厂商的大规模 RL。最低限度也应完成三件事：固定 Harness 的模型 A/B；同一轨迹的强验证器离线重评；两个现实预算档位的复测。
五、最稳妥的结论
SWE-1.7 可以支持以下判断：强底座继续在真实软件工程环境中进行 RL，仍可能获得明显的系统内增量；长任务、工具探索、验证和压缩恢复已经被纳入学习过程；这些能力与 Devin Harness、训练验证器和预算策略存在明确关系。
但公开材料没有提供完整的跨 Harness、跨检查点、验证器和预算消融，因此无法给出各层净贡献比例，也不能保证它在自研 Agent 中复制 Devin 内的提升。
Agent 时代最危险的归因方式，是把完整系统的成功全部写在模型名下；第二危险的方式，是看到系统依赖后又否认模型训练的增量。
正确做法不是在"模型更重要"和"Harness 更重要"之间选边，而是固定条件、逐项替换，然后只在证据允许的范围内下结论。
主要来源
- 1 Cognition：SWE-1.7，cognition.com/blog/swe-1-...
- 2 Cognition：FrontierCode，cognition.com/blog/fronti...
- 3 Cognition：FrontierCode 1.1，cognition.com/blog/fronti...
- 4 Meta：Muse Spark 1.1，ai.meta.com/blog/introd...
- 5 Cursor：Grok 4.5，cursor.com/blog/grok-4...
- 6 Cognition：评估 coding agents，cognition.com/blog/evalua...
错误速查卡
| 症状 | 根因 | 定位 | 修复 |
|---|---|---|---|
| 把模型从 A 换成 B 后任务成功率上升，直接归到"B 权重更强" | 忽略 Harness / 验证器 / 预算 4 个变量 | 替换实验没固定 Harness | 改做"同 Harness 换模型"测试：固定工具、指令、验证器、预算、超时，再换模型 |
| 在自己 Harness 中跑 SWE-1.7 复现不到官方 42.3% / 81.5% | SWE-1.7 训练在 Devin Harness，与自研 Harness 存在协议错配 | 工具名 / 参数语义 / 状态表达 / 恢复接口不一致 | 做"同模型换 Harness"测试：固定 SWE-1.7 与任务，记录工具映射失败、压缩恢复失败、改动范围与墙钟时间 |
| 用 FrontierCode 通用榜单对比自己的生产成功率 | 公开榜单对不同模型用不同 Agent 系统（Claude Code / Codex / Devin CLI） | 没拆"系统"与"裸模型" | 内部用同一 Harness、同一验证器、同预算跑模型 A/B；不要直接搬运厂商自报 |
| CursorBench 上某模型击败前任，但生产任务反而更差 | 榜单分数与生产运行环境解耦 | 厂商未披露 Harness，或 Harness 与生产不同 | 在自己任务集上做 A/B；Cursor 已披露 Grok 4.5 因训练数据污染在 CursorBench 排除 |
| 弱验证器通过、强验证器失败的轨迹很多，原指标主要奖励"测试变绿" | 验证器定义过窄 | 离线重评时强验证器拦截率高 | 补强验证器（回归、范围、测试有效性、代码质量），先做离线重评再决定是否换模型 |
| 模型在高预算下成功，固定预算后优势消失 | 预算与上下文策略没纳入变量 | 单一预算档位测试 | 至少跑两档现实预算，记录成功率、单位成功成本、压缩恢复成功率、P95 时延 |
| 团队用"SWE-1.7 涨了 14 个点"汇报升级依据 | 把"系统级增量"误读为"裸模型增量" | 报告只给榜单数字 | 报告必须写明：使用 Harness、工具、验证器、预算、超时、控制变量 |
| 跨 Harness 优势从 14 个点衰减到 3 个点 | 工具、状态或恢复协议错配 | 跑完"同模型换 Harness"测试 | 改 Harness：核对工具名 / 参数 / 返回格式 / 状态表达 / 恢复接口；增加 fallback 工具名映射 |
| 自压缩在原 Harness 工作，自研 Harness 跑出"摘要丢失约束" | 模型策略与运行时协议未对齐 | 压缩触发与恢复接口不匹配 | 复核自压缩的触发边界、原始状态持久化、摘要重建逻辑；如必要，先关闭自压缩或改用运行时编排 |
| 验证器能被 Agent 投机通过 | 沙箱没隔离评分路径 | 训练任务出现"刷分"行为 | 加固沙箱、引入隐藏测试与多评委、引入答案不可见的"破坏测试" |
| 离线复现 SWE-1.7 / Kimi K2.7 数字时大量偏差 | 缺第三方复现，依赖厂商自报 | 只跑一次、没公开 prompt 与 Harness | 做 A/B 与消融时记录 prompt / 工具 / 验证器 / 预算；最少跑 3 次取分布 |
| 团队报告"升级 SWE-1.7 后错误率上升" | 验证器从弱变强，或 Harness 协议不匹配 | 强验证器拦下表面正确但未处理隐藏约束的方案 | 不要立即回退模型；先回退到前任模型在同 Harness / 同强验证器下重测，确认瓶颈在 Harness 还是模型 |
作者：武子康的个人博客