1. 为什么我要折腾“一个人的 AI 团队”去年年底我接了一个私活客户要求两周内交付一套带数据分析、文案生成、竞品监控和自动回复的运营中台。预算只够我一个人干时间紧到连需求评审都省了。当时我第一反应不是加班而是——能不能让几个 AI 智能体替我把活分了这个念头就是“一个人的 AI 团队”的起点。说白了多智能体协作不是让一个模型干所有事而是把一个大任务拆成若干角色每个角色由一个独立的智能体承担彼此通过消息、文件或共享状态来交接工作。它解决的核心问题是单个大模型在长链路任务里容易“忘事”、跑偏、上下文爆炸而拆成多个专职智能体后每个智能体只关心自己那一小段稳定性和可维护性都会明显提升。这套东西适合谁适合独立开发者、小团队负责人、想用 AI 提效但不想被复杂框架绑架的运营和产品同学。哪怕你只会写一点 Python也能照着搭起来。我最终用五个智能体跑通了整条链路调度者、研究员、分析师、写手、审核员。下面我把这套分工的设计思路、每个环节的实现细节、踩过的坑以及可以直接抄的配置全部摊开讲。2. 五个智能体的角色设计与分工逻辑2.1 为什么是五个而不是三个或十个很多人一上来就想搞十几个智能体觉得角色越多越像“团队”。我试过结果是消息在智能体之间来回弹一个简单任务跑了四十多轮还没收敛。智能体数量应该由任务链路的“职责断点”决定而不是拍脑袋。我梳理自己的运营中台需求发现天然存在五个不可合并的职责调度者接收人类指令拆解任务决定下一步交给谁。研究员负责信息检索、资料收集、原始素材整理。分析师对数据做清洗、统计、找规律输出结论。写手把结论转成可读的文案、报告、回复话术。审核员检查事实、语气、合规性决定是否打回重做。这五个角色之间是串行加条件回环的关系不是并行。如果硬把研究员和分析师合并会出现“边查边算”导致上下文里混入大量无关原始数据如果把写手和审核员合并模型会倾向于“自己写自己夸”审核形同虚设。所以五个是我实测下来职责边界最清晰、回环最少的数量。2.2 每个智能体的“人设”该怎么写智能体的系统提示词就是它的岗位说明书。我踩过的最大坑是提示词写得太“温柔”模型就会偷懒。比如研究员如果只写“请收集资料”它可能只返回两条搜索结果。后来我改成带硬性输出格式和数量约束的写法效果立刻不一样。调度者的提示词核心是“只做分派不做执行”你是任务调度者。收到用户指令后只输出一个 JSON {next: researcher|analyst|writer|reviewer|done, task: 具体子任务描述, context: 需要传递的上下文摘要} 禁止自己回答问题禁止输出 JSON 以外的任何内容。研究员的提示词强调“来源和数量”你是资料研究员。针对给定主题输出至少 5 条要点每条必须附带来源类型网页/文档/数据库和一句话摘要。 不确定的信息标注 [待核实]禁止编造具体数字。分析师要求“先清洗再计算”你是数据分析师。收到原始数据后先列出清洗步骤去重、缺失值处理、单位统一再给出统计结果。 所有计算必须写出中间过程禁止直接给结论。写手强调“面向读者”你是内容写手。根据分析结论撰写面向运营人员的说明语言口语化每段不超过 4 行。 禁止添加分析中没有的数据禁止使用“综上所述”这类套话。审核员是最后一道闸你是审核员。逐条检查事实一致性、语气合规性、格式完整性。 输出格式{pass: true/false, issues: [问题1, 问题2], fix_suggestion: 修改建议} 只要发现事实错误或不合规表述pass 必须为 false。提示提示词里的“禁止”比“请”有用得多。模型对否定指令的遵守度在实测中明显高于正向请求。2.3 角色之间的交接协议五个智能体不能各说各话必须有统一的交接格式。我用的是**“三段式消息”**任务描述、上下文摘要、期望输出格式。调度者每次分派都带上这三段接收方处理完再按同样格式回传。这样做的好处是任何一个智能体挂掉我都能从消息记录里定位到断点而不是面对一堆自然语言瞎猜。举个实际交接例子。用户说“帮我分析上周竞品公众号的选题规律并写一份简报”。调度者拆成研究员抓取竞品上周推文标题和阅读量输出要点列表。分析师对标题做关键词聚类统计高频词和发布时间分布。写手根据聚类结果写 500 字简报。审核员检查数据是否与研究员原始输出一致。每一步的 context 字段只传上一步的结论摘要不传原始全文。这是控制上下文长度的关键否则跑到第四步时上下文已经爆了。3. 核心细节解析与实操要点3.1 智能体框架怎么选别被“平台”绑架市面上智能体框架很多从轻量级的脚本编排到可视化平台都有。我的建议是如果你只是一个人做项目优先选代码可控、依赖少的方案。可视化平台搭起来快但一旦某个环节要改逻辑拖拽界面反而比改代码慢。我最后用的是 Python 加一个轻量编排层核心逻辑不到 300 行所有智能体都是函数消息用字典传递。选型时我重点看三个指标指标为什么重要我的取舍上下文控制多轮交接容易爆 token必须支持手动裁剪历史失败重试某个智能体超时不能拖垮全局每个角色独立重试 2 次状态持久化断点续跑避免重头再来每步落盘 JSON 文件那些带“无限制对话”“一键生成”噱头的工具我基本不碰。原因很简单多智能体协作的难点从来不是生成而是收敛。一个不受约束的智能体会把任务带偏最后审核员都救不回来。3.2 上下文管理多智能体最容易翻车的地方单个智能体对话时上下文就是聊天记录。但五个智能体接力时如果把所有历史都往下传到写手那一步上下文可能已经上万 token模型开始“抓不住重点”。我的做法是分层上下文全局上下文只存用户原始指令和最终目标所有智能体可见但很短。局部上下文每个智能体只拿到自己需要的上一步输出处理完就丢弃原始细节只保留结论。归档上下文完整消息记录写进本地文件供我事后排查不进入模型。实测下来这套分层能把交接时的平均上下文压到 800 token 以内比全量传递少了将近八成。代价是偶尔会丢失一些细节所以我在调度者的提示词里加了一条“如果子任务需要上上步的原始数据显式向调度者申请由调度者从归档中提取。”这样既省 token又不至于断链。3.3 输出格式约束让智能体“说人话”也“说结构化的话”智能体之间交接最怕的是自由发挥。研究员如果返回一大段散文分析师就得先做自然语言理解多一层不确定性。所以我强制所有智能体间消息用 JSON只有最终面向用户的输出才转成自然语言。这里有个细节JSON 的字段名要固定不能这次叫result下次叫output。我定义了一套统一 schema{ from: researcher, task_id: t-001, status: success, summary: 一句话结论, details: [要点1, 要点2], confidence: 0.85, need_review: false }confidence字段是我后来加的让智能体自评把握程度。审核员会优先检查低置信度的条目效率高很多。need_review则是给调度者的信号如果研究员自己都觉得资料不够调度者可以决定是否让研究员再跑一轮。注意不要指望模型每次都严格输出合法 JSON。我在解析前加了一层容错先用正则提取花括号内容再尝试解析失败就触发重试。这个兜底逻辑救了我无数次。4. 实操过程与核心环节实现4.1 环境准备与最小可运行骨架我不建议一上来就接真实 API 跑五个智能体那样调试成本太高。第一步应该是用假数据跑通编排逻辑。我的做法是写一个mock_agent函数根据角色名返回预设的 JSON先把调度、交接、审核回环全部走通确认流程没问题再替换成真实模型调用。最小骨架大概长这样import json AGENTS [researcher, analyst, writer, reviewer] def dispatch(task, context): # 调度者逻辑根据任务和上下文决定下一个智能体 # 真实场景这里调用模型mock 阶段用规则 if research not in context: return researcher if analysis not in context: return analyst if draft not in context: return writer return reviewer def run_team(user_input, max_rounds12): context {goal: user_input, history: []} for i in range(max_rounds): next_agent dispatch(user_input, context) if next_agent done: break result call_agent(next_agent, context) context[history].append(result) # 审核不通过则打回 if next_agent reviewer and not result.get(pass, True): context[rework] result.get(fix_suggestion) return contextmax_rounds是必须的。我吃过亏有一次审核员和写手互相“踢皮球”一个说数据不对一个说数据没问题跑了二十多轮。加上轮次上限后超限就人工介入避免死循环烧钱。4.2 调度者的拆解逻辑与参数选择调度者是整个团队的大脑它的拆解质量直接决定后面顺不顺。我一开始让调度者“自由发挥”结果它有时把简单任务拆成七八步有时又漏掉审核。后来我给它加了拆解模板任何涉及“分析”“统计”的任务必须经过研究员和分析师两步。任何面向外部输出的任务必须经过写手和审核员。纯查询类任务可以跳过分析师。同时给调度者设了最大子任务数 6。超过 6 步的任务说明用户指令本身太模糊调度者应该先反问用户而不是硬拆。这个“反问”机制很关键我实测发现让调度者在信息不足时主动提问比让它猜着干要省一半返工。参数上调度者的温度我设成 0.2接近确定性输出写手的温度设 0.7保留一点表达灵活性审核员设 0.1要的就是严格。不同角色用不同温度这是很多人忽略的细节。4.3 审核回环怎么让“打回重做”不变成死循环审核员说“不通过”很容易难的是让写手知道怎么改。我的审核员输出里必须带fix_suggestion而且要求具体到句子不能只说“语气不好”。比如它会输出“第二段‘销量暴涨’缺乏数据支撑建议改为‘销量环比增长 23%’数据来自研究员要点 3。”写手收到打回后只重写被点名的部分不重写全文。这样既省 token又避免改出新问题。如果同一处被打回两次调度者会介入判断是研究员数据有问题还是写手理解有问题而不是让它们继续互相折磨。我设的回环上限是每个任务最多打回 2 次。超过 2 次就标记为“需人工处理”把当前草稿和审核意见一起推给我。实测中真正需要人工介入的比例不到 10%大部分任务两轮内就能过。4.4 一次完整任务的运行记录拿“分析竞品上周选题并写简报”这个真实任务举例我的运行记录大致如下轮次智能体耗时输出摘要是否通过1调度者1.2s拆成 4 步分派研究员-2研究员8.5s返回 12 条推文要点置信度 0.8-3分析师6.3s聚类出 3 个高频主题-4写手5.1s生成 520 字简报初稿-5审核员2.8s发现 1 处数据不一致打回否6写手4.2s修正数据引用-7审核员2.5s通过是整条链路约 30 秒消耗 token 约 4200。如果换成单个模型一次性生成质量明显不如这套流程尤其是数据一致性上单模型经常把研究员给的数字写错。5. 常见问题与排查技巧实录5.1 智能体“抢活”或“甩锅”怎么办这是多智能体最典型的问题。表现是研究员返回的内容里带了分析结论或者分析师说“资料不足请研究员补充”却不说补什么。根因是职责边界在提示词里没写死。我的解决办法是在每个智能体的提示词末尾加一句“你只负责 X遇到不属于你职责的内容原样传递给调度者不要自行处理。”另外调度者在分派时要带上“禁止事项”。比如给研究员的分派消息里写“只收集不分析不写文案。”这句话看着多余但实测能减少大量越界行为。5.2 上下文丢失导致前后矛盾常见现象是写手引用的数据和分析师结论对不上。排查思路是先看消息记录定位是哪一步丢了上下文。我遇到过一次原因是分析师输出太长我在裁剪时把关键数字截掉了。后来我改成裁剪只裁描述性文字数字和结论字段永不裁剪。还有一个隐蔽原因是 JSON 解析失败后静默重试重试时上下文没带全。所以我在重试逻辑里强制带上原始消息而不是只带摘要。5.3 成本失控什么时候该停多智能体比单模型贵这是事实。我给自己定了三条止损线单任务 token 超过 8000暂停并检查是否陷入回环。单任务耗时超过 2 分钟检查是否有智能体超时重试。单日总消耗超过预算自动降级为单模型处理简单任务。提示不是所有任务都值得上五个智能体。简单问答、单步生成直接调一个模型更快更便宜。多智能体的价值在长链路、多职责、需要审核的场景。5.4 常见问题速查表问题现象可能原因排查动作解决方式任务跑不完回环无上限看轮次记录设 max_rounds 和打回上限输出前后矛盾上下文被裁剪对比各步消息数字结论字段不裁剪智能体越界职责提示词模糊看越界内容加“只负责 X”约束JSON 解析失败模型自由发挥看原始返回加正则兜底和重试成本飙升重复检索或回环统计各步 token降级简单任务缓存检索结果5.5 我踩过的三个真实坑第一个坑是让审核员也参与生成。我一开始图省事让审核员在发现问题时直接改结果它改着改着就把整篇重写了还引入了新错误。后来严格规定审核员只提意见不改内容。第二个坑是所有智能体共用一个系统提示词模板。看起来省事实际上每个角色的约束完全不同共用模板导致研究员和写手行为趋同。拆成独立提示词后角色差异立刻明显。第三个坑是忽略冷启动。第一次跑某个任务时研究员没有历史资料返回质量很差。后来我加了一个“预热”步骤让研究员先跑一轮宽泛检索把结果存进本地知识库后续任务就能复用。这个改动让研究员的平均置信度从 0.6 提到了 0.8。6. 后续可以怎么扩展这套团队跑通五个智能体之后我陆续做了几个扩展效果都不错。一个是给研究员加本地知识库把常用资料向量化检索时先查本地再查外部速度和稳定性都提升明显。另一个是给调度者加任务优先级紧急任务走快速通道跳过部分审核适合时效性强的场景。还有一个我觉得很有价值的扩展方向让审核员积累“错题本”。每次打回的原因都记下来定期总结成新的约束规则反哺到写手和研究员的提示词里。这样团队会越跑越顺而不是每次都在同样的地方犯错。如果你也想搭一套我的建议是从两个智能体开始——一个干活一个审核。跑顺了再加研究员和分析师。别一上来就追求五个角色齐全先把交接和审核跑通比什么都重要。我见过太多人卡在“框架选型”上其实真正决定成败的是提示词约束和上下文管理这两样跟用什么框架关系不大。