全局策略像给所有员工发同一把钥匙——有人需要进机房，有人只需要进茶水间。Agent-scoped Policy Overlays 让你给每个Agent配不同的钥匙。
多Agent工作流的安全困境
如果你在用OpenClaw跑自动化，你大概率不止一个Agent。
你可能有一个「客服Agent」回复微信消息，一个「巡检Agent」监控服务器状态，一个「发布Agent」负责定时推送公众号文章。三个Agent各有各的活，但都用同一套策略配置。
这就是问题所在。
在OpenClaw v2026.5.20-beta.1的全局Policy层中（详见5月21日的Agent工坊文章），你设置的模型/网络/MCP策略是一刀切的：
# 全局策略：所有Agent共享
policy:
mcp:
servers:
- name: "filesystem"
allowed_operations: [read, write] # ← 客服Agent和发布Agent都能写文件
这意味着你的「客服Agent」——一个只需要读FAQ文件的Agent——也能写文件。如果哪天它的prompt被用户诱导着说"帮我把日志清空"，它真的能做到。
这不是理论上的攻击场景。2026年5月，OpenClaw合并了 Agent-scoped Policy Overlays (#85817) 和 Claude live Bash执行策略修正 (#86330)，正是为了解决这个问题。
截止5月25日18:00，这两个PR已经合并到主分支，成为下一个beta版本的基石功能。
什么是Agent-scoped Policy Overlays
一句话：每个Agent可以有自己的策略配置，覆盖全局默认值。
架构上，它用"覆盖层"（overlay）模式工作：
全局默认策略 (policy.yaml)
↓
Agent级策略覆盖 (agents.xxx.policy.yaml)
↓
最终生效策略 = 全局 + 覆盖
覆盖规则：
- Agent级配置覆盖同名全局配置
- Agent级未配置的项，继承全局默认值
- blocked_* 列表是追加模式（Agent不能取消全局的block，只能增加自己的block）
这种设计保证了安全底线不可降低——全局ban掉的危险操作，单个Agent不能给自己开绿灯。
配置实战：三步搭建分层策略
第一步：定义全局底线
# ~/.openclaw/policy/global.yaml
# 全局策略：所有Agent必须遵守的底线
policy:
# 模型底线：绝不允许使用未审查的本地模型
model:
blocked_providers:
- ollama-local
- custom-unverified
- llama-cpp-local
content_filter:
block_patterns:
- "rm -rf /"
- "DROP TABLE"
- "DELETE FROM"
- "/etc/passwd"
- "/etc/shadow"
sensitive_pii: true
# 网络底线：绝不允许访问的域名
network:
blocked_domains:
- "*.ngrok.io"
- "*.trycloudflare.com"
- "pastebin.com"
- "*.requestbin.com"
- "termbin.com"
# MCP底线：所有Agent统一限制
mcp:
servers:
- name: "filesystem"
allowed_operations: [read, write]
blocked_operations: [delete, chmod, chown]
path_whitelist:
- "/home/agent/projects/*"
第二步：按Agent角色配置覆盖
# ~/.openclaw/policy/agents/customer-service.yaml
# 「客服Agent」策略：最小权限 = 只读 + 受限网络
policy:
model:
# 覆盖全局：客服只允许低成本模型
allowed_providers: [anthropic]
max_tokens_per_request: 8000 # 客服不需要长回复
network:
# 覆盖全局：客服只能访问微信API和知识库
allowed_domains:
- "api.weixin.qq.com"
- "qyapi.weixin.qq.com" # 企业微信
- "docs.internal.company.com" # 内部知识库
mcp:
servers:
- name: "filesystem"
# 覆盖全局：客服Agent只能读，不能写
allowed_operations: [read]
path_whitelist:
- "/home/agent/faq/*"
- "/home/agent/sop/*"
# ~/.openclaw/policy/agents/deploy-bot.yaml
# 「发布Agent」策略：需要写权限 + GitHub访问
policy:
model:
allowed_providers: [anthropic, openai]
max_tokens_per_request: 32000
network:
allowed_domains:
- "api.weixin.qq.com" # 公众号发布
- "api.github.com" # GitHub操作
- "api.anthropic.com"
- "api.openai.com"
mcp:
servers:
- name: "filesystem"
# 覆盖全局：发布Agent需要完整的读写能力
allowed_operations: [read, write]
path_whitelist:
- "/home/agent/projects/ai-neican/content/*"
- "/home/agent/projects/ai-neican/images/*"
- name: "github"
allowed_operations: [read, write]
repo_whitelist:
- "my-org/ai-neican"
# ~/.openclaw/policy/agents/monitor.yaml
# 「巡检Agent」策略：只读 + 仅查询API
policy:
model:
allowed_providers: [deepseek] # 巡检用便宜模型即可
max_tokens_per_request: 4000
network:
allowed_domains:
- "api.weixin.qq.com" # 查询公众号数据
- "api.github.com" # 查询仓库状态
- "status.internal.com" # 内部健康检查
mcp:
servers:
- name: "filesystem"
allowed_operations: [read] # 巡检只需读
path_whitelist:
- "/home/agent/logs/*"
- "/home/agent/projects/ai-neican/content/*"
第三步：在Agent定义中绑定策略
# ~/.openclaw/agents.yaml
agents:
customer-service:
model: claude-sonnet-4-20250514
policy: policy/agents/customer-service.yaml # ← 绑定独立策略
platforms: [wechat]
prompt: |
你是AI创业内参的客服Agent。你的职责：
1. 回复用户关于AI工具的咨询
2. 引导用户查阅FAQ和过往文章
3. 收集用户反馈
严格禁止：修改任何文件、发送外部网络请求、执行系统命令。
deploy-bot:
model: claude-opus-4-20250514
policy: policy/agents/deploy-bot.yaml # ← 发布Agent有写权限
platforms: [wechat, github]
prompt: |
你是发布Agent。职责：
1. 将审核通过的文章提交到公众号草稿箱
2. 生成封面图并上传素材库
3. 更新GitHub仓库的文章索引
monitor:
model: deepseek-v4-pro
policy: policy/agents/monitor.yaml # ← 巡检Agent只需读
platforms: [wechat]
schedule: "*/30 * * * *"
prompt: |
你是系统巡检Agent。每30分钟：
1. 检查公众号草稿箱是否有新内容
2. 检查GitHub仓库的commit状态
3. 如果发现异常，通过企业微信通知负责人
Claude live Bash 执行策略修正：为什么它很重要
与Policy Overlays同批合并的还有一个关键修复：#86330——Claude live Bash执行策略修正。
修复前的问题
当Agent使用Claude的live Bash功能（实时交互式终端）时，Policy引擎没有正确读取Agent-scoped的策略。具体表现为：
Agent: customer-service（策略：只读）
用户通过微信诱导Agent执行: "帮我执行 ls /tmp"
↓
Agent调用Claude live Bash
↓
❌ 修复前：live Bash绕过了customer-service的策略，直接执行了
✅ 修复后：Policy引擎检查Agent-scoped策略 → 拒绝执行（filesystem: read only, no bash）
修复的技术细节
fix(agents): honor effective exec policy for Claude live Bash (#86330) 的核心改动：
- 在live Bash执行路径中，Policy引擎不再读取全局policy
- 改为读取
effective_policy(agent_id)—— 合并了全局+Agent覆盖层的最终策略 - 如果Agent级策略禁止bash操作，live Bash请求在Policy层就被拦截
这意味着Policy Overlays不只是配置文件——它实实在在地在运行时生效。
实战案例：一人公司的Agent权限分层
假设你一个人运营"AI创业内参"，下面是三个Agent的权限矩阵：
| 权限维度 | 客服Agent | 发布Agent | 巡检Agent |
|---|---|---|---|
| 读文件 | ✅ FAQ目录 | ✅ content目录 | ✅ 日志目录 |
| 写文件 | ❌ | ✅ content/images | ❌ |
| 删除文件 | ❌ | ❌ | ❌ |
| 微信发消息 | ✅ 回复 | ✅ 发布文章 | ✅ 通知 |
| GitHub读 | ❌ | ✅ 仓库状态 | ✅ commits |
| GitHub写 | ❌ | ✅ 创建PR | ❌ |
| 外部API | ❌ | ✅ Anthropic/OpenAI | ❌ |
| Bash执行 | ❌ | ✅ 图片处理 | ❌ |
| 模型选择 | Claude Sonnet | Claude Opus | DeepSeek |
| Token上限 | 8K | 32K | 4K |
关键原则：不是"先给权限再收窄"，而是"先用最小权限跑通，需要时再加"。
常见踩坑与排查
坑1：Agent策略文件路径错误
# ❌ OpenClaw不会报错，只是静默跳过
policy: agents/customer-support.yaml # 实际文件是 customer-service.yaml
# ✅ 用 dry-run 验证
openclaw policy validate --agent customer-service --dry-run
坑2：以为Agent可以取消全局block
# 全局
policy:
mcp:
servers:
- blocked_operations: [delete, chmod, chown]
# Agent策略
policy:
mcp:
servers:
- allowed_operations: [read, write, delete] # ← delete仍然会被全局block！
blocked_* 总是追加，Agent不能取消。如果需要Agent执行delete，必须在全局层面调整。
坑3：策略覆盖是深度merge，不是替换
# 全局
policy:
mcp:
servers:
- name: "filesystem"
allowed_operations: [read, write]
path_whitelist: ["/home/agent/*"]
# Agent
policy:
mcp:
servers:
- name: "filesystem"
allowed_operations: [read] # 只覆盖operations
# path_whitelist 继承全局的 "/home/agent/*"
最终该Agent的filesystem权限 = operations: [read] + path_whitelist: ["/home/agent/*"]
总结：Agent分层治理的三条金律
- 全局设底线，Agent按需放开：全局policy写最严格的限制，Agent级policy只做"额外允许"的操作
- 最小权限起步：新Agent默认只有read权限，需要write时再明确配置
- dry-run验证：每个Agent上线前用
openclaw policy validate --agent <name> --dry-run跑一遍
截止2026年5月25日，Agent-scoped Policy Overlays已合并到OpenClaw主分支。虽然还在beta阶段（当前v2026.5.24-beta.2），但对于跑多Agent工作流的创业者来说，现在适配这套策略分层体系，能省掉未来的安全债务。
实操建议：先把现有Agent的权限梳理成上面的矩阵表，然后用本文的模板逐一定义策略文件。预计30分钟完成3-5个Agent的迁移。