Claude Code Desktop 大改版：从聊天窗口到并行 Agent 工作台

从聊天窗口，走向并行 Agent 工作台

官方发布串帖把目标说得很直接：更快启动会话，更容易把工作拆到几个会话里，并且始终看得见每个会话在做什么。Claude Code 团队成员 Thariq 随后写道：“I think of this almost like a v2”。这里的 v2 是体验评价，不是正式的 2.0 版本号。12

▲ 官方发布串帖主帖的演示视频，约 10 秒。下面几张截帧来自同一串帖里另外几条帖子的视频，时间点分别注明。

本文资料核对至 2026 年 10 月 22 日。文中把官方公告、现行文档与公开 Issue 三类证据分开标注；凡属工程判断而非产品事实的部分，都会在上下文里说明。

这次究竟在升级什么

以上是官方本轮公告展示的功能地图：前两列来自公告本身，第三列是本文按官方表述归纳的设计意图，不是已验证的结果。并不是表里每项底层能力都在这一天首次出现：多会话、可拖拽面板、集成终端与编辑器、Side chat，已经出现在 2026 年 4 月 14 日的 Desktop redesign 中。十月这轮更值得关注的，是环境、派生会话和反馈界面之间的整合。13

接入判断：如果日常只有一个仓库、一个短任务，变化主要是便利性；如果经常同时推进多仓库、远端开发、验证与修复，它才更接近工作方式的变化。不要用“能开多少会话”评价它，而要看能否更快找到需要自己接手的工作，以及交付物是否更容易验收。

Nested sessions：让委派成为可管理的工作对象

官方公告介绍的行为是：当你要求 Claude 并行处理任务，它会为各项工作启动 Nested session（嵌套会话），完成后把结果报告回主会话。现行文档尚未说明这一行为对所有并行请求的触发条件，本文也未独立复现。这里同时建立了任务的父子关系与结果回流关系。4

▲ 官方演示视频（nested sessions 帖）约 15 秒处的截帧：左侧列出父会话与三个子会话，主线程收到分别带来源的结果消息，随后汇总。来源：ClaudeDevs 发布串帖；不是本地实测截图。4

如果只是把一项工作交给 Worker，拿回结论，原有 Subagent 已经能做。Desktop 此轮值得注意的是：委派不仅发生在模型的执行过程中，也成为用户能在界面里找到、进入和管理的会话关系。

这对长一点的工程任务更重要。一次改造可能同时包含接口核查、局部实现和回归验证。真正需要管理的，不只是“它们是否跑完”，还包括：

• 每项工作属于哪个目标，允许修改哪些文件。
• 哪个子任务产生了结论，证据和改动留在哪里。
• 哪个阻塞需要人决策，哪个只是仍在正常执行。
• 回到主线后，哪些结果足以支持继续推进。

交互图解：一次并行任务怎样走到可验收

工程判断：Nested session 的价值，不应只是“多一个执行单元”，而应是一个更完整的委派契约。一个实用的子任务，至少要说清目标、输入、允许写入的范围、完成标准，以及向主会话回报什么。

尤其要避免“你查接口、你改代码、你写测试”这种看似并行、实际彼此猜测的分工。涉及共享契约时，先确定契约；涉及同一批文件时，先分配写入责任或建立 Worktree。界面能把工作排成树，不代表依赖已经被正确处理。

分流与上下文：不是每条支线都该变成子任务

十月公告把 Nested sessions、主动建议的 Follow-up 和 /btw 放在同一套体验里，但三者承担的工作不同：委派执行、发现新工作、临时理解，不该混成同一种“分叉”。46

交互图解：带过去什么，带回来什么

/btw：隔离问题，而不是交付任务

Desktop 的 Side chat（/btw 打开的侧聊）可以读取发起时已有的主线程内容，侧聊本身不写回主线程；目前支持 Local、SSH、WSL，且不保存到磁盘，关闭应用后不能再回到该侧聊。重要决策要主动带回主任务，不能让它只留在临时窗口里。7

这不是十月才诞生的机制。四月官方公告已经介绍过 Side chat 和快捷键；本轮是在整个多会话工作界面中进一步整合 /btw 的入口与呈现。36

Follow-up：把“发现工作”和“批准执行”分开

现行布局中，本地与 SSH 会话的任务卡 Start 会启动另一会话，默认使用当前会话的 Environment；Do it here 则把任务作为消息送回当前会话；Cloud 会话仍走旧的 Suggested task card 形态。启动前可在 Options 中检查 Environment、模型、Worktree 与权限；Start all 会分别启动多项任务，不逐个等待。8

