企业官网建设流程全解析

1. 在CNCC2026现场被问得最多的一句话：Agent到底能干什么活

今年CNCC2026的智能计算专题区，几乎每个展台前都有人在问同一个问题：AI Agent和以前那些AI工具到底有什么区别？我坐了几场论坛，发现工业界的关注点明显和互联网圈不一样。互联网谈Agent，聊的是写文案、订机票、做Excel、编排工作流；工业圈聊Agent，说的是图纸、工艺参数、PLC程序、产线异常处置、质量追溯。一字之差，背后的难度是两个量级。

先说一个基础判断：**DeepSeek这类模型属于大语言模型（LLM），是Agent的“大脑底座”，但模型本身不等于Agent。**一个能对话的模型，你给它一个具体任务，它能给你一段建议；但它不会自己去调MES系统里的数据、不会主动翻企业知识库里的历史故障记录、不会在凌晨三点产线报警时自动拉起故障处置流程。Agent和LLM的区别，简单说就是：LLM是“会说话的大脑”，Agent是“会干活的手脚+能记忆的脑子+会调用工具的人”。

那“智能制造”在Agent语境下到底意味着什么？我的理解是：企业不再满足于“一个能回答问题的聊天机器人”，而是要一个能对接研发系统、读取设备数据、协同多个业务系统的“数字员工”。这也是标题里“深水区”三个字的由来——浅水区的Agent谁都会做，真正难的是让Agent走进研发流程和产线，去碰那些高门槛、高责任、低容错的系统。这篇文章就围绕我在汽车研发和智能制造项目里的实际经历，把Agent落地的思路、架构、踩坑和选型逻辑讲透。

2. 汽车研发侧的Agent落地：从“资料检索”变成“设计决策链”

汽车研发大概是工业企业里数据复杂度最高的领域之一，整车开发周期动辄三五年，涉及的BOM零件上万个，设计规范、试验标准、变更记录分散在PDM、PLM、TDM等多个系统里。传统知识管理系统最大的问题不是“没存”，而是“找不到”和“用不上”。Agent在这里的价值，不是帮你搜出一堆文档标题，而是直接完成“拿到问题→理解约束→给出决策建议→生成交付物”这条完整链路。

2.1 研发知识库：让老工程师的经验变成可检索资产

我在一个自主品牌主机厂的技术中心做过一个Agent试点，需求说来简单：工程师日常要查大量法规条款、设计规范、历史问题库。以前靠什么？靠问人。新来的底盘工程师想查某个支架的结构设计要点，得先搞清楚哪位老工程师管过这块，再等人家有空，翻文件夹，发给你。效率低不说，老工程师退休了就带走了。

我们的做法是搭一套基于RAG的Agent，接三个数据源：PLM里的设计规范文档、TDM里的试验报告、历史FMEA数据库。这里有个容易被低估的细节：**RAG的质量不取决于用了哪个向量模型，而取决于对硬件的切分策略和文档解析精度。**汽车规范类PDF动辄几十页，表格、公式、图纸混排，直接用文本切分器把PDF按固定长度切，检索出来的上下文经常是断裂的。我们换成了按“章节+条款编号”的结构化切分，给每个条款打上产品域、零件类型、法规国别这类业务标签，检索命中率从不到50%直接拉到85%以上。

Agent的效果之所以比传统搜索好，不只是因为召回准了，而是因为它在回答里带了“决策链”。工程师问“这个支架的模态频率目标设在多少合适”，Agent返回的不只是一条标准条款，而是把相关规范要求、同平台车型的历史设计值、甚至上一次样车试验暴露的问题全部汇总成一份参照说明。老工程师的经验，某种意义上被结构化沉淀下来了。

2.2 仿真与验证环节的Agent辅助：从参数推荐到报告自动生成

研发流程里最耗人的环节，除了方案设计，就是仿真分析和试验验证。仿真要设置边界条件、挑材料卡片、定网格密度；试验要写大纲、跟踪进度、整理数据、出报告。这些工作技术含量高，但里面有大量“约定俗成”的参数和流程，非常适合Agent去干“准备”和“收尾”的活。

我们做了一个仿真前处理Agent，让它根据分析师输入的结构描述和工况条件，推荐材料型号、焊点类型、载荷施加方式，并直接生成一份仿真设置清单。它不直接替代分析师，而是把过去三天里一天用来查资料、翻存档、问前辈的时间压缩到半小时以内。另一个是试验报告Agent：从试验数据管理系统里拉取原始数据，结合试验大纲自动生成报告的图表、结论模板、偏差分析，工程师只需要审核和签字。

