让 Agent 在沙箱中运行 1000 项任务：LLM 执行代码时会出现什么问题？｜AWS Kevin Orellana

简要说明Brief Description

沙箱中的 1,000 项智能体任务：当 LLM 运行代码时，什么会出问题 — Kevin Orellana，AWS1，000 Agent Tasks in a Sandbox: What Breaks When LLMs Run Code — Kevin Orellana， AWS

目录Table of Contents

• 一个被指示突破我们沙箱的代理
  An agent told to break our sandbox
• Amazon Bedrock AgentCore overview
• 使用编码代理模拟客户
  Simulating customers with coding agents
• 将该平台封装在 MCP 服务器中
  Wrapping the platform in an MCP server
• 在 10 个领域中生成 1,000 个测试
  Generating 1,000 tests across 10 domains
• 测试框架与 SQLite 结果
  Test harness and SQLite results
• 这 1,000 个工作流涵盖的内容
  What the 1,000 workflows covered
• 三种故障：编码、空字节、文件
  Three failures: encoding, null byte, files
• 接口层与沙箱层
  Interface layer vs sandbox layer
• 代码沙箱与云端浏览器故障
  Code sandbox vs cloud browser failures
• 沙箱基础机制：seccomp、eBPF、权限
  Sandbox primitives: seccomp, eBPF, permissions
• LLM 生成测试的局限性
  Limits of LLM-generated tests
• 本地与远程代理环境
  Local vs remote agent environments
• 通过 SSH 访问 AgentCore 沙盒
  SSH access to AgentCore sandboxes
• SWE-bench 漏洞利用与损坏的工具
  SWE-bench exploits and broken tools
• 要点：远程对沙箱进行模糊测试
  Takeaway: fuzz test sandboxes remotely

一个被指示突破我们沙箱的代理An agent told to break our sandbox

大家好。我想我们可以开始了。几个月前，我做了一件有点……嗯，稍微荒唐的事。我找来一个编码代理，把它指向我们团队的云沙箱托管环境，对它说：“试着攻破它。”然后我就让它跑了一整夜。这次演讲会讲讲我们发现了什么。Hello everyone. I think we can get started. So, a few months ago, I did something that was um a bit slightly absurd. I took a coding agent. I pointed it at my team's uh cloud sandbox hosting environment and it said try to break it and I let that run overnight. And this talk is a bit about what we found.

Amazon Bedrock AgentCore overview

嗯，我叫 Kevin。我在 Amazon Bedrock Agent Core 工作。它是一个沙盒托管环境或平台。我们提供的远不止这些。我们还提供智能体、身份管理、记忆、运行时环境、沙盒、网关，以及你在云端构建和托管智能体所需的一切。Uh my name is Kevin. I work at Amazon Bedrock Agent Core. It's a sandbox hosting environment or platform. And we do more than that. We provide agents, identity, memory, um, runtime environments, sandboxes, gateways, anything you want to use to build and host your agents on agents on the cloud.

使用编码代理模拟客户Simulating customers with coding agents

所以，这件事最初基本上是因为我认真研究了客户如何使用我们的平台。如今，我觉得业内很多人越来越意识到，互联网上的许多平台组件其实就是智能体，而且它们也越来越多地托管在沙箱中。我想，今天的分享也许会带大家了解云托管沙箱环境中可能存在的各种架构。这让我开始思考：我能不能模拟客户，并像智能体使用我们平台那样测试这项服务？So the way this started was basically with me taking a hard look at how um customers use our platform and increasingly I think a lot of us in the industry see that uh a lot of platform components on the internet are just agents and increasingly they're also sandbox hosted. I think today's talks will maybe walk you through all the architectures that can exist in cloud hosted uh sandbox environments. And so this kind of got me thinking how can I perhaps emulate simulate the customer and also test the service the same way agents use our platform.

将平台封装为 MCP 服务器Wrapping the platform in an MCP server

