做巡检机器人这几年，我最大的感觉是：真正难的不是让机器人走起来，而是让它知道“该干什么”和“为什么要这么干”。传统的导航和视觉识别已经相当成熟，可一旦碰到没写入规则表的突发情况，机器人的决策系统就完全抓瞎。所以当智能体技术开始在业内火起来的时候，我们就在琢磨怎么把这个能力真正揉进巡检机器人的决策系统里，而不是只做一个“会说话的控制台”。这篇文章不讲玄学，只讲我们实际踩过的坑和沉淀下来的架构方案，适合正在做机器人决策系统、或者想把大模型能力落到工业现场的团队参考。
1. 为什么过去的决策系统不够用
1.1 规则和状态机的天花板
传统巡检机器人的决策逻辑大多建立在有限状态机或行为树上。状态先被定义成“待机、巡检、返航、充电、报警”等几个固定节点，再靠传感器事件触发迁移。好处是可解释、可测试，问题也很明显：规则表之外的情况一概不会处理。
我印象最深的一次是在某锂电厂区，机器人例行巡检经过一个配电柜时，摄像头被设备门把手上的反光件遮挡，画面里出现了一块高亮光斑。按当时的规则，视觉模块会把这种情况归类为“疑似异常”，机器人走到柜前、停下、拍照、上传，然后返回充电桩。可实际上柜门正常、设备正常，所谓“异常”只是光照干扰。因为状态机里没有“反光干扰”这个分支，机器人整整三天都在反复拍同一张照片，后台堆了几十条误报警记录。
这种场景不是个案。工业现场最大的特点就是“不确定性永远比规则多”。设备指示灯被纸箱挡了、仪表读数被灰尘糊住、地面出现临时围栏、通信偶尔抖动……每一样都能让规则系统陷入死循环。更麻烦的是，规则系统的维护成本完全不可控，每新增一种现场情况，都要靠工程师手工补条件，补到后来整个状态图根本不敢动。
1.2 智能体不是来抢活的，是来补位的
智能体技术和传统决策最大的区别不是“更聪明”，而是“更会组合已有能力”。它把感知结果转成机器人和模型都能理解的语义，再基于长期记忆、知识库和工具清单，生成当前情境下最合理的行动序列。简单说，传统决策是查表，智能体是现场排兵布阵。
但我要先说清楚一个观点：智能体不是来抢活儿的。它负责的是“判断和规划”，底层那些涉及安全、运动的指令仍然要交给可靠的控制系统去执行。我们后来搭的架构里，Agent只输出意图、计划和参数，真正驱动电机、急停、充电的操作还是由执行层按老规矩来。这样即使模型推理出问题了，机器人的物理行为也不会失控。
所以融合的核心不是替换，而是补位。把规则系统处理不了的“非预期情况”交给Agent，让Agent调用规则系统里的能力，同时保留原有的安全兜底。这个定位想清楚了，后面所有架构设计都会顺很多。
2. 融合架构怎么搭：三层解耦与Agent核心
2.1 决策层必须和运动控制层解耦
我们一开始也走过弯路：想让Agent直接输出速度、角度这类底层指令，想着这样反应最快。结果发现根本行不通。模型推理有几百毫秒到几秒的延迟，运动控制需要的是毫秒级响应；而且一旦模型输出一个错误速度，真机就直接冲出去了。
后面我们把系统分成感知层、决策层、执行层三层，层与层之间用消息中间件解耦。感知层负责把图像、点云、遥测数据转成结构化事件流，发给决策层；决策层运行Agent核心，输出“意图级指令”，比如“前往配电室A的3号柜”“拍摄仪表照片”“读取温度数值”；执行层有一个安全转换器，把意图翻译成具体的运动控制和传感器操作，并且强制校验限速、禁行区等硬约束。
这个设计的好处非常实际：Agent模型挂了、网络断了大不了决策层不可用，机器人会停在原地或返回安全点，但不会自己突然加速或者撞到障碍物。运动控制层的独立性就是最后一道物理保险，不能因为融合了智能体就把这道保险抽掉。
2.2 记忆库：让机器人记得一个月前的设备状态
智能体融合决策系统的时候，最容易忽略的是记忆。一开始我们的Agent是“看过就忘”的：现场识别出一个异常，能给出判断，但完全没有历史概念。结果温度读数波动时，它分不清这是刚出现的故障，还是这台设备连续一周都在缓慢升温。
后来我们给决策层加了两级记忆：
- 短期记忆：当前任务周期内的环境状态快照，比如最近10分钟的设备读数、巡检点位、已执行的子任务。
- 长期记忆：跨任务的历史巡检记录、维修工单、故障处置案例，存成可检索的向量库。
每次Agent做判断时，会先由一个“状态压缩器”从长期记忆里检索与当前实体相关的历史事件，再拼接到提示词中。比如发现某台空压机温度偏高，压缩器会立刻把过去五次巡检的温度趋势、上次维修时间、同类设备的历史阈值都拉出来，Agent就能判断是偶发波动还是持续恶化。这个能力对巡检场景极其重要，因为很多设备故障不是突变的，而是渐变的，没有历史记忆的决策系统等于瞎猜。
2.3 技能库与工具调用：别让Agent赤手空拳做决策
智能体要落地，光会“想”不行，还得会“做”。所以我们把机器人的所有原子能力封装成了技能库，每个技能都有明确的输入参数、返回结果和执行条件。比如：
| 技能名 | 输入参数 | 输出结果 | 执行条件 |
|---|---|---|---|
| navigate_to | 目标点位、容忍误差 | 到达状态、耗时 | 目标点在白名单内 |
| read_meter | 仪表编号、ROI区域 | 读数数值、置信度 | 云台在该仪表正前方 |
| capture_image | 点位、角度、分辨率 | 图像URL、拍摄时间 | 云台解锁、无夹紧风险 |
| confirm_alarm | 告警ID、复核级别 | 确认结果、置信度 | 已获取该告警原始数据 |
Agent不直接调底层接口，而是从技能库里挑选工具并填好参数，由执行层去真正执行。这种做法相当于只让Agent“指挥”，不让它“动手”，既能保证操作受控，又能让模型在有限的工具集里做选择，大幅降低乱调用API的概率。
实测下来，技能库设计的关键是参数尽量少、语义尽量直白。每个技能最好只有一个明确主目标，别搞一个“execute_inspection”这种又大又模糊的万能接口，否则Agent会把你所有的需求都往这个接口里塞，反而失去灵活性。
3. 落地实操：从传感器数据到智能决策的关键链条
3.1 环境抽象：把点云、坐标、图像翻译成Agent能读懂的文本
这是整个融合里最容易被低估的环节。大模型看不懂二进制激光帧，也看不懂原始图像矩阵，它需要的是结构化、语义化的事件描述。我们最终确定了一套环境抽象格式，核心是“实体-属性-状态-置信度”。
举个例子，视觉模块识别到配电柜的指示灯状态，输出的不是一个检测框坐标，而是一段结构化文本：
事件类型：指示灯状态识别 实体：3号配电柜_A相指示灯 属性：颜色 状态：红色常亮 置信度：0.97 识别时间：2025-03-12 10:23:41 关联点位：配电室A_3号柜这样Agent能直接读到“某个设备处于什么状态”，而不是自己去翻检测框和坐标。再配合导航模块给出的机器人位置、云台朝向、现场温度等全局信息，Agent就拥有了一个“可理解的世界”。
这个环节最容易踩的坑是：为了让描述自然，把识别结果写得太口语化，比如“这个红灯好刺眼，看起来像异常”，模型完全可能被误导。我们的经验是，环境抽象必须严格统一词表：状态只能用“正常、异常、未知、告警、待复核”几个词，禁止自由发挥；置信度低于阈值就统一标成“未知”，宁可不判断，也不能瞎判断。
3.2 任务编排：怎么把一个“巡检任务”拆成可执行的小动作
有了环境抽象，Agent的规划器就可以开始干活了。我们采用的是“总任务-子任务-动作”三级分解方式，每一步都会产出结构化的JSON计划，然后交给校验器检查。
一个典型的过程是这样的：任务管理模块下发“完成配电室A整体巡检”，规划器结合当前电量、位置、历史告警，生成类似下面的计划：
{ "task_id": "task_20250312_007", "overview": "配电室A常规巡检，重点复核3号柜指示灯异常", "subtasks": [ { "subtask_id": "st_001", "goal": "巡检3号配电柜前端面板", "actions": [ {"tool": "navigate_to", "params": {"target": "配电室A_3号柜正面", "tolerance": 0.3}}, {"tool": "capture_image", "params": {"target": "3号柜指示灯区域", "angle": 30}} ] }, { "subtask_id": "st_002", "goal": "读取3号柜温度仪表数据", "actions": [ {"tool": "adjust_ptz", "params": {"yaw": 35, "pitch": 10}}, {"tool": "read_meter", "params": {"meter_id": "TEMP-3A", "roi": "meter_area"}} ] } ] }这个计划生成后，不是直接执行的，而是先过一遍合法性检查：目标点位在不在白名单？动作顺序是否违反安全约束？有没有超出当前电量的移动路径？只有检查通过才交给执行层。如果规划器的输出不合法，我们不会直接自动修正，而是把失败原因回传给Agent，让它重新规划，同时限制重试次数最多三次，还不行就上报人工。
3.3 安全校验：给Agent系上安全带
Agent规划得再合理，也不能保证100%符合现场要求。所以我们专门加了一道“规则闸门”，所有从Agent来的动作指令必须过了闸门才能生效。规则闸门分两级：
静态规则是硬编码的，永远不允许绕过，比如最高限速、禁行区域、机械臂行程范围、急停信号优先级。这些规则由安全工程师维护，Agent没有权限修改。
动态规则是根据任务临时生成的，比如本次巡检不允许进入某设备隔离区、当前环境湿度超过阈值时禁止开启高压柜柜门等。动态规则可以由Agent提出，但必须经过人工确认后才能生效。
另外还设置了“置信度阈值”机制：如果Agent对当前情况判断的把握很低，或者任务规划涉及高风险的越权操作，系统会主动转为“人工接管模式”，把现场画面、历史数据和Agent的推理理由一起推送给后台操作员，由人来决定。这样既保留了Agent的自动化能力，又避免在关键节点上让模型独自拍板。
我特别想强调一点，安全护栏一定要做可回溯。我们的系统会把每次Agent输入的完整上下文、生成的计划、规则校验结果、最终执行结果全部记录下来。真出了问题，不是去问“模型为什么错”，而是先看日志里Agent到底收到了什么信息。很多看起来像模型犯傻的情况，其实是前一步环境抽象把数据搞错了。
4. 我们怎么调优：指标、仿真和真机迭代
4.1 评估指标：别只盯着一次通过率
智能体决策系统上线前，我们列了一套评估指标体系。最开始大家只看“任务完成率”，觉得机器能把活干完就行。后来发现这个指标太粗，很多任务是在后台人工协助下“勉强完成”的，根本不算机器人独立决策。
我们最终固定下来四个核心指标：
| 指标 | 定义 | 目标值 | 说明 |
|---|---|---|---|
| 任务完成率 | 无需人工干预完整执行成功的任务占比 | ≥90% | 反映决策链路整体可靠性 |
| 人工干预率 | 每10次巡检中人工介入的次数 | ≤1次 | 越低越好，但允许高风险场景主动上报 |
| 决策时延 | 从感知事件到输出动作计划的耗时 | ≤3秒 | 太长会导致机器人反应迟钝 |
| 误报警率 | 非真实异常被上报的比例 | ≤5% | 误报太多会导致后台“狼来了” |
每周我们都会拿上一周的真实巡检数据做一次离线回归，把传感器数据重放给Agent，对比它的输出和人工审核的结论。这个动作极其重要，它能防止Agent因为提示词微调、模型版本升级等引入“隐性回归”，也就是平时看起来正常，一到某种特殊情况就犯傻。
4.2 从仿真到真机：最小可行动闭环
我们在仿真环境里跑了将近两个月才上真机。仿真的价值在于可以快速注入各种极端场景：传感器突然断线、视觉模型把异物识别成设备、导航路径上出现临时围栏等等。Agent在仿真里犯了错不会造成损失，非常适合做压力测试。
上真机的时候，我们的策略是一个功能一个功能地开。第一周只做“点到点移动”，也就是让Agent根据任务规划导航到目标点位，不做任何设备交互；第二周才加上“拍照和读数”；第三周才开始允许Agent对疑似异常做判断和标记。每一步都设一个明确的通过标准，比如连续50次导航任务零人工干预、连续20次仪表读数识别误差小于5%，才进入下一步。
这个“最小可行动闭环”的思路让我们少走了很多弯路。如果一上来就把所有功能都打开，出了问题根本定位不到是环境抽象的问题、规划器的问题还是执行层的问题。分阶段开功能，配合日志回溯，基本上每次故障都能在两小时内锁定根因。
4.3 模型选择与推理延迟的平衡
很多团队在融合智能体时都有一个误区：参数越大越好。我们在实际项目中做的是双级模型搭配。
边缘端用小模型做实时数据抽取和短句分类，比如把抓拍到的仪表图像识别成“读数46.2摄氏度”，这个环节延迟必须控制在毫秒级，而且不依赖网络。云端/中心端再跑一个相对大的模型，负责任务规划、异常推理、历史记忆检索和方案生成。这样既保证了高频实时任务的稳定性，又让复杂决策有足够的模型能力支撑。
延迟优化上，我们用的最有效手段是上下文裁剪。刚开始我们把所有历史数据全塞进提示词，结果模型输出一个计划要五六秒，而且越往后越“糊涂”。后来改成只把状态压缩器筛选出的相关实体、最近30分钟的事件流、当前任务的技能清单放进上下文，决策时延直接降到1.8秒左右，稳定性反而提升了。
5. 常见问题与避坑实录
5.1 上下文越长，效果越差
这是我们在项目里反复踩的坑。最初为了追求“智能”，恨不得把所有环境信息都告诉Agent，结果发现只要上下文一长，模型就开始忽略早期信息，甚至把不同点位的数据搞混。
解决方式就是分层记忆加主动裁剪。系统里有一个专门的“上下文管家”，负责在每次请求前决定该带哪些内容：当前任务目标、最近状态压缩摘要、相关实体历史、可用技能清单，其他一律不放。经过这个裁剪后，Agent的决策准确率明显提升，也省了不少模型成本。
5.2 Agent偶尔犯迷糊
有一段时间，Agent经常把视觉识别里“设备检测框置信度0.52”的状态判断成“疑似异常”。查了半天原因，是环境抽象层把低置信度的识别结果仍当作有效实体输出了，模型自然就当真了。
后面我们做了两个调整：第一，置信度低于0.8的识别结果统一标注为“未知实体”，不参与异常判断；第二，Agent在生成判断时必须引用原始事件的置信度，如果引用不了，规则闸门会直接判定该结论不可信，要求重新采集数据。这套“交叉验证”机制上线后，误报警率从初期的17%降到了3%左右。
5.3 安全护栏的误报与漏报
安全护栏设计得太严，Agent想执行一个“绕路看指示灯”的正常操作都会被打回；设计得太松，又怕出现越权动作。我们最终用了白名单纯回溯的思路：高危动作必须白名单内有明确允许才放行，普通动作只做参数校验和实时限速，不做过度约束。
另一个经验是：安全日志里必须记录Agent“为什么这么做”。我们在护栏拦截时，除了记录被拒绝的指令，还会强制让Agent补一条“意图说明”，解释当前目标和行动理由。这个说明虽然不参与自动决策，但人工审核的时候非常有用，能快速判断是模型误判还是确实有个合理的非预期任务。
6. 如果重新做一遍，我会怎么改
如果让我再走一遍这个项目，第一件事肯定是把环境抽象层定义得更加严格。当初我们花了太多时间调Agent的提示词，后来才意识到很多错误根本不在模型，而在喂给模型的输入数据不够干净。传感器数据一旦转成结构化文本，就要做到字段、词表、置信度口径完全统一，这个基础不打牢，后面所有智能都是空中楼阁。
第二件事是提前做离线回放通道。我们到项目后半段才把所有历史传感器数据和操作日志录下来搭建回放系统，相当于补作业。如果一开始就做好，每次迭代模型或改提示词，都能立刻在历史数据上验证效果，而不是等在真机现场踩雷。
最后分享一个小技巧：别急着搞一个“全知全能”的Agent。先挑一个频率最高、规则最模糊、人工介入最多的巡检任务，把它做透，做到连续一个月零人工干预，再横向扩展到其他任务。智能体融合不是一步到位的，它更像一个不断训练和放权的过程。你在每个小任务里积累的提示词模板、故障案例、技能库设计，才是后面真正值钱的东西。
