技术 · 深入
多 Agent 不是升级：先看这七个编排模式该不该用
先问「这一步该不该让模型自己决定」
多数 Agent 项目失败，不是模型不行，是把工作流问题当成了提示词问题：需要校验才发送、需要审批才发布，这类要求该落在运行时里，而不是写进 system prompt 指望模型自觉。这份做法把编排拆成七个可组合模式（串联 · 路由 · 并行 · 编排者-工人 · 生成-评估 · ReAct · 多 Agent），每个模式都配一条「什么时候别用」的反向条件 —— 因为用错的代价是确定的：子任务独立还串联 = 白付延迟；依赖链并行 = 把错答案更快地重排一遍。读完你能回答一个具体问题：我现在这步，该写死还是该放手。
方法 · 一图看懂
1
先分家 — Workflow = 路径由代码写死 · Agent = 模型自己决定下一步与工具用法 —— 这是性质区别，不是规模区别
2
从最简起点 — 默认从串联起步：一次调用喂给下一次，每一步的中间结果都能被检查
3
按输入分流 — 路由：先分类再交给专用提示 / 模型 / 流程 —— 换来的是每次请求只多几百个便宜 token
4
能拆就并行 — 子任务独立则可并行（拆分区段 or 同题多次投票再聚合）；单步依赖第 n 步输出的，别并行
5
中心派活 — 编排者-工人：中心模型动态拆任务、委派 worker、汇总 —— 前提是子任务事先未知
6
自评到达标 — 生成-评估：生成器与评估器循环，直到通过判据（把「什么算好」写成可判的）
7
放手要设闸 — 自由 agent = 工具循环 + 环境反馈，但必须写死停止条件与检查点
确定性路由：把「必须先校验」从提示词搬回运行时
凡「校验后才发送 / 人工审批后才发布 / 命中条件才升级」这类约束，都该由运行时执行，而不是写在 system prompt 里。理由很朴素：提示词是希望，运行时是保证。已有平台把这层显式拆开 —— 执行路由与开放式推理分两类步走。落地判据一句话：这条约束若被违反，代价是「发错了一条」还是「发慢了一点」？前者进运行时，后者可以留在提示词里。
多 Agent 的代价清单（先算，再上）
多 Agent 换来的是可维护性、可扩展性与并发能力；付出的是通信开销 · 一致性 · 调试难度 · token 成本四笔账。拆之前先写清三件事：① 每个 worker 的职责边界（谁的输出算数）；② 冲突裁决（两个 worker 结论相反听谁的）；③ 失败降级（某个 worker 挂了，主流程是等还是降级）。三件写不出来，就还不是多 Agent 的时机 —— 先按单 Agent + 显式编排做，把边界跑清楚。判断准则：任务责任边界清晰、且确实需要并发处理时才拆多 Agent；其余情况单 Agent 更好。
为什么最后常常落回 Workflow
「为什么很多 Agent 最终以 Workflow 形式实现，而非完全自由规划」是面试高频，也是工程常态。答案要按四维度答：可控性（写死的路径能被审计）· 延迟（少几轮模型决策）· 成本（token 与重试都降）· 幻觉风险（关键步骤不放给概率模型）。自由规划不是更高阶，它是面向未知子任务的一种选择；子任务一旦已知，写死就是更好的工程。
原理 · 为什么有效
这套顺序背后的机理是两条成本曲线：模型决策的次数越多，延迟与 token 成本按次累加，而不确定性也按次相乘 —— 每一步 95% 的可靠度，十步之后只剩约 60%。所以编排的默认方向是「能用代码写死的就不问模型」：分类用小模型做路由、校验用普通代码、审批走流程引擎。模型只留在真正需要判断的位置上。反过来，若把本该写死的步骤交给模型，你付出的不只是那一步的错误率，还有它把错误往下游传的代价 —— 下游每一步都在为上游的错误做功。这就是「先分家、从最简起点、逐级加复杂度」这条顺序的经济学理由。
适用场景
适用：① 手上已有一条能跑但开始「发散」的 agent 流程（步骤越来越多、结果不稳）；② 要决定一个新环节是写死还是交给模型；③ 需要给 multi-agent 方案做取舍评估。不适用：① 单步、一次调用就能出结果的任务 —— 直接串一个提示词更快；② 探索性研究（子任务确实事先未知）—— 此时该走自由 agent，但必须把停止条件写死；③ 想靠换编排解决「检索拿回的就不对」—— 那是检索层的问题，编排再漂亮也盖不住。
自测 · 5 问
我这一步的「成功」有可机器判的定义吗？（没有 ⇒ 先定义，再谈编排）
我这条路径里的每个分支，是代码判的还是模型判的？
有没有哪一步是「子任务彼此独立、我却把它们串起来跑」的？
我并行了几条线，合并那一步由谁说了算（冲突裁决写了吗）？
如果某个环节连续失败三次，我的停止条件是什么？
怎么上手 · 验证步骤
照三步上手：① 拿现在的流程画一张图，把每个节点标成「代码判」或「模型判」——凡是「模型判」但代价是发错一条的节点，先圈出来；② 把圈出来的节点按本页七模式各找一个最简替代，一次只换一个，换完跑同一批输入对比结果；③ 记录三件事：每条的耗时、每次运行的模型调用次数、失败时是「停在原地」还是「错着往下走」。
做完回看两条：① 同样的输入跑 5 次，结果的方差有没有变小（写死路径的价值就体现在这里）；② 挑一次失败，检查它是在错误的节点被拦住，还是跑完才被发现 —— 后者说明验证点放晚了。两条都过，才算真的把「该写死的写死」落到了流程上；只图快不查方差，等于把不确定性从看得见的地方挪到了看不见的地方。