机器人零样本进陌生住宅：Figure Helix 2.5发布

【2026.09.19】机器人零样本进陌生住宅：Figure Helix 2.5发布

2026年9月19日 | AI Coding × 具身智能 行业日报

一、Figure Helix 2.5：机器人零样本进陌生住宅做家务，成功率从9%飙到56%

事件内容：9月18日，Figure发布Helix 2.5模型，能让机器人"自主做家务"。Figure在美国旧金山湾区租了30套房子，机器人没有进行额外训练，到了地方就开始自己收拾房子。Helix 2.5的构建旨在回答一个问题——类人生物能否进入一个它从未见过的家，并立即自主工作？为此，Figure在全球人类行为数据集Index上预训练了Helix 2.5。基于这个单一的基础模型，机器人产生了三种行为：整理客厅、折叠毛巾和整理床铺。实测成功率从之前的9%提升到56%。Figure同时承诺投入35亿美元算力资源训练Helix，CEO称这是公司最重要的技术节点。

关注价值：这是人形机器人从"工厂场景"走向"家庭场景"的标志性突破。此前人形机器人的落地主要集中在工厂、4S店、酒店等结构化或半结构化场景，家庭是最复杂的场景——每个家庭的布局不同、家具不同、物品摆放不同，机器人需要零样本泛化能力。Figure的实验设计很有说服力：30套不同的房子、不做额外训练、直接进去干活。成功率从9%到56%，虽然还远不到商用水平，但半年前这个数字还是个位数，提升速度很快。单一基础模型驱动三种行为（整理客厅、折叠毛巾、整理床铺），说明Helix 2.5不是针对每个任务单独训练的，而是学到了通用的家务能力。

个人深度思考：家庭场景是人形机器人的终极战场，也是最难啃的骨头。工厂场景是结构化的——地面平整、物品固定、任务重复；家庭场景是非结构化的——家具摆放千差万别、物品形状各异、地面有地毯和台阶。Figure选择"零样本进陌生住宅"这个测试，直接对准了家庭场景的核心难题：泛化能力。56%的成功率说明机器人已经能做对一半的家务，但还有一半会失败——可能是把毛巾折坏了、把东西放错了位置、或者在复杂地形上卡住了。这个成功率距离商用还有距离（家庭场景要求接近100%，因为没人愿意每天帮机器人收拾残局），但方向是对的。

Figure同时承诺35亿美元算力训练Helix，这个投入规模说明Figure把家庭场景当成了核心战略。35亿美元买10万块GPU，这个算力投入在人形机器人公司中是前所未有的——Figure在用训练大模型的方式训练机器人，这和特斯拉Optimus的路线类似，但Figure更聚焦"大脑"。接下来看两个指标：一是成功率能不能在半年内从56%提升到80%以上，二是机器人能不能处理更复杂的家庭任务（做饭、照顾老人、辅导孩子）。如果Figure能把家庭场景的成功率做到90%以上，人形机器人的商业化天花板会被彻底打开。

二、Claude狂写80%代码，CI半年暴涨25倍：AI原生开发的基础设施瓶颈

事件内容：Anthropic披露内部数据：公司80%代码由Claude生成，工程师季度代码交付量达到2021-2025年均值的8倍。Claude不仅主导编码，还深度参与PR审查与合并批准，显著提升开发效率。但AI高频提交导致CI系统不堪重负——CI（持续集成）系统的负载半年暴涨25倍，暴露出基础设施瓶颈。这标志着开发范式正从"人写代码"转向"AI主写+人协同"，但配套工具链（如CI/CD）尚未适配AI原生开发节奏，亟需重构以支撑高吞吐、自动化软件交付流程。

关注价值：80%代码由AI生成，这个数字比之前报道的"26%研发由AI主导"更有冲击力——26%是AL4级（端到端自主完成）的比例，80%是代码生成比例。这意味着Anthropic的工程师团队，现在的主要工作不是写代码，而是审查AI写的代码。工程师季度交付量8倍于历史均值，说明AI极大地放大了单个工程师的产出。但CI系统半年暴涨25倍，说明AI生成代码的速度已经超过了现有基础设施的承受能力——人写代码时，一天提交几个PR；AI写代码时，一天提交几十个PR，CI/CD系统根本跑不过来。

