在探讨为何选择放弃使用LangChain之前，我们先来回顾一下其背景。作为目前备受开发者推崇的Agent框架之一，LangChain及其增强工具LangGraph在处理复杂业务场景时，确实提供了一套从组件封装到流程编排的完整工具链。随着LangChain 1.x与LangGraph 1.x版本的日趋成熟，整个技术栈的生态分工与工程化实践路径也变得愈发清晰。

然而，在实际的AI企业级业务开发过程中，无论是创建概念验证原型还是实施正式项目，经过一段时间的实践后，我个人的选择是逐步脱离对LangChain框架的依赖，转而采用更贴近业务本质的开发模式。

当然，这绝非否定LangChain的价值。它能成为行业内的主流选择，必然具备其独特的优势。但技术选型的核心从来不是盲目追逐热点，关键在于评估框架是否真正契合你的项目需求。

任何框架的最终意义，都必须落实到与项目规模、业务需求以及现有技术栈的匹配度上。

本文将结合我的亲身实践，阐述选择不使用LangChain的几个关键考量，并探讨在进行AI应用开发时，关于框架取舍的一些基本原则：

1. 小型项目或原型验证： 直接使用原生API进行开发，灵活性高且无额外依赖，总体成本更低。
2. 中型项目或紧急交付： 可采用LangChain快速搭建基础骨架，但需警惕潜在的后期维护与技术债风险。
3. 大型或企业级项目： 强烈建议自研框架，以更好地适配微服务架构和公司现有基础设施。

核心观点： 在AI编程辅助日益强大的今天，手写“胶水代码”的成本已大幅降低，自研轻量级框架的技术门槛也随之下降。

我们需要AI开发框架吗？

在讨论是否需要引入AI开发框架之前，我们首先需要明确什么是AI框架。

AI框架的本质，是为开发者提供一套标准化的解决方案路径，旨在解决重复造轮子的问题，从而提升开发效率并确保团队协作的一致性。

开发AI应用时，存在大量通用性工作：例如对大语言模型（LLM）调用的封装、提示词（Prompt）的模板化管理、与向量数据库的连接、各类工具链（如搜索、计算、数据库操作）的集成，以及对话历史状态的维护等。

这些功能模块在不同的项目中往往有着相似的实现模式，因此可以被抽象和抽取出来，形成底层的框架支撑。这正是框架所带来的核心优势：

1. 提升开发效率： 即使是对底层细节不甚熟悉的开发者，也能通过框架提供的抽象接口，以少量代码实现相对复杂的功能，并规避一些常见的陷阱。
2. 促进标准化： 在团队协作中，所有成员遵循同一套开发范式与接口约定，能够显著降低沟通成本和系统整合的难度。
3. 利用成熟生态： 主流框架通常会预先集成好常用的工具和服务（如OpenAI、Pinecone、Chroma等），省去了自行对接第三方API的繁琐工作。

然而，使用框架也伴随着一些固有的局限性：

1. 灵活性受限： 为了追求广泛的适用性，框架往往引入多层抽象和额外依赖，这不仅增加了项目的整体复杂度，还可能带来不必要的性能开销。
2. 预设范式束缚： 当业务需求需要进行高度个性化定制时，框架预设的流程和逻辑有时会成为一种束缚，修改适配的成本甚至可能高于从头实现。
3. 存在学习成本： 表面上降低了入门门槛，但要真正驾驭框架、高效解决问题，仍需深入理解其内部运行机制。否则，开发者容易陷入仅会调用API却不清楚底层原理，一旦出现异常便无从下手的困境。

因此，是否采用框架，本质上是在开发效率与灵活可控之间寻找平衡点。而找准这个平衡点的关键，在于清晰识别你当前项目的规模与需求特性。

从实践角度来看，还有一个不容忽视的问题：大多数开发团队并不具备深度维护或改造一个复杂开源框架的能力。这会导致在框架升级、遇到付费模块或需要深度定制时，团队可能束手无策，甚至面临推倒重来的风险。

接下来，我们将针对不同类型的项目场景进行具体分析。

小项目：原生开发更直接高效