所以我认为我们最初要做的第一件事，就是创建一种抽象或接口，让编程智能体以及智能体应用能够以对它们来说相当原生的方式与我们的服务交互。如今我们知道，前沿模型对 MCP 协议已经相当熟悉了。因此，我们花了一两天时间创建了一个 MCP 服务器，用来开放对我们环境和平台的访问，让它能够很快上手。第二步是对其进行打磨。我们花了一些时间寻找可以开放访问的工具，并进行了一些冒烟测试之类的工作。我们手动运行的一些测试包括，比如编写并执行一个 Python 代码文件，或者把一个 Python 文件转换成 Java。So the first thing I think we we set out to do was create an abstraction or interface that allows coding agents as well as agent applications to interact with our service uh in a way that's pretty native to them. And today we know that Frontier models know the MCP protocol pretty well. So we spent a day or two just creating an MCP server to expose access to our environment and platform um just so it can get started pretty quickly. The second piece was polishing that. Uh we spent some time in finding the tools that can be made accessible and uh smoke testing some runs and and things like that. So some of the tests we ran just by hand was uh for example write a Python code file and execute it or take a Python file and uh convert into Java.

在 10 个领域中生成 1,000 项测试Generating 1,000 tests across 10 domains

然后我们意识到，我们只是想扩大要交给编码智能体执行的测试领域。因此，我们要求它直接在 10 个领域编写 1,000 个测试。这里的 1,000 个测试数量其实相当随意，只是为了广撒网，看看能收到什么结果。这件事需要稍微打磨一下，因为我们知道，1,000 个测试要花上几个小时，而且会消耗不少 token。所以我们做了一些事情，比如凭证管理、凭证管理注入，以及测试失败时会发生什么：这是服务问题，还是 MCP 层的问题？这类事情我们都让智能体去判断。And then we realized we wanted to just expand the test domains that we we were going to set the coding agents to do. So we asked to just plainly write a thousand tests across 10 domains. And a thousand tests here was pretty arbitrary. It was just to cast a wide net and see what caught back. This took a bit of polishing because we knew that a thousand tests would take a few hours and was going to be a little tokenheavy. So we um did things like credential management credential management injection um what happens when a test fails. Is it a service issue? Is it a MCP layer issue? Uh those are the kind of things we we let the agent um figure

测试框架和 SQLite 结果Test harness and SQLite results

好了。所以这个架构说实话非常简单，但也非常强大。我想我们很多人在日常开发中可能都见过类似的架构。左上方是我们的编码智能体。我们有一个 MCP 服务器，它基本上封装了我们的云端沙箱环境，所有发现都会发送回来。我们把它们存储在 SQLite 数据库中，因为你们有些人可能也注意到了，智能体很容易写出 Markdown 文件，但当你想运行上千个测试时，这种方式就不太能扩展了。而这种做法让我们能够利用并发：可以让多个子智能体在本地运行、执行测试，并将结果存储在本地。out. So the architecture is honestly very simple but it's also very powerful and I think a lot of us have probably seen this in our day-to-day uh development. So we have our coding agent on top left. We have an MCP server that basically wraps our cloud sandbox environment and all the findings get sent back to us. We store them in a SQLite database just because as some of you might have seen u agents are pretty prone to write markdown files but that doesn't really scale when you have a thousand tests that you want to run and this allowed us to tap into concurrency or you can have multiple sub aents running locally and running and executing their tests and storing those results uh locally.

这 1,000 个工作流涵盖的内容What the 1,000 workflows covered

