8 月 28 号早上，arXiv 挂出来一篇 2608.27969。openJiuwen 团队，Tao Yu 领衔，19 个作者，cs.AI，正文 6 MB，连 TeX 源码都给了，DOI 还挂在 DataCite 那边没注册。
我做综述有个毛病：拿到一篇新论文，先扫标题里哪个词是"新"的。这篇的新词是 harness。
不是 model，不是 agent，不是 reasoning。是 harness——执行框架。
值得停一秒。过去三年，编程 agent 这块地图上标题里当主语的词换过好几轮：能力（planning、reflection、reasoning）、拓扑（multi-agent、debate、role-play）、数据（trajectory、benchmark、fine-tune）。harness 极少被单独拎出来当主语，因为它一直被归进工程管道那一堆——做 agent 的人每天泡在里面，写论文的人默认它不构成贡献。
可它现在是整条链上唯一没有公共坐标系的一层。坐标系缺位的后果很脏：你读到一篇 coding agent 论文，看到 SWE-bench Verified 上通过率涨了八个点，你没法判断这八个点是模型换代挣来的，还是 harness 设计挣来的。两件事混在同一张成绩单上，没人拆开过。
这个体感在圈里几乎是共识。我见过的做 agent 的人，十个里九个点头，剩下那个补一句"我们内部跑过，确实差得多，但不能发"。共识归共识，没有一篇论文给过受控的数字——问题恰恰在这儿：一个领域最重要的那个自变量，从来没被当成自变量测过。
这篇要做的就是把这层摊开画成一张图。四个区，逐层梳，最后落一个坐标。丑话说前面：论文原文我没逐节核，以 arXiv 页面信息和摘要为准；涉及 2026 年的其他工作，大多只看公开转述，哪块没核我当场标出来。
一、骨架：harness 是四层，不是一层
把它当成一个整体去谈，五分钟之内必然变成口水仗，因为不同人在说的其实是不同层的东西。我切成四层。这个切法不完美，第四刀切得我自己也不满意，后面会承认，但比不切强：
- 执行循环层——一轮里模型看到什么、能做什么动作、动作的结果以什么形式回来。ReAct（Yao et al., 2022）那套 thought–action–observation 的三拍结构是这个层的祖先。
- 编排拓扑层——一次任务里有多少个模型实例、谁向谁汇报、上下文在它们之间怎么流。单体、委托型子智能体、对等协商、swarm，都在这一层。
- 状态与上下文层——不断变化的仓库状态怎么被表示、检索、压缩、持久化。代码任务特有，也是整块地图上最脏的一层。
- 运行时控制层——控制流是开发者写死的，还是运行时根据中间证据改的。openJiuwen 那篇里的"运行时自适应性"指的就是这一层。
| 层 | 一句话定义 | 现在什么状态 | 主要代价 |
|---|---|---|---|
| 执行循环 | 动作空间与观测形式 | 事实标准已成，边际收益被吃干 | 观测压缩丢信号 |
| 编排拓扑 | 实例数与汇报关系 | 对等协商退场，委托型固化 | 上下文隔离换来归因链断裂 |
| 状态与上下文 | 仓库状态的表示与压缩 | 最热、最乱、无公共评测 | 压缩点不可比 |
| 运行时控制 | 控制流由谁决定 | 刚被当研究对象，最空 | 自适应与可复现互斥 |
这张表就是下文目录。四层的演化速度差得远，混在一起讲，会把 2023 年已经收敛的结论和 2026 年还空着的坑搅成一坨——很多人读 agent 论文读得累，不是因为它难，是作者自己也没分清在讲哪一层。
二、执行循环：ReAct 是起点，快成终点了
这一层最好梳，历史短，结论硬。
ReAct（Yao et al., 2022）绕不开。它的贡献不是"让模型用工具"——Toolformer（Schick et al., 2023）那一支早就在做——而是把"想一步、做一个动作、看结果"打成一个能循环的三拍结构。要紧的地方在于：它把推理从一次性生成变成一条关于外部状态的序列，而序列意味着任何一步都能被外部世界证伪。agent 这个概念真正落地就在这儿。
然后两条改造线。一条改动作空间：CodeAct（Wang et al., 2024）把"能做什么"收成"生成一段可执行代码"，解释器负责把结果吐回来。好处是动作空间不用预先枚举，你不必给模型定义一千个 API，给个 Python 解释器就行，剩下的是它语言能力的事。另一条改观测形式，这条我印象里最被低估：SWE-agent（Yang et al., 2024）那套 ACI，核心是把终端吐回来的原始输出重新排版成模型读起来省力的形式——截断长文件、给行号、给上下文窗口、把 diff 单独拎出来。零理论深度，纯工程，可它把通过率往上抬了一截，抬的幅度大到当时不少人以为是模型换代的功劳。
收敛得比我预期快。到今天，编程 agent 的动作空间基本锁定五六个：读文件、搜、改、跑、看 diff，外加一层把观测压干净的格式化。翻各家产品的公开文档，Claude Code、Codex CLI、Gemini CLI 的执行循环在内核上是同质的——都是 ReAct 加 ACI，差异全在上下文管理和权限模型上，不在这层。
这一支现在是大模型编程 agent 的事实标准，同时是最没有余量可挖的一层。
这话不是贬义。一个层收敛到没有余量，说明它做对了。想在这层再榨出东西，唯一的路是换动作空间的形态——把"改文件"扩成"改整个运行环境"，或者把"单次调用"扩成"长驻进程"。这两条我暂时没看到跑通的工作，地图上这一格先留着。
三、编排拓扑：对等协商死了，委托还活着
这一层的坟头草比谁都高。
2023 年多智能体是最热的关键词。CAMEL（Li et al., 2023）用角色扮演让两个实例对话，一个当程序员一个当审阅者；MetaGPT（Hong et al., 2023）把软件公司的 SOP 塞进对话结构，产品经理写完给架构师，架构师写完给工程师；ChatDev（Qian et al., 2023）走的是同一路子；AutoGen（Wu et al., 2023）把这件事抽象成可编程的会话拓扑，想连几个连几个。那一年这几篇被引得很凶。
代码任务上的实际收益基本没兑现。我的判断很直接，甚至有点偏：对等协商这一支在代码任务上堵死了。 堵死的原因不是"分工不对"，是通信成本的结构问题。对等协商每一轮都要把上下文广播给所有参与者，token 于是花在互相复述对方刚说过的话上，而不是花在看代码、跑测试、读报错上。在一个上下文窗口有限、仓库状态是唯一有效信息源的域里，你拿一半预算去社交——这不是调参能救的。
活下来的是另一支：委托型子智能体。父实例留着控制权和一份摘要，子实例拿一个隔离的上下文去做一件窄事，做完把结论交回来，上下文丢掉。它的收益来源经常被误读成"分工"。不是分工，是上下文隔离。一个只读三个相关文件、只回答"这个函数在哪里被调用"的子智能体，上下文里没有其他九十个文件的噪声，准确率就是比父实例自己去找要高。Anthropic 在 2025 年那篇讲多智能体研究系统的公开博文里说得很明白（我只读了转述，原文没核）。到 2026 年，委托型子智能体已经是 harness 的默认配置之一，不再是"高级特性"。
长时程编程 agent 的编排拓扑
├── 单体 (single)
│ 一个实例、一个上下文窗口、一条控制流
│ └── 状态：绝大多数 2023–2024 harness 的形态，仍在用
├── 对等协商 (peer)
│ 多实例平等对话，上下文广播
│ ├── 角色扮演：CAMEL (Li et al., 2023)
│ ├── SOP 化：MetaGPT (Hong et al., 2023)、ChatDev (Qian et al., 2023)
│ └── 可编程拓扑：AutoGen (Wu et al., 2023)
│ └── 状态：2024 年后在代码任务上基本退场
├── 委托型子智能体 (delegated)
│ 父实例留控制权与摘要，子实例拿隔离上下文做窄任务
│ └── 状态：已进默认配置，理由是上下文隔离，不是分工
└── Swarm Flow
拓扑本身可变，实例之间动态重组
└── 状态：开放。openJiuwen 三形态之一，可复现性是硬账
| 形态 | 上下文流向 | 代表 | 现在状态 | 代价 |
|---|---|---|---|---|
| 单体 | 单窗口累积 | 大多数 2023–2024 harness | 仍在用 | 长任务上下文爆窗 |
| 对等协商 | 全广播 | CAMEL / MetaGPT / AutoGen | 代码域退场 | token 烧在复述上 |
| 委托型 | 单向隔离 | Anthropic 多智能体系统（公开博文） | 已固化 | 归因链断裂 |
| Swarm | 动态重组 | openJiuwen 三形态之一 | 开放 | 结果难复现 |
Swarm Flow 这一格我持保留，理由放到讲 openJiuwen 那节一起说，因为它就长在那儿。
四、状态与上下文：最热、最乱、最没有共识
这层是现在地图上论文最密的一块，也是我梳得最没底气的一块。
"仓库状态"在 harness 里至少有四种表示方式，它们在真实系统里常常同时存在，谁也没被淘汰。
第一种，原始文件树加检索。代码在那放着，agent 自己 grep、自己 read。优点永远最新，缺点是把"找对文件"全压在模型的检索能力上，而这件事在十万行的仓库里是真的会失败。
第二种，符号级表示。把仓库解析成函数、类、引用关系的图，给模型一张 repo map。工程上有效，我知道有几个产品在做（以公开文档为准，具体实现我没核），但它在研究文献里几乎没有对应的受控评估——没人公测过"给不给 repo map，通过率差多少"。
第三种，执行轨迹本身当上下文。模型改了三次、失败了两次、第三次过了，这三次的过程本身就是关于这个仓库最好的信息。问题是它只能线性增长，而窗口有限。
第四种，显式记忆文件。项目根目录下一个 markdown，写清楚"这个项目的测试怎么跑""别动这个目录""我们的命名规范是这套"。朴素到有点土，但它同时满足三个条件：人可写、模型可读、跨会话持久。凡是同时满足这三条的机制，在工程里都会赢，跟它够不够 fancy 无关。
真正把这一层搅乱的是长上下文。4K 窗口的年代检索派是唯一解，因为塞不下。窗口涨到几十万上百万之后，"全塞进去"在某些任务上重新变成可行选项，于是"检索还是全塞"从一个工程约束问题变回开放问题。两条路的代价不对称：全塞的代价是线性成本加稀疏注意力（东西都在窗口里，但模型不一定会看），检索的代价是召回漏了就永远补不回来——它不会在第四十轮突然想起来"我当初没搜那个文件"。
压缩这件事更没共识。什么时候压、压什么、丢了什么，没有任何公共评测能回答。举个具体到疼的例子：跑到第二十轮，agent 跑了一遍测试，吐出来八百行输出，其中七百九十行是同一个 fixture 的重复栈帧，剩下十行里有一行是真正的原因。你把八百行压成二十行摘要——你可能恰好把那一行压掉了，而失败要到第四十轮才显形，那时候你已经没有任何办法回溯是哪次压缩弄丢的。
再看一个反方向的信号。AgentLess（Xia et al., 2024）那条线用一条写死的、不做 agent 循环的固定流水线——定位、修复、验证三步，中间没有自主决策——在当时的配置下和一批 agent 系统打到差不多的水平。这篇我记得的是大意，原文核得不细，后来的争议也不小。但它的信号很清楚：那个时间点上，代理循环挣来的收益，有很大一部分被上下文管理的噪声吃掉了。不是 agent 没用，是 agent 和上下文管理在互相抵消。
这层论文最多，结论最不稳，我不建议任何人现在照着这一层的某篇论文定架构。
五、运行时控制：这一刀我切得不利索
坦白说，第四层和第三层的边界我自己也画不干净——"根据新证据调整后续决策"和"根据新证据调整上下文"，在很多系统里是同一件事的两个说法。我分开切，是因为这一层有一个第三层没有的问题：谁在决策。
静态一侧做到极致的是 SWE-agent 的 ACI 和 AgentLess 的固定流水线。开发者把所有控制流写死在 if-else 里，什么情况重试、什么情况换文件、什么情况放弃，全是人事先定的。天花板很清楚：长时程任务的证据分布是右偏的——大部分轮次平淡如水，少数几轮信息量爆炸（第一次跑通测试、第一次看到真正的报错、第一次发现改动影响到了另一个模块）。写死的控制流没法在爆炸的那一轮多花钱，也没法在平淡的那些轮次省钱。它只能在平均值上设计，而平均值在长时程任务里是个很糟糕的优化目标。
动态一侧的早期尝试是 2023 那批自我反思工作：Self-Refine（Madaan et al., 2023）让模型给自己的输出打分再改，Reflexion（Shinn et al., 2023）再加一层把反思写进记忆、跨轮复用。这批工作在简单的生成任务上有效，但很快撞上一条边界：Huang et al.（2023）那篇 "Large Language Models Cannot Self-Correct Reasoning Yet" 把话挑明了——没有外部信号的自纠，基本无效。 模型在没有外部反馈的情况下"再想一遍"，往往只是把原来的答案换个说法，错误率不降反升。
这条边界从 2023 年划下来之后，整个动态控制这一支被劈成两半。一半是"无信号的自我说服"，那半已经判了死刑，不用再看。另一半是"有 verifier 信号的纠正"，这半活着，而且活得不错。
于是有个我一直觉得被讲得不够透的点：代码域是外部信号最充足的域。 编译器、测试、类型检查、linter、运行时报错，全是免费 verifier，全都不可争辩。写作域搞自适应很难，因为"这段文字好不好"没有 verifier；代码域搞自适应，模型每改一行都能拿到一个二值信号。自适应在代码域能走通、在开放域走不通，不是方法上的差别，是域的性质差别。openJiuwen 挑代码域不是巧合，是选了一块信号最便宜的地。
六、把 openJiuwen 摆到坐标上
回到那篇。它自己声明了两个轴：结构可组合性（Structural Composability）和运行时自适应性（Runtime Adaptivity）。
这两个词起得好。好不在文采，好在这两个轴可被证伪。你回头看 agent 领域里那些没法反驳的自我陈述——"我们的框架更灵活""更高效""更适合复杂任务"——那些话你没法验证也没法反驳，所以它们不构成坐标。而"能不能在不重建编排逻辑的前提下组合新能力"和"运行时证据能不能反过来影响后续决策"，这两句话可以拿实验怼。
它的做法是：给一个共享执行基底，用一套叫 Rail 的机制把能力组合起来，覆盖单体、委托型子智能体、Swarm Flow 三种形态，让开发者在同一套执行语义下搭结构。然后在固定模型策略的前提下，只让框架控制的那些运行时决策做自适应，让新出现的证据——语义诊断、执行结果、任务进度、上下文相关性变化——动态影响上下文、反馈和任务控制。
我拆开说哪部分是实的、哪部分是账。
实的部分是那把三层收进一套执行语义。 前面梳的前三层，在现实系统里常常是三个库、三套状态、三种调试方式粘出来的。粘合处出的 bug 没有人认领——循环层说上下文层给的信息不对，上下文层说拓扑层没把状态传下来。把这三层收进一套执行语义，最大的收益不是性能，是归因：一个失败第一次有了单一的责任面。
更实、而且我认为是这篇论文方法论上最值得抄的一点，是"固定模型策略"这四个字。 前面说过，这领域最要命的病是没人拆开模型收益和 harness 收益。这篇把模型钉死、只动框架控制的运行时决策，这是把 harness 当研究对象的正确姿势。它的结果因此比同分的论文多一层信息量——你可以不同意它的结论，但你至少知道它在测什么。我甚至觉得这个方法本身比它的框架设计更值得被引用。
账面部分，就是那两个数字。 SWE-bench Verified 82.6%，Terminal-Bench 2.1 87.19%，分别比论文所说的、官方排行榜中最强的点估计高 3.4 和 3.39 个点。
三个问题得连着问。第一，"官方排行榜中最强的点估计"这句话里，"所选"两个字留了很大的余地——选的是哪个榜、哪一天的快照、那个提交自己用的什么 harness 配置，这三件事决定了这 3.4 个点里有多少是真信息。同一个榜在不同时间快照上差三五个点是常态。第二，SWE-bench Verified 是人筛过的子集，体量不大，3.4 个点换算下来是十几条任务，这个量级上单次采样的方差不是小数点。第三，Terminal-Bench 2.1 这个具体版本我没跟，对它的任务分布和难度我没有任何第一手判断，只能以公开页面为准。
我不打算说这数字是灌水——我没证据。我要说的是：这两个数字在 2026 年已经不能作为主要论据，而这篇论文本身也不该靠它们立住。 它真正的贡献在前两段说的地方。
七、我持保留的那一格
Swarm Flow 是我这一整篇里最不愿意签字的坐标。
理由不复杂：拓扑越自由，可复现性越差。自适应已经让"同一份代码、同一个模型、同一个输入、跑两次"变成两条不同的控制轨迹了——这在研究上是特性，在工程上是负债。再叠一层动态重组的 swarm，一个任务失败的归因链就彻底断了：你不知道是父实例分派错了，是某个子实例拿了脏上下文，是压缩点吃掉了信号，还是拓扑在中途重组时丢了状态。四个可能，全都没法证伪。
我不是说这一支不会赢。我是说它如果赢了，赢的方式一定不是"拓扑更自由"，而是先有人把归因这一关解决了，再谈拓扑。顺序颠倒过来，做出来的东西没法迭代——你连改进是不是真的改进了都测不出来，只能靠感觉，那这个领域的进度条就断了。
这是我个人的判断，不是共识。你不同意，可以拿一篇能复现 Swarm 收益、并且能说清收益来自哪个子决策的论文来挪这块坐标，我随时重画。
八、回看全景
把前面四层压成一张表。这张表是这篇的图例。
| 层 | 分支 | 代表工作 | 现在状态 | 代价 |
|---|---|---|---|---|
| 循环 | ReAct 三拍 | Yao et al., 2022 | 已成标准 | 单链累积误差 |
| 循环 | 代码即动作 | CodeAct, Wang et al., 2024 | 已成标准 | 沙箱与安全边界 |
| 循环 | 观测重排 (ACI) | SWE-agent, Yang et al., 2024 | 已成标准 | 压缩丢信号 |
| 拓扑 | 对等协商 | CAMEL / MetaGPT / AutoGen | 代码域退场 | token 烧在复述 |
| 拓扑 | 委托型子智能体 | Anthropic 公开博文（转述） | 已进默认配置 | 归因链断裂 |
| 拓扑 | Swarm | openJiuwen 三形态之一 | 开放 | 可复现性 |
| 上下文 | 检索 / repo map | 产品侧为主 | 无公共评测 | 召回漏了补不回 |
| 上下文 | 全塞长窗口 | 随窗口涨重新可行 | 开放 | 线性成本 + 稀疏注意 |
| 上下文 | 显式记忆文件 | 多产品约定（文档为准） | 事实可用 | 需人维护 |
| 上下文 | 压缩 | 各家自定 | 最乱 | 丢什么没人测 |
| 控制 | 静态流水线 | SWE-agent ACI、AgentLess | 天花板已见 | 无法按证据分配算力 |
| 控制 | 无信号自纠 | Self-Refine / Reflexion | 已判无效 | Huang et al., 2023 那条线 |
| 控制 | 自适应（有信号） | openJiuwen 的 Runtime Adaptivity | 刚开 | 难复现 |
横向拉着看一条规律：活跃区在右移。 2023 年活跃区在第一层（ReAct、SWE-agent、CodeAct 那一批）；2024 年挪到第二层，多智能体最热；2025 年挪到第三层，上下文和记忆变成主战场；2026 年这一格是第四层。这个右移不是随机的，驱动力很简单——左边三层的边际收益被吃干了。 循环层收敛、拓扑层试错完、上下文层虽然在乱但至少是热区，控制层还空着，所以算力、人力和论文都往那边走。
读这张表的时候请带着这条时间轴一起读。不带的话，你会把"现在的活跃区"当成"一直的活跃区"，拿 2026 年的坐标去评估 2023 年的工作，得出"这些东西都没用"的错觉。
纵向再看一条：第三层是整张地图的地基，也是最不被承认的地基。 上面所有关于自适应、关于委托型子智能体的收益，最后都要经过上下文这一层兑现。一个子智能体拿到的上下文脏了，它再聪明也白搭；一次压缩吃掉了关键行，后面的自适应决策全建在错误的前提上。控制层越花哨，对上下文层的依赖越重，而这一层恰恰没有公共评测。这条依赖关系是钉死整张图的关键，不是补充说明。
九、摊开这张地图
落子是这样。
现在站在哪： harness 从"工程管道"变成"研究对象"的转折点上。我说这句话不因为 openJiuwen 本身有多强，是因为它出现的姿态——固定模型、只动框架、把两个可证伪的轴写进标题——是转折已经发生的证据，不是转折的原因。一个领域开始给自己的中间层起名字并单独测它，说明它上面那层已经收敛到没什么可测了。
地图上还空着的，我觉得是两块。
第一块，harness 的公共评测协议。现在所有人都在各自的 harness 上跑 SWE-bench、跑 Terminal-Bench、跑 LiveCodeBench，但没有一个公共榜单做"固定模型、只换 harness"这件事。这块空白不比任何一篇论文小。而且它不贵——挑三四个模型、五六个公开可得的 harness，做一次全交叉，就是一张这个领域一直缺的坐标纸。谁先做出来，谁就定义了这一层的坐标系，往后所有 harness 论文都得引用那张表，不管愿不愿意。这块地图一直空着，我猜不是没人想到，是没人愿意干那种不发论文的活。
第二块，可审计性与轨迹可复现。自适应加上委托型子智能体加上可能的 swarm，三者叠起来之后，一个长任务失败的归因链已经断了。这不是学术洁癖，是生产环境的刚需——你要为 agent 的改动付法律、账单和声誉责任，你就得能说出它为什么改了这一行。可复现性在评测里是"结果一致"，在工程里是"过程可读"，这两件事现在一个都没被解决。这块空得吓人，比控制层本身空得还吓人。
方向上，下一颗钉子最可能钉在"可归因的自适应"上。 自适应本身不稀奇，openJiuwen 这一支已经把"运行时可调"钉下去了；稀奇的是自适应完还能把"我为什么这么改"说出来——不是让模型事后编一段解释（那个我们已经知道不可信），是让框架自己在决策点上留一条可读的因。openJiuwen 钉的是前半颗，后半颗还悬着。
这个判断是可证伪的。如果未来一年里没人做出"固定模型对比 harness"的公共评测，那说明这个领域的激励机制还是奔着刷分去的，那我得承认我高估了大家的耐心。如果做出来了，接下来的一定是可归因性——因为一张能看出 harness 差异的表一旦铺开，第一个被问到的问题必然是"这个差异是从哪一步来的"，而现在的框架答不上来。
按我自己的规矩，交代一下这张图哪儿没画全。 多模态编程（截图改 UI、看设计稿写前端）整支我略过了，它和纯文本编程的成熟度差一个阶段，硬并到同一张表里会把坐标搅乱。成本维度我一个字没写——token 花了多少钱、墙钟时间多长、并发下怎么退——这篇是能力地图不是成本地图，而在生产环境里成本经常比能力更早成为否决项，这块我欠着。2026 年的工作我大多数只看公开转述，原文没逐节核，涉及那部分的所有判断，可信度都要往下调一档。最后，这一整篇的坐标会挪。这领域一周一个新分支，任何万字综述交稿那天就开始过时，你拿它当导航可以，当定稿不行。
这张图是导航，不是路线推荐。选哪支走，取决于你的任务复杂度、你的算力预算、以及你能不能接受一个跑两次结果不一样的系统。把判断停在坐标这一层是有意的，再往下伸就是替你拍板了。