还没有正式动手调模型的人可能会先被“openJiuwen 论文里那个 82.6%”吸引住。但真正接触过编码智能体尤其是拿它跑过长任务的人更关心的其实不是这个数字本身而是它背后那套叫“dynamic harness”的东西到底做了什么。过去大半年里我在多个项目里反复踩过同一个坑一个写代码的 agent 在小任务上表现挺好一旦让它持续跑二十分钟、涉及多文件修改、要自己看测试输出、再决定下一步怎么写它就开始迷路。要么反复改同一个函数要么把上下文越滚越乱要么在某个子任务上耗光了预算。这不是模型不够聪明而是外层没有一套合适的机制来承接“长程”这件事。openJiuwen 这篇工作最有价值的点就是把“harness”这个平时容易被忽略的概念重新拉回了讨论中心。它不解决模型“会不会写代码”的问题而是解决模型“怎样在一个长时间任务里持续写对代码”的问题。先说结论动态 harness 解决的不是单次生成的准确率而是长程编码流程的可控性SWE-bench Verified 82.6% 是这个机制有效的结果不是它的全部价值对它最大的误解是把它当成一个“安装完就能用”的工具而不是一种需要理解和适配的运行时设计。这篇文章会把论文里的核心设计拆开结合自己做编码智能体的实际经验聊清楚harness 和 agent 到底什么关系动态 harness 动在哪里为什么它能在长任务里稳住 agent以及当我们想在本地折腾一个类似方案时应该从哪里入手、最该注意什么。1. 先搞清楚harness 和 agent 根本不是一回事在各类技术社区和热词里harness、agent、workflow 这三个词经常被混在一起。很多人问“harness 和 agent 有什么区别”其实从工程视角看它们是明确的两层。1.1 Agent 是大脑harness 是身体和神经系统一个编码智能体如果只有模型本身它能做的是“根据输入生成代码”。但在真实任务里模型需要调用工具、读取文件、运行命令、看报错、再修改代码。这一整套行为其实由一个外层运行时来承载谁来决定调用工具谁来把工具输出塞回上下文谁来控制终止条件谁来在 agent 卡住时切换策略。这个外层运行时就是 harness。打个比方agent 是团队里那个做决策的人他会说“现在应该去读一下测试文件”“这个函数看起来有问题改一下签名”。但真正让他能接触到文件、能执行命令、能看到结果的人是 harness。在常见实现里这个角色可能叫 runtime、agent loop、execution loop或者直接用 LangGraph、OpenAI Agents SDK 之类框架里的顶层调度逻辑。但论文里明确强调 harness 不是一个“工具调用器”它决定了 agent 的感知范围和行动策略。1.2 静态 harness 和动态 harness 的分界线在哪传统 agent 实现中外层循环往往是静态的模型输出一次工具执行一次结果返回一次循环继续。这种模式在处理短任务或单轮工具调用时没有问题但长程任务会暴露问题上下文无限膨胀、决策依赖的信息错位、策略无法根据真实进度调整。动态 harness 的做法不同它不只是机械地搬运消息而是会观察任务状态更新内部的“任务表征”然后动态决定下一步把哪些信息暴露给 agent。理解这一点非常重要。它把“agent 自己决定自己做什么”这件事升级成了“harness 先判断当前该给 agent 看什么agent 再决定下一步怎么做”。后者明显更适合长时间、多步骤、需要持续纠偏的编码任务。这也是为什么 openJiuwen 论文把“dynamic harness”和“long-horizon coding agent”放在一起讲harness 不是模型内部的强化层而是模型外面一个持续运行的控制层。1.3 热词里的“deepseek harness”其实反映了同样困惑搜索热词里高频出现“deepseek harness 安装”“deepseek harness 教程”这类表达大家真正想解决的问题是我能不能用本地开源模型搭一个自己可控的编码 agent这一步看起来是“给模型买一个外挂”但本质上是在问“我应该怎么设计 harness”。实际情况里使用开源模型搭建 harness重点不是“模型强不强”而是“harness 能不能把模型的能力稳定传导出来”。模型再强如果外层循环里上下文被塞爆了、或者工具反馈没有被正确组织结果一样是坏的。这正好呼应 openJiuwen 的核心观察agent 能力的上限不只是模型参数决定的还由 harness 的感知策略和上下文管理方式决定的。2. 动态 harness 到底“动”在哪里如果只记住一个词那就是“动态”。但动态并不是指“每次生成不同内容”而是指 harness 会根据任务执行过程中的状态变化不断调整它对 agent 的“呈现方式”和“信息供给”。2.1 从固定扫描到启发式观察很多传统 agent 方案在上下文管理上采取“有信息就往里塞”的策略。比如只要工具返回了内容就 append 到对话历史里。刚开始还行但长任务跑下来上下文会变成一条越滚越长的河流早期读过的文件内容、已经过时的错误信息、不再相关的中间结果全都被保留着。openJiuwen 的做法是给 harness 加了一层“启发式观察”它不只看“工具返回了什么”还会判断“这条信息对当前的 agent 决策是否有价值”。这可能包括筛选文件中变动过的片段、保留和当前目标相关的报错、压缩已经完成的子任务描述。这样做的直接效果是agent 始终面对的是“当前任务相关度最高的信息窗口”而不是一个无限增长的日志堆积。2.2 动态更新使 agent 的“世界模型”始终对齐真实状态编码任务最麻烦的一点是文件系统、测试输出、代码运行结果是持续变化的。如果你让 agent 看一眼初始状态然后让它一口气写完十个文件它很快就会基于旧状态做错误决策。动态 harness 的另一个关键机制是它会持续维护一份“任务状态表征”并在每次工具调用后刷新。agent 基于最新状态做决策而不是基于最初的快照。我自己的实际体验是这一步对模型的效果影响非常大。尤其当模型需要基于测试失败信息来定位 bug 时如果 harness 没有把“上一次运行之后发生了哪些变化”正确地归纳给模型模型就会反复猜测。一句话概括静态 harness 把 agent 当一个“能调用工具的大模型”动态 harness 把 agent 当一个“有工作记忆、会定期更新计划的执行者”。2.3 不是把所有智能都塞进模型而是把感知和调度放在模型外这个设计选择其实隐含了一个判断模型上下文是稀缺资源所有信息都往里塞等于让模型在大量噪音里做决策。动态 harness 把“什么信息重要”的筛选放在模型外用规则、启发式、甚至更小的模型来完成从而让主模型把有限上下文用在真正的推理上。对大多数本地部署场景来说这意味着即使不用很大规模的模型只要 harness 设计得当也能在长程任务里保持不错的效果。这比“堆模型规模”更容易落地。3. SWE-bench Verified 82.6% 到底是怎么来的SWE-bench Verified 是目前评估编码智能体在处理真实 GitHub issue 时能力的常用基准。它要求 agent 理解 issue 描述、定位代码、修改文件、运行测试并且修复后的代码能通过隐藏测试。openJiuwen 论文报告的成绩是 82.6%这个数字放在长程 agent 里已经属于很亮眼的位置。3.1 这个分数不是模型单项能力的功劳从论文的工作重心看这个结果应该被理解为“模型 动态 harness 评测流程”三者共同作用的效果。82.6% 不代表模型本身能在任意编码任务里都达到这个水平而是说在 SWE-bench 这类“给定 issue、修改代码、跑测试”的闭环任务里这套组合能够稳定完成。这意味着什么如果你只换一个模型不加 harness很可能拿不到同样的分数。如果 harness 的设计一样但模型不够强分数也会掉。如果你的任务类型跟 SWE-bench 差异很大这个分数不能直接外推。3.2 数据增强和评测细节也要打折扣看从论文公开信息可以推断成绩背后大概率包含数据增强、agent 迭代、多次采样选择最佳结果等常规策略。这在编码 agent 研究里很常见但我们在读论文时要区分清楚如果 82.6% 是 best-of-n 的结果那实际单次执行的成功率可能没那么高。如果构建过程中用了测试输出作为反馈信号那就要求 harness 能快速拿到运行结果这对工程部署提出了要求。评测环境里的依赖安装、测试命令、任务过滤逻辑都会影响分数的可复现性。我个人更建议把 82.6% 理解成“这套组合可以达到的水平上限参考”而不是“你本地随便搭也能稳定复现”。3.3 单点 benchmark 不等于生产环境质量SWE-bench Verified 的任务是孤立的给定一个 issue修好它跑测试。但真实项目里issue 之间有关联代码库很大依赖很复杂环境不是标准 docker 镜像测试也经常不稳定。一个在 benchmark 上表现很好的 agent真正放到业务项目里还需要经过权限控制、日志、多级代码审查、人工抽检等环节。所以我的判断是这个分数最大的价值不是“我们比别的 agent 强多少”而是证明了“动态 harness 对长程 agent 的增益是显著的”。它给了后来者一个方向与其只换更大模型不如先检查自己的 harness 是否足够动态。4. 从论文到工程动态 harness 的落地思路论文是研究工程是实践。如果你正在写自己的编码智能体这里是我建议的落地路径不一定非要复现 openJiuwen 的所有细节但核心思想可以迁移。4.1 第一步先跑通一个最小 harness不需要一开始就上复杂框架。一个最小可用的 harness 至少做四件事接收任务描述。循环调用模型直到模型给出“完成”信号或达到最大轮次。提供工具调用接口读文件、写文件、执行命令、跑测试。将工具输出按结构化格式返回给模型。这个阶段的目标是让流程闭环模型能改代码能运行测试能根据测试结果继续修改。不要一开始就优化上下文策略。4.2 第二步区分 pipeline 和 state machine很多从 LangChain 过来的开发者容易把代码写成固定 pipeline先 A 步骤再 B 步骤再 C 步骤。但长程 agent 需要的是状态机式的控制不是每一步都走固定顺序而是根据当前状态决定下一步动作。你可以在工程实现里用while循环加一组状态切换函数来实现。核心是有一个State对象里面记录当前目标、已完成子任务、最近工具输出、未解决的错误。每一轮循环先更新 State再决定下一步调用什么工具、给模型看什么信息。这个模式就是“动态 harness”的工程雏形。4.3 第三步给 harness 加监控和日志动态 harness 一旦跑长任务最怕的是不知道 agent 在做什么。建议从第一步开始就给每个关键节点加结构化日志当前轮次。agent 的决策理由。调用了哪个工具。工具返回结果的摘要。上下文窗口用了多少。当前状态变化。这样出问题时你能迅速定位是哪一层出了问题模型判断错了还是工具执行失败了还是 harness 上下文裁剪太激进。一个排查顺序可以参考看日志里 agent 是否在重复同样的动作。看上下文里是否丢失了关键文件内容或测试结果。看工具调用是否因为权限、路径或环境问题失败。看状态更新逻辑是否没有把新信息同步进去。最后再考虑模型本身是不是不适合这个任务类型。很多长程 agent 问题最后都落在第 2 和第 4 条。4.4 第四步做上下文动态压缩当任务超过 10 到 20 轮工具调用后上下文一定会变大。动态压缩的目的不是把内容删掉而是让模型看到的信息保持精简旧文件内容如果没变化就不要每轮都带上。已经完成的子任务可以压缩为一句“已完成xxx”。测试失败信息只保留最后一次失败输出。如果文件很大优先给模型看 diff 而不是全文。这一步也是最难调的。压缩策略太激进模型会丢失信息太保守上下文还是会爆。建议从“只保留最近 N 轮和当前 pending 信息”开始逐步根据任务类型调参。5. 动态 harness 的适用边界什么时候该上什么时候别折腾不是所有任务都需要动态 harness。理解边界才能避免把简单问题复杂化。5.1 适合动态 harness 的场景任务需要多文件修改agent 需要持续感知项目全貌。任务需要根据测试输出反复调整属于“执行-观察-修改”的闭环。任务时长超过 15 分钟agent 必须维持长期上下文。团队需要记录 agent 的决策过程便于审计和调试。5.2 不适合动态 harness 的场景单次代码生成、单文件补全普通模型直接输出就行。只把 harness 当“提示词模板”没有状态管理和日志动态 harness 的收益很有限。团队没有日志和监控能力就先别追求复杂 harness跑通最小闭环更实在。判断标准很简单你的任务里agent 需不需要“记住之前发生了什么、并根据新信息调整下一步”如果需要harness 值得投入如果不需要普通循环就够了。5.3 社区里“deepseek harness”实际在解决什么问题从热词中能看到大家围绕 deepseek harness 搜索安装、插件、桌面版、源码解读等这反映出一个明显趋势越来越多个人开发者不想依赖闭源平台而是想基于开源模型自己搭一套“可观察、可改、可复用”的编码 agent 工作台。这类探索的实践路径通常是先用开源模型跑通基础 agent 循环再在 harness 层加上项目管理、上下文压缩、工具权限控制等功能。实际着手时我建议按“最小闭环 → 状态管理 → 日志监控 → 上下文优化”的顺序推进不要一上来就做插件市场或 GUI 界面。我这里插一句使用建议如果看到某个“harness 插件”声称安装了就能获得论文同款效果先别急着下单。先看它是否实现了动态状态更新和工具反馈整理这是价值核心其他都是辅助。6. 从动态 harness 到 agent 工程化最后几块拼图openJiuwen 论文把动态 harness 这件事摆到了台面上但真正要把这套思路放进项目不止是实现一个循环这么简单。6.1 可观测性一个 agent 跑完一个长任务你至少要能回答三个问题它做了什么为什么这么做哪一步出了问题没有结构化日志和 trace动态 harness 再聪明也只是个黑盒。建议日志里至少包含每轮 action 的名称、输入摘要、输出摘要、context 占用和耗时。6.2 沙箱环境与依赖管理编码 agent 要运行测试就必须有可控的执行环境。可以是一个 Docker 容器也可以是一个独立的虚拟环境。关键是要做到每次任务启动的依赖一致、文件路径一致、退出后清理干净。这一块如果没有做好agent 在测试时遇到的错误往往不是代码 bug而是环境不一致。6.3 失败恢复与人工介入长任务执行过程中一定会出现模型跑偏、工具崩溃、上下文超限等情况。动态 harness 需要在某些节点停下来等待人工确认。比如 agent 反复修改同一个测试却仍然失败时harness 应该有一个“超过 N 次尝试后暂停并向用户询问”的机制。这里不是说 harness 越自动越好。它真正要做的是让自动化可控、可中断、可恢复。6.4 成本与速度动态 harness 通常比普通 agent 循环消耗更多 token因为它要保持状态更新、记录日志、做上下文压缩。如果每次任务都要跑很久成本会线性上升。建议小任务用小模型只有长任务才上大模型。上下文压缩和过滤要放在本地做不要每次都发给模型。测试运行要加超时控制避免 agent 卡在某个测试命令上。7. 最后说几句关于“harness 工程”的大白话热词里频繁出现“harness engineering”这不是一个新造概念只是在长程 agent 兴起之后大家重新意识到它很重要。很多人花大量时间调 prompt、换模型却忽视了控制循环本身的设计这是走偏了。我的总体判断是动态 harness 的价值不是让一个模型变聪明而是让一个聪明的模型在有约束的长任务里不犯傻。这句话不是贬义。相反我认为这是 agent 落地最关键的工程问题之一。大模型的单点能力越来越强但单点强不代表整体可靠。真正把 agent 推入生产环境的是外面那套能感知、能记录、能纠偏、能止损的机制。如果你现在正在搭自己的编码 agent不妨从 openJiuwen 的思路里借鉴三件事让 agent 看到最新状态过滤掉与当前目标无关的信息在关键节点保留人工控制。这三件事做扎实即使模型不是最强整个系统也已经能稳住很长一段时间。这个方向值得长期关注。因为接下来编码智能体之间的差距很可能不再只看模型参数而要看谁能把 harness 这层工程做得好。