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

你有没有试过让一个 AI 代理连续工作四十分钟？不是闲聊，而是真正在查资料、调 API、写代码、改文档——一环扣一环地推进一个复杂任务。去年我带团队搭了一套内部知识协同代理系统，目标很朴素：自动整理每周销售会议纪要，提取客户痛点，生成跟进话术，并同步到 CRM。我们用的是当时最主流的 LangChain + OpenAI 架构，所有状态都靠模型上下文窗口硬扛。前二十分钟一切丝滑，第三十分钟开始，响应变慢；到第三十八分钟，它突然把上周三的客户投诉记录，当成今天刚收到的新需求来处理；第四十分钟，它开始编造根本没开过的 Zoom 会议链接。我们没收到任何报错，日志里只有一行平静的 200 OK 。等我们翻原始 prompt 和中间输出时才发现：上下文满了，模型悄悄把最早几轮 tool call 的结果给“挤掉”了——不是删掉，是覆盖式遗忘。它还记得自己“该做什么”，但彻底忘了“做过什么”。这不是 bug，是架构性失能。

Anthropic 在 4 月 8 日发布的 Claude Managed Agents ，表面看是一次常规功能更新，实则踩中了整个 AI 工程化落地最痛的那个神经末梢： 状态持久化与执行隔离的工业化交付 。它不卖“更聪明的模型”，它卖的是“让聪明不崩盘”的基础设施。关键词不是“Agent”，而是 Managed ——这个词在云计算史里出现过两次：一次是 AWS EC2（2006），一次是 Kubernetes（2014）。它们共同点是：把原本需要工程师手工缝合、反复调试、半夜救火的底层能力，封装成可声明、可审计、可计费的标准化服务。Managed Agents 正是这个逻辑在 agentic 系统上的复现。它解决的不是“能不能做”，而是“能不能天天做、做八小时、做一百个并发、出了问题还能回溯重放”。这和 Towards AI 社区里常讨论的“提示词工程”“RAG 优化”根本不在同一维度——前者是厨师研究火候，后者是给整座厨房装上工业级排烟系统、恒温冷库和食品溯源码。

我特意去翻了 Anthropic 官方工程博客里那张被反复引用的架构图，它没画模型怎么推理，没标 token 吞吐量，而是用三个加粗词框定了核心抽象： Session（会话）、Harness（执行器）、Sandbox（沙箱） 。这不是技术炫技，是明确告诉开发者：“别再把 session state 塞进 context window 里了，别再手写 sandbox 初始化脚本了，别再为每次 tool call 的 credential 注入提心吊胆了。”它把过去一年里我们在生产环境踩过的所有坑，打包成 YAML 文件里几行配置。比如你定义一个 sales-lead-qualifier agent，只需写：

name: sales-lead-qualifier
system_prompt: |
  You are a senior SDR at Acme Corp. Qualify inbound leads by checking CRM, 
  pulling recent support tickets, and scoring fit against ICP. Never share PII.
tools:
  - crm_lookup
  - support_ticket_fetch
  - icp_scoring_api
sandbox:
  image: acme/agent-runtime:v2.1
  memory_limit_mb: 2048
  timeout_seconds: 300

然后 Anthropic 就会为你：

• 自动创建一个隔离的 Linux 容器（不是 Docker，是更轻量的 Firecracker 微虚拟机），内存、CPU、网络全锁死；
• 把 crm_lookup 所需的 OAuth token 从密钥管理服务里安全注入，且 绝不暴露给 agent 进程的环境变量 ，连 printenv 都看不到；
• 每次调用 execute("crm_lookup", {"lead_id": "abc123"}) ，都在全新沙箱里跑，执行完立刻销毁；
• 所有输入、输出、错误、耗时、沙箱 ID 全部记入不可篡改的事件日志，存期默认 90 天，可 SQL 查询。

这才是真正的“托管”。不是帮你部署，是替你承担运维责任。当你在 Slack 里对 Claude 说“帮我分析下 Q1 销售漏斗转化率”，背后发生的是：一个 session 被唤醒 → harness 加载 checkpoint → 沙箱启动 → 调用 BI 工具 → 结果返回 → 日志落库 → 沙箱销毁。整个过程你不用碰一行 infra 代码。这种确定性，才是企业敢把真实业务流程交给 AI 的前提。否则，你永远活在“这次会不会丢数据”的焦虑里。

