AI Discord 工單機器人：先回答再升級（免寫程式）

Quickchat AI 會從你自己的文件，在 Discord server 中回答支援問題，只有在無法回答時才開啟私人 ticket thread。本指南會從頭到尾建立這個 bot，不需要寫程式，大約半小時完成。

結果會像好的第一線 agent 一樣運作。member 詢問如何重設 API key，並在 channel 中取得實際步驟。member 詢問文件未涵蓋的內容時，bot 不會猜測，而是明確說明，開啟私人 thread，把該 member 加入其中，以一行摘要 ping 你的 support role，並把對話交給可從 Inbox 回覆的真人。

選擇你的 Discord bot 要執行的工作

此建置會回答支援問題，並升級文件中的缺口。固定問候請選擇歡迎指南，管理員命令請選擇審核指南。

你需要兩樣東西：

• 一個 Quickchat AI Agent（建立你的帳號）
• 一個你是 admin 的 Discord server

從註冊到第一次支援測試

1. 如果你用 email 和密碼註冊，請開啟 email 中的驗證連結。在設定中描述一個 Discord 支援 Agent，點選 Create my AI Agent，並完成設定步驟，包括為預期用途選擇方案。
2. 在 Knowledge Base 下加入你的文件。在 External Apps 中開啟 Discord，接著 Use your own Discord app，並選擇 Advanced setup。共用的一鍵 bot 可以回答問題，但不能執行本指南中的 ticket Actions。
3. 在測試 server 中建立 ticket channel 和可 mention 的 support role。在 Actions and MCPs 中點選 Add Action，選擇 Discord Action，並使用該 server、channel 和 role 安裝 Open Support Ticket。
4. 套用下方 Agent instructions 後，@mention 你的 bot，先問一個文件能回答的問題，再問一個不能回答的問題。第一個應該取得答案且不開工單；第二個應該開啟一個私人 thread 並通知 support role。對第二段對話加入後續訊息，確認不會開啟重複工單。

Free 方案適用於個人、非商業用途。將 bot 用於商業前，請選擇付費方案。邀請客戶前請完成雙路徑測試。

以下截圖來自名為 Lumen 的測試 Agent，它是虛構產品分析公司 Beacon 的支援 bot。公司是虛構的，因此範例保持中立，但此處顯示的每段對話、每個 API call 和每個 ticket thread，都是由真實 Agent 對真實 Discord server 執行真實回覆管線所產生。

你會建立什麼

每個問題做一次決策。在理想路徑上，完全不會寫入 Discord。

三個 AI Actions 負責升級工作，Quickchat AI 會從一張 gallery card 安裝全部三個：

什麼是知識庫，為什麼它會決定你的工單量？

如果你以前沒有建立過 AI Agent，這是值得花兩分鐘理解的一個概念。

知識庫是你自己的文件，載入 Agent 並建立索引，以便在對話期間搜尋。你可以把 Quickchat AI 指向 help-docs URL 讓它抓取頁面、手動貼上文章，或上傳檔案。回覆時，Agent 會搜尋知識庫，並根據找到的內容回答，而不是根據底層模型碰巧記得的世界知識。如果你從零開始，如何建立 chatbot knowledge base 說明該寫什麼，以及寫作順序。

文件涵蓋的一切都會被回答。文件未涵蓋的一切都會變成工單。

這就是此建置的整個槓桿。Deflection 不是 prompt 技巧，也不是模型能力：它是你的涵蓋範圍。如果 bot 升級的問題比你預期更多，工單正在告訴你哪些頁面還沒寫。

這是示意，不是量測結果。重點是方向：撰寫文件是這裡槓桿最高的工作。

AI 真的可以在 Discord 回答支援問題嗎？

對於文件涵蓋的問題，可以，而且會提供實際步驟，而不是改寫摘要。以下是測試 server 中未經編輯的 deflection 案例：

在 channel 中從知識庫文章回答。沒有建立工單，因為不需要。

更重要的是答案不存在時會發生什麼。bot 會明確說明：

誠實的失敗。Beacon 的知識庫刻意省略企業 SSO，因此這是會開啟工單的路徑。

會編造合理 SSO 流程的 Agent，比會開工單的 Agent 更糟，因此這種行為值得刻意測試，而不是期待它自然發生。我們會在測試回到這一點。

連接 Discord 的兩種方式，以及為什麼工單需要第二種

Quickchat AI 有兩種 Discord 連線，開始前必須理解差異。

如果需要可與共用 bot 搭配的公開 feedback queue，請參閱回饋與文件缺口工作流程。下方的私人工單 Actions 需要你自己的 Discord bot credential。

