约束工程：2026 年每位 AI 工程师都需要知道的事

2026 年 2 月，OpenAI 的一个小团队交付了 100 万行生产代码。

他们没有手动编写一行代码。

AI 智能体编写了所有代码。

人类设计了让这些智能体变得可靠的系统。

这个系统现在有了名字。

约束工程 (Harness Engineering)。

几周内，Anthropic 发表了 3 篇相关论文。

ThoughtWorks 将其形式化为一个框架。

Hugging Face 的 Philipp Schmid 称其为“2026 年最重要的学科”。

一个新工程学科在 90 天内诞生了。

而除了 AI 基础设施团队，几乎还没有人理解它。

本文解释一切。

没有废话。没有学术术语。只有你真正需要的心智模型。

保存本文。你会读两遍。

第一部分：HARNESS 实际上是什么（改变你对 AI 看法的概念）

1. Harness 定义

最简洁的定义来自 ThoughtWorks：

→ 智能体 (Agent) = 模型 (Model) + 约束框架 (Harness)

约束框架就是模型之外的所有东西。

让智能体保持正轨的约束。捕捉错误的反馈回路。告诉智能体自身位置的文档。它被允许使用的工具。

剥离约束框架 → 原始语言模型在你的代码库中瞎猜。

加上正确的约束框架 → 能交付生产代码的系统。

这个名字来自马具。

约束框架就像是缰绳、鞍具和马嚼子，将一匹强大但不可预测的动物引导到有用的方向。

你不是让马更聪明。你设计了装备，让它的力量变得有用。

2. 操作系统类比

Philipp Schmid 给出了最佳技术框架：

将其视为一台计算机。

→ 模型 = CPU（原始处理能力）

→ 上下文窗口 = RAM（有限、易失的短期记忆）

→ 约束框架 = 操作系统（管理 CPU 看到什么以及何时看到）

→ 智能体 = 运行在顶层的应用程序

你的模型很强大。

但如果没有操作系统来管理内存、调度任务、强制执行规则——它只是硅片。

大多数人都在运行没有操作系统的应用程序。

这就是他们的智能体在生产中失败的原因。

3. 2026 年发生了什么变化

LangChain 在 Terminal Bench 2.0 上运行了同一个模型两次。

相同的模型。不同的约束框架。

→ 旧约束框架：52.8% 得分

→ 新约束框架：66.5% 得分

Vercel 走了相反的方向。

他们移除了智能体 80% 的工具。

结果？性能更好了。

而不是更差。

2026 年令人不安的真相：

→ 智能体从来不是难点。

→ 约束框架才是。

如果说 2025 年是 AI 智能体证明自己能写代码的一年……

那么 2026 年就是我们发现环境比模型更重要的一年。

第二部分：5 个 HARNESS 制品（实践中约束框架长什么样）

4. AGENT.md / CLAUDE.md 文件

最通用的约束框架制品。

分布在代码库中的 Markdown 文件。

智能体在每次会话开始时读取它们——就像新工程师加入团队时的入职文档。

里面包含什么：

→ 项目上下文

→ 编码规范

→ 架构决策

→ “我们这里怎么做”的指引

→ 当前正在进行的任务

OpenAI 称其为 AGENT.md。

Anthropic 称其为 CLAUDE.md。

Cursor 使用 .cursorrules。

名称不同。原理相同。

每个主要模块一个文件。随着项目演进而更新。

没有它们：智能体每次会话都从零开始，一无所知。有了它们：智能体每次会话都信息充分，立即进入状态。

5. JSON 功能列表（进度追踪器）

当智能体跨多次会话构建整个应用时，它每次会话开始时上下文窗口都是空的。

它怎么知道哪些已经完成了？

一个 JSON 文件。

每个条目定义：

→ 一个功能

→ 如何验证它工作正常

→ 通过 / 失败状态

智能体在会话开始时读取这个列表。挑选最高优先级的失败功能。实现它。标记为通过。提交。重复。

