阿里云 AgentTeams 解析：当 Agent 开始真正在企业里干活

阿里云AgentTeams重新定义企业级多Agent协作，从“一次任务”升级为“长期组织化运营”，让AI真正融入企业日常。核心内容：1. 企业级Agent协作与临时任务协作的本质差异2. AgentTeams四层架构与零信任安全设计3. 四大核心能力与未来应用场景展望

作者：付宇轩(计缘)、邵丹(营火)

过去这段时间，多 Agent 协作成了 AI 领域最热的方向之一。Anthropic 放出了 Claude Code Agent Teams，开源社区里 CrewAI、AutoGen、LangGraph 也打得火热。但我们在做 AgentTeams 的过程中越来越强烈地感受到，大家聊「多 Agent 协作」的时候，聊的其实不是同一个东西。

大多数方案解决的是「一次任务怎么并行跑快」。我们想解决的是「一个 Agent 组织怎么长期运转」。这两个命题的差距，就像临时组个局打羽毛球和运营一个几百号人的羽毛球俱乐部之间的区别。

AgentTeams 瞄准的就是后面这个命题。先看一张全景图。

我们的落地架构从上到下四层。

• 最上面是入口层，支持原生 AgentTeams 客户端、钉钉飞书企业微信等 IM 集成、以及自研 Web 端的 HTTP 服务化接入。我们的理念是不逼员工换工具，让 Agent 出现在他们本来就在用的地方。

• 第二层是 Agent Identity，把企业已有的 IdP 和 SSO 用户体系接进来，为 Agent 工作负载签发身份，把用户身份透传到 Agent，每一步操作都可归属到人。

• 第三层是 Agent Team 组织本身，按职能编成研发团队、客服团队、数据分析团队、运营团队等等，每个团队由 TL Agent 调度，底层引擎热插拔可替换。

• 最底层是统一 AI 资产管理，模型、Skill、MCP Server、Worker Agent 模板集中管理，BYOC（Bring Your Own Cloud）保证企业对自己的 AI 资产自主可控。

右侧贯穿四层的是一整套观测、度量、治理中台，从 Token 消耗到 Prompt 分析到效果审计，全程可观测。

Agent 不是散装的脚本，而是一种需要被管理、被治理、被观测的企业级工作负载。

下面展开聊聊我们在四个核心方向上的架构思考和取舍。

核心能力设计

Cloud Native

先聊安全，因为这是我们设计时花了最多精力、也是跟市面上大多数多 Agent 框架差异最大的地方。

坦率的讲，安全问题是目前整个多 Agent 领域最被低估的风险。大家都在卷能力、卷效果、卷 benchmark，很少有人认真讨论，当你的 Agent 开始真正在企业里干活的时候，它手里攥着一堆 API Key 和数据库凭证，这些事情有多危险。

我们的答案是四道防线，从身份、运行时、通信一直管到 AI 资产，构建一套「零信任」的 Agent 管理底座。

第一道是 AI 网关，核心思路是让 Agent 零凭证持有。传统做法里每个 Agent 手里都攥着一堆密钥，我们的做法是把所有 LLM 调用和外部密钥统一收到网关里加密托管，Agent 本身不持有任何凭证。在此基础上叠加细粒度风控，通过 Agent 身份认证加上 Skill 和 MCP 的指令级拦截，把风险挡在调用发生之前。

这个设计思路在安全领域叫零信任，Zero Trust。过去几年零信任在人类用户的身份和访问管理领域已经是标准实践了，我们做的事情是把它应用到 Agent 身上。在 Agent Identity 这一层，我们对接了钉钉、飞书、企业微信、RAM、Entra ID、Okta 等企业 IdP，为 Agent 工作负载签发身份，出站凭证全部托管（STS、OAuth、API Key），Agent 零明文持有。AgentTeams 会拦截每一次工具和 MCP 调用，按策略评估放行，杜绝越权。

这里多说一句为什么我们觉得这个这么重要。你想想看，一个被注入攻击的 Agent 如果手里有数据库写权限和你的 API Key，它能干的事情跟一个被攻陷的管理员账号没有区别。区别只是，管理员是人，你知道该找谁问责。Agent 被攻陷了，你连爆炸半径有多大都不知道。

