多代理協作

Claude Code 最近多了一個功能叫動態工作流（dynamic workflows）：讓主代理在執行時，當場寫一支 JavaScript，生成並協調一群子代理——每個子代理有自己獨立的 context window 和一個聚焦的小目標。 我前幾天用它做了件很實際的雜活：評估四個候選部落格選題，看哪個跟我既有文章庫重複、哪個值得寫。這篇把那支 script 整個攤開，講三件事——怎麼寫、parallel 和 pipeline 怎麼選、跑一次燒多少 token。 為什麼不是「開更多分頁」那麼簡單你可能會想，並行做事，開幾個對話視窗不就好了？ 差別在 context。Claude Code 過去是「一個對話、一條 context」，所有東西擠在同一個上下文視窗。長任務這個模式有三個老毛病，官方發布時直接點名：智能惰性（做到一半宣布完工）、自我偏好偏差（驗證自己的產出時護短）、目標漂移（對話太長、尤其壓縮過後忘了最初目標）。 動態工作流的解法不是把單一 context 養得更肥，而是把活切開：每個子代理拿一塊乾淨的上下文，做一件聚焦的事，彼此不互相汙染。並行只是順帶的好處，真正的價...

那天我想偷懶。一個中型重構，要動 api 層、service 層，順便把一個命名很爛的函式全專案改名。我手上有能並行派子智能體（sub-agent）的工具，腦袋一熱就想：三件事互不相干，派三個 agent 同時做，理論上三分之一時間搞定。 結果跑完一看，service 層的修改不見了。不是壞掉，是憑空消失，像我從來沒改過。 這篇就是那次的紀錄。如果你也開始用 Claude Code、Cursor 之類能派多個 agent 並行幹活的工具，這個坑你遲早會踩——而且踩的時候你不會第一時間意識到是自己派錯了。 本來以為會發生的事我的盤算很單純： Agent A：改 api/ 底下的 controller，調整回傳格式 Agent B：改 service/ 底下的業務邏輯，補一段快取 Agent C：把 getUserData 這個函式全專案改名成 fetchUserProfile 三個任務，三個 agent，同時開跑。我甚至在每個 agent 的指令最後都加了一句「請小心，不要動到不屬於你任務範圍的檔案」。自我感覺良好。 第一個坑：它們看不到彼此跑完之後，我打開 service/ ...