One-click 是快速路徑。在 External Apps 中開啟 Discord，點選 Add to your Discord server，授權後，共用 Quickchat AI bot 大約一分鐘內就會在 server 上線。members @mention 它或使用 /ask 時，它會回答；對許多 servers 而言，這就是全部工作。

你可以為它命名。授權前有一個 Bot name in the new server 欄位，預填你的 Agent 名稱；每個已連接 server 都保有自己的 Bot name in this server 方塊，可稍後變更。這是 Discord 暱稱，因此按 server 設定，上限 32 個字元；清空後會回到 Quickchat AI。共用不變的是 avatar 和底層 @username，因為同一個 Discord application 服務每個安裝它的 server。

一鍵不代表通用。bot 會把你的 Agent 名稱帶進 server，之後也可以按 server 變更。

Advanced setup 會註冊你自己的 Discord application。你在 Discord developer portal 建立 bot，並把 token 貼到 Quickchat AI 一次。這大約需要十分鐘，會讓你擁有自己的 avatar 和 @username、direct messages、同一個 server 中的多個 bots，以及本指南需要的東西：Discord API Actions。

原因值得明確說明，不應視為怪癖。本指南中的 ticket Actions 會使用 Quickchat AI 在送出時注入 request 的 credential，以你的 bot 身分呼叫 Discord API。共用一鍵 bot 的 token 屬於共用 bot，不屬於你，因此無法提供給你的 Actions 送出。如果你在尚未連接自己的 app 時開啟 Discord gallery，它會告訴你原因並停用 cards，而不是讓你建立無法執行的東西。

External Apps 是兩條路徑的起點。Advanced setup 位於 Discord 面板底部的 callout。

開始前需要什麼

連接你自己的 Discord app。 在 External Apps 中開啟 Discord，找到 Use your own Discord app 並選擇 Advanced setup。在 Discord developer portal 建立 application 和 bot，開啟 Message Content Intent，保持 Require OAuth2 Code Grant 關閉，並貼上 bot token。Quickchat AI 會在你輸入時驗證。如果你以前沒做過，建立 AI Discord bot 指南詳細說明 portal 端設定。

只授予支援 bot 需要的權限。 在 ticket channel 上：View Channels、Send Messages、Read Message History、Create Private Threads、Send Messages in Threads 和 Manage Threads。它不需要 Kick、Ban 或 Timeout permission，測試 server 中也刻意沒有這些權限。支援 bot 沒有審核的理由，未持有的權限也就不必推理其風險。

在 Discord 中建立 Actions 會指向的兩樣東西。 這部分在 Discord client 中完成，不在 Quickchat AI 中，也是你唯一需要在 Discord 做的設定：

1. 工單會開啟的 channel。 任何 text channel 都可以。使用 channel list 旁的 +，或重用現有 channel。測試 server 中是 #support。
2. 工單開啟時要通知的 role。 Server Settings，接著 Roles，接著 Create Role。測試 server 中是 @support。

三個位置，其中只有一個是公開的。

這兩項會在 Step 3 回來。安裝 ticket template 時，Quickchat AI 會即時從 Discord 讀取你的 server，並顯示三個下拉選單，其中一個是 Role picker，列出找到的 roles。你會在那裡選擇 support role，而不是在任何地方輸入 ID。

Step 3 中的 Role picker。它從 Discord 讀取清單，因此你現在建立的 role 很快就會出現在這裡。

如果略過這點就會踩到一個細節：該 picker 只列出 Discord 回報為 mentionable 的 roles，並排除 @everyone。如果你的 support role 沒有設為 mentionable，它就完全不會出現在下拉選單，也不會說明原因。這個篩選是刻意的，因為範本的整個工作就是 ping 該 role。建立 role 時設定好，就不會遇到問題：

Server Settings, Roles，選取你的 support role，並在 Display 下開啟這個選項。沒有它，role 永遠不會進入 picker。

bot 如何決定要回答或開工單？

多數 Discord 工單 bot 不做任何決策。Ticket Tool、TicketsBot 和其他工具會張貼固定面板，上面有 Create Ticket 按鈕，或註冊 slash command。member 點下去，工單就開啟，你的團隊再閱讀。這是可用且完全可預測的設計，但也表示本週十個都問如何重設 API key 的人會產生十張工單。

同樣十個問題。差異在於你的團隊最後要閱讀什麼。

先回答 bot 會先讀你的文件再決定。升級時，開啟一張工單只需要四個事實：

• thread 要在哪個 channel 開啟
• 問題來自哪個 server
• 誰在提問，因此可以把他們拉進 thread
• 工單名稱，以及問題的一行摘要

有意思的是，這四項以三種完全不同方式抵達，只有最後一項是 AI 寫的：

