第 15 章：黄金路径、共享网关与反动物园模式¶

1. 为什么即使有不错的组织模型，没有工程模板也会很快散掉¶

当你已经决定了谁拥有平台、谁拥有产品之后，下一个问题马上就会出现：团队在实践里到底应该复用什么？

在贯穿全书的支持场景里，这个问题已经非常具体：团队不应该为了同一个支持智能体，又把运行回路、策略钩子、工具网关和追踪各自重搭一遍。如果平台不给出这条现成路径，组织模型就会停留在纸面上，而工程形态很快又退回到一堆本地变体。

如果这个问题没有答案，就会出现熟悉的场景：

• 每个团队都写自己的运行时封装；
• 策略钩子在各处长得都不一样；
• 工具适配器在契约上逐渐分叉；
• 发布实践散落在各自的 wiki 里；
• 可观测性接线靠手工复制，慢慢漂移。

也就是说，形式上你有运行模型，但实际上还是有很多本地系统，它们看起来相似，却互不兼容。

2. 黄金路径不是“最佳实践文档”，而是默认可工作的路径¶

很重要的一点是，不要把黄金路径和一组建议混为一谈。

建议会被选择性阅读。 而一个好的平台产品里的黄金路径，应该是团队真心觉得“直接用它比绕过去更省事”。

它通常包含：

• 起步用的运行时模板；
• 预先接好的追踪与评测钩子；
• 默认接入的策略集成；
• 已批准的工具网关；
• 默认的部署与发布设置；
• 典型产品工作流的示例。

只有当团队待在这条路径上更划算时，黄金路径才是真的有效。

3. 共享网关的意义，是避免把关键错误复制到整个组织¶

有几层能力特别不适合留给各团队自由发挥：

• 访问外部能力；
• 策略执行；
• 密钥处理；
• 审计轨迹；
• 审批工作流；
• 遥测发出。

如果每个团队都自己实现一遍，组织几乎一定会把同样的错误复制出五个版本。

所以共享网关不是官僚主义。它是把最贵、最敏感的问题集中起来，一次性认真解决的方式。

flowchart LR
    A["产品团队 A"] --> D["共享网关与平台基础件"]
    B["产品团队 B"] --> D
    C["产品团队 C"] --> D
    D --> E["策略、追踪、审批、能力访问"]

4. 可复用模板应该带有明确取向，而不是抽象到失去价值¶

平台团队很常见的一个错误，是把模板做得尽可能中性，好像这样就能“适配所有人”。

现实里这通常帮不到任何人。它太泛化了，需要大量手工拼装，所以团队最后还是会走向自定义实现。

一个好的模板往往带有明确取向：

• 它定义了基础运行结构；
• 它已经包含策略钩子；
• 它已经接好追踪；
• 它有已批准的部署路径；
• 它带有可运行示例；
• 它只暴露有限的扩展点。

是的，这样会少一点“通用性”。但它对真实组织更有用。

5. 你不需要为所有类型的智能体准备一条唯一的黄金路径¶

这里也要有成熟度。单一路径很少能同时适合：

• 问答智能体；
• 工作流智能体；
• 审批密集型智能体；
• 高风险动作智能体；
• 内部副驾驶。

所以更实际的做法通常是：

• 一个基础平台核心；
• 2 到 4 条标准黄金路径；
• 共享网关和可观测性底座；
• 为特殊情况提供可控的偏离。

这比“一个统治世界的巨型模板”或者“完全混乱”都更靠谱。

6. 反动物园模式的起点，是在正确的地方限制自由¶

“平台动物园”这个词通常指的都是类似的问题：

• 运行时太多；
• 连接工具的方式太多；
• 本地策略引擎太多；
• 遥测模式太多；
• 几乎一样的封装层太多。

减少这个动物园，不应该靠一刀切禁止一切，而是要在关键位置加上清晰的限制：

• 一个统一的契约层；
• 一个共享网关；
• 有限数量的受支持运行时模式；
• 高风险偏离需要平台审查；
• 对旧绕路方案有淘汰策略。

6.1. 已批准模式注册表不只帮助控制，也帮助提速¶

当平台维护一份活的已批准模式列表时，产品团队会更快回答两个常见问题：

1. 什么可以直接使用，不需要单独审查？
2. 什么已经算高风险偏离？

一个好的注册表通常会包含：

