从提示词到 Harness 与 Loop：AI Agent 工程的范式迁移

话语在迁移：从 Prompt 到 Loop#

回头看，Agent 工程的讨论大致经历了几个阶段。

第一阶段是提示词工程。核心假设是：模型的行为主要由输入的一段文字决定，把指令写清楚，输出就会好。这个阶段沉淀了很多技巧，也确实有效，但它的天花板很快显现——一段话约束不了一个需要持续行动的系统。

第二阶段是上下文工程。业界观察里，Anthropic 在 2025 年前后明确把 context engineering 提了出来：重要的不只是某一段指令，而是整个上下文窗口里放了什么、怎么组织、什么时候更新。检索、记忆、工具返回结果、历史对话，都是被管理的对象。

第三阶段是 harness。说法可以概括成一个等式：Agent = Model + Harness。模型是能力来源，harness 是包裹模型的运行时骨架；一个代理最终表现成什么样，两者共同决定。

第四阶段是 loop。有人进一步把焦点放到迭代过程本身：观察、决策、执行、验证，这一圈怎么转、转多少、什么时候停，都是可以被设计的。

需要说明的是，这四个阶段不是互相取代，而是层层叠加。今天做一个靠谱的代理，提示词仍然要写，上下文仍然要管，harness 仍然要搭，环仍然要设计。变化的是瓶颈在哪一层。

话语为什么会迁移？因为被处理的对象变了。提示词工程面对的是问答，一轮文本就够了；上下文工程面对的是长任务，开始关心进入现场的所有信息；harness 和 loop 面对的是持续行动的系统，环境和过程本身成了设计对象。任务越长期、越自主，要依赖的层就越靠外。

Harness 是包裹模型的运行时骨架#

先把概念说清楚。harness 指的是包裹模型的那层运行时骨架，一般包括几件事：工具调度、沙箱、权限边界、错误处理、可观测性。

工具调度决定模型能调用什么、怎么调用、调用的结果怎么回到上下文里。沙箱决定这些动作的影响范围，文件写到哪里、命令在什么环境执行、能不能碰真实系统。权限边界决定哪些操作默认允许、哪些必须确认、哪些永远禁止。错误处理决定工具失败时是重试、降级还是停下。可观测性决定你事后能不能还原它到底做了什么。

这些事听起来都是外围工程，但它们有一个共同特点：每一条都不是模型自己想出来的，而是外部系统强加的约束或供给。

一个值得记住的判断是：模型能力到位之后，稳定性的瓶颈会转移到 harness。模型足够聪明却仍然频繁翻车的场景，往往不是它”不会”，而是它不知道该用什么工具、没有边界约束、失败了没人接住、出了问题你看不见过程。

所以 harness 不是模型的附属品，更像是它的作业环境。同一个人，在有护栏的工地和没有护栏的楼顶，表现会完全不同。

这里值得单独补一句可观测性。很多系统在执行侧投入大量精力，工具越接越多，模型越换越强，但对”发生了什么”只留一行日志。这笔账很不划算。执行过程如果不能被回放，排查错误就只能靠猜，而猜的结果通常是错的。可观测性的价值在平时看不见，出事时它决定你能修复还是只能重来。

Loop 是把反馈环当设计对象#

loop 和 harness 容易混用，但指的是不同的东西。harness 是静态的结构，loop 是动态的过程：代理一轮一轮怎么往前走。

一个典型的环长这样：

1
观察当前状态 → 决定下一步 → 执行动作 → 验证结果 → 回到观察

这个环看上去理所当然，但大多数不稳定的代理系统，问题恰恰出在环的设计上。常见的坏形态有几种：执行完不验证就宣布完成；验证只看自己生成的文本而不是外部证据；失败后无限重试同一动作；或者环没有终止条件，一直转到上下文耗尽。

把反馈环当设计对象，意味着这几步每一步都要有明确答案。观察什么、从哪里观察；决策的依据是什么；执行的动作有哪些；验证用什么标准；不满足标准时回到哪一步。

环的圈数也是设计变量。圈数少，成本低，但容易草草收工；圈数多，精度高，但容易陷在局部打磨里。我的经验是给每个环一个明确的退出条件：达到验收标准退出，连续失败退出，资源耗尽退出。有退出条件的环是流程，没有退出条件的环是赌博。

这和写 skills 时的验收标准是同一个思路的放大版。验收标准约束的是单个任务的终点，loop 设计约束的是整个迭代过程的形状。

验证比执行更值钱#

环里最容易被敷衍的一步是验证，所以我单独拿出来说。

一个可操作的做法是维护可验证清单。任务开始前列出”完成的标志”，每一条都要能被外部手段确认：构建是否通过、页面是否可访问、文件是否真的存在、接口是否返回预期结果。清单越具体，代理越难用”应该没问题”蒙混过去。

与之配套的是证据审计。验证不应该停留在代理的自述上，而要留下可检查的痕迹：命令的输出、截图、测试结果、日志片段。这不仅是为了当下判断成败，也是为了事后复盘时能还原现场。