2. 架构解剖：为什么 Session 必须是事件日志，而不是上下文快照？

2.1 上下文窗口不是数据库，是易失性缓存

先说个反常识的事实： 所有把 session state 存在 LLM context window 里的方案，本质上都是在用 CPU 寄存器当硬盘用 。寄存器快，但容量极小；硬盘慢，但能存十年账本。LLM 的 context window 就是那个寄存器——它设计初衷是承载单次推理所需的临时信息，不是长期状态存储。当你强行往里塞几十轮对话、十几次 tool call 返回的 JSON、三份 PDF 解析文本，就等于在高速缓存里堆满旧报纸，等着某次 GC（模型内部的状态清理机制）把它一把火烧掉。

我拆解过三个主流框架的 context 管理策略：

• LangChain 的 ConversationBufferMemory ：简单粗暴追加，长度超限就切头；
• LlamaIndex 的 ChatEngine ：用向量检索动态召回，但检索本身可能出错，且无法保证历史顺序；
• CrewAI 的 TaskOutput ：依赖用户手动 return ，一旦某个 agent 忘记 return，下游就断链。

它们共同缺陷是： 没有原子性、没有事务、没有版本号、没有回滚点 。而 Anthropic 的 Session-as-Event-Log 模式，直接跳过了这个陷阱。它的 session 不是字符串，而是一个结构化事件流，每条事件带时间戳、事件类型（ tool_call_started , tool_call_succeeded , model_output , error_thrown ）、唯一 trace_id、以及 payload 的 SHA256 校验值。你可以用 SQL 查：“找出所有 crm_lookup 调用失败且发生在 icp_scoring_api 成功之后的 session”，也能用 awake(sessionId) 精确恢复到任意事件点之后的状态。

提示：事件日志的真正威力不在“记录”，而在“可编程”。比如 Sentry 的 debug agent，当它发现线上报错时，会自动触发一个子 session：先调 get_stacktrace ，再调 search_docs ，最后调 generate_patch 。如果第三步失败，它不会重试整个链条，而是直接 awake(sessionId, after_event_id="search_docs_succeeded_789") ，从文档检索成功那一刻继续。这种细粒度控制，是 context window 永远做不到的。

2.2 Harness 是无状态函数，不是有状态服务

很多团队误以为“托管 agent”就是把 LangChain 代码扔上云服务器。这是典型认知偏差。Managed Agents 的 Harness 设计，本质是把 agent 执行抽象成一个纯函数： execute(name, input) → string 。注意，这里没有 state 参数，也没有 context 对象。Harness 本身不保存任何东西，它只做三件事：

1. 接收请求，校验签名和配额；
2. 拉起沙箱，注入工具定义和输入；
3. 等待沙箱返回字符串，原样透传。

所有状态变更，都必须通过 tool call 显式触发，并由沙箱内的工具代码写入外部数据库（如 CRM、Notion、PostgreSQL）。Harness 只是管道工，不碰数据。这种设计带来两个硬性好处：

• 水平扩展无脑 ：增加 Harness 实例数，就像加 Nginx worker，完全无状态，秒级扩缩；
• 故障恢复零成本 ：Harness 进程崩溃？没关系，session 日志还在，下一个 Harness 实例 awake() 就能续上。

对比我们去年自建的 agent 服务：为了实现“断点续跑”，我们不得不在 Redis 里维护一个 session_state:{id} 的哈希表，每个 key 存着当前步骤、上一步输出、重试次数……结果 Redis 成了单点瓶颈，一次网络抖动就导致 30% session 卡死。Anthropic 直接砍掉这个中间层，让状态只存在于两个地方： 事件日志（永久、可靠）和沙箱内存（瞬时、隔离） 。这是典型的“用存储换计算”思维——宁可多存几 MB 日志，也不在运行时多维护一个状态对象。

2.3 Sandbox 是“牛”，不是“宠物”

“Sandbox as cattle, not pets” 这句话在工程博客里只出现一次，却是整套架构最锋利的刀。传统做法是把沙箱当宠物养：给它起名字（ prod-agent-sandbox-v1.2 ），定期打补丁，监控它的 CPU 使用率，给它配专属 IP。Managed Agents 反其道而行之：沙箱是消耗品，用完即焚。每次 execute() 调用，都触发一套全自动流水线：

