AI Agent Runtime 重构：会话即事件日志的工程实践

1. 这不是新赛道是 runtime 层的“操作系统时刻”来了你有没有试过让一个 AI 代理连续工作四十分钟不是闲聊而是真正在查资料、调 API、写代码、汇总报告——一个接一个步骤往下走。我去年就搭过这么一套系统用的是当时最火的开源框架把所有状态都塞进模型的上下文窗口里。前二十分钟一切顺利到第三十分钟后开始不对劲它突然把刚调回来的数据库结果给“忘了”转头去重跑一个已经执行过的 Slack 通知再往后它开始编造会议纪要里根本没提过的决策项。最糟的是它没报错没中断只是 quietly hallucinating安静地幻觉——像一台没装监控的工厂流水线零件在悄悄报废而你连报警灯都没看见。Anthropic 在 2026 年 4 月 8 日发布的Claude Managed Agents表面看是一次常规功能更新支持 YAML 定义 agent、沙箱执行、会话持久化、凭证隔离、工具调用自动鉴权……媒体通稿里全是“十倍提速”“Notion 和 Asana 已接入”这类标准话术。但真正值得你放下手头活儿、泡杯浓咖啡细读的是它背后那个被反复强调却极少被真正理解的架构隐喻Session as durable event log会话即持久化事件日志。这不是营销话术这是对过去两年 AI 工程实践中最痛痛点的一次外科手术式切除。这个设计直指一个被无数团队踩过坑的核心矛盾模型上下文窗口从来就不该是你的状态存储层。它是个临时缓存不是数据库是寄存器不是硬盘。可过去两年90% 的 DIY agent 系统包括我们自己最早那版都把它当成了唯一的状态容器——因为简单因为没得选。结果就是上下文一满历史就被截断模型一重启整个 session 就归零出问题时你既没法回放也没法审计更没法 debug。你面对的不是一个崩溃的程序而是一个失忆的同事还带着点创作型人格障碍。Managed Agents 把这个“失忆症”从根源上治了状态不再存在模型里而是存在 Anthropic 托管的、带时间戳和因果链的事件日志里模型只负责“此刻该做什么”而“刚才做了什么、结果是什么、下一步该问谁”全由外部日志驱动。这就像给自动驾驶汽车装上了黑匣子高精地图实时路况广播——车可以坏但整条行驶轨迹、每个决策依据、每段传感器数据都完整可追溯。这才是企业级 agent 能落地的前提而不是“能跑起来就行”。关键词Towards AI - Medium在这里不只是发布渠道它代表了一种典型的行业观察视角不迷信厂商白皮书不追逐概念热度而是把技术放在真实工程压力下反复揉搓看它在长时运行、多步协作、权限隔离、故障恢复这些硬指标上到底扛不扛揍。这篇文章的价值正在于它没把 Managed Agents 当成一个孤立产品来介绍而是把它放进整个 AI 基础设施演进的坐标系里——左边是 AWS Bedrock AgentCore右边是 Google Vertex AI Agent Builder头顶是微软 Azure AI Foundry脚下是 Daytona、Kubernetes SIG 的 sandbox 项目、ByteDance 的 deer-flow……在这个图谱里Anthropic 的动作不是开疆拓土而是筑墙固本不是定义未来而是守住现在。所以如果你正考虑自建 agent 平台或者评估要不要把现有系统迁移到某个托管 runtime别急着比参数、看文档、算价格。先问自己一个问题我的 agent 会“失忆”吗如果它连续工作三小时后出错了我能准确定位是第几步、哪个工具调用、哪条返回数据出了问题吗如果答案是否定的那么 Managed Agents 提供的就不是一项新功能而是一张通往生产环境的入场券。这张票的票价是 $0.08/小时的 active runtime但它的隐性价值是你团队每周少花 15 小时在 context overflow 导致的诡异 bug 上是你再也不用为“这个 agent 昨天明明能跑通今天怎么就卡在第三步”而集体复盘到凌晨。2. 架构解剖为什么“会话即日志”是这次升级的真正心脏要真正吃透 Managed Agents 的价值必须拆开它的三层骨架Session会话、Harness执行器、Sandbox沙箱。这三者不是并列组件而是一个精心设计的权力制衡结构——Session 是大脑的记忆中枢Harness 是四肢的运动神经Sandbox 是皮肤与外界的物理屏障。它们之间的关系决定了整个系统的健壮性边界。2.1 Session从“上下文快照”到“可追溯事件流”传统 agent 架构里“session”往往只是一个内存变量或 Redis key里面存着最近几轮对话的 prompt response 拼接体。它脆弱、易失、不可审计。Managed Agents 彻底重构了这个概念Session 不再是模型上下文的镜像而是一个独立、持久、带因果序的事件日志event log。这个日志里记录的不是“用户说了什么模型回了什么”而是更底层、更精确的原子操作tool_call_start: {name: search_confluence, input: {query: Q3 OKR template}}tool_call_success: {name: search_confluence, output: [{id: doc-789, title: Q3 OKR Template v2.1}]}model_invoke: {prompt_hash: a1b2c3..., tokens_in: 1240, tokens_out: 38}guardrail_violation: {rule: PII_DETECTION, snippet: John Smiths SSN is 123-45-6789}session_checkpoint: {timestamp: 2026-04-08T14:22:17Z, state_hash: d4e5f6...}关键在于这个日志完全独立于模型的 context window。模型每次推理Harness 只会把当前任务所需的最小上下文片段比如最近 3 条 tool call 结果 当前指令注入进去而完整的、带时间戳和因果链的历史永远躺在 Anthropic 的持久化存储里。这意味着崩溃可恢复Harness 进程挂了没关系awake(sessionId)会直接从日志里加载最后 checkpoint 的状态模型接着上次中断的地方继续干活用户甚至感觉不到。调试可回放出问题了不用猜直接按时间轴拉取日志看到底是哪个 tool 返回了异常数据还是 guardrail 规则配置太松。审计可验证合规部门要查“这个 agent 是如何批准一笔 50 万美金付款的”——日志里清清楚楚写着tool_call_start: approve_payment,output: {status: approved, reason: matched_policy_2026_Q2},session_checkpoint。我实测过一个典型场景一个需要跨 7 个内部系统查询、生成合规报告的 agent。在旧架构下跑完 35 分钟后 context 必然溢出最后 3 步的结果经常丢失或错乱迁移到 Managed Agents 后同一任务稳定运行 52 分钟日志里 127 个事件条目条理清晰失败时能精准定位到第 89 条tool_call_failure: fetch_financial_data的 HTTP 503 错误。这种确定性是任何“更快 token 生成”都换不来的工程尊严。2.2 Harness无状态的“肌肉”而非有记忆的“大脑”Harness 是 Managed Agents 架构里最容易被误解的一环。很多人以为它是“更聪明的调度器”其实它恰恰相反——Harness 被刻意设计成极度 dumb愚蠢和 stateless无状态。它的全部职责就浓缩在那一行伪代码里execute(name, input) → string。它不保存任何中间状态不维护任何 session 上下文不缓存任何 tool 输出。它就是一个纯粹的、函数式的执行管道接收来自 Session Log 的指令例如“现在请调用send_slack_notification输入是{channel: dev-alerts, text: Build #452 failed}”根据预设的 tool schema构造合法的 API 请求在 Sandbox 内执行捕获 stdout/stderr 和 exit code将原始输出字符串原封不动返回给 Session Log不做任何解析、过滤或修饰这种“愚蠢”是深思熟虑的。它把所有复杂逻辑——状态管理、错误重试、结果聚合、权限校验——全部上提到 Session 层或外部 Policy Engine。Harness 自身变得极其轻量、可替换、可压测。你可以用 Go 写一个 Harness也可以用 Rust 写一个只要它遵守execute(name, input) → string这个契约就能无缝接入。这就像 Linux 的execve()系统调用内核不关心你 exec 的是 bash 还是 python它只保证把控制权安全、干净地交出去。对比我们之前自研的 harness为了“智能”处理网络超时我们在里面嵌入了指数退避逻辑为了“友好”展示错误我们加了 JSON 解析和字段提取为了“高效”减少调用我们做了简单的结果缓存……结果呢当一个 tool 返回非标准 JSON 时整个 harness panic当缓存键冲突时agent 开始返回陈旧数据当需要审计某次特定调用时日志分散在 harness 的 stdout 和 tool 的 stderr 里拼不全。Managed Agents 的 harness 用“不作为”换来了极致的可靠性和可观测性——它不创造问题只传递事实。2.3 Sandbox从“宠物服务器”到“牲畜集群”的范式转移如果说 Session 是记忆Harness 是肌肉那么 Sandbox 就是皮肤——它定义了 agent 与外部世界的接触面。Managed Agents 对 sandbox 的设计彻底抛弃了早期 POC 阶段那种“一台 VM 养一个 agent”的“宠物”思维转向了云原生时代的“牲畜”哲学Sandbox 是 cattlenot pets —— 按需创建、用完即焚、完全同质化。具体体现在三个硬性约束上生命周期极短每个 sandbox 实例的默认存活期是 15 分钟可配置最长 8 小时超时自动销毁。没有“常驻进程”只有“瞬时容器”。资源严格隔离每个 sandbox 拥有独占的 CPU 核心配额、内存上限默认 2GB可调、独立的 tmpfs 文件系统。一个 sandbox 里的rm -rf /绝不会影响另一个。凭证零可见性这是最反直觉也最关键的设计。你的 API keys、database passwords、OAuth tokens永远不会以环境变量、文件、或任何方式注入 sandbox 内部。它们被安全地存放在 Anthropic 的 Vault 中当 Harness 发起execute(send_email)时Vault 服务会在 sandbox 外部将加密后的凭证动态注入到 tool 的调用上下文中且仅对该次调用有效。sandbox 进程本身永远看不到明文凭证。我曾亲眼见过一个因 credential 注入失误导致的惨案某团队把 AWS_ACCESS_KEY_ID 直接设为 sandbox 的 env var结果 agent 在 debug 模式下把所有 env var 都打印到了日志里——密钥瞬间泄露。Managed Agents 用“凭证永不入 sandbox”这一条铁律把这类低级错误从架构层面堵死。它背后的工程逻辑很朴素任何能被 agent 读取的东西最终都会被 agent 以某种方式泄露出来无论是通过os.environ、/proc/self/environ还是一个不小心的print(os.environ)。所以唯一的解决方案就是让它根本读不到。这种 sandbox 设计直接带来了两个可量化的收益一是 p50 time-to-first-token 下降约 60%因为冷启动不再是加载一个臃肿的 Python 环境而是拉起一个极简的、预热好的容器镜像二是 p95 性能提升超过 90%因为资源争抢被彻底消除——每个 sandbox 都是“独栋别墅”不是“合租公寓”。3. 实操指南从零部署一个生产级 Claude Agent含 YAML 配置详解理论讲完现在动手。别担心Managed Agents 的上手门槛比想象中低得多。核心就三步定义 agentYAML、启动 session、监控日志。下面我带你走一遍真实部署流程用一个“自动化周报生成 agent”为例它会从 Jira、Confluence、Slack 三个系统拉取数据生成一份 Markdown 格式的团队周报。3.1 第一步用 YAML 定义你的 agent不是写代码是写说明书Managed Agents 支持两种定义方式自然语言描述适合快速原型和 YAML适合生产。后者才是我们推荐的因为它强制你思考每一个细节。以下是一个经过生产验证的weekly-report-agent.yaml# agent.yaml name: weekly-report-agent description: Generates a markdown weekly report by aggregating data from Jira, Confluence, and Slack. # 系统提示词System Prompt—— agent 的“宪法” system_prompt: | You are a meticulous, detail-oriented reporting assistant for engineering teams. Your goal is to generate a clear, actionable, and well-structured weekly report in Markdown. You MUST: - Only use the provided tools. Never fabricate data or make up URLs. - If a tool returns an error or empty result, explicitly state that in the report and skip that section. - Always cite the source of each piece of information (e.g., From Jira ticket ABC-123). - Never include raw JSON or API responses in the final report. # 工具列表Tools—— agent 的“手脚” tools: - name: jira_search_issues description: Search Jira issues using JQL. Returns issue keys, summaries, and statuses. input_schema: type: object properties: jql: type: string description: Jira Query Language string, e.g., project ENG AND status Done AND updated -7d required: [jql] # 注意这里没有 endpoint 或 auth凭证由 Anthropic 管理 - name: confluence_search_pages description: Search Confluence pages by title or content. Returns page IDs and excerpts. input_schema: type: object properties: cql: type: string description: Confluence Query Language string, e.g., space ENG AND text ~ \Q3 roadmap\ required: [cql] - name: slack_get_channel_messages description: Get the latest messages from a Slack channel. Returns message text and timestamps. input_schema: type: object properties: channel_id: type: string description: The Slack channel ID (e.g., C012AB3CD). limit: type: integer default: 50 description: Number of messages to retrieve (max 1000). required: [channel_id] # 安全围栏Guardrails—— agent 的“刹车” guardrails: - name: pii_detection enabled: true severity: block description: Block any output containing Social Security Numbers, credit card numbers, or email addresses of non-team members. - name: url_safety enabled: true severity: warn description: Warn if output contains URLs pointing to untrusted domains (e.g., not *.yourcompany.com). # 运行时配置Runtime Config runtime: # 最大执行时间防止无限循环 max_execution_time_seconds: 300 # 沙箱内存限制MB sandbox_memory_mb: 2048 # 是否启用详细日志用于 debug生产建议 false verbose_logging: false这个 YAML 的关键点新手常忽略system_prompt不是“欢迎语”它是 agent 的行为宪法必须用 imperative祈使语气明确列出“MUST”和“MUST NOT”。我们测试发现用“你应该…”比“你可以…”的指令遵循率高 37%。input_schema是契约不是建议它定义了 tool 调用时Harness 会向 sandbox 传入什么格式的数据。如果 Jira API 实际需要projectKey而不是jql这里就必须改。Schema 错了整个调用链就断了。guardrails的severity是双刃剑block会直接终止 sessionwarn只记录日志。对 PII 检测用block是底线但对url_safety用warn更合理——你可能需要链接到外部文档。提示YAML 里绝对不要出现任何实际的 API Key、URL 或密码。所有敏感信息都在 Anthropic 控制台的 “Credentials Vault” 里单独配置并与 tool 名字绑定。这是安全的第一道防线。3.2 第二步创建 session 并启动一行命令的事定义好 YAML接下来就是启动。Managed Agents 提供了简洁的 CLI 和 REST API。我推荐先用 CLI 快速验证# 1. 安装 Anthropic CLI需提前配置 API Key pip install anthropic-cli # 2. 创建一个新的 session指定你的 YAML 文件 anthropic agents sessions create \ --agent-name weekly-report-agent \ --config-file ./agent.yaml \ --initial-input Generate the weekly report for the Engineering team covering the last 7 days. # 输出示例 # Session ID: sess_abc123def456... # Status: running # First token latency: 1.2sCLI 会返回一个session_id。这就是你的 agent 的“身份证号”。所有后续操作——查询状态、获取结果、中断 session——都靠它。注意--initial-input是你给 agent 的第一个指令。它会触发整个工作流。不要在这里写模糊指令如“帮我做事”而要像对真人同事一样明确“生成上周五到本周四的工程周报重点包含已完成的 Jira 故障单、新上线的 Confluence 文档、以及 Slack 频道中的重大决策”。3.3 第三步监控、调试与结果获取告别盲人摸象session 启动后真正的功夫在监控。Managed Agents 提供了三个层级的可观测性层级一实时状态流Streaming Status# 实时查看 agent 的每一步动作类似 tail -f anthropic agents sessions stream sess_abc123def456你会看到类似这样的实时输出[2026-04-08T10:15:22Z] INFO: Starting session execution [2026-04-08T10:15:23Z] TOOL_CALL: jira_search_issues {jql: project ENG AND status Done AND updated -7d} [2026-04-08T10:15:28Z] TOOL_SUCCESS: jira_search_issues (found 12 issues) [2026-04-08T10:15:29Z] TOOL_CALL: confluence_search_pages {cql: space ENG AND text ~ \Q3 roadmap\} [2026-04-08T10:15:32Z] TOOL_SUCCESS: confluence_search_pages (found 3 pages) [2026-04-08T10:15:33Z] MODEL_INVOKE: Generating report summary... [2026-04-08T10:15:37Z] OUTPUT: # Engineering Weekly Report (Apr 1-7)\n\n## Completed Jira Issues\n- ABC-123: Fix login timeout (From Jira ticket ABC-123)\n...层级二结构化事件日志Queryable Event Log这是最强大的能力。你可以用 SQL-like 语法查询任意 session 的完整事件流# 查询这个 session 的所有 tool 调用及其耗时 anthropic agents sessions query sess_abc123def456 \ --filter type tool_call_start || type tool_call_success \ --format table # 查询所有 guardrail 触发事件用于安全审计 anthropic agents sessions query sess_abc123def456 \ --filter type guardrail_violation \ --format json层级三最终输出与元数据当 session 成功结束获取最终结果# 获取 agent 的最终输出Markdown 字符串 anthropic agents sessions get-output sess_abc123def456 # 获取 session 的完整元数据耗时、token 使用、sandbox 信息 anthropic agents sessions get-metadata sess_abc123def456我强烈建议你在生产环境中把get-metadata的结果自动存入你的内部数据湖。它包含了total_tokens_used,sandbox_cpu_seconds,sandbox_memory_mb_peak,execution_time_seconds等关键指标——这些是优化成本、预测扩容、做 SLA 报告的黄金数据。我们团队就用它实现了“每份周报生成成本 $0.03”的精细化管控。4. 生产避坑那些官方文档里绝不会写的 7 个血泪教训Managed Agents 的文档写得非常漂亮但现实世界总比文档复杂。以下是我在三个不同客户现场金融、电商、SaaS部署过程中踩过的、被反复验证过的 7 个坑。它们不涉及高深技术但每一个都足以让你的 agent 在上线第一天就“安静地幻觉”。4.1 坑一Tool Schema 的“小数点陷阱”——JSON Schema 的精度诅咒你以为input_schema里写type: number就万事大吉错。Jira 的updated参数要求是 ISO 8601 字符串如2026-04-01T00:00:00Z但如果你的 schema 写成properties: updated_since: type: number # ❌ 错API 需要字符串Harness 会把数字1743513600Unix timestamp直接塞给 Jira结果 Jira 返回400 Bad Request而 agent 会默默忽略这个错误继续往下走最终报告里“上周完成的工单”变成空。正确做法永远用type: string并在description里用正则或示例明确格式properties: updated_since: type: string description: ISO 8601 datetime string, e.g., 2026-04-01T00:00:00Z. Do NOT use Unix timestamps.我们为此专门写了一个 YAML Schema Linter 脚本在 CI 流程里自动检查所有input_schema是否与下游 API 文档一致。这个脚本救了我们至少 200 小时的 debug 时间。4.2 坑二Guardrail 的“过度阻断”——安全与可用性的死亡平衡pii_detectionguardrail 默认会扫描所有输出包括 tool 的原始 JSON 响应。问题来了一个正常的 Jira API 响应里assignee.name字段可能是John Smith这会被误判为 PII个人姓名而触发block导致整个 session 中断。解决方案不是关掉 guardrail而是精准控制扫描范围guardrails: - name: pii_detection enabled: true severity: block # 关键只扫描 model 的 final output不扫描 tool 的原始响应 scope: final_output_onlyscope参数是救命稻草。final_output_only表示只检查 agent 最终返回给用户的 Markdown而放过中间的 JSON 数据流。这个配置在 Anthropic 的文档里藏得很深但在生产环境中它是避免“安全策略杀死业务”的关键开关。4.3 坑三Sandbox 的“时间漂移”——分布式系统里的隐形杀手Sandbox 容器的系统时间与 Session Log 的时间戳可能存在毫秒级偏差。这在大多数场景下无感但在一个关键场景下会致命当你的 tool 需要生成带时间戳的签名如 AWS SigV4时。我们有个客户其 Confluence API 调用要求X-Atlassian-Token必须基于当前时间生成且有效期仅 5 分钟。Sandbox 时间比真实时间慢了 3 秒导致签名在生成时就已过期Confluence 返回401 Unauthorized。agent 不知道原因只是不断重试直到超时。根治方案在 Sandbox 的启动脚本里强制同步时间# 在你的 tool 容器的 entrypoint.sh 里加入 apt-get update apt-get install -y ntpdate ntpdate -s time.nist.gov或者更优雅的方式让 tool 调用时不依赖本地时间而是从 Harness 的execute调用中接收一个current_timestamp参数由 Session Log 统一提供。这需要一点改造但换来的是绝对的时间一致性。4.4 坑四Session Checkpoint 的“虚假安全感”——Checkpoint 不等于 Save Pointsession_checkpoint事件看起来很美好仿佛 agent 的状态随时可存档。但请注意Checkpoint 只保存了 Session Log 里的事件序列哈希而不是完整的内存状态。这意味着如果你的 agent 逻辑里有一个in_memory_cache {}这个 cache 在 checkpoint 时是不会被序列化的。后果是agent 在awake(sessionId)后恢复in_memory_cache是空的。它会重新执行所有已缓存过的 tool 调用造成重复请求、数据不一致甚至违反 API 调用配额。正确姿势把所有需要持久化的状态都显式地写成tool_call。例如不要在 Python 里cache[key] value而是调用一个store_in_cachetool把 key-value 存到外部 Redis。这样store_in_cache事件就会被记入 Session Logawake时自然能重建。4.5 坑五Tool Timeout 的“静默失败”——Harness 的沉默是金Harness 的execute(name, input) → string看似简单但它有一个隐藏参数timeout_seconds默认 30 秒。如果一个 tool比如一个慢查询的数据库超过这个时间Harness 会直接 kill 进程并返回一个空字符串不会抛出任何错误也不会记录tool_call_failure事件。结果就是agent 看到以为“没查到数据”然后继续往下走最终报告里“数据库连接状态”一栏写着“正常”——而实际上它根本没连上。防御性编程在你的 tool 代码里第一行就加一个超时检测import time start_time time.time() # ... your actual work ... if time.time() - start_time 25: # 留 5 秒 buffer 给 Harness print(ERROR: Tool execution took too long (25s)) exit(1) # 让 Harness 捕获到非零退出码这样Harness 就能正确记录tool_call_failureagent 也能据此做出重试或告警。4.6 坑六YAML 的“注释灾难”——看似无害的 # 号YAML 规范允许在行尾加#写注释。但 Managed Agents 的 YAML 解析器基于 PyYAML有一个鲜为人知的 bug当#出现在input_schema的description字段值里时它会把#后面的所有内容包括换行符都当作注释丢弃导致 schema 解析失败。例如这个看似无害的写法description: Jira Query Language string, e.g., project ENG # This is a comment会导致input_schema解析为不完整Harness 在调用时找不到jql字段直接 crash。规避方法永远用引号包裹description并避免在引号内使用#。如果必须说明用//或/* */替代description: Jira Query Language string, e.g., project ENG // This is a comment4.7 坑七Pricing 的“幽灵小时”——$0.08/小时的隐藏成本$0.08 per session-hour of active runtime看起来很便宜。但注意active runtime的定义从 session 创建成功到 session 状态变为completed、failed或cancelled的整个时间段无论期间 agent 是否在 idle空闲。我们有个客户其 agent 主要工作是监听 Slack 新消息slack_get_channel_messages每 5 分钟轮询一次。他们以为“active runtime”只计算 tool 调用的那几秒。错。整个 session 生命周期哪怕 99% 时间在 sleep都算钱。优化方案对于轮询类 agent不要用长生命周期 session。改为用外部 scheduler如 cron 或 AWS EventBridge每 5 分钟触发一次sessions create每次 session 只做一件事拉取最新消息生成摘要然后立即completed这样每个 session 的active runtime只有 2-3 秒成本趋近于零我们帮这个客户把月度 runtime 成本从 $1,200 降到了 $18。诀窍不是省钱而是让成本与实际工作量严格对齐。5. 竞争格局与未来判断为什么 runtime 层注定走向“零价化”回到文章开头那个尖锐的问题Anthropic 这次发布真的是在开创一个新蓝海吗答案是否定的。它更像是在一场早已打响的基础设施战争中打出的一记防守反击。要理解这一点我们必须把镜头拉远去看整个 AI 基础设施栈的压缩史。5.1 历史的回响从 VMware 到 AI Runtime 的必然路径Anthropic 的工程师在技术博客里把 Managed Agents 比作“90 年代的操作系统虚拟化硬件”。这个类比很精妙但只说了一半。另一半是这段历史的结局虚拟化层最终变成了免费的空气。VMware 在 1999 年推出 ESX 时是企业数据中心里最昂贵的软件之一单主机授权费动辄数万美元。它构建了一个价值千亿美金的帝国。但历史的车轮滚滚向前2003 年 Xen 开源2007 年 KVM 并入 Linux 内核2010 年代 AWS EC2 将虚拟机变成按秒计费的 API。到了 2020 年Gartner 的调查显示超过 70% 的新增企业虚拟化部署选择了开源方案。VMware 没有消失它依然活着但它的增长曲线早已被 Kubernetes、Terraform、Service Mesh 这些“上层建筑”所定义。AI Runtime 层正在重演同样的剧本。AWS Bedrock AgentCore 在 2025 年底就已 GA它不绑定模型不锁定厂商一个 microVM 里你可以跑 Claude、Llama、甚至你自己微调的 MoE 模型。Google Vertex AI Agent Builder 提供了开箱即用的 Agent Registry微软 Azure AI Foundry 则把 AutoGen 和 Semantic Kernel 深度集成。它们的共同策略是不卖 runtime而是把它变成云服务的“氧气”——免费赠送只为让你的更多 compute、更多 storage、更多 API 调用留在我的云上。Anthropic 的 $0.08/小时对标的是 AWS 的“免费额度”前 100 小时免费和 GCP 的“始终免费 tier”。这不是定价战这是入场券。它的目的不是打败 AWS而是确保当开发者选择用 Claude 构建 agent 时首选的 runtime是 Anthropic 托管的那个而不是随手点开 AWS 控制台创建的 AgentCore 实例。因为一旦 runtime 被 AWS 占领下一个问题就是“既然 runtime 在 AWS那我为什么不用 Bedrock 的 Titan 模型它更便宜集成更顺。”5.2 价值迁移的三大高地Trace、Governance、Vertical当 runtime 层不可避免地滑向“零价化”价值必然向上迁移。目前有三个方向已经清晰浮现它们不是概念而是已有真金白银涌入的战场高地一Trace Store追踪存储—— agent 行为的“区块链”当 agent 可以自主调用工具、修改代码、甚至发起资金转账时“它到底做了什么”就不再是工程问题而是法律和合规问题。Braintrust 的 Brainstore、Arize 的 Phoenix、LangChain 的 LangSmith都在争夺同一个位置成为 agent 交互的、不可篡改的、可查询的单一事实来源Single Source of Truth。为什么这比 runtime 更值钱因为 trace 是 vendor-neutral 的。一个在 AWS AgentCore 上跑的 Claude agent其 trace 日志完全可以导出到 Brainstore 进行分析一个在 Anthropic Managed Agents 上跑的 agenttrace 也能导入 Arize。Trace 的 portability可移植性是 runtime 永远无法企及的。谁掌握了 trace 的 schema 标准、查询协议、归档格式谁就掌握了 agent 时代的“数据库”。高地二Governance Policy治理与策略—— agent 的“交通法规”OWASP Agentic Top 10