wonder/autumn-recruitment

Fork 0

Files

T

wonder 27ffa2ed7e vault backup: 2026-08-10 12:25:40

2026-08-10 12:25:40 +08:00

6.9 KiB

Raw Permalink Blame History

tags, create time, update time

多智能体协作模式

概述

单个 Agent 的能力受限于上下文窗口和工具集。多智能体系统通过让多个专业化的 Agent 分工协作，实现复杂任务的可扩展解耦。核心挑战在于通信协议设计、任务分解质量和冲突消解机制。

详解

Supervisor 模式 — 主从分发

Supervisor 作为中央调度器，接收用户请求后将任务拆解为子任务，分配给专业子 Agent，最后整合结果。

sequenceDiagram
    participant User as 用户
    participant S as Supervisor Agent
    participant A as Writer Agent
    participant B as Researcher Agent
    participant C as Editor Agent

    User->>S: 提交复合需求
    S->>S: 任务分解与规划
    S->>B: 子任务1: 调研背景资料
    B-->>S: 返回调研报告
    S->>A: 子任务2: 撰写初稿
    A-->>S: 返回初稿
    S->>C: 子任务3: 审校编辑
    C-->>S: 返回定稿
    S-->>User: 交付最终结果

关键设计决策：

任务粒度：子任务拆得太细导致通信开销过大；太粗则失去并行价值。一般 3-7 个粒度最合适——匹配人类短期记忆容量（Miller 法则）。
状态一致性：所有中间产物存储在共享 State 中，Supervisor 负责读取每个阶段的产出并构造下一轮输入。

// Go 示例：Supervisor 路由到子 Agent
type Supervisor struct {
    agents map[string]*Agent // agentId → Agent实例
    router ModelRouter   // LLM 驱动的路由决策
}

func (s *Supervisor) Dispatch(task string) string {
    intent := s.router.Classify(task) // 调用 LLM 判断意图类型
    resultChan := make(chan Result)

    for _, subtask := range s.Decompose(intent, task) {
        go func(st SubTask) {
            agent := s.agents[st.AgentID]
            resultChan <- agent.Execute(st)
        }(subtask)
    }

    return s.Aggregate(resultChan, len(subtasks))
}

Critic 模式 — 审查反馈循环

Critic Agent 不生产内容，只评估已有内容的质量，给出评分和改进建议。形成 Producer-Critic 的对抗循环。

graph TD
    A["Producer Agent\n生成候选方案"] --> B["Critic Agent\n质量评分"]
    B --> C{"分数 ≥ 阈值?"}
    C -->|"否"| D["Feedback\n具体改进意见"]
    D --> A
    C -->|"是"| E["接受输出"]

**适用场景：**代码审查、文章校对、Prompt 优化验证、安全策略校验。

Note

Critic 的质量取决于它的评估标准是否量化。纯自然语言的评判主观性太强，应该定义结构化评分维度：准确性、完整性、安全性各占权重。

Planner 模式 — 规划先行

Planner Agent 先输出一串有序的步骤序列，Executors 按步骤逐个执行。Plan 可静态制定，也可动态调整。

静态 Planning：

Step 1: 搜索「XX 技术栈的性能基准」
Step 2: 汇总三个数据源的对比表
Step 3: 针对劣势项提出优化建议
Step 4: 生成总结报告

动态 Planning（Replan）： 当某一步失败或结果不符合预期时，Planner 重新规划后续步骤。例如搜索结果为空时，自动调整为「扩大搜索范围 → 使用同义词 → 切换到备选信息源」。

Swarm 模式 — 蜂群协作

Swarm 没有中心调度器。所有 Agent 只看同一个共享环境（比如一张公共白板），各自根据局部线索自主行动，互不发消息。

graph LR
    SA["Agent A\n看线索 → 行动"] --> WB["公共环境 / 共享状态"]
    SB["Agent B\n看线索 → 行动"] --> WB
    SC["Agent C\n看线索 → 行动"] --> WB
    SD["Agent D\n看线索 → 行动"] --> WB
    WB --> Out["最终聚合"]

跟 Supervisor 的根本区别：

维度	Supervisor	Swarm（蜂群）
通信方式	Agent ↔ Supervisor ↔ Agent（中心化）	Agent ↔ 共享环境（去中心化）
协调者	有	无
每个 Agent 知道全局吗	不知道，只知道自己的子任务	也不知道，只看局部线索
结果如何汇总	Supervisor 聚合	各自产出叠加即可

类比理解：

Supervisor = 指挥官发号施令，士兵执行并汇报
Swarm = 一群蜜蜂围着蜂巢转，每只各自找花蜜，最后蜂蜜自然 accumulate

**适用场景：**头脑风暴、概念发散、大量独立验证——即"不需要商量、答案 = 所有人想法的总和"的场景。比如让 10 个 Agent 各出 20 个点子，再挑最好的几条。

Warning

Swarm 的坑：① 多个 Agent 可能重复试同一个方向（浪费算力）；② 缺少全局约束时，产出容易过于发散难整理；③ 某个 Agent 发现走不通也无法通知别人及时止损。

消息传递协议

多 Agent 之间通过结构化消息通信，推荐基于 JSON Schema 定义契约：

{
  "type": "task_assignment",
  "id": "task_001",
  "from": "supervisor",
  "to": "researcher",
  "payload": {
    "instruction": "检索 Golang gc 在 1.21 中的改动",
    "timeout_ms": 30000,
    "format": "structured_summary"
  }
}

消息类型体系：

类型	方向	用途
`task_assignment`	S→Agent	分配子任务
`result_report`	Agent→S	汇报完成结果
`feedback_request`	C→Agent	要求重新生成
`escalation`	Agent→S	上报异常求决策
`cancellation`	S→All	全局取消信号

各模式对比

模式	优点	缺点	最佳适用场景
Supervisor	架构清晰、便于监控	单点瓶颈、上下文窗口压力大	复杂长链路任务，如研究报告生成
Critic	显著提升输出质量	增加延迟和 token 消耗	对准确性要求高的场景
Planner	解耦规划与执行、支持重试	Plan 可能不合理需 Replan	步骤依赖明确的流水任务
Swarm	简洁灵活、天然并行	缺乏全局协调、易产生不一致	探索性、发散性头脑风暴

Tip

面试高频题：为什么不做一个超级大的 Agent？答案：① 上下文窗口有限，塞入太多能力会稀释注意力；② 工具冲突概率随数量增加而上升；③ 调试困难——出问题时无法定位是哪个模块的问题；④ 迭代成本高，改一个能力可能需要重新微调整个模型。

实践场景

项目复盘：Gen2D 项目中的多 Agent 设计

Gen2D 项目中采用了 Supervisor + Planner 混合模式：

入口 Agent 将用户需求分解为前端/后端/测试三条线
每条线内由 Planner 制定步骤序列
Executor Agent 按步骤执行，每次执行后写入共享日志
Reviewer Agent 做最终交叉检查

这种分层设计避免了单层 DAG 节点过多导致的管理复杂度。

6.9 KiB Raw Permalink Blame History Unescape Escape