多 Agent 协作 vs 单一助手：什么场景该拆成多个专业 Agent？

企业里的「多 Agent」指：多个有独立知识边界、工具权限与验收指标的可执行角色，由路由器或工作流串起来——不是在一个 Prompt 里写「你是销售也是法务也是运维」。单一助手适合意图少、权限同级、写操作极少的场景；一旦知识密级、写权限或模型成本冲突，硬塞进一个助手会同时抬高幻觉与事故面。GeonAI 按场景设计拆分与编排；/agents 仅供能力参考（363+ 预设非公众全量试用）。评估请邮件 [email protected]。选型问题见 /blog/ai-agent-selection-checklist；与通用工具边界见 /blog/generic-ai-tools-vs-custom-agent。

先对齐定义：拆的是「角色包」，不是聊天窗口数量

拆分决策看 边界是否冲突，不看供应商 demo 里同时亮了几个小人。

四条硬信号：满足 ≥2 条再认真谈拆分

只满足 0–1 条：优先把单一助手做扎实（意图表、引用、转人工）。满足 2 条以上：做「最小拆分」——通常是 1 个路由 + 2–3 个专家，而不是一次上 8 个。

三种可落地的编排拓扑

① 路由 + 专家（最常用）

入口分类器（规则或小模型）把意图打到专家 Agent。专家互不共享写工具。适合客服：政策问答 / 物流只读 / 退款草稿。验收看：路由准确率、跨专家串答率。

② 串行流水线

A 抽取字段 → B 检索制度 → C 生成草稿 → 人工确认。适合售前方案、质检报告摘要。每步有结构化输入输出与超时；禁止「上一步胡说下一步接着编」。

③ 并行检索 + 合并（带人工）

同时查知识库与工单系统，合并后再生成。合并层必须处理冲突（两源不一致 → 转人工）。适合「既要政策又要订单状态」的查询。

算例：电商售后要不要拆？

多数团队从 A 做出引用与转人工后，因「退款误操作风险」才进 B。直接上 C 是常见翻车。客服模块见 /blog/custom-customer-service-agent；电商转化见 /blog/ecommerce-agent-conversion。

多 Agent 的真实代价（立项要写进成本）

• 路由错误：分错专家 → 错误承诺或无效转人工；需单独质检
• 状态传递：会话 ID、已检索文档、用户槽位要在专家间显式传递，禁止靠模型「记住」
• 重复知识：同一制度多处拷贝 → 版本漂移；应单一真相源 + 角色视图
• 观测变难：要按专家拆分延迟、缺引用率、漏转率（见 /blog/poc-to-production-agent-checklist）
• 工具面扩大：每多一个可写专家，攻击面与审计字段都增加

反模式（看到就停）

1. 「多智能体辩论」无人工节点、无审计，对外直接发送
2. 专家之间互相随意调用写工具，没有网关白名单
3. 用 363+ 预设页上的多个角色名当成已上线编排
4. 拆分后仍共用一个无 ACL 的大知识库
5. 为了 PPT 画「Agent 网络」而业务只有 5 个 FAQ 意图

试点拆分清单（可直接贴进 SOW）

1. 列出冲突边界：ACL / 写权限 / 模型档位 / 对外 vs 对内
2. 选定拓扑（默认路由+专家）；画出入口与人工节点
3. 每个专家单独：意图表、拒答、工具白名单、验收指标
4. 定义路由失败与专家超时的降级话术
5. 先灰度一个通道；路由准确率与串答率进周报
6. 达标后再加专家——禁止并行开一堆空壳

与 ERP/CRM 的工具调用见 /blog/agent-function-call-mcp-integration。交付节奏见 /blog/enterprise-ai-agent-delivery-4-steps。

找 GeonAI 时怎么描述

说明：现有单一助手卡在哪条硬信号、希望保留的入口体验、可接受的专家数量上限、是否已有路由规则。邮件 [email protected]、服务方案 或 Live chat。我们优先「最小可验收拆分」，不贩卖多智能体热闹图。