前言：這場演講在講什麼
這篇文章整理自 Patrick Debois 的演講《The Rise of Agent Enablement: Coding Agents Don’t Scale Themselves, Neither Do Your Teams》。Debois 是 DevOps 一詞的發起人，長年耕耘 Continuous Delivery（持續交付），目前在 Tesla 參與打造軟體的「dark factory（黑燈工廠）」——借用製造業「關燈也能運轉的無人工廠」概念，指幾乎不需人介入、由 coding agent 自主完成開發與交付的流程。
整場演講的主軸是 Conway’s Law（康威定律）：組織的溝通結構會決定它產出的系統結構。Debois 把它分成三段來談：
- 我們的工作在變：context（脈絡）成了新的程式碼，需要自己的開發生命週期。
- 組織在變：從個人、團隊、平台團隊到整個組織，agent 的規模化路徑長什麼樣。
- 技術反過來改變組織：當很多 agent 同時工作，concurrency（並行）成為新的瓶頸，這會迫使我們重新組織自己——他稱之為「反向 Conway」。
值得一看的原因是：市面上多數談 AI coding 的內容停在「怎麼讓一個開發者更快」，這場演講談的是當整個組織都開了 agent 之後會撞到什麼牆，而且是從 Tesla 實際開啟多座 factory 的觀察出發。
第一章：Context 即程式碼——CDLC 對照 SDLC
如果 context 是新的程式碼，它就需要自己的開發生命週期。 Debois 把它稱為 CDLC（Context Delivery Life Cycle，脈絡交付生命週期），直接對照我們熟悉的 SDLC（Software Development Life Cycle，軟體開發生命週期）。這裡的 context 泛指所有餵給 agent 的東西：prompt、skill（技能檔）、plugin、agent.md、規格文件、ticket 裡的說明。
他的觀察很單純：我們現在寫 code 的時間變少，寫 context 的時間變多，而寫 context 這件事越來越像寫 code。既然像，過去幾十年處理 code 的方法就可以拿來處理 context。
| SDLC 階段 | 對 code 做的事 | 對 context 做的事（正在出現） |
| 撰寫（write） | 寫程式 | 寫 prompt、文件、Jira/GitHub 上的脈絡；Spec-Driven Development（規格驅動開發）寫出的規格也算 |
| 測試（test） | 單元測試、整合測試 | 用 linter 檢查 skill 格式（有 header、有必填欄位）；用 evals（評測）即 LLM-as-a-judge（讓模型當評審）看產出好不好；資安掃描；測試每個情境的 token 成本 |
| 打包與發布（distribute） | library、package manager、Maven/npm 倉庫 | skill 做成套件、有 package manager 管相依性、有 marketplace（市集）、有版本號、公司規定必裝的套件 |
| 觀測與回饋（observe） | log、監控、production 錯誤 | agent log（它拒絕了什麼、做錯了什麼、人修正了什麼）、PR 上的評論、production 失敗——這些不是 evals，而是 context 的 observability（可觀測性） |
幾個值得展開的細節：
- 文件量反而暴增。 Debois 說他沒想過自己職涯裡會有一天開發者寫更多文件——因為那是在幫 agent，不是在幫人。
- context 也有資安問題。 他提到 OpenClaw 事件讓業界驚覺 context 可能是攻擊面，於是資安掃描被加進 context 的測試流程。
- 標準化正在發生。 以前每家工具各有自己的 MD 檔，現在收斂到 agent.md，這和當年 code 的建置工具標準化是同一回事。
- 順序通常不照課本。 理想上是寫、測、發布、觀測，但實務上大家先寫、先發、出事才補測試——跟當年寫 code 一模一樣。
Context 和 code 一樣會壞。 它會 drift（漂移）、累積 tech debt（技術債）、rot（腐爛），而且會 conflict（衝突）：你的 skill 和我的 skill 對同一件事有不同意見，該聽誰的？這些問題目前都還沒有好解法，但至少我們已經有一套熟悉的框架可以思考它。
最後一個提醒：在自己筆電上做這個循環是一回事，把它分享出去、讓多人一起改進才會產生複利效應。 這也是第二章的起點。
第二章：從個人、團隊、平台到組織
第一章只是把 agent 變強，第二章要談的是把「人」和「組織」變強。 Debois 用 Conway’s Law 的視角，一層一層往上走：開發者、團隊、平台團隊、組織。
開發者：停止自己寫 code
開發者的新角色是 agent 的 conductor（指揮者）：給回饋、做 orchestration（編排）。Debois 講得很直白：別再自己寫 code 了，真的還動手就該被打手心。 你該做的是修正 agent、給它 harness（約束框架）、給它更好的 context，讓它把事做好。他的口號是：「不要蓋東西，要蓋那個會幫你蓋東西的東西（build the thing that builds the thing）。」
這裡的 harness 是指包在 agent 外面的一整套規則、工具、檢查與迴圈，讓它在邊界內自主運作。
團隊：新的儀式
當 context 從個人筆電進入團隊的 repository，敏捷的儀式也跟著變形：
- Planning 變成「context planning」。 核心問題從「這個需求怎麼拆」變成「這件事的 context 夠完整到 agent 能自己做嗎？還是人類得再想、再寫、再實驗？」
- Retro 多了一個問題。 除了「我們有沒有把 code 變好」，還要問「我們有沒有把 agent 變好」。
Debois 的實地觀察是：團隊要真正進步，一定得由 team lead 把 context 的品質與共享列入改進循環。 否則每個人會各做各的，context 散落在各自的筆電上，複利效應不會發生。
平台團隊：AI Platform Team
一個團隊做好了，第二個、第三個跟上，大企業就會問：「能不能規模化？」於是出現 AI platform team（AI 平台團隊）——不是為了 cloud 或 container，而是為了 context、loop（迴圈）和 harness。
有趣的是，它需要的基礎設施和 cloud platform team 高度重疊：model router（模型路由）、proxy、gateway、testing system、registry（註冊中心）。但歸屬目前很模糊：是 AI 團隊？DevEx（開發者體驗）團隊？Cloud 團隊？這是一個正在成形的新東西。
兩個關鍵主張：
- 平台團隊不能只提供工具，必須主動出去 enable（賦能）各團隊——這也是演講標題「Agent Enablement」的由來。
- 要讓這件事在組織裡有推力，必須正式指定一個團隊負責。
給工程師的安慰：技術深度重新打開了
很多工程師抱怨：「我不是為了管 context 才入行的，這不是我簽的那份工作。」Debois 的回答是：harness 和平台這一層重新打開了技術深度——sandbox（沙箱）、runtime、規模化、可觀測性，都是硬技術問題。就像當年 DevOps 的自動化確實拿走了一些工作，但剩下的工作在規模化之後反而更有趣。他不保證每個人都有位子，但對還想走技術路線的人，這是明確的方向。
組織：VP 該看什麼指標
VP 的工作是確認平台團隊存在、指定 owner、設定目標與方向。在衡量上，DORA metrics（DORA 指標：部署頻率、變更前置時間、變更失敗率、恢復時間）仍然有效，但 Debois 多看兩個新指標：
| 指標 | 衡量什麼 | 為什麼重要 |
| Human touches（人類介入次數） | 人還需要碰 agent 幾次才能完成一件事 | 證明 agent 效能：harness 對了、context 對了，介入就會變少 |
| Reuse（複用範圍） | 我改一份 context，組織裡有多少人受益 | 這不是單人 10x，是整個組織的乘數效應 |
第二個指標是他特別強調的：一個團隊寫好資安規格、另一個團隊寫好前端規格，所有團隊的 agent 都受益。要證明 ROI，從組織層級的複用來看，比在單一 commit 上證明「這次有變快」容易得多。
他也提醒：這不只是改進，還有維護。context 會變、coding agent 本身會換版本，平台團隊的工作裡有一部分是降低這些變動帶來的風險。
第三章：Concurrent Delivery——當 agent 開始互相絆倒
Debois 對現在大家的「factory」感到無聊。 多數人的 factory 是這樣：skill 是可重用的工作流程，把 skill 放進 loop（迴圈），給它一個目標，再把多個 loop 並行或串行跑起來，就成了共享的 factory。但拆開看，它只是把「叫開發者寫 code」換成「叫 agent 寫 code」，迴圈裡還是 review、deploy、spec，沒有新東西。他的問題是：我們能做的只有這樣嗎？
Tesla 開了 factory 之後看到的事
真正的新現象是：當很多 agent 在同一個 codebase、同一個組織裡工作，它們會開始互相絆倒。 你在本機用 git worktree 開多個 session 時可能已經感受過：一個 agent 做到一半，另一個 agent 平行做了同一件事，或做了衝突的事，最後 merge 要人來解。
所有公開分享內部 factory 經驗的人都撞到同一面牆：coding 有了 concurrency（並行）問題。一個 agent 在找的資訊另一個還在產生；協調失靈；QA 還是瓶頸；並行的壓力只是從 factory 的一個地方搬到另一個地方。即使完全沒有人介入——像 Anthropic 用 16 個 agent 寫 C compiler 的實驗——agent 之間仍然互相絆倒。不是不能加到 100 個 agent，而是它們之間的依賴卡住了全部的潛力。
頓悟：Concurrency, concurrency, concurrency
Debois 說這是他演講前一個週末的頓悟（他拿 Steve Ballmer 喊「Developers, developers, developers」的梗來說）：並行無所不在，而且是痛點。 回頭看整個開發者生涯，我們一直在處理並行——我做的和你做的要對齊、我們做的和業務說的要對齊，每個人都在動。agent 只是把這件事放大了。
他把這個思維稱為 Concurrent Delivery（並行交付）——有人建議叫 Concurrent Continuous Delivery，名字不重要，重點是：事情本來就是並行發生的，我們的工作是把它們收攏，收得越快，浪費越少。
agent 絆倒的五個地方，以及正在出現的工具
| 絆倒點 | 發生什麼事 | 正在出現的解法 |
| Planning（規劃） | 天真的排程器「五台機器各做一件事」，結果重複做、互相改到、事前不知道的相依性冒出來；而且邊執行邊改計畫（聽起來很 agile） | 把任務視為 dependency graph（依賴圖）、用 claim（宣告認領）機制、持續修正計畫。你在單一 coding agent 的平行功能裡已經看得到雛形 |
| Isolation（隔離） | 乾脆讓每個 agent 各做各的：worktree → VM。但 VM 又帶來 port 衝突、資安等新問題 | microVM（微型虛擬機）：啟動一個 VM 後直接 fork（分叉）記憶體給多個 agent 用，不用等 CI/CD 起環境。這也是很多人把部分流程搬回本機的原因——輕、快 |
| Data versioning（資料版本化） | 資料集也會被多個 agent 同時用、同時改 | 類 git 的資料版本工具（他提到 Dolt），做 copy-on-write（寫入時複製）執行；而且要確保資料在語意上有代表性，不只是複製 production |
| Semantic merge（語意合併） | agent 啟動時 fork 的不只 code，還有時間點、資料、狀態、輸入。文字能合，不代表語意能合；語意能合，不代表符合原本的 spec | 分三層看 merge：文字 → 語意 → intent（意圖）。把 agent 想成拿著一份隨時可能失效的 cache，需要機制去 invalidate（使之失效）並通知其他 agent |
| PR 堆積 | commit 和 PR 排山倒海 | Stacked PR（堆疊式 PR，一串互相依賴、按順序合併的 PR）、release train（發布列車，固定節奏與順序的發布批次）；甚至有工具會算出「這條 PR 的假設已失效，換另一種 release train 順序更好」——同樣是在為 context 和 intent 最佳化 |
這五點的共同主題：所有能壓縮協調成本的東西，都直接等於工作做得更快。
Review 的本質是風險管理
Factory 一開，你的工作就變成 review、review、再 review。 這是每個開 factory 的人都感受過的痛。當然可以 YOLO（看都不看就按 LGTM），但 Debois 談的不是這個。他指出，review 這件事其實不是在看 code，而是在處理風險。有兩條路：
- 把風險拿掉。 加更多工具：adversarial review（對抗式審查，讓另一個 agent 專門找碴）、linter、consensus judge（共識評審，多個模型投票決定是否通過）。這些都是 harness 的一部分，目的是降低出錯的機率。
- 要求證據。 讓 agent 證明「它做的就是你要的」：formal verification（形式驗證，以數學方式證明程式符合規格）、比對 intent、要 agent 提出 evidence（證據）說明這是一個好的變更。
這些都該做，但 Debois 提醒：我們面對的是 non-deterministic（非決定性）的系統，風險永遠在。而且人類也一樣——我們 merge 的東西本來就可能有問題，到某個時候你會因為信心累積而不再看見它。
直播公司的故事：用風險替程式碼貼標籤
Debois 以前創過一家做電視直播互動的公司，測試套件要跑一小時。問題是他們的價值只在節目直播的那一小時產生——節目開始前沒有觀眾，結束後也沒有。節目進行中，製作人說：「那個計分板看起來怪怪的，很難跟觀眾解釋。」你改不改？等測試跑完，節目也結束了。
他們的解法是依風險替 codebase 的各個部分貼標籤：這一塊風險可以緩解、這一塊可以碰、這一塊不准動。把真正重要的核心和 nice-to-have 隔開。你的 ROI 單位可能不是一小時，而是金額、交易量、客戶曝光，但道理一樣。
由此推出三個實務建議：
- 依風險決定自動化程度。 CSS 顏色改了和 authentication（認證）系統被改了，是不同等級的風險；低風險可以 auto-merge（自動合併），高風險要人看。
- 架構和目錄佈局本身要能反映風險。 如果你看目錄看不出哪塊是認證、哪塊是樣式，agent 和人都無法據此做風險判斷。
- 漸進式釋出（progressive / gradual release）。 先給部分人、A/B 測試、小步上線，用真實環境分攤風險。
他特別區分兩個階梯：**automation ladder（自動化階梯）**和 autonomy ladder（自主化階梯）。要爬的不只是「多少事被自動化」，而是「多少事可以不經人同意就發生」——後者才是風險管理真正要回答的問題。
Dark factory 不是每個人的目標
你的 risk appetite（風險胃納）決定你該走多遠。零使用者的新創，每次都全量部署沒關係；有客戶就有影響。但即使有客戶，仍然可以分區：這一塊可以全自動，那一塊不行。DevOps 的歷史也是這樣——container 大家敢隨便重啟，因為資料不在裡面；但沒人敢動 database schema。這就是風險的差異。
唯一真正的 staging 是 production
Staging 環境再像，都少了一樣東西：真實使用者。你不知道他們會怎麼用你的產品。所以現在的 merge 其實還是在 staging，production 才是真正的證明。
由此 Debois 推出一個激進的想法：既然我們能處理開發時的並行，為什麼不能處理 production 裡多個版本並行？ 為什麼只能有一個版本、頂多幾個 feature flag？聽起來很可怕，但當年 Continuous Delivery 聽起來也一樣可怕。
- 保留選項更久，不急著收斂到共同的最小公分母；平行的 release train 各有各的風險分析。
- Cursor 的 best-of-n（做 n 個版本挑最好的）延伸到商業層：這不只是技術上的 feature flag，而是 business feature flagging——客戶會喜歡 A 還是 B？
- 極端一點：每個客戶都是自己的版本。業務的夢想：「客戶問的那個功能我們不做」這句話可能消失。
- 再翻轉一次：開放客戶在你的平台上 vibe code。你不用問他們要什麼，直接看他們在蓋什麼。
他承認這會讓人腦袋爆炸，但類比到 AI 領域的 world model（世界模型）——不是給模型單一任務，而是給它整個世界的認知——方向似乎是相通的。
從造更快的飛機，到航空管制
Pipeline 的問題，其實是 concurrency control（並行控制）的問題。 Debois 用航空管制做比喻：過去十年我們造出了更快的飛機（Continuous Delivery），現在要處理的是很多飛機同時在天上。航管要回答的問題是：什麼可以進 factory？什麼該隔離？什麼順序？風險怎麼分級、怎麼升級處理？
人類天生會壓低並行
他舉了一段 DevOps 歷史。早期有一個組態管理工具叫 CFEngine，它是 agent-based 的：給 agent 規則，agent 自己會把系統管好。但世界還沒準備好——人類無法掌握同時發生的多個事件，於是 Puppet、Chef 把它收斂成「跑一個 loop」，Ansible 更直接說「一個 loop 就好，盯著它跑」。（他承認這是誇張說法，每個工具都有其價值。）
重點是：人類一直是那個把並行壓到最低的角色，因為序列才是我們能理解的。所以結局可能是：線上看起來全是序列的，factory 裡面全是並行的，而我們必須處理它。
自動化之後，下一步是自動化的協調（coordination of the automation）。 這就是他對現在的 factory 感到無聊的原因——它們只是一堆被序列化的觸發，而真正的難題是同時協調多個 loop。
問題只會更嚴重
- OpenAI 在談 defense factory（防禦型工廠）：根據即時的資安回饋，多快能做出變更、多快能反應，幾乎是對抗式的迴圈。
- Factory 本身也需要持續維護：世界在變，factory 也要跟著改。
- 任務越有野心，trajectory（執行軌跡）越長，衝突和並行的影響越大。
Debois 相信這會反過來影響我們怎麼寫 spec，但他還沒想清楚具體是什麼。可以確定的是幾個瓶頸不會消失：integration（整合）、verification（驗證）、freshness（新鮮度，所有東西是否都已對齊）、以及人類的注意力。有人把這叫 ambient factory（環境式工廠）：「需要我的時候再叫我，其他時候自己做。」
Factory 開啟後的意外副作用
Tesla 的做法是把 support 等非開發角色也拉進同一座 factory——他們不是在旁邊各自 vibe coding，而是在同一個 factory、同一批 release 上工作。對話直接在 Slack 裡發生：客戶要這個功能 → 幫我寫 → 這是 PR → 這是 review 方式 → 我覺得要改 → merge。以前要排進 planning、常被回「沒有產能」的事，現在即時完成。
有趣的是，factory 開啟那週所有人都在抱怨：「這週到底發生了什麼？事情太多了，我們怎麼跟上？」Debois 是遠端工作者，長年苦於聽不到辦公室裡的資訊，他的反應是：「太好了，你們終於開始分享了。」但這確實是一個新問題：瓶頸從寫 code 移到了 support 文件、教育訓練等跟不上的地方——而因為它們也在 factory 裡，又製造了新一層的並行。
總結：反向 Conway
Debois 自己的三句總結：
- Context 變成 code，CDLC 是好用的類比。
- 團隊 → 平台 → 組織的規模化路徑仍然成立，是把 agent 推進組織的方法。
- Concurrent Delivery 可能會改變我們組織自己的方式。 這是一次 reverse Conway（反向康威）：過去是組織結構決定系統，現在是技術反過來重塑組織。他說這是他明年的演講題目。
對關注「AI 時代測試」的讀者，這場演講的啟發在於：它把瓶頸再往後推了一層。大家已經看到「產出變快，驗證變成瓶頸」；Debois 的觀察是驗證之後，瓶頸會落在協調——而協調問題的解法，一部分會回到風險分級、架構邊界、漸進釋出這些我們早就認識的老朋友。
LeSS 可以幫忙什麼
Debois 描述的問題，LeSS（Large-Scale Scrum）其實早就在處理——只是當年的「多個單位同時改一個 codebase」是多個團隊，現在變成多個 agent。 他說技術會反過來改變組織，而 LeSS 的立場一向是「先設計組織，再談工具」。兩者對照，LeSS 至少能在五個地方接上。
| Debois 提出的問題 | LeSS 已有的做法 | 怎麼接 |
| Context 散在各自筆電，沒人把共享列入改進循環 | Overall Retrospective（整體回顧） 和 Communities of Practice（實踐社群） | 多團隊一起回顧「我們有沒有把 agent 變好」；skill、harness 的標準由跨團隊的 CoP 維護，而不是等一個平台團隊從上而下推 |
| 誰擁有 AI platform team？歸屬模糊 | Feature team（特性團隊）優先，對專責團隊保持警覺 | LeSS 不反對平台，但要求平台團隊的目標是「讓特性團隊自己能做」，而不是變成新的瓶頸或交接點——這和 Debois 說的「平台團隊必須出去 enable」是同一件事 |
| 多個 agent 在同一個 codebase 互相絆倒 | 一個 Product Backlog、共享程式碼所有權（shared code ownership）、持續整合、Multi-team PBR | LeSS 從一開始就假設很多單位同時動同一份 code，答案不是隔離，而是頻繁整合加上事前一起釐清需求。agent 的「依賴圖」「claim 機制」其實就是 LeSS 裡多團隊共同做 refinement、把相依性在 Sprint 前談開 |
| 人類介入次數（human touches）、自主化階梯 | Definition of Done（完成定義）與 Undone work（未完成工作） | LeSS 用 DoD 的範圍來衡量組織有多接近「可直接出貨」；每一項還需要人補做的事就是 undone work。把它換成 agent：DoD 裡 agent 自己能做到的比例，就是自主化階梯爬到哪一層 |
| Review 是風險管理、唯一的 staging 是 production | 每個 Sprint 交付可出貨增量、Sprint Review 看真實成果 | LeSS 要求每個 Sprint 結束都是可出貨的狀態，逼組織把風險分級與漸進釋出做成常態，而不是 release 前才來想 |
三個更具體的切入點
- 把「context planning」放進 Multi-team PBR。 Debois 說 planning 的新問題是「這件事的 context 夠清楚到 agent 能自己做嗎？」這正是 refinement 在回答的問題，只是過去的對象是開發者，現在多了 agent。Specification by Example 寫出的範例，本身就是給 agent 最好的 context。
- 用 Overall Retrospective 處理反向 Conway。 他說技術會反過來重塑組織，但沒說由誰來重塑。LeSS 的整體回顧本來就是多團隊和管理者一起看系統性問題的場合，「factory 開了之後 support 文件跟不上」這種跨團隊的瓶頸，正該在這裡被看見。
- 把「並行交付」當成組織設計問題，而不只是工具問題。 Debois 列的五個絆倒點都有工具在解，但 LeSS 的經驗是：多單位改同一份 code 時，真正省下協調成本的是結構——一個 backlog、一個 DoD、一個整合的 code base。工具解的是症狀，結構解的是源頭。
一句話總結：Debois 從 agent 看到的「並行」，LeSS 從團隊早就看過一輪；他問的「誰來協調」，LeSS 的答案是讓做事的人自己協調，而不是再加一層。
來源
- 演講影片：The Rise of Agent Enablement: Coding Agents Don’t Scale Themselves, Neither Do Your Teams — Patrick Debois
- 本文依據影片字幕逐字稿整理，解釋與補充為筆者所加；講者提到可私訊索取投影片，Tesla 亦有多篇關於 factory 與 context 的文章。
發佈留言