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

你有没有试过让一个 AI 代理连续工作四十分钟？不是闲聊，而是真正在查文档、调 API、写代码、改配置、再验证——一整套闭环动作。去年我带团队跑一个客户的数据迁移项目，用的是自建的 LangChain + Redis 状态管理方案。前半小时一切丝滑：它能精准定位 S3 桶里的旧日志格式，调用 PySpark 脚本做字段映射，再把结果推到 Snowflake。但到了第三十七分钟，事情开始不对劲：它突然把昨天生成的 SQL 表名拼错了，接着在 Slack 里发了一条“已成功创建表”，而实际上那张表根本不存在。我们翻日志，发现 context 窗口早已爆满——模型把最开始的 S3 路径和权限策略全挤掉了，只留下后半段模糊的工具调用记忆。它没报错，没中断，只是 quietly hallucinated（安静地幻觉）——像一个经验丰富的老员工，在连续加班后开始凭印象写代码，还自信满满地提交了 PR。

这就是 Anthropic 在 4 月 8 日发布的 Claude Managed Agents 真正要解决的问题。它不是又一个“AI 代理平台”的营销话术，而是把过去一年里所有被踩过的坑、被重写的 state 层、被反复加固的沙箱边界，打包成一套可交付、可计费、可审计的托管运行时。关键词不是“agent”，而是 managed —— 它管的不是你的提示词，不是你的工具链，而是那个最脆弱、最容易被忽略的底层： 会持续存在、会跨请求存活、会承载真实业务逻辑的执行环境本身 。

这层东西，过去要么被塞进 LLM 的 context 窗口里（廉价但不可靠），要么被开发者自己用 Redis + PostgreSQL + 自定义序列化硬扛（灵活但重复造轮子），要么干脆交给 LangChain 的 Memory 类糊弄（适合 demo，不适合生产）。Anthropic 把它拎出来，命名为 Session ，并明确说：这不是模型的一部分，是独立于模型之外的、持久化的、可查询的事件日志。它不关心你用的是 Claude 3.5 还是 Claude 4，只负责记住“谁在什么时候调了什么工具、传了什么参数、返回了什么结果、中间卡在哪一步”。这个设计，直接切中了当前 agent 开发中最痛的三根神经： 状态丢失、凭证泄露、过程不可追溯 。

所以，如果你是正在评估要不要把内部客服 agent 迁上云的架构师，或者正为销售团队定制一个自动填 CRM 的 agent 的产品经理，又或者刚被老板问“我们自己搭的这套 agent 系统，到底值不值得继续投人维护”的技术负责人——这篇文章不是讲“Anthropic 又出了个新产品”，而是帮你判断： 你现在手里的 runtime 层，是该升级、该替换，还是该立刻砍掉，把资源挪到真正能建立壁垒的地方去 。它不教你怎么写 system prompt，但会告诉你，为什么你花三个月写的 prompt 工程，可能不如花三天接入一个 trace store 来得值钱。

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

2.1 “Session” 不是会话，是业务事件的不可篡改账本

Anthropic 官方文档里把 Session 描述为“durable event log living outside the model context”。这句话听着抽象，但换成工程语言就是： 每一次 tool call 的输入、输出、时间戳、调用者身份、执行耗时、错误堆栈，都被原子性地写入一个独立的、带版本号的、只追加（append-only）的日志流里 。这个日志流不存于模型的 memory 中，不依赖于任何一次 inference 请求的生命周期，甚至不依赖于你当前使用的 Claude 版本。它由 Anthropic 的后端服务统一管理，通过 GET /sessions/{id}/events 这样的标准 REST 接口对外暴露。

我拿我们去年那个失败的迁移 agent 做对比。当时我们的 state 存在 Redis 里，结构是：

{
  "session_id": "sess_abc123",
  "state": {
    "s3_bucket": "prod-logs-2024",
    "spark_script_path": "/etl/migrate_v2.py",
    "target_table": "stg_customer_events",
    "last_tool_result": "{...}"
  }
}

问题就出在这个 last_tool_result 上。当 context 溢出，模型看不到 s3_bucket 和 spark_script_path ，它只能基于 last_tool_result 和当前 prompt 猜测下一步。而 last_tool_result 本身又是上一轮 tool call 的输出，可能已经因网络抖动被截断。于是整个链条变成“猜上一轮的输出 → 猜这一轮的输入 → 猜下一轮的工具名”，最终崩塌。

