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 下一站”的故事。