最近，OpenClaw（其后续版本演变为Clawdbot，现常被称为Moltbot）在技术社区中异常火爆，其热度颇有当初Manus走红时的趋势。然而，其本质更像是对多种现有能力的排列组合，它为何能迅速流行起来，这一现象本身令人感到有些费解。

更令人意外的是，这股风潮甚至带动了Mac mini的销量，不少用户在社交平台晒单时声称购买它是“为了运行一个开源AI项目”。更为夸张的是，该项目在GitHub上的星标数在短短几天内就从几千暴涨至五万以上，引发了整个技术圈的某种FOMO（错失恐惧症）情绪。

OpenClaw（Clawdbot）的核心在于将几项常见能力串联起来：交互入口、指令执行、记忆存储与功能扩展。它更像一个“让指令能够运行起来”的框架，而非一个即装即用、开箱即令人惊艳的成熟产品。

它到底是什么：个人AI助理的核心定位

官方对OpenClaw（Clawdbot）的定位非常明确：个人AI助理 / AI智能体网关。你可以将其理解为一个“中央控制器”：

1. 入口接入：负责连接到你常用的聊天软件入口，如WhatsApp、Telegram、Discord、iMessage等，让你能在最熟悉的场景中使用它。
2. 指令编排：负责将你的自然语言指令转化为可执行的操作流程，例如发送消息、查询资料、运行脚本、写入文件或调用外部API。
3. 记忆管理：具备“记住你”的能力，能够将对话中的关键信息沉淀为长期记忆，并在后续的交互中加以利用。
4. 插件化扩展：其功能被拆分为一个个插件或技能，你可以按需安装，甚至指导它编写新的技能来满足特定需求。
5. 流程调度：协调以上所有模块，确保任务顺畅执行。

这里存在一个常见的误解：本地运行并不等于所有模型推理都在本地进行。

OpenClaw更像一个“运行在你设备上的智能管家”。真正消耗大量计算资源的模型推理工作，通常仍由OpenAI、Anthropic等云端大模型服务完成；你的本地设备主要负责消息收发、API调用、脚本执行等协调与控制工作。

因此，社交媒体上频繁出现的Mac mini晒单并非必需。任何能够运行Node.js的环境（如轻量级云服务器、家中常开的旧电脑）都足以支撑其运行。之所以有人倾向使用闲置的独立设备，一个重要的潜在原因是：鉴于其较高的操作权限，将其隔离在专用环境中运行确实更为安全。

简单来说，可以将其视为一个预置了大量技能的智能体，能够便捷地接入我们日常使用的办公聊天工具（如钉钉、飞书）。这或许正是其走红的关键原因之一：它让智能体的交互入口离用户更近，且被赋予了更大的操作权限。

为何爆火：无缝融入日常的聊天入口

许多AI工具给人的体验是：当你有需要时，才会特地去打开它，它更像一个独立的“工具箱”。不少用户可能都使用过聚合各类AI服务的网站。

OpenClaw这轮出圈，恰恰是因为它将入口重新嵌入我们每天都在高频使用的场景：即时通讯软件。在配置妥当并授予相应权限的前提下，你只需给它一句话，它不仅能回复信息，更能去执行具体操作，并将结果反馈回来。

它的走红，大概是以下几个特点共同作用的结果：

1. 入口自然：不强迫用户迁移到某个特定的工作台，而是无缝融入现有的日常沟通流。
2. 可主动触达：支持定时任务或基于触发条件主动发起对话（如推送早报、发送提醒、监控异常后告警）。
3. 具备长期记忆：并非“聊完即忘”，而是能够积累并理解用户反复提及的偏好与习惯。
4. 扩展能力强大：其通道、工具、技能、钩子、模型供应商及命令行接口均可扩展，核心保持精简而生态丰富。
5. 权限级别高：能够读写本地文件、执行系统命令、控制浏览器、调用第三方API（这也是争议最大的部分）。

OpenClaw本质上是一个“集成之作”，但它集成的重点在于功能链路而非用户界面。其实用性在很大程度上取决于你所连接的模型质量、技能丰富度，以及你愿意为其划定的权限边界。事实上，这类概念此前已有实践。

左手集成各类聊天窗口，右手配置丰富的技能库。但需要注意的是，智能体依靠循环机制来执行任务，因此在复杂任务中可能会消耗较多的Token。

与Manus的差异：云端打工人 vs 本地协作者

近来，Manus经常与OpenClaw一同被提及，但它们更像是智能体在不同场景下的两种“工作形态”。

可以将Manus理解为“云端打工人”：

1. 其主要工作在云端的沙箱或远程计算机中完成。
2. 擅长处理跨网站、跨平台的任务流程，例如订票、填表、信息搜集与批量整理。
3. 你将任务描述丢给它，它在云端模拟操作网页、运行脚本，最终将结果交付给你。

其显著优点是：你无需交出个人电脑的本地操作权限。 缺点同样明显：对于需要深度操作“本地文件、本地软件或个人工作流”的任务，它的处理就不那么顺畅。

而OpenClaw则属于本地协作型智能体，更像“坐在你身旁一同工作的数字分身”：

1. 以本地环境协作为主：你需要为其划定清晰的工作区、文件夹访问权限和安全边界。
2. 更强调人类监督：你可以在旁观察其执行过程，并在必要时随时接管。
3. 特别适合写作辅助、资料整理、代码协作及办公流程自动化等场景。

OpenClaw的核心设计理念是“人机协作”，而非“全自动放手”。总结来看，相较于Manus，OpenClaw提供的关键增量在于更贴近用户的聊天软件入口以及更广泛的本地操作权限。从技术实现角度看，这并无太高门槛，更多的差异体现在设计理念与权限设定的胆识上。

实践指南：从零开始搭建你的Moltbot

在国内网络环境下，若想使其在常用聊天软件中直接使用，不可避免会遇到账号或通道配置问题。对于新手，建议先按照官方文档在本地运行起来，再尝试对接Telegram、Discord等国际平台通道。

一个高效的方法是：直接将官方文档链接丢给具备代码理解能力的AI编辑器（如TRAE、Cursor等），让它引导你逐步完成安装。可以使用如下提示词：“根据以下官方文档，指导我逐步安装 Moltbot：https://docs.molt.bot/start/getting-started”

Windows用户在配置过程中可能更容易遇到网络相关问题，例如连接Telegram时因网关问题导致服务中断，但通常其在自带的Web会话界面中可以正常运行。

Mac用户的体验相对更友好一些。安装完成后，打开通道设置界面，你可以看到已配置的各类接入渠道：

以配置Telegram为例。你需要在Telegram中搜索并联系 BotFather：

按照BotFather的指引创建机器人、获取API令牌，然后将该令牌填写回Moltbot的配置文件中。

具体步骤在此不赘述（B站和YouTube上有大量手把手视频教程）。通道连接成功后，重启网关服务，打开官方的Web会话界面，即可看到与Moltbot的对话入口：

在此页面中，你可以直接聊天、下达指令、查看任务执行状态。左侧导航栏还提供了技能管理入口：

常见的技能类别包括：

• 信息整理：抓取网页内容、总结文章链接、输出结构化Markdown文档。
• 文件处理：批量重命名文件、整理目录结构、导出文件清单。
• 日常提醒：定时信息推送、待办事项提醒、生成日报或简报。

功能实测一：下载并保存图片到本地

我尝试让它帮我下载数张网络图片并保存到指定的本地文件夹：

在对应的本地文件夹中，确实能看到它成功下载的图片，这证实了其具备基础的本地文件系统操作能力：

前些日子，笔者探讨了AI浏览器作为流量入口的竞争格局。既然流量的主要入口正从传统浏览器向AI驱动的浏览器（或智能体）转移，那么其底层的检索与内容分发技术也必然发生根本性变革：从搜索引擎优化转向生成式引擎优化。这标志着传统的关键词布局与外链建设逻辑，其效力正在逐渐衰减。

GEO：Generative Engine Optimization，生成式引擎优化。

实际上，关于AI将取代搜索引擎的讨论由来已久。例如，三年多前笔者从事医疗AI工作时，产品演示后就常听到这样的反馈：能否替代医生尚不确定，但替代百度搜索看来是必然趋势。

现实情况也印证了这一点。目前，我仅在三种场景下会使用百度或谷歌：

1. 首先，检查网络是否断开；
2. 其次，确认VPN代理是否正常工作；
3. 最后，对AI给出的答案心存疑虑，需要追溯信息来源时。

众所周知，流量即意味着商业价值。当用户越来越频繁地向AI咨询产品信息或寻求问题解答时，一个核心问题便浮现出来：我们应如何**“优化内容以适配AI”**，从而使自家的产品或服务能在AI生成的回答中占据前列？如下图所示：

一个明显的趋势是：近期向我咨询GEO相关事宜的企业决策者显著增多，他们普遍关心两个问题：具体如何操作，以及需要投入多少成本？

