起因
我做测试 Agent 做了大半年，agent 的能力一直在涨——需求理解、用例拆解、自动执行测试、业务 agent 评估，甚至还能参与到需求本身的打磨里。从能力列表看，已经挺像回事了。
但有一个问题一直困扰我：agent 到了企业内部系统面前，还是会干蠢事。
举几个真实的例子。agent 去权限系统配权限，用的是普通测试号，在页面上反复点，点了十几次，困惑为什么没反应——因为它不知道这个操作要用管理员账号。还有一次，浏览器被 SSO 重定向到登录页，agent 开始在登录框里老老实实填账号密码，折腾了三分钟——其实直接 navigate 回原来的 URL 就行，SSO 登录态还在。最离谱的一次，它导航到一个正确的管理后台地址，页面因为权限不足显示空白，agent 判断 “这个 URL 不对”，然后满世界找入口去了。
这些错误有个共同点：对一个在公司干了半年的测试同事来说，几乎不可能犯。
一开始我也以为这是模型能力的问题，但看多了之后发现不太对。这些行为背后其实不是 “不会想”，而是 “没在这个环境里待过”。agent 并不缺推理能力，它缺的是那种人在工作中慢慢长出来的经验——那些不会被写进文档，但又在关键时刻决定你会不会踩坑的东西。
所以后来我慢慢意识到，我要解决的不是 “让 agent 更聪明”，而是另一件事：让它在一个具体环境里，逐渐拥有经验。

工作认知
我后来给这类知识起了个名字，叫 “工作认知”。
这些东西很难定义，因为它们几乎不存在于任何正式载体里。你在 wiki 上找不到，在文档里也看不到，但它们确实在团队里稳定存在，而且非常关键。比如 “配权限在测试环境要用谁谁谁的账号”，“测试、uat 环境切人要去 SSO”，“某个系统必须先切完 xxx 的账号，因为他是什么什么角色能使用这个功能”，这些都不是写出来的规则，而是某天有人踩了坑，然后顺口说了一句，慢慢就变成了大家的共识。
更麻烦的是，这类知识通常不是单点的，而是跨系统的。它不是 “这个系统怎么用”，而是 “当你在 A 系统遇到一个问题时，应该去 B 系统，用 C 身份，做 D 操作”。这是一种带有路径感的认知，而不是一个静态的说明。每个老员工脑子里其实都有一张这样的网络，新人要花很时间才能把这张网慢慢补出来。
我一开始是用常规思路去解这个问题的。写文档、做系统画像、做 RAG，把这些知识结构化、向量化，再检索出来。但很快发现这些方法都不太对劲。因为它们默认知识是可以被整理、被分类的，但 “工作认知” 不是这样。它不是 “被整理好的知识”，而是 “被经历过的经验”。文档解决的是 “你知不知道”，但这里的问题更像是 “你有没有在这个环境里做过”。
我最早试过用系统画像来承载这些知识——给每个被测系统写一份 profile，把操作规则、账号信息、注意事项都结构化地写进去。但构建实在太麻烦了，一个系统的画像就要写几千字，还要不断维护更新，几个系统一叠加根本管不过来。
试过做 RAG，把知识写成文档再做向量检索，但这类知识本来就不是"文档"的形态——一条"配权限要用管理员账号"的认知，你说它属于哪个分类？权限管理？账号切换策略？测试前置条件？它哪个都是，哪个都不完全是。
它不在一棵分类树上，它在一张网上。
后来我想，人的大脑是怎么处理这类知识的？不是翻一本手册，而是从记忆里捡起一些碎片做拼图。有点像记忆碎片那个电影，主角没有完整的记忆，但他靠纹身、便条、拍立得照片这些零散的线索，一点一点拼出事情的全貌。人在工作中调用经验，其实也是类似的过程：你不会调出一篇完整的说明，而是想起几个相关的片段，然后在脑子里把它们拼起来。
比如你搜 “怎么配权限”，浮现出来的可能不是一份指南，而是几条零散的认知：权限是在某个系统里配的、要用管理员账号、管理员账号对应的是谁。每一条单独看都不完整，但组合在一起就够用了。
那一刻我意识到，我的问题可能不在 “怎么存知识”，而在 “我选错了知识的单位”。大部分系统默认一篇文档是一条知识，embedding 是最小单元，但人在使用经验的时候，并不是这样运作的。我们不是在读一篇文档，而是在拼几个片段。
所以我做了一个决定：不再存文档，也不做 embedding，而是把每一条认知压缩成一句话（一句话的这个概念更像同事来请教你，你怎么用一句话给他讲清楚）来存。

我的做法
想到这个之后，我很快搭了一个最简单的结构：一张 SQLite 表，每条记录就是一段自然语言的内容，加上一组标签、来源、使用次数和最后使用时间。没有向量，没有复杂结构，也没有分类树，一条认知就是一句话加几个 tag，我把它叫做碎片（fragment）。
碎片长什么样，标签怎么把它们连成网络：

