去年年底有个做B2B工业设备的客户找我，说他们公司花了两万块找外包搭了个企业Agent，演示的时候确实能跟客户聊天，问产品参数、问价格区间都能答上来。但真正想让它根据客户需求自动生成一份报价单，就完全不行了——要么参数选错了配套，要么价格逻辑对不上，要么格式乱七八糟根本没法发给客户。老板很郁闷，说演示的时候明明挺好的，怎么一上线就拉胯了。
我看了他们那个Agent的底层架构，问题很典型。外包团队用的是某个零代码平台，接了个通用大模型，把产品手册PDF扔进知识库，做了个简单的对话界面就交付了。这种东西做演示绰绰有余，因为演示的时候你问的都是标准问题，模型从PDF里检索到原文回答就行。但真正要”干活”——比如根据客户的产品选型、数量、交期、付款方式算出一份准确报价单——靠检索PDF是远远不够的，它需要理解你的业务逻辑，需要对接你的定价系统，需要按照你的报价模板输出结果。
我接手之后花了三周时间帮他们重新搭了一套Agent自动报价系统，从需求拆解到知识库设计到业务系统对接再到上线调试，整个过程的每一步都有坑。今天我把这个过程完整拆开讲，不只是说技术怎么做的，更重要的是说从”能聊天”到”能干活”中间到底差了哪些东西，这些东西才是决定你的Agent项目能不能真正落地的关键。
说句实在话，我在95星球企服帮好几家企业搭过Agent，发现一个规律：能跑通demo的Agent很多，但真正能上生产干活的不到两成。差的不是大模型够不够聪明，而是从demo到生产之间那几层业务逻辑和工程化工作没做。下面我一层一层说。
demo能跑通不代表生产能用——差距在业务逻辑深度
先说第一个核心差距：业务逻辑的深度。
绝大多数Agent demo做的事情是”信息检索”——你问一个问题，它从知识库里找到相关内容，用自然语言回答你。这种场景大模型很擅长，因为本质上就是阅读理解。但企业真正需要的Agent不是给你背书的，是帮你干活的。干活意味着它要理解你的业务规则，要按照你的流程走，要输出符合业务标准的结果。
拿报价这个场景来说。客户来询价，说”我要采购50台型号A的设备，带配件B和配件C，交期30天，含税含运费”。一个能干活的Agent需要做到什么？
它得先理解客户的选型是否合理——型号A能不能配配件B？配件C跟型号A是兼容的还是需要转接件？这些信息不是写在PDF里的，是存在你的产品配置规则库里的。然后它要根据客户数量查阶梯价格表——50台是什么价格区间，有没有批量折扣。接着算交期影响——30天交期需不需要加急生产费。最后把所有费用汇总，按照你们公司的报价单模板生成一份PDF或者Excel。
这里面每一步都是业务逻辑，不是大模型靠”理解”就能搞定的。你在demo里问”型号A多少钱”，它从PDF里翻出标价告诉你，你觉得很厉害。但你让它真正算一份报价，它需要的不是PDF里的文字，而是一套结构化的定价规则引擎。
所以我在帮这个客户搭系统的时候，做的第一件事不是选大模型，不是搭对话界面，而是花了整整三天跟他们的销售总监和报价工程师坐在一起，把报价的完整流程画成了一张流程图。从客户询价进来，到选型确认，到价格计算，到交期评估，到报价单生成，每一步的输入是什么、输出是什么、判断条件是什么、异常怎么处理，全部写清楚。这张流程图后来成了整个Agent系统的骨架，大模型只是骨架上的一个执行节点而已。
知识库不是堆文档——报价场景的数据结构怎么设计
第二个差距在知识库的设计。我见过太多企业做Agent，知识库就是一锅粥——把所有PDF、Word、Excel往里一扔，让大模型自己去找。这种方式做简单问答也许行，但要做报价这种需要精确数据的场景，必须把知识库结构化。
我帮这个客户设计的知识库分了四层。
第一层是产品主数据。每个产品的型号、名称、技术参数、标准配置、可选配件、兼容性矩阵，全部用结构化表格存储。大模型在做选型确认的时候，不是去PDF里翻”型号A可以配什么配件”，而是直接查结构化表格，结果100%准确。
第二层是定价规则。基础价格、阶梯折扣、季节性调价、大客户专属折扣、配件加价规则、运费计算规则，每一条都是一条可执行的规则，而不是一段描述性文字。Agent在算价格的时候调用这些规则，而不是让大模型去”理解”定价策略。
第三层是客户档案。不同客户的协议价格、历史报价记录、信用等级、付款条件偏好，这些信息存在CRM系统里，Agent在生成报价时自动调取，保证给同一个客户的报价策略是一致的。
第四层才是非结构化内容——产品手册、技术白皮书、行业案例。这些内容主要给Agent在做技术答疑时用，作为前三层结构化数据的补充。
你发现没有，前三层根本不是传统意义上的”知识库”，更像是业务数据库加上规则引擎。大模型在这个过程中扮演的角色是”理解客户意图、调用正确数据、组织输出语言”，而不是”从一堆文档里找答案”。这个认知转变，是从demo到生产最关键的一步。
Agent接业务系统才是”干活”的开始
第三个差距是系统对接。demo阶段的Agent通常是个独立系统，你跟它聊天它回答你，完了。但生产环境的Agent必须跟你的业务系统打通，否则它就是个高级聊天机器人。
在这个报价系统里，Agent需要对接三个外部系统。第一个是CRM系统，用来读取客户档案和历史报价。第二个是ERP系统，用来查实时库存和生产排期，因为报价里要包含交期信息，交期取决于当前产线排到什么时候。第三个是OA审批系统，因为超过一定金额的报价需要销售总监审批后才能发给客户。
对接这三个系统花了我将近一周的时间，比搭Agent本身的对话逻辑还费劲。CRM的API文档不全，我反编译了他们的前端请求才搞清楚接口格式。ERP没有开放API，只能通过中间数据库做数据同步。OA系统的审批流程是固定的，Agent生成的报价单要走审批的话，得按照OA的格式提交审批工单，这里面涉及一堆字段映射和状态同步的问题。
但这一步不做，你的Agent就永远停留在”能聊天”的阶段。它告诉你”型号A的参考价格是X万”——这只是信息检索。它帮你算好完整报价、走完审批流程、生成标准报价单发到你邮箱——这才叫干活。中间差的这一大段系统对接工作，是很多企业在规划Agent项目时完全没有预估到的成本。
我后来跟这个客户的老板复盘的时候说，你花两万块搭的那个demo，其实连整个项目的十分之一都没做到。真正让Agent干活的部分——需求拆解、知识库结构化、业务系统对接、异常处理、上线调试——这些加起来才是大头。但这些你在厂商的PPT上是看不到的，PPT只给你看那个漂亮的对话界面。
上线后的调试比你想象的多——这3个问题必须盯着
最后一个差距是上线后的持续调试。很多企业以为Agent上线了就万事大吉，实际上线后的头一个月才是最累的。我帮这个客户上线后的第一周，每天都在盯日志、改规则、调参数。主要有三类问题你得特别注意。
第一类是意图识别不准。客户说”我要A型号带全套配件”，Agent理解成”只要A型号加配件包”，少了两个单独的配件。这种问题在大模型层面很难完全消除，我的做法是加了一层校验——Agent理解完客户需求后，先生成一份选型确认单发给客户确认，客户点了确认才开始算报价。多了一步确认，准确率从75%左右拉到了98%以上。
第二类是规则冲突。定价规则里有”大客户享9折”和”促销期间所有客户9.5折”两条规则，当一个既是促销期又符合大客户标准的客户来询价时，Agent不知道该用哪条。这种冲突在规则不多的时候不容易暴露，但随着规则越加越多迟早会碰到。我的处理方式是给每条规则设了优先级，冲突时按优先级走，同时把冲突记录下来定期人工复核。
第三类是数据同步延迟。ERP的库存数据每15分钟同步一次到中间库，Agent报的交期是基于15分钟前的库存状态算的。有一次客户刚下了一个大单把库存清空了，但Agent还按有库存的状态报了交期，导致报价里的交期承诺无法兑现。后来我加了一个实时校验——报价生成前直接调ERP接口查一次最新库存，虽然多了一两秒延迟，但交期准确了。
这三类问题不是上线前能全部发现的，必须在真实业务流量下跑一段时间才能暴露出来。所以我给客户的建议是，Agent上线后的第一个月一定要安排专人盯着，每天检查异常日志，发现问题马上改，不要等问题攒多了再批量处理。一个月之后系统基本稳定了，维护频率可以降到每周检查一次。
回到最开始那个问题——企业Agent从能聊天到能干活到底差了什么？差的不是大模型，不是对话界面，不是知识库有没有文档。差的是你对业务逻辑的拆解深度、知识库的结构化程度、业务系统的对接完整度，以及上线后的持续调试耐心。这些工作不性感，不会出现在PPT的演示页面上，但它们才是决定你的Agent能不能真正帮你干活的东西。如果你正在规划企业的Agent项目，先把这几件事想清楚再动手，能帮你省掉后面大量的返工。
需要相关服务？联系我们免费咨询
九五星球企服提供公司注册、代理记账、商标注册、财税咨询、高新申报、网站开发等一站式企业服务。可以先免费咨询看看，觉得合适再合作，不推销。
免费小工具推荐：
联系方式：
- 电话/微信：18910232032
- 扫码添加专业经营合规顾问，免费咨询 ↓
