简介

要基于端到端实现一个有双臂的轮足机器人， 可以基于语音控制关灯，捡东西丢垃圾桶里，把地上的东西放桌子上，叠衣服等。

曹志伟

搭建并维护 Agent-VLA-LLM 解耦协作框架，实现 VLA 服务接口、配置管理、Git 协作流程和本地联调测试。同时负责采集机器人任务数据、训练 SmolVLA 模型，并将训练好的模型接入框架，实现捡球、关灯等桌面机器人技能的可扩展部署。

第一周

week1

一、框架核心工作

本周完成了桌面端机器人 Demo 第一版的整体技术框架设计与基础代码搭建。目标是构建一个可扩展、可替换、便于多人协作开发的 Agent + VLA + LLM 解耦框架，使上层 Agent 可以根据用户自然语言输入，选择调用具身智能模型或通用大语言模型。

框架目录位于：

/home/czw1/ChenLong-Robot-Internship/agent_vla

整体架构设计如下：

用户输入
  |
  v
Agent API
  |
  +-- 机器人任务 -> VLA Service -> SmolVLA / LeRobot / 后续 Ascend NPU
  |
  +-- 通用问答 -> LLM Service -> OpenAI / Ollama / 本地大模型

本周实现了三个核心服务：

1. Agent API

   • 作为系统统一入口，接收用户输入。
   • 根据用户输入判断是机器人任务还是通用问答。
   • 将机器人任务映射为固定的 skill_id，例如 ball_pick_v1。
   • 根据路由结果调用 VLA Service 或 LLM Service。

2. VLA Service

   • 负责管理机器人技能。
   • 提供 GET /v1/skills 和 POST /v1/execute 接口。
   • 当前实现了 mock provider 和 lerobot_rollout provider。
   • 后续可以新增 ascend_vla provider，用于 Orange Pi AI Pro / Ascend NPU 推理。

3. LLM Service

   • 负责通用语言模型能力。
   • 提供 POST /v1/generate 接口。
   • 当前实现了 mock provider。
   • 后续可以扩展 OpenAI、Ollama、Qwen、本地大模型等 provider。

当前核心代码结构如下：

agent_vla/
  configs/
    app.yaml                  # 全局配置：路由规则、技能、模型路径、服务地址

  src/
    common/                   # 共享 schema、配置读取、HTTP 工具
    agent_api/                # Agent 入口、意图路由、工具调用
    vla_service/              # VLA 服务和 provider
    llm_service/              # LLM 服务和 provider

  scripts/
    run_agent_api.sh
    run_vla_service.sh
    run_llm_service.sh
    run_mock_stack_test.sh
    smoke_test.sh

  docs/
    architecture.md
    contracts.md
    development_plan.md

框架中的核心解耦点是 src/common/schemas.py。Agent、VLA、LLM 三部分统一使用这里定义的请求和响应结构，包括：

UserRequest
AgentResponse
ToolCall
VLAExecuteRequest
VLAExecuteResponse
LLMGenerateRequest
LLMGenerateResponse

通过这种方式，Agent 不需要关心 VLA 底层是 LeRobot、PyTorch、ONNX、CANN 还是 Orange Pi NPU；也不需要关心 LLM 底层是 OpenAI、Ollama 还是本地模型。只要接口协议不变，底层 provider 可以独立替换。

本周还完成了 mock 栈测试：

cd /home/czw1/ChenLong-Robot-Internship/agent_vla
bash scripts/run_mock_stack_test.sh

测试结果：

• 输入“帮我把球捡起来”可以正确路由到 robot.pick_ball，并调用 VLA Service。
• 输入 pick ball 可以正确路由到 robot.pick_ball。
• 输入“北京有什么旅游景点”可以正确路由到 llm.general_qa，并调用 LLM Service。

整体来看，第一版框架已经具备以下能力：

