1. 制造业 Agent 落地的真实困境1.1 为什么 Agent 在制造业总是“叫好不叫座”这两年 Agent 这个词在技术圈的热度不用我多说从大模型厂商到创业公司几乎人人都在讲 Agent 能重塑生产力。但如果你真的走进一家制造业工厂跟车间主任、工艺工程师、IT 部门的人聊一圈你会发现一个很割裂的现象Demo 演示的时候大家都很兴奋觉得这东西能省人、能提效可真到了要上线跑业务的时候几乎全部卡住。我自己参与过几个制造业的 Agent 项目踩过的坑总结下来无非这么几类。第一类是数据不通Agent 要干活就得拿到数据但制造业的数据散在 MES、ERP、WMS、SCADA 这些系统里接口老旧、字段混乱光是把数据接出来就要花掉大半预算。第二类是场景太虚很多方案商上来就讲“智能排产”“预测性维护”听起来高大上但工厂真正每天在烦的是“这批料到底到没到”“设备报警了谁去处理”“质检报告怎么快速归档”这种琐碎但高频的事。第三类是人不会用你给车间师傅一个对话框他根本不知道该问什么用两次觉得还不如打电话问调度来得快然后就再也不打开了。所以制造业 Agent 的核心矛盾不是技术不够强而是技术能力和真实业务场景之间缺了一座桥。这座桥是什么我认为是“低门槛的交互入口 高频刚需的场景 可验证的闭环”。而最近我观察到的一个很有意思的组合恰好把这三样东西凑齐了飞书 CLI 工具链 Agent 框架。1.2 飞书为什么成了制造业 Agent 的天然入口先说飞书。很多人对飞书的印象还停留在“办公聊天软件”但制造业里飞书的渗透率这两年涨得非常快尤其是那些有多个厂区、需要跨部门协作的中大型制造企业。原因很实际飞书的多维表格、机器人、审批流、文档协同几乎把工厂日常管理的场景全覆盖了。我举个真实的例子。有个做精密零部件的厂子之前车间巡检记录靠纸质表格班组长填完交到办公室办公室再录入 Excel一来一回大半天。后来他们用飞书多维表格做了个巡检模板班组长在手机上直接填数据实时汇总异常项自动推送给设备科。就这么一个改动巡检数据的时效性从“半天”变成了“实时”。关键在于飞书已经成为了工人们每天都会打开的工具。你不需要再教他们用一个新 AppAgent 只要能挂到飞书上就天然拥有了一个日活入口。这就是为什么热词里“飞书机器人发送表格”“飞书多维表格应用实例”“飞书怎么导入 agent”这些搜索量一直很高——大家都在找怎么把 Agent 塞进飞书这个壳里。1.3 CLI 工具链在制造业 Agent 里的角色再说 CLI。这个词对制造业的 IT 人员来说可能有点陌生但如果你关注 Agent 开发圈会发现 codex cli、claude cli、trae cli、deveco cli、zcode cli、minimax code cli 这些工具最近扎堆出现。CLI 在这里不是指“命令行”这么简单它代表的是一种轻量、可编排、可脚本化的 Agent 执行方式。为什么制造业需要 CLI 形态的 Agent因为工厂的 IT 环境往往很保守你不可能在每个工控机上都装一个重型客户端。但 CLI 工具可以跑在服务器上通过飞书机器人接收指令执行完再把结果推回飞书。整个链路对终端用户是透明的——工人只看到飞书里多了个机器人背后其实是 CLI Agent 在干活。热词里有个很典型的组合“windows claude code cc-connect 飞书”。这说明已经有人在尝试把 Claude Code 这类 CLI Agent 通过 cc-connect 桥接到飞书上。还有“飞书没有 cli 权限”“安装 codex cli”“unable to locate the codex cli binary”这些搜索说明实操层面坑很多但需求是真实存在的。1.4 这篇文章要解决什么问题所以回到标题的问题Agent 越来越多制造业如何“真用上”我的答案是——别追求大而全的“智能体平台”先用飞书做入口、用 CLI 做执行、用多维表格做数据底座把一两个高频场景跑通闭环。接下来我会从整体设计思路、核心细节、实操过程、常见问题四个维度把这套方案拆开讲清楚。适合两类人看一是制造业的 IT/数字化负责人想知道怎么低成本试水 Agent二是 Agent 开发者想知道怎么把技术能力落到真实工厂场景里。2. 整体方案设计与选型逻辑2.1 为什么是“飞书 CLI 多维表格”这个组合在讲具体怎么做之前我得先解释清楚为什么选这三个东西而不是别的方案。因为制造业数字化最怕的就是“选型选错推倒重来”所以每个选择背后都得有站得住脚的理由。飞书作为交互层核心优势是“已经在用”。你不需要说服老板批预算买新系统也不需要培训工人用新工具。飞书机器人、多维表格、审批流这些能力都是现成的Agent 只要对接飞书开放平台就能复用现有的组织架构和权限体系。这一点在制造业特别重要因为工厂的人员流动性大权限管理如果另起炉灶运维成本会高得离谱。CLI 作为执行层核心优势是“轻量和可编排”。相比 GUI 应用CLI 工具的资源占用小可以跑在工厂现有的服务器或边缘设备上。而且 CLI 天然适合脚本化你可以把多个 Agent 任务串成流水线比如“读取多维表格里的待处理工单 → 调用 Agent 分析 → 生成处理建议 → 写回表格 → 推送飞书通知”。这种编排能力是重型平台很难做到的。多维表格作为数据层核心优势是“结构化且易维护”。制造业的数据很多是非结构化的比如巡检记录、质检备注、设备日志。多维表格的好处是它既有数据库的结构化能力又有 Excel 的易用性。工人可以直接在表格里改数据Agent 也可以通过 API 读写。热词里“飞书多维表格应用实例”搜索量高说明已经有很多人在用这个能力做业务系统了。2.2 三种典型场景的选型对比不是所有制造业场景都适合这套方案。我整理了一个对比表帮你判断自己的场景该不该上。场景类型典型例子适合度原因高频信息流转巡检记录、工单派发、异常上报高数据结构清晰飞书原生支持Agent 只需做汇总和分发知识问答类设备手册查询、工艺参数咨询高CLI Agent 可以挂载知识库飞书机器人做问答入口跨系统数据整合从 MES 取数生成日报中需要额外开发接口但 CLI 脚本可以处理实时控制类设备启停、参数调节低安全要求高不建议 Agent 直接介入复杂决策类智能排产、供应链优化低需要大量历史数据和算法调优不适合快速试水我的建议是先从“高频信息流转”和“知识问答”这两类切入。因为它们对数据质量要求不高闭环短一两周就能看到效果。等团队对 Agent 建立信心了再往复杂场景延伸。2.3 架构分层从飞书消息到 Agent 执行再回到飞书整套方案的架构其实很简单我画不了图就用文字描述一下数据流。最上层是飞书客户端工人或管理员在飞书里发消息、填表格、点按钮。中间是飞书开放平台负责接收事件、鉴权、回调。再往下是你的 Agent 服务它监听飞书的事件推送解析出用户意图然后调用CLI Agent执行具体任务。CLI Agent 可能需要访问多维表格读写数据或者调用外部系统接口。执行完之后结果通过飞书机器人 API 推回给用户。这个架构的关键点是Agent 服务是常驻的它不需要用户主动触发而是被动监听飞书事件。比如有人在多维表格里新增了一行“设备异常”Agent 服务收到事件后自动启动分析流程几分钟后把处理建议推送到相关群组。整个过程用户无感但效率提升是实打实的。2.4 成本与门槛的真实评估我知道很多人看到“Agent”就觉得要花大钱。但这套方案的成本其实可控。硬件方面一台 4 核 8G 的云服务器就能跑起来如果工厂有现成的虚拟化环境直接开个虚拟机就行。软件方面飞书基础版免费多维表格免费版有行数限制但试水够用。CLI Agent 如果用开源方案成本主要是 API 调用费。我算过一笔账一个中等规模的工厂每天处理 500 条工单用轻量模型的话一个月 API 费用大概在几百块。真正的门槛不在钱而在人。你需要一个懂飞书开放平台的开发一个懂业务场景的 IT最好还有一个愿意配合试点的车间主管。这三个人凑齐两周就能跑出第一个闭环。3. 核心细节解析与实操要点3.1 飞书机器人接入从创建应用到接收事件飞书机器人的接入是整个链路的第一步也是最容易卡住的地方。我按实际操作顺序讲一遍。首先你需要在飞书开放平台创建一个“企业自建应用”。创建的时候有几个关键配置权限管理里要勾选“接收消息”“发送消息”“读取多维表格”“写入多维表格”这些权限。事件订阅里要配置请求地址这个地址就是你 Agent 服务的公网入口。机器人里要启用机器人能力设置好机器人名称和头像。这里有个坑飞书的事件订阅需要验证请求地址的有效性。你的服务必须在收到 challenge 请求后原样返回 challenge 值。很多新手在这里卡住因为他们的服务框架默认会包装响应。我的做法是在 Agent 服务里单独开一个路由处理飞书的验证请求不走业务逻辑。# 飞书事件验证的简化示例 from flask import Flask, request, jsonify app Flask(__name__) app.route(/feishu/event, methods[POST]) def handle_event(): data request.json # 处理 URL 验证 if data.get(type) url_verification: return jsonify({challenge: data.get(challenge)}) # 处理其他事件 return jsonify({code: 0})权限配置完之后你需要发布应用版本然后让管理员审批。审批通过后把机器人添加到相关的群组或多维表格里。这一步看起来简单但实际做的时候经常遇到“机器人收不到消息”的问题八成是权限没配对或者机器人没被添加到正确的会话里。3.2 CLI Agent 的安装与配置要点CLI Agent 的选择很多codex cli、claude cli、trae cli 这些都可以。我以 codex cli 为例讲一下安装配置的要点其他工具逻辑类似。安装 codex cli 最常见的问题是“unable to locate the codex cli binary or required runtime components”。这个报错通常是两个原因一是 Node.js 版本不对codex cli 一般需要 Node 18 以上二是环境变量没配好安装完之后 binary 不在 PATH 里。我的建议是用 nvm 管理 Node 版本安装完之后用which codex确认一下路径。配置方面核心是API Key 和模型选择。制造业场景我建议用响应速度快的轻量模型处理高频任务用能力强的模型处理复杂分析。比如工单分类用轻量模型设备故障分析用强模型。这样能在成本和效果之间找到平衡。还有一个容易被忽略的点是超时设置。CLI Agent 执行任务时如果卡住会一直占用资源。我一般会设置 30 秒超时超时后自动重试或降级处理。热词里“agent execution terminated due to error”这个搜索很多就是超时没处理好导致的。3.3 多维表格作为数据底座的设计原则多维表格用得好不好直接决定 Agent 能不能拿到干净的数据。我总结了几个设计原则。字段命名要规范。不要用“字段1”“字段2”这种默认名要用“设备编号”“异常描述”“处理状态”这种语义清晰的名称。因为 Agent 解析数据时依赖字段名命名混乱会导致解析错误。状态字段要用单选。比如“处理状态”字段选项固定为“待处理”“处理中”“已完成”“已关闭”。这样 Agent 可以精确判断当前状态也方便做筛选和统计。关联字段要建立。如果有多张表比如“设备表”和“工单表”要用关联字段把它们连起来。这样 Agent 查询工单时能直接拿到设备信息不用做二次查询。留一个“Agent 备注”字段。这个字段专门给 Agent 写分析结果用人工不要改。这样你能清楚地看到 Agent 做了什么判断方便调试和优化。3.4 消息格式与交互设计让工人愿意用Agent 再好工人不用就是白搭。所以交互设计要围绕“降低使用门槛”来做。第一机器人消息要短。工人不看长文本消息控制在三行以内关键信息加粗。比如“3 号设备温度异常建议检查冷却系统”而不是一大段分析。第二提供快捷操作。飞书机器人消息可以带按钮比如“已处理”“转派”“忽略”。工人点一下就能完成操作不用打字。第三支持自然语言查询。工人可以直接问“今天有哪些异常”Agent 解析后返回列表。这比让他们去表格里筛选要友好得多。第四推送时机要对。异常告警要实时推日报要固定时间推不要在不合适的时间打扰工人。我一般把非紧急通知集中在早上 8 点和下午 5 点推送。4. 实操过程与核心环节实现4.1 环境准备从零搭建 Agent 服务假设你现在要从零开始我按顺序列一下需要准备的东西。服务器一台能跑 Node.js 和 Python 的 Linux 服务器4 核 8G 起步。如果工厂有内网服务器更好数据不用出内网。飞书应用在飞书开放平台创建企业自建应用拿到 App ID 和 App Secret。CLI Agent选一个你熟悉的安装好并配置 API Key。多维表格创建好业务表格配置好字段和权限。代码仓库建议用 Git 管理方便版本回滚。环境准备好之后先写一个最小的飞书机器人能接收消息并回复“收到”。这一步跑通了再往上加 Agent 逻辑。4.2 打通飞书与 CLI Agent 的桥接桥接的核心是事件驱动。飞书推送事件到你的服务你的服务解析事件后调用 CLI AgentAgent 执行完把结果推回飞书。我写一个简化的流程说明。假设场景是工人在多维表格里新增一条异常记录Agent 自动分析并推送处理建议。第一步飞书推送“多维表格记录新增”事件到你的服务。事件里包含记录 ID 和表格 ID。第二步你的服务调用飞书 API 读取这条记录的详细内容。第三步把记录内容组装成 Prompt调用 CLI Agent。Prompt 大概是“以下是一条设备异常记录请分析可能的原因并给出处理建议{记录内容}”。第四步CLI Agent 返回分析结果。第五步你的服务调用飞书 API把结果写回多维表格的“Agent 备注”字段同时推送消息到相关群组。# 简化的桥接逻辑 def handle_bitable_event(event): record_id event[record_id] table_id event[table_id] # 读取记录 record feishu_api.get_record(table_id, record_id) # 调用 CLI Agent prompt f分析以下异常记录并给出建议{record} result call_cli_agent(prompt) # 写回表格 feishu_api.update_record(table_id, record_id, {Agent备注: result}) # 推送消息 feishu_api.send_message(chat_id, f异常分析完成{result})这个流程看起来简单但实际做的时候要注意幂等性。因为飞书可能会重复推送事件你的服务要能识别并跳过重复处理。我的做法是在数据库里记录已处理的事件 ID处理前先查一下。4.3 一个完整的制造业场景设备异常闭环我拿“设备异常处理”这个场景把整个闭环走一遍。触发巡检工人在飞书多维表格里新增一条记录字段包括“设备编号”“异常描述”“发现时间”“发现人”。分析Agent 服务收到事件后读取记录内容调用 CLI Agent 分析。Agent 会结合历史数据判断异常等级比如“温度偏高”可能是“一般”“冒烟”就是“紧急”。分发根据异常等级Agent 决定推送给谁。一般异常推给设备科紧急异常同时推给设备科和车间主任。处理接收人在飞书消息里点“已处理”按钮Agent 更新表格状态为“已完成”并记录处理时间。复盘每天下午 5 点Agent 汇总当天所有异常生成日报推送到管理群。这个闭环跑通之后设备异常的平均响应时间从原来的几小时缩短到几分钟。而且所有记录都在多维表格里方便后续做趋势分析。4.4 参数调优与效果验证Agent 上线之后不是一劳永逸的需要持续调优。我一般关注几个指标。准确率Agent 的分析结果有多少被人工采纳。如果准确率低于 70%说明 Prompt 或模型需要调整。响应时间从事件触发到消息推送的时间。制造业场景一般要求 1 分钟内超过这个时间工人就会觉得“还不如自己处理”。使用率有多少工人真的在用。如果使用率低要么是场景选错了要么是交互设计有问题。调优的方法主要是迭代 Prompt。我会把 Agent 判断错误的案例收集起来分析是哪里理解错了然后修改 Prompt。比如 Agent 经常把“温度偏高”判断为紧急我就在 Prompt 里明确“温度超过 80 度才算紧急”。5. 常见问题与排查技巧实录5.1 飞书机器人收不到消息怎么办这是最高频的问题。排查顺序如下。先确认机器人是否被添加到了正确的群组或表格。飞书机器人不会自动接收所有消息必须被显式添加。再确认权限是否配置完整。在飞书开放平台的“权限管理”里检查“接收消息”“读取多维表格”这些权限是否已勾选并发布。然后确认事件订阅的请求地址是否可访问。你可以在本地用 curl 测试一下看服务是否正常响应。最后看日志。飞书推送事件失败时会有错误码根据错误码查文档基本能定位问题。5.2 CLI Agent 执行失败的常见原因CLI Agent 执行失败我遇到过几种情况。API Key 过期或额度用完。这个最直接检查一下账户余额和 Key 的有效期。网络问题。如果 Agent 服务在内网可能访问不了外部 API。需要配置网络策略。Prompt 太长。有些模型对输入长度有限制超长会报错。我的做法是截断或分段处理。超时。前面提过设置合理的超时时间超时后重试或降级。依赖缺失。CLI 工具可能依赖某些系统库安装不全就会报错。看错误日志一般能定位。5.3 多维表格数据写入失败的排查数据写入失败通常是权限或字段类型的问题。权限方面确认应用有“写入多维表格”的权限并且被添加到了目标表格的协作者里。字段类型方面多维表格的字段有类型限制。比如“单选”字段只能写入预设的选项值写入其他值会失败。写入前先查一下字段的配置。还有一个坑是字段名大小写。飞书 API 对字段名是大小写敏感的写错一个字母就会失败。建议用字段 ID 而不是字段名来写入更稳定。5.4 独家避坑技巧汇总最后分享几个我从实操中总结的技巧。先跑通最小闭环再扩展。不要一上来就做复杂场景先用一个简单场景把链路跑通建立信心。日志要详细。Agent 的每一步操作都要记日志出问题时能快速定位。我一般记录事件 ID、输入、输出、耗时。做好降级方案。Agent 挂了怎么办我的做法是保留人工处理通道Agent 失败时自动通知人工介入。定期备份多维表格。虽然飞书有版本历史但定期导出备份更保险。和一线工人保持沟通。Agent 好不好用工人最有发言权。我每周都会找几个工人聊一下收集反馈。问题类型典型报错排查方向解决技巧机器人无响应无报错权限、添加状态、请求地址逐项检查看飞书后台日志CLI 执行失败execution terminatedAPI Key、网络、超时先手动跑一遍 CLI 命令表格写入失败permission denied权限、字段类型、字段名用字段 ID 写入检查选项值消息推送失败invalid chat_id群组 ID、机器人状态确认机器人还在群里这套方案我在几个工厂都跑过最深的体会是Agent 的价值不在于技术多先进而在于能不能让一线的人愿意用。飞书解决了入口问题CLI 解决了执行问题多维表格解决了数据问题三者凑在一起才让制造业 Agent 从 Demo 变成了真正能用的工具。如果你也在做类似的事建议先从一个小场景开始跑通了再复制别贪大。