出海产品的 Discord 社区每天新增上百条多语种消息。人工运营时，一条消息从发出到被看到通常需要 数小时，夜间和周末的消息只能堆积到下一个工作日；将一周的反馈整理成周报，通常还需要半天。
本案例用三个 Kimi 托管智能体完成同样的工作：巡检智能体 每小时 读取新消息，归类、登记待办并附回复草稿；告警智能体 每 30 分钟 筛查风险反馈，夜间和周末同样生效；问答智能体回答对历史讨论和简报的查询。日报、周报由智能体自动生成。回复草稿经人工审核后才发送。
本案例用 Discord 作为消息来源、飞书多维表格（Base）存放整理后的数据，并自建一个 Web 运营工作台。开发者也可以沿用这一设计接入其他社区和数据系统，并相应调整访问凭据、接口调用和数据字段。
Agent 架构总览
Kimi 托管智能体负责巡检、回复草稿生成、报告、告警和问答任务。运营人员通过自建 Web 工作台查看结果、追问社区动态；通过飞书多维表格审批智能体的回复方案和草稿。
收集新消息：巡检智能体每小时读取一次指定频道。系统记录各频道最后读取的消息 ID 作为采集进度，下次巡检从该消息之后继续读取。
分层登记：将有信息量的消息整理后写入飞书多维表格，并把需要人工处理的事项单独列成待办。
准备与发送回复：巡检智能体为需要回应的事项生成回复草稿，运营人员在待处理事项表中修改并确认，应用发送后记录结果。
主动汇报：日报说明当日需要处理的事项和社区动态，周报汇总一周趋势；发现疑似服务异常、安全风险等需要尽快核实的反馈时，单独通知飞书运营群。
继续追问：运营人员可以询问近期高频问题、未处理事项或历史变化，问答智能体基于社区消息摘要和简报回答。
核心设计
三个智能体分工
巡检与报告智能体：收集和整理社区消息，为需要回应的事项生成草稿，并生成日报与周报。
告警智能体：独立识别需要尽快核实的风险反馈并通知运营人员，不承担常规分类和报告任务。
问答智能体：响应运营人员的提问，查询已整理的数据，必要时核对原消息。
巡检与报告共用数据整理和写作规则，因此由同一个智能体执行。
两层数据：信息与待办
采集结果写入飞书多维表格的两张表：
| 数据表 | 写入内容 | 用途 |
|---|---|---|
| 社区消息摘要 | 有信息量的消息摘要、时间、频道、作者显示名、分类、反应数和消息链接 | 查看社区讨论的话题、升温趋势和值得关注的分享 |
| 待处理事项 | 需要处理的提问、反馈和风险，以及回复草稿、来源和跟进状态 | 确定待办与负责团队，审核回复并持续跟进 |
同一问题被多人提及时，不在待处理事项表中重复新增记录，而是更新已有记录的出现次数、最近出现时间和相关消息链接。运营人员可以在同一条待办中查看该问题的出现次数和相关反馈。
仅在两张表都写入成功后，智能体才更新采集进度。写入失败时保留原进度，下一轮重新处理这批消息，并按消息 ID 查重，避免重复登记。
以下示意场景说明数据如何支持运营工作：
| 社区场景 | 应用处理方式 | 运营人员跟进方式 |
|---|---|---|
| 多名成员反馈同一个使用问题 | 聚合成一条行动事项，保留不同反馈的来源 | 核实原因，准备回应 |
| 成员分享有价值的使用经验或作品 | 记入社区消息摘要 | 查看内容，决定是否联系作者、邀请补充或推荐 |
| 某个产品建议持续引发讨论 | 汇总诉求、分歧和相关消息 | 与产品团队讨论，再向社区解释处理决定 |
值得关注的分享不一定需要处理；只有需要运营人员采取行动时，才进入待处理事项表。
定时任务分工
巡检将社区消息整理成消息摘要、待办事项和回复草稿；告警只筛选需要尽快核实的风险反馈，并通知运营人员。两项任务分别配置运行计划。
两项任务会读取同一批频道，但产出不同：巡检用于日常跟进，告警用于优先提醒，不替代实时故障监控。
本案例的定时任务分工如下：
| 任务 | 频率 | 产出 |
|---|---|---|
| 日常巡检 | 每小时 | 更新社区消息摘要和待处理事项 |
| 日报 | 每天晚间 | 说明当天需要处理的事项和社区动态 |
| 周报 | 每周一 | 汇总上周趋势、未解决事项、活跃成员和值得整理成常见问题解答的高频提问 |
| 紧急告警 | 每 30 分钟 | 发现需要尽快核实的风险反馈时通知飞书运营群，其余时间不发送消息 |
日报和周报从已经整理好的数据中生成，不需要再次通读 Discord 原消息。
集中维护共享规则
巡检、报告、告警和问答共用的行为规则和数据约定统一保存在记忆库中的 rules.md，避免多份规则出现版本不一致。系统提示词定义各智能体的职责，运行配置则随任务指令提供：
| 配置位置 | 适用内容 |
|---|---|
rules.md | 多个智能体共享的分类、判断、写作和安全规则，以及稳定的数据约定 |
| 系统提示词 | 当前智能体的角色和职责，以及开始任务前读取 rules.md 的要求 |
定时任务触发器 initial_events | 本轮任务的目标、处理流程，以及使用的频道、表格、群组和文件路径 |
配置选择
三个智能体统一使用 kimi-k2.6 模型，主要基于两点考虑：高频且流程固定的任务优先选用轻量模型；模型的多语言理解和问答能力可满足社区日常产品咨询需求，减少人工运营工作量。三个智能体均通过系统提示词和内置工具完成任务，未额外挂载技能、插件或 MCP 服务。各项资源的配置如下：
运行成本
以一个日增约 100 条消息的 Discord 社区为例，各智能体单轮任务成本如下：
| 智能体任务 | 内容 | 单轮成本 |
|---|---|---|
| 社区巡检 | 拉取新消息、分类，写入社区消息摘要和待处理事项 | 约 ¥1 / 轮 |
| 紧急告警 | 持续扫描需要尽快核实的风险反馈（故障、诈骗、泄露凭据等），无事静默 | 约 ¥0.6 / 轮 |
| 日报生成 | 汇总当日待处理事项与社区动态，成文并发布 | 约 ¥1.5 / 份 |
| 周报生成 | 全周数据聚合分析，成文并发布 | 约 ¥2 / 份 |
| 社区问答 | 运营人员按需提问，查询社区数据与历史简报 | 按实际用量计 |
从最小版本开始搭建
先让巡检稳定地将新消息整理到飞书多维表格，再检查回复草稿是否便于审核，逐步接入日报、周报、告警、问答和运营工作台。
1. 准备消息来源和数据表
在 Discord Developer Portal 创建 Discord Bot，用于读取社区消息，只授予 View Channel 和 Read Message History 权限，不在社区中发言。在飞书开放平台创建应用，并在一个多维表格中准备社区消息摘要和待处理事项两张表。
在 Discord Developer Portal 中打开刚创建的应用，进入 Bot 页面，在 Token 区域点击 Reset Token 生成 Bot Token。Token 只在生成时完整显示一次，生成后立即复制保存。
在飞书开放平台开发者后台打开自建应用，进入凭证与基础信息页面，复制 App ID 和 App Secret。
将 Discord Bot Token 和飞书应用的 App ID、App Secret 写入凭据库，再创建一个只允许访问 Discord 与飞书 API 主机的执行环境。具体操作分别见 凭据库 和 执行环境。
多维表格的 app_token 和 table_id 无需存入凭据库，可直接从浏览器地址栏的链接中获取，链接结构如下：
https://example.feishu.cn/base/<app_token>?table=<table_id>&view=<view_id>/base/ 之后的一段是 app_token，table 参数的值是当前数据表的 table_id。在多维表格中切换数据表时，table 参数随之变化，分别打开社区消息摘要和待处理事项两张表，复制各自的 table_id，后续配置触发器时使用。
创建一个记忆库，用于保存 rules.md、采集进度和后续生成的简报，创建方法见 记忆。在记忆库中创建 rules.md，写入本案例共享的数据约定和行为规则。
rules.md 示例：
# 数据地图
- 社区消息摘要：保存值得关注的社区消息和来源。
- 待处理事项：保存需要人工处理的问题、反馈和风险，以及建议草稿、来源和跟进状态。
# 行为纪律
- 只登记与产品或社区运营直接相关的内容。
- 相同问题优先聚合，不重复创建事项。
- 信息不足时标记不确定，不补写无法确认的事实。
- 涉及具体反馈时保留原 Discord 消息链接。
- 回答时区分事实、趋势和推断，数据不足时明确说明，不根据单条消息推断社区整体观点。
- 只保存运营所需的信息，不复制完整消息流。
- 回复草稿结合原讨论和已确认的信息，并附来源，不能只依据最后一条消息。
- 信息不足时列出待核实内容，不编造解决方案，不承诺未经确认的修复时间或产品计划。
- 生成或更新回复草稿时，只修改建议草稿和来源，不覆盖人工编辑的回复、审核决定或处理状态。
# 紧急情况
- 发现疑似服务大面积不可用、安全或凭据泄露、影响多名用户的支付异常等反馈时，通知运营人员核实。
- 告警包含反馈摘要、已知的影响线索、判断依据和原消息链接，区分已知信息与待核实内容；没有满足条件的反馈不告警。2. 创建巡检智能体
创建一个智能体，创建方式见 智能体。系统提示词定义它的角色和职责，并要求每轮任务开始前读取 rules.md。
巡检和告警以 read_write 权限挂载同一个记忆库，用于保存采集进度和告警记录。rules.md 由人工维护，三个智能体的系统提示词都应要求只读取、不修改该文件。
系统提示词示例：
你是 Discord 社区巡检智能体。
每轮任务开始前，先读取记忆库中的 rules.md，并遵循其中的行为规则和数据约定。不得修改 rules.md。
你的职责是整理社区运营数据，根据本轮指令执行消息巡检、为需要回应的事项起草回复，或生成周期报告。
频道、数据表、采集进度等运行配置以本轮指令为准。3. 创建巡检触发器
创建触发器时，填写已创建的智能体、执行环境、凭据库和记忆库 ID，并在 initial_events 中配置巡检指令，写清要读取的 Discord 频道、要写入的飞书多维表格，以及保存采集进度的位置。触发器每次运行都会自动发送这段指令，无需重复配置；频道、表格或任务要求变化时，再更新指令。
访问 Discord 和飞书所需的凭据提前存入凭据库，不写入指令。
下面是创建触发器请求体的关键结构：
触发器字段、手动运行和运行记录见 定时任务。
4. 验证巡检结果
首次手动运行巡检，确认各频道已记录当前最新消息 ID 作为起点，没有拉取历史消息。后续频道出现新消息后，再运行巡检，确认消息已写入社区消息摘要、需要处理的事项已进入待处理事项，并检查消息链接是否能打开对应原文。再次运行时，确认它从上次记录的位置继续读取，没有重复登记已处理的消息。
5. 生成并审核回复草稿
运营人员在待处理事项表中查看智能体生成的回复草稿，并确认回复目标。
应用在下一轮巡检中，发送审核确认后的内容，并将结果写回对应事项。
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 应用，也可以直接接入团队已有的内部运营系统。工作台包含数据看板和问答入口。下图是一个运营看板的示例界面，开发者可以根据自身需求定制看板。
待办、简报和回复草稿附有来源，运营人员可以回到原网页核实，再决定如何回应。
看板和问答入口使用不同的数据路径：
| 工作台能力 | 数据路径 |
|---|---|
| 待办、社区动态、日报、周报和告警 | 工作台服务端读取飞书多维表格和记忆库中的结果，不调用智能体 |
| 社区问答 | 通过托管智能体 API 创建或复用会话，将问题发送给问答智能体 |
问答的调用链如下：
运营人员输入问题
↓
运营工作台服务端
↓
创建或复用会话
↓
发送 user.message
↓
问答智能体
↓
返回答案和原消息链接Kimi 托管智能体 API Key 只保存在工作台服务端，浏览器前端不直接调用。创建会话时传入问答智能体、执行环境、凭据库和记忆库 ID，与触发器使用的资源相同；复用同一会话可以支持连续追问。会话的创建和消息发送方式见 会话。
11. 验证完整工作流
全部配置完成后，按完整流程验证一次：
巡检：首次运行只记录当前最新消息 ID，不拉取历史消息；后续运行只读取新增消息，不重复登记；原消息链接可以打开。
报告：手动运行日报和周报触发器，检查报告的数据来源和统计时间范围。
告警：用普通消息运行一轮，确认不发送飞书通知；构造一条需要尽快核实的反馈后运行，确认通知包含原消息链接，并区分已知信息与待核实内容；再次运行时同一事件不重复告警。
问答：通过会话 API 或已接入的运营工作台提出一个典型问题，确认回答基于社区消息摘要、待处理事项和历史简报，涉及具体反馈时返回原消息链接。
修改规则后，巡检和告警在下一轮任务开始时重新读取 rules.md，无需更换复用的会话；日报和周报在下次新建会话时读取。问答智能体在会话开始时读取规则，如需立即使用新规则，应创建新的问答会话。
可扩展方向
接入更多社区数据源：接入 Discourse、GitHub Discussions 等社区，将不同平台的消息整理到社区消息摘要和待处理事项中，复用后续的报告、告警和问答流程。
在飞书中直接问答：也可以让运营人员在飞书里直接向问答智能体提问，不需要打开工作台。做法是部署一个中继服务，运行在自己的服务器上：订阅飞书消息事件，调用会话 API 获取回答，再发回飞书会话。本案例未包含这一中继服务。
相关文档
配置社区巡检计划：创建巡检计划并查看每次运行记录。
保存 Discord 与飞书凭据：保存 Discord 与飞书访问凭据。
归档社区知识与简报：跨会话保存采集进度和简报归档。