AI agent 平台在只跑几条 workflow 的时候，很多责任问题还能靠熟人网络解决。大家大概知道哪个工程师做的、哪个业务 owner 在跟、哪个支持同学比较懂。可一旦自动化资产变多，这种默契会迅速失效。某条 workflow 出故障时，平台团队不知道是该找模板 owner、租户交付 owner，还是 domain owner；业务团队也不知道应该向谁提异常、谁能拍板回滚、谁能决定是否临时停用。问题并不是没人关心，而是责任边界仍然停留在人和关系上，没有进入系统。
这类混乱最昂贵的地方，不只是响应变慢，而是每次故障都会重新消耗组织注意力。支持在群里喊人，工程先问这是不是业务配置问题，业务再反问是不是平台版本问题。等责任终于临时拼起来，真正的修复窗口已经被浪费掉了。平台规模越大，这种责任不清的摩擦越会成为系统性瓶颈。
所以 workflow ownership registry 的价值，不是多一张通讯录，而是让每条自动化资产从一开始就带着清晰的 owner 结构和升级路径。没有 escalation routing，平台并不是没有责任人，而是每次都要重新找一遍责任人。
建议配合 AI agent Support Replay Pack 与 Escalation Handoff、AI agent Postmortem 与 Corrective Action Tracking、AI agent Delegated Admin 与 Scoped Operations 和 AI agent Portfolio Control Tower 一起看。
Builder、operator、owner，不该被默认当成同一个角色
| 角色 | 真正负责什么 | 最容易被误解成什么 |
|---|---|---|
| Builder | 设计和实现这条 workflow 的人或团队 | 永久负责所有线上问题 |
| Operator | 日常运行、支持、监控和小修 | 有权决定策略和下线 |
| Business owner | 决定这条自动化在业务上是否继续存在 | 应该自己处理技术异常 |
| Platform owner | 决定平台级变更、模板和治理边界 | 应该接住所有租户个例 |
很多 escalation 混乱，都是因为这些角色没有被明确拆开。构建者不等于长期 owner，operator 不等于最终拍板者，业务 owner 也不等于要自己解决技术问题。只要系统还没把这些差别写清，组织就会在每次故障里重新用关系去弥补结构空白。
一个真正有用的 ownership registry，必须让“谁能决定什么”一眼可见
registry 不应该只记录名字和团队，还应该显式记录：
- 谁负责运行稳定性
- 谁负责业务效果和是否继续使用
- 谁拥有模板与版本变更决策权
- 当异常跨过某个阈值时，下一层升级对象是谁
如果没有决策边界，平台即使知道联系人是谁，也仍然会在关键时刻卡住。因为很多问题不是“通知谁”，而是“谁有权说停、说回滚、说继续观察”。
一个常见事故：每个人都在帮忙，结果却没人真正负责收口
某团队的一条审批辅助 workflow 在一个关键租户处连续出现错误升级。支持第一时间拉了实现该流程的工程师，工程师怀疑是租户特殊配置导致，业务 owner 则认为最近平台版本更新后才开始出现。三方都在响应，也都没有完全甩锅，但问题还是拖了两天才真正止住。原因不是没人处理，而是没有一份清晰的 registry 告诉大家：
- 运行时异常先由哪一层 operator 接手
- 何时必须升级给模板 owner
- 谁有权决定把该租户临时回退到旧流程
- 事后 corrective action 由谁负责跟到关闭
后来团队把 workflow registry 做成平台元数据的一部分，每条自动化都必须绑定运行 owner、业务 owner、模板 owner 和 escalation path。之后再出现类似问题，支持不用再在群里问“这条是谁的”，而是可以直接按链路升级。
Registry 最怕只在建档时存在，后面却不随资产一起维护
不少团队其实已经有 owner 表，但很快就失效。原因通常是：workflow 迭代、模板迁移、租户切换交付团队之后，owner 信息没有跟着更新。结果就是名义上有 registry，实际仍要靠群里确认。更稳的做法通常是把 ownership metadata 和 workflow 生命周期绑在一起：
- 新建必须填 owner 和升级路径
- 版本升级、模板继承或租户迁移时同步校验 owner 是否仍然有效
- owner 缺失或过期要进入 control tower 红灯视图
只有这样，registry 才不是一份静态台账，而是持续可用的运行基础设施。
如果你现在只能先补一层，先让任何 production workflow 都不能“没有 owner”
比起更复杂的组织图和值班制度，更值得先补的是一条简单但硬的规则：任何进 production 的 workflow，如果没有清晰 owner 和 escalation route，就不能继续放量。因为只要平台允许无 owner 资产继续活着，后面所有事故都还会回到群消息找人这条低效路径上。
AI agent 平台成熟的一个标志，不是大家都更忙，而是每条自动化在出问题时都能立刻知道该由谁处理、谁拍板、谁跟到收口。责任能被快速路由，本身就是系统能力。
延伸阅读：
