AJohn Blog

外观

一文带你弄懂 AI 圈爆火的新概念：Harness Engineering

约 5874 字大约 20 分钟

Agent

2026-06-03

在开讲之前，先带大家追个源。

很多人在跟风聊 Harness Engineering，但压根没搞清楚这个词最早是谁提出来的。知道了谁先喊出来的，你就会明白为啥它这次真的能火，而不是又一个换皮概念。

Harness Engineering 最早被正式叫响，是在 2026 年 2 月 5 号的一篇博客里。作者叫 Mitchell Hashimoto——HashiCorp 的创始人，Terraform 和 Vagrant 的作者，一个写了二十年代码的老派工程师。博客标题叫《My AI Adoption Journey》，讲的是他作为一个资深工程师，怎么一步一步从"不信 AI"到"每天让 Agent 替我干活"的心路历程。

他把整个过程拆成了 6 个 Step，其中有几步非常反直觉：

第一步，直接扔掉对话框。 他说一上来别用 ChatGPT 那种聊天界面，要用就用能自主执行任务的 Agent。因为聊天界面会给你一种"我在和 AI 讨论"的幻觉，实际上你啥也没干。Agent 才是真正让 AI 动起来的形态——只有把它放开让它自己执行，你才能真正感知到它的能力边界在哪。

第二步更狠，他强迫自己用 Agent 去重做一部分自己早就手写过的代码。 明明自己两下就能写完的活，非要等 Agent 慢慢磨。他原话说这个过程 "painful"——折磨人。但目的很明确：只有你亲自用 AI 去重做你已经熟得不能再熟的任务，你才能精准校准"它到底哪里行、哪里不行"。

然后到了第五步，他给自己这套做法起了个名字，就叫 Engineer the Harness——打磨这套马具。他给的定义特别简洁：

每当你发现 Agent 犯了一个错误，就花点时间去工程化一个解决方案，让它永远不会再犯同样的错误。

你品品这个思路。绝大多数人遇到 Agent 犯错是怎么办的？骂两句，手动改掉，祈祷下次别再犯。但 Mitchell 不是这么干的——他每次 Agent 犯错，都会停下来问自己：我能不能把这个错误永久性地修到环境里，让它下次在结构上就不可能再犯？

可能是给 AGENTS.md 加一条规则，可能是加一个 linter，可能是补一个自动化测试，也可能是搞一个 Git Hook。关键是：修补必须沉淀到环境里，而不是留在人脑子里。

这套做法的威力在于它是复利的：每一次 Agent 犯错，环境就变强一点；环境变强一点，Agent 下一次就更少犯错；犯错变少，改进速度就更快。时间一长，Harness 越来越坚固，Agent 在你的项目里越跑越稳。

本文从三个角度讲清楚这个概念：

  • Harness 的演进：从 Prompt Engineering 到 Context Engineering 再到 Harness Engineering，AI 工程的重心经历了三次迁移
  • Harness 的构成：一个成熟的 Harness 包含哪些部分，每一层在解决什么问题
  • Harness 的实践：OpenAI、Anthropic 等头部公司怎么在真实产品中落地

一、Harness 的演进

过去两年，AI 工程领域经历了三次重心迁移。表面上是术语更新，但拉长时间线，它们对应着三个越来越本质的问题：

  1. 模型是否听得懂你在说什么？
  2. 模型是否拿到了足够且正确的信息？
  3. 模型是否能在真实执行中持续做对？

1.1 Prompt Engineering：怎么说

大模型刚爆发时，很多人第一次感受到一种近乎魔法的体验——同一个模型，换一种说法，结果天差地别。

你对它说"帮我总结一下这篇文章"，它可能给你一段平平无奇的概述。但如果你说：

请以资深技术编辑的身份，用三段结构总结这篇文章，先讲核心观点，再讲论证方式，最后讲局限性，每段不超过 150 字。

结果会好很多。

Prompt Engineering 的核心思想：模型不是不会，而是你没有把问题讲清楚。一套方法迅速流行起来：

  • 角色设定：先告诉模型"你是谁"，限定专业视角
  • 风格约束：告诉模型"怎么说"，解决的是像不像你要的表达
  • Few-shot 示例：少讲原则，多给样例，模型更擅长模仿范式
  • 分步引导：先拆再想再答，减少拍脑袋式结论
  • 格式约束：提前规定输出长什么样，提升可用性
  • 拒答边界：先划红线再回答，降低"不知道还特别自信"的风险

