openJiuwen: Beyond Static Harnesses for Long-Horizon Coding Agents —— 精读

论文链接：https://arxiv.org/abs/2608.27969

代码仓库：https://github.com/openJiuwen-ai/jiuwenswarm

发表时间：2026 年 8 月 28 日（arXiv:2608.27969v1）

机构：华为技术有限公司 openJiuwen Team（纯企业出品，18 位核心贡献者的开源项目）

领域标签：cs.AI，智能体系统 / 软件工程 / Agent Harness

一、论文背景

1.1 Harness：从薄包装到系统层

LLM 正把自动化软件工程从单轮代码生成推向长时程编码智能体——在扩展的轨迹上与仓库、工具、执行环境持续交互。这类任务的难点不止于每步动作正确，还在于代码状态、诊断信息、任务进度、相关上下文都在运行中不断演变，智能体必须在全程保持行为连贯。

当智能体纳入规划、记忆、验证、上下文工程、委托与多智能体协调等能力后，agent harness（智能体支架——决定这些能力如何组装、执行如何被控制的系统层）不再是 LLM 外面的一层薄工具包装，而本身成了一等系统问题。类比操作系统之于应用程序：模型是 CPU，harness 就是调度、内存、IO 管理的内核。

1.2 现有 harness 的两大未解问题

论文观察 Pi、DeepSeek Harness、DeerFlow、Codex、Claude Code 等代表性系统后提炼出两个互补挑战：

挑战一：开发者复杂度（结构问题）。插件、钩子、子智能体、工作流算子各自可扩展，但把它们组合成不同协作模式时会引入碎片化的执行路径与定制的编排逻辑——可扩展性本身不等于易于组织与组合。每换一种智能体拓扑就要重写一套执行语义，这是工程负担的根源。

挑战二：执行不确定性（适应问题）。复杂编码任务的关键证据只在解题过程中浮现——语义诊断、测试结果、中间产物、上下文相关性的变化。执行前做出的决策会逐渐过时。harness 必须用新证据去调整框架控制的决策：上下文构建、语义反馈、任务延续与停止。

1.3 论文的核心主张

把这两个挑战命名为Structural Composability（结构可组合性）与 Runtime Adaptivity（运行时适应性），并主张：静态的 harness（组装好就一成不变）不够，需要在这两个维度上同时系统化设计。这呼应了业界从 prompt engineering 到 context engineering 再到 harness engineering 的演化脉络——当模型能力趋同，竞争重心向系统层转移。

二、论文定位和关联工作

2.1 三条相关研究谱系

谱系一：编码智能体架构与支架。SWE-agent 开发仓库交互专用接口；CodeAct/OpenHands 提供可执行动作空间与通用开发环境；AutoCodeRover 做程序结构感知定位；LingmaAgent 强化仓库探索；RepairAgent 做自主修复规划；Agentless 走固定修复管线；Trae Agent 做测试时生成与选择；Swarm Skills 把多智能体角色/工作流/协调约束做成可移植的自演化规范。这些工作改进特定接口、能力或工作流，较少把 harness 当作组合异构能力、跨拓扑复用执行语义的可复用基座——这正是 openJiuwen 的差异化定位。

谱系二：长时程运行时行为。实证研究识别出重复动作模式、失败轨迹更长且方差更大的现象；Ledger 把执行状态外化（观察、修改、历史动作）并用它调解冗余命令；Collaborative Optimization 联合优化工作流结构/提示/示例/路由。这些工作聚焦特定执行状态或工作流优化机制，openJiuwen 则追求更广的『证据驱动运行时调整』框架。

谱系三：上下文管理。SWE-AGILE 压缩旧推理保留近期交互；SWE-Pruner 选择任务相关上下文；AgentDiet 移除冗余过期轨迹内容；简单观察掩码也能达到有竞争力的效率；P3 联合优化系统/用户提示并做查询依赖的在线提示。这些方法主要作用于给模型看什么，而长时程执行还产生语义反馈、进度信号与可复用经验，需要超越模型输入适配的运行时适应。

2.2 定位总结

定位结论：openJiuwen 不与单点机制竞争，而是提供承载这些机制并可组合扩展的统一基座——已有的上下文管理方法原则上可以作为 Rail 或处理器接入该框架。

