AI Native 机器人开发新范式：聊天造物，打造机器人开发的 Codex

从硬件到软件，为机器人创造更简单的全链路开发基础设施

地瓜机器人起步于地平线，核心围绕旭日智能计算芯片和 RDK 机器人开发者套件展开，不做机器人本体，而是为不同形态的机器人提供计算底座和开发基础设施。现有场景从已经大规模量产的扫地机、割草机，延伸到陪伴机器人、无人机、四足机器人和人形机器人。过去一年，芯片出货量达到 600 万+，下游机器人品类 100+，生态圈开发者 10 万+。开发者本身也横跨中小学、本科、硕博、个人创客和企业团队，因此工具链既要覆盖入门，也要支持更复杂的科研和产品开发。

传统机器人开发并不是只写一段应用代码。最底层是芯片和开发板，上面是 RDK OS、ROS 2、Model Zoo 等机器人操作系统和基础软件，再往上才是目标检测、VSLAM、VLM / VLN / VLA、Locomotion 等算法与应用能力；云端还要处理数据生成、数据标注、模型训练、多模态仿真和模型量化。开发者最终面对的是一条从云到端、从模型到硬件的长链路。为此，地瓜机器人一方面通过校园与开发者计划覆盖不同阶段的人群，另一方面用以 BPU 为核心的 RDK 产品线覆盖从 5 TOPS、10 TOPS 到 560 TOPS（int8）的算力需求，对应扫地机、陪伴机器人、四足机器人、人形机器人等不同场景。

这套底座之上已经积累了大量参考应用。NodeHub 中包含人体检测、AI Stereo Occupancy、Diffusion Grasp、VSLAM、VIO 等案例，也有面向人形机器人的全身运动控制实践。这里有一个和纯软件开发不同的前提：机器人上的 AI 很多时候并不运行在云端，而是在离线板端直接执行。模型、算力、传感器和执行器绑在一起，后面的 Agent 设计自然不能只照搬云端软件 Agent。

三年多时间，AI 从聊天窗口走向自主执行

过去几年最明显的变化，不只是模型能力继续增加，而是交互方式从 Chat 逐步走向 Agent：从自然语言问答，到工具调用、任务执行，再到更长时间的自主协作。对于开发任务，这个变化尤其直观。Chat 模式里，人负责拆任务、复制上下文、逐步推进并验证结果；Agent 模式里，用户更接近只描述目标，Agent 自己读取代码库、调用终端和工具、生成代码、运行、修复，再完成验证。

开发者需要准备的“文档”也随之变化。过去的产品文档、API 文档、论坛问答和示例工程主要写给人看；Agent 更需要的是 Markdown 上下文、AGENTS.md / CLAUDE.md、Skill 与工具描述、规则文件以及可执行的验证命令。这些内容不只是解释信息，还要让 Agent 能发现能力、理解约束并真正执行。

Coding Agent 的使用率增长很快，但生成更快并不等于真实生产力一定提高。分享中的数据包括：84% 的开发者使用或计划使用 AI 工具，51% 的专业开发者每日使用 AI 工具，69% 的 Agent 用户认为生产力提高；与此同时，METR 在特定样本中观察到 -19% 的实际效率变化。对机器人开发来说，这个边界更明显：上下文、工具接入和验证闭环缺一不可，单纯换更强模型很难直接解决问题。

机器人开发为什么没有同步完成 Agent 化

软件 Agent 主要操作数字世界，机器人 Agent 则必须跨越云、PC、板端和真实物理环境。一套常见流程依然包括烧录镜像、连接设备、配置环境、编写代码、部署模型、验证功能和稳定性测试。每一步都可能对应不同工具、不同连接方式和不同权限。真正困难的不是写一段代码，而是让任务在多个环境之间连续推进，并最终得到可验证的真机结果。

从工程链路看，一个机器人应用本质上是云—PC—板端共同产出的结果。云端负责数据生成与治理、模型训练、仿真、量化和发布；PC 端承担开发环境、设备连接、文件管理、终端、VNC、部署与调试；板端负责驱动硬件、运行模型、执行任务，并把日志和状态回传。机器人动作还存在 Sim2Real 的差异：仿真中的地面、关节和受力条件相对理想，真实世界却存在摩擦、机械误差、电流控制和环境扰动，结果必须回到真机上确认。

因此，Agent 真正进入机器人开发，要先解决两个问题。第一是开发工具统一，让烧录、连接、文件、终端、IDE、VNC、监控、模型部署等能力都可以被统一调用；第二是 Agent 上下文统一，让它持续看到用户意图、设备状态、项目文件、知识与 Skill、规划过程、跨端工具调用和物理验证结果。工具统一解决“能不能调用”，上下文统一解决“能不能把事情做完”。

AI Native 解决方案

