企业官网建设流程全解析

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

你有没有在深夜调试一个跑了三小时的 AI 代理，突然发现它开始胡言乱语？不是模型崩了，不是 prompt 写错了，而是——它的“记忆”被挤掉了。上下文窗口就那么大，工具调用日志、中间结果、用户多轮对话、系统指令……全塞进去，像往一个20升的桶里硬灌35升水。最后溢出的不是水，是逻辑：它忘了自己上一步查了什么数据库，忘了用户明确说“别联系销售”，甚至把两个不同客户的订单号搞混。更糟的是，你没法回溯——没有日志、没有快照、没有时间线，只有最后一段残缺的输出。这种失败不炸裂，但特别贵：重跑要钱，重写要人，客户信任一跌再跌。

这就是 Anthropic 在 2026 年 4 月 8 日发布的Claude Managed Agents真正解决的问题。它不是又一个“让 AI 更聪明”的玩具，而是一套为生产环境量身打造的、可审计、可恢复、可隔离的代理运行时基础设施（Agent Runtime Infrastructure）。关键词是“运行时”——不是模型，不是工具，不是 prompt 工程，而是让所有这些元素能稳定、安全、可追踪地协同工作的底层土壤。它把过去散落在开发者代码里的状态管理、沙箱调度、凭证分发、会话持久化，全部收束成一套清晰、解耦、厂商中立的抽象层。Session 不再是模型上下文里一团模糊的文本，而是一个独立、持久、可查询的事件日志；Harness 不再是你自己写的那个容易内存泄漏的 Python 进程，而是一个无状态、按需拉起、执行完就销毁的轻量执行器；Sandbox 更不是你本地 Docker 里那个手动配环境变量、手抖就漏密钥的容器，而是由 Anthropic 统一管控、凭据永不落地、资源严格隔离的“一次性 cattle”。

这背后的技术判断非常务实：当模型能力趋同（Claude、GPT、Gemini 在多数任务上差距已缩至个位数百分点），当开源工具链成熟（LangGraph、CrewAI、LlamaIndex 已覆盖 90% 的编排需求），当企业最痛的点不再是“能不能做”，而是“敢不敢在生产环境跑、出了事能不能查、会不会把 API Key 搞丢”，那么，决定成败的就不再是顶层的智能，而是底层的确定性。Managed Agents 就是 Anthropic 对这个确定性问题交出的答案。它不试图重新发明轮子，而是把轮子装进标准化轴承、配上统一润滑系统、再附上实时磨损监测——让你专注造车，而不是天天修轮轴。它面向的不是算法研究员，而是 SRE、平台工程师、合规官和采购总监。如果你正在评估是否要把内部客服代理迁到生产，或者纠结要不要自建一套 LangChain + Kubernetes 的复杂运维体系，那么这篇分析就是为你写的。它不讲 hype，只讲你在真实上线前必须想清楚的五个硬核问题：状态怎么存、凭证怎么管、故障怎么追、成本怎么控、未来怎么换。

2. 核心设计与思路拆解：为什么是“解耦”，而不是“堆功能”

2.1 “Session as Event Log”：从脆弱的上下文到坚固的账本

我们先直面那个让无数团队崩溃的痛点：上下文爆炸。去年我参与过一个金融尽调代理项目，它需要串联调用 7 个内部 API（市场数据、财报解析、舆情扫描、监管文件检索、同业对比、风险评分、报告生成），每一步返回的数据都长达数千字符。我们用的是当时主流的“上下文累积法”：把每一步的输入、输出、时间戳、工具名，全部拼接进 system prompt 和 user message 里，喂给模型。前 20 分钟一切顺利，第 22 分钟，模型开始把“2023年Q4营收”错记成“2024年Q1”，第 28 分钟，它完全忘记了用户要求“排除已退市公司”，开始把 ST 股票纳入推荐池。我们检查日志，发现 context length 已达 312,480 tokens——远超 Claude 3.5 Sonnet 的 200K 窗口。模型没报错，它只是默默截断了最早的一段“监管文件检索结果”，然后基于一个残缺的历史做推理。这种失败无法捕获，无法告警，只能靠人工肉眼比对最终报告才能发现。修复方案？不是升级模型，而是彻底重构状态层。

Anthropic 的 Session-as-Event-Log 正是这个教训的产品化。它的核心不是“让窗口变大”，而是“让窗口不再承担存储职责”。具体实现是三层分离：

