如何设计 Agent 的权限系统与业务系统解耦？

网罗开发 （小红书、快手、视频号同名）

大家好，我是展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。

图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG

我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验 。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。

展菲：您的前沿技术领航员

👋 大家好，我是展菲！

📱 全网搜索"展菲"，即可纵览我在各大平台的知识足迹。

每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

文章目录

- 引言
- 一、问题本质：权限逻辑"侵入"业务
- - [1. 逻辑污染](#1. 逻辑污染)
  - [2. 难以统一治理](#2. 难以统一治理)
  - [3. 无法复用](#3. 无法复用)
  - 本质
- 二、核心目标：让权限成为"独立系统"
- - 理想架构
  - 核心原则
  - 本质
- 三、关键设计一：统一权限入口
- - 错误方式
  - 正确方式
  - 示例
  - 本质
- 四、关键设计二：策略外置
- - 正确方式
  - 示例
  - 执行
  - 常见实现方式
  - 本质
- 五、关键设计三：业务无感
- - 错误方式
  - 正确方式
  - 本质
- 六、关键设计四：资源模型标准化
- - 问题
  - 正确方式
  - 本质
- [七、关键设计五：Agent 工具层解耦](#七、关键设计五：Agent 工具层解耦)
- - 错误方式
  - 正确方式
  - 本质
- 八、关键设计六：跨系统一致性
- - 错误方式
  - 正确方式
  - 示例架构
  - 本质
- 九、关键设计七：权限缓存与性能隔离
- - 解决方案
  - 示例
  - 本质
- 十、关键设计八：失败隔离
- - 策略
  - 示例
  - 本质
- 十一、关键设计九：可测试性与可演进性
- - 示例
  - 演进能力
  - 本质
- 十二、实战架构
- - 核心特征
- 总结

引言

当你把 Agent 权限系统真正落地到业务中，很快会遇到一个"工程级问题"：

复制代码

权限逻辑，应该写在哪里？

很多团队的第一反应是：

复制代码

写在业务代码里

于是很快你会看到这样的代码：

ts 复制代码

if (user.role === "admin" && action === "delete_task") {
  // allow
}

短期看没问题，但一旦系统变复杂，就会变成：

复制代码

权限逻辑散落各处
难以维护
无法统一升级

最终演变成一句话：

业务系统 ≈ 权限系统

这其实是一个危险信号。

一、问题本质：权限逻辑"侵入"业务

当权限系统和业务系统耦合时，会出现三个典型问题：

1. 逻辑污染

复制代码

业务代码 = 业务逻辑 + 权限判断

示例：

ts 复制代码

if (canDelete(user, task)) {
  deleteTask(task);
}

随着复杂度上升：

ts 复制代码

if (isAdmin(user) || (isOwner(user, task) && !isLocked(task))) {
  if (env !== "prod" || hasSpecialFlag(user)) {
    deleteTask(task);
  }
}

你已经很难分清：

复制代码

哪部分是业务
哪部分是权限

2. 难以统一治理

复制代码

权限规则分散在：
API 层
Service 层
数据库层
Agent 工具层

结果：

复制代码

修改一个权限规则 → 改 10 个地方

3. 无法复用

复制代码

同一权限逻辑
Web 用一套
Agent 用一套
后台用一套

最终导致：

权限不一致 = 安全漏洞

本质

权限如果不解耦，本质上就是"隐式分布式系统"。

二、核心目标：让权限成为"独立系统"

解耦的目标不是：

复制代码

把代码拆开

而是：

让权限系统成为一个"独立决策层"。

理想架构

复制代码

业务系统（Business Logic）
        ↓
权限系统（Authorization）
        ↓
执行系统（Execution）

核心原则

复制代码

业务系统：不关心"能不能做"
权限系统：只负责"能不能做"

本质

业务负责"做什么"，权限负责"是否允许做"。

三、关键设计一：统一权限入口

所有权限判断必须：

复制代码

走一个入口

错误方式

ts 复制代码

// 到处都是判断
if (user.role === "admin") {}
if (task.ownerId === user.id) {}

正确方式

ts 复制代码

authorize(user, action, resource);

示例

ts 复制代码

const allowed = await auth.check({
  user,
  action: "delete_task",
  resource: task
});

if (!allowed) {
  throw new Error("denied");
}

本质

权限判断必须"收口"，否则无法治理。

四、关键设计二：策略外置

权限规则不能写死在业务代码中。

正确方式

复制代码

策略独立存储（Policy）
+
权限引擎执行（Policy Engine）

示例

json 复制代码

{
  "action": "delete_task",
  "allow": [
    "user.role == admin",
    "resource.ownerId == user.id"
  ]
}

执行

ts 复制代码

policyEngine.evaluate(user, action, resource);

常见实现方式

复制代码

JSON / YAML 策略
DSL（自定义规则语言）
规则引擎（如 OPA 思路）

本质

权限规则应该"可配置"，而不是"写死"。

五、关键设计三：业务无感

业务代码不应该感知权限细节。

错误方式

ts 复制代码

if (user.role === "admin") {
  deleteTask();
}

正确方式

ts 复制代码

if (authorize(user, "delete_task", task)) {
  deleteTask();
}

甚至进一步：

ts 复制代码

executeWithAuth(user, "delete_task", task, () => {
  deleteTask();
});

本质

业务不应该知道"为什么能做"，只需要知道"能不能做"。

六、关键设计四：资源模型标准化

权限系统和业务系统之间，必须有"统一语言"。

问题

复制代码

业务系统：task.id
权限系统：resource_id

如果不统一：

复制代码

权限判断失效

正确方式

统一 Resource Model：

json 复制代码

{
  "type": "task",
  "id": "task_123",
  "owner": "user_1"
}

本质

权限系统依赖"标准化资源描述"，而不是业务对象。

七、关键设计五：Agent 工具层解耦

在 Agent 系统中，还有一层：

复制代码

Tool / Action 层

错误方式

ts 复制代码

tool.deleteTask = () => {
  if (!isAdmin(user)) return;
  deleteTask();
};

正确方式

ts 复制代码

tool.deleteTask = async (ctx) => {
  await authorize(ctx.user, "delete_task", ctx.resource);
  return deleteTask();
};

或者：

复制代码

Agent → Tool → Auth Layer → Execution

本质

工具层不负责权限决策，只负责调用权限系统。

八、关键设计六：跨系统一致性

权限系统必须支持：

复制代码

Web
Mobile
Agent
后台系统

错误方式

复制代码

每个系统一套权限逻辑

正确方式

复制代码

统一权限服务（Auth Service）

示例架构

复制代码

Client（Web / Agent）
        ↓
API Gateway
        ↓
Auth Service（统一）
        ↓
Policy Engine

本质

权限必须"一处定义，处处生效"。

九、关键设计七：权限缓存与性能隔离

解耦后一个现实问题：

复制代码

每次都调用权限系统 → 性能下降

解决方案

复制代码

权限缓存（Cache）
+
短期 Token（Capability）

示例

ts 复制代码

const token = issueCapability(user, action, resource);

// 后续直接验证 token
verify(token);

本质

解耦 ≠ 每次远程调用，而是"逻辑独立 + 性能优化"。

十、关键设计八：失败隔离

权限系统一旦出问题，不能影响业务安全。

策略

复制代码

Auth 服务挂了 → 默认拒绝

示例

ts 复制代码

try {
  authorize();
} catch {
  deny();
}

本质

权限系统的失败，必须是"安全失败"。

十一、关键设计九：可测试性与可演进性

解耦的一个核心收益：

复制代码

权限系统可以独立测试

示例

ts 复制代码

test("user cannot delete others task", () => {
  expect(auth(user, "delete_task", task)).toBe(false);
});

演进能力

复制代码

新增规则 → 不改业务代码
调整策略 → 实时生效

本质

解耦的真正价值，是"可持续演进"。

十二、实战架构

完整解耦架构如下：

复制代码

Agent / Client
        ↓
API / Tool Layer
        ↓
Authorization Layer（统一入口）
        ↓
Policy Engine（策略执行）
        ↓
Resource Model（标准化资源）
        ↓
Business Execution（业务执行）

核心特征

复制代码

权限集中
策略外置
统一入口
跨系统复用
高可观测性

总结

权限系统与业务系统解耦的本质不是：

复制代码

代码拆分

而是：

把"是否允许"从"如何实现"中彻底剥离。

我们可以用一句话总结：

复制代码

业务系统决定"做什么"
权限系统决定"能不能做"

再进一步：

一个成熟的系统，权限逻辑应该"无处不在，但又不在任何业务代码里"。

最终目标：

让权限系统成为一个"可控、可测、可演进"的独立基础设施。