Harness Engineering：AI Agent 时代的新工程范式
Deep Research 报告 | 2026 年 3 月 | 面向 AI 从业技术人员
2026 年初，AI 软件工程领域涌现出一个迅速引发广泛关注的新概念——Harness Engineering（驾驭工程）。它不是关于更好的提示词，不是更大的模型，而是关于如何为 AI Agent 构建一套能让其可靠运行的"脚手架"体系。
OpenAI 用它完成了 100 万行零人工编写的代码；Stripe 用它每周自动合并超过 1300 个 Pull Request；LangChain 用它在不更换模型的前提下，将代理评分提升 13.7 个百分点并跻身行业排行榜前五。
本文将带你全面梳理 Harness Engineering 的起源、定义、核心技术、产业实践与行业影响。
一、概念从哪里来
从一个比喻说起
"Harness"在英语中是"马具"的意思——缰绳、马鞍、嚼口，是驾驭一匹强大但方向不定的马所需的全套装备。
这个比喻放在 AI 工程中，异常贴切：
马 = AI 模型：强大、快速，但不知道该去哪里
马具（Harness） = 基础设施：约束、护栏、反馈循环，引导模型的能力被有效利用
骑手 = 人类工程师：提供方向，而不是自己跑
没有马具，AI Agent 就像一匹在空旷草原上的纯血马——惊人的速度，却无法完成任何有意义的目标。
术语的诞生：Mitchell Hashimoto，2026 年 2 月 5 日
"Harness Engineering"这个术语由 Mitchell Hashimoto（HashiCorp 联合创始人、知名开源终端 Ghostty 的开发者）在博客文章《My AI Adoption Journey》中正式提出。
他在"Step 5: Engineer the Harness"章节中写道：
"The most sure-fire way to achieve this is to give the agent fast, high quality tools to automatically tell it when it is wrong... It is the idea that anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again."
这句话揭示了 Harness Engineering 的核心理念：当 Agent 犯错时，不要只是重试，而是永久性地工程化解决这个问题。
在实践中，这一理念体现为两种形式：
- 改善隐式提示（AGENTS.md 文件）：将错误模式和规则写入 Agent 指令文件，几乎能彻底消除重复错误。Hashimoto 为 Ghostty 项目维护的 AGENTS.md 中，每一行都对应一个真实观察到的 Agent 失败。
- 构建实际工具：截图工具、定向测试脚本、自定义验证器——配合 AGENTS.md 让 Agent 知道这些能力的存在并在需要时使用。
OpenAI 将概念推向行业：2026 年 2 月 11 日
Hashimoto 的文章发布仅 6 天后，OpenAI 发布了工程博客《Harness engineering: leveraging Codex in an agent-first world》，记录了他们为期 5 个月、零行人工编写代码的软件构建实验，并以"Harness Engineering"作为整篇文章的核心关键词。这篇文章将一个个人实践词汇推向了行业视野。
ThoughtWorks 杰出工程师 Birgitta Böckeler 随后在 Martin Fowler 的博客上发表深度分析文章（2026 年 2 月 17 日），将 Harness 类比为今天软件工程中的"服务模板"，认为这可能成为 AI 时代的新抽象层，进一步确立了这一概念在主流工程师社区中的合法性。
二、什么是 Harness Engineering
正式定义
Harness Engineering 是设计和实现一套系统的工程学科，该系统围绕 AI Agent 构建，使其能够可靠、持续地完成复杂任务。一套完善的 Harness 具备四项核心能力：
| 能力 | 含义 |
|---|---|
| 约束（Constrain） | 限制 AI Agent 能做什么（架构边界、依赖规则） |
| 告知（Inform） | 让 Agent 知道该做什么（上下文工程、文档化知识库） |
| 验证（Verify） | 检查 Agent 是否做对了（测试、lint 检查、CI 验证） |
| 纠正（Correct） | 当 Agent 出错时纠正它（反馈循环、自我修复机制） |
更简洁地说：Harness 是包裹在 AI 模型之外、管理一切非推理事务的软件基础设施。
与相关概念的边界
Harness Engineering 容易与几个相邻概念混淆，下表明确各自的范围和核心关注点：
| 概念 | 范围 | 核心关注点 |
|---|---|---|
| 提示词工程 | 单次交互 | 构造有效提示 |
| 上下文工程 | 模型上下文窗口 | 模型看到什么信息 |
| Harness Engineering | 整个 Agent 系统 | 环境、约束、反馈、生命周期 |
| Agent 工程 | Agent 内部架构 | 内部设计和路由 |
| 平台工程 | 基础设施 | 部署、扩展、运维 |
Harness Engineering 包含上下文工程，借鉴提示词工程，但在更高层次上操作——它关注的是让 Agent 可靠运行的完整系统，而不仅仅是单次交互的输入。
为什么 Agent 必须有 Harness
LLM 天生是无状态的——每次新会话从空白记忆开始。这就像一个软件项目由倒班工程师完成，每位新工程师到来时对前一班发生的一切毫无记忆。没有 Harness 的 Agent，会持续遭遇以下六种典型失败模式：
| 失败模式 | 具体表现 |
|---|---|
| 贪心执行 | 试图在一次会话中完成所有工作，上下文用尽时仅完成一半 |
| 过早宣告成功 | 看到部分进度就认为任务已完成 |
| 死循环（Doom Loop） | 对同一处错误代码反复做微小修改，超过 10 次而毫无进展 |
| 幻觉工具调用 | 调用不存在的 API 或传入错误的参数类型 |
| 状态丢失 | 网络超时或服务器重启清除全部内存进度 |
| 上下文腐烂 | 随着会话延长，早期指令被"淹没"在大量中间内容中 |
关键洞见：绝大多数情况下，模型没有问题，问题出在 Harness 上。当 Agent 失败时，答案几乎从不是"更加努力地提示"，而是"改进它运行的环境"。
三、Harness 的核心架构
Harness 不是一个单一组件，而是多个子系统的协调配合。目前业界已形成三套有代表性的架构方案，分别来自 OpenAI、Anthropic 和 LangChain。
OpenAI：三大支柱框架
OpenAI 在其工程博客中将 Harness 归纳为三个核心支柱，这也是目前被引用最广泛的框架。
支柱一：上下文工程（Context Engineering）
核心原则只有一条：仓库（Repository）即系统记录。
从 Agent 的角度看，它无法在上下文中访问的任何内容都等于不存在。OpenAI 的解决方案是将仓库设计为 Agent 的"全部世界"，使用一个约 100 行的简短 AGENTS.md 作为目录，指向结构化的 docs/ 知识库：
AGENTS.md ← 表目录，约 100 行，作为导航入口
ARCHITECTURE.md ← 顶层架构图
docs/
├── design-docs/ ← 设计文档（带验证状态和核心信条）
├── exec-plans/ ← 执行计划（活跃 / 已完成 / 技术债追踪）
├── generated/ ← 自动生成文档（如数据库 Schema）
├── product-specs/ ← 产品规格说明
└── references/ ← 外部库的 LLM 友好文本这种设计实现了渐进式披露（Progressive Disclosure）——Agent 从一个小而稳定的入口出发，被引导去哪里找更深层的真相，而不是一开始就被 1000 行规则淹没。
支柱二：架构约束（Architectural Constraints）
不是告诉 Agent 写好代码，而是机械地强制执行好代码的样子。OpenAI 在每个业务域内强制执行固定的依赖方向：
Types → Config → Repo → Service → Runtime → UI任何违反这一方向的跨层依赖，都会被自定义 Linter 和结构测试自动阻断，无法通过 CI。这带来了一个反直觉的发现：约束反而让 Agent 更高效。当 Agent 可以生成任何东西时，它会浪费大量 Token 探索死胡同。当 Harness 定义了清晰边界，Agent 更快地收敛到正确方案。
支柱三：熵管理（Entropy Management）
这是最容易被忽视、却至关重要的支柱。随着时间推移，AI 生成的代码库会自然积累熵。OpenAI 发现，如果放任不管，工程师每周要花**整整一天（周五全天，占 20% 工时）**人工清理"AI 产生的劣质代码"。解决方案是将熵管理本身也交给 Agent——文档一致性 Agent、约束违规扫描 Agent、模式执行 Agent 定期自动运行，技术债如同垃圾收集一样被持续治理。
Anthropic：初始化器—执行器双阶段模式
Anthropic 针对长期运行 Agent（跨多个上下文窗口）设计了两阶段 Harness 架构，直接内置进 Claude Agent SDK。
阶段一（只运行一次）：初始化 Agent 建立项目环境——创建 JSON 格式的特征列表（200+ 个功能需求，全部初始标记为 "passes": false）、编写 init.sh 脚本、初始化 git 和进度日志文件。
阶段二（每次会话重复执行）：每次新会话都从读取 git 日志和进度文件开始，选择最高优先级的未完成特征，实现并用浏览器自动化进行端到端验证，最后提交 git 并更新进度文件。
关键工程细节：特征列表选用 JSON 而非 Markdown 格式，因为 LLM 意外覆盖或重新格式化 JSON 的概率远低于 Markdown，这一细节显著提升了多会话间的状态稳定性。
LangChain：可组合中间件层模式
LangChain 将 Harness 设计为可独立部署、可测试、可演进的中间件链条：
Agent 请求
↓ LocalContextMiddleware → 映射代码库目录结构，注入工具清单
↓ LoopDetectionMiddleware → 追踪每文件编辑次数，检测并打破死循环
↓ ReasoningSandwichMiddleware → 推理预算：规划(xhigh)→执行(high)→验证(xhigh)
↓ PreCompletionChecklistMiddleware → 退出前强制执行验证清单
Agent 响应推理三明治（Reasoning Sandwich） 是 LangChain 的独特贡献：在任务规划和最终验证阶段使用最高推理预算，在中间实现阶段使用中等预算，在避免超时的同时，在最关键的两个节点上保证了输出质量。
四、谁在推动，效果如何
Harness Engineering 不是纯理论，它由几家头部机构的工程团队用真实生产数据验证。以下是四个具有代表性的实践案例。
OpenAI × Codex：史上最大规模的零人工代码实验
2025 年 8 月，OpenAI 一个小团队启动了一场实验：用 Codex Agent 构建一款内部软件产品，并设立一条铁律——零行人工编写代码。这不是演示，而是要交付给真实用户使用的产品。
| 指标 | 数据 |
|---|---|
| 最终代码量 | 超过 100 万行 |
| 开发时间 | 5 个月（估计是人工编写的 1/10） |
| 合并 PR 数量 | 约 1500 个 |
| 人均日产出 | 3.5 PRs / 工程师 / 天 |
| 团队规模变化 | 3 人 → 7 人（吞吐量随之持续提升） |
| 产品状态 | 数百名内部日活用户 + 外部 Alpha 测试者 |
在这套体系中，工程师不再写代码。他们的工作变成了：将大目标分解为 Agent 可执行的小构建块；当某件事失败时，不问"怎么提示才能让它成功"，而是问"缺少什么能力，如何让 Harness 使这类失败永远不再发生"。
当 Harness 足够成熟后，给出单个提示，Agent 可以独立完成：复现 Bug、录制视频证明失败、实现修复、验证修复、开 PR、响应代码审查、合并变更——全程无需人工介入。
"Our most difficult challenges now center on designing environments, feedback loops, and control systems."
— Ryan Lopopolo, OpenAI
Stripe × Minions：每周 1300+ PRs 的生产验证
Stripe 的代码库有数亿行 Ruby 代码，使用大量内部专有库，每年处理超过 1 万亿美元支付量——这种规模和复杂度使得通用 Agent 工具几乎无法直接适用。他们选择从头构建，深度定制自己的 Harness。
Stripe 的 AI 编码 Agent 系统名为"Minions"，一次典型的 Minion 运行从 Slack 消息开始，到人工可审查的 PR 结束，中间无需任何人工交互：
Slack 一条消息（任务描述）
→ Minion 读取代码库上下文 + MCP 工具调用（Toolshed 提供 400+ 工具）
→ 编写代码 → 本地 lint 检查（5 秒内）→ CI 测试（最多 2 轮，含自动修复）
→ 创建分支 + 推送 + 开 PR → 人工审查 → 合并| 指标 | 数据 |
|---|---|
| 每周合并 PR 数 | 超过 1300 个（从最初 1000 个持续增长） |
| "Atlas Fix-It Week" | Minions 自主解决了全部 Bug 的 30% |
| 代码来源 | 全部 PR 不含人工编写代码，但经过人工审查 |
LangChain：最干净的对照实验——同一模型，不同 Harness
LangChain 实验的价值在于设计的纯粹性：完全固定底层模型（gpt-5.2-codex），只修改 Harness。效果提升可以被明确归因于 Harness 的改进，而非模型更换。
| 改进 | 实现方式 | 解决的问题 |
|---|---|---|
| 自验证循环 | PreCompletionChecklistMiddleware 拦截退出行为 | 防止 Agent 过早声称任务完成 |
| 上下文注入 | 启动时自动映射目录结构和可用工具 | Agent 从会话开始就了解环境 |
| 死循环检测 | 追踪每文件编辑次数，超阈值触发策略重置 | 终止对同一错误代码的无效重复 |
| 推理三明治 | 规划和验证用 xhigh，实现用 high | 在时间约束内最大化关键节点质量 |
结果：Terminal Bench 2.0 评分从 52.8% → 66.5%（+13.7 点），排行榜排名从 Top 30 之外 → Top 5，底层模型零变化。
Anthropic 与学术界
Anthropic 工程团队用构建 claude.ai 克隆版本的实验验证了跨会话 Harness 的效果：无 Harness 时，Opus 4.5 无法跨多个上下文窗口完成生产级 Web 应用；有 Harness 后，Agent 能稳健实现 200+ 个功能需求，每次会话增量推进。
学术界同步跟进。ICML 2025 论文在 GPT-4 级别模型上系统验证了 Harness 的效果：相同底层模型，有 Harness 与无 Harness 的胜率差异显著且稳定。
五、核心成果与关键洞见
量化成果汇总
| 组织 | 指标 | 效果 |
|---|---|---|
| OpenAI | 代码生成效率 | 约人工编写速度的 10 倍 |
| OpenAI | 人均日产出 | 3.5 PRs / 工程师 / 天，持续增长 |
| Stripe | 每周 AI 生成 PR | 1300+ 个（持续增加中） |
| Stripe | Bug 自主修复率 | Fix-It 活动中 30% 的 Bug 被自主解决 |
| LangChain | 基准分数提升 | +13.7 点（仅改变 Harness，不改变模型） |
| LangChain | 排行榜排名 | Top 30 → Top 5 |
| Anthropic | Agent 完成率 | 从频繁失败到每次会话可靠完成 |
四个核心洞见
洞见一：模型是商品，Harness 是护城河
LangChain 的实验给出了最有力的证明——同样的模型，不同的 Harness，结果天壤之别。在 AI 竞争中，关键优势不再仅在于"用哪个模型"，而在于"如何构建模型之外的体系"。
洞见二：约束反而赋予了更大自由
严格的架构约束反而让 Agent 更快速、更可靠地生成代码。约束消除了 Agent 探索错误方向的空间，让它专注于有效解。"约束越精准，Agent 越自由。"
洞见三：仓库必须是 Agent 的全部世界
任何没有编码进仓库的知识，对 Agent 都等于不存在。这催生了新的文档实践——不是为了人类的可读性，而是为了 Agent 的可理解性。知识工程开始成为工程师的核心技能。
洞见四：熵必须被主动管理，而非被动应对
不加干预的 AI 生成代码库会自然走向腐化。OpenAI 的经验表明，建立持续运行的熵管理 Agent 是唯一可扩展的解法——技术债需要像代码一样被持续治理。
六、对行业的深远影响
软件工程师角色的结构性迁移
Harness Engineering 带来的不是"AI 取代工程师"，而是工程师工作内容的结构性重新定义：
| 传统职责 | 新职责 |
|---|---|
| 编写代码 | 设计让 AI 编写代码的环境 |
| 调试代码 | 分析 Agent 行为模式，定位失败根因 |
| 代码审查 | 审查 Agent 输出 + 评估 Harness 有效性 |
| 编写测试 | 设计 Agent 能自主执行的测试策略 |
| 维护文档 | 构建机器可读的文档基础设施 |
| 修复 Bug | 将失败模式工程化为永久预防措施 |
这种转变要求更深层的系统架构思维——你在设计一个没有你持续介入就能自主运转的系统。
基于头部机构的实践经验，以下技能正在变得更加关键：系统思维、架构设计、规格说明写作、可观测性、知识工程、迭代速度。
行业架构的三个潜在重塑
技术栈的收敛："AI 友好性"将成为技术选型的新维度。API 稳定、文档完善、在训练数据中代表性强的技术，会因为"Harness 更容易构建"而获得优势。
"黄金路径"的演变：针对常见应用拓扑的 Harness 模板，将让团队能快速启动并在既定路径上推进，而非从头摸索。这是今天的服务模板在 AI 时代的进化形态。
遗留系统的加速替换：对已有代码库，逆向改造 Harness 代价高昂；对从零开始的项目，Harness 是早期必需品。这种不对称性可能加速企业做出"以 Agent 优先重新构建"的决策。
🔧 技术视角
Harness Engineering 正在重新定义 DevOps 工具链。CI/CD 不再只是执行测试和部署，而是 Agent 反馈循环的一部分。自定义 Linter、结构测试、熵管理 Agent 将成为工程基础设施的标配。对数据工程师而言，这意味着数据管道、特征工程、模型评估等场景同样需要构建专属的 Harness，而不是直接把 LLM 接进 Airflow。
🏢 落地视角
Stripe 的案例说明，真正可落地的 Harness 往往需要深度定制。通用 Agent 工具在 Stripe 这种规模的代码库上直接失效——定制化 Harness 才是护城河。对大多数企业而言，从 Level 1（AGENTS.md + pre-commit hooks）开始是最现实的路径，不必一步到位地建生产级 Harness。
七、实践入门：三阶段路线图
无论团队规模，都可以从以下三个阶梯中找到适合当前阶段的起点。
Level 1 — 基础 Harness（个人开发者，1-2 小时）
- 创建
CLAUDE.md或AGENTS.md，每一行对应一个真实观察到的 Agent 错误 - 配置 pre-commit hooks 进行 lint 和格式化检查
- 建立 Agent 能自主运行的测试套件
- 保持清晰一致的目录结构
这一阶段的投入回报极高，1-2 小时的设置能消除 80% 的常见 Agent 错误。
Level 2 — 团队 Harness（小型团队，1-2 天）
- 团队共享、持续维护的
AGENTS.md，写入架构约定和团队规范 - 通过 CI 强制执行架构约束，让违规无法合并
- 针对 AI 生成 PR 制定专用的代码审查清单
- 文档即代码（Docs as Code），通过 linter 验证文档的新鲜度
Level 3 — 生产 Harness（工程组织，1-2 周）
- 自定义中间件层（死循环检测、推理预算优化）
- 可观测性集成（Agent 能直接读取日志、指标、追踪数据）
- 定时运行的熵管理 Agent（保持代码库持续健康）
- Agent 性能监控仪表板和告警机制
常见陷阱
过度工程化控制流：模型能力快速进步，构建"可撤除"（rippable）的 Harness——每个组件都应该能被轻松移除。
将 Harness 视为静态配置：Harness 需要与模型能力同步演进，每次重大模型版本升级都应重新评估。
忽视文档层：精确的机器可读文档，往往比任何中间件改进都更能提升 Agent 输出质量。
知识存放在仓库之外：Slack 讨论、Google Doc 里的决策、口耳相传的规范——对 Agent 而言，这些完全不存在。
八、未来展望
Harness 模板化：针对常见应用拓扑的 Harness 模板将成为新的"黄金路径"基础设施，类似今天的 Docker 镜像和 Helm Chart。
多 Agent 协作架构：测试 Agent、QA Agent、代码清理 Agent 各司其职，Harness 负责任务调度、上下文传递和结果整合。
自适应与自进化 Harness：Agent 失败时，Harness 自动将失败模式转化为新规则。Harness 将从"人工维护的配置"演进为"自我学习的系统"。
Harness 作为核心竞争力：当底层模型越来越商品化，企业在 Harness 上的积累——领域知识文档、自定义验证工具、失败模式库——将形成难以快速复制的"Harness 飞轮"效应。
结语
"如果 2025 年是 AI Agent 证明自己能写代码的一年，那 2026 年则是我们认识到——Agent 不是难点，Harness 才是。"
Harness Engineering 的出现，标志着 AI 辅助软件开发从"惊叹于模型能力"转向"工程化地驾驭模型能力"。它不是一个工具，不是一个框架，而是一种工程学科——一套关于如何为 AI Agent 构建可靠运行环境的系统性思考方式。
未来的软件工程师，将是那些善于设计环境、让 AI 在其中可靠运作的人。
你的 Harness 今天是什么样的？
参考资料
- Ryan Lopopolo, OpenAI (2026.02.11). Harness engineering: leveraging Codex in an agent-first world. https://openai.com/index/harness-engineering/
- Mitchell Hashimoto (2026.02.05). My AI Adoption Journey. https://mitchellh.com/writing/my-ai-adoption-journey
- Birgitta Böckeler, ThoughtWorks / Martin Fowler Blog (2026.02.17). Harness Engineering. https://martinfowler.com/articles/exploring-gen-ai/harness-engineering.html
- Anthropic Engineering (2025.11.26). Effective harnesses for long-running agents. https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
- LangChain (2026.02.17). Improving Deep Agents with harness engineering. https://blog.langchain.com/improving-deep-agents-with-harness-engineering/
- Alistair Gray, Stripe (2026.02.09). Minions: Stripe's one-shot, end-to-end coding agents. https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents