事先声明：我开发了 代理原型，这是该市场中的工具之一。后半部分提到的基本操作是真实存在的，命令也是可验证的；前半部分提出的问题本身是成立的。欢迎指正——请提交问题报告。
你给了你的编码智能体一个 shell 权限。现在，你面临着两种糟糕的局面之一。
在第一种局面中，每个有风险的操作都会停下来询问你。我可以运行 git push 吗？我可以删除这个文件吗？我可以 curl 这个地址吗？ 你批准、批准、再批准——而在大约第二百次条件反射式的“是”之后，那个真正重要的请求就凭着肌肉记忆溜了过去。
在第二种局面中，你厌倦了那种方式，于是带着 --dangerously-skip-permissions（危险地跳过权限检查）参数运行智能体。现在它不再询问任何事。它也不会在错误目录下执行 rm -rf 之前询问，或者在你吃午饭时针对错误的 DATABASE_URL（数据库统一资源定位符）执行 DROP TABLE（删除表）之前询问。
如果你记不住其他内容，请记住这一个核心观点：
自动批准读取操作。严格管控写入操作。界限不在于“有风险 vs 安全”——而在于“这是否会改变状态”。
这两种局面都有一个共同的缺陷：它们将“智能体是否需要批准”视为你注意力的属性——即你愿意点击多少次——而不是操作本身的属性。纠正这一点，整个问题的形态就会发生改变。
每个人都画错了位置的界限
询问十个团队批准边界应该设在哪里，你会得到三个错误的答案。按工具类别划分：“shell 是危险的，文件读取是安全的”——除了 cat ~/.aws/credentials 是一种窃取数据的读取操作，而 echo 可能会覆盖文件。按可逆性划分：“阻止不可逆的操作”——除了你在调用时无法可靠地判断什么是可逆的。按感觉划分：全部跳过，直到出问题为止。
真正有效的界限更简单，而且与工具完全无关：
将界限划在状态变更处。 一篇被广泛引用的关于代码智能体人工监督的文章（作者：尼克拉斯·海德洛夫）得出了完全相同的规则：仅自动批准不改变状态的命令；严格管控那些会改变状态的命令。 不是按工具分类，也不是按可逆性分类——而是看操作后世界是否发生了变化。纯读取操作可以自由运行。写入操作必须等待。
以下是研究过这一问题的人们指出的原因，说明为什么“逐个批准”从来都无法拯救你：手动批准、全部跳过和静态允许列表都以同样的方式失效。 审查每个操作会导致批准疲劳——在数百次条件反射式的“是”之后，危险的操作也会得到一个“是”。跳过所有操作等于武装了智能体。静态允许列表在智能体需要新东西的那一刻就会失效。失败的原因不在于你的纪律性，而在于让人类充当运行时权限检查器。
这与关于信任的文章中提到的困境如出一辙，只是换了一种表现形式：你是串行瓶颈，而“批准每个操作”只是将瓶颈转移到了你的点击手指上。
如今如何管控有风险的操作？
在构建之前先审视自身。四个诚实的回答，每个都有其上限。
你逐个批准。 每个受控的操作都会向你发出提示；你点击“是”。相对安全，但完全无法扩展——这就是批准疲劳陷阱，其上限是你只能全职照看一个智能体。上限：你
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
