1. 这不是新赛道，而是 runtime 层的“操作系统时刻”正在重演

你打开手机看到新闻标题《Anthropic Just Shipped the Layer That’s Already Going to Zero》，第一反应可能是：又一个大模型公司搞出了什么黑科技？但如果你真花十分钟读完原始那篇长文，会发现它根本不是在讲“Anthropic有多强”，而是在冷静地划一条线——这条线，把整个 AI 工程栈切成了上下两层： 上层是价值可沉淀、可定价、可构建护城河的部分；下层是注定被压缩、被免费化、被云厂商打包进账单的基础设施部分。 我做 AI 基础设施落地项目整整七年，从最早用 Flask + Redis 手搓 agent 调度器，到后来给三家 Fortune 500 企业设计多租户沙箱平台，再到去年带队重构一个日均 27 万 session 的金融客服 agent 系统——我亲眼见过太多团队把全部精力押注在“怎么让 harness 更快”“怎么优化 sandbox 启动时间”上，结果半年后 AWS 一纸公告，AgentCore 直接开箱即用，连 YAML schema 都和他们自研的八九不离十。这不是技术失败，是战略误判。Anthropic 这次发布的 Managed Agents，表面看是“托管型智能体运行时”，实则是把过去三年行业里反复验证过、踩过坑、流过血的工程共识，用一套干净接口、稳定抽象、生产就绪的形态，打包交付。它解决的不是“能不能跑 agent”，而是“能不能在客户生产环境里，连续跑三个月不丢 session、不泄密、不崩 context、不被审计吊销权限”。关键词里那个“Towards AI - Medium”，恰恰点出了这件事的本质：它不是一篇技术白皮书，而是一份面向工程师和架构师的产业观察报告——告诉你哪一层正在变薄，哪一层正在变硬，以及你手里的代码，明年该往哪边挪。

这个判断不是凭空而来。我去年在给某头部券商做 agent 安全加固时，就遇到过几乎一模一样的场景：他们的投研 agent 需要串联 Wind、同花顺、内部财报库、Excel 模板生成器四个工具，一次完整分析平均耗时 38 分钟。系统最初把所有中间状态都塞进 LLM context，结果第 22 分钟左右，context 开始溢出，模型开始“忘记”自己刚调用过哪个 API、返回了什么字段，转而凭空编造一个“看起来合理”的 JSON 结构。更糟的是，因为没做 event log，我们根本没法回溯到底是哪一步出错——只能重启 session，重跑整条链路。客户当时问了一句：“你们说这是智能体，但它连自己干过什么都记不住，这算哪门子智能？”这句话让我连夜推翻了整个 state 管理方案，把 session state 全部迁出 context，改用 durable event log + versioned snapshot 存储。做完之后，不仅故障率归零，还意外收获了一个能力：我们可以把任意历史 session 的完整执行轨迹，以时间线形式还原出来，供合规审计和模型行为分析。这正是 Anthropic 所谓“session as durable event log”的真实价值——它不是炫技，是把“agent 必须可靠”这件事，从一句口号，变成了可验证、可追溯、可审计的工程事实。而这种事实，在金融、医疗、政务等强监管领域，比任何 benchmark 数字都重要。所以当你看到“p50 time-to-first-token down roughly 60%”这类指标时，请别只盯着数字本身。真正该问的是：这个 60%，是靠缩短模型加载时间实现的？还是靠预热 cache？还是靠把 token decode 移到 GPU 上？答案是：都不是。它是靠把 session 初始化、tool discovery、credential binding 这些原本在每次请求里重复做的“冷启动”动作，全部下沉到 harness 层并固化下来，让每一次实际推理请求，只做最核心的“思考-决策-调用”三件事。这才是“decoupled agent stack”的底层逻辑：把变化快的部分（prompt engineering、tool logic）和变化慢的部分（session lifecycle、sandbox provisioning、credential vaulting）彻底剥离开。就像当年 Linux 把硬件驱动抽象成统一的 VFS 接口，从此上层应用再也不用关心硬盘是 SATA 还是 NVMe——开发者终于可以专注写 agent 逻辑，而不是 debug 沙箱网络策略。