三、问题定义

3.1 从具体场景到抽象问题

具体场景：开发者要构建一个能自己查代码、改代码、跑测试、决定何时完成的编码智能体系统，且希望它能从单智能体扩展到多智能体、还能在长任务中随证据调整行为。

论文把两个挑战抽象为一对正交维度：

• 结构维度：能力与执行单元能否在共享执行基座上组装重构，而不必为每种配置（单智能体/子智能体/多智能体流）配一套执行架构？——开发者侧问题；
• 适应维度：运行时证据能否在不改变模型参数的前提下动态影响框架控制的决策？——任务侧问题。

第二个维度的形式化尤其值得注意。论文用『受限在线优化作概念透镜』：在运行时控制时刻 t，框架可用信息 M_t（历史、诊断、目标状态、上下文压力、资源状态）经上下文构建产生 c_t = κ_t(M_t)，固定模型策略 π 依 c_t 行动；框架控制的运行时配置 Θ_t = (κ_t, Φ_t, ι_t) 分别控制上下文构建、语义验收/停止、诊断反馈注入。目标是轨迹级概念价值 J(Θ_{0:T}) = E[Σ(r_t − λ·cost_t)]，随证据按 Θ_{t+1} = A(Θ_t; M_t) 演化，受三条约束：C1 上下文预算 |c_t| ≤ B_ctx；C2 诊断须经机械产生与过滤才可注入；C3 遵守语义验收与配置停止边界。

3.2 抽象的精妙之处

这个形式化有意强调两点。其一，适应性改变的是框架状态而非模型参数——与训练路线（改 π）正交，两条路可以叠加；其二，公式是概念透镜而非数值算法——论文诚实声明具体机制实现的是『朝向更高效用可行配置的结构化在线调整』，不直接求解通用优化程序。这种『形式化用于组织思想而非假装求解』的态度在系统论文中相当克制，也划定了主张的边界：它是设计原则的统一表述，不是收敛性保证。

四、问题解法

openJiuwen 的解法沿两个维度展开，共享同一个执行基座。

4.1 结构可组合性：两层基座 + Rail + Swarm Flow

Inner Loop / Outer Loop 分层执行。类比操作系统的进程内指令循环与调度器：Inner Loop 负责模型—工具交互（构建上下文 → 调用策略 π → 执行工具 → 记录观察 → 暴露给后续步骤，ReAct 式有界交互），生命周期回调在模型与工具边界触发，让 Rail 能观察或修改执行而不把能力逻辑嵌进循环本身；Outer Loop 负责任务级延续——每完成一次 Inner Loop 调用为一轮，评估是否终止或继续，延续决策由可组合评估器（语义完成信号、资源上限、用户条件）供给，并在边界处理异常与有界重试，把基础设施故障与额外推理分开。运行中到达的输入在后续执行边界并入而非篡改进行中的调用——两层各自保持控制粒度。

Rail：有序能力组合。横切能力（安全、记忆、规划、上下文工程、语义反馈、委托、人机交互）需要执行可见性但不应成为核心执行算法的一部分。Rail 抽象为三元组 ρ = (H_ρ, f_ρ, p_ρ)——挂载的生命周期钩子子集、处理器、声明优先级；在每个钩子上按优先级执行、同级确定性地消解。组合顺序成为显式元数据而非执行循环里能力分支的偶然结果——加删一个能力只改 Rail 配置、不动两层循环。类比微内核系统的可加载模块或浏览器的插件管线：核心极小，一切皆可插拔。

能力门控。g(ρ,u) ∈ {0,1} 决定 Rail ρ 对执行主体 u 是否可见，主体级能力配置 R(u) = {ρ | g(ρ,u)=1}。同样的门控也适用于工具——独立智能体、委托子智能体、leader 与其他参与者共享执行基座但暴露不同能力。这支持有界递归委托、渐进能力披露与角色隔离。