如果是小型项目、Demo原型验证，或是内部工具开发，我通常倾向于采用原生开发方式，而不引入任何重型框架。

这类场景的核心目标是快速验证一个想法或跑通一个核心业务流程，例如构建一个简单的对话机器人、PDF文档问答工具，或是文案生成助手。这些功能本身相对单一，边界清晰，尚不需要复杂的架构设计。此时引入LangChain这类框架，反而会增添不必要的复杂性和依赖。

对于小项目，不推荐使用框架的原因如下：

1. 需求快速变化： 小项目的特点在于需求可能频繁调整，例如两周后需要增加会话记忆功能，或切换另一个模型供应商。使用框架开发时，每次改动都需考虑如何适配框架的既有设计；而原生开发则无此束缚，可直接修改核心业务逻辑。
2. 追求轻量与敏捷： 小项目的首要诉求是“能用”和“快速实现”，而非长期的标准化或可扩展性。原生开发能保持极简的依赖和清晰的代码结构。
3. 高度定制化： 原生开发赋予你对代码的完全控制权。你既可以避免框架带来的依赖膨胀，又能针对具体场景进行精细化优化，例如省略非必要的中间调用层，或设计完全贴合业务的自定义Prompt模板。

总而言之，对于需要快速试错、频繁迭代的小型场景，放弃框架、选择原生开发是一种更为务实和高效的选择。有时，甚至像Coze、Dify这类低代码平台也可能是更合适的选项。

中型/紧急项目：可作为过渡方案

对于功能范围明确、有固定上线 deadline，但团队开发资源与时间有限的中型项目（常涉及多轮对话、工具调用、知识检索等模块），LangChain可以作为一个有价值的过渡方案。它能够帮助团队在短时间内搭建出可运行的核心系统，快速验证项目的市场可行性。

LangChain提供了一个开箱即用的丰富组件库，使得团队能将主要精力聚焦于业务逻辑和差异化功能的实现上，而非重复编写基础功能模块。这能有效缩短通用功能的开发周期。

然而，一旦项目成功上线并经过初步验证，若后续还需持续迭代和功能扩展，就必须审慎评估是否需要对框架依赖部分进行重构。目标是将核心业务逻辑与LangChain的通用实现解耦，以避免被框架“绑定”过深。

具体的实施建议包括：

1. 按需选用，最小化依赖： 避免全盘采用LangChain。应明确评估项目需求，仅引入确实必要的模块。例如，可以单独使用其Prompt模板管理或工具调用封装，而自行实现更可控的流程编排或记忆管理模块。
2. 提前规划解耦路径： 在项目架构设计初期，就应为未来替换LangChain预留接口。例如，通过抽象层或适配器模式来封装对LangChain的调用，确保未来能平滑地迁移到自研或其他框架的组件。
3. 清晰界定并管理技术债： 在项目文档和路线图中明确记录：哪些部分因采用LangChain而存在妥协或潜在风险，并制定具体的重构优先级与时间表，将技术债控制在可管理范围内。

大项目：有实力则首选自研

当项目规模庞大、需要长期维护和深度迭代，或者计划作为公司核心基础设施对外提供AI能力时，放弃LangChain、转向自研框架几乎是必然的进化方向。

此时，项目的核心诉求已从“快速开发”转变为对系统稳定性、架构可扩展性、运维可观测性的极致追求，以及与公司现有技术体系的深度融合：

首先，LangChain的设计理念更偏向于单体应用，其内部模块间耦合度相对较高。若想将其拆解并融入微服务架构，改造工作量巨大；而自研框架则可以从零开始设计，在架构灵活性上具备天然优势。

其次，在我之前参与的一个企业落地案例中，该团队最初使用了LangChain，但其内置的日志记录与监控逻辑与公司既有的统一运维体系无法兼容，导致线上问题排查困难重重。由于团队缺乏对框架底层进行深度改造的能力，最终选择了自研一套更贴合内部规范的框架。