2. 核心设计解构：为什么是 YAML + Harness + Sandbox 三件套？

2.1 不是“又一个配置文件”，而是工程契约的具象化

很多人第一眼看到 Anthropic 让你用 YAML 定义 agent，下意识觉得：“哦，又来个配置即代码。”但如果你真去翻过他们公开的 Managed Agents spec （注意，不是营销页，是 spec），会发现这个 YAML 不是简单的 key-value 映射，而是一份 可执行的工程契约 。它强制约定三个不可绕过的维度： system_prompt 、 tools 、 guardrails 。这不是 Anthropic 的任性，而是对过去两年 agent 工程实践的残酷总结。我带团队做过一个保险核保 agent，初期用自然语言描述 agent 行为：“你是一个资深核保员，需根据客户体检报告、既往病史、投保产品条款，判断是否承保及加费比例。”上线三天，客服就收到 17 起投诉：模型把“甲状腺结节 TI-RADS 3 类”错误解读为“恶性肿瘤”，直接拒保。复盘发现，问题不在模型能力，而在 prompt 缺乏结构化约束——没有明确定义“哪些字段必须提取”“哪些医学术语必须查证”“哪些拒保结论需附带法规依据”。Anthropic 的 YAML 强制你把 system_prompt 写成带 schema 的指令块，比如：

system_prompt:
  role: "Underwriter"
  constraints:
    - "Must extract exactly: [age, bmi, systolic_bp, diastolic_bp, fasting_glucose, hba1c]"
    - "Must cross-reference ICD-10 codes from 'past_medical_history' field against latest CIRC guidelines"
  output_format:
    json_schema:
      type: object
      properties:
        decision: {type: string, enum: ["accept", "reject", "refer_to_human"]}
        rationale: {type: string}
        regulatory_reference: {type: string}

看到这里你就明白了：YAML 在这里不是配置，是 防止模型幻觉的第一道闸门 。它把模糊的语义要求，翻译成机器可校验的结构化契约。而 tools 部分更狠——它不接受“随便调个 API”，而是要求你为每个 tool 明确声明 input_schema 和 output_schema 。我们曾对接过一个税务计算 tool，原始 API 文档写得含糊：“传入收入、扣除项，返回应纳税额”。结果模型在测试中传入了字符串 "150000" 而不是数字 150000 ，API 直接 500。现在用 Anthropic 的 schema，你必须写：

tools:
  - name: "calculate_tax"
    description: "Calculate individual income tax based on annual income and deductions"
    input_schema:
      type: object
      required: ["annual_income", "deductions"]
      properties:
        annual_income: {type: number, minimum: 0}
        deductions: {type: number, minimum: 0}
    output_schema:
      type: object
      properties:
        tax_amount: {type: number, minimum: 0}
        tax_bracket: {type: string}

这个 schema 会在 sandbox 启动时被静态校验，任何类型不匹配的输入，在进入 tool 执行前就被拦截。这不是增加开发负担，是把过去靠人工 QA 发现的 80% 的集成错误，提前到部署阶段消灭。至于 guardrails ，它解决的是更隐蔽的“合规性幻觉”。比如金融场景严禁模型给出投资建议，但允许提供“历史数据摘要”。原始做法是靠 prompt 里写“不要给出建议”，效果极差。Anthropic 的 guardrail 允许你定义正则规则、敏感词库、甚至调用外部风控 API 做实时拦截。我们上线前用它堵住了一个致命漏洞：模型在分析某基金年报时，自动补全了“该基金未来三年年化收益预计 12%”，而原文只写了“过去三年年化收益 12%”。Guardrail 通过检测“预计”“将”“未来”等时态词+收益数值组合，触发阻断并返回预设话术。这背后是深刻的工程认知： LLM 的不确定性，不能靠“教育”来消除，必须靠“围栏”来约束。 YAML 就是这道围栏的施工图纸。

