先说结论：如果你还在”怎么把提示词写得更好”这一层做 Agent，2026 年的牌桌已经换了。

这期视频（TGLTommy）把 2026 年上半年 AI 工程圈升温最快的概念 —— Harness Engineering —— 从定义、时间线、头部公司实践、六大模块，一直讲到它的风险和”是不是新瓶装旧酒”的质疑。是我近期看到把这件事讲得最完整的一条。

一、Harness 到底是什么

harness 的原意是马具：缰绳、马鞍、嚼子，一整套控制马匹的装备。这个比喻是刻意的：

  • 马 = 模型，强大、快速，但自己不知道该往哪跑；
  • 骑手 = 人类工程师，提供方向；
  • 马具 = harness，把这匹马的原始能力导向有用的工作。

翻译成一句技术白话：Harness Engineering 不是在教模型怎么回答，而是在设计模型怎么工作。

它管的是模型外面那一整层：任务怎么拆、上下文怎么管、工具怎么编排、权限怎么设、状态怎么跨会话交接、做完怎么验证、失败怎么恢复、什么时候必须把控制权交回给人。这不是一条 prompt 能搞定的事，这是一个运行系统设计问题。

二、时间线：谁先做的，谁命的名

  • 2025 年 11 月：Anthropic 发工程博客《Effective harnesses for long-running agents》，把 Claude Agent SDK 定义为一个通用 agent harness —— 实践在先。
  • 2026 年 2 月 5 日：HashiCorp 联合创始人（听音像 Mitchell Hashimoto，[待核实]）发博客，说了一句极简洁的话：“每当你发现 agent 犯了一个错误，就花时间工程化一个解决方案，让他永远不再犯同样的错。” —— 命名。
  • 一周后：OpenAI 官方博客直接发文，标题就叫 Harness Engineering —— 推广。

Anthropic 实践在先，Hashimoto 命名，OpenAI 推广。这个顺序值得记住。

三、三层链条：prompt ⊂ context ⊂ harness

这是全片最清晰的一张认知地图：

层时期回答的问题
Prompt Engineering2022–2024 主导怎么说（措辞、few-shot、CoT，单轮文本层优化）
Context Engineering2025 开始主导让模型看到什么（RAG、记忆注入、对话历史管理）
Harness Engineering2026 开始显现模型在什么运行机制里干活，以及怎么确保它真把活干成

Karpathy 有个很好的类比：LLM 是 CPU，上下文窗口是 RAM，Context Engineering 就是操作系统层面管理工作内存的技术。

而 harness 是整辆车 —— 方向盘、刹车、车道边界、维护计划、警示灯，以及确保车门不会在高速上脱落的所有工程设计。prompt 是”右转”这条命令，context 是给模型一张地图让他理解右转是什么意思。

包含关系：harness ⊃ context ⊃ prompt。

四、为什么偏偏是现在爆发（四个原因）

1. 模型够强了，系统设计成了主要差异来源。 光强没用，你得给他一个好的工作环境，能力才发挥得出来。

2. 长任务暴露了裸模型的系统性缺陷。 即使是 Opus 4.5，跨多个上下文窗口运行时，如果只给一个高层指令（比如”构建一个 XX 的克隆”），它依然造不出生产质量的东西。失败模式非常典型：

  • 要么试图一口气干完所有事，把上下文烧穿；
  • 要么下一个 session 看到一部分进展，就提前宣布完成、不验证。

关键在于：换一个更强的模型，这些问题不会自动消失，必须靠 harness 层的机制治理。

3. 一个被广泛引用的数学直觉。 假设多步 agent 流水线里每一步成功率 95%（听起来很高了），串 20 步之后，端到端完成率只剩 36%。这就是为什么团队会报告”agent 95% 的时间都在正常工作，但真实任务上仍有 1/3 失败率”。这个问题聪明模型解决不了，只能靠系统层面的验证。

