多智能体系统: 编排器 + 子智能体实战

单个 AI 智能体擅长处理窄任务。当场景变大 - 工单、文档、代码、CRM、客服 - 一个「万能」智能体会开始混淆角色、膨胀上下文，并在每一步变得更贵。多智能体系统用另一种方式解决：由编排器承接目标并协调工作，而子智能体以独立工具与指令执行窄角色。下面讲实践中如何运作、何时值得投入，以及哪些错误会杀死试点。

• 编排器 - 计划、路由、限额控制与结果汇总
• 子智能体 - 窄角色：调研、编码、评审、写作、CRM
• 上下文 - 每个智能体只获得其步骤所需内容
• 控制 - 关键动作采用 human-in-the-loop
• 起步 - 2-4 个角色与一个可衡量场景，而不是「智能体动物园」
• 风险 - 无限循环、工具竞态与责任边界模糊

什么是多智能体系统

多智能体系统是一种架构：多个 AI 智能体在协调者管理下共同完成任务。与一个覆盖所有情况的「臃肿」提示词智能体不同，角色是拆分的：

同一思路在 工作流自动化 中已很熟悉：有调度器与执行者。区别在于，步骤与分支部分由 LLM 选择，而不是仅靠硬编码的 if-then 规则。

为何要拆分编排器与子智能体

一个能访问全部 API 的智能体看起来方便 - 但很快会变成问题：

• 上下文膨胀。 一个对话里混杂日志、邮件草稿、代码片段与 CRM 导出 - 模型失去焦点。
• 成本上升。 「共享」聊天中的每一个多余 token，每一轮都要付费。
• 权限过宽。 既能写代码又能给客户发信的智能体，比窄执行者更危险。
• 更难调试。 一切都在一个循环里时，不清楚坏在哪里：计划、工具，还是措辞。

角色分离带来：

1. 每个子智能体有窄系统提示 - 更少「越权」幻觉。
2. 独立工具集 - 调研者不能误删 CRM 成交。
3. 并行 - 多个子智能体可同时工作（搜索 + 草稿 + 事实核对）。
4. 可观测性 - 日志可见谁被调用、输入是什么、输出是什么。

基准设计：编排器 + 子智能体池

实用的最小骨架：

User / trigger
        │
        ▼
   Orchestrator
   (plan, routes, limits)
        │
   ┌────┼────┬────────┐
   ▼    ▼    ▼        ▼
 Research  Coder  Reviewer  Writer
   │    │    │        │
   └────┴────┴────────┘
        │
        ▼
   Summary + artifacts
   (+ human approval on risk)

编排器做什么

• 接受目标与约束（时间、token 预算、禁令）；
• 选择调用哪些子智能体及顺序；
• 向每个子智能体传递压缩简报，而不是整段原始聊天；
• 强制步骤上限并打断循环；
• 按业务需要的格式汇总结果（报告、diff、成交卡片）。

编排器可以是「薄」的（仅路由），或「厚」的（自行规划与重规划）。对业务而言，通常薄编排器 + 强窄子智能体更优：更易测试，也更易把控成本与行为。

业务与开发场景中的典型子智能体

第一天不必拥有全部角色。试点通常只需要编排器 + 2-3 个子智能体。

何时这种模式真正划算

当以下至少两条成立时，多智能体设计才有意义：

• 任务是复合的（多种能力：搜索 + 综合 + 动作）；
• 需要对系统有不同访问权限；
• 上下文体量大 - 单个智能体「装不下」且质量会掉；
• 需要独立评审者，而不是作者自查；
• 场景可复现，并能描述成基于角色的流水线。

实践示例

1. 客服： 编排器 → Research（知识库/RAG）→ Writer（回复）→ 人工批准发送。
2. 线索与 CRM： 资质评估 → 信息补全 → 写入 CRM → 经理任务；关键字段由人或规则检查。
3. 开发： Cursor / agent runtime 中的编排器 → explore 子智能体 → coder → reviewer；部署仅在批准后。
4. 内容与 GEO： 选题调研 → writer → 事实核对子智能体 → 按清单发布。
5. 运营： 解析入站邮件 → 分类 → 经 n8n/API 执行动作 → 异常升级给人。

若任务只是简单 if-then（「表单提交 → 创建成交」），多智能体是过度设计：更好用 原生自动化或 n8n。

如何在一天内设计角色

一份简短务实清单：

