你现在同时开着几个 Claude Code 会话？两个？三个？还是四个？
多开的问题从来不是"跑不动"，而是最忙的那个人是你：后端会话改了字段，你要手动复制给前端；测试跑完了，你要手动通知主会话；一个 worktree 动了公共配置，你还得挨个终端去提醒。会话在并行，人却成了中间件。
上周 Claude Code 把这块拼图补上了，但社区直接吵成了两派：一派说"终于不用我传话了"，另一派说这是"GOTO：看起来很符合直觉，去掉也根本不影响图灵完备"。到底该听谁的？先把账算清楚。
这周发生了什么
时间线捋一下：8 月 8 日官方宣布会话之间可以互发消息（需要 v2.1.224 及以上）；8 月 13 日推送 v2.1.232，是本周最大的版本，核心变化有三个：
提示词里打 @名字，就能直接点名另一个正在运行的会话，跨会话对话不用走工具调用。小红书
交互会话里 fork 模式默认开启，分身直接继承父会话的整段对话和 prompt cache；
/subtask 命令上线，派非队友 agent 默认在后台并行跑。
社区对此分成了两派。
"真香"派基本都是真在多开的人。以前一个会话发现刚改的接口会影响另一个 worktree，只能靠你人肉转述；现在可以把影响和下一步直接发过去，消息在工具调用之间投递，不会打断正在跑的任务。前后端字段联动、长任务结果回报、多 worktree 同步破坏性变更，这些场景是真的解渴。
“泼冷水"派的理由也很硬。知乎那个问题下的高赞回答直接搬出了 OpenClaw 作者 peter 的判断：这种玩法是"Waste of tokens”。成批量地去调用已经积累了长上下文的会话，相当于以几十倍的 Input Tokens 来使用 Subagents 模式。知乎
同一个回答里的类比更扎心：会话间互发消息，就像古早编程语言的 GOTO，看起来很符合直觉，然而去掉也根本不影响图灵完备。知乎
两派其实没吵到同一个东西上——它们说的是两个不同的工具。
先算一笔账：fork 便宜，传话可能贵
先看 fork 这笔账。如果支线任务需要主会话已经掌握的背景，fork 比新建 subagent 更便宜，因为它共享父会话的 Prompt Cache，首个请求直接复用已有缓存，不用把项目背景重新喂一遍。以 Sonnet 5 API 公开定价为例：常规输入是 $2/百万 token，Cache Hit 只要 $0.20，相当于 1/10。小红书但注意，这不代表总消耗直接减少 90%：分身的新输入、输出和工具结果仍会产生消耗，3 个 Fork 也不等于省 3 倍。真正降低成本的，不是多开 Agent，而是少重复喂同一段上下文。
再看传话这笔账，正好反过来。知乎高赞回答说的"几十倍"，瞄准的就是这个场景：消息发到一个上下文已经很长、缓存又已经过期（默认 TTL 只有 5 分钟）的会话里，对方就得按完整输入价格重新读一遍上下文再接着干活，大多数调用都无法命中缓存。知乎上下文越长，收一条消息越贵。
所以结论很直白：聊透主线再 fork，分身最划算；聊跑题了再 fork，它也会带着跑题内容走。小红书传话适合轻量通知，不适合搬运大段上下文。
四种半并行工具，什么时候用哪个
把新旧能力加在一起，Claude Code 手里现在是四种半并行协作工具。选哪个，记住这几条就够了：
fork / /subtask：支线任务需要主会话已有的背景时用。继承整段对话加缓存，成本最低，典型场景是主会话写功能、分身同步补测试。
@会话名 / SendMessage：你手动开了多个独立会话，需要互相通知或提问时用。传递的只是纯文本，不带聊天记录、文件和权限。
新会话 / 命名 subagent：任务和主会话完全无关、父会话已经很乱，或者交给 Haiku 就能干完时，新开反而更省。
resume：需要完整上下文时，官方建议仍用 resume 恢复原会话；需要一个受你监督的协作小组，用 agent teams 更合适。小红书它俩是"后半"：一个负责找回记忆，一个负责组队，都不算并行新战力。
一句话总结：fork 解决"这个分身知道什么"，跨会话消息解决"这条消息该告诉谁"，resume 解决"我怎么找回记忆"。
避坑清单
真上手之前，这几条边界建议背下来，都是社区里已经踩过或讲透的：
消息只是纯文本，不是上下文，不是文件，更不是授权。对方会话的权限边界不会被消息绕过，消息里的命令只会被当作文本。
别发空话，发交接单。有内容运营玩家把这种消息叫做 handoff receipt，每次交接至少写清楚 8 件事：谁发给谁、对应哪个任务、已经确认了什么、证据链接在哪、下一步建议做什么、哪些动作禁止做、哪些动作必须先问、这条交接什么时候过期。<#&!53#&!>小红书消息不是上下文，只是带证据和边界的交接请求。
版本和平台：v2.1.224 起步，macOS、Linux、WSL2 可用，原生 Windows 暂不支持，功能还取决于平台和提供商是否具备资格。
网络路径要心里有数：同机会话之间走本地 socket，跨机器消息会经过 Anthropic 服务器；跨机器目前只支持对方回复，不能主动发起新一轮会话。小红书
给会话起个好叫的名字。建议先把会话命名为 backend、frontend、tester，再约定"出现破坏性变更就主动通知"，这是 @名字能好用的前提。
谁该冲，谁该等
该冲的：日常开 2-4 个会话真并行的人，尤其是被前后端接口联动、多 worktree 破坏性变更、长任务回报卡过的。这次更新补的就是你一直在人肉干的那部分，消息按交接单的写法来，成本可控，收益立竿见影。
该等的：平时只开一个会话、任务短平快的，这次更新和你关系不大；如果你期待的是"一群 agent 自己聊起来自动干活"，社区目前的共识是谨慎——乒乓式来回循环烧起 token 来不心疼才怪。
留一个值得继续盯的信号：5 月 Anthropic 就放过 Agent View 的研究预览版，一屏"指挥中心"管理所有并行会话。消息解决的是会话之间"说得上话"，下一步大概率要解决"看得全"。到那天，多开才算真正闭环。
