在本章中，你将学习如何在 Claude 桌面应用中使用 Claude Code，如何在本地模式与云端模式之间切换，以及如何借助 Git Worktrees 并行运行多个编码 agent。你会看到：如何协调彼此独立的特性分支、如何管理后台 agent，以及如何把独立开发出来的改动合并回同一个代码库。
本章的目标，是展示如何使用 Claude Code，在本地与云环境之间编排并行开发。
这件事之所以重要，是因为它把开发方式从串行、单线程工作，推进到协调式、多智能体工作流。这样一来，你就能扩大自己的生产力，更快、更高效地构建功能。
本章将涵盖以下主题：
- 介绍 Claude Code 的桌面集成与后台 agent
- 运行模式：本地 vs 云端
- 编排并行的本地与云端 agent
- 理解 Claude Code 中的 Git Worktrees
- 合并并行开发出来的特性分支
- 通过移动端在云中运行 Claude Code
介绍 Claude Code 的桌面集成与后台 Agent
这一节中，我们将探讨 Claude Code 的桌面集成。Anthropic 已经把 Claude Code 直接集成进 Claude 桌面应用与移动应用中，使得开发任务与日常对话式推理能够在同一个环境中进行。这减少了上下文切换时的摩擦，让工作流变得更加流畅。除此之外，这套集成还开箱即用地提供了直接运行在 Claude 内部的、基于云端的后台 agent。
图 10.1 —— Claude Desktop 的仓库选择界面
后台 agent 让多个功能能够并发开发，而不是一个接一个地顺序开发。在准备这个演示的过程中，这种工作方式转变带来的影响几乎是立刻就能感受到的。无缝的桌面集成加上后台 agent 的组合，创造出了一种与过去完全不同的开发体验。
这里展示的工作流涉及多个同时进行的操作，因此，如果按步骤逐项跟下来，并不现实。这里更重要的是聚焦于概念，并观察这种集成在实践中是如何工作的。重点在于理解：这些能力结合在一起之后，如何提升生产力，以及它们如何重塑我们构建功能的方式。
Claude Code 的安装与运行模式：本地 vs 云端
Claude Desktop 应用里包含一个 Code 标签页，它会以图形界面运行 Claude Code。二者共享同一个底层引擎和配置（例如 CLAUDE.md、MCP servers、hooks 等）。
下面这张截图展示了 Claude Desktop 界面，其中可以看到 Code 标签页已经可用。
图 10.2 —— Claude Desktop 的 Code 标签页界面
打开 Code 标签页之后，就会进入 Claude Code 的工作区，你可以在这里选择一个项目文件夹，然后开始与代码库交互。
图 10.3 —— Claude Desktop 中的 Claude Code 工作区
选择工作区文件夹（本地 Worktree 模式）
在开始任何工作之前，先选择一个文件夹。这个文件夹会成为 Claude Code 的工作区。大多数情况下，这个文件夹里包含的是一个代码仓库，最好是一个 GitHub 仓库。
这里的关键细节在于：我们选择的是一个文件夹。
当 working method 被设置为 Local worktree 时，Claude Code 会在你的机器本地 spin up Git worktrees（稍后会讨论）。也就是说，这个模式下所有事情都发生在本地，没有任何东西运行在云端。
因为所有工作都发生在本地机器上，所以 Claude Code 需要一个目录，用来创建和管理这些 worktrees。这就是为什么我们需要给它提供一个文件夹位置，告诉它应该在哪里执行工作。
我们打开 working method 选择器，并确认 Local worktree 处于选中状态。
图 10.4 —— 在 Local Worktree 模式下选择工作区文件夹
选好之后，我们打开 Agentic-Coding-with-Claude-Code 目录。这个目录现在就成了所有工作运行的工作区。到这一步，Claude Code 已经处于本地 Git worktree 模式下运行。
切换到 Claude Code Web（云模式）
现在，把 working method 切换到默认选项，也就是带有云图标的模式。切换到这个模式后，Claude Code 会以 Anthropic 基础设施中的托管实例方式运行。这也就是所谓的 Claude Code web / remote workers / background agents。
在这个模型中，Anthropic 会在自己的环境里运行容器化的 Claude Code 实例。而这些实例需要访问我们的代码。我们通过授予 Claude Code web 对 GitHub 仓库的访问权限，来完成这种接入。
图 10.5 —— 在 Claude Code Web（云模式）中选择仓库
一旦权限授予完成，工作流就会按如下顺序推进：
- Anthropic 会启动一个 Claude Code 实例
- 这个实例会 clone 仓库
- 它会直接在代码上工作
- 它可以提交改动
- 它可以创建 Pull Request
因为这个实例拥有仓库访问权限，所以它的行为就和项目中的普通开发者一样。这种模型带来的价值在于可扩展性。你可以并行运行多个 Claude 实例，让它们同时处理不同任务。至于能并发运行多少实例，则取决于你的配置和付费额度。本节后面我们就会看到这种并行能力的实际效果。
Git Worktrees 如何支持并行开发
在 Local worktree 模式下，Claude Code 依赖的是 Git Worktrees。Git Worktrees 允许我们在不同目录中同时 checkout 同一个仓库的多个分支，而不需要把仓库 clone 多份。
图 10.6 —— Git Worktrees 在本地模式下支持并行开发
当多个编码 agent 同时工作时，这就变得尤其有用。
每个 agent 都可以在自己的 worktree 中、在自己的分支上运行。我们不需要反复 stash 改动，也不需要来回切分支。隔离是通过文件系统中的独立目录完成的。
对于这个工作流来说，我们并不需要深入理解 Git Worktrees 的全部细节。只要知道：它允许多个分支在同一时刻同时处于活动状态，而 Claude Code 正是利用这一机制来支持并行开发的。
有了工作区和运行模式之后，我们就可以继续下一步了。
编排并行的本地与云端 Agent
为了建立上下文，我们把 Claude Code 的 working directory 指向 Agentic-Coding-with-Claude-Code 这个仓库。
图 10.7 —— 配置 working directory，用于编排本地与云端 agent
在这个阶段，所有操作都发生在本地机器上。当前仓库 checkout 到的是 hookhub 分支，也就是我们前面一直在用的实现分支。
在本地运行 Next.js 应用
首先，我们让 Claude Code 在本地运行这个 Next.js 应用。
因为 working directory 已经配置好了，所以不需要再 clone 任何东西。Claude Code 会检查目录结构，发现 hookhub 目录，进入该目录并列出文件。随后，它通过 package.json 判断出：这是一 个 Next.js 项目。
图 10.8 —— 用 Claude Code 在本地运行 Next.js 应用
接着，它就能推断出正确执行顺序：
先安装依赖：
npm install
再启动开发服务器：
npm run dev
开发服务器会在后台运行。有些输出不会显示出来，但进程本身会成功启动。执行过程中，Claude Code 会检查 npm 版本。稍后，Next.js 应用会启动在 3001 端口上，因为 3000 已经被占用了。
图 10.9 —— 通过 Claude Code 在本地运行的 Next.js 开发服务器
协调并行的本地与云端工作
到了这里，我们开始扩展实现，来展示如何在本地与云环境之间并行开发功能。
切换到 Claude 应用（离开 Claude Code 标签页），并把它当成一个独立的研究环境来使用，与当前本地 Claude Code 会话彼此独立。给它分配一个“仓库发现任务”：开一个新聊天，让它去搜索在线仓库中实现了 Claude Code hooks 的项目，并重点关注那些 GitHub star 数较高的仓库。
图 10.10 —— 在 Claude Code 中分配一个仓库发现任务
意图很明确：一旦这些仓库被找出来，结果就会被回传给 Claude Code，并集成进 HookHub 数据库。
执行并发特性开发
当这个研究任务正在云端运行时，我们回到当前这个本地运行的 Claude Code 会话里，再请求实现一个新功能：
Add animations to the application
这个会话完全运行在你的本地机器上。你创建一个新实例，选择 Agentic-Coding-with-Claude-Code 仓库，然后直接在本地代码库上实现这个功能。
接着，在它仍在运行的同时，我们再创建另一个 Claude Code 实例，这一次保留默认的云端选项。这会激活一个运行在 Anthropic 云端的后台 agent。输入下面这个 prompt：
Add to the project/hookhub branch a much cooler hero, make it anthropic style
如下图所示。
图 10.11 —— 在并行开发中，提示 Claude Code 实现一个新功能
在这个 prompt 里，我们明确要求它：
- 在
project/hookhub分支上工作 - 添加一个明显更酷的 hero section
- 让它采用 Anthropic 风格
图 10.12 —— Claude Code 正在执行一个并发特性实现任务
到这一刻为止，一共有三个任务正在本地和云端并发执行：
- 一个云端研究任务：查找高 star 的 Claude Code hook 仓库
- 一个本地 Claude Code 会话：给 UI 加动画（
vigilant-fiestel） - 一个远程后台 agent：在指定分支上重做 hero section（
claude/anthropic-hero-design-01Fo8dkJxcBUqWHyjhPfTHQS）
其中两个任务跑在本地，一个任务跑在 Anthropic 云端。
本地的 Claude Code 实例完成了动画特性，并提出改动供审批。这个 agent 给出了一组需要确认的改动。批准这些改动，让实现继续推进。
图 10.13 —— 审查并批准 Claude Code 在本地生成的代码改动
到这一步，动画功能已经在本地完成，并且更新后的 UI 已经体现出新的动画效果。
观察远程分支的创建
接下来，切换到那个在云端运行的后台 agent。这个 agent 会先在 Anthropic 的云环境中创建一个新分支。一开始，它会从 main 分支 checkout，而不是 project/hookhub。
这点很重要，因为我们的目标是要在 project/hookhub 上实现这个功能。如果它继续从 main 开发，后面合并时很容易引发不一致。
不久之后，agent 会纠正自己的分支上下文，执行下面这个命令：
git checkout origin/project/hookhub
下面这张截图展示了它执行这条命令并切换到正确分支的过程：
图 10.14 —— 云端 agent 切换到正确的特性分支
这样，它就确保自己已经在正确分支上工作了。随后，它会重新获取相关代码，并再次列出项目文件，恢复完整上下文，然后继续 hero section 的重设计。
处理研究结果
与此同时，Claude Desktop 中的研究任务完成了，并返回了一组高 star 的 Claude Code hook 仓库列表。输出里包含多个 GitHub 仓库链接。
图 10.15 —— Claude Code 展示经过筛选的 hook 仓库结果
复制完整 URL 集合，然后把这些仓库信息粘贴到一个新的本地 worktree 会话中，再告诉 agent 把这些链接加入到 HookHub 列表里。
图 10.16 —— 将发现的仓库添加到 HookHub 配置中
由于这里用的是 Git worktrees，所以这次修改会发生在一个独立的工作目录中，并绑定到它自己的特定分支。agent 会把这些仓库映射出来，然后更新 hooks.json 文件，加入新的条目。
图 10.17 —— 更新 hooks.json 配置，加入发现的新仓库
当这些改动被生成出来之后，对它们进行 review，并接受。
图 10.18 —— 审查并批准 hooks.json 配置更新
到这个阶段，需要注意以下几件事：
- 动画特性已经在本地完成，并且能在 UI 中看到
- 数据库更新任务已经修改了
hooks.json，加入了新的仓库链接 - 远程云端 agent 正在
project/hookhub上处理 hero section 的重设计
下面这张截图展示了更新后的仓库链接，并确认这些改动已经生效。
图 10.19 —— 确认更新后的 HookHub 仓库链接
理解 Git Worktree 布局
既然现在已经在使用 Git worktrees，那么不同目录实际上就代表着不同的活跃分支。
主仓库目录依然保持不动。与此同时，还会出现额外的 worktree 目录，例如 zealous-jemison（由 Claude Code 自动生成），它对应的是另一个分支。每个并行任务都运行在自己的 worktree 上下文里，这样就避免了不同特性实现之间互相干扰。
在这个例子中，一共有三个相互独立的功能被同时开发出来：
- 应用的 UI 动画
- hook 仓库数据库更新
- hero section 重设计
每个功能都在独立分支中实现，之后再统一合并到同一个分支里。
准备合并这些产物
现在，剩下的挑战就是把这些产物整合起来。当前你手里有三个分支需要汇总：
- 一个由云端 agent 更新的远程分支
- 两个通过本地 Git worktree 产生的本地分支，分别包含动画改动和数据库更新
这些改动必须最终合并成一个统一、连贯的代码库。由于其中一个分支存在于远端，而另外两个是通过本地 Git worktrees 维护的，因此整个合并过程需要显式协调。
下一步，就是让 Claude Code 帮我们把这些分支合并起来，把动画、更新后的 hook 仓库以及重设计后的 hero section 全部汇总到一个统一分支中。对应的 prompt 如下：
Merge all the commits here to branch project/hookub
这一动作，标志着工作流从“并行执行”正式过渡到“受控整合”，也就是把本地和云端并行开发结果统一收束起来。
理解 Claude Code 中的 Git Worktrees
在继续往下讲合并之前，我们先要理解：Git Worktrees 在底层究竟是如何运作的，以及在这种 setup 下版本控制的行为是什么样的。目标是让你对 Claude Code 创建隔离工作副本时，究竟发生了什么，形成正确直觉。
当 Claude Code 创建一个 Worktree 时，它会创建一个独立的工作目录。这个目录与原仓库绑定，但会 checkout 到一个不同的分支上。
图 10.20 —— Claude Code 用于并行开发的 Git Worktrees 架构
Claude Code 如何使用 Worktree
如果我们按步骤去看，整个流程会更容易理解。下面这些，就是 Claude Code 创建并开始使用一个 Worktree 时的精确动作序列：
- Claude Code 创建一个带新分支的 Worktree。举例来说，这个 Worktree 可以被命名为
vigilant-feistel（这是 Claude Code 自动生成的名字）。 - 所有代码和所有改动，都会发生在这个 Worktree 目录里。
- 当我们提交代码时，这个 commit 会落在
vigilant-feistel分支上。 - 原始分支
project/hookhub会保持完全不变。 - 如果我们喜欢 Claude Code 产出的结果，就把它 merge 回去。
- 如果不喜欢，就删掉这个 Worktree 和它的分支，不留任何脏痕迹。
多个 Worktree 并行存在
在图 10.20 中，一共存在两个 Worktree：vigilant-feistel 和 zealous-jemison：
- 我们打开编辑器，能看到普通的
hookhub目录结构 - 同时也会看到两个额外目录，每个目录都包含了一份与原始分支代码库一致的拷贝
虽然目录结构看起来相同，但它们对应的 Git 分支是彼此独立的；vigilant-feistel 和 zealous-jemison 都是与 project/hookhub 分离开的独立 GitHub 分支。
这使得多个并行任务可以同时存在，而每个 Claude 实例都在完全不同的分支上运行，并使用原始代码库的一份全新副本。
一旦你开始使用多个 agent，就不可避免地会遇到“编排”问题——也就是开发者需要协调多个工作上下文、多个分支和多个任务。Git Worktrees 正好提供了一种非常便利的机制来支撑这种协调。
合并并行开发出来的特性分支
本地的 Claude Code 实例是在 vigilant-feistel 目录中实现动画功能的。这个目录本身就是一个 Git Worktree，它虽然链接着主仓库，但 checkout 到的是另一个分支。
即便目标分支是 project/hookhub，实际开发工作也都发生在 vigilant-feistel 目录中。这正是 Git Worktrees 的运作方式：它允许你在隔离目录中开发，同时仍然指向同一个仓库。
现在，我们希望把那里生成的代码提交掉。告诉 Claude 去创建一个 commit，并在 commit message 中明确写明：这些改动是通过 Claude Code Desktop 生成的。
图 10.21 —— 审查在 vigilant_fiestel worktree 中生成的动画功能改动
在 vigilant-fiestel 运行的同时，另一个本地 Claude 实例则在另一个 Worktree——zealous-jemison 中处理 JSON 文件更新 GitHub URL。两个实例彼此独立运行。Claude 会先准备 staging 命令。
下面这张截图展示了 Claude Code 为动画功能准备 commit，并将其呈现出来供审批。
图 10.22 —— Claude Code 正在为动画功能改动准备 commit
批准它。此时有一个非常重要的现象会显现出来：当前活动分支并不是 project/hookhub，而是 vigilant-fiestel。
图 10.23 —— commit 被应用到 vigilant-fiestel Git worktree 分支
这正好验证了 Worktree 的行为方式：如果一个 commit 是在某个 Worktree 里创建的，那么它会落到这个 Worktree 自己的分支上，而不是原始分支上。 这里，这个 commit 被成功写入了 vigilant-fiestel。
推送 Worktree 分支
接下来，我们把这些改动推上去。
切换到 zealous-jemison Worktree。这个分支上已经有它自己的 commit 了，把它也 push 上去。
Claude 会请求你批准 push。下面这张截图展示的是 zealous-jemison 的 push 过程，它对应的是数据库更新，也就是把新发现的 Claude Code 仓库条目写进 hooks.json。
图 10.24 —— 推送 zealous-jemison worktree 分支到远程仓库
而下面这个，则是 vigilant-fiestel，对应的是 landing page hero section 的 UI 动画功能：
图 10.25 —— 推送 vigilant-fiestel worktree 分支到远程仓库
批准这两个 push。
此时，project/hookhub 分支上仍然不会显示新 commit。这是符合预期的，因为每个 Worktree 都维护着自己的独立分支。
除此之外，还有第三个分支，是由远程 Claude Code 实例创建出来的，名字类似：
claude/anthropic-hero-design/<id>
图 10.26 —— 远程 Claude Code agent 完成 hero section 重设计
这个分支中的所有改动，都已经在远端被 commit 并 push 了。
刷新仓库之后，就能确认现在有三个新分支：
vigilant-fiestelzealous-jemisonAnthropic Hero Design
下面这张截图展示了 GitHub 仓库视图，其中可以看到这些新创建的分支。
图 10.27 —— GitHub 仓库视图，展示新创建的特性分支
这三个分支中的每一个，都对应一个独立开发出来的功能。
把所有内容合并进 project/hookhub
现在，我们想把所有这些实现统一带回 project/hookhub。
这里不再手工切换分支逐个 merge，而是把任务直接委托给 Claude Code。
我们把分支名告诉它，并指示它把所有 commit 都 merge 到 project/hookhub。
图 10.28 —— 提示 Claude Code 把所有特性分支合并进 project/hookhub
Claude 会开始在本地工作，并创建另一个 Worktree，名叫 suspicious-bassi。
它不会直接把东西 merge 到 project/hookhub，而是先创建一个临时的集成分支：project/hookhub-merge。
图 10.29 —— 创建临时的 project/hookhub-merge 集成分支
这样做的好处，是在真正碰到主开发分支之前，先完成所有整合。
执行合并
Claude Code 开始真正的 merge 过程。在这个过程中，会出现一个 merge conflict。
图 10.30 —— 在分支整合过程中检测到 merge conflict
Claude 随后会提出一个冲突解决计划：
- 先解决来自
anthropic-hero-design的冲突 - 再 merge
vigilant-fiestel - 再 merge
zealous-jemison - 最后把所有内容推送到
project/hookhub
冲突发生在全局 CSS 文件中。
Claude 会提出一个编辑方案，我们批准它。
于是，merge commit 被创建出来。
接着，Claude 会继续执行：
git merge vigilant-fiestel
然后再执行：
git merge zealous-jemison
下面这张截图展示了 Claude Code 执行 merge，并把最终 merge commit 呈现出来供批准的过程。
图 10.31 —— Claude Code 展示最终 merge commit，等待审批
此时，所有特性分支都已经被整合进 project/hookhub-merge。
在推送到 project/hookhub 之前先做测试
Claude 接下来会请求你批准，把合并结果推送到 project/hookhub。
这里先不要批准。在真正 push 之前，先在本地做测试。
图 10.32 —— 在推送到主分支之前，先在本地测试合并后的项目
告诉 Claude 启动开发服务器：
npm run dev
此时可能会出现一个错误：
npm is not found
Claude 会去 source .zshrc 配置文件，以便加载环境，然后再尝试一次。
接着，它会判断出依赖缺失，于是运行：
npm install
现在，会同时有两个进程在运行：
npm installnpm run dev
当依赖安装完成后，开发服务器会成功启动在 3002 端口上。此时，这份合并后的实现就已经在本地跑起来了。
验证整合后的结果
打开运行在 3002 端口上的应用，并把它与原始实现做对比。
图 10.33 —— 对比原始版与增强版 HookHub hero section
差异会非常明显。新的 hero section 现在包含了：
- 网格背景
- banner 元素
- 一条波浪线
- 仓库统计信息
- 动画效果
仓库列表里的条目数量也比以前更多了。这些仓库是 Claude Code 研究并加入进去的。动画不仅出现在局部组件，而是贯穿整个网站。与原来静态的体验相比，现在整体更有动态感。
也就是说，这三个独立开发出来的功能，已经能够在同一个结果中正确共存。
最终完成合并
既然验证完成了，现在就可以批准 push。Claude 会把 project/hookhub-merge merge 进
project/hookhub。
图 10.34 —— 所有特性分支合并进 project/hookhub 之后的最终 commit 历史
刷新仓库之后，结果就会被确认下来。此时，这个分支里包含三条 commit，而每一条 commit 都合并了一个来自独立 Worktree 的分支。每个分支都对应一个彼此独立实现出来的功能。
这种 setup 强调了一个很关键的变化：开发是可以被“扩容”的。三个不同功能，由三个不同 Claude Code 实例在同一时间并行开发出来。其中除了两个本地实例之外，还有一个 Claude Code 实例运行在远端。
当你看到三条彼此独立的开发线路最后收敛到同一个分支时，这件事的意义就会变得非常直观：我们其实是在通过委派并行特性实现，来把自己这个开发者“扩展”成多个并行工作者。
还值得一提的一点是，这整个过程中并不需要太多前端经验。驱动这些实现的 Claude Code 模型，已经能够胜任前端部分的开发，并且生成出了所需代码。
通过移动端在云中运行 Claude Code
Claude Code 现在也已经集成进移动应用了。与桌面端相同的工作流，可以直接从手机端发起。在这个例子中，我们从移动界面里选择 claude-code-crash-course 仓库，然后从那里开始会话。
因为移动环境本身不在本地执行代码，所以所有操作都发生在 Anthropic 的云端。它不依赖任何本地机器。仓库在远端被 clone，分支在远端被 checkout，改动在远端被 commit。
我们先让 Claude 切换到 project/hookhub 分支，并实现一个 Anthropic 风格的 footer。
图 10.35 —— 在移动应用界面中运行 Claude Code
这个工作流与桌面端体验完全一致：Claude 会 clone 仓库，checkout 目标分支，检查项目结构，实现功能，提交改动，并准备 Pull Request。
整个过程一步步展开：先 fetch 仓库，再切换分支，再检查文件。系统指令会确认当前已经切换到了 project/hookhub。
图 10.36 —— Claude Code 在移动会话中分析仓库
一旦项目上下文被理解之后，Claude 就会识别出：这是一个带有 Anthropic 风格品牌元素的 Next.js 应用，并据此继续执行。
这里还值得注意一点：默认的云端配置并不会自动带上 MCP、自定义 hooks 或 output styles。这个环境是以默认设置运行的。自定义配置当然也可以额外加进去，但当前这个会话并没有带这些配置。
实现 Footer 组件
Claude 会在 components 目录下生成一个新的 footer.tsx 文件。
图 10.37 —— 在移动端 Claude Code 会话中创建并集成 footer 组件
这个 footer 组件体现的是 Anthropic 风格。创建组件之后，Claude 还会把它集成到 page.tsx 里，也就是把它 import 进主页面并进行渲染。
版本控制操作也会自动跟上。改动会被暂存并提交。由于请求中明确要求把改动推送到 project/hookhub，而 Claude Code 内部使用的是 Git worktrees，因此背后还会发生一些额外 Git 操作，用于把 worktree 中的 commit merge 回目标分支。
Git log 会同时显示之前那些 merge 和 commit。此时，新加的 footer 组件以及对 page.tsx 的修改，都已经进入分支历史。
审查 Pull Request
打开 GitHub 上的仓库，会看到一个新建出来的 Pull Request。一开始，这个 Pull Request 的 base branch 指向的是 main，这并不是我们想要的目标。于是，需要把 base 改成 project/hookhub。
一旦 base branch 修正完成，这个 Pull Request 就会正确反映出两个被修改的文件：
page.tsxfooter.tsx
查看 diff，可以看到 footer 组件集成的改动，正如预期。
到了这里，你甚至还可以在 GitHub 中直接 @Claude 来审查这个 Pull Request。只不过，由于这个分支并没有配置 GitHub workflow，所以不会自动触发任何检查。
图 10.38 —— 在 GitHub 中审查由 Claude Code 创建的 Pull Request
因此，这里的 review 仍然需要手工完成。
在本地验证这些改动
为了验证这次集成，在本地执行：
git fetch
git pull
npm run dev
启动开发服务器之后，应用会加载出来，并且页面底部会出现新的 footer。你会看到一句品牌文案：
Built with love for Claude Code powered by Anthropic
布局上还需要一个小调整，这件事可以再委托给 Claude Code 继续 refinement。这里更重要的结论是：从 clone 到 Pull Request 创建，整个工作流都可以由移动设备发起，并且完全在云端执行。
工程模型始终保持一致：
- 指定意图
- 让 Claude 自己去理解仓库
- review 输出
- 继续迭代
变化的是界面，而不是底层开发过程本身。
什么时候并行 Agent 反而会适得其反
并行编码 agent 很有用，但它们并不总是正确选择。下面这些场景里，让 agent 并行跑，往往会适得其反。
强耦合功能
当多个任务会修改同一批文件，或者它们彼此依赖对方输出时，并行 agent 往往会制造 merge conflict，甚至悄悄覆盖彼此的工作。如果 feature B 需要先等 feature A 的接口存在，那就应该顺序执行，而不是并行。
共享状态与顺序约束
数据库迁移、配置文件改动、共享类型定义，这些东西天然会形成隐式依赖。两个 agent 如果同时往同一个 config、schema 或 route 文件里写东西，很容易撞车。到最后，解决这些冲突所花的成本，往往比并行节省下来的时间还大。
任务太小
每一个 agent session 都有自己的固定开销：要建立上下文、要读代码库、要规划工作。一个原本顺序做两分钟就能搞定的小任务，如果被拆给多个 agent，再加上 review 与 merge，很可能反而更慢。凡是能舒舒服服放进一个 session 里搞定的任务，就不要拆。
协调成本过高
如果你发现自己需要写出一大段详细、毫无歧义的 specification，才能防止多个 agent 互相踩脚，那这本身就是个信号。你越是要花很多时间去定义边界，其实从并行中获得的收益就越少。
探索性或不确定性很强的工作
当你自己都还不知道最佳路径是什么时，比如在调试一个棘手问题，或者在为一个模糊设计做原型探索，这时候让多个 agent 并行，只会把不确定性放大。相比之下，一个聚焦的单实例会话，边做边迭代，往往更有效。
小建议
可以采用这样一个心智模型：
并行 agent 最适合那些彼此独立、边界明确、并且作用于代码库不同部分的任务。
如果拿不准，就先顺序执行。只有在你确认这些任务不会彼此交互之后，再考虑并行化。
并行开发检查清单
- 确保每个任务都作用于独立文件或独立组件
- 在每个 agent 的 prompt 中验证正确的起始分支
- 在推送到目标分支之前，先测试合并结果
- 合并完成后，清理 worktree 目录
总结
在本章中，你学习了如何在桌面应用中使用 Claude Code，如何在 Local worktree 与 cloud 模式之间切换，以及如何并行运行多个编码 agent。你看到了 Git Worktrees 如何隔离不同特性的开发，也看到了后台 agent 如何在云端运行，以及多个独立开发出来的分支如何被 merge、测试，并整合成一个可工作的统一代码库。你还进一步看到了：同样的工作流如何扩展到移动端，在那里，所有执行都发生在云中。
这些内容之所以有价值，是因为它展示了如何把开发方式从串行开发转向编排式、多智能体工作流。只要你理解了如何管理并行分支、如何协调本地与远端 agent，以及如何安全地 merge 它们的输出，你就能显著提升开发吞吐量，同时又始终保持对代码库的控制权。
在下一章中，我们将讨论 deep agents 以及它们在长跨度任务执行中的作用。我们会定义 deep agents 的特征，并分析 LangChain deep agents harness，包括它的架构与执行模型。
