返回 2026-05-15
🤖 AI / ML

托管智能体是新的Lambda函数Managed agents are the new Lambda

martinalderson.com·2026-05-14

文章指出,虽然云托管的智能体(Managed Agents)功能强大,但过早锁定特定平台(如Frontier Labs)存在战略风险。作者警告开发者避免供应商锁定,并建议采用开放标准或可迁移架构来构建AI驱动的工作流。替代方案包括使用跨平台的无服务器计算框架或自托管轻量级代理系统。核心论点是:在AI基础设施快速演进的当下,灵活性比短期便利更重要。

Martin Alderson

托管代理(云端代理)是前沿实验室即将推出的重点产品,它们确实令人惊叹。它们将成为本轮技术浪潮中的 AWS Lambda——功能强大、粘性极强,一旦深入使用,迁移将极其困难。

尽管确切定义尚存争议,但在我看来,托管代理是指在云端而非本地机器上运行的代理框架(如 Claude Code)。

这带来了几个主要优势。最明显的是,你无需在本地运行机器——它可以全天候在后台持续工作。另一个优势是,由于运行在云端,它能及时感知变更并作出响应。例如,代理可以处理新邮件或 Webhook 触发的事件,并据此执行相应操作(虽然本地也能实现,但在服务器端运行更为便捷)。

另一个重要优势是安全性——这也是“托管”代理的核心价值所在。与 Heroku、AWS ECS/App Runner/Lambda 以及 Azure App Service/Functions 等 PaaS 产品类似,服务提供商不仅为你管理底层物理基础设施,还负责操作系统的打补丁及相关服务器软件的维护。

沙箱机制也是其带来的另一项相关好处。托管代理仅能访问你明确授权的内容,避免了代理误触不应接触的文件的风险。

如果你已经在服务器上以 Docker 方式运行 Claude Code/Codex/OpenCode,那你实际上已经构建了一个类似的系统。前沿实验室只是将这一模式产品化了。

供应商锁定问题确实存在。

Anthropic 最近大力推广其托管代理产品,这完全合理——云托管代理确实功能强大、令人惊艳。但我仍强烈建议保持谨慎,至少在现阶段应避免过度依赖单一供应商。

从根本上说,更换代理框架并不复杂。尽管不同代理在工作方式和细节上存在差异,但从 Claude Code 切换到 Codex(或 OpenCode、Pi 等其他代理框架)的过程相当简单。其核心模式一致:通过提示词、上下文和工具运行代理框架,捕获输出和日志。所有代理框架都提供相同的底层能力。

能够灵活切换代理框架和模型尤为重要。定价固然关键,但能否使用不同实验室的新模型同样重要。市场竞争异常激烈,且未见缓和迹象。

一旦开始使用前沿实验室的托管代理产品,情况就会变得复杂得多。你的数据和流程已深度嵌入其云平台。尽管 Anthropic 多次强调数据归属权属于用户且支持导出,但根据我多年应对供应商锁定的经验,这种“可迁移”的定义往往在执行中逐渐模糊,最终导致迁移难度不断攀升。

正如许多人在 AWS 上发现的那样,若要从一个超大规模云平台迁移 Docker 容器负载,过程相对容易。但迁移 AWS Lambda 函数则要困难得多——我曾见过不少组织在热潮退去后意识到 Lambda 并非理想选择时,耗费数月时间艰难拆解其中的代码逻辑和隐含假设。

Claude 使用计划变更

昨天,Anthropic 宣布对其定价模型进行了重大调整,这再次凸显了这一点。如果你以非交互方式运行 Claude Code(几乎所有云端托管代理的使用场景都包括在内,还有很多其他情况[2]),那么这些使用将不再符合你的订阅代币额度,而是会消耗新的信用额度。一旦这个额度耗尽,后续的 API 调用费用将非常昂贵。可以说,如果你之前大量使用了“非交互式”的 Claude Code,那么这次改动将使你的成本增加 5-20 倍。

显然,Anthropic 有权这样做——而且(我认为)这更多反映了他们的算力短缺,而非其他原因。但这确实为 OpenAI 创造了机会,让用户转向 Codex。目前,OpenAI 已经明确表示,你可以根据自己的计划额度,以任何方式、在任何工具中使用它。

未来,围绕 Codex(过去几个月它已获得显著增长势头)以及其他提供商的讨论将会增多——开发者通常对这类工具的定价极为敏感,尤其是个人“副项目”,而这些项目往往会在数月甚至数年后影响他们所在公司的重大采购决策[3]。

解决方案

现在很容易说不要用前沿实验室的托管代理产品,但真正的解决方案是什么呢?

我认为在你的组织中主要有两种解决方式。

首先,搭建自己的托管基础设施。这对开发者和技术相关团队来说是不错的选择——他们有足够的专业知识来实现。本质上,就是每天运行一个 Docker 容器。使用类似 OpenCode 这样的框架,可以让你在几分钟内切换任意模型提供商。

其次,市场上涌现了大量允许你使用任何模型或提供商来运行托管代理的公司。我尚未详细评估它们,因为市场变化太快,难以对质量做出切实评价。但已知的提供商包括 Cloudflare Agents、Vercel,以及各大云厂商的方案(AWS AgentCore、Azure AI Foundry 和 GCP Vertex AI Agent Engine)。

我个人观点是:在局势明朗化之前,建议坚持自建托管。这并不难实现,还能让你将代理部署在当前基础设施内部,同时培养组织在代理原语方面的能力。此时外包这一知识会导致严重的组织知识断层。不过,要留意平台未来可能推出越来越难以复制的功能,届时情况可能会发生变化。

该计划唯一潜在的变数是:我有强烈的直觉认为,前沿实验室将开始推出仅在其托管代理平台上可用的模型和全新功能。这可能标志着必须使用托管代理的趋势开始抬头——但也不一定。

  • Lambda 是一种“无服务器”运行应用的方式,理论上能极大简化部署和扩展流程,应用托管的基础设施层被进一步抽象。然而,这也意味着你必须深入依赖 AWS 特定的代码、技术和模式,一旦使用,很难迁移回去。↩︎
  • 此外,尽管这实际上属于交互式使用,但它也包含了 Claude Code 的其他前端,比如优秀的 Conductor Mac 应用。↩︎
  • 这就是为什么我真心希望 Anthropic 能在某个时候重新考虑这一政策。↩︎
  • 需要完整排版与评论请前往来源站点阅读。