要深入解答这个问题，或许需要从大语言模型的底层运作机制开始剖析。

GEO的底层逻辑

如图所示，大语言模型本质上是一个输入-输出系统。GEO的核心目标，是通过影响LLM训练时所使用的语料库，或其在回答问题时实时检索的外部知识库，最终达到影响其输出内容的目的。

这与传统SEO存在显著差异。搜索引擎的排名机制相对透明，它首先高度重视网站的权重，其次考量网页的一系列关键指标（如关键词密度、停留时间等）。这种清晰的排序逻辑使得关键词竞价等商业行为易于评估。

然而，LLM将海量语料“消化”后，其内部形成了一个复杂的黑盒。不仅内容发布者难以预测自己的内容何时会被引用，甚至模型开发者也可能无法保证输出的稳定性。因此，若企业主此刻急于在GEO领域投入大量资金，很可能需要承担较高的试错成本与风险。

我们有必要尝试揭开这个黑盒的一角。首要问题是：模型回答的内容究竟从何而来？

厘清内容的来源至关重要。答案主要集中于以下三个方面：

一、固化数据（模型参数内知识）

这部分指在模型预训练和微调阶段注入的数据，它们构成了模型认知世界的“世界观”与知识基石，犹如一座经过高度压缩的巨型图书馆。

试图通过“投喂”数据来影响基座模型，对于绝大多数公司而言是一个不切实际的目标。如果有人承诺能将网站数据直接编码进像ChatGPT这样的主流模型，这几乎可以被视作一种误导。

当然，这并非意味着完全无法介入。用于训练的数据要求极其苛刻，必须是高质量、权威性强的精品内容，其门槛本身就已非常之高，例如：在顶级学术期刊上发表SCI论文。

二、RAG（检索增强生成）

这是当前GEO最核心、最现实的优化战场。当用户提出问题时，AI会实时从互联网检索最新相关信息，并将这些信息作为“上下文”与用户问题一并提交给LLM，从而生成基于实时、相关信息的答案。

具体工作流程涉及意图识别与关键词解析，随后AI从索引库中查找相关网页。

需要特别注意，在此环节，传统搜索引擎的索引与排序逻辑依然发挥着重要作用，SEO的基础原则并未完全过时！

其内在逻辑是：AI会倾向于优先选择权威、可信、专业的信源（这意味着E-E-A-T原则的重要性依然凸显）。

注：当然，实际执行中可能出现偏差。例如，近期观察到某些模型在生成答案时引用了CSDN社区的内容，这引发了关于信源质量的讨论。

在该领域的核心策略，依然是在优质平台进行大规模的内容发布。至于“大规模”的具体标准，则因理解而异，本质上这仍是一种利用平台基础设施的内容分发逻辑。

关键洞察在于：对人类阅读体验不友好的文档格式，可能对AI处理非常友好。所谓对AI友好，通常具备以下特征：

1. 以问答对形式组织；
2. 内容海量、覆盖信息全面；
3. 采用短句结构，便于截断与引用；
4. ……

三、外链（链接内容）

如果用户问题或参考文档中包含了链接，模型也有可能对其进行访问和解读。然而，这种方式对于GEO目标的直接帮助通常较为有限。

综上所述，从模型内容输出的逻辑来看，核心原则似乎依旧围绕着E-E-A-T展开：

1. Experience（经验） - 新增且日益重要的维度
2. Expertise（专业度）
3. Authoritativeness（权威度）
4. Trustworthiness（可信度）

以上是对GEO基本原理的概述。接下来，我们思考第二个关键问题：对于AI领域的创业者而言，是否应该投身于GEO这趟快车？它当前的实际价值究竟如何？

GEO的价值与市场规模

关于GEO市场的具体规模，目前可查的直接数据相对有限：根据Valuates Reports的估算，2024年GEO相关服务市场规模约为8.86亿美元，预计到2031年将增长至73.18亿美元。

我们可以通过相邻市场的规模作为参考上下界：传统的SEO服务市场预计在2025年达到约749亿美元，2030年增至1273亿美元。

同时，预算迁移的信号已经清晰可见：美国的AI搜索广告收入预计在2029年达到259亿美元，占搜索广告总额的13.6%。

从需求侧渗透率来看，Google的AI Overviews功能在2025年3月已触发了约13.14%的搜索查询。

综上，GEO虽仍处于早期发展阶段，但已展现出可观的成长性：在AI搜索渗透率持续提升与营销预算结构性迁移的双重驱动下，它正从一项“增量试验”演变为独立的细分市场。

从数字上看，GEO的价值毋庸置疑。然而，这块市场蛋糕的大部分预计将被底层模型公司及其生态所占据，并且它们已经开始积极布局。

入口之争：从浏览器到任务调度系统

此前，我们讨论了AI浏览器作为下一代流量入口的趋势，也提及了像Atlassian以6.1亿美元收购Dia这类事件，它们都标志着流量入口正从传统浏览器向AI赋能的交互界面转移。

因此，科技巨头们纷纷加紧布局，争夺下一代的用户“入口”。并且，这种争夺不再局限于浏览器界面本身，而是深入到用户的工作流程、决策支持与深度集成层面。

在此趋势下，AI浏览器与AI智能体之间的界限正变得越来越模糊。

传统巨头的策略

拥有现有入口优势的巨头，正着力强化其既有生态：

1. 微软：将Copilot深度植入Windows操作系统内核，实现系统级的智能体调用。
2. 谷歌：通过Gemini重构Chrome浏览器，使搜索结果能直接呈现动态生成的3D模型演示等内容。
3. 苹果：将Siri升级为具备主动感知能力的智能体，可跨设备预测并响应用户行为轨迹。

新兴势力的冲击

与此同时，各类新兴力量也在不断涌入并冲击这一领域：

1. Dia浏览器：通过实时屏幕语义分析，在用户点击前即可预加载所需信息。
2. Manus智能体：首创“认知沙盒”技术，能够并行运行多个智能体以处理复杂任务链。
3. Nova Act SDK：提供跨平台的智能体运行时环境，旨在打破浏览器与本地应用之间的壁垒。

以上诸多领域是传统SEO难以触及的，但无疑是GEO必须关注的板块。从这个角度看，GEO所能覆盖的潜在流量范围实际上扩大了许多。

近期，上海交通大学发布了一篇题为《上下文工程2.0：上下文工程的上下文》（Context Engineering 2.0: The Context of Context Engineering）的论文。该论文试图系统性地梳理上下文工程这一概念的演进路径，在给出基本定义后，概括性地描述了从1.0到4.0的不同阶段划分。

通读全文，其论述较为抽象和晦涩。可以感受到，作者的核心意图是希望清晰地界定到底哪些信息构成大模型的有效输入。

为了完成这项定义工作，论文甚至追溯至GPT-3.0之前的时代，并最终给出了一个四阶段划分：1.0代表原始计算时代，2.0是智能代理时代，3.0对应人类水平时代，4.0则是超人类时代。

坦率地说，我并不推荐大家深入研读这篇论文，因为它可能难以直接解决我们面临的实际工程问题。论文的核心观点其实可以浓缩为一句话，尽管表述得有些拗口：

上下文工程的核心使命，是将人类高熵的意图转换为机器可理解的低熵信息。

为了让这句话更易于理解，我们可以稍作阐释。当前的大语言模型在设计上可以视为一套**“压缩-扩散”**体系。首先，用于训练模型的数据集本身就难以完整、精确地表征真实世界的复杂性；其次，正因为输入信息本身是残缺和不完美的，模型的输出自然也可能出现问题。

这并不完全是模型自身的缺陷，因为人类在交流中同样面临类似困境：

在实际对话中，只要交流双方的背景信息不同步，误解就极易产生（有时即便信息同步，误解依然可能发生）。

因此，一个基本的结论是：当前的大模型在理解现实世界方面存在“本质缺陷”。当然，论文中也指出，这个问题未来终将得到解决。强化学习之父Rich Sutton在其著名的**“苦涩的教训”**一文中不仅赞同问题可解，更提出了具体策略：依靠海量计算资源，简单而通用的方法终将胜出，并以AlphaGo的成功作为例证。

然而，模型迭代在现阶段确实遇到了现实的瓶颈。暂且不论高质量训练数据是否面临枯竭或难以获取的挑战，最根本的问题在于，现实世界的复杂度远非围棋棋盘或文本序列所能比拟。计算力必须作用于正确的架构之上，才有可能实现真正的突破。

当前的LLM，其本质是基于海量文本训练的“词序列条件概率模型”。它擅长学习“在特定上下文环境下，下一个词最可能是什么”，这体现了一种强大的统计拟合能力，但距离真正的理解与逻辑思考尚有距离。

