编排模式选择指南

编排器 (Orchestrator) 决定如何调度智能体完成任务。Sira AI 提供 8 种编排模式，适用于不同的业务场景。本指南帮助您选择最合适的编排模式。

快速选择

您的需求	推荐模式	适用场景
简单问答、查询	单体 (Single)	技术咨询、产品介绍、文档查询
复杂任务需要分步处理	监督者 (Supervisor)	技术方案、项目规划、多步骤分析
需要多个专家给意见	协作 (Collaboration)	创意头脑风暴、多角度分析、专家会诊
根据问题类型分配客服	条件路由 (Conditional)	客服分流、场景识别、智能分发
固定的审批或处理流程	工作流 (Workflow)	报销审批、数据处理管道
复用已有 Dify/n8n 应用	外部集成 (External)	快速接入现有应用
高级多步骤任务管理	Deep Agents 🆕	项目管理、报告生成、复杂研究任务
结构化知识问答	知识库 (Knowledge Base) 🆕	FAQ问答、政策查询、标准回复

发布与版本管理

编排器(任意类型)都采用草稿 → 发布两段式生命周期,在设计器顶栏操作:

草稿:编辑器里的所有改动先存为草稿(保存草稿 / ⌘S),不影响线上。
试运行:不发布就跑一次,可对草稿或已发布版本运行,用于上线前验证。
发布:把当前草稿发布为新版本,需填一段版本说明。
版本历史 → 回滚到此:顶栏的版本历史列出所有已发布版本,可一键回滚。

渠道 / Webhook / Cron 只跑「已发布」版本

在设计器里改了内容只是存成草稿,不点发布就不会生效——线上渠道、Webhook 触发、定时任务跑的始终是上一个已发布版本。

可选审批门

当组织启用了资源审批后,发布按钮会变成提交审核,编辑器显示审核中并提供撤回审核;审批通过才真正发布。详见资源审批。

单体模式 (Single)

什么时候用

✅ 简单的问答对话
✅ 文档查询
✅ 单一任务（如生成文案、分析图片）
✅ 需要使用工具（智能体会自动调用）

不适合

❌ 复杂的多步骤任务
❌ 需要多个专家协作
❌ 需要根据问题类型动态分配

如何配置

创建 Orchestrator 时选择 "单体 (Single)"
在配置页面选择一个 Agent
保存即可

透明路由到 DeepAgents

当所选 Agent 配置了 Skill 包（skill_ids 非空）时，引擎会自动透明地把这次执行路由到 DeepAgents 执行器，从而获得 Backend（filesystem / local_shell / sandpod 沙箱）和 Skill 脚本能力。您不需要手动改成 DeepAgents 模式。

支持人工审批 (HITL)

Single 编排器同样支持完整的三层 HITL 配置（应用 > 编排器 > 工具）。在编排器编辑页底部的"人工审批 (HITL)" 卡片就是入口——和 DeepAgents 完全一致。

实际案例

案例 1：技术文档助手

场景：员工在企业微信咨询技术问题

配置：

编排类型：Single
关联 Agent："技术文档助手"
- 模型：GPT-4o
- 工具：Context7 文档查询
- 知识库：技术文档库

效果：

员工："Kubernetes 的 Service 是什么？"
AI："Service 是 Kubernetes 中的抽象概念，用于定义一组 Pod 的访问方式..."
（自动调用 Context7 工具查询文档）

案例 2：图片分析服务

场景：用户发送图片，AI 分析内容

配置：

编排类型：Single
关联 Agent："图片分析专家"
- 模型：GPT-4 Vision
- 系统提示：图片分析专家

效果：

用户："分析这个架构图 [图片]"
AI："这是一个微服务架构图，包含：
1. API Gateway 作为统一入口
2. 三个微服务：用户服务、订单服务、支付服务
3. 使用 Redis 做缓存
4. MySQL 做数据持久化..."

监督者模式 (Supervisor)

什么时候用

✅ 复杂任务需要分解
✅ 需要动态决定调用哪个专家
✅ 多步骤处理（先做A，再做B，最后做C）
✅ 需要汇总多个专家的输出

不适合

❌ 简单的单一任务
❌ 固定流程（用 Workflow 更好）
❌ Worker 需要分析图片（当前限制）

如何配置

创建 Orchestrator 时选择 "监督者 (Supervisor)"
配置监督者 Agent：
- 选择一个作为监督者的 Agent
- 监督者需要理解任务并分配给合适的工人
配置工人 Agents：
- 选择多个工人 Agent
- 每个工人负责特定领域

