从知识补丁到上下文操作系统——RAG正在经历一场角色革命。当AI从问答走向任务执行时，仅仅检索文档已远远不够。本文深度剖析Agent时代下，RAG如何从静态知识库演进为动态的Context OS，解决业务状态、权限边界、风险控制等核心问题，揭示企业级AI落地的关键突破点。

过去几年，企业做RAG的目标很明确：

让模型别只靠参数记忆回答问题。

模型不知道企业制度，就去知识库里找；模型不知道产品规则，就把手册片段拉进上下文；模型容易幻觉，就让它基于外部证据回答。

这条路是对的，而且已经支撑起了很多成熟的生产系统。

但新的变化，出现在AI开始从“回答问题”走向“执行任务”之后。

当AI只是回答问题时，RAG要解决的是：模型应该参考哪几段资料。

可当AI开始接任务、拆步骤、调用工具、写系统、生成方案、触发流程，甚至替人完成一段业务动作时，RAG要解决的问题就变了：

它不能只告诉模型“资料在哪里”，还要告诉模型“当前场景下能不能这么做”。

资料找对了，动作仍然可能做错。

比如，用户问：

“我已经开票但还没发货，现在要退款，可以吗？”

一个问答型RAG可能会检索退款规则，然后回答：

“未发货订单原则上可以申请退款，具体以财务审批为准。”

这个答案没有错。

但如果这是一个客服Agent，它要处理的就不是“回答一句话”，而是“判断下一步怎么处理”。

这时候，它还要知道：

这个客户是不是大客户？有没有连续投诉？订单有没有关联销售承诺？当前客服有没有退款权限？这类话术能不能直接对外说？这个动作是不是必须先走主管审批？

你看，问题已经变了。

过去，RAG服务的是答案生成。

现在，RAG 要开始服务任务执行。

当AI只是回答问题时，RAG像一个知识库：用户问什么，它就帮模型找什么。

可当AI开始行动，RAG就不能只负责“把资料找出来”。

它还要回答一组更难的问题：

• 这条信息是否可信？
• 当前业务状态是否允许这么做？
• 这个用户有没有权限看到？
• 这个动作有没有风险？
• 这个判断有没有历史经验支持？
• 如果答错了，错误会回流到哪里？

所以，今天再讨论RAG，真正重要的问题已经不是“它会不会死”。

而是：

Agent时代，RAG还能不能只做一个知识库？

我的判断是：RAG没有死，但它正在失去“知识库”的旧身份。它会越来越像企业AI的Context OS。

一、RAG的旧身份：回答问题前的知识补丁

早期RAG的价值非常明确：模型不知道，或者模型记错了，就从外部知识里找证据，再把证据放进上下文，让模型基于证据生成答案。

这件事在问答型Chatbot时代非常成立。

企业有制度、FAQ、产品手册、帮助中心、SOP、接口说明。模型的参数里不可能天然知道这些内容，也不可能随时跟着企业政策变化更新。RAG 把这些外部知识接进来，确实解决了很多内部知识问答的问题。

它像一个很勤快的新同事。

• 你问年假制度，它能翻到制度条款。
• 你问退款规则，它能找到帮助中心说明。
• 你问产品参数，它能把手册里的信息整理成一段像样的回答。

在这个阶段，企业把RAG理解成“知识库 + 搜索 + 生成”，其实没有错。因为当AI的主要任务是回答问题时，RAG本来就是回答前的知识补丁。

它弥补的是模型参数记忆的不足。

• 模型不知道，就查。
• 模型可能编，就给证据。
• 模型需要引用，就把材料放进上下文。

所以我不想把今天的RAG说得很落后。事实上，很多生产级RAG已经发展得很好。

Hybrid Search、Rerank、Query Rewrite、多路召回、GraphRAG、Agentic Retrieval、评测集、权限过滤、引用溯源、观测系统，这些能力已经在不少成熟系统里成为标配。继续把所有RAG 都描绘成“切块+向量召回+Prompt拼接”，反而显得靶子太旧。

问题不是现代RAG不够强。

问题是Agent时代对RAG提出了新的系统责任。

RAG的第一性原理不是向量库，而是让外部证据进入模型的回答和行动过程。

过去我们更关心“回答时有没有证据”。

现在还要关心“行动前有没有足够上下文”。

这句话是整篇文章的分水岭。

如果AI只是回答，证据主要用来支撑答案。

如果AI要行动，证据还要支撑判断、约束、权限、流程和后续追责。

这就是RAG角色迁移的起点。

RAG角色迁移：从回答前检索层，到行动前上下文层。

二、Agent时代，RAG的服务对象变了

