AI 应用技术演进 · 第 12 章

Harness Engineering 约束工程

走到这一章，演进序列来到了 2026 年的前沿。前十一章的共识是「模型越来越强，但不可靠」——提示词会跑偏、循环会失控、多 Agent 会协作失败。Harness Engineering（约束工程）不再纠结「换个更强的模…

约 8 分钟3,389 字1 个代码示例

走到这一章，演进序列来到了 2026 年的前沿。前十一章的共识是「模型越来越强，但不可靠」——提示词会跑偏、循环会失控、多 Agent 会协作失败。Harness Engineering（约束工程）不再纠结「换个更强的模型」，而是换了个思路：通过构建受控环境，让 Agent 在约束下高效可靠地完成长周期复杂任务。它包含围绕 Agent 构建约束机制、反馈回路、可靠上下文等一系列工程实践。如果说前面的技术是在「放大模型的能力」，Harness 是在「驾驭模型的可靠性」——这是 AI 应用技术从「能不能做」走向「能不能可靠交付」的分水岭。深度版见 Agent 核心 14 · 循环、图与骨架工程。

1. 演进脉络：从 Prompt 到 Harness 的范式跃迁

1.1 三次范式转移

AI 应用开发的「主战场」经历了三次转移：

Prompt Engineering  →  Context Engineering  →  Harness Engineering
  （输入怎么写）          （上下文怎么管）          （环境怎么建）
   2022-2023              2024-2025              2025-2026

每一次转移，都是「往模型外面多圈一层工程」：

Prompt 时代：只控制输入文本，其他都交给模型
Context 时代：控制整个上下文窗口（第 09 章）
Harness 时代：控制 Agent 的整个运行环境——不仅上下文，还有工具权限、流程约束、反馈回路、终止条件、审计日志

1.2 2026：OpenAI 正式命名

2026 年，OpenAI 在官方内容中正式提出并系统论述 Harness Engineering 的概念，核心主张：把 Agent 放进一个「受控的装置」（Harness）里——就像给赛车装引擎管理系统、给飞机装自动驾驶仪——用工程手段把「不可靠的模型」约束成「可靠的系统」。

文章里分享了一个常被引用的案例：OpenAI 内部通过人类监督智能体执行，用几周时间交付了一个约 100 万行代码的项目，其中绝大多数代码由 AI 编写。文中同时提出一个前瞻判断：未来要重新定义工程师的角色与「人-AI」协作方式——工程师不再逐行写代码，而是负责约束、供给上下文、验证与纠偏。

1.3 为什么是现在

两个现实推动：

模型能力已够用，可靠性是瓶颈：长周期任务的失败不再因为「模型不会」，而是因为「模型跑偏」——死循环、乱调用、上下文漂移
Agent 开始承担真实责任：从玩具到生产，Agent 开始操作真实系统（数据库、支付、发布）——失控的代价变得不可接受

2. 核心概念：Harness 的四个构件

Harness 不是一个单一技术，而是一组工程实践的集合，围绕四个构件展开：

2.1 约束机制（Constraints）

给 Agent 划定「不能越界」的边界：

工具白名单：只暴露任务必需的少量工具（每多一个工具，就多一分调用错误的可能）
权限分级：只读/可写/需确认的操作分级，敏感操作强制人工审批
输出协议：强制结构化输出、格式校验
预算上限：步数上限、token 上限、时间上限——终止条件是 Harness 的第一工程

2.2 反馈回路（Feedback Loops）

让 Agent 的运行「可被纠偏」：

人在回路（Human-in-the-Loop）：关键节点暂停，等待人工确认/修正
自动校验：工具结果的 schema 校验、断言检查，失败即中断
评测回环：定期用评测集检验输出质量，质量下滑即告警

2.3 可靠上下文（Reliable Context）

把第 09 章的上下文工程固化进运行时：

关键指令放首尾、防中段遗忘
长循环自动摘要/裁剪，防止上下文漂移
工具结果规范化后再注入，防止垃圾进窗口
打造 AI 友好的代码与环境：提高代码可读性、补全背景注释与架构说明——AI 和新人一样，面对「没有上下文的历史代码」同样会写错。人看不懂的代码，别指望 AI 看得懂

2.4 可观测性（Observability）

Harness 不是「看不见的黑盒」：

完整日志：每步思考、每次工具调用、每个上下文变更都可回溯
审计追踪：Agent 对真实世界的每次操作都有记录
断点恢复：长任务失败可从检查点恢复，而不是从头再来（与 LangGraph 的检查点机制呼应）

3. 关键认知：Harness 的本质

一个比喻： 给 Agent 造 Harness，就像给核反应堆造控制棒——不是让反应堆更「强」，而是让它更「可控」。强而可控，才是可交付的。

三个容易被误解的点：

Harness 不是限制模型能力，而是放大可交付能力：约束掉 20% 的自由度，换回 80% 的可靠性——对生产系统来说，这是巨大的净收益
Harness 与框架不是一回事：LangGraph 等框架提供的是「编排原语」（图、状态、检查点），Harness 是「围绕可靠性的完整工程哲学」——框架是实现手段，Harness 是设计目标
Harness 是渐进的：不是「非黑即白」——小任务一个终止条件就够，长周期任务才需要完整闭环。按任务的「失控代价」决定 Harness 的复杂度

4. 现状与趋势（2026）

「可靠性工程」成为 Agent 工程的核心话题：Harness 思想被主流框架吸收（检查点、人工审批、预算控制成为框架内置能力）
评测与护栏结合：从「上线后发现问题」到「上线前用评测集护栏拦截」——评测左移
Claude Code 源码研究热：社区通过研究 Claude Code 等生产级 Agent 的源码，学习「真实 Harness 长什么样」——这是 Harness Engineering 最好的教材

5. Harness vs Guardrails vs Framework：概念辨析

Harness 出现后，很容易和两个更早的概念混在一起，这里一次分清：

概念	作用范围	管什么	代表
Guardrails（护栏）	单次模型输出	输出合规：格式、敏感词、越权内容拦截	NeMo Guardrails、Llama Guard
Framework（框架）	编排原语	提供图、状态、检查点、中断等构建块	LangGraph、OpenAI Agent SDK
Harness（约束工程）	整个运行环境	约束、反馈回路、可靠上下文、可观测性——把护栏和框架组织成一个可靠系统	Claude Code、生产级 Agent

一句话区分：Guardrails 是「单次输出的闸门」，Framework 是「搭系统的积木」，Harness 是「让整个系统可靠运行的工程哲学」。框架帮你把系统搭起来，护栏帮你拦住坏输出，而 Harness 回答的是「这个系统凭什么能长时间、低失误、可审计地干活」。

三者不是取代关系：生产级 Agent = 框架（搭骨架）+ 护栏（守输出）+ Harness（保可靠）。