最后，LangChain作为第三方开源项目，其发展路线图、API变更决策、对特定模型或向量数据库的支持优先级，均不由你的团队掌控。当框架进行不兼容的重大升级，或社区生态重心转移时，你的项目将面临被迫升级和适配的风险，这可能产生高昂且不可控的技术债务。

简而言之，大型项目的核心诉求之一就是“可控性”。

技术栈的适配度考量

在企业级应用开发中，还有一个现实而普遍的问题：技术栈的匹配度。在许多传统行业，如金融、电商、政务等领域，Java（以及PHP、Golang等）仍然是后端开发的主流语言选择。

最近，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所能覆盖的潜在流量范围实际上扩大了许多。

首先，为什么我想认真做这次 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面对的并非一个模糊指令，而是一份相对明确的执行说明书。

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

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

解决这个问题的方案听起来很简单：把所有事情都记录下来。而“记录”二字正是整个管理体系的精髓所在。实际上，待办事项清单（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（思维链） + 可溯源。即，在模型的提示词部分严格要求其必须遵循 “像我这样思考” 的推理过程；而可溯源则要求输出中的每一句关键陈述都能找到其出处。例如：

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

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

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

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

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

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

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

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

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

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

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

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

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

常见的记忆工程模式

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

https://watermelonwater.tech/insights_imgs/实现Agent记忆系统ReAct案例解析1.webp)

上下文记忆

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

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

滑动窗口记忆

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

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

摘要记忆

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

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

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

向量记忆

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

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

记忆存储方案

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

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

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

在后续的实现中，我们将采用 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客服的最终效果一定会大打折扣！

在2025年，国内人工智能领域有两个里程碑式的事件。首先是DeepSeek的发布，这标志着我们正式迈入了L2级别智能体的大门；随后Manus的亮相，则预示着行业开始进入L2.5时代。

这里提到的L1到L5分级，源于OpenAI的山姆·奥特曼对人工智能应用发展路径的预测。他认为，从L1到L5的演进大约会在十年内完成。

这条技术路线本质上是“模型吞噬一切”的路线。按照这个逻辑，基础模型提供商将成为最大的受益者，所有流量都将向其集中。然而，实际的发展轨迹却并非完全如此。

AI发展史：从L1到L2.5的演进之路

上述的L4和L5阶段尚属遥远，仅看L1到L3的文字描述也难以产生直观感受，需要结合更多背景信息来理解。

2022年底，ChatGPT（基于GPT-3.5）的发布标志着我们进入L1时代，不久之后GPT-4也相继问世。

作为这一时期的亲历者，从模型能力的角度来看，当时最大的问题并非上下文长度不足或存在幻觉，而是资源“一票难求”。普通用户很难获得OpenAI的API访问权限，即便是通过微软Azure云服务获取GPT账号，也常常需要付出高达100%的溢价，且往往有价无市。

同时，模型的推理响应速度也极其缓慢。一次完整的交互，快则需20秒，慢则要等待一分钟。因此，整个2023年，人工智能应用实际上并未达到真正可投入生产使用的状态。

那也是“百模大战”的开端。主流的技术路径普遍采用“预训练+微调”的模式，这个过程耗费巨大。国内走在前列的厂商包括百度、智谱AI、通义千问、讯飞以及百川智能等，但它们彼此之间并未拉开显著差距，其实际能力与开源的LLaMA、Bloom等模型相比也优势不大。

在这个阶段，尽管AI应用大规模进入生产环境尚不成熟，但前期研发环境已经相当完善。特别是在一些对企业级客户而言，费用和响应时间并非首要考量的场景中。因此，那些提供基础设施、研发工具的公司获利颇丰，例如教导普通人使用Coze搭建AI应用的培训服务商，以及各类从事数据生产和数据标注的公司。

然而，芯片行业遵循摩尔定律。由于人工智能热潮吸引了大规模资本涌入，直接导致了模型响应速度大约每半年翻倍、使用成本每半年减半的加速发展态势。因此，到去年年底，所有主流模型的能力都实现了质的飞跃：

1. 业界标杆ChatGPT的响应速度已经变得非常快，基本可以在5秒内完成交互；
2. 智谱AI在推理能力和响应速度上均有大幅提升，阿里的Qwen模型也取得了显著进步。

