xAI 把 Grok Bot 代理的共享模式 Team Bots 開放公測，先支援 Teams 與 Enterprise 方案。賣點很單純：每個團隊一個設定好的 AI 同事，在你已經在用的 Slack 與應用程式裡工作，而每個人的私人對話仍保持私密。
xAI 這次推出的 Grok Team Bots 是什麼
xAI 於 2026 年 9 月 28 日推出 Team Bots，是旗下 Grok Bot 代理的延伸，把原本的單人助手變成共享的團隊基礎設施。Grok Bot 在八月首度登場，是一款常駐、配有自己雲端電腦的代理，能登入應用程式、在無人監督下完成多步驟工作。Team Bots 保留這個基礎，加上一件對企業來說很重要的事：一套所有人都能依循的共享設定。
概念很直接。你圍繞一個角色或一套反覆出現的流程建立 Bot，給它所需的檔案、應用程式與專業知識，再分享出去。同事在各自的對話或共享的 Slack 頻道裡打開同一個 Grok Bot，所有人都取用相同的指令與技能。任何想要一個 Slack 裡 AI 同事的人，都會得到一個已經認識團隊的同事。
公測在 Teams 與 Enterprise 方案上運作。這是商業產品，不是你用個人帳號就能訂閱的東西。它賭的是 xAI 代理屬於公司工作流程，而不只是個別筆電，而 Grok 代理進駐 Slack，正是這個方向最清楚的訊號。
每個 Grok Team Bot 裡的四個層次
根據 xAI 的說法，每個 Team Bot 打包了四種運作情境。合起來，它們正是共享團隊代理與你傳訊息的聊天機器人之間的差別。
層次 | 內含什麼 |
|---|---|
Context | 檔案、指令與技能，例如品牌指南、內部文件與團隊程序 |
Plugins | 連結至 Salesforce、Notion、GitHub 等應用程式，可依個人或整個團隊設定 |
Credentials | 安全存取尚未有外掛的第三方 API |
Memories | Bot 記住什麼，好讓它隨時間適應被指派的角色 |
Context 是多數人最低估的一層。共享 bot 的用處，取決於你餵給它的素材，所以一份品牌指南或內部手冊對產出品質的幫助，比一句聰明的提示詞更大。
Plugins 與 credentials 處理的是 Bot 如何觸及你的工具。對已有連接器的應用程式，plugins 是乾淨的路徑。對沒有連接器的，credentials 是備案，讓 Bot 直接呼叫 API，而不必苦等一個可能永遠不出的整合。
Grok Team Bots 如何讓私人對話保持獨立
共享代理最顯而易見的顧慮是隱私。如果大家共用一個 bot，你的交易筆記會不會跑進同事的對話裡？
值得一問。xAI 說不會。
xAI 表示不會。每個人的直接對話保持私密，每位使用者有各自的情境與記憶，而共享的技能與指令仍在團隊間適用。所以業務員關於某筆交易的私人筆記，留在該使用者自己的情境裡，而客戶攻略則持續對其他成員開放。這是合理的切分：知識共享，工作階段不共享。
Slack 是故事的另一半。每個 Team Bot 都有專屬帳號，意味著你可以把它邀進頻道，任何人都能提問、補充脈絡，並依頻道既有的可見度規則讀取它的回答。把 Grok 在 Slack 的整合想成前門：bot 出現在工作發生的地方，而不是又多開一個分頁。這正是為什麼共享頻道裡的 Slack AI 代理，比一個獨立儀表板容易採用得多。
xAI 說 Team Bots 在內部已經在做什麼
xAI 用自家團隊的例子為這次發布背書，其中四個值得一提，因為它們展現的是廣度，不只是行銷話術。
在業務端，每個重要客戶都有一個專屬 Bot，由客戶經理、客戶成功經理、解決方案架構師與業務主管共用。它每晚檢視公司新聞、Gong 通話錄音、Notion 文件與相關的 Slack 討論串；每天早上在客戶頻道貼出簡報，說明有什麼變化、每個人下一步該做什麼，並附上依角色客製的草稿。當人員輪替進出某個客戶時，Bot 就成了讓新人快速上軌的紀錄。
在工程端，一個 Bot 以專案的 Slack 頻道為據點，連結 Notion、Linear、Hex、Datadog 與 Cursor。它追蹤決策、分診 bug、開立工單，並針對定義明確的修正啟動 Cloud Agents。xAI 說一個五人團隊用這套設定，駕馭了一個協調數百個 Cloud Agents 的 Cursor 專案，每天出貨超過 100 個 pull request，並在數週內自行推出 Team Bots。
行銷端拿到一個會依品牌指南檢查草稿的 Bot，並把核准過的網站與 SEO 變更從審查到預覽一路推進，讓各地團隊能照自己的時程出貨。資料端則有一個 Bot，用唯讀憑證從獲准的 Databricks 資料表回答臨時問題，取用該資料團隊兩年來在逾 45,000 張表上建立的技能庫。
xAI 之外的公司在發布文中只點名一家：Harper，一家為小型企業提供保險的公司，它建立了一個 Team Bot 來找出保單失效的客戶，協助他們復保。
Team Bots 仍留下哪些未解問題
行銷說得很清楚，運作細節卻偏薄。
xAI 的工程案例把這套流程記在每天超過 100 個 pull request 的帳上，但公告並未公布 pull request 的大小、合併或回退率、審查負載或缺陷資料。沒有這些數字，很難把這與傳統團隊或另一套代理輔助的設定相比。把這個數字當成公司說法，而非評測基準。
對認真評估要導入給真實團隊的人來說，還有幾處缺口值得注意。憑證的範圍設定、密鑰輪替、審批流程與稽核紀錄，公告都沒詳細交代。較早的 Grok Bot 指引曾說同一帳號上的 Bots 共用一台雲端電腦，彼此之間沒有安全邊界，而 Team Bots 的發布文也沒說共享模式是否加上租戶隔離。記憶治理同樣模糊：xAI 說共享的修正能改善所有人的答案，卻又說每位使用者有各自獨立的記憶，至於哪些修正會變成共享技能、設定或記憶，並不清楚。
對身處受監管產業的團隊而言，這些問題應該在導入之前問清楚，而不是之後。
Grok Team Bots 如何改變團隊的工作方式
這裡有意思的轉變不在模型，而在採用的單位。
至今為止，AI 代理大多是個人工具。一個人設定一個 bot，摸清它的脾氣，然後自己留著用。Team Bots 把代理當成共享基礎設施，有角色、有記憶，也有讓新同事上手的入口。這與產業中的一個趨勢吻合，Anthropic 的企業推進與 OpenAI 的商業連接器都朝同樣方向走，全都在追同一個念頭：團隊級的 AI 代理。
實際的好處是延續性。當一個 Bot 成為專案決策落腳的地方，招募新人意味著給他存取權，而不是三週的交接。風險則是它的鏡像：一個從壞脈絡學來的共享 bot，會把那個脈絡散播給每個人。
目前這是針對已在 Teams 或 Enterprise 方案上的公司所推出的公測。如果你帶的團隊靠 Slack 運作、又有大量反覆出現的工作，值得先觀察 xAI 怎麼回答安全與治理的問題，再把任何敏感事項接上去。先用一套你很熟悉的工作流程起步，這樣你才能拿自己本來就做得出來的工作，去評判它的產出。
