企业官网建设流程全解析

如果一个机器人只会按预设程序走固定路线，它算不算"会学习"？我反复想过很久这个问题，答案是它只是会执行，不是会学习。真正的学习应该是：机器人到了一个新环境，地图没画过、障碍没见过、充电桩挪了位置，它仍然能根据目标自己找到出路。而让这件事真正落地，靠的不是某一套模型，而是一整套被叫做 Agent（智能体）的架构。

这几年我陆续带过不少新人入门机器人学习和 Agent 开发，发现大多数人第一反应是去查"机器人学习 = 强化学习 = 数学推导"，然后被一堆策略梯度、贝尔曼方程劝退。实际上，等你真的开始做工程化项目就会发现，让机器人在真实环境里"学会做事"，更多依赖的是感知、记忆、规划、行动这套 Agent 架构，算法模型只是其中一个零件。这篇笔记，就是把我认为一个零基础的人最该知道的 Agent 开发思路、技术栈、学习路径和踩坑经验，从头到尾梳理一遍。

1. 机器人学习的本质：先改掉"写死逻辑"的思维惯性

1.1 预设程序不够用的四个典型场景

我刚接触机器人开发时，第一反应跟大多数人一样：把任务拆成 if-else 状态机，什么情况走什么分支，全写清楚不就行了吗？这种做法在实验室里确实能跑通很多 demo，但一旦放到真实环境，立刻会暴露问题。

举四个我真实遇到的场景。

第一个是环境变化。足球机器人比赛时，场地光照、球的位置、队友站位全在动态变化，你不可能预先穷举所有局面。哪怕你写一千个状态转移条件，总有一场比赛的瞬时状态是你没想到的。

第二个是目标变化。今天你让机器人送水，明天你想让它去关门，后天想让它帮忙拧瓶盖。每个目标都要重写一套控制逻辑，这本质上是开发成本爆炸，而不是机器人"学会"了什么。

第三个是故障自恢复。轮子打滑、机械臂撞到异物、GPS 信号丢失，预设程序遇到这类情况往往会直接卡死，因为它没有"发现异常→调整策略→重新尝试"这个闭环。

第四个是多机协作。两台机器人要一起搬一块长木板，如果各自跑各自的预设轨迹，稍微有点误差就会互相拉扯。它们需要根据对方的实时动作调整自己，这更是固定逻辑解决不了的。

你会发现，这四种场景有一个共同点：任务规则是开放的，环境反馈是实时的，而最优动作不是唯一的。预设程序解决不了这类问题，因为它的假设是"我知道所有可能的输入"。真正让机器人适应的方式，是给它一个目标、给它观察能力、给它行动能力，然后让它自己去不断试。

1.2 感知-规划-行动闭环：Agent 的基本盘

那么"自己不断试"在工程上到底长什么样？我习惯把它拆成一个最小闭环：感知、规划、行动，再加一个"反馈更新"的环节。

你可以把这个过程想成一个人第一次去陌生城市找一家火锅店。你先是看地图、看路标（感知），然后在脑子里规划一条路线（规划），接着迈开腿走（行动），走了几步发现前面修路堵住了（反馈），于是重新规划绕路（更新）。机器人学习也是这个逻辑，只不过"看路标"靠的是摄像头和激光雷达，"规划路线"靠的是算法和模型，"迈开腿"靠的是电机控制。

这个闭环在 Agent 开发里有一个更常见的叫法，叫 "行为循环"。一次完整的行为循环大概长这样：

• 传感器采集数据（图像、激光、里程计、IMU）
• 处理成当前状态描述（我在哪、周围有什么、离目标多远）
• 决策模块根据状态和目标生成行动序列（先去 A 点、再绕开障碍去 B 点）
• 控制模块把行动序列转成电机指令并执行
• 执行结果反馈回状态描述，开启下一轮循环

关键是最后一步。就是这一步让机器人有了"学习"的雏形：它不是执行完就结束，而是把执行结果带回来修正下一步判断。很多人理解的学习是"攒很多数据、训练一次模型"，但在 Agent 开发的语境下，学习更多时候体现在这个逐轮反馈修正的过程里。

1.3 机器人学习和算法模型的边界，别混为一谈

既然说到了模型，这里必须先分清一个概念：机器人学习并不等于强化学习。我见过太多初学者把这两个词划等号，其实它们的层级完全不同。

