上个月，OpenAI 发表了一篇文章，标题是《Harness engineering: leveraging Codex in an agent-first world》。

文章中披露了一个内部实验：一个不到 7 人的工程师团队，在短短 5 个月内使用 Codex从零构建并交付了一款包含 100 万行代码的生产级软件。它经历了需求迭代、UI 渲染、后端并发、线上故障与修复的完整生命周期。

而且最重要的是：在这个拥有百万行代码的庞大系统中，人类亲手编写的代码行数为，零。

所有的逻辑实现、CI/CD 流水线配置、测试用例甚至内部技术文档，全部由 Codex 完成。工程师们不再写代码，他们的工作变成了“设计环境、制定约束、明确意图并构建反馈闭环”。OpenAI 将这种全新的开发范式，命名为 “Harness Engineering（驾驭工程）”

这篇博客发布后，引起了不少人的讨论，有人说 Agent = Harness + Model，也有人发表了深刻洞见，见过两次类似的过程：

第一次是 1780 年代詹姆斯·瓦特发明的离心调速器。在那之前，工人必须死死盯着蒸汽机，亲手转动阀门来控制气压；调速器出现后，纯机械的反馈闭环自动接管了阀门。工人失业了吗？没有，但他们再也不用转阀门了，他们变成了“设计调速器的人”。
第二次是 Kubernetes 的诞生。过去，运维工程师半夜爬起来亲手重启崩溃的服务器；有了 K8s 之后，人类只负责声明状态（“我需要三个副本”），控制器负责比对状态并自动拉起服务。人类的工作从“手动重启服务”，变成了“编写系统需调和的规范”。
而现在，第三次来了。只是这一次，被自动化闭环接管的，是“编写代码”本身。这本质上也是计算机科学中“P vs NP”难题的现实写照：生成一个答案极其困难，但验证一个答案却容易得多。 当大模型补齐了廉价生成的算力，人类终于可以从苦工般的“生成者”，转化为系统规则的“验证者”。

很受震撼，但细想，这种所谓的“模式”，早就有了。它根本不是软件工程独有的奇观，而是宇宙和人类文明在处理“复杂性（Complexity）”时，最底层的一条通用法则。

在系统科学中，这被称为 “元系统跃迁（Meta-system transition）”。在历史上，只要一个系统的复杂性突破了人工直接干预的极限，必然会发生从“直接生成（Generation）”到“构建约束与验证规则（Harnessing / Verification）”的回路。

如果跳出代码的局限，你会发现我们在几千年前就已经在使用 Harness Engineering 了：

比如制度与法学，从“人治（直接执行）”到“宪政（设计约束）”；

比如经济学：从“计划经济”到“机制设计”；

你看，瓦特的调速器、Kubernetes、法学、市场经济，它们在底层逻辑上是完全同构的。

所有复杂系统的进化，本质上都只在做两件事：把脑子里的“潜规则”变成机器可读的“死纪律”；把“人工补锅”升级为“自动纠错”。

用稍微抽象一点的话来概括，就是：隐性知识的显性化 + 反馈闭环的向上套壳。

为什么一定会这样演进？因为人脑是有物理极限的。

每当系统的复杂性（无论是并发量、服务链路、还是动辄千万行的代码）彻底撑爆了人脑的“内存”（工作记忆）时，靠堆人力、靠技术大牛的“代码直觉”就全部失效了。 在这个临界点上，人类只有一种自救的办法：

停止作为“劳动力”去直接处理对象，转而作为“造物主”去构建一个带有反馈机制的“约束容器（Harness）”，然后把劳动力外包给非人系统。

理解了这一层，我们再回过头来看当下的 AI 编程浪潮。当代码生成的边际成本趋近于零（Code is free），时代的发展对技术人才提出了截然不同的要求。

在过去六十年里，我们习惯了将脑力耗费在“把逻辑翻译为机器指令”的过程中。而现在，当 AI 能够以机器速度（Machine speed）喷涌出海量代码时，如果缺乏外部约束，这些代码将迅速变成不可维护的技术废墟。时代的瓶颈不再是“如何高效地写代码”，而是“如何在这个高熵的算力洪流中，维持软件系统的秩序”。

那么，在这样一个智能体优先的时代，我们到底该如何去做 Harness？

结合 OpenAI 的博客复盘与系统论原则，落地其实需要完成三个关键视角的转换。虽然 OpenAI 并没有在文章中开源他们内部的具体系统源码，但我们完全可以将这套思想翻译成日常的工程实践。以下，是基于 OpenAI 原理的工程化还原：

第一，赋予系统高维的“机器感官”（Machine-readable Context）

过去我们写监控、打 Log，是为了让“人”能看懂。当接口超时，人类工程师会打开 Grafana 查大盘。但 AI 看不到你的显示器，如果在 Agent 的运行上下文中没有这个数据，那么“超时”对它来说就是绝对的不存在。

Harness Engineer 的第一步，是停止人工 Debug，转而为系统装配高维的“传感器”。你需要把监控堆栈暴露给大模型。

Case 展示：让 Agent 自己查监控

我们不再给 Agent 模糊的提示词“请优化性能”，而是直接在它的工具箱（Tools）里注入查询能力。

