[特殊字符] 具身智能Agent开发调研｜零基础超详细笔记（万字长文）

老师发了一份智能体开发调研文件，零基础看完全懵。花了一整天查资料、拆概念、整理成这份笔记。既是科普，也是自己的完整学习记录。全文包含所有细节、数据、例子、设计动机，建议收藏慢慢看。具身智能Agent开发调研｜零基础超详细笔记 - 小红书

一、核心问题：LLM会说话，但不会行动

大语言模型能理解语言、能做推理，但它没有身体、没有手、没有眼睛。你让它"把桌上的杯子拿过来"，它能写出完美步骤：先定位杯子、再规划路径、然后控制机械臂......但它一步都执行不了。

原因：它是一个孤立的"大脑"，能思考，但不能行动。

Harness 就是解决这个矛盾的关键。

Harness 是 LLM 和机器人硬件之间的中间管理层，负责组织能力、验证结果、管理记忆。

Harness 原意是"马具"------缰绳、马鞍、挽具。马本身会跑，但只有套上马具，它才能拉车、犁地、配合农夫干活。搬到 AI 上：

LLM = 一匹会跑的马（有能力，但不受控）
Harness = 马具（让能力变成可管理的行动）
机器人 = 马车/犁（物理执行端）

Harness 给 LLM 装上三样东西：

记忆：让它不忘记之前发生了什么
手脚：让它能调用工具和技能
自我评估：让它能判断自己做得好不好

为什么偏偏是现在需要 Harness？

过去两年，工程现场的痛点变了。以前大家关心"AI 答得准不准"，现在关心"AI 跨 session 记不住""AI 改完一轮没有任何客观指标说明这次比上次好"。

调研文件里那个"打开柜门找积木搭桥"的例子很说明问题。这个任务横跨好几种完全不同的能力：找积木需要视觉理解，开柜门需要和环境复杂交互，搭积木需要几何规划和精准操控。而这些能力分属 VLA、强化学习、TAMP、世界模型等不同"门派"的模型，它们各有所长，又彼此割裂------训练方式不同、输入格式不同、状态空间也不同。

能力不缺，缺的是协作。 Harness 就是那个组织协作的"工头"。

二、基础概念逐个拆

2.1 具身智能体

具身智能最朴素的定义：拥有物理身体、能通过"感知---决策---行动"闭环与环境互动的智能系统。

和纯软件智能体的根本区别：物理动作不可逆。软件里写错一行代码可以回滚，但机器人把杯子掉在地上，它不会自己飞回来。这个"不可逆性"是整个领域设计难度的根源。

具身智能体要做到四件事：

感知环境：看见物体、识别空间、理解场景
自主决策：规划任务、分析路径、动态避障
真实行动：通过执行器改变物理世界
根据反馈调整：感知结果变了，行动策略也要跟着变

此外，具身智能还面对本体异构、环境不确定、状态观测不完整和执行风险等问题。

2.2 VLA（视觉---语言---动作模型）

VLA 全称 Vision-Language-Action。你可以把它理解成：让一个模型同时做三件事------看懂画面、听懂指令、输出动作。 它不是先"理解"再"决策"最后"执行"这种串行流程，而是一个端到端的过程：输入是摄像头画面和自然语言指令，输出直接就是机器人的动作。

优势：理解开放式语言指令、在新环境里泛化。

局限：端到端生成动作的方式在长时序任务中很难保持一致性。让它做"拿起杯子"这种短动作它做得很好，但让它连续完成"打开柜门→找到积木→搭成桥"这种需要几十步衔接的任务，它容易在中途出错或迷失。

关键数据：在 LIBERO 130 个任务中训练的 Pi 0.5 模型，平均成功率高达 96%。但把这个模型部署到有目标重绑定与布局扰动的 LIBERO-Pro 环境中，成功率锐降至 50%。动作依然流畅，局部操作本身也没有明显错误，但因为目标绑定、空间关系或任务阶段判断出现偏差，整个任务仍然会失败。

这不是"模型能力不够"的问题------模型能做每个动作。问题是模型不知道在什么时候该做什么，以及在偏差出现后如何恢复。

2.3 世界模型

世界模型解决的是另一个问题：让机器人在执行动作之前，先在"脑子"里预演这个动作会引发什么后果。

打个比方：你伸手去拿一杯水的时候，不需要真的碰到杯子才知道它会不会倒------你的大脑已经在"模拟"这个动作了。世界模型就是给机器人这个能力：输入当前场景和一个候选动作，输出"如果这样做，接下来会发生什么"的预测。

两类核心功能（根据清华团队综述和 Ding 等人分类）：

理解世界：构建内部表征来理解世界的运行机制
预测未来动态：预测未来状态来支持仿真、规划和决策

具身智能中的世界模型主要落在第二类，但它会频繁借用第一类的表征学习能力。一个更收敛的定义是：世界模型是一个能把当前状态、动作和历史压缩成可预测表征，并支持未来 rollout、规划搜索或策略训练的模型。

三种角色（李飞飞和 World Labs 分类）：

渲染器：输出像素。负责生成看起来真实的画面。视频生成模型属于这一类。
模拟器：输出世界状态。负责在内部维护一个物理上合理的世界表征，包括物体的位置、速度、接触关系等。
规划器：输出动作。这是具身智能最关心的一类。模型需要判断"杯子是否要掉落""伸手是否来得及"，并输出机器人真正可以执行的抓取动作。

