S31：从 Registry、Policy 与 TCO 看 AI 平台组件关系

内容类型：预习教材（不代表已完成）
日期：2026-12-23
阶段：P2 · AI Systems Engineering 90
总路线：Day 121 / 360
周次：W5 · AI Platform Engineering & Golden Path
节奏：周三引导练习
状态：教材已备；学习未完成
标签：registry、policy-engine、tco、control-plane、platform

一句话定义

AI 平台不是一组彼此孤立的工具，而是用 registry 描述“有什么”、用 policy 决定“允许怎样使用”、再用成本模型解释“使用代价”的控制关系网络。

学习目标

1. 区分 registry、policy engine、runtime 与成本计算器各自拥有的状态和决策权。
2. 能沿一次 AI 用例调用说明版本解析、策略判定、配额检查和成本归集的先后关系。
3. 理解控制平面只发布期望状态，数据平面和运行平面才实际处理内容与副作用。
4. 能发现“注册成功”“策略允许”“预算充足”三种判断不能互相替代。

核心知识

• Registry 保存可发现的元数据，例如用例、模型、提示词、工具、owner、版本、生命周期状态与依赖关系。它回答“当前可选对象是什么”，不应直接执行模型调用。
• Policy engine 接收主体、资源、动作、上下文和目的，输出 allow / deny / escalate 及理由。策略是决策逻辑，registry 是事实目录；两者混在一起会使版本与审计难以追踪。
• Runtime 根据已经解析的版本和策略结果执行请求，管理超时、重试、会话与工具调用。运行时不能把“调用成功”反推成“调用合规”。
• TCO / unit cost 将 token、模型调用、检索、工具、基础设施和人工复核成本归集到一次成功任务或一个租户。价格表只是输入，归集边界才决定指标是否可解释。
• Control plane 管理配置、版本、策略和配额；data plane 承载业务数据；runtime plane 执行推理与工作流；evidence plane 保存 trace、评测、审计与成本证据。分层的目的不是多画几层，而是让写权限与故障传播更清楚。

机制与推导

把一次请求抽象为：

request(useCaseId, actor, purpose)
  -> registry.resolve(useCaseId, requestedVersion)
  -> policy.evaluate(actor, action, resource, purpose, context)
  -> quota.reserve(tenant, estimatedUnits)
  -> runtime.execute(resolvedBundle)
  -> evidence.record(version, decision, usage, outcome)
  -> cost.allocate(usage, tenant, successfulTask?)

这里至少有四个不同状态：目录中的 draft/active/deprecated、策略的 allow/deny/escalate、配额的 available/reserved/consumed/released、运行时的 queued/running/succeeded/failed。若只用一个 status 字段，它会同时承载四种语义，出现“active 但被策略拒绝”“执行失败但配额未释放”等无法表达的问题。

成本也要说明分母。设一次任务模型成本为 (C_m)，工具为 (C_t)，平台分摊为 (C_p)，人工复核为 (C_h)，成功任务数为 (N_s)，则：

[ C_{success}=\frac{C_m+C_t+C_p+C_h}{N_s} ]

若只报告 cost/request，失败重试和人工返工会被平均隐藏。反过来，成本模型也不能替代价值判断：便宜的错误答案仍然是失败。

最小练习或观察步骤

1. 只读查看 agentRegistry.ts、policyEngine.ts 与 tco.ts 的输入、输出和保存状态，不假设代码已经运行。
2. 选择一个合成的 AML 调查助手用例，写出 registry 记录：owner、bundle version、模型、工具、风险等级和生命周期。
3. 为“读取案件摘要”和“提交冻结建议”各写一个策略输入，比较为什么后者可能返回 escalate。
4. 画出 registry→policy→runtime→evidence→cost 的组件图，在箭头上标数据，不只写“调用”。
5. 构造一次运行失败后的配额释放场景，记录哪个组件应负责，哪个组件只接收证据。
6. 写下观察事实和待确认问题；没有实际运行就不要填写延迟、成本或成功结果。

常见误区与边界

• 把 service catalog 当成静态 Wiki；若无法解析 owner、版本和依赖，它不能支持自动化控制。
• 让 policy engine 直接读取任意业务数据库，导致判定不可复现、延迟不可控且权限面扩大。
• 将模型名称等同于用例版本，忽略 prompt、tool、index 与 policy 同样改变系统行为。
• 预算不足就静默降级到另一个模型，却不记录实际版本与行为差异。
• 把估算的 token 费用说成完整 TCO，漏掉失败、复核、存储、观测与共享平台成本。
• 本日只学习组件关系，不要求部署真实平台，也不把内存实现描述成生产 control plane。

系统 / 金融 / Web3 场景连接

在金融调查中，同一个“案件摘要”用例可能允许分析师读取，却要求主管才能触发外部案件状态变更。registry 指向已批准的模型与工具 bundle；policy 根据角色、目的和案件敏感度决定允许或升级；runtime 执行只读分析；evidence plane 关联最终人工决定。Web3 钱包助手也类似：查询余额与构造待签名交易属于不同风险层，后者不能因模型成本较低就跳过授权和人工确认。

自检问题

1. registry 的 active 为什么不等于本次请求一定可以执行？
2. policy、quota 与 runtime 各自需要哪些独立状态？
3. cost/request 与 cost/successful task 在失败率上升时会怎样分化？
4. 哪些字段应该进入 evidence plane，才能解释一次版本解析和策略判定？

专业课程对齐

• 阅读 Stanford CS329S 中 ML system design、deployment 与 monitoring 的课程结构，重点映射“模型只是系统中的一个组件”，用它检查本日组件图是否遗漏数据、反馈与维护责任。
• 阅读 Full Stack Deep Learning 2022 的 infrastructure、deployment 与 monitoring 相关讲次，关注开发期 artifact 怎样过渡到可运行服务，而不是照搬其完整技术栈。
• 阅读 Backstage 官方文档 的 Software Catalog 与 Software Templates 概览，具体观察 catalog entity、owner、lifecycle 和模板化入口怎样支撑发现与 golden path。

深入学习提示

按 CS329S 系统边界→FSDL 生命周期→Backstage 目录实体的顺序阅读。每看到一个平台名词，都问四件事：它拥有哪类状态、接受什么命令、发出什么证据、失败由谁恢复。深入时可为组件图增加读写方向与一致性要求；不要把“有 API”误认为边界已经清楚，也不要为了完整而增加部署作业。

学后填写区

• 实际阅读或查看的范围：
• 我画出的组件与数据关系：
• 一个状态所有权冲突：
• 成本分母的选择及理由：
• 尚未理解的问题：