Agent Runtime 架构解析——给智能体造一台操作系统

当 Agent Loop 只需要十行代码，真正的工作才刚刚开始。本报告拆解承载智能体循环的系统软件层：事件循环引擎、状态持久化、记忆子系统、工具执行的隔离与权限、多智能体协调，以及它脚下正在被 Agent 流量重塑的 PyTorch 推理栈。

版本基线：2026 年 8 月。关键结论均注明来源（官方文档、论文或带 commit 锚点的源码），第三方实测数据单独标出。全部示意图使用 Mermaid，可在 GitHub / Typora / Obsidian 中直接渲染。

---

0. 执行摘要

写一个能跑的 Agent，十行代码就够了；让它在生产环境里 7×24 跑上一年，需要的是一套运行时。差距不在模型，而在模型之外的所有事情：进程重启后会话还在不在、模型生成的 rm -rf 交给谁执行、三个并行工具调用会不会打爆下游 API、出了事故能不能回答"模型当时为什么这么干"。

这份报告的核心判断有三个。

第一，Agent Runtime 正在重演操作系统的历史。 vLLM 那篇报告把 KV 缓存比作操作系统管内存，这个类比在 Runtime 层面更加贴身：会话是进程，检查点是进程快照，工具是系统调用，权限网关是内核态/用户态的分界，长期记忆是磁盘，上下文窗口是物理内存。这不是修辞——2026 年主流实现的功能清单和三十年前教科书里的 OS 章节目录高度重合。

第二，格局已经收敛到可以点名道姓的程度。 循环引擎上，OpenAI Agents SDK 与 Claude Agent SDK 代表"控制内聚"路线，LangGraph 与 AutoGen 代表"消息解耦"路线（后者已于 2026 年 4 月进入维护模式，微软转向 Agent Framework）；工具协议上 MCP 已成事实标准；推理栈上发生了一件标志性事件——TensorRT-LLM 在 1.0 版本移除了自有的 TensorRT 编译后端，PyTorch 成为唯一执行路径。连 NVIDIA 都收敛了，选型焦虑可以放下了。

第三，Agent 流量正在反向重塑推理基础设施。 vLLM 与 Mooncake 对 Codex 真实 trace 的统计显示，Agent 会话的输入输出 token 比高达 131:1，相邻两轮之间 85–95% 的 prompt 完全相同。瓶颈从"解码吞吐"迁移到了"前缀复用、调度效率与工具往返等待"，这直接催生了会话级 KV 缓存池、缓存命中率感知的路由和 P/D 分离部署——这些是纯 chat 时代不存在的工程命题。

下文按一条主线展开：循环引擎（第 2 章）→ 状态与记忆（第 3 章）→ 工具执行（第 4 章）→ 推理后端（第 5 章）→ 多智能体与可观测（第 6、7 章），最后给出选型指南与开放挑战。本文始终聚焦 Runtime 系统层——模型服务与应用代码之间的那一层。

---

1. 从十行代码到一套运行时

1.1 最小 Agent 的四种死法

把最小 Agent Loop 部署上线，它大概会以下列方式之一死去，每种死法对应运行时缺了一块。

死于重启。 循环状态活在进程内存里。凌晨三点 OOM 重启，用户的三小时研究任务原地蒸发，连道歉的对象都找不到。要活下来，循环状态必须落盘，而且落盘粒度要细到"任意一步之后都能接着跑"——这就是检查点问题。

死于自己的手。 模型决定执行一段 shell 来"清理磁盘"，你的 Runtime 照做了。工具执行没有隔离边界、没有策略裁决、没有人审环节，等于把 root shell 直接递给一个概率系统。这是沙箱与权限问题。

死于并发。 模型一口气发起八个并行搜索，下游 API 的速率限制是每秒两次。没有有界扇出、没有重试分类、没有幂等保护，轻则限流风暴，重则重复扣款。这是并发治理问题。

死于账单与黑盒。 上下文只进不出，第 30 轮时单次请求 80K token；出了错没人说得清模型看过什么、调过什么。这是上下文管理与可观测性问题。

四种死法拼在一起，就是 Runtime 的功能边界。它不是框架营销出来的概念，而是被生产事故倒逼出来的工程必然。

1.2 行业怎么定义它

各家对 “Agent Runtime” 的表述不同，但拆开看指向同一组职责：

来源	表述	强调的点
OpenAI	“想要自己掌控循环就用 Responses API，想让 SDK 替你跑循环就用 Agents SDK”；运行时要回答的问题是：一次 run 做什么、下一轮如何延续、工作流在等待审批时如何表现	循环的所有权
Anthropic	运行时 = 内嵌的 agentic loop + 上下文管理 + 工具/权限/预算控制	受控的自主性
LangGraph	自我定位为 “low-level orchestration framework and runtime for building, managing, and deploying long-running, stateful agents”——durable execution、human-in-the-loop、comprehensive memory	长时间运行的有状态服务
AWS Bedrock AgentCore	区分 Harness（托管 agent 循环，一次 API 调用完成编排）与 Runtime（托管执行环境，每个会话一个 Firecracker 微 VM，最长 8 小时）	执行环境的隔离与会话化
AutoGen v0.4	运行时 = actor 中间件：注册、路由、序列化、状态存取、跨进程互通	消息传递基础设施

综合起来可以给一个工作定义：

Agent Runtime 是承载 agent 循环的系统软件层。它做四件事：决定下一步（循环引擎）、记住发生过什么（状态管理）、安全地对外做事（工具执行）、并让以上一切成为可持续运营的服务（生命周期与可观测性）。

注意定义里没有出现任何具体框架名。Runtime 是一层职能，LangGraph、Claude Agent SDK、AgentCore 各自实现了它的一个真子集或全子集——这也是第 8 章选型对比的意义所在。

1.3 分层全景

把四件事放进一张架构图，后文的章节都可以在这张图上找到位置：

两个横切面值得单独强调：可观测性和安全不是某一层的功能，而是贯穿所有层的约束——第 4.5 节会看到，安全做得好的系统，每个检查点都是确定性的、模型之外的、默认拒绝的。

---

2. 事件循环引擎：Runtime 的心脏

2.1 循环的解剖

