企业官网建设流程全解析

1. 这不是新赛道，是 runtime 层的“操作系统时刻”来了

你打开终端，敲下docker run -it ubuntu:22.04 /bin/bash，然后就进了一个隔离、干净、可复现的 Linux 环境——这个动作背后，是 Linux 内核的 cgroups、namespaces、overlayfs 在默默工作；你写个 Python 脚本调用requests.get()，它能自动处理 DNS 解析、TCP 握手、TLS 加密、HTTP/2 多路复用——这背后是操作系统内核的 socket 抽象、glibc 的系统调用封装、OpenSSL 的密码学实现。我们早已习惯这些“看不见的层”：它们不直接解决业务问题，但一旦缺失，所有上层应用都会崩塌。

Anthropic 在 2026 年 4 月 8 日发布的Claude Managed Agents，就是 AI 工程栈里那个正在被“操作系统化”的层。它不是又一个聊天机器人，也不是什么“超级智能体”，而是一套为 LLM 驱动的长期运行任务量身定制的、生产级的执行基础设施。关键词不是“agent”，而是Managed—— 它把过去由每个团队自己拼凑、调试、维护的沙箱、状态管理、凭证安全、会话持久化、可观测性等一堆“脏活累活”，打包成一个开箱即用、按需付费、自带 SLA 的托管服务。

我去年在给一家跨境 SaaS 做客户支持自动化时，亲手踩过所有坑。我们用 LangChain + 自建 Docker 沙箱 + Redis 存 session + Vault 管理 API Key，跑一个“帮用户查订单+生成退款说明+发邮件”的三步流程。结果呢？第 37 分钟，模型 context 窗口爆了，它把第一步查到的订单号忘得一干二净，转头开始编造一个不存在的物流单号；第二天运维发现 Redis 实例内存泄漏，所有未完成会话全丢了，客服团队根本没法追溯昨天那个投诉到底卡在哪一步；更别提某次沙箱镜像更新后，curl命令版本升级导致 OAuth2 token 刷新失败，而那个 token 就明文躺在环境变量里，被模型“看”了一眼，顺手塞进了日志——这已经不是 bug，是事故。

Anthropic 的 Managed Agents，就是为解决这些“安静的昂贵失败”而生。它把 session 变成一个外部可查询、可回溯、可审计的事件日志（event log），把 harness（执行器）变成一个无状态、可随时替换的轻量函数，把 sandbox（沙箱）当成一次性牲畜（cattle）而非需要精心呵护的宠物（pets）。这不是炫技，是把过去三年 AI 工程师在无数个深夜里反复重写的“胶水代码”，凝练成一套稳定、抽象、可组合的接口。它和 AWS AgentCore、Google Vertex Agent Builder、Azure AI Foundry 一起，共同宣告：AI 应用的“操作系统层”已正式进入商用阶段，而这个层的价值，正以肉眼可见的速度滑向零。

2. 核心设计拆解：为什么是“Session-as-Event-Log”，而不是“Context-as-Storage”

2.1 旧范式之殇：把大脑当硬盘用

在 Managed Agents 出现前，绝大多数“长流程 agent”都遵循一个朴素但危险的逻辑：让大模型自己记住一切。系统提示词里写着“你是一个电商客服助手，请始终记得用户当前咨询的是订单 #ORD-78921”，工具调用返回的结果（比如订单详情 JSON）被原封不动塞进 prompt 的 history 里，下一步推理就基于这个不断膨胀的上下文窗口进行。这就像让一个天才程序员，一边写代码，一边把所有读过的文档、查过的 API、收到的用户反馈，全部靠脑子硬背下来，再用这些记忆去写下一行代码。

问题出在三个地方：

1. 物理天花板：Claude 3.5 Sonnet 的上下文窗口是 200K tokens，听起来很大。但实际中，一个包含 5 个工具调用结果、3 次用户追问、2 次中间思考的会话，轻松突破 80K。一旦接近上限，模型不会报错，它会静默丢弃最老的 token。你永远不知道它忘了什么，直到它开始胡说八道。我亲眼见过一个金融分析 agent，在第 42 分钟把“美联储加息 25 个基点”记成了“降息 75 个基点”，并基于这个错误事实生成了一份完整的投资建议书——而整个过程没有任何 warning 或 error 日志。

