用户说“算了”，设备指令真的取消了吗？

用户说"算了"，设备指令真的取消了吗？

用户对语音 Agent 说"打开书房灯"，马上改口："算了。"Agent 停止播报，界面也显示"已取消"。几秒后灯却亮了。语音中断、云端任务取消、设备停止执行和恢复原状，分别需要不同证据。 如果工具只返回一个布尔值，Agent 很容易把"请求已撤回"说成"动作从未发生"。

本文用官方文档作边界，以一条控制指令为例，给出可实施的撤回状态和用户反馈。它是架构设计示意，未连接真实设备、AWS 账号，也没有物理动作或时延实测。

CANCELED 为什么不能证明灯没亮

AWS IoT Jobs 取消文档区分排队中的 QUEUED 和执行中的 IN_PROGRESS：前者可以取消，后者需要显式 force。官方警告，强制取消进行中执行后，设备无法再更新这条 Job execution 的状态，并提醒设备要能恢复到有效状态。这说明平台把记录标为 CANCELED，并不能倒推出设备没有接到指令、没有动作，甚至可能让后续结果无法继续写入这条执行记录。

这里引用的是 AWS IoT Jobs 。AWS IoT Commands 与普通 MQTT 发布是不同接口；不能把 Jobs 的取消 API 说成所有设备控制指令都能调用。自己的系统若只有"发 MQTT 消息"，就需在业务层定义 command_id、有效期、撤回请求和设备侧停机回报，不能凭 Agent 的任务取消回调回答用户"灯不会亮"。

AWS IoT Jobs 设备工作流明确要求设备在任务运行期间处理取消或删除，并恢复到有效状态。能阻止物理动作的判断最终要到设备或控制器执行点；Agent 停止 TTS 只改变音频输出。

停止说话之后，还需要查哪条命令

语音系统最先能观察到的通常是当前对话被打断：用户重新开始说话，TTS 队列停止，或模型生成终止。这些信号适合控制对话，却没有天然携带设备命令的执行结果。若设备工具已经提交，原工具调用的取消只是停止本地等待，设备消息仍可能继续运行。应用需要把会话轮次与具体 command_id 关联，才能找到用户想撤回的那次动作。

"算了"也可能指停止解释，而非撤回刚才所有控制。可以依据紧邻上下文确定具体对象：用户刚说开书房灯，随后立刻说"算了，不开了"，就有清楚的撤回目标；若同时有多个设备任务，仅凭一句泛化的"算了"无法安全推出全部任务都撤销。先完成已明确的本地中断，再对需要确定对象的控制保留待确认状态。这里是在说明意图绑定，不引入一套通用自然语言推断规则。

撤回操作自身也需要关联身份和结果。记录它针对哪条原命令、何时提出、由谁提出、哪个系统接受，以及设备终态是什么。若用户重复说"取消"，应再次查询或复用同一撤回目标，而不是不断生成相反动作。这样的记录能区分"原命令取消请求重复到达"与"用户提出新的关闭意图"，避免把相似话语转换成不同业务动作。

平台接口必须保留原始语义。Jobs 强制取消会限制后续 execution 状态更新，因此如果应用还需要得知设备实际动作，须确认另有被允许的状态或审计通道；不能假设仍能往已取消的同一记录写成功。本文没有提供具体 AWS 集成实现，只从官方警告推导：取消平台记录后，设备观察证据不能顺便被丢掉。

改口时，命令可能正处在四个位置

撤回发生时	系统动作	证据充分后的反馈
命令尚未发送	停止提交，核对没有发出	"这条指令未发送"
已排队，设备尚未领取	撤销待发项，等待队列结果	"待执行任务已撤回；设备结果仍在核对"
设备已领取，动作尚未发生	送达中止请求，由设备在执行点确认	"已请求停止，结果待确认"
动作已经发生	判断是否能安全执行反向动作或人工恢复	"动作已发生，正在恢复"或说明不能恢复

这不是四条同步 API：撤回与设备领取可能交叉。平台查询时看到"尚未执行"，设备下一瞬间仍可能执行。因此，"未执行"必须是阻止该 command_id 此后执行的设备侧终态 ，例如设备在执行临界点原子地把它转为 canceled_before_execute。一次状态快照不足以作出永久承诺。设备失联时保留 unknown，不要补猜结论。

