Harness Engineering：拆开看看，哪些是新瓶装旧酒，哪些值得你真金白银投入

在 AI 的喧嚣里，替你找到真正能用的东西。不搬运新闻，不贩卖焦虑。

最近 Harness 这个词被聊得很多。2 月初 HashiCorp 创始人 Mitchell Hashimoto 率先在博客里提出了”Harness Engineering”的概念，2 月下旬 OpenAI 跟进发了工程博客，3 月 Anthropic 连发两篇重磅文章，4 月初 Martin Fowler 从经典软件工程角度做了系统性总结，腾讯汤道生也发了一篇《人工智能正式进入 Harness 时代》。两个月内，从个人博客到行业共识。我身边做架构的朋友隔三差五就问我怎么看。

我花了点时间把这几家的原文、Medium 上的分析、Reddit 和 Hacker News 上的讨论都翻了一遍，还拆了 Claude Code 3 月底泄露的 51 万行源码，看了 OpenClaw 从 9000 星涨到 34 万星背后的真实架构，也翻了知乎、腾讯云开发者社区、36Kr、CSDN 上中文社区的深度讨论，以及 arXiv 上最新的相关论文。

我的判断：大约四成是老酒换了新瓶，六成是真正值得关注的新东西。下面一条一条拆给你看。

---

一、先搞清楚 Harness 到底是什么

一个比方

想象你让 AI 帮你点个外卖。

没有任何约束的情况下，AI 可能给你推荐一家人均 280 的日料，离你 8 公里，配送要一小时，里面还有你过敏的虾。它不是不聪明——它是不知道你的预算、你的忌口、你对配送时间的容忍度。

现在给它加一套规矩：预算 50 以内，不吃辣，海鲜过敏，要有主食，只看附近 3 公里评分 4.5 以上的店。再让它查完菜单之后自动做一轮检查——总价超了没？有忌口的东西没？配送时间合理吗？最后再让它记住你上周点过什么、哪家店你投诉过。

这一套规矩、检查、记忆加起来，就是 Harness。AI 的判断力没变，但它从一个”什么都敢推荐的愣头青”变成了一个”了解你情况、办事让人放心的助手”。

一个框架

汤道生给了一个我觉得很精准的三层框架：

• 大模型是发动机——提供原始动力，能思考、能对话，但自己不会”开车”
• Harness 是线束——把动力传导到车轮、把信号传导到仪表盘、把驾驶员的意图翻译成机械动作
• 使用者是驾驶员——决定去哪、怎么开、什么时候该接管

三者缺一不可。但过去三年所有注意力都在发动机上，现在焦点正在转向线束和驾驶员。

一条演进线

从工程实践的角度，AI 工程经历了三代进化，每一代包含前一代：

2022-2025  Prompt Engineering        → 给驾驶员一张地图
2025       Context Engineering       → 给驾驶员一套导航系统
2026.2     Mitchell Hashimoto 命名   → 给驾驶员造一辆完整的车
2026.2-4   OpenAI/Anthropic/Fowler   → 全行业开始造车

地图和导航都重要，但只有地图和导航，没有车，哪儿也去不了。

---

二、Harness 的完整零件清单

很多文章只提了 Guides 和 Sensors 两个概念，但如果你去看 Claude Code 实际的代码和 OpenClaw 的架构，一个完整的 Harness 远不止这两样。根据 Martin Fowler、OpenAI、Anthropic 的综合框架，以及 Claude Code 泄露源码的实际架构，一个生产级 Harness 至少包含 八大组件：

1. Guides（引导 / 前馈控制）

还没干活就把规矩立好。

点外卖：预算 50、不吃辣、海鲜过敏。AI 还没动手，规矩已经写死了。

在 Claude Code 里，这个东西叫 CLAUDE.md——一个文件，写着项目结构、编码规范、架构约束。Agent 每次启动都会读它，就像新员工第一天读《员工手册》。在 OpenClaw 里叫 SOUL.md——定义 Agent 的行为准则、价值观、边界。

Anthropic 的工程团队有个说法我觉得挺实在的：花 30 分钟写一个好的 CLAUDE.md，带来的质量提升比你花三天调 prompt 大得多。这可能是 Harness 里投入产出比最高的单一动作。

Cursor 团队在大规模 Agent 实验中也发现了一个反直觉的现象：当模型可以生成任何东西时，反而浪费大量 token 探索死胡同；但当 Harness 定义了清晰的边界，Agent 反而更快收敛到正确答案。约束解空间，反而提高了 Agent 的生产力。

