1. 為什么需要“一群”AI助理而不是一個先聊個現(xiàn)象。很多人第一次接觸 AI 助理的時候習慣把它當成一個“萬能機器人”問什么答什么今天讓它查資料明天讓它寫周報后天又讓它管日程。一開始確實新鮮用上一段時間就會發(fā)現(xiàn)單機版的助理有幾個很難受的瓶頸。第一一個上下文里塞了太多職責角色混亂。同一個助理既要做代碼審查又要做活動策劃還要回復(fù)用戶投訴它的系統(tǒng)提示詞會越來越長最后變成一個什么都懂一點、什么都不精的“萬金油”。第二多人協(xié)同時無法分權(quán)。比如團隊里有運營、技術(shù)、銷售所有人都拉同一個助理進群助理不知道該聽誰的也不知道哪些信息該對誰說。第三狀態(tài)管理基本為0。我讓它跟進項目 A 的進度轉(zhuǎn)頭又讓它處理項目 B它經(jīng)常把兩件事攪在一起甚至忘掉之前的約定。我身邊不少朋友最后的選擇是把 AI 助理從“一個機器人”拆成“一群機器人”每個機器人只干一類活彼此之間還能互相交接。這個思路并不新鮮就像公司里沒人指望一個員工身兼 CEO、設(shè)計師、財務(wù)三個職位一樣AI 助理也應(yīng)該有分工。問題只是怎么把這一群機器人高效地組織起來讓它們共用一個聊天入口用戶不需要裝五個 App也不需要記住五個網(wǎng)址。這次我用的方案是 OpenClaw 飛書。OpenClaw 作為助理框架負責把各個“助理實例”跑起來飛書負責當統(tǒng)一入口和消息總線。最后搭出來的效果是團隊一個群聊里躺著5個 AI 助理用戶 誰就找誰干活助理之間也能在一個共享頻道里互相傳遞任務(wù)摘要。這篇文章把整套搭建過程、角色設(shè)計、消息路由和踩過的坑都寫清楚想直接照著做的朋友可以少走不少彎路。2. 搭建前的整體架構(gòu)OpenClaw 和飛書各自扮演什么角色動手之前先花幾分鐘把架構(gòu)講明白。很多人一上來就急著配環(huán)境結(jié)果配完發(fā)現(xiàn)根本不知道數(shù)據(jù)從哪兒流到哪兒出了問題也不知道去哪個環(huán)節(jié)排查。2.1 OpenClaw 不是“一個機器人”而是一個機器人運行環(huán)境OpenClaw 這類框架的核心能力是讓每個 AI 助理成為一個可獨立配置的實例。每個實例有自己的名字、人設(shè)、使用哪個模型、掛在哪個 IM 平臺、能調(diào)用哪些工具以及自己的長期記憶存儲。你可以把它理解成“一個能同時養(yǎng)很多條電子寵物魚的魚缸”每條魚吃什么、游到哪個角落全部獨立配置但共用同一套水質(zhì)管理系統(tǒng)。這個設(shè)計解決了我前面說的“職責混亂”問題。運營助理的提示詞里不需要寫任何代碼規(guī)范技術(shù)助理的提示詞里也不需要管內(nèi)容排期。各實例的上下文互相隔離模型也不需要在多個角色之間反復(fù)橫跳回答質(zhì)量明顯比單一大助理穩(wěn)定得多。我這次搭的5個助理實例分別是助理A項目統(tǒng)籌、助理B技術(shù)開發(fā)、助理C內(nèi)容運營、助理D數(shù)據(jù)分析、助理E會議記錄。取名沒有特別復(fù)雜就是按職責來因為后面在飛書群里 的時候名字越直觀越好認。2.2 飛書當消息中樞的邏輯飛書在這套架構(gòu)里不是“錦上添花”而是唯一的用戶交互層。用戶不直接接觸 OpenClaw 的 API也不關(guān)心后端跑的是什么進程他們只需要知道“在飛書群里 助理A 就能匯報進度 助理C 就能安排推文”就夠了。選飛書而不是其他 IM主要出于三個考慮事件訂閱機制夠靈活機器人能接收到消息、回復(fù)消息、也能主動往群里推送群聊和話題線程的原生支持很完善適合多個助理共用一個“大群 獨立話題”的協(xié)作場景國內(nèi)團隊用它的比例高不需要額外培養(yǎng)用戶習慣。為了便于理解整套消息流可以簡化為用戶在飛書群里發(fā)消息 → 飛書事件訂閱推送回調(diào)給 OpenClaw 的網(wǎng)關(guān) → 網(wǎng)關(guān)根據(jù) 的對象選擇對應(yīng)助理實例 → 助理處理后把回復(fù)內(nèi)容通過 API 發(fā)回飛書群。后面所有配置都是圍繞這條鏈路展開的。2.3 環(huán)境準備清單一臺能長期在線的服務(wù)器或者本機開發(fā)調(diào)試階段用自己的電腦也行跑通后建議換到常駐機器因為飛書回調(diào)要求你的網(wǎng)關(guān)能公網(wǎng)可達OpenClaw 運行環(huán)境Python 3.10及以上牽扯到本地記憶存儲的話建議配好數(shù)據(jù)庫一個飛書開發(fā)者賬號企業(yè)自建應(yīng)用權(quán)限即可各助理實例背后的大模型 API Key可以都用同一個也可以按角色分配不同模型這套清單看起來簡單但有一個容易忽略的細節(jié)回調(diào)地址必須是公網(wǎng)可訪問的 HTTPS 地址。如果你在本地調(diào)試飛書根本推不過來事件因為它的服務(wù)器訪問不到你的 localhost。我用內(nèi)網(wǎng)穿透工具直接把本機的 8080 端口映射出去拿到一個臨時 HTTPS 域名才開始正常收到消息后面正式部署時換成了服務(wù)器上的域名。3. 飛書自建應(yīng)用從零到能收發(fā)消息的完整步驟飛書這邊的配置是整個鏈路里最容易出詭異問題的一環(huán)很多報錯信息你不去搜根本不知道它想表達什么。我從頭到尾走了一遍把關(guān)鍵步驟和坑都列出來。3.1 創(chuàng)建自建應(yīng)用與權(quán)限配置登錄飛書開放平臺創(chuàng)建一個“企業(yè)自建應(yīng)用”。創(chuàng)建時只填應(yīng)用名稱和描述就行我起的應(yīng)用名就叫“AI 助理團隊”描述里簡單寫了各助理的職責范圍。創(chuàng)建完進入“權(quán)限管理”頁面這個環(huán)節(jié)是最容易漏的。我不止一次遇到“消息發(fā)不出去”“收不到回調(diào)”的問題最后發(fā)現(xiàn)是沒有啟用對應(yīng)權(quán)限。需要開通的權(quán)限項包括im:message獲取與發(fā)送單聊/群聊消息im:message.group_at接收群聊中 機器人的消息im:chat讀取群信息contact:user.base讀取用戶基本信息用來區(qū)分是誰發(fā)的消息這里有一個經(jīng)驗之談不要在權(quán)限列表里憑感覺勾選飛書的權(quán)限分得非常細“讀消息”和“讀取群聊中的消息”是兩個完全不同的權(quán)限漏一個都不行。配完之后最好手動觸發(fā)一次事件看看到底是“沒收到”還是“收到了但被過濾了”。3.2 事件訂閱驗證 URL 與回調(diào)配置這一步很多人卡了很久。飛書要求你在事件訂閱配置里填一個“請求地址”它會在保存時向這個地址發(fā)送一個 challenge 驗證請求你的服務(wù)端必須正確響應(yīng)才能通過驗證。OpenClaw 如果帶了飛書適配層通常會把這個驗證邏輯封裝好。你需要做的就是在配置里填好回調(diào)地址https://你的域名/webhook/feishu這種路徑然后保存。如果保存時報“URL 驗證失敗”大概率不是代碼問題而是你那個地址在公網(wǎng)上根本訪問不到先用 curl 在服務(wù)器上確認一下能通再回頭排查別的。事件類型方面我訂閱了這幾個im.message.receive_v1收到消息im.message.message_read_v1消息已讀用于后續(xù)做已讀回執(zhí)group.member.added有人把機器人拉進群自動發(fā)歡迎語3.3 發(fā)消息時的身份與租戶憑證問題配置好憑證之后OpenClaw 要用tenant_access_token去調(diào)用發(fā)消息接口而不能用user_access_token。區(qū)別在于user_access_token代表某個真實用戶的身份有時候會被權(quán)限策略限制tenant_access_token代表應(yīng)用本身適合機器人主動推送消息。封裝好的框架一般會自動獲取和緩存 token但如果你自己寫腳本調(diào)試記得 token 有有效期別圖省事硬編碼。我實際調(diào)試時還遇到一個很隱蔽的問題應(yīng)用發(fā)布后權(quán)限不會自動生效。飛書的權(quán)限改動需要“創(chuàng)建版本并發(fā)布”發(fā)布之后才真正生效。我在權(quán)限管理里加了字段看文檔說“已開通”但回調(diào)里始終拿不到用戶詳情最后發(fā)現(xiàn)是壓根沒發(fā)布新版本舊版本的權(quán)限還是原來那套。這個環(huán)節(jié)排完之后的效果是你在飛書群里 機器人它會在幾秒鐘內(nèi)回復(fù)一條“收到”。這個時候說明鏈路已經(jīng)打通接下來要做的就是讓它具備干活的能力。4. 5個助理的角色矩陣提示詞分工與協(xié)作邊界鏈路打通之后就進入真正有意思的部分給這5個助理寫“崗位說明書”。這一步?jīng)Q定了團隊好不好用。我當時的想法是每個角色必須有明確的職責邊界、觸發(fā)條件和交接格式否則就會出現(xiàn)“助理A 搶了助理B 的活”這種場景。4.1 角色設(shè)計背后的思考扮演項目統(tǒng)籌的助理A主要接收項目相關(guān)消息里程碑、風險、任務(wù)指派扮演技術(shù)開發(fā)的助理B接收代碼和部署相關(guān)請求它需要訪問一些內(nèi)部文檔扮演內(nèi)容運營的助理C負責排期、選題、文案扮演數(shù)據(jù)分析的助理D處理指標查詢和報表解讀扮演會議記錄的助理E專門整理會議紀要并且在會議結(jié)束后把待辦事項發(fā)給對應(yīng)負責人。為什么是這5個而不是3個或者10個因為團隊協(xié)作的常見場景就這幾類角色太少會出現(xiàn)“什么都往技術(shù)助理里塞”的情況角色太多則會因為消息路由不清晰出現(xiàn)“不知道 誰”的局面。5個在我這個場景里剛好平衡。有一點需要強調(diào)角色之間邊界不清AI 再聰明也白搭。比如你同時給助理A和助理C配置了“生成項目周報”的能力那用戶 誰都能生成周報分工具的意義就沒了。我在提示詞里會給每個角色加上“拒絕清單”遇到不屬于自己職責范圍的事項不要硬答直接說明應(yīng)該找哪位同事。4.2 提示詞模板一個可以直接改用的例子以內(nèi)容運營助理C的提示詞為例我寫的是你是內(nèi)容運營助理C隸屬于 AI 助理團隊。 你的專屬職責內(nèi)容選題建議、推文大綱、標題優(yōu)化、排期表更新。 你只能處理與內(nèi)容運營相關(guān)的事務(wù)以下情況請直接拒絕并引導對方去找對應(yīng)同事 - 對方讓你改代碼、查服務(wù)器日志 → 引導其 技術(shù)開發(fā) - 對方讓你生成數(shù)據(jù)報表 → 引導其 數(shù)據(jù)分析 - 對方讓你安排會議 → 引導其 會議記錄 與同事交接時使用統(tǒng)一的交接格式 【交接給X】【任務(wù)編號】【上下文摘要】【請求事項】 例如【交接給數(shù)據(jù)分析D】【任務(wù)編號T-2025-011】【用戶需要上周文章閱讀量趨勢】【請生成按渠道拆分的閱讀量同比表】這個“交接格式”非常重要。因為單個助理的上下文是隔離的如果想實現(xiàn)“運營助理收集需求數(shù)據(jù)助理出報表”這條鏈路就必須有一個顯性的交接協(xié)議。格式越固定后續(xù)做狀態(tài)解析越方便。4.3 各助理的模型與工具配置在這個例子里助理A和助理B的上下文較長推理邏輯要求高所以分配給上下文窗口更大的模型助理C和會議記錄E 的日常任務(wù)相對輕量用更快的模型即可數(shù)據(jù)分析D 需要處理表格給它加了文件讀取工具。OpenClaw 里每個實例的配置類似這樣以示意配置為例agents: 項目統(tǒng)籌: model: fast-context-large memory: true system_prompt_file: prompts/coordinator.md tools: - todo_list - group_notify 技術(shù)開發(fā): model: deep-reasoning memory: true system_prompt_file: prompts/developer.md tools: - shell - repo_docsmemory: true這行建議所有助理都打開它讓每個助理能記住用戶在群里聊過的歷史避免每次對話都像第一次見面一樣。數(shù)據(jù)可以存在 SQLite 里量不大成本幾乎可以忽略。5. 協(xié)作鏈路的關(guān)鍵消息路由與交接協(xié)議飛書這邊有一個天然優(yōu)勢——它允許在一個群里多個機器人共存。這意味著5個助理可以都拉進同一個群用戶不需要切換聊天窗口。但這同時帶來一個挑戰(zhàn)**一條消息發(fā)進來怎么知道該讓哪個助理處理**我在實際搭的時候試過幾種方案最后保留了三層規(guī)則。5.1 第一層 指定路由最直接的方式是讓用戶主動 。飛書的消息回調(diào)里會帶上 mention 信息說明這條消息 了誰。OpenClaw 的飛書適配層通常會解析這個字段如果消息里明確 了“數(shù)據(jù)分析D”就直接把消息交給助理D處理。這個方案的優(yōu)點是簡單可靠缺點是需要用戶記憶每個助理叫什么。所以我在每個助理的歡迎語里都會寫一句自我介紹比如助理A進群時自動發(fā)“我是項目統(tǒng)籌A負責里程碑、風險、任務(wù)協(xié)調(diào)。需要協(xié)作請 我我會把任務(wù)分配給對應(yīng)同事。”5.2 第二層關(guān)鍵詞與群話題兜底用戶不總是記得 誰尤其剛上手的時候。我用關(guān)鍵詞做了一層兜底路由消息包含“報表”“環(huán)比”“指標”等詞自動轉(zhuǎn)給數(shù)據(jù)分析D包含“排期”“標題”“選題”等詞自動轉(zhuǎn)給內(nèi)容運營C。關(guān)鍵詞表的準確率沒必要追求百分之百因為還有第三層兜底。群話題也是一個好用的功能不同類型的任務(wù)在不同話題里討論我在話題標題里帶上對應(yīng)助理的名字比如“【技術(shù)開發(fā)】服務(wù)部署問題”然后讓 OpenClaw 監(jiān)聽并匹配話題名。這樣即使沒 對只要在正確的話題里發(fā)也能送到合適的助理手上。5.3 第三層人工兜底與歷史任務(wù)查詢?nèi)龑右?guī)則之外我在 OpenClaw 里加了一個“未知意圖處理”的邏輯。如果消息沒有觸發(fā)任何路由規(guī)則OpenClaw 默認交給助理A項目統(tǒng)籌處理助理A會追問用戶需求做一次粗分診再決定是自己處理還是轉(zhuǎn)給其他助理。這才是真正的協(xié)作不是5個助理各干各的而是有一個“總調(diào)度”負責兜底和分發(fā)。你可以在飛書群里體驗到一個很自然的流程先在群里說一句“幫我安排下周的推文排期”助理A會問清楚是內(nèi)容主題、發(fā)布時間還是人員分配然后它會把任務(wù)轉(zhuǎn)給內(nèi)容運營CC產(chǎn)出一版排期表之后再把文檔 給相關(guān)同事。協(xié)作能否跑通核心就看交接節(jié)點寫沒寫干凈。我見過很多團隊配置了多個助理最后變成“各說各話”——助理A讓用戶去找助理C但助理C完全不知道之前聊了什么。這是最掉鏈子的場景可一旦你把【交接給X】【上下文摘要】這些字段規(guī)范化助理之間傳遞信息的能力會明顯提升。6. 協(xié)同之外的另一個重點統(tǒng)一知識庫與權(quán)限隔離多助理跑起來之后比“誰能干活”更讓人頭疼的問題是“誰可以知道什么”。有些信息適合讓所有助理看到比如產(chǎn)品使用文檔有些則必須隔離比如機密配置信息。如果用一套知識庫喂給所有助理等于把權(quán)限問題全部抹平了這在團隊協(xié)作里是很危險的。6.1 知識庫按角色分區(qū)存放我用的方案是給每個助理指定獨立的文檔目錄。項目統(tǒng)籌A 的文檔目錄里放的是團隊目標、里程碑計劃技術(shù)開發(fā)B 的目錄里放的是接口文檔、部署手冊內(nèi)容運營C 只能訪問運營素材庫數(shù)據(jù)分析D 能訪問指標定義文檔會議記錄E 則對接會議模板和日歷權(quán)限。OpenClaw 的配置里可以給每個實例指定不同的知識庫路徑內(nèi)容索引也是分開構(gòu)建的。這樣技術(shù)開發(fā)B 被問到“排期怎么定的”它不會因為檢索到運營文檔而亂答因為它根本沒有那個索引。6.2 通過群成員可見性控制范圍飛書這邊也做了第二層隔離不是所有人都在同一個群里。我搭了一個“核心協(xié)作大群”里面5個助理都在另外按項目性質(zhì)建了小群只拉入相關(guān)的兩三個助理。比如某個項目群只放進項目統(tǒng)籌A和技術(shù)開發(fā)B這樣這個群里的對話天然不會被內(nèi)容運營C看到信息流更干凈也避免助理在無關(guān)話題里插嘴。飛書支持應(yīng)用在某個群內(nèi)使用前提是機器人被拉進了那個群。這就帶來一個很自然的現(xiàn)象哪個助理在哪個群由群管理員決定而不是由 OpenClaw 決定。權(quán)限管理因此在兩個系統(tǒng)里各做一半飛書管“誰能跟這個助理對話”O(jiān)penClaw管“助理能讀哪些知識庫”。這套組合目前我用下來比較踏實機密信息不會因為“另一個助理問了”而泄露。6.3 敏感操作的審批機制還有一個值得記錄的點不是所有操作助理都能自行落地。我在 OpenClaw 里給部分工具加了“需人工審批”的標記比如發(fā)送對外消息、執(zhí)行數(shù)據(jù)庫寫操作、刪除文件。用戶 技術(shù)開發(fā)B“在測試環(huán)境跑一條刪表 SQL”B 不會直接執(zhí)行而是生成一條待辦事項發(fā)給指定審核人員等審核通過后由人工抽驗后才放行。有人可能覺得這違背了“自動化”的初衷但團隊落地 AI 助理最怕的就是失控。先有護欄再談效率。等運行一段時間,大家信任度上來了再逐步放開某些低風險工具的自動執(zhí)行權(quán)限這個節(jié)奏比較穩(wěn)妥。7. 實際運行中的典型故障與排查鏈路這節(jié)寫排錯。多助理跑在真實環(huán)境里和 Demo 完全不一樣很多問題不是你寫代碼能預(yù)判出來的必須在日志里一行一行看。我把遇到過的三類比較典型的故障整理出來原因、排查鏈路和修復(fù)方案都說清楚。7.1 事件回調(diào)超時導致消息處理失敗癥狀用戶 助理之后飛書群里沒有任何反應(yīng)后臺日志里也看不到消息過來。原因飛書的事件訂閱對回調(diào)響應(yīng)有時間限制。如果你的 OpenClaw 網(wǎng)關(guān)在處理消息前先去做了一些耗時操作比如初始化模型、加載知識庫索引、拉取遠程文檔超過了允許的時間窗口飛書會判定回調(diào)失敗并反復(fù)重試最終事件被丟棄。排查鏈路先看 OpenClaw 的訪問日志里有沒有收到飛書的 POST 請求如果收到了看返回的狀態(tài)碼和響應(yīng)體如果沒收到多半是回調(diào)地址公網(wǎng)不通或者事件訂閱配置不對。我當時的問題就是模型冷啟動耗時太長處理請求前先加載了一個幾百 MB 的本地索引導致網(wǎng)關(guān)沒辦法快速返回 200。解決方案把全局初始化和消息處理分開網(wǎng)關(guān)先回 200再用后臺異步任務(wù)處理消息邏輯。這套改完之后哪怕模型生成回復(fù)需要 20 秒飛書也不會因為超時重試了因為回調(diào)接口本身永遠是秒回的。7.2 多個助理在同一個群里“搶答”癥狀有人發(fā)消息沒有 任何助理結(jié)果技術(shù)開發(fā)B和內(nèi)容運營C同時回復(fù)了一個是技術(shù)建議一個是文案腦暴整個群亂成一鍋粥。原因關(guān)鍵詞路由配置了不只一個助理命中同一句話。比如消息里同時有“部署”和“發(fā)布計劃”B 和 C 都會命中自己的關(guān)鍵詞表而 OpenClaw 默認允許并發(fā)處理就出現(xiàn)了兩個助理同時回復(fù)。排查鏈路翻日志看兩條回復(fù)各自的觸發(fā)規(guī)則是什么發(fā)現(xiàn)自己配的關(guān)鍵詞存在交叉再檢查路由優(yōu)先級配置之前沒有設(shè)明確優(yōu)先級。解決方案一是給關(guān)鍵詞表按優(yōu)先級排序命中高優(yōu)先級后直接短路不再向低優(yōu)先級路由分發(fā)二是開啟“單條消息至多一個助理響應(yīng)”的模式。這個模式引進來之后“搶答”問題基本絕跡。7.3 長短時記憶串臺癥狀內(nèi)容運營C 在給“項目X”寫推廣文案時忽然提到了之前技術(shù)開發(fā)B 查到的服務(wù)器配置參數(shù)看起來非常突兀。原因兩個助理原本是隔離的但我在配置記憶系統(tǒng)時圖省事讓它們共用了同一個向量數(shù)據(jù)庫集合。查詢語義相似的文本時C 檢索到了 B 的記錄然后當成自己的知識用了。排查鏈路去向量數(shù)據(jù)庫里看 C 的檢索記錄發(fā)現(xiàn)返回的文檔里有 B 的索引條目隨后檢查知識庫配置確認共享集合的問題。解決方案為每個助理創(chuàng)建獨立的記憶集合或者加標簽字段檢索時強制加上agent_id過濾條件。改完之后再做一次交叉提問測試確保上下文完全隔離。這類坑總結(jié)下來就一句話多助理真正難的不是讓每個助理變聰明而是不讓它們互相污染。一旦狀態(tài)、知識庫、記憶開始混用協(xié)作團隊會退化成一個精神分裂的大模型效果比單助理還差。8. 可擴展的方向與最后的實戰(zhàn)感受這套“5 個助理團隊”的架子搭完之后我身邊不少同事已經(jīng)直接照搬進自己的內(nèi)部項目里。除了跑通那 5 個基礎(chǔ)角色我還有幾個后續(xù)優(yōu)化思路寫出來供參考。第一個思路是加“助理間會議機制”?，F(xiàn)在助理之間的協(xié)作主要靠交接格式但有些任務(wù)不是單線交接能解決的比如運營策劃需要技術(shù)評估可行性。下一步我想在 OpenClaw 里設(shè)計一個簡單的“調(diào)度頻道”項目統(tǒng)籌A 把任務(wù)描述發(fā)到一個內(nèi)部頻道技術(shù)開發(fā)B和內(nèi)容運營C 分別異步回復(fù)意見A 匯總后給出結(jié)論。相當于把真實團隊的異步討論機制復(fù)制到助理之間而不是只靠格式化的交接字段。第二個思路是給每個助理增加“對外動作”的粒度控制。現(xiàn)在助理能觸達的外部系統(tǒng)還比較有限比如數(shù)據(jù)分析D 能讀 CSV 文件但還不能直接查詢數(shù)據(jù)庫技術(shù)開發(fā)B 能讀部署文檔但沒有實際操作服務(wù)器的權(quán)限。下一步會逐步接入只讀數(shù)據(jù)庫查詢和測試環(huán)境的基礎(chǔ)運維操作權(quán)限低風險動作走自動化高風險動作仍保留人工審批。第三個思路是想辦法降低路由配置的維護成本?，F(xiàn)在關(guān)鍵詞表是手工維護的過一段時間角色職責變化關(guān)鍵詞也要跟著改。長期來看可以考慮在每個助理處理完消息后自動記錄一個“任務(wù)類型標簽”用歷史數(shù)據(jù)反向優(yōu)化路由規(guī)則讓系統(tǒng)學出來的路由比手寫關(guān)鍵詞表更接近真實使用習慣。最后聊幾句實際使用的體會。整套系統(tǒng)從配通到穩(wěn)定運行中間經(jīng)歷了幾輪明顯的調(diào)整最大的變化是心態(tài)不用追求“一個模型干所有事”把任務(wù)拆給多個角色即使每個角色的模型不是最強的整體效果也好過一個大而全的模型。另外就是“路由規(guī)則要盡量讓用戶感知不到”。用戶不需要了解關(guān)鍵詞表、優(yōu)先級、知識庫索引這些底層設(shè)施他們只管在群里 一個名字事情辦完這就是一個合格助理團隊的標準。如果你已經(jīng)有一個正在用的 OpenClaw 實例加一個飛書群里的助理成員只需要幾分鐘如果是零基礎(chǔ)從申請飛書自建應(yīng)用到第一句消息跑通我實測一個下午足夠。照著文中的角色矩陣和交接格式先把 5 個助理立起來跑兩個星期再根據(jù)團隊的真實使用反饋調(diào)整角色職責這比一開始就設(shè)計完美架構(gòu)靠譜得多。