大模型进入企业采购视野后，一个反差变得越来越清楚：演示中的通用能力令人印象深刻，真正放进生产流程，却常常停在试用环节。答案看似流畅，业务人员却不敢直接采用；知识就在企业里，智能体却调用不到；系统里有流程，智能体却无法发起动作。某制造行业头部集团启动智能化升级时，也遇到过类似困惑。数商云没有把项目定义成“接一个通用大模型”，而是围绕企业级AI智能体开发路径，从业务任务、企业知识库、系统工具和治理机制逐层推进，让智能体在真实岗位中承担可验证的工作。本案例复盘这次实践，重点不在模型参数，而在大模型产业落地所需要的业务工程能力。
(1) 某制造行业头部集团的业务链条覆盖研发、生产、销售、交付和售后服务，产品配置复杂，服务政策与工艺知识分散在不同部门和系统之中。业务人员面对客户咨询时，往往需要同时查阅产品手册、历史工单、合同条款和服务规范，经验丰富的员工能快速判断，新员工却容易在信息检索和口径确认上耗费精力。集团管理层希望借助大模型能力改善知识获取效率，但更关注智能体能否真正进入岗位，而不是停留在演示环境。
(2) 过去，该集团已经建设了文档管理系统、知识库和工单系统，也尝试过关键词检索与流程自动化工具。问题在于，知识存放方式与业务提问方式之间存在距离。文档按部门归档，业务问题却跨越产品、合同、质量和售后环节；检索结果给出链接，却不一定给出可执行结论；员工即使找到答案，也需要再回到系统里完成下一步动作。知识看似已经在线，实际使用仍然依赖人工判断和反复沟通。
(3) 在智能化诉求上，客户并没有一开始就要求做一个覆盖全集团的“万能助手”。业务部门更关心几个具体问题：售后工程师能否快速确认产品配置与服务边界，客服能否准确解释政策并给出处理建议，质量人员能否从历史问题中找到相似案例。数商云在项目沟通中判断，这些诉求背后指向同一件事，即企业需要的是能够理解业务语言、调用企业知识、连接业务系统的企业级AI智能体，而不是一个只会生成通用答案的聊天工具。
(1) 项目前期，客户内部曾用通用大模型做过小范围验证。模型在开放话题上表现自然，也能总结文档，但进入制造业务后就暴露出明显不适。面对产品型号、服务政策、责任边界等问题，模型容易给出看似合理却缺乏依据的答案；当员工追问“依据在哪里”“这种情况能否受理”，回答往往无法落到企业制度与历史处理经验上。业务人员可以接受模型语言不够华丽，却无法接受答案不可追溯。
(2) 更深一层的问题出现在系统连接上。真实业务不是一次问答，而是一串连续动作：确认客户身份，查询订单与产品信息，判断服务政策，生成处理建议，再创建工单或转交责任人。通用大模型不了解企业权限，也无法直接操作系统。若智能体只能停留在对话框里，员工仍需手工复制信息、切换系统、重复录入，效率改善有限。大模型产业落地遇到的阻力，往往不是模型不会说，而是智能体不会办。
(3) 使用热度也说明问题。试点初期，员工出于好奇会尝试提问，但当答案无法嵌入工作流程，或者需要人工再次核验时，使用频率很快下降。数商云在复盘中提出，企业级AI智能体开发不能只关注模型接入，还要同步解决知识治理、工具调用、权限控制和运营反馈。否则，通用能力越强，业务人员越难判断哪些内容可以信任，最终仍然回到原有工作方式。
(1) 数商云与客户共同确定了项目目标：智能体要能够给出有依据的答案，要能够调用授权工具完成业务动作，要能够在权限边界内运行，还要能够通过运营机制持续优化。这个目标听起来朴素，却把项目从“模型演示”拉回到“业务系统建设”。企业级AI智能体不是替代某个岗位，而是把知识检索、判断辅助、流程发起和结果反馈串起来，让业务人员在一个工作入口中完成原本分散的操作。
(2) 场景边界也被重新划定。项目没有追求覆盖所有部门，而是优先选择知识密集、问题重复、结果可验证、风险可控的任务。售后技术支持、内部政策查询、质量案例辅助等场景被纳入试点范围，原因在于这些任务既有明确的知识来源，也有可观察的处理结果。智能体回答是否准确、建议是否可用、动作是否合规，都可以由业务人员直接判断，便于形成反馈闭环。
(3) 为了让智能体对结果负责，客户建立了业务负责人、知识负责人和技术团队共同参与的项目机制。业务负责人定义任务与判断标准，知识负责人确认内容口径与更新责任，技术团队负责系统集成、权限配置和运行保障。数商云则提供企业级AI智能体开发方法与智能体应用平台支持。这样的组织方式避免了项目只在技术部门内部推进，也让大模型产业落地有了明确的业务抓手。
(1) 数商云没有从“全集团知识问答”开始，而是与客户一起梳理岗位任务，将问题拆成可验证的场景。售后工程师需要确认产品配置与服务政策，客服需要解释处理口径，质量人员需要查找相似案例，这些任务都具备明确的输入、知识来源和输出形式。场景筛选时，项目组重点看业务痛点是否真实、知识是否可获取、系统是否可连接、风险是否可控制。满足条件的场景进入试点，不满足条件的场景先做知识准备，而不是急于上线。
(2) 在智能体设计上，项目组把“一个问题”拆成“任务链”。以售后咨询为例，智能体先识别产品与客户上下文，再检索企业知识库中的服务政策与历史案例，必要时调用业务系统查询订单信息，随后生成处理建议，并在需要时协助创建服务记录。这样的设计让智能体从单轮问答转向任务协同，也让AI智能体开发不再只是提示词工程，而是业务逻辑、知识结构与工具能力的组合。
(3) 试点范围保持克制。客户没有要求智能体立刻替代人工判断，而是让它先承担信息整理、依据查找、建议生成和流程发起等辅助工作。业务人员仍然是最终决策者，智能体则成为随取随用的工作助手。由于任务边界清楚，试点阶段可以快速收集问题样例，判断哪些答案不准确、哪些工具调用不顺畅、哪些知识需要补充，为后续扩展打下基础。
(1) 企业知识库建设是这次项目的重点。数商云协助客户梳理产品手册、服务政策、合同模板、历史工单、质量报告和培训材料，将原本按部门存放的内容转换为智能体可检索、可引用的知识资产。知识入库不是简单上传文档，而是补充业务标签、适用范围、生效状态和责任部门。这样，智能体在面对具体问题时，才能判断某条知识是否适用于当前产品、当前客户和当前场景。
(2) 知识治理比知识数量更重要。项目组发现，同一类问题在不同文档中可能存在口径差异，历史工单中的处理经验也未必仍然有效。为此，客户明确了知识负责人和更新流程，对冲突内容进行确认，对失效内容进行标记，对敏感信息设置访问边界。企业知识库不是文档仓库，而是智能体理解企业业务的基础设施。只有知识口径清楚，智能体的回答才具备稳定性。
(3) 在回答呈现上，数商云强调可追溯。智能体给出结论时，需要附带知识来源、适用条件和必要的操作提示；当知识不足时，应明确说明无法确认，而不是用通用语言补全。对于政策解释、服务受理等敏感问题，系统会提示业务人员复核。这样的设计减少了“看起来正确”的风险，也让企业知识库从静态资料变成可运营的上下文来源。
(1) 为了让智能体真正进入业务现场，项目组将工具调用作为关键能力建设。智能体可以在授权范围内查询订单信息、产品配置、服务记录和知识条目，也可以根据业务规则发起服务申请、补充工单信息或转交责任人。工具不是简单堆叠，而是围绕任务链组织：什么时候需要查询，查询结果如何影响判断，哪些动作需要人工确认，哪些动作可以自动完成，都在智能体流程中预先设计。
(2) 流程集成带来的变化很直接。过去，业务人员得到答案后还要切换系统、复制信息、手工录入；现在，智能体可以在对话中完成信息核对，并把关键内容带入业务系统。对于涉及客户权益、费用判断或责任认定的动作，系统要求人工确认后再提交。人机协同的边界清晰，既保留了智能体的效率优势，也避免了自动化越界。
(3) 异常处理同样被纳入设计。工具调用失败、知识检索不到、用户权限不足、业务规则冲突等情况，智能体会给出明确提示，并根据预设路径转交人工处理。项目组没有把智能体包装成“什么都能办”的助手，而是让它在可控范围内稳定工作。对于企业级AI智能体而言，能否妥善处理异常，往往比能否回答标准问题更能体现可用性。
(1) 权限设计遵循业务系统原有规则。员工在使用智能体时，只能访问其岗位授权范围内的知识和数据；智能体调用工具时，也需要继承用户身份与权限，不能因为接入了模型就绕过原有控制。项目组将权限校验放在知识检索和工具调用环节，确保回答内容、查询结果和业务动作都与用户职责匹配。这样做增加了实施复杂度，却是企业级AI智能体进入生产环境的必要条件。
(2) 安全边界覆盖数据、内容和操作层面。敏感字段按规则展示，关键操作保留确认步骤，运行过程形成可追踪记录，便于后续审计与问题定位。对于模型生成内容，系统结合企业知识库和业务规则进行约束，减少无依据扩写。数商云在项目中反复强调，智能体不是越开放越好，而是要在明确边界内提供稳定帮助。大模型产业落地需要工程约束，而不是只依赖模型自觉。
(3) 运营边界也需要提前说明。智能体承担信息整理、建议生成和流程辅助，不替代业务责任人对复杂问题的最终判断。客户在内部沟通中明确了使用规范：哪些结果可以直接采用，哪些需要复核，哪些问题必须转人工。这样的机制让员工敢于使用，也让管理者能够评估智能体的实际表现。企业级AI智能体开发不是把责任交给模型，而是把模型放入可管理的业务流程。
(1) 数商云在交付方式上采用联合共创。业务专家参与场景梳理和问题样例整理，知识负责人确认内容口径，技术团队配合系统接口与权限配置，数商云负责智能体流程设计、平台配置、评测优化和上线支持。项目推进过程中，讨论重点经常回到业务现场：这个答案业务人员敢不敢用，这个动作是否符合制度，这个提示是否能减少沟通。这样的交付方式比单纯交付一套工具更重，但更容易形成真实使用。
(2) 迭代节奏围绕问题样例展开。项目组将业务人员反馈的典型问题整理成评测材料，持续观察智能体在知识检索、答案组织、工具调用和异常处理上的表现。发现答案不准确时，先判断是知识缺失、检索偏差还是流程设计问题，再决定补充知识、调整规则还是优化交互。通过持续评测，智能体应用平台上的配置不是一次完成，而是随着业务理解加深不断校准。
(3) 上线之后，运营机制开始发挥作用。知识负责人定期检查内容有效性，业务团队反馈使用中的问题，技术团队关注系统稳定与权限配置，数商云提供运营建议和优化支持。智能体不再是一个项目交付物，而是需要持续维护的业务能力。正是在这个过程中，客户逐渐形成了自己的智能体运营方法，也更能判断哪些场景适合扩展，哪些场景还需要补知识、补流程。
(1) 售后工程师的使用方式发生了变化。过去遇到复杂咨询，需要先在文档中搜索，再向经验丰富的同事确认，最后回到系统处理；现在可以在工作入口中描述问题，智能体结合产品信息与企业知识给出处理建议，并附上依据来源。需要发起服务时，智能体还能协助带入关键信息。工程师仍然负责判断，但重复查找和跨系统操作的负担明显减轻。
(2) 知识复用开始形成正循环。历史工单中的处理经验经过整理后进入企业知识库，智能体在相似问题中调用这些内容，业务人员在使用中继续补充反馈。过去藏在个人经验里的判断依据，逐步变成团队可检索、可复核的知识资产。新员工遇到问题时有了更清晰的参考路径，经验丰富的员工也能从重复答疑中抽身，把精力放在复杂问题处理上。
(3) 管理视角也获得了新的观察窗口。智能体运行过程中积累的问题类型、知识缺口和转人工原因，为知识治理和流程优化提供了线索。哪些问题经常找不到依据，哪些政策口径需要统一，哪些系统动作容易中断，都可以在运营复盘中得到反馈。智能体的价值不只在前台回答，还在于把业务现场的模糊问题转化为可改进的知识与流程清单。
(1) 客户信息化负责人在复盘时提到，真正有价值的不是智能体能否流畅聊天，而是它能否在业务任务中给出可核验的结果。答案有来源，动作有边界，异常有出口，业务人员才会愿意持续使用。数商云在项目中没有急于展示模型能力，而是把大量精力放在知识梳理、流程拆解和权限设计上，这让智能体更接近企业真正需要的工作助手。
(2) 业务部门的评价更直接：智能体没有替代谁，而是把原本分散在文档、系统和人际沟通中的信息集中起来，让处理问题的人更快进入判断环节。对于复杂问题，智能体会提示转交人工；对于标准问题，智能体可以给出清晰建议。这样的分工符合业务现实，也降低了员工对新工具的抵触。智能体不是另一个需要维护的系统，而是嵌入现有工作的辅助入口。
(3) 客户也认可联合交付的方式。项目过程中，业务专家、知识负责人和技术团队始终保持沟通，问题能够回到具体场景中讨论，而不是停留在技术指标上。数商云提供的企业级AI智能体开发方法，帮助客户把“想做一个智能体”转化为“先做哪个任务、需要哪些知识、连接哪些系统、如何评估效果”。这种从业务出发的推进方式，为后续扩展打下了基础。
(1) 先找业务问题，不要先选模型。许多企业在启动AI智能体开发时，容易把注意力放在模型能力对比上，却忽略了业务任务是否清晰、知识是否可用、流程是否可连接。数商云在案例中的做法是先梳理岗位任务，再判断智能体适合承担哪一段工作。场景越具体，价值越容易被验证；任务越清楚，知识治理和系统集成越有方向。
(2) 把企业知识库和流程集成当作基础设施。通用大模型可以提供语言理解与生成能力，但企业答案来自企业知识，业务动作依赖业务系统。没有知识治理，智能体会给出看似合理却不可用的回答；没有工具调用，智能体只能停留在咨询层。大模型产业落地需要把知识、工具、权限和流程放在一起设计，让智能体既能理解上下文，也能完成动作。
(3) 建立运营机制，不要期待交付即结束。智能体上线后，知识会变化，政策会调整，业务问题也会更新，运营机制决定了智能体能否持续可用。企业需要明确知识负责人、问题反馈路径和评测方式，让业务人员在使用中贡献反馈，让技术团队能够定位问题。数商云在项目中提供的智能体应用平台与运营支持，正是为了让智能体从试点走向日常使用。
(4) 选择懂业务、能共创的合作伙伴。企业级AI智能体开发涉及业务、知识、系统、安全和运营，不是单一技术团队能够独立完成的工作。数商云在这次实践中承担的也不只是平台配置，而是与客户一起梳理场景、设计流程、建立评测和推动运营。对于正在评估智能体建设的企业而言，案例带来的启示是：把通用大模型转化为产业能力，需要业务工程、知识工程和平台能力的共同支撑，也需要一个能够进入业务现场、持续陪跑的合作伙伴。
点赞 | 0
