本文整理自一段与 AI 的对话探讨（2026-10-23）。内容由大模型生成，具体平台能力请以实际使用的版本为准。
本篇讲"每种模式具体怎么转"。
0. 先定一个贯穿全文的案例
只看模式定义，四种模式都能看懂，但看不出差别——因为定义说的都是"谁指挥"。真正的差别，要放到同一个需求上跑一遍才显出来。
所以这篇从头到尾只用同一个需求，四种模式各跑一遍。
0.1 需求
给公司内部的工单系统加一个登录功能：员工用工号 + 密码登录，成功进首页，失败提示原因。
选它是因为它足够小（四个人就能干完）、又足够真实（有前后端、有联调、一定会出岔子）。
0.2 拆成四个包
| 包 | 谁干 | 交付物 |
|---|---|---|
| ① 接口契约 | 架构 Agent | POST /api/login 的请求/响应字段定义 |
| ② 后端实现 | 后端 Agent | 校验工号密码，返回 token |
| ③ 前端实现 | 前端 Agent | 登录页 + 调接口 + 存 token |
| ④ 测试 | 测试 Agent | 三条用例：密码对能进、密码错提示、空输入拦截 |
0.3 关键冲突点：契约谁定、什么时候定
这是全文的枢纽。四个包之间有依赖，而依赖全卡在①接口契约上：
- 前端要等契约才知道往哪传什么字段
- 后端要等契约才知道返回什么结构
- 测试要等前端后端都好了才能联调
于是就出现一个问题：契约什么时候定下来、由谁拍板？
- 让架构 Agent 一次拍板 → 前后端都只能照着做，错了两边一起返工
- 写进任务书再开工 → 逼着先想清楚，但写不清就扯皮
- 先扔到公共区，谁需要谁取 → 前端不等后端，最快，但契约一变两边都要跟
- 让前后端先吵一轮再定 → 质量最高，但最慢
四种模式的差别，几乎全在这一点上体现出来。 下面每一种模式，都按同一套流程展开：怎么跑、伪代码长什么样、差别在哪。
0.4 四种模式在这个需求上的预告
| 契约谁定 | 前端什么时候开工 | 出问题谁发现 | |
|---|---|---|---|
| 主从 | 架构 Agent 一人拍板 | 等后端做完 | 总控验收时 |
| 合同网 | 写进任务书，先定后干 | 招标后立刻并行 | 各包验收 + 联调 |
| 黑板 | 先扔白板，谁要谁取 | 看到契约就走 | 测试写白板，相关方自己回改 |
| 对等协商 | 前后端谈出来 | 谈完才能走 | 评审会上互挑 |
1. 主从 / 分层（Master-Slave）
1.1 一句话理解
一个总控负责拆任务、派活、收结果；下面的 Agent 只管执行，互相之间不商量。
像什么？项目经理带组员。组长说"你写接口、你写测试"，两个人之间不需要沟通——有事都找组长。
1.2 组成要素
| 要素 | 作用 |
|---|---|
| 总控（Master） | 唯一的大脑：拆任务、排顺序、判断好坏、决定下一步 |
| 执行者（Slave） | 只做自己被派的那件事，不关心全局 |
| 任务队列 | 决定谁先谁后，这是主从的骨架 |
| 回传通道 | 执行者把结果交回总控 |
三个组员用单层就够了。真到十几个 Agent 才需要分层——每多一层，沟通成本涨一截，小项目别学大公司的组织架构。
1.3 用同一个案例跑一遍
总控拿到的顺序是：契约 → 后端 → 前端 → 测试。
总控：架构Agent，先定契约
架构Agent ──→ 契约：POST /api/login，入参 {工号, 密码}，返回 {token, 过期时间}
总控：后端Agent，照契约实现
后端Agent ──→ 完成（此刻前端在待机，什么也没干）
总控：前端Agent，照契约实现
前端Agent ──→ 完成
总控：测试Agent，联调
测试Agent ──→ 失败：返回的过期时间是毫秒，前端按秒处理的
总控：这属于契约没写清，退回架构Agent
架构Agent ──→ 契约 v2：过期时间明确写"毫秒"
总控：后端改一版、前端改一版、测试再跑
测试Agent ──→ 通过
注意两个特点：
- 前端明明只需要契约就能开工，却一直干等着。 因为主从的顺序是总控排的，它不会自己判断"我其实可以早点干"
- 出错之后，总控要把受影响的环节挨个再叫一遍。 契约变了，后端、前端、测试全部重跑——这就是串行的代价
1.4 实现要点
顺序 = ["架构", "后端", "前端", "测试"]
i = 0
while i < len(顺序):
角色 = 顺序[i]
结果 = 调Agent(角色, 输入=上一步产物) # ← 关键节点①：同一时刻只有一个在跑
if 角色 == "测试" and 结果.失败:
i = 顺序.index("后端") # ← 关键节点②：回边，从后端重来
continue
if not 验收(结果) and 重试次数 < 3:
重试(角色) # ← 关键节点③：单个环节的重做上限
continue
i += 1
三个 ← 就是主从的全部机关：排队、回退、限次。没有回边它就是一条死流程，测试报错了也没人管。
1.5 关键设计点
① 拆解的粒度，决定成败
拆太粗："你去把这个功能写了"——执行者还是懵的，等于没拆。 拆太细：一个字段一个任务——光调度开销就超过干活本身。
合适粒度：每个任务都能用一两句话说清"给我什么、要你交出什么"。
② 上下文别整本塞
总控很容易犯的错：把前面所有 Agent 的完整输出一股脑交给下一个。到第四个 Agent 时上下文已经爆了，它反而看不清重点。
只传它需要的那部分。 前端 Agent 不需要看 PRD 里"项目背景"，它需要的是接口字段定义。
③ 总控的判断力就是天花板
总控判断错了，全盘皆错。而"契约没写清"这种问题，总控在派活时是看不出来的——只有等到测试失败才知道。
1.6 优点 / 缺点
优点
- 可预测：流程是一张画得出来的图，跑到哪一步一目了然
- 好调试：出问题能精确定位到某个节点
- 责任清晰：每个产出都有明确负责人
- 成本可控：同一时刻基本只有一个 Agent 在跑
- 最好落地：所有平台都支持，拖几个节点连起来就行
缺点
- 总控是瓶颈，也是单点：它判断错了全盘皆错，它挂了整个停摆
- 串行浪费时间：像上面案例里前端干等后端，纯属排队排出来的
- 不能自发迭代：除非显式画回边，否则它不会自己发现"该回去重来"
- 返工代价大：改一个契约，下游全要跟着重跑
1.7 什么时候用 / 别用
用：流程固定、按顺序做就行；要给别人演示、可控性比灵活性重要；第一次搭多 Agent 拿它练手。
别用：下一步该干什么取决于上一步查到了什么；有大量可以并行的活；需要多方反复讨论才能定的接口。
2. 合同网（Contract Net，招标投标制）
2.1 一句话理解
管理者把大活拆成几个小任务，广播招标；各个 Agent 看自己能不能干，回一份投标；管理者评标选中一个，它干完交回来。干砸了就重新招标。
像什么？公司外包。发包、接单、验收。
它管的不是"顺序"，是**"分配"**——谁干什么，凭什么给它干。这一点和主从有本质区别：主从先排好顺序再叫人，合同网先说清活再挑人。
2.2 组成要素
| 要素 | 作用 |
|---|---|
| 管理者（Manager） | 拆任务、发招标、评标、验收 |
| 承包商（Contractor） | 评估自己能不能干、投标、执行、交付 |
| 招标通告 | 写清任务内容、交付物格式、验收标准、约束条件 |
| 投标书 | 承包商的能力说明、预计方案、可能的耗时 |
| 评标标准 | 管理者凭什么选它 |
2.3 用同一个案例跑一遍
合同网和主从第一个不一样的地方立刻就出现了：契约不能"边干边定"，必须在招标前就写进任务书。
管理者：先把契约这个包单独发包，因为它是其他包的前提
↓ 招标 → 架构Agent 中标 → 交出契约 v1
↓ 但管理者要审：过期时间写"毫秒"了吗？没写 → 打回，重招
架构Agent 交出契约 v2（写明了毫秒）
管理者：把剩下三个包同时挂出去招标
T1 后端实现（依据：契约 v2，验收：三条用例通过）
T2 前端实现（依据：契约 v2，验收：能登录能提示）
T3 写测试用例（依据：契约 v2，验收：覆盖空输入）
三个 Agent 同时投标 → 各自中标 → 并行开工 ← 和主从最大的不同
↓ 后端完成、前端完成、用例完成
↓ 联调：测试发现"密码错误时的提示文案"契约里根本没规定
管理者：这属于契约缺项，打回架构Agent 补 → 重招 → 前后端跟着改一版
测试通过，验收
三个特点：
- 契约被前置成一个独立任务，而且有验收标准。 写不清就打回重招，不会带着模糊往下走
- 后端、前端、测试三个包是同时发出去的，能并行
- 返工只重招出问题的包，不像主从那样整条链重跑
2.4 实现要点
包清单 = 拆任务(需求) # 每包都要有：描述 / 交付物 / 验收标准
先做(包清单.契约) # ← 关键节点①：依赖包必须前置，且要验收
for 包 in 包清单.其余:
通告 = {任务: 包.描述, 交付物: 包.格式, 验收: 包.标准} # ← 关键节点②：通告就是接口
投标 = [a.投标(通告) for a in 所有Agent if a.能接(通告)]
中标 = 按能力挑(投标) # ← 关键节点③：评标
并行执行(中标) # ← 关键节点④：同时干
if 联调失败:
重新招标(失败的那个包) # ← 关键节点⑤：只重招，不全盘重来
2.5 关键设计点
① 招标通告写不清，全盘皆输
这是合同网最常见的死法。通告至少要写清四件事：
| 要写清 | 本例里怎么写 |
|---|---|
| 任务是什么 | "实现 POST /api/login，依据契约 v2" |
| 交付物什么格式 | "单个 .py 文件，路由注册到已有蓝图" |
| 怎么算合格 | "三条测试用例全过" |
| 有什么限制 | "不许引入新依赖；过期时间用毫秒" |
少写一条，投标的就是瞎猜，交付的必然返工。合同网对"事先把话说清楚"的要求，比其他模式都高。
② 评标不能只看"谁想要"
四个常见维度：能力匹配、历史成功率、当前负载、成本。简单实现一句话："能干的里面挑最闲的，一样闲就挑干得最好的。"
③ 拆得太细，协调成本会超过干活成本
一个项目拆成 20 个包招标，光招标投标评标就跑了 60 轮对话，比直接干活还慢。
经验值：一个包的工作量，至少要是"一轮招标沟通成本"的三倍以上，拆了才划算。
2.6 优点 / 缺点
优点
- 任务边界清晰：每包都有明确交付物，验收时不扯皮
- 可以并行：三个包同时招标、同时干，总耗时短
- 失败可挽救：干砸了只重招那一包
- 天然可审计：谁接了什么、交了什么、过没过，全有记录
缺点
- 通信开销大：招标 + 投标 + 评标，最少三轮
- 对管理者要求高：拆任务、写通告的水平直接决定一切
- 可能出现流标：任务描述太怪或能力不匹配，没人接，得人工兜
- 前置设计成本高：像本例的契约，必须在开工前就想清楚，想不清就卡住
2.7 什么时候用 / 别用
用：任务能拆成边界清晰的小包；需要精细控制"谁干什么"；有多个能力相近的 Agent 要按负载调度；想并行提效。
别用：任务根本说不清交付物（说不清就没法招标）；任务小而碎，沟通成本超过干活；任务之间强依赖、必须一个个来。
3. 黑板模式（Blackboard）
3.1 一句话理解
一块公共共享区域（黑板），所有 Agent 都能读、都能写。没有固定调度者，每个 Agent 自己看黑板上现在有什么，判断"这会儿轮到我干活了吗"，满足条件就上手，产出结果再写回去。
想象一间教室，墙上挂一块大黑板：
- 黑板上先写着一行字："加一个登录功能"
- 会想接口的同学看到，上去把字段定义写下来
- 会写后端的同学看到字段定义，上去写后端
- 会写前端的同学看到字段定义，也上去写前端——它不等后端
- 会测试的同学看到前后端都有了，上去跑测试
没有人点名谁什么时候上，谁看到自己能接的活，谁就上去写。
一句话记住它的精髓：查到什么，再决定下一步由谁继续查。
3.2 三要素
| 要素 | 是什么 | 关键点 |
|---|---|---|
| 黑板 | 全局共享的存储 | 所有人可读可写；必须分层，不能一锅粥 |
| 知识源 | 一个个独立的 Agent | 各有专长、各有触发条件；彼此不直接通信，只跟黑板打交道 |
| 调度器 | 可选的控制器 | 它不下命令，只负责防抢写、判终止 |
黑板里一般这么放（本例的实际结构）：
第 0 层 需求："加一个登录功能"
第 1 层 契约：POST /api/login 的字段定义
第 2 层 后端实现 / 前端实现（两个独立字段）
第 3 层 测试结果、报错
第 4 层 交付物 + "完成"标记
为什么要分层？ 一是 Agent 判断"该不该我动"时只看自己那层，不用通读全部；二是上下文有限，分层才好做"只给它看相关的部分"。
3.3 用同一个案例跑一遍
黑板模式最值得看的就是白板怎么一步步被填满。假设前端不会等后端：
时刻1 白板：[需求]
架构Agent 条件成立 → 写下契约 v1
时刻2 白板：[需求, 契约v1]
后端Agent 条件成立 → 开始写后端
前端Agent 条件成立 → 开始写前端 ← 同时，互不等待（差别在这）
时刻3 白板：[需求, 契约v1, 后端✓, 前端✓]
测试Agent 条件成立（条件是"后端和前端都有"）→ 联调 → 失败：
过期时间毫秒 vs 秒
时刻4 测试Agent 把结果写回，同时把"契约"标记为「待修订」
← 这一步是黑板的精髓：抹掉有问题的字段，等于向全场广播"这块要重来"
时刻5 架构Agent 的条件（契约待修订）重新成立 → 改出契约 v2
时刻6 后端、前端看到契约变了 → 各自回改 → 写回白板
时刻7 测试再次触发 → 通过 → 白板打上"完成"
四个关键差别：
- 前端没有等后端，看到契约就开工——所以总耗时最短
- 谁也没指挥谁，全靠字段状态变化触发
- 返工是"自动的"：把
契约改成待修订，架构、后端、前端三个 Agent 的条件同时重新成立，自己就回去改了。不需要谁挨个通知 - 测试 Agent 是唯一的把关人，它的产出直接决定别人要不要重来
3.4 实现要点
白板 = {"需求": "...", "契约": None, "后端": None, "前端": None, "测试": None}
def 触发条件(角色, 白板):
return {
"架构": lambda: 白板["契约"] is None or 白板["契约"].待修订,
"后端": lambda: 白板["契约"] and not 白板["后端"],
"前端": lambda: 白板["契约"] and not 白板["前端"], # ← 关键节点①：不等后端
"测试": lambda: 白板["后端"] and 白板["前端"] and not 白板["测试"],
}[角色]()
while not 白板.get("完成"):
for 角色 in ["架构", "后端", "前端", "测试"]:
if 触发条件(角色, 白板): # ← 关键节点②：条件驱动，不是按顺序叫
结果 = 干活(角色, 白板)
白板[角色] = 结果
if 角色 == "测试" and 结果.失败:
白板["契约"].待修订 = True # ← 关键节点③：改状态 = 广播重来
白板["后端"] = 白板["前端"] = None
if 轮次 > 上限: break # ← 关键节点④：必须设上限
三个 ← 就是黑板的全部机关：写窄的触发条件、用状态变化当广播、设上限防死转。
3.5 关键设计点
① 触发条件要写得"窄"
写太宽，所有 Agent 都觉得自己能干，抢成一团；写太窄，谁都不动手，卡在原地。
好的触发条件长这样："白板上有 A，而且还没有 B，我就动。"
注意本例的"架构Agent"：它的条件是「契约为空 或 契约待修订」。它没有固定的执行位置，只在需要时被唤起——这就是黑板比流水线灵活的地方。
② Findings 比结论更重要
最容易踩的坑：只写"结论"，不写"我为什么这么判断"。
反面例子：白板上只写"测试失败"，别人没法判断该改哪。写成"测试失败：返回 1730000000000（14 位，毫秒），前端按 10 位秒处理，导致过期时间变成 5 万年后"——后端立刻知道该改哪。
③ 终止条件必须显式定义
白板上的信息会一直增加，它自己不会停。必须明确写："三条用例全过 + 人工确认，才算完。"
④ 别把黑板当聊天记录
黑板是结构化的工作台，不是消息流。每条信息都要有明确的键（契约、后端、测试）、明确的归属、能覆盖更新。写成流水账，Agent 找信息只能靠蒙。
3.6 优点 / 缺点
优点
- 不用排队：能干的立刻干，总耗时最短
- 加人极方便：想加一个"安全审计 Agent"，新加一个知识源，别人一行都不用改
- 容错：某个 Agent 挂了，别的还能继续推
- 返工自动化：改一个字段，相关方自己回来改，不用谁去通知
- 适合开放式问题：一开始说不清顺序，也能边做边修正
缺点
- 信息爆炸：白板越写越满，上下文装不下，模型开始胡言乱语
- 流程难控：容易出现两个 Agent 反复做同一件已经做过的事
- 调试痛苦：出了问题，你不知道是哪次写入导致的
- 成本不可预估：转几轮全看内容，事先算不出来
- 对提示词要求高：触发条件写不好，要么抢成一团，要么集体待机
3.7 什么时候用 / 别用
用：下一步干什么事先说不准，要看着中间结果才能定；问题涉及多个专业领域，需要反复补充印证；要长期演进（以后会不断加角色）；单个 Agent 挂掉不能影响整体。
别用：流程本来就很清楚（用了纯属自找麻烦）；对时间、成本有硬要求；需要严格审计（顺序不可控，追责困难）。
一句话判据："下一步该干什么"事先说得准吗？说得准，别用黑板；说不准，黑板才显出本事。
4. 对等协商（Peer-to-Peer Negotiation）
4.1 一句话理解
没有中心，Agent 之间直接发消息、来回谈，自己商量出方案，达成一致再动手。
像什么？几个同事拉个群讨论。谁擅长啥自己认领，意见不合就辩几句，最后拍板干活。
它的前提是：没有谁天然比谁更权威。 一旦有个"最终裁决者"，那就退回主从了。
4.2 组成要素
| 要素 | 作用 |
|---|---|
| 平等的参与方 | 至少两个，地位相同，都能提议、都能反对 |
| 消息类型 | 提议（propose）、反提议（counter）、接受（accept）、拒绝（reject） |
| 轮次上限 | 谈几轮必须收口，不然永远在谈 |
| 裁决机制 | 谈不拢怎么办：投票、升级人工 |
| 记录员（常被忽略） | 把最终结论落成文字，不然谈完就散了 |
4.3 用同一个案例跑一遍
对等协商的用法和前面三种都不一样：它不用来干活，用来定那个最容易吵架的东西——接口契约。
发起：后端Agent 提议
{token 放 header, 过期时间用秒} 理由：通用做法，前端好取
前端Agent 反提议
{token 放 cookie, 过期时间用毫秒} 理由：cookie 能自动带上，不用手写请求头
后端质疑
cookie 有跨域和 CSRF 问题，我们这是内网系统，header 更省事
给出反例：上次那个项目用 cookie，跨域调了半天
前端接受（第 2 轮）
"同意用 header。但毫秒还是秒得定清楚，上次就是这里出问题"
我同意用 header 毫秒，因为 JS 的 Date.now() 本来就是毫秒，不用换算
第 3 轮：双方确认，写入接口文档
契约 v1 定稿：token 放 header，过期时间毫秒
（到这里为止，一行代码都还没写）
然后才交给干活的人按契约实现
四个特点：
- 它发生在开工之前。 谈完才有契约，不是边做边改
- 结论质量高：cookie 的跨域坑是被"反例"逼出来的，单靠一个 Agent 未必想得到
- 同一句话里既有同意也有补充："同意用 header，但毫秒秒要定清楚"——这才是有效的协商
- 前置成本高：谈了 3 轮，代码还没动
4.4 实现要点
契约 = 发起提议("token 放 header，时间用秒", 提出者="后端")
for 轮 in range(1, 上限 + 1): # ← 关键节点①：必须有轮次上限
意见 = [a.质询(契约) for a in 其他Agent]
if all(同意 for 意见):
break
契约 = 修订(契约, 意见) # ← 关键节点②：改动必须附理由和反例
else:
契约 = 人工裁决(契约, 意见) # ← 关键节点③：谈不拢兜底
写入接口文档(契约) # ← 关键节点④：结论必须落地成文档
交付给干活的人()
4.5 关键设计点
① 必须有轮次上限
这是能不能用的生死线。没有上限，两个 Agent 会互相"我觉得你该考虑……""但你有没有想过……"客客气气聊二十轮，一个字没落地。
经验值：三轮之内必须出阶段性结论，否则强制收口。
② 要防"假共识"
模型有个坏毛病：特别容易顺着别人说。"你说得对，确实应该这样"——听着达成一致了，其实它上一句还在反对。
防的办法：要求它复述对方的理由再说同意。"我同意用 header 毫秒，因为 Date.now() 本来就是毫秒"比"我同意"可信得多。
③ 别让它们互相客气
提示词里明确写："不要为了和谐而同意。发现错误必须指出，并给出反例。"否则这套机制会退化成互相吹捧。
上面案例里"cookie 跨域"那个反例，就是靠这条逼出来的。
④ 记录必须落到结构化产物
谈完的结论要写成一张表：谁负责什么、按什么方案、什么条件算完成。而不是一段"我们讨论后认为……"的散文。
4.6 优点 / 缺点
优点
- 能碰撞出单 Agent 想不到的东西：跨域这个坑，就是被质疑逼出来的
- 没有单点瓶颈
- 适合"没有标准答案"的问题：几个方案各有优劣时，辩论能暴露各自盲区
- 结论质量高、后期返工少：因为开工前就把雷排了
缺点
- 慢、贵：每轮所有方都要参与，token 成倍涨
- 容易发散：没有强约束就变成聊天
- 假共识风险：看着一致，实际各说各话
- 难复现：同样输入，两轮跑出来结论可能不同
- 不适合用来干活：它产出的是"决定"，不是"交付物"
4.7 什么时候用 / 别用
用：接口/方案要反复权衡；需要"挑错"（评审、审查、找漏洞）；需求本身模糊，得先聊清楚；愿意为质量多付几倍成本。
别用：任务有明确最优解（直接派活更快）；时间紧预算紧；参与方能力明显不对等（那不叫协商，叫陪聊）；需要严格复现。
5. 附：两种少用的模式
联盟（Coalition）
几个 Agent 为了某个目标临时组队，共享能力，事办完就散。像临时项目组。实际用得少——组队和拆伙本身有成本，项目周期短的话，管理开销比收益还大。
群智能涌现（Swarm）
没有任何中央调度，每个 Agent 只遵守几条简单规则，整体却表现出聪明的协作行为——蚁群找食、蜂群选址。
- 好处：极其抗打击，个体挂了不影响整体
- 坏处：结果不可预测、不可复现，你没法保证它一定给你想要的东西
写代码这种强逻辑任务基本不考虑它——你要的是"稳定产出正确结果"，不是"看它自己长出什么"。
6. 四种模式跑同一个需求：摆在一起看
前面四遍都用了同一个登录需求，现在把差别集中摆出来。
6.1 时间线对比
下表里 → 表示先后，∥ 表示同时发生，✗ 表示返工点。
| 模式 | 时间线 | 总耗时 |
|---|---|---|
| 主从 | 契约 → 后端 → 前端（纯空等）→ 测试 ✗ → 契约v2 → 后端 → 前端 → 测试 ✓ | 最长 |
| 合同网 | 契约 ✗（通告没写清）→ 契约v2 → 后端 ∥ 前端 ∥ 用例 → 联调 ✗ → 只重招缺项 | 短 |
| 黑板 | 契约 → 后端 ∥ 前端 → 测试 ✗ → 契约v2 → 后端·前端自动回改 → 测试 ✓ | 最短 |
| 对等协商 | 提议 → 反提议 → 质询 → 定稿 → 后端 ∥ 前端 ∥ 测试 ✓（一次过） | 中（前置长） |
四行字基本就是全篇的浓缩：
- 主从：串得最长，中间还白等了一段——前端明明早就能干
- 合同网：靠并行把总时长压下来，代价是前置得把契约写进任务书
- 黑板：并行 + 自动返工，总时长最短，但对提示词要求最高
- 对等协商：前面多花一段，换来后面一次过——它是在买保险
有一点值得单独注意：只有黑板和合同网"返工"了，但返工的方式完全不同。 合同网是管理者重新发包（有人指挥），黑板是改了个字段、相关方自己回来（没人指挥）。这是两种模式最本质的差别。
6.2 七个维度对比
| 对比项 | 主从 | 合同网 | 黑板 | 对等协商 |
|---|---|---|---|---|
| 契约谁定 | 架构 Agent 一人拍板 | 写进任务书，先定后干 | 先扔白板，谁要谁取 | 前后端谈出来 |
| 前端何时开工 | 等后端做完 | 招标后立刻并行 | 看到契约就走 | 谈完才能走 |
| 谁发现问题 | 总控验收时 | 各包验收 + 联调 | 测试写白板 | 评审时互挑（开工前） |
| 返工代价 | 大，整链重跑 | 中，只重招坏的那包 | 小，条件自动触发 | 最小，雷提前排了 |
| 沟通轮次 | 少 | 中（招投评三轮） | 极少（基本不对话） | 多（来回谈） |
| 总耗时 | 最长 | 短 | 最短 | 中（前置长） |
| 最难的地方 | 总控的判断力 | 招标通告写得清不清 | 触发条件写得窄不窄 | 收敛得住吗 |
6.3 三条结论
- 没有最好的模式，只有配不配的活。 同一个登录需求，四种模式都能干成，只是代价不同。
- 接口复杂、返工贵的活，前置协商更划算。 对等协商多花的那段，省下的是后面两轮返工。
- 模块能切干净、人手够，就上合同网。 它是最容易在真实团队里落地的——因为它和生产里的"分工"最像。
7. 选型：三个问题定下来
flowchart TD
Q1{"下一步干什么<br/>事先说得准吗？"}
Q1 -- "说得准" --> Q2{"任务能拆成<br/>边界清晰的小包吗？"}
Q2 -- "能" --> R1["合同网<br/>派得清、能并行"]
Q2 -- "不能 / 顺序固定" --> R2["主从流水线<br/>最稳、最好调试"]
Q1 -- "说不准" --> Q3{"需要 Agent<br/>互相辩论吗？"}
Q3 -- "需要" --> R3["对等协商<br/>碰撞出结论"]
Q3 -- "不需要" --> R4["黑板模式<br/>谁能干谁上"]
再补三条经验：
- 第一次搭，选主从。 先把流程跑通、把每个 Agent 的提示词磨好，再考虑换架构
- 任务说不清交付物，就别用合同网。 招标通告写不明白，投标的全是瞎猜
- 黑板最灵活，但最费调试时间。 灵活是有代价的，别为灵活而灵活
实际项目经常混着用，这很正常，也不是妥协：
- 用主从搭骨架（需求 → 契约 → 后端 → 前端 → 测试）
- 契约那一步用对等协商（前后端谈定字段）
- 编码环节内部用黑板（写代码 → 报错 → 修 → 再报错，条件触发）
- 多个独立模块用合同网并行分派
就像公司里既有部门层级、又有项目组、还开会讨论——组织形态本来就该看事办事。
8. 本篇要点回顾
- 主从：排好顺序挨个派活。最稳、最好调试，但会白等，返工要整链重跑
- 合同网：管的是分配不是顺序。契约必须前置写进任务书；能并行、只重招坏包；通告写不清就全盘皆输
- 黑板：Agent 之间完全不说话，全靠一块分层的白板。前端不等后端、改字段等于广播重来、边界是触发条件写得好不好
- 对等协商：它不干活，只产出"决定"。适合定接口、做评审；必须设轮次上限、防假共识、逼出反例
- 联盟、群智能：了解即可，做开发基本用不上
- 同一个需求，四种模式都能干成，差在"契约什么时候定、前端要不要等、返工怎么处理"
- 选型三问：下一步说得准吗 → 能拆成清晰小包吗 → 需要互相辩论吗
- 别只选一种。主从搭骨架 + 契约用协商 + 局部黑板，才是真实项目的常态
