很多人在讨论AI编程时，常常抱怨生成的代码不好用，甚至显得有点“呆板”。这时候，大家往往会怀疑：是不是自家训练的模型水平不行？为什么别人的AI用起来得心应手，而自己的却像两个时代的产物？这样的代码真的敢部署到生产环境吗？

其实，问题并不完全出在模型上。模型能力固然有其天花板，但更关键的因素在于你如何组织AI工程，以及你选用的Agent工具。这些才是决定最终产出的核心变量。

与纯粹靠Prompt跟AI对话的方式不同，真正的AI工程化管理能带来截然不同的体验。例如，当前流行的SDD（Spec-Driven Development，规范驱动开发）就依赖于详尽的文档来支撑迭代、记录和检索，而非简单丢几句话等待结果。

今天，我们来深入剖析OpenAI在AI工程实践中的核心理念。他们认为，软件工程的重心正从“编写代码”转向“构建让AI高效执行的系统”（即Harness）。工程师的角色也因此演变——不再只是代码的编写者，而是设计AI工作环境的人。这套方法被称为 Harness Engineering，简单来说，就是为AI Agent搭建一个可运行、可反馈的完整系统，负责控制Agent、提供工具、管理执行、校验结果。

这一转变有多重要？OpenAI内部一个项目仅前期搭建就耗费了五个月。症结并非出在Codex（他们的代码模型）上，而是环境定义不够完善——Agent缺少实现高层目标所需的工具、抽象概念和内部结构。这正是许多AI编程项目失败的原因：没有为AI提供“即插即用”的运行条件，导致大量无效的人工干预和返工。

针对此问题，OpenAI提出了Harness的几项核心实践要点，下面逐一解读。

1、 上下文工程（Context Engineering）：为AI提供精准的“背景资料”

Agent的能力高度依赖上下文信息。你提供的需求描述质量，直接决定了每次Token消耗的性价比。常见的上下文类型包括：

• 代码仓库文档
• API文档
• 代码结构说明
• 设计规范

这里有一个常见误区：不要试图一次性塞给AI一个庞大的 AGENTS.md 文件。我们此前专门讨论过，过长的文档只会产生反效果，让AI“消化不良”。OpenAI的做法更为巧妙，他们的 AGENTS.md 仅保留约100行，相当于一个“目录”或“导航图”，其中布满链接，指向更深层、更具体的文档。

AGENTS.md
ARCHITECTURE.md
docs/
├── design-docs/
│   ├── index.md
│   ├── core-beliefs.md
│   └── ...
├── exec-plans/
│   ├── active/
│   ├── completed/
│   └── tech-debt-tracker.md
├── generated/
│   └── db-schema.md
├── product-specs/
│   ├── index.md
│   ├── new-user-onboarding.md
│   └── ...
├── references/
│   ├── design-system-reference-llms.txt
│   ├── nixpacks-llms.txt
│   ├── uv-llms.txt
│   └── ...
├── DESIGN.md
├── FRONTEND.md
├── PLANS.md
├── PRODUCT_SENSE.md
├── QUALITY_SCORE.md
├── RELIABILITY.md
└── SECURITY.md

在这个体系中，设计文档本身也是一个索引目录，包含验证状态以及一套以Agent为中心的运行原则。架构文档提供顶层模块和包的映射关系。执行计划则根据任务规模采用不同形态：小的改动使用轻量级计划，大项目则记录在详细的执行计划文档中，附带进度和决策日志，这些日志甚至会被提交到代码仓库。

2、 工具链（Tooling）：为Agent装上“手和脚”

不要让Agent只会“纸上谈兵”，要让它能执行真实操作，而不是每一步都需要人工介入。常见的工具集包括：

• Git
• shell
• CI
• 测试运行器
• 构建系统

Agent的目标是形成“编写代码 → 运行 → 修复”的闭环，这才是Agent应有的完整能力链。OpenAI的Codex直接使用 gh、本地脚本等标准开发工具来收集上下文信息，无需人工复制粘贴。