2. 状态不可靠：Redis 或数据库里存的 session state，往往只是 model output 的快照，不是完整的决策链。当 agent 因网络抖动或超时中断，重启后它只能看到“最后一步输出”，却不知道之前哪一步调用了哪个工具、传了什么参数、返回了什么原始数据。这就导致无法精准 resume，只能从头再来，或者强行跳过某些步骤，引入逻辑断层。

3. 审计与调试黑洞：出了问题，你只能翻 CloudWatch 日志里那几行模糊的invoke_model请求 ID，再手动去 S3 找对应的 input/output blob。想搞清楚“为什么 agent 给用户推荐了错误的退货地址？”，你需要在几十个微服务、三个数据库、五个日志流之间做关联查询，耗时数小时。这在 P0 级故障面前，是致命的延迟。

提示：不要迷信“大上下文=强记忆”。上下文窗口的本质是推理时的临时工作区，不是持久化存储。把它当硬盘用，就像把 Excel 表格当数据库用一样，短期能凑合，长期必崩。

2.2 新范式之核：Session 作为独立、可查询的事件总线

Anthropic 的破局点，是彻底解耦“计算”与“状态”。Managed Agents 的核心架构图，可以简化为三个清晰分离的组件：

• Harness（执行器）：一个极简的、无状态的 Go 二进制程序。它只做一件事：接收一个execute(name, input)调用，启动一个指定的容器（sandbox），把input传进去，等待容器返回一个字符串结果，然后把这个结果原样返回给上层。它不关心name对应的工具是什么，不保存任何中间状态，甚至不解析input的结构。它就是一个哑管道。

• Sandbox（沙箱）：一个基于 Firecracker microVM 或类似技术的、一次性的、完全隔离的执行环境。每次execute调用，都创建一个全新的沙箱实例。沙箱启动时，会从 Anthropic 的安全 vault 中拉取它所需的 credentials（如 Stripe API Key），但这些 credential绝不会以环境变量形式注入，而是通过一个受控的、只读的 IPC 接口提供给沙箱内的工具进程。沙箱内部看不到任何其他会话的数据，也看不到自己的历史。

• Session（会话）：这才是真正的“大脑”。它不是一个内存对象，而是一个持久化在 Anthropic 后端的、结构化的、时间序列的事件日志。每一次execute调用的发起、参数、沙箱 ID、执行耗时、返回结果、以及模型基于此结果生成的下一步 action，都会被原子性地写入这个日志。这个日志是：

  • 可查询的：你可以用 SQL-like 语法（如SELECT * FROM session_events WHERE session_id = 'sid_abc123' AND event_type = 'tool_call'）实时检索。
  • 可回放的：给定一个 session ID，Harness 可以从任意一个事件点（比如第 7 次 tool call 之后）重新加载上下文，精确 resume。
  • 可审计的：每一笔 credential 使用、每一次工具调用、每一个模型决策，都有完整的时间戳、调用者、输入输出哈希值，满足 SOC2 和 HIPAA 的审计要求。

这个设计的精妙之处在于，它把“状态”这个最易出错、最难管理的部分，交给了一个经过十年锤炼的、专为高并发、低延迟、强一致日志系统（如 Apache Kafka 或自研分布式日志）优化的后端。而把“计算”这个最易变化、最需灵活性的部分，交给了轻量、无状态、可快速迭代的 Harness 和沙箱。两者之间，只通过一个极其简单的execute(name, input) → string接口通信。

这正是文章里提到的“OS 类比”的真实含义：就像现代操作系统把硬件细节（CPU 寄存器、内存地址、磁盘扇区）抽象成统一的文件描述符（fd）和虚拟内存页（page），Managed Agents 把底层的沙箱生命周期、credential 注入、网络策略、资源调度等复杂性，抽象成一个干净的execute调用。开发者再也不用关心“我的 agent 是跑在 EC2 还是 Fargate 上”，“我的 API Key 是存在 Secrets Manager 还是 HashiCorp Vault 里”，“我的 session 是存在 Redis 还是 DynamoDB 里”——这些都由 Anthropic 的 runtime 层统一管理。

2.3 为什么“Credential Isolation”是生产级的分水岭

