过去四年，AI 在编程领域的变化可以用“天翻地覆”来形容。

2022 年我们还在纠结：提示词到底要怎么写才不跑偏？到了 2026 年，很多团队的日常已经变成：把需求扔给一个 Agent 团队，让它自己规划、写代码、跑测试、做 UI 检查、提交 PR——你更多是在做“验收”和“约束设计”，而不是逐行敲代码。

这条路的核心转折点，其实不是“模型突然变聪明了”，而是我们终于承认了一件事：长链路软件开发靠的不是灵光一现，而是可重复的工程体系。当我们把这套体系搬到模型外面，就有了一个新名词：Harness Engineering（约束工程 / 马具工程）。[1]

你可以先记住一句最重要的话：

  • Agent = Model（模型） + Harness（马具）
  • 模型负责“想”，Harness 负责“牵引、约束、纠错、复盘”

下面我们用最通俗的方式把这件事讲清楚：它是怎么从 Prompt 演进到 Harness 的；为什么 2026 年大家都在聊它；以及如果你想落地一个“靠谱能交付”的 AI 开发流程，应该先做哪几件事。

AI 工程化的三层境界：从“把话说清楚”到“让它稳定交付”

如果把 2022–2026 的演进压缩成三句话，大概是这样：

  1. Prompt Engineering（提示词工程）：解决“怎么把话说清楚”。
    你在做的是：把模糊需求翻译成模型更容易命中的指令结构。

  2. Context Engineering（上下文工程）：解决“该给模型看什么”。
    你在做的是：把信息塞对时间、塞对位置，避免缺关键资料、也避免塞爆上下文；典型手段是 RAG 和记忆框架。[6]

  3. Harness Engineering（约束工程）：解决“怎么让模型稳定执行”。
    你在做的是：建立模型之外的流程、工具、状态与质量把关，让它在长任务里不跑偏、不瞎猜、能回滚、能复盘。

很多人会把前两层理解成“写提示词”和“喂资料”，但第三层的味道完全不一样：它更像软件工程里的工程管理与质量体系。

2022–2026：一条很清晰的时间线

把这四年拆开看，你会发现每一年都在补齐“Agent 缺的那条腿”。

2022–2023：简单提示词 + 单对话时代（Prompt Engineering 的高峰）

  • 2022-11-30：ChatGPT 发布，让“对话式编程”成为大众体验。
  • 你说 1–2 句自然语言，AI 给你一个看起来不错的代码片段；很多时候你复制、粘贴、改一改就能用。
  • 工具调用开始出现：AI 不再只会“说”，还开始会“做”。（比如写文件、跑命令、查资料、提交 Git）
  • 代表工具之一：Aider（终端内做增量改动、Git 结合紧密）。[7]

但这个阶段有个致命短板：一旦任务复杂，AI 很容易“忘事”。你会看到它前一段承诺 A，后一段又开始写 B；或者越改越乱，最后你只能手动收拾残局。

2024：Agentic 工具爆发，上下文开始“可管理”（过渡期）

  • Cursor IDE、Devin 等“能动手的工具”开始流行。
  • 上下文窗口变大、RAG 开始进入日常：你不用把所有材料手动贴给它，它会自己去索引、去检索、再回答。
  • 开源项目 OpenDevin / OpenHands 让更多人能实验自主 Agent。

这一年最关键的变化是：AI 开始有了“手”和“眼睛”——能改项目、能跑测试、能看报错，不再是“只会写答案的聊天机器人”。

但问题也暴露得更清楚：上下文越长，越容易出“长任务疲劳”。很多人形容它像“越聊越焦虑”，开始泛化、开始胡编，甚至为了结束对话而瞎给结论。

2025：Vibe Coding 与 Context Engineering 爆发

  • Vibe Coding 的核心主张很直白：你描述“想要的感觉和最终效果”，AI 帮你把大部分工作做完，甚至你可以一路 “Accept All”。（这个词在 2025 年被广泛传播）
  • 记忆框架、自动压缩、长期偏好开始进入工具标配，比如 mem0 这类项目在“长期记忆”方向提供了可复用的组件化思路。[5]

