編者按：當 AI Agent 越來越便宜、越來越容易調用，軟體開發正進入一個新階段：問題不再是能否啟動更多 Agent，而是人類是否還有足夠的注意力去管理、判斷和合併它們的產出。

這篇文章提出了一個極具啟發性的概念——「編排稅」。啟動 Agent 的成本很低，只需一句 Prompt 或一次點擊；但真正昂貴的是後續環節：檢查結果是否正確、理解它對系統架構的影響、處理不同 Agent 之間的衝突，並最終決定哪些代碼可以進入主分支。這些工作無法簡單地並行化，仍需回歸到同一個串行資源：人的判斷力。

作者將開發者比作 AI Agent 系統中的「GIL」，即限制並發系統最終吞吐量的單線程鎖。多個 Agent 可同時運行，但只要進入架構判斷、代碼審查和衝突合併階段，就必須重新經過開發者的大腦。於是，Agent 越多，不一定意味著產出越高，也可能只是讓待審查的任務隊列更長，讓開發者陷入更頻繁的上下文切換和認知疲勞。

這也是當前 AI 編程工具熱潮中容易被忽略的一點：效率感與真實生產力並不總是一回事。一個滿屏運行的 Agent 儀表板，會製造出「高產」的錯覺；但如果開發者沒有真正理解、審查和整合這些變更，系統最終累積的可能不是生產力，而是技術債和認知債。

因此，本文真正討論的不是「如何使用更多 Agent」，而是「如何圍繞人的注意力重新設計工作流」。在 Agent 時代，關鍵能力不只是會提問、會分派任務，而是知道哪些任務可以交給機器並行處理，哪些任務必須保留給人類判斷；什麼時候應該批量 review，什麼時候應該停止編排，重新專注於一個核心問題。

AI 正在擴大軟體生產的併發能力，但人的注意力仍然是系統中最稀缺、最不可複製的資源。真正成熟的 Agent 工作流程，不是把所有任務都丟給機器，而是像設計生產系統一樣，認真設計自己的注意力架構。

以下為原文：

現在，啟動更多 AI Agent 已經變得很容易。但更多 Agent 同時運行，並不意味著「你」也變多了。你的認知頻寬無法平行化。所有真正用於引導它們、判斷結果、合併修改的判斷力，最終仍然必須經過同一個序列處理器——也就是你自己。

所謂「編排稅」，本質上就是你忘記這一點後所付出的代價。而唯一真正的解法，是像設計任何併發系統一樣，開始設計你自己的注意力。

我之前在 Google I/O 上參加了一場圓桌討論，與 Richard Seroter、Aja Hammerly、Ciera Jaspan 一起談論軟體工程現在的樣子，以及它未來可能如何演變。接近尾聲時，Richard 問我們：開發者聽完之後，最應該帶走並改變的一件事是什麼？

我說出了這幾個月一直反覆思考的一點：感覺自己很忙，絕不等於真的有產出。你可以同時運行 20 個 Agent，並且感覺自己忙得不可開交。但這並不等於你交付了 20 個 Agent 對應的工作量。

在那場對話早些時候，Richard 給這個問題起了一個名字。他說：「你剛才講到的，其實就是編排稅。你不可能在自己的腦子裡成功管理 20 個 Agent。」

他說得完全正確。我想把這個概念更完整地拆開講，因為這不是一個自律問題，而是一個架構問題。

那場圓桌裡有一句我幾乎是隨口說出的話，後來一直縈繞在我腦海裡：運行多個 Agent，並不意味著世界上多了一個你。

人們未計入的非對稱性

在代理工作流中存在一種隱藏的非對稱性。

啟動一個 Agent 非常便宜。你只需要敲一下鍵盤，或者寫一句 Prompt。但完成 Agent 的閉環一點也不便宜。總得有人檢查它返回的結果是否正確，並把它和其他 Agent 改動過的內容重新協調起來。

這個人就是你。而你只有一個。

上個月，我在《你的並行 Agent 上限》中寫過這個問題的一部分，主要討論的是那種環境式焦慮：你不知道哪條並行線程正在悄悄失敗。這篇文章想談的是這種成本背後的結構。

當你開始將 Agent 開發視為一個併發系統時，你就會意識到，人類本身只是這個系統中的一個組件。一個很慢的串行組件。

你就是那個單線程資源

如果你寫過並發代碼，你其實已經具備理解這個問題的直覺。只是你過去把這種直覺用錯了地方。

Python 有全局解釋器鎖，也就是 GIL。你可以建立任意多線程，但同一時間只有一個線程能執行 Python 位元碼，因為它們都必須先取得這把鎖。

你就是你的 AI Agent 的 GIL。

它們都可以同時運行。但只要它們的工作需要真正理解系統架構，或需要解決合併衝突，就必須先拿到這把鎖。而這把鎖只有一把，由你持有。

阿姆達爾定律精確地說明了這一點：並行化帶來的加速上限，取決於工作中仍必須以串行方式完成的部分。如果你的流程中有一大塊無法並行化，那麼無論你投入多少核心，最終都會遇到一個硬性上限。

在 Agent 開發中，這個串行部分就是判斷力。

啟動 8 個 Agent 不會加速你的判斷時間。它只會讓等待你處理的佇列變得更長。

這是性能工程中一個很古老的事實，但很多人依然會為此感到驚訝：優化非瓶頸部分並不會提升整體吞吐量。你只是在瓶頸前面堆積了更多尚未完成的工作。

