《互联网产品的 AI 架构·平台化与治理》13.3 全书回顾与继续阅读

四卷写完，回到最初的问题

四卷从一个问题开始：一个产品要接入模型能力，边界应该画在哪里。写到卷四结尾，这个问题变成了另一组问题：能力归谁、链路怎么计量、多团队怎么共享、多租户怎么共存。

四卷不是四个并列的专题，而是一条逐层放大的路径。卷一处理一个能力，卷二处理一条链路，卷三处理一条多能力链路，卷四处理很多条链路、很多团队与很多租户。每一层都建立在前一层的计量口径上，跳过任何一层，后面的结论都会失去分母。

本节做三件事：回顾四卷各自回答什么、不回答什么；说明这套架构在哪些条件下不适用；给出继续阅读的方向。它不预告新章节，也不把四卷包装成万能框架。

四卷各回答一个问题

这张表也可以反过来读：如果你只有一个能力，卷二的调度与卷三的编排大部分用不上；如果你只有一个团队、一个租户，卷四的配额与评审委员会可能过度设计。架构的价值不在于覆盖所有层，而在于知道当前问题在哪一层。

卷一：一个能力的边界

卷一的核心不是「怎么调模型」，而是「调用方应该看到什么」。一个能力对外只暴露契约：输入字段、输出字段、失败语义、预算单位与可覆盖参数。模型、供应商、区域、档位都藏在网关后面，调用方不需要知道，也不应该依赖。

卷一给出的关键约束有三条。第一，预算是请求的一部分，不是事后账单；调用方必须说明这次请求最多能花多少、最多能等多久。第二，降级是契约的一部分，模型不可用、预算耗尽、内容被拦截时，调用方会收到什么必须提前定义。第三，观测字段从第一天就要固定，请求 id、能力 id、版本、档位、token、成本、延迟缺一项，后面的归因都做不了。

卷一的边界也很清楚：它假设只有一条调用路径、一个调用方、一个租户。跨能力的交接、跨链路的容量、跨团队的所有权，都不在卷一的范围内。把这些问题的答案塞进网关，网关会变成一个无法评审的巨型配置。

卷二：一条链路的性能与成本

卷二把一条链路当成一个系统来看。它关心的不是单次调用快不快，而是整条链路的成功率、每次成功交付成本、P95 延迟与容量。三个指标必须一起看：只优化成本会把延迟推高，只优化延迟会让成本失控，只看平均值会掩盖尾部。

卷二留下的可复用方法有四个。第一，成本用整数微元计量，延迟用毫秒，成功率写明分母，避免跨表比较时单位漂移。第二，缓存、压缩、批处理与蒸馏都有回本线，不能因为「看起来更省」就上线。第三，容量要按峰值与排队模型估算，不能把平均 QPS 当容量。第四，实验要预先写假设、样本量与停止条件，避免看到显著就宣布成功。

卷二回答的是「一条链路内部怎么权衡」。它不回答「两条链路争一个能力时先保谁」，也不回答「A 团队调用 B 团队能力时成本记在谁头上」。这些问题的分母超出了单条链路，需要卷三与卷四。

卷三：一条多能力链路的协同

卷三把多个能力串成一条任务闭环。它给出的核心结论是：结构先于模型。同样三个能力，串行、并行、带人工复核的失败结构完全不同，成本和延迟也不同。三能力编排的示例结果是每次成功交付从 4,240 微元降到 3,786 微元，下降 10.71%；延迟从 1,200ms 升到 1,269ms，上升 5.79%。

卷三还给出了三个可复用的计量。每次交接 820 token、35ms；共享上下文 3,200 token、缓存折扣 90%、复用回本线 28.47%；单步失败预算 13.02%。这些数字来自示例样本上的运行结果，不是生产实测，但它们定义了「交接要计量、复用要看回本线、失败要有预算」这三条规则。

卷三的边界是单团队、单租户、三条链路。它假设能力目录只有一个维护者、版本只有一个在役主版本、配额只有一条链路的预算。一旦能力被多个团队共享，卷三的契约就要扩展成提供方与调用方之间的契约，卷三的评测也要扩展成跨团队的双报告线。

卷四：很多条链路如何共存

