AgentTeams 和 Claude Tag 都进入群聊模式，是新范式还是新叙事？

作者望宸我们在今年的 520 阿里云云峰会上发布了 AgentTeams定位的是企业级多智能体治理与协作平台支持企业统一创建、调度 Agent每个 Agent 可以自定义模型在钉钉、企微、飞书等 IM 平台创建群聊进行团队协作。Anthropic 近日发布了 Claude Tag把 Claude 直接作为团队成员嵌入 Slack 频道。在 ambient 模式下Claude 不需要被显式 也会主动监听上下文、跟进任务、提醒进展依托 Opus 4.8 实现跨小时级的异步协作。企业办公场景从一对一私聊到多对多群聊大家不禁要问这会是使用 Agent 的新范式么我们不着急给出判断选择范式之前读者们更多的还是想了解下单聊和群聊有哪些不同一、什么是群聊模式Anthropic 在 Claude Tag 的博客里定义了 Agent 群聊的四个特征Claude is multiplayer在一个 Slack 频道里Claude 是同一个实例与所有人协同工作而不是每个人各自开一个独立会话。Claude learns over time它持续跟随频道活动积累上下文不需要每次重新解释项目背景。Claude takes initiative开启 ambient 模式后它无须被 也会主动监听、标注相关信息、跟进沉默的任务。Claude works asynchronously它可以接收一个跨小时甚至跨天的任务自主规划执行节奏类似一个远程同事。因此群聊 ≠ 多人各自和 Bot 聊天的并集。如果群内每个人开自己的会话就只是并行的单聊了。阿里云 AgentTeams 给出的则是一个更工程化的定义。把群聊抽象为一组声明式 CRD每个 Agent、每个真人都会赋予一层身份成员身份Manager人类成员平台级管理员Team LeaderAgentN 个 Workers 的管理者WorkerAgent最小执行单元Human人类成员提供 L1 Admin / L2 Team Leader/ L3 Worker 的三级权限每个 Worker 都会携带若干声明文件SOUL.md、AGENT.md、MEMORY.md、USER.md。底层通信走 Matrix 协议通过 Element Web 接入钉钉、企微、飞书等主流 IM。群聊不是聊天形态的升级而是组织建模的开始。Slack 里的 Claude 是 Anthropic 把 Slack 当作 UI把 Slack 的 thread、channel、DM 当作天然的对话拓扑结构来复用AgentTeams 则是把群聊当作一种可被声明、可被调度、可被审计、可被复制的组织资源。总结来看Agent 群聊模式 多个人类成员 × 多个 Agent × 共享上下文 × 异步任务 × 显式身份权重的协作平面。二、什么情况下需要引入群聊不是所有 Agent 场景都需要群聊。如果只是写一段代码、查一份资料、生成一张图单聊是更直接、更低成本的选择。引入群聊的代价是显著的无论是用户的使用习惯还是背后的 Agent Infra包括技术架构、上下文管理、权限治理、并发调度、成本归因每一项的复杂度都会迅速拉高。那什么情况下需要引入群聊我们可以基于没有 Agent 的情况下进行推演即什么时候我需要从单聊切换到参与某个群聊中。场景一跨领域协作和长链路工作流跨领域协作需要多智能体本质原因是 Agent 的上下文和记忆等是有限的和人一样一个 Agent 塞太多职责注意力一分散每件事都做不好。跨领域是注意力在空间上的分散长链路则是注意力在时间上的衰减。比如从需求到发布的软件研发流程跑几小时甚至几天上下文越积越长Agent 对早期信息的注意力不断被稀释推理质量持续下降。当长链路叠加跨领域需求分析、编码、测试本身就是不同领域的工作等于空间和时间的双重挑战。拆成多个 Agent 按阶段接力每段上下文干净、注意力集中中间状态可持久化断了能从断点续跑更健壮并且要发生在所有人都能看到、都能介入、都能纠偏的频道里。阿里云 AgentLoop 的端到端 Coding 流水线就是基于 AgentTeams 群聊模式实现的。AgentTeams 中的 TeamLeader 负责调度与状态5 个 Worker 分别纳管本地 Agent包括需求分类、Coding、Test、Review 和 Verify。需求分类中按复杂度定义为 T1-T5 5档lint fix 由 Agent 链路端到端自动化处理bug fix 由人来审核 PR架构设计类的需求Agent 辅助。通过 AgentTeams 造 AgentLoop 的详细实践AgentLoop 研发工程师马云雷后续将展开分享场景二多智能体治理前两个是 Agent 注意力的限制第三个是信任边界的要求。多个团队的人和 Agent 在一起协作谁的 Agent 做了什么、花了多少钱、能访问哪些数据必须有清晰的边界。单 Agent 没法代表多个组织身份必须拆成多个独立的 Agents各自归属、各自授权、各自计费。AgentTeams 支持将所有 LLM Key、MCP 凭据、GitHub PAT、内部 API Key 全部托管在 Higress AI GatewayWorker 只持有可撤销的 Consumer Token。这些都是多智能体治理的刚性需求。场景三沉淀组织级知识单聊的上下文是用完即焚的用户关掉窗口记忆主要存在于用户自己和对话日志里。但群聊不一样新员工入群直接 它就能完成 onboarding这是组织级记忆资产不是个人助理能提供的。例如 AgentTeams 提供了独立的 AI Registry 注册中心统一管理 Skills、MCP Servers、Agents、Team Templates支持版本管理、安全审查、热加载。知识和对话被拆开前者是组织资产跨频道、跨 Team 复用后者是临时上下文绑定到具体频道。以上三种单聊都很难承载Anthropic 已经用 Claude Tag 跑通了产品团队 65% 的 PR阿里云 AgentLoop 使用 AgentTeams 实现端到端的 Coding 流水线。这意味着至少在研发场景里群聊模式带来的边际收益已经远超它带来的复杂性成本。三、群聊模式用户的使用习惯会有哪些变化不得不承认多 Agents 的群聊模式和普通的多人群聊行为上存在一些区别需要适应。身份分层单聊里 Agent 面对的是单一身份。群聊模式则需要平台管理者对成员的权限进行配置管理。Claude Tag 用 agent-identity 模型把频道身份作为权限主体无论谁在频道里 Claude工具调用权限边界由管理员预设的频道规则决定而不是触发者本人的权限。比如HR 频道里的敏感数据只有 HR 频道里的 Claude 能访问研发频道里的 Claude 拿不到。AgentTeams 则是设计了用户和 Agent 角色用户分为 Admin 和普通用户每个普通用户可以配置是否可以使用 TeamLeader Agent 和哪些 Workers 的权限Agent 则分为 TeamLeader 和普通 Workers每个 Worker 永远只持有可撤销凭据真实凭据由网关托管。上下文消歧单聊上下文是低熵的你说什么就是你说什么。群聊上下文是高熵的30 人 5 分钟发 80 条消息Agent 接到一句帮我看下这个它怎么判断哪个这个Claude Tag 的设计是不主动猜最大化利用 Slack 原生的 thread 模型。所有产出绑回原始 thread由 Slack 的数据结构而不是 Agent 的推理来消除歧义。AgentTeams 则是把消歧的责任拆给 TeamLeader Worker任务先在 Team 内部由 Leader 做意图识别和分解再下发给具体 Worker 执行。先内部协商再对外执行是一种组织级解法。用户因此要学会一个新的发言习惯重要任务从 thread 里发起不要从主频道里抛。否则上下文会被淹没在群聊噪音里。协作并发单聊是回合制你问、它答、你再问。群聊是流式多个用户同时 Agent 触发独立任务Agent 并行处理。AgentTeams 的并发模型是显式的每个 Worker 都是独立的容器实例由 hiclaw-controller reconcile类比 Pod 在 K8s 控制平面下的弹性调度。Team CRD 里 “1 个 TeamLeader N 个 Workers” 的结构本身就是并发的声明式表达。四、群聊模式对 Agent Infra 提出了哪些新的挑战前三节是从产品层、用户层讲的是群聊模式的不同这一节就是讲基础设施层。在 AgentTeams 的设计过程中我们会思考一个问题群聊模式对基础设施提出了哪些新的挑战总的来看单聊 Agent核心问题是调度怎么拆任务、怎么分配。但群聊模式核心挑战变成了治理谁有权限调用哪个 Agent成本算谁的出了问题谁负责因此群聊模式需要统一身份、RBAC 权限、成本归因、群体记忆等这些需求在企业团队场景下是刚需也更加复杂。身份与权限群聊里的权限主体不再是用户而是频道 / Team 这种集合实体。这件事 K8s 早就处理过ServiceAccount 是 Pod 的身份不是创建 Pod 的人的身份RoleBinding 绑定的是角色不是工号。AgentTeams 把这套模型搬到 Agent 群聊中并显式拆成两条正交的轴Worker 侧每个 Worker 拥有自己的 Consumer Token、自己的 MCP Servers 子集、自己的 Skills 子集能力边界在 AGENT.md 里声明运行时由 hiclaw-controller reconcile未声明的工具和未授权的频道Worker 是调不到的。Human 侧Human 显式分为三级L1 Admin 是组织管理员可创建/解散 Team、配置 Manager、托管主 Key。L2 Team 是 TeamLeader含 TeamAdmin 人类角色定义 Team 的 SOUL/AGENT/MEMORY/USER 四份声明文件、决定 Worker 编制与 Skills。L3 Worker日常发言者发起任务、 Worker、审阅产出两条轴正交但联动同一个 HR 同学在公司层是 L1 Admin在研发 Team 里可能只是 L3 Worker比如同一个 Worker 在 HR 频道里可以读敏感字段在研发频道里看不到。凭据治理Agent 单聊场景Agent 拿到的是用户的 OAuth token、API Key、MCP 授权。但在群聊模式中多人 同一个 Agent 时到底用谁的 token跨小时挂起的任务恢复执行时原始触发者的 session 早就过期了。AgentTeams 把这一层完全做到基础设施级实现细颗粒度的权限管控第一步【agent不碰真实凭据】所有凭据集中纳管在 Higress AI Gateway。LLM Key、MCP 凭据、GitHub PAT、内部业务 API Key 全部不下发给 WorkerWorker 只持有一个可撤销的 Consumer Token每次出向调用由网关代换为真实凭据。这相当于把 K8s 的 ServiceAccount RBAC 模型平移到 Agent 的出向流量层。Worker 容器即便被攻破攻击者拿到的也只是一个一次性临时凭据真实 Key 永远不出网关。第二步【主 Key 二次签发】真实凭据变成多把小权限的临时的凭据。一个 Team 持有一把主 API Key平台基于这把主 Key 派生出 N 把派生凭证分发给每个 Worker。派生凭证天然带租户/Team/Worker 三级标签一个 Worker 被攻击或被滥用影响范围被严格约束在它自己那把派生凭证内主 Key 与其他 Worker 完全不受影响。第三步【MCP 凭据按需下发、用完即焚】Worker 调用某个 MCP Server 时对应的 MCP 凭据是任务粒度下发、执行完即销毁、不可转发、不可持久化。群体记忆群聊里的记忆问题比单聊复杂一个数量级。不是简单地加一个向量库我们至少要回答四个问题短期对话怎么不爆 token长期事实怎么沉淀过期信息怎么显式遗忘组织知识怎么不污染个人记忆AgentTeams 提供了开源实现和 QwenPaw 同属 AgentScope是 QwenPaw 的“群聊版”因此我们采用了 ReMe 的记忆框架。第一层短期记忆原始对话流水落到 session/dialog/每次回复后由 auto_memory 钩子把当日轻量加工的事实卡片、对话摘要、资源阅读笔记写入 daily//。这一层只关心今天发生了什么结构稳定、可审计且不直接参与在线召回避免短期碎片污染长期检索质量。第二层长期记忆走 digest/{personal, procedure, wiki}/ 三类结构化目录分别对应个人事实 / 操作经验 / 知识节点。后端可插拔本地默认是 Markdown BM25/Embedding/wikilink 混合索引企业生产环境对接到 AnalyticDB for PostgreSQL 的长记忆服务服务端 LLM 做事实抽取、按 Agent 隔离、REST 调用。当一个 Worker 被解雇控制平面有一个明确的 cleanup hook把它的工作区目录整体归档或销毁不会有残留向量散落到其他 Worker 上。第三层Dream 让 Agent 每晚睡觉。auto_dream 是一个 cron 任务定时触发对当天的 daily/ 做四件事备份当前 MEMORY.md 保证可回滚、扫描全部短期记忆、用 LLM 做沉淀修正去重合并把短期事实蒸馏进长期 digest/、输出一份苏醒汇报到 memory/dreams/ 让 Team Admin 可审阅。此外Dream 会同步生成 daily//interests.yaml次日由 proactive 能力读取让 Agent 主动把昨天遗留的待办、合并出来的新主题、用户最近高频关注但还没追问的问题在合适的时机抛进频道。五、是新范式吗回到开篇那个问题群聊会成为使用 Agent 的新范式吗我们的判断是群聊不会取代单聊它会成为 AI Native 组织深挖团队协作效率提升空间的试验田。原因有三第一企业 70% 以上的协作发生在 IM 群聊里。个人 Agent 的使用惯性势必会潜移默化的影响到团队间的协作习惯。第二个人提效的边际收益在递减。单人 Agent 的演进走过了四个阶段prompt engineering、context engineering、harness engineering、loop engineering。但在人和人、岗位和岗位之间的衔接里依旧存在等待、信息丢失、重新对齐、责任推诿等效率黑洞。Anthropic 选择把模型直接嵌进 Slack认为单一强模型足以扮演合格队友AgentTeams 则是把整套 K8s 风格的控制平面搬到协作编排中走的是多 Agent、多 IM、多模型的异构开放路线认为模型能力外治理能力也是刚需。第三面向多智能体的基础设施已经准备好了包括构建和运行时、身份和凭据治理、观测和进化、上下文和记忆等。不过有一件事我们需要澄清群聊是一种组织协作形态不是一个万能解。它的代价并不低甚至会存在较长时间的冷启动时间例如上下文管理变复杂、权限治理变复杂、并发调度变复杂、成本归因变复杂。总的来看Agent 实现组织协作提效既需要强大的模型更需要能支持其稳定、安全、经济运行的新基础设施。AgentTeams 和 AgentLoop 均处于邀测期欢迎申请测试。