企业官网建设流程全解析

在制造业数字化圈子里泡了十几年，我明显感觉到一个分水岭：2024年之前大家聊AI，聊的是大模型能写报告、能做知识问答，本质上还是"更聪明的搜索引擎"；2025年前后风向彻底变了——甲方开口就问"能不能让AI自己去盯产线、调排程、对工单"，也就是让AI Agent真正下到车间里干活。这个变化背后，是企业级应用对AI的诉求从"问一答一"升级成了"拆解任务、协调资源、闭环执行"。

这篇文章不是厂商白皮书的复述，也不是学术综述的搬运，而是一个长期做制造业数字化交付的人，对AI Agent在企业级应用里落地现状、技术选型、真实的坑和未来走向的完整梳理。内容围绕三个问题展开：制造企业为什么需要Agent而不是普通聊天机器人？企业级Agent应用在技术架构上到底卡在哪？以及接下来两年Agent会在哪些环节先跑出规模？我会尽量把概念讲成人话，把架构决策讲出取舍逻辑，顺带把交付现场踩过的雷也一并说清楚，希望能给正在评估或正在搭Agent的团队一些参考。

1. 拆开"AI Agent 在制造企业级应用"这个概念

这个概念现在被用得太泛了，反而容易失真。先明确一个最基础的问题：制造业语境下，AI Agent 和传统的智能客服、知识库问答有什么本质区别？以及什么才算"企业级"，而不是"玩具级"。

1.1 从"被动应答"到"目标驱动"的能力跃迁

制造业里早就有人脸识别考勤、语音质检、设备振动分析这些传统AI应用，它们的特点是单点识别、被动响应：你给它一张图，它告诉你缺陷类型；你给它一段语音，它转成文字。这类AI的能力边界是"感知"，它不负责判断下一步该干什么。

AI Agent完全不同，它的核心是"目标驱动"。你给它一个目标——比如"把本周A线的排产计划优化一遍，在满足交期的前提下尽量降低换型次数"——它需要自己去拆解：先到MES拉当前订单池，再查设备日历确认可用机时，然后调用优化算法生成候选方案，最后把方案推送给人审核。中间任何一步缺数据，它会自己判断是去ERP补、去问人、还是换一个可行路径。这个过程里Agent不再是一个被调用的接口，而是一个有"主动性"的协作主体。

这个跃迁对制造业特别重要，因为车间现场的系统烟囱太多了：ERP管订单和物料，MES管工单执行，SCADA管设备实时状态，WMS管库存。过去的集成方式是写死接口、画流程图，业务一变就改代码；Agent的方式是给模型一个目标，让模型自己编排该调哪些系统、按什么顺序调、数据对不上怎么处理。这就是为什么大家都在喊AI Agent是打破系统孤岛的新手段。

1.2 "企业级"三个字到底卡住了什么

凡是做过企业交付的人都知道，概念在PPT上跑得很欢，一进企业就现原形。"企业级Agent应用"和"个人玩具Agent"之间隔着几堵墙，这些墙才是真正决定项目生死的东西：

• 身份与权限：车间里的Agent必须知道操作者是工艺员还是班组长，不同角色能看到什么、能触发什么动作，得跟现有AD域控和角色体系打通，不能在Agent里另搞一套账号体系。
• 可靠性与可追溯：产线动作一发出就是真金白银，Agent的每次决策、每个工具调用、每次参数修改都必须有完整留痕，出了问题要能回溯到具体某一次推理和调用链。
• 高并发与性能隔离：企业里有几百上千个用户，不可能让每个人在一个共享的Agent实例上排队；Agent服务要能水平扩展、要能做租户隔离。
• 安全边界与数据合规：工艺参数、订单价格、客户信息全是核心资产，Agent的模型推理如果在云端，数据出域这一关就过不去，私有化部署几乎是制造业的默认前提。
• 与现有系统的集成深度：Agent能不能对接老旧的产线数据库？能不能通过现有的ESB或消息中间件收发指令？这决定了Agent是锦上添花还是真正进入业务流程。

