别给 AI 智能体 root 权限，让它们提议下一个系统状态。
内容提要
文章讨论自主智能体操作机器的安全边界，主张不应授予其生产系统root权限，因为智能体具有非确定性且难以追溯。应通过容器隔离、不可变系统和软件工厂来约束：智能体只能检查状态、提出变更建议，变更经审查、测试、构建、签名后生成新镜像，再由系统消费。核心在于信任边界与流程，而非模型本身。
延伸解读
为什么 root 权限对智能体是错误抽象
文章指出，给智能体 root 权限就像给人类无限制 root 一样危险。智能体具有非确定性，即使有 AGENTS.md 也无法保证结果可复现。问题不在于 API 可能出错，而在于无法追踪谁或什么改变了系统。生产环境需要可追溯性，而 root shell 无法提供从意图到可审查状态的明确路径。
不可变系统如何约束智能体行为
不可变系统将基础系统视为整体镜像，运行时只读或按单元更新。智能体可以检查状态，但变更必须通过版本化定义并构建新镜像。这样，运行时不再是即兴修改的地方，而是执行已定义状态的场所。即使出错，也能通过来源追溯定位到具体提交和镜像。
智能体自身也是工作负载
智能体软件通常不来自发行版，可能通过 npm、独立二进制或容器镜像安装。本地 harness 可能通过文件系统、凭证、套接字等与主机相连。因此，智能体应作为短期工作负载运行在隔离环境中，执行边界需匹配威胁模型。标准 Pod 可能适合范围窄的智能体，而运行不可信代码的智能体可能需要沙箱 Pod 或 VM。
闭环反馈：提议而非直接修改
智能体可以诊断问题、提出修复建议，但不应通过 root 直接应用变更。自我修复是从已授权响应中选择，如重启或回滚；自我改进是提议未授权的系统状态，必须经过软件工厂：审查、测试、构建、签名、发布，再由系统消费。智能体身份应能提议但不能批准、合并、修改流水线或强制消费镜像，否则只是 root 加更多步骤。
Q&A
为什么不应该给AI智能体生产系统的root权限？
因为智能体具有非确定性，无法保证结果，且难以追溯变更。就像不应给人类无限制的root权限一样，给智能体root权限会导致不可复现和无法追踪的问题。
容器技术如何帮助限制智能体的权限？
容器通过将应用的用户空间依赖打包在一起，实现了应用与宿主系统的关注点分离。宿主只需负责启动、提供内核和运行时，平台管理容器化应用，从而限制了智能体对宿主系统的直接影响。
不可变系统在智能体操作中起什么作用？
不可变系统通过只读挂载或整体镜像更新，防止运行时漂移。智能体可以检查系统状态，但变更必须通过版本化定义和新镜像来消费，从而提供从意图到可复现系统状态的明确路径。
智能体如何在不直接访问宿主的情况下提出系统变更？
智能体可以在隔离的工作负载中运行，检查系统状态并记录评估，然后通过拉取请求提出变更建议。该建议经过审查、测试、构建、签名和发布后，生成新镜像，再由系统消费。
软件工厂在智能体驱动的系统中扮演什么角色？
软件工厂是将提议的变更转化为运行产物的机制，包括源代码控制、审查、CI、测试、镜像构建、签名、发布和部署。它确保智能体的提议经过与人类变更相同的流程，实现可追溯和可复现。
为什么仅靠不可变系统不足以保护主机？
因为不可变系统并非完全不可变，且智能体可能通过文件系统、凭证、工具、套接字、网络访问等与主机连接。如果智能体拥有不受限制的主机、内核或磁盘访问权限，不可变性无法提供保护。