• Agent、VLA、LLM 三方解耦。
• 支持通过配置注册机器人技能。
• 支持通过 provider 替换 VLA 或 LLM 后端。
• 支持 dry-run，便于在不控制真实机械臂的情况下联调接口。
• 为后续 Orange Pi AI Pro / Ascend NPU 部署预留了扩展位置。

二、模型核心工作

本周完成了 LeRobot / SmolVLA 相关环境调试、硬件链路验证、数据采集参数设计和训练部署方案设计。

当前硬件与环境约定如下：

系统环境：WSL2 Ubuntu 24.04
Python 环境：conda env lerobot
机器人框架：LeRobot
具身模型：SmolVLA
从臂：SO101 follower，/dev/ttyACM0
主臂：SO101 leader，/dev/ttyACM1
摄像头：USB Camera，/dev/video0

已完成的硬件链路验证包括：

• SO101 follower 从臂可以正常连接。
• SO101 leader 主臂可以正常连接。
• 主从臂 teleoperation 可以跑通。
• USB 摄像头可以被 OpenCV 识别。
• SmolVLA 相关依赖和 GPU 训练环境可用。

摄像头调试过程中确认了一个关键参数：摄像头实际回报 FPS 为 30。如果在 LeRobot 配置中写成 fps=10，会出现校验错误：

OpenCVCamera(0) failed to set fps=10 (actual_fps=30.0)

因此后续摄像头配置统一固定为：

--robot.cameras="{ front: {type: opencv, index_or_path: 0, width: 160, height: 120, fps: 30, fourcc: MJPG} }"

这里选择 160x120 是为了保证 WSL2 + USB 摄像头 + SmolVLA 推理链路足够稳定。摄像头硬件 FPS 使用 30，而数据集保存频率使用 --dataset.fps=10，两者不是同一个参数。

第一版 SmolVLA 任务定义为：

Pick up the ball and place it in the target area.

也就是桌面静态捡球并放到目标区域。当前设计的数据集名称为：

czw1/so101_ball_pick_v1

正式采集命令设计如下：

source /home/czw1/miniforge3/etc/profile.d/conda.sh
conda activate lerobot
cd /home/czw1/lerobot

lerobot-record \
  --robot.type=so101_follower \
  --robot.port=/dev/ttyACM0 \
  --robot.id=follower \
  --robot.cameras="{ front: {type: opencv, index_or_path: 0, width: 160, height: 120, fps: 30, fourcc: MJPG} }" \
  --teleop.type=so101_leader \
  --teleop.port=/dev/ttyACM1 \
  --teleop.id=leader \
  --dataset.repo_id=czw1/so101_ball_pick_v1 \
  --dataset.single_task="Pick up the ball and place it in the target area." \
  --dataset.fps=10 \
  --dataset.episode_time_s=15 \
  --dataset.reset_time_s=8 \
  --dataset.num_episodes=60 \
  --dataset.video=true \
  --dataset.push_to_hub=false \
  --display_data=false \
  --resume=false

后续如果需要追加数据，保持同一个 dataset.repo_id，并将：

--resume=true

打开即可。

为了保证后续可迭代，本周还确定了数据集版本规则：

czw1/so101_ball_pick_v1        静态桌面捡球并放到目标区
czw1/so101_ball_pick_v2        增加球位置、光照、背景、起始姿态变化
czw1/so101_ball_handover_v1    人手递球，机械臂夹住后放置
czw1/so101_ball_roll_v1        慢速滚动球任务
czw1/so101_light_switch_v1     关灯任务

训练方面，由于当前只有一个真实摄像头，而 SmolVLA base 默认期望多个摄像头输入，因此训练时需要做两个处理：

--rename_map="{ observation.images.front: observation.images.camera1 }"
--policy.empty_cameras=2

其中 rename_map 用于把数据集中的 front 摄像头映射到 SmolVLA 期望的 camera1，empty_cameras=2 用于补齐另外两个空摄像头输入。