现在，我觉得把一千项测试脱口而出好像挺容易，但实际上，屏幕上的每一个点都代表着客户可能会实际运行的一种工作流。我们测试了沙箱的生命周期，比如它在压力下有多可靠；还测试了文件系统 IO，比如从沙箱上传和下载文件时会发生什么。我们也测试了性能，以及一些软件开发生命周期场景，例如编写 Python 包、Java 包等等。举例来说，一个点可能代表端到端的机器学习训练程序，也可能代表生成 PDF 报告，或者只是打开一个网页。我们很快就意识到，我们的平台当时托管着两个主要应用：一个是代码沙箱，另一个是云浏览器；而这两个应用所需的测试各不相同，对于它们所运行的沙箱来说，重要性也各不相同。Now, a thousand tests I think is kind of easy to just say out loud, but really every single dot on the screen kind of represents a workflow that a customer would actually run. So, we did things like testing the sandbox uh life cycle. How reliable is it when you put it under stress? Um things like file system IO, what happens when you upload a file and download it from the sandbox? Uh tested performance. We tested some software development life cycles like uh for example writing Python packages, Java packages um and the like. So to give you a perspective of what one of these dots could represent, it could be an end toend machine learning training uh program. It could be generating a PDF report. Uh it could also just be um as simple as opening a web page. And we re quickly realized that our platform which at the time was hosting two uh major applications, one was a code sandbox, the other was a cloud browser would have different tests that mattered differently to the sandboxes that they were hosted in.

所以，比如说，在浏览器中，我们让代理创建一堆标签页，并尝试抓取所有标签页的内容并进行总结，也许还会截取一些屏幕截图、下载它们，或者填写表单、自动完成登录流程。但这里的重点是，这些在沙箱中托管的应用往往会经历不同的工作流。So for example, here in the browser, we asked the agent to create a bunch of uh tabs and try to scrape them all and summarize them, maybe take some screenshots, download them, maybe fill out a form, automate a login workflow. But the point here is these sandbox hosted applications uh tend to go through different workflows

三种故障：编码、空字节、文件Three failures: encoding, null byte, files

这些应用对沙箱提出了不同的要求。于是我们跑了一遍测试，我想谈谈其中三个失败案例，我觉得它们体现了我们在这些沙箱托管应用中看到的一些模式。一个比较简单的案例是，我们上传了一张图片，又把它下载下来，想看看下载回来的东西是否和上传的一样。结果却并非如此。我们深入调查了一下，发现 MCP 层的编码层有误。第二个案例也挺有意思，问题出在一个空字节上，它直接导致我们的测试失败。空字节可以表示零；在某些编程语言中，它也可以作为一个标记，表示字符串已经结束。还有一个特别发生在沙箱层的问题：我们把文件写入沙箱中的特定目录，但尝试取回文件时，却怎么也找不到。that demand different requirements from the sandbox. So we ran through the tests and I want to talk about just three failures that I think um showcase some of the patterns we saw uh from these uh sandbox hosted applications. So a simple one was we uploaded an image, we downloaded it and we wanted to see if the same thing that we put up uh we got back when we asked to download it and lo and behold that was not the case. Uh we deep dived a bit into it and we found that the encoding layer at the MCP layer was incorrect. The second one was a bit interesting too which was a no bite. It just threw off off our tests. Um a no bite can be a zero. It could also be a marker in some coding languages that just mean that means that the string is is uh complete. Now an interesting one that was particular the sandbox layer is one where we actually wrote files to a specific directory in the sandbox and when we try to get it back it just wouldn't be available.

接口层 vs 沙箱层Interface layer vs sandbox layer

所以现在我们开始将这些模式和故障区分为两个层次：一个是在接口层，另一个是在沙箱层。我认为，明确这一区别非常重要，因为当我们开始在沙箱中托管应用程序时，它们会在某些方面偏离典型的 API 服务模式。在典型模式中，你有一个长期运行的服务，它暴露一个 API；你发送请求，然后得到一个结构相对明确的输出，并且你大致知道后端服务在做什么。 但显然，在当今世界，我们不再拥有那么多长期运行的应用程序。相反，我们有一些专用代理，它们运行在沙箱和环境中；我们通过网关向它们提供访问权限。而它们对自身计算环境的需求，可以说会有很大的差异。So now we started to segregate the patterns uh and failures into two layers. One was at the interface and the other one was at the sandbox layer. And it's important I think to draw the distinction because uh when we start to host applications in sandboxes we they deviate a little bit from the typical API service pattern where you have a long running service that has exposes an API uh and you you know send a request you get an output that's reasonably um shaped and you you kind of know what your backend service does. But obviously in today's world we we no longer have as many long running applications rather we have specialized agents that are uh sandbox and environment we expose access to them through a gateway and the demands that they have on their let's say computer environment are going to differ greatly.