为什么是 JSON 而不是 Markdown？

Anthropic 发现智能体意外覆盖 JSON 的可能性比覆盖 Markdown 低。

小细节。在 6 小时的自主运行中意义重大。

6. 会话初始化例程

每次会话都以相同方式开始。

每。一。次。

Anthropic 的 7 步启动序列：

• 确认工作目录

• 读取 git 日志和进度文件

• 检查功能列表，找到最高优先级的未完成项

• 启动开发服务器

• 运行基本的端到端验证

• 实现一个功能

• 提交并附带描述性信息 + 更新进度

没有这个：

智能体浪费前 20 分钟弄清楚已经存在什么。

每次会话都在重新发明轮子。

有了它：

智能体立即信息充分，直接进入工作状态。

7. Sprint 契约

在智能体写一行代码之前：

两个智能体进行协商。

生成器智能体提出：

→ 它将构建什么

→ 如何验证成功

评估器智能体审查：

→ 提案是否完整？

→ 成功标准是否明确？

只有双方都同意后，实现才开始。

这是一场设计评审。

只是两个参与者都是 AI。

为什么这很重要？

在同一轮中进行计划和执行的智能体会产生不可靠的输出。

计划步骤——即使由 AI 完成——也能显著提高输出质量。

8. 结构化任务模板

在任何编码之前：

约束框架分析真实的代码库。

它生成一个基于实际的影响地图：

→ 真实文件路径（不是幻觉路径）

→ 真实存在的符号名称

→ 要遵循的现有模式

→ 具体的验收标准

然后实现开始。

这听起来显而易见。

但大多数团队跳过了这一步。

智能体猜测文件结构。发明不存在的 API 端点。构建不适合代码库的东西。

执行前有了基于实际的上下文 → 输出质量大幅提升。

第三部分：三大阵营（三个团队撞上同一堵墙——建造了三架不同的梯子）

9. OpenAI：环境优先

OpenAI 的 Codex 团队遇到了一个荒谬的问题。

100 万行生产代码。零行手动编写。

在这种规模下，你无法逐行审查代码。

所以他们不审查。

取而代之：

他们如此彻底地设计了环境，以至于智能体从一开始就能产出可审查的输出。

他们的方法：

→ 严格的依赖流向（类型 → 配置 → 仓库 → 服务 → 运行时 → UI）

→ 代码库中遍布 AGENT.md 文件

→ 智能体直接接入 CI/CD 管道

哲学：设计环境。然后让智能体自由发挥。

证明：Sora Android 应用。4 名工程师。28 天。Play Store 第 1 名。99.9% 无崩溃率。

Codex 处理了每周 70% 的内部拉取请求。

10. Anthropic：将执行者与评判者分离

Anthropic 遇到了不同的问题。

当他们要求智能体评估自己的输出时：

它会自信地称赞自己的工作。

即使对人类观察者来说，质量显然平庸。

自我评估不起作用。

智能体既是学生又是老师。

而且它在给自己打全优。

他们的修复方案：三个专门的智能体。

→ 规划者 (Planner) — 将 2 句话提示转化为完整产品规格

→ 生成器 (Generator) — 每次 sprint 实现一个功能

→ 评估器 (Evaluator) — 使用浏览器自动化像真实用户一样测试运行中的应用

关键洞察：让一个独立的评估者变得怀疑，远比让生成者批评自己的工作容易得多。

结果：单一智能体（无约束框架）：9 美元，20 分钟 → 有问题的应用；完整约束框架：200 美元，6 小时 → 可工作的软件，精美的 UI，正确的物理模拟

11. ThoughtWorks：2×2 框架

ThoughtWorks 从不同角度切入。

他们不是在构建产品。

他们在观察 50 多个工程团队在同样的事情上失败。

他们的洞察：根据两个轴对每个约束框架控件进行分类。

轴 1： 何时运行？

→ 前馈 (Feedforward) = 在智能体行动之前（引导）

