环境
- MemoryCore
2.0.0-beta.1，commit 5299c00（feat/server_team）
- Windows 11 + Node 22.20.0，standalone gateway + SQLite
- 没用 OpenClaw 插件，直接
node --import tsx src/gateway/server.ts 起的
现象
standalone 模式下，只要请求头 x-tdai-service-id 不是 default，/v3/skill/create 就必然失败：
{"code":50001,"message":"agent_not_found: cannot ensure skill asset: agent agt-urji1kbmg7 not found","request_id":"req-1f3ddd1c73d54046"}但同一时刻用 /v3/meta/agent/get 查这个 agent 是查得到的，status: active。
复现步骤
以下 4 步请求头统一带 x-tdai-service-id: dev-1：
POST /v3/internal/meta/user/init-admin {"username":"dev-admin"} → 成功，拿到 user_id / user_keyPOST /v3/meta/agent/create {"team_id":"...","owner_user_id":"...","name":"test-agent-manual"} → 成功，拿到 agt-urji1kbmg7POST /v3/meta/agent/get {"agent_id":"agt-urji1kbmg7"} → 成功，确认 agent 存在POST /v3/skill/create 用同一组 team_id / agent_id / user_id → 失败，agent_not_found
把完全相同的 4 步全部换成 x-tdai-service-id: default，第 4 步就成功了（拿到 skl-V0BfvVIpQpKp）。
用 init-admin 自动创建的默认 agent、和用 /v3/meta/agent/create 手动新建的 agent，两种都试过，结果一致，跟 agent 怎么来的无关。
直接证据
两个实例的元数据库是分开存的，agent 明确落在 dev-1 那个库里：
tdai_metadata_default/metadata.db : users=0 agents=0
tdai_metadata_dev-1/metadata.db : users=1 agents=2
根因
MemoryCore/src/gateway/server.ts:356：
const skillAssetInstanceId = this.config.instanceId
?? (this.config.deployMode === "service" ? "__unset__" : "default");
这个值在闭包建立时只算一次，之后 ensureSkillAsset 全部走它（server.ts:373 / 380 / 397）。standalone 模式下 config.instanceId 为空，就固定成 default，跟每个请求头里的 x-tdai-service-id 没有关系。
而 /v3/meta/* 那条链路是按请求头解析实例的（metadata/router/instance.ts 的 extractInstanceId）。两边解析出来的 instance 不一致，就出现了「agent 在 meta 层查得到、skill 登记时查不到」。
影响
standalone 部署只要用了非 default 的 service-id，skill 功能整体不可用。/v3/skill/create 是入口，它进不去，后面 get / list / search 都无从谈起。
环境
2.0.0-beta.1，commit5299c00（feat/server_team）node --import tsx src/gateway/server.ts起的现象
standalone 模式下，只要请求头
x-tdai-service-id不是default，/v3/skill/create就必然失败：{"code":50001,"message":"agent_not_found: cannot ensure skill asset: agent agt-urji1kbmg7 not found","request_id":"req-1f3ddd1c73d54046"}但同一时刻用
/v3/meta/agent/get查这个 agent 是查得到的，status: active。复现步骤
以下 4 步请求头统一带
x-tdai-service-id: dev-1：POST /v3/internal/meta/user/init-admin{"username":"dev-admin"}→ 成功，拿到 user_id / user_keyPOST /v3/meta/agent/create{"team_id":"...","owner_user_id":"...","name":"test-agent-manual"}→ 成功，拿到agt-urji1kbmg7POST /v3/meta/agent/get{"agent_id":"agt-urji1kbmg7"}→ 成功，确认 agent 存在POST /v3/skill/create用同一组 team_id / agent_id / user_id → 失败，agent_not_found把完全相同的 4 步全部换成
x-tdai-service-id: default，第 4 步就成功了（拿到skl-V0BfvVIpQpKp）。用 init-admin 自动创建的默认 agent、和用
/v3/meta/agent/create手动新建的 agent，两种都试过，结果一致，跟 agent 怎么来的无关。直接证据
两个实例的元数据库是分开存的，agent 明确落在 dev-1 那个库里：
根因
MemoryCore/src/gateway/server.ts:356：这个值在闭包建立时只算一次，之后
ensureSkillAsset全部走它（server.ts:373 / 380 / 397）。standalone 模式下config.instanceId为空，就固定成default，跟每个请求头里的x-tdai-service-id没有关系。而
/v3/meta/*那条链路是按请求头解析实例的（metadata/router/instance.ts的extractInstanceId）。两边解析出来的 instance 不一致，就出现了「agent 在 meta 层查得到、skill 登记时查不到」。影响
standalone 部署只要用了非 default 的 service-id，skill 功能整体不可用。
/v3/skill/create是入口，它进不去，后面 get / list / search 都无从谈起。