早上打开电脑，待办清单里挤着几件小事：把会议纪要里的行动项摘出来，按项目归档；把散落在聊天记录里的文件收进共享目录；给下周的评审准备一份背景材料。这些动作单看都不难，难在它们跨了多个软件，还要在中间做判断。于是，智能体被寄予期待：不只是回答问题，而是替人走完这几步。
它接手的不是一句话，而是一串动作
把智能体理解成一个会调用工具的软件流程，是一种接近现实的看法。它需要读取输入，决定下一步，调用浏览器、文档或消息接口，再根据返回结果调整。问题也在这里：每一步都可能遇到意外。文件重名、权限不足、页面结构变化、消息对象模糊，都会让流程卡住。模型能生成看似合理的下一步，却不等于知道什么时候该停。
我在看这类工具时，会留意它失败时的样子。一个能顺畅完成十步任务的演示，未必说明它适合放进日常流程；相反，能清楚报告哪一步没做、为什么没做、留下什么痕迹的系统，才可能被信任。智能体的可用性，往往不取决于它多会写计划，而取决于异常处理是否具体。
权限和回滚，是任务设计的一部分
当软件开始代替人点击、发送、修改，权限边界就绕不开。它能读哪些目录，能代表谁发消息，能不能删除文件，能不能提交表单，这些需要在任务开始前说清楚。另一个问题是，临时获得的权限是否会在任务结束后收回。若没有这些约束，自动化顺畅时，风险也可能变得隐蔽。
回滚也需要一并考虑。人操作时也会出错，但人知道自己刚做了什么，能手动撤回。智能体执行多步任务后，中间状态可能散落在不同系统里。此时如果没有操作日志、变更记录和可逆设计，补救成本会迅速上升。因此，我会把可观测性视作可用性的组成部分：过程能不能被看见，结果能不能被核对，失败能不能被复现。
人的位置，在确认和取舍上
这并不意味着人要被排除在流程外。相反，智能体可以处理路径明确、结果可验证的环节，把需要承担责任的判断留给人。比如整理材料可以自动完成，但对外发送前的措辞确认、涉及权限变更的审批、对模糊需求的取舍，仍需要人来拍板。人机协作不是一句口号，而是把确认点放在真正需要判断的地方。
另一个容易被忽略的边界是任务本身是否需要自动化。有些琐事之所以琐碎，是因为流程设计不清；直接把不清的流程交给软件，可能只是把混乱搬到另一个地方。梳理清楚输入输出、异常分支和责任人，再决定哪一段交给软件，是一种稳妥做法。
所以，当智能体开始接手琐事，人剩下的不是无事可做，而是清楚地定义什么算完成、什么不能自动、出了问题谁来看。这些问题不新，只是在自动化程度提高后显得具体。工具可以走完步骤，判断仍要有人负责。