PhanthyMotus从开源走向共建，具身智能开始争夺“通用底座”

范式近日正式发布 PhanthyMotus 生态社区共建计划，宣布联合优必选等十余家具身智能企业，推动这一跨平台通用具身 Agent 底座从“开源”进入“多方共建”阶段。

这件事的重点不只是又一个机器人软件框架开源，而是产业参与者开始尝试回答一个更现实的问题：未来的机器人，能不能像今天的服务器、手机和云平台一样，在硬件之外共享一套可复用的智能软件底座？

PhanthyMotus 的定位，是把不同形态、不同厂商的机器人接入同一套能够感知、记忆、推理和执行的 Agent 系统。它面向的不是某一款人形机器人，也不是只服务于某种机械臂，而是试图覆盖人形机器人、机器狗、无人机和机械臂等多种具身设备。

具身 Agent 底座，解决的不是“让机器人动起来”

具身 Agent 是能够通过传感器理解物理环境、结合记忆和任务目标进行决策，并通过机器人执行器完成动作闭环的智能体。

过去两年，机器人行业最容易展示的是“动作”，最难规模化复制的是“能力”。一台机器人可以在实验室里完成抓取、行走、递物等动作，但这些动作往往依赖人工遥操作、固定脚本，或者针对特定场景反复调参。一旦换成新的物体、新的光照、新的地面，甚至只是把任务顺序调换，系统就可能失效。

PhanthyMotus 的思路，是把机器人的智能控制从单一设备中抽离出来，形成一层相对通用的 Agent 软件。机器人负责提供摄像头、麦克风、关节、电机和执行器，底座负责理解用户意图、分析环境、规划任务，并根据设备能力调用具体动作。

这与传统机器人控制系统的差别，可以类比为“应用层”和“驱动层”的分离。传统方案经常把感知、规划、控制和硬件适配写在同一个项目里，设备换代后，软件也要重新开发；通用底座则希望把上层任务逻辑和底层硬件控制拆开，让同一个任务能够迁移到不同机器人上。

GitHub 仓库 README 显示，PhanthyMotus 采用 Agent Core 与硬件驱动相配合的运行方式。硬件通过 phanthymotus-driver 部署驱动，驱动启动后会自动向 Agent 注册，这意味着框架试图通过标准化的设备接入方式，减少上层 Agent 对具体硬件型号的依赖。

从六月开源到八月共建，变化在于参与方式

PhanthyMotus 于 2026 年 6 月首次发布并开源，官方将其定义为跨平台通用具身 Agent 框架。两个月后，范式进一步发布生态社区共建计划，说明项目目标已经从“把代码放出来”转向“让更多产业角色共同定义接口、场景和工具链”。

开源解决的是代码可见和使用门槛问题，共建解决的则是生态能否持续运转的问题。

单一公司很难独立覆盖具身智能的完整链条。模型公司擅长视觉语言模型、世界模型或大语言模型，机器人厂商掌握硬件结构和运动控制，系统集成商熟悉工厂、仓储、家庭等落地环境，科研机构则更接近算法验证和数据闭环。一个通用底座如果只有一家企业维护，最终很可能仍然变成另一套私有平台；只有硬件厂商、算法团队、应用开发者和场景方共同参与，跨平台才有机会从口号变成工程事实。

此次共建计划联合优必选等十余家具身智能企业参与，至少释放出一个清晰信号：机器人企业正在意识到，竞争焦点不只在于谁能造出一台更灵活的机器人，也在于谁能让更多机器人接入自己的软件生态。

| 阶段 | 核心目标 | 主要参与者 | 现实挑战 | |---|---|---|---| | 单机研发 | 让特定机器人完成特定任务 | 机器人本体厂商、内部算法团队 | 复用性弱，迁移成本高 | | 项目开源 | 公开框架、组件和部署方式 | 开源社区、开发者 | 代码有人用，但未必形成标准 | | 多方共建 | 共同维护接口、驱动和场景能力 | 本体厂商、模型厂商、集成商、开发者 | 版本治理、责任边界和商业利益协调 | | 生态规模化 | 形成可持续的硬件与应用网络 | 全产业链 | 数据闭环、可靠性和商业化交付 |

最大价值，是降低机器人软件的重复劳动

PhanthyMotus 最有价值的地方，在于它可能减少机器人项目中大量重复的适配工作。

今天，一个开发者想让 Agent 控制不同厂商的机器人，通常需要分别处理通信协议、传感器格式、坐标系、关节限制、动作接口和异常状态。机器人本体不同，驱动方式不同，很多原本属于“任务逻辑”的代码，最后都被迫写成设备专用逻辑。