你永遠不需要輸入 Discord ID，模型也永遠看不到你的 channel 或 role。

你一次選定的值。 你的 ticket channel 和 support role。安裝範本時從下拉選單選擇，Quickchat AI 會把它們寫進 Action。模型永遠看不到，也不能變更它們。

Discord 提供的值。 Discord integration 轉送每則訊息時，會告訴 Quickchat AI 它來自哪個 server、誰正在說話，形式為 {{metadata_discord_guild_id}} 和 {{metadata_discord_author_id}}。你的 bot token 也以相同方式抵達，作為送出時注入並在所有 call log 中遮蔽的 System Token。這些都不是模型輸入的，也不能由 public chat 或 API message 提供。

Agent 寫入的值。 ticket subject 和一行 issue summary。這是整個建置中唯一需要判斷的部分，也是之後調整很短的原因。

Step 1: 建立 Agent 並給它知識庫

建立你的 Agent，然後開啟 Knowledge Base 並加入文件。貼上 help-docs URL 讓 Quickchat AI 抓取，或直接撰寫文章。從你的文件建立 AI support agent 詳細說明抓取路徑。

Beacon 的知識庫：重設 API key、空白 dashboard、安裝 tracking snippet、plans and billing，以及匯出資料。

Beacon 的文件刻意不涵蓋一件事：企業 SSO 設定。這個缺口不是本教學的疏漏，而是重點。每個支援知識庫都有它無法回答的問題，此 bot 的全部價值就在於遇到這些問題時會怎麼做。SSO 在本指南中就是那個問題。

members 透過在可見 channel 中 @mentioning it 觸及你自己的 bot。不需要註冊任何東西。/ask command 適用於共用的一鍵 Quickchat AI bot。

Step 2: 告訴 Agent 何時回答、何時升級

Agent 的 instructions 放在 Identity 的 AI Main Prompt。貼上以下內容，並依你的公司調整：

你是 Lumen，Beacon 的支援助理。Beacon 是為軟體團隊提供的代管產品分析工具。你會在 Beacon community Discord 回答客戶問題。
只要可以，就從你的 Knowledge Base 回答。回答保持簡短實用，兩到三句，並提供具體步驟。
如果問題未被你的 Knowledge Base 涵蓋，不要猜測，也不要編造步驟。明確說你沒有該資訊，然後開啟 support ticket：
1. 呼叫 open_support_ticket 一次，使用簡短的 2 到 4 個字 ticket_subject 描述問題。
2. 接著呼叫 add_ticket_requester，把客戶帶入 thread。
3. 接著呼叫 post_in_ticket，附上一行 issue_summary，說明客戶詢問的內容。
然後告訴客戶他們的 ticket 已開啟，團隊會在新的 thread 中跟進。
絕不要向客戶詢問他們的 Discord ID、channel ID 或 thread ID。那些會為你填入。

Identity 上的 AI Main Prompt。這是永遠可用的欄位，不是獨立的 guidelines list。

那個區塊中有兩行承重。「不要猜測，也不要編造步驟」會把知識缺口變成誠實回答，而不是合理但虛構的回答。按順序命名三個 Actions，則會讓 Agent 以序列呼叫它們，而不是只選其中一個。

順序在 prompt 中描述，但並不只靠 prompt 強制，這正是接下來兩節要說明的內容。

Step 3: 一鍵安裝 ticket Actions

開啟 Actions & MCPs，點選 Add Action，並選擇 Discord Action。

Discord Action 與其他一鍵 galleries 放在一起。

gallery 會依工作分組 Discord templates：Support & Tickets 包含本指南使用的項目，Moderation 包含另外七個。

八張 cards。Open Support Ticket 是唯一會問你問題的。

選擇 Open Support Ticket，會開啟簡短設定步驟。這是整個建置中唯一的表單：

三個下拉選單，對話框一開始就說明它將安裝什麼。

清單會即時來自 Discord，並篩選為真正可用的項目。Channels 只列出 text channels：

選擇工單應在其下開啟的 channel。Threads 會在其中建立。

Roles 只列出 mentionable roles，並排除 @everyone：

這個篩選會隱藏尚未設為 mentionable 的 support role。

三個選擇完成，表單就完成：

完整設定。Server、channel、role，以及唯一重要的按鈕。

點選 Install and enable。Quickchat AI 會在後端以一個 transaction 寫入三個 Actions，且已啟用。

三張 cards，已啟用，帶有 Discord icon。沒有其他需要填寫的內容。

