整个2025年，真正运行良好且持续稳定消耗Token的Agent品类，AI编码工具当属其一。它不断地向我传递一个信号：编程时代的终结，或许比我们预想的要更早到来。

在实际场景中，我身边许多非计算机科班出身、不懂代码的朋友，已经能够借助AI结对编程，成功将产品开发并上线。

代码，长久以来被视为世界最底层、最本质的逻辑真相。因此，AI编程自然成为各大模型厂商竞相布局的关键赛道。几乎每一次基础模型的重大更新，都在AI编程能力上带来显著跃升，持续刷新我们对这项技术边界的认知。

几个月前，我仍持有这样的观点：AI在编程领域主要扮演辅助角色，无法完整实现复杂的业务需求，对整体开发效率的提升可能不足30%。 像Cursor这类工具，其核心用途也集中于Tab键自动补全、代码解释以及局部功能函数的实现，很少让其承担完整需求的开发工作。

然而，随着模型能力的持续迭代，特别是Claude 4.5和Claude 4.6 Opus等强大模型的出现，我的认知被逐步颠覆。如今，AI编程已成为编码工作的主力军。在日常开发中，我们已很少手动编写代码，大约90%的代码都由AI生成。我们的工作重心，更多地转向需求描述、任务拆解、架构设计以及代码审查等领域。

本文旨在分享当前主流的AI编程工具与模型选择策略，并结合个人实践经验，总结出一些实用技巧，以帮助各位开发者更顺畅地迈入AI编程的新阶段。

编程工具概览

下表列举了国内外主流的AI编程工具，它们主要以集成开发环境（IDE）、命令行界面（CLI）或编辑器插件等形式存在：

在众多工具中，Cursor以其出色的综合表现获得广泛认可，是开发者日常使用的主力工具之一。对于偏爱命令行的开发者，Claude Code和Codex也极受欢迎。

此外，国内也有一些优秀的AI编程工具，例如字节跳动的TRAE和阿里的Qcoder。它们使用门槛相对较低，无需特殊网络配置即可访问，但通常无法调用Claude系列的模型。

AI编程工具的演进方向，大致经历了从最初的编辑器插件，到独立的集成开发环境（IDE），再到如今备受青睐的命令行界面（CLI）。目前，我们基本不再优先考虑使用插件，因为其能力受宿主编辑器的限制过多。当前更主流的方式是采用独立的IDE或CLI工具。

自Claude Code引爆市场后，众多AI编程工具相继开始支持CLI模式。那么，CLI相比IDE具备哪些优势呢？

1. 无头化（Headless）与通用性：CLI更加通用，在任何具备命令行环境的地方均可运行。
2. 较低的开发维护成本：对于工具厂商而言，开发插件需要适配多种主流编辑器；开发独立IDE则过于复杂笨重。且开发者通常有自己偏好的编辑器，迁移成本高。CLI模式有效规避了这些问题。
3. 更佳的上下文感知与结果反馈：CLI能更好地感知命令执行结果，便于AI进一步生成、修复或优化代码。

那么，有了CLI，是否就不再需要IDE了呢？

答案是否定的。对于开发者而言，通常是两种方式结合使用。当然，具体组合方式可根据个人喜好自由搭配，例如，我日常使用 Cursor + Claude Code，你也可以选择 Codex + Claude Code。

CLI更适合全程由AI主导、人为介入较少的场景，尤其适合处理复杂任务。而IDE则能提供更优的开发体验，其可视化操作界面更加直观，更适合需要人工深度介入的场景，例如：

1. AI生成代码后，需要进行人工审查时，可利用编辑器的对比分析视图，便捷地核验代码逻辑是否符合预期，并决定接受或拒绝单文件的修改。
2. 进行局部修改时，如仅需调整某个函数中的几行代码，可以直接在Cursor中选中对应行并添加上下文，指示AI进行精确修改。
3. 需要手动微调某些代码逻辑时。

因此，最佳实践是在Cursor这类IDE中，同时打开命令行终端使用Claude Code等CLI工具，实现高效协作。

对于新手或希望体验“感觉编码”（Vibe Coding）的开发者，无需过度纠结于工具孰优孰劣，选择一个能快速上手使用的工具即可，例如Trae、Qcoder等。

编程模型选择

综合评估当前主流模型，可以从能力、价格与适用场景三个维度进行权衡与决策：

