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會將消息進行語義解析，識別出其中包含的多個子意圖，然後它不會讓一個萬能助手去硬扛所有事，而是根據子任務的屬性，將其路由到不同的技能棧。

這些被選中的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。

感興趣的童鞋趕緊上手試試吧～ (量子位)