AI Discord 工单 Bot：先回答，再升级（无代码）

Quickchat AI 会在你的 Discord 服务器中根据你自己的文档回答支持问题，只有无法回答时才开启私有工单线程。本指南从头到尾构建该 bot，无需代码，大约半小时完成。

结果类似一个合格的一线 agent。成员询问如何重置 API key，并在频道中得到真实步骤。成员询问文档未覆盖的内容，bot 不会猜测，而是说明无法回答，开启私有线程，将该成员加入线程，用一行摘要通知你的支持角色，并把对话交接给可从 Inbox 回答的人工。

为你的 Discord bot 选择任务

此构建会回答支持问题，并升级文档缺口。固定问候请选择欢迎指南，管理员命令请选择审核指南。

你需要两样东西：

• 一个 Quickchat AI Agent（创建账号）
• 一个你拥有管理员权限的 Discord 服务器

从注册到第一次支持测试

1. 如果你使用电子邮件和密码注册，请打开邮件中的验证链接。在设置中描述一个 Discord 支持 Agent，点击 Create my AI Agent，并完成设置步骤，包括为你的预期用途选择方案。
2. 在 Knowledge Base 下添加你的文档。在 External Apps 中打开 Discord，然后打开 Use your own Discord app，并选择 Advanced setup。共享的一键 bot 可以回答问题，但不能运行本指南中的工单 Actions。
3. 在测试服务器中创建工单频道和可提及的支持角色。在 Actions and MCPs 中点击 Add Action，选择 Discord Action，并使用该服务器、频道和角色安装 Open Support Ticket。
4. 应用下面的 Agent 指令后，用一个文档能回答的问题 @mention 你的 bot，然后再问一个文档无法回答的问题。第一个问题应得到回答且不开工单；第二个问题应开启一个私有线程并通知支持角色。向第二个对话添加追问，并检查不会开启重复工单。

Free 方案用于个人非商业用途。在将 bot 用于业务前请选择付费方案。邀请客户前先完成两条路径测试。

以下截图来自名为 Lumen 的测试 Agent，它是虚构产品分析公司 Beacon 的支持 bot。该公司是虚构的，因此示例保持中立，但这里展示的每个对话、每个 API 调用和每个工单线程，都是由真实 Agent 在真实 Discord 服务器上运行真实回复流水线生成的。

你将构建什么

每个问题只做一次判断。在顺利路径上，完全不会向 Discord 写入任何内容。

三个 AI Actions 负责升级工作，Quickchat AI 会从一个 gallery 卡片安装全部三个：

什么是知识库，为什么它决定工单量？

如果你以前没有构建过 AI Agent，这是值得花两分钟理解的概念。

知识库是你自己的文档，被加载到 Agent 中并建立索引，因此可在对话期间搜索。你可以将 Quickchat AI 指向帮助文档 URL 并让它抓取页面，手动粘贴文章，或上传文件。回复时，Agent 会搜索知识库并根据找到的内容回答，而不是依赖底层模型碰巧记得的世界知识。如果你从零开始，如何构建 chatbot 知识库说明了该写什么以及写作顺序。

文档覆盖的一切都会被回答。文档未覆盖的一切都会变成工单。

这就是此构建的全部杠杆。分流不是 prompt 技巧，也不是模型能力：它是你的覆盖率。如果 bot 升级的问题多于预期，工单正在告诉你哪些页面尚未编写。

这是示意而非测量结果。重点是方向：写文档是这里杠杆最高的工作。

AI 真的能在 Discord 中回答支持问题吗？

对于文档覆盖的问题，可以，而且会给出真实步骤而不是改写。下面是测试服务器中的分流案例，未编辑：

在频道中从知识库文章回答。没有创建工单，因为不需要。

更值得关注的是没有答案时发生什么。bot 会说明：

诚实失败。Beacon 的知识库故意省略企业 SSO，因此这是开启工单的路径。

一个编造看似合理 SSO 流程的 Agent，比开启工单的 Agent 更糟，因此这种行为值得有意测试，而不是寄希望于它。我们会在测试中回到这一点。

连接 Discord 的两种方式，以及为什么工单需要第二种

Quickchat AI 有两种 Discord 连接，开始前必须理解差异。