应用层可保存最小记录：command_id、设备 ID、目标动作、有效截止时间、队列状态、领取状态、取消请求时间与设备终态。cancel_requested、canceled_before_execute、executed_then_compensated 是不同事实；结果乱序到达时，不允许一条较晚送达的旧"排队中"事件覆盖"已执行"的证据。字段和状态名是作者设计示意，不是 AWS 或 MQTT 规定的通用格式。

把竞态画成两条时间线

第一条时间线可以是：云端撤回待发项，确认未发送，随后设备继续等待。若整个发送过程受同一业务状态约束，并确实没有留下另一条已提交消息，才能说这条指令未发送。只在界面上移除任务卡片，不代表后台队列被移除；只取消一个发送线程，也不代表重试线程没有持有副本。核查范围应覆盖这条命令所有可能的提交入口。

第二条时间线更难：设备领取命令，云端查询还显示排队，用户发出撤回，设备进入动作临界点。两边各有一个暂时正确的局部观察，却不能拼成"保证没执行"。设备需要在执行与取消之间做明确决定，并回报最终选择。所谓原子决定约束的是同一设备控制逻辑，不能消除网络分区；设备未看到撤回时，云端仍不能替它承诺。

可在设备或控制器把命令记录分成"可中止准备阶段"和"已跨越执行点"。执行点的定义随动作而变：开关灯可能很短，机械运动可能持续很久。对于后者，停止运动与动作从未发生也不同，回报应说明停在哪个位置、是否需要恢复。不要让一个 canceled 字段同时承担未开始、途中停止和反向补偿三种含义。

若动作已经跨过不可逆边界，设备不应为了满足取消状态强行报告未执行。仍可尝试停下后续步骤，报告已经完成的部分和未完成的部分。这个设计有助于解释多步骤任务：例如前一步已改变设备状态，后一步尚未开始。用户撤回后任务可能只停止剩余部分，原先变化仍需另行处理。

下面的本地序列把执行点前后的顺序固定下来，避免靠人工恰好在某一瞬间喊"算了"。真实设备仍需另验控制器的动作边界。

消息过期挡得住离线迟到，挡不住已交付动作

如果设备离线，用户的"开灯"指令可能等到重连才送达。MQTT 5.0 标准的 Message Expiry Interval规定：当消息已过期，而服务端尚未开始向匹配订阅者转发，就要删除为该订阅者保存的副本。AWS IoT Core 的 MQTT 文档也说明，离线持久会话中的相应 QoS 1 消息过期后，恢复连接不会再收到它。

这只能缩小迟到执行窗口，不能收回已交付的消息，更不能让继电器复位。设备即使收到旧消息，也应在执行前检查业务有效期与取消状态。有效期的长短要由动作风险决定；不能给灯、门锁和扣费动作统一填一个数字。传输层"删除未转发副本"与业务层"禁止此时再执行"是两道门。

重连时还要核对旧授权是否仍有效

离线命令至少有两种老化：时间过期与用户意图已更新。设置消息有效期处理前者，明确取消标记或命令代际处理后者。假设旧开灯命令还没有到时间，但用户已改为保持关闭，旧授权已经失效；只检查时间仍可能执行错误动作。相反，用户没有改口但命令已过期，也不能因意图未变就自动恢复旧命令，应按产品约定重新确认。

设备若保存本地待执行任务，传输服务删除副本并不会自动清掉本地副本。重连流程需要核对哪些命令已经领取、哪些仍可执行、哪些已被撤回。回报丢失的记录也要查原命令，而不从"队列现在为空"推断从未领取。这里不要求所有设备都使用同一种本地存储，只要求系统理解自己有哪些真实副本。

时钟不可靠时，绝对截止时间的判断会有误差。应用应明确时间来源与失联行为，不能只在 JSON 放 expires_at 就宣称迟到动作已阻断。对不能可靠核实有效性的设备，按动作风险选择拒绝执行或保留待确认；这种选择属于设备业务设计，必须在实际硬件上验证。

取消消息本身也可能迟到或重复。因此设备决定应依据命令身份、当前事实和已固定的终态，不让一条旧取消消息误伤下一条新命令。重连后先同步授权与任务状态，再解释需要执行的工作，比盲目消费所有积压消息更符合用户当前意图。

已经动作时，反向命令也不等于回滚