第二道是 Sandbox 沙箱，做运行时隔离。每个 Agent 跑在独立的沙箱里，实例、网络、存储三个维度物理隔离。即便某个 Agent 遭遇越权操作或提示注入攻击，破坏也会被锁死在单个沙箱内，不会波及企业内网。这个后面会专门展开。

第三道是通信安全。Agent 之间的所有通信基于端到端加密的协议传输，任务派发、上下文与数据流转全程加密，同时通过 Room 机制保证信息透明、审计可溯源。协同过程既保密又可追查。

第四道是 Skill 市场，做 AI 资产的供应链安全。所有 Skill 和 MCP 能力必须通过安全扫描审核才能注册上架，从源头杜绝恶意能力混入。调用环节通过网关的 per-consumer ACL 做按需授权，最小权限原则。再加上 Skill 分组管理，实现分组间隔离和统一分发。

四道防线层层递进，身份可信、运行可控、通信可靠、资产可查。

我们在做这个安全架构的时候，内心有一个很强烈的感受。太多人把 Agent 当成一个「更聪明的脚本」来对待。但当你真正开始在生产环境里跑多 Agent 系统的时候，你会发现安全不是锦上添花的事情，是生死线。

这也是为什么我们把安全提到了产品架构的第一优先级。

聊完安全，聊协作架构。这是 AgentTeams 的骨架。

我们定义了一个三层结构，Manager Agent 在最上面做全局监管和任务拆解，Team Leader Agent 负责具体团队的调度和分配，Worker Agent 在最底层执行任务。这个结构比 Claude Managed Agents（以下简称 CMA）的两层（Lead 加 Teammates）多了一层 TL。

这一层不是白加的。

你想想真实公司里的组织结构。CEO 不可能直接管五十个人，他管的是几个 VP，VP 再管 Team Lead，Team Lead 再带一线员工。这个层级结构是人类组织在几千年实践中沉淀出来的最优解，它解决的是管理幅度的问题。一个人（或 Agent）能有效管理的直接下属是有限的，超过某个阈值就需要分层。

我们把组织管理学的这个常识搬进了 Agent 系统。而且 TL 这一层是动态的，你可以按团队按需设立，不需要的场景也可以跳过。

还有一点跟 CMA 不太一样。CMA 里的 Lead 是固定的主会话，不可转移，也不可以把 Teammate 提升为 Lead。我们的 Manager 和 TL 都是独立的 Agent 实例，可以灵活调整。这个灵活性在真实企业场景里很重要，因为你不可能每次都从头搭一套团队结构。

在团队管理层面，我们设计了真人成员和 Agent 成员混合的组织模型。团队群里 Admin 管理团队、TL 编排任务、Worker 执行任务，真人可以随时介入打断、实时纠偏。交互模式上既有团队群聊的协作编排，也有一对一私聊的专项沟通，权限严格隔离在团队范围内。

这里多说一句我们的理解。类 CMA 模式的主 Agent 加 Subagent，其实对应的是 AgentTeams 里 Worker Agent 进程内的 Subagent 链。我们把这个定义为「延迟敏感的连贯流程收进单 Worker 内的 Subagent 链」，和 Anthropic 对 Subagent 的定位是同一个维度的能力。而 CMA 的 Agent Teams 那一层，对应的是我们的 TL 加 Worker。

简单来说，CMA 解决的是「一次任务怎么并行」，我们解决的是「一个组织怎么长期运转」。这两个东西不矛盾，是不同层次的抽象。

协作架构还有一个重要的设计决策，引擎热插拔。

现在市面上的多 Agent 方案，几乎都有一个共同的毛病，跟特定模型或框架深度绑定。CMA 只能用 Claude 系模型，CrewAI 和 LangGraph 绑定了各自的框架抽象，你想换一个底层 Agent 引擎，基本等于推倒重来。

