Agent Runtime 已成基础设施：告别自建，聚焦 Trace、Policy 与垂直智能

1. 这不是新赛道，而是 runtime 层的“临终公告”

上周四（4月8日，2026年），Anthropic 宣布 Claude Managed Agents 进入公开测试阶段。新闻稿里写着“十倍提速”“Notion 和 Asana 已接入”“沙箱执行+会话快照+凭证托管由 Anthropic 全权负责”，技术博客则用更克制的语言描述：他们把 agent 架构拆成了三个稳定抽象层——Session（持久化事件日志）、Harness（无状态执行器）、Sandbox（按需拉起的隔离环境）。p50 首 token 延迟下降约 60%，p95 稳定性优于 90%。这些数字很亮眼，但真正值得你停下来看一眼的，不是“Anthropic 又做了什么”，而是“为什么偏偏是现在，而且是以这种方式”。

我用“临终公告”这个词，不是危言耸听，而是基于过去三年亲手搭过七套生产级 agent 系统的真实体感。Managed Agents 的核心设计——session 作为外部事件日志、harness 无状态、sandbox 按需销毁——本质上是对一个早已被反复验证、却长期被忽视的工程事实的正式承认： 模型上下文窗口从来就不该是你的状态存储层 。它不是数据库，不是 Redis，更不是你业务逻辑的备份盘。把它当状态层用，就像把冰箱当保险柜——短期能塞进去，时间一长，东西发霉、标签脱落、开门时还可能砸到脚。

关键词“Towards AI - Medium”背后代表的是一类典型读者：不是刚学 Python 的大学生，也不是只看 Demo 视频的 CTO，而是每天在 LangChain、LlamaIndex、CrewAI 之间切来切去，在本地跑通后上云就崩、在测试环境 OK 上线就丢 session 的一线工程师。你们知道 context overflow 是什么味道——不是报错红屏，而是凌晨三点收到告警，发现用户提交的报销单被自动改成“请报销我的火星殖民地建设费”，而日志里只有一行模糊的 context truncated at position 32768 。这种失败不吵闹，但昂贵得让人失眠。

Anthropic 这次没发明新轮子，他们只是把行业里最痛的那个补丁，缝进了一件剪裁合体的西装里。YAML 定义 agent 行为、沙箱内 credential 隔离、$0.08/小时的 session 运行计费——这些都不是魔法，而是过去两年我们团队在 AWS Lambda + ECS + Secrets Manager 上踩坑踩出来的标准答案。区别在于，Anthropic 把这套方案封装成服务，开箱即用；而你如果自己搭，光是搞定 sandbox 内 credential 注入不泄露这一项，就得花掉两个高级工程师两周时间，还得祈祷下次 CVE 不爆在你用的容器运行时里。

所以，这不是一篇教你“如何快速上手 Managed Agents”的入门指南。这是一份给正在评估是否要自建 agent runtime、是否要押注某家初创公司、或者正被老板追问“为什么我们的销售 agent 总在第三步掉链子”的工程师写的战地笔记。接下来我会一层层拆开这个“已注定走向零价”的 layer：它到底解决了什么真问题，为什么 AWS 五个月前就交了卷，以及——更重要的是——当 runtime 本身变成水电煤一样的基础设施时，你该把精力和预算，投向哪一层才不会在未来十八个月内发现自己在维护一个正在快速贬值的资产。

2. 核心设计解构：为什么 Session 必须是事件日志，而不是上下文快照

2.1 “Session-as-Event-Log” 不是架构炫技，而是对失败模式的精准外科手术

先说一个真实案例。去年 Q3，我们为一家跨境物流客户上线了一个“智能运单异常处理 agent”。流程分四步：1）解析用户上传的 PDF 运单；2）调用 DHL API 查询实时轨迹；3）比对合同条款判断是否触发赔偿；4）生成中英文赔偿说明并邮件发送。整个流程设计时预估耗时 12 分钟。上线第一周，p95 响应时间稳定在 14 分钟以内。但到了第二周，开始出现诡异现象：用户反馈“系统说已处理完成，但没收到邮件”，后台日志显示第 4 步执行成功，可邮件服务提供商的 webhook 日志里根本没有那条记录。

排查三天后，真相浮出水面：模型上下文在第 3 步结束时已逼近 Claude 3.5 Sonnet 的 200K token 上限。当第 4 步需要注入邮件模板、收件人列表、附件元数据时，LLM 自动执行了“智能截断”——它没有报错，而是静默丢弃了最早加载的 PDF 解析结果（约 18K tokens），转而保留了最新调用的 DHL API 返回体（含大量冗余字段）。于是，agent 在缺失原始运单信息的情况下，凭记忆“脑补”出一封格式正确但内容全错的邮件，再调用 SMTP 接口发送——而那个接口，恰好不校验收件人真实性，只管发。

提示：这不是模型 bug，而是上下文管理机制的必然结果。所有主流 LLM 的 context window 都是 FIFO（先进先出）缓冲区，而非 LRU（最近最少使用）缓存。当你持续追加 token，最老的内容必然被挤出，且模型自身无法感知这一过程。它看到的永远是“当前上下文”，而不知道“当前上下文”已经残缺。

Anthropic 的 Session-as-Event-Log 正是针对此病灶的根治方案。它把 session 拆成两个物理实体：

• Harness 层 ：纯粹的执行引擎，只做三件事——接收 execute(tool_name, input) 请求、调用对应工具、返回字符串结果。它不保存任何状态，不记住历史，甚至不关心这次调用是第几步。你可以随时 kill 掉这个进程，只要 sessionId 不变，下一次 awake(sessionId) 就能从上次中断处继续。
• Session Store 层 ：独立的、持久化的事件日志服务。每次 tool call 的输入、输出、时间戳、调用者身份、沙箱 ID 全部以结构化事件（如 JSONL）写入。这个 store 可以是 S3 + Athena，可以是 TimescaleDB，也可以是 Anthropic 托管的专用服务。关键是——它与模型推理完全解耦。

这种分离带来的直接收益，远超性能数字：

• 可审计性 ：当用户投诉“你们赔错了”，你不再需要翻三天前的千行日志大海捞针。只需查 SELECT * FROM session_events WHERE session_id = 'xxx' ORDER BY timestamp ，就能还原出每一步的原始输入和机器输出，连模型生成的中间思考链（if enabled）都清晰可见。
• 可重放性 ：发现 bug 后，开发无需复现整个用户操作流。直接用 session log 中的 events 重放，精准定位是工具返回异常，还是模型解析逻辑有误。
• 可迁移性 ：当你要把 agent 从 Anthropic 迁移到 Bedrock AgentCore，或从云端迁回私有集群，唯一需要适配的只有 Harness 的 execute() 接口协议。Session log 格式是标准的，事件语义是稳定的，业务逻辑不随 infra 变动而失效。

2.2 Credential 隔离：不是安全合规的装饰品，而是生产环境的生存底线

再聊一个更隐蔽、但杀伤力更强的设计细节：credential 隔离。Managed Agents 文档里轻描淡写一句“credentials live in vau