Agent Runtime 重构：从 Context Overflow 到 Session-Event-Log

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

上周二（4月8日），Anthropic 正式开放 Claude Managed Agents 公共测试版。消息一出，技术圈刷屏——Notion、Asana、Rakuten、Sentry 都上了车；媒体通稿里全是“十倍提速”“沙箱隔离”“会话持久化”“凭证安全托管”这些词；工程博客还打了个漂亮比喻：他们把 agent 架构拆成了像 90 年代操作系统虚拟化硬件那样的稳定抽象层。听起来很酷，对吧？但如果你真在去年亲手搭过一个跑四五十分钟的多步检索 agent，亲眼看着它在第 38 分钟突然开始胡说八道、丢掉前 12 步的工具返回结果、连重放都做不到——那你看到“session as durable event log”这行字时，手指会下意识停顿半秒，心里清楚：这不是炫技，这是救命方案。

我试过三种 session 状态管理方式：全塞进 context window、用 Redis 做外部缓存、自己写 WAL 日志+快照。第一种最省事，也最危险——模型不会报错，它只会安静地覆盖、裁剪、遗忘，然后用残缺记忆编造答案。第二种看似稳妥，但一旦 Redis 挂了或网络抖动，整个会话就断在半路，trace 断点不可追溯。第三种我们坚持用了三个月，直到某天凌晨三点发现 WAL 文件写满磁盘，而快照逻辑没做原子切换，导致回滚失败。最后我们砍掉了所有自研状态模块，改用基于 S3 + DynamoDB 的事件溯源架构——不是因为多高明，而是被 context overflow 教会的生存法则。Anthropic 现在把这个方案产品化了，而且做得比我们当年更干净：state 完全脱离 model context，harness 是无状态执行器，session ID 就是唯一入口，awake(sessionId) 调用后自动恢复上下文。这不是“又一个托管服务”，这是把过去一年里无数团队踩过的坑，用工业级工程标准焊死在底座上。

关键词里反复出现的 “Towards AI - Medium”，其实恰恰点出了这件事的本质：它不是一篇技术公告，而是一份行业状态快照。当一家以模型见长的公司，突然把全部工程重心压在一个 runtime 层上，并且定价精确到 $0.08/小时——你得明白，他们不是在卖服务，是在抢时间窗口。因为就在五个月前，AWS Bedrock AgentCore 已经进入通用可用阶段；Google Vertex AI Agent Builder 的 registry 和 Apigee 集成也已上线；Azure AI Foundry 把 AutoGen 和 Semantic Kernel 全部收编进统一控制平面。这场竞赛的起点，从来就不是“谁先做出 agent runtime”，而是“谁能让开发者不费力地把 agent 跑起来，同时不担心 credential 泄露、trace 不可查、会话不可恢复”。Anthropic 的 Managed Agents，本质上是一张面向 Claude 用户的“防流失保单”：如果你要用 Claude，那就别去 AWS 上跑 LangGraph，别在 GCP 上配 Vertex Agent Registry，我们给你一套开箱即用、深度绑定、token 计费无缝衔接的闭环环境。这个逻辑很务实，也很残酷——它承认 runtime 层正在快速 commoditize，所以必须用最快的速度，把用户锁在自己的 token 生态里。

2. 核心设计解构：为什么是“Session-Event-Log”而不是“State-in-Context”

2.1 从崩溃现场还原：context overflow 是怎么悄悄杀死 agent 的

我们去年做的那个金融尽调 agent，流程是典型的“检索→摘要→交叉验证→生成报告”。每一步都调用不同工具：第一步用向量库查年报片段，第二步喂给 Claude-3.5-sonnet 做摘要，第三步调用外部 API 查监管处罚记录，第四步再汇总生成 PDF。整个链路跑下来平均耗时 42 分钟。问题出在第三步之后：当 agent 开始处理第 7 个子问题时，context 已经膨胀到 192K tokens。而当时用的模型 context window 是 200K，表面看还有 8K 缓冲。但实际运行中，模型 tokenizer 会对历史对话做隐式 re-encoding，尤其当 tool call 返回的是带表格、JSON、代码块的长文本时，re-encoding 后体积可能翻倍。结果就是：第 8 步触发时，context 实际占用已达 215K，超出部分被静默截断。更麻烦的是，截断不是从末尾切，而是按 token 重要性权重动态丢弃——最早那几轮的 tool result 就这样被“优化”掉了。agent 没报错，它只是开始基于一个缺失关键证据的上下文做推理。我们直到客户反馈“报告里提到的处罚编号根本不存在”才意识到问题。翻日志发现，最后一次 tool call 的 input 里，已经没有前序的监管数据库返回字段了。

