同样的模型、同样的提示词，为什么别人的Agent能稳定跑很久，你的总是差强人意？答案不在模型里，在模型外面那层"壳"里。

---

先说一个真实案例

年初有个朋友找我帮他们调一个Agent系统。团队之前已经做了很多努力——换上了最好的旗舰模型，Prompt改了上百版，各种参数也调了不少，但一到真实场景，效果就是不稳定。有时候很聪明，有时候莫名跑偏，任务成功率不到70%。

后来我去看了一下，最后改动最大的地方，反而不是模型，也不是提示词。改进点在于：任务是怎么拆的、状态是怎么管的、关键步骤怎么校验、失败之后怎么恢复。

新版本上线之后，还是同样的模型、同样的提示词，成功率拉到了95%以上。

这个朋友问我：你到底改了什么？

说实话，那个时候我没有一个特别准确的词来形容。直到最近一个概念越来越火——Harness Engineering——我才意识到，我当时改的那些东西，本质上就是Harness。

---

一、AI工程的三次重心迁移

过去两年，AI工程经历了三次明显的重心迁移：

第一次：Prompt Engineering（提示词工程）

大模型刚火的时候，大家最直观的感受是：同一个模型，换一种说法，结果可能差很多。

你说"帮我总结一下这篇文章"，它可能只会给你一个很平的总结。但如果你说"你是一个资深编辑，用不超过200字概括这篇文章的核心论点，语气要犀利"，效果马上就不一样。

所以那个阶段大家都相信一件事：模型不是不会，而是你没有把问题说明白。

于是大家开始疯狂研究Prompt——角色设定、风格约束、Few-shot示例、分布引导、输出格式……

为什么这些有效？因为大模型本质上是一个对上下文非常敏感的概率生成系统。你给它什么身份，它就沿着那个身份回答；你给它什么样例，它就沿着那个范式补全；你强调什么约束，它就把那部分当成重点。

Prompt Engineering的本质，不是命令模型，而是塑造一个局部的概率空间。

但Prompt Engineering很快就遇到了天花板。

第二次：Context Engineering（上下文工程）

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

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

这时候你会发现，Prompt写得再漂亮，也替代不了事实本身。

Prompt擅长的是：常驻任务约束、输出格式、激发模型已有能力。

Prompt不擅长的是：凭空弥补缺失的知识、管理大量动态信息、处理长链路任务里的状态。

说白了，Prompt解决的是表达的问题，不是信息的问题。

于是Context Engineering开始了。当大家还只是做聊天机器人的时候，Prompt的作用很大——任务短、链路短、状态少。但后来Agent开始火了，模型不只是回答问题，而是要进到真实环境里做事情：多轮对话、调浏览器、写代码、查数据库、在多个步骤之间传递中间结果、根据外部反馈不断修订计划。

这时候问题就变了：系统面对的不再是一次回答对不对，而是整条链路的任务能不能跑通。

Context Engineering的核心就变成一句话：模型不一定是知道的，系统必须在合适的时机把正确的信息送进去。

举个例子：你让AI做一个真实的任务——"帮我分析这份需求文档，找出潜在风险，结合历史评审意见给出改善建议，再生成一版发给产品经理的反馈稿。"

这至少需要：当前的需求文档、历史评审记录、相关规范、当前目标、已分析出的中间结论、输出对象是谁、语气应该怎么调……

Context不只是几段背景资料。在工程意义上，它代表了所有影响模型当前决策的信息总和——用户输入、历史对话、检索结果、工具返回、当前任务状态、中间产物、系统规则、安全约束、其他Agent传过来的结构化结果。

所以你会看到，Prompt其实只是Context的一部分。

第三次：Harness Engineering（驾驭工程）

但Context Engineering也不是终点。后来大家又发现了一个更麻烦的问题：就算信息给对了，模型也不一定能稳定地执行正确。

它可能计划做得很好，但执行跑偏了；可能调了工具，但理解错了返回结果；可能在一个很长的链路里已经慢慢偏航了，但系统却没有发现。

Prompt和Context主要都在解决输入侧的问题——Prompt优化意图表达，Context优化信息供给。但复杂的任务里还有一个更难的问题：