如需可与共享 bot 配合使用的公开反馈队列，请参阅反馈和文档缺口工作流。下面的私有工单 Actions 需要你自己的 Discord bot 凭据。

One-click 是快速路径。在 External Apps 中打开 Discord，点击 Add to your Discord server，授权后，共享 Quickchat AI bot 大约一分钟内就会在你的服务器中上线。成员 @mention 它或使用 /ask 时它会回答，对很多服务器来说这就是全部工作。

你可以给它命名。授权前有一个 Bot name in the new server 字段，预填为你的 Agent 名称；每个已连接服务器都有自己的 Bot name in this server 输入框，可稍后更改。它是 Discord 昵称，因此按服务器生效，上限 32 个字符；清空会把 bot 名称恢复为 Quickchat AI。共享不变的是头像和底层 @username，因为一个 Discord application 正服务于每个安装它的服务器。

一键不等于通用。bot 会把你的 Agent 名称带入服务器，之后也可以按服务器更改。

Advanced setup 会注册你自己的 Discord application。你在 Discord developer portal 中创建 bot，并将其 token 粘贴到 Quickchat AI 一次。大约需要十分钟，它会带来你自己的头像和 @username、私信、同一服务器中的多个 bot，以及本指南需要的内容：Discord API Actions。

原因值得明确说明，而不是当作怪癖处理。本指南中的工单 Actions 会使用 Quickchat AI 在发送时注入的凭据，以你的 bot 身份调用 Discord API。共享一键 bot 的 token 属于共享 bot，而不是你，因此不能用于你的 Actions 发送请求。如果你在没有连接自己 app 的情况下打开 Discord gallery，它会告知你并禁用卡片，而不是让你构建无法运行的东西。

External Apps 是两条路径的起点。Advanced setup 位于 Discord 面板底部的提示框中。

开始前需要什么

连接你自己的 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 所需权限。 在工单频道上：View Channels、Send Messages、Read Message History、Create Private Threads、Send Messages in Threads 和 Manage Threads。它不需要 Kick、Ban 或 Timeout 权限，并且测试服务器中故意没有这些权限。支持 bot 没有审核理由，它没有的权限也是你不需要推理的权限。

在 Discord 中创建 Actions 将指向的两样东西。 这部分在 Discord 客户端中完成，不在 Quickchat AI 中完成，也是你在那里唯一需要设置的内容：

1. 用于开启工单的频道。 任意文本频道都可以。使用频道列表旁的 +，或复用已有频道。测试服务器中是 #support。
2. 工单开启时要通知的角色。 Server Settings，然后 Roles，然后 Create Role。测试服务器中是 @support。

三个位置，其中只有一个是公开的。

这两项都会在 Step 3 回来。安装工单模板时，Quickchat AI 会从 Discord 实时读取你的服务器，并显示三个下拉菜单，其中一个是 Role 选择器，列出它找到的角色。你在那里选择支持角色，而不是在任何地方输入 ID。

Step 3 中的 Role 选择器。它从 Discord 读取列表，因此你现在创建的角色很快会出现在这里。

有一个细节如果跳过会出问题：该选择器只列出 Discord 报告为可提及的角色，并排除 @everyone。如果你的支持角色未设置为可提及，它根本不会出现在下拉菜单中，而且没有说明原因。这个过滤是故意的，因为模板的核心任务就是通知该角色。创建角色时设置它，就不会遇到这个问题：

Server Settings, Roles，选择你的支持角色，并在 Display 下开启此项。否则该角色永远不会到达选择器。

bot 如何决定回答还是开启工单？

大多数 Discord 工单 bot 并不做决定。Ticket Tool、TicketsBot 等会发布带有 Create Ticket 按钮的置顶面板，或注册斜杠命令。成员点击，工单开启，你的团队阅读。这是合理设计且完全可预测，但意味着本周十个都在问如何重置 API key 的人会生成十个工单。

同样十个问题。差异在于你的团队最终需要阅读什么。

先回答的 bot 会先阅读你的文档再决定。升级时，开启一个工单正好需要四个事实：

• 哪个频道中开启线程
• 问题来自哪个服务器
• 谁在提问，以便将其拉入线程
• 工单叫什么，以及问题的一行摘要

有意思的是，这四项来自三种完全不同的方式，只有最后一项由 AI 编写：

