1. AI 编程的一些问题(背景)

有多少人在Vibe Coding时碰到过这些典型的“翻车”场景？

1. 文档和代码完全脱节，上下文要么跟不上节奏、要么冗余得一塌糊涂，结果就是代码质量越来越离谱。更让人头疼的是，明明上一轮刚刚强调过的“禁忌”，下一轮对话就被AI忘得一干二净。 2. 代码和架构偏离到失控的地步。明明一小时就能搞定的事情，结果得花两三个小时去反复调教Prompt。审查AI生成的代码更是精神折磨，特别是你已经把意图翻来覆去说了很多遍，对方给你交上来的东西还是怎么看怎么不对劲。 3. 垃圾代码越堆越多。AI完全不会主动清理上一轮留下的废代码，反倒是在废料上继续往上盖，废料就这样一层层堆积，越来越乱。 4. 生成的代码审查起来实在令人头大。除非是对业务逻辑非常明确的“安全区”，否则不敢轻易不经过严格审查就直接上线，这要是出了线上事故，锅肯定得自己背。 说到底，缺的不是AI的能力，而是对AI的约束、正确的引导和及时的修正反馈机制。而Harness Engineering，正是在这个背景下站到了台前。

2. Harness Engineering 出现

随着工程实践的不断深入，这一领域已经从最开始的上下文工程，逐步进化到了Harness Engineering。它的核心理念很简洁——“Humans steer, agents execute”（人类掌舵，袋里执行）。在这个新范式里，工程师的角色彻底变了，从“编码者”变成了“系统驾驭者”。核心任务不再是一行一行地去写代码，而是设计一套能让AI高效、可靠工作的系统和环境。通过环境、工具、规则和反馈机制，让AI在高速奔跑时既能释放全部力量，又不会跑偏。本质上，Harness Engineering是一整套围绕AI Agent构建的约束、反馈与控制系统。

3. OpenAI 的百万行代码实验

OpenAI内部就做过一个特别能说明问题的实验，整个周期长达五个月，充分展现了Harness Engineering的巨大潜力。

试验的起点，就是一个3人小组和一个空的Git仓库。整整五个月里，他们没有手动写过一行源代码。完全依靠AI智能体（Codex）完成了整个系统的构建。最终的结果是，他们交付了一个包含超过**100万行代码**的完整Beta版产品。整个开发周期中，合入了大约1500个拉取请求（PR）。OpenAI自己估算，这种开发方式比传统人工开发大概节省了**10倍的时间**。

在整个开发过程中，三个人没有手写任何一行代码。那AI是怎么做到不乱搞的？细节很关键：

• 团队提前编写了非常详尽的架构约束文件。
• 给AI接入了Chrome DevTools协议，AI可以通过截图自己去验证前端UI渲染是否符合预期。
• 设计了严密到位的反馈回路，最终AI能在90%的情况下自主修复CI失败。

4. Harness Engineering 的演进

这条路不是一步到位的。整个行业的AI工程化经历了清晰的几个阶段。

2.1. Prompt Engineering

2022年到2024年，这一阶段被称为提示词工程。那是AI工程化的启蒙期，核心逻辑就是打磨好“一次性指令”。通过few-shot、角色扮演这些技巧，让模型单次输出时更精准、更听指挥。本质上是“教AI怎么听好一句话”。但这个阶段的局限也很明显，指令的有效性严重依赖人工经验，没法规模化复用，面对复杂任务的持续输出需求时，就显得力不从心了。

2.2. Context Engineering

2025年左右，行业进入了上下文工程阶段，算是破除了提示工程单点输出的瓶颈。这个时候大家意识到了，单靠一条指令根本支撑不起复杂的决策过程。于是开始主动为模型动态构建完整的上下文，包括文件、历史记录、知识库等。让AI在做决策时能拿到全方位的参考信息。从这个角度看，“给AI配全了参考资料”。不过这个阶段本质上还是一个“被动响应”的模式，缺乏对AI输出的主动控制，复杂任务落地时的稳定性依然是个大问题。

2.3. Harness Engineering

到2026年，Harness Engineering作为一个新的工程范式，站上了行业舞台的中心。它把前两个阶段的核心能力都吸收了，又提升到了对全生命周期进行控制的系统设计层面。通过约束、反馈、架构规则、工具链管理，让AI Agent能够长期稳定地、高质量地完成工作。它的本质更像是“为AI搭建一个能长期高效干活的办公室”，而不是只给一张任务清单。

5. Harness Engineering 核心组成

要构建一个完整的控制系统，Harness Engineering必须在三个维度上同时发力：上下文、约束与熵管理。

5.1. 上下文工程

核心的问题在于：AI Agent根本没办法访问你脑子里那些架构决策、团队约定和历史教训。

针对这一点，核心做法主要有几个：

• 为Agent准备好“导航地图”。OpenAI的项目里散布了88个AGENTS.md文件。根目录的文件定义全局默认规则，子目录的文件则负责覆盖本地的局部规则。
• 遵循“渐进式披露”原则。AI从根目录入口文件开始，按需深入到具体子目录中获取局部上下文，而不是一次性把海量信息灌进去。