如果底座能够把这些能力抽象成统一接口，开发者就可以把更多精力放在任务本身。例如，“把桌面上的红色杯子放到托盘里”应该主要描述目标、约束和环境反馈，而不是写死某一台机械臂的关节角度。Agent 负责把自然语言目标拆解为观察、定位、抓取、移动和放置等步骤，再由驱动层将这些步骤映射为具体设备动作。

这种抽象的难点并不在于把接口名称统一，而在于统一不同机器人的能力边界。一个人形机器人可以双臂协作，但移动速度和负载有限；机器狗擅长复杂地形移动，却可能缺少精细抓取能力；无人机拥有三维空间机动性，但无法直接完成接触式操作；机械臂重复定位精度高，却通常没有自主移动能力。

因此，真正可用的通用底座不能假设所有机器人拥有相同的动作集合，而需要具备能力发现、任务降级和执行反馈机制。Agent 首先要知道“这台设备能做什么”，再决定“这个任务能否完成”，而不是生成一个理论上正确、实际上无法执行的动作计划。

WAM、WM、VLM、LLM，如何拼成一个机器人“大脑”

PhanthyMotus 的技术路线围绕 WAM、WM、VLM 和 LLM 等模块展开，这些模块分别承担不同层次的具身智能能力。

WAM 可以理解为面向动作与执行的模型或模块，负责把高层任务转化为连续动作、运动轨迹或控制信号。它更接近机器人的“小脑”，关注的是如何稳定地移动、抓取和操作。

WM 是世界模型，负责维护机器人对环境、物体、空间关系和未来状态的内部预测。世界模型的价值不只是识别当前画面中的物体，还要判断“如果我移动这个物体，环境会发生什么变化”。对于需要多步规划的任务，这种预测能力比单纯的图像识别更重要。

VLM 是视觉语言模型，能够把图像或视频与语言指令联系起来。它可以回答“桌上有什么”“哪个物体是可抓取的”，也可以把视觉观察转化为任务规划所需的结构化信息。

LLM 是大语言模型，主要负责理解复杂指令、拆解任务、调用工具和管理多轮交互。它适合处理“先去仓库取出指定箱子，再送到会议室，并在途中避开施工区域”这类包含多个条件和步骤的任务，但它本身并不等于可靠的机器人控制器。

| 模块 | 主要职责 | 更适合解决的问题 | 不能单独解决的问题 | |---|---|---|---| | WAM | 动作生成与执行控制 | 如何走、如何抓、如何操作 | 长程任务理解和复杂语义推理 | | WM | 环境建模与结果预测 | 做出动作后环境会怎样变化 | 所有真实世界状态的准确预测 | | VLM | 视觉理解与视觉问答 | 看懂场景、定位物体和状态 | 高精度、强安全约束的底层控制 | | LLM | 指令理解与任务编排 | 如何拆解任务、管理工具调用 | 直接替代运动控制和安全系统 |

这套架构的关键，不是把几个模型简单堆在一起，而是建立清晰的闭环：模型观察环境，Agent 形成计划，硬件执行动作，传感器返回结果，系统根据反馈继续规划或进行纠错。没有反馈闭环的“机器人 Agent”，本质上仍然只是会生成动作描述的聊天机器人。

共建能否成功，取决于三个工程问题

第一，统一接口是否足够稳定，决定了 PhanthyMotus 能否真正跨平台。

具身设备的接口远比软件服务复杂。除了输入和输出格式，还涉及实时性、控制频率、坐标变换、动作中断、急停、碰撞检测和权限管理。一个语言模型可以容忍几百毫秒的响应波动，但机械臂在接触物体时，控制链路的延迟和抖动可能直接影响安全性。

如果共建计划只停留在展示层接口，开发者仍然需要为每一款机器人单独处理底层问题；如果接口覆盖到运动控制和安全策略，又会触及各家厂商的核心技术与责任边界。如何划分 Agent、驱动、控制器和安全系统的职责，将是项目能否落地的关键。

第二，真实世界数据能否形成可用闭环，决定了模型能力能否持续提升。

具身智能最缺的不是互联网文本，而是高质量的交互数据。机器人需要知道不同材质的摩擦力、物体被遮挡时如何判断位置、抓取失败后怎样调整力度，也需要记录任务失败的具体原因。仅靠仿真环境训练，很难覆盖真实场景中的光照变化、物体形变、地面摩擦和人类干预。

