Claude Code 讓會話互傳訊息

以前每個 Claude Code session 都像獨立聊天室，現在它們可以互傳訊息，我就能把協作從人肉轉接改成 session 直接對齊。

我用 Claude Code 一陣子了，最煩的從來不是寫 code，而是協調。A session 在查 bug，B session 在寫修正，C session 在重構同一批檔案，然後大家都得回頭問我：「前一個人有沒有看過這段？」我就像那個永遠在轉貼訊息的人，還得順手保證沒有一個 session 亂踩別人的假設。單線還撐得住，多線一開，整個流程就開始像群組裡每個人都在講自己的版本。

直到我看到這篇觸發我動手整理的方法論的文章：Zhihu 的 Claude Code 相關說明。它講的核心很直接：不同的 Claude Code sessions 現在可以彼此傳訊息。這件事不花俏，但很實際，因為它把我一直在手動搬運的上下文，改成 session 之間自己交換。

別再把每個 session 當成死胡同

「現在，你可以在一個會話（Claude Code Session）里問 AI 其他對話的信息，讓正在跑著的不同智能體之間對齊……」

翻譯一下就是：一個 session 不再只是自己的小筆記本，它可以變成網路的一個節點。它能問別的 session 看到了什麼、決定了什麼、改了什麼，這件事直接砍掉我最討厭的重工。

我之前拆過一個 repo audit，三個 session 平行跑：一個掃 API route，一個追 config，一個看測試覆蓋。結果大家都找到了東西，也都浪費時間重複蒐集上下文，因為沒有人能便宜地問別人：「你已經查到哪裡了？」

以前我只有兩條路：人工整理摘要，或接受 drift。人工摘要慢，而且容易漏；drift 更糟，因為每個 session 都很自信地活在自己的小宇宙裡。session-to-session messaging 的價值就很無聊，也很有用：它把最煩的協調成本拿掉。

實操上，我會把任務切成「局部責任」加「共享事實」。每個 session 只負責一小塊，但它可以直接去問別人事實，不用自己重建整個世界。

• 一個 session 當 investigator，另一個當 implementer。
• 讓 verifier 直接問 file path、diff、先前結論。
• 人只在真的需要拍板時介入，不當訊息中繼站。

把 session 當記憶單元，不只是輸出機器

很多人用 agent，還停在「比較會聊天的 autocomplete」這層。我覺得這太小了。更好的想法是：session 是分散式記憶，加上執行能力。它不只是吐文字，它還持有專案的一段工作記憶，然後把這段記憶提供給其他 session。

這件事重要，因為 context loss 的成本很真實。我看過一個 session 很有把握地提一個修法，結果另一個 session 早就判定那條路會炸掉別的流程。不是誰笨，是工作流設計錯了。大家都像自己擁有整個問題。

現在我比較願意替每個 session 劃清記憶邊界。Session A 管 bug report，Session B 管 implementation plan，Session C 管 regression checks。然後 A 可以問 B：「你用了哪些假設？」C 可以問 A：「使用者實際踩到哪些 edge case？」這比把整段 transcript 丟進每個 prompt 再祈禱好太多。

實操寫法很簡單：先定義每個 session 可以知道什麼，再定義它可以問什麼。聽起來有點囉唆，但這會逼 agent 不要變成什麼都懂一點、什麼都不深的雜訊機。

• 角色固定：scout、builder、reviewer、tester。
• 每個角色只准問特定類型的問題。
• 回覆要當成結構化輸入，不是聊天廢話。

平行做事有用，前提是你能收斂結果

我看過太多團隊一聽到 parallel agents 就很嗨，然後立刻淹在 merge pain。問題從來不是速度，而是收斂。三個 session 各改一塊，最後誰要知道這些改動還能不能拼起來？沒有協調通道，你就會回到手動對照紀錄，像大家都在不同分支的現實裡工作。

這次更新讓收斂變得比較像一回事。session 可以直接問別的 session：你改了什麼、測了什麼、刻意沒碰什麼。這代表 review 可以在工作進行中就發生，不用等到全部做完才開始抓包。

我會把它用在那種多條 code path 最後會匯到同一個 interface 的任務。比如一個 session 負責 API contract，另一個處理 UI wiring，第三個看 tests。它們可以在我做最後 merge 前先互相確認，少掉很多「欸你怎麼把那個名字改掉了」的場面。

實操寫法是把 reconciliation 變成任務的一部分，不要當成收尾清理。只要兩個 session 會碰到相關 code，就要求它們在結束前交換一則短狀態訊息。

• 你改了什麼？
• 你刻意沒碰什麼？
• 別的 session 繼續做時，哪裡最可能炸？

訊息要短，不然你只是做出另一個更吵的 Slack

這裡有個坑。session 可以互傳訊息，不代表它們就該開始寫日記。你一旦放任它們長篇大論，就只是做出一個更煩的聊天系統。我一點都不想要那種東西。

我想要的是短、結構化、可讀的訊息。把它想成 status packet，不是流水帳。整個目的就是降低 context transfer cost。如果每封訊息都像報告書，那你只是把問題換個地方放，還多了一個失敗模式。

