一万六千字没人读完，他干脆贴出了八张架构图

有位作者写过一篇一万六千字的多 agent 团队搭建教程，从概念、架构一路写到九个步骤落地，通用模板也放在正文里。读的人不算多，基础问题还是有人来问。他换了个方式：把文章里的图单独拎出来贴。

图比文字更容易被看完，这点不用争。

八张图连起来，是一套实际在跑的架构。核心分工一句话能说完：Grok Bot 里的 Bot 常驻在线、有长期记忆，负责编排；Mac 上的 Codex 按任务启动、做完就退出，负责执行；GitHub 的 Issue 当工单，记录任务和进度。

结构上，每个团队都长一个样：Team Lead 拆任务派活，Worker 产出，Reviewer 验收，Publisher 对外发布。所有团队归一个 Chief of Staff 调度，Bot 之间用 Handoff 交接。有人在评论里问到交接方式，作者补了一句范围：团队之间不互相通信，团队内部才互发消息。

Reviewer 这个角色被单独拎出来讨论过。有读者说，自己测系统最怕自己测自己。作者的对应做法是验收时另开一个只读的 Codex Session，不带入执行时的对话，只看产出和验收标准。

三套标准团队分别是文章、产品、视频。文章团队六个 Bot，稿子要过两道检查，Editor 看内容和表达，Researcher 核对事实数据，两个检查者都没参与写稿。产品团队五个 Bot，QA 和 PM 各管一道验收，一个看实现有没有问题，一个看东西是否符合需求。视频团队六个 Bot，剪辑和视觉按交付物分开，能同时推进，封面这类需要反复磨的东西也能单独来回调。

图的价值在这里：你不需要自己从头设计分工。作者的建议是把图发给 Claude Code 或 Codex，让它们理解之后帮你搭。你未必需要亲手敲每一条命令，但至少得知道这套东西在干什么，出了问题才知道去查哪一块。

图之外还有没画进去的部分。作者的取舍是，一张 Ticket 对应一个 Session、一个工作目录；Mac 上并发限两个 Codex；定时任务只留三类，因为每唤醒一次都在花额度。他也把失败面写得很直白：Grok Bot 还在公测，界面和功能变动快，Memory 可能记错或过期，Prompt Injection 至今没有彻底解法，系统约束能降低风险但消除不了。

这些细节读起来枯燥，但它们才是图上那些箭头能跑起来的原因。有读者问过一个更实际的问题，上游晚交半天时，下游该等、换方案，还是直接叫人。这个问题图回答不了，文章里也没有标准答案。

想动手的话，起点比想象中小：一个 Chief of Staff，配一个 Team Lead 加一两个 Worker，让一张 Ticket 从需求走到验收。跑顺了再加第二个团队。