灯已经打开后再发"关闭"，可能恢复当前状态，却抹不掉曾经亮过的事实。如果另一位用户随后又要求开灯，撤回流程盲目关闭还会覆盖新意图。补偿前至少要查询当前状态和版本，确认反向动作仍代表当前用户意图；证据不足就先询问或报告不确定。

门锁开过、药盒释放过、款项扣过，反向动作更不能称为"原动作未发生"。它们需要各自的权限、补偿规则和审计，有的根本不适合自动补偿。Agent 要报告两件事：原动作是否已发生，以及恢复动作目前有何证据。不要把"请求重新上锁"说成"开门已撤销"。

用固定序列验证"请求"与"结果"不会混成一项

把以下代码保存为 cancel_sequence.py，使用 Python 3.10 或更新版本运行 python3 cancel_sequence.py。它只使用标准库 dataclasses，处理一条命令的构造事件序列；没有网络、账户、MQTT 客户端、AWS SDK，也不会开关真实灯具。输入里的 device_receive_cancel 和 device_stop_confirmed 都是我们明确写入的假设事件，不能因为输出显示某个终态就声称设备真实回报了它。

本例区分三类输入：对话侧 interrupt_tts；云端撤回请求和记录确认；设备控制器的领取、开始、收到取消及停机确认。只有设备侧未执行终态会阻止后续 start。cloud_cancel_confirmed 只标记平台记录，故意不改设备阶段：这承载的是文章中"不能从云端取消推断物理停止"的边界，不是对 AWS Job execution 更新机制的完整模拟。

Record 的四项输出依次是：当前阶段、历史上是否开始过动作、恢复状态是否已确认、TTS 是否已停止。action_happened 一旦为 True，就不会被取消或补偿清零。对于持续运动，开始后停下意味着曾经执行过一部分；对于灯的瞬时开关，执行点的含义要由控制器另行定义，不能直接借这个布尔量判定真实灯光。

expires_at=5 是同一本地逻辑时钟上的构造截止值，不是统一推荐五秒。start 只在未开始的 queued/prepared 阶段检查业务有效期；动作已经运行时，再推进到时刻 6 不会凭过期恢复原状。本例检查的是业务执行点的有效期，不解析 MQTT Message Expiry Interval，也不实现 Broker 的过期副本删除。

"""Local, constructed sequence for ONE command; never controls a device."""
from dataclasses import dataclass


@dataclass
class Record:
    phase: str = "not_sent"
    expires_at: int = 5
    last_time: int = 0
    tts_stopped: bool = False
    cancel_requested: bool = False
    cloud_canceled: bool = False
    cancel_seen: bool = False
    action_happened: bool = False
    compensation_requested: bool = False
    restored: bool = False

    def step(self, event, now):
        # shortcut: one trusted, ordered command stream and logical clock;
        # add identity/auth/order checks for real asynchronous inputs.
        if now < self.last_time:
            raise ValueError("logical time moved backwards")
        self.last_time = now
        if event == "interrupt_tts":
            self.tts_stopped = True
        elif event == "request_cancel":
            self.cancel_requested = True
        elif event == "cancel_unsent":
            if self.phase == "not_sent":
                self.phase = "canceled_not_sent"
        elif event == "send":
            if self.phase == "not_sent":
                self.phase = "queued"
        elif event == "cloud_cancel_confirmed":
            self.cloud_canceled = True
        elif event == "claim":
            if self.phase == "queued":
                self.phase = "prepared"
        elif event == "device_receive_cancel":
            self.cancel_seen = True
            if self.phase in ("queued", "prepared"):
                self.phase = "canceled_before_execute"
        elif event == "start":
            if self.phase in ("queued", "prepared"):
                if self.cancel_seen:
                    self.phase = "canceled_before_execute"
                elif now >= self.expires_at:
                    self.phase = "expired_before_execute"
                else:
                    self.phase = "running"
                    self.action_happened = True
        elif event == "device_stop_confirmed":
            if self.phase == "running":
                self.phase = "stopped_after_start"
        elif event == "finish":
            if self.phase == "running":
                self.phase = "done"
        elif event == "compensate_authorized":
            if self.phase in ("done", "stopped_after_start"):
                self.compensation_requested = True
        elif event == "restoration_confirmed":
            if self.compensation_requested:
                self.restored = True
        else:
            raise ValueError(f"unknown event: {event}")