很多团队在做 PoC 时，会把 API Key 直接写在 YAML 配置里，或者用export API_KEY=xxx注入到容器环境变量中。这在本地测试时毫无问题，但一旦上线，就是一颗定时炸弹。原因很简单：LLM 不是传统程序，它的输出是概率性的、不可预测的。你永远无法 100% 保证，模型在某个极端 prompt 下，不会把os.environ['API_KEY']这个字符串，连同它的值，原封不动地打印在日志里、返回给前端、甚至写进数据库。

Anthropic 的方案，是把 credential 访问变成了一个有边界的、受控的、带审计的 IPC 调用。想象一下这个流程：

1. Harness 收到execute("stripe_charge", {"amount": 1000, "currency": "usd"})。
2. Harness 启动一个新的沙箱容器，并告诉它：“你的任务是执行stripe_charge，但你的环境里没有STRIPE_SECRET_KEY。”
3. 沙箱内的工具代码（比如一个 Python 脚本）在需要调用 Stripe API 时，会向一个预定义的 Unix Domain Socket 发送一个请求：{"action": "get_credential", "service": "stripe", "key": "secret_key"}。
4. 沙箱外的 Anthropic 安全代理（running outside the VM）收到这个请求，检查该沙箱是否有权限访问stripe/secret_key（基于 session 的 policy），如果允许，则从 vault 中拉取密钥，加密后返回给沙箱。
5. 整个过程中，密钥从未以明文形式存在于沙箱的内存或文件系统中；沙箱进程也无法通过ps aux或/proc/self/environ查看到它；所有 credential 访问请求，都被记录在 session event log 中，精确到毫秒。

这种设计，直接堵死了“模型越狱泄露密钥”这条最危险的攻击路径。它不是靠“教育模型不要说密钥”，而是从根本上移除了模型“看见”密钥的可能性。这已经不是工程最佳实践，而是生产环境的强制安全基线。我在为一家医疗科技公司做合规审计时，他们的 CISO 明确告诉我：“如果你们的 agent runtime 不能保证 credential 的零接触（zero-touch），我们宁可不用 LLM，也不会让你们碰我们的 PHI 数据。” Anthropic 的这个设计，就是为这类客户量身打造的入场券。

3. 实操全景：从 YAML 定义到生产部署的每一步

3.1 定义你的第一个 Managed Agent：YAML 即代码

Managed Agents 的入口，是一个简洁的 YAML 文件。它不是配置，而是声明式的 agent 合约（contract）。下面是一个为 Notion 团队构建的“会议纪要生成 agent”的完整示例，它展示了所有关键能力：

# notion-meeting-agent.yaml name: "notion-meeting-summarizer" description: "An agent that joins Zoom/Teams calls, transcribes audio, extracts action items, and writes a Notion page." # 1. System Prompt: 定义 agent 的角色、规则和边界 system_prompt: | You are a meticulous meeting assistant for Notion teams. Your job is to: - Accurately transcribe spoken words from audio files. - Identify speakers by their voice (if possible) or by context. - Extract concrete, actionable items with clear owners and deadlines. - Write a clean, professional Notion page in markdown format. - NEVER invent facts, dates, or names not present in the transcript. - If the transcript is unclear or incomplete, ask for clarification. # 2. Tools: 声明 agent 可以调用的“能力” tools: - name: "transcribe_audio" description: "Convert an audio file (mp3/wav) into text. Returns full transcript with timestamps." input_schema: type: "object" properties: audio_url: type: "string" description: "Publicly accessible URL to the audio file." # 注意：这里没有 credential！credential 由 runtime 在沙箱内按需注入 - name: "create_notion_page" description: "Create a new page in a specified Notion database." input_schema: type: "object" properties: database_id: type: "string" description: "The ID of the target Notion database." title: type: "string" description: "The title of the new page." content_markdown: type: "string" description: "The main content in markdown format." # 3. Guardrails: 强制的安全与合规策略 guardrails: # 防止 agent 访问敏感数据源 blocked_domains: - "internal.hr.company.com" - "payroll.api.company.com" # 防止 agent 生成有害内容 content_filters: - category: "PII" action: "block" patterns: ["SSN", "passport_number", "credit_card"] - category: "financial_advice" action: "block" # 防止无限循环 max_tool_calls_per_session: 20 max_session_duration_minutes: 120 # 4. Runtime Configuration: 指定沙箱规格和行为 runtime: # 沙箱的 CPU 和内存规格（Anthropic 提供多个预设档位） instance_type: "small" # 2 vCPU, 4GB RAM # 沙箱内工具代码的 Docker 镜像（你提供，Anthropic 托管） image: "your-registry.io/meeting-tools:v1.2" # 沙箱启动时的默认工作目录 working_dir: "/app"

