S29 · 总 Day 119教材已备 ≠ 学习已完成

S29：AI Platform 分层、Service Catalog 与 Golden Path

AI 平台把反复出现的数据、模型、运行、安全、评测和观测能力产品化为可发现、可组合的共享服务，并通过 golden path 降低团队认知负担而不隐藏关键边界。

2026-12-21platformengineering、control/data/runtime/evidenceplane、goldenpath

内容类型：预习教材（不代表已完成）
日期：2026-12-21
阶段：P2 · AI Systems Engineering 90
总路线：Day 119 / 360
周次 / 节奏：W5 · 周一概念与阅读
状态：教材已备；学习未完成
主题：platform engineering、control/data/runtime/evidence plane、golden path

一句话定义

学习目标

能区分 control、data、runtime 与 evidence plane 的职责和交互。
能解释 service catalog、tenant、quota、golden path 与 platform as product。
能识别共享平台能力与具体业务用例责任的边界。
能分析标准化、灵活性、锁定和治理之间的取舍。

核心知识

Control plane 管理声明、版本、策略、租户和部署意图；data plane 承载业务数据、特征、索引与输入输出流；runtime plane 执行模型、Agent、工具和 workflow；evidence plane 汇聚 trace、eval、audit、成本和发布证据。这是学习用分层，不是强制所有企业采用四套物理系统。逻辑职责可以分离，技术部署可以合并。

Service catalog 让团队知道平台提供哪些能力、接口、所有者、支持级别与使用边界，例如模型 endpoint、embedding/index、tool gateway、eval runner 和 telemetry。Golden path 是针对常见用例的一条受支持默认路径：模板、最少配置、安全默认、观测和示例。它应允许合理 escape hatch，并明确脱离默认后谁承担维护与风险。

Tenant 是资源、身份、数据和成本归属的隔离单位，不必等同组织部门。Quota 用来保护共享容量和预算，可以按 requests、tokens、并发、存储或成本定义。平台作为产品需要用户研究、采用指标、文档和反馈，不是建完基础设施等待团队使用。

平台团队负责 paved road 和共享约束，应用团队仍负责业务目标、数据合法性、domain eval、人工流程和结果风险。把所有责任上推平台会让抽象失真，把所有能力留给应用又造成重复和不一致。

机制与推导

一个用例声明 U 进入 control plane：

UseCase manifest
  → policy/identity/quota resolution
  → runtime + data bindings
  → request execution
  → evidence correlated to owner/version/cost

平台价值可用“第二个及后续用例的边际接入成本下降”理解，而不是服务数量。总认知负担可粗分：C_total = C_domain + C_platform_interface + C_escape + C_operations。Golden path 降低平台接口与运维成本，但抽象过厚会增加 debug 与 escape 成本。

控制面不可用不一定意味着数据面已运行服务立即停止；两者的故障耦合取决于设计。反之，控制面策略传播延迟可能让旧策略继续运行，因此需明确 desired state、observed state 与 reconciliation。

最小练习或观察步骤

选一个“合规知识助手”用例，画四个 plane 和请求/证据流。
列一个 6 项 service catalog：每项写用户、接口、owner 与非目标。
画 golden path：登记用例→绑定数据/模型/工具→运行→观察。
给出两个 escape hatch：为何需要、离开默认后谁负责。
写平台团队与用例团队各 5 项责任，检查是否把业务风险错误转移。

常见误区与边界

平台等同 Kubernetes、模型网关或一个统一 UI；工具不是产品边界。
Golden path 变成唯一强制路径，没有逃生口或迁移策略。
Service catalog 只列名称，不写 owner、SLO、版本与非目标。
所有日志、数据和模型集中后便称多租户隔离。
用平台采用率代替业务成效，或把本地教学组件描述为企业平台。

系统场景连接

金融机构可能同时建设客服摘要、调查辅助、政策问答和开发 Agent。共享身份、模型接入、工具策略、eval、trace 与成本归属可由平台提供；每个用例的数据 purpose、领域正确性和人工审批仍由业务负责。Web3/金融资产可作为安全的学习用例，但真实凭证、客户数据和链上写操作不进入本地实验。

自检问题

四个 plane 各自的核心状态是什么？
Golden path 与硬性强制标准有什么差别？
Tenant 为什么不必等同组织部门？
哪些责任不应因平台存在而从用例团队消失？

专业课程对齐

阅读 Full Stack Deep Learning 2022 的 development infrastructure、deployment 与 monitoring 讲次，将反复能力整理为平台 catalog，而非照搬技术栈。
阅读 Stanford CS329S 的 project lifecycle 与 system design 内容，关注平台抽象最终必须服务 stakeholder 目标和生产反馈。
阅读 CMU Deep Learning Systems 的训练/推理 runtime 内容，辨认底层执行与上层 control/evidence plane 的接口边界。

深入学习提示

先从第二个用例开始思考：第一例哪些能力值得复用，哪些是领域特有。为每项 catalog 服务写“用户无需再理解什么”和“仍必须理解什么”，防止抽象掩盖风险。阅读平台案例时寻找 paved road、escape hatch、责任分界和反馈机制，而不是只数产品组件。最终用一次故障从 evidence 反查 runtime、control 与 owner，检验分层是否可解释。

学后填写区

我的四层平台图：
六项 catalog 与 owner：
Golden path 和 escape hatch：
平台 / 用例责任边界：
一个仍过于抽象的接口：