DigitalOcean 已将 Managed Agents 推向公开预览。它瞄准的不是又一个聊天界面，而是 AI Agent 上线时更棘手的一层基础设施：把 Agent 放进隔离的 microVM 运行时，约束它能调用的工具，并通过 Serverless AI 推理执行模型请求。
对于正在把原型升级为生产服务的团队，这三项能力分别对应三个现实问题：代码在哪里执行、Agent 可以碰什么资源，以及推理容量由谁管理。
托管的重点不只是模型，而是执行边界
普通聊天机器人通常接收输入、请求模型并返回文本。Agent 则可能继续执行 HTTP 请求、查询数据库、写入对象存储，甚至触发部署流程。一旦模型输出能够转化为实际操作，基础设施就必须回答几个问题：
- 每次任务是否拥有独立的执行环境？
- 某个 Agent 能调用哪些工具，参数范围是什么？
- 密钥是否直接暴露给模型生成的代码？
- 推理任务突增时，是否需要预先维护 GPU 或推理服务？
- 一次任务结束后，运行时中还会留下什么状态？
Managed Agents 公开预览中强调的 microVM、受治理工具访问和 Serverless AI 推理，正好对应这些边界。
microVM 隔离尤其适合执行模型生成代码、处理用户文件或安装临时依赖的场景。与多个任务共享同一个长期运行进程相比，每个任务拥有更明确的运行边界，可以降低任务间状态泄漏和依赖污染的风险。不过，隔离运行时并不等于绝对安全：出站网络、凭据注入、文件大小、执行时间和工具权限仍然需要单独限制。
工具治理比 Prompt 约束更可靠
Prompt 可以告诉 Agent“不要访问生产数据库”，但这不是权限控制。模型可能误解要求，外部输入也可能包含提示注入内容。真正的控制点应该位于工具执行层：即使模型请求危险操作，网关也必须拒绝。
一套可落地的工具策略通常至少包含：
- 工具白名单：只暴露业务所需能力，而不是提供任意 Shell。
- 参数校验：限制 URL 域名、数据库表、对象存储前缀和命令参数。
- 短期凭据：由工具层取得临时凭据，不把长期密钥放进 Prompt。
- 审批分级：读取操作可以自动执行，付款、删除和部署需要人工确认。
- 审计记录：保存 Agent、用户、工具、参数摘要、结果和耗时。
关键原则是：模型负责提出意图，策略层负责决定意图能否变成动作。不要让模型同时充当申请者和审批者。
可以这样实践：先在本地实现一个最小工具网关
下面的示例不是 DigitalOcean Managed Agents 的官方 API 或配置格式，而是一个可以直接运行的最小策略网关，用来演示如何在接入托管 Agent 前整理工具边界。
先创建 policy.json：
{
"tools": {
"fetch_url": {
"allowed_hosts": ["example.com"],
"max_response_bytes": 4096,
"timeout_seconds": 5
}
}
}
再创建 tool_gateway.py：
import json
import sys
import urllib.request
from urllib.parse import urlparse
def load_policy(path="policy.json"):
with open(path, "r", encoding="utf-8") as file:
return json.load(file)
def fetch_url(url, policy):
rule = policy["tools"]["fetch_url"]
parsed = urlparse(url)
if parsed.scheme != "https":
raise PermissionError("Only HTTPS requests are allowed")
if parsed.hostname not in rule["allowed_hosts"]:
raise PermissionError(f"Host is not allowed: {parsed.hostname}")
request = urllib.request.Request(
url,
headers={"User-Agent": "governed-agent-tool/1.0"}
)
limit = rule["max_response_bytes"]
timeout = rule["timeout_seconds"]
with urllib.request.urlopen(request, timeout=timeout) as response:
data = response.read(limit + 1)
if len(data) > limit:
raise ValueError("Response exceeded the configured size limit")
return data.decode("utf-8", errors="replace")
def main():
if len(sys.argv) != 2:
raise SystemExit("Usage: python tool_gateway.py https://example.com")
policy = load_policy()
result = fetch_url(sys.argv[1], policy)
print(result)
if __name__ == "__main__":
main()
运行允许的请求：
python tool_gateway.py https://example.com
尝试访问其他域名时，请求会在真正发出之前被拒绝：
python tool_gateway.py https://example.org
迁移到托管 Agent 时，可以把这个模式映射到平台提供的工具治理能力：Agent 只看到 fetch_url 这样的窄接口，域名白名单、超时和响应大小限制则由执行层掌握。生产环境还应增加 DNS 重绑定防护、重定向检查、私网地址拦截、速率限制以及完整审计日志，避免工具成为 SSRF 或数据外泄通道。
Serverless 推理改变的是运维责任，不是容量规律
Serverless AI 推理可以减少自行部署和维护模型服务的工作量，让团队更专注于 Agent 流程、工具和业务逻辑。它也适合流量不连续、需要快速试验不同工作负载的应用。
但“Serverless”不代表可以忽略系统设计。接入公开预览服务时，仍应验证：
- 首次请求和长时间空闲后的延迟是否满足要求；
- 并发、请求大小、执行时长和速率限制是否适配业务峰值；
- 模型调用失败后是否能够安全重试，避免工具被重复执行；
- 输入、输出和工具日志会保存多久；
- 成本是否按照请求量、Token、执行时间或其他维度变化；
- 所需模型、区域和数据治理能力是否已经可用。
特别要注意重试语义。推理请求可以重试，但“创建工单”“发送邮件”或“执行付款”等工具调用必须带幂等键，否则一次超时可能产生两次真实操作。
适合从低风险、可观察的 Agent 开始
公开预览阶段，更稳妥的采用方式不是立即让 Agent 管理生产环境，而是选择边界清晰的工作流，例如文档检索、只读诊断、内部知识问答或生成待审核的变更建议。
上线前可以使用这份检查表：
- [ ] 每个工具都采用白名单，而不是默认开放；
- [ ] 模型无法直接读取长期云密钥；
- [ ] 写入、删除、付款和部署操作具备审批或幂等保护；
- [ ] microVM 内的文件和状态按预期销毁；
- [ ] 出站网络、运行时间、内存和响应大小均有限制；
- [ ] 能按用户、Agent 和工具追踪审计记录；
- [ ] 已测试模型失败、工具超时和任务中断；
- [ ] 已确认公开预览的配额、区域、支持范围和变更风险。
DigitalOcean Managed Agents 的价值，在于把 Agent 的执行环境、工具控制和推理基础设施放进同一个托管层。真正决定它能否安全进入生产的，仍然是清晰的权限边界、可审计的工具调用，以及面对失败时不会重复制造副作用的工作流设计。