Harness Engineering 驭缰工程 - AI 工程新范式
OpenAI 提出的 AI 工程新范式，工程师设计约束让 AI 智能体可靠执行，核心是 Harness 等于 Model 之外的代码与配置
什么是 Harness Engineering？
Harness Engineering（驭缰工程）是 OpenAI 在 2026 年 2 月提出的工程范式：工程师不再写代码，而是设计环境、明确意图、构建反馈回路，让 AI 智能体可靠地完成工作。
人类掌舵，智能体执行。
核心转变：工程师的产出从代码变成了约束系统——AGENTS.md、架构规则、自定义 linter、反馈回路。
一句话理解
传统工程：人类写代码 → 机器执行代码
Harness Engineering：人类设计约束 → 智能体写代码 → 机器执行代码六大核心概念
1. 仓库即记录系统
智能体在运行时无法访问的任何内容，对它来说都不存在。
| 位置 | 对人类 | 对智能体 |
|---|---|---|
| Google Docs | ✅ | ❌ |
| Slack 讨论 | ✅ | ❌ |
| 团队成员脑中 | ✅ | ❌ |
| 仓库内 Markdown | ✅ | ✅ |
| 代码 + 注释 | ✅ | ✅ |
| Lint 规则 | 间接 ✅ | ✅（强制） |
关键实践：
- AGENTS.md 是目录，不是百科 — 约 100 行，只指路
- 专职 linter + CI 验证 — 知识库是否更新？链接是否交叉引用？结构是否正确？
- doc-gardening 智能体 — 定期扫描过时文档，自动发起修复 PR
- 执行计划是一等工件 — 提交到仓库，版本控制，带进度日志
2. 机械化执行
通过强制执行不变量，而非对实施过程进行微观管理。
文档会腐烂。人会忘记。但 lint 规则和 CI 检查每次都会执行。
两类约束：
架构约束（结构测试）：
- 域内分层顺序：Types → Config → Repo → Service → Runtime → UI
- 依赖方向只能向前
- 横切关注点必须通过 Providers 进入
- 违反 = CI 阻塞合并
品味不变式（自定义 linter）：
- 结构化日志（禁止 console.log 裸输出）
- Schema/类型的命名约定
- 文件大小限制
- 平台特定的可靠性要求
关键设计：lint 错误信息 = 修复指令：
❌ 普通做法：
Error: File exceeds 500 lines.
✅ Harness 做法：
Error: File exceeds 500 lines.
Fix: Split into domain-specific modules following docs/ARCHITECTURE.md#splitting-guide.
Consider extracting types to <domain>/types/ and service logic to <domain>/service/.错误信息中注入智能体可执行的修复路径 → 自我纠正闭环。
哲学： 在中央层面强制执行边界，在本地层面允许自主权。
3. 熵管理 = 垃圾回收
智能体会复现仓库中已存在的模式——包括坏模式。
随着时间推移，不可避免地产生漂移：
- 重复的辅助函数散落各处
- 不一致的错误处理风格
- 基于猜测的数据结构（YOLO 式探测）
- 过时的文档与实际代码不符
失败方案：人工清理
团队每周五花 20% 时间清理”AI 残渣”。不出所料，不具备可扩展性。
成功方案：编码 + 自动化
“黄金规则” — 带主观意见的机械规则，编码进仓库：
- 共享实用程序包 > 手写辅助工具 — 不变式集中管理
- 不做 YOLO 探测 — 在边界验证数据，或使用类型化 SDK
- 偏好自有实现的关键子集 — 与自有遥测集成、100% 测试覆盖、行为完全可预测
垃圾回收流程：
定期后台 Codex 任务
→ 扫描偏差
→ 更新质量评分
→ 发起重构 PR
→ 大多数 1 分钟内审查 + 自动合并类比： 技术债 = 高息贷款
- ✅ 每天小额偿还（持续垃圾回收）
- ❌ 累积到痛苦时一次性清偿（重写/大重构）
4. 智能体可读性
优化目标从”人类可读”转向”智能体可推理”。
选择”无聊”技术 — API 稳定、训练集覆盖好：
- 可组合性好
- 上游行为不透明时，重新实现子集可能更便宜
原文示例： 没有引入通用的 p-limit 风格包，而是自研了带并发的 map 辅助函数：
- 与自有 OpenTelemetry 仪表紧密集成
- 100% 测试覆盖
- 行为完全符合运行时预期
让应用对智能体可操作：
- 应用可以根据 git worktree 启动 → 每次变更启动独立实例
- Chrome DevTools 协议接入智能体运行时 → DOM 快照、截图、导航
- 本地可观测性堆栈（LogQL 查日志、PromQL 查指标）→ 临时环境，任务完成即删除
上下文窗口管理（来自 LangChain）：
- Compaction — 智能压缩和卸载上下文
- 工具输出卸载 — 保留大输出的头尾，完整内容存文件系统
- 渐进式披露（Skills） — 按需加载，不在启动时预装所有工具
60 行规则（来自 HumanLayer）： AGENTS.md 控制在 60 行以内。超过这个长度，效果反而下降。
约束悖论（来自 Martin Fowler）：
限制解空间反而让 AI 更可靠。
这是一个反直觉的洞察：给智能体的自由度越大，它犯错的概率越高。通过架构约束收窄解空间，智能体在约束内的表现会显著提升。
5. 吞吐量改变合并理念
当 Codex 的吞吐量远超人类注意力时，传统的工程规范变得不再有效。
核心转变：纠错成本低，等待成本高。
具体变化：
PR 生命周期缩短：
- 1,500 个 PR / 5 个月 / 3 人 = 人均每天 3.5 个 PR
- PR 不再是需要精雕细琢的大作，而是快速流动的小变更
- 扩展到 7 人后吞吐量仍在增长（说明瓶颈不在人数）
合并门控最小化：
- 尽量减少阻塞合并的门
- 测试偶发失败 → 后续重跑解决，不无限期阻塞
- 在低吞吐量环境中这是不负责任的；在高吞吐量环境中这通常是正确的
智能体审查智能体：
- 人类可以审核 PR，但不是必须的
- 随着时间推移，几乎所有审核都调整为智能体对智能体
- Ralph Wiggum 循环：Codex 本地审核 → 请求额外智能体审查 → 对反馈做出响应 → 循环直到所有审核通过
关键洞察 — 本质是经济学问题：
传统模式：人力贵 + 吞吐量低 → 每个 PR 都要精心审查 → 阻塞门多
Harness 模式：智能体便宜 + 吞吐量高 → 快速迭代修复 → 阻塞门少前提条件：必须有足够的背压机制（测试、lint、结构检查）来保证基本质量，否则就不是”快速迭代”而是”快速腐烂”。
6. Harness 的精确定义
Agent = Model + Harness
Harness = 模型之外的一切代码、配置和执行逻辑。
裸模型不是智能体——它接受文本/图片/音频/视频，输出文本。当 harness 给它状态、工具执行、反馈回路和可执行约束时，它才成为智能体。
完整组件清单（来自 LangChain）：
| 组件 | 说明 |
|---|---|
| System Prompts | AGENTS.md、CLAUDE.md |
| Tools & MCP | 扩展智能体能力的工具和协议 |
| Skills | 渐进式加载的知识包 |
| 沙箱基础设施 | 文件系统、浏览器、隔离执行环境 |
| 编排逻辑 | 子智能体生成、handoff、模型路由 |
| Hooks/中间件 | compaction、续接、lint 检查 |
来自 HumanLayer（六个配置杠杆）：
| # | 杠杆 | 要点 |
|---|---|---|
| 1 | AGENTS.md | ≤60 行，禁止自动生成 |
| 2 | MCP Servers | 信任边界 + 工具数量控制 |
| 3 | Skills | 渐进式披露，按需加载 |
| 4 | Sub-Agents | 上下文防火墙，隔离防 context rot |
| 5 | Hooks | 生命周期脚本，成功静默/失败报错 |
| 6 | Back-Pressure | 测试/构建/类型检查 = 自我验证回路 |
来自 Martin Fowler（三层框架）：
┌─────────────────────────────────────────┐
│ Context Engineering │ 知识库 + 动态上下文
├─────────────────────────────────────────┤
│ Architectural Constraints │ LLM 审查 + linter + 结构测试
├─────────────────────────────────────────┤
│ Garbage Collection Agents │ 定期扫描 + 修复漂移
└─────────────────────────────────────────┘Harness 与模型训练的耦合（来自 LangChain）：
- 模型在 post-training 阶段与特定 harness 共同训练
- 模型可能 overfit 到特定 harness，换 harness 后表现暴跌
- Terminal Bench 2.0 数据：纯 harness 优化可以把排名从 Top 30 拉到 Top 5
- 推论：最适合你任务的 harness，不一定是模型 post-training 时用的那个
Guides × Sensors：组件如何协同（来自 Fowler）：
| 计算性（确定性，CPU） | 推理性（语义，LLM） | |
|---|---|---|
| 引导器/前馈 | bootstrap 脚本、OpenRewrite、LSP | AGENTS.md、Skills、architecture.md |
| 传感器/反馈 | linter、ArchUnit、类型检查、覆盖率 | AI code review、LLM-as-judge |
- 引导器：在智能体行动之前引导它，增加首次成功概率
- 传感器：在智能体行动之后观察，启用自我纠正
- 计算性：确定性、快速、便宜，每次提交都跑
- 推理性：概率性、慢、贵，选择性运行
关键洞察：单独使用任一维度都不行——只有反馈 = 反复犯同样错误；只有前馈 = 不知道规则是否生效。
三个规制维度（成熟度）：
| 维度 | 成熟度 | 说明 |
|---|---|---|
| 可维护性 Harness | 最成熟 | 内部代码质量，现有工具丰富 |
| 架构适应度 Harness | 中等 | 本质是 Fitness Functions |
| 行为 Harness | 最弱 | ”房间里的大象”——功能正确性验证仍无可靠答案 |
Harnessability（可驾驭性）：
不是所有代码库都同样适合被 harness：
- 强类型语言 天然自带类型检查传感器
- 清晰模块边界 支持架构约束规则
- 成熟框架（如 Spring）隐式提高智能体成功概率
- Ambient Affordances：环境本身的结构属性——可读性、可导航性、可处理性
Ashby 必要多样性定律：
调节器必须至少拥有与被调节系统同等的多样性。
LLM 能生成几乎任何东西（高多样性）→ 选定拓扑结构 = 削减多样性 → 全面 harness 变得可行。这为”约束越严，自主性越强”提供了控制论根基。
与 Harness.io（CI/CD 平台）的关系：
两者不是同一个东西，但共享同一个工程哲学：
AI Harness Engineering Harness.io (CI/CD)
约束 AI 智能体的行为 约束代码交付的过程
AGENTS.md + linter + 背压 Pipeline + Policy-as-Code + 门控
目标：可靠的代码生成 目标：可靠的代码部署
共同本质：用确定性约束驾驭不确定性系统
Backpressure over Prescription关键数据
| 指标 | 数据（来自 OpenAI 团队经验） |
|---|---|
| 团队规模 | 3 人 → 7 人 |
| 时间跨度 | 5 个月 |
| 代码量 | 约 100 万行 |
| PR 数量 | 约 1,500 个 |
| 人均日 PR | 3.5 个 |
| 单次运行时长 | 6+ 小时（通常在人类睡眠时间） |
| 效率估算 | 手工编写的约 1/10 时间 |
常见问题
Q: Harness Engineering 和 OpenClaw/Hermes Agent 是什么关系？
A: Harness Engineering 是理论框架；OpenClaw/Hermes Agent 是这个框架的实现。Hermes Agent 的 AGENTS.md、Skills、MCP、记忆系统都是 Harness 的组成部分。
Q: 需要先理解全部六个概念才能入门吗？
A: 不需要。从概念 1（仓库即记录系统）和概念 2（机械化执行）开始——这些是最实用的日常工具。概念 6（Harness 定义）提供理论基础。
Q: 这和传统 CI/CD 有什么区别？
A: CI/CD 约束代码交付过程；Harness Engineering 约束 AI 智能体在代码生成过程中的行为。它们共享”约束优于规范”的思想。
下一步
- OpenAI — Harness Engineering — 官方原文
- GitHub 仓库 — 学习笔记和源材料