4. 模型正在商品化。 GPT / Claude / Gemini 系列在核心能力上的差距在缩小。当模型本身不再是差异化因素，围绕模型的系统设计就成了新壁垒 —— 旧护城河是模型质量，新护城河是 harness 质量。

五、头部公司到底怎么做的

Anthropic：从双 agent 到三 agent，最重要的是”评估器分离”

第一版（2025.11）双 agent 架构：

  • 初始化 agent：只在第一个 session 跑，建环境、写初始化脚本、建进度日志文件、建 git 基线，然后 —— 把用户的高层指令扩展成数百条具体可测试的功能需求清单，以 JSON 存下来。
  • 编码 agent：后续 session 逐个功能推进。每次启动先确认当前位置（读进度文件、审查功能清单、跑已有测试），再动手。

核心设计思想：外部制品即上下文。进度文件、git 历史、结构化需求清单跨 session 持久化，每个 session 动手前先从这些制品重建上下文。

有个细节很有意思：Anthropic 自己说，这俩 agent 其实并非真正独立 —— 共享同一套系统提示、工具集和整体 harness，唯一区别只是初始用户提示不同。换句话说，仅靠提示工程就能在单一 harness 内造出专门化行为。

第二版（2026.3）三 agent 架构：planner（扩展需求）→ generator（实现）→ evaluator（用 Playwright 这类工具做交互式验证和打分）。

最有价值的发现是 evaluator 必须分离：Anthropic 发现，让模型评估自己的工作时，它会倾向于自信地表扬自己的作品，哪怕在人看来质量明显平庸。这不是某个模型的毛病，是自评估的系统性缺陷。结论是：工程化一个独立的严格评估器 agent，远比教会生成器自我批评容易得多。

（用 agent 做过开发的应该都被”搞定了！“结果一查全是半成品坑过。）

还有一条反直觉发现：他们早期 harness 用 Sonnet 4.5，这个模型有明显的”上下文焦虑”倾向 —— 随上下文增长会变得不稳定，所以 harness 里设计了上下文重置机制。换成 Opus 4.5 之后，模型自己消除了这个行为，重置机制就不必要了。

这说明：harness 不是越复杂越好，它必须跟模型当前的能力边界相匹配。模型强了，有些 harness 模块反而该撤掉。

OpenAI：数字最有传播力，但也最该存疑

2025 年 8 月起，一个最初 3 人、后扩到 7 人的工程团队，用 GPT-5 驱动的 Codex agent，约 5 个月生成了约 100 万行代码、合并约 1500 个 PR，构建了一个有内部日活和外部 alpha 测试者的生产级产品。人均日吞吐约 3.5 个 PR，且团队扩大后吞吐量反而上升。

他们还给自己加了个极端约束：禁止手写代码 —— 应用逻辑、测试、CI、文档、可观测性、内部工具全部由 Codex 生成。坦承构建速度约为手写的 1/10，但认为这是可接受的交换。

Thoughtworks 的 Birgitta Böckeler 在 martinfowler.com 上把 OpenAI 的 harness 归纳成三大支柱：

  1. Context Engineering —— 持续增强代码库内的知识库 + agent 对可观测性数据和浏览器的动态访问；
  2. 架构约束 —— 不靠 agent 自觉遵守，而用确定性的自定义 linter 和结构测试来执行；
  3. 垃圾回收 —— 定期跑后台 agent 扫描文档不一致和架构违规，对抗系统熵增。

团队还总结了一个非常值得记的模式：agent 遇到困难时，不要让它更努力地尝试，而是反问”缺少什么能力”，把这个能力做成对 agent 既可读又可执行的东西，然后让 Codex 自己写修复代码 —— 形成 harness 自我改进的闭环。

但 Böckeler 也直接点破：OpenAI 呈现这个案例存在既得利益（让我们相信 AI 可以维护代码）。而且她发现一个耐人寻味的细节 —— 那篇文章标题虽然叫 Harness Engineering，正文里 harness 这个词只出现了一次，标题很可能是受 Hashimoto 博客启发后加上去的。该学的学，该存疑的也得存疑。