在這裡順便了解七個 moderation templates 的兩件事。它們完全不需要設定，因為它們從 Discord request 本身取得 server、member、role 或 channel，因此點選 card 會立即安裝。第二，重複安裝同一個 template 會得到第二個可編輯副本，而不是錯誤，這是建立變體的合理方式。

那一次點選實際建立了什麼？

即使你不需要輸入，仍值得理解，因為之後可能想變更的所有內容都在這裡。

三個一般 HTTP Request Actions。沒有任何東西標示它們特殊。

它們透過編輯器中已有的兩項功能互相串接，兩者都值得記住名稱。

Save to memory 會從 response 擷取一個值，並儲存在 conversation 上。open_support_ticket 用它保留新 thread 的 ID：Discord 回傳 thread object，$.id 是 ID，並會以 discord_ticket_thread_id 寫入記憶體。兩個後續 Actions 會在 URL 中讀回它，因此它們會操作剛建立的 thread，而不是你事先必須命名的東西。（文件中的 Save to memory。）

Run only when 會根據 conversation state 封鎖或允許 Action，並在任何 request 送出前由 Quickchat AI 端檢查。（文件中的 Run only when。）

這個 gate 把三個獨立 Actions 變成可靠序列。

請從兩個方向讀這張圖，因為它做了兩件事：

• 後續動作要求 thread ID 存在，因此 Agent 無法通知你的團隊一個從未建立的 thread。
• open_support_ticket 要求它不存在，因此同一段對話中 Agent 無法開第二張工單，無論對話怎麼說。這是一項保證，而不是指令：如果 member 再花十則訊息補充細節，他們仍然只有一張工單。在 channel reply mode 中，channel 裡的每次交換都是自己的 conversation，因此下一個真正的問題仍可開啟自己的工單。

每個 Action 也有 Response filter，這點很容易誤讀。response filter 是允許清單：它命名 Agent 可看見的 paths，response 中其他內容會在模型讀取前被丟棄。（文件中的 Response filter。）

Discord 回傳一打與你的 server 有關的欄位。Agent 只會看到兩個。

序列需要的 thread ID 由 Save to memory 在 Quickchat AI 端擷取，因此 Agent 不需要攜帶它，你的 server 其他資訊也不會到達模型。進一步縮小允許清單，它就看得更少。它永遠不會看到超過你列出的內容。

真人可以從 AI 接手嗎？

可以，這也是多數工單 bot 省略的一半。沒有人讀的工單只是一個 thread。

Human Handoff 是獨立的內建 Action。開啟它，並在 Handoff Rules 下描述對話何時應交給人員，例如「當客戶要求真人，或當 Agent 無法從知識庫回答時」。Quickchat AI 接著會在你的 Inbox 中以 AI 撰寫的摘要標記對話，因此接手者讀一段文字即可，不必讀完整 thread。每個 handoff 設定都在 Human Handoff tutorial 中有自己的逐步說明。

操作員在 Inbox 工作。member 不需要離開 Discord。

把對話指派給自己，並在 Inbox composer 回覆。該回覆會直接送回 member 已經在對話的 Discord channel。他們不需要在你這裡建立帳號、email thread 或 portal login。從真人擁有對話的那一刻起，AI 會保持安靜，因此你不會和自己的 bot 搶話。

同一個 channel，相隔三天。Agent 拒絕並升級；分隔線下方的訊息由真人在 Quickchat AI Inbox 輸入。請注意它會以你的 bot 名稱出現，因為 bot 是 Discord 允許我們用來發文的唯一身分。

你這邊看到的同一段對話。Agent 的拒絕、背後的兩個 Action calls、下方操作員的答案，以及已知道 channel 是 Discord、topic 是 single sign-on 的 details pane。

同時，私人 ticket thread 會留在你的團隊對話的地方：它是工作空間，member 在其中，support role 已被 ping。答案則回到提問的位置。

六個步驟。其中三個是 Discord writes，而且三個都只因為缺少答案才發生。

兩條路徑都測試

依賴它前請執行兩條路徑，並最嚴格測試誠實失敗。

已涵蓋問題。 在 bot 能看見的 channel 中 @mention 它，並詢問知識庫涵蓋的內容。你應該在 channel 中取得實際步驟，且任何地方都沒有 thread。這是替團隊省時間的案例；文件良好時，它會是大多數流量。

未涵蓋問題。 詢問文件未涵蓋的事項。Agent 應該說明這一點，然後升級。同一時間，工單會出現：

Agent 開啟的 thread。它根據問題命名、拉入 member、ping role，並自行撰寫摘要。

而且該 thread 確實是私人，自己的 member list 就能證明：

工單是私人 thread。支援對話不會在公開處進行。

測試整段對話，而不是單則訊息。 重複防護的價值在第二回合才會顯現，也就是 member 補充細節，而天真的 bot 會開第二張工單時。

