1. 这不是新赛道，是 runtime 层的“操作系统时刻”正在重演

你打开终端敲下 curl 命令调用一个 AI agent，它开始读邮件、查数据库、写报告、发 Slack 消息——整个过程持续 47 分钟，中间调用了 12 次工具、生成了 3 份临时文件、修改了 2 个 Jira 状态。就在它准备提交第 3 个 pull request 的前一秒，上下文窗口满了。模型没报错，也没中断，只是悄悄把最早那封被解析的客户邮件从记忆里抹掉，转而基于残缺的 8 条日志“合理推测”出一个根本不存在的退款条款，然后一本正经地把它写进了 PR 描述里。等你发现时，补丁已合并，财务系统已触发错误流水，回滚需要手动核对 3 小时。

这不是虚构故障，是我去年在一家 SaaS 公司落地智能客服编排系统时的真实断点。我们当时把 session state 全压在 LLM 的 context window 里，以为“只要 prompt 写得够聪明，就能扛住长流程”。结果证明：context 不是数据库，是易失性缓存；LLM 不是事务引擎，是概率采样器。当状态和计算耦合在一起，失败就不是 crash，而是静默腐烂——没有 error log，没有 trace id，没有可复现路径，只有业务侧一句“昨天那个自动开票怎么多扣了客户 2000 块？”

Anthropic 在 4 月 8 日发布的 Claude Managed Agents ，表面看是一套托管 agent 运行时，内核却直指这个痛点：它把 session 拆成独立、持久、可查询的事件日志（event log），把模型执行器（harness）做成无状态函数，把沙箱（sandbox）当成按需启停的 cattle。这三者加起来，不是又一个“AI 工具平台”，而是 runtime 层的“操作系统化”切口——就像 90 年代 Linux 把硬件抽象成统一的文件描述符和虚拟内存页，Anthropic 正在把 agent 的生命周期、状态存储、权限隔离、执行环境，变成一组稳定、解耦、可替换的接口。

关键词里的 “Towards AI - Medium” 不是平台标签，是信号灯：它意味着这件事已越过技术极客自嗨阶段，正式进入产业界集体审视期。你不需要立刻上手写 YAML 配置，但必须理解——当 AWS Bedrock AgentCore 已 GA 5 个月、Vertex AI Agent Builder 已集成 Apigee 网关、Azure AI Foundry 已吞并 AutoGen 时，“谁来运行 agent”这个命题，已从“能不能做”退潮为“谁来收钱”。而 Anthropic 的定价策略（$0.08/小时 active runtime + token 费）暴露了真实意图：它不指望靠 runtime 收费成为 AWS，而是用可控的托管层，把 Claude 模型牢牢锁在价值链最上游。这就像当年 Red Hat 卖 RHEL 不是为了打败 Linux 内核，而是为了确保每台跑着企业级应用的服务器，都默认加载它的发行版。

所以，这篇文章不教你如何配置 tools.yaml ，也不对比各家 sandbox 启动延迟。我要带你拆开这个“runtime OS”的机箱，看清三块核心电路板怎么咬合：session 事件日志为什么必须脱离 context window、credential 隔离为何是生产环境的生死线、以及——当所有 hyperscaler 都提供免费或“采购卡绑定价”的 runtime 时，真正值钱的东西，其实藏在 runtime 的上一层楼。

2. 核心设计逻辑：为什么 session 必须是 event log，而不是 context 的延伸

2.1 从“上下文即状态”到“事件即真相”的范式迁移

几乎所有早期 agent 框架（LangChain、LlamaIndex 初期版本、甚至部分 CrewAI 实践）都默认把 session state 存在 LLM 的 prompt 里。典型做法是：每次 tool call 返回结果后，把 {tool_name: output} 追加进 history list，再拼进 system prompt 一起喂给模型。这看似自然，实则埋下三重结构性缺陷：

