> ## Documentation Index
> Fetch the complete documentation index at: https://platform.kimi.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# 出海社群运营智能体设计
> 使用 Kimi 托管智能体整理 Discord 社区反馈、生成简报和回复草稿，基于历史问答，并在人工审核后批量发送消息。
出海产品的 Discord 社区每天新增上百条多语种消息。靠人工运营，一条消息从发出到被看到通常要等 **数小时**，夜间和周末的消息只能堆积到下一个工作日；把一周的反馈整理成周报，通常还要再花半天。
本案例用三个 Kimi 托管智能体完成同样的工作：巡检智能体 **每小时** 读取新消息，归类、登记待办并附回复草稿；告警智能体 **每 30 分钟** 筛查风险反馈，夜间和周末同样生效；问答智能体回答对历史讨论和简报的查询。日报、周报由智能体自动生成，一份周报的成本 **约 ¥2**。回复草稿经人工审核后才发送。
全天运行成本 **约 ¥54**，折算每月 **约 ¥1,600**，比一名专职多语种运营的人力成本低 **一个数量级**。测算过程见运行成本一节。
本案例用 Discord 作为消息来源、飞书多维表格（Base）存放整理后的数据，并自建一个 Web 运营工作台。开发者也可以沿用这一设计接入其他社区和数据系统，并相应调整访问凭据、接口调用和数据字段。
## Agent 架构总览
Kimi 托管智能体负责巡检、回复草稿生成、报告、告警和问答任务。运营人员通过自建 Web 工作台查看结果、追问社区动态；通过飞书多维表格审批智能体的回复方案和草稿。
1. **收集新消息**：巡检智能体每小时读取一次指定频道。系统记录各频道最后读到的消息代码，作为采集进度，下次巡检从这条消息之后继续读取。
2. **分层登记**：将有信息量的消息整理后写入飞书多维表格，并把需要人工处理的事项单独列成待办。
3. **准备与发送回复**：巡检智能体为需要回应的事项生成草稿，运营人员在待处理事项表中修改、确认，应用发送后记录结果。
4. **主动汇报**：日报说明今天需要处理的事项和社区动态，周报汇总一周趋势；发现疑似服务异常、安全风险等需要尽快核实的反馈时，单独通知飞书运营群。
5. **继续追问**：运营人员可以询问近期高频问题、未处理事项或历史变化，问答智能体基于社区消息摘要和简报回答。
## 核心设计
### 三个智能体分工
* **巡检与报告智能体**：收集和整理社区消息，为需要回应的事项生成草稿，并生成日报与周报。
* **告警智能体**：独立识别需要尽快核实的风险反馈并通知运营人员，不承担常规分类和报告任务。
* **问答智能体**：响应运营人员的提问，查询已整理的数据，必要时核对原消息。
巡检与报告共用数据整理和写作规则，因此由同一个智能体执行。
### 两层数据：信息与待办
采集结果写入飞书多维表格的两张表：
| 数据表 | 写入什么 | 用途 |
| - | - | - |
| 社区消息摘要 | 有信息量的消息摘要、时间、频道、作者显示名、分类、反应数和消息链接 | 查看社区讨论的话题、升温趋势和值得关注的分享 |
| 待处理事项 | 需要处理的提问、反馈和风险，以及回复草稿、来源和跟进状态 | 确定待办与负责团队，审核回复并持续跟进 |
同一个问题被多人提起时，不在待处理事项表中重复新增记录，而是更新已有记录的出现次数、最近出现时间和相关消息链接。运营人员可以在同一条待办中查看这个问题的出现次数和相关反馈。
两张表都写入成功后，智能体才更新采集进度。写入失败时保留原进度，下轮重新处理这批消息，并按消息 ID 查重，避免重复登记。
下面用几个示意场景说明数据如何支持运营工作：
| 社区里发生什么 | 应用如何整理 | 运营人员如何跟进 |
| - | - | - |
| 多名成员反馈同一个使用问题 | 聚合成一条行动事项，保留不同反馈的来源 | 核实原因，准备回应 |
| 成员分享有价值的使用经验或作品 | 记入社区消息摘要 | 查看内容，决定是否联系作者、邀请补充或推荐 |
| 某个产品建议持续引发讨论 | 汇总诉求、分歧和相关消息 | 与产品团队讨论，再向社区解释处理决定 |
值得关注的分享不一定需要处理；只有需要运营人员采取行动时，才进入待处理事项表。
### 定时任务分工
巡检将社区消息整理成消息摘要、待办事项和回复草稿；告警只筛选需要尽快核实的风险反馈，并通知运营人员。两项任务分别配置运行计划。
两项任务会读取同一批频道，但产出不同：巡检用于日常跟进，告警用于优先提醒，不替代实时故障监控。
本案例的定时任务分工如下：
| 任务 | 频率 | 产出 |
| - | - | - |
| 日常巡检 | 每小时 | 更新社区消息摘要和待处理事项 |
| 日报 | 每天晚间 | 说明当天需要处理的事项和社区动态 |
| 周报 | 每周一 | 汇总上周趋势、未解决事项、活跃成员和值得整理成常见问题解答的高频提问 |
| 紧急告警 | 每 30 分钟 | 发现需要尽快核实的风险反馈时通知飞书运营群，其余时间不发送消息 |
日报和周报从已经整理好的数据中生成，不需要再次通读 Discord 原消息。
### 集中维护共享规则
巡检、报告、告警和问答共用的行为规则和数据约定统一维护在记忆库中的 `rules.md`，避免分别维护多份规则时出现版本不一致。系统提示词定义各智能体的职责，运行配置则随任务指令提供：
| 放在哪里 | 适合写什么 |
| - | - |
| `rules.md` | 多个智能体共享的分类、判断、写作和安全规则，以及稳定的数据约定 |
| 系统提示词 | 当前智能体的角色和职责，以及开始任务前读取 `rules.md` 的要求 |
| 定时任务触发器 `initial_events` | 本轮任务的目标、处理流程，以及使用的频道、表格、群组和文件路径 |
## 配置选择
三个智能体均通过系统提示词和内置工具完成任务，未额外挂载技能、插件或 MCP 服务。全部任务统一使用 `kimi-k2.6` 模型，选型考虑有两点：高频、流程固定的任务优先选用轻量模型；多语言理解和问答能力足以应对社区中与产品相关的日常问询，减轻运营团队负担。各项资源的配置如下：
| Kimi 托管智能体能力 | 配置选择 |
| - | - |
| [定时任务](/docs/hosted-agents/triggers) | 高频巡检和告警复用托管会话；日报和周报每次创建新会话 |
| [记忆库](/docs/hosted-agents/memory) | 保存共享规则文件 `rules.md`、采集进度、已确认的社区知识和简报归档 |
| [凭据库](/docs/hosted-agents/vaults) | 保存智能体读取 Discord 和访问飞书所需的凭据 |
| [执行环境](/docs/hosted-agents/environments) | 使用受限网络，只放行 Discord 和飞书 API 主机 |
## 运行成本
以一个日增约 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 主机的执行环境。具体操作分别见 [凭据库](/docs/hosted-agents/vaults) 和 [执行环境](/docs/hosted-agents/environments)。
多维表格的 app\_token 和 table\_id 不进凭据库，直接从浏览器地址栏的链接中获取，链接结构如下：
```text theme={null}
https://example.feishu.cn/base/?table=&view=
```
`/base/` 之后的一段是 app\_token，`table` 参数的值是当前数据表的 table\_id。在多维表格中切换数据表时，`table` 参数随之变化，分别打开社区消息摘要和待处理事项两张表，复制各自的 table\_id，后续配置触发器时使用。
创建一个记忆库，用于保存 `rules.md`、采集进度和后续生成的简报，创建方法见 [记忆](/docs/hosted-agents/memory)。在记忆库中创建 `rules.md`，写入本案例共享的数据约定和行为规则。
`rules.md` 示例：
```md theme={null}
# 数据地图
- 社区消息摘要：保存值得关注的社区消息和来源。
- 待处理事项：保存需要人工处理的问题、反馈和风险，以及建议草稿、来源和跟进状态。
# 行为纪律
- 只登记与产品或社区运营直接相关的内容。
- 相同问题优先聚合，不重复创建事项。
- 信息不足时标记不确定，不补写无法确认的事实。
- 涉及具体反馈时保留原 Discord 消息链接。
- 回答时区分事实、趋势和推断，数据不足时明确说明，不根据单条消息推断社区整体观点。
- 只保存运营所需的信息，不复制完整消息流。
- 回复草稿结合原讨论和已确认的信息，并附来源，不能只依据最后一条消息。
- 信息不足时列出待核实内容，不编造解决方案，不承诺未经确认的修复时间或产品计划。
- 生成或更新回复草稿时，只修改建议草稿和来源，不覆盖人工编辑的回复、审核决定或处理状态。
# 紧急情况
- 发现疑似服务大面积不可用、安全或凭据泄露、影响多名用户的支付异常等反馈时，通知运营人员核实。
- 告警包含反馈摘要、已知的影响线索、判断依据和原消息链接，区分已知信息与待核实内容；没有满足条件的反馈不告警。
```
### 2. 创建巡检智能体
创建一个智能体，创建方式见 [智能体](/docs/hosted-agents/agents)。系统提示词定义它的角色和职责，并要求每轮任务开始前读取 `rules.md`。
巡检和告警以 `read_write` 权限挂载同一个记忆库，用于保存采集进度和告警记录。`rules.md` 由人工维护，三个智能体的系统提示词都应要求只读取、不修改该文件。
系统提示词示例：
```text theme={null}
你是 Discord 社区巡检智能体。
每轮任务开始前，先读取记忆库中的 rules.md，并遵循其中的行为规则和数据约定。不得修改 rules.md。
你的职责是整理社区运营数据，根据本轮指令执行消息巡检、为需要回应的事项起草回复，或生成周期报告。
频道、数据表、采集进度等运行配置以本轮指令为准。
```
### 3. 创建巡检触发器
创建触发器时，填写已创建的智能体、执行环境、凭据库和记忆库 ID，并在 `initial_events` 中配置巡检指令，写清要读取的 Discord 频道、要写入的飞书多维表格，以及保存采集进度的位置。触发器每次运行都会自动发送这段指令，无需重复配置；频道、表格或任务要求变化时，再更新指令。
访问 Discord 和飞书所需的凭据提前存入凭据库，不写入指令。
下面是创建触发器请求体的关键结构：
```json theme={null}
{
"name": "社区巡检",
"agent_id": "agent_your_agent_id",
"environment_id": "env_your_environment_id",
"session_mode": "reuse_session",
"policy": {
"type": "cron",
"expression": "7 * * * *",
"timezone": "Asia/Shanghai"
},
"resources": [
{"type": "vault", "vault_id": "vlt_your_vault_id"},
{
"type": "memory_store",
"memory_store_id": "mstr_your_memory_store_id",
"access": "read_write"
}
],
"initial_events": [
{
"type": "user.message",
"data": {
"content": [
{
"type": "text",
"text": "巡检 Discord 频道：<频道 ID 列表>。从记忆库中的 <采集进度文件路径> 读取各频道的采集进度，文件不存在时创建。没有进度记录的频道，首次只记录当前最新消息 ID 作为起点并保存，不拉取历史消息；已有进度记录的频道，才获取记录位置之后的新消息。将新消息摘要写入飞书社区消息摘要表，将需要人工处理的事项写入待处理事项。为需要回应的事项生成建议草稿并保存来源，遵循 rules.md 中的草稿规则，不覆盖人工编辑和审核决定。飞书 app_token 为 ，社区消息摘要表 ID 为 <消息摘要表 ID>，待处理事项表 ID 为 <待处理事项表 ID>。写入前按消息 ID 查重；新消息全部写入成功后，才将新的采集进度保存回原文件；写入失败时保留原进度。"
}
]
}
}
]
}
```
触发器字段、手动运行和运行记录见 [定时任务](/docs/hosted-agents/triggers)。
### 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`。
创建告警触发器请求体的关键结构：
```json theme={null}
{
"name": "紧急告警",
"agent_id": "agent_your_alert_agent_id",
"environment_id": "env_your_environment_id",
"session_mode": "reuse_session",
"policy": {
"type": "cron",
"expression": "*/30 * * * *",
"timezone": "Asia/Shanghai"
},
"resources": [
{"type": "vault", "vault_id": "vlt_your_vault_id"},
{
"type": "memory_store",
"memory_store_id": "mstr_your_memory_store_id",
"access": "read_write"
}
],
"initial_events": [
{
"type": "user.message",
"data": {
"content": [
{
"type": "text",
"text": "检查 Discord 频道：<频道 ID 列表> 是否有需要尽快核实的风险反馈。从记忆库中的 <告警采集进度文件路径> 读取告警任务自己的采集进度，获取各频道该位置之后的新消息，只按 rules.md 中的紧急情况定义判断，不做常规分类。没有符合条件的反馈时不发送任何消息。发现符合条件的反馈时，向飞书运营群 <群 ID> 发送通知，包含反馈摘要、已知的影响线索、判断依据和 Discord 原消息链接，并区分已知信息与待核实内容；通知前先从 <已告警记录文件路径> 读取已告警记录，已告警的事件不再通知。全部处理完成后，保存已告警记录并更新告警采集进度。"
}
]
}
}
]
}
```
### 9. 创建问答智能体
创建第三个智能体，面向运营人员的交互式查询。问答智能体不需要定时触发器，由运营人员的提问驱动，接入方式见下一节。
问答智能体优先查询社区消息摘要、待处理事项、记忆库中归档的历史日报和周报，以及已确认的社区知识；需要核对原文或补充上下文时，通过同一 Discord Bot 读取原消息。
在系统提示词中要求问答智能体在会话开始时读取 `rules.md`。
创建后用少量典型问题验证回答质量，例如「最近一周 API rate limit 相关反馈有哪些」「哪些问题被多人反复提起但还没有解决」。
### 10. 将智能体能力接入运营工作台
运营工作台是一个独立的 Web 应用，也可以直接接入团队已有的内部运营系统。工作台包含数据看板和问答入口。下图是一个运营看板的示例界面，开发者可以根据自身需求定制看板。
待办、简报和回复草稿附有来源，运营人员可以回到原网页核实，再决定如何回应。
看板和问答入口使用不同的数据路径：
| 工作台能力 | 数据路径 |
| - | - |
| 待办、社区动态、日报、周报和告警 | 工作台服务端读取飞书多维表格和记忆库中的结果，不调用智能体 |
| 社区问答 | 通过托管智能体 API 创建或复用会话，将问题发送给问答智能体 |
问答的调用链如下：
```text theme={null}
运营人员输入问题
↓
运营工作台服务端
↓
创建或复用会话
↓
发送 user.message
↓
问答智能体
↓
返回答案和原消息链接
```
Kimi 托管智能体 API Key 只保存在工作台服务端，浏览器前端不直接调用。创建会话时传入问答智能体、执行环境、凭据库和记忆库 ID，与触发器使用的资源相同；复用同一会话可以支持连续追问。会话的创建和消息发送方式见 [会话](/docs/hosted-agents/sessions)。
### 11. 验证完整工作流
全部配置完成后，按完整链路验证一轮：
* **巡检**：首次运行只记录当前最新消息 ID，不拉取历史消息；后续运行只读取新增消息，不重复登记；原消息链接可以打开。
* **报告**：手动运行日报和周报触发器，检查报告的数据来源和统计时间范围。
* **告警**：用普通消息运行一轮，确认不发送飞书通知；构造一条需要尽快核实的反馈后运行，确认通知包含原消息链接，并区分已知信息与待核实内容；再次运行时同一事件不重复告警。
* **问答**：通过会话 API 或已接入的运营工作台提出一个典型问题，确认回答基于社区消息摘要、待处理事项和历史简报，涉及具体反馈时返回原消息链接。
修改规则后，巡检和告警在下一轮任务开始时重新读取 `rules.md`，无需更换复用的会话；日报和周报在下次新建会话时读取。问答智能体在会话开始时读取规则，如需立即使用新规则，应创建新的问答会话。
## 可扩展方向
* **接入更多社区数据源**：接入 Discourse、GitHub Discussions 等社区，将不同平台的消息整理到社区消息摘要和待处理事项中，复用后续的报告、告警和问答流程。
* **在飞书中直接问答**：也可以让运营人员在飞书里直接向问答智能体提问，不需要打开工作台。做法是部署一个中继服务，运行在自己的服务器上：订阅飞书消息事件，调用会话 API 获取回答，再发回飞书会话。本案例未包含这一中继服务。
## 下一步
创建巡检计划并查看每次运行记录。
保存 Discord 与飞书访问凭据。
跨会话保存采集进度和简报归档。