AI 底层逻辑 / 经典论文
AI Architecture Views：C4 / arc42 / 42010
AI Architecture Views 的重点不是“多画几张图”, 而是建立一个架构表达系统: 每张 view 都服务一个明确 concern, 每个 concern 都能连接到业务价值、架构决策、运行机制、风险控制和证据来源。
317 行ai-foundations/papers/87-ai-architecture-views-c4-arc42-42010.md
AI Architecture Views / C4 / arc42 / 42010 解读
配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是
docs/AI_ARCHITECTURE_VIEWS_C4_ARC42_42010_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。
核心问题: 企业 AI 架构不能只靠一张“模型 + RAG + 工具”的大图。真正可评审、可交付、可审计、可演进的 AI 架构, 必须把同一个系统拆成面向不同 concern 的一组一致视图。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| C4 Model | https://c4model.com/ | 参考 context、container、component、code 四层架构表达, 将 AI 系统从企业边界到内部组件逐层展开（持续更新的官方站点, 访问日期: 2026-07-01） |
| arc42 | https://arc42.org/ | 参考结构化软件架构文档模板, 把需求、约束、上下文、构件、运行时、部署、质量和风险组织成文档（持续更新的官方站点, 访问日期: 2026-07-01） |
| ISO/IEC/IEEE 42010 | https://www.iso.org/standard/74393.html | 参考 architecture description、stakeholder、concern、viewpoint、view 的概念关系（现行第二版标准 2022-11） |
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 把 AI 架构视图连接到风险、治理、测量、监控和管理活动（AI RMF 1.0 / AI 100-1 发布 2023-01；Generative AI Profile / AI 600-1 发布 2024-07） |
| OpenTelemetry | https://opentelemetry.io/docs/ | 为运行时视图、trace、metrics、logs、SLO 和证据链提供观测锚点（持续更新的官方文档, 访问日期: 2026-07-01） |
核心导读
AI Architecture Views 的重点不是“多画几张图”, 而是建立一个架构表达系统: 每张 view 都服务一个明确 concern, 每个 concern 都能连接到业务价值、架构决策、运行机制、风险控制和证据来源。
C4 负责分层讲清系统边界和构件关系; arc42 负责把约束、运行时、质量属性、风险和决策写成可维护文档; ISO/IEC/IEEE 42010 提醒我们先定义 concern 和 viewpoint, 再生成 view。对 AI 产品, 还必须补上 data/knowledge、tool/action、eval/control、observability/evidence 这些传统软件图经常忽略的视图。
最终目标是让 AI 架构从“演示图”升级为“共同决策语言”: 业务能判断价值, 工程能落地边界, 风险能检查控制, 运营能监控漂移, 审计能追溯证据。
问题定义
很多 AI POC 的架构图都可以简化成:
User -> UI -> LLM -> RAG -> Tools -> Backend
这类大图能解释系统大概如何运行, 但无法支撑严肃评审:
| Concern | 单一大图的缺口 |
|---|---|
| 业务价值 | 看不出 AI 支撑哪个 capability、改变哪段 value stream、收益假设如何验证 |
| 产品边界 | 看不出 MVP 范围、失败体验、人工交接、用户透明度和采用路径 |
| 系统边界 | 看不出哪些组件是平台能力、哪些是业务差异化、哪些接口需要契约 |
| 数据治理 | 看不出知识源 owner、权限、freshness、lineage、retention |
| 工具行动 | 看不出哪些 action 可读、可写、需审批、可回滚或不可逆 |
| 评测质量 | 看不出需求如何转为 eval、阈值和 release gate |
| 风险控制 | 看不出 advice boundary、PII、prompt injection、tool misuse 在哪里被拦截 |
| 运行治理 | 看不出 trace、metrics、logs、成本、延迟、人工 override、incident path |
| 审计证据 | 看不出 ADR、eval report、approval、control evidence 如何形成证据链 |
AI 架构表达因此要从“画系统拓扑”转为“组织决策视图”:
Concern
-> Viewpoint
-> View
-> Architecture element
-> Decision / Control / Evidence
如果一个视图不能支持具体决策, 它只是说明材料; 如果一个关键决策没有视图支撑, 它就是隐藏假设。
架构模型/核心原理
42010: 从 concern 出发组织 architecture description
ISO/IEC/IEEE 42010 的关键启发是: 架构描述不是一份万能文档, 而是一组围绕 concern 组织的 view。
| Concept | 在 AI 架构中的含义 |
|---|---|
| Stakeholder | 与系统成败、风险、运行或审计相关的人和组织 |
| Concern | 价值、体验、准确性、安全、隐私、成本、延迟、可审计、可恢复、可扩展 |
| Viewpoint | 表达 concern 的规则和形式, 如 C4 context、runtime sequence、control evidence view |
| View | 按 viewpoint 生成的具体图、表、矩阵、ADR 或 dashboard |
| Architecture description | 所有 view、约束、假设、ADR、风险、证据的整体集合 |
AI 系统常用 viewpoint catalog:
| Viewpoint | 回答的问题 | 常见产物 |
|---|---|---|
| Business Capability View | AI 改善哪些业务能力和价值流 | capability map、value stream map |
| Product Journey View | 用户如何使用, 失败如何交接 | journey map、service blueprint |
| C4 Context View | 系统边界、外部角色和依赖是什么 | context diagram |
| C4 Container View | 主要应用、服务、数据 store、网关如何协作 | container diagram |
| C4 Component View | 编排、retrieval、tool、eval、policy 的职责边界 | component diagram |
| Runtime / Sequence View | 一次请求如何流过模型、检索、工具、审批和降级 | sequence diagram |
| Data / Knowledge View | 知识源、权限、版本、lineage、retention 如何治理 | data flow、knowledge lineage |
| Tool / Action View | AI 能执行哪些动作, 需要哪些审批和审计 | tool contract map、side-effect matrix |
| Eval / Quality View | 需求如何转成评测和上线门槛 | eval contract、quality gate |
| Control / Evidence View | 控制在哪里执行, 证据如何产生和保留 | control-evidence graph |
| Deployment / SLO View | 部署拓扑、SLO、成本、回滚和容灾如何设计 | deployment diagram、SLO dashboard |
| Evolution View | 哪些能力会平台化、替换、退役或反转 | roadmap、ADR log |
C4: 分层表达边界和责任
C4 的价值是把一个复杂系统按粒度展开, 避免在一张图里混杂业务、部署、组件、代码和控制。
| C4 层级 | AI 系统中应回答的问题 |
|---|---|
| Context | AI capability 在业务生态中处于什么位置, 依赖哪些人、系统、数据源、模型和监管约束 |
| Container | 哪些运行单元承担 UI、orchestration、model gateway、retrieval、tool gateway、policy、eval、observability |
| Component | 每个容器内部哪些组件做分类、检索、上下文组装、模型调用、工具规划、策略判断、响应合成 |
| Code | 只在高风险实现处展开, 如 tool wrapper、policy enforcement、permission filter、telemetry propagation |
Customer-facing RAG/Agent 的 context 可表达为:
Customer
-> Digital Banking App
-> AI Service Assistant
-> Approved Model Gateway
-> Retail Policy Knowledge Base
-> Case Management System
-> Human Service Queue
-> Observability / Evidence Platform
Risk Reviewer
-> Evidence Binder
Auditor
-> Control Evidence Index
Context 层必须明确 AI 的行动等级: 它只是建议、生成草稿、自动执行低风险写入, 还是参与高影响决策。行动等级决定评测门槛、人工复核和审计要求。
arc42: 把架构讨论固化为可维护资产
arc42 的价值是把“会议讨论过的架构”整理成稳定结构:
| arc42 Section | AI 系统中的写法 |
|---|---|
| Introduction and Goals | 业务 outcome、AI capability、非目标、风险等级 |
| Constraints | 法规、数据、模型供应商、预算、延迟、人工复核、审计 |
| Context and Scope | C4 context、system boundary、external systems、trust boundary |
| Solution Strategy | RAG/agent/fine-tuning/model routing/platform reuse 的取舍 |
| Building Block View | C4 container/component, 平台服务与业务服务边界 |
| Runtime View | request flow、tool call flow、HITL flow、incident flow |
| Deployment View | region、network、model endpoint、data store、observability、DR |
| Crosscutting Concepts | policy、identity、logging、eval、prompt/versioning、data lineage |
| Architecture Decisions | model choice、RAG design、tool gateway、human oversight、rollback trigger |
| Quality Requirements | groundedness、latency、cost、privacy、auditability、resilience |
| Risks and Technical Debt | prompt debt、data debt、eval gap、vendor lock-in、control gap |
| Glossary | domain terms、model/eval/control terminology、risk vocabulary |
对 AI 产品, arc42 不应变成文档填空, 而应承载三类长期资产: 约束与取舍、运行时机制、质量与风险证据。
关键机制
AI-specific view set
AI 架构比传统业务系统多出四个必须显式表达的面:
| View | 必须表达的机制 |
|---|---|
| Data / Knowledge View | source registry、owner、authority level、permission filter、freshness、chunking、embedding/rerank、citation lineage、retention |
| Tool / Action View | tool contract、side effect、approval rule、idempotency key、compensation、audit event |
| Eval / Control View | requirement、risk、eval case、metric、threshold、control、release decision 的映射 |
| Runtime Observability View | trace span、model route、prompt version、retrieval source version、policy decision、cost、latency、feedback、incident link |
这些 view 解决的是 AI 系统的真实不确定性: 知识会变、模型会漂移、工具有副作用、输出需要证据、线上行为会偏离设计假设。
Container 责任边界
AI container view 常见运行单元:
| Container | 核心责任 |
|---|---|
| Experience App | UI、透明度提示、引用展示、人工交接、反馈采集 |
| Orchestration Service | prompt assembly、workflow state、model call、tool routing |
| Model Gateway | approved model list、routing、quota、logging、fallback |
| Retrieval Service | source selection、permission filter、hybrid search、rerank、citation |
| Tool Gateway | tool contract、policy check、approval、idempotency、audit |
| Eval Service | offline eval、regression eval、judge/human review、release gate |
| Policy Engine | allowed use、data boundary、action policy、exception |
| Observability Stack | trace、metrics、logs、cost、quality、safety signals |
| Evidence Binder | ADR、eval report、approval、monitoring、incident evidence |
这张 view 的关键不是列组件, 而是判断哪些能力应该平台化。Model gateway、tool gateway、policy、eval、observability、evidence 通常不应散落在每个业务应用里。
Component 决策点
以 Orchestration Service 为例, 组件图应呈现“谁在做决策”:
| Component | 输入 | 输出 | 风险点 |
|---|---|---|---|
| Request Classifier | user intent、context | route、risk tier | 错分高风险请求 |
| Context Assembler | user state、retrieval result、policy | prompt context | 泄露无权限信息 |
| Prompt Version Resolver | task type、locale、version | prompt version | prompt drift |
| Model Caller | prompt、model route | model response | latency、cost、model behavior change |
| Tool Planner | model response、workflow state | candidate tool calls | 不安全工具选择 |
| Policy Adapter | action、data、risk tier | allow/block/approve | 策略缺口 |
| Response Composer | answer、citation、confidence | user response | 过度自信、引用错误 |
| Telemetry Emitter | trace context | spans、metrics、events | 证据缺失 |
每个组件要能回答四个问题: 做什么决定、依赖什么输入、失败后如何降级、由哪个 eval 或 control 覆盖。
Tool/action 分级
Agent 架构的分水岭是 action:
| Action type | 示例 | 默认控制 |
|---|---|---|
| Read-only | 查询账户状态、读取 case | RBAC/ABAC、purpose logging |
| Draft | 生成回复草稿、生成 case note | 人工确认、版本记录 |
| Low-risk write | 更新标签、创建低风险任务 | schema validation、audit |
| High-risk write | 退款、冻结账户、提交监管报告 | HITL、dual control、approval id |
| Irreversible action | 资金移动、客户通知、永久删除 | 严格禁止或强人工授权 |
如果 tool/action view 没有表达副作用和审批规则, 架构图就低估了 agent 风险。
证据与控制
AI 架构视图必须能落到 control 和 evidence, 否则无法支持上线决策。
| Requirement / Risk | Architecture view | Control | Evidence |
|---|---|---|---|
| 回答必须基于批准知识源 | Data / Knowledge View | source allowlist、stale source block | citation source version、eval report |
| 不提供个性化金融建议 | Eval / Control View | policy classifier、refusal template | red-team eval、policy logs |
| 工具调用必须可审计 | Tool / Action View | tool gateway audit span | trace id、approval id、tool result |
| 高风险 case 必须人工复核 | Runtime View | HITL queue、dual approval | reviewer record、SLA dashboard |
| 运行漂移必须可发现 | Deployment / SLO View | trace completeness、quality sampling | OpenTelemetry trace、monitoring dashboard |
| 架构取舍必须可追溯 | Evolution View | ADR、reversal trigger | ADR log、release memo |
运行时观测视图应至少覆盖:
request span
-> policy classification span
-> retrieval span
-> rerank span
-> model call span
-> tool planning span
-> policy decision span
-> HITL span
-> response span
-> feedback / outcome event
关键 telemetry 包括 prompt version、model route、retrieval source version、policy decision、tool contract version、human override、latency、cost、blocked action、incident link。没有这些字段, 事故复盘和审计都会退化为人工翻日志。
AI产品/金融零售场景
Customer-facing policy assistant
目标: 为银行客户解释费用、账户、贷款和争议流程, 同时支持客服人员更快给出一致回答。
| View | 需要讲清的内容 |
|---|---|
| Business Capability | 降低人工处理时间、提升 first contact resolution、降低错误解释和投诉 |
| Product Journey | 用户提问、系统澄清、引用展示、拒答、人工升级、反馈闭环 |
| C4 Context | 客户、数字银行 App、AI assistant、policy KB、case system、human queue、evidence binder |
| C4 Container | UI、orchestrator、model gateway、retrieval service、policy engine、HITL、observability |
| Runtime | classify intent/risk -> retrieve approved policy -> generate cited answer -> policy check -> escalate if needed |
| Knowledge | source registry、effective date、document owner、permission filter、citation id |
| Tool / Action | 查询 case、生成草稿、创建内部 note; 不自动退款或发送客户通知 |
| Eval / Control | groundedness、citation correctness、refusal、escalation、latency/cost |
| Evidence | ADR、eval report、risk signoff、launch approval、trace sample、incident log |
典型 ADR:
| ADR | Decision | Reason |
|---|---|---|
| ADR-001 | Use RAG over fine-tuning for policy knowledge | 政策变化频繁, 需要引用和版本控制 |
| ADR-002 | Route all tool actions through Tool Gateway | 统一权限、审批、幂等和审计 |
| ADR-003 | Require citation and no-answer path for customer-facing answers | 控制 hallucination 和过度自信 |
| ADR-004 | Escalate suitability and high-impact questions to humans | 降低不当建议和高影响自动化风险 |
这个场景的架构成熟度不体现在是否用了更强模型, 而体现在视图是否覆盖了业务价值、知识治理、行动边界、评测门槛、运行证据和演进路径。
反模式
| 反模式 | 表现 | 修正 |
|---|---|---|
| Everything diagram | 一张图塞满组件、数据、风险、流程和部署 | 按 concern 拆分 view, 用 traceability 保持一致 |
| Vendor diagram | 图里只有模型供应商、UI 和几个箭头 | 加入企业控制面、数据面、工具面、证据面 |
| Static-only architecture | 只有静态框图, 没有正常路径、失败路径、HITL 和 incident path | 增加 runtime sequence 和 operational view |
| No data ownership | RAG 只画 vector DB, 不画 source owner、版本、权限和 freshness | 建立 knowledge lineage view |
| Tool side effects hidden | 工具只被画成 API, 不表达副作用和审批 | 建立 action classification 和 tool gateway view |
| Eval detached from architecture | 评测集存在, 但不知道覆盖哪些组件和风险 | eval/control view 映射 requirement、component、risk |
| Evidence afterthought | 上线后才补日志和审批材料 | architecture view 预先定义 evidence contract |
| No evolution | 架构像一次性项目 | 增加 ADR、reversal trigger、platform reuse、deprecation path |
最终心智模型
AI 架构视图系统可以用一句结构化关系理解:
Concern defines viewpoint.
Viewpoint produces view.
View exposes decision.
Decision creates control.
Control emits evidence.
Evidence drives evolution.
学习 C4、arc42 和 42010, 不应停留在“会画图、会套模板”。真正重要的是建立一套可复用的架构表达纪律:
| 层次 | 核心判断 |
|---|---|
| 业务 | AI 是否改变了值得投资的 capability 和 value stream |
| 产品 | 用户旅程、失败体验、透明度和人工交接是否被设计 |
| 系统 | 边界、依赖、复用点、供应商替换和部署拓扑是否清楚 |
| 数据 | 知识源、权限、版本、lineage 和 retention 是否可治理 |
| 行动 | tool side effect、审批、幂等、补偿和审计是否明确 |
| 质量 | requirement 是否转成 eval、threshold 和 release gate |
| 风险 | policy、security、privacy、HITL 和 exception 是否可执行 |
| 运行 | trace、SLO、cost、feedback、incident 是否能回连到架构 |
| 演进 | ADR、技术债、平台化、退役和反转条件是否可追踪 |
成熟的 AI 架构不是一张大图, 而是一组能共同回答“为什么这样做、如何安全运行、如何证明有效、未来如何改变”的视图。
SOTA 检查 (2026-07-01)
- 框架层结论仍然成立: ISO/IEC/IEEE 42010:2022（2022-11 发布的第二版）仍是 architecture description 的现行标准, arc42 十二节模板与 C4 四层模型截至 2026-07 均无被替代迹象。本篇的核心框架性结论——
Concern → Viewpoint → View → Decision → Control → Evidence的组织纪律——不随模型/工具版本过时, 是可长期复用的部分。 - 本篇“传统视图对 AI 不够用”的判断已被学术界正式确认: RAD-AI（arXiv 2603.28735, 2026-03）是首个向后兼容的 arc42/C4 扩展——为 arc42 增补 8 个 AI 专属 section、为 C4 增补 3 类图, 并系统映射到 EU AI Act Annex IV 技术文档要求, 与本篇自行提出的 data/knowledge、tool/action、eval/control、observability/evidence 四个补充视图方向一致。注意: EU AI Act Annex III 高风险义务已推迟至 2027-12-02（Omnibus, 2026-05 确认）, 引用其合规映射时按新时间线执行。
- C4 表达 agentic 系统已有工业实践论文: 《Describing Agentic AI Systems with C4: Lessons from Industry Projects》（arXiv 2603.15021, 2026-03）给出面向 agent、artifact、tool 调用与协调模式（含 quality gate）的建模词汇, 并按 C4 抽象层级分层组织——与本篇的 Tool/Action View、组件级“谁在做决策”表格属于同一方向, 可作为该视图集的外部佐证与升级读物。
- 风险/证据锚点需按最新文档引用: NIST AI RMF 应区分基础框架（AI 100-1, 2023-01）与 Generative AI Profile（NIST AI 600-1, 2024-07, 定义 12 类 GenAI 特有风险及 govern/map/measure/manage 行动）; 本篇“证据与控制”一节的 requirement→control→evidence 映射, GenAI 场景下建议直接锚到 AI 600-1 的行动条目。
- 文档形态趋势: 2026 年的新趋势是“架构文档作为活系统”——已出现基于 MCP server 的 arc42 文档生成/追踪工具与 LLM 自动化架构文档研究（如 CIAO, arXiv 2604.08293, 2026-04）, 即视图的生成与代码保持持续对齐; 这不改变本篇的视图组织原则, 只改变维护成本假设。落地操作仍以库内配对手册
docs/AI_ARCHITECTURE_VIEWS_C4_ARC42_42010_PLAYBOOK.md为准。