只要 Agent 能执行动作，就会立刻出现一个系统级问题：
它到底以谁的身份，在什么权限范围内，替谁行动。这个问题如果不明确，整个系统都会模糊。
审批是第一道边界。
并不是所有动作都该自动执行。 高风险动作通常必须经过人工确认，或者至少经过第二层规则校验。
权限是第二道边界。
Agent 可以有读权限、写权限、删除权限、触发权限，但这些权限不应被默认捆绑。 越成熟的系统，越会把动作按风险拆分。
审计是第三道边界。
只要发生动作，系统就需要能回答：
- 谁触发的
- 为什么触发
- 经过了哪些状态
- 最终做了什么
责任链是最后一道边界。
在复杂系统里，责任不能模糊成“是 AI 做的”。 系统必须能明确：
- 这一轮是谁发起
- 谁拥有最终确认权
- 哪一步是自动执行
- 哪一步是人工接管
没有这套链条，Agent 迟早会在组织层面撞墙。
但如果只把这四个词当成并列名词，也还是太浅。
审批、权限、审计和责任链，并不是四个风格相近的治理概念，而是在 Agent 系统里分别解决四个完全不同的问题。
审批解决的是“时间边界”。 权限解决的是“能力边界”。 审计解决的是“证据边界”。 责任链解决的是“组织边界”。
一旦少掉其中任何一个，其他三个都会失去大半意义。
如果只有审批，没有权限，系统就会变成“高权限默认存在，只是在最后问一下用户要不要继续”。 如果只有权限，没有审计，系统即使做得相对克制，也无法在事故发生后解释到底出了什么问题。 如果只有审计，没有责任链，组织最终还是会滑向一句空洞的话：这是 AI 自己做的。 如果只有责任链，没有审批和权限，那责任最后也只是纸面责任。
所以，第 28 章第一条结论应该是：
可信的 Agent 自治，不是“让系统自己干活”，而是把授权、确认、记录和归责组织成一条可以被暂停、被检查、被追溯的委托链。先看审批。
审批的本质，不是为了让系统显得更谨慎，而是为了在自动执行链里插入一个明确的人类控制点。
很多团队把审批理解成“点一下确认按钮”。 这当然是最表面的形式，但真正重要的是：系统有没有能力在高风险节点暂停，说明当前将要发生什么，等待外部判断后再恢复。没有暂停能力，就谈不上真正的审批；没有恢复能力，审批又会把系统推回纯人工流程。
因此，成熟的审批机制不是临时弹窗，而是一种正式的运行时能力。
它需要明确至少三件事：
- 哪些动作必须触发审批
- 审批前系统要向人暴露哪些关键信息
- 审批后系统如何继续执行或中止执行
这也是为什么现在很多 agent 框架都开始把 interrupt、resume、hooks、watch mode、user confirmation 直接做进运行时，而不是留给业务层自己拼。
再看权限。
权限要解决的，不是“能不能做”，而是“在什么范围内、以谁的身份、替谁做”。
这句话极其关键，因为 Agent 场景里的权限问题，往往并不是传统账号权限表能自动覆盖的。一个 agent 可以代表用户读取邮箱，但未必能代表用户批量发信；可以读取 CRM 某些字段，但未必能删除客户记录；可以浏览网页，但未必能下载任意文件并执行本地脚本。也就是说，Agent 权限必须是任务化、动作化和情境化的。
这要求系统至少做到三层区分：
- 人的身份和 Agent 的身份不能混为一体
- Agent 的读写删触发权限不能默认捆绑
- 同一个 Agent 在不同工具、不同任务、不同阶段的 scope 不能默认一致
一旦没有这些区分，所谓“审批”也很容易沦为走形式，因为系统早已把过大的能力打包交出去了。
因此，第 28 章第二条结论应该是：
审批解决的是“要不要现在做”，权限解决的是“它原本就不该拥有哪些能力”；两者不能互相替代。然后看审计。
审计经常被误解成“把日志留一下”。 这远远不够。
真正有用的审计，不是把一堆文本扔进日志仓库，而是让系统在事后能复原当时的委托链和执行链。也就是说，审计至少要能回答：
- 这次动作由谁发起
- Agent 当时拿到了哪些上下文
- 触发了哪些工具
- 是否经过审批
- 最终写入了哪些状态
- 出错后是如何被中止、回滚或升级的
如果这些问题回答不了，审计就只是存档，不是证据。
这也是为什么 Agent 时代的 observability 会和传统应用有明显不同。传统应用更多追踪请求、异常、延迟和资源占用；Agent 系统还必须追踪 decision trace、tool trace、approval trace、state transition 和 session identity。因为事故的关键，不一定发生在最后一个 API，而往往发生在“它为什么会在那个时刻决定调用这个工具”。
最后看责任链。
责任链之所以重要，是因为 Agent 特别容易制造一种错觉：既然系统里有很多自动规划、自动调用、自动恢复和自动写入，那责任是不是也被自动化了？
答案恰恰相反。
Agent 越自动化，责任越必须被重新显式定义。
因为组织不可能接受“系统自己决定了”成为最终解释。真正需要被定义的是：
- 哪个角色批准了 Agent 上线到这个场景
- 哪个角色决定了它拥有这些权限
- 哪个角色对审批策略和例外规则负责
- 哪个角色在事故发生后有义务解释、修复和对外承担后果
只有这些问题在组织层面被写清楚，Agent 才能真正从 demo 进入生产。
换句话说，责任链的作用，不是事后追责这么简单，而是事前迫使组织把含糊不清的自治边界正式制度化。
于是，第 28 章真正想说明的是：审批、权限、审计和责任链不是一组“安全增强项”，而是 Agent 系统可信运行的最小治理闭环。
审批让系统知道何时该停。 权限让系统知道哪些事本来就不该做。 审计让系统在事后能够被看见。 责任链让组织知道最终由谁负责。
四者只有合在一起，才能让 Agent 的执行权真正变成“受托执行权”，而不是“无主自动化”。
所以，本章最后要落下的判断是：
Agent 不是在真空中行动，它总是在替某个主体、借某组权限、沿某条执行链行动；因此，谁授权、谁审批、谁可见、谁负责，必须被系统显式写出来。