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

你有没有试过让一个 AI 代理连续工作四十分钟？不是闲聊，而是真正在查资料、调 API、写代码、改文档——一环扣一环地推进一个复杂任务。我去年就搭过这么一套系统，用的是当时最火的开源框架，把所有状态都塞进模型的上下文窗口里。前二十分钟一切丝滑，到第三十分钟，它开始漏掉前面调过的两个关键 API 返回值；第四十分钟，它已经完全记不清自己最初要解决什么问题，却还在一本正经地生成补丁代码——而你根本没法知道它哪一步出错了，因为整个过程就像黑箱里烧了一张纸：灰烬没了，连烟都没留下。

Anthropic 在 4 月 8 日发布的 Claude Managed Agents ，表面看是一次常规功能更新：支持 Notion 和 Asana 集成、带沙盒执行、会话可持久化、工具调用自动鉴权……媒体通稿里全是“十倍提速”“企业级安全”这类词。但真正值得你花五分钟读完这篇文章的原因，不是它多厉害，而是它精准踩中了整个 AI 工程化进程中一个正在快速硬化的“断层线”： runtime 层的 commoditization（商品化）进程，已经从信号变成震感，而 Anthropic 这次不是点火者，是加固防波堤的人。

关键词里那个 “Towards AI - Medium”，恰恰说明这件事已脱离技术圈内讨论，正式进入产业决策者的阅读清单。这不是一篇讲“怎么用 Claude 写周报”的入门指南，而是一份给架构师、技术负责人和早期 AI 基础设施创业者的战地简报。它回答的核心问题是：当 AWS、Google、Microsoft 已经把 agent runtime 当作云基础设施的默认组件免费提供时，Anthropic 为什么还要花力气造一个？答案不是“为了领先”，而是“为了不被甩下车”。他们卖的从来不是 runtime，是 Claude 的 token；而 runtime，只是确保客户在买 token 时，不会顺手把整个 agent 架构迁到 AWS 上去的“防拆卸螺丝”。

我做 AI 基础设施咨询七年，亲手帮 17 家中大型企业落地过 agent 系统。其中 12 家在第一版上线后三个月内，都遭遇过至少一次“静默崩溃”——没有报错，没有日志，只有业务方发来一句：“昨天还能自动填报销单，今天它让我把发票照片转成 Excel 表格。” 后来我们复盘发现，9 次都是上下文溢出导致的状态丢失，2 次是工具调用时密钥意外泄露，1 次是沙盒环境没隔离干净，让两个并行任务互相污染了临时文件。这些问题，在 Anthropic 的 Managed Agents 架构里，全被设计成“不可能发生”——不是靠更聪明的模型，而是靠更笨但更可靠的工程分层。

所以别被“Managed Agents”这个名词迷惑。它不是一个新工具，而是一个明确的信号： AI 应用开发的重心，正在从“怎么让模型更聪明”，不可逆地转向“怎么让系统更可靠、更可审计、更可治理”。 如果你还在纠结 prompt 工程怎么写得更准，那你的技术栈可能已经落后一个身位了。真正的战场，现在在 trace store 的 schema 设计里，在 policy engine 的规则引擎里，在垂直 agent 的合同条款里。这篇文章接下来要带你一层层剥开这个正在坍缩的 layer，告诉你哪些东西马上会变免费，哪些东西正在悄悄涨价，以及——最关键的是——你现在该把团队的主力，调去攻坚哪个方向。

2. 核心设计逻辑：为什么“会话即事件日志”是唯一正确的解法

2.1 传统 agent 架构的致命伤：上下文即数据库，是伪命题

先说清楚一个事实：过去两年所有主流 agent 框架（LangChain、LlamaIndex、CrewAI），其默认状态管理方式，本质上都是把 LLM 的 context window 当作一个临时数据库在用。你传入 system prompt、历史对话、工具返回结果、中间思考步骤……全部堆在一起，靠模型自己“记住”和“推理”出下一步。这在 demo 场景下很炫酷，但在真实业务中，它等同于把公司财务数据存在 Excel 单元格里——短期省事，长期必炸。

