具身智能会复制 Agent 的产业分工吗？从 PI 的新 API 说起
看完 PI 刚发布的机器人 API，我最先想到的是一个关于产业分工的问题：未来的机器人公司，还需要各自从头训练一套基础模型吗？
如果一家团队能够调用外部模型，用自己的数据完成适配，再把它部署到工厂、仓库或厨房，那么具身智能的产业结构，是否会逐渐接近我们今天看到的 Agent 生态？
模型公司提供可复用的基础能力，应用公司围绕具体场景，把能力变成可以交付的系统。我觉得，PI 这次发布已经给了我们一个讨论这种分工的具体入口。
沿着这个问题，我也看了 Generalist AI 的 GEN‑1.5、Google 的 Gemini 4 Argon 和 OpenAI 的 GPT‑6 家族，以及最近 DeepSeek 考虑进入具身领域的报道。我想结合这些案例，讨论具身模型公司将来可能处在什么位置，下游团队又会积累怎样的价值。
我的一个初步判断是：具身领域有机会形成类似 Agent 的分工，但物理世界的数据、硬件和运行约束，会让这种分工保留自己的特点。
10 月 13 日，PI 宣布开放最新模型的训练和推理服务。开发者上传自己的机器人数据，在 PI 管理的算力和基础设施上启动微调，再通过托管网关运行模型。测试版目前仍是小规模、分批接入。https://www.pi.website/blog/api-beta(PI 官方公告)、https://www.pi.website/waitlist(Beta 申请页面)
我想先从机器人任务的迭代方式说起，这样更容易理解这套 API 在改变什么。
一个“把物品放入箱子”的任务，在现实中会不断变形：物品位置变化、包装材质不同、抓取失败、遮挡、相机视角变化。第一次训练完成，通常只是后续工作的起点。团队需要测试机器人，找到失败模式，补采示范数据，再训练、再测试。
我的判断是，PI 这次 API 发布最重要的产品变化，是让外部团队能够自己运转这条迭代链。
过去，一家机器人公司即使能够拿到基础模型，也需要处理训练基础设施、数据适配和推理服务。如果改进任务还要等待模型供应方的研究人员排期，业务迭代就会受到额外限制。把这些环节做成服务，可能缩短的是从一次现场失败到下一版策略之间的时间。
我从 PI 公告里挑了几个案例，它们让我对这种分工有了更具体的理解：
Chef Robotics：团队用前一天采集的 33 次双臂示范训练汉堡组装模型，第二天就在机器人上运行，无需自行运行训练过程。
Foundry：上传约 500 次发动机装配示范，第二天开始在工厂车间测试托管的微调模型。
Deft：在零件上料任务中，六天内将成功率提升到原来的两倍以上，每晚自行通过 API 训练新模型。
这些数字来自 PI 官方网页中的合作伙伴案例介绍。它们说明外部团队能够开展迭代，但没有统一的测试协议，也不意味着任何新任务都能在一天内上线。
读这些案例时，我也会把两个里程碑分开：得到“可以开始测试的模型”，与得到“可以长期稳定运行的系统”，是两个不同的里程碑。上料成功率翻倍，也仍需要知道原始成功率、评估次数、物料分布和人工接管条件，才能判断生产价值。
因此，我认为 PI 的行业意义，首先体现在分工方式上：模型供应方提供可持续更新的基础能力，应用团队围绕自己的硬件、场景和数据，承担任务验证与现场改进。API 能否把这种分工规模化，还需要更多部署结果来检验。
02｜基础模型的价值，最终要体现在适配成本上
在我看来，机器人基础模型的吸引力，在于已经学到的知识能否被新任务复用。若每换一个场景，都必须重新采集大量数据、投入漫长训练，那么“通用”的实际价值就会受到限制。
PI 在今年 4 月的 π₀.₇ 工作中，给出了一种值得关注的做法：在训练时，用语言、速度与质量等元数据、控制方式标签和视觉子目标，描述任务以及执行方式，帮助模型利用来源和行为质量不同的数据。PI 报告了技能组合与跨机器人迁移的初步结果。π₀.₇ 技术介绍
我理解这项做法，可以从一个直观的问题入手。两段数据可能都在“拿起物体”，但一段追求速度，一段强调精细操作；一段是成功示范，另一段包含低质量动作。如果没有足够上下文，简单混合这些数据，模型接收到的学习信号可能含糊甚至冲突。
给数据增加条件信息，相当于为它标明“这是在什么要求下采取的行为”。我的理解是，这为复用更复杂的真实数据提供了一个方向，也提醒应用团队：数据工程需要记录动作背后的条件与结果。
不过，API 公告没有明确披露当前服务的底层模型版本，不能直接把 π₀.₇ 的实验成绩当作 API 的能力承诺。技术研究说明了发展方向，具体产品能力仍应通过目标任务评估。
我还注意到 PI 公告中的另一个案例。Ultra 在一次迭代中删掉了过多动作较慢的片段，将训练数据缩减到约 12 小时，结果得到的模型反而难以通过提示指令引导。https://www.pi.website/blog/api-beta(Ultra 案例)
这让我更愿意把数据看成一种“覆盖能力”：所谓慢片段，可能承载了任务中的等待、调整或其他行为变化。仅凭这一个案例，还无法确定性能退化的具体原因；它至少说明，删除看起来低效的片段，需要用实机评估验证收益。
03｜Generalist 把问题推进了一步：任务适配能否发生在上下文里？
带着“能否减少任务适配成本”这个问题，我接着看了 Generalist AI。它是另一家机器人基础模型公司，与 PI 合作伙伴名单中的 General Instinct 并非同一家公司。
8 月 19 日发布的 GEN‑1.5，探索的是另一种任务适配方式：把一段示范放入模型上下文，不更新参数，直接尝试执行任务。这里的“物理提示”通常包含感知与动作序列，并不等同于随便给机器人看一段普通视频。https://generalistai.com/blog/gen-1.5(GEN‑1.5 官方研究介绍)
根据 Generalist 公布的结果，在 10 个简单、短时程任务上，使用 3—12 秒的单次示范进行上下文提示，平均成功率为 59%；使用每个任务五分钟的数据、进行十步梯度更新后，平均成功率提升到 83%。这两种适配方式需要区分，后者确实进行了微调。https://generalistai.com/blog/gen-1.5
我理解这项工作的技术含义，是新任务的信息可以通过不同入口交给模型：既可以写入参数，也可以放进当前上下文。基础能力若足够丰富，一段示范可能就能让模型调用已有知识，尝试新的行为。
但我也不会忽略 59% 这个数字：从“一次示范后产生有效行为”，到“可靠完成生产任务”，仍有很大距离。
我更愿意把 GEN‑1.5 看成降低任务适配门槛的研究信号。它可能帮助团队更快建立初始策略、验证任务是否可行；真正部署时，还要继续评估稳定性、错误恢复和运行成本。
把 PI 和 Generalist 放在一起看，我觉得这两条路径可以并行发展：一条路径把微调与部署流程做得更易用，另一条路径探索减少甚至省去部分任务微调。现有证据并不能证明谁会替代谁，也不能拿 PI 的客户案例与 Generalist 的受控实验直接比较成功率。
同样在 10 月 13 日，Google 宣布扩大 Gemini 4 Argon 的可用范围，开放面向开发者和企业的 API，并在部分订阅产品中提供访问。Google 将其重点放在复杂工程与专业工作流程上。官网链接： https://blog.google/innovation-and-ai/models-and-research/gemini-models/introducing-gemini-4-argon/
相比展示从零生成一个漂亮应用，我更关注 Google 同日公开的 ADK 优化案例：它处理的是既有代码库中的性能问题，而且公开了人工审查过程。
据 Google 报告，Argon 持续运行 11 小时，提出六项优化；维护者最后采纳两项、拒绝四项。采纳后的变化使长会话中的内存会话准备开销降低约 40%，冷启动包导入耗时降低 21%。这些指标不代表模型推理提速 40%，也不代表任意 Agent 的总耗时下降 40%。
相关代码已有公开提交，读者可以查看改动及提交说明。代码存在与性能数字获得独立复现，是两种不同层次的证据。ADK 公开提交： https://github.com/google/adk-python/commit/1754b3eeb6cdb2c16e3b30619a12066623df132e
我认为，这个案例中最值得学习的，是把模型的探索能力与人类的验收责任接了起来。六项方案中，只有两项留下来，恰恰说明“会提出方案”与“方案适合现有系统”之间需要审查。
如果把这种工作方式放到工程团队里，我觉得可以将一部分问题定位、候选方案探索和验证工作交给 Agent，同时把兼容性、维护成本与上线标准写清楚。最终收益来自通过验收的改动，而不是模型生成了多少代码。
我觉得，这也为机器人团队提供了一种值得借鉴的组织思路：扩大模型可尝试的空间，同时建立可检查的结果与明确的接管机制。软件审查和实机验证当然不能互相替代，但两者都需要回答同一个问题——一次看起来不错的结果，是否满足实际工作的标准？
05｜GPT‑6：持续工作的 Agent，需要模型与运行系统一起进步
讨论 GPT‑6 时，我先明确一下这里指的是一个模型家族。OpenAI 当前文档将 Astra 面向高难度工作，将 GPT‑6.1 Sol 定位于能力与成本的平衡，将 Luna 面向成本敏感的高频任务。OpenAI 模型目录： https://developers.openai.com/api/docs/models
更值得联系到具身产业分工的，是 GPT‑6 的工作流接口：官方指南列出了异步工具调用、执行中追加用户指令，以及保留缓存的推理配置调整。异步调用仍由应用执行工具并管理结果；中途追加指令需要相应的连接与状态处理。
关注这些接口，是因为它们处理了持续执行中的协调问题。一个任务可能同时包含资料检索、代码运行和文件处理；某个工具执行较慢时，系统需要管理等待中的工作。用户临时修正要求时，也希望已经完成的有效工作能够继续使用。
基于以上的信息可以有如下判断，Agent 的产品能力，会越来越依赖模型、工具接口和运行状态管理的共同设计。单次回答质量依然重要，但它不足以描述一个系统在长任务中如何处理等待、错误和需求变化。
这让我重新回到 PI 的 API：基础模型通过接口进入工作流程，应用团队负责把它接到自己的系统里。我从这些案例中看到了一种可讨论的分工方向，但这还不能说明数字 Agent 的模型与接口已经可以直接用于可靠的机器人控制。
最近关于 DeepSeek 的消息，让我觉得这个问题更值得讨论。
10 月 12 日，凤凰网科技援引多位信源报道，梁文锋近期与具身智能创业者交流，正在评估 DeepSeek 是否进入这一领域，可能的方式包括自建团队或通过投资切入。这仍是基于知情人士的媒体报道，我会将它理解为“考虑入局”的动向，不能据此认定 DeepSeek 已经推出具身模型，或确定了最终路线。
不过，它把一个问题摆到了我面前：如果 DeepSeek、OpenAI 这样的通用模型公司进一步投入物理世界，未来的具身基础能力，会不会也集中到少数模型供应商手里？
我倾向于认为，“基础模型能力逐步共享，场景适配与交付更加专业化”，会是具身智能的一条重要发展路径。PI 开放训练与推理 API，已经提供了一个可观察的起点。Generalist 探索少量示范适配，则让我看到降低下游使用门槛的另一种可能。这些案例还不足以证明产业格局已经确定。
基座模型公司，可能负责哪些能力？
如果通用模型能够在更多机器人、任务与环境之间迁移，我预计会有一部分公司长期投入大规模数据、预训练、多模态理解、动作生成与后训练，并提供稳定的版本、评估和部署工具。
应用团队就可以围绕已有模型开展研发，把更多资源用在自己的任务上。服务形态也可能不同：托管 API 适合一些团队，开放权重、本地推理或合作部署，可能更适合另一些团队。基础能力集中，并不必然意味着所有机器人都要实时连接同一个云端服务。
我也认为，DeepSeek、OpenAI 这类公司存在掌握部分核心具身模型能力的可能。它们已有的大模型研发体系，可能帮助它们进入感知、推理和任务规划等环节。但要进一步掌握动作生成与接触控制，仍需要物理交互数据、实机经验和相应的训练与评估体系。语言或数字任务上的优势，无法直接回答这些问题。
因此，我不会预先认定现有大模型公司必然胜出。在我看来，决定核心能力归属的一个关键变量，是谁能持续获得高质量的物理数据，并把它转化为跨任务、跨硬件可复用的能力。
PI、Generalist 这样的公司，如何保持自己的位置？
如果通用大模型公司进一步进入，PI、Generalist 这样的具身模型公司，需要让自己的价值体现在物理任务的实际表现上。
我认为，它们可能继续承担基础模型供应商的角色，优势来自物理数据、动作学习、跨本体迁移和实机评估；也可能与通用模型公司合作，将上层理解与规划能力接入自己的动作模型和部署体系。这些只是我对可能路径的推演，目前案例并不能确定具体公司的选择。
我会关注的是，它们能否让下游团队用更少数据、更短迭代周期，完成更多可靠的任务。PI 的 API 让客户自己训练与迭代，在这个意义上，也是在尝试把模型公司的位置从项目支持，推进到可重复使用的基础能力服务。
下游公司，仍然需要积累什么？
如果基础模型越来越容易获得，我认为场景公司的工作会更加清晰：调研真实需求，选择任务与硬件，采集和治理数据，进行模型适配与系统集成，再对稳定运行和客户交付负责。
一个仓储项目要处理的，既有抓取，也有库存信息、箱体差异和异常订单；一个工厂项目还要满足节拍、设备接口与维护要求。知道任务怎样失败、失败造成什么影响，以及应该补充什么数据，本身就是重要的工程知识。
我更看好能够持续形成场景数据、评估方法和交付经验的下游团队。基础模型进步，可以降低一部分算法与训练门槛，同时也会让客户更加关注系统能否长期运行。调用 API 是起点，完成这条链路才是应用公司的业务。
这种分工，会比 Agent 更紧密地连接模型与现场
我觉得，具身会形成类似 Agent 的专业化分工，但模型层与应用层之间的数据往来可能更加关键。
机器人之间的运动范围、夹爪、传感器和控制方式不同；现场的摩擦、遮挡、磨损和网络条件，也会影响结果。模型供应方需要下游反馈来理解这些问题，下游团队则需要基础能力与部署工具持续改进。低延迟控制和断网运行，还可能要求部分能力留在本地。
由此，我更愿意把未来想象为一个协作网络：基础模型公司、硬件与控制公司、场景公司各有侧重，通过合作把模型迭代与现场改进连接起来。其间还需要明确客户数据权限、模型更新责任与评估标准。最终数据如何流动、价值如何分配，不会仅由模型能力决定。
回到 PI，这次发布最吸引我的，是它让我看到了这种分工的雏形。DeepSeek 的具身动向，则让“大模型公司会走到哪里”这个问题变得更加具体。
如果具身逐渐形成“基座模型＋场景落地”的生态，我认为上游的竞争会集中在能力的复用范围与适配效率，下游的竞争会集中在场景理解、数据和交付。两端都要用真实工作中的表现证明自己的价值。
Mbot具身智能实验室
让尖端科技触手可及，人人皆可探索未来
Mbot基础交流群等你加入，下方扫码联系
具身-杰西
Mbot具身-小助手
Mbot-视频号
Mbot-公众号
热门跟贴