多Agent系统权限隔离实战：共享资源与独立鉴权设计

AgentConnect 这个项目名里的 Agent指的是 AI Agent不是网络代理。它要解决的核心问题很具体当多个智能体被放进同一个执行环境里使用时底层能力可以共享但权限必须隔离。很多人做多 Agent 系统时最容易犯的错是把权限做成“跟着系统走”结果一个 Agent 能读的文件另一个 Agent 也能读一个用户触发的任务另一个用户也能看到日志。AgentConnect 这类设计的核心价值就是把“共享执行资源”和“独立访问权限”拆成两层让多个 Agent 继续复用推理、工具、连接池等基础设施但每一次请求都要按发起者重新鉴权。这篇文章会按我实际测试这类系统的顺序来写先讲清楚权限模型为什么不能省再拆出共享层和鉴权层的代码结构然后给一个能落地的最小验证路径最后把并发、缓存、日志、文件路径这些容易漏的地方单独列出来。如果你正在做多 Agent 平台、Agent 网关、或者想把多个 AI 助手接入同一个 OA 系统这篇文章应该能省掉不少踩坑时间。1. 多 Agent 系统里共享和隔离不能只在需求层面讨论1.1 先想清楚共享的是什么AgentConnect 的第一层设计目标是共享但不是所有东西都适合共享。适合共享的部分通常是成本高、初始化慢、重复建设浪费的资源。比如大模型推理实例、HTTP 连接池、向量数据库连接、同一个知识库的读取缓存、公共工具链的路由表。这些资源如果每个 Agent 都单独初始化内存会翻倍启动时间会变长连接数也会挤压数据库。不适合共享的部分第一是身份上下文第二是数据沙箱第三是操作权限。两个 Agent 可以共用同一个模型服务但它们不能共用同一个用户身份去读写外部系统。两个 Agent 可以访问同一个知识库但每个 Agent 应该只能看到自己被允许看到的知识子集。两个 Agent 都可以调用一个“发送通知”工具但发送结果和接收方范围必须由当前任务的授权者决定。这个区别就是 AgentConnect 里“shared agents”和“separate permissions”两个短语同时存在的意义资源和执行通道是共享的权限判断必须是隔离的。理解不了这一点后续整个权限模型都会搭偏。1.2 “独立权限”要独立到什么程度很多人以为独立权限就是把 API Key 分开发给不同 Agent。实际只做这一步问题非常大。API Key 只解决“请求从哪个系统来”的问题不解决“当前请求代表谁”的问题。一个团队里如果多个用户都通过同一个 Agent 发送请求服务端只看到同一个 Key。这个时候你无法判断这个请求是管理员发起的还是普通成员发起的。一旦 Agent 需要访问内部系统、写文件、拉取订单数据就会出现权限放大的风险。所以 AgentConnect 这类设计里权限至少要独立三层Agent 身份这个 Agent 是谁允许使用哪些工具和模型配置。用户身份当前触发任务的人是谁他的组织角色和资源范围是什么。资源维度这次请求需要操作的文件、数据库表、接口、队列到底属于哪个业务域。也就是说不是“Agent A 能读文件”而是“用户张三通过 Agent A在项目 X 的目录下能读哪些文件”。权限判断必须落到这个粒度。2. 先把权限模型写好再写功能代码2.1 用一张表理清主体、客体和动作我习惯在动手写 AgentConnect 核心代码之前先把权限模型画成一张表。不画这张表后面实现到什么程度全靠猜。类别字段示例主体user_id用户唯一标识主体agent_idAgent 唯一标识主体roleadmin、member、viewer客体resource_typefile、api、database、queue客体resource_scope项目编号、目录路径、表名动作actionread、write、delete、invoke条件condition时间范围、IP 范围、环境标识设计时有一个很关键的点Agent 本身不要拥有太多静态权限。Agent 更像是一个执行器真正决定能不能做的应该是“当前请求的用户 Agent 配置 资源范围”。如果在权限表里给 Agent 本身授予了很大的固定权限一旦 Agent 被外部提示词注入或者误操作影响面会非常大。所以我的建议是Agent 表里只存“能力配置”例如它能调用哪些工具、使用哪个模型、超时时间是多少。真正的资源权限全部放到用户和角色维度去管。这样权限变更时只需要调角色绑定关系不用每个 Agent 都改一遍。2.2 默认拒绝比默认允许更安全AgentConnect 的鉴权逻辑建议用默认拒绝。写权限判断时先定义一个统一入口所有工具调用、文件读取、接口请求都走同一个校验函数。如果当前上下文里找不到用户身份或者找不到资源范围直接拒绝并返回错误而不是放行后让下游处理。用伪代码表示类似这样def check_permission(request): subject get_subject(request) # user agent resource get_resource(request) # resource_type scope # 默认拒绝 if subject is None or resource is None: return False, 缺少身份或资源范围 # 查授权策略 policy get_policy(subject, resource) if not policy: return False, 未配置授权策略 if request.action not in policy.allowed_actions: return False, f动作 {request.action} 不被允许 return True, 这段代码不是完整实现但它表达了一个重要的顺序先确认主体和客体再查策略最后判断动作。很多权限问题不是策略写错了而是请求还没走到策略判断就已经在 Agent 内部被“顺手执行”了。代理执行链路里如果到处都有直接调用很难保证权限统一。2.3 最小权限角色拆分权限模型的另一个重要设计是角色拆分。不要把“管理员”定义成所有权限都有而是把每个权限拆成原子动作再组合成角色。例如viewer可以查看任务状态、查看自己触发的运行日志。operator可以启动任务、停止任务、查看日志但不能删除系统配置。deployer可以更新 Agent 配置、调整模型参数但不能修改审计日志。admin可以管理全部角色但所有敏感操作仍然需要二次确认。这样拆分的好处是单个 Agent 即使被授权为 operator它能碰到的资源范围也很有限。不会出现“能启动任务的人顺手也能删除历史数据”这种权限爆炸情况。3. AgentConnect 的核心实现共享调度层 独立鉴权层3.1 共享调度层要保持无状态设计 AgentConnect 时共享部分可以做成一个无状态的调度层。它负责接收请求、把请求分发给对应的 Agent 实例、管理并发队列、处理重试和超时。这个调度层本身不保存用户私密数据也不保存权限结果只保存任务流转信息。这样做有什么好处第一调度层可以水平扩容。请求多了就多部署几个调度实例模型服务和数据库连接池不会被打爆。第二权限判断可以放在更靠近入口的位置。任何一个新请求进来先在网关层完成身份识别和权限校验再进入 Agent 执行链路。第三Agent 实例之间不容易串状态。调度层不持有用户身份它只传递一个叫做“权限上下文”的对象。伪代码可以这样设计class AgentRequest: agent_id: str user_id: str resource_scope: str action: str payload: dict trace_id: str注意这里没有把完整的用户 Token 传给 Agent 执行器。Agent 执行器只需要一个已经鉴权后的权限上下文里面包含资源范围和允许的动作。这样即使执行器内部有自己独立的逻辑也无法绕过网关去做额外越权操作。3.2 鉴权层放在哪里最合适鉴权层应该放在两个位置。第一个位置是网关入口。所有外部请求进来先做身份认证拿到 user_id 和 agent_id再完成第一道权限校验。这一步的目的是拦截掉绝大多数无权限请求避免它们进入模型推理队列浪费资源。第二个位置是工具调用边界。Agent 在执行任务时通常会调用外部工具、读文件、写数据库。每一条工具调用都需要带上当前请求的权限上下文在工具内部再做一次检查。这一步不能省。因为模型生成的内容是不可完全预料的它可能在一次任务中请求读取多个路径、调用多个接口必须在实际动作发生前做校验。我把这个方案叫“双层校验”。网关层校验通过只代表这个任务有资格进入系统工具层校验通过才代表这个具体动作被授权。两层校验使用同一份权限策略但执行时机不同拦截位置也不同。3.3 最小可运行验证路径第一次验证 AgentConnect 时不需要把 Kubernetes 和微服务全部搭起来。可以先在单机环境里用最简单的 Flask 或 FastAPI 搭一个网关下面挂两个 Agent。每个 Agent 只做一件事读取某个目录下的文件然后返回结果。第一步准备两个 Agent 配置。一个叫 report_agent只能读data/reports/一个叫 invoice_agent只能读data/invoices/。两者都注册到同一个网关。第二步模拟两个用户发起请求。用户 A 属于 report_team用户 B 属于 invoice_team。用户 A 请求 report_agent 读文件应该成功用户 A 请求 invoice_agent 读文件应该失败。第三步在网关层伪造一个请求。故意不传 user_id或者传一个没有角色映射的 user_id看请求是否被默认拒绝。如果这三步都能按预期通过说明最基本的“共享 Agent 独立权限”链路已经成立。之后再去考虑批量任务和并发调度基础会更稳。3.4 一次请求的完整流转顺序结合前面几部分一个标准请求在 AgentConnect 里的流转顺序是这样的客户端发起请求带上 OAuth Token 或企业身份凭证。网关层解析 Token得到 user_id 和所属角色。网关根据请求里的 agent_id查出该 Agent 允许使用的工具列表。权限服务根据 user_id agent_id resource_scope action完成第一层校验。校验通过后请求进入共享调度队列等待 Agent 实例空闲。Agent 开始执行任务。每次调用工具前工具层再次读取权限上下文完成第二层校验。执行完成后返回结果给网关网关记录审计日志日志包含 user_id、agent_id、操作时间、动作、资源范围、结果状态。这个顺序很重要。如果第 4 步和第 6 步之间没有权限上下文传递或者工具层不认这个上下文那么前面做的所有鉴权都会被绕过。4. 单 Agent 跑通后再进入多 Agent 共享模式4.1 先跑单任务再开排队很多团队上来就想让多个 Agent 并行执行任务结果一跑就出现资源争抢、上下文串号、输出目录冲突。我的建议是先从单任务开始验证。单任务验证时一次只发一个请求不设置并发。观察三个指标Agent 是否能在预期时间内启动。工具调用是否都经过权限校验。日志里是否能完整还原这一次请求的所有步骤。这三项没问题再开第二个 Agent两个 Agent 同时执行任务。这时候重点看隔离性。如果两个 Agent 的执行日志在同一个目录下文件名冲突了或者权限校验读取的配置是同一个文件Agent 之间就会互相干扰。等到单任务、双任务都稳定了再考虑真正的排队和并发调度。不要跳到这一步之前就引入 Redis 队列和 Worker 多进程。4.2 并发数、超时、重试参数怎么定AgentConnect 在共享模式下最值得关注的参数有三个并发数、超时时间、重试次数。并发数不能盲目拉高。模型推理本身是资源密集型操作如果并发线程数超过机器 CPU 或 GPU 承载能力每个任务的速度都会下降甚至出现 OOM。一般先按 CPU 核心数的一半起步观察任务吞吐和响应时间。如果你的机器配置是 8 核 32G 内存可以先从 4 并发开始试再逐步往上加。如果每任务本身要跑 30 秒以上并发数反而可以小一点重点是避免互相拖慢。超时时间要分两层设置。层级建议值说明网关请求超时60 秒防止用户请求一直挂着Agent 单步工具调用超时15 到 30 秒防止某个外部接口卡住整个任务整体任务超时300 秒或更长长文档、多工具任务需要更大值重试次数不要默认给很大。权限相关的失败请求重试也没有用反而会重复调用外部接口。只有网络超时、连接中断这类瞬时错误才值得重试重试次数控制在 2 到 3 次。重试时最好带上任务 ID避免同一个任务被重复处理两遍。4.3 资源隔离目录、临时文件、环境变量共享模式里最容易漏掉的是文件路径隔离。多个 Agent 共用同一台机器时如果临时文件都写在/tmp/并且文件名只按 agent_id 区分可能还勉强能对齐。更稳妥的做法是每个任务一个独立目录目录名用 trace_id。/data/agent-runtime/trace-20250101-123456/ input/ output/ logs/这样一个任务结束之后整个目录可以归档或清理不会残留中间文件给下一个任务。权限校验时也只允许 Agent 访问当前 trace_id 对应的目录不把上一任务的输出目录暴露给它。环境变量同样要注意隔离。不同 Agent 可能需要不同模型配置、不同数据库连接串。如果环境变量是全局的两个 Agent 就会互相覆盖配置。可以用进程级环境变量隔离或者把配置存在配置中心按 agent_id 动态加载。不要在代码里写死读取同一个.env文件这个问题在测试时很难发现上线后却非常致命。5. 权限隔离最容易被忽略的四个地方5.1 缓存导致越权权限校验如果做了缓存比如把某个 user_id 对某个 agent_id 的校验结果缓存 10 分钟那么在这 10 分钟内即使管理员把该用户权限撤销了用户仍然可以继续调用 Agent 执行任务。这在生产环境里是严重隐患。解决方案缓存权限策略时只缓存策略本身不缓存“校验通过”的结果。策略变化频率低可以缓存但每个请求的用户身份、资源范围、动作是否匹配必须实时算。尤其是涉及敏感操作时连策略缓存也不要开太长或者直接不缓存。5.2 错误信息泄漏权限细节另一个常见问题是在返回错误时把策略详情带出去了。比如“当前用户没有 data/invoices/ 目录的 read 权限”这条信息对于攻击者来说恰好暴露了系统里存在一个 invoices 目录而且该目录是敏感目录。更安全的方式是统一返回通用错误“当前请求被拒绝请检查权限配置。”内部日志里再记录详细原因。对管理员来说日志已经足够定位问题不需要把权限细节暴露给普通用户。5.3 会话和上下文串号共享 Agent 模式下如果同一个 Agent 实例是复用的很容易出现上下文串号。比如 Agent 在处理用户 A 的任务时内部状态里还残留用户 B 的上一次结果导致后续输出掺杂了其他任务的数据。这个问题的根源是 Agent 执行器没有做到状态隔离。在做 AgentConnect 时我建议把每一个请求封装成一个独立 Execution Context里面存放的是当前请求的 payload、权限上下文、工具调用进度、输出目录。不要让 Agent 实例持有跨请求的全局状态。一个 Agent 实例可以被复用来处理多个请求但它内部的上下文对象必须每次请求重新创建。5.4 权限撤销不等于删除 Token很多系统在实现权限撤销时只把用户的 Token 删掉。但问题是Token 可能已经被某个 Agent 持有或者已经在执行中的任务里被使用了。仅仅删除 Token无法中断已经进入队列的任务。更好的做法是任务启动时记录权限快照并在真正执行工具调用时检查当前是否仍然有效。如果用户已经被禁用或者角色已经被移除即使任务还在队列里到执行阶段也要直接中止。安全设计里权限撤销应该是实时生效的而不是等旧任务全部执行完。6. 怎么验收“权限分开”是否真的达标6.1 构造正常通过和拒绝用例验收 AgentConnect 时不能只看正常请求能不能通过。一定要构造拒绝用例。至少准备下面这组测试测试场景预期结果普通用户访问自己资源通过普通用户访问他人资源拒绝普通用户尝试删除数据拒绝管理员删除数据通过但记录审计不同 Agent 之间互相访问资源拒绝没有 user_id 的匿名请求拒绝权限撤销后立刻发起新请求拒绝每一组测试都记录状态码、耗时、日志情况。通过用例不通过要查权限策略是否配置错误拒绝用例被放行就要立即定位是否权限校验链路被绕过。6.2 检查批量任务和长任务批量任务是权限隔离的高风险场景。比如一个用户上传了 100 个文件要求 Agent 批量处理。如果权限只在校验入口时做了一次后续 100 个文件都复用第一次的校验结果那么处理到第 50 个文件时用户权限被撤销后 50 个文件仍然被处理这就是越权。正确的做法是每个文件、每个动作都独立校验或者至少批量任务开始时检查一次循环到关键动作时再检查一次。测试时可以先用权限有效的用户发起批量任务任务执行到中间时撤销权限看后续任务是否被及时终止。长任务同理。一个任务如果跑 10 分钟第 8 分钟权限发生变化系统应该在下一个工具调用时感知到而不是继续执行到底。6.3 上线后监控哪些指标AgentConnect 上线后需要关注的指标不只有成功率。鉴权拒绝率这个值突然升高可能是权限配置改坏了也可能是有人在尝试越权。平均鉴权耗时每次请求增加一次权限判断理论上会带来几毫秒延迟。如果鉴权耗时超过 50 毫秒要检查权限服务是否变成了瓶颈。取消和重试率权限撤销后执行中的任务有没有及时中止。审计日志完整性每个敏感操作是否都有 user_id、agent_id、resource_scope、action、result。资源使用率共享调度层和 Agent 执行层的 CPU、内存、连接数等。我个人的习惯是先盯一个周。如果每天都能完整回放任意一条任务的权限链路说明 AgentConnect 的共享和隔离设计已经达到了可以长期使用的稳定状态。AgentConnect 这个名字本身只是一个入口真正决定它好不好用的是把共享调度层、独立权限层、审计层三段关系理清楚。先把单代理跑稳再把权限模型收紧最后才放开批量并发。这个顺序踩不了坑。