run conditions 未涵蓋的一件事。 它們會阻止順序錯誤的呼叫，但不會對 retry 去重：如果你手動重新執行 notify Action，它會張貼第二則訊息。碰 live ticket 前值得知道。

若要一次檢查多種措辭而不全部輸入 Discord，請使用 Testing 下的 Simulations：建立 dataset 客戶訊息、執行 你的真實 Agent，並一起閱讀評分結果。在同一個 dataset 中混合已涵蓋和未涵蓋問題，因為兩條路徑會以不同方式失敗。

六個問題，四個已涵蓋、兩個未涵蓋，在一次 run 中評分。第 5 和第 6 列是誠實失敗，得分和答案一樣高。

為只能看 transcript 的 grader 撰寫 evaluation criteria，因為它只能取得這些。否則有兩件它看不到的事會讓你扣分。它看不到 Discord side effect，因此除非你說明，否則它會把「我已為你開啟工單」解讀為 Agent 編造能力。它也看不到你的知識庫，因此會把正確且具體的答案標為捏造，只因為它無法查證數字。這兩件都值得在 criteria 中各寫一句，如果漏掉，會把你最好的行為評低。

如何阻止 bot 開太多工單？

這是多數 servers 唯一需要的調整，而且大多不是 prompt 問題。

工單量是知識庫問題。 文件中的每個缺口都會變成工單。如果 bot 升級的問題比你預期更多，請閱讀工單：它們是你的文件尚未回答的問題清單。補上這些缺口會直接降低量。

Insights 告訴你接下來要寫什麼文件。 Quickchat AI 會依 topic 分組對話，因此你可以看到哪些問題最常出現，而不是猜測。在知識庫中修正前三個 topics，觀察 escalation rate 下降。

沒有人設定這些。在 Insights, Advanced 下，AI-Detected Topics 會從對話本身命名，而 counts 是按優先順序排列的文件待辦清單。

這個清單就是整個調整循環。Pricing 和 API keys 出現最多，因此先寫那些文章，下週的 chart 會告訴你是否有效。上方 topics 是自動發現的；如果你想刻意追蹤特定產品領域，也可以在 Manage Topics 下定義自己的 topics。請參閱文件中的 AI-Detected Topics、Conversation Topics 和 managing topics。

如果它太積極升級，請收緊 Action description，使其只在 Agent 已告訴 member 沒有該資訊後觸發。如果它太少升級並開始猜測，請強化 main prompt 中「不要猜測，也不要編造步驟」那一行。

這可以安全地在公開 server 中執行嗎？

任何人都能在 public channel 對話的 bot，都值得嚴格檢查。保護這個 bot 的是你可以在 editor 中閱讀的設定，而不是 prompt 文字，因此不受訊息措辭影響。

member 可以對模型說話。他們不能越過中間欄。

每個 ticket Action 都要求真實 Discord turn，且來自你的 server。 每個 Action 上三個 run conditions 中有兩個會檢查訊息確實透過 Discord integration 抵達，且來自你安裝時選定的 server。這些值由 integration 產生，不是由訊息產生，public chat 或 API message 無法提供，也無法繼承較早儲存的副本。把 Agent 的 public API 指向這些 Actions，它們會拒絕。

將某人加入私人 thread 的 Action 完全沒有可由模型編輯的參數。 它的 URL 以 integration 為目前訊息提供的 member ID 結尾。Agent 不能傳入不同 ID，因此無法把 server 中任意 member 拉進別人的工單。

Mentions 在安裝時鎖定。 notify Action 會傳送明確 mention list，包含提問的 member 和你選擇的 role，並停用 parsing。Agent 碰巧寫進 issue summary 的 mention 不會解析，@everyone 永遠不會觸發。這值得驗證，不應只相信，而它確實成立：role ping 和 user mention 都會送達，同一則訊息中的 literal @everyone 則不會做任何事。

Threads 是私人且不可邀請的。 它們以 type: 12 和 invitable: false 建立，因此被加入工單的 member 不能把其他人帶進來。

bot 不能審核。 它沒有 Kick、Ban 或 Timeout permission。member 說服 Agent 做不該做的事時，最壞結果是一個他們本來正常詢問也能開啟的 ticket thread。

token 永遠不會暴露。 它作為 System Token 存在，送出時注入，並在所有 call 記錄中遮蔽。

有一件事要刻意決定：ticket threads 是私人，但任何擁有 support role 的人都能閱讀，這正是支援所需；如果 members 可能貼上敏感細節，這點值得知道。真正機密的內容請引導他們使用 email。

Discord AI 支援 bot 要多少錢？

