我不是第一次折腾 QQ bot。
很早之前，大语言模型还没这么火的时候，我就用 NoneBot 写过一个 QQ 机器人。那时候接 QQ 用的还是 go-cqhttp，用户发一句话过来，后面基本靠结巴分词、关键词和自己写的一堆规则来判断该触发哪个功能。
当时也不是完全不能用。我做过一个查学校电费的功能：学校网站写得比较随意，前端请求稍微抓一下就能看到接口，所以 bot 里包了一层，用户在 QQ 里发宿舍号，就能查到剩余电费。功能很简单，但确实解决问题。
只是现在回头看，那种写法的上限很低。
它更像是在 QQ 里挂了一堆命令。用户刚好说中关键词，就能触发；用户换个说法，就要继续补规则。比如”查电费""宿舍还剩多少电""是不是快没电了”，人一看就知道是一个意思，但以前那套规则系统不一定知道。更麻烦的是，你还得不断告诉用户应该怎么说、命令格式是什么。功能一多，机器人就开始变得又硬又蠢。
所以那一代 bot 能用，但不好用。它的核心其实不是理解用户，而是等用户说中暗号。
这次想换一种写法#
现在不一样了。
大语言模型出来之后，尤其是 Codex、Claude Code 这类 Agent 工具出现之后，我对”个人助手”这件事的期待变了。以前是人去适应 bot 的命令，现在更应该是 bot 去理解人的说法，然后自己决定要查什么、调什么工具、怎么把结果组织回来。
所以小青团这次没有把重点放在传统的插件触发上。
NoneBot 当然还在用，OneBot V11、WxClaw 也还在项目里，但它们现在只是入口层。QQ、微信、CLI 收到消息后，先把消息格式统一一下，再交给同一个 Agent Core。真正决定下一步怎么做的，不是某个插件里的关键词判断，而是 LLM 的 function calling。
也就是说，我不想再给每个功能写一套”用户说了什么才触发我”的逻辑。功能应该被包装成工具，模型根据上下文自己选。
比如查记忆是一个工具，写笔记是一个工具，联网搜索是一个工具，预约座位也是一个工具。工具只需要说明自己叫什么、能做什么、参数长什么样、风险高不高。至于什么时候调用、怎么填参数、调用完怎么继续说，都交给模型。
这比以前舒服很多。以前加功能像是在加插件和命令，现在更像是在给 Agent 扩工具箱。
MCP 也是这个思路的延伸。复杂一点的能力，不一定非要塞进小青团主项目，可以单独做成一个 MCP server，小青团只负责接入和调用。这样主项目不会越来越臃肿，也方便以后把某些能力单独部署、单独维护。
小青团现在是什么#
现在的小青团，我更愿意把它看成一个接在 QQ / 微信上的个人任务型 Agent，而不是一个普通聊天机器人。
聊天只是入口。真正想做的是这些事：
- 能多轮对话，不用每次从零开始。
- 能调用工具，而不是只生成文本。
- 能记住长期偏好和规则。
- 能查自己的 Wiki 和索引。
- 能区分不同用户，不把记忆串在一起。
- 涉及提交、预约这类操作时，先问一句确认。
- 出问题以后能从日志里追溯发生了什么。
举个很小的例子。
如果我说：
我以后图书馆优先坐二楼安静区它不应该只是回一句”好的”。这句话应该变成一条长期偏好，落到记忆系统里。
以后我再问：
我一般喜欢坐哪里？它应该去查记忆，而不是靠当前上下文猜。
如果我说：
帮我约明天上午二楼安静区的座位它可以先查偏好，再查座位。如果真要提交预约，就停下来问我确认；确认后再执行，取消就不动。
这和早期 QQ bot 的感觉很不一样。以前是”说中命令，然后插件执行”，现在更像是”说出目标，然后 Agent 自己组合工具”。
真正麻烦的是记忆#
工具调用这件事，有了 function calling 和 MCP 之后，反而没有以前那么别扭。真正麻烦的是记忆系统。
个人 Agent 如果没有记忆，每次都像新来的，能做的事情就很有限。但记忆也不是简单地把所有聊天记录塞进向量库。
很多 RAG 系统会把文档切 chunk、做父子检索，再丢到向量库里。这在问答场景里很常见，也不是不好用。但如果把它当成个人长期记忆，我觉得问题很明显。
首先是人看不懂。chunk 是机器切出来的，可能从一个段落中间开始，又在另一个地方结束。检索效果也许还行，但你很难打开它、像看笔记一样维护它。
其次是太容易什么都存。聊天里的临时话、重复话、已经过期的偏好、工具返回的一堆中间结果，如果都进长期记忆，后面召回的时候就会污染判断。看起来记得很多，实际上可能更乱。
还有冲突问题。今天我说喜欢三楼靠窗，明天我又说三楼太吵、以后二楼安静区优先。如果只是存了两段文本，检索时两段都回来，模型到底信哪个？旧偏好是不是过期了？谁来解释？
所以我不太想把小青团的长期记忆做成”向量库里一堆文本片段”。
我更倾向于知识图谱那种思路：记忆应该尽量是事实、关系、偏好、规则，而不是一团聊天记录。比如”我偏好二楼安静区""图书馆预约提交前需要确认""某个账号属于某个人”。这些东西更像结构化知识，也更适合长期维护。
但我也不想上来就搞一个很重的图数据库。对个人项目来说，最重要的是能看、能改、能回滚。于是最后选了 Wiki-first。
为什么用 Wiki 做记忆源#
小青团的长期记忆，权威源是 Markdown Wiki。
这里的意思不是说不用向量检索，也不是说直接拿 Markdown 全文搜索就完事。我的想法是把几层东西分清楚：
SQLite events 记录发生过什么
Markdown Wiki 记录现在相信什么
FTS5 / LanceDB / memories 负责从 Wiki 里把东西找出来events 是流水：用户说了什么、助手回了什么、工具调了什么、确认了什么，都追加进去。它解决的是追溯问题。
Wiki 是长期知识：偏好、规则、项目上下文、重要记录，都应该沉淀成能读懂的 Markdown。它解决的是”现在系统到底记住了什么”。
FTS5、LanceDB、memories 这些是索引。它们负责召回，但不是事实源。坏了可以删掉重建，Wiki 不能丢。
这个区别很重要。
如果一个 Agent 说它记住了我喜欢二楼安静区，我希望我能打开文件看到类似这样的内容：
## 当前
- 优先二楼安静区
- 提交预约前必须二次确认
## 历史
- 2026-06-20~2026-06-23：曾偏好三楼靠窗这样我才知道它到底记了什么。记错了，我也能直接改。Git 还能看到 diff，必要时可以回滚。
这就是 Wiki-first 对我最有吸引力的地方。它不神秘，也不高级，但适合长期维护。
向量库适合召回，不适合当唯一记忆源。它可以帮你找到东西，但不应该决定什么是真的。小青团里 FTS5 和 LanceDB 都只是从 Wiki 派生出来的索引层，真正要维护的是 Wiki。
记忆应该少一点#
我现在越来越觉得，个人 Agent 的记忆不是越多越好。
很多东西没必要长期保存。随口说的话、一次性的上下文、已经完成的临时任务，留在 events 里就够了。真正应该进 Wiki 的，是以后还会影响决策的东西，比如偏好、规则、身份、项目背景、长期任务状态。
所以小青团的流程是先记流水，再抽取候选记忆。不是用户每说一句话都写进 Wiki，而是回复之后再判断有没有值得沉淀的内容。
冲突也不能直接覆盖。
现在的做法很简单：同一个 subject + predicate 出现新值时，新值进入 ## 当前，旧值移到 ## 历史。这还不是特别复杂的冲突系统，但至少不会把旧事实静默删掉，也能让当前决策有明确依据。
后面可以继续加来源优先级、置信度、人工审核队列、关系抽取这些东西。但底线我想保持住：原始日志不覆盖，长期记忆可版本化，索引随时可以重建。
后面想加什么#
小青团现在的底座已经差不多搭起来了：QQ / 微信 / CLI 入口、Agent Core、工具注册、Wiki-first 记忆、Hybrid 检索、多用户隔离、人工确认、MCP 接入和 Docker 部署。
接下来想先做几个更日常的东西。
第一个是图书馆预约。
这部分我不太想直接塞进主项目。预约会涉及登录态、页面自动化、验证码、失败重试，后面维护成本肯定不低。更合适的方式是单独开一个项目，把它打包成 MCP server，小青团只把它当工具调用。这样预约系统坏了，也不会把整个 Agent 拖下水。
第二个是天气提醒。
不只是查天气，而是根据天气主动提醒，比如要不要带伞、降温要不要加衣服。这种东西放在聊天入口里挺自然，因为提醒本来就应该主动推到你面前。
第三个是订阅系统。
比如某个网站、项目、课程公告、论文、软件版本有更新时，自动发消息提醒。即时通讯入口最大的好处就是它很适合做通知，不一定每次都等用户来问。
这些功能看起来散，但底层其实是一回事：工具负责获取和执行，记忆负责保存偏好和规则，订阅系统负责触发，聊天入口负责把结果发给用户。
先跑起来#
现在我想先把这些想法记下来，然后把小青团部署到实验室服务器上跑一段时间。
它本身不算很吃资源。核心就是 NoneBot、LangGraph、SQLite、Wiki 索引，再加一些可选的 embedding 能力。真正重的浏览器自动化预约以后会拆出去。如果跑起来对服务器有影响，那就关掉或者把服务拆开。
这个项目我不打算一口气做成什么大而全的平台。先把入口、Agent Core、记忆系统和工具协议这几块打稳，后面天气、预约、订阅、提醒、自动化查询，都可以慢慢接。
早期 QQ bot 解决的是”怎么在 QQ 里触发一个功能”。
小青团现在想解决的是另一个问题：能不能把 QQ / 微信这种每天都在用的入口，变成一个长期可用、能记住偏好、能调用工具、还能追溯和扩展的个人 Agent。