文档中心

向量数据库VikingDB

使用 OpenViking 接管 Agent 记忆

使用 Peer 分开管理不同对象的记忆

在自主开发 Agent 记忆的接入时，不同的场景可能需要在 user 目录下进行进一步的记忆隔离。例如：

一个内部 IT 服务助手场景，助手在群聊中与不同的用户交互，希望分别记住每个用户的工单处理历史和反馈
办公协作或 Coding Agent 希望按不同的工作项目、本地工作来区分项目内的记忆

Peer 用来回答“这是谁或哪个项目的记忆”。可以用来为一个 User（agent，用户）下做不同交互对象（如群聊）或不同项目的记忆隔离。

位置	用途
viking://user/{user_id}/memories/	Self：User 自身的长期记忆
viking://user/{user_id}/peers/{peer_id}/memories/	特定的人或项目的记忆
viking://user/{user_id}/sessions/	原始会话；消息用 peer_id 标记关联对象

接入时分别设置三件事：创建 Session 时用 memory_policy 允许相应目标的抽取；写入消息时用 peer_id 标记对象；检索时用 target_uri 或接口支持的 Peer 范围限制本次读取。写入侧的 peer_id 不会自动替你限定每次检索范围。
详细了解 User-Peer 的机制，可参考 User 和 Peer：实现目录下的记忆和资产隔离。
本篇使用 2 个不同的实践场景，讲述使用 Peer 隔离记忆抽取和记忆使用的方法。

实践一：群聊 Agent 按发言人设置 Peer

以团队助手（ User=team_assistant）在群聊中服务大量用户（包括 Alice 和 Bob ）为例：群或话题标识聊天场景，Session 保存一段连续对话；Peer 区分发送者。一个 Session 可以在不同轮次收到不同 Peer 的消息，不需要为群里的每个人都新建一个 OV Session。

业务对象	OV 中的对应关系
团队助手	User=team_assistant，管理这批记忆
Alice / Bob	分别映射为 person_alice / person_bob，保存各自的长期信息
群里的 VPN 排障话题	一个 Session，按时间记录不同发言人和助手的交互

从已验证的渠道用户 ID 或企业成员 ID 建立 Peer 映射。同一人在不同群中能否复用同一个 Peer，取决于业务是否允许跨群使用记忆；若只能在单个群内使用，可按“群 ID＋成员 ID”生成稳定的 Peer ID。

标记 Message：用户消息带自己的 Peer，助手消息保留助手身份

每条 user 消息都带上该条消息发送者的 peer_id。助手回复和工具执行记录使用 role=assistant。
下面是同一话题中先后发生的两个轮次。请求提交到 POST /api/v1/sessions/{session_id}/messages/batch；也可以按相同顺序逐条调用 messages 接口。

{
  "messages": [
    {
      "role": "user", "peer_id": "person_alice",
      "parts": [{"type": "text", "text": "我使用 macOS，排障时请给简短步骤。"}]
    },
    {
      "role": "assistant",
      "parts": [{"type": "text", "text": "Alice，我先检查你的 VPN 配置。"}]
    },
    {
      "role": "assistant",
      "parts": [{
        "type": "tool", "tool_id": "call_alice_001", "tool_name": "check_vpn",
        "tool_input": {"device_id": "device_alice_01"},
        "tool_output": "该设备的 VPN 配置已过期。", "tool_status": "completed"
      }]
    },
    {
      "role": "user", "peer_id": "person_bob",
      "parts": [{"type": "text", "text": "我使用 Windows，希望附上界面操作说明。"}]
    },
    {
      "role": "assistant",
      "parts": [{"type": "text", "text": "Bob，下面是适用于 Windows 的操作步骤。"}]
    }
  ]
}

回流与抽取：逐条保留身份，按话题保存完整过程

按话题或连续任务建立 Session，并保持消息顺序。多人并发处理时，记录每个工具调用对应的请求、对象与调用 ID；若回复和工具结果难以对应，可按独立任务拆分 Session，Peer 仍保持不变。
创建 Session 时启用 memory_policy.peer.enabled。根据需求单独决定是否开启 Self 抽取；无 Peer 的助手消息不代表一定生成 Self 记忆。上传完成且话题告一段落后 Commit，检查各 Peer 目录和 memory_diff，确认 Alice、Bob 的信息没有串写。

检索：先确定服务谁，再确定哪些信息可以用于当前回复

接到请求后，应用根据可信身份和任务对象选择 Peer，再根据回复渠道筛选可使用的信息。不要因为消息来自某个群，就检索该群所有成员的全部历史。

当前任务	建议的检索目标
Alice 的私聊排障	person_alice，以及允许用于此任务的助手通用记忆；不查 person_bob
在群里回复 Alice	先判断 Alice 的信息是否允许用于群内回复；不允许公开的私人记忆不注入本轮上下文，可转到私聊处理
回答全群通用问题	优先查获准共享的知识和通用记忆，不默认遍历所有个人 Peer
确实需要比较多位成员的信息	由业务确认任务对象和授权后，分别查指定 Peer；保留来源，且只输出可向当前受众展示的结果

