第 14 章：平台团队与产品团队¶

1. 为什么智能体平台往往不是坏在代码上，而是坏在责任模型上¶

在贯穿全书的支持场景里，这件事非常具体：智能体已经有了，工具网关已经有了，追踪已经接上了，审批也已经在工作。但第一次平台级事故一来，核心问题马上不再是“哪里坏了”，而是“到底谁有责任去修这个共享层，并修改默认路径”。

一开始一切看起来都很简单：几个热心的人，一两个智能体，几条集成，快速实验。这很正常。

问题通常出现在后面：

• 产品团队开始各自做本地智能体运行时；
• 每个团队都用自己的方式写策略检查；
• 可观测性被拆成三种互不兼容的格式；
• 工具适配器重复建设；
• 没人确定平台级事故到底该谁来修。

所以系统在技术上也许还能跑，但在组织层面已经开始散开了。

2. 平台团队不应该把所有决定都从产品团队手里收走¶

有一种很糟糕的极端：平台团队试图成为所有智能体决策的唯一审批点。

然后就会发生这些事：

• 平台变成瓶颈；
• 产品团队失去速度；
• 所有改动都排进同一条队列；
• 平台层膨胀成一个很重的系统。

这个模型是行不通的。平台团队的职责不是自己把所有智能体能力都做完，而是提供稳定的共享层和默认安全路径。

3. 反过来的极端也不好：完全联邦化¶

有些公司会走向另一边：“每个团队自己决定怎么做智能体。”

这很快就会带来：

• 不兼容的契约；
• 不同的安全姿态；
• 参差不齐的评测质量；
• 参差不齐的可观测性；
• 每个团队内部又长出自己的小平台。

短期看像自由，长期看几乎总会变成动物园。

4. 成熟的模型通常是平台与产品分工¶

一个好的运行模型，责任大致会这样拆：

平台团队 负责：

• 编排基础能力；
• 策略框架；
• 工具与能力契约；
• 可观测性与评测底座；
• 共享网关；
• 基线安全模型。

产品团队 负责：

• 用户工作流；
• 产品特定的提示与策略；
• 领域逻辑；
• 任务成功的验收标准；
• 把平台基础能力集成进具体产品。

flowchart LR
    A["平台团队"] --> B["运行时、策略、可观测性、网关"]
    C["产品团队"] --> D["用户工作流、领域逻辑、UX 结果"]
    B --> E["黄金路径与共享基础件"]
    D --> E

5. 平台应该提供黄金路径，而不是只给一堆底层零件¶

如果平台团队只交付一个“零件箱”，产品团队最后还是会各自拼出不同的系统。

一条黄金路径通常包含：

• 基线运行时模板；
• 现成的策略钩子；
• 标准化的追踪与评测接线；
• 经过批准的工具网关模式；
• 关于记忆使用的建议；
• 默认的发布与回归设置。

也就是说，一个好的平台产品不只是让团队“能做”，而是让团队“默认就做得对”。

6. 每一层的责任都应该是显式的¶

最好尽早把这些事情说清楚：

• 谁可以修改平台契约；
• 谁批准新的写入能力；
• 谁拥有策略模式；
• 谁拥有遥测模式；
• 谁负责平台事故的值班；
• 谁决定什么时候某个产品可以偏离黄金路径。

如果责任很模糊，几乎任何事故最后都会变成一场很长的组织性乒乓球。

6.1. 平台清单也应该有人拥有¶

Google 这里一个很实用的提醒是：治理不应停留在策略框架。平台还需要一份明确的清单，说明组织里到底在运行什么。¹²

至少最好看见这些东西：

• 现在有哪些智能体运行时；
• 哪些能力是已批准的；
• 哪些网关被视为已批准；
• 哪些连接器和密钥正在被使用；
• 哪些偏离仍然活跃；
• 每个对象的负责人是谁。

如果没有这份清单，平台几乎注定会滑向“凭印象治理”：表面上大家都觉得“事情是可控的”，直到事故发生，才发现根本没人真正知道生产环境里到底跑着哪些智能体和工具。

7. 不是所有偏离都要禁止，但它们必须是有意识的¶

有时候产品团队确实需要一个特殊情况：

• 非标准工作流；
• 单独的能力；
• 不同的延迟/成本权衡；
• 实验性的发布。

这没有问题。成熟平台和混乱之间的区别在于，偏离必须：