从渲染器到规划器，难度逐级递增。生成看起来不错的视频很容易，难的是构建一个真正对机器人有用的通用模型------它需要紧密跟随动作，还要足够准确以避免频繁幻觉。

局限：预测时域越长，误差累积越严重。所以它通常和 Harness 配合使用------Harness 负责"做不做、做几步"，世界模型负责"如果做，大概会怎样"。

2.4 边云协同

ABot-AgentOS 的一个设计要点。边端 Tiny LLM 处理每一轮交互，负责低延迟感知、指令理解、状态跟踪和常规决策；遇到复杂语义、长程规划或歧义消解时，再按需调用云端 Large LLM。

记忆也做了分离：公共环境记忆（路障、施工区域）可以在云端共享，涉及隐私的记忆（人脸、个人物品）必须保留在本地。这既保证了实时性，又保留了处理复杂问题的能力，同时兼顾隐私。

2.5 认知---物理解耦

PhyAgentOS 的核心设计原则。它把系统拆成两条独立轨道：

Track A（认知核心）：Planner 和 Critic 在这里工作。大模型不直接发命令，它发出的命令必须先经过 Critic 对照当前机器人的运行时配置文件（EMBODIED.md）验证，通过后才能提交。
Track B（物理执行）：一个独立的硬件看门狗（hal_watchdog.py）监听并执行经过验证的命令。

这两条轨道之间通过一个叫 "State-as-a-File" 的协议通信。

2.6 State-as-a-File

PhyAgentOS 中软件和硬件之间的通信机制。软件和硬件作为独立的守护进程，通过读写本地 Markdown 文件（比如 ENVIRONMENT.md、ACTION.md）来交换状态。

之所以用文件而不是消息队列或 RPC，是因为它保证了极端透明。任何时刻你打开那些 Markdown 文件，就能看到机器人当前的环境状态和待执行动作，不需要去解析二进制协议或调试分布式系统。这种透明性也让它能做到"零代码跨硬件迁移"：换一台机器人，只需要换掉 Track B 的实现和对应的配置文件，Track A 完全不用动。

三、通用五组件（重点框架）

从 PhyAgentOS 和 ABot-AgentOS 中抽象出五个通用组件，它们回答同一个问题：如何让一个会说人话的大模型，可靠地驱动一个物理身体去完成复杂任务。

组件	职责	一句话
Planner	任务理解、分解、高层决策	决定"做什么"
Skills	封装导航、抓取、VLA 等能力	被调用的能力单元
Runtime/Abstraction	Skill 和硬件之间的隔离层	让高层不依赖具体硬件
Verifier	Plan → Execute → Observe → Verify → Replan	闭环的关键
Memory/Evolution	积累历史环境、执行结果和失败经验	让系统持续进化

Planner

LLM/VLM 不直接控制电机，而是做任务理解、分解和高层决策。ABot 明确是 Main LLM 做 scene-conditioned planning；PhyAgentOS 也是 AgentLoop + Planner。Planner 决定"调用哪个能力"，而不是生成每一个底层动作。

Skills

把导航、抓取、视觉、VLA 等能力封装成可调用的 Skill。Planner 只决定"调用哪个能力"，而不是生成每一个底层动作。英伟达的 ASPIRE 技能库是一个典型：它把机器人的一次次失败和修复，沉淀成之后能继续调用的经验。当机器人完成第 100 个任务时，它终于不再像完成第 1 个任务时那样一无所知。

Runtime / Abstraction

Skill 和具体机器人硬件之间再隔一层执行层，让高层 Agent 尽量不依赖某一种机器人。PhyAgentOS 在这方面做得特别明确：它用"State-as-a-File"协议，软件和硬件通过读写本地 Markdown 文件来通信，实现了认知和执行的完全解耦。Forge Gateway 把执行入口统一成一个契约，Agent 只需要知道"调用哪个 Skill、传入什么参数"，不需要知道底层是 Franka 机械臂还是松灵双臂。

Verifier / Closed Loop

实现闭环------不是 Plan → Execute → 完事，而是 Plan → Execute → Observe → Verify → Replan。ABot 用 Verifier，PhyAgentOS 用 SessionVerifier。它相当于给执行结果加一个"裁判"，不仅判断成功与否，还用初始任务定义和环境快照进行语义验收。

物理世界的执行结果不是"成功/失败"二元的。机器人执行了"抓取杯子"这个动作，动作本身成功了（机械臂闭合了），但如果杯子从手中滑落，Verifier 会判定为失败------因为它检查的是"杯子是否真的被拿起来了"这个用户可见的目标。

执行失败后的自我纠正，会被沉淀为技能进入记忆库，补上了自进化所缺失的反馈闭环。

Memory / Evolution

把历史环境、执行结果和失败经验重新注入 Agent。ABot 更强调长期多模态 Graph Memory；PhyAgentOS 更强调 verified experience、Lessons 和 Skill evolution。

四、十个项目深度解析

4.1 PhyAgentOS （单机完整闭环）

定位与核心问题