我们知道这一点，而且我认为这是很多人都能产生共鸣的一种经历：你在本地开发某些东西，然后开始看到你的 agent——不管是 Curo、Cloud Code、Codeex，还是其他工具——做出一些奇怪的事情。比如，它可能会下载一个你没想到的包，或者不知为何把 CSV 文件转换成 JSON，再转换成 PDF。你的 agent 想要执行的所有这些工作流，都会对你的环境提出不同的要求。比如，你的沙箱拥有多少内存或 CPU、你的进程和文件系统具备哪些权限等。 我认为在今天的许多演讲中，我们会看到很多不同的沙箱架构。这里更重要的一点是，所有这些约束都会对你的 agent 解决这些问题的能力产生相当重大的影响。We know that and this is an experience I think a lot of us can relate to which is you are developing something locally and you just start to see your agent uh either a curo cloud codeex whatever it might be do funny things like it might uh download a package you might not have expected or it might translate a CSV file to JSON to PDF for whatever reason and all of these workflows that your agents will want to do are going to demand uh different things from your environment. So things for example like how much memory or CPU your sandbox has the permissions that are available to your processes and file systems. I think in a lot of the talks we'll see today there are a lot of different architectures that your sandboxes can have. And the wider point here I think is all these constraints have pretty massive implications for your agents ability to solve these problems.

代码沙箱与云浏览器故障Code sandbox vs cloud browser failures

为了直观地展示这一点，这些是我们比较两个运行在沙箱中的不同应用时观察到的一些故障。上面是代码沙箱，下面是云浏览器。右下方用红色标出了故障模式，表示沙箱实际崩溃的次数。在这个案例中，我们知道云浏览器每次打开标签页都会占用大量内存。因此，我们的许多测试仅仅因为内存限制而失败。这并不是我们在代码解释器环境中看到的故障。换一种方式呈现后，我们开始发现，这些故障模式集中在沙箱的基本组件上。我们知道，文件系统相关的一些组件往往涉及文件系统权限、挂载的文件系统、读取、写入和执行文件的权限，以及文件系统是持久化的还是临时的。And just to kind of visualize that, these are some of the faults that we saw when we compared two different applications hosted in sandboxes. So at the top we have the code sandbox and the bottom we have the cloud browser. At the bottom right we have the failure modes that are highlighted in red which signify how many times the sandbox actually uh perished. In this case, because cloud browsers, we know that whenever we open up tabs, they're pretty memory heavy. And so, a lot of our tests fail just due to memory constraints. And that wasn't really a fault we saw in the uh code interpret environment. And when we map them out a little bit differently, we start to see that the failure modes coales around sandbox primitives. So we know some of the components around file systems tend to be file system permissions uh mounted file systems uh permissions to read, write, execute files, um whether or not the file system uh is persistent or uh ephemeral.

嗯，而且测试相当不留情面。比如在右下角，我们看到浏览器测试只是让会话和沙盒耗尽内存，并将其标记为完全失败。我认为这里更广泛的一点是，当我们将这些应用托管在沙盒中，并且希望客户能够在这些沙盒里构建相当任意的工作负载时，我们必须非常谨慎，因为沙盒的限制会对这些代理完成相关问题的能力产生巨大影响。Um and the tests were pretty unforgiving. Um for example, in the bottom right we have uh the browser tests just starving the the sessions and sandboxes out of memory and signaling that as a complete failure. And I think the wider point here is as we host these applications in sandboxes and we expect our customers to be able to build uh pretty arbitrary workloads in these sandboxes, we have to be pretty careful that the sandbox constraints have massive implications as to those agents ability to complete those problems.

沙箱原语：seccomp、eBPF、权限Sandbox primitives: seccomp, eBPF, permissions

