当 Agent 从“能演示”进入“能交付”，竞争焦点就会从模型能力转向工程控制能力。Harness Engineering 正是在这个阶段决定 Agent 是否能规模化落地的关键基础设施。

---

2026 年初，两件事几乎同时发生。

一是 OpenAI 发布了一篇名为 Harness Engineering: Leveraging Codex in an Agent-First World 的内部工程实验报告，披露了一个让人倒吸一口凉气的数据：3 名工程师，5 个月，零手动编码（Zero Hand-Written Code），产出约 100 万行代码，合并了 1500 个 PR。

二是 HashiCorp 创始人 Mitchell Hashimoto 发表了一篇文章，抛出一个观点：每一次 AI 应用，如果想要不止跑一次，就要围绕它建一套工程系统，让它能自动、反复、可靠地运行。 他把这套系统叫做 Harness。

这两件事指向同一个方向——当 AI 模型足够聪明的时候，瓶颈已经不在模型本身了。瓶颈在模型之外的那一整套环境。

一、什么是 Harness Engineering？

先给个直白的定义。

在 AI Agent 编程的世界里，有一个公式被广泛引用：

Agent = Model + Harness

Model 是模型——GPT-4o、Claude、Gemini，它们负责"想"。Harness 是模型之外的一切——代码、配置、工具链、执行环境、反馈回路和约束系统。它负责"做"。

打个比方：模型是一台马力强劲的发动机。但光有发动机，车跑不起来。你需要变速箱、底盘、方向盘、刹车系统——这一整套把你从 A 点送到 B 点的工程体系，就是 Harness。

Anthropic 官方文档里有一段话，把这个概念解释得很干净：

An agent harness (or scaffold) is the system that enables a model to act as an agent: it processes inputs, orchestrates tool calls, and returns results.

翻译过来：Harness 就是让一个"只会说话的模型"变成一个"能干活的智能体"的整套系统。它处理输入、编排工具调用、返回结果。

所以 Harness Engineering（驾驭工程），就是围绕 AI 模型，设计和构建这套"能让模型持续、可靠、安全地完成任务"的工程系统的学问。

注意这个词的微妙之处：它不叫"模型工程"，不叫"提示工程"，而是驾驭工程——核心关注点不是"让模型更聪明"，而是"如何驾驭一个已经足够聪明的模型"。

二、为什么是 2026 年？

这不是凭空冒出来的概念。过去三年，AI 编程领域经历了三次范式转移。

2023 年：Prompt Engineering 的黄金时代。 所有人都在研究怎么写好提示词——角色设定、思维链、少样本示例。那时候的观点是：模型能力有限，得靠精雕细琢的提示词来弥补。本质上，我们在"教一个不太聪明的学生考试技巧"。

2024 年：Context Engineering 崛起。 Andrej Karpathy 在 2025 年初提出了 Context Engineering 比 Prompt Engineering 更重要的论断。核心变化是：模型本身已经够聪明了，关键在于你给它喂什么上下文——代码仓库结构、系统提示、历史对话、工具描述。本质上，我们在"给一个聪明的学生提供好教材"。

2026 年：Harness Engineering 登场。 OpenAI、Anthropic 等巨头相继发布了关于 Harness Engineering 的专题文章。学术界也开始系统化研究。核心变化再进一步：不仅上下文要给对，工具要配好，执行环境、反馈回路、质量守卫、架构约束——整个系统都要为 Agent 的工作方式重新设计。 本质上，我们在"为天才建一整套研发基础设施"。

这三次转移有一条清晰的脉络：注意力从"怎么跟模型说话"→"给模型什么信息"→"为模型建什么系统"。 越往后越系统化、工程化。

2025 年是 Agent 从概念验证走向生产落地的关键年份。但真正让 Agent 在生产环境中"跑起来"而不是"偶尔灵验一下"，靠的就是 2026 年正在成型的 Harness Engineering 体系。

三、Harness 到底包含什么？

拆开来看，一个典型的 Agent Harness 通常包含五个核心层：

1 系统提示层——给 Agent 定岗位

这是最基础也最容易被低估的一层。好的系统提示不是一段文字，而是一份精确的"岗位说明书"：Agent 的角色、目标、权限边界、行为规范、决策优先级。OpenClaw 的 AGENTS.md 文件就是这一层的典型实现——它定义了 Agent 是谁、为谁服务、能做什么、不能做什么。

2 工具与技能层——给 Agent 配工具箱

模型本身只能"想"，不能"做"。工具层补上了这个缺口：文件读写、Bash 执行、浏览器操作、数据库查询、API 调用、Web 搜索。MCP（Model Context Protocol）是这一层的关键标准化协议，它让不同的工具能以统一的方式被 Agent 调用。

OpenAI 的实验有一个有趣的发现：他们更倾向于选择"无聊但 API 稳定"的技术栈，而不是"新潮但对 Agent 不友好"的技术。AI 友好性正在成为技术选型的新维度。

3 基础设施层——给 Agent 提供办公场地

包括文件系统、沙箱环境、容器化运行时、可观测性栈（日志、指标、追踪）。OpenAI 的实验中，团队为每个任务启动隔离的本地可观测性栈（Vector、Victoria Logs 等），Agent 可以通过 LogQL 查询日志、用 PromQL 查询指标，自主排查问题。

这一层解决的是安全和可扩展性问题——让 Agent 在一个被隔离、可观测、可复现的环境中工作。

