内部 AI 平台怎么保住灵活性：统一契约可以，但别把业务变化一起平台化
内部 AI 平台一旦开始做大，最容易发生的一件事不是能力不够，而是“什么都想统一”。最开始大家统一的是鉴权、日志、模型路由，听起来都没问题；再往后，连业务模板、流程步骤、审批习惯和租户差异也一起往平台里收，灵活性就会开始明显下降。
我对这件事最具体的印象，不是在某次架构评审里，而是在几次业务方开口提需求的时候。
最开始大家都很欢迎平台。因为它确实解决了一批痛点：鉴权终于统一了，日志终于能对起来了，供应商切换也不再每个项目自己写一套。可一段时间以后，业务方提需求的语气开始变了：
- 这个租户的模板能不能单独放一个版本
- 这个审核流能不能不要走平台默认步骤
- 这个场景其实只想覆写一个局部参数
平台团队最开始的本能反应，通常是“也能支持，我们加进配置里就行”。问题就从这里开始。
真正危险的不是抽象，而是把变化最快的东西也一起收进去
平台化一开始当然要抽象，不抽象就没有平台。可我后来越来越觉得，平台真正危险的时刻，不是它开始抽象，而是它开始把变化最快的那部分也抽象进去。
如果今天让我只选几样必须平台化的东西，我还是会先选这些：
- 身份和鉴权
- 审计日志
- 模型路由接口
- 版本和回放能力
- 限流、超时、成本配额
这些东西有个共同点：几乎所有业务都会用，而且不统一的成本只会越来越高。
相反，我现在特别谨慎去平台化这些东西：
- 每个业务线自己的 Prompt 策略
- 审核流或任务流的步骤编排
- 业务特有的字段解释
- 各租户自己的内容规则
原因也很简单，这些部分变化太快。一旦被平台提前收死，业务线后面就一定会开始绕平台。
我见过最典型的“平台收太多”长什么样
很多平台早期会把能力模板做成一个很大的配置对象，看起来很统一：
type PlatformTaskConfig = {
promptTemplate: string;
modelProvider: string;
workflowSteps: string[];
tenantOverrides: Record<string, unknown>;
approvalPolicy: string;
outputSchema: unknown;
};
这种配置第一次看上去总会让人很有安全感，因为所有东西都在一个地方。但问题不是它不能工作，而是这里面混进了太多层次不同的东西：
- 有的是平台公共能力
- 有的是业务编排
- 有的是租户定制
一旦这些东西被放在同一层管理，平台就会越来越像一个什么都想知道、什么都想控制的总控中心。短期看很完整，长期看每加一次能力都更笨重。
我现在更喜欢的平台边界，反而没有那么“全能”
我会更愿意把边界切成三层：
-
平台公共层
负责统一鉴权、审计、模型路由、配额和回放。 -
业务编排层
负责流程步骤、字段契约和降级策略。 -
租户扩展层
负责在受控范围里覆写模板、规则或局部参数。
这样做以后，平台终于不需要对每个业务细节都了如指掌。真正稳定的部分由平台托住，变化快的部分仍然留在更接近业务的一层。
不留扩展点，最后一定会长出旁路
我现在很相信一件事：如果平台不留扩展点，业务线一定会自己长逃生口。平台团队有时会把这种行为理解成“不守规矩”，但很多时候，它只是说明平台没给变化留下合法出口。
最常见的旁路包括：
- 在业务服务里偷偷写一套模型调用
- 自己维护一份 Prompt 模板版本
- 在平台输出之后再做一层私有裁剪
- 用平台不认识的字段塞临时逻辑
所以我现在反而宁愿一开始就承认：平台不可能覆盖所有变化。与其假装自己能兜住一切，不如明确告诉业务：
- 哪些参数允许租户覆写
- 哪些步骤允许业务插拔
- 哪些特殊场景必须走审批的 escape hatch
这样看上去没有“一套平台包打天下”那么漂亮，但现实里会更稳。
多租户不只是隔离问题，也是节奏问题
很多人谈多租户只谈数据隔离，但我觉得还有另一层：租户之间的变化速度不一样。
有的租户只需要稳定默认配置，有的租户会不断试新策略。如果平台没有把“可配置范围”和“共享基础能力”分开，最后要么大家都被最保守的策略绑住，要么平台被各种定制搞乱。
所以我现在会更愿意把租户能力分成：
- 不可改的公共基线
- 可参数化的受控差异
- 必须审批的非常规扩展
这套分层虽然没有“一套配置走天下”听起来简单，但它至少承认了一个事实：不同租户不是同一种节奏。
所以我现在对平台灵活性的判断也更具体了：好的平台不是消灭灵活性，而是把灵活性放进可治理的范围里。真正值得统一的，是契约、审计、版本、配额这些公共基础设施；真正不该过早统一的，是变化最快的业务策略和租户差异。
平台只要把“该稳的地方稳住，该变的地方留口子”，灵活性就不会天然和平台化对立。怕就怕平台一边想成为所有能力的入口，一边又想成为所有变化的终点，那最后它多半会先变成大家最想绕开的那一层。