def run(events):
    record = Record()
    for event, now in events:
        record.step(event, now)
    return (record.phase, record.action_happened, record.restored,
            record.tts_stopped)


def main():
    sent = [("send", 0), ("claim", 1)]
    started = sent + [("start", 2)]
    done = started + [("finish", 3)]
    cases = [
        ("tts_only", started + [("interrupt_tts", 3)],
         ("running", True, False, True)),
        ("cancel_request_only", sent + [("request_cancel", 2), ("start", 3)],
         ("running", True, False, False)),
        ("cloud_only", sent + [("cloud_cancel_confirmed", 2), ("start", 3)],
         ("running", True, False, False)),
        ("cancel_before_send", [("cancel_unsent", 0), ("send", 1)],
         ("canceled_not_sent", False, False, False)),
        ("device_cancel_before_start", sent + [("device_receive_cancel", 2), ("start", 3)],
         ("canceled_before_execute", False, False, False)),
        ("cancel_after_start", started + [("device_receive_cancel", 3)],
         ("running", True, False, False)),
        ("device_stop", started + [("device_receive_cancel", 3), ("device_stop_confirmed", 4)],
         ("stopped_after_start", True, False, False)),
        ("expiry_before_start", sent + [("start", 5)],
         ("expired_before_execute", False, False, False)),
        ("expiry_after_start", started + [("start", 6)],
         ("running", True, False, False)),
        ("compensation_pending", done + [("compensate_authorized", 4)],
         ("done", True, False, False)),
        ("compensation_confirmed", done + [("compensate_authorized", 4), ("restoration_confirmed", 5)],
         ("done", True, True, False)),
        ("unrequested_restoration", done + [("restoration_confirmed", 4)],
         ("done", True, False, False)),
    ]
    for name, events, expected in cases:
        actual = run(events)
        if actual != expected:
            raise AssertionError(f"{name}: {actual} != {expected}")
        print(f"{name}: {actual}")
    print(f"PASS {len(cases)} constructed sequences")


if __name__ == "__main__":
    main()

本次在 Python 3.11.6、macOS arm64 环境执行，退出码为 0，实际标准输出如下。每条序列与预先定义的预期四元组比较；出现差异会抛出 AssertionError，不能继续打印全部通过。

tts_only: ('running', True, False, True)
cancel_request_only: ('running', True, False, False)
cloud_only: ('running', True, False, False)
cancel_before_send: ('canceled_not_sent', False, False, False)
device_cancel_before_start: ('canceled_before_execute', False, False, False)
cancel_after_start: ('running', True, False, False)
device_stop: ('stopped_after_start', True, False, False)
expiry_before_start: ('expired_before_execute', False, False, False)
expiry_after_start: ('running', True, False, False)
compensation_pending: ('done', True, False, False)
compensation_confirmed: ('done', True, True, False)
unrequested_restoration: ('done', True, False, False)
PASS 12 constructed sequences

tts_only 已停语音，动作仍运行；cancel_request_only 只有本地请求，设备仍能开始；cloud_only 即使平台记录确认取消，也没有设备未执行终态。这三条反例使"界面已取消"无法冒充"动作已停止"。它们没有证明真实系统一定还会执行，只说明缺少设备证据时不应许诺不会执行。

cancel_before_send 在后续发送入口醒来后仍保持未发送；device_cancel_before_start 在收到取消后再给 start，也不再进入运行。前者约束本地提交入口，后者约束设备执行入口。取消已经晚于 start 时，cancel_after_start 仍显示 running；只有新增 device_stop_confirmed 事件，device_stop 才显示停止，而且历史动作标记继续为 True。

expiry_before_start 在截止点拒绝开始，expiry_after_start 则保留已经运行的动作。二者共用同一截止值，唯一关键差别是过期前是否跨越执行点；这让有效期只承担阻止迟到开始的职责，不被解释成中途停止或物理回滚。

compensation_pending 只有新的补偿授权，restored 仍为 False；compensation_confirmed 在追加恢复确认后变为 True，原阶段仍是 done、action_happened 仍为 True。unrequested_restoration 没有匹配的补偿请求，不能直接把记录标成恢复成功。真实恢复还要核对新命令身份、授权、后续意图和新鲜设备状态；本例的授权事件只是可信输入占位，不能替代权限检查。

