先说结论如果你的团队正准备上一个多智能体系统并且在全部自研编排和直接用通用框架之间反复横跳那我强烈建议你把注意力放到第三种选项上——混合架构。我们在实际落地一个跨部门协同的智能任务系统时最初踩过纯自研和维护上的坑也体验过通用框架的黑盒失控感最后把两者拆开、分而治之才真正把多智能体从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优化就无从谈起。第五也是我最深的体会不要迷信新框架也不要迷恋全自研的掌控感。真正可靠的架构是把足够成熟的东西交给框架把决定业务成败的东西握在自己手里。混合架构不是我们的创意发明它本质上是一种工程务实主义——用最合理的成本换取最适合自己业务的可控性和效率。这条思路放在多智能体系统里成立放在其他很多系统设计里同样成立。