失败处理同样要提前设计。重试不是简单地再来一次，最好带上次数上限和退避策略；重试仍失败时要降级——换一个更保守的方案，或者停下来把问题交还给人。一个永远不会自己停下的环，比一个会失败的环更危险。

我自己的经验是：与其花力气让代理”一次做对”，不如花力气让它”做错时能被及时发现”。前者依赖模型能力，后者依赖工程设计，而后者是你真正可控的部分。

这些做法的成本都不高，多数在手工做工程时也会做。区别在于，手工时代这些靠脑子记，代理系统里必须把它们写进环里。写进去之后，它们就不再依赖任何人的自觉性了。

MCP 把工具接口拉进协议层#

前面说的工具和调度，过去大多是各家自己实现的。接口不统一，意味着每接一个新工具都要写一遍适配，经验也没法跨系统复用。

MCP 的意义就在于把这层接口标准化。业界观察里，从 2025 年到 2026 年这段时间，它经历了从提案到被广泛采纳的过程，逐渐成了工具接入层面的一个事实收敛点。生态里出现了大量现成的服务端与客户端实现，“给代理接一个能力”的成本明显下降。

标准化的价值不只是省事。它让工具的能力描述、调用方式、错误返回有了共同语言，harness 的很多设计——权限、审计、沙箱——才有一个稳定的着力点。协议不收敛的时候，这些工程只能在各自的私有接口上重复造。

在 MCP 之外，还有 A2A 这类更偏代理之间通信的协议讨论，处在不同的层次上。我的看法是：协议选型要看实际需求，也要算成本。每引入一层协议，就多一层抽象、多一套要维护的适配；任务没有跨系统协作的需求时，提前上全套协议反而是一种负担。

协议收敛是好事，但收敛的过程本身也提醒我们：标准是用来降低摩擦的，不是用来堆砌的。

从个人开发者的角度，协议收敛还有一个更直接的收益：学到的知识可以迁移。工具能力怎么描述、调用失败怎么处理、权限怎么声明，这些成了跨生态的通用问题，而不是绑定在某个平台上的私学。这种可沉淀性，比任何单个现成实现都更值钱。

多 Agent 需要先泼一盆冷水#

聊编排，绕不开多 Agent。它现在是最热的叙事之一：把任务拆给多个角色，互相协作，似乎规模越大越先进。

但有实证研究给出了相反的证据：在顺序推理类任务上，多 Agent 系统不仅不一定更好，有时反而会降低性能。原因不难理解——每多一个代理，就多一次信息转述，而每次转述都可能丢失细节、引入偏差，推理链越长，误差越容易累积。

这个结论不是说多 Agent 没用，而是说它的收益高度依赖任务形态。可并行、可独立验证、边界清晰的任务，拆分才有意义；本来就是一条紧密推理链的任务，强行拆分等于主动引入损耗。

工程上更诚实的说法是：多 Agent 是一种有成本的结构，不是一种天然先进的形态。

还有一笔账值得算：成本。多个代理意味着成倍的多轮调用，token 消耗和延迟都会跟着上去。就算不计算经济账，等待时间也是真实的约束。如果单代理三分钟能搞定的事，多代理要十分钟且结果不稳定，那选择并不困难。

架构-任务对齐比数量重要#

把上一条往前推一步，我认为编排的第一原则是架构与任务对齐，而不是代理数量。

先问任务是什么形状。如果是单一链条、上下文紧密的工作——读懂一个代码库、写一篇长文、追一个疑难 bug——一个代理配一个好的 harness 往往就够了，甚至更好。如果是天然可分片的——多个独立模块的排查、多种格式的批量处理——拆分才值得考虑。

什么时候单 Agent 加好 harness 就够了？我的判断标准有三条：任务的上下文需要高度共享；中间步骤之间强依赖；验证可以集中做。满足这几条时，加代理通常只会增加沟通开销。

什么时候才值得编排？当你能把任务切成边界清晰的块，每一块有独立的输入输出和验收标准，块与块之间只需要传递明确的产物。这时编排的收益才开始大于它的成本。

堆数量是容易的，对齐是难的。但决定系统稳定性的，从来是后者。

这里还想补一点：对齐不是一次性的决定。任务的形状会随项目阶段变化，原来单代理能干好的事，系统变大后可能真的裂成了几块独立的工作。架构是否合适需要定期重估，守着单一结构不放，和盲目堆代理一样危险。

把 system prompt 当代码管理#

编排系统的另一块隐形资产，是那些散落在各处的配置：system prompt、工具说明、权限策略、验收清单。它们实际上决定了代理的行为，却常常被当成随手可改的字符串。

我认为这些东西应该享受代码同等待遇。

版本化是第一步。每一次对 prompt 或配置的修改都应该有记录，能追溯是谁、在什么时候、为什么改。不然出了问题，你连行为是从哪一次改动开始漂移的都不知道。

diff 是第二步。system prompt 的修改和代码修改一样，值得被认真审查。一句看起来无害的措辞调整，可能悄悄改变代理在边界情况下的选择。

