导 语

Harness Engineering 关注模型周围的整套运行系统：怎样给信息、接工具、留状态、做验证、控权限，并让失败能够被发现和修复。本文从概念边界、OpenAI 与 Anthropic 的实践，一直讲到最小落地闭环。

01

/核心参考资料

1. 视频：Harness Engineering 到底是什么？

2. OpenAI：Harness engineering: leveraging Codex in an agent-first world

3. Anthropic：Effective harnesses for long-running agents

4. Anthropic：Harness design for long-running application development

5. LangChain：The Anatomy of an Agent Harness

6. Mitchell Hashimoto：My AI Adoption Journey

7. Martin Fowler：Harness engineering for coding agent users

8. DeepSeek Harness：Architecture

02

/  一句话结论

Harness Engineering（智能体支撑系统工程）研究如何设计模型周围的整套运行系统，使模型能够持续获取信息、调用工具、执行任务、验证结果、从错误中恢复，并在权限和成本边界内稳定交付。

业界常用下面这个公式帮助理解：

Agent = Model + Harness

因此，也可以写成：

Harness = Agent - Model

这是当前常见的工程定义，尚未形成严格、统一的学术边界。广义上，模型权重之外，为智能体提供上下文、状态、工具、执行环境、反馈和约束的代码与配置都可以归入 Harness。

模型只有进入上下文、工具与验证组成的支撑系统，才有机会稳定交付。

03

/核心总结

Harness 是围绕模型搭建的运行与保障系统，让智能体能够获取信息、调用工具、持续执行、验证结果、修复错误并稳定交付。

04	/ Prompt、Context、Harness 的关系

三者的研究范围逐层扩大，彼此包含且相互配合。

维度	Prompt Engineering	Context Engineering	Harness Engineering
核心问题	这句话怎么说清楚	此刻应给模型哪些信息	怎样让整个智能体可靠完成任务
主要对象	当前提示词	模型本次调用看到的全部内容	模型周围的完整执行系统
典型内容	任务描述、约束、格式、示例	对话历史、检索结果、工具说明、记忆、上下文压缩	上下文、工具、权限、沙箱、状态、计划、工作流、验证、观测、恢复
时间范围	一次调用	一轮或多轮会话	从任务进入到交付、维护的完整生命周期
常见失败	意图含糊、输出格式错误	信息过多、关键信息缺失、上下文污染	越权操作、任务跑偏、重复犯错、无法验收、成本失控
主要优化手段	改写提示词、Few-shot、结构化输出	检索、压缩、渐进式披露、记忆选择	确定性规则、工具闭环、任务拆分、隔离环境、评估与恢复机制

可以用三个问题快速区分：

1. 我有没有把需求说清楚？—— Prompt Engineering。

2. 模型现在掌握的信息是否足够、准确、相关？—— Context Engineering。

3. 模型犯错后，系统能否发现、阻止、修复，并减少以后再次发生的概率？—— Harness Engineering。

Prompt 和 Context 仍是 Harness 的组成部分。Harness 把关注范围继续扩大到执行、反馈、治理和长期运行。

从一句话到一次调用，再到完整执行系统，工程边界逐层扩大。

05	/  一个完整 Harness 包含什么

流程定义

01flowchart LR

02    U[用户目标] --> P[需求与计划]

03    P --> C[上下文组装]

04    C --> M[模型推理]

05    M --> T[工具调用]

06    T --> E[隔离执行环境]

07    E --> O[日志、指标、截图、测试结果]

08    O --> V[验证与评估]

09    V -->|未通过| C

10    V -->|通过| R[交付结果]

11

12    G[权限、预算、超时、审批] -.约束.-> T

13    S[文件、Git、会话状态、记忆] -.支撑.-> C

14    S -.记录.-> E

1. 指令与上下文

• 系统提示词、AGENTS.md、项目规范和业务约束。

• 按任务加载相关文档，减少无关内容挤占上下文。

