从角色聊天机器人到社区系统
我独立部署并持续迭代了一个面向角色／兴趣社区的多人 AI 陪伴机器人平台。QQ 是有实际运行证据的参考部署；Discord 完成了端到端验证，但没有长期运营指标。
难点不只是让模型生成符合角色的回复。底层模型并未针对这个角色或社区训练；机器人还要避免逐句抢话、多人同时写入状态时失效，或成为扰乱社区互动的目标。
2026 年 5 至 7 月间，QQ 参考部署累计实际运行 22 天，记录到 5,689 次 DeepSeek 核心模型调用。这不是连续运行期：约有一到两周因我无暇维护而离线。部署所在社区有 5,000+ 成员；300+ 指该期间在群内多次发言、并与机器人有一定互动的周期活跃成员，不是并发用户，也不是回复数。
我的职责与平台边界
我负责 QQ 部署、持续功能迭代、运行复盘与用户反馈分析。我实现了网页数据采集与知识准备流程、分层安全与模型路由规则、多用户处罚逻辑、时间与随机事件人格行为、QQ 表情采集替代插件，以及运行配置和测试。
AstrBot、OneBot/NapCat、RAG 与长期记忆是集成并扩展的框架或生态能力，并非我从零构建的系统。我对参考上游思路的 enhance-mode 和 life-scheduler 做了大幅改造；其中的核心漏斗与事件逻辑由我设计。
这是一张用于解释案例主线的简化图；公开仓库保留了更完整的部署拓扑、插件结构和运行细节。
校准角色一致性与互动节奏
当回答不像角色口癖、过度迎合用户，或让用户把角色带离设定边界时，我会持续更新角色系统提示。每次更新后，我会结合群聊反馈、对设定集和剧情文本的审阅，以及特定问题测试进行检查；人工审阅与 AI 辅助审查都只作为支持信号，而不替代判断。
这不是训练模型，而是让平台集成的既有模型遵循更清晰、可测试的角色约束。
如果群聊机器人对每句话都立即回应，很快会打断正常对话。我降低了被动回复频率：被触发后，机器人会等待若干消息或一段时间再回应。
同时，它并非完全被动。无人触发时，它可以在时间与事件表的约束下主动互动，但会在深夜保持沉默。这个设计将两个容易冲突的目标分开处理：避免频繁打扰，同时保留有边界的角色存在感。
我将参考上游思路的主动回复能力接入并轻度调整为互动漏斗的一环：它会先将候选消息打包，再交给小型意图模型判断此时是否值得回复；只有判断为需要回复时，才调用更大的回复模型。打包避免在群聊仍在快速推进时反复发送几乎相同的上下文。
为社区实际讨论的世界观补足知识
未经处理的模型会在角色细节、世界观、社区称呼和外号上给出不理想的回答。为了给已有检索能力提供更合适的输入，我从萌娘百科、赛马娘官网等公开来源收集材料，并完成清洗、筛选和文档整理。
框架负责分块和导入知识库。我经过多次尝试选择分块参数，但不把它包装成自研 RAG 技术栈。真正的贡献是准备并调整了一套贴合角色与社区实际问题的知识材料。
反馈支持了这个方向，但它不是大规模研究。44 次浏览带来 25 份匿名回复，其中 16 人重视可靠的被动回复，15 人重视长期偏好与记忆。我据此继续调整互动节奏与世界观知识支持；原始问卷数据不公开。
在昂贵模型调用前处理社区边界
在多人社区里，机器人也会收到攻击性表达、试图绕过角色或安全约束的输入，以及情绪勒索式的提示注入。我设计了分层处理路径：黑白名单与轻量／本地模型分类在调用更重的生成模型前运行。风险输入会被忽略或拦截，安全输入才继续生成回复。
重复违规按 12、24、48 小时逐步加重限制，并在一周后重置。QQ 参考部署中，这些规则实际拦截了约 4 条明显攻击意图的信息，也能处理部分谐音和暗示性表达。机器人的自身忽略或封禁路径在运行中被使用；QQ 管理员封禁是独立设计选项，但机器人未获管理员权限，因此我不声称它已在实际运行中执行过管理员封禁。
解决一次真实的 SQLite 写入竞争故障
多人同时写入记忆或状态时，机器人可能仍在运行却停止回复；群成员合理地会以为它未开启。我通过运维侧的 database is locked 报错定位到问题。
经过多次尝试后，我加入 SQLite WAL 和针对性的 PRAGMA 配置来处理写入竞争，而没有引入额外数据库服务。该部署中观察到的这类数据库报错得到解决。这是一个符合当前范围的可靠性取舍，而不是声称 SQLite 适用于所有规模或负载。
证据、限制与反思
本案例的运行证据来自 QQ 部署。Discord 只证明多渠道接入链路已完成端到端验证。仓库包含部署配置、SQLite 补丁、插件扩展和测试；聊天记录、问卷导出、密钥与可识别信息均保持私有。
项目后续的限制不只来自技术质量。持续运行还取决于维护投入和社区采用：并非所有传统群聊成员都欢迎 AI 参与者，付费意愿也不会自然覆盖持续运营成本。这让我更明确地区分“功能可用”和“社区能长期维持的产品”。