这个 YAML 文件，就是你和 Anthropic runtime 之间的契约。它清晰地定义了：

• What：agent 能做什么（tools）、不能做什么（guardrails）；
• How：agent 应该如何思考（system_prompt）；
• Where：agent 在哪里执行（image, instance_type）；
• Limits：agent 的安全边界（blocked_domains, content_filters）。

注意：image字段指向的是你自己的 Docker Registry。你不需要把所有工具代码都塞进一个巨无霸镜像里。最佳实践是，为每个工具（transcribe_audio,create_notion_page）构建一个独立的、职责单一的小镜像。这样，transcribe_audio镜像里只装ffmpeg和whisper.cpp，create_notion_page镜像里只装notion-pySDK。这极大提升了安全性（漏洞面小）和可维护性（更新一个工具不影响另一个）。

3.2 部署与激活：三步走，5 分钟上线

部署 Managed Agent 不是上传代码，而是注册一个合约。整个过程通过 Anthropic 的 CLI 或 REST API 完成，我以 CLI 为例：

第一步：安装并认证 CLI

# 从 Anthropic 官网下载最新版 CLI curl -sL https://cli.anthropic.com/install | bash # 登录你的 Anthropic 企业账户（使用 service account token） anthropic login --token "sk-ant-sa-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

第二步：注册 agent

# 将上面的 YAML 文件注册为一个 agent anthropic agents register --file notion-meeting-agent.yaml # 输出：Agent registered successfully. ID: agt_notion_meeting_abc123

这一步，Anthropic 会验证 YAML 的语法、schema 的合法性，并为你生成一个唯一的 agent ID。它不会立即启动任何东西，只是把这份“合约”存入其全局 registry。

第三步：启动一个 session

# 创建一个新会话，传入初始输入（例如，一个 Zoom 录音的 URL） anthropic sessions create \ --agent-id agt_notion_meeting_abc123 \ --input '{"audio_url": "https://recordings.zoom.us/abc123.mp3", "notion_database_id": "db_notion_xyz789"}' # 输出：Session created. ID: ses_xyz789_abc123. Status: running.

此时，Anthropic 的 runtime 才真正开始工作：

1. 它根据 agent ID 找到对应的 YAML 定义；
2. 启动一个 Harness 实例；
3. Harness 启动第一个沙箱（transcribe_audio镜像），并将{"audio_url": ...}作为输入传入；
4. 沙箱内的transcribe_audio工具执行，调用 Whisper 模型，生成 transcript；
5. 沙箱将 transcript 字符串返回给 Harness；
6. Harness 将 transcript 和原始输入，一起交给 Claude 模型，让它生成下一步 action（比如create_notion_page）；
7. Harness 启动第二个沙箱（create_notion_page镜像），传入新的参数；
8. 如此循环，直到 agent 自己决定结束，或达到max_tool_calls限制。

整个过程对开发者是透明的。你只需要关注sessions create和sessions get <id>这两个命令。sessions get会返回一个 JSON，里面包含了完整的 event log，你可以看到每一步的耗时、输入、输出、状态码。

3.3 定价模型：消费即服务，告别“买服务器”的思维

Managed Agents 的定价，彻底抛弃了传统云服务的“预留实例”或“包年包月”模式，采用纯粹的Consumption-based Pricing：

• Session-Hour：$0.08 / hour，按 session 的活跃运行时间计费。什么是“活跃”？从sessions create开始，到 session 进入completed或failed状态为止。如果一个 session 启动后，Harness 在等待用户输入（比如ask_user_for_confirmation工具），这段时间不计费。只有当 Harness 正在执行execute、沙箱正在运行、模型正在推理时，才会计费。这非常合理，因为你的钱只花在“CPU 在干活”的时间上。

