Agent Runtime层的范式革命：从Prompt上下文到事件日志

最新推荐文章于 2026-06-27 15:11:29 发布

原创

最新推荐文章于 2026-06-27 15:11:29 发布 · 348 阅读

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

你有没有试过让一个 AI 代理连续工作四十分钟？不是闲聊，而是真正在查资料、调 API、写代码、改文档——一环扣一环地推进一个真实业务流程。我去年就带着团队跑过这样一个销售线索自动归因+竞品动态抓取+周报生成的端到端 agent 流程。前38分钟一切丝滑：它从 Salesforce 拉出线索列表，用 SerpAPI 查竞品新闻，调用内部风控 API 做合规校验，再把结构化结果喂给 Claude 生成带数据看板的 Markdown 周报。直到第39分17秒，它突然开始胡说八道——把上周三的会议纪要当成今天的新闻摘要发给了销售总监。

我们翻日志，没报错；看 token 计数，还没到上限；重放最后三步，它又对了。折腾两小时后才发现：它的整个 session 状态全堆在 prompt context 里，40分钟下来，上下文早已溢出。模型不是“爆内存”，而是悄悄把最早调用的 SerpAPI 返回结果给挤掉了。它后面所有推理，都是基于一个被截断、被污染的历史做出来的。更糟的是——我们根本没法回溯。没有完整事件流，没有工具调用快照，没有 credential 使用痕迹。那个 session 就像一滴水蒸发在沙漠里，连水渍都没留下。

Anthropic 在4月8号发布的 Claude Managed Agents ，表面看是又一个“AI agent 托管服务”，但真正击中痛点的，是它把“session”从模型上下文这个脆弱容器里彻底解放出来，变成一个独立、持久、可查询、可审计的 事件日志（event log） 。这不是功能升级，是架构范式的切换。它和 AWS Bedrock AgentCore、Google Vertex AI Agent Builder、Azure AI Foundry 一起，共同确认了一件事： agent runtime 层已经不再是“要不要建”的问题，而是“谁来定义标准接口”的争夺战 。而这场战争的胜负手，不在于谁的 sandbox 启动快100ms，而在于谁能让开发者在换掉 runtime 的那天，不用重写一行业务逻辑、不丢失一次用户会话、不泄露一个生产密钥。

这层技术，正以肉眼可见的速度走向“零价化”。不是免费，而是像 Linux 内核、Kubernetes 调度器、PostgreSQL 存储引擎一样——它必须存在，但没人会为它单独付大钱。价值正在向上迁移：迁移到你能看见 agent 干了什么的 可观测性层 ，迁移到你能控制 agent 能干什么的 治理策略层 ，迁移到你能直接卖给客户“销售线索自动归因”而不是“一个托管 runtime”的 垂直场景层 。Gaurav Yadav 在 Towards AI 那篇原文里说得极准：“The piece of the stack that gets bid down toward zero is the piece they just shipped.” —— 这句话不是预言，是正在发生的事实。接下来我要拆解的，不是 Anthropic 的 PR 文案，而是这个“零价层”背后真实的工程骨架、它为什么必然 commoditize、以及作为一线从业者，你现在该把力气花在哪一层。

2. 核心设计与思路拆解：为什么“Session as Event Log”是唯一解

2.1 旧范式之痛：把 state 塞进 context window 是一场慢性自杀

先说清楚旧路为什么走不通。几乎所有早期 agent 框架（包括我们自己写的第一个版本）都默认把 session state 当作“临时变量”塞进 LLM 的 prompt 里。逻辑很朴素：模型需要记住它刚调了哪个 API、返回了什么 JSON、下一步该问谁。于是我们写这样的 system prompt：

“你是一个销售助理 agent。你已执行以下步骤：1. 从 Salesforce 获取线索 ID: SL-7892；2. 调用 SerpAPI 查询 'Acme Corp 官网更新'，返回摘要：'Acme 于4月5日上线新定价页...'；3. 调用风控 API 校验，结果：通过。请基于以上信息生成周报。”