第一版训练命令设计如下：

source /home/czw1/miniforge3/etc/profile.d/conda.sh
conda activate lerobot
cd /home/czw1/lerobot

lerobot-train \
  --policy.path=lerobot/smolvla_base \
  --policy.repo_id=czw1/so101_ball_pick_smolvla_v1 \
  --policy.push_to_hub=false \
  --dataset.repo_id=czw1/so101_ball_pick_v1 \
  --rename_map="{ observation.images.front: observation.images.camera1 }" \
  --policy.empty_cameras=2 \
  --batch_size=1 \
  --steps=2000 \
  --save_freq=500 \
  --output_dir=outputs/train/so101_ball_pick_smolvla_v1 \
  --job_name=so101_ball_pick_smolvla_v1 \
  --policy.device=cuda \
  --wandb.enable=false

如果效果不够，继续训练到 5000 steps：

lerobot-train \
  --policy.path=lerobot/smolvla_base \
  --policy.repo_id=czw1/so101_ball_pick_smolvla_v1 \
  --policy.push_to_hub=false \
  --dataset.repo_id=czw1/so101_ball_pick_v1 \
  --rename_map="{ observation.images.front: observation.images.camera1 }" \
  --policy.empty_cameras=2 \
  --batch_size=1 \
  --steps=5000 \
  --save_freq=500 \
  --output_dir=outputs/train/so101_ball_pick_smolvla_v1 \
  --job_name=so101_ball_pick_smolvla_v1 \
  --policy.device=cuda \
  --wandb.enable=false \
  --resume=true

部署测试方案使用 lerobot-rollout。考虑到当前链路推理速度较慢，先使用低频安全测试：

lerobot-rollout \
  --robot.type=so101_follower \
  --robot.port=/dev/ttyACM0 \
  --robot.id=follower \
  --robot.cameras="{ front: {type: opencv, index_or_path: 0, width: 160, height: 120, fps: 30, fourcc: MJPG} }" \
  --policy.path=/home/czw1/lerobot/outputs/train/so101_ball_pick_smolvla_v1/checkpoints/002000/pretrained_model \
  --rename_map="{ observation.images.front: observation.images.camera1 }" \
  --task="Pick up the ball and place it in the target area." \
  --fps=1 \
  --duration=15 \
  --display_data=false \
  --return_to_initial_position=false

这一部分的核心成果是：确定了第一版 SmolVLA 模型的任务、采集参数、训练参数、继续训练方式和部署测试方式，并且将这些参数与 agent_vla 框架中的 VLA Service 对接方式统一起来。训练完成后，只需要把 checkpoint 路径写入 configs/app.yaml，即可通过 Agent 调用 VLA 模型。

此外，本周还调研了可复用的“捡物块 / pick-place”基础模型方案。选择先从捡球、捡物块这类任务入手，主要是因为 pick-place 是桌面机器人最基础、最通用的动作单元，很多后续任务都可以拆解为类似能力：

捡球 -> 抓取物体 -> 移动到目标区域 -> 放下
放到桌子上 -> 抓取物体 -> 移动到桌面指定位置 -> 放下
整理桌面 -> 多次执行 pick-place
人手递物 -> 接近物体 -> 闭合夹爪 -> 移动到目标区

当前调研结论是：第一版不直接追求大而全的多任务模型，而是先训练一个稳定的 so101_ball_pick_smolvla_v1，把它作为可复用的桌面抓取基础模型。后续如果捡球效果稳定，再把数据扩展为更通用的捡物块模型，例如：

czw1/so101_pick_object_v1

该数据集可以逐步加入：

• 球
• 方块
• 小积木
• 轻量日用品
• 不同颜色和不同材质的小物体

对应的任务描述可以统一为：

Pick up the object and place it in the target area.

这样可以把模型从“只会捡球”扩展为“能捡常见小物体”，提高后续复用价值。对于 Agent 框架来说，这类能力可以注册成一个通用 VLA 技能：

