论文链接：Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents 发表时间：2026年7月15日（arXiv:2609.00006v1；分析快照锚定 2026 年 7 月版本） 机构：Wavestone AI Lab + Inclusive Brains（产业咨询/研究实验室；Paul Barbaste 为主笔） 领域标签：cs.SE / 软件工程实证研究 / Agent 架构

一、论文背景

1.1 Harness 工程：2026 年初才被命名的学科

2026 年初，“harness engineering（运行架工程）“作为一个工程学科被正式命名——业界普遍接受了"Agent = 模型 + Harness"的公式：harness 是通过循环、工具、上下文管理、安全控制、编排与扩展面把 LLM 与世界耦合起来的运行时。Martin Fowler 网站、Microsoft Agent Framework 文档、LangChain/Databricks 博客都在 2026 年发表了 harness 概念的科普——一个共识正在形成，但它是碎片化的：每家厂商讲自己的故事，没有统一的解剖学语言。

1.2 为什么需要源码级研究

在这篇论文之前，对 harness 的认知来自三条有偏的渠道：厂商文档（营销倾向）、使用评测（黑箱外部观察）、社区讨论（轶事为主）。而 harness 的本质是软件制品——只有读源码才能回答"它到底怎么建的"这类问题：记忆管理策略是什么？提示词如何组装？提供商耦合到什么程度？安全控制有几层？这些恰恰是决定 harness 质量的内部结构，外部评测全部不可见。

1.3 研究对象的谱系

论文锚定 2026 年 7 月的版本快照：四大提供商旗舰——Claude Code（Anthropic，TypeScript，经流通的源码快照）、Codex CLI（OpenAI，Rust）、Gemini CLI（Google，TypeScript）、Mistral Vibe（Mistral，Python）；七大开源系统——OpenHands（事件溯源 SDK）、Aider（十三种多态编辑格式）、Mini-SWE-Agent（“100 行研究下限”）、Hermes（Nous Research，GitHub 增速最快）、Pi、OpenCode、OpenClaw（10+ 提供商适配器）；外加 Omnigent（Databricks）作为首个"元 harness”（能托管其他 harness 的 harness）对照点。

二、论文定位和关联工作

2.1 相关工作谱系

谱系一：概念科普类。厂商与工程社区的 harness 概念文章（Martin Fowler、Microsoft、LangChain 等）——定义了"是什么”，但没有跨系统实证。关键区别：本文用源码证据替代概念叙述。

谱系二：配置机制分析。arXiv 2602.14690 系统分析了编码工具的配置机制——但聚焦配置面，本文覆盖完整架构。

谱系三：外部评测。Terminal-Bench 等基准测"harness-模型对"的表现——黑箱。本文明确"不 benchmark、不排名、只解剖"——与评测工作正交互补。

谱系四：设计空间综述。arXiv 2604.14228 等设计空间论文给出分类框架；本文的增量是逐系统的源码级深度与设计模式的可操作性提炼。

2.2 定位对比表

维度概念科普外部评测设计空间综述本文
方法厂商叙述黑箱跑分框架分类逐系统源码解剖
深度浅表现层中实现层
产出概念排名分类法子系统图谱+模式目录+设计建议+最小实现
偏差源营销内部不可见抽象悬空版本快照时效

定位结论：这是第一部 harness 的"比较解剖学"——为刚命名的学科提供共同语言（七子系统）与实证地基（29 模式），性质上类似软件工程领域的"架构实证研究"传统。

三、问题定义

具体场景：harness 已成为决定 agent 表现的关键层（同模型不同 harness 差距可达两位数百分点），但缺乏对其内部结构的系统知识。

核心问题拆解：

  1. 定义问题：harness 到底是什么、不是什么？（边界模糊则一切讨论失焦）
  2. 解剖问题：harness 由哪些子系统构成？每个子系统的最小与最大实现是什么？
  3. 比较问题：11 个系统在各子系统上做了哪些不同的选择？哪些选择收敛了（事实标准）、哪些仍然分化？
  4. 规律问题：跨系统观察揭示了哪些设计规律与行业演化方向？

抽象的精妙之处：论文刻意选择"不排名"——因为 harness 质量依赖场景（模型生态、部署环境、安全要求），排名会把架构问题降格为选型问题；解剖学提供的是决策地图而非胜负表，让读者按图索骥做自己的架构决策。

四、问题解法（研究方法与七子系统框架）

4.1 七大子系统（harness 的解剖学骨架）

