deep-research-gate

扇出安全门（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 消耗与主线程的预期完全脱钩。

再叠加第三个条件，就会从「贵」变成「静默地贵」：

1. 若权限模式配置为跳过确认弹窗，上述触发全程无人拦截——没有弹窗、没有询问，等发现时配额已经见底。

后果形态：一次本该廉价的核查，可以在很短时间内把剩余配额打满并锁死账号，连带打断的是之后所有本可以正常进行的工作。无人值守时段触发尤其致命，因为没人来得及叫停。

根因落点要认准：炸配额的是子 agent 权力过大（能递归、能自开深度调查）+ 工作流引擎放大，不是「主线程派了一批子 agent」这个动作本身。主线程并行派一批有界子 agent 从来不是问题——别从这类事件里学错教训、连累正常并行。

---

二、硬防护（只焊 workflow 引擎，不碰普通并行）

在 ~/.claude/settings.json 配置：

"disableWorkflows": true,
"workflowKeywordTriggerEnabled": false

• disableWorkflows: true —— 引擎级关掉「动态工作流」（深度研究和大规模递归 fan-out 全靠它）。这是开关、不是弹窗：所以「跳过确认」类权限模式吞不掉它、子 agent 也绕不过。触发时当场被拒、零 token 消耗。
• workflowKeywordTriggerEnabled: false —— 关掉「关键词自动触发工作流」（默认是开的，prompt 里带上特定关键词就会升级成工作流，是隐患入口）。

作用域必须说清（否则会误伤并行）：这两个开关焊死的是动态工作流引擎——即深度研究 / 大规模递归 fan-out 的总闸。它管不到、也不该管主线程普通的 Agent 并行调用：🟢 绿灯那种宽度并行根本不经过工作流引擎，这开关对它零影响。所以「开关开着」绝不是「不准并行派 agent」的理由。