地瓜机器人的方案以 Moss AgentEngine 为中枢，把云端 RoboGo、PC 端 RDK Studio 和板端 Moss 串起来。这里之所以要做自己的 Agent Harness，不是为了重复实现一个通用 Coding Agent，而是因为机器人场景有大量通用工具不了解的状态和操作。仅设备连接就可能经过 Wi-Fi、网线、串口等不同路径，不同板卡的资源和运行条件也不一样。通用 Agent 可以写代码、写文档，但如果没有面向机器人设备和开发流程的 Harness，很难连续处理跨端状态、工具调用和真机验证。

核心任务也不是再增加一个聊天框，而是把三个环境原本割裂的工具和状态放进同一条任务链：用户给出一句话意图，Agent 规划任务，调用云端或本地能力，生成代码和配置，连接设备并部署，真机执行后回收状态与日志，根据结果继续修正，最后把可复用能力沉淀为 Skill。

PC 端的 RDK Studio 是这条链路里的主要工作台。设备发现、连接、切换、恢复，文件与代码、SSH / 串口终端、VNC，镜像烧录、应用配置、模型下发、进程运维，以及 Skill 工坊、本地模型 Ollama、板端 Agent 管理，都被放进一个环境中。GUI 仍然服务于人，但这些能力同时需要对 Agent 可调用。这样，设备接入之后，Moss 才能检查当前状态、选择工具、执行操作并返回结果，而不是让用户在多个窗口之间人工搬运信息。

Moss 更接近面向机器人开发的 Agent Harness。它同时处理 Host Code、Host Commands、Board Diagnostics 和 Board Workflows，能力矩阵分成三部分：Agent 内核负责规划、多 Agent、模型切换、长任务、记忆与恢复；机器人专属 Skill 封装软硬件知识、开发流程、设备和模型工具；物理设备验证负责代码运行、硬件反馈、日志分析、失败修复和结果确认。机器人与普通 Coding Agent 最大的差异也落在这里——它最终必须面对真实设备，部分动作还涉及物理安全。

云端的 RoboGo 则把开发机、云桌面、数据管理、标注、图像生成、训练任务、推理服务、量化工具和模型资产管理放进统一平台。云端生产模型后，可以导出 ONNX、完成量化并发布 .bin 产物，再由 Studio 承接设备连接、运行验证和调试。板端产生的日志与验证结果继续回到链路中，成为下一轮修改依据。过程中还会沉淀用户意图、模型、数据、部署产物以及执行结果，这些过程数据比单纯的对话记录更接近机器人开发本身的资产。

目标体验：一个会话，制作一个机器人应用

这套方案最终希望把“操作工具”隐藏到 Agent 后面。用户描述“让机器人识别有人跌倒，语音询问是否需要帮助，并把异常事件上传到后台”，后续选择模型或 Skill、生成应用、配置依赖、连接设备、量化部署、启动测试、分析日志、修复问题和输出验收结果，都由 Agent 沿着完整任务链推进。开发者看到的主要产物变成应用工程、设备运行状态、验证录像或日志，以及可复用的 Skill 和部署包。

几个真机案例更能说明这条链路的工作方式。板端实时检测案例中，Agent 自动连接设备、调起相机并部署 YOLO11，最终以 30 FPS 展示实时检测；NERO 机械臂案例中，任务是把 RDK X5 的盒子搬到 S600 上，执行过程用时 29.5 秒、行程 98.9 mm、力控 5.0 N；四色套环案例需要先识别红 64、黄 57、绿 50、蓝 44，再规划五步搬运顺序；在人形机器人动作编排中，涉及高风险写入时，不会直接驱动真机，而是先经过人工确认。

安全也是机器人 Agent 无法绕开的设计约束。软件 Agent 出错可能是文件、代码或服务异常，机器人执行错误则可能直接转化为物理动作。因此，板端 Agent 的权限范围需要更严格，涉及高风险执行时保留人工确认；更高权限、跨设备和系统级操作更适合放在开发者电脑或受控环境中完成。当前的目标不是让机器人在任何情况下完全自治，而是在可控边界内，把原本分散的工具、上下文和验证过程串成一条连续开发链。

从一句话做一个应用，到未来一句话创造一个机器人，中间仍然有很长的工程距离。现阶段更现实的变化，是开发者逐渐把注意力从“记住每条命令、切换每个工具”，移到“描述我要实现什么，并确认真实设备是否按预期工作”。对于 AI Native 的机器人开发，这条从意图到真机验证的闭环，才是 Agent 真正进入物理世界必须补上的部分。目前也提供客户端、Web 版和开发者交流群入口，客户端覆盖 Windows / Mac / Linux；Moss 以开源方式提供，方便开发者继续扩展机器人 Skill、设备能力和跨端流程。