Harness Engineering 介绍
一、什么是 Harness Engineering？
1.1 核心定义
Harness Engineering 是围绕 AI 智能体设计与构建的约束系统、反馈回路、工作流控制和持续改进循环的一套系统工程实践。它不优化模型本身，而是优化 Agent 的运行环境。
"每当发现 Agent 犯错，就花时间设计一个解决方案，确保 Agent 永远不会再犯同样的错误" —— Mitchell Hashimoto
1.2 概念演进：从 Prompt 到 Harness
工程范式演进图
三者的嵌套关系：
1.3 术语的诞生
| 时间节点 | 事件 | 意义 |
|---|---|---|
| 2026年2月 | Mitchell Hashimoto 博客首次命名 | 提出"防止重复犯错"核心理念 |
| 数天后 | OpenAI 发布百万行代码实验报告 | 标志性实践案例 |
| 同期 | Ethan Mollick 重组 AI 指南框架 | 推动术语规范化 |
| 随后 | Martin Fowler 发表深度分析 | 提出三大分类框架 |
二、为什么需要 Harness Engineering？
2.1 核心洞察：瓶颈在基础设施，不在模型智能
实验数据：Harness 的威力
2.2 Agent 的四大典型失败模式
Agent 失败模式全景图
2.3 上下文窗口的"甜蜜区间"
上下文窗口利用率与输出质量关系
三、Harness Engineering 的四大支柱
四大支柱架构图
3.1 支柱一：上下文架构
核心原则：Agent 应当恰好获得当前任务所需的上下文——不多不少。
三层上下文体系
反面案例：巨大的 AGENTS.md
3.2 支柱二：Agent 专业化
核心原则：专注于特定领域、拥有受限工具的 Agent 优于拥有全部权限的通用 Agent。
Agent 角色分工表
3.3 支柱三：持久化记忆
核心原则：进度持久化在文件系统上，而非上下文窗口中。
跨会话持久化记忆架构
编码 Agent 的典型会话启动流程：
3.4 支柱四：结构化执行
核心原则：将思考与执行分离。
结构化执行流程
四、业界标杆案例
4.1 OpenAI：百万行代码的零手写实验
OpenAI 实验概况
五大 Harness 原则：
架构约束强制执行：
4.2 Anthropic：16 个 Agent 构建 C 编译器
Carlini C 编译器项目数据
关键 Harness 设计：
4.3 Stripe：千级 PR 的 Minions 系统
Stripe Minions 架构
五、核心组件详解
5.1 AGENTS.md —— Agent 的活文档
AGENTS.md 定位与特性
5.2 架构约束与自动化执行
自定义 Linter 的巧妙设计
5.3 可观测性集成
可观测性集成架构
5.4 熵管理与"垃圾回收"
熵管理机制
六、工程师角色的转变
6.1 从写代码到设计环境
工程师角色转变
6.2 规划是新的编码
规划优先原则
6.3 并行编排的两种风格
并行工作模式对比
七、业界共识与分歧
7.1 六大共识
业界六大共识
7.2 四大分歧
业界四大分歧
7.3 三大空白区
三大空白区（最值得探索的方向）
八、最佳实践总结
8.1 立即可行的行动清单
立即可行的行动清单
8.2 Harness 成熟度评估模型
Harness 成熟度评估模型
8.3 关键组件检查清单
关键 Harness 组件检查清单
九、总结
核心结论
参考资料
- OpenAI — Harness engineering: leveraging Codex in an agent-first world
- Anthropic — Effective harnesses for long-running agents
- Nicholas Carlini — Building a C Compiler with Claude
- Martin Fowler — Harness Engineering
- Mitchell Hashimoto — My AI Adoption Journey
- Charlie Guo — The Emerging "Harness Engineering" Playbook
