治理不是写文档:授权边界、行为约束、结果验收、事后追责

全文 3445 字｜预计精读 18 分钟，建议收藏关注，慢慢研读。

以乌圆之智，铸硅基之魂。 这里是乌圆 AI —— 站在 AI 与企业决策的交叉点，深拆全球前沿架构、模型路线与组织变革。

Agent 上线前，制度写了一柜子。

权限说明、操作手册、异常处理预案、AI 使用规范，每一份都签过字、上过会、归档在同一个知识库里。

三个月后，Agent 把生产库的数据推到了外部群。值班同学半夜爬起来手工拦，事后开总结会，第一句话是"制度没写清楚"。

于是下一轮整改的清单通常长这样：再加一道审批、再加一次录屏、再写一版更细的规范。

问题不在这儿。一柜子制度救不了火，是因为制度不是动作。 它顶多是说明书。

说明书不会拦下任何一次越权。它只在出事之后，证明你曾经想过这件事。

前四篇把治理的概念掰开过：

Agent 治理是什么？先把授权、验收、追责这三件事说清

Agent 越自主，为什么越需要人管？自治度与治理强度怎么同步

AI 出了事，为什么没人说得清？缺的是治理的三段式

治理的对象不只是 Agent：人、Agent、产物，缺一个就漏一层

治理是什么、管到多紧、出了事怎么追、该治谁。这篇往下一层，问具体做哪几个动作。

先做一次穷举。任何一次"Agent 做了不该做的事"，往前追一步，只会落在四个位置。

它够不够得着，是授权边界。动手之后有没有刹车，是行为约束。做完的东西谁说了算，是结果验收。出了事能不能查回那一步，是事后追责。

四类，不多不少。再多一类就会滑回写文档，少一类就有一处没人管。

这不是我搭的概念框架，是官方配置里现成的四套机制。

Claude Code 的托管设置文档里，授权边界是 permissions 下的 deny / ask / allow 规则，行为约束是沙箱开关，结果验收是 PostToolUse 钩子跑审计脚本，事后追责是审计日志事件。四个机制，装在同一份配置里。

整理成一张能贴墙的卡：

这张表是本篇最想让你带走的东西。这个表里没有"文档"这一行。

前面讲治理是什么的时候，Agent 治理是什么？先把授权、验收、追责这三件事说清把三件事摆上了桌。这一篇做的是下半截：拆成能落到配置里的动作。约束该落在哪一维，基于本体建模的 AI 原生操作系统（六）：治理层 5 维框架 + 3 道防线那篇讲过；"|谁来定"这一列怎么落到具体的人身上，智能体项目全周期管理方法（七）：团队治理（终篇）讲的是团队治理那一层。

授权边界这件事，大家习惯问"该给它多少权限"。这问题没有答案，多少都不对，因为该给多少取决于它这一秒在干什么。

该问的是另一个问题：哪些明确不让碰。

Claude Code 的权限规则求值顺序是 deny、ask、allow，先命中谁就按谁算，规则写得多具体都不影响顺序。这条顺序的意思是，写了一条宽的 deny，后面更精细的 allow 是没用的。

官方文档里有一句很硬的话：允许规则没法从拒绝规则里 carve 出一个例外。既然把 Bash(aws *) 整个拒了，就别指望放行 Bash(aws s3 ls)。

那怎么写才不浪费？官方托管配置里有个现成例子，四条 deny 加两个开关：

{   "permissions": {     "deny": ["Bash(curl *)", "Read(./.env)", "Read(./.env.*)", "Read(./secrets/**)"],     "disableBypassPermissionsMode": "disable"   },   "allowManagedPermissionRulesOnly": true }

数一下：4 条 deny，2 个开关，6 个能当场判定放不放行的可判定点。

同一套要求写进提示词，可判定点是 0 个。"不要读取密钥文件"没有拦截点，只是一句请求。差别不在语气，在有没有一个能返回"放"还是"拦"的判断。