Swarm Flow：可组合多智能体协调。不预设固定多智能体架构，而是提供协调算子让开发者搭任务专属的协作流：budget() 暴露剩余执行预算、parallel() 并发分支并同步、compact() 过滤无效空结果、pipeline() 流式衔接阶段、agent_session() 跨阶段维护有状态会话、human() 引入可选人工干预、return 终止并暴露结果。论文的示例 Coding Agent 中，leader 查预算决定 worker 数量 → parallel 生成独立候选 → compact 去空 → pipeline 流经评审 → agent_session 的仲裁者聚合候选与评审反馈 → 信心不足时 human() → return。从单智能体到多智能体只改变组合方式，不引入第二套执行引擎——这是结构可组合性的完整兑现。

4.2 运行时适应性：固定模型周围的四个机制

Context Management（κ）。上下文不是系统提示与完整历史的静态拼接，而是按当前压力、任务状态、内容结构处理：渐进压缩（m^(0)→m^(1)→…→m^(L)，近期信息保真度优先，机制含对话摘要、增量压缩、全会话压实）；结构感知缩减与死循环塌缩（diff/日志/表格先过确定性结构处理器再上模型摘要；重复无产的推理或工具调用模式被塌缩防止空耗预算）；外置与检索（大工件全量外置、活跃上下文留紧凑摘要或句柄，遵循 full content → 结构/语义摘要 → 紧凑句柄 → 按需检索的渐进信息层级，对话检索可由粗到细）；与推理层协同的会话亲和与 KV-cache 复用。

Goal Mode（Φ）。语义完成评估器 Φ_t(M_t) ∈ {continue, complete, blocked}，与配置硬上限 g_cap（最大尝试/时间/资源）分离：T = inf{t : Φ_t ≠ continue 或 g_cap = 1}。这一分离区分了成功完成/语义阻塞与资源耗尽。支持自评估（执行智能体的完成报告）、独立评估（独立评估路径）与混合三种策略，共享同一接口。它管当前任务内，与跨任务的 Self-Reflection 相区分。

LSP-Driven Passive Feedback（ι）。语言服务器协议（LSP）在相关代码变更后机械产出语义诊断，经 RankDedupLimit(Δ(s_t); K_file, K_sem) 排序去重限量后注入后续执行（M^+{t+1} = M{t+1} ∪ ι_t(δ_t)）——实现约束 C2。被动诊断（变更后自动浮现）与主动查询（定义/引用/调用层级）的区别在控制权。诚实边界：机制限于分析基础设施暴露的性质（类型错误、符号关系、静态诊断），不建立架构质量或端到端正确性。

Self-Reflection。任务完成后从轨迹 h_τ 提取经验 X_n = Ψ(h_τn)，经 U 验证/去重/合并/修订入持久经验库 E_{n+1}；后续任务按查询检索 R_{n+1} = Retrieve(E_{n+1}, q_{n+1}) 并入初始信息。检索不绕过 Context Management——经验仍可能被压缩、摘要、推迟或省略。这是不改模型参数的跨任务非参数适应。

4.3 全景表

五、评估指标与实验证据

5.1 指标体系与基准

• SWE-bench Verified Pass@1：500 个人工验证的真实 GitHub issue 任务，产出的补丁须通过官方测试套件——仓库级长时程软件工程能力的金标准；
• Terminal-Bench 2.1 Accuracy：89 个容器化终端环境的多样任务，按任务专属验证器判分——更广的工具驱动长时程执行。

配置：SWE-bench 用 Claude Opus 4.5（high 推理强度）；Terminal-Bench 主结果用 GPT-5.6 Sol，另用 Fable 5 做模型对齐对比（与 Claude Code、Terminus 2 同骨干）。每个配置内提示、工具、模型配置固定。

5.2 主结果

Terminal-Bench 2.1（表 1 摘选）：

超最强官方榜单（Claude Code 83.8%）3.39 个百分点；模型对齐下 84.04% 比 Claude Code 高 0.24、比 Terminus 2 高 3.64。

SWE-bench Verified（表 2 摘选）：

超最强入选榜单结果 3.4 个百分点。关键对照：最强先验系统同样用 Claude 4.5 Opus——性能差异不能归因于用了更强的模型。

5.3 分类与时长分析

