前言
最近智能体开发领域掀起了一股造词热潮——似乎任何一个赛道要真正火起来，都得先造出几个“新词”。而其中最炙手可热的新概念，当属 Harness Engineering。
虽然这个词热度很高，但很多人并没有真正理解它的内涵。今天笔者在读者群中看到大家围绕 Harness Engineering 展开了热烈讨论，大家的理解各有道理，但总觉得还不够全面。恰好最近笔者也在持续研究这一概念，并结合 EasyDataset 作者花园老师的视频内容，学习了不少关于 Harness Engineering 的系统知识。
笔者将这些内容整理成这篇文章，分享给所有热爱大模型、智能体技术的读者，帮助大家紧跟智能体开发的潮流前沿。
一、真正决定智能体应用性能的到底是什么？
不知道大家有没有思考过这个问题：一个智能体系统，真正决定它运行效果的核心能力究竟是什么？
很多人会不假思索地回答——模型。但如果你最近正在做 Agent 开发，或者关注大模型的应用落地，相信你一定遇到过这样的困惑：使用同样的模型，为什么别人做出来的 Agent 准确率更高、运行更稳定，而我做出来的却像是一个玩具？
这时候大家惯用的排查思路往往是：是不是模型还不够强？是不是提示词没调好？是不是 RAG 没调用明白？这些想法当然都没错。
但随着智能体应用开发技术的不断成熟，越来越多的团队发现：真正决定系统能不能稳定、高效跑起来的，往往不是模型本身，而是模型外面那套支撑它运行的工程系统。 而开发这套系统的工程理念，如今就被称为 Harness Engineering。
Harness Engineering 的概念非常直观。它的英文原意是“马具”——你可以把大模型想象成一匹千里马。千里马固然很强，但如果没有一副合适的马具来约束和引导，它也很难发挥出真正的价值。这样一比喻，是不是一下子就清晰多了？
二、智能体应用开发的历史追溯
要全面准确地理解 Harness Engineering，最好的方法是沿着智能体应用开发的历史演进，循序渐进地来看。过去两年，AI 工程经历了三次明显的重心迁移：
Prompt Engineering → Context Engineering → Harness Engineering
2.1 Prompt Engineering —— 把话说清楚
2022 年底 ChatGPT 刚火起来的时候，大家最直观的感受是：同一个模型，换一种问法，结果可能天差地别。于是，人们普遍相信——模型不是不会，而是你没把问题说清楚。那个阶段，所有人的精力都集中在研究提示词的写法上，希望让大模型产生符合预期的回复，由此诞生了大量提示词撰写技巧（感兴趣的朋友可以阅读笔者之前的文章《与大模型对话的艺术：提示词工程指南，价值百万！（一）——提示词必备要素与基本技巧》）。
为什么提示词会有效？因为大模型本质上是一个对上下文极其敏感的概率生成系统。你给它什么身份，它就沿着那个身份回答；你给什么样例，它就沿着那个范式补全。提示词工程的本质不是“命令”模型，而是塑造一个局部的概率空间。 想深入了解大模型原理的读者，推荐阅读笔者的另一篇文章：《大模型训练全流程实战指南基础篇（二）——大模型文件结构解读与原理解析》。
然而，大家很快发现提示词工程遇到了天花板。很多任务不是你说清楚就行，而是大模型必须“知道”——比如公司内部文档，模型不清楚就是答不对；再比如如何让模型调用工具去解决复杂任务……这些问题提示词解决不了。提示词解决的是“表达”问题，无法补全大模型的信息差。
2.2 Context Engineering —— 补全大模型的信息差
进入 2025 年，AI 圈最热的关键词从“大模型”变成了“智能体”。此时模型不再只是回答问题，而是要进入真实环境里做事：多轮对话、调浏览器、写代码、查数据库，还要在多个步骤之间传递中间结果。这时大模型智能体应用开发的关键，不再是“这个问题能不能回答对”，而是“这个任务能不能成功运行”。
举个例子，用户说：“帮我分析这份需求文档，找出潜在风险，结合历史评审意见给出改进建议，再生成一版发给产品经理的反馈稿。” 这已经不是单靠提示词能解决的了，而是需要给大模型提供大量额外信息。
注意，这里的 Context 并不仅仅是指前期给模型的一些背景资料，而是整个运行过程中影响大模型判断和决策的信息总和，包括：用户输入、历史对话、检索结果、工具返回、任务状态、系统规则、安全约束，以及多智能体协作时其他智能体传来的结构化结果。从这个角度看，Prompt 其实只是 Context 中的一部分。
最典型的 Context Engineering 实践就是 RAG 系统。但需要特别注意：一个成熟的 RAG 系统关注的并不只是“检索”，而是整条链路——文档怎么切块、结果怎么排序、长文怎么压缩、历史对话什么时候保留、工具返回要不要全部暴露……
包括最近很火的 Agent Skills（不熟悉的读者建议先阅读笔者的文章《Agent Skills完全指南：核心概念丨设计模式丨实战代码》），本质上也是上下文工程的高级实践。它采用 “渐进式披露” 策略：不一开始就把十几个工具的说明和参数定义全部塞给模型，而是只给它最少量的元信息；等模型真正要触发某个能力时，再把对应的 SOP、详细参考、脚本动态加载进来。这样就极大地节省了大模型的上下文窗口，保证了信息的高效处理。
2.3 Harness Engineering —— 让模型跑得稳、不跑偏
有人可能会觉得，有了 Context Engineering，构建一个智能体系统已经绰绰有余。但现实很快给出了新的难题：就算信息给得足够多，模型也不一定能稳定地执行。
笔者自己就遇到过这样的问题：实现过一个自动编写代码并执行的工具，每个阶段模型工具调用的准确率都能达到 90%。但持续几个阶段后，比如三个阶段下来，0.9 × 0.9 × 0.9 = 0.729，整体准确率只有 70% 左右——这在生产环境中是不可接受的。
类似的情况在大模型开发中比比皆是：模型计划做得很好，但执行跑偏了；调用了工具，却理解错了返回结果；在一个很长的链路里，输出逐渐偏航，而系统却毫无察觉。
前面说的 Prompt Engineering 和 Context Engineering，主要解决的都是大模型信息层面的问题。但当模型开始连续行动时，谁来监督、约束、纠偏它的行为？
这时候就需要 Harness Engineering 登场了。它的思想非常朴素：当模型从“回答问题”走向“执行任务”时，系统不仅要能传递信息，更要能驾驭整个过程。 如果说前两代工程关注的是“怎么让模型更会想”，那么 Harness 关注的是：怎么让模型别跑偏、跑得稳，出了错还能拉回来。
2.4 三者关系：不是替代，而是递进包含
看完整个智能体开发的演进过程，大家大概也能明白：这三者的关系并不是替代，而是递进的包含关系。
- Prompt Engineering：对指令的工程化
- Context Engineering：对输入信息的工程化
- Harness Engineering：对整个运行系统的工程化
它们的边界一层比一层大。LangChain 的工程师曾给 Harness 下过一个经典定义：
Agent = Model + Harness
翻译成人话就是：在一个 Agent 系统里，除了模型本身以外，几乎所有能决定它能不能稳定交付的东西，都可以算进 Harness。
三、一个好的 Harness Engineering 应该具备哪些架构？
关于这一点，笔者与花园老师的观点基本一致：一个成熟的 Harness Engineering 体系，可以拆解为六个核心层次。
.1 第一层：上下文边界层
模型能否稳定发挥，很多时候不仅取决于它“聪不聪明”，更取决于它“看到了什么”。Harness 的首要职责，就是让模型在正确的认知边界内思考。这一层通常包含三件事：
- 角色、目标与成功标准的定义：模型需要清楚自己是谁、任务是什么、怎样才算完成得好。
- 信息的裁剪与选择：上下文不是越多越好，而是越相关越好。冗余信息反而会干扰判断。
- 结构化组织：固定规则放哪里、当前任务放哪里、运行状态放哪里、外部证据放哪里——最好分层清晰。一旦信息组织混乱，模型很容易遗漏重点、忘记约束，甚至产生自我污染。
3.2 第二层：工具系统
没有工具，大模型本质上仍只是一个文本预测器。而一旦接入工具，模型才能真正“做事”——搜索网页、阅读文档、编写代码、调用 API。但 Harness 在这一层要做的，并不是简单地把工具挂上去，而是解决三个核心问题：
- 给什么工具：工具太少，能力不足；工具太多，模型容易乱用。
- 什么时候调用：不该查的时候不要乱查，该查的时候也不要硬答。
- 工具结果如何喂回模型：搜索结果返回几十条，不能原封不动地塞回去，而应提炼、筛选，保持与任务的高度相关性。
3.3 第三层：执行编排
很多 Agent 的问题不在于某一步不会做，而在于不会把所有的步骤串起来。它会搜索、会总结、会写代码，但整个过程想到哪做到哪，最后交付出一堆半成品。
一个完整任务的执行轨道通常包含以下环节：
理解目标 → 判断信息是否充足 → 不足则补充 → 基于结果分析 → 生成输出 → 检查输出 → 不满足则修正或重试
这已经非常接近人类的工作方式了。区别在于：人靠经验，Agent 靠 Harness 提供的这套运行环境。
3.4 第四层：记忆与状态管理
没有状态的 Agent，每一轮都像失忆一样——它不知道自己刚才做了什么，也不清楚哪些结论已经确认、哪些问题尚未解决。
Harness 必须妥善管理状态，至少要能够区分以下三类信息：
- 当前任务的状态
- 会话过程中的中间结果
- 长期记忆与用户偏好
这三类信息如果混在一起，系统会越来越混乱。只有分清楚之后，Agent 才能像一个稳定可靠的协作者。
3.5 第五层：评估与观测
这一层是很多团队最容易忽视的。许多系统的问题不是“生成不出来”，而是生成完了之后，根本不知道自己做得怎么样。
如果没有独立的评估与观测能力，Agent 就会长期停留在“自我感觉良好”的状态。
这一层通常包括：
- 输出与验收环节的验证
- 自动化测试
- 日志与指标采集
- 错误归因分析
系统不仅要会“做”，还要知道自己“有没有做对”。
3.6 第六层：约束、校验、失败和恢复
最后一层，往往才是真正决定系统能不能上线的关键环节。因为在真实环境里，失败不是例外，而是常态。
可能搜索不准、API 超时、文档格式混乱、模型误解任务……如果没有恢复机制，Agent 每次出错就只能从头再来。
一个成熟的 Harness，一定要包括三件事：
- 约束：哪些能做、哪些不能做。
- 校验：输出之前、输出之后要怎么检查。
- 恢复：失败之后怎么重试、切换、回滚到稳定状态。
四、OpenAI 和 Anthropic 是如何做 Harness Engineering 的？
Harness Engineering 绝不仅仅是一个被炒作的概念，它已经成为众多明星智能体产品的核心能力。接下来，笔者就简单分析一下 OpenAI 和 Anthropic 在生产实践中对 Harness Engineering 的应用。
4.1 OpenAI：人类不再写代码，而是设计环境
OpenAI 的实践体现了一个核心转变：人类不再写代码，而是设计环境。工程师的任务被精简为三件事：
- 把产品目标拆解成 Agent 能理解的小任务；
- 当 Agent 失败时，不是让它“更努力”，而是追问环境缺少了什么结构性能力；
- 建立反馈链路，让 Agent 能“看见”自己的工作结果。
早期 OpenAI 也踩过不少坑——比如把所有规范塞进一个巨大的 AGENT.md 文件，结果导致 Agent 注意力涣散。后来他们改为渐进式披露：主文件变成一个目录页，只保留核心索引，详细内容按需加载。这与 Anthropic 的 Skills 思路不谋而合。
更关键的是，OpenAI 让 Agent 拥有了“看见”应用运行情况的能力。因为当 Agent 的产出速度提上来之后，人类根本验不过来。于是，他们为 Agent 接上了浏览器（可截图操作）、日志系统和隔离环境，使其能够自主跑通“写代码 → 运行结果 → 发现 Bug → 修复”的完整闭环。
最后，OpenAI 还将资深工程师的经验固化为系统规则。而且这些规则不仅仅是“报错”，而是连同“怎么修”一并反馈给 Agent，从而形成了一套可持续运行的自动治理系统。这正是 Harness 中“执行编排”“评估观测”与“约束恢复”三层的完整体现。
4.2 Anthropic：上下文重置与生产验收分离
Anthropic 的明星产品 Claude Code，同样处处体现着 Harness Engineering 的思想。他们在长程任务中发现了两大问题：
一是上下文“焦糊” ：当上下文窗口被塞满后，模型开始丢失细节，只能仓促收尾。简单的压缩上下文并没有真正消除负担，于是他们改用 Context Reset（上下文重置） ——把任务交接给一个全新的 Agent，类似于内存泄漏后重启进程。这是一种典型的 Harness 设计思路。
二是自评失真：模型对自己的评估往往偏乐观，尤其是在没有标准答案的任务上。Anthropic 的解决方案是 生产与验收分离：
- Planner：负责扩展和拆解需求；
- Generator：按计划逐步实现；
- Evaluator：像真正的 QA 人员一样操作页面、校验交互，独立评估结果。
通过这套机制，系统形成了“生成 → 检查 → 修复 → 再检查”的闭环，确保了整体运行的稳定与可靠。
以上就是本期分享的全部内容，相信大家看到这里一定懂得什么是Harness Engineering， 期待大家早日在项目实践中应用Harness Engineering的思想~
五、总结
本篇分享介绍了Harness Engineering， 它是智能体从“回答问题”迈向“执行任务”的关键工程思想。Harness Engineering并非替代提示词工程或上下文工程，而是在二者之上构建约束、编排、观测与恢复机制，确保模型跑得稳、不跑偏。掌握 Harness，才能真正将大模型能力转化为稳定可靠的生产级应用。
笔者的专栏《深入浅出LangChain&LangGraph AI Agent 智能体开发》适合所有对 LangChain 感兴趣的学习者，无论之前是否接触过 LangChain。该专栏基于笔者在实际项目中的深度使用经验，系统讲解了使用LangChain/LangGraph如何开发智能体，目前已更新 43 讲，并持续补充实战与拓展内容。欢迎感兴趣的同学关注笔者的掘金账号与专栏，也可关注笔者的同名微信公众号大模型真好玩，每期分享涉及的代码均可在公众号私信: LangChain智能体开发免费获取。
