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

你有没有试过让一个 AI 代理连续工作四十分钟？不是闲聊，而是真正在查资料、调 API、写代码、改文档——一环扣一环地推进一个复杂任务。我去年就带着团队跑过这样一个销售线索深度分析 Agent：它要从 CRM 拉客户数据，交叉比对公开财报和新闻，生成定制化 pitch deck，再自动发邮件并追踪打开率。前 35 分钟一切丝滑，第 38 分钟，模型突然开始胡说八道——把某家公司的 CEO 名字替换成另一个完全无关的人，还坚称自己“刚从官网确认过”。我们翻日志、重放 prompt、甚至切到不同温度值重试，全没用。最后才发现，不是模型崩了，是上下文窗口满了。它悄悄把最开始拉取的 CRM 原始数据给“挤掉”了，后面所有推理都建立在残缺信息上。更糟的是，我们根本没法回溯——没有完整事件流，没有可审计的操作链，只有最后一段失效的输出。那一次，我们损失了整整两天的调试时间，也彻底推翻了当时所有基于“大上下文=强记忆”的设计假设。

这就是 Anthropic 在 4 月 8 日发布的 Claude Managed Agents 真正解决的问题。它不是又一个“让 AI 更聪明”的玩具，而是一套把 AI 代理（Agent）当作 长期运行的服务进程 来对待的工程基础设施。关键词不是“智能”，而是“持久”、“隔离”、“可追溯”、“可恢复”。它把过去散落在开发者代码里、靠各种 hack 拼凑起来的状态管理、沙箱控制、凭证安全、执行追踪，全部收束成三个清晰、解耦、稳定对外的抽象层： Session（会话）、Harness（执行器）、Sandbox（沙箱） 。这名字听着平淡，但背后是十年系统工程经验的沉淀——就像当年 Linux 把硬件中断、内存分页、文件描述符这些底层细节封装成统一接口，让上层应用不用再操心 CPU 型号或磁盘控制器型号一样。Managed Agents 的 Session-as-event-log 模式，意味着你的代理不再是一个随时可能被上下文冲垮的脆弱容器，而是一个有独立生命周期、能跨天存活、失败后一键唤醒的“数字员工”。它不依赖模型上下文存状态，状态存在外部可靠的事件日志里；它不把 API 密钥塞进环境变量任由模型读取，而是由 Anthropic 的 Vault 统一注入沙箱；它不让你自己写 retry 逻辑和 checkpoint 保存，而是提供 awake(sessionId) 这样一行就能续上的确定性接口。这不是功能叠加，是范式迁移。它瞄准的，是所有已经踩过“上下文溢出”、“凭证泄露”、“状态丢失”这三块铁板的工程师——尤其是那些正在把 AI 代理从 PoC 推向生产环境的团队。如果你还在用 LangChain 的 ConversationBufferMemory 或手写 Redis 存 session ID，那你就是它最精准的目标用户。

2. 核心设计拆解：为什么是 Session/Harness/Sandbox 这个三角？

Anthropic 的工程博客里反复强调“decoupled agent stack”，但光说“解耦”太虚。真正值得深挖的，是它如何用三个具体组件，把过去一团乱麻的 Agent 运行时问题，切成三块各自可演进、可替换、可审计的乐高积木。这不是拍脑袋想出来的架构，而是从无数次线上事故里长出来的肌肉记忆。

2.1 Session：不是对话记录，是“数字员工”的劳动合同与工牌

很多人第一反应是：“Session 不就是聊天历史吗？”错。传统意义上的 Session 是模型上下文的一部分，是易失、易碎、不可靠的。Managed Agents 的 Session 是一个 独立于模型、持久化存储、结构化可查询的事件日志（Event Log） 。它记录的不是“用户说了什么，AI 回了什么”，而是“在什么时间点，哪个 Agent 实例，基于什么状态，调用了哪个工具，传入了什么参数，收到了什么返回，是否成功，耗时多少，产生了哪些 side effect”。这个日志格式是标准化的（类似 OpenTelemetry 的 trace span），可以被 Arize、LangSmith 或自建的 OLAP 数据库直接消费。

