答疑特辑（四）：全场景机器人、共享 KV cache 与 agent harness 三问

先厘清一个概念：“全场景”不是”每台都会”#

问题里有一个隐含前提值得先拿出来看：读者假设”全场景覆盖的机器人”意味着同一台机器人同时具备洗碗、做饭、做生化实验的全部能力，所以它必然贵到普通人买不起。

这个前提在软件定义机器人（software-defined robot）的时代并不成立。行业对”全场景”的主流理解是通用硬件平台 + 按需技能包：机器人的身体（本体）是一套标准化硬件，能力以软件形式下发——就像 iPhone 出厂时并不自带全部 App。一台家庭机器人和一台实验室机器人，本体可以是同一款（宇树 G1、Figure 03 这类通用平台），差别在于安装了哪些技能模型、接入了哪些工具。购买者按需付费：家庭用户买”洗碗 + 叠衣 + 整理”技能包，实验室客户买”移液 + 样本搬运”技能包。

这样一来，“全场景”就不再要求单台机器人的硬件堆料达到”全人类技能全集”的水平，它要求的是平台够通用、技能可以持续追加。成本问题从”一次性买断全能”变成了”按场景购买技能”，两个市场的预算完全不同（这一点在第四部分展开）。

算力的账：云端大脑 + 边缘执行#

接下来回答最核心的质疑：“这样的机器人要真的智能需要很大的模型，不可能一个机器人里面装 8 张 B200。”

这里要拆掉一个常见的误解：大模型不必（也不应该）跑在机器人身上。 具身智能的计算架构早已分化成”训练—仿真—推理”三段，NVIDIA 称之为机器人三大计算平台（three-computer architecture）：

1. 训练（Training）：在数据中心的 DGX 集群上训练基础模型。这一阶段吃掉绝大部分算力——GR00T N1.5 的训练用了 1000 块 H100、25 万步，这显然不是机器人身上的设备能干的活；
2. 仿真与合成数据（Simulation）：在 Omniverse + Cosmos 平台上用 Isaac Lab 把人类演示数据扩展为合成动作数据，同样在云端完成；
3. 推理执行（Inference）：部署在机器人本体上的边缘计算平台，负责实时感知、决策与运动控制。

也就是说，8 张 B200 属于第一步（训练），而机器人本体只需要第三步的设备。 英伟达官方博客这张图把机器人所需的硬件与软件组件列得很清楚——计算平台、传感器、执行器、软件栈各司其职，没有任何一个组件是”数据中心级 GPU”：

那么”机器人身上的大脑”到底需要多大？看英伟达专为人形机器人设计的边缘计算平台 Jetson AGX Thor（2025 年 8 月发布）的规格，答案会让”必须装 8 张 B200”的直觉动摇：

B200 的绝对算力当然碾压 Thor——但注意两个关键差异：功耗相差约 8-10 倍，而机器人恰恰是功耗预算最紧张的计算场景。 机器人靠电池供电，整机散热靠被动风道。做一道简单的算术：一块 100 Wh 的消费级电池（笔记本电池水平），带满载的 B200（1000 W）只能撑 6 分钟，带满载的 Thor（130 W）能撑约 46 分钟——这还是没算关节电机（机器人的耗电大头）的情况。把 B200 装进机器人不是”贵不贵”的问题，是物理上撑不住的问题。8 张 B200 的电费账同样在数据中心里算，不在机器人身上算。

模型要多大：3B 的 VLA 就能干活#

“要真的智能需要很大的模型”——这句话需要修正为”需要很强的模型，而不一定是很大的模型”。机器人执行层的主流模型是视觉-语言-动作模型（Vision-Language-Action model，VLA），它直接吃视觉和语言指令、输出关节动作，参数量远小于通用大语言模型：

• NVIDIA 开源的 GR00T N1.5 是约 30 亿（3B）参数的 VLA 基础模型，官方就部署在 Jetson Thor 上——FP16 下权重约 6 GB，连手机存储都装得下；
• 物理智能公司（Physical Intelligence）的 π0 系列同样只有 30 亿参数级别；
• 更大的规划模型（世界模型、任务规划器）可以留在云端，通过 5G/专网下发高层指令。

GR00T N1.5 的双系统架构解释了为什么这么小的模型够用：System 2（视觉语言推理，约 10 Hz）理解场景与指令、做慢速规划；System 1（扩散 Transformer 动作头，用流匹配生成连续动作，最高 120 Hz）负责快速动作执行。高频闭环（触觉、力控、平衡）在边缘用小模型完成，低频规划（“下一步做什么”）可以交给云端大模型。“大”和”快”各安其位，不需要一个模型包办所有时间尺度。

