# Run Your Harness Outside of the Sandbox (Why and How)
**作者**: Nathan Flurry
**日期**: 2026-07-27T15:45:48.000Z
**来源**: [https://x.com/NathanFlurry/status/2081768022025658672](https://x.com/NathanFlurry/status/2081768022025658672)
---
There's been a running debate since the beginning of 2026 about where you run agents: inside the sandbox, or outside of it. There have been a lot of implementations of both, but the industry is moving toward running agents outside of sandboxes for mature projects.
Within the last few months, OpenAI, Anthropica, Vercel, Cloudflare, and Amp all shipped platforms that run the agent loop outside the sandbox.
# Running Agents Inside Sandboxes: Easy to Set Up, Hard to Maintain
A lot of companies start by running the agent inside the sandbox because, frankly, it's simple. Setting it up looks something like this:
But when companies run with this architecture, they start fighting an uphill battle against the inherently chaotic nature of what runs inside a sandbox.
# Why Not to Run Agents in Sandboxes
Sandboxes are built for running untrusted code, not for hosting the agent itself. Running the agent inside falls apart for three reasons:
## Reason 1: The Blast Radius
Sandboxes are a place for containing the chaos that agents create. That's by design, there's no structure to what agents can do inside of a sandbox, so sandboxes break for many, many reasons. A build command OOMs the sandbox, a runaway script pegs the CPU, a botched tool install breaks `$PATH`, or the filesystem just ends up corrupted.
When the sandbox breaks, it takes these down with it:
- The agent loop, retries, and durability: The durability mechanism that's supposed to recover from failures dies when the sandbox dies. Retries need to live in your backend so you can gracefully handle failures of the sandbox itself.
- Session history: The session history gets corrupted or wiped along with everything else when stored inside the sandbox. Keep it outside, in a real database.
- Observability of failures: If the sandbox dies, it will not be able to report its own failure to observability. Ship detected failures from within your own backend.
## Reason 2: The Trust Boundary
Sandboxes are meant to have a trust-nothing architecture, because agents are prone to prompt injection and leaking sensitive information. If something is accessible in the sandbox, it's safe to assume that data or API will be abused and leaked.
You can do none of these safely in a sandbox:
- LLM credentials and routing: A token inside the sandbox is a token the agent can leak or abuse. Keep it outside. (Some routers have per-tenant scoped tokens that help mitigate this problem.)
- Permissions and approvals: Coding agents are trained to work around barriers, so permissions enforced inside a sandbox are permissions the agent can probably work around. Enforce them outside in your trusted backend.
- Audit logs: An audit log written from inside the sandbox is one the agent can manipulate or corrupt. Write it from outside.
- Multiplayer security: Access to the sandbox is access to everything, so there's no way to give collaborators per-user permissions inside it. Enforce per-user permissions within your backend.
- Trusted tools: Tools that talk to private databases or internal APIs need credentials the sandbox can't be trusted with. Provide them as tools in the harness, no custom authentication proxies required.
- Agent-to-agent communication: Sandbox-to-sandbox communication means every sandbox must hold addresses and credentials for its siblings, which is complicated, error prone, and insecure. Route agent-agent communication in your backend instead where you don't need complex authentication and routing mechanisms.
## Reason 3: The Sandbox Isn't Always Running
Sandboxes go to sleep when not in use, by design. But that breaks a lot of what makes agents powerful.
Here's what stops working while the sandbox is asleep:
- Schedules ("loops"): A sleeping sandbox can't wake itself to trigger something. Your harness outside the sandbox is responsible for waking it.
- Workflows ("graphs"): A durable multi-step workflow retries failures and may sleep for hours. Something has to exist outside the sandbox to resume it.
- Loading sessions quickly: Reading a session shouldn't require waking a sandbox, because starting one can take a long time. Store the history in an external database and reads are instant.
- Indexing sessions: Searching across sessions means reading every transcript, and you can't wake a fleet of sandboxes to build an index. With history outside, indexing is just a database job.
# The Correct Architecture: Expose the Sandbox as Tools
What does the correct architecture look like for agents and sandboxes? It requires moving the agent harness from running inside the sandbox to running in your own backend.
When the harness needs to execute a script, read or write a file, or do anything else in the sandbox, it goes through a tool that makes a remote call into the sandbox.
Nothing ever executes on the machine the harness runs on. Instead, everything executes as tool calls into the sandbox.
# A Simple Example with the Vercel AI SDK
To introduce the concept, let's start with the simplest possible version: a generateText loop and the sandbox exposed as tools. There's no framework and no orchestration layer here. It's three tools and a loop, about 90 lines of code.
The code does three things:
Step 1: Create the sandbox on the local Docker provider:
Step 2: Define the tools that call into the sandbox:
Step 3: Set up the agent loop, reading tasks from the terminal:
This gives you full control of the agent's sessions, their permissions, observability, and everything else we discussed above.
The full runnable example is on GitHub.
# Taking It to Production: The Problem of Stateless HTTP Servers
The above script works great on your local dev machine, but now we need to productionize it.
But there's a problem. Most backends are stateless HTTP servers, and running an agent on top of them gets ugly fast:
- Race conditions: Two calls to the same agent land on different servers, and both run the loop and write history at once.
- Canceling prompts: Stopping a prompt mid-run means reaching into whichever request is running it, and stateless servers give you no way to do that.
- Multiplayer: Multiple users talking to the same agent need a shared, live place to connect, and a stateless endpoint can't do that.
- Durability and fault tolerance: If the server dies mid-loop, the agent dies with it, and nothing resumes it.
Another alternative you might consider is a workflow engine for "durable agents." But an agent's main loop runs indefinitely, and workflow engines were never built for loops that never end:
- Replays get slow: Workflow engines rebuild state by replaying every step so far, and a loop that never ends means a replay that never stops growing. (Some workflow engines have hacks to cap the history, but they're not built for this.)
- Hard to upgrade mid-run: Changing workflow code under a live run is notoriously difficult, and an agent that never exits means every deploy happens mid-run.
- No realtime or multiplayer: A workflow can't hold a WebSocket or stream tokens to a client, so you end up building a separate layer for that.
Stateless servers and workflow engines fail for the same reason. An agent is a long-lived, stateful workload, and neither is built for that.
# The Actor Model: The Stateful Architecture for Agents
The problem of stateful workloads is nothing new.
Imagine running a tiny Node.js process forever for every agent: it restarts when it crashes, sleeps when it's idle, and you can send requests to it.
That's the actor model: one actor per agent, each with its own sandbox. It's the same architecture behind WhatsApp, Discord, and Halo's multiplayer, and it's the best way to run agents in production.
Looking back at the agent loop we built in the previous step, this fits the actor model well. Our agent needs to:
- Run for a long period of time: The agent loop survives anything. If the actor crashes or the sandbox enters a corrupt state, the actor restarts and picks up where it left off.
- Maintain state between runs: Each actor gets its own SQLite database, so session history lives right next to the loop.
- Sleep when idle: When the user goes quiet, the actor sleeps. Awake, it's a couple megabytes of RAM. You pay web-request prices for a stateful process.
- Wake up when the user prompts it again, or on a schedule: Actors wake on requests, on a schedule or cron, and workflows are a subset of actors.
In addition, actors also provide:
- Multiplayer & realtime by default: Multiple clients can talk to the same actor, with WebSockets for realtime collaboration.
- Scales horizontally: One actor per agent, spread across as many machines as you need. Spinning up agents in parallel is the default, not a project.
This guide uses Rivet Actors specifically for demos, but any tool that imeplments the actor model also applies.
# Moving the Agent Loop into an Actor
Here's a simple example of implementing this with actors. The code spans three files (client.ts, actors.ts, and server.ts), and the complete working version is about 180 lines of code:
Step 1: The actor creates a sandbox when it wakes, reattaching to the same sandbox across sleeps and restarts:
Step 2: Set up the tools to talk to the sandbox:
Step 3: Process the prompt off the durable queue, with the session history in the actor's SQLite database:
Step 4: Register the actor and start the server:
Step 5: The user creates an agent, which creates an actor. Each key is an independent agent with its own actor, sandbox, and history:
Step 6: The user sends a prompt, queued on the actor:
The full runnable example is on GitHub.
# Frameworks That Run the Harness Outside the Sandbox For You
This architecture is already well proven, despite being poorly communicated across the industry. There are a lot of options that run the harness outside of the sandbox for you:
- Rivet Actors (bring your own harness): Rivet Actors are the most flexible option for bringing your own harness with sandboxes, because it's a generic primitive, and it's open-source and self-hostable. See the documentation and GitHub.
- agentOS (existing harnesses): agentOS is built on top of Rivet Actors, and it provides support for this architecture with mainstream harnesses like Claude Code, Codex, OpenCode, and Pi. It also lets you provide your own custom agent, and supports talking to sandboxes using sandbox mounting. See the documentation and GitHub.
- Vercel's Eve (custom harness): Eve provides the agent-outside-the-sandbox architecture with Vercel-native primitives.
- Cloudflare's Flue (modified Pi): Flue provides the same architecture with Cloudflare-native primitives.
- Amp Orbs: Amp Orbs run agents with durable threads, self-scheduling, and agent-to-agent messaging, all automated from the Amp CLI.
- OpenAI's Agents SDK (bring your own sandbox): Sandbox Agents keeps the agent loop in your own harness and delegates execution to a pluggable sandbox client, with hosted providers including Cloudflare, Daytona, E2B, Modal, and Vercel.
- Anthropic's Managed Agents (hosted loop): Managed Agents keep the agent loop on Anthropic's infrastructure while tool execution runs in a sandbox you configure (Cloudflare, Daytona, Modal, and Vercel at launch, or bring your own). It validates the same split, but the loop runs on Anthropic's servers instead of your backend.
# Frequently Asked Questions
- Is it insecure to run the harness outside the sandbox? No. The tools are effectively API calls into a sandbox. Nothing lets the agent run code or touch files on the machine running the harness.
- How do I run Claude Code, Codex, or OpenCode like this? They don't support this architecture natively, but agentOS provides a runtime that enables these harnesses to operate outside of the sandbox. Pi supports it directly: you can swap out its coding tools for tools bound to your sandbox, like the Vercel AI SDK example above.
- Isn't this more expensive than just the sandbox? No. An actor is a few megabytes of RAM, and a lot of the time it's the only thing running instead of the full sandbox. For example, reading or sharing a thread doesn't need to boot the full sandbox.
- What's the latency of running the agent outside the sandbox vs inside? Negligible. Roughly 10 milliseconds extra per tool call in the same datacenter, compared to 50 to 200 milliseconds for a typical API request from your browser.
# Get Started
We've been building Rivet Actors as a fleibile, open-source, and self-hostable primitive for agents. Come join our Discord, drop a reply, or shoot me a DM if you have questions!
- Documentation: rivet.dev/docs/actors
- GitHub: github.com/rivet-dev/rivet
- Discord: rivet.dev/discord
## 相关链接
- [Nathan Flurry](https://x.com/NathanFlurry)
- [@NathanFlurry](https://x.com/NathanFlurry)
- [44K](https://x.com/NathanFlurry/status/2081768022025658672/analytics)
- [OpenAI](https://developers.openai.com/api/docs/guides/agents/sandboxes)
- [Anthropic](https://claude.com/blog/claude-managed-agents-updates)
- [Vercel](https://vercel.com/eve)
- [Cloudflare](https://blog.cloudflare.com/agents-platform-flue-sdk/)
- [Amp](https://ampcode.com/news/agents-in-orbs)
- [on GitHub](https://github.com/rivet-dev/rivet/tree/main/website/src/content/posts/2026-07-27-run-your-harness-outside-the-sandbox/example-agent-simple)
- [SQLite database](https://rivet.dev/docs/actors/sqlite)
- [schedule or cron](https://rivet.dev/docs/actors/schedule)
- [workflows](https://rivet.dev/docs/actors/workflows)
- [realtime](https://rivet.dev/docs/actors/events)
- [Rivet Actors](https://rivet.dev/)
- [on GitHub](https://github.com/rivet-dev/rivet/tree/main/website/src/content/posts/2026-07-27-run-your-harness-outside-the-sandbox/example-agent-actor)
- [Rivet Actors](https://rivet.dev/docs/actors)
- [documentation](https://rivet.dev/docs/actors)
- [GitHub](https://github.com/rivet-dev/rivet)
- [agentOS](https://agentos-sdk.dev/)
- [sandbox mounting](https://agentos-sdk.dev/docs/sandbox)
- [documentation](https://agentos-sdk.dev/docs)
- [GitHub](https://github.com/rivet-dev/agentos)
- [Eve](https://vercel.com/eve)
- [Flue](https://blog.cloudflare.com/agents-platform-flue-sdk/)
- [Amp Orbs](https://ampcode.com/news/agents-in-orbs)
- [Sandbox Agents](https://developers.openai.com/api/docs/guides/agents/sandboxes)
- [Managed Agents](https://claude.com/blog/claude-managed-agents-updates)
- [agentOS](https://agentos-sdk.dev/)
- [swap out its coding tools](https://pi.dev/docs/latest/extensions)
- [Rivet Actors](https://rivet.dev/docs/actorS)
- [rivet.dev/docs/actors](https://rivet.dev/docs/actors)
- [github.com/rivet-dev/rivet](https://github.com/rivet-dev/rivet)
- [rivet.dev/discord](https://rivet.dev/discord)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [11:45 PM · Jul 27, 2026](https://x.com/NathanFlurry/status/2081768022025658672)
- [44.3K Views](https://x.com/NathanFlurry/status/2081768022025658672/analytics)
- [View quotes](https://x.com/NathanFlurry/status/2081768022025658672/quotes)
---
*导出时间: 2026/7/28 13:01:21*
---
## 中文翻译
# 在沙箱之外运行你的控制层（原因与做法）
**作者**: Nathan Flurry
**日期**: 2026-07-27T15:45:48.000Z
**来源**: [https://x.com/NathanFlurry/status/2081768022025658672](https://x.com/NathanFlurry/status/2081768022025658672)
自 2026 年初以来，关于在哪里运行代理一直存在激烈的争论：是在沙箱内部，还是外部。这两种方式都有很多实现，但对于成熟的项目来说，行业正朝着在沙箱之外运行代理的方向发展。
在过去的几个月里，OpenAI、Anthropic、Vercel、Cloudflare 和 Amp 都发布了在沙箱之外运行代理循环的平台。
# 在沙箱内运行代理：易于设置，难以维护
许多公司一开始选择在沙箱内运行代理，因为坦率地说，这很简单。设置起来大概是这样的：
但是，当公司采用这种架构运行时，他们开始与沙箱内部运行环境的固有混乱性质进行一场艰难的对抗。
# 为什么不在沙箱中运行代理
沙箱是为了运行不受信任的代码而构建的，而不是为了托管代理本身。在沙箱内运行代理会因为三个原因而分崩离析：
## 原因 1：爆炸半径
沙箱是用来容纳代理制造的混乱的地方。这是设计使然，代理在沙箱内可以做任何事情，没有任何结构限制，因此沙箱会因无数种原因而崩溃。构建命令导致沙箱内存溢出 (OOM)，失控的脚本占满 CPU，失败的工具安装破坏了 `$PATH`，或者文件系统仅仅是损坏了。
当沙箱崩溃时，它会把以下东西也拖垮：
- 代理循环、重试和持久性：本应从故障中恢复的持久机制会随着沙箱的死亡而消亡。重试机制需要存在于你的后端中，这样你才能优雅地处理沙箱本身的故障。
- 会话历史：如果历史记录存储在沙箱内部，它就会随着其他所有东西一起被破坏或擦除。将其保留在外部的真实数据库中。
- 故障的可观测性：如果沙箱死亡，它将无法向可观测性系统报告自己的故障。从你自己的后端发送检测到的故障。
## 原因 2：信任边界
沙箱旨在采用“零信任”架构，因为代理容易受到提示注入攻击并泄露敏感信息。如果某样东西在沙箱中可访问，那么可以安全地假设该数据或 API 会被滥用和泄露。
你无法在沙箱中安全地执行以下任何操作：
- LLM 凭证和路由：沙箱内的令牌是代理可能泄露或滥用的令牌。将其保留在外部。（某些路由器具有每租户范围的令牌，这有助于缓解此问题。）
- 权限和批准：编码代理被训练为绕过障碍，因此在沙箱内执行的权限是代理可能绕过的权限。在你受信任的后端外部执行它们。
- 审计日志：从沙箱内部写入的审计日志是代理可以操纵或损坏的日志。从外部写入。
- 多人安全：对沙箱的访问就是对一切的访问，因此无法在其中为协作者提供每用户权限。在你的后端中强制执行每用户权限。
- 受信任的工具：与私有数据库或内部 API 通信的工具需要沙箱无法信任的凭据。将它们作为控制层中的工具提供，无需自定义身份验证代理。
- 代理到代理的通信：沙箱到沙箱的通信意味着每个沙箱都必须保存其同级的地址和凭据，这很复杂、容易出错且不安全。改为在你的后端中路由代理间的通信，在那里你不需要复杂的身份验证和路由机制。
## 原因 3：沙箱并不总是在运行
根据设计，沙箱在不使用时会进入睡眠状态。但这破坏了代理强大功能的许多方面。
在沙箱睡眠期间，以下功能将停止工作：
- 计划任务（“循环”）：睡眠的沙箱无法唤醒自己来触发某些事情。你在沙箱之外的控制层负责唤醒它。
- 工作流（“图”）：一个持久的多步骤工作流会重试失败，并且可能会睡眠数小时。必须在沙箱外部存在某种东西来恢复它。
- 快速加载会话：读取会话不应需要唤醒沙箱，因为启动沙箱可能需要很长时间。将历史记录存储在外部数据库中，读取是即时的。
- 索引会话：跨会话搜索意味着读取每个脚本，你无法唤醒一群沙箱来构建索引。如果历史记录在外部，索引只是一个数据库作业。
# 正确的架构：将沙箱作为工具暴露
对于代理和沙箱来说，正确的架构是什么样的？它需要将代理控制层从沙箱内部移动到你自己的后端中运行。
当控制层需要执行脚本、读取或写入文件或在沙箱中执行任何其他操作时，它会通过一个工具进行，该工具向沙箱发起远程调用。
没有任何东西在控制层运行的机器上执行。相反，所有操作都作为工具调用在沙箱中执行。
# 使用 Vercel AI SDK 的简单示例
为了介绍这个概念，让我们从最简单的版本开始：一个 `generateText` 循环和作为工具暴露的沙箱。这里没有框架，也没有编排层。它包含三个工具和一个循环，大约 90 行代码。
这段代码做了三件事：
步骤 1：在本地 Docker 提供程序上创建沙箱：
步骤 2：定义调用沙箱的工具：
步骤 3：设置代理循环，从终端读取任务：
这使你可以完全控制代理的会话、它们的权限、可观测性以及我们在上面讨论的所有其他内容。
完整的可运行示例在 GitHub 上。
# 投入生产：无状态 HTTP 服务器的问题
上面的脚本在你的本地开发机器上运行得很好，但现在我们需要将其产品化。
但这里有一个问题。大多数后端都是无状态的 HTTP 服务器，在它们之上运行代理很快就会变得很难看：
- 竞态条件：对同一代理的两个调用落在不同的服务器上，并且两者都同时运行循环并写入历史记录。
- 取消提示：在运行中途停止提示意味着接触到正在运行它的任何请求，而无状态服务器无法给你提供这样做的途径。
- 多人协作：多个用户与同一个代理对话需要一个共享的、实时的连接场所，而无状态端点无法做到这一点。
- 持久性和容错能力：如果服务器在循环中途死亡，代理也会随之死亡，没有任何东西能恢复它。
你可能会考虑的另一种替代方案是用于“持久代理”的工作流引擎。但是，代理的主循环是无限期运行的，而工作流引擎从来都不是为永不结束的循环而构建的：
- 重放变慢：工作流引擎通过重播到目前为止的每一步来重建状态，而一个永不结束的循环意味着一个永不停止增长的重放。（一些工作流引擎有变通方法来限制历史记录，但它们不是为此而构建的。）
- 难以中途升级：在实时运行下更改工作流代码是出了名的困难，而一个永不退出的代理意味着每次部署都是在运行中途进行的。
- 没有实时功能或多人协作：工作流无法保持 WebSocket 或将令牌流式传输给客户端，因此你最终需要为此构建一个单独的层。
无状态服务器和工作流引擎失败的原因是相同的。代理是一个长期存在的、有状态的工作负载，而这两者都不是为此而构建的。
# Actor 模型：代理的有状态架构
有状态工作负载的问题并不新鲜。
想象一下为每个代理永远运行一个微小的 Node.js 进程：它会在崩溃时重启，在空闲时睡眠，并且你可以向它发送请求。
这就是 Actor 模型：每个代理一个 Actor，每个都有自己的沙箱。这是 WhatsApp、Discord 和 Halo 多人游戏背后的相同架构，也是在生产环境中运行代理的最佳方式。
回顾我们在上一步构建的代理循环，这非常符合 Actor 模型。我们的代理需要：
- 运行很长时间：代理循环可以经受任何考验。如果 Actor 崩溃或沙箱进入损坏状态，Actor 会重新启动并从上次中断的地方继续。
- 在运行之间保持状态：每个 Actor 都有自己的 SQLite 数据库，因此会话历史就紧挨着循环存在。
- 空闲时睡眠：当用户保持沉默时，Actor 会睡眠。唤醒时，它只占用几兆字节的 RAM。你为有状态进程支付 Web 请求级别的价格。
- 当用户再次提示它或按计划唤醒时：Actor 可以通过请求、计划或 cron 唤醒，工作流是 Actor 的一个子集。
此外，Actor 还提供：
- 默认支持多人协作和实时功能：多个客户端可以与同一个 Actor 对话，并通过 WebSocket 进行实时协作。
- 水平扩展：每个代理一个 Actor，分布在尽可能多的机器上。并行启动代理是默认设置，而不是一个项目。
本指南专门使用 Rivet Actors 进行演示，但任何实现 Actor 模型的工具都适用。
# 将代理循环移动到 Actor 中
这是一个使用 Actor 实现此功能的简单示例。代码跨越三个文件（client.ts、actors.ts 和 server.ts），完整的工作版本大约 180 行代码：
步骤 1：Actor 在唤醒时创建一个沙箱，在睡眠和重启期间重新连接到同一个沙箱：
步骤 2：设置与沙箱通信的工具：
步骤 3：从持久队列中处理提示，会话历史位于 Actor 的 SQLite 数据库中：
步骤 4：注册 Actor 并启动服务器：
步骤 5：用户创建一个代理，该代理创建一个 Actor。每个密钥都是一个独立的代理，拥有自己的 Actor、沙箱和历史记录：
步骤 6：用户发送提示，该提示在 Actor 上排队：
完整的可运行示例在 GitHub 上。
# 为你在沙箱之外运行控制层的框架
尽管这种架构在整个行业交流中很少被提及，但它已经得到了很好的验证。有很多选项可以为你自动在沙箱之外运行控制层：
- Rivet Actors（自带控制层）：Rivet Actors 是使用沙箱自带控制层最灵活的选项，因为它是一个通用原语，并且是开源和可自托管的。请参阅文档和 GitHub。
- agentOS（现有的控制层）：agentOS 构建在 Rivet Actors 之上，它使用 Claude Code、Codex、OpenCode 和 Pi 等主流控制层为此架构提供支持。它还允许你提供自己的自定义代理，并支持使用沙箱挂载与沙箱通信。请参阅文档和 GitHub。
- Vercel's Eve（自定义控制层）：Eve 使用 Vercel 原生原语提供了代理在沙箱之外的架构。
- Cloudflare's Flue（修改版的 Pi）：Flue 使用 Cloudflare 原生原语提供了相同的架构。
- Amp Orbs：Amp Orbs 使用持久线程、自我调度和代理到代理消息传递运行代理，所有这些都通过 Amp CLI 自动化。
- OpenAI's Agents SDK（自带沙箱）：Sandbox Agents 将代理循环保留在你自己的控制层中，并将执行委托给可插拔的沙箱客户端，托管提供商包括 Cloudflare、Daytona、E2B、Modal 和 Vercel。
- Anthropic's Managed Agents（托管循环）：Managed Agents 将代理循环保留在 Anthropic 的基础设施上，而工具执行在你配置的沙箱中运行（发布时有 Cloudflare、Daytona、Modal 和 Vercel，或者自带）。它验证了相同的分离，但循环运行在 Anthropic 的服务器上而不是你的后端。
# 常见问题
- 在沙箱之外运行控制层是否不安全？不。这些工具实际上是对沙箱的 API 调用。没有任何东西允许代理在运行控制层的机器上运行代码或接触文件。
- 我该如何像这样运行 Claude Code、Codex 或 OpenCode？它们本身不支持这种架构，但 agentOS 提供了一个运行时，使这些控制层能够在沙箱之外运行。Pi 直接支持它：你可以将其编码工具替换为绑定到沙箱的工具，就像上面的 Vercel AI SDK 示例一样。
- 这不是比仅仅使用沙箱更贵吗？不。一个 Actor 只有几兆字节的 RAM，而且在很多时候，它是唯一运行的东西，而不是完整的沙箱。例如，读取或共享线程不需要启动完整的沙箱。
- 在沙箱之外运行代理与在内部运行相比，延迟是多少？可以忽略不计。与浏览器发出的典型 API 请求的 50 到 200 毫秒相比，同一数据中心内每次工具调用大约多 10 毫秒。
# 开始使用
我们一直在构建 Rivet Actors，将其作为一个灵活、开源且可自托管的代理原语。加入我们的 Discord，回复推文，或者如果有问题直接给我发私信！
- Documentation: rivet.dev/docs/actors
- GitHub: github.com/rivet-dev/rivet
- Discord: rivet.dev/discord
## 相关链接
- [Nathan Flurry](https://x.com/NathanFlurry)
- [@NathanFlurry](https://x.com/NathanFlurry)
- [44K](https://x.com/NathanFlurry/status/2081768022025658672/analytics)
- [OpenAI](https://developers.openai.com/api/docs/guides/agents/sandboxes)
- [Anthropic](https://claude.com/blog/claude-managed-agents-updates)
- [Vercel](https://vercel.com/eve)
- [Cloudflare](https://blog.cloudflare.com/agents-platform-flue-sdk/)
- [Amp](https://ampcode.com/news/agents-in-orbs)
- [on GitHub](https://github.com/rivet-dev/rivet/tree/main/website/src/content/posts/2026-07-27-run-your-harness-outside-the-sandbox/example-agent-simple)
- [SQLite database](https://rivet.dev/docs/actors/sqlite)
- [schedule or cron](https://rivet.dev/docs/actors/schedule)
- [workflows](https://rivet.dev/docs/actors/workflows)
- [realtime](https://rivet.dev/docs/actors/events)
- [Rivet Actors](https://rivet.dev/)
- [on GitHub](https://github.com/rivet-dev/rivet/tree/main/website/src/content/posts/2026-07-27-run-your-harness-outside-the-sandbox/example-agent-actor)
- [Rivet Actors](https://rivet.dev/docs/actors)
- [documentation](https://rivet.dev/docs/actors)
- [GitHub](https://github.com/rivet-dev/rivet)
- [agentOS](https://agentos-sdk.dev/)
- [sandbox mounting](https://agentos-sdk.dev/docs/sandbox)
- [documentation](https://agentos-sdk.dev/docs)
- [GitHub](https://github.com/rivet-dev/agentos)
- [Eve](https://vercel.com/eve)
- [Flue](https://blog.cloudflare.com/agents-platform-flue-sdk/)
- [Amp Orbs](https://ampcode.com/news/agents-in-orbs)
- [Sandbox Agents](https://developers.openai.com/api/docs/guides/agents/sandboxes)
- [Managed Agents](https://claude.com/blog/claude-managed-agents-updates)
- [agentOS](https://agentos-sdk.dev/)
- [swap out its coding tools](https://pi.dev/docs/latest/extensions)
- [Rivet Actors](https://rivet.dev/docs/actorS)
- [rivet.dev/docs/actors](https://rivet.dev/docs/actors)
- [github.com/rivet-dev/rivet](https://github.com/rivet-dev/rivet)
- [rivet.dev/discord](https://rivet.dev/discord)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [11:45 PM · Jul 27, 2026](https://x.com/NathanFlurry/status/2081768022025658672)
- [44.3K Views](https://x.com/NathanFlurry/status/2081768022025658672/analytics)
- [View quotes](https://x.com/NathanFlurry/status/2081768022025658672/quotes)
---
*导出时间: 2026/7/28 13:01:21*