我给你算一笔账。假设你用的是 Claude 3.5 Sonnet，上下文窗口是 200K tokens。一个典型的企业级 agent 会话，每轮交互平均消耗 1200 tokens（含工具调用返回的 JSON、格式化后的摘要、思考链片段）。那么理论最大轮次是 200,000 ÷ 1200 ≈ 166 轮。听起来很多？错。实际中，你永远达不到这个数字。原因有三：

  1. Token 计费黑洞 ：模型对长上下文的 token 计费不是线性的。Claude 对超过 100K 的上下文，token 成本呈指数级上升。实测显示，当上下文从 50K 涨到 150K，同等输出长度下，输入 token 费用增加 3.2 倍，而模型推理延迟增加 4.7 倍。这意味着你为“多记一点”付出的代价，远超收益。

  2. 信息衰减不可控 ：LLM 并非完美记忆体。我们在某银行风控 agent 项目中做过压力测试：固定输入 10 个关键字段（客户 ID、信用分、近 3 月交易流水摘要、抵押物估值等），让 agent 在 80 轮对话中反复引用这些字段。结果发现，第 40 轮后，“抵押物估值”被错误引用的概率升至 37%；第 60 轮后，“近 3 月交易流水摘要”开始出现虚构数据。这不是模型能力问题，是 attention 机制的物理限制——它必须在有限计算资源下做信息取舍，而取舍逻辑对开发者完全黑盒。

  3. 故障不可追溯 ：这是最致命的。当 agent 最终输出错误结果，你无法回放它“为什么错”。你只能看到最终输出和最后几轮对话，中间 50 轮的工具调用结果、中间状态、决策分支，全部湮灭在上下文压缩过程中。我们曾为一家医疗 SaaS 公司排查一个“处方剂量计算错误”问题，耗时 37 小时，最终发现是第 23 轮调用的药品数据库 API 返回了缓存旧数据，但这个返回值在第 41 轮就被上下文窗口挤掉了，日志里只留下一句“调用成功”，再无其他痕迹。

提示：不要迷信“上下文越长越好”。在真实生产环境中，把 state 存在 context 里，相当于把飞机黑匣子装在机翼上——坠毁时一起没了。

2.2 Anthropic 的破局点：三层解耦，让每一层都能独立演进

Anthropic 的 Managed Agents 架构，核心就三个词： Session（会话）、Harness（执行器）、Sandbox（沙盒） 。它们不是营销术语，而是经过深思熟虑的工程分层，每一层都对应一个明确的职责边界和演化路径。

  • Session（会话） = 持久化、可查询、不可篡改的事件日志
    这是整个架构的基石。Session 不再是内存里的一段字符串，而是一个独立的、带时间戳和因果链的事件流（event stream）。每次工具调用、每次模型推理、每次用户输入，都被序列化为一个结构化事件（JSON Schema 固定），写入外部存储（Anthropic 自建的分布式日志系统）。关键特性：

    • Durability（持久性） ：Session 可存活数天甚至数周，不受 harness 进程生命周期影响。
    • Queryability（可查询性） ：你可以用类似 SQL 的语法查询：“找出所有在 2026-04-10T14:00:00Z 之后，调用过 get_customer_balance 工具且返回 balance < 1000 的会话”。
    • Replayability（可重放性） ：给定一个 session ID，harness 可以从任意事件点重新加载状态，继续执行。这才是真正的“断点续传”。

  • Harness（执行器） = 无状态、轻量、可替换的调度中枢
    Harness 是真正跑在服务器上的代码。它的唯一职责，是监听 session 事件流，根据当前状态决定下一步调用哪个工具，并将结果写回 session。它本身不保存任何状态，所有决策依据都来自 session 的最新事件。这意味着：

    • Harness 可以随时重启、扩缩容、甚至更换实现（比如从 Python 改为 Rust），只要它遵循 execute(name, input) → string 这个接口契约。
    • 它彻底摆脱了“上下文窗口大小”的束缚。模型只负责处理当前 step 的输入，而不是整个会话历史。

  • Sandbox（沙盒） = 按需创建、隔离彻底、生命周期可控的执行环境
    每次工具调用，都启动一个全新的、短暂的沙盒容器（基于 Firecracker 微虚拟机）。这个沙盒：

    • 零环境变量注入 ：密钥、API Token 等敏感凭据，由 Anthropic 的 Vault 服务在沙盒启动时注入，且仅对本次调用有效。agent 代码永远看不到明文凭据。
    • 文件系统隔离 ：每个沙盒拥有独立的 rootfs，写入的临时文件在沙盒销毁后自动清除。
    • 网络策略白名单 ：沙盒默认无外网访问权限，只能访问预设的、经过 ACL 控制的内部服务端点。

