边界判断把高复用、高治理、低业务差异且有人长期运营的能力向平台收敛;把高变化、高领域语义和结果责任留给业务。交付形态逐能力决定,不对“整个平台”一刀切。

边界由多变量共同决定

复用度只是起点。能力还要评估安全与合规是否需要一致控制,业务差异是否会迫使抽象频繁变化,远程调用是否引入不可接受的延迟和故障耦合,以及平台团队能否提供文档、支持、升级与值班。没有长期 Owner 的共享组件只是公共遗留代码。

用一张能力卡记录客户、变化来源、调用规模、数据边界、SLO、故障半径、支持成本和退出难度。高复用但变化快的能力先以规范或参考实现验证;低复用但必须中央审计的高风险策略可以做控制面;极低延迟且需要调用方自定义的逻辑更适合 SDK。

平台边界变量与默认倾向
变量向中央收敛留在领域侧
治理强度身份、审计、预算底线需一致仅影响单一低风险任务
变化来源协议稳定、变化可兼容领域政策和用户流程高频变化
运行耦合可承担共享 SLO 与隔离远程依赖会扩大故障域
所有权有产品、工程与运营 Owner只有建设预算,没有持续支持

能力可以以不同形式交付

同一能力可以分层交付。例如 Tool 元数据由 Registry 控制面统一,执行仍在领域数据面;策略基线由中央发布,业务通过受控扩展点补充;尚未稳定的 Agent 骨架以参考项目试点,成熟后再抽出共享服务。形态应匹配责任,不以技术潮流决定。

Library/SDK

SDK 适合低延迟、进程内控制和离线可用,但版本会碎片化,安全修复也无法瞬时覆盖。必须维护兼容矩阵、升级遥测、废弃窗口和最小受支持版本;若关键策略不能容忍旧客户端,不能只靠 SDK 分发。

Shared Service

共享服务适合集中运营、资源池化和强一致治理,但团队必须承担多租户隔离、容量、网络失败、配额和 SLO。把代码部署成服务不等于平台化,调用方仍需要清晰契约、故障降级和支持边界。

Policy/Registry/Config 控制面

控制面适合保存版本化事实、分发策略和审计变更,数据面可就近执行并用已验证快照继续运行。设计重点是配置生效语义、回滚、缓存过期和控制面不可用时的行为,不能让一次后台故障立即中断所有在途 Run。

模板、规范和参考实现

当共性尚未稳定,Golden Path 用可运行范例和默认值降低试错成本,同时保留反馈。它不承诺中央运行 SLO,更不能把复制出来的私叉当成已治理实例;采用与逃逸数据决定下一步是否 SDK 化或服务化。

逐类判断而非整个平台一刀切

模型接入、身份、预算、Trace Schema、评测协议和安全底线通常具有较强跨团队一致性;领域 Prompt、领域 Tool、业务 Gold、用户体验和业务终态仍应由领域团队负责。Run/State、RAG、Memory 是否共享,取决于一致语义是否已经出现,而不是它们听起来像“基础设施”。

一个实用拆法是把控制与执行分开。平台发布允许的模型、Tool 描述、策略和版本,业务数据面保存领域状态并执行动作;Trace 使用统一关联字段但保留领域结果属性。这样中央能治理,领域仍能按自己的变化速度交付。

联邦平台的责任切面
中央控制面身份底线、目录、策略、版本与审计。
共享运行能力仅承接已稳定且有 SLO 的共性。
领域数据面业务 Tool、状态、评测与终态责任。
反馈回路采用、逃逸、事故与支持成本回改边界。

Build、Buy、Open Source 与组合

默认先复用成熟能力,把自研预算留给差异化和不可替代约束。比较项必须覆盖功能、数据地域、身份与审计、扩展、可靠性、三年总拥有成本、人才、升级、供应商停服和迁移资产。许可证费用低并不代表 Open Source 的运营成本低。

PoC 应覆盖最难运营场景,而非最快 Quickstart:租户隔离、峰值容量、策略回滚、数据删除、故障降级和版本迁移。ADR 记录选择与 Why Not,也要写退出资产,例如开放 Trace、领域 Eval、标准 Tool 契约和可导出状态,避免把未来迁移变成从零重建。

平台边界常见失败

“未来所有团队都会用”不能证明共性。万能 Agent DSL、统一 Prompt UI 或领域无关 Memory 往往冻结尚未稳定的假设。另一类失败是平台只交付门户和 SDK,却不承担 SLO、升级、支持与事故;使用者得到新的依赖,却没有更低的认知负担。

强制最低公分母会促使业务绕开,中央收编领域逻辑又会制造排队。修复不是扩大治理,而是区分不可绕过的安全底线和可协商的产品路径,对高频逃逸做根因分类:缺能力、契约不适合、迁移太贵,还是团队只是未理解边界。

规模化后采用联邦治理

中央团队负责协议、身份与安全底线、共享目录、基础 SLO 和 Golden Path;领域团队负责用例正当性、领域 Tool、业务评测、运营和业务结果。安全、数据与 SRE 通过策略即代码、自助检查和例外评审参与,不成为每次变更的人工工单。

RACI 只能辅助澄清,不能替代单点 Accountability。每项能力明确一个对结果负责的 Owner,咨询者限定在真正拥有约束或证据的角色。例外必须记录范围、风险接受者、到期日和退出条件,逾期后重新评审而非自动永久化。

典型联邦责任划分
产物或结果Accountable关键协作
共享模型网关 SLO平台团队SRE、安全、领域调用方
领域 Tool 正确性业务应用团队平台契约、安全、数据 Owner
高风险例外业务风险 Owner安全、合规、架构评审
平台采用与退役平台产品 Owner代表性领域团队、财务

边界会随成熟度变化

边界复审看采用率、留存、逃逸、支持工单、平台变更前置时间、SLO、单位成本和业务交付速度。高采用不一定健康,强制使用也会制造数字;应同时看关键旅程是否更快、故障是否更易恢复、团队是否减少重复建设。

成熟门槛可以是多个团队已验证稳定契约且治理压力显著,此时参考实现升级为服务;反向门槛可以是长期低采用、高耦合或维护成本超过价值,此时下放、替换或退役。迁移提供兼容窗口、自动化工具、数据导出、支持责任和最终关闭日,不能用永久双轨回避决定。

主动提取:跨团队复用率很高,为什么仍不一定适合共享服务?
若能力变化快、极度延迟敏感或远程故障会扩大影响,SDK、控制面加本地执行或 Golden Path 可能更合适。复用度只决定值得治理,不单独决定交付形态。
退出判断:何时应把平台能力下放或退役?
当真实采用和业务加速长期不足,支持与耦合成本持续高于复用收益,或更标准的替代品已成熟,应执行迁移。保留审计与导出能力,明确兼容窗口和最终 Owner。

资料与事实边界

以下以官方文档、标准、论文和原始工程资料为主。厂商 API、价格、限额与模型能力会变化,落地时仍需按目标版本做能力探测和回归。

  1. CNCF TAG App Delivery:Platforms White Paper — 平台面向内部客户策展能力,并通过价值流间接创造价值
  2. DORA:Platform engineering capability — 平台产品思维、最小可行平台、可扩展性与采用度量,页面更新于 2026 年
  3. Google SRE:Service Level Objectives — 从用户行为定义共享服务可靠性目标与责任
  4. FinOps Foundation:Allocation — 共享成本归属、元数据与责任机制