• 从预置镜像仓库拉取 acme/agent-runtime:v2.1 （已内置所有依赖和安全加固）；
• 启动 Firecracker microVM，分配 2GB 内存、1 vCPU、只读根文件系统；
• 注入本次调用所需的 credentials（从 Vault 动态获取，有效期 5 分钟）；
• 执行工具代码，超时或异常则强制 kill；
• 卸载 microVM，释放所有资源。

整个生命周期平均 1.2 秒，P95 < 2.8 秒。这意味着：

• 零共享状态风险 ：A 用户的 CRM token 绝对不可能泄露给 B 用户；
• 零版本漂移 ：每次执行都用相同镜像，不存在“上次好使这次不行”的诡异问题；
• 零横向移动面 ：即使沙箱内工具存在 RCE 漏洞，攻击者也只有一秒半的时间逃逸到宿主机——Firecracker 的隔离强度比 Docker 高两个数量级。

我们曾用 CVE-2023-27350（一个严重的 Python urllib3 SSRF 漏洞）测试过自建沙箱，攻击者成功发起外网请求；但在 Managed Agents 的沙箱里，同样的 PoC 直接被 microVM 的 eBPF 网络策略拦截，日志里只有一行 DENY outbound to 1.2.3.4:8080 。这就是“cattle”思维的价值：不追求单个沙箱的完美，而追求整个沙箱集群的确定性。

3. 实操指南：从零部署一个合规销售代理（含避坑清单）

3.1 准备工作：账号、权限与最小可行镜像

别急着写 YAML。先确认三件事：

1. Anthropic 账号已开通 Managed Agents Beta 权限 （目前需申请，审核约 2 个工作日）；
2. AWS IAM Role 已配置 anthropic:InvokeAgent 权限 （如果你用 Bedrock AgentCore 作对比基线）；
3. 你的工具代码已容器化 ，且满足三个硬约束：
   • 主程序必须监听 STDIN 并从 stdin 读取 JSON 输入（格式见下文）；
   • 输出必须是 stdout 的单行 JSON（含 result 字段）；
   • 不能有后台进程、不能监听端口、不能写 /tmp 以外的路径。

我推荐用 Python + FastAPI 构建工具镜像，但 不要用 Uvicorn 启动 Web 服务 ——Harness 不走 HTTP，它走 stdin/stdout。正确姿势是：

# tools/crm_lookup.py
import json
import os
import sys

def main():
    # 从 stdin 读取输入
    input_data = json.loads(sys.stdin.read())
    lead_id = input_data.get("lead_id")
    
    # 从环境变量安全读取 token（由 Anthropic 注入）
    crm_token = os.environ.get("CRM_API_TOKEN")
    if not crm_token:
        print(json.dumps({"error": "CRM token missing"}))
        return
    
    # 实际调用 CRM API（此处省略 requests 代码）
    result = {"name": "Alice Smith", "company": "TechCorp", "status": "qualified"}
    print(json.dumps({"result": result}))

if __name__ == "__main__":
    main()

Dockerfile 如下（关键点已注释）：

FROM python:3.11-slim

# 安装依赖（务必用 --no-cache-dir 减小镜像）
RUN pip install --no-cache-dir requests==2.31.0

# 复制工具代码（注意：不复制任何 credentials！）
COPY tools/crm_lookup.py /app/crm_lookup.py

# 设置入口（必须是可执行文件，且不带参数）
ENTRYPOINT ["/app/crm_lookup.py"]

构建并推送到 ECR（或 Anthropic 支持的任意 registry）：

docker build -t 123456789.dkr.ecr.us-east-1.amazonaws.com/agent-tools:crm-v1 .
docker push 123456789.dkr.ecr.us-east-1.amazonaws.com/agent-tools:crm-v1

注意：镜像大小务必控制在 500MB 以内。Anthropic 对沙箱启动时间有 SLA（P95 < 3s），超大镜像会导致冷启动超时。我们曾因镜像含 pandas 和 numpy ，启动耗时达 8.2s，被自动拒绝。解决方案是：用 pyinstaller 打包成单文件二进制，或改用更轻量的 httpx 替代 requests 。

