LangChain：让 agent 拥有自己的计算机

LLM 可以进行推理。但光有推理，还做不成多少事。

在 AI agent 中运行代码执行，难度比看上去更大。你的 agent 需要一台真正的电脑（文件系统、shell、包管理器、持久状态），但把它交到你的基础设施里又很危险。

可以这样理解：你只用一台笔记本电脑。你是独一无二的一个人。但 agent 将要运行数百万个任务，而每个任务都需要一台属于自己的电脑来工作。这就是当下正在发生的基础设施转变。Satya Nadella 说得很直白：“每个 agent 都需要一台电脑。”问题在于，这台电脑应该长什么样，以及你要如何安全地把它提供给它们。

LangSmith Sandboxes 就是我们给出的答案。下面是它重要的原因，以及为什么自己动手做比听起来要难得多。

想想 Cursor、Claude Code，或者 ChatGPT 的代码解释器，能做的是普通聊天界面做不到的。它们不只是回答问题：它们会运行代码、查看报错、修复问题、再运行一遍，然后把可用的结果交给你。正是这个反馈闭环让它们变得有用。

同样的闭环，也把演示用的 agent 和生产级 agent 区分开来。一旦你的 agent 能执行操作，一整类工作就被打开了：

一个 coding assistant 不只是建议修复方案：它会直接应用修复、运行测试，并确认没有引入破坏

一个 data analyst 会拉取 CSV，用 Python 对它进行处理，然后交给你一份格式化报告

一个 CI 智能体：克隆你的仓库、安装依赖、运行完整测试套件，并发起一个 PR（就像 OpenSWE）

一个研究智能体：会浏览、抓取、综合并写作——不只是搜索

一个内容流水线：生成、渲染并导出最终成品

一个 RL 或评测 harness：需要并行启动环境，以突发规模运行 episode，并立即将其销毁——从零到成千上万个沙箱，再回到零

共同点在于：这些智能体需要的不只是一个 token 流，它们还需要一个可以工作的地方。

一个显而易见的下一个问题是：为什么不直接让智能体在本地运行代码？或者放到 Docker 容器里？团队在早期原型中确实会这么做。但到了生产环境，这种做法会因为两个原因而失效。

第一：按定义，智能体会运行不受信任的代码。

你的智能体执行的代码可能来自模型、用户提示、克隆的仓库，或者已安装的包。这些代码不是你写的，你也无法完全审查它们。2025 年 9 月，一个名为 Shai-Hulud 的自我复制 npm 蠕虫在任何验证能够执行之前，就通过 preinstall 阶段植入了 500 多个包的后门。到了 11 月，第二波攻击又在数小时内波及另外 796 个包和 25,000 多个 GitHub 仓库。如果智能体把安装 npm 包作为工作流的一部分，它暴露的正是这种风险。

第二点：容器还不够。

常见的第一反应是：“直接放到 Docker 里跑就行了。”容器非常适合隔离已经确认、经过审查的应用代码（比如 Web 服务器、后台任务）。但它们并不是为这样的 agent 设计的：它要安装任意依赖、运行模型生成的脚本，并在一个长时间运行的会话中持续保存状态。更关键的是：容器与宿主机共享内核。内核漏洞可以穿透这层隔离。Copy Fail（CVE-2026-31431）就是一个只有 732 字节的 Python 脚本，它利用 kernel crypto API，通过内核把自 2017 年以来的所有主流 Linux 发行版都提权到 root。AI 工具大约用了一小时就找到了它。

容器边界不是隔离边界。对于不可信、由模型生成的代码，你需要的是硬件级隔离。

这里有一个有帮助的心智模型：sandbox 需要同时满足两件事。它需要像 serverless 函数一样瞬时启动，因为你不能让 agent 为了等虚拟机启动而白白等两分钟。它还需要像一台完整机器一样具备状态，因为 agent 不是无状态的请求处理器；它们是在会话中工作的任务执行者，会安装依赖、编辑文件，并在上次停下的地方继续执行。

