多智能体系统怎么搭 三种架构各自的坑

单个智能体的演示五分钟就能做得漂亮，给一个目标、几个工具、一段宽松的提示词，它转两圈就把活干完了。数量一多，问题就从会不会推理由变成怎么协调，而协调吃掉的时间比推理多得多。演示环境只需要成功一次，生产环境要连续跑半年，还得接住没人预想过的输入，这两件事根本不是一回事，把演示当结论的人通常撑不过头一个月，返工都发生在上线之后，演示里看不到的那部分才开始显形。

拆开写的理由和拆函数差不多。一个智能体同时管检索、推理、校验、排版，四件事都会做得马马虎虎，提示词越堆越长，行为越难预测，出了错也说不清是哪一段的锅。拆成各管一件事的几个智能体，每个提示词都短，职责边界清楚，单独评测也方便，改一个不影响其他三个。代价是多出一层协作，而协作本身要写代码、要监控、要兜底，写得好不好直接决定系统能不能上生产。

最常见的排布是调度加执行者。一个总调度接任务、拆子任务、分给专职执行者，再把结果汇总成答案，执行者之间不说话，只跟调度打交道。任务能提前列成清单的场景用它最省事，代价是总调度变成瓶颈，所有上下文都要从它那里过一遍，它拆错一步，下游全跟着错，而且错得很有信心，回头查还要一层层往回倒，日志里全是转手记录，看不出哪一步开始错，拆得越细倒查越慢。

还有一派排布是把中间状态摊在一块公共白板上，谁有发现谁往上写，由一个轻量调度决定下一步谁动手，没有谁独占整个计划。查生产环境里说不清的故障时用它合适，一个提假设，一个找证据，一个挑逻辑毛病，下一步做什么完全取决于已经翻出来的东西。代价是难测，一个坏结果要事后把整串读写复原，像查并发冲突，而不是查一次函数调用，同样的输入未必能复现同样的分歧。

流水线最简单，检索、抽取、校验、排版一路交下去，不派活也不共享草稿。流程稳定、能重复的场景默认用它，每一段的输入输出都有约定，可以单独测、单独换，出了问题也容易定位到具体一段。它的毛病是硬，遇到第三步要回头重做第一步，就得往上挂分支，挂到后面又长成半个调度，只是多了几层不好读的代码，改一处要顺着分支找半天，上线前还得给每条分支补测试，补不完就带病上线。

演示里看不到的坑有四类。两个智能体互相把活推回去，能无限转下去；每次转手都是一次模型调用，账单比错误先到；几个智能体同时改同一份共享状态会撞车；最阴的一类是错误顺着链条放大，五个各错百分之五的智能体不会互相抵消，只会把错倍起来。挡这些不能靠提示词写得更漂亮，要在代码里设硬上限，转手深度卡在 3 到 5 跳，每个任务给一个总预算，触顶就停，并且留一条真人接手的通道，让系统在没把握的时候认输。

创业找资源，上乌鸦部落。