诗曰:
科技新潮卷巨澜，RAG旧制渐凋残。
深搜不倚向量库，MCP通联天地宽。
思维链里藏玄钥，脚本生成胜绘栏。
莫道框架终有尽，开源星火又重燃。

2023 年 RAG 风靡一时, 市面上冒出一批 LLM AI 应用框架或开发库, 像 Dify､ LangChain､ RAGFlow､ FastGPT 等等, 都打着整合 RAG（检索增强生成）与 AI 工作流的旗号｡ 它们似乎许诺了一种捷径, 让开发者能快速搭出既能消化私有知识､ 又能自动跑腿的智能应用, 深受 B2B 用户的喜爱｡ 然而 AI 行业的技术演进何其迅速, 到了 2025 年, Deep (Re)Search 异军突起, MCP（模型上下文协议）渐成气候, 这两股新势力, 恐怕正悄悄掘着这类通用 AI 应用开发范式的根基｡ 它们赖以立足的两条支柱——所谓 RAG 和图形化工作流——似乎都遇上了硬茬｡

Deep (Re)Search 一出手, 便知向量 RAG 有没有

传统 RAG, 几乎等于在一些框架（如 LangChain､ Dify）里, 高度依赖向量数据库的那套玩法, 其看家本领无非是: 用户扔进文档, 系统将其切分段落, 调用嵌入模型（embedding model）化为向量, 召回时再根据语意相似度捞出些片段, 塞给大模型去组织答案｡ 这套流程, 一度被捧为处理私有知识､ 给模型“开外挂”的不二法门｡

但 Deep (Re)Search 一鸣惊人, 直接给这套以词句向量相似度为核心的 RAG 范式提出了严峻考验｡ 不论是 Google Gemini 的 Deep Research, 还是 XAI grok 的 DeepSearch, 还是 OpenAI deep research, 甚至是 Perplexity AI, 姑且统称 Deep (Re)Search, 个个都完全不依赖向量化的文档库, 纯靠关键词的网络搜索实现, 效果却好得吓人｡ 于是结论显而易见, 昭然若揭: 搞 RAG, 向量数据库搜索这门过度炒作的技术, 不但没那么必要, 甚至可有可无｡

Deep (Re)Search 技术细节尚被各大 AI 巨头保密, 此刻外界所知甚少, 多半只能从使用体验中, 倒推技术原理｡ 给人感觉上, 行为方式更像做研究: 先吃透问题, 再琢磨精准的关键词, 浏览结果, 不满意就调整关键词再搜, 最后汇总提炼, 交出一份像模像样的结构化报告｡ 整个过程, 向量数据库无从落脚, 反倒是大模型自身的“研究功夫”被推上了前台｡

这就带出个要命的问题: 想让 RAG 效果更好, 到底该死磕向量召回那些套路, 比如加入重排序等, 还是该下力气打磨模型自身做“研究”的真本事?

Deep (Re)Search 的出色表现, 明确指出: 关键在后者｡ 私下揣测, 其核心技术恐怕有二:

1. 固化 CoT（思维链）的“思考路径”: Deepseek-R1 石破天惊, 观其论文所述 R1-Zero 训练过程可知, 模型为了形成良好的答复, 其潜在的思考路径何止千万｡ 但要做好深度研究, 有两条道必须走通: 一是领会用户意图, 拟出恰当的搜索词；二是嚼烂搜索结果, 回头优化搜索词｡ 这就必须在后训练阶段 RL, 对走到这类思考路径上的行为给足奖励, 让模型“开窍”, 学会搜索-反馈-再搜索的反馈循环｡
2. 固化“结构化输出”的格式: 观察 Deep (Re)Search 跑起来的界面, 不难反推出, 模型吐出来的东西, 格式是相对固定的｡ 要是模型信马由缰, 输出格式乱套, 轻则亡羊补牢, 重则推倒重来, 白白烧掉算力, 耗费上下文窗口｡ 与其每次求它办事都得在 Prompt 里絮絮叨叨､ 耳提面命, 塞一堆 JSON schema､ 给几个例子, 挤占宝贵的注意力空间和显存, 不如在训练后期就把这套规矩“刻进骨子里”｡ 就像训练 -thinking -reasoner 模型会焊死 <think></think> 标签一样, 直接拿 Deep (Re)Search App 需要的输出格式来微调, 让它天生就懂规矩｡ 再者, 即使这套格式规范自身需要迭代改进, 其迭代速度也不及对应模型的迭代速度, 使得 “prompt 指定输出格式” 这种在其他场景下的灵活性优势, 在此场景下变得毫无必要｡