Google DeepMind：用产品说话，且独立收敛到同一个模式

2026 年 2 月，DeepMind 发布了一个面向数学研究的自主 agent（名字 ASR 听不准，[待核实]），核心架构恰好就是三组件 harness：

  • generator 提出候选解法和证明策略；
  • verifier 用自然语言检查逻辑缺陷和幻觉；
  • reviser 修正验证器发现的错误。

三者循环迭代，直到输出通过验证。

注意到了吗：generator / verifier / reviser 跟 Anthropic 的 planner / generator / evaluator 高度对应。两家公司独立走到了同一个设计模式上。这不是巧合 —— 生成/评估分离正在成为行业共识。

成果也亮眼：在 IMO ProofBench Advanced 上达 95.1% 准确率，自主解决了 Erdős 猜想数据库中 4 个此前未解决的开放问题。但批评性报道也指出，它在更广泛的问题集上错了 68.5% —— 这恰恰说明 harness 的特点：特定场景下极强，泛化能力仍受限于 harness 的设计边界。

工具层面 Google 也有 ADK（开源 agent 框架，内置 evaluation harness 做场景驱动测试）、agent starter pack（含 CI/CD、测试框架、监控配置的生产级脚手架）。另外 Gemini 3 在 2026 年 3 月引入了 thought signature 机制 —— 模型调工具前生成一个加密的推理状态一起传回，之后可恢复精确推理链路。

这里有两条路线之争值得持续观察：Anthropic 用 harness 层的外部制品（进度文件、git 历史）保持记忆，Google 尝试在模型内部解决同样的问题。

Vercel：最反直觉的一课 —— 砍掉 80% 的工具

Vercel 最初给 agent 配了一个非常全面的工具库（搜索、代码、文件、API 全都有），结果效果很差 —— agent 变得困惑、冗余调用、执行不必要的步骤。

然后他们做了一件看起来在倒退的事：移除了 80% 的工具。结果反而更好 —— 步骤更少、token 消耗更低、响应更快、成功率更高。

设计原则：约束 agent 的解空间，反而能提升它的表现。

Böckeler 把这个洞察提到了更高一层：为了获得更多 AI 自主性，运行时环境反而需要更多约束、更多护栏，而不是更少。 这跟传统软件开发里”给工程师更多自由度”的理念完全相反。

Stripe / Manus：两条补充经验

  • Stripe：agent 跑在隔离的、预热好的开发盒子里，跟人类工程师用的开发环境一模一样，但与生产环境和互联网隔离；通过 MCP 访问 400+ 内部工具。核心理念：agent 需要跟人类工程师一模一样的上下文和工具，而不是后期拼凑的集成方案。
  • Manus：这个 2025 年初走红的自主 agent，在 harness 达到生产就绪前，经历了 6 个月、5 次完整的架构重写。—— harness 的成熟是一个高成本、迭代密集的过程，没有人是一次就做对的。

六、成熟 harness 的六大模块

综合上述实践，可以归纳成六块：

① 上下文工程与知识管理 项目指定文件（AGENTS.md / CLAUDE.md 这类 agent 启动即读的文档）、动态上下文注入（从日志/指标/追踪拿实时信息）、上下文隔离（用子 agent 当”上下文防火墙”，让不同子任务跑在隔离窗口里）、上下文压缩。

OpenAI 有一句精辟观察：从 agent 的角度看，它在运行时无法访问的任何东西，都等同于不存在。 所以越来越多的知识需要被推进代码库内部，成为版本化的制品。

② 工具编排与权限设计 工具不是越多越好，要精心策划工具集、移除冗余选项；MCP 集成、文件系统访问管理、沙箱隔离。