ReAct 论文（arXiv:2210.03629）给出了至今仍然有效的形式化：把动作空间扩展为  = A ∪ L——A 是真实的行动，L 是语言形式的"思考"。思考不改变环境，只更新上下文（c_{t+1} = (c_t, â_t)），轨迹就是"思考→行动→观察"的交替序列。今天所有的生产实现都是这个形式化的工程化，差别在于三处：

• 一轮的粒度：是一个动作一轮，还是一批动作一轮；
• 控制流的归属：循环逻辑写在宿主代码里，还是被分解成图上的节点、actor 之间的消息；
• 中断语义：暂停意味着什么——丢掉？存档？还是变成一个可以恢复的分布式事务？

先看通用形状：

图里有两个容易被低估的设计决定。其一，结果合并为一条消息：并行工具调用的全部结果必须塞进同一条 user 消息回传，拆成多条会让部分模型停止批量发起并行调用。其二，暂停即存档：人工审批可能持续几分钟也可能持续几天，远超任何进程的生命周期，所以挂起不能是"线程等着"，必须是完整的状态序列化——这直接引出第 3 章。

2.2 六种实现，两种范式

把 2026 年主流实现的循环语义摊开对比，会发现它们分属两种范式。控制内聚路线里，循环是一个进程内的显式 while 循环，逻辑一目了然：OpenAI Agents SDK 的 Runner.run（循环直到产出 final output，max_turns 默认 10，超限抛 MaxTurnsExceeded）、Claude Code 的一轮 = “评估 + 执行一批工具”、smolagents 约一千行核心代码的 ReAct 循环、CrewAI 的 crew 编排器加每代理独立执行器。消息解耦路线里，循环被打散成调度单元间的协作：LangGraph 把计算建模为 Pregel 风格的超步（superstep），每轮执行一批可并行节点后统一同步；AutoGen v0.4 干脆不提供内置 LLM 循环，运行时只保证消息投递、生命周期与持久化，决策逻辑完全交给 actor 自己。

维度	OpenAI Agents SDK	Claude Agent SDK	LangGraph	AutoGen Core	CrewAI	smolagents
运行时核心	Runner 事件循环	Claude Code 内嵌循环	Pregel 超步调度	actor 消息中间件	编排器 + ReAct 执行器	MultiStepAgent 循环
一轮粒度	一步（step）	一批工具	一个超步	一条消息	一项任务	一步（代码动作）
状态管理	Session / RunState / 服务端 conversation	会话内累积 + 自动压缩	Checkpoint 快照链	save/load 可序列化状态	TaskOutput 链 + 记忆	内存步骤列表
人审机制	工具审批，RunState 恢复	权限模式 + hooks	interrupt() / Command(resume)	InterventionHandler	human_input 标志	无内建
多代理	handoffs / agents-as-tools	子代理 + Workflow 工具	子图 + Send API	topic/subscription	层级 manager	managed agents
2026 状态	活跃（新增 SandboxAgent、嵌套 handoff beta）	活跃 v2.1.x	v1.2.x 活跃	维护模式 → 微软 Agent Framework	活跃	活跃

几个值得驻足的实现细节。OpenAI SDK 的每一步解析为一个 NextStep* 判定——NextStepHandoff、NextStepFinalOutput、NextStepRunAgain、NextStepInterruption——审批中断后的恢复从保存的 RunState 继续，而不是开新一轮对话，这个设计保证了"批准"发生在原来的因果链上。Claude Code 的权限系统是一条固定的六段求值链：hooks → deny 规则 → ask 规则 → 权限模式 → allow 规则 → 兜底回调，且 allow 不跳过后续规则；预算上限 max_budget_usd 连子代理的花费一起计，触顶后拒绝新子代理并停掉后台的。AutoGen 的单线程运行时用 asyncio 队列做信封投递，可插拔的 InterventionHandler 能在任何 send/publish 前拦截甚至丢弃消息——这是消息解耦路线独有的治理钩子。

范式之间没有胜负，只有代价结构的不同：控制内聚好调试、好推理，但跨进程扩展要自己想办法；消息解耦天然分布、天然可插拔，但一条消息的生命周期排查起来像在读分布式系统的日志。AutoGen 进入维护模式的教训则更现实一些——运行时的护城河不在抽象优雅度，而在生态位是否踩中了下一个需求浪潮。

2.3 一轮请求的生命周期

把镜头拉近到单个回合，看数据如何流过整条链路：

三个环节值得展开。流式与工具调用的交错：模型的回复以 SSE 增量到达，文本 token 和 tool_use 结构块混在同一条消息流里，Runtime 边收边解析，收到完整的 tool_use 才触发执行，期间已到的正文可以先推给用户——OpenAI 的 run_streamed() 把每步结果推入异步事件队列，消费方按语义事件（原始增量 / 条目级事件）迭代，整个 run 要等流结束才算终结。结果的配对：tool_result 靠 tool_use_id 与请求配对而非靠顺序，这是并行调用不出乱序的基础。检查点的时机：写档发生在回填模型之前而不是之后，崩溃恢复时才能做到"最多重做一个动作，绝不重复一次副作用"。

2.4 中断与恢复：HITL 的三种姿势

人审是 Agent 与传统自动化的分水岭，三家给出的姿势各有侧重。OpenAI 用审批对象：工具声明标记 needs_approval，运行在审批点暂停，批准后从 RunState 恢复，且审批绑定精确参数——模型事后改参数，原审批不作数。Claude 用权限模式谱系：从 bypassPermissions 到 plan 再到 auto（模型分类器替代人工审批），配合 hooks 可以在 PreToolUse 阶段改写、延迟或否决调用。LangGraph 用一等公民的 interrupt()：节点内随时抛出中断，状态自动存档，恢复时用 Command(resume=...) 注入人类决定，同一个 thread_id 下循环从中断点继续。

三种姿势共享同一条底线：暂停必须等价于存档。凡是做不到这一点的 HITL 都是装饰品——审批弹窗弹出来的时候，如果背后没有一个持久的、可恢复的状态快照，那么进程一崩，“等待审批"就变成了"永远丢失”。

---

3. 状态与记忆：把易失的循环变成可恢复的服务

3.1 五层状态模型

Runtime 的状态管理可以在一个分层模型里讲清楚，每一层都能在操作系统中找到对应物：

五层的职责边界很清楚：L1 易失且昂贵，一切设计都围绕"少装、快命中"；L2 是恢复语义的载体，检查点做在这里；L3 是审计的真相，只追加不修改；L4 跨越会话的生命周期，决定 Agent “记不记得你”；L5 解决协调，也引入一致性问题。工程上最容易犯的错误是层间混淆——把长期记忆塞在上下文里当短期记忆用（账单爆炸），或者把审计日志当状态存储用（无法高效恢复）。

