Harness Engineering
AI时代老是冒出一些新词，前不久出现的"Harness Engineering"，翻译过来是"驾驭工程"。
驾驭工程其实你应该不陌生，人类掌舵，智能体执行。看起来跟你使用 Claude Code 开发是一个道理——你提供需求，定义交付形态，定义中间过程约束，其他的都由 AI 自主完成。
OpenAI 的 Harness Engineering 文章
2026年2月，OpenAI 发布了一篇文章，分享他们一个团队在过去五个月里做的实验：构建并交付一款软件产品，其中没有一行代码是人工编写的。
当软件工程团队的主要工作不再是编写代码，而是设计环境、明确意图和构建反馈回路，从而使 Codex 智能体能够可靠地工作时，会发生哪些变化。
这篇文章分享的经验非常值得一读，跟我之前写的 agentic-coding 系列高度呼应。其中有一些重点：
工程师角色的重新定位——管理而非协助
由于不写代码，工程师的工作重点转向了系统、架构和杠杆作用。
-
早期进展比预期慢，环境规范不够明确——智能体缺乏实现高级目标所需的工具、抽象层和内部结构。
-
采取的是深度优先的工作方式——把大目标拆解为小模块（设计、代码、评审、测试），提示智能体去构建，用这些模块解锁更复杂的任务。
-
人类几乎完全通过提示与系统交互。Codex 被指示在本地审核自己的更改，请求额外审查，处理反馈，循环往复直到所有智能体审核通过。
组成Ralph Wiggum 循环：智能体修改代码 → 智能体审查 → 智能体响应审查 → 循环。
提高应用可读性——给智能体装上眼睛
随着吞吐量增加，瓶颈变成了人工 QA。人类的时间和注意力是固定的限制因素，所以要让智能体自己能"看见"更多。
-
让应用可由 Codex 驱动，Codex 能自己复现 bug、验证修复、推理 UI 行为。
- 根据 git worktree 启动Codex。基于主分支创建一个worktree，切换到对应分支。在worktree中启动应用实例，Codex编写验证完成后清理合并。
- 把 Chrome DevTools 协议接入智能体运行时，创建了处理 DOM 快照、截图和导航的 skills。
-
给 Codex 完整的可观测性栈：每个 worktree 启动时，附带启动一个本地的可观测性堆栈，应用把遥测数据写入这个本地栈。智能体可以使用 LogQL 查日志、PromQL 查指标。而且在仓库里封装成一个 skill，Codex 能够直接用自然语言调用。
仓库是记录系统——给地图而不是说明书
给 Codex 的是一张地图，而不是一本 1000 页的说明书。
他们试过"一个巨大 AGENTS.md"的方案，结果是失败：
- 上下文是稀缺资源，巨大指令文件会挤掉任务和代码
- 过度指导反而无效——"当一切都重要时，一切都不重要"
- 文档迅速腐烂，变成陈旧规则的坟场
- 难以被机械检查（覆盖率、新鲜度、所有权）
正确的做法是将 AGENTS.md 视为内容目录。仓库的知识库位于结构化的 docs/ 目录：
AGENTS.md
ARCHITECTURE.md
docs/
├── design-docs/ # 设计文档，含验证状态和核心理念
├── exec-plans/ # 执行计划，含进度和决策日志
│ ├── active/
│ ├── completed/
│ └── tech-debt-tracker.md
├── product-specs/ # 产品规格
├── references/ # 参考文档（为 LLM 优化过的）
├── DESIGN.md
├── FRONTEND.md
├── QUALITY_SCORE.md
├── RELIABILITY.md
└── SECURITY.md
这实现了渐进式披露：智能体从小而稳定的切入点开始，被指引下一步去哪里看，而不是一开始就被淹没。
还有专职的 linter 和 CI 验证知识库的更新状态。一个定期运行的"doc-gardening"智能体扫描过时文档并发起修复 PR。
为智能体的可读性优化
关键洞察：从智能体角度看，运行时无法在上下文里访问到的内容就是不存在的。Google Docs、聊天记录、脑中知识——都无法被系统访问。
因此要不断把更多上下文推入仓库。那次让团队达成共识的 Slack 讨论？如果智能体发现不了，它就跟迟到三个月入职的新员工一样，一无所知。
这带来了明确的取舍：
- 倾向于选择可以在仓库中完全内化推理的依赖项和抽象
- "枯燥"的技术（可组合性强、API 稳定、训练集中表现好的）反而更容易被智能体建模
- 有时候让智能体重新实现部分功能子集，比绕过公共库不透明的上游行为更划算
规范架构与品味——用代码强制执行设计
仅靠文档无法保持全智能体生成代码库的连贯性。关键做法：强制执行不变量，而非对实施过程进行微观管理。
他们将应用架构建立在一个严格的分层模型上：
Types → Config → Repo → Service → Runtime → UI
↑
Providers（唯一的横切关注点入口）
这些约束通过自定义 linter（当然也是 Codex 生成的）和结构测试机械性强制执行。听起来迂腐，但对智能体来说这是倍增器——一旦编码，立即在所有地方生效。
人类品味也持续反馈到系统中。审查评论、重构 PR、用户 bug 被记录为文档更新，或直接编码到工具中。文档不够用时，就把规则转化为代码。
吞吐量改变了合并的理念
随着 Codex 吞吐量增加，许多传统工程规范变得不再适用。
仓库尽量减少阻塞合并门。PR 生命周期很短。测试偶发失败通常通过后续重跑来处理，而非无限期阻碍进展。在智能体吞吐量远超人类注意力的系统中，纠错成本低，等待成本高。
在低吞吐量环境里这么做是不负责任的。在这里，这通常是正确的选择。
"智能体生成"到底意味着什么
OpenAI 说的"智能体生成"指的就是整个仓库，包括：
- 产品代码与测试
- CI 配置和发布工具
- 内部开发者工具
- 文档和设计历史
- 评估框架
- 审查评论和回复
- 管理仓库本身的脚本
- 生产仪表板定义文件
人类始终参与其中，但抽象层次变了：优先处理工作、把用户反馈转化为验收标准、验证结果。智能体卡住时，识别缺失的东西——工具、指导和约束、文档——并反馈到仓库中，始终由 Codex 自己写修复。
不断提高的自主水平
随着越来越多的开发环节被编码到系统中，仓库最近跨过了一个重要门槛：Codex 可以端到端驱动一个新功能。
给定一个提示，智能体现在可以：
- 验证仓库当前状态
- 重现已报告的错误
- 录制一个演示故障的视频
- 实施修复
- 通过运行应用验证修复
- 录制第二个视频演示解决方案
- 打开 PR
- 回应智能体和人类反馈
- 检测并修复构建失败
- 仅在需要判断时才交由人工处理
- 合并更改
这个行为很大程度上取决于仓库特定的结构和工具投入，目前不能假设它可以泛化。
熵与垃圾收集
完全自主的智能体也带来了新问题。Codex 会复现仓库中已存在的模式——包括不均衡或不够理想的模式，这导致代码漂移。
最初团队每周五花 20% 的时间清理"AI 残渣"。不可扩展。
于是他们将"黄金原则"直接编码到仓库中，建立循环清理流程。定期运行后台 Codex 任务，扫描偏差、更新质量评分、发起针对性重构 PR——其中大多数可以在一分钟内完成审查并自动合并。
这就像垃圾回收。技术债务是一笔高息贷款：不断以小额方式偿还，总比堆积后再痛苦地一次性解决要好。
他们仍在学习的内容
- 在全智能体生成的系统中，架构连贯性如何随时间演变——尚不清楚
- 人类判断力在哪些地方能发挥最大作用，以及如何编码这种判断力
- 随着模型能力增强，系统将如何演变
但有一点是明确的：构建软件仍然需要纪律，但纪律更多地体现在支撑结构上，而不是代码上。 保持代码库一致性的工具、抽象和反馈回路变得越发重要。
最棘手的挑战集中在：设计环境、反馈回路和控制系统，帮助智能体实现目标——大规模构建和维护复杂、可靠的软件。
回到 helloagent
这篇文章几乎完美地串起了我前面八篇文章想表达的核心逻辑：
- 提示词工程（之二）：工程师通过提示与系统交互，定义行为边界
- 上下文工程（之三）：仓库是记录系统，渐进式披露，地图优于说明书
- MCP（之五）：Chrome DevTools MCP、可观测性工具，把外部能力接给智能体
- Skills（之六）：skills 让智能体能力模块化和可复用
- vibecoding（之七）：人类掌舵、智能体执行，从"写代码"转向"设计环境"
- agent workflow（之八）：Ralph Wiggum 循环、智能体对智能体审查、端到端自主
Harness Engineering 不是单独的一门技术，而是当你就把前面这些全部做到位之后，自然而然浮现出来的一种新工程范式。
关键不是模型有多聪明，而是你为智能体搭建的支撑体系有多坚实。