LangSmith Sandboxes 正是为这种模型打造的。每个 sandbox 都是一个经过硬件虚拟化的 microVM。不是容器，而是一台拥有自己内核的完整机器。agent 可以：

它可以安装包、运行脚本、编辑文件、启动本地服务器，并在长会话中持续工作——整个过程都不会触碰你的生产基础设施，也不会影响其他 agent 的 sandbox。工作完成后，sandbox 就会消失。

你可以通过你已经在使用的同一个 LangSmith SDK 和 API key 来访问它：

只需一次调用，你的 agent 就拥有了一台电脑。

对于运行 GPU 工作负载的团队来说，还有一个不那么显眼的好处：当你的沙箱能瞬时启动时，GPU 就不会因为等待 CPU 计算资源完成预配而空闲。更快的沙箱会放大 GPU 的利用效率——而这一细节在规模化场景下会很快累积成显著差异。

沙箱不仅仅是运行代码的地方。GA 版本还提供了一组原语，让 agent 工作流可以直接用于生产环境：

快照和分叉：在会话进行中捕获一个沙箱状态，并基于它启动新的沙箱。分叉采用写时复制，因此同时启动 10 条并行分支的成本大致与启动 1 条相同。当你的 agent 走错方向时，可以直接恢复并重试，而不必从头重建。

预热环境蓝图：定义一个基础镜像（仓库已克隆、依赖已安装、配置已就绪），然后在几秒内而不是几分钟内基于它启动沙箱。

服务 URL：如果智能体启动了一个本地 Web 服务器——比如用于预览生成的报告——你会得到一个经过身份验证的 URL，可以在浏览器中打开，或者分享给同事。无需端口转发。

认证代理：来自沙箱的出站请求会通过一个代理，代理会在网络层注入凭证。密钥不会接触智能体运行时。

默认仅创建者可见：只有启动某个沙箱的用户（以及工作区管理员）可以访问它。准备好之后再共享。

当你的智能体需要做某件事，而不只是说说而已时，沙箱就是合适的层。具体来说：

你的 agent 会生成代码，而你希望它在回复前先验证这段代码能够运行

你正在构建一个编码助手、CI agent，或者一个会操作真实文件的数据管道

你在运行多步骤工作流，状态需要在多次工具调用之间保持

你需要突发容量（也就是用于 RL 训练或评估的成千上万个并行环境），而且必须在几秒内从零扩展起来

你正在接受任何可能最终会被执行的用户输入

如果你的智能体只会调用固定 schema 的 API，且从不执行动态代码，那么沙箱就显得过度了。一个检索型智能体如果只是搜索文档并返回引用，就不需要沙箱。一个会编写并运行 Python 脚本的智能体则需要。

在 monday.com，Sandbox 为他们的 Sidekick AI 助手提供支持，为其提供一个安全环境，用于编写和运行代码，以处理更高级的用户工作流，包括数据分析和多媒体生成。

“LangSmith Sandboxes 正在帮助我们让 Sidekick 对 monday.com 用户更有能力。借助安全环境，Sidekick 可以编写和运行代码，并利用结果创建更丰富的工作流，比如运行数据分析和生成多媒体。”

—— monday.com AI 平台组经理 Omri Bruchim

在过去几年里，让智能体变得更强大，意味着给它更好的工具：搜索 API、计算器、数据库连接器。这仍然成立。但预定义工具所能做到的上限并不高。

那些真正会取代工作流（而不只是辅助工作流！）的智能体，是能够拿起自己需要的任意工具、运行它、查看结果并作出调整的智能体。拥有一台电脑，才能让这一切成为可能。这不是基础设施层面的细节，而是一个智能体能思考与能行动之间的区别。

你只用一台笔记本电脑。你的每个智能体都需要自己的。LangSmith Sandboxes 就是用来把一台这样的环境交给它们。

开始使用：试试 LangSmith Sandboxes，或阅读文档。

LangSmith 是我们的智能体工程平台，帮助开发者调试每一个智能体决策、评估变更，并一键部署。