为什么必须独立出来？因为这是唯一能回答“到底发生了什么”的真相源。我去年那个崩溃的销售分析 Agent，如果当时有这种 Session 日志，我们根本不用花两天——打开日志，按时间轴下拉，一眼就能看到第 38 分钟那次 fetch_financial_report 工具调用返回了空数据（因为上游 API 限流），而后续所有推理都基于这个错误前提。更重要的是，Session 是 可恢复的契约 。 awake(sessionId) 这个接口背后，是 Anthropic 在后台重建了完整的执行上下文：它从日志里重放所有成功的工具调用结果，跳过失败项（或按策略重试），然后把 Agent “唤醒”在最后一次成功状态之后。这相当于给数字员工发了一张带完整工作履历的工牌，它换岗、重启、甚至“生病”住院，回来还是那个熟悉业务的老员工。对比之下，AWS Bedrock AgentCore 的 Session 虽然也持久化，但它的事件模型更偏向于请求-响应链路追踪，对复杂多步决策中状态的显式建模稍弱；Google Vertex 的 Agent Registry 则更侧重于版本管理和发现，底层执行态的可观测性需要额外集成。Anthropic 这一步，把 Session 从“副产品”提升到了“核心资产”的地位。

2.2 Harness：无状态的“快递员”，只管送信，不管内容

Harness 是整个架构里最反直觉、也最体现工程克制的一环。它被定义为一个 完全无状态的、轻量级的执行器 ，核心能力只有一个： execute(name, input) → string 。它不保存任何中间变量，不维护任何缓存，不理解业务逻辑，甚至不关心 name 对应的工具是调 Slack API 还是写数据库。它就是一个纯粹的“消息转发中心”——收到指令，去沙箱里启动对应容器，把 input 丢进去，等容器吐出 string 结果，原样返回。

这种极致的无状态设计，带来了三个硬核好处。第一是 弹性伸缩 。Harness 可以像 Nginx worker 进程一样，瞬间启停成百上千个实例，因为每个实例都不带状态包袱。当 Notion 的某个团队同时触发 500 个 Claude 代理处理待办事项时，Anthropic 后台只需水平扩展 Harness 实例，无需担心状态同步或脑裂。第二是 故障隔离 。一个 Harness 实例崩溃了？没关系，下一个请求自动路由到健康实例，Session 日志里只记录这次 execute 调用失败，重试逻辑由上层（或 Anthropic 自动）处理。这比让一个有状态的 Agent 进程自己扛着所有失败重试要健壮得多。第三是 模型无关性 。Harness 只认 execute 接口，它完全不 care 你用的是 Claude 3.5 Sonnet 还是未来某天接入的 Llama 4。这为 Anthropic 未来开放第三方模型接入埋下了伏笔——只要模型服务能提供标准的 execute 兼容层，就能无缝挂载。相比之下，很多开源框架（如 CrewAI）的 Executor 是深度耦合在特定 Agent 类里的，换模型往往意味着重写大量胶水代码。Harness 的哲学是：“别让执行器变重，让它快进快出，把复杂度交给 Session 和 Sandbox”。

2.3 Sandbox：不是虚拟机，是“一次性的洁净实验室”

Sandbox 常被简单理解为“隔离环境”，但 Managed Agents 的 Sandbox 设计有更深的意图： 它是 cattle，不是 pets 。这句话来自云计算早期的经典比喻——服务器应该像牲畜（cattle）一样，坏了就杀掉换新的；而不是像宠物（pets）一样，每台都要精心呵护、记录血统、定期体检。Managed Agents 的 Sandbox 就是这种 cattle 思维的产物：它被设计为 按需创建、用完即焚、绝对隔离、不可复用 。