这五个方面，每一个都能让一个技术看起来很美的Agent项目死在POC阶段。所以后面谈技术选型和架构时，本质上都是在回答"怎么把这五堵墙拆掉"。

2. 制造业场景对Agent的核心能力需求拆解

制造业的Agent需求，跟互联网行业有很大差异。互联网Agent追求的是对话体验和C端交互，制造Agent追求的是对物理世界的准确理解和可靠操作。我梳理了目前工业界需求最迫切、也是落地案例最多的四类场景。

2.1 生产排产与调度：决策型Agent的主战场

排产这个业务痛点极其清晰，但过去很难用传统IT系统真正解决。排产要考虑订单交期、设备产能、物料齐套、换型时间、人员班次，变量多且互相牵制。以前的APS系统靠运筹优化算法，能做，但模型参数调整复杂，业务一变化，模型就要重建。

Agent做排产的优势在于"自然语言交互+算法内核"。排产工程师可以直接说"明天A线优先做C客户订单，但不要超过两次换型"，Agent会把这条模糊指令翻译成优化模型的约束条件，调用求解器出方案，再基于结果反问人："如果C客户订单插入，B订单将延迟6小时，是否接受？"这个边对话边建模边求解的过程，传统系统做不到。

实际项目里，这种Agent通常走的是"大模型做意图理解和结果解释，成熟求解器做数学优化"的混合架构，而不是让大模型自己脑补排产方案。这个思路是制造场景里Agent落地的关键心法：大模型负责连接和表达，确定性算法负责计算。

2.2 设备运维与预测性维护：感知型Agent的延伸

设备维护领域过去做了很多预测性维护模型，但问题在于：模型报警了，然后呢？报警信息躺在系统里，等工程师有空了才看——这个"最后一公里"恰恰是Agent最能补位的环节。

设备Agent的典型工作方式是：SCADA系统发现某个电机温度异常，触发事件；Agent自动拉取该设备历史维修记录、同类设备的故障模式库、当前工况参数，做初步诊断归因；如果判断是早期故障征兆，Agent会自动生成一条工单并指派给对应区域的维修工程师；同时在工程师到达现场后，Agent把相关手册、备件清单、历史维修案例推送到他手机上——整个过程人没有被淹没在报告里，而是直接拿到可行动的建议。

这类Agent的核心难点不在大模型推理，而在于时序数据的特征提取和故障知识库的质量。大模型在设备诊断里更像"经验丰富的老师傅"，它不能替代传感器和信号处理算法，但能把多源信息整合起来。

2.3 供应链协同与订单交付：跨系统编排型Agent

制造业的供应链协同是系统最多、流程最长、角色最杂的环节。一个订单交付涉及销售、计划、采购、仓储、物流多个部门，横跨CRM、ERP、SRM、WMS多个系统。过去靠人工跟单，靠微信群催料，信息不同步是常态。

供应链Agent的架构通常是一个"主Agent"加多个"子Agent"的团队形态。主Agent负责理解订单变更意图，然后分派任务：采购Agent去查ERP的采购在途和供应商交期、仓储Agent去查库存批次和库位、物流Agent去查承运商的运力计划，各子Agent把结果汇总回来，由主Agent整合成一份完整的交付风险评估报告。整个过程可以在半小时内完成，人工跨系统拉数可能要半天甚至一天。

这里要特别提醒的是，供应链Agent最容易栽跟头的环节是数据质量问题：ERP里的交期可能三个月没更新、库存账和实物有差异。Agent再聪明，喂进去是脏数据，出来的结论就是一本正经地胡说八道。所以做供应链Agent的前提是先做数据治理，且Agent的回复必须带上数据时间戳。

2.4 质量分析与异常追溯：知识密集型Agent的标杆场景

