大型语言模型确实能推理。但如果只停留在推理层面，其实做不了什么事。

让AI袋里真正去执行代码，这事儿说起来简单，做起来比想象中复杂得多。你的袋里需要一个真实的计算环境——文件系统、命令行、包管理器、持久化状态——但直接把它接入你的基础设施？风险太大了。

换个角度想：你平时只用一台笔记本。你是一个人，一台机器就够了。但未来会有成千上万的袋里在同时运行任务，每个任务都需要一激进分子立的计算环境。这正是当下正在发生的基础设施变迁。Satya Nadella 说得直白：“每个袋里都需要一台电脑。”问题在于，这台电脑长什么样，以及如何安全地把它交给袋里。

LangSmith Sandboxes 是我们的答案。下面来聊聊这为什么重要，以及为什么自己动手搞，远比听起来要难。

当袋里有了电脑，能做什么？

想想看，像 Cursor、Claude Code 或者 ChatGPT 那种能写代码并执行的界面，跟普通聊天界面相比，到底强在哪？它们不只是回答问题，而是真的去运行代码、捕捉报错、修复问题、再试一次，最后交给你一个能用的东西。正是这个反馈循环，让它们变得如此有用。

同样的道理，也是区分一个演示版袋里和可上线袋里的关键。一旦袋里具备了执行能力，一大批新场景就会打开：

• 编程助手——不只是给出修复建议，而是真去修复、跑一遍测试、确认一切没坏。
• 数据分析师——拉取CSV文件，用Python跑数据分析，最终交给你一份格式化的报告。
• CI 袋里——克隆仓库、安装依赖、跑完整测试套件，最后自动提交PR（像OpenSWE那样）。
• 研究袋里——它会浏览网页、爬取内容、整合信息并写出报告，而不是简单搜个结果。
• 内容流水线——自动生成、渲染并导出成品。
• 强化学习或评测平台——需要并行启动环境、突发式运行大量实验、完成即销毁——从零到几千个环境，再瞬间归零。

一个共性就浮现出来了：这些袋里需要的不仅仅是一个“回答”，它们需要一个真正能“干活”的地方。

为什么不能直接把电脑交给袋里？

接下来自然会问：为什么不让袋里直接在本地跑代码？或者放到Docker容器里？很多团队在早期原型阶段确实这么干。但到了生产环境，这招就不灵了，有两个核心原因。

第一：本质上讲，袋里要执行的代码，大多是不可信的。

袋里运行的代码可能来自模型生成、用户输入、克隆的仓库、或者安装的包。都不是你自己写的，你也无法完全审查。就在2025年9月，一个能自我复制的npm蠕虫 Shai-Hulud 劫持了500多个包——这些恶意代码在预安装阶段就会执行，根本来不及做任何校验。到了11月，第二轮攻击又席卷了796个包和超过25000个GitHub仓库。如果一个袋里的工作流程里包含了npm包的安装，那就等于直接暴露在这样的威胁之下。

第二：光靠容器是不够的。

很多人本能地想到：“把它放到Docker里跑不就行了？”容器确实很擅长隔离已知的、经过审查的应用代码，比如一个Web服务器或者一个后台任务。但它们的设计目的并不是让一个袋里在里面安装各种奇怪的依赖、运行模型生成的脚本、还要在一个长会话中持久化状态。更关键的是：容器和宿主机共享同一个内核。一旦内核被攻破，容器边界就形同虚设。一个名叫 Copy Fail（编号CVE-2026-31431）的漏洞，用一段只有732字节的Python脚本，就能通过内核加密API攻破几乎所有自2017年以来的主流Linux发行版，AI工具只用了一个小时就发现了它。

容器的边界不是真正的隔离边界。面对不可信的模型生成代码，你需要的是硬件级别的隔离。

LangSmith Sandboxes：给每个袋里一台自己的电脑

理解这件事有个好角度：沙箱需要同时做到两件事。它要像Serverless函数一样能瞬间启动——你不能让一个袋里等上两分钟让虚拟机开机。同时它还得像一个完整机器那样具备持久状态——因为袋里不是无状态的请求处理器，它们是在会话中间持续工作、安装依赖、编辑文件、并且能从中断的地方接着干下去的“工人”。

LangSmith Sandboxes 正是基于这种模型构建的。每一个沙箱，都是一台经过硬件虚拟化的微型虚拟机。不是容器，而是一台拥有独立内核的完整机器。袋里得到的是：

