1. 制造业Agent落地的真实困境不是技术不够是场景没对齐我在制造业信息化这个圈子里待了快十年从最早的MES系统实施到后来的工业互联网平台再到现在满天飞的Agent概念见过太多“技术很美好、落地很骨感”的案例。最近半年几乎每周都有制造业的朋友来问我“我们老板说要搞Agent到底怎么搞”这个问题背后其实藏着一个非常现实的焦虑——Agent产品越来越多Demo一个比一个炫但真正能在车间里、在供应链上、在质检环节跑起来的少之又少。先说一个我亲眼见过的场景。某汽车零部件工厂2024年底上了一套基于大模型的“智能排产Agent”供应商演示的时候输入订单数据Agent自动生成排产计划还能根据设备状态动态调整看起来完美。结果上线两周就停了。原因特别朴素车间里的设备状态数据根本没有实时打通Agent拿到的永远是几小时前的“历史数据”排出来的计划跟实际产线情况对不上。更麻烦的是排产员根本不敢信Agent给出的结果因为Agent不会解释“为什么把A订单排在B订单前面”而排产员需要对这个决策负责。这就是制造业Agent落地的第一个核心矛盾Agent需要的是实时、准确、结构化的数据而制造业现场的数据往往是滞后的、孤立的、非结构化的。很多Agent产品在演示环境里跑得通是因为演示数据是精心准备的“干净数据”一旦接入真实生产环境数据质量问题就会让Agent的表现断崖式下跌。还有一个更隐蔽的问题制造业的很多决策场景本质上不是“信息不足”的问题而是“责任归属”的问题。排产员不敢用Agent不是因为Agent排得不好而是因为一旦排错了责任算谁的质检员不敢让Agent直接判定产品合格与否因为出了批量质量问题追责追到谁头上这些组织层面的问题不是技术能解决的但恰恰是Agent能否“真用上”的关键。所以当我们在讨论“制造业如何真用上Agent”的时候首先要做的不是选型、不是开发、不是部署而是场景筛选。不是所有场景都适合Agent也不是所有适合的场景都能立刻上Agent。我自己的经验是制造业Agent的落地场景需要同时满足三个条件第一数据可得性高至少能拿到准实时的结构化数据第二决策容错率相对较高Agent出错不会直接导致重大损失第三有明确的“人机协作”界面Agent做建议、人做最终决策。按照这个标准制造业里真正适合Agent优先落地的场景其实并不多。我梳理了一下自己接触过的案例大概有这么几类设备预测性维护的辅助诊断、供应链异常事件的初步归因、质量问题的知识库检索与推荐、生产报表的自动生成与解读。这些场景的共同特点是Agent不需要直接控制物理设备不需要做不可逆的决策而是扮演“副驾驶”的角色帮人更快地获取信息、缩小排查范围、生成初步方案。提示如果你所在的制造企业正在考虑上Agent建议先做一个“场景-数据-责任”三维评估表把候选场景列出来逐个打分。数据可得性低于6分的、责任归属不清晰的先放一放不要硬上。2. 从飞书多维表格到CLI工具制造业Agent的技术栈怎么搭聊完场景再聊技术。制造业Agent的技术栈跟互联网公司很不一样互联网公司可以全套自研制造业企业通常没有这个基因也没有这个必要。我见过比较务实的做法是用飞书多维表格做数据底座和交互界面用CLI工具做Agent的执行引擎用飞书机器人做消息触达。这套组合看起来不“高大上”但实测下来落地速度最快维护成本最低。2.1 为什么飞书多维表格是制造业Agent的天然搭档飞书多维表格在制造业里的渗透率可能比很多人想象的要高。我接触过的制造企业从几百人的中型工厂到几万人的集团几乎都在用飞书而且很多一线业务部门已经自发地用多维表格来管理生产计划、设备台账、质量记录。这意味着当你想要部署一个Agent的时候数据源和用户界面都是现成的。多维表格的优势在于第一它是结构化的每一列都有明确的字段类型Agent读取和写入都很方便第二它有API可以通过飞书开放平台进行程序化操作第三它的界面足够简单车间班组长都能上手不需要额外培训。我见过一个案例某电子厂用多维表格管理SMT贴片机的换料记录后来加了一个Agent自动分析换料记录和不良率之间的关联当某个料号的换料频率异常升高时Agent会自动在表格里标记并推送消息给工艺工程师。整个项目从立项到上线只用了三周。当然多维表格也有局限。它的数据处理能力有限单表超过5万行就会明显变慢复杂的关联查询也不如专业数据库。所以我的建议是多维表格适合做Agent的“前端”和“轻量级数据层”重度的数据分析和模型训练还是要放到后端。比如你可以用多维表格收集数据定期同步到数据仓库Agent的推理逻辑在后端完成结果再写回多维表格。2.2 CLI工具在制造业Agent中的角色定位CLI这个词在制造业信息化圈子里其实有点陌生但它的价值正在被越来越多的人认识到。简单来说CLI工具就是命令行界面工具它可以让Agent通过执行命令来完成各种操作比如调用API、读写文件、执行脚本。相比于传统的图形界面CLI的优势在于可编程、可组合、可自动化。我举个例子。假设你有一个Agent需要每天从MES系统导出生产数据清洗后写入多维表格然后生成日报。如果用图形界面你需要模拟点击、填写表单、等待加载任何一个环节出问题都会导致整个流程失败。但如果用CLI工具你可以写一个脚本把导出、清洗、写入、生成日报这几个步骤串起来Agent只需要执行这个脚本就行了。而且CLI工具通常有更好的错误处理和日志记录出问题了容易排查。目前市面上比较流行的CLI工具比如Codex CLI、Claude CLI、Trae CLI都可以用来构建Agent的执行层。它们的核心能力是接收自然语言指令转换成具体的命令或API调用然后执行并返回结果。对于制造业场景我特别推荐关注那些支持“工具调用”的CLI框架因为制造业Agent经常需要调用各种内部系统工具调用的灵活性和稳定性至关重要。注意选择CLI工具时一定要确认它是否支持你现有的系统环境。有些CLI工具对Windows的支持不够好而制造业现场大量使用Windows工控机。另外权限管理也要提前规划不能让Agent拥有过高的系统权限。2.3 飞书机器人Agent与人的“最后一公里”Agent分析出结果之后怎么让人知道飞书机器人是目前最顺滑的方案。你可以让Agent把结果直接推送到相关的群聊或个人的飞书消息里支持文本、表格、卡片等多种格式。我见过一个很实用的做法Agent每天早会前自动生成一份“生产异常简报”包括昨日异常事件、今日重点关注事项、建议的排查方向然后通过飞书机器人推送给生产主管。主管在手机上就能看不需要登录任何系统。飞书机器人还有一个好处是“可交互”。你可以在机器人消息里加按钮比如“确认”“忽略”“查看详情”用户点击后Agent可以继续执行后续操作。这就形成了一个闭环Agent推送建议人做决策Agent根据决策执行下一步。这种“人机协作”的模式比让Agent全自动执行要靠谱得多也更容易被制造业的老师和傅们接受。3. 一个可复现的制造业Agent最小可行方案说了这么多不如直接给一个可以抄作业的方案。下面这个方案是我自己在某个离散制造项目里实际用过的场景是“设备异常初步诊断”。整个方案不复杂但覆盖了从数据采集到消息推送的完整链路适合作为制造业Agent的入门项目。3.1 场景定义与数据准备这个场景的目标是当设备出现异常报警时Agent自动检索历史维修记录和知识库给出初步的故障原因排序和排查建议推送给维修工程师。数据来源有三个一是设备报警日志从SCADA系统导出包含报警代码、时间、设备编号二是历史维修工单从EAM系统导出包含故障现象、维修措施、更换备件三是设备手册和故障代码表以PDF或Excel形式存在。数据准备阶段最关键的是把非结构化的维修记录变成结构化的知识。我的做法是先用大模型对历史工单进行信息抽取提取出“故障现象-可能原因-维修措施”的三元组然后人工审核一遍确保准确性。这个过程大概花了三天处理了两年约2000条工单。审核后的数据存入多维表格作为Agent的知识库。3.2 Agent执行逻辑的搭建Agent的执行逻辑分四步第一步监听设备报警事件可以通过飞书多维表格的自动化流程或者定时轮询实现第二步根据报警代码和设备编号从知识库中检索相关的历史案例第三步用大模型对检索结果进行归纳和排序生成初步诊断建议第四步通过飞书机器人推送给对应的维修工程师。这里有一个细节很重要检索策略的选择。我试过纯向量检索和关键词检索发现对于设备故障场景关键词检索的效果反而更好因为故障代码和设备型号是精确匹配的。所以最终采用的是“关键词过滤向量排序”的混合策略先用设备型号和报警代码做精确过滤缩小候选集再用向量相似度对候选集排序。代码层面核心逻辑大概长这样# 伪代码示例设备异常诊断Agent的核心逻辑 def diagnose_equipment_alarm(alarm_code, equipment_id): # 第一步从多维表格获取历史维修记录 history_records feishu_bitable.query( table_idrepair_records, filterfequipment_id{equipment_id} AND alarm_code{alarm_code} ) # 第二步从知识库检索相关故障案例 knowledge_base load_knowledge_base() candidates keyword_filter(knowledge_base, alarm_code, equipment_id) ranked vector_rank(candidates, alarm_code) # 第三步用大模型生成诊断建议 prompt build_diagnosis_prompt(alarm_code, equipment_id, ranked[:5]) diagnosis llm.generate(prompt) # 第四步推送到飞书 feishu_bot.send_message( user_idget_engineer_id(equipment_id), contentdiagnosis ) return diagnosis这个逻辑不复杂但实测下来维修工程师的接受度很高。因为他们不需要改变工作习惯只是在收到报警的时候多了一条飞书消息里面写着“根据历史记录这个报警80%是XX原因建议先检查XX”。即使Agent判断错了工程师也不会有什么损失只是忽略这条消息而已。3.3 上线后的效果与调优这个Agent上线第一个月处理了约300条报警其中维修工程师认为“有帮助”的占65%“无帮助但无害”的占30%“误导”的占5%。这个数据不算惊艳但已经足够让项目继续下去了。后续的调优主要集中在两个方面一是扩充知识库把更多设备型号和故障类型纳入进来二是优化排序算法让最可能的故障原因排在前面。我自己的体会是制造业Agent不要追求“一步到位”而是要先跑通一个最小闭环让用户用起来然后根据反馈迭代。很多项目失败不是因为技术不行而是因为一开始就想做“大而全”的平台结果半年过去了用户连个能用的功能都没见到。4. 制造业Agent落地中那些没人告诉你的坑技术方案可以抄但坑得自己踩。下面这几个坑是我和同行们用真金白银换来的教训希望能帮你少走弯路。4.1 数据权限的“隐形墙”制造业企业的数据权限管理通常很严格MES、EAM、SCADA这些系统各有各的权限体系而且往往由不同的部门管理。当你想要让Agent跨系统读取数据时第一个拦路虎就是权限。我见过一个项目Agent的开发只用了两周但申请各个系统的数据权限花了两个月而且最后还有两个系统没批下来。我的建议是在项目立项阶段就把数据权限申请作为关键路径来管理不要等到开发完了才发现数据拿不到。另外可以考虑用“数据副本”的方式绕过权限问题——让有权限的人定期导出数据到多维表格或数据仓库Agent只访问副本不直接访问源系统。这样虽然数据有延迟但至少能跑起来。4.2 大模型“幻觉”在制造业的放大效应大模型的幻觉问题在互联网场景可能只是“回答得不太准确”但在制造业场景可能会被放大成严重问题。比如Agent如果错误地建议“更换XX型号的轴承”而工程师照做了结果发现型号不对可能导致设备损坏甚至安全事故。所以制造业Agent的输出必须加“安全护栏”。我的做法是第一Agent只做“建议”不做“指令”所有输出都明确标注“仅供参考请以实际检查为准”第二对于涉及安全、涉及关键备件更换的建议必须经过人工二次确认第三在知识库中明确标注哪些信息是“已验证”的哪些是“待验证”的Agent优先引用已验证信息。4.3 一线员工的“抵触”与“过度依赖”这是一个很有意思的现象Agent上线后一线员工的态度往往两极分化。一部分人完全不用觉得“机器懂什么”另一部分人过度依赖Agent说什么就是什么自己不动脑子了。这两种态度都有问题。我的经验是在推广阶段要刻意设计“人机协作”的流程让员工感受到Agent是来帮忙的不是来替代的。比如在飞书机器人推送诊断建议时可以加一个“我认为这个建议不对”的按钮员工点击后可以填写自己的判断这些反馈会被用来优化Agent。这样既给了员工参与感又收集了宝贵的标注数据。4.4 成本控制的“隐形陷阱”大模型API的调用成本在Demo阶段几乎可以忽略不计但一旦规模化成本会迅速上升。我算过一笔账如果一个Agent每天处理1000次请求每次请求平均消耗2000个token按目前主流大模型的价格一个月的成本大概在几百到几千元不等。对于大企业来说不算什么但对于中小企业这笔钱可能就卡住了项目。控制成本的方法有几个第一能用小模型就不用大模型很多分类、检索任务用小模型就够了第二做好缓存相同或相似的请求不要重复调用大模型第三设置调用频率上限避免Agent被滥用。我见过一个项目因为没做缓存同一个报警代码被反复查询一个月烧掉了上万元。5. 从“能用”到“好用”制造业Agent的进阶方向如果你已经跑通了一个最小可行方案接下来可以考虑往哪些方向进阶我结合自己看到的案例梳理了三个方向。5.1 多Agent协作让专业的人做专业的事单个Agent的能力边界是有限的但多个Agent协作可以覆盖更复杂的场景。比如在供应链异常处理场景中可以有一个“订单Agent”负责分析订单延误风险一个“库存Agent”负责检查备件库存一个“物流Agent”负责评估运输方案三个Agent通过消息传递协作最终给出一个综合建议。这种多Agent架构在技术上已经可行比如用飞书的多维表格作为共享状态存储用CLI工具作为各Agent的执行引擎用飞书机器人作为Agent之间的通信通道。但要注意的是多Agent协作的复杂度是指数级上升的调试和排错会变得很困难。我的建议是先从两个Agent的简单协作开始跑通了再扩展。5.2 Agent记忆让经验真正沉淀下来现在的Agent大多是“无状态”的每次对话都是全新的开始。但在制造业场景很多知识是需要积累的。比如某个设备在特定工况下的故障模式可能需要多次观察才能总结出来。如果Agent能记住每次诊断的结果和实际维修情况就能不断优化自己的判断。实现Agent记忆的方式有几种一是用多维表格记录每次交互的结果作为长期记忆二是用向量数据库存储历史案例支持相似检索三是用大模型的“上下文学习”能力在每次对话中注入相关的历史信息。我目前用的是第一种和第二种的结合效果还不错。5.3 Agent评估怎么知道Agent到底好不好用Agent上线之后怎么评估它的效果不能只看“用了多少次”要看“用了之后有没有产生价值”。我通常从三个维度来评估第一准确性Agent的建议有多少被采纳、多少被证明是正确的第二效率提升Agent帮用户节省了多少时间第三用户满意度用户愿不愿意继续用。这三个维度的数据可以通过飞书多维表格来收集。比如在机器人消息里加“采纳/不采纳”按钮用户点击后自动记录在Agent处理请求时记录时间戳跟人工处理的时间对比定期发问卷收集满意度。这些数据不仅能评估Agent还能指导后续的优化方向。提示Agent评估不要追求“完美指标”制造业场景里Agent能帮用户节省10%的时间、提升5%的准确率就已经很有价值了。关键是持续迭代让价值逐步累积。6. 写在最后一些个人体会做制造业Agent这一年多我最大的体会是技术不是瓶颈场景理解才是。很多团队一上来就研究用什么框架、用什么模型却忽略了最根本的问题——这个场景里用户到底需要什么Agent到底能帮上什么忙我见过最成功的一个制造业Agent项目技术方案特别朴素就是用飞书多维表格加一个简单的脚本连大模型都没用。但它解决了一个真实的痛点车间主任每天要花半小时手动汇总各条产线的产量数据Agent自动帮他汇总并生成报表就这一个功能车间主任就愿意用而且主动帮我们推广。所以如果你正在考虑制造业Agent我的建议是先别想太大找一个具体的、高频的、数据可得性好的小场景用最简的技术方案跑通它让用户用起来然后根据反馈慢慢迭代。Agent这个东西跟制造业的很多改进一样是“干出来的”不是“想出来的”。另外关于工具选型我的个人偏好是飞书多维表格做数据层和交互层CLI工具做执行层飞书机器人做触达层。这套组合不一定是最优的但一定是最容易上手的。如果你有更好的方案欢迎交流。制造业Agent这个领域现在还在非常早期的阶段大家都是在摸索多交流、多分享才能少踩坑。