# 策展 · X (Twitter) 🔥🔥🔥🔥🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：Addy Osmani (@addyosmani) · 平台：X (Twitter) · 日期：2026-05-28

> 原始來源：https://x.com/addyosmani/status/2059844244907696186

## 中文摘要

Orchestration Tax 揭示 AI Agent 時代的注意力瓶頸。

**核心問題：Orchestration Tax（編排稅）的本質**
在 Google I/O 的小組討論中，作者與 Richard Seroter、Aja Hammerly 及 Ciera Jaspan 探討了軟體工程的演進。作者指出，雖然啟動多個 AI Agent 非常容易，但這並不代表人類的認知頻寬能同步擴展。人類是整個系統中唯一的「序列處理器」，所有判斷與程式碼合併工作都必須經過大腦。所謂的「編排稅」，就是當你忽略了人類注意力有限，試圖同時管理過多 Agent 時所付出的代價。

**技術瓶頸：人類作為「全域解釋器鎖（GIL）」**
作者以 Python 的「全域解釋器鎖（GIL）」為比喻：即便你可以同時啟動多個執行緒，但涉及架構理解或解決合併衝突時，工作必須取得唯一的鎖，而這個鎖就是你本人。
- 根據「阿姆達爾定律（Amdahl’s Law）」，系統的加速比受限於無法並行化的序列部分。
- 在 Agent 開發中，人類的「判斷力」就是那個無法並行的序列部分。
- 盲目增加 Agent 數量並不會提升判斷速度，只會讓待處理的佇列（Queue）變長，導致瓶頸處的壓力過大。

**結構性限制與認知疲勞**
作者強調，單純的「努力工作」無法解決結構性限制。
- **上下文切換成本**：頻繁在多個 Agent 之間切換，會導致大腦不斷進行「冷重載（Cold Reload）」，這比 CPU 的微秒級切換更耗能且精確度更低。
- **認知崩潰**：當工作量超過負荷，人類會產生「認知投降」，為了應對壓力而草率審查程式碼，甚至直接接受 Agent 的輸出，這會導致技術債與認知債同時累積。

**架構化你的注意力**
為了避免被「忙碌感」欺騙，作者建議將注意力視為稀缺的序列資源進行架構設計：
- **調整生產與消費速率**：Agent 的數量（生產者）應與你的審查速率（消費者）匹配，實施「反壓（Backpressure）」機制，大多數人能同時處理的 Agent 數量應維持在個位數。
- **任務分流**：將任務分為「可委派的隔離工作」與「需要判斷力的複雜任務」。切勿嘗試並行處理複雜任務，那只會導致思緒混亂。
- **批次審查**：減少切換頻率，讓 Agent 的工作累積到一定程度後再進行批次審查。
- **自動化驗證**：讓 Agent 自行產生測試或螢幕截圖，將人類寶貴的注意力留給那 20% 真正需要判斷的決策。
- **保護序列時間**：有時最高效的策略是停止編排，關閉所有 Agent，專注於解決單一問題。

**結論：真正的技能在於系統設計**
作者總結，啟動 20 個 Agent 並非專業技能，真正的核心能力在於「圍繞著無法複製的序列資源（即你的注意力）」來設計系統。若系統不尊重人類的認知極限，最終將導致你對程式庫的理解完全過時，並在生產環境崩潰時付出慘痛代價。正如 Aja Hammerly 所言，架構能力是當前最重要的技能，而你本身就是該系統中最關鍵的組件。

## 標籤

Agent, 產業趨勢, 其他, Google