质量部门是制造业里知识密度最高的地方之一：8D报告、FMEA、检验规程、历史不良记录散落在各种系统和个人电脑里，新工程师上手慢，老工程师的经验又带不走。

质量分析Agent把散落的知识组织起来：当你输入一个客诉现象，Agent会先检索相似历史案例，按FMEA框架帮你梳理可能的失效模式，再调出该产品的检验记录和工艺参数做关联分析，最后给你生成一个8D报告的初稿框架，包含问题描述、临时措施建议、根本原因分析需要补充的数据项。它不是一个报告生成器，而是一个"质量知识引擎的交互前端"。

质量Agent落地的一个关键挑战是知识库构建。很多企业以为把文档扔给向量数据库就行，实际做下来，生产过程中的经验往往没被文档化。我见过比较成熟的做法是：先让Agent和老师傅做一轮访谈式采集，把他们的口头经验结构化沉淀，再进入日常使用。这个前置投入如果不做，Agent的知识底座就是空壳。

3. 企业级Agent应用的技术架构与选型要点

聊完场景，进入硬核的部分——企业级Agent到底用什么技术架构来搭。这一节我会尽量把主流方案拆开，讲清每种选择背后的原因，并加进一些选型时的对比视角。

3.1 编排框架选型：LangChain、LangGraph 与 Spring AI

目前企业级Agent开发最主流的方式是基于编排框架。LangChain是生态最全的入门选择，组件化程度高，文档多，社区案例丰富，适合快速出原型。但它的问题在于用久了你会发现它的抽象层级偏"重"，很多组件的默认行为在复杂工业场景下不够可控，经常要绕过框架写原生代码。

LangGraph是LangChain生态里更适合复杂业务编排的选择，核心价值在于把Agent的工作流做成显式的图结构：节点代表工具调用或模型推理，边代表状态流转条件。这对制造业场景特别重要——你在产线场景里本身就要求流程可预期、分支可控，LangGraph让Agent的每一步路径都可视、可断点调试、可恢复。我们在做多Agent协同系统时就是用LangGraph做的底座，调试体验比纯LangChain好很多。

Spring AI 是Java生态团队的选择。很多制造企业的IT部门是Java技术栈，集团层面还有很多存量Java EE系统。Spring AI的价值在于让Agent技术能平滑融入现有的Java微服务体系，复用已有的Spring Cloud基础设施、配置中心和链路追踪。如果你的企业Java技术栈非常统一，且集成目标是Spring Boot体系内的系统，那Spring AI的吸引力确实很大；但坦白说，它现在的生态丰富度和社区活跃度相比LangChain还有差距，适合Agent业务不复杂但对系统整合要求极高的团队。

这里还有一个容易被忽略的选项——Django。如果企业有Python技术栈底子，很多算法和数据处理服务本来就是Python写的，用Django做Agent的对外API服务和调度管理后台，再配合Celery做异步任务，整个技术栈非常顺。前面提到的那套FastAPI+LangChain+LangGraph组合也类似，FastAPI做服务层、LangGraph做编排层，在性能和开发效率上很均衡，是目前我个人最推荐的轻量级企业Agent骨架。

3.2 单Agent与多Agent协同：怎么选

架构决策里第二个重要问题是：用一个Agent包打天下，还是多个专职Agent协作？

逻辑上，多Agent更贴近组织运作方式（计划员、采购员、设备员各司其职），但在工程上，多Agent的复杂度指数级上升——Agent之间通信协议、任务结果冲突消解、全局状态一致性、故障扩散的管控，都是实实在在的成本。

我建议一个务实的判断标准：以"工具集的边界"来划分Agent数量。如果某一类任务涉及的工具有强内聚性（比如排产Agent需要调MES、APS、日历系统，它们天然在一个业务域），就适合做成一个专职Agent；如果任务需要跨完全不同业务域的工具链（比如订单变更既要查采购交期又要查设备产能），就应该拆成多个Agent再配一个协调者。千万别为了架构好看而拆Agent，多Agent的通信开销会在你排查问题时变成噩梦。

