先说结论：如果你的团队正准备上一个多智能体系统，并且在"全部自研编排"和"直接用通用框架"之间反复横跳，那我强烈建议你把注意力放到第三种选项上——混合架构。我们在实际落地一个跨部门协同的智能任务系统时，最初踩过纯自研和维护上的坑，也体验过通用框架的黑盒失控感，最后把两者拆开、分而治之，才真正把多智能体从"demo很好看"推进到了"生产环境能稳定跑"的状态。这篇文章不聊空泛的概念，只讲我们做架构选型时看到的事实、对比过的维度、最终设计的混合架构长什么样，以及在落地过程中那些文档里不会写的坑。如果你也在纠结多智能体系统怎么搭，希望这份实录能帮你少走点弯路。1. 先讲背景：多智能体系统为什么值得做，又为什么难做多智能体系统的核心逻辑并不复杂：把一个大任务拆成若干子任务，交给不同角色、不同工具的Agent协同完成。比如我们做的企业内部智能助手，最初只是"你问我答"，模型越强，单次回答的质量越高。但业务方很快就提了新需求——不是回答问题，而是解决问题：你要帮我查三个系统的数据，做交叉分析，生成一份报告，再按流程发给对应负责人审批。这个链条里有检索、有计算、有推理、有判断、有写文档能力、还有和外部系统的交互。指望一个Agent一个上下文全部搞定，样本量大点就会乱。于是第二阶段的方案是让Agent拥有工具调用能力，让它自己去查数据库、调API。这解决了一部分问题，但很快发现单Agent的工具调用链一旦超过四五个步骤，成功率就直线下降。原因也很直接：模型在超长上下文里容易遗忘早期的中间结果，决策会漂移；工具返回的异常情况多了，Agent自己也不知道该找谁兜底。这时候多智能体系统的价值就体现出来了——把长链路拆成短链路，每个Agent只负责自己擅长的一段，通过架构保证任务流转，而不是让一个Agent扛下所有事。但"多Agent"听起来美好，工程上却是另一回事。Agent之间怎么通信？任务状态谁维护？其中一个Agent挂了怎么办？多个Agent并行跑的时候上下文怎么隔离？这些问题，恰恰就是架构选型的核心矛盾所在。我们当时面临的抉择是：自己写一套编排逻辑，还是直接用市面上的通用编排框架。那个阶段我们花了大概两周做技术预研，结论很有意思：两种路线都有明显短板，而短板恰好互补。这也直接促成了后面混合架构的出现。先别急着看结论，我把两条路线的真实差异摊开聊一聊。2. 自研编排与通用框架的真实差异，我把各自的底牌摊开2.1 通用框架解决什么，又遗漏了什么市面上成熟的多Agent框架大概分三类：第一类是把流程画成状态图、由调度器按图执行的显式工作流框架；第二类是让Agent以群聊方式自由对话、自主决策的协作框架；第三类是给每个Agent定义角色和目标、由管理器统一分派的团队框架。每一类都有自己擅长的场景。显式工作流框架的优点是流程可控、可复现，适合能提前画出步骤的固定任务；自由对话式的框架灵活度高，agent协作靠模型自组织，适合开放式探索，但结果不可预期；团队框架最接近人类组织协作，manager分配任务、成员执行，比较贴近真实的业务分工。通用框架真正的价值在于：它把Agent执行过程中的基础设施问题帮你提前解决了。Agent实例的生命周期管理、大模型调用的上下文维护、工具注册和自动调用、简单的错误恢复、断点续跑，这些如果全部自己从零写，工作量相当可观。而且好的框架社区活跃，踩过的坑都会体现在版本更新里，文档和讨论也丰富。我们用它做原型验证，几乎一个下午就能跑通一个"两个Agent协作完成任务"的demo，速度非常快。但框架的问题同样明显。首先是可解释性——框架内部对Agent之间消息的处理逻辑、状态变更的触发条件，很多时候是一个黑盒。任务一旦跑得不符合预期，你很难判断是模型决策问题还是框架状态流转问题，调试成本反而比自研更高。其次是耦合性——过度依赖框架的抽象方式，业务逻辑会被框架的范式绑架。比如你想在某个节点执行一个自定义的复杂并行策略，框架没提供这个接口，你可能得绕过框架直接改内部代码，这样一旦升级框架就会冲突。还有一点是我们后期才深刻体会到的：通用框架大多面向"Agent与Agent"的协作，但它对"业务流程与业务状态"的建模非常弱。多智能体系统如果只是Agent之间的对话游戏，那没有实际业务价值；可一旦要对接真实业务流程，就涉及审批流、超时、重试、幂等、权限校验、审计日志这些硬性要求。这些内容框架不是不能做，但硬塞进去会非常别扭。2.2 自研编排的底气与包袱自研编排的核心优势一句话就能说清楚：一切皆可控。任务状态维护，我们写代码；Agent之间的调度逻辑，我们写代码；重试策略、超时策略、降级策略，都是显式的代码逻辑。业务人员能参与进来review，测试人员可以写针对状态迁移的单元测试，出了问题打断点调试，不用去猜框架做了什么。对我们这种需要对接公司内部多个系统、有强审批合规要求的场景，自研的吸引力是巨大的。权限控制要精确到数据表级别，审计日志要记录每一步是谁、在什么时间、基于什么上下文做的决策——这种定制化需求，框架给不了。但自研的代价也很沉重。首先是对团队的要求高：你得有人真正理解多Agent协作的底层机制，包括状态机、事件驱动、并发控制，而不是只会调API。开发周期也长，从设计到稳定运行，保守估计比用框架慢三到五倍。更头痛的是，调试多Agent系统的复杂度是超线性的：Agent越多，状态组合越爆炸，排错越困难。在没有可视化面板和成熟调试工具的情况下，纯自研团队需要额外搭建很多观测基础设施。2.3 一张表看清两条路的取舍对比维度通用编排框架全自研编排启动速度快，几天内能跑原型慢，前期设计开发投入大流程可控性受限于框架抽象能力完全由代码决定调试直观性黑盒较多，较难定位问题断点、日志、单测直接可用业务定制深度一般，特殊逻辑另辟蹊径无上限，但写多少全在自己框架升级风险接口变动可能影响项目无框架就无此风险生态与社区有现成组件和案例参考全部自己积累对团队能力要求较低，上手快较高，要懂底层设计这张表做出来以后，我们的判断其实已经清晰了：框架的"快"和自研的"可控"，恰好是对方缺失的。纯框架容易失控，纯自研周期太不可控。于是我们决定做一个改造——为什么不能让框架负责Agent内部的脏活累活，而我们自己掌握Agent之间的业务编排呢？这就是混合架构的雏形。3. 混合架构怎么落地：三层设计与一次完整任务的流转3.1 上层：自研业务编排层，把"业务流程"从框架手中拿回来混合架构的第一条原则：Agent系统里涉及业务语义的全部由自研代码控制。包括任务的拆解策略、Agent的选择路由、每个Agent的执行目标、超时与重试参数、任务完成与失败的标准、人工介入的时机。我们在这一层设计了一个显式的任务状态机，核心状态包括：等待中、执行中、等待外部输入、成功、失败、已取消。所有Agent的状态迁移都必须经过编排层，不允许Agent之间直接改状态。任何一次状态变化，都写入审计表，记录from、to、触发源、附带上下文摘要。代码上，这个状态机不是玩具。我们用了一张配置表来定义每个任务类型从哪个状态允许流转到哪个状态，非法流转会直接抛异常，让错误在开发期暴露而不是在线上静默发生。这一步看起来基础，但几乎决定了整个系统的稳定上限。我们见过太多多Agent项目，Agent乱改共享状态，最后数据都错乱了还查不出来根源。3.2 中间层：桥接层，隔离框架和业务的双向翻译混合架构最容易被忽略、但恰恰最核心的是中间桥接层。它的职责是把自研编排层发出的指令，翻译成通用框架能理解的Agent任务；再把框架执行过程中产生的事件，翻译回编排层的状态变更。我们在桥接层里维护了一个Agent注册表，记录每个Agent的能力描述、可调用工具、运行状态、当前关联任务。编排层要派任务时，不需要关心目标Agent在框架内部如何初始化，只需要提交一个统一的任务包：Agent标识、输入载荷、期望产出、回调地址、超时阈值。桥接层负责把任务包投递给框架对应接口，再监听框架回报的事件，转成编排层能消费的标准化事件。这个桥接层还承担了一个很重要的职责：把框架抛出的底层异常翻译成业务能理解的错误。比如"LLM上下文超限"会被翻译为"任务上下文过大，建议压缩检索内容"，"工具调用非法参数"会被翻译为"下游系统提示参数校验失败"。这听起来像小事，但没有这层翻译，排障时每个人都要先搞懂框架内部术语，沟通成本高得可怕。3.3 下层：框架执行层，把脏活杂活交给专门选手下层我们保留了通用框架的Agent执行能力：Agent实例生命周期管理、大模型调用的上下文窗口维护、工具调用的鉴权和执行、Agent内部推理循环、来自模型侧的异常时延等，全交给框架处理。这些属于通用能力，自己造轮子的边际收益很低，交给成熟框架反而稳定。特别说明一个点：Agent之间的直接对话，我们默认是关闭的。在框架层，每个Agent接收到的信息来自编排层的task包，Agent产出结果后把结果返回给编排层，由编排层决定下一步。这个设计大大降低了Agent间互相污染上下文的风险。如果你用的是图编排框架，可以把它配置成"节点输出必须显式声明"的严格模式，而不是允许自由边跳转。3.4 一个完整任务的流转示例拿我们最典型的"数据报告生成与审批"场景来演示混合架构的完整运转过程：用户提交需求后，编排层先创建一个主任务，状态置为等待中。接着调度器根据需求类型查Agent注册表，选出三个候选Agent：检索Agent、分析Agent、撰写Agent。这是路由阶段的决策，路由结果全部记录到审计表，包括候选Agent的评分依据。检索Agent在框架层执行，工作内容是查询三个内部数据源，输出一个统一格式的检索结果包。桥接层监听执行事件，执行成功后把结果包交给编排层。编排层更新任务状态为执行中，并判断下一步：如果检索结果包含关键字段缺失，则不走分析Agent，直接回调一个"需要补充检索条件"的人工介入事件；如果数据完整，则把任务包派给分析Agent。这一个分支判断，就是业务方最看重的可解释性——每一步都有据可查。分析Agent跑完后，生成分析结论和几个候选结论摘要。到这里，编排层不会直接让撰写Agent开工，而是先把结果推到一个"待确认"队列，由人工确认分析结论方向是否正确。人工确认后，编排层再给撰写Agent下发任务。这个人工介入点，在多智能体系统里非常关键，不是所有决策都应该交给模型自治，尤其是涉及数据判断和对外输出的环节。最后撰写Agent生成报告，编排层做完整性校验，然后调用下游审批系统发起审批流。报告产出后，所有Agent的执行记录、中间结果、token消耗和耗时全部汇总到一张任务明细表。整条链路跑完，自研层控制了所有业务转折点，框架层负责单个Agent节点的执行细节，中间没有任何一环出现职责模糊。4. 落地过程中的工程细节与稳定性设计架构选了混合只是个开始，真把它跑稳，需要在工程的细节上花大量功夫。我把我们踩过和见过的坑整理成几类，每一类都有对应的解法。4.1 Agent通信不能裸奔，消息总线要尽早设计多Agent系统最容易出的问题就是通信混乱。Agent直接互发消息demo里很好看，但生产环境你会遇到消息丢失、重复投递、消费顺序乱等一堆问题。我们在混合架构里没有让Agent之间直接通信，所有消息都走编排层的消息总线。总线用的队列是现成的消息中间件，每条消息带上taskId、sourceAgentId、targetAgentId、messageType、payloadVersion和时间戳。消费者按taskId做隔离消费，同一任务的消息顺序由消息队列的顺序投递保证。这样设计以后，任务从A变到B的过程中即使中间某个环节崩溃，重启后也能按队列积压消息恢复状态，而不是一片空白。有一个细节很容易被忽略：Agent执行结果和Agent发送的消息要区分开。执行结果是任务状态迁移的依据，应该走同步回调；Agent在过程中产生的过程性消息（比如思考日志、中间提示）走异步消息。把这两类混在一起，状态机逻辑就会变得混乱。4.2 状态机、幂等与重试：稳定性三件套多Agent系统里，任何一个节点都可能失败。大模型可能超时、返回格式异常、内容不符合预期；工具API可能抖动；网络可能闪断。所以状态机必须内置完备的超时和重试机制。我们的重试策略分成策略级和算子级两层。策略级重试针对整个Agent任务，比如当Agent返回内容格式不合法时，直接用同样的任务包重试一次，但会要求Agent参考上一次错误重新生成；算子级重试针对单次工具调用，比如网络超时，采用指数退避策略重试两次。关键是每次重试都携带requestId，下游系统根据requestId做幂等判断，避免重复扣减库存、重复提交数据这类严重事故。另外我强烈建议在状态机上再加一个"最大流转深度"限制。比如一个任务最多允许经过15次Agent状态流转，超过就自动终止并触发人工介入。这个数值不是拍脑袋定的，是我们统计了线上任务的流转分布，发现90%以上的正常任务都在这个范围内。有了这个限制，Agent陷入死循环时系统会自动熔断，而不是无限空转烧token。4.3 可观测性：没有traceID，多Agent排障就是灾难多Agent系统的排障难度比单Agent高一个量级，因为一个任务的失败可能发生在任意一个Agent节点上。我们没有哪个天才方法，靠的就是一个贯穿全链路的traceID。从任务创建开始，traceID就生成，并随着任务包、消息、事件传递给每一个Agent和工具调用。日志全部结构化输出，每一条都带taskId、traceId、agentId、节点名称和时间戳。排障时的第一步永远是按traceId查询全局时间线，看任务在哪个环节耗时最长、在哪个环节报错、报错前后上下文是什么。更进一步，我们把关键节点的输入输出做了快照存储。每个Agent的关键执行步骤的输入载荷和输出结果，都会以JSON格式入库存档。这不是为了存储，而是为了支持"回放调试"——线上某个任务出了问题，你可以把快照抽出来，在测试环境重新跑一遍同样的输入，观察Agent的决策过程。这个能力在我们后续优化提示词、调整路由策略的时候，帮了非常大的忙。5. 常见问题排查与避坑实录5.1 Agent陷入死循环，token烧完还没出结果症状是一个任务在同一个Agent之间来回跳转，状态机深度不断增长，token消耗飙升。排查trace后发现Agent把一个不确定的结果反复重试，每次生成结果都差不多，但每次都觉得自己"还差一点需要再验证"。解法就是上面提到的最大流转深度限制，外加一个"结果相似度去重"逻辑。当Agent连续两次产出结果相似度高于某个阈值时，编排层直接判定当前节点无法收敛，结束该Agent的执行并带上最后一次结果，交由后续分支或人工接管。这个阈值前期可以放宽一点，观察线上数据再逐步收紧，太激进会把正常的多轮迭代误杀。5.2 上下文超限，长任务跑到后半段开始失忆多Agent的优势本来是把上下文切小，但如果某个Agent承担了过重的分析任务，照样会把上下文撑爆。我们的做法有两层：一是编排层在派发task包时对输入载荷做了精简，只传与当前Agent任务最相关的字段，而不是把上游所有原始输出一股脑塞进去；二是给每个Agent配置了"记忆摘要"机制，长对话过程中定期把历史内容做动态摘要，用摘要替换早期原始内容，压缩窗口占用。一个血泪教训：不要相信模型"我记住了"这种输出，关键信息必须在编排层显式传参，而不是放在上下文里让Agent自己找。出了几次线上事故之后，我们定了一条规矩：所有任务包必须带上明确的目标字段和数据字段，Agent不需要靠回忆来完成任务。5.3 工具调用参数幻觉，把意图界面操纵当查询条件几次失败的共性是Agent把用户问题里不存在的条件当成查询参数传了下去。排查后发现，问题出在工具描述写得太模糊，模型对参数的可选范围产生了误解。后来我们把工具的字段schema全部改成了枚举严格模式，并加了参数合法性前置校验，编排层在调用工具前会先验一遍参数，不合法直接打回并要求Agent重新生成参数。这一条看上去简单，但对工具调用类Agent的成功率影响极大。建议所有工具接口都做一层参数校验的拦截器，宁可多一步校验，也不要让幻觉参数直接打到下游系统。5.4 框架升级导致的隐性行为变化框架版本升级后，有几个生产任务执行路径变了，排查半天发现是框架内部某个消息处理逻辑调整了。这就回到混合架构设计的初衷了：桥接层的价值就在这里。升级前我们会在测试环境跑一遍全量回放用例，对比关键Agent节点的行为差异。由于业务编排逻辑全在自己手里，框架层的变化被隔离在执行范围内，不会影响到业务状态机的正确性。这个设计不是我们保守，而是生产中必须有的隔离心态。6. 最后再分享几个我们定下的原则多智能体系统的架构选型没有标准答案，但我自己在整个落地过程中逐渐形成了几条判断原则，分享出来供参考。第一，尽量用框架处理通用能力，但永远不要让框架替你做业务决策。业务决策必须显式写在编排层里，用代码表达，而不是靠提示词暗示Agent去猜。第二，状态机越早建模越好。不要等Agent跑乱了再回头补状态约束。我们在设计阶段就先画清了所有任务类型的合法状态迁移关系，后面的开发测试都围绕这个模型进行，省了很多返工。第三，人工介入点不是"系统不智能"的遮羞布，而是生产系统的安全阀。尤其是涉及金额、权限、对外发布的节点，宁可牺牲一点自动化率，也要把好最后一道关。第四，多Agent系统的性能优化，前提永远是先量化。每个Agent节点的耗时、成功率、token消耗、平均流转深度，这些指标从第一天就要埋点统计。没有数据，你根本不知道瓶颈在哪个Agent，优化就无从谈起。第五，也是我最深的体会：不要迷信新框架，也不要迷恋全自研的掌控感。真正可靠的架构，是把"足够成熟的东西交给框架，把决定业务成败的东西握在自己手里"。混合架构不是我们的创意发明，它本质上是一种工程务实主义——用最合理的成本，换取最适合自己业务的可控性和效率。这条思路，放在多智能体系统里成立，放在其他很多系统设计里，同样成立。
先说结论：如果你的团队正准备上一个多智能体系统，并且在"全部自研编排"和"直接用通用框架"之间反复横跳，那我强烈建议你把注意力放到第三种选项上——混合架构。我们在实际落地一个跨部门协同的智能任务系统时，最初踩过纯自研和维护上的坑，也体验过通用框架的黑盒失控感，最后把两者拆开、分而治之，才真正把多智能体从"demo很好看"推进到了"生产环境能稳定跑"的状态。这篇文章不聊空泛的概念，只讲我们做架构选型时看到的事实、对比过的维度、最终设计的混合架构长什么样，以及在落地过程中那些文档里不会写的坑。如果你也在纠结多智能体系统怎么搭，希望这份实录能帮你少走点弯路。1. 先讲背景：多智能体系统为什么值得做，又为什么难做多智能体系统的核心逻辑并不复杂：把一个大任务拆成若干子任务，交给不同角色、不同工具的Agent协同完成。比如我们做的企业内部智能助手，最初只是"你问我答"，模型越强，单次回答的质量越高。但业务方很快就提了新需求——不是回答问题，而是解决问题：你要帮我查三个系统的数据，做交叉分析，生成一份报告，再按流程发给对应负责人审批。这个链条里有检索、有计算、有推理、有判断、有写文档能力、还有和外部系统的交互。指望一个Agent一个上下文全部搞定，样本量大点就会乱。于是第二阶段的方案是让Agent拥有工具调用能力，让它自己去查数据库、调API。这解决了一部分问题，但很快发现单Agent的工具调用链一旦超过四五个步骤，成功率就直线下降。原因也很直接：模型在超长上下文里容易遗忘早期的中间结果，决策会漂移；工具返回的异常情况多了，Agent自己也不知道该找谁兜底。这时候多智能体系统的价值就体现出来了——把长链路拆成短链路，每个Agent只负责自己擅长的一段，通过架构保证任务流转，而不是让一个Agent扛下所有事。但"多Agent"听起来美好，工程上却是另一回事。Agent之间怎么通信？任务状态谁维护？其中一个Agent挂了怎么办？多个Agent并行跑的时候上下文怎么隔离？这些问题，恰恰就是架构选型的核心矛盾所在。我们当时面临的抉择是：自己写一套编排逻辑，还是直接用市面上的通用编排框架。那个阶段我们花了大概两周做技术预研，结论很有意思：两种路线都有明显短板，而短板恰好互补。这也直接促成了后面混合架构的出现。先别急着看结论，我把两条路线的真实差异摊开聊一聊。2. 自研编排与通用框架的真实差异，我把各自的底牌摊开2.1 通用框架解决什么，又遗漏了什么市面上成熟的多Agent框架大概分三类：第一类是把流程画成状态图、由调度器按图执行的显式工作流框架；第二类是让Agent以群聊方式自由对话、自主决策的协作框架；第三类是给每个Agent定义角色和目标、由管理器统一分派的团队框架。每一类都有自己擅长的场景。显式工作流框架的优点是流程可控、可复现，适合能提前画出步骤的固定任务；自由对话式的框架灵活度高，agent协作靠模型自组织，适合开放式探索，但结果不可预期；团队框架最接近人类组织协作，manager分配任务、成员执行，比较贴近真实的业务分工。通用框架真正的价值在于：它把Agent执行过程中的基础设施问题帮你提前解决了。Agent实例的生命周期管理、大模型调用的上下文维护、工具注册和自动调用、简单的错误恢复、断点续跑，这些如果全部自己从零写，工作量相当可观。而且好的框架社区活跃，踩过的坑都会体现在版本更新里，文档和讨论也丰富。我们用它做原型验证，几乎一个下午就能跑通一个"两个Agent协作完成任务"的demo，速度非常快。但框架的问题同样明显。首先是可解释性——框架内部对Agent之间消息的处理逻辑、状态变更的触发条件，很多时候是一个黑盒。任务一旦跑得不符合预期，你很难判断是模型决策问题还是框架状态流转问题，调试成本反而比自研更高。其次是耦合性——过度依赖框架的抽象方式，业务逻辑会被框架的范式绑架。比如你想在某个节点执行一个自定义的复杂并行策略，框架没提供这个接口，你可能得绕过框架直接改内部代码，这样一旦升级框架就会冲突。还有一点是我们后期才深刻体会到的：通用框架大多面向"Agent与Agent"的协作，但它对"业务流程与业务状态"的建模非常弱。多智能体系统如果只是Agent之间的对话游戏，那没有实际业务价值；可一旦要对接真实业务流程，就涉及审批流、超时、重试、幂等、权限校验、审计日志这些硬性要求。这些内容框架不是不能做，但硬塞进去会非常别扭。2.2 自研编排的底气与包袱自研编排的核心优势一句话就能说清楚：一切皆可控。任务状态维护，我们写代码；Agent之间的调度逻辑，我们写代码；重试策略、超时策略、降级策略，都是显式的代码逻辑。业务人员能参与进来review，测试人员可以写针对状态迁移的单元测试，出了问题打断点调试，不用去猜框架做了什么。对我们这种需要对接公司内部多个系统、有强审批合规要求的场景，自研的吸引力是巨大的。权限控制要精确到数据表级别，审计日志要记录每一步是谁、在什么时间、基于什么上下文做的决策——这种定制化需求，框架给不了。但自研的代价也很沉重。首先是对团队的要求高：你得有人真正理解多Agent协作的底层机制，包括状态机、事件驱动、并发控制，而不是只会调API。开发周期也长，从设计到稳定运行，保守估计比用框架慢三到五倍。更头痛的是，调试多Agent系统的复杂度是超线性的：Agent越多，状态组合越爆炸，排错越困难。在没有可视化面板和成熟调试工具的情况下，纯自研团队需要额外搭建很多观测基础设施。2.3 一张表看清两条路的取舍对比维度通用编排框架全自研编排启动速度快，几天内能跑原型慢，前期设计开发投入大流程可控性受限于框架抽象能力完全由代码决定调试直观性黑盒较多，较难定位问题断点、日志、单测直接可用业务定制深度一般，特殊逻辑另辟蹊径无上限，但写多少全在自己框架升级风险接口变动可能影响项目无框架就无此风险生态与社区有现成组件和案例参考全部自己积累对团队能力要求较低，上手快较高，要懂底层设计这张表做出来以后，我们的判断其实已经清晰了：框架的"快"和自研的"可控"，恰好是对方缺失的。纯框架容易失控，纯自研周期太不可控。于是我们决定做一个改造——为什么不能让框架负责Agent内部的脏活累活，而我们自己掌握Agent之间的业务编排呢？这就是混合架构的雏形。3. 混合架构怎么落地：三层设计与一次完整任务的流转3.1 上层：自研业务编排层，把"业务流程"从框架手中拿回来混合架构的第一条原则：Agent系统里涉及业务语义的全部由自研代码控制。包括任务的拆解策略、Agent的选择路由、每个Agent的执行目标、超时与重试参数、任务完成与失败的标准、人工介入的时机。我们在这一层设计了一个显式的任务状态机，核心状态包括：等待中、执行中、等待外部输入、成功、失败、已取消。所有Agent的状态迁移都必须经过编排层，不允许Agent之间直接改状态。任何一次状态变化，都写入审计表，记录from、to、触发源、附带上下文摘要。代码上，这个状态机不是玩具。我们用了一张配置表来定义每个任务类型从哪个状态允许流转到哪个状态，非法流转会直接抛异常，让错误在开发期暴露而不是在线上静默发生。这一步看起来基础，但几乎决定了整个系统的稳定上限。我们见过太多多Agent项目，Agent乱改共享状态，最后数据都错乱了还查不出来根源。3.2 中间层：桥接层，隔离框架和业务的双向翻译混合架构最容易被忽略、但恰恰最核心的是中间桥接层。它的职责是把自研编排层发出的指令，翻译成通用框架能理解的Agent任务；再把框架执行过程中产生的事件，翻译回编排层的状态变更。我们在桥接层里维护了一个Agent注册表，记录每个Agent的能力描述、可调用工具、运行状态、当前关联任务。编排层要派任务时，不需要关心目标Agent在框架内部如何初始化，只需要提交一个统一的任务包：Agent标识、输入载荷、期望产出、回调地址、超时阈值。桥接层负责把任务包投递给框架对应接口，再监听框架回报的事件，转成编排层能消费的标准化事件。这个桥接层还承担了一个很重要的职责：把框架抛出的底层异常翻译成业务能理解的错误。比如"LLM上下文超限"会被翻译为"任务上下文过大，建议压缩检索内容"，"工具调用非法参数"会被翻译为"下游系统提示参数校验失败"。这听起来像小事，但没有这层翻译，排障时每个人都要先搞懂框架内部术语，沟通成本高得可怕。3.3 下层：框架执行层，把脏活杂活交给专门选手下层我们保留了通用框架的Agent执行能力：Agent实例生命周期管理、大模型调用的上下文窗口维护、工具调用的鉴权和执行、Agent内部推理循环、来自模型侧的异常时延等，全交给框架处理。这些属于通用能力，自己造轮子的边际收益很低，交给成熟框架反而稳定。特别说明一个点：Agent之间的直接对话，我们默认是关闭的。在框架层，每个Agent接收到的信息来自编排层的task包，Agent产出结果后把结果返回给编排层，由编排层决定下一步。这个设计大大降低了Agent间互相污染上下文的风险。如果你用的是图编排框架，可以把它配置成"节点输出必须显式声明"的严格模式，而不是允许自由边跳转。3.4 一个完整任务的流转示例拿我们最典型的"数据报告生成与审批"场景来演示混合架构的完整运转过程：用户提交需求后，编排层先创建一个主任务，状态置为等待中。接着调度器根据需求类型查Agent注册表，选出三个候选Agent：检索Agent、分析Agent、撰写Agent。这是路由阶段的决策，路由结果全部记录到审计表，包括候选Agent的评分依据。检索Agent在框架层执行，工作内容是查询三个内部数据源，输出一个统一格式的检索结果包。桥接层监听执行事件，执行成功后把结果包交给编排层。编排层更新任务状态为执行中，并判断下一步：如果检索结果包含关键字段缺失，则不走分析Agent，直接回调一个"需要补充检索条件"的人工介入事件；如果数据完整，则把任务包派给分析Agent。这一个分支判断，就是业务方最看重的可解释性——每一步都有据可查。分析Agent跑完后，生成分析结论和几个候选结论摘要。到这里，编排层不会直接让撰写Agent开工，而是先把结果推到一个"待确认"队列，由人工确认分析结论方向是否正确。人工确认后，编排层再给撰写Agent下发任务。这个人工介入点，在多智能体系统里非常关键，不是所有决策都应该交给模型自治，尤其是涉及数据判断和对外输出的环节。最后撰写Agent生成报告，编排层做完整性校验，然后调用下游审批系统发起审批流。报告产出后，所有Agent的执行记录、中间结果、token消耗和耗时全部汇总到一张任务明细表。整条链路跑完，自研层控制了所有业务转折点，框架层负责单个Agent节点的执行细节，中间没有任何一环出现职责模糊。4. 落地过程中的工程细节与稳定性设计架构选了混合只是个开始，真把它跑稳，需要在工程的细节上花大量功夫。我把我们踩过和见过的坑整理成几类，每一类都有对应的解法。4.1 Agent通信不能裸奔，消息总线要尽早设计多Agent系统最容易出的问题就是通信混乱。Agent直接互发消息demo里很好看，但生产环境你会遇到消息丢失、重复投递、消费顺序乱等一堆问题。我们在混合架构里没有让Agent之间直接通信，所有消息都走编排层的消息总线。总线用的队列是现成的消息中间件，每条消息带上taskId、sourceAgentId、targetAgentId、messageType、payloadVersion和时间戳。消费者按taskId做隔离消费，同一任务的消息顺序由消息队列的顺序投递保证。这样设计以后，任务从A变到B的过程中即使中间某个环节崩溃，重启后也能按队列积压消息恢复状态，而不是一片空白。有一个细节很容易被忽略：Agent执行结果和Agent发送的消息要区分开。执行结果是任务状态迁移的依据，应该走同步回调；Agent在过程中产生的过程性消息（比如思考日志、中间提示）走异步消息。把这两类混在一起，状态机逻辑就会变得混乱。4.2 状态机、幂等与重试：稳定性三件套多Agent系统里，任何一个节点都可能失败。大模型可能超时、返回格式异常、内容不符合预期；工具API可能抖动；网络可能闪断。所以状态机必须内置完备的超时和重试机制。我们的重试策略分成策略级和算子级两层。策略级重试针对整个Agent任务，比如当Agent返回内容格式不合法时，直接用同样的任务包重试一次，但会要求Agent参考上一次错误重新生成；算子级重试针对单次工具调用，比如网络超时，采用指数退避策略重试两次。关键是每次重试都携带requestId，下游系统根据requestId做幂等判断，避免重复扣减库存、重复提交数据这类严重事故。另外我强烈建议在状态机上再加一个"最大流转深度"限制。比如一个任务最多允许经过15次Agent状态流转，超过就自动终止并触发人工介入。这个数值不是拍脑袋定的，是我们统计了线上任务的流转分布，发现90%以上的正常任务都在这个范围内。有了这个限制，Agent陷入死循环时系统会自动熔断，而不是无限空转烧token。4.3 可观测性：没有traceID，多Agent排障就是灾难多Agent系统的排障难度比单Agent高一个量级，因为一个任务的失败可能发生在任意一个Agent节点上。我们没有哪个天才方法，靠的就是一个贯穿全链路的traceID。从任务创建开始，traceID就生成，并随着任务包、消息、事件传递给每一个Agent和工具调用。日志全部结构化输出，每一条都带taskId、traceId、agentId、节点名称和时间戳。排障时的第一步永远是按traceId查询全局时间线，看任务在哪个环节耗时最长、在哪个环节报错、报错前后上下文是什么。更进一步，我们把关键节点的输入输出做了快照存储。每个Agent的关键执行步骤的输入载荷和输出结果，都会以JSON格式入库存档。这不是为了存储，而是为了支持"回放调试"——线上某个任务出了问题，你可以把快照抽出来，在测试环境重新跑一遍同样的输入，观察Agent的决策过程。这个能力在我们后续优化提示词、调整路由策略的时候，帮了非常大的忙。5. 常见问题排查与避坑实录5.1 Agent陷入死循环，token烧完还没出结果症状是一个任务在同一个Agent之间来回跳转，状态机深度不断增长，token消耗飙升。排查trace后发现Agent把一个不确定的结果反复重试，每次生成结果都差不多，但每次都觉得自己"还差一点需要再验证"。解法就是上面提到的最大流转深度限制，外加一个"结果相似度去重"逻辑。当Agent连续两次产出结果相似度高于某个阈值时，编排层直接判定当前节点无法收敛，结束该Agent的执行并带上最后一次结果，交由后续分支或人工接管。这个阈值前期可以放宽一点，观察线上数据再逐步收紧，太激进会把正常的多轮迭代误杀。5.2 上下文超限，长任务跑到后半段开始失忆多Agent的优势本来是把上下文切小，但如果某个Agent承担了过重的分析任务，照样会把上下文撑爆。我们的做法有两层：一是编排层在派发task包时对输入载荷做了精简，只传与当前Agent任务最相关的字段，而不是把上游所有原始输出一股脑塞进去；二是给每个Agent配置了"记忆摘要"机制，长对话过程中定期把历史内容做动态摘要，用摘要替换早期原始内容，压缩窗口占用。一个血泪教训：不要相信模型"我记住了"这种输出，关键信息必须在编排层显式传参，而不是放在上下文里让Agent自己找。出了几次线上事故之后，我们定了一条规矩：所有任务包必须带上明确的目标字段和数据字段，Agent不需要靠回忆来完成任务。5.3 工具调用参数幻觉，把意图界面操纵当查询条件几次失败的共性是Agent把用户问题里不存在的条件当成查询参数传了下去。排查后发现，问题出在工具描述写得太模糊，模型对参数的可选范围产生了误解。后来我们把工具的字段schema全部改成了枚举严格模式，并加了参数合法性前置校验，编排层在调用工具前会先验一遍参数，不合法直接打回并要求Agent重新生成参数。这一条看上去简单，但对工具调用类Agent的成功率影响极大。建议所有工具接口都做一层参数校验的拦截器，宁可多一步校验，也不要让幻觉参数直接打到下游系统。5.4 框架升级导致的隐性行为变化框架版本升级后，有几个生产任务执行路径变了，排查半天发现是框架内部某个消息处理逻辑调整了。这就回到混合架构设计的初衷了：桥接层的价值就在这里。升级前我们会在测试环境跑一遍全量回放用例，对比关键Agent节点的行为差异。由于业务编排逻辑全在自己手里，框架层的变化被隔离在执行范围内，不会影响到业务状态机的正确性。这个设计不是我们保守，而是生产中必须有的隔离心态。6. 最后再分享几个我们定下的原则多智能体系统的架构选型没有标准答案，但我自己在整个落地过程中逐渐形成了几条判断原则，分享出来供参考。第一，尽量用框架处理通用能力，但永远不要让框架替你做业务决策。业务决策必须显式写在编排层里，用代码表达，而不是靠提示词暗示Agent去猜。第二，状态机越早建模越好。不要等Agent跑乱了再回头补状态约束。我们在设计阶段就先画清了所有任务类型的合法状态迁移关系，后面的开发测试都围绕这个模型进行，省了很多返工。第三，人工介入点不是"系统不智能"的遮羞布，而是生产系统的安全阀。尤其是涉及金额、权限、对外发布的节点，宁可牺牲一点自动化率，也要把好最后一道关。第四，多Agent系统的性能优化，前提永远是先量化。每个Agent节点的耗时、成功率、token消耗、平均流转深度，这些指标从第一天就要埋点统计。没有数据，你根本不知道瓶颈在哪个Agent，优化就无从谈起。第五，也是我最深的体会：不要迷信新框架，也不要迷恋全自研的掌控感。真正可靠的架构，是把"足够成熟的东西交给框架，把决定业务成败的东西握在自己手里"。混合架构不是我们的创意发明，它本质上是一种工程务实主义——用最合理的成本，换取最适合自己业务的可控性和效率。这条思路，放在多智能体系统里成立，放在其他很多系统设计里，同样成立。