3.2 YAML 配置详解：每一行都是生产经验

下面是你真正要提交给 Anthropic 的 sales-agent.yaml ，我逐行解释其背后的血泪教训：

# 1. name 是全局唯一标识，也是计费单位，别用中文或空格
name: sales-lead-qualifier-prod

# 2. system_prompt 是 agent 的“宪法”，必须包含三要素：
#    - 角色定义（你是谁）
#    - 行为边界（禁止做什么）
#    - 数据来源（只能调哪些工具）
system_prompt: |
  You are a Senior Sales Development Representative at Acme Corp.
  Your job is to qualify inbound leads by checking CRM, reviewing support history,
  and scoring against our Ideal Customer Profile (ICP).
  NEVER output PII (names, emails, phone numbers) in plain text.
  ALWAYS use the provided tools. NEVER make up data.

# 3. tools 定义必须与沙箱内工具名严格一致（大小写敏感！）
tools:
  # 工具名必须是镜像 ENTRYPOINT 文件名（不含 .py）
  - crm_lookup
  - support_ticket_fetch
  - icp_scoring_api

# 4. sandbox 配置是性能与安全的平衡点
sandbox:
  # 镜像地址必须完整（含 registry 和 tag）
  image: 123456789.dkr.ecr.us-east-1.amazonaws.com/agent-tools:crm-v1
  
  # 内存限制：2048MB 是甜点值。低于 1024MB 可能 OOM；高于 4096MB 浪费钱且启动慢
  memory_limit_mb: 2048
  
  # 超时时间：300 秒（5 分钟）是底线。金融类工具建议设 120 秒，避免长阻塞
  timeout_seconds: 300
  
  # 关键！启用 credential injection，但必须指定 vault path
  # Anthropic 会从你的 Vault 中读取 secret/crm/token，并注入为 CRM_API_TOKEN 环境变量
  credentials:
    - vault_path: secret/crm/token
      env_var: CRM_API_TOKEN

# 5. guardrails 是企业级刚需，不是可选项
guardrails:
  # 敏感词过滤：防止 PII 泄露（注意：正则必须 PCRE 兼容）
  pii_filter:
    patterns:
      - \b[A-Z][a-z]+@[a-z]+\.[a-z]{2,}\b  # 邮箱
      - \b\d{3}-\d{3}-\d{4}\b              # 电话
    action: redact  # 可选 redact（脱敏）或 block（拦截）
  
  # 输出长度限制：防 token 爆炸（我们吃过亏：一个 agent 生成 200KB 报告，账单翻倍）
  max_output_tokens: 2048
  
  # 工具调用频率限制：防循环调用（如 crm_lookup → support_ticket_fetch → crm_lookup...）
  tool_call_rate_limit:
    crm_lookup: 3/minute
    support_ticket_fetch: 5/minute

# 6. observability 是事后追责的唯一依据
observability:
  # 日志保留天数：免费版 30 天，付费版可设 365 天
  log_retention_days: 90
  # 是否开启 trace 采样（100% 采样适合调试，生产建议 10%）
  trace_sampling_rate: 1.0

实操心得： guardrails.pii_filter 的正则模式必须经过严格测试。我们最初用 \b\d{10,15}\b 匹配手机号，结果把订单号 ORD-1234567890 也脱敏了。正确做法是：先用 aws anthracite test-guardrail 命令本地验证正则，再上线。另外， tool_call_rate_limit 的数值不是拍脑袋：我们统计了过去 30 天真实流量，取 P95 峰值的 1.5 倍作为阈值，既防滥用，又保弹性。

3.3 首次部署与调试：三步定位 90% 的问题

部署不是 anthropic deploy -f sales-agent.yaml 就完事。真实流程如下：

第一步：Dry-run 检查语法与权限

anthropic agents validate --file sales-agent.yaml
# 输出应为 "Valid YAML, all resources accessible"
# 如果报错 "Vault path secret/crm/token not found"，说明你的 Vault 权限没配对

第二步：启动测试 session，观察沙箱行为

