不同 Agent 的记忆机制形式不同，但底层思路很接近：从历史任务里提炼经验，存成本地可读文件，再在相关任务里召回。

对比维度 Codex 类机制 Claude 类机制
触发方式 更偏后台自动从历史会话里提炼 更偏在项目执行中主动整理
组织形态 独立经验卡片，偏跨任务通用 目录页加专题文件，偏项目级组织
存储位置 统一记忆目录，方便跨会话使用 跟项目绑定，方便承接项目规则
共同点 都记“经验”而不是完整聊天；都能被人查看、修改、删除；召回时都强调少而精 共同点相同
这类机制已经很有用，但它也有明显上限。Agent 只能记住自己参与过的窗口和能访问的目录。真实工作环境里的飞书消息、会议纪要、文档、代码评审、设计稿、邮件和内部系统，往往都不在它的视野里。

还有一个问题：记忆通常跟着工具走。换一个 Agent，历史经验不一定能带过去。于是，一个更稳的方向是把个人或团队的知识系统独立出来，让不同 Agent 都能读取同一套可治理的知识资产。

知识库架构：从原始材料到可召回资产
个人工作记忆不能只靠“保存资料”。原始数据太乱，直接塞进知识库会出现一个尴尬结果：模型知道有这批资料，但召回不到关键片段。

更合理的链路是先清洗、分片、建卡，再进入语义学习和召回系统：
mermaid-01.png

图：从原始材料到 Agent 召回的工作记忆沉淀链路

这个图里的关键点不是向量库，而是“结构化卡片”。真实工作里的召回维度经常是人、日期、项目、模块、MR、会议结论、待办、决策。如果这些维度没有在数据进入知识库前显式建出来，后面只靠语义搜索很难稳定命中。

五类知识：不是所有东西都该进记忆
一套可用的 Agent 知识系统，至少要区分五类内容：

类型 例子 建议存法
原始数据 聊天记录、会议纪要、MR、日志、文档、截图 resource，保留来源和时间
可检索卡片 某次会议结论、某个 bug 排查、某个模块决策 retrieval card，结构化摘要
长期记忆 稳定偏好、项目惯例、历史决策、常见坑 memory，短、准、有证据
技能流程 review 流程、日报生成、发布检查、排障手册 skill / playbook / template
实时状态 今日排期、线上指标、最新 MR 状态 不进长期记忆，现场查询
这张表背后有一个原则：长期记忆只放未来会反复用、能改变行动的东西。临时状态不该进长期记忆，敏感信息也不该进。否则记忆会从资产变成污染源。

记忆准入：短、稳、可回查
一条记忆是否值得保存，可以用五个条件过滤：

条件 含义
稳定 未来还会反复用，不是一次性状态
可执行 能改变下一次任务的做法
可验证 能回到原始证据，而不是凭空总结
不敏感 不包含 token、cookie、个人隐私和不该长期保存的信息
不空泛 不能是“认真验证”“注意质量”这种废话
Skill 或自动化也有类似准入标准：重复出现、有明确输入、有固定步骤、有验证标准、有常见失败，才值得封装。否则写出来也不会被用，甚至会误导 Agent 走错流程。

召回策略：少而精比全量更重要
很多知识库项目最后失败，不是因为资料太少，而是召回太粗。Agent 每次拿到一堆无关上下文，会更慢、更贵，也更容易被干扰。

召回应按任务重排，而不是按“相似度最高”一把梭。一个更可靠的排序方式通常会综合四类信号：

信号 用途
项目相关性 当前任务属于哪个项目、模块或业务域
时间新鲜度 最近决策、最新接口、最新规范优先
证据强度 有来源、有会议结论、有代码或文档支撑的内容优先
可执行性 能直接改变下一步操作的记忆优先
这样召回出来的上下文才像“工作记忆”，而不是资料大杂烩。

从使用 Agent 到构建个人智能体
高频使用 Agent 和打造有工作记忆的个人智能体，其实是同一条路的两个阶段。

前一个阶段解决“我怎么摸清 AI 的边界”。通过大量真实任务，理解哪些事能交给它，哪些事要拆，哪些事必须验证。后一个阶段解决“AI 怎么记住我的边界”。通过记忆、知识库、skill、自动化和反馈，把个人经验变成模型能调用的外部系统。

这件事短期看是在提效，长期看是在改变个人工作方式。人的经验不只存在文档里，也存在聊天、会议、代码、复盘和脑子里的隐性判断里。把这些经验用正确粒度沉淀下来，Agent 才可能从“会回答的工具”变成“能承接工作上下文的协作者”。