3.2 检查点：暂停即存档的工程实现

LangGraph 的 Checkpointer 是这条路上最完整的公开实现。图编译时挂载一个 checkpointer，此后每个超步边界自动保存一次完整状态快照。Postgres 后端的表结构值得细看：

CREATE TABLE checkpoints (
    thread_id            TEXT,
    checkpoint_ns        TEXT NOT NULL DEFAULT '',
    checkpoint_id        TEXT,          -- ULID, 字典序即时间序
    parent_checkpoint_id TEXT,
    type                 TEXT,
    checkpoint           BYTEA,         -- 序列化的完整图状态
    metadata             JSONB,
    PRIMARY KEY (thread_id, checkpoint_ns, checkpoint_id)
);

CREATE TABLE writes (                -- 节点级增量写入
    thread_id TEXT, checkpoint_ns TEXT, checkpoint_id TEXT,
    task_id   TEXT, idx INTEGER,
    channel   TEXT, type TEXT, value BLOB,
    PRIMARY KEY (thread_id, checkpoint_ns, checkpoint_id, task_id, idx)
);

两个设计决定体现了深思考。其一，checkpoint_id 用 ULID 而非 UUID——时间有序让"找上一个快照"变成一次索引扫描。其二，checkpoint 内部除了 channel_values（应用状态本体）还维护 channel_versions 和 versions_seen 两张版本向量表，用来判定"这个节点是否已经看过某通道的这个版本"——这是并发正确性的核心，也是超步模型能安全重放的原因。恢复出来的 StateSnapshot 里，next 字段就是程序计数器：下一步该跑哪些节点。

于是四种恢复模式全部免费获得：续跑（同 thread_id 再次 invoke，从最近快照的 next 队列继续）、重放（指定历史 checkpoint_id 重跑其后节点，LLM 会真实重新执行）、分叉（update_state 修补历史快照后形成新分支，类似 git 的分支模型）、人审挂起（interrupt 本身就是一次存档）。生产上的注意点反而朴素：checkpoint 表无界增长需要保留策略清理；SQLite 版有写锁限制只适合本地；Redis 版靠 TTL 语义适合高吞吐短会话；要审计和时间旅行，Postgres 是默认答案。

Claude Code 给出了另一种答案：事件溯源。它的会话是 ~/.claude/projects/<编码路径>/ 下的 JSONL 文件，每行一个自包含事件（user / assistant / tool_result / system），每条记录带 uuid 和指向上一条的 parentUuid，天然构成链表。压缩发生时写入一条特殊的 compact_boundary 系统事件，携带触发类型与前缀 token 数——真实会话里能看到 "preTokens": 167219 这样的记录，说明约 16.7 万 token 才触发一次自动压缩。子代理的事件写在独立文件里，通过 isSidechain 标志关联。追加式写入带来天然的崩溃安全（最坏丢最后一行），代价是恢复时要沿链重放而非直接加载快照。

两条路线的选择题没有标准答案：快照式恢复快、查询强，但快照本身是有损压缩后的状态；事件式无损、可审计，但重放有成本且存储只增不减。成熟系统正在合流——LangGraph 的 writes 表本质上就是事件流，而 Claude Code 的 compact_boundary 就是快照标记。

3.3 核心实体关系

把上述机制抽象成数据模型，一张 ER 图可以覆盖绝大多数运行时的持久化需求：

几处建模决策值得说明。MESSAGE 的内容用 typed blocks 数组而非纯文本，因为 thinking、tool_use、tool_result 需要不同的生命周期——上下文清理时删得掉 tool_result 却必须留着 tool_use 记录，否则模型不知道自己调用过什么。MEMORY_RECORD 的四维作用域（user/agent/app/run）来自 mem0 的实践，它让"这次任务内的临时记忆"和"这个用户的长期偏好"天然分离，清理互不影响。FACT 的四个时间戳来自 Graphiti 的双时态模型，下一节展开。

3.4 长期记忆的三条路线

Letta（MemGPT 的工程化）走"让模型自己管理内存"路线。 核心抽象是 Block：带 label、value、大小上限的可编辑文本块，常驻上下文，模型通过 core_memory_append / core_memory_replace 自我修改；放不下的进 archival memory 走语义检索，文件类内容用 LRU 窗口管理。这套设计的哲学是把上下文窗口当物理内存、把外部存储当磁盘，用函数调用完成分页。

mem0 走"基础设施托管"路线。 应用调 add() / search()，抽取、去重、冲突消解全部由确定性管道完成：单次 LLM 调用按 ADD-only 语义抽取事实（纠正靠显式的 update/delete，不做模糊合并），MD5 哈希去重，向量化入库，同时把每次变更写进 history 表留审计。它的价值主张是"记忆的正确性不该依赖模型的自觉"。

Zep/Graphiti 走"时间线"路线。 论文（arXiv:2501.13956）的出发点很尖锐：纯向量检索返回陈旧事实和当前事实时置信度一样高，而 Agent 记忆的本质是随时间演化的关系网络。Graphiti 把原始输入无损存成 episode 子图，实体和事实抽成语义子图，每条事实边携带四个时间戳——valid_from/valid_to 记录"世界上这件事何时为真"，observed/recorded 记录"我们何时听说并记下"。新信息与旧事实冲突时不删除，而是关闭旧事实的 valid_to：当前真相和历史真相同时可查，Agent 幻觉最常见的来源之一就此消除。基准数字也拿得出手：DMR 上 94.8% 对 MemGPT 的 93.4%，LongMemEval 最高 +18.5% 精度、延迟降九成。

选型直觉：要 Agent 有"自我人格"般的连续性，Letta；要把记忆做成可治理的基础设施，mem0；业务事实本身带强时序（用户换了地址、换了职位、取消了订阅），Graphiti。三者不互斥——向量召回是所有路线共用的底层组件，区别在上层的组织方式。

3.5 上下文工程：压缩、编辑与预算

