作者付宇轩(计缘)、邵丹(营火)过去这段时间多 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 模板集中管理BYOCBring Your Own Cloud保证企业对自己的 AI 资产自主可控。右侧贯穿四层的是一整套观测、度量、治理中台从 Token 消耗到 Prompt 分析到效果审计全程可观测。Agent 不是散装的脚本而是一种需要被管理、被治理、被观测的企业级工作负载。下面展开聊聊我们在四个核心方向上的架构思考和取舍。核心能力设计先聊安全因为这是我们设计时花了最多精力、也是跟市面上大多数多 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 KeyAgent 零明文持有。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 不可能直接管五十个人他管的是几个 VPVP 再管 Team LeadTeam 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 可以跑我们自己的 QwenPawWorker B 纳管 OpenClawWorker C 纳管 Claude CodeWorker 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 协作数据。最后聊聊我们自己在这个过程中的一些思考。一些思考做 AgentTeams 的这段时间我们最大的一个认知转变是Agent 不是工具是员工。这话听着有点大但确实是我们的真实感受。当你认真去做一个多 Agent 系统的时候你会发现你面对的问题跟企业管理出奇地相似。需要身份认证、需要权限管理、需要通信加密、需要弹性资源、需要可观测性、需要持续学习和进化。这些事情企业 IT 在过去几十年里已经为人类员工做过一遍了。我们现在做的事情就是为 Agent 再做一遍。AgentTeams 还远不是终态有很多需要继续打磨的地方。但至少我们相信这个方向是对的。