当然，国内最具标志性的人工智能事件当属DeepSeek的发布。无论是其率先展示的思维链（CoT）技术，还是专家模型等创新设计，都足以让人眼前一亮。这也标志着我们完全进入了L2阶段。

进入2025年，无论是模型的基础推理能力、响应速度还是使用成本，都已达到能够支撑生产应用的水平。因此，业界才将2025年称为“国内AI应用元年”，这个说法正是基于这样的背景。

基础环境就绪后，各类AI应用自然如雨后春笋般涌现。另一个标志性事件随即爆发：Manus发布了。Manus产品的意义不在于其技术难度有多高，而在于它率先提出并实践了一种符合AI时代的智能体产品交互范式。事实上，随后各大浏览器厂商也开始朝这个方向演进，“入口即应用”的思维方式开始普及。

只不过，Manus这类产品在实际使用中仍存在诸多问题。虽然基础模型能力已经足够，但配套的基础设施和工具链尚未完全跟上，这导致其用户体验总感觉“差那么一点意思”。

随后，红杉资本的人工智能峰会也指出，第一批智能体的机会在于垂直领域。果不其然，面向设计师的智能体、面向程序员的智能体在今年取得了长足进步。例如Cursor、Lovart等产品已经切实地改变了部分人群的工作方式。

其次，今年的Google I/O大会展示了众多智能体发展趋势，其中尤其值得关注的是图像/视频生成体系的“Flow + Veo3 + Imagen 4”组合。近期发布的Nano Banana更是火爆异常，文本生成图像的应用似乎近在眼前。

人工智能正在如火如荼地发展，但随之而来的问题是：我们普通人的机会在哪里？我们又需要避免哪些潜在的陷阱？

要回答这个问题，或许需要从智能体的基础架构层面进行审视和判断。

从基础架构视角审视AI领域的机遇

智能体框架的核心技术架构主要包含以下几个方面：

1. 大模型负责解决规划与调度问题。Manus能够爆发的核心原因正是模型能力的显著增强。
2. RAG（检索增强生成）技术用于缓解幻觉问题。就当前模型发展趋势而言，上下文窗口突破百万级别是迟早的事。如何让模型对话更像真人，以及体验良好的AI数字分身类应用，预计将在未来两年内诞生。
3. 工具链旨在解决多模态交互问题。最近颇受关注的MCP（模型上下文协议）、Computer Use等，本质上都是AI多模态能力的延伸，目的是解决AI在各种感官交互（如听觉、视觉、触觉）上的局限性。

从基础架构出发，一条关于基础能力的“红线”也随之清晰：例如，切勿轻易涉足多模态相关领域！

包括语音识别与合成、视频生成、文生图、图生文、视频语音处理等方向，接下来将迎来大规模的行业洗牌，普通公司最好不要轻易涉足。

另一方面，当前的记忆模块主要依赖RAG技术，但未来这一部分可能会有不小的迭代。模型可能会预留更合适的接口，以便我们更高效地注入领域知识。然而，这其中涉及的数据安全问题也不容小觑。

此外，在模型上下文窗口持续扩大（例如超过10万token）的趋势下，传统的向量数据库等技术，可能在未来几年内逐渐退出历史舞台。

一个好消息是，模型的幻觉问题是难以从根本上彻底解决的，因此企业不必过分担心数据壁垒最终会完全消失。正如OpenAI近期发表的论文《Why Language Models Hallucinate》所指出的：

幻觉并非神秘的缺陷，而是训练与评估过程中，奖励“猜测”行为、惩罚“不确定”表达的统计性后果。 降低幻觉，需要在评估中对过于自信的错误答案施加重罚，对合理的不确定性给予部分分数，并允许模型在不确定时选择“弃答”或“请求澄清”。 RAG可以缓解事实性错误，但若底层激励机制不改变，猜测行为仍会发生。

再看如今常见的智能体，大致可以分为两类：通用型智能体和垂直行业智能体。