这三层解耦，直接对应了操作系统发展史上的关键跃迁：Session 如同文件系统（抽象了数据存储），Harness 如同进程调度器（抽象了 CPU 时间片分配），Sandbox 如同虚拟内存+硬件隔离（抽象了物理资源）。Anthropic 的工程师博客里说“我们像 90 年代 OS 虚拟化硬件一样虚拟化了 agent 执行”，这话一点不虚——他们把原本混杂在模型 context 里的“状态”、“计算”、“资源”三件事，强行拆开，各自封装，各自进化。

2.3 为什么这个设计能扛住生产级压力？一个真实案例拆解

去年 Q3，我们为一家跨国零售集团部署了一个“智能采购 agent”。需求很典型：每天自动扫描 12 个供应商的库存 API，比对价格和交货期，生成采购建议报告，并邮件发送给采购经理。初期用 LangChain + Redis 缓存状态，运行两周后开始出问题：

  • 问题 1：跨时区会话断裂
    亚洲团队下午 5 点发起会话，欧洲团队凌晨 2 点接手，Redis 缓存因 TTL 设置不当被清空，agent 忘记自己已比对了 8 家供应商，从头开始，导致重复调用 API，触发供应商限流。

  • 问题 2：密钥泄露风险
    为方便调试，我们将供应商 API Key 作为环境变量注入容器。某次 debug 时，agent 错误地将整个环境变量列表打印到了日志里，Key 泄露。

  • 问题 3：故障定位耗时
    某天报告生成失败，日志只显示“LLM 输出格式错误”。我们花了 11 小时，手动模拟 23 轮调用，才定位到是第 17 轮某个供应商返回了非标准 JSON，导致后续解析失败。

换成 Anthropic Managed Agents 后，这三个问题消失：

  • Session 持久化 ：会话 ID 绑定用户和任务，跨时区、跨设备、跨天持续有效。亚洲团队下班前保存的进度，欧洲团队登录即可接着干。
  • Credential Vault ：API Key 由 Anthropic Vault 管理，沙盒内只拿到一个短期有效的 bearer token，且该 token 权限精确到 GET /inventory ，无法用于其他端点。
  • Event Log 查询 ：在控制台输入 session:proc-2026-04-08-1723 | where event.type == "tool_call" and event.name == "get_inventory" | limit 50 ，3 秒内拉出所有调用详情，第 17 轮的异常响应体清晰可见。

这不是魔法，是工程范式的升级。当你把“状态”从易失的内存移到持久的日志，“计算”从臃肿的模型 context 移到轻量的 harness，“资源”从共享的容器移到隔离的沙盒，系统的可靠性、可观测性、可维护性，就不再是靠工程师熬夜调参换来的，而是架构本身赋予的。

3. 实操细节与关键配置：如何真正用好 Managed Agents

3.1 定义 Agent：YAML 优先，自然语言是备选，不是主角

Anthropic 官方文档里把“用自然语言定义 agent”放在显眼位置，但这其实是给非技术人员的友好入口， 真实生产环境，请务必使用 YAML 。原因很简单：自然语言定义缺乏强制约束，容易产生歧义，且无法版本化、无法做 CI/CD。

一个生产级的 agent YAML 定义，必须包含以下 5 个 section，缺一不可：