个人深度思考："CI被AI干崩"是一个很有象征意义的事件。它说明AI Coding的瓶颈已经从"AI能不能写代码"转移到了"基础设施能不能接住AI写的代码"。当AI一天提交50个PR，CI/CD系统需要跑50次构建、测试、部署，这个负载是人类时代的几十倍。传统CI/CD系统是为人类开发节奏设计的——一天几个提交，每次构建跑十几分钟，完全够用。但AI原生开发节奏是一分钟几个提交，CI/CD必须重构。

这个瓶颈对行业意味着什么？第一，CI/CD工具链会迎来一次AI原生重构——需要更快的增量构建、更智能的测试选择（不是每次都跑全量测试）、更并行化的流水线。第二，代码审查流程会变化——人类工程师不可能审查AI一天写的几千行代码，需要AI辅助审查AI（AI Reviewer）。第三，"工程师"这个角色会进一步分化——从"写代码的人"变成"定义需求的人、审查AI输出的人、处理异常边界的人"。Anthropic的80%代码由AI生成、CI暴涨25倍，这些数据会成为所有正在引入AI Coding的企业的预警信号：先把基础设施准备好，再放开AI Coding的缰绳。

三、Figure与Nscale达成35亿美元协议：部署10万块GPU训练Helix

事件内容：Figure与英国AI基础设施提供商Nscale达成多年战略协议，部署多达10万块NVIDIA Vera Rubin GPU。初始承诺总额35亿美元，可扩展至60亿美元以上。这些基础设施将部署在Nscale的数据中心，用于训练和推理Figure的Helix机器人控制模型。这是人形机器人行业迄今为止最大规模的算力采购协议——Figure正在用训练大模型的算力规模来训练机器人模型。

关注价值：35亿美元、10万块GPU，这个数字在人形机器人行业是前所未有的。此前机器人公司的算力投入主要是租用云GPU，规模在几千到几万张卡。Figure直接签10万块GPU的多年协议，说明它把"大脑"当成了核心竞争力，愿意用大模型级别的算力投入来训练机器人模型。NVIDIA Vera Rubin是NVIDIA最新一代GPU，算力远超当前的H100/B200，Figure直接用最新一代硬件，说明它对模型训练的算力需求非常迫切。

个人深度思考：Figure的35亿美元算力协议，标志着人形机器人的竞争正式进入"算力军备竞赛"阶段。此前人形机器人公司的竞争主要在硬件层面——谁的本体更便宜、谁的关节更灵活、谁的续航更长。但随着Helix 2.5证明"大脑"才是家庭场景的关键瓶颈，竞争重心正在向算力和模型转移。Figure的逻辑很清晰：家庭场景的泛化能力需要海量数据+巨大算力来训练，和大模型的训练逻辑一样。谁有更多算力，谁就能训练出更强的机器人模型，谁就能在家庭场景竞争中胜出。

但35亿美元的投入也有风险：如果Helix模型的训练效率不高，10万块GPU可能也不够用；如果机器人硬件成本降不下来，模型再强也没有载体。Figure的赌注是"大脑优先"——先把模型做到最好，硬件可以后补。这个赌注能不能赢，取决于Helix模型能不能在家庭场景中持续提升成功率。接下来看Figure会不会公开Helix模型的训练数据量和训练方法，以及其他机器人公司（特斯拉Optimus、智元、宇树）会不会跟进大规模算力采购。如果人形机器人行业的算力投入从"万卡级"跳到"十万卡级"，说明这个行业的竞争已经和大模型行业同质化了。

四、OpenAI开源Symphony：自主编码Agent编排器，用issue tracker做控制计划

事件内容：OpenAI开源Symphony，一个自主编码Agent编排器。Symphony使用项目管理工具（如issue tracker）作为控制计划来协调多个编码Agent。开发者不再管理交互式编码会话，Symphony管理"任务"——将每个任务分配给专门的Agent，Agent自主工作到完成。任务完成后，人类负责审查输出。Symphony的设计理念是：把软件开发从"人坐在终端前和AI对话"变成"人在issue tracker里写任务，AI Agent自主完成，人审查结果"。

