整合 Dust 與 GitHub、Zendesk：構建跨系統工單分類與除錯智能體實踐指南

技術支援工程師與技術營運（TechOps）團隊經常面臨跨系統協作的斷層痛點：客戶回饋、SLA 規範與工單流程集中在 Zendesk 中，而程式缺陷、代碼修復、Pull Request（PR）以及工程討論則散落在 GitHub 裡。由於兩個系統各自為政，支援團隊在處理複雜技術客訴時，往往必須在多個視窗間反覆切換，手動在程式庫中搜尋 Issue、核對錯誤日誌、複製堆疊訊息，甚至在 Slack 中來回詢問工程師修復進度，極易造成重複開單與資訊延遲。

Dust（dust.tt）為這一痛點提供了基於企業知識上下文的 AI 協同方案。不同於傳統生硬的欄位同步插件，Dust 將 Zendesk 與 GitHub 接入統一的 AI 智能體編排平台，讓智能體同時具備客戶溝通記錄與研發程式庫的雙重脈絡。藉由這套架構，團隊能夠自動分流新工單、智能比對已知技術缺陷、在服務台中代擬內部排錯筆記，並在確認新 Bug 時自動向研發團隊建立標準化的 GitHub Issue。

本文將解析如何運用 Dust 深度串接 Zendesk 與 GitHub，打造高效率、全閉環的內部支援與技術會診（Triage）流程。

架構解析：Dust 如何串聯技術支援與研發工程

在建立整合流程前，應先釐清 Dust 與外部系統互動的三層核心架構：

這套分層機制確保 Dust 不只是傳遞資料的管道，而是具備推理能力的決策中樞：它能依據 GitHub 的研發進度與代碼脈絡，深度解析 Zendesk 的客訴徵兆，並在受控環境下執行跨系統協作。

第一步：配置全域資料連接（建立知識庫底座）

智能體若要進行準確的故障判斷，必須先取得歷史支援紀錄與研發問題庫的唯讀檢索權限。

1. 配置 Zendesk 資料連接

1. 登入 Dust 工作區，前往 Spaces > Connections，在清單中選取 Zendesk。
2. 輸入機構的 Zendesk 子網域（如 https://<subdomain>.zendesk.com）。
3. 由同時具有 Dust 管理員及 Zendesk 管理員（至少擁有 Support 與 Guide 權限）身分的人員完成 OAuth 授權。
4. 進入連接管理頁面（Manage）自訂同步範圍：
   • 工單範圍與保留期限：Dust 預設僅同步過去 180 天內更新且處於 Solved 或 Closed 狀態的工單，本機保留期限為 120 天。若需比對正在處理中的事故，可開啟 Sync Unresolved Tickets。
   • 個人隱私保護（去識別化）：建議啟用 Hide Customer Information，系統將自動從詮釋資料中移除提單客戶的姓名與電子郵件，僅保留工單正文中的技術內容。
   • 標籤與自訂欄位映射：透過 Included Tags（如設定 tier-2 或 bug）過濾掉非技術性工單。若企業使用自訂欄位標記模組或事故等級，可將欄位數字 ID 填入 Custom Field Tags，Dust 將自動轉換為 fieldName:value 標籤供語意搜尋工具調用。
   • API 頻率限制保護：若 Zendesk 訂閱方案對 API 呼叫有較嚴格的配額限制，可在設定中指定每秒事務數（TPS）上限。

2. 配置 GitHub 資料連接

1. 在 Dust 中點擊 Spaces > Connections > GitHub > Connect。
2. 由 GitHub 組織管理員授權，並挑選允許 Dust 讀取的指定儲存庫（例如核心後端 API、前端 Web 應用與用戶端 SDK）。
3. 視需求勾選 Code synchronization：若希望智能體在排錯時直接檢視預設分支的代碼實作，開啟此功能；代碼預設每 8 小時更新一次，Issue 與 PR 則保持即時增量同步。
4. 儲存設定。Dust 將自動解析 Issue 標題、內文、標籤與提交者，構建結構化的語意檢索庫。

第二步：啟用 Zendesk 與 GitHub 動作工具（Tools）

資料連接賦予智能體「閱讀」能力，而若要代擬工單回覆或自動建立 GitHub 缺陷，則需在工作區啟用相應的 Tools：

1. 前往 Spaces > Tools，點選 Add Tools。
2. 啟用 Zendesk Tools：
   • Search Tickets：支援使用精確查詢語法（如 status:open priority:urgent tags:bug）檢索工單。
   • Get Ticket：擷取指定工單的完整留言紀錄、中繼資料及 SLA 效能指標。
   • Draft Reply：在工單內產生內部私密筆記（Private Comment），對一般客戶完全隱藏，僅供支援專員檢核。
3. 啟用 GitHub Tools：
   • 設定憑證授權模式：建議選擇 Workspace Credentials，智能體執行的所有提單與留言動作將統一以 @dust-agent 官方 Bot 身分留痕，便於稽核追蹤；亦可選用 Personal Credentials，操作將直接對應至觸發人員個人的 GitHub 帳號與儲存庫權限。

第三步：在 Agent Builder 中建立會診智能體

完成底層資料庫與操作工具的配置後，即可在 Dust 的 Agent Builder 中建立專門負責技術支援會診的智能體（例如命名為 @tier2-triage）。

智能體設定要點

