一个Java开发人员最近给公司的售后系统做了企业知识库Agent。员工可以直接提问"退款要满足什么条件"，Agent通过检索工具找到政策文档，再给出回答和引用来源。
上线初期效果不错，直到运营更新了一份退款规则。旧政策规定部分商品需要在七天内申请，新政策调整了适用范围，并补充了新的审批条件。运营删除旧PDF，上传新版本，后台也提示"更新成功"。
第二天，客服向Agent询问退款流程，得到的却仍是旧规则。更尴尬的是，回答末尾还附着旧文档标题，像是有据可查。
开发人员检查上传记录，新文件确实存在；调用知识库工具也没有报错。团队于是让Codex排查Prompt，试着加入"优先使用最新文档"，但回答还是时新时旧。
文件已经更新，为什么Agent仍然引用旧政策？
问题往往不在模型是否听话，而在知识库并不是一个文件夹。原始文档、解析结果、文本分块、向量索引、检索缓存和对话上下文是一条异步链路。文件更新只是第一步，任何一层仍保留旧版本，都可能让Agent回答过期内容。
一、先找到断点：上传成功不等于知识已经生效
先还原这次请求：运营在管理页面上传了新PDF，文件存储返回成功，数据库里的文档记录显示新版本；但客服发起检索时，系统返回的却是旧版Chunk。模型根据检索结果生成回答，自然会引用旧政策。
这里至少有四种不同的成功状态：原文件保存成功、解析和切块完成、索引完成并可检索、真实问答能够使用指定版本。管理后台只显示第一个状态，就宣布"知识库更新完成"，容易误导运营和开发者。
对Agent而言，检索结果才是它真正看到的材料。哪怕文件页面已经删掉旧PDF，只要向量库里的旧文本仍可被检索，模型就可能继续使用它。
知识更新的验收终点，不应该是上传接口返回200，而应该是目标版本已经进入可用检索结果，并能在回答中被正确引用。
二、第一层机制：原始文档、Chunk和向量不是同一份数据
典型的RAG流程是：原文件进入存储，解析器抽取正文，切分成多个Chunk，生成Embedding，写入向量索引；用户提问时再进行检索、重排和上下文拼装，最后由模型生成回答。
一个30页的政策文件可能被拆成几十甚至上百个片段。上传新PDF后，如果任务只覆盖了原始文件，没有触发重新解析和索引更新，检索端就看不到变化。
还要检查解析质量。新版PDF可能把关键规则写在表格、扫描图片或页脚里，解析器却漏掉这段内容。后台显示索引成功，实际可检索的Chunk却没有新条款。这时重新上传多少次也没用，必须拿解析后的文本与原文逐段核对，尤其检查本次修改过的章节。
还有一种情况：新文件已经完成切块，但旧Chunk没有删除。于是索引里同时存在新旧规则。它们包含大量相似关键词，比如"退款期限""申请条件"，向量检索很可能把两版都找出来。
这时问题不一定每次复现：用户换一种问法，检索排序就可能改变，今天回答新版，明天回答旧版。单纯提高Top K甚至可能让更多冲突片段一起进入模型上下文。
文档更新不是覆盖一个文件名，而是替换一组与版本绑定的衍生数据。
三、第二层机制：删除旧文件，为什么旧向量还在？
很多系统把"删除文件"和"删除索引"设计成两个异步动作。管理端删除文件后，存储层已经不可见，但向量数据库仍有相同文档ID对应的记录，或者索引清理任务还在队列中。
如果每次上传都生成新的随机文档ID，而旧文档没有建立稳定的业务标识，也可能出现"新旧两个文件都被当成有效资料"的情况。反过来，若仅按文件名覆盖，又容易误删不同部门恰好同名的文档。
需要为知识对象设计稳定的业务文档ID，并为每次内容变更分配明确版本。Chunk需要关联文档ID、版本、租户和发布状态；旧版进入撤销状态后，检索层应立即拒绝返回它，即使物理向量删除仍在后台执行。
这可以理解为先在逻辑上撤销旧版本，再完成物理清理。否则，在删除任务执行的时间窗口内，旧政策依旧可能流入回答。
四、第三层机制：索引任务成功，为什么用户仍看到旧结果？
即使新Chunk已经写入向量库，也不代表线上检索正在使用这批数据。大型知识库可能存在增量索引、批量重建、读写副本和索引别名。写入使用新索引，查询却还指向旧索引，就会出现"后台显示完成，线上仍旧"的现象。
更棘手的是任务并发：运营连续上传v2和v3，v3先完成，耗时更长的v2任务随后结束。如果没有版本检查，旧任务可能把检索指针重新指回v2，形成版本倒退。
工程上需要把"构建完成"和"发布生效"分开。先在隔离索引里完成解析、向量写入和抽样检索，确认版本正确后，再通过受控的索引别名或版本指针切换；发布动作必须检查预期版本，避免旧任务覆盖新任务。
这类切换应尽量让一次检索使用同一版知识快照，避免同一个回答的不同片段来自不同发布批次。
五、第四层机制：缓存和对话历史也会把旧答案带回来
排查时，开发人员发现直接搜索新文档关键词已经可以命中v3，但聊天窗口仍返回旧政策。继续追踪后才看到，应用有查询结果缓存和答案缓存：相似问题命中旧缓存后，根本没有重新检索。
还有一个常见入口是对话历史。用户之前询问过旧规则，Agent在后续轮次可能继续引用历史回答，即使当前知识库已更新。若系统摘要了长期对话，旧政策甚至可能被写入摘要。
所以不能只清理向量索引。应检查检索缓存、重排缓存、完整答案缓存，以及长会话里的知识引用。
更稳妥的缓存键需要包含租户、权限范围和知识发布版本。版本切换后，旧缓存自然不能满足新版本请求。对于涉及退款、权限、合规等可能产生业务后果的内容，应优先要求重新检索并核对有效版本，而不是只依赖上一次生成的答案。
尤其不能只以用户提问文本生成答案缓存键。不同租户、不同地区和不同政策版本可能问同一句"能退款吗"，却对应完全不同的有效规则。如果缓存缺少授权和版本维度，问题就不只是旧答案，还可能演变成跨租户引用错误。
模型引用旧内容，不一定是模型记忆出了问题，也可能是应用把旧内容再次作为当前证据提供给它。
六、第五层机制：检索正确，为什么回答仍然引用旧规则？
假设检索结果已经包含新版Chunk，但模型依旧输出旧政策。此时需要检查实际送入模型的上下文，而不是只看向量库搜索页面。
有的系统先召回20段，再由重排器挑选5段；新版虽然被召回，却在重排阶段被旧版挤掉。也有系统把"历史问答摘要"排在检索证据之前，使模型沿用旧结论。
此外，检索结果若只有文本，没有文档版本、发布日期和来源标识，模型也无法可靠判断哪一段有效。让Prompt写上"只用最新文档"，不能代替真正的版本过滤。
比较稳妥的做法，是在检索阶段按已发布版本过滤候选内容，重排时保留来源元数据，送入模型时明确给出有效政策片段。生成后再核对引用的文档ID和版本是否属于本次有效知识快照。
这并不保证模型永远不会概括错误，但至少可以防止一个已经撤销的文档继续被当作合法依据。
七、修复方案：给知识库建立可追踪的发布链路
与其给上传接口再加一个"完成"提示，不如建立完整的文档状态：已上传、解析中、索引中、待验证、已发布、已撤销、失败。
一份文档的每次更新都应有明确的文档ID、内容版本、内容摘要和索引批次；每个Chunk也要带上相同的版本关系。系统可以在操作台显示：原文件已保存，不等于索引已生效；发布失败时，应继续使用经过确认的上一个有效版本，并明确告知运营当前版本，而不是假装已经更新。
对于替换政策，发布前先检查新文件是否完成解析，Chunk数是否异常，关键章节是否可被检索，引用是否指向正确文档。验证通过后，再把有效版本指针切换过去，并让旧版本立即退出检索候选集。
旧Chunk可在后续安全清理，但必须确认不会再被正常检索。若涉及多租户，还要让文档版本和授权范围同时生效，不能因为更新索引而让其他租户读到不属于自己的政策。
核心思路是先构建、再验证、最后发布，而不是边更新边让用户随机命中新旧内容。
八、怎样让Codex排查，而不是只修改Prompt？
不要只告诉Codex"知识库回答不准"。应该给它一条异常问答的追踪信息：用户问题、最终答案、引用来源、检索候选Chunk、重排结果、实际送入模型的上下文，以及文档上传和索引任务记录。敏感文档需要脱敏或在受控环境分析。
让Agent依次判断：新文件是否成功解析？新旧Chunk是否并存？检索指向哪个索引版本？过滤和重排是否丢掉新内容？答案或会话缓存是否命中旧版本？最终引用来自哪份文件？
找到断点后再做最小修复。如果是旧Chunk残留，补齐撤销过滤；如果是索引发布落后，修正版本指针；如果是缓存失效不完整，就让缓存与发布版本关联。
不要同时调大Top K、修改Embedding模型、重建全部索引、重写Prompt。这样即使暂时回答正确，也很难确认真正的修复点。更换Embedding模型还涉及向量维度和索引兼容性，不能在未规划迁移时把不同模型产生的向量随意混合。
九、修复后，怎样设计一组能发现旧知识的回归测试？
不能只输入"退款怎么申请"，看答案有没有出现新政策关键词。更有效的是为每次发布准备一组版本敏感问题，特别覆盖新旧政策差异最大的条款。
例如，旧版与新版对申请期限、适用商品和审批步骤的规定不同，就分别提问这些条件。测试不仅检查回答文本，还要检查引用的文档ID、版本和有效状态。
还需要故障注入：让新索引构建延迟、删除任务失败、缓存仍保留旧答案，或连续上传两个版本，检查系统会不会发布倒退、引用旧文档或错误宣称更新完成。
对于长会话，先在旧版本下提问，再切换新政策继续追问，验证系统能否主动重新检索并纠正历史回答。涉及关键业务时，无法确认有效版本应明确提示暂时无法给出可靠政策结论，而不是把旧内容包装成最新答案。
十、只突出一个指标：知识生效时延
这篇的核心指标是知识生效时延：从运营正式提交并批准发布新文档，到线上检索和回答能够稳定采用目标版本所经历的时间。
例如，14:00发布v3，14:03新索引写入完成，14:05切换了线上版本，但答案缓存直到14:08才失效。在这段时间里，部分请求仍返回旧政策，那么真正的知识生效时间不能简单记为14:03。
测量时，应选取代表性问题，持续核对检索版本、回答内容和引用来源。只有目标版本在约定测试范围内稳定通过，才确认生效。若多实例或多租户分别发布，还要明确统计范围，并关注最慢节点，不要只取一次成功查询当作完成。
知识生效时延越短不一定越好。不能为了追求秒级更新，跳过解析质量检查和版本校验。真正的目标，是让每次知识变更何时生效、失败在哪里、能否回退，都有可以核查的结果。
十一、Plus和Pro怎么判断？
如果主要用ChatGPT、Codex维护一个知识库项目，检查文档切块、向量检索、缓存失效和少量引用错误，Plus通常够用。
如果长期要跨多个知识库、检索服务和Agent工作流分析版本发布、权限过滤、索引切换和大批量回归评测，还要多轮修改代码与运行测试，Pro更适合高频、长任务的工程工作流。
选择套餐仍要结合实际任务规模、使用频率与可用额度。无论Plus还是Pro，都不能替代文档版本治理、权限控制和知识更新的真实验收。
最后
Agent接入企业知识库，文档明明更新了，为什么回答还是旧版本？
因为用户看到的是一份新文件，Agent看到的却可能是旧Chunk、旧索引、旧缓存或旧对话摘要。文件更新成功，不等于整条检索链路同步完成。
可靠的改造路径是：记录文档版本 → 重建并验证Chunk和索引 → 受控发布有效版本 → 撤销旧内容 → 让缓存跟随版本失效 → 校验检索与回答引用。
ChatGPT、Codex可以帮助定位知识更新的断点、补充发布流程和回归测试，但最关键的工程能力，是让系统能够回答三个问题：现在生效的是哪一版，为什么是这一版，旧版是否已经彻底退出可用结果。
企业知识库的可靠性，不只取决于Agent会不会检索，更取决于每一次知识变更，能否准确、及时、可验证地传递到最终回答。
持续分享 Codex、大模型开发与 AI 编程实战内容
也整理了稳定的 Plus/Pro 会员订阅渠道，有需要可自取。