上下文窗口是 L1 内存，管理它的手段在 2026 年已经标准化。Anthropic 把三个原语并列为一等能力：Compaction（compact_20260112，输入 token 达阈值——默认 150K、下限 50K——服务端把整个对话扁平化为一条摘要块，后续请求自动丢弃摘要之前的一切）；Context Editing（clear_tool_uses_20250919，精准得多：只清除旧的 tool_result 大载荷，保留 tool_use 记录，默认保留最近三对，可用 clear_at_least 保证"至少清够本，否则不打断缓存"）；Memory Tool（memory_20250818，把上下文之外的文件系统暴露给模型自行读写，跨会话生效）。官方给出的内部评估是组合使用在长程任务上有显著收益，100 轮网页搜索评测中 token 消耗下降 84%。

预算策略比原语选择更能区分新手和老手。实践中站得住的几条：阈值别设太低，否则摘要请求本身就可能再次触发压缩；按工作单元设自然压缩点（每处理完 N 个工单、每个阶段结束），比全局统一阈值更贴合业务节奏；用"压缩计数器 + pause_after_compaction"构造总预算，超了就优雅收尾而不是被硬切断；警惕缓存 token 的陷阱——SDK 侧统计若把缓存读也算进累计输入，会在真实历史远未到限时误触发压缩。Anthropic 自己的研究 agent 示例把阈值设在 180K，刻意让第一批大规模读取在阈值之下完成，第二批推进时才触发压缩——压缩点的位置是可以被设计出来的。

3.6 为缓存而设计的提示词前缀

这一小节是 Runtime 设计与第 5 章推理经济的接口，也是全文性价比最高的一节。Prompt caching 的定价结构决定了游戏规则：缓存写入加价 25%，命中读取只要十分之一的价格——第二次命中就回本。而 Agent 循环恰恰是最理想的受益者：相邻两轮之间绝大部分内容不变。

规则不多，但每条都有反例背书。层级顺序 tools → system → messages，任何一层变化都会使其后全部层级失效——所以工具定义要一次定稿，别在循环中途增删。cache_control 断点最多四个，应该打在"最后一个跨请求不变的块"上；打在包含时间戳的块上等于永远零命中，这是最常见的翻车点。超过二十个内容块的增量需要第二个断点兜底（20-block 回看窗口的限制）。各模型有最低可缓存长度（512 到 4096 token 不等），低于阈值静默不缓存，排查时看响应里的 cache_read_input_tokens 是否为零。最精妙的一条来自 Letta 的宪法文档：“把频繁更新的记忆放在 system prompt 末尾以最小化缓存失效”——低频指令在前、高频记忆在后，一行布局决策直接换算成账单折扣。这些纪律在第 5.3 节会兑现为具体的命中率数字。

---

4. 工具执行：Runtime 的系统调用接口

4.1 MCP 的位置与生态现状

MCP 之于工具生态，相当于 USB-C 之于外设：一次声明，处处接入。Gateway 类产品进一步把它变成治理点——聚合多个上游 MCP 服务、做入站出站双向认证、用语义搜索从几千个工具里按当前任务筛选出少数几个注入 prompt（工具太多本身就是上下文污染）。但生态的安全水位还远谈不上健康：2026 年 5 月的一项测量显示，43% 的线上 MCP 服务器存在命令注入缺陷，30% 允许无限制 URL 抓取，40.55% 的远程 MCP 服务器完全未认证；VIPER-MCP 项目扫描近四万个仓库发现了 106 个零日。这就是为什么工具执行必须有纵深防御，而不能信任"声明了 schema 的工具就是安全的工具"。

4.2 隔离谱系：从容器到微VM 到 WASM

沙箱选型的三个维度是冷启动、运行时开销和隔离强度，2026 年的数据已经足够把选择变成算术题：

技术	冷启动	运行时开销	隔离强度	适用场景
Docker (runc)	~50–500 ms	<2% CPU	共享内核，一次内核 CVE 全线穿透	可信代码、开发环境
gVisor	~150–200 ms	I/O 密集 10–30%，典型 5–15%	用户态内核拦截 ~250 个 syscall	Cloud Run/GKE 系托管沙箱
Firecracker 微 VM	~125 ms 启动，快照恢复 5–30 ms	接近原生，VMM 每实例 <5 MiB	硬件虚拟化两层防线	生产级代码执行（Lambda/E2B 同源）
WASM (wasmtime)	热实例化 ~105 µs，冷启动 ~23 ms	Rust AOT 场景 3–10%	能力模型，天然默认拒绝	高频短命调用

Firecracker 的快照恢复是被低估的关键技术：预热好的微 VM 可以在毫秒级恢复到干净初始态，这让"每次工具调用都用全新内核"从奢侈品变成默认选项——AWS 官方的架构说明确认 AgentCore 为每个会话分配独立微 VM，会话结束即销毁消毒，单个会话最长八小时。WASM 则在另一个极端发光：单机并发密度比容器高两个数量级（runwasi 基准 329 对 85 tasks/s），代价是无线程、无 GPU、语言运行时开销不均（Go 编译产物慢 13–15 倍，Rust AOT 几乎无感）。托管平台把这道选择题变成了采购题：E2B（Firecracker 系，实测创建 717ms、快照恢复 662ms，$0.0504/vCPU·h）、Modal（gVisor 系，唯一能把 GPU 装进沙箱，$0.1419/core·h）、Cloudflare Sandboxes（2026 年 4 月 GA，出口代理凭证注入是亮点）、Daytona（~90ms 启动，但同年 6 月转闭源云托管——自托管路线的选型要留意这类转向风险）。

选型启发浓缩成三句：不可信代码至少 gVisor，碰生产凭证上微 VM；冷启动敏感的高频短调用考虑 WASM；共享内核容器跑多租户不可信代码在任何情况下都不成立。

4.3 受守卫的调用路径：权限即基础设施

权限设计的核心原则一句话可以说完：模型不是授权层。系统提示词里的规则是建议，注入攻击随时可以改写它；真正的授权必须发生在模型之外。2026 年的标准架构是 PDP（Policy Decision Point）模式，控制分四层递进：

第一层管可见性：模型看不见的工具就不会被调用，按角色裁剪工具清单既省 token 又缩小攻击面。第二层管决策：OPA/Rego 或 AWS Cedar 在调用前裁决，输入是工具名、完整参数、代理身份与会话上下文。fail-closed 是铁律——OPA 对未定义决策返回空结果，客户端必须把"没有结论"当作拒绝处理，配合拦截器超时拒绝、Rego 默认 deny，三层保险缺一不可。Cedar 的语言级保证更彻底：default-deny、forbid 永远压过 permit、求值顺序无关。第三层是人审，关键在绑定：审批令牌签名的对象是精确参数而非"这次操作"，TTL 默认五分钟，高危操作叠加二次认证。第四层是下游自证：短生命周期能力令牌随调用下发（IETF Transaction Tokens 草案的 principal/actor 双身份模型），下游服务独立校验——纵深防御的意义在于上游被打穿时下游还有一道门。

