背景
当前 OpenPI Workflow 技术上并不缺少大规模 fan-out：
默认并发为 8；
默认每次 Workflow 最多 128 个 Agent 调用；
硬上限为 64 并发、1024 个调用；
pipeline() 和 parallel() 已支持由数组动态生成调用。
但真实使用中，模型经常只创建约 3 个 Agent，即使面对完整仓库审计、几十个模块或大量可独立验证单元。
这不是 Runtime 容量不足，更像是模型被当前工具描述与示例锚定在“小规模角色拆分”。
当前锚点
基于当前 main@22e77d6：
skills/workflows/SKILL.md Quick Start 是 2 个扫描 Agent；常见模式是“少量 explorer + 1 个汇总”；
虽然 EXAMPLES.md 展示了按 files.map(...) 动态 fan-out，但缺少完整的“先发现工作单元，再按证据动态扩展规模”的示例；
Child 不能递归创建更多 Agent/Workflow，因此父 Workflow 如果只拆成 3 项，运行图就会稳定停在 3 个左右；
当前 Workflow 默认前台阻塞，这也会让模型对扩大调用量更加保守，相关默认生命周期调整见 Workflow 默认应释放父 turn：与 Subagent 的后台生命周期合同对齐 #74
设计目标
OpenPI 不规定“正确的 Agent 数量”。
模型应根据以下信息自由决定规模：
用户目标；
可独立工作的真实任务单元；
依赖关系；
所需证据覆盖；
用户自然语言表达的时间、成本或数量约束；
当前运行反馈。
Runtime 只负责可执行的安全事实：
并发调度；
权限与隔离；
绝对防失控上限；
生命周期、取消和清理；
运行状态与失败证据。
建议方向
1. 增加 discovery → dynamic fan-out 范式
在 Workflow Skill 中补充一个完整示例：
发现阶段
→ 得到结构化的独立工作单元
→ 去重并校验工作单元
→ 根据工作单元动态生成 Agent 调用
→ 在并发上限内排队执行
→ 对高风险结果做验证
→ 综合报告
例如审计 22 个 extension 时，可以自然形成：
1 个 inventory 调用
→ 22 个模块审计调用，最多同时运行 8 个
→ 若干交叉验证调用
→ 1 个综合调用
这里 22 是任务结构产生的结果，不是 OpenPI 规定的目标。
2. 区分总工作量与并发量
模型可以创建几十个待执行调用，但 Runtime 只同时运行配置允许的数量。
不要因为并发默认是 8，就让模型把总任务也压缩成 8 个甚至 3 个大包。
3. 让自然语言约束直接影响模型判断
示例应覆盖：
“快速看一下” → 少量、宽粒度检查；
“全面审计” → 按模块或证据单元扩大覆盖；
“最多使用 5 个 Agent” → 模型主动控制总量；
“控制成本” → 合并低价值任务、减少交叉验证；
“成本不限，尽可能全面” → 扩大 fan-out 和复核。
这些由模型理解，不新增关键词解析器或 Runtime 路由规则。
4. 提供高保真容量反馈
可以让 Workflow 中的模型清楚知道：
当前已创建调用数；
running / queued / settled / failed；
配置的并发上限；
绝对调用上限及剩余容量；
累计 token/cost（如 Provider 提供）。
这些是事实反馈，不是 Runtime 替模型决定预算。
5. 用 Benchmark 验证，而不是以 Agent 数量验收
至少比较：
当前自由策略；
改进 Skill 后的自由策略；
固定 3 Agent 诊断臂；
必要时加入 8/16 Agent 参考臂。
观察：
任务覆盖率；
verifier/pass 结果；
遗漏问题数量；
重复发现；
token、成本和 wall time；
汇总质量；
不同规模仓库下是否会自然改变 fan-out。
目标不是“Agent 越多越好”，而是规模能够随任务结构变化。
明确不做
不规定最少 Agent 数；
不规定“复杂任务必须 20 个 Agent”；
不做关键词到数量的硬编码映射；
不引入自动 token 预算分配器；
不因用户没有主动表达成本限制，就默认把任务压缩到少量 Agent；
不允许 Child 递归扩张 Agent 树；
不取消现有并发、总调用量和权限硬上限；
不让 Runtime 接管模型的任务拆分判断。
与其他 Issue 的关系
推荐顺序是先保证 #71 的可靠性，再完成 #74 的生命周期调整，同时改进本 Issue 的 Skill/示例与诊断反馈。
验收标准
背景
当前 OpenPI Workflow 技术上并不缺少大规模 fan-out：
pipeline()和parallel()已支持由数组动态生成调用。但真实使用中，模型经常只创建约 3 个 Agent，即使面对完整仓库审计、几十个模块或大量可独立验证单元。
这不是 Runtime 容量不足，更像是模型被当前工具描述与示例锚定在“小规模角色拆分”。
当前锚点
基于当前
main@22e77d6：skills/workflows/SKILL.mdQuick Start 是 2 个扫描 Agent；EXAMPLES.md展示了按files.map(...)动态 fan-out，但缺少完整的“先发现工作单元，再按证据动态扩展规模”的示例；设计目标
OpenPI 不规定“正确的 Agent 数量”。
模型应根据以下信息自由决定规模：
Runtime 只负责可执行的安全事实：
建议方向
1. 增加 discovery → dynamic fan-out 范式
在 Workflow Skill 中补充一个完整示例：
例如审计 22 个 extension 时，可以自然形成：
这里 22 是任务结构产生的结果，不是 OpenPI 规定的目标。
2. 区分总工作量与并发量
模型可以创建几十个待执行调用，但 Runtime 只同时运行配置允许的数量。
不要因为并发默认是 8，就让模型把总任务也压缩成 8 个甚至 3 个大包。
3. 让自然语言约束直接影响模型判断
示例应覆盖：
这些由模型理解，不新增关键词解析器或 Runtime 路由规则。
4. 提供高保真容量反馈
可以让 Workflow 中的模型清楚知道：
这些是事实反馈，不是 Runtime 替模型决定预算。
5. 用 Benchmark 验证，而不是以 Agent 数量验收
至少比较：
观察：
目标不是“Agent 越多越好”，而是规模能够随任务结构变化。
明确不做
与其他 Issue 的关系
推荐顺序是先保证 #71 的可靠性，再完成 #74 的生命周期调整，同时改进本 Issue 的 Skill/示例与诊断反馈。
验收标准