这两条路径都指向了非微调 LLM 不可的技术路线｡ 这么看来, 那些一门心思扑在“嵌入向量库相似度检索召回片段重排序”上的技术路线, 路走窄了｡ 当 Deep (Re)Search 用 “做研究” 的架势, 凭着一身微调出来的硬功夫整合信息时, 你还在那吭哧吭哧优化召回的准确率, 效果提升不痛不痒, 甚至可以说是被人家“降维打击”了｡ 以前觉得传统 RAG 还凑合, 那是没见过 Deep (Re)Search 大发神威, 现在两相对照, 高下立判, 活像 Llama 2 碰上了 GPT-4｡

想当年, 手里攥着些精校过的垂直领域数据, 是该拿来 SFT 微调大模型, 还是拿去做 RAG 向量知识库? 这道选择题, 在 GPT-4 刚出来的时候还有争议, 到 llama3-70b 普及后没几个人微调了: 大量实践得到的经验是, 微调费力不讨好, RAG 虽然不那么费力, 但实际体验也没有那么讨好｡ 三十年河东三十年河西, 今日 Deep (Re)Search 当道, 情况似乎再度反转, 如今那些只埋头做向量检索技术的厂商, 要是没本事自己把大模型微调成适合 Deep (Re)Search 的形状, 恐怕也只能干瞪眼, 坐等哪个菩萨心善, 开源个 Deep (Re)Search 版的 LLM 了｡ 反观 RAG 老字号 Cohere, 坚持自研 LLM, 如今看来, 确实是棋高一着｡

有些 AI 爱好者有种错觉, Deep (Re)Search 只能搜互联网, 而传统 RAG 用的是本地知识库, 两者场景本就不同｡ 这就大错特错了｡ Deep (Re)Search 作为面向公众的产品功能, 接的是互联网; 但这不等于这门技术只能吃互联网这碗饭｡ 后端对接的是本地文档库还是谷歌搜索, 对 LLM 模型来说, 本就是解耦的｡ 若真有富老板找到奥特曼, 让他拿 Deep (Re)Search 技术做个企业内部版, 对奥特曼来说, 无非是换个数据源的事｡

所以说, RAG 的字面含义——“召回增强式生成”——并没过时｡ 过时的, 只会是被各路专家､ 厂商死死摁在“嵌入模型向量数据库”上的传统 RAG 实现｡ Deep (Re)Search 用事实证明, 优化模型自身的思维链, 让它学会迭代关键词去召回信息, 比捣鼓向量数据库有用得多｡ 干脆点说, Deep (Re)Search 就是 2025 年 RAG 该有的样子｡ 未来已来, 只是分布不均｡

自动化工作流新玩法: MCP + AI 脚本

这类 AI 应用框架的另一根支柱是工作流｡ 有些工具（如 Dify､ RAGFlow､ LangFlow）喜欢用拖拽流程图, 可视化地把任务串起来；另一些框架（如 LangChain）则倾向于用代码定义链式或 Agent 结构｡ 它们初衷都是帮用户编排 AI 能力, 搞定复杂的自动化任务｡ 建立 AI 工作流, 无非两件事: 一是逻辑要足够活泛, 二是要左右逢源, 打通生态, 接通本地软硬件和各路远程服务｡

拖拽流程图, 够灵活吗? 流程图再花哨, 终究被平台提供的节点库框死了｡ 节点不够用? 那就得撸起袖子写代码, 造个自定义节点｡ 既然如此……何不一开始就直接写代码? 如今, 张嘴就能让 AI 写代码, 这正是 LLM 的强项｡ 有这等利器在手, 写脚本则如虎添翼, 拖拽流程图则隔靴搔痒｡ 各行各业的自动化需求千奇百怪, 要应付这些高度定制化的任务, 恐怕只有代码脚本才能提供那份“随心所欲”的灵活性｡ PocketFlow 硬凑百行代码的噱头固然可笑, 但它形成 AI 工作流的思路, 值得借鉴: 核心代码库为单文件, 并且小得足以复制粘贴到任何 AI 聊天对话框里, 即使叫上下文才 4k 的旧款 GPT4 临时去学, 也能轻松掌握｡

