Runtime：模型之外，Agent 真正活着的那一层

---

Anthropic 做 Claude Managed Agents 的第一版时，把三样东西塞进了同一个容器：会话记录、Agent 循环（harness）、执行代码的沙箱。

这个设计很自然，也很快出了问题。容器成了一只「宠物」：挂了，会话就丢了；要调试，就得进到装着用户数据的容器里；客户想让 Claude 访问自己 VPC 里的资源，只能把网络和 Anthropic 打通，因为 harness 默认「要干活的东西都在我旁边」。更隐蔽的是性能：每个会话不管用不用沙箱，都得先等容器拉起、仓库克隆完，模型才能开始推理。

后来他们把这三样拆成了三个接口：session 是一条只追加的事件日志，brain 是 Claude 加 harness，hands 是沙箱和工具。拆完之后，首 token 延迟 P50 降了约 60%，P95 降了 90% 以上；沙箱死了就重新 provision 一个，harness 死了就 wake(sessionId) 从日志里接着跑。

这件事里没有一行是关于模型能力的。它讲的全是另一个问题：一个非确定性的循环，要在确定性的工程系统里长期、安全、可恢复地运行，需要什么样的底座。

这个底座，就是 Agent Runtime。

这篇文章想把 2024 年到 2026 年这一层上公开的东西系统地梳理一遍：论文（AIOS、Autellix、Continuum、CaMeL 等）、各家工程博客（Anthropic、OpenAI、LangChain、Manus、Cloudflare、AWS）、开源实现（Codex、LangGraph、Temporal 集成、各类沙箱）。目标不是列清单，而是讲清楚每个子系统为什么存在、各家在哪里做了不同的取舍、哪些地方至今没有答案。最后会给一个能跑的最小 Runtime，用崩溃恢复把前面的概念串起来。

数字和接口名都尽量来自一手资料，出处列在文末。

---

一、先把词说准：Framework、Harness、Runtime、Sandbox

这四个词在 2026 年仍然经常被混用，连 AWS 自己都把 AgentCore Runtime 和 AgentCore Harness 放在同一个品牌下。先拆开。

Framework 是写循环的零件库：模型适配、工具 schema、状态、图或工作流。LangGraph、CrewAI、Mastra、Pydantic AI、Google ADK 属于这一类。它把控制流的决定权留给你。

Harness 是别人已经写好的循环，连系统提示词、工具集、上下文管理一起交付。Claude Code / Claude Agent SDK、Codex、OpenCode、Deep Agents、DeepSeek Harness 属于这一类。LangChain 的 Vivek Trivedy 在 2026 年 3 月给了一个流传很广的定义：Agent = Model + Harness，不是模型的部分都算 harness。

Framework 和 Harness 其实占的是同一层：前者是自己造循环，后者是采用现成的循环。

Runtime 管的是循环之外的时间维度。camelAI 在 2026 年 10 月的一篇文章里说得很精确：harness 跑的是一个 turn，runtime 跑的是 Agent 的一生。它负责五件事：

• 状态：历史、文件、待办工作存在任何一个进程之外；
• 身份：稳定的 ID，同一个用户、工单、线程每次都找到同一个 Agent；
• 唤醒：消息、定时、Webhook、审批结果到来时启动工作，不需要有进程在那儿等；
• 伸缩：大多数 Agent 睡着，少数醒着，醒着的放到有空间的机器上；
• 恢复：记录下来的进度足以让中断的 turn 续上，或者至少准确报告停在哪。

Sandbox 隔离的是模型写出来的代码，不是你的代码。E2B、Modal、Daytona、Vercel Sandbox、Cloudflare Sandboxes 属于这一类。

这张图有三处要注意。

第一，Framework 画成了虚线框、放在旁边，因为它不是独立的一层：用 LangGraph 写出来的那个循环，本身就是一个 Harness。所以「我们用 LangGraph，不用 Claude Agent SDK」这个选择，是在同一层里二选一，不是叠两层。

第二，Harness 和 Runtime 的分界线是时间。Harness 关心的是「这一个 turn 里模型调了几次、工具怎么执行、上下文满了怎么办」；Runtime 关心的是「这个 turn 结束之后，下一个 turn 可能在三天后、在另一台机器上、由另一个版本的代码执行，Agent 怎么还是同一个 Agent」。

第三，Sandbox 从 Harness 引出、挂在旁边，因为它服务的是模型生成的代码。你自己写的工具代码可以跑在受信环境里，模型写的 rm -rf 不行。

这篇文章里的「Agent Runtime」取一个稍宽的口径：从模型输出 token 之后、到 token 变成真实世界的副作用为止，以及在两次调用之间让 Agent 继续存在的全部基础设施。具体包括循环的执行语义、会话与状态、持久执行、上下文调度、工具与协议、沙箱、安全、编排、推理服务的配合、可观测和部署。Harness 里的提示词和工具设计不是重点，但它们和 Runtime 的边界会反复出现，因为很多 Runtime 决策就是为了支撑它们。

---

二、为什么 Agent 需要一个专门的 Runtime

Web 服务有成熟的运行时：请求进来、处理、返回，进程无状态，状态在数据库。批处理有调度器和重试。工作流引擎有 DAG 和补偿。Agent 看起来像这三者的混合体，但它的负载特征把每一种现成方案都推到了边界之外。

时间尺度跨了六个数量级。 Cloudflare 的 Agents 文档列过一张表：等用户输入是秒到天，等 LLM 是秒到分钟，等工具是秒到小时，等人工审批是小时到天，定时唤醒是分钟到月。一个 99% 时间在睡觉、1% 时间在干活的 Agent，放在常驻 VM 上就得付 100% 的钱。HTTP 请求的超时模型、进程常驻模型，在这里都不成立。

核心步骤是非确定性的。 同一段上下文，模型两次输出可能不同。这对恢复是致命的：传统工作流引擎靠「重放确定性代码」恢复状态，Agent 的下一步却不能靠重算得到。唯一的办法是把模型的输出当成外部输入记下来。

副作用由模型触发。 发邮件、改数据库、提交代码、下单——这些动作的决定者是一个可能被提示注入的组件。Runtime 必须假设决定者不可信，权限和审批不能交给它自己判断。

上下文是稀缺且昂贵的资源。 输入 token 和输出 token 的比例在 Agent 场景里极度失衡（Manus 报告过约 100:1），KV-cache 命中与否价格差 10 倍。上下文怎么拼、怎么压、什么时候卸载到文件，本质上是内存管理问题。

执行的代码是不可信的。 模型会写代码、跑命令、装依赖。这些代码可能有 bug，也可能是攻击者通过网页内容间接写进来的。

多租户且有状态。 每个用户、每个工单、每个线程都可能对应一个长期存在的 Agent，状态彼此严格隔离。

把这几条和已有系统对照一下：

维度	Web 服务	工作流引擎	Agent
生命周期	毫秒到秒	分钟到天	秒到月，大部分时间在等
控制流	代码写死	DAG 预先定义	模型每一步现场决定
步骤确定性	确定	要求确定	核心步骤非确定
副作用发起者	受信代码	受信代码	可能被注入的模型
主要资源	CPU、连接	队列、存储	上下文窗口、KV-cache、GPU
执行内容	自己的代码	自己的代码	模型生成的代码

最后两行是 Agent 独有的。前四行每一行都有现成技术可以借，但借过来都要改。

这也解释了为什么 2025 到 2026 年这一层的产品井喷：AgentCore Runtime、Claude Managed Agents、OpenAI Agents SDK 的 sandbox harness、Cloudflare Project Think、LangSmith Deployment，以及 Temporal、Restate、Inngest、DBOS 这类持久执行引擎纷纷推出 Agent 集成。Hermosa AI 在 2026 年整理的一份目录里，光托管 Runtime 就有 25 个。

---

三、参考架构：把 Runtime 拆成可替换的接口

把各家的设计叠在一起看，一个完整的 Agent Runtime 大致由这些部分组成：

按一次请求的路径从上往下读这张图：

1. 各种事件（用户消息、Webhook、定时器、审批结果）先到 Control Plane。它只做一件核心的事：把事件映射到一个会话 ID，并决定唤醒哪个 Brain 实例来处理。配额、预算、版本灰度也在这里拦；
2. Brain 被 wake 起来时手里什么都没有。它从 Session Log 读事件，由 Context Engine 投影成模型上下文，调用推理服务；
3. 模型要调工具，先过 Policy，再通过 execute() 交给 Action Gateway。需要执行代码的，网关再转给 Sandbox 池；
4. 每一步的输入输出都通过 emit 写回 Session Log。Brain 随时可以被杀掉，下一个实例从日志继续。

Session Log 和 Brain 之间画了两个方向的箭头，这是整张图里最重要的一对：Brain 只写日志、从日志读，自己不持有任何必须存活的状态。左下角的横切关注点不是独立服务，而是每个组件都要往外吐的数据。

Anthropic 在《Scaling Managed Agents》里把这套拆分的接口写得非常克制，值得原样记下来：

• 每只「手」都是一个工具：execute(name, input) → string。harness 不知道背后是容器、手机还是宝可梦模拟器；
• 沙箱挂了，harness 把错误当成工具调用失败交给 Claude，Claude 决定重试时调用 provision({resources}) 重新拿一个；
• harness 运行时通过 emitEvent(id, event) 把每个事件写进会话日志；
• harness 挂了，新的 harness 用 wake(sessionId) 拉起，getSession(id) 读回事件日志，从最后一个事件继续。

左右对照着看。左边的三个框画在同一个橙色容器里，任何一个出问题，另外两个跟着陪葬；而且三者之间的调用是进程内调用，没有接口，也就没法单独替换。右边每个部件之间只剩几个函数签名，Session 在 harness 之外，Hands 可以是一个沙箱、一个 MCP 工具，也可以是客户 VPC 里的一台机器。延迟改善来自一个很朴素的变化：Brain 不再需要等容器就绪才能开始推理，沙箱改成在第一次需要时才 provision。

