ShipStation Global 如何以 Amazon Bedrock AgentCore 打造 Deckhand AI IT 服務台

本文由 ShipStation Global 的 Kenneth Salmon、Edward Boswell、Jack Armstrong、Robert Bahn 和 Nick Ciubotariu 共同撰寫。

回答相同的 IT 問題和處理例行工單，會耗費 IT 團隊原本可用於其他工作的時間。為了騰出這些時間，ShipStation Global 工程團隊基於 Amazon Bedrock AgentCore，為 Slack 建立了由 AI 驅動的 IT 服務台 Agent Deckhand。

ShipStation Global 是領先的智能寄件及物流平台，服務中小型寄件商。公司的理念很簡單：團隊效率越高，就越能為客戶提供更佳服務。Deckhand 正是這個理念的實踐。它利用精選知識庫回答常見的 IT 及公司問題、讀取錯誤訊息的螢幕截圖，並建立及更新 Jira Service Management 工單。

本文會探討 ShipStation 如何設計 Deckhand。這套系統成功解決了 97.5% 的頻道提問，並獲員工給予 96% 的正面回饋評分（圖 1）。

圖 1：三個月的頻道覆蓋及正面回饋

業務挑戰

Deckhand 要解決的問題，每個 IT 團隊都熟悉：相同問題不斷有人提出、有人在辦公時間以外發佈錯誤訊息，而且所需資訊分散在不同團隊。在 ShipStation Global，這些對話都集中在一個繁忙的 Slack 服務台頻道。員工提出問題，IT 團隊則逐條對話串作答。答案通常早已存在於 Confluence 教學文章、公司內聯網頁面，或八個月前的對話串中。真正困難的是找到答案。

頻道數據清楚呈現了問題的規模。在 Deckhand 推出前的 12 個月內：

員工發佈了超過 1,500 條對話串，而且數量持續增加。
員工分佈於美國、英國、西班牙、波蘭、澳洲和菲律賓，超過五分之一的問題在美國辦公時間以外提出。
答案散落在不同地方：Confluence 文章、內聯網頁面和 PDF、由 IT 團隊維護的指南，以及頻道本身的歷史訊息。
重複問題耗用了不少時間，而有系統的自助服務流程本可處理這些問題。

「我們建立 Deckhand，是因為尋求協助應該像在 Slack 提問一樣簡單，而不必費力解讀工單表格，或發出電郵後石沉大海。我們認為，工單反映的是營運阻力，而非生產力。Deckhand 能即時解決常見問題；遇到無法解決的情況時，只需按一下，就能把對話轉換成具備完整背景資訊的工單，改善員工體驗，亦讓團隊不必再無休止地重複説：『請提交工單。』」

— ShipStation Global 資深 IT 總監 Chris Collins

解決方案概覽

Deckhand 在 Slack 中的運作方式就像任何隊友：加入頻道、閲讀對話，並從 Slack 個人檔案取得背景資訊，直接在頻道內回答 IT 問題。我們在 Amazon Bedrock AgentCore 上運行 Deckhand。這個平台可使用任何框架或模型，大規模建置、連接及優化 Agent。AgentCore runtime 是 Amazon Bedrock AgentCore 的一項功能，可在隔離的工作階段中託管 Agent，因此我們毋須運行任何伺服器或容器。

解決方案由四個主要部分組成，如圖 2 所示：

Slack 服務： 以 FastAPI 和 Slack Bolt 建構的應用程式，託管於 AWS App Runner。它會接收 Slack 事件、判斷機械人是否應作出回應，並根據提出請求者的 Slack 個人檔案建立用戶上下文 payload，當中包括姓名、電郵、時區及主管。
Agent 服務： Strands agent 以容器形式部署於 Amazon Bedrock AgentCore runtime，使用 Amazon Bedrock 中 Anthropic 的 Claude 管理多輪工具 Agent 循環。
工具與知識： 單一 AWS Lambda 函數透過 AgentCore Gateway（Amazon Bedrock AgentCore 的一項功能）以 Model Context Protocol (MCP) 工具形式提供，可分類請求、建立及更新 Jira 工單，以及分析圖像。Amazon Bedrock knowledge base 會為 Confluence、公司內聯網、Slack 及市場推廣頁面的內容建立索引，並將內容儲存在 Amazon Simple Storage Service (Amazon S3)。
營運與意見回饋。 Amazon DynamoDB 儲存意見回饋，AWS X-Ray 使用 OpenTelemetry 追蹤請求路徑，而各項服務則將記錄寫入 Amazon CloudWatch。

