眼下虽然 Loop Engineering 虽是最前沿最热门的话题，但落地较少。Mulit-Agent（多智能体）仍是解决现实问题且可落地的最优解。但多智能体落地复杂任务时，都绕不开三个老问题：流程不稳定、上下文爆炸、异常处理随机。
带着日常工作中遇到的问题，我用业余时间启动了一项研究与实验，最终收敛到一套架构思路上。这篇文章把整个过程记录下来，希望能给同样在摸索的人一个参考。
主流方案的三条路径，各有一个死结
路径一：早期单一超级Agent
这条路径最简单：一个Agent包揽所有事。它自己拆任务、自己干、自己检查，人只管发指令和收结果。
优势是快。 不需要设计多Agent协作协议，不需要考虑状态传递，Demo跑起来非常惊艳。
问题是不可控。 一个Agent的上下文窗口是有限的。当任务链条超过十几步，它一定会出现三类故障：
注意力衰减：长上下文中部的约束被遗忘，阶段三定的标准，阶段五就丢了
流程跳步：审批节点被“自主优化”掉，因为它觉得这次没问题
异常处理不一致：同一个错误今天重试、明天跳过，没有稳定策略
Claude的Artifacts模式把产出物做了结构化隔离，Codex在任务拆解上做了增强，但它们本质上还是单一Agent模型。让一个LLM既管流程又管产出，等于让一个人既当裁判又当运动员，还要自己记比分。
路径二：编排器调度模式
这是目前最主流的多Agent设计。一个编排器Agent负责规划、拆解、调度，多个Worker Agent负责执行。
Kimi Agent Swarm是这派的代表。编排器拿到任务后，先做规划，然后把子任务分发给专业Worker，Worker干完活汇报，编排器再决定下一步。
优势是有分工了。 规划的和干活的分开了，Worker可以专注在自己的角色里，产出质量比单一Agent高。
问题是编排器本身还是LLM。 它依然在猜token，不是在执行状态机。当任务足够复杂——比如一个需要7个阶段、40多个子任务的开发项目——编排器自己就会成为瓶颈：
它的上下文窗口会塞进越来越多的历史——初始规划、每次Worker汇报、异常处理记录、人的反馈。到了中后期，上下文膨胀到几万字，注意力必然丢失
流程规则写在提示词里，它在某次推理中跳过阶段关口的概率不为零。这不是bug，是LLM的本质特征——它不执行规则，它预测文本
异常处理策略不稳定。Worker失败是该重试、跳过还是补偿？编排器今天选A，明天可能选B
Kimi Agent Swarm在短任务上表现很好，但它把“流程推进的确定性”和“任务决策的智能性”压在了同一个Agent身上。这是架构层面的耦合，调提示词解不开。
路径三：框架工具模式
LangChain不代表一种架构，它是一种工具。它给你Chain、Agent、Tool、Memory这些积木，让你自己搭。
优势是灵活。 你想怎么组合都行，没有强制的范式约束。
问题是它不提供流程范式本身。 你依然要在代码里自己实现阶段管理、人审挂起、异常补偿、防膨胀检查。LangChain帮你调用LLM，但不帮你管状态。开发者还是要在工程层面对付上下文管理和流程稳定性的问题，LangChain只是让这件事做起来稍微顺手一点。
路径四：子代理（Sub-Agent）模式
除了上述三条主流路径，还有一种被广泛采用的修补手段：子代理模式。做法是让主Agent在遇到复杂子任务时，临时派生一个新的Agent去处理，处理完把结果返回，子Agent销毁。
这看起来解决了两个问题：一是把大上下文切成了小块，二是让专业任务有专注空间。AutoGPT的部分实现、LangChain的AgentExecutor中的某些用法，都采用了这个思路。
但它没有解决根本问题。
第一，主Agent依然是流程瓶颈。 子代理处理完一个子任务后，结果还是要汇入主Agent的上下文。十个子任务跑下来，主Agent的上下文该膨胀还是膨胀。子代理只是把执行外包了，决策权和状态整合的压力原封不动地留给了主Agent。
第二，子代理之间没有结构化的接力机制。 主Agent把三个子任务分给三个子代理，这三个子代理各自为战。子代理A的产出里藏着一个关键风险信号，子代理B的产出里有一处跟子代理A矛盾，子代理C跑偏了却没人纠正。主Agent拿到三份结果后，要在已经膨胀的上下文里做交叉验证和冲突调解——这恰恰是LLM注意力最容易丢失的环节。
第三，子代理没有“阶段感”。 它只在一层进行拆分——拿到任务，拆成子任务，分出去，收回来。但真实世界的复杂工作不是一层能解决的。一个开发项目从需求到上线，需要在不同阶段做完全不同性质的决策：需求阶段要追问和收敛，规划阶段要权衡和取舍，执行阶段要应对意外和补救，验证阶段要检查和质疑。这些决策的性质不同，对上下文的需求不同，甚至对Agent的“性格”要求都不同。子代理模式把所有决策压在同一层，用同一个主Agent的同一种判断方式处理所有问题，这本身就是一种架构上的妥协。
所以子代理模式只是在无限延长一个必然崩溃的结构。 它没有阶段边界带来的上下文隔离，没有关口检查带来的质量保障，没有结构化的回退机制。它只是让一个不堪重负的主Agent又多了一群需要它操心的下属。
共同病灶：把两件性质相反的事交给同一个东西
四条路径看似不同，底层的毛病是一样的：
确定性流程（状态管理、规则执行、格式校验）和智能决策（任务拆解、内容审核、异常补偿）被混在一起处理了。
LLM适合做后者。它不适合做前者，就像你不能指望一个天才画家同时也是瑞士钟表匠——他画着画着就可能忘了拧发条。
那解决方案就很自然了：把它们拆开。
但光拆开还不够。拆完之后，你还需要一个机制，把复杂任务本身也拆开。不是拆成平行的子任务，而是拆成有先后次序、有质量门槛、有明确边界的阶段。每个阶段做完，必须过一道门才能进入下一阶段。这就是阶段-关口的设计起点。
我的方案：控制面 + 领航员 + 阶段-关口范式
架构上我分了三层，流程上引入阶段-关口范式：
人（用户） ←→ 控制面（程序） ←→ 领航员（LLM）
←→ Worker（多个专业Agent）
整个任务的推进，不是一股脑拆完就分派，而是被严格切分成多个阶段。每个阶段有明确的上下文边界和退出条件。阶段内是一套固定的循环范式，阶段结束时必须通过关口检查。
控制面
控制面是一个确定性的程序，不是Agent，不调用LLM做决策。
它是整个系统的状态中枢和规则执行引擎。它的职责：
持有全部任务状态（当前阶段、每个任务的状态、所有产出物、异常日志）
驱动流程推进（阶段进入、任务派发、关口检查、阶段终态决策）
执行确定性校验（输出格式、字段完整性、语法检查、阈值比对）
管理人审交互（挂起、恢复、超时）
在需要“动脑子”的节点，调用领航员
所有需要记忆的东西都留在控制面里。控制面不思考，它只执行规则。这意味着流程铁律永远不会被LLM遗忘或跳过——因为LLM根本不碰流程。
领航员
领航员是一个被控制面按需调用的LLM智能服务。它的工作方式像一个无状态函数：
控制面每次调用它，传一份精心裁剪过的上下文过去
它返回一个结构化的决策结果
调用结束，它的上下文清空（在同一阶段内保留精简的决策日志，保证策略连贯；阶段结束彻底清空）
领航员是整个系统中唯一能做判断的角色。它负责：
阶段设计（任务启动时，从8个阶段中裁剪出专属序列）
任务规划（每个阶段开始时，拆解任务、分配角色、定义输出标准）
内容审核（Worker产出后，判断文档逻辑是否完整、方案是否合理）
异常补偿（任务失败时，分析缺口、生成补偿或替代方案）
关口风险扫描（阶段结束时，判断是否存在未覆盖的重大风险）
一个比喻：控制面是船体和航行规则，领航员是站在高处画航线的人，Worker是船员。领航员不做具体工作，它只做判断和规划。判断完就交还控制面，自己不再记得任何事。
阶段-关口：把复杂任务切成有质量门槛的片段
这是我的方案与子代理模式及其他主流路径最根本的分别之一。我们不把任务看成一层可拆分的子任务树，而是看成多个性质不同的阶段的序列。
一个阶段就是一个独立的上下文边界。阶段启动时，领航员拿到的是这个阶段的专属上下文——阶段目标、上一阶段的产出物摘要、全局约束——而不是整个任务的历史洪水。阶段结束时，所有该阶段的上下文被归档，领航员被重置，下一阶段从一个干净的状态开始。
每个阶段内部是一套固定的循环范式：
阶段进入 → 规划 → 人审 → 执行循环 → 关口检查 → 终态决策
展开来看：
1. 规划。 控制面调用领航员，生成阶段任务计划。计划包含任务清单、依赖关系、每个任务的输出契约和安全标记。输出契约分两层——确定性契约（格式、字段、语法）由控制面自动校验；内容性契约（章节完整性、逻辑合理性）由领航员审核。
2. 人审。 控制面将计划摘要提交人审。通过则执行，驳回则领航员重规划。两次驳回后强制进入人工编辑模式，人直接修改任务序列。所有驳回原因被记录，作为领航员下次规划的约束输入。
3. 执行循环。 控制面按依赖图派发任务给Worker。Worker完成后，控制面先做确定性校验，再调用领航员做内容审核。失败时，控制面先做规则判定（重试次数、是否关键任务），简单情况直接处理；需要决策时调用领航员生成补偿或替代方案。
4. 动态响应。 执行中如果发现遗漏或外部依赖变化，控制面调用领航员分析缺口并生成新任务，插入依赖图。系统预设了防膨胀约束——任务数上限和时间上限，超限则强制挂起人审，避免一个阶段无限膨胀。
5. 关口检查。 所有任务终态后，控制面执行自动检查项：全部产出物完成确定性校验、全部通过内容审核、关键指标达标、无未处理异常。必要时调用领航员做风险扫描，判断是否存在未被已有任务覆盖的重大风险。全部通过则进入终态决策，否则挂起人审。
6. 终态决策。 通过则进入下一阶段。回退则调用领航员重新规划，回到本阶段起点或指定前序阶段——保留失败原因作为领航员的约束输入，但清空回退阶段的上下文，避免错误的中间状态污染后续。暂停则等待外部输入。
阶段-关口解决了什么
第一，上下文隔离，从根本上阻断膨胀。 这是子代理模式没做到的事。子代理模式外包了执行，但主Agent的上下文依然在积累。阶段-关口把整个任务的生命周期切成多个独立的上下文窗口，领航员一次只面对一个阶段。阶段结束，上下文归档，下一个阶段全新开始。即使在最长的“执行”和“验证”阶段，也有阶段内上下文上限保护和强制检查点机制来进一步分段。
第二，质量关口，每个阶段都有硬性的交付物验收。 子代理模式没有机制保证子代理的产出物质量——主Agent拿到结果后就继续了，中间没有结构化的检查点。阶段-关口要求每个阶段结束时，自动检查项全部绿灯、内容审核全部通过、风险扫描无遗漏，才能进入下一阶段。这不是提示词里的建议，是代码里的铁律。
第三，决策性质的分离。 探索阶段的决策需要发散和质疑，规划阶段的决策需要收敛和权衡，执行阶段的决策需要快速响应和务实补救，验证阶段的决策需要严谨和挑剔。这些决策需要不同的思维模式，甚至需要不同的Agent角色来承担。阶段-关口让每个阶段可以调用最适合的Worker组合——比如验证阶段调用“质疑者”这个独立角色来做风险扫描，它的上下文与其他Worker完全隔离，不受团队共识影响。这在子代理的一层拆分里是做不到的。
第四，结构化的失败处理。 子代理失败，主Agent需要临时想办法，处理策略不稳定。我的方案里，失败分三层处理：控制面的规则判定（可重试？关键任务？）、领航员的补偿决策（替代方案是什么？）、阶段关口的终态决策（回退还是暂停？）。每一层有明确的职责边界和处理逻辑。回退时，失败原因作为约束输入传给领航员，但回退阶段的上下文被清空——既利用了失败的经验，又不让错误的中间状态污染重来。
这样做的好处
流程确定性。 阶段关口、人审挂起、异常触发——这些都是代码，可测试、可调试、不会漂移。
注意力受控。 领航员每次只处理一个阶段内的问题。阶段结束时彻底清空，下个阶段全新开始。阶段内也有上下文上限保护。这是子代理模式和单Agent模式都做不到的。
异常处理有章法。 Worker失败时，控制面先执行规则判定，简单情况直接处理。只有复杂情况才调用领航员。补偿策略由领航员在阶段内连贯做出，不会前后矛盾。严重失败触发关口暂停，由人介入决策。
智能可升级。 领航员可以用最强模型，编码Worker可以用性价比高的模型，质疑者Worker可以用另一个厂家的模型做交叉验证。所有Agent在控制面眼里都是平等、可插拔的。
一个简化版的任务流程
这套架构的运转逻辑，用一次典型的开发任务就能看清楚。
任务启动时，控制面调用领航员做阶段设计。领航员分析任务特征——这是一个需求明确的中等复杂度开发项目，跳过触发、探索和定义阶段，直接进入规划、执行、验证、交付。阶段序列经人确认后，冻结到控制面。
规划阶段。 控制面调用领航员生成任务计划。领航员返回结构化计划：需求分析→技术方案→任务拆解→排期。控制面提交人审，通过后按依赖图派发Worker。需求分析员产出需求文档，控制面校验格式通过，领航员审核内容通过。以此类推，四个任务全部完成。关口检查：全部产出物完成审核、关键指标达标、无异常、风险扫描无遗漏。通过，进入执行阶段。规划阶段的上下文归档，领航员重置。
执行阶段。 控制面调用全新的领航员——它手里只有阶段目标和上一阶段的产出物摘要，没有规划阶段的历史包袱。领航员生成执行计划：搭建脚手架→开发申请模块和审批引擎（并行）→前端开发→自测。执行中，审批引擎的Worker发现需求里有一个规则模糊：“超过3天包括3天吗？”控制面调用领航员做缺口分析。领航员插入一个补充需求澄清任务，暂停审批引擎，等澄清完成后再恢复。防膨胀约束检查：任务数未超上限，自动执行。Bug修复、前端联调、自测通过。关口检查全部绿灯，进入验证阶段。
验证阶段。 领航员重新初始化，生成测试计划。测试员执行中发现一个Bug：总监审批后状态未更新。控制面捕获失败状态，规则判定为关键任务，调用领航员做补偿决策。领航员插入Bug修复任务和回归测试任务。全部完成后关口检查，人审验收通过，进入交付阶段。
交付阶段。 领航员规划部署和文档任务。生产部署被标记为高危，控制面自动挂起人审。人批准后执行部署，生成用户手册。关口通过，任务完成。
整个过程中，领航员在每个阶段开始时都是“新人”——但控制面通过精心裁剪的上下文（阶段目标+上阶段产出摘要+全局约束），让它能快速进入状态，又不会被历史信息淹没。人在全过程只跟控制面交互，感知为与一个懂全局的智能体对话，但背后有领航员在做规划判断，有多个Worker在产出内容，有质疑者在关口挑刺。
写在最后
多智能体不是提示词工程问题，是系统工程问题。
市面上的主流方案——单一超级Agent、编排器调度、框架工具、子代理打补丁——普遍把流程控制和智能决策混在一起，把复杂任务拆成一层子任务来处理，导致流程漂移、上下文爆炸、异常处理随机三个老问题反复出现。
我的解法建立在四个支点上：把确定性交给代码，把智能交给LLM，把上下文按阶段严格隔离，让每个阶段过质量关口。
控制面是系统里最无聊、最机械的部分，也恰恰是让整个系统可靠运转的骨架。领航员只在需要思考时被叫醒，每次醒来手里都是一份清爽的阶段地图。阶段-关口范式保证了复杂任务可以被切成多个独立且高质量的推进单元，而不是一层子任务的混乱委托。
这四句话和阶段-关口的设计构成了整套架构的基石。目前我们还在持续细化，落地验证后会再分享实践心得。如果你也在被多智能体系统的不稳定折磨，或者发现子代理模式只是在延长崩溃的时间线，希望这个思路能给大家提供一个不同的方向。
本文由Ai辅助完成