还有一个更极端的案例：有人仅仅把代码编辑工具的格式从 str_replace 换成 hashline（一种基于行号的编辑格式），同一个模型的编程成功率从 6.7% 跳到 68.3%——十倍提升，模型没换，prompt 没换，只换了工具调用的格式。这说明 Harness 层面一个看似微小的设计决策，对最终效果的影响可能远超你的想象。

2. Sensors（传感器 / 反馈控制）

干完活检查一遍。

点外卖：下单前检查总价、忌口、配送时间。不合格就打回重来。

传感器分两种：

• 计算型（毫秒级）：跑测试、类型检查、规则校验——确定性高，速度快
• 推理型（秒级）：用另一个 AI 来审查输出——能捕捉”逻辑不对但格式正确”的问题

LangChain 有个案例值得注意——他们只加了自我验证和循环检测两个 Sensor，在 Terminal Bench 2.0 上从 52.8% 跳到 66.5%，排名从三十名开外直接进前五，模型一行没换。

这里有个重要发现来自 Anthropic：AI 无法可靠地评价自己。 当 Agent 评估自己刚完成的工作时，它会自信地表示”做得很好”，即便在人类看来质量明显不行。Anthropic 的工程师原话是：”开箱即用的 Claude 是一个很差的 QA Agent。” 这意味着仅靠模型自身无法形成有效的质量闭环，必须在模型外部建立独立的评估机制——这正是 Sensors 存在的根本原因。

arXiv 上也有相关的学术验证。一篇关于容错沙箱的论文（arXiv:2512.12806）实现了基于策略的拦截层 + 事务性文件系统快照回滚，对高风险命令达到了 100% 的拦截率，而性能开销只有每次事务 1.8 秒（总开销 14.5%）。另一篇 ALARA 框架（arXiv:2603.20380）的核心发现是：通过结构性强制（改工具列表）来保证行为改变，比通过指令合规（告诉模型”不要做 X”）可靠得多。 换句话说，与其对 AI 说教，不如直接拿走它的工具——信任机制，不信任说教。

3. Context Engineering（上下文工程）

给模型看什么信息，决定了它的判断质量。

点外卖：不是把全城 5000 家餐厅丢给 AI，而是只给它看附近 3 公里、50 块以内的。

这是 Harness 里面最有价值的新东西。传统软件里一个函数能访问整个数据库，但大模型有上下文窗口限制——你塞太多它反而糊涂，塞太少它信息不够。”给什么、什么时候给、给多少”本身就是一门新手艺。

Anthropic 发布了一组工程实验数据：同一个模型、同一句提示词，用简单方式跑 20 分钟花 9 美元，核心功能完全无效；而用完整的 Harness 跑 6 小时，花 200 美元，交付了一个真正可用的游戏，核心交互全部跑通。另一个案例里，通过精细的上下文管理把 token 消耗从 15 万降到 2000——降了 98.7%。

一位独立开发者 Heyuan110 做了 60 天的 A/B 测试也印证了这一点：换模型（从 Opus 换到 Sonnet）只带来 5% 的质量变化，但重构 Harness 在保持质量的同时降低了 60% 的 token 成本。

模型没变，变的是驾驭它的线束。

arXiv 上一项大规模实验（arXiv:2602.05447）用 9649 次实验、11 个模型、4 种文件格式（YAML/Markdown/JSON/TOON）验证了上下文工程的效果：基于文件的上下文检索对前沿模型有 +2.7% 的提升，且能够成功处理 10000 张表的大规模场景。有趣的是，格式本身影响不大——YAML 和 Markdown 效果差不多——重要的是信息的组织方式，而不是载体格式。

另一篇 ACE 框架论文（arXiv:2510.04618）发现了一个叫”上下文坍缩”（Context Collapse）的问题：当 Agent 反复重写上下文时，细节会逐步丢失。解决方案是用结构化的模块式更新代替整体重写，在 Agent 任务上提升了 10.6%。

4. Memory（记忆系统）

让 AI 记住之前发生了什么。

点外卖：记住你上周点了黄焖鸡给了好评，上月投诉了某家店，周五晚上通常点烧烤。

这个被很多 Harness 文章忽略了，但它在生产系统里极其关键。Claude Code 的源码揭示了一个三层记忆架构：

