Skip to main content
出海产品的 Discord 社区每天新增上百条多语种消息。靠人工运营,一条消息从发出到被看到通常要等 数小时,夜间和周末的消息只能堆积到下一个工作日;把一周的反馈整理成周报,通常还要再花半天。 本案例用三个 Kimi 托管智能体完成同样的工作:巡检智能体 每小时 读取新消息,归类、登记待办并附回复草稿;告警智能体 每 30 分钟 筛查风险反馈,夜间和周末同样生效;问答智能体回答对历史讨论和简报的查询。日报、周报由智能体自动生成,一份周报的成本 约 ¥2。回复草稿经人工审核后才发送。 全天运行成本 约 ¥54,折算每月 约 ¥1,600,比一名专职多语种运营的人力成本低 一个数量级。测算过程见运行成本一节。
本案例用 Discord 作为消息来源、飞书多维表格(Base)存放整理后的数据,并自建一个 Web 运营工作台。开发者也可以沿用这一设计接入其他社区和数据系统,并相应调整访问凭据、接口调用和数据字段。

Agent 架构总览

Discord 社区运营架构:三个智能体读取社区消息,整理事项、回复草稿、报告和风险反馈,并支持问答;回复草稿经人工审核后由应用发送,结果写回待处理事项表 Kimi 托管智能体负责巡检、回复草稿生成、报告、告警和问答任务。运营人员通过自建 Web 工作台查看结果、追问社区动态;通过飞书多维表格审批智能体的回复方案和草稿。
  1. 收集新消息:巡检智能体每小时读取一次指定频道。系统记录各频道最后读到的消息代码,作为采集进度,下次巡检从这条消息之后继续读取。
  2. 分层登记:将有信息量的消息整理后写入飞书多维表格,并把需要人工处理的事项单独列成待办。
  3. 准备与发送回复:巡检智能体为需要回应的事项生成草稿,运营人员在待处理事项表中修改、确认,应用发送后记录结果。
  4. 主动汇报:日报说明今天需要处理的事项和社区动态,周报汇总一周趋势;发现疑似服务异常、安全风险等需要尽快核实的反馈时,单独通知飞书运营群。
  5. 继续追问:运营人员可以询问近期高频问题、未处理事项或历史变化,问答智能体基于社区消息摘要和简报回答。

核心设计

三个智能体分工

  • 巡检与报告智能体:收集和整理社区消息,为需要回应的事项生成草稿,并生成日报与周报。
  • 告警智能体:独立识别需要尽快核实的风险反馈并通知运营人员,不承担常规分类和报告任务。
  • 问答智能体:响应运营人员的提问,查询已整理的数据,必要时核对原消息。
巡检与报告共用数据整理和写作规则,因此由同一个智能体执行。

两层数据:信息与待办

采集结果写入飞书多维表格的两张表: 同一个问题被多人提起时,不在待处理事项表中重复新增记录,而是更新已有记录的出现次数、最近出现时间和相关消息链接。运营人员可以在同一条待办中查看这个问题的出现次数和相关反馈。 两张表都写入成功后,智能体才更新采集进度。写入失败时保留原进度,下轮重新处理这批消息,并按消息 ID 查重,避免重复登记。 下面用几个示意场景说明数据如何支持运营工作: 值得关注的分享不一定需要处理;只有需要运营人员采取行动时,才进入待处理事项表。

定时任务分工

巡检将社区消息整理成消息摘要、待办事项和回复草稿;告警只筛选需要尽快核实的风险反馈,并通知运营人员。两项任务分别配置运行计划。 两项任务会读取同一批频道,但产出不同:巡检用于日常跟进,告警用于优先提醒,不替代实时故障监控。 本案例的定时任务分工如下: 日报和周报从已经整理好的数据中生成,不需要再次通读 Discord 原消息。

集中维护共享规则

巡检、报告、告警和问答共用的行为规则和数据约定统一维护在记忆库中的 rules.md,避免分别维护多份规则时出现版本不一致。系统提示词定义各智能体的职责,运行配置则随任务指令提供:

配置选择