关注价值：Symphony代表了AI Coding的一个重要方向：从"交互式编码"走向"任务式编码"。此前的编码Agent（Claude Code、Cursor、Codex）主要是交互式的——开发者在终端里和AI对话，一步步引导AI写代码。Symphony把这个模式反过来：开发者只需要在issue tracker里写清楚任务描述，Symphony自动把任务分配给Agent，Agent自主完成，人只在最后审查。这和Claude Code的多Agent重构方向一致，但Symphony更进一步——它不只是在一个项目里并行多个Agent，而是把整个开发流程变成了"任务队列+Agent执行+人类审查"的异步模式。

个人深度思考：Symphony的开源很有意义。它把"Agent编排"这个能力从Claude Code、Cursor等商业产品中抽出来，变成了一个开源的基础设施。任何团队都可以基于Symphony搭建自己的Agent编排系统，不需要绑定某个商业产品。用issue tracker作为控制计划，也是一个很务实的设计——开发者已经习惯了在Jira、GitHub Issues、Linear里管理任务，Symphony不需要改变开发者的工作流，只需要在任务后面接上Agent执行能力。

但Symphony也有局限：它解决的是"任务分配和执行"的问题，但没有解决"任务质量"的问题。如果issue写得不清楚，Agent做出来的东西就不对；如果Agent完成的任务有Bug，人类审查的负担就很重。接下来看Symphony的社区活跃度——如果有足够多的开发者基于Symphony构建工具链，它可能成为Agent编排的开源标准。同时看OpenAI自己会不会用Symphony来编排内部的编码Agent，以及Symphony和Claude Code的多Agent功能是什么关系（竞争还是互补）。Agent编排正在从"产品功能"变成"基础设施"，这个趋势对整个AI Coding行业都有影响。

五、Claude Code支持AGENTS.md：跨工具通用项目规则标准

事件内容：从Claude Code 2.1.277版本开始，如果文件夹中没有CLAUDE.md，Claude将检查并使用AGENTS.md。用户可以在/config中切换此行为。CLAUDE.md是Claude Code特有的工作流、MCP、Sub-agent或命令配置；而AGENTS.md的目标是让不同工具共享项目级基础规则，可视为所有AI都应该遵守的通用规则。这意味着AGENTS.md正在成为跨AI编码工具的通用项目规则标准——一个文件写好，所有AI编码工具都能读取。

关注价值：AGENTS.md的出现解决了一个实际痛点：每个AI编码工具都有自己的项目配置文件（Claude Code用CLAUDE.md，Cursor用.rules，Codex用AGENTS.md），开发者需要在多个文件里重复写同样的规则。AGENTS.md试图成为一个通用标准——开发者只需要写一份AGENTS.md，所有支持这个标准的AI工具都能读取。这和编程语言中的README.md、Makefile类似——不是某家公司的私有格式，而是行业通用约定。

个人深度思考：AGENTS.md成为跨工具标准，对开发者是好事——不需要在多个AI工具之间重复配置项目规则。但对AI工具厂商来说，这是一个微妙的博弈：谁都想让自己的私有格式成为标准，但又都需要一个通用标准来降低开发者的使用成本。Claude Code主动支持AGENTS.md，说明Anthropic意识到了这个趋势——与其让开发者维护多个配置文件，不如拥抱通用标准，降低迁移成本。这和当年Markdown成为通用文档格式的过程类似——不是某家公司推广出来的，而是开发者社区自然形成的共识。

接下来看Cursor、Codex、Windsurf等其他AI编码工具会不会跟进支持AGENTS.md。如果主流工具都支持，AGENTS.md就会成为AI编码时代的"Makefile"——每个项目根目录都有一个，定义AI应该遵守的规则。这对AI编码工具的竞争也有影响：当项目规则标准化后，AI工具之间的差异化会更多体现在模型能力和Agent编排上，而不是配置格式上。AGENTS.md的标准化，本质上是把AI编码工具的竞争从"锁定开发者"推向"模型能力竞争"。

六、宇树发布UnifoLM-ER-1-4B：7项具身推理评测领先开源模型

事件内容：宇树发布通用人形机器人模型UnifoLM-ER-1-4B，其具身推理底座在16项多模态感知与理解基准中，有7项领先参评开源模型，整体结果与多款闭源模型处于相近水平。项目当前已开放部分模型权重和数据，其他模型、代码与数据仍在后续开放计划中。这组结果显示，宇树在具身空间感知与推理方面进入开源模型前列。随着模型权重和数据逐步开放，开发者可以基于UnifoLM-ER进行机器人感知和推理的二次开发。

