← 返回文章

Agent 向左,具身向右:AI 在信息空间与物理世界的分岔

它们共享模型与规划能力,却分别受数字世界的可逆性和物理世界的不可逆后果约束。

一段代码写错了,可以回滚;一封邮件发错了,还能补充说明;数据库被误改,日志和备份能救回来。机械臂碰坏一个物体,损失已经发生;移动机器人撞到人,不能靠“重试”恢复;设备电量耗尽停在危险位置,问题不只是任务失败,还可能引入新的风险。

这条线就是 Agent 与具身智能的分界线:系统是否直接承担现实世界里的不可逆后果。Agent 主要改变信息世界的状态;具身系统直接改变物理世界的状态。状态不同,错误能否撤销、系统如何评测、安全责任如何划分、产品怎样部署、公司如何规模化,全都随之分岔。

这条分界线今天特别容易被抹掉,因为有一个流行的故事把两者缝在一起:模型越来越强,AI 开始理解环境、规划步骤、调用工具——所以具身智能是 Agent 的下一站,机器人就是给 Agent 装上一副身体。

这个故事的前半句是真的,后半句是错的。

它们确实有一段相似的过去

在信息世界,自动化先从脚本和固定规则开始:RPA 按预配置的步骤点击界面,传统软件按明确流程处理输入。模型能力上来之后,Copilot 参与局部工作,再往前一步,Agent 理解目标、选择工具、执行多步操作并根据结果继续调整。

在物理世界,自动化也曾依赖固定程序和结构化环境:工业机器人在确定的位置、节拍和安全边界内重复动作。后来视觉感知、学习控制和策略模型逐步提高了系统处理变化的能力——RT-2 把视觉、语言与机器人动作放进同一模型,Open X-Embodiment 尝试用跨机器人数据提高策略迁移,Google DeepMind 的 Gemini Robotics 也把泛化、交互和灵巧操作列为机器人模型的关键能力。

两条路线的共同变化确实存在:环境不再需要被完全预定义;系统开始理解自然语言和多模态上下文;系统不只给建议,还会选择并执行动作;动作之后会读取反馈再决定下一步。从模型能力看,Agent 调用 API,机器人调用运动控制器;Agent 读取网页和数据库,机器人读取摄像头、深度信息和关节状态。

但共同的模型能力,不等于共同的产品规律。

分岔发生在哪里

Agent 处理的通常是文件、代码、消息、日程、数据库、账户和业务流程;具身系统处理的是位置、姿态、物体、空间、能量和人与设备之间的安全关系。

数字世界当然也有不可逆操作——转账、公开发布、数据删除——但软件通常能通过权限、沙箱、版本、日志和人工审批,把高风险动作单独隔离出来。物理世界的错误更难被这样抽象掉,而且一个在 Benchmark 上表现很好的模型,并不自动等于一个可以持续交付的机器人产品:模型只是物理闭环中的一层,传感器、状态估计、控制、结构、执行器、能耗、安全、维护与异常恢复必须同时成立。

沿着这条分界线,两条路线会在八个维度上越走越远:

维度 AI Agent 具身智能 / 机器人
主要操作对象 文件、消息、代码、账户、数据库与业务状态 位置、物体、空间、能量与人的安全边界
错误可逆性 多数操作可回滚、重试、补偿或转人工 物理后果可能即时发生,部分错误不可逆
复制与扩张 软件可快速分发,同一套能力服务大量用户 每增加一个执行单元,都要生产、部署和维护实体设备
数据闭环 操作日志天然产生,反馈成本相对较低 真实数据采集昂贵,且受本体、环境和任务差异影响
评测环境 可以用测试集、沙箱、历史任务和数字孪生反复运行 必须面对真实摩擦、遮挡、磨损、时延和环境长尾
安全与权限 重点是数据、账户、合规、越权与错误执行 还要处理碰撞、力、稳定性、故障与人身安全
部署与运维 版本可以集中更新,问题能够快速回滚 涉及硬件版本、备件、充电、维修、现场支持与寿命
单位经济 主要受推理、软件服务和人工复核成本影响 还要承担 BOM、制造、渠道、库存、售后与现场服务

这张表不意味着 Agent 一定简单、机器人一定缓慢——金融、医疗、企业核心系统里的 Agent 同样可能面临极高的错误成本;扫地机这类高度收敛的机器人产品已经大规模商业化。它意味着的是:不能用一条路线的速度和成功标准,去推断另一条。

Agent 这边:竞争落到任务交付

当基础模型逐渐成为可替换的公共能力,Agent 产品的差异不再来自“模型更聪明”,而来自它是否真的接入了一套任务系统。一套可用的 Agent 至少要解决五件事。

它理解的是任务,不是一句提示词。“生成一份报告”不是完整任务,还要说明报告给谁看、支持什么决定、用哪些材料、什么结果算完成、失败后怎么处理。更长的 Prompt 解决不了这些,Agent 需要的是一份清楚的结果契约。

