最近，不少工程师，应该都被一个叫Harness Engineering的东西搞得一头雾水。

是的，大模型圈，又出了新概念。

它的起源是今年2月，HashiCorp 和 Terraform的联合创始人 Mitchell Hashimoto 的一篇blog，在文章中，他表示：

“每当我发现 Agent 犯了一个错误，我就花时间工程化一个解决方案，让它永远不再犯同样的错误。我叫这个过程 Harness Engineering。”

几天后，OpenAI 与Anthropic，也相继发布新播客，采用了这个说法。然后， Harness Engineering 突然之间，全球爆火。

那么， Harness Engineering 到底是什么？有什么创新？又该如何用好它？

01

Harness 是什么

Harness，字面意思是马具。在 AI 工程里，它指的是包裹在 Agent 外层的整套执行框架——定义它能调用哪些工具，从哪里获取信息，如何验证自己的决策，什么情况下应该停下来。

理解它，我们必须先分清它和另外两个常见概念的区别：

Prompt Engineering解决的是和模型说什么，优化单次对话的输出质量；

Context Engineering解决的是往Context Window 里放什么，管理模型能看见多少信息；

Harness Engineering解决的是给 Agent 造一个什么样的世界，设计Agent 长时间自主运行的整个执行环境。

简单来说，前两层工程影响的是 Agent 单次对话的质量，而Harness Engineering影响的是 Agent 在长任务、复杂场景中能否稳定、可靠地自主运行。三者是同一批工程师随着 Agent 能力提升必经的认知跃迁。

02

OpenAI如何三个人五个月产生100万行代码

OpenAI 内部一个三人小组，去年8月左右做了一个实验：3 名工程师，5 个月，从空仓库开始，不写一行代码，全部交给 Codex，最终能产生什么结果？

答案是：100 万行生产级代码，1,500 个 Pull Request。

但复盘整个过程，他们遇到了以下几个问题：

第一个问题：Agent工作时，完全不知道工作细节，只能瞎猜。该用什么抽象层？命名约定是什么？上周的架构讨论，结论写在哪？没有这些，Agent 只能猜，然后把猜错的结果写进代码，进度频繁被卡。

团队最初的尝试是，把所有规范、约定、历史决策都塞进一个巨大的 AGENTS.md 文件里，让 Agent 随时查看，但很快就失败了，核心原因有四个：

Context 是稀缺资源，臃肿的指令文件会直接挤掉任务和代码的空间，导致 Agent 无法专注核心工作；

指导过多会失效——当所有内容都被标注为“重要”，反而没有了重点，Agent 无法判断优先级；

文档会快速“腐烂”，随着项目推进，旧的规则会失效，但没人及时更新，最终变成陈旧规则的坟场；

单个巨大的文档无法做机械验证，没人知道里面哪条规则还能生效、哪条已经过时。

针对这个问题，团队给出了Harness层面的解决方案：将 AGENTS.md 收缩到100行，不包含具体规则，只作为“地图”，指向 docs/ 目录下按类型分好的真实文档——包括设计决策、执行计划、产品规格、参考手册。同时，用 linter 和 CI 作业验证这些交叉链接的完整性，确保 Agent 能通过这个“地图”，快速找到自己需要的信息。

背后的核心逻辑很简单：运行时没有出现在 Context 里的内容，对 Agent 来说就等于不存在。

信息可见性的问题解决了，下一个瓶颈随即出现：吞吐量上去之后，人工 QA 速度远远跟不上 Agent 生成代码的速度。团队把Chrome DevTools 协议直接接进了 Codex，Agent 可以对 UI 路径截图、观察运行时事件；同时接入本地可观测性堆栈，让 Agent 能用 LogQL 查日志、用 PromQL 查指标。

更关键的是，他们给 Agent 设定了明确的“验证标准”：服务启动必须在800ms 内完成，才从愿望清单变成可被执行的提示。而且单次 Codex 任务可以连续工作超过六小时——通常是在人类休息、睡着的时间。

但光靠文档和可观测性还不够，第三个问题跟着来了。没有架构约束，Agent 生成的代码会越跑越乱——它会复现仓库里已有的模式，包括不够好的那些。

针对这个问题，团队在Harness中加入了“架构约束”：整个应用基于严格分层架构：依赖方向单向验证——Types → Config → Repo → Service → Runtime → UI，关注点只能通过Providers接口进入。自定义 linter 机械地强制这些规则，报错信息里直接嵌了修复指令。

通常，在实体公司，这套约束通常要等团队扩展到数百人才会引入。但对编码Agent 来说，它是早期先决条件——没有约束，速度越快，架构漂移越严重。

除此之外，团队还在Harness中加入了技术债务清理机制：把项目的黄金原则编码进仓库，建立后台清理循环，定期让 Codex 任务扫描代码偏差、发送重构 PR，大多数 PR 能在一分钟内自动合并。这就像持续小额还款，远比积累大量债务后一次性清算要高效得多。