论文定义 harness 的七个规范子系统（各子系统最小→最大实现的谱系在论文中逐系统展开）：

  1. Agent 循环：驱动模型-工具交互的主循环（从 Mini-SWE-Agent 的线性循环到 OpenHands 的事件溯源引擎、Codex 的 Tokio 异步状态机）；
  2. LLM 集成：提供商抽象层（五档光谱：单提供商紧耦合 ↔ 多提供商适配器矩阵）；
  3. 提示架构：提示组装与缓存策略（Claude Code 的模块化组装+缓存边界、Codex 的 per-model 服务器下发、OpenHands 的注册表+缓存层级）；
  4. 记忆管理：长会话上下文的维持策略（线性无裁剪 → 摘要 → 递归折半 → 阈值触发 LLM 压缩）；
  5. 工具面：工具暴露与权限控制（被动原语 ↔ 能力门控的工作流工具）；
  6. 安全控制：审批门、沙箱、破坏性操作拦截（Claude Code 的 deny-first 七层安全架构）；
  7. 扩展面：技能/MCP/插件机制（静态配置 ↔ 运行时可扩展）。

4.2 方法论要点

  • 版本锚定：所有分析锚定 2026 年 7 月发布版（Claude Code 经流通源码快照），部分系统做两次快照做纵向对比；
  • 维度一致：11 系统按同一套七子系统维度逐一解剖，保证可比性；
  • 制品化产出：13 条跨系统观察 + 29 个设计模式目录 + 18 条设计建议 + 90 行最小 harness 脚手架（论文证明：90 行代码可实现十种核心设计模式中的九种）。

五、评估指标与实验证据（实证发现）

作为实证研究，本文的"证据"是源码级观察的密度与可复现性。最有信息量的发现：

5.1 收敛：记忆管理的事实标准

7/11 系统（四大提供商原生 + 三个新增系统）独立收敛于"阈值触发 LLM 压缩"（threshold-triggered LLM compaction）——上下文超阈值时用 LLM 自己压缩历史。线性/摘要/折半等策略仅存于早期或极简系统。收敛即事实标准的诞生：新系统大概率默认采用该方案。

5.2 光谱：提供商抽象的五档策略

  • 单提供商紧耦合（Anthropic/OpenAI/Google 旗舰）：深度绑定自家特性（Claude 的 extended thinking 与工具格式、Codex 的 Responses API 线格式、Gemini 的 Vertex 耦合）；
  • 提供商优先+通用回退（Mistral Vibe）：MistralBackend 吃自家特性 + GenericBackend 兜底；
  • 多提供商抽象层 / 自有传输 / 混合插件（开源阵营，OpenClaw 达 10+ 适配器与故障转移）。

纵向证据：Gemini CLI 的路由层在两次快照间完成整代模型更替（默认目标从 gemini-3.1 系换到新一代）——路由层存在的意义就是吸收模型 churn，让循环层不必改。

5.3 洞见级观察（选摘）

  • 提示即数据：Codex 已把 per-model 提示作为服务器端模型目录数据在运行时刷新下发，而非编译期模板——提示词工程变成了数据运营；
  • 平台化转折：OpenHands 从产品演化为"能托管 rival harness 的宿主"，Omnigent 进一步做元层——harness 生态出现分层（平台/框架/产品）；
  • 两个缺席：三个 corpus 交叉验证后仍缺失的设计（论文识别出两个系统性空白）——这类"负面发现"只有解剖学才可能给出；
  • 90 行下限：Mini-SWE-Agent 证明 100 行可以做出能打的 harness，90 行脚手架证明核心模式的最小实现远比想象中小——harness 的本质复杂度在少数几个决策点。

5.4 证明力评估

源码研究的证明力来自可核查性：每条观察都锚定具体系统与版本，读者可对照源码验证。局限（论文自承）：Claude Code 依赖流通快照而非官方源码（版本漂移风险）；2026 年 7 月快照对快速演化的领域有时效性——这恰是论文做双快照纵向分析的原因。

六、效果优势的根源解释（本文为实证研究，解释"为什么这些发现重要"）

为什么记忆管理会收敛于阈值压缩？ 机制层面：长会话中上下文窗口是硬约束，“无损失保留"不可行；摘要/折半等启发式需要领域定制且信息损失模式不可控；而"LLM 压缩 LLM 的历史"用模型自身的语义能力决定保留什么——通用性最好、实现最省。四家竞争厂商独立做出同构选择，说明这是约束面下的强力收敛而非巧合——对从业者的含义：除非有特殊需求，跟随该标准是低风险默认。

为什么提供商耦合呈五档光谱而非统一抽象？ 商业与技术的双重因果：紧耦合吃到自家模型独有特性（Claude 的缓存边界、Codex 的流格式），性能最优但锁死；抽象层换来自由但特性均质化。厂商旗舰选前者（卖模型差异化）、开源系统选后者（跨模型是卖点）——光谱位置映射商业模式，这解释了为什么不会有"统一正确答案”。

为什么"提示即数据"是重要信号？ 它把提示词从"代码的一部分"变成"运营的一部分"——可以不发版更新、可以 A/B、可以按模型版本参数化。这与数据库迁移/特征旗标的演化路径同构：当某类资产变化频率超过代码发布频率，它必然从代码中分离为数据。

