AI agent 變成團隊之後，開發者真正要學的是交接

以前我們問 AI 會不會寫 code。

現在問題變得比較麻煩：如果你同時開三個 agent，一個查 repo，一個改功能，一個幫你 review，你怎麼知道它們沒有把事情做歪？

這不是很遠的想像。coding agent 正在從「一個聊天框裡的助手」變成「主 agent 協調多個 subagent」的工作流。聽起來很像終於有了一支廉價工程團隊。但我覺得這個比喻很危險。

Subagent 最有價值的地方，不是讓人幻想有一群免費工程師，而是替工作建立邊界。它可以把搜尋、讀 log、掃文件、探索模組這些容易污染主線 context 的任務隔離出去。它可以用不同 prompt、不同工具權限、不同模型成本，去處理一個比較窄的問題。

但邊界不是工具自己會長出來的。邊界要有人寫。

平行化會放大交接問題

一個 agent 工作時，混亂通常還看得見。它讀了哪些檔案、改了哪些地方、卡在哪裡，你大概可以沿著對話往回找。

多個 agent 平行工作時，事情就不一樣了。

假設你讓一個 agent 改登入流程，另一個 agent 改資料庫 schema，第三個 agent 補測試。表面上很合理，工作可以同時跑。但如果登入流程其實依賴新的 schema，測試 agent 又不知道前兩個 agent 改了哪些假設，最後很可能產生三份各自看起來合理、合在一起卻很難收拾的結果。

這也是為什麼我不太相信「多開 agent 就會自動變快」這種說法。平行化本來就不是免費的。人類團隊如此，AI agent 也一樣。

真正省時間的不是多派幾個 worker，而是任務切得夠乾淨。哪些檔案可以改、哪些只能讀、輸入資料在哪裡、輸出要長什麼樣子、驗收標準是什麼、做不下去時要停下來回報什麼。這些東西如果沒有寫清楚，subagent 只是在幫你把不清楚的需求複製成更多版本。

交接物不是聊天紀錄，而是 spec

很多人用 AI coding tool 的方式，還是把所有脈絡塞在聊天裡。前面講過的限制、臨時做出的決定、某個檔案不能碰、某個測試暫時壞掉，全都存在對話紀錄裡。

這在單一 session 裡勉強能用。一旦開始用 subagent，就很容易斷掉。

比較穩的做法，是把重要決策寫成檔案。可能是一份很短的 PRD，也可能是一個 task spec，甚至只是 repo 裡的 implementation note。重點不是格式漂亮，而是它能不能被下一個 agent、下一個人、明天的你讀懂。

一份好的交接 spec 至少要說清楚幾件事：

• 這次任務真正要完成什麼，不包含什麼。

• 需要讀哪些檔案或資料，哪些只是背景。

• 可以修改的範圍在哪裡，不能碰的地方在哪裡。

• 輸出要是 patch、分析報告、測試結果，還是待確認清單。

• 怎樣算完成，怎樣算應該停下來問人。

這些看起來像專案管理雜事。但在 agent workflow 裡，它們其實是工程介面。

以前我們用 API contract 讓服務之間不要亂接。現在我們也需要 task contract，讓 agent 之間不要亂接。

Subagent 是 context 管理工具，不是人格分身

我看到不少討論會把 subagent 講得很像角色扮演：一個是 architect，一個是 reviewer，一個是 compiler，一個是 tie-breaker。這種說法有時候有用，因為它提醒我們不要把所有責任塞給同一個 prompt。

但更務實地看，subagent 是 context 管理工具。

主對話最珍貴的是方向感。它要知道產品目標、目前進度、哪些決策已經定案、哪些問題還沒解。如果你把一堆 log、搜尋結果、長文件、錯誤輸出全部塞進主對話，主線很快就會變髒。後面再問它做產品判斷時，它可能已經被一堆細節拖走。

Subagent 適合處理這些支線。讓它去讀一坨錯誤 log，回來只交三件事：可能原因、證據、建議下一步。讓它去掃某個模組，回來只交責任邊界和風險點。讓它去比較兩種實作，回來只交 tradeoff，而不是把整段探索過程倒回主線。

這樣用，subagent 很有價值。

反過來，如果只是因為「可以開」就一直開，結果通常不會更聰明，只會更貴。每個 subagent 都要讀 context、消耗 token、產出需要人判斷的東西。它們不是免費背景程序，而是需要管理的計算資源。

Review 不在流程最後

很多團隊會把 review 想成最後一步：agent 先做完，人再看。

這在小任務可以。但任務一大，review 應該前移。

你要在派工之前就決定哪些地方需要人看。比如認證、付款、權限、資料遷移，這些不能等 agent 全部做完才開始想風險。你要先定義測試要跑什麼、哪些 diff 需要人工逐行看、哪些變更超過範圍就必須拆 PR。

AI review 也不能無限制加上去。GitHub Copilot 走向 usage-based billing，code review 也會消耗額度與 CI 類資源，這件事其實是在提醒大家：agentic workflow 不是免費魔法，而是工程成本的一部分。

所以 review gate 要設計，不是憑感覺補一層。

對小團隊來說，我會把規則寫得很直接：

• agent 改超過一定檔案數，先停下來整理摘要，不准直接繼續擴大範圍。

• 涉及 auth、billing、資料刪除，必須有人先看設計再讓 agent 實作。

• subagent 只能負責互斥範圍，不要兩個 agent 同時改同一個責任區。

• 任務完成後，先要求 agent 自己列風險和未驗證假設，再進入人工 review。

這些規則不浪漫，但很有用。

未來稀缺的是把工作說清楚的人

AI agent 變強之後，開發者的價值不會只剩下「親手打字」。這句話很多人都同意。但接下來要補什麼能力，大家常常講得太抽象。

我覺得答案其實很普通：交接。

能不能把模糊需求拆成一個 agent 可以安全處理的小任務。能不能把背景脈絡變成 spec，而不是散落在聊天紀錄裡。能不能決定哪些工作可以平行、哪些一定要串行。能不能看懂 agent 交回來的結果，知道哪裡是證據，哪裡只是它很有自信的猜測。

這些能力以前也重要，只是現在更早暴露出來。

過去一個 junior 工程師如果任務沒拆清楚，可能做了一天才發現方向錯。現在 agent 可能一小時就把錯誤方向展開成十幾個檔案。速度變快之後，模糊不會消失，只會更快變成成本。

所以我不會把未來的開發者想成「prompt 魔法師」。那個畫面太輕了。

比較像 tech lead，但不是只管人。你要管理 context、任務邊界、工具權限、成本預算、review 節點，還要在最後把責任接回來。

AI agent 越像團隊，人的工作越不像下指令。

人的工作是把事情說清楚，讓可以交出去的部分真的交得出去；也要把結果看懂，知道什麼時候該相信，什麼時候該按下停止。