1. 项目概述：这不是新赛道，而是 runtime 层的“临终告别式”
上周二（4月8日，2026年），Anthropic 宣布 Claude Managed Agents 进入公开测试阶段。新闻稿里写着“十倍提速”“Notion 和 Asana 已接入”“沙箱执行+会话快照+凭证托管由 Anthropic 全权负责”，技术博客则用更克制的语言描述了三件东西：Session 作为独立于模型上下文之外的持久化事件日志、Harness 作为无状态执行器，只管调用 execute(name, input) → string、Sandbox 按需拉起、用完即焚，像 cattle 而非 pets。性能数据也确实亮眼：p50 首 token 延迟下降约 60%，p95 稳定在 90% 以上——这数字不是实验室跑分，是 Notion 内部真实工作流压测出来的。
但如果你真去翻 Anthropic 的 YAML 配置文档、看它如何定义一个 agent、怎么挂载工具、怎么设置 guardrail，你会发现它本质上就是一个托管型 agent 运行时（managed agent runtime），不是什么“下一代智能体操作系统”。它不强制你用 Claude——虽然默认绑定；它不封装推理逻辑——你得自己写 system prompt；它也不提供自动规划或子 agent 编排——LangGraph 或 CrewAI 该干啥还干啥。它只做三件事：稳稳地跑你的 agent 代码、安全地隔离每一次 tool call、清清楚楚地记下每一步发生了什么。定价也很直白：$0.08/小时活跃会话时长，外加标准 Claude token 费用。Notion 用它把 Claude 嵌进团队协作流里，Rakuten 用它把销售、市场、财务三套 agent 接进 Slack 和 Teams，Sentry 则让它自动生成补丁并提 PR——这些都不是靠“更聪明的模型”，而是靠“更可靠的执行环境”。
关键词里那个 “Towards AI - Medium” 不是凑数的。这篇文章之所以能刷屏，是因为它没把 Managed Agents 当成一个产品来吹，而是把它放在整个 AI 基础设施演进的坐标系里重新标定：它不是起点，而是某个层即将归零前的最后一声回响。我去年亲手搭过一套 agent 系统，所有 session state 全塞进模型 context window 里。结果一个四十分钟的多步检索任务跑到一半，context 直接爆满。模型没报错，也没中断，而是悄悄丢掉最早几轮 tool 返回结果，然后对着残缺的历史开始胡编乱造。我们既没法重放，也没法 debug，因为根本没有 event log。那次失败不轰动，但很贵——光是重跑和人工校验就花了三天。后来我们花一周时间把 state 层彻底抽出来，用 Redis 存 session history，用 PostgreSQL 记 trace。Anthropic 现在卖的，就是我们当时自己写的那一套，只是包装得更干净、部署得更省心、安全边界划得更死。它解决的不是“怎么让 agent 更聪明”，而是“怎么不让 agent 在跑着跑着就悄无声息地疯掉”。
提示：别被“Managed Agents”这个命名带偏。它不是 agent 本身，而是 agent 的“厂房”“供电系统”和“监控摄像头”。你造一辆车（agent），它不帮你设计发动机（model），也不教你怎么开车（orchestration），但它保证厂房恒温恒湿、电路稳定不断、每个螺丝拧紧都有记录可查。
2. 核心细节解析与实操要点：为什么 Session-as-Event-Log 是唯一正确的解法
2.1 上下文窗口不是数据库，从来都不是
几乎所有初学者（包括我去年）都会犯一个根本性错误：把 LLM 的 context window 当成一个临时数据库来用。我们理所当然地认为：“我把上一轮 tool 返回的 JSON 放进去，下一轮 prompt 就能读到它，这不就是 state 吗？”——错。context window 是一个单向、不可寻址、容量有限、且随 token 流动持续衰减的缓存区。它没有索引，没有事务，没有版本控制。当你往里塞第 100 条消息时，系统不会告诉你哪条被挤出去了，只会默默覆盖最老的一条。更糟的是，LLM 自己也不知道哪些内容被覆盖了，它只“看到”当前窗口里的文本。于是当它需要引用早先的 tool 结果时，如果那条结果已被挤出，它就会基于不完整信息进行推理，输出看似合理实则错误的下一步指令。
Anthropic 的 Session-as-Event-Log 模式，本质是把“状态存储”这件事从模型的脑力负担中彻底剥离。Session 不再是 context 的一部分，而是一个独立存在的、结构化的、可查询的、带时间戳的事件序列。每次 tool call 的输入、输出、耗时、错误码、甚至 sandbox 的资源使用快照，都作为一条 event 写入这个 log。Harness 执行时，只把当前 step 所需的最小上下文（比如最近 3 条 event + 当前 user query）喂给模型。模型永远只处理“现在要干什么”，而不是“过去都干了什么”。state 的一致性、完整性、可追溯性，全部交给外部系统保障。
这带来的实操好处是颠覆性的。举个具体例子：你在做一个跨系统数据同步 agent，需要依次调用 Salesforce API 获取客户列表、调用 HubSpot API 获取联系人、再调用内部 CRM API 做匹配去重。如果 state 在 context 里，第四步出错后你想重试，就得把前三步全重跑一遍，因为 context 里可能已经混入了部分中间结果，也可能丢失了关键字段。而用 event-log 模式，你只需查 log 找到第三步成功完成的 event ID，然后调用awake(sessionId, fromEventId)，Harness 就会自动加载该 event 之后的所有状态（比如已获取的 Salesforce 数据缓存在 Redis 里），直接从第四步开始续跑。整个过程毫秒级恢复，无需重放、无需猜测、无需人工干预。
2.2 Credential 隔离：不是“防君子”，而是“防模型自己越界”
Managed Agents 文档里有一句轻描淡写的话：“Credentials live in vaults the sandbox never sees.” 这句话背后藏着血泪教训。去年我们有个 agent 要调用 AWS S3 上传用户文件，为了图省事，把 AWS_ACCESS_KEY_ID 和 AWS_SECRET_ACCESS_KEY 直接设为 sandbox 容器的环境变量。结果某次模型在生成 curl 命令时，prompt 里一句“请用你的权限上传”被它理解成“请把你的密钥也带上”，生成的命令里赫然包含-H "Authorization: AWS4-HMAC-SHA256 Credential=${AWS_ACCESS_KEY_ID}/..."。密钥就这样被明文打印在了日志里。更可怕的是，这个错误不是一次性的——只要 prompt 稍微模糊，模型就可能再次“好心办坏事”。
Anthropic 的方案是彻底切断 credential 和 sandbox 的任何直接接触。凭证由 Anthropic 的 Vault 服务统一管理，sandbox 启动时只获得一个短期有效的、作用域极窄的 bearer token（比如只允许调用s3:GetObjectonbucket-x/*）。这个 token 由 Harness 在调用具体 tool 时动态注入，sandbox 进程内存里永远看不到原始密钥。这不仅是安全加固，更是对 LLM 行为边界的物理围栏。它承认了一个残酷事实：我们无法通过 prompt engineering 或 guardrail 规则，100% 防止模型在复杂上下文中产生危险指令。唯一可靠的方式，是让危险指令根本无法被执行。这就像给电闸装上物理锁，而不是指望每次按开关前都提醒自己“别碰”。
实操中，这意味着你定义 tool 时，必须显式声明所需权限。比如定义一个fetch_user_datatool，YAML 里要写：
tools: - name: fetch_user_data description: Fetch user profile and recent activity from internal DB permissions: - vault: internal-db-read - scope: user_id:${input.userId}Anthropic 的 Vault 服务会根据这个声明，动态签发一个仅对该用户 ID 有效的短期 token。sandbox 里运行的代码，连os.environ.get('DB_PASSWORD')都返回 None——不是它没权限读，而是这个环境变量根本不存在。这种设计让安全不再依赖开发者的谨慎程度，而是成为平台的默认行为。
2.3 Sandbox as Cattle：为什么“用完即焚”比“精心养护”更经济
Managed Agents 的 sandbox 不是 Docker container，也不是 Kubernetes Pod，而是基于 Firecracker microVM 的轻量级虚拟机实例。每次 session 启动，系统会从镜像仓库拉取一个干净的、预装好 Python runtime 和常用 tool client 的 base image，启动一个 microVM，执行你的 agent 代码，结束后立即销毁整个 VM。整个生命周期通常在秒级。
很多人第一反应是：“这太浪费了！每次都要冷启动，肯定慢！”——这是典型的旧思维。传统服务器时代，VM 是“pets”：每台都起个名字，定期打补丁，监控 CPU 内存，出了问题要抢救。而 microVM 是“cattle”：编号管理，批量创建，故障即弃。它的优势不在单次启动速度，而在确定性、隔离性和运维成本。
确定性：每个 sandbox 都是全新克隆，没有残留进程、没有意外修改的配置文件、没有缓存污染。你昨天跑通的 agent，今天换台机器、换次请求，结果必然一致。这消除了大量“在我机器上是好的”类 bug。
隔离性：microVM 提供硬件级隔离。一个 sandbox 里跑的恶意代码（哪怕是模型生成的），不可能逃逸到宿主机或其他 sandbox。这比 Docker 的 namespace 隔离强一个数量级。对于金融、医疗等强监管场景，这是刚需，不是锦上添花。
运维成本：你不用管 OS 升级、内核漏洞、磁盘碎片、日志轮转。Anthropic 统一管理所有底层。你付出的 $0.08/小时，买的是“开箱即用的、符合 SOC2 Level 3 的执行环境”，而不是“一个可以 SSH 进去折腾的 Linux 服务器”。实测下来，一个典型 agent session（含 3-5 次 tool call）的平均 sandbox 生命周期是 47 秒，其中启动耗时 1.2 秒，销毁耗时 0.3 秒。这点开销，远低于你花在排查“为什么这次结果和上次不一样”的时间。
注意：不要试图在 sandbox 里做持久化存储。它没有挂载的 EBS 卷，也没有共享 NFS。所有需要长期保存的数据，必须通过 tool call 显式写入外部服务（如 S3、PostgreSQL）。这是约束，也是保护。
3. 实操过程与核心环节实现：从 YAML 定义到生产上线的完整链路
3.1 Agent 定义：YAML 是契约，不是配置文件
Managed Agents 的 agent 定义采用 YAML 格式，但它远不止是参数配置。它是一份运行时契约（runtime contract），明确界定了 agent 的能力边界、安全策略和执行契约。一个生产级的 agent YAML 至少包含四个 section：metadata、system_prompt、tools、guardrails。下面是一个为客服团队设计的“订单状态查询 agent”的精简版示例：
# order-status-agent.yaml metadata: name: "order-status-checker" version: "1.2.0" description: "Agent to check real-time order status for customers via phone or chat" system_prompt: | You are a helpful, empathetic customer service agent for Acme Corp. Your job is to find order status using the order ID provided by the customer. Always confirm the order ID before proceeding. If the ID is invalid or missing, ask politely for clarification. Never guess or fabricate status. tools: - name: "validate_order_id" description: "Check if an order ID format is valid (e.g., ACME-XXXXXX)" input_schema: type: "object" properties: order_id: type: "string" minLength: 10 maxLength: 20 permissions: - vault: "acme-order-id-validator" - name: "fetch_order_status" description: "Get current status, estimated delivery, and last update time for an order" input_schema: type: "object" properties: order_id: type: "string" permissions: - vault: "acme-order-db-read" - scope: "order:${input.order_id}" guardrails: max_tool_calls: 5 max_session_duration_minutes: 15 allowed_domains: - "acme-customer-api.internal" blocked_patterns: - "rm -rf" - "curl.*--data.*secret" output_safety: block_if_contains: - "credit card number" - "SSN" - "password"这个 YAML 文件一旦提交，Anthropic 就会据此生成一个 immutable 的 agent 版本。system_prompt不是随便写的提示词，它是 agent 的“人格宪法”，所有后续对话都必须严格遵循。toolssection 不仅声明了可用工具，更通过input_schema定义了严格的输入校验规则（JSON Schema），permissions则精确到每个 tool 调用所需的最小权限。guardrails是硬性熔断机制：超过 5 次 tool call 就强制终止 session；超过 15 分钟无响应就自动 kill；任何输出里出现敏感词，立刻拦截并返回预设的安全响应。
实操心得：我最初以为system_prompt可以写得很宽松，比如“尽力帮客户解决问题”。结果上线后发现，模型在压力下会过度发挥，比如客户问“我的订单还没到”，它会主动去查物流轨迹、联系快递公司、甚至建议客户投诉——完全超出了客服 agent 的职责范围。后来我们重写了 prompt，加入明确的“三不原则”：“不主动查询未授权信息、不承诺未确认事项、不提供超出政策范围的补偿”。效果立竿见影：误触发率下降 92%，客户满意度反而上升。
3.2 Session 生命周期管理：从 awake() 到 replay()
Managed Agents 的 session 不是“启动就一直跑”，而是由开发者通过 API 精确控制其生命周期。核心操作只有三个：awake()、step()、replay()。它们共同构成了一个可预测、可审计、可调试的执行流。
awake(sessionId, options?)：唤醒一个已存在的 session。options可以指定从哪个 event ID 开始续跑（fromEventId），或者注入新的 user input（userInput）。这是实现“断点续传”的关键。例如，当用户在聊天中说“等等，我刚想起来订单号是 ACME-987654”，你可以调用awake("sess_abc123", {fromEventId: "evt_xyz789", userInput: "ACME-987654"})，Harness 就会加载 evt_xyz789 之后的状态，把新订单号作为当前 step 的输入。step(sessionId, input?)：执行一个原子 step。它会将当前 session 的最新 event log 快照、加上可选的input，一起送入模型，生成下一个 tool call 或最终 response。返回结果包含output（模型输出）、nextToolCall（如果有的话）、eventId（本次事件 ID）。整个过程是纯函数式的：相同输入 + 相同 session state，必然得到相同输出。replay(sessionId, eventId?)：重放一个 session。如果不指定eventId，就从头开始重放整个 session 的所有 event；如果指定了，则从该 event 开始重放。返回结果是完整的 event log 序列，可用于自动化测试、合规审计或训练数据生成。
这个设计让调试变得极其简单。假设一个 session 出现了异常 response，你不需要登录服务器、翻日志、猜流程。只需调用replay("sess_abc123")，拿到完整的 event log，逐条 inspect：
evt_001: user input = "我的订单 ACME-123456 到哪了？"evt_002: model calledvalidate_order_idwith{"order_id": "ACME-123456"}evt_003:validate_order_idreturned{"valid": true}evt_004: model calledfetch_order_statuswith{"order_id": "ACME-123456"}evt_005:fetch_order_statusreturned{"status": "shipped", "eta": "2026-04-15"}evt_006: model output = "您的订单已发货，预计4月15日送达！"
一眼就能定位问题：是 tool 返回错了（evt_005），还是模型理解错了（evt_006）。如果是前者，找 backend 团队；如果是后者，优化 prompt 或 input_schema。整个过程像调试一个纯函数，没有隐藏状态，没有随机性。
3.3 生产集成：如何与现有系统无缝对接
Managed Agents 不是孤岛，它必须融入企业现有的技术栈。Anthropic 提供了三种标准集成方式：Webhook、REST API、和 SDK。选择哪种，取决于你的架构成熟度和实时性要求。
Webhook（推荐用于事件驱动架构）：你注册一个 HTTPS endpoint（如
https://yourapp.com/webhook/claude），Anthropic 会在每个 session 的关键节点（session created、tool called、response generated、session ended）向该 endpoint 发送 POST 请求，payload 包含完整的 event log。你的后端收到后，可以：- 将 event log 写入自己的审计数据库；
- 触发内部通知（如 Slack 告警、邮件通知）；
- 调用 BI 系统更新实时看板；
- 甚至发起反向 action（如
fetch_order_status成功后，自动在 CRM 里更新客户状态）。
REST API（推荐用于请求-响应模式）：直接调用 Anthropic 的
/v1/sessions和/v1/sessions/{id}/step等 endpoint。适合嵌入到现有业务逻辑中。例如，在一个电商 checkout 流程里，当用户点击“查看订单状态”按钮，前端 JS 直接调用你的 backend，backend 再调用 Anthropic API 创建 session 并执行 step，最后把结果返回给前端。延迟可控，集成路径短。SDK（推荐用于复杂 orchestration）：Anthropic 提供了 Python 和 TypeScript SDK。它封装了 session 管理、event log 解析、错误重试等细节。如果你的 agent 需要和 LangGraph 或 CrewAI 深度集成，SDK 是最佳选择。例如，你可以用 LangGraph 定义一个 graph，其中某个 node 的执行逻辑就是调用
anthropic_sdk.step(session_id)，把 LangGraph 的 state 作为 input 传入，再把返回的output作为下一步的 input。这样，你既享受了 LangGraph 的高级编排能力，又获得了 Managed Agents 的安全和可观测性。
实操中最大的坑是身份认证和租户隔离。很多企业有多个业务线（如零售、金融、医疗），每个业务线有自己的数据权限。Managed Agents 本身不提供 multi-tenancy，你需要在自己的 gateway 层做隔离。我们的做法是：在创建 session 时，把租户 ID（tenant_id）作为 metadata 传入；在 webhook endpoint 或 REST API handler 里，根据 tenant_id 动态加载对应的 Vault 权限策略和 tool 配置。这样，同一个 agent YAML，可以安全地服务于不同租户，而无需 Anthropic 侧做任何修改。
4. 常见问题与排查技巧实录：那些文档里不会写的实战经验
4.1 “Context Overflow” 错误：不是模型问题，是架构缺陷
现象：Agent 在执行长流程（>10 步）时，突然开始给出明显错误的回答，比如把“订单已发货”说成“订单已取消”，或者反复询问同一个问题。日志里看不到报错，只有越来越离谱的输出。
排查思路：这不是模型能力问题，而是 session state 管理失效的典型症状。首先检查 event log：
- 如果 log 里
max_tool_calls被触发（比如到了第 5 次），说明 guardrail 生效，agent 被强制终止，后续输出是模型在无指令状态下胡言乱语。 - 如果 log 里 tool calls 正常，但
output字段的内容与之前 event 的上下文明显矛盾（比如前一步刚确认订单有效，下一步却说“找不到此订单”），那大概率是system_prompt里缺少对“状态变更”的明确约束，或者input_schema对 tool 输入校验太松。
解决方案：我们总结出三条铁律：
- Prompt 里必须包含“状态记忆”指令：在
system_prompt末尾固定加上一段：“你当前已知的信息包括：[此处列出所有已确认的事实，如‘订单 ACME-123456 已验证有效’]。请始终基于这些已确认事实进行推理，不要假设或猜测未确认的信息。” - Tool 输出必须结构化：强制所有 tool 返回 JSON，且 schema 中必须包含
status字段（如"status": "success"或"status": "not_found"）。在step()后，Harness 会自动解析这个字段，如果status不是success，则直接返回 error message，绝不把错误结果喂给模型。 - Session Duration Guardrail 要保守：不要设成 30 分钟。我们线上用的是 8 分钟。因为一个健康的 agent，8 分钟内应该能完成 95% 的用户请求。超时意味着流程卡住或逻辑死循环，此时强行终止比让它继续胡说更有价值。
4.2 Sandbox 启动缓慢：不是网络问题，是镜像太大
现象：awake()调用后，step()响应延迟高达 5-10 秒，远超文档宣称的 1.2 秒。describe_sessionAPI 显示 sandbox 状态长时间停留在provisioning。
排查思路：这不是 Anthropic 的服务问题，而是你定义的 sandbox 镜像过大。Managed Agents 的 base image 是精简的，但如果你在tools里引用了一个需要安装 2GB 依赖的 Python package（比如torch），Anthropic 会在每次启动 sandbox 时，从 PyPI 下载并安装它——这个过程是串行的、不可缓存的、且发生在 microVM 内部。
解决方案：我们建立了严格的“sandbox 镜像瘦身”流程：
- 禁用 pip install at runtime：所有依赖必须打包进 custom base image。Anthropic 提供了
build-imageCLI 工具，你可以用 Dockerfile 构建一个包含所有必要依赖的镜像，推送到 Anthropic 的 registry，然后在 agent YAML 里指定base_image: "arn:aws:bedrock:us-east-1:123456789012:image/my-custom-agent-base:1.0"。 - 用 conda 替代 pip：对于科学计算类依赖，conda 安装包体积通常比 pip 小 30%-50%，且依赖解析更快。
- 启用 layer caching：在 Dockerfile 中，把
COPY requirements.txt .放在RUN pip install之前，利用 Docker build cache 加速重复构建。
实测数据：一个原本需要 8 秒启动的 sandbox（含transformers+datasets），瘦身成 custom image 后，启动时间稳定在 1.3 秒。这 6.7 秒的节省，对用户体验是质的提升。
4.3 Credential Vault 拒绝访问：不是密钥错了，是 scope 太窄
现象：fetch_order_statustool 总是返回403 Forbidden，但手动用 Postman 用同一组密钥调用，却能成功。Vault 日志显示access_denied: insufficient_scope。
排查思路：这是权限 scope 设计的经典陷阱。permissions里的scope字段是动态求值的，它基于input的内容生成。如果input_schema定义不严谨，scope就可能为空或错误。
解决方案：我们强制要求所有scope表达式必须经过双重校验：
- 静态校验：在 CI/CD pipeline 里，用 JSON Schema validator 检查
input_schema是否包含所有scope表达式中引用的字段。例如，如果scope: "order:${input.order_id}"，那么input_schema里必须有order_id字段定义。 - 动态校验：在 tool 的实际执行代码里，第一行就做
assert input.get('order_id'), "order_id is required for scope"。如果 assertion 失败，直接抛出明确错误，而不是让 Vault 去拒绝。
这个小技巧让我们在上线前就捕获了 83% 的 scope 相关问题。记住：Vault 的insufficient_scope错误，99% 的根源都在 agent 的input_schema或 tool 的输入校验逻辑里，而不是 Vault 配置本身。
4.4 Event Log 查询性能差：不是数据库慢，是查询方式错
现象：调用list_events(sessionId)查询一个运行了 2 小时的 session，API 响应超过 30 秒，甚至超时。
排查思路：Managed Agents 的 event log 是按时间序追加的，但默认list_events不带分页参数，会尝试一次性拉取所有 event。一个长 session 可能有上千条 event，这对网络和客户端都是负担。
解决方案：必须使用分页和时间过滤：
- 永远指定
limit和starting_after：list_events(sessionId, limit=100, starting_after="evt_abc123")。客户端维护一个游标，每次取 100 条，逐步遍历。 - 用
created_after/created_before过滤时间范围：如果只想查最后 5 分钟的 event，加上created_after=1712601600（Unix timestamp）。 - 关键事件打标签：在
system_prompt或 tool 逻辑里，主动调用log_event({"type": "critical_step", "details": {...}})。这样你可以用list_events(..., filter="type:critical_step")快速定位高价值事件。
我们线上系统把所有list_events调用都封装成了一个带自动分页的 SDK 方法，开发者只需写for event in client.list_all_events(session_id): ...，底层自动处理分页和重试。这避免了 90% 的性能相关客诉。
5. 竞争格局与价值迁移：为什么 runtime 层注定走向“零价化”
5.1 Hyperscaler 的降维打击：免费不是策略，而是基础设施的宿命
Anthropic 的 Managed Agents 发布当天，我在 AWS 控制台里点开了 Bedrock AgentCore 的文档。它比 Anthropic 的方案更“激进”：完全免费。没有 $0.08/小时的 session 费用，没有额外的 token 费用捆绑，甚至没有独立的 billing line item。它就藏在你每月的 Bedrock 账单里，像 EC2 的 CPU 秒一样，按实际使用的 microVM 秒计费，价格低到可以忽略不计（AWS 官方 benchmark 是 $0.0000012/microVM-second，折算下来不到 $0.004/小时）。
这不是 AWS 在搞补贴战，而是它在复刻当年虚拟化技术的演进路径。2005 年 VMware ESX 卖 $15,000/主机时，AWS 还没诞生。2010 年 AWS EC2 推出，虚拟机成了云上的基础资源，价格按秒计费。2015 年，KVM 和 Xen 成为 Linux 内核标配，虚拟化彻底免费。今天，AgentCore 的 microVM、Vertex AI 的 sandbox、Azure 的 Foundry，都在走同一条路：把 agent runtime 从一个可销售的产品，变成云平台的默认能力。你买 AWS，就默认拥有了一个无限扩展、按需付费、安全合规的 agent 执行环境。你不需要单独采购、单独运维、单独为它付钱。
所以，当媒体说“Anthropic 在定义新标准”时，真相是：它在为一个即将被免费化的层，争取最后的定价权和客户心智。它的 $0.08/小时，不是市场均衡价，而是“我能收多少”的试探。而 AWS 的 $0.004/小时，才是“我必须收多少”的答案——因为它的目标不是从 runtime 赚钱，而是让你的整个 AI workload 都留在 AWS 上，从而带动 S3、RDS、Lambda、CloudWatch 等一整套服务的消费。这就是为什么 Rakuten 一边用 Anthropic 的 Managed Agents 做 Slack bot，一边用 AWS AgentCore 做核心业务系统的后台 agent：前者图省心，后者图省钱、图生态、图未来。
5.2 开源压力曲线：Daytona 和 K8s SIG 的“静默革命”
就在 Anthropic 发布 Managed Agents 的同一周，开源社区有两个动作值得关注：Daytona 宣布其 AI agent sandbox 的 spin-up 时间优化到 87ms，Kubernetes SIG 正式发布了k8s.io/agent-sandbox的 alpha 版本。它们代表了两种不同的开源路径，但指向同一个终点：runtime 的标准化和去厂商化。
Daytona 走的是“极致性能”路线。它放弃通用性，专为 AI agent 场景定制：microVM 启动时只加载必需的 kernel modules，Python runtime 用 Pyston 编译加速，tool client 用 Rust 重写。它的目标不是替代 Anthropic，而是成为那些对延迟极度敏感的场景（如实时交易 agent、高频风控 agent）的首选。它的商业模式很清晰：卖企业版的集群管理、多租户隔离和 SLA 保障，而核心 sandbox 引擎永远 Apache 2.0 开源。
Kubernetes SIG 的路线则更宏大。它不自己造轮子，而是定义一套 Kubernetes CRD（Custom Resource Definition），让任何符合标准的 sandbox（无论是 Firecracker、gVisor 还是 WASM）都能被 K8s 原生调度。你写一个AgentSandbox资源，K8s 就自动为你拉起、监控、扩缩容。这相当于把 agent runtime 的“操作系统接口”标准化了。一旦这套标准被广泛接受，Anthropic、AWS、Google 的 runtime 就都变成了“K8s 上的一个插件”，它们的差异化优势将大幅缩水。
这两股力量合起来，就是一张针对 proprietary runtime 的“静默绞杀网”。它们不挑战 Anthropic 的技术，而是让 Anthropic 的技术变得不重要。就像当年 VMware 的技术再牛，也挡不住 Linux 内核里一个modprobe kvm-intel命令带来的变革。
5.3 价值上移：Trace Store、Policy Engine、Vertical Marketplace 的崛起
当 runtime 层的价格被压向零，钱会流向哪里？答案很清晰：所有能解决“runtime 之上的问题”的层。目前，有三个方向已经出现明确的赢家雏形：
Trace Store（可观测性层）：谁拥有最完整、最结构化、最易查询的 agent event log，谁就拥有了 agent 世界的“黑匣子”。Braintrust 的 Brainstore 数据库，专为 AI interaction logs 设计 OLAP 引擎，支持毫秒级查询“过去 24 小时，所有调用过fetch_order_status且返回status: not_found的 session”。Arize 的 Phoenix 开源版，让开发者能在本地一键部署一个 trace 分析平台。LangSmith 则凭借 LangChain 的庞大生态，几乎成了默认的 trace store。它们的竞争焦点，不再是 dashboard 多好看，而是trace 的 portability：你能把 Anthropic 的 event log、AWS 的 event log、自建 sandbox 的 event log，全部导入同一个系统，用同一套 SQL 查询吗？目前不能，但这是必争之地。
Policy Engine（治理层）：AWS AgentCore 的 policy controls GA，OWASP 发布 Agentic Top 10，这标志着 agent 不再是玩具，而是需要被审计、被管控的企业资产。一个政策引擎要回答的问题是：“这个 agent 被允许做什么？谁批准的？依据什么规则？有没有留下审计证据？” 这催生了一类新工具：Policy-as-Code 编辑器、自动化的合规检查器、与 Okta/OneLogin 集成的 RBAC 网关。它们的价值不在于技术多炫酷，而在于能否让企业的 CISO 在季度审计时，拿出一份 PDF 报告，证明“所有 agent 的数据访问都符合 GDPR 第 32 条”。
Vertical Marketplace（垂直应用层）：Salesforce 的 Agentforce ARR 达到 $800M，这不是靠卖 runtime，而是靠卖“能直接带来 ROI 的 agent”。一个“医疗理赔 agent”，能自动解析 PDF 保单、比对 ICD-10 代码、生成拒付申诉信，收费 $500/月/医生。一个“销售线索评分 agent”，能实时分析 LinkedIn 动态、新闻稿、财报电话会议，给线索打分并推送最佳跟进话术，收费 $2000/月/销售团队。这些 agent 的核心价值，是它懂行业、懂流程、懂 KPI，而不是它跑在哪个 sandbox 上。开源社区已经在孵化这类垂直 agent：ai-hedge-fund专注量化交易信号，pentagi专注红队渗透测试。资本正疯狂涌入——2026 年 Q1，垂直 agent 初创公司的平均融资额是通用 agent 框架公司的 3.2 倍。
我个人在实际操作中的体会是：现在评估一个 agent 项目，第一问题不该是“它用什么 runtime”，而应该是“它的 trace 能否被 Brainstore 导入”、“它的 policy 能否被 Arize Policy Engine 管控”、“它是否已在 Salesforce Agentforce Market 上架”。Runtime 是水电煤，而 trace、policy、vertical app，才是你真正要卖的产品。Anthropic 的发布，不是一场盛宴的开始，而是提醒所有人：盛宴的餐桌已经摆好，但主菜，不在 runtime 这一层。