Managed Agents 的 Session 则完全不同。它的事件流长这样（简化版）：

sequence	timestamp	type	tool_name	input	output	status
1	2026-04-08T09:01:22Z	tool_call	list_s3_files	{"bucket": "prod-logs-2024", "prefix": ""}	["2024-04-01.log", "2024-04-02.log"]	success
2	2026-04-08T09:02:15Z	tool_call	run_spark_job	{"script": "/etl/migrate_v2.py", ...}	{"job_id": "spark_789", "status": "RUNNING"}	success
3	2026-04-08T09:05:44Z	tool_call	check_job_status	{"job_id": "spark_789"}	{"status": "COMPLETED", "rows_processed": 12487}	success

提示：这个表格不是示例，是 Anthropic 实际返回的 JSON 结构的直译。你可以用 curl -H "x-api-key: $KEY" https://api.anthropic.com/v1/sessions/sess_abc123/events 直接拿到。它不依赖模型上下文，不随 inference 请求消失，且支持按 type 、 tool_name 、 status 多维度过滤查询。

这种设计带来的第一个硬性收益，是 故障可回溯、可重放 。当 agent 在第 12 步出错，你不需要重启整个 session，也不需要祈祷 Redis 里存的 state 还完整。你只需拉取从第 10 步开始的事件流，用 awake(sessionId) API 让 harness 从那个精确的 checkpoint 恢复执行。Harness 是无状态的，它只负责读取事件日志、解析下一步该调哪个 tool、把参数传进去、再把结果写回日志。模型崩溃？没关系，Harness 会重新加载；网络超时？事件日志里标记为 failed ，下次重试时自动跳过已成功的步骤。这不再是“AI 系统”，而是一个符合传统分布式系统设计原则的、有明确 SLO 的业务工作流引擎。

2.2 Harness：无状态执行器，不是模型包装器

很多开发者第一次看到 Managed Agents 的架构图，会下意识把 “Harness” 理解为“另一个模型 wrapper”。这是最大的认知偏差。Harness 的核心接口只有一个： execute(name, input) → string 。注意，它返回的是 string ，不是 LLMResponse ，不是 ToolResult ，就是一个纯文本字符串。这意味着 Harness 对模型一无所知——它不解析 response，不处理 stop sequences，不管理 temperature 或 top_p。它只做一件事： 把 name （工具名）和 input （JSON 字符串）丢给一个容器，等容器吐出一个字符串，然后原封不动地交还给上层逻辑 。

这个设计背后是深刻的工程权衡。Anthropic 明确放弃了“在 runtime 层做智能决策”的诱惑。他们不提供 auto_retry_on_failure ，不内置 fallback_to_human ，不支持 dynamic_tool_selection 。为什么？因为所有这些“智能”都依赖对模型输出的深度理解，而这种理解在不同模型、不同版本、不同 prompt 下极不稳定。去年我们团队在 LangChain 里实现了一个 AutoRetryToolWrapper ，它会分析模型返回的 error message，判断是网络超时还是参数错误，再决定是重试还是换工具。上线两周后，因为 Claude 3.5 的 error message 格式微调，整个 retry 逻辑失效，导致 37% 的失败请求被无限重试，拖垮了下游 API。这就是把“智能”耦合在 runtime 层的代价。

Managed Agents 的 Harness 则把“智能”彻底上移。你可以在自己的应用层写一个简单的状态机：

def handle_session_step(session_id: str):
    events = get_session_events(session_id, from_sequence=last_success_seq)
    last_event = events[-1]
    
    if last_event["status"] == "failed":
        # 应用层决策：是重试？降级？还是转人工？
        if is_network_error(last_event["output"]):
            return execute("retry_tool", {"original_input": last_event["input"]})
        else:
            return escalate_to_human(session_id, last_event)
    
    # 否则，让模型决定下一步（基于完整的事件日志）
    prompt = build_prompt_from_events(events)
    return call_claude(prompt)

Harness 只是那个沉默的、可靠的、永远在线的“工人”。它不思考，只执行。这种分离，让系统变得极其健壮：模型可以升级，prompt 可以 A/B 测试，工具可以灰度发布，而 Harness 这一层纹丝不动。它就像 Linux 内核里的 execve() 系统调用——你传给它一个可执行文件路径和参数，它就帮你启动进程，至于进程里跑的是 Python 还是 Rust，是训练好的模型还是一个 shell 脚本，它一概不管。