主流实现方式上，多Agent编排目前有"计划者-执行者"模式和"层级委派"模式。前者由一个主Agent负责任务分解，把子任务下发给执行Agent；后者允许某Agent在执行中发现自己能力不足时向上一层申请协助。工业场景我偏好"计划者-执行者"：流程更可控，每个Agent的动作边界清晰，权限管控也容易落实。

3.3 高并发与性能：从API网关到推理优化

"AI Agent怎么扛并发"是这个领域最常见的技术问题。企业级环境下，几百个用户同时跟Agent交互，每个Agent任务还有多轮工具调用和模型推理，性能瓶颈跟传统API服务完全不同。

首先要明确：Agent服务天然包含两部分负载——编排调度负载（CPU密集+IO密集）和模型推理负载（GPU密集）。架构上必须把这两层分开。编排层可以套用常规的微服务做法：水平扩展无状态Agent实例，通过Redis存会话状态，通过消息队列解耦异步任务。真正的瓶颈在推理层：一个复杂Agent任务可能涉及十几轮大模型调用，单用户单任务都要几十秒量级，直接同步接口肯定炸。

企业里一般三种解法：

• 异步任务化：把Agent执行转成长任务，客户端轮询或通过WebSocket推送执行进度，用户侧体验是"提交目标-看进度-拿结果"，而不是"等同步返回"。
• 推理batch并发：对同一批次进入的短任务做动态batching，提升GPU利用率，降低单次推理成本。
• 模型分级：简单意图用中小模型（比如7B-14B的本地模型），复杂推理才调用更大参数模型。成本能降一个量级，响应速度也快很多。

还有一点容易被忽略：Token消耗是企业级Agent成本的大头。Agent的多轮推理和工具调用非常烧Token，一个复杂任务可能消耗几万甚至十几万Token。上线前一定要把Token成本纳入评估，按任务类型测算单次成本，并对上下文长度做裁剪策略（比如历史对话摘要、工具结果截断）。不然Agent项目即使业务效果再好，也可能因为推理成本过高而算不过来账。

3.4 部署形态：私有化依然是制造业的主流答案

数据敏感+生产系统连续性，决定了制造企业几乎不会把核心Agent应用跑在公有云大模型API上。私有化部署是目前制造业Agent落地最典型的方式。

私有化带来的问题很实际：GPU资源有限。多数制造企业的IT机房里，能分给AI应用的GPU资源通常不会很宽裕，一两张A100或4090都算好的。所以你的模型选型必须跟算力现实对齐。我们现在的常用组合是：7B-14B级别的通用对话模型处理日常任务，专精领域用更小的微调模型，必要时才把少数高难度任务转发到云端大模型API（这需要数据脱敏审批流程）。

部署架构上，Agent服务本身通常用容器化，放进Kubernetes集群统一调度。还需要额外考虑的是模型服务的GPU调度机制（业界通用的模型服务框架是主流选择），以及Agent与现有系统的连接通道——制造业环境里很多老系统只支持内网特定协议，Agent所在的容器网络要能跟这些系统安全互通，网络策略要提前规划。

4. 从POC到量产：企业级Agent落地的完整路径

技术选型讲完，更关键的是落地路径。制造企业的Agent项目最容易死在"demo很惊艳，上线没人用"。结合我的交付经验，一条靠谱的落地路径大概是四个阶段。

4.1 第一阶段：选准一个高价值窄场景做POC

选场景是决定项目生死的第一件事，也是最考验经验的地方。我见过太多企业一上来就想做"全厂智能调度大脑"，这种项目注定烂尾。靠谱的做法是：选一个业务痛感强、边界清晰、数据条件相对好、失败影响可控的场景。

