芯耀
与非AI
493
2025 年 11 月底，Anthropic 工程团队公开了一份内部实验报告：他们让 Claude Code 在一个高级指令下"克隆 claude.ai"。结果颇为戏剧，即便是 Opus 4.5 这样的前沿模型，单凭一句高级 prompt，也无法稳定地完成这个项目。
Agent 会试图一次性写完整个应用，半路上下文窗口耗尽，下一个 session 接手时只能对着半成品抓瞎；又或者在做完几个功能后，"自我感觉良好"地宣布任务完成，留下一堆未实现的需求。
几乎同一时间，OpenAI 发布了另一份更轰动的实验报告：三名工程师用 5 个月时间，没有手写一行源代码，纯靠 AI Agent（Codex）构建出一个包含超过 100 万行代码的 Beta 产品。
同样是顶尖模型，同样是 Agent，结果却天差地别。差在哪？答案就是 OpenAI 那份报告标题里的那个新词：Harness Engineering（缰绳工程 / 驾驭工程）。
短短一个月内，这个词从一篇博客文章变成了全球开发者社区的高频词，Martin Fowler、Mitchell Hashimoto、Addy Osmani 等业内大佬纷纷下场撰文。今天，我们就来彻底拆解这个正在重塑 AI 工程范式的新概念。
什么是 Harness Engineering？
从一个公式开始
要理解 Harness Engineering，先记住这个被广泛引用的公式：Agent = Model + Harness
这句话是 Mitchell Hashimoto 在 2026 年初提出的。它的潜台词是：一个 AI Agent，从来都不只是一个模型。模型提供推理能力，而 Harness 提供让模型可靠运行的所有规则、约束、上下文与验证机制。
"Harness" 这个词原本指马具：缰绳、马鞍、嚼子、辔头。骑手用它来引导一匹强壮但桀骜的马，让它的力量朝着有用的方向释放，而不是脱缰狂奔。在软件工程里，"test harness"指的是测试脚手架；而在 AI 工程里，Harness 指的是模型之外的一切：上下文组装、工具编排、验证循环、成本控制、可观测性、错误恢复——所有这些围绕模型构建的基础设施。
如果用计算机系统来类比就更清楚了：
模型 = CPU（提供计算/推理能力）
上下文窗口 = 内存（临时存储）
Harness= 操作系统（调度、I/O、内存管理、异常处理）
Agent= 应用程序（最终交付给用户的形态）
你不会让软件直接跑在裸 CPU 上，同样地，你也不该让 Agent 在没有 Harness 的情况下投入生产。
三层工程范式的演进
从 ChatGPT 引爆大模型应用以来，AI 工程经历了三个清晰的阶段：
第一阶段：Prompt Engineering（提示词工程）关注"说什么"。怎么把一句话写得更精准、更结构化，让模型理解我们的意图。这是 2023 年的主旋律。
第二阶段：Context Engineering（上下文工程）关注"给什么"。不只是 prompt，还要把代码库、文档、历史对话、动态数据组织成模型能消化的形式。RAG、向量数据库、记忆系统都属于这一层。这是 2024–2025 年的主线。
第三阶段：Harness Engineering（驾驭工程）关注"在什么条件下运行"。它包含前两者，但站得更高——它关心的是让 Agent 持续、稳定、高质量地完成长周期工作的整套控制系统。这是 2026 年正在发生的事。
打个比喻：Prompt Engineering 是给员工写一个清晰的任务说明，Context Engineering 是给他配一本厚厚的资料手册，而 Harness Engineering 是给他建一整间办公室——有打卡机、有同事评审、有 git 仓库、有自动化测试、有出错时能回滚的时间机器。
Agent 为什么会"翻车"？Harness 要解决什么问题？
要理解 Harness 的必要性，得先看清没有它时 Agent 会以什么方式失败。Anthropic 在那次 claude.ai 克隆实验中观察到的两种典型失败模式很有代表性：
失败模式一：贪多嚼不烂Agent 看到 prompt 后试图一次性把整个应用写完，结果上下文窗口在实现到一半时耗尽。下一个 session 启动时，前一个 session 留下的是一堆半成品——文件零散、注释缺失、状态不清。新 session 只能花大量 token 去"猜"前任做到哪儿了。
失败模式二：自我感觉良好项目跑了一阵子后，新的 Agent 实例进来一看："好像功能都有了嘛？"，于是宣布项目完成。但其实需求清单里还有几十项没实现，它根本不知道完整的需求边界在哪。
除此之外，业界还总结出几类高频问题：
上下文焦虑：长任务中模型性能会随着上下文堆积而下降；
失忆症：跨 session 没有记忆，每次新会话都"重启大脑"；
工具滥用：给 Agent 配了 40 个工具，它反而陷入选择困难；
多 Agent 死循环：A 把任务委托给 B，B 又委托回 A；
破坏性操作：Agent 一时兴起跑了个
rm -rf，数据就没了。
这些问题，没有一个能靠"换个更聪明的模型"来解决。它们全都是系统层面的问题，而 Harness 就是这套系统。
Harness 的核心组件：五大支柱
综合 Anthropic、OpenAI、Martin Fowler、Addy Osmani 等多方的论述，一个完整的 Harness 通常包含五大组件：
上下文组装：Agent 看到的每一个 token 都是经过精心组装的。这不只是把文档塞进 prompt 那么简单，而是：
静态上下文：项目级的规则（OpenAI 推崇的
AGENTS.md 文件就是典型代表）；
动态上下文：当前任务相关的代码片段、最近的 git 日志、错误堆栈；
渐进式披露（Progressive Disclosure）：不要一次性灌入 1000 页说明书，而是让 Agent 按需深入到具体子目录获取局部上下文。
OpenAI 在那个百万行代码项目中，散布了 88 个 AGENTS.md 文件——根目录定义全局规则，子目录覆盖局部约定。这就是分层上下文的实战范例。
工具编排：
工具不是越多越好。Harness 要做的是根据任务状态约束可用工具集。一个查询任务不需要 git push 权限，一个总结任务不需要 bash 执行权限。Anthropic 的 Skill 系统（后来成为开放标准，Codex、OpenCode 也支持）就是这种思路的体现——技能按需加载，而不是塞进系统 prompt。
3.3 验证与反馈循环（Verification & Feedback）
Martin Fowler 总结了一套被广泛接受的"指南与传感器"（Guides and Sensors）框架：
Guides（指南） = 前馈控制，告诉 Agent 该做什么（AGENTS.md、约束文件、上下文管道）；
Sensors（传感器）= 反馈控制，检查 Agent 做得对不对（测试、Linter、CI、LLM-as-Judge）。
传感器又分两类：
计算型：跑测试、跑 Linter，确定性高、速度快、便宜，每次改动都能跑；
推理型：语义分析、AI 代码审查、"LLM 作为评委"，更慢更贵、非确定性，但能做语义判断。
3.4 状态管理与记忆外化（State Management）
这是 Anthropic 解决得最漂亮的一块。既然模型有上下文窗口的限制，那就把记忆放到模型脑子外面去：
claude-progress.txt：进度日志，每个 session 结束前更新，下一个 session 开始时第一件事就是读它；
Git 历史：每次改动都 commit，错了直接
git revert回滚到干净状态；
特性清单文件（feature_list.json）：把需求结构化成 JSON，每条带
passes: false/true 标记，Agent 只能改状态字段，不能删除测试项。
每个 session 启动时，Agent 都要走一套"开机仪式"：跑 pwd 确认目录 → 读 git log 看最近改动 → 读 progress.txt 看接下来该做什么 → 跑 init.sh 启动开发服务器并做一次基础端到端测试。这就像工厂换班时，下一班工人先翻交接簿。
人机协作与安全门：
完全自主很少是合适的。Harness 要设计：
审批门："Agent 想跑
rm -rf，是否批准？"
定期复核：长任务的进度检查点；
沙箱隔离：在容器里跑、在 worktree 里改、限制网络访问。
目标不是让人类微观管理 Agent，而是把人的判断力放在杠杆最高的决策点上。
真实世界的应用示例
光讲理论太干，我们来看几个真刀真枪的案例。
案例 1：Claude Code 本身
Claude Code 之所以被誉为目前最好的编码 Agent，不是因为它用了什么独家模型，它用的就是公开可用的 Claude。它的护城河是 Harness。从泄露的源码分析和 Anthropic 的官方博客可以看到这些设计：
错误自愈：遇到可恢复错误时，Harness 会尝试多种恢复策略：上下文坍缩、主动压缩、输出 token 上限提升、多轮续接；
子 Agent 上下文防火墙：主 Agent 把子任务分发给子 Agent 时，只传必要上下文，避免污染；
增量进展机制：不让一个 Agent 跑几个小时，而是开启很多个跑 5 分钟左右的短 Agent，并行或串行；
检查点机制：用文件系统和 markup 文件存储跨 session 的检查点。
值得一提的是，Anthropic 后来把 Claude Code SDK 改名为 Claude Agent SDK，因为他们发现这套 Harness 不只能写代码，做深度研究、生成视频、做笔记同样有效。Harness 的本质是通用的 Agent 操作系统。
案例 2：OpenAI 的百万行代码实验
三名工程师，5 个月，100 万+ 行代码，0 行手写。这个项目用 Codex 作为 Agent，外加一套精心设计的 Harness：持续增强的知识库 + 动态上下文（可观测性数据、浏览器导航状态）；大量 AGENTS.md 文件分层管理规则；工程师角色从"代码编写者"转变为"系统驾驭者"，他们的座右铭是
"Humans steer, agents execute"（人类掌舵，代理执行）
OpenAI 团队的一个关键洞察是：传统的"一个巨大的 AGENTS.md 文件"必然失败。上下文是稀缺资源，过多的指导反而失效，会变成"陈旧规则的坟场"。
案例 3：LangChain 的定量验证
LangChain 提供了 Harness Engineering 价值的最强量化证据。他们用 GPT-5.2-Codex 作为模型，在 Terminal Bench 2.0 上测评：
初始状态（裸模型 + 简单循环）：得分 52.8%，排不进 Top 30；
加入精心设计的 Harness 后：分数大幅跃升至榜单前列。
模型没变，分数翻倍。这就是 Harness 的力量。
案例 4：企业级应用——客服 Agent
不止是写代码。任何生产级 Agent 都需要 Harness。一个企业客服 Agent 的 Harness 通常包括：
上下文工程：拉取相关账户数据、历史对话、当前订单状态；
工具编排：根据问题类型动态开放工具——退款问题打开退款 API，物流问题打开物流查询；
审批门：超过 500 元的退款必须人工审核；
可观测性：每一通对话的工具调用、token 消耗、转人工率都进入监控面板；
回退策略：连续 3 轮无法解决时自动转人工。
给开发者的实战建议
心态转变：你已经在做 Harness 了
如果你正在做 AI 应用开发，无论你叫不叫它 Harness，你已经在做 Harness Engineering 了。系统 prompt、工具定义、记忆机制、上下文检索、错误处理逻辑……这些都是 Harness 的组成部分。差别只在于：你是在自觉地设计它，还是在被动地堆砌它。
七条避坑指南：
综合各方实践经验，新手最常踩的坑：不要把系统 prompt 当静态文档——它应该根据当前任务动态注入相关上下文；
不要给 Agent 40 个工具——按任务状态约束工具集；
不要在一个 AGENTS.md 里写完所有规则——分层、按需加载；
不要相信 Agent 的"自我评估"——务必用外部传感器（测试、Linter）验证；
不要让 Agent 一次性做完整任务——拆成增量步骤，每步 commit；
不要忘了把记忆外化——状态写到文件里，不要指望模型记住；
不要省略"开机仪式"——每个 session 强制走一遍 pwd / git log / progress.txt 三件套。
上手路径：
如果你想系统地入门 Harness Engineering，推荐顺序：读 Anthropic 官方博客《Effective harnesses for long-running agents》——最权威的实践指南；读 Martin Fowler 的《Harness engineering for coding agents》——理论框架最清晰；读 OpenAI 的 Codex 实验报告——产业级案例；动手用 Claude Agent SDK 或 Claude Code 跑一个自己的小项目，刻意观察它的 Harness 行为；反过来用同样的设计原则改造自己手头的 AI 应用。
范式之外：这意味着什么？
Addy Osmani 有一句话讲得很到位：AI 编码的兴起并没有取代软件工程的工艺——它抬高了工艺的门槛。
模型在飞速商品化。Claude、GPT、Gemini、开源模型，在标准评测上越来越接近。模型本身已经不再是竞争优势。模型之外的那一层，才是。
这对开发者意味着什么？我认为是三件事：
第一，工程师的角色在转变。从"写代码的人"变成"设计让 AI 能可靠工作的系统的人"。这不是降级，恰恰相反——它要求你既懂模型的脾气，又懂系统设计，还懂业务的边界。这种复合能力的门槛只会越来越高。
第二，工程纪律的价值在回归。Git 工作流、测试覆盖、文档规范、CI/CD——这些"老派"的工程实践，在 AI 时代不仅没有过时，反而成了 Harness 的核心组成部分。一个有完整 CI 流水线的项目，Agent 在上面跑得就是更稳。
第三，瓶颈不在智能，而在基础设施。当你的 Agent 表现不及预期时，第一反应不该是"换个更强的模型"，而是"我的 Harness 哪里出了问题？"——是上下文组装不到位？验证循环缺失？还是记忆机制设计粗糙？
写在最后
2023 年，我们学会了写 prompt；2024–2025 年，我们学会了组织 context；2026 年的这个春天，Harness Engineering 把这一切纳入了一个更大的工程框架。
它不是某个公司的私货，也不是某个产品的专属概念。它是这个行业用真金白银的失败换来的共识：Agent 是模型与 Harness 的乘积，而 Harness 才是那个被长期低估的乘数。
如果你正在构建 AI 应用，无论它叫智能助手、Copilot 还是 Agent，花点时间，认真设计你的 Harness 吧。这一层做扎实了，你的 Agent 才真正具备在生产环境里跑下去的资格。
毕竟，再快的马也跑不过没有缰绳的悬崖。
参考资料：Anthropic Engineering Blog、Martin Fowler 个人博客、OpenAI Codex 实验报告、LangChain Terminal Bench 评测、Addy Osmani 个人博客、MindStudio、Red Hat Developer、知乎/36氪相关深度报道。