过去RAG服务的是“答案生成”。

现在RAG要服务的是“任务执行”。

这句话看起来像概念，但放到业务现场里，差别非常大。

在问答场景里，用户问：“退款规则是什么？”系统检索退款文档，模型总结规则，给出引用。这条链路的目标是回答清楚。

但在Agent场景里，用户可能说：“帮我处理这个退款工单。”

这就不是一个答案生成问题了。

Agent需要理解目标，读取订单状态，判断客户类型，查看历史沟通，调用CRM或工单系统，检查权限，生成处理方案，必要时触发审批，最后还要记录结果。

同样是“退款”，一个是问规则，一个是办事情。

问规则时，RAG找到文档就已经很有价值。

办事情时，RAG只找到文档就远远不够。

因为真实业务从来不是按FAQ的格式运行。

• 客服真正想知道的不是“退款规则在哪里”，而是：“这个客户已经催了三次，还在投诉升级，我现在还能不能按标准话术回复？”
• 销售真正想知道的不是“折扣政策是什么”，而是：“这个客户去年有过历史承诺，又赶在季度末签约，这个口径能不能给？”
• 研发真正想知道的不是“这个模块说明是什么”，而是：“这段代码看起来没人调用，能不能删，会不会影响另一个灰度流程？”

这些问题难在哪里？

不难在找文档。

难在要把规则、状态、权限、历史经验和风险边界一起放进当前任务里。

所以，RAG如果还只回答“相关资料是什么”，就不够了。

它必须回答更具体的问题：

在当前任务、当前用户、当前状态、当前权限下，Agent应该看到什么、相信什么、禁止什么、执行什么、回流什么？

这句话是Agent时代重新理解RAG的关键。

过去的RAG更像Retrieval for Answer。

未来的RAG会走向Context for Action。

这个转变不是把搜索做得更复杂，而是把上下文从“生成材料”升级为“行动条件”。

• 一个销售Agent在生成报价前，不只需要产品手册，还需要客户等级、历史承诺、折扣权限、合规边界、审批状态、过往失败案例。
• 一个客服Agent在回复投诉前，不只需要标准话术，还需要客户情绪、投诉次数、SLA状态、是否升级过、哪些承诺不能说、哪些场景必须转人工。
• 一个研发Agent在修改代码前，不只需要代码片段，还需要架构约束、灰度策略、测试覆盖、上线窗口、历史事故、团队约定。

所以Agent时代的RAG，不再只是“帮模型找资料”。

它要帮助Agent在行动前建立一个可用的业务现场。

说得再直白一点：

过去RAG让模型像一个读过资料的新同事。

未来的Context OS，要让Agent像一个知道现场、懂边界、会留痕、能复盘的业务助手。

Agent时代的上下文需求：知识、状态、约束、权限、记忆、反馈。

三、从RAG到Context OS：企业AI需要的不是知识库，而是上下文运行层

我把这种能力叫做Context OS。

Context OS，不是一个具体技术组件，也不是又一个需要采购的新名词。

它是一套企业AI的上下文组织能力。

它负责把企业里的文档、数据、状态、权限、流程、经验、风险和反馈，组织成 AI 在回答和行动前都可以调用的上下文资产。

这里最容易误解的是OS这个词。

它不是说企业要再买一个“上下文操作系统”。

它强调的是运行时能力。

知识库关心的是资料放在哪里。

RAG关心的是资料怎么被检索出来。

Context OS关心的是：什么上下文，在什么任务里，以什么权限，被谁调用，用来支撑什么判断，最后如何被校验和回流。

这就不只是“检索”了。

它更像Agent Runtime里的上下文调度层。

过去RAG是“回答前的检索层”。

现在RAG要成为“行动前的上下文层”。

对产品经理来说，可以把Context OS拆成一个结构：

Context OS=知识层+状态层+约束层+权限层+记忆层+反馈层

这不是为了凑一个好看的公式。

而是因为企业AI一旦进入行动场景，缺任何一层都会出问题。