现在，如果我们仔细看一下这张幻灯片，它的第二列内容相当多，其中包含了许多用于构建沙箱容器的基本组件。我们可以深入到内核能力，比如内核拦截器，以及所谓的扩展 BP BPF 程序，它们允许你运行内核模块，并在 Python 层拦截程序。这些组件可能会控制你的智能体实际能够如何发起一些出站调用，比如向你们公司的内部服务发起内部 API 调用。 如果把这些内容画成图，大致可以从较高层次看出，沙箱中的各个组件可能会如何影响工作负载完成任务的能力。比如，我记得我们之前的演讲中提到过安全计算，它控制着应用程序可能想要运行的系统控制程序。Now if we look a little bit closely and this slide is pretty heavy on the second column we have a lot of the primitives used to compose what a sandbox container um might look like. So we can go as deep as kernel capabilities, things like kernel interceptors, um these things called extended BP BPF programs which allow you to run kernel modules and intercept programs at the at the Python layer. Um those might uh control how your agent actually can make some egress calls, maybe make a internal API call to um your internal company services. If we diagram this out, this is kind of what a very high level overview of how the components in the sandbox might uh affect your um workload's ability to do its job. So here for example, I think earlier in our talks, we spoke about uh security secure compute which controls the system control programs that your applications might want to run.

比如说，我有一个需要启动进程的机器学习包。那么我的进程或容器到底有没有能力启动一个新进程？嗯，也许我有一个代码解释器任务，需要把一个 Python 包下载到一个非常特定的模块中，这样 Python 内核才能识别它；或者 Rust 二进制文件是否位于正确的位置，以便编码代理能够运行或执行程序。所有这些非常非常细小的事情，往往都会累积起来，影响代理执行……的能力。So for example, say I have a machine learning package that needs to spawn a process. Does my process or container even have the ability to start a new process? Um perhaps I have a code interpreter uh task that needs to download a Python rep Python package into a very specific module for uh the Python kernel to be able to pick it up or are the Rust binaries in the right location for when the coding agent is able to um run or execute a program. All these very very small things tend to add up into your agents ability to uh execute the

LLM 生成测试的局限性Limits of LLM-generated tests

业务问题。现在退一步来看，我觉得这有点意思：用 NLM 来生成基本的单元测试。我想我们都这么做过。我不知道现在还有没有人手写单元测试。类似地，如果我们再往上一层看，看看集成测试，我们可以预期，智能体会很擅长理解问题空间并为其编写测试。但随着我们开始在沙箱中托管越来越多纯粹由智能体构成的应用，我们开始看到这种模式的缺陷：这些非常底层的原语和控制机制，实际上可能会妨碍智能体实现其既定目标。我们希望在这里传达的是，要揭示这些对我们来说相当不起眼的失效模式，有一种非常有效的方法：对智能体沙箱进行模糊测试，让它尝试完成（比如在这个案例中）一千个工作流，然后看看会得到什么结果。business problem. Now just taking a step back I think this was kind of interesting uh which was the idea of like using an NLM to generate basically unit test. I think we've all done it. We I don't know if anyone writes unit tests by hand anymore. Uh and similarly if we go up up a layer integration tests uh we we we can anticipate agents to be pretty good at understanding the problem space and writing tests for them. But as we move towards hosting more and more applications which are just agents uh in sandboxes, we start to see the cracks in the model which is um these very low-level primitives and controls um might actually hamper your agents ability to do its state of goal. Um, and what we were hoping to relay here is a a very strong way to actually surface these failure modes that are that are pretty innocuous to us is just through fuzzy testing your agent sandbox asking it to complete perhaps in this case a thousand workflows and seeing what results you get.

本地与远程代理环境Local vs remote agent environments

而且，为了让这件事更具体一点，嗯，我们这里很多开发者都非常习惯于在本地运行编码代理。你可能会在本地运行你的，嗯，你的 Codex 或 Claude。随着我们不断扩展并创建更多工作区，很快就会让你的笔记本电脑不堪重负。现在，你知道，你的团队希望把这些编码代理放到远程沙箱中，这样就能扩大你们处理 GitHub PR 的规模，诸如此类。但正如你可能已经看到的，你本地工作站上的工具、MCP 工具以及本地运行的应用程序，可能和你在一个……里使用的并不匹配。And just to also make it a little bit more tangible, um, a lot of us here developers, we are very used to running coding agents locally. You might have your, you know, your your codeex or your cloud running locally. And as we expand and create more workspaces, you quickly put a constraint on your laptop and now, you know, your teams want to put these coding agents in remote sandboxes so you can scale how many GitHub PRs you you work through and the like. But as you've probably seen, the tools that you have in your local workstation, your MCP tools, your locally running applications might not match what you have in a