强化学习是一种训练方法，它让机器人通过大量试错和奖励信号来学到一个策略，比如学会走路、学会抓取。模仿学习是从示教数据里学，比如你手把手带着机械臂走一遍轨迹，它学你的轨迹分布。而基于大模型的学习，是让模型利用语言和视觉的共同常识来理解任务，比如你告诉它"把红色杯子放到托盘上"，它能泛化到从没见过的杯子型号。

在真实项目里，这三类方法往往不是互斥的，而是分层配合。底层电机控制如果想学出很细腻的力反馈，可以用强化学习或端到端策略；中层的导航、避障、路径规划，成熟方案是 SLAM 和规划算法；上层的任务理解、目标拆解、异常决策，如今用大模型做 Agent 编排最合适。

也就是说，"机器人如何学习"这个问题，现在最好的答案不是"找一个万能算法"，而是"设计一个架构，让不同层级各司其职地学习"。这就是 Agent 开发的起点。

2. Agent 开发的技术栈：大模型只是其中一个零件

2.1 智能体大脑的四个模块：记忆、规划、工具、反思

我在带人做 Agent 开发时，最常纠正一个认知偏差：很多人以为 Agent 就是"把 API 接给大模型，让它输出 JSON 指令"。真这么简单的话，市面上就不会有那么多机器人项目在落地时翻车了。

一个真正能跑的机器人 Agent，它的大脑至少要包含四个模块——记忆、规划、工具、反思。我一个个说。

记忆模块分为短期和长期。短期记忆是当前这一轮任务里的状态信息，比如"机器人当前位置在充电桩西南侧 3 米处，电量还剩 15%"。长期记忆是可以跨任务复用的经验，比如"每次厂房东侧通道在下午会被叉车占用，尽量避开"、"电池快没电时应该优先走直线道路而不是绕路拍照"。对机器人来说，长期记忆不一定是文本数据库，也可以是经验轨迹库、故障处理规则甚至是一个向量检索库。

规划模块负责把高层的自然语言目标拆成子目标序列。比如"去充电"可以拆成：定位自身位置→生成到充电桩的路径→绕过临时障碍→执行停靠→对齐充电接口→启动充电。这一层直接用大模型做 Chain-of-Thought 推理效果已经很好，但必须加上约束校验，否则大模型可能给出"先飞起来再去充电"这种物理上不存在的方案。

工具模块是机器人 Agent 区别于普通聊天机器人的核心。每个工具都对应机器人的一个原子能力：调 SLAM 地图接口、查询里程计、下发底盘速度指令、控制机械臂关节角度。大模型不直接动硬件，它只负责从一堆工具描述里选一个合适的并传对参数，实际执行交给工具。

反思模块是很多人忽略但极其重要的一层。每轮任务结束，Agent 要能复盘：这次行动为什么失败？是传感器误判、规划不合理，还是工具参数传错了？这个反思结果被写回记忆，下次就能避免类似错误。没有反思模块，Agent 就只能"每次都在同一个地方跌倒"。

2.2 工具调用：让模型真正"操纵"硬件

说到工具模块，我想多花点笔墨，因为这是机器人 Agent 和普通大模型应用最大的分水岭。

在纯软件 Agent 里，工具通常是搜索引擎、数据库查询、代码执行器。在机器人 Agent 里，工具变成了一系列和物理世界交互的函数。我在项目里常用的工具清单大致是这样：

• get_pose()——返回机器人在地图坐标系下的当前位姿
• get_laser_scan()——返回当前激光雷达 360 度测距数据
• navigate_to(x, y, theta)——下发目标点并调用路径规划导航过去
• detect_object(class_name)——用视觉模型检测画面里的目标物体
• set_arm_pose(joint_angles)——设置机械臂各关节目标角度
• gripper(open_close)——控制夹爪开合

每个工具在被大模型调用前，都要编写一份标准的"工具描述"，包括功能说明、参数类型、取值范围、注意事项。大模型靠的是这份描述来"理解"工具，而不是靠读你的源码。写得含糊，它就给错参数。我在 4.2 节会给出一个可直接抄的代码示例，这里先记住一个原则：工具描述的清晰度，直接决定 Agent 的可靠性。

另外要特别注意的是，工具层的实时性要求很高。大模型推理一次少说要几百毫秒，而底盘运动控制要求毫秒级响应。所以工程上一定是双层结构：上层大模型负责战略决策（决定去哪个点），下层传统控制算法负责战术执行（平滑速度、避障）。大模型下发的是一个目标点，不是一连串电机 PWM 值。