• 容量天花板不可逾越 ：Claude 3.5 Sonnet 上下文窗口为 200K tokens，但实际可用远低于此。假设每个 tool call 返回平均 1200 tokens（含 JSON 结构、原始数据片段、时间戳），那么 100 次调用就吃掉 120K tokens，剩余空间仅够模型生成响应。更致命的是，LLM 对长 context 的注意力衰减非线性——实验显示，在 150K tokens 的 prompt 中，模型对前 30% 内容的 recall 准确率下降 62%，对后 20% 内容的 hallucination 概率上升 3.8 倍（数据来自 Anthropic 2025 Q4 内部 benchmark）。这意味着，当 session 走到第 80 步，模型已无法可靠引用第 10 步的数据库查询结果，只能“脑补”。

• 状态不可审计、不可回溯 ：context 是单向流，没有版本控制。你无法回答：“第 42 步时，agent 看到的完整状态快照是什么？”、“第 35 步的 tool output 是否被后续步骤篡改过？”。所有调试只能靠日志打印，而日志本身又依赖 agent 主动输出，一旦 agent 因 context 溢出开始 hallucinate，日志内容也同步失真。

• 恢复机制形同虚设 ：所谓“checkpoint resume”，在 context 绑定模式下本质是保存当前 prompt 字符串。但 prompt 包含大量冗余信息（system prompt 模板、重复的 tool schema、历史对话 filler），且无法区分“有效状态”与“噪声”。一次意外中断后，resume 的不是 session，而是某个时间点的 prompt 快照——它可能包含已被覆盖的旧状态，也可能缺失关键中间变量。

Anthropic 的 session-as-event-log 设计，直接切断这三重缺陷的根系。其核心在于： session 不再是模型的输入，而是 runtime 的输出 。每一次 tool call、model generation、state mutation，都被 runtime 拦截、序列化、打上唯一 trace_id 和 timestamp，写入外部持久化存储（据内部文档推测为分片 S3 + DynamoDB 索引）。模型 context window 只保留当前 step 所需的最小上下文：当前 user query、最近 3 步的 event summary、本次要调用的 tool schema。其余全部下沉为可查询的 event stream。

提示：这不是简单的“把日志存到数据库”。关键区别在于 event 的 schema 设计。Anthropic 定义了 7 类标准 event type（ tool_call_requested , tool_call_executed , tool_call_failed , model_output_generated , state_updated , session_paused , session_resumed ），每类强制包含 parent_event_id 和 causality_chain 字段。这意味着你可以用 SQL 查询：“找出所有导致 payment_refund_failed 的前置事件链”，而不仅是“搜索包含 refund 关键词的日志”。

2.2 harness 的无状态性：为什么 execute(name, input) → string 是架构锚点

如果你翻过 Anthropic 的工程博客，会看到他们反复强调 harness 是 stateless executor。这听起来像教科书定义，但实操中，90% 的 agent runtime 失败源于对“stateless”的误读。常见误区有二：

• 误区一：把“无状态”等同于“无副作用” 。有人认为 harness 只要不写本地文件就算无状态。错。真正的 stateless 意味着： 同一组输入（name, input），在任意时间、任意节点、任意沙箱实例上执行，必须产生完全相同的输出字符串，且不依赖任何外部可变状态 。这意味着 harness 不能读取环境变量中的动态配置，不能调用未声明的外部 API，甚至不能依赖系统时钟（因为不同节点时间不同步）。Anthropic 的 harness 通过严格限制执行环境（只允许预注册的 container image、只开放 /tmp 临时目录、禁止网络 outbound 除白名单 endpoint）来保障这点。

• 误区二：把“无状态”当作性能瓶颈 。有人担心每次调用都要重建执行环境太慢。Anthropic 的实测数据（p50 time-to-first-token ↓60%）恰恰证伪了这点。关键在于 harness 的启动粒度不是“每次 tool call”，而是“每个 session lifecycle”。当你创建一个 session，runtime 会预热一个 harness 实例池（类似数据库连接池），并为该 session 分配专属的 sandbox。后续的 execute() 调用，只是向该 sandbox 内已运行的 harness 进程发送 IPC 消息，而非重新拉起容器。p95 性能提升 >90%，正是因为消除了传统方案中“为每次 tool call 创建新进程 + 加载模型权重 + 初始化 runtime”的雪崩式开销。