圖 2：架構圖顯示 Slack 事件進入 Slack 服務及 Amazon Bedrock AgentCore runtime，並分別連接至 Amazon Bedrock knowledge base、由 AgentCore Gateway 支援的 Lambda 工具、Jira Service Management 及 DynamoDB 意見回饋。

當員工在 Deckhand 所屬的頻道發佈訊息時，Slack 服務會整理完整的對話串記錄及用戶上下文，然後透過 AgentCore runtime API 呼叫 Agent。Agent 會搜尋知識庫，並按需要呼叫工具。找到答案時，Agent 會傳回最終回覆（圖 3）；找不到答案時，則會提出澄清問題或建議建立工單（圖 4）。

圖 3：Deckhand 提供自助處理步驟

圖 4：Deckhand 提議建立工單

Deckhand 工作流程

本節會逐步介紹 Deckhand 的實作方式，從先決條件到完成部署。

先決條件

要實作此模式，你需要具備以下條件：

可使用 Amazon Bedrock、AgentCore runtime 及 AgentCore Gateway 的 AWS 帳戶。
已設定事件訂閲、簽署密鑰及符合使用情境之 Bot token 的 Slack app。
容器映像檔登錄庫，例如 Amazon Elastic Container Registry (Amazon ECR)。
Amazon S3 儲存貯體及 Amazon Bedrock knowledge base。
為各 runtime 和工具設定適用權限範圍的 AWS Identity and Access Management (IAM) 角色，以及用於第三方憑證的 AWS Secrets Manager 項目。

使用 Strands Agents 和 AgentCore 建構 Agent

這個 Agent 刻意採用輕量設計。使用開源的 Strands Agents SDK，Agent 由模型、一組工具及系統提示詞組成。SDK 會管理推理循環，讓模型選擇工具、處理結果，並反覆執行，直至產生答案。Deckhand 的 Agent 服務只需少量 Python 程式碼即可實作。

from strands import Agent
from strands.models import BedrockModel
from strands.tools.mcp import MCPClient
from strands_tools import retrieve
from mcp.client.streamable_http import streamablehttp_client

model = BedrockModel(
    model_id=MODEL_ID,
    max_tokens=2048,
    temperature=0.3,
)

gateway = MCPClient(lambda: streamablehttp_client(url=GATEWAY_URL))

agent = Agent(
    model=model,
    tools=[gateway, retrieve],
    system_prompt=SYSTEM_PROMPT,
)

模型 ID 透過環境變數設定，因此無須修改應用程式程式碼即可切換模型。

工具透過兩種方式與代理程式整合。Amazon Bedrock Knowledge Bases 檢索是 Strands 的原生工具，只需匯入一次即可搜尋知識庫。其他功能，包括分類、工單管理、用戶識別及圖像分析，則由在 AgentCore Gateway 上註冊的 Lambda 函式處理。Gateway 將這些功能公開為 MCP 工具，而 Lambda 會按工具名稱路由每次呼叫。這種分離方式可讓工具邏輯獨立更新，代理程式亦可透過 Gateway 使用新工具，無須重新建置。

AgentCore runtime 以容器形式託管代理程式，無須管理伺服器或工作階段。Slack 服務會就每則訊息同步呼叫代理程式，提供對話串記錄及用戶背景資料，並發佈最終回覆。由於每次請求都會附上背景資料（包括員工個人檔案），代理程式可自動填寫工單詳情。

知識庫設計與答案路由

Deckhand 透過單一 Amazon Bedrock 知識庫提供答案，主要資料來源均由 S3 提供支援：

從 Confluence 同步的文章。
從公司內聯網同步的內部網頁、PDF 文件及活動資訊。
從 Slack 挖掘的已解決支援對話串（下一節會介紹）。

每份文件都包含標題、來源網址、內容類型及活動日期等中繼資料。這讓代理程式可以篩選內容，例如在用戶詢問即將舉行的活動，或 Austin 辦公室每週午餐餐單時，找出相關資訊。

