Salesforce 已推出重建版本的 Slackbot，將 Slack 長期以來的工作助理從輕量級通知功能，重新定位為該公司所稱、用於企業搜尋、撰寫與任務執行的 AI 代理。根據 VentureBeat 報導，新的 Slackbot 現已向 Slack Business+ 與 Enterprise+ 客戶正式開放，擴大部署將持續至 2 月底，行動版完成則預計在 3 月 3 日前上線。
這項變動的意義不只是一個單一產品更新。Salesforce 正試圖讓 Slack 成為員工提問、產生文件、從分散系統中整合脈絡，並最終觸發商務軟體中的動作的場所。這讓該公司與 Microsoft Teams 中的 Microsoft Copilot、Google Workspace 中的 Google Gemini 更直接競爭，同時也讓 Slack 與 Salesforce 更廣泛的 AI 代理與 Agentforce 願景緊密綁定。
對 Salesforce 而言，這次推出也回應了一個戰略壓力點。過去一年，投資人一直在問，生成式 AI 會強化既有軟體巨頭，還是把它們降格為第三方助理背後的基礎設施供應商。Salesforce 的答案是：只要具備足夠的脈絡、權限與工作流程覆蓋範圍，聊天層本身就能成為企業 AI 的控制平面。
重建版 Slackbot，而不是小幅升級
VentureBeat 報導指出，Salesforce 高層將這個產品描述為從零開始重建，而不是舊 Slackbot 的迭代版。先前版本主要處理 Slack 內的提醒、通知與基本提示。根據 Slack CTO 兼 Salesforce 共同創辦人 Parker Harris 的說法，新系統建立在大型語言模型、搜尋，以及連接企業資料來源的連接器之上。
VentureBeat 所呈現的內容顯示，Slackbot 可以搜尋 Slack 對話、Salesforce 記錄、Google Drive 檔案與行事曆資料。該媒體引用的一段示範中，Slack 產品團隊展示助理分析客戶回饋、將該材料與上傳的儀表板圖片進行關聯、找出 Salesforce 中可能作為試點的帳戶、把輸出內容轉成 Slack Canvas 文件，並檢查利害關係人是否有空進行後續會議。
這個工作流程很重要，因為它顯示 Salesforce 並非只把 Slackbot 定位成問答用的聊天介面。該公司希望 Slackbot 成為 Slack Canvas 內的協調層，並在未來延伸到外部工具。Slack 產品長 Rob Seaman 告訴 VentureBeat，目前將文件生成到 Canvas 的流程，實際上等同於內部工具呼叫，並預示著未來第三方工具呼叫的規劃。
如果這條路線圖成形，Slackbot 將更接近任務導向的助理：它在使用者既有的協作介面內運作，而不是獨立的聊天機器人分頁。這正是企業 AI 競爭中普遍追逐的方向，但 Salesforce 賭的是，Slack 的對話歷史與頻道結構能讓它在脈絡上取得優勢。
為什麼 Salesforce 先選 Claude
根據 VentureBeat 報導，新的 Slackbot 目前運作在 Anthropic 的 Claude 上。Harris 表示，最初的模型選擇部分受到合規需求影響，具體來說，Slack 的商業服務是以 FedRAMP Moderate 認證面向美國聯邦客戶運作，而 Anthropic 是當系統建置時可用、且符合合規要求的選項。
這似乎不是長期的單一模型策略。Harris 告訴 VentureBeat，Salesforce 預計今年支援更多供應商，並特別提到 Gemini 在效能與成本上都是很強的選項。他也表示 OpenAI 仍有可能納入。
這點值得注意，原因有二。首先，它顯示 Salesforce 正把基礎模型視為可替換元件，而產品體驗則由自己掌控。其次，這反映出更廣泛的市場轉變：應用程式供應商愈來愈希望能依照延遲、定價、合規與品質，把任務路由到不同模型，而不是把產品綁定於單一供應商。
Salesforce 也藉由這次發布再次強調一個熟悉的企業保證：Harris 表示公司不會用客戶資料訓練模型。這種說法回應了常見的買家疑慮，但應被視為供應商對產品政策的主張，而非對架構或資料處理做法的獨立驗證。
這場競爭真正爭的是工作流程主導權
最直接的比較對象是 Microsoft Copilot，尤其是因為 Teams、Microsoft 365、Outlook 與 Office 文件本來就位於許多企業工作流程之中。Google Gemini 在 Workspace 中也有類似的內建優勢。Slack 的回應則是主張：在日常對話中的接近性與脈絡，同樣能與文件套件整合一樣強大。
Salesforce 高層告訴 VentureBeat，Slackbot 的優勢在於它已經嵌入團隊溝通與決策的地方。該公司也主張，Slackbot 以使用者既有的頻道、檔案與權限為基礎，不需要終端使用者進行大量設定。
這個論點有其合理性，但也有侷限。在 Slack 是營運中心的組織中，Slackbot 可能確實是最快進入助理式工作流程的途徑；但在主要依賴 Microsoft 365 或 Google Workspace 的組織中，情況可能正好相反。企業 AI 的很大一部分競爭，正在變成一場爭奪哪個介面夠「接近」工作內容、足以成為預設請求層的戰爭。
Salesforce 也試圖把競爭範圍擴大到助理之外。Harris 告訴 VentureBeat，Slackbot 最終會成為一個「super agent」，也就是能協調其他代理的中央介面。這把 Slackbot 與 Salesforce 對企業 AI 代理的更大願景 Agentforce，以及 Slack 中正在興起的外部代理生態系連結起來。
VentureBeat 指出，Anthropic 的 Claude Code for Slack 已進入預覽，而 OpenAI、Google 與 Vercel 也都已為這個平台打造代理。如果 Slack 變成多個專門代理的容器，Salesforce 的機會就不只是賣出一個助理，而是掌握人類工作者與軟體代理互動的環境。
證據、採用說法與未解問題
由於這則報導基於 VentureBeat 對 Salesforce 訪談與產品示範的報導，因此幾個最強的效能與採用訊號都來自供應商自身，應審慎看待。
Salesforce 告訴 VentureBeat，公司已在內部用 80,000 名員工測試新的 Slackbot。公司表示，其中三分之二的員工曾試用過它，試用者中有 80% 持續定期使用，內部滿意度達到 96%。高層也表示，員工回報每週可節省 2 到 20 小時。這些數字可能顯示出強烈的內部興趣，但它們是自述或公司提供的指標，並非經過獨立稽核的使用資料。
同樣的提醒也適用於試點客戶案例。VentureBeat 報導了來自 Beast Industries、Slalom、reMarkable、Xero、Mercari 與 Engine 的評論。這些參考可作為市場測試的早期訊號，但不能證明廣泛的企業牽引力。像某位 Beast Industries 員工每天節省 90 分鐘、Engine 某位主管每天節省 30 分鐘這類時間節省數字，都屬於軼事且與職位高度相關。
產品限制也仍然存在。Seaman 表示，讀取行事曆與檢查可用時段已經可用，而會議預約預計在幾週後推出。圖像生成功能尚未提供。Salesforce 也沒有向 VentureBeat 提供對 HubSpot 或 Microsoft Dynamics 等競爭性 CRM 平台支援的具體細節。這點很重要，因為買家會想知道 Slackbot 能否作為中立的企業層，或是否最好只在 Salesforce 已經是系統紀錄來源時使用。
成本也是一個尚未解決的問題。VentureBeat 報導，Business+ 與 Enterprise+ 客戶使用 Slackbot 本身不需額外付費。但該媒體也把這次發布與 Salesforce 資料存取定價的更廣泛疑慮連結起來，包括 Fivetran 執行長 George Fraser 的批評：較高的 API 相關成本，可能會讓企業更難把 Salesforce 資料匯入 Snowflake 等外部系統，或透過 Salesforce 偏好的技術堆疊以外的工具與之互動。這個問題雖與 Slackbot 相鄰，但仍相關：一個承諾提供廣泛企業脈絡的產品，若資料移轉更容易，價值就更高；反之，當存取變得更受限或更昂貴時，吸引力就會降低。
這對開發者與企業買家意味著什麼
對產品團隊與 AI 開發者而言，這次發布強化了一個清楚的設計模式：企業助理正從通用聊天機器人，走向嵌入協作工具、具備脈絡感知的代理。Slackbot、Microsoft Copilot 與 Google Gemini 都在試圖減少使用者切換應用程式或手動蒐集素材的需要。
對企業買家而言，關鍵問題是營運層面，而非願景層面。Slackbot 對權限的尊重程度如何？它能多可靠地引用或以 Slack 與 Salesforce 記錄作為答案基礎？連接器與治理到底需要多少設定？以及它能否安全地完成動作，而不只是產生漂亮的摘要？
Slack Canvas 的角度尤其重要。協作文件中的共享輸出，比起一次性的聊天機器人回覆，更容易被審閱、編輯與核准。如果 Slackbot 真的擅長把對話轉成持久的產物與後續任務，那它可能會比只停留在摘要層面的助理更有用。
對在 Slack 上開發的開發者來說，Salesforce 關於第三方工具呼叫與可能支援 Model Context Protocol 的說法值得關注。Slack 內更強的代理介面，可能為利基企業動作創造新的分發路徑，從程式碼工作流程到核准流程，再到支援營運皆然。但這個機會取決於 Salesforce 對平台保持多開放，以及它在多大程度上偏袒自家產品，包括 Agentforce。
接下來要看什麼
下一批有用的訊號將會是具體而非口號。首先，觀察 Salesforce 是否加入承諾中的 Gemini 或其他模型供應商支援，因為這將顯示公司對多模型架構的認真程度。
其次，留意超出 Slack Canvas 之外的實際工具呼叫證據，尤其是能讓 Slackbot 在第三方系統中執行動作，且具備稽核性與權限控制的整合。
第三，追蹤 Salesforce 是否釐清對 HubSpot、Microsoft Dynamics、Snowflake 或外部資料平台等非 Salesforce 系統的支援。買家會想知道 Slackbot 是企業助理，還是主要是一個住在 Slack 裡的 Salesforce 助理。
最後，Salesforce 自家員工與精選試點帳戶之外的採用情況，比內部成功故事更重要。使用留存率、大型客戶內部的擴張，以及資安團隊是否願意接受大規模部署，這些都會比主管的熱情更能說明問題。
Creati.ai 觀點
Salesforce 推出 Slackbot 的意義在於，它把 Slack 從一個帶有 AI 功能的溝通產品，變成企業 AI 介面層更強的競爭者。該公司最有力的論點不是自家模型特別強，而是工作脈絡本來就存在於 Slack 對話、檔案、頻道與串接系統中。如果 Slackbot 能可靠地把這些脈絡轉化為有用的行動，Salesforce 就有一條路徑可防守 Slack 對抗 Microsoft Teams，並讓 Agentforce 顯得實際而非抽象。
但這仍是一個披著成熟軟體外衣的早期產品類別。供應商報告的內部採用數字令人鼓舞，但還不是定論。更大的考驗在於，企業客戶是否會把 Slackbot 視為值得信賴的自動化介面，而不只是另一個助理側欄。在職場 AI 的競賽中，贏家不太可能是能寫出最聰明答案的系統，而是那個在權限、工作流程、合規與後續執行上都足夠契合、足以成為日常營運一部分的系統。Salesforce 透過 Slackbot 已經邁出可信的一步。接下來，它必須在自家牆外證明這一點。