• 长任务中的压缩、上下文重置和结构化交接。

• 把重要事实放进模型能够搜索、读取、验证的位置。

2. 工具与执行环境

• 文件读写、搜索、终端、浏览器、数据库、日志平台、MCP 等工具。

• 语言运行时、依赖、启动脚本和测试工具。

• 沙箱、网络隔离、命令白名单和临时工作区。

• 工具描述、参数约束、失败重试和结果截断策略。

3. 状态与长期任务

• 计划、任务清单、进度文件、Git 历史和会话日志。

• 跨上下文窗口的状态交接。

• 中断恢复、幂等执行和重复任务检测。

• 多智能体之间的分工、委派和结果汇总。

4. 验证与反馈

• 单元测试、集成测试、端到端测试、静态检查和架构规则。

• 浏览器操作、截图、DOM、日志、指标和链路追踪。

• 明确的完成标准和可机器判断的验收信号。

• 生成者与评估者分离，降低自我评价偏高的问题。

5. 治理与维护

• 权限、人工审批、敏感信息保护和审计记录。

• Token、时间、调用次数和费用上限。

• 定期清理技术债、过期文档和失效规则。

• 根据真实失败记录持续调整 Harness，并用评测集验证改动效果。

可靠性来自执行、观察、验证、修复和再次运行组成的反馈闭环。

06	/  OpenAI 案例：让仓库和环境对 Codex 可读、可操作、可验证

OpenAI 在 2026 年 2 月发布的文章中介绍了一次内部实验：从空仓库开始，用 Codex 构建一个有真实用户的软件产品。五个月后，仓库约有 100 万行代码，约 1,500 个 Pull Request；最初由 3 名工程师推动，后来扩至 7 人。团队估算开发时间约为手写代码的十分之一。所有应用代码、测试、CI、文档、可观测性和内部工具均由 Codex 编写。

这些数字来自特定团队、特定产品和 agent-first 仓库，适合证明这种方法具备可行性，不宜直接当作所有团队都能达到的效率基线。

实践一：给智能体地图，避免塞入一本巨型手册

团队早期把大量规范都写入一个很长的 AGENTS.md，随后发现四类问题：

• 占用大量上下文，挤压任务、代码和相关文档。

• 所有内容都被标记为重要，模型很难判断优先级。

• 项目变化后内容迅速过期。

• 大段自然语言很难通过机械检查保持准确。

后来的做法是把 AGENTS.md 缩短到约 100 行，让它充当目录；详细知识进入结构化 docs/，通过链接和索引按需读取。这体现了渐进式披露：先给稳定入口，再让智能体沿目录寻找相关事实。

实践二：让仓库成为可版本化的事实来源

对运行中的智能体而言，无法访问的信息几乎等于不存在。聊天记录、在线文档和个人经验中的关键决策，需要整理成仓库内可搜索、可版本控制的文档、Schema、执行计划或测试。

这项实践同时改善人和智能体的协作：新成员也能沿相同路径理解设计决策，文档变更也能接受审查和自动检查。

实践三：把产品反馈直接接回智能体

OpenAI 让 Codex 能够直接观察自己的工作：

• 每个任务使用独立 worktree 和临时应用实例。

• 通过 Chrome DevTools Protocol 操作页面、读取 DOM、截图和复现问题。

• 为每个任务提供隔离的日志、指标与链路追踪。

• 用测试和 Linter 把架构约束转成可执行规则。

• 检查失败后，把明确错误反馈给 Codex，继续修改和复验。

这里的关键是形成闭环：

实现 → 运行 → 观察 → 判断 → 修复 → 再验证

如果一个要求只能由人阅读后主观判断，智能体很难稳定自治；如果它能变成测试、规则、截图对比或指标阈值，智能体就能自己迭代。

实践四：持续清理代码和文档

高吞吐会快速放大重复代码、命名漂移、架构偏离和过期文档。OpenAI 使用后台任务扫描技术债与文档漂移，并提交修复。这相当于为代码库配置持续运行的“垃圾回收”。

