夜雨聆风
4月22日，CLl-Anything/Nanobot团队负责人黄超老师，HiClaw项目发起人、阿里云智能高级解决方案架构师付宇轩，中科大副研究员程明月等5位嘉宾将在OpenClaw技术研讨会带来主题报告。
作者：sunnyzhao
地址：
https://zhuanlan.zhihu.com/p/2015575496742679437
经授权发布，如需转载请联系原作者
引言
本文基于agent技术论文，社区agent工程分享，结合笔者近期multi-agent项目实践，提出一套“知识—编排—门控—治理”四层解耦设计、经验沉淀、持续治理的 MAS Harness设计架构, 整理成文，分享如下。
01
龙虾背后的工程治理隐忧
2026 年 1 月，一只红色龙虾悄悄改变了开发者的桌面。
OpenClaw，前身叫 Clawdbot，因商标纠纷数次改名，吉祥物是一只龙虾，在 72 小时内积累了超过 6 万 GitHub Star，随后飙升至 24 万，成为 GitHub 有史以来增速最快的项目之一，近期已经突破30万 star，火遍大江南北。
它的独特之处在于，龙虾这只agent能在你没有主动发起对话的情况下自主行动，定时扫描收件箱、整理日历、凌晨跑任务、在你睡觉时帮你整理资料，睡醒时给你推送当天科技要点，简而言之，我们之前接触到的AI都是在被动回答/完成问题，而OpenClaw在你的高授权环境内， 开始主动给你干活，而且随着记忆和经验的沉淀，它还能越来越懂你。
但是在热度背后，恰好也让我们看到了现阶段高自主AI真实存在的问题。数周内社区技能市场出现341 个恶意 skill，占整个注册表的 12%；相关平台泄露 35,000 个邮件地址和 150 万个 agent API token；同时还有高危漏洞 CVE-2026-25253 的攻击链仅需毫秒级触发，访问一个恶意网页就足以让 agent 被接管。
这刚好也让我想到一句话-“能力越大，责任越大”，对人如此，对agent亦然。当agent开始承担独立角色完成实际环境的任务时，价值提升的同时风险也在随之增加，一旦agent真正跑进生产环境，工程治理的缺位也就会被急剧放大。 这可能也是整个 agent 工程领域正在面对的系统性困境，模型能力在快速往前跑，而围绕模型的工程基础设施的进展速度明显滞后。这背后的原因也好理解，模型快速发展的能力正在吞噬与模型增长能力存在重合的工程领域，而传统软件也正在面临AI native范式带来的冲击，AI native的代表性工程化方案就是agent，那如何让agent具备更强的模型能力适配性，更有效的缓冲模型能力增长带来的冲击，以及实现agent的持续运营和治理，就成为agent工程不得不面对的问题。
1.agentic 系统工程化演进
agent的核心决策能力来自于模型，所以在开始讨论工程化方案架构之前，我们还是先从模型角度来看一下技术发展的迭代和演进。
最近四年的时间，agent能力从模型的执行扩展的补位者逐步成为核心推理能力的一等公民，这四年的演进路径，粗看是一条模型能力持续提升的曲线，细看却是两条曲线同时在走：一条是模型的 agentic 能力曲线，另一条是工程基础设施的成熟度曲线。
2023 年，GPT-4 + plugins 在 GAIA 基准上只得 15 分，而人类受试者是 92 分，那时候多 agent 的价值主要是「能力补位」，把单模型做不好的长链任务靠协作和工具拆开来做。2024 年AI工程开始认真区分 workflow 和 agent，评测范式从「回答像不像」转向「在真实环境里能不能把事做成」（WebArena、τ-bench）。范式转折的起点是 o1的出现，它用强化学习训练出「先推理再行动」的能力，agent 的function call能力开始大幅得到提升，开始学会了何时调用工具，而不只是如何调用。这是推理模型开始重构 agentic 系统设计逻辑的真正起点。2025 年，o1 奠定的推理范式在执行层面开始量化兑现：GPT-4.1 专注指令遵循和代码生成，在 SWE-bench Verified 上从 33.2% 跃升至 54.6%，推理判断能力和 代码执行能力在 agentic 任务上形成分工互补；产品级 agent（ChatGPT agent、Claude Research）开始出现，把「自动化」定义为模型 + 工具 + 审批 + 观测 + 风险控制的组合体，而不再是纯模型行为。
从2025年下半年gpt-5，opus-4系列开始，前沿模型迭代加速，agentic 能力成为了模型发布时重点突出的一等公民。Claude Sonnet 4.6 在 coding、computer use、agent planning 上全面升级，在 SWE-bench Verified 上达到 79.6%，ARC-AGI-2 从 13.6% 跃升至 58.3%，首次以 Sonnet 价位提供 Opus 级别的推理能力，成为大多数 agentic 工作流的默认选择；Opus 4.6 则在此基础上提供更深的推理深度，在METR 任务时间跨度上运行的时间线长达 14.5 小时，是当时所有模型里最长的长时自主运行能力。GPT-5 系列把 tool_search、compaction、computer use 直接内置为模型原生能力，codex系列模型也开始与opus模型在AI coding领域分庭抗礼，部分早期 benchmark 出现接近饱和或区分度下降的迹象，推动社区引入 GAIA2、Terminal-Bench 2.0、MCP-Atlas 等更贴近真实任务和 harness 条件的评测。
但我们可以发现，agentic 能力的高分，几乎没有一个是基座模型裸跑出来的。 厂商发布的agent强性能指标，标注里都带着具体的 harness 条件，例如web search、code execution、context compaction等。harness 可以理解为包裹在模型外部的运行编排层，负责工具调用、上下文压缩、状态持久化、安全约束与结果评测。模型的推理能力决定 agent 的上限，但只有在合适的 harness 中，这种能力才能被稳定地转化为可执行、可验证、可交付的任务完成能力。能力在增长，但增长的方式是模型能力与agent能力的协同进化，模型的推理能力是agent驱动的核心，但是推理能力得以产生价值需要结合对应的harness来提供发挥的环境和良好运行保障。
相应地，提升 agent 能力也不只是优化基座模型，还需要在训练中构建带工具、带环境反馈、带 verifier 的训练 harness，agent能力主要涉及基础模型的RL后训练，要提升模型的agent能力，需要构建后训练环境支持模型调用工具，完成特定任务交付结果，并根据结果的正确性来获得系统奖励，以此训练模型的自主化agent能力。而随着 agent 能力增长，可授权的自主范围也在扩大，一旦 harness 缺位，放大的不是效率而是风险，OpenClaw 产生的相关安全案例也在印证这个判断。
harness这套agent工程应该怎么设计，首先还是需要基于agent的技术设计和实现架构，我们需要先从 agent 的设计模式入手，先看清楚单 agent 和多 agent 目前的技术发展，工程落地现状，各自能走多远、在哪里触碰边界，这样我们才能深入探讨agent harness工程闭环设计。
02
从单 agent 到多 agent
agent 工程化难在哪里
单agent(single agent)和多agent(multi-agent)之争一直是学术界和工业界讨论的一个热点话题，但基本都默认一个前提：先从单 agent 开始，只有当明确的瓶颈出现时，才引入多 agent。MAS(multi-agent system) 虽然同时扩展了agent的协作和自主的自由度，但是也带来了通信协调的复杂度和更高的token成本，所以多agent不一定由于单agent，还是需要结合实际场景去做成本和收益的权衡，进行迭代优化。
1.单 agent 能走多远
单agent就是整个系统用一个agent来完成所有任务，这个模式实现相对简单，配备对应的工具系统(tools or mcp)，单agent在很多场景下已经足够，包括我们现在用到的AI coding agent，例如codex，claude code，默认都是单gent。单agent 的核心运行逻辑就是如何在自己的执行循环里推理和行动，目前有五种主流设计范式，核心差异在于规划与执行是否分离、计划是否可动态修正、context 如何管理、模型选型是否异构：
- ReAct：推理与执行交替循环，每步观察驱动下一步决策，灵活但 context 线性累积
- Plan-and-Execute：规划执行两阶段分离，计划可在执行中动态 Replan
- ReWOO：规划执行严格隔离，计划一次性前置锁死，最大化 token 效率
- 异构模型分工：大模型负责规划，小模型负责执行，成本与能力精细化匹配
- Ralph Loop：（工程化门控治理机制，非推理范式）长程任务分解为子任务，每轮全新 context 启动，进度通过文件持久化
ReAct 是最直觉的单 agent 范式：每一步先推理（Thought），再执行动作（Action），观察结果（Observation），再进入下一轮推理。优势是执行路径可以随观察实时调整，适合探索性强、路径不确定的任务。代价是 token 消耗随步骤线性累积，完整历史每轮都要打包送入模型，长链路任务的 context 会迅速膨胀。
Plan-and-Execute 把规划和执行分离到两个独立角色：Planner 生成高层计划，Executor 逐步执行。关键特征是计划在执行过程中可以动态调整——每步执行完，Planner 可以根据新的观察修订后续步骤（Replan）。适合任务结构相对清晰、但执行中存在不确定性的场景。
ReWOO与 Plan-and-Execute 同属规划执行分离的范式，但设计目标不同：彻底解耦推理与观察，以最大化 token 效率。Planner 一次性生成包含占位符（#E1、#E2…）的完整计划，Worker 并行执行所有工具调用，Solver 最后汇总——执行过程中不会触发重规划，计划在开始前就锁死。HotpotQA 基准：同等准确率下 token 消耗约 2,000，而 ReAct 是 9,795，降低80%。两者核心差异在于有无动态 Replan：ReWOO 适合工具依赖关系可提前确定的批量处理场景，Plan-and-Execute 适合需要中途修正的场景。
异构模型分工是近年生产级 agent 降本的核心路径：规划和执行不只是逻辑上的分离，更是模型选型上的分层——用 frontier 大模型担任 Planner 负责高层推理，用轻量小模型或专用微调模型担任 Executor 负责低层执行。Plan-and-Act（Erdogan et al., ICML 2025）的实验提供了直接的量化依据：即便 Executor 是完全未经微调的基础模型，仅凭高质量计划就能将执行性能提升34.39%；与全程使用 frontier 模型相比，这种异构分工可以降低约90% 的成本。ReWOO 论文本身也指出了同一方向：将推理模块从 175B GPT-3.5 蒸馏到 7B LLaMA，在保持性能的同时大幅压缩参数规模。这个范式的本质是：规划是认知密集型工作，执行是操作密集型工作，两者对模型能力的需求不对称，没有理由用同一个模型全程处理。
Ralph Loop 的核心思想来自 agent 工程实践，严格来说它不是一种推理设计模式，而是一种基于 context 管理和门控验证的长程任务治理机制。LLM 会忘事，那就别让它记太多，用context 刷新代替 context 积累。名字取自《辛普森一家》里憨厚健忘的 Ralph Wiggum，比喻 AI agent 不记得上次失败、每次重新来过的特性。具体机制：把长程任务提前拆成独立子任务列表，每次迭代 agent 从全新 context启动，只处理当前一个子任务；执行完毕后对照预设验收标准（通常是自动化测试）进行门控验证；通过则把状态写入文件/git commit，清空 context，用新鲜 agent 接手下一子任务；不通过则当前迭代重来。进度活在文件里，不活在 LLM 的记忆里——这个设计绕过了 context 随任务推进膨胀的问题，也把每个子任务的验收标准前置为系统设计的一部分。
这五种范式在单 agent 框架内就可以覆盖相当广泛的任务类型，目前落地的agent工程项目还是以react为为主体设计思路实现的比较多，但可以混合其它设计范式的思想，例如结合Plan-and-Execute添加对子任务的动态调整特性，从成本节约角度考虑采用易购模型分工，长时任务增加部分可控的门控Ralph设计等。
2.单 agent 在哪里开始撑不住
单 agent 有几个结构性天花板，当真正触碰到这些边界时，才需要考虑多 agent 架构：
上下文窗口被填满（context pollution）。所有状态都存在同一个 context 里，当任务横跨多个领域、需要同时维持大量工作记忆时，上下文会被稀释。OpenAI Codex 官方文档把context pollution / context rot作为引入多 agent 的核心技术动机之一。Stanford 的「lost-in-the-middle」研究给出了量化依据：关键信息在 4000 token context 开头准确率 75%，放中间跌到 55%。这是单 context 在高信息密度下的结构性退化，不是 prompt 写得不好的问题。
需要真正的并行执行。单 agent 天然串行—当任务结构是「同时从十个数据源收集信息再汇总」时，单 agent 只能排队，时延线性叠加。
不同子任务需要截然不同的领域深度。同一个 system prompt 很难让 agent 在法律条文解析和财务模型计算上都做到足够深，通才在需要专家判断的场景是软肋。
需要系统性的 Maker-Checker。生成内容和审查内容的是同一套参数和同一个 context，自我审查的可靠性结构上有限。
错误需要跨任务隔离。单 agent 的统一 context 会让一处错误的中间结果被后续所有步骤看到，错误无法被隔离。
3.引入多 agent 之后：四种设计模式的选择
触碰到上述边界之后，不是“要不要用多 agent”的问题，而是“用哪种多 agent 架构模式”的问题。OpenAI Codex 给出了一个明确的能力渐进升级路径：先用 Skills 封装可复用能力，再用 MCP 连接外部系统，最后才是 Multi-agents—“当你准备好把嘈杂或专业化的任务委派给子 agent 时”再引入多 agent。
LangChain 把主流 MAS 设计模式归纳为四种，核心区别在于协调方式、状态管理和上下文隔离程度
Subagents（中央协调）：主 agent 负责协调，把专用 subagent 作为工具调用；subagent 无状态，主 agent 维护全局上下文。优势是强上下文隔离、支持并行调用、集中控制；代价是每次交互多一次模型调用，结果要经主 agent 转述。适合多域任务需要并行执行，且不需要 subagent 直接与用户交互的场景（个人助手协调日历/邮件/CRM，研究系统委派领域专家）。
Skills（渐进式加载）：技术上仍是单 agent，但能按需加载专用提示和知识—LangChain 称之为「准多智能体架构」。Agent 启动时只知道 skill 名称和描述，skill 被激活时才加载完整 context。优势是轻量、用户全程直接交互、不同团队可独立维护不同 skill；代价是 skill 不断加载会导致 context 累积膨胀。适合单 agent 需要大量可能的专业化方向、但不需要强制约束能力边界的场景（coding agent、创意写作助手）。
Handoffs（状态驱动转交）：活跃 agent 根据对话上下文动态切换—当前 agent 通过工具调用触发状态转换，决定下一个接管的 agent。状态跨对话轮次保留，支持顺序解锁工作流。优势是自然的多轮对话体验，上下文在 agent 间无缝延续；代价是状态管理更复杂，且无法并行执行。适合需要按阶段收集信息的客服流程、多阶段对话体验、能力需要前置条件才能解锁的场景。
Router（并行分发与合成）：路由步骤对输入分类，并发分发给专用 agent，汇总结果。Router 通常无状态，每次请求独立处理。优势是并行执行效率高，不同知识域完全隔离；代价是无对话历史时会重复路由开销。适合多垂直领域知识库、需要同时查询多个来源再合成答案的场景。
在进行四种multi-agent的模式选择时可以参考这个选择依据
然而multi-agent相比单agent最明显的一个问题就是token消耗的剧增，按Anthropic 的多智能体研究系统提供的数据：使用并行 subagent 协作的架构，比单 agent Claude Opus 性能高出 90.2%，但 Token 消耗增加约 15 倍。OpenAI Codex 的实际使用场景印证了这个代价何时值得付出：高度并行的复杂任务，如大型 codebase 探索、多步 feature 实现计划—这类任务天然可以拆分为独立子问题并行处理，多 agent 的协调开销被并行收益抵消。
Anthropic 在 Claude Code 中实践了一个更细的区分，补充了 LangChain 四种模式没有覆盖的维度。LangChain 的分类是按协调方式（谁来协调、怎么传递任务）来划分的；Anthropic 的区分则是按agent 间通信强度来划分的，两者是正交的视角。他们把多 agent 协作拆成两种不同强度：Subagents（子 agent 在主 session 内被召唤，完成任务后汇报，无独立 context，适合快速聚焦的工作单元）和 Agent Teams（多个 Claude 实例各自拥有独立 context window，可以互相通信、挑战彼此的结论、自主协调，team lead 负责统筹，适合需要真正并行探索的复杂任务）。选择核心判断只有一个：工作单元之间需不需要互相通信—如果只是分工汇报用 Subagents，如果需要 agent 间共享发现、互相质疑则用 Agent Teams。代价也随协调强度线性增长：Agent Teams 的 token 消耗显著高于单 session，在顺序依赖强、同文件操作多的任务上反而不如单 session 或 Subagents 有效。
无论选择哪种模式，OpenAI Codex 文档给出了一个适用于所有 MAS 设计的核心原则：「最好的 role 定义是 narrow and opinionated—给每个 role 一个清晰的任务、匹配这个任务的工具面、以及防止它漂移到相邻工作的指令」。Anthropic 自己的多智能体研究系统工程实践也印证了这一点：当他们早期允许 lead agent 给出模糊指令时，多个 subagent 会重复探索同一方向，或遗漏关键信息,后来他们给每个 subagent 明确了任务目标、输出格式、工具范围和任务边界，协调质量才大幅改善。
03
MAS 特有的生产挑战
把系统从单 agent 升级到 MAS，不是把单agent能力直接做累加乘法，而是复杂度呈现指数增长趋势。在《Why Do Multi-Agent LLM Systems Fail?》这篇论文中，UC Berkeley 的研究者从 7 个主流 MAS 框架收集了1,642 条执行轨迹，建立了一个系统性的 MAS 失败分类框架（MAST），识别出 14 种细粒度失败模式，归入三大类：
FC1 系统设计问题占 44.2%，是最主要的失败根因。五种模式：不遵守任务规范（FM-1.1，10.98%）、不遵守角色规范（FM-1.2，0.5%）、步骤重复（FM-1.3，17.14%，通常因轮次配置过于僵化）、上下文丢失（FM-1.4，3.33%）、无法识别任务完成（FM-1.5，9.82%）。具体的案例：ChatDev 被要求生成「每日随机词」的 Wordle 游戏，prompt 中明确写了「不要固定词库」，系统仍然反复输出硬编码词典，即便强化 prompt 也无效，根源在于 MAS 的角色设计和任务解析结构本身存在缺陷。
FC2 智能体间协调失败占 323%。 六种模式：推理与行动不一致（FM-2.6，13.2%，占比最高）、任务目标漂移（FM-2.3，7.40%）、未主动求证就继续执行（FM-2.2，6.80%）、对话意外重置（FM-2.1，2.20%）、忽视他方输出（FM-2.5，1.90%）、隐瞒关键信息（FM-2.4，0.85%）。例如Phone Agent 的登录 API 要求传入手机号，但 Phone Agent 未向 Supervisor Agent 说明这一格式要求；Supervisor Agent 也未主动求证，双方反复尝试错误凭证直至任务失败。表面是信息缺失，根源是 agent 无法准确建模对方的信息需求，论文称之为多 agent 场景下「theory of mind 的崩塌」。
FC3 任务验证缺失占 23.50%。三种模式：过早终止（FM-3.1，7.82%）、不完整验证（FM-3.2，6.82%）、错误验证（FM-3.3，6.66%）。例如一个 ChatDev 生成的国际象棋程序通过了代码编译和注释检查，却因未验证实际棋规而接受非法棋步，浅层检查（能否编译）替代了深层检查（能否正确运行），系统认为任务完成，实际输出不可用。
研究还发现了一个现实存在的工程问题，大多数团队在 MAS 失败时本能地去优化 prompt，但 MAS 的失败大多数不是 prompt 问题，MAS 失败的根源是系统级的协调架构缺陷，你无法通过调指令解决系统级的协调失败。 仅改善 ChatDev 的 agent 角色规范（让 CEO agent 拥有最终决策权），在不换模型、不改用户 prompt 的情况下，任务成功率提升+9.4%；在输出管道加入高层目标验证步骤，提升+15.6%。但论文也明确指出，这些局部修补仅对单一失败模式有效，7 个框架的整体实测失败率仍在 41%–86.7% 之间。
笔者在构建生产级多 agent 内容生成系统的过程中也体会到这一点，当 orchestrator 的职责边界开始模糊时，第一反应往往是去调整提示词或拆分函数，但真正的问题从来不在那里，而在于编排层的设计，以及不同控制层与治理层间的边界在结构上设计不清晰，导致编排的子agen存在完成子任务失效的情况时有发生，相关内容在后文的架构设计部分会具体展开。
04
Harness Engineering：
工程主战场在模型外面
理解了 MAS 的复杂性，我们可以清晰的看到agent项目，特别是multi agent项目，只是完成demo级别的效果展示难度并不大，真正有挑战的是将agent落地到生产实现可靠，可维护，可持续优化迭代的控制和治理，这就需要从架构设计和技术实现上来进行系统工程化，但是并不能将传统的软件工程直接套用在agent工程上，因为传统的软件工程大体都是确定性的，而agent的本质是概率决策，存在各种”不确定性”，那如何实现将这种”不确定性”的技术方案发挥智能推理决策的同时保持工程可接受的交付和运行性能呢？
解法不是试图消除不确定性，而是在 agent 的外部构建一套与其推理逻辑解耦的运行环境，agent 的 orchestrator 负责怎么做-任务分解、路由、replan，这套外部环境则负责“如何有效执行”，包括工具调用的权限约束、context 的策略管理、全链路可观测、安全门控等。治理、控制、安全不是和agent编排并列的模块，而是包裹在编排之外、让编排结果可信的基础设施。这就也就是最近我们经常看到的一个概念 - Harness Engineering。
Harness 这个词来自马具：缰绳、轭具、挽带构成的完整配件组，把马的力量引导到车辆上。马凭自己的判断决定往哪里跑、跑多快；马具不参与这个决策，它在外部管控马的力量如何被传导、约束越界行为、防止脱轨。这个词进入工程词汇后，软件工程里的 test harness 使用了这个概念：它是外部于被测软件的执行环境（Wikipedia），负责驱动测试运行、收集结果，但不执行被测组件本身的业务逻辑。而Agent harness 对应的就是：存在于 agent 的推理逻辑外部，不干预 agent 内部如何决策，但确保agent的行动在受控的环境中被执行、被追踪、被约束在安全边界内。
2026 年 2 月，OpenAI 的实战报告让 harness engineering 在 agent 工程圈正式破圈。OpenDev 论文（arXiv 2603.05344）给出了比较精确的技术区分：scaffolding 负责第一个 prompt 之前的 agent 组装（system prompt 编译、tool schema 构建、subagent 注册）；harness是之后持续运转、与 agent 推理逻辑解耦的外部运行层，包括tool dispatch、context compaction、safety enforcement、session persistence等。
MAS harness 是把多个 LLM 推理单元协调成可靠整体的运行环境，覆盖多 agent 协作协议、跨 agent 上下文管理、状态持久化与同步、安全隔离与权限边界、生命周期治理等一切模型之外的工程工作。
在 MAS 里，这个逻辑可以进一步拆清楚：编排层负责解决「怎么协作」- 任务分解、agent 路由、状态同步、replan，是系统的调度大脑；harness负责解决「如何安全稳定地运行并持续治理」- 权限约束、预算控制、错误拦截、全链路追踪、经验沉淀，是让编排结果能被信任、被审计、被持续改进的运行环境。没有Harness的约束，控制，管理，编排层就难以实现可控可持续的工程化落地实现。
Anthropic 自己的工程实验给出了一个MAS harness的工程实例。他们用 16 个 Claude agent 并行编写了一个 Rust 实现的 C 编译器——从零开始，能编译 Linux 内核——历经近 2,000 个 Claude Code session，耗费约 $20,000 的 API 成本，最终产出 10 万行能在 x86、ARM 和 RISC-V 上构建 Linux 6.9 的编译器代码。这个实验最核心的工程教训不是模型有多强，而是：绝大部分精力花在设计 Claude 周围的环境，包括测试体系、任务锁机制、反馈循环等。测试验证器稍有不精确，Claude 就会优化错方向；没有清晰的任务同步机制，多个 agent 会重复锁定同一子任务。Harness 设计的质量直接决定了 16 个 agent 能否形成合力，而不是各自内卷。
所我们可以看到强如opus 4.6这样的模型，在使用multi-agent架构完成复杂任务上，也需要投入大量精力在Harness上。这背后的逻辑也好理解，模型越强，可授权的自主范围越大，harness 反而越重要，因为人的角色从具体实现迁移为如何治理。 模型能力越强，放大风险的能力越高，围绕模型的基础设施需要与之匹配的工程密度。OpenClaw 的安全事故，包括恶意 skill 分发、prompt injection 劫持、越权操作等，主要原因可以为归类 harness 层的缺位，与底层模型能力的关联反而是次要因素
05
MAS 协调拓扑：
选错了就是给自己挖坑
在进入Harness架构设计之前，我们还有必要先厘清 MAS 核心的设计选择-协调拓扑。它直接决定了系统在规模化时是越跑越稳还是越跑越乱。
Supervisor（中央协调） 是最直觉的模式：一个中央 Orchestrator 管理所有 agent 的交互——接收用户请求、分解子任务、委派给专用 agent、验证输出、汇总结果。所有通信流都经过同一个枢纽。优点是实现简单、调试清晰、全局状态一致、单一责任追溯；代价是 Orchestrator 本身成为性能瓶颈和单点故障。适合合规性要求高、需要强可追溯性的场景（金融风控、医疗审批流程）。Northwestern Mutual 借助 Amazon Bedrock 的 supervisor agent 框架把内部开发者支持的响应时间从小时级压缩到分钟级。Anthropic 在 Claude Code 中的Subagents 是这一拓扑的典型实现——主 session 充当中央协调者，subagent 无状态、完成任务后汇报结果，多个 subagent 可并行调用，但彼此不直接通信。
Hierarchical（分层协调） 是对 Supervisor 的扩展：顶层 Orchestrator 负责高层规划，中层 Coordinator 负责子领域协调，底层 Worker 负责具体执行。这一结构把认知负载按层分配，避免顶层 Orchestrator 被细节淹没，同时保持整体可控性。适合大型复杂任务，如软件工程（Claude Code 的多实例并行模式）、深度研究（先并行信息收集再分层汇总）。
Mesh（对等网络） 让 agent 直接点对点通信，无中央控制节点。弹性最强，单点故障不会级联扩散。学术上，这一拓扑已有明确的适用场景支撑：Google/MIT 的 MAS 扩展研究（arXiv 2512.08296，2025 年 12 月）发现，去中心化拓扑在动态网页导航任务上比中央化高出 9.2%（中央化仅 +0.2%）——当任务本身高度动态、局部状态比全局路由更重要时，P2P 决策的优势才会显现。「多 agent 辩论」是 Mesh 最成熟的学术形态：多个 agent 互相批判彼此的回答，A-HMAD（2025）在引入异构 agent 后，在六个 benchmark 上取得 4–6% 的绝对精度提升，传记事实错误减少超 30%。
纯 Mesh 在生产环境极少落地，根本原因是可控性问题。去中心化意味着没有单一的全局状态持有者：当 agent A 和 agent B 同时修改共享资源、消息在网络中循环、某个 agent 的错误在 P2P 链路中无限放大时，没有任何一个节点有完整的视图来发现和干预。这与工程系统对可观测性、可审计性、可回滚性的基本要求直接冲突。合规性要求高的场景（金融、医疗）更是完全无法接受这种不确定性。
但目前有这样的落地工程化案例，保留 P2P 消息能力，但在 Mesh 之上叠加一个 lead agent，形成 Hybrid 结构。Claude Code 的 Agent Teams 就是这样的设计，teammate 之间可以直接点对点发消息、互相质疑、并行探索，这是 Mesh 的通信模式；但始终有一个 team lead 负责全局规划、任务分配和最终整合，这保留了 Supervisor 的可控性。纯 Mesh 试图让秩序从局部规则中涌现，Agent Teams 的选择是：涌现归涌现，但不放弃中央视图。
目前行业对 Mesh 的基础设施投入集中在通信协议层，例如Google 的 A2A（Agent-to-Agent）协议已获 150+ 家机构支持，现由 Linux 基金会维护，解决的是跨框架、跨厂商 agent 之间的互操作问题，本身不绑定任何拓扑，Supervisor、Hierarchical、Mesh 均可使用它通信，但目前还没有形成类似MCP这样的通用协议影响力。
另外Google DeepMind「科学化 agent 系统扩展」研究发现：超过 4 个 agent 后，如果拓扑设计不当，准确率增益开始饱和甚至下滑，这就是所谓的「协调税」（Coordination Tax）。结构化拓扑能把多 agent 协作稳定在有效区间，而无结构的「agent 袋子」会在规模化时放大错误而不是放大能力。
06
四层治理架构 + 经验闭环：
AI-Native 架构设计
理解了 MAS 协调的本质，就能理解为什么需要一套原生设计的分层工程架构，而不是在传统 DevOps 框架上打补丁，因此基于对harness的理解与近期的mas工程实践，将这套agent harness engineering的核心架构设计为四层，将 MAS harness 分解为知识供给、执行编排、风险门控、治理运营四个职责边界清晰的功能层，以全链路观测采集信号，以经验通道将轨迹沉淀定向反哺，三者协同发挥作用，构成在生产运行中持续进化的 MAS 治理闭环。考虑到MAS复杂度高于单agent，在MAS中生效的Harness工程架构应用范围可以覆盖单agent，所以后文提到的harness的架构设计都以MAS为基准进行设计
07
知识供给层：不是仓库，
是主动的信息生态
定位：MAS 中各层推理的信息上游，为执行编排、风险判断、治理决策提供知识基础。与其他层不同，这一层的问题往往不在本层直接暴露，而是沿依赖链向下传递，在输出质量上间接显现，所以这一层是影响agent知识加工处理的源头环节。
1.三类知识，本质不同
参数化知识存在于模型权重中，静态、有截止日期，更新成本极高。它构成 agent 的基础推理能力，但无法覆盖部署后发生的事情，也无法在运行时动态扩展。在对agent使用的模型进行选型时，除了本身fc等能力，还需要明确记录使用的模型的知识边界，避免对截止日期之后的内容产生不合理预期；领域专用 agent 考虑微调以强化特定领域的参数化知识密度。
非参数化知识通过 RAG Pipeline 在推理时动态注入。对 MAS 场景有一个特殊的挑战：跨 agent 的知识一致性—当 Planner agent 和 Executor agent 在同一任务中使用同一知识库时，需要保证检索版本的一致性，否则两者基于不同版本文档做出的决策会产生冲突，导致协调失败。混合检索（语义相似度 + 结构化过滤 + 时效性权重）是 MAS 场景的基础能力要求。
经验知识是三类知识中唯一随运行时间单调增长的部分，也是 MAS 系统最核心的长期竞争要素。它来自经验沉淀通道的提纯产物：成功/失败/边界案例库、高质量执行轨迹摘要。经验知识检索时按任务相似度排列优先级，让 agent 在面对类似任务时从「历史上怎么做过」出发，而不是每次从零重新推理。另外，经验知识的结构化趋势正在加速，以 Anthropic Agent Skills（2025 年 10 月推出，同年 12 月成为开放标准）为代表，行业开始将程序性经验封装为带有触发条件、执行策略和接口定义的可复用模块（SKILL.md），让 agent 按需动态加载，而不是每次从案例库自由检索。这也是经验知识从「记住发生了什么」向「记住怎么做」演进的标志性一步。
2.Context Engineering：把正确的信息送到正确的 agent 面前
知识供给层把知识资产备齐只是第一步，这一层在 MAS 中还有一个很棘手的问题：如何把正确的信息在正确的时机送到正确的 agent 面前。agent 的 context window 是有限且脆弱的资源，塞得太满会稀释关键信息，传递不当会让下游 agent 的推理偏离目标。这正是 Context Engineering 要解决的问题，也是知识供给层在 MAS 场景中比较有挑战性，需要持续投入资源优化的地方。
Chroma Research 2025 年的报告「Context Rot: How Increasing Input Tokens Impacts LLM Performance」覆盖了 18 个前沿 LLM（包括 GPT-4.1、Claude 4、Gemini 2.5）的实验揭示了一个棘手的现象：模型性能会随 context 长度增长出现不可预测的跌落，即 Context Rot（上下文腐化）。
同时Stanford 的研究还记录了「lost-in-the-middle」问题：将同一条关键信息放在 context 开头，准确率 75%；放在中间，准确率跌至 55%。在 MAS 中，这个问题被进一步放大：每个 agent 不仅要处理自己任务的 context，还要处理来自上游 agent 的中间结果。如果设计不当，agent 间传递的冗长输出会迅速污染下游 agent 的 context 窗口，使其遗忘初始约束、目标漂移。
Context Rot 还有一个容易被忽视的元层面：它不只发生在 agent 的 context 里，也会发生在工程师推进长周期 MAS 重构时自己的工作 context 里。 随着多轮计划叠加和阶段性结论累积，同一份计划会混入大量中间判断、过时结论和过渡设计—继续在同一上下文里硬推收尾，只会放大误判。这个现象在使用AI coding工具时经常会遇到，对于相对复杂的任务，一个窗口持续对话修改很多轮之后，性能会出现明显下降。
所以对运行链路周期链路更长的 MAS 架构重构而言，对运行过程的关键checkpoint同样进行上下文管理，就是一种必要的治理手段：把已达成的阶段成果、仍未收口的问题、已经失效的旧判断全部固定下来，基于更窄的新 context 继续推进。这和 agent 系统里的 context compaction 是同一个道理—不是中断工作，而是避免旧上下文继续污染后续判断，Context Engineering在知识供给层发挥着关键知识压缩，管理，更新，维护的作用。
08
执行编排层：MAS 的调度大脑
定位：MAS 任务执行的控制中枢，不只是单个 agent 的「规划器」，也是多 agent 协作网络的调度大脑。编排层只管「做什么、谁来做、如何协调」，不包含对应的业务规则和权限判断，这是整个架构可演化性的关键解耦点。这一层主要是mas编排逻辑，可以如上述提到的使用多种拓扑组合，这部分涉及到的mas编排架构主要是我在自己mas项目上用到的架构。
1.Orchestrator 在 MAS 中的职责边界
在 MAS 场景下，Orchestrator 承担的职责远超单 agent 的任务规划，它是整个 agent 网络的大脑：
任务分解与 agent 路由：将用户意图解析为结构化任务图（DAG），识别哪些子任务需要专用领域 agent（Domain Specialist），哪些走通用执行 agent（General Executor），哪些需要验证 agent（Validator）做第二视角检验。路由决策的质量直接决定系统的性能上限。
协调拓扑的动态选择：根据任务特性选择 Supervisor / Hierarchical / Mesh 拓扑，而不是固定一种。时效性要求高的并行任务偏向 Mesh；合规性要求高的任务偏向 Supervisor 串行审批；复杂长链路任务偏向 Hierarchical 分层分发。这需要 Orchestrator 在运行时具备任务特征识别和拓扑动态配置能力。
跨 agent 状态同步：维护全局任务状态，协调 agent 间的依赖关系，管理并行执行中的资源竞争，以及处理部分 agent 失败后的状态回滚或补偿策略，这是 MAS 比较复杂的工程挑战，也是大多数生产系统失败的集中地带。Cursor 2026 年 1 月的工程报告记录了一个典型案例：20 个 agent 并发协作时，锁竞争就已经把有效吞吐压到 2-3 个，agent 失败时持有的锁无法释放，系统直接挂起——最终不得不放弃全局状态同步，改用层级隔离结构绕开这个问题。
Replan 与协调恢复：当某个 agent 执行失败或输出质量不达标，触发局部 replan。相比单 agent 的 replan，MAS 的协调恢复需要同时考虑已完成的并行子任务状态，避免全局回滚的浪费。成熟的 Replan 策略会记录所有历史修订及触发原因，这既是调试的依据，也是治理层根因分析的核心输入。
2.Orchestrator / Workflow / Policy 三分法：最容易混淆的设计边界
在实际工程中，「执行编排层」内部最容易出现的错误是把三类不同性质的职责堆在一起—这会导致某一层能力升级时，需要牵连其他层一起重构，这也是我近期mas项目所遇到。比较推荐的做法是在编排层内部维护三个独立的状态层：
Orchestrator / 编排层负责：任务 DAG 的生成、子 agent 的选择与路由、并行/串行决策、结果综合、re-plan。这是整个系统里最应该随经验积累被替换的部分——从「硬编码启发式」向「经验驱动的自主规划」演化，是合理的自主化路径。
Stateful Workflow / 控制层负责：阶段转换、重试策略、补偿操作、人工审批节点、长任务的状态持久化与恢复。这里的「Workflow」不是指编排任务的工作流，而是指一种确定性的状态控制结构—执行路径在设计时固定触发特定的状态流程。它定义的是「这个任务在整个生命周期里应该经过哪些阶段」，而不是「哪个 agent 来做」。Azure AI Foundry 把 Connected Agents（agent 协作与委托）与 Multi-Agent Workflows（状态持久化、重试、错误恢复）设计为两个独立能力层，背后逻辑正是如此，前者处理概率性的 agent 推理，后者处理需要确定性保障的过程控制。
Policy Runtime / 门控层负责：权限控制、预算上限、数据域边界、授权审批、动作拦截、审计日志、风险处置。这是最不应该随「自主化」趋势而消融的部分。模型越能行动，越需要把外部约束做成独立的 runtime，而不是嵌入 agent 的 prompt 里，这样才能在mas编排决策之外实现更可控的人类介入控制。
这三分法直接影响演化路径的正确判断：未来迁移时应该被替换的，是 Orchestrator 里的任务分解和调度启发式；不应该被一起替换的，是 状态workflow 里的阶段控制和 Policy Runtime 里的审批、授权、预算、数据边界、可观测性与审计机制。模型自主性逐步接管的是「如何做」，还不是「能不能做」。
这个判断我在自己的mas项目里有非常具体的体感。我们的多 agent 系统名义上采用了 orchestrator + subagents 的结构，但随着功能迭代，orchestrator 逐渐吸附了越来越多的职责：不只是在下发任务，还同时承担了流程控制、门控触发、fallback 组织、状态持久化和一部分兼容逻辑。系统越来越像一个规则系统，而不是以 LLM 决策为核心的混合编排。重构时真正难的部分不是「把哪些函数迁出去」，而是看清了一个更本质的事实：ownership 只是换了宿主，却没有真正迁走。把规则从 orchestrator 挪到 policy、adapter 或 controller，并不等于完成解耦，只要控制语义还在代码里显式生成 plan、activation 或 replan，系统就没有回到「more LLM decision, less hard-coding」的目标上。三分法的价值不在于文件结构的整洁，而在于每一层的决策权归属是否真的对齐，这个是从踩坑里得出的结论，不是从设计原则里推导的。
3.Orchestrator 的核心调度机制
Orchestrator 在运行时要解决三个具体的调度问题，这是执行编排层区别于单 agent 规划器的主要工程挑战。
任务分解粒度：子任务切得太细，协调开销压过执行收益；切得太粗，context 又回到了单 agent 的问题。Anthropic multi-agent research system 的工程实践给出了一个有效的判断标准：每个子任务需要有明确的目标、输出格式、工具范围和边界，上文智能体研究系统工程例子提到过，他们早期允许 lead agent 给出模糊指令，结果多个 subagent 重复探索同一方向，或者各自独立得出矛盾结论；任务描述标准化之后，协调质量才明显改善。
subagent vs 工具调用的边界：这是 Orchestrator 比较容易判断错的决策点。错误地把工具调用包装成 subagent，会引入不必要的协调轮次和 token 开销；错误地把需要独立推理上下文的子任务塞进同一个 agent，会导致 context 污染和认知过载。判断标准可以参考这个：这个子任务需不需要独立的推理上下文—如果只是确定性的数据获取或格式转换，用工具；如果需要 agent 独立判断、独立搜索、独立处理不可预测的中间状态，才应该是独立 subagent。
成本控制内建：协调本身是有成本的。SupervisorAgent（ICLR 2026）在 Orchestrator 中内建轻量级监督机制，对三类高风险交互（错误纠正、低效行为引导、过长观测净化）进行实时干预，在 GAIA benchmark 上将 Token 消耗平均降低 29.68%，其中 Level 2 任务降幅达35%，输出方差同步下降63%，这个收益不是来自减少 agent 数量，而是来自减少每个 agent 的无效行为。这也给我们提供了一个新思路，成本控制不应该是事后的运营问题，在 Orchestrator 的调度逻辑里也可以进行优化。
4.轨迹产出：MAS 的经验原料工厂
执行编排层是整个闭环的经验原料工厂，MAS 的轨迹比单 agent 更复杂，也更有价值。每条 MAS 轨迹需要记录：全局协作计划（含拓扑结构和 agent 角色分配）、每个 agent 的完整执行细节、跨 agent 的消息传递完整记录、协调事件（等待、重试、回滚）、全局 Token 消耗的 per-agent 分解，以及协调失败和恢复操作的完整时间线。这些轨迹是治理层提炼协调模式经验的原料，轨迹记录质量直接决定闭环能产出什么质量的协调经验资产。
09
风险门控层：MAS 的安全边界
需要更高工程密度
定位：整个 MAS 与外部世界之间的确定性安全中间件，独立于编排逻辑，可独立升级和回滚。在 agent 行动边界介入，对动作结果进行风险审查、权限校验、输出质检和安全拦截，决策结果可以为「放行 / 拦截 / 升级人工审批」等。正因为它在推理链条之外，才能作为不受链条污染的独立检查点。
MAS 里的 agent 会真实地操作外部世界，写文件、调 API、发邮件、执行代码。这些动作一旦触发，部分是不可逆的。谁来决定这些动作「能不能真的执行」？答案不能是 Orchestrator，因为它是动作的发起者；不能依赖模型内部的自我审查，因为推理本身可以被外部内容操控。门控层的价值在于它是整条 agent 推理链条之外不受链条污染的决策节点。
这种「推理链条内部无法自我审判」的脆弱性在生产环境中已有两类具体表现。
第一类：错误在 agent 边界静默传播。 与传统微服务不同，agent 的失败不产生明确错误码—它产生语义错误，格式完全合法，但内容已经偏离。这类错误被下游 agent 当作可信输入消费，沿链放大。MAST 的全量数据（1,642 条轨迹）显示，验证缺失（FC3）占所有失败的 23.5%，是第三大失败根因；Pathak et al.（2025）专门研究了 agent 轨迹中的静默失败检测问题，指出这类错误「不产生任何报警信号，却持续偏离预期行为」，是 MAS 中最难调试的一类故障。
第二类：外部内容变成恶意指令。 agent 读取的每一份外部内容—网页、文档、邮件、代码注释，在模型眼中都和系统指令位于同一个 token 流里。模型没有可靠的机制区分「任务内容」和「嵌入其中的攻击指令」。这已经不是理论风险：2024 年 8 月，Slack AI 被通过 RAG 污染实现数据窃取；2025 年，GitHub Copilot 的 CVE-2025-53773 确认攻击者只需在公开仓库的代码注释里嵌入指令，就能让 Copilot 在受害者本地执行任意代码；同年，Cursor 的 CVE-2025-59944 则是一个路径大小写漏洞让 agent 读入了错误配置文件，随即执行了其中的隐藏指令。OWASP 2025 LLM Top 10 将 prompt injection 列为第一大漏洞，出现在 73% 的生产 AI 部署中。Lakera 的结论直接：「真正的安全边界是模型周围的一切，而不是模型本身。」
两类风险的共同点是：它们都发生在 agent 的行动边界，发生在推理过程完成之后、动作真实触发之前的那个间隙。这个间隙只有外置的门控层能覆盖。
1.MAS 场景的额外门控挑战
MAS 的门控层面临几个单 agent 没有的特殊挑战：
跨 agent 的权限传递问题：agent A 被授权执行某操作，它调用了 agent B，agent B 是否自动继承这个权限？答案是否定的，每个 agent 的操作都在自己的权限边界内独立审批，不通过 agent 链的委托传递权限。这是防止权限提升攻击的关键，也是 OpenClaw 被恶意 skill 利用的根本漏洞所在。
级联错误的门控：当一个 agent 失败后，依赖其输出的下游 agent 不应该用错误的中间结果继续执行。门控层需要对 agent 间传递的结果进行质量检查，而不只是对最终输出进行检查—错误在 agent 链中静默传播，是 MAS 协调失败中最难调试的一类。
协调行为的整体风险评估：单个 agent 的每一步操作单独看都在边界内，但组合起来可能触发系统级风险（如多个 agent 联合消耗超出资源预算、多个 agent 的分布式写操作导致数据一致性问题）。门控层需要具备全局视角，对整个协作计划进行整体风险评估。
2.三层防御与规则体系
硬性规则（不可绕过）：数据访问边界、操作黑名单、单任务 Token/成本硬上限、法律合规约束，以及 MAS 特有的跨 agent 权限隔离规则。这类规则在任何情况下不可被 agent 的任何推理绕过，基于确定性代码实现而非 LLM 判断。
软性规则（触发审批/降级）：风险评分阈值、已知高风险执行模式匹配、低置信度输出的二次确认，以及协调异常检测—如 agent 间消息循环、无终止条件的协调循环，这类问题不触发单步操作层面的规则，但会在系统层面造成成本爆炸。
动态规则（来自经验沉淀）：从历史失败案例归纳的风险模式，从成功轨迹提取的安全协调路径白名单，以及 MAS 特有的「危险 agent 组合」识别—某些角色组合在历史上反复出现协调失败，可以作为软性预警触发人工审批。治理层识别风险模式后，先以「警告模式」灰度生效，观察误报率，确认有效后转为正式拦截规则。这是让门控策略随经验积累持续演化的机制。
10
治理运营层：把协调经验变成组织资产
定位：把 MAS 运行痕迹转化为组织级资产，是经验沉淀的主归属，也是整个闭环「越跑越好」的驱动引擎。
1.日志和资产是两回事
MAS 产生的日志比单 agent 复杂得多，价值也更大—其中包含了大量协调经验，这是单 agent 系统无法产生的知识类型。但日志本身不是资产。
原始 MAS 轨迹是日志：记录了所有 agent 的执行和协调行为，存储成本高，不能被 agent 直接检索复用。
经提纯的协作案例是资产：通过mas生成运营积累的轨迹经过分析处理后，既可以包括特定任务使用怎样的任务编排，工具配置，上下文策略可以完成的比较好，还可以包含「什么类型的任务用什么 agent 拓扑」「哪类协调失败由什么根因触发」「哪种 agent 角色分配在类似场景下被证明有效」等策略性知识，可以被 Orchestrator 在下次面对类似任务时直接检索参考。治理层的核心工作就是持续地把日志转化为资产。这不是一次性的数据工程项目，而是需要系统性设计的持续流程。
2.三层评估：自动 + 模型辅助 + 人工
自动评估（量化维度）：任务完成率、各 agent 的执行效率、协调开销（agent 间消息数量/总 Token 的比值，过高说明协调效率低）、门控触发率、全局 Replan 频率、成本/价值比。这些指标全部来自结构化轨迹，完全自动化。
模型辅助评估（语义维度）：协调路径合理性、agent 角色分配恰当性、子任务分解质量、输出内容质量—重点是评估 MAS 特有的「协调质量」维度，提供自动评估无法覆盖的判断。
人工评估（高价值边界区域）：聚焦机器判断不确定的区域—复杂协调失败的根因分析、多 agent 系统级行为的意外涌现、协调策略最佳实践标注。人工聚焦边界，而非全量人工，这是让人工投入边际效率最大化的关键设计。
3.MAS 失败根因路由
11
观测体系与经验沉淀：让 MAS 越跑越好
1.MAS 的可观测性是调试的基础设施
MAS 的调试复杂度是单 agent 的数倍。研究数据：调试多 agent 系统所花费的时间是单 agent 的 3–5 倍，工程团队 40% 的 sprint 时间可能都花在排查 agent 行为上，而不是构建新功能。根本原因是：失败发生在 agent 之间的边界上，而不是在某个 agent 内部，传统监控完全看不见这层。
全链路 Trace 基础设施必须覆盖：每次 LLM 调用的完整 prompt + response、工具调用 I/O、agent 间消息传递的完整记录、协调事件（启动、等待、重试、失败）、门控决策记录（包括被拒绝的操作）。没有这层基础设施，MAS 对工程师来说是一个不透明的黑箱—一旦出问题，只能靠猜。
2.经验沉淀飞轮
经验沉淀通道连接四层，驱动闭环持续旋转。完整流向：
- 执行编排层产出结构化 MAS 轨迹（包含跨 agent 协作的完整记录）
- 观测体系捕获，标准化格式，跨 session 关联，统一存储
- 评估体系筛选，质量标注 + 分类标签，过滤噪声
- 治理层提纯（主归属）：协调案例生成、元数据丰富、协调规则草案生成
- 知识层承载（主存储）：协调模式库、任务案例库，支持相似任务检索复用
- 门控层吸收：规则草案经灰度生效，丰富动态规则库
MAS 场景下，经验沉淀特别需要防止「成功偏差」：如果只从成功轨迹中学习，系统会逐渐丧失对非标准协调情况的适应能力。生产级经验提纯需要主动保证协调失败案例、局部成功案例（任务完成但成本超预期）和边界案例的覆盖比例—这些往往比「典型成功」更有策略学习价值。
12
三阶段演化：从预定义到经验驱动
在笔者实际构建 MAS 系统的过程中，有一次重构印象很深。一个项目在初期运行良好，但随着任务复杂度上升，系统开始出现一个典型的偏移：Orchestrator 里的 LLM 驱动决策逐渐被规则硬编码替代—遇到不确定场景就加条件判断，边界情况也开始出现 if-else的逻辑。表面上系统还在跑，但它已经不是一个 LLM 原生的 MAS，而是一个被部分规则掺杂进入编排决策，如果不加以干预，就会滑向more rules，less autonomous的方向。
复盘后定位到的根因是：Harness 工程上缺少多层次治理的解耦设计。治理逻辑、安全约束、协调启发式混在同一层里互相污染，导致每次遇到新的边界情况，AI coding在处理这种复杂问题时倾向于「再加一条规则」，而不是分析系统架构是否存在不合理的设计。后面通过架构重组，将这几类关切拆分到各自归属的层，系统才重新回到 LLM 驱动的轨道。
三阶段演化框架就是从这类经历里提炼出来的，其实不算是一个预设路线图，而更像是一个诊断工具：大多数 MAS 项目卡在阶段一，是因为没有建立经验闭环；滑向规则堆积，往往是在阶段一和阶段二之间缺少了治理解耦这道关卡。而mas系统本身是一个复杂的工程系统，通过分阶段实现也是将架构解耦设计后，在不同的阶段划分不同架构层任务优先级，然后进行逐步优化迭代，构建兼顾mas”自主性”与”可控性”平衡，适配LLM技术发展趋势的一种路径选择。
一旦实现了分层架构设计支持mas的harness治理，那mas系统就可以朝着持续学习的经验驱动方向发展，以下是预期的三阶段经验驱动的mas演化路径
1.阶段一：先把闭环跑通，不要过度设计
起点应该是最保守的配置：多agent的拓扑编码，agent 角色预定义，门控依赖静态规则，治理以人工标注为主。协调模式库为空，这是正常的，不是缺陷，因为这个阶段的首要任务是把执行轨迹记录下来，还不是从中学习。
不建议在这个阶段就开始堆复杂的动态路由和自适应调度。没有经验数据支撑的「智能」，实质上很难进行实质性的动态适应优化。阶段一的健康指标有一个：每次执行都有完整的可审计轨迹，这是后续一切演化的原料，当然前提是实现了架构层面的知识-编排-门控-治理四层的解耦。
2.阶段二：经验开始反哺系统
进入阶段二的信号不是时间，而是轨迹库积累到足以从中发现重复出现的协调模式，哪些 agent 组合在哪类任务上稳定奏效，哪些转接点反复出错，哪些门控规则产生了过多误报。
这时候 Orchestrator 的任务分解可以开始引用历史成功路径，不再每次从零推理；门控层从治理层接收自动归纳的协调安全规则，动态规则开始替代部分静态规则；评估从人工主导转向自动为主、人工兜底。这一阶段最重要的感知指标是：运营成本在下降，同时任务完成质量在上升。如果两者没有同向移动，说明「经验」还没有真正进入系统的决策路径。
3.阶段三：飞轮效应开始显现
当协调模式库足够丰富、门控规则大比例来自自动归纳、Orchestrator 的预定义启发式被经验驱动的规划大量替代，系统会出现一个明显的质变：它开始表现出越运行越强的特征，而不只是「运行得更多」。新任务的协调质量因为相似历史任务的积累而提升，失败率的下降速度开始超过任务复杂度的增长速度。
4.自主化的边界：什么不应该被「自主化」接管
三阶段里逐步被替换的，只有 Orchestrator 层的任务分解和调度启发式。stateful Workflow 层的阶段控制与 Policy Runtime 的审批、授权、预算、数据边界，这些不应该随着「自主化」一起交出去。
回到最初提出 Harness Engineering 的出发点：这些不被交出去的工程化实现，不是为了约束模型能力，而是为了给模型能力提供一个可以安全释放的结构。没有 Harness，自主化程度越高，系统就越脆，每一次模型判断失误都直接暴露在外部世界。有了 Harness，自主化和可控性不再是对立的：模型在框架内部可以充分发挥，框架的边界本身保证了系统不会因为单次判断失误而整体失控。这正是三阶段演化能够成立的前提-不是因为模型越来越强就可以去掉 Harness，而是因为 Harness 在，模型才可以将其决策推理应用到容错性更低，但价值更高的场景
13
结语
当下大模型和agent技术都发展飞快，最后我们来探讨一个问题：调用相同模型 API 的两个团队，会有持久的竞争差距吗？
答案是肯定的。模型是有截止日期的静态资产，API 对所有人开放。但同一套技术思路和类似的技术栈，最终实现的效果，特别是生产场景的agent体验，却会存在很大差别，一个重要的因素就是agent harness engineering的实践差异，结合文中提到的这套架构逻辑，实现效果更好的会属于工程设计实现更完善、运行时间更长的系统：
任务级案例库：「这类任务在这个系统里跑过一千次的执行经验」，新任务可以直接检索复用，竞争者从零开始。
协调模式库：「什么类型的任务用什么 MAS 拓扑在这个业务场景下被证明有效」—这是 MAS 系统特有的、只能从真实运行中积累的知识，无法靠设计推演，无法从通用数据集中学习。
失败模式库：「这类 agent 组合在第三步容易出协调失败，需要提前在门控层配置人工审批」—积累了这类知识的系统，运营成本随时间下降；没有积累的系统会持续为同类失败付出代价。
这三类资产有一个共同特点：投入时间越长、运行次数越多，优势越大，且不会因为模型升级而归零。它们无法被快速复制，无法被购买，不能靠迁移到更强的模型来补偿。
这里有一个值得反复确认的判断：构建生产级 MAS，主线从来不是「模型越来越强，所以工程结构可以越来越少」，而是「模型能力、工具协议、上下文工程、评测体系、治理运行时要一起升级」。正确的架构不是把一切都塞进 orchestrator，也不是把所有规则都硬编码成 workflow；而是把自主决策（orchestrator）、状态流（workflow）、治理边界（policy runtime）拆成能独立演进的层，让经验积累主要发生在 orchestrator 这一层，而治理层作为基础设施保持长期稳定。
构建生产级 MAS，本质上是在构建一套让这条护城河持续加深的工程基础设施。Harness 工程不是运营 agent 的辅助工作，它就是核心工作本身，因为随着模型核心能力的增长，很多具体的业务实现会被模型能力吃掉，但对模型本身构建agent系统的控制和治理不会。
人机协作的分水岭正在从人类主导完成具体工作走向agent开始主导完成某项具体工作，但是工作完成的质量如何(评估)，工作完成存在什么漏洞(风控)，什么工作交给什么样的agent(决策分配)，这些工作的价值却越来越高，人类更多价值也会体现在价值判断和决策，或者用当下一个时髦的词来说就是”taste”,taste并不是一天两天就能积累出来，它需要你接触，你思考，你质疑，你接受，才能形成自己独特的一套价值判断体系，这也是模型能力迭代所无法替代的。
参考文献
END
✦
✦
大会推荐
✦
4月21-22日，智猩猩主办的2026中国生成式AI大会将举行，设有开幕式，AI算力基础设施、大模型、AI智能体3大专题论坛，以及OpenClaw、LLM强化学习、大模型记忆等6场技术研讨会。其中，OpenClaw最强轻量平替nanobot团队负责人黄超、Claw-R1项目负责人程明月等学者专家将带来报告分享。
✦
✦
入群申请
✦
智猩猩矩阵号各专所长，点击名片关注