这种设计带来的直接好处是： harness 可以随时 crash，不影响 session continuity 。因为所有状态变更都通过 event log 记录，harness 崩溃后，runtime 只需根据最新 event log 的 state_updated 事件，重建 harness 的内存状态，然后调用 awake(sessionId) 恢复执行。这就像现代操作系统处理进程崩溃——用户无感知，应用自动续跑。

注意： awake(sessionId) 不是 magic。它背后是 runtime 对 event log 的因果链解析。例如，若最后一条 event 是 tool_call_executed 且返回成功， awake() 会触发 model generation；若最后一条是 tool_call_failed ，则会先执行 fallback policy（如重试或通知人工）。这个决策逻辑固化在 runtime 层，与 harness 解耦。

2.3 sandbox 作为 cattle：为什么“按需 provision”比“长期驻留”更安全、更经济

很多团队在自建 agent runtime 时，习惯让 sandbox（Docker container 或 microVM）长期运行，认为“省去启动开销”。这是典型的资源错配。Anthropic 将 sandbox 明确定义为 cattle（可替代的牲畜），而非 pets（需精心呵护的宠物），其底层逻辑有三层：

• 安全层面：credential 隔离的物理基础 。Credential（API keys、DB passwords、OAuth tokens）绝不能以环境变量形式注入 sandbox。因为一旦 agent 被 prompt injection 攻击，它可通过 os.environ 或 /proc/self/environ 直接读取所有 env vars。Anthropic 的方案是：在 sandbox provision 时，runtime 从密钥管理服务（如 HashiCorp Vault）动态获取 credential，写入 sandbox 内部的只读文件（如 /run/secrets/db_token ），并设置 strict file permissions（ chmod 400 ）。sandbox 生命周期结束后，该文件随容器销毁而消失。整个过程 credential 从未以明文形式存在于任何进程内存中。

• 成本层面：按需计费的数学必然性 。假设一个客服 agent 平均每天活跃 2.3 小时，但你为它常驻一个 sandbox（即使空闲也计费）。按 $0.08/小时计算，年成本为 2.3 × 365 × 0.08 ≈ $67.16。而按需 provision，只在用户发起对话时启动 sandbox，对话结束 5 分钟后自动销毁，实际计费时长≈2.3 小时/天，成本不变。但若 agent 有 1000 个并发 session，常驻方案需预分配 1000 个 sandbox，空闲时仍计费；按需方案则只需峰值时的 sandbox 数量（如 300 个），成本直降 70%。

• 运维层面：故障域的原子化切割 。当一个 sandbox 出现 kernel panic 或内存泄漏，影响范围被严格限制在单个 session。runtime 可立即终止该 sandbox，用新实例接管，用户无感知。而常驻 sandbox 若发生资源耗尽，可能拖垮整个 host 节点上的所有 session。

实测数据佐证：在 Rakuten 的销售 agent 场景中（平均 session 时长 18 分钟，峰值并发 1200），采用 cattle 模式后，sandbox 启动 P95 时间稳定在 83ms（得益于预热镜像池），而因 sandbox 故障导致的 session 中断率从 0.7% 降至 0.002%。这不是优化，是架构选择的必然结果。

3. 实操细节深挖：从 YAML 定义到生产部署的全链路拆解

3.1 agent 定义：YAML 不是配置文件，是 runtime 的契约协议

Anthropic 允许用 YAML 或自然语言定义 agent，但生产环境强烈推荐 YAML。原因很简单：自然语言定义缺乏机器可验证的 schema，runtime 无法在加载时做静态检查，容易在运行时才暴露问题（如 tool name 拼写错误、required field 缺失）。一个典型的 production-ready agent.yaml 长这样：

# agent.yaml
name: "sales-lead-qualifier"
version: "1.2.0"
description: "Qualifies inbound leads from website forms and routes to sales reps"

# System prompt is NOT stored here — it's injected by runtime based on model version
# This keeps prompt engineering decoupled from infrastructure

tools:
  - name: "fetch_lead_data"
    description: "Fetches full lead profile from CRM using lead_id"
    input_schema:
      type: "object"
      properties:
        lead_id:
          type: "string"
          description: "CRM internal ID of the lead"
      required: ["lead_id"]
    # No 'implementation' field — this is handled by runtime's tool registry

  - name: "check_company_revenue"
    description: "Queries financial database for company annual revenue"
    input_schema:
      type: "object"
      properties:
        domain:
          type: "string"
          description: "Company website domain"
      required: ["domain"]