你从不输入 Discord ID，模型也永远看不到你的频道或角色。

一次性选择的值。 你的工单频道和支持角色。安装模板时从下拉菜单选择，Quickchat AI 会将它们写入 Action。模型永远看不到，也不能更改。

Discord 提供的值。 对每条转发的消息，Discord 集成都会告诉 Quickchat AI 它来自哪个服务器、谁在说话，分别是 {{metadata_discord_guild_id}} 和 {{metadata_discord_author_id}}。你的 bot token 以同样方式到达，作为 System Token 在发送时注入，并在每个调用日志中被遮盖。这些都不是模型输入的，也不能由公开聊天或 API 消息提供。

Agent 编写的值。 工单主题和一行问题摘要。这是整个构建中唯一需要判断的部分，也是后续调优很短的原因。

Step 1: 创建 Agent 并为其提供知识库

创建你的 Agent，然后打开 Knowledge Base 并添加文档。粘贴帮助文档 URL，让 Quickchat AI 抓取，或直接编写文章。从文档创建 AI 支持 agent详细说明了抓取路径。

Beacon 的知识库：重置 API key、空仪表板、安装跟踪代码片段、方案和账单、导出数据。

Beacon 的文档故意不覆盖一件事：企业 SSO 设置。这个缺口不是本教程的疏忽，而是重点。每个支持知识库都有无法回答的问题，此 bot 的全部价值就在于遇到这些问题时怎么做。SSO 是本指南中的这个问题。

成员通过在 bot 可见的频道中 @mention 它来访问你自己的 bot。无需注册任何命令。/ask 命令可用于共享的一键 Quickchat AI bot。

Step 2: 告诉 Agent 什么时候回答，什么时候升级

Agent 的指令放在 Identity 的 AI Main Prompt 中。粘贴以下内容，并按你的公司调整：

你是 Lumen，Beacon 的支持助手。Beacon 是面向软件团队的托管产品分析工具。你在 Beacon 社区 Discord 中回答客户问题。
只要可以，就从你的 Knowledge Base 回答。回答保持简短实用，两到三句话，并给出具体步骤。
如果问题未被你的 Knowledge Base 覆盖，不要猜测，也不要编造步骤。明确说明你没有该信息，然后开启支持工单：
1. 调用 open_support_ticket 一次，使用简短的 2 到 4 个词 ticket_subject 描述问题。
2. 然后调用 add_ticket_requester，将客户带入线程。
3. 然后调用 post_in_ticket，用一行 issue_summary 概括客户的问题。
然后告诉客户他们的工单已开启，团队会在新线程中跟进。
不要向客户索要他们的 Discord ID、频道 ID 或线程 ID。这些会为你填入。

Identity 上的 AI Main Prompt。这是始终可用的字段，不是单独的 guidelines 列表。

该代码块中有两行承担关键作用。“不要猜测，也不要编造步骤”会将知识缺口变成诚实回答，而不是看似合理的回答。按顺序命名三个 Actions，会让 Agent 将它们作为序列调用，而不是任选一个。

顺序在 prompt 中描述，但不只在那里强制执行，接下来两节说明这一点。

Step 3: 一键安装工单 Actions

打开 Actions & MCPs，点击 Add Action，并选择 Discord Action。

Discord Action 与其他一键 galleries 放在一起。

gallery 打开后，Discord 模板按任务分组：Support & Tickets 包含本指南使用的模板，Moderation 包含另外七个。

八张卡片。Open Support Ticket 是唯一会向你询问信息的卡片。

选择 Open Support Ticket，会打开一个简短配置步骤。这是整个构建中唯一的表单：

三个下拉菜单，对话框会预先说明它将安装什么。

列表实时来自 Discord，并过滤为实际可用的内容。频道仅限文本频道：

选择工单应在哪个频道下开启。线程会在其中创建。

角色仅限可提及角色，并排除 @everyone：

这个过滤器会隐藏尚未设置为可提及的支持角色。

完成三个选择，表单就完成了：

完整配置。服务器、频道、角色，以及唯一重要的按钮。

点击 Install and enable。Quickchat AI 会在后端以一个事务写入三个 Actions，并且已经启用。

三张卡片，已启用，带 Discord 图标。没有其他需要填写的内容。