我们不想走这条路。因为我们有一个很明确的判断，Agent 引擎这个东西，在可预见的未来一定会快速迭代和分化。今天最好的 Agent 引擎，半年后可能被更好的替代。如果你的平台跟某一个引擎深度绑定，那每次引擎更新你都得跟着大改。

所以我们在协议层做了解耦，底层引擎可以混编。同一个 Team 里面，Worker A 可以跑我们自己的 QwenPaw，Worker B 纳管 OpenClaw，Worker C 纳管 Claude Code，Worker D 是客户自己写的 Agent。把协作层和引擎层切开，企业就不会被单一技术栈锁死。这个选择短期内看不到好处，长期来看可能是生死攸关的架构决策。

Kubernetes 当年做了一个类似的决策，通过 CRI 把编排层和容器运行时解耦。当时很多人不理解，觉得 Docker 不就够了吗？结果后来 containerd、CRI-O 等替代运行时冒出来，证明了那个解耦的价值。我们在 Agent 领域做了同样的事情。

说到 Kubernetes，我们的产品设计里有一个很核心的范式映射。Kubernetes 的 Pod 是最小工作单元，我们的 Worker 是数字员工。Kubernetes 的 Deployment 管理期望状态，我们的 Team 管理数字团队。Kubernetes 的 Ingress 和 Gateway 是流量入口，我们的 AI Gateway 是安全大闸。甚至 Kubernetes 的 kubectl apply 声明式管理，我们也搞了一个 agentteams apply 的团队声明。

Kubernetes 之所以能赢，不是因为它做了什么惊天动地的创新，而是因为它用声明式、Reconcile、CRD 这套理念，把容器编排从一个「写脚本」的活儿变成了一个「声明意图」的活儿。我们想在 Agent 领域做的事情一模一样。你不是在写一套脚本来编排 Agent 的行为，而是在声明「我要一个研发团队，有一个 TL，五个 Worker，用 QwenPaw 引擎，挂载这些 Skill 和 MCP」，然后平台帮你 Reconcile 到期望状态。

当然这个类比也有它的边界，我们自己也很清楚。容器是确定性的，Agent 是概率性的。所以我们在 Kubernetes 范式之上还加了 Heartbeat 监控、阻塞上报、Human-in-the-Loop 介入、全链路可观测，这些都是为了应对 Agent 的概率性本质。但核心思路不变，把 Agent 当成一种新的工作负载来管理，用基础设施的思路而不是脚本的思路来对待它。

在 Agent 引擎的选择上，目前我们托管 QwenPaw，纳管 OpenClaw 和 Claude Code，后续会支持更多 Agent 和 CLI。协议级解耦让「混编团队」成为可能，不同底层引擎在同一协作底座内无缝沟通、共享上下文。

第三个核心方向是 Sandbox 沙箱运行时。这块解决的是 Agent 真正跑起来之后「安不安全、扛不扛得住、贵不贵」的问题。

我们集成了 ACS Sandbox，把安全隔离、弹性伸缩、按需计费三件事一次性做到位。整套运行时的调度核心是 Session 亲和路由，遵循「单 Session 单 Sandbox」原则。每一个会话都被稳定地路由到属于自己的独立沙箱里，资源、网络、存储三维隔离，彼此互不串扰。

安全隔离这块前面已经提过，再强调一下。每个 Agent 的运行环境在资源、网络、存储三个层面做物理隔离，跟四道防线里 Sandbox 收敛爆炸半径的思路一脉相承。这个不是可选项，是企业级的硬门槛。

弹性伸缩这块，我们设计了三种方式。

• 第一种是 Session 级扩并发。五个人同时跟同一个 Worker Agent 交互，就会拉起五个独立的 Sandbox 并行接请求。并发随 Session 数线性扩展，会话间天然隔离。当某个会话流量上行、负载升高时，系统会秒级新建拉起对应的 Sandbox。

• 第二种是 Team 级多副本分流。创建多个相同的 Team 副本，以副本为单位分流请求，像多实例负载均衡一样横向扩并发。