2.2 Harness：无状态执行器的真相与陷阱

“Harness as stateless executor” 这句话被很多人轻飘飘读过，但它的重量，只有亲手写过 agent 调度器的人才懂。所谓“stateless”，不是指 harness 什么都不存，而是指它 不存储业务状态，只管理执行状态 。我拆解过市面上 12 个主流 agent 框架的调度器源码，发现一个惊人共性：9 个框架的 harness 实际上是“伪无状态”——它们把 session history、tool call stack、retry count 等关键状态，以 in-memory map 或 local cache 形式存在 harness 进程里。这导致两个灾难性后果：一是水平扩展困难，你无法简单加机器，因为新实例不知道老 session 的进度；二是故障恢复脆弱，harness 进程一崩，整个 session 就永远丢失。Anthropic 的 harness 真正做到了“stateless”，因为它把所有业务状态（session history、tool inputs/outputs、checkpoint data）全部交给外部 durable event log 存储，harness 自身只做三件事： fetch_next_event(sessionId) → execute(tool_name, input) → log_result(sessionId, result) 。这个设计看似简单，实则暗藏玄机。最大的挑战在于 事件顺序一致性 。想象一个 session 同时触发两个 tool call： get_stock_price("AAPL") 和 get_news("AAPL") 。如果 harness 并发执行，返回顺序不确定，event log 里就会出现乱序记录，导致后续 replay 时逻辑错乱。Anthropic 的解法是：harness 在发起 tool call 前，先向 event log 写入一个 TOOL_CALL_QUEUED 事件，包含唯一 request_id；tool 执行完成后，再写入 TOOL_CALL_COMPLETED 事件，并关联该 request_id。event log 服务保证同一 sessionId 下的所有事件按写入顺序严格排序。这相当于把分布式系统里最难的“全局有序”问题，交给了专精于此的 log service（很可能是基于 Raft 或类似协议的 WAL 存储），而非让每个 harness 自己去搞分布式锁或序列号。这种“把难题外包给专业组件”的思路，正是成熟基础设施的标志。但这里有个极易被忽略的陷阱： harness 的“无状态”是建立在 event log 绝对可靠的假设之上的。 如果 event log 出现写入延迟或丢事件，harness 就会卡死或执行错误。我们在压测时就遇到过：当 event log 服务 GC 导致短暂延迟，harness 会不断重试 fetch，最终触发 rate limit，整个 session 流水线停滞。解决方案不是修 harness，而是给 event log 加强监控和熔断——比如当写入延迟超过 200ms，自动降级为本地内存缓存（仅限非关键 session），同时告警。这再次印证一个真理：在复杂系统里，没有真正的“无状态”，只有“状态被托管到了哪里”的选择。

2.3 Sandbox：从“宠物”到“牲畜”的运维哲学革命