• 受支持的运行时模板；
• 已批准的网关；
• 已批准的能力类别；
• 允许的连接器模式；
• 已废弃的本地绕过方式。

这不仅对安全团队有帮助，也会提升开发速度，因为团队不需要每次都从零重新判断。

7. 一个平台默认策略示例¶

下面是一个很实用的模板，用来把黄金路径和偏离明确写出来：

platform_defaults:
  required:
    - shared_tool_gateway
    - standard_trace_schema
    - policy_hooks
    - eval_gate_in_ci
  supported_templates:
    - qa_agent
    - workflow_agent
    - approval_agent
  deviations_require_review:
    - custom_runtime
    - direct_tool_access
    - custom_telemetry_schema
    - bypass_of_policy_layer

这样的策略不会扼杀速度，它只是去掉了模糊地带。

7.1. 注册表和淘汰策略最好一起存在¶

一种很弱的模式是：平台有“推荐路径”，但没有正式说明哪些做法已经不该再被接受。

更成熟的组合通常是：

• 已批准注册表；
• 可见的偏离；
• 淘汰窗口；
• 例外情况的审查路径。

这才不会让反动物园策略退化成一句无力的“请大家尽量走标准路径”。

8. 共享网关不只提升安全，也能提升演进速度¶

当关键路径被集中起来以后，平台团队可以：

• 在一个地方更新契约；
• 一次性改进审计轨迹，所有团队都受益；
• 调整发布护栏，而不用重写十个产品；
• 更快推出新的策略能力；
• 更快修复大面积运行问题。

所以共享网关不只是控制手段，它也是工程改进可以规模化传播的方式。

9. 常见错误¶

这里也有很多重复出现的错误：

• 黄金路径太重，团队就绕开；
• 共享网关太慢或太难用；
• 例外逐渐变成常态；
• 模板很快过时；
• 平台团队没有追踪团队到底在哪些地方偏离路径；
• 说了要淘汰，但从来没有真正执行。

于是组织表面上在谈标准化，实际上只是在继续生产旧混乱的新变体。

10. 如果你真的想对抗“动物园”，该测什么¶

这里更有价值的运行指标是：

• 本地运行时分叉的数量；
• 绕过网关的直接工具访问路径数量；
• 使用受支持模板构建的智能体占比；
• 在黄金路径上启动一个新工作流的中位时间；
• 没有负责人的活跃偏离数量；
• 淘汰不安全模式所需时间。

这些指标比单纯统计“有多少团队在用平台”更有意义。

10.1. 清单漂移本身也值得被计量¶

还可以单独跟踪平台清单里的漂移：

• 有多少运行时没被注册；
• 有多少活跃智能体运行在已批准模板之外；
• 有多少连接器没有负责人；
• 有多少偏离超过了审查窗口还在继续。

如果这些数字在上涨，那反动物园策略也许形式上还存在，但实际上已经在失守。

11. 给黄金路径和反动物园模式做一次快速成熟度测试¶

团队不应该只因为已经发布了模板、网关和推荐的架构图，就觉得自己已经有了真正的平台路径。

更高的标准应该是：

• 黄金路径真的比绕过去更容易使用；
• 共享网关能帮各团队消除重复出现的关键错误；
• 受支持运行时模式是被有意识限制的；
• 偏离是可见的、有负责人的，并且会被推向审查或淘汰；
• 平台默认值能可度量地减少分叉、复制粘贴和本地封装。

如果这些条件大多不成立，那组织也许已经有一些平台资产，但还没有真正的反动物园运行模型。

12. 现在就该做什么¶

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

• 你真的有一条比绕过去更容易用的黄金路径吗？
• 敏感能力是否有共享网关？
• 受支持运行时模式的集合是否受控？
• 偏离是否可见，而且有负责人？
• 平台能不能淘汰不安全的本地模式？
• 新的平台层是否真的减少了复制粘贴和本地分叉？

如果连续好几个问题答案都是“否”，那你现在做的还不是平台产品，而是一套带着良好愿望的库。

13. 下一步做什么¶

先确认黄金路径和共享网关真的比绕路更容易用，再去看这条路径怎样落成运行时代码。

这一章之后，下一步已经不再是新的组织图，而是代码骨架：去看黄金路径、共享网关和已批准运行时模式怎样在参考实现里真正固定下来。

• 第 14 章：平台团队与产品团队
• 第 16 章：基础运行时蓝图
• 第六部分：组织模型
• 参考资料