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

你有没有在深夜调试一个跑了三小时的 AI agent，突然发现它开始胡言乱语，翻看日志却只看到一串被截断的 context？或者更糟——整个 session 像被橡皮擦抹掉一样，连重放都做不到？我去年就栽在这上面：一个负责跨 17 个内部 API 检索合同条款的 agent，在第 42 分钟、第 8 次 tool call 后，context 窗口彻底溢出。模型没报错，只是安静地把前 30 分钟的工具返回结果全“遗忘”了，然后基于残缺记忆编造了一个看似合理、实则完全错误的法律意见。我们花了两天时间手动回溯每一步，最后发现根本没法复现——因为没有事件日志，没有 checkpoint，没有 durable state。那不是 bug，是架构缺陷。

Anthropic 在 4 月 8 日发布的 Claude Managed Agents 公共测试版，表面看是又一个“AI agent 托管平台”，但它的核心价值，恰恰就藏在那个被媒体轻描淡写带过的词里： session-as-event-log 。这不是营销话术，是直击上述所有痛点的工程解法。它把 agent 的“生命史”从易失、受限、不可靠的模型 context 窗口中剥离出来，变成一个独立、持久、可查询、可审计的外部事件流。这个设计，让 agent 从一个依赖“内存”的脆弱进程，变成了一个拥有“硬盘”和“文件系统”的可靠服务。

关键词 Towards AI - Medium 提示我们，这是一篇面向技术决策者、架构师和资深工程师的深度分析，不是给产品经理看的功能清单。它不讲“Claude 多聪明”，而讲“为什么你不能再把 state 塞进 prompt 里”。它不吹“十倍提速”，而拆解“p95 延迟下降 90%”背后是沙箱冷启动优化、凭证隔离机制和 harness 无状态化带来的确定性收益。它不回避竞争——AWS Bedrock AgentCore 已 GA 五个月，Google Vertex AI Agent Builder 和 Microsoft Azure AI Foundry 早已就位。这场发布，本质是一场防御战：当 runtime 层正以肉眼可见的速度滑向“零成本基线”，Anthropic 必须守住自己的 token 生态护城河。它卖的不是 runtime，是让 Claude 模型在复杂、长周期、高可信度任务中持续发挥价值的“运行环境许可证”。如果你正在评估是否要自建 agent infra，或者纠结该选哪家云厂商的托管服务，这篇文章就是你绕不开的底层逻辑说明书。

2. 核心架构拆解：三层解耦，为何是“操作系统级”的抽象？

Anthropic 的工程博客将 Managed Agents 比作 1990 年代操作系统的硬件虚拟化，这个类比精准得令人警醒。它不是说这个产品有多酷，而是指出它解决的是同一类根本性问题： 如何将上层应用（agent）与下层资源（计算、存储、安全）的耦合降到最低，从而让每一层都能独立演进、互不掣肘 。这种解耦不是修修补补，而是从底座开始的重构。我们来一层层剥开它的设计哲学。

2.1 Session：从“上下文快照”到“持久化事件日志”

传统 agent 架构里，“session” 是一个模糊概念。它可能是一段存在 Redis 里的 JSON，可能是一次 HTTP 请求的生命周期，也可能干脆就是模型输入 prompt 里那几千 token 的历史对话。这种设计在简单问答场景下尚可，一旦进入多步骤、多工具、长时间的任务链，立刻崩塌。原因有三：第一，context 窗口是硬性上限，超出即丢弃；第二，prompt 中的历史是“只读快照”，无法做原子性更新或回滚；第三，没有结构化元数据，无法回答“这个 session 里调用了几次数据库？哪次失败了？谁授权的？”这类问题。

Managed Agents 彻底颠覆了这一点。 Session 不再是模型的附属品，而是一个独立的、由 Anthropic 托管的、具备完整生命周期的实体 。它的核心特征是：