当前具身智能领域有三条技术路线并行------VLA 模型、World Model、Code as Policies。这三者在感知、规划和控制上各有所长，但各自解决的是局部问题，缺少一个统一的运行体系来回答"何时调用、谁来执行、如何验收、失败后如何继续"。PhyAgentOS 的定位不是"第四个模型"，而是在三个范式之下的操作系统层 。核心设计原则是 Cognitive-Physical Decoupling（认知---物理解耦）。

Track A / Track B 双轨设计

Track A（认知核心）：Planner 负责将用户指令分解为子任务并规划 Tool 调用序列；Critic 负责对照当前机器人的运行时配置文件验证每个命令是否可执行。大模型不直接发命令，必须经过 Critic 验证。
Track B（物理执行）：硬件看门狗（hal_watchdog.py）监听并执行经过验证的命令。它不关心命令是怎么来的，只关心"这个命令在当前硬件上能不能执行"。

两条轨道通过 "State-as-a-File" 协议通信。软件和硬件作为独立的守护进程，通过读写本地 Markdown 文件（如 ENVIRONMENT.md、ACTION.md）来交换状态。之所以用文件而不是消息队列或 RPC，是因为它保证了极端透明------任何时刻打开 Markdown 文件，就能看到机器人当前的环境状态和待执行动作。

Session-Centered Runtime

PhyAgentOS 不把单次动作当作调度单元，而是把整个会话（Session）当作最小调度单元。当你告诉机器人"把桌上的杯子拿过来"，系统不会只记录"抓取"这个动作的成功/失败，而是会追踪整个会话的完整链路：环境初始状态、Planner 做了什么规划、每个 Tool 调用的前后状态、Verifier 的判定结果、失败后的恢复策略。整个链路的状态被持久化在 SQLite 中，崩溃也不会丢失。如果同一个任务再次执行，系统可以检索到上一次会话的完整经验------哪个步骤容易出错、哪种恢复策略有效、Planner 当时为什么做了那个决策。

SessionVerifier

验证机制。判定逻辑比简单的"成功/失败"复杂得多，接收的信息包括：目标定义、成功标准、约束条件、执行事实、证据（前后对比图像和机器人状态）、血缘历史以及可选的 Skill 级建议。验证器的判定基于"用户可见的目标是否真的达成了"，而不是"动作是否执行了"。PhyAgentOS 有三个可能的验证判定结果。执行失败后的自我纠正，会被沉淀为技能进入记忆库。

Forge Gateway

核心理念是"一个执行边界"：所有机器人动作都通过一个版本化的 Forge Gateway 契约进入系统。Agent 永远不会直接接触策略、模拟器、Dora 节点或硬件 SDK。在传统机器人系统中，上层规划代码经常会直接调用底层控制接口------这不仅让系统难以审计，也让跨硬件迁移变得极其困难。Forge Gateway 把执行入口统一成一个契约，Agent 只需要知道"调用哪个 Skill、传入什么参数"，不需要知道底层是 Franka 机械臂还是松灵双臂。在证据收集方面，PhyAgentOS 在绑定的 Action 执行前后捕获经过验证的图像和可选的机器人状态，存储时附带来源、序列、时间、大小、摘要和保留元数据。这意味着每一次执行的证据都是可追溯的。

覆盖范围

已覆盖游戏智能体、仿真评测和真实机器人三类场景，在 19 种以上仿真与真实机器人本体上完成验证，并在 LIBERO、CALVIN、RoboCasa 等基准中展示了对多种 VLA 模型的适配与性能增益。GitHub Star 已超 2100。

4.2 ABot-AgentOS

定位与核心问题

来自阿里高德视觉实验室。核心研究问题是：长周期具身智能体如何持久地记住经验，并在不同场景间迁移。 它的定位与 PhyAgentOS 类似------坐在低层控制器之上，提供一个审议型 Agent 层，负责场景条件规划、上下文隔离的技能执行、多阶段验证、多模态记忆和边云协同。

Universal Multi-modal Graph Memory

记忆系统。它不把记忆存成简单的向量或文本，而是存成带类型的节点和边：

节点：对话轮次、视觉观测、任务轨迹
边：空间关系（"杯子在桌子左边"）、时间先后（"先开门再拿积木"）、因果关系（"因为碰撞所以抓取失败"）

这种图结构的优势在于检索的精确性。当机器人面对一个新场景时，它可以沿着图的路径找到"和当前场景在空间或时间上相关的历史经验"，而不只是找语义相似的文本。比如机器人看到"厨房台面"，它可以沿着"空间关系"边找到"台面上的物体通常放在橱柜里"这条经验，而不需要这条经验在文本上和"厨房"有多高的语义相似度。

EmbodiedWorldBench

一个可执行基准，包含：

16 个室内、室外和混合场景
四个难度等级
超过 200 个任务，涉及导航、物体搜索、NPC 对话、动态事件和轨迹接地的评分

特殊之处在于它是可执行的------不只是静态问答，而是在仿真环境中实际运行整个 Agent 系统。任务设计上也特意覆盖了长时序场景（导航+搜索+对话的组合），考验的是 Agent OS 的调度和记忆能力，而不仅仅是单个模型的感知或规划能力。

记忆性能的量化结果