4 编排逻辑层——给 Agent 设计工作流

子 Agent 调度、任务拆分与分发、模型路由（简单任务用便宜模型，复杂任务用强力模型）、会话管理、持久化状态。这是 Harness 的"神经系统"——它决定了多个 Agent 之间怎么协作、任务怎么流转、失败了怎么重试。

Claude Code 的 subagent 机制、OpenClaw 的 ACP（Agent Client Protocol），都是这一层的实现。

5 质量守卫层——给 Agent 当质检员

这是最容易被忽略但最关键的一层。包括：

• 上下文管理：压缩、卸载、技能延迟加载，防止 Agent 在长任务中"越用越笨"

• 自动化评审：Agent 自审 + 云端其他 Agent 交叉评审，模拟代码 Review 流程

• 架构约束执行：自定义 Linter 和结构测试，强制模块边界，防止代码库变成"大泥球"

• 垃圾回收机制：定期运行的"重构 Agent"，扫描并修复技术债务积累

OpenAI 把这种机制叫做 Ralph Wiggum Loop（智能体对智能体的评审循环），并且发现它的效果惊人——代码质量在持续运行中不降反升，因为每次"垃圾回收"都会把偏离标准的代码拉回正轨。

四、工程师的角色变了

这是 Harness Engineering 最深刻的影响：人类工程师不再写代码了。

不是"不能写"，而是"不需要写"。OpenAI 的实验强制要求零手动编码，结果工程师们发现，当不能写代码的时候，他们被迫把精力转向更有价值的事情——

设计 Harness 本身。

具体来说，工程师的新角色变成了：

传统模式	Harness 模式
写代码实现功能	写系统提示定义意图
手动调试 Bug	设计可观测性体系让 Agent 自查
做代码 Review	设计自动评审循环让 Agent 互审
管理架构规范	写 Linter 和结构测试强制约束
修技术债务	设计"垃圾回收 Agent"自动治理

OpenAI 技术团队成员 Ryan Lopopolo 的一句话总结得很到位："我们团队的主要工作变成了让智能体能够完成有用的工作。"

这不是裁员宣言，而是岗位升级。工程师从"搬砖的"变成了"设计搬砖系统的"。低级重复的编码工作确实会被取代，但系统设计、架构规划、Agent 行为调试——这些高级能力反而变得更稀缺、更有价值。

五、 Harness Engineering 的核心挑战

任何新技术都不只有光鲜的一面。Harness Engineering 目前面临的挑战同样真实：

上下文衰减：长任务中，上下文越来越长，模型表现越来越差。目前的方案是压缩、卸载和延迟加载，但这些手段都有信息损失的代价。

AI 废料积累：Agent 产出的代码中，会混入不良模式和不优实践。OpenAI 的方案是"垃圾回收 Agent"，但这需要持续投入算力和监控成本。

遗留系统改造难：Harness Engineering 在从零开始的项目上效果显著，但对于已经积累了大量技术债务的遗留代码库，改造成本可能远超收益。

安全边界难定：给 Agent 太多权限有风险，限制太多又影响效率。如何在自主性和安全性之间找到平衡，是每个团队都要面对的难题。

成本控制：Agent 反复运行、互相评审、自动修复，token 消耗可能指数级增长。没有精细的成本管控机制，很容易烧钱。

这些挑战不是"不可逾越的障碍"，而是"2026 年从业者需要实打实解决的问题"。谁解决了这些问题，谁就能在 AI 编程的新时代占据有利位置。

六、行动建议

如果你是一名后端开发者或 AI 应用开发者，以下是我认为最务实的行动路径：

第一步：理解 Agent 的工作方式。 不是泛泛地了解，而是实际使用 Claude Code、Codex、OpenClaw 等工具完成一个真实项目。感受它们哪里聪明、哪里犯傻、哪里需要人帮忙。

第二步：从改造自己的工作流开始。 不要一上来就想搞大系统。先从写好 AGENTS.md、设计好项目结构、配置好工具链这些"小 Harness"开始，逐步构建自己的 Agent 工作环境。

第三步：学习 Context Engineering。 搞清楚上下文窗口怎么管理、信息怎么压缩、工具描述怎么写。这是 Harness Engineering 的基本功。

第四步：建立反馈循环。 设计测试策略、可观测性体系和自动评审机制，让 Agent 的产出能被系统化地验证和修正。

第五步：关注 ACP 和 MCP 等协议。 Agent Client Protocol 和 Model Context Protocol 是正在标准化的基础设施。理解这些协议，有助于构建可互操作的 Agent 系统。

结语

回过头看这篇文章的标题：如果说 2025 年是 Agent 从"概念"走向"生产"的元年，那 2026 年很可能是 Harness Engineering 真正集中爆发成为主战场的一年。

这个判断基于一个朴素的观察：当模型能力不再是瓶颈的时候，瓶颈就在驾驭模型的能力上。

过去两年，所有人都在盯着模型——GPT-5 发布了没有、Claude 新版本强不强、Gemini 能力到哪了。这些当然重要。但从 2026 年开始，一个同样重要、甚至更重要的战场正在浮出水面：你怎么围绕这些模型，建一套足够好的工程系统？

Prompt Engineering 教我们怎么跟模型说话。Context Engineering 教我们给模型什么信息。Harness Engineering 教我们为模型建什么系统。