使用遞迴語言模型（RLM）挖掘 Slack 歷史記錄

最有價值的資料來源，是已解決支援對話串的存檔。在 Deckhand 出現之前，Slack 一直是解決問題的地方：多年來，員工在 Slack 描述問題，IT 人員則逐步指導他們排除故障。這段歷史自然累積成一個知識庫，並由最理想的審核者——問題得到解決的當事人——驗證。不過，當中也有不少雜訊：原始匯出內容混雜閒談、自動警示，以及實際上從未解決的對話串。若將未經驗證的解決方法或錯亂的摘要編入索引，知識庫就可能以與正確答案同等的信心顯示錯誤答案，因此資料萃取必須精確。

挖掘流程分為三個階段（圖 5）：

指令碼透過 Slack API 匯出頻道的完整歷史記錄，擷取每個對話串的所有回覆，並寫入結構化資料檔，其中包括對話串標記、時間戳記及回覆數量。
DSPy 的遞迴語言模型（RLM）在 Amazon Bedrock 上執行 Claude，並在沙盒化的 Python 讀取－求值－輸出循環（REPL）環境中，把匯出資料視為可導覽的記憶空間，而非單一提示詞。模型會反覆處理數據，將每個對話串分類為已解決、未解決或已升級，並篩走公告及非疑問內容。嚴格的準則有助維持品質：只有當對話串本身清楚顯示完整且可行的解決方法時，才會將其視為已解決。
對於每個已解決的討論串，RLM 會協調遞迴呼叫子大型語言模型（LLM），擷取結構化欄位，並逐一使用 Pydantic 模型驗證。欄位包括問題摘要、原始問題和解決方法，亦會記錄修正方法是可自行處理還是需要建立支援單、自助處理步驟、涉及的應用程式和系統、錯誤訊息及標籤。如果子 LLM 呼叫傳回的內容不符合結構描述，RLM 以程式碼實作的迴圈便會在直譯器中捕捉驗證錯誤並重試。結果會寫入一份按問題分類的 Markdown 文件。處理流程會將文件上載至 Amazon S3，供知識庫編製索引。

圖 5：Slack 對話匯出的分類及擷取工作流程

我們選用 RLM，因為它會在持續存在的沙盒變數空間中保留完整的 Slack 歷史記錄，讓系統可以反覆推理匯出內容，並確保輸出結構一致。因此，當員工遇到同事曾經解決的問題時，Deckhand 便會提供已驗證有效的解決方案，通常會以可直接跟隨的編號步驟呈現。

知道何時不應回答

在共用頻道中，AI 機械人往往會先在社交層面出問題，才在技術層面出錯。Deckhand 最成熟的邏輯，是判斷何時應保持沉默：

代理程式每次收到訊息時，首先會判斷該訊息是公告、社交訊息，還是人與人之間的對話。如屬上述情況，它會輸出「SKIP」，Slack 服務便會隱藏回覆。
在討論串中，它只會回覆原始發訊者。
如果最近一則回覆來自另一位人類協助者，它便會保持沉默，因為已有真人接手。
如果回覆以 @提及某人開頭，該訊息就不是發給機械人的。

收集意見

每個答案都附有意見回饋按鈕。系統會直接記錄讚好；如果用戶按倒讚，則會顯示簡短的「出了甚麼問題」欄位。評分會連同原始問題和機械人的回覆一併儲存在 DynamoDB。

負面意見回饋是寶貴的數據集，可用於改善系統提示詞及代理程式行為，並更新知識庫中不正確的資訊。

安全及驗證

提示詞規則有助改善行為，但不能取代存取控制。執行管控由程式碼和基礎架構負責：