英伟达官方博客给出了 Thor 上跑生成式模型的实际延迟数据：同时处理 16 路请求，运行 Qwen2.5-VL-3B（视觉语言模型）和 Llama 3.2 3B（语言模型），首 token 时间（Time to First Token，TTFT）稳定低于 200 毫秒，每输出 token 时间（Time per Output Token，TPOT）低于 50 毫秒——这是机器人控制可用的实时性。下图即该测试的结果：

顺带一提，Thor 并不是孤例：Agility Robotics（第六代 Digit）、波士顿动力（Atlas）、Figure、1X、优必选、宇树、银河通用都宣布了基于 Thor 的整机方案——“机器人身上的大脑”已经是 130 W 边缘模组的共识，而不是数据中心 GPU。

存储的账：训练数据在云端，机器人本体只带”模型 + 当前状态”#

“具身智能需要存储大量现实活动数据，存储要求远大于 LLM”——这句话在训练侧完全正确，而且值得展开：具身智能的训练数据确实是迄今 AI 领域最”重”的数据。遥操作（teleoperation）演示要记录多视角视频、关节力矩、触觉信号，一条演示数据就是普通文本数据的几个数量级；全球头部团队都在建”数据工厂”收集人类操作数据，这些数据以 PB 计。

但注意：这些数据存在数据中心的存储阵列里，不在机器人身上。 训练数据的使用者是 DGX 集群，不是机器人本体。机器人本体在推理时只需要两类数据：

1. 模型权重：GR00T N1.5 约 6 GB（FP16），更大的端侧 VLA 也就几十 GB——消费级手机存储的量级；
2. 即时状态：当前环境的感知数据、短期任务记忆，几百 MB 到几 GB 的循环缓冲。

类比一下：你不会因为”YouTube 上有海量视频”而要求手机装下整个 YouTube。视频存在云端，手机只需要”当前正在播放的这一段”。具身智能同理：经验（数据）存在云端，机器人只需要”此刻的环境与任务”。真正需要机器人本机大容量存储的，只有离网/弱网场景（矿井、太空）——那是特例，不是通用架构。

成本的账：全场景按市场分化，B 端先付费#

“普通人买不起”——这个判断需要区分两个市场：

家庭市场的”全场景”其实是有限的技能集合（洗碗、叠衣、整理、陪护），不是”全人类技能全集”。这个市场的价格目标早已明确：机构普遍预测 2030 年前后整机价格降至 3-4 万美元（IDTechEx 预测 2030 年均价约 3.7 万美元），规模化量产后部分预测低至 2-3 万美元——虽然仍不是”白菜价”，但已进入中产家庭可考虑的范围，且成本曲线每年下降 30-40%（详见《人形机器人必答题》的成本交叉点部分）。

实验室/专业市场（生化实验正是典型）本来就是 B 端付费市场，买主是药企、医院、研究机构，不是个人。这类客户今天已经在为专用自动化设备付钱：高端液体处理工作站（Tecan、Hamilton 的产品）数十万美元一台，入门级桌面移液机器人（如 Opentrons）数千美元。人形机器人在实验室里的定位不是替代这些专用设备——专用设备在”精准移液”上永远更便宜更可靠——而是做通用操作员：拿取试管架、开关离心机、整理台面、配合自动化设备完成非标动作。这些任务当前靠人力完成，人力的成本在发达国家实验室里是每小时 20-40 美元级别（含福利）。对照《人形机器人必答题》中 Figure 对宝马约 25 美元/小时的 RaaS 报价，经济账在同一量级。

诚实的另一半#

把话说全：上面四条论证的是”8 张 B200 不必装进机器人”，不是”全场景机器人明天就能造出来”。真实的约束仍然存在：

• 端侧模型的能力天花板：3B 级 VLA 目前只能稳定执行几十种任务，复杂长程操作（多步骤、不可预测环境）仍要靠云端大模型兜底，而云端调度的延迟和网络稳定性是工程痛点；
• 数据确实是当前最大的瓶颈：训练侧的数据需求远大于 LLM 时代，这一点读者的直觉是对的——只不过解决办法是”云端共享数据设施”，而不是”每台机器人装大硬盘”；
• “全场景”是渐进的：当前没有任何一台机器人能做到”洗碗 + 做饭 + 生化实验”三合一，行业路线是先在每个垂直场景跑通（仓库、工厂、实验室各干各的），技能库再逐步横向扩展。

