AIPA 长文#8：TOGAF ADM × agentic AI 的治理悖论——传统企业架构遇上 6 个月半衰期

日期：2026-10-08 作者：MomoWeb3（10 年金融零售 PM+BA+开发背景） 系列：AI Product Architect（AIPA）长文系列 第 8 篇 定位：方法论。把 TOGAF ADM 这套为「季度变更节奏」设计的企业架构方法论，放到 agentic AI「6 个月半衰期」的现实里压力测试，给出一套可落地的裁剪方案与 C4 治理视图。

---

引言：一个没人愿意承认的空白

企业架构（EA）这门学科有一个尴尬的现状：它最权威的方法论 TOGAF，至今没有为 agentic AI（自主代理型 AI）给出官方治理标准。

截至 2026-06，The Open Group 仍未发布任何针对 agentic AI 系统的 ADM 扩展、参考架构或治理框架。市面上能找到的全部是从业者的博客、咨询公司的「适配建议」、以及把 TOGAF 10 现有阶段「硬塞」AI 关注点的零散尝试（George James Consulting，2025；Amit Verma，2025-09）。换句话说，当 Gartner 预测「到 2026 年约 40% 的企业应用将内嵌任务型 AI 代理」、IDC 预测「到 2026 年 60% 的企业应用将把多代理能力作为标准特性」（两者均见于多份 2025-2026 行业综述）时，指导这些代理如何被「架构」「治理」「演进」的那套方法论，本身还停留在前 GenAI 时代。

这不是一个小空白。它是一个结构性悖论：TOGAF ADM 的核心价值在于「审议」——通过相位推进、利益相关者工作坊、文档评审、人工决策检查点来降低大变更的风险；而 agentic AI 的核心特征是「速度」——模型能力、Agent 框架、协议标准（如 MCP）以「月」为单位迭代。一边是为减速设计的治理引擎，一边是停不下来的技术列车。本文要回答的就是：当审议的节奏遇上 6 个月就过时一半的技术，企业架构师该怎么办？

一句话定位：这不是「TOGAF 死了」的檄文，而是「TOGAF 必须从蓝图机构转型为持续治理操作系统」的改造手册。

---

一、ADM 审议节奏 vs GenAI 速度：结构性冲突的解剖

1.1 ADM 的隐含假设：时间是充裕的

TOGAF 的 Architecture Development Method（ADM）是一个十阶段的环形流程：预备阶段（Preliminary）→ 架构愿景（A）→ 业务架构（B）→ 信息系统架构（C）→ 技术架构（D）→ 机会与方案（E）→ 迁移规划（F）→ 实施治理（G）→ 架构变更管理（H），以及贯穿全程的需求管理（Requirements Management）。

这套设计有一个从未被明说、却无处不在的假设：在你从 A 走到 D 的过程中，世界不会发生颠覆性变化。 业务架构（B）今天定义的能力，到技术架构（D）落地时仍然成立；Phase C 选型的信息系统，在 Phase G 实施治理时仍然是合理选择。在传统企业 IT（ERP、核心银行、数仓）里，这个假设大体成立——这些系统的变更以季度甚至年度为单位。

1.2 GenAI 把这个假设击碎了

问题在于 agentic AI 的迭代速度。Praveen Mittal 在《The Paradox of Governance》（Medium，2025-11）里给出了一个尖锐的观察，我把它称为「相位错位」：

当架构团队走完 Phase C（信息系统架构）时，AI 版图已经剧变，以至于 Phase D（技术架构）面对的是一个完全不同的现实。

把这句话量化一下。GenAI 的企业采用率在「一年内从 33% 跳到 78%」（McKinsey，2025）。如果一次完整的 ADM 循环（含工作坊、评审、文档）需要 3–6 个月，那么在你的架构循环跑完一圈的时间里，主流 Agent 框架可能已经换代、底层模型可能已经发布两个大版本、连「Agent 之间怎么通信」的协议标准都可能从推荐变成「谨慎使用」。

最有力的佐证来自 Thoughtworks Technology Radar Vol. 34（2026-04）：在同一期 Radar 里，Claude Code 被升级到 Adopt（推荐采用），而 MCP（Model Context Protocol）by default 被降级到 Caution（谨慎）。同一种技术家族，在一个 Radar 周期（约 6 个月）内，既有组件成熟到「该上了」，又有用法危险到「该刹车了」。这就是「6 个月半衰期」的实证——你的技术判断，半年后有一半需要重估。

1.3 量化对比表（一）：ADM 节奏 vs agentic AI 节奏