• 事件驱动（Event-Driven） ：每一次 tool call 的发起、执行、返回、失败，每一次用户输入、系统响应，都被记录为一条结构化的事件（event）。这些事件按时间戳严格排序，形成一个不可篡改的、线性的事件流（event log）。这不再是“快照”，而是“录像带”。

• 持久化（Durable） ：这个事件日志存储在 Anthropic 的后端服务中，与模型推理完全分离。即使 harness 进程崩溃、网络中断、甚至整个沙箱被销毁，事件日志毫发无损。你可以随时 awake(sessionId) ，让一个新的 harness 实例从事件流的任意位置（比如最后一次成功的 tool call 之后）恢复执行。这解决了我去年那个“42 分钟后崩溃”的噩梦——现在，崩溃不是终点，只是暂停键。

• 可查询（Queryable） ：事件日志不是黑盒。Anthropic 提供了 API 和控制台界面，让你能像查询数据库一样检索：“过去 24 小时内，所有调用过 get_customer_data 工具且返回状态码为 404 的 session”；或者“列出某个 session 中所有涉及敏感 PII 字段的 tool call 输入”。这直接支撑了合规审计、故障排查和行为分析。

提示：这个设计的价值，在于它把“agent 的行为”从“模型的幻觉”中剥离出来。模型可以出错，但它的每一次出错，都会被忠实记录。这为构建可信 AI 系统提供了最基础的事实依据。

2.2 Harness：无状态的“执行引擎”，而非有状态的“大脑”

如果说 Session 是 agent 的“记忆”和“历史”，那么 Harness 就是它的“肌肉”和“手脚”。在 Managed Agents 架构中，Harness 被刻意设计成 完全无状态（stateless） 。它的唯一职责，就是接收一个指令（ execute(name, input) ），在一个隔离的沙箱中执行它，并将字符串形式的结果（ string ）返回给 Session 层。

这个设计带来了三个关键优势：

• 极致的可伸缩性（Scalability） ：无状态意味着 Harness 实例可以像牲畜（cattle）一样被随意创建、销毁、替换。当流量激增时，Anthropic 可以瞬间拉起数百个新的 Harness 实例；当流量回落，又能优雅地回收。这与传统有状态服务（pets）需要精心呵护、备份、主从切换的运维模式截然不同。

• 强健的容错性（Resilience） ：Harness 崩溃了？没关系。Session 层会检测到超时或失败，然后自动调度一个新的 Harness 实例，传入相同的 sessionId 和待执行的 name/input ，继续工作。用户感知不到任何中断，就像你的浏览器标签页崩溃后，你刷新一下就能回到之前的状态。

• 清晰的责任边界（Clear Boundaries） ：Harness 不关心“这是第几步”、“用户之前问了什么”、“这个工具调用是否符合公司政策”。它只做一件事：执行。所有的业务逻辑、状态管理、策略判断，都下沉到 Session 层或上层的 policy engine。这种清晰的分层，让系统更容易理解、测试和维护。

注意： execute(name, input) → string 这个接口看似简单，却是整个架构的“契约”。它强制要求所有工具必须被封装成符合此规范的函数。这意味着你需要将你的数据库连接、API 客户端、文件读写等能力，全部包装成一个个独立的、可注册的“tool”。这初期会增加一点开发量，但换来的是未来无限的灵活性——你可以随时替换某个 tool 的实现（比如把本地 MySQL 换成云端 Aurora），而无需改动 Harness 或 Session 的任何一行代码。

2.3 Sandbox：一次性的“洁净室”，而非共享的“办公桌”

沙箱（Sandbox）是 Managed Agents 安全模型的基石。它不是一个简单的容器，而是一个 按需创建、严格隔离、一次性使用 的执行环境。其设计理念是“cattle, not pets”，即把它当作消耗品，而不是需要长期维护的资产。