2.3 多模态感知：视觉 SLAM、语音、激光雷达的接入

感知层是机器人 Agent 的另一大技术难点。现在的趋势是把多模态信息全都接进来：摄像头图像负责物体识别和语义理解，激光雷达负责几何建图和测距，IMU 和里程计负责姿态估计，麦克风阵列负责语音交互。每一项都有成熟方案，但把它们统一成 Agent 能理解的状态描述，才是工程难点。

以视觉 SLAM 为例。它解决的核心问题是"机器人身处未知环境时，如何一边建图一边确定自己在地图中的位置"。视觉 SLAM 比激光 SLAM 更有挑战，因为图像对光照敏感、特征点容易丢失，但它的优势是能够利用语义信息，比如识别出门、走廊、货架这类地标。最近这两年的热门方向是视觉 SLAM 和语义分割结合，让地图不只有几何坐标，还能标注"哪里是货架区域""哪里是通道"。这样一来，Agent 的规划模块在思考路径时就有了语义依据，而不只是数值坐标。

多模态感知接入 Agent 时，我的做法是先把感知结果压缩成结构化文本，再喂给大模型。比如视觉模块输出"检测到前方 2.5 米处有一个红色锥桶，置信度 0.93"，激光雷达模块输出"左侧通道净宽 1.2 米，可通过"，然后让大模型基于这些文本描述做决策。这样做的好处是模型对文本的鲁棒性远高于对原始图像的鲁棒性，而且每一步决策都可以被记录、回看、审计。

3. 入门学习路线：别再一上来就啃数学推导

3.1 先过 ROS2 这关，但别陷进工具本身

我看到网上很多人在推荐 ROS2 机器人开发从入门到实践的 PDF，也都说学 ROS2 是入门机器人开发的必经之路。这个判断我基本同意，但我要补充一句：ROS2 是工具和生态，不是目的。你得用它跑通一个端到端的机器人任务，但不要花三个月去钻研它的通信中间件源码。

ROS2 里最核心要掌握的知识点，我认为就四个：

• 节点（Node）与话题（Topic）：机器人程序怎么拆分成多个独立进程，它们之间怎么通过发布/订阅传递消息
• 服务（Service）与动作（Action）：什么时候用请求/响应，什么时候用长耗时任务，以及如何抢占和取消
• TF 坐标变换：机器人底盘、雷达、机械臂末端这些坐标系怎么互相转换，这是做任何空间推理的基础
• 行为树与状态机：怎么把机器人的任务用结构化流程（比如行为树）组织起来，让决策看起来有序、可调试

这四点学扎实，你的后续开发效率会很高。我这里尤其想强调 TF 坐标变换，很多新人卡在"明明雷达检测到障碍物在左边，底盘指令却往右边避"的问题上，十有八九是 TF 没配对。

与此同时，仿真平台不要太纠结。Gazebo 适合 ROS 生态全家桶，Isaac Sim 适合做感知和强化学习仿真，也有不少人直接用自己的 2D 仿真器做导航算法验证。我个人的建议是先用 Gazebo 把基础流程跑通，因为它的学习资料最多、社区最活跃。

3.2 仿真先行，真机后上的具体策略

仿真先行这一条，我几乎是每次带新人都会强调的。原因不是仿真能替代真机，而是仿真能把"环境不可控"这个变量暂时去掉，让你专心调 Agent 的逻辑。真实机器人的传感器噪声、电池掉电、轮子打滑这些因素，往往会把一个原本清晰的 bug 搅成一团乱麻。

我在仿真里通常安排这三个阶段：

第一阶段，跑通最简单的"到达指定点"任务。用 Gazebo 搭一个空房间，让机器人从 A 点导航到 B 点，先只关注 Agent 主循环能不能正常走完"感知→规划→行动→反馈"这一圈。

第二阶段，加入动态障碍物和语义目标。在仿真场景里放几个移动障碍物，并把"检测物体类别""语义导航"这些工具接进来，让 Agent 学会根据视觉反馈动态调整路径。

第三阶段，故意注入传感器噪声和随机初始化位置，测试 Agent 的反思模块能不能识别异常并自救。这一步是仿真最值钱的地方——你可以毫无成本地让机器人在仿真里撞墙一百次、走丢一百次，把它的"抗挫折能力"练出来，再放去真机。