• 知识层，管理文档、制度、FAQ、产品手册、知识库、接口说明。它回答“标准信息是什么”。比如退款制度、合同模板、接口字段说明。
• 状态层，管理客户状态、订单状态、项目状态、流程状态、系统字段。它回答“当前业务运行到哪一步”。同一条规则，在未发货、已发货、已开票、已投诉升级这些状态下，处理方式可能完全不同。
• 约束层，管理业务规则、合规边界、不可承诺事项、必须人工确认的场景。它回答“哪些事能做，哪些事不能做”。很多企业不是怕AI不会答，而是怕它答得太自信，把不该承诺的事说出去了。
• 权限层，管理谁能看、谁能用、哪些内容只能用于内部判断不能外显。它回答“这份上下文对当前用户和当前Agent是否可用”。比如内部风控标签可以影响判断，但不能直接写给客户看。
• 记忆层，管理历史交互、专家经验、老员工know-how、过往案例、事故复盘。它回答“组织过去在类似场景里学到了什么”。这部分最难沉淀，也最值钱。很多时候真正决定答案质量的，不是制度，而是老员工踩过坑之后留下的判断。
• 反馈层，管理用户采纳、人工改写、bad case归因、结果回流、版本迭代。它回答“系统错了以后如何变得更可靠”。没有反馈层，系统只是一次次重新犯错。

这六层合在一起，才是企业AI真正需要的上下文结构。

原来我们说“业务上下文地图”，更多是在强调RAG不应该只读文档。到了Agent时代，这张地图要继续升级，变成Context OS的组成结构。

因为Agent不只要回答，它还会计划、调用、执行、校验、交接和复盘。

生产级Context OS不是堆更多上下文，而是让上下文在正确任务、正确角色、正确状态、正确权限下被动态调用和持续回流。

企业AI的竞争，不是谁能塞进更多上下文，而是谁能在正确时刻调用正确上下文。

这也是为什么我不太愿意把Context OS写成一个特别玄的概念。

它其实很朴素。

就是把过去散落在文档、系统、聊天、审批、复盘和老员工脑子里的东西，变成Agent可以读取、判断、约束和复盘的运行资源。

四、为什么只做Agentic RAG还不够

现在很多生产级RAG已经引入Agentic Retrieval。

模型不再只是被动拿Top-K结果，而是可以主动搜索、拆解问题、打开文档、在文档内定位、比较证据、追问缺口，再总结答案。

这当然比传统RAG强很多。

尤其在复杂研究、代码理解、法律条款分析、企业知识检索里，Agentic RAG能显著提升系统处理复杂问题的能力。

它让RAG从“你给我问题，我给你几段结果”，变成“我先想想该查什么，再一步步补证据”。

这个变化很重要。

但我们也要把边界说清楚。

Agentic RAG主要解决的是“如何更主动地找到和分析信息”。

它不天然解决企业级上下文治理问题。

比如：

• 权限是否正确？
• 状态是否实时？
• 约束是否可执行？
• 证据是否能审计？
• 风险是否可控？
• 错误是否能回流？

一个Agent很会搜索，不代表它知道哪些内容不能对外说。

它很会打开文档，不代表它知道当前订单状态已经变化。

它很会总结证据，不代表这条证据适用于当前角色、当前地区、当前客户等级。

更关键的是，Agent越会探索，越需要边界。

以前的RAG是在一条固定管道里找材料，虽然薄，但边界相对清楚。

Agentic RAG让模型自己规划检索路径，这当然更聪明，但也意味着它更可能碰到权限、时效、冲突和风险问题。

它能找到更多东西。

但找到更多，不等于用得更对。

这就是Agentic RAG和Context OS的区别。

Agentic RAG是检索形态的进化，Context OS是系统角色的进化。

前者让RAG更主动。

后者让上下文变成企业AI可以调度、约束、审计和回流的运行资源。

如果说Agentic RAG解决的是“怎么找到更多、更准的信息”，Context OS解决的就是“这些信息如何在企业系统里被正确使用”。

Agentic RAG与Context OS的区别：前者是检索形态进化，后者是系统角色进化。

五、RAG的竞争正在从召回率转向上下文调度能力

过去评估RAG，我们很自然会看召回率、准确率、引用质量、幻觉率。

这些指标仍然重要。

一个连相关证据都找不到的系统，谈不上生产级。一个引用不稳定、证据不可信、回答经常跑偏的系统，也不可能支撑业务。

但在Agent时代，只看这些还不够。

因为Agent的失败，不一定发生在“没搜到资料”。

更多时候，它失败在上下文调度错了。

• 该读取实时状态时，它只看了静态文档。
• 该按权限过滤时，它把内部判断依据直接外显。
• 该触发人工确认时，它自己给了承诺。
• 该把人工改写回流为约束时，它只把这次对话存进日志。

这些问题都很具体。

也都很要命。

你可能召回率很高，答案引用也很漂亮，但Agent还是不敢让业务人员放心使用。

因为业务人员真正关心的不是“你找到了几段材料”。

他关心的是：“你为什么在这个场景下这样判断？你有没有看当前状态？你有没有越权？你错了以后我去哪儿改？”

所以产品经理要开始用另一套问题评估RAG：