“Sandboxes as cattle, not pets” 这句口号背后，是一场静默的运维范式革命。过去我们做 agent 沙箱，习惯把它当“宠物”养：每台 sandbox VM 都有名字（比如 agent-prod-us-east-1-a ），有专属 IP，有手动配置的防火墙规则，有定期登录检查的日志。结果就是：扩容要开单、审批、等资源；故障要登录排查、手动重启；安全审计要逐台检查配置。Anthropic 的 sandbox 是彻头彻尾的“牲畜”：无名、无状态、按需创建、用完即焚。它的实现依赖三个关键技术支柱： 微虚拟化（microVM）、不可变镜像（immutable image）、声明式网络（declarative networking） 。我们对比过 AWS AgentCore 的 microVM 和 Anthropic 的 sandbox 启动流程。AWS 的 microVM 基于 Firecracker，启动约 120ms；Anthropic 宣称 sub-100ms，实际测试在 us-east-1 区域平均 87ms。差距在哪？在于镜像。AWS 允许你挂载 EBS 卷，意味着 sandbox 启动后还要执行 apt update && pip install ；Anthropic 强制使用预构建的、签名的 OCI 镜像，所有依赖（Python 3.11、requests、pydantic、特定版本的 tool SDK）都 baked 进镜像层。这带来两个硬性好处：一是启动快（省去网络拉包和编译时间），二是安全（镜像哈希值可验证，杜绝运行时注入恶意包）。但这也带来一个开发者的痛： 迭代成本变高。 你改一行 tool 代码，就要重新 build、push、sign、deploy 整个镜像。我们团队为此开发了一套“双轨制”工作流：日常开发用轻量级 Docker 容器（模拟 sandbox 行为），确保逻辑正确；CI/CD 流水线里，只有 git tag 打上 v1.2.3 这样的正式版本，才触发 full OCI 镜像构建和签名。这本质上是把“开发敏捷性”和“生产确定性”做了分离。另一个常被忽视的细节是网络。传统 sandbox 往往暴露一个公网 IP 或内网 IP，然后靠 iptables 做端口转发。Anthropic 的 sandbox 网络是完全声明式的：你在 YAML 里写 network_policy: {egress: ["https://api.wind.com", "https://internal-db.company.com"]} ，harness 就只允许 sandbox 访问这两个域名，且自动处理 DNS 解析、TLS 握手、证书验证。这意味着：你不用再担心 agent 调用 curl http://10.0.1.5:8080/hack 这种硬编码地址；也不用为每个 sandbox 单独配安全组；更不用在 agent 代码里写 if os.getenv("ENV") == "prod": ... 这种丑陋分支。网络策略成为 infrastructure-as-code 的一部分，和你的 agent 逻辑解耦。这种解耦的价值，在跨云迁移时体现得淋漓尽致——去年我们帮一家客户把 agent 系统从 Azure 迁到 GCP，只需修改 YAML 里的 network_policy 和 credential_vault_path ，其他代码一行未动。这就是“stable abstraction”的力量：当你把易变的底层细节（云厂商网络模型）封装成稳定的接口（声明式策略），上层应用就能获得真正的可移植性。

3. 实操落地：从 YAML 定义到生产上线的完整闭环

3.1 从零开始：一个真实电商客服 agent 的 YAML 定义与调试

我们以一个真实的电商客服 agent 为例，完整走一遍 Anthropic Managed Agents 的实操流程。这个 agent 需要处理“订单查询”“退货申请”“物流跟踪”三类请求，后端对接公司内部的 Order Service、Return Service、Logistics API。第一步，不是写代码，而是定义 YAML。这里的关键不是“能写出来”，而是“写得足够防错”。我们最初的 draft 是这样的：

# v0.1 - naive version
name: "ecommerce-customer-support"
system_prompt: "You are a helpful customer support agent for Acme Corp. Answer questions about orders, returns, and shipping."
tools:
  - name: "get_order_status"
    description: "Get current status of an order by order ID"
  - name: "initiate_return"
    description: "Start return process for an order"
  - name: "track_shipment"
    description: "Get latest tracking info for a shipment"

上线测试第一天，就暴露出三个致命问题：1）用户说“我上周下的单”，模型无法解析“上周”为具体日期范围；2）退货时用户没提供订单 ID，模型直接调用 initiate_return 传空字符串，API 返回 400；3）物流查询时，用户说“我的快递”，模型不知道是哪个订单，盲目调用 track_shipment 传随机 ID。这些问题的根源，是 YAML 里 system_prompt 太模糊， tools 缺少输入约束。于是我们迭代到 v1.0：

# v1.0 - production-ready
name: "ecommerce-customer-support"
system_prompt:
  role: "Customer Support Agent"
  constraints:
    - "Must ask for order ID if user does not provide it explicitly in first message"
    - "Must parse relative time expressions (e.g., 'yesterday', 'last week') into absolute ISO dates using current date"
    - "Must never call any tool with empty or null parameters"
  output_format:
    json_schema:
      type: object
      properties:
        next_action: {
          type: string,
          enum: ["ask_for_order_id", "parse_time", "call_tool", "answer_directly"]
        }
        tool_call: {
          type: object,
          properties: {
            name: {type: string},
            input: {type: object}
          }
        }
        response: {type: string}
