公司舊聊天能變成 AI 代理的知識嗎？先找出真正解決問題的那一段
以 Deckhand 案例解釋如何從舊聊天辨認已解決問題、保留解法的適用條件，並安排代理答不了時的後續處理。
公司若想讓 AI 代理協助回答內部問題，規章與操作手冊是可用的資料來源。但有些實際解法沒有寫進手冊，而是留在同事的聊天裡：誰遇到問題、試過哪些方法，最後怎麼處理。這些對話值得保留，卻不適合不分青紅皂白地全部當成標準答案。
這裡說的 AI 代理，是會查找公司資料、回答問題，必要時還能透過工具接續工作的助手。若想先了解代理為什麼需要查公司資料，可以接著讀企業 AI 知識庫入門。
它要用好聊天紀錄，關鍵在於先辨認「哪一段真的解決了問題」，再整理出適用條件與處理方法。否則，過去的一句猜測，也可能被它拿來回答今天的同事。
亞馬遜雲端服務（AWS）與物流軟體公司 ShipStation Global 在 2026 年 10 月共同發表的 Deckhand 案例，提供了一個具體做法。依案例描述，這個 IT 助手會在 Slack 這種公司團隊通訊工具裡回答問題，使用的知識包含公司文件及整理過的已解決對話。找不到答案時，它會追問，或提供建立工單的選項：把問題正式記錄下來，交給 IT 人員追蹤處理。案例使用的 Jira Service Management，就是這類 IT 問題追蹤系統，後文簡稱工單系統。
先分清「有人回答」與「問題解決」
以下是假設的公司群組對話，用來說明怎麼辨認真正有效的解法：
小林：我打不開共用資料夾。 同事甲：重新登入試試？ 小林：試了，還是不行。 IT 同事：你剛調部門，帳號還沒加入新部門的存取群組。我已調整，請再試一次。 小林：現在可以開了。
若只留下第一個建議，就可能把「重新登入」記成解法。完整讀完才知道，在這段對話裡，真正有效的是調整帳號權限。而且這件事是由 IT 處理，不能改寫成一般員工自行操作的步驟。
Deckhand 案例的整理方式，正好處理了這種差別。它先匯出完整討論串及回覆，再把對話分成已解決、未解決或已轉交處理，排除公告與非提問內容。列為已解決的條件，是對話裡能看見完整、可實行的解法。
這個條件並不保證解法永遠正確；它的作用，是避免把尚未確認的建議，和已有結果的處理方法混在一起。
把對話整理成「什麼情況，該怎麼處理」
篩出已解決對話之後，下一步不是替整段聊天寫一篇漂亮摘要，而是把之後回答問題需要的資訊留下來。
整理後的文件會放到 Amazon S3，再供知識庫建立搜尋索引。S3 是 AWS 提供的雲端檔案儲存服務；可以把它理解成這批知識文件的存放處。
案例中的整理欄位包含問題摘要、原始問題、解法、可自行處理的步驟，以及是否需要建立工單，也記錄涉及的系統與錯誤訊息。
把前面的對話整理起來，至少應看得出以下關係：
| 要留下的資訊 | 前面這段對話該記什麼 |
|---|---|
| 發生什麼事 | 調部門後，無法開啟新部門的共用資料夾 |
| 已試過什麼 | 重新登入，問題仍在 |
| 真正的處理方式 | IT 調整帳號所屬的存取群組 |
| 結果 | 員工確認可以開啟 |
| 誰能處理 | 需交由有權限的人員處理，不是請員工自行取得權限 |
這樣整理，保住的是解法與情境之間的關係。下一位同事若也說「資料夾打不開」，代理應先確認是否有相似情況，而不是直接把每個人的問題都歸因於調部門。
案例也使用程式檢查整理結果是否符合預定欄位。這能幫忙攔下格式不合的輸出，但欄位完整不等於內容正確：如果把「重新登入無效」整理成「重新登入即可」，表格再整齊，解法仍然寫錯。這是閱讀這類自動整理流程時，要另外留意的品質問題。
代理的下一步，也需要安排
整理好的知識，不應只告訴代理「可以回答什麼」，也要讓它知道何時應停下來補問，或把問題交出去。
Deckhand 找到答案就回覆；找不到時，會提出澄清問題，或提供在工單系統建立紀錄的選項，讓問題接續交給人處理。
回到共用資料夾的問題：如果尚未知道是哪個資料夾、錯誤訊息是什麼，較合理的回應是先問清楚；若需要人員調整權限，就應把相關資訊交給能處理的人。把查詢、追問與人工處理接起來的安排，也可以參考AI Agent 工作流程。
過去解決過，今天仍要確認適不適用
歷史對話能證明某個情境下曾有這種處理方式，不能單靠它保證今天仍適用。因此，整理聊天時也要安排後續修正。
Deckhand 的回答設有回饋按鈕，負面回饋會收集出錯原因，用來調整代理行為與知識內容。案例使用 AWS 的 Amazon Bedrock 知識庫服務，讓代理從文件中找答案。這項服務的文件說明，資料來源新增、修改或刪除檔案後，需要重新同步，更新才會反映到知識庫。
企業也不能忽略誰能查到這些內容。AWS 的 S3 知識庫連接文件提醒，同步進去的資料可能包含原本受限的內容，而具有知識庫檢索權限的人可檢索這些資料。原聊天頻道有存取限制，不代表搬進另一個知識庫後就自然沿用相同限制。
若要評估自家的舊聊天是否值得整理，可以先挑一個已解決問題，問三件事：看不看得出真正有效的解法？知不知道誰有權執行？日後方法改了，有沒有人負責更新？
這三件事清楚了，聊天紀錄才比較有機會從「有人記得曾經談過」，變成代理能引用、同事能判斷是否適用的工作知識。
資料截至 2026 年 10 月 16 日。本文依 AWS 與 ShipStation Global 共同發表的案例及官方文件整理，編輯部未實測。