多方共建如果能够统一数据格式、任务描述和失败标注，就有机会把不同厂商的机器人经验沉淀为公共资产。但这也会带来数据归属、隐私、安全和商业利益分配问题。工业现场数据可能包含生产流程和客户信息，家庭场景数据则涉及更敏感的个人隐私，数据开放不可能只靠技术协议推动。

第三，开源治理是否透明，决定了开发者是否愿意长期投入。

一个真正的生态项目，需要明确核心仓库的维护者、版本发布节奏、代码合入规则、兼容性承诺和安全漏洞响应机制。对企业来说，还需要知道哪些组件可以商用、哪些模型或驱动存在授权限制，以及出现设备损坏或任务失败时由谁承担责任。

开源项目最怕“代码开放、决策封闭”。如果硬件厂商只能提交适配代码，却无法参与接口演进和路线决策，生态最终仍可能围绕单一厂商运转。反过来，如果共建缺少明确的技术负责人和版本规则，不同参与方的需求也可能让底座陷入长期分叉。

对开发者来说，现在值得关注什么

PhanthyMotus 当前最值得观察的，不是发布会上的参与企业数量，而是仓库和社区能否持续产出可验证的工程成果。

开发者首先应该关注硬件驱动是否覆盖真实设备，而不是只提供示例适配。理想状态下，同一套任务 Agent 能够在至少两种不同形态的机器人上运行，并且通过能力发现机制自动识别设备限制。

其次要看任务编排是否支持失败恢复。真实机器人任务一定会失败，杯子可能滑落，目标物可能被遮挡，路径可能被人挡住。一个成熟的具身 Agent 不应只给出一次计划，而应能根据传感器反馈重新规划、暂停、回退或请求人工介入。

再次要看是否提供可复现实验和评测指标。具身智能不能只用“能完成演示”来判断效果，至少应报告任务成功率、平均执行时间、重规划次数、人工介入率、动作延迟和跨设备迁移成本。比如，同一个任务在不同机器人上的成功率分别是多少，换硬件后需要修改多少代码，这些数据比视频展示更能说明底座的实际价值。

| 评测维度 | 建议关注的指标 | 为什么重要 | |---|---|---| | 任务能力 | 多步骤任务成功率、失败恢复率 | 判断 Agent 是否具备闭环执行能力 | | 跨平台能力 | 支持的设备类型、迁移代码量 | 判断“通用”是否只是概念 | | 实时性 | 感知延迟、规划延迟、控制频率 | 关系到动作稳定性和安全性 | | 可靠性 | 连续运行时间、异常率、人工介入率 | 判断能否从演示走向生产 | | 开发体验 | 驱动接入时间、文档完整度、调试工具 | 决定社区能否扩大 |

判断：底座之争才刚开始

PhanthyMotus 从开源走向共建，说明具身智能的竞争正在从单个模型和单台机器人，转向软件底座、硬件兼容性与开发者生态的综合竞争。

但“通用具身 Agent”是一个很高的目标。它不仅需要一个能理解语言和图像的模型，还需要稳定的设备接口、可验证的世界状态、可靠的动作控制、持续的数据闭环和清晰的安全边界。任何一环缺失，系统都可能退化为一套适配了大模型的机器人脚本。

范式选择在今年 6 月开源、在 8 月推动多方共建，节奏是合理的：先让框架接受开发者检验，再通过产业伙伴补足硬件和场景。但最终能否形成影响力，仍要看未来几个月能否公开更多驱动、评测、案例和治理细节。

对行业而言，PhanthyMotus 的意义可能不在于它马上成为所有机器人的统一操作系统，而在于它把一个长期存在却缺少共识的问题摆到台面上：机器人智能究竟应该绑定在设备厂商内部，还是以开放底座的方式成为整个产业的公共能力。

如果共建计划能够让不同厂商的机器人共享任务能力，让开发者用更低成本完成跨设备部署，那么它会成为具身智能软件基础设施的一次有价值尝试。反之，如果所谓跨平台仍然依赖大量定制适配，社区只有发布会参与、没有持续贡献，那么 PhanthyMotus 仍然只是一个开源项目，而不是生态底座。

参考来源

• PhanthyMotus GitHub 中文 README：项目定位、Agent Core 与 phanthymotus-driver 硬件驱动接入方式。
• PhanthyMotus GitHub 代码仓库：项目源代码、目录结构与社区协作入口。

本文根据 2026 年 8 月 25 日前公开信息整理。生态参与企业、技术接口和后续评测数据，以范式及项目官方发布为准。