从这个角度看，前文提到的某些定义或许意义有限。在实际工作中，我们依然需要逐个调试提示词，进行大量工程实践。因此，这篇论文并未旨在解决我们实际工程应用中的难题，但它的出现及其论述方式，确实引发了我对相关领域现状的一些思考。

AI与数据的交互：复杂项目的核心挑战

真正参与过复杂AI项目开发的工程师都会深刻理解，在AI应用层，最艰巨的任务往往是：如何实现数据与AI的高效、精准交互。

例如，我曾研究过数个生产级别的复杂AI项目，其核心代码量可能仅在一万行左右，但所依赖和整合的知识库却规模惊人。这种强烈的非对称性导致了一个普遍现象：在复杂AI项目中，团队80%以上的开发时间都投入在处理数据相关的问题上！

正因如此，业界对于复杂AI项目中AI与数据交互的标准化范式与最佳实践抱有极高的关注度。不过，我个人对堆砌各种新名词（如短期记忆、长期记忆、语义记忆、情景记忆等）的做法持保留态度。

甚至，我曾对“上下文工程”这个术语本身也感到不适。在我看来，与模型的交互本质极为简洁：仅包含一套输入和输出（即API调用），除此之外别无他物：

基于我过去三年完整参与AI项目开发的经历，从1.0阶段的“百模大战”（大家竞相卷训练），到2.0阶段的“套壳时代”（普遍应用简单的RAG技术），再到当前的3.0阶段（开发者开始依据数据构建复杂的思维链，即CoT），其中的关键分水岭在于模型是否具备识别与遵循CoT的能力。

在提示词工程主导的阶段（1.0和2.0），面临的尴尬局面是模型理解能力有限且上下文长度不足，往往无法基于正确的输入获得理想的输出。因此，在AI与数据交互的设计上，大家普遍采取保守且简单的策略。

随着模型推理能力的显著进步，现在的模型已经能够很好地理解并执行CoT。正是在此基础上，构建复杂AI应用才成为可能。然而，这也意味着技术路径开始出现真正的分叉，其核心区别在于：CoT所包含的推理步骤及其所需的数据，究竟是由开发者强控制提供的，还是由AI自主生成的？

更具体地说，关键在于：提示词中运用的是人为设计的CoT，还是由AI自行衍生的CoT？

两种CoT范式的分野

首先，何为“人为CoT”，何为“AI CoT”？ 下面这张图或许能提供一个初步的说明：

但要彻底厘清两者的区别，可能需要从AI项目的构建目标谈起。以我之前开发的“群聊分身”项目为例，其目标是在管理学科领域，构建一个能模拟我的思维方式与表达习惯的智能体，使其能够替我完成管理相关的咨询工作。

其中，“模拟我的思维方式”包含两个层面：

第一，KnowHow（技术诀窍）。即我究竟是如何思考的？这实际上是一套内化于我大脑中的决策算法，需要将其外化翻译出来，其具体的产物就是“工作流程”（Workflow）或“标准操作程序”（SOP）。

第二，数据。SOP无法在真空中执行，它需要调用我大脑中存储的管理领域相关知识，这些知识此前已被我整理成约40篇的管理课程文章。

综上所述，这套CoT实质上是 “算法（SOP）+ 数据” 的组合体。它也正是我们所说的 “AI与数据的交互范式”。

这种交互范式对我们的工程能力提出了明确要求：能够获取数据、能够获取正确的数据、能够获取充足的数据（包括完整的关系链与逻辑链）。在满足这些基本要求的前提下，才谈得上对成本与效率的优化，例如避免获取冗余数据。

所谓人为CoT，即指由开发者自行构建这套SOP与数据结构；而AI CoT的思路则是：何必如此费力？让AI来协助甚至自主完成SOP和数据的组织工作。

这样的表述可能仍有些抽象。我们可以以大家最熟悉的RAG（检索增强生成）场景为例，简要描述其演进逻辑：

范式原理的进一步阐释

在人为CoT的方法论中，问题求解的步骤与逻辑完全由人类开发者预先设计和编排。

我们需要将内在的思维流程（KnowHow）翻译成显式的SOP或Workflow，并严格控制模型严格按照这些既定步骤执行。例如，面对一个复杂任务，我们可能预先定义：“第一步执行分析A，第二步根据A的结果执行操作B，第三步查询数据库C，第四步综合给出最终结论”。模型在这种模式下，更像是在执行一个人类预先编写好的精密脚本，每一步需要何种数据、进行何种处理都被明确规定。

AI CoT方法则将这种规划与控制权在很大程度上交还给模型本身。我们仅向模型提供一个总体目标或高层级提示，由它自行决定如何分解问题、采取哪些具体的推理步骤。模型可能在内部自主生成一系列链式思考（类似于人类在脑海中进行推理的过程），自主决定执行的先后顺序。简而言之，人为CoT是我们替模型规划好每一步路径，而AI CoT则是为模型设定目标，让它自己去探索和开辟路径。

相应地，在数据交互层面，两者也存在显著差异。

在人为CoT范式下，模型推理所需的知识片段是由开发者显式、主动提供的。也就是说，我们确保模型在推理时能够“看到”所有必需的低熵（高确定性）信息。一个典型例子是经典的RAG流程：我们先从知识库中检索出与问题相关的文档片段，经过人工整理或简单拼接后，将其置入提示词中，再让模型基于这些给定的内容生成答案。整个过程中，检索什么、提供什么、以何种顺序提供，都主要由人为决定。

AI CoT则尝试让模型自己去主动“索取”数据。模型在推理过程中，可以自行意识到需要某些额外信息来推进思考，然后自主调用外部工具（如搜索引擎、数据库查询接口、函数API等）来获取新信息，再基于新信息继续推理。换言之，在AI CoT模式下，模型不仅思考“下一步该做什么”，还会自行判断“我需要什么额外信息”并主动尝试获取，使得数据与AI的交互过程更具自主性和动态性。

两者之间最根本的区别之一在于工程上的可观测性与可控性。

AI CoT的简单实现逻辑

阐述完基本原理后，我们来看看这两种思维链范式在实际项目中是如何运作的。人为CoT的流程大家可能比较熟悉，这里我们将重点介绍AI CoT的实现思路。我们继续以大家熟知的RAG场景为例，说明其演进逻辑。

实现AI CoT的关键在于：引导模型输出其内部的思考过程，并为模型提供工具接口，让它能够自主发起检索动作。

在实际运行时，模型会首先接收到用户的问题，并可能产生类似“Thought：我需要先理解问题的核心，并确定缺失哪些关键信息”的思考。接着，它可能输出一个“Action：搜索关于[特定概念X]的详细定义或最新资料”。系统在监听到这个动作指令后，便执行一次知识检索操作，并将检索结果作为新的上下文信息反馈给模型。

首先，为什么我想认真做这次 AI Coding 验证?

如今大家对 AI Coding 已经相当熟悉了。无论是代码补全、编写工具函数、搭建一个新页面，还是完成一个演示Demo，它大多都能胜任，而且很多时候表现得相当不错。

因此，如果仅仅讨论“AI是否会写代码”，这个议题的实际探讨价值已经不大。 至少在局部编码这一具体任务上，它的可用性已经经过了反复验证。

然而，我一直更想探究的是另一个问题：

如果我们把时间线拉长，不局限于让它补充某一段代码，而是让它真正投身于一个完整的交付流程。

从需求理解开始，到功能实现，再到验证与收尾，它目前究竟能做到什么程度？

换句话说，我这次真正想要验证的，并非AI能否辅助写代码，而是它是否有可能从局部参与演进到完整参与交付。

这个问题，表面上看只差一步，实则天壤之别。

局部参与，验证的是它的编码能力；而完整参与交付，验证的则是在一个完整任务链路中的稳定性：AI Coding能否理解任务边界，能否按照既定要求推进，能否在给定的约束下把事情做完，而不是仅仅产出几段“看起来还行”的代码。

为了更清晰地审视这个问题，我并没有直接使用现有的业务项目进行尝试。

一方面，业务项目本身不适合公开展示；另一方面，我也不希望将业务复杂度、历史遗留问题以及真实环境的诸多限制混为一谈，导致最终难以判断，究竟是AI的能力到达了边界，还是测试条件本身不够纯粹。

因此，这次我专门搭建了一个脱敏的演示项目，并刻意将验证过程拆分为三个典型场景：

1. 场景一：从零到一。直接要求AI按照指定要求搭建一个新项目，并完成一个最小可行功能。
2. 场景二：迭代加需。在已经搭建好的项目中继续添加新需求，模拟更贴近日常开发的迭代过程。
3. 场景三：老项目攻坚。模拟一个文档不全、约束模糊的老旧项目，先补充必要的工程规范，再进行功能开发。

这三个场景串联起来，基本就构成了我想验证的那条完整问题链：今天的AI，究竟能不能真正参与一段完整的交付过程，而不仅仅是把局部编码做得更快？

如果先给出结论，我目前的判断是：

