技术 · 熟练
编排逻辑由它自己写，你要审的就变了
省下的不是代码，是把「审什么」换了个对象
过去搭多 agent，编排是你写的：谁先跑、谁等谁、失败回哪一步，全在代码或画布上，审它就是读那张图。Anthropic 新加的 multiagent_20261001 类型把这一步也让出去了 —— agent 可以自己写一段动态工作流程序，在后台并行调度多个 agent，还能在回合中途去问一个更强的 advisor。省事是真的，但可审性的落点换了：你不再读步骤，而是读它生成的程序与运行日志。这一页把三件事说清：三种协调机制各自的边界、它生成的编排要审哪几处、以及两条会先撞上的硬约束（嵌套最多一层、推理地理必须与主 agent 一致，不一致直接 400），最后给一条把它落成可回滚件的做法。
方法 · 一图看懂
1
三种机制先分清 — 子代理是常驻线程、动态工作流是跑完即归档的临时线程、advisor 是回合中途请教的更强模型
2
谁写编排要先声明 — 人写死（可预测）还是交给它生成（覆盖面大但要看程序），⛔ 不能两头都算
3
审它生成的三处 — 输入边界（谁能进工作流）、停止条件（什么算跑完）、失败回退（某支挂了怎么办）
4
两条硬约束会先撞上 — 嵌套不能超过一层、被调度 agent 的推理地理必须与主 agent 一致
5
落成可回滚的件 — 工作流定义进版本库、每次运行留日志，改一版能退回上一版
原理 · 为什么有效
把编排交出去，真正的变化不是「少写代码」，而是可审对象的替换。人写编排时，编排本身就是规格：图上有几个节点、边怎么连，一眼能数。交给 agent 生成时，规格变成了「它这次写出来的程序」—— 每一次运行的程序可能不同，你没法靠读一份静态文档确认行为。这时候能审的只剩三样：输入边界（哪些数据、哪些工具允许进这个工作流）、停止条件（什么情况算完成、什么情况必须停）、失败回退（某一支超时或报错，是重试、跳过还是整体失败）。这三样必须在提示与配置里写死，而不是指望它每次都想起来。另一头是平台侧的硬约束：嵌套最多一层，意味着你不能让它再生成一个会继续生成的东西；推理地理必须一致，意味着跨区调度会在校验阶段就 400 —— 这两条不是性能问题，是设计边界，早一天知道就少一次白跑。
适用场景
适合：已经在用托管 agent、想把「多文档评审、批量核查、并行检索」这类任务交出去的人；被自己写的编排图维护成本拖住的人；要评估「能不能让它自己排流程」的技术负责人。
不适合：还在单 agent 阶段的人（先把一个 agent 的停止条件写对，比引入动态编排收益大）；需要严格可复现审计的场景（同一任务每次生成的程序不同，复现要靠日志而不是靠定义）。
自测 · 5 问
我能说出子代理、动态工作流、advisor 三者的差别，而不只是「都是叫别的模型干活」
我知道本项目的编排是人写死还是由 agent 生成，并且写在了配置里
我能指出这套编排的输入边界、停止条件、失败回退分别写在哪一处
我知道我的调度链路嵌套了几层，以及会不会撞上一层的上限
我能拿出版本号与一次运行的日志，用来回滚或复盘
怎么上手 · 验证步骤
1. 先给现有编排标一个来源：人写死，还是 agent 生成。两种混用的，把边界写在配置注释里。
四步走完做一次空跑：给一个必然失败的分支，看它是否按你写的回退策略停下，而不是自己换个办法继续跑。