这里的产品边界是：Claude 可以发现更多工作，但发现不等于值得做，值得做也不等于应该立刻并行做。一键启动越方便，越需要先判断任务是否属于本轮目标。

跨会话消息：要看清“哪一种可见范围”

Desktop 内置的会话管理能力可以检查、读取和消息联系其他 Code 标签页会话，但这一入口只看 Desktop 自己运行的 Local、SSH、WSL 会话，不因此看见 Cloud、独立 CLI 或 VS Code 会话。通用 Cross-session messaging 是另一项能力，可触达范围应另查其文档，不能把两者的能力并集直接套给 Desktop 入口。9

来自其他会话的消息会显示来源；接收方仍按自己的权限设置行动，也可以通过入站控制拒收。消息是新的输入，不是绕过权限的通行证。9

Saved environments：复用工作入口，不混淆执行与隔离

Saved environment 把“我接下来在哪里工作”变成可复用的配置。官方公告展示了多目录、SSH 主机、Cloud 环境，以及按目录选择 Worktree 的工作方式。现行文档进一步说明：保存的 Local / SSH Environment 会持有工作目录，后续从该入口启动会话，不必重新逐个选择。1011

▲ 官方演示视频（environments 帖）约 18 秒处的截帧：一个本地 Environment 包含多个目录，其中一个目录标记为 Worktree。这个细节说明，“环境有多个目录”和“每个目录都已隔离”不是同一件事。10

把三个问题拆开

前两项来自 Desktop 的环境与会话定义；第三项是使用 Git 工作目录隔离时必须保留的工程边界。Environment 负责复用执行入口，Worktree 负责避免多个会话直接争用同一份检出目录。1213

交互图解：会话独立，不代表文件独立

有三个容易漏掉的真实行为：

• 普通 Git 项目会话的 Worktree 默认关闭。需要在启动前开启；使用 Saved environment 时，在创建或编辑 Environment 时配置。不要把这条普通会话规则误当作“所有 Nested session 的默认隔离策略已获确认”。13
• 会话运行中通过 + → Add folder 添加的目录，会直接使用该目录，不为它创建 Worktree。即使主仓库已经隔离，后加目录也需要单独检查写入冲突。14
• 首次进入当前布局时，Desktop 会根据最近一个月常用的 Local / SSH 目录自动建立最多八个 Environment。因此，“我没手动创建，为什么出现这些环境”有官方解释；反过来，也不能期待所有历史目录都自动迁移成环境入口。15

对多仓库开发，这比“记住最近的文件夹”更实用。但环境配置应当小而明确：一组真正需要一起工作的仓库、一种执行位置、一套可核查的隔离设置。不要把 Saved environment 当作跨会话的全量状态容器。

Session rail 与 Recap：把注意力放到该接手的地方

并行工作的瓶颈，常常不是 Agent 不够快，而是人每次切回来都要重建现场：它做到了哪里，改了什么，为什么停住，现在到底要我决定什么？

本轮官方展示了四层反馈：侧栏区分正在执行与需要用户介入的会话；实时 ToDo 跟随计划推进；Recap 在需要人接手时概括当前轮次；Session rail 展示执行位置、上下文与改动。16

▲ 官方演示视频（侧栏与 recap 帖）约 16 秒处的截帧：左侧区分 Needs input 与 Completed；会话中的 Recap 概述改动与验证，并把下一步“是否开 PR”呈现为明确动作。画面中的测试数量只是演示项目结果，不是产品性能指标。16

四层反馈都由发布公告说明；表格最后一行那个 Session rail，在现行文档里叫 Session details panel，被定义为环境、改动、运行内容和上下文占用等卡片，且会受窗口宽度影响。窗口窄时入口可能移入菜单，不能仅凭面板没出现就判断功能不存在。1617

产品判断：这更像是在补 Agent 的“人机协作控制面”。人不必跟着每条工具调用走，而是在状态变化、风险判断、结果验收处介入。衡量它的好坏，应看重建现场是否更快、阻塞是否更明确，而不是卡片是否更漂亮。

官方资料与实现边界：这轮更新应该怎么读

持续跟踪不能只收藏新闻，也不能只看一份不断变化的文档。公告回答“本轮强调什么”，现行文档回答“现在如何使用”，Issue 则暴露真实使用中的摩擦；三者不能互相替代。

