OpenClaw 多租与身份透传测试报告

1. 测试目标

本轮测试围绕 examples/openclaw-plugin 的多租户与会话身份透传能力展开，重点验证以下目标：

1. 验证插件在 api_key 与 trusted 两种服务认证模式下的请求头行为是否正确。
2. 验证插件是否按照服务侧命名空间策略，将 viking://user/memories 与 viking://user/memories 正确展开为 canonical URI。
3. 验证 senderId / requesterSenderId 是否能够稳定映射为会话消息的 peer_id。
4. 验证 afterTurn 与 memory_store 两条写会话路径的身份语义是否一致。
5. 验证多租户场景下用户空间、共享资源与 peer/session metadata 的召回行为是否符合预期。

2. 测试方法

2.1 服务端直连验证

在 OpenClaw 之前，先通过 OpenViking HTTP API 直接验证服务端状态与数据面：

• 使用 curl 调用 /health、/api/v1/system/status、/api/v1/search/find
• 直接验证显式 URI，例如：
  • viking://user/default/memories
  • viking://user/default/skills
  • viking://resources
• 通过结构化 seed 与分层 reindex，确保召回验证基线可用

2.2 插件端到端验证

通过真实 OpenClaw gateway 与 OpenViking 后端联调验证：

• 远端 19950：用于 api_key 模式与用户空间验证
• 远端 19960：用于 trusted 模式与 peer_id 验证
• 使用真实 Feishu 机器人入口验证真实 sender 映射
• 结合以下日志进行判定：
  • before_prompt_build
  • find POST
  • session message POST
  • session commit POST

2.3 真实机器人验证

针对 peer_id 透传行为，使用真实机器人私聊/群聊场景复核：

• 私聊验证真实 sender 到 peer_id 的稳定映射
• 群聊验证不同成员写入不同 peer_id
• 工具调用验证 memory_store 路径是否能通过 requesterSenderId 写出 peer_id

3. 测试范围

3.1 认证模式

• api_key
• trusted
• trusted + root_api_key

3.2 命名空间策略

• user-scoped memory：viking://user/<user_id>/memories
• user-scoped skills：viking://user/<user_id>/skills
• shared resources：viking://resources

3.3 身份透传

• afterTurn.runtimeContext.senderId -> peer_id
• memory_store.requesterSenderId -> peer_id
• assistant message 不传 peer_id

4. 测试结果

4.1 通过项

维度	case	结果	说明
api_key	api_key_without_key_dev	通过	不再合成 default/default 租户 header
api_key	personal_token_default	通过	命中 DEFAULT_USER_TOKEN_19950
api_key	runtime_peer_worker	通过	runtime agent 只参与 peer/session metadata
namespace	user_memory_token	通过	user memory 空间命中正确
namespace	user_skill_token	通过	user skill 空间命中正确
namespace	resource_token	通过	shared resource 空间命中正确
trusted	trusted_without_key	通过	无 key trusted 路径正常
trusted	trusted_with_key	通过	带 key trusted 路径正常
trusted	trusted_root_key_required	通过	不带 key 被服务侧拒绝
trusted	trusted_root_key_optional_ok	通过	带 root key 正常
senderId -> peer_id	senderid_trusted_user_msg	通过	telegram:12345 -> telegram_12345
senderId -> peer_id	senderid_trusted_blank	通过	peer_id:null
senderId -> peer_id	senderid_sanitize_symbols	通过	wx/user-01@abc -> wx_user-01_abc
真实机器人	私聊 sender 映射	通过	sender 稳定映射到真实 peer_id
真实机器人	群聊多成员 peer_id	通过	不同成员落不同 peer_id
memory_store	requesterSenderId -> peer_id	通过	memory_store 已使用 requesterSenderId 写出真实 peer_id

4.2 已知说明

项目	状态	说明
user_token_main_default	已打通	曾出现一次回答少 _19950，属于回答精度问题，不是链路问题
真实机器人最终回复	非插件问题	群聊/私聊中出现的 Something went wrong... 已定位在 OpenClaw 工具结果回填阶段，与 OpenViking 插件链路无关

5. 关键结论

1. 插件侧 user namespace、显式租户 header 与 peer_id 透传能力已完成联调验证。
2. afterTurn 路径可通过 runtimeContext.senderId 正确写出 peer_id。
3. memory_store 路径在工具上下文中无法直接读取 senderId，但可稳定通过 requesterSenderId 写出 peer_id。
4. 在真实机器人私聊与群聊场景中，已确认不同用户会被映射为不同的 peer_id，且 assistant message 保持 peer_id:null。
5. 当前 OpenViking 插件链路已满足多租户、命名空间与 sender 身份透传的测试目标。

6. 建议

1. 若后续服务端对 api_key + USER 的 peer_id 语义收紧，应补充一条显式兼容说明或服务端协同约束。
2. 如需继续扩大矩阵，可追加：
   • 更多账号/用户组合
   • 不同群聊成员的稳定性回归
   • memory_store 与 afterTurn 跨会话一致性复测
3. 若要沉淀为长期回归用例，建议将当前已验证的矩阵继续脚本化，但保留真实机器人场景作为最终回归验证补充。