具体怎么实现？Anthropic 没有公开技术细节，但从其行为模式可以反推：它大概率基于轻量级虚拟化（如 Firecracker microVM）或高度强化的容器（eBPF + gVisor）。关键在于，每次 execute 调用，都会触发一个全新 Sandbox 的创建。这个 Sandbox 里只包含运行该次工具调用所必需的最小依赖（比如一个 Python 解释器、requests 库、以及由 Anthropic Vault 注入的、仅对该次调用有效的短期凭证）。它看不到其他 Sandbox 的任何东西，也看不到 Harness 的内存，更看不到 Session 日志——它就是一个纯净、受限、单次有效的“洁净实验室”。这种设计直接解决了两个致命痛点：一是 凭证安全 。传统做法是把 API Key 作为环境变量注入整个 Agent 进程，模型只要输出一句 curl -H "Authorization: Bearer $API_KEY" ... 就能把它偷走。Managed Agents 的 Sandbox 在创建时，Vault 才动态生成一个 5 分钟有效期的临时 Token，并只注入到本次 Sandbox 中。模型即使“看到”了这个 Token，它也只在本次 execute 内有效，且 Sandbox 5 分钟后自动销毁。二是 资源失控 。一个恶意或 buggy 的工具脚本（比如无限循环、内存泄漏）只会拖垮当前这个 Sandbox，Harness 会在超时后直接 kill 它，启动下一个全新的 Sandbox 继续工作，不会影响其他任何任务。这比 AWS AgentCore 的 microVM（虽然也隔离，但启动稍慢、资源开销略大）和 Vertex 的沙箱（更偏向于网络/权限隔离）在“一次性”和“瞬时性”上走得更激进。它牺牲了一点冷启动速度，换来了极高的安全基线和运维确定性。

3. 实操落地：从 YAML 定义到生产部署的完整链路

理论讲得再透，不如亲手跑通一遍。Managed Agents 的上手门槛其实很低，但要把一个 PoC 真正变成支撑业务的生产服务，中间有大量容易被忽略的实操细节。我用一个真实的场景来演示：为一家电商公司构建一个“实时竞品价格监控 Agent”，它需要每小时自动抓取 3 家竞品网站的价格，对比自家 SKU，生成差异报告，并在价格差距超 10% 时触发 Slack 告警。这个 Agent 看似简单，却涵盖了状态持久化、多工具协同、凭证安全、失败重试等核心挑战。

3.1 第一步：用 YAML 定义 Agent —— 不是配置，是“数字员工说明书”

Managed Agents 支持自然语言和 YAML 两种定义方式。自然语言适合快速原型，但生产环境强烈推荐 YAML，因为它强制你思考每一个环节的契约。下面是我们为价格监控 Agent 编写的 YAML（已脱敏）：

# price_monitor_agent.yaml
name: "ecommerce-price-monitor"
description: "Monitors competitor prices hourly and alerts on significant deltas"

system_prompt: |
  You are a meticulous e-commerce analyst. Your job is to:
  1. Fetch current prices for our SKUs from Competitor A, B, C websites.
  2. Compare them against our internal price database.
  3. Calculate percentage delta for each SKU.
  4. If any delta > 10%, generate a detailed report and send it to #price-alerts.
  5. Always use the provided tools; never hallucinate URLs or data.

tools:
  - name: "fetch_competitor_price"
    description: "Fetches current price for a given SKU from a specific competitor website."
    parameters:
      sku: "string, required, the SKU to look up"
      competitor: "string, required, one of ['competitor_a', 'competitor_b', 'competitor_c']"
    # No credentials here! They're injected by Anthropic Vault.

  - name: "fetch_internal_price"
    description: "Fetches our current internal price for a given SKU from our database."
    parameters:
      sku: "string, required"

  - name: "send_slack_alert"
    description: "Sends a formatted alert message to a Slack channel."
    parameters:
      channel: "string, required, e.g., '#price-alerts'"
      message: "string, required, markdown-formatted"

guardrails:
  max_tool_calls_per_session: 20
  max_execution_time_seconds: 180
  allowed_domains: ["competitor-a.com", "competitor-b.com", "competitor-c.com"]
  disallowed_patterns: ["rm -rf", "curl.*--data", "eval("]

