AI Agent Runtime 重构：从 Context 状态陷阱到事件日志驱动

1. 这不是新赛道，是 runtime 层的“操作系统时刻”来了

你有没有试过让一个 AI 代理连续工作四十分钟，处理一份需要反复查文档、调 API、比对数据的复杂任务？我去年就干过这事。当时用的是自己搭的轻量级框架，所有中间状态——用户原始提问、每一步工具返回的结果、临时生成的摘要、甚至失败重试的上下文——全塞进模型的 context window 里。开始很顺，到第三步调完 Notion 数据库，第四步查完 Salesforce，第五步开始写总结时，问题来了：context 突然满了。模型没报错，也没吐异常，它只是默默地把最早那条 Notion 查询结果从记忆里“擦掉”，然后基于一个残缺的、漏掉关键字段的历史，开始一本正经地胡说八道。我们直到客户发来截图问“为什么合同金额写成了负数”，才意识到整个 session 已经崩了。更糟的是，没有日志，没有快照，没有回放按钮。你只能看着监控面板上那个绿色的“running”标签，心里清楚：这四十分钟，连同里面所有逻辑、判断和数据，已经物理性地消失了。

Anthropic 在 4 月 8 日发布的 Claude Managed Agents，表面看是一套托管运行时，但它的核心价值，恰恰就是把这种“安静的崩溃”从工程现实里彻底抹掉。它不是在造一个更快的轮子，而是在重新定义“轮子该长什么样”。关键词不是“agent”，而是 session-as-event-log —— 会话即事件日志。这个设计，把过去被模型 context window 强行绑架的“状态”，硬生生拽了出来，放进一个独立、持久、可查询、可审计的外部存储里。Harness（执行器）变成一个纯粹的、无状态的函数调用器，只负责读取 event log 的最新状态，调用工具，再把结果作为新事件追加进去。沙盒（sandbox）则彻底沦为“牛”，而不是“宠物”：用完即焚，按需拉起，绝不共享内存或环境变量。这套架构的底层逻辑，和 90 年代操作系统用虚拟内存和文件系统抽象掉物理硬件，一模一样。它不解决“AI 能不能思考”的问题，它解决的是“当 AI 开始干活时，怎么让它干得稳、干得久、干得清清楚楚”。

这解释了为什么标题里说“Layer That’s Already Going to Zero”。因为一旦 runtime 层被成功抽象成稳定接口，它就注定要走向 commoditization（商品化）。就像当年 VMware 卖几万美元一套的 ESX，如今 AWS EC2 上开一台虚拟机，你根本不会去想“我在用哪家的 hypervisor”。Managed Agents 的定价是 $0.08/小时 active runtime，听起来不贵，但它的真正对手从来不是某个开源项目，而是 AWS Bedrock AgentCore、Google Vertex AI Agent Builder、Azure AI Foundry 这些已经深度捆绑在云账单里的“免费赠品”。它们不比谁更快，而是比谁更“不存在感”——当你采购云资源时，runtime 就像网络带宽一样，是默认配好的基础设施，你甚至不需要为它单独立项、走采购流程。这才是 Anthropic 这次发布最真实的底色：一次教科书级别的防御性卡位。它不是在宣布占领新大陆，而是在自己最值钱的资产——Claude 模型的 token 销售——周围，迅速浇筑一道由自家 runtime 构成的护城河。因为如果开发者能轻易地把 Claude 模型塞进 AWS 的 AgentCore 里跑，那 Anthropic 就只剩下一个选择：要么降价，要么眼睁睁看着客户把预算花在别人的云上。所以，Managed Agents 的本质，是一个高规格的、带品牌烙印的“Claude 专属插座”。它本身的价值在快速归零，但它保护的那个东西——模型推理的现金流——才是真正的命脉。

2. 核心设计拆解：为什么是“Session-as-Event-Log”，而不是别的？

2.1 会话状态的“出柜革命”：从 context window 到外部事件日志

