2024年我从杭州回到西安和两个老同事注册了一家智能体开发公司方向很明确只做垂直行业智能体不碰通用聊天机器人。两年多下来最大的感受是这里的市场和北上广完全是两个世界——客户不关心你用了什么模型只关心你能不能解决他车间里的老师傅退休后没人会修设备的问题、业务员离职后客户跟单断档的问题、以及领导忽然要一份报表却没人会查数据库的问题。到了2026年西安本地的制造、能源、贸易企业开始主动打听智能体怎么落地我们的项目从单个定制变成行业复购。这篇东西就是我在西安做垂直行业智能体开发和本土落地实践的全过程复盘适合想在这个方向创业的团队也适合正在帮传统企业做AI转型的技术负责人。1. 西安市场的真实需求盘点谁在买单买单要什么1.1 本土企业客户的典型画像在西安待久了你会发现真正的企业客户不是高新区的互联网公司而是散布在各开发区、产业园里的制造企业、贸易公司、能源配套商和职业院校。这些客户有几个共同特征年营收几千万到几个亿IT部门只有两三个人甚至没有专职IT内部数据散落在ERP、Excel、纸质单据和企业微信聊天记录里管理层听说AI很火但说不清具体能干什么。我们接到的第一类典型需求来自一家做汽车零部件的工厂。他们的采购负责人在展会上看了我们的演示回去就跟老板汇报说这东西能让新来的质检员少问老员工问题。第二类典型需求是一家做外贸的小公司七八个业务员每天有一半时间在回复重复的询盘、查报关政策、翻译客户邮件。第三类来自一所职业技术学院他们想把实验课的选择式问答搬到线上让每个学生都能有自己的AI助教。这三类客户决定了我们的产品形态不是做一个大而全的智能体平台而是针对每个行业的痛点做知识库工作流系统对接的垂直解决方案。2026年回头看这个判断是对的通用智能体在西安几乎没有付费场景垂直行业智能体才是企业愿意掏钱的形态。1.2 客户以为的智能体和我们要交付的智能体不是一回事绝大多数客户第一次来咨询开口就是我们要做一个AI客服。但聊到第二轮就会发现他们真正要解决的不是客服问题而是业务流程跑不通的问题。比如那家外贸公司表面上是需要回答客户关于产品规格、交期、付款方式的问题实际上需要的是根据客户邮件内容自动填写报价草稿、从历史订单里找出类似产品做参考、把新的询盘自动归类进不同的业务组。这三个动作如果只用AI客服去承接效果一定很差。所以我们定制了一套需求澄清流程核心是一个选择式问答清单你希望智能体知道哪些信息产品手册、流程文件、历史问答记录你希望智能体能操作哪些系统ERP、CRM、数据库、企业微信哪些问题是必须给出标准答案的报价、审批、合规哪些问题是允许它凭已有知识发挥的介绍、解释、建议回答错了会造成什么后果有没有人工兜底这个清单看着简单但它能帮客户把他们脑子里的模糊想法转成可落地的产品边界。很多项目能不能成在需求澄清阶段就已经决定了。1.3 真正能成交的三个行业切入口两年多跑下来西安市场真正能形成付费意愿的垂直行业智能体集中在三个方向垂直知识库问答RAG制造和能源行业最普遍的需求。设备维修手册、安全操作规程、质量检验标准这些文档动辄几百页老师傅凭经验知道答案新员工翻半天找不到。用RAG把文档变成智能问答是投入产出比最高的切入点。销售跟单与商品推荐企业有明确的决策链和ROI可算。一个销售智能体如果能让新人快速掌握产品卖点、自动生成报价方案、根据客户历史偏好推荐商品老板很愿意为它付费。教学与培训场景高校、职业院校、培训机构的预算相对稳定。选择式问答、实训辅导、作业批改助手这些需求在学校里是明确的痛点而且采购周期清晰、回款也稳定。这三个方向不是我们凭空想出来的都是被客户需求推着走才逐渐聚焦的。2. 框架选型不能只看热度从Dify到自研的取舍逻辑2.1 为什么低代码平台是本地项目的第一选择智能体开发的热门词汇每年都在变2025年最火的是各种Agent框架和多智能体平台很多团队一上来就自研编排引擎。但我在西安做垂直行业项目第一选择永远是Dify、扣子这类成熟平台理由不是技术而是交付后的可维护性。本地企业客户几乎没有一个专职的AI工程师。项目交付后客户那边真正每天在用的是业务部门的人比如质检主管、外贸跟单员。他们遇到智能体回答不准的情况第一反应是改知识库、调提示词而不是看代码日志。Dify这类平台最大的价值是让业务人员不用写代码就能维护智能体。我们把系统文档、提示词、知识库结构都迁到平台里客户的项目经理经过半天培训就能自己换零件、调参数。扣子平台在有些场景下甚至更合适尤其是客户不想折腾私有化部署、只想要一个能快速上线的内部工具时。但如果是制造业客户、数据不能出内网的场景Dify社区版的私有化能力就成了刚需。我的结论是先别管框架是不是先进先问客户谁能长期维护这个系统。2.2 多智能体框架在什么阶段才需要2025年多智能体成了行业热词AgentScope、各种多智能体编排框架铺天盖地。但我必须说一句得罪人的话很多项目把简单问题搞复杂了。一个智能体能解决的不要拆成三个。多智能体的代价是调试难度指数级上升、回答延迟变高、错误来源变多对一个只有两三个人维护系统的客户来说可能是个灾难。我自己的判断标准很简单场景建议方案原因单个领域知识问答问题简单直接单智能体RAG维护简单效果稳定需要先收集信息再查系统最后汇总答案单智能体工作流用步骤控制逻辑不需要多个Agent不同领域的知识必须隔离比如财务问答和设备维修问答多智能体按领域拆防止知识串味、提示词互相干扰需要多个角色协同比如一个角色写草稿、一个角色做审核多智能体MCP/API角色边界清楚各自动作可审计我们真正启用多智能体是在一个销售跟单项目里一个Agent负责从邮件中抽取客户需求一个Agent负责查询历史订单和库存一个Agent负责根据报价规则生成方案最后还有一个审核Agent检查数字是否一致。每个Agent的知识库和工具权限完全隔离这样才不会出现销售方案里混进了设备维修的内容这种事故。2026年的现状是多智能体不是不能做而是必须建立在单智能体已经跑通、业务边界足够清晰的前提下。2.3 MCP、RAG、工作流的组装顺序最近客户和同行问的最多的问题就是智能体怎么和业务系统打通MCP和RAG到底先做哪个。我的经验是大部分垂直行业项目里打通业务系统的优先级应该高于灌知识库。很多团队拿到项目先做RAG把一堆PDF丢进向量库模型确实能回答知识问题了。但客户一句话就能把你问住那上周的订单金额是多少这种问题根本不在文档里而在ERP数据库里。如果不在前期就设计好工具调用API、MCP、数据库查询最后还得返工接系统。我推荐的组装顺序是梳理任务清单标出哪些是读文档能答的哪些是查系统才能答的先把工作流搭出来把任务的先后依赖关系定死接系统和工具调用MCP/API/数据库连接确保事实性数据有源可查再补RAG知识库覆盖制度文档、产品手册、经验总结这类非结构化内容最后统一调提示词让模型知道什么情况下调用工具、什么情况下检索文档、什么情况下直接回答这个顺序帮我们避开了很多坑。RAG做得再好回答不了系统里的实时数据客户一样觉得不智能。3. 把一个智能体真正塞进业务流程交付层面的关键设计3.1 权限与私有化部署本土客户最在意的不是模型能力做西安的制造业客户项目多了以后我发现一个规律他们第一关心的不是智能体聪明不聪明而是数据能不能留在我内网。很多企业有自己的保密要求产品图纸、工艺参数、客户信息都不能传到外部API。这句话基本决定了技术方案的天花板。所以我们在投标或方案设计阶段都会明确问三个问题这个智能体要处理的数据里有没有涉密或敏感数据是否允许调用云端大模型API还是必须全部在内网跑客户现场能不能提供GPU服务器没有的话CPU推理能不能接受如果是纯内网部署模型一般选择开源模型而不是API。Dify平台可以接入本地模型向量库用内网部署的向量数据库Embedding模型也用本地的。整个链路全部内网化客户才敢把真正的生产数据喂进来。这里有一个容易被忽略的细节本地部署的模型和云端API的性能差距是肉眼可见的。所以要在项目启动前就和客户对齐预期明确内网环境下回答速度会慢一些复杂推理能力会有上限避免交付时被吐槽怎么和你们演示时不一样。3.2 RAG落地中的数据清洗与知识库维护做了一堆RAG项目之后我敢说80%的效果问题出在源文档上而不是模型上。客户给的PDF经常是扫描件、表格错位、目录混乱、同一个知识点在不同文件里说法不一。如果直接切块丢进向量库出来的答案一定让人失望。我们现在每个RAG项目都有一套固定的数据清洗流程先做文档去重把内容相近的版本合并扫描件先OCR人工抽检至少两页确认识别准确率表格统一转成结构化文本因为纯文本切块会把表格拆散按目录结构切块起始点放在章节标题避免语义在中间被切断重叠窗口切块通常前后各重叠100-200字防止跨块信息丢失切块后还要做一轮检索调参。默认的top_k往往不够用要根据文档量和问题类型调整。这块没有标准答案只能一个项目一个项目地试。知识库上线只是开始真正的难点是持续维护。我见过太多项目上线时智能体回答得很漂亮三个月后客户发现新文档加不进去、旧数据更新不生效系统就荒废了。所以交付时一定要帮客户建立更新机制新增文档走什么格式、谁来审核、什么时候重新做向量化。这些写进运维手册甚至写进合同的服务条款。3.3 评测与验收怎么证明智能体好用智能体到底做得好不好这个问题如果答不上来验收就是一场灾难。客户觉得哪里不对又说不清你也不知道该改哪里。所以我们现在每个项目必须建一套垂直领域的评测集用数据说话。我常用的一张验收维度表维度具体指标评测方法答案准确率参考答案一致的比例人工抽测规则判断检索命中率返回的知识片段是否来自正确文档检查Top-K结果的相关性多轮对话成功率上下文不丢失、指代能正确解析按预设对话剧本回放超时率单次响应时间是否在可接受范围压测脚本统计知识边界控制不知道的是否直接说不知道设置知识外问题集评测集不是随便找几个问题就行必须来自客户真实的业务场景。我们一般会让客户提供50到100个高频问题再叠加我们自己整理的错误变体组成一个评估集。每次改完提示词或知识库就跑一遍回归评估看分数有没有下降。这个习惯救了我们很多次——至少不会出现改好了一个问题弄坏了三个问题的尴尬。如果涉及代码也可以用简单的脚本计算准确率import json evals [ {question: SKU 30012 的库存是多少, answer_docs: [库存表.xlsx], expected: }, {question: 这个订单要审批到哪一级, answer_docs: [订单审批流程.md], expected: } ] def evaluate(predicted, expected_doc): hit 1 if expected_doc.lower() in predicted.lower() else 0 return hit total len(evals) hit_count sum(evaluate(返回结果中的来源, item[answer_docs]) for item in evals) print(f来源命中率: {hit_count / total:.2%})脚本本身不复杂但它把验收从感觉好用变成了指标达标客户和我们都轻松很多。4. 踩坑实录从Demo到生产环境要过的四道坎4.1 客户买的是替班员工不是百科全书我们丢过很多单子大部分不是技术败了而是需求错位。很多客户看到Demo里智能体能回答各种问题潜意识里把它当成了什么都知道的百科全书上线后发现它没答出某个很偏门的问题立刻失望。现在我在项目启动时一定会做一件事明确智能体的支持范围。给它划定领域边界边界之外的问题明确回答不在我的支持范围内请联系相关负责人。表面上这是降低了智能体的能力实际上是保住了信任——客户知道哪些问题可以问也知道问错了会得到什么反馈预期就稳了。业务人员真正要的是一个替班员工知道自己该干什么、不该干什么而不是一个假装全能的聊天机器人。4.2 模型幻觉在垂直场景里的致命性以及兜底策略如果智能体只是讲讲产品介绍模型说错一两个形容词问题不大。但在报价、安全规程、库存查询这些场景里模型一本正经地编出一个价格或者一段操作流程是会出大事的。所以我们给所有垂直场景的智能体都加了硬性的兜底策略。第一个策略所有给出事实性结论的回答必须附上知识库来源或系统数据依据。没有来源支撑的内容模型宁可说我需要查阅更多资料后再回答也不能凭空推断。第二个策略数值类问题不走生成。库存、价格、订单状态这些字段一律通过数据库查询或API获取模型只负责把查询结果转成自然语言。数字的来源必须是业务系统而不是模型的记忆。第三个策略设置置信度阈值。对模型的回答做一次自我评分低置信度的时候转给人工处理。这个策略在一些问答场景里非常有效可以大幅降低错误引导的概率。没有完美模型。落地的时候不是追求模型能不犯错而是设计一套机制让错误不会造成严重后果。4.3 交接文档比代码更重要第一次交付给一家工厂时我们把部署文档和API说明扔给客户就撤了。结果第二周客户打电话来说知识库更新后智能体回答变差了。一查发现是他们把新文档直接传进了系统但没做去重和切块处理导致同一知识点有多个互相矛盾的碎片。从那以后我把交接文档提到了和代码同等的级别。一个完整交付包必须具备系统架构说明哪些组件部署在哪台机器上网络访问关系是什么知识库更新指引文档格式要求、切块规则、向量化步骤提示词变更日志每次调整改了哪个Prompt、影响范围是什么常见问题手册高频报错、恢复步骤、客服联系方式业务侧培训资料面向客户业务人员的操作说明不需要懂技术这些文档不是写给工程师看的是写给客户公司里那个被临时指派来管智能体的行政或业务骨干看的。写清楚这些能减少80%的售后问题。4.4 部署环境参差不齐本地化部署遇到的坑远比你想象的多。有的工厂整个厂区用的还是老旧的网络架构外网访问要层层转发白名单申请要走半个月有的客户现场只有一台老服务器内存32G还要同时跑模型和向量库还有的客户数据库只开放给指定IP智能体应用根本连不上。现在我养成了一个习惯签合同之前先派工程师去客户现场做一次部署环境调研出一份环境清单网络拓扑内网能否访问外部API还是必须全内网服务器资源CPU核心数、内存、硬盘、是否预留GPU系统版本Linux发行版、Python版本、Docker是否可用数据源情况数据库类型、连接方式、有没有只读账号安全合规有没有数据外发限制、日志留存要求别嫌麻烦。环境问题在项目中期爆发代价是整体工期延期这个时间成本远高于提前一趟现场调研。2026年的今天我们接新项目时都把环境调研作为第一道关卡不再让部署问题成为项目延期的理由。5. 团队配置与项目节奏一家西安智能体公司的生存法则5.1 人效模型轻研究、重交付在西安这种非一线城市一线城市那种动辄几十个人的AI研发团队根本不现实。我们目前只养了一个精干小团队核心架构是211两个开发工程师一个负责前端和交互、一个负责后端和AI链路集成一个行业解决方案顾问负责行业调研、客户需求梳理和方案设计一个项目经理兼客户成功负责进度、沟通、培训和售后。这套配置最大的好处是每个项目的决策链路极短客户抛出一个需求当天就能讨论出能不能做、怎么做、报价多少。不会因为组织层级太多把琐碎的沟通成本转嫁到客户身上。如果后续业务量上来我们宁可多招懂行业的实施顾问也不急着堆算法工程师。垂直行业智能体的重点不在攻克技术难点而在理解业务、梳理流程、把系统接好。5.2 项目节奏两周Demo、一个月POC、三个月交付做本地项目节奏感太重要了。一上来就埋头开发等三个星期给客户看成果客户往往早就失去耐心了。我们现在的标准节奏是前两周做一份高保真Demo不追求全流程打通把核心交互和关键答案展示出来让客户看得见摸得着。一个能聊出行业味道的Demo比五十页PPT管用得多。Demo通过后进入为期一个月的POC验证。这个阶段会接真实数据、跑真实场景用评测集输出效果报告。POC阶段可以象征性收费但一定不能免费到底。免费的东西客户不会认真对待也不会珍惜你的投入。POC通过后签正式合同三个月内完成开发和交付。包括系统部署、数据接入、知识库清洗、评测达标和人员培训。这套节奏下一个项目的完整周期大概五个半月客户能看到阶段性的产出我们也避免了长期项目拖垮现金流。5.3 收费模式项目制为主SaaS在2026年还不是主力我们刚开始也想做SaaS订阅一劳永逸。但很快发现西安的量产客户既没有标准化系统也没有像样的IT基础设施通用SaaS根本接不进去。每个客户都要定制SaaS的产品化程度远不够。所以目前的收费模式是项目交付费年度维护费。项目交付费覆盖定制开发、私有化部署和实施按项目复杂度评估。年度维护费覆盖知识库更新、模型迭代、系统巡检和培训支持。收费项内容特点项目交付费定制开发、私有化部署、数据清洗、实施交付一次性覆盖核心成本年度维护费知识库更新、模型迭代、系统巡检、人员培训续费形成稳定收入这个模式的好处是客户决策简单——一次性采购没有续费的陌生感。维护费会在第二年产生复购形成持续收入。缺点是每接一个新客户几乎都要从头搭一套利润率上不去。这也是为什么我们越来越看重产品化把一个行业的交付经验沉淀成可复用的模块。6. 2026年之后垂直智能体的分水岭与西安的机会窗口6.1 从会做到规模化产品化是唯一出路做了大量项目制订单之后我开始意识到一个残酷的问题每个项目都从零开始做定制公司只会越做越累利润也上不去。2026年对智能体开发公司来说最大的分水岭不是技术能力而是有没有能力把项目经验沉淀成产品。我们现在做的是把已经交付过的行业解决方案拆成两层一层是行业知识包包括该行业的高频问题集、知识库结构模板、领域提示词模板、评测集另一层是技术基座包括统一的RAG流程、工作流模板、权限模块、运维脚本。新项目来了先用行业知识包快速生成Demo再用技术基座搭建系统把80%的重复工作固化下来只对20%的客户特殊需求做定制。6.2 细分赛道的预测销售、数据仓库、教学2026年我认为西安市场会出现三个快速放量的垂直智能体赛道。销售智能体西安的贸易和制造业企业有大量销售跟单需求把客户邮件自动转化为报价草稿、销售话术推荐、历史订单匹配这些场景ROI清晰决策链短。数据仓库智能体很多企业积累了十几年的ERP、ERP周边表、Excel台账管理层想看数据只能麻烦IT部门。让业务人员用自然语言查数据是刚需中的刚需。这类智能体的关键在于建模和数据权限技术难度高护城河也深。教学训练智能体职业院校和企业的培训部门有明显付费意愿。选择式问答、实训考核、AI助教这些场景可以按学期复购是一种接近订阅制的商业模式。6.3 给想入局的开发者/公司的建议如果你也想在西安或者类似城市做智能体开发公司我只有几条实在的建议送给你第一不要一上来就做通用智能体平台。通用市场是巨头和资本的游戏本地公司拼不过。选一个行业扎进去泡三个月把客户的业务语言、决策流程、系统链路摸清楚。第二从能成交的小订单开始。做一个500人的工厂知识库问答可能只有两三万预算但也足够你积累第一个标杆案例。案例比技术更重要中小客户特别认同行业的同行经验。第三团队里一定要有能听懂客户业务的人。不是每个写代码的都能和厂长对话。如果你自己是技术出身就找个行业顾问合伙或者逼自己天天泡在客户现场。做垂直行业智能体本质上不是做算法是做服务。能放低姿态钻进客户车间里看工人怎么操作、跟着业务员跑几趟客户的客户比在键盘上调模型的收益大得多。