→ 反馈 (Feedback) = 在智能体行动之后（传感器）

轴 2： 如何工作？

→ 计算型 (Computational) = 确定性，毫秒级（linter、类型检查器、测试套件）

→ 推理型 (Inferential) = 使用 LLM，秒级（代码审查智能体、语义分析）

2×2 矩阵：

→ 计算型前馈：类型系统、linter、架构规则

→ 计算型反馈：测试套件、覆盖率分析、突变测试

→ 推理型前馈：规格文档、约束描述

→ 推理型反馈：LLM 代码审查者、行为验证器

仅有前馈或仅有反馈都不行。

两者都需要。

第四部分：每个阵营都认同的 5 条原则（三个团队从未协调，独立得出了相同的结论）

12. 原则 1：上下文优于指令

OpenAI：“给地图，而不是一千页的说明书。”

Anthropic：JSON 功能列表和进度文件，让智能体始终知道自己的位置。

Red Hat：在生成任何任务之前分析真实代码库。

ThoughtWorks：“前馈。”

不同措辞。相同发现。

向智能体展示世界的当前状态，始终优于抽象地告诉它该做什么。

→ 基于真实文件路径 → 适合代码库的代码

→ 基于模糊描述工作 → 幻觉的文件路径和发明出来的 API

教训：在智能体输入任何内容之前，确保它确切知道自己的位置。

13. 原则 2：计划和执行必须分离

OpenAI：人类设计环境，智能体执行。

Anthropic：专用规划者智能体在生成器接触任何代码之前运行。

ThoughtWorks：在计划和实现之间设置强制性的人工审查检查点。

Red Hat：阶段 1（影响地图）和阶段 2（实现）之间有硬性关口。

每个阵营独立发现了这一点：

让智能体在同一轮中计划和执行会产生不可靠的输出。

计划步骤不一定由人类完成。

但它必须是一个独立的步骤，其输出在实现开始前被审查。

14. 原则 3：反馈回路是强制性的

OpenAI：智能体接入 CI/CD 和可观测性系统。

Anthropic：使用浏览器自动化的专用评估器智能体。

ThoughtWorks：形式化为“传感器”。警告仅前馈的方法永远无法确认引导是否实际有效。

同一条原则的三种方法：

→ OpenAI 使用自动化测试和 CI

→ Anthropic 使用另一个 LLM

→ ThoughtWorks 表示应两者结合、分层使用

他们在谁提供反馈上意见不一。

但在是否需要反馈上意见一致。

没有反馈的约束框架只是带额外步骤的提示词。

15. 原则 4：一次只做一件事

OpenAI：将目标分解为更小的构建块，深度优先工作。

Anthropic：强制每个 sprint 一个功能，每次提交后推进。

ThoughtWorks：分阶段生命周期（预集成 → 后集成 → 持续监控）。

试图一次做太多事情的智能体：

→ 上下文用尽

→ 失去连贯性

→ 静默丢弃需求

Anthropic 的例程：

读取进度 → 选择一个功能 → 实现 → 提交 → 重复

每个成功的约束框架都强制递增式工作。

16. 原则 5：代码库就是文档

OpenAI：在仓库中嵌入 AGENT.md 文件。

Anthropic：将功能列表、进度文件和 git 历史作为智能体的连续性机制。

ThoughtWorks：衡量“可约束性 (harnessability)”——代码库对智能体的可读性。

没有人维护单独的智能体知识库。

仓库是唯一真实来源。

如果某个约定、约束或架构决策不在代码库中——智能体就不会知道。

实际意义：

→ 投资于代码组织的团队能免费获得更好的智能体性能

→ 混乱的仓库 + AI 智能体 = 混乱，但以规模化的方式

第五部分：悖论——为删除而构建（约束工程中最反直觉的真相）

17. 约束框架衰减是真实存在的

当 Anthropic 从 Opus 4.5 升级到 Opus 4.6 时：

Sprint 分解——之前是必不可少的——变成了负担。

