news 2026/9/1 18:40:10

再迎突破!openJiuwen技术论文刷新Coding多榜单SOTA,并在WorkSwarm落地

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
再迎突破!openJiuwen技术论文刷新Coding多榜单SOTA,并在WorkSwarm落地

2026 年,编码智能体的竞争正在悄悄换赛道。

过去两年,比拼的重心一直是模型——谁的推理更强、谁的代码补全更准。但当越来越多团队用上同一批顶尖模型,一个值得关注的问题浮出水面:同样的大脑,换一套驱动它运转的执行架构,成绩到底能差多少?

针对以上问题,一篇名为《openJiuwen: Beyond Static Harnesses for Long-Horizon Coding Agents》的技术报告给出了强有力的参考,该报告结果直接刷新了SWE-bench Verified和Terminal-Bench 2.1两大榜单的SOTA——在500个真实GitHub issue构成的编程“黄金标准”中拿下82.6%,在真实终端环境复杂指令集中斩获87.19%,双双超越此前最强表现3个百分点以上。笔者了解到,报告背后的openJiuwen是华为 2012 实验室、华为云、终端、计算联合构建的开源 AI Agent 平台,报告同时指出其Coding Harness核心能力已在面向办公、编程的蜂群智能体WorkSwarm中落地,一键下载安装即可体验。

  • SWE-bench Verified上,openJiuwen 与榜单最强系统使用同一款模型(Claude Opus 4.5),最终成绩却高出3.4 个百分点,达到82.6%
  • Terminal-Bench 2.1上,openJiuwen 以87.19%的准确率超越 Codex、Claude Code、Terminus 2 等一众强力对手,比官方榜首高出3.39 个百分点
  • 更关键的是一组"同模型"对照实验:换上与榜首 Claude Code、榜二 Terminus 2 完全相同的Fable 5模型,openJiuwen 依然拿到84.04%,反超 Claude Code 的 83.8%,比 Terminus 2(80.4%)高出3.6 个百分点

同一个模型,差出来的分数,只能来自模型之外的那一层——Coding Harness,即真正驱动编码智能体理解任务、调用工具、诊断错误、持续推进的执行框架。

论文地址:https://arxiv.org/abs/2608.27969

Coding Harness 的局限:长时复杂任务,既考验结构对开发者是否友好,也考验运行时能否应对新情况

为什么很多 Code Agent 在演示视频里游刃有余,一到真实、复杂、长链路的任务里就掉链子?

根子在于:多数编码智能体沿用的仍是一套"静态"的 Harness——写死的流程、写死的工具列表、写死的上下文策略。这套机制处理三五步的短任务问题不大,但长程编码任务会带来两方面的压力,让它的短板逐渐显现:根子在于:多数编码智能体沿用的仍是一套"静态"的 Harness——写死的流程、写死的工具列表、写死的上下文策略。这套机制处理三五步的短任务问题不大,但长程编码任务会带来两方面的压力,让它的短板逐渐显现:

举个例子:一个 Agent 在修复某个仓库级 bug 时,改完代码后产生了新的类型错误,但静态 Harness 不会主动去检查,Agent 继续按原计划往下走,最终交付了一个看似完成、实则编译不过的结果——直到 CI 报错才发现问题。这类"长任务翻车"在真实场景里并不少见。

  1. 结构上越来越复杂,对开发者不友好。一个编码 Agent 要用到的能力持续增多——安全策略、代码记忆、任务规划、上下文管理、语义反馈、子任务委派、多智能体协作。如果这些能力各自为战,开发者每新增一种能力都得读懂并改动整个执行内核:新功能牵一发而动全身,排查问题要在纠缠在一起的逻辑里来回跳转,维护成本随能力数量增加而显著上升。
  2. 运行时越来越动态。任务推进过程中会不断冒出"事前无法预知"的新信息:代码改动后有没有新的语义错误、任务到底是真的完成了还是看起来完成了、上下文里哪些该留哪些该扔、这次踩过的坑下一次会不会重蹈覆辙。一套只会按预设剧本往前走的 Harness,难以应对这些信息。

