把 agent 当服务运营 · 规模化 agent fleet

0. 一堵 2026 年才撞上的新墙

先看清这一章存在的理由。一个 agent harness 在你笔记本上跑得好好的,和把成千上万个 agent 会话稳稳运营在生产里,是两件难度差着量级的事。IBM 估计到 2026 年底,大型企业平均每家要跑 1600 个以上的 agent,但只有约 12% 有一个集中的管理平台,IDC 则报告 88% 的 agent 试点根本到不了生产 —— 失败的几乎从来不是模型,而是模型外面那一层运营。就连前沿实验室都在这堵墙上撞得很疼:Anthropic 在 2026 年第一季度的需求,按年化算是它原计划 10 倍的 80 倍,逼得它在工作日高峰收紧会话限制;OpenAI 则说,一年前 ChatGPT 还卡在 GPU 上,等解决了 GPU,新的瓶颈变成了「什么都卡」。

这堵墙的根源,是 agent 会话和你前面服务的那种请求,形状完全不同。一个无状态的 web 请求是短命的、可互换的、可重试的,要扩容就加副本。一个 agent 会话却恰恰相反:它活很久(几分钟到几小时)、带着一路积累的状态、行为有副作用没法随便重试、还必须在你部署新版本时活下来。Kubernetes 社区为 agent 专门起了个项目,因为 agent 要的是一个「长期运行、有状态、单例、还带稳定身份」的容器,这正是无状态 web 副本的反面。更要命的是计费形状的错配:agent 会话是长时间挂着、中间夹着大量等模型响应的空闲,真正烧钱的往往不是那几次调用,而是 agent 干等响应时、那个沙盒的计时器还在走(有研究测出在线服务工作负载有六成时间在空闲、却消耗了那段时间近一半的能量)。

这是一堵 2025–26 年随着 agent 产品化才撞上的新墙:单个 harness 能跑,不等于万级并发能运营。前面那套服务「一个模型」的功夫不会自动迁移过来,因为 agent 会话的形状(长命、有状态、爆发、必须续命)和无状态请求根本不是一回事。

接下来四节,就是翻越这堵墙的四个面:怎么编排这些会话、怎么调度它们要的几万个沙盒、怎么让长任务扛住崩溃、以及怎么多租户地计费并把它们接回你前面那条 serving 主脊。

1. 编排 backplane:agent 会话不是无状态请求

要运营一群长命的有状态会话,第一件事是把「决策」和「执行」分开,这套思路直接借自网络领域几十年的控制面与数据面之分。控制面(control plane)负责决定:把一个会话调度到哪、路由怎么走、配额策略是什么,以及最关键的,谁拥有这个会话的状态。数据面(data plane)负责执行:真正把 agent 跑起来、把工具调用打出去。把这两层分开,你才能在不动正在跑的 agent 的前提下,改路由、改策略、加可观测性。

为什么不能像无状态服务那样,随便拿个反向代理或 API 网关往前一架就完事?因为一个 agent 会话可能持续几小时、一路握着记忆和上下文,这直接打破了反向代理和 API 网关背后的全部假设 —— 它们假设请求短命、可互换、能随意打到任意后端,而 agent 会话不能被随意搬动。一个有用的心智模型是把状态分成层级:一个用户底下有多个会话,一个会话又会跨越多次运行(一次运行 = 一段执行)。会话才是那个「包住一次活的交互」的隔离边界,而记忆是另一回事,是你有意重新引入的持久状态。这里有两个新手常踩的坑值得记住:拿用户 ID 当会话键(于是同一用户两个不相干的任务共享了草稿状态、互相污染),以及把工作进程本地的内存当成状态的权威来源(于是一次重启就把「跑得好好的」变成「状态丢了」)。

