一、大模型投入不少，业务端为什么还是没什么感觉
这一两年，很多企业都做过同一件事：把大模型接进内部系统，做出一个能对话的入口。新鲜感过去之后再看，一线员工该跑的流程照旧，管理侧该等的汇总照等，投入像是落在了空处。问题往往不在模型本身，而在 AI 智能体被放在了业务流程的哪个位置。
下面这份内容来自 数商云与某制造行业头部集团的一次完整合作。它不属于那种"上线就惊艳全场"的项目，反倒是靠着一个个具体场景慢慢长出来的。把它写出来，是希望正在做 AI Agent 开发、或者正在为企业 AI 智能体落地发愁的团队，能少走一点弯路。
二、客户背景：一家管理颗粒度很细的制造行业头部集团
2.1 业务跨度带来极高的信息密度
这家集团横跨多个区域的生产基地，产品线跨度大，上下游链条长。它的日常运转，靠的是大量写在纸面、存在系统、留在老员工经验里的知识：工艺参数、设备维护要点、质量标准、客户特殊要求、异常处置流程。这些东西不是不存在，而是散落在太多地方。
举个很常见的画面：一台设备报警，现场人员要先在手册里翻故障代码，再去群里问有没有人碰到过，运气好几分钟解决，运气不好就得等工程师回消息。这类场景在制造业里太普遍了，普遍到大家已经习惯了它的低效。
2.2 这家企业其实早就试过大模型
它不是那种对新技术反应迟钝的企业。相反，在行业里算是走得比较早的：内部搭过知识问答入口，也做过面向员工的通用助手。刚推出来的时候大家挺积极，试用的人不少。
问题出在热度退了以后。问工艺参数，答得模棱两可；问某个客户的特殊要求，翻出一段不相关的旧文档；好不容易问清楚了，还得自己复制到另一个系统里填单。员工算了一笔时间账，发现没省下多少，慢慢地就没人点开了。
三、痛点拆解：投入见不到水花，通常卡在这几个地方
接手项目之后，数商云的团队先花时间做了一件事——把这家企业之前的尝试复盘一遍。看下来，问题并不特殊，几乎每一家 AI 智能体落地不顺的企业都会撞上。
3.1 场景定得太大，模型没有着力点
"用 AI 提升生产效率"这类目标听着提气，可模型接不住。它没办法对一句空泛的话负责，只能对一个个具体动作负责：查一份历史工艺记录、判断一次质量异常属于哪类、生成一张待确认的处置单。场景颗粒度不降下来，后面所有的评估都无从谈起。
3.2 知识散在各处，模型看不见真实的业务现场
企业以为自己的知识很完整，其实文档在共享盘里、规范在业务系统里、经验在老师傅的脑子里。模型能读到的那部分往往只是碎片，回答飘忽不定也就在情理之中。
3.3 只做对话，不做动作
这是最容易被忽略的一点。一个只能给建议的助手，本质上还是"搜索框的升级版"。员工拿到建议之后仍然要切换系统、手工录入、再找人确认，省下来的时间又还回去了。智能体如果不能把结果落成单据、记录或者后续流程的触发条件，价值就很难被感知。
3.4 上线当终点，没人管后面的事
项目组撤了，入口还在，但没人看它答得准不准，也没人收集员工反馈。使用的次数一点点变少，最后安静地躺在系统角落里。AI 应用是需要运营的，这一点在很多企业内部还没有形成共识。
四、数商云的解法：让 AI 智能体贴着业务流程长出来
4.1 先明确"办什么事"，再谈用什么模型
数商云在项目里的第一个动作，不是选模型，而是做场景盘点。团队和业务部门一起，把日常工作中反复出现、耗时明显、结果可验证的环节列出来，再按痛感深浅排序，挑出少数几个作为切入点。判断标准很朴素：这件事员工是不是经常要干？干完之后有没有明确的"做好了"的标准？如果两个答案都是肯定的，它就是一个好场景。
4.2 AI 智能体开发的能力分层
场景定好之后，才进入能力搭建。数商云的 AI 智能体开发通常分几层推进，每一层解决一个明确的问题。
（1）知识层：让回答有据可依
把散落的技术手册、工艺文件、质量标准、历史工单归拢起来，做结构化整理，再配上检索能力。智能体回答问题时，先在企业自己的资料里找到依据，再组织语言，而不是凭模型的通用记忆去猜。对制造业来说，这一点尤其重要——结论必须能追溯到来源，员工才敢照着做。
（2）工具层：让智能体真的能动手
光会答还不够。数商云把企业的业务系统接口封装成智能体可以调用的工具，让它能查设备状态、查库存、查订单进度、提交工单草稿。员工说一句话，智能体把后续几步一起做完，人只需要确认。这个变化带来的体验差异非常大，用过的人基本不愿意退回去。
（3）编排层：把复杂任务拆成可执行的步骤
真实业务里的问题，往往不是一问一答能解决的。比如处理一起质量异常，需要先定位批次、再比对工艺参数、再查历史相似案例、再生成处置建议。数商云用任务编排的方式把这类流程拆解开，让智能体一步步走，中途还可以向人确认。这样既保证了可控，也避免了一次性生成大段内容带来的偏差。
（4）治理层：让企业敢用、可追溯
越接近业务核心，权限和边界的问题就越绕不开。谁能用、能查哪些数据、哪些动作必须人工确认、对话记录保留多久，这些规则在方案设计阶段就要定清楚。数商云在这家集团的做法，是把权限体系和原有组织架构对齐，员工看到的范围和他本来的职责一致，接受度自然就高。
五、落地过程：企业 AI 智能体落地是怎么一步步推进的
方案讲起来是分层的，落到现场却是一堆琐碎的事。这一节把推进过程里的几个关键环节摊开说，可能比架构图更有参考价值。
5.1 场景筛选：从最"烦人"的环节切入
候选场景列出来的时候并不少，数商云和业务部门一起做了筛选，最终挑的是几个大家一提就皱眉的环节：设备故障处置时的资料查找、质量异常的分类判定、售后常见问题的答复。选它们的理由很实在——高频、耗时、有明确的对错标准，而且不涉及敏感决策，试错成本可控。
5.2 知识准备：把老师傅的经验变成可调用的资产
这是整个项目里最花功夫的部分。技术手册好整理，麻烦的是那些"写在人脑子里"的经验：某种异响代表什么、什么情况下必须停机、哪类客户对交期特别敏感。数商云的做法是拉着资深员工做场景化的问答梳理，把隐含判断显性化，再让业务专家交叉校验。过程不算轻松，但这份资产一旦沉淀下来，价值是长久的。
5.3 先做能用的版本，而不是先做完美的版本
很多企业卡在"要一次性把知识库做全"这个念头上。数商云倾向于反着来：先在选定的场景里做出一个能用的版本，覆盖面不求全，但要求回答准确、动作闭环。用起来之后，缺什么补什么，知识库跟着使用过程一起长大。这种做法还有个好处——团队能更快看到反馈，信心也更容易建立。
5.4 让一线员工当产品经理
项目推进中有一条经验值得单独说：真正能提出好意见的，是天天干这件事的人。数商云在每个场景里都找了岗位上的骨干参与测试，他们会指出"这句话我们看不懂""这个顺序跟实际操作反了""这里应该直接给我一张填好的单子"。这些反馈看着琐碎，却直接决定了智能体好不好用。
5.5 从一个岗位，扩散到相邻岗位
一个场景跑顺之后，推广反而变得轻松。相邻岗位的人看到同事用得上手，会主动来问能不能也给自己配一个。数商云顺着业务的自然脉络做延展，而不是按部门下指标摊派，节奏更稳，落地也更扎实。
六、应用成效：变化藏在具体的日常动作里
6.1 一线岗位：查资料、填单据的负担明显减轻
设备报警的时候，现场人员直接问智能体，它能给出故障可能原因、对应的处理建议、需要准备的工具和备件，还能顺手把处置记录填好。原本要翻手册、找人问、事后补录的流程，现在通过对话和确认就能走完。省下来的时间不一定轰轰烈烈，但对天天在产线上跑的人来说，是实打实的轻松。
6.2 管理侧：信息汇总与异常响应的节奏变快
以前要看某类异常的分布情况，得等汇总、等出表。现在管理岗可以直接用自然语言提问，智能体从系统里把结果拉出来，并标明数据来源。响应速度上来了，讨论的起点也从"数据对不对"变成了"接下来怎么处理"。
6.3 组织侧：对 AI 的信任是一点点攒出来的
这一点最难量化，却在项目里体现得最明显。起初大家的期待是"别给我添乱"，后来变成"这个能不能也让它做"。信任的来源并不神秘——回答有出处、动作有确认、出错了能追溯。数商云在治理层做的那些看似不显眼的设计，最终都在这里兑现了价值。
七、可复用的几条判断
把这段合作经验收拢一下，几条判断对大多数准备做 AI 智能体的企业都成立。
7.1 场景选得对，比模型选得贵更重要
模型能力当然重要，但决定项目成败的通常是场景颗粒度。挑一个高频、明确、可验证的环节做透，比铺开一堆宏大目标更能说明问题。
7.2 数据与知识的准备，是绕不过去的功课
指望模型自动理解企业业务，大概率会失望。把知识整理成智能体可用的形态，是必要投入，也是长期资产。
7.3 智能体要能落成单据、落成动作
衡量一个企业 AI 智能体落地的价值，可以问一句：它有没有替员工完成某个具体动作？如果能，价值就是看得见的。
7.4 运营机制决定它能活多久
上线只是开始。有人看数据、有人收反馈、有人定期更新知识，智能体才会越用越顺手。
八、写在最后：数商云 AI 智能体的价值，是把 AI 变成日常
回到最初那个疑问：大模型的投入为什么看不到成效。多数时候，答案不在模型这一侧，而在场景选择、知识准备、动作闭环和运营机制这几件事上。数商云在这家制造行业头部集团做的，就是把 AI 智能体从"一个会聊天的入口"变成"嵌在流程里的一个角色"，让企业 AI 智能体落地有迹可循、有据可查。
不同行业的业务形态差别很大，但判断逻辑是相通的。如果你所在的企业也在为 AI 应用开发怎么落地发愁，不妨把最烦人的那个环节拿出来，和数商云的团队一起看看能不能交给智能体去做。定制化的方案，往往就是从这样一次具体的对话开始的。
评论