5 个月 100 万行代码，0 行人工编写——解读AI驾驭工程Harness Engineering

🤖 5 个月 100 万行代码，0 行人工编写——AI驾驭工程Harness Engineering：软件工程的新范式

🎬 开篇：一个激进的实验

5 个月，100 万行代码，0 行人工编写

2025 年 8 月，OpenAI 团队启动了一个激进实验：

完全由 AI 智能体编写代码，构建并维护一个拥有百万行代码的软件产品。

人类工程师的角色从"编写者"转变为"设计者"和"指挥者"。

核心数据

核心洞察

"人类掌舵，智能体执行。"

这不是未来愿景，而是已经发生的现实。

📚 第一部分：什么是驾驭工程？

AI 工程化四层链条模型

驾驭工程不是孤立存在的，它处于 AI 工程化链条的顶层：

核心定义

驾驭工程不是把提示词写长一点，而是围绕高自治 AI 模型构建整套可持续执行环境。

它是对前三者的上卷和封装，处于操作系统层。

关键区别

🔍 第二部分：为什么"现在"重要？

行业瓶颈的根本性转移

过去的瓶颈：

• "让 AI 多做点"
• 模型能力不足
• 工具链不完善

现在的瓶颈：

• 人类 QA 成为瓶颈
• 人类注意力成为稀缺资源
• 系统设计目标：让人只在高杠杆节点出手

术语成熟：从边缘到一线

2026 年初里程碑：

• OpenAI 官方文档明确使用"Harness Engineering"
• Anthropic 发布 Harness Design 最佳实践
• 标志着该领域从边缘探索进入一线工程实践

🛠️ 第三部分：驾驭工程六大核心部件

部件 1：机器可验证的完成契约

核心原则：

"Done"不是漂亮的回答，而是可验证的完成。

契约必须包含：

• 输出格式
• 工具使用
• 停止条件
• 验收方法

OpenAI 实践：

• 每个 Sprint 前与评估者协商"Sprint 契约"
• 明确"完成"的定义
• 评估者根据契约标准评分

部件 2：Durable Knowledge 的 System of Record

核心原则：

知识必须离开聊天窗口，进入可发现、可维护、可验证的记录系统。

错误做法：

• ❌ 巨大的 AGENTS.md 文件（挤占情境窗口）
• ❌ 过时的规则文档
• ❌ 仅靠大 Prompt 承载知识

正确做法：

• ✅ 精简 AGENTS.md 为约 100 行的"内容目录"
• ✅ 指向代码仓库中结构化的 docs/ 目录
• ✅ 文档即代码（版本化存储）
• ✅ 运行"doc-gardening"智能体自动修复过时文档

部件 3：真正的感官和手脚

核心原则：

Agent 不能只读代码，必须能读 UI、看日志、跑测试。

Anthropic 实践：

• 接入 Chrome DevTools 协议
• 智能体可以驱动浏览器、截屏、处理 DOM 快照
• 使用 LogQL 和 PromQL 查询日志和指标
• 独立完成：重现漏洞→录制视频→修复→验证→提交 PR→合并

能力清单：

[ ] 读取 UI（截屏、DOM 快照）

[ ] 查看日志（LogQL 查询）

[ ] 运行测试（自动化测试套件）

[ ] 验证指标（PromQL 查询）

部件 4：长时程失忆的解决方案

核心问题：

• 不能只靠大上下文硬扛
• 模型 tend to lose coherence on lengthy tasks
• "上下文焦虑"：过早结束工作

解决方案：

• 进度文件（记录当前状态）
• 特性列表（已完成/待完成）
• Git 回滚点（状态可恢复）
• 上下文重置（clean slate）

Anthropic 实践：

• 使用结构化 artifacts 在会话间传递上下文
• 上下文重置 + 结构化 handoff
• 比 compaction 更有效（给 agent 干净的状态）

部件 5：外置验证回路

核心原则：

不能让主 Agent 既当运动员又当裁判。

错误做法：

• ❌ 让主 Agent 自证完成
• ❌ 依赖 Agent 的口头声明
• ❌ 无外部验证

正确做法：

• ✅ 引入外部 Evaluator
• ✅ 自动化测试
• ✅ 监控指标
• ✅ 证据来自外部世界（测试结果、指标变化）

Anthropic 三智能体架构：