更要命的是, AI 应用怎么打通任督二脉, 连接外部世界? 像 Dify 这样的平台, 尝试自己搭台唱戏, 搞插件市场；LangChain 则下了苦功, 构建了一个庞大的集成库（Integrations）｡ 这些都是为了简化 AI 应用跟外界打交道的麻烦｡ 但现在, Anthropic 倡导的 MCP（模型上下文协议）这个开放标准, 正以星火燎原之势蔓延开来, 颇有天下归心的气象｡ MCP 的核心价值在于, 它把“连接外部服务”这件事给解耦了｡ 借助这种标准接口, AI 应用客户端就能和各种本地或远程资源（文件､ 数据库､ API､ 硬件等等）轻松互动｡

这意味着什么? 意味着大量开放､ 开源､ 去中心化的 MCP 仓库一旦蔚为大观, 开发者或用户写自动化脚本时, 就能专注于核心的业务逻辑, 把那些跟外部世界打交道的鸡零狗碎, 统统甩给实现了 MCP 的组件或服务去操心｡ 以前得指望特定平台的插件市场（比如 Dify 的）或者某个框架的庞大集成库（比如 LangChain 的）才能获得的“连接能力”, 现在靠一个开放标准加上社区五花八门的实现就能搞定｡ 这对 Dify 这类平台的插件生意, 或者 LangChain 那种“中央集权式”的集成管理模式, 无疑是直接的冲击和挑战｡ 一个还没站稳脚跟的中心化平台, 一个需要不断投入人力去维护巨大集成库的框架, 凭什么跟一大片得到广泛认可､ 由社区驱动的开放标准实现掰手腕?

那么, 当下搞工作流, 到底哪家强? 要是非常喜欢拖拖拽拽, n8n 据说还行, 不妨一试｡ 但我个人越来越觉得, 对很多场景而言, 让 AI 生成一次性脚本, 可能是更好的路子｡ 这里说“一次性脚本”, 不是搞严肃的软件工程｡ 兼容性､ 健壮性､ 可维护性､ 可读性､ 高性能? 通通可以放一边——跑对结果就是赢! 要是报错, 或者跑得结果不对, 没关系, 让 AI 再生成一版脚本｡ 这种玩法, 依赖又轻, 又不吃资源｡ 至于说管一堆脚本会不会头大? 什么年代了, 这点心智负担完全可以甩给 AI｡ 当然, 凡事看需求, 要是真需要一个极其复杂､ 稳定运行､ 还得长期维护的工作流, 那老老实实的可视化方案或许还有它的用武之地｡

就算 Dify 或 LangChain 原地支持 MCP, 也不构成用户必选的理由｡ 论权威, 比不上 Claude 桌面版这类官方嫡系；论轻便, 又不如市面上那些专攻此道的小工具｡ 兼容一个开放标准, 不代表你就有了独特的卖点或护城河, 除非你能在 MCP 之上玩出什么别人没有的花活儿｡

结语: AI 应用框架何去何从

一边是 Deep (Re)Search 强势崛起, 直击传统 RAG 在信息处理上的核心价值；另一边是 MCP 普及加上 AI 写脚本越来越溜, 冲击着现有工作流方案的吸引力｡ 传统 LLM AI 应用框架尝试两条腿走路, 结果两条腿瘸｡ 那些试图“一站式”包办 RAG 和工作流的 AI 应用框架, 前景堪忧, 日薄西山｡

昨日明星, 明日黄花｡ 廉颇老矣, 尚能饭否?

参考资料

• The Differences between Deep Research, Deep Research, and Deep Research
• RAG的2024—随需而变，从狂热到理性

本文初稿于 2025-03-21 撰写并小范围发表｡
终稿由 gemini 2.5 pro 润色, 人工校对完成, 于 2025-04-15 上传博客公开发表, 但正文涉及的种种, 仍基于 2025-03-21 的时事｡

后续更新 (2025-04-14):

2025-04-14 开源的 THUDM/GLM-Z1-Rumination-32B-0414, 可能是第一个专为 Deep (Re)Search 能力优化的开源模型, 后续预期有更多这种模型问世, 于是, 原先微调调不动､ 召回召不准 RAG 框架们, 总算又可以续命了｡