同一画面，两种动作：多模态 Agent 如何验证状态是否足够

先看两个合成工程场景。它们不是公开事故，也不是作者实测。

机械臂在两次测试中看到几乎相同的 RGB 画面：夹爪已经合拢，杯子位于指尖之间。策略都准备"向上抬升"。第一次杯子被稳定拿起；第二次杯子刚离开桌面就滑落。像素没有告诉系统的是：第二次接触力不足、杯身仍在下滑，而且上一条闭合命令尚未执行完成。

语音 Agent 在两段会话中都收到同一句 ASR 文本："好的"。第一段里，TTS 已播放完，没有待执行工具，这句话只是确认听见；第二段里，TTS 仍在播放，用户正在打断，后台还有一个等待二次确认的支付调用。"好的"在两个场景中对应的安全动作完全不同。

这两次失败有同一个根因：系统把当前能看到的 Observation ，误当成了此刻足以决定动作的 State。

本文只回答一个问题：

当两个场景拥有近似相同的画面或文本，却应该执行不同动作时，团队如何判断多模态 Agent 掌握的状态是否足够？

核心结论是：状态不是一个越大越好的字段集合，而是一项相对于任务、动作和未来时域的充分性假设。验证它的最好方式，不是检查 Prompt 塞了多少上下文，而是主动构造"观测相同、隐藏条件不同"的成对场景，看系统能否发现不确定性、等待关键证据，并依据真实执行回执修正下一步。

一、机器人抓取：同一张图为什么对应两个动作

把开头的抓杯过程展开，两次决策的差异会非常具体。

决策时刻的信息	场景 A：可以抬升	场景 B：不能抬升
RGB 画面	夹爪合拢，杯子位于指尖之间	几乎相同
接触力	已达到稳定阈值	偏低且波动
杯体相对速度	接近零	仍在缓慢下滑
闭合命令回执	`executed`	`accepted`，尚未完成
控制器状态	允许进入抬升阶段	仍处于夹持建立阶段
安全动作	向上抬升	保持、重新夹持或停止

如果策略只读当前图像，它会把两个场景压成同一个输入。增加更大的视觉模型也不一定能解决，因为决定差异的变量并不都存在于像素中。

这里至少出现了三种信息缺口。

第一是隐藏变量。接触力、摩擦、夹持稳定性和物体微小速度决定杯子是否会滑落，但单帧 RGB 很难唯一确定它们。

第二是时间错位。相机帧、力传感器、关节数据和控制器回执可能来自不同采样时刻。把它们直接拼接，会制造一个现实中从未存在过的"同时状态"。

第三是执行回执缺失。模型输出了"闭合夹爪"，并不代表控制器已经接受、没有裁剪并且执行完成。如果历史只保存模型想做什么，而不保存实际发生了什么，下一次决策就会从虚构状态出发。

如果任务只是识别杯子颜色，单张图可能已经足够；如果任务是安全抓取，它显然不够。所谓状态充分性，必须同时写清任务和动作后果。

二、State 是针对任务和时域的充分性声明

在控制与强化学习语境中，Markov 性表达的是：给定当前状态和动作后，预测下一步所需的信息不再依赖更早历史。 $E2-S01$ 这句话最容易被忽略的部分，是"当前状态"本身由系统设计者定义。

用于 20 毫秒伺服的状态，可能只需要近期位置、速度、力和控制模式；用于未来 10 秒任务规划的状态，还要包含目标进度、可通行区域、工具状态和失败恢复条件。同一份表示不必同时满足所有时域。

真实系统通常不能完整读取环境状态。POMDP 将这种部分可观察性显式化：同一观测可能来自多个隐藏状态，系统需要利用动作---观测历史形成对隐藏状态的判断，也就是 Belief State。 $E2-S02$

工程实现不一定维护完整概率分布。它可以是卡尔曼滤波状态、粒子集合、有限历史窗口、规则状态机、RNN 隐状态或 Transformer 记忆。但名称不能替代证据：一个张量叫 hidden_state，不代表它已经保留了当前任务需要的信息。

World Models、Dreamer 和 MuZero 分别展示了学习潜表示服务预测、想象和规划的不同方式。 $E2-S03$ $E2-S04$ $E2-S05$ 它们支持一个重要边界：内部状态可以是任务相关的近似，不必重建客观世界的全部细节；但它是否"足够"，仍要通过对应任务、动作和时域上的结果验证。

所以更准确的定义是：

State 是在指定系统边界、任务、动作空间和预测时域内，被假设足以支持预测与决策的信息集合或分布。

这不是"世界全部真相"，也不是把视频、数据库和全部对话塞进上下文。更多信息只能增加候选证据，不能自动形成充分状态。

