deep-research-gatelisted

# 扇出安全门（deep-research-gate） > **任何「要不要扇出一批子 agent / 要不要开深度研究·工作流」的时刻，先读这里、按这里走。** > > 它管两件事，别搞混：① 该并行的有界任务**放行别缩**；② 会失控放大的深度研究/工作流**焊死，要开得经用户同意**。 --- ## 〇、先分清两类扇出（决策从这里开始） 危险的**从来不是「子 agent 多」**，是「扇出会不会失控放大」。先对号入座： | | 🟢 绿灯·有界并行 | 🔴 红灯·无界/递归/工作流 | |---|---|---| | 数量 | 已枚举、算得出上界（N 个明确子任务） | 不可预知，子 agent 自己决定要不要再扩 | | 成本 | O(N) 封顶，事前算得出 | 失控放大，事前算不出上界 | | 任务性质 | 执行**已交代清楚**的事（模拟 / 只读核验 / 已定的批处理） | **开放式调查**：自己去查清某课题、查多深由它定 | | 递归 | 不递归，子 agent 是叶子 | 子 agent 内部还会再派 / 触发 deep-research / 跑 workflow | | 怎么办 | **直接并行，不必问、不必缩——串行才是错** | 走 §三 开闸流程 + **经用户同意** | **判据三问，任一为「是」→ 红灯：** 1. **数量算不出上界？**（子 agent 自己决定要不要再派、要查多深） 2. **会递归？**（子 agent 内部还会再派 agent / 触发 deep-research / 跑 workflow） 3. **是开放式调查？**（任务是「自己去查清楚某课题」，而非「执行已交代的一件事」） > **绿灯典型**：「M 个配置 × N 个场景 = 一批模拟」这类——并行单元天然可枚举，靶子与流程全部冻结、零调查、不递归。**正确做法是一次全部并行，硬拆成串行是纯浪费。** > **红灯典型**：某个子 agent 为核实一个数据点，自行触发了深度研究，在内部再扇出一整层子 agent。 --- ## 一、为什么需要这道门（失控是怎么发生的） 单个子 agent 之所以能把整个账号配额打穿，靠的是两层机制叠加，缺一不可： 1. **子 agent 默认拿到全权限。** 派研究/检索类子 agent 时若不显式指定类型，它默认是通用 agent——手里有完整工具集，**能递归再派 agent、能自己触发深度研究 / 工作流**。主线程以为自己只派了几个助手，实际上每个助手都能再开一整层。 2. **工作流引擎负责放大。** 深度研究与大规模递归 fan-out 都由动态工作流引擎驱动。一次触发就可能在内部展开成整层子 agent 与大量工具调用，token 消耗与主线程的预期完全脱钩。 再叠加第三个条件，就会从「贵」变成「静默地贵」： 3. **若权限模式配置为跳过确认弹窗**，上述触发全程无人拦截——没有弹窗、没有询问，等发现时配额已经见底。 **后果形态**：一次本该廉价的核查，可以在很短时间内把剩余配额打满并锁死账号，**连带打断的是之后所有本可以正常进行的工作**。无人值守时段触发尤其致命，因为没人来得及叫停。 > **根因落点要认准**：炸配额的是**子 agent 权力过大（能递归、能自开深度调查）+ 工作流引擎放大**，**不是「主线程派了一批子 agent」这个动作本身**。主线程并行派一批**有界**子 agent 从来不是问题——别从这类事件里学