# 创建一个测试 session，输入是标准 JSON
echo '{"lead_id": "LEAD-789"}' | anthropic agents invoke \
  --agent-name sales-lead-qualifier-prod \
  --input-file - \
  --debug  # 开启 debug 模式，显示沙箱启动日志

你会看到类似输出：

[DEBUG] Starting sandbox with image: .../agent-tools:crm-v1
[DEBUG] Injecting credential from vault_path: secret/crm/token
[DEBUG] Sandbox PID: 12345, Memory: 1.8GB/2.0GB
[INFO] Tool 'crm_lookup' executed in 423ms
{"result": {"name": "Alice Smith", ...}}

第三步：查询事件日志，确认全链路可观测

# 查最近 5 个 session 的概览
anthropic agents list-sessions --agent-name sales-lead-qualifier-prod --limit 5

# 查特定 session 的完整事件流（关键！）
anthropic agents get-session --session-id sess_abc123 --events

# 输出示例：
# event_id: ev_crm_start_456 | type: tool_call_started | timestamp: 2026-04-10T08:22:11Z
# event_id: ev_crm_end_457   | type: tool_call_succeeded | payload: {"name":"Alice Smith",...}
# event_id: ev_model_out_458| type: model_output | content: "Lead Alice Smith is qualified..."

常见问题速查表：

现象	可能原因	排查命令
invoke 返回 503 Service Unavailable	Sandbox 启动超时（镜像太大/网络慢）	anthropic agents get-session --session-id X --events 查 sandbox_failed 事件
工具返回 {"error": "CRM token missing"}	Vault path 错误或权限不足	anthropic vault get-secret --path secret/crm/token 测试读取
输出含明文邮箱	pii_filter 正则未匹配	anthropic agents test-guardrail --pattern '\b[A-Z][a-z]+@[a-z]+\.[a-z]{2,}\b' --text "test@domain.com"
tool_call_rate_limit 频繁触发	阈值设太低或存在逻辑循环	anthropic agents get-session --session-id X --events | grep "rate_limited"

4. 生产级陷阱与实战避坑指南（来自 7 个真实项目）

4.1 Credential 注入的“蜜罐陷阱”：永远不要信环境变量

去年我们有个金融客户项目，要求 agent 调用内部风控 API。安全团队坚持“token 必须注入环境变量”，理由是“开发习惯”。结果上线第三天，一个 agent 在 debug 模式下输出了完整环境变量列表（含 RISK_API_TOKEN=xxx ），日志被意外上传到公开 S3 桶。这不是 Anthropic 的锅，是我们的架构失误。

Managed Agents 的 credential 注入机制，本质是 Vault-to-Sandbox 的单向隧道 。Anthropic 的沙箱运行时，在 microVM 启动后，会调用 Vault 的 read API 获取 secret，然后通过 virtio-serial 设备将 token 传入沙箱内存，再由沙箱内核将其映射为环境变量。这个过程的关键在于： token 在传输过程中从未以明文形式存在于宿主机磁盘或内存中 。但如果你在工具代码里写了 os.system("env | grep TOKEN") ，或者用 ps aux | grep python 查进程，依然能看到它——因为此时 token 已加载进沙箱进程空间。

避坑铁律：

• 永远不要在日志中打印 os.environ ；
• 工具代码中所有敏感操作，必须用 try/except 包裹，并在 except 中清除内存 （Python 用 ctypes.memset ）；
• 在沙箱镜像的 Dockerfile 中，添加 RUN rm -rf /usr/bin/env （禁用 env 命令，防社工）。

我们现在的标准实践是：在工具代码开头强制清空所有非必要环境变量：

import os
keep_envs = ["CRM_API_TOKEN", "PATH", "HOME"]
for key in list(os.environ.keys()):
    if key not in keep_envs:
        del os.environ[key]

4.2 Session 日志的“黑洞效应”：如何避免日志爆炸吞噬预算

事件日志按 session 计费，$0.08/小时。听起来便宜？但一个高并发客服 agent，每分钟处理 200 个 session，每个 session 平均存活 120 秒，日志量轻松破 TB。我们曾因未设 log_retention_days ，三个月后账单飙升至 $12,000/月。

更隐蔽的陷阱是 日志采样率 。 trace_sampling_rate: 1.0 （100% 采样）适合上线首周调试，但生产环境必须降。我们采用分层采样策略：