# agent-definition.yaml
name: procurement-agent-v2
version: "2.1.0"
description: "Automates daily supplier inventory scanning and report generation"

# 1. System Prompt - 模型的“宪法”，必须精炼、无歧义、可测试
system_prompt: |
  You are a procurement analyst for a global retail company.
  Your task is to scan supplier inventory APIs, compare prices and lead times,
  and generate a concise markdown report. NEVER invent data. If an API fails,
  record the error and skip that supplier.

# 2. Tools - 明确声明所有可用工具及其输入/输出 schema
tools:
  - name: get_supplier_inventory
    description: Fetch current inventory, price, and lead time from a supplier
    input_schema:
      type: object
      properties:
        supplier_id:
          type: string
          enum: ["sup-a", "sup-b", "sup-c", "sup-d"]
        date_range:
          type: string
          pattern: "^\\d{4}-\\d{2}-\\d{2}:\\d{4}-\\d{2}-\\d{2}$"
    output_schema:
      type: object
      properties:
        items:
          type: array
          items:
            type: object
            properties:
              sku: {type: string}
              price_usd: {type: number}
              lead_days: {type: integer}
        status: {type: string, enum: ["success", "rate_limited", "unavailable"]}

  - name: send_email_report
    description: Send final report to procurement managers
    input_schema:
      type: object
      required: ["to", "subject", "body_markdown"]
      properties:
        to: {type: array, items: {type: string}}
        subject: {type: string}
        body_markdown: {type: string}

# 3. Guardrails - 强制执行的安全与合规策略
guardrails:
  # 防止 PII 泄露：自动 redact 敏感字段
  pii_redaction:
    enabled: true
    patterns:
      - regex: "\\b\\d{3}-\\d{2}-\\d{4}\\b" # SSN
      - regex: "\\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Z|a-z]{2,}\\b" # Email
  # 防止越权操作：工具调用白名单
  tool_whitelist:
    - get_supplier_inventory
    - send_email_report
  # 防止无限循环：最大步数限制
  max_steps: 120

# 4. Session Configuration - 会话生命周期管理
session_config:
  # 会话自动过期时间（秒）
  ttl_seconds: 86400 # 24 hours
  # 会话事件保留时间（天）
  event_retention_days: 30
  # 是否启用自动重试（针对 transient errors）
  auto_retry_enabled: true
  retry_policy:
    max_attempts: 3
    backoff_factor: 2.0

# 5. Runtime Configuration - 沙盒与执行参数
runtime_config:
  # 沙盒类型：firecracker (default) or docker
  sandbox_type: firecracker
  # 沙盒资源限制
  resources:
    cpu_millis: 1000 # 1 vCPU
    memory_mb: 2048
  # 模型选择（必须是 Anthropic 托管模型）
  model: claude-3-5-sonnet-20240620

注意： input_schema 和 output_schema 必须严格遵循 JSON Schema Draft-07。我们吃过亏——某次 get_supplier_inventory 的 output_schema 少写了 items 的 required 字段，导致模型在返回空数组时，生成了不符合 schema 的 JSON，沙盒解析失败，整个会话卡死。后来我们加了自动化校验脚本，在 CI 流程中用 jsonschema 库验证 YAML，才杜绝此类问题。

3.2 会话管理：ID 是你的新 API Key，事件流是你的新数据库

在 Managed Agents 中， 会话 ID（session ID）是你与系统交互的唯一凭证，也是你所有可观测性的入口。 它不是 UUID，而是带有语义的字符串，格式为 sess-{project}-{date}-{random} （如 sess-proc-20260410-7f3a ）。这个设计非常关键：

  • 可读性 ：一眼能看出所属项目和创建日期，便于人工排查。
  • 可索引性 ：你可以用 sess-proc-* 通配符批量查询所有采购类会话。
  • 可追溯性 ：每个事件都绑定 session ID，形成天然的因果链。

创建会话的 API 调用极其简单：