OpenAI的核心思路就是，把代码仓库当成Agent唯一的知识来源。所有规则、文档和代码都纳入版本管理，之前靠老员工“口口相传”的那些隐性经验，全部显性化，让Agent随时能找到所需的信息。同时，他们刻意摒弃了“大一统的指令文档”，改用了不超过60行的AGENTS.md做“目录”，通过渐进的披露方法，确保Agent在每个任务里只获取自己需要的上下文，既防止了信息过载，也避免了关键约束被遗漏。此外，还给Agent配上了浏览器、可观测性栈，让它自己能验证结果、排查问题。

5.2. 架构约束

核心问题刚好相反：靠人工Code Review，完全跟不上AI的代码产出速度。架构漂移和安全失控成了必然。

解决方案也清晰——把架构规则“代码化”，让机器而不是人来守住边界。具体操作中，OpenAI实现了用AI自己编写Linter（代码检查工具）来约束AI自己。

强制执行的“围栏”是这样：比如，规定“service层不能反向依赖controller层”，把这个规则直接写进Linter。AI每次提交代码，Linter都会自动运行。一旦违规，代码合并请求就直接被拒绝，根本过不了。

同时，反馈闭环也设计得很巧妙。Linter的错误提示信息本身就被当成了上下文的一部分，它会告诉AI“哪里错了”以及“怎么改”。AI读取后可以自动修正代码再重新提交。Harness不会依赖任何人去审查，而是直接把架构文档、依赖关系、格式规范转成可执行、可强制的硬约束。一旦AI的输出违反了规则，CI流程会直接挂掉，且报错信息自带修复指引。这样做，相当于把“老师傅的经验”写进了编译器。

5.3. 熵管理

核心问题是，AI会不自觉地复制代码库中已经存在的坏模式，导致技术债务呈指数级放大。

解法也很直接——把清理技术债务变成一个全自动化、持续进行的流程。核心在于构建一个“后台清洁Agent”，定期扫描代码库，找到那些偏离了“黄金原则”（比如代码重复、模式不佳）的段落，然后自动生成重构的PR。这就好比给代码库装了垃圾回收机制，持续地、小额度地偿还技术债务。

解决了AI规模化输出带来的“混乱”问题。AI生成的代码里，技术债的增速是肉眼可见的。Agent不会主动去清理上一轮的遗留问题，而是基于废料继续往上堆。OpenAI的方案就是部署GC Agent（垃圾回收Agent），定期扫描并修复过时的文档、架构漂移、代码异味。最终实现的是代码库的“自我清洁”，防止信噪比持续恶化。

6. 行业实践经验

• 设计真正AI友好的架构。事实证明，AI在结构清晰、边界明确的系统里干活效率最高。
• 保证反馈闭环。反馈不能断，AI需要知道对与错以及怎么改。
• 建立完善的技术债务清理机制。别等到坏模式扩散到整个项目再动手。
• 重新定位工程师角色。核心技能不再只是编码，而是转向系统设计、规则制定、反馈循环设计与多Agent协调。
• 把隐性知识系统化。建立可靠的知识库维护机制，确保信息时效性，别让Agent总拿过时的信息去犯错。

7. 重构AI时代的工程师角色

Harness Engineering的兴起，绝不只是工程方法论的变化，它也在深刻重塑着人类工程师的定位。过去，一个优秀的工程师靠的是“写代码”的能力；而在Harness时代，工程师变成了“系统驾驭者”，核心任务不再是写代码，而是设计工程环境、明确任务意图、构建高效的反馈闭环，把精力从繁琐的编码里解放出来，聚焦到更核心的系统设计上。

工程师从“代码生产者”向“系统监考官”转型的趋势，已经非常明显。一线工程师不再需要直接去编写业务逻辑，而是写“描述逻辑的逻辑”——架构文档、验证规则和反馈系统。在AI能处理好琐碎编码任务的时候，人类对系统整体稳定性、模块解耦和长期技术债务的判断力，变得比以往任何时候都重要。

未来的顶尖工程师，其价值的衡量方式不会是手写代码的速度，而是其构建的“AI运行环境”的质量。正如Martin Fowler所说：“我们正在进入一个工程师不再追求‘写得更好’，而是追求‘管得更好’的时代。”对于身处一线的开发者，掌握Harness Engineering，可以说就是通往AI时代高级工程师的必经之路。

8. 结束总结

Harness Engineering，从根本上预示着未来软件开发将运行在两个并行不悖的闭环里：

• 人类循环：关注的主题是“为什么做”——业务目标、产品决策和战略方向。
• AI循环：关注的主题是“怎么实现”——代码生成、测试、修复和验证。

人类不再逐行写代码，而是去设计系统、制定规则、管理整个循环。换个更形象的说法：人类负责建造杠杆，AI负责放大杠杆。而Harness Engineering的核心价值，就是用工程的方法，让概率性的AI系统在真实业务场景中做到可靠交付。

每天都有新名词冒出来，知识永远学不完，AI带来的焦虑也在蔓延。作为一个普通人，有时候或许确实该冷静想一想：在无休止追逐新技术之外，什么才是我真正需要的。

9. 参考资料

martinfowler.com/articles/ex...

openai.com/zh-Hans-CN/...

blog.langchain.com/improving-d...

developer.aliyun.com/article/171...

www.agent-engineering.dev/article/har...

blog.langchain.com/the-anatomy...