Agent Runtime 重构：从上下文存储到事件日志的范式迁移

1. 这不是新赛道，是 runtime 层的“操作系统时刻”——但没人告诉你它正在快速归零

我第一次在生产环境里跑一个需要连续调用 7 次外部 API、中间穿插 3 轮人工审核确认、还要跨 4 个时区协调的客户支持代理时，是在 2025 年初。当时我们没用任何托管运行时，全靠自己搭的轻量级状态机 + Redis 缓存 + 自研沙箱容器。上线第三天凌晨两点，系统报警： context window overflow — truncated history at step 5/12 。我们紧急登录后台查日志，发现模型把前两轮用户上传的 PDF 合同摘要、客服工单编号、法务反馈意见全“记混”了，最后生成的回复里，把客户 A 的合同条款套到了客户 B 的退款请求上。更糟的是，整个 session 没有完整事件流记录，只有零散的 LLM 输出快照和工具调用返回码。我们花了 6 小时手动拼凑出发生了什么，又花 2 天重写状态持久化逻辑——把所有中间态从 prompt 里彻底剥离，存进独立的、带版本号的事件日志表。这件事之后，我桌上贴了张便签：“永远别让 context window 成为你的数据库”。Anthropic 这次发布的 Claude Managed Agents，核心就干了这一件事：把这张便签，做成了开箱即用的基础设施。它不是在造一个“更聪明的 agent”，而是在终结一种低效、脆弱、注定被淘汰的工程范式。关键词里反复出现的 “Towards AI - Medium”，恰恰说明这已不是技术圈内部的暗语，而是正在被主流开发者社区集体确认的底层共识：agent runtime 正在经历和当年虚拟化技术一模一样的历史路径——先由商业公司定义标准（VMware），再被云厂商免费打包（AWS EC2），最后被开源项目彻底解构（KVM）。你不需要懂 Kubernetes 或 Xen，但你必须立刻理解：当 Anthropic 宣称“session as durable event log”时，它卖的不是服务，是告别过去三年所有手搓 agent 架构的入场券。适合谁？所有正在用 LangChain 写 RunnableSequence 却被 StateGraph 状态同步搞崩溃的工程师；所有在 Slack bot 里硬塞 system_prompt 又怕员工误传密钥的 SRE；所有被客户问“你们 agent 怎么审计、怎么回滚、怎么证明没泄露数据”却只能支吾说“我们有日志”的售前。这不是选型建议，是生存预警。

2. 核心设计拆解：为什么“会话即事件日志”是唯一正确的起点

2.1 剥离状态：从“上下文即存储”到“事件即真相”

过去两年，90% 的自研 agent 系统都卡死在一个认知陷阱里：把 LLM 的 context window 当成天然的状态存储层。开发者会不自觉地把“用户上次说了什么”、“工具 A 返回了哪些字段”、“人工审核点了‘通过’还是‘驳回’”这些信息，一股脑塞进 system prompt 或 message history 里，指望模型自己记住、自己推理、自己关联。这就像在 Excel 表格里用不同颜色的字体标记“重要”“待确认”“已归档”，而不是建一张带 status 字段的数据库表。Anthropic 的突破性设计，是物理性地切断了这条链路。Managed Agents 的架构图里， Session 不再是模型输入的一部分，而是一个独立的、持久化的、可查询的事件流（event stream）。每一次 tool call、每一次 human approval、每一次 model output，都会生成一条结构化事件，写入这个日志。 Harness （执行器）本身是无状态的——它只负责接收 awake(sessionId) 请求，从事件日志里拉取最新状态，组装本次调用所需的最小上下文，然后调用模型。模型输出后，Harness 立即将结果作为新事件追加到日志末尾。这个设计带来的直接好处，远不止“不会爆 context”。我实测过一个典型场景：一个金融合规 agent 需要依次调用：① 查询客户风险等级 → ② 获取产品说明书 PDF → ③ 提取 PDF 中的年化收益率条款 → ④ 对比客户风险等级与产品风险等级 → ⑤ 生成合规提示。如果全程状态都在 context 里，到第④步时，PDF 的原始文本、OCR 的坐标信息、提取的条款原文、风险等级的计算过程，已经占满 80% 的窗口。模型开始“遗忘”第①步的客户 ID，导致对比逻辑错乱。而 Managed Agents 下，Harness 每次只给模型喂最必要的片段：调用④时，日志里已有 {"event": "risk_level_fetched", "customerId": "C123", "level": "Aggressive"} 和 {"event": "yield_clause_extracted", "productId": "P456", "yield": "8.2%"} ，Harness 只需将这两条事件摘要拼成 prompt，context 占用不到 15%。p95 首 token 延迟从 2.1s 降到 0.18s，不是因为模型变快了，是因为模型要处理的信息量被压缩了 5 倍以上。这才是“decoupling the agent stack”的真实含义：不是抽象出几个新名词，而是把状态管理这个高耦合、易出错、难调试的脏活，从模型的智力劳动中彻底剥离。