• 按需创建（On-Demand Provisioning） ：每个 tool call 都会触发一个全新的沙箱实例。这个沙箱从一个干净的、预定义的镜像启动，里面只包含运行该 tool 所必需的二进制文件、库和配置。执行完毕，沙箱立即被销毁。这从根本上杜绝了“一个恶意 tool 污染整个运行环境”的风险。

• 严格隔离（Strict Isolation） ：每个沙箱拥有自己独立的 CPU 时间片、内存空间、网络命名空间和文件系统。它无法访问其他沙箱的进程、内存或磁盘。更重要的是， 凭证（credentials）永远不会以环境变量（env var）的形式注入沙箱 。这是 Anthropic 从血泪教训中总结出的关键点。想象一下，一个本应只读取 S3 的 tool，如果通过 AWS_ACCESS_KEY_ID 环境变量拿到了一个高权限密钥，它就可能转头去删除整个 bucket。Managed Agents 的做法是：凭证存放在 Anthropic 的安全 Vault 中，当沙箱需要调用某个 tool 时，Harness 会向 Vault 申请一个临时的、作用域极窄的短期令牌（short-lived, scoped token），并将其作为参数传递给沙箱内的 tool 进程。沙箱本身永远不知道原始密钥是什么。

• 一次性的（Ephemeral） ：沙箱的生命周期与单次 tool call 绑定。它不会被复用。这确保了每次执行都是在完全一致、可预测的环境中进行，消除了因缓存、残留状态或未清理的临时文件导致的“幽灵 bug”。

这个沙箱模型，直接对应了现代云原生架构中的“微服务”和“Serverless”思想。它牺牲了一点冷启动的毫秒级延迟（但 Anthropic 通过预热池等技术已将此优化到亚秒级），换来了无与伦比的安全性、确定性和可审计性。对于处理金融、医疗等敏感数据的 agent 来说，这不是可选项，而是必选项。

3. 实操落地：从 YAML 定义到生产部署，一个真实案例

理论再好，也要落到键盘上。下面，我将以一个真实的、已在 Notion 内部上线的“会议纪要生成 agent”为例，手把手带你走一遍 Managed Agents 的完整实操流程。这个 agent 的需求很明确：用户在 Notion 页面中选中一段会议录音的链接（通常是 Zoom 或 Teams 的云存储 URL），点击“生成纪要”按钮，agent 就能自动下载音频、转录、提炼要点、生成待办事项，并将结果格式化后插入到当前页面。

3.1 第一步：用 YAML 定义你的 Agent（系统提示、工具、守卫）

Managed Agents 允许你用自然语言或 YAML 来定义 agent。对于生产环境，我强烈推荐 YAML，因为它结构清晰、易于版本控制、方便 CI/CD 流水线集成。以下是我们这个会议纪要 agent 的核心定义（ meeting-minutes-agent.yaml ）：

# agent.yaml
name: "Notion-Meeting-Minutes"
description: "An agent that generates meeting minutes from audio recordings stored in cloud storage."

# 系统提示（System Prompt）：告诉 Claude 它是谁、要做什么、遵循什么规则
system_prompt: |
  You are a professional meeting minute generator for Notion.
  Your task is to:
  1. Download the audio file from the provided URL (must be from zoom.us or teams.microsoft.com).
  2. Transcribe the audio into text using the `transcribe_audio` tool.
  3. Analyze the transcript to extract: key decisions, action items (with owner and due date), and discussion topics.
  4. Format the output as clean, markdown-compatible text suitable for Notion.
  5. NEVER hallucinate details not present in the transcript. If information is missing, state "Not specified".
  6. ALWAYS use the `format_for_notion` tool to structure your final output.