openJiuwen 把这两类压力概括为Structural Composability(结构可组合性)Runtime Adaptivity(运行时自适应性),并围绕这两个方向,重新设计了整套执行架构。

结构可组合性:执行内核稳定不变,能力模块可插拔扩展,对开发者友好

openJiuwen 的第一处关键设计,是把"能力"和"执行逻辑"彻底解耦——开发者不必啃透整个执行内核,就能像搭积木一样组装、扩展系统,这正是结构可组合性对开发者友好的核心所在。

openJiuwen Coding Agent 整体架构:Inner Loop(观察—推理—行动—验证)与 Outer Loop(目标—计划—执行—评估—更新)之间,由一层可插拔的 Rail 组成稳定执行核心

Inner Loop / Outer Loop:同一套执行内核,覆盖从单个 Agent 到团队协作的所有场景。不论是独立工作的单个 Agent、被委派处理子任务的 Agent,还是 Swarm 团队里的一名成员,跑的都是同一套"内层负责观察—推理—行动—验证,外层判断要不要再来一轮"的执行引擎。开发者不需要为每一种使用场景重新设计一套调度逻辑。

Rail 机制:能力即插件,想接就接。安全策略、记忆管理、任务规划、工具治理、语义理解、人机交互……这些能力全部以 “Rail” 的形式挂载在执行生命周期的固定钩子上,通过优先级决定谁先谁后、谁能覆盖谁。给 Agent 新增一种能力,只需要声明一个新的 Rail,完全不用改动执行内核。这意味着很低的扩展成本:想加一条自定义规则、接一个内部工具,不必读懂整个框架源码,照着 Rail 的接口写一个 handler 即可。

Swarm Flow:不是一套固定的多智能体架构,而是一组可自由拼装的编排算子。它提供budget()(查询剩余预算)、parallel()(并发派发并等待收齐)、compact()(过滤空结果)、pipeline()(流式传递结果)、agent_session()(维护有状态会话)、human()(引入人工兜底)等算子,最后以return收口。示例中,一个编码 Agent 用它们拼出了"查预算 → 并行生成 → 过滤 → 流式复核 → 仲裁 → 必要时人工 → 返回"的流程——但这只是众多拼法之一,开发者可以按自己的任务自由重排、增减这些算子,不必绑定某一种协同架构。

Swarm Flow 编排示例:budget()查询预算 →parallel()并行生成候选 →compact()过滤空结果 →pipeline()流式复核 →agent_session()有状态仲裁 → 必要时human()人工兜底 →return返回结果。

运行时自演进:让编码 Agent 真正学会"边做边学"

架构再清晰,如果 Agent 不能根据执行中出现的新信息调整,长任务依然容易出问题。围绕这一核心问题,openJiuwen 给出了四套配套机制:

  • Goal Mode(目标驱动):不再是"跑够固定步数就收工",而是持续评估目标是否完成、是否被卡住,并把"完成判断"和"预算耗尽"严格区分开——既不会明明做完了还在空转,也不会明明卡住了还在硬撑预算。

  • LSP-Driven Passive Feedback(语言服务器被动反馈):每次代码改动,语言服务器产生的类型错误、悬空引用等诊断信息会被自动过滤、去重、排序后主动推送给下一步决策,不必等 Agent 自己想起来去查——相当于配了一位随时在线的 Code Reviewer。

  • Context Management(动态上下文管理):不再是把系统提示词加完整对话历史直接塞进上下文,而是根据实时压力做渐进式压缩、结构化摘要、死循环折叠,甚至把体积过大的内容卸载到外部存储、按需检索取回——避免长任务被上下文窗口拖累。

  • Self-Reflection(跨任务经验沉淀):任务完成后,系统会从执行轨迹中提炼可复用的经验存入经验库,供未来相似任务检索调用——相当于给 Agent 配了一本自己越写越厚的"复盘笔记"。模型参数没有变,但 Agent 会随着使用不断积累经验。