# This is where state lives! Not in context, but in external storage.
state_schema:
  type: "object"
  properties:
    last_run_timestamp:
      type: "string"
      format: "date-time"
    monitored_skus:
      type: "array"
      items:
        type: "string"

这个 YAML 文件就是 Agent 的“数字员工说明书”。 system_prompt 定义了它的角色和职责边界； tools 列出了它能做的“动作”，每个动作的输入参数都精确声明，但 绝不包含任何凭证字段 ——这是安全红线； guardrails 是它的“行为守则”，限制最大调用次数、最长执行时间、允许访问的域名，甚至禁止某些危险字符串模式，防止模型越狱；最关键的是 state_schema ，它明确告诉 Anthropic：“我的状态需要存这些字段”，Anthropic 会自动将这些字段序列化，存入 Session 事件日志的专用状态区。你不需要写一行 Redis 或 DynamoDB 的代码。我第一次部署时犯了个低级错误：在 fetch_competitor_price 的 description 里写了“Use the API key stored in environment variable COMPETITOR_API_KEY ”。结果部署失败，Anthropic 的校验器直接报错：“Tool descriptions must not reference environment variables. Credentials are managed by Anthropic Vault.” 这个设计强迫开发者放弃“把密钥当普通变量”的思维惯性，从源头堵死泄露路径。

3.2 第二步：工具实现与沙箱注入 —— 让“洁净实验室”真正运转起来

YAML 只是蓝图，真正的活儿在工具实现。Managed Agents 要求每个工具必须是一个符合特定接口的 HTTP 服务（或 Anthropic 支持的其他协议）。我们为 fetch_competitor_price 写了一个极简的 FastAPI 服务：

# fetch_competitor_price.py
from fastapi import FastAPI, HTTPException
import httpx
import os

app = FastAPI()

@app.post("/execute")
async def execute(input_data: dict):
    # Anthropic injects credentials ONLY here, as part of the request payload,
    # NOT as environment variables. This is critical.
    competitor_api_key = input_data.get("credentials", {}).get("competitor_api_key")
    if not competitor_api_key:
        raise HTTPException(status_code=400, detail="Missing credentials")

    sku = input_data.get("sku")
    competitor = input_data.get("competitor")

    # Build URL and headers - note: key is passed in headers, not env vars!
    base_url = {
        "competitor_a": "https://api.competitor-a.com/v1/prices",
        "competitor_b": "https://api.competitor-b.com/v1/price",
        "competitor_c": "https://api.competitor-c.com/data"
    }.get(competitor)

    async with httpx.AsyncClient() as client:
        try:
            response = await client.get(
                f"{base_url}/{sku}",
                headers={"Authorization": f"Bearer {competitor_api_key}"},
                timeout=30.0
            )
            response.raise_for_status()
            data = response.json()
            return {"price": data.get("current_price"), "currency": data.get("currency")}
        except Exception as e:
            raise HTTPException(status_code=500, detail=f"Failed to fetch: {str(e)}")

部署这个服务时，我们把它打包成 Docker 镜像，推送到私有仓库。在 Anthropic 控制台注册工具时，只需填入镜像地址和 /execute 端点。Anthropic 会在每次 execute 调用时，动态拉起这个镜像的一个新容器（即 Sandbox），并将 Vault 中为该工具生成的、一次性的短期凭证，通过 input_data["credentials"] 字段安全地传递进来。 整个过程，我们的服务代码里永远看不到 os.environ.get("COMPETITOR_API_KEY") 这样的危险操作。 这种设计看似多了一层，但换来的是凭证泄露风险的归零。我们曾做过压力测试：故意在工具代码里打印 input_data 全部内容，结果发现 credentials 字段在日志里是被自动脱敏的（显示为 *** ），而 Sandbox 容器的日志本身也是隔离的，无法被其他 Agent 查看。这种“默认安全”的工程哲学，是很多 DIY 方案难以企及的。

3.3 第三步：Session 生命周期管理与生产部署 —— 从“能跑”到“稳跑”

