核心 · Key Idea
一句话：Multi-Agent 就是多个具备不同 system prompt 的 Agent 通过「对话」协作。每个 Agent 有自己的角色（PM / 工程师 / 评审 / QA），通过消息传递把一个大任务做完。
是什么#
单 Agent 什么都干，容易变成「样样通、样样松」。Multi-Agent 把工作分给多个专业 Agent：
PM Agent → 拆需求、出验收标准
Coder Agent → 写代码
Reviewer Agent → Code Review，挑刺
Tester Agent → 写并跑测试
它们之间用结构化消息互相喊话，由一个 Orchestrator (协调者) 调度。
打个比方#
打个比方 · Analogy
单 Agent 像全能临时工，事事都做但都做得一般。
Multi-Agent 像正常软件团队：PM、前端、后端、QA 各管一摊，专人专事 + 互相评审 = 质量更稳。
关键概念#
Role角色
每个 Agent 一个 system prompt，定义身份、职责、输出格式。
Orchestrator协调者
决定哪个 Agent 上场、怎么传消息 —— 可以是另一个 Agent，也可以是固定流程。
Conversation消息流
Agent 间的通信日志，本身就是状态。
Memory共享 / 私有记忆
公共白板 (shared) + 每个 Agent 自己的笔记 (private)。
三种常见拓扑#
- 层级：Manager 拆活、Worker 干活、汇总。AutoGen 的 GroupChat、CrewAI 默认。
- 流水线：固定顺序，每个 Agent 只看上游产物。简单稳定。
- 辩论：两个意见相反的 Agent 互相挑刺，第三个做裁判 —— 逼出更高质量答案。
实操要点#
- 不要一上来就上 5 个 Agent：先用单 Agent 跑通，确实搞不定才拆。每多一个 Agent 上下文成本和失败概率都上一截。
- Role 要清楚 + 互不重叠：「Reviewer 只挑代码错误，不写代码；Coder 只写代码，不评审」 —— 角色交叉是混乱的来源。
- 结构化消息：Agent 间不要自由对话，用
{from, to, type, content}的 JSON。便于路由 + 日志 + 限流。 - 加上「停止人」：辩论模式要有 max_rounds，否则两个 Agent 会无限对线。
- 共享白板优先：所有 Agent 写一个 markdown / DB，比 N×N 互发消息便宜得多。
易混点#
Multi-Agent
Agent 们**自主对话**，谁说什么由模型决定。
灵活，但可能跑题。
灵活，但可能跑题。
Workflow + 多个 prompt
人事先连好节点 / 边。
每步 prompt 不同但**流转固定**。
每步 prompt 不同但**流转固定**。