• P0 故障（HTTP 5xx） ：100% 采样；
• P1 异常（tool call timeout > 10s） ：20% 采样；
• P2 正常流量 ：1% 采样（足够做趋势分析）。

Anthropic 支持基于表达式的动态采样：

observability:
  trace_sampling_rate: 0.01
  # 仅对错误事件全量采样
  error_sampling_rate: 1.0
  # 对高价值客户 session 提升采样率
  custom_sampling_rule: |
    if input.get("customer_tier") == "enterprise":
      return 0.1
    else:
      return 0.01

4.3 Harness 的“雪崩临界点”：当 1% 的慢请求拖垮全局

P95 延迟 2.8 秒很稳？别高兴太早。我们压测发现：当 support_ticket_fetch 工具因上游 API 降级，响应从 300ms 涨到 8s 时，Harness 集群的 P95 会瞬间跳到 15s，且持续 12 分钟——因为慢请求占满连接池，新请求排队等待。

解决方案是 双保险熔断 ：

1. 沙箱层熔断 ：在 sandbox.timeout_seconds: 300 基础上，工具代码内加 timeout=5 参数（如 requests.get(url, timeout=5) ）；
2. Harness 层熔断 ：在 YAML 中配置 circuit_breaker ：

circuit_breaker:
  failure_threshold: 5  # 连续 5 次失败
  timeout_seconds: 60   # 熔断后 60 秒内拒绝新请求
  half_open_after: 300  # 300 秒后尝试半开

实测效果：当 support_ticket_fetch 故障时，Harness 在第 5 次失败后立即熔断，后续请求 100ms 内返回 {"error": "circuit breaker open"} ，P95 稳定在 200ms。

4.4 “合规性幻觉”：你以为的审计就绪，其实只是假象

金融客户总问：“你们的日志能当审计证据吗？”答案是： 能，但必须满足三个条件 ：

• 不可篡改性 ：Anthropic 的事件日志用 Merkle Tree 哈希链签名，每条事件含前序事件 hash，修改任一事件都会导致链断裂；
• 时间权威性 ：所有时间戳由 Anthropic 的硬件安全模块（HSM）签发，非系统时钟；
• 内容完整性 ：日志包含 payload_hash 字段，可独立校验原始数据是否被篡改。

但我们发现一个致命漏洞： system_prompt 不在事件日志里！ 如果你上线后偷偷改了 prompt（比如把“禁止输出 PII”删掉），日志里查不到这个变更。解决方案是：

• 将 system_prompt 存入 Vault，YAML 中用 prompt_ref: vault://secret/agents/sales-prompt 引用；
• 每次 invoke 时，Harness 会记录 prompt_version: v3.2 字段；
• 审计时，用 vault read secret/agents/sales-prompt --version v3.2 还原原始 prompt。

这才是真正的“PromptOps”。

5. 竞争格局与未来判断：为什么 runtime 层注定归零？

5.1 不是 Anthropic 在定义标准，是市场在淘汰不合格玩家

媒体把 Managed Agents 描绘成 Anthropic 的“新护城河”，这严重误判了现实。真相是： AWS Bedrock AgentCore 在 2025 年底就已 GA，且支持 Claude 模型 。这意味着，一个开发者今天想用 Claude 构建 agent，他有三个选择：

• 自建（LangChain + EC2）：成本高、运维重、安全弱；
• 用 Anthropic Managed Agents：开箱即用，但绑定 Claude；
• 用 AWS AgentCore：同样开箱即用，且可随时切换到 Llama 3、Mixtral 或自研模型。

我们帮客户做过成本对比：处理 100 万次 session，Anthropic 方案年支出 $96,000（$0.08/session-hour × 100 万 × 1.2h avg），AWS 方案 $72,000（AgentCore 免费，只付 EC2 + Lambda + CloudWatch 日志）。差价 $24,000/年，够雇一个专职 infra 工程师。

这就是“hypervisor 时刻”的重演。2005 年 VMware ESX 卖 $15,000/主机，AWS EC2 初期定价 $0.10/小时，看似贵，但算上运维人力、安全加固、灾备建设，EC2 总拥有成本（TCO）三年内反超。Runtime 层的终局不是“谁家更快”，而是“谁家能让客户忽略 infra 存在”。当 AWS 把 AgentCore 深度集成进 CloudFormation、CDK、Service Catalog，当 Azure Foundry 提供一键部署 CrewAI 的 ARM 模板，Anthropic 的 YAML 配置就变成了“高级玩具”。