第 1 层：MEMORY.md — 轻量索引，每行约 150 字，永远在上下文里
          → 你脑子里随时能想起来的东西

第 2 层：主题文件 — 按需加载的详细信息
          → 你书桌上的文件夹，需要时才打开

第 3 层：完整会话记录 — 存在磁盘上，搜索时才调用
          → 你的文件柜，偶尔才翻

AutoGPT 2023 年失败的核心原因之一就是没有持久记忆——每一步都忘了前面做了什么，反复解决同一个问题。

5. Tools & MCP（工具与标准协议）

AI 光靠”脑子”不够，得能动手干活。

点外卖：查评分、读菜单、下单、支付——这些都是”工具”。

MCP（Model Context Protocol） 是 Anthropic 在 2024 年底推出的统一工具协议，微软称其为”应用领域的 USB-C”。以前每个框架自定义工具接口，换框架就得重写。MCP 让工具写一次到处用，把 N 个模型 × M 个工具的适配问题变成了 N+M。OpenAI 在 2025 年 3 月跟进支持，现在基本是事实标准。

Claude Code 的实现里有一个巧妙设计：工具定义不是全部塞进上下文，而是按需加载。 Agent 不需要知道自己有 50 个工具——默认只暴露 19 个，其余按需发现和加载。这又回到了上下文工程：省 token，减少选择困难。

6. Security & Sandboxing（安全与沙箱）

防止 AI 干出格的事。

点外卖：不能访问你的银行密码，不能给陌生人转账，只能在外卖 App 里操作。

这个在 demo 里从不讨论，但在生产环境里是第一优先级。一个没有 Harness 的大模型，就像一个没有操作规程的实习生——能力不差，但你不知道他下一步会做什么。

Claude Code 泄露的源码揭示了一个分层权限管道：

通用规则（允许/拒绝/询问）
    ↓
工具级检查（这个工具能做什么）
    ↓
独立分类器（在另一个模型实例上运行，看不到 Agent 的对话——防止 prompt 注入）
    ↓
拒绝永远优先于允许
    ↓
人类审批作为最后兜底

关键设计：权限分类器和 Agent 运行在不同的模型实例上，分类器看不到 Agent 的对话内容。为什么？因为如果它们共享上下文，攻击者可以通过 prompt 注入让分类器放行恶意操作。

这不是对 AI 能力的削弱，而是让 AI 真正进入企业生产环境的前提。用得放心，才能用得起，才能真正用得上。

7. Observability & Tracing（可观测性与追踪）

知道 AI 在干嘛、干得怎么样。

点外卖：你能看到 AI 查了哪些店、比较了哪些菜、为什么选了这家——完整的决策过程，不是一个黑盒。

生产环境里，这意味着：

• 每一步 tool call 都有 trace（类似 OpenTelemetry）
• 能看到 token 消耗、延迟、成本
• 异常时能回溯完整的决策路径
• 能从真实使用数据中构建评估数据集

OpenAI Agents SDK 内置了 tracing，LangChain 有 LangSmith。

8. Cost Control & Resilience（成本控制与容错）

别让 AI 把你的钱烧光了，出了错能自己恢复。

点外卖：预算硬上限 50 块，超了就停。网络断了能重试，店关了能换一家。

这是我觉得目前讨论最不充分的一个组件。真实数据：

• 带工具调用的复杂 Agent，token 消耗是简单调用的 5-20 倍
• 一个 Reflection 循环跑 10 轮是单次调用的 50 倍
• 没有成本控制，一个失控的 Agent 一晚上能烧掉几百美元

生产系统里需要 token 预算（超阈值终止或降级）、指数退避重试、熔断器模式、模型降级方案。这些做微服务的人都熟，但在 Agent 领域还没有被系统性地实践。

闭环：Evals（评估飞轮）

以上八大组件搭好了，怎么知道效果好不好？怎么持续改进？答案是 Evals——独立于组件之外的闭环验证系统。

Martin Fowler 近期反复强调一个概念叫 “Agentic Flywheel”（智能体飞轮）：用 Evals 的结果反哺 Harness 的改进，让 Agent 自己驱动 Harness 的迭代。

Evals 不是 Sensors 的附属品。Sensors 是实时的、嵌入执行流程的检查（”这一步做对了没？”），而 Evals 是离线的、全局的质量度量（”这个 Agent 整体表现如何？这次 Harness 修改是进步还是退步？”）。

