最近一篇研究 Microsoft 早期導入 Claude Code 與 GitHub Copilot CLI 的論文，給了 AI coding agent 一個很好的提醒：企業採用 agent，不是把工具發下去就會自然發生。

這件事代表的是，coding agent 正在從「個人效率工具」進入「團隊擴散系統」。研究追蹤數萬名工程師，發現第一次使用主要透過社交網路擴散，留存更接近工程師本身的 coding activity，而不是人口屬性；採用者合併的 PR 約比預期多 24%。這個數字不能直接等於商業價值，因為 PR 不是收入，也不是品質。但它至少說明一件事：CLI agent 不是純 novelty，也不是每個人裝了都一樣有效。

真正該在意的人，不只是工程師，而是 CTO、平台工程、DevEx、資安、工程經理。因為 agent 採用失敗，常常不是模型不夠強，而是 rollout 設計太天真。公司以為問題是「要不要買 Codex、Claude Code、Copilot CLI」，但更核心的是：團隊裡誰示範高品質用法？新手能不能看見可複製的 workflow？agent 改的 code 進不進得了 review？token 成本、權限、repo 邊界和失敗記錄有沒有被管理？

錯誤理解是把 CLI agent 當成新版 autocomplete。Autocomplete 是每個人打字時自己變快；agent 則會跑 command、改多個檔案、開 PR、吃上下文、消耗預算，甚至碰到內部資料。它更像一個低階外包工程單元，需要任務切分、執行邊界和驗收機制。只用「每席多少錢」或「哪個模型 benchmark 高」判斷，很容易買到熱鬧，買不到速度。

另一個錯誤理解，是只看重度使用者的 demo。高手用 agent 會變快，因為他知道怎麼切任務、怎麼設限制、怎麼讀 diff、怎麼要求測試。弱 rollout 會讓其他人只看到失敗案例：agent 改壞、跑太久、上下文錯、PR 很難 review。這時候不是工具沒用，而是團隊沒有把高手的使用方法產品化。

採用建議很簡單：先不要全公司鋪開，先找高 coding activity、願意留下範例的團隊做「可見試點」。要求他們沉澱三種東西：適合 agent 的任務類型、不適合 agent 的任務類型、PR 驗收清單。接著把這些變成 repo 的 AGENTS.md、標準 prompt、任務模板、成本儀表板和 review 規則。

判斷是否值得擴大，不要只看使用人數，要看四個指標：留存、PR 後續修正率、review 時間、單位有效產出的 token 成本。如果 PR 變多但 review 卡死，那只是把瓶頸搬到下游；如果 token 花很多但只產生低價值小修，那是把預算換成噪音。

我的結論是：CLI coding agent 的勝負，不在「員工會不會用 AI」，而在公司能不能讓好用法被看見、被複製、被治理。未來工程組織的 AI 優勢，會越來越像內部平台能力，而不是採購能力。