如果你有一个工业级 OpenClaw
早上 8 点，产线王组长发现 A 区的料箱车又堆在一起了。这在工厂里是很常见的问题，组长已经头疼好久了……他想知道昨晚十一点以后到底发生了什么：是哪几台车、卡在哪个路口、有没有报过障、运单是从哪一步开始堆的。
这个问题不难回答，难的是它需要组长打开系统，分别调出 5、6 个界面，完成以下操作：
- 先翻运单列表按时间筛
- 再挨个点进去看执行记录
- 再切到机器人页面看当时的状态
- 再去告警记录里对时间戳
- 最后自己在脑子里把这条时间线拼出来
换做以前，王组长又要花上大半天的时间排查问题，每次排查完，一上午时间就过完了，连吃午饭的心情都没有了。直到王组长用上了 M4 AI 助手，仅仅几分钟就找到了问题的根源。
但，大模型真的可以解决所有问题吗？
很多人会说：现在大模型能力很强，每次只要问一句："昨晚 A 区为什么堆单了"，它自己就能找到答案，发给我。
但事实远非如此。大模型具备思考能力，但它无法替你完成操作。那 M4 AI 助手为什么可以直接操作下发运单呢？
我们先厘清几个概念。
大模型和 Agent 是什么关系
行业中，我们通常把 Agent 理解为大模型 + Harness。大模型不做的那部分，就是 Harness。
Harness 直译是"挽具"，就是套在马身上、让马的力气真正能拉动车的那套东西。这个比喻非常贴切。
换个更贴近现场的说法：大模型像一位见识极广、但从没进过你车间的工程师。他懂原理、会推理、表达清楚，你跟他讲什么他都能接得上。但他没有你车间的钥匙，没有系统权限，看不到实时状态，也不会自己走过去按按钮。
把这个人真正"编入岗位"所需要的一切——工牌、权限、操作规程、复核流程、出错时谁来接手——那些就是 Harness。而"这个人 + 这套岗位机制"合起来，才是 Agent。
所以分工其实很清楚。在一次任务里，大模型只负责三件事：
- 想：分析当前进度，判断下一步该干什么、为什么。
- 提：提出一个具体动作，比如"去查这个时间段的运单列表"。
- 停：判断信息够了，可以给结论了。
其余全部由 Agent 负责：
- 真正去执行那个动作——调哪个接口、参数怎么校验、超时怎么办、失败重试几次、这个操作这个人有没有权限。
- 管住上下文。每问一轮，对话记录就长一截。模型的上下文窗口有上限，超了就丢信息。Agent 得决定留什么、压缩什么。
- 管住循环，别让它跑飞。纯靠模型自己转，很容易陷在原地：同一个工具反复调、同样的想法绕不出来。Agent 必须有硬约束：最多跑多少步、连续几次重复动作就打断、总时长超了直接终止。
因此，Agent 并不是另一种大模型，也不只是一个聊天界面。大模型为 Agent 提供理解和判断能力，Agent 则为大模型补上行动所需的工具、流程与边界。
Agent 依靠"理解—行动—反馈"循环处理多步骤任务
传统软件通常等待用户完成一连串操作：找到入口、选择对象、填写信息、提交任务，再切换页面查看进度。
Agent 接收的往往是一个目标。例如："把一箱 A 物料送到 3 号工位。"
一个具备相应能力和权限的 Agent，可能按照这样的过程工作：
- 理解用户想要完成物料配送。
- 检查物料、起点或数量等信息是否完整；缺少关键信息时继续询问。
- 查询库存、机器人和调度系统的实时状态。
- 判断当前是否满足执行条件，并形成操作方案。
- 在需要时请用户确认，再向系统创建运输任务。
- 持续获取执行结果；遇到异常时分析原因，决定继续处理还是交给用户。
- 验证物料确实到达目标位置，再向用户报告最终结果。
这个过程可以概括为：理解目标 → 采取行动 → 获取反馈 → 再次判断 → 完成、继续或询问用户。
Agent 的价值正来自这个循环。它不局限于一次提问和一次回答，而是根据真实世界不断变化的状态推进任务。
Agent 能帮我们做什么
在机器人项目中，大模型（LLM）负责理解用户表达、分析信息和判断下一步，Agent 负责查询系统、调用工具并获取真实结果。两者结合后，主要可以处理三类工作。
把跨界面的追查变成一次对话
回到开头那个问题。当用户询问"昨晚 A 区为什么堆单"，LLM 会识别时间、区域和问题类型，判断还需要哪些信息；Agent 随后查询运单、机器人状态和告警记录。拿到数据后，LLM 再梳理时间线并解释原因。用户不再需要反复切换页面，也不用自己拼接分散的信息。
把分散的经验变成随时可查的知识
Agent 可以查找产品文档、版本说明和历史工单，LLM 则负责筛选相关内容、归纳重点并生成容易理解的回答。
这样可以减少对少数老员工的依赖，也能让回答带上对应的出处和版本，方便用户继续核对。
容错地理解人的表达
机器人叫 AMB-01，人会说 amb 1、amb01、AMB 1；语音输入还可能识别成"amb 一"。而工具接口要的是精确值。这件事恰好是大模型比传统规则强得多的地方。与其写一堆大小写和符号的转换规则（永远写不完），不如在会话一开始就把现场真实存在的机器人清单交给模型——"本系统内有以下机器人"。模型自己就能把 amb 1 对上 AMB-01，成功率明显更高。
Agent 好不好用，往往不取决于用了多强的模型，而取决于有没有人认真设计过信息怎么喂给它。
Agent 目前的局限性
Agent 的能力边界，由人给它接了什么决定。它只会用已经装好的工具和 skill：查得到运单，是因为有人做了运单查询接口；跑得了仿真，是因为有人把它封装成了 skill。系统里没有对应的能力，它就办不成这件事。
并且，就算工具齐了，把它稳稳地串成一次完整交付，仍然有不少活要干：选对工具、把模糊的说法落到具体对象、失败之后按策略重试或换路、拿到结果再确认目标真的达成。更现实的一层是，大模型给出的参数是一个高概率推测，当闸门用还差着可靠性，所以不可逆的操作要留给人确认，接口也得自己返回准确的错误，比如"这张运单已完成，不能取消"。到了不限制对话、而是会改变现场状态的那一步，审查会更严：操作前的审批、重复执行的幂等保护、同类操作的互斥、完整审计和随时人工接管，一样都不能少。
这些机制和对话体验没有关系，却决定了一个 Agent 能不能真的上线。
为什么工厂里的 Agent 更难做
通用 Agent 已经能写代码、查资料、整理文件，用起来相当顺手。把同一套东西搬进车间，会遇到三重额外的约束。
误操作的代价不可撤销。聊天场景里模型答错，重问一遍就行。车间里一台车动错方向，可能是一次碰撞、一次停线、一批货损。所以操作前的人工审批、重复执行的幂等保护、同类操作的互斥、完整审计和随时人工接管，一样都不能少。这些机制和对话体验没有关系，却决定了能否上线。
工业级的 Agent 得懂这个领域。通用助手能帮你写周报，但它不知道 Executing 和 Pending 差在哪，也不知道叉车与料箱车混跑时哪些告警需要立刻处理。更麻烦的是现场状态每秒都在变，几分钟前查到的机器人位置可能已经作废，判断必须基于实时数据。
权限要对得上人。谁能下发运单、谁能改调度配置、谁只能查看，这些在工业系统里本来就有明确规定。Agent 接进来之后，得沿用同一套规则，并且留下可追溯的记录。
工业级的门槛就落在这里。对话做得好只是入场券，能在真实现场安全地把任务做完，才是难的部分。
M4 第二代 Agent 即将上线
2025 年我们发布了 M4 大模型助手，已经让自然语言开始参与机器人系统的管理和控制。用户可以通过文字或语音表达需求，并将自然语言用于运单下发、机器人和运单状态查询、库存查询及问题分析等场景。
这带来了一种新的操作方式：用户不再需要把自己的目标逐项翻译成页面操作，而是可以先说明"想完成什么"，再由 AI 帮助连接目标与 M4 的实际能力。
M4 AI 助手验证了大模型与机器人业务结合的价值，也让我们进一步思考：如果 Agent 拥有更独立的产品形态、更丰富的任务方法和更完整的执行过程，它还能帮助用户完成什么？
在 M4 AI 助手的基础上，我们正在推进第二代 Agent。
新的探索将不再局限于 M4 内部的一个功能入口，而是面向机器人和复杂系统，打造更独立、更灵活的交互与执行方式。它将继续以自然语言为入口，并重点提升几个方向：
- 通过可扩展的任务方法，逐步支持更多机器人管理与现场工作。
- 更清楚地展示执行过程、所调用的能力和当前进度。
- 适应不同设备和使用场景，让用户可以更方便地与机器人系统交互。
这些方向仍在持续打磨。我们期待第二代 Agent 带来的，不只是一个更聪明的对话框，而是一种更自然、更透明，也更值得信任的人机协作方式。