基准	得分
LoCoMo（长对话记忆）	87.5
OpenEQA EM-EQA（开放域具身问答）	59.9
Mem-Gallery（多模态记忆）	88.6
NExT-QA Acc@All（视频问答）	76.5

自进化机制进一步提升了这些指标：LoCoMo 从 87.5 提升到 88.7，OpenEQA 从 59.9 提升到 60.4，Mem-Gallery 从 88.6 提升到 89.0。这些数据的意义在于：它证明了图记忆结构不仅能存储多模态信息，而且在实际检索任务中确实优于简单的向量或文本存储方案。

Failure-driven Self-evolution Loop

自我进化机制。核心设计是：把诊断出的记忆失败转化为"门控运行时进化资产"，但这些资产只允许在后续的评估分割中使用。这个设计的精妙之处在于防止 ground-truth 泄漏。如果进化资产可以在当前评估分割中立即生效，那系统就是在"用答案改进答案"，评估结果就失去了意义。通过将进化资产限制在后续分割中使用，系统在真正意义上实现了持续改进而不作弊。

边云协同

不是简单的"小模型处理简单问题，大模型处理复杂问题"。记忆系统做了分层设计：公共环境记忆（路障、施工区域）可以在云端共享，让所有接入系统的机器人受益；涉及隐私的记忆（人脸、个人物品）必须保留在本地。这意味着同一套系统既能在云端共享"这个路口在施工"这类公共知识，又不会把"用户A的家里布局"泄露给用户B。

4.3 ABot-Claw

定位与核心问题

来自阿里高德视觉实验室，定位很特别：不是从零造一个机器人系统，而是给一个已有的、纯软件的智能体运行时（OpenClaw）补上物理世界的能力。 当前具身系统有一个明显的断层：VLA 模型感知强、响应快，但本质是开环的，做长时序任务容易"走着走着就忘了自己在干嘛"；而带 System 2 认知机制的系统虽然会规划，却通常跑在封闭沙盒里，用的是预定义的工具集，对真实系统几乎没什么控制力。OpenClaw 本身是一个强大的本地运行时，有完整的系统权限，能执行 shell 命令、控制 GUI、监听消息，甚至能让 AI 自主生成代码、验证逻辑、部署新功能。但它缺少一个关键的东西：高层控制架构。它没有清晰区分 System 1 和 System 2 的角色，导致对高层意图的持续分解、监控和纠错变得困难；而且它依赖文本日志，视觉、语言和状态信息被割裂成了多模态的"孤岛"。

它补上了哪三块

统一具身接口 + 能力驱动调度：让异构机器人（不同厂商、不同构型）通过同一个接口接入，调度不再依赖硬件细节，而是基于"能力"来分配任务。
以视觉为中心的跨本体多模态记忆：不是把视觉信息转成文字再存，而是直接以视觉为核心组织记忆，让上下文能持久保留，并且检索时能"接地"到真实的视觉观测上。
基于 Critic 的闭环反馈 + 通用奖励模型：用一个通用的奖励模型在线评估任务进展，发现偏了就本地修正，修不好就重新规划。这就把"执行→评估→纠错"的闭环真正跑起来了。

架构分层

三层：OpenClaw 层、共享服务层、机器人具身层，彼此解耦，让自然语言意图到物理动作的闭环成为可能，并支持智能体在开放动态环境中逐步自我进化。

在研究脉络中的位置

ABot-Claw 和 ABot-AgentOS 同出阿里高德视觉实验室，可以看作同一个研究脉络下的两个方向：ABot-AgentOS 更关注长周期记忆和边云协同的认知架构 ；ABot-Claw 更关注如何把已有的智能体运行时"具身化"。

4.4 RoboOS

定位与核心问题

来自智源研究院，2025 年 3 月在中关村论坛首次发布，是首个开源的跨本体具身大小脑协作框架 。它回答的是**"多个异构机器人如何像一个团队一样协作"**。核心设计是大脑-小脑分层架构。

三层架构

具身云模型 ：一个多模态大语言模型，负责全局感知和高层决策。它是系统的"大脑"，做的是"理解场景、拆解任务、决定谁去做什么"这类工作。
小脑技能库 ：一个模块化、即插即用的技能工具包，负责无缝执行多种技能。它是"小脑"，做的是"接到大脑指令后，调用具体的运动控制、抓取、导航能力"这类工作。
实时共享内存 ：一个时空同步机制，让多个智能体之间的状态能实时协调。这是实现多机协作的关键------如果两个机器人不知道彼此的位置和状态，协作就无从谈起。

解决的核心痛点

当前机器人系统面临三个核心痛点：跨本体适应性差、任务调度低效、动态纠错能力不足。端到端 VLA 模型长时序规划弱、任务泛化差；分层 VLA 模型又缺乏跨本体兼容性和多智能体协调能力。RoboOS 通过大脑-小脑分层信息流，把"规划、调度、纠错"和"技能执行"分开，同时用共享内存保证多智能体协作的效率。它已经在餐厅、家庭、超市等真实场景中验证，支持单臂、双臂、人形、轮式等多种异构本体。

RoboOS 2.0 的进化

基于具身智能 SaaS 平台，支持无服务器一站式轻量化部署，全链路平均响应时延低于 3ms，端云通信效率提升 27 倍，并通过"小脑技能免适配注册机制"把典型场景的代码量缩减到传统方式的十分之一。