• 上下文是否按任务动态装配？
• 是否能根据角色和权限过滤？
• 是否能根据业务状态更新？
• 是否能区分“可引用信息”和“仅供内部判断信息”？
• 是否能将错误答案回流成新的约束或知识？
• 是否能在多Agent、多工具协作中保持上下文一致性？

这不是技术教程，而是产品设计视角的转向。

过去我们问：“这个问题召回了哪些文档？”

现在还要问：“这个任务为什么装配了这组上下文？”

过去我们问：“答案引用是否正确？”

现在还要问：“这个引用是否对当前用户可见，是否对当前状态适用，是否足以支撑当前动作？”

过去我们问：“模型有没有幻觉？”

现在还要问：“如果Agent准备执行动作，系统有没有足够的上下文边界阻止它越权？”

RAG的下一阶段，不是更强检索，而是更强上下文调度。

上下文调度能力，会成为企业AI从“能答”走向“敢用”的关键差异。

这句话可以再说重一点：

检索决定AI能不能找到信息。

上下文调度决定AI能不能把信息用在正确地方。

六、产品经理真正要设计的，不是RAG功能，而是上下文生命周期

如果只把RAG当功能，产品经理很容易陷入功能清单：

• 要不要向量库？
• 要不要rerank？
• 要不要GraphRAG？
• 要不要Agentic Retrieval？
• 要不要接MCP？

这些问题都重要，但它们不是第一层问题。

第一层问题应该是：企业上下文如何从现实业务进入系统，又如何在AI使用后持续更新？

也就是上下文生命周期。

上下文生命周期=采集→结构化→索引→路由→注入→校验→观测→回流

这一节，是产品经理真正要抓住的部分。

第一步，采集。

上下文不只来自文档。它还来自业务系统、工单、聊天记录、会议纪要、事故复盘、专家访谈、人工改写、审批记录。采集的目标不是把所有内容都吞进去，而是找到那些反复影响判断、反复导致升级、反复改变处理结果的信息。

这一阶段的产物，不应该只是“资料库列表”，而应该是一张上下文来源清单：哪些来源提供规则，哪些来源提供状态，哪些来源提供经验，哪些来源提供风险，哪些来源提供反馈。

第二步，结构化。

一条经验如果只是自然语言，很难稳定进入Agent工作流。它需要被补充来源、适用范围、时效、权限、风险等级、责任人、触发条件、失效条件。结构化不是为了好看，而是为了让系统知道这条上下文什么时候能用、谁能用、用错了谁负责。

这一阶段的产物，是上下文卡片。

比如一条客服经验不能只写成“客户催三次就要重视”。它应该被拆成：来源是投诉复盘，适用范围是高价值客户，触发条件是连续催促三次且出现负面情绪，处理策略是先安抚再解释规则，风险边界是不得承诺必退，反馈机制是人工是否采纳、客户是否继续投诉。

第三步，索引。

索引不只是一种向量索引。不同上下文需要不同入口：向量索引用来处理语义相似，关键词索引用来处理精确术语，图谱索引用来处理关系推理，业务标签索引用来处理场景、角色、状态和流程。

索引的目标不是“全都能搜到”，而是让上下文能被正确路由。

如果一条规则只能在华东区使用，它就不能只靠语义相似被召回。

如果一条话术只能给内部客服看，它就不能只因为“相关”而进入最终回答。

第四步，路由。

路由决定某个任务应该调用哪些上下文。一个投诉处理任务，应该优先拿客户状态、投诉历史、SLA、风险话术和升级规则。一个代码修改任务，应该优先拿架构约束、依赖关系、测试策略和发布窗口。

上下文路由做不好，长上下文也只是把更多噪声塞进模型。

这一阶段的产物，可以是一张任务-上下文矩阵：每类任务需要哪些必选上下文，缺少哪些上下文就不能继续自动执行。

第五步，注入。

注入不是把检索结果粗暴贴进Prompt。它要决定粒度、顺序、形式和可见性。

哪些内容作为证据给模型引用，哪些内容作为内部策略影响判断，哪些内容只作为工具调用参数，哪些内容必须隐藏在最终回答之外，这些都需要产品和工程一起设计。

这一步做不好，就会出现一个很常见的问题：系统知道了内部判断，但把内部判断原样说给了用户。

这不是“回答不自然”。

这是权限和表达边界出问题。

第六步，校验。

校验要判断证据是否充分、状态是否匹配、动作是否越权。对于高风险场景，还要判断是否触发人工确认，是否需要二次检索，是否需要降级为建议而不是自动执行。

Agent越能行动，校验就越重要。

一个知识库答错了，最多让人不满意。

一个Agent做错了，可能会触发流程、影响客户、制造合规风险。