填写监督者系统提示词 (关键！)：

你是项目经理，负责协调以下专家完成用户任务：

可用专家：
- 技术专家：评估技术可行性，提供技术方案
- 成本分析师：分析成本和预算
- 文档专家：撰写技术文档

工作流程：
1. 理解用户需求
2. 决定需要哪些专家参与
3. 按顺序调用专家
4. 汇总所有专家意见
5. 给出综合方案

其他选项：
- 启用汇总：监督者最后汇总所有专家意见
- 最大迭代次数：防止无限循环（建议 5-10 次）

实际案例

案例：技术方案编写

场景：用户请求"设计一个电商系统的技术方案"

配置：

编排类型：Supervisor
监督者："项目经理" Agent
工人 Agents：
- "架构师"（设计系统架构）
- "技术选型专家"（选择技术栈）
- "成本分析师"（评估成本）
- "文档专家"（撰写方案文档）

执行过程：

1. 用户："设计一个电商系统的技术方案"

2. 监督者 (项目经理)："这个任务需要架构设计、技术选型和成本评估"
   → 分配任务给"架构师"

3. 架构师："建议采用微服务架构，前后端分离..."
   → 返回给监督者

4. 监督者："很好，现在需要技术选型"
   → 分配任务给"技术选型专家"

5. 技术选型专家："前端 React，后端 Go + MySQL..."
   → 返回给监督者

6. 监督者："评估一下成本"
   → 分配任务给"成本分析师"

7. 成本分析师："预估服务器成本 XX 元/月..."
   → 返回给监督者

8. 监督者："整理成文档"
   → 分配任务给"文档专家"

9. 文档专家："## 电商系统技术方案\n\n### 架构设计..."
   → 返回给监督者

10. 监督者汇总："根据各专家意见，完整方案如下：..."

注意事项：

工人 Agent 目前无法看到图片（LangGraph 限制）
如果需要多个 Agent 都分析图片，使用 Collaboration 模式

协作模式 (Collaboration)

什么时候用

✅ 需要多个专家的不同观点
✅ 所有专家都需要看到用户的图片
✅ 创意头脑风暴
✅ 多角度分析同一个问题

不适合

❌ 简单任务
❌ 固定的流程顺序
❌ 专家过多（建议 3-5 个）

如何配置

创建 Orchestrator 时选择 "协作 (Collaboration)"
选择多个 Agent（建议 2-5 个）
选择协作策略：
- 顺序 (Sequential)：一个接一个执行
  - Agent 2 可以看到 Agent 1 的分析
  - Agent 3 可以看到 Agent 1 和 2 的分析
  - 适合：需要前面专家的分析才能进行下一步
- 并行 (Parallel)：同时执行
  - 所有 Agent 独立分析，互不影响
  - 最后汇总所有意见
  - 适合：各专家独立工作，不需要参考别人意见
其他选项：
- 共享记忆：所有 Agent 共享对话历史
- 启用汇总：最后统一汇总所有专家意见

实际案例

案例 1：UI 设计评审（顺序协作）

场景：评估一个界面设计稿

配置：

编排类型：Collaboration
协作策略：Sequential（顺序）
Agents：
1. "视觉设计专家"（分析视觉效果）
2. "UX 专家"（分析用户体验）
3. "技术专家"（评估实现难度）

执行过程：

用户："评估这个设计稿 [UI 截图]"

→ 视觉设计专家：
"这个设计采用了卡片式布局，色彩搭配和谐，使用了蓝色作为主色调..."

→ UX 专家（看到图片 + 视觉专家分析）：
"视觉设计专家提到的卡片布局很好。从用户体验角度，我补充几点：
1. 导航栏清晰，用户容易找到功能
2. 建议增加搜索框的视觉权重..."

→ 技术专家（看到图片 + 前两位专家分析）：
"从实现角度，这个设计可以用 Flex 布局实现。UX 专家提到的搜索框优化，
技术上很容易调整..."

→ 最终汇总：
"综合三位专家意见：
- 视觉：色彩和谐，布局清晰
- UX：建议优化搜索框
- 技术：实现难度低
总评：8/10，建议采纳"

案例 2：创意方案（并行协作）

场景：策划中秋节营销活动

配置：

编排类型：Collaboration
协作策略：Parallel（并行）
Agents：
1. "创意策划"
2. "文案专家"
3. "营销专家"