你在这里还应知道七个审核模板的两点。它们完全不需要配置，因为它们从 Discord 请求本身获取服务器、成员、角色或频道，所以点击卡片会立即安装。重复安装一个模板会得到第二个可编辑副本，而不是报错，这是构建变体的合理方式。

那一键到底构建了什么？

尽管你不必输入它，仍值得理解，因为以后可能想更改的所有内容都在这里。

三个普通的 HTTP Request Actions。没有任何标记说明它们特殊。

它们通过编辑器中已有的两个功能相互连接，这两个名称都值得记住。

Save to memory 从响应中捕获一个值，并将其存储在对话上。open_support_ticket 用它保存新线程 ID：Discord 返回线程对象，$.id 是 ID，并作为 discord_ticket_thread_id 写入记忆。两个后续 Actions 会在 URL 中读回它，因此它们作用于刚创建的线程，而不是某个必须提前命名的线程。（文档中的 Save to memory。）

Run only when 根据对话状态控制 Action，并且在任何请求发送前由 Quickchat AI 侧检查。（文档中的 Run only when。）

把三个独立 Actions 变成可靠序列的门控。

请从两个方向阅读该图，因为它做了两件事：

• 后续操作要求线程 ID 存在，因此 Agent 不能通知你的团队一个从未创建的线程。
• open_support_ticket 要求它不存在，因此无论对话怎么说，Agent 都不能在同一对话中开启第二个工单。这是保证而不是指令：如果成员再用十条消息补充细节，他们仍然只有一个工单。在频道回复模式下，频道中的每次交流都是自己的对话，因此下一个真实问题仍可开启自己的工单。

每个 Action 还有一个 Response filter，这个功能容易误读。响应过滤器是一个允许列表：它指定 Agent 可看到的路径，响应中的其他所有内容都会在模型读取前被丢弃。（文档中的 Response filter。）

Discord 返回关于你的服务器的十几个字段。Agent 只看到两个。

该序列需要的线程 ID 由 Quickchat AI 侧通过 Save to memory 捕获，因此 Agent 不必携带它，你的服务器其他信息也不会到达模型。进一步收窄允许列表，它看到的就更少。它永远不会看到未列出的内容。

人工可以从 AI 接管吗？

可以，而且这是大多数工单 bot 缺少的一半。没人阅读的工单只是一个线程。

Human Handoff 是一个独立的内置 Action。开启它，并在 Handoff Rules 下描述什么情况下对话应转给人工，例如“客户要求人工时，或 Agent 无法从知识库回答时”。Quickchat AI 随后会在你的 Inbox 中用 AI 编写的摘要标记对话，因此接手的人读一段摘要即可，而不是整个线程。每个 handoff 设置在 Human Handoff 教程中都有单独说明。

操作员在 Inbox 中工作。成员从不离开 Discord。

将对话分配给自己，并在 Inbox 编辑器中回复。该回复会直接送回成员当前对话所在的 Discord 频道。他们不需要在你这里拥有账号、电子邮件线程或门户登录。人工拥有对话后，AI 会保持沉默，因此你不会与自己的 bot 竞争。

同一频道，相隔三天。Agent 拒绝并升级；分隔线下方的消息由人在 Quickchat AI Inbox 中输入。注意它以你的 bot 名称到达，因为 Discord 只允许我们以你的 bot 身份发帖。

你这边看到的同一对话。Agent 的拒绝、背后的两个 Action 调用、下面的操作员回答，以及已经知道渠道是 Discord、主题是单点登录的详情面板。

同时，私有工单线程仍留在团队讨论的位置：它是工作空间，成员在其中，并且你的支持角色已被通知。答案回到问题提出的位置。

六个步骤。其中三个是 Discord 写入，且全部只因为缺少答案才发生。

两条路径都要测试

依赖它之前运行两条路径，并最严格地测试诚实失败。

已覆盖的问题。 在 bot 可见的频道中 @mention 它，并询问知识库覆盖的内容。你应在频道中得到真实步骤，并且任何地方都不应出现线程。这是节省团队时间的案例，一旦文档足够好，它将成为大多数流量。

未覆盖的问题。 询问文档未覆盖的内容。Agent 应说明无法回答，然后升级。同时，工单会出现：

Agent 开启的线程。它根据问题命名线程，将成员拉入，通知角色，并自行编写摘要。

