> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/zh-hant/2026/w33-five-steps-toward-the-future-work-paradigm-seen-through-agent-teams.md).

# W33-從 Agent Team 看未來工作範式的 5 個臺階

最近，Claude Code 負責人 Boris Cherny 發佈了一張名為 [Steps of AI Adoption](https://docs.google.com/document/d/1R91ayvj7uvlxgNi--__2-Bf3w8x5r1nF-xIBN7ds8Ns/edit) 的表格。

他在[原帖](https://x.com/bcherny/status/2077929379661844559)裡提到一個反覆出現的現象。團隊裡有一個人藉助 Claude 獲得了數量級的產出提升，組織裡的其他人卻沒有跟上。

這個觀察很接近我最近的體感。AI 帶來的差距已經不只是工具熟練度的差距。不同的人正在使用完全不同的工作範式。

Boris 把 AI adoption 分成 L0 到 L4 五個等級。更準確地說，這是五種狀態和四次躍遷。我更願意把它理解為未來工作範式的五個臺階。

## 五個臺階

| 層級       | 人的角色    | 工作方式                        | 主要瓶頸     |
| -------- | ------- | --------------------------- | -------- |
| L0 受限    | 旁觀者     | 想用 AI，但真正有能力的模型被擋在工作之外      | 訪問權限     |
| L1 輔助    | 結對者     | 你和一個 Agent 配合，它執行，你逐步檢查     | 人的注意力    |
| L2 並行    | 編排者     | 你同時組織多個 Agent，它們執行和自檢，你驗收結果 | 評審能力     |
| L3 受監督自治 | 管理者的管理者 | 定時任務或事件主動觸發工作，人審批例外         | 信任和決策吞吐量 |
| L4 AI 原生 | 意圖定義者   | 數百或上千個 Agent 按目標運行，人按異常管理   | 價值判斷和治理  |

Boris 在表中給出的 Agent 數量從 0、1、10、100 一直到 1000 以上。這些數字更像數量級，不是升級指標。真正重要的變化是人的角色。

在 L1，人仍然坐在每個任務的駕駛位上。Agent 更像一名速度很快的助手。

到了 L2，人開始設計分工、控制上下文、設置驗收標準。工作過程由多個 Agent 並行推進，人的注意力主要放在結果和例外上。

L3 又跨了一步。任務不再全部由人逐次發起。系統開始監聽事件、按計劃運行、發現問題並主動創建工作。人不再管理每一個 Agent，而是管理 Agent 組成的工作系統。

## 多個 Agent 不等於 Agent Team

過去，我們一直關心怎樣讓單個 Agent 變得更強，怎樣讓它完成更長、更複雜的任務。單個 Agent 的能力總有邊界，於是越來越多人開始同時使用多個 Agent。

Agent 多了，新的問題也隨之出現。單個 Agent 的能力不再是唯一瓶頸，組織方式開始決定整體上限。

如果每項工作仍然要由人選擇入口、整理背景、搬運 Context，再把一個 Agent 的結果交給另一個 Agent，那麼這些 Agent 本質上仍是一組獨立工具。人依然是整個系統裡唯一的 Router，也是事實上的瓶頸。

我理解的 Agent Team 有三個特徵。

第一，每個 Agent 長期負責自己的 Domain。它知道自己應該處理什麼，邊界在哪裡，也知道哪些問題不屬於自己。

第二，一部分協作責任從人轉移給 Agent。它們在明確的責任關係裡完成路由、交接和結果迴流，不再要求人串聯每一個步驟。

第三，人仍在 Team 裡，只是位置發生了變化。人會在方向、事實、選擇、Review 和授權的位置回來，不再盯住全部執行過程。

但當人不再參與每一步，另一個問題會立刻出現。我怎麼知道這支 Team 到底運行得怎麼樣？

所以 Agent Team 還必須能夠被觀察、理解和持續調整。否則我只是從親自調度每個 Agent，變成看不見它們在做什麼。

## 第一次感受到一支 Agent Team

我對 L2 最深的一次體驗來自 Multica。

我最初在 Multica 裡建立了一個 Engineering Squad，用它構建一套連接公司內網代碼託管平臺的 MCP。早期版本裡，Claude 負責策略、拆解和路由，Codex 負責實現，Gemini 負責探索和獨立驗收。我保留產品意圖、優先級、取捨和最終批准。

這個組合第一次給了我很強的團隊感。我把目標和邊界說清楚以後，Leader 會繼續拆分任務，選擇合適的 Agent 完成探索、實現和驗收。只有遇到需要判斷的事情，我才會收到通知，再回到任務裡做決定。

一次任務開始時，兩份材料對接口風格和鑑權方式的描述互相衝突。Leader 沒有馬上讓 Codex 寫代碼，而是先派出一個有邊界的 Spike。任務只回答幾個事實問題，要求真實請求作為證據，同時明確禁止實現 MCP。幾分鐘的探索避免了一次完整的錯誤實現。

後面的驗收也暴露了 Agent Team 真正的價值。有份報告用無效 Token 返回 401 證明某種鑑權機制不存在。結論碰巧正確，推理卻無效。另一輪測試全部通過，但真實 fixture 只有一個空數組，根本沒有驗證非空數據的字段結構。

這些報告沒有造假。它們只是正確但不完整。Leader 需要換一個目標函數再次看證據，實現者和驗收者也不能共享同一套自證邏輯。

這個任務最後形成了幾條穩定規則。有界探索先於實現。作者不能成為高風險改動的唯一 Reviewer。證據必須同時說明證明了什麼和沒有證明什麼。對外可見、不可逆或涉及身份背書的動作停下來交給人。

這就是 L2 給我的直接感受。一個人開始擁有一支協調成本很低的交付團隊。

## 從一次配置到一套運行模型

之後，我開始把 Multica 的用法從臨時配置變成一套可以維護的運行模型，並把它整理進 Git 倉庫。

這裡最關鍵的做法，是把四個對象分開。

| 對象                 | 負責什麼                    | 變化速度      |
| ------------------ | ----------------------- | --------- |
| Profession Profile | 角色職責、判斷邊界、工具和證據契約       | 穩定，可版本化   |
| Agent Instance     | 具體 Runtime、模型、權限和併發     | 可以替換      |
| Squad              | 持久化使命、路由規則和成員關係         | 隨穩定工作隊列調整 |
| Issue Run          | 一次任務的目標、Context、證據和剩餘風險 | 每次任務都不同   |

它的核心價值在於把穩定契約和可變部署分開。

角色職責應該穩定。Delivery Lead 長期負責拆解、路由、衝突裁決和證據收口。Implementation Engineer 長期負責實現和測試。Challenger 長期尋找反例並做只讀 Review。Explorer-Validator 長期負責大上下文探索、影響面分析和獨立驗收。

具體 Runtime 和模型可以變化。今天的 Delivery Lead 可以部署在 Claude 上，Implementation Engineer 可以部署在 Codex 上，Challenger 使用 Grok，Explorer-Validator 通過 Antigravity 使用 Gemini。以後模型發生變化，可以替換實例，但不必同時重寫 Team 的責任關係。

這不等於模型可以無成本互換。不同 Runtime 的權限、工具、會話和錯誤模式都需要重新驗證。可替換指的是組織契約不綁定某個模型品牌，不是跳過部署驗收。

## 現在的 Multica 配置

寫這篇文章時，我在 Multica 中管理 8 個 Agent Instance 和 4 個持久化 Squad。

四個跨 Squad 的主力角色是 Delivery Lead、Implementation Engineer、Challenger 和 Explorer-Validator。另有 Product Architect、Market Researcher、Ops Engineer 和 Data Analyst，分別服務研究、架構和可靠性任務。

四個 Squad 按穩定工作隊列劃分。

| Squad                   | 進入條件                  | 默認路徑                                     |
| ----------------------- | --------------------- | ---------------------------------------- |
| Engineering             | 日常功能、重構、普通 bug 和工程交付  | Claude 路由，Codex 單寫，Gemini 驗收，必要時 Grok 挑戰 |
| Reliability & Incident  | 根因不明、跨模塊、難復現或線上可靠性問題  | 多路只讀取證，Claude 收斂假設，Codex 單寫修復，非作者回歸      |
| Research & Architecture | 技術選型、產品取捨、遷移或有限 Spike | Gemini 取證，Grok 攻擊假設，Codex 只做有邊界的實驗       |
| Frontend Experience     | 用戶流程、視覺、響應式、無障礙和瀏覽器驗收 | Gemini 建立基線，Codex 實現，Gemini 在真實頁面驗收      |

Squad 不按倉庫劃分，也不因為出現一個新模型就新增。新倉庫只是新的 Project 資源。已知該由誰負責的任務直接 Assign 給對應 Agent。只有工作需要多種能力，而且創建 Issue 時無法確定具體 Owner，才進入 Squad。

這套配置也有明確的硬邊界。每個任務只有一個當前 Owner。每個 Worktree 只有一個 Writer。寫入型 Agent 的併發為 1，非寫入角色可以為 2，本機 Daemon 的總併發上限是 3。生產、憑據、發佈、外部發送和不可逆動作始終由我批准。

## 每次只喚起最小必要角色

Agent Team 很容易被誤解成每次讓所有模型一起工作。這樣做通常只會增加 Context、Token 和協調成本。

Multica 的 Squad 本身只是路由對象。Issue 分給 Squad 後，系統先喚醒 Leader。Leader 讀取 Context，再決定下一步應該交給誰。Squad 不會自動運行所有成員，也不會增加併發。

所以我的默認規則是，每次只喚起足夠完成任務的最小角色集合。

一個邊界清楚的小修復，可以直接交給 Codex，不需要啟動 Squad。陌生大倉庫或 UI 任務，先讓 Gemini 建立影響面和驗收基線，再交給 Codex。難復現故障或高風險 Diff，才增加 Grok 的對抗性 Review。

默認同時激活不超過兩個執行成員。並行只用於互不依賴的調查、同一個穩定 Commit 上的獨立 Review，或文件範圍完全不重疊的 Worktree。多個 Agent 同時修改同一份狀態，速度看似提高，最後通常會變成衝突和返工。

Agent 數量不是 Team 成熟度。能否在正確時刻喚起正確角色，才是編排能力。

## DoD 是 Agent 之間的接口

Agent 之間能夠直接協作，不代表可以只說一句你接著做。

我要求每次委派都寫清四件事。

```
outcome: 最终可观察结果
evidence: 证明结果的测试、命令、截图、数据或链接
verification: 由谁、用什么方式验收
max_rounds: 最多返工轮数，默认 2
```

這就是 Definition of Done。它定義結果被接受前必須滿足的證據契約。

Implementation Engineer 交付的不只是代碼，還要返回變更範圍、Commit、測試命令和原始結果。獨立 Reviewer 讀取的是目標、Diff 和測試，不接受作者的完成聲明作為證據。Leader 收口時要列出實際結果、未驗證項、剩餘風險和需要人決定的事項。

`max_rounds` 同樣重要。Agent 可以互相 Mention，但系統無法替我判斷協作應該在什麼時候結束。兩輪返工後仍然證據衝突，Team 必須停止循環，把分歧交給人。

在 Multica 裡，一個 Task 顯示 `completed`，只說明這次 Agent Run 正常結束，不代表 Issue 的目標已經完成。真正決定任務能否進入 Review 的，是 DoD 和證據。這條區分讓 Agent 的運行狀態和工作的完成狀態分離開來。

## Agent Team 也需要配置工程

角色 Prompt 寫得再好，也不能證明 Team 在真實環境裡可以運行。

我把 Git 倉庫設為配置事實源。`config/agents/` 保存角色契約，`config/squad-*.md` 保存路由規則，`config/topology.json` 保存 Agent、Runtime、權限、併發和 Squad 拓撲。Multica 線上對象只是這套聲明的運行副本。

同步器默認只輸出變更計劃。人工檢查後才應用，再運行一次，結果必須是 `No changes.`。未納管對象只報告，不自動刪除。Workspace ID、Agent ID、Token、Webhook 和本機路徑都留在倉庫外。

這套機制解決的是配置漂移。角色和路由發生變化時，我可以看到 Diff，可以 Review，也可以把線上狀態重新對賬到預期狀態。

實際接入過程也讓我看到，Agent Team 遠不只是幾段 Prompt。Leader 既要操作 Multica 控制面，又不能寫項目文件。Grok 需要只讀 Review，卻不能繼承過寬的網絡和寫入能力。桌面 Runtime 還會受到代理、沙箱、命令參數和本機環境影響。

這些問題先後暴露後，我連續修正了控制面直連、沙箱邊界和 CLI 子命令匹配。配置文件裡寫著允許，不代表運行時真的健康。每個關鍵角色都需要真實的正向和負向煙測。

## 從 Agent Team 再看五個臺階

從 Agent Team 的視角看，未來工作範式的五個臺階，本質上是路由、協作和驗收責任逐步從人轉移到系統。

| 層級 | Agent 的組織方式                 | 人的主要工作                |
| -- | --------------------------- | --------------------- |
| L0 | Agent 無法進入真實工作              | 繼續使用原有流程              |
| L1 | 多個獨立工具，人是唯一 Router          | 逐次提供 Context，檢查每個結果   |
| L2 | 角色和 Squad 持久化，Leader 選擇最小團隊 | 定義目標和 DoD，驗收證據，處理關鍵選擇 |
| L3 | 日程或事件主動觸發 Agent Team        | 管理例外、權限、預算和停止條件       |
| L4 | 多支 Team 按意圖運行，組織結構可以動態調整    | 決定方向、價值和不可委託的邊界       |

我目前處在 L2 到 L3 之間。現在這套 Multica 配置解決了角色、路由、證據和可觀察性問題，但大多數任務仍由我主動創建。

L3 的關鍵變化是觸發權。Multica 的 [Autopilot](https://multica.ai/docs/autopilots)可以讓週期任務或 Webhook 事件自動創建 Issue，再交給 Agent 或 Squad。此前我在[《Builder 的 Mac，也需要一個 Sweeper》](https://weekly-essay.mikey.wang/zh-hant/2026/w32-a-builders-mac-also-needs-a-sweeper)裡寫過每天治理 Skills、每週檢查 Mac 環境的 Routines。這類工作更接近 L3。

但觸發權不能走在驗證能力前面。沒有 DoD、證據、權限、停止條件和可觀察記錄，自動喚醒更多 Agent 只會讓錯誤更早發生，也更難被發現。

團隊整體仍以 L1 為主，大多數人處在 L1 向 L2 過渡的階段。大家已經會使用 Agent，下一步要把角色、路由、驗收和權限變成共同的工作系統。