一句话总结第一问：机器人的智能=云端的大脑+边缘的小脑+本体的执行器，算力和数据都分摊在云与端之间，而不是全部塞进机器人——“装 8 张 B200”既无必要，也不可能。

先复习：KV cache 是 prefill 的产物#

在《MLA 完全拆解》和《PagedAttention 完全拆解》里都讲过：Transformer 自注意力中，每个 token 都要与上下文里所有 token 做注意力计算。为了不在每生成一个新 token 时重算历史 token 的 K、V 向量，推理系统把每个已处理 token 的 K、V 缓存下来——这就是 KV cache（键值缓存）。

KV cache 的大小与模型结构和上下文长度成正比：每层、每个 KV 头各存一份 K 和 V，token 越多越大。这也解释了为什么 KV cache 是长上下文推理的内存大头——它随上下文长度线性增长，而模型权重是固定的。

540 GB 是怎么算出来的：完整的推导#

论文的数字不是拍脑袋，它对应一个具体模型的具体配置。论文场景是 Llama 3.1 405B（FP8 权重约 405 GB），它使用分组查询注意力（Grouped-Query Attention，GQA）——注意头 128 个，但 KV 头只有 8 个（8 个 KV 头被 128 个查询头分组共享）。Llama 3.1 405B 的官方配置为：126 层、8 个 KV 头、头维度 128。

每个 token 产生的 KV 缓存大小可以精确写出：

逐项解释：因子 2 来自 K 和 V 各一份；$n_{\text{kv heads}}$ 是 KV 头数（GQA 下每层只有 8 个）；$d_{\text{head}}$ 是每个头的维度（128）；$n_{\text{layers}}$ 是层数（126）；最后乘每个数值的字节数——论文按 FP16 计算，即 2 字节。代入：

即平均每个 token 约 0.5 MB（FP16）。再乘上下文长度：100 万 token 的上下文对应约 516 GB，1000 万 token 对应约 5.16 TB——论文写作时取整为 540 GB / 5.4 TB（与按 1024 进制或模型细节的取整差异都在量级之内）。推导与论文数字吻合，说明这个表格数字可以直接从 Llama 3.1 405B 的 GQA 结构算出来，而不是随意给的。

“预计算”：把知识库先跑一遍 prefill#

理解了 KV cache 之后，“预计算”就清楚了。普通对话中，每个请求都要从零开始：先做 prefill（预填充）——把用户输入整段送进模型，算出每层的 K、V 并缓存，然后才进入逐 token 生成。长输入的 prefill 很贵：一次 100 万 token 的 prefill 要跑约 516 GB 的 KV 计算。

但如果输入的内容是固定不变的知识库（公司文档、教科书、代码库），就有一个明显的优化：把文档预先跑一次 prefill，把 KV cache 存下来，之后所有查询直接复用这份缓存，完全跳过 prefill。 这就是缓存增强生成（Cache-Augmented Generation，CAG）——2024 年底由 Hive AI 等团队提出（论文 Don’t Do RAG: When Cache-Augmented Generation is All You Need for Knowledge Tasks，发表于 WWW 2025）。H³ 论文引用 CAG 作为”海量只读”工作负载的典型代表。

“共享”：K 和 V 只取决于文档，不取决于问题#

“共享”是这份缓存最反直觉也最关键的属性。注意力计算是：

其中 Q（查询）来自当前问题，而 K、V 只来自被读的文档。两个不同的用户问两个不同的问题，查询向量 Q 不同，但只要读的是同一份文档，K 和 V 就完全相同。所以这份 KV cache 可以被所有请求共享——这就是”共享预计算 KV cache”的字面意思：一份 540 GB 的缓存，为所有读这份文档的请求服务，每个请求只花”读缓存 + 生成”的钱，不花”重新计算”的钱。

这带来两个推论，正是 H³ 论文看中它的原因：

1. 只读：缓存一旦算好，就只被反复读取，从不写入。这恰好避开 HBF（高带宽闪存，High Bandwidth Flash）的写耐久短板（NAND 怕写不怕读），是”放 HBF”的充分理由；
2. 摊薄：一次 prefill 的成本被 N 个请求分摊，请求越多越划算。论文里”共享 KV 注意力（shared-KV attention）“的描述即指这种多请求共享同一份 KV 的计算模式。

