聊到AI Agent，这两年圈内人已经从“什么是Agent”吵到了“Agent怎么在产线上不翻车”。CNCC2026会场里，汽车研发和智能制造的话题热度明显高于Demo演示——大家已经不想再看玩具了，而是想搞清楚：它到底能在工业深水区干哪些脏活累活，又该怎么安全地接进现有系统。这篇文章不聊概念模型，只聊我在这些场景里反复推敲过的应用模式、踩过的坑，以及一个能落地的最小技术骨架。想真正上手把Agent用起来的工程师、架构师，都可以拿去做参考。
1. 先把概念掰开：AI Agent、LLM和AI模型到底差在哪
1.1 一句话说清三者的层级关系
很多人把AI Agent、LLM、AI模型混着用，但一落到技术选型就懵了。AI模型是所有学习算法的总称，线性回归、随机森林、CNN、Transformer都属于这个范畴；LLM是其中专门处理自然语言和代码的大规模神经网络模型，DeepSeek就是这类模型，属于AI模型中的一个分支。AI Agent则是一个软件系统，技术上通常以LLM为核心，再叠加感知外部输入、维护记忆、规划行动步骤、调用工具、执行动作等模块，最终完成一个完整任务。
用造车来打比方：AI模型是发动机，LLM是一台高性能发动机，而AI Agent是把发动机装进底盘、配上变速箱和方向盘跑起来的车。DeepSeek是发动机，它本身不是车。你可以买一台发动机回来自己造车，也可以直接用别人造好的车。这个区别不是理论咬文嚼字，而是决定你项目的技术架构。如果团队说“我们用了AI Agent”，但实际只是接了一个LLM的API，交付时一定会被质疑。反过来，你真把Agent当成系统工程来做，才有机会在工业场景里站稳脚跟。
| 类型 | 本质 | 在工业场景里怎么用 | 典型例子 |
|---|---|---|---|
| AI模型 | 完成特定模式的预测、识别 | 做缺陷检测、参数回归、文本分类 | CNN、LSTM、Transformer |
| LLM | 大规模语言模型，AI模型子类 | 理解需求文档、生成代码、问答 | DeepSeek、Qwen、ChatGLM |
| AI Agent | 以LLM为大脑的自主任务系统 | 自动拆解需求、调用CAE/PLM/MES工具并闭环 | 基于LangGraph、Spring AI搭建的应用 |
1.2 为什么工业场景特别需要Agent
工业软件过去最擅长的是把确定流程刚性化，但工业现场大量工作恰恰是非标准的。汽车研发一个设计变更可能牵动BOM、仿真、试验、法规文档多个环节，以前靠工程师在Excel和邮件里来回搬运；智能制造更麻烦，设备报警、质量波动、排产调整相互纠缠。AI Agent能把这些环节中的非结构化输入消化掉，调用企业已有的数字化系统，把“人找工具”变成“Agent找工具”。
工业深水区的判断标准很简单：能不能对结果负责。Demo里Agent帮你写周报，错了没关系；产线上Agent给出一条错误维护建议，停工成本可能就是几十万。所以工业Agent不会用“自由发挥”的方式落地，而是被设计成“先理解约束，再调用工具，最后让人确认”。这不是保守，而是工业场景对可靠性的硬要求。
2. 汽车研发里的AI Agent：从文档助手到仿真优化闭环
2.1 研发链路里的机会到底在哪
汽车研发链条很长，市场定义、造型、整车集成、仿真、试验、法规认证、量产导入，每个节点都产生大量文档和数据。最典型的痛点不是缺少某个软件，而是软件之间的信息断层。比如NVH工程师要做一轮新的仿真分析，得先去PLM系统里找上一个项目的数模，再手动配置求解器参数，跑完还要把结果誊到PPT里和试验报告对比。这套流程里，真正费时间的不是计算，而是来回搬运上下文。
这种场景天然适合Agent介入。它不是要取代工程师，而是把工程师从“搬运工”状态里解放出来，让工程师把时间花在判断方案、审核结果上。汽车研发的流程长、文档多、工具杂，恰恰是Agent发挥串联作用的最佳温床。很多车企已经开始在研发中台里试点Agent，目标是打通SOR、设计、仿真、试验这条主链路。
2.2 典型Agent模式与工作流
先举几个已经在做或正在验证的Agent场景：
- 需求解析Agent：读取整本SOR，拆出功能指标和验收标准，自动生成可追溯矩阵。
- 设计评审Agent：把设计BOM和DFMEA库做交叉对比，命中历史问题模式时给出警告。
- 仿真调度Agent：接收仿真请求后，自动校验网格质量、提交计算任务、监控收敛曲线，异常时尝试调整参数并重跑。
- 测试报告Agent：从台架数据文件里提取特征，按模板生成对比报告，并把结论推送到项目群。
这几个Agent不需要多高的智能，关键是能稳定调用工业工具。归根结底，Agent的护城河不在模型，而在工具链的完整程度。
用一个简化链路来说明它们在研发流程里的位置：
SOR文档 -> 需求解析Agent -> 指标清单 -> 设计Agent 设计Agent -> 方案模型 -> 仿真Agent -> 结果摘要 -> 测试Agent -> 验证报告 -> PLM状态更新这个链路里每个节点都可以用不同模型驱动，某个Agent用DeepSeek跑规划和推理，另一个Agent用专用小模型做参数提取，这样成本更优。比如仿真Agent里，用一个小模型做参数识别，再让大模型做异常判断，整体延迟和费用都能压下来。架构上各Agent通过消息总线传递数据，而不是简单在一个Prompt里塞全程。
2.3 落地时千万别忘了“副驾驶”定位
再往深走一步，你会发现汽车研发里的Agent必须接受约束：软件授权、数据权限、责任边界。我见过一个仿真中台项目，Agent自动提交计算任务，结果把公司的CAE许可证全部占满，导致其他工程师无法工作。后来我们在Agent外面加了一层“资源水位监控”，超过并发阈值就排队或转人工。还有PLM审批流，Agent不能直接改设计状态，只能生成变更申请。记住，在汽车研发里，Agent永远是一个“提交者”，不是“决策者”。
这也引出一个经验：想让Agent在研发口落地，必须先说服数字化团队和设计部门建立一套“人机确认机制”。Agent生成的报告、变更申请、仿真结论，都要在流程里保留确认节点。这个机制不是给Agent拖后腿，而是给项目兜底，避免“模型出错没人担责”的尴尬局面。
3. 智能制造里的AI Agent：产线、PLC与边缘部署
3.1 制造现场为什么不能只用云端大模型
制造现场与办公室环境差异很大。产线中机器人急停、安全光栅、PLC扫描都是毫秒级动作，大模型一次推理可能要几百毫秒甚至几秒，要是拿Agent直接走实时控制闭环，很容易出事故。智能制造里的Agent定位不是替代PLC，而是做PLC的“副驾驶”和“参谋长”：实时控制继续由PLC负责，Agent负责读取和分析报警、预判设备趋势、优化排产建议。它更多在边缘侧或云端做非实时性任务，再通过消息把建议下发给操作员或MES系统。
换句话说，Agent和PLC的分工是：PLC管“这一刻怎么做”，Agent管“下一步怎么做”。前者是确定性的、硬实时的，后者是策略性的、柔实时的。把两者解耦，才能既保证产线安全，又发挥大模型的智能优势。
3.2 AI Agent如何辅助PLC编程和调试
热词里很多人问AI Agent与PLC编程的关系。我的判断是：现在最能落地的是用Agent辅助生成PLC程序骨架，而不是让Agent直接接管PLC。工业控制领域对确定性要求太高，老师傅写的程序都有严格注释、版本和测试记录，Agent生成的代码必须经过人工评审才能使用。举个例子，你给Agent一句话：“传送带卡料超过3秒触发停机，亮黄灯提示人工处理。”它能生成类似下面ST风格的逻辑：
IF Conveyor_Blocked_Time >= T#3S THEN Motor_Stop := TRUE; Warning_Lamp := YELLOW; Alarm_User[1] := TRUE; END_IF;这段逻辑不复杂，但Agent的价值在于：把散落在老师傅经验里的“如果卡料3秒就停”这类规则，快速转成可读的结构化文本，减少从自然语言到代码的翻译成本。更进一步，可以把历史故障树、操作说明、报警手册都喂给Agent做上下文，它就能在生成代码时主动补上联锁条件、复位逻辑。当然，代码下载到PLC前必须过仿真和人工确认，绝对不能跳过。
3.3 工业Agent的参考架构
再说说整体架构。工业Agent落地通常分四层：设备层、边缘层、平台层、云层。设备层通过OPC UA、Modbus、Profinet等协议把PLC、传感器、机器人接入；边缘层部署轻量化模型和Agent运行时，做实时数据清洗、报警分类、规则判定；平台层统一管理所有Agent，负责知识库、模型服务、审批流程；云层做离线训练和全局优化，但不直接面向产线。层与层之间用消息总线解耦，典型协议是MQTT Sparkplug B或Kafka。
| 层级 | 主要职责 | 常用技术/协议 |
|---|---|---|
| 设备层 | 采集数据、执行指令 | PLC、传感器、OPC UA、Modbus |
| 边缘层 | 实时计算、轻量模型推理、规则兜底 | 工业网关、Docker、量化模型 |
| 平台层 | Agent编排、知识库、权限审计 | Spring AI、LangGraph、向量数据库、统一权限服务 |
| 云层 | 训练优化、全局调度 | GPU集群、模型训练平台 |
这套架构的核心思想是边界清晰：模型只负责理解和生成，控制指令必须经过规则引擎和安全校验。Agent可以在边缘侧或云端运行，但它能调用的动作集合是提前声明好的。比如Agent可以推荐“把3号工位的节拍降低5%”，但要真正修改PLC里的速度参数，必须经过控制层审批。
3.4 模型与场景的匹配策略
很多团队一上来就选最大的模型，其实在智能制造里往往是浪费。短文本报警分类、设备名识别、状态判断这类任务，用7B/13B的轻量开源模型在边缘就能跑，延迟可能20毫秒就够；复杂工况诊断、多Agent规划、长期推理，才需要DeepSeek这类大参数模型，放在云端或本地GPU集群。更关键的是，安全控制永远要用规则引擎兜底：Agent给出建议，规则引擎判断这个动作合不合规，再决定是否下发给产线。你可以把它理解成“Agent负责聪明，规则负责不闯祸”。
4. 从0到1搭建工业AI Agent：技术栈与实操步骤
4.1 Agent的组成结构
从0到1搭工业Agent，先要把组成结构想清楚。工业Agent不是简单调一次大模型API，而是一个小系统。我通常按六个模块设计：感知、记忆、规划、工具、行动、安全。感知模块接收用户输入或系统事件，比如MES工单、设备报警；记忆模块保存对话历史、任务上下文、历史案例，常用向量库加Redis缓存；规划模块把目标拆成步骤，典型的ReAct、Plan-and-Execute；工具模块统一封装外部系统接口，比如查数据库、调CAE、发消息；行动模块执行具体动作并返回结果；安全模块管权限、白名单、审计日志，这也是工业场景最不能省的部分。
| 模块 | 职责 | 工业落地示例 |
|---|---|---|
| 感知 | 接收意图和外部数据 | 用户自然语言、MES工单、PLC报警 |
| 记忆 | 保存上下文和历史经验 | 向量数据库、Redis会话缓存 |
| 规划 | 把目标拆成可执行步骤 | ReAct、Plan-and-Execute |
| 工具 | 调用外部系统 | 查数据库、调CAE接口、发HTTP请求 |
| 行动 | 执行动作和输出结果 | 生成报告、写入工单、审批建议 |
| 安全 | 权限约束和过程审计 | 角色权限、操作白名单、审计日志 |
安全模块放在最后不是因为它不重要，而是需要贯穿所有模块。工业Agent的权限要比普通软件更严格：模型可以被超过上下文限制，但工具的调用权限必须由统一的服务管理。比如设备报警诊断Agent能查询知识库，但不能直接改PLC参数，这是底线。
4.2 技术栈选型：Python生态与Java企业级
工业界落地时经常分两派：Python派和Java派。Python生态胜在AI算法库丰富，LangGraph、LlamaIndex、AutoGen都很成熟，适合做算法原型和模型服务；Java派更看重企业级治理，Spring AI加上Spring Cloud，可以把Agent做成微服务，纳入现有的配置中心、注册中心、权限体系、链路追踪。我见过不少车企和制造企业，本身就是Java技术栈，让团队为了Agent重新学Python并不划算，用Spring AI直接编排Agent反而更顺。
两条技术栈不冲突：Python做模型推理服务，Java做业务流程编排，中间用HTTP或消息队列对接。常用的组件大致是这样的：
- 模型服务：DeepSeek、Qwen等LLM，通过OpenAI兼容接口封装
- Agent编排：LangGraph（Python）、Spring AI（Java）
- 知识库：RAG + pgvector或Milvus
- 工业接入：OPC UA SDK、MQTT客户端
- 可观测：审计日志、链路追踪、模型调用监控
这套组合的好处是每一层都可以替换。你今天用DeepSeek，明天换成Qwen，只要接口不变，Agent编排层不用动；今天用LangGraph，明天觉得Java侧更稳，把流程迁到Spring AI也不至于推倒重来。工业最忌讳技术栈绑死，留出替换空间很重要。
4.3 实操：做一个设备报警诊断Agent
写一个最小但完整的闭环。任务：设备报警诊断Agent，输入报警代码，输出处理建议。我用LangGraph风格来表达，但里面的函数都是示意，大家可以直接改造成自己的场景。
from langgraph.graph import StateGraph, END from typing import TypedDict, Optional class AgentState(TypedDict): alarm_code: str device_id: str history: Optional[str] suggestion: Optional[str] def parse_alarm(state): # 1. 从报警文本中抽取设备ID和故障码 # 这里为了演示，直接透传 return state def search_knowledge(state): # 2. 在历史故障库中检索相似记录 state["history"] = query_knowledge_base(state["device_id"], state["alarm_code"]) return state def generate_suggestion(state): # 3. 调用LLM生成处理建议，并确保只输出白名单格式 state["suggestion"] = llm_generate(state["history"], state["alarm_code"]) return state graph = StateGraph(AgentState) graph.add_node("parse_alarm", parse_alarm) graph.add_node("search_knowledge", search_knowledge) graph.add_node("generate_suggestion", generate_suggestion) graph.set_entry_point("parse_alarm") graph.add_edge("parse_alarm", "search_knowledge") graph.add_edge("search_knowledge", "generate_suggestion") graph.add_edge("generate_suggestion", END) app = graph.compile() result = app.invoke({"alarm_code": "E-402", "device_id": "Robot-01"}) print(result["suggestion"])代码里最关键的一步是search_knowledge：先把报警代码和设备ID拿去历史库检索，再让LLM基于检索结果生成建议。如果反过来让LLM直接回答，大概率会一本正经地编出维修步骤。生产系统里，search_knowledge可以扩展成同时查备件库、排班表、操作手册，工具并跑，再把结果拼接起来。这样Agent给出的建议才是可追溯、可执行的。
4.4 多智能体协作模式与开发规范
当你不想把功能全部塞进一个Agent时，就需要多智能体协作。常见模式有三种：Router模式，一个主Agent把请求分发给专业子Agent；Pipeline模式，按流程依次传递，比如需求、设计、仿真、测试；Blackboard模式，多个Agent共享一块“黑板”（消息总线），各自往上面写结论。汽车研发里Pipeline最直观，制造现场Router更常见。
协作过程要有开发规范。我给团队定的基线是：每个Agent必须有明确的输入输出JSON Schema，工具调用必须注册统一Schema，提示词模板要版本化管理，Agent之间不允许直接读私有库，只能通过消息总线交换结果；全链路必须有审计日志，模型输出要保留原始记录。这一套本质上和开发微服务没有区别，只是把“逻辑”换成了“模型加工具”。
5. 常见问题与排查技巧实录
5.1 模型幻觉，如何把输出钉在知识上
先说最有共性的坑：模型幻觉。大模型不知道你企业的私有知识，如果你直接问它“咱们厂3号空压机上次大修是什么时候”，它很可能编一个时间。治这个问题的三板斧：第一，强制RAG，所有专业知识先检索再生成；第二，结构化输出，让模型只能填JSON字段，不允许自由发挥；第三，置信度低时就转人工。最好再加一个追溯字段，让Agent每个结论都带上知识条目ID，后续出问题能查到出处。
在实际项目里，我还会在模型输出后接一道“校验过滤器”。比如让模型只能输出JSON，但JSON里的枚举值必须先过白名单，匹配不上就直接拒绝并改成“需人工确认”。这样即使模型临时抽风，也不会把错误信息带进工单。
5.2 OT/IT对接的四个隐形坑
对接OT系统时，我遇到的坑比想象中更多。传统IT团队进入工业现场，最容易低估的就是协议、权限和环境复杂度。列几个典型的：
- 协议不通：老设备只有Modbus RTU，Agent服务是HTTP JSON，中间必须加边缘网关做协议转换。
- 时基不统一：报警时间、PLC扫描周期、MES工单时间有时差，直接关联会张冠李戴，先统一时基再谈数据治理。
- 权限边界：Agent不能直连PLC寄存器，所有写操作必须经过白名单服务和人工复核。
- 数据不出厂：生产数据往往敏感，模型尽量私有化部署，云服务只传脱敏汇总。
| 问题 | 现象 | 解决思路 |
|---|---|---|
| 协议不通 | 设备数据接不进Agent服务 | 加边缘网关做Modbus/OPC UA到JSON的转换 |
| 时基不统一 | 报警记录和工单时间对不上 | 统一时基，所有系统用同一时间源 |
| 权限越界 | Agent偶尔尝试下发危险指令 | 写操作白名单、人工复核、审计日志 |
| 数据外传风险 | 生产数据不能上公有云 | 私有化模型部署，云端只传脱敏数据 |
这些坑往往不会在Demo阶段暴露，因为Demo数据是干净的，现场数据是乱七八糟的。上线前做一轮“脏数据演练”，把错位时间、缺失字段、乱码报警都喂一遍，比什么预案都管用。
5.3 模型选择时几个容易犯的错误
选模型常见的几个错误也提一下：一是只看榜单不看场景，DeepSeek在一些复杂推理任务上很强，但产线上“短文本分类”用小模型更快更省；二是只看聊天体验不看任务完成率，Agent任务完成率才是关键指标；三是不做延迟容错，外部模型API高峰期会抖动，生产环境必须加超时重试、限流、降级；四是不算失败成本，一次错误建议可能引发连锁反应，宁可多设人工确认点。
一个比较实用的做法是“分层选型”：规划、总结、复杂推理用大模型；字段提取、分类、相似度匹配用轻量模型；确定性逻辑用规则引擎。每一层各司其职，既控制成本，又提升整体稳定性。
5.4 几个奇怪的故障与修复实录
分享几个我实际遇到的奇怪故障：上下文爆炸。为了让Agent处理维修手册，把整本手册塞进Prompt，结果模型“晕了”，回不到用户问题。解决：把手册先分块索引，只检索相关片段。工具调用死循环。Agent反复调用查询接口，每次都说“再查一次才能确定”。解决：限制单次任务最大调用次数，加熔断。多Agent死锁。设计Agent等仿真Agent给结果，仿真Agent等设计Agent确认数据，互相卡住。解决：每个编排节点加看门狗，超时后自动生成中间态升级人工。
这些故障不看日志根本猜不到，所以工业Agent上线前一定要把监控和日志做好。每个Agent的输入、输出、工具调用耗时、模型Token消耗，都要能在一条链路里拉出来。否则出了问题，你只能对着一个黑盒干瞪眼。
在工业里做AI Agent，最大的体感不是模型多聪明，而是工程约束多严格。项目能不能成，往往取决于你把多少脏活提前想好了：数据统一了吗？权限界清楚了吗？出错了谁兜底？给Agent留一个人工确认按钮，永远比让模型全自动更受欢迎。我个人这两年最深的体会是：别一上来就搭超级Agent，先选一个足够痛、边界足够清楚的小场景，比如设备报警诊断、维修工单分诊，把数据、工具、人这三件事跑通，再慢慢扩成多智能体协同。CNCC2026上的很多案例，也都是这样一点一点磨出来的。AI Agent进工业，能跑到最后的人，一定不是把模型调得最炫的人，而是把刹车和方向盘做得最稳的人。