• 第三种比较巧妙，是用 Subagent 同进程编排来压时延。一个 Worker Agent 内部可以内建多个 Subagent，各自有独立的 SOUL.md 和 Skill 配置，但跑在同一个进程里，Agent 之间的协作不需要网络通信，零跳数，端到端时延压到最低。这个设计我是真的觉得挺见功力的，它把编排粒度的选择权交给了业务场景本身，而不是一刀切。

举一个实际的例子。售后退款这个业务功能，对应一个 Worker Agent，内部的退款受理、订单核验、责任判定、规则计算、风控校验、退款执行、通知归档七个步骤，分别由七个 Subagent 在同一进程内串行完成，端到端零网络跳数。只有跨功能协作（比如退款完成后要通知财务结算那个 Worker Agent）才走跨进程调用。

按业务时延敏感度选择编排粒度，这是我们反复推敲后确定的分层原则。

成本这块，我们做了深休眠机制。无请求时 Sandbox 进入深休眠状态，只以快照形式保留现场，不产生费用。一旦有请求，秒级从快照拉起整个 Sandbox，恢复现场。对企业来说，其实就是不用再为空闲的 Agent 会话持续付费，算力真正做到了「用多少、付多少」。

存储方面也有灵活性。Worker Agent 的 Sandbox 既可以使用每个沙箱专属的独享存储，也可以按需挂载 OSS、NAS 这类跨 Sandbox 的共享存储，兼顾隔离与数据共享两种诉求。

概括来讲，我觉得我们基于 ACS Sandbox 把「安全的 Agent 运行环境」和「经济的资源模型」合二为一了。隔离保证安全，HPA 保证弹性，深休眠保证成本可控。三者叠加，是一个既稳又省的弹性沙箱运行时。

第四个核心方向，Agent 持续进化。这块可能是 AgentTeams 最有长期想象力的部分。

我们跟 AgentLoop 调优引擎做了集成，形成了一个双飞轮结构。左飞轮是 AgentTeams 的多 Agent 协作底座，在真实业务运转过程中自然沉淀执行轨迹、工具调用日志、数字员工之间的协作记录、成功和失败案例。右飞轮是 AgentLoop，接过这些数据做清洗、自动评估、SFT 和 RLHF 训练，再把成果反哺回去，体现为 Prompt 优化、模型更新、技能库优化和组织结构优化。

核心链路是三个动作。发现，监控高频失败的 Task，沉淀 Bad Case。对齐，结合人类偏好数据，构建企业专属的 DPO 和 RLHF 训练集。进化，自动重构 Prompt，持续提升效果。

说实话，这个飞轮在现阶段还比较偏理想化。要真正转起来，需要足够多的真实业务数据、成熟的评估体系和持续的工程投入。但我们坚信这个方向，Agent 系统不应该是一个静态的工具，而应该是一个能够从使用中学习、持续进化的系统。

而且这里有一个很现实的壁垒。你想想看，随着飞轮转动，Agent Team 会越来越懂企业自己的 SOP 和业务流程，这种积累是别家搬不走的。你用通用模型和通用 Prompt 搭的 Agent 系统，跟人家跑了半年飞轮、沉淀了几千条 Bad Case 和 RLHF 数据训练出来的 Agent 系统，效果差距会越来越大。

这可能才是 Agent 时代真正的护城河。不是你用了哪个模型、哪个框架，而是你积累了多少属于自己业务的 Agent 协作数据。

最后聊聊我们自己在这个过程中的一些思考。

一些思考

Cloud Native

做 AgentTeams 的这段时间，我们最大的一个认知转变是，Agent 不是工具，是员工。

这话听着有点大，但确实是我们的真实感受。当你认真去做一个多 Agent 系统的时候，你会发现你面对的问题跟企业管理出奇地相似。需要身份认证、需要权限管理、需要通信加密、需要弹性资源、需要可观测性、需要持续学习和进化。这些事情，企业 IT 在过去几十年里已经为人类员工做过一遍了。我们现在做的事情，就是为 Agent 再做一遍。

AgentTeams 还远不是终态，有很多需要继续打磨的地方。但至少我们相信，这个方向是对的。

登录查看剩余 70% 内容