# 定义可用的工具（Tools）
tools:
  - name: "download_audio"
    description: "Downloads an audio file from a public URL. Returns the local file path."
    input_schema:
      type: "object"
      properties:
        url:
          type: "string"
          description: "The public URL of the audio file (e.g., https://zoom.us/rec/...)."
      required: ["url"]

  - name: "transcribe_audio"
    description: "Transcribes an audio file at the given local path into text."
    input_schema:
      type: "object"
      properties:
        file_path:
          type: "string"
          description: "The local path to the downloaded audio file."
      required: ["file_path"]

  - name: "format_for_notion"
    description: "Formats the extracted meeting content into Notion-friendly markdown."
    input_schema:
      type: "object"
      properties:
        decisions:
          type: "array"
          items:
            type: "string"
        action_items:
          type: "array"
          items:
            type: "object"
            properties:
              owner: { type: "string" }
              due_date: { type: "string" }
              description: { type: "string" }
        topics:
          type: "array"
          items: { type: "string" }
      required: ["decisions", "action_items", "topics"]

# 守卫（Guardrails）：定义安全和合规规则
guardrails:
  # 防止访问非白名单域名
  allowed_domains:
    - "zoom.us"
    - "teams.microsoft.com"
    - "notion.so"

  # 防止工具滥用
  tool_call_limits:
    download_audio: 1
    transcribe_audio: 1
    format_for_notion: 1

  # 敏感信息过滤（内置）
  pii_filtering: true

这个 YAML 文件定义了 agent 的全部“灵魂”：它的身份（ system_prompt ）、能力（ tools ）和底线（ guardrails ）。注意几个关键点：

• system_prompt 的精确性 ：它没有泛泛而谈“你很聪明”，而是给出了极其具体的、分步骤的操作指南（1. 下载 2. 转录 3. 提炼 4. 格式化），并设定了严格的约束（“NEVER hallucinate”, “ALWAYS use format_for_notion ”）。这直接决定了 agent 的行为边界。
• tools 的输入 Schema ：每个 tool 都有严格的 JSON Schema 定义。这不仅是给模型看的，更是给 Anthropic 的 runtime 看的。它确保了模型生成的 tool call 参数，一定能被后端的 tool handler 正确解析和执行。避免了“模型说要下载 https://evil.com/malware.exe ，而 handler 却傻乎乎地去执行”的灾难。
• guardrails 的实战性 ： allowed_domains 是一道硬防火墙，任何不在白名单里的 URL， download_audio 工具根本不会被允许调用。 tool_call_limits 防止 agent 在一个 session 里陷入无限循环（比如反复调用 download_audio ）。 pii_filtering: true 则启用了 Anthropic 内置的 PII（个人身份信息）识别和脱敏功能，自动屏蔽掉 transcript 中的电话号码、邮箱、身份证号等。

3.2 第二步：部署与配置——不是上传，而是“注册”

在传统方式中，你可能需要打包一个 Docker 镜像，推送到仓库，再在 Kubernetes 上部署。Managed Agents 的流程简洁得多： 你只需要将这个 YAML 文件注册（register）到 Anthropic 的平台 。

1. 获取 API Key ：在 Anthropic 控制台创建一个项目，生成一个具有 agents:write 权限的 API Key。

2. 调用注册 API ：

   curl -X POST https://api.anthropic.com/v1/agents \
     -H "x-api-key: $ANTHROPIC_API_KEY" \
     -H "anthropic-version: 2023-06-01" \
     -H "Content-Type: application/json" \
     -d '{
           "name": "Notion-Meeting-Minutes",
           "config": {
             "type": "yaml",
             "content": "...内容是上面那个YAML文件的完整字符串..."
           }
         }'
   

   这个 API 调用会返回一个唯一的 agent_id ，比如 agent_abc123 。这就是你的 agent 在 Anthropic 世界里的“身份证”。