第七步，观测。

观测不是只看调用次数和满意度。它要记录模型使用了什么上下文、为什么这么判断、调用了哪些工具、在哪个环节失败、是否被人工改写、是否触发了权限或风险拦截。

没有观测，就没有复盘。

没有复盘，所谓“持续优化”就是一句空话。

第八步，回流。

回流决定系统会不会成长。人工修正、用户反馈、bad case归因、投诉结果、审批驳回原因，都应该回写到知识层、约束层、权限层或评测集中。否则系统每次都像第一次遇到问题。

这套生命周期，比“做一个RAG功能”更接近企业AI的真实工作。

因为企业AI的难点，不是把上下文拿进来一次。

而是让上下文持续被采集、被治理、被调度、被校验、被观测、被修正。

产品经理真正要设计的，不是一个检索框，而是一套上下文运行机制。

Context OS结构：采集、结构化、索引、路由、注入、校验、观测、回流。

七、MCP、长上下文、Skills、Memory、GraphRAG都在把RAG推向Context OS

再看这两年的技术趋势，会发现它们并不是在消灭RAG。

它们是在把RAG拆解，并融入Agent Runtime。

长上下文解决的是容量问题。

它让系统一次能带更多材料，但不判断哪些材料可信、过期、越权或者不适用。容量变大，不等于判断变准。

MCP解决的是连接问题。

它让模型更容易接入文件、数据库、工具和业务系统。但连接之后，数据如何治理、证据如何判断、权限如何隔离，仍然要产品和系统来设计。

Skills解决的是能力封装和工作流复用问题。

它让Agent可以在特定任务里加载一组更稳定的流程、资源和操作方式。但Skill也需要正确上下文触发和加载。能力本身不是问题，问题是它什么时候该被调用、带着什么上下文调用、调用后有没有边界。

Memory解决的是跨轮次和跨任务的持续性问题。

Agent需要记住用户偏好、历史决策、项目进展、长期约束。但记忆不是越多越好。它需要写入规则、检索规则、过期机制、权限治理和冲突处理。没有治理的记忆，很快会变成新的噪声源。

GraphRAG和Knowledge Graph解决的是关系组织问题。

它们能把文档里的实体、关系、主题、社区结构组织起来，让系统不只按片段相似度找材料。但图谱也需要和状态、权限、反馈结合。否则图谱知道“谁和谁有关”，但未必知道“当前是否能用这条关系做判断”。

Agentic RAG解决的是主动探索问题。

它让模型可以自己规划检索路径、补证据、查缺口。但探索越主动，越需要上下文边界、证据校验、行动约束和观测追踪。

这些技术的共同方向，不是让RAG消失。

而是让“检索”变成Agent Runtime里的一部分，让“上下文”变成运行时资源。

OpenAI Agents SDK、Responses API、各类MCP生态、Claude Skills、GraphRAG工具链，都在指向同一个趋势：Agent系统不只是模型加工具，而是模型、工具、状态、权限、记忆、观测、评测共同组成的运行环境。

所以这些技术不是RAG的讣告。

它们更像一组提醒：

• 只会搜索的RAG太窄了。
• 只会读文档的知识库太薄了。

Agent时代真正需要的是一套上下文运行层。

RAG在这个环境里不会只剩一个搜索模块。

它会变成Context OS的一部分。

MCP、Skills、Memory、GraphRAG、Agentic RAG如何共同把RAG推向Agent Runtime。

八、RAG也许不再叫RAG，但它会成为Agent Runtime的一部分

RAG也许不会一直以原来的名字存在。

它可能会被拆进Agent Runtime、Memory、MCP、Skills、Graph、Context Engineering这些系统模块里，成为企业AI架构中的上下文能力。

但它背后的核心问题不会消失：

AI在回答和行动之前，必须获得真实、可信、可验证、可约束、可回流的上下文。

过去，RAG解决的是“模型不知道，所以要检索”。

未来，Context OS解决的是“AI要行动，所以必须知道什么能信、什么能做、什么不能越界、错了如何修正”。

所以，今天重新讨论RAG，真正重要的不是证明它有没有死，也不是继续批判低配RAG，而是看清它的系统角色正在变化：

它正在从问答前的检索能力，升级为行动前的运行能力。

到那时，RAG可能不再叫RAG。

但它会成为企业AI的记忆系统、约束系统、权限系统、反馈系统和上下文调度系统。

也就是Agent Runtime的一部分。

RAG解决的是“模型别乱说”。

Context OS解决的是“Agent别乱做”。

这两件事之间，就是企业AI从问答走向行动时，必须跨过去的那道门槛。