OpenAI 路线的重点

提高整个项目对智能体的可理解性，并把质量要求变成可以自动执行的反馈。

短入口、结构化文档、测试与日志共同构成智能体可读的工程地图。

07	/  Anthropic 案例：用规划、交接和独立评估支撑长任务

Anthropic 的两篇文章体现了 Harness 的逐步演进。

第一阶段：Initializer + Coding Agent

早期实验要求智能体克隆 claude.ai。直接执行高层需求时，常见问题包括：

• 试图一次完成全部功能，在上下文耗尽时留下半成品。

• 下一轮会话不了解前序状态，只能猜测。

• 看到已有界面便过早宣布完成。

• 花费大量时间重新判断项目怎样启动和测试。

对应方案：

• Initializer Agent

  ：初始化 Git 仓库、init.sh、功能清单和进度文件。

• Coding Agent

  ：每次推进一部分，开始时读取状态，结束前测试、提交并留下结构化进度。

核心思想是让文件和 Git 承担跨会话记忆，使新的上下文能够从可验证状态继续工作。

第二阶段：Planner + Generator + Evaluator

后续方案把职责进一步拆开：

• Planner

  ：把 1～4 句高层需求扩展成完整产品规格，主要描述目标和交付物。

• Generator

  ：按照规格实现产品，运行代码并进行初步检查。

• Evaluator

  ：独立操作应用，按明确标准评估功能、设计和代码质量，并提供缺陷清单。

初版中，Generator 与 Evaluator 会先协商每个 Sprint 的完成标准，随后进入实现和验收循环：

text

01用户需求

02  ↓

03Planner：形成产品规格

04  ↓

05Generator + Evaluator：约定完成标准

06  ↓

07Generator：实现并自检

08  ↓

09Evaluator：独立测试和反馈

10  ↓ 未通过

11Generator：修复

12  ↓ 通过

13进入下一阶段或交付

独立评估仍需调优。Anthropic 观察到，未经专门调校的评估智能体也会测试得很浅，甚至主动忽略自己已经发现的问题。因此，Evaluator 需要具体评分项、硬门槛、真实操作工具和持续评测。

Solo 与 Full Harness 的实验对比

项目	Solo	Full Harness
模型	Claude Opus 4.5	Claude Opus 4.5
任务	根据一句话构建复古游戏制作工具	相同
结构	单个智能体直接实现	Planner + Generator + Evaluator
耗时	20 分钟	6 小时
Token 成本	9 美元	200 美元
结果	界面初看可用，核心游戏交互失效	功能和视觉明显更完整，仍有交互与边界问题

Full Harness 的成本超过 Solo 的 20 倍。该结果只代表这一次实验，不能推导为固定倍率。它说明：当任务超出单个模型的稳定能力范围时，规划与独立评估可能显著提升结果，同时会增加时间、Token 和系统复杂度。

模型变强后，Harness 要做减法

Anthropic 在 Opus 4.6 上移除了逐 Sprint 强制拆分，并把 Evaluator 改为末尾评估。原因是模型已经能够更长时间保持一致性。其结论很实用：

• Harness 中的每个组件都隐含了一个假设——模型独立完成这件事不够可靠。

• 模型升级后要重新验证这个假设。

• 对模型已经能稳定处理的任务，额外评估只会增加开销。

• 对仍处于模型能力边缘的任务，Planner 和 Evaluator 继续具有价值。

规划、实现和评估通过持久化交接物跨越上下文窗口。

08	/  OpenAI 与 Anthropic 路线比较