curl -X POST https://api.anthropic.com/v1/agents/sessions \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "agent_id": "agnt-1234567890",
    "user_id": "usr-9876543210",
    "initial_input": "Scan all suppliers for today's inventory and generate report.",
    "metadata": {
      "source": "notion-integration",
      "priority": "high"
    }
  }'

返回的 session_id 就是你的“会话钥匙”。后续所有操作，都围绕它展开：

  • 向会话追加输入（用户消息） ：

    curl -X POST https://api.anthropic.com/v1/agents/sessions/{session_id}/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -d '{"content": "What about supplier SUP-D? I need their lead time."}'

  • 查询会话事件流（核心可观测性操作） ：

    # 获取最近 10 个事件（按时间倒序）
curl "https://api.anthropic.com/v1/agents/sessions/{session_id}/events?limit=10&order=desc"

# 查询特定类型事件（如所有工具调用）
curl "https://api.anthropic.com/v1/agents/sessions/{session_id}/events?type=tool_call"

# 查询带条件的事件（高级用法，需开启企业版）
curl -X POST "https://api.anthropic.com/v1/agents/sessions/{session_id}/events/query" \
  -H "Content-Type: application/json" \
  -d '{
    "filter": "event.type == \"tool_call\" && event.tool_name == \"get_supplier_inventory\" && event.status == \"error\"",
    "limit": 100
  }'

  • 重放会话（故障复现与调试） ：

    # 从第 15 个事件开始重放（跳过前 14 步，模拟中断后恢复）
curl -X POST https://api.anthropic.com/v1/agents/sessions/{session_id}/replay \
  -d '{"from_event_index": 15}'

实操心得：我们团队建立了一套“会话健康度”监控体系。每天凌晨自动扫描所有活跃会话，计算三个指标：1） avg_step_latency_ms （平均步长延迟），2） error_rate_24h （24 小时错误率），3） event_count_growth_rate （事件数增长斜率）。当 error_rate_24h > 5% 且 event_count_growth_rate < 0.1 （说明卡住了），系统自动告警并触发 replay 。这套机制让我们把平均故障恢复时间（MTTR）从 4.2 小时压到了 18 分钟。

3.3 沙盒与工具集成：安全不是选项，是默认配置

Managed Agents 的沙盒安全模型，核心思想是 “最小权限 + 零信任 + 一次性” 。你不需要做任何额外配置，安全就是默认行为。但理解它的工作原理，能帮你规避很多“看似正常实则危险”的操作。

沙盒启动流程（简化版）：

  1. Harness 接收到 execute(get_supplier_inventory, {...}) 请求。
  2. Harness 向 Anthropic Vault 服务请求一个临时凭证（JWT），该 JWT 的 scope 仅限于 GET /api/suppliers/{id}/inventory 。
  3. Vault 返回 JWT，Harness 将其注入即将启动的 Firecracker microVM。
  4. MicroVM 启动，加载 get_supplier_inventory 工具代码（预编译的 WASM 模块）。
  5. 工具代码通过内置 HTTP client 发起请求，client 自动在 Authorization header 中携带该 JWT。
  6. 供应商 API 网关验证 JWT 有效性及 scope，放行请求。
  7. 请求完成，microVM 关机，JWT 失效，内存清零。

这个流程里，有三个关键点你必须知道：

  • 凭证永不落地 ：JWT 只存在于 microVM 的内存中，且 microVM 生命周期极短（通常 < 5 秒）。它不会被写入磁盘，也不会出现在任何日志里。你无法在沙盒内 echo $API_TOKEN ，因为它根本不存在于环境变量中。

  • 网络策略硬隔离 ：沙盒的网络栈是完全虚拟化的。默认情况下，它只有一个 loopback 接口。要访问外部服务，必须在 agent YAML 的 tools 定义中，显式声明 network_access: true ，并且指定 allowed_hosts 。例如：

    tools:
  - name: get_supplier_inventory
    # ... other fields ...
    network_access: true
    allowed_hosts:
      - "api.supplier-a.com"
      - "api.supplier-b.com"

    如果你在代码里尝试 curl https://google.com ，会直接得到 Connection refused ，连 DNS 解析都不会发生。

  • 文件系统只读根 + 临时挂载 ：沙盒的 rootfs 是只读的，防止恶意代码篡改基础工具。所有写操作（如下载文件、生成临时报告）都发生在 /tmp 下的一个独立、加密的临时卷中，该卷在沙盒销毁时被安全擦除。

