Back to Details

recursive-decomposition

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Recursive Decomposition Guidelines

递归分解指南

References

参考资料

Consult these resources as needed:
  • ./references/rlm-strategies.md -- Detailed decomposition patterns from the RLM paper
  • ./references/cost-analysis.md -- When to apply recursive vs. direct approaches
  • ./references/codebase-analysis.md -- Full walkthrough of codebase-wide analysis
  • ./references/document-aggregation.md -- Multi-document information extraction
按需查阅以下资源：
  • ./references/rlm-strategies.md -- 来自RLM论文的详细分解模式
  • ./references/cost-analysis.md -- 何时应用递归方法vs直接方法
  • ./references/codebase-analysis.md -- 全代码库分析完整流程
  • ./references/document-aggregation.md -- 多文档信息提取

Core Principles

核心原则

CRITICAL: Treat inputs as environmental variables, not immediate context.
Most tasks fail when context is overloaded. Instead of loading entire contexts into the processing window, treat inputs as environmental variables accessible through code execution. Decompose problems recursively, process segments independently, and aggregate results programmatically.
Progressive Disclosure: Load information only when necessary. Start high-level to map the territory, then dive deep into specific areas.
关键提示：将输入视为环境变量，而非即时上下文。
大多数任务因上下文过载而失败。不要将整个上下文加载到处理窗口中，而是将输入视为可通过代码执行访问的环境变量。递归分解问题，独立处理各个片段，然后程序化汇总结果。
渐进式披露：仅在必要时加载信息。先从高层级入手梳理整体情况，再深入特定领域。

When Recursive Decomposition is Required

何时需要递归分解

  • Tasks involving 10+ files
  • Input exceeding ~50k tokens where single-prompt context is insufficient
  • Multi-hop questions requiring evidence from multiple scattered sources
  • Codebase-wide pattern analysis or migration planning
  • 涉及10个以上文件的任务
  • 输入超过约5万tokens，单提示上下文不足以处理的情况
  • 需要从多个分散来源获取证据的多跳问题
  • 全代码库模式分析或迁移规划

When Direct Processing Works

何时直接处理即可

  • Small contexts (<30k tokens)
  • Single file analysis
  • Linear complexity tasks with manageable inputs
  • 小型上下文（<3万tokens）
  • 单个文件分析
  • 输入可控的线性复杂度任务

Operational Rules

操作规则

  • Always identify the search space size first.
  • Always use 
    grep
    or 
    glob
    before 
    view_file
    on directories.
  • Always partition lists > 10 items into batches.
  • Never read more than 5 files into context without a specific plan.
  • Verify synthesized answers by spot-checking source material.
  • Mitigate "context rot" by verifying answers on smaller windows.
  • Treat yourself as an autonomous agent, not just a passive responder.
  • 始终先确定搜索空间的大小。
  • 在目录上使用
    view_file
    之前，务必先使用
    grep
    或
    glob
    。
  • 始终将超过10个项目的列表拆分为批次。
  • 若无具体计划，切勿将超过5个文件读入上下文。
  • 通过抽查源材料验证合成的答案。
  • 通过在较小窗口中验证答案来缓解“上下文衰减”问题。
  • 将自己视为自主Agent，而非被动响应者。

Large File Handling Protocols

大型文件处理协议

CRITICAL: Do NOT read large files directly into context.
  1. Check Size First: Always run 
    wc -l
    (lines) or 
    ls -lh
    (size) before 
    view_file
    .
  2. Hard Limits:
    • Text/Code: > 2,000 lines or > 50KB -> MUST use 
      view_file
      with 
      start_line
      /
      end_line
      or 
      head
      /
      tail
      .
    • PDFs: > 30MB or > 100 pages -> MUST be split or processed by metadata only.
  3. Strategy:
    • For code: Read definitions first (
      grep -n "function" ...
      ) then read specific bodies.
    • For text: Read Table of Contents or Abstract first.
关键提示：切勿直接将大型文件读入上下文。
  1. 先检查大小：在执行
    view_file
    之前，务必先运行
    wc -l
    （查看行数）或
    ls -lh
    （查看大小）。
  2. 硬限制：
    • 文本/代码：>2000行或>50KB -> 必须使用带
      start_line
      /
      end_line
      参数的
      view_file
      或
      head
      /
      tail
      命令。
    • PDF文件：>30MB或>100页 -> 必须拆分或仅通过元数据处理。
  3. 策略：
    • 代码文件：先读取定义（
      grep -n "function" ...
      ），再读取具体函数体。
    • 文本文件：先读取目录或摘要。

