企业官网建设流程全解析

权限提示弹得太频繁，工程师会一路点允许；弹得太少，又怕 Agent 在本地跑出一条改坏环境的命令。Anthropic 在两篇工程文里给出了自己的做法，核心是把「隔离边界」和「提示边界」分开配。本文按来源事实拆开讲，读完你能列出自己 Agent 的隔离边界与放行条目。

权限疲劳从哪里来，隔离为什么要单独做

Anthropic 官方文档说，Claude Code 此前靠每一轮请求用户许可来防止代理执行非预期操作。这种做法直接带来提示量：官方文档披露的遥测数据显示，用户批准了约 93% 的权限提示（来源机构 Anthropic）。

高批准率不一定说明每次都安全，也可能是工程师不再逐条读内容。Claude Mythos Preview 就是一个对照：官方文档说，该模型因 blast radius 过高，在 2026 年 4 月被判定不宜发布。来源只说明提示存在疲劳现象，不能推出「用户点允许不足以压住范围过大的动作」这一因果关系。

另一条路是减少提示，但不牺牲边界。Anthropic 官方文档说，Claude Code 的新沙箱功能通过文件系统和网络隔离两条边界，减少权限提示并提升用户安全；内部使用中，沙箱安全地把权限提示减少了 84%（来源机构 Anthropic）。这两个数字针对的是 Anthropic 自己的场景，不能直接套到你的仓库，但方向可借用：先把 Agent 能碰的范围画小，再谈放行。

提示密集时，绝大多数提示都被放行，这正是隔离要单独做的理由。

沙箱边界、默认只读、自动批准，这三层怎么分工

最底层是执行环境边界。Anthropic 官方文档说，沙箱运行时可定义代理可访问的目录和网络主机，无需自行起容器管理；同期还发布了 Claude Code on the web，在云端隔离沙箱里运行 Claude Code。这一层的责任是「就算判断错了，也够不到别处」。

中间层是默认姿态。Anthropic 官方文档说，Claude Code 默认只读，修改或运行命令前需要请求权限。在作者设计的假设规则里，默认只读意味着未列入放行清单的动作一律回到人工，而不是默认放行后再补救；这是自建 Agent 的作者自设规则，并非来源验证的厂商默认行为。

上层才是自动批准策略。Anthropic 官方文档说，其近期构建的 Claude Code auto mode 用来自动化更安全的批准，以缓解批准疲劳；auto mode 在执行前捕获约 83% 的过度积极行为（来源机构 Anthropic）。这句话的边界要读清：捕获的是执行前动作，不是替代沙箱，也不能替代你对自己仓库风险面的判断。

三层没有互相替代关系。按作者设计的假设示例，沙箱缩小可触范围，默认只读决定未列举动作的去向，auto mode 只处理其中一部分可自动判定的批准；这是作者自设的三层分工，不适用于没有默认只读机制的 Agent。若把 auto mode 当作唯一防线，沙箱白名单之外的路径仍然要靠它逐条挡，漏一条就是真实副作用。规划时不妨先问三个问题：这个 Agent 需要写哪些目录？需要访问哪些网络主机？哪些动作可以由策略自动批准、哪些必须人工？把答案写成清单，再映射到三层。

Agent场景自检 提供的自查问题可以当作对照表，用它核对上面三个问题是否都有明确答案，例如沙箱运行时里目录和网络主机分别设成了什么。

用一份策略清单把三层配置落到配置文件

三层的落地方式，是在配置文件里显式写出目录、主机和放行条目，让缺口一眼可见。下面是一份与厂商 SDK 无关的示例配置，仅演示结构，字段按你自己的运行时替换。示例假设计算机上的 Agent 只处理某个仓库及其依赖缓存：

{"example_only":true,"filesystem":{"read_only":["/srv/repo","/srv/repo/vendor"],"read_write":["/srv/repo/src","/srv/repo/tests","/tmp/agent-build"],"deny":["/srv/repo/.env","/root","/etc","/home"]},"network":{"allow_hosts":["registry.example.internal","pypi.org"],"deny_all_else":true},"approval":{"default":"ask","auto_approve":["read_file_under:/srv/repo","run:test_suite","format:within_read_write_paths"],"never_auto":["write_outside_read_write","fetch_unlisted_host","git push"]}}

按这份假设的策略格式校验分三步：第一，读这份配置，先看 read_write 是否被 deny 覆盖，再看它是否落在 read_only 之内；在这份示例里，规则约定 deny 优先，其次由显式 read_write 覆盖只读的父目录，逐条记录每个目标路径最终属于哪一类；第二，检查 network.allow_hosts 是否为空或含通配，避免「整段放行」；第三，检查 approval.auto_approve 里的每条动作，是否引用了上面已定义的路径或主机。这只是作者设计的格式，不代表可直接被厂商运行时执行。检查不通过就说明白名单里有悬空引用，属于配置内部矛盾。

按作者设计的规则以示例数据粗算：若某仓库有 10 个可写子目录，清单里只列出 3 个，其余 7 个不在沙箱可写范围内，写操作会被拒绝；只有环境允许但不在自动批准列表的动作才可请求人工，人工批准不会自动扩大沙箱权限；反过来，若 allow_hosts 写成通配，deny_all_else 形同虚设。

目录、主机、批准三段各自对应一次校验，缺口在图上就能看见。

失败边界、人工交接与回滚怎么准备

再细的清单也会有漏项。Anthropic 官方文档说，Claude Code 默认只读、修改或运行命令前需请求权限；在作者假设引入 auto_approve 的示例里，未列出的动作去向由该假设规则决定，而条目一旦被错误地加进 auto_approve，就不再有人工兜底。为这种情况准备两件事：一是把「新增自动批准条目」本身作为需要评审的变更，二是为每条自动批准动作写明失败后的回滚步骤，比如改动路径的备份位置与恢复命令。

网络主机的漏项同样要单列。allow_hosts 里少一个依赖源，构建会失败；多一个不该有的主机，网络隔离边界就出现开口，需要事后核对实际访问。处理办法是把主机清单当作与代码同级的配置，改动走同一套评审，并在每次新增后按上面的三步校验重跑一遍，确认 deny_all_else 仍生效。

至于人从哪一步接手，可以先定一个简单规则：auto_approve 之外的动作，一律交人工判断，并在提示里带上这条动作命中的清单条目、涉及的路径或主机、以及它未被自动批准的原因。这样接手的人先看到的是上下文，而不是一个光秃秃的允许按钮——93% 批准率伴随的注意力下降，正是这类提示想避免的情形。

下一步可以很小：拿本文那份示例配置，在本地对着自己的仓库改出三个清单——可写目录、可访问主机、自动批准条目——然后跑一遍上面的三步校验。这一步做完，就已经把边界和放行分开放在纸面上了。