它的权限边界是产品的一部分。工具越多不等于能力越强。Agent 一旦接入邮件、代码库、支付、客户数据和内部系统,“能访问什么、不能访问什么”就必须成为显式设计:低风险操作自动执行,高风险操作需要确认;只读、建议、起草、提交和正式执行,应当是不同权限等级。

过程要留下可检查的状态变化。可靠的 Agent 不应只给最终答案,还要让用户知道它读取了什么、依据什么判断、改变了哪些对象、哪些步骤失败、哪里需要人工介入——这也是当前 Agent 开发框架开始强调工具、Guardrails、Tracing 和可观测性的原因:产品管理的是整条任务执行链,不是一段对话。

错误要能被发现、回滚和补偿。数字世界可以建立版本、Diff、日志、沙箱和审批机制,产品应该主动利用这些特性,而不是让模型直接操作所有系统。

人在什么时候接管要写清楚。Human-in-the-loop 不是一句安全口号:什么置信度继续执行,什么动作必须确认,出现什么异常立即停止,用户如何快速理解现场并接管——这些都要有明确答案。

所以 Agent 的长期竞争,更像“任务交付系统”的竞争:谁拥有更完整的上下文、更合理的工具与权限、更清晰的结果契约、更低成本的异常处理。

具身这边:竞争发生在持续可靠的物理闭环

具身智能也需要更好的模型,但模型能力必须进入一条更长、约束更多的系统链路。一个机器人完成任务,要连续处理感知环境、判断状态、理解意图、规划动作、控制执行、检查结果、处理异常——任何一环不稳定,最终任务都可能失败。

而它面对的是一个持续变化的世界:物体会滑动,人会突然进入,光照会改变,地面摩擦有差异,传感器会被遮挡,执行器会发热,零件会磨损。这也是机器人安全天然要分层的原因:高层模型可以理解任务和语义风险,底层仍然需要碰撞避免、接触力限制、动态稳定和针对具体本体的安全控制——Google DeepMind 在 Gemini Robotics 的公开说明中,就把低层安全控制与高层语义理解明确分开处理。

对具身产品来说,一次 Demo 成功远远不够,有意义的指标是:在明确环境里连续多少次完成任务;遇到哪些变化会失败、失败是否可恢复;多久需要人工介入一次;一次任务的时间、能耗和服务成本;设备在数周、数月使用后是否仍可靠;出故障时用户和服务团队能否快速定位修复。

因此具身智能早期更适合从边界清楚的窄任务长出来:环境相对清晰、任务重复、价值足够高、失败可以被安全处理。先把一个物理任务稳定做成,再逐步扩大环境和任务边界,通常比一开始追求“通用机器人”更接近产品现实。

商业化速度不能互相套用

Agent 产品可以软件分发:一次能力更新同时服务大量用户,新工具通过 API 接入,任务数据在使用中持续产生。机器人每扩大一份收入,往往要多生产、交付、维护一台设备,规模增长同时带来制造、供应链、现场部署、维修和客服压力;即使模型可以在线升级,身体仍受既有传感器、算力、结构和执行器的限制。

验证顺序也不同:Agent 更容易先验证“有没有人愿意把任务交给它”;机器人必须同时验证“任务有价值、系统做得到、长期交付得起”。所以不能因为 Agent 几个月就进入大量工作流,就推断通用机器人会以同样速度进入家庭和企业;也不能因为机器人商业化更慢,就认为它的长期价值更低。

会合流,但不会变回一条路

未来很多完整任务会同时包含信息行动和物理行动。比如一套现场巡检系统:Agent 读取工单、理解设备历史、规划任务、调度机器人、整理异常证据并生成报告;机器人负责移动、观察、测量和现场操作。

两者能否协作,取决于一份清楚的任务协议:目标是什么,允许采取哪些信息与物理动作,成功、失败和异常如何定义,哪些条件必须停止,什么时候请求人工接管,最终留下什么证据。Agent 与机器人会协作,但仍由两套不同的工程、产品和运营系统支撑——前者负责理解、协调和管理信息状态,后者负责安全、可靠地改变物理状态。

这个区分怎么用于产品判断

判断一个 Agent 产品,先问:它替用户完成的是哪一段真实工作?需要接入哪些数据、工具和权限?什么结果算完成、如何评测?哪些动作可以回滚、哪些必须审批?人工介入发生在哪里、成本多少?

判断一个具身产品,继续问:它在什么环境、面对什么对象、完成什么高频任务?当前本体和模型能否形成持续闭环,而不只是完成一次演示?最危险、最常见、最昂贵的失败分别是什么?设备如何充电、维护、恢复和升级?把制造、部署和服务算进去,单位经济是否成立?

跳过这个区分,判断就常常出错:模型能力的迁移被看得太快,产品仍需补齐的系统能力被看得太轻。

Agent 与具身智能共享模型、自然语言、多模态和规划能力,也会在越来越多任务中彼此连接,但不会收敛成同一种产品。Agent 向左,进入更深的信息上下文、工具权限与组织工作流;具身向右,进入更复杂的物理环境、可靠性、安全与交付系统。判断它们时,应该先看各自能否持续交付任务,而不是把每一次模型进步都装进同一个“AI 下一站”的故事。


延伸资料