tools:
  - name: "get_order_status"
    description: "Get current status of an order by order ID"
    input_schema:
      type: object
      required: ["order_id"]
      properties:
        order_id: {type: string, minLength: 12, pattern: "^[A-Z]{2}\\d{8}$"}
    output_schema:
      type: object
      properties:
        status: {type: string, enum: ["pending", "shipped", "delivered", "cancelled"]}
        estimated_delivery: {type: string, format: "date"}
  - name: "initiate_return"
    description: "Start return process for an order. Requires order ID and reason."
    input_schema:
      type: object
      required: ["order_id", "reason"]
      properties:
        order_id: {type: string, minLength: 12, pattern: "^[A-Z]{2}\\d{8}$"}
        reason: {type: string, enum: ["defective", "wrong_item", "not_needed"]}
    output_schema:
      type: object
      properties:
        return_id: {type: string}
        return_label_url: {type: string, format: "uri"}
  - name: "track_shipment"
    description: "Get latest tracking info for a shipment by order ID"
    input_schema:
      type: object
      required: ["order_id"]
      properties:
        order_id: {type: string, minLength: 12, pattern: "^[A-Z]{2}\\d{8}$"}
    output_schema:
      type: object
      properties:
        carrier: {type: string}
        tracking_number: {type: string}
        status: {type: string}
        last_update: {type: string, format: "date-time"}
guardrails:
  - type: "sensitive_data_filter"
    patterns: ["credit_card", "ssn", "bank_account"]
  - type: "output_safety"
    blocklist: ["I cannot help with that", "Contact support"]

这个 YAML 的每一个字段，都对应一个血泪教训。 order_id 的正则 ^[A-Z]{2}\d{8}$ 来自我们发现 37% 的用户会输错格式（比如少一位数字），提前校验能避免 90% 的无效 API 调用。 output_schema 里明确 status 枚举值，是为了让前端能根据状态渲染不同 UI（比如 delivered 显示五星好评按钮）。 guardrails 里的 blocklist 是针对客服场景的特殊设计：模型如果回复“I cannot help with that”，会极大降低用户满意度，我们必须强制它要么给出有效信息，要么引导至人工。定义完 YAML，下一步是本地调试。Anthropic 提供 claude-managed-agents-cli 工具，支持离线模拟 harness 行为：

# 模拟一次 session
claude-managed-agents-cli run \
  --config ecommerce-customer-support.yaml \
  --input "My order AC12345678 is delayed. Can you check?" \
  --log-level debug

CLI 会输出完整的 event log 流，包括 SESSION_STARTED 、 TOOL_CALL_QUEUED 、 TOOL_CALL_COMPLETED 、 SESSION_COMPLETED 。我们正是通过这个 log，发现了 get_order_status 返回的 estimated_delivery 字段有时是 null ，而我们的前端代码没做空值处理，导致页面崩溃。于是我们立刻在 output_schema 里加上 nullable: false ，并更新前端。这个过程，把过去需要部署到测试环境、构造测试用例、抓取日志才能发现的问题，压缩到了本地 3 分钟内解决。这就是“可预测性”的价值：YAML 定义 + CLI 模拟，让你在代码写完前，就看清整个执行路径。

3.2 生产部署：凭证隔离、会话持久化与可观测性接入

