从基础设施分层角度系统梳理 Agent Infra 的关键组成,包括计算、身份与权限、上下文与记忆、执行环境与运行时、调度与协作、安全治理,以及支付和 Agentic Web 的平台实现方向。
为什么 Agent 需要新的基础设施
过去二十年的主流应用基础设施,服务的是有限应用实例面向海量用户的模型。系统的核心任务是扩容、负载均衡、微服务拆分、部署回收和状态管理。无论用户规模增长到什么程度,平台维护的应用集合通常仍然是有限的。
Agent 改变了这个前提。每个 Agent 会话都可能对应独立目标、独立上下文、独立工具链和独立执行路径。执行路径由 LLM 动态决定,运行过程会跨越工具调用、外部系统访问、长周期状态延续和人机协同。平台面对的不再只是更多请求,还包括数量级更高的执行环境、更多自治任务和更复杂的权限边界。
这也是 Agent Infra 形成独立层次的原因。它讨论的重点不在预训练、后训练或推理集群,而在 Agent 的运行时、执行环境、上下文管理、调度协作、安全治理和支付访问机制。
从 Cloudflare 的判断来看,当前云基础设施的主要矛盾已经发生变化。系统承载的不只是网页、移动应用和 API 服务,还要承载海量短生命周期、高自治度、强工具依赖的 Agent 任务。Addy Osmani 从企业落地角度补充了另一层现实:今天很多生产级 Agent 的主要问题,已经不在模型效果,而在身份、可审计性、上下文继承、长时任务持续性和治理能力。
Agent Infra 的最小分层模型
计算层:isolates、容器与持久执行
Agent 跑在什么计算原语上,如何兼顾轻量启动、隔离性和长任务支撑。
面向 Agent 的平台不能只依赖容器,也不能只依赖轻量运行时,而是需要分层计算能力。
对很多短任务来说,isolates 更合适。它们启动快、内存占用低、可按请求创建和销毁,适合高并发、短生命周期、工具调用密集的任务。Cloudflare 把 Workers 和 Dynamic Workers 放在这一层,核心原因就在这里。
对 coding agents、浏览器自动化和需要完整操作系统能力的任务来说,容器仍然是必要执行单元。它们提供文件系统、Git、Shell、任意二进制程序和更完整的环境控制能力。Cloudflare 的 Sandboxes 正是在这个层面补能力。
企业级 Agent 能力并不止于会话不断开,而是任务能够跨掉线、跨重启、跨部署、跨凭证轮换持续推进。计算层因此还要承担持久执行职责,包括:
- 状态恢复
- 检查点
- 长任务续跑
- 人机审批等待
- 多天甚至多周任务的连续性
这意味着计算层需要同时支持两类工作负载:
- 高频、轻量、短生命周期任务
- 长周期、可恢复、具备状态延续的任务
这一层的产品例子已经很明确:
- Workers 与 Dynamic Workers 提供轻量执行能力
- Sandboxes 提供完整执行环境
- Workflows 提供持久工作流承载长时任务
- Artifacts 提供与 Agent 工作流匹配的版本化存储