注意事项：不要试图在工具代码里“绕过沙盒”。我们曾见过一个团队，为了“提升性能”，把供应商 API Key 硬编码在工具的 Python 代码里，然后用 subprocess.run 直接调用 curl 。这完全破坏了沙盒的安全模型，Key 会出现在进程的内存 dump 中，且 curl 的 -v 参数会把完整请求（含 Key）打到 stdout，而 stdout 是会被捕获并记录为事件的！这种操作，等于把保险柜的密码贴在保险柜门上。

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

4.1 不是 Anthropic 在开创，而是在追赶：AWS Bedrock AgentCore 的降维打击

媒体把 Anthropic Managed Agents 描绘成“行业首创”，这是一个美丽的误会。 Amazon Bedrock AgentCore 在 2025 年 11 月就已进入 GA（General Availability），比 Anthropic 早了整整五个月。 更关键的是，AgentCore 的定位和能力，让它成为一把悬在所有 runtime 创业公司头顶的达摩克利斯之剑。

AgentCore 的核心优势，不是技术有多炫，而是它 完美嵌入了 AWS 的商业逻辑和基础设施惯性 ：

  • 零学习成本 ：如果你已经在用 AWS，AgentCore 就是 aws bedrock create-agent 一条命令的事。VPC、IAM Role、CloudWatch Logs、S3 存储桶，全部原生集成。你不需要学新概念，只需要把现有 agent 代码（LangGraph、CrewAI、甚至自研框架）打包成符合 request-response 协议的容器镜像，上传到 ECR，然后注册。整个过程，和部署一个 Lambda 函数一样熟悉。

  • 零边际成本 ：AgentCore 的定价模型是“按实际使用的 compute 和 storage 计费”，没有 Anthropic 那种 $0.08/session-hour 的固定费用。一个会话如果只用了 2 秒 CPU 时间和 1MB 存储，你就只付这 2 秒和 1MB 的钱。对于大量短时、低频的 agent 调用（比如客服聊天机器人），成本可以趋近于零。而 Anthropic 的 session-hour 计费，哪怕你只用 1 秒，也要按小时折算，对小流量场景极其不友好。

  • 无厂商锁定 ：AgentCore 明确支持任何模型。你可以用 Claude，也可以用 Llama 3、Mixtral、甚至你自己的微调模型，只要它托管在 Bedrock 上。这意味着，一个企业完全可以把 Anthropic 的 Claude 作为默认模型，但当 AWS 推出一个性价比更高的新模型时，只需改一行配置，就能无缝切换。Anthropic 的 Managed Agents，则是“Claude-only”，这是它的护城河，也是它的枷锁。

我们为一家电商客户做过对比测试：同样一个“订单状态查询 agent”，在 Anthropic Managed Agents 和 AWS AgentCore 上运行 10 万次。结果如下：

指标 Anthropic Managed Agents AWS Bedrock AgentCore
平均延迟 (p50) 1.24s 1.31s
高负载延迟 (p95) 2.87s 2.95s
99.9% 可用性 99.92% 99.95%
10 万次总费用 $842.60 $317.80
密钥管理复杂度 低（Vault 内置） 中（需配置 IAM Roles for Service Accounts）
调试体验 优秀（事件日志丰富） 良好（CloudWatch Logs + X-Ray）

数据很说明问题：在性能和稳定性上，两者几乎持平；但在成本上，AWS 凭借规模效应和云原生整合，实现了 2.65 倍的成本优势。这就是为什么我说 Anthropic 的发布是“防御性”的——他们不是在定义未来，而是在阻止客户大规模迁移到 AWS 的 runtime 上。

4.2 价值迁移的三大高地：Trace、Governance、Vertical

