Mislav Ivanda：先选执行边界，再选智能体框架

Mislav Ivanda 介绍自己将 Daytona 沙箱接入智能体框架、编程代理运行环境和开发者工具的工作。尽管这些框架差异很大，他仍发现了反复出现的共同模式。

他展示一段代码，请观众猜测所属框架。他说，多个答案都说得通，因为沙箱相关的实现非常相似：有的框架使用工具，有的使用插件，还有的使用客户端类。

在这些不同接口之下，反复出现的是相同操作：创建沙箱、在其中运行代码或任务，然后删除沙箱。Ivanda 认为这很值得注意，因为竞争框架在许多其他基本问题上意见不一。

他比较了将智能体描述为图、扮演不同角色的智能体集合、模型循环或完整产品的框架。它们使用的语言不同，对开发者明确指定工作流还是由智能体自行决定步骤的看法也不同。

Ivanda 认为，有用的智能体工作流最终往往需要执行代码或访问 shell。接下来的架构问题是这些代码在哪里运行，以及它们拥有哪些能力。

第一种方法是在本机运行，配合命令白名单、审批提示和拦截钩子。这些检查可以约束交互，但批准通用解释器后，运行的代码仍可能访问文件、建立网络连接或执行其他代码。

他说，指定模型应该使用哪个命令，与控制进程实际上能做什么，是两回事。如果进程拥有广泛的主机权限，遭入侵的执行步骤就可能利用这些权限。

第二种方法是在 V8 或 QuickJS 等嵌入式运行时中执行生成的代码。这样可以对运行时内的代码提供一定的文件系统和网络隔离。

Ivanda 提醒，隔离生成的代码，不等于自动隔离它调用的每个工具。邮件或数据库工具可能在运行时外凭自己的权限执行，因此有害操作仍可能通过暴露的工具跨越边界。

他推荐使用通过 API 管理的独立沙箱计算机或虚拟机。执行环境可以创建、使用和销毁，而不必有意共享应用主机的全部资源。

Ivanda 认为这有助于限制遭入侵的执行步骤，避免整个应用直接暴露。实际保护效果仍取决于沙箱配置、网络访问、凭据以及所连接工具的能力。

他举出 CrewAI、AG2 和 OpenAI Agents SDK 等框架改变代码执行支持的例子。他的重点是，隔离正从可选附加功能变成核心执行选择。

Ivanda 描述沙箱使用方式的演变：早期智能体通常为单次任务创建短期环境，完成后删除；能力更强的智能体则可以在隔离环境中运行更完整的工作流。

同时运行大量环境还可以支持强化学习、微调、基准测试和并行子智能体。这些工作负载都依赖大规模提供隔离执行环境的能力。

这段经历让他重新思考“应该选择哪个智能体框架”这个常见问题。他认为，开发者常比较的许多因素之后都能改变，而执行边界通常更根本。

他说，同一种语言编写的框架可以通过重构迁移，模型和提示词也可以在调优和回归测试后更换。缺失的功能有时也能自行实现或通过外部工具补足。

Ivanda 特别指出，持久执行更难在短时间内重新实现，因为它影响系统架构。他认为评测、追踪和记忆集成则是团队常常可以另行添加的例子。

沙箱服务商也可能共享创建、运行、删除的基本接口，但具体能力和性能各有差异。他将其与更难改变的选择作比较：在本机执行，还是使用外部环境。

本机优先的原型可能让工具依赖主机文件系统和应用进程。如果这些假设延续到生产环境，迁移到独立执行边界就可能需要修改整个系统。

Ivanda 最后给出核心建议：先选择执行边界，再选择框架。框架体现可以改变的设计偏好；执行边界则会成为嵌入系统架构的长期承诺。