2.3 Sandbox：按需生成的“计算牲畜”，而非精心养护的“宠物服务器”

“Sandboxed execution” 这个词在各种 AI 平台宣传稿里快被用烂了。但 Anthropic 的实现方式，暴露了他们对生产环境的真实理解。他们的 sandbox 不是 Docker 容器，不是 Kubernetes Pod，而是一种更轻量、更隔离的微虚拟机（microVM），其核心特征是： 完全无状态、按需创建、用完即焚、资源硬隔离 。

具体来说，当你在 YAML 里定义一个 tool：

tools:
  - name: "run_sql"
    description: "Execute a SQL query against the data warehouse"
    input_schema:
      type: "object"
      properties:
        query:
          type: "string"
          description: "The SQL query to execute"
    sandbox:
      image: "ghcr.io/your-org/sql-runner:v1.2"
      cpu: "1"
      memory: "2Gi"
      timeout: "300"

Anthropic 的调度器会在每次 execute("run_sql", ...) 调用时，动态拉起一个全新的 microVM 实例，加载 sql-runner:v1.2 镜像，分配 1 个 vCPU 和 2GB 内存，设置 5 分钟超时，然后把 {"query": "SELECT ..."} 作为 stdin 输入。执行完毕，microVM 立刻销毁，所有内存、磁盘、网络连接全部清零。下一次调用，是另一个全新的、干净的实例。

这和我们常见的“长期运行的 agent service”有本质区别。后者通常是一个常驻进程，监听 RabbitMQ 队列，用同一个数据库连接池处理所有请求。好处是启动快、资源省；坏处是状态污染、资源争抢、安全风险。去年我们有个 agent 服务，因为一个恶意用户提交了超长的 base64 编码图片，导致进程内存暴涨，把同一台机器上其他 agent 的内存也吃光了，引发连锁雪崩。

Managed Agents 的 sandbox 彻底规避了这个问题。每个 tool call 都在一个独立的、资源受限的、与世隔绝的环境中运行。更重要的是， credentials 从不注入 sandbox 。你在 YAML 里定义的 aws_access_key_id 和 aws_secret_access_key ，会被 Anthropic 的 vault 服务安全存储，sandbox 只能通过一个受控的、单向的、带签名的 IPC 通道向 vault 请求临时 token。sandbox 里的进程永远看不到原始密钥，连环境变量都接触不到。这解决了 LLM agent 最致命的安全漏洞：模型通过 system prompt 或 user message 诱导 agent 输出敏感信息。在 Managed Agents 里，agent 的“视野”被严格限制在事件日志和当前 tool call 的输入里，它连自己的 credential 都不知道，更别说泄露了。

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

3.1 定义你的第一个 Managed Agent：YAML 是唯一真相源

Managed Agents 支持两种定义方式：自然语言描述（适合快速原型）和 YAML（适合生产）。我强烈建议，哪怕你是 MVP 阶段，也直接从 YAML 开始。因为 YAML 是唯一能精确控制所有行为的“真相源”（source of truth），它决定了你的 agent 在生产环境里如何被调度、如何被审计、如何被计费。

一个典型的、可用于生产的 agent YAML 如下（以“自动分析用户反馈并生成产品改进建议”为例）：

# feedback_analyzer_agent.yaml
version: "2026-04-01"

# Agent 元信息，用于审计和计费
metadata:
  name: "feedback-analyzer-prod"
  description: "Analyzes user feedback from Intercom and Jira, identifies top pain points, and drafts product roadmap items"
  owner: "product-team@yourcompany.com"
  tags: ["product", "customer-success", "ai"]

# 核心行为：system prompt 是 agent 的“性格”和“职责”
system_prompt: |
  You are a senior product analyst at a SaaS company. Your job is to analyze user feedback and generate actionable product insights.
  - You MUST use the provided tools to fetch data. Never hallucinate data.
  - You MUST cite the exact source (Intercom conversation ID or Jira ticket number) for every claim.
  - You MUST output in the exact JSON schema specified by the 'generate_roadmap_item' tool.