• 可见；
• 被讨论过；
• 影响半径受限；
• 有明确负责人；
• 不会悄悄变成新的默认标准。

8. 一个智能体平台治理策略示例¶

下面是一个很实用的模板：

governance:
  platform_owned:
    - runtime_contracts
    - policy_framework
    - telemetry_schema
    - shared_tool_gateway
  product_owned:
    - workflow_logic
    - domain_prompts
    - task_success_criteria
  requires_platform_review:
    - new_write_capability
    - custom_policy_engine
    - telemetry_schema_change
    - direct_external_tool_access

这段 YAML 不能解决所有组织问题，但它很擅长解决一个永恒的问题：“这件事到底该谁拍板？”

8.1. 已批准注册表几乎和策略模式一样重要¶

团队通常会认真讨论策略，却很少认真讨论注册表。但注册表实际上回答的是：

• 什么才算平台批准；
• 什么可以不经额外审查直接运行；
• 什么目前处于例外区域；
• 什么已经应该退出使用。

一个简单例子：

registry:
  approved_runtimes:
    - agent_runtime_v3
    - workflow_runtime_v2
  approved_gateways:
    - shared_tool_gateway
    - approval_gateway
  deprecated_patterns:
    - direct_prod_tool_access
    - local_policy_engine_without_audit

这个注册表不会替代治理，但它会让治理变得可执行。

9. 平台的衡量标准不该是功能数量，而是它减少了多少混乱¶

很重要的一点是，不要掉进虚荣指标的陷阱，比如：

• 增加了多少工具；
• 启动了多少 MCP 服务；
• 有多少产品团队“接入了平台”。

强平台应该减少的是：

• 重复建设；
• 自定义绕过路径；
• 增加新工作流的成本；
• 事故调查时间；
• 不安全偏离的数量。

不然你可能建设了很多东西，但系统并没有变得更好。

9.1. 持续控制比一次性审查更可靠¶

另一个很有用的升级是：不要只靠人工审批去抓高风险变更，还要靠持续控制。

比如平台可以自动检查：

• 是否出现了绕过网关的直接工具访问；
• 是否出现了没有负责人的连接器；
• 某个运行时是否偏离了已批准模板；
• 是否出现了未经审查的新密钥范围；
• 已废弃模式是否超过了下线期限还在运行。

这很重要，因为平台治理通常不是在架构宣讲当天坏掉，而是几个月后被一连串安静的例外和绕过慢慢掏空。

10. 常见错误¶

常见问题基本都很像：

• 平台成了所有决策的瓶颈；
• 产品完全绕开平台；
• 责任不清晰；
• 可复用基础能力太底层；
• 没有偏离流程；
• 平台路线图和产品团队真实痛点脱节。

这会把组织带向经典岔路：不是平台帮不到人，就是产品团队觉得平台本身就是阻碍。

11. 给平台运行模型做一次快速成熟度测试¶

团队不应该只因为已经组建了平台团队、写下了几条审查规则，就觉得平台负责人归属问题已经解决。

更高的标准应该是：

• 平台和产品负责人归属在真正发生事故的层面是清楚的；
• 黄金路径真正在减少混乱，而不只是发布可复用零件；
• 偏离是可见的、有负责人的、影响半径受限的，而不是被默认容忍；
• 平台清单和已批准注册表让治理变得可执行；
• 平台的衡量标准是重复建设和绕过路径的减少，而不是接入表演。

如果这些条件大多不成立，那组织也许已经有了平台这个标签，但还没有真正的平台运行模型。

12. 现在就该做什么¶

先过一遍这份短清单，把所有回答为“否”的地方单独记下来：

• 哪些东西归平台团队，是否清楚？
• 哪些东西留给产品团队，是否清楚？
• 你有黄金路径吗，还是只有“一组能力”？
• 谁批准新的高风险能力，这件事清楚吗？
• 有没有偏离标准路径的流程？
• 平台是否真的减少了本地运行时实现的数量？

如果连续好几个问题答案都是“否”，那你大概率遇到的已经不是技术问题，而是组织设计问题。

13. 下一步做什么¶

先把负责人归属说清楚，再看这些责任边界如何落成黄金路径、共享网关和反动物园模式。

这一部分接下来的自然步骤，就是继续看共享网关、可复用模板和反动物园模式，避免运行模型只停留在口头上。

• 第 13 章：离线评测、在线评测与回归门禁
• 第 15 章：黄金路径、共享网关与反动物园模式
• 第六部分：组织模型
• 参考资料