存储变简单之后，关键问题变成了：怎么把这些碎片在需要的时候找出来。我不太想走数据库那种精确匹配的路径，因为那更像是在 “查”，而不是 “想”。我更想模拟一种接近人脑的方式：当你想到一个点的时候，会带出一串相关的东西。
所以检索的逻辑会稍微复杂一点：基础是关键词匹配，加上中文 bigram 提高召回率；包含 URL 或账号信息的碎片会被额外加权，因为这些是可以直接执行的；使用次数会提供一个温和的权重，但会设上限，避免少数碎片垄断结果；最关键的是标签的关联扩展，当直接命中的碎片不够时，会顺着标签再往外捞一圈，把相关的内容一起带出来。
从传统 RAG 的角度看，这套东西其实有点反直觉——没有向量召回，也没有一个明确的 “最相关结果”。但它更像是在做一件事：不是找答案，而是把线索捞出来，让 agent 自己去拼。

做梦：记忆整合
碎片越来越多之后，我开始遇到两个问题：有些碎片其实在表达同一件事的不同侧面，而有些碎片则长期没有再被用到。
我后来参考了 Claude Code 里的一个设计思路：人睡觉的时候，大脑会把白天的短期记忆整合成长期记忆，同时遗忘掉一些不重要的东西。于是我给这个系统加了一个后台的 “做梦” 机制。

这个过程是异步触发的，每当碎片累积到一定程度，或者 agent 跑完一轮测试，就会跑一轮 “梦”。它做三件事：对长期未使用的碎片做软遗忘（不删除，只是降低排序权重），根据标签共现关系把碎片聚成簇，再用 LLM 把同一簇里的内容融合成一条更完整的认知，同时把原碎片标记为已整合。
做到这里的时候，这个系统开始有点不像 “一个功能”，而更像是在发生某种演化：短期经验被不断整理、压缩，逐渐沉淀成更稳定的结构。

怎么用起来的
这个 “大脑” 并不是一个单独的模块，而是嵌在 agent 的工作流里的。
任务开始之前，规划引擎和执行引擎会用任务描述去搜一遍大脑，把相关的碎片注入到 prompt 里；在数据准备阶段，agent 会分析用例需要什么数据，再去大脑里找现成数据或获取路径，并根据步骤成本选一条最短路径；执行过程中，如果遇到不确定的地方，可以随时调用 recall_brain(query) 去找线索。我在 prompt 里专门写了一句话反复强调：记忆不一定有现成答案，但一定有线索。

整套东西跑在 SQLite 上，本地部署，不需要额外的数据库服务。碎片的相似度用中文 bigram + Jaccard 算，不做 embedding——碎片库就几百到几千条的量级，bigram 判断"这两句话是不是同一件事"已经够了，快，而且不用调模型。
检索是全表扫描。听起来暴力，但这个规模下在内存里遍历一遍比走数据库索引还灵活——bigram 滑窗、标签关联扩展、正则加权这些逻辑都能直接写在遍历里面，不受 SQL 表达力的限制。
做梦是 fire-and-forget，异步后台跑，不阻塞用户操作。出错就 catch 打个 log，下次触发再来，不影响主流程。LLM 合成用的是轻量模型，够用，成本也低。
碎片的来源有四种：用户手动教的、文档提取的、agent 执行中学到的、做梦合成的。四种来源没有任何区别，存在同一张表里，参与同样的检索和做梦。
整个循环画出来是这样的：

没有人工维护环节，整个循环是自驱的。

后来
写这个大脑之前，我没预期它会带来什么质变。但有一次看 agent 执行的时候，我突然意识到它已经有点不一样了。
那次的用例是用某个特定角色去目标系统查看人员列表。以前的 agent 会直接导航过去，发现没权限，然后卡住。但这一次，它先生成了一段执行计划：先去 SSO 切换账号，再刷新确认身份，然后再进入目标系统。
整个过程跨了三个系统，没有试错，也没有卡顿，完全是一个老员工会走的路径。
那一刻让我有点被击中。因为它不再像是在 “尝试”，而是在按一条它已经 “知道” 的路径在行动。
这种感觉很微妙，它并没有变得更 “聪明”，但它开始有一点 “在场” 的感觉了。它不像一个只会执行指令的工具，而更像是一个在这个环境里待过、积累过经验的存在。
也是在那之后，我给这个大脑开了一个 “同乐者” 的模式。在这个模式下，经验不再只属于某一个人，而是可以在系统里流动起来。有人踩过的坑会留下来，有人试出来的路径会被记住，下一次再遇到类似的问题，不需要重新试一遍。你甚至不需要知道这些经验是谁留下的，但你可以用到它。

最后
以前我们在想的是怎么让模型更聪明，而现在更像是在做一件更朴素的事情：让一个系统在一个地方待得够久。
这可能是我目前见过的最接近 “AGI” 的一种状态。它不是通用的，也不是无所不知的，但它在一个具体环境里，通过持续的存在和使用，慢慢长出了超出模型本身能力的行为。
也许 AGI 真正落地的时候，并不是一个什么都知道的系统，而是很多 agent，在各自的环境里待得足够久。