3.3 掌握 Agent 框架的骨架，低代码和代码框架都要看

目前入门 Agent 开发有两条路：低代码/无代码平台和代码框架。这两年扣子这类低代码平台火得很快，我身边甚至有零代码基础的硬件工程师用它搭出了完整的机器人演示流程。低代码平台的优势是托管了大模型、工具网关、记忆和编排逻辑，你只需要像拼积木一样把节点连起来。对想快速验证想法的人来说，这是性价比很高的起步方式。

但我必须提醒一句：低代码平台能让你快速理解 Agent 的工作流，却很难让你掌握 Agent 的内部原理。它把"工具描述怎么写""记忆如何检索与写入""反思怎么回写"这些关键机制都封装掉了。我的建议是，用低代码平台花一两天跑通概念，然后马上转入代码框架，比如 LangChain、Semantic Kernel，或者干脆自己实现一个轻量的 Agent 循环，才能真正掌握这门技术。

3.4 一个可以参考的 12 周学习时间表

讲完抽象路线，我直接给一个带时间节奏的入门排期。这是我带过几批新人之后总结出来的，比较适合每天能投入 2-3 小时的业余学习者。如果你是全职投入，可以把时间压一半。

这个时间表的核心思想是：先让机器人"动起来"，再让机器人"看懂世界"，最后才让 Agent "学会决策"。顺序反过来的话，你会陷入"模型调了半年，连电机的线都没接上"的尴尬。

4. 动手项目：做一个会"找充电桩"的机器人 Agent

4.1 先把业务需求拆清楚，再碰任何代码

在 Agent 开发过程中，我见过翻车最多的原因不是技术不行，而是需求没理清就动手。你问一个新人"你要做什么"，他能回答"我要做一个机器人 Agent"；但你再问"它的输入是什么、输出是什么、在什么环境里工作、有哪些边界条件"，他就开始含糊了。

所以在我动手写任何代码之前，都会强制自己先填一张需求表。以"找充电桩"这个项目为例，我是这么填的：

• 任务目标：机器人在电量低于 20% 时，自主导航到最近的可用充电桩并完成对接
• 输入：一句话任务指令"我电量低了，去充电"；以及连续传感器数据
• 输出：底盘运动指令、机械臂/对接机构的动作指令
• 工作环境：室内平坦地面，有已知地图，有 3-5 个充电桩，部分可能被占用
• 边界条件：地图上标记的充电位不会变，但充电桩前可能临时堆放杂物
• 评估标准：从收到指令到成功对接，耗时不超过 5 分钟；失败后能自主尝试其他充电桩

这张表看起来简单，但它的价值在于，它直接决定了你 Agent 的工具清单和主循环逻辑。比如"部分充电桩可能被占用"这个条件，就必须在工具里加一个"查询充电桩占用状态"的接口，而在规划模块里也要有"若目标桩被占用则切换下一个"的逻辑。这些设计决策，都是从需求表里长出来的，不是从模型里冒出来的。

4.2 把底层能力封装成 Agent 可调用的工具

需求理清之后，第二步就是把机器人的底层能力封装成工具函数。这里我给一个用 Python 写的简化示例，结构可以直接套用到你的项目里。