维度	OpenAI	Anthropic
主要问题	如何让大量 Codex 任务持续维护一个生产仓库	如何让智能体跨长时间完成复杂应用
重点对象	仓库、工具环境、可观测性、架构规则、技术债	任务规划、跨会话交接、生成与评估分工
主要状态载体	仓库文档、执行计划、代码、worktree、日志指标	功能清单、进度文件、Git、Agent 间文件
反馈方式	测试、Linter、浏览器、日志、指标、链路追踪	独立 Evaluator、Playwright、评分标准、缺陷反馈
人的主要职责	指定方向、建设环境、把规则变成可执行约束	定义目标、设计评估标准、调优角色与流程
主要代价	建设和维护 agent-first 工程基础设施	明显增加运行时间、Token 和编排复杂度
共同原则	让失败可观察，让规则可执行，让状态可延续，让改进可积累	同左

两条路线可以组合：仓库级知识与可观测环境负责提供可靠基础，Planner、Generator、Evaluator 负责组织复杂任务的执行过程。

09	/  Harness、Framework、Runtime 的边界

这些词在不同项目中会有重叠，可以按职责理解：

名称	主要回答的问题	例子
Agent Framework	用哪些抽象编写智能体	Agent、Tool、Graph、Middleware 等开发接口
Agent Runtime	智能体运行时怎样调度与保存状态	Agent Loop、事件流、会话、重试、并发、生命周期
Agent Harness	怎样围绕某类任务组织模型、环境、规则和反馈	工具组合、沙箱、上下文策略、计划、审批、评估闭环
Harness Engineering	怎样持续发现失败并改进上述系统	用失败样本改规则、工具、评测和工作流

同一个产品可以同时具备 Framework、Runtime 和 Harness 属性，名称取决于讨论视角。

10	/  与 DeepSeek Harness 的关系

Harness Engineering 是一类工程方法，DeepSeek Harness 是这类方法的一个具体开源实现。

结合此前对 DeepSeek Harness 源码的研究，它采用 Cordis 插件体系：

• Profile、Bundle、Preset 负责组装一次运行所需的能力。

• Agent Loop 负责 Turn、Step、模型调用和工具执行。

• Session Event Log 保存持久事实，使模型可见历史可以从日志重建。

• 文件、终端、审批、后台任务、Skill、计划、压缩、子智能体和工作流等能力通过插件组合。

所以，DeepSeek Harness 展示的是“怎样实现一套可替换、可组合的 Harness Runtime”；视频讨论的是“为什么需要 Harness、应优化哪些环节，以及它是否值得被称为一门独立工程方法”。

11	/  “是不是炒概念”的判断

认为被高估的理由

• 测试、Linter、沙箱、工作流、任务拆分、代码审查和可观测性都是已有技术。

• Harness Engineering

   这一叫法在 2026 年 2 月才快速传播，定义仍在变化。

• 一些针对当前模型弱点设计的复杂流程，会随模型能力提升而失去价值。

• 过度编排会带来更高成本、延迟和维护负担。

仍然值得重视的理由

• 旧技术被组织成围绕智能体可靠性的统一方法后，可以系统设计和持续改进。

• 权限、外部工具、持久状态、审计和真实环境反馈无法仅靠模型权重提供。

• 当前模型仍会产生幻觉、提前结束、遗漏要求和高估自身结果。

• OpenAI、Anthropic 和 LangChain 都展示了只调整模型外围系统便能显著改善效果的案例。

我的判断

Harness Engineering 是当前阶段非常实用的系统工程方法。部分补偿模型弱点的组件会逐步简化，工具接入、权限控制、状态持久化、环境隔离、可观测性和业务验收仍会长期存在。

更准确的趋势可以表述为：

模型与 Harness 共同演进。模型吸收通用能力，Harness 保留环境连接、业务约束和可验证反馈，并继续承接更复杂的任务。

12

/  最小落地方案

不需要一开始就搭建三个智能体或完整平台。先为一个重复出现、边界清楚的任务建立最小闭环。

第一步：选择失败可判断的任务

优先选择具备以下条件的任务：

• 输入和预期产物清楚。

• 能通过测试、规则或清单判断成功。

• 执行环境可以隔离。

• 失败后能够安全重试。

第二步：提供最小知识地图

