只要 AI agent 平台开始把 workflow 做成模板，复杂度就会从“每次项目从零做”转移成“模板怎么演化、派生怎么治理、租户定制怎么收口”。最开始这一切看起来都很合理。某个模板为了适配特殊租户派生出一版，某个团队为了更快交付在模板上直接改一条 review 规则，某个高价值客户再加一个 override。可如果平台没有显式的 template registry 和 inheritance 规则，这些看似局部合理的改动，很快就会把模板体系变成一团谁也说不清祖先关系的分叉森林。
到那时，最痛的往往不是模板数量变多，而是任何一次变更都不再可预测。平台团队不知道一个基础模板改动会影响哪些派生版本，支持团队不知道客户用的是哪层模板叠出来的配置，交付团队也越来越不敢合并回主模板，因为谁都担心改了一个默认值就把某批租户的生产行为一起带偏。
所以 template registry 的价值，不是把模板堆在一个列表里，而是把每个模板的来源、继承关系、可覆盖范围和生命周期状态显式化。没有 inheritance governance，模板复用走到后面不会更快，只会更难改。
建议配合 AI agent Golden Path Template Pack、AI agent Tenant Config Bundle 与 Override Governance、AI agent Version Set Pinning 与 Rollback 和 AI agent Capability Deprecation 与 Sunset Migration 一起看。
模板、派生模板、租户 override，必须被当成三种不同对象
| 对象 | 该承载什么 | 最容易出问题的点 |
|---|---|---|
| 基础模板 | 平台默认推荐的标准 workflow | 一旦承载太多例外，就会变成历史包袱 |
| 派生模板 | 为特定行业或场景形成的稳定分支 | 没有回合并或退役规则，越分越多 |
| 租户 override | 某个租户在有限边界内的局部差异 | 被滥用成“所有特殊需求都先这么改” |
很多平台的混乱，正是从把这三层混成一层开始的。基础模板上不断叠租户特殊逻辑，租户 override 又被长期保留成事实模板，派生模板和正式产品能力也逐渐说不清边界。最后平台拥有的不是模板体系，而是一堆不能轻易碰的历史配置团块。
一个真正可治理的 registry，要能回答“它从哪来、继承了谁、允许改哪层”
模板注册表至少应该让平台稳定回答这些问题：
- 这个模板的上游是谁，是正式基础模板还是某个行业派生模板
- 它允许覆盖哪些字段，是 prompt、tool binding、review threshold 还是 owner metadata
- 哪些变更会自动继承，哪些变更必须显式确认
- 这个模板当前处于 active、frozen、deprecated 还是 sunset 状态
如果 registry 不能给出这些答案，平台就没法做稳定升级。因为每次变更都像在黑箱里碰运气：改了基础模板，不知道派生会不会跟；不跟，又不知道租户是不是已经因此和主线越来越远。
Inheritance governance 最关键的，不是“能不能继承”，而是“继承到哪里停止”
不少团队一说模板继承，就会默认层级越深越灵活。现实里，层级越深，差异解释成本越高。更稳的做法通常是：
- 限制继承层数，不允许出现三层四层以上的长链派生
- 明确哪些字段只能在基础模板控制，不能被下层随意覆盖
- 租户 override 必须有 TTL 或回收计划，不能长期代替模板演化
这不是为了降低灵活性，而是为了保住系统的可解释性。因为支持和工程最终要回答的，不只是“它为什么会这样”，还要回答“它和标准路径到底偏离了多少”。没有清晰的停止点，偏离度就会越来越难量化。
一个常见事故：一次基础模板优化，意外打到了十几个历史派生版本
某团队给高频审批 workflow 做了一次基础模板优化，目的是统一 review 节点和状态语义。单看主模板，这个改动完全合理。问题出在平台并不知道有多少历史派生模板仍在默认继承这部分行为，也不知道哪些租户 override 正在和旧逻辑绑定。结果上线后，十几个租户的 workflow 在不同环节表现异常，有的 review 阈值改变了，有的状态文案失真，有的甚至触发了本不该出现的升级链路。
团队最后补的不是更多回归测试，而是先把 registry 做出来：所有模板必须登记 parent、继承规则、可覆盖字段和当前 owner；任何基础模板变更都要先显示受影响派生树，再决定是继承、冻结还是拆分。这个动作让模板治理第一次从“靠记忆维护”变成了“靠结构维护”。
如果你现在只能先补一层，先把 parent-child 关系和 override 边界显式化
很多平台会先想着做更漂亮的模板中心，但如果 parent-child 关系和 override boundary 还没写清，再漂亮的中心也只是更好看的混乱列表。真正值得先补的，是最基础的 lineage 信息：模板来源、继承方向、允许覆盖的层次和当前生命周期状态。
AI agent 平台一旦开始模板化，治理难点就不再是“要不要复用”，而是“复用之后如何继续可维护”。registry 不是附属品，它是模板体系还能继续演化的前提。
延伸阅读：
