什么情况下才真的需要拆成 Multi-Agent?
官方对 Multi-Agent 的定位是「一个智能体无法完成、需要小团队配合」的复杂任务,例如综合分析一批数据后形成决策建议,把分析、查资料、算结果、风控把关、写结论分给不同子智能体。反过来说,任务里只要有一个角色能独立完成全流程——单轮知识问答、按固定条件走工单——拆多智能体就只剩成本没有收益。拆分是协同问题的解法,不是架构上的加分项。
判断是否需要拆分的四个条件
- 先把任务写成角色清单,看分析、检索、计算、复核是否由同一个角色就能完成。
- 算一算任务要调几类工具,只查知识库加一个业务接口的任务,单应用就够。
- 记下官方口径:灵活响应、多工具调用、多 Agent 协同这 3 个条件,至少同时满足 2 个再考虑拆。
- 拿去对照官方四模式文档里 Multi-Agent 的场景描述,对得上再进入下一步评估。
边界与提醒这个判断不适用于已经固化、不需要模型临场判断的流程类任务——那类任务连自主规划都不需要,用单工作流更可控;如果误把它当成复杂任务拆成多智能体,代价是每排查一次问题都要多看几层子智能体的调用记录,运维成本先涨上去。
只有单轮问答需求,选标准模式还是 Multi-Agent?
标准模式是官方为「稳定、精确的知识问答」设计的形态,思考模型与生成模型双模型协同,适合企业知识服务、产品咨询这类严肃问答场景;Multi-Agent 把对话主动权交给模型自主规划,换来的是灵活性而不是问答稳定性。只有单轮问答需求时先选标准模式,问答准确率达标后,再按工具调用需求评估要不要换模式——官方支持两者互切。
单轮问答场景的模式取舍
- 用标准模式先建第一个问答应用,配齐角色指令和知识库,再谈准确率。
- 抽 30 条真实业务高频问题做评测,准确率可接受就不动架构。
- 留一条升级路径:当问答需要接查数、算结果这类工具时,再评估换模式。
边界与提醒如果所谓的「问答」实际要跨订单库、知识库多个来源取数并交叉核对,单轮问答的前提就不成立——官方把跨知识源的复杂问题归入智能检索与多工具协同的适用范围,此时继续堆知识库解决不了准确率问题,该评估的是检索架构而不是模式名称。
流程已经固化、步骤固定,为什么不该上 Multi-Agent?
工单流转、售后处理、审批流这类固化流程,官方建议用单工作流模式:把判断条件、接口调用、处理建议编排成一条可复用流程,让应用按同一条流水线反复执行。固化流程要的恰恰是「不自主」——每一步可预测、可审计、可回放;Multi-Agent 的价值在自主规划,给固定流程用自主规划,等于用确定性换灵活性,换来的灵活性用不上,不确定性却要天天排查。
固化流程为什么留在单工作流
- 把流程先画成节点图,每个节点都有明确输入输出时,单工作流就能承载。
- 核对分支逻辑:条件判断写进工作流的条件节点,比交给模型自主规划可控。
- 给审批、打款这类敏感步骤显式编排一条人工复核节点,而不是交给模型决定。
边界与提醒混合场景例外:如果流程里有一小段必须临场判断,比如 20% 的工单要模型读上下文再决定回复口径,纯单工作流会显得僵硬。这类情况可以工作流走主干、把临场判断收窄到个别节点处理,不必整条流程升级成 Multi-Agent。
拆 Multi-Agent 之前,先验证什么才不会越拆越难排查?
Multi-Agent 由系统在后台自动分工协作,分工意味着排错面变大:一条结论出错,可能出在任何一个子智能体的规划或调用上。拆之前应先让单应用版本在真实任务上跑出基线,记录错误类型,确认失败确实源于一个智能体装不下,而不是提示词或知识库质量问题。深云公开的 ADP 交付页把「测试与评测」列为四步交付里的独立一步,基线工作就属于这一步的前置。
拆分前的基线验证怎么跑
- 跑一遍单应用基线:同一批真实任务,记录完成率与每类错误的占比。
- 列出每个子智能体的输入输出和调用关系,排查时才有路径可走。
- 存下每次协同的中间结果,子智能体对话与工具调用记录留档 2 周以上。
边界与提醒基线验证不适用于完全没有历史任务的全新场景——没有基线可比时,先小规模试运行 2 周,用试运行数据代替历史基线再决定;跳过验证直接拆分的常见代价,是说不清效果变化到底来自拆分,还是来自同期调整的知识库和提示词。
模式选错了再切回来,要重配哪些东西?
官方规则明确:标准模式、单工作流模式、Multi-Agent 三者之间支持互相切换,切换后应用名称、头像、开场白保持不变,知识库和工作流的范围与发布状态也不变,但角色指令、连接器与工具、模型配置等不会相互继承;Multi-Agent 模式还要选择「知识库问答」工具才能启用知识库问答。切错的代价是重配一遍指令和工具,不是推倒重来;只有涉及 Claw 模式时才必须新建应用。
模式切换规则与重配清单
| 切换情形 | 配置变化与要做的事 |
|---|
| 标准、单工作流、Multi-Agent 互切 | 知识库和工作流范围保留;角色指令、连接器与工具、模型配置需按新模式重配 |
| Multi-Agent 模式启用知识库问答 | 需选择「知识库问答」工具;知识库设置和发布状态保持不变 |
| 涉及 Claw 模式 | 不支持切换到其他模式,其他模式也不能切到 Claw,只能新建应用重建配置 |
- 先把当前模式的角色指令和工具配置导出存档,切错了能照着清单重配。
- 核对切换后知识库问答是否生效:Multi-Agent 模式下要重新选「知识库问答」工具。
边界与提醒这条规则只适用于三种模式之间的切换,不适用于从 Claw 模式迁出——Claw 与其他三种模式差异较大,官方明确只能新建应用重建配置;把 Claw 应用当成可随时切换的形态来规划,会在需要换模式时多付一次重建成本。
出现什么信号,才值得从单应用升级到 Multi-Agent?
3 个信号同时出现再升级:任务确实需要多角色配合且单应用装不下;效果瓶颈出在环节衔接而不是知识或提示词质量;团队有人能持续维护子智能体的分工。官方的产品建议本身就是渐进式的——先从知识助手、智能客服这类小场景试点,再逐步扩展到更多业务流程。架构升级解决的是协同问题,解决不了没人用的问题。
升级前要确认的三个信号
- 统计一个月内的失败任务,错误集中在环节衔接而不是单点答错,才值得拆。
- 比对官方场景描述:需要小团队配合、综合分析数据后形成决策建议这类任务。
- 指定一名负责人维护子智能体分工,没有归属的多智能体配置漂移更快。
- 测完 3 个信号再动手,2 个以上不满足就先留在单应用打磨。
边界与提醒这些信号不适用于「想用上多智能体」的团队诉求——升级动机应该是架构需要,不是平台功能展示;如果当前应用还没有稳定的业务使用量,先把采用和知识质量做好,Multi-Agent 的复杂度只会放大没人用的状态。
内容说明
本文的模式定义、适用场景与切换规则引自腾讯云 ADP 官方文档(产品概述及四种模式说明页);服务分层与交付步骤引自官网公开服务页面,口径以页面原文为准。
需要评估这类场景的落地路径?
深云做企业 AI 生产化交付,可以先给一版场景判断与实施路径,再决定要不要做。
了解深云的交付方式