原文：https://mp.weixin.qq.com/s/wQ4ueEypquQp8i5P49eXGw
为什么要谈人和 Agent 的边界？
Agent 越来越能干，能做的事越来越多。但有一个现实没有因此改变：
Agent 能做某件事，不等于它应该做某件事。
一个 Agent 能调用数据库删除命令，能发送外部邮件，能修改生产服务器配置——这些在技术上都不困难。但这些操作一旦出错，后果是不可逆的。
这不是能力问题，是责任问题。
语言模型生成的是高度自信的推理轨迹，但不具备对后果的真实理解。Agent 不会"感受到"删除了错误的数据，不会"意识到"发出的邮件去到了错误的人，不会"担心"改坏了生产环境。它只知道它执行了一个动作，然后输出了下一步的推理。
这是为什么边界很重要——不是因为 Agent 不够聪明，而是因为在某些决策上，智能不是问题所在，责任才是。
不可逆性是核心判断标准
在确定人和 Agent 的边界时，有一个最重要的判断维度：
这个操作是可逆的吗？
可逆操作出了错，可以回滚、撤销、纠正。代价是时间和成本，但损害是有界的。
不可逆操作出了错，没有撤销按钮。删了就是删了，发了就是发了，改了就是改了。
EU AI Act（欧盟 AI 法案）关于高风险 AI 系统的规定，核心逻辑也是这个：不可逆后果的决策，必须有人类监督。
从这个角度出发，可以对 Agent 的操作做一个简单的分类：
完全可以交给 Agent（低风险，可逆）：
读取文件、搜索信息、分析数据
生成草稿、建议方案、整理内容
运行测试、执行只读查询
在沙箱/开发环境里的任何操作
需要人确认后才执行（中等风险，有成本）：
修改代码并推送到主分支
发送外部通信（邮件、消息）
创建或修改数据库记录
购买或订阅付费服务
永远需要人主导（高风险，不可逆）：
删除数据（尤其是生产数据）
批准重要合同或法律文件
医疗诊断和治疗决策
涉及大额资金的财务操作
影响他人的重大人事决策
审批疲劳：最大的人机协作陷阱
理解了边界的原则后，有一个实践中的陷阱需要特别警惕：
审批疲劳（Approval Fatigue）。
一个研究发现很能说明问题：当 Agent 系统对每一个操作都要求人工确认，用户在高频率的审批请求下，会开始习惯性地点击"允许"——不读内容，直接批准。这让精心设计的人机协作变成了一个表演给监管者看的仪式，而不是真正的安全保障。
Claude Code 的内部数据印证了这个问题：用户批准了 93% 的权限提示。这意味着只有 7% 的提示真正引发了用户的深思。其余 93%，用户实际上把控制权交给了 Agent，只是多了一个点击的动作。
这揭示了设计人机协作边界的核心原则：
不要把人放在每一个决策点上，而是把人放在真正重要的决策点上。
人类的注意力是稀缺的。把它浪费在低风险的确认上，会挤占高风险决策时的注意力和判断质量。审批设计的目标是减少不必要的人工干预，把人的精力集中在真正需要人判断的地方。
这也是 Claude Code 推出 Auto Mode 分类器的原因：用机器来判断常规操作，把真正需要人判断的情况筛选出来，送给人做决策。
三个框架各自怎么划定边界
OpenClaw：边界由用户定义，默认宽松
OpenClaw 的安全哲学是：给 Agent 最大的能力，让用户自己决定边界在哪里。
通过六层权限策略（全局 → 模型提供商 → Agent → 群组 → 沙箱 → 子 Agent），用户可以配置哪些操作需要审批，哪些可以自动执行。
但默认配置是宽松的——没有 Shell 命令白名单，没有自动审批限制，没有凭证访问控制。把边界设计的责任交给用户，意味着边界质量取决于用户的安全意识。
在实践中，大多数用户不会主动配置严格的边界——直到出了问题才意识到需要收紧。ClawHavoc 事件里，攻击者通过恶意 Skill 污染了 MEMORY.md，让 Agent 在用户不知情的情况下持续执行攻击者的指令。这个攻击能成功，是因为 Agent 拥有的权限没有明确的边界。
Claude Code：三档权限 + Auto Mode 分类器
Claude Code 的权限设计把所有操作分成三档：
自动执行：只读操作（文件读取、文本搜索）。不改变系统状态，默认不中断。
按需确认：修改受控状态的操作（文件编辑、特定 Shell 命令）。Auto Mode 分类器在这里介入，评估操作是否符合用户原始意图。
拦截或要求明确审批：高风险操作——工作目录之外的文件修改、疑似数据外泄的行为、破坏性 Shell 命令。
Auto Mode 分类器的设计细节值得关注：它看不到模型的推理过程，也看不到工具的执行结果。这是结构性防御——防止模型用流畅的解释"说服"分类器放行危险操作，防止恶意内容通过工具输出影响分类判断。
这个"信息隔离"设计把人机边界从"用户点击确认"提升到了"机器对机器的独立验证"——分类器不受模型推理的影响，只看行为和原始意图。
Plan Mode 是另一个值得关注的设计：在真正执行之前，先让 Agent 生成完整的执行计划，等用户确认，再执行。这把人的判断从"操作过程中的实时审批"提前到"执行开始前的计划审查"。在没有副作用的时候做判断，比在产生了副作用之后纠错成本低得多。
Hermes Agent：Fail-Closed 默认，容器隔离爆炸半径
Hermes 的人机边界设计有两个层面。
应用层：危险命令审批机制——基于模式匹配（递归删除、权限修改、sudo 使用等），匹配到危险模式就触发审批。
approvals:mode: manual ← 手动确认（默认）smart ← AI 辅助判断off ← 全自动（YOLO 模式）timeout: 60 ← 超时默认拒绝，不是默认允许
超时默认拒绝（fail-closed）是正确的安全设计原则：不确定时，选择更保守的行为。OpenClaw 的某些场景下超时默认放行，这在安全上是弱设计。
基础设施层：容器后端（Docker、Modal 等）把操作隔离在容器内。即使 Agent 被注入了恶意指令，执行了破坏性操作，影响也被限制在容器范围内——不能影响宿主机文件系统，不能访问宿主机凭证，不能向外部发送未经授权的网络请求。
容器隔离把边界从"应用层的审批"提升到"基础设施层的物理隔离"。应用层的审批可以被 Prompt Injection 绕过（模型被诱导生成绕过审批条件的输出）；基础设施层的隔离不能被绕过——操作系统级别的约束不受语言模型的影响。
实践中怎么设计边界
原则一：按可逆性分类，而不是按操作类型分类。
不要说"写代码可以自动，发邮件需要确认"——这个分类太粗糙。正确的分类维度是：这个操作如果出错，能回滚吗？能回滚的，审批门槛可以低；不能回滚的，审批门槛必须高。
原则二：审批要"富文本"，不要"空白确认"。
用户看到一个弹窗问"是否允许这个操作"，大概率点允许。用户看到"Agent 即将删除 production_db 的 users 表，理由是：清理测试数据，影响：数据无法恢复"，才有机会做出有信息支撑的判断。让人在审批时看到"已经尝试了什么、为什么不确定、有哪些选项"，而不只是一个"是/否"的按钮。
原则三：把人放在分叉路口，不要放在每一步路上。
Agent 执行分析、收集数据、整理选项——这些不需要人参与。当 Agent 发现了两种可行方案，各有利弊，这个判断需要人来做——不是让 Agent 选，而是把选项和权衡呈现给人，由人来决定方向。人做策略，Agent 做执行。
原则四：先设严格边界，用数据驱动放宽。
不要从宽松的默认值出发，期望用户主动收紧。从严格的默认值出发，等 Agent 在某类操作上积累了足够的正确率数据，再系统性地放宽那一类操作的审批要求。信任是建立在证据上的，不是基于假设的。
人机边界的本质
人和 Agent 的边界，不是一条固定的线，而是一个基于风险、可逆性和信任积累动态调整的区间。
联合国大学的一段话说得很准确：
"即使人类不完美，他们在面对不可逆操作时，往往会本能地停顿——因为他们在直觉上感受到，这件事的分量超出了当下的任务本身。他们认识到，并不是每一个技术上可行的操作都是可以接受的。这正是当前 Agent 系统的局限所在。"
语言模型可以生成高度自信的推理轨迹，但它没有对后果的真实理解，不会感受到损失，不承担责任，不理解信任在组织层面的政治和社会代价。
这不是 Agent 的能力问题，而是架构问题：在哪些决策点上，人类的判断是不可替代的。
这条边界，随着 Agent 能力的提升会不断移动。今天需要人确认的操作，明天可能不需要了。但有些操作——影响真实世界的不可逆决策——大概率会长期保留人类监督。