这张表要传达的核心：ADM 的瓶颈不在于它「慢」，而在于它假设环境「稳」。 当环境本身以高于循环周期的速度变化时，每一次审议产出的蓝图，出厂即半过时。

---

二、agent topologies × team topologies：组织结构也要重画

冲突不止发生在「流程」层面，也发生在「组织」层面——而这恰恰是企业架构师最该管、却最容易忽视的一环（Conway 定律：系统结构镜像组织沟通结构）。

2.1 Thoughtworks 的新命题

Thoughtworks 在 Technology Radar Vol. 34（2026-04）里提出了一个会让所有 EA 从业者警觉的命题：

我们可能需要在「团队拓扑（team topologies）」之外，同时考虑「代理拓扑（agent topologies）」，并据此重新思考反馈循环（feedback cycles）。

这句话的分量在于：过去十年，团队拓扑（Stream-aligned / Platform / Enabling / Complicated-subsystem 四类团队 + 三种交互模式）是企业架构师做服务拆分、康威逆向设计的事实标准。而 agentic AI 引入了一类全新的「准团队成员」——它们不是工具，因为它们能自主编排子系统、跨工作流行动；它们也不是人，因为它们没有职业生涯、可以瞬间复制、权限边界由配置决定。

Vol. 34 的四大主题之一「把编码代理拴上链子（putting coding agents on a leash）」与「保护权限饥渴的代理（securing permission-hungry agents）」（Thoughtworks，2026-04）正面回应了这一点：当代理拥有广泛系统访问权（Radar 点名了 OpenClaw 这类工具）并暴露在「致命三连（lethal trifecta，即提示注入 × 私有数据访问 × 外部通信）」之下时，必须先有架构控制，再谈规模化采用。

2.2 把代理建模为「架构构造块」而非「人」

我的主张是：企业架构师应该把 agent topology 当成 architecture building block（ABB）来治理，而不是当成 HR 意义上的「团队成员」。具体映射如下表。

2.3 量化对比表（二）：team topology 角色 vs agent topology 治理映射

数据锚点：到 2026 年，成熟平台会把代理当作「一等公民」，配齐 RBAC 权限、资源配额与治理策略（platformengineering.org，2025-12）；2026 年「94% 的企业认为 AI 对平台成功至关重要」、「73% 的平台团队已在至少一个开发者工作流里集成了 AI 助手」（The New Stack / platformengineering.org，2026）。

EA 启示：传统 ADM 的 Phase B（业务架构）需要新增一类建模对象——「自主代理能力」，并在 Phase G（实施治理）里为它们配齐 RBAC/配额/断路器，而不是把它们当成 Phase D 的一个普通技术组件一笔带过。

---

三、AI 平台工程：「企业操作系统」承接治理速度差

如果 ADM 太慢、代理太快，那中间需要一个「速度变压器」——这个角色，正在由 AI 平台工程（AI platform engineering）承担，业界越来越多地把它称为面向 AI 的「企业操作系统」。

3.1 平台作为控制层（control plane）

The New Stack（2026-02）把 2026 定义为「AI 与平台工程合流之年」。其核心论点是：大多数 2026 年的企业不缺对 AI 的访问（模型 API 到处都是），它们卡在治理它、规模化它、让它在几十个团队间可靠运行。内部开发者平台（IDP）被点名为「构建 AI 采用、并加上你所在行业风险画像所需的护栏与闸门的最佳地基」。

这正是企业架构师该兴奋的地方：平台把「治理」从一次性的 ADM 蓝图，变成了持续运行的运行时控制。 蓝图会过期，但一个能持续做策略执行（policy enforcement）、可观测性、变更管理的平台不会——它把架构原则「编译」成了每天都在运行的护栏。

3.2 「企业操作系统」的四个职责

把平台类比为操作系统，它对 agentic AI 的职责可归纳为四个内核子系统：

1. 身份与权限（identity & RBAC）：每个代理是一个有身份的 principal，权限按最小化原则配置，对齐第二节的 agent topology。
2. 资源与配额（resource & quota）：代理的算力/调用/成本有配额，FinOps 内建——防止自主代理「跑飞」烧钱。
3. 安全与合规（security & compliance）：策略即代码，针对「致命三连」做注入防护、数据边界隔离、外部通信审计。
4. 可观测性与变更管理（observability & change management）：代理行为可追溯、可回放、可熔断；模型/框架换代通过平台灰度，而不是通过一次 ADM 大循环。

