DigitalOcean 已将 Managed Agents 推向公开预览。它试图解决的并不只是“在哪里运行模型”，而是 AI Agent 上线后更棘手的一组基础设施问题：如何隔离执行环境、约束工具调用，以及按需提供模型推理能力。
这三件事组合在一起，意味着开发者可以把更多精力放在 Agent 的任务逻辑上，但托管并不等于自动安全。尤其在公开预览阶段，团队仍需明确权限边界、审计方式和故障降级策略。
microVM 隔离解决的是执行边界
普通聊天应用通常是“请求进入、模型生成、文本返回”。Agent 则可能执行代码、读取文件、调用内部 API，甚至触发有副作用的操作。此时，运行环境本身就成为安全边界。
Managed Agents 提供隔离的 microVM 运行时。与把多个 Agent 直接放进同一个长期运行进程相比，隔离环境可以缩小单次任务失控后的影响范围，例如：
- Agent 生成的代码进入死循环或消耗过多资源；
- 工具返回了恶意内容，诱导 Agent 读取本地敏感文件；
- 第三方依赖包含漏洞或执行了非预期命令；
- 不同用户或任务之间出现临时文件、环境变量和进程状态泄漏。
不过，microVM 不能替代身份认证和权限控制。一个被隔离的 Agent 如果仍然拿到了生产数据库管理员凭据，依然可能造成严重影响。更稳妥的设计是同时限制以下四个维度：
- 身份：每个 Agent 或工作流使用独立的服务身份；
- 网络：默认禁止外连，只开放必要的目标地址；
- 凭据：按任务临时签发，避免长期密钥进入提示词或日志；
- 生命周期：任务结束后销毁运行环境，不依赖本地状态持久化。
工具治理比提示词约束更可靠
Agent 的真正风险通常发生在“模型决定调用工具”之后。仅在系统提示词里写上“不要删除生产数据”并不构成强制控制，因为提示词可能被覆盖、误解，或受到间接提示注入影响。
受治理的工具访问应位于模型与真实系统之间。模型只能提出调用请求，独立的策略层负责判断：
- 这个 Agent 能否调用该工具；
- 参数是否落在允许范围内；
- 操作是否需要人工审批；
- 是否应该转换成只读或预演模式；
- 调用结果和拒绝原因如何进入审计日志。
下面是一个可以直接运行的本地示例，用来演示“模型提议、策略层裁决”的结构。它不是 DigitalOcean 的实际配置格式，而是可在接入托管 Agent 前用于验证权限模型的最小实现。
将以下内容保存为 tool_policy.py：
from dataclasses import dataclass
from typing import Any
POLICY = {
"read_ticket": {
"roles": {"support", "operator"},
"projects": {"website", "billing"},
},
"restart_service": {
"roles": {"operator"},
"services": {"web-staging", "worker-staging"},
"require_dry_run": True,
},
}
@dataclass
class Decision:
allowed: bool
reason: str
def authorize(role: str, tool: str, arguments: dict[str, Any]) -> Decision:
rule = POLICY.get(tool)
if rule is None:
return Decision(False, "tool is not registered")
if role not in rule["roles"]:
return Decision(False, f"role {role!r} cannot call {tool!r}")
if tool == "read_ticket":
if arguments.get("project") not in rule["projects"]:
return Decision(False, "project is outside the allowed scope")
if tool == "restart_service":
if arguments.get("service") not in rule["services"]:
return Decision(False, "service is outside the allowed scope")
if rule["require_dry_run"] and arguments.get("dry_run") is not True:
return Decision(False, "restart requires dry_run=true")
return Decision(True, "policy checks passed")
def evaluate(request: dict[str, Any]) -> None:
decision = authorize(
role=request["agent_role"],
tool=request["tool"],
arguments=request.get("arguments", {}),
)
print({
"request": request,
"allowed": decision.allowed,
"reason": decision.reason,
})
if __name__ == "__main__":
evaluate({
"agent_role": "support",
"tool": "read_ticket",
"arguments": {"project": "billing", "ticket_id": 1042},
})
evaluate({
"agent_role": "support",
"tool": "restart_service",
"arguments": {"service": "web-production", "dry_run": False},
})
evaluate({
"agent_role": "operator",
"tool": "restart_service",
"arguments": {"service": "web-staging", "dry_run": True},
})
运行：
python3 tool_policy.py
这个例子刻意不执行真正的重启操作。生产环境中，应让策略服务运行在 Agent 无法修改的位置，并在授权通过后由服务端注入凭据、执行调用和记录审计事件。不要把完整策略、管理员令牌或长期密钥交给模型自行保管。
无服务器推理改变容量规划，但不会消除配额问题
Managed Agents 同时提供无服务器 AI 推理。这类架构适合请求量波动明显的 Agent，因为团队不必为了偶发任务长期维护固定推理容量。
应用层仍然需要处理几个现实问题：
- 冷启动与延迟：交互式任务应设置明确的超时和进度反馈；
- 并发与限流：Agent 循环可能在短时间内产生多次模型调用；
- 成本上限：需要限制最大步骤数、上下文长度和重试次数；
- 幂等性：推理超时后重试，不能重复执行已经成功的外部操作；
- 模型降级：主模型不可用时，是切换模型、进入队列，还是直接失败。
一个实用的 Agent 执行预算可以这样定义：
# 概念性配置，并非 DigitalOcean 官方配置格式。
agent_budget:
max_steps: 8
max_tool_calls: 5
inference_timeout_seconds: 30
workflow_timeout_seconds: 180
retry:
max_attempts: 2
backoff_seconds: 3
side_effects:
require_idempotency_key: true
require_approval_for:
- delete_resource
- production_write
真正接入平台时，可以把这些字段映射到应用代码、工作流引擎或平台支持的配置项。关键不是字段名称，而是让一次 Agent 运行拥有可计算、可拒绝的资源边界。
公开预览阶段应怎样落地
公开预览适合验证架构，不宜一开始就承载不可逆的生产操作。建议从只读、低风险且有明确成功标准的场景切入，例如工单摘要、文档检索、测试环境诊断或生成待人工确认的变更建议。
试点前可以检查：
- microVM 是否会在任务之间复用，临时数据何时销毁；
- 工具权限能否按 Agent、用户、环境和参数细分；
- 是否能导出模型请求、工具调用、拒绝记录和执行耗时；
- 密钥如何注入、轮换和撤销，是否会进入日志；
- 推理服务的区域、模型、配额、超时和失败语义是否满足需求；
- 平台升级或接口变化时，是否具备回滚和迁移路径；
- 当策略服务、推理服务或外部工具不可用时，任务是否安全失败。
Managed Agents 的价值在于把隔离运行时、工具治理和弹性推理放到同一个托管层中。评估它时，不要只比较模型调用是否方便，还要观察它是否能让每一次 Agent 行为都具备明确身份、最小权限、资源预算和可追溯记录。只有这些控制真正落地，托管基础设施才会转化为更可靠的 Agent 系统。