AI Coding 已经不再仅仅适合写Demo、补函数、起页面了。

在约束清晰、边界明确、验收方式可执行的前提下，它已经能够参与相当一部分真实的交付工作。

但这个结论并非无条件成立。从本次实践来看，它更适配以下三类项目场景：

1. 全新项目： 适合先建立基线，再落地最小可行功能。
2. 结构相对清晰的已有项目： 适合在边界明确的前提下进行迭代开发。
3. 约束缺失但尚可运行的老项目： 适合先补充最小工程规范，再继续后续开发。

如果用更直接的方式表述，我现在会将AI编程的可用范围理解为：

1. 做Demo、局部编码、小功能实现： 技术已比较成熟。
2. 做新项目初始化和最小功能闭环： 可以胜任。
3. 做已有项目中的小到中等规模迭代： 可以胜任，但前提是任务边界需事先界定清楚。
4. 做老项目直接功能开发： 不建议直接开始，更适合采取“先补规范，再做功能”的策略。
5. 做高不确定性、强业务耦合、约束大量依赖隐性经验的任务： 表现仍然不够稳定。

换言之，AI已经能够参与交付，但它更像一个需要被明确定义、有效约束、并得到充分验证的协作对象，而非一个将需求丢过去就能自动完成收尾的全能开发者。

下面，就是我为了验证这个判断，专门设计并执行的一条完整实验链路。

第一部分：输入与模型——决定结果的关键因素

——真正影响结果的，往往不是模型，而是输入

在刚开始进行这次实践时，我的想法比较直接：既然要验证AI能否承担更多工作，最自然的方式就是将任务交给它，让它尽量推进，我再进行检查、修正和收尾。

简单来说，就是先看看它能“接住”多少。这种用法在许多小型、独立的任务上确实没有问题，甚至常常让人觉得非常顺畅。

尤其是那些上下文简单、边界清晰的事情，比如补充一个函数、编写一个独立页面、修改一个相对孤立的小功能，AI通常能快速给出不错的结果。

也正因如此，在初期很容易形成一种印象：似乎只要需求描述得差不多，后续的事情就可以交给它了。

然而，当任务变得稍微完整一些时，问题便开始逐渐显现：

1. 有时功能虽然实现了，但一些关键细节与预期不符。
2. 有时代码可以运行，但实现方式与项目原有的组织风格不统一。
3. 还有些情况是，我们以为理所当然的前提并未被明确写出，于是AI会自行“脑补”，而它补全的内容未必是我们真正想要的。

后来我逐渐意识到，这其中最棘手的地方，往往并非“它把代码写错了”，而是很多偏差在代码编写之前就已经发生。更准确地说，许多问题出现在“理解任务”这一初始环节。

当任务仅限于局部编码时，这个问题尚不明显。因为上下文短、目标集中，即便AI理解不够完整，影响范围也通常有限。

然而，一旦任务开始变长，开始涉及需求边界、功能约束、验收标准、回退机制等内容时，如果输入本身不完整，后续过程就难以稳定。

也正是在这个阶段，我越来越确信：决定结果质量的关键，不只是模型能力，更在于我们究竟为它提供了怎样的输入。

如果输入只是一个方向性的模糊描述，那么AI在很多时候所做的并非执行，而是在“猜测”。它一边编写代码，一边补充那些我们未曾明确说明的前提假设。

问题恰恰在于：那些没有被明确写出来的前提，往往才是决定结果是否稳定的真正因素。

因此，我后来的调整重点，不再是“如何把提示词写得更加华丽”，而是另一件更为基础的事情：如何将任务定义得更加完整。

我不再满足于只提供一个需求描述，而是尽量将目标、边界、规则、验收方式等内容提前写清楚，让AI面对的并非一个模糊指令，而是一份相对明确的执行说明书。

在我们探讨AI项目的技术选型时，一个常见且关键的问题是：构建AI应用应该选择哪个框架？ 讨论中频繁出现的名字包括Coze、Dify、FastGPT、n8n，以及LangChain。

对于那些偏好深度控制和“亲手编写代码”的开发者而言，拖拽式的低代码平台往往并非首选。在众多选项中，LangChain通常被认为是技术层面更优的选择。

LangChain与LangGraph作为当前主流的AI Agent开发框架，为开发者提供了一套从基础组件封装到复杂流程编排的完整工具链。随着LangChain 1.x与LangGraph 1.x版本的日趋成熟，整个技术栈的生态分工与工程化实践路径也变得更加清晰。本文将深入剖析这两个框架的核心概念、演进历史、核心功能及其实际应用场景。

LangChain的发展历程

LangChain由Harrison Chase于2022年10月创立，最初定位为一个专注于“使用大语言模型构建应用程序”的开源框架。彼时，ChatGPT刚刚掀起全球的AI热潮，开发者们急需一种能够快速连接LLM与外部数据源、工具及API的解决方案。

一、抢占先机

LangChain的诞生恰逢其时。它本质上是对一系列LLM应用最佳实践的抽象与封装，提供了几个关键的抽象层：

1. Models（模型）：对各种大语言模型进行统一封装，提供标准化的推理与对话接口，构成系统的基础能力层。
2. Chains（链）：将多个独立组件串联起来，形成可执行的工作流。
3. Tools（工具）：为LLM提供调用外部能力（如API、数据库）的接口。
4. Agents（代理）：实现让模型自主决策、调用工具的执行机制。
5. Memory（记忆）：负责管理对话历史与中间状态，使模型在多轮交互中保持上下文连贯性。

该框架极大地简化了LLM应用的开发流程，使开发者能够快速搭建问答系统、文本摘要工具和对话机器人等。在早期阶段，许多高级功能并不突出，可以简单地将LangChain理解为实现RAG（检索增强生成）的便捷工具。

然而，LangChain的早期架构采用了**单体式（Monolithic）**设计，所有组件紧密耦合。这种设计虽然便于快速集成，但也带来了扩展性方面的挑战。因此，许多团队在实际项目中更倾向于参考其设计思想，而非直接使用其全部代码。

二、快速迭代

如前所述，在ChatGPT早期，模型本身能力有限且算力成本高昂，因此在生产环境中直接使用LangChain的情况并不普遍。但从2023年开始，模型能力几乎每半年就有显著提升，LangChain也随之快速迭代，不断弥补自身的短板，例如：

1. 模块化设计更加合理，各组件能够灵活组合。
2. 支持了更多模型提供商（如OpenAI、Anthropic、Google等）。
3. 生态系统日益丰富，社区贡献了大量第三方集成。

不过，这一时期的AI开源框架普遍面临一些共性问题：

1. API变更频繁，破坏性更新较多。
2. 代理（Agent）逻辑分散，难以维护复杂的业务流程。
3. 状态管理能力相对薄弱。
4. 对于需要长期记忆和状态持久化的应用支持不足（这不仅是框架问题，也与当时模型能力有限有关）。

值得一提的是，如今大热的智能体（Agent）概念在2023年仍处于萌芽阶段。当时，AgentExecutor是实现智能体的核心组件，它通过一个**硬编码的循环（Hardcoded Loop）**来执行ReAct逻辑。这种“黑盒”设计使得开发者很难定制复杂的执行流程，例如加入人机交互或错误重试机制。

三、应对复杂需求：LangGraph登场

随着模型能力的持续增强，AI项目的复杂度也水涨船高。LangChain团队意识到，简单的链式结构已无法满足高级Agent开发的需求。

因此，LangGraph作为一个专门的编排框架应运而生。它的核心设计理念包括：

1. 基于图结构：采用节点（Node）、边（Edge）、状态（State）三大核心抽象。
2. 支持复杂流程：能够处理循环、条件分支和并行执行。
3. 状态持久化：通过检查点（checkpoint）机制实现状态的保存与恢复。
4. 人工介入：支持“人在回路”（Human-in-the-Loop）的交互模式。

这依然是一个过渡阶段。直到2025年，模型能力真正达到了新的高度，LangChain 1.0 才正式发布。

1.0正式版发布

2025年10月，LangChain 1.0与LangGraph 1.0同步发布，这标志着这两个框架进入了首个稳定版本阶段。以“1.x”开头的版本号通常意味着更高的稳定性，开发者可以更放心地将其用于生产环境。

在后续发展中，版本稳定性将得到更多重视：与早期的快速迭代相比，1.x阶段更强调API的向后兼容性与平滑的迁移路径，从而降低维护成本。同时，LangChain与LangGraph的定位边界也更加清晰：

1. LangChain：更偏向于应用层的组件与集成，强调易用性和快速拼装。
2. LangGraph：更偏向于底层的流程编排与状态管理，强调可控性、可恢复性和可扩展性。

接下来，我们简要探讨一下1.0版本与旧版本的主要区别。

1.0 版本的重要特点