YAML 定义好，只是万里长征第一步。生产部署的核心挑战是三个： 凭证如何安全注入？会话如何跨天持续？行为如何被监控？ Anthropic 的方案是环环相扣的。凭证隔离采用“vault-first”原则：你不能在 YAML 里写 api_key: xxx ，而是必须指定一个 vault path，比如 credential_vault_path: "secret/ecommerce/order-service/api-key" 。这个 path 对应的是 Anthropic 托管的加密 vault（很可能是基于 HashiCorp Vault 的定制版）。当 sandbox 启动时，harness 会以 sandbox 的唯一身份（由 microVM attestation 证明）向 vault 请求该 path 的 secret，vault 返回解密后的密钥，并 只在 sandbox 的内存中存在，绝不写入磁盘、不暴露为环境变量、不进入任何进程的 /proc/env 。我们做过渗透测试：即使攻破 sandbox 内部，也找不到密钥明文，因为 vault 的响应是 AES-GCM 加密的，密钥材料只存在于 harness 进程的受保护内存页中。这种设计，直接堵死了“LLM 通过 os.environ 泄露密钥”的经典攻击链。会话持久化则依赖 event log 的 durability。Anthropic 的 event log 服务承诺 99.999% 可用性和 13 个月保留期。这意味着，一个用户昨天咨询的订单，今天继续对话，harness 只需 awake(sessionId) 就能从 log 中重建完整上下文。我们实测过：一个持续 47 小时、跨越 3 次网络中断的客服 session，所有中间状态（包括用户上传的 5 张图片的 OCR 文本、3 次 tool call 的返回、2 次人工转接记录）全部完好无损。这背后是 event log 的强一致性设计：每个事件都有全局单调递增的 sequence_id，harness 通过 fetch_events_since(sequence_id) 获取增量，确保不丢不重。最后是可观测性。Anthropic 原生支持 OpenTelemetry，你可以轻松接入自己的 tracing backend（如 Jaeger、Datadog）。但更重要的是，它把 agent 特有的可观测性维度做了标准化： session_id 、 step_number 、 tool_name 、 tool_duration_ms 、 model_latency_ms 、 guardrail_triggered 。我们把这些字段打点到 Datadog，构建了几个关键 dashboard：1）“Top 5 Slowest Tools” —— 发现 track_shipment 平均耗时 2.3s，远超其他工具，推动物流团队优化 API；2）“Guardrail Trigger Rate by Tool” —— 发现 initiate_return 的 sensitive_data_filter 触发率高达 12%，说明大量用户在退货理由里写信用卡号，立即在前端加了输入掩码；3）“Session Abandonment by Step” —— 发现 68% 的用户在“确认退货原因”步骤放弃，于是把单选按钮改成更友好的卡片式选择。这些洞察，都是传统 APM 工具给不了的，因为它们只看到 HTTP 请求，看不到 agent 的决策链条。Anthropic 的可观测性，是把 agent 当作一个有记忆、有决策、有行动的“数字员工”来监控，而不是一堆零散的 API 调用。

3.3 定价模型与成本控制：$0.08/session-hour 的真实含义

