多 Agent 的组织方式
基于公开证据比较 Agent、Persona、协调者与并行任务的组织方式
本页解决的问题
先给结论「多 Agent 的组织方式」要解决的关键问题是什么？
基于公开证据比较 Agent、Persona、协调者与并行任务的组织方式
让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。
写下一个问题：试完这个方法后，你能用什么证据回答它？
结论听起来很完整，却没有检查最关键的假设。
从 subagent_coordinator 读出 Grok Build 的实际组织方式，能用任务依赖、上下文需求、文件冲突和结果汇总成本选择组织策略。
父会话通过事件通道管理一组有身份的子 Agent
Coordinator 在这里是 Grok Build 源码中的真实组件名。图形布局属于课程表达。
定义层：AgentDefinition + Persona
AgentDefinition 给出 prompt、工具、权限、模型、MCP 继承和可 spawn 类型等合同。Persona 追加行为指令、I/O 契约及部分运行时默认值。二者使每个子 Agent 有可观察身份与能力边界。
协调层：SubagentEvent
start_subagent_coordinator 只启动一次 drain task。每个 Spawn 事件再启动本地异步任务，调用 handle_subagent_request。
并行执行
Spawn 事件独立进入 spawn_local，协调器登记 pending、active 与 completed 状态。并行能力来自异步任务，不受 Persona 数量限制。
结果与等待
Query 可立即返回快照，也可注册 block wait slot 并轮询状态。Completions 会 drain 待通知完成项，并按 suppress_ids 过滤。
取消与清理
Cancel 支持按 subagent ID 或 parent prompt ID。协调器还会淘汰过期 completed 记录，并记录显式 kill。
可对照的是产品表面能力
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 定义文件。
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」或「多成员共享任务」，并说明并行收益、依赖关系、上下文复制成本、文件冲突与汇总责任。
「父会话通过事件通道管理一组有身份的子 Agent」为什么能找到相关内容
「从 subagent_coordinator 读出 Grok Build 的实际组织方式，能用任务依赖、上下文需求、文件冲突和结果汇总成本选择组织策略」把检索问题从“把资料存起来”推进到“怎样找到真正相关的资料”。这一步决定了 RAG、推荐和以图搜图最后交给模型的输入质量。
相似度不是答案，召回之后还要核对
在「Coordinator 在这里是 Grok Build 源码中的真实组件名。图形布局属于课程表达」对应的流程里，Embedding 负责把对象放到可比较的语义空间，近邻索引负责减少搜索范围，最终的回答仍然依赖召回片段是否覆盖问题、距离指标是否合适，以及内容有没有过期。
先区分找得到和找得准
把「为下面三个场景选择「单 Agent」「主会话 + subagents」或「多成员共享任务」，并说明并行收益、依赖关系、上下文复制成本、文件冲突与汇总责任」落成一次小测试：准备几条有明确答案的查询，记录召回的相关性、遗漏和无关结果，再决定是否需要换切分方式、索引或重排。
从「父会话通过事件通道管理一组有身份的子 Agent」走到「定义层：AgentDefinition + Persona」
「父会话通过事件通道管理一组有身份的子 Agent」先把问题落在「Coordinator 在这里是 Grok Build 源码中的真实组件名。图形布局属于课程表达」上；到了「定义层：AgentDefinition + Persona」，讨论继续推进到「AgentDefinition 给出 prompt、工具、权限、模型、MCP 继承和可 spawn 类型等合同。Persona 追加行为指令、I/O 契约及部分运行时默认值。二者使每个子 Agent 有可观察身份与能力边界」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
检索系统也可以这样看：先确定什么算相关，再观察召回是否覆盖问题，最后检查排序、切分和时效性有没有把真正有用的内容挤出去。
- 「父会话通过事件通道管理一组有身份的子 Agent」：Coordinator 在这里是 Grok Build 源码中的真实组件名。图形布局属于课程表达
- 「定义层：AgentDefinition + Persona」：AgentDefinition 给出 prompt、工具、权限、模型、MCP 继承和可 spawn 类型等合同。Persona 追加行为指令、I/O 契约及部分运行时默认值。二者使每个子 Agent 有可观察身份与能力边界
- 「最后的要点」：从 subagent_coordinator 读出 Grok Build 的实际组织方式，能用任务依赖、上下文需求、文件冲突和结果汇总成本选择组织策略
最后的「最后的要点」把讨论落到「从 subagent_coordinator 读出 Grok Build 的实际组织方式，能用任务依赖、上下文需求、文件冲突和结果汇总成本选择组织策略」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。