3. 配置凭证（Credentials） ：这是最关键的一步，也是体现其安全设计的地方。你不需要把你的 AWS 密钥、Zoom API Token 等敏感信息写进 YAML 或暴露给前端。你只需在 Anthropic 控制台的“Credentials Vault”中，为每个 tool 创建对应的凭证：

   • 为 download_audio 创建一个名为 zoom_read_only_token 的凭证，类型为 OAuth2 ，填入你的 Zoom App 的 Client ID 和 Secret。
   • 为 transcribe_audio 创建一个名为 whisper_api_key 的凭证，类型为 API Key ，填入你的 Whisper 服务密钥。
   • 这些凭证会被安全地存储在 Vault 中，只有当 Harness 需要执行某个特定 tool 时，才会动态地、临时地、以最小权限原则发放给沙箱。

3.3 第三步：启动 Session 与执行——一次“唤醒”之旅

现在，agent 已经注册好了。当 Notion 用户点击“生成纪要”时，前端会调用你的后端服务，后端服务再调用 Anthropic 的 API 来启动一个 session。

# Python 伪代码
import requests

def start_meeting_minutes_session(audio_url):
    # 1. 创建一个新的 Session
    response = requests.post(
        "https://api.anthropic.com/v1/sessions",
        headers={
            "x-api-key": ANTHROPIC_API_KEY,
            "anthropic-version": "2023-06-01"
        },
        json={
            "agent_id": "agent_abc123",  # 你注册的 agent ID
            "initial_input": {
                "url": audio_url  # 用户提供的 Zoom/Teams 链接
            }
        }
    )
    session_id = response.json()["id"]  # 得到 session_id，如 "sess_def456"

    # 2. 开始执行（唤醒）
    # 这会触发 Harness 启动，加载 agent config，执行 system_prompt，并开始处理 initial_input
    response = requests.post(
        f"https://api.anthropic.com/v1/sessions/{session_id}/awake",
        headers={...}
    )

    # 3. 轮询结果（或使用 Webhook）
    while True:
        status = requests.get(f"https://api.anthropic.com/v1/sessions/{session_id}", headers={...})
        if status.json()["status"] == "completed":
            return status.json()["output"]
        time.sleep(1)

这个过程的核心在于 awake(sessionId) 。它不是一个简单的“开始”命令，而是一个 状态机的触发器 。Harness 会根据 session 的事件日志，找到当前应该执行的下一步（比如，第一步是调用 download_audio ），然后创建一个沙箱，注入 zoom_read_only_token 凭证，执行下载。下载完成后，事件日志会新增一条 download_audio_success 事件，Harness 再根据新的日志状态，决定下一步是调用 transcribe_audio ，依此类推。

实操心得：在实际部署中，我们发现 awake() 的轮询模式在长任务（如转录一小时音频）中并不理想。我们最终采用了 Anthropic 的 Webhook 功能。我们在注册 agent 时指定了一个回调 URL（例如 https://yourapp.com/webhook/anthropic ）。每当 session 状态发生变化（started, tool_call, completed, failed），Anthropic 都会向这个 URL 发送一个 POST 请求，携带完整的事件详情。我们的后端收到后，可以立即更新 Notion 页面的状态（“正在转录…” -> “正在提炼要点…”），用户体验流畅得多。这是官方文档里一笔带过，但生产环境必备的技巧。

4. 竞争格局与价值迁移：为什么 runtime 层注定走向“零价”？

Anthropic 的 Managed Agents 发布，被很多媒体描绘成一场“开创性革命”。但如果你拉远镜头，把它放在整个 AI Infra 的演进长河中审视，就会发现一个更冷静、也更残酷的真相： 它不是在开辟新大陆，而是在一片早已硝烟弥漫的战场上，加固自己的滩头阵地 。这片战场，就是“agent runtime”层。而它的命运，已经被历史反复验证——终将 commoditize（商品化），价格趋近于零。

4.1 四大巨头已就位：这不是蓝海，是红海