工程细节里最容易被忽略的是 dispatcher 绕过：给模型一个万能 bash 工具，前面所有的按工具名策略都形同虚设。解法是在审批入口解析出逻辑调用对，与直连工具共用同一套规则，解析不出的一律拒绝。

4.4 并发治理：有界扇出与幂等账本

模型一轮发起八个并行工具调用是常态，并发治理的目标是让这种自由不至于失控。有界扇出的第一原则：信号量上限对齐最慢下游的并发配额，而不是模型发起的数量；起点 4–8，观察限流信号再调。重试要先分类再动手：429 和 503 属瞬时可重试（全抖动指数退避，尊重 Retry-After），401/404 重试纯属烧钱；实测 Agent 工具调用的重试率高达 15–30%，因为 SDK 层、运行时层、模型自发重试会叠罗汉——不分类的重试策略在这种基数下是灾难放大器。熔断阈值参考值 5 次失败，分布式部署用 Redis 共享计数防止跨实例级联。

幂等是其中最深的一坑。重复调用的来源有四个：SDK 重试、包装层重试、运行时步骤重试、以及模型自己重发（结果被截断时它不确定动作是否落地）。正确的键由编排器派生——(agent_run_id, step_id, tool_name, business_scope)——而不是参数哈希：模型"再试一次"时金额四舍五入了、memo 变了一个词，哈希一变，防重瞬间失效。执行前查账本、执行后记账，顺序不能反；并发去重靠唯一约束加 PENDING 行仲裁，先插入者执行、冲突者等待结果。还要认清 durable execution 引擎的边界：Temporal 们保证的是 at-least-once 重放，不保证外部世界只见一次副作用——LangGraph 从 interrupt 恢复时会重放中断前的节点，中断之上的 send_email 就这样发出去两次。账本永远承重。最后留一个遥测钩子：去重命中率突然飙升，往往是网络抖动或模型进入重规划循环的最早信号。

4.5 攻防现实：注入无法阻止，只能围堵

把过去两年的真实案例摆在一起，模式惊人地一致。EchoLeak（CVE-2025-32711，CVSS 9.3）：恶意邮件被企业助手检索进上下文，数据被编码进 markdown 图片 URL，客户端自动加载图片完成外泄——全程零点击。Claude Code 的 CVE-2025-55284：仓库文件里的恶意指令诱导读取 .env，密钥编码进 DNS 子域查询外泄，而 ping/nslookup 属于"被允许的网络调用"。Files API 攻击更诛心：白名单里的 api.anthropic.com 本身成了外泄通道——allowlist 上每个可达函数都是攻击面。CSA 把这类攻击归纳为混淆代理四阶段：注入 → 上下文污染 → 凭证放大 → 权限再委托，第四阶段让危害沿着子代理链和代码仓库继续扩散。

防御体系围绕 Willison 的"致命三联"展开：私密数据 × 不可信内容 × 外部通信，三者齐备才有泄漏，打断任何一条腿即可。饿死读取：凭证永不进入上下文，放在模型外的 resolver 里仅在授权调用点注入。约束出口：agent 进程物理断网（仅设置 HTTPS_PROXY 不够，注入可以 unset 环境变量），全部流量过扫描代理——DLP 要做多轮解码对抗（base64→hex→URL 套 3–5 层）、跨请求熵预算防分片慢渗、DNS 解析前扫子域名。控制与数据分离：CaMeL 架构在 AgentDojo 上做到 77% 任务成功率加可证明安全；污点追踪方案（如 Palizade）给工具输出按来源打标，污点数据流入写/发送/删除类 sink 时按策略阻断；MDPI 2026 年的实测把信息流标签 PEP 的数字钉在了桌面上——攻击成功率从 40% 压到 5%，单次调用开销约 0.6ms。

诚实的边界必须写明：2026 年 1 月一项覆盖 78 项研究的元分析显示，自适应注入对 SOTA 防御的成功率仍超过 85%，EchoLeak 当年就绕过了微软自家的 XPIA 分类器。结论不是绝望而是重新排布承重墙：输入过滤只是纵深防御的一层，真正的承重墙是身份作用域（ASI03）、供应链固定（ASI04）、调用策略（ASI02）和沙箱（ASI05）。注入无法阻止，只能围堵。

---

5. 对接推理后端：PyTorch 服务栈里的 Agent 流量

Runtime 的每一次"想一下"，都是对推理服务的一次 HTTP 请求。前四章把循环、状态、工具讲完，现在往下钻一层——这一层是 PyTorch 的主场，而且正在被 Agent 流量反向改造。

5.1 全景数据通路

自上而下过一遍这条链路，注意每个环节上 Agent 特有的压力点。torch.compile 在 vLLM V1 里是默认开启的核心组件：Dynamo 捕获全图（注意力算子被包装成 custom op 以保持整图捕获），再按注意力位置切成 piecewise 子图交给 Inductor 编译成 Triton 内核。所有编译在服务启动前完成，请求永远不会触发编译——这是延迟确定性的底线，编译产物缓存在 ~/.cache/vllm/torch_compile_cache/ 可以整体分发。CUDA Graph 则精细到按批次形态分派：2026 年的设计里 CUDAGraphMode 枚举区分 PIECEWISE / FULL / FULL_DECODE_ONLY / FULL_AND_PIECEWISE（现默认），各注意力后端声明自己的图捕获支持等级，FA3 是 ALWAYS，FlashInfer 只到单 token decode。对 Agent 负载的含义很直接：decode 阶段靠 full graph 快速重放吃延迟红利，但每轮工具返回后的新 prefill 与混合批次会跌回 piecewise 甚至 eager 路径——Agent 流量反复触发这种切换，比 chat 流量更难待在快车道上。

5.2 Agent 流量画像：它不像聊天