我跟人協作時，本來就偏好短更新，而且要有欄位。agent 也該被同樣對待。告訴我你學到什麼、改了什麼、需要誰、卡在哪裡。其他都是裝飾。

實操寫法：替每個 agent 固定一個訊息格式。如果工具本身不強制，prompt 就自己強制。

STATUS UPDATE
- owner: session-name
- changed: files or concepts touched
- learned: new facts discovered
- needs: questions for other sessions
- risk: anything likely to break

拿來減少人類 babysitting，不是拿來取消判斷

我不想假裝 agent 可以自己把專案跑完。不能。它們能做的是，別再讓我當所有移動零件之間的膠水。這才是這個功能真正有感的地方：少一點 babysitting，多一點判斷。

session-to-session messaging 有用，是因為它讓系統先自己回答操作層問題，不要每次都升級到我這邊。另一個 session 有沒有看過這個檔案？有人已經決定命名規則了嗎？這個 test failure 是預期的嗎？這些是協調問題，不是策略問題。人只該在答案會改變方向時介入。

我已經受夠那種同一個問題被問三次的 session。它不是不會做事，是它沒辦法去問另一條 thread。現在能先互問，我就少接幾次打斷，流程也比較連續。

實操寫法：先定義什麼是 coordination question，什麼是 product question。前者讓 agents 自己解，後者留給你。

這對 Claude Code 本身改了什麼

Claude Code 本來就很有「直接在 repo 裡工作」的味道，但這次更新把它往更像多 agent 工作台的方向推了一步。差別不是你能開更多 sessions，而是這些 sessions 現在真的像共享工作空間，不必假裝彼此不存在。

這件事在亂一點的 codebase 特別有感。小 demo 你腦中就能 hold 住全部；真實產品 repo 不行。你需要 agents 分工、對照、避免互踩。這個功能等於承認：如果 session 永遠各做各的，協作就會卡在天花板上。

如果你要看官方背景，我會先去 Anthropic 的 Claude Code 頁面，再搭配 Anthropic Docs。我也建議把 Claude Code 的 GitHub repo 一起放著，因為實際工作流最後都會落到文件、範例和版本差異上。

實操上，我只會在真的有 dependency edge 的任務用這招。單檔小改動不用浪費。要留給那種「一個 session 的結論會直接影響另一個 session 下一步」的場景。

我會怎麼用，給你一個可直接搬的版本

我的版本很簡單：先分角色，再分訊息，再分責任邊界。不要一開始就想把所有 agent 都拉成全知全能，那只會更亂。先讓它們各自知道自己該知道什麼，再讓它們互相問最小必要資訊。

我通常會把流程設成 scout 先找事實，builder 再動手，reviewer 負責挑假設，tester 負責驗證。每一步都要能對上一個 session 的輸出，而且輸出要短。這樣你才不會把多 agent 協作做成一堆長聊天紀錄。

下面這段就是我整理後可以直接抄的模板。原始想法來自 Zhihu 那篇文章和 Claude Code 的協作方向，剩下的角色切法、訊息格式、流程順序，都是我自己整理出來的實用版。

可抄的模板

# Claude Code 多 session 協作模板

## 角色分工
- session-scout：蒐集事實、追 code path、列出未知項
- session-builder：實作變更
- session-reviewer：檢查假設、命名、整合風險
- session-tester：驗證行為、回報失敗

## 協作規則
- 每個 session 只負責一件事。
- session 之間只問事實，不問空泛意見。
- 訊息必須短、結構化。
- 只有產品方向或架構方向的問題才交給人。

## 統一訊息格式
STATUS UPDATE
- owner: <session-name>
- changed: <檔案或觸及範圍>
- learned: <新發現的事實>
- needs: <要問另一個 session 的問題>
- risk: <可能的衝突或回歸風險>

## 協作流程
1. session-scout 先畫出問題範圍並送出狀態更新。
2. session-builder 先問 session-scout 補齊缺的事實。
3. session-reviewer 問 session-builder 用了哪些假設。
4. session-tester 同時問 builder 和 scout 哪些地方要覆蓋。
5. 人只處理還沒解掉的衝突，或真的要改方向的決策。

## 每個 session 的 prompt 片段
你正在一個多 session 的 Claude Code 工作流中。

你的工作是守住自己的角色，需要時先問其他 session 拿事實。
在做決定前，先確認別的 session 是否已經知道答案。
只送短的、結構化的更新。
不要重複另一個 session 已經完成的工作。
如果需要幫忙，請用 STATUS UPDATE 格式提出具體問題。

## 範例跨 session 問題
STATUS UPDATE
- owner: session-reviewer
- changed: auth flow review
- learned: token refresh 是在 middleware 處理，不是在 route handler
- needs: session-builder，請確認新 error state 有沒有保留原本的 retry logic
- risk: 如果 UI 再加一層 fallback，可能會重複 refresh

這篇裡面我寫的 template 是原創整理，不是 Anthropic 官方原文。真正啟發我的來源是這篇 Zhihu 文章：https://zhuanlan.zhihu.com/p/2069484509557421666。Claude Code 的官方背景則可以從 Anthropic 和 文件 交叉看。