没有 Evals，你对 Harness 的每一次修改都是盲人摸象。有了 Evals，Harness 的优化就从”凭感觉”变成了”用数据说话”。这也是为什么我在最后的投入建议里把 Evals 列为第二优先级——它是从 demo 到生产的分水岭。

---

三、真实产品是怎么做 Harness 的？

Claude Code：Harness Engineering 的教科书级实现

2026 年 3 月 31 日，Anthropic 因为 npm 打包配置错误，意外泄露了 Claude Code 的完整源码——51.2 万行 TypeScript，1906 个文件。这次泄露意外地成了全行业的 Harness Engineering 教材。

核心架构：一个 while 循环

Claude Code 的核心是一个 while 循环：发消息给 API → 收到回复 → 如果是工具调用就执行 → 把结果发回去 → 继续循环。没有 DAG，没有分类器，没有 RAG。

听起来简单，但精髓在于：模型决定做什么，另一个独立系统决定允不允许做。 这个”判断”和”许可”的分离，就是 Harness 的核心思想。

用户输入
   ↓
QueryEngine (while 循环)
   ├─ 发消息给 Claude API
   ├─ 收到回复：是工具调用吗？
   │   ├─ 是 → 权限管道检查 → 执行工具 → 返回结果
   │   └─ 否 → 输出给用户
   └─ 继续循环，直到任务完成

权限管道（独立于 Agent 运行）
   ├─ 通用规则
   ├─ 工具级检查
   ├─ 独立分类器（隔离的模型实例）
   └─ 拒绝永远优先

记忆系统
   ├─ MEMORY.md（永远在上下文）
   ├─ 主题文件（按需加载）
   └─ 完整记录（磁盘存储，搜索时用）

上下文压缩
   ├─ 输入 token 超过 10 万时自动触发
   ├─ 生成摘要 → 丢弃旧消息 → 从摘要继续
   └─ 关键信息（MEMORY.md）在压缩后仍然保留

工具系统
   ├─ 50+ 工具实现
   ├─ 默认只暴露约 19 个（减少模型选择困难）
   └─ 其他工具按需发现和加载

为什么 Claude Code 成功了？不是因为模型比别人好——是因为 Harness 比别人扎实。三层记忆让它不会遗忘，权限管道让它不会越界，上下文压缩让它能持续工作几小时不崩溃，工具按需加载让它不会被 50 个选项搞糊涂。

OpenClaw：从 9000 星到 34.6 万星

OpenClaw 是那只”搅动整个行业的小龙虾”。奥地利开发者 Peter Steinberger 创建的开源个人 AI 助手——通过 WhatsApp、Telegram、Slack 等消息应用控制，本地运行，免费。60 天内超越了 React 十年积累的 GitHub 星标记录。

它没有发布任何新模型，没有刷新任何基准测试，甚至没有训练一个新参数。它只做了一件事：给大模型搭建了一套完整的工作环境。

三层架构：

Channel 层（网关）：接入 WhatsApp / Telegram / Slack 等
     ↓
Brain 层（Agent 运行时）：LLM 推理和决策
     ↓
Body 层（技能系统）：执行具体动作

OpenClaw 的 Harness 特色：多文件人格系统

不像传统 Agent 只有一个 system prompt，OpenClaw 用一组 Markdown 文件来定义 Agent 的全部规矩：

文件	作用	对应 Harness 组件
SOUL.md	定义目的、行为准则、价值观、边界	Guides
TOOLS.md	声明能力和工具	Tools
IDENTITY.md	个性化配置	Context
HEARTBEAT.md	执行节奏和调度	Cost & Resilience
AGENTS.md	多 Agent 协调	Orchestration

OpenClaw 社区里有句话说得到位：”每次 Agent 醒来，它读取 SOUL.md——它把自己读进存在。” Agent 的人格不在模型里，在 Harness 里。换个 SOUL.md，同一个模型变成完全不同的 Agent。

设计原则也值得注意：”更多规则不等于更好的人格——几条精选的规则比一堆模糊的规则更有效。”

三层 Harness 架构（来自中文社区的独特框架）

国内有一篇分析文章提出了一个很实用的三层架构框架，值得架构师参考：

层级	作用	典型内容
通用 Harness 层	运行时环境，所有 Agent 共享	沙箱、权限管道、token 预算、tracing
项目 Harness 层	特定项目的规范和约束	CLAUDE.md、编码规范、架构约束、依赖规则
任务 Harness 层	具体任务的验收流程	测试用例、验收标准、输出格式要求