Agent 的優化針對的是原本並非瓶頸的部分。真正的瓶頸是審核環節，而整個系統的吞吐量，恰好等於該環節的吞吐量。

排稅，就是代理的生產能力與你實際能夠合併的內容之間的結構性缺口。當你讓一個單執行緒資源去管理一個併發系統時，就會發生這種情況。

硬扛解決不了結構性上限

在那場圓桌上，我說過一句話：我從未像現在這樣覺得自己的工具如此高效，但我也從未像現在這樣疲憊。

這兩種感受都完全真實，而且它們來自同一個原因。

這種疲憊有一個非常具體的來源：它就是將一個串行處理器持續壓至 100% 且不留下任何餘量時的感覺。

每次你回頭查看一個已經離開你注意力範圍的 Agent，你都要支付一次上下文切換成本。你必須清空大腦，然後從零開始重新載入另一個語境。

CPU 可以在微秒內完成這件事，即便如此，架構師仍會盡量避免頻繁切換。而你要花幾分鐘才能完成，而且永遠無法完美恢復上下文。

5 個 Agent 並不是將 1 倍工作量重複 5 次。它是 5 次冷啟動式的上下文重載，再加上一個在後台持續運行的大腦進程，不停擔心你現在到底該去檢查哪個 Agent。

你不能靠「更努力」來解決一個結構性限制。這筆稅總是要付的。

如果你試圖硬撐，它最終會以另一種形式出現：要麼是代碼審查變得越來越淺，要麼是你進入一種「認知投降」狀態——因為形成自己的判斷太消耗注意力，你乾脆直接接受 Agent 寫出來的代碼。

你 either 主動支付這筆稅，either 任由它在暗處慢慢摧毀你對自己系統的理解。

像設計系統一樣設計你的注意力

因此，你必須將自己的注意力視為一種稀缺的串行資源。

你在設計一個分散式系統時，不會完全忽略瓶頸；請同樣尊重你的大腦。

以下是一些對我來說真正有效的方法：

一個良好的併發系統會使用反壓機制，避免佇列無限增長。生產者需減慢速度，以匹配消費者處理能力。

你的 Agent 數量就是生產者，你的 review 能力就是消費者。正確的並行 Agent 數量，應該是你能夠認真完成程式碼 review 的數量。對大多數人來說，這通常只是一個很低的個位數。

AI 工具當然會很樂意讓你啟動 20 個 Agent，但那只是一個 UI 功能，不代表你真的有能力管理它們。

當 Richard 問我如何處理這件事時，我提到過這個方法。我會把任務分成兩堆。

第一堆工作是相對獨立的，我願意交給在雲端後台運行的 Agent。這些任務可以異步執行，通常只需我在最後關頭做一次把關。

第二堆是複雜任務，真正的工作本身就是判斷。例如一個很奇怪的 bug，或一次架構設計。

最大的錯誤，就是試圖將第二類任務也並行化。並行處理多個複雜任務，並不會擴大你的產出，只會讓那把鎖被反覆爭搶，最終所有結果都會變差。

每次上下文切換都會讓你付出很高的成本。一次性坐下來 review 4 個 Agent 的結果，要比先看一個、去做別的事、再冷啟動回來繼續看另一個便宜得多。

給 Agent 更長的牽引繩。讓工作稍微累積一點，然後把它們作為一個批次來處理。

不要把你的大腦浪費在機器可以自行驗證的事情上。讓 Agent 寫出能通過的測試，或者生成截圖。

讓它們自己證明那 80% 聊無趣但可驗證的部分。這樣，你稀缺的注意力只需花在真正需要人類判斷的 20% 上。

瓶頸需要你最專注的時間，而不是你在幾次 Agent 檢查之間剩餘的碎片時間。

有時候，最高槓桿的動作反而是完全停止編排：關掉那台塞滿 Agent 的電腦，只專注思考一個問題，並在整個過程中牢牢持有那把鎖。

排程並非真正的工作，它只是圍繞工作產生的開銷。

Aja 指出，架構能力現在已經成為最緊迫的技能：你需要知道什麼任務適合交給一個 Agent，什麼任務對它來說太大了。

我還想補充一點：你自己也是這個系統中的一個組件。你的注意力有一個已知的、很低的串行吞吐量。系統要麼尊重這個數字，要麼就會透過悄悄降低你的標準來繞過它。

忙碌不等於高產

這一點非常重要，因為這種失敗模式對你本人來說幾乎是不可見的。

20 個正在運行的 Agent 會讓你產生一種「生產力爆棚」的感覺。儀表板塞得滿滿的，所有東西都在運轉。但這種感覺與真正將高質量代碼合併到主分支之間，已經脫鉤了。

你可以忙到極限，卻幾乎沒有真正產出。從內部體驗上看，這兩者幾乎一模一樣。

Ciera 提到了 Margaret-Anne Storey 關於債務的研究。我們聊到了技術債，也聊到了認知債。

未支付的編排稅，會讓你同時累積這兩種債務。

你合併了自己沒有認真讀過的東西。你對代碼庫的心智模型徹底過時。這些問題今天不會出現在儀表板上。它們會在生產環境出現故障時顯現出來——那時你看著系統，突然意識到自己已經不知道它到底是怎麼運行的了。

因此，真正的結論是：啟動 Agent 不是能力。任何人都可以運行 20 個。

真正的能力，是圍繞那個無法被複製、無法被平行化的序列資源來設計系統。

這個資源，就是你的注意力。

像設計任何生產環境中依賴的關鍵組件一樣，去設計它。