《互联网产品的 AI 架构·多能力编排与任务闭环》13.3 进入卷四：平台化与治理

三条链路跑通之后

回声的三条链路已经有基线：A 内容摘要与审核 96.25% 通过，B 会话回复 239/240，C 检索下单 95.00% 未达 97% 目标。13.2 的评审给 C 开了处方：幂等键加一次补偿重试，预期成功率不低于 97.4%，每次成功交付不超过 2,489 微元。

如果故事停在这里，卷三可以结束了。但真实组织不会只有三条链路、一个团队、一个租户。下个月会有第二个团队把自己的能力接进来，会有大客户要求独立配额，会有合规同学问「这条链路的数据保留多久」，也会有模型退役需要把旧链路迁走。这些问题不是「再写一个编排」能解决的，它们属于平台化与治理。

本节做两件事：把卷三的结论压缩成五条可以交给卷四的输入，并把卷四要回答的四个问题展开。所有数字仍来自前三节的示例样本，不是生产实测。

卷二留下的三个问题，卷三回答了什么

卷二 13.3 留给卷三三个问题：跨能力调用传什么、上下文复用回本线在哪、失败如何传播。卷三用十二章逐条回答，答案可以压缩成三句话。

第一个问题的答案不是「传得越少越好」。传什么由契约决定：下游需要哪些字段、哪些字段可以只传摘要、哪些必须传原文。第二个问题的答案也不是「复用率越高越好」：复用率要跟交接 token 一起看，B 的 60% 复用率已经让每次交接的边际成本低于复制。第三个问题的答案更不是「失败就重试」：模型节点可以重试，动作节点必须有幂等键，人工节点要把拒绝当成一种正常结果。

这三个答案构成了卷三的骨架。但它们是针对「一个团队、三条链路、一个租户」的答案。一旦能力被多个团队共享，骨架还在，边界条件全变了。

五个交接输入

把卷三压缩成五条，交给卷四。每条都带一个可复核的证据，不是一个口号。

这张表不是目录，而是约束。卷四的每一章都可以问：它落到了哪一行？如果一行都落不到，这一章很可能只是功能说明。

输入一：结构先于模型

三条链路的节点数接近，成本与失败结构完全不同。A 的 P95 3,523ms 来自 2,400ms 的人工复核，B 的 1,738ms 来自模型重试的尾部，C 的 793ms 说明它既不慢也不贵，问题只在最后一跳的动作可靠性。同一个「平均成功率」会把三种问题混成一种。

卷四的含义：平台不能只提供「调用一个模型」的接口，必须让团队声明链路结构——哪些节点、什么顺序、哪里并行、哪里转人工。没有结构声明，平台无法做配额、评测与归因。

输入二：交接是显式成本

每次交接 820 token、35ms，共享上下文 3,200 token，缓存折扣 90%，回本线 28.47%。B 的交接成本占比 11.18%，C 是 17.91%，A 是 18.00%。这些数字不是常数，它们随链路结构变化，但「交接必须计量」这条规则不变。

卷四的含义：多团队共享能力时，交接成本会跨团队结算。A 团队调用 B 团队的能力，820 token 记在谁头上、35ms 算谁的延迟、缓存命中算谁的收益，平台必须能回答。没有交接计量，跨团队成本分摊只能拍脑袋。

输入三：失败传播要有预算

单步失败预算 13.02%，三步各一次重试、目标 95% 时成立。C 的下单动作 4% 失败率没有重试，整链掉到 95.00%；补一次重试后理论有效失败率 0.16%。失败不是局部事件，它会沿着链路传播，也会沿着组织边界传播。

卷四的含义：平台要把「失败预算」变成可配置的策略，而不是每个团队各写一套重试。模型失败、动作失败、人工拒绝、超时、越权，五类失败的默认动作应该由平台给出，团队只声明例外。

输入四：质量、成本、安全是同一张表

13.1 的五道门禁是成功率、每次成功交付成本、P95、交接成本占比、复用率。13.2 的评审又加了重复下单数与回滚条件。这些指标必须一起看：C 的成本和延迟都很好，成功率不达标，结论仍是 conditional；R-1 提议三次重试，成本可能更低，但重复下单风险不可接受。

卷四的含义：平台不能只做成本看板或只做安全扫描。一个能力是否允许被共享，要同时看质量、成本、安全与合规四类证据。缺一类，共享就是把风险转嫁给调用方。

输入五：编排必须可评审、可回放

13.2 的记录把方案、基线、改动、预期、条件、负责人、复查日期写死。7.3 的回放包把请求、节点摘要、模型档位、提示版本、采样参数冻结。两者合起来，编排才从「一次上线」变成「一条可以复查的证据链」。