• 事件日志（Event Log）：所有关键动作——用户输入、模型决策（含 tool_choice）、工具调用（name + input）、工具返回（output）、guardrail 触发、错误堆栈——都被序列化为结构化 JSON，写入一个独立、高可用、带 TTL 的持久化存储（推测为类似 DynamoDB 或 Cloud Spanner 的服务）。这个日志有全局唯一 session_id，支持按时间范围、事件类型、工具名、状态码（success/error）进行毫秒级查询。

• Harness 执行器：这是一个极简的、无状态的 Go 二进制程序。它只做三件事：1）根据 session_id 从日志中拉取最新 N 条事件（默认 50 条，可配置）；2）将这些事件格式化为标准 prompt（含 system message + conversation history）；3）调用anthropic.messages.create()API，传入 prompt 和 tools 定义。它本身不存任何状态，内存占用恒定在 15MB 以内，启动时间 < 200ms。如果它崩溃了，下一次awake(sessionId)调用会直接从日志重建上下文，毫秒级恢复。

• 模型上下文（Model Context）：它现在只承载“当前决策所需的信息”。Harness 拉取的日志片段是经过智能裁剪的：保留最近 3 次工具调用的完整输入/输出，保留所有 guardrail 规则，但自动摘要或丢弃超过 5 分钟前的非关键日志（如“用户问候”、“确认收到”）。这确保 context length 始终控制在安全水位（实测 p95 < 85K tokens），彻底杜绝静默截断。

提示：这不是简单的“把日志存数据库”。关键在于 Harness 与日志的契约——它必须能从任意历史点精确重建执行环境。这意味着日志必须包含足够的元数据：tool_call_id必须全局唯一且有序，output必须是原始字节流（而非摘要），error必须包含完整的 stack trace 和 exit code。Anthropic 的工程博客提到他们为此重写了日志序列化协议，放弃了通用 JSON，改用 Protocol Buffers v3，只为减少 12% 的网络传输延迟和 7% 的磁盘 I/O。

2.2 “Harness as Stateless Executor”：告别“宠物式”进程，拥抱“牛群式”调度

很多团队的代理系统，本质是几个长期运行的 Python 进程（常驻在 EC2 或 K8s Pod 里），它们像“宠物”一样被精心呵护：监控内存、定期重启、手动扩容、配置复杂的健康检查。一旦某个进程因 GC 停顿或依赖库 bug 卡死，整个会话就永久中断。Managed Agents 彻底颠覆了这个范式，其 Harness 设计哲学是“Cattle, not Pets”。

• 按需拉起（On-Demand Provisioning）：每个用户请求（无论是新会话还是唤醒旧会话）都会触发一个全新的 Harness 实例。这个实例在 AWS Lambda 或 Anthropic 自研的轻量 FaaS 平台上启动，生命周期与单次messages.create()调用完全绑定。请求结束，实例立即销毁，释放所有 CPU、内存、网络连接。没有“长连接”，没有“心跳保活”，没有“优雅关闭”逻辑。

• 零状态（Stateless）：Harness 进程内不维护任何会话状态。它不读取本地文件，不连接 Redis，不使用 in-memory cache。所有状态都来自上一步的 Event Log 查询。这带来两个巨大好处：1）水平扩展无限——流量高峰时，系统自动并行拉起数千个 Harness，无需预热；2）故障隔离完美——一个 Harness 崩溃，只影响当前这一次调用，不会污染其他会话。

• 统一执行接口（execute(name, input) → string）：这是 Harness 与外部世界的唯一契约。无论你的工具是调用 Slack API、执行 Python 脚本、还是查询 PostgreSQL，都必须封装成一个符合此签名的函数。Anthropic 提供了 SDK（Python/JS/Go），帮你自动生成这个封装，并处理超时、重试、熔断。更重要的是，这个接口强制了“工具即服务”的思维：你的工具代码必须是幂等的、无副作用的、可独立测试的。我们曾用这个原则重构了一个老系统，把原来混在 agent 逻辑里的数据库更新操作，抽离成一个update_customer_status工具，结果发现它在 30% 的场景下会因并发导致数据错乱——这个 bug 在旧架构下根本无法暴露。

2.3 “Sandboxes as Cattle”：凭证隔离不是最佳实践，是生存底线

