安德魯的部落格

這類趨勢報告, 越看越覺得很考驗你的解讀能力… 這也是一個, async agent 的崛起…

2025/07/23

這類趨勢報告, 越看越覺得很考驗你的解讀能力… 這也是一個, async agent 的崛起…

今天要談的是 第七個趨勢預測: (7) The rise of asynchronous agent work

–

如果只看報告的敘述，短短兩段文字，其實沒有帶到太多資訊。我看報告的方式就像是算命，報告告訴你未來會發生什麼事，而我會自己推敲試著解讀現在到未來的因果關係。如果想通了，那我就有判斷的能力了。因此這份趨勢報告，我每一段都試著用這樣角度解讀，在沒人可以給我標準答案的時候，我還能靠自己的判斷能力來評估一下可信度。

非同步 (async) 的作業模式，其實不管有沒有 AI 都是必然的結果啊。A16Z 把這發展趨勢寫在這裡，要點出的重點到底是什麼? 我覺得是 AI 的進步會 “如何” 影響我們使用工具的方法。

我還是從 vibe coding 當案例來切入這題吧，把實際的案例套進去之後, 你會發現你突然就能想通報告想表達的是什麼了。AI 發展至此，幻覺仍然無法完全避免，因此各種 AI 強化的工作流程，免不了在關鍵環節需要跟 “真人” 互動、協作、確認結果。這些互動，最吃 “真人” 的時間，這是最根本的瓶頸，人的專注時間是無法 scale 的..

因此，優化的方向就兩個極端，一個是加速，讓互動等待的時間越來越短；另一個是批次，讓處理流程不要是線性的，可以累積到一個程度一次確認。而隨著思維鏈，推理模型的發展，回應時間其實越來越長，但是相對地模型能力也越來越強，可以獨立處理的任務越來越大，也因此開始可以長時間獨立作業了 (例如: 有些 Agent 已經可以不需要人為介入，獨自處理超過 30min 的任務了)

模型能力的進步，朝向推理時間越來越長，思維鏈的過程越來越長，能負責的任務規模越來越大，Agent 的互動模式越來越往非同步發展。最近在幾場研討會，分別看到保哥跟董大偉老師各別 Demo 他們團隊的運作流程，不約而同的都是在 Azure DevOps 上面，整合各種不同身分的 Agent ，來完成日常任務:

兩位都示範了這樣的情境:

  1. 在 Azure DevOps 建立了 task, 在裡面用詳細的 prompt 交代了要改什麼 code..

  2. Create Task 的 webhook 觸發了 Agent 來接手任務, 這 Agent 在 Sandbox Pull Code 下來解 issue, 改完 code 跑完 test, 發 PR , 並且更新 issue, 花費 15 ~ 30 minutes

  3. 同時間可能有多個 issue 被開出來, 在雲端有多個 agent 同時在執行任務, 隔天上班時負責人逐條 issue 確認能否 merge PR, 若不行就再重複一次, 直到完成為止。

這整個工作流，比起 AI coding IDE ( ex: Cursor ) 來說，更像你把開發任務 “外包” 了。高度互動的 AI coding IDE 比較像是 Pair Programming, 而模型能力越來越強，強到能獨立作業，互動模式就會變成這樣了。

我認為，與其說 “非同步” 是個趨勢，更貼切的說法應該是 “非同步” 會是未來必然的互動方式。在這必然的發展上，真正重要的不是 IDE + Agent, 而是像 GitHub, Azure DevOps 這樣的協作平台 + Agent 的組合。唯有有非同步協作的能力，你才 “養” 的起 (這裡的 “養” 不是指成本，而是指能否讓多個 Agent 有效率的協作) 多個 Agent 不眠不休替你工作。

所以，想通這趨勢是怎麼變化的，我歸納幾個關鍵點給大家參考:

  1. 模型能力越強，你越需要一個外包任務給 Agent 的管理系統 ( 就是 issue + git 啊 )，集中管理文件、程式碼、任務。這管理系統讓這非同步的協作模式可以有效率運行

  2. 工作方式改變，你要能累積足夠的 context 讓 Agent 能夠長時間獨立作業，資訊在傳遞或指派之前都要先儲存 （文件化），因此前兩天聊到的 “ docs are evolving” 就是必要條件了，所有任務都是先更新文件，再要求按照文件執行

  3. 降低互動的頻率, 最主要就是 review AI 產出, 不斷修正的往返次數。預先寫好合適的 coding guideline (預防 AI 寫出你不想要的 code)，盡可能在前期的階段 (建立需求) 就做好介面設計以及準備好 test case (寫這通常很快，用互動的方式當場驗證)，累積越多這類能讓 AI 自己檢驗自己的素材，你在非同步作業階段得到的產出物品執會越好。

  4. 互動式的工具仍有存在價值，但是會越來越轉移到前後階段，前段在修飾需求文件的細節，後段在修正 agent 沒做好的小 bug 收尾。

當你能選擇時，優先選擇非同步的協作模式。除了最節省你的互動時間之外，非同步是最能 scale 的工作模式。你可以一次開出 10 x issues 讓 10 個 agent 同時工作，但是你難以一次跟 10 個 agent 進行 pair programming. 前面的 (1) (2) (3) 有沒有做好，就是你將來處理能力能不能 scale out 的關鍵

而這演進不會一夜之間發生，但是已經慢慢在進行了。就看這兩年 (尤其是 developer) 大家常用的工具跟使用方式變化，就能察覺這趨勢:

  1. ChatGPT (GPT3.5 年代) 一開始什麼都是 “聊天”，完全互動的介面

  2. ChatGPT Research, 開始要花上十幾分鐘, 因此也開始有了 Task 的通知 & 排程機制

  3. GitHub Copilot / Cursor, 開始出現互動的 AI coding IDE

  4. 開始出現 Claude Code, OpenAI Codex 等等各種 CLI 的 coding agent

  5. ( 有了 CLI, 這些 coding agent 開始能被放在各種 Batch 作業的場合, 例如 create issue 的 callback )

逐漸的，每個團隊的開發平台 ( ex: Azure DevOps , or GitHub ) 開始會變成 “軟體開發” 的外包中心。從最基本的版控 ( 工廠生產內容的倉庫 )，變成需求管理 ( 下單與出貨管理 )，交付的管理 ( CI / CD, 就像是工廠的物流一樣 )，到外包人力的資源調度 ( Agent Auto Scaling, 有需求需要處理，馬上就能 allocate Agent 起來接單，處理完畢後就能釋放資源 )

這不就是未來理想的樣貌嗎? 這段原文沒有給圖，我用先前在 Generative AI 年會，我老闆的一頁投影片當作結尾，在闡述的就是這樣的場景。

如果你認同這樣的想法，其實現在就要開始準備，往主要發展路線移動了。





Facebook Pages