一张图看清 CAG 与 RAG 的本质区别#

为什么不用传统的检索增强生成（Retrieval-Augmented Generation，RAG）？RAG 每次查询要先做检索（IR），把相关文档片段拼进上下文，再走完整的 prefill；CAG 则把全部文档离线预计算成 KV cache，查询时直接进生成阶段。CAG 论文的图 1 把两条路线并排画了出来：

读图要点：左侧 RAG 路径中，查询（Query）要先经过检索模型（IR Model）从知识源（Knowledge Source）里挑出片段，再连同查询一起送进 LLM 走完整的 prefill（Context 构建）；右侧 CAG 路径中，知识源先做离线预加载（Offline Preloading），把 KV cache 存起来，查询到来时直接与缓存拼接，跳过检索和重复计算。代价是缓存容量大（几百 GB 到 TB 级），收益是省掉检索延迟、检索错误和系统复杂度。

为什么 540 GB 需要专门的硬件方案#

最后回到数字本身：540 GB 有多大？作为参照，一块 B200 的 HBM 是 192 GB——540 GB 的 KV cache 光是”装下”就需要 3 块 B200 的全部显存（且模型权重 405 GB 还没算）。5.4 TB 则需要 28 块。这正是 H³ 论文的痛点：HBM 容量是硬上限，而 KV cache 是”装不下”而不是”算不动”。

H³ 的答案是给 KV cache 换介质：只读、共享、超大容量的预计算 KV cache 放进 HBF（3 TB 容量、成本约 HBM 五分之一），动态生成的 KV（对话中新 token 的 K/V，写后读、延迟敏感）留在 HBM。这也是数据放置表格的逻辑——按数据的访问特征选择介质：共享预计算 KV cache 是”最大、最读、最不敏感”的数据，理应放最便宜的大容量介质。

一句话总结第二问：共享预计算 KV cache = 把固定知识库一次性 prefill 得到的 K/V 缓存（Llama 3.1 405B 在 FP16 下约 0.5 MB/token，1M token 上下文约 540 GB），它只读、被所有请求共享，是 CAG 场景的核心数据结构，也是 H³ 把它放进 HBF 的理由。

先修正一个理解：agent 不是工具，模型也不是 agent 的全部#

读者把 agent 理解成”工具”、把 agentic AI 理解成”里面的 AI 模型”——这个类比有一半说反了。准确的关系是：模型（model）是零件，agent 是系统，agentic AI 是行业。

• 模型（如 GPT、Claude 这类大语言模型）：接收文本、输出文本，本身没有手、没有循环、没有记忆，只是”大脑”；
• agent（智能体）：把模型放进一个能”感知—规划—行动”的循环里，让它能调用工具（浏览器、代码解释器、文件系统）、观察结果、决定下一步，直到完成任务。agent 是那个会干活的东西——它恰恰是”用工具的主体”，而不是工具本身；工具是它手里拿的扳手；
• agentic AI（智能体式 AI）：描述”AI 从被动回答问题走向自主行动”这一整个范式转型的行业术语。它不是一个具体的系统，而是一个类别名——就像”互联网行业”不等于”某个网站”。

用公司作类比：agentic AI 是”雇佣制”这个概念，agent 是”被雇佣的员工”，工具是员工手里的设备，模型是员工的大脑。说”agent 是工具”等于说”员工是扳手”。

harness：把模型变成 agent 的脚手架#

那 harness 是什么？agent harness（智能体驾驭层/脚手架）是包裹在模型外面、连接模型与现实世界的那层软件基础设施。 Anthropic 工程博客的定义是目前流传最广的版本：“agent harness 是模型周围的软件脚手架——循环、工具、上下文管理与护栏，把原始智能变成能工作的智能体。“（An agent harness is the software scaffolding around a model: the loop, tools, context management, and guardrails that turn raw intelligence into a working agent.）

业界普遍用这个公式概括三者关系：

模型只负责”想”，harness 负责”干”：模型产生文本，harness 决定这些文本能碰什么、不能碰什么。一个生产级 harness 至少包含四类组件：