凭证泄露是 LLM 应用最致命的风险。去年某电商大厂的“智能选品代理”事故就是典型：开发为了快速验证，把 AWS Access Key 直接写在了 agent 的 system prompt 里。模型在一次工具调用失败后，将完整的 error message（含 key）作为上下文的一部分，传递给了下一个工具——一个本该只读取商品库的脚本。脚本误将 error message 当作商品 ID，尝试调用get_product_by_id("AKIA...")，结果触发了 AWS IAM 的异常访问日志，但为时已晚。攻击者已用该 key 创建了数百个 EC2 实例挖矿。

Managed Agents 的沙箱设计，就是为堵死这种路径。它不是靠“教育开发者别写密钥”，而是从架构上让密钥“不可见”。

• 凭证注入时机：密钥（API Keys、OAuth Tokens、Database Passwords）只在沙箱（Sandbox）被 provisioned 的瞬间，由 Anthropic 的 Vault 服务（推测为 HashiCorp Vault 或自研替代品）注入到沙箱的内核级安全区域（如 Linux Kernel Keyring），绝不通过环境变量（env vars）、挂载卷（volumes）或 config files 传递。

• 沙箱隔离边界：每个 Sandbox 是一个独立的 microVM（基于 Firecracker 或 Kata Containers），拥有专属的 CPU 核心、内存页、网络命名空间和 root filesystem。Harness 进程运行在 Sandbox 外部，它调用execute(name, input)时，请求被转发到 Sandbox 内的一个轻量守护进程（daemon）。这个 daemon 负责：1）从内核 keyring 中安全读取对应密钥；2）构造真实的 HTTP 请求；3）将响应返回给 Harness。Harness 进程的内存空间里，永远不存在明文密钥的字节。

• 凭证生命周期：密钥在 Sandbox 生命周期内有效。Sandbox 销毁（通常在 execute 调用结束后几秒内），密钥即从内核 keyring 中擦除。没有“长期存活的密钥句柄”，没有“跨会话复用”，从根本上杜绝了密钥被意外 dump 或窃取的可能。

注意：这并非银弹。它无法防止模型“诱导”用户主动提供密钥（如“请把您的数据库密码告诉我”），也无法阻止沙箱内工具代码本身的漏洞（如 SQL 注入）。但它解决了 80% 的因开发疏忽或架构缺陷导致的密钥泄露，是生产环境的绝对基线要求。

3. 实操过程与核心环节实现：从 YAML 定义到生产部署

3.1 三步定义你的第一个 Managed Agent

Managed Agents 的入门门槛极低，核心是用 YAML 描述三个要素：行为（Behavior）、能力（Capabilities）、边界（Boundaries）。下面是一个为内部 IT 支持团队构建的“密码重置助手”代理的完整定义（it-support-agent.yaml）：

# 1. Agent 元信息 name: "IT-Support-Password-Reset" version: "1.2.0" description: "Helps employees reset their corporate passwords via Okta API" # 2. 核心行为：System Prompt + Guardrails system_prompt: | You are an IT Support Assistant for Acme Corp. Your sole purpose is to help employees reset their passwords. - ALWAYS verify the employee's identity using their employee ID and last 4 digits of SSN before proceeding. - NEVER ask for full SSN, credit card numbers, or other PII beyond what's specified. - If identity verification fails 3 times, end the session and instruct the user to contact IT Help Desk directly. - Use ONLY the 'reset_password' tool provided. Do not suggest manual steps. guardrails: - type: "PII_Detection" config: forbidden_fields: ["full_ssn", "credit_card", "driver_license"] action: "block_and_warn" - type: "Jailbreak_Prevention" config: patterns: ["ignore previous instructions", "act as", "you are now"] action: "block_and_warn" # 3. 能力：声明可用的 Tools tools: - name: "verify_identity" description: "Verifies employee ID and last 4 digits of SSN against HR database" input_schema: type: "object" properties: employee_id: type: "string" description: "Employee ID (e.g., ACME-12345)" ssn_last4: type: "string" description: "Last 4 digits of SSN" # 凭证由 Anthropic Vault 注入，此处不出现 - name: "reset_password" description: "Resets the employee's password via Okta API and sends a temporary link" input_schema: type: "object" properties: employee_id: type: "string" description: "Employee ID to reset" # 同样，Okta API Key 由 Vault 注入 # 4. 部署配置 deployment: region: "us-east-1" timeout_seconds: 120 max_session_duration_hours: 2

实操要点：