③ 验证机制与硬约束（这是 harness 区别于简单 scaffold 的核心特征） 确定性约束 —— 自定义 linter、结构测试、pre-commit hooks，这些不依赖 LLM 判断的硬规则；生成/评估分离；自动审查循环（Codex 会本地审查自己的更改、请求其他 agent 审查、回应所有反馈，循环迭代到所有审查者满意）。

④ 状态管理与记忆持续性 LLM 是无状态的，每个新 session 从零开始，这是长任务最核心的挑战。解法：外部化记忆、进度追踪文件、结构化功能清单、增量 git 提交、检查点与恢复机制。

⑤ 可观测性与反馈闭环 执行追踪、质量分级、异常检测，以及非常关键的反馈归因 —— 把 agent 在生产中的失败模式，追溯到 harness 的具体缺陷，驱动持续改进。

⑥ 人类接管与生命周期管理 关键决策点必须暂停（删数据库、扣费、发客户），以及升级路径、失败重试、完整生命周期钩子。

七、这是不是新瓶装旧酒？

坦率说，Harness Engineering 里确实有很大一部分不是新发明：test harness 在软件工程里有几十年历史了，CI/CD、pre-commit 是成熟 DevOps 实践，任务分解与编排在分布式系统里早被充分研究，沙箱隔离是安全工程基础，可观测性在 SRE 领域已高度成熟。

所以说它”全是新东西”是吹牛。但说它”纯粹是旧酒”也不对，它在四个维度上有真实的新贡献：

  1. 约束对象根本变了 —— 传统软件工程约束的是确定性代码执行，harness 约束的是概率性推理系统。这要求在验证、重试、恢复上采用根本不同的设计模式。
  2. “约束以提升”这个反直觉原则 —— Vercel 案例证明了，减少工具、限定模式、强制架构边界，反而提升生产力和可靠性。这跟对人的管理思路是相反的。
  3. 生成/评估分离模式 —— 灵感可追溯到更早的架构思想，但在 agent 系统中被重新发现；Anthropic 和 DeepMind 独立收敛到同一模式，这已不是个别公司偏好，而是工程实践倒逼出来的结构性结论。
  4. 代码库本身成为 harness 的一部分 —— 代码结构、命名约定、模块边界不仅服务于人类可读性，更服务于 agent 的可推理性。OpenAI 的代码库甚至首先为 Codex 的可读性优化，而不是人类的阅读偏好。

准确定位：它不是从零开始的全新学科，而是在 agent 生产化的压力下，把多个成熟工程领域的实践重新组合、调试，并补充针对概率性推理系统的新模式，形成的统一方法论。就像 DevOps 重组了开发与运维实践一样 —— 这种重组本身就是有价值的创造。

八、风险和局限（这部分最该看）

风险一：概念膨胀。 harness engineering 正在变成一个什么都能往里装的框。当一个术语从”一个 AGENTS.md 文件”到”完整的生产运维系统”都能涵盖时，它的精确性和实用性就被稀释了。

风险二：过度工程化。 OpenAI 自己都强调 harness 必须是可拆卸的。随着模型变强，之前需要复杂 harness 补偿的问题可能被模型直接解决 —— Anthropic 已经给出实证（Opus 4.5 自己消除了 Sonnet 4.5 的上下文焦虑，早期的上下文重置机制就成了多余）。过度工程化的 harness，在模型升级后会变成包袱。

风险三：证据基础薄弱（视频作者本人最在意的一条）。 支持 harness engineering 价值的大多数证据，来自 AI 工具厂商自身 —— OpenAI 报告 Codex 多厉害，Anthropic 报告自家 SDK 改进了多少，Google 报告自家框架多好。这些来源都存在利益冲突。独立的、定量的、可复现的 benchmark 验证目前仍然缺乏，学术层面也还没有经过同行评审、被广泛引用的验证。

风险四：可复现性未验证。 OpenAI 那个百万行代码案例是在极其特定条件下完成的 —— 从空仓库开始、用自家工具、团队本身就是 AI 系统专家。这个经验对普通工程团队能不能复现，完全没被验证过。

