行知01 / SERVICE SCENARIO行知 · 实践记录
从群里的重复问题，开始做起。
产品使用、账号额度、模型与工具配置、常见报错，经常在群里被反复询问。用户 @机器人后，客服结合群内记录和角色约束提供回答。
02 / MESSAGE PIPELINE行知 · 实践记录
把消息接入，和回答串起来。
- 01QQ / NapCatQQ原生客户端连接 QQ 消息
- 02OneBot v11反向 WebSocket 接入 AstrBot
- 03AstrBot + 插件保存消息、追加动态上下文
- 04模型 APIOpenAI 兼容接口生成回复
- NapCatQQ
- 承担 QQ 消息接入。项目采用 Linux 原生部署，以减少实践中容器重启后重新扫码的负担。
- AstrBot
- 承接机器人事件、客服 persona 和模型 provider；群聊记忆插件在模型请求前补充上下文。
- 独立 Web Chat
- 与机器人读取同一份记忆库，并调用模型。可以在网页里测试回答，不需要向真实 QQ 群发消息。
03 / MEMORY行知 · 实践记录
先把记忆存好，再逐步沉淀知识。
当前仓库的记忆插件是最小可用参考实现：原始消息同时写入 SQLite 与 JSONL，在模型请求前注入少量相关群聊。
- 消息记录
- 按群、会话和时间保存消息。SQLite 支持查询，JSONL 便于备份和审计。
- 当前检索方式
- 按当前群限定范围，使用关键词 LIKE 查询；没有命中时取最近记录，默认最多 8 条。它还不是向量数据库检索系统。
- 客服边界
- 注入内容包含客服角色范围、当前群记录总数和相关消息，让回答围绕本群产品、售后和技术排障展开。
- FAQ 扩展方向
- 仓库已定义 FAQ 与总结运行状态表；文档将每日 FAQ 自动总结列为后续扩展。应筛选有明确结论、可长期复用的答案，再保留来源与时间。
- 图片能力
- 当次对话看图排障与长期知识入库是两个环节。后者还需要 OCR 或视觉摘要流程。
实现取舍
先用轻量存储跑通“消息 → 记忆 → 回答”，再依据真实问题补充检索、FAQ 总结与评估。
04 / OPERATIONS行知 · 实践记录
能持续运行，才能持续服务。
- 部署方式
- Linux 原生 NapCat + AstrBot 源码部署，systemd 托管。安装器识别 apt-get、dnf 或 yum，并用 uv 准备 Python 运行环境。
- 验收顺序
- 确认 QQ 在线、OneBot 已连接、消息数增长，再在 Web Chat 测试同一份记忆是否参与回答，最后验证群内 @回复。
- 日常维护
- 查询服务状态、消息入库与上下文命中。修改插件或 provider 时优先重启 AstrBot，避免不必要地打断 QQ 登录状态。
依据仓库 README、记忆系统文档与插件代码整理；核对版本：e02ec85。