1. 一句话定义
Harness Engineering（驾驭工程）：当 AI 智能体取代人类成为代码的主要生产者时，工程师的核心工作从"写代码"转向"设计环境、明确意图、构建反馈回路"，让智能体可靠地执行。人类掌舵，智能体执行。
2. 核心发现
OpenAI 用 3 名工程师 + Codex，5 个月内交付了一个约 100 万行代码的产品（有真实内外部用户），合并了约 1,500 个 PR，效率约为手工编码的 10 倍。全程 零行人工代码。
3. 六条关键原则
| # | 原则 | 含义 |
|---|---|---|
| 1 | 代码仓库是唯一的记录系统 | 智能体看不到的东西等于不存在。Slack 讨论、Google Docs 中的决策必须编码进仓库，否则智能体无法发现。给智能体的是地图（AGENTS.md），而非百科全书。 |
| 2 | 为智能体可读性优化 | 代码和文档的首要读者是 AI，不是人。选择"无聊但稳定"的技术栈（API 稳定、训练集中常见），某些场景下自己重写比绕过不透明的第三方库更划算。 |
| 3 | 强制不变量，不微管实现 | 架构边界通过自定义 linter + 结构测试机械执行（如分层依赖方向、边界解析数据形状），但实现细节留给智能体自由发挥。约束让速度不降、架构不漂移。 |
| 4 | 吞吐量改变合并理念 | 高吞吐下，纠错成本低、等待成本高。PR 生命周期短，偶发测试失败不阻塞合并，智能体可自行压缩合并自己的 PR。 |
| 5 | 品味编码为规则 | 人类的审查反馈、重构偏好不留在脑子里，而是转化为 linter 规则或文档更新。当文档不够时，把规则写成代码。 |
| 6 | 持续垃圾回收 | 智能体会复现仓库中的坏模式，导致漂移。解决方案：定期运行后台 Codex 任务扫描偏差、发起重构 PR（类似 GC），每天还债而非累积后一次性偿还。 |
4. 工程师角色转变
| 传统 | Harness Engineering |
|---|---|
| 编写代码 | 设计环境与约束 |
| Code Review | 构建自动化审查回路（智能体审智能体） |
| 手动 QA | 赋予智能体可观测性（日志/指标/追踪）+ Chrome DevTools 协议驱动 UI 验证 |
| 解决技术债 | 将还债编码为自动化流程 |
| 文档维护 | CI 强制文档新鲜度，doc-gardening 智能体自动修复过期文档 |
5. 智能体端到端自主能力
给定一个提示，Codex 可以完成以下全流程：
复现 Bug使用 Chrome DevTools 协议驱动应用，捕获故障状态
录制故障视频记录问题发生的完整过程
实施修复在代码库中定位并修改代码
验证修复重启应用，通过 UI 自动化确认问题已解决
录制修复视频记录解决方案的完整演示
开 PR 并回应审阅处理智能体和人类的反馈，修复构建故障
合并仅在需要人类判断时才交由人工处理
6. 核心洞察
构建软件仍然需要纪律，但纪律更多地体现在支撑结构上，而不是代码上。工具、抽象和反馈回路变得比代码本身更重要。
Harness Engineering 的本质：不是让 AI 替你写代码，而是构建一套"驾驭系统"——让智能体在结构化、可验证、有反馈的环境中自主运行，人类只在关键判断点介入。
7. 关键实践细节
7.1 渐进式情境披露
AGENTS.md 保持约 100 行，作为内容目录指向 docs/ 目录中的深层信息。设计文档已编目索引，执行计划作为一等工件被版本控制。智能体从小而稳定的切入点开始，被引导去查看下一步需要的信息，而不是一开始就被淹没。
7.2 架构分层模型
每个业务域划分为固定的层，依赖方向严格验证：
Types → Config → Repo → Service → Runtime → UI
↕
Providers（横切关注点：认证、连接器、遥测、功能标志）
自定义 linter 和结构测试强制执行这些规则，错误信息中直接注入修复指令。
7.3 熵与垃圾回收
智能体会复现仓库中已有的模式——包括不理想的模式。解决方案是将"黄金原则"编码到仓库中，并建立循环清理流程：
- 优先共享工具包而非手写辅助函数，集中管理不变量
- 不使用"YOLO 式"探测数据，验证边界或依赖类型化 SDK
- 定期运行后台 Codex 任务扫描偏差并发起重构 PR
- 大多数重构 PR 可在一分钟内审查并自动合并
技术债务就像高息贷款：持续小额偿还远好于累积后一次性解决。