ROSA：用自然语言查询 ROS 图，JPL 的机器人 Agent 到底能做什么

它替谁省下了翻文档的时间

ROS 系统的调试有一个固定的开场动作：先搞清楚现在到底有哪些节点在跑、它们之间通过哪些话题连着、哪些话题只在广播没人听。老手靠 rosnode list、rostopic info、rqt_graph 这套组合拳几分钟就能摸清，但前提是记得住命令名和参数。ROSA 想解决的就是这一步的翻译成本。README 给的第一个例子很能说明定位：agent.invoke("Show me a list of topics that have publishers but no subscribers")。这句话对应的不是控制指令，而是一次图结构巡检。所以它的目标用户是机器人开发者，具体来说是那些需要检查、诊断、理解并操作机器人的人，README 里用的正是 inspect、diagnose、understand、operate 这四个词。JPL 自己拿它做过 NeBula-Spot 在火星场地的演示，也有一个 TurtleSim 的 Docker 演示，README 说那个演示里 ROSA 会先推理怎么画一个五角星，再执行相应命令。这两个演示的共同点是：任务本身有明确的成功判据，而且失败代价低。

Langchain 在中间，ROS 在两端

从 README 能确认的架构信息不多，但足够画出骨架。ROSA 建立在 Langchain 之上，构造函数接收两个关键参数：ros_version 和 llm。ros_version 取 1 或 2，对应 ROS1 和 ROS2 两套不同的命令行与 API 体系；llm 由使用者自己提供，README 里写的是 get_your_llm_here()，模型配置的细节被放到了 Wiki 的 Model Configuration 页面。这个设计意味着 ROSA 本身不绑定任何一家模型供应商，代价是你必须自己把模型接上，包括密钥、端点、以及模型是否支持工具调用。数据流的方向是：自然语言进入 LLM，LLM 决定调用哪个工具，工具落到具体的 ROS 命令或 API 上，结果再回到 LLM 组织成回答。README 明确提到可以继承 ROSA 类或传入自定义参数来创建自定义 Agent，也提到可以添加工具和定制提示词，具体做法在 Custom Agents 那页 Wiki。这里有一个值得注意的取舍：把 LLM 放在决策环里，意味着每次查询都要经过一次模型推理，延迟和成本都取决于你选的模型，而不是取决于 ROS 本身。

安装只要一行，配置全在别处

README 的安装步骤只有一条命令：pip3 install jpl-rosa。包名是 jpl-rosa，导入名是 rosa，两者不一致，写脚本时容易踩。环境要求写的是 Python 3.9+ 与 ROS Noetic 或更高，徽章上标注支持 ROS1 Noetic 以及 ROS2 的 Humble、Iron、Jazzy。最小可用代码是四行：从 rosa 导入 ROSA，准备一个 llm 对象，用 ROSA(ros_version=1, llm=llm) 构造 agent，然后 agent.invoke(...) 传入自然语言字符串。真正需要花时间的部分 README 没有展开：模型怎么配、密钥放哪里、用哪个模型。这些都在 Wiki 的 Model Configuration 页面，仓库正文只给了指向。TurtleSim 演示需要本地装 Docker，具体步骤在 Wiki 的 TurtleSim Demo Guide。如果你打算把它接进自己的机器人，Custom Agents 那页是必读的，因为默认的 ROSA 实例只覆盖通用能力，机器人特有的动作需要你自己注册成工具。

模型是外部依赖，也是失败点

最明显的限制来自架构本身：ROSA 的每一次判断都要调用 LLM。README 没有给出任何离线运行方案，也没有提到本地模型之外的兜底路径，模型配置被完全交给使用者。这带来几个具体后果。第一，网络或模型服务不可用时，Agent 直接失效，而 ros2 topic list 这类命令不受影响。第二，回答的确定性取决于模型，同一个问题两次问可能得到不同措辞甚至不同结论，这在需要可复现的故障排查记录时是个麻烦。第三，工具调用的准确性由模型决定，如果模型对 ROS 概念理解不到位，它可能选错工具或拼错参数，而 ROS 侧的命令往往是有副作用的。README 里演示的任务都是查询类或仿真环境里的动作，没有展示在真实硬件上执行高风险操作的例子，这个边界应当被当作设计意图而不是疏漏。另外，ROS1 与 ROS2 通过 ros_version 参数区分，说明两套后端是分开实现的，跨版本混用的场景不在支持范围内。

和 ros2cli、rqt 的分工在哪里

最直接的替代方案不是另一个 AI Agent，而是 ROS 自带的命令行工具集：ros2 topic list、ros2 node info、rqt_graph。它们的优势是确定性、零延迟、零外部依赖，输出格式固定，可以写进脚本和 CI。ROSA 的差别在于交互方式：你不需要记住子命令和参数名，用一句中文或英文描述意图就行，而且它能把多个查询串起来回答一个复合问题。这个差别在探索阶段很值钱，在重复执行阶段就不值钱了。判断标准很简单：如果这个问题你已经知道该敲哪条命令，那就敲命令；如果这个问题需要先搞清楚图结构才能问出正确的命令，ROSA 能省下那一步。另一个方向上的替代是直接写 Python 脚本调用 rclpy 或 rospy，好处是逻辑完全可控，坏处是每换一个机器人就要重写。ROSA 的继承与自定义工具机制，本质上是想在这两者之间找一个可复用的中间层。

版本节奏与维护成本

从发布记录看，v1.0.8 在 2025 年 4 月，v1.0.9 在 2025 年 11 月，标签写的是 Hotfix: Tiktoken Deps，v1.0.10 在 2026 年 3 月。这个节奏说明项目在维护，但更新并不密集，而且中间出现过依赖层面的热修复。Tiktoken 是 tokenizer 相关的依赖，这类问题通常由上游版本变动引起，对使用者的含义是：依赖锁定需要你自己做，不能假设每次 pip3 install 都能拿到一组互相兼容的版本。ROS 侧的升级成本也要算进去，ROS2 的 Humble、Iron、Jazzy 是三个不同的发行版，徽章列出支持不等于在每个版本上都经过同等验证，切换发行版前应当先在目标环境里跑一遍 README 里的查询例子。许可证是 Apache-2.0，允许商用与修改，但具体到你在产品里的分发方式、以及是否需要保留声明文件，应当由你们自己的法务判断，这里不做法律意见。

编辑结论

ROSA 适合已经在跑 ROS1 Noetic 或 ROS2 Humble/Iron/Jazzy、并且手头有可用 LLM 接口的团队，用来做话题与节点的巡检、故障初筛和新人上手时的图结构讲解。它不适合放进对实时性有硬要求的闭环控制路径，也不适合在无法调用外部模型服务的离线现场使用。上手前先确认三件事：你的 LLM 供应商与密钥配置方式（见 Wiki 的 Model Configuration 页）、pip3 install jpl-rosa 拉到的版本是否与你正在用的 ROS 发行版匹配、以及你要执行的动作是否只是只读查询。如果只是想知道有哪些话题没有订阅者，ros2 topic list 加一行脚本就够了，不必引入一个 Agent。

官方来源

1. License: Apache-2.0
2. nasa-jpl/rosa on GitHub
3. Project website
4. README
5. Releases