执行过程：

用户："策划一个中秋节营销活动"

同时执行 ↓

创意策划："建议举办'月饼 DIY 线下活动'..."
文案专家："活动主题：'团圆 有你相伴'，文案如下..."
营销专家："推广渠道：微信朋友圈广告 + 抖音短视频..."

汇总：
"中秋节营销活动方案：
• 创意：月饼 DIY 线下活动
• 主题文案：'团圆 有你相伴'
• 推广渠道：微信 + 抖音
详细方案见下..."

条件路由 (Conditional)

什么时候用

✅ 客服场景的智能分流
✅ 根据问题类型自动分配
✅ 场景识别和分类
✅ 快速路由到专业 Agent

不适合

❌ 需要多个 Agent 协作
❌ 复杂的任务分解
❌ 规则很难定义清楚

如何配置

创建 Orchestrator 时选择 "条件路由 (Conditional)"
添加路由规则（可添加多个）：
每条规则包括：
- 名称：规则的名字
- 优先级：数字越大越优先（10 最高，1 最低）
- 条件：匹配规则
- 目标 Agent：匹配后路由到哪个 Agent
设置条件类型：
关键词匹配：
- 操作符：包含 (contains) / 等于 (equals) / 开头 (starts_with) / 结尾 (ends_with)
- 值：关键词列表，如 ["bug", "错误", "崩溃"]
正则表达式：
- 高级匹配，如手机号 \d{11}
上下文条件：
- 检查用户信息，如 VIP 等级
配置默认 Agent（必填）：
- 所有规则都不匹配时使用
可选：启用 LLM 兜底
- 规则无法判断时，使用 AI 智能识别意图

实际案例

案例：客服智能分流

场景：企业官网客服，自动识别用户问题并分配

配置：

编排类型：Conditional

路由规则：

规则 1：技术支持（优先级 10）

条件：关键词包含 ["bug", "错误", "崩溃", "无法使用", "API", "代码"]
目标：技术客服 Agent

规则 2：销售咨询（优先级 9）

条件：关键词包含 ["价格", "购买", "试用", "优惠", "套餐"]
目标：销售客服 Agent

规则 3：账号问题（优先级 8）

条件：关键词包含 ["登录", "密码", "账号", "注册"]
目标：账号客服 Agent

默认：通用客服 Agent

效果：

用户："我的账号无法登录，提示密码错误"
→ 匹配规则 3（包含"账号"、"登录"、"密码"）
→ 路由到"账号客服"

用户："你们的价格是多少？"
→ 匹配规则 2（包含"价格"）
→ 路由到"销售客服"

用户："我想了解你们公司的发展历程"
→ 无规则匹配
→ 路由到"通用客服"

技巧：

优先级高的规则写得更具体
通用规则优先级设低一点
必须设置默认 Agent 兜底

工作流模式 (Workflow)

完整节点配置参考

本节是概览。每个节点的配置字段、模板变量、连线类型、节点鲁棒性与常见坑，见 工作流编辑器（节点详解）。

什么时候用

✅ 规则清晰、节点间数据流明确的业务(审批、批处理、ETL、规则引擎)
✅ 需要把 Agent / HTTP / 判断 / 循环 / 数据查询等异构步骤编排在一起
✅ 需要节点级重试 / 超时 / 失败兜底的鲁棒流程

不适合

❌ 需要开放式动态决策的任务(用 Supervisor / DeepAgents)
❌ 流程极其多变、难以画成固定图

工作流是可视化画布(不是线性步骤列表)

工作流不是"步骤 1 → 2 → 3,每步选一个 Agent"的线性列表,而是一张 React-Flow 可视化画布:你拖入节点、用连线(edge)把它们连起来,数据沿边在节点间流动。支持并发分发(一个节点拉多条出线)、条件分支、循环回边等非线性结构。

11 种可添加节点(外加默认的开始 / 结束):

