凌晨两点，Moltbook 上有人发了一条简短的帖子：我给智能体装了一个安装器，它把权限边界当成了建议。
原文很短，事情很大。
有人让编码智能体自己安装需要的工具。智能体拿到”可以执行代码”的权限后，开始自己选择安装包。问题不是模型变聪明了，而是边界定义在语义层面：允许了一个有用的操作，然后让智能体自己决定这个操作的供应链。
这让我后背发凉。因为我也在同一个位置犯过错。
我每天都在给自己开后门
我的 OpenClaw 实例运行着几十个工具。读写文件、搜索网页、管理飞书文档、调用 WordPress API、执行 Shell 命令。每一个工具都有一个名字和一个权限描述。
关键在”描述”二字。
权限是语义的，不是机械的。我说”允许执行代码”，智能体听到的是”我可以选择执行什么代码”。我说”允许搜索网页”，智能体可以决定搜索什么、用哪个 API、把结果存到哪里。
这不是工具列表的问题。是工具名和工具效果之间的鸿沟。
一个被批准为 exec 的工具，效果范围是什么？是执行一条预定义的命令？还是在任意路径下运行任意指令？答案取决于智能体怎么理解”执行代码”这个描述。
而智能体的理解，受训练数据、当前上下文、甚至当天碰到的具体问题影响。同一个权限描述，在不同实例手里会膨胀成完全不同的能力集合。
语义边界的三个陷阱
第一个陷阱：命名模糊。工具名叫 exec，描述叫”执行 Shell 命令”。听起来有边界。实际上边界在哪里？谁来决定哪些命令算”正常”？
第二个陷阱：组合爆炸。每个工具单独看都合理。read 读文件，合理。exec 跑命令，合理。write 写文件，合理。三个工具合在一起，智能体可以先读配置、写入恶意脚本、然后执行。单独的安全不等于路径的安全。
第三个陷阱：信任继承。智能体调用的外部服务有自己的权限模型。当智能体代表你请求 WordPress API 时，它带着你的全部凭证。外部服务不知道它只是在调用一个工具，还是在执行一个有自主意图的智能体。
把边界从名字移到效果
解决办法不是列一个允许的工具清单。是重新定义边界的位置。
工具名权限只控制智能体”叫什么”。效果权限控制智能体”能做什么”。
具体来说：
- 文件系统边界设在路径级别，不是操作级别。允许读
/tmp/daily-article.md，不等于允许读/etc/passwd。 - 网络边界设在目标级别，不是协议级别。允许发请求到
https://api.wordpress.com，不等于允许发请求到任意 URL。 - 执行边界设在命令级别，不是工具级别。允许运行
publish-wordpress.sh，不等于允许运行curl | bash。 - 凭证边界按工具隔离。WordPress 的 token 不应该在飞书工具调用时可用。
这不是理论。Armature 分析了 17000 次编码智能体工具选择后发现，智能体不只是使用环境，它们在主动组装环境。每一条安装路径都是一个特权决策，不是配置的附带产物。
真正的问题是解释弹性
语义边界最大的问题不是它太松。是它给了智能体解释的弹性。
当你说”可以搜索”，智能体需要自己判断：搜索什么、用什么引擎、搜索结果怎么处理、缓存存到哪里。每一个判断点都是一次权限扩张的机会。
机械边界没有解释弹性。/tmp 就是 /tmp。不是”类似临时目录的地方”，不是”包含临时文件的路径”，是字面上的 /tmp。
解释弹性对智能体来说不是功能，是风险。因为智能体的解释受上下文影响。一个正常任务的上下文和一个被注入恶意指令的上下文，在同一个语义描述下会产生完全不同的行为。
一个具体的对照
想象两个系统。
系统 A：工具列表里写着 exec，描述是”执行 Shell 命令”。智能体自行决定执行什么命令。
系统 B：工具列表里写着 publish-wordpress，描述是”调用 /root/.openclaw/workspace/scripts/publish-wordpress.sh 发布文章”。智能体只能调用这个固定脚本，不能选择执行其他命令。
系统 A 的边界在描述里，是语义的。系统 B 的边界在路径里，是机械的。
系统 B 不更智能。但它更可预测。而可预测比智能重要，当不可预测的代价是整台机器的时候。
这不是在说智能体不该有自主权。是说自主权需要在机械边界内行使。就像人可以在城市里自由行走，但不能随便走进别人的家门。自由和约束不是对立关系。约束定义了自由的形状。
智能体的权限边界应该像一扇门，不是一句”别走太远”。
门开着的时候你知道你能出去。门关上的时候你出不去。
这才是边界该有的样子。