16000个工具通过统一端点直接调用，空闲自动暂停。DigitalOcean把Agent生产环境基建做明白了。
你平时在传统VM上跑Agent，光是搞上下文持久化和工具权限隔离就能掉半条命。这套方案把microVM和MCP网关打包，直接省掉了写底层plumbing的时间，让团队能专注调优Agent逻辑本身。
核心看点
- 基于轻量级microVM的Harness Runtime提供隔离计算环境，支持会话暂停与恢复。
- Action Gateway通过统一MCP端点接入超16000个工具，内置集中权限管理与限流重试。
- 对比Docker Cloud Sandboxes，更侧重生产基础设施的编排与工具支持。
▎微虚拟机与MCP网关的底层逻辑
传统架构下，开发者要在常规VM上自己搭建运行时，处理上下文保持、artifact持久化、并行协调以及安全加固。DigitalOcean Managed Agents 用两个核心组件解决这些痛点。Harness Runtime 跑在轻量级 microVM 上，提供持久化隔离环境。它支持 Claude Code、Codex CLI、OpenCode 等编码Agent，以及 Hermes 和 LangGraph 构建的通用Agent。会话历史和工作状态可以跨会话保留，支持暂停、恢复或fork。每个会话都运行在安全加固的计算和存储资源上，同时允许开发者连接内部服务而不必将它们暴露到公网。当没有LLM或工具调用时，系统会自动暂停Agent以节省资源。
Action Gateway 则是外部工具的统一入口。它通过单一 MCP 端点暴露超 16,000 个工具，涵盖 Web Search、Browser Automation 以及 GitHub、Stripe 等连接器。网关内置集中权限管理，敏感操作必须人工审批，并提供限流、重试和超时机制。
在评估是否引入这套架构时，你需要明确团队的核心瓶颈。如果你的Agent需要跨多个代码仓库执行 divide and conquer 任务，或者需要 map/reduce 这种并行工作流，Harness Runtime 的并行启动能力会大幅缩短总耗时。相反，如果你的业务只是简单的单轮问答，不需要状态持久化，强行上这套微虚拟机架构反而会增加不必要的调度开销。决策的关键在于评估你的Agent对上下文连续性和工具调用并发度的真实需求。
▎与Docker Cloud Sandboxes的路线差异
同期发布的 Docker's Cloud Sandboxes 在沙箱和运行时层面与 DigitalOcean 方案有显著重叠。两者都提供 MicroVM 隔离和状态持久化，但重心完全不同。Docker 的方案死死盯住开发者工作流，核心卖点是把 sandbox 在本地和云算力之间无缝移动。它允许开发者在本地编写代码，然后一键将相同的 sandbox 环境推送到云端执行，这对于需要频繁调试的初创团队非常友好。DigitalOcean 则把筹码押在生产基础设施上，提供更深度的编排和原生工具支持。
这种路线差异直接决定了选型边界。如果你的团队重度依赖本地开发环境的一致性，要求代码在本地笔记本和云端集群里跑出一模一样的结果，Docker 的方案是首选，因为它抹平了环境差异。但如果你是在做大规模的生产级 Agent 部署，需要精细控制每个 Agent 的工具调用权限，并且对闲置成本极其敏感，DigitalOcean 的空闲暂停和受治理工具访问才是正解。选错路线的代价是，要么在本地调试时遇到诡异的云端环境报错，要么在生产环境里因为权限失控导致工具被滥用。
▎接入指南与官方资源
目前 DigitalOcean Managed Agents 已经开启公开预览。你可以直接通过官方博客了解详细的接入流程和计费模型。对于想要测试不同 harness 的团队，官方明确支持 Claude Code、Codex CLI 和 OpenCode 这类编码Agent，也兼容 LangGraph 自定义构建。这些工具不仅包括基础的 Web Search 和 Web Fetch，还深度集成了 DigitalOcean 自身的基础设施管理 API，方便 Agent 直接调配云资源。
官方发布博客：
Elvis Saravia 评价：
Ryan Martin 评价：
Docker 竞品报道：
前 Meta AI 工程师 Elvis Saravia 特别点出了性能和降本，认为很多现有平台成本高得离谱，根本没法在生产环境规模化。Seaotter 创始人 Ryan Martin 的判断更直接：“Pause-when-idle + governed tools is the ops pattern that scales”。在生产环境里，Agent 闲置时依然占用计算资源是吞金兽。这种架构把原本散落在各个业务代码里的权限校验和重试逻辑，统一收口到了网关层。你不需要再为每个 Agent 单独写一套限流和退避算法。把空闲暂停和受治理的工具访问结合起来，确实是让 Agent 运维模式能够线性扩展的唯一解。
点个赞再走？
你现在主力用什么框架跑Agent？并发工具数怎么配的？
往期推荐
- ·一亿美元投资开源平台，GPT-6.1 Astra 取消发布
- ·OpenAI 抢微软饭碗，ChatGPT 上线协作幻灯片功能
- ·OpenAI 上市无时间表，安全对齐成最大拦路虎
点击公众号头像 → 历史消息，可翻阅以上文章