三个智能体均通过系统提示词和内置工具完成任务,未额外挂载技能、插件或 MCP 服务。全部任务统一使用 kimi-k2.6 模型,选型考虑有两点:高频、流程固定的任务优先选用轻量模型;多语言理解和问答能力足以应对社区中与产品相关的日常问询,减轻运营团队负担。各项资源的配置如下:

运行成本

以一个日增约 100 条消息的 Discord 社区为例,各智能体单轮任务成本如下:

从最小版本开始搭建

先让巡检稳定地将新消息整理到飞书多维表格,再检查回复草稿是否便于审核,逐步接入日报、周报、告警、问答和运营工作台。

1. 准备消息来源和数据表

在 Discord Developer Portal 创建 Discord Bot,用于读取社区消息,只授予 View Channel 和 Read Message History 权限,不在社区中发言。在飞书开放平台创建应用,并在一个多维表格中准备社区消息摘要和待处理事项两张表。 在 Discord Developer Portal 中打开刚创建的应用,进入 Bot 页面,在 Token 区域点击 Reset Token 生成 Bot Token。Token 只在生成时完整显示一次,生成后立即复制保存。 在 Discord Developer Portal 的 Bot 页面生成 Bot Token 在飞书开放平台开发者后台打开自建应用,进入凭证与基础信息页面,复制 App ID 和 App Secret。 在飞书开放平台开发者后台的凭证与基础信息页面获取 App ID 和 App Secret 将 Discord Bot Token 和飞书应用的 App ID、App Secret 写入凭据库,再创建一个只允许访问 Discord 与飞书 API 主机的执行环境。具体操作分别见 凭据库 和 执行环境。 多维表格的 app_token 和 table_id 不进凭据库,直接从浏览器地址栏的链接中获取,链接结构如下:
/base/ 之后的一段是 app_token,table 参数的值是当前数据表的 table_id。在多维表格中切换数据表时,table 参数随之变化,分别打开社区消息摘要和待处理事项两张表,复制各自的 table_id,后续配置触发器时使用。 创建一个记忆库,用于保存 rules.md、采集进度和后续生成的简报,创建方法见 记忆。在记忆库中创建 rules.md,写入本案例共享的数据约定和行为规则。 rules.md 示例:

2. 创建巡检智能体

创建一个智能体,创建方式见 智能体。系统提示词定义它的角色和职责,并要求每轮任务开始前读取 rules.md。 巡检和告警以 read_write 权限挂载同一个记忆库,用于保存采集进度和告警记录。rules.md 由人工维护,三个智能体的系统提示词都应要求只读取、不修改该文件。 系统提示词示例:

3. 创建巡检触发器

创建触发器时,填写已创建的智能体、执行环境、凭据库和记忆库 ID,并在 initial_events 中配置巡检指令,写清要读取的 Discord 频道、要写入的飞书多维表格,以及保存采集进度的位置。触发器每次运行都会自动发送这段指令,无需重复配置;频道、表格或任务要求变化时,再更新指令。 访问 Discord 和飞书所需的凭据提前存入凭据库,不写入指令。 下面是创建触发器请求体的关键结构:
触发器字段、手动运行和运行记录见 定时任务。

4. 验证巡检结果

首次手动运行巡检,确认各频道已记录当前最新消息 ID 作为起点,没有拉取历史消息。后续频道出现新消息后,再运行巡检,确认消息已写入社区消息摘要、需要处理的事项已进入待处理事项,并检查消息链接是否能打开对应原文。再次运行时,确认它从上次记录的位置继续读取,没有重复登记已处理的消息。

5. 生成并审核回复草稿

运营人员在待处理事项表中查看 AI 生成回复草稿并确认回复目标。 应用在下一轮巡检中,发送审核确认后的内容,并将结果写回对应事项。

6. 增加日报和周报

为巡检智能体分别配置日报和周报触发器。 日报触发器每天晚间运行,initial_events 写明本轮不读取 Discord,只读取当天的社区消息摘要和待处理事项并生成日报。日报单独使用一个触发器,不在每小时巡检的指令里叠加按时间判断的分支。 周报触发器每周一运行,汇总上周趋势、未解决事项、活跃成员和值得整理成常见问题解答的高频提问。除两张表外,还可以读取记忆库中归档的历史日报和周报。 巡检触发器复用会话(reuse_session),采集进度保存在记忆库中;日报和周报每次创建新会话(new_session),每期报告都是相对独立的分析任务。