# Harness: 赋予 Agent 运行时感知能力def query_promql(query: str, time_range: str) -> str:    """供 Agent 调用：查询系统的实时 Prometheus 指标"""    response = prometheus_client.query(query, time_range)    return format_for_llm(response)# Agent 的自主闭环：# Act: 提交了一段代码并启动测试容器# Observe: 自动调用 query_promql("http_request_duration_seconds{route='/api/auth'}")# Think: "发现 P99 延迟激增到了 1.2s，远超规定的 800ms 阈值，我需要重构数据库查询的并发逻辑..."

不仅是后端，在前端，OpenAI 的做法是将 Chrome DevTools 协议接入智能体，让它自己截取 DOM 快照、甚至录屏对比渲染差异。环境必须变得“机器可读”，AI 才能形成验证闭环。

第二，隐性知识的“显性化与契约化”（Explicitizing Tacit Knowledge）

传统的开发团队充斥着“隐性知识”：只有老员工懂的“代码品味”、不允许 Router 层直接调用 DB 的潜规则。但智能体不懂人情世故，试图用一个写满提示词的超大 AGENTS.md 文件来指导 AI 是徒劳的，因为上下文会遗忘。

Harness Engineer 必须把脑子里的架构洁癖，翻译成冷冰冰的、机器可验证的机制。

Case 展示：架构边界的强硬拦截

我们不再在 Code Review 时苦口婆心地教导 AI，而是写出严格的架构测试（Structural Tests）。一旦 AI 违反，系统在 CI 阶段直接阻断，并抛出带修复指南的错误栈。

// Harness: 使用依赖检查工具（如 dependency-cruiser 或自定义 AST 脚本）import { strict as assert } from 'assert';import { analyzeDependencies } from 'architecture-linter';test('架构契约：UI 层绝对不允许直接调用 Database 驱动', () => {    const violations = analyzeDependencies({        from: 'src/ui-components/**/*',        to: 'src/database/**/*'    });        // 如果 Agent 试图跨层调用，测试直接失败，并将这段信息喂给 Agent 让其反思    assert.equal(violations.length, 0,         "LINTER_ERROR: 发现跨层依赖！UI组件不得直连DB。" +        "请查阅 docs/ARCHITECTURE.md 的分层设计，" +        "你必须通过 src/providers/api-client 进行调用。"    );});

如果一条规矩不能被机器自动化校验，那它就不存在。代码库（Repo）本身，变成了系统唯一的真理来源。

第三，建立对抗机器速度的“代谢机制”（Automated Metabolism）

人类积累一大堆屎山代码可能需要几年，AI 制造代码垃圾只需要几分钟。面对机器制造的高熵，用人力去审查是徒劳的。Harness 体系的最后一块拼图，是建立类似于生物体新陈代谢的垃圾回收机制（GC）。

Case 展示：全自动的架构“清洁工”

OpenAI 的团队最初每周五要花一天时间手动清理“AI 残渣”，直到他们写出了一套后台清道夫。

# Harness: 每日自动巡检与重构流水线 (GitHub Actions)name: Agentic Doc-Gardening & Refactoron:  schedule:    - cron: '0 2 * * *' # 每天凌晨 2 点，人类睡觉时机器运转jobs:  refactor:    runs-on: ubuntu-latest    steps:      - name: 唤醒架构审查 Agent        run: |          agent run --task "扫描过去 24 小时的代码变更" \                    --rule "docs/golden_principles.md" \                    --action "如果发现冗余的硬编码或废弃模式，自动发起重构 PR 并附带解释"

你把团队的“黄金原则”写进系统，清洁工 Agent 7x24 小时地扫描。用一套自动化的演化淘汰流水线，去死死地驯服另一套自动化的代码生成流水线。

当我们把这些抽象的约束、测试和验证闭环部署完毕，看着千百个智能体在极度严苛的测试环境中疯狂试错、崩溃、自我修正，最终析出极其优雅且健壮的系统时，一种前所未有的宿命感会击中我们。

1948 年，当诺伯特·维纳创立“控制论（Cybernetics）”时，他特意选取了古希腊语中的 κυβερνήτης 作为词根，这个词的意思是——“舵手”。

在过去漫长的软件工程史中，我们其实并不是舵手。我们是被绑在需求文档的战船底层，随着产品经理的鼓点，一行一行手动划动桨叶（敲击代码）的苦力桨手。我们沉浸在微观的、汗流浃背的“生成”之中，误以为这就是创造的全部。

每一次元系统的跃迁，都会带来旧有执行者的阵痛。习惯了亲手掌控气压阀的工人，会觉得调速器剥夺了他们的手艺；习惯了敲击键盘、享受心流的程序员，也会因为大模型的暴力生成而感到失落。

但正是在这种剥离微观掌控权的痛楚中，人类换来了系统吞吐量千万倍的爆发。 放弃敲击代码，并不意味着我们在AI面前的溃败。相反，这标志着我们终于从低维的执行苦役中彻底解脱。

当 Code is free，前端没有死，后端也没有死。死去的只是那种将代码当砖头一块块手动堆砌的劳作方式。我们终于可以放下雕刻所用的小刀和沉重的木桨，洗净双手，推开顶层甲板的舱门。

我们接过了船舵，正式驶向星辰大海。