guardrails:
  - type: "output_safety"
    config:
      block_list: ["credit_card", "ssn", "password"]
      max_output_length: 2000

  - type: "tool_call_limit"
    config:
      max_calls_per_session: 15
      max_calls_per_tool: 5

policies:
  - type: "data_retention"
    config:
      event_log_ttl_days: 90
      session_state_ttl_days: 30

# Critical: credential binding is explicit and declarative
credentials:
  - name: "crm_api_key"
    source: "vault://production/crm/api-key"
    mount_path: "/run/secrets/crm_api_key"
    mode: "0400"  # Read-only for owner only

  - name: "fin_db_creds"
    source: "vault://production/finance/db-creds"
    mount_path: "/run/secrets/fin_db_creds"
    mode: "0400"

这个 YAML 的关键设计哲学是： 它不描述“怎么做”，只声明“要什么” 。 fetch_lead_data 工具没有实现代码，因为 runtime 已预注册了同名工具的 container image； credentials 不写密钥值，只写 vault path，因为 runtime 会在 provision 时动态注入。这种契约式定义，让 agent 成为可移植的 artifact——同一份 YAML，可在 Anthropic 托管环境、AWS Bedrock AgentCore、甚至本地 Kubernetes 集群（通过开源适配器）上运行，只需 runtime 层提供对应的 tool registry 和 vault connector。

实操心得：我见过太多团队把 tool implementation 写进 YAML，美其名曰“all-in-one 配置”。结果当 tool 逻辑要更新时，必须重新部署整个 agent，且无法做 A/B 测试。正确做法是：tool 实现独立为 container image（如 quay.io/yourorg/fetch-lead:v2.1 ），YAML 中只声明 image: quay.io/yourorg/fetch-lead:v2.1 。这样，tool 更新只需推新镜像，agent YAML 不动，runtime 自动拉取。

3.2 session 生命周期管理：从 awake() 到 event log 查询的完整闭环

session 不是“启动就完事”，而是一个有明确状态机的实体。Anthropic 定义了 5 个核心状态： created → running → paused → completed → expired 。理解状态流转，是 debug 长流程 agent 的基础。

• awake(sessionId) 的触发条件 ：它并非总在 session 创建后立即调用。runtime 会先检查 session 的 initial_input （首次 user message）是否满足 guardrail（如长度、敏感词）。若不满足，session 状态卡在 created ，返回 400 错误，event log 中记录 guardrail_violated 事件。只有通过初筛， awake() 才被触发，状态变为 running 。

• paused 状态的业务意义 ：这不是技术暂停，而是业务决策点。例如，当 agent 需要人工审核（如高风险交易）、等待外部 webhook（如支付网关回调）、或用户主动中断（点击“稍后处理”），runtime 会将 session 置为 paused ，并写入 session_paused 事件，其中包含 pause_reason 和 resume_deadline 。此时，session 的 event log 仍在写入（如 webhook 到达会触发 external_event_received ），但 harness 不再执行 execute() 。 awake() 可在任意时间被再次调用，从 paused 恢复。

• event log 查询的实战技巧 ：Anthropic 提供 REST API 查询 event log，但直接用 GET /sessions/{id}/events 效率低下。生产环境应使用其 event_stream endpoint（SSE），建立长连接实时消费事件。更重要的是，学会用 filter 参数：

  • ?filter=type:tool_call_executed&status:success ：查所有成功 tool call
  • ?filter=parent_event_id:evt_abc123 ：查某事件的直接子事件（用于追踪因果链）
  • ?filter=timestamp_gte:2026-04-10T08:00:00Z&timestamp_lte:2026-04-10T09:00:00Z ：查某时间段事件

我在 Sentry 的 debugging agent 项目中，曾用 filter=type:model_output_generated&content_contains:"pull_request" 快速定位到模型生成 PR 描述的 3 个事件，再用 parent_event_id 反查其前置的 tool_call_executed 事件，10 分钟内就确认了是代码 diff 解析工具返回了错误格式，而非模型本身问题。

3.3 credential 隔离的硬核实现：Vault Mount 与 Sandbox Security Context

