🤖 AI 编程进化史：从提示词、上下文工程到 Harness

同等能力的模型越来越多，各家产品的体验差距反而越拉越大。有的产品写出来的代码可以直接提交上线，有的产品写出来的却难以维护——为什么？ 因为模型是一样的，差距在于怎么用模型，怎么稳定地用模型。 在 AI 行业里，这就叫 Harness Engineering（驾驭工程）。

🧠 Harness 工程：把 Agent 拆成三层

我们将编程 Agent 划分为三个层次：

Scaffolding（脚手架） 负责 AI 任务执行前的所有准备工作，包括系统准备的工具。
Harness（运行时编排，核心） 整个智能体的核心调度中心。负责管控 AI 的核心推理循环，协调工具调用、上下文管理、运行安全管控和会话数据的持久化存储。
Context Engineering（上下文工程） 负责管理大模型处理文本的最小计算单位——token 的资源分配。决定 AI 运行过程中，哪些信息需要保留，哪些信息应当丢弃。

一个稳定干活的 AI 代码智能体 = 所调用的一个或多个大模型 + 一套完善的 Harness 系统。

核心关注点：怎么去写好一个指令。

单条 prompt 已经不够用了——需要为模型动态构建整个上下文环境。让模型在做每一个决策时，都能精确看到它所需要的全部信息：任务文件、历史对话、工具规则、知识库条目……

核心理念：给模型看它该看的，挡住它不该看的。

每当你发现 Agent 犯了一个错误，你就花时间去工程化地解决它，让它不会犯相同的错误。

模型的能力够了，但它就是不听话，怎么办？ 答案就是——Harness Engineering。

真实案例：

Agent 不难，Harness 才难。

1. 试图一步到位 在一个窗口里想把所有功能都做完，结果就是上下文窗口迅速耗尽，后半段的质量断崖式下跌。

2. 过早宣布胜利 复杂项目开发后期，AI 智能体完成了核心功能、有了可见产出，就直接判定任务完成而主动终止——哪怕大量功能还没实现，核心需求尚未满足，依然会停止。

3. 过早标记功能完成 AI 智能体只要写完了某个功能，就会将其标记为已完成。它不会主动做端到端的完整功能测试，也不会验证这个功能在真实环境中到底能不能用。看起来能跑，实际上到处是隐藏的 bug。

4. 机械复制代码模式 AI 会机械地沿用已有的代码模式（架构风格、编写规范），哪怕这个模式是错误的，并在整个项目里持续放大。不加约束的 AI 智能体，会以极快的速度在项目中积累大量技术债务。

AGENTS.MD 文件越长、信息越冗余，Agent 任务成功率就越低，推理成本却越高。 AGENTS.MD 文件应严格控制在 60 行以内。

上下文是稀缺资源，过多的指导会挤掉真正重要的任务代码。

实行严格的分层架构——不是用 prompt 告诉 agent"请遵守架构"，而是用确定性的 Linter 和结构化测试来机械执行。

在 Linter 报错信息里直接嵌入修复指引，告诉 agent 应该怎么改。约束比指令更有效。

在 Harness 里，代码审查变成 Agent 对 Agent 的方式。形成标准化闭环：规划与发现 → 构建 → 验证 → 修复，循环往复，持续提纯代码质量。

随着时间推移，AI 生成代码会积累大量问题：文档过时、架构漂移、风格走样、死代码堆积…… 让 Agent 为 Agent 维护文档，持续对抗熵增，防止项目腐化。

AI 编程的进化，本质上是一场从"写好提示词"到"构建好系统"的范式转移。

三条线不是替代关系，而是叠加递进——每一层都建立在上一层的基础之上。真正能稳定产出高质量代码的 AI 编程产品，必定在这三个层次上都下了硬功夫。