智能体需要自己的计算机：如何安全地赋予它们

在计算机历史的大部分时间里，开发者环境意味着物理机、虚拟机或容器，每一个都共享工作负载，需要刻意搭建和拆除。为每个智能体提供独立的计算机——在一秒内启动并在任务完成后自行清理——在规模化之前并不实用。沙箱为您提供了一种更安全的方式来运行升级的工作流，它提供了一个隔离的环境，用于执行需要迭代、验证和访问人类通常使用的工具的任务，而无需人工监督。每个人类开发者都有一台笔记本电脑，每个智能体都可以拥有一台计算机。

为什么智能体需要自己的计算机

让LLM调试失败的测试或清理数据集，它大部分工作都能完成。它可以解释修复方法、编写查询、概述分析。然后它停下来，你必须接手所有剩下的工作。问题在于，一个只能生成文本的系统就像一位承包商，能精确描述如何修理你的水管，但没有手、没有工具、没有卡车。建议可能完美，但总得有人去扳动扳手。

智能体通过获得“手”来缩小这一差距。让模型能够运行代码、读取结果并重试，完整的智能体循环使智能体能更自主地执行任务。一个只能建议修复方案的智能体无法知道修复是否有效。这就是智能体需要自己计算机的原因：一个真正的环境，包含文件系统、Shell、包管理器、网络访问和跨步骤持久化的状态。

而当你只有一台笔记本电脑且可能只有你使用时，一个智能体平台可能会同时启动数千个这样的环境，每个都需要隔离、可丢弃且安全地交予实际执行能力。

实际上意味着什么

• 编程智能体可以克隆仓库、安装依赖、运行测试套件、读取失败信息、修补代码，并返回已验证通过的差异。
• 数据分析智能体可以加载原始文件、检查模式、用Python或SQL编写转换、生成图表，并在向你展示报告前检查自己的数学。
• 研究智能体可以浏览网页、下载来源、解析并规范化、交叉引用声明，并汇编带有引用的完整报告。

在每个例子中，模型都在运行实际步骤并检查实际结果。这需要一个工作场所，而不仅仅是一个推理的上下文窗口。

为什么不能直接把基础设施交给它

那么为什么不让智能体在本地或Docker容器中运行代码呢？大多数原型从本地开始：快速、熟悉，足以让演示工作。然后进入生产环境，同样的设置会在两个方面开始失效：安全性（智能体要运行的代码可能由人类未编写、审查甚至未见）和隔离性（标准容器边界并非为保存不受信任的模型生成代码而设计）。

虽然你的智能体没有恶意，但你不知道代码来自何处。一行代码可能来自模型本身、克隆的仓库或中途安装的包。智能体执行的代码可以在运行前几秒生成，直接受用户输入影响，并在智能体推理任务过程中产生。中间没有审查步骤。写得好的提示词并不能让你免于安全顾虑。最安全的姿态是机器级隔离：给智能体一个真实的工作环境，但将该环境与你的笔记本电脑、生产环境以及所有其他智能体的工作空间隔离开。

每个智能体计算机需要做好的四件事

1. 安全执行：2025年，一个自我复制的npm蠕虫后门了数百个包，并在任何测试运行前在预安装钩子中执行。2026年披露的Linux内核CVE可以用732字节的Python脚本在一小时内获取任何主要发行版的root权限，而容器无法帮助，因为它们与宿主机共享内核。智能体执行的代码应默认视为不可信，不论来源。每个智能体工作空间应是一个硬件虚拟化的机器，拥有自己的内核、文件系统和网络边界。

1. 保持控制：沙箱内的控制保护你免受智能体做出昂贵、意外或泄露凭据的行为。凭据管理：通过代理在网络层注入凭据，智能体可以调用外部服务而无需看到令牌。资源限制：CPU限制、内存上限和网络白名单/黑名单让你为每个任务定义成本上限。生命周期控制：沙箱默认是临时的，为任务启动，需要时持久化状态，空闲时清理。

1. 可观测性：智能体执行的可观测性意味着知道哪些命令运行了、哪些文件被创建或修改、哪些网络调用发出、哪些包被安装、每一步的输出是什么。这本质上是工作流的审计日志，尤其对于接触敏感数据或具有真实世界后果的行动。使智能体可靠的是能够从已知状态重新运行、比较分支并追溯实际发生情况的能力。

