Agent 运行时架构解析：Session-as-Event-Log 与凭证隔离设计

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

上周二（4月8日），Anthropic 正式开放 Claude Managed Agents 的公开测试。新闻稿里满是“十倍提速”“Notion 和 Asana 已接入”“沙箱执行+会话快照+凭证托管”这类标准话术。技术博客则抛出了一个更耐人寻味的类比：他们把 agent 架构拆解成了稳定抽象层——就像90年代操作系统对硬件的虚拟化那样。Session 是脱离模型上下文、持久存在的事件日志；Harness 是无状态的执行器，只管调用 execute(name, input) → string ；Sandbox 是按需拉起、用完即弃的“牛”，不是需要精心养护的“宠物”。

但剥开所有包装，Managed Agents 的本质非常朴素：它是一个托管式 agent 运行时（hosted runtime）。你用 YAML 或自然语言定义 agent 的系统提示、可用工具、安全护栏；Anthropic 负责运行它。会话能跨天持续；工具调用在隔离环境中发生；凭证永远锁在 vault 里，sandbox 根本碰不到；整个执行过程被完整记录，事后可查、可追溯。计费方式也干脆：$0.08/小时的活跃会话运行时费用，外加常规的 Claude token 费用。Notion 用它让团队在工作区里直接委派任务给 Claude；乐天（Rakuten）建了销售、市场、财务三套 agent，消息路由走 Slack 和 Teams；Sentry 则把自家调试 agent 和一个能写补丁、提 PR 的 Claude agent 链在一起。

这个架构本身确实扎实。尤其是“session 作为事件日志”这一设计，是真正直击痛点的工程判断。状态不再挤在模型上下文里，而是存放在外部可靠存储中。Harness 可以随时崩溃、重启，只要调用 awake(sessionId) 就能从断点恢复。模型的 context window 终于卸下了“唯一状态存储”的重担，回归它最该干的事：理解与生成。

我去年就亲手踩过这个坑。当时跑一个四步检索任务，agent 在第40分钟时，context 窗口被填满。它没报错，也没中断，而是悄无声息地把最早几轮的工具返回结果从上下文中“挤掉”。接着，它开始基于一个残缺的历史记录胡编乱造，最终输出完全不可信的结果。我们不仅丢了整个 session，连回溯都做不到——没有日志，没有快照，没有 trace。失败不是轰然倒塌，而是温水煮青蛙式的昂贵沉默。我们当周就重写了状态层，把它彻底搬出 context window。Anthropic 现在做的，就是把我们那个痛苦一周的补救方案，变成了开箱即用的产品。

另一个常被忽略但生产级至关重要的细节，是凭证隔离。凭证不是在 sandbox 启动时通过环境变量注入的——那种方式等于把钥匙塞进 agent 自己能读的口袋里。Anthropic 的做法是：凭证由平台在 sandbox 外部管理，仅在 tool call 发起瞬间，由平台代理完成认证并传递结果。这背后是血泪教训：你只有在亲眼见过 LLM 把一个本不该暴露的 API token 拼进 curl 命令、然后发往错误地址之后，才会真正理解为什么这种“零信任”设计不是过度工程，而是生存必需。

2. 内容整体设计与思路拆解：一场迟到的防御战，而非开疆拓土

把 Anthropic 这次发布放在整个 AI infra 地图上审视，会发现一个被主流报道刻意模糊的事实：这不是一次开创性发布，而是一场明确的、带着紧迫感的防御战。真正的“ incumbent ”（ incumbents ）根本不是什么神秘新玩家，而是 AWS、Google、Microsoft 这些早已落子的云厂商。

Amazon Bedrock AgentCore 在2025年底就已进入通用可用（GA）阶段。到2026年3月，AWS 官方披露其 AgentCore SDK 在五个月内下载量突破两百万次，配套的策略控制（policy controls）也同步达到 GA。它的每个会话都运行在一个独立的 microVM 中，拥有隔离的 CPU、内存和文件系统，最长可持续运行八小时。最关键的是，它天生框架无关——LangGraph、CrewAI、Strands，或者任何能编译成 request-response 循环的框架，都能跑；模型选择也完全开放，开发者爱用 Claude、Llama 还是 Gemini，Bedrock 都支持。

Google Vertex AI Agent Builder 也早已推出自己的托管 agent 运行时，并通过 Apigee 深度集成了 Agent Registry，让企业能统一发现、治理和调用不同团队开发的 agent。微软则更进一步，直接将 AutoGen 和 Semantic Kernel 整合进 Azure AI Foundry，把 agent 开发、部署、监控、治理打包成一个端到端平台。