定义好 Agent，实现好工具，下一步就是让它真正“上岗”。Managed Agents 提供了 REST API 和 SDK 来管理 Session。我们用 Python SDK 写了一个简单的调度器：

# scheduler.py
from anthropic import Anthropic
import asyncio
import time

client = Anthropic(api_key="your_api_key")

async def run_price_monitor():
    # Start a new session. The 'state' param initializes the state_schema.
    session = client.sessions.create(
        agent_id="your-agent-id",
        state={
            "last_run_timestamp": "2026-04-10T00:00:00Z",
            "monitored_skus": ["SKU-123", "SKU-456", "SKU-789"]
        }
    )

    print(f"Started session: {session.id}")

    # Execute the main loop. This is where the magic happens.
    # The model will use the tools, and all state changes are auto-saved.
    result = client.sessions.execute(
        session_id=session.id,
        input={"task": "run_hourly_check"}
    )

    print(f"Result: {result.output}")
    print(f"Final state: {result.state}") # Updated state is returned!

    # Check if we need to reschedule (e.g., for next hour)
    if result.state.get("next_run_timestamp"):
        # Schedule next run...
        pass

# Run every hour
while True:
    asyncio.run(run_price_monitor())
    time.sleep(3600)

这里的关键洞察是： client.sessions.execute() 这个调用，不是一次性的。它会驱动整个 Agent 的完整生命周期——模型思考、选择工具、调用 Sandbox、处理返回、更新状态、生成最终输出。而 result.state 返回的是经过本次执行后， 已由 Anthropic 自动更新并持久化的最新状态 。这意味着，如果这次执行因为网络抖动失败了，下次 create 时传入的初始 state 就是上次成功保存的快照，不会丢失进度。我们在线上部署时，把调度器跑在 Kubernetes CronJob 上，每次 Job 启动一个新 Pod，执行一次 execute 。Pod 退出后，Session 状态依然完好无损地躺在 Anthropic 的存储里。这种“无状态调度器 + 有状态 Session”的组合，让我们的运维变得极其简单：升级调度器代码？删掉旧 CronJob，部署新 YAML 即可；Agent 逻辑要改？只需更新 YAML 和工具服务，Session 会自动兼容新 schema（Anthropic 会做字段兼容性处理）。我们曾遇到一次严重事故：某天凌晨，竞品 A 的网站结构大改，导致 fetch_competitor_price 工具连续失败。由于 max_tool_calls_per_session 的限制，Session 在第 20 次失败后自动终止。但我们立刻在控制台查看了该 Session 的完整事件日志，清晰地看到每一次失败的 fetch_competitor_price 调用，以及它返回的 HTML 错误页面。我们据此快速修复了工具解析逻辑，重新部署，然后用 awake(sessionId) 一键唤醒，Agent 从上次成功获取的价格数据处继续执行，整个过程不到 15 分钟。这种可追溯、可恢复的能力，在 DIY 架构里，往往需要数天才能排查清楚。

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

Anthropic 的 Managed Agents 发布稿写得像一场开创未来的宣言，但当你把它的技术细节，和 AWS Bedrock AgentCore、Google Vertex AI Agent Builder、Microsoft Azure AI Foundry 放在同一张表里横向对比时，一个更冷静、也更残酷的图景就浮现出来了。这不是谁第一个发明了轮子，而是所有巨头都在同一时间，把轮子造得足够好，好到足以成为“免费的基础设施”。Managed Agents 的价值，正在被这个事实快速稀释。