# 工具集：每个 tool 都是独立的、可审计的执行单元
tools:
  - name: "fetch_intercom_conversations"
    description: "Fetch recent Intercom conversations matching search terms"
    input_schema:
      type: "object"
      properties:
        query:
          type: "string"
          description: "Search terms, e.g., 'login slow', 'billing error'"
        days_back:
          type: "integer"
          default: 30
          description: "How many days back to search"
    sandbox:
      image: "ghcr.io/your-org/intercom-fetcher:v2.1"
      cpu: "0.5"
      memory: "1Gi"
      timeout: "120"
      # 凭证由 Anthropic vault 注入，sandbox 内部不可见
      secrets:
        - "intercom_api_token"
        - "intercom_app_id"

  - name: "fetch_jira_tickets"
    description: "Fetch Jira tickets with specific labels or statuses"
    input_schema:
      type: "object"
      properties:
        jql:
          type: "string"
          description: "Jira Query Language string"
    sandbox:
      image: "ghcr.io/your-org/jira-fetcher:v1.8"
      cpu: "0.5"
      memory: "1Gi"
      timeout: "120"
      secrets:
        - "jira_api_token"
        - "jira_base_url"

  - name: "generate_roadmap_item"
    description: "Generate a structured product roadmap item from analysis"
    input_schema:
      type: "object"
      properties:
        pain_point:
          type: "string"
          description: "The core user pain point identified"
        evidence:
          type: "array"
          items:
            type: "object"
            properties:
              source:
                type: "string"
                description: "e.g., 'Intercom: conv_abc123', 'Jira: PROJ-456'"
              summary:
                type: "string"
        priority_score:
          type: "number"
          description: "0-100 score based on frequency and severity"
    # 这个 tool 不需要 sandbox，因为它只是格式化输出
    # Anthropic 会直接在 harness 层执行
    inline: true

# 安全护栏：防止 agent 走偏的硬性约束
guardrails:
  # 禁止访问任何未声明的外部服务
  disallowed_domains:
    - "*"
  # 强制所有输出必须是 JSON，且符合 generate_roadmap_item 的 schema
  output_validation:
    tool_name: "generate_roadmap_item"
    enforce_schema: true
  # 会话最大时长，防止无限循环
  max_session_duration_seconds: 1800  # 30 minutes

这个 YAML 文件，就是你 agent 的“宪法”。它被上传到 Anthropic 控制台后，会触发一系列自动化流程：语法校验、schema 验证、sandbox 镜像预拉取、vault 凭证绑定、权限策略生成。一旦通过，你就可以用 POST /agents API 创建一个 agent 实例。关键点在于：

• sandbox 配置是强制的 ：每个外部 tool 必须指定 image 、 cpu 、 memory 、 timeout 。没有“默认配置”，没有“继承父级”。这确保了资源消耗可预测、可计费。
• secrets 是声明式的 ：你只告诉 Anthropic “我需要哪些 secret”，它负责安全地注入到 sandbox 的 IPC 通道里。sandbox 内部进程永远无法通过 os.environ 或 cat /proc/self/environ 看到它们。
• guardrails 是不可绕过的 ： disallowed_domains 是 DNS 层的硬拦截， output_validation 是在 harness 层做的 JSON Schema 校验， max_session_duration_seconds 是由 session manager 强制终止。这些不是模型层面的 soft constraint，而是基础设施层的硬熔断。

注意：YAML 里的 version: "2026-04-01" 不是随意写的。它对应 Anthropic 的 API 版本和 runtime 行为规范。如果你升级了 Anthropic 的 SDK，但 YAML version 没变，那么你的 agent 行为不会改变。这是保证生产环境稳定性的关键设计。

3.2 启动、调试与监控：Session ID 是你的新身份证

在 Managed Agents 里， session_id 是一切操作的起点。它不像传统 Web 会话 ID 那样只是一个随机字符串，而是一个承载了完整上下文的、可追踪的、可审计的实体标识符。

启动一个新 session 的 API 调用非常简单：

curl -X POST \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "agent_id": "agnt_fdbk_anlzr_prod_123",
    "initial_input": "Analyze feedback about 'API latency' from last 7 days"
  }' \
  https://api.anthropic.com/v1/sessions

响应会立即返回：

{
  "session_id": "sess_fdbk_20260408_abc123",
  "status": "running",
  "created_at": "2026-04-08T14:22:15.123Z",
  "expires_at": "2026-04-09T14:22:15.123Z"
}

这个 session_id 就是你后续所有操作的钥匙。你可以用它来：

• 实时获取状态 ： GET /v1/sessions/{session_id}/status
• 拉取完整事件流 ： GET /v1/sessions/{session_id}/events?limit=100&from_sequence=50
• 强制唤醒或暂停 ： POST /v1/sessions/{session_id}/awake 或 POST /v1/sessions/{session_id}/pause
• 导出为审计报告 ： GET /v1/sessions/{session_id}/export?format=pdf