为了实现Agent并行工作、快速验证，他们将应用项目设计为基于Git Worktree独立启动。每次Codex进行一次更改，即可立刻启动一个实例进行测试，多个项目修改可同时并行推进。

3、 反馈循环（Feedback loops）：构建自动化的“自检系统”

Agent需要一个完整的自动反馈系统，比如：

• CI
• 单元测试
• linter
• 静态分析

有了这套系统，Agent才能真正实现“自驱动”，这也是许多AI编程实践中容易被忽视的一环。只有具备明确的测试约束和验收标准，AI才能自动验证、自动修复，从而大幅减少人工介入。

在OpenAI的项目中，日志、指标和追踪信息通过一个本地的可观测性堆栈暴露给Codex，该堆栈对每个Worktree是临时的。Codex运行在完全隔离的版本上，任务完成后这些日志和指标即被销毁，但Agent可以在运行时使用LogQL查询日志，使用PromQL查询指标。有了这些上下文，诸如“确保服务启动时间在800毫秒内”或“四个关键用户旅程的耗时均不超过两秒”之类的**提示，对AI来说就不再是空话，而是可以被验证和修正的目标。

4、 架构约束（Architectural Constraints）：必要的“边界感”与“规则感”

最后，给AI设定行为边界同样重要。比如：

• 代码结构规范
• 模块边界约定
• API 规则
• Lint 规则

这些规则能防止Agent写出结构混乱的代码，确保它尽可能遵循规范。一个有趣的观点是：最佳的Agent管理方式是让它能够直接从代码库推断出完整的业务领域。因此，工程师需要在代码中逐步加入更多上下文信息，例如“本次需求讨论的结论是什么”、“针对某个变更需做哪些调整”。这至关重要，否则Agent可能在一次修改中将团队迭代了三次的关键功能又改回最初的版本。

此外，Agent在边界清晰、结构可预测的环境中表现最佳。一个层级分明、流向清晰的架构，对Agent的维护最为友好。

这样做的目的很简单：划定执行边界，允许局部自主。OpenAI认为，Agent生成的代码不必完全符合人类的个人风格偏好，只要输出正确、易于维护，且方便后续的Agent运行，就算达标。

一旦Harness管理得当，后期就能实现高效的并行开发。

Planner Agent
│
┌───────────────┼───────────────┐
│               │               │
Code Agent1     Code Agent2     Code Agent3
│               │               │
Worktree1       Worktree2       Worktree3
│               │               │
Test            Test            Test
│               │               │
└─────────────── Merge / PR ────────────┘

可以看到，在传统的“古法编程”中，流程是：

设计 → 写代码 → 测试 → 部署

而在“Agent-first”开发模式下，流程变为：

设计Harness → Agent生成代码 → Agent测试 → Agent修复 → Agent提交PR

工程师的工作重心也随之转变，主要负责审查、架构设计、信息输入和方向决策。OpenAI在实践中总结出以下几条经验：

• 复杂、花哨的技术对AI不友好，应优先选择“无聊技术”、标准库和明确API，这样AI更容易理解和上手。
• 文档在某种程度上是写给Agent看的，需转化为机器可读的上下文。
• 小任务的效果远优于大任务，细化任务非常重要。
• 自动反馈是核心，应尽可能让AI自己发现问题、测试和修复。例如在Flutter场景下，Agent可以在修改后直接运行 flutter run，然后从终端日志中定位问题。

由此可以得出一个判断：现阶段AI产品的竞争力已不再单纯取决于模型本身，而在于Harness。一个好的Harness（如Claude Code或Codex）能决定模型能力的上限。因为它决定了：

• AI能访问哪些工具
• AI能获取多少上下文
• AI能否实现自我修复

现在你应该明白了，为什么真正的AI编程并非简单的Prompt Engineering，而是一项Harness Engineering。你的项目需要持续迭代和修改，AI是健忘的，你的任务就是构建一个系统，让它在需要时能轻松回忆过去，再去实现未来。

链接

openai.com/index/harne…