Harness Engineering
Harness(套具/脚手架)工程是一种以 AI 代理为中心的软件开发方法论。
核心:人类是唯一真正稀缺的资源,通过构建极高密度的自动化脚手架,让 AI 代理接管从编码、测试到运维的全生命周期。
原则:
- 不再是为人写代码,而是
为代理写代码 - 将 Codex(编码模型)直接作为测试框架和入口点
- 持续自省:哪里在出错?哪里在浪费时间?如何自动化?
1. 设定零人工代码的极端约束
实验背景
Ryan 在 OpenAI Frontier 产品探索团队工作,团队职责是探索将模型打包成企业级解决方案的新方式。团队成员背景涵盖 Snowflake、Stripe、Citadel 等公司。
极端约束的实施
Ryan 给自己设定了一个"外星"级别的约束:整个项目中不写一行代码。所有工作都必须通过提示词驱动 AI 代理完成。
约束条件: - 禁止手动编写代码 - 所有功能需求必须转化为 Prompt 交付给代理 - 代理无法完成时,首先构建更小的构建块(Building Blocks)演进
关键在于 形成可复用的工具链
| 阶段 | 模型版本 | 能力状态 | 团队体验 |
|---|---|---|---|
| 初期 | Codex mini | 较弱 | 极度痛苦,比手动开发慢 10 倍 |
| 中期 | Cx51-Cx54 | 逐步提升 | 工具链逐渐成形 |
| 最终 | 成熟版本 | 强大 | 代理能完成端到端任务 |
关键:当模型"做不到"时
当代理无法完成某个任务时,不要手动介入,而是双击进入问题,构建更小的构建块。这些构建块可以被重新组合成更大的目标。
“Whenever the model just cannot, you always pop open that hood, double click into it and build smaller building blocks that then you can reassemble into the broader objective.”
成果
- 5 个月完成项目开发
- 零行人工代码
- 百万行+代码库总规模
- ~1500 个 PR(Pull Request)
- 生产力比手动开发快10 倍
2. 构建一分钟内的极速反馈循环
为什么是"一分钟"?
代理的行为模式与传统编程不同。当模型支持后台 shell(background shells)时,它变得不那么有耐心,不愿意阻塞等待。为了保持效率,必须让构建过程足够快。
# 构建时间的演进路径Makefile(自定义) → Bazel → Turso → NX 目标:任何构建必须在60秒内完成约束机制
当构建超过 60 秒时:
- 将其作为一个**
信号(Signal)** 而非错误 - 停止当前工作
- 双击进入构建图,分解(Decompose)
- 优化到 60 秒以内
- 恢复代理工作
棘轮机制(Ratchet)
这种约束类似于强制纪律——就像棘轮只能朝一个方向转动,一旦变慢就立即压缩。你不是在优化,而是在强制执行纪律。
对比:传统方式的问题
| 传统做法 | Harness 方式 |
|---|---|
| 构建时间逐渐膨胀到不可接受 | 保持 60 秒硬性上限 |
| 平台团队花 2-3 周优化回可接受范围 | 每时每刻都在园艺式维护 |
| 代码库分散度高 | 保持高一致性,减少 SDLC 分散 |
实际应用
Ryan 提到当前工作中有个 12 分钟的构建,他正在持续优化。团队的目标是让 Token 成本极低且极度并行,可以不断维护这些不变性。
3. 跨越人工代码评审的瓶颈
问题:人类成为瓶颈
在百万行代码规模下,同步的人类注意力是唯一真正稀缺的东西。人类需要吃饭、睡觉,而模型的产出速度远超人类评审能力。
解决方案:从同步评审到异步评审
传统流程:Code → PR → 人工评审 → 合并 Harness 流程:Code → PR → 异步评审/合并后评审 → 最终确认"合并后评审"模式
- 不再阻塞合并:评审改为异步进行
- 优先级框架:设定问题严重程度分级
- P0/P1:必须阻塞合并
- P2 及以下:不阻塞合并,纳入后续迭代
双代理博弈机制
实现了一个作者代理与评审代理相互博弈的系统:
作者代理 → 生成代码/PR ↓ 评审代理 → 检查质量、发现问题 ↓ 评分系统 → 决定是否可以合并观察:模型的本质
“Fundamentally the model is trivially parallelizable. As many GPUs and tokens as I am willing to spend, I can have capacity to work with the code base. The only fundamentally scarce thing is the synchronous human attention.”
4. 软件工程的 Model-View-Claw 范式
核心思想:代理不应被关在盒子里
真正的 AI 组织应赋予代理完全的领域掌控权:
- 访问监控指标
- 查看日志
- Slack 沟通
- 环境配置
代理应该能看到自己的调用轨迹。
三层架构
| 层级 | 职责 | 特点 |
|---|---|---|
| Model | Codex 编码模型 | 推理、决策、主控 |
| View | 可观测性层 | 日志、指标、追踪 |
| Claw | 执行工具层 | CLI 工具、脚本、技能 |
入口点的反转
传统模式:
环境设置 → 启动代理 → 代理在环境中工作Harness 模式:
启动 Codex(作为入口点)→ 通过 Skills 和 Scripts 提供能力 → 代理自主决定如何启动堆栈关键能力:代理自主决策
代理拥有大量 CLI 工具和脚本技能,可以自主决定:
- 何时启动堆栈
- 如何配置环境
- 使用什么工具组合
推理模型 vs 旧范式
| 旧代理模式(4o 时代) | 当前 Harness 模式(推理模型) |
|---|---|
| 必须定义脚手架 | 不需要脚手架,让模型自主决策 |
| 预定义状态转换 | 模型自己决定下一步 |
| 封闭盒子 | 开放领域控制 |
5. 技能系统(Skills Framework)
Skills 起源
Skills 是在项目中期才引入的概念,当时还没有现有的成熟工具。通过构建大量技能,代理获得了强大的任务执行能力。
技能定义示例
Tech Jet Tracker(技术缺陷追踪器)
一个 Markdown 表格结构,作为 Codex 执行代码评审的 hook 功能: 1. 让代理扫描所有业务逻辑 2. 对比文档化的 guardrails 3. 提出后续工作建议Quality Score(质量评分)
另一个 hook,用于: 1. 评估代码质量 2. 标记潜在问题 3. 引导后续改进技能触发机制
代理自己决定何时使用工具,不会在每个调用时都运行技能。它会根据上下文判断何时需要检查质量分数。
知识持久化
当遇到问题(如缺少 timeout)时:
修复代码 + 告诉 Codex:"请更新可靠性文档,要求所有网络调用必须有 timeout"这样不仅修复了当前问题,还持久化了过程知识:
- 修复了这一刻的问题
- 编码了"什么是好代码"的规范
- 作为上下文传给未来的编码代理
6. 观察系统(Observability)
构建历程
从只有 app 开始,逐步构建完整的可观测性栈:
阶段 1:仅有 app 阶段 2:添加向量、指标、API 监控 阶段 3:完整的开发栈技术选型
团队有意选择非常高层的快速开发工具:
- Me(工具名):使拉取 Victoria stack 二进制文件变得极其简单
- Tiny Python glue:用于启动整个栈
- 本地开发环境开箱即用
追踪系统(Traces)
观察系统允许团队和代理查看完整的调用轨迹,这对于理解代理行为和调试至关重要。
7. Ghost Libraries(幽灵库)— Symphony 系统
概念:软件分发的新形态
通过 Symphony 系统,软件不再以二进制或源码分发,而是以**“规范(Spec)”**分发。
传统分发:二进制文件 / 源码包 Symphony 分发:高保真规范文件工作机制
代理根据高保真规范在本地重新组装系统,无需传输完整代码。
优势
- 极低的共享成本:只传输规范,而非完整代码
- 环境适配:软件可以根据部署环境自动适配和重构
- 进化能力:像生物进化一样,根据上下文自我调整
8. 实践中的关键教训
约束的力量
极端约束(不写代码)迫使团队从"写代码"思维转向"构建系统和工具"思维。这种转变最终带来了 10 倍的生产力提升。
系统思维的重要性
“You kind of have to step back right, like you need to take a systems thinking mindset to things and constantly be asking, where is the agent making mistakes, where am I spending my time, how can I not spend that time going forward.”
自底向上的工具构建
当代理无法完成任务时:
- 不要降低标准或手动介入
- 构建更小的可组合单元
- 这些单元可以被复用和重组
知识编码的持久价值
每次遇到问题,不只是修复,而是:
- 编码到文档中
- 添加到代理的技能库里
- 让知识在未来可被复用
关于"过度规范化"的风险
过度遵循规范结构可能导致问题。需要注意:
- 例外情况的存在
- 需要回滚的部分
- 技能的滥用(过度使用技能)
9. 工具链全景
构建系统演进
Makefile → Bazel → Turso → NX ↑ ↑ 遇到问题 达到目标 需要并发 构建 < 60s关键技术栈
| 类型 | 工具/技术 |
|---|---|
| 编码模型 | Codex 系列 |
| 构建工具 | NX(Bazel/Turso 演进终点) |
| 开发栈 | Victoria stack(通过 Me 拉取) |
| 胶水语言 | Python |
| 规范格式 | Markdown / 自定义 Spec |
技能类型
- Tech Jet Tracker:缺陷追踪
- Quality Score:代码质量评估
- Reliability Documentation:可靠性规范生成
10. 未来展望
模型进化带来的范式转变
随着模型能力的提升:
- 不再需要硬编码的脚手架
- 模型可以自主推理下一步
- Agentic M(代理模式)与短上下文模型结合
与其他 AI Builder 的融合
这种 Harness 工程实践正在成为 AI 构建者的核心能力。Ryan 的文章已成为这个新兴学科的定义性文献。
关键术语表
| 英文术语 | 中文解释 |
|---|---|
| Harness | 套具/脚手架,指用于控制 AI 代理的工具和框架 |
| Model-View-Claw | 一种将 Codex 作为入口点的软件架构模式 |
| Ghost Libraries | 幽灵库,通过规范而非代码分发的软件形态 |
| Background Shells | 后台 Shell,模型可在后台执行命令而不阻塞 |
| Skills | 技能,预定义的工具和脚本库 |
| Ratchet | 棘轮机制,强制保持系统不变性 |
| Post-merge Review | 合并后评审,异步化的代码审查方式 |
总结
Harness 工程的核心洞见是:人类是唯一真正稀缺的资源。通过设定极端约束(零人工代码)、强制反馈循环(一分钟构建)、异步评审流程,团队在 5 个月内完成了百万行代码的项目,生产力提升 10 倍。关键不是让人类做更多,而是让自动化系统接管所有可接管的工作,将人类注意力留给真正需要判断力的决策。