CI 测试是第三步。准备一组固定的任务场景，每次配置变更后跑一遍，检查关键行为有没有倒退。不需要多精密，哪怕只是十几个冒烟用例，也能拦住大部分鲁莽的改动。

这套做法的本质，是把”调 prompt”从一种手感活变成一种工程活。手感依赖个人，工程可以积累。

起步不必完美。今天就把最核心的那段 system prompt 放进版本控制，下一次改动时认真写一句原因，就已经越过了大多数实践。工程化的价值从来不在宏大的设计，而在这些小习惯的累积。

一次全站排查的编排形状#

最后用一个典型的编排场景把前面的概念串起来：让一个 agent 团队完成一次全站排查与修复。

这类任务的合理起点是任务分解。把”全站健康”拆成可以独立描述的子任务：构建是否通过、核心页面是否可访问、关键接口是否正常、静态资源有没有失效、安全配置是否还在位。每一块都要有自己的验收标准，而不是笼统的”检查一下”。

接下来是依赖排序。不是所有子任务都能并行：修复要等排查结论，部署要等验证通过，涉及同一文件的改动必须串行。把依赖画清楚，编排才不会自相矛盾。

然后是验证闭环。每个子任务完成后，产物要能被独立检查；汇总阶段要再做一次整体确认，防止”每块都通过、合起来却坏了”的情况。

最后一道是评审兜底。自动化验证能覆盖的终究有限，涉及判断力的部分——这个改动该不该上、风险是否可接受——仍然应该由人来拍板。编排系统的成熟标志之一，是它清楚自己哪里需要人。

这个形状其实和任何一次工程协作没有本质区别：分解、排序、验证、评审。Agent 带来的不是流程的发明，而是流程执行方式的延伸。

它也顺带回答了一个常被问到的问题：怎么避免代理互相等待、原地打转。答案通常不是更聪明的调度器，而是更清晰的分解和依赖。任务边界越含糊，编排层要补的沟通就越多，卡死的机会也就越多。

还有一个容易被忽略的点：交接物的粒度。代理之间传递的产物应当是自描述的——做了什么、验证到了什么、还剩什么不确定。如果接收方要从头重新摸底，分解就只省了执行的力气，反倒浪费了协调的力气。

先评估，再动手改造#

把这些思路往自己的工作流上搬时，我倾向于先盘点，再动工。

第一个问题：现在的流程里，哪些环节依赖口头叮嘱？凡是需要反复交代、对方才能做对的地方，都是应该写进手册或 harness 的候选。一个经验如果你已经说了三遍，它就该变成结构，而不是第四遍重复。

第二个问题：代理失败的时候，我是不是及时知道的？如果失败总是事后才发现，或者上线之后才暴露，说明环里缺了验证。最直观的信号是：你回答不出”它到底做了什么”。

第三个问题：哪些环节我仍然必须亲自下场？那些你还要出手的地方，就是约束或验证还没建立的地方。别把它们当负担，它们其实是一张改进地图。

盘点之后，改造的方向通常很清楚：把口头叮嘱变成显式约束，把事后抽查变成固定清单，把依赖眼睛的检查变成机器可验证的步骤。这个过程比引入任何新框架都更有价值。

盘点完还建议留一个基线：数一数当前一次典型任务里，人工要介入几次。这个数字不必精确，但它可以作为改造前后的对照。过几个月再看，如果数字没有下降，说明改造的方向没有碰到真正的瓶颈。

尤其要提醒一种冲动：看到新概念就想把整个工作流推翻重来。工程经验不支持这种玩法。系统是一个瓶颈一个瓶颈改出来的，一次推倒重来，往往连原来攒下的隐性经验一起丢掉。

继续……#

回头看这一路的讨论：提示词解决”说什么”，上下文解决”带什么入场”，harness 解决”在什么环境里干活”，loop 解决”一步一步怎么走”。Agent 工程的成熟，大致就是关注点沿着这条线不断往后端移动的过程。

我不觉得这代表着提示词不重要了。恰恰相反，当系统变复杂，每一段进入上下文的文字都变得更贵，怎么写才精炼反而更值得琢磨。变化在于，单靠文字已经撑不起一个可靠系统了。

也不是说编排越复杂越好。我越来越倾向于一种保守的判断：先把单 Agent 的 harness 做扎实，把反馈环的每一步设计清楚，把配置当代码管起来，再谈要不要引入多 Agent 和更多协议。顺序反了，复杂度会先于能力到来。

Skills 那篇聊的是给代理一本工作手册，这篇聊的是手册之外的工地怎么搭。两件事都指向同一个方向：让 AI 协作从依赖临场发挥，变成依赖可复用的结构。

结构不会让错误消失，但会让错误变得可见、可拦截、可复盘。而对工程来说，这就已经是很好的起点了。

如果非要用一句话概括这篇的想法：把代理当作需要入职手册、作业环境和定期评审的同事，而不是一个说两句就能心领神会的天才。前者需要工程，后者只需要信念。工程可以持续改进，信念只能祈祷。

继续搭，继续改，继续让环转得更稳一点。