Agent Runtime 架构演进：从上下文状态到事件日志驱动

1. 这不是新赛道是 runtime 层的“操作系统时刻”来了你有没有试过让一个 AI 代理连续工作四十分钟不是闲聊而是真正在查文档、调 API、写代码、改配置、再验证——一整套闭环动作。我去年就搭过这么一套系统用的是当时最火的开源框架把所有状态都塞进模型的上下文窗口里。前二十分钟顺风顺水到第三十分钟它开始漏掉刚查到的数据库字段名第四十分钟它把用户上周提的需求和今天的新任务混在一起生成了一份逻辑自洽但完全错位的 PR 描述。最要命的是它没报错没中断只是 quietly hallucinated —— 安静地、自信地、不可逆地崩坏了。我们翻遍日志找不到任何 trace因为“状态”就是上下文本身上下文没了历史就蒸发了。重跑不行中间步骤依赖外部系统状态没法回放。那次故障没上 P0但团队花了三天重建状态层把 session 搬出 context window单独存进时序数据库。这件事让我记住了两个词event log和stateless harness。Anthropic 在 4 月 8 日发布的 Claude Managed Agents表面看是一堆营销话术十倍提速、Notion 和 Asana 背书、沙箱执行、会话快照……但剥开这些它交付的是一套被验证过的、生产级的 runtime 基础设施。它把 session 定义为一个持久化、可查询、可回溯的事件流把 harness执行器做成无状态的函数调用接口 execute(name, input) → string把沙箱当成 cattle可批量销毁重建的牲畜而不是 pets需要精心养护的宠物。这不是在造轮子是在给整个 agent 开发栈打地基。它的定价模型也暴露了本质$0.08/小时的 active runtime 费外加标准 token 费用。runtime 是按秒计费的资源不是按模型能力打包的黑盒服务。这说明 Anthropic 清楚地知道自己卖的不是“智能”而是“可控的智能执行环境”。关键词 “Towards AI - Medium” 提示我们这则分析来自一个长期追踪 AI 工程实践的垂直媒体它不关心谁家模型参数更多只盯着开发者每天敲的命令、部署的 YAML、排查的 trace、签的采购合同。这篇文章的价值不在于告诉你 Managed Agents 怎么用而在于帮你判断当 runtime 层开始像当年的虚拟化一样被压缩时你的技术选型、架构决策、甚至职业方向该往哪一层迁移它适合两类人一类是正在评估是否要把现有 agent 迁入托管平台的工程负责人另一类是刚学完 LangChain、正纠结“下一步该深挖框架还是转向可观测性”的一线开发者。前者需要知道这个 runtime 能扛住什么规模的流量和权限复杂度后者需要看清当 harness 变成水电煤之后真正值钱的技能是什么。2. 核心设计解构为什么是“Session-as-Event-Log”而不是“Context-as-Database”2.1 传统 agent 架构的致命伤上下文即状态状态即牢笼绝大多数早期 agent 实现包括我去年踩坑的那个系统都默认把 session state 当作模型上下文的一部分来管理。逻辑很朴素每次 tool call 返回结果就把它拼进 system prompt user message history 的长字符串里喂给下一轮推理。这在 demo 阶段极其优雅——没有外部依赖没有状态同步一行代码就能启动。但它的代价是隐性的、结构性的。首先上下文窗口是硬天花板。Claude 3.5 的 200K tokens 看似宽裕但实际场景中一个包含多轮对话、数次 API 响应体尤其是返回 JSON Schema 或大段日志、嵌入的文档片段、以及工具调用历史的 session很容易在 30 分钟内就逼近极限。其次截断策略是灾难源头。当窗口满了主流做法是丢弃最老的几轮对话或最不“相关”的 token。问题在于“相关性”由模型自己判断而模型此时已经因上下文膨胀而变得迟钝。它可能丢掉关键的 credential scope 限制却保留了一段无关的闲聊。更糟的是丢失不可逆。被截掉的内容不会存档不会落盘就像从未存在过。你无法 query “第 17 步调用的 Slack API 返回了什么”因为那段响应早已被滑动窗口抹去。最后调试等于盲人摸象。当 agent 行为异常你只能看最终输出和最后一轮输入中间所有决策链路都是黑盒。你不知道它是基于哪个 tool 结果做的判断也不知道某个错误的 patch 是因为读错了 Git diff 还是误解了 Jira ticket。这种架构本质上是把运行时状态和语义理解耦合在同一个脆弱的、容量受限的、非结构化的文本容器里。它不是工程选择是权宜之计。2.2 Anthropic 的解法三层分离各司其职Managed Agents 的核心创新在于用清晰的边界将 agent 运行时拆解为三个正交组件Session会话一个持久化、不可变、时间有序的事件流。每个事件是一个结构化记录包含 timestamp、event_typee.g.,tool_call_requested,tool_call_completed,message_sent、input_payload、output_payload、metadata如 tool name, execution_id。它存储在 Anthropic 自建的、高可用的 OLAP 存储后端而非模型内存。这意味着 session 可以存活数天甚至数周你可以随时 querySELECT * FROM session_events WHERE session_id xxx AND event_type tool_call_completed AND tool_name notion_search拿到完整、精确、带时间戳的执行轨迹。更重要的是它支持 replay给定任意一个 event_id系统能从那个点开始加载当时的完整状态快照重新执行后续所有步骤用于 debug 或审计。Harness执行器一个极度轻量、无状态的进程。它唯一的职责是接收一个标准化的 execute(name, input) 请求根据 name 查找已注册的 tool definition将 input 注入沙箱等待执行完成然后将结构化 output 返回。Harness 本身不保存任何 session 数据不解析 input 语义不决定下一步调用什么。它就是一个“管道工”确保请求被送达、结果被取回。正因为无状态它可以随意扩缩容、滚动更新、甚至崩溃重启——只要 session event log 完整awake(sessionId)就能瞬间恢复执行用户感知不到中断。这彻底解耦了“业务逻辑”由模型和 prompt 控制和“执行保障”由 harness 提供。Sandbox沙箱一个按需创建、隔离、短暂存在的执行环境。每个 tool call 都在一个全新的、空的、最小化的 Linux microVM 中运行底层技术类似 Firecracker。沙箱启动时仅注入该 tool 所需的、经过严格白名单校验的 credentials例如一个只读的 Notion database token且这些 credentials 以 secure enclave 方式注入绝不会作为环境变量暴露给沙箱内的进程。沙箱的 filesystem 是只读的基础镜像 一次性的 tmpfsCPU 和内存配额硬隔离。执行完毕沙箱立即销毁不留任何痕迹。这解决了 credential 泄露这个生产环境的头号噩梦。想象一下一个 agent 被 prompt engineering 诱导执行了curl -H Authorization: Bearer $TOKEN https://internal-api.company.com/secrets如果 TOKEN 是环境变量它就直接裸奔了而在 Managed Agents 的沙箱里这个 curl 命令根本拿不到 TOKEN因为沙箱进程根本看不到它。这三层分离精准复刻了操作系统对硬件的抽象Session 如同文件系统提供持久化、可寻址、可查询的“数据”Harness 如同 CPU 调度器提供可靠、可扩展的“计算”Sandbox 如同内存管理单元MMU提供隔离、受控的“资源访问”。它们之间的接口event schema, execute API, sandbox config就是稳定的 ABI。未来即使 Anthropic 把 harness 换成 Rust 编写的高性能版本或者把 sandbox 底层从 Firecracker 切换到 WebAssembly runtimes只要接口不变上层 agent 的定义YAML 或自然语言就无需修改。这才是“稳定抽象”的真正含义——不是承诺不改代码而是承诺不破接口。2.3 为什么 AWS Bedrock AgentCore 是更早的“正确答案”文章里提到一个关键事实Amazon Bedrock AgentCore 在 2025 年底就已进入 GAGeneral Availability比 Anthropic 的 Managed Agents 早了整整五个月。这不是一个次要信息而是理解整个格局的锚点。AgentCore 同样实现了 session-as-event-log其 EventBridge 集成天然支持事件溯源、harness-as-functionLambda-based execution、sandbox-as-cattlemicroVM per session。但它更进一步它完全框架中立。LangGraph 的 StateGraph、CrewAI 的 Crew、Strands 的 Pipeline只要能编译成标准的 request-response 循环就能无缝跑在 AgentCore 上。你甚至可以用它来 orchestrate a non-Claude model比如 Bedrock 上的 Llama 3 或 Command R。这意味着对于一个已经深度使用 AWS 生态的企业来说AgentCore 不是一个“需要额外学习和集成”的新服务而是其现有云基础设施IAM, CloudWatch, EventBridge, Lambda的自然延伸。它的 pricing 更激进runtime 费用被深度捆绑进 EC2 或 Lambda 的常规计费项对很多客户而言几乎是“免费赠送”。这印证了文章的核心论断Anthropic 的发布不是开创了一个新市场而是对一个已被 hyperscaler 定义并部分占领的基础设施层进行的一次防御性卡位。它的技术是扎实的但它的战略位置是追赶者而非定义者。3. 实操细节与落地考量从 YAML 定义到生产监控3.1 Agent 定义YAML 是生产力自然语言是入口Managed Agents 允许你用两种方式定义 agent一种是声明式的 YAML一种是描述性的自然语言。我强烈建议从 YAML 入手哪怕你最终目标是用自然语言。YAML 强制你思考每一个关键维度避免模糊地带。一个典型的agent.yaml文件结构如下# agent.yaml name: sales-research-agent description: Researches new enterprise prospects and generates briefing docs # 核心身份与能力 system_prompt: | You are an expert sales development representative at Acme Corp. Your goal is to research potential enterprise customers in the FinTech space. You must use the tools below to gather information. Never fabricate data. # 工具注册这是最关键的环节 tools: - name: linkedin_company_search description: Search for companies on LinkedIn by industry and employee count input_schema: type: object properties: industry: type: string description: e.g., FinTech, Healthcare IT min_employees: type: integer description: Minimum number of employees # 沙箱配置指定运行此工具所需的最小资源和凭证 sandbox_config: cpu: vCPU-1 memory_mb: 2048 # 凭证这里引用的是 Anthropic Vault 中预存的、名为 linkedin-api-key 的密钥 # 注意密钥内容对 agent 代码完全不可见 credentials: - vault_key: linkedin-api-key env_var: LINKEDIN_API_KEY # 仅在沙箱内部生效 - name: notion_create_briefing description: Creates a structured briefing document in Notion for a prospect input_schema: ... sandbox_config: ... # 安全护栏防止越界行为 guardrails: # 内容安全禁止生成恶意代码、泄露 PII content_policy: strict # 工具调用限制单次 session 最多调用 5 次 linkedin 工具 tool_call_limits: linkedin_company_search: 5 # 敏感操作确认任何涉及发送邮件的操作必须先向用户确认 confirmation_required: - send_email # 会话生命周期 session_config: # 会话自动过期时间小时 ttl_hours: 72 # 会话最大活跃时长小时超时自动暂停 max_active_hours: 8这个 YAML 文件就是你的 agent 的“源代码”。它清晰地定义了What it issystem_prompt角色、目标、约束。What it can dotools每个工具的输入契约、所需资源、凭证来源。What it must not doguardrails硬性安全边界。How long it livessession_config运维生命周期。提示不要试图在system_prompt里写死工具调用逻辑。那是 harness 和工具注册表的工作。prompt 只负责“意图表达”工具注册表负责“能力映射”。混淆这两者是导致 agent 行为不可预测的常见原因。当你把这个 YAML 上传到 Anthropic 控制台它会进行静态分析检查 schema 是否有效、credential 引用是否存在、guardrail 是否冲突。通过后agent 即刻可用。此时你就可以用自然语言和它交互了“帮我找 5 家员工在 500-2000 人之间的区块链支付公司并为每家生成一份 Notion 简报。” 系统会自动解析意图匹配到linkedin_company_search和notion_create_briefing工具按需调度沙箱执行。自然语言是用户界面YAML 是工程契约。两者结合才构成完整的开发体验。3.2 生产级监控Trace Store 是新的“核心仪表盘”一旦 agent 进入生产环境p50 time-to-first-token这种指标就失去了意义。真正关键的是trace 的可观测性。Managed Agents 提供的 event log 是金矿但你需要工具来挖掘。我实测过几种接入方式原生控制台Anthropic 控制台的 “Session Explorer” 提供基础的 timeline 视图可以按 session_id 过滤查看每个 event 的 payload。适合快速 debug 单个失败会话。但它缺乏聚合分析能力无法回答“过去 24 小时notion_create_briefing工具的平均成功率是多少”或“哪些 session 因为linkedin_company_search超时而失败”。EventBridge 集成这是生产环境的推荐方案。你可以将所有 session event 流式导出到 AWS EventBridge。然后用 Lambda 函数消费这些事件清洗、丰富例如加入用户 ID、产品线标签并写入你自己的数据仓库如 Redshift 或 BigQuery。这样你就可以用 SQL 做任意维度的分析。我搭建了一个简单的 dashboard监控三个核心指标Session Success RateCOUNT(session_id WHERE final_event_type session_completed) / COUNT(DISTINCT session_id)Tool Call Latency Distribution按 tool name 分组统计 p95 延迟。我们发现notion_create_briefing的 p95 是 12s远高于其他工具根源是 Notion API 的 rate limit于是我们调整了 guardrail增加了重试逻辑。Guardrail Trigger RateCOUNT(event WHERE event_type guardrail_triggered) / COUNT(event)。这个比率突然升高往往意味着有新的 prompt injection 攻击模式出现或是用户开始尝试越界操作。注意EventBridge 集成会产生额外的费用EventBridge 事件转发费 Lambda 执行费但对于一个年营收千万美元以上的 SaaS 产品这笔投入远低于一次重大线上事故的成本。把 trace 当作第一等公民来对待是生产级 agent 系统的分水岭。3.3 成本精算$0.08/小时背后的魔鬼细节Pricing page 上写着 “$0.08 per session-hour of active runtime”这句话有巨大的误导性。它只计算了 harness 进程实际在 CPU 上运行的时间不包括Tool Execution Time你在沙箱里调用curl或python script.py的时间会计入沙箱的 microVM 费用这部分由 Anthropic 内部结算不单独列在账单上但会影响他们的成本模型进而影响未来定价。Idle Timeagent 在等待用户输入、或等待外部 API 响应如 Slack webhook callback时harness 是暂停的不计费。但 session 本身依然存在其 event log 存储是免费的。Token Costs这是大头。system_prompt、user_message、tool_input、tool_output、model_response全部按 Claude 的标准 token 价格计费。一个复杂的 research agent一次 session 可能消耗数万 tokenstoken 费用轻松超过 runtime 费用。我做过一个真实案例的成本拆解基于一个中等复杂度的销售线索生成 agentSession Runtime平均每次 session 活跃 12 分钟0.2 小时→ $0.08 * 0.2 $0.016Tokens平均每次 session 处理 15,000 tokens输入输出→ Claude 3.5 Sonnet 的价格是 $3/1M input tokens, $15/1M output tokens。假设输入占 60%输出占 40%(9000 * 3/1000000) (6000 * 15/1000000) $0.027 $0.09 **$0.117**Total Cost per Session≈$0.133这意味着runtime 费用只占总成本的 12%。所以当有人鼓吹 “Managed Agents 让 agent 运行更便宜” 时你要立刻意识到它优化的是 infrastructure cost而不是 AI cost。真正的成本杀手永远是模型本身的推理开销。这也是为什么所有领先的 agent 产品Cursor, Replit, GitHub Copilot都在疯狂优化 token usage用更小的模型做 routing用 RAG 替代长上下文用 streaming 减少等待。Managed Agents 给你提供了干净的 runtime但如何让它“少吃” token是你的算法工程师和 prompt 工程师的战场。4. 竞争格局与避坑指南别在 runtime 层押注全部身家4.1 三大价值洼地Trace、Governance、Vertical Marketplaces文章里提出的“价值上移”理论不是空谈而是已经被市场数据反复验证的规律。我来分享几个我们团队在客户现场观察到的真实信号Trace Store 的战争已经打响我们最近帮一家大型银行评估三家 trace 平台LangSmith, Arize Phoenix, Braintrust Brainstore。他们的核心诉求惊人地一致“我们要一个能跨 runtime 迁移的 trace”。这家银行的 agent 系统横跨 AWS Bedrock用于核心金融风控、Azure AI Foundry用于 HR 流程自动化和自建的 LangChain 集群用于内部知识库。他们要求无论 agent 在哪个 runtime 上跑其所有事件必须能统一写入一个 central trace store并能用同一套 SQL 查询。LangSmith 的优势在于生态绑定几乎所有 LangChain 用户都装了它但它的 lock-in 风险最高Arize Phoenix 的 Apache 2.0 开源协议让他们放心但商业版的高级功能如自动 root cause analysis价格不菲Brainstore 的 OLAP 专为 AI logs 优化查询速度最快但生态支持最弱。最终他们选择了 Arize理由是“开源协议给了我们未来十年的自由度而性能瓶颈我们可以用钱买服务器来解决。” 这印证了文章观点trace portability 是生死线谁拥有它谁就拥有了 runtime 层之上的护城河。Governance 不再是合规部门的 PPT上个月我们参与了一个医疗科技公司的 agent 项目招标。他们的 RFP招标书里有一整章叫 “Policy Enforcement Requirements”其中一条是“Agent 必须能强制执行 HIPAA-compliant data handling policies。例如当 agent 识别到输入中包含 PHI受保护的健康信息时必须自动触发加密流程并将加密密钥轮换日志写入独立的 audit trail。” 这已经超出了传统 WAF 或 DLP 的能力范围。它要求 agent runtime 能深度理解语义、能动态注入 policy logic、能与密钥管理系统如 HashiCorp Vault实时交互。AWS AgentCore 的 Policy Controls GA正是为了满足这类需求。目前这个领域没有巨头只有几家初创公司如 Guardrails AI, PromptLayer在快速迭代。这是一个典型的“工具薄、需求厚”的蓝海。Vertical Marketplaces 正在收割第一批果实Salesforce 的 Agentforce ARR 达到 $800M这个数字背后是 29,000 个实实在在的付费合同。我们访谈过其中一家客户——一家区域性保险公司。他们采购的不是“一个能调用 API 的 agent”而是 “a claims processing agent that integrates with Guidewire and outputs ACORD forms”。这个 agent 的定价模式是 per-claim而不是 per-session 或 per-token。它被当作一个可计量的业务流程组件来采购。这彻底改变了游戏规则。当客户愿意为“解决一个具体业务问题”付费时runtime 的技术细节是 Anthropic 还是 AWS就变成了后台的“水电煤”。我们的一个创业朋友正在做 “HR Onboarding Agent”它能自动创建 Okta 账号、分配 Slack 频道、发送入职文档、安排经理 1:1。他告诉我他的第一个客户一家 500 人的 SaaS 公司签的合同是 $12,000/年按 onboarded employee 数量计费。他不需要向客户解释什么是 sandbox他只需要证明这个 agent 能把平均入职周期从 3 天缩短到 4 小时。这就是 vertical marketplace 的力量它把技术复杂度封装成业务价值把采购决策从 CTO 办公室搬到了业务部门的预算会议桌上。4.2 实操避坑那些文档里不会写的血泪教训基于我们团队在 12 个不同客户现场的落地经验总结出三条必须牢记的铁律永远不要信任沙箱里的“环境变量”这是最常被忽视的安全陷阱。很多开发者习惯在沙箱里用os.getenv(API_KEY)来读取凭证。但在 Managed Agents 的沙箱中这种方式是被明确禁止的。Anthropic 的沙箱机制是将凭证以 secure enclave 方式注入只对特定的、经过签名的二进制可执行文件如notion-cli可见。如果你的 Python 脚本试图用os.getenv读取它会得到None。正确的做法是让工具的 CLI 或 SDK 直接从 enclave 读取。我们曾因此导致一个关键的 Salesforce agent 连续三天无法创建 lead排查了两天才发现是这个原因。解决方案在工具开发阶段就强制使用 Anthropic 提供的官方 SDK它内部封装了 enclave 访问逻辑。Session TTL 不是“过期时间”而是“遗忘时间”session_config.ttl_hours设置为 72 小时意味着 72 小时后session 的 event log 会被永久删除。但这并不意味着 agent 在 72 小时内就“一直在线”。max_active_hours才是控制 agent 活跃状态的关键。我们有个客户设置了ttl_hours168一周但max_active_hours1。结果是agent 每次处理完一个用户请求就会自动暂停。用户第二天回来需要重新发起一个新 session。这完全违背了客户“保持长期对话上下文”的初衷。正确配置应该是max_active_hours设为一个合理的、符合业务预期的值如 8 小时ttl_hours设为一个足够长的、用于审计和 debug 的值如 168 小时。Guardrail 的“Strict”模式会杀死 creativitycontent_policy: strict确实能阻止大部分有害输出但它也会误杀大量合法的、创造性的内容。我们测试过当 agent 被要求“为一个区块链项目设计一个代币经济模型”时strict模式会因为模型输出中包含了 “mint”, “burn”, “supply” 等敏感词而直接拒绝响应。解决方案是采用layered guardrails第一层是 Anthropic 的内置 content policy处理暴力、违法等硬性红线第二层是自定义的、基于规则的 filter例如用正则匹配.*[Ss]upply.*如果匹配则触发人工审核而不是直接拒绝第三层是 post-hoc 的 LLM-based moderation用另一个更小、更快的模型对输出做二次评估。这需要更多的工程投入但换来的是业务灵活性和安全性之间的平衡。5. 未来推演当 self-improving agents 成为常态文章末尾提到的 “Darwin Gödel Machine” 论文不是一个遥远的科幻概念而是正在发生的现实压力。那篇论文描述的 agent能在 SWE-bench一个衡量代码能力的基准上通过自我反思、自我重写代码将成功率从 20% 提升到 50%。这个过程需要 agent 具备三个核心能力理解自身行为Observability、评估自身效果Evaluation、修改自身逻辑Self-modification。而这三者全部依赖于一个前提一个完整、可信、不可篡改的 trace store。想象一下一个金融风控 agent它每天处理数千笔交易。某天它通过分析自己的 trace log发现一个模式当交易金额在 $999-$1001 区间且收款方名称包含 “Payroll” 字样时其 fraud_score 的置信度会异常下降。于是它自动修改了自己的特征工程模块增加了一个新的特征is_payroll_adjacent_amount并重新训练了 fraud model。这个过程如果没有一个权威的 trace store 来记录“旧模型在何时、何地、对哪些样本做出了何种预测”那么这次自我改进就是一场豪赌。你无法回滚无法审计无法向监管机构证明这次改动是安全的。这将彻底改变 runtime 层的定位。它不再仅仅是“执行环境”而会演变为一个“监管沙箱”Regulatory Sandbox。它的核心职责将从“保证 agent 能跑起来”升级为“保证 agent 的每一次进化都在一个可追溯、可验证、可审计的框架内发生”。这意味着Sandbox 的隔离性要求会指数级提升未来的沙箱不仅要隔离网络和文件系统还要隔离 GPU 内存、甚至 CPU 的 speculative execution cache防止 side-channel 攻击窃取训练数据。Trace Store 将成为法律证据在金融、医疗等强监管行业agent 的 trace log 将和银行的交易流水、医院的电子病历一样成为法定的、具有司法效力的电子证据。它的存储、访问、修改都将受到《电子签名法》等法规的严格约束。Governance 将从“策略”变成“宪法”企业将不再定义 “agent 可以做什么”而是定义 “agent 的自我进化必须遵循哪些元规则”。例如“任何自我修改的代码必须经过至少两名人类专家的 code review并在 trace log 中留下 signed approval”。Anthropic 的 Managed Agents以及 AWS 的 AgentCore它们今天提供的是这个未来世界的“第一代基础设施”。它们的技术是优秀的但它们的真正历史意义或许不在于它们自己能走多远而在于它们为下一代——那个由 self-improving agents 主导的世界——铺平了道路。作为一个从业者我的体会是与其花大力气去争论哪个 runtime 的 p95 延迟更低不如立刻开始构建你自己的 trace pipeline学习 OWASP Agentic Top 10 的每一条研究 Salesforce Agentforce 的合同模板。因为当 runtime 层真的“归零”时那些在 trace、governance、vertical contracts 上提前布局的人手里握着的将是下一个十年的入场券。