什么是 Multi-Agent？Single-Agent 和 Multi-Agent 的设计方案？

#RAG#Agent#面试八股

什么是 Multi-Agent？Single-Agent 和 Multi-Agent 的设计方案？

Multi-Agent（多智能体）指把任务交给多个各有分工的 Agent，通过消息传递或共享状态协作完成。 它常被误当成"更高级的架构"，实际上它是用协调成本换上下文隔离与并行能力，只在特定场景划算。

1. 结论：先证明单 Agent 不行，再上多 Agent

单 Agent 的主要瓶颈不是智力，而是三件事：上下文装不下、工具太多互相干扰、单点串行太慢。 多 Agent 恰好对症：每个 Agent 有独立上下文与工具集、可以并行执行、可按角色做权限隔离。代价是延迟翻倍、token 翻倍、错误定位变难。

2. 机制：常见拓扑

① 主管式（Supervisor）        ② 层级式（Hierarchical）
      ┌──────────┐                   ┌──────────┐
      │Supervisor│                   │  Top     │
      └────┬─────┘                   └──┬────┬──┘
     ┌─────┼─────┐                      │    │
     ▼     ▼     ▼                   ┌──▼─┐ ┌▼───┐
  [检索] [代码] [写作]               │Sub │ │Sub │──▶ Worker
                                      └─┬──┘ └────┘
③ 流水线（Pipeline）            ④ 群聊/黑板（Blackboard）
  A ──▶ B ──▶ C ──▶ 汇总         共享状态 ⇄ 任意 Agent 读写

生产里最常用的是主管式：一个路由 Agent 只做"派活"，专业 Agent 只做"干活"，职责边界清晰、trace 好看。

3. 拓扑对比

拓扑通信方式优点缺点适用
主管式星型，经主管转发控制集中、易观测、易加权限主管成为瓶颈与单点大多数业务场景
层级式树形可扩展到几十个 Agent层数多则延迟高大型平台、部门级编排
流水线链式简单、可预测不能回头、错误向下传播内容生产、ETL 类
群聊/黑板广播 + 共享状态灵活、可辩论易发散、成本不可控研究、方案评审
对等式交接点对点低延迟、无中心易乒乓转交、难追踪客服转人工类流程

4. 单 Agent 与多 Agent 的取舍

判断维度倾向单 Agent倾向多 Agent
上下文规模一个窗口装得下每个角色都需要大量专属资料
工具数量少于 10 个几十个且领域差异大
并行性步骤天然串行子任务彼此独立，可并行
权限要求统一权限需要按角色隔离（如只读 vs 可写）
延迟预算严格可接受多轮往返
调试成本必须能快速定位团队有 trace 与评测基建

经验阈值：工具超过 15 个、或单次任务上下文超过窗口 60%，才考虑拆分。低于这个量级，多 Agent 带来的协调开销通常大于收益。

5. 代码：主管式的最小实现

WORKERS = {
    "researcher": {"prompt": "你只负责检索与核实事实，输出带出处的要点", "tools": ["search", "fetch"]},
    "coder":      {"prompt": "你只负责写可运行代码，输出完整文件", "tools": ["run_python"]},
    "writer":     {"prompt": "你只负责把材料组织成文，不要新增事实", "tools": []},
}

def supervisor(task: str, llm) -> str:
    transcript = []
    for step in range(6):
        route = llm(f"""任务：{task}
已完成：{transcript}
可选角色：{list(WORKERS)}
只输出 JSON：{{"next": "角色名或 DONE", "instruction": "给它的具体指令"}}""")
        plan = json.loads(route)
        if plan["next"] == "DONE":
            break
        w = WORKERS[plan["next"]]
        out = run_worker(w, instruction=plan["instruction"], context=transcript)  # 独立上下文
        transcript.append({"by": plan["next"], "result": out})
    return llm(f"根据以下分工结果完成任务：{transcript}\n任务：{task}")

两个关键设计：Worker 拿到的是指令 + 必要上下文，而不是全量对话（否则等于没隔离）；主管只做路由，不做具体工作（否则退化成单 Agent 加了一层壳）。

6. 常见追问

问：多 Agent 最常见的翻车点是什么？ "传话游戏"：A 把结论转述给 B，B 再转述给 C，每传一次丢一批细节，最后产出与原始需求偏离。解法是让下游直接读上游的结构化产物（文件、JSON），而不是读自然语言转述。

问：成本会涨多少？ 经验值是单 Agent 的 2~5 倍：每个 Agent 都要带系统提示，主管还要额外一轮路由。上线前必须做 token 预算与并发上限，否则一次任务烧掉几块钱很常见。

问：怎么评估每个 Agent 的贡献？ 按 trace 分段统计：每个 Agent 的调用次数、token、产出被下游采纳的比例。采纳率长期接近 0 的角色应当合并或删除。

问：多 Agent 需要共享记忆吗？ 共享"事实与产物"，不共享"思考过程"。共享过程既浪费 token 又会互相污染；把中间产物落到对象存储，用 id 传递，是最稳的做法。

小结

多 Agent 是用协调成本换上下文隔离、并行和权限分离。选型先看工具数量、上下文压力和延迟预算，够不上就别拆；拆了就用主管式拓扑、结构化产物传递、明确预算与 trace，否则很容易得到一个又贵又难调试的"传话系统"。

笔记加载中…