实验背景与架构设计

Kevin Orellana来自Amazon Bedrock Agent Core，其团队负责提供包括代理、身份验证、记忆体及沙箱环境在内的云原生Agent构建平台。为了模拟真实客户行为并测试服务稳定性，他进行了一项看似荒诞的实验：让一个编码代理（Coding Agent）在云端沙箱环境中运行一整夜，目标只有一个——尝试破坏该环境。这一实验的初衷源于对行业趋势的观察：越来越多的互联网平台组件本质上就是Agent，且越来越多地托管在沙箱中。为了高效执行测试，团队首先花费一两天时间创建了一个MCP（Model Context Protocol）服务器接口，使前沿大模型能够以原生方式访问沙箱环境。随后进行了工具可用性测试和冒烟测试，例如编写并执行Python代码或将其转换为Java。最终决定扩大测试范围：在10个不同领域生成并运行总计1,000项测试任务。这一数量并非精确统计，而是为了“撒大网”以捕获更多潜在问题。由于测试耗时较长且Token消耗巨大，团队还优化了凭据管理、失败处理机制（区分是服务层问题还是MCP层问题）等细节。整个架构相对简单但功能强大：顶部的编码代理通过MCP服务器与云沙箱交互，所有结果存储于SQLite数据库中。这种设计不仅解决了Agent倾向于生成难以扩展的Markdown文件的问题，还允许本地多个子代理并发运行并存储结果。每个测试点代表一个真实的客户工作流，从简单的打开网页到复杂的端到端机器学习训练或PDF报告生成。

测试领域与差异化需求

这1,000项测试覆盖了广泛的场景，旨在评估沙箱在不同压力下的可靠性。测试领域包括文件系统IO性能、软件开发生命周期（如编写Python或Java包）以及沙箱生命周期管理。Kevin指出，不同托管在沙箱中的应用对底层环境的需求存在显著差异。例如，对于云浏览器应用，测试重点在于创建多个标签页、抓取并总结内容、截图下载以及自动化登录流程。而对于代码沙箱，则更关注文件上传下载的完整性及执行效率。这种差异化的需求揭示了传统API服务模式与新型Agent托管模式的根本区别：传统的长运行服务通常暴露稳定的API，输入输出格式可预测；而现在的Agent环境通过网关访问，其工作流高度多样化且不可预知。正如Kevin所言："> 我们很快意识到，当时托管在平台上的两个主要应用程序——代码沙箱和云浏览器——对于它们所驻留的沙箱而言，有着不同的重要测试维度。" 这种复杂性要求平台必须具备极高的灵活性和鲁棒性，以应对Agent可能执行的任意操作。

典型故障模式分析

在测试过程中，团队发现了三类具有代表性的失败案例，这些案例清晰地展示了接口层（Interface Layer）与沙箱底层（Sandbox Layer）的不同故障模式。第一个案例较为简单：上传一张图片后下载，发现内容与原始文件不一致。深入排查后发现，问题出在MCP层的编码层处理错误。第二个案例涉及编程中的“无操作”（no-op）标记，在某些语言中代表字符串结束或零值，这导致测试脚本意外中断。第三个案例更具沙箱特性：当代理将文件写入特定目录后，尝试读取时却无法找到该文件。Kevin强调，区分故障发生在接口层还是沙箱底层至关重要。因为随着应用从传统API服务转向由专用Agent托管的沙箱环境，其对计算环境的依赖发生了根本性变化。开发者常遇到本地开发时Agent行为异常的情况，如意外下载包或进行非预期的格式转换（CSV转JSON再转PDF）。这些不可预测的工作流对沙箱环境的隔离性、状态一致性和资源管理提出了前所未有的挑战。正如Kevin总结道："> 显然，在当今世界，我们不再拥有那么多长运行应用程序，而是由专门的Agent托管在沙箱环境中。"

沙箱环境约束对智能体能力的决定性影响

在构建基于大语言模型（LLM）的智能体时，沙箱环境的配置细节直接决定了智能体的任务成功率。这些约束不仅包括内存和CPU等基础资源，还涉及进程权限、文件系统访问以及网络出口控制。演讲者指出，“这些约束对智能体解决问题的能力有着巨大的影响”。为了直观展示这一点，研究团队对比了两种不同的应用托管环境：代码解释器（Code Sandbox）与云浏览器（Cloud Browser）。在测试中，云浏览器因打开标签页导致内存占用极高，从而引发了大量失败；而代码解释器环境则未出现此类严重的内存瓶颈问题。这种差异表明，不同的沙箱架构会导致截然不同的故障模式分布。

底层原语与资源耗尽导致的系统性崩溃

当深入分析故障模式时，发现失败往往集中在沙箱原语（Sandbox Primitives）层面。例如，文件系统的权限设置、挂载方式以及持久性/临时性的配置，都会成为智能体执行的障碍。在云浏览器测试中，“会话和沙箱因内存耗尽而完全失败”成为主要问题。此外，底层组件如内核能力、BPF程序拦截以及Python层的进程控制，共同构成了一个复杂的约束网络。如果智能体需要启动新进程、下载Python包或执行Rust二进制文件，任何微小的权限缺失或路径错误都会累积成最终的任务失败。这意味着，“随着我们在沙箱中托管越来越多的应用程序，必须谨慎对待这些约束对智能体完成目标能力的巨大影响”。

