AI 底层逻辑 / 经典论文
AI Platform Service Catalog：Golden Paths
AI Platform Service Catalog 是把模型访问、RAG、工具调用、评测、观测、控制、证据和成本能力产品化；Golden Paths 是把这些能力组合成可复用的交付路径，让业务团队在不绕过治理的情况下更快上线。
185 行ai-foundations/papers/86-ai-platform-service-catalog-golden-paths.md
AI Platform Service Catalog / Golden Paths 解读
配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是
docs/AI_PLATFORM_SERVICE_CATALOG_GOLDEN_PATHS_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| CNCF Platform Engineering | https://tag-app-delivery.cncf.io/wgs/platforms/ | 参考平台工程、平台能力和内部平台产品思路（持续更新的工作组文档，访问日期: 2026-07-01） |
| Backstage Docs | https://backstage.io/docs/ | 参考 service catalog、software templates 和开发者门户（持续更新文档，访问日期: 2026-07-01） |
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 将平台 self-service 与风险、评估、治理和监控连接（GenAI Profile NIST AI 600-1 发布 2024-07；框架页访问日期: 2026-07-01） |
| OpenTelemetry | https://opentelemetry.io/docs/ | 参考 trace、metrics、logs 的可观测性基础（持续更新文档，访问日期: 2026-07-01） |
核心导读
AI Platform Service Catalog 是把模型访问、RAG、工具调用、评测、观测、控制、证据和成本能力产品化；Golden Paths 是把这些能力组合成可复用的交付路径，让业务团队在不绕过治理的情况下更快上线。
平台的目标不是集中控制所有 AI 项目，而是把高复杂度和高风险能力做成默认可用的内部产品。好的 AI 平台让团队少做重复工程，同时把安全、合规、可观测和成本控制嵌入默认路径。
系统价值在于把 AI 交付从项目手工拼装变成可发现、可申请、可测试、可审计的能力组合。Service catalog 定义服务契约，golden path 固化推荐架构，control plane 统一权限、评测、日志、成本和证据；评估平台成熟度要看团队是否沿默认路径稳定交付，而不是平台组件数量。
治理边界在于：平台应降低合规摩擦，但不能替业务 owner 承担 use case 目标、客户影响和风险接受责任。低风险场景应自助，高风险场景应自动升级评审；平台必须保留例外机制、pattern lifecycle 和退出路径，避免 golden path 变成僵硬审批或影子 IT 的诱因。
问题定义
如果 AI 平台只提供模型 API，组织会迅速出现能力碎片化：
- 每个团队各自实现 prompt 管理、日志、RAG、评测和权限。
- 风险控制靠项目自觉，证据格式不一致。
- 模型成本、延迟、质量和失败类型无法横向比较。
- 同类场景重复建设，供应商和数据接入方式越来越难治理。
- 业务团队觉得治理慢，于是绕过平台直接采购或调用外部服务。
Service catalog 要解决“平台提供什么、如何申请、如何使用、质量如何、谁负责、证据在哪里”的问题。Golden path 要解决“一个团队如何从 use case 到上线，沿着最少阻力路径完成合规交付”的问题。
核心原理与方法
AI 平台服务目录应覆盖以下能力：
| 服务类别 | 服务示例 |
|---|---|
| Model Access | 模型网关、供应商路由、密钥管理、速率限制、成本预算 |
| Prompt & Policy | prompt registry、policy templates、content rules、版本控制 |
| Knowledge / RAG | corpus onboarding、chunking、embedding、retrieval policy、source freshness |
| Tool Runtime | tool registry、permission scope、idempotency、approval gate |
| Evaluation | eval harness、scenario library、regression test、red team suite |
| Observability | trace、metrics、logs、quality feedback、drift、cost telemetry |
| Governance Evidence | use case inventory、risk tiering、control evidence、approval workflow |
| Operations | incident playbook、kill switch、rollback、support model |
服务目录不是组件列表，而是服务契约：
| 字段 | 说明 |
|---|---|
| Service Name | 能力名称 |
| Use Cases | 推荐使用场景和不适用场景 |
| Interface | API、SDK、portal、template 或 workflow |
| Guardrails | 默认控制、限制、风险等级适配 |
| SLO | availability、latency、support、quality expectation |
| Cost Model | 计费方式、预算阈值、成本可视化 |
| Evidence | 自动生成哪些日志、测试和审批证据 |
| Owner | 服务 owner、支持路径、roadmap |
Golden path 则把多个服务串成标准路径，例如：
AI Use Case Intake
-> Risk Tiering
-> Architecture Pattern Selection
-> Data / Knowledge Onboarding
-> Prompt / Tool Contract
-> Eval Baseline
-> Release Gate
-> Runtime Monitoring
-> Management Review
系统与架构模型
平台架构可以分为门户层、服务层、运行层和治理层：
Developer / Product Portal
-> Service Catalog / Templates / Golden Paths
-> AI Runtime Services
-> Observability & Evidence Platform
-> Governance / Risk / Cost Control Plane
| 层 | 能力 |
|---|---|
| Portal | 服务发现、申请、模板、文档、示例、支持入口 |
| Runtime | 模型网关、RAG runtime、tool execution、policy enforcement |
| Delivery | CI/CD checks、eval pipeline、configuration promotion、release gate |
| Observability | OpenTelemetry-style trace、quality metrics、cost、latency、user feedback |
| Governance | inventory、risk tier、control mapping、evidence graph、exceptions |
Golden path 不应只有文档，应尽可能以模板和自动化实现：
- 新建 use case 时自动创建 inventory record。
- 选择 RAG pattern 时自动生成 corpus policy 和 eval baseline。
- 接入 tool 时自动要求 permission scope、幂等键和 audit log。
- 发布前自动检查 eval threshold、PII masking、risk approval。
- 上线后自动接入 dashboard、alert 和 evidence retention。
关键机制与取舍
| 取舍 | 设计判断 |
|---|---|
| Self-service vs Central Review | 低风险路径自助，高风险 use case 自动升级架构和风险评审 |
| Flexibility vs Standardization | runtime pattern 标准化，业务 workflow 和 eval case 保持可配置 |
| Build vs Buy | 基础控制面和证据层应内部掌控，模型和部分工具可供应商化 |
| One Platform vs Federated Platforms | 核心能力统一，领域知识和业务工具可 federated |
| Developer Experience vs Governance | guardrails 嵌入默认路径，避免额外审批成为主要控制手段 |
服务目录还需要产品化运营：
| 运营机制 | 目的 |
|---|---|
| Adoption funnel | 发现服务、申请服务、成功集成、稳定运行 |
| Service health | SLO、incident、support backlog、文档质量 |
| Cost transparency | 按 use case、模型、团队和渠道看成本 |
| Pattern lifecycle | 推荐、试点、标准、废弃的模式管理 |
| Feedback loop | 从团队摩擦、失败案例和审计发现更新 golden path |
证据与控制
平台应自动产生治理证据，减少项目手工补材料。
| 平台能力 | 自动证据 |
|---|---|
| 模型网关 | model version、routing decision、latency、token cost、policy decision |
| RAG 服务 | source id、retrieval set、freshness、access filter、chunk version |
| Tool runtime | caller、permission、parameters、idempotency key、result、rollback |
| Eval pipeline | test suite、threshold、result、failure class、approval |
| Release gate | risk tier、control checklist、exception、approver、conditions |
| Observability | trace id、quality feedback、override reason、alert、incident |
控制应该按 golden path 自动嵌入：
| Gate | 检查 |
|---|---|
| Intake | 是否有 owner、业务目标、风险等级、客户影响 |
| Knowledge Onboarding | 数据来源、权限、PII、retention、freshness |
| Tool Registration | 最小权限、幂等、补偿、审计字段 |
| Pre-release | eval baseline、red team、cost estimate、support readiness |
| Runtime | SLO、quality drift、cost anomaly、incident trigger |
金融零售场景映射
银行 AI 平台可提供几条标准 golden path：
| Golden Path | 适用场景 | 默认控制 |
|---|---|---|
| Internal Knowledge Assistant | 员工政策问答、运营指南 | 权限过滤、来源引用、反馈收集 |
| Customer Service Copilot | 坐席辅助、回复草稿、摘要 | 禁止自动承诺、人工确认、QA 抽样 |
| Regulated Decision Explanation | 信贷/费用/投诉解释 | 高风险评审、固定模板、审计 trace |
| Document Intelligence | KYC、合同、申请材料抽取 | schema validation、human review、confidence threshold |
| Tool-Calling Agent | 创建 case、更新状态、查询系统 | tool registry、最小权限、幂等和补偿 |
真实取舍：业务团队希望快速接入任意模型和知识源；企业需要可控、可审计、可退出。平台设计应允许模型供应商灵活替换，但把日志、证据、权限、评测和成本控制留在内部控制面。
反模式
- 平台只提供 API key 管理，没有服务目录、SLO、支持和证据。
- Golden path 是文档，不是模板、自动检查和可运行 reference implementation。
- 所有 AI use case 走同一审批路径，低风险太慢，高风险不够严。
- 观测只看 token 和延迟，不看质量、失败类型、人工接管和业务结果。
- 平台团队只优化技术指标，不管理 adoption、cost 和服务体验。
- 业务团队绕过平台采购工具，导致数据、合同、退出和监管风险外溢。
最终心智模型
AI 平台的本质是把复杂能力和治理要求封装成内部产品。Service catalog 定义可复用能力，golden paths 定义推荐交付路径，control plane 定义风险和证据。平台成熟度不看组件数量，而看业务团队能否更快、更安全、更可审计地把 AI 能力转化为业务结果。
SOTA 检查 (2026-07-01)
- 本篇核心论点被 DORA 2025 报告（2025-09）实证支持：高质量内部平台是「AI 投入能否转化为组织绩效」的最强预测因子——平台质量高时 AI adoption 对绩效的正向效应显著，平台质量低时效应接近于零。这直接印证本篇「平台成熟度看业务团队能否沿默认路径稳定交付，而非组件数量」的判断，该框架性结论不随工具版本过时。
- Model Access 层已高度商品化，选型格局明朗（2026 上半年）：自托管路由首选 LiteLLM（MIT，100+ providers，单实例 >500 RPS 时 Python 开销成瓶颈）；Portkey 于 2026-03 将其 gateway 全量开源（Apache 2.0，1,600+ 模型 / 40+ providers），定位从「网关」升级为含 guardrails、PII redaction、审计轨迹的 AI control plane——与本篇「日志/证据/权限/评测/成本留在内部控制面」的 build-vs-buy 判断一致。库内实操对照见
docs/aipa/day43-litellm-gateway.md与docs/aipa/day110-platform-v1-tco.md。 - Tool Runtime 一栏出现新增标准件：MCP gateway。2026 年企业平台开始在模型流量网关之外，为 agent 工具流量（Model Context Protocol）单独建治理注册表/网关（如 TrueFoundry MCP Gateway），即「模型流量 + 工具流量」双控制面——本篇 tool registry / permission scope / approval gate 契约模型仍然成立，但落地载体正在从自建 registry 演进为 MCP 化网关。库内自建对照见
docs/aipa/day50-mcp-server-build.md、docs/aipa/day53-risk-gateway.md。 - 治理证据层的锚点在更新：NIST AI 600-1 GenAI Profile（2024-07）仍是本篇 Governance Evidence 映射的现役基线；2025-12 NIST 发布 Cyber AI Profile 初稿（NIST IR 8596），SP 800-53 AI control overlays 与 RMF 1.1 增补预计 2026 年内推进——本篇「平台自动生成证据」的表格无需改，但证据字段对标清单应跟踪这些新 profile。
- Golden path 概念本身在向「agent golden paths」外延（2026 平台工程社区预测方向）：AI 编码/运维 agent 成为平台新用户类别，平台团队开始为 agent 定义与人类开发者同构的默认路径（模板+自动 guardrail），且 2025 State of Internal Developer Portals 显示 Backstage 类门户满意度低（仅 ~6% very satisfied）、商业门户（Port/OpsLevel）分流明显——本篇「golden path 必须是模板+自动化而非文档」的反模式论述反而更重要，不过时。