技术手记约 14 分钟阅读
观察 · 思考 · 实践
网站采用 Agent-Native 形态：内置多个 Agent，各自承担不同职责，并需要不同的操作权限——
01
背景与问题
BACKGROUND网站采用 Agent-Native 形态：内置多个 Agent，各自承担不同职责并需要不同的操作权限——
- 代码 Agent：更新代码、触发构建与部署；
- 内容 Agent：更新 CMS 内容、发布文章；
- UI 设计 Agent：调整页面样式与设计资源。
由此产生两个核心问题：
- 问题一：Agent 的权限应该怎么给？——「谁可以调哪些工具、动哪些资源、做哪些动作」如何建模与强制执行；
- 问题二：是否引入 CrewAI 等 Agent 编排框架来完善权限管理？——框架自带能力边界在哪，还需要补什么。
02
核心方案：三层权限模型
PERMISSION MODEL可靠做法只有一个：权限收敛到一个「工具网关 + 策略引擎」上。Agent 只是一个身份（带角色），不能直接调工具，只能向网关发起请求；网关去问策略引擎「这个角色能不能对这个资源做这个动作」，通过才执行，并全程留痕。这套模型与具体编排框架无关，换框架时权限体系原样不动。
架构示意（示意结构）
三层职责
- 身份层：每个 Agent 有唯一身份 + 角色（如
code-agent/content-agent/design-agent），必要时可带「代用户行动」的委托身份（OBO）。 - 授权层：策略引擎定义规则
角色 × 动作 × 资源 → allow/deny。RBAC 起步即可，需要按资源属性细化（如「只许改 src/ 不能碰 config/」）时升级 ABAC。 - 执行层：工具网关强制校验；高风险动作走人工确认（HITL）；全部调用记审计日志；资源本身再做沙箱隔离（目录 / 容器 / 服务账号）作为兜底，策略判断失误也不会直接波及生产。
权限矩阵示例
| Agent 角色 | 可调工具 | 资源与动作范围 | 高风险动作 | 审批策略 |
|---|---|---|---|---|
| 代码 Agent code-agent | git ci deploy | Git 仓库读写、触发构建；不可写 CMS | 生产部署 | 需人工审批 HITL |
| 内容 Agent content-agent | cms media | 内容库读写；无代码库权限 | 对外发布 | 需人工确认 |
| UI 设计 Agent design-agent | design asset | 设计资源、前端样式目录读写；Git 只读 | 覆盖线上样式 | 需人工确认 |
| 说明：绿 = 放行、红 = 禁止、黄 = 需人工介入。表中为示例配置，用于说明模型，实际 scope 需按业务收敛。 | ||||
03
框架选型建议
FRAMEWORKCrewAI 的定位与边界
CrewAI 可以用，但只把它当编排层。它的角色机制适合分工与流程编排（谁做什么、协作顺序）；但其企业版 RBAC 控制的是平台人类用户对 crews / 工具 / 环境变量 / LLM 连接 / Git 仓库的访问——不是「Agent 运行时自己能调哪个工具」的细粒度授权。也就是说：CrewAI 的角色 ≠ 权限。
推荐组合
| 层次 | 可选组件 | 说明 | 适用起点 |
|---|---|---|---|
| 编排层 | CrewAI / LangGraph | 角色分工、流程编排、状态管理；不承载权限 | 选熟悉度高的即可 |
| 授权层 | Casbin / OPA / Permit.io / OpenFGA | Casbin 进程内库、策略存 DB；OPA 独立策略引擎，网关 / API / 数据层均可拦截；Permit.io 托管省运维；OpenFGA 为 Zanzibar 风格关系服务 | 轻量起步用 Casbin；复杂策略上 OPA |
| 执行层 | 自建工具网关（FastAPI / Node 等） | 唯一入口：身份识别 → 策略决策 → 执行/拒绝 → 审计；高风险动作 HITL | 必须自建，工作量核心所在 |
主要取舍：自建策略层 + 网关是主要成本；换来的是权限模型与编排框架解耦——以后换 LangGraph 或自研编排，权限体系原样不动。如果只是内部工具、Agent 数量少，一张「角色 → 工具白名单」配置表即可起步，不必上 OPA。
04
案例项目推荐
CASE PROJECTS调研了 7 个真实可查的开源项目 / 参考设计，按「可借鉴程度」分为四档。完整对比见下文矩阵。
档一 · 整体架构可抄网关 + 沙箱 + 审批的完整骨架
OpenClaw github.com/openclaw/openclaw · MIT
自托管 AI 助手（GitHub 数十万 star）。核心设计：「可信网关 + 不可信执行 + 策略由代码强制」；默认只能读写工作区目录，访问其他文件需显式授权，敏感操作走审批流（approvals），通道级 allowFrom 控制。这是最接近你要的「工具网关」的完整案例。
NVIDIA OpenShell nvidia.com · 开源（Apache-2.0）
安全 Agent 运行时参考架构：沙箱隔离文件 / 进程 / 网络 / 工具，策略在进程外强制（不可绕过），网关负责生命周期与策略，按「意图」授权（zero-trust）。可借鉴其「沙箱兜底 + 网关管策略」的分层。
档二 · 权限层组件可直接用最贴 CrewAI / LangChain 场景
agent-rbac PyPI: agent-rbac · MIT · Python ≥ 3.10
手搓分层 RBAC 库：AgentIdentity / DelegationToken、角色 DAG、通配能力匹配、策略评估器 + 行为风险评分；内置 LangChain 工具包装器、CrewAI 任务拦截器、AutoGen 包装器，并带审计后端。直接装进 CrewAI，即可拦截每次工具调用。
LangGraph Platform Auth docs.langchain.com · 平台能力
运行时身份层参考：@auth.authenticate 把用户级凭据注入 run context，Agent 以用户身份访问资源（OBO 委托）。学「Agent 权限 = 用户权限」的身份写法。
档三 · 网关 / 运营层参考key 级授权 + 预算治理
LiteLLM Proxy docs.litellm.ai · 开源核心 MIT
生产级 LLM 网关：虚拟 Key 即「身份 + 策略包」（模型白名单、预算、限速、团队隔离），并提供请求级审计；企业版加 SSO / OIDC / RBAC。网站若为多租户，这套 key 级授权 + 预算模型可直接搬用。
档四 · 设计参考不抄代码，学审批模式
Claude Code 权限模式 code.claude.com · 闭源
Manual / Auto / Plan 三种模式；Auto 模式用一个分类模型代替人审批（介于「全问」与「全放」之间）；工具级 canUseTool 回调、子 Agent 继承权限。这个「权限分类器」思路值得抄进自己的 HITL。
CrewAI 企业 RBAC（边界提醒） docs.crewai.com · 企业版
管的是平台人类用户对 crews / 工具 / 环境变量 / 仓库的访问，不是 Agent 运行时权限。看清边界：它管人，不管 Agent。
案例对比矩阵
| 项目 | 定位 | 权限机制 | 许可 · 技术栈 | 可借鉴点 |
|---|---|---|---|---|
| OpenClaw | 自托管 AI 助手 · 多 Agent 网关 | 可信网关 + 不可信执行，策略由代码强制；默认仅工作区读写；敏感操作审批流 | MIT · Node/TS | 网关—执行分离 + 审批队列，可当网站 Agent 骨架 |
| NVIDIA OpenShell | 安全 Agent 运行时（参考架构） | 沙箱隔离文件 / 进程 / 网络 / 工具；进程外强制不可绕过；网关管生命周期与策略；按意图授权 | 开源 · 容器化 | 零信任 + 沙箱兜底，「权限按意图给」 |
| agent-rbac | Agent 权限库（手搓 RBAC） | 分层 RBAC：身份 / 角色 DAG / 通配能力 / 策略评估 + 行为风险评分；拦截工具调用 · 内存 · 子 Agent | MIT · Python ≥ 3.10 | 有 CrewAI / LangChain / AutoGen 现成拦截器，最快跑通 |
| LiteLLM Proxy | LLM 网关 | 虚拟 Key = 身份 + 策略包：模型白名单 / 预算 / 限速 / 团队隔离；请求级审计 | 核心 MIT · Python | key 级授权 + 预算 + 多租户隔离的运营设计 |
| LangGraph Auth | 运行时身份层（OBO 委托） | @auth.authenticate 注入用户级凭据，Agent 代用户访问资源 | 平台 · Python/JS | 「Agent 权限 = 用户权限」的身份委托写法 |
| Claude Code 权限模式 | 参考设计（闭源） | Manual / Auto / Plan 模式；Auto 由分类模型审批；工具级 canUseTool；沙箱 Bash | 闭源 | 审批模式 + 「权限分类器」思路，抄进自己的 HITL |
| CrewAI 企业 RBAC | 平台用户权限（非运行时） | 控制人类用户对 crews / 工具 / 环境变量 / LLM 连接 / 仓库的访问 | 企业版 | 看清边界：它管人，不管 Agent 运行时 |
05
落地路线
IMPLEMENTATION路线 A · 自研为主
稳定优先，工作量最大
- 按 OpenClaw / OpenShell 的参考，先定组件边界：网关 — 沙箱 — 审批；
- 实现工具网关：身份识别 → 策略查询 → 执行 / 拒绝 → 审计；
- 接入策略引擎（Casbin 起步，策略存库、可版本管理）；
- 资源层沙箱隔离（目录 / 容器 / 服务账号）；
- 高风险动作接 HITL 审批 + 审计面板；CrewAI 只做编排。
效果：权限模型与框架解耦，最稳。
路线 B · 快速跑通
先用现成组件验证，再逐步替换
- 安装 agent-rbac（pip），接 CrewAI 任务拦截器；
- 给三个 Agent 配角色 + 工具白名单策略；
- 跑通一个 demo（代码 / 内容 / UI 各配一个角色）；
- 验证审计与拒绝行为，再决定是否替换为自研策略 / 网关。
效果：最快看到效果，验证后再投入自研。
建议下一步：花半天读 OpenClaw 权限 / 审批文档 + NVIDIA OpenShell 参考架构博客（均含架构图），把组件边界定下来；随后产出权限矩阵表 + 工具网关骨架代码（Python/FastAPI 或 Node 均可）。
06
参考来源
REFERENCES- OpenClaw 官方仓库：https://github.com/openclaw/openclaw
- OpenClaw 文档（架构与安全）：https://docs.openclaw.ai/
- OpenClaw FAQ（文件权限与敏感操作审批）：https://openclawai.io/zh-cn/faq
- NVIDIA Open Agent Safety Platform：https://www.nvidia.com/en-us/solutions/ai/agent-safety/
- NVIDIA OpenShell 参考架构博客：https://developer.nvidia.com/blog/how-nvidia-openshell-reference-architecture-secures-and-governs-ai-agent-workloads-at-scale
- agent-rbac（PyPI）：https://pypi.org/project/agent-rbac/0.2.0/
- LangGraph Platform 认证与访问控制：https://docs.langchain.com/langgraph-platform/auth
- LiteLLM AI Gateway 文档：https://docs.litellm.ai/docs/simple_proxy
- LiteLLM 企业版（SSO / RBAC / 预算）：https://www.litellm.ai/enterprise
- Claude Code 权限模式文档：https://code.claude.com/docs/en/permission-modes
- Anthropic 工程博客：How we built Claude Code auto mode：https://www.anthropic.com/engineering/claude-code-auto-mode
- CrewAI 企业版 RBAC 文档：https://docs.crewai.com/en/enterprise/features/rbac