卷四处理的是规模化之后才出现的问题：能力重复、版本漂移、配额争抢、责任不清。它用十二章分别给出目录字段、版本矩阵、三层配额、评测平台、质量运营、成本分摊、合规、安全、平台工程、组织责任与演进治理。

卷四最后落在两张可执行的表上。一张是 13.1 的治理基线：12 条判据，每条有责任人、证据与 blocking 标记，总体结论分 pass、conditional、blocked。另一张是 13.2 的评审记录：参会方、争议、决议、待办与放量级别。两张表合起来，把「治理」从制度文件变成可复核的决定。

卷四的边界同样明确：它不教你选哪个模型，也不替代供应商的运维手册；它假设组织愿意为治理投入人力，并且有人能对跨团队争议做最终裁决。没有这两个前提，再完整的基线也会变成空转。

四卷的数字怎么对齐

跨卷阅读最容易犯的错误，是把不同分母的数字放在一起比较。下面四组口径必须成对出现。

同样是「成功率 96%」，能力成功率的分母是调用，链路成功率的分母是任务。能力成功但下游动作失败时，链路成功率会低于任何一个能力的成功率。把两者混在一张看板上，团队会误以为能力退化，实际是链路结构问题。

成本也一样。每次成功交付成本的分母只算成功请求，失败请求的成本被摊进成功请求里；如果只看总成本除以总请求，会低估失败重试的代价。四卷一直坚持「整数微元、写明分母」，原因就在这里。

这套架构在什么条件下不适用

前面四卷给了很多机制。但机制有成本：目录要维护、基线要评审、配额要对账、评测要跑回归。下面六种条件下，完整架构的收益可能低于维护成本。

只有一个团队、一条链路

如果调用方、提供方、平台方是同一批人，能力目录、评审委员会与跨团队配额都没有意义。团队只需要卷一的契约与卷二的链路预算，再加一份简单的版本记录。把卷四的十二张表搬进来，只会让三个人维护一套给自己看的流程。

判断标准不是团队人数，而是「是否真的存在两个以上能独立做决定的组织」。如果所有决定都可以在一个站会里完成，治理机制就是多余的。

调用量与成本低于阈值

治理机制需要固定投入：每月对账、每季度基线、每次评审的会议与记录。如果月度 AI 成本只有几百元，或者月调用量低于一万次，人工抽查与简单预算就足够。

可以用一个粗略的示例阈值判断：月度总成本低于一名工程师一天的人力成本时，自动化治理的投入很难回本。这个阈值不是行业标准，只是提醒团队先算治理本身的成本，再决定上多少机制。

单租户且没有合规约束

多租户配额、跨租户评测、租户级联删除，都是为了处理「不同客户的数据与额度必须隔离」。如果产品只有一个内部租户，数据不出组织边界，也没有外部合规审计，卷四的配额三层与合规分级可以大幅简化。

简化不等于删除。即使单租户，也要保留成本归属与数据保留期限；只是不需要把每个团队切成独立份额，也不需要为跨租户共享设计隐私级别。

模型与供应商单一且稳定

版本矩阵、双跑、弃用窗口与退役清单，解决的是「模型会变、供应商会换」。如果业务锁定一个模型、一个区域，且供应商承诺的退役周期长于产品生命周期，完整的版本矩阵可以退化成一张版本记录表。

但要注意，「现在单一」不等于「永远单一」。一旦出现第二个模型或第二个区域，版本矩阵就要补起来。可以晚建，但不能假设永远不需要。

业务生命周期短于治理建设周期

治理机制从设计到稳定运行，通常需要一到两个季度。如果业务本身只打算跑三个月，建目录、跑基线、开评审的时间可能超过业务寿命。这时更合理的做法是借用平台已有的治理能力，而不是自建一套。

短期业务也不是完全裸奔。至少要保留请求预算、失败降级与成本记录，否则业务结束后连账都算不清。

组织没有裁决权

治理的核心是「有争议时谁能做最终决定」。如果平台团队只有建议权，业务团队可以绕过配额、跳过评审、拒绝迁移，那么基线、评审与待办都会变成建议。与其建一套无人执行的流程，不如先把裁决权与升级通道定清楚。