他们给这个设计找了一个很老的参照物：操作系统。几十年前 OS 把硬件虚拟化成进程、文件这些足够通用的抽象，read() 不在乎底下是 1970 年代的磁盘组还是今天的 SSD。Managed Agents 想做的也是这件事：对接口的形状有主见，对接口背后跑什么没有主见。

这句话是理解整个 Runtime 领域的钥匙。后面每一节，都可以看成在回答「这个接口应该长什么样，背后有哪些实现可以替换」。

另一个参照是学术界的 AIOS（Mei 等，2024，Rutgers）。它把 LLM 当成 CPU 核心，在 Agent 应用和模型之间放一个内核，提供调度器、上下文管理器（支持生成过程的快照与恢复）、内存管理器、存储管理器、工具管理器、访问控制管理器，Agent 通过 execute_llm_syscall、add_memory、sto_rollback、check_access 这样的系统调用使用它们。AIOS 的具体实现没有成为工业标准，但它的模块划分和今天工业界的拆法几乎一一对应：调度器对应推理服务和 Control Plane，上下文管理器对应 Context Engine，访问管理器对应 Policy。

---

四、执行模型：Loop 不是 while True

所有 Agent 的内核都是 ReAct（Yao 等，2022）那个循环：推理、行动、观察、再推理。写成代码只有几行：

while True:
    resp = model(context)
    if not resp.tool_calls:
        return resp.text
    for call in resp.tool_calls:
        context.append(execute(call))

生产 Runtime 里，这几行要回答至少七个问题。

1. 一次调用的单位是什么。 OpenAI 在 Codex App Server 里定了三个原语，后来很多 harness 都沿用了这套词汇：