# agent_tools.py import json from typing import Dict class RobotTools: """封装机器人底层能力的工具集合""" def __init__(self): # 模拟底盘、雷达、充电桩状态表 self.pose = {"x": 0.0, "y": 0.0, "theta": 0.0} self.chargers = [ {"id": "C1", "pose": {"x": 5.0, "y": 3.0}, "occupied": False}, {"id": "C2", "pose": {"x": 8.0, "y": 6.0}, "occupied": True}, ] def get_pose(self) -> str: """获取机器人当前位姿""" return json.dumps(self.pose) def get_charger_status(self) -> str: """查询所有充电桩的位置和占用状态""" return json.dumps(self.chargers) def navigate_to(self, x: float, y: float) -> str: """导航到地图上的指定坐标点""" # 实际项目里这里会调用 ROS2 action client / move_base 等接口 # 这里用缩短距离模拟移动 dx = x - self.pose["x"] dy = y - self.pose["y"] print(f"[exec] 从 ({self.pose['x']:.2f}, {self.pose['y']:.2f}) 移动到 ({x:.2f}, {y:.2f})") self.pose["x"] += dx self.pose["y"] += dy return f"已到达 ({x:.2f}, {y:.2f})" def trigger_docking(self, charger_id: str) -> str: """控制对接机构与指定充电桩对接""" charger = next(c for c in self.chargers if c["id"] == charger_id) if charger["occupied"]: return "对接失败：该充电桩被占用" if abs(self.pose["x"] - charger["pose"]["x"]) > 0.2 or \ abs(self.pose["y"] - charger["pose"]["y"]) > 0.2: return f"对接失败：距离充电桩 {charger_id} 过远" print(f"[exec] 已与充电桩 {charger_id} 对接") return f"对接成功，开始充电" # 工具描述列表，Agent 模型靠这个理解每个工具的功能 def tool_schema(self) -> list: return [ { "name": "get_pose", "description": "获取机器人当前在地图上的坐标(x,y)和朝向theta，返回JSON" }, { "name": "get_charger_status", "description": "查询全部充电桩的位置和占用状态，返回JSON数组，字段包括id、pose、occupied" }, { "name": "navigate_to", "description": "导航到指定坐标点，参数x、y为地图坐标。执行成功后机器人位姿会改变", "parameters": { "type": "object", "properties": { "x": {"type": "number"}, "y": {"type": "number"} }, "required": ["x", "y"] } }, { "name": "trigger_docking", "description": "触发与指定充电桩的对接流程，参数charger_id为充电桩编号。执行前必须已经导航到充电桩附近", "parameters": { "type": "object", "properties": { "charger_id": {"type": "string"} }, "required": ["charger_id"] } } ]

注意tool_schema这个函数，它是从工具函数到 Agent 可调用格式的关键一步。每一份描述都在帮大模型回答四个问题：这个工具是干什么的？参数有哪些？参数怎么填？用之前需要什么前置条件？最后一条往往会被忽略，但像trigger_docking这类工具，如果不强调"必须先导航到附近"，大模型很可能在距离几十米的地方就去触发对接。

4.3 主循环设计：从大模型决策到数值控制

工具准备好之后，就要设计 Agent 的主循环。我用一个非常经典的循环结构，核心逻辑就是：给大模型一个目标，让它在工具列表里选择并调用，然后把执行结果带回模型，再决定下一步。

# main_loop.py import json from agent_tools import RobotTools def run_agent_loop(task_prompt: str, tools: RobotTools, max_steps: int = 10): """Agent 主循环：感知 - 决策 - 执行 - 反馈""" # 这里是真实项目里调用大模型生成请求的地方。 # 关键是把当前的系统提示、工具描述、历史对话和最新观察拼进去 messages = [ {"role": "system", "content": "你是一个机器人控制助手。你的任务是调用可用工具完成用户指令。"}, {"role": "user", "content": task_prompt} ] # 最初一轮先让模型主动调用工具，比如获取位姿和充电桩状态 messages.append({ "role": "assistant", "content": "我先查询一下当前位置和充电桩状态。", "tool_calls": [ {"name": "get_pose", "arguments": {}}, {"name": "get_charger_status", "arguments": {}} ] }) observation = json.dumps({ "pose": tools.get_pose(), "chargers": tools.get_charger_status() }) messages.append({"role": "tool", "content": observation}) for step in range(max_steps): # 实际调用大模型，返回下一步动作。简化起见，这里直接模拟一个决策逻辑 # 假设模型看到最近的可用桩是 C1，决定导航过去 action = {"name": "navigate_to", "arguments": {"x": 5.0, "y": 3.0}} print(f"\n=== step {step} ===") print(f"[model] 要调用: {action['name']} {action['arguments']}") result = execute_tool(tools, action) print(f"[exec ] 结果: {result}") messages.append({"role": "tool", "content": result}) # 模型根据结果决定下一步：触发对接 if "已到达" in result: next_action = {"name": "trigger_docking", "arguments": {"charger_id": "C1"}} print(f"[model] 要调用: {next_action['name']} {next_action['arguments']}") result = execute_tool(tools, next_action) print(f"[exec ] 结果: {result}") if "对接成功" in result: print("任务完成") break # 如果失败，需要反思为什么失败，并尝试下一个充电桩 # 现实项目里，这里需要一个反思模块记录本轮对话摘要写入长期记忆 def execute_tool(tools: RobotTools, action: dict) -> str: """根据模型返回的动作分发到对应的工具函数""" name = action["name"] args = action.get("arguments", {}) func = getattr(tools, name) return func(**args) if __name__ == "__main__": tools = RobotTools() run_agent_loop("电量不足，请尽快找到充电桩充电。", tools)