裁决权不一定是某个委员会。它可以是一个明确的角色，例如平台负责人对跨团队配额有一票决定权。关键不是形式，而是争议发生时有人能拍板，并且拍板结果能被记录与复查。

不适用不等于否定

上面六种条件否定的是「完整架构的投入」，不是「架构里的所有原则」。即使不建目录、不开评审，下面四条仍然值得保留。

第一，计量口径要统一。成本用整数微元、延迟用毫秒、成功率写明分母，这些不是平台专属，任何一条链路都用得上。

第二，契约要显式。调用方需要哪些字段、失败时看到什么、预算上限是多少，写清楚比口头约定便宜。

第三，失败要有预算。重试不是免费的，动作节点要有幂等键，人工节点要把拒绝当成正常结果。

第四，改动要可回放。至少保留请求 id、版本、档位与关键参数，事故复盘时才有证据。

这四条是四卷的最小内核。平台化与治理是它们的放大版，不是替代品。

四条继续阅读路线

四卷覆盖的是 AI 架构这一层。往外走，有四条路线值得继续读。

这四条路线不是必读清单，而是问题地图。遇到配额争抢，去读排队论与公平调度；遇到评测争议，去读实验设计与统计推断；遇到合规问题，去读隐私工程与数据保留；遇到组织扯皮，去读组织设计与责任分配。

继续阅读的具体方向

如果只想选三个方向深入，建议从下面三个开始。

第一，分布式系统与排队论。多租户配额、平台 SLO、峰值容量、借用与回收，本质上都是共享资源调度。理解排队延迟、利用率与尾延迟的关系，比再学一个模型 API 更有用。

第二，SRE 与可观测性。平台化之后，故障不再只属于一个团队。错误预算、事故分级、复盘文化、发布工程，这些能力决定了平台能否在压力下保持可信。

第三，隐私工程与数据治理。评测集、回放包、审计日志、租户级联删除，都会碰到数据边界。理解数据分级、最小化、保留期限与跨境传输，才能把合规从「事后检查」变成「设计约束」。

如果还有余力，可以补 FinOps 与组织设计。前者帮你算清单位经济模型，后者帮你把评审、所有权与升级通道落到人身上。两者都不是技术书，但它们决定了治理机制能否长期运行。

阅读时建议带一个具体问题，而不是从第一页读到最后一页。例如你正在处理配额争抢，就先读排队论与公平调度；正在写事故复盘，就先读 SRE 的错误预算与事后分析；正在被合规追问数据保留，就先读隐私工程的数据最小化与保留期限。问题驱动阅读比书单驱动阅读更容易留下结构。

四卷之间的依赖关系

四卷不是四个孤岛。后一卷的每个机制，都依赖前一卷的某个口径。把依赖关系画出来，能看出跳过某一卷会缺什么。

这张表还有一个用途：排查线上问题时，可以按依赖反推是哪一层口径先坏了。配额对不上，先查成本归因；成本归因对不上，先查请求预算与用量字段；用量字段缺失，问题其实在卷一。

依赖关系也解释了为什么四卷的阅读顺序不能完全打乱。可以先读卷四了解治理全貌，但真正动手时仍要回到卷一补契约与字段。只看卷四的目录模板，做出来的往往是一张没有分母的表。

一个反例：把治理当装饰

某团队照着卷四建了能力目录、评审委员会与季度基线，运行两个季度后，团队发现事故没有减少、成本没有下降、决策也没有变快。复盘时找到三个原因。

第一，目录字段不全。条目只有名字与 owner，没有契约、SLA、计费单位与退役日期。目录能查到能力，却回答不了调用方最关心的问题。

第二，评审没有否决权。委员会可以提建议，但业务团队可以绕过配额直接调用模型。评审记录写得很完整，执行时没人看。

第三，基线只统计文档。十二条全部是「有没有制度」，没有一条检查最近一次执行记录。两个季度过去，基线全是绿色，事故照常发生。

这个反例说明，治理的每个部件都必须接到一个真实决定上：目录接到调用方选型，评审接到配额与放量，基线接到证据与待办。接不上的部件，越完整越像装饰。

适用性判断的四个问题

在决定是否引入完整架构之前，可以先回答四个问题。它们不能替代详细评估，但能快速排除明显过度设计的场景。