三、语音打断：同一句"好的"为什么也对应两个动作

机器人案例很直观，但同样的问题会出现在语音 Agent。

决策时刻的信息	会话 A：普通确认	会话 B：打断且存在待确认操作
ASR 文本	"好的"	"好的"
说话来源	用户在 TTS 结束后发言	TTS 播放期间检测到近端语音，也可能混有回声
播放状态	输出缓冲区已结束	仍有音频待播放
对话阶段	信息说明已完成	用户正在打断原回复
待处理操作	无	支付调用等待二次确认
最近工具回执	无未决结果	上一次提交状态尚未确认
安全动作	简短回应或进入下一轮	先停止播放、确认打断内容，不得直接提交支付

如果 Agent 只读 ASR 文本或对话消息，两段会话几乎相同。真正改变动作选择的，是跨越实时音频、播放链、业务状态机和工具执行链的变量。

音频时间线回答"这句话在什么时候、相对于谁的声音出现"；播放状态回答"系统是否还在说"；待处理操作回答"这句话可能确认什么"；工具回执回答"现实世界是否已经发生副作用"。这些事实不一定适合全部写入自然语言上下文，却必须在动作前可被决策层读取。

长上下文无法自动修复这类问题。它可以保留更早的文字，却不能补回缺失的播放事件、错误的时钟对齐、未落库的工具结果或已经变更的授权状态。

四、两个案例共同暴露的三条失效链

机器人和语音系统的输入看起来不同，但失效链几乎一致。

1. 时间没有对齐

机械臂把旧图像与新力传感器拼在一起；语音 Agent 把稳定后的 ASR 文本与仍在变化的播放状态拼在一起。字段都存在，却不代表它们描述同一个参考时刻。

因此观测至少要带来源、采集时间、时钟域、质量标记和允许的最大陈旧时间。状态估计器还需要明确：当某个来源超时、缺帧或时钟漂移时，是继续、降级、询问还是停止。

2. 决定动作的变量没有进入估计

抓取动作依赖接触与相对运动；语音动作依赖播放、打断和待确认操作。若团队只列"模型能看到什么"，而不列"什么隐藏条件会改变安全动作"，就很难发现缺口。

最有效的审查问题不是"还有哪些传感器可以接入"，而是：

能否构造两个当前观测近似相同、但正确动作不同的场景？

如果可以，区分这两个场景所需的变量、历史或不确定性表达，就是状态估计必须覆盖的内容。

3. 系统记录了请求，却没有记录现实结果

requested、accepted、clamped、executed、failed 和 outcome_unknown 不是同一个状态。

机器人控制器可能裁剪动作；语音播放可能被取消；工具调用可能已经成功但响应丢失。若下一轮只看到模型最初的请求，内部历史会与现实持续分叉。

因此执行回执不是日志附属品，而是下一次状态更新的输入。没有它，系统无法判断该继续、补偿、重试还是先对账。

五、一次动作前，最少需要拼出什么

不必为所有项目引入一个庞大的统一框架。更实用的做法，是在每类高影响动作前明确一份可检查的状态快照。

字段	需要回答的问题	机器人示例	语音 Agent 示例
`decision_id` 与参考时刻	这次判断对应哪个时间点	控制周期与单调时钟	当前 turn 与音频时间线
任务与动作时域	要决定什么，结果要维持多久	抬升前 200 ms	停止播放并处理本轮确认
观测及其新鲜度	证据来自哪里，是否过期	图像、力、速度、控制模式	ASR、VAD、播放缓冲、工具状态
相关历史	哪段动作---观测历史仍影响当前判断	最近闭合命令与反馈	最近输出、打断事件与确认范围
状态估计与不确定性	系统当前相信什么，哪里仍未知	夹持稳定概率或显式状态	用户发言来源与意图仍是否含混
未决操作	哪些动作已经请求但尚无最终结果	控制器仍在执行闭合	工具调用等待确认或结果未知
最近真实回执	上一步实际发生了什么	accepted / clamped / executed	played / cancelled / submitted / failed
当前允许动作	哪些动作可执行，谁可以拒绝	抬升、保持、重夹、停止	继续说、停止、追问、提交工具
失效条件	什么变化会让快照作废	新帧、力突变、控制模式切换	新的打断、目标变化、授权过期

这张表的目的不是创造一个新名词，而是迫使团队把"模型应该知道"改写成可采集、可对齐、可失效和可验证的事实。

动作接口仍需明确类型、坐标、单位、频率、范围与有效期。ROS REP 103 和 REP 105 说明了单位和坐标框架为何必须约定，但具体机械臂工具坐标、权限与控制模式仍要由项目定义。 $E2-S06$ $E2-S07$ 对 Agent 也一样：draft_email、send_email 和 charge_card 不是同一级动作。