1. 循环（loop）：让 agent 反复执行”思考→行动→观察结果→再思考”的智能体循环（agentic loop），直到任务完成；
2. 工具（tools）：把模型输出映射为真实操作——文件读写、执行命令、调用 API。Claude Code 的每个工具调用都要经过权限检查，模型无法绕过；
3. 上下文管理（context management）：决定每轮往有限的上下文窗口里放什么——检索、压缩、技能按需加载、子代理（subagent）隔离上下文。上下文管理被称为”好 harness 与坏 harness 的分水岭”：Anthropic 曾把工具定义改为按需发现后，单个任务上下文从 15 万 token 降到 2000 token；
4. 护栏（guardrails）：权限系统、批准门（approval gates）、成本上限、失败重试与回滚——决定 agent 在无人监督时能做什么、不能做什么。

用操作系统类比：模型是 CPU，harness 是操作系统。 CPU 再强，没有操作系统就只是一块硅片；模型再聪明，没有 harness 就只能在单轮对话里打转。这也回答了”为什么光有前沿模型还不够”：让一个强模型裸跑长任务，它会出现上下文溢出、权限失控、提前宣布完成（Anthropic 称之为 agentic laziness，“智能体偷懒”）等系统性失败——这些都不是模型智能不够，而是缺少 harness 的约束与支撑。

其实读者每天都在使用 harness：Claude Code 本身就是一个 agent harness——它的系统提示、工具定义、权限系统、会话记忆、上下文压缩、子代理机制，全部属于 harness 的范畴。你在这台机器上运行的每一个命令，都要经过”模型产生意图 → harness 检查权限 → 执行 → 结果回灌”的循环。

为什么 2026 年 harness 突然成了焦点：NVIDIA AVO#

“最近新出”的感觉是对的——harness 这个词在 2026 年夏天突然出圈，直接导火索是 NVIDIA 的 AVO（Agentic Variation Operators，智能体变分算子）研究，以及围绕它的一个戏剧性对比。

2026 年 8 月，NVIDIA 发布博客称其长时程智能体架构 AVO 在 ARC-AGI-3 基准的公共演示集上拿到 100.00 RHAE（Relative Human Action Efficiency，相对人类动作效率——结合任务完成度与动作效率的评分），完成了 25 个环境里的全部 183 个关卡。关键不在满分本身，而在对照组：同样的基座模型（Anthropic 的 Claude Opus 5）在 ARC 官方评测的不同条件下只得到约 30% RHAE——而 30% 已经是所有裸模型中的最好成绩。也就是说，AVO 没换模型，只是换了 harness（加上持久记忆、监督者组件、执行反馈循环等），就把分数从”最强裸模型”的 30% 推到了 100%。同期还有报道称 OpenAI 内部研究发现，仅调整 harness 的两个设置就能让自家分数翻三倍。

AVO 架构里最能说明”harness 在干什么”的组件是监督者（supervisor）：一个独立的监控组件，观察主 agent 是否陷入停滞或无效循环，一旦发现就跑出来”踢一脚”——把它拉回正轨或建议换策略，NVIDIA 官方把它比作 CEO。此外还有持久记忆（把之前的实现、评测结果、编译输出带进下一轮，让 agent 从当前状态续跑）和 inspect-plan-implement-evaluate-diagnose/repair 的循环。下图是 AVO 的官方架构图：

值得说明的两点事实与一个诚实注脚：

• AVO 不是玩具 demo：它原本是为 CUDA GPU kernel 优化构建的——7 天运行探索了 500 多个优化方向、产出 40 个提交的 kernel 版本，在 DGX B200 上比 FlashAttention-4 最高快 10.5%，同一架构迁移到 ARC-AGI-3 无需领域定制；
• harness 工程（harness engineering）由此成为独立话题：NVIDIA 表示 AVO 不是商业产品，但会以 NeMo 品牌开源 harness 构建模块；“设计环境、约束、反馈与文档让 agent 可靠干活”被当作一门手艺讨论；
• 注脚（重要）：100% 只覆盖 ARC-AGI-3 的公共演示集，不覆盖半私有/私有集；ARC 创始人 François Chollet 明确指出 30%→100% 的对比不是受控消融实验，并批评了宣传口径（NVIDIA 随后在博文加了编辑注）。结论方向（harness 决定长时程任务成败）与具体宣传口径（30 到 100）要分开看待。

一张表收尾：三者的关系#

最终答案：agent 是具体干活的那个系统；agentic AI 是这类系统的总称（相当于”行业”）；harness 是 agent 背后的工程层——没有它，模型只是会对话的模型；有了它，模型才是会干活的 agent。 读者不需要把三个词当成三种不同的产品，它们描述的是同一个事实的三个层次：模型负责想，harness 负责管，agent 负责干，agentic AI 负责定义这个新工种。