复用之前 Assistants 建的 vs_abc，在 responses 里写 tools=[{type:file_search, vector_store_ids:[vs_abc]}]，返回 400，原文 Vector store ‘vs_abc’ not found，可控制台的存储列表里这个库还挂着。
一开始怀疑是「传的是上传文件的 file-xxx，而不是向量库的 vs-xxx」，查了一圈，方向不对。
真正麻烦的地方在于，几个原因的现象几乎一样。向量库属于另一个项目，换了项目 key 之后根本看不到。还有一种是库刚建完还在 in_progress，文件索引没完成就拿来引用。
不容易想到的是，组织调整后旧库被归档，列表接口默认不返回已归档对象。
先列出当前 key 真正能看到的向量库
curl https://api.openai.com/v1/vector_stores -H "Authorization: Bearer $OPENAI_API_KEY" | jq -r '.data[].id'随后查单个库的状态和文件计数
curl https://api.openai.com/v1/vector_stores/vs_abc -H "Authorization: Bearer $OPENAI_API_KEY" | jq '{status,file_counts}'接着在当前项目下新建一个库备用
curl https://api.openai.com/v1/vector_stores -H "Authorization: Bearer $OPENAI_API_KEY" -H "Content-Type: application/json" -d '{"name":"kb"}'索引完成后带上新库 id 再问一次
curl https://api.openai.com/v1/responses -H "Authorization: Bearer $OPENAI_API_KEY" -H "Content-Type: application/json" -d '{"model":"gpt-4o-mini","input":"文档里写了什么","tools":[{"type":"file_search","vector_store_ids":["vs_new"]}]}'恢复的判定其实很直接。向量库详情里 status 是 completed 且 file_counts.completed 与上传数一致，responses 返回 200 并在 output 里给出带 file_citation 的引用。
容易忽略的是，id 前缀就能区分对象类型，vs_ 是库、file- 是文件，混用时报错文案会误导到权限上，先看请求里的 id 前缀最省事。如果同一现象隔几天又出现，说明根因没找到，别当偶发处理。