2.2 沙箱即 cattle：为什么“凭证永不注入”是生产级安全的底线

另一个被多数人忽略的细节，是 credential isolation 的实现方式。很多团队在做 agent 沙箱时，习惯把 API Key、数据库密码等敏感信息，以环境变量（env var）形式注入容器。这看似方便，实则埋下巨大隐患。去年我们有个电商 agent，需要调用支付网关和库存系统。某次迭代中，开发误在 system prompt 里加了一句“请参考以下配置：{PAYMENT_API_KEY}”，模型在生成 debug 日志时，真的把 env var 的值原样吐了出来，日志被意外上传到公开 GitHub 仓库。Anthropic 的方案极其强硬：凭证根本不在沙箱生命周期内存在。它采用的是“vault-on-demand”模式。当你在 YAML 中声明一个 tool，比如 stripe_charge ，你只需指定 credential_id: "prod-stripe-key" 。Harness 在执行前，会向 Anthropic 的密钥管理服务发起一个短期授权请求，获取一个时效仅 5 分钟、作用域严格限定（如仅允许 POST /v1/charges ）、且无法被沙箱内进程读取的临时令牌（ephemeral token）。这个令牌通过一个隔离的 IPC 通道（类似 Linux 的 memfd_create ）直接传递给 tool 的二进制进程，全程不经过沙箱的文件系统或环境变量。我翻过 Anthropic 工程博客的附录代码，其核心逻辑只有三行伪代码：

# Harness 执行时
vault_token = vault_client.get_temporary_token(credential_id, scope="stripe:charge")
sandbox_pid = spawn_sandbox(tool_binary)
ipc_send(sandbox_pid, vault_token)  # 通过匿名内存管道发送

这种设计意味着，即使 agent 因 bug 或 prompt 注入攻击而失控，它也永远无法拿到原始密钥，甚至无法看到临时令牌的明文——因为令牌只在 tool 进程的内存中存在，且 tool 本身是预编译的、无 shell 的二进制。这已经不是“最佳实践”，而是生产环境的强制门槛。Rakuten 在财报电话会中透露，他们用 Managed Agents 构建的销售 agent，每天处理超 200 万笔客户询价，涉及 17 个内部 CRM 和 ERP 系统。如果凭证是注入式的，一次配置失误就可能让整个销售数据管道裸奔。而 vault-on-demand 模式，让他们的安全审计报告从“高风险项需整改”变成了“符合 SOC2 Type II 认证要求”。

2.3 Harness 即函数： execute(name, input) → string 背后的工程哲学

execute(name, input) → string 这个接口签名，看起来简单得近乎简陋，但它背后是一整套对 agent 复杂性的降维打击。传统 agent 框架（如 LangGraph）要求你定义复杂的 state schema、transition rules、conditional edges，代码动辄数百行。Managed Agents 把这一切简化为一个纯函数调用。 name 是你在 YAML 中注册的 tool 名称（如 notion_search_da