这四套机制彼此关联,构成一个此消彼长的权衡系统:更丰富的上下文能带来更好的决策,却会挤占有限的上下文预算;更严格的完成判断能减少"假装做完",却要多付出评估成本。openJiuwen 的价值,正是把这些原本要靠工程师逐个项目摸索的取舍,沉淀成了可配置、可组合的工程能力。

约束优化视角下的运行时自适应机制:在 Context Construction(上下文构建)、Diagnostic-Feedback Injection(诊断反馈注入)、Acceptance & Stopping(接受与停止)三个维度上,系统不断向"可行且理想"的运行时配置区域逼近。

Benchmark:SWE-bench Verified 与 Terminal-Bench 2.1 双双刷新 SOTA

openJiuwen 在两个差异极大的基准上系统评测了这套架构。

SWE-bench Verified(500 个源自真实 GitHub issue 的修复任务,考验仓库级长程软件工程能力):openJiuwen 使用 Claude Opus 4.5,Resolved 82.6%,超过当前榜单最强的同模型系统(79.2%)3.4 个百分点。值得注意的是,榜单最强的对比系统用的同样是 Claude 4.5 Opus——同样的模型,差出来的 3.4 个百分点,只能来自 Harness 本身。

Terminal-Bench 2.1(89 个容器化终端任务,覆盖软件工程、系统运维、数据处理、模型训练与安全等更广泛场景):openJiuwen 使用 GPT-5.6 Sol,Accuracy 87.19%,超过官方榜单最强结果(Claude Code + Fable 5,83.8%)3.39 个百分点,超过 Codex、Claude Code、Terminus 2 等多个强力系统。

同时还有一组"模型对齐"实验:把 openJiuwen 换成与榜首、榜二完全相同的 Fable 5,成绩依然是84.04%,比 Claude Code + Fable 5 高 0.24 个百分点,比 Terminus 2 + Fable 5 高出 3.64 个百分点。这组对比排除了"模型强弱"这个混淆变量——即便模型完全一致,Harness 本身的贡献依然十分明确。

数据分析:优势来自架构的两个设计维度

总分好看只是结果,把总分拆开看更有意思——正好能看出 Structural Composability 和 Runtime Adaptivity 这两条设计主线各自兑现了多少。

证据一:细看分类目,openJiuwen 在"工具密集型"任务上优势明显——这正是结构可组合性的红利。在同样使用 Fable 5 的模型对齐设置下:

  • file-operations(文件操作):openJiuwen 0.76,Claude Code 0.56,Terminus 2 0.52;
  • system-administration(系统运维):openJiuwen 0.889,Claude Code 0.778,Terminus 2 0.844;
  • 换成主力配置 GPT-5.6 Sol 后,system-administration 冲到0.956,software-engineering 达到0.908,data-science 达到0.950

这几类任务高度依赖工具——反复读写文件、操作终端、核对环境状态。openJiuwen开箱即用的操作型工具加上 Rail 提供的统一执行接口,让 Agent 不必为每个任务临时现造工具,省下的执行轨迹能更多用在推理和验证上——结构可组合性由此兑现成了具体的分数差距。

模型对齐设置(均使用 Fable 5)下,openJiuwen 在>从论文到应用:能力开源并集成至WorkSwarm,也进入华为云码道

这篇论文的价值不只是刷新了两个榜单,而是这套架构从设计之初就是为了被真正用起来——它已经开源,并封装进了可以直接安装使用的产品。

对开发者而言,openJiuwen SDK 把结构可组合性落到了实处:Rail 机制让你无需读懂整个框架源码就能插入自定义能力;Inner Loop/Outer Loop 统一的执行语义,让单 Agent 脚本可以平滑扩展为多智能体 Swarm 团队;Goal Mode、LSP 被动反馈、上下文管理等工程能力开箱即有。

对普通用户而言,WorkSwarm 支持 HarmonyOS / Windows / Mac 一键安装下载。打开应用后像聊天一样描述需求,Agent 会自动读文件、搜代码、跑 Shell、装依赖、改代码、跑测试,直到任务完成。驱动它的,正是拿下 SWE-bench Verified 82.6% 与 Terminal-Bench 2.1 87.19% 的同一套 openJiuwen 架构。