1. 快速构建和迭代：生产要求包括快速配置（热启动低于1秒）、可复现环境（由Docker镜像或蓝图定义）和持久化状态（文件、已安装包和会话上下文在智能体轮次间保持）。如果启动执行环境需要30秒，需要多个环境的智能体任务会感觉缓慢。如果环境不可复现，bug难以隔离。如果状态不跨会话持久化，长时间运行的任务需要昂贵的重启。

何时使用托管沙箱与自行构建

你可以DIY方式：在开发者笔记本上运行智能体，升级到Docker容器获得一定分离，手动配置资源限制和凭据注入。对于只调用固定模式API且从不执行动态代码的智能体，这通常足够。当你想扩展到生成脚本、安装包、运行测试套件或解析文件时，你必须为每个任务启动虚拟机、安全注入凭据而不接触运行时、构建快照和分支支持、记录执行轨迹并将其关联到智能体轨迹、处理清理、空闲检测和配额管理。决策标准：如果智能体只调用API且不执行动态代码，本地或容器化执行可能没问题。如果智能体执行模型生成的代码、安装包或处理任意文件，则需要真正隔离，从头构建意味着你在构建一个沙箱平台。DIY方法的生产级运营开销迅速增加。托管沙箱路径用更简单的接口和平台处理工作规模来换取工程面。

LangSmith 沙箱：每个智能体一台计算机

每个LangSmith沙箱启动快（中位时间低于1秒），作为硬件虚拟化的微虚拟机运行，有自己的内核，并在智能体工作会话中持久化状态（文件、已安装包、环境）。任务完成后，沙箱空闲并自动清理。容器与宿主机共享内核，而微虚拟机有自己的。在沙箱内，智能体可以安装任何东西、运行Docker、启动服务——而你的基础设施和其他工作负载不受影响。

核心原语包括：微虚拟机隔离（每个沙箱内核隔离，不影响其他）、快照和分支（捕获运行状态，写时复制分支，从快照并行启动十个分支成本与一个类似）、认证代理（出站请求通过代理注入凭据，凭据不接触运行时）和服务URL（通过认证HTTP访问沙箱内运行的任何服务，无需端口转发）。

一键设置示例：

from langsmith.sandbox import SandboxClient
client = SandboxClient()
with client.sandbox() as sb:
    result = sb.run("python my_analysis.py")
    print(result.stdout)

沙箱与Deep Agents、Open SWE、LangSmith Deployment、LangSmith Fleet以及任何自定义代码兼容。它们使用与LangSmith其余部分相同的SDK和API密钥。

沙箱工作流中的提示注入注意事项

沙箱提供了强大的执行隔离，但它们不改变语言模型的一个基本属性：智能体读取的任何内容都会影响它下一步做什么。当沙箱输出被反馈给模型时，这一点很重要。一个示例担忧是：研究智能体下载文档，文档包含看似给模型指令的文本，模型遵循它。这是LLM应用OWASP Top 10中的#1漏洞，适用于任何处理外部内容的智能体。沙箱不会消除注入威胁，但它们会限制执行爆炸半径。在沙箱内运行的恶意代码无法到达宿主机，但如果执行输出未被质疑地由智能体读取，输出中的注入指令仍可能影响下游行为。

缓解措施包括：将沙箱输出视为不可信数据；对于最敏感的工作流，使用“非智能体读取”模式，由非模型进程从沙箱检索成品；限制跨边界智能体的本地访问权限；在边界应用输出过滤，如结构化输出模式、内容分类器或格式验证；不要依赖提示让模型检测或忽略注入，对抗性研究一致表明这在规模上不足。这些并非沙箱独有，任何从网页读取、处理上传文件或调用外部API的智能体都有相同暴露。沙箱的附加价值在于帮助控制执行损害，且两层都需要。

使用案例：编程智能体

编程智能体是沙箱的流行用例，因为执行隔离非常重要。一个能运行测试套件、检查失败、修补代码并重新运行测试套件的智能体比仅能生成补丁并交回给开发者验证的智能体有质的不同。沙箱中的编程智能体可以克隆仓库并运行完整设置脚本（包括npm install、pip install等）而不触及开发者机器；针对当前代码状态运行测试套件、读取失败输出、尝试修复、重新运行测试并交付已验证的补丁；处理多个并行分支，每个分支都有自己的沙箱，比较不同方法的结果；安装和测试依赖项，而无需在本地机器上安装包。

编程智能体是沙箱工作的典型示例，因为安全边界直接转化为开发者信任。如果你相信智能体不能损害你的环境，你就更可能让它自主运行。