• 基礎模型：建議選用長上下文且具備深度技術推理能力的高階模型（如 Claude 3.5 Sonnet、GPT-4o 或 Gemini 1.5 Pro）。
• 掛載知識庫：在 Knowledge 設定中勾選先前建立的 Zendesk 連接（工單與常見問題）與 GitHub 連接（儲存庫與代碼）。
• 賦予工具權限：勾選 Zendesk 的 Search Tickets、Get Ticket、Draft Reply，以及 GitHub 的 Issue 搜尋與建立工具。
• 提示詞設計（Prompt）：明確規範智能體的診斷步驟、查重邏輯與輸出格式。

你是一名專責二線技術支援與問題會診的智能體（Tier-2 Triage Copilot）。你的任務是深入分析傳入的 Zendesk 工單，交叉比對 GitHub 儲存庫中的問題記錄，並提供清晰有力的技術診斷支援。

處理 Zendesk 工單時，請遵循以下流程：
1. 提取工單中的錯誤描述、異常日誌或堆疊追蹤資訊，在指定的 GitHub 儲存庫（預設：dust-tt/app-backend）中搜尋是否存在相符的 Open 或 Closed Issue。
2. 檢索歷史 Zendesk 工單，確認過去是否有類似客戶回報，以及是否存在已獲工程團隊驗證的臨時因應措施（Workaround）。
3. 若找到相符的 GitHub 缺陷：
   - 呼叫 Zendesk "Draft Reply" 工具草擬一則內部私密筆記（Private Comment）。
   - 內容需包含：關聯的 GitHub Issue 連結與當前處理狀態、問題根因簡述、建議回覆客戶的技術說明或暫行緩解步驟。
4. 若確認為尚未被研發建檔的新 Bug 且重現步驟明確：
   - 呼叫 GitHub 工具在目標儲存庫建立新 Issue，標題格式為：[Triage] 問題簡述，內文列出對應的 Zendesk 工單編號、影響環境、重現步驟與完整日誌。
   - 在 Zendesk 工單中發布內部私密筆記，註記新建的 GitHub Issue 編號與分析摘要。
5. 絕不可直接向終端客戶發送公開回覆。所有輸出內容必須以內部私密筆記形式提供，待專員確認後方可發出。

第四步：部署前端操作介面與自動化觸發機制

智能體建立完成後，可依團隊需求採取兩種協同模式：客服專員主動呼叫，或透過 Webhook 實施無人值守自動會診。

模式 A：Zendesk 側邊欄協同助手

1. 前往 Zendesk Marketplace 安裝官方 Dust 應用程式。
2. 進入 Zendesk 管理中心開啟 Dust 應用設定頁面。
3. 貼上由 Dust 管理員產生的 Workspace ID 與 API Key。
4. 在 Default Agent IDs 中輸入剛剛建構的 @tier2-triage 智能體 ID。設定完成後，支援專員點開任何工單時，右側資訊列將預設載入該診斷助手。
5. 確認專員的 Zendesk 電子郵件與 Dust 帳號一致。當專員遇到複雜問題時，可直接在側邊欄詢問：「這個結帳超時錯誤是否已有修復 PR？」，智能體會立即檢索 GitHub 代碼與 PR 討論並產出診斷報告。

模式 B：基於 Webhook 的全自動事件會診

若希望系統在高優先級工單進線時第一時間完成背景診斷：

1. 在 Dust 中依序點選 Spaces > Triggers > Add source。
2. 選擇內建提供者 Zendesk，連結工作區帳號。
3. 進入 @tier2-triage 智能體編輯介面，點選 Triggers > Add triggers，綁定此 Zendesk Webhook 來源。
4. 設定觸發細節：
   • 監聽事件：Ticket Created（工單建立）或 Ticket Updated（工单更新）。
   • 觸發條件：以自然語言輸入過濾邏輯，例如 "priority is urgent or tags contain technical-escalation"。
   • 傳遞載荷：啟用 Include webhook payload，將工單主旨、描述與標籤直接傳入智能體上下文。
   • 頻率防護：設定 24 小時上限，避免突發性事故工單潮耗盡系統額度。
5. 儲存設定。每當符合條件的工單進線，Dust 會在背景自主完成代碼庫比對，並在客服專員打開工單前，就已留下條理分明的內部診斷筆記。

方案效益評估：原生 Dust 智能會診對比傳統同步插件

治理權限、計費規劃與實踐建議

1. 堅持內部私密筆記原則：在任何自動化會診流程中，嚴格限制智能體僅能透過 Draft Reply 產出內部私密筆記，嚴禁直接發送公開訊息給客戶。確保「AI 負責預研與草擬，專員負責最終把關」的資安準則。
2. 精準控制觸發頻率與額度：透過明確的標籤與優先級過濾條件設定 Webhook，避免針對一般性帳號登入、密碼重設等非技術性諮詢濫用高階大模型。
3. 合理配置團隊席位與 Credits：Dust 商業版採自助式訂閱，包括 Pro（年繳每月每席 24 歐元，含 8,000 credits）與 Max（年繳每月每席 120 歐元，含 40,000 credits）；企業版（Enterprise）則提供工作區共用額度池、SCIM 帳號同步、單租戶部署及專屬 SLA。團隊應根據 Webhook 自動化量級與專員側邊欄呼叫頻次，精準規劃額度。

透過將 Zendesk 的服務前線與 GitHub 的研發核心無縫串接，Dust 不僅消除了跨工具搬運資訊的重複勞動，更為技術營運團隊構建出反應迅速、標準統一的現代化技術會診體系。

參考資料

• Zendesk Tools - Dust Docs
• GitHub Tools - Dust Docs
• Zendesk Connection - Dust Docs
• GitHub Connection - Dust Docs
• Dust in Zendesk - Dust Docs
• Webhooks - Dust Docs
• Customer Support - Dust Docs
• Dust Pricing: Business and Enterprise Plans for AI Agents