本次核验时，原来的 desktop-changelog 地址实际提供的是 Desktop application 参考页，而不是逐版本日志；公开 Issue 也记录了这个问题。因此本文按“公告日期 + 应用版本 + Code 运行时版本 + 功能行为”建立跟踪基线，不虚构一份完整的 Desktop 发版清单。1819

同样，公开资料尚不足以还原这轮 Desktop 的全部内部实现。下文所说的任务契约、上下文边界和控制面，是对可见行为的工程归纳，不是对 Desktop 内部源码的逐行分析。

Nested sessions 不是 Agent teams 的桌面版

这些概念有重叠，但不是同义词。Desktop 文档明确区分 Agent teams 与其自身的会话管理能力；Projects 也有独立的项目组织与可用范围，不能因为看见子会话就推导出获得了共享项目记忆。202122

延伸对照：Claude Code Projects：多会话并行的瓶颈在哪？。理解两篇笔记时，可以分别抓住两个问题：Desktop 这轮让多会话工作更容易被组织和接手；Projects 则让 Claude 持续协调一个项目不断产生的新工作。

上手验证：先跑通一个小闭环，再扩大并行

先记清两个版本号

Desktop 应用本身和 Code 标签页运行的 Claude Code 拥有独立版本号。本地 Code 会话可以用 /status 查看运行时；它也可能不同于终端里的 claude。更新桌面应用或更新 CLI，不应被视为同时更新了另一个。23

现行文档以 Desktop v2.37337.0 作为普通部署从旧布局升级的检查点；第三方模型部署还受版本和运行位置条件影响。最直观的识别方式，是新会话输入框下方是否有 Environment selector，以及是否具备 Saved local / SSH environments 和 Session details panel。看不到入口时，先查布局排障，而不是反复更新 CLI。24

用一个熟悉的小项目验证

1. 建环境：只加入这轮需要的目录；确认 Local / SSH / Cloud 及实际路径。
2. 查隔离：对并行写入的 Git 仓库，启动前检查 Worktree；追加目录另外检查。
3. 定权限：复杂改造先用 Plan 审阅方案，再选择执行权限；不要为了减少提示直接跳过权限。Auto 与 Bypass permissions 不是同一模式。25
4. 小范围委派：先试两项边界明确的工作，观察是否建立预期的子会话、是否能进入查看。
5. 测试中途接手：补充一条约束，检查真正执行的会话是否收到并遵守；不只看主会话是否回复“明白”。
6. 验证回流：确认汇报链接、Diff、分支与测试输出相互对应，再决定是否开 PR。主会话说“完成”不能代替验收。

前两项的操作与默认行为见环境、Worktree 文档；最后三项是建议执行的验收步骤，并不表示本文已经完成这些本地实测。1113

可用于首次试跑的提示词：

目标：给视频渲染任务结果增加 resolution 字段。

先读取相关代码，提出拆分计划和字段契约，等待我确认，不要先修改。
建议拆成两项：API/调用方兼容性核查，以及渲染结果与测试方案核查。
确认这两项相互独立后，再使用嵌套会话并行推进；不要自动扩展到其他工作。

每项任务都说明：目标、必要背景、允许修改的文件范围、验证方式。
如需写代码，先确认实际目录、分支与 Worktree，不要只因为是子会话就认为已隔离。
遇到字段语义、依赖缺失或环境不可达时，报告阻塞，不要自行猜测替代。

回报主会话时，只交付：结论、证据位置、实际改动、测试结果和未解决风险。
不要提交、推送、合并或部署，除非获得明确授权。

这是工作约束示例，不是 Claude Code 的配置格式；关键隔离与权限仍应在真实 Environment / Session 设置中核对。

边界与摩擦：树状组织，并不自动等于好用

这轮变化也有代价。公开 Issue 中，使用 Desktop 2.37337.1 的用户报告了父子嵌套后的历史会话查找困难、分组方式变化，以及深层关系在侧栏中难以辨认等问题。它们说明“按启动关系组织”与“按仓库或主题找回工作”可能发生冲突；这些是具体版本与用户的报告，不是本文独立复现的结论，也不能据此断言所有用户都会遇到。26

这个反馈很有启发：任务树适合解释“谁启动了谁”，Environment 适合解释“在哪里执行”，仓库或主题则适合解释“这件事属于什么”。三种关系并不总是相同。好的工作台应允许从不同维度找回同一项工作，而不是让一种树替代所有浏览方式。

