Slack花3年沒搞定的AI上下文，亞馬遜用47行代碼解決了

Slack用戶平均每4.3分鐘切換一次應(yīng)用。當(dāng)你的團(tuán)隊正在討論季度規(guī)劃，有人拋出一個問題："上個月的AWS賬單 anomaly 在哪？"——所有人開始翻找瀏覽器標(biāo)簽、登錄控制臺、復(fù)制粘貼會話ID。 conversation history 像沙子一樣從指縫漏走。

亞馬遜Bedrock團(tuán)隊最近放出一組 CDK 模板，把這個問題按進(jìn)了馬桶。不是比喻，是真的按進(jìn)去了。他們的解法讓AI agent直接住進(jìn)Slack，且 conversation context 不會丟。

Slack集成的3個隱形殺手

做過Slack bot的開發(fā)者都懂：這事表面簡單，實(shí)際埋雷。Slack的 event request 需要驗證簽名，超時窗口只有3秒，且用戶期待 thread 里的對話能被"記住"。

AWS的方案拆成三塊：API Gateway 接請求，Lambda 做路由，SQS 當(dāng)緩沖墊。關(guān)鍵設(shè)計是把"快響應(yīng)"和"慢思考"解耦——Slack收到"正在處理"的回執(zhí)后，agent在后臺慢慢跑，跑完再推結(jié)果。

超時問題用隊列解決，context 問題用 memory 層解決，身份問題用 Secrets Manager 解決。

這聽起來像標(biāo)準(zhǔn)的云架構(gòu)，但魔鬼在協(xié)議層。AgentCore 用了 MCP（Model Context Protocol，模型上下文協(xié)議），這是 Anthropic 今年初開源的標(biāo)準(zhǔn)，讓 tool 調(diào)用和狀態(tài)管理有了通用語言。

ARM64 容器與"可替換的"agent

整個方案用 CDK 一鍵部署，分成兩個 stack。WeatherAgentImageStack 管鏡像：CodeBuild 編譯 Graviton（ARM64）容器，塞進(jìn) ECR。WeatherAgentCoreStack 管運(yùn)行時：Runtime、Gateway、Memory、Lambda 四件套。

他們拿天氣查詢當(dāng) demo，但特意把 integration layer 和 agent 邏輯剝離開。換句話說，你把 weather tool 換成 Jira、Salesforce 或內(nèi)部數(shù)據(jù)庫，Slack 那端的代碼不用動。

Strands Agents SDK 在這里當(dāng)膠水。這個開源框架對接 Bedrock AgentCore Gateway 拿 tool 權(quán)限，對接 AgentCore Memory 存對話歷史。Runtime 里的 agent 被容器化托管，擴(kuò)縮容由 AWS 操心。

為什么是現(xiàn)在？

Slack 自己也有 AI 功能，但走的是"平臺中心化"路線。亞馬遜這招是"把 agent 塞進(jìn)你的基礎(chǔ)設(shè)施"，數(shù)據(jù)不出 AWS，模型調(diào)用走 Bedrock，合規(guī)團(tuán)隊能睡個好覺。

更隱蔽的賣點(diǎn)是 usage tracking。AgentCore 的身份管理能精確到"誰在什么時間調(diào)用了哪個 agent 的哪個 tool"，這對企業(yè)內(nèi)部結(jié)算和審計是硬需求。

部署文檔里有個細(xì)節(jié)：Lambda 函數(shù)分了三個，分別管 event 接收、異步處理、響應(yīng)回傳。這種"三段式"結(jié)構(gòu)是 AWS 無服務(wù)器架構(gòu)的老套路，但用在對話場景里，恰好卡在 Slack 的 technical constraint 上。

代碼已經(jīng)開源。開發(fā)者拷貝倉庫，改幾個環(huán)境變量，半小時內(nèi)能讓自己的 agent 在 Slack 里說話。至于 agent 是查天氣、審代碼還是調(diào) K8s，那是下一層的事。

Slack 的 3000 萬日活用戶里，有多少人的 workflow 會被這種"嵌入即服務(wù)"的架構(gòu)改寫？Bedrock 團(tuán)隊沒給預(yù)測數(shù)字，但 CDK 模板里的注釋寫得很直白："This integration layer is completely reusable."