• 能力排名：整体表现上，Claude Opus 4.6 最为强劲，其次是 GPT 5.3 Codex，再次是 Claude Sonnet 4.6。
• 价格梯度：GPT 5.3 Codex 成本最具优势，Claude Sonnet 4.6 居中，Claude Opus 4.6 最为昂贵。

基于能力与成本的平衡，建议采用以下模型使用策略：

1. 日常开发与主流任务：优先使用 GPT 5.3 Codex 或 Claude Sonnet 4.6。
2. 高复杂度推理或困难任务：直接使用 Claude Opus 4.6。
3. 前端复杂UI交互实现：可考虑使用 Gemini 3 Pro。

目前，编码能力最强的模型序列仍是Claude 4.6系列。如果条件允许，直接使用顶流模型可以减少大量的调试和修复成本，事半功倍。

昨晚做了一个梦，又一次梦见了前老板老王。在梦境中，我不知是因为某个项目还是汇报，再次被劈头盖脸地责骂了一顿，随后猛然惊醒，或许是被子太厚，让我热出了一身汗……

随后查看日期，发现大约两年前的这个时候我提交了离职申请。当时本计划调整一两个月后重返职场，却鬼使神差地认为AI时代或许应该尝试以半年为限自己创业，结果一折腾就到了今天。

如果用一句话来形容这两年的感受，那便是：我无时无刻不想要一个老板。

然后我发现自己干最大的好处是自由，没人管；最大的问题也是自由，没人管。

没人管，意味着我们需要自己去寻找目的、意义、项目和反馈。有一种说法是创业后，内耗和无谓的事情会减少，不必去做自己认为垃圾的工作。

但与此同时，你做的任何事情，甚至这件事本身是否正确都需要自己承担后果。在公司，你只需要确保过程正确；而自己创业，则需要先方向正确、再过程正确、最后结果正确。

这三者中只要有一个环节出错，所有投入都可能付诸东流。并且，很多事情不亲自尝试根本无法知道深浅，例如：有些大家都觉得有潜力的领域根本赚不到钱，比如制作视频；有些我们认为门槛很低的却存在巨大需求，比如AI客服；大家都在做的事情往往演变为销售或关系链生意，比如外包。

另一方面，脱离公司体系后，你的信息渠道必须从被动变为主动。曾经在公司，微信消息亮起可能让你烦躁，但自己创业后手机一天没有响动反而更令人焦虑，因为如果你不主动与世界联系，世界一定不会主动联系你！

并且，真的不会有老板主动批评你了。你之前所惶恐的激烈指责其实全部是一种反馈，它虽激烈但有效；当然，也不会有老板夸奖你或给你发放年终奖！

所有的正反馈必须通过不停的心理建设来获得、每一分钱都要依靠自己的实力从市场赚取，对于一般人来说，或许好好打工才是更稳妥的选择。

说完基本感受，再来聊聊我的创业项目，希望能给各位正在创业的同学带来一些收获：

2B业务的困境：销售驱动与定制化泥潭

首先，我去年从事的是2B的AI + 管理创业，对应产品为CEO数字分身。它由两个部分组成：

一套公司人效评估系统 + 一套AI表格引擎，可以承载公司所有的降本增效业务，与多维表格非常类似。

我并非盲目行动。为了验证系统的可行性，我在两家公司担任产品/技术顾问，进行了几个月的测试，最终得到的数据反馈都很好，都是100%提效：

我拿着产品询问身边的人，虽然大家并不看好，但也没有提出特别尖锐的负面反馈。然而，在具体售卖时问题就浮现出来了：

中小公司老板们不太愿意买单？或者说他们不愿意为管理事项付费……

之后，我在AI 2B这个漩涡里反复左右横跳，进行了各种尝试和论证，最终得出一个结论：

2B软件/系统/服务 是一个销售驱动的生意，非常看重关系好坏。这里的逻辑是你能不能做 ＞ 是不是轮着你做 ＞ 你是不是做得好。在水平相近甚至略差的情况下，只要达到及格线以上，那么关系好坏就成为首要因素。

其次，即使是拿到项目，也根本不存在标品或者SaaS的可能性。80%以上的甲方要求定制化/私有化部署。只要是定制化/私有化，就一定是卖人头的生意，一般收取员工待遇的120%就已经很高了，再高就显得不现实了……