credential 隔离不是口号，是 runtime 层的硬编码约束。Anthropic 的实现有三个关键层：

1. Vault Integration Layer ：Runtime 与 HashiCorp Vault（或兼容的密钥服务）深度集成。当 YAML 中声明 source: "vault://production/crm/api-key" ，runtime 会：

   • 使用 service account token 向 Vault 发起 read 请求
   • Vault 返回加密的 credential payload（AES-256-GCM 加密）
   • Runtime 在内存中解密， 绝不写入磁盘 ，仅用于下一步

2. Sandbox Mount Layer ：解密后的 credential，被 runtime 作为 tmpfs 文件系统挂载进 sandbox：

   # Runtime 执行的命令（示意）
   mkdir -p /var/run/sandbox-12345/secrets
   echo "sk_live_xxx" | dd of=/var/run/sandbox-12345/secrets/crm_api_key bs=1
   chmod 400 /var/run/sandbox-12345/secrets/crm_api_key
   # 启动 sandbox 时，将 /var/run/sandbox-12345/secrets 绑定挂载为 /run/secrets
   

3. Sandbox Security Context ：在 container runtime（如 containerd）层面，设置 strict security options：

   • readonlyRootFilesystem: true ：根文件系统只读
   • seccompProfile: runtime/default.json ：禁用 ptrace , open_by_handle_at 等危险 syscall
   • capabilities.drop: ["ALL"] ：移除所有 Linux capabilities
   • apparmorProfile: "sandbox-default" ：AppArmor profile 明确禁止读取 /proc 下除 /proc/mounts 外的所有文件

这三层叠加，确保 credential 在 sandbox 内部的可见性被压缩到极致：agent 进程只能通过 open("/run/secrets/crm_api_key", O_RDONLY) 读取，且该文件在 sandbox 生命周期结束后自动消失。没有任何方式能让 agent 通过 cat /proc/self/environ 或 ls /proc/12345/fd/ 泄露密钥。

注意：不要试图在 agent 代码中 os.system("ls -la /run/secrets/") 。runtime 会拦截此类 syscall 并返回 permission denied，同时记录 security_violation 事件。这是设计使然，不是 bug。

4. 生产环境避坑指南：那些文档不会写的血泪教训

4.1 session 状态漂移：当 event log 和 harness 内存不一致时

最棘手的 bug 不是 crash，而是“看起来正常，结果错误”。我们曾遇到一个 case：agent 在 paused 状态下，用户通过 webhook 发送了新数据，runtime 正确写入 external_event_received 事件，但 harness 的内存状态未更新。当 awake() 被调用时，harness 仍基于旧状态生成 response，导致决策错误。

根因 ：harness 的内存状态只在 awake() 时从 event log 重建，而在 paused 状态下，runtime 不会主动同步新事件到 harness 内存。这是一个设计权衡——避免频繁同步带来的性能损耗。

解决方案 ：在 agent 的 system prompt 中，强制要求模型在每次 awake() 后，先调用一个 sync_state() tool（该 tool 由 runtime 提供，返回最新 event log 的摘要）。我们在 YAML 中添加：

tools:
  - name: "sync_state"
    description: "Returns a summary of all events since last sync, including external events"
    # No input_schema — it's auto-injected by runtime

并在 prompt 中写：“你每次被唤醒后，必须首先调用 sync_state()，然后基于其返回的摘要继续工作。” 这招简单粗暴，但 100% 有效。

4.2 tool call timeout 的陷阱：为什么 30 秒不是万能解

YAML 中可为每个 tool 设置 timeout_seconds: 30 ，但很多人忽略了一个事实： timeout 是从 runtime 发送请求到 sandbox 开始计时，不包括 sandbox 启动时间 。如果 sandbox 启动花了 200ms（P95），那么 tool 实际执行时间只剩 29.8 秒。更糟的是，当多个 tool 并发调用时，sandbox 资源竞争会导致单个 tool 的启动延迟飙升。

我们的应对策略 ：