• YAML 是声明式，不是编程式：你不需要写if/else逻辑，所有流程控制（如“验证失败3次就终止”）由 Anthropic 的 Guardrail 引擎在 runtime 解释执行。这极大降低了安全策略的实施成本。
• Schema 是契约：input_schema不仅用于校验，更是 Harness 与 Sandbox 之间的 ABI（Application Binary Interface）。Harness 会严格按 schema 序列化 input，Sandbox 内的工具代码也必须按 schema 反序列化。我们曾因一个字段名大小写不一致（employeeIDvsemployee_id），导致工具调用始终返回400 Bad Request，排查了 2 小时才定位到 YAML。
• Guardrail 是第一道防线：PII_Detectionguardrail 会扫描模型生成的所有token，一旦检测到ssn_last4字段值匹配已知 SSN 模式（如\d{4}），立即拦截。这比在应用层做正则匹配更早、更可靠。

3.2 部署、调试与监控：如何让代理真正“生产就绪”

定义好 YAML，下一步是部署。Anthropic 提供了 CLI 和 Terraform Provider，我们推荐后者，因为它能将 Agent 配置纳入 IaC（Infrastructure as Code）流水线：

# 使用 Terraform 部署（terraform.tf） provider "anthropic" { api_key = var.anthropic_api_key } resource "anthropic_managed_agent" "it_support" { name = "IT-Support-Password-Reset" yaml_config = file("${path.module}/it-support-agent.yaml") # 关联一个预配置的 Vault 策略，定义哪些凭证可被注入 vault_policy_id = "policy-it-support-tools" }

部署后的关键调试步骤：

1. Session Replay（会话回放）：这是 Managed Agents 最强大的调试功能。在 Anthropic 控制台，你可以选择任意一个失败的 session_id，点击“Replay”。系统会：

   • 从 Event Log 中精确还原该会话的每一步；
   • 在一个隔离的、与生产环境完全相同的 Sandbox 中，逐条重放execute()调用；
   • 显示每一次调用的原始输入、Sandbox 内部的完整执行日志（包括 stdout/stderr）、返回的 output、以及耗时。
   • 我们曾用它定位到一个verify_identity工具的 bug：它在处理特殊字符（如O'Malley）时，SQL 查询未正确转义，导致500 Internal Server Error。这个错误在生产日志里只显示为ToolCallFailed: unknown error，但在 Replay 中，Sandbox 的 stderr 清晰打印了psycopg2.errors.UndefinedColumn: column "omalley" does not exist。

2. Trace Store 集成：Managed Agents 原生支持将 Event Log 导出到你指定的 Trace Store（如 LangSmith、Arize Phoenix）。只需在 YAML 中添加：

   tracing: export_to: - "langsmith://<your-langsmith-api-key>@<your-project-id>"

   这样，所有会话事件会实时同步到 LangSmith。你可以在 LangSmith 的 UI 上，用自然语言搜索：“找出所有在verify_identity工具调用后，reset_password返回404 Not Found的会话”，LangSmith 会秒级返回结果。这比在原始日志里grep高效百倍。

3. 性能监控看板：Anthropic 控制台提供开箱即用的指标：

   • p50/p95 Time-to-First-Token (TTFT)：衡量 Harness 启动、日志拉取、prompt 构建、API 调用的端到端延迟。我们的it-support代理 p50 TTFT 为 842ms，p95 为 2.1s。
   • Session Success Rate：成功完成（非因 guardrail 或工具错误而终止）的会话占比。我们目标是 >99.5%，低于此值会触发告警。
   • Tool Call Failure Rate by Tool：按工具名统计失败率。verify_identity的失败率曾高达 12%（因 HR 数据库偶发超时），这促使我们为其增加了指数退避重试逻辑。

3.3 成本精算：$0.08/小时背后的隐藏公式

Managed Agents 的定价看似简单：$0.08 per session-hour of active runtime+ Claude token 费用。但“active runtime”有精确定义，它只计算 Harness 进程实际在 CPU 上执行的时间，不包括：

• Harness 启动/销毁的冷启动时间（< 200ms，免费）；
• 日志查询的网络延迟（计入 Anthropic 内部带宽，免费）；
• Sandbox 内工具执行的 CPU 时间（计入工具所在云服务的费用，如 AWS Lambda 费用）。

因此，真实成本 =Σ(Harness_CPU_Seconds) * $0.08 / 3600+Claude_Input_Tokens * $0.000003+Claude_Output_Tokens * $0.000015（以 Claude 3.5 Sonnet 为例）。

