我想要的工作过程并不复杂：打开编辑器，连接仓库，进入对话，继续做事。为了解决持续运行的问题，如果一个方案要求我记住更多终端命令、判断多个会话状态，还要自己恢复中断，那么我会继续追问：人的工作真的变少了吗？
后台任务还活着，解决了运行的一部分问题。使用者能否放心离开、回来后看懂进度、发生错误时接得上，是另外几部分。
我想把人因视角带到 Agent 的设计里。自动化的评价，需要计算它留下了什么工作给人。
不要把维护当成免费的背景
设想一个自动生成研究简报的系统。以前人工整理需要一段连续时间，现在系统自己运行，但每天需要检查是否掉线、来源是否改变、结果有没有重复。
即使每次检查只花几分钟，它也可能打断原来的工作。更难估计的是人要记住“还有一个系统可能需要我”的持续负担。
因此，我会分别记录初次配置、每次任务准备、运行监督、结果复核和异常恢复。一次投入与反复投入要分开，也要说明由谁承担。
以下只是评估框架：自动化带来的净变化，等于原先的人力投入减去这些新增或保留的人力投入。注意力中断不一定能与分钟数简单相加，可以另外记录介入次数、发生时机，以及是否要求立即响应。
一个节省处理时间、却增加大量不可预测打断的系统，可能仍然不适合当前工作方式。
留给人的，可能恰好是最难的部分
Bainbridge 在《Ironies of Automation》中讨论过，自动化可能扩大而非消除人的操作问题，尤其是监督和异常接管的困难。这篇论文针对工业自动化；我把其中的问题用于检查 Agent 的设计，是一种方法上的延伸。原文，1983
Agent 顺利运行时，人不需要了解每个步骤。发生异常时，却可能要求人迅速理解刚才读了什么、改了什么、为什么走到这里。若系统没有保留足够的过程记录，接管者会比从头执行更缺上下文。
所以“有人兜底”不能只是一句安排。兜底的人需要知道问题发生的位置、已完成的动作、尚未发生的动作，以及哪种修正能安全继续。
状态应该让人知道下一步，而不只是知道系统很忙
“运行中”可能包含正在下载、等待外部服务、循环重试、等待用户补资料，甚至已经没有有效进展。用同一个标签展示这些情况，使用者仍然要自己诊断。
我希望状态至少能回答：当前做到了哪里，正在等什么，是否需要人处理，处理以后会从哪里继续。展示的详细程度可以分层，默认只给决定下一步所需的信息，必要时再查看完整记录。
进度数字也需要有依据。未知长度的研究任务显示“完成 87%”，可能比“已完成来源筛选，正在核查三项冲突”更让人误判剩余工作。
真正有用的反馈，是减少人的推测。
恢复能力要在中断时检验
一个能从头重跑的流程，不一定能够安全恢复。假设它已经写入资料、创建任务或发送过通知，重复执行可能产生重复结果。
我会在设计上区分可重复读取与改变外部状态的动作，保留完成记录，并在不确定上次是否成功时先检查实际状态。需要继续时，应该能从已确认的位置开始。
对使用者来说，关键体验不是“我们实现了某个技术机制”，而是回来后知道哪些已完成、哪些待处理，也不会因为重试多做一遍重要操作。
这类能力不能只看顺利演示。应该主动在资料缺失、网络中断和工具失败时检查，人需要做多少诊断、能否理解提示，以及恢复后结果是否一致。
人的介入应该与后果相称
不是完全没有人工介入才算好的自动化。复核一个会影响研究结论的异常，与批准一次普通文件读取，承担的作用不同。
我会区分三种介入：补充机器拿不到的事实，判断没有固定答案的取舍，授权会产生外部后果的行动。每一种都应该让人获得完成判断所需的材料。
如果系统不断询问已经说过的条件，或者把它自己能够检查的错误交给人处理，这种介入更接近流程缺陷。减少它们，可以让人的注意力留给真正需要判断的节点。
同样，完全不询问也未必更好。错误跨过边界后再让人收拾，可能只是把可见的审批时间换成更大的事后修复。
我会怎样比较两个方案
让两个方案完成同一组真实任务，并加入同样的异常。除完成质量与总耗时，还记录人工介入、立即响应要求、恢复步骤，以及离开一段时间后能否理解状态。
评估时间也应覆盖日常使用，不能只包含配置完成后的最佳十分钟。谁能维护、多久更新一次、换一位同事能否继续，都会影响长期价值。
这些是我提出的验收维度，并非当前系统已经证明的成绩。对某些低频任务，简单人工操作可能仍然更省事；对高频且规则稳定的任务，投入恢复和反馈设计才更容易值得。
我希望 Agent 带来的是工作连续性：需要它时能开始，离开时不用一直惦记，回来时接得上，出错时知道怎么处理。与稳定交付的技术取舍相比，这里再多问一步：稳定运行之后，使用者是否也能够稳定地工作？