您已經建置好了代理程式。它可能存在於某處：一個 LangChain 鏈結、一個 Azure Foundry 部署、一個 Slack 機器人。您的使用者則在 Teams 中。Teams 是大多數企業工作發生的場域：決策在此做出、客戶在此獲得回應、專案在此推進。在建置任何 Teams 特有的功能之前，將您的代理程式導入該情境，本身就已極具價值。
這歸結於 Teams TypeScript SDK 中的一個模式：HTTP 伺服器介面卡。您將它指向您的 HTTP 伺服器，它會註冊一個訊息傳遞端點，而您現有的伺服器則能維持原樣繼續運行。下方的案例涵蓋了三種不同的起始點：一個 Slack 機器人、一個 LangChain 鏈結，以及一個 Azure Foundry 代理程式。
SDK 還會處理您不想費心處理的部分：它會在呼叫您的處理常式之前，驗證每一筆傳入的請求是否確實來自 Teams，並自動將訊息路由到正確的事件處理常式。
本文中的每一個範例都遵循相同的「三步驟」架構：
SDK 會將 POST /api/messages 路由注入您現有的 Express 應用程式。/api/messages 是 Teams 用來將訊息傳遞給您的機器人的眾所周知端點，也是您的 HTTP 伺服器需要具備的 Teams 介面。
您的伺服器依然是您的；Teams SDK 僅新增了這個端點。
您有一個使用 Bolt 建置的 Slack 機器人（或任何其他以 Web 服務形式部署的機器人）。您的團隊同時使用 Slack 和 Teams。與其維護兩個程式碼庫，不如讓兩者運行在同一個 Express 伺服器上。
ExpressReceiver 讓 Bolt 可以掛載到您的 Express 應用程式上，而不是獨佔伺服器。Teams SDK 也做同樣的事情，因此兩個平台共享同一個處理程序。
兩個平台運行在同一個處理程序中。Slack 訪問 /slack/events，Teams 訪問 /api/messages，任何共用的代理程式邏輯（LLM 調用、資料庫查找、業務規則）都存在於簡單的函式中，供兩個處理常式調用。
您有一個 LangChain 鏈結。您希望 Teams 使用者能夠與之互動。
您的鏈結會在收到每則訊息時運行。在 LLM 回應之前，會先觸發輸入指示器，讓使用者知道有事情正在發生。
您有一個部署在 Azure AI Foundry 中的代理程式。Teams SDK 會將訊息傳遞給您；您將其轉發給 Foundry 並傳達回覆。
Python SDK 也可供使用。同樣的三步驟模式也適用於 FastAPI 和其他 ASGI 框架。
請參閱「自我管理您的伺服器」以取得完整的 Python 指南。
所有三個案例都共享相同的註冊步驟。
步驟 1：為您的本機伺服器取得公開 URL。
Teams 需要透過 HTTPS 連線到您的機器人。對於本機開發，Dev tunnels 是推薦的選項 — 它內建於 VS Code 和 Azure CLI 中。ngrok 也適用。無論哪種方式，您都會獲得一個類似 https://abc123.devtunnels.ms 的 URL，它會轉發到您的本機埠。
步驟 2：使用 Teams Developer CLI 註冊您的機器人。
這會在一個指令中處理 AAD 應用程式註冊、用戶端密碼生成、資訊清單建立和機器人設定。您的 .env 會自動填入 CLIENT_ID、CLIENT_SECRET 和 TENANT_ID。
步驟 3：將應用程式側載到 Teams。
在 teams app create 指令執行後，請依照 CLI 輸出中的側載說明，在您的 Teams 用戶端中安裝該應用程式進行測試。
本文中的每個案例都遵循相同的架構，因為 SDK 是圍繞一個核心理念建置的：您的伺服器是您的。介面卡是您現有基礎設施與 Teams 之間的連接點。無論您運行的是 Express 還是任何其他 HTTP 伺服器，SDK 並不在乎底層是什麼。它只需要一個能夠註冊路由並處理請求的伺服器。
如果您已經在某處運行了機器人，將其整合到 Teams 只需要幾行粘合程式碼。完整文件請參閱「自我管理您的伺服器」。