Free 方案包含 AI Actions、Human Handoff、知識庫、Topics 和 Insights，每月 50 個 AI credits，適用於個人、非商業用途。商業用途需要付費方案；付費方案也提供更多 AI credits。如果你正在和自行執行比較，free AI Discord bots 會誠實比較自架路線，包括它花費的時數。

當兩條路徑都通過後，放行 Agent：

1. 讓 members 知道 bot。 在 channel topic 中說明他們可以 @mention 它。沒有人知道的 bot 無法 deflect 任何東西。
2. 觀察第一天。 每個 Action 都保留包含精確 request 和 response 的 call log，Inbox 保存每段對話，因此你可以看到它回答了什麼、升級了什麼。
3. 把第一批工單當成文件待辦清單閱讀。 它們是你的文件尚未回答的問題。

同一個 Agent 也可以在其他地方運作。 知識庫、prompt 和 Human Handoff 屬於 Agent，不屬於 Discord，因此同一個支援 bot 可以在你的網站 widget、Slack、WhatsApp 和 email 上回答，每段對話都會進入同一個 Inbox。這三個 ticket Actions 是此建置中唯一與 Discord 相關的部分。如果你的團隊主要在 Slack 而不是 Discord，把 handoff notification 傳到那裡，而不是通知 Discord role。

你的 Discord AI Agent 還能做什麼？

同一個 gallery 有 Moderation 類別：timeout、kick、ban、unban、assign role、slowmode 和 announcements。每個安裝後都會帶有 author_is_admin is true run condition，因此只有 server administrator 可以觸發，而且該 flag 來自 Discord，不是來自對話。這是風險輪廓不同的另一種 bot，有自己的指南：建立 AI Discord 審核 bot。

任何其他 Discord endpoint 都遵循相同配方：一個帶有 Authorization: Bot {{discord_bot_token}} header 的 HTTP Request Action、一兩個 parameter，以及一段決定 Agent 何時觸發它的白話描述。建立會採取行動的 AI Agent 是這個概念的入門版本，將你的 AI Agent 連接到任何 API 則涵蓋一般情況。

並非每個 Discord bot 都是支援 bot。同一個 Agent 也可以扮演角色：Discord AI roleplay bot 使用相同知識庫和記憶體來處理 persona，而不是工單；完整角色建置 則逐步說明 persona prompt、canon，以及維持角色一致的 settings。

Appendix: 精確 requests

你永遠不需要輸入這些，但值得讀一次，而且它們就是你手動對任何其他平台建立時會做的內容。{{...}} 值會由 Quickchat AI 在送出時填入。

1. 開啟 private thread

POST https://discord.com/api/v10/channels/YOUR_TICKET_CHANNEL_ID/threads
Authorization: Bot {{discord_bot_token}}
Content-Type: application/json

{ "name": "ticket-{{ticket_subject}}", "type": 12, "auto_archive_duration": 1440, "invitable": false }

type: 12 讓 thread 成為 private。auto_archive_duration 以分鐘為單位，因此 1440 會在 quiet ticket 一天後封存。Save to memory 會將 $.id 擷取為 discord_ticket_thread_id。

2. 加入提問的 member

PUT https://discord.com/api/v10/channels/{{metadata_discord_ticket_thread_id}}/thread-members/{{metadata_discord_author_id}}
Authorization: Bot {{discord_bot_token}}

沒有 body，也沒有 parameters。兩個 IDs 都來自 memory 和 integration。

3. 通知 support team

POST https://discord.com/api/v10/channels/{{metadata_discord_ticket_thread_id}}/messages
Authorization: Bot {{discord_bot_token}}
Content-Type: application/json

{
  "content": "<@{{metadata_discord_author_id}}> your ticket is open. <@&YOUR_SUPPORT_ROLE_ID> new ticket: {{issue_summary}}",
  "allowed_mentions": { "parse": [], "users": ["{{metadata_discord_author_id}}"], "roles": ["YOUR_SUPPORT_ROLE_ID"] }
}

如果你自己建立，兩個細節會花掉真正的除錯時間。auth scheme 是 Bot, not Bearer，這是手動呼叫 Discord 時最常見的錯誤。而在 allowed_mentions 中，搭配明確 users 和 roles lists 的空 parse 正是你需要的：它會阻擋 @everyone，同時讓兩個預期 mentions 通過。若在相同類型的明確清單旁使用非空 parse，會直接被拒絕，錯誤為 400 MESSAGE_ALLOWED_MENTIONS_PARSE_EXCLUSIVE。

相關指南