pick_object_v1:
  name: Pick up object
  task_prompt: "Pick up the object and place it in the target area."
  policy_path: /home/czw1/lerobot/outputs/train/so101_pick_object_smolvla_v1/checkpoints/...

后续 Agent 在理解用户指令时，可以把“捡球”“拿积木”“把这个东西放到目标区”等不同说法统一路由到同一个可复用的 pick_object_v1 技能，从而减少重复训练和重复开发成本。

三、下周主要工作

下周的主要目标是把当前框架从 mock 联调推进到真实模型闭环。

计划工作如下：

1. 正式采集 czw1/so101_ball_pick_v1 数据集，目标至少 60 条高质量演示。
2. 使用 SmolVLA base 训练 so101_ball_pick_smolvla_v1，先训练 2000 steps。
3. 使用 lerobot-rollout 对捡球任务进行低频部署测试，统计基础成功率。
4. 根据测试效果决定是否继续训练到 5000 steps 或补充采集数据。
5. 将训练好的 checkpoint 路径写入 agent_vla/configs/app.yaml。
6. 将 VLA Service 从 mock provider 切换为 lerobot_rollout provider。
7. 让 Agent 通过 /v1/chat 真实调用 VLA Service 执行捡球任务。
8. 接入一个真实 LLM provider，例如 OpenAI、Ollama 或本地模型，用于替换当前 mock LLM。
9. 优化 Agent 的意图识别方式，减少纯关键词匹配带来的误判。
10. 在捡球任务稳定后，规划第二个技能，例如关灯或放到桌子上。

后续长期方向是将当前 WSL2 桌面端 Demo 逐步迁移到 Orange Pi AI Pro。初期可以让 Orange Pi 只运行 Agent，VLA 推理仍调用 WSL2 服务；等 SmolVLA 到 ONNX / Ascend NPU 的部署链路验证后，再新增 ascend_vla provider，使底层推理切换到 Orange Pi AI Pro / Ascend NPU，而 Agent 层接口保持不变。

宋红

学员主页/目录。侧边栏这一节是折叠的，点击名字展开/收起下面的题目。

基本信息

题目目录

• AgentOS 编排层 — 架构设计、技术选型、开发方案
• 周报 — 每周工作汇报与下步计划

最新进展

本周（07-07 ~ 07-09）完成了项目启动阶段的全部工作：

1. 环境搭建：WSL2 Ubuntu-24.04 + venv 隔离环境，mock 栈三服务联调全通过
2. 架构调研：产出《Agentos机器人架构调研》（业界 9 项目剖析 + MCP + 小模型引擎 + 边缘部署）
3. 总体规划：产出总览四件套（项目大纲、分阶段待办、完整规划、执行约束）
4. 开发方案：方案 01（整体计划）和方案 02（编排核心增强）均通过审核，待进入 EXECUTE
5. 边界澄清：明确双下游黑盒（机械臂同学A + 底盘同学B）+ 自有路线规划模块

当前处于 第一月（mock） 阶段，方案 02 已 PASS，等待授权进入 S2-S4 编码实现。

备注

• 双轨记录（任务日志 + 任务详情）存于 D:\THU\BeiJing\嘲风\
• 开发方案与审核结果一一对应编号，归档于 开发方案\ 和 审核结果\

AgentOS 编排层

宋红 · AgentOS 编排层技术文档 代码位置：agent-llm-vla/src/agent_api/ 配套约束：D:\THU\BeiJing\嘲风\AgentOS任务约束手册.md

一、职责定位

AgentOS 编排层是“嘲风“桌面机器人的决策中枢，负责：

核心文件：

• router.py — 意图识别与工具路由（主战场）
• main.py — Agent 服务入口与编排流程
• tool_clients.py — 调用 VLA/LLM 服务的客户端