vLLM 与 Mooncake 联合发布的分析（2026 年 5 月，基于 Codex 真实 trace）给出了量化画像：输入输出 token 比 131:1；第 30 轮时上下文约 80K token，最长超过 180K；每轮新增不过几百到几千 token，其余全是可复用前缀。另一项会话级状态化推理研究（arXiv:2605.26289）测得五轮 Agent 对话中 85–95% 的 prompt 与上一轮完全相同。

调度的压力同样具体。AgentSysBench（arXiv:2608.15127）实测同一引擎上 batch 从 1 涨到 4，TPOT（每 token 生成耗时）从 7ms 涨到 30ms——工具暂停期间会话占着 KV 块却没有计算，GPU 出现空泡，而短生成让 decode 批次长期凑不满。结论可以一句话说尽：瓶颈从解码吞吐迁移到了前缀复用、调度效率与工具往返等待。这解释了为什么 2026 年推理栈的创新几乎全部围着"会话"打转。

5.3 前缀缓存：把 O(n) 变成 O(Δ)

第 3.6 节的前缀设计纪律在这里兑现为命中率。机制上两条路线：vLLM 用内容哈希管理 16-token 块（v0.11 起默认 sha256，防碰撞），只缓存满块——这意味着追加在块中间的工具输出会让最后一块不参与命中，前缀命中以块粒度截断；SGLang 的 RadixAttention 按 token 粒度建 radix 树，共享前缀的命中率天然更高，2026 年又补了两刀——Unified Radix Cache 让一棵树同时服务混合注意力模型的多种状态，Session-Aware Radix Cache 用 session_id 软引用保护活跃会话的 KV 不被内存压力驱逐。

收益的量级由 Mooncake 的数字定义：单实例本地缓存在真实 Agent 负载下命中率只有 1.7%（100K token 的 FP8 KV 约 3.8GB，本地很快饱和驱逐，轮转路由又造成跨实例 miss）；把它改成经 RDMA 共享的分布式 KV 池后命中率升到 92.2%，换来吞吐 3.8 倍、P50 TTFT 降低 46 倍、端到端延迟降低 8.6 倍，且在 60 卡规模上保持近线性扩展。学术侧的 CacheScout（arXiv:2608.14624）进一步指出反应式 LRU 驱逐在多 Agent 场景下的自我踩踏问题——Agent B 的缓存块挤掉 Agent A 正在等待复用的锚点——学习式驱逐加预取能再加 10–18 个百分点的命中率。这些数字合起来指向同一个架构判断：Agent 时代的 KV 缓存正在从"引擎内部优化"升格为"独立于计算实例的状态基础设施"，就像数据库连接池之于应用服务器。

5.4 调度：连续批处理遇上工具暂停

连续批处理和 chunked prefill（默认 2048 token 一片，长 prompt 切片与 decode 混批）解决的是 chat 时代的问题；面对"短生成 + 长工具暂停"的流量形状，2026 年的答案是把调度单位从请求升级为会话。Sutradhara（arXiv:2601.12967）在 vLLM 上实现工具执行与下一轮 prefill 的重叠——工具结果流式回填、prompt 分段提交——同等延迟下承载能力提高 77%。KVFlow、SAGA 一类工作则直接把 DAG 感知引入调度器。指标语言也要更新：TTFT（首 token 时间）、TBT（token 间隔）、TPOT（单 token 耗时）三件套之外，Agent 场景真正关心的是回合级端到端延迟，它被工具往返时间和排队深度主导，而非任何单个 token 的速度。

5.5 结构化解码：函数调用的硬保证

函数调用要求模型输出严格合法的结构化参数，采样期的 logit 掩码提供了数学级别的保证：不满足语法的 token 概率置零。工程价值取决于掩码生成的速度，这正是 xgrammar（MLSys 2025 论文）改写格局的地方——它把词表分成可预计算的上下文无关部分和需运行时检查的上下文相关部分（JSON 语法下后者不到词表的 1%，Llama-3.1 的 128K 词表里只有 1134 个），配合与 GPU 解码重叠执行，做到每 token 低于 40 微秒，比 Outlines 快 3 到 100 倍，端到端最高 80 倍。2026 年的 XGrammar-2 补上了 Agent 场景的关键短板：工具调用意味着 schema 频繁切换，旧方案每次重编译要一秒以上，新方案压到约 10ms，同时把 JSON schema 合规率从 66.95% 提到 100%。vLLM 的 structured_outputs 接口默认在 xgrammar 与 guidance 之间自动选择；Outlines 的集成实测有 8–12% 的延迟开销——对每轮都要结构化输出的 Agent 来说，这个差距就是选型依据。

5.6 投机解码与 P/D 分离

投机解码与 Agent 负载是天作之合，只是配对方式有点反直觉。高并发吞吐场景下投机解码收益有限（batch 已经很大，验证成本摊不薄），但 Agent 循环恰恰是低并发、延迟敏感、生成偏短的画像——正是官方文档标注的投机解码最优区间。方法选择上，ngram/suffix 类提示查找投机尤其契合：工具结果、“continue”、schema 前导在会话内高度重复，直接从输入历史里匹配草稿 token，无需额外模型。

Prefill/Decode 分离则回应另一个形状问题：180K 前缀的 prefill 洪峰如果和 decode 挤在同一批 GPU 上，TTFT 和 TPOT 互相拖累。分离部署下 prefill 实例算完 KV 经 RDMA 推给 decode 实例（Mooncake Connector 是生产推荐路径），decode 实例保持满批次稳定出字。对 Agent 的意义在于：每轮工具返回触发的长上下文重编码被隔离在 prefill 层，用户感知到的 TPOT 不再被前缀长度绑架。2026 年的趋势是 P/D 分离与分布式 KV 池合流——反正 KV 都要跨实例流动了，传输与复用共用一套基础设施。

5.7 2026 年的引擎格局

这一年推理栈最大的新闻是一条否定句。TensorRT-LLM 1.0（2025 年 9 月）的 release notes 白纸黑字：移除 TensorRT 编译后端，PyTorch 成为唯一执行路径——trtllm-build 等 CLI 全部删除，冷启动从 28 分钟的离线编译降到 60–90 秒。NVIDIA 保留的是自家定制内核（FP8/FP4/MoE 优化），但图的捕获、编译、执行全部回到 PyTorch 生态。加上 vLLM 已托管至 PyTorch Foundation（采用率实证研究中以 1821 个仓库遥遥领先），"PyTorch 作为推理运行时底座"这件事不再需要论证，需要讨论的只剩上层引擎怎么选：