5.2 价值迁移的三块高地：Trace、Governance、Vertical

既然 runtime 层在压缩，钱流向哪里？我们跟踪了 2026 年 Q1 的融资数据，结论清晰：

第一高地：Trace Store（追踪存储）

• Braintrust 的 Brainstore 数据库，专为 AI 交互日志优化，支持毫秒级 SELECT * FROM traces WHERE tool_name = 'crm_lookup' AND status = 'failed' ；
• Arize 的 Phoenix 开源版，已成 LangChain 生态默认 trace 后端；
• LangSmith 的杀手锏不是技术，是 LangChain 安装基数 ——全球 42% 的 agent 项目默认用它打日志。

我们的判断：Trace Store 不是数据库，是 AI 时代的“黑匣子” 。当 agent 写错合同、误删数据库、生成歧视性话术，法庭要的不是“模型输出”，而是完整的 event_id 链。谁能提供不可篡改、可验证、可导出的 trace，谁就卡住合规咽喉。

第二高地：Governance（治理）
OWASP Agentic Top 10 刚发布，第一条就是“Broken Agent Authorization”。企业采购部门现在必问三句：

• 这个 agent 被允许调用哪些 API？（Policy as Code）
• 谁批准了这个权限？（Approval Workflow）
• 上次审计是什么时候？（Compliance Report）

AWS AgentCore 的 Policy Controls GA，微软的 Azure AI Governance SDK 已支持 SOC2 模板。这不再是“最好有”，而是“必须有”。

第三高地：Vertical Marketplace（垂直市场）
Salesforce Agentforce ARR $800M，不是靠卖 runtime，是靠卖 预训练+预集成+预合规的行业 agent 。他们的销售 agent 内置了：

• 与 Salesforce CRM 的深度字段映射；
• 对 Veeva、IQVIA 等医药 CRM 的 connector；
• HIPAA 合规的 PII 处理 pipeline；
• 销售总监看的 ROI 仪表盘（自动生成）。

这才是终极答案：企业不为“agent 技术”付费，为“解决具体问题”付费。当 runtime 归零，价值必然向 问题域 （Problem Domain）迁移。一个懂医疗法规的 agent，比十个超快 sandbox 有价值得多。

5.3 最后一个警告：自我进化 agent 正在改写游戏规则

Sakana AI 的 Darwin Gödel Machine 论文不是科幻。它证明：agent 可以通过强化学习，自动重写自己的 tool call 逻辑，将 SWE-bench 通过率从 20% 提升到 50%。这意味着什么？

• 沙箱不再只是隔离容器，而是“实验牢笼” ：你必须确保 agent 在沙箱内重写的代码，无法逃逸、无法污染宿主机、无法绕过 policy；
• Trace Store 不再是调试工具，而是法律证据 ：当 agent 自己生成了违规代码， event_id 链就是它的“犯罪现场”；
• Governance 不再是静态策略，而是动态围栏 ：你需要实时分析 agent 的重写行为，自动调整 sandbox 权限（如检测到 os.system 调用，立即 revoke sys_admin capability）。

我们已在内部测试一个“进化防护层”：在沙箱启动前，用轻量级 ML 模型扫描 agent 的初始代码，预测其重写倾向（如高频调用 eval() 、 exec() 的概率），并动态设置 sandbox.max_syscalls: 100 。这不再是 DevOps，而是 AI SafetyOps 。

我个人在实际操作中的体会是：Managed Agents 的发布，不是终点，而是起点。它把过去一年散落在各处的工程实践，凝练成一个可交付、可计费、可审计的接口。但真正的战争，才刚刚从 infrastructure 层，转移到 trace、governance 和 vertical 层。如果你还在纠结“我的 sandbox 启动快 100ms”，那你已经输了——赢家在忙着构建医疗 agent 的 FDA 合规流水线，或设计金融 agent 的 SEC 审计报告模板。runtime 归零是必然，而价值，永远属于离业务最近的那一层。