AI代理Runtime层的基础设施革命：从胶水代码到托管沙箱

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()调用到收到第一个 token，p50 是 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 特性体现在三个硬核设计上：

1. 镜像即合约（Image-as-Contract）：你提交的不是代码，而是 OCI 兼容容器镜像。Anthropic 强制要求镜像必须满足：

   • 启动后暴露/executeHTTP endpoint（接受 POST{"input": {...}}，返回{"output": {...}}）
   • 无 root 权限，仅能访问/tmp和/input只读挂载点
   • 10 秒内必须响应，超时则强制 kill
     这意味着你无法在 sandbox 里偷偷读取环境变量、写入磁盘、或建立长连接——它就是一个纯粹的、一次性的函数执行单元。

2. Credential 隔离零信任（Zero-Trust Credential Injection）：这是生产级安全的分水岭。传统做法是把 API key 写进环境变量，再docker run -e API_KEY=xxx启动容器。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 彻底不可见。

3. 网络策略白名单（Egress-Only Whitelist）：sandbox 默认无外网访问权限。你必须在 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 第一步：定义你的 Agent（YAML 是唯一入口）

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 fastapi==0.110.0 httpx==0.27.0 pydantic==2.7.0

main.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 获取 token（Anthropic 自动注入） token = os.getenv("VAULT_TOKEN") # 不是 API_KEY！这是 runtime 注入的临时 token if not token: raise HTTPException(status_code=500, detail="Missing 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_code=400, detail=f"Unknown 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": f"Bearer {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_code=resp.status_code, detail=resp.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.0

3.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 → "I'll 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(f"Attempting 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( b"your-webhook-secret", body, digestmod="sha256" ).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 移到外部 service，sandbox 只做轻量 glue code。

4.3 陷阱三：Guardrail Violation 的“静默降级”

Guardrail 的output_safety类型，当检测到潜在违规时，默认行为是block（返回 403）。但如果你配置了severity: "warn"，它不会阻断，而是在输出末尾插入一段不可见的 HTML 注释：<!-- GUARDRAIL_WARN: harassment_score=0.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": f"Bearer {token}"}, json=data) if resp.status_code == 401: # 触发 Vault refresh（Anthropic 提供 /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 层“归零”，价值必然向上迁移。这不是理论推演，是市场正在发生的现实：