卷四的含义：多团队场景下，评审记录与回放包要成为平台的资产，而不是某个团队的本地文件。平台要能按能力、按租户、按版本检索「当时为什么这么改、改完结果如何」。

卷四要回答的四个问题

卷四讨论平台化与治理。它不是卷三的放大版，而是换了一层问题：卷三问「一条链路怎么协同」，卷四问「很多条链路、很多团队、很多租户怎么共存」。

多团队共享能力

第一个问题是能力的所有权与共享边界。回声内部，chat.reply 可能同时被内容团队、客服团队和交易团队调用；每个团队都希望它按自己的提示、自己的档位、自己的预算运行。平台要回答：能力目录里一条能力归谁维护、版本如何兼容、SLA 由谁承诺、调用方能否覆盖默认参数。

这不是一个技术问题，首先是一个契约问题。卷三的节点契约只约束一条链路内部的上下游；卷四的能力契约要约束「提供方」与「调用方」两个组织。契约里必须写清楚输入输出、失败语义、计费口径、配额单位与退役策略。

举一个具体冲突：内容团队希望 chat.reply 使用 economy 档位，因为摘要场景可以接受稍差的措辞；客服团队希望同一能力使用 standard，因为回复会直接发给用户。如果平台只允许一个全局默认，两个团队必然有一个要妥协；如果允许每个调用方覆盖，提供方的指标就会被拆成很多份，无法判断能力本身是否退化。

合理的做法是把「能力默认值」与「调用方覆盖范围」分开。提供方声明哪些参数可以覆盖、覆盖后谁承担成本与质量责任；调用方在允许范围内覆盖，并在自己的链路基线里记录。平台保留一份「按调用方切分」的能力指标，同时保留一份「按能力默认值」的基准指标。两份都要有，否则无法区分「能力变差」与「调用方用错」。

能力目录因此不能只有名字与负责人。一个可用的条目至少要有：能力标识、提供方、版本、输入输出契约、默认档位、可覆盖参数、失败语义、计费单位、SLA、依赖的下游能力、退役日期。缺一项，调用方就要靠口头约定补。

多租户配额

第二个问题是配额。单租户时，预算是一条链路的成本上限；多租户时，预算变成三层：租户总额、团队份额、单次请求上限。三层之间要有优先级与借用规则，否则一个大客户可以把整个平台打满。

配额还要处理公平性。同样是 1,000 次调用，一个租户用来做低价值摘要，另一个用来做下单前的关键判断，平台是否应该区别对待？卷三的失败预算与成本预算只回答「这条链路能不能跑完」，卷四要回答「资源紧张时先保谁」。

可以用一个三层配额例子说明。某租户月度总额 1 亿微元，内容团队分到 4,000 万，客服团队分到 3,000 万，交易团队分到 3,000 万；每个团队内部再设单次请求上限，例如摘要 6,200 微元、回复 4,200 微元、下单 3,000 微元。三层之外还要有借用规则：低峰期内容团队可以借用交易团队未使用的份额，高峰前必须归还；借用期间的单次上限不变。

这个例子里有三个容易漏掉的点。第一，总额、份额与单次上限的计量单位必须一致，都是微元，不能有的用次数、有的用 token。第二，借用要有上限与归还时间，否则「借用」会变成永久占用。第三，配额耗尽的默认行为要提前定义：是拒绝新请求、降级到经济档，还是排队等下一窗口。三种行为对应三种用户体验，不能由每个团队自己决定。

配额还会影响基线。13.1 的 B 链路每次成功交付 3,804 微元，如果某租户的份额只够每天 1,000 次，那么这条链路对这个租户的真实容量就是 1,000 次/天，而不是「理论上无限」。平台要把配额换算成链路容量，再告诉租户「你的预算能支撑多少条这样的链路」。

评测平台

第三个问题是评测。卷三的评测是单团队的：一套样本、一个门禁、一次发布。多团队共享能力后，提供方改一次提示，所有调用方的链路都可能变；调用方换一个档位，提供方的能力指标也可能变。平台需要一个跨团队的评测平台：共享评测集、回归门禁、按能力与租户切分的报告、以及能把线上失败回灌到评测集的通道。

评测平台最难的不是跑分，而是语料治理。哪些样本可以跨团队共享、哪些含租户隐私、哪些已经过期、哪些是合成数据，必须有目录与保留策略。否则评测集会变成第二个隐私死角。

一个可执行的评测集条目可以包含：样本 id、来源（真实回放 / 合成 / 人工构造）、隐私级别、覆盖的能力与节点、期望结果、有效期、责任人。平台按隐私级别控制可见范围：公开样本所有团队可读，租户样本只在租户与平台之间可见，合成样本可以跨团队共享但必须标记生成方式。

