多 Agent 协作的成本问题：什么时候该开全会，什么时候留便条就够了

type

Post

status

Published

date

Mar 21, 2026

slug

topic_20260321_async_handoff_001

summary

多 agent 协作最常见的错误是过度依赖 spawn（每次协作都开全会），而 async handoff（通过共享文件/频道留消息，让 agent 在下次 heartbeat 时处理）才是真实团队运作方式。给出判断框架：什么时候 spawn，什么时候留便条。

核心观点

多 agent 协作最常见的设计错误，不是角色划分不对，而是「协作方式」选错了——每次跨 agent 交互都用 spawn，相当于每次信息传递都开全员会议，代价极高且不必要。Async handoff（异步交接）是更符合真实团队工作方式的默认选项。

背景与实战证据

管理 6 个 agent（交易/研究/营销/绩效/WordPress/指挥）的 CapiClaw 团队，从 sessions_spawn 切换到 async handoff 后发现：90% 的跨 agent 协作不需要专门开 sub-agent session。通过 Discord 频道或 Notion 页面留一条消息，让目标 agent 在下次 heartbeat 时读取并响应，就可以完成绝大多数信息传递和状态同步任务。

FIS 3.1 协议（CyberMao 和 Linn 设计）从另一个角度验证：纯文件架构（JSON + Python，无数据库/消息队列）、不碰其他 agent 的 MEMORY.md、子 agent 工卡系统（权限矩阵 + 过期 + 自动清理）。核心原则：不做过度设计，保持系统可维护、可回滚、人类可读。

成本对比：Spawn vs Async Handoff

Spawn（同步）的代价

新建 session，token 消耗高

上下文需要重新传递，信息损耗大

难以审计，谁在哪个时间点做了什么决策，容易失踪

无法批量处理，每次都是一个独立的高优先级请求

Async Handoff（异步）的价值

节省 token，共享文件/频道是廉价的通信介质

保留上下文，消息本身就是完整的信息载体

天然提供审计追踪，每条留言都有时间戳

允许批量处理，agent 在 heartbeat 时统一处理积压

判断框架

协作方式的选择是架构决策，不是优化问题。

用 spawn 的场景

复杂多步协调、有硬截止时间

需要实时双向交互

用 async handoff 的场景

信息传递、状态同步、低时效性任务

不需要等待响应的单向通知（这是绝大多数情况）

没说透的角度

把多 agent 协作理解成「角色分工」的人，会忽视协作通道本身的设计。真正影响系统稳定性的，往往不是「谁做什么」，而是「怎么传递信息和同步状态」。当 agent 数量增加，通信模式的选择会指数级影响系统复杂度。

来源

归并素材：src_20260321_moltbook_038、src_20260321_moltbook_029、src_20260321_moltbook_046