Terminal-Bench 分类拆解（模型对齐，Fable 5）：优势集中在工具密集类——file operations 0.76 vs Claude Code 0.56 / Terminus 2 0.52；system administration 0.889 vs 0.778 / 0.844。论文将此归因于开箱即用的宽工具集与统一暴露接口（减少任务特定工具构造、把更多轨迹预算留给推理与验证），同时诚实标注：基准未隔离工具可用性与其他 harness 机制，此解释是系统级合理解释而非受控因果归因。

SWE-bench 按预估修复时长分组（Opus 4.5 配置）：

最有信息量的对照：mini-swe-agent 上 Opus 4.5 的 high 推理强度在 1–4 小时桶反而低于 medium 设定（35.71% vs 42.86%）——论文给出上下文预算效应解释：更高推理强度消耗更多 token 于深思，长轨迹下挤占有限上下文窗口中仓库状态/工具反馈/执行历史的空间。而 openJiuwen 用 high 强度仍达 52.38%，与其上下文管理机制『选择性保留与暴露任务相关信息』的角色一致——harness 层的上下文管理保住了深推理的收益。同样诚实标注：基准未直接隔离推理 token 消耗或上下文溢出，这是系统级解读而非受控因果主张。

5.4 指标如何证明论点

论文主张『可组合 + 可适应的 harness 设计能支撑复杂编码任务的强性能』。证明链：(1) 两个性质迥异的基准（仓库 issue 解决 vs 通用终端任务）上同时超越最强榜单——一致性支持 harness 的可复用性主张；(2) 最强 baseline 用同款模型——排除模型能力混淆；(3) 模型对齐对比（Fable 5 三方）进一步压缩混淆面；(4) 时长分桶显示长任务上优势保持——支撑长时程主张。同时论文反复声明榜单系统在提示/工具/实现上仍有差异，结果是系统级比较而非 harness 单独贡献的受控估计——这个边界意识贯穿全部归因陈述，是系统论文中罕见的严谨。

六、效果优势的根源解释

6.1 为什么整体超越榜单（+3.4 / +3.39）

对比对象：Claude Code（成熟的闭源商业 harness）、Codex、Terminus 2 等。它们有效的原因——大量工程打磨的专用机制与深度模型协同优化。

根源分析：openJiuwen 的优势不能归结为任何单点机制（论文自己的消融都不做此主张），而是四机制在统一执行语义下的组合效应，可拆成三条机制链：

• 上下文链：渐进压缩 + 死循环塌缩把长轨迹的上下文压力控制在预算内 → 模型在任务后期仍能看到足够的仓库状态与工具反馈 → 长时长桶不衰退（52.38% vs 同强度 mini-swe-agent 35.71%）；mini-swe-agent 的 high<medium 反常现象从反面印证：没有上下文管理时，深推理的 token 开销在长任务上变成自我伤害；
• 反馈链：LSP 被动诊断在变更后自动注入过滤后的语义错误 → 模型的下一步修正建立在机械证据而非纯自省上 → 修正闭环缩短（debugging 类 0.96、file-operations 0.76 的优势与此相关）；
• 停止链：Goal Mode 把语义完成与资源硬上限分离 → 区分『真正做完』『语义受阻』『资源耗尽』→ 减少两种经典失败——过早放弃未完成任务、或烧完预算才停。

工具链补充：统一工具接口减少任务特定工具构造 → 轨迹预算更多花在任务推理与验证上——对应工具密集类的最大优势。

6.2 为什么结构可组合性间接提升性能

结构维度看似纯开发者体验，但有性能侧面：同一执行语义复用意味着 Inner/Outer Loop 的边界控制、异常处理、有界重试在单智能体、子智能体、Swarm Flow 中行为一致 → 多智能体配置可以大胆用（如 parallel 生成多候选 + 评审 + 仲裁）而不用为每种拓扑重写并调试执行逻辑 → 示例 Coding Agent 这类『多候选+评审』结构本身就是提升难任务成功率的手段。Rail 的优先级元数据化还消除了能力间隐藏的执行顺序依赖——这类依赖正是碎片化执行路径中 bug 与不可预期行为的温床。

6.3 反事实与边界

