1. 为什么一个人需要一支 AI 团队1.1 单智能体的天花板在哪里过去一年我几乎把市面上能试的智能体框架都摸了一遍从最早的 AutoGPT 到后来的 Dify、扣子再到各种开源的多智能体编排库。踩了无数坑之后我得出一个很朴素的结论单个智能体做复杂任务几乎必然会在某个环节掉链子。原因不复杂。一个智能体本质上就是“一个大模型 一段系统提示词 若干工具”。当你让它同时负责“理解需求、拆解任务、查资料、写代码、做校验、输出报告”时它的上下文会被塞满注意力被稀释提示词越写越长最后变成一锅粥。我实测过一个典型场景让单个智能体写一份带数据支撑的行业分析它前 30% 写得像模像样到中间开始编数据最后干脆把前面写过的结论又抄了一遍。这不是模型不行是角色过载。打个比方这就像你让一个人同时当产品经理、程序员、测试和项目经理。他可能每样都懂一点但四件事同时压过来必然顾此失彼。人的做法是组队分工智能体也一样。1.2 五个智能体的分工模型是怎么来的我最终稳定下来的方案是五个智能体分别承担规划、检索、执行、校验、汇总五个角色。这个数字不是拍脑袋定的是我从三个、四个、六个一路试过来的结果。三个智能体的问题是规划和执行经常打架校验没人做六个以上则沟通成本陡增智能体之间来回传话token 消耗翻倍而且容易出现“踢皮球”——A 说等 BB 说等 C最后卡死。五个刚好覆盖一条完整链路每个角色职责单一输入输出边界清晰。这套模型的核心思想是把“思考”和“干活”分开把“干活”和“检查”分开。规划智能体只负责拆任务不碰具体内容执行智能体只负责按指令产出不做全局判断校验智能体专门挑刺。每个智能体都活在自己的小上下文里互不污染。1.3 这套方案适合谁参考如果你正在做智能体开发、想搭一套能真正跑通复杂流程的多智能体系统或者你只是一个人想用 AI 完成原本需要一个小组才能做的事这套分工模型都能直接抄。它不依赖特定平台Dify、扣子、LangGraph、AutoGen 都能落地甚至你用最原始的 API 调用加一个循环调度器也能实现。需要说明的是下面讲的所有参数、提示词结构、调度逻辑都是我在实际项目里跑通并反复调优过的。涉及具体数值的地方我会给出计算依据涉及取舍的地方我会讲清楚为什么这么选。2. 五个智能体的角色定义与职责边界2.1 规划智能体只做拆解不做执行规划智能体的唯一职责是把用户的一句话需求拆成一份带依赖关系的任务清单。它的输出必须结构化我通常要求它输出 JSON包含任务 ID、任务描述、依赖任务 ID、预期产出格式四个字段。为什么强制 JSON因为下游的执行智能体需要按顺序领取任务如果规划输出的是自然语言调度器就得再写一个解析器多一层就多一个出错点。JSON 是机器和人都能读的格式调试时一眼就能看出任务拆得对不对。规划智能体的系统提示词里有一条铁律禁止在规划阶段给出任何具体答案或内容。我早期犯过这个错规划智能体顺手把答案写了结果执行智能体要么照抄要么和规划打架。后来我在提示词里明确写“你只负责拆解任何具体结论、数据、代码都不得出现在你的输出中”问题才解决。一个典型的规划输出长这样{ tasks: [ {id: T1, desc: 收集近三年行业规模数据, deps: [], format: 表格}, {id: T2, desc: 分析增长驱动因素, deps: [T1], format: 段落}, {id: T3, desc: 撰写结论与建议, deps: [T2], format: 段落} ] }2.2 检索智能体负责找料不负责判断检索智能体的职责是根据任务描述去获取原始素材。它可以是联网搜索、查本地知识库、读数据库或者调用某个 API。关键在于它只负责“把料找回来”不负责判断料好不好、对不对。为什么不让检索智能体顺便做判断因为判断需要全局视角而检索智能体只看到当前任务。如果它自作主张过滤掉“看起来没用”的资料很可能把后面执行环节需要的关键细节给扔了。我的做法是让检索智能体宁滥勿缺把相关度超过阈值的都带回来由执行智能体在使用时再筛选。这里有个实操细节检索智能体返回的内容必须带来源标记。我要求每条资料前面加一个[来源:xxx]的标签这样后面校验智能体发现数据有问题时能直接定位到是哪条资料出的错。没有来源标记的检索结果在我这里一律打回重做。2.3 执行智能体按单干活不越界执行智能体是真正“产出内容”的角色。它领取一个具体任务拿到上游检索智能体给的素材然后按规划智能体指定的格式输出。执行智能体的提示词里我加了两条约束。第一只处理当前任务不允许它去操心别的任务。第二必须标注引用了哪些素材。比如它写了一段分析后面要跟上[引用:T1-资料3]这样的标记。这样做的好处是校验智能体可以逐条核对而不是笼统地说“感觉不对”。执行智能体的温度参数我通常设得比较低0.3 到 0.5 之间。温度高了它容易自由发挥偏离任务描述温度太低又显得死板。0.4 是我实测下来在“忠实执行”和“表达自然”之间比较平衡的值。2.4 校验智能体专门挑刺不负责改校验智能体是我认为整套系统里最容易被忽略、但价值最高的一环。它的职责只有一个找出执行智能体产出中的问题。它不改内容只列问题清单。我让校验智能体从四个维度检查事实一致性有没有和素材矛盾、逻辑连贯性前后有没有打架、格式合规性是不是按要求的格式输出、完整性任务描述里的要求有没有漏。每个维度它都要给出具体的定位比如“第 3 段第 2 句的数据与 T1-资料2 不符”。校验智能体的提示词里我特意加了一句“你的任务是找问题不是夸赞。如果实在找不出问题也要指出至少一处可以改进的地方。” 这是为了防止它偷懒直接回一句“没问题”就交差。实测下来加了这句话之后校验环节的检出率明显提升。2.5 汇总智能体拼装成品不添油加醋汇总智能体负责把各个执行智能体的产出按规划的任务依赖关系拼装成最终成品。它的核心约束是只做拼接和过渡不新增任何实质性内容。我见过很多人让汇总智能体“润色一下”结果它把执行智能体的结论改了导致前面校验白做。我的做法是让汇总智能体只做三件事按顺序排列、加过渡句、统一格式。任何涉及事实、数据、结论的修改一律打回执行智能体重做。汇总智能体的输出就是最终交付给用户的内容。它拼装完成后我会再跑一次轻量校验主要看格式和衔接不重复做事实核查因为那是校验智能体已经做过的事。3. 智能体之间的协作机制怎么设计3.1 调度器整个团队的大脑五个智能体不会自己互相喊话它们通过一个中央调度器来协调。调度器的工作很简单读规划智能体的任务清单按依赖关系依次唤醒对应的智能体把上游的输出传给下游。为什么不用智能体之间直接通信我试过太乱。A 直接找 BB 直接找 C出了问题根本不知道是谁先动的手。中央调度器虽然看起来“笨”但它让整个流程可追踪、可回放、可中断。任何一个环节出错我都能在调度日志里看到当时传了什么参数、返回了什么结果。调度器的核心逻辑用伪代码表示大概是这样tasks planner.run(user_input) results {} for task in topological_sort(tasks): if task.type retrieve: results[task.id] retriever.run(task, results) elif task.type execute: results[task.id] executor.run(task, results) elif task.type verify: issues verifier.run(task, results) if issues: results[task.id] executor.run(task, results, fixissues) final summarizer.run(results)注意里面那个if issues的分支校验不通过就打回执行智能体重做。这个重试我设了上限最多两轮。两轮还过不了就把问题清单直接附在最终输出里让人来判断。无限重试是我早期踩过的大坑两个智能体互相不服来回改了十几轮token 烧了一大把最后产出还不如第一版。3.2 上下文传递只传该传的不传全部多智能体系统最容易失控的地方就是上下文膨胀。如果每个智能体都能看到前面所有智能体的全部输出那到第四个智能体时它的上下文里已经塞了几万字注意力完全涣散。我的做法是按需传递。规划智能体只把当前任务描述和直接依赖任务的产出传给执行智能体不传无关任务的内容。检索智能体只把和当前任务相关的素材传给执行智能体。校验智能体则拿到任务描述、执行产出和对应的素材三样东西不多不少。这样每个智能体看到的上下文都控制在 2000 到 4000 token 之间既够用又不臃肿。我实测过按需传递比全量传递的 token 消耗降低了约 60%而产出质量反而更高因为每个智能体都聚焦在自己的那一小块上。3.3 失败重试与降级策略任何自动化系统都要考虑失败。我的策略分三层。第一层是单点重试。某个智能体调用超时或返回格式错误调度器自动重试一次。这一层解决的是网络抖动、偶发格式问题。第二层是打回重做。校验不通过时把问题清单附给执行智能体重做。这一层解决的是内容质量问题。第三层是降级输出。如果重做两轮还不过调度器不再纠缠直接把当前最好的版本加上问题清单输出并明确标注“以下内容存在未解决问题”。这一层解决的是“宁可交付有瑕疵的成品也不能卡死”的问题。我踩过最惨的一次坑就是没有设降级策略一个校验智能体死磕一个格式问题整个流程卡了四十分钟最后我手动 kill 掉。从那以后任何环节我都设了硬性超时和最大重试次数。3.4 智能体之间的“语言”统一五个智能体如果各说各话调度器就得当翻译很容易出错。我的做法是统一中间产出的格式。所有智能体之间的传递都用 JSON字段名固定。比如执行智能体的输出统一是{ task_id: T2, content: 正文内容, citations: [T1-资料3, T1-资料5], status: done }校验智能体的输出统一是{ task_id: T2, issues: [ {type: fact, location: 第3段第2句, desc: 数据与T1-资料2不符} ], pass: false }格式统一之后调度器不需要做任何自然语言解析直接读字段就行。这看起来是小事但实际开发中能省掉大量调试时间。我早期用自然语言传递光写解析正则就写了一整天还经常解析错。4. 从零搭建这套系统的实操步骤4.1 环境准备与框架选型框架选型上我推荐两条路线。如果你想要快速验证用 Dify 或扣子这类可视化平台拖拽就能搭出多智能体流程半天能跑通。如果你想要深度定制用 LangGraph 或 AutoGen代码可控性更强但上手需要一两天。我自己的主力方案是 LangGraph原因是它对“状态机”式的流程支持最好调度逻辑写起来清晰。AutoGen 更适合“对话式”的多智能体但我的场景是流水线式的LangGraph 更贴合。环境上没什么特殊要求Python 3.10 以上装好对应框架的 SDK再准备一个能调用的模型 API 就行。模型方面规划、校验、汇总这三个偏“思考”的角色我用能力强的模型检索和执行这两个偏“干活”的角色用速度快、成本低的模型。这样搭配下来整体成本能降一半左右。4.2 五个智能体的提示词怎么写提示词是这套系统的灵魂。我每个智能体的提示词都遵循同一个结构角色定义 职责边界 输出格式 禁止事项。以规划智能体为例我的提示词骨架是你是规划智能体。你的唯一职责是把用户需求拆解成任务清单。 你不负责执行任何任务不给出任何具体答案、数据或结论。 输出必须是JSON包含tasks数组每个task有id、desc、deps、format四个字段。 禁止在desc中写入具体内容只写“做什么”不写“是什么”。注意最后那句“只写做什么不写是什么”这是我反复调试后加上的。早期规划智能体经常在任务描述里就把答案写了导致执行智能体无事可做。执行智能体的提示词则强调“忠实”你是执行智能体。你只处理当前分配给你的任务。 你必须基于提供的素材产出内容不得编造素材中没有的信息。 每处引用素材的地方必须标注[引用:素材ID]。 输出格式必须符合任务描述中的format字段要求。校验智能体的提示词强调“挑刺”你是校验智能体。你的职责是找出执行产出中的问题不是修改不是夸赞。 从事实、逻辑、格式、完整四个维度检查。 每个问题必须给出具体位置和原因。 如果找不出问题也要指出至少一处可改进之处。4.3 调度器的核心代码实现调度器我用 Python 写核心就是一个拓扑排序加循环。关键代码如下import json from collections import deque def topological_sort(tasks): graph {t[id]: set(t[deps]) for t in tasks} in_degree {t[id]: len(t[deps]) for t in tasks} queue deque([tid for tid, d in in_degree.items() if d 0]) order [] while queue: tid queue.popleft() order.append(tid) for other in tasks: if tid in other[deps]: in_degree[other[id]] - 1 if in_degree[other[id]] 0: queue.append(other[id]) return order def run_pipeline(user_input): plan planner.run(user_input) tasks json.loads(plan)[tasks] order topological_sort(tasks) results {} for tid in order: task next(t for t in tasks if t[id] tid) context {dep: results[dep] for dep in task[deps]} output executor.run(task, context) issues verifier.run(task, output, context) retry 0 while issues and retry 2: output executor.run(task, context, fixissues) issues verifier.run(task, output, context) retry 1 results[tid] output return summarizer.run(results)这段代码里topological_sort保证任务按依赖顺序执行while issues and retry 2就是前面说的重试上限。实际项目里我还会加日志、超时、异常捕获但核心逻辑就这些。4.4 参数调优与成本控制参数上我重点调三个温度、最大 token、重试次数。温度方面规划 0.2、检索 0.1、执行 0.4、校验 0.1、汇总 0.3。规律是“越需要创造性的越高越需要严谨的越低”。执行智能体温度稍高是为了让表达自然其他角色都压得很低。最大 token 方面规划 1000、检索 2000、执行 3000、校验 1500、汇总 4000。这些值是根据各角色的典型输出长度定的设太小会截断设太大浪费。成本控制上我最大的心得是把便宜模型用在检索和校验上。检索只是搬运素材校验只是比对都不需要顶级模型。规划、执行、汇总这三个真正影响产出质量的环节才用能力强的模型。这样搭配下来一个中等复杂度的任务整体成本能控制在可接受范围内。5. 实际运行中踩过的坑与排查技巧5.1 智能体“踢皮球”怎么破最常见的故障是任务卡死。表现是调度器日志里某个任务一直处于“等待依赖”状态但依赖任务明明已经完成了。排查下来十有八九是依赖关系写错了或者某个任务的输出格式不对导致下游解析失败。我的排查步骤是先看调度日志里每个任务的完成状态找到第一个卡住的任务再看它的依赖任务输出是否符合预期格式最后检查规划智能体生成的任务清单里依赖关系有没有环。有环的话拓扑排序会直接失败这个好发现难发现的是“隐式依赖”就是规划智能体没写依赖但执行时又需要上游数据。解决办法是在规划智能体的提示词里加一条“如果任务 B 需要任务 A 的产出才能完成必须在 B 的 deps 里包含 A。” 加了之后隐式依赖的问题基本消失。5.2 校验智能体“放水”怎么办校验智能体偷懒是另一个高频问题。表现是它对明显有问题的产出回一句“通过”或者只挑格式问题不挑内容问题。我的对策有三条。第一提示词里明确“找不出问题也要指出改进点”逼它至少输出一条。第二给它提供检查清单让它逐项打勾而不是自由发挥。第三定期人工抽查它的校验结果发现放水就调整提示词。检查清单我通常这么写检查维度具体检查项事实数据是否与素材一致有无编造逻辑前后结论是否矛盾推理是否连贯格式是否符合任务要求的格式完整任务描述中的要求是否全部覆盖有了这张表校验智能体就没法含糊其辞必须逐项给结论。5.3 上下文串味怎么避免“串味”是指某个智能体的输出里混入了不属于它职责的内容。比如执行智能体在写分析时顺手把校验的活也干了加了一句“以上内容已核对无误”。这种串味会干扰下游判断。根因是提示词的边界不够硬。我的解决办法是在每个智能体的提示词末尾加一句“你只做 X不做 Y、Z”把不该它做的事明确列出来。比如执行智能体的提示词末尾写“你不做校验、不做汇总、不做规划”。加了这句之后串味问题大幅减少。5.4 常见问题速查表现象可能原因排查方法解决任务卡死依赖关系有环或隐式依赖看调度日志首个卡住的任务修正规划提示词强制声明依赖校验放水提示词太宽松人工抽查校验结果加检查清单强制逐项打勾上下文膨胀全量传递看单次调用 token 数改为按需传递重试死循环无重试上限看重试次数设最大重试 2 次超限降级输出格式错提示词未强制格式看返回内容提示词里明确 JSON 结构成本过高全用强模型看各角色 token 消耗检索校验换便宜模型5.5 我个人的几条实操心得第一先跑通两个智能体再扩到五个。我一开始就上五个调试时根本分不清是哪个环节的问题。后来退回到“规划执行”两个跑通了再加校验再加检索最后加汇总。每加一个都单独验证问题定位快得多。第二日志要记全。每个智能体的输入、输出、耗时、token 消耗全部落盘。出问题时翻日志比重新跑一遍快十倍。我现在的日志格式是每行一个 JSON包含时间戳、智能体名、任务 ID、输入摘要、输出摘要、耗时、token 数。第三别追求一次完美。多智能体系统的调优是迭代出来的不是设计出来的。我第一版跑出来的结果惨不忍睹但每跑一次就改一处提示词改了大概二十轮才稳定。这个过程没有捷径。第四人工兜底永远要有。再好的系统也会遇到它处理不了的情况。我在最终输出前留了一个人工确认环节重要任务必须人看一眼再发。这不是不信任系统而是对结果负责。这套五个智能体的分工协作模型我从最初的想法到稳定运行前后花了大概三周时间中间推翻重来了两次。现在它已经能处理我日常大部分的内容整理、数据分析和方案撰写工作我一个人加上这支 AI 团队产出效率大概相当于过去一个小型团队。如果你也在做类似的事希望上面这些踩坑记录能帮你少走点弯路。