4.5 Qwen-RobotNav

定位与核心问题

Qwen 团队 2026 年 6 月发布的工作。定位不是"一个完整的 Agent 系统"，而是一个可以被 Agent 系统调用的导航基础模型 。核心洞察是：导航看起来是一个任务，实际上包含差异极大的子任务。 指令跟随需要对历史观测保持长期记忆，以便回溯远处的地标；目标跟踪几乎只关注最近几帧；物体搜索在探索阶段需要长程历史，在接近目标阶段又需要紧凑的近期窗口。传统做法是给模型嵌入固定的"该记住什么"的假设，但 Qwen-RobotNav 换了一种思路：把上下文视为可由外部自由控制的部分。

四个可调参数

视觉词元预算：总共用多少视觉信息
时间衰减：近期帧相对于较早帧的权重
相机权重：各相机的重要性（比如前向相机比后向更重要）
帧采样模式：随机采样覆盖全局历史，还是选最新帧构建紧凑窗口

训练时这些参数在每个样本中随机化，模型从未见过固定配置，因此能泛化到推理时的任意设置。

与 Agent 系统的配合

被设计为双层导航系统中的可重配置导航基础模型。上层规划器（比如 Qwen3.7-Plus）负责分解长时序目标、调度可配置的导航调用；Qwen-RobotNav 作为"导航动作执行单元"，接收上层传来的参数，输出 8 个路径点。在 EXPRESS-Bench 上，这套双层系统配合记忆机制，效果提升了 15.4%，导航步数减少了 77%。它在 Unitree Go2 四足机器人上零样本部署，只用机器人自带的低分辨率相机，无需任何环境特定微调。

在知识框架中的位置

Qwen-RobotNav 回答的是**"导航能力如何封装成一个可配置、可调用的 Skill"**。它不解决规划问题，不解决记忆问题，只解决"给定参数，输出路径点"这一件事。这恰好是通用组件框架中"Skills"组件的一个具体实例------Planner 决定"调用导航"，Qwen-RobotNav 负责"导航本身怎么做"。

4.6 Pi agent

定位

不是具身智能系统，它是一个纯软件的编码智能体 harness，但被列为"架构参考"，因为它体现了一种值得借鉴的设计哲学。

核心设计：4 个工具，其他全部外挂

Pi 的设计极其克制：它只给模型四个工具------read（读文件）、write（写文件）、edit（编辑）、bash（执行命令），然后系统提示词尽量简短，其余能力全部通过 skills、prompt templates、extensions 和 packages 来添加。它不内置 subagent、不内置 MCP、不内置 plan mode、不内置 todos------这些东西在别的系统里通常是标配，Pi 选择全部不做，让用户按需外挂。

运行时循环

提示 → 上下文转换 → LLM 流式生成 → 工具执行 → 事件回流 → 循环。扩展挂在生命周期事件上，技能按需加载，社区 harness 把钩子面进一步封装成 skill-router、session-summary、extract-patterns、telemetry 等现成扩展。

为什么值得参考

Pi 的设计哲学直接回应了一个核心问题：Harness 不应该是一个"什么都包"的庞然大物 。它应该是一个最小化的、可扩展的骨架 ，核心只做"管理工具调用循环"这一件事，复杂能力通过明确的扩展点外挂。这对于理解 PhyAgentOS 和 ABot-AgentOS 的设计也有帮助：它们看起来组件很多，但每一个组件（Planner、Critic、Verifier、Memory）都可以看作 Pi 意义上的一个"扩展"------挂在核心循环上的可插拔模块。Pi 的极简主义让你更清楚地看到，一个 Harness 的最小内核到底是什么。

4.7 端侧模型专用 Harness

问题背景

前面看到的 PhyAgentOS、ABot-AgentOS 这些系统，默认接入的是云端大模型 API。它们的 Harness 设计得非常复杂、功能全面，因为大模型有足够的"脑容量"去消化这些复杂的框架和指令。但端侧部署是另一回事。美格智能在 MT200 AI BOX 上部署 DeepSeek Harness 的案例说明了端侧部署的核心诉求：模型推理全程运行在设备本地，不联网也能对话、检索、执行任务 。这对数据安全、响应延迟和离线可用性都有重要意义。问题是：如果你直接把为大模型设计的复杂 Harness 塞给一个 27B 参数的端侧模型，它会"消化不良"。Perplexity 的实验发现，尽管 Qwen 3.8 27B 提供了 26 万 token 的上下文窗口，但当 token 数量超过 10 万时，模型性能就开始下降。

解决方案：Harness 和模型相互配合

Perplexity 的思路不是"让小模型去适应大模型的框架"，而是让两者相互配合：框架根据模型的能力特性量身定制，模型经过后训练以有效使用框架。具体做法：

保持核心框架的简洁性：端侧模型的 Harness 不做大而全的设计，而是把核心循环压到最精简。它只保留必要的工具调用和状态管理，其余能力按需外挂------这和 Pi agent 的极简主义哲学一脉相承。
支持上下文压缩：当对话轨迹变长时，Harness 会自动总结过时的上下文，把信息压缩后保留，以便模型始终在有效窗口内运行。这相当于给端侧模型配了一个"自动摘要器"，而不是让它自己硬扛长上下文。
模型侧的后训练配合：Perplexity 基于 Qwen 3.8 27B 进行后训练得到的 PPLX 27B，在适配专用 Harness 后，得分从基础版本的某个水平提升到了 85.4%。这说明 Harness 和模型是协同进化的，而不是一个迁就另一个。