将限定 peer 目录的请求提交到 POST /api/v1/search/find，可限定仅召回 assistant 和 Alice 交互过程中产出的记忆。

{
  "query": "使用的设备和排障回复偏好",
  "target_uri": "viking://user/team_assistant/peers/person_alice/memories/",
  "limit": 5
}

说明

相似实现可参考 OpenViking 官方的 OpenClaw 插件：OpenClaw 插件

实践二：Coding Agent 按项目或工作区设置 Peer

开发助手需要长期记住每个项目的技术栈、工程规范、设计决策与排障记录。这个场景下，Peer 代表正在处理的项目或工作区，不代表当前发言的开发者。以下使用 User=dev_workspace，分别将 Atlas 和 Beta 项目映射为 project_atlas、project_beta。

确定 Peer：按需要共享记忆的工作范围划分

想要的效果	Peer 如何划分
同一项目跨机器、克隆目录和 worktree 延续背景	映射到同一个稳定项目 ID，例如 project_atlas
实验环境或客户交付分支持有独立约定	显式分配独立工作区 Peer，例如 workspace_atlas_lab
多个项目使用同一个助手	仍分别使用 project_atlas、project_beta 作为 Peer，Agent 有 User 目录的鉴权权限，可访问所有的 peers。

由应用维护“项目或工作区 → Peer”的映射。新建任务先确定 User、Peer 与 Session 的对应关系，之后回流和检索都使用这份任务记录。

标记 Message：项目相关的输入、回复和工具结果使用同一个 Peer

与群聊按人区分不同，这里要保存的是“Atlas 项目的工作记录”。因此，项目相关的 user、assistant 消息及 Tool Part 所在的 Message 都可标记为 project_atlas。role 仍区分说话者，peer_id 只说明这段内容属于哪个项目。

{
  "messages": [
    {
      "role": "user", "peer_id": "project_atlas",
      "parts": [{"type": "text", "text": "Atlas 使用 pnpm。请为新增接口补充集成测试。"}]
    },
    {
      "role": "assistant", "peer_id": "project_atlas",
      "parts": [{
        "type": "tool", "tool_id": "call_atlas_test_001", "tool_name": "run_tests",
        "tool_input": {"project_id": "atlas", "command": "pnpm test:integration"},
        "tool_output": "本次集成测试全部通过。", "tool_status": "completed"
      }]
    },
    {
      "role": "assistant", "peer_id": "project_atlas",
      "parts": [{"type": "text", "text": "已补充集成测试，并通过验证。"}]
    }
  ]
}

回流与抽取：固定任务归属，项目切换时不改写历史

任务开始时解析并保存 Peer ID。后台队列中的记录也携带该 ID，不能等到上传时再用当前工作目录重新计算，否则切换项目后可能把 Atlas 的记录写进 Beta。
同一项目的新任务创建新 Session，但复用同一个 Peer。任务中转去处理 Beta 时，先结束或提交 Atlas 的完整片段，再建立 Beta 的 Session，不批量重标原来的消息。
按顺序增量回流需求、实际动作、工具结果和用户反馈，保存上传进度。重复投递或重试不能被当成新的业务交互；缺少结果时保留未完成状态。
只抽取本项目的普通记忆时，可设置 self.enabled=false、peer.enabled=true。提交后检查 project_atlas 下的事实和决策，以及是否误混入 Beta 内容；经验记忆的生成和落点仍以对应能力与策略为准。

跨项目个人偏好可以不携带 peer 信息，写入顶层的user memory目录。例如“我总是喜欢简短回答”与“Atlas 的接口必须写集成测试”不是同一类范围。

检索：以当前任务的项目为目标，再按需加入通用记忆

检索开始前，从任务记录取得 project_atlas，优先查询该项目的记忆，再补充允许复用的 Self 记忆。完成检索后，带着来源 URI 将相关内容加入模型上下文。

{
  "query": "包管理工具、接口测试要求和近期相关设计决策",
  "target_uri": "viking://user/dev_workspace/peers/project_atlas/memories/",
  "limit": 5
}

说明

相似实现可参考 OpenViking 官方的 Codex 插件：Codex 插件

最近更新时间：2026.09.17 17:49:16

这个页面对您有帮助吗？

有用

无用

向量数据库VikingDB

实践一：群聊 Agent 按发言人设置 Peer #

标记 Message：用户消息带自己的 Peer，助手消息保留助手身份 #

回流与抽取：逐条保留身份，按话题保存完整过程 #

检索：先确定服务谁，再确定哪些信息可以用于当前回复 #

实践二：Coding Agent 按项目或工作区设置 Peer #

确定 Peer：按需要共享记忆的工作范围划分 #

标记 Message：项目相关的输入、回复和工具结果使用同一个 Peer #

回流与抽取：固定任务归属，项目切换时不改写历史 #

检索：以当前任务的项目为目标，再按需加入通用记忆 #