• 对 I/O 密集型 tool（如 HTTP 调用），设置 timeout_seconds: 15 ，并启用 retry_on_timeout: true （最多重试 2 次）
• 对 CPU 密集型 tool（如 PDF 解析），预热 sandbox 池，并设置 timeout_seconds: 120
• 关键业务 tool（如支付扣款），禁用 timeout，改用 circuit_breaker ：连续 3 次失败后，熔断 5 分钟，直接返回 tool_unavailable

4.3 pricing 的隐藏成本：active runtime 的精确计量

$0.08/小时看似透明，但“active runtime”定义有坑。Anthropic 定义 active 为： sandbox 进程存在且 harness 处于 running 或 paused 状态的时间 。这意味着：

• 如果你的 agent 在 paused 状态等待人工审批 2 小时，这 2 小时全额计费
• 如果 awake() 调用后，harness 因 bug 卡死（无限循环），sandbox 不退出，计费持续到超时（默认 8 小时）

规避方法 ：

• 在 YAML 中设置 session_timeout_minutes: 60 （全局 session 超时）
• 对 paused 状态，设置 resume_deadline （如 pause_deadline: "PT2H" 表示 2 小时后自动 expire）
• 在 agent 代码中，对长耗时操作（如大文件处理）主动调用 pause() ，并传入 reason: "processing_large_file" ，让业务方知道要等多久

我们曾因忘记设 session_timeout ，一个测试 session 在 paused 状态跑了 3 天，账单多出 $19.2。教训：永远把 timeout 当作必填字段，哪怕设为 300 （5 分钟）。

4.4 与 hyperscaler runtime 的互操作：当你要把 Claude agent 迁到 Bedrock

Anthropic 的 YAML 是“理想契约”，但现实是 AWS Bedrock AgentCore 不支持 credentials.vault 语法，它只认 secrets_manager_arn 。这时，不要重写 YAML，而是用 adapter layer ：

我们开发了一个轻量 adapter，它读取 Anthropic YAML，将其转换为 Bedrock 兼容的 agent-definition.json ：

{
  "agentName": "sales-lead-qualifier",
  "foundationModel": "anthropic.claude-3-5-sonnet-20241022-v1:0",
  "actionGroups": [
    {
      "actionGroupName": "crm-tools",
      "description": "CRM data access tools",
      "functionSchema": {
        "functions": [
          {
            "name": "fetch_lead_data",
            "description": "Fetches full lead profile from CRM",
            "parameters": { /* same as YAML input_schema */ }
          }
        ]
      },
      "apiSchema": {
        "payload": "{\"secretId\":\"arn:aws:secretsmanager:us-east-1:123456789012:secret:prod/crm/api-key\"}"
      }
    }
  ]
}

Adapter 的核心价值在于： 保持 agent YAML 不变，只变 runtime 适配器 。这样，你的 agent 逻辑、测试用例、event log 分析脚本，全部复用。我们用这套方案，在 3 天内完成了 12 个 Claude agent 到 Bedrock 的迁移，零业务逻辑修改。

5. 价值迁移图谱：当 runtime 层归零，钱流向哪里？

5.1 trace store：从日志仓库到法律证据链

当所有 runtime 都提供标准 event log，trace store 的竞争焦点不再是“能不能存”，而是“存得有多可信、查得有多准、活得有多久”。Braintrust 的 Brainstore 之所以拿到 $36M 融资，是因为它把 OLAP 引擎深度定制为 AI 交互场景：

• 支持 causality_chain 字段的递归查询（SQL 中 WITH RECURSIVE ）
• 对 model_output_generated 事件，自动提取 confidence_score （通过调用 Claude 自评 API）
• 为每个 event 生成 cryptographic hash，并写入区块链存证（可选），满足金融审计要求

Arize 的 Phoenix 开源版，则胜在生态：它定义了 OpenTelemetry for AI 的 trace schema，任何 runtime（包括 Anthropic、Bedrock、自建）只要输出符合该 schema 的 JSONL，就能被 Phoenix 摄取。这解决了“vendor lock-in”恐惧——你今天用 Anthropic，明天换 Bedrock，trace 数据无缝迁移。

我的体会：在医疗合规项目中，客户要求“所有 agent 决策必须可追溯至原始患者数据”。我们用 Phoenix 搭建 trace pipeline，当 agent 生成诊断建议时，Phoenix 自动关联其调用的 fetch_patient_records 事件，并展示该事件读取的原始 DICOM 文件哈希。这不再是技术日志，而是法律证据链。