其他实践

面壁智能与吉利合作发布的 RoboHarness 也是这个方向的实践，它基于端侧大模型，让机器人在吉利生产仓储场景中实现了常态化作业。

在知识框架中的位置

"端侧模型专用 Harness"回答的是**"当模型足够小、算力足够有限时，Harness 应该怎么设计"**。它和前面所有系统共享同一个底层直觉------LLM 不直接控制硬件，中间需要一层组织层------但它的设计约束完全不同：不是"如何组织更多能力"，而是"如何在有限资源下保持可用"。

4.8 Harness VLA

问题背景

这是调研文件中信息最完整的一篇。清华大学于超教授团队的工作，核心问题非常明确：VLA 模型在标准测试集上表现很好，但离开标准环境就大幅衰退。 具体数据：在 LIBERO 130 个任务中训练的 Pi 0.5 模型，平均成功率高达 96%。但把这个模型部署到有目标重绑定与布局扰动的 LIBERO-Pro 环境中，成功率锐降至 50%。动作依然流畅，局部操作本身也没有明显错误，但因为目标绑定、空间关系或任务阶段判断出现偏差，整个任务仍然会失败。这不是"模型能力不够"的问题------模型能做每个动作。问题是模型不知道在什么时候该做什么，以及在偏差出现后如何恢复。

解决方案：给 VLA 加一层 Harness Layer

底层 VLA 全程冻结，权重保持不变。不训练模型，不微调参数，只在 VLA 外面加了一层 Harness Layer。这层 Harness 由一个 Agentic Planner 驱动，负责三件事：

决定何时调用 VLA：不是让 VLA 一直跑，而是由 Planner 判断"现在该执行哪个动作原语"，然后才调用 VLA 去执行这个原语。
管理执行上下文：维护任务的状态跟踪，确保 VLA 在正确的阶段被调用，避免"目标绑定"出现偏差。
失败后重置和重试：当 VLA 执行失败时，Harness 负责重置环境状态，然后以修正后的方式重新调用 VLA。

本质是：VLA 是一个"接触密集操控"的专才，Harness 是它的"项目经理"。专才只负责把单个动作做到极致，项目经理负责判断"什么时候该叫它、叫它做什么、做砸了怎么补救"。

效果和意义

在 LIBERO-Pro 扰动评测中，把成功率从 50.0% 提升到了 82.4%。作为对比，同期英伟达的 Cap-X 仅 18.2%，Berkeley RATS 为 43.8%。整个过程中，VLA 本身没有改变任何参数------提升完全来自系统层的组织方式。Harness 并非针对某一特定模型设计，而是一种面向系统层的通用框架。除了 VLA，它同样能够与 WAM（世界-动作模型）等具身基础模型结合，通过统一的任务执行层释放不同基础模型的能力。于超教授在专访中总结了这个范式转变："我们不再把 VLA 当作一个纯粹的端到端执行器，而是在它外面加了一层 Harness Layer，并与 code policy agent 结合，结果系统自己学会了如何分配任务"。

与 PhyAgentOS / ABot-AgentOS 的关系

维度	Harness VLA	PhyAgentOS / ABot-AgentOS
解决的问题	单个 VLA 模型在扰动下的稳定性	完整任务闭环（规划、技能、验证、记忆）
组织层的位置	VLA 之上、任务规划之下	贯穿整个 Agent 系统
是否修改模型	完全不修改，VLA 冻结	不修改模型，模型只是组件之一
核心组件	Agentic Planner + 记忆引导	Planner + Skills + Verifier + Memory + Runtime

你可以把 Harness VLA 理解为 PhyAgentOS 中"Skills 层"的一个具体实现方案：它展示了如何用 Harness 的思路，让一个原本脆弱的 VLA 模型变得可靠可用。

4.9 RoboHarness

问题背景

Harness VLA 解决的是"一个模型如何在扰动下稳定发挥"。RoboHarness 面对的是另一层问题：当任务超出任何一个模型的能力边界时，怎么办？ 调研文件里反复出现的那个例子------打开柜门、找到积木、搭成桥------完美说明了这个问题。这个任务横跨四种完全不同的能力：

VLA：理解开放式语言指令、在新环境里泛化，但端到端生成动作的方式在长时序任务中很难保持一致性。
RL 策略：能在特定训练场景内磨出稳定的闭环行为，但稳定性高度依赖训练分布，环境稍有变化便可能失效。
TAMP（任务与运动规划）：擅长符号推理和几何约束，但需要预先定义动作原语，面对开放场景和模糊目标时很快就会吃力。
WAM（世界-动作模型）：能通过预测未来状态辅助长时序决策，但容易随预测时域增长产生误差累积。

能力不缺，缺的是协作。 RoboHarness 的出发点正是：与其等待某一个模型填平所有能力的鸿沟，不如先让已经存在、各有所长的模型真正协同起来。

核心设计：策略封装 + 能力感知路由 + 记忆桥

