无人值守Agent被提交前检查卡住70分钟

一个无人值守的 Copilot CLI 任务，因为机器上没有安装身份检查工具 gitpro，最终留下约 70 分钟、55 个文件的已验证工作，却没有提交。代理遵守了规则，也暴露出规则的缺口：要求「先问用户」，却没写用户不在线时怎么办。

作者准备补上的，是无人值守时的决策边界：区分本地提交与推送，提前写清哪些操作可以降级执行，哪些必须报告阻塞。这件事值得经常让 AI 连续跑任务的程序员留意。

代理守住了什么，又卡在了哪里

作者让 Copilot CLI 以 headless 模式运行，并通过 resume loop 持续恢复任务。代理自行加载了 gitpro skill，因为它的描述要求在提交前使用。

这份 skill 有两条相关规则：

• 每次执行 git commit 前，先运行 gitpro why 检查身份。
• 如果没有安装 gitpro，安装前必须询问用户。

问题恰好出在两条规则的交界处：机器上没有 gitpro，现场也没有人能回答安装请求。

代理没有擅自找替代路径。它继续工作，再次检查 gitpro 是否可用，但始终没有提交；也没有使用 --no-verify、自行安装工具，或以错误身份提交。任务最后以一条说明结束：身份预检不可用，而且不能绕过。

规则成功阻止了未经许可的提交，却没有给任务留下完成路径。

标题里的「停了 70 分钟」容易让人以为代理一直空转。按正文描述，它仍在做开发工作，最终留下约 70 分钟、涉及 55 个文件的已验证改动。作者之后重新跑了测试，并亲自提交。

为什么本地提交和推送需要不同规则

作者发现，原规则漏掉了三个区别。

首先，「询问用户」只适用于有人响应的场景。无人值守任务需要提前记录决策，否则代理即使正确执行指令，也无法继续。

其次，本地提交和 push 的影响范围不同。这次仓库没有 remote，本地提交容易撤销；推送则可能影响外部仓库和其他协作者。把两者放进同一个审批条件，会让风险较低的操作也一起卡住。

最后，工作受阻不等于任务完成。代理虽然留下了说明，却结束了运行，没有把结果报告为 blocked。对依赖状态判断是否继续处理任务的人或系统来说，这个区别很重要。

作者提出的新规则是：无人值守且缺少 gitpro 时，如果仓库没有 remote，并且仓库自己的 user.email 已设置，就允许本地提交，同时记录身份检查被跳过。只要仓库配置了 remote，或者操作涉及任何 push，就停止，并报告 blocked，而不是 done。

这是作者准备采用的方案。原文没有展示修改后的运行结果，也没有证明它已经解决了后续问题。

我的判断

我赞同把「无人响应时怎么办」写进 skill，也赞同明确区分 blocked 和 done。前者让代理有可执行的分支，后者让人知道任务还欠哪一步。

但放宽提交条件仍有前提。user.email 已设置，不代表身份一定正确；没有 remote，也不代表改动内容没有风险。这套条件缩小了操作的外部影响范围，却没有替代原来的身份检查。

与「缺少工具就一律停止」相比，作者的方案更重视保存本地工作进度；与「自动安装缺失工具」相比，它继续保留了安装授权边界。哪种更合适，取决于团队是否接受跳过身份预检，以及如何查看这条跳过记录。原文没有说明记录格式，也没有给出不同策略的对照数据，因此这仍是一次具体故障后的经验调整。

可以借鉴的是提前写清决策条件，不能直接照搬的是允许跳过检查的门槛。

能拿来做什么

• 给无人值守的 AI 编程任务检查一遍 skill：凡是出现「先询问用户」，都补上无人响应时应停止、降级执行还是记录待处理事项。
• 如果前端或 Node 项目允许代理自动提交，就分别写清本地 git commit 和 push 的条件，并明确仓库存在 remote 时如何处理。
• 把缺少工具、等待授权、验证通过但未提交等情况写入任务状态规则，避免代理用 done 掩盖尚未完成的步骤。
• 在持续运行任务前，检查 skill 依赖的 CLI 是否可用。这次具体要检查的是 gitpro，以及 gitpro why 能否正常执行。