跳到主要内容

Swarm模式

1. 定义与边界​

Swarm 模式通常指多个 Agent 通过动态 handoff、局部决策或去中心化协作完成任务的架构。它强调 Agent 之间可以按当前状态互相转交控制权，而不是所有步骤都由中央 Supervisor 指定。

需要注意：OpenAI 的 Swarm 仓库定位为教育性、实验性框架，而不是生产级 SDK；LangGraph 生态中的 swarm 实现也应按具体版本和文档核对。工程上不能因为名称叫 swarm 就默认可生产使用。

2. 为什么重要​

Swarm 的价值在于开放路径任务：

  • 用户意图会在多轮交互中变化。
  • 不同专业 Agent 需要根据对话状态接管。
  • 没有固定计划，任务路径要运行时发现。
  • Agent 可以局部判断“我不该继续，应该转给谁”。

它的代价也明显：

  • 控制权可能循环。
  • 状态一致性更难保证。
  • 安全审批点更分散。
  • 调试比 Supervisor 更难。

3. 核心机制​

Swarm 的基本单元：

  • Agent：带指令、工具和可用 handoff 目标。
  • Handoff：通过工具调用或控制信号切换 active agent。
  • Shared state：保存用户目标、上下文、artifact 和预算。
  • Transition policy：限制哪些 Agent 可以转给哪些 Agent。
  • Termination policy：判断任务何时结束。

4. 架构/流程​

Swarm 与 Supervisor 的区别：

维度SupervisorSwarm
控制方式中央调度当前 Agent 局部 handoff
可控性较强较弱，需要转移图约束
灵活性中等高
可观测性较容易集中需要全局 trace
适用企业流程、审计、明确任务多轮接待、开放路径、领域切换

推荐的生产形态通常不是完全去中心化，而是“受控 Swarm”：Agent 可以 handoff，但所有 handoff 都经过编排层的策略检查。

5. 工程实现​

转移图配置：

agents:
  triage:
    can_handoff_to: ["billing", "tech_support", "human"]
    tools: ["classify_issue"]
  billing:
    can_handoff_to: ["triage", "human"]
    tools: ["invoice_lookup"]
    requires_approval_for: ["refund"]
  tech_support:
    can_handoff_to: ["developer", "human", "triage"]
    tools: ["kb_search", "diagnostics"]
  developer:
    can_handoff_to: ["tech_support"]
    tools: ["repo_search", "test_runner"]

limits:
  max_handoffs: 6
  max_same_agent_visits: 2
  max_total_cost_usd: 0.40

Handoff schema：

{
  "type": "handoff",
  "from": "tech_support",
  "to": "developer",
  "reason": "需要根据错误堆栈定位代码路径",
  "state_delta": {
    "error_signature": "TypeError in payment callback",
    "reproduction_steps_ref": "artifact:steps_001"
  },
  "allowed_context_refs": ["artifact:steps_001", "artifact:logs_redacted"],
  "forbidden_context_refs": ["artifact:customer_pii"]
}

6. 生产实践​

  • 使用显式转移图，不允许任意 Agent 转任意 Agent。
  • 对每次 handoff 记录理由、上下文引用和权限变化。
  • 设置最大 handoff 次数、最大同 Agent 访问次数和总预算。
  • 对高风险转移，例如从只读 Agent 到写操作 Agent，加入策略审批。
  • 为循环设置检测：相同状态多次在同一 Agent 间往返时触发人工接管。
  • UI 中展示当前 active agent 和下一步动作，避免用户感知混乱。

7. 常见反模式​

反模式风险修正
完全自由 handoff循环、越权、不可审计转移图和策略检查
所有 Agent 共享全部上下文隐私扩散按 handoff 传最小上下文
没有终止条件多轮空转预算、状态变化和完成标准
用 swarm 处理固定流程调试难度无意义增加使用 workflow 或 Supervisor
把实验框架直接上生产能力和稳定性不确定核对官方定位和生产要求

8. 评测方法​

Swarm 评测重点：

  • 正确接管率：任务是否转到合适 Agent。
  • 循环率：是否出现重复 handoff。
  • 上下文最小化：是否只传必要信息。
  • 完成率：开放路径任务是否被解决。
  • 用户中断率：用户是否因多次转交而放弃。
  • 安全转移通过率：高权限转移是否经过审批。

测试样本应包含：意图切换、领域误判、用户补充新约束、Agent 不知道答案、需要人工审批、恶意诱导 handoff。

9. 安全与治理​

  • 每个 handoff 都要经过策略引擎验证，不要让模型自行扩大权限。
  • 低可信 Agent 不能把自然语言“授权”传给高权限 Agent。
  • Handoff 中的上下文引用要按数据分类过滤。
  • 远程 Agent 接管前要验证身份和能力声明。
  • Trace 要能还原“谁把控制权交给谁、为什么、带了什么上下文”。

10. 工程手册补充​

10.1 Swarm 的工程约束​

Swarm 强调去中心化 handoff，但生产环境仍需要协议、预算和终止条件。

风险控制
Agent 互相传球设置 max_handoffs 和必须产出 artifact
上下文泄漏handoff 只传最小必要字段
责任不清每次 handoff 写明原因和期待输出
成本不可控run 级预算和逐步降级

上线清单：

  • 每个 Agent 都声明“何时接手、何时拒绝、交给谁”。
  • handoff 消息必须结构化，不能只说“请你继续处理”。
  • 评测要看最终成功率、错误 handoff 率、循环率和平均 handoff 数。
  • 高风险工具不适合完全去中心化，应交给 Supervisor 或 workflow gate。

11. 权威资料​