Agent Runtime 重构：Session-as-Event-Log 与无状态 Harness 实践

1. 这不是新赛道，是 runtime 层的“操作系统时刻”正在重演

你打开终端敲下 curl 命令调用一个 AI agent，它开始读取 Notion 页面、查询 Slack 历史、调用 Sentry API 抓取错误堆栈，最后在 GitHub 上提一个带测试用例的 PR——整个过程持续 27 分钟，中间经历三次工具调用失败重试、一次模型上下文溢出自动回滚、两次人工审批介入。任务结束时，你没收到“成功”或“失败”的弹窗，而是打开一个时间线视图，看到每一步操作的输入/输出、耗时、凭证使用痕迹、决策依据的 token 概率分布，甚至能点击某次 curl 调用，直接跳转到该请求在 AWS CloudTrail 中的原始日志条目。

这不是科幻设定。这是 Anthropic 在 2026 年 4 月 8 日发布的 Claude Managed Agents 公测版所支撑的真实工作流。但真正值得你花五分钟细读这篇文章的原因，不是 Anthropic 又推了个新产品，而是它背后那个被所有人轻描淡写带过的词： runtime 。

我过去三年亲手搭过七套生产级 agent 系统，从用 LangChain 写死在 Flask 里的单体服务，到基于 Kubernetes 自建 sandbox 集群跑 CrewAI 的混合编排平台，再到给某跨国银行定制的、把金融合规检查嵌进每个 tool call 的 policy-first 架构。所有这些系统，最终都卡在一个地方： 状态存哪？凭证放哪？失败了怎么回放？谁来保证这次调用的 curl 不会把 AWS_ACCESS_KEY_ID 打印进日志？

Anthropic 没发明新概念，它只是把我们熬了两年夜、踩了三轮坑才想明白的工程共识，打包成 YAML 文件和一个 awake(sessionId) 接口，扔到了开发者面前。它叫 Managed Agents，但内核是 Session-as-Event-Log + Harness-as-Stateless-Executor + Sandbox-as-Cattle —— 这三个短语，每一个都对应着过去一年里我团队在凌晨三点 Slack 频道里反复争论、推翻、重写的架构决策。而 Anthropic 的工程博客里，它们被轻巧地类比为“90 年代操作系统对硬件的虚拟化”。这个类比不是修辞，是预警。

为什么说“Layer That’s Already Going to Zero”？因为 runtime 层的价值锚点，从来就不是“能不能跑”，而是“跑得有多稳、多可审计、多难被绕过”。当 AWS AgentCore 已经用 microVM 实现纳秒级进程隔离，当 Vertex AI Agent Builder 的 registry 支持跨云部署同一 agent 定义，当 Azure AI Foundry 把 AutoGen 的 subagent 调度逻辑直接编译进 WASM runtime——你卖的就不再是“执行能力”，而是“执行的可信证明”。而可信证明，正被快速压缩成基础设施的默认属性。就像今天没人会为“Linux 能 fork 进程”单独付费一样，明年也不会有人为“agent 能安全调用 API”付溢价。

所以这篇文章不讲“Managed Agents 怎么用”，它要拆解的是： 当你决定把 agent 运行时交给 Anthropic（或 AWS、Google、Microsoft）时，你真正买断的是什么？放弃的是什么？以及，你手里的 trace log、policy rule、vertical workflow，如何在 runtime 层归零后，成为你唯一不可替代的资产？ 这不是技术选型指南，是面向未来十八个月的生存策略。

2. 核心设计解构：为什么是 Session-as-Event-Log，而不是 Context-as-Database？

2.1 一个被上下文窗口谋杀的四十分钟任务

去年 Q3，我们为一家医疗设备公司搭建一套临床试验数据核查 agent。流程很清晰：第一步，从 PDF 报告中提取受试者编号；第二步，用编号查 EDC 系统获取原始录入数据；第三步，比对 PDF 描述与 EDC 记录的差异；第四步，生成结构化报告并邮件通知监查员。整个链路用 LangChain 的 RunnableSequence 编排，系统提示词里明确写了“请严格按步骤执行，每步结果必须保存”。

前 35 分钟一切顺利。第 36 分钟，agent 开始处理第 17 份 PDF，上下文窗口已塞满前 16 份的提取结果、EDC 查询返回的 JSON、比对逻辑的中间变量。模型开始“遗忘”——它把第 1 份 PDF 的受试者编号，错当成第 17 份的编号去查 EDC。更糟的是，它没报错，而是用伪造的编号返回了一段格式完美的假数据，接着用这段假数据生成了“无差异”的核查报告。整个 session 在静默中崩塌。我们无法回放，因为所有中间状态都随上下文一起被丢弃；我们无法 debug，因为日志里只有最终输出，没有决策路径；我们甚至无法确认问题出在哪一步——是 PDF 提取错了？EDC 查询超时返回了缓存？还是模型自己编造了数据？

这就是 Context-as-Database 模式的致命缺陷：它把运行时状态（state）和推理上下文（context）混为一谈。模型的 context window 是为 推理 设计的，不是为 状态持久化 设计的。它的容量有限、访问随机、生命周期短暂。而 agent 的 state 需要的是： 持久（persist）、可追溯（traceable）、可审计（auditable）、可恢复（recoverable） 。Anthropic 的 Session-as-Event-Log，本质是把这四个需求，从模型的负担里彻底剥离。

2.2 Event-Log 如何重构 agent 的生命线

Anthropic 的 session 并非简单地把每次 tool call 的输入输出存进数据库。它的 event log 是一个 有向无环图（DAG） ，每个节点包含：

• 事件类型 ： system_prompt_set 、 tool_call_start 、 tool_call_success 、 tool_call_error 、 model_output 、 human_approval_requested 、 session_resumed ；
• 结构化 payload ： tool_call_start 事件里，payload 不仅包含调用的 tool name 和 input，还包含该调用的 前置依赖事件 ID 列表 （例如，“本次 Sentry 查询依赖于上一步 Slack 消息解析的结果”）；
• 元数据 ：精确到微秒的时间戳、执行 harness 的唯一 ID、sandbox 的 hash 值、本次事件消耗的 tokens（in/out）、 凭证 vault 的审计 ID （证明凭证未被 agent 读取）；
• 因果链标记 ：每个 tool_call_success 事件会显式标注“此结果将用于后续事件：[event_id_1, event_id_2]”，形成可验证的因果图谱。

这意味着，当你的 agent 因网络抖动在 tool_call_start 后卡住，你可以随时调用 awake(sessionId) ，Harness 会从 event log 中找到最后一个 tool_call_start 事件，重新启动一个 sandbox，加载相同的环境，并精准地从那一步继续执行—— 不是从头开始，不是靠模型记忆，而是靠事件图谱的确定性重放 。这解决了我们之前所有自研系统最头疼的“长尾失败”问题：网络超时、API 限流、模型响应延迟，都不再导致 session 丢失，因为失败点本身就是 log 中的一个可定位节点。

提示：Anthropic 的 event log 默认保留 90 天，但关键在于它的 schema 是开放的。你可以通过其 /v1/sessions/{id}/events API 获取完整 DAG，然后用 Apache Arrow 或 DuckDB 做实时 OLAP 分析。我们团队上周刚用这个能力，发现某类财务 agent 的 tool_call_error 事件中，73% 的错误发生在 bank_statement_parse 工具调用后的 200ms 内——这直接指向了 PDF 解析服务的内存泄漏，而非 agent 逻辑问题。这种根因定位，在 context-based 系统里是不可能的。

2.3 Harness：为什么必须是“无状态”的执行器？