提示：不要依赖模型自身的 context 管理能力。LLM 的 context window 是计算资源边界，不是数据存储层。把它当数据库用，等于把银行金库钥匙交给快递员保管。

Anthropic 的 session-as-event-log 设计，直接绕开了这个陷阱。它的底层实现非常清晰：每次 tool call 的输入、输出、元数据（timestamp、tool name、execution duration、error code）都被序列化为结构化事件，写入独立于 model context 的持久化存储（据其工程博客透露，是基于 S3 + DynamoDB 的分层存储）。model context 里只保留当前 step 所需的最小上下文切片——比如“请基于以下三段摘要生成对比分析”，后面跟着的只是最新一轮的 tool output 摘要，而非全部原始返回。这意味着：

• 即使 model context 被清空或重置，只要 session ID 存在，就能从 event log 中重建任意时间点的完整状态；
• harness 进程崩溃后，awake(sessionId) 调用会自动拉取最新 checkpoint 事件，跳过已成功执行的步骤；
• audit trail 天然存在，无需额外埋点——每个事件自带 trace_id、span_id、principal_id，可直接对接 OpenTelemetry。

2.2 Credential 隔离：为什么“注入环境变量”是生产环境的自杀行为

Credential 管理是另一个血泪教训。我们早期为了快速验证，把 API key 直接写进 Dockerfile 的 ENV 指令里，然后挂载进 sandbox 容器。测试时一切正常，上线第三天就出事：某个 agent 在解析用户上传的 Excel 表格时，误把表头“API_KEY”当成真实字段，调用 curl 时拼接进了 URL 参数。日志里赫然出现 curl https://api.example.com/data?token=sk_live_xxx 。虽然对方 API 有 rate limit，但 key 已泄露。事后复盘发现，问题不在 agent 逻辑，而在 sandbox 的信任模型——它把 credential 当作“运行时配置”，而非“受控资源”。一旦 agent 获得 shell 权限或能构造任意 HTTP 请求，credential 就形同裸奔。

Anthropic 的做法是彻底解耦：credential 不进 sandbox，只进 vault。sandbox 启动时，vault 会动态生成一个短期有效的 bearer token，通过 secure channel 传给 sandbox 内部的 credential proxy service。agent 调用 tool 时，只需声明需要哪个 credential scope（如 salesforce:read , notion:write ），proxy service 自动完成 token 交换、权限校验、调用转发。整个过程对 agent 透明，它甚至不知道真实 credential 长什么样。这种设计借鉴了 AWS IAM Roles for EC2 的思路——不是给实例一把万能钥匙，而是让它临时申领一张有时效、有范围、可审计的工牌。

注意：任何允许 agent 直接读取环境变量、文件系统或内存的 sandbox，都不具备生产级 credential 安全性。真正的隔离，是让 credential 在 agent 视野之外完成生命周期管理。

2.3 Harness 的无状态性：为什么 crash-recovery 必须是默认能力

Harness 是 Managed Agents 架构里最易被误解的部分。很多人以为它就是个“调用模型的胶水层”，实则不然。Anthropic 明确将其定义为 stateless executor，核心接口只有 execute(name, input) → string。这个设计背后有两层深意：
第一，它强制分离关注点。Harness 不负责决策（那是 model 的事），不负责状态（那是 event log 的事），不负责 credential（那是 vault 的事），它只做一件事：把 input 序列化、发给指定 container、等 response、反序列化返回。这种极简主义让 harness 本身几乎不可能出错——没有状态要维护，就没有状态不一致的风险；没有本地缓存，就没有缓存污染的可能。
第二，它为弹性伸缩铺平道路。当某个 session 的 tool call 出现长阻塞（比如调用一个需 5 分钟响应的 legacy 系统），harness 可以优雅超时、释放资源、由负载均衡器将后续请求路由到新实例。而 awakable session ID 机制确保用户无感知——前端看到的只是“稍等，正在处理”，后台早已完成实例切换和状态恢复。

我们曾用 Kubernetes Deployment 管理 harness，结果发现：当节点故障时，Pod 重启会导致 in-memory session state 丢失。后来改成 StatefulSet + PVC，又遇到 PVC 跨 AZ 挂载延迟问题。最终方案是放弃本地存储，所有状态外置，harness 只保留 30 秒的 request-scoped