00 — 什么是 Harness Engineering（驭化工程）
定义
Harness Engineering 是一门专注于为 AI 编程 Agent 设计可靠运行环境的工程学科。它不优化模型本身，而是系统性地设计围绕模型的约束、上下文、工具与反馈机制，使 Agent 在真实生产代码库中能持续、高质量地输出成果。
Mitchell Hashimoto 给出了一个极为精炼的操作定义：
"每当发现 Agent 犯了一个错误，花时间设计一个工程解决方案，使得 Agent 永远不再犯同样的错误。"
Martin Fowler 的描述则更系统：
"驭化工程描述了保持 AI Agent 在大规模生成和维护代码时处于受控状态的工具与实践。"
核心公式
AI 编程 Agent = AI 模型(s) + 驭化层（Harness）
Phil Schmid 提出了一个更形象的计算机类比：
| 类比层 | 传统计算机 | Agent 系统 |
|---|---|---|
| 处理单元 | CPU | AI 模型 |
| 工作内存 | RAM | 上下文窗口 |
| 操作系统 | OS | Agent Harness（驭化层） |
| 应用程序 | App | Agent 任务逻辑 |
驭化层不是可选的附加配置，它是 Agent 系统的操作系统。
三大支柱
OpenAI 的实践与 Martin Fowler 的分析共同归纳出驭化工程的三大核心支柱：
支柱一：上下文工程（Context Engineering）
为 Agent 持续构建和维护高质量的知识基础设施。包括：
- 嵌入代码库的动态知识库
- 系统化的文档结构（渐进式披露）
- 代码设计本身作为上下文的一部分
支柱二：架构约束（Architectural Constraints）
通过机械化手段强制执行代码规范，而非仅靠文档说明。包括：
- 自定义 linter 及其带有指导性的错误消息
- 结构测试验证依赖方向
- CI 流水线阻断架构违规
支柱三：熵管理（Entropy Management）
周期性检测和修复 Agent 生成代码造成的系统性衰退。包括：
- 垃圾回收式的文档一致性检查
- 架构违规的自动扫描与修复
- 技术债务的持续追踪
历史背景：为什么 2025-2026 年这个概念兴起？
之前发生了什么
2023-2024 年，工程师将 AI 用于"辅助编码"——Copilot 式的行级自动补全。这个阶段的问题是：模型犯了错，工程师手动修。模型是工具，人是主体。
范式转变
2025 年下半年开始，多个团队开始大规模实验自治 Agent——不是补全，而是完整完成任务直到 PR 合并。
转折点数据：
- OpenAI 实验（2025 年 9 月至 2026 年 2 月）：3 名工程师，5 个月，100 万行生产代码，1500 个合并 PR，全部由 Codex Agent 撰写，无一行手写代码。工程师平均每人每天完成 3.5 个 PR。
- Stripe Minions（2026 年初）：每周自动合并 1300+ PR，工程师从写代码转变为审查代码、改进规范模板。
- LangChain Terminal Bench 2.0（2026 年 2 月）：不换模型，仅优化驭化架构，基准从 52.8% 提升至 66.5%，排名从 Top 30 外跃升至 Top 5。
核心洞察浮现
当规模扩大后，工程师们发现：
Agent 的可靠性瓶颈不是模型，是环境。
同一个 Claude Opus 4.5 模型：
- 在通用 CORE-Agent 脚手架下：成功率 42%
- 在 Claude Code 驭化层下：成功率 78%
相差 36 个百分点，模型完全相同，只有驭化层不同。
驭化工程的核心操作原则
原则一：把 Agent 失败视为系统设计问题
当 Agent 出错时，不要手动修复——要追问：
- 它缺少什么工具？
- 它缺少什么文档？
- 什么约束应该被机械化执行？
- 反馈循环在哪里断裂？
原则二：环境设计优于提示词调整
提示词是易失性的；环境是持久的。每一个驭化工程改进都应沉淀为可复用的基础设施，而非下次再写的临时提示。
原则三：渐进式披露，而非全量注入
上下文窗口是 RAM，不是硬盘。与其把所有规则塞进系统提示，不如建立按需加载的知识层级：
AGENTS.md（≤100 行索引）
└── design-docs/（架构决策）
└── product-specs/（功能规范）
└── references/（设计系统、API 文档）
原则四：人类品味一次性编码，持续机械化执行
人工审查发现了一个模式问题？将其转化为 lint 规则。这样人类的工程判断就变成了可以永久执行的系统约束。
原则五：验证循环替代人工 QA
为 Agent 提供机械化的自我验证能力：
- 类型检查
- 构建验证
- 单元测试与集成测试
- E2E 浏览器测试
成功时静默，失败时详细报告——这是驭化层中最高杠杆的投资之一。
工程师角色的转变
| 维度 | 传统角色 | 驭化工程时代角色 |
|---|---|---|
| 主要工作 | 亲手写代码 | 设计让 Agent 能写好代码的环境 |
| 失败响应 | 手动修复 bug | 改进驭化层基础设施 |
| 代码审查 | 关注实现细节 | 关注架构边界与规范符合性 |
| 文档 | 给人类开发者看 | 同时为 Agent 提供上下文 |
| 规范 | 写在 README 里 | 机械化执行（lint + 测试） |
Martin Fowler 将这个转变总结为：
"工程学纪律从代码本身（抽象、测试、风格）转移到了基础设施——工具、文档结构、反馈循环，维护系统一致性的架构约束。"
重要警告
驭化工程不等于：
- 写更多 prompt
- 装更多 MCP 服务器
- 创建更详细的 AGENTS.md
- 在 Agent 第一次失败时就添加大量规则
HumanLayer 的研究发现：
- 过多工具会让 Agent 进入"愚蠢区"（dumb zone）
- ETH Zurich 研究：人工撰写的 AGENTS.md 只带来 4% 提升，LLM 自动生成版本反而降低 20%+
- 过长上下文不是解决方案：更多 token 不等于更好的性能
正确的做法：先观察真实失败，再精准修复，不要预防性地堆砌配置。
下一步
- 深入了解三大支柱：→
01-context-engineering.md - 查看可读性评分标准：→
04-agent-readability.md - 立即开始实施：→
../practice/4-week-roadmap.md