• 建立 AI Discord bot，本指南假設的設定
• 建立 AI Discord 審核 bot，同一個 gallery 指向 moderation
• 最佳 AI Discord bots，比較各選項
• 免費 AI Discord bots，self-hosting 實際花費
• Discord AI roleplay bot，同一個 Agent 改為扮演角色
• 將你的 AI Agent 連接到 HubSpot，CRM 的同一種一鍵 gallery
• 讓你的 AI Agent actions 更可靠，深入說明 run conditions 和 memory
• 將你的 AI Agent 連接到任何 API，一般配方
• 如何建立 chatbot knowledge base，決定工單量的那一半
• Product tutorial: Human Handoff，每個 handoff setting 的說明

常見問題

如何在 Discord 設定工單機器人？

在 External Apps 連接你自己的 Discord app，為你的 Agent 提供知識庫，然後開啟 Actions and MCPs，點選 Add Action，選擇 Discord Action，再選 Open Support Ticket。從下拉選單選擇你的 server、ticket channel 和 support role，然後點選 Install and enable。除了建立 channel 和 role，不需要託管任何東西，也不需要在 Discord 內設定其他內容。

如何製作 Discord 工單機器人？

建立 Quickchat AI Agent，連接你自己的 Discord app，然後開啟 Actions and MCPs，點選 Add Action，選擇 Discord Action，再選 Open Support Ticket。你從下拉選單選擇 server、ticket channel 和 support role，點選 Install and enable，Quickchat AI 就會為你寫入三個完整的 AI Actions。先為 Agent 提供知識庫，因為這會決定它會開多少工單。

AI 可以在 Discord 回答支援問題嗎？

可以。Agent 會搜尋你的知識庫，找到答案時在 channel 中回答。Deflection 會追蹤涵蓋範圍：文件涵蓋的問題會被回答，文件未涵蓋的問題會變成工單。這個關係是執行這個 bot 時最重要的一件事。

我需要寫程式才能建立這個 Discord 工單機器人嗎？

不需要。你從 Discord gallery 選一個範本，從下拉選單選擇 server、channel 和 role，Quickchat AI 會在後端寫入 method、URL、headers、body、parameters、response settings 和 run conditions。你不需要輸入 Discord ID，也不需要編輯 JSON。

這個範本會安裝幾個 Actions？

三個。一個會在你的 ticket channel 中開啟 private thread 並把 ID 儲存到 memory，一個會加入提問的 member，一個會張貼摘要並提及你的 support role。它們安裝後已啟用，且已彼此串接。

bot 如何知道何時要開工單？

由兩件事決定。Action description 會告訴 Agent 只在知識庫沒有答案時呼叫它，而 run condition 會讓序列具備確定性：thread 開啟前不得已經存在，後續動作執行前則必須存在。

bot 會開重複工單嗎？

同一段對話中不會。Open Support Ticket 帶有 run condition，要求 memory 中尚未有 ticket thread ID，因此一旦已有一張工單，無論 prompt 怎麼寫，Agent 都不能為該對話再開第二張。

真人可以接手對話嗎？

可以。Human Handoff 會在你的 Quickchat AI Inbox 中以 AI 撰寫的摘要標記對話。把它指派給自己，在 Inbox 輸入回覆，回覆就會送到 member 已經所在的同一個 Discord channel。他們不需要離開 Discord，也不需要在你這裡建立帳號。

為什麼工單 bot 需要我自己的 Discord app？

ticket Actions 會以你的 bot 身分呼叫 Discord API，因此需要你的 bot token。共用的一鍵 Quickchat AI bot 可以回答問題並使用 Google Sheets Actions。它的 Discord token 無法提供給你的 private-ticket Actions。在 External Apps 開啟 Discord，選擇 Advanced setup，大約需要十分鐘。

bot 需要哪些 Discord permissions？

ticket channel 上需要 View Channels、Send Messages、Read Message History、Create Private Threads、Send Messages in Threads 和 Manage Threads。支援 bot 不需要 Kick、Ban 或 Timeout permission，未持有的權限也就不必推理其風險。

為什麼下拉選單中沒有我的 support role？

role picker 只列出 Discord 回報為 mentionable 的 roles，且排除 @everyone。如果你的 support role 沒有在 Server Settings, Roles 中設為 mentionable，它就不會出現，因為範本無法 ping 它。

Discord 工單 bot 可以安全地在公開 server 中執行嗎？

控制來自設定，而不是 prompt 文字，因此不受訊息措辭影響。每個 ticket Action 都要求該 turn 確實來自 Discord 且來自你選取的 server，將某人加入 private thread 的 Action 完全沒有可由模型編輯的參數，mentions 被鎖定為提問的 member 和你選擇的 role，threads 是 private 且不可邀請的。任何 request 離開 Quickchat AI 前都會先檢查 run conditions。