还有一条容易忽略：allowManagedPermissionRulesOnly 的作用是，用户个人配置不许自己加规则。否则你划的线，用户可以现场擦掉。

但别把 deny 当成免费的。官方文档写得很清楚：单独写一个工具名当 deny，这个工具会从 Claude 的上下文里整个消失，它连想都不会想到用它。最强的 deny，也最贵。

所以授权边界的质量，不看给得多宽，看划得准不准。

最后一条硬约束必须知道：Bash 规则匹配的是 Claude 写出来的那串命令文本，官方原话是"它不是围绕这个程序的安全边界"。同一个程序换个写法、塞进 sh -c 里，这条 deny 就落空。

所以光有权限规则不够，得配沙箱。这正好是下一类动作。

授权边界管的是能不能开始，行为约束管的是开始之后会被什么拉回来。

这一类动作里最该被看见的，是一条默认行为：沙箱起不来的时候怎么办。

官方文档写得很直白：默认情况下，平台不支持沙箱、或者启动时的依赖检查失败，Claude Code 会不带沙箱继续跑。

也就是说，出故障的那一刻，约束自己蒸发了。

想改，就显式设成沙箱不可用时直接退出。只是改一个开关，性质就完全不同：前一种是约束尽力而为，后一种是约束要么在要么不启动。

第二个开关是关掉"沙箱跑失败就退回去无沙箱重试"这条路。关掉之后 Claude Code 会忽略 dangerouslyDisableSandbox 这个参数。逃生口一堵，边界才是边界。

第三个是 excludedCommands：让某条命令完全在沙箱外跑。代价写得很直白，没有文件系统限制，也没有网络代理。官方同时给了更省的做法，工具只多需要一个目录或主机时，用 allowWrite 或加白名单域名，它仍然待在沙箱里。

还有一类约束跟权限无关，跟上下文有关。

Anthropic 那篇讲上下文工程的文章里提了一个现象：上下文越长，模型对其中信息的召回能力越低，而且所有模型都有。这不是某个模型的缺陷，是上下文本身的性质。

对应的做法有两个。一个是把接近上限的对话总结一遍、重开一个上下文窗口。另一个更轻，需要什么现取什么。

还有一个更值得借鉴的做法是子 Agent 架构。一个子 Agent 可能探索好几万 token，回传给主 Agent 的只有 1000 到 2000 token 摘要，压缩掉九成以上，但结论不丢。

这提示了一件事：行为约束不只管它能干什么，还管它一次能带多少东西进上下文。上下文超载本身就是行为失控。

结果验收这一类动作，最常见的失效方式是：验收标准写成了"符合公司要求"。

这句话没法判。它只是一句态度，不是口径。

口径得满足两个条件：事先写死，机器能判。

事先写死，是第 4 篇讲过的，产物凭什么算对，判定标准要落在业务语义上，在你们公司里"客户""订单""退款"到底指什么，得有个说法。自研 Ontology Engine 最小规格：5 大模块 + Action Engine 7 步链路那篇讲的正是这件事，约束要落到一个能执行的地方，而不是停留在一句话的约定。

机器能判是工程活儿。官方给的做法是在 PostToolUse 上挂一个钩子，匹配 Edit|Write，每次文件改动之后跑一遍审计脚本。脚本说合格就合格，不合格就记下来。

还要定时点：不可逆动作之前验一次，产出之后验一次，中间不必都验。全验，成本会压垮业务。

顺带一个细节值得注意，在审批弹窗上是可以附一句评论的。批还是不批、为什么批，这一句话会被记下来。行为和理由一起留，比只留一个"通过"有用得多。

还有一个细节对多 Agent 场景特别关键：子 Agent 调用工具时钩子照样触发，输入里带着是哪个 Agent、哪一类 Agent。验收记录因此能区分出谁做的，责任链条不至于断在中间。

