近日，DigitalOcean 正式向所有用户开放 DigitalOcean 托管 Agent 服务。
现在，团队可以直接部署自己偏好的 Agent Harness，例如 OpenCode、Codex CLI，也可以使用自定义方案；同时还可以让 Agent 接入 16,000 多个工具，在无需自行搭建和维护底层基础设施的情况下，让 Agent 承担更多工作并扩展到更大规模。
托管 Agent 服务与 DigitalOcean 推理引擎（Inference Engine） 原生集成，把推理 Token、Agent 执行和工具调用整合到同一个平台中，让整个 Agent 工作负载可以集中运行和扩展。
Agent 从创建 Session 到返回响应只需不到几秒，恢复暂停任务大约只需 300 毫秒。平台按照活跃 CPU 使用时间按秒计费，因此你只需要为 Agent 实际消耗的 CPU 付费。目前，包括 OpenHands、Qencode 和 Amplitude 在内的客户已经开始基于 托管Agent服务构建和扩展 Agent 应用。
为什么 Agent 工作负载与传统云应用不同？
如今，开发者和企业团队正在让 Agent 承担越来越复杂的工作：开发新功能、排查生产环境问题、构建应用、跨系统研究信息，以及协调多个子 Agent 完成不同任务。
例如，一个 Agent 正在排查结账错误突然增加的问题。它可能先通过 MCP Server 查询多个服务的日志，然后编写并运行脚本复现问题，接着测试修复方案，最后创建一个 Pull Request，交给团队成员审核后再上线生产环境。
查询日志、执行复现脚本和测试修复方案，这些步骤在短时间内都可能需要大量 CPU 和内存。但在这些步骤之间，或者等待模型生成 Token、等待人工审批时，Agent 可能几乎不消耗 CPU。
问题在于，即便 Agent 暂时不运行，它的上下文、文件和工作状态仍然需要持续保留，这样才能在恢复之后从原来的位置继续执行。
软件开发之外的 Agent 工作负载同样需要执行代码，并生成其他人可以继续使用的产物。
例如，一个帮助团队进行库存规划的 Agent，可能需要读取销售数据和供应商 PDF，运行蒙特卡洛模拟来预测需求和交付延迟，然后生成报告并给出库存水平建议。
为了完成这些任务，它需要一个隔离的 Sandbox，可以安装依赖、执行代码、分析结果并生成报告。同时，数据集、脚本和报告不能随着 Session 结束而消失，因为团队成员可能还需要继续审核结果，或者由另一个 Agent 在新数据到来后更新分析。
传统虚拟机提供的，本质上只是“一台空白电脑”。开发者仍然需要自己搭建 Agent 工作流真正需要的运行环境和 API。
这意味着团队不得不投入大量精力处理基础设施层面的工作，例如保存 Agent 上下文、持久化任务产物、让这些文件在原 Agent 结束后仍然可访问、协调并行任务，以及为工具访问增加安全控制。
为了让 Agent 能够快速启动，可以提前保持一批 VM 运行，但这会产生大量空闲成本；如果按需创建和配置资源，又可能需要几分钟，从而拖慢 Agent 执行速度。
而且，只要 VM 仍然处于配置状态，即使 Agent 正在等待模型响应、工具结果或者人工批准，CPU 费用仍然会持续产生。
花在“让 VM 适合 Agent 工作负载”上的时间，本可以用来提升 Agent 真正为用户创造价值的能力。
Agent 工作负载需要的是专门为它设计的基础设施：经过安全加固的代码执行环境、持久化 Session、快速启动能力，以及受到权限控制的工具访问。
Checkpoint 和 Fork 机制可以让任务分支、暂停，并在不同设备和不同团队成员之间继续执行。基于活跃 CPU 的计费方式，则可以让成本真正与实际资源消耗挂钩。
托管Agent服务并不是把通用虚拟机简单改造成 Agent 环境，而是从一开始就围绕 Agent 工作负载设计了一套基础能力，让开发者把精力集中在真正重要的事情上：让 Agent 能完成更有价值的工作。
DigitalOcean 托管 Agent 服务：为 Agent 提供专属运行环境
DigitalOcean 托管 Agent 服务主要由两个部分组成：Harness Runtime 负责 Agent 的运行环境和任务状态，Action Gateway 负责 Agent 与外部工具之间的连接和权限控制。
- DigitalOcean Harness Runtime 为 Agent 提供一个可持续运行的云端工作环境。它把轻量级 microVM、Chromium、Coding Sandbox 等常用能力整合在一起，Agent 可以直接在其中安装依赖、执行代码、操作文件和运行后台任务。同时，Harness Runtime 提供 Session 生命周期管理能力，可以保留对话历史和工作状态，并支持暂停、恢复和 Fork。这样一来，Agent 即使中途等待模型、人工审批或外部工具响应，也不必每次都从头重新创建环境。
- DigitalOcean Action Gateway 解决的是 Agent 如何安全调用外部工具的问题。通过一个托管 MCP Endpoint，Agent 可以在统一的权限控制下访问 16,000 多个工具，包括 Web Search、Web Fetch、Browser Automation、DigitalOcean 基础设施管理 API，以及 GitHub、HubSpot、Stripe、Snowflake、Box、Supabase、Exa 等常用平台。团队也可以接入自己的 MCP Server 和内部工具，把现有系统纳入同一套工具调用体系。
简单来说，Harness Runtime 负责“Agent 在哪里运行、任务状态如何保留”，Action Gateway 则负责“Agent 可以调用哪些工具、以什么权限调用”。
两者配合之后，开发者不需要再单独搭建执行环境、持久化机制和工具接入层，就可以把更多精力放在 Agent 本身的能力和业务逻辑上。
下面分别来看看 Harness Runtime 和 Action Gateway 具体提供了哪些能力。
DigitalOcean Harness Runtime：让 Agent Session 不再依赖你的本地电脑
Harness Runtime 为 Agent 提供一个持久化的云端工作空间。Agent 可以在其中执行代码、操作任务产物，并在不同设备和团队成员之间继续工作。
计算、存储以及 Session 生命周期都由平台负责管理，因此开发者可以并行运行多个 Agent、尝试不同解决方案，并随时回到正在进行的任务，而无需重新构建环境和上下文。
Harness Runtime 提供了 Agent 工作所需的几项关键能力：
- 基于 Firecracker microVM 的隔离执行环境。 每个 Session 都运行在独立的 Firecracker microVM 中，拥有自己的计算资源和文件系统。通过硬件虚拟化，对 Agent 安装依赖、执行生成代码和运行后台进程的环境进行隔离。
- Execution 和 Access API。 可以通过
exec执行命令、启动测试以及检查 Session 环境。经过安全加固的端口转发功能，让开发者无需把服务直接暴露到公网，就可以预览应用并连接 Session 内运行的服务。 - 基于 Snapshot Storage 的暂停与恢复。 暂停 Session 时，系统会保存当前工作状态，因此恢复之后，文件、进程和上下文都可以保持不变。Session 暂停期间不再收取 CPU 和内存费用，但保留的存储空间仍然计费。Harness Runtime 还支持自动暂停：当一段时间内没有向 LLM 或工具发出请求时，可以自动把 Agent 视为空闲状态并暂停。
- 并行 Session 与子 Agent 工作流。 可以运行多个子 Agent，也可以针对不同代码仓库和任务启动独立 Session。针对每种支持的 Harness，相关 API 都以 Skills 的形式提供，让 Agent 可以方便地创建并行任务，例如分治、协作以及 Map/Reduce 场景。
- 完整查看每一次运行过程。 结构化事件会记录工具调用、模型请求和文件操作。你可以查看 Token 使用量和审批操作，同时监控 Session 日志和指标，用于调试运行过程、审计 Agent 行为，并基于真实 Agent 工作构建评测体系。
你可以使用 Claude Code、Codex CLI、OpenCode 等 Coding Harness，也可以运行 Hermes 等通用 Agent，或者基于 LangGraph 构建 Agent。
此外，还可以把自定义 Agent 打包成标准 OCI 容器镜像，并将其转换成可重复使用的环境模板。这样，你可以直接带上自己的依赖、工具和配置，而无需围绕 DigitalOcean 特定的 Harness 重新构建一套 Agent。
DigitalOcean Action Gateway：让 Agent 在权限控制下访问工具并完成真实任务
一个负责处理生产故障的 Agent，可能需要查看代码仓库、读取工单、查询数据库，然后通知团队。
这些步骤中的每一步，都需要访问另一个系统。
如果逐个连接这些工具，开发者就需要分别处理每个集成的身份认证、权限管理、重试机制以及监控。
Action Gateway 把这些工作统一放到一个托管 MCP Endpoint 后面，让 Agent 可以在权限控制下访问 来自 500 多个平台的 16,000 多个工具。
你可以连接 GitHub、HubSpot、Stripe、Snowflake、PagerDuty、Box、Supabase 和 Exa 等服务，同时还可以使用 Web Search、Browser Automation、代码执行以及你自己的 MCP Server。
- 让凭据始终处于 Agent 环境之外。 凭据会在执行时由 Gateway 代为处理，不会直接进入模型或 Sandbox。工具可以通过 API Key、共享 OAuth 应用或者单用户 OAuth 接入。当工作流运行过程中需要授权时，Gateway 会提供登录链接，并在授权完成之后继续执行原来的工具调用。
- 控制 Agent 可以执行哪些操作。 集中的客户权限系统可以定义每个 Agent 能使用哪些工具和操作。对于敏感操作，可以要求人工审批，让 Agent 在团队设定的边界内自主执行任务。
- 随着工作负载增长处理更多工具流量。 内置的限流管理、重试、退避机制和超时控制，可以在越来越多 Agent 调用外部系统时，让工作流继续稳定运行。
- 找到正确的工具，同时避免把整个工具目录塞进模型上下文。 Action Gateway 会针对每个任务向 Agent 提供相关且已获批准的工具，而不需要把全部工具列表加载进 Context。根据 DigitalOcean 内部测试，即使请求中的表达方式与工具名称或描述不同，Action Gateway 仍然能够以 99.3% 的准确率，将 Agent 的任务意图匹配到正确的工具能力。相比传统的关键词工具搜索，这种方式准确率更高，同时也能更快找到需要的工具。
Action Gateway 不仅可以和 Harness Runtime 配合使用，也支持其他兼容 MCP 的应用。
只需要把 Action Gateway Endpoint 添加到应用的 MCP 配置中，就可以访问已经连接的工具，同时继续使用同一套集中式权限和控制机制。
按照实际资源消耗计费
Agent 的资源使用往往呈现明显的突发性。
它可能先编译代码、运行测试，然后等待模型返回结果或者等待外部工具响应。Harness Runtime 的 CPU 计费方式 会根据 CPU 的实际使用量计算，因此当 Agent 处于等待状态、没有消耗 CPU 时，对应的 CPU 费用也会降到 0。
例如，一个配置 2 个 vCPU 的 Session，如果 1 小时内平均 CPU 利用率为 25%，同时内存峰值保持在 4 GB，那么 CPU 和内存费用为 0.060 美元。
如果按照整整 1 小时的已分配资源计费，相同配置的成本则为 0.126 美元。
存储、模型推理以及单独计费的工具还会产生额外费用。
暂停 Session 之后，CPU 和内存费用停止计算，但保存的 Session 状态仍然会占用存储并继续计费。
Action Gateway 中需要 Sandbox 的第一方工具，会按照 Harness Runtime 的计算和内存价格计费；第三方工具则按照各自公开的按次使用价格收费。
Agent 运行性能实测
更快的启动和恢复速度，可以减少“Agent 响应速度”和“空闲基础设施成本”之间的取舍。
当 Coding Agent 必须先获得一个执行环境才能开始工作时，环境创建所需的时间会直接变成用户的等待时间。
而当环境在任务之间处于空闲状态，或者正在等待人工操作时，如果为了保持响应速度一直让环境运行，就会持续产生成本。
暂停可以保留工作状态，而快速恢复则可以让这些状态很快重新投入使用。
延迟的重要性，取决于它发生在什么阶段，以及会重复多少次。
启动延迟会影响第一次响应；恢复延迟会影响下一轮交互；如果 Agent 经常需要在不同环境状态之间切换，那么这些重复产生的延迟还可能减少 Agent 在固定时间内能够完成的探索和测试次数。
我们的目标，是尽量减少 Agent 等待基础设施的时间，同时让暂停空闲 Session 成为一个真正可行的选择。
因此，我们同时测试两个指标：运行环境何时真正 Ready，以及从开始创建 Session 到 Agent 真正返回响应需要多久。
通过各个平台公开 API，我们使用相同的 Coding Agent 和相同模型，完整执行一次 Session 创建、首次响应、暂停、恢复以及第二次响应流程。
更快的启动速度，可以让 Agent 更早开始真正有价值的工作。
“Create → agent response” 衡量的是从发起 Session 创建请求，到 Agent 完成一次完整回复的全过程，其中包括创建 microVM、启动 Harness，以及完成一轮模型调用。
在这次 Benchmark 中，Harness Runtime 在 886 毫秒内进入 Ready 状态，并在 3.3 秒内返回第一次响应。
同时衡量这两个指标，可以把基础设施本身产生的额外开销，与用户真正感受到的等待时间区分开来。
更快的恢复速度，让暂停 Session 真正具备实用价值。
开发者应该能够暂停空闲 Session，同时又不会让下一次交互感觉像“重新启动了一遍”。
Harness Runtime 从暂停状态恢复到 Ready 只需要 305 毫秒。
在这次 Benchmark 中，恢复后的 Session 在 2.43 秒内返回 Agent 响应，与已经处于运行状态的 Session 测得的 2.47 秒几乎相同。
这些结果意味着，可以通过 Auto-pause 在任务间隙停止计算和内存计费，同时用户返回后仍然能够获得快速响应。
Active CPU Billing 则解决生命周期中的另一个问题：当正在运行的 Agent 只是等待模型或者工具响应、实际上没有消耗 CPU 时，不再收取对应 CPU 费用。
命令执行性能仍然是我们需要继续优化的地方。
“Run a command” 衡量的是已经处于运行状态的 Session 中，一次命令执行的完整往返时间。
Harness Runtime 测得为 189 毫秒，而 Sprites 为 79 毫秒。
托管Agent服务的 exec 请求需要经过 DigitalOcean Edge 和 Harness Runtime Control Plane，以完成身份认证、授权以及审计日志记录。
因此，目前测试得到的命令执行链路比对方慢 110 毫秒。
如何在保留这些安全和控制能力的同时降低这部分额外开销，仍然是我们的重点性能优化方向。
注：Fly.io Sprites 没有独立的 Resume API，因此其恢复时间为估算值，并非直接通过 Resume 调用测得。DigitalOcean 内部 Benchmark，2026 年 9 月 21 日。所有平台均使用 Codex CLI 原生 Agent 模式调用 gpt-5.5，通过各平台公开 API，从 RIC1 的 DigitalOcean Droplet 发起测试。每个平台执行相同数量的完整测试流程，取 p50，并剔除预热运行。所有平台均请求 2 vCPU / 4 GB Session；Fly.io Sprites Guest 实际报告为 8 vCPU / 16 GB。不同平台使用的 Agent CLI 版本有所不同：托管Agent服务为 0.154.0，Sprites 为 0.151.0。_
几秒钟即可开始使用
通过 CLI 启动一个 Session：
# Authenticate with your DigitalOcean account
doctl auth init
# Start a session. --harness builds the manifest for you and
# prompts for your Anthropic key if it isn't already exported
doctl harness-runtime launch --harness claude-code --name my-first-agent
# You're dropped straight into a chat with the agent.
# Detach any time with Ctrl-D, then reattach later,
# from any device, right where you left off
doctl harness-runtime launch my-first-agent
如果通过代码助手创建 Agent，可以使用下面这段 Prompt：
Set me up on DigitalOcean 托管Agent服务and leave me with a working agent.
Docs: https://docs.digitalocean.com/products/managed-agents/ — add index.html.md to any page for the markdown version. I have nothing installed or configured yet, so install doctl and get me authenticated. Never ask me to paste a token or any other secret into this chat.
Use this spec as written. It needs no model key and it attaches the tool catalog:
name: my-first-agent
agent: opencode
tools:
- do.actions
permissions:
default: ask
Then give it a job big enough to take a few minutes — a sourced brief on what shipped this week in AI, written to its workspace. Approve the tool calls for this first run so it can work unattended, and tell me that you did. Don't wait for it to finish: hand me back the commands to check on it, read the file, and pause it.
统一可观测性：在一个地方看清 Agent 做了什么
理解 Agent 一次运行过程中到底做了什么，应该和启动它一样简单。
借助目前处于 Private Preview 阶段的 DigitalOcean Insights，开发者可以在一个界面中查看 Agent 横跨 Harness Runtime、Action Gateway 和内置工具的完整执行过程：它执行了哪些操作、调用了哪些工具、在哪里出现了性能瓶颈，以及最终是如何得到结果的。
不再需要在多个浏览器标签页和不同平台之间来回切换，才能拼凑出一次 Agent 运行的完整过程。
不过，要真正改进 Agent，仅仅分析失败案例还不够。
表现特别好的运行同样可以揭示哪些方法值得进一步强化，就像失败运行可以暴露哪些行为需要修正一样。
即将推出的 Signals 会进一步利用这些可观测数据，帮助开发者把 Agent 运行过程转化为评测和强化学习所需的反馈。
Insights 和 Signals 结合之后，团队不仅可以看到 Agent “做了什么”，还可以进一步理解“为什么这次运行效果更好”，让每一次运行都有机会帮助下一次 Agent 表现得更好。
面向已经在生产环境运行 Agent 的团队
媒体处理公司 Qencode 在 Harness Runtime 上构建了一个客服请求分流 Agent。
在引入自动化之前，他们的团队每周都需要花费数小时，人工处理来自 Slack、Email 和 Intercom 的客服请求。
现在，这个 Agent 会检查每一条新请求，评估紧急程度、用户情绪以及客户收入情况，然后创建或更新对应的 Jira Ticket。
对于置信度较低的情况，则会标记出来，交给团队成员进一步审核。
初步结果显示，这套 Agent 每周可以为团队节省大约 4 到 8 小时的工单分流和状态汇报时间，同时把响应时间从数小时缩短到几乎即时。
“它极大提升了整个团队的效率。正确的 Ticket 会自动交给正确的人处理，不再需要有人一直盯着每一个消息线程。” —— Qencode CEO 兼联合创始人 Murad Mordukhay
DigitalOcean 托管Agent服务目前已经上线。你可以使用自己偏好的 Harness，接入需要的工具，并为 Agent 提供一套真正为其工作方式设计的基础设施，让它们能够承担更多任务。
如果你需要了解更多详情，可直接咨询 DigitalOcean 中国区战略合作伙伴卓普云（aidroplet.com）。
相关产品与选型
