recursive-decomposition

递归分解

长输入会逐渐失真。细节容易遗漏，彼此相距较远的部分会被猜测强行拼在一起，推理也会偏离方向。RLM 论文将其称为上下文腐化。不要把整个输入都载入上下文窗口。把它视为一个可查询的环境：先测量规模，再缩小范围、拆分内容，把彼此独立的部分交给子 Agent，在较小的窗口中验证，并用代码综合结果。基于 Recursive Language Models（Zhang、Kraska、Khattab，2025）。

使用方法

• /recursive-decomposition：将以下流程应用于当前任务。
• /recursive-decomposition <path or question>：先测量该输入的规模，再按流程处理。

适用场景

是否放得下不是判断标准。即使有百万 token 的窗口，密集型工作也会逐渐失真。论文中，OOLONG-Pairs 有 32k token，GPT-5 的 F1 得分为 0.1%；RLM(depth=1) 达到 58.0%（arXiv:2512.24601，表 1）。下方的 30k 和 50k 是框架上限。

情况	方法
单个文件、单个函数或一个明确目标	直接阅读
线性汇总或列出所有内容，且完整性很重要	分解（使用此技能）
散布在多个来源中的成对比较、二次复杂度任务或多跳任务	分解，即使少于 30k token
10 个以上文件或 50k 以上 token	分解
少于 30k token，且答案范围明确	直接阅读

流程

1. 先测量输入规模，再阅读任何内容：统计文件数（glob、find）、行数（wc -l）、字节数（ls -lh）以及 PDF 页数。
2. 先筛选搜索范围，再打开任何文件：使用内容搜索、文件模式、关键词和文件类型。逐层筛选：先按文件类型，再按关键词，最后按含义。
3. 分块处理剩余内容：按自然单元（函数、类、章节）、行范围或关键词分区。每批处理 5 到 10 个文件。
4. 在深度 1 递归：每个相互独立的批次分配一个子 Agent，并提供自包含的简要说明（文件、问题、输出格式）；并行运行一轮。先写明批次数。如果还有剩余批次，在合并结果后再运行下一轮。子 Agent 负责回答；不得创建自己的子 Agent。
5. 验证综合后的答案：在较小的窗口中提取最少量的证据并重新检查；通过针对性重读解决分歧。
6. 以程序方式综合：汇总结构化结果、去重、分类，然后附上文件和行号引用来撰写答案。

规则

• 必须在阅读输入前测量其规模
• 必须先搜索再阅读目录；绝不能以递归列出目录树代替搜索
• 必须按行范围读取大型文件：超过 2,000 行或 50 KB 的文件，绝不能一次性读取；PDF 超过 100 页或 30 MB 时，必须通过元数据检查或拆分处理
• 必须先将 PDF 和 Office 文件转换为 markdown，再进行推理。优先使用 Firecrawl convert-documents-to-markdown 技能中的本地 anydoc（npx -y @firecrawl/anydoc FILE -o .firecrawl/FILE.md）。OCR 使用云端 firecrawl parse（--ocr hosted / firecrawl parse）、-Q 或 -S。绝不要将二进制内容直接载入上下文。云端解析上限为 50 MB，每页 PDF 约消耗 1 个积分；如果文件更大，先拆分。
• 未写明批次计划前，绝不要将超过 5 个文件载入主上下文
• 必须为每个子 Agent 提供独立上下文：文件、问题和输出格式
• 必须将递归深度保持在 1：子 Agent 负责回答；绝不能启动子 Agent
• 必须在启动前写明批次数；先并行运行一轮，再合并；只有合并后才能运行后续批次
• 回答前必须对照来源抽查综合结果
• 应先阅读定义（grep -n "function"），再阅读函数体；先阅读目录和摘要，再阅读全文
• 绝不要在多个子 Agent 中对相同内容运行相同查询；只进行一次划分，确保批次互不重叠
• 绝不要因为合并结果显得单薄就提高递归深度；应重新阅读有分歧的部分

与 Agent 无关的工具

