递归 AI 系统：进阶指南

递归 AI 系统将模型的输出反馈回自身——用于分解问题、优化答案，或生成子 Agent，而子 Agent 又能生成更多子 Agent。递归天然适合那些结构无法预先知晓的问题（例如“研究这个主题”：不深入查看，你就不知道有哪些子主题）。它也是构建一个消耗 200 美元 token 却一无所获的系统的最简单途径。本指南涵盖三种行之有效的模式以及确保其安全运行的控制机制。

模式 1：递归任务分解

模型将任务拆分为子任务；每个子任务要么直接解决，要么再次拆分。

python
import json
MAX_DEPTH = 3
def solve(task: str, depth: int = 0, budget: dict = None) -> str:
    budget = budget if budget is not None else {'calls': 30}
    if budget['calls'] <= 0:
        return f'[预算耗尽，无法解决：{task[:60]}]'
    budget['calls'] -= 1
    # 在最大深度强制进入叶子路径——深度控制存在于你的代码中，而非提示词中
    if depth >= MAX_DEPTH:
        return llm(f'直接简洁地解决：{task}')
    plan = json.loads(llm(
        f'任务：{task}\n'
        '如果此任务可直接一步回答，返回 {"atomic": true}。\n'
        '否则返回 {"atomic": false, "subtasks": ["...", "..."]}——最多 4 个，'
        '每个子任务严格更小且不重叠。仅返回 JSON。'
    ))
    if plan['atomic']:
        return llm(f'直接简洁地解决：{task}')
    results = [solve(s, depth + 1, budget) for s in plan['subtasks']]
    joined = '\n\n'.join(f'## {s}\n{r}' for s, r in zip(plan['subtasks'], results))
    return llm(f'将这些子任务结果综合成一个答案，回答：{task}\n\n{joined}')

这段代码防御的失败模式：模型不擅长决定何时*停止*分解——不加防护时，它们会把“写一首俳句”拆成三个子任务。因此，代码中强制设置了两个硬性限制（深度和调用预算），并在提示词侧施加压力（“严格更小”、“最多 4 个”）。独立的子任务天然可以并行化——将列表推导式替换为 asyncio.gather（异步模式）。

模式 2：递归优化（生成 → 批判 → 修订）

通过批判和修订循环迭代草稿，直到达到标准：

python
def refine(task: str, max_rounds: int = 3) -> str:
    draft = llm(f'完成此任务：{task}')
    for _ in range(max_rounds):
        verdict = json.loads(llm(
            f'根据任务对以下草稿评分（1-10），并列出具体缺陷。'
            f'JSON：{"score": n, "defects": [...]}\n任务：{task}\n草稿：\n{draft}'
        ))
        if verdict['score'] >= 8 or not verdict['defects']:
            break
        draft = llm(f'仅修复以下具体缺陷，不更改其他内容：\n'
                    f'{verdict["defects"]}\n\n草稿：\n{draft}')
    return draft

确保此循环收敛而非振荡的两个关键：批判者必须提出具体缺陷（仅凭分数无法为修订提供依据），并且修订范围仅限于修复这些缺陷。收益递减很快——第 1-2 轮捕获了大部分改进，而模型自我批判会在自身盲点上停滞（使用不同模型作为批判者有明显帮助）。这与宪法 AI 在训练时利用的生成/评估差距相同，但在推理时应用。

对于代码任务，用客观事实替换 LLM 批判者：运行测试，将失败信息反馈回去。只要可行，客观信号总是优于自我评估。

模式 3：递归 Agent（Agent 生成 Agent）

编排器将任务委托给子 Agent，每个子 Agent 拥有自己的上下文窗口——这是 Agent 系统扩展至单个上下文之外的方式：编排器持有计划，工作者持有细节，只有摘要向上流动。框架（CrewAI vs AutoGen、LangGraph）提供了监督者/工作者机制。递归特定规则：

通常一层就够了。 编排器 → 工作者覆盖了大多数实际任务；深度 ≥ 3 主要增加成本和协调失败风险，成熟的 Agent 平台会刻意限制委托深度。

子 Agent 返回摘要，而非完整记录——关键在于上下文隔离；将工作者的完整追踪向上传递会破坏这一目的。

向下传递共享预算，就像模式 1 中的 budget 一样，防止某个失控的工作者耗尽整个分配。

控制平面（不可协商）

每个生产级递归系统都需要以下四项，且应实现在代码中而非提示词中：

控制项实现方式

深度限制depth 参数，硬性截止到叶子路径 预算共享计数器，记录每次调用消耗的调用次数/token/金额 收敛检查当分数趋于平稳或输出不再变化时停止——而非仅依赖最大迭代次数 追踪记录完整的调用树（父→子，每个节点的 token 数）；未追踪的递归无法调试。LangSmith/Langfuse 能很好地渲染这些树——参见 LLM 评估工作流

还有一个质量警告：递归放大错误的能力与提升质量的能力相当。 一个略微错误的子任务答案会被向上综合为事实；一个幻觉性的批判会将修订引向歧途。在边界处进行验证（对模型返回的每个 JSON 进行模式检查——Zod vs Pydantic），并在可能的情况下将循环锚定在客观信号上（测试、检索、计算器）。

常见问题

这是 AGI 风格的递归自我改进吗？ 不是——这些系统在固定模型权重内改进*输出*。这里没有任何内容改变模型本身。

何时递归不是合适的选择？ 当工作流的结构预先已知时——固定流水线（提取 → 转换 → 摘要）更便宜、更快，且更易于调试，而让模型每次请求都重新发现该结构则不然。递归仅适用于未知结构。

总成本直觉？ 深度为 3、分支为 4 的分解最多产生 4³ = 64 次叶子调用，加上每层的综合。在部署循环之前，务必估算最坏情况下的树——这正是预算上限的用途。

---

*最后更新：2026 年 6 月。*