若去掉上下文管理，预期退化最明显的应是 1–4 小时桶（对照 mini-swe-agent 的曲线可推断）；若去掉 Goal Mode，资源耗尽型失败会增加（无法区分受阻与耗尽）；若去掉 LSP 反馈，修正闭环退化为纯自省。但论文未提供机制级消融（Limitations 明确承认），因此上述链条是从系统对比+分类/时长分析+反面现象（high<medium 反常）间接推断的——这是阅读本文时必须保持的意识：证据是系统级的，机制归因是解释性的。>4 小时桶三系统同分 33.33%（仅 3 题）也提醒分桶结论的统计边界。

七、必要知识反推

7.1 领域知识层

• 长时程编码任务的执行特性：证据何时浮现（诊断/测试/进度）、上下文如何随轨迹演化、失败轨迹的重复模式——没有这些实证知识（来自 Lindenbauer、Majgaonkar 等研究）就不知道该适应什么；
• 现有 harness 生态：Pi/DeepSeek Harness/DeerFlow/Codex/Claude Code 的架构取舍——提炼两大挑战的素材；
• LSP 基础设施：语言服务器能提供什么语义证据、诊断如何产生——被动反馈机制的实现前提；
• 长上下文模型的压力特性：上下文窗口、KV-cache、推理 token 与有效容量的关系——解释 high<medium 反常现象需要这个知识。

7.2 方法论知识层

• 受控比较思想：模型对齐对比（Fable 5 三方）压缩混淆面的方法；
• 在线优化概念框架：决策变量/目标/约束/信息集的抽象——Θ_t 形式化的语言来源；
• 钩子/优先级/门控的组合系统设计：来自操作系统、中间件、编译器 pass 管线等成熟领域的通用模式；
• 基准评测方法：SWE-bench/Terminal-Bench 的协议、置信区间、榜单比较的注意事项。

7.3 工程知识层

• 多智能体系统实现：并发分支同步、状态会话、流式管线、人工干预接口的工程化；
• 上下文压缩工具链：对话摘要、增量压缩、KV 复用的落地细节；
• 可复现评测基建：容器化执行、官方评分套件接入、日志与轨迹记录。

7.4 知识融合的关键节点

• 洞察一（正交维度的识别）：把纷繁的 harness 特性整理成『结构（开发者侧）× 适应（任务侧）』两个正交轴——这个坐标系让每个机制都有自己的位置，也让与相关工作比较变得清晰。融合了系统设计经验与实证研究（失败轨迹特征）两类知识；
• 洞察二（固定模型周围的适应）：把『不改参数的运行时调整』形式化为配置轨迹 Θ_{0:T}——把 agent 社区『改提示/改上下文』的零散实践统一成在线优化语言，又不越界声称真的在解优化问题；
• 洞察三（机制映射到约束）：四个适应机制恰好一一对应三条约束 + 跨任务维度（κ↔C1、ι↔C2、Φ↔C3、Self-Reflection↔任务间）——设计的完备性检查由形式化提供。

八、论文中可以提取的通用性灵感

灵感一：共享执行基座 + 可插拔能力——组合性优于定制化

核心思想：复杂系统的能力膨胀后，与其为每种配置写定制编排，不如建一个极小共享内核，把一切能力做成带显式优先级与可见性门控的可插拔单元。

论文证据：Rail 三元组 (H, f, p) 让加删能力只改配置不动循环；同一 Inner/Outer Loop 语义从单智能体复用到 Swarm Flow——多智能体不引入第二套执行引擎。

推广场景：(1) 编译器的 pass 管线与插件系统；(2) 微服务架构的 sidecar 模式；(3) 浏览器扩展生态；(4) 数据处理框架的算子组合（Flink/Beam）；(5) 企业中台的能力组件化。

灵感二：适应性不等于学习——固定模型周围的非参数适应

核心思想：系统可以在完全不改核心模型/算法参数的前提下，通过调整外围配置（输入构建、反馈注入、停止判据）获得强适应性。

论文证据：四个机制全部作用于框架控制的运行时状态；Self-Reflection 显式定义为『跨任务非参数适应』——经验进检索库而非梯度进权重。

推广场景:(1) 无网调条件下的 LLM 应用增强（RAG/记忆/工作流）；(2) 嵌入式控制系统中不重刷固件的参数调度；(3) 人的技能不变但改变环境与流程带来的绩效提升（GTD 方法论）；(4) 推荐系统的冷启动规则层与模型层分离；(5) 任何部署后不可训练场景的系统优化。