首先是整体架构上的重大变化。在1.x生态中，一个明显的趋势是：LangChain更聚焦于提供应用层的能力与集成，而LangGraph则更适合作为流程编排与状态管理的“底座”，被引入到复杂的Agent场景中。

在实际项目中，二者的组合方式会因具体版本、编程语言包和团队选型而有所不同，但整体方向是让流程控制变得更加显式、更易于维护。

这一架构转变使得LangChain从一个流程执行框架，演进为面向开发者的应用层SDK，带来了以下显著优势：

1. 运行时能力下沉，职责边界更清晰。
2. Agent执行模型得到统一，减少了隐式行为。
3. 具备了更强的可扩展性与可观测性。
4. 为复杂Agent场景提供了工程级别的稳定性保障。

其次，在应用层的易用性上，LangChain 1.0展现了强大的应用性和生态整合能力：

1. 提供了高级API抽象，例如create_agent等便捷的Agent构建接口。
2. 内置了丰富的可复用组件，包括：
   • Agent构建工具
   • 预构建的Chains（任务链）
   • Retrievers（检索器）
   • Tools / Tool Calling 抽象
   • Middleware（中间件/回调）机制

在编排层，LangGraph作为面向系统的统一Agent运行与编排引擎，是LangChain 1.0的核心基础设施，扮演着“总控制器”的角色：

自去年以来，我所处理的事务变得异常繁多且琐碎，需要寻找研究课题、撰写文章、开发培训课件、进行客户拜访、出差提供咨询服务、完成各类售前支持……

此外，还需要分出一部分精力进行团队管理。然而，事务堆积的最终结果往往只有一个：许多重要事项被无意中遗漏。

解决这个问题的方案听起来很简单：把所有事情都记录下来。而“记录”二字正是整个管理体系的精髓所在。实际上，待办事项清单（Todolist）配合有效的提醒机制，能够解决80%以上的事件管理难题。

更进一步说，待办清单与提醒本身就是项目管理的核心。换言之，任何项目（或事件）的管理流程，都应围绕一个清晰的待办清单来构建。

在此基础之上，让我们审视一下管理工具的演进逻辑。以我自身为例，最初阶段，在钉钉或飞书文档上创建一个简单的个人待办清单完全足够。它的优势在于轻便且入门门槛极低：

然而，随着需求的变化，这种简单的方式逐渐难以满足要求：

1. 个人任务与团队任务的差异：管理自己的任务相对容易，但随着团队成员增加，如果不去密切关注他们任务的执行状态，很容易出现三种糟糕情况：任务目标在执行中变形、交付时间严重延迟、或者任务被彻底遗忘。
2. 信息记录的局限性：早期纯文字版的待办事项，所能承载的背景信息过于有限。这导致一个月后，连我自己都可能无法准确回忆起某个任务的具体细节，更不用说进行高效的团队协作了。
3. 规模化协作的需求：当工作进入规模化协作阶段，任务信息需要更加丰富和标准化。渐渐地，我们会发现简单的待办清单模板已经不再适用。

于是，在这个需求背景下，面向团队的轻量级项目管理工具应运而生。直观来看，它就是一个清晰的团队任务看板。例如，Trello所提供的看板视图就非常出色：

你可能会问，这类工具好不好用？它们确实不错。但在人工智能时代，它们似乎总显得有些不足。一个比较突出的问题是：所有的待办事项都需要我手动逐个录入。例如：

1. 我经常需要阅读大量文章和论文（尤其是公众号推文），并希望将其有价值的部分记录下来。目前最快捷的操作路径是直接转发到我的微信小号，这个过程完全可以由AI协助整理。
2. 我偶尔在抖音、视频号上看到有启发的短视频，也需要跟进学习。这个板块涉及到视频文案的提取与归档。
3. …（其他类似场景）

不难看出，传统的待办清单系统本身并没有问题，但我迫切需要一个专属的项目管理小助理。这个小助理需要能帮我处理各种“杂事”，比如：

1. 自动将微信聊天中有价值的内容整理成待办事项。
2. 自动抓取抖音视频，将其整理为待办项，并提取其中的文案甚至关键画面，方便我后续深度阅读。
3. 对长篇论文进行自动化要点总结。
4. …（其他自动化处理需求）

基于这样的构想，整个系统的架构蓝图便清晰浮现：

可以看出，在核心的待办清单系统搭建完毕后，接下来的挑战并非技术上的根本性难点，而在于需要持续地集成和补充各种实用的工具（Tools）。为了让大家有更直观的感受，我们以“抖音文案抓取”为例，简单展示其实现思路。

抖音文案抓取

实际上，在扣子（Coze）等AI平台上已有现成的类似插件，可以直接收集指定博主的信息，并操作飞书多维表格等。这正是利用平台生态的优势，能够省去大量重复开发工作，我们只需在其基础上进行适当封装即可。

单就视频文案提取这一功能而言，可以结合多维表格来实现。例如，定义清晰的输入与输出格式：

输入：  
2.82 复制打开抖音，看看【全球速探的作品】# 国际局势 # 军事科普 # 俄乌冲突 # 全球... https://v.douyin.com/Gal24TqZjjo/ nqr:/ 09/25 J@V.LW  
  
输出：  
11月13日早上的情报，现在他来了第一条情报，乌克兰宣布停止和谈，俄军17万大军押进红军城，发起新一轮猛攻  
......

最终的运行结果稳定且符合预期：

在此基础之上，只需进行一些简单的API对接工作，并部署一个微信机器人，即可形成完整流程：

进一步拓展思路，由于我经常出于选题需要关注大量不同平台的博主（包括公众号、视频号等），因此会对他们日常发布的内容进行系统性整理和收集。其呈现形式大致如下：

所有信息收集的最终目的，都是为了服务于后续的快速学习与知识吸收。下面，简要介绍一下具体的工作流实现过程。

工作流实现过程

Coze平台提供了丰富的插件库，因此在大多数情况下我们无需重复造轮子。例如，平台已有插件可以直接用于收集指定博主的信息。

第一步：建立多维表格字段 设计多维表格的字段结构，确保每个字段都与后续工作流中的操作步骤一一对应。

第二步：在扣子平台搭建工作流 利用平台现有插件（如redirect插件）将我们分享的复杂链接转换为标准URL。 像下面这种格式的链接无法被直接处理，需要先进行转化：

1.58 复制打开抖音，看看【贪玩歌姬小宁子的作品】2026年做自媒体是什么样？ 小宁子工作室 Roo... https://v.douyin.com/ODMQ4i9LRaI/ 03/14 mdn:/ B@t.rR

将链接转化为正常可访问的URL后，即可使用专门的插件对视频内容进行文案处理。这一步通常需要申请并使用一个AI服务的API密钥（例如阿里百炼）：

1. 获取你的API密钥（格式如sk-XXXXX）。
2. 将其填入工作流对应的api_key配置项中。

近期，不少参与学习的同学陆续步入面试环节，他们频繁遇到的一个经典问题是：应当如何评估RAG（检索增强生成）系统的实际效果？

这个问题看似基础，却极易回答失误。它所涉及的解决方案，正是AI项目实践中的难点所在。即便是已经亲手搭建过RAG系统的开发者，也可能对此感到困惑。如何给出令人满意的答案，正是本文将要深入探讨的核心。首先，让我们从宏观视角进行审视：

RAG效果评估本质上隶属于产品评测框架下的一个技术性子领域。其核心构成包括测试标准、评估数据集以及具体的测试方法论。结合过往的项目经验，我们可以勾勒出如下全景图，供大家先建立初步认知：

对于一个准备投入生产环境的RAG产品而言，通常需要建立两套评估标准：一套服务于产品体系，另一套则聚焦于技术体系。我们首先从技术体系入手进行分析。

请注意：在实际项目开发中，产品层面的评估体系往往占据更重要的地位。

一、技术体系的评估指标

我们此前讨论过，复杂AI项目的挑战主要源于三个方面：

第一，如何将零散的认知系统化地整理为结构化知识；或者，在知识已然存在的前提下，如何高效地组织相关数据。

第二，数据应当如何与AI模型进行交互，以确保每次推理都能获取到最相关的信息。当发现因数据不足导致AI输出不佳时，应如何利用生产环境中产生的真实数据来反馈并优化知识库？这正是我们常说的“数据飞轮”系统，它属于数据工程的一个分支。

第三，则是对用户意图的精准识别。

单就面试官的考察意图而言，他们通常更关注上述第二点。而若将这一点展开，又可细分为三个层面：

1. 每次检索能否准确命中相关数据；
2. 检索到的数据是否“合适”，此处的“合适”包括数据量是否过多或过少。数据过多虽会增加Token消耗（成本），但更关键的是可能干扰模型判断；数据过少则容易导致信息不全，影响输出质量。
3. 生成内容是否正确，这是在检索准确、数据组织得当的前提下，模型最终输出是否符合预期的最终检验。