比如"订单交付风险评估"就比"车间排产优化"更适合第一步——前者主要读数据做判断和汇总，不直接操作产线，即使Agent判断错了也不会造成物理损失；后者动辄涉及生产计划调整，风险高得多。检验Agent能力从"只读分析型"场景开始，让业务部门先建立信任，再做"写操作型"场景。

POC阶段一定要定可量化的评估指标。比如"人工跟单核对时间从1天缩短到2小时""质量报告初稿起草时间从3小时缩短到20分钟"。没有量化指标的POC，汇报时只能靠感觉说话，决策层很难拍板投入。

4.2 第二阶段：构建企业级Agent基础设施

POC跑通后，从"能跑"到"能生产用"之间，通常要补一大块基础设施工作，这也是最容易被低估的工作量。

首先是非结构化数据治理：把业务文档、设备手册、历史报告做清洗、分块、建立知识库。这部分工作枯燥但至关重要，Agent回答质量的上限其实由知识库质量决定。其次是结构化系统接入：打通ERP、MES、WMS等系统的API，这个过程中要跟各个系统的厂商或IT团队反复协调，耗时很长。

然后是Agent可观测性体系。企业里用Agent，不能当黑盒用。我们需要为每个Agent任务记录完整的调用链：模型输入输出、工具调用参数、中间决策、耗时和成本。这块可以用OpenTelemetry那一套做链路追踪，把Agent执行轨迹可视化出来。没有可观测性，Agent一出问题就是灾难，你根本不知道是哪一环导致结论错误。

安全和权限也是这个阶段要完成的硬指标：Agent服务要接入企业的统一身份认证、工具执行要做好基于角色的权限控制，敏感操作要加入双人审批流程。比如Agent要修改一个生产工单，不能直接改，应该生成"待审批修改建议"，人工确认后才真正写入系统。

4.3 第三阶段：人机协同运营模式的建立

Agent上线后最大的挑战不是技术问题，而是"人怎么跟它配合"。这里有一个关键心法：Agent初期定位不是替代人，而是给人赋能，把人的精力从重复信息检索中释放出来，让人做更有价值的决策和沟通。

这个阶段要重点设计人机交互边界。哪些事Agent可以自主完成？哪些事Agent只能给建议？哪些事Agent完全不能碰？必须在运营规则里定义清楚。我们的经验做法是"三级控制"：一级为纯信息查询（Agent自主，无需审批）；二级为跨系统操作（Agent生成建议工单，人确认后执行）；三级为涉及成本或工艺变更的操作（Agent只提供分析报告，由人造作执行）。

同时还要建一个Agent运营反馈闭环。产线上的真实情况永远比测试丰富，要有一线用户提交反馈、标注错误案例的机制，定期用这些反馈去校准Prompt、补充知识库、调整工具调用逻辑。Agent不是部署完就不管的静态系统，它会随着使用越用越准。

4.4 第四阶段：从单场景扩展到平台化

当一个Agent场景稳定运行后，自然想扩大到更多场景。这时最忌讳的是每个场景一个独立Agent系统，重复造轮子。正确方向是把POC阶段沉淀的东西平台化。

平台化至少包含三层：底层的模型服务层（统一管理模型路由、微调、Token计算、成本监控）；中间的能力服务层（统一封装企业系统API、知识库模块、权限中心、审批中心）；上层的Agent编排层（支持用LangGraph或类似框架配置各种业务Agent）。有了这个平台底座，新场景的开发周期可以从一两个月压缩到一到两周，因为工具连接、知识管理、权限控制都是现成的。

制造业企业如果能走到这一步，就已经不是"上一个AI项目"了，而是具备了可持续进化的AI能力平台——这也就是很多企业提出"AI中台"的真正内涵。

5. 这个领域的现实问题与避坑指南

AI Agent不是技术方案到位就能顺跑的，这一节专门讲一讲制造业Agent项目里最容易踩的坑，全是真金白银换来的教训。

5.1 大模型幻觉：如何让Agent不"一本正经胡说八道"

