顺序、并行、循环：多智能体编排到底在编排什么
最近在学一个多智能体框架，跑了它的三个示例：顺序、并行、循环。示例都很短，但把它们放在一起看，能看出框架的设计意图。记一下我理解的东西。
三个示例
顺序。 写代码 → 评审 → 重构。三个智能体依次跑，后一个用前一个的产出。
并行。 三个研究员各查一个方向，同时跑，最后一个汇总的智能体把三份结果合成一份报告。
循环。 评论员评论 → 修订者修改，反复；修订者觉得够好了就调一个”退出”工具跳出循环，另外设最大轮次兜底。
状态怎么流动
三个示例的共同点：智能体之间不直接传参，而是通过共享状态。 上游智能体把结果写到一个约定的键，下游智能体在提示词里引用这个键。
写代码智能体 ──写 generated_code──► 共享状态 ──读 {generated_code}──► 评审智能体这个设计的好处在循环里最明显：修订者每轮都写同一个键，评论员每轮读同一个键，谁也不用知道现在是第几轮。
智能体不该知道自己在哪
这是我觉得最重要的一条。三个示例里的智能体，提示词里只有”你是谁、你要做什么、输入在哪个键、输出写哪个键”，没有”你是流水线的第二步”。
好处：同一个评审智能体，可以放在顺序流水线里，也可以放在循环里，不用改。编排结构和智能体实现解耦，改编排不动智能体。
我之前自己写过一版编排，智能体的提示词里塞了流程信息（“你收到的是初稿，请评审后交给重构者”），结果换个流程就得改提示词。看了框架的示例才意识到问题在哪。
用工具控制流程
循环示例里，退出条件不是编排层判断的，是修订者智能体主动调一个 exitLoop 工具。把流程控制暴露成工具，让智能体自己决定。 这比在编排层写”如果输出包含’通过’就退出”要稳，因为智能体的自然语言输出不可靠，但工具调用是结构化的。
并行不一定并行
跑并行示例时看日志，三个研究员的调用是依次完成的，每次隔四五秒。可能是框架在这个组合下没真并发，也可能是模型客户端是同步的。没深究，但记下来：并行编排是语义上的并行（子任务互不依赖），不保证执行上的并发。 要真并发得另外确认。
一个跑出来的坑
循环示例第二轮报了 400。查下来是：智能体配置了”不带对话历史”，第二轮修订者调了工具没产出文本，评论员这一轮的请求里就只剩一条系统消息，没有用户消息。请求经过一个协议转换层时，系统消息被单独提走，用户消息为空，上游拒收。
这个坑和编排无关，但它说明编排方式会直接影响发出去的请求长什么样。用编排框架的时候得知道底下的请求是怎么拼的。这个问题后来在协议转换那一侧修了，单独写一篇。
小结
三种原语覆盖了我目前遇到的所有流程。真正要想清楚的不是选哪种原语，而是：状态键怎么命名、智能体职责怎么切到”不知道流程也能干活”的粒度、退出条件交给谁。这三个想清楚，编排就是配置。