Anthropic 的公告稿里，对竞争对手只字未提。但现实是，就在它发布前五个月， Amazon Bedrock AgentCore 已正式进入通用可用（GA）阶段 。截至 2026 年 3 月，其 SDK 下载量已突破两百万次。它的架构同样惊艳：每个 session 运行在独立的 microVM（微型虚拟机）中，拥有专属的 CPU、内存和文件系统，隔离级别远超普通容器。Session 最长可运行八小时，且完全框架无关——LangGraph、CrewAI、Strands，只要你能把它编译成 request-response 的循环，AgentCore 就能托管它。最关键的是，它已经深度集成进了 AWS 的计费体系。对于一个已经在 AWS 上花费数百万美元的企业客户来说，为 agent runtime 多付一笔钱，远不如直接把这笔预算算进 EC2 或 Lambda 的账单里来得方便。

与此同时， Google Vertex AI Agent Builder 和 Microsoft Azure AI Foundry 也早已亮剑。Vertex 的方案主打“Agent Registry”，通过 Apigee（谷歌的 API 网关）进行统一的流量管理和策略控制。Azure 则选择了一条更激进的路径：它没有从零开始造轮子，而是直接将开源生态的两大巨头——AutoGen 和 Semantic Kernel——深度整合进自己的 AI Foundry 平台。这意味着，一个已经在用 AutoGen 构建 agent 的微软客户，几乎可以零成本地将现有代码迁移到 Azure 的托管环境。

这张“四巨头”地图清晰地表明： runtime 层的基础设施战争，已经结束了第一阶段。胜者不是技术最炫的那个，而是生态最广、集成最深、计费最顺的那个 。Anthropic 的 Managed Agents，本质上是一场“防御性创新”。它的核心问题不是“我们能不能做”，而是“如果我们不做，我们的客户会不会明天就用 AWS 的 AgentCore 来跑他们的 Claude agent，然后后天就因为 AWS 的价格更优，而把模型也换成 Titan？” 这就是为什么它的定价（$0.08/小时）如此克制——它不是为了盈利，而是为了筑起一道价格护城河，让客户没有强烈的经济动机去迁移。

4.2 价值迁移的三大高地：当 runtime 变成“水电煤”，钱流向哪里？

当一个技术层 commoditize，它的价值并不会消失，而是会向上游或下游迁移。就像当年虚拟化技术（VMware）的商品化，并没有杀死云计算，反而催生了 Kubernetes、Terraform 和 SaaS 应用。AI agent runtime 的 commoditization，正在将价值清晰地导向三个新的高地：

4.2.1 高地一：Trace Store（追踪存储）——Agent 的“黑匣子”与“司法证据”

当 runtime 变得廉价、易得、可替换，最大的不确定性就变成了： 我的 agent 到底做了什么？ 这不再是一个技术问题，而是一个商业、合规甚至法律问题。一个销售 agent 在 Slack 里向客户承诺了某项服务，这个承诺是否被准确记录？一个财务 agent 自动审批了一笔大额付款，它的决策依据是什么？当发生纠纷时，谁能提供一份不可篡改的、权威的“行为日志”？

这就是 Trace Store 的价值所在。它不再是一个简单的日志聚合器，而是一个专为 AI 交互设计的、具备 OLAP（在线分析处理）能力的数据库。目前，三家公司在激烈角逐：

• Braintrust ：背靠 $36M 的 A 轮融资，其 Brainstore 数据库专为 AI 事件日志优化，支持毫秒级的复杂关联查询（例如：“找出所有在 approve_payment 工具调用中， amount > 100000 且 approver_role = 'CFO' 的 session”）。
• Arize ：已累计融资 $131M，其开源项目 Phoenix（Apache 2.0 许可）已成为事实上的社区标准。它提供强大的可视化分析能力，能直观地展示 agent 的“决策路径图”，帮助你一眼看出哪个环节的失败率最高。
• LangSmith ：作为 LangChain 生态的“亲儿子”，它最大的优势是“默认安装”。任何一个使用 LangChain 的开发者，只要 pip install langchain , 就自动拥有了 LangSmith 的基础追踪能力。它的护城河，是庞大的、已经存在的用户基数。