这个场景里最关键的架构设计是一个原则：**Agent生成的任何东西都只到“草稿”状态，必须有角色审核环节。**仿真参数清单要专业人员确认，试验报告要有试验工程师签发。看起来多了一道流程，但这正是工业Agent和C端Agent的本质区别——工业场景要的是降低工作负担，不是取代人的判断责任。

2.3 一个能跑的参考流程：Agent在企业网内怎么搭

很多团队问我不上云、在企业内网里Agent能不能跑，我的回答是能，而且应该这么跑。汽车企业的研发数据有强保密要求，不可能把BOM和图纸传到公网模型服务上。我们的做法是私有化部署一套较小的基础模型做推理，配合企业内的向量数据库和Agent编排服务。

跑通的流程大致是：

• 工程师在统一入口提交问题（钉钉、自研门户或Teams机器人均可）
• 入口服务先判断问题类型，分发给对应的Agent子任务
• Agent读取用户权限，带着权限去检索PLM、TDM的知识库切片
• 检索结果灌入提示词模板，大模型生成结构化回答
• 回答中附上引用来源和原文链接，方便工程师回溯验证
• 所有操作日志留痕，满足研发数据审计要求

这套链路里最容易被忽略的点是权限。Agent检索时必须继承用户权限，不能让Agent变成越过权限的“万能搜索”，否则质量管理体系审计第一个不通过。我们当时在权限这块额外做了两层：数据源接入层按账号映射过滤底层文档，提示词构建层再做一轮字段级裁剪。

3. 智能制造现场的Agent实践：当Agent开始和PLC打交道

如果说汽车研发侧的Agent是“脑力辅助”，那智能制造现场的Agent就是“手眼协同”。我在几个焊装车间和电池PACK线里看到的Agent应用，和PPT里画的完全不一样——现场没有科幻感，机柜里是可编程逻辑控制器（PLC）、传感器网关、工控机，网络是隔离的，数据是脏的，流程是不允许出错的。Agent在这里的第一个任务不是“智能化”，而是先把过去干活的方式重新组织起来。

3.1 为什么工业现场比办公室场景难过十倍

工业现场做Agent，有个办公室场景根本不会遇到的坎：**Agent要连的系统都在OT网络里，而且通讯协议五花八门。**PLC有西门子、罗克韦尔、三菱、欧姆龙等品牌，老一点产线还有串口、Modbus RTU、Profibus、OPC DA，新产线才逐步上OPC UA。设备数据不干净，同一个温度点的数据在PLC里有10秒的平均值，在MES里又有另一个口径。Agent再聪明，底层数据接不通，它就是空中楼阁。

另外一个坎是响应确定性。办公场景的Agent答错了，改一下重新生成就行；产线上的Agent如果给出了错误的排产建议，或者自动下发了一个不合理的参数，轻则产生批次报废，重则造成设备碰撞。所以我在产线类项目里始终强调一个原则：现场Agent更多承担“感知、辅助决策、告警、生成处置建议”的职责，真正的执行指令永远要过人机界面（HMI）确认那一关。

3.2 PLC编程辅助Agent：让老师傅的梯形图逻辑变成自然语言

我注意到最近“AI Agent与PLC编程”成了一个热门组合词，这确实是目前工业AI领域讨论度高的方向。过去PLC调试依赖工程师读梯形图、查变量表、翻说明书。一个老师傅脑子里装着几百个点位地址和它们的逻辑关系，年轻工程师接手时只能一个个查。Agent能改变什么？它能帮你做三件事：解释、检索、生成。

解释方面，把一段梯形图或结构化文本（ST语言）程序导入Agent，用自然语言描述“这段逻辑在做什么”，老师傅写的复杂互锁逻辑，新人几秒钟就能看懂大意。检索方面，用自然语言描述“哪个变量控制3号工位的夹紧动作”，Agent直接定位到对应程序块和变量地址，不用再手工翻工程文件。生成方面，给它工艺时序要求，辅助生成结构化文本程序的初稿，调试工程师再做修改和验证。

这里我要特别提醒一句：**Agent写出来的PLC程序，当前阶段绝对不能直接烧录到控制器里跑。**它不是“程序自动生成工具”，而是“工程师的辅助草稿工具”。我们项目中明确约定：Agent只生成ST语言初稿和注释文档，最终程序必须由持证工程师在仿真环境下验证。

3.3 多智能体协作的产线调度：排产、质检、设备预测维护的联动

