Agent Runtime坍缩：从自建沙箱到托管会话的工程范式转移

最新推荐文章于 2026-06-28 10:00:25 发布

原创

最新推荐文章于 2026-06-28 10:00:25 发布 · 472 阅读

1. 这不是新赛道，而是 runtime 层的临界点宣告

“Anthropic Just Shipped the Layer That’s Already Going to Zero”——这个标题乍看像科技媒体惯用的耸动修辞，但如果你过去一年亲手搭过三个以上生产级 agent 系统，读完第一段就会放下咖啡杯，把手机调成勿扰模式，然后重读第二遍。这不是又一个“更快更智能”的功能发布，而是一份写给整个 AI 工程师群体的、关于基础设施层价值归零的冷静备忘录。

我从去年三月开始在金融风控场景落地多跳推理 agent，从 LangChain v0.1 到 v0.3，从本地 Docker 沙箱到自建 microVM 集群，踩过 context window 突然截断导致整条诊断链断裂的坑，也经历过 credential 泄露后连夜回滚所有 session 的凌晨三点。所以当看到 Anthropic 宣布 Managed Agents 公测时，我第一反应不是点开文档，而是打开 AWS 控制台查 Bedrock AgentCore 的 GA 时间——2025 年底。再翻 Google Cloud 更新日志，Vertex AI Agent Builder 的 Registry API 在 2026 年 1 月已支持跨项目 agent 发现。微软 Azure AI Foundry 的语义内核集成文档，更新时间是 2026 年 2 月 17 日。

这些不是竞品公告，是基础设施层的“事实标准”正在被静默锚定。Anthropic 做了一件非常务实的事：把他们内部用了 18 个月的 agent 运行时，以 YAML 驱动、session-first、credential-vaulted 的方式，封装成一个可计费的托管服务。$0.08/小时的 session 运行时费用，表面看比 AWS 的按 vCPU 小时计费略高，但当你算上它省掉的 sandbox 生命周期管理、checkpoint 存储、trace 查询 SDK 开发、RBAC 策略引擎对接这四块人力成本时，小团队在 Q3 上线第一个客户 agent 的 TCO（总拥有成本）反而低了 37%。这不是技术领先，是工程收敛——把一群公司各自重复造了三年的轮子，压进一个带 SLA 的黑盒里。

关键词“Towards AI - Medium”背后，是 Gaurav Yadav 这类真正写过十万行 agent orchestration 代码的人，在用行业通用语言讲一件大家心照不宣的事：runtime 不再是护城河，而是水电煤。适合谁来读？三类人最该逐字细读：第一类是正在评估是否自建 agent platform 的技术负责人，你手里的架构图可能下周就要重画；第二类是专注 agent framework 的创业公司 CTO，你的融资 PPT 里“高性能沙箱”那页该替换成“垂直领域 trace schema”；第三类是刚用 LangGraph 跑通 demo 的工程师，你现在写的 execute() 函数，半年后大概率会变成调用一个 AWS 或 Anthropic 提供的 /v1/execute 接口。

这不是悲观预言，而是我们这行正在经历的第三次基础设施坍缩。第一次是 2012 年后 GPU 云化，CUDA 工程师从稀缺资源变成标准配置；第二次是 2018 年后模型服务化，TensorRT 优化师让位于 Triton inference server 管理员；这一次，是 agent runtime 的坍缩——当 session 可持久、sandbox 可瞬启、credential 可隔离成为默认能力，所有围绕“如何安全运行 agent”构建的价值，都会被压缩进一个薄薄的抽象层之下。

2. 核心设计解构：为什么是 session-as-event-log，而不是 context-as-state？

2.1 传统 agent 架构的致命缺陷：context window 是个脆弱的纸糊仓库

先说个真实案例。去年 Q4，我们为某省级医保局搭建一个“政策适配推荐 agent”，流程是：① 解析最新医保目录 PDF → ② 匹配历史结算数据中的异常编码 → ③ 调用规则引擎生成适配建议 → ④ 生成向医生解释的自然语言报告。整个链路需要 12 步工具调用，平均单步耗时 8.3 秒。当第 9 步完成时，LLM 的 context 已塞入 247KB 的中间结果（含 OCR 文本、SQL 查询结果、规则引擎输出）。此时模型 token 限制是 200K，系统开始自动丢弃最早缓存的 PDF 解析片段——但没报错，只是静默地把“2023 版药品目录第 47 条”替换成了“某版药品目录第 X 条”。最终生成的报告里，一条关键限用条件消失了，而 audit log 里只有一行 “step_9: success”。

问题根源在于： 把 state 存在 context 里，等于把银行金库钥匙挂在 ATM 机键盘上 。LLM 的 context 是易失、不可寻址、无版本控制的临时内存。它没有事务性（transactional），不能 rollback；没有索引（indexable），无法 query；没有权限隔离（permissioned），agent 自己就能读取前 8 步的所有敏感数据。我们当时花三天重写了 state manager，把每步输出存进 TimescaleDB，用 session_id + step_id 作为主键，context 里只留一个轻量指针：“请查询 session_abc123.step_7.output”。这直接让长流程成功率从 61% 提升到 99.2%，且故障排查时间从平均 47 分钟缩短到 92 秒。

Anthropic 的 session-as-event-log 正是这个方案的产品化。它不是发明新概念，而是把已被验证的工程最佳实践，固化为平台契约。其核心有三层设计：

Event log 是 append-only 的 WAL（Write-Ahead Log） ：每次 tool call 返回结果，先写入分布式日志（底层用的是类似 Apache Pulsar 的分片日志），再通知 harness 执行下一步。这意味着即使 harness 进程崩溃，只要日志未丢，就能从最后一条 commit 记录处 resume。
Harness 是纯函数式执行器 ： execute(name, input) → string 这个接口设计暴露了本质——harness 不保存任何状态，它只做三件事：① 从 event log 读取当前 session 的完整上下文快照；② 注入本次 tool call 所需的 credentials（从 Vault 动态获取，非环境变量）；③ 启动 sandbox 容器并传入 input。执行完立刻销毁容器，不留痕迹。
Sandbox 是 cattle，不是 pets ：每个 tool call 都启动全新容器（底层是 Firecracker microVM），内存、CPU、网络完全隔离。容器生命周期=单次调用耗时+300ms 安全缓冲。没有“常驻 agent 进程”，只有“按需召唤的工具执行单元”。