AI Agent 真正进入业务流程后，团队最怕的不是它偶尔做错，而是做错以后没人知道该谁处理。用户说是 Agent 自动做的，管理员说只是配置了工具，业务负责人说自己没有确认，最后所有责任都悬在系统里。
责任边界要和 运行日志、事故复盘、权限复核 放在一起。日志保留证据，复盘找流程问题，权限复核决定 Agent 到底能做什么。
先分清触发人和负责人
触发人只是让任务开始的人，不一定等于结果负责人。比如销售助理发起客户资料整理，真正要确认客户状态变更的人可能是销售负责人；运营同学触发内容检查，最终发布责任可能仍在栏目负责人。
如果触发人和负责人没有分开，Agent 很容易被当成“谁点了按钮谁负责”。这在低风险任务里问题不大，一旦涉及客户、合同、权限或财务，就会留下管理漏洞。
执行范围要写成可检查规则
责任边界不能只写“Agent 负责辅助处理”。更清楚的写法是：Agent 可以读取哪些资料，可以生成哪些草稿，可以调用哪些只读工具，哪些动作必须等待人工确认，哪些动作完全禁止。
这部分可以复用 OpenClaw 权限复核清单 的思路。每个任务场景对应工具动作和数据范围，边界就不再是口头约定。
人工确认不是形式签字
很多团队加了人工确认，但确认人并不知道自己在确认什么。Agent 给出一段流畅结论，下面一个“确认执行”按钮，看似有人工把关，实际只是把责任转移给了人。
有效确认应该展示关键信息：输入来源、工具调用结果、风险提示、变更字段和影响范围。确认人看不到这些，就很难承担结果责任。
异常升级要提前定好
责任边界还要包含异常升级。任务失败、证据不足、权限拒绝、用户身份不明、工具返回冲突时，Agent 应该找谁？是退回触发人、进入人工接管队列，还是暂停流程等待管理员？
这一步可以对照 异常分级。可重试的问题交给系统，需确认的问题交给业务负责人，高风险问题直接熔断。
总结
AI Agent 责任边界的核心，是把触发、执行、确认、结果归属和复盘责任拆开。边界越清楚，团队越敢把 Agent 放进真实流程；边界越含糊，出问题以后就越容易互相推诿。
