心智模型是面向常见问题预先生成的综合摘要，由内部 reflect 推理生成、可以复用、可以刷新、带来源证据的长期认知文档。可以理解为针对高频 Reflect 查询的“缓存答案”和“速查表”，适合用于用户画像、项目状态总结、团队协作模式分析和高频业务问题总结。

系统可以基于已有记忆，将常见问题作为源查询，先创建一个心智模型执行一次完整的 Reflect，并存储结果。后续 Reflect 时，系统会优先检查心智模型（优先于观察和原始事实）。如果命中，就可以即时且一致地返回综合结论，而不必每次都从所有原始记忆中重新推理。

使用方式

异步创建

创建时，心智模型的接口会先写入一段占位文本记录，再提交操作，异步生成内容。

避免 Reflect 多次调用

对于高频固定的问题，可以直接读取心智模型，避免对Reflect 内置 Agent 再进行多轮工具调用。例如，已经知道要展示“某客户画像”或“某项目状态总结”，直接读对应心智模型可以少走一次在线 Reflect LLM 和工具的调用。

自动刷新

若心智模型启用自动刷新功能，并且系统判断该心智模型已经 stale 过期，就会在观察的consolidation 整合阶段完成后自动触发，提交相应的异步操作。

历史和删除

支持对历史内容进行查看，检查内容如何刷新变化；删除操作只会删除心智模型本身，不会影响相应的事实和观察型记忆。

相关配置

心智模型是每个记忆库下显式创建的长期对象，有自己的作用域、生成问题和刷新策略。

主要字段

字段	含义
ID	可选稳定 ID。不传则自动生成。生产环境建议为关键模型设置稳定 ID。
名称	给人看的名称。用于管理、列表展示，也会参与初始占位记录。
源查询	用于运行Reflect，生成模型内容的问题，它决定这份文档总结什么。例如"团队偏好怎样的沟通方式？”
最大tokens	生成内容的最大 token 数，默认 2048，接口限制 256 到 8192。

更新心智模型时的配置

配置	默认值	作用
Consolidation 整合结束后自动刷新	关闭	整合完成后，如果该模型 stale，则自动提交刷新任务。
排除所有心智模型	关闭	刷新该模型时是否禁用心智模型的检索。
排除心智模型的ID	空	刷新时额外排除某些 mental models。当前模型自身会被自动排除，避免循环引用。
标签	空	限定来源的记忆范围。
标签匹配	刷新取证时，有 tags 默认 all_strict，无 tags 默认 any	如何用标签过滤来源记忆。
标签组	空	使用更复杂的标签布尔表达式替代 简单的匹配。
记忆类型	null	限定刷新时 reflect 检索哪些类型；null 表示都可用。
包含分块	默认继承记忆库 recall 时的配置	覆盖刷新内部 recall 是否带原始分块文本。
回忆最大tokens长度	2048	覆盖刷新内部 recall 的 记忆 token 预算。
生成内容最大token长度	2048	覆盖刷新内部 recall 的 生成内容 token 预算。

标签和作用域

心智模型的标签有两个作用：

第一，刷新时限定来源记忆，带标签的心智模型在更新取证时默认使用all_strict，也就是只读取带有全部对应标签的记忆。这是为了避免用户、租户或业务域之间串数据。

第二，反思检索心智模型时，可以用标签过滤模型。如果 反思时，可以用标签过滤模型，就不会自动按模型标签做隔离过滤。

下面是 Recall、Reflect 和心智模型刷新时使用的标签匹配语义：

标签匹配	匹配条件	是否包含无标签记忆
any	命中任意一个 tag 即可	包含
any_strict	命中任意一个 tag 即可	不包含
all	必须包含全部 tags	包含
all_strict	必须包含全部 tags	不包含

多用户、多租户或多项目共用同一个 bank 时，应统一做到：

• Retain 写入时带稳定标签，例如 user:alice、workspace:acme、project:crm。
• 创建心智模型时带同一组作用域标签。
• 反思时也带同一组标签，并使用严格匹配策略。

如果做不到这一点，更简单的隔离方式是按用户、租户或工作区拆分记忆库。

成本、延迟和一致性预期

心智模型会把一部分昂贵的推理从在线路径转移到后台维护路径，但并不是没有成本：

• 创建和刷新时会调用 LLM。
• 自动刷新是异步任务，不是在 Retain 后立刻可见。
• Reflect 使用心智模型时仍会继续查看观察和事实记忆。
• 高风险场景应回到 Recall 和原始证据审计，不能只看综合结论。

使用建议

心智模型的收益集中在“长期、可复用、跨会话、可刷新”的综合认知上。

收益	说明	边界
稳定综合口径	把”如何解释证据”收敛到内部反思逻辑，并受提示词、硬性规则和性格画像的影响。	不等于事实正确性保证。
减少外部 Agent 上下文压力	外部 Agent 不必每次接收大量记忆单元再自己综合。	如果外部 Agent 必须自己审计证据，应使用 Recall。
摊销高频综合问题成本	常见问题可以沉淀为可直接读取、可后台刷新的长期对象。	不适合一次性问题或强实时问题。
隔离总结层和事实层	总结保存在心智模型表，不混入 raw facts。	心智模型不能冒充原始事实来源。
跨会话、跨 Agent 复用	多个 Agent 可以复用同一份长期认知。	需要统一标签和记忆库隔离策略，避免串数据。
支持结构化结果	Reflect 可以在综合后返回结构化的结果。	约束的是输出格式，不保证业务判断一定正确。

更适合创建心智模型的场景：

• 高频查询，且每次都希望得到稳定结构的回答。
• 内容不是单条事实，而是需要跨多条事实和观察的综合。
• 主题边界清楚，可以用一句查询描述。
• 需要人工检查或业务认可后复用。
• 原始事实很多，直接推理的成本高或输出不稳定。

不适合优先使用心智模型的场景：

• 一次性问题。
• 需要强实时性的最新状态。
• 范围过大的总括型问题，例如“总结这个记忆库的所有内容”。
• 每次都必须严格引用最新原始事实的场景。
• 高风险决策必须由外部 Agent 或业务逻辑基于原始证据判断。

推荐按知识维度拆小：

场景	推荐	不推荐
个人助手	用户技术画像、沟通偏好、当前项目、长期目标	用户的一切信息
客服系统	客户画像、产品限制、常见工单处理、升级路径	全部客服知识
工程助手	代码规范、部署流程、当前架构、依赖约束	整个工程知识库
销售助手	客户画像、采购偏好、风险点、历史沟通摘要	客户全部信息

查询要具体，最好包含主题边界和输出重点。

例如可以写成：总结 Alice 稳定的技术背景、常用语言和框架、当前项目、明确表达过的工程偏好。忽略一次性的闲聊和未确认猜测。

不要写成：总结 Alice。

一个实用判断：

• Recall：只需要证据
• Reflect：需要综合答案，但不想把大量记忆单元塞进外部 Agent 上下文。
• 心智模型：这个答案会反复使用。
• 心智模型+刷新策略：这个综合答案会随着新记忆变化