常见问题速查表：为什么不能用 Elasticsearch 或 Datadog？

问题	Elasticsearch/Datadog	Trace Store (e.g., LangSmith)
数据模型	通用日志，schema-less	专为 AI 设计，预定义 session_id , trace_id , tool_name , input , output , latency , error 等字段
关联分析	需要复杂的 join 和 script 查询	原生支持 session -> span -> event 的树状层级关系，一键展开整个决策链
成本	存储海量原始日志，成本高昂	支持智能采样、压缩和 schema 优化，存储成本降低 50%+
合规性	需自行配置 PII 过滤、加密	内置 PII 识别、GDPR/CCPA 合规模板、审计日志

4.2.2 高地二：Governance & Policy（治理与策略）——Agent 的“交通法规”

当 agent 能够自主调用 API、修改数据库、甚至生成代码，一个朴素的问题就浮出水面： 它被允许做什么？谁批准了它这么做？ 这不再是开发者的个人偏好，而是企业级的治理挑战。OWASP（开放式Web应用程序安全项目）在 2026 年初发布的《Agentic Top 10》安全风险榜单，将“不充分的策略执行”列为头号风险。这直接推动了企业采购部门开始提出标准化问题：“你们的 agent 平台，如何定义和执行访问控制策略？”

AWS AgentCore 在 2026 年 3 月 GA 的“Policy Controls”，正是对这一需求的回应。它允许管理员通过 IAM 策略，精细地控制一个 agent session 能调用哪些 AWS 服务、能访问哪些 S3 bucket、能执行哪些 DynamoDB 操作。这不再是代码里的 if/else ，而是云平台级别的、可审计的、可继承的策略。

这个领域目前还是“蓝海中的蓝海”。没有一家公司能宣称自己是“Agent Governance”的绝对领导者。它需要与企业的现有 IAM、SIEM（安全信息与事件管理）系统深度集成，需要理解垂直行业的合规要求（如 HIPAA 对医疗数据的限制，FINRA 对金融交易的留痕要求）。谁能率先提供一套开箱即用、符合主流合规框架的策略模板库，并能无缝对接企业现有的 ITSM（IT 服务管理）流程，谁就能在这个价值洼地中占据先机。

4.2.3 高地三：Vertical Agent Marketplaces（垂直领域 Agent 商店）——Agent 的“App Store”

当 runtime 和基础工具链都变得免费、易用，最终的竞争，必然回归到“ 谁的 agent 能解决我最痛的业务问题？ ” 这就是垂直市场（Vertical Market）的力量。Salesforce 的 Agentforce 在 2026 年 Q4 达到了 8 亿美元的 ARR（年度经常性收入），同比增长 169%，这绝非偶然。它成功的关键，在于它卖的不是一个“AI agent 平台”，而是一个个能直接嵌入销售流程的、开箱即用的“agent 应用”： Lead-Scorer （线索评分）、 Deal-Coach （交易教练）、 Contract-Analyzer （合同分析）。客户采购经理看到的，不是技术参数，而是一份清晰的 ROI（投资回报率）报告：部署 Deal-Coach 后，销售周期平均缩短了 17%，赢单率提升了 22%。

开源社区已经敏锐地捕捉到了这一趋势。在 GitHub 上， virattt/ai-hedge-fund 项目为量化交易员提供了完整的、可复现的 AI 投资组合 agent； vxcontrol/pentagi 则为网络安全团队打造了一个能自动执行渗透测试、生成报告的 offensive security agent。这些项目之所以能快速获得数万 star，是因为它们精准地切中了某个专业领域的“最后一公里”——它们不是在教你怎么搭一个 agent，而是在告诉你：“用这个，你就能立刻解决你每天都在面对的那个具体问题。”

