我们正处于一个奇怪的拐点。模型越来越强，智能体越来越自主，但很多团队用了 AI 工具却发现——结果一团糟，返工率居高不下，根本不敢放手让智能体跑。问题不是模型不够强，而是我们还不会「驾驭」它。
一、三次浪潮：我们走到哪里了？ #
回顾过去几年 AI 工程实践的演进，可以清晰地看到三个阶段：
-
第一浪：提示工程
2022–2024
Prompt Engineering
这是大多数人的起点。核心是「怎么问」——少样本提示、思维链、角色设定。目标是写出一条完美的指令，换来一个满意的输出。 **比喻**：给一个人写了一封措辞精准的信，期待他完美执行。 **局限**：一次性、不可维护，模型输出的不确定性无法系统性应对。 -
第二浪：上下文工程
2025
Context Engineering
认识到单个提示远远不够。模型的表现高度依赖它「看到了什么」——RAG 检索、对话历史、工具定义、结构化记忆。这一阶段的核心是动态构建最优上下文窗口。 **比喻**：不只是写信，还要附上所有正确的附件、背景材料、参考文件。 **局限**：仍然是单次会话级别的优化，无法处理持续运行的智能体在复杂环境中的失控问题。 -
第三浪：驾驭工程
2026–
Harness Engineering · 当前前沿
当智能体开始真正自主运行——写代码、提 PR、调 API——单靠提示词和上下文已经不够了。我们需要的是围绕智能体的完整控制基础设施。 **比喻**：Harness 一词来自马具——缰绳、马鞍、嚼子。模型是马，工程师是骑手，Harness 是驾驭这匹强大动物的全套装备。
核心定义：Harness Engineering 是设计系统、约束机制和反馈回路的工程学科，目的是让 AI 智能体在生产环境中可靠、持续地运行。
二、为什么现在？一个震惊社区的真实案例 #
OpenAI 内部实验（2026年2月公开）：三名工程师，五个月，一百万行代码，全程人类零直接代码贡献。
2026年2月，OpenAI 公开了一个颠覆社区认知的内部实验：
| 维度 | 数据 |
|---|---|
| 📅 起点 | 2025年8月，一个空仓库 |
| 👥 团队规模 | 三名工程师 |
| 🤖 工具 | Codex CLI（GPT-5） |
| 📦 产出 | ~1,000,000 行代码 |
| 🔀 PR 数量 | ~1,500 个，全部合并 |
| ⚡ 效率 | 平均每人每天合并 3.5 个 PR |
| 🚫 人类代码 | 零行 |
这个团队的首席工程师 Ryan Lopopolo 用一句话总结了整个项目：
“Agents aren’t hard; the Harness is hard.”
与此同时，LangChain 也公布了一组实验数据：
不改动任何模型权重，只优化 Harness 系统，编码智能体在 Terminal Bench 2.0 上的得分从 52.8% → 66.5%，跻身全球前五。
结论只有一个：瓶颈不在模型，在环境。
三、Harness Engineering 的五大支柱 #
mindmap
root((Harness Engineering))
工具编排
文件系统权限
Shell 白名单
API 调用策略
护栏系统
静态 Linter
架构约束
测试套件
上下文管理
AGENTS.md
仓库即真相
代码可读性
熵对抗
CI 一致性扫描
死代码检测
依赖验证
可观测性
行为日志
PR 成功率
干预次数 KPI
🔧 支柱一：工具编排（Tool Orchestration） #
定义智能体能调用什么工具、怎么调用、权限边界在哪里。
关键原则：不是给智能体最大权限，而是给它刚好够用的最小权限。
- 文件系统访问范围
- Shell 命令白名单
- 外部 API 调用策略
- 数据库操作权限
🛡️ 支柱二：护栏（Guardrails） #
在智能体执行路径上插入确定性检查，防止它走偏。
- 静态分析：Linter、类型检查，在代码进入 CI 前拦截
- 架构约束：用
dependency-cruiser等工具强制依赖方向 - 测试套件：智能体的每次提交都必须跑通测试，失败即回滚
核心洞察：规则应该由工具强制，而不是写在提示词里「希望」模型遵守。不要请求，要约束。
📚 支柱三：上下文管理（Context Management） #
确保智能体在每个会话中获得正确、一致的信息。
# AGENTS.md 示例结构
## 架构约束
- 禁止在 /api 目录下直接访问数据库，必须通过 /services 层
- 新增模块必须在 /docs/modules/ 下创建对应文档
## 历史失败记录（每行=一次真实失败）
- 不得在 React 组件中直接调用 fetch，使用 useQuery hook
- 测试文件命名必须以 .test.ts 结尾，不接受 .spec.ts代码必须对智能体可读，不只是对人类可读——需要清晰的结构、一致的命名、详尽的注释。
♻️ 支柱四：熵对抗（Entropy Management） #
持续运行的智能体会积累「熵」——过期文档、死代码、不一致的命名。Harness 需要内建反熵机制。
- 定期扫描不一致性的 CI 任务
- 自动检测过期文档的工具
- 代码依赖关系的持续验证
👁️ 支柱五：可观测性与反馈回路（Observability） #
核心 KPI：人工干预次数 / 总 PR 数 → 越低说明 Harness 越健康
一条启发性原则：如果一个 PR 需要大量人工干预，问题不在智能体，问题在 Harness。
四、核心反直觉：约束 = 能力 #
这是 Harness Engineering 最重要、也最反直觉的洞察：
给智能体设置约束，反而会提升它的能力和自主性。
逻辑链路：
没有约束 → 需要持续人工监督 → 智能体无法真正自主
↓
有了 Harness → 错误被系统捕获 → 人类可以放心授权 → 智能体真正自主Stripe 案例佐证：为智能体建立独立沙箱环境，接入 400+ 内部工具，与生产完全隔离。结论：给智能体和人类工程师相同的工具和上下文，而不是事后拼凑的集成。
五、Mitchell Hashimoto 的实战方法论 #
每当智能体犯了一个错误，就花时间设计一个解决方案，让这个错误永远不再发生。
— Mitchell Hashimoto，HashiCorp 联合创始人，2026年2月
三层干预手段 #
-
第一层：隐式提示
最轻量
更新 `AGENTS.md`，每一行对应一次历史失败。 成本最低，适合频率低的边缘 case。 -
第二层：显式架构说明
中等强度
更新架构文档，将约定变成文档化的规范。 适合影响范围较广的结构性问题。 -
第三层：程序化工具
最强力
写脚本强制执行——截图验证脚本、过滤测试脚本、Linter 规则。 让违规从「不应该发生」变成「不可能发生」。
六、对我们团队的启示与行动清单 #
工程师角色的演变 #
| 过去 | 现在 | |
|---|---|---|
| 核心工作 | 写代码 | 设计让 AI 写好代码的系统 |
| 身份认同 | 提示词作者 | 系统架构师 |
| 应对错误 | 修复 Bug | 设计让 Bug 不可能出现的约束 |
| 评价标准 | 代码产出量 | Harness 健康度 |
行动清单 #
🔴 短期（本季度可落地）
- 建立
AGENTS.md文件，每次智能体犯错就加一行约束 - 在 CI 中引入依赖方向 Linter
- 梳理 AI 工具的权限清单，能收窄就收窄
🟡 中期（下半年规划）
- 建立 AI 专用沙箱开发环境
- 统计 AI PR 人工干预率，作为持续追踪的 KPI
- 推进关键模块的「AI 可读性」专项 Review
🟢 长期（战略方向）
- 将 Harness Engineering 作为团队核心能力进行系统建设
- 考虑设立「智能体基础设施」专项角色
结语 #
AI 编程工具的竞争，表面上是模型的竞争。但真正拉开差距的，是谁先建立起一套可靠的 Harness 系统。这不是「AI 替代工程师」的故事，而是「工程师驾驭 AI」的故事。而 Harness Engineering，就是这门驾驭技术的名字。
延伸阅读 #
- Mitchell Hashimoto 博客（2026.02）：Harness Engineering 概念原文
- OpenAI Engineering Blog（2026.02）：One Million Lines of Code, Three Engineers, No Human Commits
- LangChain Blog：How We Improved Agent Performance Without Touching the Model
- Stripe Engineering（2026.03）：Designing Developer Environments for Autonomous Agents
