用途：处理代码库级、多文档、PDF 与聚合类密集任务，即使输入能塞进上下文窗口也适用。核心思路是不把全部输入载入窗口，而是把它当作可查询的环境：先度量规模，再收窄、切分，把独立部分交给子代理，最后在小窗口上校验并用代码综合。依据 Recursive Language Models（Zhang、Kraska、Khattab，2025）。
主要能力：按文件数、行数、字节数、PDF 页数度量输入；用内容搜索、文件模式、关键词、文件类型链式过滤；按函数、类、章节、行范围或关键词分块，每批 5 至 10 个文件；深度 1 递归，每批一个子代理，给出自包含简报（文件、问题、输出模式），先写批次数量，跑一波并行，合并后再决定下一波；在小窗口上抽取最小证据复核；用程序化方式聚合、去重、分类，并附文件与行号引用。
使用方式：/recursive-decomposition 对当前任务应用该协议；/recursive-decomposition <路径或问题> 先度量该输入再运行协议。工具与代理无关，可按所用代理（Claude Code、Codex、Cursor、Gemini CLI）映射等价工具。PDF 或 Office 文件先转 markdown，例如 npx -y @firecrawl/anydoc FILE -o .firecrawl/FILE.md，需要 OCR 时用云端 firecrawl parse。
适用场景：代码库错误处理模式分析、跨 PRD 的功能提取、TODO 聚合、大型 PDF 处理、长输出分段生成。
限制：分解会消耗协调 token，平均成本可能因异常轨迹上升；单文件、单函数或单点查找应直接读取；子代理不得再派生子代理；不得把 PDF 二进制直接载入上下文；云端 parse 上限 50 MB、约每页 1 信用点。论文数据：BrowseComp-Plus 上 RLM(GPT-5, depth=1) 得 91.3%，平均 $0.99；OOLONG-Pairs 达 58.0% F1，基线 0.1%。