1. 为什么一个人需要一支 AI 团队去年年底我接手了一个内容运营的活儿需求很杂每周要产出三篇深度稿、维护两个社群的日常答疑、还要定期整理行业动态做简报。按传统做法要么招人要么自己硬扛。招人成本高自己扛则意味着每天至少多耗四五个小时在重复劳动上。后来我换了个思路——不招人而是搭一支“一个人的 AI 团队”用五个各司其职的智能体把整条链路串起来。这套东西跑通之后我最大的感受是多智能体协作真正的价值不在于“多”而在于“分工明确、边界清晰、交接顺畅”。很多人一上来就堆七八个 agent结果互相打架、输出重复、上下文爆炸最后还不如一个单体 prompt 好用。我踩过这个坑所以这篇文章想把我最终稳定下来的五智能体架构完整拆给你看——每个智能体负责什么、为什么这么切分、它们之间怎么传递信息、以及我在调试过程中遇到的那些“文档里不会写”的问题。如果你正在做智能体开发、想搭建自己的自动化工作流或者只是好奇“多 AI 协作”到底怎么落地这篇内容应该能给你一套可以直接抄的骨架。我不讲虚的框架概念只讲我实际跑起来的那套东西。2. 五个智能体的角色切分逻辑2.1 为什么是五个而不是三个或十个先说结论角色数量应该由“任务链路上不可合并的决策节点”决定而不是拍脑袋定的。我最初试过三个智能体——一个负责搜集、一个负责写作、一个负责审核。跑了两周发现两个问题第一搜集和写作之间的信息损耗太大搜集回来的原始素材没有经过结构化整理写作智能体每次都要重新理解一遍浪费大量 token第二审核智能体既要做事实核查又要做风格润色两个目标经常冲突改着改着就把内容改得面目全非。后来我拆成了五个核心思路是把“理解”“整理”“创作”“校验”“调度”这五件事分开。每一件事的评判标准不同混在一起就会互相干扰。五个是我实测下来既能覆盖全链路、又不会因为层级太多导致通信开销爆炸的平衡点。十个不是不行但每多一个智能体你就要多维护一套输入输出契约边际收益递减得很快。2.2 五个角色的职责边界我把它们分别叫做调度者、侦察员、架构师、写手、审稿人。名字不重要重要的是每个角色的输入和输出必须严格定义。角色核心职责输入输出调度者拆解任务、分配顺序、汇总结果用户原始需求结构化任务清单侦察员搜集素材、提取关键信息任务清单中的检索项带来源的素材卡片架构师设计内容结构、规划论证逻辑素材卡片 需求详细大纲写手按大纲填充内容大纲 素材初稿审稿人事实核查、风格统一、逻辑校验初稿 素材修改意见 终稿这张表看起来简单但真正难的是每个角色的输出格式要足够“机器可读”。比如侦察员的输出不能是一段散文而必须是结构化的卡片每条素材包含“核心事实、来源、可信度评级、可用的论证角度”。这样架构师拿到之后才能直接用来搭骨架而不是再花一轮去理解。2.3 角色之间的通信契约多智能体协作最容易翻车的地方就是通信。我的经验是智能体之间传递的信息必须是“自包含”的也就是说下游智能体拿到上游的输出后不需要回头去问上游“你这句话什么意思”。具体做法是给每个交接点定义一个固定的 JSON 结构。比如侦察员交给架构师的素材卡片长这样{ topic: 多智能体协作的通信开销, facts: [ { statement: 智能体数量超过七个后通信轮次呈指数增长, source: 内部实测记录, confidence: high, usable_angle: 论证为什么五个是平衡点 } ], gaps: [缺少具体的轮次对比数据] }这个结构里gaps字段特别关键——它明确告诉下游“我这边还有什么没搞定”架构师就能在规划时避开这些坑或者主动标注“此处需要补充”。没有这个字段下游就会默认上游给的是完整的结果写到一半发现缺东西整个流程就得回滚。3. 调度者整条链路的指挥官3.1 调度者的核心任务不是“分配”而是“拆解”很多人以为调度者就是发号施令的把任务丢给其他智能体就完事了。我一开始也这么想结果发现调度者如果只做分配整个流程会非常僵硬——因为其他智能体拿到的是模糊指令输出质量完全看运气。调度者真正要做的是把用户的模糊需求拆成可执行的原子任务。比如用户说“帮我写一篇关于多智能体协作的文章”调度者要输出的是这样一份清单检索多智能体协作的典型架构模式交给侦察员检索协作过程中的常见失败案例交给侦察员基于素材设计文章结构交给架构师按结构撰写初稿交给写手核查事实并统一风格交给审稿人每个原子任务都要附带明确的验收标准。比如第 1 项的标准是“至少找到三种不同的架构模式每种有具体案例支撑”。有了验收标准侦察员才知道自己要做到什么程度才算完成而不是随便搜几条就交差。3.2 调度者如何决定执行顺序顺序不是随便排的。我的原则是有依赖关系的串行无依赖关系的并行。上面那个例子里第 1 和第 2 项都是检索任务互不依赖可以同时跑第 3 项依赖前两项的结果必须等第 4 项依赖第 3 项第 5 项依赖第 4 项。但这里有个坑并行任务的结果汇总时顺序会影响架构师的理解。如果侦察员 A 先返回、侦察员 B 后返回架构师拿到的素材顺序就是乱的。我的解决办法是让调度者在汇总时按预设的优先级重新排序而不是按返回时间。这个细节很小但不处理的话架构师设计出的大纲逻辑会跳来跳去。3.3 调度者的异常处理机制实际跑起来最常出问题的是某个智能体“卡住”或者“跑偏”。调度者必须有一套异常处理逻辑。我的做法是给每个原子任务设一个“最大重试次数”和“超时阈值”。比如侦察员如果两次返回的素材都不符合验收标准调度者就不再重试而是标记这个任务为“降级完成”并在最终输出里注明“此处素材不足结论仅供参考”。提示不要指望调度者能自动修复所有问题。它的核心价值是“让流程可控”而不是“让流程完美”。有些任务就是做不好这时候诚实地标注出来比强行编一个结果要靠谱得多。4. 侦察员与架构师从素材到骨架的转化4.1 侦察员的素材处理原则侦察员最容易犯的错是“什么都往回搬”。我见过很多实现方案侦察员把搜到的网页全文直接丢给下游结果下游被海量无关信息淹没。我的原则是侦察员只返回“经过提炼的、带来源的、可验证的”素材。具体操作上我让侦察员做三层过滤第一层剔除明显无关的内容第二层把长文压缩成三到五条核心事实第三层给每条事实标注可信度。可信度分三档high 表示有明确来源且逻辑自洽medium 表示来源模糊但内容合理low 表示只有单一来源且无法交叉验证。架构师拿到素材后会优先使用 high 档的medium 档的作为补充low 档的基本不用。这个过滤过程会损失一些信息但换来的是下游效率的大幅提升。我实测过不做过滤的话架构师设计大纲的时间要多花三倍而且经常被无关信息带偏。4.2 架构师如何设计“可写”的大纲架构师的核心任务不是“列个目录”而是设计一套论证逻辑。我要求架构师输出的大纲必须包含三个要素每个章节的核心论点、支撑该论点的素材编号、以及章节之间的过渡逻辑。举个例子如果大纲里有一章叫“通信开销是协作的瓶颈”架构师必须注明这一章用素材 3 和素材 7 来支撑论点是“智能体数量增加导致通信轮次指数增长”并且要说明“这一章紧接在角色切分之后因为读者需要先理解角色划分才能理解为什么角色多了通信会爆炸”。没有这层逻辑写手拿到大纲后只能机械地填充内容写出来的东西章节之间是断裂的。有了这层逻辑写手就知道每一段该往哪个方向使劲。4.3 素材不足时架构师的应对策略有时候侦察员返回的素材就是不够。这时候架构师不能硬编而应该主动调整结构。我的做法是让架构师在素材不足的地方标注“此处需要补充案例”或“此处建议改为经验分享而非事实论证”。这个机制很重要因为它避免了写手在素材不足时胡编乱造。我见过太多 AI 生成的内容明明没有数据支撑却写得像有数据一样这种内容发出去是砸招牌的。架构师主动标注缺口写手就能用“根据我的经验”这类表述来过渡既诚实又自然。5. 写手与审稿人从初稿到终稿的打磨5.1 写手的“风格锚定”技巧写手最大的挑战是风格不稳定。同一个写手智能体写第一篇和第二篇的语气可能完全不同。我的解决办法是给写手一个“风格锚定样本”——在系统提示里放一段我过去写的、风格满意的文字要求写手在输出时模仿这段文字的节奏和用词习惯。这个技巧看起来简单但效果非常明显。没有锚定样本的时候写手写出来的东西要么太正式像论文要么太随意像聊天。有了锚定样本风格一致性至少提升了一个档次。锚定样本不用太长三五百字就够了关键是选一段你自己满意的、能代表你目标风格的文字。5.2 审稿人的双重校验机制审稿人要做两件事事实核查和风格统一。这两件事的评判标准不同所以我让审稿人分两轮来做。第一轮只做事实核查逐条对照素材卡片检查初稿里的每个事实性陈述是否有来源支撑。第二轮只做风格统一检查用词、句式、段落长度是否符合锚定样本的风格。分两轮的好处是避免“改着改着把事实改错了”。如果同时做两件事审稿人可能会为了风格流畅而删掉一些关键事实或者为了保留事实而容忍风格上的不一致。分开做每轮只关注一个目标质量会稳定很多。5.3 审稿人的修改意见如何被写手采纳审稿人输出的是修改意见不是直接改稿。这个设计是故意的——让写手自己改比让审稿人直接改更能保持全文一致性。如果审稿人直接改它可能只改了局部但局部改动会破坏全文的节奏。让写手根据意见重写相关段落写手会通盘考虑上下文改出来的东西更协调。修改意见的格式也有讲究。我要求审稿人输出的是“问题定位 问题类型 修改建议”而不是“把这句话改成那句话”。比如“第三段第二句事实错误素材 5 显示的数据是 2023 年的不是 2022 年建议核对后修正。”这种格式给了写手足够的上下文写手能理解为什么要改而不是机械地执行替换。6. 实测中踩过的坑与调优经验6.1 上下文爆炸多智能体协作最大的隐形杀手跑多智能体最容易被忽视的问题就是上下文长度。每个智能体都要读取上游的输出如果上游输出很长下游的上下文就会被撑爆。我最初的设计里侦察员返回的是完整素材架构师返回的是详细大纲写手返回的是全文初稿审稿人返回的是全文加修改意见——到最后一轮上下文已经长到模型开始“遗忘”前面的内容了。解决办法是每一层都做摘要压缩。侦察员返回素材卡片而不是全文架构师返回大纲加关键论据而不是详细描述写手返回初稿时附带一个“本章要点”的简短摘要。这样每一层的输出都控制在合理长度内下游读起来不会吃力。6.2 角色越界智能体总想干别人的活另一个常见问题是角色越界。写手有时候会忍不住去“核查事实”审稿人有时候会忍不住去“重写段落”。这种越界会导致流程混乱——写手核查的事实可能不准审稿人重写的段落可能偏离大纲。我的应对方法是在每个智能体的系统提示里明确写“你不负责什么”。比如写手的提示里写“你只负责按大纲填充内容不要核查事实不要调整结构遇到不确定的事实直接标注‘待核查’。”审稿人的提示里写“你只负责提出修改意见不要直接改稿不要新增内容。”把边界写死越界的情况就少了很多。6.3 循环依赖A 等 BB 等 A多智能体协作最怕的就是循环依赖。我遇到过一次架构师设计大纲时需要侦察员补充素材侦察员补充素材时需要架构师明确检索方向两边互相等流程直接卡死。后来我定了一条死规矩任何两个智能体之间只能单向依赖不能双向。如果架构师需要补充素材它不能直接找侦察员而是把需求返回给调度者由调度者发起新一轮侦察任务。这样依赖关系始终是单向的不会形成环。6.4 质量波动的收敛方法多智能体协作的最终输出质量往往取决于最弱的那一环。我实测下来最容易出问题的是侦察员——素材质量不稳定下游再怎么努力也救不回来。我的收敛方法是给侦察员加一个“自检”步骤返回素材前先自己检查一遍每条素材是否满足验收标准不满足的要么补充要么剔除。这个自检步骤会增加侦察员的运行时间但换来的是下游返工率的大幅下降。算总账是划算的。7. 这套架构适合什么场景不适合什么场景7.1 适合的场景特征这套五智能体架构最适合任务链路长、质量要求高、但单次任务量不大的场景。比如深度内容创作、行业研究报告、复杂方案的初稿撰写。这些场景的共同点是一个人做太耗时但又不值得专门组一个团队任务有明确的阶段性每个阶段的质量标准不同最终输出需要经过多轮打磨。我目前用它来跑三类任务每周的深度稿、月度行业简报、以及给客户做的方案初稿。跑顺了之后原本需要四五个小时的工作现在一个半小时左右能出可用的初稿我再花半小时做人工润色就能交付。7.2 不适合的场景特征反过来如果你的任务是实时性要求极高、或者单次任务极其简单这套架构就不合适。比如客服自动回复、简单的信息查询用单个智能体甚至直接调 API 就够了上多智能体纯属浪费。还有一种不适合的情况是任务目标本身就很模糊。多智能体协作的前提是任务能被拆解成清晰的原子步骤。如果连你自己都说不清楚要做什么调度者拆出来的任务清单也是乱的后面全盘皆输。这种时候应该先人工把需求想清楚再交给智能体团队。7.3 从单智能体迁移到多智能体的时机判断我的经验是当你发现单个智能体的提示词里开始出现“既要……又要……”的时候就是该拆的时候了。比如你发现提示词里写着“既要保证事实准确又要保证语言流畅还要控制篇幅”这三个目标经常互相冲突单智能体很难同时满足。这时候拆成侦察员、写手、审稿人三个角色每个角色只对一个目标负责质量会立刻提升。但也不要拆得太早。如果单智能体跑得挺好就别折腾。多智能体的维护成本是单智能体的好几倍每增加一个角色你就要多维护一套输入输出契约、多处理一类异常情况。只有当单智能体的质量瓶颈确实卡住了你才值得上多智能体。8. 我个人的几条实操建议第一先把两个智能体跑通再扩展到五个。我一开始就搭了五个结果调试的时候根本分不清是哪个环节出的问题。后来退回到两个——一个搜集一个写作——跑顺了之后再逐步加入架构师、审稿人和调度者。每加一个只调这一个问题定位起来快得多。第二给每个智能体写一份“岗位说明书”。不要只在系统提示里写几句而是像给真人写岗位描述一样写清楚职责、权限、输入输出格式、异常处理方式。这份说明书越详细智能体的表现越稳定。我现在的说明书每份都在八百字以上看起来啰嗦但省下了大量调试时间。第三保留人工介入的接口。再好的多智能体系统也会有搞不定的时候。我在调度者那里留了一个“人工接管”的开关遇到它连续三次重试都失败的任务就暂停流程等我人工处理。这个开关救过我好几次避免了一堆垃圾输出直接流到终稿。第四定期回看智能体之间的通信记录。我每周会抽半小时翻一遍这周所有智能体的输入输出记录看看有没有角色越界、有没有信息损耗、有没有可以优化的交接格式。这个习惯让我发现了很多隐蔽的问题比如某个智能体的输出格式偶尔会漂移导致下游解析失败但如果不看记录根本发现不了。这套东西说到底就是一个思路把复杂任务拆成清晰的阶段每个阶段交给一个专注的智能体用严格的契约保证交接质量。技术实现上没有什么高深的东西难的是对任务本身的理解和对边界的把控。你把这两件事想清楚了五个智能体也好三个也好都能跑起来。