验收这一环真正想达到的状态是：拿到一条产物，能立刻说出它是谁做的、依据哪条授权、按什么口径判的、判的人是谁。四个答案凑齐，才叫验收过了。没有这四个答案，验收就只是一次点头。

最后一类动作，事后追责。它靠的不是日志系统本身，是每一步当场留下痕迹。

Claude Code 的审计日志事件包含三样东西：执行的是什么动作、哪个账号和哪台设备执行的、前后值的引用。三样凑齐，一次动作才追得回去。

配置改动也有留痕办法，ConfigChange 钩子能记录本地设置文件的改动。

还有一层更硬的机制：如果策略没拿到，客户端干脆不启动。官方文档的表述是，客户端会一直等远程设置刷新，失败就退出，而不是在没有策略的状态下继续跑。

这一层是从源头解决的。没有策略，就没有运行。

但这里要泼一盆冷水，说两个这套方法不该用的地方。

第一，闸口会变成排队。每个动作都要求人批，成本不会消失，只会从机器转移到人身上。

我按常见规模算一遍：5 个 Agent，每天 20 次人工审批，每次 3 分钟，一个月 22 个工作日。

5 × 20 × 3 × 22 = 6600 分钟 = 110 小时，差不多 2.7 个工作周。

超过一个人的全部产能。而且审批的人会疲劳，疲劳的审批等于放行。

所以闸口不该开在每个动作上，只该开在不可逆的动作上：发出去、删掉、改权限、对外发消息。其余用规则判，用事后验收兜。

第二，这套方法有它不成立的地方。一次性任务、低风险的内部只读工具、还在探索期的原型，这三种情况我倾向于不上四套动作。硬上就是浪费人力。

这个判断是我自己的，不是标准答案。凡是"所有 Agent 一律同规格治理"的方案，都可以打个问号。

补一个容易忽略的点：衡量这套东西不能只看一个指标。先行指标看闸口等待时间，变化得快，能提前告诉你规则是不是过紧。滞后指标看违规动作进入生产的数量，变化慢，才说明防线真的有用。卡在"写清楚了但没人查"的团队，往往两个指标都空着。

最后给你能直接抄的。六条红线句式，覆盖四类动作，可以截图发给团队。

一 · 授权边界：本 Agent 只允许对【系统】执行【动作】；其余【动作类型】一律拒绝，不因个人配置放宽。二 · 授权边界：本 Agent 权限只能由【角色】在托管配置中授予；个人配置无权放宽或绕过。三 · 行为约束：沙箱不可用时，系统拒绝启动，不降级为无沙箱运行。四 · 行为约束：本 Agent 不得直接访问【地址或目录】；确需访问时走【流程】，不就地放行。五 · 结果验收：本 Agent 产出物须经【角色】按【可机器判定的口径】验收；未验收不得进入【下游】。六 · 事后追责：每一次【动作】须记录：谁发起、依据哪条授权、判定结果、产物出处；记录不可事后补写。

六条里，第六条的"不可事后补写"最容易被忽略，补写出来的记录证不了任何事。

回头看这五篇：治理是什么、管到多紧、出了事怎么追、该治谁、具体做哪几个动作，下一层是多个 Agent 一起干活时谁说了算。自治档位怎么配，从"提示词工程"到"自治分级"给过一套判据。

最后一句：治理不是把制度写厚，是把动作做实。文档是写给人和审计看的，动作是做给系统执行的，只有后者能在出事之前拦住你。

关注我，带你一起拆解企业AI原生操作系统方法论。

#AI原生#智能体#Agent治理#企业AI#AI组织#数字员工#深度解析#AI认知

以乌圆之智，铸硅基之魂。尽在 乌圆·AI认知觉醒，点击关注 ↓，精彩不错过。

免责声明：本文原创解读部分版权归本公众号所有；网络整理的第三方内容版权归原作者所有，仅供学习参考，禁止商用。如有侵权或内容谬误，请联系我们删除修正。