上面这个例子为了让大家看懂主循环，我把大模型决策那一层简化成了硬编码的模拟逻辑。真实项目里，你需要把messages发到大模型 API，让它根据工具描述返回tool_calls，然后执行execute_tool，再把工具结果作为新的tool消息追加到消息列表里，如此往复。这就是目前主流 Agent 框架最常见的 ReAct 模式——你要把"想哪一步、怎么想"交给模型，把"执行哪一步、怎么执行"交给工具，然后让循环把两者串起来。

还有一个工程细节值得单独说：超时和回退。真机上导航到某个点可能花了 2 分钟，如果大模型还一直等它返回，整个系统就堵死了。我的方案是给每个工具调用加一个最大执行时间，超时后返回"执行超时"，让 Agent 走反思分支——是重新规划路线，还是换一个充电桩。这个机制在仿真里看不出价值，但一上真机就会成为你的救命稻草。

4.4 实测中会遇到的真实问题：Agent 的决策和底层控制脱节

跑通上面的 demo 之后，你的 Agent 就算有雏形了。但真机实测才是真正磨人的阶段。我挑几个最常见的问题说。

第一个是坐标系不一致。仿真里导航坐标是二维地图坐标，但真机底盘的里程计原点往往是上电时刻的位置。你在地图里告诉 Agent 充电桩在 (5, 3)，但机器人自己以为自己在 (0, 0)。这件事必须在工具层做好坐标系转换，我通常的做法是在get_pose()里直接返回地图坐标系下的位姿，把 TF 转换藏在这个函数内部。否则 Agent 规划得再好，底层控制也是乱的。

第二个是工具结果过于冗长。激光雷达 360 度的原始数据直接丢给大模型，不仅浪费 token，还会拖慢决策速度。我在 2.3 节说过，感知层要做"结构化压缩"。实测下来，把原始激光数据压缩成"前方 1.2 米有障碍物、左侧通道净宽 0.8 米"这样的描述，比把原始数组丢给模型可靠得多。大模型的强项是语义推理，不是数值计算，不要让它在原始传感器数据上浪费时间。

第三个是 Agent 的"幻觉动作"。大模型可能在没有执行任何工具的情况下，直接告诉你"我已经完成充电了"。解决这个问题的办法，是在主循环里强制校验：每一步都必须先看到工具返回结果，才能进入下一步；没有工具结果就宣称成功，视为失败并触发反思。

5. 避坑经验：Agent 开发中几个典型翻车现场

5.1 模型幻觉传错参数，光靠提示词拦不住

我跟好几个团队合作时，都遇到过同样的问题：大模型偶尔会把trigger_docking的charger_id传成不存在的 "C99"。提示词里写了"只能传入充电桩状态接口返回的 id"，它有时候还是犯傻。

我的经验是，光靠提示词约束远远不够，一定要在工具执行层加一道参数校验。最简单有效的方法，就是执行函数前先检查参数是否在允许范围内。比如查一下charger_id是否存在于已知充电桩列表里，如果不存在，直接返回一个"参数错误"而不是尝试执行。这种校验逻辑要写进工具函数本身，而不是指望模型每次都对。把工具当作程序员写的函数来保护，而不是当作大模型的附属品。

另外，关于 tool_calls 里的参数类型，也要在工具描述里写非常具体。navigate_to的 x、y 是数字还是字符串？坐标原点在哪？单位是米还是厘米？这些信息不写明，模型就会默认用字符串、默认原点在原点、默认单位是像素。我甚至见过模型把坐标填成[5.0, 3.0]数组而不是x=5.0, y=3.0，就是因为描述里没说清楚。工具描述越接近 API 文档的严谨程度，模型就越少犯错。

5.2 LLM 推理时延和物理安全，必须设计两级护栏

有人问我：如果大模型决策错了，机器人会不会撞墙？答案是，如果你让大模型直接控制底层电机，它一定会撞。而且它决策一次要几百毫秒，等你反应过来去纠正，机器人早就冲出去了。

所以我在任何项目里都坚持两级控制架构。第一级是硬护栏，由底层控制器或安全传感器完成，比如激光雷达检测到前方 30 厘米内有障碍物，无论上层发什么指令，底盘立刻急停或者降速。这一级不允许大模型参与，它必须在毫秒级响应。第二级才是软决策，大模型只负责在目标层面做规划，比如决定"去 C1 充电桩"，具体怎么绕开刚出现的障碍物，交给运动规划算法。

