当我们谈论 AI Agent 的部署时，大多数讨论集中在模型选择、提示词工程和工作流编排上，却往往忽视了运行时层这个关键维度。Cloudflare Agents 的出现提供了一个独特的视角：它将 Agent 的运行环境从传统的云端服务器迁移到全球边缘网络，并通过 Durable Objects 实现了有状态、长寿且可休眠的执行单元。本文从运行时层面深入剖析 Cloudflare Agents 的工具注册机制、调用协议与无服务器执行模型，并对比其与传统云端部署的根本差异。
基于 Durable Objects 的边缘 Agent 运行时
Cloudflare Agents 的核心架构建立在 Durable Objects 之上。Durable Objects 是 Cloudflare 提供的一种有状态的 Serverless 执行模型，每个对象在全球范围内拥有唯一的身份标识，并且能够保持内存状态同时将数据持久化到本地磁盘。与传统云函数不同，Durable Objects 不是无状态的短生命周期函数，而是一个可以长期运行、拥有独立存储空间的微型虚拟机。在 Cloudflare Agents 中，每一个 Agent 实例都对应一个 Durable Object，这意味着每个 Agent 拥有自己的状态、工具、缓存和后台任务处理能力，而不是仅仅作为数据容器存在。
这种架构的设计哲学与传统云端 Agent 截然不同。在 AWS Lambda 或 Azure Functions 上运行的 Agent 通常需要依赖外部状态管理：Redis 用于缓存会话上下文、数据库存储持久化数据、向量数据库保存记忆。这种模式带来了显著的开销 —— 每次函数触发时都需要从远程存储重新拉取上下文，增加延迟的同时也增加了系统复杂度。而 Cloudflare Agents 将状态与执行单元共置，Agent 的内存中可以直接访问自己的工具和状态数据，消除了外部状态管理的需求。
@callable () 装饰器：工具注册的核心机制
在 Cloudflare Agents 中，工具注册通过 TypeScript 的 @callable() 装饰器实现。当开发者在一个 Agent 类的方法上标记 @callable() 时，该方法会被自动注册到 Agent 的可调用方法注册表中。运行时系统会记录每个方法的名称、元数据和参数模式，从而将该 TypeScript 方法转化为一个可寻址的 RPC 端点。这个过程对开发者是透明的 —— 你只需要写普通的 TypeScript 方法，加上装饰器，它就自动变成了一个可以被外部调用的工具。
@callable() 装饰器支持多种配置选项，其中最常用的是 { stream: true }，用于指示该方法返回流式数据而非单一的 JSON 响应。这个特性对于 AI Agent 场景尤为重要，因为大语言模型的输出往往是流式的，Agent 需要将模型的 token 实时推送客户端。通过装饰器声明流式返回，运行时会自动处理分块传输和序列化逻辑，开发者无需关心底层的 WebSocket 消息切分细节。
从实现角度看，@callable() 的工作原理是：装饰器在类初始化阶段扫描所有带有该标记的方法，构建一个以方法名为键的注册表。当外部请求到达时，运行时根据请求中的方法名查找注册表，找到对应的方法并执行，然后将结果序列化后通过 WebSocket 返回客户端。这种设计将工具的定义与调用解耦，使得工具列表可以动态生成并暴露给大语言模型。
调用协议分层：内部 DO RPC 与外部 WebSocket RPC
Cloudflare Agents 的运行时在调用层面区分了两种截然不同的协议路径，这是理解其架构的关键。第一种是内部 Durable Object RPC：当一个 Worker 调用另一个 Agent，或者同一个 Worker 内的不同 Agent 之间相互调用时，直接使用 Durable Object 的内部 RPC 机制。这种调用不需要 @callable() 装饰器，因为调用双方都在 Cloudflare 的内部网络中，可以通过对象存根直接访问公开方法。这种方式效率极高，延迟通常在毫秒级，且不涉及序列化和网络传输的开销。
第二种是外部 WebSocket RPC：当浏览器、移动应用或其他外部客户端需要调用 Agent 时，必须通过 WebSocket 连接。客户端持有 Agent 的存根代理，调用 agent.stub.someMethod() 时，SDK 会生成一个 WebSocket RPC 消息，包含方法名和参数。Agent 端的运行时监听 WebSocket 消息，将请求路由到对应的 @callable() 方法，执行后通过同一连接返回结果。这种双层架构确保了内部高性能通信与外部灵活访问的并存。
这种分层设计还有一个重要后果：当 Agent 集成大语言模型时，模型看到的 “工具” 与实际执行的代码是分离的。模型收到的是工具的名称、描述和 JSON Schema，这些是元数据层面的东西；实际的执行则通过 @callable() 方法完成。这种分离使得同一套工具可以被不同的模型使用，也便于在不影响模型提示词的情况下修改工具的实现逻辑。
无服务器执行模型：休眠、冷启动与成本
Cloudflare Agents 的无服务器执行模型是其最具差异化的特性之一。Durable Objects 被设计为可以自动休眠的微型虚拟机：当某个 Agent 持续没有活动时，平台会将其冻结，但其持久化存储仍然保留。下一次请求到来时，Agent 会从本地存储快速恢复内存状态，而无需像传统云函数那样从头开始冷启动。这个恢复过程通常比冷启动一个容器加外部状态 hydration 快得多，因为状态就保存在 Agent 所在的同一台边缘节点上。
这种休眠机制直接影响了成本模型。传统云端 Agent 部署为了避免冷启动带来的用户体验问题，往往需要保持预热实例或者使用复杂的预热逻辑，这意味着即使没有实际请求也要持续付费。而 Cloudflare Agents 在空闲时几乎不产生计算成本，只有活跃请求才会计费。对于需要为大量用户提供个性化 Agent 服务的场景 —— 例如每个用户一个 AI 助手、每个游戏房间一个游戏 AI—— 这种 “按需唤醒” 的模式可以显著降低运营成本。你可以运行数百万个 Agent，每个在 Inactive 状态下不产生费用，只有在被调用时才激活。
对比传统云端部署，差异更加明显。在 Kubernetes 或虚拟机上运行的 Agent 需要手动管理扩缩容、滚动更新和故障恢复；在 Lambda 上运行的 Agent 虽然免去了基础设施管理，但每次调用都需要重新初始化，且状态必须外置。Cloudflare Agents 则在两个极端之间找到了平衡点：无需管理服务器，Agent 拥有持久状态，且具备自动扩缩容和故障恢复能力。
工程选型建议
选择 Agent 运行时要考虑几个关键因素。如果你需要为每个用户或每个会话维护独立的状态、需要低延迟的实时交互、且希望将运维复杂度降到最低，Cloudflare Agents 的边缘运行时模式非常适合。其工具注册和调用协议的简洁性也降低了开发门槛，开发者可以专注于业务逻辑而非基础设施。但如果你需要与特定云服务的深度集成、需要运行 GPU 密集型的推理任务、或者已有成熟的 Kubernetes 运维体系，传统云端部署可能更为务实。
理解运行时层的差异是做出正确架构决策的基础。当前的 AI Agent 开发社区对模型能力和工作流编排投入了大量关注，但对执行环境的优化往往被低估。Cloudflare Agents 代表的边缘有状态 Serverless 范式，为构建大规模个性化 AI Agent 提供了一条值得探索的路径。