[访谈笔记]OpenAI Harness 工程实践
2026/4/23 12:41:16 网站建设 项目流程

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 秒时:

  1. 将其作为一个**信号(Signal)** 而非错误
  2. 停止当前工作
  3. 双击进入构建图,分解(Decompose)
  4. 优化到 60 秒以内
  5. 恢复代理工作

棘轮机制(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 沟通
  • 环境配置

代理应该能看到自己的调用轨迹。

三层架构

层级职责特点
ModelCodex 编码模型推理、决策、主控
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 分发:高保真规范文件

工作机制

代理根据高保真规范在本地重新组装系统,无需传输完整代码。

优势

  1. 极低的共享成本:只传输规范,而非完整代码
  2. 环境适配:软件可以根据部署环境自动适配和重构
  3. 进化能力:像生物进化一样,根据上下文自我调整

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.”

自底向上的工具构建

当代理无法完成任务时:

  1. 不要降低标准或手动介入
  2. 构建更小的可组合单元
  3. 这些单元可以被复用和重组

知识编码的持久价值

每次遇到问题,不只是修复,而是:

  • 编码到文档中
  • 添加到代理的技能库里
  • 让知识在未来可被复用

关于"过度规范化"的风险

过度遵循规范结构可能导致问题。需要注意:

  • 例外情况的存在
  • 需要回滚的部分
  • 技能的滥用(过度使用技能)

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 倍。关键不是让人类做更多,而是让自动化系统接管所有可接管的工作,将人类注意力留给真正需要判断力的决策。

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询