如何安全地为它配一台电脑

文章开篇指出，仅能输出文本的大模型如同只会描述如何修水管的承包商，缺乏真正动手的工具。智能体的核心价值在于闭合这一缺口：让模型能够运行代码、读取结果、再次尝试，从而把原本需要人来完成的“拧螺丝”工作纳入自动循环。这就要求智能体拥有一个完整的工作环境，包括文件系统、Shell、包管理器、网络访问以及跨步骤可用的持久状态，而不仅仅是一个用于推理的上下文窗口。

['为什么不能直接把现有基础设施交给智能体？文章认为，智能体将要执行的代码可能未经任何人工审查就直接运行，来源可以是模型输出、克隆的仓库，甚至在执行过程中临时安装的第三方包。普通 Docker 容器与宿主机共享内核，无法在硬件层面隔离这类不受信任的执行。2025 年 npm 自复制蠕虫以及 2026 年披露的 Linux 内核漏洞都表明，标准容器边界已不足以防御模型生成代码带来的风险，因此需要更严格的隔离姿态。']

围绕“安全执行”这一核心需求，文章提出每个智能体工作空间都应当运行在独立内核、文件系统和网络边界的硬件虚拟化机器中，与开发机、生产环境以及并行运行的其他智能体工作空间完全隔开。在控制能力方面，沙箱应通过代理在网络层注入凭据，避免把 API token 直接暴露给智能体代码；同时设置 CPU、内存、网络白黑名单等资源上限，并允许环境在任务完成后自动销毁。

可观测性方面，文章强调智能体执行环境需要像审计日志一样记录命令、文件变更、网络请求、安装的包以及每一步输出，从而支持从已知状态重放任务、对比不同执行分支并定位真实发生的行为。这种级别的执行追溯是把智能体变成可信赖生产组件的关键，而不是停留在演示阶段。

文章还讨论了工程效率层面的要求：生产级沙箱需要在热启动时实现亚秒级供应，使用镜像或蓝图保证环境可复现，并在多轮交互间持久保留文件、安装包与会话上下文。如果启动一个执行环境需要三十秒，那么需要多次中间环境的任务就会显得迟缓；如果环境不可复现，缺陷就难以隔离。

在选型决策上，文章建议只调用固定 API、且不执行动态代码的智能体可以继续使用本地或容器化方案；而一旦涉及执行模型生成代码、安装依赖或处理任意文件，就必须引入真正的隔离与快照、分支、追踪等能力，否则将难以兼顾规模化部署与安全合规。

要点

• 智能体需要的不只是文本输出，而是具备文件系统、Shell 与网络访问的真实运行环境。
• 标准容器与宿主机共享内核，已无法防御模型生成代码带来的安全风险。
• 每个智能体工作空间应采用硬件虚拟化隔离，凭据通过网络层代理注入，避免暴露给执行代码。
• 可观测性要求记录命令、文件变更、网络请求等全量审计日志，以支持任务重放与回归对比。
• 只有 API 调用而无动态代码执行的轻量智能体，可以继续使用本地或容器化方案；其余场景则必须引入专业沙箱。