这些 12 条序列真实通过，验证范围仅为所列输入与本地状态转移。代码把一条命令的事件串行处理；没有持久化、线程锁、消息乱序或网络分区模型，也没有真实发送通道。设备侧"收到取消并固定未执行终态"在一个本地调用中完成，不证明远端控制器具备原子执行点。真实接入应先确认这些能力存在，再把可信事件带着原命令 ID 接到实际记录上。

补偿必须有新的授权与新的结果

开灯后关灯是一个新动作。即使它通常风险不高，也仍要确认目标设备、当前状态和是否有后续用户意图。可以在读取状态时记录版本，再在提交补偿前核对是否仍成立；若平台不支持这种条件更新，应保留竞争窗口的限制，不把查过一次状态说成永远不会覆盖别人操作。

补偿还可能失败。原动作已经执行，恢复命令发出却未确认，用户最终得到的应是两个结果：原动作已发生，恢复尚待确认。若把两次调用压成一个撤销成功布尔值，就会再次制造与开头相同的错误。每一步保留自己的身份、接受结果与设备观察，最终汇总时明确当前状态和历史事实。

不适合反向操作的动作，则不要为了完成取消流程硬造回滚。比如已经产生不可逆输出，能够做的可能是停止剩余任务、说明已发生部分并进入人工处理。可恢复性由真实业务和权限决定，不从动作名字推测。本文中的门锁或药盒只用来解释不可逆边界，没有给任何真实设备的自动补偿建议。

最终可把测试报告按原命令与撤回操作并排组织。原命令是否提交、领取、动作；撤回是否记录、送达、在执行点生效；补偿是否授权、提交、确认。三个过程在网络上可以交错，用户反馈却只能选择已有证据支持的最具体结论。这样的验收不会因界面显示取消就提前结束，也不会因未知便随意重发动作。

一份撤回验收至少要保留哪些反例

单文件已覆盖未发送、执行前取消、执行后停机和过期边界，接入验证还要保留它没有覆盖的证据。首先是所有真实提交入口：任务取消后，重试线程、后台发送器或另一个副本是否仍会提交同一 command_id？只检查会话卡片无法回答；发送入口必须读取同一授权状态。

其次是到达顺序与物理历史。动作完成但成功回报迟到时，云端可能先收到撤回，再收到原动作已执行；记录应保留已发生事实，能恢复时另记补偿结果。若以消息抵达顺序把旧排队状态覆盖已执行，就会产生本例串行输入未涵盖的错误。

最后是多命令重连：旧命令、旧取消与新命令可能通过不同通道到达。每条事件须核对身份和当前授权，不能把旧取消应用到新命令。验证保留输入 ID、次序与设备最终状态；时钟、版本和终态证据不充分时继续保留 unknown，不凭队列空或最后一条消息猜测历史。

还有一种情况：补偿执行中，又收到用户的新意图。系统应重新判断补偿目标是否还代表用户要求，而不是因为补偿流程已启动就坚持做完。能否中止仍受设备执行边界约束，但反馈必须说明当前正在执行什么、哪些部分已不能撤回。撤回不是一次性的 UI 变化，而是让正在推进的动作与最新有效意图重新对齐。

停机确认要说明已停止的范围，恢复确认要同时说明原动作曾发生与当前状态已恢复。其余未发送、请求待确认和设备未执行的反馈，沿用前面的四位置表即可，无需给用户逐个念内部状态名。

如果系统只有发送接口，暂时不支持设备取消，可以先交付"停止后续提交、记录撤回、查询当前状态"这部分能力。并清楚说明已交付动作无法保证收回。补足真实设备能力前，不用语音上的取消体验承诺物理结果。

给用户的最终回答，应刚好停在证据边界

收到"算了"后，先确认撤回请求已记录；能撤销队列，就说明队列结果；设备侧回报终态未执行，才说"这条指令没有执行"；设备已经动作，就转向明确的补偿与状态核对。无设备回报时，说"撤回请求已收到，设备结果暂时无法确认"。

与上一篇"PUBACK 已到，灯还没亮"的完成确认不同，这里要回答的是改口后能否保证动作未发生、已停止或已恢复。四个位置的证据表，就是这条指令的撤回验收单。