模型改进后的规划能力使其冗余。

三月份还是承重构件的约束框架组件，到了四月份就成了开销。

然后 Opus 4.7 来了。

模型开始验证自己的输出。

评估器智能体的职责描述开始缩小。

这就是约束框架衰减 (Harness Decay)。

约束框架中的每个组件都编码了一个关于模型不能做什么的假设。

随着模型改进 → 这些假设过期 → 该组件变成开销。

Opus 4.5：sprint 分解 + 每次 sprint 评估

Opus 4.6：无 sprint 分解 + 单次评估（节省 38% 成本）

Opus 4.7：模型开始自我验证 → 评估器角色进一步缩小

18. 为删除而构建

Philipp Schmid 的建议：

“为删除而构建。”

设计每个约束框架组件都可移除。

定期测试每个组件：关闭它，测量输出质量是否变化。

如果没有变化：删除它。

Manus 在 6 个月内重构了 5 次约束框架。LangChain 在 1 年内重构了 3 次。Vercel 移除了 80% 的工具 → 获得了更好的性能。

这些不是糟糕工程的标志。

它们是在快速改进的模型之上构建的自然结果。

携带已死的约束框架组件会在每次运行中消耗 token。零额外质量。纯粹浪费。

19. 成本现实

来自 Anthropic A/B 测试的真实数据：

→ 单一智能体（无约束框架）：9 美元，20 分钟 → 可工作的 UI，核心功能有缺陷

→ 完整约束框架（Opus 4.5）：200 美元，6 小时 → 可工作的软件，精美 UI，正确的物理模拟

成本增加了 22 倍。

对于一个功能产品 vs 一个只在截图中看起来正确的演示。

这是昂贵还是便宜，完全取决于一个带有缺陷的发布对你的团队意味着什么。

但没人谈论的是：

约束框架 + 模型的组合在进化。

一次模型升级就将 200 美元的约束框架降到了 124 美元。

趋势线：

→ 更好的模型 = 更简单的约束框架 = 更廉价的运行 = 更快的输出

2026 年获胜的工程师不是在写最好的代码。

他们在设计最好的约束。

并且愿意在它们不再发挥作用的那一刻丢弃这些约束。

结语

你刚刚学到的一切：

什么是约束框架：

→ 1. 智能体 = 模型 + 约束框架

→ 2. 模型 = CPU。约束框架 = 操作系统。

→ 3. 相同模型，更好的约束框架 = +13% 性能

5 个约束框架制品：

→ 4. CLAUDE.md / AGENT.md — 智能体的入职文档

→ 5. JSON 功能列表 — 进度追踪器 + 测试套件合二为一

→ 6. 会话初始化例程 — 每次相同的 7 步启动

→ 7. Sprint 契约 — 编码前智能体协商

→ 8. 结构化任务模板 — 真实文件路径，真实模式

三大阵营：

→ 9. OpenAI：设计环境，让智能体自由发挥

→ 10. Anthropic：将执行者与评判者分离

→ 11. ThoughtWorks：2×2 前馈/反馈框架

5 条通用原则：

→ 12. 上下文优于指令

→ 13. 计划和执行必须分离

→ 14. 反馈回路是强制性的

→ 15. 一次只做一件事

→ 16. 代码库就是文档

悖论：

→ 17. 约束框架衰减 — 上个月有效的，这个月成了负担

→ 18. 为删除而构建 — 测试并移除已死的组件

→ 19. 成本现实 — 更好的模型 = 更简单的约束框架 = 更廉价的运行

2026 年获胜的工程师不是在写最好的代码。

他们在设计最好的约束。

并且愿意在它们不再发挥作用的那一刻丢弃这些约束。

如果本文对你有帮助：

→ 转发以触达你网络中的构建者

→ 关注 @sairahul1 获取更多类似内容（每周更新）

→ 收藏本文——当你的智能体开始出问题时，你会回来参考的

我写关于 AI、产品构建以及 2026 年实际有效的内容。