內部 IT 群組的 AI 客服，何時該回答、何時該讓人接手？

ShipStation Global 在 Slack 裡放了一個 IT 服務台代理，名叫 Deckhand。它替同事從整理過的知識庫回答一般 IT 與公司問題，找不到答案時，會提出釐清問題或建立 IT 工單的選項。這個案例由 ShipStation Global 人員與 AWS 作者共同撰寫，刊在 AWS 部落格上，所以文中的做法與成效，都是企業與供應商共同的說法。

導入前，IT 的答案分散在 Confluence 說明文章、公司內部網頁、PDF、IT 維護指南，還有 Slack 過往的討論串。這些答案各在不同地方，同事要找，就得一處一處翻。案例的做法，是把其中的文章、內部網頁、PDF 與整理過的 Slack 討論串同步進一個知識庫，代理回答時搜尋的就是它。

本文要回答的問題是：內部客服代理要怎麼接上既有知識與工單系統，又不干擾同事、不搶走人工處理的場合？案例的做法可以拆成三個部分：整理知識、訂好群組裡何時說話、何時不說話，以及把答不了的問題接到工單，由使用者確認後才送出。

先把散落的答案整理成代理可以查的資料

代理回答時會搜尋一批整理過的資料，也就是知識庫。Deckhand 的知識庫同步的來源，包括 Confluence 文章、公司內部網頁與 PDF，以及從 Slack 整理出來的已解決支援討論串。原本留在 Slack 過往討論串裡的已解決問題，經過整理後，也能被代理搜尋到。

整理的重點不只是把檔案倒進去。每筆已解決的問題，會記錄問題摘要、原始提問與解法；並標示這個解法是使用者可以自行處理，還是需要開工單。相關的自助步驟、應用程式或系統、錯誤訊息與標籤也會記下來。這樣一來，代理搜尋時能同時看到問題的說法、解法，以及它屬於哪一種處理方式。

舊聊天紀錄要怎麼挑出真正有用的那段，可以參考公司舊聊天能變成 AI 代理的知識嗎？。

群組裡的規則：能回答，也要知道不該插話

員工在 Deckhand 所在的 Slack 頻道發文時，系統會把完整的討論串與使用者的情境一起交給代理。代理搜尋知識庫，必要時呼叫工具。找到答案就回覆；找不到，就提出釐清問題，或提供建立工單的選項。

但群組裡不是每則訊息都要 IT 回答。公告、社交訊息，以及人與人之間的對話，代理會輸出一個叫 SKIP 的訊號，Slack 服務收到後就不把回覆顯示在頻道裡。SKIP 可以理解成代理的「這則不歸我回」。

在討論串裡，代理只回覆原始發文者。如果討論串最後一則回覆來自另一位人類協助者，代理就保持安靜。

這幾條規則的重點，是把「查得到答案」和「該不該回答」分開。代理搜尋到內容，不代表它應該出現在那段對話裡。遇到人已經接手的場合，代理就退開，把處理權交還給人，避免同事之間的對話被插話打斷。

答不了的問題，建單要由使用者按下確認

找不到答案時，代理可以提出建單選項。但建單不是代理單方面送出的：系統會顯示「Create Ticket」按鈕，使用者選取後，才送出確認並進入建單流程。

工單系統是 Jira Service Management，它是 IT 問題的追蹤系統，工單就是需要 IT 人員接手處理的正式紀錄。Deckhand 可以建立及更新這類工單。

工單內容的欄位，來自兩個地方。一是 Slack 服務每次送出請求時，都會附上包含員工個人檔案的情境資料，代理可以據此自動填妥工單細節。二是系統還會另外呼叫一次 AI 模型，把問題整理成結構化的工單欄位，也就是有固定格式、可以逐項寫進工單的內容。

從使用者按下確認，到工單送進 Jira，中間還有一道驗證：任何內容送達 Jira 前，都要先經過 Pydantic 這套驗證工具檢查。

回頭看，導入前要先對上三組條件

把這個案例拆開，主管可以先盤點三組條件。第一組是答案來源：自己的答案分散在哪裡，哪些能整理成問題、解法與處理方式的格式。第二組是群組規則：哪些訊息不該讓代理回，同一串誰接手，接手後代理如何退開。第三組是工單與資料：誰按下建單確認，員工資料會被帶進哪些欄位。少了任何一組，案例裡的做法就少了一塊依據。

三個月的數字，要看定義才能讀

案例列出前三個月的數字：處理 1,935 則訊息，開始 1,221 段代理對話，建立 409 張 Jira 工單。另外，有 812 段對話在聊天中處理，沒有轉成工單。

最容易看錯的是「97.5%」。文章結果段說，代理在前三個月回覆了 97.5% 的訊息；文章開頭則寫，它解決了 97.5% 的進入頻道查詢。兩句用詞不同。回覆一則訊息，不等於問題已經解決。讀這組數字時，應把它當成回覆比例，不要當成解決率。

工時部分，文章以每張工單約 30 分鐘的填寫、處理與結案時間估算。如果把那 812 段在聊天中處理、沒有轉成工單的對話換算成工單工時，三個月約 406 小時，推估每年約 1,600 小時。這是估算，不是已實現的現金節省，讀者也不能直接把它換算成成本。

來源沒有交代的部分

來源沒有交代這套系統的完整導入成本，也沒有提供失敗案例或錯誤回答的分布。來源沒有獨立第三方評估，也沒有非共筆方對 Deckhand 的客戶訪談。

因此，這個案例能說明的是：在 ShipStation Global 這個環境裡，代理怎麼接上知識、群組與工單。它不能推論所有公司都會得到同樣的結果。讀者若要判斷自己的條件，應回到自己的答案來源、群組規則與工單流程，不要把這組數字直接套用。

資訊截至 2026 年 10 月。本文依文末所列公開來源整理，所述成果來自當事企業或供應商的說明，未經獨立第三方驗證。

資料來源

1. AWS 官方部落格：https://aws.amazon.com/blogs/machine-learning/how-shipstation-global-built-an-ai-it-help-desk-on-amazon-bedrock-agentcore/（2026-10-13）