为什么会有效？

因为大模型本质上是一个对上下文极度敏感的概率生成系统。你给它什么身份，它就沿着那个身份分布去采样；你给它什么例子，它就沿着那个模式补全；你强调什么约束，它就把那部分当成高权重信号。

Prompt Engineering 的本质不是"下命令"，而是塑造局部概率空间。

天花板在哪？

很多任务不是"你说清楚就行"，而是"你得真的知道"。比如：

  • 分析一份公司内部文档
  • 回答某个产品最新配置
  • 对照一套长规范生成代码
  • 在多个工具之间完成复杂任务

提示词再漂亮，也不能替代事实本身。

Prompt 解决的是"表达问题"，不是"信息问题"。 当任务从开放问答进入真实业务，问题的焦点从"怎么说"变成了"给什么"。

1.2 Context Engineering：给什么

如果说 Prompt Engineering 的假设是"模型本来就知道，只是你得问对"，那么 Context Engineering 的假设变成了：模型未必知道，系统必须在调用时把正确的信息送进去。

为什么兴起？

因为使用场景变了。大模型刚流行时，主流形态是聊天——用户提一个问题，模型给一段回答。Prompt 权重很高，因为任务短、链路、状态少。

后来 Agent 爆火，模型被放进真实执行环境：要多轮对话、要调用搜索/浏览器/代码/数据库、要在多个步骤间传递中间结果、要根据外部反馈修正计划、甚至要和其他 Agent 协作。

举个例子，"帮我总结这篇文章"只需要看文章内容。但如果是：

帮我分析这份需求文档，找出潜在风险，结合历史评审意见给出修改建议，并生成一版给产品经理看的反馈稿。

这至少需要：当前需求文档、历史评审记录、相关规范、当前任务目标、之前分析过的中间结论、输出对象和语气调整。模型的上下文窗口是有限的，你必须考虑：有没有把对的信息，以对的形式，在对的时刻，交给模型。

Context 到底是什么？

在工程意义上，Context 不是几段背景资料，而是所有会影响模型当前决策的信息总和：

  • 当前用户输入、历史对话
  • 外部知识检索结果、工具调用返回
  • 当前任务状态、工作记忆与中间产物
  • 系统规则与安全约束、其他 Agent 传来的结果

Prompt 只是 Context 的一部分。 这就是为什么同一个模型、同一个 Prompt，放在不同系统里效果完全不一样——背后的上下文供给机制根本不是一回事。

典型实践：RAG 和 Skills

RAG 回答了一个现实问题：模型参数里没有的知识，怎么在运行时补进去？做法是先从外部知识库检索相关内容，再注入上下文。

但成熟的 Context Engineering 关心的不只是检索，而是整条链路：文档怎么切块、检索结果怎么排序、长文档怎么压缩、历史对话什么时候保留原文什么时候该摘要、工具返回是否全部暴露给模型、多个 Agent 之间传原文还是结构化字段。

Agent Skills 是另一个典型实践。当系统调用工具时，如果把十几个工具的说明、参数定义一次性全塞进上下文，Token 消耗巨大、注意力被分散。Skills 的核心机制是渐进式披露——只在需要时暴露与当前任务相关的部分：

层级内容加载时机Token 开销
元数据层技能名称、触发条件、功能概述启动时全局加载~50
指令层SOP、输入输出规范任务触发时加载~500
资源层脚本、模板、API 文档执行具体步骤时动态调用按需

局限性在哪？

到这里，很多系统已经比纯 Prompt 时代强很多了。但新问题出现了：即便信息是对的，模型也未必稳定执行。它可能：

  • 计划做得好，但执行偏了
  • 调了工具，但误解了结果
  • 中间某一步出错后继续一路错下去
  • 表面很自信，实际任务状态早已失真

Prompt 和 Context 都作用在输入侧。但真实世界的复杂任务还有个更难的问题：当模型开始连续行动时，谁来持续监督它、约束它、纠正它？