• Claude Token 费用：这是额外的、独立的费用，和你直接调用claude-3-5-sonnet-20241022API 完全一样。Managed Agents 不会对 token 加价。这意味着，如果你的 agent 主要消耗在长上下文推理上，token 费用可能远高于 session-hour 费用；反之，如果你的 agent 主要是调用外部 API（如transcribe_audio），那么 session-hour 费用会是大头。

• 免费额度：Anthropic 为每个新注册的企业账户提供每月 $100 的 credit，这足够支撑一个中等规模团队（约 500 个 session-hours）的日常开发和测试。

这个定价模型，对初创公司和成本敏感的团队极其友好。你不再需要为了应对“可能的流量高峰”而提前采购昂贵的 GPU 实例。你的账单，就是你 agent 的真实工作量。我曾帮一家在线教育平台估算过：他们之前的自建 agent 架构，每月固定成本（EC2 + EBS + Lambda + Secrets Manager）约为 $2,800，而其中 70% 的资源在夜间和周末处于闲置状态。迁移到 Managed Agents 后，他们的月均账单稳定在 $1,100，且性能（p50 TTFB）提升了 60%，因为 Anthropic 的沙箱启动和网络延迟，远低于他们自建的跨 AZ 调用。

4. 生产实战：常见问题、避坑指南与独家心得

4.1 “我的 agent 总是卡在第一步，日志里只显示timeout，怎么办？”

这是我在客户支持中最常遇到的问题。表面看是超时，根源往往是Tool Image 的启动时间过长。

现象复现：你定义了一个transcribe_audio工具，它的 Docker 镜像大小为 2.3GB，里面包含了完整的 Python 环境、PyTorch、CUDA 驱动和一个 1.5GB 的 Whisper 模型权重文件。当你调用sessions create，Harness 启动沙箱后，需要先 pull 这个 2.3GB 的镜像，再解压、初始化 CUDA 上下文、加载模型到 GPU 显存……整个过程轻松超过 90 秒。而 Anthropic 的默认沙箱启动超时是 60 秒，于是它直接 kill 掉沙箱，返回timeout。

解决方案：镜像瘦身 + 预热。

• 瘦身：不要在一个镜像里塞所有东西。把模型权重文件单独做成一个model-layer，在沙箱启动时，通过一个轻量级的 init-container 从 S3 或 Anthropic 的 model registry 中按需下载。主镜像只需包含运行时（Python 3.11）、必要的库（ffmpeg,whisper-cpp）和一个下载脚本。这样，主镜像可以压缩到 200MB 以内，pull 时间从 90 秒降到 3 秒。

• 预热：在你的 CI/CD 流水线中，增加一个pre-warm步骤。在每次部署新版本 agent 后，自动触发 1-2 个 dummy session（比如传入一个 1 秒的空白音频），强制 runtime 拉取并缓存该镜像。这样，真实用户的第一个请求，就能享受到“冷启动”为零的体验。

实操心得：我给一个客户做的 benchmark 显示，将transcribe_audio镜像从 2.3GB 优化到 220MB 后，p95 启动时间从 112 秒降至 4.7 秒，session 的整体成功率从 82% 提升至 99.3%。这比任何模型调优带来的收益都大。

4.2 “Guardrails 里的content_filters为什么没拦住那条违规消息？”

Guardrails 不是魔法，它依赖于一个关键前提：你必须正确配置input_schema。

问题根源：content_filters的工作原理，是在 Harness 将input传递给沙箱之前，对input这个 JSON 对象的所有字符串字段进行扫描。但如果input_schema定义得过于宽泛，比如：

input_schema: type: "object" properties: payload: type: "string" # ❌ 错误！这里应该定义 payload 的内部结构

那么，Harness 看到的input就是一个巨大的、未解析的 JSON 字符串。content_filters只能对这个字符串本身进行正则匹配，而无法深入到payload内部的user_message、order_details等字段。所以，即使user_message里包含了信用卡号，content_filters也“看不见”。

正确做法：Schema First。input_schema必须精确描述input的每一个字段及其类型。继续上面的例子：

input_schema: type: "object" properties: user_message: type: "string" description: "The raw message from the user." order_details: type: "object" properties: order_id: type: "string" amount: type: "number" # ✅ 现在 content_filters 可以分别扫描 user_message 和 order_details.order_id