六、状态是否足够，要用反例测试而不是字段评审

字段表只能证明设计看起来完整，不能证明决策真的安全。至少需要四类测试。

1. 观测相同、隐藏条件不同

固定当前图像或 ASR 文本，改变接触力、物体速度、播放状态、待处理工具或确认范围。系统应输出不同动作，或明确进入"不确定、等待更多证据"状态。

2. 时间错位与陈旧注入

人为延迟一个传感器、重放旧帧、让业务状态晚到，或制造跨时钟域漂移。检查系统是否识别过期组合，而不是把字段齐全误判为状态完整。

3. 回执丢失与晚到成功

让动作已经执行，但响应超时；或让控制器只接受未执行。系统不能把超时直接当失败重试，也不能把请求成功当现实成功。

4. 动作边界在决策中途变化

在观测完成后切换控制模式、目标版本、授权或安全约束。旧状态快照应失效，重新评估允许动作。

测试结果不要只看平均任务成功率。更有价值的指标包括：

含混场景中的危险动作率；
关键证据缺失时的停止、追问或降级率；
陈旧输入被正确拒绝的比例；
请求状态与真实执行结果的一致率；
outcome_unknown 被对账而不是盲重试的比例；
状态恢复后能否回到正确流程，而不是永久卡死。

如果系统只在"信息完整、时间同步、回执正常"的理想路径上成功，还不能说明状态足够。

七、哪些场景不需要把事情做得这么重

状态充分性是相对于任务的，不意味着每个功能都要建立复杂 Belief。

静态图片分类、无副作用的信息检索或允许人工复核的推荐，可以使用更轻量的状态表示。只要单次观测已经覆盖任务所需信息，增加实时状态估计器反而会提高延迟和维护成本。

另一方面，高影响动作也不要求把所有事实都送进一个大模型。更合理的分工是：

感知模型提供带时间和质量信息的观测；
状态估计器或业务状态机维护任务相关事实与未决操作；
策略基于状态和不确定性提出动作；
适配器与安全层验证单位、范围、权限和失效条件；
执行器返回真实回执，再进入下一轮状态更新。

模型隐藏向量可以成为状态近似，但必须经过成对反例、时序扰动和闭环结果验证。业务数据库可以是权威事实来源，但也要处理缓存、版本和提交结果。上下文窗口可以保存叙事历史，但不能替代实时媒体状态、权限与工具回执。

结论

同一张机械臂画面，可能对应"抬升"或"停止"；同一句"好的"，可能对应普通确认，也可能发生在打断和高风险操作待确认期间。

Observation 是证据，State 是一项针对任务、动作和未来时域的充分性假设。团队真正需要验证的，不是输入字段够不够多，而是：

哪些隐藏条件会改变正确动作；
多模态证据是否对齐到同一参考时刻；
系统是否记录了真实执行结果，而不只是模型请求；
证据不足、过期或冲突时，Agent 是否会停止、追问或降级；
在"观测相同、隐藏状态不同"的成对反例中，系统能否做出不同且安全的选择。

能通过这些测试，状态才不是一个命名漂亮的张量，而是一个可以被验证、被推翻、并在现实反馈中持续修正的工程假设。

FAQ

上下文越长，状态就越完整吗？

不一定。上下文增加历史证据，但实时媒体状态、业务事实、授权和执行回执仍需要独立来源与时序。

模型隐藏向量可以直接叫 State 吗？

可以作为候选近似，但必须证明它保留了当前任务和时域所需的信息，并能通过含混场景与闭环结果测试。

状态不确定时，系统应该总是停止吗？

不必。低风险任务可以降级或请求更多信息；不可逆或高影响动作则应等待关键证据、重新确认或停止。

参考资料

$E2-S01$ Richard S. Sutton, Andrew G. Barto, Reinforcement Learning: An Introduction, 2nd ed.
$E2-S02$ Leslie P. Kaelbling, Michael L. Littman, Anthony R. Cassandra, Planning and Acting in Partially Observable Stochastic Domains.
$E2-S03$ David Ha, Jürgen Schmidhuber, World Models.
$E2-S04$ Danijar Hafner et al., Dream to Control: Learning Behaviors by Latent Imagination.
$E2-S05$ Julian Schrittwieser et al., Mastering Atari, Go, Chess and Shogi by Planning with a Learned Model.
$E2-S06$ Open Robotics, REP 103.
$E2-S07$ Open Robotics, REP 105.

机械臂抓杯和语音 Agent"好的"均为本文构造的工程反例，不是公开事故或作者实测。