真正让我觉得“工业Agent开始走进深水区”的，是多智能体协作。单点Agent解决单点问题，价值有限；一旦多个Agent组合起来，形成一条判断链和处置链，价值就出来了。我们在一个电池模组产线做了个试点，三个Agent协同工作：质量检测Agent、设备预测维护Agent、生产调度Agent。

质量检测Agent读取视觉检测系统和过程参数数据，把一段时间内的缺陷率趋势、缺陷类型、相关工艺参数相关性分析出来，输出“疑似异常工序”判断。这个判断不是直接下达停机指令，而是发给生产调度Agent。调度Agent结合当前订单交期、线体产能、在制品状态，给出处置建议：继续生产但加大抽检频次，或者切换备用工位，或者安排短停检修。设备预测维护Agent则根据振动、电流、温度数据，判断设备劣化趋势，把“建议在下次换型时增加保养项”这类信息提前推给调度Agent。

这个协作链路里，每个Agent的能力边界是清楚的，数据是共享的，决策权却是分级授权的。质量Agent只能“报警”，调度Agent只能“建议”，最终“执行”由产线班长在终端确认。我们管这个叫“工业Agent的三级权限体系”——感知层、分析层、执行层，层级越高，Agent的权限越小，人的确认越不可少。加粗显示这一点，是因为所有做工业Agent的团队第一个踩的坑都是“想让Agent一步到位全自动”，结果全是被现场管理一票否决。

4. 企业级Agent平台的技术底牌：组成结构、Skill、Memory与MCP

聊完场景，得扒一扒技术底牌。这半年“Agent组成结构”“Skill”“Memory”“MCP”这几个词成了热搜常客，我也在CNCC2026的Agent相关分论坛里被反复追问。我的看法是：工业级Agent平台，本质上是一套“大脑+记忆+工具+控制器”的工程架构，而不是某一个大模型或者某一个框架。

4.1 Agent的组成结构：规划、记忆、工具、执行四件套

一个能进工业场景的Agent，我习惯拆成四层来看：

• 模型层：也就是LLM底座，负责理解、推理和生成。私有化部署通常选百亿到千亿量级的中小规模模型，兼顾效果和成本。
• 规划层：把用户目标拆解成子任务，判断调用哪些工具、按什么顺序执行、遇到异常时怎么处理。这是Agent和普通对话机器人的分水岭。
• 记忆层：分短期记忆和长期记忆。短期记忆保存当前任务的上下文，长期记忆存储企业的业务规则、历史处理方案、用户的偏好习惯。
• 工具执行层：通过API、SDK、数据库连接器、工业协议网关去操作真实业务系统。

工业场景里这四层缺一不可，而且每一层都有特定要求。规划层不能只靠模型“自由发挥”，要给它一套业务规则模板，比如“涉及批次报废的决策必须转人工”。记忆层要解决企业知识准确性的问题，不能让它“凭印象”回答。工具执行层最复杂，因为要面对异构系统的接口。

4.2 Skill与MCP：把企业系统和Agent解耦的关键

“Skill”（技能）和“MCP”（模型上下文协议）是今年讨论频率最高的两个词，它们的核心作用是一样的：**让Agent和业务系统之间不要硬编码耦合。**没有这层抽象的时候，Agent每接一个新系统，都要重新写一套工具调用逻辑；业务系统一改接口，Agent就废了。

Skill本质上是把“完成某类任务所需的能力”封装成可复用的模块。比如“查BOM变更记录”“读取PLC报警代码”“生成试验报告模板”，每个Skill封装了对应的调用参数、输入输出格式、异常处理逻辑。Agent在规划阶段先决定调用哪个Skill，再通过MCP标准协议去发现和调用外部能力，也就是所谓“工具即插即用”。对我们做企业落地的人来说，这层抽象最大的好处是：你可以在不改Agent核心代码的情况下，不断往平台里加新Skill，就像给机器人换手爪。

4.3 选型思考：Spring AI这类框架在企业Java体系里的优势

关于Agent框架选型，社群和热搜里一直争论不休，比如LangChain、Semantic Kernel、Spring AI等。我自己判断一个框架能否用于工业级项目，就看两条：一是团队现有技术栈能否驾驭，二是它和企业存量系统对接是否顺畅。

国内工业企业，尤其是汽车、装备制造、能源这些行业，存量IT系统以Java技术栈为主。这也是我特别关注Spring AI这类框架的原因——它让Java团队不必从零啃一套Python生态，可以直接把Agent能力嵌进既有的微服务体系里，统一走Spring的配置、事务、监控、安全机制。我见过不少企业级Java团队做Agent，用Spring AI搭底，配合自研的连接器和RAG服务，代码维护成本确实可控。