调试体验和以前完全不同。过去，你要在 LangChain 的 CallbackHandler 里埋点，看 on_tool_start 、 on_llm_end 的日志，还要自己拼接 context。现在，你只需要打开一个终端，执行：

# 实时 tail 事件流（类似 tail -f）
watch -n 1 'curl -s -H "x-api-key: $KEY" "https://api.anthropic.com/v1/sessions/sess_fdbk_20260408_abc123/events?limit=10" | jq ".events[] | {type, tool_name, status, timestamp}"'

你会看到一行行清晰的事件：

{"type":"tool_call","tool_name":"fetch_intercom_conversations","status":"success","timestamp":"2026-04-08T14:23:01Z"}
{"type":"tool_call","tool_name":"fetch_jira_tickets","status":"success","timestamp":"2026-04-08T14:23:45Z"}
{"type":"tool_call","tool_name":"generate_roadmap_item","status":"success","timestamp":"2026-04-08T14:24:22Z"}

如果某一步失败了，比如 fetch_jira_tickets 返回了 401 Unauthorized ，事件流里会明确记录：

{
  "type": "tool_call",
  "tool_name": "fetch_jira_tickets",
  "status": "failed",
  "error": {
    "code": "AUTH_ERROR",
    "message": "Invalid Jira API token",
    "details": "HTTP 401 from Jira API"
  },
  "timestamp": "2026-04-08T14:23:45Z"
}

你不需要猜是网络问题还是 token 过期，错误详情里已经包含了 HTTP 状态码和原始响应。这就是“可观测性”从口号变成现实的瞬间。

3.3 生产部署与成本控制：$0.08/小时背后的精算逻辑

Managed Agents 的定价模型是 $0.08 per session-hour of active runtime ，外加标准的 Claude token 费用。这个“session-hour”不是指 session 的存活时间，而是指 harness 实际在执行 tool calls 或等待模型响应的 CPU 时间总和 。这是一个极其精细、对开发者友好的计费粒度。

我们来算一笔账。假设你的 feedback-analyzer-prod agent 在一个典型 session 中：

• fetch_intercom_conversations : sandbox 运行 42 秒
• fetch_jira_tickets : sandbox 运行 38 秒
• generate_roadmap_item : inline 执行，耗时 1.2 秒（不计入 session-hour）
• harness 等待模型响应：平均 8.5 秒（模型推理时间不计入 session-hour）
• harness 自身调度、序列化、日志写入：约 0.3 秒

那么这个 session 的 active runtime 是 42 + 38 + 0.3 = 80.3 秒 ≈ 0.0223 小时 。费用是 0.0223 * $0.08 = $0.00178 ，约 0.18 美分 。再加上 Claude 3.5 的 token 费用（假设输入 2000 tokens，输出 500 tokens，按 $0.015/1K input, $0.075/1K output 计算），总成本约 $0.0078 ，也就是 0.78 美分 。

这个成本结构，彻底改变了你的架构决策。过去，为了省钱，你会拼命优化 prompt，减少 tool calls，把多个步骤合并成一个大请求，结果牺牲了可维护性和可观测性。现在，你可以大胆地把逻辑拆得更细： fetch_intercom_conversations_by_sentiment 、 fetch_jira_tickets_by_priority 、 cross_reference_sources ……每个都是独立的、可测试的、可计费的单元。因为拆分带来的额外成本，可能只有几美分，而它换来的是：故障定位时间从小时级降到秒级，A/B 测试新工具的成本从部署新服务降到修改 YAML，审计合规的难度从“写几百页文档”降到“导出一个 PDF”。

但要注意一个陷阱： session 的“活跃”状态是有心跳机制的 。Harness 默认每 30 秒会向 session manager 发送一个心跳。如果连续 3 次心跳失败（比如你的网络断了），session 会被标记为 inactive ，停止计费。但 session 数据依然保留，直到 expires_at 。你可以随时用 awake(sessionId) 让它恢复。这意味着，如果你的 agent 需要长时间等待用户输入（比如一个客服 bot），你应该在用户输入到达前，先用 POST /v1/sessions/{id}/pause 主动暂停 session，避免空转计费。这是一个需要在应用层主动管理的细节，也是 Managed Agents 对开发者提出的新要求：你不仅要懂 AI，还要懂基础设施的“呼吸节奏”。

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