节点	作用
🤖 智能体(agent)	调一个 Agent 跑一次推理
🎛️ 嵌套编排(orchestrator)	调另一个 Orchestrator(可嵌套 workflow / supervisor 等)
🔀 条件判断(conditional)	keyword / regex / expression 路由到不同分支
🔁 有界循环(loop)	计数器节点,配合 conditional 回边实现循环
🔂 数组遍历(for_each)	对数组逐元素跑模板(纯模板 map,无 LLM)
🙋 人工确认(human_input)	暂停推卡片给用户,等 approve / reject 后续跑(HITL)
🌐 HTTP(http_request)	调外部 REST API
🔧 数据整形(transform)	纯模板渲染,不调 LLM(多分支汇聚 / 数据组合)
📚 知识库查询(kb_query)	直接查 RAG 知识库,不走 LLM 包装层
🗃️ 数据查询(data_query)	直调数据工具(SQL / NoSQL / 图),由 Sira 内置执行器运行,省一次 LLM 往返
🔌 MCP 调用(mcp_call)	直调一个 MCP 工具,参数明确时不绕 Agent

节点级鲁棒性:调外部服务的节点(http_request / agent / mcp_call / kb_query / transform / for_each / data_query)都可单独配置 retry / timeout / on_error(失败兜底跳转),让单点失败不炸整条流程。

📖 完整搭建步骤(进画布、加节点、连线、模板变量、调试运行、循环模板、故障排查)见操作手册《工作流编辑器使用指南》(操作手册 01-agent-system §1.1.3)。

外部集成 (External)

什么时候用

✅ 已经有 Dify 应用想直接用
✅ 已经有 n8n 工作流想接入
✅ 不想重新配置智能体
✅ 快速集成现有系统

不适合

❌ 需要在 Sira AI 内精细控制
❌ 外部系统不稳定

如何配置

详见：

实际案例

案例：接入已有 Dify 知识库应用

场景：已在 Dify 创建了产品知识库应用，想接入企业微信

配置：

编排类型：External
系统类型：Dify
应用类型：CHAT
API 地址：https://api.dify.ai/v1
API Key：app-xxx

效果：

员工在企业微信提问
自动调用 Dify 应用
返回知识库答案
保留对话记忆（24 小时）

如何选择编排模式

决策树

您的任务是什么？

├─ 复用已有 Dify/n8n 应用
│  └─ 选择：外部集成 (External)
│
├─ 简单的单一任务
│  └─ 选择：单体 (Single)
│
├─ 需要多个 Agent
│  │
│  ├─ 固定流程，按步骤执行
│  │  └─ 选择：工作流 (Workflow)
│  │
│  ├─ 根据问题类型分配
│  │  └─ 选择：条件路由 (Conditional)
│  │
│  ├─ 需要动态任务分解和决策
│  │  └─ 选择：监督者 (Supervisor)
│  │
│  └─ 需要多个专家一起讨论
│     └─ 选择：协作 (Collaboration)

Deep Agents 模式 🆕

什么时候用

✅ 复杂的多步骤任务管理
✅ 需要创建和管理待办清单
✅ 需要文件系统操作（创建、编辑文件）
✅ 需要子智能体协作处理子任务
✅ 长对话需要自动总结

不适合

❌ 简单的单次问答
❌ 不需要状态管理的任务
❌ 对成本敏感的场景（Token 消耗较高）

核心能力

Deep Agents 基于 LangChain Deep Agents 框架，让 AI 能像人一样管理多步骤任务：自动维护待办清单、读写文件、把子任务委派给子智能体、按 Markdown 技能包(Skill)剧本执行，并通过 Backend(filesystem / local_shell / sandpod 沙箱)真正落地这些操作。

配置字段

DeepAgents 配置表单(DeepAgentsConfigForm)暴露以下字段：

字段	说明
`ai_model_id`	主智能体 LLM 模型(必填)
`vision_model_id`	视觉模型(可选)
`system_prompt`	主智能体系统提示词
`tool_ids`	主智能体可用的 MCP 工具
`subagent_default_model_id`	子智能体默认模型
`subagents`	子智能体列表(引用已有 Agent 或预定义 name + prompt + skill)
`backend_config`	Backend 类型与参数:`local_shell` / `filesystem` / `sandpod`,以及 `base_path` / `namespace` / `execute_timeout` / 沙箱绑定(`mode` / `sandbox_id`)等

表单没有独立的"中间件开关(Todo / Filesystem / Summarization)"或"composite 存储"选择项——这些能力随框架内置,行为由 backend_config 与子智能体配置驱动。

如何配置

创建 Orchestrator 时选择 "Deep Agents"
选择主 LLM 模型(ai_model_id,推荐 Claude / GPT-4o 级别强模型)
(可选)配主智能体提示词(system_prompt)、工具(tool_ids)、视觉模型(vision_model_id)
(可选)配子智能体列表(subagents)及其默认模型(subagent_default_model_id)
配 Backend(backend_config):选 local_shell / filesystem / sandpod,填对应参数