服务类产品现阶段很类似于外包卖人头，价格被压得很低。所做的事情要么是硬骨头，要么是垃圾任务，员工成长空间有限，还很容易遇到项目青黄不接的情况。这条路对于规模小的团队很难走通，规模大了又风险巨大……

并且，2B业务拖欠尾款是常态。交付周期越长越危险，因为很多公司自身战略变化就很快，三个月后可能根本不需要这套系统了，甲方就会找茬不验收；除此之外还涉及各种人事变化之类的麻烦事，总之尾款很难收到，这已经成为行业的老大难问题！

我也看到一些同学做SaaS服务赚到了钱，但深入了解下来情况可能有些灰暗……

总结下来就一句话：国内2B做不了，根本不存在你能做标品的可能。AI兴起初期还能依靠一波红利，现在各个公司拿着100万要求做出一个GPT的事情时有发生，终究到底还是因为国内人太多了啊……

于是，坚持了一年多之后，在今年4月，我终于跟团队下定决心暂停了CEO数字分身项目的投入。随后贼心不死，又开始折腾AI 2C：

2C业务的挑战：易抄袭与流量竞争

放弃2B的CEO数字分身后，我们的主要精力都投入了2C的AI英语类产品空气小猪。

这个产品也不是无的放矢，是与我一位做了十多年英语教培的合伙人共同规划的。他的公司受双减政策影响，在疫情期间关闭后一直想做点事，于是提出了空气小猪，现阶段获得的用户反馈都很好：

只不过，从产品最初我就发现了2C产品的通用问题：这东西倒是不靠关系了，但它没什么壁垒，容易抄袭、容易重复啊！

比如，在做了充分调研确认市面上确实没有类似产品后，我们加班加点将产品上线，开始有了用户。

于是上周马上有用户反馈：有个团队在做类似产品。随后又在非语言学习场景发现了体验类似的产品……

这也是2C很难的原因：它不是独家生意，谁都可以做。不论是产品还是服务，你在做的同时别人也在做，并且只要做得好就一定会被抄袭，而抄袭的成本还极低！

比如，我做完AI课后，有几个学员也在做AI课，并且内容很类似。这是很正常的事，除非IP很强，否则用户一定会用脚投票。

于是，2C的产品最终又会演化成一个流量生意，各种流量运营策略随之而来，而这东西还挺耗精力，挺花钱的……

时代洪流：AI创业的资源游戏

这两年跑下来，我越来越确认一个残酷但清晰的结论：国内AI应用有些沦为了资源的游戏。

许多财大气粗的公司，他们冷眼旁观，自己不愿承担原创风险，一点试错成本都不想给，反手**“像素级跟进”**玩得飞起！

巨头们凭借流量、数据和资本优势，能迅速复刻任何被市场验证的创意，将创业团队的差异化优势周期压缩至以“周”计算。

这也是为什么做AI 2C的反而又想去做2B，做完AI 2B没好果子吃又想做2C的原因：前者看关系与定制，后者看流量与复制，结果是哪里都没份……

所以，我感受到的无人管束的自由之重，不仅仅源于自身的局限，也交织在一个对独立创业者并不算友好的生态里。

于是很多人选择了躺平打工，更多人选择了出海。甚至前些天我们TGO小组会10个人中，8个人所在公司都在出海，只不过方式各有不同……

最后回归一下，我无时无刻不想要个老板。这里的“老板”并非指具体的人，而是一个系统、一个坐标、一个稳定的反馈源。它象征着：

1. **明确的目标与意义：**独自一人时，“为什么而做”这个最根本的问题需要自己回答，并随时可能被动摇。
2. **即时反馈：**独自前行时，你不知道自己做得好不好，方向对不对，这种不确定性是最大的内耗。
3. **责任的边界：**在公司，你的责任是有限的。而自己干，“甚至连这件事情是否正确本身都需要买单”，这种无限责任带来了巨大的心理压力。

我之前的老板是一个智多星，每隔一段时间就会蹦出一个新的创意，然后会询问我们的意见。我们多数人觉得毫无可能（但表面上会很支持），于是老板总是想去试一试。

其实就算是我们给出了反对意见，他依旧会去试一试，因为不试一试怎么知道真的对不对呢？

在探讨为何选择放弃使用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客服的最终效果一定会大打折扣！