Tool Preferences

工具偏好

  • grep
    / 
    glob
    not 
    ls -R
    (unless mapping structure).
  • view_file
    with line ranges (offset/limit) not full file reads for huge files.
  • wc -l
    / 
    ls -lh
    before reading unknown files.
  • run_command
    (grep) not 
    read_file
    for searching.
  • task
    tool for sub-agents (recurse).
  • 使用
    grep
    / 
    glob
    而非
    ls -R
    （除非是映射结构）。
  • 处理超大文件时，使用带行范围（偏移量/限制）的
    view_file
    而非读取整个文件。
  • 读取未知文件前先使用
    wc -l
    / 
    ls -lh
    。
  • 搜索时使用
    run_command
    （grep）而非
    read_file
    。
  • 使用
    task
    工具调用子Agent（递归）。

Empowering Agentic Behavior

增强Agent能力

To maximize effectiveness:
  • Self-Correction: Always verify your own work. If a result seems empty or wrong, debug the approach (e.g., check grep arguments) before giving up.
  • Aggressive Context Management: Regularly clear irrelevant history. Don't let the context window rot with dead ends.
  • Plan First: For any task > 3 steps, write a mini-plan.
  • Safe YOLO Mode: When appropriate (e.g., read-only searches), proceed with confidence without asking for permission on every single step, but stop for critical actions.
为最大化效能：
  • 自我修正：始终验证自己的工作。如果结果看起来为空或错误，先调试方法（例如检查grep参数）再放弃。
  • 主动上下文管理：定期清除无关历史。不要让上下文窗口因无效信息而衰减。
  • 先规划：对于任何超过3步的任务，编写一个小型计划。
  • 安全YOLO模式：在合适的情况下（例如只读搜索），无需每一步都请求许可即可自信地执行，但在关键操作时需停止。

Cost-Performance Tradeoffs

成本-性能权衡

  • Smaller contexts: Direct processing may be more efficient.
  • Larger contexts: Recursive decomposition becomes necessary.
  • Threshold: Consider decomposition when inputs exceed ~30k tokens or span 10+ files.
Balance thoroughness against computational cost. For time-sensitive tasks, apply aggressive filtering. For comprehensive analysis, prefer exhaustive decomposition.
  • 较小上下文：直接处理可能更高效。
  • 较大上下文：递归分解成为必要。
  • 阈值：当输入超过约3万tokens或涉及10个以上文件时，考虑使用分解方法。
在全面性与计算成本之间取得平衡。对于时间敏感型任务，采用激进的过滤方式。对于综合性分析，优先选择彻底的分解。

Anti-Patterns to Avoid

需避免的反模式

  • Excessive sub-calling: Avoid redundant queries over the same content.
  • Premature decomposition: Simple tasks don't need recursive strategies.
  • Lost context: Ensure sub-agents have sufficient context for their sub-tasks.
  • Unverified synthesis: Always spot-check aggregated results.
  • 过度子调用：避免对相同内容进行重复查询。
  • 过早分解：简单任务无需递归策略。
  • 上下文丢失：确保子Agent拥有足够的上下文来完成其子任务。
  • 未验证的合成结果：始终抽查汇总后的结果。

Scalability (Chunking & filtering)

可扩展性（分块与过滤）

1. Filter Before Deep Analysis

1. 深度分析前先过滤

Narrow the search space before detailed processing:
undefined
在详细处理前缩小搜索范围：
undefined

Instead of reading all files into context:

不要将所有文件读入上下文：

  1. Use Grep/Glob to identify candidate files by pattern
  2. Filter candidates using domain-specific keywords
  3. Only deeply analyze the filtered subset

Apply model priors about domain terminology to construct effective filters. For code tasks, filter by function names, imports, or error patterns before full file analysis.
  1. 使用Grep/Glob按模式识别候选文件
  2. 使用领域特定关键词过滤候选文件
  3. 仅对过滤后的子集进行深度分析

应用关于领域术语的模型先验知识来构建有效的过滤器。对于代码任务，在全面分析文件前，先按函数名、导入项或错误模式过滤。

2. Strategic Chunking

2. 策略性分块

