AI 底层逻辑 / 经典论文
Enterprise AI Reference Architecture：控制平面
Enterprise AI Reference Architecture 是企业 AI 系统的 shared mental model。它把体验、编排、模型、数据/知识、工具、策略控制、评估、可观测性和治理证据拆成可复用、可控制、可演进的架构平面。
211 行ai-foundations/papers/79-enterprise-ai-reference-architecture-control-plane.md
Enterprise AI Reference Architecture / Control Plane 解读
配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是
docs/AI_ENTERPRISE_REFERENCE_ARCHITECTURE_CONTROL_PLANE_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 用 Govern / Map / Measure / Manage 定义风险治理、评估、监控和持续管理（AI RMF 1.0 发布 2023-01） |
| ISO/IEC 42001 | https://www.iso.org/standard/81230.html | 参考 AI management system、职责、运营、绩效评估和持续改进（标准发布 2023-12） |
| OpenTelemetry | https://opentelemetry.io/docs/ | 参考 trace、metric、log 的可观测性语言, 映射到 AI telemetry（持续更新文档，访问日期: 2026-07-01） |
| NIST Cybersecurity Framework 2.0 | https://www.nist.gov/cyberframework | 将 AI 参考架构和 identify / protect / detect / respond / recover 的安全运营语言连接（CSF 2.0 发布 2024-02） |
核心导读
Enterprise AI Reference Architecture 是企业 AI 系统的 shared mental model。它把体验、编排、模型、数据/知识、工具、策略控制、评估、可观测性和治理证据拆成可复用、可控制、可演进的架构平面。
这篇的核心判断是: 企业 AI 不能让每个 use case 自己解决模型接入、RAG、工具权限、日志、评估、风控、审计和运营。参考架构的价值不是统一所有产品形态, 而是统一高风险、重复和需要治理的控制面。
问题定义
单个 AI use case 常被画成:
User -> App -> LLM -> Response
生产级企业 AI 实际更像:
User / Employee / System
-> Product experience
-> Workflow / agent orchestration
-> Context / retrieval / memory
-> Model gateway / routing
-> Tool gateway / business systems
-> Policy / control plane
-> Eval / observability / incident loop
-> Evidence / governance / audit
如果没有参考架构, 会出现:
- 每个团队自己接模型, 成本、隐私、日志和 vendor risk 不一致。
- 每个团队自己做 RAG, 知识源权限、版本、引用和 freshness 不一致。
- 每个团队自己做 tool calling, 权限、幂等、审批、回滚和审计不一致。
- 每个团队自己定义 eval, 质量门槛不可比较。
- 风险团队只能上线前人工审查, 无法持续监控。
- 平台团队变成接需求团队, 无法产品化横向能力。
参考架构要解决的是“哪些能力必须共享, 哪些边界必须一致, 哪些变体允许业务线配置”。
核心原理/方法
八层参考架构:
| Plane | 核心职责 | 典型组件 | 关键设计问题 |
|---|---|---|---|
| Experience / Application | 用户、员工、客户、API 的交互入口 | Web/mobile、agent UI、copilot、case screen、API | 用户知道 AI 边界吗, 如何反馈和转人工 |
| Orchestration / Workflow | 管理任务流、状态、工具调用和人工节点 | workflow engine、agent runtime、state machine、HITL queue | 何时自动、何时人工、何时补偿和回滚 |
| Model | 模型接入、路由、调用、版本和成本 | model gateway、router、cache、small/frontier model | 哪个任务用哪个模型, 如何隔离 vendor risk |
| Data / Knowledge | 业务数据、知识源、检索、特征和上下文 | RAG、knowledge graph、feature store、semantic layer | 哪些数据可用、可外发、可引用、可删除 |
| Tool / Action | AI 可调用的业务系统和外部动作 | tool gateway、API connectors、event bus、business services | 工具权限、幂等、审批、审计和副作用 |
| Policy / Control | 策略、权限、风险分层、控制和门禁 | policy engine、risk tiering、DLP、guardrails、kill switch | 哪些行为允许、拒绝、升级或暂停 |
| Eval / Observability | 上线前评估、线上监控、质量和成本 | eval harness、trace、metrics、logs、dashboard、alerts | 如何证明质量、成本、风险和体验可控 |
| Governance / Evidence | 证据、审计、管理评审和持续改进 | AI inventory、ADR、system card、evidence binder | 如何回答审计、监管、管理层和事故复盘 |
参考架构不是所有 use case 的同一张部署图, 而是一组原则和能力边界。业务产品可变, control plane 和 evidence plane 必须一致。
系统/架构模型
Control plane 与 data plane 必须明确分离。
Data plane 处理实际请求、上下文、模型输出和工具动作:
request -> context -> model -> tool/action -> response
Control plane 决定请求能不能走、走哪条路径、需要什么证据:
risk tier
-> policy decision
-> model route
-> tool permission
-> eval gate
-> monitoring threshold
-> evidence capture
| Control Plane Capability | 作用 | 例子 |
|---|---|---|
| Risk classifier | 按任务、用户、数据、动作影响分层 | 客服问答 low, 信贷解释 high |
| Policy engine | 决定 allow / deny / escalate / redact | PII 外发拦截、投资建议边界 |
| Model gateway | 统一接入、路由、记录、限流 | approved model allowlist |
| Tool gateway | 控制工具权限和副作用 | read-only、approval-required、write action |
| Eval gate | 上线前和变更前强制评估 | prompt/model/RAG release gate |
| Observability | 记录 trace、latency、cost、quality、risk | request span、retrieval span、tool span |
| Evidence capture | 将决策、版本和审批沉淀为证据 | ADR、eval report、audit log |
如果没有 control plane, 每个 AI application 都会变成自己的治理孤岛。
关键机制与取舍
参考架构至少需要五种视图:
| View | 回答的问题 | 典型产物 |
|---|---|---|
| Capability view | 企业需要哪些 AI 能力 | capability map、platform service catalog |
| C4 / container view | 系统组件如何部署和集成 | context/container/component diagram |
| Sequence view | 一次请求如何穿过策略、检索、模型、工具和日志 | sequence diagram、trace design |
| Control view | 哪些风险由哪些控制处理 | risk-control matrix、policy flow |
| Operating view | 谁负责运营、变更、事故、复盘和改进 | RACI、runbook、review cadence |
关键取舍:
- 共享平台降低重复建设和治理成本, 但会增加平台产品化、SLO 和支持负担。
- 统一 control plane 有利于风险一致性, 但业务线必须能配置知识源、阈值、话术和流程。
- 单一供应商平台能加速早期交付, 但可能造成数据、评估、日志和退出策略锁定。
- 自建参考架构能增强控制, 但必须避免把所有能力都做成内部重资产。
证据与控制
参考架构必须支撑持续 assurance:
| 证据/控制 | 作用 |
|---|---|
| AI inventory | 记录 use case、risk tier、owner、模型、数据、工具和状态 |
| Architecture decision record | 记录模型、RAG、工具、平台和控制选择 |
| Eval report | 证明质量、安全、风险和回归门槛 |
| Trace schema | 统一 request、retrieval、model、tool、human 和 outcome event |
| Policy decision log | 记录 allow/deny/escalate/redact 的理由 |
| Evidence binder | 聚合 release、approval、exception、incident 和 review 证据 |
| Incident runbook | 定义 detect/respond/recover 和 communication |
| Control effectiveness review | 定期检查控制是否真的拦住风险 |
参考架构的成熟度可以用这些问题评估:
- 能否回答某个 AI 决策用了哪个模型、哪个知识版本、哪个工具权限。
- 能否解释为什么某个请求被允许、拒绝、脱敏或升级。
- 能否在 prompt、model、RAG、tool 变化后自动触发 eval gate。
- 能否在事故后快速定位影响范围和回滚路径。
AI产品/金融零售场景
Shared AI case assist platform
适用场景:
- AML alert triage。
- 信贷运营 case summary。
- 客服投诉摘要。
- KYC 文档检查。
共享能力与可变点:
| Shared Capability | 可复用部分 | 业务线可变部分 |
|---|---|---|
| Case summarization | summary schema、citation requirement、eval rubric | 字段、政策、话术 |
| Document extraction | OCR/extraction pipeline、confidence threshold | 文档类型、验证规则 |
| Policy RAG | source registry、permission filter、citation | policy corpus、jurisdiction |
| HITL queue | review workflow、override reason、SLA | reviewer role、priority rules |
| EvalOps | golden set tooling、judge calibration、report | scenario set、threshold |
| Audit evidence | trace id、version capture、approval log | retention、report format |
架构目标不是做一个万能 AI 应用, 而是把 case summary、policy RAG、人工复核、审计 trace 和 eval 做成共享能力, 让业务线配置知识源、流程、阈值、话术和风险边界。
客户 facing AI
客户 facing 场景必须在参考架构中显式经过 disclosure、advice boundary、appeal path、policy engine、source citation 和 complaint monitoring。不能只复用员工端 copilot 的模型链路。
反模式
| 反模式 | 表现 | 修正 |
|---|---|---|
| App-centric architecture | 每个 use case 自己接模型和工具 | 建 reference architecture 和 shared control plane |
| Control plane missing | 策略和风险只在文档里 | policy engine、gateway、eval gate、evidence capture |
| RAG sprawl | 各团队自建知识库 | source registry、permission filter、freshness SLO |
| Eval inconsistency | 每个团队自定义通过标准 | EvalOps、risk-tiered threshold、report format |
| Tool calling without action governance | API 调用可用但无幂等、审批、回滚 | tool gateway and side-effect policy |
| One big platform | 所有业务差异都被平台统一掉 | shared core + configurable variation points |
最终心智模型
Enterprise AI Reference Architecture 的最终心智模型是:
应用可以多样;
模型可以替换;
业务知识可以分域;
但控制面、评估面、观测面和证据面必须统一。
企业 AI 的规模化不是把一个 demo 复制到多个部门, 而是建立一套能支撑多条业务线持续交付、监控、审计、回滚和演进的架构底座。参考架构真正保护的是企业的学习能力和控制能力。
SOTA 检查 (2026-07-01)
- 「Agent control plane」已从本篇的抽象概念变成 2026 年的商用产品品类: GitHub Enterprise AI Controls + agent control plane 于 2026-02-26 GA (统一 agent 的身份、权限、策略与执行监督); Futurum 发布 Agent Control Plane Framework 参考模型; Bain 对 Google Cloud Next 2026 的解读将 Agent Identity / Agent Gateway / Agent Registry 列为「agentic enterprise control plane」核心平台能力。本篇 policy engine + model/tool gateway + evidence capture 的拆分与这一代产品形态一致, 主线仍成立。
- Policy engine 层出现两个可直接对标的实现: Microsoft Agent Governance Toolkit (开源, 2026-04-02 发布) 提供确定性、亚毫秒级策略执行, 覆盖 OWASP agentic AI 十大风险; Databricks Unity AI Gateway (Data + AI Summit 2026, 2026-06) 把治理从 catalog 扩展到 model 调用、tool 调用、MCP 服务与 agent workflow 的运行时拦截。这正是本篇「Policy / Control plane」从文档走向 runtime 的实例。
- 治理标准侧进展: NIST AI RMF 于 2025-03 更新补充生成式 AI、供应链与第三方模型评估内容, 2025-12 发布 Cybersecurity Framework AI Profile 初稿, 2026-04 发布关键基础设施可信 AI profile 概念说明; NIST 已发布 AI RMF ↔ ISO/IEC 42001 官方 crosswalk (两者互补: RMF 自愿指南, 42001 可认证 AIMS); 新加坡 IMDA 于 2026-01 发布全球首个面向 agentic AI 的 Model AI Governance Framework (引入 Agent Identity Cards 披露格式)。本篇 Source Anchors 的 NIST/ISO 锚点仍是现役主线, 但读时应叠加上述增量。
- 时间线勘误提醒: 2026 年不少资料仍写「EU AI Act 高风险义务 2026-08 生效」——该时间线已过时, Annex III 高风险义务经 Digital Omnibus (2026-05-07) 推迟至 2027-12-02, 引用监管期限时以推迟后为准。
- 行业成熟度缺口佐证本篇问题定义: 2026 年多数组织的 agent 已进生产但控制最小化、治理非正式 (Gravitee《State of AI Agent Security》与 obot 治理趋势报告的共同结论), 即本篇「app-centric、control plane missing」反模式是当前普遍现状而非假想敌。
- 不随版本过时的框架性结论: control plane 与 data plane 分离、八平面能力边界、「应用可多样但控制/评估/观测/证据面必须统一」、shared core + configurable variation points——这些是架构判断而非具体产品选型, 在 2026 年的 agent 平台竞争中反而被各家产品验证。落地操作细节仍配对
docs/AI_ENTERPRISE_REFERENCE_ARCHITECTURE_CONTROL_PLANE_PLAYBOOK.md。
主要来源: GitHub Changelog (2026-02-26) · Microsoft Agent Governance Toolkit (2026-04-02) · Databricks Unity AI Gateway @ DAIS 2026 · Futurum Agent Control Plane Framework · Bain: Google Cloud Next 2026 · NIST AI RMF 2025–2026 updates · Gravitee State of AI Agent Security (均访问于 2026-07-01)