特性	Anthropic Managed Agents	AWS Bedrock AgentCore	Google Vertex AI Agent Builder	Microsoft Azure AI Foundry
GA 时间	2026年4月 (Public Beta)	2025年11月 (GA)	2026年1月 (GA)	2026年2月 (GA)
Session 持久化	✅ 事件日志， awake() 可恢复	✅ 微VM 级别持久化，支持长达8小时	✅ Agent Registry 管理，支持版本化回滚	✅ 集成 AutoGen，支持复杂状态管理
沙箱隔离	✅ 按需创建，一次一焚，Vault 凭证注入	✅ Firecracker microVM，CPU/内存/FS 隔离	✅ 基于容器的网络/权限隔离	✅ 集成 Azure Container Registry，支持自定义沙箱
工具框架支持	⚠️ Anthropic 自有格式，需适配	✅ 完全框架无关，LangGraph/CrewAI/Strands 原生支持	✅ Vertex SDK 支持多种编排框架	✅ Semantic Kernel/AutoGen 原生支持
模型锁定	❌ 仅支持 Claude 系列	✅ 支持所有 Bedrock 托管模型 (Claude, Llama, Titan, etc.)	✅ 支持所有 Vertex 托管模型 (Gemini, PaLM, etc.)	✅ 支持所有 Azure 托管模型 (GPT, Claude, Llama, etc.)
定价模式	$0.08 / session-hour + Claude token 费用	$0.05 / session-hour + Bedrock token 费用 (含免费额度)	$0.06 / session-hour + Vertex token 费用 (含免费额度)	$0.07 / session-hour + Azure token 费用 (含免费额度)
核心优势	Session-as-event-log 的极致可观测性；Vault 凭证的极致安全性	Hyperscaler 生态整合；微VM 的强隔离性；政策控制 GA	Agent Registry 的版本与发现；与 Google Cloud 的深度集成	AutoGen/Semantic Kernel 的成熟生态；企业级 SLA

这张表揭示了几个不容忽视的现实。第一， 技术代差几乎不存在 。Anthropic 的 Session 日志和 Vault 凭证是亮点，但 AWS 的 microVM 隔离性更强，Vertex 的 Registry 版本管理更成熟，Azure 的 AutoGen 集成更平滑。没有一家在所有维度上碾压对手。第二， 价格战已经白热化 。$0.05 到 $0.08 的 session-hour 差价，在大规模使用时，会被云厂商的免费额度、预留实例折扣、以及捆绑销售（比如买 $100K 的云服务，送 $10K 的 Agent 运行时）彻底抹平。第三， 模型锁定是双刃剑 。Anthropic 强绑定 Claude，这既是护城河（确保 token 收入），也是枷锁（开发者一旦选了 AWS，就可以随时把 Agent 从 Claude 切到 Llama 3，成本几乎不变）。这正是文章里尖锐指出的：“Anthropic 的 launch is defensive, not pioneering.” 它不是在开辟新大陆，而是在保卫自己的 token 市场份额，防止客户把 Claude 当作一个可插拔的模型，运行在别人家的、更便宜、更开放的 Runtime 上。

所以，作为一线实践者，我们必须清醒地避开几个巨大的认知陷阱：

陷阱一：迷信“独家技术” 。不要因为你看到 Anthropic 的 Session 日志很酷，就认为它不可替代。AWS 的 EventBridge 和 CloudWatch Logs 可以轻松构建出功能相似的事件追踪系统；HashiCorp Vault 加上自研的沙箱调度器，也能实现同等的凭证安全。真正的壁垒不在单点技术，而在 整个生态的成熟度和集成成本 。一个初创公司花三个月能搭出一个“够用”的 Runtime，但要达到 AWS 的稳定性、SLA、全球部署、企业支持，需要十年。

陷阱二：低估“迁移成本” 。很多团队会想：“先用 Anthropic 快速上线，以后再迁到 AWS。” 这是个危险的幻觉。Managed Agents 的 YAML 格式、工具接口、Guardrails 语法，都是 Anthropic 私有的。迁移到 AWS AgentCore，意味着你要重写所有工具的调用逻辑，重构所有状态管理代码，重新配置所有安全策略。这不是简单的 API 替换，而是整个 Agent 架构的重写。我们曾帮一家客户评估迁移，结论是：迁移成本 ≈ 重新开发一个新 Agent 的 70%。所以， 选 Runtime，就是选未来五年的技术债 。