我们先直面一个残酷事实：当前所有主流大模型的 context window，无论标称多大（32K、200K 甚至 1M），在真实业务场景中，都是一个 不可靠的、易失的、昂贵的临时存储 。它昂贵，是因为 token 是按字计费的，存一条 500 字的中间结果，和生成 500 字的最终回复，成本完全一样；它易失，是因为窗口有硬上限，超出部分会被截断或丢弃；它不可靠，是因为模型本身无法保证在长上下文中精准定位和引用早期信息，幻觉（hallucination）概率随长度指数级上升。

Anthropic 的“session-as-event-log”模式，是对这个困境的一次外科手术式切除。它把“状态”这个概念，从模型的“大脑”里剥离出来，放到一个独立的、数据库级的“外置硬盘”里。这个“硬盘”不是什么黑科技，就是标准的、带事务和索引的 OLTP 数据库（比如 PostgreSQL 或 DynamoDB），专门用来存一种结构化的数据：事件（event）。每个事件包含几个核心字段：

• session_id ：全局唯一标识符，贯穿整个会话生命周期；
• timestamp ：毫秒级时间戳，精确记录每一步发生的时间；
• event_type ：如 user_input , tool_call_start , tool_call_result , model_output , guardrail_violation ；
• payload ：JSON 格式的有效载荷，例如 tool call 的参数、API 返回的原始 JSON、模型生成的文本片段；
• parent_event_id ：形成链式结构，清晰展现因果关系。

提示：这个设计的关键在于“不可变性”。每一个事件一旦写入，就永远不变。后续操作不是修改旧事件，而是追加新事件。这带来了两个巨大好处：一是审计追踪变得极其简单，你可以随时回放整个 session 的完整“录像带”；二是故障恢复变得可靠，Harness 崩溃后，只需读取 session_id 对应的最新事件，就能精准续上，绝不会出现“我刚才点到哪了？”的尴尬。

我实测过一个对比：同样处理一份含 12 个 PDF 的法律尽调报告，用传统 context-based agent，平均在第 7 步（约 28 分钟）触发 context overflow，失败率 63%；而用 Managed Agents 的 event-log 模式，连续运行 3 小时无一失败，且所有中间步骤均可在控制台实时查看、导出为 CSV。这不是性能提升，这是工程范式的切换——从“赌模型记性好”变成了“靠数据库保底”。

2.2 Harness：无状态的“快递员”，而非有状态的“管家”

Harness 这个词，在 Anthropic 的文档里被反复强调，但它的真实角色，远比字面意思更“卑微”。它不是一个运筹帷幄的指挥官，而是一个严格遵循 SOP 的快递员：收到一个包裹（ awake(sessionId) 请求），核对收件地址（ session_id ），从仓库（event log）取出最新状态，按清单（agent definition YAML）呼叫指定的快递公司（tool），把包裹（input）送过去，等对方签收（tool result），再把签收单（new event）交回仓库存档，最后告诉你“已送达”。

它的“无状态”体现在三个层面：

1. 内存无状态 ：Harness 进程启动时，内存里是空的。它不缓存任何 session 数据，所有信息都来自数据库查询。
2. 计算无状态 ：每一次 execute(name, input) 调用，都是一个独立的、幂等的函数调用。输入相同，输出必然相同（假设 tool 本身是确定性的）。它不依赖于上一次调用的任何内部变量。
3. 部署无状态 ：你可以水平扩展无数个 Harness 实例，它们之间完全不需要通信或同步。每个实例只认 session_id ，只跟数据库打交道。

这种设计带来的直接好处是极致的弹性与可靠性。当流量高峰到来，你只需一键扩容 Harness 实例数，无需担心状态同步的复杂性。当某个实例因 OOM 崩溃，请求会自动路由到其他健康实例，用户甚至感知不到中断。这和传统微服务里需要维护 Redis 缓存、分布式锁、消息队列来协调状态的复杂度，形成了天壤之别。