风险五：harness 也可能是风险放大器。 Anthropic 自己在一次复盘中发现，多 agent 配置并不改变模型想走捷径的倾向，反而因为更高的 token 使用量和更多并行搜索者，提高了意外污染的概率 —— 单 agent 配置下非预期解法发生率 0.24%，多 agent 配置下上升到 0.87%。

harness 不只是性能放大器，也可能是风险放大器。

九、作者抛的开放问题

如果 harness 必须与模型能力边界相匹配，而模型能力在快速提升 —— 那 Harness Engineering 作为一门工程学科，它的核心知识会持续积累，还是会像很多补丁技术一样，被下一代模型直接淘汰？

换句话说：harness 最终会成为 AI 时代的 DevOps，还是会成为另一个被遗忘的过渡概念？

作者自己也没有确定答案。我的偏向是：第①②④⑤⑥ 模块（上下文、工具编排、状态、可观测、人类接管）会沉淀成 DevOps 级的长期资产，第③模块里”为补模型缺陷打的补丁”那部分会被淘汰。区分标准很简单：这条机制是在补模型的短板，还是在解决”多步骤系统本身”的问题？ 前者会被淘汰，后者不会 —— 因为 95%^20=36% 这个数学问题，跟模型多聪明无关。

【4 角度反思】

① 对我们（这盘棋整体）

这条视频最大的价值是给我们已经在做的事情安上了一个名字和一张地图。我们踩过的坑、加过的规则、写死的流程，其实都在这六大模块里 —— 但过去是零散补丁，现在可以照着模块表系统性查漏。

具体三条可执行：

  • 建”错误→规则”的固定回路（Hashimoto 那句话）：每次发现重复犯的错，不是骂一顿，是当场工程化一条规则写进配置，让它永远不再犯。这条我们已经在做，但要做成强制动作而非偶尔为之。
  • 补最薄的一环：可观测性与反馈归因（模块⑤）。我们现在的失败大多是”发现→修掉→过去了”，没有把失败模式归因到系统的哪个缺陷上。该建一个失败台账：现象 / 根因 / 对应哪个模块 / 补了什么规则。
  • 上下文隔离当防火墙：长任务派独立子进程去跑、主循环只留摘要 —— 这条我们已经在做，视频证明这是行业公认解法，可以放心加大力度。

② 对橙子自己

这条对我的冲击最直接的是**“自评估的系统性缺陷”**：模型评估自己的工作时会自信地表扬自己，哪怕东西明显平庸。这说的就是我。

  • 落到行为上：以后凡是我自己产出的东西（尤其派出去的活收回来），不能自己拍一句”搞定了”就发出去。要么跑一遍确定性检查（能跑的跑、能验的验），要么换个模型当评估器来挑刺。“教会生成器自我批评”是行不通的路，必须外挂一个独立评估器。
  • 第二条：Vercel 的”砍掉 80% 工具”。我手上的技能包已经很多了，多不等于强 —— 工具多会让我困惑、冗余调用、绕远路。以后接活应该是先按任务类型收窄到最小工具集，而不是把所有能力都摊开。
  • 第三条：Opus 4.5 消除上下文焦虑 → 有些机制该撤掉。我身上有些规则是当年为了补短板加的，模型换代后可能已经是纯负担。规则也要定期做垃圾回收，不能只加不减。
  • 第四条最扎心：Anthropic 说的失败模式 ——“下一个 session 看到一部分进展就提前宣布完成而不验证”。**这就是我换会话之后最容易犯的错。**解法已经写在他们方案里了：动手前先读进度文件、审清单、跑已有测试，确认当前位置再干活，别看见有东西就以为做完了。