当模型开始连续行动的时候，谁来监督它、约束它、纠偏它？

Harness这个词，原本的意思是缰绳、马具、约束装置。放在AI系统里，就是在提醒我们一件非常朴素的事情：当模型从"回答问题"走向"执行任务"，系统不只要负责喂信息，还要驾驭整个过程。

如果前两代工程关注的是"怎么让模型更会想"，那Harness更关注的是"怎么让模型别跑偏、跑得稳、出了错还能拉回来"。

---

二、一个比喻讲清三者关系

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

Prompt Engineering：把话讲清楚——见面先寒暄→介绍方案→问需求→确认下一步。重点是把话说明白。

Context Engineering：把资料准备齐全——客户背景、过往沟通记录、产品报价、竞品情况、这次会议的目标。重点是把信息给对。

Harness Engineering：持续监督纠偏——带Checklist去、关键节点实时汇报、会后核实纪要和录音、发现偏差马上纠正、按明确标准验收结果。重点是有一套持续观测、持续纠偏、最终验收结果的机制。

三者不是替代关系，而是包含关系：

• Prompt 是对指令的工程化
• Context 是对输入环境的工程化
• Harness 是对整个运行系统的工程化

它们的边界一层比一层大。

---

三、Harness的六层架构

一个成熟的Harness系统可以拆成六层：

第一层：Context管理（站在Harness视角重新看）

模型能不能稳定发挥，很多时候不取决于它多聪明，而取决于它看到了什么。Harness的第一职责就是让模型在正确的信息边界内思考。

三层细分：

• 角色/目标定义：模型要知道自己是谁、任务是什么、成功标准是什么
• 信息裁剪和选择：上下文不是越多越好，而是越相关越好
• 结构化组织：固定规则放哪、当前任务放哪、运行状态放哪、外部证据放哪——分层清楚，否则模型容易漏重点、忘约束、自我污染

第二层：工具系统

没有工具，大模型本质上还是一个文本预测器——会解释、会总结，但接触不到真实世界。连上工具后，模型才能真正做事：搜网页、读文档、写代码、调API。

Harness在这里要解决的不只是"挂工具"，而是三个问题：

• 给什么工具：太少能力不够，太多模型乱用
• 什么时候调用：不该查的时候别乱查，该查的时候也别硬答
• 结果怎么回喂：搜索回来的几十条结果不能原封不动塞回去，要提炼筛选、保持任务相关性

第三层：执行编排

核心问题：模型下一步该做什么？

很多Agent的问题不是某一步不会，而是不会把所有步骤串起来。它会搜索、会总结、也会写代码，但不知道先做哪个、后做哪个、哪些可以并行、什么时候该等待、什么时候该重试。

任务拆解、步骤依赖管理、并行执行、状态跟踪——这些都需要在Harness层面解决。

第四层：验证机制

Claude Design的提示词里有一个非常精辟的设计：在开发完成后，fork出一个独立的子Agent，对当前完成的网页做全面检查。

为什么不用同一个Agent检查自己的输出？因为它会天然倾向于觉得自己没问题。但换一个全新的上下文，这种"自我感觉良好"就很容易被打破。

这就是Harness中验证层的核心理念——独立验证，不要自己检查自己。

第五层：错误恢复

不是每个错误都需要从头来。Harness需要定义：

• 失败了怎么重试（相同策略还是换策略）
• 怎么回滚到上一个正确的状态
• 怎么降级处理（核心功能保底，非核心功能放弃）

第六层：可观测性

全链路的日志和监控。出了问题，能快速定位是哪一层、哪一步、什么原因。

---

四、实战案例：OpenClaw的多Agent架构就是Harness的工程化实践

聊完理论，来看一个真实的工程实践——OpenClaw的多智能体团队搭建。

有人用OpenClaw搭了一个7人AI团队：生图助手、资讯助手、开发助手、投资助手、社区助手、写作助手、团队协调专家。

为什么不能做一个"全能Agent"？

很多人装好OpenClaw后的第一反应：把所有技能塞进一个Agent。实践证明这是个坑，原因恰好对应Harness的前两层：

