这几个月后台私信里问得最多的就是两类问题一类是“AI智能体到底怎么赚钱”另一类是“现在学智能体开发还来得及吗”。说实话年初那批靠卖课和拉群赚到钱的人现在已经不怎么提“年入百万”了反而是真正在给企业做知识库问答、流程自动化、客服机器人的人开始接到越来越多预算不算小的单子。这个赛道没有死它只是在从“讲故事”切换到“讲交付”。考虑到这是“AI智能体”主题下的第二篇这篇我不打算再复述概念重点聊更实际的东西开发平台怎么选、企业知识库里的向量数据库到底承担什么角色、智能体测试数据集怎么设计才不会在客户现场翻车以及大模型、小模型、智能体这三者对于初学者而言应该以什么顺序去学。这些内容都是我这几个月真实交付项目时反复踩过、验证过的东西。文章会直接给方案和步骤但也会先说清楚背后的判断逻辑因为只知道“怎么点按钮”不理解“为什么这么做”换个场景照样不会做。1. 这波智能体浪潮真正的产业机会到底长在哪先说结论机会不在模型层不在你用来写提示词的漂亮外壳而在“把一个通用模型变成某个行业里能稳定干活的员工”这个过程里。很多人问AI智能体是不是又一个泡沫我的看法是只要它解决的是真实存在的人工成本问题这个方向就站得住。关键在于你切入的是不是那个真实的“费力点”。1.1 大模型是“大脑”智能体才是一个“完整的人”我经常打一个比方API调用相当于你招了一个名校毕业生他脑子很好用但你得把他安排进一家公司给他配电脑、开账号、告诉他公司流程、让他和其他部门协作他才能真正产出价值。这个“把人安顿进组织里”的过程就是智能体在做的事情。从这个角度看智能体的核心能力不是“会聊天”而是三件事理解任务能从用户一句含糊的话里拆出意图比如“帮我查一下上个月华东区的回款情况”要能拆出“华东区”“上个月”“回款”这几个关键条件。调用工具知道去哪个系统拿数据、调哪个接口、查哪个表。组织行动把一个大目标分解成多个步骤并且能根据中间结果调整后续动作。你去看市面上所有号称“智能体”的产品凡是体验好的基本都在把这三件事做扎实凡是体验差的基本都只做了第一件事还是那种只做了半吊子的理解。1.2 现在企业愿意为哪些智能体需求掏钱我做过的、以及身边朋友被真实买单的项目主要集中在下面几个场景。这些场景有一个共同点以前都靠人肉重复劳动而且招聘越来越难、成本越来越高。企业内部知识库问答把散落在文档、工单、群聊记录里的经验变成24小时在线的“老师傅”。这是目前需求最扎实、也最适合小团队切入的方向。客服与售前咨询不是那种全自动替代人工的客服而是“辅助坐席”模式——智能体实时给出推荐答案人工确认后发出回复效率能提升一大截。业务流程自动化把“收到邮件→解析附件→录入系统→通知相关负责人”这类固定流程交给智能体去跑。营销内容批量生产基于企业自己的产品资料和客户画像生成朋友圈文案、公众号初稿、短视频脚本再由人工修改。我不太建议个人开发者一上来就做那种“开放域聊天机器人”没有垂直场景的数据和流程做支撑做出来的东西既不够好用也很难向客户解释价值在哪。2. 选工具先于写代码扣子/Dify/自研框架的边界在哪很多初学者容易陷入一个误区一听说要开发智能体就想去学LangChain源码、研究Agent框架底层。但真正接企业项目的时候效率和可维护性才是第一位的。我目前的选型原则很简单能用成熟平台解决的绝不自己造轮子平台满足不了的再用代码补齐。2.1 扣子Coze适合谁来用适合接什么活扣子Coze是我目前最推荐给刚入门者和轻量项目团队的工具。它对国内用户非常友好工作流可视化、插件集成、知识库管理、卡片消息这些都做得比较完善而且搭建一个原型的速度极快。我有个做电商客户的朋友用扣子搭了一套售前导购智能体从0到1只花了一个下午核心就是拖了几个节点用户输入→识别意图→检索商品库→生成推荐话术。这套流程放到代码层面去写至少需要三天。而用扣子大部分时间其实是花在调提示词和设计知识库结构上这对非技术背景的人极其友好。适合用扣子的场景我总结了一下需要快速验证想法的MVP项目。客户预算不大、交付周期短的中小企业应用。个人开发者做工具型产品比如小红书文案助手、周报生成器。企业内部小范围试点先跑通业务逻辑再决定要不要上更重的方案。但扣子也有它的天花板。底层的模型调度、私有化部署、深度定制化的数据处理流程都会被平台限制住。遇到对数据安全极其敏感、要求必须内网部署的客户扣子就不太合适了。2.2 Dify、RAGFlow这类开源平台解决的是企业数据不出内网的问题如果你的客户是金融、医疗、政务这类对数据合规要求极高的行业私有化部署通常是硬性条件。这种情况下Dify和RAGFlow这类开源平台就派上用场了它们相当于在“开箱即用”和“自由定制”之间取了一个平衡点。Dify最打动我的地方在于它把Agent、知识库、工作流、模型管理这些核心组件都整合在了一个后台里支持docker compose一键部署。也就是说你可以把它装到客户的服务器上让客户的数据始终留在自己的内网环境里模型既可以用公共API也可以对接客户自己部署的模型服务。RAGFlow则在文档理解方面做得更细对于PDF里复杂的表格、版式它的RAG效果比很多通用方案要稳。需要注意引入开源平台不等于什么都解决了你仍然要花大量时间调整知识库的切片策略、测试不同的向量化模型、优化检索的召回效果。平台只是把底层复杂度封装了业务效果还是要靠人来调。2.3 什么时候才值得自己动手搭框架当你发现项目的核心壁垒不在业务逻辑而在底层的调度效率、多智能体协作机制、或者大规模并发处理这时候才需要考虑从零搭建。但即便到这一步我也建议先基于LangChain、LlamaIndex等成熟框架去改而不是连HTTP调用都自己封装一遍。我给一个比较务实的判断标准如果你需要同时管理超过20个不同的智能体节点、需要复杂的条件路由和跨系统操作或者你对Token成本敏感到需要精细控制每次调用的模型路由那么自研或深度定制才有意义。否则用Dify或扣子就够了省下来的时间去做业务调研和客户沟通回报率高得多。3. 企业知识库背后的向量数据库不是“差不多能用”就行最近有个问题被频繁问起AI智能体的企业知识库是存放在向量数据库里的吗这是个好问题说明大家已经开始关注知识库背后的技术架构了。直接回答是的当前主流的智能体知识库方案底层几乎都离不开向量数据库但它只是知识库链路中的一环。如果你以为“知识库把文档丢进向量数据库”那你大概率会做出一个检索结果乱七八糟、回答前后矛盾的产品。3.1 为什么松散的文档必须变成“可检索的向量”先想一个问题当用户问“我们公司的年假制度是什么”系统凭什么知道要去回答这个问题而不是把整本员工手册都返回给模型答案就是靠“语义检索”。在传统的关键词搜索里它只能做字面匹配用户说“年假”手册里写的是“休假管理办法”两边可能就匹配不上了。而在RAG链路里文档会被切成一个个片段每个片段经过Embedding模型转换为一串向量写进向量数据库。用户提问时系统会把问题也转成向量然后去数据库里找“距离最近”的那些片段。你完全可以把它理解为查字典先通过索引找到可能相关的页码再把这些页码里的内容交给大模型去组织答案。向量数据库就是那套索引系统而且它支持的是“语义级别的模糊查找”比精确匹配要聪明得多。3.2 一个最小可用RAG链路的五步搭建我接企业知识库项目时标准流程基本是固定的分享出来供你参考第一步文档解析与清洗这一步最容易被忽略但也最影响效果。你要处理的不只是干净的Word文档还有各种扫描版PDF、Excel表格、PPT。扫描件需要OCR识别PDF里的复杂表格容易解析错位二维码、页眉页脚也要过滤掉。只有源文件干净后面的切片和检索才不会出问题。第二步切片策略设计切片是RAG的命门之一。切片太大检索出来的一段内容里包含太多无关信息模型容易被带偏切片太小语义又不完整。目前没有万能参数需要按文档类型测。我的经验是制度规章类文档按章节切操作手册类文档按步骤上下文切常见的是256到512个字符的块大小并设置一定比例的重叠。第三步向量化处理选择一个合适的Embedding模型把文本片段转换成向量。这一步没什么特别技巧关键是选择与你的文档语言、领域匹配的模型。比如主要业务是中文场景就需要重点考察中文语义理解的模型表现。第四步写入向量数据库并建立索引把上一步生成的向量连同原文、来源、章节等元数据一起写入向量数据库同时建立好索引。如果数据量比较小简单的索引就够了数据量大到百万级以上就要考虑索引参数的调优问题。第五步召回→重排→生成用户提问后先向量检索TopK个候选片段然后用一个重排模型或规则去调整顺序滤掉无关内容最后把这些片段组装成上下文丢给大模型生成回答。重排这个环节对于答案质量的提升非常明显。3.3 向量数据库选型别只盯着性能和名气目前常见的向量数据库大致有几类一类是专门的向量数据库产品一类是在传统数据库上增加向量检索能力的方案还有一些是云厂商提供的托管服务。选型时我主要看三个维度部署运维难度、检索质量、生态兼容性。方案类型典型代表适合场景注意事项轻量级嵌入式Chroma等本地原型、小数据量、入门学习数据量大时性能不够稳适合单机小规模独立向量数据库Milvus、Qdrant等生产环境、大规模数据、高并发检索需要独立部署组件较多运维有一定成本分布式扩展方案ES加向量插件、云数据库自带向量能力已有ES等基础设施的团队能复用现有运维体系但向量检索性能需要对比测试不建议上来就追求“性能最强”的。先拿几百份文档跑通整条链路评估召回质量再决定要不要上更重的设施。对很多中小项目来说一个轻量方案或一个托管的向量服务已经足够了。记住一个原则选型不是选最先进的而是选你最有把握维护好的。4. 智能体测试数据集没数据你做出来的Agent就是玄学“AI智能体测试的数据集怎么设计”这个问题被问到的频率越来越高。原因也很现实很多开发者在demo阶段觉得效果非常惊艳一到客户那里就被真实问题问得哑口无言。这不是模型变笨了而是你根本没有一套像样的测试数据帮你提前发现问题。4.1 为什么“demo正常”和“真能商用”是两回事你拿两三个精心设计的例子去演示当然怎么看怎么顺眼。但真实的用户提问方式是什么样的他们会说一半句话、会打错字、会问超出你知识库范围的问题、会一次问三个问题还要求你分别回答。这些情况demo里统统没有。我见过不少项目上线后才暴露严重问题的情况智能体对主营产品相关的回答很准确但客户一旦问“你们和另一家公司的产品有什么区别”它就自由发挥了。原因很简单开发时根本没有把这些常见但难缠的问题放进测试集。所以智能体测试集的价值不是给开发人员“看效果”用的而是给质量兜底的。4.2 一套可落地的测试数据集由哪几类问题组成我通常把测试集分成五个大的类别每一类对应一种真实风险。整理成如下结构测试类型定义示例以企业知识库为例标准业务题知识库里有明确答案、用户正常提问“我们公司的年假制度是怎么规定的”语义泛化题换了种问法但指向同一答案“我想休息一段时间能休几天有钱拿吗”边界题问题涉及细则、例外情况“入职不满一年能享受年假吗”干扰题问题里混入无关信息或错别字“我之前用发票报了培训费那机票呢年假还能折现吗”越界题超出知识库范围或敏感话题“帮我写一封辞职信”明显超出知识库范围针对每一类问题你都要为它提前定义一个“预期正确行为”。比如越界题不一定要求智能体完美回答但至少不该编造一个错误的制度出来。4.3 判定标准怎么写才不会被模型结果糊弄过去有了测试问题集还不够你还需要一套评分标准否则两个人的评测结果可能大相径庭。我一般从三个维度打分内容准确性答案里是否有事实错误关键数据是否与知识库原文一致。这个维度权重最高一票否决。完整度用户问了三个点答案是否覆盖了全部三个点还是只答了第一个。表达合理性语气是否符合设定有没有啰嗦或者漏掉重点。这里补充一个很实用的经验测评结果里要单独记录“引用来源”。也就是说每次回答都要保留它参考了哪个知识库片段。这样当答案出错的时候你能快速定位是检索环节出了问题还是生成环节出了问题。如果引用来源本身就是错的那大概率是检索召回的质量不行如果引用来源是对的但答案不对那就是模型的指令遵循能力或者提示词设计需要调。5. 大模型、小模型、智能体到底该怎么学先后顺序是什么“学习AI大模型、小模型、智能体从哪里开始”也是高频问题。我能理解这种焦虑因为市面上课程太多了今天讲Transformer明天讲微调后天讲Agent看着都重要但真要投入时间又不知道从哪下手。5.1 先别啃论文把“调用-提示-评测”这条线跑通我的建议可能和一些培训机构的路线不太一样不需要上来就啃论文先当一个好“产品经理”和“工程师”把这个闭环跑通学会调用大模型API知道怎么发起请求、怎么处理流式返回、怎么控制参数temperature、max tokens等对结果的影响。学会写提示词并理解其边界不是背模板而是要理解“大模型是在做概率生成”同样的任务换一种措辞效果可能天差地别。学会搭一个带外部数据的智能体哪怕只是一个最简单的“文档问答机器人”也要亲手把它部署上线观察它在真实问答中的表现。学会评测和迭代用上面说的测试集去测记录问题再反推是提示词的问题、知识库切片的问题还是上下文组装的问题。这个阶段你不需要理解模型内部的每一个矩阵乘法但你要见过足够多的“翻车现场”。见过模型一本正经地编造数据之后你对“什么叫幻觉”“为什么要RAG”的理解会比你读十篇综述都深刻。5.2 大模型、小模型、智能体的分工不是越强越好很多人弄不清“大模型、小模型、智能体”之间的关系。我用一个比较直观的方式来解释大模型是知识面很广但脑子贵的外聘专家小模型是某个领域练得很熟、成本极低的专职老员工智能体则是把这些角色组织起来干活的项目经理。在实际工程里不是所有环节都需要用大模型。比如从用户一句话中抽取结构化信息意图识别、槽位填充用一个效果不错的小模型可能就足够了速度快、成本低。而最终生成一封需要情商和文采的回复邮件再调用大模型。这就是模型路由的基本思想也是你在掌握了单模型调用之后值得进阶去研究的方向。5.3 一个偏实战的三个月起步路径下面是我给来咨询的朋友建议的一份三个月练习计划照着做基本能完成入门。第1个月基础通关。聚焦API调用和提示词工程每天至少完成一个实际任务比如让模型做摘要、写邮件、抽取信息、改写文案。周末把多个任务串起来做一个“输入一段会议记录输出待办事项”的小工具。第2个月RAG与知识库。用开源平台或代码实现一个完整的企业知识库问答机器人。把至少50份文档灌进去重点体验并记录不同切片策略、不同Embedding模型、不同检索参数对回答质量的影响并建立自己第一个像样的测试集。第3个月智能体与工作流。尝试构建带工具调用的智能体比如让它能上网搜索、能查天气、能读写数据库。然后挑选一个真实业务场景比如客服工单分类做一个能从“用户提问”到“工单创建”再到“回复生成”的完整智能体自动化流程。这份计划不是面面俱到的但三个月后你至少会成为一个“能解决具体问题的人”而不是“背了很多名词但什么项目都没跑通过的人”。6. 聊点实在的智能体项目的定价逻辑和交付边界回到“AI智能体年入百万”这个诱人的说法。我的观点很明确这确实是一个处于上升期的赛道但“捡钱”这个词会严重误导人。真正能持续赚到钱的项目靠的都是把一个细分场景扎进去做深然后建立可复用的交付能力而不是靠信息差赚一票就跑。6.1 为什么说“捡钱”是个危险的错觉我见过不少开发者在网上接单几千块钱帮客户做一个“智能体”。交付的时候演示效果很好客户也很满意。但过了一个月客户拿着真实业务问题来反馈说很多问题答不了。这时候怎么处理如果当初合同里没有写明交付范围和验收标准那就只能陷入无休止的“微调地狱”。所以做智能体项目难点其实不在技术而在于需求边界。客户说“我要一个能回答所有产品问题的机器人”本质上是在说“我要一个能替代半个客服团队的机器人”。这个预期如果不从一开始就管理好后面一定出事。6.2 我曾踩过的一个交付边界坑说一个我早期的真实案例。当时接了一个制造业客户的设备知识库项目商务阶段聊得挺好客户一再强调“先做个能跑的版本看看”。我当时对范围也没多想就按“常见问题问答”来做了。结果演示那天客户的工程师直接拿设备说明书里最冷门的一个参数来问智能体当然答不上来场面一度有点尴尬。后来我复盘问题不在于智能体能力不行而在于需求阶段我没有问清楚三个问题用户会拿哪些问题来问是常见问题还是包含冷门问题什么样的回答算“对”是复述文档原文就行还是需要结合上下文给出操作建议当知识库没有答案时智能体应该怎么办是明确说“不知道”还是引导用户去联系人工这三个问题不搞清楚你做的就只是一个“demo”不是一个“能用”的交付。现在我做项目第一步永远是拉着客户把所有可能的提问类型盘一遍然后一起写出一份二十条以上的QA样例。别小看这步它能帮你省掉后面一大半扯皮。6.3 从“做一个智能体”到“做一门围绕智能体的生意”的关键节点要想让这个方向变成可持续的“生意”我的体会有几个关键节点找到重复度高的细分场景。比如餐饮连锁的“加盟咨询智能体”、律所的“合同审查辅助智能体”、电商公司的“售后安抚智能体”。场景越垂直需求越相似你的方案就越能复用到下一个客户。把交付过程标准化。从需求调研、知识库梳理、智能体搭建、效果评测到上线培训每一个环节都沉淀成模板和检查清单。这样既能控制质量也能缩短周期。把一次性项目变成年度服务。智能体的知识库需要持续更新模型效果需要持续优化。和客户签年度维护协议比每次都接新项目要稳定得多也更符合“让客户真正用起来”的目标。回到最开始那个问题这个赛道还能不能做我的答案是能但它不再是那种靠一个想法就能捡钱的赛道了。它变成了一个需要技术、运营、项目管理综合能力的专业赛道。谁的交付更稳、更懂客户业务谁就能在这个赛道里持续分到蛋糕。那些还在研究“如何用智能体一键生成十个爆款文案”的人可能要多花点时间去思考一个更关键的问题你做的智能体到底为客户省下了多少真金白银。