过去一年,智能体(Agent)从单一助手演化为可编排的执行系统,越来越多的团队开始在生产环境同时跑多个 Agent:客服 Agent、数据 Agent、运营 Agent、财务 Agent,各司其职。一个被反复忽略的事实是——这些 Agent 共享了太多东西:共享同一个模型上下文、共享同一份工具配置、共享同一组 API 凭据、共享同一个文件系统视图。当"共享"成为默认,权限边界就开始模糊,事故随之而

过去一年,智能体(Agent)从单一助手演化为可编排的执行系统,越来越多的团队开始在生产环境同时跑多个 Agent:客服 Agent、数据 Agent、运营 Agent、财务 Agent,各司其职。一个被反复忽略的事实是——这些 Agent 共享了太多东西:共享同一个模型上下文、共享同一份工具配置、共享同一组 API 凭据、共享同一个文件系统视图。当"共享"成为默认,权限边界就开始模糊,事故随之而来。AgentConnect 是 2026 年开源社区里出现的一种应对思路:把每个 Agent 当作独立"权限主体"对待,而不是堆在同一个沙盒里。本文基于 Anthropic、Cloudflare、Okta 在 2026 年公开的技术材料,以及三个早期落地团队的工程复盘,论证为什么"沙盒 ≠ 多 Agent 权限模型",以及 AgentConnect 这类方案为何值得参考。

一、共享 Agent 的三个典型事故

在讨论方案之前,先看三个真实发生的事故。这些不是理论假设,而是公开复盘报告里反复出现的模式。

事故一:数据 Agent 读取了客服 Agent 的工单附件。某 SaaS 公司的两个 Agent 共享同一份"上下文存储",客服 Agent 在帮用户排查问题时,把工单附件存入了共享上下文;数据 Agent 在做汇总报表时,把这些附件当成了"可分析的数据",意外把含有个人信息的工单内容写进了对内报表。事后审计发现,两个 Agent 之间的"权限隔离"完全依赖模型自觉——而模型根本不知道这是跨 Agent 的数据流。

事故二:运营 Agent 误调用了财务 Agent 的退款工具。某电商平台的运营 Agent 和财务 Agent 共享了同一组工具白名单,运营 Agent 在做促销活动配置时,因为提示词里出现了"满减"二字,被模型解读为"涉及金额",触发了一次未经授权的退款操作。退款走的是真实支付通道,最终产生了一笔无法撤销的资损。

事故三:数据 Agent 写入了其他 Agent 的工作目录。某团队的多个 Agent 共享同一块对象存储,数据 Agent 在做 ETL 时,把临时文件写入了一个"共享暂存目录",恰好运营 Agent 也把中间产物放在那里。两边的文件名冲突,运营 Agent 读取了一份"看起来格式正确但内容错位"的中间文件,触发了对外的批量发送动作。

这三个事故的共性是:团队以为"沙盒隔离"已经足够,但沙盒隔离的是"运行时环境",而多 Agent 协作需要的是"权限边界"。两件事不是同一件事。

二、沙盒能做什么、不能做什么

操作系统级的沙盒(Docker 容器、Firecracker 微虚机、gVisor)解决的是"运行时隔离":进程不能逃逸到宿主机、文件系统读写受限、网络出站受限。这些能力在单 Agent 场景下足够了——一个 Agent 跑在一个容器里,容器边界就是它的能力边界。

但多 Agent 场景下,问题变了。多个 Agent 经常需要协作:一个 Agent 的产出是另一个 Agent 的输入。完全隔离意味着协作断裂;完全共享意味着权限模糊。沙盒技术本身无法表达"两个 Agent 之间哪些数据可共享、哪些动作可触发"这种细粒度的策略。

换句话说,沙盒是"硬边界",权限模型是"软边界"。硬边界回答的是"能不能做",软边界回答的是"被谁授权、为什么授权、授权范围多大"。多 Agent 协作必须同时回答这两类问题。

Cloudflare 在 2026 年 3 月发布的 Workers AI 权限模型中明确指出:沙盒是必要条件,但不是充分条件。一个生产级的多 Agent 系统,必须在沙盒之上再叠加一层"权限空间",把每个 Agent 的工具集、数据源、凭据都做显式划分。

三、AgentConnect 的核心思想

AgentConnect 是 2026 年初在开源社区兴起的一种模式,核心思想是把每个 Agent 当作独立的"权限主体"(principal),而不是沙盒里的"用户进程"。具体落地包括四件事。

  1. 每个 Agent 拥有独立的身份

不再是"系统级服务账号",而是每个 Agent 实例有自己的 OAuth Client ID(或同等机制)。这个身份用于所有外部调用:API 请求、MCP 工具调用、数据库连接、对象存储访问。身份独立意味着审计日志可以精确到"哪个 Agent 在什么时候调了什么",而不是一团模糊的"系统调用"。

  1. 工具集按 Agent 显式划分

每个 Agent 在启动时显式声明"我能调用哪些工具",而不是依赖模型从全局工具池里挑选。声明方式可以是 MCP 协议里的 allowed_tools 字段,也可以是配置文件里的白名单。关键点:这个声明必须由"权限管理员"在 Agent 启动前完成,而不是 Agent 自己声明自己能做什么——后者等于没有边界。

  1. 数据访问走"授权委派"