跨团队评测还要解决「谁的基线算数」。提供方改一次提示，调用方的链路指标会变；调用方换一个档位，提供方的能力指标也会变。平台需要两条报告线：一条按能力默认值跑，回答「能力本身有没有退化」；一条按调用方配置跑，回答「这个团队的链路有没有退化」。两条线的样本可以共享，但聚合口径必须分开。

合规与长期运营

第四个问题是合规与长期运营。内容链路的 A 已经有人工复核，但多租户后要回答：复核记录保留多久、谁能查看、跨境调用是否允许、模型退役后旧链路怎么迁移、审计日志与回放包如何区分权限。

长期运营还包括容量与退役。一个能力从上线到退役可能跨越多个模型版本；平台要能标记「这条链路仍在使用旧档位」，要能在模型下线前给出迁移清单，要能回答「如果明天关掉这个能力，哪些租户会受影响」。

保留策略也要分层。以下是示例口径，不是法规结论：

这张表的关键不是具体天数，而是「不同数据不同权限」。如果评审记录、回放包与审计日志共用一套权限，要么审计看不到证据，要么值班能看到不该看的隐私。

退役则要有一条可执行的清单：依赖该能力的链路列表、每条链路的负责人、替代档位或替代能力、迁移截止日期、迁移后的回归结果。模型下线不是一次通知，而是一次跨团队的迁移项目。

一次跨团队场景

把四个问题落到一个具体场景：客服团队想在 B 链路末尾接一个「退款动作」，复用交易团队已经维护的下单能力。

卷三的做法很直接：在 B 的节点序列后加一个动作节点，声明输入输出，给失败策略，重跑基线。但跨团队之后，每个字段都要多问一句。

结构上，退款动作属于交易团队的能力目录，客服团队只能声明「调用哪个版本」，不能自己改节点实现。能力目录要告诉客服：这个动作的输入是什么、失败语义是什么、是否支持幂等、P95 是多少。

交接上，客服链路把 820 token 的会话摘要传给退款动作，交易团队只想要订单号与退款原因。传多了浪费，传少了无法判断。双方要在契约里约定字段，而不是让客服把整段上下文塞过去。

失败上，退款动作不能自动重试。交易团队要求幂等键，客服团队要在自己的链路里生成并透传；如果客服没传，交易团队应该直接拒绝，而不是「帮忙重试一次」。

指标上，退款动作的成功率会进入客服链路的基线，也会进入交易团队的能力指标。同一个失败会被两边各记一次，平台要明确「链路成功率」与「能力成功率」是两个口径，不能互相替代。

评审上，客服团队的方案评审要引用交易团队的能力版本与 SLA，交易团队的变更评审要列出受影响的调用方。两份评审记录通过能力目录关联，而不是靠邮件抄送。

这个场景没有一个是新技术问题。它们全是契约、计量、策略、口径与责任的问题。卷四要做的，就是把这些回答从「每次合作重新谈」变成「平台默认提供」。

四个问题与五条输入的对应

把卷四的四个问题与五条输入放在一张表里，能看出哪些组合已经被卷三回答，哪些是新的。

这张表也解释了为什么卷四不能从「平台功能」讲起。功能是答案，问题是上面四行；没有这四行，功能列表就没有取舍依据。

本卷没有回答的问题

卷三有意留下了一些空白，交给卷四。

第一，跨团队的成本分摊。卷三只算一条链路的总成本，没有算「A 团队调用 B 团队能力」时费用怎么切。交接 token 的归属、缓存收益的归属、失败重试的归属，都需要平台规则。

第二，配额的动态调整。卷三的预算是静态上限，卷四要处理高峰期借用、低峰期归还、租户之间的公平调度。

第三，评测集的跨团队共享。卷三的评测集是单团队资产，卷四要解决语料目录、隐私分级与版本兼容。

第四，模型与能力的退役。卷三假设模型档位稳定，卷四要处理模型下线、提示版本迁移与旧链路的强制升级。

第五，组织责任。卷三的负责人是一个团队，卷四要回答提供方、调用方、平台方在事故中的责任边界。

这些空白不是卷三的缺陷，而是分层的结果。卷三把「一条链路怎么协同」讲透，卷四才有稳定的输入去讨论「很多条链路怎么共存」。

还要注意一点：空白不等于可以跳过。卷四回答这些问题时，仍然要沿用卷三的计量口径——成本用整数微元、延迟用毫秒、成功率写明分母、交接 token 单独计。口径一变，跨卷的数字就无法比较，平台看板也会失去意义。