4.1 不是 Anthropic 在开创，而是在防御：AgentCore 的五个月领先优势

媒体把 Anthropic Managed Agents 的发布描绘成一场“AI agent 操作系统”的革命。但如果你翻开 AWS 的发布日志，会发现一个被集体忽略的事实： Amazon Bedrock AgentCore 在 2025 年 11 月就已进入 GA（General Availability）阶段，比 Anthropic 早了整整五个月 。截至 2026 年 3 月，AgentCore 的 SDK 下载量已突破两百万次，其配套的 Policy Controls（策略控制）也同步达到 GA。这意味着，一个成熟的、企业级的、与 AWS 生态深度集成的 agent runtime，早已在市场上铺开。

AgentCore 的架构与 Managed Agents 高度相似，但有一个关键差异： 它不绑定任何特定模型 。你可以用 AgentCore 运行 Claude、Llama、Cohere，甚至是你自己微调的模型。它的 session 同样是持久化的事件日志，sandbox 同样是 microVM，credential 隔离同样通过 AWS Secrets Manager 实现。唯一的区别是，AgentCore 的定价模型是 免费 ——它不单独收取 session-hour 费用，而是作为 Bedrock 服务的一部分，其成本已摊销在你的整体 AWS 账单里。

这构成了 Anthropic 当前最真实的处境： 它不是在定义一个新市场，而是在一个已被巨头免费提供的基础设施上，试图建立一个付费的、模型锁定的替代方案 。这就像 2005 年 VMware 在卖 ESX 时，面对的是 Red Hat Enterprise Linux 里自带的 Xen，以及后来 Linux 内核原生的 KVM。技术上，ESX 更成熟、功能更丰富；但市场上，开源方案的“免费”属性，加上云厂商的“捆绑”策略，最终压倒了所有技术优势。

Anthropic 的应对策略很清晰： 用 Claude 的模型优势，反向拉动 runtime 的采用 。他们知道，对于那些已经深度依赖 Claude 的客户（比如 Notion、Rakuten），切换到 AgentCore 意味着要重新适配 prompt、重写 tool wrappers、重构监控体系。这个迁移成本，可能远高于每年几万美元的 Managed Agents 费用。所以 Anthropic 的定价 $0.08/session-hour ，本质上是一个“忠诚度溢价”——它不是 runtime 的公允价格，而是你为继续使用 Claude 所支付的“便利税”。

提示：如果你的公司已经在用 Bedrock，评估 Managed Agents 时，不要只比 $0.08 和 free ，而要算总拥有成本（TCO）。包括：现有 Bedrock agent 的维护人力、prompt 工程的迭代成本、debugging 失败 session 的时间成本、以及未来可能产生的 vendor lock-in 成本。很多时候，“免费”的 runtime，其隐性成本远高于一个透明的、可预测的付费方案。

4.2 价值正在向上迁移：Trace Store、Governance、Vertical Marketplaces 的崛起

当 runtime 层开始 commoditize（商品化），价值必然向上游迁移。历史已经多次证明这一点：当虚拟化成为云的默认能力，价值迁移到了 Terraform（基础设施即代码）、Kubernetes（容器编排）、Service Mesh（服务治理）；当数据库成为云服务，价值迁移到了 Fivetran（数据集成）、dbt（数据转换）、Superset（数据可视化）。

在 agent 栈中，价值迁移的三个方向已经非常清晰：

4.2.1 Trace Store：成为 agent 行为的“唯一真相源”

目前市场上有三家公司在激烈争夺这个位置：Braintrust 的 Brainstore、Arize 的 Phoenix、LangChain 的 LangSmith。它们的核心竞争点，不是谁的 UI 更好看，而是谁的 trace 数据模型更通用、谁的导入导出能力更强、谁的 schema 更能兼容不同 runtime 的事件格式。

以 Brainstore 为例，它不是一个简单的日志查看器。它是一个专为 AI interaction logs 设计的 OLAP 数据库，支持对 tool_call 事件进行亚秒级的多维分析：

• “过去 24 小时， fetch_jira_tickets 工具的平均延迟是多少？P95 是多少？哪个 JQL 查询最慢？”
• “ generate_roadmap_item 的输出，有多少比例被产品经理手动修改过？修改集中在哪些字段？”
• “对比使用 Claude 3.5 和 Claude 4 的两个 agent，它们在相同 fetch_intercom_conversations 输入下的 pain_point 识别准确率差异是多少？”

