摘要： Cohere 在 2026 年 10 月 15 日發表的文章指出，企業員工自行打造 agents 已經變得容易，真正的難題是盤點與治理——當管理流程追不上 agent 數量，就形成 agent sprawl。文章提出一個替代思路：允許「挑戰者」agent 與現有 agent 在限時、有指標的條件下競爭，用證據決定去留。
先分清楚：proliferation 不等於 sprawl
Cohere 的基本立場是，agent 數量增加本身不是壞事。最貼近工作流程的人，往往最有條件判斷哪個環節適合用 agent 改善；而一個團隊做好的 agent，如果能被分享和重用，其他面對類似問題的團隊也受惠。
更重要的是，多一個沒人用的 agent，並不會單純因為存在就消耗 token。管理負擔真正出現的時刻，是治理流程跟不上數量的成長——找不到現有的 agent、無法重用、權限沒人管。Cohere 把這個狀態定義為 agent sprawl。這個區分很實用：它把問題從「要不要限制大家建 agent」轉移到「管理機制要怎麼跟上」。
三種現行的治理模式
文章整理了企業目前常見的三種做法：
- 集中式：由中央 AI 或工程團隊統一建置與治理，控制力強，但創新速度受限。
- 聯邦式：各業務單位擁有 agent 的開發與營運，中央提供共享基礎設施、標準與治理模式。
- 混合式：中央與業務團隊在共同標準下分擔建置與營運責任。
無論採用哪種模式，Cohere 觀察到企業越來越依賴 agent registry——一份記錄 agent 擁有權、使用情況與存取權限的共享清單，同時讓員工搜尋到已存在的 agent。預設行為是先重用、再新建。
重用至上的一個盲點
registry 加上「避免重複」的偏好，確實能壓低 sprawl。但 Cohere 提出一個值得注意的反面論點：如果只要有一個堪用的 agent 就禁止替代方案，組織就失去了發現更便宜、更可靠、更貼合任務的解法的機會。把重複一律當成浪費，代價是創新。
挑戰者模式：重複是暫時的
Cohere 的替代方案是把重複視為暫時狀態。任何團隊若有充分理由相信能做得更好，可以建一個 challenger 挑戰 incumbent；但 challenger 能否存續，取決於它是否展現出實質優勢。
這套機制的關鍵是限時、以證據為本的比較，指標依用例而定，可能包括可靠性、token 用量、延遲與任務表現。文章用一間銀行舉例：中央團隊做了一個替客戶經理草擬信貸備忘錄的 finance agent，放貸團隊認為用更小更便宜的模型、加上一道核對財務數字的步驟可以做得更好，於是建了 challenger。兩個 agent 同時跑 30 天，比較四項指標：數字能否溯源到文件、信貸主管修改草稿的幅度、每份備忘錄的 token 成本、以及產出第一稿的時間。
結果有三種：全面領先就取代 incumbent；沒有優勢就淘汰 challenger；只在例行年審上表現更好，則兩者並存，各自負責擅長的工作。一旦測試證明某一方沒有優勢，就沒有理由讓它留下。
對建置者的啟示
把這篇文章的框架濃縮成一句話：讓建立 agent 變得容易，但讓存續變得有條件。這其實是把演化機制引進 agent 治理——變異要有，選擇壓力也要有。
實作上，這對評估基礎建設有直接要求：你需要能對兩個 agent 跑同一組具代表性的任務、收集可比對的指標，然後做出去留決定。如果你正在為 agent 行為設計可評分的測試，可以參考本站先前關於 agent 評估實務的整理（從一條 trace 開始：把 agent 的行為變成可評分的測試），挑戰者機制沒有那套評估基本功就走不動。另外，Cohere 自己的 North 2 平台就是這套思路的產品化載體，定位是讓企業在資料所在之處建置和共享 agents。
一個留給你的實際問題：你的組織現在連「有哪些 agent、誰擁有」都答不上來的話，先建 registry 再談競爭機制，順序不能反。