当我们谈论 AI 推理时，本地设备推理与云端集中式推理是两个主流叙事。Cloudflare 作为全球 CDN 与边缘计算厂商，正在用一种截然不同的架构 —— 边缘推理层 —— 切入 AI 代理（Agent）赛道。与传统云厂商不同，Cloudflare 将推理能力下沉到全球 300 余个数据中心，让代理可以在离用户最近的地方完成决策、工具调用与状态持久化。这种 “云边协同” 模式为代理工作流带来了低延迟、高可用与按需付费的可能性。
边缘推理层的架构核心
Cloudflare 的边缘推理能力主要依托两条技术线路：Workers AI 作为无服务器推理引擎，AI Gateway 作为模型接入与流量管控层。Workers AI 并非简单的模型托管，它采用了无服务器架构 —— 开发者无需预置 GPU 容量，按调用次数与计算时长付费。这种模式与传统云厂商的 “预留实例” 形成鲜明对比：峰值流量时自动扩容，空闲时零成本闲置。
在推理模型覆盖方面，Workers AI 目前支持 Llama 3.1 系列、DeepSeek R1 蒸馏版本、Nous Hermes 2 Pro 等主流开源模型，并通过 JSON 模式（response_format）支持结构化输出。JSON 模式兼容 OpenAI 的 response_format 实现，开发者可以直接复用现有 SDK，只需指定 json_schema 即可获得模型返回的验证后的 JSON 对象。这对于需要将自然语言转换为 API 调用的代理场景尤为关键 —— 代理不再需要解析自由文本再手动构造请求，而是直接得到结构化指令。
AI Gateway 则承担了模型目录管理、流量监控与成本控制职能。它提供了模型发现、调用日志与用量统计的统一入口，开发者可以在 Gateway 中配置模型访问策略、实施速率限制，并通过统一的观测面板追踪各模型的响应延迟与错误率。Gateway 还支持流式输出场景下的日志采集，这意味着代理在执行多步推理时，每一步的耗时与 token 消耗都可以被精确计量。
agents-sdk 与代理工作流编排
如果说 Workers AI 解决了 “在哪里推理” 的问题，那么 agents-sdk 则解决了 “如何编排代理” 的问题。agents-sdk 是 Cloudflare 在 2025 年初发布的 JavaScript 框架，专门用于构建可在边缘部署的 AI 代理。它的设计理念是将代理的复杂性抽象为声明式接口，开发者通过继承 Agent 基类并实现 onRequest 方法即可定义代理行为。
代理与传统的 workflow 自动化有本质区别：workflow 是线性确定的，而代理是非线性、非确定性的。以旅行预订为例，传统自动化只能按固定顺序调用航班 API、酒店 API 和餐厅 API，一旦某个 API 返回不可用状态，整个流程即告失败。代理则可以在接收到 “航班售罄” 的响应后，自主决策重新规划行程 —— 调整日期或更换目的地，然后继续执行后续步骤。这种自适应决策能力正是代理区别于自动化脚本的核心特征。
agents-sdk 提供了 AIChatAgent 类来简化聊天代理的构建。该类封装了消息处理、工具调用与流式响应的完整流程，开发者只需关注业务逻辑即可。在底层，AIChatAgent 利用 Durable Objects 提供的状态持久化能力，确保代理可以在多次请求之间保持会话上下文。Durable Objects 是 Cloudflare 的无服务器状态抽象，每个对象实例都是一个独立的、持久的微服务，可以水平扩展到数千万级别。这意味着即使面对海量并发代理实例，平台也能自动完成负载均衡与状态分片。
代理的另一个核心能力是工具调用（Tool Calling）。Workers AI 的 tool calling 功能允许模型在推理过程中主动调用外部 API—— 这不仅仅是输出文本，而是真正触发操作。以订餐代理为例，模型可以识别用户意图后直接调用餐厅预订 API，返回预订结果后再继续与用户对话。整个过程不需要应用层代码解析模型输出，工具定义与调用由框架内部完成。
状态管理与持久化策略
代理工作流中的状态管理是一个容易被忽视但至关重要的工程挑战。与无状态 API 不同，代理需要跨多个推理步骤维护对话上下文、中间决策结果与外部系统交互记录。Cloudflare 通过两种机制解决这一问题：Durable Objects 的内存状态与 SQLite 持久化存储。
每个代理实例在 Durable Objects 中运行时，其状态可以通过 this.setState API 直接存储。该状态会被自动持久化到底层存储，并在实例重启后恢复。对于需要长期保留的数据，agents-sdk 还提供了原生 SQLite API，开发者可以在代理内部直接创建表、写入查询结果，无需额外部署数据库。这意味着代理可以自主管理其工作数据 —— 比如记录用户偏好、缓存 API 响应或存储多轮对话的摘要。
在状态同步方面，agents-sdk 支持前端状态同步接口。通过 useAgent hook，React 应用可以与代理建立 WebSocket 双向通道，实时接收代理状态更新并推送用户输入。这种双向同步机制使得构建实时交互代理成为可能 —— 用户无需刷新页面即可看到代理的思考过程与工具调用结果。
对于需要人工介入的场景，agents-sdk 内置了 human-in-the-loop 支持。代理可以在执行关键操作前暂停，等待用户确认后再继续。这一功能通过工具调用的确认机制实现：当模型输出的工具调用需要人工授权时，框架会将控制权交还给前端，用户确认后代理继续执行后续步骤。
工程落地的关键参数与监控建议
将代理部署到 Cloudflare 边缘环境时，有几个关键参数需要关注。首先是 maxSteps—— 它限制了代理在单次请求中执行的最大推理步数。默认值通常为 10 步，但在实际应用中需要根据代理复杂度调整：如果代理需要调用多个外部 API 或执行多轮检索，建议将此值设置为 20 至 30，以保证代理有足够的 “思考空间”；但也要警惕设置过高导致代理陷入循环调用。
其次是上下文窗口（context window）管理。Workers AI 的各模型有不同的上下文长度限制，Llama 3.1 70B 版本的上下文窗口目前为 128k tokens。代理在处理长对话或复杂文档时，需要注意不要超出模型限制。超出会导致模型拒绝处理或截断输入。实践中建议在代理层实现上下文压缩策略 —— 当对话历史超过阈值时，利用模型自身对早期对话进行摘要，保留关键信息的同时减少 token 消耗。
在成本监控方面，AI Gateway 提供了细粒度的用量统计。每个模型的调用次数、token 消耗与响应延迟都有独立指标。建议为关键业务代理设置告警阈值：当单模型日调用量超过预期容量的 80% 时触发通知，避免因用量突增导致服务降级。此外，Gateway 的速率限制功能可以防止恶意调用 —— 为公共代理接口设置每秒请求数上限，是保护后端推理资源的必要措施。
代理的可用性监控需要关注两个层面：推理可用性与外部工具可用性。Workers AI 本身提供了 SLA 保证，但外部 API（如第三方预订服务、数据检索接口）可能存在超时或熔断风险。建议在代理层实现工具调用的超时控制与重试策略 —— 单次工具调用超时阈值建议设置为 5 至 10 秒，重试次数不超过 3 次，以避免因外部依赖导致代理请求堆积。
对于需要长时间运行的代理任务（如批量数据处理、定时报告生成），Cloudflare Workflows 提供了另一种编排选择。Workflows 与 Durable Objects 互补 —— 前者适合有向无环图（DAG）式的任务流程，后者适合需要维护长期状态的交互式代理。两者可以结合使用：Workflows 负责调度，Durable Objects 负责状态保持。
Cloudflare 的边缘推理层为 AI 代理提供了一种独特的部署范式 —— 推理发生在离用户最近的边缘节点，状态持久化由 Durable Objects 抽象，应用逻辑通过 agents-sdk 声明式编写。这种架构在需要低延迟、多租户与成本敏感的代理场景中具有显著优势。当然，它并非万能：对于需要大规模 GPU 训练或复杂向量检索的场景，仍需借助传统云服务。将边缘推理视为云边协同的一环，而非替代方案，是更为务实的工程态度。
资料来源：本文核心信息来源于 Cloudflare 官方博客《Making Cloudflare the best platform for building AI Agents》（2025 年 2 月）及 Workers AI 产品文档。