当AI代理开始批量下单，云工作流引擎如何扛住每秒300次冲击

凌晨两点，你的AI代理还在帮用户比价、填表、等审批。突然，500个代理同时启动，每个要跑十几个步骤——你的后台扛得住吗？

Cloudflare的工程师最近就遇到了这个问题。他们发现，原本为人类点击设计的工作流引擎，正在被机器以百倍速度调用。这不是简单的流量增长，而是整个使用场景的质变。

从"人等系统"到"系统等机器"

Cloudflare Workflows最初的设计假设很朴素：用户注册、下单、提交表单——人的手速能有多快？一个用户同时跑一个工作流实例，绰绰有余。

但过去两年，数据讲了一个完全不同的故事。

人类触发的工作流在减少，代理触发的工作流在暴增。这些AI代理不是瞬时完成的工具调用，而是可能持续运行数小时甚至数天的"数字员工"。它们需要记住进度、等待外部事件、在失败时从断点恢复——这正是工作流引擎的强项。

更关键的是架构层面的变化：代理本身开始用工作流来实现核心循环。一个代理会话可能同时启动几十个嵌套工作流，成百上千个代理并发运行时，实例创建速度从"每秒几次"跳到了"每秒几千次"。

Cloudflare的Agents SDK集成加速了这一趋势。代理可以实时获取工作流进度，形成双向反馈。随着Project Think的发布，这个速度只会更快。

数字背后的架构重构

面对这种压力，Cloudflare公布了新的性能上限：

• 并发实例数：4,500 → 50,000（11倍提升）
• 每秒创建实例：100 → 300（3倍提升）
• 单工作流队列深度：100万 → 200万（2倍提升）

这些数字不是简单的扩容，而是控制平面的彻底重写。

V1架构中，单个Durable Object（持久化对象）充当整个账户的中央注册表和协调器。这在人类速度下没问题，但面对机器速度时成了瓶颈。

V2拆成了两个新组件，实现水平扩展。所有客户在零停机的情况下完成了迁移——这意味着Cloudflare在重构核心架构的同时，还要保证线上流量不受影响。

为什么"持久化"成了代理时代的刚需

Workflows的核心设计哲学在原文中写得很清楚：每个步骤独立可重试、可暂停等人机交互、故障不丢进度。这三点在代理场景下变得至关重要。

代理不像传统API调用那样"请求-响应"即结束。它们可能在第5步等待用户确认邮件，在第12步等外部系统回调，在第20步因为下游服务超时自动重试。如果中间服务器重启，人类可以刷新页面重新登录，代理却需要底层引擎帮它"记住"刚才做到哪了。

Cloudflare把这叫作"durable harnesses"（持久化 harness）——工作流成了代理的"生命维持系统"，确保这些自主运行的程序不会中途"猝死"或"失忆"。

一个典型的工作流代码结构展示了这种设计：

步骤1：调用API获取数据
步骤2：等待"approval"类型事件，最长等24小时
步骤3：处理并存储结果

第二步的等待是代理时代的典型模式。代理可以去做别的事，工作流引擎帮它守着这个"坑位"，事件到来时自动唤醒继续执行。

这对开发者意味着什么

性能提升只是表象，更深层的信号是：云厂商正在重新划定"基础设施"的边界。

传统的无服务器函数（Serverless Functions）假设执行是短暂的、无状态的。但代理需要状态、需要持久化、需要跨时间的协调能力。这推动Cloudflare把工作流引擎从"辅助工具"升级为"代理的基础设施层"。

对构建AI应用的开发者来说，选择执行环境时多了一个关键考量：你的代理能"活"多久？能记住多少？能同时养多少个？

Cloudflare的答案很明确：5万个并发实例，每个可以等上数天，每秒还能新增300个。这个规格已经足以支撑相当规模的自动化代理集群。

但这也引出一个开放的问题：当代理开始以机器速度批量创建工作流，传统的计费模式、调试工具、监控体系是否还跟得上？Cloudflare没有透露迁移后的单位成本变化，但架构层面的复杂度显然在上升。

如果你的AI代理明天需要同时启动一万个长时任务，你现在用的基础设施，真的能接住吗？