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。

感興趣的童鞋趕緊上手試試吧～