OpenClaw 工作流越复杂，越需要一张责任矩阵。很多团队只给任务配置了 Agent，却没有配置人：谁可以触发，谁负责结果，谁审批高风险动作，谁接管异常，谁复盘事故。流程一出问题，才发现所有人都以为别人会处理。
责任矩阵可以和 多 Agent 交接单、权限复核清单、人工接管队列 组合使用。交接单解决上下游上下文，权限清单解决能做什么，责任矩阵解决谁来兜底。
触发人不等于业务负责人
触发人负责启动任务，业务负责人负责判断结果是否可以使用。两者可以是同一个人，但不能默认相同。比如运营同学触发内容质检，栏目负责人仍然要决定是否发布；客服触发退款材料整理，财务或客户成功负责人仍要确认。
在矩阵里，触发人字段应该记录“谁发起”，业务负责人字段记录“谁对结果负责”。这个区别越早写清，后续争议越少。
审批人只管高风险动作
不是所有步骤都需要审批。读取资料、生成草稿、整理日志可以自动执行；修改客户状态、发送外部通知、触发财务流程、回收权限就应该有审批人。
这和 权限复核 的原则一致。审批应该跟动作风险绑定，而不是跟 Agent 名字绑定。
异常接管人要提前指定
多 Agent 工作流失败时，最耗时间的不是修问题，而是找人。工具超时、权限拒绝、输入冲突、证据不足、下游拒收，这些异常都应该在责任矩阵里提前指定接管人。
如果异常没有明确接管人，就会堆到系统管理员那里。但系统管理员通常不懂业务判断，只能继续转问业务团队，处理时间被拉长。
复盘负责人负责改流程
复盘负责人不是事故记录员，而是推动流程修正的人。一次异常结束后，是否要改输入表单、改权限、加回放测试、更新知识库、补充交接字段，都需要有人跟到底。
这一步可以接到 事故复盘。否则复盘写完就归档，下一次还是同样的问题。
总结
OpenClaw 责任矩阵的价值，是把触发人、业务负责人、审批人、工具管理员、异常接管人和复盘负责人分开。人和 Agent 的边界写清楚，多 Agent 工作流才不容易在关键节点断掉。
