Agent当上群主后，群聊变成办事大厅了量子位

文心APP的群里，最近有点“AI多势众”。

此群非一般的群，正是文心APP最近正在内测的行业首个“多人、多Agent”群聊功能。

该怎么形容它最贴切，一进这个群，就相当于进入了一个微型“办事处”，有几位随时待命、各司其职的Agent专员，能真正替你办事、帮你支招，沟通效率还很高的那种。

它的用处很实在。

比如年初体检季，家人对着报告单上几个箭头忧心忡忡，亲戚群里七嘴八舌，焦虑在转发和猜测中发酵。这时就可以立刻拉个文心群。

大家聊天中一旦出现“指标异常要不要紧”等健康方面的疑问，原本在线的群聊助手Agent就会立刻拉文心健康管家Agent入群，用口语化的表述解读专业术语，区分哪些问题需要重视、哪些不必过度担心。

这既回应了当事人的具体困惑，也平复了围观亲友的紧张情绪。专业信息成了可理解、可落实的建议。

再举个栗子，几个朋友想周末特种兵式出游，以往在群里定行程，常陷入“随便都行”和“怎么都行不通”的拉扯。

但建一个文心群聊，当大家讨论“这个季节哪儿人少景好”“怎么走不绕路”时，不用你手动@，群聊助手便会主动识别需求给出建议，帮你做旅行规划、实时查询信息等。

群中还为每位成员配备了专属的个人文心助手Agent，它能记住你的个人偏好，担任你的随行助理。也就是说，大家的讨论会在多个Agent的实时补充与协作下，得以快速聚焦，形成可行方案。

这也正应了百度文心团队对这个群聊功能的定位——目标不是“社交场景的AI增强”，而是“协作场景的AI原生重构”。

文心正试图为群聊叠加一个关键的行动层，推动其从一个闲聊场，变成一个能办事、能交付结果的行动中枢。

目前，该功能已扩大内测范围，在文心APP最新版本中即可体验。

但这个看似顺理成章的功能，为什么行业内一直少有落地？把多个Agent放进群里，百度文心团队究竟是怎么做到的？

把AI拉进群，难在哪儿？如何解？

把AI放进群聊，要系统性地攻克层层技术难关。

群聊本质是高熵、非结构化、多并发的场景，与传统1v1对话存在本质区别。这就像让一个个顶级学霸突然钻进菜市场，这里信息嘈杂、七嘴八舌、话题跳跃。在几十条甚至几百条消息里，人类尚且会常常找不到结论，AI同样会懵圈。

要分辨不同的人说的不同的话，各个Agent还要快速完成分工协作，然后解决完你的、解决你的，并不容易。

传统大模型的单体智能范式，与群聊场景的社会性计算需求，存在根本性的错配。要攻克它，不能只靠把模型做得更聪明，而必须为AI重塑一套适应“群居生活”的底层工作方式。

由此，百度文心团队提出了Group-MAS（Multi-Agent System），它并非简单的Chatbot，而是一个管理进程（Agents）、内存（Context）、I/O（User Streams）和权限（Permissions）的智能运行时环境。

第一关：信息乱炖，AI怎么听话？

群聊中，核心指令常常淹没在闲聊噪音中。如果像传统AI大模型似的使用单一的、线性的FIFO（先进先出）上下文窗口，会把群聊中所有人的对话，无论是“帮我写代码”还是“中午吃啥”都一锅炖地处理，导致关键指令被污染，进而引发模型幻觉，输出荒诞结果。

文心团队解决这个问题的第一步，就是放弃所有消息塞进一个上下文窗口的思路，而是采用了Hub-and-Spoke（星型拓扑）架构。

Hub（中心节点），对应Group-MAS中的Master中心节点，是整个系统的“大脑+路由器+内核”。所有群聊消息、用户指令都会先汇总到这里，它不直接执行具体任务，而是负责全局管理。

消息进入后，先由Master进行语义层面的拆分与归类。

这背后是团队研发的语义切片（Semantic Slicing）技术。通俗来讲，Master就像一个制片人，把群聊里关于“代码讨论”的对话剪进Slice A，把“生活闲聊”剪进Slice B，不同类型的信息在逻辑上被隔离成多个并行频道。

Spoke（分支节点），则对应系统中的各类Agent以及工具。它们是具体的执行者，各自拥有专属技能，通过标准化接口与Master连接，接收Master分发的任务。

当某个Agent需要介入时，它拿到的不是整个群的原始聊天记录，而只是与自己任务相关的那一小段语义切片，无关信息的干扰会被完全屏蔽掉。

从系统视角看，这相当于为每个Agent构建了专属上下文空间；从体验视角看，表现出来的就是AI开始能听懂并能匹配上群聊中每一个人、每一段话的真实意图。

但听话只是第一步。

第二关：不同Agent之间，如何高效协作？

要真正实现高效协作，还需要解决一个更精妙的问题：不同的Agent之间，如何像一支训练有素的团队一样互相配合，甚至主动补位？这背后需要一套统一的架构支撑与任务分级调度机制。

首先，Group-MAS打造了统一声明式架构与标准化体系：

一方面，所有智能体都遵循同一套Agent Lifecycle FSM（有限状态机）生命周期管理，确保系统稳定性；

另一方面，通过MCP Native协议兼容和Hot-Pluggable（热插拔）特性，任何标准MCP Server都可一键接入，新增Agent只需上传JSON Schema，无需重启Kernel，极大提升了系统扩展性。

在协作流程上，当用户在群聊中提出一个复杂请求时，Master会先基于认知熵进行任务分级：

对于简单的L1任务（原子操作），直连Agent或进行Zero-Shot ToolCall；

对于中等复杂度的L2任务（需验证），采用 Map-Reduce、并行搜索等轻量级Deep Research方式整合信息；

对于复杂长程的L3任务（高复杂度），会生成任务树进行详细编排，分解为子任务并明确依赖关系。

在此基础上，Master会将消息进行语义解析，识别出其中包含的多个子意图，然后它不会让一个万能助手去硬扛所有事，而是根据子任务的属性，将其路由到不同的技能栈。