Agent 平台架构

平台解决重复工程与组织治理问题

当每个团队都自行接模型、保存 Run、执行 Tool、处理身份、埋 Trace 和建设评测时，重复的不只是代码。Provider 升级、安全政策、审计字段和事故修复会在多套实现中漂移，组织无法知道哪条调用链符合生产底线。平台应把这些跨业务稳定、规模收益明确、需要一致治理的责任收敛，而不是接管每个业务 Agent。

CNCF Platforms White Paper把平台描述为面向内部客户、经过策展的能力与体验。这个定义带来一个重要约束：平台是产品，不是共享组件仓库。它需要清晰用户、服务契约、支持模式和反馈闭环；如果使用者只能提交工单，或者必须理解平台全部内部拓扑，平台尚未提供真正的自助服务。

工程建议：用“重复痛点 × 风险集中度 × 接口稳定度”排序平台候选能力。暂时只有一个团队需要、接口仍快速变化的能力，先以参考实现或共享库验证，不要为了组织图完整而提前建设服务。

四个平面承担不同责任

四个平面不是四套必须独立部署的系统，而是四类不同变化速度和故障语义。划分的目的，是避免一次控制台故障拖垮在途 Run，也避免运行热路径被报表查询和策略发布争抢资源。

控制面

控制面保存期望状态：Registry 元数据、策略、租户配额、评测门禁、路由规则和发布版本。它负责校验、审批和分发配置，但不应成为每个 Token 或 Tool 调用的同步依赖。数据面消费已签名、可回滚的配置快照，并报告当前应用版本。

数据面

数据面承担热路径：Run 调度、状态、队列、模型与 Tool 调用、Artifact 和事件。它必须明确幂等、背压、超时、取消和恢复语义。业务 Runtime 可以由平台托管，也可以是符合统一契约的自管实现；后者仍要接入身份、策略与 Telemetry 底线。

开发者面

开发者面是平台的产品界面，包括 SDK、CLI、模板、Sandbox、本地调试、文档和支持。Golden Path 应把安全默认值和生产证据自动装配进去，同时公开逃生舱及其代价。它不能只是控制面表单的另一层包装。

运营面

运营面把 Trace、日志、指标、评测、账单、审计与变更事件关联成可行动证据。它需要回答某次事故影响哪些租户、运行使用了什么版本、谁改变了策略、单位成功任务成本为何变化，而不是只展示模型请求量。

共享服务按稳定边界建设

共享服务的边界应围绕责任与数据所有权，而不是厂商产品清单。AI Gateway 负责模型访问横切控制；Capability Registry 管发现与治理元数据；Executor 负责把已授权动作转为可验证回执；Run、State 与 Artifact Store 管运行事实；Context、RAG 与 Memory 基础设施提供带来源和租户边界的信息；Identity、Policy、Telemetry 与 Eval 分别保留自己的权威判断。

平台不应把所有服务塞进一个数据库和一个发布单元。共享 Schema 会让配置、运行状态、审计和报表相互锁定；共享部署会让低风险 UI 变化获得数据面同等爆炸半径。可以先共用基础设施降低早期成本，但逻辑所有权、数据保留和 SLO 必须先分清。

平台必须允许业务差异化

平台政策分为不可绕过底线和可配置默认值。身份真实性、租户隔离、审计完整性、敏感凭据保护属于底线；模型、Prompt、Tool 组合、领域评测和工作流通常允许团队选择。把两者混成一组“平台规范”，会让使用者为了必要差异私接 Provider 或私叉 Runtime，最终失去治理。

扩展点需要稳定协议、兼容策略和认证测试。自定义 Model Adapter 必须证明流事件、Usage、错误和取消语义；自定义 Tool Executor 必须实现身份、策略、幂等与审计钩子；自定义存储必须满足租户、保留、删除和恢复契约。例外由有期限的决策记录管理，包含 Owner、原因、补偿控制、到期复审和回归 Golden Path 的条件。

平台级可靠性考虑故障域

可靠性首先要回答“谁的请求在什么故障下仍可继续”。控制面不可用时，已固定版本的在途 Run 可继续，新的高风险配置和新租户接入应停止；Registry 不可用时，只能使用未过期的批准快照；某 Provider 或区域故障时，只有数据政策、模型能力、质量和成本约束仍成立，才允许切换。

Google SRE 的 SLO 方法要求从用户关心的行为反推少量指标。平台至少分开看控制面配置发布、数据面 Run 接受与恢复、Gateway 首 Token/完成延迟、关键审计落盘和开发者自助成功率。单一“平台可用率”会掩盖某个平面已经失效。

容量模型不能只算 CPU。主要约束可能是 Provider Token/分钟、并发连接、长流占用、Tool 下游配额、队列积压、向量检索吞吐和 Telemetry 基数。用生产形状压测过载拐点，验证背压、租户公平、预留容量和降级；Google SRE 的发布实践同样强调，仅凭线性估算无法预测过载行为，必须用负载测试找出失效点。

平台从真实重复点渐进演进

迁移从观测开始，因为没有统一基线就无法证明平台收益。先为现有 Agent 增加 Trace、Usage 与身份关联，再用旁路或 Adapter 收敛 Gateway 和 Tool 契约；随后把 Run、评测和发布门禁做成可选 Golden Path；只有当多团队持续复用且手工运营成为瓶颈时，才建设自助 Registry 和更高层编排。

1. 盘点：建立能力地图、调用量、事故、成本、Owner 和私接原因基线。
2. 兼容接入：提供 SDK/代理/事件桥，保持业务协议和回滚路径。
3. 双轨验证：影子流量或低风险租户比较质量、延迟、成本与审计完整性。
4. 分批迁移：按风险与依赖分群，固定退出条件，不做一次性重写。
5. 收敛旧路：只有覆盖、回滚演练和 SLO 达标后，才停止旧入口。

采购方案也走同一链路。PoC 要用代表性任务和故障注入，不只比较功能清单；合同需要覆盖数据使用、区域、保留、导出、限额、事件通知和支持；退出演练要证明配置、Trace、Registry 元数据与业务代码可以迁出。

平台成功不看组件数量

DORA 的平台工程能力指南强调采用与留存以及面向用户的反馈。对 Agent 平台，核心结果是首个生产 Agent 交付时间下降、Golden Path 自愿采用且持续使用、逃逸原因被关闭，同时质量、SLO、安全和单位成功任务成本改善。

分类验收的最低产物是一份跨团队可评审的 RFC：能力地图和非目标、四平面责任、build-vs-buy ADR、SLO/容量与成本模型、RACI、迁移批次、回滚和采用度量。阅读本文不能证明具备平台能力，只有这些产物经业务、安全、运维和财务相关方共同验证，才能证明架构决策可执行。