设计你的 AI 团队架构图：从「有几个 AI 员工」到「画清楚谁向谁交付」
哈喽，我是飞飞。
你现在看的这一整套进阶课，没有一篇是我一个人从头敲到尾的。我把它拆成一条链路，丢给一批专职的 agent 同时跑：一个出门搜资料核数字，一个照着我的写作规则起草，一个专盯 AI 腔做润色，还有一个画封面。我坐在中间派活、收活、最后逐篇过手。
但今天我不想再聊「该招哪几个 AI 员工」这种事了，那是入门的活。今天聊一件更上一层的：当你手里真有了一支 AI 团队，你得像个架构师那样，把这张团队的架构图画出来。谁的输出喂给谁、信息在角色之间怎么流、哪一步必须停下来等人。招人是开始，画图才是把一群散兵焊成团队的真功夫。
招齐了人，不等于有了团队
很多人以为搭 AI 团队就是凑角色：找个写作的、找个研究的、找个 SEO 的、再找个程序员，齐了。
我一开始也这么想，结果跑起来才发现满地是坑。两个 agent 抢着改同一个文件，研究员交回来的料写作员压根接不住，润色完的稿子把前面核好的数字又改飘了。角色都在，活就是串不起来。
Anthropic 去年公开过一篇讲他们自己怎么搭多智能体研究系统的工程文章，里面有个例子我印象特别深：他们早期一个系统，一个子 agent 在埋头查 2021 年的汽车芯片荒，另外两个子 agent 却在重复查 2025 年的供应链，三个人干岔了还互不知道。问题不出在 agent 不够聪明，出在没人给它们划清楚边界。后来的修法跟换更强的模型没关系，就是把派活的指令写明白：每个 agent 该干嘛、不该碰哪块、交出来要长什么样。
说白了，团队的难点从来不在「有没有人」，在「这些人之间的接口对没对齐」。架构师干的就是这个，不是招人，是设计人和人之间那根线。
每个 AI 员工，先写死一张「岗位接口卡」
那这根线怎么对齐？我的做法是，给团队里每个角色都写死一张接口卡，四样东西缺一不可。
这四样其实是从 Anthropic 那篇文章里抄来的。它讲派活时点明：每个子 agent 都需要一个明确的目标、一个固定的输出格式、用哪些工具和信源的指引、还有清晰的任务边界。我把它当成自己每个 AI 员工的岗位说明书，一条条落到 skill 文件里。
拿我的研究员举例。它的目标是「就这个选题搜回 3 到 5 个带出处的可靠信源」；输出格式是「整理成一份干净的素材笔记，落到 Obsidian 那个固定文件夹」；工具是「联网搜索加网页抓取，别的不给」；边界是「只准搜不准编，搜不到就老实标空，绝不许自己造数字」。这四条钉死之后，写作员来接活，它清楚知道自己拿到的是什么、长什么样、能信到几分。
接口卡最值钱的地方，是它把「上一个人的输出」和「下一个人的输入」对齐成了同一种东西。研究员吐出来的笔记格式，正好就是写作员张嘴要吃的格式。这一对齐，交接处就不打架了。你要是哪个角色的输出格式没定死，那道接缝迟早出事。
把这张图拆开，其实就五个零件
定完单个角色，再往后退一步看整张图。一支 AI 团队再花哨，骨架就那么几根。
有篇叫 Paiteq 的技术博客把这事说得特别干脆：任何一套多智能体架构，不管你用什么框架，都能归约成五个零件。第一是 agent 本身，每个就是一段 prompt 加一个模型加一份工具清单。第二是消息总线，也就是 agent A 的输出怎么物理地送到 agent B 的输入。第三是共享状态，一块能在交接之间存活下来的公共草稿区。第四是工具登记表，规定哪些外部能力可调、谁有权调。第五是总指挥，决定下一个谁跑、卡着交接规则、判断啥时候收工。
对着这五个零件看我自己这套，一下就清楚了。每个 skill 是一个 agent，我那个越喂越厚的写作规则文件加 Obsidian 素材库是共享状态，Claude Code 读 frontmatter、认 hook 的那套机制是消息总线，每个 skill 申明的工具就是工具登记表，而总指挥那个位子，我没全交给机器，是我自己坐着。
所以实话讲，画架构图别去画一个个孤零零的角色框，那没用。你要画的是这五样东西怎么咬合，尤其是中间那两根线：信息从哪流到哪，状态存在哪不会丢。角色框是死的，线才是活的。
交接口才是团队最容易塌方的地方
为什么我一直死磕交接？因为团队真要出事，八成出在交接处，不在角色本身。
Augment Code 整理过一份多智能体的故障研究，里面有个数字挺扎心：在 AutoGen、CrewAI、LangGraph 这几个主流框架上，协调类的失败占了全部故障的百分之三十七。也就是说，每三次崩，差不多就有一次跟哪个 agent 笨不笨没关系，纯粹是它们之间的交接没对上。这跟我自己的体感完全吻合：单个 agent 干砸的次数，远没有两个 agent 在接缝上互相坑的次数多。
交接最常见的塌方有两种。一种是信息在传递路上丢了，下一个 agent 拿到半截料，越走越不知道自己在干嘛。另一种是上下文快撑满了，agent 急着草草收尾，活没干完就交了。Anthropic 给长任务的建议里专门点了这两个坑。它们的解法挺接地气：让 agent 在干完一段活、要进下一段之前，先把这段总结一下、把关键信息存到外部记忆里，逼近上限时干脆开一个全新的、上下文干净的 agent 接着干，靠一次干净的交接把活续上。Anthropic 自己甚至会拿一个进度文件加上 git 历史，当成 agent 换班时的交接记录。
我设计交接口时就盯着这两件事：上一棒交出去的东西落不落得了地，以及哪一棒太长了得拆。把这两处守住，团队才不会半路散架。
团队怎么长大，先把指挥权攥在中间
架构图画顺了，下一个问题自然来了：要不要让 agent 之间自己互相派活，把我这个总指挥也省掉？
听着很美，但我劝你先别急。微软在它那份 AI agent 设计模式的指南里给过一条特别实在的建议：先用中心化的架构，也就是所有活都从一个总指挥这儿过；只有当你撞上了实打实的规模瓶颈，才考虑让 agent 们去中心化地自己协调。多数人其实一辈子都到不了那个瓶颈。
我自己就是死守中心化。我这条链路骨架是写死的工作流，研究到写作到润色到配图的大顺序我焊得死死的，免得整个跑飞；但每个环节内部，我放手让那个 agent 自己判断怎么干。大方向我攥着，具体动作它说了算。团队要扩，我也是顺着这张图加岗：哪个环节最堵就先补哪个 agent，新人插进来，照样得先领一张接口卡，对齐输入输出才许上工。攒团队是一格一格搭的，不是一口气拉一支大军。
去中心化当然能干，可那套自治协调一旦上来，调试难度直接翻几倍。微软那份指南还顺手提了一句：给每一处交接都加上观测，不然出了事你都不知道是在哪一棒掉的链子。这话我太认了。
这张图上，总有一个框得是人
把架构图画到最后你会发现，图上总有那么一两个节点，连线不能指向任何一个 agent，只能指向你自己。
我这套机器跑掉了大半，但有两道闸我攥着死不撒手：选题往哪个方向走，我亲自拍板；最终稿子发出去之前，我逐篇过手。署的是我的名字，这两关没法外包给任何 agent。Anthropic 也老实交代过代价，这种多智能体系统烧的 token，是单次聊天的大约十五倍，机器替你跑完的是产出，不是判断。
我前阵子还实打实吃过一次亏。我博客整条发布是全自动的，push 上去自动构建部署。结果有个授权令牌悄没声地过期了，构建明明是绿的，只有最后一步推送红了，没人盯就没人知道，镜像站静默挂了整整一天，我隔天主动去查才发现。那次之后我把这条刻进了架构图：越是没人盯的全自动链路，失败越会闷声往上堆。所以图上那个「人」的框，本质就不只是审稿，还得是盯着整条链路别无声崩掉的那双眼睛。
所以你看，画 AI 团队架构图，画到底画的是一句话：哪些活可以交给线和框，哪些判断必须留在你手里。从用 AI 到管 AI，隔着的就是你会不会画这张图，也敢不敢在该是「人」的那个框前面，停下来认真过一遍。这张图我也还在边跑边改，但已经原原本本摊给你了。
最后想问你一句：如果现在让你给自己的 AI 团队画第一版架构图，你觉得最先卡住你的，会是定不清某个角色该交出什么，还是迟迟舍不得把某道闸交出去？