对于通用型智能体而言，其核心在于工具生态，生态越繁荣，产品越容易脱颖而出。而对于垂直行业智能体来说，私有的领域语料库、垂直领域的专用插件越多，其在实际使用中的友好度和有效性就越高。

以Manus类产品为例，其本身并没有过高的技术壁垒。国内已有不少类似产品，其基本功能的实现周期大约在一个月左右。当然，如果要打磨到体验出色，仍需投入大量时间。

为了让读者更清晰地理解智能体架构，我们接下来将利用Coze这一工具，尝试简单实现一个“类Manus”系统，以便大家对智能体架构的核心工作量分布有一个更系统的认识。

Manus核心原理简要分析

在开始动手实现之前，有必要了解一下 Multi-Agent System（多智能体系统） 的概念。

智能体的最佳实践遵循“单一职责”原则。所谓的多智能体系统，就是指一项工作由多个职责分明的智能体协同完成。至于如何调用这些智能体，则需要大模型进行详细的规划和调度。而Manus在本质上，就是一个多智能体系统。

实例解析：一个贪吃蛇游戏的诞生

举个例子：打开Manus，让它“帮我做一个贪吃蛇游戏”，它很快就能完成任务。

在这个过程中，它可能调用了以下工具能力：

1. 文件读写能力；
2. 浏览器操作能力（包括网页搜索、模拟点击、键盘事件等）；
3. 代码编写与纠错能力；
4. 系统命令执行能力；
5. 代码部署与预览能力；
6. ……

所有这些操作都在一台云主机上完成，并且实时回传了运行进展。其简化版的架构猜想如下（注：真实场景中，规划与记忆模块会复杂得多，此处仅做原理性示意）：

回顾过去一年的热门技术事件，DeepSeek的发布与Manus的问世无疑是两个最受瞩目的焦点。市场对这类产品展现出持续的热情，近期爆火的Agent形态产品OpenClaw（由Clawdbot演进为Moltbot）便是例证。

关于为什么需要Agent以及它究竟解决了哪些核心问题，我们在之前的文章中已有详细阐述。今天，我们将采取一种更为务实的视角，直接带领大家动手构建一个Agent，通过实践来深入理解其背后的技术难点与实现逻辑。

一、环境配置：从零搭建开发环境

在开发过程中，不同的项目往往需要不同版本的Python运行环境。为了高效管理多个Python版本，我们推荐使用pyenv这一工具。

macOS系统可以通过Homebrew进行安装：

brew update
brew install pyenv

或者，您也可以选择使用官方安装脚本：

curl https://pyenv.run | bash

Linux与Windows系统的安装命令如下：

curl -fsSL https://pyenv.run | bash

# Windows系统需使用pyenv-win：
# 1. 以管理员权限打开PowerShell。
# 2. 执行以下安装命令：
Invoke-WebRequest -UseBasicParsing -Uri "https://raw.githubusercontent.com/pyenv-win/pyenv-win/master/pyenv-win/install-pyenv-win.ps1" -OutFile "./install-pyenv-win.ps1"; &"./install-pyenv-win.ps1"

安装完成后，可以通过运行以下命令来验证安装是否成功：

pyenv --version

若成功显示版本号，则表明安装正确。以下是一些常用的pyenv命令：

# 查看所有可安装的Python版本
pyenv install --list | grep 3.12
# 安装指定版本的Python，例如3.12.0
pyenv install 3.12.0
# 查看当前已安装的所有Python版本
pyenv versions
# 设置全局默认的Python版本
pyenv global 3.12.0
# 仅为当前目录设置特定的Python版本
pyenv local 3.12.0

Python包管理工具：uv

uv是一个轻量级的Python包管理工具，它集成了虚拟环境管理和依赖包管理功能，可以看作是pip与venv的组合体。使用uv能够方便地为不同项目创建独立的虚拟环境，并精确管理依赖版本。

确保已通过pyenv安装并切换至所需版本的Python后，即可安装uv。

macOS / Linux系统可通过官方脚本安装，或使用pip安装：

curl -fsSL https://uv.dev/install.sh | bash
# 或
pip install uv-cli

Windows系统的安装步骤如下：