2025 Working Progress

By 2025/12/17

  • 调研完毕RoboBrain2.0，详细记录见飞书文档。部分结论如下：
    • RoboBrain2.0模型支持的 输入模态 包括 （文本类） 指令文本/scene graph+ （视觉类） 图像/多视角图像/视频；输出模态为 纯文本 ，可能是用文字描述的子任务分解结果，也可能是一串图片上的像素点；
    • RoboBrain2.0模型的 典型任务 包括：
      • 可供性预测（affordance prediction），预测图像中物体的可交互区域，输入模板"Please identify the affordance area xx"，输出图像上的bounding box坐标；
      • 空间指代（spatial referring），定位图像中的物体，输入模板 "Please point out xxx"，输出图像上的像素坐标；
      • 轨迹预测（trajectory forecasting），预测终端执行器的运动轨迹，输入模板"Please predict the key trajectory points for xxx"，输出一系列图像中的坐标点，这些坐标点连成了预测的终端执行器的运动轨迹；
      • 多智能体协作（multi-agent coordination）、场景图建构与更新（scene graph construction and updating）等；
      • 上述典型任务中，运动轨迹在图像中的定位如何与空间坐标匹配，执行器如何按照轨迹运动到指定位置，不在VLM的能力范畴内。
    • RoboBrain2.0的VLM基线为qwen2.5-VL-7B/32B，其参考推理脚本也复用了qwen的pipeline。Robobrain2.0官方似乎默认用户会同时输入文本和图像，没提供输入仅含文本的推理示例；手动修改后的text-only推理会遇到中间张量不在同一设备上的推理错误，需要指定在单卡运行；
      • 或许通过调整调用方式可解决上述问题，未细究；
    • RoboBrain2.0对工具调用（tool calling）存在不足。原生qwen2.5-VL-7B/32B未在相关数据集上训练，其官方chat template（对话模板）中没有包含工具调用的相关内容。RoboBrain2.0在训练时也未对这一部分进行补充，且沿用qwen的pipeline，为后续搭建MCP-Client造成一定困难（详细见下）。
      • 对话模板：将用户的输入和上下文、可利用的工具按照一定格式填充形成prompt，例如，填充后生成的prompt"你是一个有用的助手（system message），用户输入的文本是xx，你可以调用xx工具，xx工具的输入参数为xx"，示例。
      • qwen3-VL在训练时包含了工具调用数据，且对应的对话模板中也有工具调用相关内容；
      • 尽管在训练时未对工具调用特化训练，考虑到LLM/VLM具有一定的泛化能力，可以通过prompt以纯文本的形式描述工具与工具调用方式，可参考RoboOS的prompt模板，但是调用性能或许显著低于专项训练后的模型。
  • 阅读文档+运行参考示例，了解MCP（Model Context Protocol）：
    • MCP的作用是 联通AI应用（如Claude Desktop，AI-enhanced IDE等）和数据与工具，作用是将AI应用（N）和数据与工具（M）之间开发的成本/复杂度从"N*M"（每个AI应用需要对每个数据/工具一一适配）降低到"N+M"（对每个AI应用、数据、工具适配一次，对接到MCP中），作用可以类比模型部署中的onnx；
    • MCP是"Server-Client"架构，基本组件包括Host、Server和Client：
      • Host就是各个AI应用，如Claude Desktop，核心是其中的LLM；
      • Client是LLM侧与工具对接的接口，它负责LLM与应用的通信，并提供征询（Elicitation）用户输入、限定文件操作范围（Root）的功能；
      • Server是按照MCP包装起来，暴露特定功能的数据库/工具；
      • MCP工作的基本流程是，Client从各个Server收集可用的工具/数据（通过list_tools方法），维护一个可用工具的列表；当用户输入query后，将用户query与工具列表填充到一个template中，形成包含用户需求与可用工具描述的prompt，输入给Host（LLM），LLM将返回一段可能包含工具调用（用特殊符号/约定字符标识）的输出；Client将LLM输出文本中的调用信息（工具名、工具参数）提取出来，并与相应的Server通信，获得一段Json格式的工具响应；工具响应与之前的会话信息（用户query、LLM的第一次回答）组合在一起，作为LLM第二轮的输入，LLM将根据用户需求、自己的调用历史、工具响应进行第二轮推理，并把结果返回给用户；
      • MCP的社区生态比较丰富，官方给出了参考Client列表与现成的server，其中就有宣称可以为本地LLM包装client的工具，如mcp-use（未细看）。
  • 尝试依托本地大模型（RoboBrain2.0-7B）搭建MCP Client，但是进展不太顺利：
    • 目的是，延续使用ros-mcp-server将LLM接入ROS环境（乃至仿真场景）进行机器人控制的思路，ros-mcp-server官方repo中使用的MCP Client是Claude Desktop（严格来说，对应于MCP中的Host，它做了若干client的集成，但是我们只需要跑通其中一个，完成基本流程验证即可），它是一种基于商业闭源LLM API调用的方式，与我们未来的使用场景不匹配（本地部署开源LLM），因此需要将Claude Desktop替换为基于本地LLM的MCP Client。若完成基本流程验证，后续可将RoboBrain2.0替换为任意本地LLM/VLM。
    • 参考MCP官方Client搭建流程，将官方示例中的Anthropic API调用改为本地LLM推理，遇到 本地LLM无法调用工具 的问题，这是因为 RoboBrain2.0官方推理pipeline沿用了qwen2.5的，两者都没有考虑LLM的工具调用能力，对应的对话模板中未包括工具调用部分 。目前考虑解决问题的思路如下：
      • 最坏的情况下（即便调通client侧，还需适配ros-mcp-server，后续问题只多不少），如果后续弃用ros-mcp-server的方式，可以在机器人本地环境中直接部署LLM，并参考RoboOS的方式，以纯文本的形式将可调用的工具、工具描述（入参）预埋进prompt，和LLM约定工具调用的输出格式，并手工解析调用指令、执行命令，将执行结果返回给LLM，也可实现LLM工具调用；
      • 可参考qwen3的对话模板、github issue中网友提供的模板、博客中提供的解决思路修改并替换官方推理pipeline中的对话模板，添加工具调用功能，风险是这些模板采用jinja格式，有一定学习成本 + RoboBrain2.0未对工具调用进行训练，调用性能可能较差。
      • 除官方/huggingface推理pipeline外，有部分回答提到OpenAI的推理pipeline可以兼容其他本地LLM且具有工具调用模板，应该可以尝试。
      • 此外，一些MCP生态中的项目（如mcp-use，它宣传自己可以为本地LLM创建client）、博客（如这篇）或许也可参考。