灵感三：语义化停止——把『做完了吗』从资源问题升级为判断问题

核心思想：任务终止决策应该由语义验收信号（complete/blocked/continue）主导，资源上限只做兜底；两者分离才能区分成功、受阻与耗尽三种结局。

论文证据：Goal Mode 的 T = inf{t : Φ_t ≠ continue ∨ g_cap = 1} 形式化；与固定轮数循环相比，语义化停止避免『烧完预算才停』的失败模式。

推广场景：(1) 项目管理中的验收标准前置（DoD）；(2) 自动化测试的语义断言 vs 超时兜底；(3) 对话系统的意图完成检测决定挂机；(4) 深度研究智能体的证据充分性判断决定停止检索；(5) 个人时间管理中的目标完成判据 vs 时间盒。

灵感四：机械证据优先——被动反馈的过滤注入

核心思想：把机械产生、可过滤限量的客观证据自动注入决策循环，比让决策者自省更可靠；但注入前必须经过排序去重限量（RankDedupLimit）防止噪声淹没。

论文证据：LSP 诊断在代码变更后被动浮现，经 K_file/K_sem 双重限量后注入后续执行（约束 C2）；被动与主动查询的区别被明确为控制权归属。

推广场景:(1) CI/CD 的静态检查自动注入 PR 评审；(2) 可穿戴设备健康数据过滤后推送给用户；(3) 汽车的车况监测与主动仪表盘查询分层；(4) 协作软件的自动状态同步 vs 手动汇报；(5) 任何 LLM 智能体的工具验证信号设计。

灵感五：深推理与长上下文的冲突需要系统层调和

核心思想：更强的推理（更多思考 token）与更长的任务（更多历史 token）争抢同一有限窗口；没有上下文管理时，深度思考在长任务上会自我伤害——系统层的信息分层保留是调和两者的必要条件。

论文证据：mini-swe-agent 上 Opus 4.5 high 在 1–4 小时桶低于 medium（35.71% vs 42.86%）；openJiuwen 用 high 达 52.38%，上下文管理的选择性保留保住了深推理收益。

推广场景:(1) 人类的深度工作需要外部笔记系统承载记忆负担；(2) 长会中的纪要与看板防止『讨论越深忘得越多』；(3) 任何长推理链 AI 系统的 KV/上下文预算分配策略；(4) 大型代码库开发中的文档分层（README/详细文档/源码）；(5) 组织记忆与个人记忆的制度化分工。

灵感六：诚实的归因边界——系统论文的科学态度

核心思想：当评测无法隔离单个机制的贡献时，明确声明『系统级解释而非受控因果归因』，比含糊地邀功更可信也更可复用。

论文证据：分类优势归因、时长分析归因两处均主动标注解释性质；Limitations 承认缺机制级消融与更广的受控研究。

推广场景:(1) A/B 测试中的混杂因素声明；(2) 医学观察性研究的因果语言规范；(3) 企业绩效归因的多因子声明；(4) 自动驾驶安全报告的场景边界标注；(5) 一切系统评测报告的写作规范。

附录：值得记录的细节

• 示例 Coding Agent 的协调流：leader 查 budget() 决定 worker 数 → parallel() 并发候选 → compact() 去空 → pipeline() 流经评审 → agent_session() 仲裁者聚合 → 信心不足时 human() → return——这个七算子组合是多智能体编码的现成参考模板；
• 渐进信息层级：full content → 结构/语义摘要 → 紧凑句柄 → 按需检索，加上对话检索的由粗到细——可直接移植到任何长时程智能体的上下文设计；
• 作者构成：18 位核心贡献者全部来自华为，项目以 openJiuwen Team 名义发表、代码开源在独立组织下——大厂纯企业团队做开源基建的样本；
• 与 LoopArena 的互补阅读：LoopArena 评测『谁当 Controller』，openJiuwen 展示『Controller 所在的 harness 长什么样』——两篇同期论文正好构成 Loop Engineering 实践的评测侧与系统侧，合读能看到这个方向的完整图景。