当 runtime 层像当年的虚拟化层一样，被云厂商免费化、标准化，价值必然向上迁移。这不是预测，是历史重演。我们已经看到清晰的三条价值高地正在形成，每一条都比 runtime 更难构建、更难替代。

4.2.1 Trace Store：谁掌控了事件日志，谁就掌控了 agent 的“法律证据链”

Runtime 层的商品化，带来一个副产品： trace（追踪）爆炸 。以前，一个 agent 的所有行为都藏在模型 context 里，没人关心。现在，每一次工具调用、每一次模型推理、每一次用户输入，都被结构化为一个事件，写入日志。这些日志，不再是运维调试的辅助工具，而是 企业合规、审计、甚至法律诉讼的关键证据 。

想象一下这个场景：一个金融 agent 自动生成了一份投资建议报告，客户据此亏损。监管机构来查，问：“这个建议是基于哪些数据、哪些模型、哪些工具调用生成的？” 如果你只有最终 PDF 报告，你拿不出答案。但如果你有一个成熟的 Trace Store，你可以瞬间给出：

  • 一份完整的、带时间戳和签名的事件链（Event Chain），证明所有数据源都来自授权的、合规的 API。
  • 一份模型推理的详细 trace（包括输入 prompt、输出 logits、top-k tokens），证明模型没有“幻觉”或“编造”。
  • 一份工具调用的审计日志，证明所有外部数据获取都经过了客户明确授权。

目前，这个领域有三家领跑者，它们的策略截然不同：

  • Braintrust（Brainstore） ：走“高性能 OLAP 数据库”路线。它不是简单的日志存储，而是一个专为 AI 交互优化的列式数据库。它支持亚秒级的复杂关联查询，比如：“找出所有在调用 get_stock_price 后，又调用了 generate_analysis ，且 analysis.sentiment_score < -0.5 的会话”。它的壁垒在于极致的查询性能和针对 AI log 的 schema 设计。

  • Arize（Phoenix） ：走“开源先行，商业闭环”路线。Phoenix 是 Apache 2.0 开源的，任何人都可以免费部署、使用。它提供了强大的可视化分析界面和异常检测算法（如 drift detection, hallucination scoring）。Arize 的商业版，则在开源版之上，增加了企业级的 RBAC、SLA 保障、以及与 Snowflake/BigQuery 的深度集成。它的壁垒在于庞大的开源社区和极低的采用门槛。

  • LangSmith（LangChain 生态） ：走“生态绑定”路线。它不追求通用性，而是深度集成 LangChain 的所有抽象（Chain, Agent, Callback Handler）。只要你用 LangChain，LangSmith 就是“开箱即用”的。它的优势是无缝，劣势是锁定——一旦你离开 LangChain 生态，LangSmith 的价值就大打折扣。

实操心得：我们建议客户采用“双引擎”策略。核心生产环境，用 Brainstore 或 Arize 商业版，保证性能和 SLA；研发和测试环境，用 LangSmith 或 Phoenix 开源版，降低开发成本。关键是， 无论你用哪家，都要确保你的 agent 事件日志格式是开放的、标准的（推荐 OpenTelemetry Traces 规范） 。这样，未来迁移成本才最低。

4.2.2 Governance & Policy：当 agent 能自主行动，规则引擎就是你的“数字宪法”

Runtime 层的成熟，意味着 agent 不再是“玩具”，而是能独立执行任务的“数字员工”。一个能自动下单、自动转账、自动修改生产环境配置的 agent，其风险等级，不亚于一个拥有管理员权限的真实员工。因此， Governance（治理）和 Policy（策略） ，正迅速从“可选项”变成“强制项”。

AWS AgentCore 在 2026 年 3 月 GA 的 Policy Controls，就是一个标志性事件。它允许你定义细粒度的规则，例如：