7. 创建紧急告警智能体

再创建一个智能体,职责只限于识别需要尽快由人工核实的风险反馈。它不做普通消息分类,不维护待处理事项,也不生成日报和周报。 告警智能体沿用同样的结构:系统提示词定义它负责识别和上报风险反馈,并要求每轮任务开始时读取 rules.md。需要通知的反馈范围和输出格式作为判断规则维护在 rules.md 中。

8. 创建紧急告警触发器

告警触发器每 30 分钟运行一次,复用已有的执行环境、凭据库和记忆库,绑定告警智能体。 告警任务维护独立的采集进度和已告警记录,不与日常巡检共享采集进度,避免一个任务提前推进读取位置后,另一个任务漏掉消息。例如巡检进度保存为 discord/cursor.json,告警进度保存为 discord/alert-cursor.json。 创建告警触发器请求体的关键结构:

9. 创建问答智能体

创建第三个智能体,面向运营人员的交互式查询。问答智能体不需要定时触发器,由运营人员的提问驱动,接入方式见下一节。 问答智能体优先查询社区消息摘要、待处理事项、记忆库中归档的历史日报和周报,以及已确认的社区知识;需要核对原文或补充上下文时,通过同一 Discord Bot 读取原消息。 在系统提示词中要求问答智能体在会话开始时读取 rules.md。 创建后用少量典型问题验证回答质量,例如「最近一周 API rate limit 相关反馈有哪些」「哪些问题被多人反复提起但还没有解决」。

10. 将智能体能力接入运营工作台

运营工作台是一个独立的 Web 应用,也可以直接接入团队已有的内部运营系统。工作台包含数据看板和问答入口。下图是一个运营看板的示例界面,开发者可以根据自身需求定制看板。 社区运营工作台:左侧展示今日待办和社区动态,右侧运营助手回答关于历史反馈和讨论的问题 待办、简报和回复草稿附有来源,运营人员可以回到原网页核实,再决定如何回应。 看板和问答入口使用不同的数据路径: 问答的调用链如下:
Kimi 托管智能体 API Key 只保存在工作台服务端,浏览器前端不直接调用。创建会话时传入问答智能体、执行环境、凭据库和记忆库 ID,与触发器使用的资源相同;复用同一会话可以支持连续追问。会话的创建和消息发送方式见 会话。

11. 验证完整工作流

全部配置完成后,按完整链路验证一轮:
  • 巡检:首次运行只记录当前最新消息 ID,不拉取历史消息;后续运行只读取新增消息,不重复登记;原消息链接可以打开。
  • 报告:手动运行日报和周报触发器,检查报告的数据来源和统计时间范围。
  • 告警:用普通消息运行一轮,确认不发送飞书通知;构造一条需要尽快核实的反馈后运行,确认通知包含原消息链接,并区分已知信息与待核实内容;再次运行时同一事件不重复告警。
  • 问答:通过会话 API 或已接入的运营工作台提出一个典型问题,确认回答基于社区消息摘要、待处理事项和历史简报,涉及具体反馈时返回原消息链接。
修改规则后,巡检和告警在下一轮任务开始时重新读取 rules.md,无需更换复用的会话;日报和周报在下次新建会话时读取。问答智能体在会话开始时读取规则,如需立即使用新规则,应创建新的问答会话。

可扩展方向

  • 接入更多社区数据源:接入 Discourse、GitHub Discussions 等社区,将不同平台的消息整理到社区消息摘要和待处理事项中,复用后续的报告、告警和问答流程。
  • 在飞书中直接问答:也可以让运营人员在飞书里直接向问答智能体提问,不需要打开工作台。做法是部署一个中继服务,运行在自己的服务器上:订阅飞书消息事件,调用会话 API 获取回答,再发回飞书会话。本案例未包含这一中继服务。

下一步

配置社区巡检计划

创建巡检计划并查看每次运行记录。

保存 Discord 与飞书凭据

保存 Discord 与飞书访问凭据。

归档社区知识与简报

跨会话保存采集进度和简报归档。