需求	使用
查找文件	文件搜索或 glob 工具，或 find
查找内容	内容搜索或 grep 工具，切勿完整读取
获取大小	wc -l、ls -lh、页数（如果有 pdfinfo）
读取	带偏移量和限制的文件读取器，或 sed -n 'START,ENDp'
PDF 或 Office 文件	先用 anydoc（npx -y @firecrawl/anydoc FILE -o .firecrawl/out.md），然后 grep Markdown。需要 OCR、-Q 或 -S 时使用 Cloud firecrawl parse。否则使用 pdfinfo 并拆分文件。切勿完整读取二进制文件
委派	子 Agent 或任务工具，每批提供一份简报
汇总	使用临时文件或结构化笔记，然后进行一次最终检查

不同 Agent 使用的工具名称各不相同（Claude Code、Codex、Cursor、Gemini CLI）；请将表格中的工具映射为你的 Agent 所对应的工具。

模式

代码库分析

“查找所有错误处理模式。”对源文件进行 glob，用 grep 搜索 catch|throw|Error|except，按模块将匹配项分批（每批 5 到 10 个文件），每批分配一个子 Agent，并使用固定的报告格式；然后合并为带有文件引用的分类摘要。示例：references/codebase-analysis.md。

多文档问答

“所有 PRD 中计划了哪些功能？”对文档进行 glob，获取文档大小，定义提取格式（名称、优先级、状态、季度），为每组文档分配一个子 Agent，去重并分类，再从源文档中抽查 3 条。示例：references/document-aggregation.md。

汇总

“汇总所有 TODO 注释。”用 grep 搜索 TODO|FIXME|HACK，按模块分组，提取每组的上下文和优先级，并生成按优先级排序的列表。

大型 PDF

对 *.pdf 进行 glob，获取文件大小（字节）和页数（pdfinfo）。超过 100 页或 30 MB 时：不要摄取。使用 anydoc 转换到 .firecrawl/（Firecrawl 技能 convert-documents-to-markdown），然后对 Markdown 进行 grep 和分块。如果 anydoc 以 3 退出（扫描页面），使用 --ocr hosted 或 firecrawl parse 重新运行（Firecrawl 技能 firecrawl-parse，50 MB / 每页约 1 个 credit）。按文档分批，深度设为 1，并根据 PDF 元数据抽查标题。

单页的 Markdown 转换任务不属于此技能。将其单独交给 anydoc 或 firecrawl parse。

长输出

将输出拆分为多个部分，分别生成每一部分，将中间结果存入文件，再通过一次连贯性检查将它们合并。

成本与质量

在论文中（arXiv:2512.24601，表 1 和图 1），RLM（GPT-5，深度 = 1）在 BrowseComp-Plus 上得分为 91.3%（使用 6 到 11M 个 token），平均成本为 $0.99；相比之下，压缩方案得分为 70.5%。在 OOLONG 上，它比 GPT-5 高出 28.4%。在 OOLONG-Pairs 上，其 F1 达到 58.0%，而基准值为 0.1%。图 1 将输入规模从 2^13 个 token 扩展到 2^20 个 token。中位成本与基础模型相近；在异常轨迹中，平均成本可能会上升。阈值：references/cost-analysis.md。

反模式

反模式	修正方法
为了“了解上下文”而先读取所有内容	先获取大小并筛选，然后按范围读取
将 PDF 二进制内容直接倾倒到窗口中	转换为 Markdown，然后进行 grep 和分块
将一个简单查找或单文件查找拆解处理	直接读取
未提供问题或格式要求就调用子 Agent	提供自包含的简报
让子 Agent 再生成子 Agent	深度设为 1：子 Agent 负责回答，不负责委派
直接信任合并后的答案	在小范围内抽查
在多个子 Agent 中重复查询相同内容	只划分一次，分批内容互不重叠

参考资料

• references/rlm-strategies.md：论文中的分解策略
• references/cost-analysis.md：何时进行分解、盈亏平衡阈值
• references/codebase-analysis.md：工作示例，跨代码库的错误处理
• references/document-aggregation.md：工作示例，跨 PRD 的特性提取
• 论文：递归语言模型，Zhang、Kraska、Khattab，arXiv:2512.24601