Claude Code 实战入门（八）：子 Agent、worktree、计划模式

学完 Hooks 之后，下一个改变 Claude Code 体感的特性是并发控制。不是线程意义上的并发，而是"模型同时在帮你处理几件事、隔离到什么程度、你能监督多少"那种意义。

三个特性，按所需信任度从低到高排。

计划模式——气闸

计划模式最便宜。Shift+Tab 切到指示器显示 plan。模型现在只规划、不执行：读、想、提议、停。你看完计划，要么批准、要么改、要么砍。同意之后它才动手。

我什么时候用：

• 任何非平凡任务的前 30 秒。“实现 X 功能” → 先 plan。多数情况下计划会暴露模型对代码库的误解。
• 任何动到鉴权、支付、schema 迁移、生产配置的事。两秒钟读计划，省下数小时收拾烂摊子。
• 在我不熟的仓库里干活。计划顺便就是我自己的 onboarding 文档。

误区：因为"任务很小"就跳过 plan 模式。小任务"咦这不是我想要的"密度最高。

子 Agent——可以并行的活

子 Agent 是父 Agent 拉起来处理一个圈定任务的另一个 Claude Code 实例。经典写法放在 .claude/agents/<name>.md：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

---
name: research
description: 跨代码库阅读某个主题并产出报告。不做编辑。
tools: Read, Grep, Glob, WebFetch
---

你是一个调研子 Agent。你的工作：
1. 在代码库里搜索这个主题。
2. 读够多的文件，理解它。
3. 返回一份带文件路径和原文引用的结构化报告。

不要编辑。不要执行 shell。保持聚焦。

对话里就说：“去调研鉴权是怎么实现的，用 research agent。”

它给你的：

• 上下文隔离。 子 Agent 的上下文是它自己的，父 Agent 的上下文不会被污染。
• 工具收紧。 一个 research agent 物理上改不了文件。安全是架构，不是纪律。
• 并行干活。 任务彼此独立时可以同时拉三个子 Agent。

它的代价：

• Token。每个子 Agent 自带 system prompt、自带上下文、自带一来一回。
• 协调成本。父 Agent 要合并结果，把那一步明确写在计划里。

什么时候子 Agent 是错答案：父 Agent 已经有它需要的上下文。“去读这一个文件然后告诉我"开个子 Agent，是昂贵的递归。

worktree——并行分支不会让你脑袋打架

git worktree 是同一个仓库的第二个工作树，挂在不同分支上、不同目录里。Claude Code 知道这件事：EnterWorktree 工具会新建一个分支 + worktree，然后把会话切进去。

什么时候有用：

• 正在 feat/x 上干活，用户要你顺手在 main 上修个不相关的小 bug。开 worktree、修、commit、退。
• 想对同一个问题试两套方案，又不想把废弃的 commit 全堆到主分支。
• 你要把活下放给子 Agent，并希望它在文件系统上也被隔离。

心智模型：worktree 是上下文隔离的物理版本。子 Agent 隔离上下文，worktree 隔离文件系统。

退出怎么选：

• keep — worktree 留在磁盘上。活只做了一半、可能回来时用。
• remove — 删掉，分支也删。确信做完了再用。

如果 worktree 里还有没提交的改动，删除会拒绝，除非你显式 discard_changes: true。这是对的。别绕过。

三者的组合

我处理硬任务的套路：

1. 计划模式。 “我想做这个，你会怎么做？” 读计划，调一调。
2. worktree。 开一个隔离分支，让实验可以失败而不弄脏主线。
3. worktree 里用子 Agent 处理彼此独立的子任务。先调研、再实现、再写测试，每个走自己的上下文。
4. 回到父 Agent，合并结果，commit，退出 worktree（活停了用 keep，做完了用 remove）。

三道信任闸门，三级递进。等模型真的在改文件时，你已经精确投入了这件事值得的注意力。

什么时候三个都不要用

绝大多数任务。说真的。80% 的情况是"改这个函数、跑测试、提交”——普通模式、不开子 Agent、不开 worktree。上面这些特性是给那 20% 又大、又不可逆、又分叉的活准备的。

如果你发现自己每个任务都在抓子 Agent 和 worktree，更值得问的问题是：你的任务是不是切得太大了。