从卷三到卷四的阅读方式

读卷四时，建议带着卷三的五条输入逐章对照。

看到「能力目录」，问一句：它有没有把结构、交接、失败策略写进契约？看到「配额」，问一句：它有没有区分租户总额、团队份额与单次上限？看到「评测平台」，问一句：它有没有把回放包与评测集接起来？看到「合规」，问一句：它有没有把评审记录、审计日志与回放包的权限分开？

如果卷四的某一章只讲平台功能，没有回答这五个问题，那它只是工具介绍，不是架构。反过来，如果某一章能把五条输入落到具体的目录、配额、评测与审计机制上，它就完成了从「编排」到「治理」的跨越。

卷三的结论不是终点，而是一组约束。卷四可以扩展规模、增加团队、引入租户，但不能绕过这些约束：结构要显式、交接要计量、失败要有预算、指标要一起看、改动要可评审可回放。

一份平台化检查表

在进入卷四之前，可以用下面这份检查表判断一个「平台」是否真的接住了卷三的结论。它不是评分表，而是一组否决项。

能力目录方面：每个条目是否有提供方、版本、输入输出契约、默认档位、可覆盖参数、失败语义、计费单位、SLA 与退役日期？缺三项以上，目录就只是索引。

链路声明方面：每个团队是否声明了节点序列、交接字段、失败策略与预算？如果平台只记录「调用了哪个能力」，它无法做归因、配额与评测。

交接计量方面：820 token 与 35ms 是否有明确归属？跨团队调用时，交接成本记在调用方、提供方还是平台？没有归属，分摊规则一定会在季度结算时吵架。

配额方面：是否有租户总额、团队份额、单次上限三层？借用是否有上限与归还时间？耗尽时是拒绝、降级还是排队？三个问题缺一个，配额就会被绕过。

失败策略方面：模型、动作、人工、超时、越权五类失败是否有平台默认动作？团队能否声明例外，例外是否有人复核？没有默认值，每个团队都会重新发明一套重试。

评测方面：是否有按能力默认值与按调用方配置的两条报告线？语料是否有来源、隐私级别、有效期与责任人？只有一条线，能力退化与调用方用错会混在一起。

证据方面：评审记录、回放包与审计日志是否可检索、权限是否分开、保留期是否明确？三者混在一起，要么查不到，要么看太多。

退役方面：模型下线前是否有依赖清单、替代方案、迁移截止日期与回归结果？没有清单，退役当天会变成事故。

这份检查表不需要平台第一天全部满足，但每一项都要有负责人和日期。平台化不是把功能做全，而是把「谁负责、什么时候完成」写清楚。

小结

卷三回答了卷二留下的三个问题：跨能力传契约字段，交接 820 token、35ms；复用回本线 28.47%；失败按节点类型传播，单步失败预算 13.02%。三条链路的基线是 A 96.25%、B 99.58%、C 95.00%，总判定 conditional；13.2 的评审给 C 开了幂等键加一次补偿重试的处方。

交给卷四的五条输入：结构先于模型、交接是显式成本、失败传播要有预算、质量成本安全是同一张表、编排必须可评审可回放。卷四要在这五条输入之上回答四个问题：多团队共享能力、多租户配额、评测平台、合规与长期运营。

单团队把一条链路跑通，是编排；多团队让很多条链路共存，是治理。卷四从治理开始。

阅读导航：上一节：13.2 一次编排方案评审 · 下一节：目录与学习路径 。

常见错误与边界

• 把卷三的基线当成平台基线。三条链路、一个租户的数字不能直接外推到多团队。
• 认为能力共享只是加一个目录。没有所有权、版本、SLA 与计费口径，目录只是索引。
• 配额只设一个总数。没有租户、团队、单次三层，资源会被单一调用方打满。
• 评测平台只跑分。不治理语料来源、隐私分级与保留期限，评测集会变成隐私死角。
• 合规只在事故后检查。评审记录、审计日志与回放包的权限必须提前分开。
• 模型退役没有迁移清单。旧链路会在模型下线当天集体失效。
• 用「平台会统一处理」回答所有治理问题。平台处理的是机制，责任边界仍要写清楚。
• 把五条输入当成口号。每一条都要能落到目录字段、配额规则、评测门禁或审计记录上。
• 只做能力目录，不做配额与计费归属。目录能查到能力，却算不清谁该付钱。
• 评测集只有一条报告线。能力退化与调用方用错会混在一起，无法定位。
• 配额耗尽没有默认行为。每个团队各写一套拒绝、降级或排队，用户体验会分裂。
• 跳过卷三直接读卷四。没有结构与交接的约束，平台化很容易变成功能堆叠。