• 用一份短入口文档说明项目结构、关键命令、约束和文档索引。

• 把详细规则放在对应模块附近，按需读取。

• 把重要决策、完成标准和已知限制放进版本库。

第三步：接通执行和观察工具

• 让智能体能够启动项目、运行定向测试、读取日志。

• 涉及界面时提供浏览器操作、截图和 DOM。

• 涉及服务时提供指标、链路和可搜索日志。

• 为高风险操作配置权限边界和人工审批。

第四步：建立验证循环

text

01明确完成标准 → 实现 → 执行检查 → 读取失败证据 → 修复 → 再检查

先使用确定性检查。主观质量确实重要时，再增加独立 Evaluator，并给它具体评分规则和真实操作工具。

第五步：从失败中更新系统

每次失败后判断缺口属于哪一层：

• 需求不清楚：改 Prompt 或需求模板。

• 信息缺失或污染：改 Context 选择与知识结构。

• 工具不足：补工具或环境能力。

• 无法判断结果：补测试、观测或验收标准。

• 权限风险：补沙箱、审批和操作限制。

• 长任务失忆：补状态文件、Git 记录或结构化交接。

改完后把真实失败加入回归评测，确认同类问题不再出现。这是 Harness Engineering 最有价值的循环。

从一次真实失败出发，归因、改系统、做回归，失败才会沉淀为能力。

13

/  设计检查表

上下文

• □

    入口说明是否足够短，并能指向详细资料？

• □

    关键事实是否可搜索、可版本化、可验证？

• □

    是否只加载当前任务需要的内容？

• □

    长任务是否有压缩、重置或交接方案？

执行

• □

    智能体是否知道怎样安装、启动、测试和停止系统？

• □

    执行环境是否隔离？

• □

    工具权限是否遵循最小授权？

• □

    重试、超时和预算是否明确？

验证

• □

    “完成”的标准能否被执行或观察？

• □

    是否同时覆盖实际用户路径和静态代码检查？

• □

    失败信息是否足够具体，能直接指导下一轮修改？

• □

    主观评估是否与生成过程分离？

维护

• □

    是否记录任务进度和关键决策？

• □

    是否能发现过期文档和失效规则？

• □

    是否保存失败案例并进行回归测试？

• □

    模型升级后是否重新评估 Harness 中的复杂组件？

14

/  容易踩的坑

1. 把长提示词当成完整 Harness

   ：提示词不能提供真实执行、权限隔离和确定性验证。

2. 把所有资料一次塞进上下文

   ：内容越多不代表有效信息越多，应使用索引和渐进式披露。

3. 让生成者独自判断质量

   ：自检可以保留，关键交付还需要确定性测试或独立评估。

4. 只检查代码，不操作产品

   ：界面能打开不等于流程可用，需覆盖真实用户路径。

5. 只增加智能体数量

   ：角色越多，通信、成本和失败面越大；先证明每个角色有独立价值。

6. 忽略权限和审计

   ：自主执行能力越强，越需要沙箱、审批、凭证隔离和操作记录。

7. 把案例数字当成普遍收益

   ：100 万行代码、十倍效率、20 倍成本都来自特定实验。

8. 模型升级后保留全部旧流程

   ：定期移除已经失去作用的步骤，避免 Harness 腐化。

15

/  最终总结

Harness Engineering 的价值可以归纳成一句话：

把个人反复纠正智能体的经验，沉淀为系统可执行、可观察、可复用的能力。

衡量一套 Harness 的水平，不应只看它接了多少工具或部署了多少智能体，更应看以下结果：

• 同类错误是否逐步减少。

• 复杂任务是否能够持续推进并恢复。

• 质量要求是否能够自动验证。

• 高风险行为是否始终处于权限边界内。

• Token、时间和人工注意力是否得到合理使用。

• 模型更换或升级后，系统能否以较低成本调整。

当这些能力形成闭环，模型的概率性输出才有机会变成稳定的工程产出。

16

/  原始资料