配了三个月 Claude Code，今天才发现它的子 Agent 硬上限悄悄被移了——这件事把长会话的账彻底变了

Anthropic 在 8 月 7 日发了 Claude Code 2.1.224，release note 很长，但有一行淹没在里面，没引起多少讨论：200 子 Agent 上限没了。

这行字背后，是一个被反了的逻辑。

这个上限是 Anthropic 几个月前刚加的，动机很清楚：防止 Agent 疯狂派生把自己跑崩——一个 session 不断生成子 Agent，子 Agent 再生成子 Agent，递归失控，最后把 runner 撑爆。这个保护是合理的。

但保护加错了地方。

上限看的是 session 生命周期内派生过的子 Agent 总数，不是「现在同时在跑多少」。一个健康的 session 做大型重构，跑 5 小时，派生了几百个子 Agent 处理不同模块的测试、文档、依赖更新，每个子 Agent 都正常完成然后退出——它也会被上限卡住。

换句话说：上限保护的是一种失败模式（疯狂递归），但代价是惩罚了另一种正常用法（长时间累积任务）。

现在上限没了，只保留下层限制：depth limit 防止 Agent→Agent→Agent 的无限链式派生，concurrency limit 防止同时激活过多 Agent。这两个才是真正在防失控，上限数值只是「你跑了多久」的计数器，和健康与否无关。

同一周还跟着发了两个相关变化：

v2.1.232 把 subagent_type: “fork” 设为默认，新派生的子 Agent 自动继承父 session 的完整对话上下文和 prompt cache。意味着分支出去处理并行任务时，下一轮不需要重新解释项目背景、重新建立 cache——上下文直接传过去。v2.1.232 之前，每次派生子 Agent 都要在 prompt 里重新粘贴必要的上下文，新 prompt 从零建立 cache。fork 类型把这两个摩擦同时消掉了。

非 teammate 的 agent 派生在交互式 session 中默认改为后台运行，分支出去处理任务时不会打断你正在看的 session。

三个变化放在一起看，逻辑很清楚：Anthropic 在系统性地解除长时间 unattended session 的摩擦，同时保留真正管用的保护机制。

这件事的实际影响：

如果你的工作流会跑长时间 session 处理复杂任务，现在不需要再估算「这个 session 大概会派生多少个子 Agent」然后提前规划拆分。depth 和 concurrency 的保护依然在，session 生命周期本身不再有硬上限。

如果你的工作流需要并行分支处理多个子任务，fork 类型的上下文继承意味着每个分支不需要重新解释项目上下文，后台运行的默认行为意味着分支不会抢你的主 session 注意力。这两个变化把「开一个长会话让它自己跑」这件事从「需要小心规划」变成了「可以直接用」。

对于在 CI/CD 或自动化 pipeline 里跑 Claude Code 的团队，这个变化让需要长时间、多步骤的任务终于不再被硬上限中断。

上限取消是 2.1.224 的变化，fork 默认化是 2.1.232 的变化，间隔一周，两个叠加。Anthropic 的工程团队在把 Claude Code 从「适合短任务的高频工具」向「适合长程任务的主力环境」方向推——这次改的是底层约束，不是界面功能。