多 Agent 的组织方式

Grok Build · Multi-Agent Organization 多 Agent 的组织方式多 Agent 系统要同时解决角色定义、spawn、状态查询、取消、完成通知与资源继承。Grok Build 的源码把这些职责落在定义层与协调事件层。一句话速览基于公开证据比较 Agent、Persona、协调者与并行任务的组织方式课程目标从 subagent_coordinator 读出 Grok Build 的实际组织方式，能用任务依赖、上下文需求、文件冲突和结果汇总成本选择组织策略。

TEACHING DIAGRAM 父会话通过事件通道管理一组有身份的子 Agent Coordinator 在这里是 Grok Build 源码中的真实组件名。图形布局属于课程表达。

父会话、subagent coordinator 与三个子 Agent 的关系

parent session task / query / cancel SubagentCoordinator pending · active · completed wait slots · completions explore AgentDefinition + Persona general-purpose AgentDefinition + Persona plan AgentDefinition + Persona

Grok Build 源码侧：定义与协调

定义层：AgentDefinition + Persona AgentDefinition 给出 prompt、工具、权限、模型、MCP 继承和可 spawn 类型等合同。Persona 追加行为指令、I/O 契约及部分运行时默认值。二者使每个子 Agent 有可观察身份与能力边界。 resolve type → definition → role/persona runtime config

协调层：SubagentEvent start_subagent_coordinator 只启动一次 drain task。每个 Spawn 事件再启动本地异步任务，调用 handle_subagent_request 。 events Spawn · Query · Cancel · ListActive · Completions · Outstanding

并行执行 Spawn 事件独立进入 spawn_local ，协调器登记 pending、active 与 completed 状态。并行能力来自异步任务，不受 Persona 数量限制。结果与等待 Query 可立即返回快照，也可注册 block wait slot 并轮询状态。Completions 会 drain 待通知完成项，并按 suppress_ids 过滤。取消与清理 Cancel 支持按 subagent ID 或 parent prompt ID。协调器还会淘汰过期 completed 记录，并记录显式 kill。

crates/codegen/xai-grok-shell/src/agent/mvp_agent/subagent_coordinator.rs crates/codegen/xai-grok-agent/src/config.rs start_subagent_coordinator handle_subagent_request

Claude 对照：只使用公开行为

可对照的是产品表面能力 Claude Code 公开支持自定义 subagents：每个 subagent 可拥有独立上下文、system prompt、工具权限与模型，主会话可自动委派或由用户显式调用。公开的 Agent Teams 功能描述包含共享任务、成员间消息与独立上下文。本课不把「Coordinator」或「Swarm」当作 Claude Code 源码内部类型，也不推断其调度器实现。

单主会话委派适合一个 owner 统一拆解、串联依赖并汇总。Grok 的 task + coordinator 事件与 Claude 公开的 subagent 委派都能支持这类工作流。多成员协作适合成员需要彼此通信、认领共享任务的工作。评估时应以公开 Agent Teams 行为和当前版本限制为准。角色复用适合长期重复的 reviewer、explorer、planner。Grok 用 AgentDefinition 与 Persona；Claude 公开配置用 subagent 定义文件。

真实源码快照

crates/codegen/xai-grok-shell/src/agent/mvp_agent/subagent_coordinator.rs REAL SOURCE · abridged

while let Some(event) = rx.recv().await {
 match event {
 SubagentEvent::Spawn(boxed) => { /* handle request */ }
 SubagentEvent::Query(query) => { /* snapshot or block */ }
 SubagentEvent::Cancel(request) => { /* cancel target */ }
 SubagentEvent::ListActive(request) => { /* summaries */ }
 SubagentEvent::Completions(request) => { /* drain */ }
 ...
 }
}

快照说明：事件变体与控制结构来自真实源码，分支体为课堂压缩。Claude 侧没有源码快照，所有描述限于公开功能行为。

课堂练习：场景决策为下面三个场景选择「单 Agent」「主会话 + subagents」或「多成员共享任务」，并说明并行收益、依赖关系、上下文复制成本、文件冲突与汇总责任。检索 8 个互不依赖的模块，最后汇总风险清单。同一支付模块内连续修改 schema、service 与测试，步骤强依赖。三个独立服务并行迁移，成员需要互相同��接口变更。

Takeaway：多 Agent 组织先解决任务图，再选择产品机制。Grok 源码展示了事件协调器和可配置 Agent 身份；跨产品比较应停留在公开行为层，避免把营销术语写成内部架构事实。