AI创业内参
AI风向

【AI风向】Claude Code 开放嵌套子代理：Agent 可以生出 Agent，开发者实测飙到 9 层

AI创业内参

Anthropic 在 Claude Code v2.1.172 中悄悄开放了子代理嵌套能力——你的 AI Agent 现在可以自己派生子 Agent，官方称上限 5 层，但社区实测直接冲破天花板跑到 9 层。这对 AI 开发者意味着什么？

▲ 图1：Claude Code 嵌套子代理架构 — 5层递归调用链，每层上下文隔离▲ ▲ 图1：Claude Code 嵌套子代理架构 — 5层递归调用链，每层上下文隔离

事件回顾

6 月 10 日，Anthropic 发布了 Claude Code v2.1.172，在更新日志中用一句话描述了这项变化：「Sub-agents can now spawn their own sub-agents (up to 5 levels deep)」。——子代理现在可以生成自己的子代理，官方称最多支持 5 层嵌套。

而在此之前两年多的时间里，Claude Code 的子代理有一道硬限制：子代理不能创建子代理。这个约束的目的是「防止无限嵌套」。当开发者设置一个 code-reviewer 子代理时，它只能自己干活，不能再去叫帮手。

现在这道墙被推倒了。

Ready Solutions AI 的工程师在功能上线当天就做了一个测试：写了一个只会复制自己的子代理，然后把它扔向天花板。结果不是 5 层就停了——而是跑到了 9 层，零报错。更新日志写的是 5，实机测试是 9。

这就是这条新闻的核心：官方文档还在说「子代理不能生成子代理」，但代码已经可以跑了。而且跑得比你想象的要深。

除了嵌套子代理，v2.1.172 还带来了以下重要更新：

  • Amazon Bedrock 区域解析改进，现在能从 ~/.aws 配置文件读取区域
  • /plugin 市场新增搜索栏
  • 修复了 1M 上下文无配额时 session 永久卡死的 Bug（现在自动压缩回标准限制）
  • 修复了模型选择器、权限规则、背景代理等多个关键 Bug
  • 总计 30 项改动，以 Bug 修复为主

而截至发稿前，Claude Code 已迭代到 v2.1.176，新增了 session 标题多语言、Bedrock 凭证缓存优化、enforceAvailableModels 托管设置等功能。

为什么重要

这个改动看似只是一行更新日志，但它触及了 AI Agent 架构的核心问题：任务分解的深度应该由谁来控制？

在此之前，开发者用 Claude Code 的多代理模式只有两种选择：

  1. 平坦结构：一个主 Agent 同时调度多个子 Agent，每个子 Agent 独立干活，互不通信。适合「把一个大任务拆成 N 个独立小任务」的场景。
  2. Agent Teams：一个 lead agent 管理多个 worker agent，但 worker 之间不能相互调度。适合「有明确分工的协作场景」。

嵌套子代理打开了第三种模式：递归分解。子 Agent 遇到自己处理不了的子任务时，可以再派生子 Agent，层层下钻。这对于以下场景特别有价值：

  • 大规模代码库分析：顶层 Agent 识别出需要深入分析的模块 → 派生子 Agent → 子 Agent 发现某模块依赖关系复杂 → 再派生子 Agent 去分别分析各个依赖
  • 日志/数据管道排查：日志阅读 Agent 发现异常 → 派出根因分析 Agent → 根因分析 Agent 需要查数据库 → 派出数据库查询 Agent → 结果只把摘要向上传递
  • 文档生成：文档 Agent 扫描项目结构 → 为每个模块派出子 Agent 写文档 → 子 Agent 发现某模块太大 → 再拆分

关键的价值在于上下文隔离。Ready Solutions AI 的分析文章指出：在嵌套结构里，每一层子 Agent 只拿到「调度指令」下行，只传回「摘要」上行。这意味着原始日志、中间结果等大量 token 不会污染上层 Agent 的上下文窗口。这对于控制 API 成本至关重要。

但这也意味着每一层嵌套都是开销。每个子 Agent 至少要消耗一次模型调用 + prompt 处理。如果你的任务本质上不需要递归分解，多加一层不会让结果更好，只会让账单更厚。

我们能学到什么

▲ 图2：三种Agent架构对比 — 平坦结构 vs Agent Teams vs 嵌套结构▲ ▲ 图2：三种Agent架构对比 — 平坦结构 vs Agent Teams vs 嵌套结构

1. Agent 树 ≠ 组织架构树

Read Solutions AI 的文章给出了一个重要警告：「我预判最普遍的误用，是团队把他们公司的组织架构映射成 Agent 树。」

正确的做法是根据任务的形状决定 Agent 结构，而不是根据公司的部门结构。代码库的模块边界≠你的团队架构。过度嵌套的一个典型症状是：你发现每个子 Agent 的 prompt 里都在解释「为什么要这样做」，而不是直接描述「要做什么」。

2. 文档和代码已经脱节

截至 v2.1.172 发布次日，Claude Code 官方文档的三个不同页面仍然写着「子代理不能生成子代理」，并明确指导开发者「不要将 Agent 工具加入子代理的 tools 数组」。但变更日志说的是相反的话。

对此的正确心态是：变更日志比文档新，代码比变更日志新。依赖新功能时，以实际运行结果为准，引用变更日志做依据，定期重新验证。

3. 嵌套只存在于 CLI，SDK 和 API 还没有

这是容易踩的坑。目前嵌套子代理只在 Claude Code CLI 的文件式子代理（.claude/agents/）中可用。以下三个入口不支持嵌套：

入口支持嵌套？限制
CLI 文件式子代理✅ 支持官方称 5 层
Agent SDK 子代理❌ 不支持Agent 工具被禁用
Agent Teams❌ 不支持只有 lead agent 能管理
Managed Agents API❌ 单层depth > 1 被忽略，最多 20 个 agent

如果你在 API 或 SDK 里设计多 Agent 系统，不要假设嵌套可用。但如果你用 CLI 做开发工作流，现在就可以在 .claude/agents/ 里定义支持嵌套的子代理。

行动建议

  1. 更新 Claude Code 到最新版：claude update，确保版本号 ≥ 2.1.172。建议直接升到最新的 2.1.176 以获得更多 Bug 修复。
  2. 先试平坦结构，再考虑嵌套：大多数开发任务用平坦的子代理调度就够了。只有当你的任务本身就要求递归分解时（如依赖树遍历、多层级分析），嵌套才有额外价值。
  3. 每加一层嵌套，问自己三个问题：
  • 这一层是否在做上一层做不到的事情？
  • 上下文隔离带来的收益是否大于额外调用的开销？
  • 如果不加这一层，用平坦结构能否实现？
  1. 注意成本：Claude Code 子代理的费用计入你的 API 用量或订阅配额。每层嵌套 = 额外的上下文窗口 + 模型调用。一个 5 层的调用链意味着至少 6 次模型推理（1 主 + 5 子），如果每一层都用 Opus 模型，单次任务成本可能轻松超过 $10-20。
  2. 关注后续更新：Anthropic 的发布节奏很快（10 天内从 v2.1.172 到 v2.1.176）。嵌套子代理的能力边界随时可能扩大，官方文档也随时可能更新。

本文由AI辅助创作，经人工审核编辑发布