二、系统架构

                    ┌─────────────┐
                    │  用户语音/文本 │
                    └──────┬──────┘
                           │
                    ┌──────▼──────┐
                    │   ASR 模块   │  SenseVoice-Small (254MB, CER~8%)
                    │  (音频→文本)  │
                    └──────┬──────┘
                           │
                    ┌──────▼──────┐
                    │  Agent API   │  ← 我的主战场 (8010端口)
                    │  编排状态机   │
                    └──┬──────┬───┘
                       │      │
            ┌──────────▼┐    ┌▼──────────┐
            │ VLA Service│    │ LLM Service│
            │  (8011端口) │    │  (8012端口) │
            └──────┬─────┘    └───────────┘
                   │
        ┌──────────┼──────────┐
        │          │          │
   ┌────▼────┐ ┌──▼───┐ ┌───▼────┐
   │机械臂(VLA)│ │底盘(Nav)│ │视觉判定 │
   │  同学A   │ │ 同学B  │ │(YOLO等)│
   └─────────┘ └──────┘ └────────┘

三服务解耦架构（已跑通）：

• Agent API: 8010 — 编排中枢
• VLA Service: 8011 — 视觉语言动作（机械臂技能）
• LLM Service: 8012 — 大语言模型（通用问答）

三、编排状态机（方案02，已审核通过）

DISPATCH（意图识别）
    │
    ├─ 安全检查：置信度 < 0.75 → REPORT_FAIL
    │
    ▼
EXECUTE（调用执行）
    │
    ├─ dry-run 预演 → 碰撞/边界检查
    │
    ▼
JUDGE（视觉判定）
    │
    ├─ 成功 → DONE
    │
    └─ 失败 → RETRY（≤ max_retries 次）
                  │
                  └─ 超限 → REPORT_FAIL → TTS 报告

关键设计决策：

1. router 只做纯决策：(intent, ToolCall) 输出签名不变，下游零改动
2. orchestrator 管执行编排：抽成独立 orchestrator.py，main.py 保持薄
3. MockJudge 走 metadata 注入：smoke_test 可覆盖“一次过“与“失败重试“两条路径
4. Judge 契约：{success, detail, evidence}，mock 阶段 evidence 恒 {}

四、两个下游黑盒

路线规划是自有模块（route_planner）：高层路线决策归我，轮子低层电机驱动归同学B。复合任务中 orchestrator 交替调度 VLA 和底盘。

五、技术选型

六、开发阶段规划

第一月(mock)：  S1 ✅ → S2 → S3 → S4 → S5 → S6
第二月(仿真)：  S7 真实VLA仿真 → S8 本地LLM决策脑 → S9 关灯闭环
进阶：          S10 边缘部署 → S11 决策引擎Phase3 → S12 MCP/SSE/多轮
路线规划(SR)：  SR1 接口占位 → SR2 骨架 → SR3 复合任务状态机

当前进度：S1 已完成，方案02（S2-S4）已 PASS，待进入 EXECUTE。

七、约束与红线

• 不破坏三服务解耦架构
• 不破坏 schemas.py 契约（只允许向后兼容新增）
• 不改 VLA/LLM 同事的 provider 内部代码
• 不在 agent 层 import lerobot / 绑定具体大模型 SDK
• 真机动作前必须 dry-run；危险动作需安全确认
• commit/PR 只署名本人，不添加任何 AI 共同署名

详见 D:\THU\BeiJing\嘲风\AgentOS任务约束手册.md。

第 1 周（2026-07-07 ~ 2026-07-09）

宋红 · AgentOS 编排层 · 暑期实习第一周 阶段声明：第一月（mock） 详细记录：D:\THU\BeiJing\嘲风\任务日志.md + 任务详情.md

一、本周工作总览

二、关键成果

2.1 环境搭建与联调验证