这个分层和我们做微服务时的”平台层-业务层-接口层”思路是一致的。好处是关注点分离：平台团队管通用层，业务团队管项目层，具体需求方管任务层。

学术界的最新进展

GitHub 上有个项目叫 AutoHarness，提出了一个 6 步治理管道：解析校验 → 风险分类 → 权限检查 → 执行 → 输出清洗 → 审计日志。提供三个可配置的强度级别（Core / Standard / Enhanced），让团队根据场景选择治理力度。

arXiv 上还有一篇叫 Meta-Harness（arXiv:2603.28052）的论文更有意思——它用一个外层系统通过搜索来自动优化 Harness 代码，相当于”给 Harness 写 Harness”。这是目前我看到的第一个系统性证明 Harness 质量可以通过自动化搜索来持续改进的框架。而且这个概念已经在落地——KAOS v0.2（基于 SQLite 的 Agent 运行时）已经支持让大模型在沙箱里自动迭代优化自己的 Prompt 和 Harness 源码，Meta-Harness 从论文走向产品的速度比预想的快得多。

另一篇关于自然语言 Agent Harness（arXiv:2603.25723）的论文提出把控制逻辑从代码中提取出来，用可编辑的自然语言表达。这样 Harness 就变成了可移植、可比较、可科学研究的对象——不再是埋在控制器代码里的隐性知识。

林清华在 GitHub 上写了一本 42 万字的《御舆：解码 Agent Harness》（github.com/lintsinghua/claude-code-book），139 张架构图分析了 50 多个设计决策。如果你想深入理解 Claude Code 的 Harness 实现，这可能是目前最详细的中文参考。

---

四、历史拷问：以前的 Agent 难道不是这么干的？

答案是：以前确实在做类似的事，但做得很粗糙，而且没有把它当成一门独立学科。

一张表看清 2023-2026 的演进

阶段	代表产品	Harness 水平	结果
2023 概念验证	AutoGPT	几乎没有——只有 prompt	无限循环、token 爆炸、花费失控
2023 改良	BabyAGI	有任务优先级循环（原始 Sensor）	比 AutoGPT 好，但仍脆弱
2023-24 结构化	MetaGPT	角色分工 + SOP + QA 验证	ICLR 发表，连贯性显著提升
2024 生产级	Devin	完整记忆层 + 规划循环 + 沙箱	能自主工作数小时
2025 标准化	Claude Code / OpenClaw	八大组件完整落地	生产可用，百万用户

AutoGPT 的失败是最好的反面教材

AutoGPT 2023 年爆红，也几乎同时暴露了所有”没有 Harness”的问题：

• 无限循环：Agent 反复执行同一个子任务而不自知。语义搜索无法区分”我正在做的事”和”我已经做过的事”。用户报告出现 150 多次循环后才失败
• 上下文爆炸：当积累的上下文超过 token 限制，Agent 直接跑偏——忘了原始指令，输出完全不可靠
• 费用失控：无人值守的运行一晚上能烧掉几百美元，因为没有任何上限、超时或成本估算
• 不会求助：Tom’s Hardware 的评价——”太自主以至于没用”：不会问你确认，也不接受纠正，但同时又不靠谱

根本原因：AutoGPT 把语言模型当成了整个 Agent。没有 Harness，模型就是在虚空中执行。

Devin 的成功证明了 Harness 的价值

Cognition 的 Devin（2024）是第一个明确按 Model + Harness 思路构建的生产级 Agent：

• 规划器 LLM：先拆解计划，每步自我批评（Guides + Sensors）
• 完整时间线：每个命令、每次代码修改都有记录，可以回溯和重试（Memory + Observability）
• 沙箱环境：独立的终端 + 编辑器 + 浏览器，不会破坏生产系统（Security）
• 持久任务列表：能维护 to-do list，”在几小时甚至几天内逐步完成”（AutoGPT 不可想象）

Devin 能做到 AutoGPT 做不到的事，不是因为模型更好——而是 Harness 更好。

关键转折点：从隐式到显式