调度和排队这一层,正好和你前面学的 serving 主脊接上:这种长命、爆发的工作,要的是一个持久的任务队列加一个工作进程池,而不是一台「一请求一线程」的服务器。这套队列与工作进程的具体机制,恰恰是下一节沙盒调度和第三节 durable execution 的共同底座。这里要划清的边界是:本节讲的「编排」指的是基础设施的 backplane(会话调度、控制面与数据面、排队、状态归属),不是 agent 和 agent 之间怎么协作、怎么交接(那是多 agent 协同,#8 Agent 工程 Ch8 已经完整教过)。

2. sandbox-as-a-fleet:调度几万个隔离环境

agent 一旦动手执行代码,就需要一个隔离的沙盒。#8 Agent 工程 Ch4 已经完整教过单个沙盒是什么:用什么隔离档(Firecracker 微虚拟机、gVisor 等)、怎么设五维权限、本地还是上云。这一节不重复那些,它接着问一个纯粹是分布式 infra 的问题:当你要同时调度、回收几万个这样的沙盒,会怎样?

这个规模下的核心矛盾,是空闲回收与冷启动之间的权衡。沙盒闲着就烧钱(计时器在走),所以你想尽快回收它;可一旦回收,下一个请求来了就得从冷启动等起,而冷启动可能是好几秒。两头都贵。2026 年正在胜出的解法,是快照到待命加按活跃计费:把一个配置好的沙盒快照下来、挂起,释放掉计算资源(于是不烧钱),需要时再从快照近乎瞬间地恢复。配套的预热池(warm pool)则是另一根旋钮:预先备一批热沙盒,把启动延迟换成空闲成本,控制面的活就是拿到达速率去算这个池该多大。真实的数字能给你体感:Google 的 GKE agent-sandbox 报告每秒能起约 300 个沙盒、九成在 200 毫秒内;Modal 称能扩到 5 万个并发沙盒;Cloudflare 的沙盒 2026 年 4 月正式可用、单计划上万并发。

这里有个常被引错的数字值得澄清(也是性能工程该有的较真):Firecracker「125 毫秒启动」是 2018 年的最佳情况裸内核启动数,今天真正在用的是快照恢复,实测从约 28 毫秒(优化过的)到几百毫秒不等。安全这头,规模下的代表做法是一会话一微虚拟机、会话结束就把内存擦干净销毁(AWS Bedrock AgentCore 就是这么做的),因为长期共享的环境会累积跨会话的残留状态。注意这一节自始至终讲的是「沙盒服务底下那层分布式调度基础设施怎么造」,而「怎么用一个沙盒服务让 agent 安全地动手」是 #8 Ch4 的题目,两者像 GKE Agent Sandbox 那样分工:它的 K8s 底座属 #2,它对外暴露的那层 agent 沙盒抽象属 #8。

3. durable execution at scale:让长任务扛住崩溃与重启

一个跑几小时的 agent,中途机器崩了、或者你部署了新版本,它不能从头再来。#8 Agent 工程 Ch2 已经教过为什么 agent 需要这种「断点续跑」的能力(durable execution),也讲过它的两大流派和那个「把不确定的 LLM 调用包成可重放步骤」的确定性陷阱。这一节接着 #8 留下的那条线,讲 #8 明确没碰的东西:这些 durable execution 引擎,作为分布式系统,底层到底是怎么造的。把它理解成一条三点谱系最清楚。

一端是嵌入式的库,代表是 DBOS:它把持久性做成一个嵌在你进程里、用 Postgres 兜底的库,不需要单独的基础设施,队列就是 Postgres 里的记录,一次步骤转移约等于一次 1 毫秒的数据库写。它最轻,适合不想多养一套系统的场景,多节点恢复靠一个控制面检测到崩溃的执行器、把工作流恢复到健康节点上。谱系的中间是专门造的分布式日志,代表是 Restate:它从头造了一个持久执行数据库,底下是一条复制日志,按键分区(用工作流 ID、幂等键这类做分区键),每个分区有自己的主从,对应用隐藏分区细节,于是能在不丢一致性的前提下重新分片。另一端是外部编排器,代表是 Temporal:它的服务器只编排状态转移、从不运行你的代码,你的代码跑在无状态的工作进程里、长轮询任务队列,一个工作进程能挂着上百万个开着的工作流执行,它的匹配服务把每条任务队列切成一棵树来避免热点。三者的取舍很清楚:越往嵌入式走越简单、越往外部编排走越能扛多租户多区域的超大扇出。

这条谱系是真在被生产采用的:Temporal 在 2026 年 2 月拿了 3 亿美元 D 轮、估值 50 亿,OpenAI 的 Agents SDK 也在 2026 年 3 月正式集成了它。durable execution 从一个小众技术,变成了生产 agent 的标配。要再次划清边界:本节讲的是引擎内部的分区、工作进程分片、一致性这些分布式系统机制(#8 说它「不碰」的那一层),而「我的循环怎么用 durable execution 扛崩溃、怎么避开确定性陷阱」是 #8 Ch2 的题目,不在这里重讲。

4. 多租户网关 + 接回主脊

最后两件事,把这群 agent 接到真实世界:怎么向多个租户收费,以及它们背后那层模型服务怎么接回你前面学的主脊。先看网关。一个服务多租户的 agent 网关,第一条要纠正的直觉是:按请求数限流是错的原语。一个一万 token 的调用和一个五十 token 的调用,开销天差地别,可它们都算「一个请求」。所以要按 token 计量(每分钟 token 数、每天 token 数为主,请求数为辅),而且输入和输出要分开记(它们价格不同)。计量和隔离的那把钥匙,是一个按租户、工作负载、模型三个维度组合的桶键:它粗到能限流、又细到能把某个跑飞了的租户单独掐住而不误伤别人,同一个维度还顺带支撑成本台账、审计日志和配额。配额本身按组织、团队、用户、虚拟密钥层层向下分,子级不能超过父级;虚拟密钥就成了租户之间的隔离边界,撞到配额就返回 429,而 agent 框架天然会把 429 读成退避信号,于是配额执行和 agent 循环干净地咬合在一起。

现在是这一章最该让你「啊哈」的一处,它把 Ch11 接回了整条路书的主脊。agent 是所有 serving 客户端里前缀最霸道的一种:它的上下文是目标加工具定义加一路积累的完整行动与观测历史,输入对输出的比例常常超过 100 比 1。这意味着第六、七章讲的前缀缓存,对 agent 比对任何别的工作负载都更值钱。但有个坑:标准的 LRU 缓存淘汰策略对 agent 是错的,它常常在一段 KV 即将被复用前把它丢掉。于是出现了一批 agent 专属的招:按工作流感知来淘汰(KVFlow)、给 KV 设存活时间好熬过工具调用那段停顿(CacheTTL)、以及缓存感知的 prefill/decode 分离路由(把高复用和冷 prefill 的请求分开打)—— 这些正是你在 Ch6 学的 PD 分离、Ch7 看的前缀缓存,换到 agent 客户端这一侧再看一遍。这里还藏着一个微妙的安全点:跨租户共享前缀缓存会造出一条时序侧信道,一个有心的租户能靠观察缓存命中的延迟,推断出别的租户最近问了什么,缓解办法是按租户给缓存命名空间做哈希(代价是牺牲跨租户复用)。

把镜头拉到真实的 lab,你会看到这一章不是空想。Google 在 2026 年 I/O 上把这套能力产品化成了「Managed Agents」,号称把编排、沙盒、工具路由、状态管理塌缩成一次调用。OpenAI 撑着它那 8 亿用户,靠的是一套单主 Postgres 加约 50 个只读副本(刻意没上分片)、把高低优先级流量隔到不同副本池,还在 ChatGPT 图像上线、每小时新增百万用户时,在线把同步架构改成了异步而没大宕机。Anthropic 则反复强调一句话:推理而非训练,才是那个永不停歇的算力消耗,因为训练是一次性的,而推理随每个用户、每天 24 小时地涨。这些就是「把 agent 当服务运营在规模上」此刻在前沿真实的样子。

综合 · 你现在能把 agent 当一个生产服务来运营了

收一下这一章。你先认清了一堵 2026 年才撞上的新墙:单个 harness 能跑,不等于万级并发能运营,因为 agent 会话的形状(长命、有状态、爆发、必须续命)和无状态请求根本不是一回事。然后你走了翻墙的四个面:用控制面与数据面分离来编排会话、想清楚会话和状态该归谁拥有;把沙盒当成一支舰队来调度,在空闲回收与冷启动之间用快照到待命来权衡;理解了 durable execution 引擎作为分布式系统的三点谱系(嵌入式 DBOS、分布式日志 Restate、外部编排 Temporal),那是 #8 教你「怎么用」之后、#2 接手讲的「怎么造」;最后学会了按 token 多租户计量,并把 agent 那霸道的前缀接回了 Ch6/Ch7 的前缀缓存与 PD 分离主脊。

这一整套的价值,是让你能对一个 agent 生产服务负责,而不只是写好一个 agent。当成千上万个会话同时在跑,你不再手足无措,而会问:会话状态归谁拥有、控制面和数据面分开了吗?沙盒池该多大、空闲的该快照挂起还是冷杀?长任务用哪一档 durable 引擎扛崩溃?计费按 token 还是按请求、前缀缓存跨租户安全吗?能答出这些,你就跨过了这堵墙。同时也请守住那条边界:这一章自始至终讲的是把 agent 当服务运营在规模上的分布式与运维面,而单个 harness 怎么造(循环、上下文、工具、单沙盒、单 agent durable、对抗安全),始终是 #8 Agent 工程的题目。

学完这一章,你已经能设计一个 agent fleet 的编排 backplane、能权衡 sandbox 舰队的空闲与冷启动、能挑选 durable execution 引擎、能设计多租户网关,也理解了 agent 作为前缀霸道的客户端为什么让前缀缓存格外关键。下一章是整条系统设计路书的收官:我们把全路书的 trade-off 串成一把判断力的尺子,再用「墙与轴」外推这个领域往哪走 —— 收口到使命说的「前沿就绪」。

本章关键术语

本章引入的 canonical 术语,点进术语表看更完整的解释:

• agent fleet · 把 agent 当服务运营 把成千上万个 agent 会话当成一个生产服务运营在规模上。新墙:单 harness 能跑 ≠ 万级并发能运营。agent 会话的形状(长命/有状态/爆发/必须续命)与无状态 web 请求相反 —— 这是 #2 分布式 infra × #8 agent 语义的交叉,只讲运营面、不重教 harness 内部
• orchestration backplane · 编排 backplane 借自网络的控制面/数据面之分:控制面决定路由/调度/策略/状态归属,数据面执行 agent + 工具调用。反向代理的无状态假设对长命有状态会话失效;状态分层 用户→会话→运行,会话是隔离边界(别拿用户 ID 当会话键、别拿工作进程本地内存当权威)
• sandbox fleet · sandbox-as-a-fleet 调度/回收几万个隔离沙盒(单沙盒是什么见 #8 Ch4)。核心旋钮是空闲回收 vs 冷启动:2026 解法 = 快照到待命(近瞬恢复)+ 按活跃计费 + 预热池(拿到达速率算池大小)。一会话一微虚拟机 + 结束擦内存是规模下的安全做法
• multi-tenant gateway · 多租户网关 按 token 计量(非请求数 · 输入输出分开),用「租户×工作负载×模型」桶键同时做限流/成本台账/审计,配额按 组织→团队→用户→虚拟密钥 层层向下;虚拟密钥 = 租户隔离边界(撞配额返回 429,agent 读作退避)。跨租户共享前缀缓存有时序侧信道,按租户哈希命名空间缓解

参考文献

Mode A · 引用出处(正文 inline,集中列在此)

• Temporal · Restate · DBOS(各官方文档)· durable execution 的三点谱系:外部编排(无状态工作进程长轮询任务队列)/ 分布式日志(按键分区 + 主从)/ 嵌入式(Postgres 兜底、队列即记录);Temporal 2026-02 拿 3 亿 D 轮、估值 50 亿,OpenAI Agents SDK 2026-03 集成
• Firecracker + GKE Agent Sandbox + Cloudflare Sandboxes GA(各官方)· 沙盒舰队:Firecracker 125ms 是 2018 裸内核数、今天用快照恢复(~28ms 起);GKE 约 300 沙盒/秒、九成低于 200ms;一会话一微虚拟机 + 擦内存
• Kubernetes agent-sandbox SIG(CNCF)· agent 要的是「长期运行、有状态、单例、带稳定身份」的容器 —— 无状态 web 副本的反面
• Anthropic · 多 agent 研究系统 + OpenAI · Scaling PostgreSQL(各官方工程博客)· agent 4× / 多 agent 15× token;OpenAI 8 亿用户跑在单主 Postgres + ~50 只读副本、刻意不分片、高低优先级隔离
• KVFlow(2025)· agent 工作流感知的 KV 淘汰:标准 LRU 对 agent 是错的(在复用前丢掉 KV);承 Ch6 PD 分离 + Ch7 前缀缓存到 agent 客户端侧
• DeepMind · Agent Platform / Managed Agents(JD + Google I/O 2026)· 编排 / 工具用 infra / 规模化 sandboxing;把编排/沙盒/工具路由/状态塌缩成一次调用(收录于 research/system-design/job-postings/deepmind.md)
• 前置 · #8 Agent 工程:单个 harness 的 loop/context/tools/单沙盒(Ch4)/单 agent durable(Ch2)/多 agent 协同(Ch8)—— 本章站在其上,只讲运营在规模上的分布式/ops 面,不重教

深 dive 资源(可选 · 想往下走再看)

• The Tail at Scale(Dean & Barroso, CACM 2013)· 上一章的请求对冲,同样适用于 agent fleet 的长尾会话
• E2B / Modal / Daytona(各官方)· agent 沙盒平台的真实形态:并发上限、快照恢复、计费模型(自报数,自己实测为准)

说明:本章没有 Mode B 视频站 —— 「把 agent 当服务运营在规模上」是 2025–26 才成形的新领域,缺少合格的系统化教学长视频;官方文档、工程博客与 JD 在上方按需列出,由 Mode A 原创讲解扛主线。

下一章

下一章 Ch12 是整条系统设计路书的收官。它不再加新零件,而做两件事:把前面十一章的 trade-off 串成一把判断力的尺子(latency × throughput × cost × reliability 这四维怎么相互拉扯,一个 serving 系统的设计取舍到底怎么做),再用第一章给你的「墙与轴」方法,带你外推这个领域往哪走 —— 当前还有哪些墙(内存墙、能耗墙、规模可靠性墙、网络带宽墙、agent fleet 运营墙),可能的正交新轴又在哪。读完你不只会设计当下的系统,还会用同一把尺子持续判断每个新进展的意义,这就是使命说的「前沿就绪」。