对实际使用，至少保留以下判断：

• 并行不是默认更快。如果任务共享契约、修改同一文件或等待同一资源，协调与验收可能反而更重；本文没有足够实测数据绘制效率提升或 Token 节省曲线。
• 可见不是可靠。ToDo、Recap 和状态是理解现场的入口，代码与验证结果才是交付证据。
• 环境复用不是安全隔离。分开的工作目录依然可能操作同一数据库、队列或服务账号。
• 跨会话消息不是实时共享记忆。关键决策要确认送达相关执行者，长期规则应放到合适的持久化位置。

对 Agent 工程的启示

以下是从这轮产品行为抽象出的设计建议，不是对其内部架构的断言。

把会话做成可寻址的工作对象。除了聊天历史，还应有父任务、执行位置、可见状态、交付物引用与下一步动作。用户需要回到“那件工作”，而不只是回到“那段聊天”。

让汇报成为协议，而不是最后一句自然语言。Worker 的输出应包含结论、证据、产物和风险。主会话能否长期保持清晰，取决于回来的信息是否可用，而不只是是否足够短。

把“需要人”当成一等状态。与其只有 Running / Done，不如说明是权限审批、需求歧义、环境故障还是等待验收，并给出可以执行的下一步。

拆开浏览关系与执行关系。任务树、项目分类、Environment、仓库、时间线分别解决不同的找回问题；这也能减少层级增长后带来的组织负担。

让权限留在实际执行边界。协调者传来一条消息，不应提升执行者权限；切换 Environment 或启动另一会话，也不应让用户误以为原来的隔离假设自动成立。

如果把它借鉴到视频生成 Agent，最值得先做的不是“更多 Agent 同时跑”，而是任务可追踪、阻塞可解释、产物可定位、修改可验收。这些做好之后，并行才有机会变成收益，而不是更难排查的工作堆积。

跟踪清单：下一次更新优先验证什么

建档于 2026 年 10 月 22 日。以下是待验证项，不是已完成的产品承诺；后续按“日期 / Desktop 版本 / Code 版本 / 平台与 Environment / 证据”补记录。

• 子会话上下文：实际带入哪些父会话信息？父会话后续更改的契约如何可靠同步？
• 隔离默认值：手动新建、并行委派、Follow-up 启动的会话，Worktree 行为是否一致？逐项检查，不互相推导。
• 生命周期：中断、失败、关闭应用、归档父会话后，子会话与结果入口分别如何表现？
• 组织方式：父子层级、Environment 分组与仓库查找是否更容易同时使用？跟踪 #102129。
• 运行位置差异：本机与 SSH 分别试跑同一小任务，检查入口、消息、权限与产物回流。
• 验收与成本：记录真实任务的重建现场难度、冲突、返工和用量，再评价并行是否值得；不要先画收益结论。
• 版本记录：是否恢复清晰的 Desktop 逐版本 Changelog？跟踪 #102385。

结论：这轮更新最值得跟踪的，不是 Claude 又多会写多少代码，而是它是否把“多个 Agent 同时工作”推进成“一个人仍能从容组织、介入和验收这些工作”。UI 的变化只是表面，工作对象、信息回流与注意力分配的变化，才是这次换代感的来源。

参考资料

1. ClaudeDevs 发布串帖
2. Thariq on X
3. Claude Code desktop redesign
4. ClaudeDevs：nested sessions 说明
5. Desktop — Manage sessions
6. ClaudeDevs：side chat / follow-up
7. Desktop — Ask a side question
8. Desktop — Start a task that Claude suggests
9. Desktop — Work across sessions
10. ClaudeDevs：saved environments
11. Desktop — Create a saved environment
12. Desktop — Environment configuration
13. Desktop — Run a session in its own worktree
14. Desktop — Add folders to a session
15. Desktop — Environments that Desktop creates for you
16. ClaudeDevs：session rail 与 recap
17. Desktop — See session details
18. Desktop changelog 地址
19. Issue #102385：Desktop changelog 缺口
20. Run agents in parallel
21. Desktop — What’s not available in Desktop
22. Claude Projects
23. Desktop — Claude Code version in the Code tab
24. Desktop — Check which layout you have
25. Desktop — Choose a permission mode
26. Issue #102129：侧栏层级反馈
27. Lydia Hallie：Idle compaction
28. Claude Code CHANGELOG
29. Code Review is now generally available
30. Code Review docs