该线程确实是私有的，其成员列表可以证明：

工单是私有线程。支持对话不会在公开空间进行。

跨整个对话测试，而不是只测一条消息。 重复保护的价值只会在第二轮显示出来：成员补充细节时，天真的 bot 会开启第二个工单。

运行条件没有覆盖的一件事。 它们会阻止乱序调用，但不会对重试去重：如果你手动重新运行 notify Action，它会发布第二条消息。在实时工单上操作前应知道这一点。

如果想一次检查很多表达方式，而不是全部输入 Discord，请使用 Testing 下的 Simulations：构建数据集包含客户消息，运行它对照真实 Agent，并一起阅读评分结果。在一个数据集中混合已覆盖和未覆盖问题，因为两条路径的失败方式不同。

六个问题，四个已覆盖、两个未覆盖，一次运行完成评分。第 5 和第 6 行是诚实失败，得分与答案一样高。

为只能看到 transcript 的评分器编写评估标准，因为它只能看到这些。有两件它看不到的事，否则会影响评分。它看不到 Discord 侧效果，因此如果你不说明，它会把“我已为你开启工单”理解为 Agent 编造能力。它也看不到你的知识库，因此会把正确且具体的答案降分为编造，只因为它无法核对数字。这两点都值得在标准中各写一句，如果遗漏，就会让最佳行为被降分。

如何阻止 bot 开启过多工单？

这是大多数服务器唯一需要的调优，而且主要不是 prompt 问题。

工单量是知识库问题。 文档中的每个缺口都会变成工单。如果 bot 升级的问题多于预期，请阅读工单：它们是你的文档尚未回答的问题列表。补上这些缺口会直接降低工单量。

Insights 告诉你下一步该写什么。 Quickchat AI 会按主题对对话分组，因此你可以看到最常出现的问题，而不是猜测。在知识库中修复前三个主题，并观察升级率下降。

没人配置这些内容。在 Insights, Advanced 下，AI-Detected Topics 根据对话本身命名它们，计数就是按优先级排列的文档待办。

这个列表就是完整调优循环。定价和 API key 出现最多，因此先写这些文章，下周的图表会告诉你是否有效。上面的主题会自动发现；如果你想有意跟踪特定产品区域，也可以在 Manage Topics 下定义自己的主题。参阅文档中的 AI-Detected Topics、Conversation Topics 和 managing topics。

如果它升级过于积极，收紧 Action 描述，使其仅在 Agent 已告诉成员它没有该信息后触发。如果它升级太少并开始猜测，加强 main prompt 中“不要猜测，也不要编造步骤”这一行。

这可以安全地在公开服务器中运行吗？

任何公开频道中的人都能对话的 bot 都值得仔细检查。保护此 bot 的是你可以在编辑器中阅读的配置，而不是 prompt 文案，因此无论消息怎么措辞都有效。

成员可以与模型对话。他们不能绕过中间列。

每个工单 Action 都要求真实 Discord 轮次，并来自你的服务器。 每个 Action 上三个运行条件中的两个会检查消息确实通过 Discord 集成到达，并且来自你安装时选择的服务器。这些值由集成生成，而不是由消息生成，公开聊天或 API 消息无法提供它们，也无法继承较旧的已存副本。把 Agent 的公共 API 指向这些 Actions，它们会拒绝。

将某人添加到私有线程的 Action 完全没有模型可编辑参数。 它的 URL 以集成为当前消息提供的成员 ID 结尾。Agent 不能传递不同 ID，因此不能把你服务器中的任意成员拉进别人的工单。

提及在安装时锁定。 notify Action 发送显式提及列表，其中包含提问成员和你选择的角色，并禁用解析。Agent 碰巧写入问题摘要的提及不会解析，@everyone 永远不会触发。这一点值得验证而不是信任，并且确实有效：角色通知和用户提及都会到达，同一消息中的字面量 @everyone 不会做任何事。

线程是私有且不可邀请的。 它们以 type: 12 和 invitable: false 创建，因此被添加到工单的成员无法再拉其他人进来。

bot 不能审核。 它没有 Kick、Ban 或 Timeout 权限。成员诱导 Agent 做错事的最坏结果，是开启一个他们本来也能正常请求开启的工单线程。