1.3 Harness Engineering：怎么管

Harness，本意是"缰绳、马具、约束装置"。放在 AI 系统里，它是一个直白的提醒：

当模型从"回答问题"走向"执行任务"，系统不能只负责喂信息，还必须负责驾驭过程。

如果说前两代工程思路关注的是如何让模型"更会想"，Harness Engineering 关心的是：如何让模型别跑偏、跑得稳、出了错能拉回来。

一个例子看清三者区别

假设你要让一个新人完成一次重要客户拜访：

Prompt Engineering——把任务讲清楚：

见面先寒暄，再介绍方案，再问需求，最后确认下一步。

Context Engineering——把资料准备齐：

客户背景、过往沟通记录、产品报价、竞品情况、会议目标。

Harness Engineering——建立持续监督机制：

让他带着 checklist 去、要求关键节点实时回报、会后核对纪要与录音、出现偏差马上纠正、按明确标准验收结果。

三者的关系

不是替代，而是层层递进：

  • Prompt 是对"提示词"的工程化
  • Context 是对"输入环境"的工程化
  • Harness 是对"整个运行控制系统"的工程化

Prompt 是 Context 的一部分，Context 是 Harness 的一部分。边界一层比一层大，后者天然包含前者。

很多技术趋势看上去像观点之争，实际上是任务复杂度逼出来的：任务简单时 Prompt 就够了；上下文不够用时 Context 成为核心；任务变成持续执行、长链路、低容错时，Harness 几乎不可避免。

二、Harness 的构成

2.1 Harness 到底是什么？

LangChain 工程师给了一个非常精炼的定义：

Agent = Model + Harness
Harness = Agent - Model

简单理解：Harness 是 Agent 中除了模型之外的所有东西。它决定了模型看到什么、能做什么、按什么规则做、做错了怎么纠偏，以及最后如何稳定交付。

理解这一点，很多问题就有了答案：为什么同一个模型在不同产品里表现差距巨大？因为模型的能力上限由 OpenAI、Anthropic 决定，而 Harness 由工程师决定。

一个成熟的 Harness 通常包含六层：

2.2 第一层：上下文管理

模型能力的差异往往不在于"智商"，而在于它看到了什么信息。Harness 的第一职责是让模型在正确的信息边界内思考。

  • 角色与目标定义——模型需要先知道自己是谁、任务是什么、成功标准是什么。同样是"写一篇文章"，技术科普还是产品宣传？面向小白还是工程师？追求传播性还是严谨性？这些不是文风细节，而是任务边界。

  • 信息选择与裁剪——上下文不是越多越好。常见问题不是"知道太少"而是"信息太杂"。好的 Harness 会把相关的信息挑出来，不相关的挡在外面。

  • 上下文结构化组织——同样的信息堆成一团和按层次组织，效果天差地别：

2.3 第二层：工具系统

没有工具，大模型只能做文本预测。接上工具后，模型可以搜网页、读文档、写代码并执行、调用 API、操作浏览器、生成图片。

Harness 在这里解决三个问题：

  • 给模型什么工具——工具太少能力不够，太多模型容易乱用。写作 Agent 和安全分析 Agent 应该拥有完全不同的工具集。

  • 什么时候调用工具——比"有什么工具"更重要。糟糕的 Agent 会出现两种极端：本来不需要查非要查，明明该查证却凭印象乱答。

  • 如何把工具结果喂回模型——工具不是一调用就结束。搜索到十条结果不应该原封不动塞回去，Harness 需要帮助模型提炼有效证据。

2.4 第三层：执行编排

很多失败的 Agent 不是不会某一步，而是不会"串起来"。它可能会搜索、也会总结、也会写代码，但整个过程像想到哪做到哪，最后输出一堆半成品。

执行编排就是把任务拆成明确的流程：理解目标 → 判断信息是否足够 → 必要时获取外部信息 → 基于结果分析 → 生成输出 → 检查是否满足要求 → 不满足则修正重试。

成熟 Harness 的执行编排包含：步骤划分、决策节点、中间产物、终止条件、异常处理逻辑。

2.5 第四层：状态与记忆