Planner（规划者）→ Generator（生成者）→ Evaluator（评估者）

部件 6：边界、沙箱与熵控制

核心原则：

必须机械化地设定边界，防止系统失控。

关键措施：

• 沙箱隔离
• 最小权限原则
• 强制分层架构
• 自定义 linter 和结构测试

OpenAI 实践：

• 每个业务域划分为固定层（Types → Config → Repo → Service → Runtime → UI）
• 依赖方向严格限制
• 横切关注点通过 Providers 接口进入
• 通过自定义 linter 强制执行

⚠️ 第四部分：七种反模式与陷阱

反模式 1：把大长 Prompt 当 Harness

错误：认为长 Prompt=驾驭工程

真相：长 Prompt 只是入口，不是知识库本体

正确做法：

• 精简入口 Prompt
• 知识库进入版本化文档仓库
• 文档即代码

反模式 2：层级混淆

错误：

• 把 Workflow 误叫 Agent
• 把 Agent 误叫 Harness
• 导致预期和评测错位

正确做法：

• 明确四层链条定位
• 根据层级设定预期
• 使用正确评测指标

反模式 3：工具越多越好

错误：堆砌工具，认为工具多=能力强

真相：工具过多会提高选择噪声

正确做法：

• 追求精简和边界清晰
• 工具与任务匹配
• 定期清理无用工具

反模式 4：过早追求完全自治

错误：高风险场景直接上完全自治

正确做法：

• 采用"Agent 预处理 + 人类放行"模式
• 逐步提升自治级别
• 高风险场景保留人类裁决权

反模式 5：让主 Agent 自证完成

错误：依赖 Agent 的口头声明

正确做法：

• 证据必须来自外部世界
• 测试结果、指标变化
• 外置验证回路

反模式 6：无回滚点修改状态

错误：长时运行系统必有失误，但无恢复机制

正确做法：

• 预设 Git 回滚点
• 进度文件记录状态
• 状态可恢复、可交接、可继续

反模式 7：越复杂越先进

错误：过早优化和过度工程

真相：简单结构往往更稳健

正确做法：

• 从最小闭环开始
• 逐步迭代
• 避免过度工程

第五部分：中国落地路线

中国落地窗口

独特优势：

• 庞大数字经济底盘（2024 年核心产业增加值超14 万亿元）
• 网民超11 亿
• 政策："人工智能+"已从口号转向具体任务书

落地场景广阔：

• 软件研发（证据最强）
• 客服与运营（ROI 最清晰）
• 销售运营（半自动驾驶）
• 制造现场（指标硬、验证强）
• 财务与合规（强辅助）
• 企业知识运营（System of Record 练兵场）

六类优先试点场景

实施路线：五级成熟度

30/60/90 天推进法

前 30 天：单 Agent 最小闭环

[ ] 跑通任务切片

[ ] 建立基础契约

[ ] 验证可行性

31-60 天：加状态、回退、接管阈值

[ ] 实现 100 次稳定完成

[ ] 建立外置验证回路

[ ] 定义人工接管阈值

90 天后：扩展至多 Agent 协同

[ ] 关注系统级经营指标

[ ] 多 Agent 协同

[ ] 持续优化熵控制

核心指标

不再只看"写得像不像"，而是关注：

📝 结尾：人的角色转变

从"表达者"到"设计者"

过去：

• 工作重点：编写具体的 Prompt
• 角色：表达者（告诉 AI 做什么）

现在：

• 工作重点：定义系统行为、验收标准和治理规则
• 角色：设计者（设计执行环境）

组织能力要求

真正稀缺的不再是模型能力，而是：

• 产品定义能力
• 工程构建能力
• 治理合规能力
• 运营维护协同能力

核心判断

驾驭工程的核心在于将人类判断制度化。

🔗 参考资料

核心报告

• 清新研究团队《驾驭工程 研究报告》（2026 年 3 月）
• IMA 笔记：驾驭工程 Harness Engineering

官方文档

• OpenAI: Harness engineering: leveraging Codex in an agent-first world https://openai.com/index/harness-engineering/
• Anthropic: Harness design for long-running application development https://www.anthropic.com/engineering/harness-design-long-running-apps

相关链接

• OpenClaw 文档: https://docs.openclaw.ai

学习完成时间: 2026-04-07 21:12

报告撰写: 九章智库 · 半山听雨