• Item：最小的输入输出单位，有类型（用户消息、Agent 消息、命令执行、文件 diff、审批请求等），有明确的生命周期：item/started → 可选的 item/*/delta 流式增量 → item/completed 带最终负载；
• Turn：用户一次输入引发的一整段 Agent 工作，里面可能有很多轮模型推理和工具调用；
• Thread：持久的会话容器，可以创建、恢复、分叉、归档。

这三层的价值在于让客户端可以在 started 时就开始渲染，而不必等工具跑完；也让「中断」「恢复」「分叉」这些操作有了明确的作用对象。

2. 通信是不是双向的。 Codex App Server 的 JSON-RPC 是全双工的：通常是客户端发请求、服务端发一串通知，但服务端也可以反过来向客户端发请求，例如 item/commandExecution/requestApproval，然后暂停这个 turn，直到客户端回复 allow 或 deny。审批不是 UI 层弹窗，而是协议里的一等公民。这一点决定了同一个 harness 能不能嵌进 IDE、桌面端、Web、CLI 而不各写一套审批逻辑。OpenAI 把这叫做「一个 harness，多个界面」。

时序图里有两个细节。客户端只发了三次消息（thread/start、turn/start、审批回复），服务端回了十几条通知，「一个请求、多条通知」是 Agent 协议和普通 RPC 最大的差异。红色那一段是服务端发起的请求：turn 在这里暂停，右侧竖条表示暂停的时长，可能是几秒，也可能是用户午饭回来。服务端要把这个暂停状态持久化，客户端断线重连之后，审批请求还得在。右侧的嵌套框说明三个原语的包含关系，一个 Thread 有多个 Turn，一个 Turn 有多个 Item，每个 Item 都走 started → delta* → completed。

3. 什么时候停。 正常终止是模型不再请求工具。异常终止要 Runtime 自己兜底：步数上限、token 预算、墙钟时间、连续失败次数、重复动作检测（同一个工具同样参数连续调用 N 次）。这些限制必须放在模型够不着的地方，因为模型「觉得自己快做完了」是最常见的失控方式之一。

4. 工具调用能不能并行。 模型一次返回多个工具调用时，Runtime 要决定是并行还是串行。Anthropic 的多 Agent 研究系统里，让子 Agent 一次并行调 3 个以上工具，加上主 Agent 并行拉起 3 到 5 个子 Agent，复杂查询的研究时间缩短了最多 90%。并行的前提是 Runtime 知道哪些工具没有相互依赖、没有写冲突；读文件可以并行，改同一个文件不行。LLMCompiler（Kim 等，2023）把这件事做成了显式的依赖图规划。

5. 用户中途插话怎么办。 模型跑到一半，用户又发了一句话。这句话是取消当前 turn 开新 turn，还是作为「转向」注入当前 turn 的下一次模型调用？主流 coding harness 普遍支持后者：把这句话排队到下一个安全点（例如一次工具调用结束后）再注入，同时保留显式中断当前 turn 的入口。安全点的概念很重要，在工具执行中间打断，可能留下半写的文件。

6. 流式输出是谁的责任。 模型 token 流、工具 stdout 流、状态变化事件，要合并成客户端能消费的一条事件流。Codex 的做法是 harness 内部有一条低层事件流，App Server 的消息处理器把它翻译成一小组稳定的、面向 UI 的通知。内部事件可以随便改，外部协议保持稳定。

7. 失败算谁的。 工具报错不应该让循环崩溃，而应该变成一条观察结果交还给模型，让它自己修正。这是 Manus 总结的经验之一：把错误留在上下文里，模型看到失败的动作和堆栈，会降低重复同样错误的概率。但 Runtime 自身的错误（模型 API 超时、沙箱丢失、存储写失败）要走另一条路径：重试、降级或挂起会话，不能直接喂给模型。

把这七个问题的答案放在一起，Loop 实际上是一个状态机：

蓝色的四个状态（PREPARING → INFERRING → OBSERVING 循环，加上 TURN_COMPLETED）是 ReAct 那几行代码本来就有的部分。黄色和绿色是生产 Runtime 加上去的：POLICY_CHECK 在模型和副作用之间插了一道闸；WAITING 是一个可以持续数天的状态，期间不应该占用任何进程；PROVISION 处理「手」丢了的情况，重新拿一个沙箱后回到 EXECUTING 重做这一步。红色箭头是 Runtime 自身的故障，它们在 Runtime 内部消化，不进入模型上下文；而工具自身的报错走底部那条灰线，作为观察结果交还给模型。

把循环建模成状态机的直接好处是：任何时刻 Runtime 都能回答「这个会话现在处于什么状态、在等什么」。这是挂起、恢复、超时检测、给用户展示进度的共同前提。

每一次状态迁移都写一条事件到会话日志。这个状态机本身也可以挂起和恢复，这就引出了下一节。

---

五、Session：事件日志才是真相，上下文只是它的投影

几乎所有成熟的 Runtime 最后都收敛到同一个设计：会话的权威来源是一条只追加的事件日志，模型看到的上下文是这条日志的一个投影。

Claude Managed Agents 的 session 是这样；Codex 把每个 thread 持久化成 rollout 文件，按事件逐条追加，恢复时重放；DeepSeek Harness 的架构文档也明确写了 Session Log 是系统的权威来源；OpenAI Agents SDK 的 Sessions、LangGraph 的 checkpoint 链，本质上也是同一思路的不同粒度。

为什么不直接存「当前的消息列表」？因为消息列表是有损的。

第一，上下文会被压缩。压缩之后，原始的工具输出、中间推理就从消息列表里消失了。如果只存消息列表，压缩就是不可逆的。存日志的话，压缩只是投影规则变了，原始事件还在，需要时可以重新读回。Anthropic 在分享 Managed Agents 时提到，会话日志承担了三重职责：可观测性；让 harness 在 Claude 丢弃某段上下文之后还能把它切片读回来；以及一个叫「dreaming」的周期性批处理，用日志去重写和整理记忆。

第二，日志能区分「发生了什么」和「模型知道了什么」。工具执行开始了、执行完了、审批请求发出了、审批通过了，这些是 Runtime 的事实；它们中哪些、以什么形式进入模型上下文，是另一层决定。

第三，日志让 harness 本身变成无状态的「牲口」。只要日志在，任何一个 harness 实例都能接手任何一个会话。这正是 Managed Agents 能把 harness 移出容器的前提。

状态要分层。 一个 Agent 的「状态」其实是四种东西，持久化要求完全不同：

层	内容	典型存储	生命周期
会话日志	消息、工具调用与结果、审批、状态迁移	追加写的表、JSONL、事件流	会话级，可归档
工作区	代码仓库、生成的文件、安装的依赖	沙箱文件系统 + 快照、对象存储挂载	会话级或跨会话
长期记忆	用户偏好、跨会话事实、学到的技能	KV/向量库、记忆文件	用户级
外部世界	发出的邮件、改过的数据库、提交的 PR	不归你管	永久

前三层是 Runtime 可以回滚的，第四层不能。整个持久执行问题，归根结底是前三层和第四层之间的一致性问题。

左边是日志，右上是这一轮真正发给模型的东西，中间的 project() 就是投影规则。几个对应关系值得逐条看：

• 第 #41 条 compaction 事件覆盖了 #1 到 #38，于是右边出现一条「压缩摘要」，但 #1 到 #38 在日志里一条没少。哪天发现摘要漏了关键信息，可以换一个投影规则重新生成；
• 第 #5 条工具输出有 38KB，进入上下文的只有头尾各 1KB 和一个文件路径。模型需要全文时自己去读文件，不需要时就不付这 38KB 的钱；
• 第 #6、#7 条审批记录了「谁批的」，这是审计需要的事实，但模型不需要知道审批人是 alice，所以不进上下文；
• 第 #43、#44 条沙箱丢失和重建，进上下文时变成一句「沙箱已重建，工作区从快照恢复」，让模型知道环境变过，避免它假设之前启动的后台进程还在。

右下角的四层状态里，绿线下面的三层 Runtime 能回滚或重建，红线下面的外部世界只能靠幂等和补偿。下一节专门讲这条红线。

工作区这一层在 2026 年变化最大。AgentCore Runtime 支持在会话 stop/resume 之间保留文件系统，装好的包和构建产物不用重来；OpenAI Agents SDK 引入了 Manifest 抽象，声明挂载哪些本地文件、输出目录在哪、从 S3、GCS、Azure Blob、R2 拉哪些数据；Cloudflare 的 Workspace 用 SQLite 加 R2 给每个 Agent 一个持久文件系统。共同的方向是：工作区是可声明、可快照、可在新机器上重建的，不再是某台机器上的一个目录。

长期记忆也逐渐从「向量库检索」转向「文件」。Claude Code 的 CLAUDE.md、Codex 的 AGENTS.md、各家的 skills 目录，本质上都是让模型用读写文件的方式管理自己的记忆。原因很朴素：模型非常擅长浏览文件系统，而文件天然可版本化、可审查、可以让人直接编辑。

---

六、持久执行：崩溃之后，哪些事可以重做

这是 Runtime 里最难、也最容易被宣传材料说错的一部分。

先定义失败模型。一个 Agent 会话在运行中可能遇到：进程被 OOM 杀掉、机器被回收、部署滚动重启、沙箱超时销毁、模型 API 返回 529、下游工具超时但其实执行成功了。前几种是「Runtime 死了」，最后一种是「结果不明」。持久执行要解决的是：Runtime 死了之后接着跑，并且不重复已经完成的副作用。

业界有两条技术路线。

路线一：Checkpoint（快照）。 在若干边界上把整个状态序列化存起来，恢复时加载最近的快照，从那个边界之后继续。LangGraph 是代表：每个 super-step 结束生成一个 checkpoint，按 thread_id 串成链，恢复时用同一个 thread_id 调用即可。它在 v0.6 引入了三种 durability 模式：

• sync：下一步开始之前同步写完 checkpoint；
• async：下一步执行的同时异步写，崩溃时有小概率丢最后一个 checkpoint；
• exit：只在图退出时写，性能最好，但进程中途崩溃无法恢复。

路线二：Journal + Replay（日志重放）。 不存整个状态，而是记录每一个非确定性操作的结果。恢复时从头重新执行代码，遇到已经记录过的操作，直接返回记录的结果而不再真正执行。Temporal、Restate、DBOS、Inngest、Cloudflare Workflows、AWS Lambda Durable Functions、Azure Durable Task 都是这一类。

Temporal 的模型最典型：Workflow 代码必须是确定性的，所有 I/O 都放进 Activity。Activity 的结果写进事件历史，Workflow 重放时直接读。2025 年 7 月，OpenAI 和 Temporal 发布了 Agents SDK 的官方集成，映射关系是：

Agent 中的东西	放在 Temporal 的哪里
Agent 循环、handoff、工具选择	Workflow
模型调用	Activity（集成自动处理，重放时不会重复调用）
做 I/O 的工具	activity_as_tool() 包成 Activity
纯计算工具	@function_tool，可以直接在 Workflow 里跑
人工审批	Workflow 等待，Signal 或 Update 送回结果

模型调用被当成 Activity，正好解决了「模型非确定」的问题：第一次调用的输出被记下来，重放时就是确定的数据了。

Restate 的风格更轻：普通的服务 handler 里用 ctx.run(...) 包住一个步骤，结果进 journal；还提供持久定时器、内置 KV 状态、幂等键，以及叫 awakeable 的持久回调，适合「等一个外部事件回来」这种场景。

两条路线不是互斥的。OpenAI Agents SDK 2026 年 4 月的更新里同时出现了「外部化的 Agent 状态」「快照」「在新容器里重建（rehydration）」，就是 checkpoint 思路用在沙箱层；而模型和工具调用层更适合 journal。

真正的难点：副作用的那条缝。 不管哪条路线，都有一个无法消除的窗口：

上半部分对比两条路线。左边 checkpoint 的粒度是「步」：蓝点是存档点，step 3 崩溃后，从 step 3 的第一行重新开始，step 3 里已经做过的事会再做一遍。右边 journal 的粒度是「每一个非确定性操作」：Workflow 里的代码每次恢复都从头跑，但跑到 Activity 时直接拿记录好的结果，所以只要 Activity 切得够细，重做的范围就很小。

下半部分是两条路线都绕不过去的时间线。从「外部已生效」到「记 step_done」之间那段红色区域，就是 Runtime 不知道真相的窗口。窗口可以缩短（比如下游同步返回后立即写日志），但不能消除，因为「调用外部系统」和「写自己的日志」不可能是同一个原子操作。

恢复时 Runtime 面对的是一个状态不明的步骤。重做，可能发两封邮件；跳过，可能一封都没发。

LangGraph 的文档对这一点很诚实，但很多人读漏了：恢复时，崩溃那一刻正在执行的节点会从第一行重新执行；interrupt() 之前的代码在审批回来时也会再跑一遍。社区里有人在 langgraph==1.2.14 上用 SQLite checkpointer 验证过这两条。LangGraph 仓库里的 issue #9240 专门要求在文档里写明：durability 模式只决定 checkpoint 何时持久化，不保证外部副作用恰好执行一次。

Temporal 也一样：Activity 的重试是「至少一次」。所以官方文档反复强调 Activity 要幂等。

所以「exactly-once」在 Agent Runtime 里只能靠组合拼出来：

1. 幂等键由 Runtime 生成。 键必须在重试之间保持不变，比如 session_id + step_id，并且作为参数传给下游。不能让模型生成，模型每次生成的值都可能不同。
2. 下游支持去重。 Stripe 风格的 Idempotency-Key，或者数据库里的唯一约束、去重表。
3. 下游不支持去重时，先对账再重试。 查一下邮件是否已在已发送列表里、订单是否已存在。查不到确定答案，就挂起会话交给人。
4. 把不可逆动作放在审批之后、并且单独成步。 审批前的代码可能重跑，所以审批节点之前不要放副作用。

状态不明时宁可停下。 这是本文最后那段最小 Runtime 的核心逻辑：如果一个步骤「开始过但没有完成记录」，可重试的就带着同一个幂等键重做，不可重试的直接报错要求人工对账。

持久执行还管「等」。 审批要等几天，定时任务要等几周。Temporal 的 workflow.wait_condition()、Restate 的 awakeable、Cloudflare 的 alarm、LangGraph 的 interrupt()，都是让会话挂起而不占计算资源，等事件到来再唤醒。没有持久等待的 Runtime，只能让进程一直挂着，或者自己写一套轮询表。

---

七、上下文调度：Runtime 里最贵的那块内存

如果把模型比作 CPU，上下文窗口就是它唯一的工作内存。Runtime 怎么往里装东西，直接决定延迟、成本和正确率。

7.1 KV-cache 命中率是第一指标

Manus 的季逸超在 2025 年写过一篇被反复引用的文章，开头就说：如果只能选一个指标，他选 KV-cache 命中率。理由是 Agent 的输入输出比约 100:1，每一步都要把越来越长的上下文重新喂进去；而带缓存的输入 token 价格（以 Claude Sonnet 为例 0.30 美元/百万 token）是不带缓存的十分之一（3 美元/百万 token）。

前缀缓存只认完全相同的前缀，所以 Runtime 层面要做到：

• 系统提示词稳定。 在开头放一个精确到秒的时间戳，会让每一次请求的缓存全部失效；
• 上下文只追加，不修改历史。 改了第 3 条消息，后面全部重算；
• 序列化必须确定。 很多语言的 JSON 序列化不保证 key 顺序，同样的对象两次序列化结果不同，缓存就没了；
• 显式标注缓存断点（在需要手动标记的 API 上），断点至少放在系统提示词结尾；
• 自部署推理时，同一会话的请求路由到同一个 worker，否则前缀缓存在别的机器上。

7.2 不要动态增删工具，用掩码

直觉做法是按需加载工具，用 RAG 选出相关的几个。Manus 试过，结论是除非绝对必要，不要在迭代中途增删工具：工具定义序列化后通常在上下文最前面，任何改动都会让后面全部缓存失效；而且历史里引用了已经不存在的工具，模型会困惑，容易产生 schema 违规或幻觉调用。

他们的替代方案是在解码时掩码：工具定义一直都在，通过约束解码限制当前状态下能选哪些。工具名用统一前缀（browser_、shell_），一个前缀就能圈出一组工具，不需要有状态的 logits 处理器。

这是 Runtime 和 Harness 边界的典型例子：Harness 决定「这个状态下只允许浏览器工具」，Runtime（推理侧）提供「按前缀掩码」的能力。

三条色带是同一个会话第 4 轮请求的三种拼法。第一条只有末尾新增的部分需要 prefill；第二条只是在系统提示词里多了一个秒级时间戳，整条请求变成全价；第三条在第 3 轮时按需换了一个工具，工具定义之后的所有轮次全部失效。会话越长，后两种拼法的浪费越大，因为被迫重算的是越来越长的历史。

如果确实需要让模型知道当前时间，放在上下文末尾的用户消息或工具结果里，而不是系统提示词里。

7.3 文件系统就是外部内存

128K 甚至 1M 的窗口在 Agent 场景里仍然不够，而且越长越贵、越长越不准（长上下文下模型表现下降，有人把这叫 context rot）。三个常用手段：

• 工具输出卸载。 LangChain 的 Deep Agents 对超过阈值的工具输出，只在上下文里保留头尾，全文写入文件系统，模型需要时自己去读；
• 可恢复的压缩。 网页内容可以丢掉，只要 URL 还在；文档内容可以丢掉，只要文件路径还在。压缩必须是可恢复的，否则就是在赌模型之后用不上；
• 渐进式披露。 Anthropic 在《Code execution with MCP》里把 MCP 工具组织成文件系统里的代码文件（./servers/google-drive/getDocument.ts），模型先 ls 看有哪些服务器，再读需要的那几个工具定义。一个案例里 token 从 15 万降到 2000，节省 98.7%。Cloudflare 把同样的思路叫做 Code Mode。Skills 机制（一个目录里放说明文件和脚本，只在用到时读全文）也是同一个原理。

7.4 压缩（Compaction）

上下文快满时，Runtime 必须做点什么，否则 API 直接报错。常见做法是让模型对已有历史做摘要，用摘要替换旧消息。OpenAI 在 Codex 里走得更远：调用 /responses/compact 端点，返回一个不透明的 encrypted_content 条目，承载模型对之前内容的「理解」，比文本摘要更紧凑。这是只有模型厂商能做的压缩，第三方 harness 做不到。

压缩是一个 Runtime 级的事件，要写进会话日志：压缩前的原始事件保留，压缩后的投影从这里开始。没有日志，压缩就是不可逆的信息损失。

7.5 注意力操控：复述与保留错误

Manus 的 Agent 平均一个任务约 50 次工具调用。它会创建一个 todo.md，边做边更新、勾掉完成项。这不是为了给人看，而是把全局目标反复「复述」到上下文末尾，对抗长上下文里的目标漂移（lost-in-the-middle）。

另一条是不要清洗错误。失败的调用和报错留在上下文里，模型会隐式更新自己的判断。把错误抹掉再重试，等于删掉了证据。

还有一条反直觉的：少样本示例在 Agent 里可能有害。上下文里充满相似的动作-观察对，模型会模仿这个节奏，哪怕已经不合适了。Manus 的办法是在序列化模板、措辞、顺序上引入少量受控的变化，打破过于整齐的模式。

7.6 跨越多个上下文窗口

压缩能延长一个窗口，但任务长到几小时、几天时，迟早要换一个全新的窗口。Anthropic 在《Effective harnesses for long-running agents》里描述了他们的方案，核心洞察是：让新窗口里的 Agent 能快速理解工作现状，靠的不是更好的摘要，而是外部化的工件。

方案分两种 Agent：

• Initializer Agent，只在第一个窗口跑一次，用专门的提示词搭环境：写一个 init.sh 启动开发服务；写一个 claude-progress.txt 记录做过什么；做一次初始 git 提交；把用户的需求展开成一份结构化的 JSON 功能清单。在 claude.ai 克隆的例子里，清单有 200 多条，比如「用户可以新建对话、输入问题、按回车、看到 AI 回复」，全部初始标记为 failing。
• Coding Agent，之后每个窗口都是它。开头先读进度文件和 git log，跑一遍基本测试，发现上一轮留下的未记录 bug；然后只挑一个功能做；结束时提交 git、更新进度文件。

他们列了两类典型失败及对策：

问题	对策
过早宣布整个项目完成	功能清单逐条标记，每次只做一条，必须端到端验证后才能改成 passing
环境留在有 bug 或进度不明的状态	开头读进度和 git log、跑冒烟测试；结尾提交并写进度

这里的 Runtime 含义是：跨窗口的状态载体是文件系统和 git，不是对话历史。Runtime 要保证工作区在窗口之间、甚至机器之间完整保留，这又回到了上一节的工作区持久化。

上排每个框是一个全新的上下文窗口，窗口之间没有任何对话历史传递，向右的箭头只表示时间顺序。真正把它们连起来的是下面那排文件：每个窗口开始时从这里读，结束时往这里写。这个结构其实就是第五节「日志是真相，上下文是投影」在更长时间尺度上的版本，只不过这里的「日志」由 Agent 自己维护，形式是人也能读懂的文件和提交记录。

对 Runtime 来说，这意味着窗口切换可以不再是 harness 内部的私事：Runtime 可以在压缩次数或 token 消耗达到阈值时主动结束当前窗口，用同一个工作区、同一份进度文件拉起下一个。

---

八、工具与协议：Action Gateway

模型说「我要调用 X」，到 X 真的被执行，中间隔着一层网关。这一层做的事比看上去多：

• Schema 校验：参数不合法直接拒绝，作为错误回给模型；
• 权限检查：这个会话、这个用户、这个 Agent 能不能调这个工具；
• 审批路由：需要人确认的，挂起并发审批请求；
• 凭证注入：工具需要的 token 在这里注入，不经过模型，也不进沙箱；
• 超时、重试、限流：防止一个慢工具拖死整个会话；
• 结果整形：截断、卸载到文件、脱敏，再交还给模型；
• 审计：每一次调用都落日志。

顶部的七个环节是有顺序的。Schema 校验放最前，是因为它最便宜，而且错误信息对模型最有用（「参数 path 缺失」比「权限不足」更容易自我修正）。凭证注入放在审批之后，保证被拒绝的调用连凭证都碰不到。结果整形放在审计之前，审计记录完整原文，模型拿到的是整形后的版本。

下面两块是 MCP 2026-07-28 版本里和 Runtime 关系最大的两项改动。

MCP：工具的垂直协议。 Model Context Protocol 是 2024 年底以来事实上的工具接入标准。2026 年 7 月 28 日发布的规范版本是一次破坏性升级，和 Runtime 关系很大：

• 无状态核心：去掉了 initialize/initialized 握手和 Mcp-Session-Id，每个请求通过头和 _meta 自带协议版本、客户端信息和能力。远端 MCP 服务器可以跑在普通的轮询负载均衡后面，按 Mcp-Method 头路由，客户端按服务器给的 ttlMs 缓存 tools/list；
• Tasks 扩展（io.modelcontextprotocol/tasks）：长任务不再阻塞一个连接。服务器对 tools/call 直接返回任务句柄，客户端用 tasks/get 轮询、tasks/update 中途补充输入、tasks/cancel 取消；状态经历 Working → Input_Required → Completed/Failed/Cancelled。任务状态存在外部存储里，任意服务器实例都能接手；
• 授权：远端服务器强制 OAuth 2.1 + PKCE，并要求 RFC 8707 Resource Indicators 防止 token 被拿去别的服务器重放；
• MCP Apps 扩展：服务器可以下发交互式 UI，在宿主控制的沙箱里渲染。

MCP 去状态化之后，「会话状态归谁」的答案变得很清楚：归 Agent Runtime，不归工具协议。需要跨调用保持的东西，用显式的句柄作为参数传递。

Tasks 扩展和第六节的持久等待正好接上：Agent 调用一个耗时 20 分钟的 CI 工具，拿到任务句柄 t-42 后，Runtime 把句柄写进会话日志，会话进入等待状态、释放计算资源；之后靠轮询或完成通知唤醒，用 tasks/get 取结果。如果中途 Runtime 重启，句柄在日志里，任务状态在 MCP 服务器的外部存储里，两边都不丢。

A2A：Agent 之间的水平协议。 MCP 是 Agent 调工具，A2A（Agent2Agent，Google 2025 年发起，后捐给 Linux 基金会）是 Agent 调另一个 Agent：Agent Card 声明能力，Task 承载长时交互，消息里可以带文件和结构化数据。MCP 社区在 2026 年路线图里也明确了分工：MCP 是工具访问协议，不是 Agent 间协议。

代码即工具调用。 前面提到的 Code Mode / code execution with MCP 对网关也有影响：模型不再一次调一个工具，而是写一段代码，在沙箱里调用多个工具、过滤中间结果，只把最后需要的东西返回。好处是中间数据不经过模型（隐私）、条件分支不需要额外一轮推理（延迟）。Anthropic 举的例子里，harness 还可以自动把敏感字段（邮箱、电话）替换成占位符，数据在 Google Sheets 和 Salesforce 之间流动，真实值从未进入模型上下文。代价是必须有一个靠得住的沙箱，网关的检查点也从「每次工具调用」变成了「沙箱的出口」。

---

九、Sandbox：给不可信代码一个围墙

9.1 威胁模型先于技术选型

沙箱要防的不只是 bug，主要是间接提示注入：模型读了一个网页、一个 issue、一份 PDF，里面藏着指令，模型照做了。Anthropic 在讲 Claude Code 沙箱时说得很直接：沙箱的目标是让「即使注入成功」也被完全隔离，被注入的 Claude Code 偷不走你的 SSH 密钥，也连不上攻击者的服务器。

由此得出一个硬约束：文件系统隔离和网络隔离必须同时存在。没有网络隔离，被攻陷的 Agent 能把 ~/.ssh 外传；没有文件系统隔离，它能改掉沙箱配置、逃出去再拿网络。

9.2 隔离强度的光谱

从弱到强：

• 进程级 + OS 原语：macOS 的 Seatbelt（sandbox-exec），Linux 的 bubblewrap、Landlock、seccomp。Claude Code 的 sandbox-runtime（已开源）和 Codex 的本地沙箱都在这一层。优点是零启动开销、直接用本机环境，限制对命令派生出的所有子进程都生效。Claude Code 的做法是：读写只允许在当前工作目录；网络只能通过一个 Unix domain socket 连到沙箱外的代理，代理按域名白名单放行，遇到新域名再问用户。Anthropic 内部数据是这样做让权限弹窗减少了 84%；
• 容器：namespace + cgroup。共享宿主内核，内核漏洞就是逃逸路径。Daytona 默认用 Docker，可选 Kata；
• 用户态内核：gVisor（runsc）在用户态拦截系统调用，比容器强，比 VM 弱。Modal Sandboxes 用这个；
• microVM：Firecracker、Cloud Hypervisor，每个沙箱有自己的内核，硬件虚拟化边界。E2B、Vercel Sandbox、AWS Lambda 和 AgentCore Runtime 都基于 Firecracker 这一类技术；
• V8 isolate：Cloudflare 的 Dynamic Workers 跑模型生成的 JS/TS，启动极快，但只能跑这类语言；要完整 OS（git、编译器）时再用 Sandboxes 容器。

2026 年的公开对比数据大致是：Firecracker 冷启动 125 到 200ms，从预启动快照恢复可以降到 5 到 30ms；E2B 宣称约 150ms 冷启动、Pro 版单会话上限 24 小时；Daytona 约 90ms；Modal 和 Vercel 亚秒级。这些数字来自厂商或第三方评测，不同区域和镜像大小差异很大，只适合看量级。市场的大方向已经收敛：microVM、按秒计费、快照快启。差异化转移到 GPU、区域、会话时长和 SDK 体验上。

9.3 Brain 和 Hands 分离

2026 年最重要的架构共识，是 harness 不要和沙箱放在一起。

OpenAI 在 Agents SDK 的 sandbox 更新里给了三个理由：

• 安全：系统设计要假设提示注入和外泄必然发生。harness 和计算分开，凭证就不会出现在模型代码执行的环境里；
• 持久：Agent 状态在外面，丢了一个沙箱容器不等于丢了这次运行。快照和 rehydration 可以在新容器里从上一个 checkpoint 继续；
• 伸缩：一次运行可以用一个或多个沙箱，按需拉起，子 Agent 可以路由到各自隔离的环境，并行跑在多个容器上。

Anthropic Managed Agents 的说法几乎一致：凭证在出口代理处注入，Claude 永远看不到。沙箱里的代码访问 GitHub 时，请求经过代理，代理加上 token 再转发。Cloudflare Sandbox SDK 的 outboundByHost 做的是同一件事。

9.4 控制面本身也是攻击面

2026 年 9 月 8 日披露的 CVE-2026-82533（CVSS 9.4）是一个很好的教材。DeepSeek Harness 8 月开源后几周内获得约 21.5 万 star，它的本地控制 API 用客户端传来的 HTTP Host 头判断请求是否来自本机，而不是校验连接的真实来源。结果是被沙箱关着的 Agent 用一条 shell 命令就能访问控制 API，把会话提升到无限制、免审批的执行模式。默认配置，不需要网络暴露，不需要偷凭证。

教训有两条。第一，沙箱里的代码能发起网络请求，就能打到沙箱外监听在 localhost 上的任何服务，包括 harness 自己。第二，「关掉沙箱」「切换审批模式」这类操作必须走一个模型和沙箱内代码都够不着的通道，比如只接受来自终端用户 TTY 的输入，或者带外签名。

图分三块。顶部光谱从左到右隔离越来越强，启动也越来越重；选哪一档取决于跑的是谁的代码：开发者本机上的 coding Agent，OS 原语加上人在旁边看着，通常就够了；云上替匿名用户跑代码，安全团队一般会要求 microVM。

左下是凭证流向。Sandbox 框里写着「无凭证、无直连网络」，它唯一的出口是那根 UDS（Unix domain socket）连到 Egress Proxy。代理按白名单放行，并在这里给发往 github.com 的请求加上 token。红色虚线是被切断的两条路：读 ~/.ssh（文件系统隔离挡住）和连攻击者服务器（网络隔离挡住）。即使沙箱里的代码完全被注入者控制，它能做的最坏的事也只是「以受限身份访问白名单里的域名」。

右下是 CVE-2026-82533 的结构：问题不在沙箱本身，而在沙箱外面那个本该受保护的控制 API 对沙箱是可达的。设计检查时，除了问「沙箱里能碰到什么」，还要问「沙箱能连到哪些本机端口」。

9.5 沙箱的生命周期

沙箱不是用完就扔那么简单。Runtime 要管：

• 模板与预热池：常用镜像预构建、预启动成快照，按需从池里取；
• 暂停与恢复：E2B 的 pause/resume、Modal 的快照恢复到新沙箱、AgentCore 的持久文件系统；
• 资源上限：CPU、内存、磁盘、进程数、墙钟时间，任何一项超限都转成工具错误交给模型，而不是让会话挂死；
• 清理：会话结束后整个 microVM 销毁、内存清零（AgentCore 的文档明确这样承诺），残留数据不进入下一个会话。

---

十、安全与权限：不要指望模型守门

沙箱解决「代码能碰到什么」，权限解决「Agent 被允许做什么」。两者都不能靠模型自觉。

10.1 致命三要素

Simon Willison 在 2025 年 6 月提出的「lethal trifecta」是目前最实用的检查框架。一个 Agent 同时具备以下三样，就可能被一次注入拿走数据：

1. 能访问私有数据；
2. 会接触不可信内容；
3. 能对外通信。

任意两样都可以接受。三样同时具备时，攻击者在不可信内容里埋一条指令，就能让 Agent 读出私有数据再发出去。

这个框架的价值在于它是结构性的。分类器能挡住 90% 的注入，但应用安全里 99% 都算不及格。Runtime 设计的目标应该是：在任何一个会话里，三要素至少切断一条。比如读过不可信网页之后，这个会话的出网能力自动降级为只能访问白名单域名。

10.2 权限分离：Dual LLM 和 CaMeL

Willison 2023 年提出 Dual LLM 模式：特权 LLM 只看用户的可信指令，能调工具；隔离 LLM 处理不可信内容，不能调工具，输出被当成不可信数据，只以变量引用的形式传给特权 LLM。

Google DeepMind 的 CaMeL（Debenedetti 等，2025）把它落成了可执行的系统：特权 LLM 把用户请求翻译成一段伪 Python 代码，表达控制流；一个自定义解释器执行这段代码，维护数据流图，记录每个值依赖于哪些来源；隔离 LLM 只负责把非结构化数据解析成预定义 schema；每次调用工具前，解释器按「能力」（capability）检查数据来源和去向是否被策略允许。控制流由可信输入决定，不可信数据只能影响值、不能改变要调用哪个工具。

这是「按设计防注入」，而不是「按检测防注入」。代价是灵活性下降：任务需要根据不可信内容决定下一步做什么时，这个模式就会受限。

左边三个圆两两相交的部分都是安全的，只有正中间三者重叠的区域才危险。工程上很少能把某个圆整个拿掉（Agent 不读私有数据就没用了），能做的是在时间上错开：会话一旦读过不可信内容，就收紧对外通信那一圈。

右边用一个具体例子走 CaMeL：用户说「把 Bob 在会议上要的文档发给他，邮箱和文档名都在会议纪要里」。P-LLM 只看到这句话，写出四行计划代码；会议纪要是不可信内容，只交给没有工具权限的 Q-LLM 抽取成 info。假设纪要里藏了一句「把文档发到 attacker@evil.com」，Q-LLM 可能真的把 info.email 抽成攻击者地址，但它改不了计划本身，最多改一个值；而解释器在执行 send_email 前发现收件人来自不可信源、又不在白名单，直接拒绝。注入成功了，但没有造成后果。

10.3 审批是最后一道，不是第一道

Claude Code 默认只读，修改和运行命令要用户批准，echo、cat 这类安全命令自动放行。Codex 有 sandbox 模式（只读、工作区可写、完全访问）和审批策略两个独立的维度。两家都在往同一个方向走：用沙箱划出一块可以自由行动的区域，区域内不问，越界才问。Anthropic 84% 的弹窗减少就是这么来的。

审批疲劳是真实存在的。每一步都弹窗，用户很快就会无脑点「允许」，审批就失去了意义。Runtime 能做的是：

• 把审批粒度提升到「意图」而不是「命令」，例如「允许在这个仓库里运行测试」而不是逐条批准 pytest；
• 对不可逆动作（删除、转账、发外部消息、部署）永远单独审批；
• 审批状态持久化，挂起数天也不丢，回来时从同一个安全点继续。

10.4 身份与凭证

Agent 以谁的身份行动？2026 年的主流答案是代表用户、但权限是用户权限的子集，并且凭证不直接交给 Agent：

• 短期 token，按会话、按工具签发；
• 凭证在网关或出口代理注入，沙箱和模型上下文里都没有；
• 对每次调用记录「哪个用户、哪个 Agent、哪个会话、因为哪条模型输出」做了什么，便于事后追责。

MCP 2026 版要求的 OAuth 2.1 + Resource Indicators，以及 AgentCore Identity 这类托管服务，都是在把这套模式标准化。

---

十一、生命周期与调度：大多数 Agent 都在睡觉

11.1 Actor 模型

Cloudflare 的 Agents SDK 把这个问题想得最透：一个 Agent 就是一个 Durable Object。每个实例有稳定的名字（同名请求永远路由到同一个实例）、自带最多 10GB 的 SQLite（与计算同机、单写者）、自己的 WebSocket 连接和定时器。HTTP 请求、WebSocket 消息、定时 alarm、收到的邮件都能唤醒它；处理完就休眠，休眠期间不计时长费用。

他们给过一个直观的对比：一万个 Agent，每个只有 1% 的时间活跃，用 VM 或容器要一万个常驻实例；用 Durable Objects，任意时刻大约只有一百个在跑。这就是「每个客户一个 Agent」「每个邮件线程一个 Agent」在经济上成立的前提。

this.schedule() 接受秒数、具体时间或 cron 表达式；因为一个 Durable Object 同时只能有一个 alarm，SDK 用内部的 SQLite 表把所有定时任务复用到这一个 alarm 上。子 Agent 共享父对象的 alarm，SDK 记录每个定时任务属于哪个子 Agent，唤醒父对象后再路由给子 Agent。

11.2 会话即 microVM

AWS AgentCore Runtime 走的是另一条路：每个用户会话一个专用 microVM，CPU、内存、文件系统完全隔离，会话结束整个 VM 销毁、内存清理。microVM 会话最长 8 小时；如果用 Instances（跑在用户自己账号的 EC2 上），可以到 14 天，支持 GPU 和多个 Agent 共享一台实例。InvokeAgentRuntime（Agent 推理）和 InvokeAgentRuntimeCommand（确定性 shell 命令）作用在同一个会话的同一个容器上。2026 年 9 月发布的新一代 Runtime 加了弹性内存回收，按实际用量而不是峰值计费，冷启动时间不再随镜像大小和并发变化。

两种模型的取舍很清楚：actor 模型把「状态」做成一等公民，计算是临时的；会话 VM 模型把「环境」做成一等公民，适合需要完整 OS、长时间驻留的 coding 类 Agent。

左边的时间轴是一个 Durable Object 的一天：四次被不同事件唤醒，每次活跃很短，其余时间都在休眠，只有橙色块计费。下面那两根条形是同一个规模的直观对比，灰色长条是一万个常驻实例，橙色细线是任意时刻实际在跑的约一百个。

右边是一个 AgentCore 会话的状态流转：首次 invoke 创建 microVM，空闲时可以被新请求拉回活跃，最终销毁。和左边的本质差别在于，右边的「空闲」仍然保留着一整台虚拟机的环境（进程、文件、装好的依赖），代价是这段时间资源并没有完全释放；左边的「休眠」只保留 SQLite 里的数据，醒来时环境是全新的。

实际系统常常两者混用：用 actor 承载 Agent 的身份、状态和调度，需要跑代码时再按需挂一个 microVM 沙箱。Cloudflare 自己的 Project Think 就是这样，Durable Object 加上 Sandboxes。

11.3 唤醒的来源

Runtime 要把这些事件统一成「唤醒某个会话」：

• 用户消息、IDE 操作；
• 定时器和 cron；
• Webhook（PR 被评论、工单状态改变、CI 失败）；
• 审批结果、MCP Task 完成通知、子 Agent 回报；
• 部署：新版本上线，进行中的会话要么在旧版本上跑完（Anthropic 研究系统用的是 rainbow deployment，新旧版本同时在线逐步切流），要么在安全点迁移到新版本。

最后一条经常被忽略。Agent 的一次运行可能跨越好几次部署，如果升级会打断所有进行中的会话，团队就不敢频繁发布。

11.4 推理服务：把「程序」而不是「请求」当调度单位

上面讲的都是 Agent 侧。推理服务那一侧，2025 年开始出现一批专门为 Agent 负载设计的系统论文，它们的共同出发点是：传统推理引擎（vLLM 等）把每次 LLM 调用当作独立请求，先来先服务，而 Agent 是一串相互依赖的调用，中间夹着工具执行的停顿。

• InferCept（Abhyankar 等，ICML 2024）：最早系统讨论「增强型 LLM」推理被工具调用打断时，KV-cache 该丢弃、换出还是保留，按代价选；
• Autellix（Luo 等，2025）：把整个 Agent 程序作为调度的一等实体。提出 PLAS（Program-Level Attained Service），优先调度累计服务时间少的程序，缓解程序级的队头阻塞；多机场景下还考虑数据局部性做路由。报告的吞吐提升是 4 到 15 倍；
• Continuum（2025）：指出 Autellix 没有考虑工具调用本身的特性。每次工具调用造成一次停顿，停顿期间 KV-cache 可能被驱逐，回来后要么重新 prefill，要么排队等进入 continuous batch。Continuum 给产生工具调用的请求在 GPU 显存里「钉住」KV-cache，并设一个 TTL，TTL 由重新加载的代价和驱逐引起的排队延迟决定；TTL 到期自动释放，保证极端情况下的稳健性。配合程序级先来先服务，在 SWE-Bench、BFCL 等真实 Agent 负载上降低了任务完成时间。

这条线对 Runtime 设计者的意义是：Agent 侧要把程序身份传下去。推理请求里带上 program_id/session_id，告诉推理服务这是同一个程序的第几轮、刚刚在等什么工具，服务端才能做程序级调度和 KV 保留。用托管 API 时你控制不了这些，但会话级的路由亲和、稳定前缀，仍然是你能做的那部分。

上面两条时间轴是同一个三轮 Agent 程序在两种引擎上的执行过程。传统引擎里，每次工具调用回来都要经历两段浪费：橙色的排队（这个请求被当成新请求排到队尾），以及蓝色的重算（停顿期间 KV 被别的请求挤掉，要重新 prefill 整个前缀）。而且前缀越来越长，第二次重算比第一次更贵。下面那条在工具执行期间把 KV 钉住，回来后只 prefill 新增的工具结果，也不用重新排队。紫色的 TTL 线表示钉住是有期限的：工具跑得太久，就放手把显存让给别人，避免几个慢工具占满 GPU。

---

十二、多 Agent：本质上是上下文的分配问题

多 Agent 在 Runtime 层面是两个问题：怎么分配上下文，怎么协调状态。

支持的证据。 Anthropic 的多 Agent 研究系统用 orchestrator-worker 模式：主 Agent 规划并拉起专门的子 Agent 并行搜索不同方向。以 Claude Opus 4 为主、Sonnet 4 为子 Agent 的系统，在内部研究评测上比单 Agent 的 Opus 4 高 90.2%。他们在 BrowseComp 上做了方差分析：三个因素解释了 95% 的表现差异，其中 token 用量一项就解释了 80%，另两个是工具调用次数和模型选择。结论是多 Agent 有效，主要是因为它能把足够多的 token 花在问题上，每个子 Agent 有自己独立的上下文窗口。代价是 token 消耗：Agent 大约是普通对话的 4 倍，多 Agent 系统大约是 15 倍。

反对的证据。 Cognition 在 2025 年 6 月写了《Don't Build Multi-Agents》，论点是子 Agent 之间看不到彼此的决策，会做出隐含冲突的选择。他们举的例子是做一个 Flappy Bird 克隆：一个子 Agent 误做成了超级玛丽风格的背景，另一个做的小鸟既不像游戏素材、动作也和背景对不上，最后拼不起来。他们的原则是共享完整上下文（包括完整的 Agent 轨迹，而不只是消息），以及「动作隐含决策，冲突的决策带来坏结果」。

两者并不矛盾。Anthropic 的场景是广度优先的研究，子任务天然独立，结果只需要汇总；Cognition 的场景是写代码，子任务之间有大量隐含的耦合。Runtime 层面的实践共识是：

• 读可以并行，写尽量串行。搜索、阅读、分析交给多个子 Agent；改代码、改状态由一个 Agent 负责；
• 子 Agent 返回压缩结果。子 Agent 可能用了几万 token 探索，返回给主 Agent 的只有一两千 token 的结论，主 Agent 的上下文保持干净；
• 子 Agent 的轨迹也要写日志，但作为独立的子会话，可以单独回放；
• 共享状态走文件系统或显式的存储，不靠在消息里互相转述。

左边这张结构图里，向下的箭头带的是任务描述，向上的绿色箭头带的是压缩后的结论，两者都很小。每个子 Agent 内部可能花掉几万 token，但这些 token 只留在它自己的窗口和子会话日志里，Lead Agent 的上下文始终只装着计划和各路结论。这就是「多 Agent 能花更多 token」的具体机制：总 token 被分散到了多个互不干扰的窗口里。

右上是同一个结构在耦合任务上失败的方式：两个子 Agent 各自做出了合理但互相矛盾的决定，Lead Agent 拿到的两个结论都「对」，却拼不到一起。右下的共识本质上是在问：子任务之间有没有共享的隐含决策？有，就别拆。

Runtime 要提供的原语。 拉起子 Agent（带独立的上下文、工具集、沙箱）、等待一个或多个子 Agent 完成、取消、超时、预算继承（子 Agent 花的 token 计入父会话）。Managed Agents 的「brain 可以把 hand 传给另一个 brain」，就是让子 Agent 直接复用父 Agent 已经准备好的沙箱，而不必重新克隆仓库、装依赖。

跨组织、跨 Runtime 的 Agent 协作，走 A2A 这类协议。同一个 Runtime 内部的子 Agent，一般走内部 API，不需要协议开销。

---

十三、可观测：Trace 能解释，不能恢复

Agent 的 trace 和普通服务的 trace 结构相似：一个会话是一棵树，节点是模型调用、工具调用、子 Agent、审批、handoff。OpenTelemetry 的 GenAI 语义约定定义了模型调用相关的 span 属性（模型名、输入输出 token 数、结束原因等），LangSmith、Langfuse、Arize Phoenix、OpenAI Traces 都在这上面做了自己的扩展。

有三点和普通服务不同。

第一，trace 不等于 journal。 这是 Zylos 那篇持久执行综述里的一句话，说得很准：trace 能解释发生了什么，journal 必须决定什么可以重放、跳过、补偿或恢复。很多团队以为接了 tracing 就有了恢复能力，其实没有。理想情况是二者共用同一条事件流：会话日志本身就是 trace 的数据源，而不是另外打一份。

第二，要能看到模型当时看到的东西。 光记录「调用了什么工具」不够，调试时最常问的问题是「模型为什么这么做」，答案在它当时的完整上下文里。所以要能根据会话日志和投影规则，还原任意一步的完整上下文。这也是为什么投影规则要版本化。

第三，成本是一等指标。 每个会话的输入 token、缓存命中 token、输出 token、沙箱秒数、工具调用次数，都要按租户、按 Agent 版本聚合。多 Agent 一次 15 倍 token，不监控就是一张意外的账单。KV-cache 命中率作为单独的仪表盘指标，比延迟更早暴露上下文拼装的回归。

从 trace 到改进。 LangChain 的 Vivek Trivedy 在 2026 年 7 月写了一篇《Improving Agents is a Data Mining Problem》，观点是改进 Agent 的主要工作是从大量生产 trace 里挖出失败模式，再变成评测集和 harness 改动。Anthropic 研究系统的经验也类似：先用 20 个左右的真实查询做小规模评测，因为早期的改动效果很大，小样本就能看出来；再用 LLM 作为评委按标准打分，配合人工看 trace 找自动评测漏掉的问题。Runtime 层要保证的是：trace 保留足够久、可以按失败类型检索、可以一键把某个会话从某一步开始重放到新版本的 harness 上。最后这一条依赖前面讲的 journal：重放时，旧的工具结果当作数据回放，只有模型调用用新版本重新跑。

---

十四、2026 年的产品地图

按层归类主要的公开方案。产品变化很快，这里只记录截至 2026 年 10 月公开资料里的定位。

层	代表	关键特征
托管 Runtime	AWS AgentCore Runtime	每会话一个 microVM，最长 8 小时（Instances 14 天），持久文件系统，支持 MCP/A2A，框架无关
托管 Harness + Runtime	AgentCore Harness（2026-06 GA）	声明模型、提示词、工具、技能、记忆，AWS 跑循环
托管 Harness + Runtime	Claude Managed Agents	Session / Brain / Hands 解耦，出口代理注入凭证
托管 Runtime	Cloudflare Agents / Project Think	一个 Agent 一个 Durable Object，休眠零成本，内置 SQLite、alarm、Workspace
托管 Runtime	LangSmith Deployment	托管 LangGraph 的执行和 checkpoint 存储
SDK + Harness	OpenAI Agents SDK	模型原生 harness，sandbox 执行，Manifest 描述工作区，支持 E2B、Modal、Daytona、Cloudflare、Vercel 等
SDK + Harness	Claude Agent SDK	Claude Code 的同一套 harness，作为库提供
开源 Harness	Codex（Rust，Apache-2.0）	App Server：JSON-RPC，thread/turn/item，OS 原生沙箱 + 审批策略
开源 Harness	DeepSeek Harness	一切皆插件，Session Log 为权威来源；开发者预览，有过严重 CVE
Framework	LangGraph、CrewAI、Mastra、Pydantic AI、Google ADK、Microsoft Agent Framework	自己写循环；持久化能力差异大
持久执行	Temporal、Restate、DBOS、Inngest、Hatchet、Cloudflare Workflows、Lambda Durable Functions	journal + replay，和 Agent 框架集成
沙箱	E2B、Modal、Daytona、Vercel Sandbox、Cloudflare Sandboxes、Runloop、Blaxel	microVM 或 gVisor，快照快启
本地沙箱	Anthropic sandbox-runtime、Codex linux-sandbox	Seatbelt / bubblewrap / seccomp

怎么选。 几个判断问题按顺序问：

1. Agent 的生命是否超过一个请求？不超过（一次问答、几十秒的工具链），Framework 加普通 Web 服务就够了，不需要专门的 Runtime。
2. 会不会执行模型生成的代码？会，就必须有沙箱，而且 harness 不要和沙箱放在一起。
3. 有没有不可逆的外部副作用？有，就需要 journal 级的持久执行和幂等设计，checkpoint 不够。
4. 有多少个 Agent 实例，空闲比例多高？大量、多数空闲，actor 模型（Durable Objects 一类）在成本上有数量级优势；少量、长时间重度计算，会话 VM 更合适。
5. 要不要自己掌控循环？要，用 Framework 加持久执行引擎；不要，用托管 Harness，把精力花在工具和评测上。

五个问题不是互斥分支，而是一路往下叠加要求：问题 ② 回答「是」，就在架构里加上沙箱；问题 ③ 也回答「是」，再加上 journal 和幂等键。问题 ④ 和 ⑤ 才是真正的二选一。图底部给了三个常见场景的组合，可以拿自己的系统对照一下，看缺了哪一块。

---

十五、动手：100 行写一个能从崩溃里恢复的最小 Runtime

前面讲的会话日志、journal、幂等键、投影、状态不明时停下，用一段能直接运行的 Python 串起来。模型用脚本模拟，保证离线可复现；沙箱用子进程代替，它不是安全边界，只用来演示接口。

场景：用户让 Agent「算 1 到 100 的和，并把结果发邮件给运维」。Agent 先调 run_python 计算，再调 send_email 发送。我们故意让进程在邮件已经发出、但 Runtime 还没记录「完成」的那一刻死掉，然后重启，看会不会发两封。

15.1 会话日志

import json, os, sqlite3, subprocess, sys, tempfile

# ---------- 1. Session：追加写的事件日志，是唯一的真相来源 ----------
class SessionLog:
    def __init__(self, path):
        self.db = sqlite3.connect(path)
        self.db.execute("""CREATE TABLE IF NOT EXISTS events(
            sid TEXT, seq INTEGER, kind TEXT, key TEXT, payload TEXT,
            PRIMARY KEY (sid, seq))""")

    def append(self, sid, kind, payload, key=None):
        with self.db:  # 单条事务：要么整条写进去，要么没写
            seq = self.db.execute(
                "SELECT COALESCE(MAX(seq), 0) + 1 FROM events WHERE sid=?", (sid,)
            ).fetchone()[0]
            self.db.execute("INSERT INTO events VALUES (?,?,?,?,?)",
                            (sid, seq, kind, key, json.dumps(payload, ensure_ascii=False)))

    def events(self, sid):
        rows = self.db.execute(
            "SELECT kind, key, payload FROM events WHERE sid=? ORDER BY seq", (sid,))
        return [{"kind": k, "key": key, "payload": json.loads(p)} for k, key, p in rows]

表里只有插入，没有更新。(sid, seq) 是主键，同一个会话的事件严格有序。with self.db 让每次追加是一个事务，进程在写到一半时死掉，这条事件要么完整存在，要么完全不存在，不会出现半条记录。

生产环境里这张表会换成 Postgres、DynamoDB 或者 Kafka，但约束一样：只追加、有序、单条原子。

15.2 Journal：结果记下来，恢复时当数据用

# ---------- 2. Journal：把非确定性步骤的结果记下来，恢复时当数据重放 ----------
class Journal:
    def __init__(self, log, sid):
        self.log, self.sid = log, sid

    def step(self, key, fn, idempotent):
        evs = [e for e in self.log.events(self.sid) if e["key"] == key]
        done = [e for e in evs if e["kind"] == "step_done"]
        if done:                                  # 已完成：直接返回记录，不再执行
            return done[-1]["payload"]
        if evs and not idempotent:                # 开始过但没完成，又不能安全重试
            raise RuntimeError(f"步骤 {key} 状态不明，需要人工对账")
        self.log.append(self.sid, "step_started", {}, key)
        result = fn(idem_key=f"{self.sid}:{key}")  # 幂等键由 Runtime 生成，跨重试不变
        self.log.append(self.sid, "step_done", result, key)
        return result

step 是整个 Runtime 的核心，它把一个步骤分成三种情况：

• 有 step_done：这一步已经完成过，直接返回当时记录的结果。模型调用走这条路，就解决了非确定性问题：重放时模型不会被再调一次，拿到的是第一次的输出；
• 只有 step_started，没有 step_done：这就是第六节那条「缝」。工具声明了幂等，就带着同一个幂等键重做；没声明，就抛错，交给人；
• 什么都没有：第一次执行，先记 started，执行，再记 done。

幂等键是 会话ID:步骤键，由 Runtime 根据日志位置算出来，和模型输出无关。如果把这一行改成用 uuid4() 生成，每次重试的键都不一样，下游的去重就失效了，这正是生产里最常见的重复副作用来源。

15.3 Hands：工具

# ---------- 3. Hands：工具。这里的子进程只是演示，不是安全边界 ----------
WORKDIR = tempfile.mkdtemp(prefix="ws-")
OUTBOX = os.path.join(os.path.dirname(os.path.abspath(__file__)), "outbox.json")

def run_python(code, idem_key):
    p = subprocess.run([sys.executable, "-c", code], cwd=WORKDIR, env={},
                       capture_output=True, text=True, timeout=10)
    out = (p.stdout + p.stderr)[-2000:]           # 只把尾部回灌给模型
    return {"exit": p.returncode, "output": out}

def send_email(to, body, idem_key):
    box = json.load(open(OUTBOX)) if os.path.exists(OUTBOX) else {}
    if idem_key not in box:                       # 模拟下游按幂等键去重
        box[idem_key] = {"to": to, "body": body}
        json.dump(box, open(OUTBOX, "w"), ensure_ascii=False)
    if os.environ.get("CRASH_AFTER") == "send_email":
        os._exit(1)                               # 副作用已发生，step_done 还没写
    return {"sent": True, "id": idem_key}

TOOLS = {"run_python": (run_python, True), "send_email": (send_email, True)}

run_python 演示了三个沙箱接口约束：独立工作目录、清空环境变量（凭证不传进去）、超时。输出只截取尾部 2000 字符，对应第七节的工具输出整形。真正的沙箱要换成 microVM 或至少是 bubblewrap/Seatbelt，并且限制网络。

send_email 模拟一个支持幂等键的下游服务：同一个键只记一次。CRASH_AFTER 用 os._exit(1) 直接杀进程，不执行任何清理，最接近真实的 OOM 或机器被回收。

TOOLS 里每个工具带一个布尔值，表示能否安全重试。这个声明属于工具的契约，由写工具的人负责，Runtime 只按声明执行。

15.4 Brain 与 Loop

# ---------- 4. Brain：用脚本假装模型，保证示例可离线复现 ----------
def fake_model(messages):
    n_tool = sum(1 for m in messages if m["role"] == "tool")
    if n_tool == 0:
        return {"tool": "run_python", "args": {"code": "print(sum(range(101)))"}}
    if n_tool == 1:
        total = messages[-1]["content"]["output"].strip()
        return {"tool": "send_email", "args": {"to": "ops@example.com", "body": f"结果={total}"}}
    return {"final": "已计算并发送邮件"}


# ---------- 5. Loop：上下文是日志的投影，不是内存里的变量 ----------
def project(events):
    msgs = []
    for e in events:
        if e["kind"] == "user":
            msgs.append({"role": "user", "content": e["payload"]})
        elif e["kind"] == "step_done" and e["key"].startswith("tool:"):
            msgs.append({"role": "tool", "content": e["payload"]})
    return msgs

def run(log, sid, task=None, max_steps=8):
    j = Journal(log, sid)
    if task and not log.events(sid):
        log.append(sid, "user", task)
    for turn in range(max_steps):
        msgs = project(log.events(sid))
        action = j.step(f"llm:{turn}", lambda idem_key: fake_model(msgs), idempotent=True)
        if "final" in action:
            log.append(sid, "final", action["final"])
            return action["final"]
        fn, idem = TOOLS[action["tool"]]
        j.step(f"tool:{turn}", lambda idem_key: fn(**action["args"], idem_key=idem_key), idem)
    return "超出步数上限"

if __name__ == "__main__":
    log = SessionLog(os.path.join(os.path.dirname(os.path.abspath(__file__)), "session.db"))
    print(run(log, "s-001", task="算 1..100 的和并发邮件给运维"))
    for e in log.events("s-001"):
        print(e["kind"], e["key"])

project 是第五节「上下文是日志的投影」的最小实现：遍历事件，只挑用户消息和工具完成结果组装成消息列表，step_started 这类 Runtime 内部事件不进模型上下文。压缩、卸载、记忆注入，在真实系统里都是这个函数的扩展。

run 里没有任何「当前状态」变量，每一轮都从日志重新投影。这让它天然可以从任何位置恢复：重启后再调一次 run(log, sid)，前面完成的模型调用和工具调用全部从 journal 返回，循环快进到断点。

步骤键用 llm:{turn} 和 tool:{turn}，依赖循环是确定性的：同样的日志，重放时走到同一个 turn 必然遇到同一个键。这是 Temporal 要求 Workflow 代码确定的同一个原因。如果在循环里根据当前时间或随机数决定走哪条分支，重放时键就对不上了。

max_steps 是放在模型够不着的地方的硬上限。

15.5 跑一遍：在最坏的时刻崩溃

把上面的代码存成 mini_runtime.py，先带着崩溃开关跑，再正常跑一次：

CRASH_AFTER=send_email python3 mini_runtime.py; echo "exit=$?"
python3 mini_runtime.py
cat outbox.json

实际输出：

exit=1
已计算并发送邮件
user None
step_started llm:0
step_done llm:0
step_started tool:0
step_done tool:0
step_started llm:1
step_done llm:1
step_started tool:1
step_started tool:1
step_done tool:1
step_started llm:2
step_done llm:2
final None
{"s-001:tool:1": {"to": "ops@example.com", "body": "结果=5050"}}

逐行看恢复过程：

• 第一次运行，llm:0、tool:0、llm:1 都完整执行；tool:1 写了 step_started，邮件写进了 outbox，进程死了，step_done 没写；
• 第二次运行，run 从头开始。llm:0 在日志里有 step_done，直接返回第一次的模型输出，没有再调模型；tool:0 同理，Python 没有再跑；llm:1 同理；
• 到 tool:1，只有 step_started。send_email 声明了可重试，于是再记一条 step_started（日志里出现两次，这正是排查重试时要看的证据），带着同一个键 s-001:tool:1 重做。下游发现这个键已存在，不重复发送；
• outbox.json 里只有一封邮件。

再试一次不可重试的情况：把 send_email 的声明改成 False，同样在发出后崩溃，第二次运行输出：

RuntimeError: 步骤 tool:1 状态不明，需要人工对账

Runtime 拒绝猜。生产系统里这里会把会话挂起成 WAITING_RECONCILE，通知人去下游查一下邮件到底发没发，然后手工补一条 step_done 或者允许重试。

15.6 从这 100 行到生产，差了什么

逐项对照前面的章节：

• 日志：SQLite 换成支持多实例的存储；events() 每次全量读，要换成按序号增量读并缓存投影；
• 并发：同一个会话同时只能有一个 Runtime 实例在推进，需要租约或单写者 actor（Durable Object 天然满足）；
• 沙箱：子进程换成 microVM 或 OS 沙箱，加网络出口代理和凭证注入；
• 上下文：project 要加压缩、卸载、缓存友好的确定性序列化；
• 等待：审批、定时、外部回调需要持久挂起，不能让进程一直阻塞；
• 策略：工具调用前的权限检查和审批路由；
• 观测：每个事件同时作为 trace 输出，加 token 与成本计量；
• 版本：日志要记录 harness 和投影规则的版本，否则升级后重放会走到不同的分支。

每一项在业界都已经有成熟答案，难的是把它们放在同一个一致的模型里。这也是托管 Runtime 产品真正在卖的东西。

---

十六、趋势与没有答案的问题

Harness 在变薄，Runtime 在变厚。 Anthropic 讲 Managed Agents 时反复提到一点：harness 里编码了对模型的假设，而这些假设会随着每一代模型过时。早期模型需要的规划提示、强制复述、细粒度的工具拆分，新模型可能都不需要了。工程问题从「怎么控制模型」变成「哪些事可以不做了，交给模型」。但 Runtime 的需求不会因为模型变强而消失：状态、隔离、恢复、身份、成本，模型再聪明也替代不了。可以预期的是 harness 越来越多由模型厂商提供（「model-native harness」），而 Runtime 越来越像操作系统和云基础设施。

会话格式可能会标准化。 现在每家的事件日志格式都不一样，换 harness 就要丢历史。MCP 统一了工具接口，A2A 统一了 Agent 之间的接口，会话日志（thread/turn/item 这一层）是下一个可能被统一的东西。Codex App Server 的协议已经被 JetBrains、Xcode 等第三方客户端采用，这是一个信号。

上下文管理会下沉到 Runtime 甚至推理层。 Codex 的加密压缩只有模型厂商能做；Continuum 一类工作把 KV-cache 驻留和 Agent 程序结构绑定；AIOS 把上下文快照当成内核功能。上下文越来越像被操作系统管理的虚拟内存，而不是应用自己拼接的字符串。

持久执行和 Agent 框架在融合。 Temporal 有 OpenAI Agents SDK 和 Pydantic AI 集成，DBOS 有 OpenAI Agents 集成，LangGraph 有自己的 durability 模式，OpenAI Agents SDK 自己也在做快照和 rehydration。最终形态大概率是 Agent 框架默认就是持久的，开发者不再需要区分「工作流」和「Agent」。

记忆与持续学习进入 Runtime。 Managed Agents 用会话日志驱动的「dreaming」批处理整理记忆，LangChain 把改进 Agent 定义为数据挖掘问题。Runtime 不只是执行环境，也是收集经验、离线改进的数据源。这带来新的问题：跨用户的经验能不能共享，记忆被投毒怎么办，记忆的版本怎么回滚。

几个至今没有好答案的问题：

• 跨部署的会话迁移。 一个跑了三天的会话，harness 升级后投影规则变了、工具 schema 变了，旧日志在新版本上重放会走到哪里？目前大多数系统的答案是「旧会话在旧版本上跑完」，这对长达数周的 Agent 不现实；
• 不可信内容的污点传播。 CaMeL 证明了在受限场景下可行，但通用 coding Agent 需要根据读到的代码决定下一步，控制流本身依赖不可信数据。怎么在不牺牲能力的前提下做细粒度的信息流控制，还是研究问题；
• 副作用的语义化。 现在的幂等性靠工具作者自觉声明。能否让工具声明更丰富的语义（可补偿、可预览、需对账），让 Runtime 自动生成 saga 式的补偿流程？
• 多 Agent 的一致性。 多个 Agent 共享一个工作区并发写，目前主要靠「写只让一个 Agent 做」回避问题。真正的并发协作需要类似事务或 CRDT 的机制；
• 成本可预测性。 同一个任务，Agent 的 token 消耗可能相差一个数量级。按结果计费、预算硬上限、提前终止，都需要 Runtime 能在中途估计「还要花多少」。

---

收尾

把这篇文章压成几句话：

Agent Runtime 是让一个非确定性的循环，在确定性的工程系统里长期、安全、可恢复地运行的那一层。

它的骨架已经比较清楚：一条只追加的会话日志作为真相来源；无状态、可替换的 brain；按需拉起、随时可丢弃的 hands；凭证在出口注入，不进沙箱也不进上下文；非确定性的步骤记录结果，恢复时当数据回放；副作用靠 Runtime 生成的幂等键和下游去重拼出恰好一次，状态不明时宁可停下；上下文是日志的投影，按 KV-cache 友好的方式拼装，用文件系统做外部内存；大多数 Agent 大多数时间在睡觉，按事件唤醒。

这些设计没有一条是新发明。事件溯源、actor 模型、journal 重放、能力安全、虚拟内存、microVM，都是几十年前就有的东西。Agent 带来的新东西只有一个：做决定的那个组件是不可信、不确定、按 token 计费的。Runtime 的全部工作，就是围绕这一点，把老技术重新组合一遍。

---

参考资料

架构与 Runtime 定义

• Anthropic, Scaling Managed Agents: Decoupling the brain from the hands, https://www.anthropic.com/research/managed-agents
• camelAI, Agent Harness vs Framework vs Runtime vs Sandbox, Explained（2026-10），https://camelai.com/blog/agent-harness-vs-framework-vs-runtime
• Vivek Trivedy, The Anatomy of an Agent Harness（LangChain, 2026-03），https://www.langchain.com/blog/the-anatomy-of-an-agent-harness
• OpenAI, Unlocking the Codex harness: how we built the App Server, https://openai.com/index/unlocking-the-codex-harness ；源码 https://github.com/openai/codex
• OpenAI, The next evolution of the Agents SDK（2026-04），https://openai.com/index/the-next-evolution-of-the-agents-sdk
• Mei et al., AIOS: LLM Agent Operating System, arXiv:2403.16971

持久执行

• Zylos Research, Durable Execution for AI Agent Runtimes（2026-04），https://zylos.ai/research/2026-04-24-durable-execution-agent-runtimes
• Temporal, OpenAI Agents SDK integration, https://docs.temporal.io/develop/python/integrations/openai-agents
• LangGraph Durability 参考，https://reference.langchain.com/python/langgraph/types/Durability ；issue #9240，https://github.com/langchain-ai/langgraph/issues/9240

上下文工程与长任务

• Manus, Context Engineering for AI Agents: Lessons from Building Manus, https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus
• Anthropic, Effective harnesses for long-running agents, https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
• Anthropic, Code execution with MCP, https://www.anthropic.com/engineering/code-execution-with-mcp
• Anthropic, How we built our multi-agent research system, https://www.anthropic.com/engineering/multi-agent-research-system
• Cognition, Don't Build Multi-Agents, https://cognition.ai/blog/dont-build-multi-agents

沙箱与安全

• Anthropic, Making Claude Code more secure and autonomous with sandboxing, https://www.anthropic.com/engineering/claude-code-sandboxing
• AWS, Amazon Bedrock AgentCore Runtime 文档，https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/agents-tools-runtime.html
• Cloud Security Alliance, DeepSeek Harness Sandbox Escape and Agent Containment（CVE-2026-82533）
• Debenedetti et al., Defeating Prompt Injections by Design（CaMeL），arXiv:2503.18813
• Beurer-Kellner et al., Design Patterns for Securing LLM Agents against Prompt Injections, arXiv:2506.08837
• Simon Willison, The lethal trifecta for AI agents（2025-06）

协议、生命周期与推理服务

• MCP, The 2026-07-28 Specification Release Candidate, https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate
• Cloudflare, Project Think 与 Agents 文档，https://blog.cloudflare.com/project-think ，https://developers.cloudflare.com/agents/
• Luo et al., Autellix: An Efficient Serving Engine for LLM Agents as General Programs, arXiv:2502.13965
• Continuum: Efficient and Robust Multi-Turn LLM Agent Scheduling with KV Cache Time-to-Live, arXiv:2511.02230
• Abhyankar et al., InferCept: Efficient Intercept Support for Augmented Large Language Model Inference, ICML 2024