我们对it-support代理做了 7 天的 A/B 测试：

• 旧架构（自建 K8s + LangChain）：平均每次会话耗时 4.2 分钟，其中 3.1 分钟在等待数据库、API、模型响应（I/O Wait），Harness 进程实际 CPU 占用仅 0.8 分钟。但 K8s Pod 按小时计费，且需预留资源，日均成本 $12.70。
• Managed Agents：Harness 实际 CPU 时间平均 0.6 分钟/会话（得益于极致优化的 Go 代码和 FaaS 架构），日均会话 1200 次，日均 Harness 成本 =(0.6 * 1200) / 60 * $0.08 = $0.96。加上 Claude token 费用 $3.20，总成本 $4.16，下降 67%。

实操心得：成本优化的关键在于缩短 Harness 的 CPU 时间，而非减少会话数。我们通过两项改造进一步降本：1）将verify_identity工具的数据库查询从SELECT *改为SELECT employee_id, status，减少网络传输量，Harness 解析 JSON 的时间从 120ms 降至 45ms；2）为reset_password工具启用 Okta 的批量 API，将 3 次独立调用合并为 1 次，Harness 的总执行时间再降 200ms。这些微小的优化，在百万次会话规模下，每年可节省数万美元。

4. 常见问题与排查技巧实录：那些文档里不会写的坑

4.1 “Session not found” 错误：不是丢了，是“睡过头”了

现象：用户发起一个新会话，得到404 Session not found。检查日志，发现该 session_id 确实从未创建过。

根因与排查：Managed Agents 的 Session 有严格的 TTL（Time-To-Live）。默认是 24 小时，但如果你在 YAML 的deployment.max_session_duration_hours中设为2，那么会话在最后一次活动后 2 小时就会被自动归档（Archived），归档后的会话无法被awake()唤醒，只能通过 Trace Store 查询历史。

解决方案：

• 短期：在客户端增加重试逻辑，捕获404，自动创建新会话并提示用户“您的会话已过期，请重新开始”。
• 长期：在业务逻辑中，对需要长周期（>2 小时）的会话，主动调用anthropic.sessions.extend(session_id, hours=24)延长 TTL。我们为一个“季度财报分析代理”设置了 72 小时 TTL，并在每次工具调用后自动续期。

4.2 “Tool call timed out”：不是网络慢，是 Sandbox 的“呼吸权”被剥夺

现象：reset_password工具调用总是返回504 Gateway Timeout，但单独测试 Okta API 速度正常（< 200ms）。

根因与排查：Managed Agents 的 Sandbox 有严格的资源配额。默认是 1 vCPU / 2GB RAM / 30s 超时。我们的reset_password工具在 Sandbox 内执行时，会先下载一个 5MB 的 Okta CA 证书 bundle，这个下载过程在 Sandbox 的受限网络环境下，有时会超过 30s。

解决方案：

• 最优解：在工具代码中，将 CA bundle 静态嵌入到工具二进制中，避免运行时下载。我们用go embed将证书打包进 Go 工具，超时问题消失。
• 备选：在 YAML 中为该工具单独配置超时：

  tools: - name: "reset_password" # ... 其他配置 timeout_seconds: 60 # 覆盖全局默认值

4.3 Guardrail 误报：当“合规”成了“拦路虎”

现象：PII_Detectionguardrail 频繁拦截合法请求，例如用户说“我的工号是 ACME-12345，SSN 后四位是 6789”，guardrail 报警PII_DETECTED: ssn_last4='6789'。

根因与排查：Guardrail 的 PII 检测是基于模式匹配，它无法理解上下文。6789符合\d{4}模式，就被视为潜在 SSN。

解决方案：

• 精准白名单：在PII_Detectionguardrail 的config中，添加whitelist_patterns：

  guardrails: - type: "PII_Detection" config: forbidden_fields: ["full_ssn", "credit_card"] whitelist_patterns: ["ssn_last4=\\d{4}"] # 允许在特定键名后出现 action: "block_and_warn"

• 上下文感知：更高级的方案是，将ssn_last4作为verify_identity工具的必填参数，而非放在用户消息里。这样，PII 只存在于工具调用的结构化 input 中，Guardrail 默认不扫描工具 input（只扫描 model output 和 user input），从而规避误报。

