概念入口
围绕 harness engineering 的讨论里，最容易混淆的是对象、机制和工程实践三层。先分清三个问题：
- 什么算
agent harness - 什么只是机制，还不能算
agent harness本身 harness engineering讨论的到底是对象，还是围绕这些机制展开的工程实践
本文讨论的是软件工程语境中的 harness engineering。离开这个语境，harness 这个词可以被用得更宽；一旦进入代码仓库、工具调用、验证回路和长任务，它所承载的工程负载才会足够具体，值得被单独讨论。
先讲证据边界
Section titled “先讲证据边界”下文的判断主要分成两层：
事实陈述来自 Anthropic、OpenAI、Martin Fowler、LangChain 等公开一手材料，尤其是 关键文章研究解释是为了把不同系统放进同一张比较坐标而采用的工作划分，用来帮助读者区分AI Agents、Agent Harnesses，以及Harness Engineering这条实践视角
因此，本文采用的不是某个官方统一定义，而是一套可追溯、可比较、可继续扩展的工作定义。更完整的边界规则见 术语与证据边界；如果你想知道这些文章是如何被逐篇拆成稳定比较材料的，再看 文章证据工作法。
第一问：什么算 agent harness
Section titled “第一问：什么算 agent harness”在软件工程语境里，这三个词经常被混用，但它们不是一回事：
agent harness更偏系统对象，指模型外面那层让代理能进入真实工作面、被控制、被恢复、被约束的外壳harness 机制更偏构件层，指提示词、MCP、工具、钩子、技能、子代理、记忆、审批、沙箱和验证回路等机制harness engineering更偏工程实践，指人类如何把这些对象和机制组合成稳定的方法，让代理能持续做项目开发
OpenAI、Anthropic 和 LangChain 都在讨论这些相关层次，只是重心不同。OpenAI 更明显地讨论人如何设计环境、规则与反馈回路来治理代理；Anthropic 更强调怎样把 harness 设计成能跨上下文持续推进的系统；LangChain 则更倾向于把模型外面的部件层整体摊开来看。
如果再把当前站点的主叙事对齐得更稳定，当前更适合这样读：
AI Agents指直接作为宿主或代理产品出现的系统，例如Claude Code、Codex、OpenCodeAgent Harnesses指叠加在宿主之上的外层系统，包括宿主增强型 harness、方法系统型 harness 和交付套件型 harness
而 Harness Engineering 讨论的是：人如何围绕这些对象和机制层，组织出稳定可持续的开发方法。
更底层的 orchestration / runtime / automation substrate 当然存在，但它们太底层、也不是本站当前主叙事，所以这里不单列展开。
这里的“重心不同”不是凭感觉写出来的，而是来自对关键文章的两步读取：先看文章重心落在哪些要素上，再区分原文可核对内容、作者 framing 和仓库解释。完整方法见 文章证据工作法。
第二问：什么只是机制，不是 agent harness 本身
Section titled “第二问：什么只是机制，不是 agent harness 本身”很多讨论一上来就在讲提示词设计、上下文工程、MCP、工具、钩子、技能、子代理，但这些东西通常更接近机制层，而不是 agent harness 本身。
提示词设计、上下文工程、MCP、工具、钩子、技能、子代理往往属于 harness 的机制层- 它们很重要，但不自动等于
agent harness本身 - 真正的区别不在有没有这些机制，而在这些机制是否被组织进一个可运行、可恢复、可治理的系统表面
第三问：什么才是 harness engineering
Section titled “第三问：什么才是 harness engineering”所谓 harness engineering，不是单指某个代理会不会写代码，而是指人如何围绕 agent harness 及其机制层，把模型能力变成持续可运行、可恢复、可验证、可协作的系统能力。
它真正关心的是模型外面那层让代理变得可持续、可读、可控的系统：
- 任务如何进入系统，如何被拆解、委派、恢复和完成
- 代理如何被规则、工具、状态、审批、验证与记忆层约束
- 如何把聪明模型变成能连续产出结果的工程系统
- 宿主、协议、线程生命周期与客户端表面如何共同构成可复用运行时
可以先记住一句话：
agent harness是对象，harness 机制是构件层，harness engineering是围绕它们展开的工程实践。
它关心的不是某一项机制单独强不强，而是这些机制怎样被组合、治理、验证与演化。
第四问：它为什么不等于提示词工程、宿主或工作流编排
Section titled “第四问：它为什么不等于提示词工程、宿主或工作流编排”- 不等于单次提示词工程
- 不等于某个 IDE 插件或聊天入口本身
- 不等于任何一个单独机制，比如只等于
MCP、只等于技能或只等于钩子 - 不等于只会写演示样例的自主代理
- 不等于只提供编排原语、但没有明确宿主工作面和执行约束的抽象框架
换句话说：
AI Agents不等于Harness EngineeringAgent Harnesses是当前最接近本文讨论中心的对象层，但它本身也不等于实践层
在编程代理语境里，只要一种说法还没有回答“代理在哪里工作、谁来控制下一步、状态如何续跑、人类怎样介入”，它就还没有真正进入 harness engineering 的讨论中心。
最近两条已经跑通的宿主链路研究还提醒了另一点：光说“人类怎样介入”还不够，最好继续追问它的 用户参与契约 是什么。也就是：
- 用户通常通过什么接口触发一条流程
- 用户一开始要提供什么材料
- 用户会在哪些节点被要求批准、回答、补充或停止
- 长任务要继续时，系统要求用户回到哪个状态面上接手
这组问题很适合被当成后续比较宿主与 harness 的补充判断轴。
第五问：一个系统至少要回答哪些问题，才算真正进入这个讨论
Section titled “第五问：一个系统至少要回答哪些问题，才算真正进入这个讨论”一个面向编程任务的 harness，至少要回答下面这些问题：
| 问题 | 它在追问什么 | 如果答不上来会怎样 |
|---|---|---|
| 代理在哪里工作 | 它有没有真实宿主工作面，能不能读写 repo、跑命令、接触外部系统 | 系统会退回到“会说不会做” |
| 谁决定下一步 | 主控制中心在运行时、流水线关卡、策略层还是人工审批 | 长任务里很快会失去节奏 |
| 什么东西会被持续保存 | 状态、记忆、进度工件、交接文档是否能跨轮继续工作 | 会话一断就从头理解 |
| 失败如何回流 | 失败是回到原控制器、回到规划环节，还是只做局部重试 | 失败恢复成本不可见 |
| 人类怎样掌舵 | 审批、边界、规则、评审、合并纪律是否是系统对象 | 系统会变成不可读黑箱 |
| 用户参与契约是什么 | 触发、输入、批准与恢复这些接口是不是清晰、稳定、可持续复用 | 系统会退化成“看起来什么都能做，但用户不知道何时该介入” |
这组问题主要适用于本文关注的、以宿主为中心的编程代理系统，也是后面 生态与比较 和 研究专题 最常用的比较坐标。它们不是所有 agent harness 的唯一标准，但对软件工程场景尤其关键。
若把当前最常见的对象层与瓶颈一起摊开来看，更稳的对齐方式是下面这张表：
| 对象层 | 主要关注点 | 典型对象 | 主要瓶颈 |
|---|---|---|---|
AI Agents | 让代理真正进入仓库、改文件、跑命令、做验证 | Codex、Claude Code、OpenCode、Goose | 单次任务能否真正执行完 |
Agent Harnesses | 在宿主之上补控制、恢复、记忆、规则、角色和用户参与契约 | OMO、OMX、Trellis、BMAD、gstack、Ralph | 长任务能否持续、可控、可恢复地跑 |
关键不在“后一层取代前一层”，而在工程负载逐渐外移：先是把代理放进真实工程环境，再是把长期控制和恢复压到外层 harness，最后才是把这些能力组织成稳定的方法与实践。
Harness Engineering 则不在这张对象层表里。它更像一条横切实践线：讨论人如何围绕这些对象设计规则、状态、验证回路、交接方式与方法体系。
第六问：和相邻对象相比，边界到底在哪里
Section titled “第六问：和相邻对象相比，边界到底在哪里”边界要靠并排比较才更清楚：
| 对象 | 它主要解决什么 | 为什么不等同于 harness engineering | 与 harness 的关系 |
|---|---|---|---|
提示词工程 | 改写输入、提示和任务表述 | 它通常不直接提供持久状态、工具执行、验证、审批或恢复机制 | 常常进入 harness 的机制层，但不是整体 |
AI Agents | 给代理一个能进入真实工程环境的主执行面 | 它回答的是“代理在哪里工作”，不自动回答“长期怎么控、怎么续跑、怎么交接” | 往往是 harness 的宿主层 |
Agent Harnesses | 围绕宿主增加规则、记忆、钩子、评审、恢复、角色和团队结构 | 它是系统对象，关注的是模型外部的控制面设计，而不是实践层本身 | 是当前重点考察的对象层 |
Harness Engineering | 组织规则、状态、评审、交接、验证与方法体系 | 它讨论的是围绕对象和机制展开的工程实践，不是另一类产品 | 横切 AI Agents 和 Agent Harnesses |
通过这种比较可以更稳地看到本文关心的边界：重点不是“所有代理系统”，而是怎样把对象层和实践层分开，再观察模型外部那层把代理变成工程能力的工作面、控制面和恢复面。
第七问：如果开始做 harness engineering，通常在设计什么
Section titled “第七问：如果开始做 harness engineering，通常在设计什么”如果把 harness engineering 看成围绕 agent harness 及相关机制展开的工程实践，通常就要设计下面这些机制层与控制面：
| 构成 | 它回答什么 | 典型来源 |
|---|---|---|
提示与上下文工程 | 系统提示词、指令文件、上下文注入怎样帮助代理稳定行动 | Anthropic agents / tools、OpenAI harness、LangChain anatomy |
MCP / 协议化能力表面 | 工具、资源、提示模板这类能力怎样被稳定暴露给代理与客户端 | MCP 官方文档、Anthropic tools、OpenAI Codex MCP 文档 |
状态与持久化 | 代理怎样跨会话保存和恢复工作状态 | Anthropic 长任务文章、LangChain anatomy |
工具与接口表面 | 代理面对的工具表面是否可理解、边界清晰 | Anthropic agent / tools 两篇 |
执行环境 | 代理是否有真实 repo、命令和外部系统工作面 | OpenAI harness / app server 文章 |
反馈与验证回路 | 测试、浏览器、日志、评审如何反向塑造下一轮 | Anthropic 长任务、OpenAI harness、LangChain 深代理材料 |
上下文管理与知识注入 | 每轮到底带什么知识继续运行 | Anthropic long-running apps、OpenAI harness |
约束、规则与边界 | 防护栏、工具边界、停止条件怎样工作 | Anthropic tools / agents、OpenAI harness |
续跑、交接与恢复 | 长任务如何形成干净交接，而不是重新猜状态 | Anthropic 长任务、社区实践材料 |
宿主协议与客户端表面 | 在以宿主为中心的 harness 中，thread、turn、approval、diff、工具执行 怎样变成稳定接口 | OpenAI app server / harness |
人类控制面 | “人类掌舵，代理执行” 如何真正成立 | OpenAI harness、Anthropic agent systems |
这些项更适合先被读成 harness 机制，而不是都被读成 agent harness 本身。它们之所以重要，不是因为每一项单独就等于 harness，而是因为真正的 harness engineering 总是在设计这些机制怎样协同工作。
这些构成若放到具体系统里看，差异会更清楚，可继续读 研究专题。
为什么现在重要
Section titled “为什么现在重要”从 2025-2026 的公开材料看，“模型已经够强，所以剩下只是工程包装”这个说法已经不够准确。更贴近当前状态的表述是：
- 瓶颈正在从“局部代码能不能生成出来”迁移到“代理能不能在真实环境里持续推进、验证、恢复并交接下去”
- 执行环境本身已经成为承重部分
agent harness正在从“内部脚手架”走向“可复用的工程表面”harness engineering也在从零散提示技巧走向更稳定的工程方法语言- 它的重要性不是静态上升，而是随着模型改进不断换位置，新的模型会让旧脚手架失去必要性，也会暴露新的瓶颈
但也要避免另一个极端：不是所有代理系统都必须长成 Codex App Server 这种形态。对 OpenAI 来说，协议化客户端表面是核心；对 Anthropic 的长任务研究来说，初始化器、进度工件和干净交接更居中；对 LangChain 的部件式定义来说，harness 的边界甚至可以宽到“模型之外的一切”。重点不是消灭这些差异，而是把它们保留下来。
因此既需要保留 关键文章 的时间线，也需要把 工程观察 和 生态与比较 这两种页面分开写。