但这年也让更多人意识到：上下文工程能提升“想得更对”，但很难保证“做得更稳”。
尤其当任务跨多个小时、跨多个子系统时，真正把你搞崩的，往往不是模型不会写，而是它：

  • 一次改太多，无法回滚
  • 不按约定输出格式，状态丢失
  • 不跑测试就宣称完成
  • 遇到失败不会自救，开始循环尝试

2026：Harness Engineering 成熟，主流打法变成“系统设计”

到了 2026 年，行业开始用更系统的方式把“长任务怎么做”讲清楚。

  • Anthropic 在工程实践里系统讨论长运行 Agent 的 harness 设计与复盘机制。[2]
  • 进一步提出面向长链路应用开发的 harness 设计要点：用结构化文件传递状态、用真实交互做评估、用角色分离降低互相污染。[1]
  • Claude Opus 4.6 与团队协作等能力发布，也把“多实例并行 + 明确分工”的产品形态推到台前。[4]

如果你只记住 2026 年的一条共识，那就是：把“可靠性”从模型里拿出来，放到系统里做。

Harness Engineering 到底是什么？一句话讲明白

Harness 原意是“马具”。放在 AI 这里，它指的是：模型之外的所有工程化支撑体系。

你可以把它想成一套“防跑偏装置”，包括但不限于：

  • 边界：你是谁、你能做什么、你不能做什么、成功标准是什么
  • 工具：你可以调用哪些能力（文件、终端、浏览器、数据库），以及怎么用才算合规
  • 流程：你必须按什么步骤做事（先理解→再检索→再实现→自检→修正）
  • 状态：任务清单、里程碑、变更记录、已知风险，都不能只靠聊天记忆
  • 评估：不能自己写完自己说“OK”，要有独立的检查（测试、lint、e2e、截图对比）
  • 恢复：超时、死循环、格式错、测试红了怎么办，是否回滚、是否重试、是否换路径

一句话：模型负责出主意，Harness 负责让它像团队一样交付。

一个成熟 Harness 系统，通常会补齐这六层

你可以用这六层当作“自查清单”。如果你的 Agent 经常成功率卡在 60%–80%，一般不是模型不行，而是其中某一层是空的。

  1. 信息边界层：角色、输入去噪、成功标准与验收口径。
  2. 工具系统层：可用工具清单、调用时机、返回结果的提炼规则。
  3. 执行编排层：SOP（理解→检索→实现→自检→修正），以及每步的输出格式。
  4. 记忆与状态层：短期对话 vs 中间产物 vs 长期偏好，分别怎么保存、怎么传递。
  5. 评估与观测层：独立 QA、日志与指标、失败原因归因。
  6. 约束与恢复层（最核心）：超时/死循环/重复尝试/输出漂移/回滚与重试策略。

Anthropic 的顶尖实践：为什么“角色分离 + 状态外置”这么关键

很多人第一次听 Harness，会误以为是“更复杂的 Prompt”。但 Anthropic 的实践恰恰相反：Prompt 可以很短，关键是系统要稳。

上下文重置：别指望一段对话能扛完整个项目

当任务变长后，最常见的崩坏是“对话历史污染”：
早期的错误判断、临时的妥协方案、甚至一句随口的假设，会在后续不断被模型当成事实沿用。

一个很实用的策略是 Context Reset：
需要继续做事时，直接开启一个干净的新 Agent，只把必要状态通过结构化文件交接（例如 spec.md、contract.md、tasks.json、Git diff）。[1]

这听起来“反直觉”，但效果往往非常好：你不是让它“努力记住”，而是让它只看单一事实来源。

Planner / Generator / Evaluator：把“会写”和“会验收”拆开

另一个关键点是角色彻底分离（经典三代理架构）：

  • Planner（规划器）：把 1–4 句需求扩展成可执行规格（范围、边界、验收、里程碑）。
  • Generator（生成器）：专注实现代码，按规格推进。
  • Evaluator（评估器）：像 QA 一样验证，不参与“写”，只负责“挑错”和“给可操作反馈”。

它的直觉很朴素：让“写代码的人”自己验收，天然会放水。
你把验收独立出来，质量就会更稳定。