token 永远不会暴露。 它作为 System Token 存在，发送时注入，并在记录调用的所有地方被遮盖。

需要有意决定的一件事：工单线程是私有的，但任何拥有你的支持角色的人都可以阅读，这正是支持场景需要的；如果成员可能粘贴敏感细节，也值得知道。真正机密的内容应引导他们使用电子邮件。

Discord AI 支持 bot 成本是多少？

Free 方案包含 AI Actions、Human Handoff、知识库、Topics 和 Insights，每月 50 个 AI credits，供个人非商业使用。商业使用需要付费方案；付费方案还提供更多 AI credits。如果你正在权衡自行运行，免费 AI Discord bots会诚实比较自托管路径，包括它需要的时间成本。

当两条路径都通过后，让 Agent 上线：

1. 告诉成员使用 bot。 在频道主题中说明他们可以 @mention 它。没人知道的 bot 不会分流任何问题。
2. 观察第一天。 每个 Action 都保留包含准确请求和响应的调用日志，Inbox 保存每个对话，因此你可以看到它回答了什么、升级了什么。
3. 把最早的工单当作文档待办阅读。 它们是你的文档尚未回答的问题。

同一个 Agent 也能在其他任何地方工作。 知识库、prompt 和 Human Handoff 属于 Agent，不属于 Discord，因此同一个支持 bot 可以在你的网站 widget、Slack、WhatsApp 和电子邮件中回答，并且每个对话都会进入同一个 Inbox。三个工单 Actions 是此构建中唯一与 Discord 相关的部分。如果你的团队主要在 Slack 而不是 Discord 中工作，请改为在那里发送 handoff 通知，而不是通知 Discord 角色。

你的 Discord AI Agent 还能做什么？

同一个 gallery 包含 Moderation 类别：timeout、kick、ban、unban、assign role、slowmode 和 announcements。每个模板安装时都带有 author_is_admin is true 运行条件，因此只有服务器管理员能触发它们，并且该标志来自 Discord，而不是来自对话。这是风险画像不同的另一个 bot，因此有自己的指南：构建 AI Discord 审核 bot。

任何其他 Discord endpoint 都遵循同样配方：一个 HTTP Request Action，带有 Authorization: Bot {{discord_bot_token}} 标头、一两个参数，以及决定 Agent 何时触发它的自然语言描述。构建会执行动作的 AI Agent是该思路的入门版本，将你的 AI Agent 连接到任意 API覆盖一般情况。

并非每个 Discord bot 都是支持 bot。同一个 Agent 也可以运行一个角色：Discord AI 角色扮演 bot使用相同知识库和记忆来承载 persona 而不是工单，完整角色构建则介绍 persona prompt、canon，以及保持角色一致的设置。

附录：准确请求

你永远不需要输入这些，但值得读一次，它们也是你针对任何其他平台手动构建时会写的内容。{{...}} 值会在发送时由 Quickchat AI 填入。

1. 开启私有线程

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 会让线程成为私有线程。auto_archive_duration 以分钟为单位，因此 1440 会在一天后归档安静的工单。Save to memory 会将 $.id 捕获为 discord_ticket_thread_id。

2. 添加提问成员

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

没有正文，也没有参数。两个 ID 分别来自记忆和集成。

3. 通知支持团队

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"] }
}

如果你自己构建，这两个细节会消耗真实调试时间。认证方案是 Bot，不是 Bearer，这是手动调用 Discord 时最常见的错误。并且在 allowed_mentions 中，你需要的是显式 users 和 roles 列表旁边的空 parse：它会阻止 @everyone，同时允许你预期的两个提及通过。同一类型的显式列表旁边放一个非空 parse 会被直接拒绝，错误为 400 MESSAGE_ALLOWED_MENTIONS_PARSE_EXCLUSIVE。

相关指南

• 创建 AI Discord bot，本指南假定的设置
• 构建 AI Discord 审核 bot，同一个 gallery 指向审核
• 最佳 AI Discord bots，各选项如何比较
• 免费 AI Discord bots，自托管实际会带来什么成本
• Discord AI 角色扮演 bot，同一个 Agent 改为运行角色
• 将你的 AI Agent 连接到 HubSpot，同样的一键 gallery 用于 CRM
• 让你的 AI Agent actions 更可靠，深入介绍运行条件和记忆
• 将你的 AI Agent 连接到任意 API，通用配方
• 如何构建 chatbot 知识库，决定工单量的那一半
• 产品教程：Human Handoff，解释每个 handoff 设置