AutoGPT (2023)     → 隐式 Harness：prompt 里硬塞一些规则，碰运气
BabyAGI (2023)     → 临时 Harness：加了任务循环，稍好一点
MetaGPT (2024)     → 结构化 Harness：角色 + SOP + QA，开始有纪律
Devin (2024)       → 完整 Harness：记忆 + 规划 + 沙箱 + 时间线
Claude Code (2025)         → 工程化 Harness：八大组件，51 万行代码支撑
Mitchell Hashimoto (2026.2) → 首次命名 "Harness Engineering"
OpenAI/Anthropic/Fowler     → Harness 成为正式学科 (2026.2-4)

就像人类在命名”面向对象编程”之前也在写对象——概念一直在那里，但命名和方法论的价值在于把散乱的经验系统化了。

---

五、灵魂问题：到底哪些是新瓶装旧酒？

确实是旧酒（换了 AI 外衣的老概念）

状态管理 → “Agent Memory”。 分布式系统里的 session 管理、状态机，干了二十年了。叫它”记忆”不会让它变新。

工作流编排 → “Agent Orchestration”。 Airflow、Temporal、Step Functions——编排引擎的 AI 翻版。Agent 框架里的 tool calling 链就是换了层皮的 DAG。

反馈循环 → “Sensors”。 CI/CD 流水线、测试驱动开发、代码审查。换个名字叫”传感器”，本质是你写了十年的自动化测试。

输入校验和护栏 → “Guides / Guardrails”。 类型系统、linter、schema 校验、业务规则引擎。不新。

分层权限 → “Permission Pipeline”。 RBAC、ABAC、OAuth——安全领域的基本功。

重试和熔断 → “Agent Resilience”。 Hystrix、Resilience4j、指数退避——微服务架构里的标配。

对于有扎实软件工程功底的架构师来说，以上这些你已经会了。不需要从头学，只需要理解它们在 AI Agent 场景下的适配方式。

确实是新酒（值得认真投入的新东西）

1. 上下文工程（Context Engineering）

Harness 最核心的创新，传统软件里不存在这个问题。

传统系统里，你的函数能访问整个数据库。但大模型有 token 窗口——你不可能把所有信息都塞进去。”给什么信息、什么时候给、怎么压缩、怎么优先级排序”变成了一门全新的工程学科。

Anthropic 的实战数据：上下文优化带来 98.7% 的 token 消耗降低。Stanford HAI 研究：Harness 优化提升效果 28-47%，而 prompt 调优只有不到 3%。Nate B Jones 的实验：同一模型只换 Harness，编程成功率从 42% 跳到 78%。

这不是旧概念的翻版，这是 LLM 时代独有的新问题。

2. “约束即赋能”（Constraints as Enablement）

反直觉但有数据支撑的新发现：给 Agent 越严格的限制，它表现越好。

OpenAI Codex 团队发现，设置了固定分层结构、强制依赖方向、机械化 linter 的 Agent，比没有约束的 Agent 又快又准。Cursor 团队也验证了这一点：约束解空间，反而提高了 Agent 的生产力。LangChain 不换模型只优化 Harness，绝对性能提升 13.7%。

传统软件也有规范，但没有人系统论证”约束如何提升自主系统的可靠性”。这是 Autonomous Systems 领域的新知识。

3. MCP 协议（工具集成的 USB-C 时刻）

以前每个框架自定义工具接口——N 个模型 × M 个工具 = N×M 个适配器。MCP 把它变成 N+M。这不是技术创新，是生态创新。2024 年底 Anthropic 推出，2025 年 OpenAI 跟进，已成事实标准。

4. AI 审查 AI（Generator-Critic 模式）

用一个模型检查另一个模型的输出。Claude Code 用独立的模型实例做权限分类，和 Agent 的对话上下文完全隔离。这种”模型间的制衡”在传统软件里没有对应物。

5. Human on the Loop（人机协作新范式）

从 “human in the loop”（人审查每个输出）到 “human on the loop”（人维护 Harness 规则，Agent 自主执行）。Martin Fowler 原话：”人的工作是通过迭代改进 Harness 来引导 Agent”——你不是质检员，你是教练。

6. 多文件人格系统（CLAUDE.md / SOUL.md）

传统 Agent 用一个巨大的 system prompt。现代 Agent 用一组结构化文件来定义行为、约束、记忆、工具。这不只是格式变化——它让 Harness 变得可版本控制、可协作编辑、可 A/B 测试。你可以对 CLAUDE.md 做 git diff，看看哪次修改提升了 Agent 表现。

