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_id="repair_records", filter=f"equipment_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_id=get_engineer_id(equipment_id), content=diagnosis ) 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这个领域，现在还在非常早期的阶段，大家都是在摸索，多交流、多分享，才能少踩坑。