这也是 openJiuwen 团队反复强调的一件事:Coding Harness 不该只掌握在少数团队手中,它应该像操作系统一样,开发者能扩展,普通用户能直接用。

同时,openJiuwen社区与华为云码道深度协同,作为码道的社区联创版本,也持续将开源框架中的优秀能力集成到码道中。

WorkSwarm 官网:https://www.openjiuwen.com/workswarm,支持 HarmonyOS / Windows / Mac 一键下载安装,安装后即可通过自然语言对话方式驱动 Agent 完成任务。

结语:编码智能体竞争的关键已不仅是模型能力

Terminal-Bench 2.1 和 SWE-bench Verified 的难点在于,Agent 必须在真实环境里连续做对很多件事:理解任务、诊断错误、管理上下文、判断何时收手、把结果真正交付出来。模型决定的是 Agent 的基础智力,而 openJiuwen 用两个榜单证明的是:真正决定 Agent 能走多远的,是那套包裹在模型外面、看不见却始终在起作用的 Coding Harness。

这一次,openJiuwen 论文公开、代码开源、产品可装。从一篇技术论文,到两个权威基准双双刷新 SOTA,再到一次下载安装就能用上的桌面体验,验证的始终是同一件事——Harness,不该只活在论文和榜单里,它应该装进每一个人的电脑。一键下载安装 WorkSwarm,立即体验吧!

相关资源:

  • 论文地址:https://arxiv.org/abs/2608.27969

  • openJiuwen 官网:https://www.openjiuwen.com/

  • WorkSwarm GitHub:https://github.com/openJiuwen-ai/jiuwenswarm

  • WorkSwarm AtomGit:https://atomgit.com/openJiuwen/jiuwenswarm

  • Swarm Skills Hub:https://swarmskills.openjiuwen.com/

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/9/1 18:38:46

2026年英语作业批改软件怎么选?三款主流工具实测解析

【摘要】进入2026年,英语作业批改软件已从单纯的查错工具,升级为覆盖作文批改、口语评测与学情分析的AI教学辅助系统。本文基于一线教学场景,实测天学网AI智能批改、讯飞AI学习机和批改网三款产品,重点拆解天学网97.2%批改准确率、…

作者头像 李华
网站建设 2026/9/1 18:38:30

用Python和OpenAI API构建科研工作台连接器:从数据到模型的可复现链路

做科研工具链集成的人经常会遇到一个现象:模型能力已经够用,但真正跑不起来的是研究数据与模型工具之间的衔接。文献在 PDF 里、实验记录在 Excel 里、结果散落在聊天窗口里,每次要把数据送进模型,都要写一段临时脚本。OpenAI Ros…

作者头像 李华
网站建设 2026/9/1 18:38:18

ChatGPT双重曝光提示词工作流:从PS手势到语义描述的转变

我最早被双重曝光吸引,是在刷设计作品时看到一张人像侧面剪影,里面藏着整片星空。当时第一反应是,这得打开 Photoshop,抠图、叠图层、调蒙版,没有一个小时下不来。后来我用 ChatGPT 的图像生成功能试了一次&#xff0c…

作者头像 李华
网站建设 2026/9/1 18:37:49

论文被说方法陈旧?研究方法更新的4步清单

“你的研究方法有些陈旧,建议更新。”——这类反馈常出现在开题答辩、中期检查或盲审意见里。方法陈旧不等于论文作废,而是研究设计的某个环节没跟上领域内近几年的进展。与其焦虑推倒重来,不如按步骤把"更新研究方法"这件事做扎实…

作者头像 李华
网站建设 2026/9/1 18:35:44

用Python量化市场温度:从估值分位到泡沫提示

8月13日,常士杉的一场私募直播,把两个词重新推到了讨论中心:泡沫、市场温度。标题写得很直接,“中国大爱泡沫中洗澡”这种说法本身就有强烈的情绪色彩。但无论直播间里具体说了什么,真正值得留意的,是“如何…

作者头像 李华