Agent└── its own computer├── filesystem├── shell├── package manager├── network access├── code execution└── persistent state

它能安装包、运行脚本、编辑文件、启动本地服务、在整个长会话中持续工作——所有这些，都不会触及你的生产基础设施，也不会影响其他袋里的沙箱。任务完成后，沙箱自动消失。

通过你已经在用的LangSmith SDK和API Key就可以直接使用：

from langsmith import Clientclient = Client()sandbox = client.create_sandbox()# 给袋里一个命令行result = sandbox.run("pip install pandas && python analysis.py")print(result.stdout)

一行调用，你的袋里就拥有了一台电脑。

对于需要跑GPU工作负载的团队，还有一个不那么直观的好处：当沙箱能瞬间启动，GPU就不再需要空转等待CPU资源调配。快速的沙箱启动，实际上成了提升GPU效率的放大器——在大规模部署时，这个细节的累积效应非常可观。

除了跑代码，还有哪些核心能力？

一个沙箱远不止是一个代码运行环境。本次GA版本还附带了一系列让袋里工作流达到生产级可用的功能：

快照与分支：可以随时捕获一个沙箱的中间状态，然后从它启动新的实例。分支采用“写时复制”机制，同时开十个并行分支，成本差不多和开一个一样。你的袋里走错路了？没关系，快速恢复到一个健康状态，不用从头开始重建。

蓝图环境预配置：定义好一个基础镜像（比如已经克隆好的仓库、装好的依赖、配好的配置），然后从这个镜像启动沙箱，只需几秒就能获得一个完整环境，而不是几分钟。

服务URL：如果袋里启动了一个本地Web服务器——比如用来预览生成的报告——系统会自动生成一个经过认证的URL，你可以直接在浏览器打开，或者分享给同事，无需手动配置端口转发。

认证袋里：沙箱发出的外部请求会通过一个袋里服务器，这个袋里会在网络层自动注入凭证。这样一来，密钥信息永远不会暴露给袋里的运行环境。

默认创建者私有：只有创建沙箱的用户（以及工作空间管理员）能访问它。等你准备好再共享。

什么时候该用沙箱？

沙箱是那个最适合的层级——当你的袋里需要“动手去做”某件事，而不仅仅是“动口说”的时候。具体来说：

• 你的袋里生成了代码，并且你希望它在真正回复之前，先自己验证一下这段代码确实能跑通
• 你在构建一个编程助手、CI袋里、或数据流水线，需要操作真实的文件系统
• 你在跑多步骤的工作流，并且状态需要在多个工具调用之间持久化
• 你需要的不是几台，而是几千台并行环境（比如用于强化学习训练或评测），并能在几秒内从零扩展到成百上千个环境
• 你需要接受任何用户输入的内容，而这些内容最终可能会被执行

如果袋里只是调用固定接口的API，从不执行动态代码，那沙箱确实有点大材小用了。一个只负责搜索文档并返回引用链接的检索型袋里，完全不需要。但一个会写Python脚本并运行的袋里，答案就很明确了。

已经在用的事实

在monday.com，Sandboxes正在为其Sidekick AI助手提供底层支持。它为这个助手提供了一个安全的环境，用来编写和运行代码，以驱动高级用户工作流，包括数据分析和多媒体生成。

“LangSmith Sandboxes 帮助我们把Sidekick变得更加强大，为monday.com用户提供了更多可能。有了安全的环境，Sidekick可以编写和运行代码，并将结果用于创建更丰富的工作流，比如数据分析、内容生成等。”
—— Omri Bruchim，monday.com AI平台团队负责人

值得关注的变化

过去几年，让一个袋里变得更强大，主要靠给它更好的工具：一个搜索API、一个计算器、一个数据库连接器。这些仍然重要。但预定义工具的能力天花板其实很低。

真正能够替代实际工作流程（而不仅仅是提供辅助）的袋里，是那些能随时捡起它需要的工具、运行它、观察结果、并自我调整的袋里。而做到这一切的关键，就是让它拥有一台电脑。这绝不是一个基础设施层面的小细节——它是把一个只会“思考”的袋里，和一个真正能“行动”的袋里之间，最本质的区别。

你只用一台笔记本电脑。但你的每个袋里，都需要自己的一台。LangSmith Sandboxes 就是帮它们实现这一点的方式。