开发智能体时很多团队会从一个很自然的想法开始Agent 要懂业务先给它接一个 RAG。这个想法没错但很容易用错。因为 Agent 需要的上下文不全是知识。用户问帮我看看这个客户为什么审批没通过。这句话背后可能需要审批制度和风控规则、当前客户资料、最近一次审批记录、当前用户的查看权限、这个任务前面已经查到哪一步、用户之前的偏好约束、工具调用是不是临时失败。这些不能都叫 RAG。审批制度和风控规则适合走 RAG。当前客户资料应该走业务系统工具。任务前面查到哪一步属于 Task State。用户之前的偏好和约束属于 Memory。权限判断属于 Policy。工具错误和执行记录属于 Trace / Tool Result。如果你把它们都塞进一个向量库再让模型自己判断就会出现一类很常见的问题该查工具的时候去查文档该读状态的时候去搜知识库该问权限的时候直接回答该用当前事实的时候召回了旧内容。所以为什么有的智能体需要 RAG有的不需要这个问题本质上是一个 Agent Runtime 设计题当前这类任务需要的上下文到底属于 Knowledge、State、Memory、Tool / Environment、Policy还是 TraceRAG 只覆盖其中一类Knowledge Retrieval。它不负责保存任务状态、不负责读取真实现场、不负责执行工具、不负责权限判断、不负责把工具结果变成可审计 trace。这篇就从开发的角度重新拆这个问题并用 Cursor 和 Claude Code 作为两条对照路线看看它们分别把上下文从哪里来这件事做成了什么形态、为什么那样做。一、先把 RAG 的职责缩小RAG 被说得太泛了。只要模型外面接了点资料很多人就叫 RAG。在工程上最好把它缩小成一个更清楚的定义RAG 是一种基于外部知识源的检索增强生成先从某个可检索的知识空间里找候选证据再把证据放进模型上下文让模型基于证据回答或行动。关键词是外部知识源、可检索、候选证据、进入模型上下文、支撑回答或行动。注意它不是只指向量库。向量检索只是其中一种实现方式关键词检索、符号索引、结构化过滤、图谱检索都可以是 RAG 的一部分。更重要的是不要把所有上下文都塞进 RAG。很多信息根本不是知识它们是状态、现场、权限或执行记录。信息应该去哪为什么公司的报销制度Knowledge Store / RAG稳定文档适合检索引用当前报销单审批到哪一步Task State / Tool实时状态不该靠向量召回用户说以后默认看华东区Memory长期偏好不是外部知识当前库存数量Tool / Database实时事实需要查系统用户有没有退款权限Policy权限判断不能交给语义检索上一次工具调用失败原因Trace / Tool Result调试和回放信息不一定进上下文这张表比要不要 RAG重要。因为很多 Agent 出错不是缺 RAG而是把不同类型的信息放错了地方把当前审批状态写进向量库下一次很可能召回旧状态。把工具错误日志当知识喂给模型模型可能把临时失败当成业务规则。把用户长期偏好和本次任务约束混在一起下一次任务就会被污染。开发 Agent 时第一步不是接 RAG而是做 placement先判断信息属于哪一层再决定要不要检索。二、RAG / Memory / State / Tool 怎么区分这几个最容易搞混。它们都像历史信息但生命周期完全不一样。类型解决什么问题典型例子读取方式Knowledge / RAG外部知识怎么找回来制度、文档、代码规范、API 手册检索 过滤 引用State当前任务做到哪一步目标、计划、已完成步骤、当前阻塞按 task_id 读取Memory长期偏好和历史决策用户偏好、项目背景、长期约束按 user_id / project_id 召回Tool / Env当前真实世界是什么状态订单、库存、文件、代码、测试结果工具调用 / API / DBPolicy能不能做、风险多大权限、审批、合规、工具准入规则 权限系统Trace刚才发生了什么工具调用、错误、上下文快照run_id / step_id 回放如果你把它们都做成 RAG会有几个后果状态会过期、记忆会污染、工具现场会被静态化、trace 会干扰模型。所以真正要设计的是what goes where不是everything goes to vector db。三、什么 Agent 需要 RAG什么 Agent 不需要可以用两个简单画像直接判断。必须有 RAG 的任务依赖大量稳定的外部知识典型场景企业知识库问答、法务合同审查、售前方案、API 文档助手、研发规范助手、客服制度解释。它们的问题通常长这样这个客户的场景应该适用哪套报价规则我们接口的鉴权方式在 v2 里有什么变化这个需求是否违反现有产品边界这些问题不是模型凭常识能答的也不是查一个字段就能解决的必须从一堆文档里找依据。RAG 在这里承担的是召回依据、限定回答范围、提供引用来源、降低幻觉、让结果可追溯。没有它这类 Agent 会变成模型凭训练知识和 prompt 猜业务规则生产里不可接受。不需要 RAG 的任务依赖当前状态和工具执行典型场景订会议室、查订单、报销审批、数据看板、运维操作、日程安排、本地文件整理。帮我查一下客户 A 最近三个月的订单异常。这不是知识问答它需要的是工具调用 状态查询查客户、查订单、查退款、查发货、计算异常指标。如果你给这类 Agent 先接知识库最多能查到公司会议室使用规范。但真正要完成任务靠的是工具和状态。这类 Agent 的主路径是识别任务 - 检查权限 - 读取系统状态 - 执行工具 - 处理失败 - 写回结果 - 记录 traceRAG 可以作为辅助解释规则、查操作手册但不是主路径。四、Cursor 和 Claude Code两条典型路线到了 Coding Agent这个问题就更清楚了。很多人误以为Cursor 用了 RAGClaude Code 没用。更准确的说法是**它们都需要上下文只是把上下文获取的主路径放在了不同位置。**Cursor 把上下文成本前置到索引Claude Code 把上下文成本放在执行时现场发现。Cursor把上下文成本前置Cursor 常驻在 IDE 里服务的是高频、低延迟的代码库问答和补全。如果每次都让 Agent 现场搜索延迟无法接受且第一次 query 通常不准。所以它选择预建索引workspace 打开时解析文件、提取 chunk 和符号、构建关键词 / 向量 / 符号三类索引查询时快速召回候选最后读真实文件确认——因为索引可能落后于未保存 buffer 或刚切换的分支。预建索引解决四类问题跨文件低延迟召回、相似实现的语义匹配风格相似不等于关键词相同、大仓库搜索空间控制、多信号排序路径、邻近度、最近修改、符号引用、语义相似混合。核心不是接了向量库而是多信号索引 实时文件确认 上下文组装。只做向量库会很不稳。Claude Code把上下文成本放在执行循环Claude Code 按需启动典型入口是修复这个测试失败“实现这个接口”。它没有常驻后台也不需要代码任务可以运行执行结果本身就是最强的纠偏信号。它的上下文不是一次召回的而是在执行循环里逐步发现的搜索 → 读文件 → 形成假设 → 修改 → 跑测试 → 读报错 → 再搜索。这是另一种检索——工具驱动的实时检索。这样做的工程理由现场天然新鲜直接读当前文件和 diff不受索引延迟影响对修 bug、处理脏工作区尤其重要。执行结果是纠偏信号不一定要在第一步召回完美上下文测试、lint、类型检查都会告诉你猜错在哪。证据链清楚能说出读了 A、搜了 B、跑了 C、失败在 D 行比召回了一批相似片段对工程任务更可靠。没有常驻后台按需启动的会话无法假设有进程在维护索引也不需要单独治理哪些文件能进索引。对比维度Cursor预建索引式Claude Code实时工具发现典型入口IDE 助手、代码库问答、补全终端任务、自动修复、按需会话上下文来源向量 / 符号 / 路径索引 元数据文件系统、grep、git diff、测试输出成本支付提前索引查询时低延迟查询时现场搜索执行中逐步发现新鲜度取决于索引更新策略天然新鲜优势快、适合大仓库、相似召回、自然语言问答可执行验证、契合当前工作区状态风险索引过期、召回错片段、权限治理复杂路径慢、可能漏全局语义最适合“项目里有没有类似实现”“这个概念在哪”“修这个 bug”“跑测试改到通过”不适合高频依赖未保存 / 未提交状态的修复大仓库开放式语义探索**Cursor 像仓库地图Claude Code 像现场勘查。**地图很好但会过期。勘查很准但每次都走一遍会慢。真正成熟的架构不应该二选一而是用 Context Router 按任务分发代码库问答 / 相似实现搜索 - code indexCursor 思路bugfix / review / 测试修复 - live toolsClaude Code 思路规范解释 / 需求约束 - docs retrieval用户偏好 / 项目决策 - memory五、如果决定做 Coding RAG不要只做向量库如果你决定给 Coding Agent 加 RAG最容易踩的坑是只做一层向量检索。代码库检索至少要有四类信号信号适合解决什么问题例子路径信号模块边界、语言、目录归属apps/web/src/routes/settings关键词信号精确名称、错误码、API、配置项createSession、E_AUTH_EXPIRED符号信号定义、引用、调用链、类型关系function、class、interface、import语义信号相似实现、自然语言概念、风格迁移“导出功能”“审批流”“客户画像”纯向量检索最容易漏精确性。函数名、错误码、配置项、测试名这些东西语义不重要字符串本身最重要。所以更合理的是混合检索query - 路径过滤 - 关键词检索 - 符号 / 引用分析 - 语义召回 - rerank - 读完整文件或关键范围 - Context Builder 组装还有一个很容易忽略的点召回 chunk 不是最终上下文。代码任务经常需要读完整函数、完整类、完整文件甚至相邻测试文件。只把几个 chunk 塞给模型它可能看不到 import、类型定义、边界条件和副作用。所以 Coding RAG 的 Context Builder 至少要扩展到函数 / 类边界、补齐 import 和类型定义、补齐相邻测试、标注文件路径和行号、标注证据来源、控制重复和过期片段。六、Context Router先决定上下文类型Agent 的 Router 不应该只判断是否需要 RAG它应该输出一个具体的上下文计划ContextPlan( task_typecustomer_order_analysis, primary_context_pathtools, needs{ knowledge: False, state: True, memory: False, tools: [customer_api, order_api, refund_api], policy: True, }, required_evidence[customer_profile, recent_orders, refund_records], freshnessrealtime,)如果用户问的是这个审批规则在什么情况下可以跳过主管ContextPlan( task_typepolicy_explanation, primary_context_pathknowledge_retrieval, needs{knowledge: True, state: False, memory: False, tools: [], policy: False}, required_evidence[policy_doc, effective_version, source_quote], freshnessversioned_knowledge,)两个计划里的freshness完全不同realtimevsversioned_knowledge。实时业务状态应该从工具读制度文档应该从版本化知识库检索代码索引召回后最好再读真实文件确认。Agent Runtime 比普通 RAG 问答更复杂的地方在于它不仅要找相关还要判断这类信息是否应该从 RAG 来。七、长上下文也消灭不了这个问题有人会说现在窗口越来越大直接全塞进去不就行了不行。长上下文解决的是放得下没有解决该放什么。放得越多干扰越多。模型看到十段相似资料不一定更准它可能混合不同版本、业务线、权限范围的信息。放得越多责任越不清楚。出错以后你很难知道是召回错、排序错、模型忽略证据、工具没查、索引过期、状态没读还是权限没判断。放得越多成本和延迟越不可控。Agent 经常多轮执行每轮上下文都很重工具循环里成本和延迟会崩。长上下文只是给 Context Builder 更多预算。Router 仍然要判断该拿什么Builder 仍然要负责取舍Trace 仍然要记录证据链。八、落地顺序如果你正在做一个自己的 Agent建议按这个顺序来。第一步先做信息分层。把 Agent 需要的信息按 Knowledge / State / Memory / Tool / Policy / Trace 分清楚画出what goes where。这一步不要急着向量化所有资料。第二步加 Context Router。不要所有任务走同一条链路。至少分出知识问答、业务查询、高风险操作、长任务执行、个人偏好相关、文档 工具混合、需要澄清的问题。第三步先把工具和状态做稳。很多 Agent 不稳不是缺 RAG而是工具和状态不稳。先保证工具返回结构化、工具失败能归因、任务状态能恢复、工具结果能追踪、高风险动作有确认、当前事实从真实系统读取。这一步完成之前RAG 救不了系统。第四步再加 RAG。当你明确遇到这些问题时再加文档太多人工找不到、知识散落在多个系统、需要引用来源、需要按版本 / 权限 / 业务线过滤、需要相似案例或相似实现。并且最好做混合检索而不是纯向量。第五步补 Trace 和评估。至少记录用户任务、Router 选择了哪条路径、检索了哪些知识、调用了哪些工具、读取了哪些状态、哪些证据进入最终上下文、哪些候选被跳过、工具结果和错误、最终回答基于哪些证据。否则你无法回答最基本的一个问题这次做错了到底是知识没召回状态没读工具没查还是模型没用对结尾不要问要不要 RAG要问上下文怎么来回到开头那个问题为什么有的智能体需要 RAG有的看起来不需要答案不是模型强弱也不是 RAG 过时了。真正的答案是不同 Agent 需要的上下文类型不同。知识问答 Agent 需要 RAG因为它要从大量稳定文档里找依据。业务操作 Agent 不一定需要 RAG因为它更依赖工具、权限和实时状态。长任务 Agent 不一定先需要 RAG因为它更需要 Task State 和 Trace。个性化 Agent 不一定先需要 RAG因为它更需要 Memory。Cursor 把上下文成本前置到索引因为它服务的是 IDE 内的高频、低延迟、大仓库语义召回。Claude Code 把上下文成本放在执行循环因为它服务的是终端按需启动、需要执行验证、对现场新鲜度敏感的工程任务。两条路都需要检索只是把检索发生在了不同地方。如果你自己做 Agent把这条链路画清楚任务进来 - Router 判断需要哪类上下文 - 用 RAG 找知识 - 用 Tool 查现场 - 用 State 保持任务连续 - 用 Memory 召回长期偏好 - 用 Policy 控制风险 - 用 Builder 组装证据 - 用 Trace 记录过程RAG 就不会变成一个信仰问题。它只是上下文工程里的一个组件。有些任务需要它有些任务不需要有些任务需要它先找方向、再让工具确认事实。最后留一个问题你现在开发的 Agent是缺 RAG还是把 State、Memory、Tool、Policy、Trace 都误当成了 RAG学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