模糊测试与本地/远程环境的差异挑战

为了暴露这些隐蔽的故障点，研究团队采用了模糊测试（Fuzzy Testing）策略，让智能体在沙箱中完成一千个工作流任务。这一方法揭示了本地开发环境与远程沙箱环境之间的巨大差异。开发者习惯在本地使用MCP工具或运行代码智能体，但一旦扩展到远程沙箱以支持大规模GitHub PR处理等场景，“本地工作站上的工具可能与远程沙箱中的环境不匹配”成为常见痛点。为此，AWS推出了允许用户（或智能体本身）通过SSH进入沙箱的功能，“以便查看导致代码智能体运行不畅的问题根源”。“这已成为我们致力于为客户解决的一个明确业务问题”。

学术研究与环境控制对性能的双刃剑效应

学术界的研究进一步佐证了环境配置的重要性。一方面，UC Berkeley的研究人员发现，“在给予适当的环境控制和利用漏洞的情况下，智能体可以将SWE-bench基准测试的得分提升至100%”。另一方面，“当向智能体提供带有故障工具的业务问题时，其有效性会大幅下降”。这表明，当前的应用正从简单的REST API服务转向“在沙箱内运行的任意智能体”，这种转变使得识别和修复那些导致失败的“尖锐边缘（sharp edges）”变得极具挑战性。因此，理解并优化沙箱底层原语与智能体行为之间的交互，是确保LLM代码执行可靠性的关键。

沙箱基础原语对智能体执行效率的限制

在构建基于大语言模型（LLM）的智能体系统时，开发者往往倾向于使用沙箱环境来隔离代码执行风险。然而，Kevin Orellana 指出，沙箱原语（sandbox primitives）的设计往往导致智能体完成任务的效率显著降低。这些基础性的隔离机制虽然保障了安全性，但在实际运行中却构成了性能瓶颈。当智能体需要在受限环境中进行代码生成、调试和执行时，低效的原语交互会直接拖慢问题解决的速度。这种效率损失并非偶然，而是由沙箱架构本身的局限性决定的。因此，仅仅依赖本地的简单测试无法全面暴露这些问题。

"sandbox primitives uh lead to you know a less efficient uh ability for your agents to complete that problem."

这意味着，如果开发者希望部署能够自主执行复杂任务的智能体，必须正视沙箱环境带来的固有性能损耗。这种损耗体现在代码执行的延迟、资源调度的复杂性以及错误处理的冗余上。忽视这一点，可能导致智能体在真实场景中表现远低于预期。

远程模糊测试与多领域验证的必要性

针对上述效率问题，演讲者提出了一个明确的挑战：如果你计划将智能体托管在沙箱中，除了本地测试外，还必须进行广泛的远程模糊测试（fuzzy test）。这种测试策略要求覆盖广泛领域的用例集，以模拟真实世界中不可预测的输入和边缘情况。本地测试通常局限于开发者预设的场景，容易遗漏潜在的系统性缺陷。

通过在远程环境中进行模糊测试，开发者可以观察到智能体在面对非结构化、噪声数据或极端边界条件时的真实表现。这种方法能够揭示出本地测试无法捕捉的鲁棒性问题。Orellana 强调，这种多维度的验证是确保智能体在生产环境中稳定运行的关键步骤。只有通过跨领域的远程压力测试，才能真正评估沙箱环境对智能体能力的实际影响。

"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."

这一建议的核心在于打破本地测试的局限性。远程模糊测试不仅是对代码功能的验证，更是对智能体在受限环境中适应能力的全面考察。它要求开发者建立一套包含多种领域知识的测试基准，从而确保智能体在各种复杂场景下都能保持高效和稳定。

结论：从本地验证到远程鲁棒性测试的范式转变

综上所述，在沙箱中运行LLM智能体面临着基础原语导致的效率低下这一核心挑战。解决这一问题不能仅靠优化代码逻辑，更需要从测试策略上进行根本性的转变。本地测试应被视为基础验证手段，而远程模糊测试则是确保系统鲁棒性的关键。通过引入广泛领域的远程测试用例，开发者能够更准确地评估智能体在真实生产环境中的表现。

这种从本地到远程、从确定性测试到模糊性验证的范式转变，对于构建可靠的AI代理系统至关重要。它要求开发者不仅要关注智能体的功能正确性，更要重视其在受限环境下的执行效率和适应能力。只有通过这种全面且严格的测试体系，才能确保智能体在部署后能够高效、稳定地完成任务。

"Yeah, thank you. [applause]"

结论

实验证实，沙箱底层原语与权限配置直接决定LLM智能体的任务成功率。云浏览器因内存瓶颈频发失败，而代码沙箱表现更优，凸显环境架构对故障模式的决定性影响。传统API的稳定性无法移植至Agent场景，接口层编码错误与沙箱状态不一致构成主要短板。本地测试难以捕捉远程环境差异，必须通过跨领域模糊测试暴露隐蔽缺陷。

该研究揭示从本地验证向远程鲁棒性测试的范式转变必要性。仅靠代码逻辑优化不足以保证可靠性，需正视沙箱带来的固有性能损耗与效率限制。开发者应建立包含多领域用例的远程测试体系，以应对不可预测的工作流和尖锐边缘情况。唯有通过严格的环境适配与压力测试，才能确保智能体在复杂生产环境中稳定高效运行。