arXiv 上一篇论文（arXiv:2602.14690）系统梳理了 8 种 Agent 配置机制：Context Files、Skills、Subagents、Commands、Rules、Settings、Hooks、MCP Servers，覆盖了 Claude Code、GitHub Copilot、Cursor CLI、Gemini CLI、Codex CLI 五个主流工具。这意味着多文件行为定义已经从 Claude Code 的独家做法变成了行业共识——不管你用什么工具，背后都在做这件事。

另一篇关于”外化”的综述论文（arXiv:2604.08224）给出了一个更高层的概括：现代 Agent 越来越少通过改模型权重来定制行为，越来越多通过重组运行时环境来实现。记忆、技能、协议、Harness 工程，本质上都是”外化”策略——把能力从模型内部搬到模型外部。Harness Engineering 就是这些外化策略的统一层。

我的判断：四六开

大约 40% 是旧酒（状态管理、编排、护栏、重试、权限），60% 是新酒（上下文工程、约束即赋能、MCP、AI 审查 AI、human on the loop、多文件人格）。

---

六、六项技术突破让 Harness 从概念变为可能

为什么 Harness Engineering 在 2023 年不可能、2026 年才成熟？因为六项底层技术条件刚刚到位：

突破	时间	影响
百万级上下文窗口	2024-2025	Claude Opus / GPT-4.1 / Gemini 2.5 Pro 支持 100 万+ token。AutoGPT 时代只有 8K
推理 + 工具同时使用	2025.4	o3/o4-mini 首次实现”一边想一边用工具”。以前要么推理要么用工具，不能同时
MCP 标准化	2024.11	解决了 N×M 工具适配问题
安全沙箱成熟	2024	MicroVM、gVisor 让 Agent 能安全执行代码
SWE-bench 飞跃	2024-2025	模型编码能力从 15-25% 跳到 80%+，Harness 终于有了值得包装的”引擎”
自我纠错循环	2024-2025	Agent 能跑测试、发现错误、生成修复、重试——从”碰运气”变成”工程化”

没有这些底层突破，Harness 就是空架子。 就像你不能在马力只有 10 匹的发动机上谈底盘工程——先得有足够好的引擎，才值得投资包装它的系统。

---

七、商业视角：架构师和 VP 需要知道的

框架之争的本质是生意

别被”开源”和”社区”的叙事迷惑。大厂推 Agent 框架的真实动机：

掌控 Harness = 掌控推理流量 = 掌控云计算消费。

公司	策略	锁定什么
OpenAI	Agents SDK 绑定 OpenAI API	推理消费
Google	ADK + A2A 协议	Vertex AI 计算资源
AWS	Agent 嵌入 Bedrock	云消费
微软	AutoGen + Semantic Kernel → Azure	Azure OpenAI 调用

McKinsey 确认：Agentic AI 是 Hyperscaler 增长最快的品类。框架是入口，推理是收银台。

Build vs Buy 的决策框架

维度	自建	采购平台
上线时间	12-24 个月	6-8 周
成功率	~67%（有合作伙伴时）	更高（基于成熟 Harness）
成本认知偏差	通常低估 40-60%	更透明
差异化价值	高（完全控制）	低（标准方案）
适合场景	Agent 是核心业务	Agent 是辅助能力

MIT 的研究：有清晰基线指标的公司，获得正回报的概率是没有基线的 3 倍。别还没量化现状就急着上 Agent。

ROI 的真实数据

好的一面（Microsoft ROI 框架 + Deloitte 调研）：运营成本降 15-35%，效率提 20-40%，错误减 30-60%。回收周期：定向部署 6-18 个月，企业级规模 1-3 年。

不好的一面：RAND 研究 80-90% 的 AI Agent 项目失败。Gartner 预测超过 40% 到 2027 年进不了生产。五个失败原因中只有一个是技术问题，其他四个是组织和战略问题。

失败率高不是因为技术选错了，而是因为组织没准备好。Harness 不只是技术架构，也是组织能力的映射。

---

八、前瞻：Harness 会被模型吃掉吗？

这是汤道生文章里最有远见的一个判断：模型正在自己长出手脚。

随着上下文窗口越来越大、记忆能力不断提升、推理链条越来越长，今天需要外部搭建的工具调用、上下文管理、反馈循环、记忆系统，模型正在一项一项地内化。

就像早期汽车需要复杂的外部操作机构来转化发动机动力，而现代电动车的发动机和传动系统已经高度一体化——线束越来越简单，因为发动机自己就”懂”了。

