graph TB
subgraph Harness["Harness Engineering 体系"]
direction TB
CE["上下文工程<br/>Context Engineering"]
AC["架构约束<br/>Architectural Constraints"]
GC["垃圾回收<br/>Garbage Collection"]
end
subgraph CE_Detail["上下文工程"]
KB["仓库内知识库<br/>AGENTS.md / docs/"]
OB["可观测性接入<br/>Logs / Metrics / Traces"]
BR["浏览器驱动<br/>Chrome DevTools"]
end
subgraph AC_Detail["架构约束"]
LI["自定义 Linter"]
ST["结构化测试"]
LA["分层架构规则"]
end
subgraph GC_Detail["垃圾回收"]
DS["文档扫描 Agent"]
QG["质量评分追踪"]
RR["自动重构 PR"]
end
CE --> CE_Detail
AC --> AC_Detail
GC --> GC_Detail
classDef main fill:#1A9090,stroke:#0d5454,color:#fff
classDef sub fill:#0d5454,stroke:#1A9090,color:#e0f0f0
classDef detail fill:#1a2e2e,stroke:#1A9090,color:#b0d8d8
class CE,AC,GC main
class CE_Detail,AC_Detail,GC_Detail sub
class KB,OB,BR,LI,ST,LA,DS,QG,RR detail
业界怎么看？
Harness Engineering 这个概念一出来，社区反应很有意思。
看好的一方认为这是 AI 编程从"辅助工具"到"工程范式"的关键跳跃。Towards AI 的文章直接用了"Beyond Copilot"这个标题，认为 2026 年是从 Copilot 模式转向 Agentic Harness Engineering 的转折点。
第三，AI 编程会惩罚每一个没有好好遵循软件开发流程的人。 这句话听起来有点刺耳，但确实是这篇文章给我最大的启发。那些你一直觉得"以后再补"的东西——软件文档、测试用例、边界定义、架构规范——在 AI 原生开发的世界里，不是锦上添花，而是基础设施。Agent 需要这些东西来理解你的系统，才能自动介入。
第四，纪律没有消失，只是换了个地方。 OpenAI 团队的原话是："Building software still demands discipline, but the discipline shows up more in the scaffolding rather than the code."（构建软件仍然需要纪律，但纪律更多体现在脚手架而非代码本身。）
题外话：
今天公司裁员了。受影响的主要是前端和测试，后端研发也有一些。公司效益是主因，但 AI 的影响也占了不小的比重。不只是我们，很多大公司最近也接连有动作。预感今年对程序员、对整个国内软件开发行业，都会是特别的一年。大家加油吧。
最近在读 OpenAI 刚发的一篇博文。标题叫 "Harness engineering: leveraging Codex in an agent-first world"。读完之后的感受很复杂——一方面是对技术趋势的兴奋，另一方面是对行业变化的焦虑。
这篇文章讲的事情很简单：OpenAI 内部一个小团队，从一个空的 git 仓库开始，用 0 行手写代码，5 个月交付了一个百万行级别的内部产品。每一行代码——业务逻辑、测试、CI 配置、文档、可观测性工具——全部由 Coding Agent 生成。
3 个工程师，平均每人每天 3.5 个 PR，效率是传统方式的 10 倍。
这不是 demo，不是 POC，是一个有真实日活用户的产品。
这篇文章适合正在思考 AI 如何改变软件开发流程的工程师和技术管理者。不管你是想了解前沿实践，还是想为团队找到 AI 落地的方向，都值得花时间读一读。
太长不看版
一、什么是 Harness Engineering？
先从一个类比说起
如果把 AI Agent 比作一匹马，那 Context Engineering（上下文工程）解决的是"怎么跟马沟通"的问题——给它正确的指令、足够的信息。而 Harness Engineering 解决的是另一个问题：缰绳、马鞍、围栏和道路维护。
不管马多聪明，你不可能同时安全地跑十匹马，除非这些基础设施到位。
这个类比来自 SmartScope Blog，很精准地抓住了 Harness Engineering 的本质：它不是关于模型本身，而是关于模型周围的一切。
Martin Fowler（对，就是那个写《重构》的 Martin Fowler）在读完 OpenAI 这篇文章后，把 Harness 的组成拆成了三类：
Latent Space 的总结更直接：
换句话说，模型是原始智能，Harness 是让它变得有用的那套系统。
业界怎么看？
Harness Engineering 这个概念一出来，社区反应很有意思。
看好的一方认为这是 AI 编程从"辅助工具"到"工程范式"的关键跳跃。Towards AI 的文章直接用了"Beyond Copilot"这个标题，认为 2026 年是从 Copilot 模式转向 Agentic Harness Engineering 的转折点。
持保留态度的也不少。Nonsense.io 的作者坦言："我读完之后一直在想，这到底是一百万行不可维护的垃圾代码，还是对近期软件工程未来的一瞥？"
Martin Fowler 则提出了一个关键问题：这套体系能不能用在已有的老项目上？ 她把这比作"在一个从来没跑过静态分析的代码库上第一次开启 lint——你会被告警淹没"。
这些不同的声音恰恰说明了一件事：Harness Engineering 不是银弹，但它确实指向了一个值得认真对待的方向。
二、OpenAI 的实践：从空仓库到百万行代码
实验设定
OpenAI 这个实验的约束条件非常极端：0 行手写代码。
2025 年 8 月底，第一个 commit 落入一个空仓库。初始脚手架——仓库结构、CI 配置、格式化规则、包管理器设置、应用框架——全部由 Coding Agent CLI 生成。甚至指导 Agent 如何在仓库中工作的 AGENTS.md 文件，本身也是 Agent 写的。
5 个月后的成绩单：
工程师角色的重新定义
这里最值得工程师警惕的是：人的角色变了。
过去：工程师写代码，Agent 辅助。 现在：Agent 写代码，工程师设计环境。
OpenAI 团队的原话是："Humans steer. Agents execute."（人类掌舵，Agent 执行。）
具体来说，工程师的日常工作变成了：
他们甚至把大部分 code review 也交给了 Agent。一个 PR 的生命周期大致是：Agent 写代码 → Agent 自审 → 请求其他 Agent review → 根据反馈迭代 → 所有 Agent reviewer 满意后合并。人类可以介入 review，但不是必须的。
让 Agent "看见"更多
随着代码产出速度上来，瓶颈转移到了人类 QA 能力上。团队的应对策略是：让更多东西对 Agent 可读。
浏览器驱动：通过 Chrome DevTools Protocol，Agent 可以直接操作应用 UI——截图、DOM 快照、导航。这意味着 Agent 能自己复现 bug、验证修复、推理 UI 行为。
可观测性接入：每个 git worktree 都有独立的可观测性栈（Victoria Logs / Metrics / Traces）。Agent 可以用 LogQL 查日志、用 PromQL 查指标。这样一来，"确保服务启动在 800ms 内完成"这种 prompt 就变得可执行了。
他们经常看到单次 Agent 运行持续工作 6 个小时以上——通常是在人类睡觉的时候。
仓库即知识系统
这是整篇文章里我认为最有洞察力的部分。
OpenAI 团队试过"一个大 AGENTS.md"的方案，失败了。原因很直觉：
所以他们把 AGENTS.md 当作目录，而不是百科全书。真正的知识库是一个结构化的
docs/目录：AGENTS.md ← 约 100 行，只是地图 ARCHITECTURE.md docs/ ├── design-docs/ ← 设计文档，带验证状态 ├── exec-plans/ ← 执行计划，分 active/completed ├── product-specs/ ← 产品规格 ├── references/ ← 外部参考（llms.txt 格式） ├── DESIGN.md ├── FRONTEND.md ├── QUALITY_SCORE.md ← 质量评分 └── SECURITY.md核心原则是渐进式披露：Agent 从一个小而稳定的入口开始，被教会"下一步去哪里找"，而不是一上来就被信息淹没。
更关键的一句话："从 Agent 的视角看，任何它在运行时无法访问的东西，等于不存在。"
那个在 Slack 里对齐的架构决策？如果没有写进仓库，对 Agent 来说就是不可见的——就像一个三个月后入职的新人也不会知道一样。
架构即护栏
文档只能解决一半问题。另一半靠机械化的架构约束。
OpenAI 团队围绕一个严格的分层架构模型构建应用。每个业务领域被划分为固定的层级，依赖方向严格校验，允许的边只有有限的几条：
跨切面关注点（认证、连接器、遥测、特性开关）通过唯一的显式接口 Providers 进入。其他一切都被禁止，并通过机械化手段强制执行。
他们的原话很到位："这是你通常会推迟到有几百个工程师时才做的架构。用 Coding Agent 的话，这是一个早期前提条件：约束才是让速度不带来衰退的东西。"
具体的执行手段包括：
在人类优先的工作流里，这些规则可能显得吹毛求疵。但对 Agent 来说，一旦编码，就在所有地方同时生效。
垃圾回收机制
Agent 会复制仓库中已有的模式——包括不好的模式。时间一长，漂移不可避免。
团队最初的做法是每周五手动清理"AI 垃圾"，占了 20% 的工作时间。显然不可持续。
后来他们把"黄金原则"编码进仓库，建立了定期清理流程：
这就像垃圾回收。 技术债像高利贷——持续小额偿还，远好过攒着一次性爆发。人类品味只需捕获一次，然后在每一行代码上持续执行。
三、落地核心要素：复制这套体系需要什么？
读完 OpenAI 的实践，一个自然的问题是：如果我想在自己的团队里落地，需要具备哪些要素？
1. 仓库即唯一真相源（Repository as System of Record）
不是可选项，是前提。
docs/结构化知识库，支持渐进式披露2. 机械化的架构约束（Mechanically Enforced Architecture）
靠人记不住，靠 Agent 也不够，靠工具强制执行。
3. Agent 可观测性（Agent-Legible Observability）
Agent 不能只写代码，还要能"看到"代码运行的效果。
4. 持续的质量治理（Continuous Quality Governance）
不是一次性的代码审查，是持续运转的质量机器。
5. 渐进式自治（Progressive Autonomy）
不是一步到位，是逐步放权。
OpenAI 团队目前已经到了 Level 4：给一个 prompt，Agent 能验证代码库状态 → 复现 bug → 录屏 → 修复 → 验证 → 再录屏 → 开 PR → 响应反馈 → 处理构建失败 → 必要时升级给人类 → 合并。
但他们也坦言：这高度依赖仓库的特定结构和工具，不应假设可以直接泛化。
要素总览
写在最后
读完 OpenAI 的这篇实践，有几个想法想分享。
第一，这是一个基于全新仓库的实验。 从空仓库开始，面向 Agent 构建，没有历史包袱。Martin Fowler 提出的那个问题很尖锐：老项目怎么办？给一个从来没跑过静态分析的代码库装上 harness，大概率会被告警淹没。这是大多数团队面临的现实。
第二，国内现有开发流程的转变会更困难。 很多团队的最终 QA 基本全依赖测试团队的手工测试，开发自己写的单元测试覆盖率低、集成测试缺失、文档更新不及时。这种模式下，Agent 根本没有足够的上下文来理解系统行为。要落地 Harness Engineering，不是加个工具的问题，而是要重建整个质量保障体系——这对很多团队来说，可能比重写代码还难。
第三，AI 编程会惩罚每一个没有好好遵循软件开发流程的人。 这句话听起来有点刺耳，但确实是这篇文章给我最大的启发。那些你一直觉得"以后再补"的东西——软件文档、测试用例、边界定义、架构规范——在 AI 原生开发的世界里，不是锦上添花，而是基础设施。Agent 需要这些东西来理解你的系统，才能自动介入。
第四，纪律没有消失，只是换了个地方。 OpenAI 团队的原话是："Building software still demands discipline, but the discipline shows up more in the scaffolding rather than the code."（构建软件仍然需要纪律，但纪律更多体现在脚手架而非代码本身。）
问题到这里还没结束。Harness Engineering 目前还是一个很早期的概念，OpenAI 自己也承认不知道这套体系在年级尺度上的架构一致性会如何演化。但方向已经很清楚了：未来的软件工程，不是写更多的代码，而是建更好的缰绳。