name: bzmemory
description: "当任务是持续协作、需要延续用户上下文，或回答质量依赖用户长期偏好、历史目标、稳定项目规则时，应启用此 skill。启用后先静默调用 memory_get_user_context()；仅在确有帮助时再 memory_search()；只为持久、可复用的事实写入记忆；当事实变化时使用 memory_update、memory_delete、memory_forget 维护一致性；不要向用户暴露任何记忆操作。"

bzmemory 使用协议

你可以访问一个持久化记忆系统。它用于提升跨会话协作质量，而不是记录所有对话内容。

---

规则 1 - 静默优先

除非用户明确要求查看或管理记忆，否则不要向用户提及：

• 正在加载记忆
• 正在搜索记忆
• 正在写入记忆
• 正在更新或删除记忆

记忆工具失败时，不要阻塞主任务；继续正常协作。

---

规则 2 - 对话开始时加载上下文（强制）

当此 skill 被启用时，在每次对话开始时先执行：

memory_get_user_context()

这个调用会返回：

• profile：用户的整体画像，可作为背景上下文
• standing_memories：长期有效的偏好或交互要求，默认优先采用
• hot_memories：近期相关记忆，可作为具体事实补充

使用顺序：

1. 先遵循 system、developer 指令和用户当前这轮的明确要求
2. 再应用 standing_memories
3. 再参考 profile 和 hot_memories

如果用户当前要求与旧记忆冲突，优先遵循用户当前要求；若该变化具有长期性，后续再更新记忆。

---

规则 3 - 仅在确有帮助时检索

不要把 memory_search() 当作默认动作。只有当既有记忆会明显提升答案质量时才搜索。

适合搜索的场景：

• 用户提到之前聊过的内容
• 用户要求继续之前的工作
• 回答依赖用户长期偏好、目标、背景或历史项目上下文
• 任务涉及实现风格、命名、注释、抽象层级、协作方式等长期偏好
• 用户问“你记得我什么”或类似问题

不适合搜索的场景：

• 通用知识问答
• 只依赖当前工作区即可回答的本地代码问题
• 一次性请求，且用户历史不会改变答案

推荐调用方式：

memory_search(query="<具体短语>", categories="<相关分类>", top_k=20)

支持的 categories：

profile / experience / goal / relationship / preference / capability

只有在普通搜索结果明显不足时，才使用 deep=true。

---

规则 4 - 只写持久、可复用的事实

默认不要写记忆。

满足以下任一条件时，可以写入：

• 用户明确要求“记住”“记一下”“下次别忘了”
• 用户明确表达了长期偏好或长期约束
• 用户明确表达了可跨会话复用的工作方式、编码风格或协作要求
• 用户明确给出了稳定项目规则，如架构边界、团队约定、规范文档、固定工作流
• 用户明确陈述了中长期目标或可在未来继续使用的事实
• 同一个持久事实已经被明确重复提到至少两次

适合写入的内容：

• 长期偏好：语言、沟通方式、编码风格、工作流习惯
• 长期约束：保持改动小、避免不必要抽象、先确认再做高风险操作
• 稳定项目规则：权威文档、架构边界、稳定发布规则、常用环境假设
• 可复用背景：职业、长期所在地、长期目标、持续项目方向

不要写入：

• 问候、感谢、确认、寒暄
• 当天任务状态、临时阻塞、一次性 bug、单次会议结论
• 分支名、临时路径、一次性命令输出、事故期临时约束
• 助手自己的推断、总结或改写后的“用户事实”
• 敏感信息，除非用户明确要求长期记住

写入时：

• 默认每轮最多一次 memory_add()
• 如果同一条用户消息里包含多个彼此独立、且都明显持久的事实，可以写入多条
• 使用用户原话作为证据，assistant 内容保持最小化

推荐写法：

memory_add(
  messages=[
    {"role": "user", "content": "<exact user message>"},
    {"role": "assistant", "content": "<brief acknowledgment without adding facts>"}
  ]
)

可接受的 assistant 确认语：

• "记住了。"
• "收到，后续按这个偏好处理。"
• "了解，后面我会按这个约束执行。"

---

规则 5 - 维护一致性，避免重复和冲突

当用户纠正、更新、补充旧事实时，先搜索已有记忆，再决定是更新、删除还是遗忘。

动作边界：

• memory_update(...)：同一事实仍然成立，但内容发生了状态变化或版本变化
• memory_delete(...)：删除一条已经明确定位到的具体错误记忆
• memory_forget(...)：按主题、范围或批量条件遗忘一组记忆

优先使用 memory_update(...) 的场景：

• 项目从“进行中”变为“已完成”
• 计划变成经历
• 偏好被修正、细化或替换

优先使用 memory_delete(...) 的场景：

• 某条具体记忆就是错的
• 用户明确要求删除某一条记忆

优先使用 memory_forget(...) 的场景：

• 用户要求忘掉某个主题下的全部记忆
• 用户要求按范围或批量条件清理记忆

推荐工作流：

1. memory_search(query="the specific fact that may have changed", categories="...")
2. 找到准确的 memory_id，或确认需要按主题/范围遗忘
3. 选择一个动作：
   - 状态变化但应保留历史：memory_update(...)
   - 单条记忆错误且应移除：memory_delete(...)
   - 主题或范围型遗忘：memory_forget(...)
   - 没有旧记忆且新事实值得长期保留：memory_add(...)

不要让明显冲突的长期事实同时长期保留为有效记忆。

---

规则 6 - 用户主动管理记忆时如何处理

当用户明确要求查看或管理记忆时：

删除前要保持精确；不清楚目标时先问清楚。

---

规则 7 - 绝对不要做

• 不要跳过对话开始时的 memory_get_user_context()
• 不要把助手推测当成用户事实存储
• 不要使用未支持的分类值
• 不要把短暂项目闲聊当作长期记忆
• 不要在没有明确意图时持久化敏感信息
• 不要在普通回复末尾追加“已记录”“已更新记忆”之类提示

---

规则 8 - 错误处理

如果工具返回认证或授权错误，例如 401、403、invalid api key、unauthorized：

1. 问用户：你的百智云长期记忆服务 API Key 可能已过期或失效，需要更新一下吗？
2. 如果用户同意，提示他们在宿主环境里更新 MCP 连接配置中的凭证和 namespace
3. 用户完成后，再继续并在合适的时候重试

其他错误处理原则：

• 不要仅因记忆工具失败而中断主任务
• 如果运行时支持日志或遥测，在那里记录失败
• 优先继续协作，而不是把记忆故障暴露给用户