然而，一个完整的RAG系统并非孤立的模块。如果底层的知识结构本身存在问题，那么无论是检索质量还是生成质量都会受到牵连。不过，若仅为了回答面试问题，我们可以将衡量指标简化为三个主要部分：

1. 检索评估；
2. 关系链（知识结构）评估；
3. 输出评估。

1. 检索评估

检索评估的核心指标是召回率，即针对一个具体问题，系统能否成功检索出所有相关的知识片段。为此，通常需要预先准备一个评测数据集，其基本格式如下：

用户问题 Q
正确应该命中的文档或段落 ID（一个或多个） D*
或者
正确该命中的数据

这里需要特别强调文中的 “或者” 。当前许多人想当然地认为RAG必然与向量数据库强绑定，但在笔者实际接触的项目中，至少有三分之一的应用场景其实与向量库无关。

举例来说，假设在一个AI管理知识库中，存在以下用户提问：

用户：我最近在工作上感到非常疲惫，请问是什么问题导致的啊？
# 这里预期的答案应关联到以下数据
1、副班长缺失对应数据；
2、员工精力不足对应数据；
3、能者多劳对应数据；
...

在此场景下，既可以通过向量库实现，也可以不通过向量库实现，具体取决于哪种策略能达到更优的效果。

不过，我们此处不深入讨论技术方案，仅聚焦于评估指标。那么，核心便是直接计算召回率：

1. 在前 K 条检索结果中，至少命中一个标准文档/段落的问题所占的比例；
2. 对于一些复杂场景，可以考察多个命中目标（例如，一个问题需要同时命中 2 篇不同的指南文档才算合格）。

此外，一个关键点是，评测问题必须覆盖真实的用户提问分布。这意味着在构建评测数据集时应力求全面，既要包含常见的FAQ（常见问题解答），也要涵盖长难问题、模糊表述、甚至包含错别字的问题。否则，很可能出现测试环境表现优异，但一上线面对真实用户就效果骤降的情况。

例如，对于语义相似的不同表达，系统的测试结果应当保持一致：

“肾结石的检查项目有哪些？”
“查肾结石一般要做哪些检查？”
“肾结石要做啥检查啊？”

上述问题，都应当指向相同的正确答案。

2. 关系链评估

简单的RAG系统通常完成第一步检索即可。但对于稍复杂的RAG应用，则必须处理关系链问题。系统需要能够根据用户问题，正确地提取出与之关联的所有相关信息。如果无法做到这一点，同样属于失败。例如：

用户：我得了肾结石，一分钟给我所有的信息！
# 这里就不能只提供肾结石的基础信息，必须结合语境给出所有相关信息
肾结石的检查项目...
肾结石的症状表现...
肾结石的缓解办法...
肾结石的治疗方案...

关于如何测试关系链，方法依旧与上述类似：紧密结合实际项目需要完成的具体任务，构建出针对性的正确测试数据集。

3. 生成评估

前面两个部分确保了：喂给大语言模型的数据是可靠的。

在输入数据正确的前提下，模型的输出通常不会出现大的偏差。然而，在实践中也确实存在 “正确的输入未能产生正确的输出” 的情况。

从生产级要求出发，输出评估主要考察三个方面：

1. 真实性：是否存在胡编乱造、脱离检索证据的情况；
2. 实用性：是否真正解决了用户提出的任务或问题；
3. 安全性：尤其是在医疗、金融等高风险场景下，内容是否安全合规。

现阶段对模型输出的最高要求可以概括为：CoT（思维链） + 可溯源。即，在模型的提示词部分严格要求其必须遵循 “像我这样思考” 的推理过程；而可溯源则要求输出中的每一句关键陈述都能找到其出处。例如：

根据当前的市场反馈，多数公司的AI应用仍停留在使用Coze、Dify等平台搭建基础知识库的阶段。因此，若能深入掌握上述任一主题，在求职市场上便已具备显著优势。

然而，若希望进入专注于“真AI应用”的团队，或应对技术深度要求更高的面试，仅掌握单一知识点可能显得不足。此时，将Agent与RAG两者融合的 Agentic RAG 概念便应运而生，它能显著提升系统的智能化水平。

Agentic RAG 自诞生之初，便被视为一种更高级的解决方案，随之而来的一种常见论调是 “RAG已经过时”。

就在昨日的一次AI闭门讨论会上，这一观点再次出现：一位资深投资人士在推崇Agent的同时，不自觉地质疑RAG的价值。但若深入追问其参与过哪些深度RAG项目，往往又无法得到实质性的答案。

尽管如此，我们仍需厘清当前所谓的 “RAG过时论”究竟指什么。本质上，大语言模型仅具备输入和输出接口，任何在输入前对问题进行干预处理的过程，广义上均可被视作RAG的范畴。从这个角度看，RAG作为一种范式本身并不过时。

重新审视“RAG过时论”

技术迭代中，不好用的方法被淘汰是共识。这里所指的“过时”，通常是针对前几年兴起的 “朴素RAG” 模式： 进行一次向量检索，将Top-K的文本块直接塞入提示词，最终导致“垃圾进，垃圾出”。

这种模式最突出的问题是上下文割裂：在对原始文档进行分块时，破坏了文本的完整性，例如切分了表格、打断了论证逻辑，最终导致信息丢失。

于是，一个自然的疑问产生：既然分块导致问题，而如今模型上下文窗口极大（百万级上下文也即将普及），是否可以将整个文档直接交给模型，从而避免分块？

答案可能并非如此。虽然长上下文可以缓解因分段造成的语义割裂，但背后的检索效率与精度问题依然存在，因此分块仍是必要步骤，主要原因如下：

主流文本嵌入模型有其最佳的编码长度（通常是中等长度）。将一本数万令牌的书籍编码成一个向量，就如同用一句话概括全书，大量细节必然丢失，导致检索精度急剧下降。这一点或许需要进一步解释：

每个基座模型都提供嵌入接口，它并不关心输入量的大小，无论是200字还是2万字，最终都会将其压缩为一个向量。结果是：输入文本越长，承载信息越多，压缩就越剧烈，生成的向量往往更“平均化”，从而导致检索分辨率降低。

信息在传递过程中具有扩散和压缩的特性，并非越多越好，可参考下图：

正因如此，工程领域出现了许多技术进行“迁就”，例如《树搜索RAG系统：PageIndex》所介绍的方法。

然而，当文档结构化做到这种程度时，我们完全可以为每个子文档先归类，再为其生成一段摘要描述。当问题到来时，可先通过穷举匹配进入具体类型，再利用小型模型判断摘要的相关性，这种方法效率很高，有时甚至可以不再依赖向量数据库。

因此，在真实场景中，向量数据库并非唯一选择，多种技术常常混合使用。

随着智能体需求的激增，模型侧对智能体的基础支持进行了大量优化，包括提出了MCP、Skills等概念。可以说，工具链中最令人头痛的问题已得到相当程度的解决；明年，模型很可能在记忆侧发力，给出更优秀的工程策略。

举例来说，理想的知识数据处理流程是：将文档全量喂给某个智能知识库，当进行知识检索时，该智能知识库能够给出准确答案。过去，大家使用向量数据库进行语义检索，但效果不佳，需要叠加大量工程技术才能勉强实现。后来人们发现，小型模型配合结构化知识库也能完成语义检索，何必非用向量数据库？于是，整个工程范式发生了很大变化。

如何将这类复杂的工程技术内化并封装，如何将向量检索技术内置到模型黑盒中，这可能是下一代模型技术需要突破的命题之一。

在大致解释了何为“过时的RAG”（尽管我们并不完全清楚批评者具体所指）之后，让我们回归到Agentic RAG的主题。

Agentic RAG：定义与核心理念

为了获得更好的AI应用体验，我们在工程层面进行了诸多优化，包括：多源知识整合、更动态的上下文验证、与外部工具的深度融合等。

当Agent概念兴起后，大家发现可以利用计算成本（Token）来换取架构的简化，通过多次循环迭代的增量成本，来解决工作流泛化的工程难题。

于是，便有先行者思考，是否可以引入 Agentic RAG 的概念，使其能够进行精细的计划、多步骤推理，并充分利用外部工具来处理复杂问题。

总而言之，所有冠以“Agent”之名的技术，其出现都是为了降低工程复杂性，是一种用（计算）时间换取（系统）架构简化的范式。

Agentic RAG的核心工作是：在多个文档和数据源之间比对信息、提炼总结，从而产出全面且准确的答案。换言之，它实现了从被动检索到主动推理的转变，将静态的问答过程升级为动态、智能的知识探索过程……

注：可以看到，但凡沾上“Agent”字样，描述就显得颇为玄妙。

下图展示了传统RAG（上）与Agentic RAG（下）的流程对比：

