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

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

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

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

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

使用者痛点汇总

• 难以判断观测是否真正覆盖任务所需信息。
• 缺少实时执行回执导致决策基于虚构状态。
• 时间同步错误导致不同来源信息组合不一致。
• 模型输入量大但并不保证充分性。
• 缺乏程序化的反例测试手段。

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

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

决策时刻的信息
A： 可以抬升	B： 不能抬升

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

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

单帧 RGB 很难唯一确定接触力、摩擦等隐藏变量；导致抓取决策失误，

时间错位——相机帧、力传感器与控制器回执采样时刻不同，直接拼接会产生不存在的“同时状态”。

执行回执缺失——模型输出“闭合夹爪”，并不代表控制器已接受或执行完成；历史只保存请求而非实际结果会让下一轮决策基于虚构状态。

If task is only color recognition,single image may suffice;for safety grasping it clearly isn’t.

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

在控制与强化学习语境中，Markov 性表达的是：给定当前状态和动作后预测接下来所需的信息不再依赖更早历史。这句话最容易被忽略的是“当前状态”本身由程序设计者定义。

• POMDP 明确部分可观察性：同一观测可能来自多个隐藏状态。需要利用动作—观测历史形成对隐藏状态的判断，即 Belief State。工程实现可以是卡尔曼滤波、粒子滤波、有限窗口或 RNN 隐藏层，但名称不能替代证据。
• World Models 等展示内部状态可以是任务相关近似，不必重建完整世界细节；但其“足够”需要，话说回来，

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

决策时刻的信息
A： 普通确认	B： 打断且存在待确认操作

ASR 文本“好的”“好的”看似一样。 但跨越实时音频、播放链和业务状态机等变量才决定最终动作。例如 TTS 是否还在播放？是否有待处理支付调用，工具回执是否已返回？这些事实无法仅靠文本捕获，却必须在决策前可读取。

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

'时间没有对齐'

• Mecanic arm 把旧图像与新力传感器拼在一起；语音 Agent 把稳定后的 ASR 文本与仍在变化的播放状态拼在一起。不过，字段都存在却不代表它们描述同一个参考时刻。
• => 必须带来源、采集时间和允许最大陈旧时间，并明确超时策略。

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

• {抓取}依赖接触与相对运动；{语音}依赖播放/打断/待确认操作。若团队只列 “模型能看到什么”。而不列 “什么隐藏条件会改变安全动作”，很难发现缺口。说起来，
• => 最有效审查问题是 “能否构造两个当前观测近似相同。但正确动作不同，” 如可，则区分所需变量即为必须覆盖内容。

'程序记录了请求，却没有记录现实结果'

• `requested`。`accepted`,`clamped`,`executed`,`failed` 与 `outcome_unknown` 并非同一状态。如果下一轮只看到模型最初请求，则内部历史会与现实持续分叉。
• => 执行回执不是日志附属品，而是下一次状态更新输入。无它，程序无法判断继续/补偿/重试还是先对账。其实，

'五、一旦行动前最少需要拼出什么'

字段	需要回答的问题	机器人示例	语音 Agent 示例
decision_id	哪个时间点对应此判断？ Task & action timespan what should be decided now?Outcome persistence duration. (eg.抬升前 ms停止播放并处理本轮确认观测及其新鲜度证据来自哪里 是否过期?)	image + force + velocity + control mode ASR+VAD+playback buffer + tool status history action‑observation history still affecting current judgment recent close‑command feedback	ASR / VAD / playback buffer Tool status History of pending operations Current turn Audio time‑line relative to system clock

从说明来看，

• The table is meant to force teams to translate “what model should know” into collectible,alignable,failable,verifiable facts.

An action interface still needs explicit type,coordinate,unit,frequency。range & validity period.

No single massive model is required – split responsibilities 娱乐ween perception,state estimator/business state machine,strategy and safety adapter.

---

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

• If state seems complete under ideal path but fails on edge cases → not sufficient.

Poorly designed tests miss hidden conditions leading to unsafe decisions.

You must validate against realistic execution outcomes – not just average success rate.

---

再看四类测试示例，

- 观测相同 / 隐藏条件不同→应输出不同行动或“不确定”。- 时间错位 / 陈旧注入→应识别过期组合。- 回执丢失 / 延迟成功→应区分超时 vs 真正失败。- 动作边界变化→旧快照失效，应重新评估。按理说，-->

- 含混场景中的危险行动率；- 缺少关键证据时停止/追问比例；- 陈旧输入被正确拒绝比例；- 请求 vs 实际执行一致率；- outcome_unknown 被对账而非盲重试比例；- 状态恢复后流程恢复能力。

-->

---

从指标建议来看。- 安全优先度： -->- 对比平均成功率，更关注危险行为率和退让行为率。按理说，

​​​
​

---