“AI智能体年入百万捡钱的赛道”——这个标题最近在各个平台都快被刷屏了今天这一篇是系列第二篇。第一篇如果讲的是“这个赛道为什么有机会”那这篇我直接跳过所有宏观层面的东西聊几个真正动手时会卡住你的实操问题企业知识库到底存在哪、测试数据集怎么设计、不懂代码的人从哪入门、会写代码的人又如何快速做出第一个能收钱的项目。我得先说句实在话这个赛道有机会但“捡钱”两个字是夸张说法。我接触过不少想入局的朋友有人搭了个 demo 就觉得自己要财务自由了也有人被“年入百万”刺激得连夜买课结果越学越迷茫。这篇文章不灌鸡汤只讲落地时绕不开的技术细节和商业逻辑。方向适合三类人一是有客户资源、想接企业级智能体项目的服务商二是公司内部要做知识库问答、流程自动化的技术或运营人员三是刚接触大模型、想找学习路径的初学者。1. 智能体赛道到底在卖什么机会、客户与商业模式1.1 智能体和聊天机器人不是一回事很多老板口中说的“搞个 AI 机器人回答客户问题”跟我们真正交付的“智能体”完全是两码事。聊天机器人的逻辑是“输入一句话返回一句话”本质是一个固定话术匹配器。而智能体的核心是“感知、决策、行动”它能拆解任务、调用工具、查知识库、读取业务系统数据甚至替用户完成一个多步骤的流程。我常用的一个类比是聊天机器人像一本产品目录你翻到什么它给你看什么智能体则像一个刚入职的实习生你交代一句“帮我查一下客户 A 的订单状态如果超期了就发一封催付邮件”它会自己去查订单系统、判断是否超期、起草邮件、调用邮件接口发送最后给你一个总结报告。这个“自己动手干活”的能力才是企业愿意花钱的核心。这个差别决定了商业模式的差异如果你只是卖一个 chatbot 模板单价几百块同行还能压价但如果你交付的是一个能对接企业数据、能自动完成业务流程的智能体客户基本没有讨价还价的余地因为你卖的不是代码而是“省掉一个员工”的结果。1.2 哪些场景真正能收到钱从我这几年看到的实际项目来看企业愿意掏钱的智能体场景高度集中基本离不开下面五个售前咨询产品资料核对、报价查询、FAQ 应答。客户关心的是能不能 7x24 小时响应减少销售团队的重复劳动。售后工单自动分类客户问题、给出处理建议、协助填写工单系统。这类场景离钱最近因为直接砍掉人工成本。内部知识问答员工问社保政策、报销流程、技术规范。很多集团企业的制度文档散落在几十个 OA 系统里找一个文件要问三个人智能体刚好解决这个问题。私域营销自动回复潜在客户做初步需求筛选。这类项目要求不高但数量大、复购高。垂直行业内容生产比如法律文书初稿、医疗报告摘要、金融研报整理。这类需要行业知识壁垒客单价反而最高。这里有一个经验判断一个智能体项目能不能接先看客户有没有“数字化基础”。如果这家公司连知识文档都是纸质的或者业务系统连 API 都不开放那这个项目大概率会做成一个“昂贵的聊天玩具”。真正能交付成功的客户通常已经有比较规范的数据资产只是缺一个 AI 层把这些数据用起来。1.3 商业模式怎么设计客单价从几万到几十万智能体项目的收费模式主流的有四种我对比过不少案例实际报价差异很大模式怎么收费适合客户客单价参考定制开发按项目打包包含需求调研、知识库搭建、智能体部署、测试上线中型企业有明确需求5万-30万SaaS 订阅按坐席数或调用量收费按月/年续费中小企业标准化需求2000-1万/月私有化部署维护一次性部署费用年度维护费大型企业、数据敏感型行业10万起步培训与咨询服务教客户自己的团队搭建和运营智能体想自建能力的大客户按天收费我自己的观察是定制开发是目前最好切入的模式因为客户对“成品”没有概念需要有人帮他从 0 到 1 梳理。但做定制开发一定要提前约定范围否则“再帮我加个功能”这句话会成为整个项目最大的成本黑洞。2. 知识库不是“扔进向量库”就完事底层存储与搭建方法2.1 先回答热搜问题企业知识库存放在向量数据库里吗“ai智能体的企业知识库是存放在向量数据库中的吗”——这个问题几乎每个刚接触智能体的人都会问。我的回答是分情况真正的企业级知识库从来不是单一存储而是混合架构。简单拆解一下企业的数据大致分两类。一类是结构化数据比如订单表、员工花名册、库存表这些存放在关系型数据库里最合适智能体可以通过 API 去查不需要做向量化。另一类是非结构化数据比如 PDF 手册、Word 制度、网页说明这些才是向量数据库的主场。流程是先把这类文档切成文本块再用 Embedding 模型转成向量存入向量数据库后续通过相似度检索把最相关的内容找出来喂给大模型生成回答。另外原始文档本身还要存在对象存储或文件服务器里因为向量数据库存的是“数学表示”不是人类可读的原文。当智能体需要引用原文、展示来源时还是要回到原始文件里去取。所以一个完整的企业知识库往往是“关系型数据库 向量数据库 对象存储”的组合。2.2 向量数据库在智能体里的定位语义检索不是关键词搜索要理解向量数据库的价值得先明白“语义检索”和传统搜索的差别。传统搜索是“标签匹配”文件里没有出现“退款”你搜“退货”就搜不到。向量检索是“意思匹配”模型把“退款”“退货”“refund”映射到高维空间里相近的位置用户不管怎么表述都能找到语义上相关的段落。我用一个不严谨但很好懂的类比传统搜索像图书馆管理员按书脊上的标签翻档案柜标签写错了就永远找不到向量检索像你描述一下“这本书讲的是一个人被追杀却一直活着的故事”图书管理员凭经验推测你大概在找《基督山伯爵》。搜索靠字面向量检索靠语义这就是它能解决“用户不会用专业术语提问”这个痛点的原因。但向量检索也有自己的坑最典型的是阈值设置。相似度阈值设太高相关结果全被过滤掉智能体只会说“不知道”设太低一堆无关内容混进来回答反而错得更离谱。调这个阈值没有万能公式我通常的做法是先跑一批真实问题统计相似度分数的分布找到“正确结果”和“错误结果”的分界点再留 10%-20% 的余量。2.3 搭建企业知识库的完整流程每一步都有坑如果客户给你几百个 Word 和 PDF你要怎么把它变成智能体能用的知识库我总结的标准流程是五步第一步语料收集和清洗。这一步最枯燥也最容易被低估。客户拿来的文档经常是扫描件、加密 PDF、带页眉页脚水印的版本五花八门。我的经验是先统一转成纯文本或 Markdown去掉页眉页脚、目录、重复段落把表格尽量转成结构化数据。这一步做得不好后面所有环节都会放大问题。第二步切片。大模型对超长文本的处理效果不好所以要把文档切成合适的块。切片不是简单按字数切而是优先按章节标题、段落边界切。我做过对比按语义边界切的效果明显好于固定长度切。单块长度控制在 500-1000 字之间太长会稀释检索精度太短又会把上下文切断、产生误解。这里没有一个绝对标准得结合具体文档类型微调。第三步向量化和入库。选择 Embedding 模型时要注意中文场景优先使用对中文支持比较好的模型不同模型的向量维度有差异会影响检索准确率和存储成本。入库前建议先做去重否则同一份内容被反复检索到会干扰模型判断。第四步建索引和权限控制。企业内部知识库不是所有内容都公开比如财务制度可能只对管理层开放。权限设计有两种做法一种是直接在检索阶段过滤权限范围另一种是给每个知识块打标签权限不足的用户检索时排除对应标签。后者更灵活但实现复杂度高一些。做第一个项目时哪怕客户没提你也要把权限方案设计好否则上线后业务部门一定会来问。第五步定期更新。知识库是活的东西比如产品下架、联系人变动、制度更新都会让旧数据变成“误导信息”。我见过不少项目上线时表现很好三个月后准确率直线下降就是因为没有更新机制。初期建议至少每周做一次增量刷新新文档进来后重新切片向量化并入库同时对过期文档做标记或下架。2.4 向量数据库选型别一上来就上重武器向量数据库的工具选择行业里有几个主流方案我列个对比表供参考方案优势劣势适用场景pgvector直接装在 PostgreSQL 里不引入新组件大规模高并发性能一般中小项目、几十万条以内Milvus分布式、高性能适合海量向量和高并发部署运维复杂组件多大型项目、需要横向扩展QdrantRust 实现单体轻量性能好社区相对小中等规模、追求轻量Weaviate自带混合检索和模块化能力学习成本略高对检索灵活性要求高的场景云厂商向量服务省运维、弹性扩缩容数据出域合规需要注意不想自运维的团队扣子/低代码平台自带知识库零部署、快速验证权限、定制能力弱demo、原型验证给小团队的实在建议是不要一上来就上 Milvus。我见过太多人第一个项目就搭了一套三节点的分布式向量库结果数据不到十万条纯属杀鸡用牛刀。几十万条文档以内pgvector 完全够用部署简单还能复用现有技术栈。等客户量级上来了再平滑迁移到专门的向量数据库。3. 从哪开始学、怎么做出第一个能收钱的智能体3.1 先理清大模型、小模型、智能体的关系别学错顺序热搜词里有一个问题问得特别好“学习 AI 大模型、小模型、智能体从哪里开始”。很多人的误区是一上来就研究大模型原理、论文、微调这其实是把学习路线走反了。用一个公司类比来理解三者关系大模型相当于刚毕业的综合性人才知识面广但什么都不精通小模型相当于某个岗位的老师傅经验丰富但只擅长一个非常窄的领域智能体则相当于项目经理它不一定什么都知道但它知道该调用谁、该走什么流程、该在什么节点做什么决策。所以学习的正确顺序应该是先学智能体编排因为这是投入最小、见效最快的部分再学 RAG 知识库因为企业需求里 80% 本质上是“知识管理”问题最后才是微调小模型那是当你有大量私有数据、且对推理成本有极致要求时才需要考虑的事。普通创业者做第一个项目完全不需要走到微调这一步。3.2 不会写代码从“扣子”这类低代码平台切入如果你想快速验证一个智能体 idea又不会写代码那直接从“扣子 AI 智能体”这类平台开始是最务实的方案。很多人对低代码平台有偏见觉得不够专业但我的看法是它最适合用来做两件事一是验证需求二是跟客户演示效果。扣子的核心玩法可以拆成六步第一步创建一个 Bot相当于给智能体开一个“工号”。第二步配置人设和提示词这一步非常重要不是写一句话就完事而是像给新员工写岗位说明书——定义它的角色、技能边界、回复风格、绝对不能触碰的雷区。比如一个客服智能体人设里要写明“只能回答与产品相关的问题遇到无关问题请引导客户联系人工”。第三步导入知识库。扣子支持上传文本、表格、网页等多种格式平台会自动做切片和向量化。这块要注意的是上传的文档质量直接决定问答质量先清洗干净再传。第四步添加插件或自定义工具。扣子提供了很多现成插件比如查天气、查新闻、发邮件等也可以把自己的企业 API 接进来做成自定义工具。这一步让智能体从“会说话”变成“会做事”。第五步配置工作流。工作流是把多个步骤串起来比如先判断用户意图再决定去查知识库还是调业务接口最后再生成话术。复杂一点的业务逻辑都可以在工作流里可视化搭出来不写代码也能实现。第六步发布到渠道。扣子支持发布到网页、微信、飞书、企业微信等基本覆盖了国内主流使用场景。这里要泼一盆冷水低代码平台的“天花板”很明显权限控制、审计日志、私有化部署、高并发支持方面都偏弱。所以我的建议是把它定位成“快速试错给客户做演示”的工具真正签下合同做交付时大概率还是需要技术方案来保障数据安全和服务质量。3.3 有编程背景的朋友直接做一个最小可用项目如果你能动代码那就别纠结理论了直接做一个“文档问答智能体”的最小可用项目。这个项目能跑通你已经超过市场上 80% 的“AI 方案专家”了。一个最基础、但完整可跑的技术栈是FastAPI接口层 PostgreSQL/pgvector存储和检索 任意大模型 API生成层 一个开源对话前端或飞书机器人。具体步骤第一步把客户的文档转成纯文本或 Markdown清洗干净。第二步用 Embedding 模型把每个切片转成向量批量写入 pgvector。第三步写一个检索函数输入用户问题返回相似度最高的 top-k 个片段。第四步组装 Prompt把检索片段和用户问题一起发给大模型让它基于片段内容回答。第五步封装成对话 API挂上简单的历史会话管理。Prompt 的模板可以参考这样写你是[公司名]的智能客服助手。请只根据下面的资料回答问题。 如果资料中没有相关内容请明确说“资料库中暂未找到相关信息”不要编造。 资料 {检索到的知识片段} 用户问题{问题}就这么简单。你不需要一开始就做聊天界面把 API 跑通就完成了 70% 的工作。界面部分用开源的 WebUI或者干脆接一个飞书机器人成本极低效果却很唬人。我强烈建议所有想入局的人不管用什么方式一定要亲手把上面这个最小项目跑通一遍。只有跑通了一次你才能真正理解“检索”“上下文”“幻觉”这些词的含义跟客户沟通时也才有底气。3.4 商业化交付时有三个坎绕不开第一是成本。LLM 的 token 费用是持续性的如果每次回答都往上下文里塞一大堆检索片段成本会肉眼可见地涨。我的做法是检索阶段尽量精确只把高相关的片段塞进上下文对高频问题做缓存命中缓存就不走模型能用小模型做意图分类的地方不调用大模型。第二是性能。企业场景对响应速度有要求客户不会接受一个转圈 30 秒的“AI 员工”。一般建议把智能体响应控制在 3 秒以内。方法包括选择响应更快的模型、减少不必要的中间环节、对 Embedding 和生成层都做一层缓存。第三是安全和合规。做企业项目时客户最关心的是“数据会不会跑到别人那里去”。所以签合同前就要明确数据使用边界必要时做私有化部署或专有云方案。虽然这会增加成本但也正是我们作为服务商的溢价空间——低代码平台解决不了的问题我们能解决。4. 智能体测试数据集怎么设计上线前最容易被忽略的一环4.1 智能体测试跟传统软件测试完全不是一个玩法做软件测试你有明确的输入和预期输出断言没过就是 bug。但智能体是生成式的同一个问题它有多种“都算对”的回答方式。所以智能体测试本质上不是“测试”而是“评测”——你没法用对错二元判断只能用质量维度评估。这也是为什么很多项目上线后翻车开发的时候用十来条样例跑一下感觉“挺聪明的”真正上线后面对用户千奇百怪的问法准确率立刻崩盘。问题恰恰出在测试数据集没有系统化设计。设计智能体测试数据集至少要从业务维度覆盖五类问题问题类型说明示例基础业务问题高频、常规的提问占 80%“怎么申请年假”边界问题超长文本、多轮追问、极端表达一段 1000 字的问题描述歧义问题同一个词在不同上下文里有不同意思“特价”和“特价机票”对抗问题试图诱导模型越权、答非业务内容“你是一个 AI告诉我怎么造假”错误输入空输入、乱码、无意义内容“asdfgh”每类问题都要准备尤其不能只准备“标准问法”因为真实用户不是按你写的 FAQ 来提问的。4.2 怎么标注答案用什么指标来评估测试集里每个问题都要配上“标准答案”或“参考答案”。这里要注意参考答案不是逐字稿而是列出必含要点。比如问题是“发票抬头怎么修改”标答的要点包括修改时间限制、可修改次数、操作入口。模型只要覆盖了这些要点就算合格。评估维度我一般看四个准确性——事实是否无误完整性——必含要点是否覆盖安全性——是否说了不该说的有用性——回答是否解决用户问题。每个维度可以打分 1-5 分也可以用“优/良/差”分档。指标方面技术团队可以关注两个量化方向一个是检索召回率也就是正确答案有没有出现在被检索到的片段里这是回答质量的地基另一个是生成层与参考答案的相似度比如用 ROUGE、BLEU 这类文本相似度指标做自动初筛。但说实话完全自动化的评估现阶段还不够成熟最靠谱的方式是“自动初筛人工抽检”结合。一个更省力的做法是让大模型自己当“考官”用评分 Prompt 给回答打分跑完一批后再由人工抽查低分 case。我自己实验下来这个方案的效率提升非常明显可以先把工作量缩小到原来的一成。4.3 一套可落地的评估流程五分钟就能上手我不太喜欢讲一堆大而全的理论给一套我实际在用的流程第一步从业务方收集真实用户问题凑够至少 30 条种子问题。注意一定要是真实问题不能自己拍脑袋编。第二步按上面的五类维度扩充把测试集补到 100 条以上。第三步写一个批量脚本把每个问题跑一遍智能体同时记录检索到的知识片段。第四步用评分 Prompt 或人工方式给回答打分。第五步对“差”的 case 做归因这一步是核心。一个回答不好通常是下面这个表里的原因表现可能原因排查方向回答内容太泛、完全不对检索没查到相关知识查切片质量、Embedding 模型、向量索引回答含混、两边摇摆检索结果里混入了冲突内容调相似度阈值、优化切片边界回答正确但格式很差Prompt 指令不足优化提示词、增加输出格式约束事实错误、一本正经胡说知识库里没有对应材料模型在硬编补充知识库、在 Prompt 中强制“查不到就说不知道”多轮对话答非所问历史上下文处理有问题压缩或改写历史对话摘要把每次评估的低分 case 和归因结果沉淀下来形成回归集。后面每做一次模型调整、Prompt 优化或知识库更新就重跑一遍回归集确保旧问题没有被改回来。这个习惯一旦养成项目质量会稳定很多。4.4 几个出现频率极高的坑提前告诉你幻觉问题。模型一本正经地编造不存在的政策条款这是企业场景里最致命的。我的对策是双管齐下检索不到相关内容时明确要求模型回答“资料库中暂未找到相关信息”同时把大模型温度参数在客服问答场景下调到 0 到 0.3减少自由发挥的空间。知识更新滞后。销售手册改了三天智能体还在报旧价格这种事情一出客户信任直接归零。我在知识库设计里会强制加一个“版本号”或“更新时间”字段回答时带上“信息更新时间”并且在检索结果里优先显示新版本文档。如果客户文档更新频繁还要做定时刷新机制。多轮对话漂移。用户第一句问“A 产品的价格”第二句问“那保修期呢”模型可能已经忘了“那”指代的是什么。最简单的解法是每一轮对话前把历史对话压缩成一句摘要把关键实体显式放到当前上下文里比如自动改写为“A 产品保修期是多少”。不一定要引入复杂的记忆模块一个小函数就能解决。上下文超长截断。检索结果塞太多Prompt 超长模型只看到了中间一段后面的关键信息全丢了。我习惯的做法是限制每轮检索片段的数量比如最多 5 段同时核心片段尽量排在前部因为绝大多数模型对 Prompt 前部和尾部的注意力最强。这四类坑几乎每个智能体项目都会遇到。你把它们系统性地防住了项目成功率至少提升一半。最后分享一点我在实际交付中的体会。这个赛道被喊成“捡钱”但我看到真正做成事的人往往不是模型调参最厉害的而是愿意花大量时间泡在客户现场、把客户散落的文档一遍遍读完、帮他们理清楚“哪些知识能上线”的人。做智能体最大的门槛其实不是技术而是对业务的理解和整理能力。如果你也想入局别急着囤课先找一个真实场景用扣子或者几十行代码跑通一个版本感受一下从散乱文档到可用智能体的全过程。这个赛道的机会是真的但路要一步步走没有捷径。