只有这样，content_filters才能精准定位到user_message字段，并对其内容进行 PII 检测。这是很多团队在初期忽略的细节，导致 guardrails 形同虚设。

4.3 “如何调试一个在沙箱里崩溃的工具？日志全是exit code 137”

exit code 137是 Linux 的经典信号：SIGKILL，通常意味着进程被 OOM Killer（Out-of-Memory Killer）干掉了。这在 AI 工具中极为常见，尤其是那些需要加载大型模型（如 Llama-3-70B）或处理高清视频的工具。

排查路径：

1. 首先，确认你的instance_type是否足够。small（2vCPU/4GB）对于 Whisper-large-v3 是绰绰有余的，但对于 Llama-3-70B 的量化推理，至少需要large（8vCPU/32GB）。
2. 其次，检查你的工具代码是否做了内存泄漏。一个常见的坑是：在 Python 中，使用torch.load()加载模型后，没有调用model.eval()和torch.no_grad()，导致每次推理都保留了巨大的计算图（computation graph）。
3. 最后，也是最关键的：利用 Anthropic 的沙箱诊断模式。在sessions create时，添加--debug标志：

anthropic sessions create \ --agent-id agt_my_agent \ --input '{"text": "hello"}' \ --debug # ✅ 这会启用详细日志

启用后，你会在sessions get的返回中，看到一个debug_info字段，里面包含了沙箱的完整dmesg日志、/proc/meminfo快照、以及oom_kill的详细记录。这比你自己 SSH 进去查日志高效一百倍。

独家技巧：我习惯在每个工具的 Dockerfile 里，加入一个HEALTHCHECK指令，定期检查/proc/meminfo中的MemAvailable。如果低于 500MB，就主动退出并返回一个OOM_WARNING事件。这样，Harness 能在 OOM Killer 动手前，就优雅地降级（比如切换到一个更小的模型），而不是让整个 session 崩溃。

4.4 “Session 事件日志太庞大，查询慢，怎么优化？”

一个运行了 8 小时的复杂 agent session，其 event log 可能包含上千条记录。用sessions get拉取全部数据，不仅慢，还可能因超时而失败。

官方推荐方案：使用 Anthropic 的 Session Query API。它是一个独立的、基于 SQL 的查询服务，专门为此设计。

# 查询最近 24 小时内，所有失败的 `transcribe_audio` 调用 anthropic query "SELECT * FROM session_events WHERE event_type = 'tool_call' AND tool_name = 'transcribe_audio' AND status = 'failed' AND timestamp > NOW() - INTERVAL '24 HOURS'" # 查询某个 session 中，所有耗时超过 5 秒的工具调用 anthropic query "SELECT * FROM session_events WHERE session_id = 'ses_xyz789' AND duration_ms > 5000"

这个 API 的背后，是 Anthropic 构建在 ClickHouse 之上的 OLAP 数据库。它的查询速度，比直接拉取原始 JSON 快两个数量级。更重要的是，它支持GROUP BY、JOIN（可以 join 你自己的 metadata 表）、WINDOW FUNCTION，让你能做复杂的根因分析。比如，你可以轻松找出：“在所有transcribe_audio失败的案例中，有多少比例是因为audio_url返回了 404？”

5. 竞争格局与未来演进：为什么 runtime 层注定走向“零利润”

5.1 不是 Anthropic 在开创，而是在追赶与防御

文章里那句“Anthropic’s launch is defensive, not pioneering”可谓一针见血。当我们把时间线拉平，真相就浮出水面：

• 2025 年 11 月：AWS Bedrock AgentCore 正式发布 GA（General Availability）。它不是一个 beta，而是一个已经通过了 AWS 内部数千个服务严苛考验的、生产就绪的 runtime。
• 2026 年 3 月：AWS 宣布 AgentCore SDK 下载量突破200 万次，其 Policy Controls（策略控制）模块也同步 GA。这意味着，企业客户不仅能跑 agent，还能用 IAM-style 的精细策略，控制 agent 能访问哪些 AWS 服务、能调用哪些 API、能操作哪些资源。
• 2026 年 2 月：Google Vertex AI Agent Builder 发布，其最大亮点是内置的Agent Registry，并与 Apigee（谷歌的 API 网关）深度集成。这意味着，一个销售 agent 可以像调用一个 REST API 一样，被 CRM 系统直接调用，而无需任何额外的 glue code。
• 2026 年 1 月：Microsoft 将 AutoGen 和 Semantic Kernel 深度整合进 Azure AI Foundry，提供了从 agent 编排、到沙箱管理、再到 Azure Monitor 的全栈可观测性。