上下文污染（第一层问题）：生图的提示词模板、投资分析的框架、写作的风格指南全塞进同一个上下文，注意力严重分散。让它写文章，它可能在行文中不自觉使用投资分析的术语。

权限冲突（第二层问题）：开发助手需要Shell来调度Code，投资助手需要访问股票数据接口，社区助手需要访问Reddit。全部开放给一个Agent，违反最小权限原则。

人设冲突（第一层问题）：投资助手应该谨慎、数据驱动；写作助手应该有温度、有文采；社区助手需要有趣、有个性。这些截然不同的性格，很难在一个Agent上共存。

专精Agent的设计

每个Agent绑定不同的模型（写作用擅长聊天的模型，开发用擅长编码的模型），拥有独立的记忆（短期对话上下文 + 中期每日记录 + 长期偏好沉淀），通过SOUL.md等文件定义独立人设。

Agent间通过非阻塞调用协作：主Agent发起调用后继续做自己的事，被调用Agent完成后主动推送结果。通过serveAgent配置实现权限隔离。

这本质上就是Harness的工程化落地——每个Agent是一个被Harness约束的模型实例，多个Agent之间的协作编排是更高层的Harness。

---

五、Claude Design的提示词：Context Engineering的教科书级案例

Claude Design的提示词泄露后（上线不到24小时），被很多人视为Context Engineering的教科书。其中几个核心设计：

动态角色定位

不是"你是一个AI助手"，而是"你是一个专家级设计师，用户是你的产品经理"。根据任务动态切换身份：做动画就当动效设计师，做原型就当UX设计师。

这是Context Engineering中角色定义的高阶用法——不是写死一个角色，而是让模型根据任务自主切换角色边界。

去AI味清单

AI生成网页的典型毛病：紫粉蓝渐变、大圆角卡片、Emoji当图标、假数据填充、烂大街的字体。

Claude Design把这些雷区一条条列出来，逼着AI不能走老套路。

这对应Harness中的约束管理——不是告诉模型"应该做什么"，而是明确"绝对不能做什么"。

OKLCH色彩系统

传统HSL色彩空间感知不均匀——同样亮度值，黄色比蓝色看着亮一大截。用OKLCH（感知均匀的色彩空间），保持亮度和色度不变、只转变色相角，出来的颜色自然和谐。

这是Context Engineering中信息供给的精妙之处——不是给模型更多颜色选择，而是给它一个更好的颜色框架。

验证机制：独立子Agent检查

完成网页后，fork出一个独立的子Agent做全面检查。换一个全新上下文，打破"自我感觉良好"。

这直接对应Harness的第四层：独立验证机制。

---

六、写在最后：2026年AI开发者的核心竞争力

把这三个话题放在一起，结论很清晰：

AI的能力瓶颈已经不在模型本身，而在模型外面那层"壳"。

层次	关注点	要解决的问题
Prompt	怎么把话说清楚	意图表达的精准度
Context	信息怎么喂进去	知识供给的完整度和时机
Harness	整个系统怎么跑稳	执行的稳定性、可恢复性、可观测性

2026年的AI开发者，核心竞争力正在从"会不会调Prompt"变成"能不能造出稳定交付的系统"。

同样的模型，Harness从70%拉到95%。同样的模型，一套好的提示词系统让输出质量产生质的飞跃。同样的模型，一个专精Agent比一个全能Agent靠谱得多。

Agent = Model + Harness。

Harness就是模型之外的一切。你不需要换更好的模型——你需要先把Harness造好。

---

参考资料：

《最近爆火的 Harness Engineering 到底是啥？一期讲透！》，B站视频，code秘密花园，2026年5月8日。本文通过Ai好记智能解析获取。

《龙虾装上了，可以用来干啥？分享下我的 OpenClaw 多智能体团队搭建经验！》，B站视频，code秘密花园，2026年5月8日。本文通过Ai好记智能解析获取。

《我把 Claude Design 做成了 Skill，人人都能成为顶级网站设计师》，B站视频，code秘密花园，2026年5月8日。本文通过Ai好记智能解析获取。