Agent Harness：AI 驱动的代码生成实践

一行代码都没写，五个月交付百万行产品——OpenAI 的 Agent Harness 实验启示

前言

在软件开发的历史长河中，"人类写代码"一直是不可撼动的铁律。然而，OpenAI 近期公布的一项实验彻底打破了这个认知：他们的团队在五个月内交付了一个拥有近百万行代码的产品，而其中没有一行是人工编写的。

这不是概念验证，不是 POC，而是一个拥有真实用户、真实部署、真实迭代的商业级产品。

什么是 Agent Harness？

“Agent Harness”（智能体驾驭）是一种全新的软件开发范式：人类掌舵，智能体执行。

简单来说，Harness 是一个让 AI 智能体能够可靠完成复杂任务的工程框架。它不仅仅是"让 AI 写代码"，而是要解决一个更深层的问题：

当代码吞吐量提升 10 倍时，人类工程师如何保持对系统的掌控？

传统的 Harness 概念源自测试领域——测试 Harness 用来连接被测系统与测试用例。而在 Agent 时代，Harness 的含义发生了根本转变：它成为了人类与 AI 智能体之间的协作协议。

核心经验：从"说明书"到"地图"

实验中最有趣的发现之一是：给智能体的文档应该是一张地图，而不是一本说明书。

团队最初尝试创建一个面面俱到的 AGENTS.md 文件，结果失败了：

情境是稀缺资源 — 巨大的指令文件会挤占实际任务所需的上下文
过多指导反而无效 — 当一切都"重要"时，一切都不重要
文档会腐烂 — 不被维护的指南很快就与现实脱节
难以核查 — 单个大文件无法进行覆盖率、新鲜度检查

正确的做法是：将 AGENTS.md 变成内容目录。

代码仓库知识库
├── docs/               # 记录系统
│   ├── architecture/   # 架构文档
│   ├── design/        # 设计文档（含验证状态）
│   └── plans/         # 执行计划
└── AGENTS.md          # 地图 (~100行)

智能体从一个"小而稳定的入口"开始，按需探索更深层次的信息——这就是渐进式披露。

智能体优先的设计原则

1. 可观测性即基础设施

为了让智能体能够验证和调试自己的输出，需要把应用对智能体"可见"：

日志、指标、追踪 → 通过本地可观测性堆栈展示给智能体
UI 自动化 → 接入 Chrome DevTools 协议，智能体可以截图、操控 DOM
临时环境 → 每个任务在独立实例中运行，完成后连同日志一起销毁

这意味着，像"确保服务启动在 800ms 内完成"这样的需求，变得完全可行。

2. 边界处的强类型约束

团队发现，让智能体在边界处解析数据形状比让它自由发挥更可靠。强制执行不变量，让智能体能够快速交付而不必担心削弱基础。

3. 智能体对智能体的审核

人工 Code Review 并非必须。团队建立了智能体间的审核机制：

人类描述任务 → Codex 执行 → 打开 PR
    ↓
Codex 自我审核 + 额外智能体审查
    ↓
响应反馈 → 循环直到所有人满意

结果：三名工程师平均每天处理 3.5 个 PRs，且随团队规模扩大而增加。

关键洞察：人类真正稀缺的是什么？

实验揭示了一个深刻的事实：

当智能体可以完成几乎所有编码工作时，人类工程师唯一的稀缺资源是：时间和注意力。

因此，工程师的工作重心发生了转移：

传统模式	Agent Harness 模式
编写代码	设计环境
实现功能	明确意图
调试修复	构建反馈回路

人类的角色变成了"系统架构师"和"智能体协调者"，而不是代码执行者。

我们能学到什么？

渐进式上下文 — 不要一次性塞给智能体所有信息，设计好导航结构让它按需获取
让系统对智能体友好 — 可观测性、可测试性、清晰的边界——这些不仅是给人类工程师的礼物，也是给 AI 智能体的
文档即代码 — 文档要版本化、交叉链接、可验证，避免成为"腐烂的坟场"
接受"智能体优先"的架构思维 — 当智能体成为主要生产者，代码库的设计要以智能体的可读性为先

结语

OpenAI 的实验并非要证明"人类工程师将被取代"，而是展示了一个新的可能：当繁琐的代码执行交给智能体，人类可以专注于真正需要创造力、判断力和系统思考的工作。

Agent Harness 不仅仅是技术框架，更是一种思维方式的转变。它要求我们重新定义"软件开发"的边界，重新思考人与 AI 的协作模式。

未来已来。只是还未普及。

本文参考 OpenAI 官方博文 Harness Engineering

Agent Harness 配图

前言