为什么 90 行脚手架有价值？ 它证明 harness 的核心决策点（循环、工具分发、上下文裁剪、停止规则）可以在极小代码量内表达——复杂度在决策质量而非代码规模。这是对"harness 需要庞大工程"的解毒剂，也是教学与原型的最优起点。

七、必要知识反推

领域知识层

  • 11 个系统的产品形态与生态位（谁卖模型、谁卖平台、谁是研究下限）——不知道生态位就无法解释架构选择的商业因果；
  • 2026 年 harness 概念谱系（概念科普的碎片化现状）——本文要统一的正是这套语言。

方法论知识层

  • 软件工程实证研究方法（anchored cross-case study、模式目录的传统如 GoF 设计模式）——29 模式的提炼方法直接师承模式语言运动；
  • 比较解剖学的框架思维——同维度跨系统的可比性设计；
  • 版本锚定与纵向快照方法——应对快速演化对象的标准技术。

工程知识层

  • 读 TypeScript/Rust/Python 生产代码的能力（三个语言族）；
  • LLM SDK 生态细节（Anthropic/OpenAI/Vertex 的特性差异）——提供商光谱的分析依赖知道"耦合到了什么特性"；
  • 最小可行系统的构造能力（90 行脚手架）。

知识融合的关键节点：最关键的融合是把生物学"比较解剖学"的方法论引入软件研究——对同功器官（各系统的记忆管理）与同源器官（共同的 ReAct 祖先）做区分，从收敛中识别"环境约束的必然"（阈值压缩），从分化中识别"商业定位的选择"（耦合光谱）。没有模式目录传统则发现无法沉淀为可复用知识，没有源码级深度则退回概念综述。

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

灵感一：为新兴学科先写"解剖学"再写"药理学"

  • 核心思想：当一个领域刚被命名、概念混乱时，最高杠杆的工作不是比较优劣（药理学），而是建立结构语言（解剖学）——先让大家讨论同一套器官，再谈哪个器官的哪种方案好。
  • 论文证据：七子系统框架 + 29 模式让"harness 讨论"从厂商叙事变为结构化对话；后续工作（如 HoH/HarnessDev）已开始使用这套语言。
  • 推广场景：新领域综述的结构化先行（如 prompt 工程早期分类学）；公司新业务线的岗位与流程先定骨架；立法对新技术的规制框架先定义对象。

灵感二：收敛点即默认标准，分歧点即设计自由度

  • 核心思想：跨竞争实体的独立同构选择（如 7/11 收敛于阈值压缩）揭示约束下的必然——跟随它是低风险默认；持续分歧的选择（如耦合光谱）揭示场景依赖——那里才是设计决策的真正所在。
  • 论文证据：记忆管理收敛 vs 提供商耦合分化的对照。
  • 推广场景：行业标准制定的"事实标准优先"原则；微服务 vs 单体的持续分歧说明场景依赖；数据库选型中收敛的 SQL 接口与分歧的存储引擎；个人决策中"大家都这么做"的合理性边界。

灵感三：变化频率决定资产的代码/数据归属

  • 核心思想：当某类资产的变更频率显著超过代码发布频率，它必然从代码中分离为数据/配置/服务端资产（Codex 的"提示即数据"）。
  • 论文证据：Codex 的 per-model 提示改为服务器端运行时下发的模型目录数据。
  • 推广场景：特征旗标的诞生史；推荐系统策略从硬编码到配置中心；法规条文的"母法+实施细则"分层；教材知识点与习题集的分离。

灵感四：最小实现是理解本质复杂度的探针

  • 核心思想：构造一个仅含核心决策点的最小系统（90 行 harness），能把"本质复杂度"与"工程堆料"分离——最小实现覆盖的模式数就是本质复杂度的度量。
  • 论文证据：90 行脚手架实现 29 模式中 10 个核心模式的 9 个。
  • 推广场景：教学中的最小内核（minix 之于操作系统）；产品 MVP 的本质功能探针；物理学的 toy model；法规的最小可行案例。

灵感五：为快变对象做研究要锚定版本并做纵向对比

  • 核心思想：研究快速演化的对象（软件/制度/生态）时，单快照会迅速过时——版本锚定保证可复现，双快照纵向对比把"演化方向"本身变成研究对象。
  • 论文证据：2026 年 7 月锚定 + Gemini CLI 路由层的代际更替观察。
  • 推广场景：开源项目的长期追踪研究；政策评估的前后对照；生物演化的纵向样带；城市发展规划的分期对比。

本文基于 arXiv:2609.00006v1 全文（含七子系统逐系统解剖、模式目录与设计建议）撰写。同期 harness 三部曲：Harness-of-Harness (arXiv:2609.01481)、HarnessDev (arXiv:2609.01437)。