企业大模型被讨论得很多，真正进入业务流程并稳定产出可核验结果的项目却不算多。不少集团型企业有过类似的经历：接入通用大模型接口，搭建内部知识库，组织几轮演示，现场效果看起来不错；可一旦放进真实业务，问题接连出现。回答流畅却经不起核对，遇到跨系统流程就中断，出错之后找不到责任归属，业务人员用上几次便不再打开。原因往往不在模型本身，而在模型能力与企业业务语境、知识资产、系统权限、运营机制之间，缺少扎实的工程连接。
数商云的客户中，就有企业在这条路上走过弯路。本文以某制造行业头部集团的AI智能体定制开发项目为线索，梳理企业大模型从“能做演示”走向“能承担业务”的过程：场景怎么筛，知识怎么治理，智能体怎么编排，系统怎么集成，上线之后又靠什么持续运转。比起模型参数与榜单排名，这些看似琐碎的环节，更接近企业大模型落地的真实答案。
在项目启动之前，客户内部已经做过一轮探索。通用大模型的对话能力给业务部门留下了印象，也正因如此，最初的预期偏向乐观。真正推进到业务环节，落差开始显现。数商云在调研阶段把这些问题逐条记录，发现它们指向同一处：模型能力与企业运行方式之间缺少适配层。这个判断，后来成为整个项目设计的出发点。
(1) 通用大模型擅长组织语言，却不了解企业的产品型号、工艺路线、合同条款与审批惯例。面对客户提问，它能给出一段读起来通顺的回答，但其中的参数、责任划分、适用条件未必经得起业务人员核对。在制造行业，错误的工艺建议可能带来返工，不严谨的交期承诺可能影响客户关系。客户在试点阶段就意识到，能聊天和能办事之间隔着距离，这段距离需要靠企业自己的知识与规则来填。
(2) 集团型企业的知识分布很分散。制度文件在办公系统，产品资料在技术部门，历史问题处理记录在工单系统，更多经验留在老员工的判断里。这些内容格式不一、版本混杂，有的甚至相互矛盾。直接把它们丢给模型，得到的只会是含糊其辞的回答。想让智能体给出可用的答复，先要把散落的资料整理成结构清晰、来源可溯、版本可控的企业知识库，这项基础工作绕不过去。
(1) 演示往往由技术人员陪同，提问经过挑选，网络与数据都处在理想状态。生产环境完全不同：用户会输入错别字、方言化表达和不完整信息，业务系统可能响应缓慢，权限规则层层叠加。客户此前做过演示，效果不错，但接入真实账号体系后，智能体无法判断来访者能看到哪些数据，只能给出笼统回答，业务部门很快失去兴趣。生产环境考验的不是模型会不会说，而是系统能不能稳。
(2) 企业里真正有价值的动作，多半发生在业务系统中：查订单、提工单、走审批、调库存。如果智能体只能停留在对话框里，不能调用这些系统，价值就停留在咨询层面。客户最初的设想是让智能体直接回答问题，深入讨论后调整为：回答之外还要能发起动作，把结果回写到系统，并留下操作记录。这一转变对接口设计、权限控制、异常处理都提出了更高要求，也让项目从“接个模型”变成了系统工程。
(1) 客户评估过直接采购通用模型服务的方式，也考虑过在内部搭建简单的问答应用。前者上手快，但难以贴合工艺、合同、售后等专业语境；后者可控，却缺少工具调用与多轮任务编排能力。客户的业务链条长，一个问题往往牵涉多个系统与多个角色，需要智能体在限定范围内自主规划步骤、调用工具、汇总结果。正是这种复杂度，让定制开发成为更现实的选择。
(2) 作为集团型企业，客户对数据边界有明确要求：哪些数据可以进入模型上下文，哪些只能留在内网，哪些需要对访问者做权限过滤，都要提前界定。同时，客户不希望做成交付即结束的项目，而是希望内部团队逐步具备运营能力，能自己调整知识、优化提示、评估效果。数商云在方案中把知识管理后台、评测工具与运营流程一并纳入，正是回应这一诉求。
项目没有从模型选型开始，而是从业务盘点开始。数商云团队与客户业务部门一起，把高频问题、重复劳动与跨系统流程摊开来看，再判断哪些适合交给智能体，哪些仍需人来把关。整个实施过程可以概括为几条并行的主线：场景收敛、知识治理、智能体编排、系统集成与上线运营。它们相互牵制，任何一条走偏，最终效果都会打折。
(1) 客户最初列出的需求很多，从客服问答到生产排程都有涉及。数商云建议先做收敛，用业务价值与实施可行性做交叉评估：价值高、数据基础好、容错空间相对宽裕的场景优先；涉及安全红线或责任重大的环节暂缓。经过几轮讨论，智能体应用场景集中到客户咨询响应、技术资料检索、售后问题辅助处理等方向。范围收窄之后，团队能把精力放在打磨细节上，而不是铺开摊子。
(2) 哪些结论可以直接给用户，哪些必须由人确认后发出，这个边界要在设计阶段就定清楚。客户的做法是按风险分级：一般性资料查询由智能体直接回复并标注来源；涉及方案变更、价格承诺、责任认定的内容，智能体只提供参考意见与依据，由业务人员确认。这样的分工既发挥了智能体的效率，也保留了必要的审核环节，业务部门在接受度上明显提高。
(1) 客户提供的资料体量大、格式杂。数商云团队先做分类，把制度、产品手册、技术规范、历史问答记录分开处理；再做清洗，剔除过期版本、合并重复内容、补齐缺失的上下文；最后做结构化，按业务对象和问题类型建立层次，给每一条知识标注来源与适用范围。这项工作耗时但无法跳过，因为智能体回答的可信度，最终取决于知识库的干净程度。
(2) 知识会过期，制度会修订，产品会迭代。如果每次更新都要找开发团队，运营很难持续。数商云在系统中设置了知识管理后台，由客户各业务条线指定人员负责本领域内容的维护，更新后经过审核即可生效，并保留版本记录。责任落到人，更新才有动力；有版本可查，出问题才能追溯。这套机制看起来不复杂，却是企业知识库建设能否长期运转的关键。
(1) 项目初期尝试用单个智能体覆盖全部任务，很快遇到瓶颈：既要懂产品，又要懂售后，还要会查系统，提示词越写越长，效果反而下降。后来调整为按职责拆分，由不同的智能体分别承担资料检索、问题归类、工单草拟等任务，再由调度层决定调用顺序。拆分之后，每个智能体的知识范围和工具集合都更清晰，调试与迭代也更容易定位问题。
(2) 智能体要办事，就得调用工具。数商云为客户封装了查询类与办理类接口，智能体根据任务需要选择调用，调用前校验用户权限，调用后核对返回结果。为避免模型自作主张，流程中设置了约束条件：超出授权范围的操作直接拒绝，关键步骤要求二次确认，结果与知识库内容不一致时给出提示而非强行作答。这些约束牺牲了部分灵活性，换来的是业务部门敢于把真实任务交出去。
(1) 客户的系统环境复杂，既有自建平台，也有外部采购的应用。数商云采用统一接入层的方式，把需要的能力封装成标准接口，智能体不直接接触底层数据，而是通过接入层获取经过权限过滤的结果。用户身份从原有账号体系透传，确保不同岗位看到的数据范围与过去一致。数据边界清晰之后，安全与合规部门的顾虑明显减少，项目推进也顺畅许多。
(2) 只读查询能解决部分问题，真正节省时间的环节在于办理。以售后场景为例，智能体在了解问题之后可以草拟工单、填充必要字段、推荐处理方案，经人工确认后提交到工单系统，后续进度再回流到对话中展示。链路打通之后，业务人员不必在多个系统之间来回切换，智能体的使用频率也随之上升。集成做得越深，智能体越像业务流程的一部分，而不是额外的工具。
(1) 评测阶段，数商云与客户共同设计了一套评估维度：回答是否有依据、来源是否可追溯、遇到不确定问题时是否如实说明、任务完成情况如何、业务人员的采纳意愿如何。单纯看答案对错容易失真，因为很多业务问题没有唯一答案，重要的是给出可核验的依据和合理的处理建议。客户业务骨干参与了评测集的构建，用真实问题检验效果，比实验室里的测试更接近实际。
(2) 上线不是终点。项目组建立了定期复盘机制，收集使用记录与反馈，把高频未解决的问题整理成优化清单，分别归入知识补充、提示调整、工具扩展等方向。数商云同时向客户团队移交了运营方法，包括如何看数据、如何定位问题、如何做小步验证。随着使用深入，客户内部已经能够独立完成常规优化，外部支持逐渐转向复杂场景与新增需求。
项目运行一段时间后，客户内部的评价逐渐从“试试看”转向“离不开”。这种变化不是某个功能带来的惊喜，而是许多细节叠加后的结果。回看整个过程，有几个方面的变化比较有代表性，也有一些经验值得同类企业参考。
(1) 过去，业务人员遇到客户咨询，要先判断问题归属，再去不同系统或找不同同事求证，耗时且容易遗漏。接入智能体之后，常见问题可以在对话中得到带来源的答复，复杂问题也能拿到初步判断与处理建议。更明显的变化是口径一致性：不同区域、不同岗位的人员得到的答案基于统一知识，减少了因理解差异造成的沟通成本与客户体验波动。
(2) 老员工的经验过去主要靠带教传递，覆盖范围有限。知识治理过程中，大量隐性经验被整理成可检索的内容，新员工遇到问题时可以先与智能体交互，再向同事请教，成长路径缩短。对客户而言，这是一笔长期资产：人员会流动，整理过的知识与经过验证的处理逻辑留在系统里，持续为后续业务提供支撑。
(1) 项目初期，业务部门把需求交给技术团队就撒手不管，结果做出来的功能与实际场景有偏差，返工不少。后来客户调整了协作方式，由业务骨干参与场景定义、知识审核与效果评测，技术团队负责接口、编排与稳定性保障，双方按固定节奏对齐。这种配合方式增加了业务部门的时间投入，但减少了方向性错误，整体效率反而更高。
(2) 客户没有把项目做成完全依赖外部团队的样子。数商云在实施过程中安排了多轮培训与共同操作，把知识维护、提示调整、效果分析等方法逐步移交。项目后期，客户内部已能承担日常运营，并能识别哪些新需求适合用智能体解决、哪些不适合。这种能力沉淀，比交付系统更有价值，也决定了后续扩展的上限。
(1) 项目起步时，客户内部对智能体的期待偏高，有人把它理解成可以替代业务人员。数商云在多次沟通中把预期拉回到“辅助人”上：智能体承担资料检索、初步判断、重复录入等环节，复杂判断与责任认定仍由人完成。预期调整之后，业务部门的评价标准更务实，看到进步时也更有耐心，项目推进反而更顺。
(2) 项目推进到中途，陆续有部门提出新的需求，希望把更多场景塞进来。客户与数商云共同做了范围控制，把与当前目标关联不强的需求放入后续清单，避免主链路被反复牵动。这个决定在当时引起过讨论，但事后看，保住核心场景的完成度，为后续扩展积累了信任与经验。
(1) 不少企业在规划阶段追求大而全，试图一次覆盖所有场景，结果周期拉长、信心消耗。从这次实践看，先选几个痛点明确、数据基础较好的场景做深，让业务人员真正用起来并形成习惯，比铺开多个半成品更有效。有人用，才有真实反馈；有反馈，优化才有方向。
(2) 智能体不是装好就完事的软件。知识会过期，业务会变化，用户预期也会提高，需要持续投入运营。客户在项目立项时就明确了运营角色与预算安排，这一点在后来的推进中起到了作用。对准备启动同类项目的企业而言，与其问“模型能力够不够”，不如先想清楚“谁来运营、怎么评估、如何迭代”，这些问题的答案，往往决定了企业大模型落地能走多远。
企业大模型落地难，难的不是把模型接进来，而是让它在一个讲究责任、权限与准确性的组织里稳定工作。数商云在这个项目中做的事情，说到底是把模型能力翻译成业务语言：用场景收敛控制范围，用知识治理保证依据，用智能体编排承接任务，用系统集成打通链路，用运营机制延续效果。这些工作不炫目，却决定了智能体能不能被真正用起来。
对仍在观望的企业来说，这个案例提供的不是可以照搬的方案，而是一种判断方式：先看业务问题是否清晰，再看数据与知识是否可用，最后看组织是否准备好长期投入。想清楚这些，AI智能体定制开发才有意义；否则，再强的模型也只是一次演示。
点赞 | 0