Agentic RAG采用循环迭代流程：引入Agent对查询进行分析和决策，例如决定是查询内部知识库还是进行网络搜索，然后对检索结果的相关性进行评分。如果结果不理想，Agent会改写查询重新检索。如此反复，直到收集到足够有用的上下文，再由大语言模型生成可靠答案。

换句话说：Agentic RAG 是一种泛化能力很强的工作流架构，能够让模型自主获取更优质的数据。

我知道大家可能仍有些困惑，让我们看一个之前的实际案例。

从实践案例看传统RAG的局限

成都某大型律师事务所曾有一个需求： 在审阅一份800页的跨境并购协议时，需要快速定位数十个关键条款（如赔偿、终止、担保、知识产权转移等），并对每个条款的风险点进行初步分析。一位资深律师完成全面审阅需要40-50小时。

他们的负责人询问能否用10万元预算通过AI解决。我回答可以，并且付诸实践，也“解决了”问题。只不过，系统的可扩展性不高，毕竟10万元的预算不可能打造出一个Harvey（知名法律AI）级别的产品。

初期，我们尝试了一种基于Dify的标准方案：

1. 文档处理：将PDF合同转换为文本，按固定长度（如512字符）进行重叠分块。
2. 向量化：使用Dify的知识库功能自动处理分块与嵌入。
3. 检索：用户提问时，召回相似度最高的Top-5个文本块。
4. 生成：将文本块与问题拼接，提交给GPT-4生成答案。

实际效果堪称灾难：

一、关键条款信息丢失

一些“条款”可能跨越3-5页，包含定义、范围、限额、除外情形等多个部分。固定长度的分块会将其切割成5-6段，导致每段语义都不完整。

二、表格数据丢失

合同附录中包含大量表格，通常需要转换为Markdown格式。如果未做处理或处理不当，表格会被切碎，模型可能只看到表头或零星数据。

三、引用混乱

模型常常自信地引用“第523页第2段”，但实际上该页讨论的是完全不同的内容。甚至出现过引用页码超出了文档总页数的情况。

四、图片信息缺失

这一点无需多言，图片未经特殊处理（如转化为Markdown并添加描述），信息几乎全部丢失。

五、答案一致性差

针对同一问题在不同时间提问，得到的答案和引用来源完全不同，完全无法用于正式的法律意见书。只要错一处，律师便会怀疑所有结果的可靠性。

书接上文，我们继续构建智能体（Agent）的探索之旅。此前，我们致力于实现一个简单的智能体原型，并带领大家进行实操。鉴于内容篇幅，该主题被分为上下两篇。本文作为下篇，将聚焦于三大核心模块：记忆系统、ReAct框架以及一个小红书爆款内容发布的实践案例。

记忆系统：构建智能体的海马体

真正实践过复杂AI项目的开发者会深刻理解，在AI应用层，最具挑战性的环节往往是：数据如何与AI进行有效交互。

例如，某些生产级的复杂AI项目，其代码量可能仅在一万行左右，但所依赖的知识库却异常庞大。这里存在着显著的非对称性，其结果便是：在复杂的AI项目中，高达80%的开发时间都投入在了处理数据相关的问题上！

因此，我们格外关注复杂AI项目中AI与数据交互的范式（最佳实践）。正是在此基础上，衍生出了许多专业术语：短期记忆、长期记忆、语义记忆、情景记忆……

所有这些概念共同构成了智能体的记忆系统。如果说大型语言模型（LLM）是智能体的大脑，负责思考与决策；那么记忆（Memory）就是智能体的海马体，负责记录经验与知识。

LLM有一个核心特性：无状态性。对于模型而言，每一次调用都是全新的开始。无论之前的对话多么深入，一旦开启新一轮交互，它就会将此前发生的一切彻底遗忘。

为了让智能体具备“记忆”能力，就必须构建一套外部的记忆系统。这套系统远不止简单地“保存聊天记录”，它需要解决三个核心的工程挑战：

1. 记在哪里？（存储机制：数据库选型）
2. 怎么记住？（写入策略：短期与长期）
3. 怎么想起？（检索机制：RAG与检索）

在工程语境下，记忆指的是模型在当前输入之外，仍然能够访问和使用的信息集合。这些信息可能来源于历史对话、外部存储或系统内部状态，但其核心目标始终如一：为当前的推理过程提供必要的上下文补充。

从内容性质上划分，智能体中的记忆通常可以分为三类：

1. 情景记忆：记录具体发生的事件或会话片段，例如用户说过的话、一次任务执行过程中的中间决策。
2. 语义记忆：记录经过抽象提炼的稳定信息，例如用户的偏好、已验证的事实、总结后的结论。
3. 程序性记忆：记录“如何执行任务”，例如可用的工具、技能、流程模板或固定的执行策略。

这是一种逻辑上的分类，并不等同于具体的存储或实现方式。在实际落地时，这些记忆往往会以不同的工程形态存在。

常见的记忆工程模式

在实际的系统中，很少直接实现抽象的“情景记忆”或“语义记忆”，而是通过以下几种常见的工程模式来承载它们：

上下文记忆

上下文记忆是最基础的实现方式。其原理是将历史对话内容原样拼接到当前的提示词（Prompt）中，一并发送给模型。模型通过“看到”先前的对话来保持语义上的连贯性。

这种方式实现成本极低，适合用于原型验证或短对话场景。但它受限于模型的上下文长度（Token）上限，对话越长，成本越高，且无法支持跨会话或长期记忆。从本质上讲，它是一种短期、一次性的情景记忆。

滑动窗口记忆

滑动窗口记忆是在上下文记忆基础上的一种优化策略，即只保留最近固定轮数的对话，超出窗口的旧内容会被直接丢弃。它主要解决的不是“记忆能力”问题，而是“Token成本控制”问题。

在工程上，可以将其理解为情景记忆的生命周期管理机制。它适用于上下文有效期明确、业务流程较短的场景。然而，一旦关键信息被移出窗口，就会永久丢失。

摘要记忆

摘要记忆通过调用模型对历史对话进行压缩，将大量的情景记忆转换为一小段简要描述，并在后续对话中使用该摘要来替代原始内容。

这种方式在控制成本和扩展上下文长度方面具有明显优势。但摘要过程不可避免地会造成信息丢失，其质量高度依赖于模型的能力。因此，它更适合用于保留“整体脉络”，而不适用于那些依赖精确细节的场景。

从记忆类型来看，摘要记忆本质上是将情景记忆转化为一种低精度的语义记忆。

向量记忆

向量记忆是一种典型的长期记忆实现方式。其核心做法是将对话内容、经验或用户偏好转化为向量（嵌入）后，存入向量数据库。在需要时，通过计算语义相似度来检索相关内容。

这种方式不受单次对话长度的限制，适合长期知识积累和跨会话记忆。但检索结果是基于“语义相似”而非“精确匹配”，且实现复杂度高于前几种方式。它是当前智能体系统中最常见的语义记忆工程实现。

记忆存储方案

某些信息需要被持久化存储，这有多种目的：保存单次会话内的完整对话历史；支持在同一会话中进行多轮交互，使AI能访问历史消息；保证消息的顺序和完整性；提供高效的查询与加载机制；支持基于语义的检索。

根据项目需求和复杂度，通常涉及以下几类存储方案：

1. 关系型数据库：擅长结构化存储，查询方便，技术成熟稳定，支持ACID事务。
2. 本地JSON文件：无需搭建数据库，操作简单，便于保存和读取整个会话状态。
3. 向量数据库：专为高维向量设计，支持高效的相似度检索（语义搜索）。

方案	优点	缺点	适用场景
MySQL / PostgreSQL	功能强大稳定，支持高并发	部署和维护成本相对较高	生产级服务
SQLite	单文件、零配置，支持完整SQL	并发能力弱，适合单机应用	本地智能体 / 实验 / 轻量级应用
本地 JSON 文件	极致简单，无需额外依赖	无法进行复杂查询，读写效率较低	脚本级测试或原型
向量数据库	具备强大的语义检索能力	通常只存储向量，不适合存结构化业务数据	长期记忆 / 知识库

在后续的实现中，我们将采用 SQLite + ChromaDB 的混合存储方案。

之前我们探讨过，2023年是基础大模型爆发的元年，行业内主要的关注点都集中在模型本身，上演了被称为“百模大战”的激烈竞争。

然而，市场很快意识到单纯在模型层面内卷难以持续，于是业界开始回归理性，积极寻找能够切实落地的应用场景。因此，2024年的重心转向了AI应用，其中AIGC（辅助生成文案）、工作流自动化以及AI客服被视为最具代表性的三大应用方向。

进入2025年，AI视觉相关的需求显著增长，成熟的AI编程助手也异军突起。尽管如此，复杂的AI客服场景依然拥有庞大的市场需求。尽管AI客服通常被归类为RAG应用，看似原理简单，但实践中许多公司却难以将其做好，效果不尽如人意。