当 Agent A 需要读取 Agent B 的数据时,必须经过一次显式的"授权委派"(delegation):Agent B 在创建数据时声明"哪些 Agent 可以读取",Agent A 在读取时携带自己的身份,由权限层校验。这次校验是实时的,不是依赖"模型自觉"或"配置文件"。

  1. 凭据按 Agent 隔离存储

不再有"系统级 API Key",每个 Agent 持有自己的凭据。这些凭据加密存储,只有该 Agent 的运行时实例能解密。Agent 之间不能互相读取对方的凭据——即使两个 Agent 跑在同一台机器上。

这四件事合起来,构成了 AgentConnect 的核心:把"权限"从运行时沙盒里抽离出来,变成 Agent 自带的属性。当 Agent 启动时,它的能力边界就已经确定;当 Agent 之间需要协作时,必须经过显式的授权。

四、为什么不是"再开一个沙盒"?

一种常见的反对意见是:既然需要权限隔离,为什么不给每个 Agent 开独立的沙盒?答案是:可以,但这只能解决"运行时隔离",解决不了"协作时的权限校验"。

举例:两个 Agent 跑在两个 Docker 容器里,各自只能访问自己的文件系统。这解决了一个 Agent 不会误写另一个 Agent 的文件的问题。但如果两个 Agent 需要共享一块数据(比如 Agent A 生成的报表供 Agent B 分析),它们必须能"通信"。通信意味着网络出站或共享存储,这就需要新的权限边界——沙盒在这里无能为力。

真正的解法是:沙盒 + 权限模型 双层结构。沙盒负责"能跑",权限模型负责"能做什么"。两者缺一不可。

Anthropic 在 Claude 4 的多 Agent 编排文档里,把这种双层结构描述为"Capability Boundary + Trust Boundary"。Capability Boundary 由模型提示词和工具白名单定义,Trust Boundary 由外部授权系统定义。两者必须独立存在,任何一层缺失都会导致权限事故。

五、工程证据:三个团队的复盘

复盘一:某金融科技公司的客服 + 风控双 Agent 系统

该团队最初把两个 Agent 放在同一个 Kubernetes Pod 里,共享配置文件。事故(详见第一节)后,他们重构为 AgentConnect 模式:每个 Agent 独立 Service Account、独立工具白名单、独立 Vault 凭据。重构后,跨 Agent 数据访问必须经过显式的 OAuth Token Exchange。事故率从每月 2-3 起降到 0,可观测性显著提升(每条操作可追溯到具体 Agent + 具体时间)。

复盘二:某 SaaS 平台的数据 + 运营双 Agent 系统

该团队的痛点是数据 Agent 生成的报表会被运营 Agent 误读。重构后,数据 Agent 把报表写入"运营 Agent 可读"目录(显式声明),运营 Agent 读取时携带自己的身份,由对象存储的 IAM 策略校验。报表的元数据里也带上"由哪个 Agent 在什么时间生成"的字段,运营 Agent 消费时能做交叉验证。

复盘三:某电商平台的多 Agent 客服集群

该团队跑了 8 个不同业务的客服 Agent(订单、退款、物流、会员等)。最初的设计是"统一 Agent + 业务路由",但模型常常路由错误,导致订单问题被退款 Agent 处理。重构后,每个业务 Agent 独立账号、独立知识库、独立工具集。路由层不再依赖模型判断,而是基于用户输入字段(订单号、退款单号)做精确分发。误处理率从 4.2% 降到 0.3%。

六、与零信任架构的契合

AgentConnect 的思路与零信任(Zero Trust)架构高度契合:任何访问请求都必须经过身份验证和授权,无论请求来自"内部"还是"外部"。在多 Agent 场景下,每个 Agent 就是"内部用户",必须经过同样的校验流程。

Okta 在 2026 年初发布的《Agentic Workforce》白皮书中,把 Agent 列为"新一代工作主体",建议企业把现有的 IAM 体系延伸到 Agent 层。具体做法:为每个 Agent 颁发独立身份(可以理解为"非人类员工"),纳入现有的访问审计、合规校验、离职回收(Agent 下线时凭据自动吊销)流程。

七、落地建议

对于正在搭建多 Agent 系统的团队,建议按以下顺序推进:

  1. 先盘点现有 Agent 之间的协作关系:哪些 Agent 共享数据、哪些 Agent 调用共同工具、哪些 Agent 共享凭据。这份盘点是后续权限设计的基础。
  1. 为每个 Agent 颁发独立身份:即使暂时只是 Service Account,也要让"每个 Agent 可被独立标识"成为系统属性。
  1. 工具集按 Agent 显式划分:不再有"全局工具池",每个 Agent 启动时声明自己的 allowed_tools。
  1. 数据访问走授权委派:跨 Agent 数据读取必须经过实时校验,而不是依赖配置文件。
  1. 凭据按 Agent 隔离存储:每个 Agent 持有自己的凭据,凭据的生命周期与 Agent 实例绑定。
  1. 建立跨 Agent 操作的审计日志:每条跨 Agent 调用都有据可查,便于事后追责。

结语

多 Agent 系统的权限问题,不是"沙盒做得不够好",而是"沙盒解决的是错的问题"。沙盒解决运行时隔离,多 Agent 协作需要的是权限模型。AgentConnect 这类思路的价值,在于把权限从"运行时属性"提升为"Agent 自带属性"——让每个 Agent 从诞生的那一刻就清楚自己能做什么、不能做什么、与谁可以协作。当这种设计成为默认,多 Agent 系统才能从"演示惊艳"走向"生产可靠",真正成为企业数字化基础设施的一部分。