从知识补丁到上下文操作系统——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的价值非常明确：模型不知道，或者模型记错了，就从外部知识里找证据，再把证据放进上下文，让模型基于证据生成答案。
这件事在问答型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角色迁移：从回答前检索层，到行动前上下文层。
过去RAG服务的是“答案生成”。
现在RAG要服务的是“任务执行”。
这句话看起来像概念，但放到业务现场里，差别非常大。
在问答场景里，用户问：“退款规则是什么？”系统检索退款文档，模型总结规则，给出引用。这条链路的目标是回答清楚。
但在Agent场景里，用户可能说：“帮我处理这个退款工单。”
这就不是一个答案生成问题了。
Agent需要理解目标，读取订单状态，判断客户类型，查看历史沟通，调用CRM或工单系统，检查权限，生成处理方案，必要时触发审批，最后还要记录结果。
同样是“退款”，一个是问规则，一个是办事情。
问规则时，RAG找到文档就已经很有价值。
办事情时，RAG只找到文档就远远不够。
因为真实业务从来不是按FAQ的格式运行。
这些问题难在哪里？
不难在找文档。
难在要把规则、状态、权限、历史经验和风险边界一起放进当前任务里。
所以，RAG如果还只回答“相关资料是什么”，就不够了。
它必须回答更具体的问题：
在当前任务、当前用户、当前状态、当前权限下，Agent应该看到什么、相信什么、禁止什么、执行什么、回流什么？
这句话是Agent时代重新理解RAG的关键。
过去的RAG更像Retrieval for Answer。
未来的RAG会走向Context for Action。
这个转变不是把搜索做得更复杂，而是把上下文从“生成材料”升级为“行动条件”。
所以Agent时代的RAG，不再只是“帮模型找资料”。
它要帮助Agent在行动前建立一个可用的业务现场。
说得再直白一点：
过去RAG让模型像一个读过资料的新同事。
未来的Context OS，要让Agent像一个知道现场、懂边界、会留痕、能复盘的业务助手。
Agent时代的上下文需求：知识、状态、约束、权限、记忆、反馈。
我把这种能力叫做Context OS。
Context OS，不是一个具体技术组件，也不是又一个需要采购的新名词。
它是一套企业AI的上下文组织能力。
它负责把企业里的文档、数据、状态、权限、流程、经验、风险和反馈，组织成 AI 在回答和行动前都可以调用的上下文资产。
这里最容易误解的是OS这个词。
它不是说企业要再买一个“上下文操作系统”。
它强调的是运行时能力。
知识库关心的是资料放在哪里。
RAG关心的是资料怎么被检索出来。
Context OS关心的是：什么上下文，在什么任务里，以什么权限，被谁调用，用来支撑什么判断，最后如何被校验和回流。
这就不只是“检索”了。
它更像Agent Runtime里的上下文调度层。
过去RAG是“回答前的检索层”。
现在RAG要成为“行动前的上下文层”。
对产品经理来说，可以把Context OS拆成一个结构：
Context OS=知识层+状态层+约束层+权限层+记忆层+反馈层
这不是为了凑一个好看的公式。
而是因为企业AI一旦进入行动场景，缺任何一层都会出问题。
这六层合在一起，才是企业AI真正需要的上下文结构。
原来我们说“业务上下文地图”，更多是在强调RAG不应该只读文档。到了Agent时代，这张地图要继续升级，变成Context OS的组成结构。
因为Agent不只要回答，它还会计划、调用、执行、校验、交接和复盘。
生产级Context OS不是堆更多上下文，而是让上下文在正确任务、正确角色、正确状态、正确权限下被动态调用和持续回流。
企业AI的竞争，不是谁能塞进更多上下文，而是谁能在正确时刻调用正确上下文。
这也是为什么我不太愿意把Context OS写成一个特别玄的概念。
它其实很朴素。
就是把过去散落在文档、系统、聊天、审批、复盘和老员工脑子里的东西，变成Agent可以读取、判断、约束和复盘的运行资源。
现在很多生产级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，我们很自然会看召回率、准确率、引用质量、幻觉率。
这些指标仍然重要。
一个连相关证据都找不到的系统，谈不上生产级。一个引用不稳定、证据不可信、回答经常跑偏的系统，也不可能支撑业务。
但在Agent时代，只看这些还不够。
因为Agent的失败，不一定发生在“没搜到资料”。
更多时候，它失败在上下文调度错了。
这些问题都很具体。
也都很要命。
你可能召回率很高，答案引用也很漂亮，但Agent还是不敢让业务人员放心使用。
因为业务人员真正关心的不是“你找到了几段材料”。
他关心的是：“你为什么在这个场景下这样判断？你有没有看当前状态？你有没有越权？你错了以后我去哪儿改？”
所以产品经理要开始用另一套问题评估RAG：
这不是技术教程，而是产品设计视角的转向。
过去我们问：“这个问题召回了哪些文档？”
现在还要问：“这个任务为什么装配了这组上下文？”
过去我们问：“答案引用是否正确？”
现在还要问：“这个引用是否对当前用户可见，是否对当前状态适用，是否足以支撑当前动作？”
过去我们问：“模型有没有幻觉？”
现在还要问：“如果Agent准备执行动作，系统有没有足够的上下文边界阻止它越权？”
RAG的下一阶段，不是更强检索，而是更强上下文调度。
上下文调度能力，会成为企业AI从“能答”走向“敢用”的关键差异。
这句话可以再说重一点：
检索决定AI能不能找到信息。
上下文调度决定AI能不能把信息用在正确地方。
如果只把RAG当功能，产品经理很容易陷入功能清单：
这些问题都重要，但它们不是第一层问题。
第一层问题应该是：企业上下文如何从现实业务进入系统，又如何在AI使用后持续更新？
也就是上下文生命周期。
上下文生命周期=采集→结构化→索引→路由→注入→校验→观测→回流
这一节，是产品经理真正要抓住的部分。
第一步，采集。
上下文不只来自文档。它还来自业务系统、工单、聊天记录、会议纪要、事故复盘、专家访谈、人工改写、审批记录。采集的目标不是把所有内容都吞进去，而是找到那些反复影响判断、反复导致升级、反复改变处理结果的信息。
这一阶段的产物，不应该只是“资料库列表”，而应该是一张上下文来源清单：哪些来源提供规则，哪些来源提供状态，哪些来源提供经验，哪些来源提供风险，哪些来源提供反馈。
第二步，结构化。
一条经验如果只是自然语言，很难稳定进入Agent工作流。它需要被补充来源、适用范围、时效、权限、风险等级、责任人、触发条件、失效条件。结构化不是为了好看，而是为了让系统知道这条上下文什么时候能用、谁能用、用错了谁负责。
这一阶段的产物，是上下文卡片。
比如一条客服经验不能只写成“客户催三次就要重视”。它应该被拆成：来源是投诉复盘，适用范围是高价值客户，触发条件是连续催促三次且出现负面情绪，处理策略是先安抚再解释规则，风险边界是不得承诺必退，反馈机制是人工是否采纳、客户是否继续投诉。
第三步，索引。
索引不只是一种向量索引。不同上下文需要不同入口：向量索引用来处理语义相似，关键词索引用来处理精确术语，图谱索引用来处理关系推理，业务标签索引用来处理场景、角色、状态和流程。
索引的目标不是“全都能搜到”，而是让上下文能被正确路由。
如果一条规则只能在华东区使用，它就不能只靠语义相似被召回。
如果一条话术只能给内部客服看，它就不能只因为“相关”而进入最终回答。
第四步，路由。
路由决定某个任务应该调用哪些上下文。一个投诉处理任务，应该优先拿客户状态、投诉历史、SLA、风险话术和升级规则。一个代码修改任务，应该优先拿架构约束、依赖关系、测试策略和发布窗口。
上下文路由做不好，长上下文也只是把更多噪声塞进模型。
这一阶段的产物，可以是一张任务-上下文矩阵：每类任务需要哪些必选上下文，缺少哪些上下文就不能继续自动执行。
第五步，注入。
注入不是把检索结果粗暴贴进Prompt。它要决定粒度、顺序、形式和可见性。
哪些内容作为证据给模型引用，哪些内容作为内部策略影响判断，哪些内容只作为工具调用参数，哪些内容必须隐藏在最终回答之外，这些都需要产品和工程一起设计。
这一步做不好，就会出现一个很常见的问题：系统知道了内部判断，但把内部判断原样说给了用户。
这不是“回答不自然”。
这是权限和表达边界出问题。
第六步，校验。
校验要判断证据是否充分、状态是否匹配、动作是否越权。对于高风险场景，还要判断是否触发人工确认，是否需要二次检索，是否需要降级为建议而不是自动执行。
Agent越能行动，校验就越重要。
一个知识库答错了，最多让人不满意。
一个Agent做错了，可能会触发流程、影响客户、制造合规风险。
第七步，观测。
观测不是只看调用次数和满意度。它要记录模型使用了什么上下文、为什么这么判断、调用了哪些工具、在哪个环节失败、是否被人工改写、是否触发了权限或风险拦截。
没有观测，就没有复盘。
没有复盘，所谓“持续优化”就是一句空话。
第八步，回流。
回流决定系统会不会成长。人工修正、用户反馈、bad case归因、投诉结果、审批驳回原因，都应该回写到知识层、约束层、权限层或评测集中。否则系统每次都像第一次遇到问题。
这套生命周期，比“做一个RAG功能”更接近企业AI的真实工作。
因为企业AI的难点，不是把上下文拿进来一次。
而是让上下文持续被采集、被治理、被调度、被校验、被观测、被修正。
产品经理真正要设计的，不是一个检索框，而是一套上下文运行机制。
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的讣告。
它们更像一组提醒：
Agent时代真正需要的是一套上下文运行层。
RAG在这个环境里不会只剩一个搜索模块。
它会变成Context OS的一部分。
MCP、Skills、Memory、GraphRAG、Agentic 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从问答走向行动时，必须跨过去的那道门槛。
本文由人人都是产品经理作者【诗说红豆】，微信公众号：【诗说红豆】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。