没有状态的系统每一轮都像失忆——不知道自己刚做了什么，哪些结论已确认，哪些问题没解决。

Harness 的状态管理要回答三个问题：

  • 当前任务进行到哪一步？ 已完成资料收集、正在撰写提纲、已生成初稿待校验。这会让系统避免反复横跳。

  • 哪些中间结果应该保留？ 已确认的需求约束、重要结论、已筛选的资料、已完成的子任务。

  • 哪些内容应该形成长期记忆？ 用户偏好、稳定规则、长期项目背景。记忆要区分：临时状态、会话记忆、长期偏好。混在一起系统会越来越乱。

2.6 第五层：评估与观测

很多系统的问题不是"生成不出来"，而是"生成完了却不知道好不好"。没有独立评估，Agent 容易停留在"自我感觉良好"。

这一层包括：输出验收（是否满足要求）、环境验证（是否真的可运行）、自动测试（代码/接口/页面）、过程观测（日志/指标/调用链）、质量归因（问题出在模型、上下文、工具还是流程）。

2.7 第六层：约束、校验与失败恢复

真正让系统从"能跑"走向"能上线"的，往往不是主流程而是异常流程。真实环境里失败才是常态：搜索不准、API 超时、文档格式混乱、模型误解指令、输出不符合约束。

Harness 的最后一层：

  • 约束：限制模型可做和不可做的事
  • 校验：输出前检查是否回答了问题、是否遗漏关键要求、是否满足格式规范
  • 恢复：一步失败时分析原因、重试、切换备用路径、回退到上一个稳定状态

这部分最像传统软件工程里的"鲁棒性设计"。

三、Harness 的实践

各大头部公司纷纷发布了 Harness 的工程实践，来看三个最典型的案例：

公司实践核心成果
OpenAI几名工程师 + Codex 智能体，从零构建超百万行生产级应用100% 由 Agent 编写，耗时仅人工的 1/10
Anthropic长程自主编码系统，一句需求连续运行数小时端到端交付 2D 游戏制作工具、浏览器端数字音频工作站
LangChain模型不变，仅改造 HarnessTerminal Bench 2.0 得分从 52.8 提升到 66.5，Top 30 开外杀入 Top 5

同样是调用大模型 API，加上精心设计的 Harness 为什么能产生如此大的质变？

3.1 Anthropic 的实践

两个典型失败模式

上下文焦虑：任务一长，上下文窗口越来越满，模型开始丢细节、丢重点。甚至出现一个有趣现象——当模型接近上下文极限时，它会"焦虑"地想赶紧收尾，仿佛知道自己快装不下了。

自评失真：模型做完后自己评判，往往偏乐观，尤其在设计、体验、产品完整度这类没有绝对二元答案的问题上更明显。

实践一：上下文重置

很多系统在上下文变长后做 Compaction（压缩历史继续跑）。Anthropic 的思路是做 Context Reset（换一个干净上下文的新 Agent，交班时把工作交接清楚）。

  • Compaction：同一个 Agent，历史变短了，但"心理状态"还延续着
  • Reset：全新 Agent，清空包袱重新出发

Anthropic 发现对某些模型（如 Claude Sonnet 4.5），压缩不能解决上下文焦虑，真正的 Reset 才行。这很像工程里的进程重启——不是所有内存泄漏都能靠清理缓存解决，有时候就得重启进程。

实践二：引入评估者

Anthropic 说得很直白：让模型评估自己的产出时，它往往会"自信地夸自己"。

解法：把"干活的人"和"打分的人"拆开——generator + evaluator，后来扩展成 planner + generator + evaluator。

  • Planner：把一句短需求扩展成完整产品规格
  • Generator：逐步实现
  • Evaluator：像 QA 一样，用浏览器真实操作应用，检查功能、设计、代码质量

关键在于 Evaluator 不是"读代码打分"，而是带环境的验证——实际操作页面、跑交互、看结果。一旦 Evaluator 能独立测试并保证公平性，系统就实现了"生成—检查—修复"的工程循环。

3.2 OpenAI 的实践

重新定义"工程师"