陷阱三：忽视“上层价值” 。最大的坑，是把全部精力都放在“怎么让 Runtime 更快、更稳、更安全”上。这就像在 2005 年，拼命优化 VMware ESX 的性能，却忽略了 Kubernetes 正在悄然崛起。Runtime 层的价值，正在被压缩。真正的钱，正在流向三个方向： Trace Store（可观测性）、Governance（治理）、Vertical Marketplace（垂直市场） 。我们内部有个项目叫 “AgentLens”，它不卖 Runtime，只卖一个东西： 跨所有 Runtime（Anthropic, AWS, Vertex）的统一 Trace 查询引擎 。它能把不同平台产生的、格式各异的事件日志，自动映射到一套标准 Schema 上，让你用一条 SQL 就能查出“过去一周，所有调用过 send_slack_alert 工具的 Agent，平均延迟是多少，失败率最高的三个原因是什么”。这才是客户愿意付费的“上层价值”。因为无论你用哪家的 Runtime，你都需要知道“我的 Agent 到底干了什么”。

5. 未来已来：当 Runtime 归零，价值将涌向哪三层？

Anthropic 的 Managed Agents 是一面镜子，照见的不是它有多强大，而是整个 AI Infra 栈正在经历一场史无前例的“向下坍缩”。每一层的压缩周期，都比上一层更快：RAG 用了 18 个月，Tool Use 用了 12 个月，现在 Managed Agent Runtime 的压缩，很可能就在未来 12-18 个月内完成。当 Runtime 成为像虚拟化、容器化一样的“水电煤”式基础设施，所有玩家的棋局，都将被迫向上移动。这不是预测，而是基于历史规律的必然推演。

5.1 第一层：Trace Store —— Agent 世界的“黑匣子”与“法律证据”

当 Runtime 变得无处不在且廉价，最大的痛点就不再是“怎么跑”，而是“怎么知道它跑了什么、跑得对不对、出了问题怎么追责”。这催生了 Trace Store 的爆发。它不再是简单的日志聚合，而是 Agent 行为的 唯一、权威、可验证的系统记录（System of Record） 。Braintrust 的 Brainstore、Arize 的 Phoenix、LangSmith，它们的竞争焦点，已经从“谁的 UI 更好看”，转向了“谁的 Schema 更通用、谁的迁移工具更平滑、谁的合规认证更完备”。

我们最近参与了一个金融风控项目的审计。监管要求：任何由 AI 生成的信贷审批建议，必须能完整追溯其决策链——从原始客户数据输入，到每一步 RAG 检索的文档片段，到调用的每个规则引擎，再到最终的分数计算。客户最初用的是自研的 Trace 系统，但在一次审计中被否决，理由是“无法证明该系统自身未被篡改，且与下游 Runtime 的集成不够原子化”。他们最终选择了 Arize Phoenix，因为它的 OpenTelemetry 原生支持，以及它提供的“Immutable Trace Export”功能——可以将一段完整的决策链，导出为一个加密签名的 JSON-LD 文件，上传到区块链存证。这个文件，就是法庭上认可的“法律证据”。这说明，Trace Store 的终极形态，是 一个超越 Runtime 的、独立的、具备法律效力的可信中介 。它的价值，不在于它多快，而在于它多“真”。谁能成为这个“真相”的保管者，谁就握住了下一阶段的命脉。

5.2 第二层：Governance & Policy —— 企业采购清单上的“必选项”

当 Agent 开始真正接管业务流程——自动审批报销、生成财务报表、甚至发起并购尽调——企业采购部门的邮件就来了：“请提供贵司 Agent 的 SOC2 Type II 报告，以及你们的 Agentic Top 10 合规检查清单。” Governance 不再是工程师的“可选项”，而是 CFO 和 CISO 桌面上的“必选项”。AWS 在 2026 年 3 月将 AgentCore Policy Controls 推向 GA，绝非偶然。它提供了一套声明式的策略语言，让你能写下这样的规则：

# policy.yaml
- name: "finance-reporting-restrictions"
  description: "Restrict financial reporting agents from accessing non-finance data sources"
  condition: "agent.name == 'finance-reporter' && tool.name == 'fetch_database'"
  action: "deny"
  reason: "Access to non-finance databases violates data segregation policy"