一些实践里还会用真实交互（例如 Playwright）去验证 UI 流程，而不是只看代码“像是对的”。[1]

三个可落地的小案例：把 Harness 从概念变成流程

下面这三件事，你不需要换模型也能做；但做完之后，长任务成功率通常会明显上升。

案例 1：用 “Sprint Contract” 把需求变成可验收的合同

很多失败不是因为 AI 不会写，而是因为“需求在对话里不断漂移”。
一个简单的做法是：在每个 sprint 开始前，要求 Planner 输出一份短合同，包含范围、非目标、验收标准和风险。

你可以让它生成一个 contract.md，格式类似这样（示意）：

  • 目标：本轮要交付什么（可演示、可测试）
  • 非目标：明确这轮不做什么，避免“顺手加功能”
  • 验收：至少 3 条可检查标准（测试通过、某页面能走通、日志无错误等）
  • 风险：已知不确定点与备选方案

合同不是形式主义，它的价值是：给 Evaluator 一个稳定的“打分依据”，也给 Generator 一个稳定的“边界”。

案例 2：把“状态”从对话里挪出来，用文件当单一事实来源

如果你只让 Agent 在聊天里维护 TODO 列表，你很快会遇到：

  • 列表被覆盖、被重写、被遗忘
  • 做过的事反复做
  • “我以为你说过了”式误会

更稳的方式是：让它维护一个外部文件，比如 tasks.json 或 TASKS.md，并规定：

  • 每次开始工作先读取它
  • 每次完成/失败必须更新它
  • 任何“完成”必须附上证据（测试命令输出、截图、链接、diff）

这就是 Harness 的核心味道：别让重要状态只存在于语言模型的概率云里。

案例 3：引入“独立评估”，禁止“未验证的完成宣告”

最能拉开差距的一条约束是：
Generator 不允许说“完成了”，只能说“我做了哪些变更、下一步请 Evaluator 验收”。

Evaluator 的检查可以从轻到重：

  • 轻量：lint、单测、构建、静态检查
  • 中等：跑 e2e、检查关键页面、验证配置文件
  • 重量：用 Playwright 真实点击流程、截图对比、检查网络请求与错误日志

当你把“完成宣告权”从生成器手里收回来，很多“看起来能用”的半成品就不会混进主分支。

这套演进对开发者意味着什么？

写到这里，你会发现一个很现实的变化：未来更值钱的能力，不是“更会写提示词”，而是：

  • 能不能把需求变成可验收的合同
  • 能不能把状态管理做成单一事实来源
  • 能不能设计出“写”和“验收”的分离机制
  • 能不能把失败变成可复盘、可恢复的流程

换句话说：你在从“写代码的人”变成“设计交付系统的人”。

核心要点

  • Prompt 工程解决“说清楚”，Context 工程解决“给对信息”，Harness 工程解决“稳定交付”。
  • 2026 年的主流经验是：不要把可靠性交给模型的自觉，把它做进系统里。
  • Harness 的关键不在“更长的提示词”，而在 边界 + 工具 + 流程 + 状态外置 + 独立评估 + 失败恢复。
  • 真正能提升长任务成功率的，往往是三件小事：sprint contract、单一事实来源、独立 evaluator。

引用来源

〔注1〕Anthropic 提出的长运行应用开发 Harness 设计要点与三代理思路：Harness design for long-running application development

〔注2〕Anthropic 更早的长运行 Agent harness 实践文章：Effective harnesses for long-running agents

〔注3〕视频学习笔记来源（理解“马具工程”直觉很有帮助）：最近爆火的 Harness Engineering 到底是个啥？一期讲透！

〔注4〕Claude Opus 4.6 发布信息（作为 2026 年产品形态背景参考）：Introducing Claude Opus 4.6

〔注5〕长期记忆框架 mem0（Context Engineering 方向的代表之一）：mem0 GitHub Repo

〔注6〕RAG 基本概念（检索增强生成）：Wikipedia：检索增强生成

〔注7〕Aider（终端 AI 编码助手，强调 Git 增量改动）：Aider GitHub Repo