多智能体协作（上）：概念、实现路径与工具选型多智能体协作说到底只回答三个问题：信息放哪儿、谁决定下一步、活怎么拆。这篇讲

本文整理自一段与 AI 的对话探讨（2026-10-23）。内容由大模型生成，平台能力细节（尤其 WorkBuddy、Dify 不同版本之间的差异）请以实际使用的版本为准。

本文讲"要搭哪几块、按什么顺序搭、用什么工具搭"。

0. 先说清这件事到底在讲什么

多智能体协作，说到底就一句话：

一个大活，一个 Agent 干不完也干不好，那就拆给几个各有专长的 Agent 分着干，再定一套"怎么配合"的规矩。

这套规矩就是"协作架构"（也叫协作范式）。听起来玄，其实它只回答三个问题：

信息放哪儿？ 各揣各的兜里，还是摊在公共台面上？
谁决定下一步谁干？ 有人统一指挥，还是自己看情况上？
活怎么拆、怎么交？ 拆成小块分派，还是大家一起凑？

把这三个问题答清楚，任何一种模式你都能自己推出来，不用死记。

一个容易混淆的点，先在这儿分开，后面就不乱了：

协作模式（主从 / 合同网 / 黑板 / 对等）——决定 Agent 之间怎么沟通、谁说了算

Agent 本身——是一个大模型 + 一套工具（读写文件、跑命令、搜索、调接口）

前者是组织架构，后者是员工。别把两件事混成一件事。

1. 六种协作架构一览

先看全貌，细节在下篇。

模式	一句话理解	谁做决策	信息怎么共享
主从 / 分层	项目经理带组员，排好顺序挨个派活	总控 Agent	逐级下发、逐级上报
合同网	发招标 → 各家投标 → 中标的干	管理者 Agent（评标）	一对一委托
黑板	一块公共白板，谁能干谁上	没有固定的人	全部通过白板
对等协商	没老大，Agent 之间互相谈，谈拢就干	大家一起谈	直接对话
联盟	几个 Agent 临时组队，事办完就散	联盟内部	联盟内共享
群智能	每只蚂蚁只按简单规则走，整体却很有序	没人管	局部感知

实际做开发，能用得上的就前四种。 后两种（联盟、群智能）偏学术和多机器人领域，写代码这种强逻辑任务基本不考虑——原因见下篇第 5 章。

四种主流模式，用一句话互相区分：

模式	一句话
主从	老大安排好顺序，挨个派活
合同网	发招标、投标、分配任务，一对一委托
黑板	大家盯着公共白板，有机会就上，谁也管不着谁
对等协商	你一句我一句，谈成就干

这篇后面不再纠结选哪种。 记住一句话就够：模式决定"谁指挥、信息怎么走"，但不管选哪个，要搭的东西是同一套。想深入某一种，翻下篇对应章节——下篇用一个"给系统加登录功能"的需求，把四种模式各跑了一遍，看完就知道差别在哪。

2. 实现方式：不管选哪种模式，都得搭这五块

模式是"规矩"，这部分是"骨架"。规矩可以换，骨架基本不变。

