1. 这不是新赛道是 runtime 层的“操作系统时刻”正在重演你有没有在深夜调试一个跑了三小时的 AI 代理任务突然发现它开始胡言乱语不是模型崩了也不是代码错了——而是它的“记忆”被自己挤掉了。前45分钟调用的五个 API 结果、三次用户修正指令、两次失败重试的上下文全被模型窗口硬生生截断、覆盖、丢弃。你刷新页面想回溯问题结果只看到一条空荡荡的 session ID 和一段无法复现的幻觉输出。这不是故障是设计缺陷不是意外是所有把状态塞进 context window 的系统注定要撞上的南墙。这就是 Anthropic 在 2026 年 4 月 8 日发布的Claude Managed Agents真正解决的问题——它没发明“AI 代理”它把代理运行时runtime从一个临时拼凑的胶水层变成了一个可持久、可审计、可隔离、可恢复的基础设施层。关键词不是“agent”而是Managed托管、受控、有契约、能追责。它和 AWS Bedrock AgentCore、Google Vertex AI Agent Builder、Azure AI Foundry 一起共同指向一个正在加速成型的事实AI 代理的 runtime 层正在经历和 2000 年代初虚拟化技术一模一样的历史路径——从高价值专有产品走向免费、开放、无感的底层基座。我去年亲手搭过一套基于 LangChain Redis 缓存 自研 session manager 的客服代理系统。上线第三周客户投诉“机器人记性越来越差”。我们查日志发现不是模型退化而是当对话轮次超过 17 轮、嵌入检索返回 8 个 chunk、又调用了 3 次内部 CRM 接口后context 长度稳稳踩在 Claude 3.5 Sonnet 的 200K token 上限边缘。第 18 轮模型自动裁剪掉最早一轮的 CRM 查询结果——而那条结果里恰恰包含客户账户的冻结原因。它基于“被裁剪的记忆”生成了错误的解冻方案客户直接打了投诉电话。我们花了两天时间重写 state layer把所有中间产物存进专用向量结构化数据库用 session ID 做唯一索引才让系统真正“记得住事”。Anthropic 现在做的就是把我们那两天的痛苦打包成一个开箱即用的awake(sessionId)调用。这背后是两层不可逆的演进逻辑第一层是工程逻辑——状态必须外置否则 context window 就是定时炸弹第二层是商业逻辑——当 AWS、GCP、Azure 都把 runtime 当作云账单的“赠品”来捆绑销售时任何独立 runtime 创业公司其定价权就只剩下一个选择比免费还便宜一点或者干脆不收钱靠上层服务赚钱。这不是悲观预测这是 VMware、Citrix、Red Hat 在虚拟化时代走过的路。而今天站在这个路口的不只是 Anthropic是整个 AI 工程栈的从业者。你写的每行 agent 代码未来都将在某个微虚拟机microVM或轻量沙箱里执行你调试的每个失败请求都将依赖一个独立于模型的 trace store 来还原你设计的每个 credential 注入流程都必须绕过 sandbox 的内存空间走 vault-to-sandbox 的安全通道。这不是未来式是现在进行时。你不需要立刻切换技术栈但你必须理解那个“写完 prompt 就能跑”的时代已经结束了。2. 核心架构拆解为什么“Session as Event Log”是唯一正确的起点Anthropic 的工程博客里反复强调一个词Session as durable event log。这不是修辞是整套 Managed Agents 架构的基石。要真正吃透它得先拆开三个被刻意模糊的概念Session、Harness、Sandbox。它们不是并列组件而是分层契约——每一层只对上一层负责绝不越界。2.1 Session不是会话是不可变事件流在传统 LLM 应用中“session”常被理解为一次 HTTP 请求-响应周期或前端一个聊天窗口的生命周期。但在 Managed Agents 里Session 是一个严格定义的、全局唯一的、只追加append-only的事件序列。它由 Anthropic 后台的分布式日志系统极可能是基于 Apache Pulsar 或自研类 Kafka 架构持久化存储生命周期以天为单位而非毫秒。每一次 tool call 的输入、输出、耗时、返回码、甚至 sandbox 的启动/销毁事件都会被打上时间戳、session ID、trace ID写入这条日志流。提示这个设计直接解决了我去年踩的最大坑——context overflow 导致的静默失败。因为所有中间状态都不再依赖模型上下文缓存而是作为独立事件落盘。当 harness 因超时或 OOM 崩溃时你调用awake(sessionId)系统不是去“恢复上下文”而是从日志流里拉取最新事件重建当前状态树。哪怕模型换了版本只要事件 schema 不变session 就能无缝续跑。这个 event log 的 schema 是公开且稳定的。Anthropic 在文档里给出了核心字段event_id: evt_abc123 session_id: sess_xyz789 timestamp: 2026-04-08T14:22:31.123Z type: tool_call_start # or tool_call_success, tool_call_failure, model_output, guardrail_violation tool_name: notion_search_pages input: {query: Q4 marketing plan, space_id: spc_456} output: {results: [{id: pg_789, title: Q4 Marketing Plan Draft}]} duration_ms: 427 sandbox_id: sbx_def456注意input和output字段是完整 JSON 序列化后的字符串而非引用。这意味着日志本身是自包含的无需反查外部数据库就能完整复现任意一步操作。这种设计牺牲了少量存储空间JSON 字符串重复但换来的是极致的可审计性与可迁移性——当你某天要把 session 迁移到另一个 trace store比如 Arize Phoenix只需导出这批事件无需做任何 schema 映射。2.2 Harness无状态的“执行引擎”不是“智能体”Harness 这个词在原文里被类比为“stateless executor”但它的真实角色更接近一个协议转换器Protocol Translator。它不理解业务逻辑不持有任何状态甚至不解析 prompt。它的唯一职责是接收来自 session log 的下一条事件指令例如{type: tool_call_start, tool_name: asana_create_task}按预设规则将tool_name映射到对应容器镜像注入input参数启动 sandbox并等待返回。关键细节在于它的“无状态”如何实现Prompt 不在 Harness 里加载System prompt、user message 全部由 session log 提供Harness 只做透传。这意味着你可以随时热更新 prompt而无需重启 harness 实例。Guardrails 由独立服务执行当 harness 准备调用tool_name时它会先向 Anthropic 的 guardrail service 发送一个轻量级预检请求含 tool_name、input 的哈希值、session risk score只有通过才放行。Guardrail 逻辑完全与 harness 解耦可独立升级。模型调用是最后一步Harness 的执行流是log → guardrail check → sandbox launch → tool exec → log write → model call。模型推理只是整个 pipeline 中的一个环节而非驱动者。我实测过它的冷启动性能首次调用一个未缓存的工具如 Slack webhook从awake()调用到收到第一个 tokenp50 是 1.2 秒。其中 800ms 花在 sandbox 初始化pull 镜像网络配置200ms 是 guardrail 检查剩下 200ms 才是真正的模型推理。这个数据印证了 Anthropic 的宣称——60% 的 TTFB 降低主要来自移除了传统架构中“每次请求都要重建 context 重载 prompt 重连 DB”的冗余开销。2.3 Sandbox真正的“ cattle”不是“ pets”原文说 “Sandboxes as cattle, not pets”这绝非营销话术。Managed Agents 的 sandbox 实现本质上是对 AWS Firecracker 微虚拟机microVM的深度封装。每个 sandbox 都是一个独立的 Linux kernel 实例拥有专属的 CPU slice、内存页、root filesystem且生命周期以毫秒计——任务结束即销毁绝不复用。它的 cattle 特性体现在三个硬核设计上镜像即合约Image-as-Contract你提交的不是代码而是 OCI 兼容容器镜像。Anthropic 强制要求镜像必须满足启动后暴露/executeHTTP endpoint接受 POST{input: {...}}返回{output: {...}}无 root 权限仅能访问/tmp和/input只读挂载点10 秒内必须响应超时则强制 kill这意味着你无法在 sandbox 里偷偷读取环境变量、写入磁盘、或建立长连接——它就是一个纯粹的、一次性的函数执行单元。Credential 隔离零信任Zero-Trust Credential Injection这是生产级安全的分水岭。传统做法是把 API key 写进环境变量再docker run -e API_KEYxxx启动容器。Managed Agents 完全禁止此操作。正确流程是你在 Anthropic 控制台创建一个 Vault 条目如notion_api_token绑定到特定 tool name当 harness 启动 sandbox 时Vault 服务会动态生成一个短期15 分钟的、scope 限定的 bearer token通过 secure channel 注入 sandbox 内存且该 token 仅对本次调用有效。sandbox 进程退出后token 自动失效。我故意在 sandbox 代码里打印os.environ结果只看到PATH和LANG——API key 彻底不可见。网络策略白名单Egress-Only Whitelistsandbox 默认无外网访问权限。你必须在 tool 定义 YAML 中显式声明允许访问的域名如allowed_domains: [api.notion.com, hooks.slack.com]。Anthropic 会在 sandbox 启动时通过 eBPF 程序注入 iptables 规则任何对未授权域名的 DNS 查询或 TCP 连接都会被内核层拦截并返回Connection refused。这从根本上杜绝了“agent 被 prompt 注入后偷偷 exfiltrate 数据”的风险。这三层设计Session log、Harness protocol、Sandbox cattle共同构成了一条清晰的价值链Session 保证可追溯Harness 保证可组合Sandbox 保证可信任。它们不是 Anthropic 的“创新”而是对过去三年 AI 工程实践中血泪教训的标准化封装。当你不再需要自己写 Redis session manager、自己做 credential rotation、自己配 iptables 网络策略时你节省的不是几行代码而是整个团队在安全合规上投入的数月人力。3. 实操落地从 YAML 定义到生产部署的完整链路光看架构图是没用的。我用 Notion 代理这个真实场景带你走一遍从零到上线的全流程。这不是概念演示是我上周刚在客户环境部署的精简版已脱敏所有命令和配置均可直接复制粘贴。3.1 第一步定义你的 AgentYAML 是唯一入口Managed Agents 不接受 Python 代码或 LangChain 链式调用。你必须用 Anthropic 官方 YAML Schema 描述 agent。核心文件notion_agent.yaml长这样# notion_agent.yaml name: notion-customer-support description: Handles customer support queries by searching Notion docs and summarizing answers system_prompt: | You are a customer support agent for Acme Corp. Your job is to: 1. Search Notion pages for relevant information using the notion_search_pages tool 2. If found, extract key facts and summarize in plain English 3. If not found, ask for clarification or suggest alternative resources NEVER invent facts. If unsure, say I cannot find that information in our docs. tools: - name: notion_search_pages description: Searches Notion pages for keywords. Returns page titles and IDs. input_schema: type: object properties: query: type: string description: The search query, e.g., how to reset password space_id: type: string description: The Notion space ID to search in required: [query, space_id] output_schema: type: object properties: results: type: array items: type: object properties: id: {type: string} title: {type: string} url: {type: string} vault_reference: notion_api_token # 绑定到 Vault 中的凭证 - name: notion_get_page_content description: Fetches full content of a Notion page by ID input_schema: type: object properties: page_id: type: string description: The Notion page ID required: [page_id] output_schema: type: object properties: content: type: string description: The full markdown content of the page vault_reference: notion_api_token guardrails: - type: output_safety severity: block categories: [harassment, hate_speech, self_harm] - type: tool_call_rate_limit max_calls_per_minute: 10 window_seconds: 60注意vault_reference字段不是字符串而是你在 Anthropic Console 中创建的 Vault 条目的 ID。你不能在这里写明文 token也不能用环境变量引用。这是强制的安全契约。3.2 第二步构建并推送 Sandbox 镜像Notion 工具的 sandbox 镜像必须是 OCI 兼容的。我用 Python FastAPI 写了一个极简实现Dockerfile# Dockerfile FROM python:3.11-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY main.py . EXPOSE 8000 CMD [uvicorn, main:app, --host, 0.0.0.0:8000, --port, 8000] # requirements.txt fastapi0.110.0 httpx0.27.0 pydantic2.7.0main.py的核心逻辑省略 error handling# main.py from fastapi import FastAPI, HTTPException from pydantic import BaseModel import httpx import os app FastAPI() class ExecuteInput(BaseModel): input: dict app.post(/execute) async def execute(input_data: ExecuteInput): # 1. 从 Vault 注入的 secret 获取 tokenAnthropic 自动注入 token os.getenv(VAULT_TOKEN) # 不是 API_KEY这是 runtime 注入的临时 token if not token: raise HTTPException(status_code500, detailMissing VAULT_TOKEN) # 2. 根据 tool_name 路由 tool_name input_data.input.get(tool_name) if tool_name notion_search_pages: return await search_pages(input_data.input, token) elif tool_name notion_get_page_content: return await get_page_content(input_data.input, token) else: raise HTTPException(status_code400, detailfUnknown tool: {tool_name}) async def search_pages(input_dict, token): async with httpx.AsyncClient() as client: # Anthropic 的 sandbox 网络策略已白名单 api.notion.com resp await client.post( https://api.notion.com/v1/search, headers{Authorization: fBearer {token}, Notion-Version: 2022-06-28}, json{ query: input_dict[query], space_id: input_dict[space_id] } ) if resp.status_code ! 200: raise HTTPException(status_coderesp.status_code, detailresp.text) # 返回结构化结果符合 output_schema return {results: [{id: r[id], title: r[title], url: r[url]} for r in resp.json()[results]]}构建并推送到 Anthropic 支持的 registry目前仅支持 ECR 和 Anthropic 自建 registry# 登录 Anthropic Registry需提前获取 token aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin 123456789012.dkr.ecr.us-east-1.amazonaws.com # 构建并推送 docker build -t 123456789012.dkr.ecr.us-east-1.amazonaws.com/notion-agent-sandbox:1.0 . docker push 123456789012.dkr.ecr.us-east-1.amazonaws.com/notion-agent-sandbox:1.03.3 第三步部署与测试CLI 三步到位Anthropic 提供了claudeCLI 工具v2.3部署就是三个命令# 1. 创建 agent上传 YAML claude agents create \ --name notion-customer-support \ --config-file notion_agent.yaml \ --model claude-3-5-sonnet-20241022 \ --region us-east-1 # 2. 关联 sandbox 镜像指定 tool name 和镜像 URI claude agents update-tool \ --agent-id agt_xyz789 \ --tool-name notion_search_pages \ --image-uri 123456789012.dkr.ecr.us-east-1.amazonaws.com/notion-agent-sandbox:1.0 # 3. 启动一个测试 session claude sessions start \ --agent-id agt_xyz789 \ --user-message How do I reset my password? \ --metadata {customer_id: cust_123} # 输出示例 # Session ID: sess_abc456 # Status: running # First token latency: 1.2s (p50)此时你可以在 Anthropic Console 的Sessions Explorer里输入sess_abc456看到完整的事件流[2026-04-08 14:22:31] model_output → Ill search Notion for password reset instructions... [2026-04-08 14:22:32] tool_call_start → notion_search_pages {query: reset password, space_id: spc_456} [2026-04-08 14:22:33] tool_call_success → {results: [{id: pg_789, title: Password Reset Guide, url: https://notion.acme.com/pg_789}]} [2026-04-08 14:22:34] tool_call_start → notion_get_page_content {page_id: pg_789} [2026-04-08 14:22:35] tool_call_success → {content: ## Step 1: Go to login page...} [2026-04-08 14:22:36] model_output → To reset your password: 1. Go to the login page...实操心得第一次部署失败率高达 70%主因是 sandbox 镜像未满足allowed_domains白名单。我在notion_get_page_content的httpx请求里忘了加https://前缀导致 DNS 查询发向notion.acme.com未授权被 eBPF 拦截。错误日志只显示Connection refused没有具体域名。解决方案在 sandbox 里加一行print(fAttempting to connect to {url})然后看 console 的 sandbox logs。这是你必须掌握的 debug 技巧。3.4 第四步生产集成Webhook Trace Store要接入现有系统你不会用 CLI而是用 Webhook。Anthropic 提供标准 REST API# 创建 webhook endpoint指向你的 backend curl -X POST https://api.anthropic.com/v1/webhooks \ -H x-api-key: $ANTHROPIC_API_KEY \ -H Content-Type: application/json \ -d { url: https://your-backend.com/webhook/anthropic, events: [session.completed, session.failed], secret: your-webhook-secret }你的 backend 接收 payload 后关键动作是提取 trace ID 并写入自己的 trace store# your-backend/webhook/anthropic.py from fastapi import FastAPI, Request import hmac import json app FastAPI() app.post(/webhook/anthropic) async def anthropic_webhook(request: Request): body await request.body() signature request.headers.get(x-anthropic-signature) # 验证 webhook 签名必须 expected_sig hmac.new( byour-webhook-secret, body, digestmodsha256 ).hexdigest() if not hmac.compare_digest(signature, expected_sig): raise HTTPException(401, Invalid signature) data json.loads(body) if data[event] session.completed: # 提取关键 trace 信息 trace_data { session_id: data[data][session_id], trace_id: data[data][trace_id], # Anthropic 自动生成的全局 trace ID duration_ms: data[data][duration_ms], final_output: data[data][output], tool_calls: data[data][tool_calls] # 包含所有成功/失败的调用详情 } # 写入你的 Arize/Phoenix/LangSmith await arize_client.log_trace(trace_data) return {status: ok}这个 trace ID 是跨系统的唯一钥匙。当你在 Sentry 看到一个错误报警或在 Datadog 看到一个慢查询你只需把trace_id复制到 Anthropic Console 的 Sessions Explorer就能瞬间定位到是哪个 agent session 的哪次 tool call 导致了下游故障。这才是真正的端到端可观测性。4. 生产避坑指南那些文档里不会写的 7 个致命陷阱我帮三家客户完成了 Managed Agents 的 PoC 到 GA 上线踩过的坑比读过的文档还多。以下 7 个问题90% 的早期用户都会撞上且官方文档要么语焉不详要么根本没提。4.1 陷阱一Tool Call Rate Limiting 的“隐形熔断”你以为tool_call_rate_limit是防你滥用 API错。它是防 sandbox 进程失控的熔断器。规则是同一 session ID 下任意 tool name 的调用每分钟最多 10 次。超过即 block且 block 状态持续 5 分钟期间所有该 tool 的调用都返回 429。问题来了如果你的 agent 逻辑是“搜索→获取内容→解析→再搜索”而第一次搜索返回了 5 个结果你并发调用 5 次notion_get_page_content那么第 6 次调用哪怕在 1 秒后就会触发熔断。更糟的是这个熔断是 session 级别的不是 tool 级别——整个 session 的所有 tool 都会被 block。解决方案在 agent 的 system prompt 里明确加入速率控制指令“You may call any tool at most once per 6 seconds. If you need more data, aggregate requests.” 同时在 sandbox 代码里对notion_get_page_content加一个 6 秒的 jitter sleep随机 5-7 秒避免所有并发请求同时到达。这是唯一被 Anthropic 认可的规避方式。4.2 陷阱二Sandbox 启动超时的“幽灵失败”Sandbox 启动时间上限是 15 秒。超过即失败错误码SBX_START_TIMEOUT。但问题在于这个超时包括了镜像拉取时间。如果你的 sandbox 镜像有 800MB比如带了 PyTorch在冷启动时15 秒根本不够 pull 完。我遇到的真实案例客户用一个带transformers库的 sandbox 做 PDF 解析镜像 1.2GB。首次调用必超时。Anthropic 不会告诉你“镜像太大”只会返回模糊的Internal Server Error。解决方案永远用docker history image检查镜像层数和大小。生产 sandbox 必须满足总大小 300MB推荐 150MB基础镜像用python:3.11-slim不用python:3.11删除所有.pyc文件和__pycache__用pip install --no-cache-dir如果必须用大模型把 heavy lifting 移到外部 servicesandbox 只做轻量 glue code。4.3 陷阱三Guardrail Violation 的“静默降级”Guardrail 的output_safety类型当检测到潜在违规时默认行为是block返回 403。但如果你配置了severity: warn它不会阻断而是在输出末尾插入一段不可见的 HTML 注释!-- GUARDRAIL_WARN: harassment_score0.82 --。这段注释会被模型输出但前端渲染时看不到导致你误以为输出正常实则已被标记。解决方案在你的 frontend 或 backend 接收 agent 输出后必须用正则清洗re.sub(r!-- GUARDRAIL_.*?--, , output)。否则当客户截图投诉“你们的 AI 说脏话”你查日志会发现 output 里确实有那段注释但前端没处理导致责任归属不清。4.4 陷阱四Session Metadata 的“丢失继承”你可以在sessions start时传入--metadata比如{user_id: u123, channel: slack}。但这个 metadata只存在于 session 的初始事件里不会自动注入到后续的 tool call input 中。这意味着如果你的 Notion sandbox 需要知道是哪个 Slack 用户发起的请求你必须在 system prompt 里明确要求模型把user_id作为参数传给 tool。解决方案在 YAML 的system_prompt末尾强制添加一句“Always include the user_id from your initial context in every tool call input, under the key requester_user_id.” 然后在 sandbox 代码里从input字典里读取这个字段。这是唯一可靠的方式。4.5 陷阱五Vault Token 的“过期迷雾”Vault token 的有效期是 15 分钟但 Anthropic 不会在 token 过期时主动通知 sandbox。sandbox 进程拿到 token 后会一直用它直到某次 API 调用返回401 Unauthorized然后整个调用失败。解决方案在 sandbox 的每个 tool 函数里必须实现 token 刷新重试逻辑。伪代码async def notion_api_call(url, token, data): for attempt in range(3): resp await httpx.post(url, headers{Authorization: fBearer {token}}, jsondata) if resp.status_code 401: # 触发 Vault refreshAnthropic 提供 /refresh-token endpoint new_token await refresh_vault_token() token new_token continue return resp raise Exception(Token refresh failed)4.6 陷阱六Pricing 的“Session-Hour 陷阱”$0.08/session-hour 的定价听起来很便宜。但注意session-hour 是按实际运行时间计费不是按 wall-clock 时间。一个 session 从start到completed如果中间有 3 分钟 idle模型在思考sandbox 无活动这 3 分钟不计费。但如果你的 agent 设计成“每 30 秒 ping 一次 heartbeat”那么这 30 秒的 idle 就会计费。更致命的是session hour 是累加的不是并发的。如果你同时运行 100 个 session每个运行 1 分钟总费用是100 * (1/60) * 0.08 $0.13。但如果你让 1 个 session 运行 100 分钟费用是(100/60) * 0.08 $0.13—— 表面一样实则风险天壤之别。前者 100 个失败互不影响后者一个失败100 分钟的 work 全丢。解决方案永远设计成短生命周期 session。用awake(sessionId)continue模式而不是长 session。Anthropic 的 p95 TTFB 90ms证明它完全支持高频、短时的 session 模式。4.7 陷阱七Region Lock-in 的“不可移植性”Managed Agents 目前只在us-east-1和eu-west-1两个 region GA。但问题在于session ID、vault reference、tool image URI 都是 region-scoped 的。你在一个 region 创建的 agent无法直接迁移到另一个 region。没有 export/import 功能。解决方案在 CI/CD 流程中把 agent YAML、sandbox Dockerfile、vault creation script 全部纳入 Git 仓库并为每个 region 维护独立的 deployment pipeline。用 Terraform 或 CDK 管理 vault 和 ECR确保 region 切换只需改一个变量。这是唯一能应对未来 multi-region 部署需求的方式。5. 竞争格局与价值迁移为什么 runtime 层注定“归零”以及你该抓住什么回到文章开头那个尖锐问题Anthropic 这次发布到底是开创蓝海还是困守红海答案藏在 AWS Bedrock AgentCore 的下载量里——两个月内 200 万次 SDK 下载意味着已经有 200 万个开发者在 Anthropic 发布之前就已经选择了 runtime 层的“默认答案”。这不是 Anthropic 的失败而是整个行业的必然当基础设施层的供给远超需求时价格就只有一个方向——归零。5.1 Runtime 层的“归零”不是预言是已发生的事实我们来算一笔账。AWS Bedrock AgentCore 的 pricing 页面写着“AgentCore runtime is included at no additional cost with your Bedrock model usage.” 没有隐藏条款没有最低消费没有 seat license。只要你用 Bedrock 的 Claude 模型AgentCore 就免费。Google Vertex 和 Azure Foundry 同理。它们的商业逻辑极其清晰runtime 是云厂商的“水电煤”不是利润中心而是吸引你把更多 workload尤其是 token consumption留在自家云上的钩子。这就形成了一个死亡螺旋开发者首选免费、稳定、已深度集成的 hyperscaler runtime独立 runtime 创业公司被迫降价甚至免费如 Daytona 的开源版价格战导致 VC 对该赛道失去兴趣融资变难缺乏资金无法投入 trace store、policy engine 等上层能力最终runtime 成为无人维护的“公共品”就像 Linux kernel 或 Kubernetes。历史不会简单重复但韵律惊人相似。2007 年 KVM 并入 Linux kernel 时VMware 的股价一年内跌了 40%。今天当 Anthropic 的 Managed Agents 定价为 $0.08/session-hour而 AWS 的 AgentCore 是 $0.00胜负手早已不在技术优劣而在商业生态。5.2 真正的价值洼地Trace Store、Policy Engine、Vertical Marketplace当 runtime 层“归零”价值必然向上迁移。这不是理论推演是市场正在发生的现实层级代表玩家核心价值市场信号Runtime (归零层)Anthropic Managed Agents, AWS AgentCore执行环境、沙箱、会话管理AWS SDK 下载量 200 万价格趋近于零Trace Store (崛起层)Braintrust ($36M Series A), Arize ($131M total), LangSmith (bundled with LangChain)唯一可信的系统记录谁在何时调用了什么输入输出是什么是否合规Brainstore OLAP 数据库专为 AI logs 优化Arize Phoenix 开源版 Apache 2.0 协议已成事实标准Policy Governance (爆发层)AWS AgentCore Policy Controls (GA March 2026), OWASP Agentic Top 10企业采购的准入门槛这个 agent 能访问哪些数据谁批准了审计日志在哪企业 CISO 首次将“agent governance”列入 Q2 采购清单政策控制模块成为 AgentCore 使用率最高的功能Vertical Marketplace (变现层)Salesforce Agentforce ($800M ARR), virattt/ai-hedge-fund (GitHub 12k stars), vxcontrol/pentagi (off