2 什么是 Harness？
在比较实现之前，先固定研究对象。 本节定义 Harness，梳理这个术语的短暂历史，把它与常被混淆的概念区分开，并列出语料库中每个 Harness 都以某种形式实现的七个子系统。 初入该领域的读者读完本节后应能准确知道 Harness 是什么、由什么构成；论文其余部分将逐一用生产级源代码印证这张地图的每一个格子。
2.1 定义与谱系
智能体 = 模型 + Harness。Harness 是模型之外的一切：把 LLM 与世界耦合起来的运行时——它的循环、工具、上下文、安全控制、编排与扩展接口。Harness 工程就是设计与演化这个运行时的学科。
一行代数式 Agent = Model + Harness 由 Trivedy 的 LangChain 工程系列文章在 2026 年初推广开来 [28]，而 harness engineering 一词在 2026 年 2 月进入流通：Mitchell Hashimoto 首先顺带使用，随后 Trivedy 在 LangChain 的 Deep Agents 工作背景下给出定义并加以阐述 [29]。111这个术语的出身有一层耐人寻味的讽刺：它是在 LangChain 内部被命名和定义的，而这家框架供应商的库在本语料库的每一个 Harness 运行时中都缺席（观察 13.2）。LangChain 对这种缺席的回应不是游说推广，而是发布了自己的 Harness——基于 LangGraph 构建的 Deep Agents [37]——它独立收敛到了本语料库记录的这些约定上：SKILL.md 技能加渐进披露、AGENTS.md 记忆、子智能体派生，以及 todo 规划工具。第 14.2 节将回到框架与 Harness 之间的这种双向交流。 这门学科在几周内就形成了自己的实践者文献：Böckeler 面向编码智能体用户的 Harness 工程指南 [30]（4 月）、O'Reilly 与独立作者的综述（6 月），以及社区策展的模式目录。 学术浪潮也沿着同样的弧线展开：Lin 等人的 Agentic Harness Engineering [85] 自动化了 Harness 演化；HARBOR [35] 针对基准优化 Harness；Wang 等人把代码本身重塑为 Harness 基底 [36]；Rombaut 对 13 个开源脚手架的源码分类 [34] 是本研究在方法上最近的亲缘（第 3.3 节把他的 12 个维度映射到我们的 7 个子系统上）；Macedo [33] 则给这个概念下了第一个可操作定义，推导出什么算作 Harness 的充要条件。 我们采用 Macedo 的定义核心——包裹语言模型并把它变成能在仓库上行动的智能体的那一层——并用第 2.3 节的子系统分解加以扩展；定义文献虽已有所暗示，但尚未在生产源码中落地。
2.2 Harness 不是什么
这个词的用法颇为松散，四个边界情形解释了大部分混淆 [33]。
-
•
Harness 不完全是脚手架。这两个词在实践中几乎是同义词，本文也沿用了自己早期词汇中的“scaffold（脚手架）”。在需要区分的地方，脚手架指结构性代码（循环、注册表），Harness指嵌入这些代码的成品运行时工件：Mini-SWE-Agent 的脚手架是 100 行 Python；Claude Code 的 Harness 是带终端 UI、权限系统和插件生态的产品。
-
•
Harness 不是智能体框架。框架（LangChain、AutoGen、CrewAI）是开发者引入来构建智能体的库；Harness 是开发者身处其中工作的运行时。这条界线在 2025 年还很清晰，到 2026 年正从两个方向同时消融——这正是第 14.2 节的主题。
-
•
Harness 不是评测 Harness。SWE-bench 的“harness”包裹的是智能体，让它在任务上运行；智能体 Harness 包裹的是模型，让它去行动。同一个词，包裹方向相反。
-
•
Harness 不是编排器。编排器（或称元 Harness，第 14.4 节）从上层协调一个或多个 Harness，自身不实现任何编辑循环。Omnigent 编排 11 个厂商 Harness——其中 5 个是本文的研究系统——自身不实现任何编辑循环；它是关于 Harness 的证据，而不是其中一员。
2.3 七个子系统
语料库中的每个系统，从 100 行的研究基线到百万行的生产级 CLI，都必须对同样的七个子系统表态（图 1）——即便表态的方式是刻意的缺席。 它们是第 4 节的分析维度 D1–D7，但我们认为它们也是这个工件本身的规范解剖：最小实现显示每个子系统能缩到多小——在一种情形（编排）下缩到刻意缺席——最大实现则显示每个子系统里十年的工程余量都藏在哪里。 表 1 给出这张解剖图：每个子系统做什么、观察到的最小与最大形态，以及本文在哪一节解剖它。
| 子系统 | 职责 | 最小形态 | 最大形态 | 节 |
| 智能体循环 | 交替执行推理与动作；负责停止条件与失败恢复 | Mini-SWE-Agent：线性的 while 循环跑在单个 bash 工具上 | OpenHands：基于持久事件日志的事件溯源对话，支持并行动作批次 | 6 |
| LLM 集成 | 对接供应商协议；组装提示词；管理缓存、思考与路由 | Mini-SWE-Agent：一次 LiteLLM 调用，一个 Jinja 模板 | Hermes：五个自研传输层、29 个供应商配置；Codex：服务端下发的模型目录 | 7 |
| 工具与动作 | 定义并执行智能体能做的事，首推文件编辑 | Mini-SWE-Agent：仅 bash | Claude Code：43 个类型化工具加延迟加载；Codex：工具调用作为 V8 执行的代码 | 8 |
| 记忆与上下文 | 配给上下文窗口；跨轮次与会话持久化知识 | Mini-SWE-Agent：无界线性历史 | Codex：智能体自维护的跨会话记忆管线；Gemini CLI：基于图的上下文蒸馏 | 9 |
| 安全与权限 | 决定什么直接运行、什么需要询问、什么被禁止；隔离执行 | Mini-SWE-Agent：成本与步数限制 | Codex：策略规则 + LLM 审批审查器 + 三平台操作系统沙箱 | 10 |
| 编排 | 派生并协调子智能体；连接其他智能体 | Aider：无（设计上就是单智能体） | Claude Code：递归组合；Omnigent：跨厂商协调（元层） | 11 |
| 可扩展性 | 让用户与生态添加能力：配置、Hook、技能、插件、MCP | Mini-SWE-Agent：结构化类型（Python protocols） | Pi：一切皆扩展的运行时；Codex：市场分发的插件 | 12 |
七个子系统之外还有两个横切面：接口层（TUI、CLI 参数、IDE 协议、HTTP 服务器、SDK），人类与程序通过它驱动 Harness；以及会话基底（转录、持久化、恢复/分叉），多个子系统共享它。 两者都会在语料库分析中反复出现，其中接口层尤其承载着第 14 节的平台化论证。
2.4 最小 Harness
上面的分解说明了 Harness 由什么构成；却没说每个部件需要多少。 语料库里有一个地板级别的存在性证明：Mini-SWE-Agent 用大约 100 行实现了全部七个子系统——一个 while 循环、一个模板、一个工具、一个消息列表、两个限制、没有编排，用结构化类型作为全部扩展方案——并且在 SWE-bench Verified 上报告的结果与比它大三个数量级的系统处于同一区间。222自报数字，模型与日期各不相同；见第 15 节的方法学警示。扣除这些警示，论点依然成立：地板很低。 第 16 节用 90 行的最小可用 Harness 收束这个循环，实践者可以直接复制并特化它。 把地板与生产级系统分开的，不是任务完成率，而是本文记录的其余一切：安全、恢复、成本管理、可扩展性，以及——越来越重要的——第 14 节的平台表面。