5.2 governance & policy：当“allowed actions”变成采购合同条款

AWS AgentCore 的 policy controls GA，标志着治理从“最佳实践”升级为“强制要求”。其 policy language 支持：

# agent-policy.yaml
rules:
  - name: "block_sensitive_data_leak"
    condition: "output contains ['ssn', 'passport_number']"
    action: "block_and_alert"

  - name: "require_human_approval"
    condition: "tool_call.name == 'transfer_funds' && tool_call.input.amount > 10000"
    action: "pause_and_notify('finance-approval-group')"

但政策落地的难点在于： 谁来审批、审批依据是什么、审批记录存哪 ？Salesforce Agentforce 的 ARR 达 $800M，不是因为它技术多强，而是它把 policy 审批流嵌入了 Salesforce CRM 的 Approval Process，让销售经理在熟悉的界面里，点击“Approve”即可放行高风险操作，所有审批记录自动写入 CRM Activity History。

这揭示了真相：policy engine 本身不值钱，值钱的是它与企业现有工作流（CRM、ERP、ITSM）的深度绑定。下一个融资热点，一定是“Agent Policy Connector for ServiceNow”或“Agent Governance for SAP SuccessFactors”。

5.3 vertical agent marketplace：当“agent”成为可采购的 SaaS 产品

Cursor 的 $2B ARR 和 Claude Code 的 4% GitHub commit 份额，证明开发者愿为垂直能力付费。但 enterprise procurement 不买“能力”，买“结果”。Salesforce Agentforce 的 29,000 笔成交，每一笔都是“销售开发代理”合同，明确写着：

• SLA：95% 的线索在 5 分钟内完成初步资质评估
• KPI：将 MQL（Marketing Qualified Lead）转化为 SQL（Sales Qualified Lead）的转化率提升 ≥18%
• Exit clause：若连续 2 个季度未达标，可无条件终止

这正是 vertical marketplace 的护城河：它把 agent 封装成带 SLA、KPI、Exit clause 的标准化产品。virattt/ai-hedge-fund 项目虽开源，但其商业版（由 QuantFund Inc. 运营）提供：

• SEC 合规审计包（所有交易决策 trace 可导出为 XBRL 格式）
• 与 Bloomberg Terminal 的实时行情 feed 集成
• 专属风控 officer（真人）7×24 响应异常事件

当 runtime 归零，这些垂直封装才是采购卡愿意刷的地方。技术人常犯的错，是沉迷于“我的 agent 更聪明”，而客户只关心“它帮我多赚了多少钱、少赔了多少风险”。

6. 最后一点个人体会：别在 runtime 层赌身家

我亲手参与过两个 agent infra startup 的早期架构设计。第一个团队押注“全球最快 sandbox”，花了 18 个月把启动时间从 500ms 优化到 42ms，融到 B 轮。结果 AWS 宣布 AgentCore sandbox P95 < 35ms，免费。第二个团队放弃 runtime，专注做“Agent Trace for Healthcare”，用 6 个月做出 HIPAA-compliant 的 trace audit dashboard，今年 Q1 拿下 Kaiser Permanente 的 PO。

Anthropic 的 Managed Agents 是一把精准的手术刀，切开了 runtime 层的脓包，但刀锋所指，从来不是 runtime 本身。它是在提醒所有人：当基础设施层被 hyperscaler 压成薄片，真正的价值，永远在你能解决的具体问题之上——在 trace 的可审计性里，在 policy 的可执行性里，在 vertical agent 的可采购性里。

所以，下次看到“XX Agent Platform”融资新闻，别急着看它的 sandbox 启动速度。打开它的官网，找找这三个问题的答案：

• 它的 trace 数据，能迁移到另一个 runtime 吗？
• 它的 policy 规则，能导出为 PDF 交给法务审阅吗？
• 它的 agent，能在 Salesforce AppExchange 或 Azure Marketplace 里，被采购经理一键下单吗？

如果答案是否定的，那它大概率还在 runtime 的沙滩上堆城堡。而浪潮，已经涌向更高处。