我的知識庫

Team Topology ＋ AI 治理：組織如何因應 Agent 規模化

閱讀時間約 8 分鐘

當 AI agent 不再只是個人工具，而是整個團隊都在用的工作流元件，組織設計的問題就浮出來了。 Thoughtworks 邀請《Team Topologies》作者 Skelton & Pais 討論這個問題（2025-09），並在 2026 年陸續用控制論和治理框架補充答案。

Team Topologies 的 AI 更新

來源：Thoughtworks Podcast，Organizational design and Team Topologies after AI，Matthew Skelton & Manuel Pais（Team Topologies 作者），2025-09-04

核心原則不變，但更重要了

Skelton & Pais 強調：Team Topologies 的基礎原則——「專注於價值流動和人的認知負載」——在 AI 時代不變，甚至更重要。AI 的局部加速（更快的程式碼生成）若沒有對應的下游投資（測試、部署、產品決策），反而會讓系統整體交付變慢。這和 CircleCI 2026 數據 完全呼應。

Team Topologies 作為「Agency 的基礎設施」

關鍵的框架延伸：Team Topologies 的邊界、職責和領域忠誠（domain fidelity）原則，同時適用於管理人類團隊和 AI agent。

  • 為人類團隊設計的清晰邊界，也是給 AI agent 提供良好工作範圍的邊界
  • 沒有清晰的領域模型，LLM 容易在無意中把不相干的架構耦合在一起

Domain-Driven Design 的重要性上升

沒有全系統一致的「泛在語言（Ubiquitous Language）」，LLM 在跨模組工作時容易意外地把不相干的架構連在一起，製造危害的耦合。

DDD 不只是設計工具，在 AI 時代成了 AI agent 工作的護欄。 沒有清晰的領域邊界，agent 的工作範圍無從界定；沒有一致的術語，agent 產出的命名和結構會跨模組不一致。

Enabling Team 模式：比以往更必要

組織需要一個專職的 Enabling Team 來統籌 AI 採用：

  • 監測外部 AI 發展，評估哪些值得引入
  • 評估組織就緒程度（工程成熟度、治理框架、人員技能）
  • 向 stream-aligned 團隊提供實作引導（不是中央指令，是手把手支援）
  • 管理風險與倫理考量

bol.com 案例（Thoughtworks 直接引用）：這個 Enabling Team 模式在 bol.com 的資料科學採用上已成功驗證，成功讓 AI 能力在多個 product team 間一致擴散。

系統思維，不是局部最佳化

Team Topologies 2nd Edition（2025 年 9 月）的重點之一：局部最佳化≠系統最佳化。 AI 讓某個團隊的程式碼生成速度加倍，但若測試、部署和產品決策的速度沒有跟上，整個系統的 lead time 可能反而變長。

技能組成的演變（進行中）

團隊組成需求在轉移，可能出現新角色：

  • 管理 AI agent 群的協調者
  • 診斷 AI 生成服務失敗的專家

這些角色目前尚無標準名稱，Team Topologies 的框架本身也還在演化中。

AI 治理的技術面

四個治理失敗模式

來源：Technology Radar Vol.34 Caution blips；AI/works™ 平台設計

  1. Shadow IT 擴散：AI 降低了非工程師建立 workflow 的門檻 → 缺乏審查的 agentic workflow 在組織角落悄悄增殖 → 安全漏洞和方案重複（Radar: AI-accelerated shadow IT，Caution）
  2. 認知債累積：程式碼變更速度超過理解速度 → 工程師對系統的掌握逐漸流失 → 更難有效審查 AI 的工作（Radar: Codebase cognitive debt，Caution）
  3. Pipeline 未就緒：程式碼生成速度快但交付管道沒跟上 → 主幹品質惡化（CircleCI 數據：主幹成功率跌至 5 年最低）
  4. Durability 缺失：agent workflow 沒有狀態持久化，任何網路中斷都會造成不完整狀態和難以預測的副作用（Radar: Ignoring durability，Caution）

Thoughtworks AI/works™ 平台的治理設計

Thoughtworks 自己的 agentic 開發平台（2026 年 1 月上線）在治理方面的設計選擇，反向定義了「治理完整的 agentic 開發」應有的要素：

  • 成本透明度：每個 agent 操作都可追蹤（知道花了多少 token / 算力）
  • 主動護欄（active guardrails）：不只是被動日誌，而是主動攔截違規行為
  • 端到端 lineage 追蹤：知道每行程式碼從哪個 agent / prompt 生成
  • 合規執行：在平台層級強制執行政策，不依賴每個工程師記得遵守

認知負載：AI 時代的新計算維度

Radar Vol.34 把「Codebase cognitive debt」列為 Caution：

「隨著 AI 增加變更速度，實作與團隊理解之間的鴻溝在擴大，讓開發者愈來愈難以有效引導 agent。」

對 Team Topologies 的影響：Cognitive Load Mapping 在 AI 時代需要加入新維度——不只是「這個 team 負責的系統有多複雜」，還有「這個 team 能理解 AI 生成的系統多深」。

如果 AI 讓程式碼的複雜度增長速度快於工程師的理解速度，認知負載的計算就要重新做。這也是為什麼 Go See 實踐（定期深入查看實際程式碼，不只看儀表板）在組織層次變得重要。

主張 vs 可佐證

  • 可佐證：Team Topologies 原則來自 Skelton & Pais 的大量研究和案例（book 2019, 2nd ed. 2025）；bol.com Enabling Team 案例有直接引用；Codebase cognitive debt 和 Shadow IT 的治理風險都有 Thoughtworks 客戶觀察支持；CircleCI 數據支持「局部最佳化不等於系統改善」。
  • 主張：「AI agent 管理者」作為新角色的出現時間線是預測；DDD 在 AI 場景的「護欄效果」有工程直覺支持，但尚無系統性實驗；AI/works 的治理設計是 Thoughtworks 自己的平台選擇，不能直接泛化為業界標準。
  • 收斂結論：治理不是 AI 採用的末端，而是 AI 採用能否規模化的前提條件。 組織架構（Team Topologies + DDD）不是軟體架構的附屬品，而是與軟體架構等重要的 AI 工作品質的決定因素。沒有清晰邊界，agent 無從定位工作範圍；沒有 Enabling Team，AI 採用的速度和品質差異就會在各團隊之間快速分化。

來源：

反向連結