编程代理还在忙，我该等着吗？

编程代理改变的不只是代码怎么写，还有我的时间怎么安排。任务交出去、代理开始工作后，我要先决定：继续守着，还是趁这段时间处理另一件事？

如果知道它还要二十分钟，我可以开始其他事情。如果它三十秒后就需要我的答复，我可能会等着。困难在于，我往往不知道自己面对的是哪一种情况。

等着代理，不代表自己就有空

不用亲手写每一处修改，并不意味着我已经空下来。我可能还得批准操作、澄清需求或审查结果。盯着对话记录，有时只是在看状态更新，自己的工作却没有前进。

可是一旦离开，代理又可能马上遇到问题，停下来等我。结果不是我等它，就是它等我。

短暂空档可以处理一件小事，但另一个技术任务往往需要重新找回上下文、回忆上次进度，再慢慢进入状态。切换本身就要付出成本。

如果刚进入第二个任务，第一个代理就完成了，我又得决定：打断眼前的工作，还是让结果再等一等？多开一个代理并不会自动解决问题，还可能让多个任务同时等着我审查。

所以，真正有用的问题不只是“代码什么时候写完”，而是“下次需要我回应之前，我有多长一段时间可以有效地做其他事”。

“工作中”不能区分代理是在探索问题、实施修改、运行检查，还是等待外部服务。

不同阶段意味着不同的空档。分析时可能发现需求缺失，测试时也许更容易估算等待时间，批准请求则需要我马上回应。补丁做完仍要审查，这部分工作不会因自动化而消失。

如果这些状态混在一起，我就只能围着黑箱安排时间：要么查看得太频繁，要么回来得太晚。

我不需要一个装作知道未来的倒计时，只想得到足够的信息来决定下一步：

例如，“验证中 · 粗略窗口：几分钟 · 无需输入”会比旋转图标更有帮助。这是界面设计示例，不是实测预测，也不表示已有这项功能。

还应区分“预计完成时间”和“下一次需要人回应的时间”。整个任务可能很长，却几乎马上就需要我作一个决定。

早期估算一定会变。任务范围会调整、检查可能失败、外部服务也可能变慢。有用的显示应把变化说清楚，而不是让一个过期的倒计时永远停在零。

可以先迈一小步：区分“能独立继续”和“正在等你”。然后再加入有依据的粗略范围，对照实际结果，看看它到底能帮多少忙。

有时适合继续陪着代理，有时可以处理小事，也有时值得切换任务。代理能在我忙别的事时推进实现，但想真正利用这种并行，我还得判断何时离开、何时回来，以及交接和审查需要多少注意力。