在把多个大模型Agent串成一条流水线之前我以为难点会在大模型能力上。真正跑起来才发现最难的是让三个角色在一张表里各说各话还能说到一个频道上。这套多智能体协作系统我前前后后改了三版从最初的三个Agent各干各的到后来能稳定产出可交付的技术评审报告中间踩的坑比写的代码还多。今天把整个过程复盘一遍给同样想搭多智能体协作系统的朋友一些可参考的思路。我用这个案例解决的痛点很具体把一份模糊的产品需求转化成有结构的技术方案初稿再自动做一轮缺陷检测。过去靠单个大模型Prompt硬顶输入一长就上下文发飘指令权重被稀释现在改成产品经理Agent 架构师Agent 质检Agent的三人小组协作每个角色只管自己那一亩三分地问题反而变得可控。这个思路不挑框架核心在于角色边界、消息协议和决策兜底理解了这三点你用CrewAI也好手搓Prompt编排也好都能落地。1. 为什么单Agent顶不上去三个死穴逼着我把任务拆开1.1 上下文一长指令就开始飘先说最直观的问题。我最早尝试用一个大型Prompt让大模型完成全部工作输入需求文本要求它自己完成需求理解、方案设计、完整性检查三个步骤。效果在短输入时确实能看但需求一旦超过800字模型就开始顾头不顾尾。经常出现的情况是前面明确了只做接口层设计到后半段它又自动补了一段数据库建模或者质检环节让它指出自己方案里的漏洞它象征性挑两个小毛病大而明显的问题反而看不见。原因是多方面的。大模型的注意力机制对长上下文的处理并不是均匀的越靠后的指令在输出时越容易被前面大量的中间推理挤掉权重。我称它为指令被稀释。单个Prompt承载越多的职责、越长的前置信息每一步的指令强度都在被摊薄。1.2 角色错位一个模型没法同时演好做事的人和挑刺的人更深一层是角色冲突。做方案和查方案本质上是两种相反的思维方式。做方案需要顺着需求一路推理构建出一个自洽的系统查方案需要逆着思路去找漏洞打掉这份自洽。这两个动作放在同一个上下文里模型很容易被自己的推理带跑——它倾向于相信自己刚写出来的东西无法再去严格地质疑自己。我试过在同一个Prompt里加你现在是严格的审查者请批判你上一阶段的输出效果仍然理想。模型给出的缺陷往往是格式或措辞层面的小毛病真正的逻辑断链它抓不到。这就是角色错位同一个权重分布同时承载构建者和审视者两种心智本质上是矛盾的。1.3 问题定位不清出错了不知道找谁还有一个工程层面的死穴。单Agent模式下如果最终输出质量不达标你根本不知道是哪个环节出了问题——需求理解错了方案设计错了还是质量检查漏了你只能整段重推或者疯狂调整Prompt词。排查链路完全是黑的。这三个问题叠加在一起让我放弃了单Agent方案。多智能体协作不是炫技而是把一个大而模糊的任务切片成多个小而明确的任务每一个切片只承担一种心智模式本质上是在降低单次推理的熵。2. 协作系统骨架角色分工、消息协议与流程编排2.1 三个角色的分工边界宁可重叠不可真空多智能体系统里最常见的翻车不是Agent不会干活而是活被重复干或者没人干。我的做法是写清楚每个Agent的输入、输出、以及坚决不做什么。Agent角色输入输出明确不做什么产品经理Agent原始需求文本结构化需求清单功能列表、约束条件、验收标准不做技术方案不写代码架构师Agent结构化需求清单技术选型说明、模块划分、接口设计、数据模型不重新解读需求不做质量评价质检Agent架构方案全量文本缺陷列表按严重级别分级标注对应原文位置不修改方案不给替代设计最开始我把质检Agent设计成给出修改后的最优方案结果它越俎代庖产出了一份架构变形体和架构师Agent的输出冲突。后来硬性规定质检Agent只能定位问题、给出证据不能开药方。修改动作要回到架构师Agent那一层去重做。这个职责分离是整个系统稳定运行的关键。2.2 消息协议先定格式再谈协作Agent之间的消息格式我建议在写任何Prompt之前就定义死。用JSON包一层至少包含四个字段agent_name谁发出的、target_role给谁的、task_summary本阶段的结论摘要、raw_output完整输出。摘要字段特别重要它会成为下一阶段Agent的上下文锚点避免它读全文读到头晕。我踩过一个教训最初产品经理Agent输出的是一大段自然语言架构师Agent需要自己从中提取需求清单结果提取质量受输入表述影响很大。后来改为产品经理Agent必须输出固定Schema的需求项每条需求给id、title、detail、acceptance_criteria四个字段。架构师Agent收到的是一个结构体数组而不是一段散文。结构化的消息协议把Agent之间的翻译误差降到了最低。2.3 流程编排串行主链 条件重试整个流程用串行就够需求理解 → 方案生成 → 质量检查。但串行不等于死板我加了一个条件分支如果质检Agent反馈的严重缺陷数量超过阈值自动触发架构师Agent的方案修订模式让它在原方案基础上修订而不是从零生成然后再次送检。这个循环最多跑三次超过三次转入人工队列。这里注意一个细节修订模式的重试不能简单地把原方案和缺陷列表拼在一起再生成一遍。我在重试时要求架构师Agent明确引用缺陷ID并在修订说明里逐条回应已修改/无法修改/建议降级这样质检Agent在复检时能精准定位而不是从头再看一遍。这个引用-回应机制是系统从表面协作走向真协作的转折点。3. 四个翻车现场协作链路里最要命的坑3.1 陷阱一职责重叠导致的内容重复第一版系统跑出来的方案里出现过两套数据库设计。产品经理Agent在需求清单里顺手写了建议采用关系型数据库存储订单和用户数据架构师Agent原封不动把这句话演化成一个完整的库表设计。表面看问题不大但真正的风险在于产品经理Agent的建议没有任何技术论证却干扰了架构师的决策。排查过程很直接我比对了一段方案的文本来源发现一半是由需求阶段的原始文本直接转述。修复方案是在产品经理Agent的约束里加了一条需求文档中禁止出现任何技术实现细节包括技术栈命名、模块命名、数据库选型若需求文本本身含有这些内容一律将其移动到原始参考字段而非需求描述字段。同时在架构师Agent的约束里加了一条优先从需求清单的字段定义出发设计数据模型不准引用需求阶段的技术建议。教训协作系统的第一步不是让Agent多输出而是让Agent克制输出。每个Agent必须知道哪些内容不归自己管才不会污染下游输入。3.2 陷阱二上下文漂移——第二个Agent听不到第一个的弦外之音有个案例让我印象很深产品经理Agent在需求清单里明确写了本项目仅覆盖管理后台不涉及C端用户端但架构师Agent仍然做了一整套登录鉴权设计理由是管理后台也需要用户体系和权限控制。这确实是功能需要但它做重了——C端用户端的边界被悄悄膨胀了。问题出在上下文传递。架构师Agent读到的消息里仅覆盖管理后台被压缩在长长的task_summary角落里远不如需要设计安全可靠的权限体系这类显式指令醒目。模型在这方面和人类很像显著的、具体的、靠后的指令比隐含的、约束性的、靠前的指令更容易被执行。修复方法是边界显式化。我给产品经理Agent加了一个强制输出字段scope_constraints边界约束要求它把所有本项目不做的事单独列出来放到消息协议的高优先级字段中。架构师Agent被要求生成方案时第一段必须先复述scope_constraints内容并逐条说明本方案是否遵守。先复述再答题这个强制动作逼着模型在生成前就把边界空间过一遍。3.3 陷阱三质检死循环——一个缺陷永远修不完第三版测试时遇到一次真正的死循环质检Agent报出接口鉴权不完善架构师Agent修订后加了一版鉴权设计质检Agent又报鉴权逻辑仍然存在未覆盖场景架构师Agent再改质检Agent再挑出鉴权与角色权限模型耦合过深……三个来回后我手动叫停。问题不在质检严不严而在于缺陷清单没有收敛标准。我对质检Agent做了两个改变第一增加缺陷严重级别三维分类法P0逻辑错误必然影响上线/ P1功能缺失应该有但没有/ P2建议优化不影响功能第二设置复检准入机制——架构师Agent修订后质检Agent只复检上一轮被标记为P0和P1的缺陷禁止在复检中提出全新领域的P2级建议。等于是把评审范围锁定在增量上避免每一次复检都像第一次评审那样从头扫雷。经过这个调整循环次数从不可控收敛到平均1.3次绝大多数方案跑一遍质检就能通过少数需要第二次修订。3.4 陷阱四幻觉在链路中的逐级放大这就是幻觉传播。如果产品经理Agent在分析需求时编造了一个子功能这个子功能会原样出现在需求清单中架构师Agent会认真地为这个不存在的功能设计接口质检Agent会因为接口设计符合规范而放行。到最后你花了一整套智能协作的算力产出的是一个工整的、自洽的、但方向错误的方案。放大效应的核心在于下游Agent天然信任上游Agent的结构化输出格式越规范内容越不加怀疑。我的对策是双重的在流程层面加入了一个轻量级需求真实性校验步骤——它不改变任何设计只对需求清单做两件事一是检查是否存在与原始输入无关的自主添加项二是对每个需求项标注证据来源原文直接引用 / 基于原文合理推导 / 属于补充假设。凡是补充假设进入架构设计时优先级降两级并提示架构师标明该部分为假设性设计。这套机制并不完美但它把幻觉从隐形的污染变成了可见的标注至少在一开始就能被识别和人工校验。4. 从能跑到能用质量门禁与人工兜底4.1 质检Agent是门卫不是法官在设计质检Agent时我一直提醒自己它再智能本质上也还是一个大模型还是会漏、还是会误报。真正能用起来需要的是把质检结论转成可执行的门禁规则而不是直接信赖它的判断。我设置了三级门禁基础门禁P0缺陷数为0P1缺陷数不超过2个否则自动驳回方案并触发架构师Agent修订复核门禁系统自带规则引擎检查一些硬性指标——例如方案中是否出现与需求清单数量不一致的模块名是否遗漏了scope_constraints中的任意一条边界这类检查不做语义判断只做结构比对速度快、可解释性强弥补了大模型判断的不稳定性人工门禁对于P0/P1缺陷累计修复超过两轮、或者需求真实性校验中出现3条以上补充假设的方案直接进入人工审核队列不再自动迭代。这三道门禁下来系统自动产出质量基本稳定在了技术组评审只需修改小细节的水准。重要的是我没有任何一个环节全盘信任大模型的判断而是把判断转化成规则和行为策略用工程手段兜住模型的随机性。4.2 让Agent输出置信度给决策者一个低头的台阶这是一个很小的改动但收益极大。我在输出协议里给每个Agent增加了一个confidence_meta字段包含两个值confidence对本次输出的信心0-1和uncertain_items不确定的点list。别小看这两个字段的意义——它让Agent在不确定时有合规的表达渠道而不是硬着头皮自圆其说。产品经理Agent如果对某条需求的理解没有把握会把它放入uncertain_items架构师Agent在做技术选型时如果面临两难会直接写明此处存在替代方案见uncertain_items。这些不确定点会被汇总到最终报告的开头。这样做有两个直接收益下游Agent遇到这些内容会降低自信度更倾向于做防御性设计人工审核者有明确抓手优先看不确定的地方不用从头通读全文。4.3 中断恢复给协作链条留个人工插话口多智能体系统最可怕的不是答错而是卡住。协作链条一旦跑起来Agent之间的数据流是单向的如果中途出错全部重跑的成本非常高。我一开始没有考虑这个问题直到有一次LLM接口超时整个链路卡在中游前序Agent的结果全部作废。后来我加了检查点机制每一步Agent产出结果后立即存到本地state_dir下的一个JSON文件并记录state_id。重启恢复时指定state_id直接从那个步骤继续。这个机制平时用不上但一旦遇到接口波动或Agent输出格式异常就能少烧掉几千token。另外我给每个Agent的调用都加了超时重试和降级输出逻辑——如果某个Agent连续三次超时不等它直接用一条预设的本次跳过该Agent任务降级由下游Agent基于已有上下文续作的标记把链路往下推。自动跳过比全链路失败好得多。真实业务的韧性不是靠单次100%准确性而是靠整套系统在部分失效时仍能交出可用结果。5. 成本账与适用边界这套系统不是万金油5.1 跑一次协作系统的真实消耗我测过用GPT-4级别模型粗略估算跑完一次需求 → 方案 → 质检完整链路的token消耗数据大概是环节平均输入token平均输出token单次估算成本产品经理Agent120003500中架构师Agent180006000偏高质检Agent250001500偏高修订重试(平均0.3次)80002000低合计6300013000一次完整链路接近一美元量级这是个不能忽视的账。智能协作的叠加效应管用但那是字节和延迟换来的。如果要处理大量任务必须做分类路由简单任务走单Agent直通模式只有复杂任务才触发完整的三Agent协作链路。在入口加一个路由器Agent对输入做复杂度预判能省掉一大半成本。5.2 什么场景真的需要多智能体什么场景不需要我踩过的坑还包括为多而多。有一段时间什么东西都想塞给Agent小组去搞后来发现有些任务用单个Agent加充足的上下文就够了。任务特征适合单Agent适合多智能体输入短500字是否需要单一专业视角是否结果需要对照原始需求逐条验收需人工强烈推荐同一份材料需要构思评审双重处理否强烈推荐需要多个知识领域交叉综合视复杂度平均而言是核心判断标准只有一个是否存在角色冲突—即同一份工作内容里既有创造力需求又有批判性需求。有就拆成多智能体没有单Agent更省更稳。另外给个最小可行配置的个人建议三个Agent是体验协作乐趣的起点两个Agent也能跑生成评审四个以上Agent时编排复杂度和上下文重复传递成本会急剧上升慎用。我自己现在最舒服的组合是一个执行Agent负责干活一个评审Agent负责挑刺再加一个无论何时都开着的人工审核口。5.3 一个冷门但管用的优化为每个场景定制消息摘要多智能体链路中容易忽视的是消息长度管理。每次会话会把上游全量输出当成上下文越往后面本轮Agent要处理的无用信息就越多。我在中间加了一个摘要Agent——上游输出进来后先做一个给下游看的精简版只提炼与下游任务直接相关的信息再连同完整版原文一起打包发送并说明完整版供参考摘要版为处理依据。这就解决了长链路中的上下文过载也让后续思考有了更干净的起点。写在最后宁可慢一点也要让协议先行现在回看这套多智能体协作系统的演进过程我最想分享给同行的一句话一开始就把消息协议、角色约束和中断恢复想清楚比调Agent的Prompt重要十倍。Agent本身的提示词可以迭代但协议一旦定错了后面每一步决策失误的根源都在上游。如果你正在搭自己的多智能体系统我的建议是从一个小场景起步找一段真实的任务文本让两个Agent执行评审先跑起来然后把第三个、第四个角色逐步加进来。每加一个角色都要重新检查一遍边界是否重叠和消息是否精简。实际跑下来你会发现系统真正变可靠往往不是在增加模型智能而是在收窄每个Agent发挥的边界让它们在有限的自由度里做最擅长的事。这个收窄的过程正是多智能体协作系统最容易出效果、也最值得花时间的部分。