OpenViking × OpenClaw 多租户与会话身份透传联调指南认证模式、命名空间策略与 role_id 映射全解析【免费下载链接】OpenVikingSelf-evolving Context Database for AI Agents. Unify Agent Memory, Knowledge RAG and Skills.项目地址: https://gitcode.com/GitHub_Trending/op/OpenViking本篇技术指南围绕 examples/openclaw-plugin 的 OpenClaw 记忆插件系统讲解其在 OpenViking 服务端之上实现的多租户Multi-Tenant与会话身份透传Identity Passthrough能力。文章以 openclaw-multi-tenant-test-report.md 的实测矩阵为主线深入api_key/trusted两种服务认证模式、ff / tf / tt三种命名空间策略以及senderId/requesterSenderId到会话消息role_id的稳定映射机制。读完本文你将掌握该插件在真实 OpenClaw gateway 与 OpenViking 后端联调中如何按 account/user 租户与 actor peer 维度正确路由请求、隔离召回与写入身份并能据此复现验证与扩展测试矩阵。1. 测试目标多租户与身份透传要解决什么在接入层OpenClaw与记忆层OpenViking分离的架构里一个 OpenViking 服务端需要同时服务多个 OpenClaw agent、多个账号account与多个用户user并且要能区分这条记忆/这次召回属于谁。本轮测试围绕以下五个目标展开验证插件在api_key与trusted两种服务认证模式下的请求头行为是否正确验证插件是否在 account/user 租户身份之外按peer_role/peer_prefix生成一致的peer_id与X-OpenViking-Actor-Peer验证senderId/requesterSenderId是否能够稳定映射为会话消息的role_id验证afterTurn与memory_store两条写会话路径的身份语义是否一致验证多租户场景下默认用户空间与不同 actor peer 视角下的召回行为是否符合预期。从源码结构看这五项目标恰好对应插件中三个独立但协作的模块租户 header 解析client.ts 的resolveTenantHeaders、peer 身份路由routing/identity-routing.ts 与 plugin/openviking-session-routing-runtime.ts、以及会话写入路径services/context-lifecycle-service.ts 的 assemble/afterTurn 编排。2. 认证模式api_key 与 trusted 的请求头语义2.1 两种模式的差异模式含义典型场景api_key客户端携带 API Key服务端依据 Key 派生租户身份默认部署每个用户/账号一个 Keytrusted服务端信任网关转发允许不带 Key 或带 root Key网关代理、内部网络、需要显式传租户 header 的部署trusted root_api_keytrusted 模式下服务端要求 root Key 才放行显式租户 header多租户托管服务防止租户身份伪造测试报告中远端19950端口用于api_key模式与命名空间矩阵验证远端19960端口用于trusted模式与role_id验证分别覆盖两种模式的全链路。2.2 请求头生成源码解析插件在每次请求前通过resolveTenantHeaders()组装租户身份client.ts并在request()中写入三个关键 headerclient.tsX-API-Key来自配置的apiKeyX-OpenViking-Account来自配置的accountIdX-OpenViking-User来自配置的userIdX-OpenViking-Actor-Peer来自按 peer 身份计算出的actorPeerId。需要特别说明的是无 Key 时插件不再合成default/default租户 header。这对应测试矩阵中api_key_without_key_dev用例的判定不再合成 default/default 租户 header——身份完全由服务端从 Key 派生客户端不画蛇添足。accountId与userId在配置中是高级选项注释明确说明With a user key the server derives identity from the key使用用户 Key 时服务端从 Key 派生身份。因此这两个字段只在 root-key 或 trusted 部署、需要显式发送租户身份 header 时才需要配置见 config.ts 与uiHints说明。2.3 认证模式的判定日志测试报告将before_prompt_build、find POST、session message POST、session commit POST四类日志作为判定依据。其中find POST与会话写入日志由logFindRequests配置项控制或通过OPENVIKING_LOG_ROUTING1/OPENVIKING_DEBUG1环境变量开启输出X_OpenViking_Account、X_OpenViking_User、X_OpenViking_Actor_Peer三项路由信息永远不会输出 apiKeyclient.ts。3. 命名空间策略ff / tf / tt 三档隔离矩阵3.1 三种策略语义策略user 侧agent 侧适用场景ffuser 不按 actor peer 归因agent 不按 user 隔离单租户、共享知识库tfuser 按 actor peer 归因agent 不按 user 隔离多用户区分、agent 共享ttuser 按 actor peer 归因agent 按 user 隔离完全多租户隔离测试矩阵对每一种策略都分别验证了 user token 与 agent token 两条路径ff_user_token/ff_agent_token/tf_user_token/tf_agent_token/tt_user_token/tt_agent_token全部通过。3.2 兼容路径与覆盖优先级测试范围中专门列出兼容路径legacy peer scope modeagent即旧配置中按 agent 维度做 peer scope 的别名新 policy 覆盖旧 alias新配置策略的优先级高于旧的legacy peer scope modeagent。对应用例deprecated_agent_alias通过与new_policy_overrides_deprecated通过保证升级迁移过程中旧配置不破坏新策略且新策略生效。3.3 peer 身份如何参与命名空间peer 身份由peer_role与peer_prefix两个配置项共同决定config.tspeer_rolenone默认、assistant、senderperson是sender的旧别名运行时归一化为sender见 config.tspeer_prefix仅当peer_roleassistant时生效作为 agent 派生 peer id 的前缀配置值为default时等价于空前缀config.ts。uiHints对存储路径给出精确定义config.tsnoneviking://user/user_id/memoriesassistantviking://user/user_id/peers/assistant_id/memoriessenderviking://user/user_id/peers/sender_id/memories3.4 actor peer id 的生成规则X-OpenViking-Actor-Peer的计算集中在 routing/identity-routing.tspeer_rolesender时actor peer 取自 sanitize 后的 sender iduser 侧身份peer_roleassistant时actor peer 取自 agent idpeer_rolesender但缺少 sender 身份时直接抛错peer_rolesender requires a sender identity。而默认的 agent actor peer 由resolveDefaultActorPeerHeader()生成${peerPrefix}_mainclient.ts。这正对应测试用例peer_prefix_worker中实际 agent 值为worker_main的判定——配置peer_prefixworker后agent 身份统一带上前缀worker_。4. 身份透传senderId / requesterSenderId 到 role_id 的两条路径4.1 两条写会话路径路径身份来源说明afterTurn.runtimeContext.senderId - role_id会话钩子上下文的runtimeContext.senderId会话轮次结束自动写回memory_store.requesterSenderId - role_id工具上下文的requesterSenderIdAgent 调用记忆写入工具时写回assistant message不传role_id助手消息保持role_id:null测试结论明确指出memory_store路径在工具上下文中无法直接读取senderId但可稳定通过requesterSenderId写出role_id。这正是工具上下文与钩子上下文字段命名差异导致的插件在 plugin/openviking-runtime-utils.ts 的extractToolSenderId中做了统一优先取requesterSenderId其次回退senderId两者都做 trim 校验。4.2 peer id 的清洗规则无论哪条路径raw sender 字符串在进入请求体之前都要经过sanitizeOpenVikingPeerIdrouting/identity-routing.ts清洗trim - 非 [a-zA-Z0-9_-] 统一替换为 _ - 去掉首尾 _ - 连续 _ 合并为一个这与测试矩阵中两个判例完全一致telegram:12345 - telegram_12345冒号被替换为下划线wx/user-01abc - wx_user-01_abc/与均被替换为下划线清洗后的 peer id 通过addSessionMessage的peerId参数写入请求体peer_id字段服务端将其落为会话消息的role_id。单测同样固化了这一行为requesterSenderId: wx/user-01abc时断言body.peer_id wx_user-01_abc且请求体不含role_id字段tests/ut/tools.test.tstelegram_12345作为peer_id传入时同样断言body没有role_id属性tests/ut/client.test.ts——role_id由服务端依据peer_id生成客户端只负责传递清洗后的身份。4.3 agent id 与会话 id 的映射除 sender 外agent 身份与会话 id 同样需要规范化sanitizeOpenVikingAgentIdHeaderOpenClaw agent id 可能含:而 OpenViking peer 标识只允许[a-zA-Z0-9_-]因此必须清洗后才可写入X-OpenViking-Actor-Peerrouting/identity-routing.tsopenClawSessionToOvStorageIdOpenClaw 会话 id/sessionKey 映射为 AGFS 路径安全的 OpenViking session_id——UUID 会话直接小写使用非 UUID 场景用sha256(sessionKey)派生稳定 idrouting/identity-routing.tscreateSessionAgentResolver按agent:agentId:前缀从 sessionKey 提取 agent id并支持会话级 agent 绑定记忆remember/resolve保证同一会话内 agent 身份一致routing/identity-routing.ts。5. 测试方法三层验证体系5.1 服务端直连验证在 OpenClaw 介入之前先用curl直连 OpenViking HTTP API 验证服务端状态与数据面调用/health、/api/v1/system/status、/api/v1/search/find直接验证显式 URI 的可达性viking://user/default/memoriesviking://resourcesviking://user/skillsviking://session/session_id/history通过结构化 seed 与分层reindex确保召回验证基线可用直连层的作用是先确认服务端自身行为正确把插件变量隔离在联调阶段之外避免两端问题互相污染。5.2 插件端到端验证通过真实 OpenClaw gateway 与 OpenViking 后端联调远端19950api_key模式与命名空间矩阵验证远端19960trusted模式与role_id验证使用真实 Feishu飞书机器人入口验证真实 sender 映射结合before_prompt_build、find POST、session message POST、session commit POST四类日志进行判定。5.3 真实机器人验证针对role_id透传行为用真实机器人私聊/群聊场景复核私聊验证真实 sender 到role_id的稳定映射群聊验证不同成员写入不同role_id工具调用验证memory_store路径能通过requesterSenderId写出role_id。6. 测试结果总览6.1 通过项维度case结果说明api_keyapi_key_without_key_dev通过不再合成default/default租户 headerapi_keypersonal_token_default通过命中DEFAULT_USER_TOKEN_19950api_keypeer_prefix_worker通过实际 agent 值为worker_main兼容deprecated_agent_alias通过legacy peer scope modeagent兼容正常覆盖优先级new_policy_overrides_deprecated通过新 policy 覆盖旧 aliasnamespaceff_user_token通过user 共享空间命中正确namespaceff_agent_token通过agent 共享空间命中正确namespacetf_user_token通过user 按 actor peer 归因命中正确namespacetf_agent_token通过agent 共享空间命中正确namespacett_user_token通过user/agent 双隔离命中正确namespacett_agent_token通过agent/user 双隔离命中正确trustedtrusted_without_key通过无 key trusted 路径正常trustedtrusted_with_key通过带 key trusted 路径正常trustedtrusted_root_key_required通过不带 key 被服务侧拒绝trustedtrusted_root_key_optional_ok通过带 root key 正常senderId - role_idsenderid_trusted_user_msg通过telegram:12345 - telegram_12345senderId - role_idsenderid_trusted_blank通过role_id:nullsenderId - role_idsenderid_sanitize_symbols通过wx/user-01abc - wx_user-01_abc真实机器人私聊 sender 映射通过sender 稳定映射到真实role_id真实机器人群聊多成员role_id通过不同成员落不同role_idmemory_storerequesterSenderId - role_id通过memory_store已使用requesterSenderId写出真实role_id6.2 已知说明项目状态说明agent_token_main_default已打通曾出现一次回答少_19950属于回答精度问题不是链路问题真实机器人最终回复非插件问题群聊/私聊中出现的Something went wrong...已定位在 OpenClaw 工具结果回填阶段与 OpenViking 插件链路无关值得关注的是第二条已知说明的判定方式通过find POST与session message POST日志确认 OpenViking 侧写入与召回均正常从而把问题域收敛到 OpenClaw 工具结果回填阶段。这体现了一套基于日志的链路责任判定方法——先用服务端日志排除插件链路再定位上层问题。7. 关键结论插件侧 peer identity routing、显式租户 header 与role_id透传能力已完成联调验证afterTurn路径可通过runtimeContext.senderId正确写出role_idmemory_store路径在工具上下文中无法直接读取senderId但可稳定通过requesterSenderId写出role_id在真实机器人私聊与群聊场景中已确认不同用户会被映射为不同的role_id且 assistant message 保持role_id:null当前 OpenViking 插件链路已满足多租户、命名空间与 sender 身份透传的测试目标。8. 后续建议与回归策略服务端语义协同若后续服务端对api_key USER的role_id语义收紧应补充一条显式兼容说明或服务端协同约束避免客户端假设与服务端实现脱节扩大矩阵可追加更多账号/用户组合、不同群聊成员的稳定性回归以及memory_store与afterTurn跨会话一致性复测脚本化回归将当前已验证的矩阵继续脚本化沉淀为长期回归用例同时保留真实机器人场景作为最终回归验证补充——自动化覆盖确定性链路真实入口兜底端到端语义。对希望复现验证的读者建议按以下顺序操作先在 examples/ov.conf.example 基础上配置 OpenViking 服务端并确认/health与/api/v1/system/status正常再参考 examples/openclaw-plugin/README.md 安装插件配置peer_role/peer_prefix/apiKey支持${ENV}插值或{source:env|file}形式的 SecretRef见 config.ts最后开启logFindRequests观察四类日志中的租户与 peer 路由信息即可对照本文第 6 节矩阵逐项判定。插件侧单元测试 tests/ut/tools.test.ts 与 tests/ut/client.test.ts 可作为快速验证 peer id 清洗与租户 header 语义的本地入口。【免费下载链接】OpenVikingSelf-evolving Context Database for AI Agents. Unify Agent Memory, Knowledge RAG and Skills.项目地址: https://gitcode.com/GitHub_Trending/op/OpenViking创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OpenViking × OpenClaw 多租户与会话身份透传联调指南：认证模式、命名空间策略与 role_id 映射全解析
OpenViking × OpenClaw 多租户与会话身份透传联调指南认证模式、命名空间策略与 role_id 映射全解析【免费下载链接】OpenVikingSelf-evolving Context Database for AI Agents. Unify Agent Memory, Knowledge RAG and Skills.项目地址: https://gitcode.com/GitHub_Trending/op/OpenViking本篇技术指南围绕 examples/openclaw-plugin 的 OpenClaw 记忆插件系统讲解其在 OpenViking 服务端之上实现的多租户Multi-Tenant与会话身份透传Identity Passthrough能力。文章以 openclaw-multi-tenant-test-report.md 的实测矩阵为主线深入api_key/trusted两种服务认证模式、ff / tf / tt三种命名空间策略以及senderId/requesterSenderId到会话消息role_id的稳定映射机制。读完本文你将掌握该插件在真实 OpenClaw gateway 与 OpenViking 后端联调中如何按 account/user 租户与 actor peer 维度正确路由请求、隔离召回与写入身份并能据此复现验证与扩展测试矩阵。1. 测试目标多租户与身份透传要解决什么在接入层OpenClaw与记忆层OpenViking分离的架构里一个 OpenViking 服务端需要同时服务多个 OpenClaw agent、多个账号account与多个用户user并且要能区分这条记忆/这次召回属于谁。本轮测试围绕以下五个目标展开验证插件在api_key与trusted两种服务认证模式下的请求头行为是否正确验证插件是否在 account/user 租户身份之外按peer_role/peer_prefix生成一致的peer_id与X-OpenViking-Actor-Peer验证senderId/requesterSenderId是否能够稳定映射为会话消息的role_id验证afterTurn与memory_store两条写会话路径的身份语义是否一致验证多租户场景下默认用户空间与不同 actor peer 视角下的召回行为是否符合预期。从源码结构看这五项目标恰好对应插件中三个独立但协作的模块租户 header 解析client.ts 的resolveTenantHeaders、peer 身份路由routing/identity-routing.ts 与 plugin/openviking-session-routing-runtime.ts、以及会话写入路径services/context-lifecycle-service.ts 的 assemble/afterTurn 编排。2. 认证模式api_key 与 trusted 的请求头语义2.1 两种模式的差异模式含义典型场景api_key客户端携带 API Key服务端依据 Key 派生租户身份默认部署每个用户/账号一个 Keytrusted服务端信任网关转发允许不带 Key 或带 root Key网关代理、内部网络、需要显式传租户 header 的部署trusted root_api_keytrusted 模式下服务端要求 root Key 才放行显式租户 header多租户托管服务防止租户身份伪造测试报告中远端19950端口用于api_key模式与命名空间矩阵验证远端19960端口用于trusted模式与role_id验证分别覆盖两种模式的全链路。2.2 请求头生成源码解析插件在每次请求前通过resolveTenantHeaders()组装租户身份client.ts并在request()中写入三个关键 headerclient.tsX-API-Key来自配置的apiKeyX-OpenViking-Account来自配置的accountIdX-OpenViking-User来自配置的userIdX-OpenViking-Actor-Peer来自按 peer 身份计算出的actorPeerId。需要特别说明的是无 Key 时插件不再合成default/default租户 header。这对应测试矩阵中api_key_without_key_dev用例的判定不再合成 default/default 租户 header——身份完全由服务端从 Key 派生客户端不画蛇添足。accountId与userId在配置中是高级选项注释明确说明With a user key the server derives identity from the key使用用户 Key 时服务端从 Key 派生身份。因此这两个字段只在 root-key 或 trusted 部署、需要显式发送租户身份 header 时才需要配置见 config.ts 与uiHints说明。2.3 认证模式的判定日志测试报告将before_prompt_build、find POST、session message POST、session commit POST四类日志作为判定依据。其中find POST与会话写入日志由logFindRequests配置项控制或通过OPENVIKING_LOG_ROUTING1/OPENVIKING_DEBUG1环境变量开启输出X_OpenViking_Account、X_OpenViking_User、X_OpenViking_Actor_Peer三项路由信息永远不会输出 apiKeyclient.ts。3. 命名空间策略ff / tf / tt 三档隔离矩阵3.1 三种策略语义策略user 侧agent 侧适用场景ffuser 不按 actor peer 归因agent 不按 user 隔离单租户、共享知识库tfuser 按 actor peer 归因agent 不按 user 隔离多用户区分、agent 共享ttuser 按 actor peer 归因agent 按 user 隔离完全多租户隔离测试矩阵对每一种策略都分别验证了 user token 与 agent token 两条路径ff_user_token/ff_agent_token/tf_user_token/tf_agent_token/tt_user_token/tt_agent_token全部通过。3.2 兼容路径与覆盖优先级测试范围中专门列出兼容路径legacy peer scope modeagent即旧配置中按 agent 维度做 peer scope 的别名新 policy 覆盖旧 alias新配置策略的优先级高于旧的legacy peer scope modeagent。对应用例deprecated_agent_alias通过与new_policy_overrides_deprecated通过保证升级迁移过程中旧配置不破坏新策略且新策略生效。3.3 peer 身份如何参与命名空间peer 身份由peer_role与peer_prefix两个配置项共同决定config.tspeer_rolenone默认、assistant、senderperson是sender的旧别名运行时归一化为sender见 config.tspeer_prefix仅当peer_roleassistant时生效作为 agent 派生 peer id 的前缀配置值为default时等价于空前缀config.ts。uiHints对存储路径给出精确定义config.tsnoneviking://user/user_id/memoriesassistantviking://user/user_id/peers/assistant_id/memoriessenderviking://user/user_id/peers/sender_id/memories3.4 actor peer id 的生成规则X-OpenViking-Actor-Peer的计算集中在 routing/identity-routing.tspeer_rolesender时actor peer 取自 sanitize 后的 sender iduser 侧身份peer_roleassistant时actor peer 取自 agent idpeer_rolesender但缺少 sender 身份时直接抛错peer_rolesender requires a sender identity。而默认的 agent actor peer 由resolveDefaultActorPeerHeader()生成${peerPrefix}_mainclient.ts。这正对应测试用例peer_prefix_worker中实际 agent 值为worker_main的判定——配置peer_prefixworker后agent 身份统一带上前缀worker_。4. 身份透传senderId / requesterSenderId 到 role_id 的两条路径4.1 两条写会话路径路径身份来源说明afterTurn.runtimeContext.senderId - role_id会话钩子上下文的runtimeContext.senderId会话轮次结束自动写回memory_store.requesterSenderId - role_id工具上下文的requesterSenderIdAgent 调用记忆写入工具时写回assistant message不传role_id助手消息保持role_id:null测试结论明确指出memory_store路径在工具上下文中无法直接读取senderId但可稳定通过requesterSenderId写出role_id。这正是工具上下文与钩子上下文字段命名差异导致的插件在 plugin/openviking-runtime-utils.ts 的extractToolSenderId中做了统一优先取requesterSenderId其次回退senderId两者都做 trim 校验。4.2 peer id 的清洗规则无论哪条路径raw sender 字符串在进入请求体之前都要经过sanitizeOpenVikingPeerIdrouting/identity-routing.ts清洗trim - 非 [a-zA-Z0-9_-] 统一替换为 _ - 去掉首尾 _ - 连续 _ 合并为一个这与测试矩阵中两个判例完全一致telegram:12345 - telegram_12345冒号被替换为下划线wx/user-01abc - wx_user-01_abc/与均被替换为下划线清洗后的 peer id 通过addSessionMessage的peerId参数写入请求体peer_id字段服务端将其落为会话消息的role_id。单测同样固化了这一行为requesterSenderId: wx/user-01abc时断言body.peer_id wx_user-01_abc且请求体不含role_id字段tests/ut/tools.test.tstelegram_12345作为peer_id传入时同样断言body没有role_id属性tests/ut/client.test.ts——role_id由服务端依据peer_id生成客户端只负责传递清洗后的身份。4.3 agent id 与会话 id 的映射除 sender 外agent 身份与会话 id 同样需要规范化sanitizeOpenVikingAgentIdHeaderOpenClaw agent id 可能含:而 OpenViking peer 标识只允许[a-zA-Z0-9_-]因此必须清洗后才可写入X-OpenViking-Actor-Peerrouting/identity-routing.tsopenClawSessionToOvStorageIdOpenClaw 会话 id/sessionKey 映射为 AGFS 路径安全的 OpenViking session_id——UUID 会话直接小写使用非 UUID 场景用sha256(sessionKey)派生稳定 idrouting/identity-routing.tscreateSessionAgentResolver按agent:agentId:前缀从 sessionKey 提取 agent id并支持会话级 agent 绑定记忆remember/resolve保证同一会话内 agent 身份一致routing/identity-routing.ts。5. 测试方法三层验证体系5.1 服务端直连验证在 OpenClaw 介入之前先用curl直连 OpenViking HTTP API 验证服务端状态与数据面调用/health、/api/v1/system/status、/api/v1/search/find直接验证显式 URI 的可达性viking://user/default/memoriesviking://resourcesviking://user/skillsviking://session/session_id/history通过结构化 seed 与分层reindex确保召回验证基线可用直连层的作用是先确认服务端自身行为正确把插件变量隔离在联调阶段之外避免两端问题互相污染。5.2 插件端到端验证通过真实 OpenClaw gateway 与 OpenViking 后端联调远端19950api_key模式与命名空间矩阵验证远端19960trusted模式与role_id验证使用真实 Feishu飞书机器人入口验证真实 sender 映射结合before_prompt_build、find POST、session message POST、session commit POST四类日志进行判定。5.3 真实机器人验证针对role_id透传行为用真实机器人私聊/群聊场景复核私聊验证真实 sender 到role_id的稳定映射群聊验证不同成员写入不同role_id工具调用验证memory_store路径能通过requesterSenderId写出role_id。6. 测试结果总览6.1 通过项维度case结果说明api_keyapi_key_without_key_dev通过不再合成default/default租户 headerapi_keypersonal_token_default通过命中DEFAULT_USER_TOKEN_19950api_keypeer_prefix_worker通过实际 agent 值为worker_main兼容deprecated_agent_alias通过legacy peer scope modeagent兼容正常覆盖优先级new_policy_overrides_deprecated通过新 policy 覆盖旧 aliasnamespaceff_user_token通过user 共享空间命中正确namespaceff_agent_token通过agent 共享空间命中正确namespacetf_user_token通过user 按 actor peer 归因命中正确namespacetf_agent_token通过agent 共享空间命中正确namespacett_user_token通过user/agent 双隔离命中正确namespacett_agent_token通过agent/user 双隔离命中正确trustedtrusted_without_key通过无 key trusted 路径正常trustedtrusted_with_key通过带 key trusted 路径正常trustedtrusted_root_key_required通过不带 key 被服务侧拒绝trustedtrusted_root_key_optional_ok通过带 root key 正常senderId - role_idsenderid_trusted_user_msg通过telegram:12345 - telegram_12345senderId - role_idsenderid_trusted_blank通过role_id:nullsenderId - role_idsenderid_sanitize_symbols通过wx/user-01abc - wx_user-01_abc真实机器人私聊 sender 映射通过sender 稳定映射到真实role_id真实机器人群聊多成员role_id通过不同成员落不同role_idmemory_storerequesterSenderId - role_id通过memory_store已使用requesterSenderId写出真实role_id6.2 已知说明项目状态说明agent_token_main_default已打通曾出现一次回答少_19950属于回答精度问题不是链路问题真实机器人最终回复非插件问题群聊/私聊中出现的Something went wrong...已定位在 OpenClaw 工具结果回填阶段与 OpenViking 插件链路无关值得关注的是第二条已知说明的判定方式通过find POST与session message POST日志确认 OpenViking 侧写入与召回均正常从而把问题域收敛到 OpenClaw 工具结果回填阶段。这体现了一套基于日志的链路责任判定方法——先用服务端日志排除插件链路再定位上层问题。7. 关键结论插件侧 peer identity routing、显式租户 header 与role_id透传能力已完成联调验证afterTurn路径可通过runtimeContext.senderId正确写出role_idmemory_store路径在工具上下文中无法直接读取senderId但可稳定通过requesterSenderId写出role_id在真实机器人私聊与群聊场景中已确认不同用户会被映射为不同的role_id且 assistant message 保持role_id:null当前 OpenViking 插件链路已满足多租户、命名空间与 sender 身份透传的测试目标。8. 后续建议与回归策略服务端语义协同若后续服务端对api_key USER的role_id语义收紧应补充一条显式兼容说明或服务端协同约束避免客户端假设与服务端实现脱节扩大矩阵可追加更多账号/用户组合、不同群聊成员的稳定性回归以及memory_store与afterTurn跨会话一致性复测脚本化回归将当前已验证的矩阵继续脚本化沉淀为长期回归用例同时保留真实机器人场景作为最终回归验证补充——自动化覆盖确定性链路真实入口兜底端到端语义。对希望复现验证的读者建议按以下顺序操作先在 examples/ov.conf.example 基础上配置 OpenViking 服务端并确认/health与/api/v1/system/status正常再参考 examples/openclaw-plugin/README.md 安装插件配置peer_role/peer_prefix/apiKey支持${ENV}插值或{source:env|file}形式的 SecretRef见 config.ts最后开启logFindRequests观察四类日志中的租户与 peer 路由信息即可对照本文第 6 节矩阵逐项判定。插件侧单元测试 tests/ut/tools.test.ts 与 tests/ut/client.test.ts 可作为快速验证 peer id 清洗与租户 header 语义的本地入口。【免费下载链接】OpenVikingSelf-evolving Context Database for AI Agents. Unify Agent Memory, Knowledge RAG and Skills.项目地址: https://gitcode.com/GitHub_Trending/op/OpenViking创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考