执行bl memory add后拿到了event_id，紧接着检索却为空，应该重新提交吗？先别重复写入。这个 ID 代表提交事件，抽取可能还在后台继续；真正用于查看和修改记忆节点的，是memory_node_id。
百炼当前 CLI 命令参考把几个常见混淆写得很清楚：提交成功与抽取完成不同，节点 ID 与事件 ID 不同，事实记忆与技能记忆的默认检索范围也不同。按这个顺序检查，比反复 add 更容易找到原因。
图：阿里云百炼官方 Memory 命令参考。说明中明确写出--wait 0只返回回执，且event_id不是记忆节点 ID。
先按现象选检查入口
| 看到的现象 | 先检查哪里 | 下一步 |
|---|---|---|
| add刚返回event_id，search为空 | 抽取是否仍在后台 | 查现有list结果，不立即重复add |
| 同一内容在不同终端结果不同 | 空间、用户、库与规则 | 把写入和查询参数并排对照 |
| 已有Skill，默认search为空 | search默认只查observation | 显式传入skill类型 |
| node show提示找不到节点 | 是否误用了event_id | 从list或search取得memory_node_id |
第一步：确认抽取是否已经完成
Memory能力目前对中国站账号开放，以下CLI操作适用于2.5.0及以上，API Key与业务空间必须一致。先理解这条链路：提交内容 → 后台抽取 → 形成记忆节点 → 按范围检索。拿到提交事件的回执，只说明进入了前面的环节。
| ID或状态 | 能说明什么 | 不能据此判断什么 |
|---|---|---|
| event_id | 内容提交对应的事件 | 不能代替记忆节点ID，也不能说明抽取完成 |
| memory_node_id | 已形成的具体记忆节点 | 节点存在不保证能被当前查询范围命中 |
| 本地等待超时 | CLI的等待预算已经用完 | 不代表后台一定停止或全部失败 |
写入时使用--wait 0会立即返回；默认等待预算为120秒，超时后后台仍可能继续处理。一次调用也可能新增、更新或删除多个节点。先查看既有结果，避免在状态不明时再次写入同一内容。
下面使用独立测试用户标识，执行会访问云服务：
bl memory list --user-id demo-user --output json关注对应内容及memory_node_id。列表一次只返回一页，暂时没看到目标节点，还要结合分页、规则和后台处理进度判断。
第二步：把写入和检索的范围对齐
同样一句查询，放在不同用户、记忆库或规则里，结果可能完全不同。排查时把下面几项并排核对。
| 范围 | 写入端 | 查询端重点 |
|---|---|---|
| 业务空间 | 参数、环境变量或配置项 | 必须指向相同空间，Key也属于该空间 |
| 用户 | --user-id | 使用同一个用户标识 |
| 记忆库 | --library-id，或默认库 | 不要一端显式指定、一端误用其他默认值 |
| 规则 | add 的--project-id | list 用--project-id；search 用--project-ids |
| 类型 | observation或skill | search默认只查observation |
业务空间配置的优先级是命令参数、BAILIAN_WORKSPACE_ID环境变量、配置项workspace_id。怀疑终端默认值不一致时，可以在排查命令中显式传--workspace-id，避免请求跑到另一个空间。
普通 list 默认只列默认规则，并且每次只返回一页。刚写入的节点不在当前一页，或者写入时指定了其他规则，都可能造成“列表里没有”的错觉。
第三步：如果写的是Skill，显式查Skill
官方规定，search 不传记忆类型时只检索事实记忆observation。写入了技能记忆，再用默认查询方式找不到，首先要修正的是查询范围。
下面以已有的技能规则为例。把尖括号内的规则 ID 替换成实际值后执行；CLI 本身不提供规则创建命令。
bl memory search --user-id demo-user --query "整理学习笔记" --memory-types skill --project-ids <skill-project-id> --output json需要同时查事实与技能时，在查询中同时指定observation和skill。search使用复数参数--memory-types与--project-ids；旧单数别名不要和新名称混用。
先看一个只改变查询类型的对照：节点 N2 始终存在，默认范围返回空，显式查 skill 则命中 N2。这是独立本地教学例子的实际输出，只做关键词筛选，不调用百炼或模拟语义相似度。
图：独立本地教学例子的实际输出。节点 N2 已存在，只改变查询类型就从空结果变成命中；这不是百炼云服务的返回界面。
这个对照说明：节点存在与当前查询能否命中，是两件事。先改查询范围再判断是否需要重写，可以减少重复记忆。
第四步：拿到节点ID后，直接看节点
从list或search取得memory_node_id后，可用节点详情命令bl memory node show --node-id <memory_node_id> --output json检查节点。
错误的做法是把 add 返回的event_id填进--node-id。两者指向的对象不同，等待更久也不会让事件 ID 变成节点 ID。节点详情还可能显示status为delete，这时要结合列表与搜索结果判断它是否已经被删除。
如果节点确实存在，但相似度搜索仍然为空，再看策略和过滤条件。--min-score只在 pro 策略生效；lite 不按这个阈值过滤。两种策略的分数不能直接混比，空结果本身也不是命令报错。
这组排查的终点是明确哪一步不一致：后台还没完成、查错范围、记忆类型不对，还是已有节点被过滤。确认原因后再决定是否重提，避免把同一个事实重复写进记忆库。
资料：百炼 Memory CLI 操作指南、Memory 命令参考。