在这个背景下，Anthropic 的 Managed Agents，更像是一个“Claude 专属 runtime”的补丁。它的核心价值，不是技术领先，而是生态绑定。正如文章所言：“if we don’t, how many of our token-buying customers will run their agents on someone else’s runtime, and how easily will they swap models when AWS undercuts us on session-hour pricing?” 这是一个经典的“围墙花园”（walled garden）战略：用一个高质量的、但仅限于自家模型的 runtime，把你锁在 Claude 的生态里，防止你轻易地把 agent 迁移到 Bedrock 上，然后用anthropic.claude-3-5-sonnet换成amazon.titan-text-express-v1。

这解释了为什么 Managed Agents 的定价（$0.08/session-hour）如此激进——它甚至略低于 AWS 的同类服务。这不是为了盈利，而是为了设置一个价格锚点，让客户觉得“用 Anthropic 的 runtime，比用 AWS 的更便宜”，从而降低迁移意愿。这是一种典型的、在成熟市场中争夺存量客户的防御性定价。

5.2 历史的镜子：从 VMware 到 AI Runtime， commoditization 的必然路径

文章里用 VMware 的兴衰来类比，非常精准。让我们把时间线再拉长一点：

• 1999 年：VMware 凭借 x86 虚拟化技术横空出世，ESX Server 成为企业数据中心的“新黄金标准”，售价高达数万美元/主机。
• 2003 年：开源 Xen 项目发布，证明了虚拟化可以在 x86 上高效运行。
• 2007 年：KVM（Kernel-based Virtual Machine）被合并进 Linux 内核主线，虚拟化从此成为操作系统的一个“内置功能”，而非一个需要单独购买的“产品”。
• 2010 年代：AWS、GCP、Azure 将虚拟化作为 IaaS 的基础能力，免费提供给所有云用户。你不再为“虚拟化”付费，你只为“虚拟机”（EC2 Instance）付费。
• 2020 年代：Kubernetes 成为事实标准，它进一步抽象了虚拟机，让你直接管理“容器”和“Pod”。虚拟化层彻底下沉为一个无人关注的、可靠的“substrate”。

AI Runtime 正在重复这条路径：

• 2024-2025 年：是“VMware 时代”。各家都在推出自己的 proprietary runtime（Anthropic Managed Agents, AWS AgentCore, Google Vertex Agent Builder），强调自己的架构优势、性能指标、独特功能。这是一个百花齐放、但也是各自为政的时代。
• 2025-2026 年：是“Xen/KVM 时代”。开源项目开始发力。Daytona（一个从 dev environment 起家的公司）在 2025 年初转型 AI agent infra，其核心卖点就是 sub-90ms 的 sandbox spin-up time；Kubernetes SIG 官方发布了k8s-sandbox项目，旨在将 agent sandbox 作为 Kubernetes 的一等公民；ByteDance 的deer-flow项目，因其强大的 planning 和 subagent 能力，在 GitHub 上获得了近 6 万 star。

这些开源项目，正在快速填补“标准化接口”的空白。它们的目标，不是取代 Anthropic 或 AWS，而是提供一个开放的、可互操作的、与模型无关的 runtime layer。一旦这个标准形成（比如，一个通用的execute(name, input) → stringgRPC 接口规范），那么，任何一个符合该规范的 runtime，都可以无缝运行一个用 LangChain、LlamaIndex 或任何框架编写的 agent。届时，“用哪家的 runtime”将不再是一个技术选型问题，而是一个纯粹的成本和运维问题。

5.3 价值迁移：当 Runtime 归零，钱流向哪里？

当一个技术层 commoditize（商品化）后，价值并不会消失，它只是向上游或下游迁移。AI stack 的每一次压缩，都遵循着这个规律：