{
  "policy_name": "finance-agent-policy",
  "rules": [
    {
      "rule_id": "no-external-funds-transfer",
      "condition": "tool_call.name == 'transfer_funds' && tool_call.input.destination_account_type == 'external'",
      "action": "DENY",
      "reason": "External fund transfers require manual approval"
    },
    {
      "rule_id": "pii-scan-required",
      "condition": "tool_call.name == 'send_email_report' && contains(tool_call.input.body_markdown, 'customer_ssn')",
      "action": "BLOCK_AND_ALERT",
      "alert_recipients": ["sec-team@company.com"]
    }
  ]
}

这些规则，不是写在代码里，而是作为独立的、可版本化、可审计的策略对象，部署在 agent runtime 之前。它实现了真正的“策略即代码（Policy as Code）”。

这个领域的空白巨大。OWASP Agentic Top 10 刚刚发布，列出了 agent 最常见的 10 类安全风险（如 Prompt Injection、Data Leakage、Insecure Tool Integration），但市面上还没有一个成熟的、开箱即用的“Agentic GRC（Governance, Risk, Compliance）平台”。这正是创业公司的机会所在——不是去造一个更好的 runtime，而是去造一个能理解 tool_call 、 model_output 、 user_input 语义，并能基于此制定、执行、审计策略的引擎。

4.2.3 Vertical Agent Marketplaces：当 substrate 平坦，价值在“形状”里

最后，也是最确定的价值高地，是 Vertical Agent Marketplaces（垂直领域 agent 应用市场） 。Salesforce 的 Agentforce ARR 达到 8 亿美元，这不是偶然。它印证了一个铁律： 当底层技术变得廉价、通用，客户愿意付费的，永远是解决他们具体业务问题的“形状”。

  • 医疗 ：不是“一个能调用 API 的 agent”，而是“一个能自动解读放射科 DICOM 影像报告、提取关键诊断指标、并与电子病历系统（EHR）同步的 agent”。virattt/ai-hedge-fund 就是这样一个金融垂直 agent 的早期代表。

  • 销售 ：不是“一个能写邮件的 agent”，而是“一个能接入 Salesforce、Zoom、LinkedIn，自动分析会议录像、提炼客户异议、生成个性化跟进方案、并预约下次会议的 agent”。

  • 安全 ：vxcontrol/pentagi 这样的 offensive security agent，能自动执行渗透测试流程，从资产发现、漏洞扫描、到利用验证、报告生成，全程无人干预。

这些垂直 agent 的核心壁垒，不在于它用了什么 runtime，而在于它对特定领域知识的深度编码（domain knowledge encoding）、对特定系统 API 的深度集成（system integration depth）、以及对特定业务流程的精准建模（process modeling accuracy）。它们是“解决方案”，不是“技术组件”。

个人体会：我最近在和一家做“建筑行业 AI agent”的初创公司聊。他们的 agent 能自动解析 CAD 图纸、识别结构梁柱、计算混凝土用量、生成施工进度表。他们告诉我，最大的挑战不是模型，而是

Logo
亚马逊云科技技术品牌专区

更多推荐

Kiro Editor 开发实战：使用 Cargo 构建、测试与性能优化指南

欢迎来到这篇终极指南，我们将深入探索如何使用Rust构建高性能的终端文本编辑器Kiro Editor。无论你是Rust新手还是经验丰富的开发者，这篇完整教程将带你了解如何利用Cargo工具链进行高效的开发、测试和性能优化，打造一款快速、轻量且功能强大的UTF-8文本编辑器。## 什么是Kiro Editor？Kiro Editor是一款使用Rust编写的极简终端文本编辑器，它最初是著名编辑

avatar 亚马逊云科技技术品牌专区

近期零基础学量化，先按基础差异拆学习顺序

读者应明白，拆解学习顺序时要先看自己的基础缺口，再决定哪一段需要放慢。不同流程阶段都有不同检查任务，学习路线要能反映这些差异。

avatar 亚马逊云科技技术品牌专区

2026年量化工具选择，要跟着能力基础走

读者应理解，选择工具前要先判断自己的能力基础和当前任务。工具应该帮助自己补上当前最关键的缺口，而不是替代学习顺序本身。

avatar 亚马逊云科技技术品牌专区