平台团队正在为此构建共享算力层、大规模评测后端、批量/在线混合推理基础设施（行业综述，2026），这与第一节「6 个月半衰期」直接对冲——当技术半年翻新一半时，你需要的不是更频繁地重画蓝图，而是一个能让换代「热插拔」的平台。

一句话：ADM 负责「决定原则」（slow，季度级），AI 平台负责「执行原则」（fast，分钟级）。两者分工，速度差才有处安放。

---

四、裁剪方案：轻量 ADM + 持续架构

理论讲完，给出我作为架构师真正会落地的裁剪方案。原则只有一句：保留 TOGAF 的「原则」，舍弃它的「节奏假设」。 这与 Thoughtworks Vol. 34 的主题二「保留原则，放弃模式（retaining principles, relinquishing patterns）」是同一种精神。

4.1 三层裁剪

第一层——慢内核（Slow Core，季度级，仍用经典 ADM） 适用对象：那些 6 个月内不会过时的东西。例如企业的数据治理原则、合规边界、风险偏好、业务能力地图（Phase B 的核心）、安全基线。这些用完整 ADM 审议，值得慢。

第二层——快外壳（Fast Shell，持续架构，替代季度循环） 适用对象：AI 模型选型、Agent 框架、协议（MCP/A2A）、推理基础设施。这一层放弃「Phase A→D 走一遍」，改用：

• 持续架构（continuous architecture） 实践，嵌入 DevOps/MLOps 流水线（Mittal，2025-11）；
• 实时知识图谱替代静态架构图——架构现状从「文档」变成「可查询的运行时事实」；
• 治理冲刺（governance sprints）+ QuickScan 替代季度评审——把 Phase G 的实施治理拆成短周期、高频次的小评审。

第三层——代理治理层（Agentic Governance，运行时，由 AI 平台承载） 适用对象：代理的日常运行。把专精代理用于聚合、合规校验、风险评估、报告（agentic architecture governance，Mittal，2025-11），即「用 AI 治理 AI」，人类架构师从「画图」上移到「定原则、做仲裁」。

4.2 量化对比表（三，可选第三表强化论证）：经典 ADM vs 裁剪后「轻量 ADM + 持续架构」

4.3 关键取舍（trade-off）

• 得：治理跟得上技术速度，蓝图不再「出厂即过期」，开发提速 30–50% 的红利能被「干净架构」放大（Mittal，2025-11）。
• 失/风险：放弃部分审议会增加「治理债（governance debt）」与「认知债（cognitive debt，Vol. 34 主题一点名的过度依赖 AI 风险）」。对冲手段是把「慢内核」的边界守死——合规、风险、数据治理绝不进「快外壳」。

---

五、C4 治理视图：把上面的话画成图

最后用 C4 模型（Context / Container / Component / Code 四级）给出一个可复用的治理视图骨架。这里聚焦 Context 与 Container 两级，因为治理决策主要发生在这两层。

5.1 System Context（治理边界）

            ┌─────────────────────────────────────────────┐
            │            企业架构治理边界                    │
            │                                             │
  架构师 ───▶│  [慢内核: 轻量 ADM]   决定原则/合规/风险偏好   │
  (人)      │        │                                    │
            │        ▼ 编译为护栏                          │
  合规官 ──▶│  [AI 平台 = 企业操作系统]  执行原则(运行时)    │◀── 监管/MiCA/SEC
  (人)      │        │                                    │
            │        ▼ 治理                               │
            │  [agent topology: 编排/校验/领域专精代理]     │──▶ 外部模型 API
            │                                             │    (Claude / 开源)
            └─────────────────────────────────────────────┘

5.2 Container 视图（控制层内部）

[AI 平台 / 企业操作系统]
 ├── 身份与 RBAC 容器        ── 每个代理一个 principal，最小权限
 ├── 配额与 FinOps 容器       ── 调用/算力/成本配额，防跑飞
 ├── 策略即代码容器           ── 致命三连防护、数据边界、注入检测
 ├── 可观测性与熔断容器        ── 行为可追溯/回放/断路器
 ├── 实时知识图谱容器          ── 替代静态架构图，架构现状可查询
 └── 治理型代理容器           ── 自动做合规/风险/报告聚合（AI 治理 AI）
        ▲                          ▲
        │ 策略下发                  │ 高频小评审
   [慢内核: 轻量 ADM]          [治理冲刺 / QuickScan]

5.3 这张图的 EA 价值