第一，是否存在两个以上能独立做决定的组织？如果所有决定都能在一个站会里完成，跨团队治理没有对象。

第二，月度 AI 成本是否足以养活一套治理流程？把对账、评审、基线维护的人力折算成成本，再与节省的浪费比较。

第三，数据是否跨租户、跨区域或受外部合规约束？如果数据始终在一个内部租户内，配额与合规分级可以简化。

第四，争议发生时谁拍板？如果没有人能对跨团队配额、版本升级与退役做最终决定，先解决裁决权，再谈流程。

四个问题里有两个以上回答「否」，建议从最小内核开始：统一计量、显式契约、失败预算、可回放记录。等规模与争议真正出现，再逐层加机制。

一份结课自检

合上书之前，可以用下面十个问题检查自己是否真的理解了四卷的分工。

1. 你能说清一个能力的契约里必须有哪些字段，以及哪些参数允许调用方覆盖吗？
2. 你能为一条链路写出成功率、每次成功交付成本与 P95 的分母吗？
3. 你知道缓存、压缩与批处理的回本线怎么算吗？
4. 你能画出三个能力的执行图，并标出哪些节点可以重试、哪些必须幂等吗？
5. 你能解释交接 token 为什么要单独计量，而不是摊进总 token 吗？
6. 你能为一个能力设计三层配额，并说明借用与归还规则吗？
7. 你能写出跨团队评测集的一条目录字段，并说明隐私级别怎么控制可见范围吗？
8. 你能用一页纸说清一次治理评审的参会方、争议、决议与待办吗？
9. 你知道基线什么时候该判 conditional、什么时候该判 blocked 吗？
10. 你能说出这套架构在什么条件下不适用，以及不适用时该保留哪四条原则吗？

如果前九题能答，第十题答不出来，说明你学到的是机制，还没有形成边界感。边界感比机制更重要：机制可以照抄，边界必须自己判断。

写在最后

四卷的案例是「回声」，一个内容社区加 IM 加轻交易的产品。它的数字是示例样本上的运行结果，不是生产实测；它的组织是简化过的，真实公司会有更多历史包袱与例外。但四卷的方法不依赖这些具体数字：先把对象建模，再把计量口径统一，再把失败与成本写成预算，最后把跨团队的决定写成可评审的记录。

这套方法不会让 AI 产品自动成功。它只能让团队在规模变大时，仍然回答得出三个问题：这次调用花了多少、失败了谁负责、下次改动怎么证明更好。能持续回答这三个问题，架构就算站住了。

小结

四卷分别回答能力边界、链路性能、多能力协同与多团队治理。它们共享同一套计量口径：整数微元、毫秒、写明分母。卷四的基线把前十二章压成 12 条判据，评审把判据变成决议与待办。

这套架构在单团队单链路、低调用量、单租户无合规、单一稳定供应商、短周期业务与无裁决权组织里可能不适用。不适用时，仍应保留统一计量、显式契约、失败预算与可回放记录四条原则。

继续阅读可以从分布式系统与排队论、SRE 与可观测性、隐私工程与数据治理三个方向开始，再按角色补 FinOps 与组织设计。

阅读导航：上一节：13.2 一次跨团队治理评审 · 下一节：目录与学习路径 。

常见错误与边界

• 把四卷当成四个可以独立套用的模板。跳过卷一直接读卷四，会得到一堆没有分母的指标。
• 认为平台化越完整越好。治理机制有维护成本，规模不到时是负收益。
• 把能力成功率与链路成功率混用。分母不同，结论可能完全相反。
• 用总成本除以总请求代替每次成功交付成本。失败重试的代价会被低估。
• 只建目录不建裁决权。没有最终决定人，争议会回到邮件与会议。
• 认为单一供应商不需要版本治理。供应商退役与模型升级仍会发生。
• 短期业务完全不做计量。业务结束后连成本与失败原因都查不清。
• 把继续阅读当成书单。应该带着具体问题去读，而不是按顺序刷完。
• 把示例数字当生产基线。四卷的数字用于说明方法，不是行业基准。
• 结课后不再回看边界。组织、模型与租户都会变，适用条件要定期重判。