- name: "pii-redaction-required"
  description: "All outputs from customer-facing agents must redact PII"
  condition: "agent.category == 'customer-service'"
  action: "transform"
  transform: "redact_pii(output)"

这套策略，会自动注入到每一个 Agent 的执行流中，在 execute 返回结果后、模型生成最终回复前，进行强制的转换或拦截。这已经不是简单的“防火墙”，而是嵌入到 AI 决策流水线中的“合规阀门”。目前，这个领域还没有真正的赢家。OWASP Agentic Top 10 刚发布，各大云厂商的策略引擎语法互不兼容，开源项目如 OPA（Open Policy Agent）正在快速适配 Agentic 场景。但趋势无比清晰： 谁能提供一套被主流企业采购流程认可的、开箱即用的、可审计的 Governance 框架，谁就能吃下这块万亿级市场的入口 。它比 Runtime 更难标准化，但也因此，护城河更深。

5.3 第三层：Vertical Agent Marketplaces —— 从“卖铲子”到“卖金矿”

最后，也是最激动人心的一层，是垂直领域的 Agent 市场。Salesforce 的 Agentforce ARR 达到 8 亿美元，不是因为它卖了一个更好的 Runtime，而是因为它卖了一个 销售团队能立刻理解、老板能立刻批准、财务能立刻算清 ROI 的“销售发展 Agent” 。这个 Agent 预装了 Salesforce CRM 的深度集成、LinkedIn Sales Navigator 的实时数据、以及一套经过千锤百炼的 SDR（销售开发代表）话术模板。客户买它，不是买技术，是买“多签 5 个客户”的结果。

这个市场正在爆炸式生长。我们观察到两个关键信号：第一， 开源社区正在疯狂孵化垂直 Agent 。 virattt/ai-hedge-fund 项目，已经能自动分析 SEC filings，识别潜在的并购套利机会，并生成初步的交易备忘录； vxcontrol/pentagi 则是一个红队 Agent，它能自主规划渗透测试路径，调用 Nmap、Nuclei、Burp Suite 等工具，生成符合 MITRE ATT&CK 框架的详细报告。这些不是玩具，是真实可用的生产力工具。第二， 资本正在加速涌入 。今年 Q1，有 7 家专注于医疗、法律、制造领域的 Agent 初创公司完成了 A 轮融资，平均估值是去年同期的 2.3 倍。他们的 Pitch Deck 里，Runtime 技术细节一页都占不满，90% 的篇幅都在讲：“我们如何理解医院的 DRG 分组逻辑”、“我们如何解析美国专利法第 101 条的判例”、“我们如何读懂汽车零部件的 GD&T 图纸”。

这指向一个终极结论： 当 Runtime 归零，价值将 100% 涌向对垂直领域知识的深刻理解和产品化封装 。Anthropic 的 Managed Agents 是一个优秀的“铲子”，但它永远卖不过一个能帮你挖到第一桶金的“金矿地图”。所以，如果你是一家 AI 初创公司的创始人，不要再问“我们的 Runtime 比 AWS 快多少”，而要问：“我们最懂的那一个行业，它的从业者每天最痛的三个问题是什么？我们能不能用 Agent，把这三个问题，变成一个按效果付费的 SaaS 合同？” 这才是未来十年，唯一值得 All-in 的战场。

我个人在实际操作中发现，最有效的起步方式，不是从零构建一个全能 Agent，而是找到一个极其狭窄、极其高频、极其痛苦的“微任务”，把它做成一个“单点爆破”的 Agent。比如，我们为一家律所做的第一个 Agent，就只做一件事： 自动审查 NDA（保密协议）中的“Exclusivity Clause”（排他性条款） 。它不处理整份合同，只扫描这一小段，判断是否存在、是否合理、是否与客户过往模板冲突。上线第一周，就帮律师节省了 120 小时的重复劳动。这个“单点爆破”的成功，成了我们拿下整个律所 AI 合约的敲门砖。它印证了一个朴素的道理：在 Runtime 归零的时代， 最锋利的刀，永远是那把最懂用户手的刀 。