SWE-bench Verified 82.6% 这个数字是编程智能体领域最近值得花时间细看的一个标杆。论文项目代号 openJiuwen核心不是又换了一个更大的模型也不是把测试用例喂回去让模型背答案而是把重点放在“长程编码智能体”的执行过程上提出了一套动态 harness 机制。这篇文章想清楚说一件事动态 harness 到底在调什么为什么它对长程编码任务的影响会比单纯提升模型推理能力更明显以及你如果想把这类思路落地到自己的工程评估里应该先准备什么、看什么、避免什么。适合看的读者有两类。一类是在做 coding agent、自动修 bug、自动实现 issue 的系统设计者你需要理解基准高分背后是什么机制而不是只被数字打动。另一类是把 SWE-bench Verified 当成团队模型能力验收指标的人你需要知道动态 harness 会怎样影响通过率免得上线后发现测试和真实形态差太多。先给判断openJiuwen 的 82.6%说明长程编码智能体的瓶颈已经从“单次推理对不对”转移到了“多次交互和动态验证的编排好不好”。这也意味着如果你只关心模型权重而不关心执行框架大概率无法在复杂任务上复现同等效果。1. SWE-bench Verified 到底在考什么为什么长程任务这么难1.1 从“生成代码”变成“解决一个完整的 issue”SWE-bench Verified 不是普通代码生成测试。它的任务是给智能体一个真实的 GitHub issue里面有 bug 描述、相关代码仓库以及一组测试用例。智能体需要自己读代码、定位问题、修改文件最后跑测试。通过标准是修复后的代码能通过隐藏测试。这和“根据自然语言生成函数”是两回事。前者是单轮输出后者是多步骤决策。每走一步都要决定改哪个文件、怎么改、要不要查文档、要不要先写测试甚至要处理编译失败、测试超时、依赖缺失这些外部问题。很多模型在单轮代码生成上表现不错一到完整 issue 修复就明显掉分。原因不是不会写代码而是不会规划。长程任务的难点在于状态空间很大反馈是延迟的中间任何一个错误决策都会影响最终结果。1.2 82.6% 这个分数的分量在 SWE-bench Verified 上60% 以上已经算很强的基线。如果达到 82.6%意味着智能体不只是碰运气修好了少数简单 bug而是能在大多数 issue 上完成多步推理和代码修改。但这个分数必须放在具体环境里理解。它通常是经过严格过滤的测试子集测试用例明确仓库环境可复现不会出现“issue 描述含糊不清”的情况。也就是说它衡量的是“在环境可控、输入相对规范的前提下智能体能否稳定解决任务”。所以看到高分时不要直接等同于“在真实生产仓库里也能这么强”。真实 issue 会更脏依赖版本更乱测试可能不完整甚至 issue 本身描述就是错的。合理理解是这个分数证明了动态 harness 配合强模型能把可控环境下的长程任务完成度推到很高水平。1.3 为什么动态 harness 会成为关键变量传统评测里模型生成一段代码然后拿测试用例一跑对就过错就挂。这个过程是静态的模型没有机会从失败中学习。但 SWE-bench Verified 这样的任务不一样模型可以多次修改可以读测试输出可以重新编译。这时候执行框架就成了决定因素。如果一个系统只能让模型“改一次”那每次修改的信息量很低如果系统能动态反馈测试结果、控制超时、管理仓库环境模型就能像工程师一样反复试错。openJiuwen 的论文标题里把“动态 harness”放到核心位置实际上是在强调长程任务的成绩是模型能力和执行框架的乘积。这也解释了为什么它值得专门写一篇解读。只看模型名和分数你不会知道提升来自哪里。只有拆开 harness 的机制才能理解 82.6% 是“怎么跑出来”的。2. 动态 harness 是什么和静态评测有什么本质区别2.1 静态 harness 的典型形态和边界最常见的评测流程是预先准备好仓库、写好测试命令模型输出一个 patch系统把 patch 打到仓库上然后执行 pytest。如果测试通过任务就算成功。整个过程只有一个反馈点就是最后的测试结果。这种静态方式的问题很明显中间过程全部不可见。模型如果把仓库改坏了系统不会告诉它“你的 import 语句写错了”只会给一个冷冰冰的“测试失败”。对于简单修复这足够但对于多文件改动、重构、升级依赖这类任务一次性的失败信息几乎等于没有。静态 harness 在工程上也很脆弱。不同仓库的启动方式不同有的需要初始化数据库有的需要安装额外系统依赖有的测试和代码文件有复杂路径关系。如果 harness 不提供任何中间状态管理模型根本无法在长时间任务中保持稳定。2.2 动态 harness 的核心是反馈循环openJiuwen 所说的动态 harness我理解不是某一段函数而是一套围绕智能体执行过程的反馈系统。它一般包含几个能力分阶段执行启动、编译、单测、回归测试分开跑而不是一把梭。动态反馈根据中间报错把报错类型、相关文件、失败用例重新组织成模型能读懂的上下文。超时和重试控制任务卡住时能中断而不是无限等待。环境恢复每轮修改后初始化或清理依赖避免状态污染。测试选择不总跑全量测试先跑相关测试通过后再扩展。这套循环的思路非常接近真实开发先做一个小改动立刻看结果根据结果调整下一步。如果每一步都能给模型更高质量的信息最终输出质量自然会提升。2.3 动态 harness 对模型行为的影响模型本身不会因为 harness 动态就自动变强但 harness 会改变模型能获得的信息边界。比如一个模型要修复一个 undefined variable 的报错。静态 harness 可能只会反馈“Task Failed”动态 harness 可以把 pytest 的 traceback、报错所在文件、当前分支状态都喂给模型。这种信息差异会让模型从“盲猜”变成“有方向地排查”。另一个影响是“容错性”。模型的第一版 patch 很可能有语法错误动态 harness 可以让模型读取到编译错误后再次修改。这个“再次修改”的能力比一次性生成能力更贴近实际开发。openJiuwen 的高分很可能主要来自这种迭代机制的优化。注意动态 harness 并不是把测试次数放大就有效。如果每轮反馈只是重复同一句“失败”模型会原地转圈。关键是反馈信息是否足够定位问题。3. 我理解的 openJiuwen 核心机制拆解3.1 任务分解与状态追踪长程 coding agent 面临的第一个问题是如何把一个大 issue 拆成可执行的小步骤。openJiuwen 这类方案通常会在系统提示或 harness 层加入一个状态跟踪器。它不只记录模型说了什么还记录当前仓库处于什么状态改动了哪些文件哪些测试已经通过哪些还在失败。这个状态不是简单的聊天历史而是结构化的执行进度。实际操作中状态追踪会直接影响模型下一步决策。如果模型不知道“上一个 patch 已经让测试 A 通过了”就有可能重复修改同一个方法浪费 token 和时间。动态 harness 从测试执行结果中提取状态再注入到下一轮模型上下文这种做法比单纯把历史消息拼在一起要清晰得多。3.2 基于测试用例的验证与修复循环高分系统的另一个关键设计是“验证优先”。模型改完代码harness 会运行一组精选测试然后对比输出。通过记录不通过把详细错误返回给模型。这个循环不是无限进行的。实现时通常会设置最大轮数比如 5 轮或 10 轮。轮数太少模型来不及修复轮数太多单任务耗时太长整体吞吐会掉得非常明显。建议从三条路径观察验证循环通过率提升曲线每轮通过多少新测试是不是越到后面越慢。修复有效性模型是否在重复同类错误还是真正解决了新错误。上下文长度增长轮数越多喂给模型的上下文越长最终可能超过模型窗口导致效果退化。3.3 感知上下文与文件修改的编排策略长程任务里一个经常被忽略的设计是“让模型知道应该改哪里”。SWE-bench 的 issue 描述通常不会精确到文件名模型需要自己探索仓库结构。openJiuwen 的做法很可能包括先在仓库里做检索找出可能的关联文件再让模型读关键文件片段最后才生成 patch。这个顺序很重要。直接让模型从头到尾读一个大型仓库既浪费 token也会让注意力分散。动态 harness 可以帮助模型做“信息筛选”。比如在反馈里告诉模型最近提交涉及哪些文件、失败测试引用了哪些模块、相似修复在历史记录里长什么样子。这些都算 harness 层面的信息增强不需要改模型权重却对最终分数有直接影响。这个设计给普通开发者的提示是如果你也在搭 coding agent不要急着上大模型先把你仓库里的文件索引、测试用例和依赖关系整理清楚。这样 harness 才可能把“有用信息”送到模型面前。4. 想复现这类方案评估环境怎么搭参数怎么定4.1 一个可运行的评估流水线通常包含哪些部分不管你有没有 openJiuwen 的完整代码只要想研究这类动态 harness都要先建一套评估流水线。常见组成如下模块作用常见实现仓库管理准备基础代码库和依赖Git 分支、Docker 镜像数据加载读取 issue、测试用例JSON、SQLite模型调用器把上下文发送给模型OpenAI SDK、vLLM、本地推理接口执行器跑测试、获取结果pytest、shell 脚本反馈处理器把报错转换成模型可读信息模板、traceback 解析状态存储记录每轮动作和测试输出日志文件、Redis这六个模块里最容易做也最容易被忽略的是“反馈处理器”。很多定制 harness 效果差不是因为模型不行而是报错信息没有格式化模型读不懂。4.2 关键配置项和各自影响配置项决定你是“能跑”还是“能跑得稳”。我建议上手时特别注意这几个最大迭代轮数典型值是 3 到 10。太低会压制修复能力太高会拖慢评测。测试超时单条测试超时用 60 秒还是 300 秒结果差异很大。长任务仓库要单独配置。相关测试选择范围先跑哪些测试决定反馈效率。可以按 git diff 文件推断。并发数一个评测集通常几百个 issue如果不做并发跑完需要非常久但并发太高又会造成资源争抢测试结果不稳定。上下文截断策略模型窗口有限需要决定哪些反馈可以压缩哪些必须完整保留。由于原始材料没有给出 openJiuwen 的官方参数上面这些需要你自己在复现时根据环境调整。不要把这些当成固定值。4.3 最小可复现流程怎么设计如果只是想验证“动态 harness 是否有用”不需要一上来就全量跑 SWE-bench Verified。可以先取 20 个 issue 做小样本测试。流程可以这样先选一个固定模型比如一个支持函数调用的开源模型或 API 模型。配一个最简单的静态 harness仓库 checkout 到指定 commit模型生成 patch执行测试记录通过率。记录 baseline。再配一个动态 harness增加中间反馈、失败重试、测试结果回传。跑同样 20 个 issue对比两者通过率。只要动态版本平均通过率明显高于静态版本就说明改装执行框架有价值。小样本跑完再扩展到全量数据能够少踩很多资源坑。注意小样本对比时尽量保证同一个 issue 的总轮数和超时设置一致否则只能说明配置差异不能说明 harness 优劣。5. 高分方案放到真实开发任务里会有哪些边界和坑5.1 真实 issue 的噪声会让动态 harness 失效一部分SWE-bench Verified 的 issue 通常是从真实仓库里筛出来的但筛选后的表述相对完整测试也明确。真实开发里的 issue 可能有几十条评论、错误复现步骤缺失、用户描述和实际行为不一致。这时harness 再动态也无法替代“需求确认”这一步。所以落地时不要把 82.6% 理解为“部署后 82.6% 的工单都能自动处理”。真实工单的自动修复率会受数据质量、测试完善度、权限限制影响通常会明显低于基准。5.2 动态 harness 会放大时间和成本风险每多一轮迭代就多一次模型调用也就多一份 tokens 成本和运行时间。静态 harness 可能一分钟跑完一个 issue动态 harness 可能变成十分钟甚至更久。这在研究和评测阶段可以接受到生产环境就必须做成本上限控制。建议在生产场景给每个任务设置硬性预算最大轮数、最大 token 数、最大运行时间。一旦达到预算强制结束并输出当前状态宁可让任务失败返回人工也不要让智能体无限漂移。5.3 分数高不一定代表代码风格好动态 harness 的目标是让测试通过不代表生成代码可读、可维护。有些高分 patch 可能绕过原有设计直接修改测试配置或者用不优雅的方式把错误吞掉。这在评测里能得分在 Code Review 里会被打回。如果团队要用这类方案辅助开发建议加入人工 review 环节同时记录每次 AI patch 的 diff 大小、改动文件数、是否有破坏性变更。低质量但能通过测试的 patch长期维护成本很高。6. 想深入研究和落地我建议先做这三件事6.1 先复现小样本把所有反馈路径打点记录不要急着追求 82.6%先跑通 5 个 issue 的完整链路。把每个环节的输入输出都记录成日志模型收到了什么、执行器返回了什么、反馈处理器最终发送了什么。你会发现很多问题不是模型笨而是反馈在某个环节被截断、丢失或格式化错误。这一步是最容易出成果的。打完日志你能知道动态 harness 的瓶颈在哪。可能是 traceback 太长超出模型窗口可能是测试超时设置太短也可能是有几个仓库的安装脚本根本没执行。6.2 把丢分点按类型拆开看而不是只看总通过率总通过率是唯一指标时你很难知道接下来该优化什么。建议将失败任务分成几类模型定位不到文件位置。模型改完代码但引入新错误。测试本身不稳定偶发失败。依赖环境不一致复现失败。上下文太长模型丢失关键信息。分类之后再针对性调整 harness。比如“定位不到文件”占多数就增强检索和文件索引能力“测试不稳定”占多数就先修依赖和超时不要动模型。6.3 把动态 harness 当产品来做而不是当脚本写很多项目最初只是写一个 Python 脚本调用模型、跑一下测试、记录结果。等任务规模变大脚本会立刻失控没有并发管理、没有失败重试、没有任务队列、没有输出命名规范。论文里的 harness 之所以能达到高分数一定不是只靠一段脚本而是有系统化的任务调度、状态管理和容错设计。普通项目也要尽早模块化。至少要把数据读取、模型调用、执行器、反馈处理器、日志存储拆成独立模块用统一的配置入口管理。这样后续换模型、改策略、加并发时才不用重写。7. 最后留几个可执行的判断标准这篇文章不是让你去抄一个固定方案而是帮你理解为什么同样一个模型在不同 harness 下会差这么多。如果你在评估 coding agent或者在设计自动修复系统下面几条可以作为验收参考单条任务能否在有限轮数内稳定完成而不是偶尔成功。报错信息返回给模型后模型是否真的会针对性修改还是原地打转。并发跑批量任务时通过率是否和单任务一致。日志能不能还原每一步决策和测试结果。失败任务是否具备人工继续处理的可读上下文。这五条都满足说明你的动态 harness 已经具备工程基础。如果都不满足那问题大概率不在模型而在执行框架本身。openJiuwen 的 82.6% 是一个很好的目标参照但不是终点。真正有价值的是它背后的思路让智能体在长程任务中看到更清楚的状态拿到更有用的反馈在试错中逼近正确修复。顺着这个思路优化自己的 harness比单纯追一个模型版本更值得投入时间。