周五下午，你让一个 AI Agent 帮忙把下周出差定下来。它查了车次、比了酒店、填好了报销单，最后停在一个要输支付密码的弹窗前——这一步它做不了，也不该做。
这个停顿比它前面做的所有事都重要。市面上被叫作 AI Agent 的东西，真正的分水岭并不在它能不能拆解任务，而在于它有没有把手伸进你的账户、文件和日程里。会说话的系统出错，顶多给你一段错答案；会动手的系统出错，删掉的是真文件，发出的是真邮件。
风险从”信不信”挪到了”拦不拦得住”
聊天式工具的失败是可见的：你读完那段文字，觉得不对，重问一遍就行。Agent 的失败往往是静默的——它按自己的理解改了三行配置、给五个联系人发了同一封邮件，然后汇报”任务已完成”。等你发现时，动作已经落地。
这意味着评估一个 Agent 好不好用，光看它任务完成得漂不漂亮是不够的。更实际的问题是：它动手之前会不会问、动手之后留没留下痕迹、出了问题能不能倒回去。这三件事，和模型本身有多聪明关系不大，更接近工程约束。
权限该切到多细
常见的做法是给 Agent 一个账号，让它在这个账号能碰到的范围内自由行动。方便，但粗糙。账号权限是按人设计的，而 Agent 干活时需要的权限往往比人更窄、更短：读一份合同只需要几分钟，改一个单元格只需要一次。
- 能不能只给”读”，把”写”留给人来确认；
- 能不能限定在某个目录、某段时间内有效；
- 涉及对外发送、支付、删除的动作，是否一律中断等人；
- 同一件事重复执行时，有没有幂等保护，避免二次扣款或重复发送。
这些问题听起来琐碎，但它们决定了 Agent 是能放心交活儿的助手，还是需要一直盯着的不确定因素。
日志不是给审计看的，是给你自己看的
很多团队在接入 Agent 时，把注意力放在提示词和工具数量上，等到出问题才发现，没人说得清它到底调用了什么、传了什么参数、拿到了什么返回。可观测性在这里不是加分项，是底线。至少要能回放到”哪一步、因为什么、做了什么”，否则连复现都做不到，谈修复就是空的。
我倾向于一个朴素标准：如果一个 Agent 做的事，你没法用三句话向同事解释清楚它为什么这么做，那它就不该被放出沙箱。
有些活，先别急着交出去
任务链条越长，中间每一步的偏差都会累积。三五步的流程，人还能在关键节点抽查；二三十步的流程，人其实已经跟不上了，只能看最终结果，而这恰恰是最危险的形态——看起来全自动，实际上无人驾驶。
所以我的判断是，现阶段更适合让 AI Agent 接手那些失败代价低、可回滚、结果容易验证的环节，比如整理资料、生成草稿、批量重命名。至于对外沟通、资金相关、不可撤销的操作，让人留在回路里不是技术不够先进的表现，而是一种成本核算：拦一下的代价，远低于事后解释的代价。
那个停在支付密码前的 Agent，其实是个不错的范例。它不是能力不足，而是被正确地设计成在某个位置必须停下来。真正的成熟，可能不是让它走得更远，而是清楚知道该在哪里交还控制权。