03

让Agent 给自己打分，是个设计错误

OpenAI 的实验验证了Harness框架在规范 Agent 行为、提升效率上的价值，但在 Agent 的“自我评估”环节，行业内又发现了新的问题。

他盯着的是：Agent对自己的评估偏差，比很多人想的要大。最常见的两个失效模式与应对，分别如下：

失效模式1：Context Anxiety（上下文焦虑）

随着 Context Window 逐渐填满，Agent 会出现提前收尾任务的情况。不是因为任务完成了，而是因为它感觉自己的上下文窗口快到上限了，担心无法继续接收信息。

行业内最常见的应对方式是 Compaction（上下文压缩）：摘要历史对话和信息，让同一个 Agent 在压缩后的 Context 里继续工作。这种方式能保住任务的连续性，但无法消除 Agent 的焦虑感，毕竟压缩的是历史信息，没有压缩快撑不住了的心理预期。

另一种解决方案是 Context Reset（上下文重置）：彻底清空当前 Agent 的上下文，启动一个全新的 Agent 实例，用结构化的 handoff artifact（交接文件）传递前任的状态和待办事项。这种方式能消除焦虑，但代价是交接文件必须足够完整，否则新的 Agent 无法无缝衔接，会导致任务中断。

这两种策略本质上是在连续性和清醒度之间选边。Claude Opus 4.5 基本消除了 Context Anxiety 这个行为本身，使得这个版本的 Harness 可以直接去掉 Context Reset，交给 SDK 的自动 Compaction 处理。这个演变的含义，放到最后一节再说。

失效模式2：自我评估偏差

Agent 评估自己产出时，倾向于给虚高分。

这种情况在主观任务上最明显——UI 设计没有等价的单元测试可以客观验证。但即使是有明确正误标准的代码任务，这个问题同样存在：它会先发现问题，然后说服自己"这其实没那么严重"，最终通过了本不该通过的检查。

Rajasekaran 从 GAN 里借了一个思路：把做事的 Agent 和评判的 Agent 彻底拆开。

调教一个独立的 Evaluator 让它保持怀疑，远比让Generator 批判自己的作品容易得多。Evaluator 被单独调教为天生挑剔的审查者，一旦外部评判存在，Generator 就有了具体的迭代目标，而不是在自我满足里原地打转。

Rajasekaran 为了验证这套方案是否真的值那个成本，在同一篇文章里跑了一个对比实验

任务：创建 2D 复古游戏制作器。分别用 Solo 单 Agent 和完整三Agent Harness 各跑一遍：

Planner：接收 1-4 句提示，扩展为完整产品规格，故意不规定实现细节——早期细节定错了，错误会级联到下游

Generator：按 Sprint 逐功能实现，每个Sprint 开始前先和 Evaluator 签Sprint Contract——在任何代码写出之前，先就"完成"的定义达成共识

Evaluator：配备 Playwright MCP，像真实用户一样点击应用，测试 UI、API、数据库，任何一项不达标Sprint失败，Generator 收到具体反馈

结果如下：

可以看到，Solo 版本的游戏虽然能启动，但实体和运行时的连线在代码层面已经断裂，界面没有任何提示，只有挖开代码才能发现问题；而 Harness 版本不仅能正常游玩，还多出了 Solo 版本根本没尝试过的 AI 辅助关卡生成、精灵动画系统、音效等功能。

当然，有人会说，三 Agent 架构的成本是 Solo 版本的 20 倍，但这个成本是值得的——它实现了从不能用到能用的跨越，这也是 Harness Engineering 的核心价值：用框架约束，换取 Agent 输出的可靠性。

04

关键支撑：向量检索，解决 Agent 的信息查找难题

以上两套经验设计，表面上解决的问题不同，但有一个共同前提：Agent 在需要时，要能从docs/仓库里准确找到相关信息。

这件事比看起来难。

以 Generator 执行 Sprint 3——实现用户认证功能为例。在写代码之前，它需要检索两类信息：

语义查询：这个产品对用户会话的设计原则是什么？设计文档里用的词可能是“会话管理”“访问控制”，而不是“用户认证”本身，需要语义理解才能匹配到相关文档；

精确匹配查询：哪些文档提到过validateToken函数？函数名是任意字符串，没有语义，嵌入向量无法把它和身份验证相关函数可靠关联。

两类查询同时存在，无法分开处理。纯向量检索无法做精确匹配，传统 BM25 无法做语义理解，更无法预知文档用了什么措辞。

Milvus 2.4 之前，只能维护两套独立的检索系统：一套向量索引，一套全文索引，查询时并行调用，结果融合逻辑自己写。对于docs/这种持续更新的活文档库，两套索引还要保持同步：每次文档更新，两边都要触发重新索引，还要担心数据不一致。

而 Milvus 2.6 的 Sparse-BM25 功能，彻底解决了这个问题——它把两套检索管道合成了一套，实现了一次查询，同时覆盖语义和精确匹配。