RoboHarness 把 VLA、RL、TAMP 等独立开发的控制系统封装成可复用的 agentic skills ，由 Coding Agent 负责高层决策和子任务路由。但这里有一个关键难题：不同策略的状态分布不兼容。VLA 可能期望视觉观测作为输入，RL 策略可能期望低维状态向量，TAMP 可能期望符号化的世界状态。当任务从一个策略切换到另一个策略时，机器人当前所处的状态可能完全不在下一个策略的"分布内"，导致切换瞬间崩溃。

RoboHarness 的解法是 Memory Bridge（记忆桥）：

检索与下一个策略相关的历史执行轨迹
估计该策略的分布内状态区域（in-distribution state region）
引导机器人向该区域移动，而不需要对策略进行联合重训练

你可以把 Memory Bridge 想象成接力赛中的"交接区"------上一棒选手不是随便把棒子扔出去，而是要先进入下一棒选手能够顺利接棒的位置，再把棒子交出去。此外，RoboHarness 还配备了理解、记忆和进化三大辅助技能，用于精准评估当前环境和任务进展，决定下一步该派哪个策略上场。

效果

在三个公开基准、500 个定制任务和 135 个真实机器人实验中取得了 86% 的成功率 ，在零样本长时序规划和分布外鲁棒性上都有显著提升。作者有一个重要的判断：直到某一个模型能够完全压制其他所有模型之前，这种编排架构都是非常有意义的。

与 Harness VLA 的对比

维度	Harness VLA	RoboHarness
核心问题	单个策略的稳定性	多个策略的协同
组织对象	一个冻结的 VLA	VLA + RL + TAMP + WAM 等异构策略
核心组件	Agentic Planner + 记忆引导	Memory Bridge + 能力感知路由
一句话概括	让一个专才变得更稳	让一群各有所长的专才协同作战

4.10 世界模型（实际应用案例）

宇树 UnifoLM-X2-1.0：世界模型驱动的全自主搏击

2026 年 9 月，宇树科技发布了世界-动作大模型 UnifoLM-X2-1.0，首次实现人形机器人全自主搏击 ------出拳、格挡、躲闪、连续攻防转换，全程不依赖外部遥控或预设脚本。搏击场景对世界模型提出了极高要求：目标高速移动、对抗强、攻防转换极快，机器人必须在毫秒级时间内 完成感知、预测、决策和执行。宇树创始人王兴兴在 WRC 2026 上直言，机器人目前最大的瓶颈是"AI 模型的输入和输出对齐程度不够。每输入输出一次，都会产生偏差"。UnifoLM-X2-1.0 的意义在于验证了世界模型实时驱动人形机器人的基础可行性。

智元 Act2Goal：以终为始的目标达成

智元的 Act2Goal 方案引入了"目标条件"的世界模型：给机器人一张"目标照片"，它就能自己想办法把面前的场景变成照片里的样子。不同于传统机器人机械地执行死板指令，Act2Goal 让机器人"以终为始"------先理解目标状态，再反推需要执行的动作序列。

地瓜机器人 WM-LOCO：世界模型引入人形行走

地瓜机器人发布的 WM-LOCO 方案，首次将预测世界模型引入人形机器人复杂地形行走，与 PPO 策略实现端到端联合训练。该方案不依赖落脚点标注，让机器人在"想象"中学习如何在梅花桩等地形上行走。

与 RoboHarness 的关系

两者在光谱上处于互补的位置：世界模型解决的是"如果做，大概会怎样 "------它擅长预测未来状态，辅助长时序决策。但正如 RoboHarness 论文中指出的，世界模型（WAM）容易随预测时域增长产生误差累积。RoboHarness 解决的是"什么时候该用哪种能力 "------它不试图预测未来，而是通过记忆桥和能力感知路由，让不同策略在正确的时间被调用。调研文件里那篇"世界模型思路"的微信文章，核心观点可以概括为：世界模型不是要取代 VLA 或 RL，而是为它们提供一个"预演"的能力。在执行代价高昂或不可逆的动作之前，先在脑内世界里试错，这恰好呼应了 Harness VLA 中"失败后重置和重试"的设计------Harness 负责"重试"，世界模型负责让"试错"发生在脑内而不是真实世界。

五、对比与总结

5.1 PhyAgentOS vs ABot-AgentOS

维度	PhyAgentOS	ABot-AgentOS
核心原则	认知---物理解耦（Track A/B 分离）	边云协同 + 图记忆
通信机制	State-as-a-File（本地 Markdown 文件）	多模态图结构（节点+边）
调度单元	Session（整个会话）	场景条件规划 + 技能执行
验证方式	SessionVerifier（语义验收 + 证据链）	多阶段验证
记忆系统	LESSONS.md + 技能经验库	Universal Multi-modal Graph Memory
进化机制	技能进化（失败经验沉淀为 Skill）	failure-driven loop（门控进化资产）
硬件抽象	Forge Gateway 统一执行边界	跨本体执行抽象
独特设计	"State-as-a-File"极端透明	图记忆 + 防泄漏进化

共同的设计直觉 ：都选择在 LLM 和硬件之间加一层"操作系统层"，都强调执行证据和闭环验证，都把记忆/进化作为系统的一等公民而不是事后补丁。