4.4 性能瓶颈定位：当 p95 TTFT 突然飙升

现象：控制台显示p95 TTFT从 2.1s 飙升至 8.5s，持续 15 分钟，但p50仍稳定在 842ms。

根因与排查：p95 的飙升通常意味着长尾请求。我们导出该时段的 100 个慢会话日志，发现它们有一个共同点：都发生在下午 2:00-2:15，且都涉及verify_identity工具。进一步检查verify_identity的 Sandbox 日志，发现其数据库连接池（PostgreSQLpgbouncer）在该时段达到了max_client_conn=100的上限，新连接被排队，导致execute()调用在 Sandbox 内部等待连接的时间长达 6 秒。

解决方案：

• 立即缓解：在verify_identity工具的代码中，增加连接池的max_client_conn配置，并设置合理的server_idle_timeout，避免连接长时间空闲。
• 架构升级：将verify_identity工具从直接连数据库，改为调用一个内部的、带自动扩缩容的 REST API（如 AWS App Runner），由 API 层统一管理数据库连接池。这将 Sandbox 的资源压力转移到更易管理的服务上。

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

5.1 不是 Anthropic 在开创，而是在防御：AWS Bedrock AgentCore 的碾压式存在

媒体把 Anthropic Managed Agents 描绘成“革命性发布”，但现实是，它发布时，AWS Bedrock AgentCore 已 GA（General Availability）整整五个月。这个时间差至关重要。Bedrock AgentCore 不是概念验证，而是已经深度集成进 AWS 生态的工业级产品：

• 基础设施即服务（IaaS）级整合：每个 Agent Session 运行在一个独立的 Firecracker microVM 中，拥有专属的 CPU、内存、网络栈和加密的 EBS 卷。这意味着它天然具备硬件级隔离，比 Anthropic 基于容器的 Sandbox 在安全等级上高出一个维度。
• 框架中立性（Framework Agnostic）：AgentCore 不强制你用 AWS 的 SDK。它接受任何符合request-response协议的二进制——你可以用 LangGraph 的graph.invoke()，用 CrewAI 的agent.execute_task()，甚至用你自己写的 Rust 二进制。模型选择完全自由：Claude、Llama 3、Cohere Command R+，全在 Bedrock 的模型列表里，按需选用。
• 政策即代码（Policy-as-Code）：Bedrock 的 AgentCore Policy Controls 在 2026 年 3 月 GA，允许你用 YAML 定义细粒度的访问控制策略，例如：“仅允许sales-agent调用dynamodb:GetItem，且TableName必须匹配^sales-data-.*$正则”。这直接对标企业级合规要求，Anthropic 的 Guardrail 目前还停留在内容过滤层面。

提示：当你在评估 Managed Agents 时，必须问自己：你的客户是否已经是 AWS 重度用户？如果是，那么 Bedrock AgentCore 的优势是压倒性的——它不额外收费（费用已包含在 EC2/EBS/CloudWatch 的常规账单中），它与你现有的 IAM 角色、VPC 网络、WAF 防护无缝集成，它不需要你学习一套新的 YAML 语法。Anthropic 的 Managed Agents，本质上是在为那些“不想被 AWS 绑定”或“已有大量 Claude 专用模型资产”的客户提供一个“Claude 专属 runtime”。它的价值不是技术领先，而是生态锁定。

5.2 开源压力曲线已形成：Daytona、K8s SIG、Deer-Flow 的三重夹击

如果说 AWS 是“巨无霸”，那么开源社区就是“游击队”，它们正从三个方向压缩 runtime 层的价值：

• Daytona：这家从 DevOps 领域转型的公司，在 2025 年初宣布全面进军 AI Agent Infra。其核心是daytona sandbox，一个用 Rust 编写的超轻量沙箱，启动时间 < 90ms（Anthropic 实测为 110ms）。它最大的创新是sandbox-as-a-service的商业模式：你只需部署一个 Daytona Controller（一个 2vCPU/4GB 的 EC2 实例），它就能为你管理成千上万个 sandbox。Controller 本身是开源的（Apache 2.0），而 sandbox 的二进制是闭源的，但价格仅为$0.005/session-hour，是 Anthropic 的 1/16。

