Claude Code子代理现在默认后台运行：实际变化解读

我每天用 Claude Code 作为主要的开发 agent，本地跑，也在 SSH 上跑，连接的是一台跑着几个生产站点的 VPS。过去几周有个变化悄悄改变了我用它的工作方式：子代理现在默认在后台运行了。

以前，当 Code 把任务委托给子代理时，对话会阻塞直到子代理完成。自 7 月 1 日起，它会在子代理运行期间继续做其他事，并在完成时通知你。对于任何在使用 --dangerously-skip-permissions 运行长时间会话、几小时后才回来看的人来说，这是本质区别——从一个等待的工具变成了真正能无人值守工作的工具。

日常发生了什么变化

我的工作流始终如一：批准最初的计划，然后让 Code 无需确认地继续执行每一步，只在真正出错时才停下。后台子代理让这种自主性叠加了。我现在可以同时让它审计站点、生成新内容、审查配置文件——每个都作为独立的子代理运行，而不是一个接一个地排队。

这里有两个重要的限制：默认最多 20 个并发子代理，嵌套深度现在允许到 3 层（从之前的 1 层提升）。这两个限制都有其道理——如果没有任何约束，一个大任务很容易分支出比你预期更多的东西。

Sonnet 5 和 Opus 5：1M 上下文不再是例外

Claude Sonnet 5 在 6 月底成为默认模型，原生 1M token 上下文窗口。Claude Opus 5 在 7 月 24 日接替它成为默认 Opus 模型，同样是 1M 上下文。在长会话中——比如对站点进行全面重构时——我以前会盯着 /context 并在任务中途运行 /compact 以避免丢失线程。现在我明显能跑更长的会话而无需触碰这两个命令。这不是魔法——自动压缩仍在起作用，非常长的 Opus 会话的成本也值得注意，但实际的天花板已经提高了。

真正重要的安全修复

作为一个管理生产基础设施的人，这是我最关心的改进：8 月份修复了一个问题，即在 worktree 隔离会话（及其子代理）中可能对主 checkout 运行破坏性 git 命令的漏洞。当你在用广泛权限启动子代理处理重要系统时，这种隔离失效正是你最不想看到的故障模式。它被快速关闭是个好信号——但也提醒了"自主"和"无人监督"不是同一回事。我仍然会仔细检查每个会话的最终报告，而不是假设没有可见错误就意味着一切正常。

我仍然划定的界限

有了这么高的自主性，诱惑是越来越把雄心勃勃的任务交出去然后走人。我不会在接触面向客户的生产服务器上这样做——那些会话保持交互式，在敏感步骤上需要明确确认。我在自己基础设施上才会给予完全的自由度，那里出错的代价很低且可以恢复。这个区别比任何配置标志都更能决定一个会话获得多少自主性。

后台默认子代理是近几个月来最改变我日常使用 Claude Code 的变化——不是因为它花哨，而是因为它契合了我已经习惯的方式：批准计划，让它运行。Sonnet 5 和 Opus 5 的 1M 上下文很好地支持了这一点。工作tree 隔离修复提醒我们，更大的自主性意味着需要更仔细地审查最终输出，而不是更少。