这个团队从第一天定了一条铁律：人类不写代码，只设计环境。工程师的核心工作变成三件事：

  • 拆解意图：把产品目标拆成 Agent 能理解的小块任务
  • 补全能力：Agent 失败时，不是"再试一次"，而是问"环境里缺了什么让它失败了"，然后补上
  • 建立反馈回路：让 Agent 能看到自己工作的结果

用他们的话说：当出了问题，修复方案几乎从来不是"更努力"，而是"缺了什么结构性的能力"。

渐进式披露

早期他们犯了一个经典错误：写了一个巨大的 AGENTS.md，把所有规范一股脑塞进去。结果 Agent 反而更迷糊了。

最终方案优雅得多——AGENTS.md 只有 ~100 行，充当目录页：

AGENTS.md          ← 入口，只有指针
ARCHITECTURE.md    ← 架构总览
docs/
├── design-docs/   ← 设计文档（带验证状态）
├── exec-plans/    ← 执行计划（活跃/已完成/技术债务）
├── product-specs/ ← 产品规格
├── references/    ← 第三方参考
├── QUALITY_SCORE.md ← 各模块质量评分
└── SECURITY.md

Agent 先看到目录，需要深入时再去查对应文档。这是不是看着很熟悉？就是 Skills 的核心机制：渐进式披露。

更关键的是，他们用 CI 自动校验文档新鲜度，还有一个专门的"文档园丁" Agent 定期扫描过时文档并提 PR 修复。知识管理本身也自动化了。

让 Agent "看见"整个应用

代码产出速度上去后，瓶颈从"写"变成了"验"——人类根本验不过来。OpenAI 的解法：让 Agent 自己验。

结果：单次 Codex 运行经常连续工作 6 小时以上，通常在人类睡觉的时候。Agent 自己跑应用、发现 bug、修复、验证、提 PR，一条龙。

把架构约束写进系统

人类 Code Review 的带宽跟不上 Agent 的产出速度（每人每天 3.5 个 PR）。怎么保证质量？

答案：把资深程序员的经验判断写成机器可自动执行的检查规则。

比如按固定分层组织业务代码（Types → Config → Repo → Service → Runtime → UI），检查结果本身带着修复提示，可以直接回到上下文推动下一轮修改。

代码质量不再靠人盯，而是靠一套能反复执行的规则来守住。此外还有后台 Agent 定期扫描代码库：检查哪些模块在变乱、给不同区域打质量分、找出值得重构的部分、直接提交修复 PR。

3.3 他们做的其实是同一件事

把前面的案例放回 Harness 框架，OpenAI 和 Anthropic 看似路径不同，本质上都在补同一套东西：

Harness 层Anthropic 的做法OpenAI 的做法
上下文管理Context Reset，清空包袱重新出发渐进式披露，AGENTS.md 做目录页
工具系统浏览器 + 工具做真实验证给 Agent 完整开发环境
执行编排Planner → Generator → Evaluator拆解意图 → 补全能力 → 反馈回路
评估与观测独立 Evaluator 带环境验证CI 自动校验 + 后台扫描
约束与恢复生产与验收分离架构规则写进系统自动检查

把模型从一个会回答问题的概率机器，变成一个能稳定完成任务的工程系统——这就是 Harness 的意义。

最后

回头看三次演进，不是谁取代了谁，而是 AI 工程在面对更复杂任务时，重心一层层向外扩展：

  • 任务停留在单轮生成时，Prompt Engineering 很重要
  • 任务依赖外部知识和运行时信息时，Context Engineering 成为关键
  • 模型进入长链路、可执行、低容错的真实环境后，Harness Engineering 几乎不可避免

Prompt 没有过时，Context 也不是终点。它们都还在，而且都很重要。

只是越往后我们越会意识到：真正决定 AI 产品上限的也许是模型，但决定 AI 产品能否落地、能否稳定交付的，往往是 Harness。

未来 AI 工程的竞争，未必是"谁接入了更强的模型"，而更可能是谁更早建立起一套成熟的运行系统——它知道该给模型看什么、允许模型做什么、要求模型如何验收结果、又在失败时如何把它拉回正轨。

Harness Engineering 不是新瓶装旧酒。它更像是一个信号：AI 落地的核心挑战，正在从"让模型显得聪明"，转向"让模型在真实世界里稳定工作"。

参考资料