建立支援單必須取得明確確認。當 Deckhand 提議建立支援單時，Slack 服務會加入 建立支援單 按鈕；用戶選取後，代理程式便會發出確認。支援單更新只接受符合服務台專案格式的有效鍵值，並會拒絕空白留言。
執行分類前會先進行驗證。請求分類會透過獨立的 Amazon Bedrock Converse API 呼叫執行，傳回結構化支援單欄位；這些欄位會先經 Pydantic 驗證，才會送至 Jira。
圖像工具只可從 Slack 的檔案主機下載檔案。工具會使用機械人權杖進行驗證，每次請求最多處理五張圖像，每張不超過 5 MB，並透過 Converse API 將檔案傳送至視覺模型。
憑證不會寫入程式碼。Slack 權杖、簽署密鑰和 Jira 憑證均儲存在 AWS Secrets Manager；每項服務和工具則使用各自具有限定範圍的 IAM 角色執行。
提示詞會強制執行行為防護措施：絕不索取密碼或多重驗證（MFA）代碼、絕不在支援單留言中寫入憑證，也絕不透露用於支援單欄位的個人資料中繼資料。

成果

Deckhand 於 2026 年 4 月推出。最初每日約處理 30 則訊息，到初夏時增至每日最多 100 則。在推出後首三個月，它處理了 1,935 則訊息，啟動了 1,221 次 Agent 對話，並開立了 409 張 Jira 工單。它回覆了 97.5% 的訊息。三分之一的問題在非辦公時間提出，當時 IT 團隊沒有成員當值，而 Deckhand 回覆了其中 94% 的問題。原本要等到翌日早上才會得到回覆的用戶，當晚便收到了答案。

團隊持續改進系統，評分亦有所提升。正面評分由 4 月的 82% 升至 6 月的 96%；團隊修訂系統提示詞和知識庫，處理用戶提出的問題。

最明顯的成效是減少了工單。一段 Agent 對話，指的是原本會變成 Jira 工單的問題。在 1,221 次對話中，只有 409 次最終變成工單，其餘 812 次則在聊天中處理。開立工單，再進行處理並關閉，約需 30 分鐘。這 812 次對話在三個月內合共節省約 406 小時，換算下來每年約 1,600 小時。員工可把這些時間用於自己的工作，IT 團隊亦無需花時間處理工單登記。

結論

Deckhand 減輕了員工處理重複 IT 問題的負擔，讓員工和 IT 團隊都能騰出時間。它之所以奏效，是因為技術堆疊的每個部分各司其職，並以受管理服務方式運行：AgentCore runtime 用來託管 Agent，AgentCore Gateway 將 Lambda function 轉換為 Agent 可呼叫的 MCP 工具，而 Amazon Bedrock Knowledge Bases 則負責檢索。團隊無需架設伺服器或維護協調程式碼，便完成了部署。

如要建置類似的方案，請先準備妥善維護的知識來源，並清楚界定要執行的操作。如要開發 Agent，請參閲 Amazon Bedrock AgentCore 文件和 Strands Agents SDK；如要連接內容來源，請參閲 Amazon Bedrock Knowledge Bases 文件。

如要討論適用於貴機構的代理式 AI 使用案例，請聯絡 AWS 客戶團隊。

作者簡介

Kenneth Salmon

Kenneth 是 ShipStation Global 的軟件工程師，專長是整合、工作流程自動化及 AI 驅動系統。他的工作重點是運用應用式 AI、大型語言模型和對話式 Agent，解決複雜的營運挑戰。

Edward Boswell

Edward 是 ShipStation Global 的高級軟件工程師，專長是 AI 應用程式和快速原型開發。他熱衷於運用 AI 消除營運瓶頸，提升團隊效率。工作以外，Edward 曾是職業魔術師，喜歡在會議上表演助興。

Jack Armstrong

Jack 是 ShipStation Global 的高級軟件工程師。他精通多種程式語言，熟悉 Python、TypeScript 等語言，並具備豐富的軟件工程系統知識，尤其熟悉 Amazon Bedrock。

Robert Banh

Robert 是 ShipStation Global 的工程總監，負責帶領一支專注於在各部門部署 AI 的 SWAT 團隊。他熱衷於解決問題，並運用數據推動切實可行的改進。

Nick Ciubotariu

Nick 是 ShipStation Global 的首席技術總監。二十多年來，他一直負責推出企業級軟件和 AI 系統，這些系統服務數以億計的人。

Ravi Kashyap

Ravi 是 AWS 的資深解決方案架構師，與零售及電子商務公司合作，協助建立、擴展及優化雲端和 AI 工作負載。他專注於自動化及應用 AI，並積極貢獻開源項目，回饋開發者社羣。