这些问题的答案，无法从 Anthropic 的 /events API 里直接得到，因为那是原始日志流。你需要一个专门的、可分析的、可关联的 trace store。而 Brainstore 的价值，就在于它能把来自 Anthropic、Bedrock、Vertex、甚至你自建的 LangChain agent 的 trace 数据，统一摄入、标准化、建模，然后提供一个统一的查询接口。 它不关心你用的是哪家的 runtime，只关心你的 agent 做了什么。它是 runtime 迁移时，唯一能无缝带走的资产 。

4.2.2 Governance & Policy：从“能做什么”到“应该做什么”

AWS AgentCore 在 2026 年 3 月 GA 的 Policy Controls，标志着 agent 治理正式进入企业采购清单。这些 policy 不再是简单的“禁止访问外部网站”，而是深入到业务逻辑层：

• 数据主权策略 ： "All tool calls that read PII must route through our internal DLP gateway"
• 成本管控策略 ： "No single session may consume more than $5 worth of compute resources"
• 合规审计策略 ： "Every 'generate_roadmap_item' output must be signed by a human approver before being sent to Jira"

OWASP Agentic Top 10 的发布，更是将这类策略从“最佳实践”提升到了“安全基线”。它明确列出了 Insecure Tool Integration （不安全的工具集成）、 Overprivileged Agents （权限过大的 agent）、 Insufficient Input Sanitization （输入净化不足）等十大风险。这意味着，一个没有内置 policy engine 的 agent runtime，在大型企业眼里，已经不是一个“可用”的产品，而是一个“待修复的安全漏洞”。

4.2.3 Vertical Agent Marketplaces：从“通用 agent”到“行业 agent”

Salesforce 的 Agentforce ARR 达到 8 亿美元，这个数字背后是一个残酷的现实： 企业愿意为能解决具体业务问题的 agent 付费，而不是为一个能“调用工具”的通用框架付费 。Agentforce 的成功，不在于它有多快的 sandbox，而在于它预装了 Sales-Development-Agent 、 Customer-Success-Agent 、 CPQ-Configurator-Agent ，每一个都经过 Salesforce 内部销售、CSM、实施顾问的联合打磨，能直接嵌入客户的 Sales Cloud 工作流。

开源社区也在加速这个进程。 virattt/ai-hedge-fund 项目，已经能根据实时新闻和财报数据，自动生成对冲基金的交易信号； vxcontrol/pentagi 则是一个面向红队的 agent，能自动规划渗透测试路径、选择 exploit、利用漏洞、并生成符合 MITRE ATT&CK 的报告。这些不是玩具，而是正在被真实使用的、垂直领域的生产力工具。

注意：这些 vertical agent 的核心，并不在于它们用了多先进的模型，而在于它们封装了深厚的领域知识（domain knowledge）。一个金融 agent 的价值，90% 来自它对 SEC filings、10-K 报告结构、期权希腊字母的理解；一个安全 agent 的价值，90% 来自它对 CVE 数据库、Nmap 扫描结果、Metasploit 模块的熟悉程度。这才是真正的、难以被 runtime commoditization 冲击的壁垒。

5. 实战避坑指南：从早期 adopter 身上总结的 7 个血泪教训

5.1 教训一：别把 YAML 当配置文件，它就是你的生产代码

很多团队在初期会把 agent YAML 当作一个“配置项”，放在 config/ 目录下，和 database.yml 、 redis.yml 放在一起。这是大忌。YAML 定义了你的 agent 的行为契约，它和你的 Python 代码一样重要，甚至更重要——因为它是 runtime 层的唯一输入。我们团队就吃过亏：一个 junior engineer 在紧急修复一个 bug 时，直接在生产环境的控制台里编辑 YAML，删掉了一个 guardrails 规则，结果导致 agent 开始调用未授权的内部 API，触发了安全警报。

正确做法 ：

• 将 agent YAML 纳入 Git 仓库，和应用代码同目录（如 src/agents/feedback_analyzer.yaml ）。
• 建立 CI 流水线，对 YAML 进行静态检查： yamllint 、 jsonschema 验证、 secret 字段是否存在明文。
• 所有生产环境的变更，必须走 Pull Request 流程，至少两人 review。
• 使用 anthropic-cli 工具，在本地 `anthropic agents deploy --dry