别卷 Prompt 了！它只是你 AI 员工的“开机键”
进入 2026 年，Skills 的爆火和 Clawdbot（OpenClawd）的横空出世，传递了一个清晰的信号：当 Agent 从酷炫的演示走向支撑业务的生产系统时，单纯依靠优化提示词（Prompt）的“艺术”，已无法满足企业对可靠性、执行力与持续进化能力的刚性需求。
这并不是说 Prompt 不再重要，而是它的角色发生了根本性转变。它从一个需要被无限雕琢、承载所有逻辑的“总指挥”，演变为一个触发器。它的新任务是：准确理解人类指令，然后高效地唤醒后方一套庞大且专业的能力系统。就像手机的开机键，按一下就可以打开各种应用功能的入口。
这个能力系统，正是现代 AI 工程的核心——一个为 Agent 打造的“可控思维”架构。它由三个相互协作的引擎构成：
1. 记忆引擎（Memory）：确保 Agent 有“记性”，能够记住用户偏好和交互历史。这意味着它能记住重要的对话历史和你的要求，做事有头有尾，不用你每次都从头交代。
2. 知识引擎（RAG）：确保 Agent 有“实时的知识库”，能够从海量、动态的企业数据中精准检索信息，保证它给出的信息永远准确、最新，不会凭空乱造。
3. 技能引擎（Skills）：确保 Agent 有“手脚”，能够将复杂的业务操作（如数据查询、报告生成、系统调用）封装为可被随时调用的标准化模块，从“能说”走向“会做”。
Prompt、Memory、RAG、Skills 共同构成了一个能独立干活、不出错、有记性的 AI 员工，当它要完成的任务越复杂、越关键，后三者的系统化工程价值就越发凸显，Prompt 也因此必须从舞台中央退下。作为使用者，我们不再只是和模型对话的“提问者”，而是为 Agent 设计和组装能力模块的“架构师”，思考重点也从“怎么问得好”，全面转向“怎么让 AI 干得好”。
理解这种从孤立提示到系统工程的范式迁移，是我们今天话题的起点。下面，是一场来自 OceanBase 社区嘉年华的圆桌讨论，看顶尖的实践者们如何具体拆解这些核心组件的演进与融合。
从 Prompt 到 Skills，RAG 还行不行
主持人：张海立，LangChain Ambassador、OceanBase Ambassador，up 主“沧海九粟”
嘉宾：张颖峰，RAGFlow CEO
嘉宾：余金隆，FastGPT 负责人
嘉宾：古思为，Co-founder of Nowledge Labs
嘉宾：吉剑南，OceanBase AI 平台与应用负责人
议题一：2026 年 RAG 生态何去何从？
张海立：从去年末到今年年初，AI 领域热点频发。除了近期备受关注的 Clawdbot（OpenClawd），Skills 成为另一个重要话题。我在进行 Skills 相关实践时发现，许多 Skills 与本地文件系统紧密相关，但都离不开 RAG 体系对外部数据的召回，这对 Agent 发挥更大作用至关重要。LangChain 在构建 Agent 生态时，RAG 也是核心体验之一。想请教各位老师：在当前大环境下，您认为 2026 年 RAG 生态将如何发展？请结合各自产品进行简要介绍。
张颖峰：先说个笑话，2025 年被称为 Agent 元年，当时有朋友问我们要不要（从 RAGFlow）改名为 AgentFlow；而今年是 Agent 落地元年，我们内部也讨论要不要改名为 ContextFlow。实际上我们永远不会改名，因为我们认为“R”是核心点，单纯的 RAG 确实不足以服务 Agent，但“R”是服务 Agent 数据层的核心点。
单纯的 RAG 确实不足以服务 Agent，但 RAG 是服务 Agent 数据层的核心。当前 Agent 需要的是上下文（Context），它来自三方面数据：企业内部数据、工具数据以及对话过程中生成的数据。Skills 偏向工具层面，但比工具更高一层，还包含了规划（Plan）能力。Skills 本身也需要搜索——当企业内部有 1000 个 MCP 时，如何调用对应的 Tools 和 Skills 同样需要检索能力。因此 RAG 永远不会消失。
我们的布局是从 RAG 引擎向上层引擎演进。技术本身未变，但内涵发生变化：数据从简单的企业内部数据，扩展到 Agent 过程中的上下文数据。我们判断未来所有 Agent 都是 Coding Agent，包括对工具的调用也将变成代码生成（Code Generation），需要 RTC（Run-Time Code）在沙箱中执行，访问各类 Tools 和 Skills，最终通过文件系统返回结果。这也是我们向上下文引擎方向演进的核心计划。
余金隆：我赞同颖峰老师关于 Code Generation 解决所有问题的观点，这也是我们团队的认知。无论是做 RAG 引擎还是 Workflow 引擎，都在向代码生成靠拢。
RAGFlow 不想改名，我们有点想改名字。因为近几年我们发现，做 Agent 本质是把数据使用起来，所以我们的平台主要解决数据连接层问题。过去数据分布在数据库、文档等各种结构中，现在通过大量连接器实现不同数据的连接。Skills 出现后，以前需要写代码和 Webhook 连接的数据层，现在可以通过 Skills 实现。这对国内交付场景特别有价值——国内系统数据格式不统一、缺乏标准，交付同学以前需要写大量适配代码，现在通过 Skills 将数据标准化连接到平台。
今年我们主要做两件事：一是完善连接层，二是优化 RAG 的 Retrieval 层。Retrieval 效果很大程度上取决于召回过程，不同场景的召回流程差异很大。过去需要通过 Workflow 形式搭建积木、进行意图识别分类、编写不同提示词适配不同场景，链路复杂。现在我们探索通过 Skills 这种偏语义化的方式生成代码，类似 Test-to-Code 的思路，但生成的是 SDK 代码来构建整个 Retrieval 流程，这是一个很有意思的探索方向。
古思为：关于 2026 年 RAG 相关变化，可以看到在 Coding Agent 中对代码的检索已从纯 Embedding 转向 AST（抽象语法树）、Agentic FS Graph 或 AST Graph 等方案。包括 PageIndex 项目，以及我们公司在 Haicon 2024 发布的实验性项目 OpenKL，尝试用类文件系统方法处理 Memory 和 RAG Docs。
另一个趋势是 RAGFlow 等通用内容引擎同时处理文档和 Memory。我们已发布的第一个产品是面向 C 端的 Memory 桌面 APP Knowledge MAM，动机是帮助用户在不同工具间无缝切换工作流。例如在 ChatGPT 完成 Deep Research 后，无需重新解释即可继续在 Cursor 中工作；或者当 Agent 帮助发帖子进入热榜后，可以切换到另一个 Agent 继续任务，同时保留所有交互历史和偏好设置。
吉剑南：OceanBase 面向 AI 的能力——seekdb、 PowerRAG 与 PowerMem 均已开源。我们团队除了做向量数据库和 AI 应用基础设施外，也在探索面向数据库的 AI 应用，比如面向开发者工具的 Text-to-SQL 和数据库智能运维。
关于 2026 年趋势，我认可颖峰老师说的 RAG 不会消失，它和 Skills、MCP 处于不同维度。即使未来 Skills 和 MCP 越来越多，最终仍需通过 RAG 或某种方式召回，不能将所有 Skills 都喂给模型。但我有不同观点：当前 RAG 仍集中在知识库领域，通过搭建 Chatbot 做问答，而问答更像玩具而非生产应用。真正的生产应用应将 RAG 融入日常工作，如销售根据集团材料为客户生成定制化 PPT 或“一指禅”。未来 RAG 会结合应用反馈，反向影响数据如何切分、如何做更精细化的 Embedding，而非仅仅前置处理。
议题二：AI 系统中的多路检索与数据源管理
张海立：感谢各位的分享，Skills 给我们带来了更多机会，能创建更多 Agent 和 RAG 应用。同时有一个概念非常重要：我们常说的 RAG 里的“R”，到底指什么？它指的是 Retrieval，是一个“检索过程”。
Retrieval 的 source 可以是文件系统，可以是数据库，可以是 Web，甚至多种来源并存。所以引申出第二个问题：随着 Skills 和 RAG 体系的发展，未来多路检索会越来越常见，RAG 不会消失，它将长期存在于 Agent 体系中。这样一来，数据源头的管理就变得更加重要。最简单的是把数据直接塞进软件系统，但更常见的情况可能是：越来越多的数据会落在数据库中。在这种情况下，当数据库的多路检索能力得到极大增强之后，做 RAG 应更多依赖数据库，还是在数据入库层面通过一些技巧将复杂的事情交给基础设施？
吉剑南：必然入库是最大影响，这也是 OceanBase 提出混合搜索（Hybrid Search）概念的核心。如果完全以非结构化数据或切片方式进入系统，召回效率顶天就是向量化的近似能力。去年所有 RAG 产品都在强调从非结构化数据中提取结构化数据，存为 JSON 等半结构化形式，用于前置过滤或与结构化数据一起做混合搜索。
为什么要这样做？本质上是语义理解包含两个层面：一是你问的是模糊问题，但脑子里想的是确定性答案；二是问题模糊，答案也模糊，希望召回所有相关点。大部分实践场景属于第一种。
在文档预处理时，结构化提取非常重要。例如从医疗文档或简历中提取结构化字段，召回时先对结构化数据做精确匹配，再对字段内的非结构化内容做向量检索。半结构化数据解决范围和准确性问题，向量检索解决语义理解问题。通过混合搜索模式，入库时做文档理解提取结构化数据，召回时统一检索，效率会大幅提升。数据库也应在接下来一年面向这个方向发展，我们看到 Chroma 等国外开源数据库已在往这个方向演进。
古思为：我们比较早做 Graph RAG，可能是第一个探索的团队。张老师分享的新架构与我们上一家公司做的 FusionGraph 很像。核心思想是：要让复杂 RAG 系统表现好，索引结构既要贴近知识本质，又要把特定场景的领域知识元信息投射到 Retrieve、Index、Transform 各环节做优化。
通用方法是知识后加工时做 Entity Graph 或 Semantic Graph，同时在做 IDP（Intelligent Document Processing）和 Parsing 时，对多层 folder 和复杂章节的长文档要识别 layout，涉及多模态时考虑是否转换模态。要做好这些并能演进，不要过度领域化 pipeline，而是按基本原理拆分，确保各组件能力跟上。Database 是重要基础设施，比如 RAGFlow 的 Graph 和 Tree 结构能否原生保留、高效检索；要做 Dynamic Agents Retrieve，模型能否自然利用复杂多层结构。数据库的高性能、索引召回率和内置 Hybrid RRF 都很重要，决定系统下限。
余金隆：在交付过程中，数据源解析是基础且重要，但更重要的是召回（Retrieval）层。即使使用最简单的原始向量，只要检索词和检索语句构建得好，也能得到很好效果，只是效率较差。我们在此基础上扩展了语义化加标量方式。
但标量遇到较大问题：它不固定，用户自己也不知道需要什么标量。我们今年研究的方向是标量的动态扩展，包括用户自身扩展和模型自生成。例如给模型一些 Skills，或用户编写场景来生成场景下的标量存入数据库。当然这会引发多租户系统中成千上万标量的高效索引问题，以及渐进式生成问题——很难在预处理时生成所有标量，很多需要在检索时评估并渐进补全。在 Retrieval 阶段，多标量关联查询的生成方式也借鉴了 Text-to-SQL 的思路。我们希望找到通用存储方式覆盖 80% 场景，目前看语义化加标量检索加动态标量可以覆盖很多场景，所以我们没有用图，因为图是以复杂方式解决复杂问题，而 AI 时代可能有更简单的方式处理复杂问题。
张颖峰：我们现在是数据库使用者，但曾经也是数据库开发者。从纯技术角度，我非常喜欢"一边推理一边搜索"的技术方向，我称之为 Attention Engine，我认为它也是一种 RAG。DeepSeek 近期已大体实现类似方式，因显存限制不得不用内存，在推理时通过内存索引搜索内容，从外置记忆变为内置记忆。但从商业角度这条路行不通，要求检索与模型延迟极低，必须在同一交换机后，意味着只能卖一体机。因此我们仅作为调研方向。
从业务视角看，我们最早做 Infra 、做数据库时发现离业务太远，后来做 RAG 流量较大，促使我们重新思考 Data+AI 落地生态。我们的观点是：过去数据库是底座，上面写应用做增删改查；现在应用是 Agent，底座是以 RAG 为基础的组件，数据库在底层支撑 RAG 中间件。Data+AI 建设不能 AI 和 Data 各干各的，接口有时不清晰，因为中间层用 Python 实现，其好处是适应多变需求，召回策略可随时调整，不过 Python 带来的效率问题也让人头疼。AI 时代的数据底座让 Infra 人员直接触达业务，通道变短。因此中间层需要一个 Python 层适应业务多样化，一旦发现好的方式就迅速下沉到数据库解决效率问题。
我们在 2024 年底就鼓吹跨模态，但至今未落地，因为 Infra 到模型都未准备好。跨模态需要多向量搜索（Tensor Search），用多向量表示图片或文本，语义更准确、排序更准，但数据会膨胀两三个数量级，这是灾难。这需要模型、算法、Infra 共同解决挑战。因此我们需要端到端的、以 RAG 为中间层的体系，这其实就是 Agent 的数据库。
议题三：Memory 与 RAG 到底有何区别？
张海立：我非常认同颖峰老师提到的“端到端”。作为 LangChain 社区大使，我们主要做应用层框架，今年非常想做的一件事情是：和各个厂商比如 OceanBase、seekdb 一起提供真正的端到端解决方案，服务企业和个人用户，帮助他们快速构建生产级 Agent。
简单总结一下几位老师的理解：当我们面向用户提供检索能力时，会在中间层、应用层、数据库层进行多层协同优化，共性问题会逐步下沉到数据库解决。以我的个人体验为例：在最初布道时，我会给大家讲很多 RAG 的流程和算法，但从去年底开始，我更多会建议“你直接用这个数据库就好了”，因为它已经帮我们解决了很多多路检索的问题。这种“沉淀”是应用方和数据库厂商不断联合实践的结果。
下一个问题也与此有关：我们经常被问到 Memory 和 RAG 到底有什么区别？从 Memory 召回和从数据库召回有何区别？近期 Clawdbot（OpenClawd）从文件系统读取，到支持 PowerMem 直接接入进行更有效的内存管理。想请教剑南老师，这里做了什么特别工作？以及各位如何理解 Memory 与 RAG 的关系？
吉剑南：Memory 是为让大模型更像人而引入的。如果查询的都是客观事实且不存在人与人之间的理解，RAG 已能解决问题。但问题在于每个人对客观事实的理解和描述不同，加上人有记忆曲线，希望记住昨天强调的内容——这些内容虽非客观事实，但是主观认可。
例如每个人都有一个叫"老王"的朋友，随着时间推移这个"老王"可能已变化，但在记忆中一直叫"老王"，这时 RAG 搞不定，但 Memory 能搞定，因它会更新对"老王"的认知。“老王”是一个知识吗？并不是，因此，Memory 的核心是个性化和千人千面。
无论是 RAG 还是 Memory，整体是搭建一整套解决方案面向 Agent 为业务带来价值，不应区分该用 RAG 还是 Memory，而应思考如何组合好共同为业务赋能。
古思为：我们目前做 Memory，之前做 Graph RAG。Memory 有广义和狭义之分，狭义指 Agent 或 LLM 需要检索的更外部的 Memory，它确实是特殊的 RAG，特殊在几个方面：
1. 原始数据是持续的 message thread。
2. 知识需求是时序性的（temporal），包含两个时间维度：信息创建时间、事件/事实时间。
3. 时序性存在一个问题，遗忘（forget）是 feature 而非 bug，需结合时间、访问频率和正反馈影响 Retrieval。
4. 条目层面有 category 和不同类型，取决于 Memory 目的，可能需要 schema 区分 ephemeral（瞬时）和 permanent（永久）。
5. 不同结构间需要 transform 关系，可在 Retrieve 或写入过程触发 event，或周期性处理（类似大脑做梦处理记忆）。
6. 多租户和 sessional scoping。
如果做细会发现与典型 RAG 差别很大，但二者又有很大 overlap。RAG Engine 可以处理 Memory，Memory Engine Service 项目也会处理文档，界限会变得模糊。
余金隆：我理解 Memory 算是广义 RAG 的一种，无非也是数据 I/O、Pipeline 处理、特殊数据结构，比较偏个性化。从产品角度看，Memory 目前 C 端个性化场景用得较多。在任务流中，用户提 Memory 的还不多。在技术实践中，Mem0 有工具调用的 Memory 用于长 Agent 任务，但看其架构有点像 Context Engine，与 Memory 又不太一样。所以感觉 Memory 还是 RAG 的一种特殊 Pipeline 形式，没有太大区别，可能实时性比 RAG 更高。
张颖峰：单从技术角度而言，Memory 与 RAG 确实没有本质区别，都是 Retrieval。但重要的是 Memory 如何发挥作用，这是在快速变化的。
我在分享 Context Engine 时提到三类数据：企业内部数据、Tools 数据、Agent 使用过程中生成的数据。但它们存储在两个地方：RAG 专有区域和 Memory 专有区域。可见所有大模型生成的内容都要存到 Memory，包括 Skills 的元数据（Skills 本身数据存文件系统）。
怎么存、什么时候存、什么时候取，这些设计点很难决策。例如生成 Plan 是否存入 Memory？作为 Plan Cache 有价值，但如果 Human-in-the-loop 干预修改了 Plan，应如何存储？以后如何根据 Memory 数据抽取内部 MCP Tools 的 Skills？这些都是新问题。
从 Infra 角度，RAG 和 Memory 没区别；但从使用者角度，Memory 是重要的基础设施，解锁了大量场景。因此 Memory 项目很多（如 Mem0、MemU），但对 Memory 区域的定义（数据库该有哪些表）尚未完全一致，反映 Agent 到底需要什么样的 Memory 还在进化中。不过整个 Agent 体系需要哪些组件，已进入收敛期，就是 Context。
议题四：Skills 开发实践与推荐
张海立：各位老师都在做 Workflow、数据库或融合方案，是否开发了自己的 Skills 帮助用户更好地使用产品？如有请推荐，如无请设想会开发什么样的 Skills 服务开发者？
张颖峰：抱歉我目前没有特别好的推荐。我比较关注如何针对大量内部 MCP Tools 生成对应 Skills，这需要一个专门的 Agent 平台来实现。我的观点是：未来 Agent 平台可能没有统一标准，所有都是 Coding Agent，但特定 Agent（如低代码、无代码、Workflow）可能因良好交互而便于生成 Skills。
余金隆：我们内部 Skills 用得很多，运营和 SEO、GM 等场景一大把。产研团队用得不算多，主要是代码开发和 Review。交付团队用得特别多：面向用户时遇到各种问题，排查系统后沉淀为 Skills，辅助交付和运维。因此，内部有句玩笑话“交付同学比研发同学更懂系统”，他们做了二十多个 Skills，涵盖工作流搭建、问题排查、RAG 优化等。总体感觉 Skills 更像自然语言工作流，虽更抽象，但目前大部分还是偏自然语言的 Workflow。对非开发人员在生产流程上比较友好。
古思为：我们维护基于 Skills 的插件，在 Skills 发布第二天就推出了 Cloud Code 插件支持。早期没有 Skills 时，我们只能基于 MCP，让插件调用 MCP 的 Custom Command 触发操作，用 Hook 实现功能。后来发现 MCP 规范了工具调用，但有两个地方不如 Skills：
1. MCP 有 Prompt 抽象，实现为斜杠命令可主动调用类似 Workflow 的东西，但并非所有 Client 都实现，我们要做很多额外工作。Skills 天然支持主动说和自动做。
2. Skills 的打包方式让不同工具间组合更灵活。我们内部将 Skills 从 MCP 换成 CLI 后变化很大。例如让 Agent 做 Memory 复杂更新查询时，MCP 需要多轮次，即使 interleave 也不够好。但 CLI 可以动态组合 Linux Shell Pipeline，在一个 turn 里精确完成复杂操作，且内部 CLI/Script 可以 self-contain，打包给用户后自然享受复杂能力。
调试经验方面：Skills 比较通用，容易用不同平台测试。我们发现一个有意思的案例：Skills 对应的工具有很多具体选择，如何调优模糊的问题？我们的做法是用最聪明的 Agent 做 honest 的复杂 long run 评估，像跟客户聊天一样告诉我们如何改进。有时需要更端到端看细节，不得不自己 server model，在 template 解析过程中用小模型发现工具复杂类型定义的问题，虽然其他模型能克服，但会影响 performance。
吉剑南：OceanBase 内部沉淀了很多 Skills。Skills 本质是最佳实践，告诉大模型最佳实践是什么，而最佳实践无非两类：一是提升工作效率的工程类（如 Cursor 的 rules），二是业务类 Skills。
Skills 也可以用在 RAG 上，RAG 效率和准确性今天跟两个因素相关：相似度和 Top K。但大家有没有想过，召回前 Top K 和相似度有时不能完全指定，需要反复调，知识库又在更新。如果针对不同的业务实现写不同的 Skills，例如当需要某类数据时，希望相似度设到什么位置、Top K 设到什么位置，根据召回结果动态调整，这就变成了一个 Skills。这是 RAG 搞不定的，需要根据具体召回内容判断，是 RAG 的最佳实践。
之前大家可能想是否把 RAG 数据放 Skills 里就不用召回了，而我觉得 Skills 是对 RAG 的增强。关于 OceanBase 的 Skills，我们是有准备的，包括 seekdb 的研发人员今天也在现场，未来应该会有更多相关的 Skills 开放出来。
张海立：非常感谢各位老师精彩分享。简单总结：RAG 还“行”！只要理解 RAG 的 R 是 Retrieval，有 Memory、传统数据库等多种数据来源，随着各位老师所在厂商的努力，多路检索能力、应用层提升、流程算法优化都在推进。相信 2026 年 RAG 会有更大发展。
Agent 可控思维的工程实现：从分散工具到一体化基座
本次圆桌讨论，为我们清晰地勾勒出 2026 年 AI 工程化的演进路径。专家们的共识指向一个明确的结论：构建可靠、可用的 Agent ，其核心不再是追求某个单一组件的极致，而在于如何系统性地整合记忆（Memory）、检索（RAG）与技能（Skills），形成一个协同的“可控思维”体系。
综合专家观点，这一体系的发展呈现出三大趋势。第一，RAG 不会消失，反而会变得更加基础与核心。它的内涵正在从狭义的文档问答，扩展为 Agent 对所有上下文数据的 Retrieval 能力——无论是企业内部文档、数据库中的业务数据，还是工具（Tools）与技能（Skills）的元数据，都需要被高效检索与调用。未来的 RAG 将深度融入工作流（Workflow），根据应用反馈动态优化，并与混合搜索（Hybrid Search）等技术结合，实现更精准的“语义理解+精确过滤”。第二，Memory 与 RAG 边界模糊，融合为数据层。从技术基础设施（Infra）视角看，Memory 与 RAG 的本质都是数据的存储与召回。二者的区别更多在于数据特性和使用场景：Memory 更侧重于个性化的、时序性的对话与状态记忆；RAG 更侧重于客观的、相对静态的知识存储。但在服务 Agent 时，它们共同构成了支撑“上下文（Context）”的数据层。一个优秀的底层平台，应能一体化地管理这两种数据范式。
第三，工程复杂度下沉，呼唤一体化数据基座。当应用层通过 Skills 和灵活编排满足业务多变需求时，通用的、性能瓶颈性的复杂度会自然下沉到底层基础设施。无论是多路检索、混合搜索，还是海量 Skills 元数据的管理，都对底层数据平台的能力提出了更高要求。专家们指出，未来的理想路径是依赖一个强大的数据基座，它能原生支持向量检索、关系查询与结构化记忆，从而让开发者从繁琐的多系统集成工作中解放出来，更专注于 Agent 本身的业务逻辑。
因此，构建“可控思维”的终极路径，在于选择或打造一个能够统一承载 Agent 记忆、知识与状态的数据基座。这样的基座，正如专家们在讨论中多次暗示的，能够将 Memory 的个性化记录、RAG 的海量知识检索、以及支撑 Skills 运行的业务数据，融于一个简洁、高效、一致的系统中。它让 Agent 的“思维”过程变得可管理、可观测、可优化。
最终，Prompt、RAG、Skills、Memory 这些活跃于应用层的概念，都将在这样稳固的基座之上，更好地各司其职、协同工作，共同将 Agent 从“聪明的对话者”转变为“可靠的业务执行者”。这标志着 AI 应用开发正式进入系统工程时代，而坚实的数据基础设施，是这一切得以实现的基石。