它把本文三条主线缝合成一个可治理的整体：慢内核（第四节）定原则 → AI 平台（第三节）编译并执行原则 → agent topology（第二节）在护栏内运行 → 而整个循环用持续架构而非季度 ADM 驱动（第一节）。 架构师交付的不再是一份会过期的蓝图，而是一套会持续运行的治理操作系统。

---

结语：从「蓝图机构」到「治理操作系统」

回到引言的悖论：审议的节奏遇上 6 个月半衰期，企业架构师该怎么办？

我的答案是：别再试图让 ADM 跑得更快，而是让它管得更准——把它从一个「每季度产出蓝图」的机构，改造成一个「持续运行护栏」的操作系统。 TOGAF 的价值从来不是那十个阶段的仪式，而是它背后「让大变更可治理」的原则。当变更从「季度一次的大事」变成「每天发生的常态」时，治理就必须从「文档」下沉到「运行时」，从「人画图」上移到「人定原则、机器执行」。

The Open Group 截至 2026-06 还没给出 agentic AI 的官方标准，这个空白短期内不会消失。但对一个有 10 年金融零售经验、又懂 Web3 与 AI 的架构师来说，这恰恰是机会：谁先把「轻量 ADM + AI 平台 + agent topology」这套治理操作系统在真实金融/零售场景里跑通，谁就定义了下一代企业架构的事实标准。

---

SOTA 检查（2026-06-11 更新）

• TOGAF / The Open Group 官方 agentic AI 标准：截至 2026-06 仍为空白，无官方 ADM 扩展或参考架构。当前主流做法是从业者裁剪（Mittal 的「Lean TOGAF + 持续架构」，2025-11；George James Consulting 的「ADM 套用 AI」，2025）。仍是 SOTA，但属「事实标准」而非「官方标准」，存在被 The Open Group 后续官方框架替代的风险，需持续跟踪。
• agent topologies × team topologies：源自 Thoughtworks Technology Radar Vol. 34（2026-04），是**当前最新（< 3 个月）**的组织拓扑前沿命题，仍是 SOTA。下一卷 Radar（预计 2026-10 前后）可能深化或修正，需复查。
• MCP 状态：Vol. 34 将「MCP by default」降级到 Caution（2026-04），「致命三连」是当前主流风险框架。MCP 协议本身仍在快速演进，6 个月内状态可能再变——本文论点正是基于此「半衰期」现象，不受单点状态变化影响。
• AI 平台工程 =「企业操作系统」：The New Stack（2026-02）、platformengineering.org（2025-12）为主线，是近 6 个月内的主流叙事，仍是 SOTA。
• 量化数据时效：McKinsey 33%→78%（2025）、Gartner 40% / IDC 60%（2026 预测）、94%/73% 平台采用（2026）——均在 12 个月内，主线未过时。
• 是否有更新替代品：暂无更权威的「TOGAF × agentic」整合方案。若 The Open Group 在 2026 下半年发布官方 AI 治理扩展，本文「裁剪方案」需对齐复审。

本文非历史回顾。最新进展请跟踪：The Open Group 官网（TOGAF AI 扩展）、Thoughtworks Technology Radar 后续卷次、platformengineering.org 年度预测。

---

学习资源（含发布日期）

• Praveen Mittal，《The Paradox of Governance: When TOGAF's ADM Meets GenAI's Velocity》，Medium，2025-11。（核心论点来源：相位错位、Lean TOGAF、持续架构、33%→78%、30–50% 提速）
• Thoughtworks，《Technology Radar Vol. 34》，2026-04。（agent topologies、MCP→Caution、Claude Code→Adopt、致命三连、保留原则放弃模式）
• Thoughtworks，《Key themes in Technology Radar Vol.34》播客，2026-04。（四大主题：评估、原则、拴住代理、保护权限饥渴代理）
• The New Stack，《In 2026, AI Is Merging With Platform Engineering》，2026-02。（AI 平台作为企业操作系统、IDP 作为 AI 地基）
• platformengineering.org，《10 Platform Engineering Predictions for 2026》，2025-12。（代理作为一等公民、RBAC/配额/golden path）
• George James Consulting，《TOGAF Architecture for AI: Applying ADM to Enterprise AI Transformation》，2025。（ADM 套用 AI 的从业者实践）
• Amit Verma，《TOGAF in the Age of AI》，Medium，2025-09。（ADM 阶段显式纳入 AI 关注点）
• Gartner / IDC 行业预测，经多份 2025–2026 综述引用（40% 任务型代理 / 60% 多代理应用）。
• McKinsey GenAI 采用率调查，2025（33%→78%）。