常见问题

如何在 Discord 中设置工单 bot？

在 External Apps 中连接你自己的 Discord app，为你的 Agent 提供知识库，然后打开 Actions and MCPs，点击 Add Action，选择 Discord Action 并选择 Open Support Ticket。从下拉菜单中选择你的服务器、工单频道和支持角色，然后点击 Install and enable。除了创建频道和角色之外，不需要托管任何内容，也不需要在 Discord 内配置任何其他内容。

如何制作 Discord 工单 bot？

创建一个 Quickchat AI Agent，连接你自己的 Discord app，然后打开 Actions and MCPs，点击 Add Action，选择 Discord Action 并选择 Open Support Ticket。你从下拉菜单中选择服务器、工单频道和支持角色，点击 Install and enable，Quickchat AI 会为你写入三个完整的 AI Actions。先给 Agent 一个知识库，因为知识库决定它会开启多少工单。

AI 能在 Discord 中回答支持问题吗？

可以。Agent 会搜索你的知识库，并在找到答案时在频道中回答。分流反映覆盖率：文档覆盖的问题会被回答，文档未覆盖的问题会变成工单。理解这种关系，是运行此 bot 最重要的一点。

构建这个 Discord 工单 bot 需要写代码吗？

不需要。你从 Discord gallery 中选择一个模板，从下拉菜单中选择服务器、频道和角色，Quickchat AI 会在后端写入方法、URL、标头、正文、参数、响应设置和运行条件。你不需要输入 Discord ID，也不需要编辑 JSON。

模板会安装多少个 Actions？

三个。一个在你的工单频道中开启私有线程并将其 ID 保存到记忆中，一个添加提问的成员，一个发布摘要并提及你的支持角色。它们安装时已启用，并且已相互连接。

bot 如何知道什么时候开启工单？

由两件事决定。Action 描述告诉 Agent 只在知识库中没有答案时调用它，运行条件使序列具有确定性：线程必须尚不存在才能开启，后续操作必须在线程存在后才能运行。

bot 会开启重复工单吗？

同一对话中不会。Open Support Ticket 带有一个运行条件，要求记忆中尚不存在工单线程 ID，因此一旦该对话已有一个工单，无论 prompt 怎么说，Agent 都无法为该对话开启第二个工单。

人工可以接管对话吗？

可以。Human Handoff 会在你的 Quickchat AI Inbox 中用 AI 编写的摘要标记对话。将它分配给自己，在 Inbox 中输入回复，它会送达成员当前所在的同一个 Discord 频道。成员不会离开 Discord，也不需要在你这里拥有账号。

为什么工单 bot 需要我自己的 Discord app？

工单 Actions 会以你的 bot 身份调用 Discord API，因此需要你的 bot token。共享的一键 Quickchat AI bot 可以回答问题并使用 Google Sheets Actions。它的 Discord token 不能用于你的私有工单 Actions。在 External Apps 中打开 Discord 并选择 Advanced setup，大约需要十分钟。

bot 需要哪些 Discord 权限？

在工单频道上需要 View Channels、Send Messages、Read Message History、Create Private Threads、Send Messages in Threads 和 Manage Threads。支持 bot 不需要 Kick、Ban 或 Timeout 权限，它没有的权限也是你不需要推理的权限。

为什么下拉菜单中没有我的支持角色？

角色选择器只列出 Discord 报告为可提及的角色，并排除 @everyone。如果你的支持角色没有在 Server Settings, Roles 中设置为可提及，它就不会出现，因为模板将无法通知它。

Discord 工单 bot 可以安全地在公开服务器中运行吗？

控制来自配置，而不是 prompt 文案，因此无论消息如何措辞都有效。每个工单 Action 都要求当前轮次确实来自 Discord，并来自你选择的服务器；将某人添加到私有线程的 Action 完全没有模型可编辑参数；提及被锁定为提问成员和你选择的角色；线程是私有且不可邀请的。任何请求离开 Quickchat AI 之前都会检查运行条件。

Discord AI 支持 bot 成本是多少？