Discord AI 支援 bot 要多少錢？

Free 方案每月包含 50 個 AI credits，適用於個人、非商業用途。AI Actions、Human Handoff、知識庫、Topics 和 Insights 都包含在內。商業用途需要付費方案；付費方案也提供更多 AI credits。

這和 Ticket Tool 或 TicketsBot 有什麼不同？

那些是規則式工具。member 點選固定面板上的 Create Ticket 按鈕，每次都會開工單，包括文件已經能回答的問題。這個機器人會先回答，只有真正無法解決時才升級，因此你的團隊只需要閱讀真正需要真人處理的問題。

ChatGPT、Claude 或 Gemini 可以執行 Discord 工單 bot 嗎？

可以，透過 Quickchat AI。你的 Agent 在最新模型上執行，並用這些 AI Actions 呼叫 Discord API，因此會從你的知識庫回答，並開啟真正的 private threads。你決定有哪些 Actions，以及 bot 可以做什麼。

同一個 Agent 可以在 Discord 以外的 channels 上運作嗎？

可以。知識庫、prompt 和 Human Handoff 屬於 Agent，不屬於 Discord，因此同一個支援 bot 可以在你的 website widget、Slack、WhatsApp 和 email 上回答。這三個 ticket Actions 是此建置中唯一與 Discord 相關的部分。

members 如何開始和 bot 對話？

本指南中的 ticket bot 使用你自己的 Discord app，因此 members 會在它能看見的 channel 中 @mention 它來開始。Agent 會在同一個 channel 回覆，只有在無法回答時才開啟 ticket thread。/ask command 屬於共用的一鍵 Quickchat AI bot。

如何阻止 bot 開太多工單？

先改善知識庫涵蓋範圍，因為每個缺口都會變成工單。把第一批工單當成文件待辦清單閱讀，並使用 Insights 查看最常出現的 topics，知道下一步該寫什麼。之後再收緊 Action description。

我可以編輯 gallery 安裝的 Actions 嗎？

每個欄位都可以。它們是一般的 HTTP Request Actions，沒有任何標示它們特殊的東西：沒有 lock、沒有 badge、沒有獨立 policy layer。變更 URL、body、description 或 run conditions，或安裝第二份副本再編輯那一份。

我可以不使用 helpdesk 也執行 Discord 工單系統嗎？

可以。工單是一個 private Discord thread，佇列是你的 Quickchat AI Inbox，因此流程中沒有 Zendesk、Intercom 或 Jira，也沒有任何要遷移的東西。如果你已經使用 helpdesk，可以保留它：同一個 Agent 也可以用另一個 AI Action 在那裡建立工單，HubSpot gallery 正是這麼做。

bot 可以從我們的 help center 內容回答嗎？

這正是它的基礎。貼上你的 help center URL，Quickchat AI 會把頁面抓取成知識庫，或上傳檔案並直接貼上文章。Agent 會在每個問題上搜尋那些文章，找到答案時在 channel 中回答，因此既有文件不需要重寫就會變成 bot。從你的文件建立 AI support agent 會單獨說明這一半。

ticket channel 開啟時，bot 可以問候 member 嗎？

可以，用另一個功能。像 Ticket Tool 這樣的 ticket bot 會建立 channel，而 Quickchat AI 的 New channel automated message 會在幾秒後張貼固定問候，因此 member 會立刻看到有東西可以對話。因為沒有呼叫模型，所以不花 credits。問候 members、threads 和 ticket channels 會完成設定。

如何衡量 ticket deflection？

Deflection 是未開工單即被回答的問題占比，因此在此建置中，就是沒有 ticket thread 的對話除以所有對話。每個 Action 都保留 call log，因此計算 open_support_ticket 的呼叫次數就能直接得到升級的那一半，Insights 則會依 topic 分組其餘部分。請按 topic 追蹤，而不是只看單一數字：某個 topic 的比率下降，就是你可以補上的文件缺口。Chatbot analytics 涵蓋更廣泛的指標集合。

摘要

有了知識庫和一次點選，Quickchat AI Agent 就會成為你 Discord server 的第一線支援 bot：它回答文件涵蓋的問題，文件未涵蓋時會承認，為其餘問題開啟 private ticket thread，把 member 拉進來，以自己撰寫的摘要通知你的 support role，並把對話交給真人，讓真人從 Inbox 回答，而 member 不必離開 Discord。gallery 會寫入三個 Actions，下拉選單讓你永遠不需要輸入 Discord ID，run conditions 則讓序列即使在對話不按計畫發展時仍然成立。剩下的是只有你能做的工作：建立值得用來回答的知識庫。