深度 深度專欄 #24 · 2026年8月19日
八月中，三則推文接起來像是一個新工序被發現了：交代一件事變便宜：Anthropic 的產品長說，現在四句話就夠，年初還得自己搭一套鷹架。機器跑得變久：一位資深開發者的作息表裡，agent 整夜跑，他一天只進場兩次審。於是工具跟著移動：同一位開發者的新創，把產品的招牌功能做成「一眼掃過所有工作視窗、找出哪個需要你」。推論很順：卡住人的不再是「怎麼跟它講」，而是「先看哪一個」。當時我們認為證據不夠，只把它記下來觀察、沒有正式採信，理由寫得很白：三則推文、兩位發言者都有利益關係、零量測，而最該有的那個數字（跑了一整晚的東西，隔天有多少真的能用）完全不存在。
那個數字現在有了。而它一補上，方向對了，但量錯了對象：真正該盯的是每一份產出等多久才有人看，不是同時開著幾個視窗；護城河的判斷則直接被推翻。本篇的路線：先說清楚「注意力路由」到底是哪一道工序；再用三組獨立的大樣本量測依序回答三個問題：到底幾個人在並行、產出隔天有多少能用、人的注意力花在哪；然後把「等待」這件事拆成兩半，這是本篇的核心；最後處理一個時序問題：模型商早就進場了，而且他們選的不是這條路。
這篇比日報上的同一條多給了什麼？三件，都是具體的。第一，「等人來看」和「看」被拆成兩個數字。在一份 810 萬筆合併請求（工程師寫完一批改動、送出去等人審核、通過才併進正式版本的單位）的資料集裡，AI 寫的程式碼平均要等大約 1,050 分鐘才有人開始看，人寫的只等大約 200 分鐘；但一旦有人開始看，AI 的那份平均 194 分鐘就看完，人寫的要 252 分鐘。貴的是排隊，不是審查。這是那句「注意力是驗證的前置成本」第一次拿到價目表。第二，我們拿「這只是因為 AI 寫的檔案比較大」去攻這個判斷，它沒有全撐住。AI 的合併請求確實大 2.6 倍，而大檔案本來就等更久，所以那五倍裡有多少屬於注意力、多少屬於體積，這份資料沒有拆，本篇也拆不出來。這個洞我們寫在正文裡，不藏在附註。第三，「模型商吃不掉這一層」這句話，在它被寫下的當天就已經不成立。OpenAI 的桌面版 Codex 在二月二日上線時就自稱是 agent 的「指揮中心」；Anthropic 的 Claude Code 更新紀錄裡，那個列出「有幾個背景 agent 正在等你輸入」的畫面不但已經出貨，還已經在修它的狀態顯示錯誤了。會有錯誤可修，代表它在使用者手上待得夠久。
並存 ⇄
這個詞需要解釋，因為它指的不是任何一個既有的東西。
問題是這樣長出來的。傳統上人和軟體的關係是同步的：你打一個指令，它回一個結果，你在場。這種形態下沒有「該先看哪一個」的問題，因為只有一個，而且你正看著它。當 agent 可以在你睡覺時跑八小時，兩件事同時變了：一是產出的時間點和你的清醒時間脫鉤，二是同時在跑的委派不只一件。於是在「決定要不要委派」和「驗證它做得對不對」之間，長出了一道以前不存在的工序：在有限的一次進場裡，先分辨出哪一個需要我。
它為什麼是一道獨立的工序，而不是驗證的一部分。因為它的成本結構完全不同。驗證的成本隨任務難度走：難的東西查起來久。而找出「該看哪一個」的成本隨同時在跑的件數走，跟每一件的難度無關。兩者也在不同的地方失效：驗證失效是看錯（放行了不該放行的東西），路由失效是根本沒看（東西躺在那裡等，或者被略過）。這個區別是本篇後面所有判斷的地基，先記著。
邊界在哪。這道工序只有在委派數 ≥2 且產出不同步時才存在。如果你一次只跑一個 agent 並在旁邊看著，它的成本是零。所以第一個該問的實證問題就是：到底有多少人真的處在那個狀態？
六月二十五日，一組研究者（Drew Johnston、David Holtz、Alex Martin Richmond、Christopher Ong、Prasanna Tambe、Aaron Chatterji）發表了對 OpenAI Codex 使用資料的大規模分析。這份研究之所以關鍵，是它把使用者切成三群分開看：OpenAI 內部員工、外部組織帳號用戶、外部個人帳號用戶。摘要裡的那句總數是：「超過 10% 的用戶在每週的某個時點同時管理三個以上的 Codex agent」。
但拆開來看，這個 10% 是三群平均出來的，而三群的形狀差得極遠。在六月十一日前一週的讀數裡：
個人帳號那一群還要打個折：樣本只涵蓋同意把查詢用於訓練的使用者，不見得代表全體個人用戶。
也就是說，「一支 agent 艦隊」這個畫面是真的，但它是模型公司自己員工的日常，不是市場的日常。市場的中位數是零到二。這正好對上我們手上唯一的實測讀數：一位把 agent 排進作息表、還在創辦這類工具公司的資深開發者，自報的常態並行數是「至少 2」。他不是保守，他是外部使用者裡的上緣。
這件事值得停一秒，因為它的方向對本篇的結論不利卻更可信：這份資料是 OpenAI 自己的，作者群裡有該公司的首席經濟學家，要說有動機，動機是把採用畫得更深而不是更淺。而它給出的數字是「三分之二的組織用戶完全不並行」。當一個資料源的偏誤方向和它報出來的結論相反時，那個結論比較站得住。
不過同一份研究裡，另一個數字的方向完全相反，而且它才是本篇後面的引擎：送出「一個有經驗的人要做八小時以上」這種任務的用戶佔比，從 2.1% 升到 25.6%。並行沒有普及，但單件變長普及了。四分之一的用戶現在會丟出一件人類要做一整天的事。
把兩個數字並排，形狀就出來了：多數人不是同時盯八個視窗，而是丟出一件很大的東西，然後離開。這對後面很重要，因為「離開之後那個東西怎麼辦」，才是真正的問題。
當時我們寫下的話是：沒有「夜跑 agent 產出的隔日採用率」，「注意力是瓶頸」就只是一個聽起來對的故事。
最接近的公開代理數字來自 LinearB 的 2026 年工程基準報告，母體是 810 萬筆合併請求、約 4,800 個工程團隊、42 個國家。它把合併請求分成三類：完全人寫的、人寫但 AI 參與塑形的、以及完全由 agent 產生的。「接受」的定義是三十天內被合併。讀數是：
人工撰寫的合併請求，84.4% 在三十天內被合併；AI 參與的只有 32.7%。
先說這個數字不能拿來做什麼。它不是「AI 寫的程式碼三分之二是壞的」：合併請求沒被合併的原因很多，重複、被更好的做法取代、需求變了、開的人自己放棄了都算。它也不是產業常數：LinearB 賣的正是改善這條流程的工具，資料集是自家客戶的，而且它沒有公開「怎麼判定一筆合併請求算 AI 參與」。同一個廠商、同一份資料裡的相對落差可以用，絕對水準不可以搬走當常識。
但即使打完這些折，剩下的東西還是硬的：在同一套判定標準、同一批團隊裡，AI 產出的東西進到主線的機率不到人寫的一半。錨定那條判斷時最想要的那個數量級（「跑了一晚的東西隔天有多少能用」），答案是「比你以為的少很多」，而且這是第一次有八位數規模的樣本能這樣講。
現在講本篇真正的增量。同一份報告把「一筆合併請求從開出來到合併」的時間拆成兩段，而這個拆法直接命中了前面說的那道工序。
第一段叫「等人來看」（業界術語是 pickup time）：從開出來，到第一個人真的開始看它，中間躺著的時間。第二段叫「看」：從有人開始看，到看完給出結論。讀數是：
| 等人來看 | 開始看之後 | 三十天內合併率 | |
|---|---|---|---|
| 人寫的 | 約 200 分鐘 | 約 252 分鐘 | 84.4% |
| AI 參與的 | 約 1,050 分鐘 | 約 194 分鐘 | 32.7% |
兩段往相反方向動。等人來看的時間變成大約 5.25 倍；但一旦有人坐下來看，AI 那份反而比人寫的快（194 對 252 分鐘）。
這個形狀是本篇最重要的一張圖。它說的是：人的審查能力沒有變差，審查本身甚至變輕了，大概因為 AI 產出的東西結構比較整齊。這一點另有實驗支持：六月一份預印本在 64 次對照執行上發現，把交辦契約寫明對「正確性」沒有影響，因為在那個難度帶本來就全對；真正被改善的是看得懂它做了什麼，變更檔案清單的出現率從 7% 跳到 93%。要打一個折：那 64 次驗收與可審查性評分全部是由 LLM 審查者做的，不是人；「人真的比較好審」這件事本身還沒有被人驗證過。真正爆掉的是前面那一段：東西產出來之後、有人願意分神給它之前的那段空白。
而那段空白，正是前面定義的那道工序。所以：「注意力是驗證的前置成本」這句話，現在有價目表了。在這份資料裡，那個前置成本是審查本身的五倍以上，而且是唯一在惡化的一段。
我們拿最明顯的反駁去攻它：AI 的合併請求比較大，而大的東西本來就等更久。
這個反駁有據。同一份報告裡，第 75 百分位的 AI 參與合併請求是 408 行，人寫的是 157 行，是 2.6 倍。而合併請求的體積和被撿起來的速度是強相關的，有分析指出小的合併請求被撿起來的速度快到二十倍，Google 內部的經驗法則也認為審查品質在 200 行以上開始明顯下降。人看到一個 400 行的東西會下意識往後排，這不需要任何關於 agent 的理論就能解釋。
這個攻擊我們沒能擋掉。LinearB 沒有在控制體積之後重算等待時間，我們也沒有原始資料可以自己算。所以那 5.25 倍裡有多少屬於「同時在跑的件數太多、注意力分不過來」、多少純粹屬於「這包東西太大我等一下再看」，本篇無法拆開。
唯一的線索指向兩者都有份，但它也只是線索：同一份報告的三分類裡，完全由 agent 產生的合併請求只有約 290 行，比 AI 參與的 408 行小。如果體積是唯一的驅動力，全自動那類應該等得比較短。但報告沒有單獨公布那一類的等待時間，所以這只是一個沒被驗證的推測，不是證據。這是本篇最大的未解，也是下一輪該去要的東西。
第二個獨立來源把這件事推到更難看的地方。Faros AI 的 2026 年工程報告母體是 22,000 名開發者、4,000 多個團隊的兩年遙測資料，方法是拿每個組織自己在 AI 採用最低期和最高期之間的指標變化來比。讀數：
那個 31.3% 有一個沒公開的地方：Faros 沒有交代它怎麼算「經過審查」，自動化檢查或機器人核可算不算、母體含不含機器開的改動，都不知道。所以它離「完全沒有人看過」有多近，只能保守讀。
這份資料的方法有它自己的問題，必須先講：組織內部「低採用期對高採用期」是一個時間前後比，兩年之間變的不只有 AI：團隊擴編、流程改版、人員流動都混在裡面。所以它的幅度不能當精確值。但它和 LinearB 是不同的公司、不同的客戶群、不同的量測方法，兩邊在「等第一次審查的時間大幅拉長、審查本身不是瓶頸」這個方向上一致，這種一致比任何單一數字更有分量。
真正該注意的是那個 31.3%。把三個數擺在一起：三分之一的東西沒人審就進去了、AI 產出只有三分之一進得去、等第一次審查的時間翻了好幾倍。畫面就不是「注意力被分配得不夠好」，是「注意力根本不夠，而系統找到的均衡解是丟棄」。而且它從兩頭洩：一頭是不看就放行（風險被推到上線之後，事故對合併請求的比率上升 242.7% 就掛在這裡；另有一份 182 個真實專案的長期追蹤研究，量到專案的免審率每上升 10 個百分點，agent 貢獻的後續維護負擔約上升 6%），另一頭是永遠沒人來撿（那沒被合併的三分之二裡，有多少是躺到過期的，資料沒說，但它一定不是零）。
這個診斷比「找不到該看的那一個」嚴重一級。「先看哪一個」預設了一個所有東西最終都會被看的世界，只是順序待定。實測的世界裡，大部分產出根本不會被看。順序問題和容量問題需要的解法不一樣：順序問題要的是排序介面，容量問題要的是減少需要人看的東西。
當初只把它記下來觀察時，我們寫下的分岔是二選一：如果約束真在注意力這一層，工具會收斂到預覽與通知面。Superlogical 押這邊：這家新創的創辦人就是開場那位資深開發者，它的產品預覽把招牌功能做成三指下滑即時預覽所有工作分頁，自陳目標是讓需要你注意的那個 session 容易被找到。如果仍在執行層，工具會收斂到隔離環境與車隊基礎設施。Cursor 押這邊：這是另一家做編碼 agent 工具的公司，它的官方更新紀錄講得很明白，要讓團隊「跑一支端到端處理任務的平行 agent 車隊」，為此建了可配置的開發環境、跨專案工作區、背景隔離分支。
查完之後，這個二選一有兩個問題。
第一，「模型商吃不掉桌面級即時介面」這句話，寫下時已經不成立了。當時的理由是：模型公司吃得掉鷹架，吃不掉桌面級的即時介面，而 Superlogical 自陳的瓶頸正是找不到夠好的原生介面工程師，不是模型。但時序對不上：
最後那一條比前兩條更有說服力：會有狀態顯示的錯誤可修，代表這個功能已經在使用者手上待得夠久、被用得夠兇。一個還在概念影片階段的功能不會有這種錯誤。所以那個「離模型商最遠的一塊」的判斷，在寫下它的時候，兩家最大的模型公司都已經在裡面了。（要公平講：出貨不等於做得好。Superlogical 押的是即時算繪品質與桌面級互動，一行更新紀錄證明不了體驗等價。所以正確的收窄是：這一層不再是模型商夠不到的地方，但誰做得好還沒裁。）
第二，也更重要：這根本不是二選一，因為市場上還有第三條路，而且它最早開跑。
回到那個 31.3% 沒人審就合併的數字。它有兩種讀法：一種是放棄，另一種是那些東西被審了，只是審的不是人。
第三條路的證據不但存在，而且比前兩條都早。2025 年 9 月，OpenAI 的 Thibault Sottiaux 在一次官方 podcast 上談自家程式碼審查機器人的設計動機，他的原話是：
「我們開始注意到，隨著需要被審查的程式碼量增加，我們最大的瓶頸就是團隊裡的人單純必須做的審查量本身。」
那是十一個月前，比本篇這條判斷的三個資料點早了將近一年。而他們的解法不是給人做一個更好的儀表板，是把審查這件事也委派出去：做一個窄範圍的高信號審查模式，不只看差異，而是去理解這筆改動背後的意圖與契約，再回頭驗證程式碼有沒有真的實現那個意圖。他們形容內部上線後「相當成功，壞掉的時候大家會不爽，因為感覺失去了那張安全網」。
所以正確的分岔圖是三條路，各自假設瓶頸在不同的地方：
1. 注意力面：瓶頸是人分不清該看哪一個。解法是排序、預覽、通知。
2. 執行基礎設施：瓶頸是 agent 跑起來的環境成本。解法是隔離環境、跨專案、快取、治理。
3. 把審查也委派掉：瓶頸是人的審查總量。解法是讓另一個 agent 先審，人只看它舉手的地方。
前面三組量測對這三條路並不中立。「等第一次審查的時間翻了五倍、審查本身反而變快、三分之一沒人審就進去」這個組合，指向的是容量不足而不是順序錯亂。而排序介面解不了容量問題。把八件事排好序，人還是只看得完兩件。第三條路是唯一直接動到容量的。
不過第三條路自己也有兩個沒解的問題，不能當定論：一是那則自述是廠商講自家內部採用，沒有外部量測；二是機器審查器自己也會產出需要人看的東西：它舉的手也是一種要排隊的東西。它到底是消滅了工作量，還是把工作量換了一種形狀，目前沒有資料能回答。
還有一種需要人的情況，這三條路全都不處理：agent 走到一半卡在一個只有人能點的按鈕上。八月九、十兩日，Flask 的作者連兩天記錄同一種故障：密碼管理器的瀏覽器擴充、套件發布的信任設定，都是為坐在瀏覽器前的人設計的，agent 只能走到門口，剩下的「要我幫忙點完」。這類中斷不是「該先看哪一個」的排序問題，也不是審查容量問題，是流程根本走不完。它需要的是第四種東西：把授權介面改成機器也能走完。
在評估 agent 平台的人：採購清單上多一條，但問法要比常見的那條精確。最常見的問法是「它怎麼告訴我哪個任務需要人」，但這個問法只涵蓋了三條路裡的第一條。改成問三件事：(a) 它怎麼減少需要人看的產出總量（有沒有內建審查層、它的誤報率多少）；(b) 產出等待人看的時間，你們的客戶讀數是多少；(c) 沒被人看就進到主線的比例是多少。第三個問題是最誠實的一個，因為它量的是這套系統實際上放棄了多少監督，而多數廠商不會主動報。
在管一支工程團隊的人：本篇最可操作的一句話是：你的交付上限已經不在寫的那一端了。如果你只盯每人吞吐（Faros 那份資料裡是 +33.7%），你會看到一組漂亮的數字，而同一批團隊的審查等待中位數上升了 156.6%、三分之一的改動沒人看過就進去了、事故對改動的比率上升了 242.7%。具體的排班含意也很直接：如果 agent 在夜裡跑，早上第一件事把夜間產出清完的人，得是一個指名的人，不能靠自願，不然那些產出就會積成無人認領的存貨。那 32.7% 的合併率裡，有一部分就是這樣來的。
在做這個賽道的人：「注意力面離模型商最遠」這個投資論點需要修正。兩家最大的模型公司都已經在這一層出貨，其中一家已經在修它的邊角錯誤。剩下的可辯護空間不在「有沒有這個畫面」，而在兩個地方：跨廠牌（模型商只會做自家 agent 的畫面，你的八件事跑在三家工具上）、以及容量而非順序（做排序的天花板是人一次進場能看多少，做削減的天花板高一個量級）。至於第三條路：如果真正的瓶頸是容量，那麼把審查也委派掉這個方向，已經被最大的模型公司用自家內部工具背書過，而且比這三組量測早了十一個月；但它到目前為止只有廠商自評，沒有外部量測。而機器審查器自己也會產出需要人看的東西，所以「它究竟是消滅了工作量，還是只把工作量換了一種形狀」，是這條路的估值上還空著的一格。
在為自己買工具的個人開發者：多數人不是同時盯著八個視窗（外部用戶三分之二完全不並行）。更可能的情況是：丟出一件大東西，離開，回來面對一包很大的產出。那麼對你有價值的不是儀表板，是讓那包東西小一點、結構清楚一點。這也是那份契約實驗量到的：把交辦寫清楚買不到更高的正確率（那個難度帶本來就全對），買到的是你事後看得懂它做了什麼，代價是多花 13% 的 token 和 38% 的等待時間。對照前面那個「AI 的東西大 2.6 倍、等得久 5 倍」，這是一筆划算的交換。只是要記得，那份實驗的評分者是模型不是人。
「agent 讓交代變便宜、跑得變久，於是人的瓶頸從指令設計移到注意力」這個方向，被三組互相獨立的大樣本量測支持：等第一次審查的時間在兩份不同廠商的資料裡都大幅拉長（LinearB 的 810 萬筆合併請求裡是 200 分鐘變 1,050 分鐘，Faros 的兩年遙測裡是中位數上升 156.6%），而審查本身沒有變慢、甚至變快。但這個判斷的單位錯了，而且它自己的護城河子命題已經被推翻。單位：真正的排隊物件不是「session」而是產出，所以真正該看的關鍵數字，是合併請求的等待時間，不是同時開著的視窗數，而並行本身並未普及（外部組織用戶 67.4%、同意分享查詢的那群外部個人用戶 63.9% 完全不並行，普及的是單件變長：八小時級任務的用戶佔比 2.1%→25.6%）。護城河：模型商吃不掉這一層的說法，在該判斷寫下時已有反例（OpenAI 桌面版 Codex 2026-02 上線即自稱 agent 指揮中心；Anthropic 的背景 agent「需要輸入」計數已出貨並在修錯誤）。更關鍵的是，這場競爭是三條路不是兩條（注意力面、執行基礎設施、以及把審查本身也委派掉），而三組量測共同指向的是容量不足（31.3% 沒經任何審查就合併、AI 產出三十天合併率 32.7%）而非順序錯亂，這對只做排序的路線不利。本判斷最大的未解是：AI 產出等待時間的 5.25 倍裡，有多少屬於注意力、多少屬於體積（AI 的改動大 2.6 倍，而大改動本來就等更久），現有公開資料無法拆開。
什麼會推翻它：第一，任何一份控制了改動體積之後重算等待時間的資料：若體積控制後 AI 產出的等待差距收斂到接近零，本篇「注意力是獨立工序且已被計價」的核心讀法作廢，整條判斷退回「聽起來對、但還沒被證實」的狀態。這是最該去要的一份資料，也是本篇最脆的一節。第二，若「產出等第一次審查的時間」在後續年度基準裡回落（LinearB 與 Faros 皆為年度發布，下一版即為觀察窗；此為本報自設的觀察窗，非任一方承諾的時點），則瓶頸屬過渡性擁塞而非結構性約束，本條降級。第三，若第三條路（委派審查）出現外部量測顯示它沒有降低人的審查總量、只是把它換了形狀，則「容量勝過順序」的推論失效，三條路回到平手。第四，若外部組織用戶的並行率在後續讀數中大幅上升（本報自設門檻：完全不並行者跌破五成），則「並行未普及」的判斷翻轉，排序介面的市場遠比本篇估的大。第五，若模型商把注意力面做成僅限自家 agent 的封閉功能且不開放跨廠牌，則「跨廠牌是剩餘可辯護空間」的判斷坐實；反之若任一模型商開放跨廠牌 session 匯入，這塊空間也關上。