devgo.cn假设你正在做一个 AI 邮件助手，它要读收件箱、给邮件分类、写回复、安排会议、跟踪订单。一开始你写了一个 ReAct 循环（让模型思考-行动-观察的循环，相当于给模型一个“想一步做一步”的框架），发现单智能体处理单一任务还行。但一旦任务拆成分类、摘要、起草、排程，一个智能体就忙不过来了，你需要一个团队。团队有了，新的麻烦来了：怎么给它们派活？怎么让它们协作不打架？怎么防止它们陷入无限重试的泥潭？
这篇文章用一个虚构的 AI 邮件助手 Mailmind 作为贯穿案例，把多智能体编排的几种核心模式讲得清清楚楚。最让我意外的是作者抛出的那个反常识结论：一个管理者智能体只是简单地对工人智能体说“再试一次”，就能在不到一秒内让整个流水线死锁。而且解决办法不是写更好的提示词，而是一个“停滞检测器”——它发现工人一直在给出同样的错误答案，就立刻叫停。
先看最简单的模式：顺序流水线。它让智能体按固定顺序执行，一个的输出是下一个的输入。就像餐厅后厨，菜要经过备料、烹饪、装盘、传菜检查，每个环节都依赖前一个环节。Mailmind 用它来处理重要邮件的回复：先由分流智能体读邮件线程并分配优先级（立即回复、稍后回复、不回复），如果是“立即回复”，结果流入起草智能体生成回复草稿，最后审查智能体检查语气、完整性和事实错误，不满意就打回给起草智能体并附上具体反馈。这种线性流程的好处是调试简单，坏消息出问题能精确追溯到三个智能体中的哪一个；代价是僵化，每次跑的都是同一套流程。
第二种模式解决的是互不依赖的任务：管理者-工人模式。管理者把独立的子任务并行分发给多个工人，收集结果、评估、决定接受、重试还是升级。Mailmind 的晨报功能是完美示范：管理者收到一批新邮件，同时派出三个工人——一个按紧急程度和类别分类，一个为过去 24 小时的每个线程生成两句话摘要，一个提取明确的行动项（谁需要回复、谁提到了截止日期、谁要文档）。三个工人完全独立，并行跑，用户等待的时间从三次串行调用缩短到“最慢的工人 + 管理者的汇总步骤”。风险在于管理者必须足够聪明，能合并或拒绝冲突的输出，一个只会拼接原文的笨管理者会生成一份没法读的晨报。
接下来是智能体之间怎么传状态。作者给了三种实用方案：直接传递（A 的输出就是 B 的输入，适合短流水线，但团队变大后每个新智能体都得知道前一个的完整 schema，耦合很脆）；共享内存存储（所有智能体读写一个以 thread_id 为键的中央存储，像黑板一样，缺点是任何智能体都可能污染共享状态，坏数据难恢复）；上下文对象（一个结构化记录，每个阶段往里加字段，Mailmind 的 ThreadContext 从原始邮件开始，分流智能体加优先级和意图，起草智能体追加草稿正文和置信度，审查智能体盖上 approved 或 rejection_reason，每阶段只读自己需要的字段、写新字段，不碰别人的，schema 显式可审计，比直接传递扩展性好，又避免了共享大杂烩的混乱）。
最后是编排里最大的坑：永不终止的循环。死锁发生在管理者拒绝工人输出、工人重试、产出同样的东西、又被拒绝，如此往复。作者给了三道防线：最大重试次数（N 次后管理者必须做决定：接受最佳输出、回退到更简单的智能体、或标记人工审查，Mailmind 默认上限是三次）；停滞检测（记录工人输出的哈希值，如果连续两次哈希相同，立刻停止重试循环，Mailmind 用在排程智能体上，当工人一直返回“没有可用时间”而不去检查其他日期时，这个机制能当场掐断）；还有第三种机制原文没写完，但前两个已经足够说明问题。
这套思路能直接用到你自己的场景：任何需要多个 LLM 调用协作完成复杂任务的地方，比如客服工单自动分类+回复、代码评审机器人、数据分析报告生成。要注意的坑是：顺序流水线别硬套到独立任务上，那会白白增加延迟；管理者-工人模式里管理者不能太笨，否则并行省下的时间全浪费在合并烂结果上；状态传递优先选上下文对象，别图省事用共享大 blob；重试逻辑一定要配停滞检测，否则“再试一次”就是死锁的快捷键。
内容与图片版权归原作者所有 · 原文: https://dev.to/internals_decoded/multi-agent-orchestration-managers-workers-and-pipelines-5227