• WSL2 Ubuntu-24.04 + venv 隔离环境（fastapi/uvicorn/pydantic/pyyaml）
• 三服务（Agent:8010 / VLA:8011 / LLM:8012）mock 栈联调全通过
• smoke_test 四项测试全过：
  • /health → ok
  • “帮我把球捡起来” → robot.pick_ball → ball_pick_v1（中文命中）
  • “pick ball” → 同技能（英文命中）
  • “北京有什么旅游景点” → llm.general_qa（LLM 兜底）
• 修复 WSL 挂载导致的脚本 mode 位漂移（git config core.fileMode false）

2.2 架构调研

产出《Agentos机器人架构调研》（36KB），覆盖：

• 业界 9 项目剖析（rosaOS、ROSA、ros-mcp-server、LiteVLA-Edge、OK-Robot、Octo、RAI、EMOS、Code as Policies）
• MCP 协议与动态能力发现
• 小模型决策引擎设计（Qwen2.5-1.5B/3B + Code as Policies）
• 任务编排状态机（DAG 流转：DISPATCH→EXECUTE→JUDGE→RETRY）
• 边缘硬件部署方案（昇腾310B / 进迭时空K3）

2.3 总体规划（总览四件套）

2.4 开发方案（已通过审核）

• 方案01：整体计划与开发大纲（ASR 选型、视觉判定分层、首发任务为关灯）
• 方案02：编排核心增强（S2 意图识别 + S3 反馈闭环 + S4 失败重试状态机）
  • 审核结论：PASS（可进入 EXECUTE）
  • 吸收审核02全部意见（Judge 契约补 evidence、职责切分钉死、MockJudge 不硬编码等）

2.5 边界澄清

• 明确两个隔离的下游黑盒：机械臂（同学A）+ 底盘移动（同学B）
• 路线规划是自有模块（route_planner），夹在 orchestrator 与底盘之间
• 复合任务中 orchestrator 交替调度 VLA 和底盘
• 四份总览文档全部贯通新边界

三、关键决策与取舍

四、遗留问题与待确认项

需与队友/带教对齐

可推后（不阻塞当前实现）

• 310B 推理后端选型（MindIE vs llama.cpp CPU）
• Code-as-Policies 路径 A/B
• MCP 迁移时机
• 断网降级细化策略

五、下周计划

1. 进入 EXECUTE 阶段：按方案02执行 S2→S3→S4 编码
   • S2 意图识别增强：文本归一化 + 扩充同义词 + LLM 分类兜底插槽
   • S3 反馈闭环骨架：新增 orchestrator.py，MockJudge 实现
   • S4 失败重试状态机：DISPATCH→EXECUTE→JUDGE→RETRY/REPORT
2. 每步跑 smoke_test.sh 回归验证
3. 收尾补双轨记录 + 结构化任务清单，交审核03
4. （可选）开始方案03 准备：S5 ASR + S6 视觉判定

六、产出文件清单

蒋丰泽

在 rk3588 开发板上开发轮足机器人，实现平衡控制、机械臂托举等功能。并将 Starry OS 改造成实时操作系统，移植到机器人上。

核心任务

在此项目中我负责机器人的结构选择，硬件配置，平衡控制。

选型

针对轮足机器人在市面上进行了大量调研，选型，发现在售的成熟产品不多。寻找了开源项目，成熟的路面级也很少。

努力寻找轮足机器人合适的机械结构以及相应电机，得出合适的架构有两种，一个是四电机方案，一个是六电机方案。

四电机：简单、轻量、高效率。

六电机：增加腿部自由度，提高地形适应能力和运动能力。

最后综合考虑需求暂时确定六电机结构。

准备

为轮足机器人所需要的算法和模型进行环境配置和学习，准备为轮足机器人的平衡控制进行算法控制和模型训练。配置了isaac gym环境，并学习与之相关的使用教程，和强化学习的知识。为后面机器人可能需要的建模做足了充分准备。

下周工作

等下周有了原型机器，对其进行研究算法控制，和模型训练。为其接入大脑，移植所需要的驱动等。