工业场景最让人不敢放手的一点，就是大模型的幻觉问题。Agent一本正经编造一个不存在的数据，可比人算错数字严重得多——机器给出来的感觉，比人更权威。

应对幻觉有几种组合拳，按优先级排列：

• 强约束回答边界：把Agent能回答的范围严格限定在已接入的工具和知识库内，对于没有数据支撑的问题，Agent必须明说"我不掌握相关信息"，而不是编造。这需要在Prompt层做强约束，并在框架层做输出校验。
• 关键数据引用溯源：要求Agent在输出任何具体指标时，必须附带数据来源（来自哪个系统的哪个接口、哪个文档的哪个段落）。一旦发现无法溯源，默认判定为不可信输出。
• 工具结果优先于模型记忆：Agent涉及具体数值查询时，强制走API拉取，而不是让模型"回忆"。模型只能做推理和表达，不能做数据记忆。

落地时的细节是：在LangGraph里，我们给每个工具调用节点之后加了"数值格式校验"逻辑——如果模型输出的关键字段和工具返回不一致，直接截断并要求重新生成。这个防御性环节极其有效。

5.2 数据孤岛与连接成本：Agent好不好用，取决于系统开放度

制造业的老系统有多难搞，做过集成的人都懂：有的是厂商私有协议，有的连API都没有，只能通过数据库只读账号访问，还有的是换了供应商之后历史数据格式完全对不上。Agent再好，系统连不通就是废的。

这里提供几条实用经验：先做一份"系统连接难度评估清单"，把Agent涉及的每个系统按三大维度打分——接口完整性、数据质量、数据实时性。综合分数低于某个阈值的系统，先做数据同步或中间层改造，再接入Agent。

另一个经验是：优先通过企业已有的集成平台（ESB、消息中间件）接入，而不是每个Agent直连各系统。虽然前者多了一道转发，但便于统一监控、权限管控和格式转换，长期维护成本更低。

还有一个经常被忽视的问题是"连接通道的两端都有变化"。企业系统经常升级、接口字段有时会变，Agent如果依赖的接口变了，可能整个链路就挂了。所以Agent平台要建接口健康检查机制，定期验证所有工具链路的连通性，指标下降能提前预警。

5.3 指标评估与ROI：别拿"演示效果"当"经营效益"

AI Agent项目在制造业里推动慢，很大一个原因是ROI算不清。销售给老板演示的时候，Agent像个超级员工什么都会；真到了财务那里，问投入产出比，就含糊了。

我建议在项目章程期就要定义清楚的ROI口径，分类测算：

• 显性人力节省：替代了多少人工数据检索和报告整理时长，这个可以直接算工时。
• 效率提升收益：比如订单风险评估审核周期从2天压缩到4小时，释放出来的交期窗口对经营有什么影响。
• 质量改善收益：比如设备故障提前预警减少了非计划停机时长，按吨位产值折算。
• 知识资产沉淀：老师傅经验结构化带来的长期价值，这个没法精确算，但可以作为战略指标。

项目上线后每季度做一次复盘，对照这些指标看趋势。如果Agent项目的量化指标连续两个季度没有明显变化，就要果断查原因：是使用率不足，还是知识库没跟上，还是流程上根本没有真正嵌入。Agent项目最怕的不是技术失败，而是"上了但没人用"——这通常意味着早期场景选择和流程设计出了问题。

5.4 组织与人才：真正的瓶颈不是技术，是复合型团队

最后说一个很多人不愿意正视的问题：Agent项目的核心瓶颈往往不是技术选型，而是团队配置。一个企业级Agent项目至少要三类人：懂大模型和Agent框架的AI工程师、懂制造业务流程和系统架构的业务架构师、懂数据治理的数据工程师。这三类人如果沟通不畅，项目大概率内耗殆尽。

AI工程师最容易犯的错是过度沉迷技术细节，忽略了业务问题本身；业务架构师如果不懂Agent能力边界，会把需求提得非常抽象，导致开发反复返工；数据工程师如果对业务字段含义不熟，建出来的知识库会跟业务脱节。

