面经策

同一个工具（比如「执行命令」）在不同场景下应该有不同的权限。你会怎么设计工具的权限控制？OpenClaw 的工具策略管道是怎么分层的？ ​

  • 标签：AI、OpenClaw、大模型应用开发、AI应用开发、Agent开发

🏛 业务架构师 ​

工具权限控制我用"分层管道"设计（OpenClaw 的工具策略管道正是这个思路），从粗到细四层：

1. 静态声明层（能装什么）：Agent 配置里声明可用工具清单——按角色配工具包，客服 Agent 就不该看到转账工具。最小权限原则在这一层落实。

2. 上下文约束层（能用什么）：运行时按会话上下文收紧——同一"执行命令"工具，开发环境放行、生产环境只读；个人会话可以执行、群组会话禁止（群内消息可能诱导 Agent）。渠道/群组/用户身份都参与判定。

3. 参数校验层（怎么用）：工具执行前校验参数合规——路径白名单（只能动 /data 目录）、SQL 只读检查、金额上限。挡住"工具用对但参数越界"的风险。

4. 审批层（谁批准）：高危操作（删数据、对外发送、资金操作）强制人工确认或双人复核，附操作摘要给审批人。

贯穿设计：每个决策点记审计日志（谁、何时、哪个 Agent、什么工具、什么参数、放行/拦截依据）。

业务视角的核心原则：权限跟着"场景"走而不是跟着"工具"走——"执行命令"本身无善恶，开发沙箱里它是效率工具，生产库里它是事故源。所以权限模型要以"工具×环境×发起者身份"三元组建模。这套管道前期建设成本不低，但一次投入所有 Agent 受益——出过一次越权事故的团队都知道，这钱花得比事后公关便宜太多。

🏗 系统架构师 ​

工具权限控制我用**"分级 + 策略管道"**设计，先讲分级模型再看 OpenClaw 的分层管道：

权限分级（按风险递增）：

  • 只读低危：查询类工具（搜索、读文档）——自动放行 + 限流；
  • 只读敏感：读用户数据、内部系统——需要角色授权（RBAC 绑定到工具）；
  • 写操作可逆：创建草稿、发消息——自动放行 + 审计；
  • 写操作难逆：删文件、改配置——策略限制（作用域白名单）+ 审计；
  • 高危不可逆：支付、删除生产数据、执行任意命令——人工确认闸门 + 双人复核可选。

维度控制：不只"能不能用"，还有参数级限制——exec_command 在只读探索时禁止 rm，在部署场景放行；按渠道/群组降权（群聊里禁用高危工具，防有人诱导 Agent）。

OpenClaw 的工具策略管道（分层过滤）：工具调用请求依次经过多层策略——会话/渠道策略（此渠道允许哪些工具）→ 用户策略（此用户角色可用集）→ 工具级策略（参数校验、路径白名单、资源配额）→ 动态确认（高危弹人工审批）。每层可独立配置，管道可插拔（自定义策略节点），全部决策留审计日志。

架构师要点：策略要声明式（配置而非硬编码）、默认拒绝（白名单制）、可解释（拒绝时告诉用户因为哪条规则）——这三点让权限系统可审计可维护，和零信任架构的原则一脉相承。

💻 全栈开发专家 ​

工具权限控制我按「分层策略管道」设计，OpenClaw 的 Tool Policy Pipeline 就是这个模式：

分层模型（从粗到细）：

  1. 场景层（Where）：哪个渠道/会话/任务类型——生产群允许只读诊断，禁止写操作；私聊允许更多；
  2. 角色层（Who）：用户身份与角色——DBA 才能用 restart_service，普通人只有 query_status；
  3. 动作层（What）：工具本身的危险等级——read（放行）/ write（需确认）/ destructive（禁止或双人确认）；
  4. 参数层（How）：同工具不同参数不同策略——delete(env='test') 放行、delete(env='prod') 必须确认且限制范围（where 必须非空、影响行数上限）。

管道执行（每个 tool_call 过一遍）：

python
def policy_pipeline(call, context):
    for p in [ScenePolicy, RolePolicy, ActionPolicy, ParamPolicy]:
        verdict = p.check(call, context)   # ALLOW / DENY / CONFIRM
        if verdict == DENY:  return deny_with_reason(call)
        if verdict == CONFIRM:
            return request_approval(call, approver=owner_of(context))
    return execute(call)   # 全部通过才执行

工程要点：策略配置外置可热更；DENY 要返回给模型可读的原因（「该操作仅限 DBA 角色」），模型能向用户解释而不是装死；CONFIRM 的审批要带完整调用快照（工具+参数+发起人），防「确认的和执行的不一致」；审计日志记录每次裁决（哪条策略放的行），出事能追责；高危工具加冷却时间（同参数 5 分钟内不允许重复确认执行）。

一个原则：权限默认拒绝（deny by default），显式开放——反过来做必出事故。