Failures and authority

This page has not been translated yet. It is shown in Chinese.

这一篇的收获

遇到失败时，能够区分“需要查状态”“需要授权”和“需要结束工作”，不凭一条报错猜测远端发生了什么。

一个没有收到结果的命令

设备已经给文件追加了一行，返回结果时网络断开。调用方只知道自己没收到回复，不能因此断言命令没运行。如果换一个新编号再提交，追加动作可能发生第二次。

工作区为命令保存请求编号和执行记录。账本仍在时，相同编号与相同输入会对应原任务；相同编号却换了命令内容会被拒绝。重连后应先查询原编号。项目实现：请求登记与冲突检查

调用方知道的事

没有收到结果。执行是否完成仍然未知。

设备可能知道的事

原请求已登记，正在运行或已有最终结果。

恢复的第一步是对齐已有记录，不是猜测并重做。

这不是跨设备重启的“恰好执行一次”保证。agent 重启丢失账本后，不能用新建的空记录假装记得旧任务。命令编号也不同于 JSON-RPC 用来匹配请求与响应的消息 ID，不能直接拿会变化的通信编号代替。原始资料：JSON-RPC 请求对象

文件写入的未知结果与命令去重不是同一种机制：不能假定给所有文件操作加一个相同编号，就自动拥有命令账本的保证。文件操作的未知结果处理

停止等待只表示调用方暂时不再接收结果。cancel 要求终止命令；当前工作区实现会使相应 shell 失效，不能承诺保留它的全部环境。exit 则明确结束整个工作区。

此外，宿主的工具审批、wanctl 的身份与访问检查、设备的执行策略位于不同位置。一个层面的允许不能替代另一个层面的检查。工作区根目录只帮助解释路径，也不是限制任意程序访问整个系统的沙箱。MCP 宿主职责 · 项目权限边界

命令提交后连接断开，你还保存着原请求编号。最合适的第一步是什么？

查看解释（可以跳过作答）

先查询原任务才能区分正在执行、已经完成和记录不可用。换新编号可能重复副作用；切回本地则可能换了工作地点。

每一种恢复动作都应依据已知事实。下一篇把这些边界变成可核验的验收条件。

如果这一点还不清楚，可以把本篇的问题和你自己的项目场景交给协作 agent，请它换一个例子解释。自检只提供即时反馈，不代表已经掌握；隔一段时间，不看答案再解释一次更有价值。