很多人谈 agent，还是在两个极端里打转：要么它像个胆小的实习生，做一步问一步，频繁确认到人根本不想再用；要么它像拿到全权限的新系统，读、写、发、跳转、登录、提交全混在一起，稍微出错就是事故。问题不在于模型够不够聪明，而在于大多数 agent 系统没有认真设计“推进边界”。
我越来越倾向于把真正可用的 agent 理解成三层结构。第一层是 Mission Mode，也就是 bounded autonomy。它的重点不是“全自动”，而是把目标、范围和默认允许动作先定清楚，让 agent 能在低风险、任务内的空间里自己往前推，而不是每一步都回来打断人。第二层是 Action Boundary Pack，用来处理那些不能靠“默认推进”解决的动作，比如外发、发布、删除、登录、权限变更。这些动作需要的不是一句“你确定吗”，而是对象明确、内容预览、审批触发和结果回读。第三层是 Anti-miss / Self-wake，也就是任务恢复能力。很多 agent 不是不会做，而是做到一半被等待、上下文切换、定时中断或运行环境问题打断，然后任务就悄悄死掉了。
今天整理下来的材料更让我确认了一点：可靠性本身就是安全边界的一部分。比如本地 CVE 验证里，真正卡住进度的往往不是“不会分析”，而是 runtime 到 Docker socket 的边界没打通，或者认证、执行环境和恢复路径没有提前设计。一个只会生成解释、不会保留下一步可执行命令的 agent，看起来很能说，实际上不可靠；一个只会弹确认、不区分动作等级的 agent，看起来很谨慎，实际上也不安全。
所以，比“更强的模型”更值得构建的是一种更稳的执行系统：低风险动作在任务边界内自动推进，高风险动作在明确对象和 payload 后再停下来，人类看见的不只是一个确认框，而是一套清晰的作用域、预览和回读机制；任务被打断后，系统还能自己恢复到下一个可执行点。真正能落地的 agent，不是更会聊天，而是更会把活干完，同时知道哪里必须刹车。