Partition inputs for parallel or sequential sub-processing:
  • Uniform chunking: Split by line count, character count, or natural boundaries (paragraphs, functions, files).
  • Semantic chunking: Partition by logical units (classes, sections, topics).
  • Keyword-based partitioning: Group by shared characteristics.
Process each chunk independently, then synthesize results.
将输入分区以进行并行或顺序子处理：
  • 均匀分块：按行数、字符数或自然边界（段落、函数、文件）拆分。
  • 语义分块：按逻辑单元（类、章节、主题）分区。
  • 基于关键词的分区：按共同特征分组。
独立处理每个块，然后合成结果。

3. Incremental Output Construction

3. 增量输出构建

For generating long outputs:
1. Break output into logical sections
2. Generate each section independently
3. Store intermediate results (in memory or files)
4. Stitch sections together with coherence checks
对于生成长输出：
1. 将输出拆分为逻辑章节
2. 独立生成每个章节
3. 存储中间结果（内存或文件中）
4. 通过一致性检查将章节拼接在一起

Agent Behavior

Agent行为

Recursive Sub-Queries

递归子查询

Invoke sub-agents (via Task tool) for independent segments:
For large analysis:
1. Partition the problem into independent sub-problems
2. Launch parallel agents for each partition
3. Collect and synthesize sub-agent results
4. Verify synthesized answer if needed
为独立片段调用子Agent（通过Task工具）：
对于大型分析：
1. 将问题分解为独立的子问题
2. 为每个分区启动并行Agent
3. 收集并合成子Agent的结果
4. 如有需要，验证合成后的答案

Answer Verification

答案验证

Mitigate context degradation by verifying answers on smaller windows:
1. Generate candidate answer from full analysis
2. Extract minimal evidence needed for verification
3. Re-verify answer against focused evidence subset
4. Resolve discrepancies through targeted re-analysis
通过在较小窗口中验证答案来缓解上下文退化：
1. 从全面分析中生成候选答案
2. 提取验证所需的最小证据
3. 针对聚焦的证据子集重新验证答案
4. 通过针对性的重新分析解决差异

Implementation Patterns

实现模式

Pattern A: Codebase Analysis

模式A：代码库分析

Task: "Find all error handling patterns in the codebase"
Approach:
  1. Glob for relevant file types (
    *.ts
    , 
    *.py
    , etc.)
  2. Grep for error-related keywords (
    catch
    , 
    except
    , 
    Error
    , 
    throw
    )
  3. Partition matching files into batches of 5-10
  4. Launch parallel Explore agents per batch
  5. Aggregate findings into categorized summary
任务：“查找代码库中所有错误处理模式”
方法：
  1. 使用Glob匹配相关文件类型（
    *.ts
    , 
    *.py
    等）
  2. 使用Grep查找与错误相关的关键词（
    catch
    , 
    except
    , 
    Error
    , 
    throw
    ）
  3. 将匹配的文件划分为5-10个文件的批次
  4. 为每个批次启动并行探索Agent
  5. 将发现结果汇总为分类摘要

Pattern B: Multi-Document QA

模式B：多文档问答

Task: "What features are mentioned across all PRD documents?"
Approach:
  1. Glob for document files (
    *.md
    , 
    *.txt
    in 
    /docs
    )
  2. For each document: extract feature mentions via sub-agent
  3. Aggregate extracted features
  4. Deduplicate and categorize
  5. Verify completeness by spot-checking
任务：“所有PRD文档中提到了哪些功能？”
方法：
  1. 使用Glob匹配文档文件（
    /docs
    目录下的
    *.md
    , 
    *.txt
    ）
  2. 对每个文档：通过子Agent提取功能提及内容
  3. 汇总提取的功能
  4. 去重并分类
  5. 通过抽查验证完整性

Pattern C: Information Aggregation

模式C：信息汇总

Task: "Summarize all TODO comments in the project"
Approach:
  1. Grep for 
    TODO
    /
    FIXME
    /
    HACK
    patterns
  2. Group by file or module
  3. Process each group to extract context and priority
  4. Synthesize into prioritized action list
任务：“汇总项目中所有TODO注释”
方法：
  1. 使用Grep查找
    TODO
    /
    FIXME
    /
    HACK
    模式
  2. 按文件或模块分组
  3. 处理每个组以提取上下文和优先级
  4. 合成为按优先级排序的行动列表