这在单次、短链路任务里没问题。但一旦任务变长、分支变多、工具调用变频繁，三个致命缺陷立刻暴露：

Token 泄露不可控 ：每次 tool call 的 input/output 都要原样塞进 prompt。一个 500 字的 SerpAPI 返回摘要，加上前后描述，轻松吃掉 1200 tokens。而 Claude 3.5 Sonnet 的 context 是 200K，看似很大，但实际可用推理空间远小于此——system prompt、tool schema、few-shot examples、历史对话轮次，都在抢空间。我们实测过，当 session 超过 15 步工具调用，context 占用率就突破 70%，此时模型开始“选择性遗忘”，优先丢弃最早、最不“语义相关”的片段——往往是关键的 credential 或中间状态。
状态一致性无法保证 ：LLM 不是数据库。它不会做 ACID 事务。当它“认为”自己调用了某个 API，但实际网络超时失败了，prompt 里却写着“已成功调用”，后续所有推理都建立在这个错误前提上。我们曾遇到 agent 把“调用失败”误读为“返回空数组”，进而推断“该线索无竞品动态”，直接跳过关键分析步骤。
调试与审计完全失能 ：出了问题，你只能看最终输出和原始 prompt。中间发生了什么？哪个 tool call 的输入参数错了？credential 是在第几步被意外暴露给模型的？没有任何记录。就像开车没有行车记录仪，只靠司机口述事故经过——不可靠，且无法复盘。

提示：这不是模型能力问题，是架构设计的根本性错误。把有状态、需持久化、需强一致性的业务逻辑，强行压进一个无状态、易丢失、弱一致性的文本生成器里，违背了计算机科学最基本的分层原则。

2.2 新范式之核：Event Log + Stateless Harness 的分离哲学

Anthropic Managed Agents 的核心创新，就是用操作系统虚拟化硬件的思路，来虚拟化 agent 的执行环境。它把整个 agent 生命周期拆成三个清晰、解耦的抽象层：

Session（会话） ：一个独立的、持久化的、时间序列化的 事件日志 。它不存于模型 context，而存于 Anthropic 自建的、高可用的分布式日志系统（底层很可能是类似 Kafka/Pulsar 的流存储）。每一条 event 都是结构化的：
```
{
  "eventId": "evt_abc123",
  "sessionId": "sess_xyz789",
  "timestamp": "2026-04-08T14:22:31.456Z",
  "eventType": "tool_call_start",
  "toolName": "salesforce_query",
  "input": {"object": "Lead", "fields": ["Id", "Company", "Status"]},
  "traceId": "trc_def456"
}
```
这个日志是只追加（append-only）的，不可篡改，天然支持按时间、按 sessionId、按 eventType 查询。它就是你的“行车记录仪”。
Harness（执行器） ：一个极度轻量、 完全无状态 的容器。它只做一件事：接收 awake(sessionId) 请求，从 event log 里拉取最新状态，根据当前 event 序列决定下一步该调用哪个 tool，然后执行 execute(toolName, input) 。执行完，把结果（success/fail + output）作为新 event 写回日志。Harness 本身不存任何 state，可以随时被 kill、重启、扩缩容。它 crash 了？没关系， awake(sessionId) 会自动从日志里恢复到崩溃前一刻的状态，继续执行。这就是“crash-resilient”的本质——state 在 log 里，不在进程里。
Sandbox（沙箱） ：一个按需创建、用完即焚的隔离执行环境。每个 tool call 都在一个全新的、干净的 microVM 或 container 里运行。最关键的是： credential 从不注入沙箱环境变量 。Anthropic 的 vault 服务在沙箱启动时，将 credential 以安全的方式（如 Unix socket 通信或内存映射）传递给 tool 二进制，沙箱内的代码永远看不到明文 token。这堵住了 LLM 通过 os.environ 或 curl -H "Authorization: Bearer xxx" 泄露密钥的最大漏洞。