身份与权限层:Agent identity 必须下沉到平台层
Agent 用什么身份访问资源,如何实现最小权限、撤销和审计。
很多生产级 Agent 还在借用 shared credentials、service account 或人工 OAuth token 工作。这样做能跑通流程,但会累积治理债务。平台很难回答几个基础问题:
- 是哪个 Agent 调用了哪个工具
- 它访问了哪些数据
- 它使用了哪类凭证
- 它是否越过了授权边界
一旦 Agent 进入企业环境,提示词里的约束不再等同于策略。身份和授权必须下沉到平台层,由网络、平台和策略系统共同执行。
Cloudflare 提供了这层的产品化案例:
- Mesh 让 Agent 能在私有网络中以受控方式访问数据库和内部 API
- Managed OAuth 把 Agent 代理访问内部应用的能力做成标准能力
- resource-scoped permissions 和更细粒度 token 能力,用于实现最小权限
- MCP 治理参考架构 把协议接入、认证和监控放到统一控制平面
这一层解决的是 Agent 可追责、可撤销、可审计的问题。没有这层,自治任务越多,平台风险也越高。
上下文与记忆层:通用上下文决定 Agent 的上限
Agent 如何获取跨系统上下文,如何保持长期任务连续性。
今天很多 Agent 的上下文仍然是局部的、脆弱的、依赖应用窗口的。浏览器里的 Agent 只能看到当前页面,桌面里的 Agent 只能看到显式打开的文件,系统之间的业务上下文通常仍然是割裂的。
如果 Agent 无法同时获得 CRM、ERP、数据仓库、知识库、邮件、工单、会议记录和项目状态中的相关信息,那么复杂任务就只能退化成狭窄自动化。
上下文层应该由结构化上下文存储和共享工作空间组成。前者管理对话历史、任务状态、规划中间件和元信息,后者管理文件、代码、数据和协作文档。
为了让长任务可持续,这一层还需要承担记忆和交接职责:
- 任务中间状态可回读
- 长期偏好可继承
- 跨执行实例可交接
- 会话结束后上下文仍可保留
这一层的产品例子包括:
- Agent Memory 提供托管记忆能力
- AI Search 提供 Agent 侧的检索原语
- Artifacts 提供可版本化的工作空间
- Cloudflare Email Service 与 Browser Run 提供多通道输入输出能力,用于补足任务上下文来源
执行环境与运行时层:环境隔离、Box、分支能力与 Git Worktree
Agent 在什么环境中执行 Action,如何控制副作用与环境劣化。
今天很多 Agent 采用顺序执行模型:一步、等待结果、再一步。这个模型在复杂探索任务里会同时遇到三个问题:
- 行动之间依赖强,难以并行
- 任一步失败会阻塞整体路径
- 带副作用的 Action 会持续污染环境
环境劣化是这一层最容易被低估的问题。只要 Action 具备强副作用,复杂任务执行越久,环境就越容易偏离可预测状态。Coding Agent 在真实代码仓库里尤其明显,临时代码、日志、生成文件、相互覆盖的改动都会让工作区越来越难以恢复。
Git Worktree 已经是一个局部可行解。它通过独立工作区为不同 Agent 或子任务提供隔离环境,最后只回收 diff 或 Pull Request。这个方向说明,执行环境必须具备两个能力:
- 可隔离
- 可丢弃
Skill + Env = Box,可以作为这一层的一种运行时设计方向。它试图把语义化 Skill 与可复现执行环境绑定,形成轻量、可销毁、可组合的执行单元。这个抽象还不是行业定论,但它点出了一个关键目标:Action 不应直接暴露全部底层环境细节,平台应该把复杂副作用限制在受控边界里。
这一层还需要分支能力。复杂任务需要多路径探索、试错和回退。分支能力在 Agent Infra 里应该成为一等系统能力,用来支持同一目标下的多条执行路径并行推进,同时隔离副作用。
这一层的实现方向包括:
- Git Worktree 这一类独立工作区模式
- Sandboxes 这一类隔离执行环境
- Box 这一类语义化执行单元抽象
- 基于 Durable Objects 或数据库实现的分支元信息管理
调度与协作层:调度器、消息总线与持久工作流
任务如何拆分、分发、并发、重试、暂停和交接。
当 Agent 拥有多个可执行单元、多个工作区和多条任务路径后,平台需要新的调度与协作层。
- 调度器与生命周期管理器
- 消息总线或通信服务
- 分支能力与上下文共享机制
调度器负责最朴素也最关键的问题:
- 任务发到哪里执行
- 并发度怎么控制
- 失败是否重试
- 超时后怎么处理
- 哪些任务可以取消
- 哪些任务需要人工审批
消息总线负责 Agent 间的协作和事件分发。今天很多 Agent 协议只解决了对话层通信,离真正的平台级协同还有距离。复杂任务需要更清晰的消息语义、事件订阅、状态同步和任务交接。
企业真正需要的是 mission 级持续性,不是单次会话延长。调度与协作层决定的,正是任务能否跨执行实例、跨会话、跨时间持续推进。
Cloudflare 的产品案例可以放在这一层理解:
- Workflows 提供持久工作流引擎
- Project Think 指向更高层的 Agent SDK 与持久 Agent 平台
- Browser Run、Cloudflare Email Service、AI Search、Agent Memory 共同构成 Agent 工具箱
- Artifacts 为多步骤任务提供共享代码和数据空间
安全治理层:协议治理、网络边界与审计
如何把策略、网络、凭证、审计和协议治理放进平台底座。
安全治理层和身份层有交叉,但关注点更宽。它解决的是整个平台如何把策略、网络、协议和审计统一起来。
Cloudflare 的两篇文章在这层给出了很具体的方向:
- 私有网络接入要平台化,而不是靠临时隧道
- MCP 接入要有治理架构,而不是无序扩张
- 凭证注入要受控,避免敏感 token 暴露给不可信执行代码
- 协议层日志、访问路径、异常行为要能被观测和追踪
这层的必要性在企业环境里尤其强。只要组织内任何人都可以创建自己的 Agent,平台就必须能处理 Shadow MCP、越权访问、数据外泄和不可解释工具调用的问题。
这一层的代表性能力包括:
- Outbound Workers for Sandboxes 用于受控出站访问
- Cloudflare Access、Managed OAuth、resource-scoped permissions 用于策略和访问控制
- MCP 参考架构 与协议治理能力
- AI Gateway 等网关层能力,用于成本控制、日志和策略执行
支付、内容访问与 Agentic Web
这个话题详细看我之前这篇 Agent 支付基础设施全景:从 HTTP 402 到机器对机器经济
当 Agent 成为互联网流量的重要组成部分,Agent Infra 会进入最后一层:支付、内容访问和 Agentic Web。
这里的 Agentic Web,指面向 Agent 的网络形态。它关注的是 Agent 如何发现服务、如何获得授权、如何执行支付、如何遵守内容访问策略。
传统互联网的经济模型建立在人类注意力上,依赖广告、订阅和付费墙。Agent 不会消费这些中间环节,因此内容所有者和服务提供者需要新的基础设施来表达访问规则并获得收益。
这一层至少包括四个问题:
- 可发现性:Agent 如何知道一个服务支持什么协议和操作
- 授权:Agent 如何被识别并获得访问许可
- 支付:Agent 如何为服务和内容直接完成 machine-to-machine 支付
- 内容策略:内容所有者如何控制 Agent 可读取、可训练、可重定向的内容范围
Cloudflare 的产品和方向包括:
- MCP 作为服务发现与调用的重要协议
- x402 作为支付基础设施方向
- Agent Readiness 作为站点是否适配 Agent 的评估机制
- Redirects for AI Training 作为内容访问治理能力