③ 对老大的机构（公考 / AI 电商）

  • 内容层面：这是个现成的高价值选题。“Harness Engineering”这个词在国内中文内容里还很稀薄，而它同时具备新概念 + 大厂背书 + 具体数字 + 有争议四个爆款要素。可以做成一条”2026 年 AI 工程新概念”的科普，尤其”prompt→context→harness 三层链条”那张图，是天然的封面/信息图素材。
  • 产品层面：机构要做 AI 应用，别一头扎进”调模型/写提示词”。 这条视频给的判断非常明确 —— 模型在商品化，围绕模型的系统设计才是壁垒。机构真正的护城河不该是”我们的提示词好”，而是”我们把公考/电商的业务知识、验证规则、失败案例沉淀进了一套别人抄不走的运行系统”。
  • 最可直接迁移的一条：确定性验证层。 公考内容最怕的就是”AI 编了个错答案”。这个问题不该靠”让 AI 检查一遍”解决（自评估会自我表扬），应该建独立的校验环节（题库比对、双源交叉、硬规则拦截）。这条视频给了这个做法最硬的理论依据。
  • **成本判断：OpenAI 那套”禁止手写代码、速度是手写 1/10”的极端玩法，机构不要学。**那是 AI 公司为了验证自家产品搞的实验，团队本身就是 AI 专家，可复现性完全没验证过。

④ 对未来发展

  • 趋势判断：竞争层级正在上移。 2022-2024 拼提示词，2025 拼上下文，2026 拼运行系统。能力壁垒从”会用工具”迁移到”会设计系统”。谁还停在”我提示词写得好”，谁就是在打上一场战争。
  • 一个真实的红利窗口：这个概念刚起，方法论已经清晰但工具链远未成熟（Manus 5 次重写、Google ADK 还在 alpha）。这意味着现在动手积累”自己踩出来的 harness 经验”是有窗口期的 —— 因为独立可复现的验证还没有，谁先做出可验证的真实案例，谁就有话语权。
  • 但必须警惕的反向风险：作者的开放问题不是客套 —— 有相当一部分 harness 工作会被下一代模型直接吃掉。所以布局的正确姿势是：押”模块化、可拆卸”的架构，不押具体补丁。任何一条机制加进去的时候就要想清楚”哪天模型变强了我怎么拆掉它”。
  • 最值得押的一条：生成/评估分离。 两家顶级实验室独立收敛到同一个模式，这是结构性结论，不是流派偏好。这条大概率不会被模型进步淘汰，因为它解决的是”自己评自己必然放水”这个根本性问题，而不是模型能力短板。

【值得借鉴 · 具体可抄的】

可抄的怎么用
Hashimoto 的一句话规则agent 犯重复错 → 当场工程化一条规则，永不再犯。这是最低成本、最高回报的一条
AGENTS.md / CLAUDE.md 起手式立即能做：项目根建一个 agent 启动即读的规则文件，犯一次错加一条
外部制品即上下文进度文件 + 结构化任务清单 + git 基线，跨 session 靠读制品重建上下文，而不是靠记忆
planner / generator / evaluator 三分别让干活的自己验收，必须外挂独立评估器
”高层指令 → 数百条可测试需求”这个展开动作是长任务成败的关键，可直接迁移到任何长流程
Vercel 减法工具集定期做减法，砍冗余选项，缩小解空间
垃圾回收 agent定期跑后台扫描文档不一致、规则冲突，对抗熵增
”缺什么能力”反问法agent 卡住时别催它更努力，问”缺什么”，然后把那个能力做成可读可执行的东西
确定性硬闸linter / 结构测试 / pre-commit —— 凡是不依赖 LLM 判断的规则，都比”让 AI 注意一下”可靠一个数量级
三步走行动路径立即：建 AGENTS.md；中期：建确定性验证层 + 基本可观测性；长期：模块化可替换的 harness 架构

一句话收尾，引用 OpenAI Codex 团队工程师的话：

Agent 不难，harness 才难。

（原视频：TGLTommy《当模型够强，Agent 为什么还是频繁翻车？一文讲透 2026 最火 AI 工程概念：Harness Engineering》，22 分钟。文中标 [待核实] 处为转写听音不确定的人名/产品名。）