引擎	定位	相对优势	注意事项
vLLM	事实标准，社区最广	特性最全：投机 decoding 全谱、P/D 分离、结构化输出	块粒度前缀缓存对超长共享前缀略逊
SGLang	前缀密集型负载专家	Radix 树 token 级复用，第三方实测 prefix-heavy 吞吐高 ~29%	FlexAttention 后端尚有限制（page_size=1 等）
TensorRT-LLM	NVIDIA 单模型极限吞吐	第三方实测较 vLLM 同配置吞吐高 32–40%	绑定 NVIDIA；灵活性换性能
TorchServe	管理层而非内核层	v0.12 起内嵌 vLLM/TRT-LLM 作执行引擎，补版本管理与运维	不要拿它和引擎比推理速度

第三方基准数字（16,200 vs 12,500 vs 17,500 tok/s 一类）来自厂商与测评机构，引用时注明条件即可，不必当真理供起来。

5.8 端侧延伸：ExecuTorch

云端故事讲完，看一眼边缘。ExecuTorch 到 2026 年 8 月已迭代到 v1.4：基础运行时仅 50KB，Meta 自家的 Instagram、WhatsApp、Quest 3 和 Ray-Ban 眼镜在生产环境跑着它，后端覆盖 CPU（XNNPACK）、Apple Neural Engine、高通 Hexagon、Arm Ethos-U 直到桌面 Vulkan。与 Agent 相关的两个信号值得记录：CUDA 后端开始支持图捕获重放（端侧也在 graph 化），以及 v1.4 给 GenerationConfig 加了 grammar 字段——约束解码正式登陆端侧，意味着手机上的小模型 Agent 也能获得函数调用的硬保证。当然要泼的冷水也得泼：端侧性能强依赖模型与后端的组合，官方从不承诺通用加速倍数；on-device 工具生态仍在早期。端云协同的 Agent Runtime（本地轻循环 + 云端重推理）是未来两年的看点，现在下注为时尚早但值得跟踪。

---

6. 多智能体运行时：协调的成本

6.1 编排拓扑

三种拓扑对应三种控制流哲学。监督者模式把决策集中在一个协调代理手里，OpenAI 的 handoffs 和 LangGraph 的 Send API 都是它的实现；去中心移交源自 Swarm（README 已明确声明被 Agents SDK 取代，但移交语义留了下来），控制权像接力棒一样传递，没有中央大脑；层级模式里 CrewAI 自动生成一个 manager，把其他代理当作工具调用。Claude Code 走了第四条路：子代理是完全隔离的新会话，父代理只拿到最终消息作为工具结果，中间过程全部留在子代理内部——用上下文隔离换取主线的干净，并发上限默认 20，深度、花费分别设帽。Workflow 工具进一步把编排逻辑本身移出对话上下文、作为脚本执行，避免编排步骤本身撑爆窗口。

6.2 黑板还是信箱

共享状态的祖师爷是黑板模式：Hearsay-II 语音理解系统（1970s）到 BB1（1984）确立的三件套——分层黑板、互不通信的知识源、机会式调度器——今天在 Letta 的共享 memory blocks（多个代理引用同一 Block，一处修改处处可见）和 LangGraph 的类型化通道（写入经 reducer 串行化）里都能认出来。消息传递路线则保持代理间的边界干净。

MAST 研究（1600+ 条真实轨迹、7 个框架）给了这场争论一个刺眼的数字：约 37% 的失败源于代理间错位——交接时扣留信息、忽略输入、假设不相容；算上本可通过共享状态暴露的规格失败，过半失败本质上是协调失败。机理不难理解：每条代理间消息都是模型在 token 压力下的一次有损重述。实践建议因此偏向保守：默认用消息传递保边界清晰；确需共享时，用类型化通道加 reducer 把并发写串行化，别让两个代理裸写同一份自由格式状态。

---

7. 可观测性：看住一个不确定的系统

传统系统的调试单元是请求，Agent 的调试单元是轨迹（trajectory）：一次任务 = 多次推理 × 多次工具调用 × 可能的中断恢复。OpenTelemetry GenAI 语义约定（2026 年仍处 Development 阶段但已被广泛采纳）为此规定了标准的 span 层级：

约定里有几个容易被漏看的细节：内容默认不采集（隐私优先，采集要显式开启）；影响采样决策的属性必须在 span 创建时就位；工具执行的 span 名约定为 execute_tool {tool_name}，这让跨团队、跨厂商的轨迹可以互相拼接。平台侧，LangSmith 与 Langfuse 都已兼容 OTLP 摄取，前者单条 trace 上限 25,000 条 run，后者的 observation 类型原生区分 generation/tool/retrieval。

实战中丢 span 的六个惯犯值得贴在工位上：工具绕过注册表被裸调用；asyncio.create_task 不继承 contextvars 导致孤儿 span；异常被 except: pass 吞掉只剩半个 span；serverless 进程退出前没 flush；代码执行类工具内部的调用完全隐形；SDK 版本钉死在 execute_tool 约定发布之前。可观测性的投入回报周期很长，但它决定了一件无法外包的事：当老板问"为什么它删了那张表"，你有没有能力在十分钟内拿出完整证据链，而不是一句"AI 干的我也说不清"。

---

8. 选型指南：一张表做决策

先给结论的使用姿势：协议押注大于框架押注。MCP 和 A2A 这类协议的生命周期长于任何单个框架——AutoGen 从明星项目到维护模式用了两年，而 MCP 已经穿过了三个框架世代。框架层面，按控制权需求排序：

你的处境	建议
快速验证产品想法	OpenAI Agents SDK 或 Claude Agent SDK，循环、审批、追踪开箱即用
需要复杂状态机、时间旅行调试、强持久化语义	LangGraph，checkpointer 体系目前无对手
已有 AutoGen 存量	制定迁移计划，微软官方迁移路径指向 Agent Framework
极简主义、想彻底掌控每行代码	smolagents（千行核心）或徒手 Loop + 自建 Runtime 组件
团队角色分工明确的流水线业务	CrewAI 的角色抽象贴合心智
企业级托管、不想养基础设施	AWS AgentCore 一类 Harness + Runtime 组合

无论选哪条路，四件事建议尽早自有而不是等框架施舍：检查点存储（Postgres 先行）、策略引擎（OPA/Cedar sidecar）、OTel 追踪埋点、幂等账本。这四样是与框架解耦的资产——框架会换代，它们不会。