1. 在纸上描述 happy path： 输入 → 3-6 步 → 输出产物。
2. 用动词命名角色： 「查找」「检查」「撰写」「写入 CRM」 - 而不是「聪明智能体 #3」。
3. 对每个角色固定：输入、输出（schema/JSON）、工具、禁令。
4. 决定谁编排： LLM 规划器，还是确定性图（常见是混合：图 + 节点内 LLM）。
5. 在错误成本高处插入 human-in-the-loop。
6. 设定停止条件： 最大步数、最大成本、超时、「不确定则升级」。

子智能体契约胜过「漂亮提示词」

好的契约：

• 输入：{ task, constraints, sources[] }
• 输出：{ status, summary, artifacts[], confidence, needs_human }
• 禁令：「不捏造 URL」「不改 prod」「不直接给客户发信」

这样编排器就能可靠合并答案，并决定下一步调用谁。

行之有效的编排模式

对中小企业，流水线 + 调度器通常足够。「智能体辩论」在演示里很酷，若无硬 token 预算，在生产中会非常贵。

控制、安全与成本

没有护栏的多智能体系统，很快会变成昂贵的混乱机器人。

最低必备：

• 按角色分离 API 密钥与权限（最小权限）。
• 限额： 步数、token、并行度、超时。
• 幂等动作（重试不得创建 5 笔成交）。
• 审计日志： 谁 → 输入是什么 → 调用了哪个工具 → 输出是什么。
• 密钥不在提示词里：vault、env - 而不是「把 token 贴进系统消息」。
• 不可逆动作需人工批准： 付款、删除、群发、生产部署。

在成本上，不要只算「模型单价」，而要算链路价格：编排器 × N 次子智能体调用 × 重试。有时一次带好上下文的强调用，比五次互相传 JSON 的弱调用更便宜。

常见落地错误

• 先建 10 个子智能体「以后用」，却没有一个能跑通的场景。
• 给每个人相同的全工具访问权。
• 把编排器完整日志传给子智能体，而不是短简报。
• 不限制循环 - 编排器与评审者永无止境地争论。
• 把多智能体设计当成流程的替代品：没有清晰 Definition of Done，系统只会装忙。
• 与 vibe coding 混淆：「让智能体自己搞清楚」却没有角色与契约 - 通往技术债之路。

如何启动 2-3 周试点

1. 选一个有可衡量 KPI 的场景（响应时间、错误率、经理分钟数）。
2. 搭建编排器 + 两个子智能体（例如 research + writer，或 coder + reviewer）。
3. 冻结输入/输出契约与人工升级清单。
4. 跑 20-50 个真实案例，并按类型标注失败。
5. 之后再加第三个角色或并行。

工具可以是智能体框架（LangGraph、类 Crew 方案、IDE runtime）、接到 n8n 的确定性边，或定制 Python。角色架构比框架 logo 更重要。

总结

编排器 + 子智能体是一个可用模式：当任务大于单一技能，且你需要不同权限、上下文与质量检查时。力量不在于智能体数量 - 而在于清晰角色、窄工具与硬停止。从小型闭环与可衡量场景起步：这样多智能体系统才会成为加速杠杆，而不是昂贵的「自主性舞台剧」。

常见问题

多智能体系统与一个长提示词智能体有何不同？

长提示词智能体试图在一个上下文与一套权限里「身兼多职」。多智能体设计拆分角色：编排器协调，子智能体窄范围执行。这更易控制、在长链路上 token 更省，也更安全，因为每个执行者的暴露面更小。

是否始终需要 LLM 编排器？

不必。 确定性图（状态机 / 工作流）往往更好，LLM 放在节点内部。当输入非结构化、路由无法预先硬编码时，LLM 编排器才划算。生产中最常见的是混合方案。

起步时子智能体数量多少最优？

通常 2-4。一个编排器加 research 与 writer，已是内容与客服的可用闭环；coder 与 reviewer - 用于开发。更多角色只有在试点稳定达成 KPI 且日志可读之后才有意义。

如何避免在 token 上烧钱？

压缩简报，禁止「复述整段对话」，缓存稳定系统提示，设最大步数上限，仅在能缩短 wall-time 处并行 - 不为炫技。衡量端到端场景成本，而不是一次漂亮的演示回复。

若智能体已经「很聪明」，还需要人工介入吗？

在风险处需要。 模型不会免除对资金、个人数据、法律措辞与生产的责任。Human-in-the-loop 不是架构弱点 - 而是业务允许智能体靠近真实系统的前提条件。