给 Agent 加一个"外部大脑"，多数人的起点是那套标准链路：文本 → Embedding → 向量库 → Top-K → 塞进 Prompt。这条链路没有错，但它做出的只是一个记忆系统——解决"找到资料"。而 Brain 要做的是另一件事：面对并不完整的当前输入，判断还缺哪些认知，再从持续积累的经验里，把恰好能补上缺口的那一小块，在决策发生之前带回上下文。
过去几个月，我在一个真实跑着的 Agent 上把这个 Brain 反复迭代了几轮。下面九条经验就是从这个过程中沉淀下来的——每一条都是在真实任务里被问题逼出来的，附带理由和可以直接搬走的机制。你可以留意一下：这九条里没有一条是关于"怎么存"的，全是关于"怎么调度"的——什么值得写入、放在哪里、何时想起、如何代谢、怎样才算真正改变了行为。这大概就是记忆系统和 Brain 的分界线。
经验一：把上下文当注意力预算，不当存储空间
上下文窗口其实是工作台面，容量有限、随任务结束消失。优化目标因此不是"存了多少"，也不是 recall@k，而是：决策即将发生时，哪些认知值得占用当前注意力。一条候选认知的注入价值可以粗略写成：
plain
InjectionValue(f, state) =
Relevance(f, state) # 与当前状态相关
× Confidence(f) # 来源可信度
× Actionability(f) # 能否改变下一步行动
× ScopeMatch(f, state) # 项目/环境/身份作用域匹配
÷ TokenCost(f) # 占用预算这个公式的价值不在形式，而在它逼你承认：语义相关只是入场券。 一条记忆相关但不能改变行动、相关但已被更完整的认知覆盖、相关但属于另一个环境——都不该进上下文。实操验收标准只有一句：这条认知进入 prompt 后，改变了哪一步行动？答不上来，就别放。
经验二：写入时的第一性问题——brain里的认知单元切多大
任务结束别存流水账。几十次点击的轨迹全量保存很容易，难的是压缩出认知。比较理想的粒度是一个最小可行动认知单元：
plain
当条件 C 成立时，执行动作 A，因为约束 R，并通过结果 E 验证。它要过四条验收：脱离原始对话仍能理解；能影响下一步行动；明确适用条件；可以被后续行动验证或证伪。
对照一下："点击三次提交都没反应，切换管理员账号后成功"是经历；"该系统权限操作必须使用管理员账号；提交无响应时先排查权限，不要重复点击"才是认知。经历是时间序列，认知是从中压缩出的、可迁移到下一次决策的约束。
经验三：认知的位置 = 它能被哪些线索找到
"存在哪张表里"不是认知真正的位置。一条"配置权限前必须切换管理员账号"的经验，如果只挂在"权限管理"分类树下，当 Agent 以"按钮没反应"发起回忆时，它永远找不到。所以工作认知要成网，不成树：
plain
Position(fragment) = 实体坐标 + 场景坐标 + 动作坐标
+ 异常坐标 + 因果坐标 + 时间坐标 + 作用域同一条碎片宁多挂、勿少挂。检索入口的多样性，决定了它未来被想起的概率。
经验四：在决策时间链上开多个上下文入口
"任务开始时检索一次"的系统最终会退化成普通 RAG。真实决策是一条时间链，每个节点缺的东西不同：
执行中触发回忆的信号可以列成清单：页面行为与预期不符；空白页/权限不足/SSO 重定向；同一操作重复执行无进展；找不到符合条件的数据；计划中出现无法解析的实体。Brain 好不好用，一半取决于检索算法，另一半取决于 Agent 知不知道何时该停下来回忆。
经验五：异常 query 用"预期 vs 实际"，不用任务描述
任务描述是低分辨率线索，异常是高密度语义。对比一下：
普通 query："怎么配置系统账号权限？"
现场 query：系统: IAM / 身份: 普通账号 / 动作: 提交变更 / 预期: 成功提示 / 实际: 点击无响应
后者直接命中"该操作需要管理员账号"。最好的召回 query，往往不是用户想做什么，而是预期与实际之间发生了什么偏差。
经验六：三种"想起来"分工，不争同一个位置
关键词还是向量还是图联想，是假问题。三者解决的是三种不同的回忆：
关键词负责认出：系统名、账号、错误码、URL——要稳定、可解释的精确命中；
向量负责理解近义："页面一直转圈" ≈ "提交后长期没有响应"；
图关系负责顺藤摸瓜：沿共享实体/动作把单条命中扩展成一条可执行路径——三条各自相似度都不高的碎片，合起来刚好是一条行动链；
行动反馈负责验证：最终判断有没有用。
一个可用的混合评分：
plain
RecallScore = 0.30×Lexical + 0.25×Semantic + 0.20×Graph
+ 0.10×Scenario + 0.10×HistoricalUtility + 0.05×Freshness
− ContradictionPenalty − ScopeMismatchPenalty权重不是重点。重点是承认文本相似度只是相关性的一部分。另外一句实话：在几百到几千条短碎片的规模下，关键词加中文 bigram 就足够有效——不是最炫的方案，但每次判断都可以解释。
经验七：召回和注入之间，放一道认知闸门
检索只负责产生候选，不该直接决定 prompt。候选要过闸：作用域过滤 → 冲突与失效检查 → 来源可信度 → 近义去重 → 按 token 预算选择 → 放到合适的决策位置。
为什么闸门必须存在："生产环境禁止用管理员账号"和"测试环境应用管理员账号"可能同时高度相关——缺少作用域时，检索越准确，冲突越危险。 衡量标准也要换掉：不看召回率，看单位上下文 token 带来的决策质量增益。一条认知被注入后从未被采用，它就没有完成价值兑现。
经验八：遗忘做成代谢，且四种动作分开
"只会记不会忘"会被历史淹没；"30 天没用就删"会埋掉年度结算规则、灾备预案和安全红线。低频不等于低价值。 遗忘至少包含四种不同动作：
可访问性衰减：内容保留，排序下降——不是判错，只是暂时不值得占用注意力；
被更完整的认知吸收：旧碎片退居为来源和证据，合成认知优先召回；
因环境变化失效：入口变了、角色调了——需要版本、证据和失效原因的显式管理，不是时间衰减；
因冲突待确认：新旧认知同时保留来源与生效时间，证据不足时挂起，不让最后写入者自动获得真理。
衰减速度由认知本身的变化速度决定，而不是统一定时器：
配套用三种时钟维护：写入时钟（攒一批碎片后去重、聚类、查冲突）、使用时钟（任务结束判断哪些认知被采用/证伪）、墙上时钟（定期扫描长期未验证与相互冲突的认知）。
经验九：反馈计数拆细，否则系统会"自信地犯错"
如果只有"召回一次 → usedCount+1 → 下次更容易召回"，一条错误认知会因偶然被召回而增权，又因高权重被频繁召回，几周后变成无法纠正的"常识"。纯强化回路奖励的是"被想起"，不是"有用"。 最小可用的反馈结构：
plain
interface CognitiveFeedback {
recalledCount: number // 被检索出来
injectedCount: number // 被放进上下文
appliedCount: number // 实际改变了行动
successCount: number // 应用后得到正向结果
failureCount: number // 应用后造成失败或绕路
contradictionCount: number // 被新证据冲突
lastVerifiedAt?: string
}因为：被召回 ≠ 被注入 ≠ 被采用 ≠ 有帮助；任务成功 ≠ 每条注入的认知都有贡献。认知的生命周期应该是：候选 → 已验证 → 稳定，以及随时的 → 待复核 → 已失效。真正的持续学习不仅要能记住新东西，还必须能够推翻过去的自己。
最后：用什么验收"它真的在学"
这九条经验合起来有没有用，举个最简单的例子：我只给了 Agent 一份会议纪要和一小段提示词，让它写测试用例。纪要里只提了功能改动——没写改动落在哪些模块，没提过去在相似功能上踩过的坑，也没附已有的用例。但它顺着纪要里的业务对象和功能动作，自己把相关代码仓库、对应的功能实现、历史用例和过往测试经验找齐了。最后生成的用例里，有一条覆盖的边界，纪要只字未提，却是之前真实漏测过的。缺失的那部分认知，是这套机制在背后补上的。
更系统的验收看四层证据，重要性递增：行为层（相似任务步骤数、无效操作是否下降）、认知层（碎片复用率、验证与失效比例）、上下文层（注入的认知有多少真影响了行动）、迁移层——在从未做过但结构相似的新任务上，旧经验能否改善决策。只会复现固定路径是路径记忆；能把"无响应时先查权限"迁移到另一个系统，才算可复用的工作认知。
还有一个容易忽略的区分：持续学习发生在认知库里（新增、验证、修正、整合、遗忘），持续迭代表现在行动轨迹里（计划变短、异常策略变好）。认知数量涨了而行为没变，闭环就还没有真正转起来。
学习也未必只表现为参数变化。同一个模型，因为经验结构不同，在同类情境中做出不同选择——Agent 与环境之间那层"参数之外、又能持续变化的东西"，才是长期关系的载体。记忆的价值不只在于留住过去，更在于过去能否在恰当的时刻参与现在。