差异的根源 ：PhyAgentOS 更强调工程透明性 ------用文件系统做通信，任何人都能审计整个执行链路。ABot-AgentOS 更强调认知持久性------用图结构组织记忆，让系统在长时间运行中持续积累和检索经验。

5.2 所有项目的完整光谱

按"解决的问题层级"从低到高排列：

项目	核心问题	在光谱上的位置
Pi agent	Harness 的最小内核是什么	纯软件，极简参考架构
Qwen-RobotNav	导航能力如何封装成可调用的 Skill	单一能力层
端侧模型专用 Harness	小模型+有限算力下 Harness 怎么设计	部署约束下的 Harness
Harness VLA	单个 VLA 模型如何变得可靠	单模型可靠性层
RoboHarness	多个异构策略如何协同	多策略编排框架
世界模型	如何在行动前预演后果	认知预演层
PhyAgentOS	单智能体如何实现认知-物理解耦	完整 Agent OS
ABot-AgentOS	单智能体如何持久记忆、边云协同	完整 Agent OS
ABot-Claw	已有软件智能体如何具身化	Agent OS 的"具身扩展"
RoboOS	多个异构机器人如何协作	多智能体协作框架

5.3 贯穿所有项目的一条线

所有项目共享同一个底层直觉：LLM/VLM 不直接控制硬件，中间必须有一层组织层来编排能力、验证结果、管理记忆、预演后果。 区别只在于这层组织层：

是极简的还是完整的：Pi agent 四个工具 vs PhyAgentOS 五组件
是服务单策略的还是多策略的：Harness VLA 管一个 VLA vs RoboHarness 管四种策略
是部署在云端还是端侧的：ABot-AgentOS 边云协同 vs 端侧专用 Harness
是服务单机还是多机的：PhyAgentOS 单智能体 vs RoboOS 多机器人协作
是纯软件的还是延伸到物理世界的：Pi agent 纯软件 vs ABot-Claw 具身扩展

5.4 两个必记数据

Harness VLA：LIBERO 标准测试 96% → LIBERO-Pro 扰动测试 50% → 加 Harness 层后 82.4%。VLA 参数全程冻结。
RoboHarness：500 个定制任务 + 135 个真实机器人实验，86% 成功率。核心洞察是"直到某一个模型能完全压制其他所有模型之前，编排架构都有意义"。

六、零基础学习路径

阶段一：建立整体认知（1---2 周）

目标：知道具身智能体是什么、各组件之间什么关系，能用自己的话解释核心概念。推荐先看科普性文章："LLM 到 harness 技术科普"和"具身智能 Skills 方案"两篇微信文章，科技日报关于 PhyAgentOS 的报道，雷峰网那篇 Agent 走向具身世界的文章。

阶段二：通读技术材料，理解架构设计（2---3 周）

目标：能读懂 PhyAgentOS 和 ABot-AgentOS 的架构文档，理解它们各自的设计取舍。建议顺序：先读两篇"技术解析"微信文章，再去 GitHub 看 PhyAgentOS-core 的文档，重点看 05-agent-experience-and-skill-evolution.md，然后读 ABot-AgentOS 的论文摘要和介绍。这个阶段不需要读代码，但要能回答：PhyAgentOS 的 State-as-a-File 是什么意思？为什么它能实现跨硬件的零代码迁移？ABot 的记忆系统为什么用图结构而不是简单向量数据库？

阶段三：动手实践（3---4 周）

目标：在仿真环境中跑通一个最小闭环。推荐 Datawhale 的 dive-into-embodied-ai 开源教程，它面向求职和转行人群，目标是"从零到一搭建一台具身智能机器人"。具体顺序：先跑通仿真环境，按教程把 examples/01_hello_every_embodied_mujoco.py 跑起来；然后理解感知---决策---行动闭环，实现最简单的"看到目标 → 规划路径 → 移动"；再引入一个 VLA 模型；最后尝试把 Harness 概念用进去。

阶段四：深入一个方向（持续）

可选方向：架构方向（深入 PhyAgentOS 或 ABot-AgentOS 源码）、导航方向（Qwen-RobotNav）、多机协作/操作系统方向（RoboOS）、技能学习与进化方向（ASPIRE 范式）。

七、给自己的四个提醒

不要试图一次搞懂所有东西。这份调研覆盖了架构、导航、技能、记忆、验证、世界模型等多个子领域，任何一个方向都有大量论文。先建立框架，再逐步填充。
概念比代码重要。零基础的情况下，先理解"为什么这样设计"比"代码怎么写的"更有价值。PhyAgentOS 的 State-as-a-File 之所以有意义，是因为它解决了"不同机器人硬件接口不统一"这个根本问题。
动手比读论文重要。具身智能的很多概念（闭环、验证、技能进化）在纯文字层面很难真正理解，只有在仿真里跑一遍，才能体会到"为什么需要 Verifier""为什么 Plan 完不能直接 Execute"。
善用调研文件里的资源。那些微信文章是很好的二手解读，技术报告是更严谨的一手材料，GitHub 仓库是最终的事实来源。三者配合着看，效率会比只看一种高很多。

📌 整理自老师发的调研文件 + 一天查资料。零基础整理，如有错误欢迎指正。全文涵盖所有细节、数据、例子、设计动机，可作为完整学习笔记收藏。

Jenny Lab - 小红书