实际案例

案例：市场研究报告生成

配置：

编排类型：Deep Agents
AI 模型：Claude 3.5 Sonnet
中间件：Todo List + Filesystem + SubAgents
子智能体：
- 数据分析专家
- 行业研究员
- 报告撰写专家

效果：

用户："生成一份智能手机市场研究报告"

AI 创建待办清单：
✅ 1. 收集市场数据
□ 2. 分析竞争对手
□ 3. 识别市场趋势
□ 4. 撰写报告

AI 委托数据分析专家收集数据
AI 委托行业研究员分析竞品
AI 委托报告撰写专家生成报告
AI 将最终报告保存为文件

了解更多：Deep Agents 详细文档

知识库模式 (Knowledge Base) 🆕

什么时候用

✅ FAQ 标准问答
✅ 政策制度查询
✅ 产品手册问答
✅ 需要精准可控的答案
✅ 答案需要分类管理

不适合

❌ 需要理解长篇文档
❌ 需要推理和分析
❌ 问题格式多变且复杂

核心能力

知识库模式直接走 RAG 检索回答，不调度 Agent——平台基于 LightRAG（向量 + 知识图谱）+ 多种文档解析器（auto / markitdown / vlm / mineru，每库可选） 同时支持：

结构化 QA 对：精准问答（FAQ、政策标答、标准回复）
- 分类树形管理、CSV/JSON 批量导入、渠道隔离、优先级控制
非结构化文档 RAG：文档分块 + 向量检索 + 知识图谱
- 支持 PDF / Word / Markdown / 图片（OCR）等多格式
- 混合检索（向量 + 关键词 + 图谱）

详见知识库管理（批次 B 会拆分为 QA 对 + RAG 文档库两个独立页面）。

如何配置

创建知识库并选择 QA 问答库类型
创建分类结构
添加问答对：
- 手动创建
- 批量导入 CSV/JSON
创建 Orchestrator 时选择 "知识库 (Knowledge Base)"
选择要使用的知识库
配置检索参数：
- 检索模式（精准/语义/混合）
- Top K（返回结果数）
- 相似度阈值

实际案例

案例：产品FAQ智能客服

配置：

编排类型：Knowledge Base
知识库：产品FAQ（500个问答对）
检索模式：混合检索
Top K：3

效果：

用户："如何重置密码？"
AI 检索到标准问答对：
"密码重置步骤：
1. 点击登录页面的'忘记密码'
2. 输入注册邮箱
3. 查收验证邮件
4. 设置新密码"

了解更多：知识库 QA 详细文档

对比表

模式	复杂度	Agent数量	适合场景	图片支持	HITL 支持
Single	⭐	1	简单问答、查询	✅ 完全支持	✅
Supervisor	⭐⭐⭐	3+	复杂任务分解	⚠️ 仅监督者	✅
Collaboration	⭐⭐⭐⭐	2-5	多角度分析	✅ 完全支持	✅
Conditional	⭐⭐	2+	客服分流	✅ Agent 支持	✅
Workflow	⭐⭐	2+	固定流程	✅ 各步骤支持	⚠️ 看节点
External	⭐	0	外部集成	✅ 看外部系统	❌ 外部托管
Deep Agents 🆕	⭐⭐⭐⭐⭐	1+	复杂多步骤任务	✅ 完全支持	✅
Knowledge Base 🆕	⭐	0	结构化问答	❌ 不需要	❌ 纯检索

常见问题

Q1: 单体模式和监督者模式有什么区别？

单体：直接调用一个 Agent，简单直接
监督者：由监督者 Agent 动态决定调用哪些工人 Agent

举例：

单体：用户问"K8s 是什么" → 技术专家 Agent 直接回答
监督者：用户说"写技术方案" → 监督者决定先让架构师分析，再让文档专家撰写

Q2: 协作模式的顺序和并行有什么区别？

顺序 (Sequential)：一个接一个执行，后面的能看到前面的分析
并行 (Parallel)：同时执行，各自独立，最后汇总

选择建议：

需要前面专家的分析才能继续 → 顺序
各专家独立工作，不需要参考别人 → 并行

Q3: 条件路由的规则匹配顺序是什么？

按优先级数字从大到小匹配：

优先级 10 的规则先匹配
如果不匹配，再尝试优先级 9
依次类推
都不匹配，使用默认 Agent