通过 SSH 访问 AgentCore 沙盒SSH access to AgentCore sandboxes

远程沙箱。顺便简单提一下 Agent Core。我们非常关注这个问题，因为我们知道客户希望扩大编码智能体的规模，也希望了解客户实际上是如何运行这些软件开发生命周期的。我们最近发布的一项功能，就是允许客户通过 SSH 登录自己的沙箱，查看里面的情况。当然，现在通过 SSH 登录沙箱的已经不再是真正的人类了，也可能是你正在一起开发的编码智能体。不过，能够进入沙箱、四处查看，找出导致编码智能体或应用运行不够顺畅的问题，这确实是我们明确要解决的一个业务问题，我们也正在努力为客户解决它。remote sandbox. And just a small shout out to uh agent core. This is actually one of the problems that we're very keen on because we recognize that customers want to scale their coding agents um and how customers are actually running these uh software development life cycles. So one of the releases we recently did was grant the ability to customers to SSH into their um sandbox just to see what's going on. And of course it's not really a human who is SSH into your sandbox anymore. or it's a coding agent who you're developing with uh as well. But the idea is there uh bridging into the sandbox and poking around and seeing what problems are causing your coding agent or your application to not run as smoothly is a pretty um stated business problem for us and one that we're trying to solve for customers.

SWE-bench 漏洞利用与失效工具SWE-bench exploits and broken tools

如果你稍微关注一下学术界，我想很多人都会在意一个有趣的例子：每当有前沿模型发布，我们首先看的就是那份亮眼的基准测试报告，看看这个模型在这三项基准测试中的得分是多少，另一个模型又是多少。最近，UC Berkeley 的一些研究人员做了一项研究，发现只要设置好环境控制并使用一个利用漏洞的智能体，它们实际上能在这三项基准测试中取得高达 100% 的成绩。反过来，还有另一项研究，研究人员试图让一个工具有缺陷的智能体处理范围广泛的商业问题。当然，这个智能体的效果也随之下降。And if you look a little bit uh if you look a little bit at academia uh one interesting example I think a lot of us probably care about is whenever frontier models come out the first thing we look at is the sweet benchmark report which is okay this model got XYZ percentage on this three benchmark versus another and there was a recent study made by some researchers at UC Berkeley where they found that given the right environment controls and an exploit agent they actually beat the three benchmarks like reaching up to 100%. And in inversely uh there was another study where um researchers were trying to give a wide set of business problems to an agent with broken tools. Uh and of course the effectiveness of that agent uh went down

要点：远程对沙箱进行模糊测试Takeaway: fuzz test sandboxes remotely

很大程度上。所以我想，今天我主要想谈的就是：如今我们构建的应用越来越具备智能体特性，它们也不再局限于你为客户构建的 REST API 服务，而是可能成为在沙箱中运行的任意智能体。要找出沙箱原语可能带来的所有棘手问题——这些问题会让智能体解决任务的效率降低——确实非常具有挑战性。因此，我今天想给大家的建议是：如果你打算在沙箱中托管智能体，当然要在本地测试，但也要在远程环境中，使用覆盖广泛领域的测试进行模糊测试。谢谢。greatly. So I think this is uh mostly where I want to aim to leave today which is as these applications that we build today are more and more agentic and they're not constrained to a rest API service that you you build for customers but rather uh an arbitrary agent running inside of sandbox it's really really um uh challenging to find all the sharp edges where the sandbox primitives uh lead to you know a less efficient uh ability for your agents to complete that problem. So my challenge here for you today is uh if you're looking to host your agents on sandboxes, sure test it locally, but also fuzzy test it with a wide set of domain tests um remotely. Yeah, thank you.