update · TowCue 編輯團隊
Claude Code Projects 協調平行 Agent:為什麼編排正在成為新的程式開發工作流
Anthropic 重新設計 Claude Code Projects,以 coordinator、平行 cloud threads 與共享記憶管理長期開發工作。TowCue 分析它適合什麼、限制在哪裡,以及團隊應如何審核平行 Agent 的產出。
快速解答
Anthropic 在 2026 年 9 月 17 日公布重新設計的 Claude Code Projects。過去開發者若同時執行多個 Claude Code session,需要自己拆工作、重複交代背景、追蹤進度並整合結果;新版則讓一個 Project 對話充當 coordinator,由 Claude 判斷如何拆分任務、啟動或路由到平行 cloud threads、共享專案記憶與脈絡,再把結果帶回來供使用者審核。
TowCue 認為真正值得注意的不是「一次跑更多 Agent」,而是 coding agent 正從單一任務執行走向工作編排。平行化只有在任務能清楚拆分、分支彼此相對獨立、測試能提供可靠證據,而且人類可以有效審核整體結果時才會產生真正的效率提升。
延伸閱讀可查看 Claude 工具頁、AI Agent 最佳實務 與 AI Agent 任務簡報檢查表。
Claude Code Projects 這次改了什麼
Anthropic 對舊問題的描述很直接:同時使用多個 session 時,開發者必須自己決定如何分工、重複提供背景、逐一檢查進度,最後再把結果拼回來。
新版 Project 在這些工作上方增加一層 coordinator。使用者描述目標並加入 repository 或其他脈絡後,Claude 可以在主對話直接回答簡單問題,也可以為需要實際執行的工作建立 thread。
每個 thread 都是一個完整的 Claude Code cloud session,有自己的 branch 與 repository copy。多個 thread 可以平行執行、建立 pull request 並跑測試;thread 本身還能透過 subagents、loops 與 workflows 再拆分任務。
因此產品角色已經不只是「幫你完成一項 coding task」,而是開始協助判斷多項 coding task 應該如何組織。
共享記憶和平行執行同樣重要
平行 Agent 很容易做出漂亮的展示,但長期脈絡能不能持續可靠地使用,才是更難的部分。
Anthropic 表示,每個 thread 都會讀取並寫入共享 project memory。像是「release 改到星期五」、「某項功能已取消」或「碰 billing service 前要先取得批准」這類決策,可以被後續工作沿用,不必每個 session 都重新說一次。
Project 也有 Library,用來保存使用者加入的檔案與 Claude 工作過程產生的 artifacts。
TowCue 認為這是設計中更具長期價值的一層。真正的軟體專案不是一串彼此獨立的 prompts,而是不斷變動的決策、限制、相依關係與審核狀態。如果協調層無法保存這些內容,增加更多 worker 往往只會增加更多 handoff。
哪些工作真的適合平行 Agent
Anthropic 的例子包括:為了降低 checkout latency,同時讓多個 thread profile 不同 endpoint;或是在 API、Web 與 mobile repository 中分別建立 thread,一起淘汰 deprecated API。
這些案例適合平行化,是因為它們有共同目標,但工作本身可以切成相對清楚的邊界。
其他可能適合的情境包括:
- 同時調查多個彼此獨立的 regression;
- 讓多個 service 升級相同 dependency 或 configuration;
- 實作互不干擾的實驗版本;
- 平行處理研究、實作與文件;
- 建立數個具有明確 merge order 的 pull requests。
共同條件是可拆分性。如果每個 worker 都持續依賴其他 worker 尚未完成的決策,平行化很快就會變成協調成本。
更多 Agent 不會消滅 merge conflict
Anthropic 明確說明,如果不同 threads 修改到相同程式碼,重疊部分仍會像一般 Git 工作流一樣形成 merge conflict。
這是一個很重要的現實限制。
Agent orchestration 不會讓軟體工程原本的限制消失。它可能加速實作,但 ownership 重疊、隱藏相依、flaky tests 與模糊需求仍然存在。甚至因為平行產出更快,這些問題可能更早一起出現。
因此 TowCue 不建議用 thread 數量衡量成功。更有意義的指標是:平行工作是否縮短了從開始到可審核、可合併變更的實際時間。
審核層反而變得更重要
一個 Agent 做一件事時,開發者還能比較容易追蹤每一步。當 coordinator 同時啟動多個 workers,逐步監督的成本會迅速升高。
審核方式必須往更高層移動。
每個 thread 的交付至少應該清楚說明:
- 修改了什麼;
- 執行了哪些測試以及結果;
- 做了哪些假設;
- 哪些部分仍未測試;
- 是否與其他 thread 修改相同檔案或系統;
- 變更是否容易回滾;
- 還有哪些決策需要人類確認。
Coordinator 可以降低逐一查看 session 的成本,但團隊仍需要足夠強的證據,才能信任摘要與合併決策。
目前 beta 有明確限制
新版 Projects 還不能取代所有本機 Claude Code 工作流。
Anthropic 官方文件指出,Projects 目前以 public beta 形式逐步開放給 Pro 與 Max。Team 與 Enterprise 尚未提供。首批 rollout 主要面向已使用 Claude Code cloud sessions、而且尚未在 Claude chat 或 Cowork 建立既有 Projects 的帳戶。
Projects 可在 claude.ai/code 與 desktop app 使用,目前不是 terminal CLI 功能。
Thread 現階段在雲端執行。Anthropic 表示未來會支援在本機、搭配 local tools、code 與 private network 資源運作,但尚未給出確切日期。如果你的工作依賴 local database、device emulator、VPN-only service 或特定機器上的工具,目前的 Project 執行邊界可能並不適合。
平行化也會改變使用成本
每個 worker thread 都是一個完整 Claude Code session。Anthropic 因此提醒,Projects 可能更快碰到方案的 usage limits。
所以「多跑幾個 Agent」並不是免費的最佳化。團隊要判斷平行執行節省的時間,是否值得額外的模型使用量與審核負擔。
對高度耦合的工作,一個範圍清楚的 session 可能仍更有效率;對 critical path 上彼此獨立的工作,平行 threads 才可能有更好的經濟性。
比「每個 Agent 用多少 tokens」更有用的指標,是每個通過審核並被接受的結果成本。
誰最適合先試
Claude Code Projects 最適合已經手動管理多個相關 cloud sessions 的開發者,尤其是 migration、多 repository 變更、持續進來的 bug queue 或 release 工作。
如果任務很小,一個 session 就能完成,新 Project 未必帶來額外價值。Anthropic 官方文件本身也建議,單一且範圍明確的任務可以直接使用一般 cloud session。
高度依賴本機工具或 private network 的團隊,也應等執行邊界符合自身環境後再擴大使用。
一個低風險的測試方式
先挑一個包含三到五項、可以清楚拆分,而且自動化測試完整的專案。
在 standing context 中明確寫出 target branch、ownership 邊界、test commands、需要批准才能修改的檔案或 service,以及什麼情況必須回來詢問使用者。
接著把 Project 工作流和原本流程比較:
- 到 pull request 可審核狀態的總時間;
- merge conflicts 與重複工作;
- reviewer time;
- test failures 與 rework;
- plan usage;
- coordinator 需要重新詢問的頻率。
不要因為 demo 看起來很快就擴大使用。只有在通過審核的結果確實更好時才擴大。
TowCue 觀點:稀缺資源正在變成協調品質
Coding model 的實作能力持續提高之後,瓶頸會逐漸移到另一個地方:哪些工作應該平行、脈絡如何保存、相依關係如何控制,以及結果如何被整理成可以有效審核的形式。
Claude Code Projects 很清楚地把這個趨勢做成了產品。
最好的工作流不會是「啟動最多 Agent」的那一個,而是能讓彼此獨立的 workers 擁有足夠脈絡快速前進,同時不製造比節省時間更多的 integration work。
可以把實際操作模型整理成:
目標 → coordinator → 有邊界的平行 threads → 測試與證據 → 人工審核 → merge order → 共享記憶
這已經更像管理一個小型軟體團隊,而不是和 coding assistant 聊天。
真正值得問的問題也從:
「Agent 能不能寫出這段程式碼?」
變成:
「這套系統能不能用比人工協調更低的成本,把工作正確拆分、執行,再安全地整合回來?」
這才是接下來值得追蹤的 benchmark。
來源
- Claude — Projects redesigned: from folder to conversation,發布於 2026 年 9 月 17 日。
- Claude Code Docs — Let Claude coordinate ongoing work with Projects,查閱於 2026 年 9 月 18 日。
- The Verge — Claude Code relaunches Projects to manage multiple AI agents in the cloud,發布於 2026 年 9 月 17 日。