为此，我们将以一个真实的生产级案例作为教学素材，带领大家由浅入深地理解，一个高效可靠的AI客服系统是如何经过精心打磨而成的。

案例说明

这个AI客服案例来源于我们去年的一个AI to C创业项目：空气小猪。它是一款基于社交场景的语言学习应用程序。自上线以来，客服工作一直由团队内部成员承担，平均每天需要耗费2至3个小时，这种状态已经持续了半年之久，占据了大量的宝贵时间。

在此期间，我们也尝试过引入兼职客服，但效果并不理想。一方面，兼职人员的投入度和责任心往往不足；另一方面，由于对产品的核心理念与定位缺乏深度理解，他们常常无法准确、有效地回应用户的疑问，导致整体服务质量难以达到预期标准。

实际上，用户提出的问题绝大部分是重复性的，高频问题就那么几类。每天人工重复回答这些问题，无疑是一种低效且不可持续的工作模式。因此，针对简单的AI客服场景，我们早已形成了一套成熟的方法论。

简单场景直接套用该方法论即可（尽管后续事实证明，其他实践者可能会在其他环节遇到挑战）；而对于复杂场景，我们则另有一套应对策略。由此，我们几乎可以得出一个明确的结论：

未来的客服工作，无论其简单或复杂，都将大概率被AI所替代。

在线客服工作本身具有高度的重复性特征，因此，“降本增效”始终是客服系统演进的核心驱动力。基于大模型构建的AI客服，不仅能显著提升产品服务能力和用户体验，还能大幅降低长期的运营维护成本。

随着AI Agent技术的日益成熟与普及，AI客服系统在成本控制、响应效率和可扩展性方面将进一步得到优化，逐渐成为企业客服体系的最优解。

此时，可能有读者会产生疑问：既然如此，为何不从一开始就部署AI客服，反而要每天投入数小时进行人工客服呢？

答案非常直接：我们需要积累最原始的、高质量的对话数据。

在这半年多的时间里，项目创始人与用户之间沉淀了大量真实、高质量的对话语料，这为我们提供了极其宝贵的数据基础。当基础性问题开始不断重复出现时，便是构建一套AI客服系统的最佳时机。

此时，我们的目标就变得非常清晰：**将团队从每天2小时的人工客服工作中解放出来！**以上就是项目的整体背景。接下来，我们将详尽介绍“空气小猪”AI客服从零到一的全过程实践，以及各个关键环节的落地步骤。

技术选型

在具体实现环节，我们面临一个关键抉择：是采用智能体低代码开发平台，还是进行彻底的工程化代码开发？

单纯从技术实现的角度看，两种方式都能达成目标。但若追求深度把控与长期效益，我们果断选择了工程化代码开发的方案。这样做的好处众多，最重要的是能够获得更深入的技术实践与理解，所有这些优势最终都体现在系统的自主可控性上。当然，我们也可以简要回顾一下选型过程，供各位参考：

在评估智能体开发平台时，我们主要考察了Dify。此前我们已对比过Coze、Dify、FastGPT、N8n等平台的技术特性。

整体而言，Dify的能力在这些平台中最为均衡，没有明显的短板，尤其适合企业级场景下的智能体开发、工作流编排以及知识库驱动的应用构建。

然而，我们最终没有选择Dify，主要基于以下几点考量：

1. 我们对知识库的检索能力有较高要求，希望在召回策略、排序逻辑、上下文拼接等核心环节进行深度定制与优化。这部分是AI客服能力的基石，我们更希望其逻辑完全自主可控。
2. 私有化部署会带来额外的服务器成本与运维负担，这对于我们当前的项目阶段而言并非必要（实际使用后才会发现开源版本缺少哪些关键功能）。
3. 在实际测试中，我们发现Dify的执行链路相对较长，特别是在知识检索节点，整体响应时间偏长，无法完全满足我们对实时性的要求。
4. 即便使用Dify，在实际落地过程中依然会涉及大量的系统对接、数据适配和定制开发工作，并非真正的“零代码”或“低成本”集成。

综合以上因素，我们最终决定采用自主编码的方式，从底层能力开始搭建系统。虽然前期投入更高，但在可控性、性能优化空间以及系统的长期演进能力方面，这为我们带来了显著优势。

并且，从长远来看，自主开发的实际成本也并不高昂…

解决了第一个问题，许多同学的第二个疑问随之而来：那么，我们的AI客服是否应该直接采用Agent模式呢？

Workflow 还是 Agent？

在项目启动阶段，除了决定使用Dify还是工程化开发，我们还需要在Workflow（工作流）和Agent（智能体）两种开发模式中做出选择。

Agent是具有高度自主性和推理能力的智能体，但其结果的确定性、性能表现以及可控性通常不占优势。在客服这类对准确性和稳定性要求极高的场景中，业界通常倾向于采取较为保守的策略：先按照Workflow的模式，搭建一个稳定、可控的流程框架，以追求确定且可靠的结果。

我们选择从工作流程入手，逐步引入并解决每一个遇到的问题，在保证效果、控制成本与确保可控程度之间取得平衡。

至于后期是否需要“升级”到Agent版本，完全取决于具体的业务需求。在业务层面，我们几乎不盲目追求技术上的时髦概念。

基础流程设计

确定了基础技术选型后，便可以着手进行流程设计。在第一个版本中，我们将用户意图初步划分为产品咨询和闲聊两大类，基本流程如下：

然而，我们很快发现，用户除了咨询常见的产品功能问题，还会频繁反馈产品优化建议以及程序运行故障等问题。

这部分内容的处理逻辑与单纯的产品咨询截然不同。用户反馈的问题需要被结构化地存入数据库，并根据问题的严重程度划分优先级等级，以便我们及时跟进与修复。

因此，我们在初版设计的基础上，增加了“优化建议”与“故障反馈”两类意图的处理流程。具体流程优化如下：

这便对应了我们方法论中强调的“整理意图大表”环节。在基础意图分类大致清晰后，便可以进入最为关键的知识梳理阶段。

知识整理

所有计划构建AI知识库的同行务必注意：高质量的数据才是系统的灵魂！如果有人谈论AI项目却不深入探讨数据问题，那么他很可能缺乏实战经验。

产品知识是AI客服赖以生存的基础（这也是为什么我们宁愿等待半年才启动客服AI化的原因）。只有输入优质的知识，AI才能输出优质的答案，否则就是“垃圾进，垃圾出”。

在数据基础不完备的情况下，无论进行多少工程化的优化都是徒劳。因此，RAG（检索增强生成）的本质是一个数据工程问题，大家必须深刻理解这句话背后的含义。

具体到AI客服的知识梳理工作，理论上要求极高，它最好由对产品拥有最终解释权的人来主导完成。然而，知识的完备性并非一蹴而就，需要通过持续的迭代更新才能逐步完善。

实际情况是，所有知识库应用在初始阶段都存在类似的知识覆盖不全问题。因此，我们允许初期存在知识缺口，并在后续迭代中逐步补齐。同时，采用“数据飞轮”策略来自动化地完善知识库，已成为当前的主流做法。

具体到本项目，我们的知识来源主要包括两部分：一部分是人工整理的结构化知识，另一部分则是沉淀的历史客服对话数据。

在进行知识整理时，必须思考如何组织知识才能获得更佳的检索效果。而检索效果在很大程度上取决于数据处理是否正确，例如每个文本分块是否语义完整、独立。

因此，输出的知识单元必须能够独立成块。我们可以利用Markdown格式的层级结构进行整理，在分块时依据标题进行分割。知识内容的大致形式如下：

另一方面，我们导出了所有的历史客服对话数据。这里主要按会话维度进行分析。由于数据量庞大，人工整理几乎不可能，因此我们借助AI来分析并提取每个会话中有效的问答对。

当然，我们不可能一次性将所有数据交给大模型处理，原因有二：

1. 数据量过大会超出大模型的上下文长度限制；
2. 数据量过大也会增加模型的“幻觉”，导致准确率下降。

我们的处理策略是分批次进行整理，例如以每10个会话为一个批次。我们借助Coze平台搭建了一个自动化处理工作流，具体流程如下：

补充说明：由此可见，我们并非完全不用Coze这类平台，但通常只将其用于一些自动化的轻量级操作，用完即走。

从数据库导出会话记录时，每10个会话被导出为一个独立的记录文件，最终会生成若干个此类文件。将这些文件上传至Coze工作流进行批量处理后，生成的问答对内容会被自动写入飞书多维表格中。

最终表格中的内容必然存在重复项。我们将表格的全部内容再次交由大模型进行分析，进行去重处理，从而形成最终的、纯净的问答对数据集。

通过以上两种方式的结合，我们最终获得了高质量的产品知识数据。这一步至关重要，也极其耗费精力，并且必须由真正理解产品内核的人员参与，才能取得理想的效果。

可以断言：如果这一步没有做好，那么AI客服的最终效果一定会大打折扣！