另外一个选型经验是：**不要指望一个框架解决所有问题。**我们实际项目中，Spring AI做Agent编排和请求链路，LangChain的思想用于设计记忆和子任务拆解，模型本身单独管理，三个部分是可以共存的。框架选型要服从于你企业“让Agent可控、可见、可审计”这个目标，而不是追新。

5. 踩坑实录与我的实操建议：从Demo到产线，中间的坑比想象多

写到这里必须进入我最想说的部分——踩坑。过去一年，我在几个工业Agent项目里踩过的坑，如果按影响排序，排最前面的有三个。

5.1 踩过的三个典型坑

第一个坑是幻觉问题在工业场景被无限放大。办公场景Agent答错了，大家笑一笑换个答案；工业场景Agent答错一个工艺参数，可能导致整批零件返工。我们有一版Agent在回答焊接参数时，把和另一条产线的数据混在一起，编出了一个不存在的“标准值”，幸好工程师复核时发现了。从那以后，我们规定Agent涉及数值、规格、标准的输出，必须附数据来源标识，且数值型回答一律走“先查库、后生成”的插件调用模式，不允许模型凭训练知识直接输出。

第二个坑是网络和数据架构没有提前规划。第一次做车间Agent试点时，IT和OT网络是隔离的，Agent部署在IT侧，拿不到PLC实时数据。最后协调安全部门在工业防火墙上开了白名单通道，又部署了边缘网关做数据单向转发，项目周期硬生生拖长了两个月。这个坑完全可以提前规避：做Agent之前先画一张数据流图，把数据源、网络域、安全策略、边缘节点位置全部标注清楚。

第三个坑是高估了大模型的“规划能力”，低估了规则引擎的作用。模型在复杂流程编排上仍然会“自由发挥”，把步骤顺序搞错。我们后来在规划层前面挂了一个轻量级的规则预处理器——业务人员用拖拽式规则把“哪些场景走什么流程”定义死，模型只能在规则允许的范围内做灵活编排。效果一下子稳了很多。这个经验其实可以推广到几乎所有工业Agent项目：大模型负责理解，规则负责兜底。

5.2 给AI Agent落地工业场景的六条实施建议

结合这些经验，我给已经在做或准备做工业Agent的朋友整理了一套可以直接照搬的实施建议：

• 先选一个高价值但低风险的单点场景切入，比如设计规范检索、设备故障代码解释、试验报告草稿生成；不要在第一个项目就做全产线多Agent协同。
• 数据先行，先把数据源摸清楚，哪些数据在MES、哪些在PLC、哪些在PLM，质量如何，清洗和链接工作往往占整个项目50%以上的工作量。
• 私有化部署优先，工业数据不出厂区是红线，至少也要做企业专属区域部署，敏感信息绝对不能落到公有模型服务上。
• 权限继承和审计机制在第一天就设计进去，Agent调用任何数据源都带用户身份，所有操作留日志，出了事能回溯。
• 设计人机协作的确认节点，凡是涉及执行、报废、停线、参数修改的环节，必须有人的确认步骤，不要试图全自动化。
• 从单Agent走向多Agent要尊重现有的组织分工，质量科只管质量，调度科只管调度，Agent的边界划分也按这个来，不要做一个“万能Agent”把所有活都干了。

关于钢铁、汽车、电子制造等不同细分行业，Agent的切入点确实会有差异，但上面这六条算是通用方法论。我见过不少团队一上来就规划“十大场景”，最后连第一个场景都没跑通，问题就出在没控制复杂度。

5.3 下一步我会怎么扩展

我个人的下一步，会重点关注两个方向。一是Agent与工业数字孪生的结合，让Agent在虚拟环境里先做预演和验证，再往物理世界下发建议，能大幅降低试错成本。二是把工业知识和Agent Skill更加系统化地组织起来，形成一套“工业Agent技能库”，让一个工厂沉淀的工艺技能可以通过标准化接口被另一个工厂复用。这背后需要行业标准和组织机制跟上，光靠技术远远不够。对刚进入这个领域的团队，我建议先别急着上一个“平台级”的东西，拿一个看得见效果的场景跑通，比什么都重要。

最后分享一个我自己一直在用的判断标准：一个Agent项目是否真正“走进深水区”，不看它接了多少个炫酷的模型，只看它是否改变了产线上一个人或研发里一个工程师的真实工作习惯，让他愿意每天都打开这个入口。做到了这一条，你的Agent才真的在工业现场扎下根了。