看到 $0.08 per session-hour ，很多人的第一反应是“好便宜”。但作为操盘过千万级 agent 月账单的从业者，我必须说：这个定价模型是把双刃剑，用不好反而比自建更贵。关键在于理解“session-hour”到底是什么。它 不是按你启动 sandbox 的时长计费，而是按 session 的“活跃窗口”计费 。什么是活跃窗口？Anthropic 的定义是：从 session 创建（ SESSION_STARTED 事件）开始，到 session 进入“空闲”状态（连续 5 分钟无任何事件）为止。期间无论你调用多少次 tool、生成多少 token、经历多少次网络抖动，都只算这一个窗口的时长。我们做过详细测算：一个典型的电商客服 session，平均交互轮次是 4.2 轮，总耗时 8.7 分钟，其中 6.3 分钟是用户思考时间（空闲）。按 $0.08/hr 算，单 session 成本是 (8.7/60)*0.08 ≈ $0.0116 。但如果 session 设计不合理，比如每次用户提问都新建一个 session（而不是复用），或者 tool call 设计成串行等待（用户问“订单状态”，等返回后再问“物流信息”，而不是并发调用），那么空闲时间会被大幅拉长，成本飙升。我们曾有一个版本，因为前端 bug 导致每次用户点击按钮都触发新 session，单日 session 数暴涨 300%，账单直接翻倍。解决方法是：1）强制前端复用 session_id，除非用户明确说“我要重新开始”；2）在 YAML 里用 concurrent_tools: true 允许 harness 并发调用多个 tool；3）设置 idle_timeout_minutes: 2 （最小值），把空闲窗口从 5 分钟压到 2 分钟。第二个成本陷阱是 token 费用。Managed Agents 的定价是叠加的： $0.08/session-hour + Claude token rates 。很多人只盯着 $0.08，忘了 token 才是大头。一个 claude-3-5-sonnet-20241022 的输入 token 是 $0.003/1K，输出是 $0.015/1K。我们分析过 10 万个生产 session，发现平均每个 session 消耗 12,400 输入 tokens 和 3,800 输出 tokens，token 成本是 (12.4*0.003 + 3.8*0.015) = $0.0942 ，远超 $0.0116 的 session-hour 成本。所以， 优化 token 消耗，比优化 session-hour 更重要 。我们的实战技巧是：1）在 system_prompt 里明确要求模型“用最简短的 JSON 回复，不要解释”；2）对 tool output 做 schema-based truncation，比如 get_order_status 返回 200 行 JSON，但模型只需要 status 和 estimated_delivery 两个字段，就在 harness 层用 Pydantic 模型做自动裁剪；3）启用 Anthropic 的 streaming 模式，让前端边生成边渲染，减少用户等待带来的“重复提问”（用户等不及，又发一遍同样的问题，导致 token 浪费）。经过这三项优化，我们把平均 token 消耗降低了 37%，token 成本从 $0.0942 降到 $0.0593，降幅远超 session-hour 成本的优化空间。这印证了一个朴素真理：在 AI 基础设施里， 最贵的永远是模型推理，其次是数据移动，最后才是计算资源 。Managed Agents 的价值，不在于它多便宜，而在于它把最不可控的“模型推理成本”，和最可控的“基础设施成本”，清晰地剥离开来，让你能精准地优化每一美分。

4. 竞争格局与避坑指南：为什么说 runtime 层正在“归零”

4.1 Hyperscaler 的降维打击：AWS AgentCore 的真实威胁

当媒体还在热议“Anthropic 发布 Managed Agents”，AWS 的 AgentCore 已经悄悄完成了从 GA 到“事实标准”的蜕变。原文提到“AgentCore SDK 下载量超两百万”，这个数字背后是更惊人的事实： 在我们接触的 43 个正在评估 agent 平台的企业客户中，31 个（72%）已将 AgentCore 列为首选，理由清一色是“它已经在我现有的 AWS 账户里，开箱即用，无需额外采购流程” 。这不是技术优劣问题，是采购经济学问题。AWS 的杀手锏从来不是“更快”，而是“更无缝”。AgentCore 的 SDK 可以直接调用你账户里已有的 Lambda、Step Functions、EventBridge，你的 IAM 角色、KMS 密钥、VPC 配置，全部原样复用。我们帮一家银行做 PoC，用 Anthropic Managed Agents 部署一个信贷审批 agent，花了 5 天：要申请新服务配额、配置新的 KMS key、开通新的 CloudWatch Logs 组、学习 Anthropic 的 YAML schema。用 AgentCore，2 小时搞定： aws bedrock-agent create-agent 一条命令，所有资源自动创建，IAM policy 自动生成，连日志组名字都按你账户命名规范来。这种“零摩擦集成”，是任何独立厂商都无法复制的护城河。更致命的是定价策略。AWS 宣布 AgentCore 的 session-hour 费用“计入现有 Compute Savings Plans”，这意味着如果你已经买了 EC2 Savings Plans，AgentCore 的计算费用可能直接归零。我们测算过：一个中等规模客户，月均 50 万 session，用 AgentCore 的综合成本（含 token）比 Anthropic 低 22%，而这 22% 的差价，大部分来自“无需为 runtime 单独付费”。这印证了原文的判断：Anthropic 的 launch 是 defensive 的。它不是在开创一个新市场，而是在阻止自己的核心资产——Claude 模型——被 hyperscaler 的 runtime 层“管道化”。一旦客户习惯了在 AWS 上跑 Claude agent，下次升级模型、调整 prompt、切换工具，都还在 AWS 控制台里完成，Anthropic 就彻底沦为一个“插件供应商”。这就像当年 Oracle 数据库在 AWS RDS 上跑，DBA 的技能树、监控体系、备份策略，全部绑定在 AWS，Oracle 只能卖 license。所以，如果你是 Anthropic 的客户，现在最该做的不是欢呼，而是立刻做三件事：1）把所有 agent 的 YAML schema 导出，和 AgentCore 的 schema 做 diff，标记差异点；2）在 CI/CD 流水线里，加入 AgentCore 兼容性检查（用 aws bedrock-agent validate-agent ）；3）和 AWS SA 约谈，明确 AgentCore 对 Claude 模型的支持路线图。这不是背叛，是生存。runtime 层的 commoditization 不是你愿不愿意的问题，而是它已经在发生的物理事实。

