企业官网建设流程全解析

很多人一谈 Agent 安全，就会走向两个极端。一端是过度乐观：

模型很强，给它权限，它会自己判断。

另一端是过度保守：

Agent 很危险，最好什么都别让它做。

这两个判断都不够工程化。生产级 Agent 的目标，不是让它完全自由，也不是把它关成只能聊天。而是让它在明确边界内行动。

该读的能读。 该写的能写。 高风险动作要审批。 生产资源要隔离。 所有关键动作可审计。 失败以后能回滚或补偿。

这就是权限、沙箱与人类监督要解决的问题。

一、安全不是“不让它做事”

如果一个 Agent 只能回答问题，风险当然低，但价值也有限。真正有价值的 Agent，一定会开始行动：

修改文件 运行命令 访问数据库 调用内部 API 创建工单 发消息 发起退款 触发部署

这些动作风险不同：不能一刀切，读 README 和删除生产数据，不应该在同一套权限里。

运行单元测试和执行部署，也不应该被同样看待。

所以第一步不是问：

给不给 Agent 权限？

而是问：

这类动作属于哪一级风险？ 需要什么边界？ 需要谁确认？ 执行后如何留痕？

二、五级权限模型

我建议先用五级模型做基础分层。

Level 0: Read-only Level 1: Write workspace Level 2: Run commands Level 3: Network / external services Level 4: Production / irreversible actions

Level 0 是只读。

适合新项目第一天接入：

读文件 查文档 分析日志 总结结构 审查 diff

Level 1 是工作区写入。

允许修改本地文件，但不能执行高风险命令。

适合：

改代码 补文档 生成测试 更新配置样例

Level 2 是命令执行。

允许跑测试、构建、格式化、脚本。

这里要开始引入 allowlist。

比如：

pnpm test pnpm typecheck pytest go test

但不应该默认允许：

rm -rf deploy kubectl apply terraform apply

Level 3 是外部服务。

包括网络访问、SaaS API、数据库、云资源，这里要看凭证来源、最小权限和审计。

Level 4 是生产或不可逆动作。

比如：

删除数据 退款 发消息给用户 发布文章 部署生产 修改权限 旋转密钥

这一级默认不应该自动执行，至少需要人工确认、二次校验和审计记录。

三、沙箱解决环境边界

权限模型回答的是“能做什么”。

沙箱回答的是“在哪里做”。

常见沙箱维度包括：

filesystem sandbox network isolation process isolation container / devcontainer temporary workspace read-only mount command allowlist secret isolation

文件系统沙箱限制 Agent 能读写哪些目录；网络隔离限制它能访问哪些外部地址。

容器隔离限制命令执行的系统影响。临时工作区让 Agent 可以大胆尝试，但不会污染主工作区。

密钥隔离则避免它误读.env、云凭证、生产 token。

沙箱不是为了降低效率，沙箱是为了让你敢开放更多能力。没有沙箱，你只能给 Agent 很少权限。有了沙箱，你可以让它安全地试错。

四、审批门不是每一步都问

很多工具的审批体验很差。

Agent 每跑一个命令都问一次。

人类不停点确认。最后大家要么烦了全放开，要么不用了。更好的审批策略应该按风险触发。低风险动作可以自动执行。中风险动作可以批量确认。高风险动作必须逐项确认。

例如：

读取文件：自动允许 修改工作区文件：允许，但展示 diff 运行测试：自动允许 安装依赖：询问 访问外网：按域名询问 修改生产资源：强制人工审批 删除数据：禁止或双人审批

审批门要精确：太粗，会挡住正常工作；太松，会让风险进生产。

五、Human-in-the-loop 与 Human-on-the-loop

人类监督也要分层：Human-in-the-loop 是人在循环里。Agent 每到关键节点都要等人确认。

适合高风险、低频、价值判断强的任务。

比如：

退款审批 生产部署 客户通知 法律合规判断 数据删除

Human-on-the-loop 是人在循环上方。

Agent 可以持续运行，但人类通过仪表盘、告警、审计和抽检监督它。

适合低风险、高频、可回滚、可验证的任务。

比如：

每日文档漂移检查 PR 风险摘要 测试失败归因 依赖更新建议 工单分类

成熟系统不会只选一种。

它会把不同动作路由到不同监督模式。

六、敏感动作分类

你可以从这张清单开始给动作分类。

支付：退款、扣款、订阅变更 数据：删除、导出、批量修改 发布：部署、发文章、发公告 通讯：发邮件、发短信、发站内信 权限：加管理员、改角色、读密钥 隐私：访问用户资料、下载日志 基础设施：改 DNS、改云资源、改防火墙

这些动作不一定都禁止，但必须有更强边界。

至少包括：

明确对象 明确金额或范围 明确原因 明确执行人 明确审批记录 明确回滚或补偿方案

如果一个动作不能回滚，就不要让 Agent 自动执行；如果必须自动执行，就要把验证、审计和熔断做得更强。

七、审计日志是安全边界的一部分

很多团队只记录最终结果，这不够。

Agent 审计日志至少应该回答：

谁触发了任务？ Agent 看到了哪些上下文？ 调用了哪些工具？ 工具输入是什么？ 工具输出是什么？ 哪些动作经过审批？ 谁批准的？ 是否触发了错误或回滚？ 最终结果是什么？

没有这些记录，出了问题就只能靠聊天记录和记忆排查，这在生产系统里不可接受。

审计不是合规装饰，它是事故恢复的基础设施。

八、实战Checklist

给 Agent 接入新任务前，先问这十个问题。

1. 这个任务最高风险动作是什么？ 2. 默认能否只读启动？ 3. 哪些目录可以写？ 4. 哪些命令自动允许？ 5. 哪些命令必须审批？ 6. 是否需要网络访问？ 7. 是否会接触密钥或隐私数据？ 8. 是否会产生外部副作用？ 9. 是否有回滚或补偿方案？ 10. 审计日志是否能复盘全过程？

如果答不上来，不要先接生产系统。先在沙箱里跑，先只读。先生成草稿。先让人确认。

九、最后

Agent 安全的目标不是让它无能，而是让它有边界地有用。没有权限，它只能建议。

没有边界，它会危险。

生产级 Agent 需要的是：

分级权限 隔离环境 审批门 审计日志 人类监督 回滚策略

这套系统越清楚，Agent 越能进入真实工作流。

下一篇，我们讲 Harness 的最后一层：

可观测性。

因为看不见 Agent 的循环，就无法调试 Agent。

参考资料：

• OpenAI Agents SDK: Guardrails and Human Review
• Anthropic Claude Code Permissions Documentation
• Martin Fowler: Harness Engineering for Coding Agent Users
• Anthropic: Effective Harnesses for Long-Running Agents

参考文献：

第十篇：权限、沙箱与人类监督，让 Agent 有边界地行动