最近读了一篇 OpenAI 的技术博客《Harness engineering: leveraging Codex in an agent-first world》，文中提到的 Harness engineering 给了我不少启发。更重要的是，它讨论的很多问题与痛点，在我们团队的 vibe coding 工程实践中几乎都在真实遇到过：当AI Agent让代码产出不再稀缺，质量闭环、上下文管理、架构一致性、以及人类精力被消耗在“检查与返工”上，这些开始成为新的主矛盾。

我理解 Harness engineering 的核心目标可以概括为三点：
1、把“写代码”从瓶颈中移走。
随着大模型能力与 Agent 工具链发展，代码生成的吞吐量已经很高，真正稀缺的是人类的时间与注意力。因此提升工程效率的关键，不是让人类更快地写实现细节，而是让人类更多承担决策、优先级与验收，把编码、补测试、补文档、改 CI 等“细粒度产出”交给 Agent。
2、把智能体纳入可控的工程系统。
对生产级工程项目而言，追求的并不是“更会写代码的模型”，而是让 Agent 在明确目标与约束下，能够稳定地产出可合并、可运行、可回归验证的变更。
3、让“纠错成本低于等待成本”。
在高吞吐环境里，许多传统的阻塞式门禁（merge gate）会把等待变成主要成本，反而降低整体效率。更合理的目标是建立快速试错、快速修正、并能持续清理漂移的机制，让系统能在高频迭代下保持可控。

围绕这些目标，Harness engineering 要做的本质上是一套“把软件工程流程产品化”的方法论：
首先是角色重构：工程师不再以“亲手写代码”为中心，而是聚焦在三件事上——设计环境（工具与运行时）、表达意图（规格与验收标准）、构建反馈回路（测试、可观测性、评审与修复）。当 Agent 失败时，不是简单地“再试一次”，而是要追问到底缺了什么能力、约束或工具，并把修复方案编码进仓库，让后续任务复用并产生复利。

其次是提升可读性与可验证性，把 UI、日志、指标等运行态信号变成 Agent 可直接使用的输入。典型做法包括：让Agent能为每个 worktree 启动独立实例；接入浏览器自动化与 DevTools 能力，用截图、DOM 快照与导航能力完成端到端复现与验证；同时将可观测性尽量本地化、临时化，让 Agent 可以直接查询日志与指标，把“只读代码”升级为“读运行态并用证据驱动修复”。当这些能力到位后，诸如性能红线、关键链路时延上限、交互路径正确性等约束，才会从“口头要求”变成可执行的验收条件。

第三是把仓库变成事实记录系统（system of record），让关键知识在 repo 内结构化、版本化并可校验。与其写一份超长说明书，不如用一个短小的 AGENTS.md 做“目录与地图”，把事实、决策与规则沉淀在 docs/、架构文档、执行计划、质量评分等可审计、可追溯的制品里，并通过 CI 与 linter 机械化检查文档的新鲜度、交叉链接与结构完整性，再配合周期性的“doc-gardening/cleanup agent”去自动修补过期内容，降低知识漂移带来的成本。

第四是机械化架构约束与“品味不变量”。关键不在于规定实现细节，而在于强制不变量，例如分层依赖方向、允许的依赖边、边界数据校验、结构化日志、命名规范、文件大小上限、可靠性要求等。更进一步，把整改建议写进 linter 报错信息，相当于把评审意见前置为可执行规则，让 Agent 在开发过程中自动被“引导到正确的轨道”。

第五，合并哲学需要随吞吐改变。在“Agent 吞吐远大于人类注意力”的前提下，应减少阻塞式门禁，保持 PR 短生命周期；对测试抖动等问题，更倾向于后续重跑与快速跟进修复，而不是长时间阻塞主流程。因为在这种系统里，纠正往往便宜，等待反而昂贵。

最后是反熵机制：像垃圾回收一样持续清理漂移。智能体会复制仓库里已有的模式，包括不均衡或不够理想的坏模式，因此必须有周期性扫描、质量打分、定向重构的后台任务，把人类的审美与规则“捕获一次、持续执行”，避免团队陷入每周花大量时间清理“AI 生成残渣”的被动状态。

Harness engineering 的价值在于提供了一个明确的方向：让Vibe Coding能稳定可控地产出”。当我们把目标、约束、证据与纠错机制都工程化之后，Vibe Coding 才有机会从灵感驱动的快速产出，升级为可持续的生产力。