从 CloudFlare 的产品生态看 Agent Infra 的层次分布
用基础设施分层重新观察,这些产品大致落在以下位置:
- 计算层:Workers、Dynamic Workers、Sandboxes、Durable Objects、Workflows
- 身份与权限层:Mesh、Managed OAuth、scoped permissions、Cloudflare Access
- 上下文与记忆层:Agent Memory、AI Search、Artifacts、Cloudflare Email Service
- 执行环境与运行时层:Sandboxes、Browser Run、Dynamic Workers
- 调度与协作层:Workflows、Project Think、cf CLI、Agent Lee
- 安全治理层:Outbound Workers for Sandboxes、MCP 参考架构、AI Gateway、Cloudflare Access
- 支付与 Agentic Web:x402、Agent Readiness、Redirects for AI Training
这说明 Agent Infra 已经从单点产品问题转向平台拼装问题。真正困难的部分,在于这些层次如何共同工作。
最后
下一代 Agent Infra 的核心,在于执行可控、身份可审计、上下文可继承、任务可持续、支付与访问规则可标准化。模型能力会持续提升,但单靠模型能力提升,无法替代这些平台层能力。
面向 AI Agent 的下一代基础设施,最终会形成一种新的平台形态:
- 轻量计算和完整执行环境并存
- 身份、授权与治理下沉到平台层
- 上下文、记忆和工作空间成为共享底座
- 执行环境具备隔离、可丢弃和分支能力
- 调度器、消息总线和持久工作流支撑长周期自治任务
- 支付、内容访问和协议治理延伸到 Agentic Web
这套平台还在形成过程中,但结构已经足够清楚。今天讨论 Agent Infra,讨论的是互联网、云平台和企业系统如何为 Agent 这类新型工作负载重写底层机制。