原文標題：The Orchestration Tax

原文作者：Addy Osmani

編譯：Peggy

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

這篇文章提出了一個極具啟發性的概念——「編排稅」。啟動 Agent 的成本很低，只需一個提示或一次點擊；但真正昂貴的是後續環節：檢查結果是否正確、理解其對系統架構的影響、處理不同 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 工作流裡存在一種隱藏的非對稱性。

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

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

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

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

你就是那個單線程資源

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

Python 有全域解譯器鎖，也就是 GIL。你可以創建任意多執行緒，但同一時間只有一個執行緒能執行 Python 字節碼，因為它們都必須先拿到這把鎖。

你就是你的 AI Agent 的 GIL。

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

阿姆達爾定律把這件事說得非常精確：並行化帶來的加速上限，取決於工作中仍然必須串行完成的那一部分。如果你的流程裡有很大一塊無法並行化，那麼無論你投入多少核心，最終都會撞上一個硬上限。

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

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

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

增加 Agent 優化的是那個本來就不是約束的部分。真正的約束是 review 環節，而整個系統的吞吐量，恰好就等於這個環節的吞吐量。

編排稅，就是 Agent 生產能力與你實際能夠合併的內容之間的結構性缺口。它發生在你讓一個單線程資源去管理一個並行系統的時候。

硬扛解決不了結構性上限

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

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

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

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

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

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

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

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

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

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

所以，你必須把自己的注意力當作一種稀缺的串行資源來對待。

你不會在設計一個分佈式系統時完全不考慮瓶頸。那麼，也請給你的大腦同樣的尊重。

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

按照 review 能力擴張 Agent 隊伍，而不是按照 UI 能力擴張。

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

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

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

給任務分類。

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

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

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

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

批量 review。

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

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

只把這把鎖用在判斷上。

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

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

保護你的串行時間。

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

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

編排不是真正的工作。它只是圍繞工作產生的開銷。

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

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

忙碌不等於高產

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

20 個正在運行的 Agent 會給你一種「生產力爆棚」的感覺。儀表板滿滿當當，所有東西都在動。但這種感覺和真正把高質量程式碼合併進主分支之間，已經脫鉤了。

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

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

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

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

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

真正的能力，是圍繞那個無法被克隆、無法被並行化的串行資源來設計系統。

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

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

[原文連結]

歡迎加入律動 BlockBeats 官方社群：

Telegram 訂閱群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方帳號：https://twitter.com/BlockBeatsAsia