---

9. 未竟之路

几个问题的开放程度足以定义未来两年的工作议程。

评估与回归。 非确定性循环怎么做回归测试？LangGraph 的 fork 语义提供了一条务实路径：把历史 checkpoint 当测试夹具，修补中间状态后断言后续行为——Agent 版的金丝雀测试还在成形期。

自适应对抗。 85% 的绕过率意味着攻防天平仍在攻击方。污点追踪、信息流标签这类确定性机制是当前最硬的牌，但它们的覆盖面（哪些 sink 该拦、标签如何跨子代理传播）远未收敛。

状态经济学。 无界增长的 checkpoint 表、按 GB 计的 KV 池、压缩本身的 token 成本——状态管理的每一层都有账单，目前没有哪个框架给出过完整的成本模型。谁先把"每会话状态成本"做成一等公民指标，谁就拿到了下一个话语权。

多运行时互操作。 A2A 与 AG-UI 协议在尝试让不同厂商的 Agent 互相发现、通信、交接流式事件，但语义鸿沟（各自的审批模型、状态格式都不相同）还横在中间。协议统一之日，才是 Agent 互联网真正开工之时。

---

10. 结语

操作系统用三十年完成了三部曲：资源虚拟化让程序以为自己独占机器，保护隔离让恶意程序伤不了邻居，稳定抽象让 1960 年代的代码还能跑在今天的硬件上。Agent Runtime 正在重演这三部曲，只是难度全面升级——它的"进程"会自己写代码，它的"系统调用"要由策略裁决，它的"内存"按 token 计费，它的"用户"随时可能被一段藏在工作票里的文字说服去做任何事。

这也是为什么本文坚持系统视角而非框架视角。框架会像 AutoGen 一样退场，协议会像 MCP 一样登基，唯一不变的是那组老问题：状态放哪里、权限谁来裁、失败怎么恢复、行为如何审计。回答好这四个问题的那一层软件，不管叫什么名字，都是 Agent 时代真正的操作系统。

---

附录：参考资料

规范与官方文档

• Anthropic Context Management（compaction / context editing / memory tool）：platform.claude.com/docs/en/build-with-claude/compaction · …/context-editing
• Prompt Caching 机制与定价：platform.claude.com/docs/en/build-with-claude/prompt-caching
• Claude Code 内部循环与会话格式：code.claude.com/docs/en/how-claude-code-works#the-agentic-loop · …/sessions
• OpenAI Agents 文档（Running agents / Compaction / Conversation state）：developers.openai.com/api/docs/guides/agents/running-agents · …/guides/compaction
• LangGraph Checkpointers / Persistence / Store：docs.langchain.com/oss/python/langgraph/checkpointers · …/persistence
• AWS Bedrock AgentCore Runtime 服务契约与架构说明：docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-service-contract.html · amazon.science/blog/demystifying-agents
• OTel GenAI 语义约定：github.com/open-telemetry/semantic-conventions-genai
• OWASP Agentic Top 10 (2026) 与 AI Agent Security Cheat Sheet：genai.owasp.org · cheatsheetseries.owasp.org
• vLLM 设计文档（prefix caching / CUDA graphs / torch.compile / speculative decoding / disagg prefill）：docs.vllm.ai/en/latest/design/
• SGLang Session-Aware Radix Cache 与 Unified Radix Cache 博客：docs.sglang.io · lmsys.org 博客（2026-08）
• TensorRT-LLM v1.0 Release Notes（PyTorch-only 后端）：github.com/NVIDIA/TensorRT-LLM/releases/tag/v1.0.0
• PyTorch FlexAttention 系列（FlexAttention / FlexDecoding / FA4 后端）与 ExecuTorch v1.4 Release：pytorch.org/blog · github.com/pytorch/executorch/releases/tag/v1.4.0

论文

• ReAct: Synergizing Reasoning and Acting in Language Models（arXiv:2210.03629）
• MemGPT: Towards LLMs as Operating Systems（arXiv:2310.08560）
• Zep: A Temporal Knowledge Graph Architecture for Agent Memory（arXiv:2501.13956）
• XGrammar: Flexible and Efficient Structured Generation Engine（MLSys 2025）；XGrammar-2（arXiv:2601.04426）
• SGLang: Efficiently Programming Large Language Models using SGLang（arXiv:2312.07104）
• MAST: Multi-Agent System Failure Taxonomy（arXiv:2503.13657）
• AgentSysBench: agentic workload characterization（arXiv:2608.15127）
• CacheScout: learning-based prefix cache management（arXiv:2608.14624）
• Stateful Inference for Multi-Agent Tool Calling（arXiv:2605.26289）
• Sutradhara: overlapping tool execution with prefill（arXiv:2601.12967）
• LLM Serving in the Wild（arXiv:2608.03036）

源码锚点（commit 固定链接）

• OpenAI Agents SDK 循环实现：openai/openai-agents-python @ 2334679 — src/agents/run_internal/run_loop.py（run_single_turn）、turn_resolution.py（NextStep* 判定）
• LangGraph Command / interrupt / Pregel：langchain-ai/langgraph @ f09cfe8 — libs/langgraph/langgraph/types.py、pregel/_loop.py
• AutoGen 单线程 actor 运行时：microsoft/autogen @ 027ecf0 — python/packages/autogen-core/src/autogen_core/_single_threaded_agent_runtime.py
• smolagents CodeAgent 循环：huggingface/smolagents @ 30bb116 — src/smolagents/agents.py（MultiStepAgent.step）
• CrewAI 编排：crewAIInc/crewAI @ f4731f5 — lib/crewai/src/crewai/crew.py（kickoff / process 调度）
• Swarm 弃用声明与循环伪代码：openai/swarm @ 6af0b4c — README.md
• mem0 存储层：mem0ai/mem0 @ 8d5b786 — mem0/memory/storage.py
• Graphiti 时序图谱：getzep/graphiti @ 993e081
• xgrammar：mlc-ai/xgrammar；Firecracker 规格书：firecracker-microvm/firecracker SPECIFICATION.md
• gVisor：google/gvisor；wasmtime：bytecodealliance/wasmtime

注：文中标注"第三方实测"的吞吐与时延数字（如 SGLang 16,200 tok/s 对比项）来自 2026 年公开评测，实验条件各异，仅供数量级参考。