我见过比较有效的团队组织方式是"业务架构师当产品经理，AI工程师当技术负责人，数据工程师当底座支撑"，三个人从一开始就泡在同一个业务场景里，而不是各写各的文档做交接。制造业的Agent需求，往往是三类人坐在一起面向用户现场聊出来的，而不是靠需求评审会评审出来的。

6. 未来趋势研判：制造Agent下一步往哪走

最后一个部分，基于我在一线观察到的技术演进方向和行业需求变化，谈几点对趋势的判断。这一部分更多是个人视角的分析，但我会尽量落在可验证的维度上。

6.1 从"对话式Agent"走向"流程嵌入型Agent"

目前市面上一半以上的Agent产品还停留在"你在对话框里问，我回答"的形态。但制造场景里，真正的价值在于Agent直接嵌入到业务流程节点中，不需要人主动找它。

流程嵌入型Agent意味着它会被事件驱动：当MES报出一个异常事件时，Agent自动醒来、自动分析、自动推送结果。这类Agent不再有"对话框"，更像业务系统里的一个智能引擎，在后台持续运转。这种形态对工程化的要求更高（事件机制、任务的优先级、阻塞恢复），但它才是Agent真正创造规模价值的方向。

6.2 多模态感知Agent将加速渗透车间现场

制造业的Agent不会只停留在电脑屏幕前。随着视觉大模型和边缘算力设备的发展，具备视觉感知能力、能看懂现场设备状态和操作行为的Agent正在出现：质检Agent直接看图判断缺陷，安全Agent识别违规操作，甚至可以跟AR眼镜结合，给维修人员做实时指引。

过去视觉类AI需要单独训练特定模型，现在多模态大模型让"看懂"的门槛大幅降低，同一个模型可以理解多种场景。这个能力一旦跟Agent的任务拆解能力结合，制造业数字化中"最后一米的物理世界感知"会有根本性突破。

6.3 从单企Agent到产业链Agent协同

再往远看一层：如果每家核心工厂都建立了自己的Agent平台，上下游企业之间是否可以让Agent与Agent直接对话？比如主机厂的采购Agent在库存告急时，可以直接向供应商的订单Agent发起批量询价和交期确认——这不只是API对接，而是基于统一语义的智能协同。

这个场景技术上是可行的（Agent通信协议逐步标准化），但落地会非常依赖伙伴企业的数字化成熟度，以及一个产业级的信任机制。这个大方向短期内不会成为主流，但已经在一些龙头企业的供应链协同项目里露出苗头，值得持续关注。

6.4 小模型与Agent的结合会越走越深

制造业对模型的经济性非常敏感，动辄上亿参数的云端大模型长期来看不是车间场景的最优解。已经有趋势是：用较小的开源模型做本地Agent的"大脑"，针对特定业务做微调（比如设备故障诊断、标准作业指导），效果可以逼近大模型，但成本只有后者的零头。

这种"小模型加知识库加确定性工具"的组合，会逐渐成为制造业Agent应用的主流形态。大模型的价值更多体现在"生成合成数据、离线提炼知识、训练小模型"的环节，而不是在每个实时请求上都跑一次。这个判断如果成立，今后实施Agent项目的GPU门槛会大幅下降，中小制造企业也能真正用起来。

最后再分享一点个人体会。我在制造企业里做Agent项目，最深的感受是：这行当没有银弹，Agent不是说说话就能把老工厂改造了的。真正的推进力，来自团队愿意坐在车间办公室，跟生产计划员、设备工程师一个个去聊流程痛点，然后把大模型能力跟那些成熟了几十年的工业软件老老实实地接起来。技术框架会迭代，模型会换新，但"把业务流程搞清楚、把数据底座打扎实、把人机协作文案做好"这三件事不会变，谁先把这三件事做扎实，谁的Agent项目就能真正在车间里站起来。