Agent 架构总览

- 收集新消息:巡检智能体每小时读取一次指定频道。系统记录各频道最后读到的消息代码,作为采集进度,下次巡检从这条消息之后继续读取。
- 分层登记:将有信息量的消息整理后写入飞书多维表格,并把需要人工处理的事项单独列成待办。
- 准备与发送回复:巡检智能体为需要回应的事项生成草稿,运营人员在待处理事项表中修改、确认,应用发送后记录结果。
- 主动汇报:日报说明今天需要处理的事项和社区动态,周报汇总一周趋势;发现疑似服务异常、安全风险等需要尽快核实的反馈时,单独通知飞书运营群。
- 继续追问:运营人员可以询问近期高频问题、未处理事项或历史变化,问答智能体基于社区消息摘要和简报回答。
核心设计
三个智能体分工
- 巡检与报告智能体:收集和整理社区消息,为需要回应的事项生成草稿,并生成日报与周报。
- 告警智能体:独立识别需要尽快核实的风险反馈并通知运营人员,不承担常规分类和报告任务。
- 问答智能体:响应运营人员的提问,查询已整理的数据,必要时核对原消息。
两层数据:信息与待办
采集结果写入飞书多维表格的两张表:
同一个问题被多人提起时,不在待处理事项表中重复新增记录,而是更新已有记录的出现次数、最近出现时间和相关消息链接。运营人员可以在同一条待办中查看这个问题的出现次数和相关反馈。
两张表都写入成功后,智能体才更新采集进度。写入失败时保留原进度,下轮重新处理这批消息,并按消息 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 只在生成时完整显示一次,生成后立即复制保存。

/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 应用,也可以直接接入团队已有的内部运营系统。工作台包含数据看板和问答入口。下图是一个运营看板的示例界面,开发者可以根据自身需求定制看板。
问答的调用链如下:
11. 验证完整工作流
全部配置完成后,按完整链路验证一轮:- 巡检:首次运行只记录当前最新消息 ID,不拉取历史消息;后续运行只读取新增消息,不重复登记;原消息链接可以打开。
- 报告:手动运行日报和周报触发器,检查报告的数据来源和统计时间范围。
- 告警:用普通消息运行一轮,确认不发送飞书通知;构造一条需要尽快核实的反馈后运行,确认通知包含原消息链接,并区分已知信息与待核实内容;再次运行时同一事件不重复告警。
- 问答:通过会话 API 或已接入的运营工作台提出一个典型问题,确认回答基于社区消息摘要、待处理事项和历史简报,涉及具体反馈时返回原消息链接。
rules.md,无需更换复用的会话;日报和周报在下次新建会话时读取。问答智能体在会话开始时读取规则,如需立即使用新规则,应创建新的问答会话。
可扩展方向
- 接入更多社区数据源:接入 Discourse、GitHub Discussions 等社区,将不同平台的消息整理到社区消息摘要和待处理事项中,复用后续的报告、告警和问答流程。
- 在飞书中直接问答:也可以让运营人员在飞书里直接向问答智能体提问,不需要打开工作台。做法是部署一个中继服务,运行在自己的服务器上:订阅飞书消息事件,调用会话 API 获取回答,再发回飞书会话。本案例未包含这一中继服务。
下一步
配置社区巡检计划
创建巡检计划并查看每次运行记录。
保存 Discord 与飞书凭据
保存 Discord 与飞书访问凭据。
归档社区知识与简报
跨会话保存采集进度和简报归档。