Free 方案每月包含 50 个 AI credits，供个人非商业使用。AI Actions、Human Handoff、知识库、Topics 和 Insights 均包含在内。商业使用需要付费方案；付费方案还提供更多 AI credits。

这和 Ticket Tool 或 TicketsBot 有什么区别？

它们基于规则。成员点击置顶面板上的 Create Ticket 按钮，每次都会开启工单，包括文档已经能回答的问题。这个 bot 会先回答，只升级它确实无法解决的问题，因此你的团队只需要阅读真正需要人工的问题。

ChatGPT、Claude 或 Gemini 能运行 Discord 工单 bot 吗？

可以，通过 Quickchat AI。你的 Agent 运行在最新模型上，并通过这些 AI Actions 调用 Discord API，因此它会从你的知识库回答并开启真实的私有线程。由你决定哪些 Actions 存在，以及 bot 被允许做什么。

同一个 Agent 能在 Discord 以外的渠道工作吗？

可以。知识库、prompt 和 Human Handoff 属于 Agent，不属于 Discord，因此同一个支持 bot 可以在你的网站 widget、Slack、WhatsApp 和电子邮件中回答。三个工单 Actions 是此构建中唯一与 Discord 相关的部分。

成员如何开始与 bot 对话？

本指南中的工单 bot 使用你自己的 Discord app，因此成员通过在 bot 可见的频道中 @mention 它来开始。Agent 在同一频道回复，并且只在无法回答时开启工单线程。/ask 命令属于共享的一键 Quickchat AI bot。

如何阻止 bot 开启过多工单？

先提高知识库覆盖率，因为每个缺口都会变成工单。把最早的工单当作文档待办阅读，并使用 Insights 查看最常出现的主题，从而知道下一步写什么。之后再收紧 Action 描述。

我能编辑 gallery 安装的 Actions 吗？

每个字段都可以。它们是普通的 HTTP Request Actions，没有任何特殊标记：没有锁、没有徽章、没有单独的策略层。可以更改 URL、正文、描述或运行条件，也可以安装第二份副本并编辑它。

我可以不使用 helpdesk 运行 Discord 工单系统吗？

可以。工单是一个私有 Discord 线程，队列是你的 Quickchat AI Inbox，因此流程中没有 Zendesk、Intercom 或 Jira，也没有需要迁移的内容。如果你已经在使用 helpdesk，可以继续使用：同一个 Agent 也可以通过另一个 AI Action 在那里创建工单，HubSpot gallery正是这样做的。

bot 能从我们的帮助中心内容回答吗？

这正是它的基础。粘贴你的帮助中心 URL，Quickchat AI 会将页面抓取到知识库，或者上传文件并直接粘贴文章。Agent 会在每个问题上搜索这些文章，并在找到答案时在频道中回答，因此你现有的文档无需重写即可成为 bot。从文档创建 AI 支持 agent单独介绍了这一半。

工单频道开启时，bot 能问候成员吗？

可以，使用一个单独功能。Ticket Tool 等工单 bot 创建频道后，Quickchat AI 的 New channel automated message 会在几秒后发布固定问候语，因此成员会立即看到这里有东西可以对话。由于没有调用模型，因此不消耗 credits。问候成员、线程和工单频道介绍了设置方法。

如何衡量工单分流？

分流是无需工单即可回答的问题占比，因此在此构建中，它等于没有工单线程的对话数除以所有对话数。每个 Action 都保留调用日志，因此统计 open_support_ticket 的调用次数即可直接得到升级的一半，Insights 会按主题对其余部分分组。按主题跟踪，而不是只看一个总数：某个主题分流率下降，就是一个可以补上的文档缺口。Chatbot analytics介绍更广泛的指标集。

总结

有了知识库和一次点击，Quickchat AI Agent 就会成为你的 Discord 服务器的一线支持 bot：它回答文档覆盖的问题，在无法回答时承认这一点，为其余问题开启私有工单线程，将成员拉入，用自己编写的摘要通知你的支持角色，并把对话交给人工，由人工从 Inbox 回答，而成员无需离开 Discord。gallery 会写入三个 Actions，下拉菜单意味着你永远不需要输入 Discord ID，运行条件意味着即使对话没有按计划进行，序列仍然有效。剩下的是只有你能做的工作：一个值得据此回答的知识库。