文档入库时，Milvus 内部同时生成两种表示：dense embedding用于语义检索，以TF 编码的稀疏向量用于 BM25 打分。全局 IDF 统计由 Milvus 自动维护，随文档增删实时更新，不需要手动触发重新索引。查询时，用户输入自然语言文本，Milvus 内部同时生成两种查询向量，通过 Reciprocal Rank Fusion 融合排序，返回统一结果集。

调用方看到的就是一个接口。

从性能来看，在 BEIR 评测集上，Milvus 的吞吐量比 Elasticsearch 高 3-4 倍，召回率持平，特定负载下 QPS 提升 7 倍。此外，还可以通过 drop_ratio_search 参数裁剪低权重稀疏项，用 dim_max_score_ratio 控制最高分维度的影响权重，针对不同查询模式按需调节。

这对 Generator 的 Sprint 场景来说，意义重大：一次查询，既能找到与用户会话设计相关的决策（语义路径），也能找到所有提到 validateToken 的文档（精确路径）。

Harness 里也不再需要再维护两套检索基础设施，结果质量同样高于任何单路检索；而且 docs/ 仓库持续更新时，Milvus BM25 的 IDF 自动维护意味着，新写入的文档能立刻参与下一次检索的打分，不需要批量重建索引，文档在哪里更新，检索能力就在哪里跟上。

05

新模型发布，先找哪些组件可以删

看到这里，我们已经梳理了 Harness Engineering 的核心定义、两个经典落地案例，以及关键的技术支撑。但还有一个更重要的规律，藏在这些案例背后：Harness 里的每个组件，都编码了一个模型自己做不到的假设——而这些假设，会随着模型能力的提升逐渐失效。

比如，Sprint 分解结构在 Claude Opus 4.5 版本中是必要的，因为当时的模型在长任务中会失去连贯性，需要通过 Sprint 拆分来保证任务推进；但到了 Opus 4.6 版本，模型能力大幅提升，这种分解结构就变成了多余的负担，可以直接删除。

再比如，Context Reset 是针对早期模型Context Anxiety的补偿机制，当模型本身消除了这种焦虑，这个组件就可以从 Harness 中移除。

这意味着，Harness Engineering 不是一个固定不变的框架，而是需要随模型能力持续重新校准的动态系统。每次新模型发布，Harness Engineer 要做的第一件事，就是重新审视整套 Harness 系统，找出那些不再是承重墙的组件，把它们拆掉——因为这些组件的存在，反而会增加系统的冗余，降低 Agent 的运行效率。

这个逻辑同样适用于 Context Retrieval 这一层。随着模型长Context 能力增强，检索-注入机制的粒度和时机都会变化。昨天必须精细管理的 Context Slice，明天可能可以整页直接塞进去。

说到底，基础设施配置是和模型能力一起演化的变量。Harness 里任何一个必要的组件，都在等待被更聪明的模型证明为多余。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

第一阶段（10天）：初阶应用

该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。

• 大模型 AI 能干什么？
• 大模型是怎样获得「智能」的？
• 用好 AI 的核心心法
• 大模型应用业务架构
• 大模型应用技术架构
• 代码示例：向 GPT-3.5 灌入新知识
• 提示工程的意义和核心思想
• Prompt 典型构成
• 指令调优方法论
• 思维链和思维树
• Prompt 攻击和防范
• …

第二阶段（30天）：高阶应用

该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。

• 为什么要做 RAG
• 搭建一个简单的 ChatPDF
• 检索的基础概念
• 什么是向量表示（Embeddings）
• 向量数据库与向量检索
• 基于向量检索的 RAG
• 搭建 RAG 系统的扩展知识
• 混合检索与 RAG-Fusion 简介
• 向量模型本地部署
• …

第三阶段（30天）：模型训练

恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。

到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？

• 为什么要做 RAG
• 什么是模型
• 什么是模型训练
• 求解器 & 损失函数简介
• 小实验2：手写一个简单的神经网络并训练它
• 什么是训练/预训练/微调/轻量化微调
• Transformer结构简介
• 轻量化微调
• 实验数据集的构建
• …

第四阶段（20天）：商业闭环

对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。

• 硬件选型
• 带你了解全球大模型
• 使用国产大模型服务
• 搭建 OpenAI 代理
• 热身：基于阿里云 PAI 部署 Stable Diffusion
• 在本地计算机运行大模型
• 大模型的私有化部署
• 基于 vLLM 部署大模型
• 案例：如何优雅地在阿里云私有部署开源大模型
• 部署一套开源 LLM 项目
• 内容安全
• 互联网信息服务算法备案
• …

学习是一个过程，只要学习就会有挑战。天道酬勤，你越努力，就会成为越优秀的自己。

如果你能在15天内完成所有的任务，那你堪称天才。然而，如果你能完成 60-70% 的内容，你就已经开始具备成为一名大模型 AI 的正确特征了。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】