当这一天到来，驾驶员的角色将从”操作者”升级为”委托人”——不再告诉 AI 怎么跑，而是告诉它要去哪里。

但即便模型吸收了所有的工具和流程，有一件事它永远无法自己生成：目的地。 去哪里、为什么去、到了之后怎么判断值不值，这些关于方向、意义和价值的问题，永远是人的责任。模型越强，这个责任越重——因为当机器什么都能干的时候，”干什么”变成了唯一重要的问题。

这就是”品味”在 AI 时代的新含义：不是审美偏好，而是判断什么是好的、什么是对的、什么是值得做的能力。同样的发动机，同样的 Harness，不同的驾驶员产出的东西可以有天壤之别。

---

九、投入建议

第一优先级：上下文工程

投资回报最高的能力，不会随框架更替贬值。推荐读 Anthropic 的 “Building Effective Agents” 和 “Effective Harnesses for Long-Running Agents”。

第二优先级：Evals（评估体系）

没有好的 eval，你根本不知道 Agent 改好了还是改坏了。这是从 demo 到产品的分水岭。

第三优先级：原生 Function Calling + MCP

不依赖框架，直接用 API 实现工具调用。先懂底层，再决定要不要用框架。MCP 已成事实标准。

第四优先级：写好你的 CLAUDE.md / SOUL.md

30 分钟写一个好的行为规范文件，可能比你花三天调 prompt 效果更好。可版本控制、可协作、可 A/B 测试。

可以等一等的

• Multi-Agent 架构：概念很酷，但目前大多数生产任务一个 Agent 就够了。复杂度高，收益不确定
• 具体框架的 API：更新太快，概念比 API 重要。理解 Harness 的八大组件，用什么框架都不慌

Anthropic 的忠告

“从简单的 prompt 开始，用全面的评估来优化它，只有在简单方案确实不够时才引入多步骤 agentic 系统。”

别上来就搞框架，先把最简单的方案做到极致。

---

收尾

Harness 解决的核心问题是靠谱，不是聪明。

模型提供判断力，Harness 提供可靠性。Stanford 的数据说得很清楚——在 Harness 层面做优化的回报是 prompt 层面的 10 倍以上。如果只能在一个地方投入精力，投在模型外面那一圈——上下文工程、评估体系、行为规范。这才是真正拉开差距的地方。

真正稀缺的能力，不在模型里面，在模型外面。驯服一匹野马，需要的不是更长的鞭子，而是一副趁手的缰绳，和一个知道目的地的骑手。

---

参考来源

行业博客：Mitchell Hashimoto “My AI Adoption Journey” (2026.2.5)、OpenAI “Harness Engineering” Blog (2026.2)、Anthropic “Building Effective Agents”、Anthropic “Effective Harnesses for Long-Running Agents” (2026.3.24)、Martin Fowler “Harness Engineering for Coding Agent Users” (2026.4.2)、LangChain “Anatomy of an Agent Harness”、汤道生《人工智能正式进入 Harness 时代》(2026.4.13)

中文社区：知乎 Harness Engineering 深度解析系列、腾讯云开发者社区 Harness 专题、36Kr《读懂 Harness Engineering：翻遍 14 篇工程文章》、CSDN Agent Harness 架构进阶、林清华《御舆：解码 Agent Harness》(GitHub)、Heyuan110 博客 60 天 A/B 测试数据

arXiv 论文：Natural-Language Agent Harnesses (2603.25723)、Externalization in LLM Agents (2604.08224)、Meta-Harness (2603.28052)、ACE Context Engineering (2510.04618)、Structured Context Engineering (2602.05447)、ALARA Least-Privilege (2603.20380)、Fault-Tolerant Sandboxing (2512.12806)、Configuring Agentic AI Tools (2602.14690)、Context Engineering Survey (2507.13334)、CLEAR Enterprise Framework (2511.14136)

GitHub：AutoHarness、Deep Agents (LangChain)、SOUL.md、OpenHarness (HKUDS)、AI Agent Eval Harness、awesome-harness-engineering、KAOS v0.2 (Meta-Harness 落地)

研究机构：Stanford HAI Research、RAND Corporation、McKinsey、Deloitte、MIT

---

在 AI 的喧嚣里，替你找到真正能用的东西。不搬运新闻，不贩卖焦虑。