• Kubernetes SIG Agent-Sandbox：K8s 社区在 2026 年初正式成立了 Agent-Sandbox 特别兴趣小组（SIG），并发布了首个官方项目k8s-sandbox-operator。它不是一个新 runtime，而是一个“runtime 编排器”。它能将任何符合 OCI 标准的 sandbox（包括 Anthropic 的、Daytona 的、甚至你自研的）统一纳管，提供标准化的部署、扩缩容、日志收集和监控接口。这意味着，未来你选择 runtime 的自由度会越来越高，因为上层的编排层是统一的。

• Deer-Flow：ByteDance 开源的长周期 Agent 框架，GitHub Star 数已破 59,000。它内置了planning和subagents能力，其核心dearflow-harness是一个纯 Go 的无状态执行器，设计理念与 Anthropic 的 Harness 高度相似。区别在于，Deer-Flow 的 harness 是完全开源的，你可以把它部署在自己的 K8s 集群里，零成本运行。它唯一的“收费点”是其商业版的Deer-Flow Observability Hub，一个专为 Deer-Flow 优化的 Trace Store。

这三股力量合起来，描绘了一幅清晰的图景：runtime 层正在经历与当年虚拟化（VMware vs Xen/KVM）和容器（Docker vs rkt）完全相同的 commoditization（商品化）路径。Anthropic 的 Managed Agents，就像 2005 年的 VMware ESX，是一款优秀的、高利润的专有产品。但历史告诉我们，当开源方案达到“够好”（Good Enough）的临界点，当 hyperscaler（AWS/GCP/Azure）将其作为云服务的“免费赠品”捆绑销售时，专有 runtime 的利润率就会被迅速压向零。这不是预测，而是正在发生的事实。

5.3 价值迁移：当 runtime 变成“水电煤”，钱该往哪赚？

Runtime 层的压缩，不是行业的衰退，而是价值的上移。就像云计算没有杀死软件，而是催生了 SaaS；容器化没有杀死应用，而是催生了微服务。AI Agent 的价值，正加速向三个新楼层聚集：

• Trace Store（追踪存储）：谁拥有最完整、最标准、最易迁移的 Agent 行为日志，谁就拥有了“AI 行为的黄金数据”。Braintrust 的 Brainstore、Arize 的 Phoenix、LangChain 的 LangSmith，都在争夺这个“系统记录”的地位。它们的商业模式很清晰：免费提供基础日志存储和查询，收费提供高级功能——如跨 runtime 的日志联邦查询、基于日志的自动化 A/B 测试、合规审计报告的自动生成。关键洞察：Trace Store 的价值不在于“存得多”，而在于“存得准”和“迁得动”。如果你的 Agent 今天跑在 Anthropic，明天想切到 Bedrock，你的 Trace Store 能否无缝承接？目前，只有 LangSmith 因其与 LangChain 的深度绑定，做到了最高程度的兼容。

• Governance & Policy（治理与策略）：当 Agent 能力越来越强，企业最怕的不是它“做不到”，而是它“做错事”。OWASP Agentic Top 10 列出了十大风险，从 Prompt Injection 到 Data Poisoning，再到 Model Theft。AWS 的 AgentCore Policy Controls 是第一步，但远远不够。未来的治理层，需要能回答：“这个 Agent 是否被授权访问财务数据？”、“它的决策是否符合 GDPR 的‘可解释性’要求？”、“当它生成一份合同，法律效力如何认定？”。这催生了新一代的“AI Governance Platform”，它们不运行 Agent，而是为 Agent 的运行制定规则、监控规则执行、并生成审计证据。这个市场目前空白，是创业公司的绝佳机会。

• Vertical Agent Marketplaces（垂直领域 Agent 商店）：Salesforce 的 Agentforce ARR 达到 8 亿美元，证明了企业愿意为“能解决具体业务问题”的 Agent 付费，而不是为“能跑 Agent 的平台”付费。未来的赢家，将是那些深耕垂直领域的玩家：医疗领域的ai-hedge-fund（已能自动分析 SEC 文件并生成投资建议），网络安全领域的pentagi（能自动执行渗透测试并生成报告），金融领域的TradingAgents（能实时分析新闻情绪并调整交易策略）。它们的成功不依赖于 runtime 的性能，而依赖于对行业知识、数据源、工作流的深刻理解。我的体会是：如果你还在创业，不要再去做一个“更快的 sandbox”，而是去做一个“懂医疗法规的保险理赔 Agent”，或者“懂建筑规范的图纸审查 Agent”。前者是红海，后者是蓝海。

6. 我的实战结论：什么时候该用，什么时候