把合同、政策和产品资料放进 OpenAI File Search，Agent 就能检索文件并回答问题。但团队接下来要做的事往往超出这次回答：谁确认了结论，哪份文件支持它，原来记录里的说法是否需要修改，下一位同事或 Agent 应该读取哪一个版本？
如果只把回答复制进群聊，文件引用容易和结论分开；如果直接覆盖业务表，检索到的一段话又可能被当成已经确认的事实。需要设计的交接，是把检索证据、修改提案和最终采用的记录连接起来。
OpenAI File Search 可以负责找资料，Busabase 可以承接结构化记录与变更审核。两者通过你自己的应用或 Agent 工具连接；这需要显式编排检索、映射和写入步骤。
先分清回答、引用和检索结果
OpenAI File Search 文档说明，它是 Responses API 的托管工具，面向已上传到 vector store 的文件进行语义和关键词检索。调用方先准备文件与索引，再在请求的 tools 中启用 file_search 并指定 vector_store_ids。
返回内容里，file_search_call 表示工具调用，message 承载回答，回答中的 file_citation 注释可以提供 file_id、filename 和引用位置。应用应该从结构化注释提取这些字段，而不是从显示出来的脚注符号猜文件身份。
检索结果默认不会随工具调用返回。需要保留证据片段时，在请求中显式加入 include: ["file_search_call.results"]。引用告诉你回答关联了哪些文件；检索结果提供核对材料。两者都不能代替人工判断某段材料是否足以支持具体结论。
用两张表保存交接，而不是一列长回答
建议从一个 Folder 和两张 Base 开始。以下是可按业务调整的起步设计：证据 Base 保存来源与核对材料，结论 Base 保存团队实际采用的判断。已有业务表时，直接复用它作为结论表。
证据表使用短标题作为主字段，另设文件标识（text）、文件名（text）、来源入口（url）、相关片段（longtext）、采集时间（date）和响应标识（text）。来源入口应指向团队有权访问的原文件或存储入口；file_id 本身不是人人可打开的下载地址。
结论表保存问题（主字段）、当前结论（longtext）、证据关系（relation）、业务状态（select）和负责人（text）。一条结论可以关联多份证据。业务状态例如“需要核实”或“已确认”，表示这条业务记录的含义；CR 的 in_review、approved、merged 表示修改提案的状态，两者分别管理。
文件可能过期或被替换。保留文件标识、采集时间和原始出处，可以让下一次复核知道本次依据是什么。如果现有源系统有版本号或内容摘要，也一起保存；不要只靠可能重复的文件名认定版本。
提议修改前，读取当前记录
检索得到答案后，Agent 先查现有结论与其当前版本，判断它是在补证据、纠正旧判断，还是回答了另一个问题。使用稳定的问题标识查找同一主题，避免每次运行都创建一条近似记录。
可以给已连接 Busabase 工具的 Agent 这样的指令：
读取这次 File Search 回答、结构化引用与已返回的检索结果。在指定的证据表和结论表中查找现有主题。把支持每个判断的片段与文件标识对应起来；有矛盾就保留矛盾，不推断缺失条款。读取当前结论和版本后，只为有证据的字段提交变更提案，保留旧值供比较，返回提案入口。
指令需要和实际工具能力配套。Busabase MCP 文档介绍连接入口；OpenAI 的文件权限与 Busabase 的记录权限需要各自配置。给 Agent 访问一端的凭据，不会自动开放另一端。
把“必须待审”落实到写入权限
Busabase Change Requests保留修改前后和提交历史。提案专用 changeRequest 权限会让写入等待审核；拥有 write 权限的写入可能创建后立即合并。需要这批结果等待人工时，应使用提案专用凭据，或在支持的调用中显式传入 autoMerge: false。
审核者检查的重点包括：证据是否支持每个拟修改字段、来源是否仍适用、是否遗漏反例，以及旧记录是否已经被别人更新。发现材料不足时，退回补证据比把不确定判断改成肯定答案更有用。
获批与合并分开核实。读取实际 CR 状态，合并后再回读 canonical 记录，确认最终结论和证据关系一致。关于这种记录与知识库的分工，可进一步阅读Agent 记忆、知识库与记录系统。
下一次任务读取哪一层
日常执行优先读取已合并的结论与关联证据；待审提案只在明确的审核流程中读取。业务还要求“已确认”才能行动时，下游应额外检查该业务字段，不能把 merged 自动解释为业务负责人已授权外部动作。
来源变化后，重新检索并对照现有结论，提出带新证据的更新。请求超时则先寻找原提案和当前记录，再决定是否重试；保留响应标识与主题标识，减少重复创建。
先用一个真实问题走通交接
选择一个有明确来源、已有团队记录、需要负责人判断的问题。检查文件索引完成、引用能对应原文、提案等待方式符合权限、合并前旧值保持、合并后下次读取新值。外部发送或业务操作另按原有授权执行。
File Search 帮助回答问题，而有来源的记录让团队能在同一个判断上继续工作。先把这条交接走通，再决定是否扩大资料范围和自动执行的权限。