所以，当 Anthropic 在2026年4月高调推出 Managed Agents 时，它面对的不是一个空白市场，而是一个已被三大云厂商深度渗透、且已形成事实标准的基础设施层。此时，一个开发者如果想用 Claude 构建 agent，他有至少三个成熟、稳定、且已深度集成进现有云工作流的选择：Bedrock、Vertex、Azure。Anthropic 的问题从来不是“要不要做”，而是“如果不做，我们的 token 买家会不会心安理得地把 agent 运行在 AWS 上？当 AWS 下调 session-hour 价格时，他们换模型会不会比换云服务商还容易？”

这才是这次发布的底层逻辑。媒体把它包装成 Anthropic “定义新范式”，但竞争地图清晰地表明：Anthropic 是在为自己的核心资产——Claude 模型的 token 收入——修筑一道护城河。它不是要赢下 runtime 这个战场，而是要确保，当开发者选择 Claude 时，最顺手、最省事、最无缝的 runtime 就是 Anthropic 自家的。这是一种精明的“垂直整合”，一种典型的“卖铲子的人顺便把矿坑也承包了”的商业策略。

当然，有人会立刻反驳：“Anthropic 根本不在乎 runtime 层！他们只关心卖 token，这完全合理。”这个反驳完全正确，但它恰恰强化了本文的核心论点： runtime 层正在快速 commoditize（商品化），而 Anthropic 刚刚把自己押注在了那个即将被压向零的价格带里。 Anthropic 公司层面或许很健康，因为它卖的是模型推理服务，这是另一条价值曲线。但 Managed Agents 这个产品本身，其技术壁垒和长期定价权，正面临来自云厂商和开源社区的双重挤压。它本质上是一个高效的分发渠道，一个让 Claude token 更容易被消费的“前端”，而不是一个能独立构筑护城河的“平台”。

3. 核心细节解析与实操要点：为什么“Session-as-Event-Log”是灵魂设计

在 Managed Agents 的所有技术细节中，“Session as durable event log” 绝对是那个值得单独拎出来、反复咀嚼的灵魂设计。它不只是一个功能点，而是一种架构哲学的具象化。要理解它的分量，必须先看清传统 agent 架构的“阿喀琉斯之踵”。

3.1 传统模式的致命缺陷：Context Window 是脆弱的单点

绝大多数 DIY agent 系统，其状态管理极度依赖模型的 context window。每一次 tool call 的输入、输出、中间思考链（thought chain）、甚至用户对话历史，都被一股脑塞进这个有限的空间里。以 Claude 3.5 Sonnet 的 200K token 上下文为例，这听起来很大，但实际运行中，它会被迅速吞噬：

• Token 消耗是双向的 ：你发送给模型的 prompt（含 system message + history + current query）消耗 tokens；模型返回的 response 也消耗 tokens。一个长回复可能就吃掉 5K-10K tokens。
• 历史是线性累积的 ：每一轮交互，旧的历史不会自动“压缩”或“归档”，只是简单地追加在末尾。几十轮下来，有效信息密度急剧下降。
• 没有真正的“垃圾回收” ：模型无法主动丢弃它认为“过期”的信息。它只能靠 prompt engineering 强行要求“只关注最后3轮”，但这在复杂多步骤任务中极易失效。

我去年维护的那个 agent 就是典型。它需要：

1. 从知识库检索3份文档；
2. 对每份文档进行摘要；
3. 比较摘要，找出共同点与差异；
4. 生成一份综合分析报告。

整个流程涉及至少12次 tool call（3×检索+3×摘要+3×比较+1×报告+2×校验）。当进行到第8次调用时，context 已经接近饱和。模型开始“遗忘”——它不再引用第一次检索到的文档A的关键结论，转而基于文档B和C的局部信息做推断。更糟的是，当它需要调用一个需要精确参数的工具（比如 search_db(query="documentA_key_conclusion") ）时，它已经记不清 documentA 的 key conclusion 是什么了，于是胡乱拼凑一个 query，结果返回一堆无关数据。整个 session 就这样在无声无息中滑向错误的深渊。

3.2 Managed Agents 的解法：状态外置与事件驱动

Anthropic 的方案，是用一个经典的、经过时间检验的软件工程原则来解决这个问题： 关注点分离（Separation of Concerns） 。

• State Lives Outside the Harness