智能体在等信任或登录：保留指令、恢复原会话，再确认任务结果

你在 iPhone 上打开了电脑中的项目，写下“修复登录页无法滚动的问题，保留已有登录方式”。点击发送后，App 提示智能体暂时不能接收。终端里却有界面，也没有显示进程已经退出。

这时需要回答两个问题：智能体正在等什么？刚才的指令处于什么状态？只解决其中一个还不够。处理完登录提示，可能仍有一份保留的消息等待你的选择；恢复网络以后，刚才的请求也可能已经开始执行。

Tactic Remote 1.11 配合更新后的电脑端，会解释已识别的输入阻塞，并保留被拒的消息。下面用三个操作示例说明如何继续。示例用于解释恢复步骤，不代表已经发生的用户案例，也不是对所有智能体界面的统一描述。

先分清进程运行、输入就绪和任务完成

终端进程还在，不意味着它现在能接收编程指令。它可能在确认项目、等待服务商登录，或正在准备输入界面。反过来，界面显示空闲，也不证明代码已修好；可能只是当前没有任务执行。

工具权限是任务执行过程中的批准机制，不必然属于“发送被拒”。不同智能体、运行模式和版本会有不同提示，以实际终端和 App 的说明为准。

场景一 新项目停在目录信任确认

你刚切到一个新的仓库，终端出现是否信任当前目录的提示。在交互式会话中，Claude Code 会对尚未信任的目录显示工作区信任对话框；官方安全文档说明了这个行为。

先核对终端中的完整路径。它是否是预期的仓库？来自自己的代码、同事的项目，还是刚下载的未知内容？同名目录也可能属于不同分支、复制目录或独立工作区，不能仅凭会话标题判断。

在 1.11 已识别这种等待的情况下，恢复入口会引导你打开终端。按屏幕显示的选项回应，完成信任决定后，再检查智能体是否进入输入界面。重新启动仍在等待的进程，往往只会再次遇到同一个决定。

然后检查被保留的指令。如果原要求包含修改或提交，可以先返回输入框缩小范围：

只读检查这个仓库的启动方式、相关登录页面和已有测试。列出可能需要修改的文件与需要保留的行为。先给出方案，不要编辑、安装依赖或提交。

确认回复中的路径与当前仓库一致，再进入实施。对工具权限的后续请求，还需要根据动作本身判断；目录信任并不代表所有后续动作都已经批准。权限文档解释了具体操作的授权规则。

场景二 电脑已连接，智能体仍要求登录

Tactic 账号负责你与开发电脑之间的关联和访问；Claude Code、Codex、Amp、Droid 则使用电脑上各自的服务商账号。你能在手机打开项目，不代表这些服务商身份都已准备好。

先看是哪一个程序在要求登录。如果是智能体的终端提示，就按它的流程完成验证；如果需要在电脑浏览器中操作，先完成那个浏览器流程，再返回同一会话。不要把登录网址、一次性授权码或账号凭据复制到普通聊天消息中。

登录完成后，确认终端已经离开登录页面，并能处理输入。若实际错误是账号权限、订阅资格、网络访问或配置问题，使用对应错误继续定位。反复登录 Tactic 或重新绑定电脑，不能替代服务商验证。

再查看保留消息、输入框和待发队列。如果指令还没有发送，选择其中一份继续；如果新的输出已经对应这条指令，就查看当前结果。不要因为登录成功后画面暂时安静，就把整个任务复制一次。

选择恢复操作时，看它会对这条消息做什么

1.11 的恢复操作会按已识别的状态提供不同入口。明确未运行时，可以选择 启动并发送（Start & Send）；已识别为仍在等待信任、登录或启动时，入口是 打开终端（Open Terminal），用于处理当前提示。

同一份保留消息还可以选择 队列（Queue） 或 编辑（Edit）。两者用途不同：

若输入框已有内容，编辑（Edit）按钮会被禁用，以防新草稿被保留消息覆盖。队列暂停、等待审批或任务状态不确定时，也不会仅因为网络重新连接就证明队列中的消息已经发送。

旧电脑端可能不提供完整的等待分类，因此 App 可能显示通用的 Start & Send。这个按钮不证明进程已经停止；先看终端中的实际状态，再决定是否启动，并更新实际使用的电脑端。

场景三 按下发送后断线，先确认送达

如果 App 明确收到电脑端的拒绝，这条消息可以作为未被接受的消息恢复。如果发送途中超时或断线，情况不同：请求可能已经送到电脑，只是手机没有收到结果。

回到原电脑、原项目和原会话，查找与这条请求对应的最新输出。Agent 正在修改登录页，就让任务继续；已经生成结果，就先验收。在聊天界面中，只看到旧记录或暂时没有出现新的回复气泡，仍不足以证明请求没有执行，后台可能已经接收了请求。

例如，刚才的要求是“修复后提交”。重新发送可能产生额外改动、第二次提交或重复运行耗时命令。状态未明确前，不应把“再试一次”作为默认恢复动作。

确认当前会话空闲后，可以要求它说明已有进展：

说明上一条任务是否已经开始、目前改了哪些文件、实际运行了哪些检查，以及是否创建了提交。不要重复执行上一条任务，也不要继续修改或发布。

这是一条状态查询。如果终端仍停在信任、登录或权限选择上，先处理那个提示，否则查询本身也可能无法被接受。原会话无法读取时，可在电脑端检查相应项目与进程，再决定如何恢复。

恢复以后，用结果验证任务而不是只看状态灯

先用一个范围小的请求验证原会话响应正常，再下达实施指令。仍以前面的滚动问题为例，可以把目标和保留条件写在一起：

修复小屏登录页无法滚动的问题。保留已有登录方式、登录返回流程和取消验证的提示。先说明最小修改范围；完成后列出实际修改、运行的检查、失败项，以及仍需人工核验的操作。暂不发布。

验收时，至少确认修改发生在预期仓库，页面确实可滚动，原有登录与取消流程仍符合要求。测试结果应对应当前修改；如果检查后又改了相关代码，需要重新核验受影响的行为。能收到回复，只证明恢复了响应，不能替代这些检查。

只有确认原会话已不存在或无法继续时，再创建新的会话。先保存任务摘要、已改文件、已运行检查和未决问题。使用同一目录创建新会话，或改用另一位智能体，不会自动继承原任务的全部上下文。

如果电脑又无法连接，回到连接排查流程；如果能连接但仍无有效回复，记录智能体名称、两端版本、具体等待提示与刚才的消息状态，再联系支持。两端升级要求与这一版的其他变化，可查看1.11 详细介绍。