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

西风 发自 凹非寺
量子位 | 公众号 QbitAI

文心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会将消息进行语义解析，识别出其中包含的多个子意图，然后它不会让一个万能助手去硬扛所有事，而是根据子任务的属性，将其路由到不同的技能栈。

这些被选中的Agent会并行执行各自的任务，正如前所述，它们从Master那里接收到的，是已经过语义切片的、与自身任务高度相关的纯净上下文，因此能专注处理。

执行完毕后，它们将结果返回给Master。Master充当最终的整合编辑，将来自不同Agent的、格式各异的结果，整合成一份结构清晰、语言统一的完整方案，再通过“群聊助手”这个统一的界面交付给用户。

更进一步的主动协同体现在，垂类智能体负责专业问题，而如果任务中包含了明显的个人偏好，个人智能体记住每个人偏好与限制，Master在分发时，会优先将任务路由到用户的“个人助手”。这个个人助手基于对用户历史对话、偏好的长期记忆，能够输出更具个性化的结果。

第三关：任务打架，资源怎么分？

解决了听清命令和任务分配的问题，更棘手的情况来了：如果群里好几个人同时派活——“查股价”、“画个Logo”、“顺便算算市盈率”，系统该怎么办？

传统做法要么是排队阻塞（Typing时无法响应），让用户干等；要么是缺乏统一调度导致资源争抢，系统卡顿甚至崩溃。

百度文心的核心策略，是引入计算机CPU设计的精髓——乱序执行（Out-of-Order Execution）与分支预测（Branch Prediction），构建了智能调度系统。

这也被认为是Group-MAS与常规智能体系统的最⼤区别

在Group-MAS系统中，面对爆发式涌入的多个任务，Master会维护一张动态的任务依赖图（Task Dependency Graph），进行依赖感知与并发流水线调度。

它能看清所有任务之间的依赖关系：

• 如查股价等无依赖的独立任务立即启动执行；
• 算市盈率依赖股价数据属于强依赖任务，进入等待状态，一旦前置任务完成，结果将自动作为输入参数注入，立即解锁执行；
• 画“刚才那样”的Logo等依赖不明确的任务，系统会挂起并询问用户，或基于历史上下文推测确认。

换句话说，系统不再排队，而是构建了一座“任务立交桥”：能独立执行的立刻上桥；有依赖关系的在匝道等待，一旦数据到达立刻通行；不明确的则先沟通确认。

这让AI群聊摆脱了呆板的一问一答模式，变成了一个能并行处理多项复杂任务的智能中枢。

第四关：Agent如何有眼力见儿？

最后一个挑战直接决定用户体验的好坏：

如何让Agent像一个得力的同事，懂得在合适的时机、用合适的方式介入，而不是一个需要反复@、或总在不合时宜时插话的铁憨憨？

百度文心的答案，是为其植入动态的风格偏好系统与主动交互机制，前者解决“怎么说”，后者解决“何时说”。

市面上很多Agent的性格都是固定死的，Group-MAS摒弃了通用的System Prompt硬编码模式，构建了动态的Flavor注入层（Interaction Parameter Control System），将Agent的行为风格解耦为一组可调节的连续特征，核心包括信息密度、介入阈值和语气温度，支持无限细腻的风格微调。

这一机制并非静态，而是基于会话（Session-based）或指令（Instruction-based）动态注入，遵循“用户定义优先，语境适应为辅”的原则。

你想改风格，可以主动说，比如发一句“接下来说话简洁点”，它就会立刻调整信息密度参数。你没说但场景需要，它也能够自动实时调节参数。

在技术实现上，Flavor层作为中间件（Middleware）位于LLM推理层之前。系统先解析用户输入意图（闲聊则降低Flavor权重，任务场景Flavor权重则优先服务于任务效率），再将预设配置与当前对话风格加权融合，最终转化为具体Prompt指令注入Context。

更重要的是主动介入机制。

很多Agent都是被动响应，你不@它、不发指令，它就一直躺平。但Group-MAS是主动观察模式，背后是一套叫OODA循环的逻辑，简单说就是AI一直在盯着群聊，随时判断该怎么做：

• 观察（Observe）：群里每一条消息都不放过，哪怕是大家聊午饭、聊八卦；
• 判断（Orient）：结合当前的聊天氛围和自己的性格参数，算一算现在插话合适吗；
• 决策（Decide）：要么沉默着更新自己的知识库（比如记住你喜欢的报告风格），要么主动出手（比如看到大家争论一个错误点，悄悄抛出正确答案）；
• 行动（Act）：用之前调好的风格，给出回应。

这套逻辑下来，Agent不再是召之即来、挥之即去的工具，而是能读懂群聊氛围、适配场景需求的团队成员。该沉默时不打扰，该出手时不缺位，这就是Agent的“眼力见儿”。

从功能到系统，一次全栈验证

透过文心APP群聊功能来看，别的不说，在造“新物种”这件事上，百度向来敢投入。

文心APP敢于率先蹚这条路，并将其工程化落地，反映的并非简单的创意领先，而是一种更底层的技术路径选择和能力结构映射。它不是给群聊加个AI插件，而是对协作场景的AI原生重构

纵观行业，将多智能体系统深度整合进一个高并发的实时交互场景，是一条高难度路径。

不仅需要同时解决噪声过滤、依赖调度、风格适配等多个耦合性问题；还要求将大模型能力、实时通信、状态管理、资源调度等多层技术栈无缝焊接，形成稳定、低延迟的服务体系。

更关键在于，这类系统的持续优化也极度依赖真实、复杂的交互数据来迭代调度策略与协作逻辑，这需要拥有足够的用户规模和场景深度作为养料。

而这样的系统级挑战，恰恰考验着百度长期构建的从芯片、框架、模型到应用的“全栈AI”能力的深度协同。

文心APP群聊功能更像是一个水到渠成的技术验证，体现了百度将前沿的多智能体研究转化为一个稳定、可交付的消费者级产品的工程化与系统整合能力。

更具前瞻性的是，Group-MAS在设计之初就考虑了“生态”与“标准”。

其架构原生支持MCP协议，而智能体的热插拔能力，则让增加一个专业Agent变得像上传一份配置文件那样简单。

这种设计指向了一种可能性，它不止于提供一个功能固化的产品，更可能在为不同来源、不同专业的AI能力，预备一套标准化的接入与协作机制。

文心APP群聊是一次关于“系统智能如何融入人类协作流程”的工程性探索，它验证了LLM as OS（⼤模型即操作系统）的可⾏性，也验证了百度有构建支撑未来AI原生世界的操作系统级基础设施的能力。

据了解，下一步，文心APP群聊功能还将支持在群聊内给自己、或别人布置任务提醒，还会上新一批特色玩法类Agent。

感兴趣的童鞋赶紧上手试试吧～