Salesforce推出Slack Code多智能體編程
Salesforce CEO Marc Benioff宣佈，Slack Code正式上線，將開發人員與AI代理置於同一Slack頻道協作，並首批接入Anthropic、GitHub、Cognition和Vercel的代理。
Benioff將該產品定義爲“多人協作編程”：人類開發者可在頻道內提出需求、審閱結果、分配任務和處理異常，AI代理則承擔代碼生成、代碼庫理解、測試、部署或運行環境相關工作。產品意圖是把代碼協作從IDE和工單系統的一對一操作，遷移到可追蹤的團隊通信界面。
首批合作方覆蓋模型、代碼託管、代理式開發與部署鏈條。Anthropic提供Claude相關代理能力；GitHub掌握代碼託管、拉取請求和開發者工作流；Cognition主打自主軟件工程代理；Vercel處於前端應用開發與部署環節。Slack試圖以頻道作爲這些不同代理之間的人機協作與任務編排層。
該產品的關鍵不在於單一模型生成代碼，而在於讓多個工具共享上下文、協作記錄和任務狀態。開發者可在同一對話中保留需求討論、代碼變更、審查意見、測試結果和部署反饋，減少信息在Slack、GitHub、IDE、CI/CD系統及雲平臺之間重複搬運。
Slack Code的推出與Dreamforce同期，顯示Salesforce正把Slack從企業即時通信工具推進爲AI工作入口。若代理能通過受控權限讀取頻道、調用代碼庫、提交變更並反饋執行結果，Slack的價值將從消息分發延伸到軟件開發流程的控制面板。
市場機制上，開發團隊與企業IT部門是協作式AI編程的買方；模型提供商、代碼代理、代碼託管、雲部署和企業協作軟件是供給方。Salesforce可通過Slack席位、企業AI訂閱、合作伙伴分發及工作流增值服務獲得收入；受壓的是僅提供孤立代碼補全、缺少團隊協作入口或無法接入企業權限體系的工具。實際滲透仍取決於代碼安全、訪問控制、審計記錄、代理執行權限和企業採購週期。
來源：公開信息
ABAB AI 解讀
Salesforce在AI產品上的路徑經歷了從Einstein預測模型、Einstein GPT，到以Data Cloud爲數據底座的Agentforce。其收購Slack後，先將其作爲內部協作入口，再試圖把Slack Channel轉爲業務代理的執行界面。Slack Code延續這一策略：Salesforce並不需要自行贏得基礎模型競賽，而是通過連接企業身份、CRM數據、消息流和工作流權限，把外部模型與代理納入自身軟件分發體系。
資本路徑的重點是“入口控制”而非獨佔模型。Microsoft將GitHub Copilot嵌入GitHub、VS Code和Azure；Amazon用Bedrock、CodeWhisperer及AWS開發工具連接模型和雲資源；Google把Gemini嵌入Cloud、Workspace和Android生態。Salesforce選擇與Anthropic、GitHub、Cognition及Vercel合作，意味着它嘗試成爲多代理調度層：客戶在Slack內發起任務，模型、代碼工具和部署平臺在後臺競爭執行份額，而Slack掌握對話、權限與組織關係。
歷史類比可參考Jira與GitHub改變軟件交付管理的過程。Jira把需求、缺陷和項目管理標準化，GitHub把版本控制、代碼審查和開源協作網絡化；Slack Code試圖將“需求提出—代碼生成—審查—部署—反饋”壓縮進實時頻道。行業正從輔助編程階段進入代理協作階段，但代理生成的代碼一旦能夠觸發生產部署，團隊協作工具便必須承擔審批、責任歸屬和審計功能，而不只是聊天界面。
本質屬於產業鏈重構。過去開發工具鏈的價值分散於IDE、代碼託管、項目管理、測試和雲部署；代理式編程將這些環節連接爲連續執行鏈，價值向擁有身份權限、工作上下文和任務分發權的平臺集中。Slack若成爲企業中代理接收指令和回報結果的默認界面，Salesforce就能重新掌握開發工作流的一部分入口；但若GitHub、Microsoft Teams或AI原生IDE控制更深的代碼與部署上下文，Slack的協調層地位將受到限制。
ABAB News · 認知定律
AI代理越多，調度入口越值錢
寫代碼會商品化，控制部署纔有權力
協作工具的終局不是聊天，而是執行