这一点怎么强调都不为过。把物理安全寄托在一个概率模型上，是机器人 Agent 开发里最危险的错误。模型会幻觉，会迟疑，会错误理解指令，但硬件安全不能有任何赌的成分。

5.3 状态管理比模型能力更影响成功率

有一段时期我特别迷信大模型的能力，觉得只要模型够聪明，Agent 一定表现好。后来我发现，很多任务失败不是模型不会决策，而是状态管理乱了。

这个"乱"往往表现在两个方面。一个是历史消息列表无限膨胀，几轮对话之后，模型要处理几千条工具调用记录，既费 token 又把注意力稀释了。解决办法是，在每一轮任务结束时做摘要压缩，把关键状态（当前位置、剩余电量、已完成动作）固化成一条结构化的记忆，下一轮任务从这条记忆开始，而不是从头回顾所有历史。

另一个是 Agent 不知道"当前处于任务的哪一步"。比如已经导航到充电桩附近了，模型还不知道自己已经成功到达，又调用了一次navigate_to。这种情况下，我给消息列表里额外注入一个"当前状态摘要"字段，在每次工具执行后更新，让模型随时知道自己完成了什么、还没完成什么。实测下来，这个简单的状态注入能让成功率提升得非常明显。

5.4 仿真能跑，实物必翻车

仿真永远比真实环境干净。即使我前面说仿真很有价值，也必须承认，仿真里跑通的 Agent 代码搬到真机上，大概率第一次运行是失败的。我总结下来，主要差异有三个。

传感器噪声。仿真里激光雷达测距是精确的，真机则有很多毛刺、丢帧、偏差。视觉 SLAM 在仿真里很容易匹配到特征点，真机光照一变可能就跟踪丢失。

执行不确定性。仿真里navigate_to(5, 3)会精确到达，真机轮子打滑可能到不了还差 30 厘米，你的 Agent 却以为到了。这就需要在工具返回里加"实际执行结果"而不是"预期结果"，最好带上实际位姿让模型判断误差在不在可接受范围内。

环境动态性。仿真里充电桩不会被别人挪走，真机里一切都可能变。所以工具层的状态查询必须实时进行，不能相信缓存在记忆里的旧地图。

我处理这些差异的方法很朴素：上真机之前，先做一次"模拟真机"测试，也就是在仿真的基础上故意给传感器数据加噪声、给执行结果加随机误差，让 Agent 在噪声环境中能正常运行，再上真机。这个过程能过滤掉一大半问题。

5.5 怎么判断 Agent 是真的"学会"了

最后聊一个容易被忽略的问题：怎么评估一个机器人 Agent 是真的学会了，还是只会跑你安排的固定剧本？我的做法是建立一套行为测试集，里面包含 5-10 个不同难度的任务变体。

比如"找充电桩"项目，第一级测试是充电桩位置不变、无障碍，验证基础闭环。第二级测试是充电桩位置换掉，其中一个桩被占用，要看它能不能切换到第二个。第三级测试是在路线上随机放障碍，或者把一个桩在导航途中突然改成占用状态，考察它的在线重规划能力。第四级测试是给一个模糊指令，比如"我快没电了"，看它能不能把"快没电"解析成"去充电"。

每一级测试既要有成功率统计，也要记录失败时的具体表现，比如"是工具调用错了，还是反馈解读错了"。把这些失败记录回填到反思模块的规则库里，Agent 才谈得上持续改进。没有这套评估体系，你可能永远不知道自己的 Agent 是碰巧跑通了，还是真的具备了应变能力。

我个人在实际带项目的过程中最大的体会是，Agent 开发跟传统机器人开发最大的区别，不是你多会调模型，而是你多会设计"让模型和世界正确互动"的机制。感知怎么结构化、工具怎么描述、反馈怎么回写、状态怎么压缩、硬护栏怎么设，这些机制设计得好不好，直接决定一个机器人 Agent 是停留在 demo 阶段，还是真的能在现场长期稳定运行。所以如果你想入门这个方向，我的建议是：先让它动起来，再用这套循环把一个简单场景打磨到极致，再逐步扩展。这条路比一开始就追求大模型有多聪明，要稳妥得多。