建议：

最具体的规则设高优先级
通用规则设低优先级

Q4: 监督者模式的工人 Agent 为什么看不到图片？

这是当前的技术限制（LangGraph handoff 机制）。

解决方案：

如果需要多个 Agent 都分析图片 → 使用协作模式
或者在监督者中完成图片分析，再委派后续任务

Q5: 可以修改已创建的 Orchestrator 的编排类型吗？

不可以。编排类型创建后无法修改。

如需更换：

创建新的 Orchestrator
选择新的编排类型
将 Application 关联到新的 Orchestrator
删除旧的 Orchestrator

Q6: 一个 Orchestrator 可以关联多个 Application 吗？

可以。同一个 Orchestrator 可以同时：

在企业微信 AI Bot 使用
在 Web 聊天使用
通过 API 对外服务

修改 Orchestrator 配置后，所有 Application 自动生效。

Q7: Agent 数量有限制吗？

没有硬性限制，但建议：

Single：1 个
Supervisor：监督者 1 个 + 工人 2-5 个
Collaboration：2-5 个（过多影响性能和成本）
Conditional：按需配置
Workflow：按流程步骤数

下一步

智能体系统 - 了解 Agent/Orchestrator/Application 关系
图片分析功能 - 让 AI 识别和分析图片
快速上手指南 - 5 分钟创建第一个应用
Dify 集成 - 接入 Dify 应用
N8N 集成 - 接入 n8n 工作流

编排模式选择指南 ​

快速选择 ​

发布与版本管理 ​

单体模式 (Single) ​

什么时候用 ​

不适合 ​

如何配置 ​

实际案例 ​

监督者模式 (Supervisor) ​

什么时候用 ​

不适合 ​

如何配置 ​

实际案例 ​

协作模式 (Collaboration) ​

什么时候用 ​

不适合 ​

如何配置 ​

实际案例 ​

条件路由 (Conditional) ​

什么时候用 ​

不适合 ​

如何配置 ​

实际案例 ​

工作流模式 (Workflow) ​

什么时候用 ​

不适合 ​

工作流是可视化画布(不是线性步骤列表) ​

外部集成 (External) ​

什么时候用 ​

不适合 ​

如何配置 ​

实际案例 ​

如何选择编排模式 ​

决策树 ​

Deep Agents 模式 🆕 ​

什么时候用 ​

不适合 ​

核心能力 ​

配置字段 ​

如何配置 ​

实际案例 ​

知识库模式 (Knowledge Base) 🆕 ​

什么时候用 ​

不适合 ​

核心能力 ​

如何配置 ​

实际案例 ​

对比表 ​

常见问题 ​

Q1: 单体模式和监督者模式有什么区别？ ​

Q2: 协作模式的顺序和并行有什么区别？ ​

Q3: 条件路由的规则匹配顺序是什么？ ​

Q4: 监督者模式的工人 Agent 为什么看不到图片？ ​

Q5: 可以修改已创建的 Orchestrator 的编排类型吗？ ​

Q6: 一个 Orchestrator 可以关联多个 Application 吗？ ​

Q7: Agent 数量有限制吗？ ​

下一步 ​

编排模式选择指南

快速选择

发布与版本管理

单体模式 (Single)

什么时候用

不适合

如何配置

实际案例

监督者模式 (Supervisor)

什么时候用

不适合

如何配置

实际案例

协作模式 (Collaboration)

什么时候用

不适合

如何配置

实际案例

条件路由 (Conditional)

什么时候用

不适合

如何配置

实际案例

工作流模式 (Workflow)

什么时候用

不适合

工作流是可视化画布(不是线性步骤列表)

外部集成 (External)

什么时候用

不适合

如何配置

实际案例

如何选择编排模式

决策树

Deep Agents 模式 🆕

什么时候用

不适合

核心能力

配置字段

如何配置

实际案例

知识库模式 (Knowledge Base) 🆕

什么时候用

不适合

核心能力

如何配置

实际案例

对比表

常见问题

Q1: 单体模式和监督者模式有什么区别？

Q2: 协作模式的顺序和并行有什么区别？

Q3: 条件路由的规则匹配顺序是什么？

Q4: 监督者模式的工人 Agent 为什么看不到图片？

Q5: 可以修改已创建的 Orchestrator 的编排类型吗？

Q6: 一个 Orchestrator 可以关联多个 Application 吗？

Q7: Agent 数量有限制吗？

下一步