flowchart TD
    A[&#34;用户需求&#34;] --> B[&#34;1. 任务拆解器（Manager，可选）&#34;]
    B --> C[&#34;2. 共享状态中心（内存 / 数据库 / 消息队列）&#34;]
    C --> D[&#34;3. 若干职能 Agent（角色 + 工具）&#34;]
    D --> E[&#34;4. 调度控制器（防争抢 / 防死循环 / 判终止）&#34;]
    E --> F[&#34;5. 结果汇总 + 持久化（写文件 / git 提交）&#34;]
    E -. 未完成 .-> C

模块	干什么	没它会怎么样
1. 任务拆解器	把大需求切成子任务	只能做单步小事，复杂的搞不定
2. 共享状态中心	存中间结果，所有人读写	Agent 之间没法配合，各干各的
3. 职能 Agent	真正干活的，带角色和工具	没得谈
4. 调度控制器	按规则决定下一步谁上，加锁、限次数、判结束	无限循环；两个 Agent 抢着写同一个文件
5. 汇总与持久化	把成果落到文件、提交到 git	活干完了，东西没留下

这五块里，只有第 4 块和"模式"有关。 换模式，改的是调度器怎么写，前四块的其他部分照用——这是理解所有多智能体系统的关键。

2.1 每个 Agent 内部都是同一套

大模型 + 系统提示词（定角色、定规矩） + 工具集（读文件 / 写文件 / 跑测试 / git / 搜索）

不同模式变的是"它们之间怎么沟通"，不变的是"每个个体怎么构成"。所以换模式不用重写 Agent，改的是外面的调度层——这一点想通了，架构就清楚了。这条对下面两种场景都成立。

2.2 两个常见场景：同一套骨架，两种用法

"多智能体协作模式"是一个很泛的概念。适用于任何涉及到多个Agent之间协作的项目。大体上我分为两类场景：开发系统的场景、系统内部业务之间交互的场景。

	场景一：系统开发	场景二：系统运行
核心内容	用 Agent 把系统造出来	系统已经跑起来了，系统内各种业务 Agent 在工作
本质是什么问题	软件工程问题	业务架构设计问题
角色从哪来	软件开发流程中的固定角色	按业务岗位定
模式怎么选	选择适用于软件开发的协作模式	按这一段业务怎么耦合（业务间交互方式）来定
衡量什么	代码质量、交付速度	正确率、响应时间、成本
失败长什么样	有 bug、交付延期	答错话、赔钱、合规事故

场景一：系统开发——六个角色可以直接复用

软件开发流程中的角色可借鉴如下，可长期使用不做变动：

角色	产出	需要的工具
需求 Agent	PRD、需求边界	读写文档
架构 Agent	模块划分、接口设计、目录结构、技术选型	读代码库、写设计文档
编码 Agent	代码	读写文件、跑命令
评审 Agent	规范问题、安全隐患	读代码（只读，不给写）
测试 Agent	测试用例、跑单测、抓报错	执行命令、读日志（不给写）
文档 Agent	注释、README、接口文档	读写文件

为什么这套能直接搬用？ 因为"写代码交付一个系统"这件事的业务形态是固定的。不管你要做的是合同管理系统、客服系统还是投研平台，交付过程都是：想清楚要什么 → 定结构 → 写 → 挑错 → 验 → 记下来。变的是代码内容，不是工序。 所以角色表抄下来就能用，不必为每个项目重新设计一套。

推荐的协作模式：主从流水线 + 强制独立判断位。 需求→架构→编码→评审→测试→文档按序推进，由调度层派活（主从）；但评审和测试必须是独立 Agent、且拿不到写权限。这一套能覆盖绝大多数开发任务，选模式这一步可以直接跳过。

可以裁，但有一条红线：

合并	行不行
需求 + 架构合一	行，小项目很常见
编码 + 文档合一	行
编码 + 评审合一	不行
编码 + 测试合一	不行

判据一句话：产出者不能兼任判断者。 写代码的 Agent 自己审自己，它一定会说没问题——不是偷懒，是它的上下文里没有第二个视角来撞它。它认为对的，就是它刚才写的那一套。

一个实操细节：评审 Agent 只给读权限，不给写权限。 光靠提示词说"你只负责评审"，它是会手滑的；把工具收走才是硬约束。"评审顺手把代码改了、编码 Agent 完全不知道发生了什么"——这是多智能体最典型的事故。

场景二：系统运行——角色和模式都随业务变

这里的 Agent 是产品的一部分：客服系统里接待客户的、投研系统里出结论的、合同系统里审单的。它们怎么分工、怎么配合，取决于业务本身。

角色按业务岗位定，三个例子：

系统类型	运行期角色
客服系统	受理、意图识别、知识查询、复核与升级、归档
投研系统	数据采集、分析、反方质疑、结论汇总
合同审核系统	初审、口径核对、风险识别、复核签发

运行期恰恰是按业务模块划分 Agent 的。 合同系统里有订单审核、成本统计、批量预提三个模块，就配三个 Agent 各管一摊，这是对的。但有几点必须查：

每个业务级任务都有唯一主人
没有哪个任务被两个 Agent 同时接管（不重叠）
所有块拼起来盖满全部工作，没有悬空的活（不留空）
被拆成流程段的业务，指定了总负责人
每个交接点写清了"给什么、什么格式、什么口径"
下游有拒收权，且真的会退
权限、审计、金额精度、单号、事务边界都有明确归属
共用数据只有一家能写，其他家只读
没有任何一个 Agent 的活是"某个任务的 60%"

模式怎么选：看这一段 Agent 之间的耦合形态。

模块间的关系	该用	为什么
强顺序依赖（审核通过才生成预提，预提才计入成本）	主从 / 流水线	顺序是死的，不用商量，只要一个调度者按序推
弱耦合、能各自独立验收	合同网	能提前写清任务书，就地发包并行
共享同一份核心数据、互相触发（主数据一改都得跟着改）	黑板	改状态即广播，不用谁去通知谁
各有立场要谈判（成本口径、金额精度、责任归属）	对等协商	必须在开工前把口径谈死，否则后面全是返工

第四行最容易忽略。成本统计和批量预提对"预提金额含不含税"的理解很可能不一致，月度一对账就差出钱来——这是口径问题，不是代码问题，值得让两个 Agent 在动手前先谈一轮，谈定之后写成文档，后面都照它走。

还有一个容易漏掉的点：模式是分段的，不必全局统一。 需求到架构这段是主从（有唯一权威），编码那段是三个模块并行（形态完全不同），评审测试是裁判（只读）。一个系统里三种形态共存，非常正常。模式作用在"这一段怎么耦合"上，不是整个系统的全局配置。

三个判据（比"看场景适合哪种"好用得多）：

任务能不能提前拆成"可独立验收"的包？能 → 合同网；不能 → 黑板
有没有唯一权威？有 → 主从；多方平权 → 协商
中间状态要不要互相看得见？要 → 黑板或共享状态；不要 → 消息传递就够

三个问题答得出来，模式基本就定了。细节和伪代码都在下篇，这里只需要知道"该往哪儿想"。

两个场景的关联：两批 Agent，一条原则

最关键的一点：上下两层是两批完全不同的 Agent。

开发期的编码 Agent，是"我用它来写代码的工具"；运行期的客服 Agent，是"客户在用的产品"。它们不在同一个进程里，不共享上下文，甚至不同时存在。

关联点：系统运行阶段的多Agent及协作关系，是由系统开发阶段的Agent设计并交付实现的。

3. 实现路径概述

不管最后选主从、合同网还是别的，推进顺序都一样——先定接口，再由简到繁，最后工程化。

3.1 第一件事不是写代码，是定三份契约

多智能体项目失败，八成不是因为模型不够聪明，而是没人说清"交什么、算不算过"。所以动手前先把三件事写在纸上：

契约	要写清什么	举例
输入契约	每个 Agent 接到什么、格式是什么	"接一段自然语言需求，输出 JSON"
状态契约	中间结果都叫什么名、谁的字段	`prd` / `arch` / `code` / `test_result`
验收契约	什么情况算这一步完成、什么情况算整体完成	"测试用例全过 + 人工点确认"

三份契约定完，剩下的都只是把它们翻译成代码。定不下来，就别急着开工——后面每一步都会返工。

这里有个特别反直觉的点：契约是给"人"看的，不是给模型的。 你写给模型的提示词可以很宽松，但契约必须精确到"字段名叫什么、空值怎么处理"。因为穿针引线的是代码，代码不认模糊。

3.2 五步推进，一步都别跳

第 1 步  跑通单个 Agent
        一个 Agent 能：读任务 → 调工具 → 交结果
        模型先用本地 Ollama，不花钱

第 2 步  串两个 Agent，加一条回退路径
        A 干完交给 B，B 说"不合格"就退回 A 重做
        这一步只验证两件事：交接能不能通、回退能不能转

第 3 步  补齐角色，钉死交接契约
        加到 3～5 个角色，每个角色的输入输出严格按 3.1 的契约来

第 4 步  加调度和保护
        最大轮次、超时重试、终止判定、并发写保护

第 5 步  工程化
        持久化、可观测、权限分级、人工卡点

每一步做完，你应该能看到明确的"东西"，看不到就说明这步没做完：

步骤	做完应该能看到
1	给它一句话需求，它真的改了一个文件
2	故意让 B 判不合格，A 真的被重新叫起来
3	五个角色跑完，产物之间有明确引用关系，不打架
4	把模型接口拔了、或者让它一直失败，系统能自己停下并报错
5	中途 kill 掉进程，重启能接着跑；每一步都有日志可查

第 2 步是关键分水岭。只有两个 Agent 的时候你能一眼看懂整个流转；加到五个以上，出问题就不知道该怪谁了。宁可在这步多停两天。

3.3 与模式无关的最小骨架

任何多智能体系统，剥掉模式的外壳，内核都是三个东西：

① 状态（State）——一次任务的全过程数据，所有步骤共用这一份
② Agent     ——统一成一个函数：给我状态和指令，还我结果
③ 调度器     ——决定"下一步谁上"的那段代码

# ① 状态：一份数据走完全程
task = {
    "requirement": "写一个计算器",
    "outputs": {},          # 各步骤的产物都放这里，按角色名归档
    "round": 0,
    "max_rounds": 5,        # 保护：绝不允许无限转
    "done": False,
}

# ② Agent：所有角色长得一样，只是提示词和工具不同
def run_agent(role, state, instruction):
    prompt = f"你是{role}。任务：{instruction}\n已知信息：{state['outputs']}"
    return call_llm(prompt, tools=TOOLS[role])

# ③ 调度器：换模式只改这一个函数
def orchestrate(state):
    while not state["done"] and state["round"] < state["max_rounds"]:
        state["round"] += 1
        role = decide_next(state)              # ← 协作规则就写在这
        if role is None:
            break
        state["outputs"][role] = run_agent(role, state, INSTRUCTIONS[role])
        state["done"] = check_done(state)
    return state

关键在于 decide_next() 这个函数——它就是"协作模式"落地的地方：

`decide_next` 怎么写	得到什么效果
按固定列表一个个返回	顺序流水线
按状态内容判断"谁的条件满足"	条件触发式协作
先算好任务清单再一个个派	任务分派式协作
返回两个人、一起讨论	对话协商式

Agent 那一层完全不用改。 这也是为什么前面说"换模式不用重写 Agent，只改调度层"。

3.4 从原型到工程，要补的四件事

原型能跑通，离能用还差四步：

补什么	为什么
持久化	进程一挂全没了。中间状态要落盘（Redis / SQLite），最好每步提交 git
可观测	每个 Agent 读了什么、写了什么，全要记日志。出问题第一个要看的就是这个
限流与超时	模型调用会超时、会限速。没有重试和超时，一个卡住整个流程停摆
人工卡点	关键节点（比如"要动生产配置了"）必须停下来等确认，不能全自动跑完

4. 工具选择

选工具之前先认清一件事：市面上的方案分成两类，差别不是"好用不好用"，而是"编排逻辑写在哪"。

代码框架：编排逻辑写在你的代码里 → 想怎么调度就怎么写，代价是得写程序
低代码平台：编排逻辑写在画布和配置里 → 拖拽就能跑，但改不动底层规则

这条线一分清，后面的选择就顺了。

4.1 先说 LangGraph 是什么

这是目前做多智能体最常用的代码框架，值得单独讲清楚。

一句话：LangGraph 是 LangChain 团队做的一个开源编排框架，专门用来组织"多个步骤、带判断、要来回循环"的 AI 流程。它的想法特别朴素——把流程画成一张图，让程序照着这张图跑。

它解决什么问题

不用框架也能做多 Agent：写个 while 循环，里面 if 判断该调谁，就这样。三五个步骤时很清爽。但一旦出现这些需求，自己维护就散了：

某一步失败了要退回上一步重来（循环）
按中间结果走不同分支（条件）
跑到一半要停下来等人确认，然后接着跑（暂停恢复）
想让每一步的中间状态都能查、能回看（可观测）

这些都要你自己写代码管，很快就会变成一坨没法维护的 if-else。LangGraph 把这些做成框架自带的能力。

三个核心概念

概念	是什么	类比
State（状态）	一份贯穿全程的数据，每个节点都能读、能改	一张在工位之间传递的工单
Node（节点）	一个处理步骤，函数形式：收状态 → 返回要更新的字段	一个工位
Edge（边）	决定节点之间的走向	工位之间的传送带

边分两种，这是理解 LangGraph 的关键：

普通边：固定往下一个走（A 干完去 B），相当于流水线
条件边：先看工单内容，再决定去哪（合格就走 END，不合格退回上一步），相当于路口有个调度员

flowchart LR
    A[&#34;START&#34;] --> B[&#34;Node：拆任务&#34;]
    B --> C[&#34;Node：干活&#34;]
    C --> D{&#34;条件边：验收？&#34;}
    D -- &#34;不合格，退回重做&#34; --> C
    D -- &#34;合格&#34; --> E[&#34;END&#34;]

一个能看懂的最小例子

下面这段是"干活 → 验收 → 不合格就退回"的最小结构，实际接口以官方文档为准（LangGraph 迭代很快）：

from typing import TypedDict
from langgraph.graph import StateGraph, START, END

class WorkState(TypedDict):
    requirement: str
    plan: str
    code: str
    test_ok: bool

def plan_node(state: WorkState):
    return {"plan": call_llm(f"给这个需求出方案：{state['requirement']}")}

def code_node(state: WorkState):
    return {"code": call_llm(f"按方案写代码：{state['plan']}")}

def test_node(state: WorkState):
    return {"test_ok": run_tests(state["code"])}

def judge(state: WorkState):                  # 岔路口的调度员
    return "done" if state["test_ok"] else "retry"

g = StateGraph(WorkState)
g.add_node("plan", plan_node)
g.add_node("code", code_node)
g.add_node("test", test_node)
g.add_edge(START, "plan")
g.add_edge("plan", "code")
g.add_edge("code", "test")
g.add_conditional_edges("test", judge, {"done": END, "retry": "code"})

app = g.compile()                              # 编译成可执行的图
result = app.invoke({"requirement": "写一个计算器", "test_ok": False})

读这段代码，注意三件事：

每个节点只关心自己那点事，往里返一个字典，LangGraph 自动帮你合并进 State
流转规则全部写在边的声明里，不在节点内部——这是它和"在函数里写 if-else"的根本区别
add_conditional_edges 那一行，就是"测试不过就回去改"的全部实现

它白送你的能力

能力	有什么用
循环与分支	失败重试、多路分支，不用自己写状态机
并行节点	互不依赖的步骤同时跑，省时间
Checkpointer 持久化	每步状态自动存档，能暂停、断点续跑、回看历史
Human-in-the-loop	指定节点前停下来等人工确认，确认完接着跑
流式输出	边跑边把中间过程吐出来，方便做界面和调试

它和 LangChain 什么关系

一句话分工：LangChain 管"怎么调模型、怎么调工具"，LangGraph 管"什么时候谁跑、跑完去哪"。

LangGraph 是从 LangChain 生态里长出来的，但不强制你用 LangChain——单独用也行。

它不是什么

不是模型，不提供智能
不是平台，没有界面
不会替你写提示词、不会替你想清楚该拆几步
不是"必须用它"：流程就一条直线、也不需要暂停恢复，直接用普通函数调几次反而更简单

什么时候值得上

需要循环回退、需要按中间结果分支、需要人工卡点、需要断点续跑——这四条占一条，就值得用。

4.2 另外两个代码框架

CrewAI —— 面向"角色 + 任务"的高层封装

声明好一个 Agent 的三样东西就能用：role（角色）、goal（目标）、tool（工具）。剩下的顺序编排、上下文传递它替你做了。

适合：快速搭一个分工明确的团队，比如"调研员 + 写手 + 审校"
特点：代码量最少，但它替你定了默认流程，想精细控制会别扭

AutoGen（微软）—— 面向"多轮对话"

主打 Agent 之间直接收发消息，可以来回质疑、补充、辩论。

适合：评审、找 bug、方案权衡这类需要观点碰撞的场景
特点：对话是它的强项，流程编排不是

三者的定位差别：

	LangGraph	CrewAI	AutoGen
层次	底层编排，规则你自己定	高层封装，流程它定	高层封装，靠对话推进
控制粒度	最细	中	中
上手难度	最高	低	中
一句话	自己画流程图	组个队就开工	拉个群讨论

4.3 低代码平台

Dify

可视化画布编排 + 知识库 + 插件/工具 + 多模型接入，能私有化部署，模型随便换。

强项：把流程画出来给别人看、要私有化、要接各种模型、需要知识库
边界：编排逻辑固定在画布结构里；触发完全由你连的线决定，Agent 不会自己判断"该我上了"；复杂的状态和循环要手工绕

WorkBuddy（桌面版）

面向本地开发的成品助手，文件读写、命令行、git 是原生能力，可以自定义几个专家组成"开发小组"。

强项：直接动本地项目代码，不用搭环境，组个队就能开工
边界：调度逻辑是封装的，你通过提示词和专家定义间接控制，改不了底层规则

Coze（扣子）

工作流画布 + 插件，适合快速做原型、对外发布。本地文件和工程操作能力弱，真做项目开发不合适。

4.4 两类工具横向对照

维度	代码框架（LangGraph / CrewAI / AutoGen）	低代码平台（Dify / WorkBuddy / Coze）
编排方式	写代码	拖画布 / 配专家
控制粒度	细，能定每一步的规则	粗，只能按平台给的方式组合
状态管理	你自己定义、自己管	平台提供全局变量之类的容器
循环与回退	原生支持	要手工绕，容易失控
本地工具	自己接，但完全自由	平台决定，Dify 需配 MCP；WorkBuddy 原生支持
可视化	弱（只有代码和日志）	强（流程一眼看清）
部署	你自己部署	可私有化 / 开箱即用
上手成本	高，要会写程序	低
适合谁	要精细控制、要长期演进	要快速跑通、给非技术同事用

4.5 怎么选：三句话

流程是"一条直线"就选低代码。 画几个节点连起来，半小时能跑，没必要写代码。
需要"失败回退、按结果分支、人工卡点"就选代码框架。 低代码也能凑，但越凑越乱。
要长期演进、要精细控制调度就选 LangGraph。 代价是学习成本，收益是以后改起来容易。

还有一个常见的务实选择：先低代码跑通业务流程，验证"这套分工合理"，再决定要不要用代码重写。 一上来就写框架，很容易把错误的分工固化进代码里。

5. 五个最容易翻车的坑

这一章是实战经验，比看十篇架构介绍都有用。

坑	具体表现	解法
状态膨胀	共享的中间结果越积越多，上下文装不下，模型开始胡言乱语	只传该传的增量；定期摘要；淘汰过期信息
循环死锁	改代码 → 测试报错 → 再改 → 再报错，无限来回	设最大轮次；留人工介入开关
Agent 越权	评审 Agent 顺手把代码改了，职责全乱	提示词约束 + 把工具权限收走
写冲突	两个 Agent 同时改同一个文件，后写的覆盖前写的	文件锁；或只输出补丁，由统一入口应用
责任不清	出了问题不知道是谁哪一轮写坏的	每个产物带上"谁产的、第几轮、依据什么"

第二条尤其要注意。"让 AI 自己改到测试通过为止"听起来很美，实际上很容易变成两个 Agent 互相甩锅——编码说改了，测试说还是错。必须有轮次上限。

第三条也是：光在提示词里写"你只负责评审"没用，它该改还是改。把 write_file 工具从它手上拿走，才叫真的约束。

第五条最容易被忽略。等真出问题时你就会发现，"谁写的"这个信息比结果本身还重要。

6. 三个常见误区

误区一：低代码平台只能做单 Agent

不对。Dify 工作流里放多个 Agent 节点、WorkBuddy 的专家团，本身就是多智能体协作。区别只在于：编排规则不由你的代码定义，而是靠提示词约束 + 平台内置调度。

误区二：多个 Agent 并行跑起来，就叫多智能体协作

不是。几个 Agent 各干各的、产出的东西互不相干，那只是"同时跑了几个任务"。

协作的关键是有交接规则：谁先谁后、上一个人的结果怎么传给下一个、不合格怎么办、什么情况算完成。没有这套规则，Agent 再多也只是各说各话。

误区三：多 Agent 一定比单 Agent 强

恰恰相反。任务简单的时候，多 Agent 是纯负担：每个 Agent 都要喂上下文、要写提示词、要处理交接，成本翻好几倍，效果还不一定更好。

只有当一个任务真的需要"不同专业视角"或"多轮迭代才能收敛"时，拆多 Agent 才划算。 否则一个 Agent 加几个工具，往往又快又稳。

7. 本篇要点回顾

多智能体协作 = 拆活 + 定规矩。规矩只回答三问：信息放哪、谁决定、活怎么拆
六种模式，常用的四种：主从（排顺序）、合同网（派任务）、黑板（抢活干）、对等（互相谈）。但不管选哪个，要搭的是同一套骨架
落地永远要搭五块：拆解器、共享状态、职能 Agent、调度器、汇总持久化。其中只有"调度器"跟模式有关
每个 Agent 都是同一套：模型 + 系统提示词 + 工具集。换模式只改调度层，不用重写 Agent
先分清两个场景：造系统（六角色，模式基本固定，可直接复用）vs 系统在跑（角色随业务变，模式随这一段的耦合形态变）。两批 Agent 不共享上下文，只通过交付物衔接
六角色可裁：需求和架构能合一，编码和文档能合一，但编码不能兼评审、不能兼测试——产出者不能兼任判断者
动手前先定三份契约：输入、状态、验收。它们决定项目会不会返工
上手别跳步：单 Agent → 串两个加回退 → 补齐角色 → 加保护 → 才工程化
LangGraph 就是"把流程画成图让程序照着跑"：State 是传递的工单，Node 是工位，条件边是岔路口的调度员
选工具看三件事：流程是不是一条直线（是→低代码）、要不要回退分支（要→代码框架）、要不要长期精细控制（要→LangGraph）
五个坑：状态膨胀、循环死锁、Agent 越权、写冲突、责任不清
简单任务别上多 Agent；没有交接规则的"并行"，不算协作