Agent Runtime 重构：从 Context 依赖到事件日志驱动的会话管理

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

我第一次在生产环境里跑一个多步骤、带外部工具调用的 Claude 代理时，是在 2025 年初。当时没想太多，直接把 session state 全塞进 context window —— 毕竟模型能记住，何必额外存？结果第四步调用 Notion API 后，第五步开始查 Slack 历史消息，第六步要汇总写周报……到第 38 分钟，context 已经撑到 192K tokens，模型突然开始编造上周根本没开过的会议纪要，还顺手伪造了参会人签名。更糟的是，我们没法回溯：没有日志、没有 checkpoint、没有可重放的 trace。整个 session 就像被抽走脊椎的蛇，软塌塌瘫在 terminal 里，连 debug 都无从下手。

Anthropic 在 2026 年 4 月 8 日发布的 Claude Managed Agents ，表面看是一次常规功能更新，但内核解决的，正是我当年那个凌晨三点对着空白 terminal 抓头发的问题。它不是“又一个 agent 框架”，而是把 agent 运行时（runtime）这个层，第一次真正当成操作系统来设计：session 是持久化事件日志，harness 是无状态执行器，sandbox 是按需生成的 cattle。这三者拆开，每一块都直指过去两年我们在真实项目里反复踩坑的痛点。

你不需要是架构师才能理解它的价值。你可以把它想象成手机里的 iOS 系统 —— App（你的 agent）运行在沙盒里，系统（Anthropic）统一管理内存、网络、权限和崩溃恢复；App 自己不用操心怎么申请摄像头权限、怎么保存用户相册、怎么在后台续传大文件。以前你得自己写一套“iOS”，现在 Anthropic 把这套系统做出来了，而且默认就支持 Claude 3.5 Sonnet 和 Opus。

关键词里提到的 Towards AI ，其实是这篇分析的原始发布平台，但它背后折射出的是整个行业正在发生的位移：技术媒体还在报道“Anthropic 发布新功能”，而一线工程师已经默默把旧版 LangChain + 自建 Redis state store 的代码库归档，开始改 YAML 配置文件。这不是 hype，是 runtime 层正在经历的“Windows 95 式”基础设施切换 —— 当底层足够稳定，上层应用才敢大规模爆发。而这次切换的临界点，就是 session 不再寄生在 context 里，而是成为独立、可查询、可审计、可重放的一等公民。

2. 核心设计逻辑：为什么必须把 state 拉出 context 窗口？

2.1 Context 窗口从来就不是为 state 存储设计的

我们先算一笔账。假设你用 Claude 3.5 Opus，context 窗口是 200K tokens。一个典型企业级 agent session 包含什么？

• 系统提示词（system prompt）：约 1.2K tokens
• 用户初始问题 + 多轮对话历史：保守估计 8K–15K tokens
• 工具调用返回结果（Notion 页面内容、Slack 消息列表、Sentry 错误堆栈）：单次平均 3K–7K tokens，5 次调用就是 15K–35K
• 中间推理链（chain-of-thought）、计划树（plan tree）、子任务分发记录：每次 2K–4K，10 步就是 20K–40K

加起来， 不超 30 分钟，context 就已逼近 120K–150K tokens 。而模型不会优雅地告诉你“我要溢出了”，它只会悄悄截断最老的 token —— 通常是第一步调用的 Notion 文档摘要，或是第二步确认的用户权限范围。你得到的不是错误，而是静默失真：模型基于一个被裁剪掉关键上下文的残缺记忆继续推理，输出看起来合理，实则根基已塌。

提示：我在 2025 年 Q3 做过一次压测，用相同 prompt 和工具集，在 context 限制为 128K 和 200K 下分别跑 100 个长流程任务。结果是：128K 组的 hallucination 率为 37%，其中 68% 的错误源于早期 tool result 被截断；200K 组下降到 22%，但仍有 41% 的失败可追溯至 context 内部 state 管理混乱（如混淆两个不同用户的 Slack channel ID）。这证明：单纯扩大窗口只是缓兵之计，根治方案是让 state 彻底离场。

Anthropic 的解法很干净： Session = Event Log 。每一次 tool call、每一次 model output、每一次 guardrail 触发、每一次 human-in-the-loop 审批，都被序列化为结构化事件，写入外部持久化存储（具体实现未公开，但工程博客暗示是基于时间戳+session ID 的 append-only log）。Harness（执行器）只负责读取最新事件、调用模型、生成下一步 action，然后把结果作为新事件追加。模型 context 里只保留当前 step 所需的最小上下文 —— 比如“用户刚批准了 PR，现在需要生成 release note”，而不是整段 Git diff 和前 7 次 commit message。

2.2 Harness 无状态化：崩溃不是终点，而是 resume 的起点

传统 agent 架构里，harness（执行循环）往往承载着大量隐式状态：当前 step 编号、待处理的 tool result 队列、retry 计数器、timeout 计时器……一旦进程崩溃或节点重启，整个 session 就宣告死亡。我们曾因此在灰度发布时损失过客户连续 3 天的自动化财务对账数据。

Managed Agents 的 harness 设计哲学是： 它应该像 HTTP handler 一样轻量、可丢弃、可水平扩展 。所有决策依据只来自两处：1）session event log 的最新快照；2）当前输入（user message 或 timer trigger）。这意味着：

• 你可以随时 kill 掉正在运行的 harness 实例，只要 session ID 不变，新实例启动后调用 awake(sessionId) 就能从上次中断处无缝继续；
• 你可以为高优先级 session 分配专用 harness 实例，为低优先级 session 使用共享池，资源调度完全解耦；
• harness 本身不存 credential、不缓存敏感数据、不维护 long-lived connection —— 它就是一个纯函数： input → model call → event write → next input 。

这个设计直接对应了工程博客里那句“Harness as stateless executor that calls containers via execute(name, input) → string ”。注意， execute() 返回的是 string，不是 JSON object 或复杂结构。这是刻意为之的约束：强制所有 tool output 必须经过序列化/反序列化，杜绝 harness 内部状态污染。我试过把一个原本依赖内存 cache 的 PDF 解析工具封装进去，第一版返回了 Python dict，结果 harness 直接报错；改成返回 JSON string 后，一切正常 —— 这个“麻烦”恰恰是稳定性的代价。

2.3 Sandbox 即 cattle：隔离不是目的，是规模化运维的必然选择

很多人看到“sandboxed execution”第一反应是安全。没错，credential 隔离确实关键（后面详述），但 Anthropic 真正想解决的，是 运维层面的确定性 。

我们曾用 Docker 容器跑 agent tool，每个 session 启一个 container。问题很快浮现：容器启动耗时 800ms–1.2s，高峰期并发 200+ session，光是容器调度就吃掉 3 分钟；更糟的是，某个用户上传了恶意 PDF，触发了 ImageMagick 的远程代码执行漏洞，整个宿主机被拿下 —— 因为容器共享内核，且我们没做严格的 seccomp profile。

Managed Agents 的 sandbox 是“cattle，not pets”：按需创建、用完即焚、规格统一、不可登录。工程博客没明说技术栈，但从性能指标（p50 time-to-first-token ↓60%）和 AWS AgentCore 的 microVM 对比来看，极可能是基于 lightweight VM（如 Firecracker）或强隔离容器（gVisor）