关注价值：宇树做人形机器人本体起家，现在开始发布具身推理模型，说明宇树正在从"本体公司"向"本体+大脑"全栈公司转型。UnifoLM-ER-1-4B只有4B参数，是一个轻量级模型——不是那种千亿参数的大模型，而是面向机器人端侧部署的小模型。4B参数意味着可以部署在机器人本地，不需要依赖云端推理，这对实时性要求很高的机器人控制很重要。7项评测领先开源模型，说明宇树的具身推理能力已经达到了开源第一梯队水平。开放部分模型权重和数据，也是一个积极信号——宇树在尝试通过开源建立生态。

个人深度思考：宇树的UnifoLM-ER-1-4B代表了具身智能模型的一个趋势：端侧小模型。和Figure用35亿美元训练云端大模型不同，宇树走的是另一条路——用4B的小模型在端侧完成具身推理。这两条路线各有优劣：云端大模型能力强，但延迟高、依赖网络、成本高；端侧小模型延迟低、不依赖网络、成本低，但能力上限受限于模型大小。对人形机器人来说，端侧推理是刚需——机器人不能在移动时等云端推理几秒钟，实时控制需要毫秒级响应。

宇树选择开源部分模型权重和数据，也是一个聪明的生态策略。当前具身智能的开源生态还很早期，如果宇树的UnifoLM能成为具身推理的开源标准，会吸引大量开发者和合作伙伴，形成生态壁垒。接下来看UnifoLM-ER的实际部署效果——4B小模型在真实机器人上的表现如何，能不能支撑复杂的空间推理和任务规划。如果端侧小模型的能力接近云端大模型，人形机器人的商业化成本会大幅降低——不需要为每个机器人配上昂贵的云端推理服务。

七、JetBrains Junie /demo：让Agent测试功能并生成视频报告

事件内容：JetBrains发布Junie /demo功能：让Junie测试应用中的功能，观看它工作，并审查视频、截图和HTML报告。开发者在IDE中调用Junie /demo，Agent会自动启动应用、模拟用户操作、执行测试场景，然后生成一份包含视频回放、截图和HTML报告的测试结果。这意味着开发者不需要手动点击测试功能，Agent可以自动完成测试并生成可分享的报告。

关注价值：测试是软件开发中最耗时的环节之一。传统的测试方式要么是手动点击（慢且容易遗漏），要么是写自动化测试脚本（前期投入大、维护成本高）。Junie /demo的思路是：让AI Agent像人类用户一样操作应用，自动完成测试场景，然后用视频和截图记录整个过程。这比写自动化测试脚本灵活得多——Agent不需要预先知道应用的界面结构，它像人一样看屏幕、点按钮、验证结果。生成的视频和HTML报告也方便分享和审查。

个人深度思考：Junie /demo代表了AI Coding的一个新方向：从"写代码"扩展到"测代码"。此前的AI编码Agent主要辅助开发者写代码，但测试环节一直是空白——写完代码后，还是需要开发者手动测试或写自动化测试脚本。Junie /demo让Agent自动测试并生成报告，补上了这个空白。视频报告的形式也很聪明——不是冷冰冰的测试通过/失败，而是用视频展示Agent实际操作了什么、在哪里出了问题，开发者一看就明白。

这个功能的实际价值取决于两点：一是Agent能不能像人类用户一样准确地操作应用（找到按钮、输入文本、验证结果），二是视频报告的可审查性有多高（能不能精确定位Bug、能不能区分"应用Bug"和"Agent操作错误"）。如果这两点都能做好，Junie /demo可能会改变软件开发的测试流程——开发者写完代码后，不再需要手动点一遍，直接让Agent跑一遍/demo，看视频报告就行。接下来看JetBrains会不会把这个能力开放给其他AI编码工具使用，以及GitHub Copilot、Cursor等竞品会不会跟进类似功能。AI Coding的竞争正在从"写代码"向"全流程覆盖"扩展——写代码、审代码、测代码、部署代码，每一个环节都在被AI重构。

本期完。

AI Coding × 具身智能 行业日报 | 每日自动采集、筛选、改写、排版