4.2 开源势力的悄然崛起：Daytona 与 Kubernetes SIG 的真实能力

如果说 hyperscaler 是“明牌压制”，开源社区就是“暗流涌动”。原文提到 Daytona 和 Kubernetes SIG 的 agent-sandbox 项目，很多人以为这只是实验室玩具。但我在今年 Q1 的深度评测中发现，它们的能力边界，已经远超想象。Daytona 的核心突破不是“快”，而是“可编程沙箱生命周期”。它允许你用 YAML 定义 sandbox 的整个生命周期钩子：

lifecycle:
  pre_start:
    - command: ["sh", "-c", "echo 'Setting up env...' && export CUSTOM_VAR=prod"]
  post_stop:
    - command: ["python", "/scripts/cleanup.py"]
  health_check:
    exec: ["curl", "-f", "http://localhost:8000/health"]
    initial_delay_seconds: 5
    period_seconds: 10

这个能力，解决了企业级 agent 最头疼的“状态清理”问题。我们有个 agent 需要临时下载大文件（>1GB）做分析，sandbox 停止后，磁盘空间没释放，导致后续 sandbox 启动失败。用 Daytona， post_stop 钩子能确保每次退出前清理 /tmp 。更绝的是，Daytona 的 sandbox 支持“嵌套执行”：一个 sandbox 可以启动另一个 sandbox，形成 agent-in-agent 架构。我们用它实现了“安全审计 agent”：外层 sandbox 运行主 agent，内层 sandbox 运行一个只读的、无网络的审计 agent，专门扫描主 agent 的输出，检查是否包含 PII 信息。这种细粒度的控制，是 Anthropic 和 AWS 都不提供的。而 Kubernetes SIG 的官方 agent-sandbox 项目，则代表了另一种哲学： 把 agent 运行时，变成 Kubernetes 的一等公民 。它不是一个新平台，而是为现有 K8s 集群添加了 AgentPod CRD（Custom Resource Definition）。你只需写一个 YAML：

apiVersion: agent.k8s.io/v1
kind: AgentPod
metadata:
  name: "sales-assistant"
spec:
  model: "anthropic/claude-3-5-sonnet"
  tools:
    - name: "salesforce-api"
      image: "registry.company.com/tools/salesforce:v1.2"
  resources:
    limits:
      memory: "4Gi"
      cpu: "2"

K8s controller 就会自动为你创建 Pod、挂载 secrets、配置 network policy、设置 liveness probe。这意味着，你不需要学 Anthropic 的 YAML，不需要学 AWS 的 CLI，你只要会写 K8s YAML，就能跑 agent。对于已经重度投入 K8s 的企业（据 CNCF 2025 报告，78% 的 Fortune 500 企业已将 K8s 作为核心平台），这几乎是零学习成本的迁移路径。我们