实操心得：我在为客户设计 agent 解决方案时，越来越倾向于采用“垂直优先”策略。与其花三个月时间，从零开始构建一个通用的“客户服务 agent”，不如直接寻找一个成熟的、针对电商客服场景的开源 agent（比如 ecommerce-customer-support-agent ），然后用 2 周时间，将其与客户的 Shopify API 和 Zendesk 系统集成。前者听起来更“高大上”，后者却能在 3 周内就产生可衡量的业务价值（比如将首次响应时间从 2 小时缩短到 2 分钟）。价值，永远来自于解决具体问题，而不是堆砌技术。

5. 未来已来：当 agent 开始自我进化，runtime 层的终极形态是什么？

文章开头提到的那个“42 分钟后崩溃”的 agent，其根源在于它是一个静态的、被动的工具。它被人类编写，被人类部署，被人类监控。而真正的范式转移，正在悄然发生： agent 正在获得自我改进、自我演化的能力 。这不再是科幻小说的情节，而是已经发表在顶级学术期刊上的、经过同行评审的严肃研究。

2026 年 3 月，Sakana AI 团队发布的《Darwin Gödel Machine》论文，描述了一个令人震撼的实验。他们构建了一个名为 Darwin 的 agent，其核心能力是： 阅读自己的源代码，理解其在特定任务（SWE-bench，一个衡量代码生成能力的基准）上的表现，然后自主地、迭代地重写自己的代码，以提升性能 。实验结果显示，Darwin 在短短几轮自我迭代后，其在 SWE-bench 上的得分，从初始的 20% 跃升至 50%。更关键的是，这个结果被 SWE-bench 的官方团队独立复现并确认。

这个实验的意义，远超一个技术指标的提升。它揭示了一个根本性的转变： 当 agent 能够自我进化时，“runtime”这个概念本身，就必须被重新定义 。

• 沙箱（Sandbox） 不再仅仅是安全隔离的容器，它必须成为一个 受控的、可审计的“进化实验室” 。你不能让一个 agent 在生产环境中，随心所欲地重写自己的核心逻辑。每一次代码变更，都必须被记录、被审查、被批准。沙箱需要提供一种机制，让 agent 的“进化提案”（proposal）能够被提交到一个 governance workflow 中，由人类或更高阶的 policy agent 进行评估，只有通过评估的变更，才能被合并到主干。

• 追踪存储（Trace Store） 的角色，也从“记录发生了什么”，升级为“记录了为什么发生”和“记录了如何被批准”。它需要存储的，不仅是 tool_call 事件，还有 code_change_proposal 、 governance_review 、 approval_signature 等全新的事件类型。它将成为一个组织的“AI 行为宪法”，是任何关于 AI 决策的法律诉讼中，最具分量的证据。

• 治理与策略（Governance & Policy） 将成为整个 AI stack 的“中枢神经系统”。它需要定义的，不再是简单的“能否调用 API”，而是更复杂的“进化权”（Right to Evolve）：一个 agent 在什么条件下，可以启动自我进化？它能修改哪些模块？它的进化目标函数（Objective Function）必须满足哪些伦理和合规约束？谁有权否决一次进化？这些问题的答案，将直接决定一个组织的 AI 系统，是走向高效与创新，还是滑向失控与风险。

因此，Anthropic Managed Agents 所代表的，或许不是 runtime 层的终点，而恰恰是它的起点。它提供了一个坚实、可靠、安全的基座，让我们得以在上面，去构建那些真正能改变世界的、具备自我意识和自我进化能力的 AI 系统。它的价值，不在于它今天能做什么，而在于它为明天的无限可能，铺平了道路。作为一个在一线摸爬滚打多年的从业者，我亲眼见证了从单体应用到微服务，再到 Serverless 的每一次架构跃迁。这一次，我们站在的，是 AI 原生时代的门槛上。而 Managed Agents，就是那把打开大门的钥匙。