Cloudflare Matt Carey 为每个 AI Agent 配工作区与浏览器

Agent 有了自己的"电脑"

在最近一场 WorkOS init() 活动中，Cloudflare 的 Matt Carey 展示了一个颇具启发性的 AI Agent 演示：他把一个基于 Pi 的 agent 放进 Durable Object 里持久运行，然后给它配上了有状态的工作空间，以及一个叫 Kitesurf 的浏览器来实际操作网页。

这个演示的核心信息很简单，但意义不小：Agent 不再只是"回答问题"，而是开始拥有属于自己的执行环境——一块可以存东西的工作区，和一双可以点页面的"手"。

拆解这个演示的三个关键组件

Durable Object：Agent 的持久身份

Cloudflare 的 Durable Object 是一个有状态的计算单元，天然适合承载需要"记住自己"的 agent。传统 serverless 函数每次调用都是无状态的，agent 想记住上下文得靠外部存储来回搬运。而 Durable Object 让 agent 本身就是一个长期存在的实体，状态跟着它走。

Carey 选择把 Pi agent 放进去，意味着这个 agent 可以跨越多次交互保持自己的记忆和执行历史，而不是每次从零开始。

Serverless 的无状态特性是理解 Durable Object 价值的背景。传统 FaaS（如 AWS Lambda、Cloudflare Workers 的普通请求处理）每次调用都在一个全新的隔离环境中运行，函数执行完毕后内存即被回收，任何需要跨调用保留的数据都必须显式写入外部存储（如数据库、KV、对象存储），下次调用时再读回。这对无状态 API 很高效，但对需要连续记忆的 agent 就成了负担：每一轮对话、每一步任务都要序列化和反序列化整个上下文，还要处理并发写入冲突。

Durable Object 走的是另一条路：它是一个有唯一 ID 的、单线程执行的有状态实例，状态可以常驻内存并自动持久化到存储后端，同一个 ID 的请求会被路由到同一个实例上串行处理。这天然解决了 agent 的"身份连续性"和"并发一致性"问题——agent 不再是一个每次从零启动的函数，而是一个可以持续存在、按顺序处理消息的实体。理解这一点，就能明白为什么它被视为承载 agent 的理想底座。

有状态的工作空间：Agent 的"硬盘"

给 agent 一个 workspace，本质上是让它拥有可读写的持久存储。这不是简单的 memory buffer，而是类似文件系统的结构——agent 可以往里写文件、组织数据、在下一次运行时读取之前留下的成果。

这一点对实际任务至关重要。一个 agent 如果能记住"我上次已经把数据清洗到这一步了"，它就能继续往下推进，而不是每次都要重复前面的步骤。

Agent 的上下文窗口与持久存储是两回事，这是很多初次接触 agent 开发的人容易混淆的地方。上下文窗口（context window）是模型单次推理能看到的 token 范围，本质上是易失的、有上限的、每次调用都要重新填充；而工作空间是外部持久存储，容量远大于上下文窗口，且不随调用结束而消失。

两者的关系类似 CPU 缓存与磁盘：模型推理时只把工作空间里最相关的片段加载进上下文，其余成果留在"硬盘"上。这正是"记忆"机制的核心——agent 通过读写文件系统来组织长期状态，用检索或摘要的方式把需要的信息临时搬进上下文。没有持久工作空间的 agent，只能把一切塞进有限的上下文，一旦超出就只能截断或遗忘，难以承接长周期的多步骤任务。

Kitesurf 浏览器：Agent 的"眼睛和手"

演示中最有画面感的部分，是 agent 通过 Kitesurf 浏览器去驱动网页。这代表 agent 可以真正操作外部系统——打开页面、读取内容、执行点击和输入，而不只是生成一段文本让人类去照做。

浏览器操作能力把 agent 从"建议者"变成了"执行者"。

浏览器自动化是 agent 连接真实世界的通用接口。相比为每个服务单独写 API 集成，浏览器操作的优势在于通用性：只要有网页，agent 就能通过打开页面、解析 DOM、点击按钮、填写表单来完成操作，无需目标系统提供官方 API。这与近年来兴起的"computer use"类能力一脉相承，只是把操作范围聚焦在网页这一最普遍的人机界面上。

不过浏览器自动化也带来新的工程挑战：页面结构会变化、操作可能触发异步加载、需要处理登录态与反爬机制，且每次点击都有真实副作用，容错成本高。因此在生产环境中，浏览器能力通常与沙箱隔离、操作回放和人工兜底机制配合使用。Kitesurf 在这套组合里扮演的角色，就是把 agent 从"生成文本让人去执行"推进到"自己动手把事做完"。

为什么这三件套组合起来才成立

单独看每个组件都不新鲜，但组合起来指向一个清晰的模式：持久身份 + 持久存储 + 真实执行能力 = 一个可以独立干活的 agent。

缺少 Durable Object，agent 每次醒来都是失忆的；缺少 workspace，它做完的事留不下来；缺少浏览器，它只能纸上谈兵。三者叠加，才让 agent 有可能承接需要多步骤、跨会话、与真实系统交互的任务。

从工程角度看，这个方向也解释了为什么 Cloudflare 这类边缘计算平台会在 agent 基础设施上投入——把 agent 跑在离用户和数据更近的地方，同时用有状态计算解决它的"记忆"问题，是很自然的组合。

对开发者意味着什么

如果你正在构建 agent 应用，这个演示给出的信号很直接：与其在应用层反复拼凑状态管理和工具调用，不如把 agent 本身当成一个有状态的服务来部署。

Durable Object 提供了这种部署形态，workspace 和浏览器则提供了能力接口。这种分层方式，可能比把所有逻辑塞进一个 prompt 循环更可维护，也更接近真实生产环境的需求。

Carey 的这次演示规模不大，但把 agent 基础设施的几个关键拼图摆到了一起，值得关注后续 Cloudflare 在这个方向上的产品化进展。