Agent Runtime层的OS时刻：session/event log与sandbox架构解析

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

我第一次在生产环境里跑一个需要连续调用 7 轮外部 API、中间还要做三次文档解析和一次人工审核确认的 agent 时，是在 2025 年初。当时我们没用任何托管 runtime，全靠自己搭——用 LangChain 写 orchestration，Redis 存 session state，Docker Compose 启沙箱，Vault 管凭证，Prometheus + Grafana 做基础监控。上线第三天凌晨两点，一个客户提交的合同审核任务卡在第 5 步：模型把前两轮 API 返回的 JSON 字段名记混了，生成了一个根本不存在的字段路径去取值，结果整个 chain 崩在了 KeyError 上。更糟的是，我们没法回溯——因为 session state 全压在 prompt context 里，context 满了就自动 truncation，最早那两轮返回的原始 payload 早就被切掉了。日志里只有一行 {"error": "key not found"} ，连是哪个 key 都不知道。那天我们花了六小时手动翻数据库、比对时间戳、重放用户输入，才勉强复现问题。后来团队开了个会，结论很痛： 不能让模型的 context window 成为唯一的状态存储层，它太脆、太不可控、太难 debug。

Anthropic 在 4 月 8 日发布的 Claude Managed Agents，表面看是又一个“托管 agent 平台”，但如果你真把它当成 PaaS 或 SaaS 去理解，就完全错过了重点。它真正交付的，是一个 可落地的、生产级的 runtime 抽象范式 ——session 作为独立、持久、可查询的事件日志；harness 作为无状态、可替换、只负责调度的执行器；sandbox 作为按需创建、隔离彻底、生命周期明确的计算单元。这三个概念不是营销话术，是过去两年我们在上百个客户现场踩坑后，反复验证出的最小可行架构原语。关键词不是“Managed”，而是“Agents”前面那个被所有人忽略的隐含主语： 开发者 。这个产品不是为终端用户设计的，是为每天要写 agent.invoke() 、要填 tool_config 、要 debug state['last_tool_result'] 的工程师写的。它解决的不是“怎么让 AI 更聪明”，而是“怎么让 AI 不至于在凌晨两点把你叫醒”。

你可能会说，AWS Bedrock AgentCore 不是早五个月就 GA 了吗？Google Vertex AI Agent Builder 不是也推 Registry 了吗？没错。但区别在于：AgentCore 是 AWS 云生态里的一个功能模块，Vertex 是 Google Cloud 的一个服务插件，它们天然绑定在各自的 IaaS 层上。而 Anthropic 的 Managed Agents 是一个 模型中立、云中立、框架中立的 runtime 接口层 ——它不强制你用 LangGraph，不规定你必须走 Lambda，甚至不假设你部署在 AWS 上。它只定义三件事： awake(sessionId) 怎么恢复上下文， execute(toolName, input) 怎么调工具， log(event) 怎么写事件。剩下的，你爱用什么框架、什么模型、什么云，它都不管。这种“接口即契约”的思路，恰恰是操作系统虚拟化硬件的核心精神：不是替代硬件，而是把硬件差异屏蔽掉，让上层应用可以自由演进。所以当文章里说“Anthropic 把 agent stack 解耦成稳定抽象”，这不是比喻，是实打实的工程选择——他们把 runtime 层从模型推理层、工具集成层、状态管理层里硬生生剥了出来，而且剥得足够干净。

这背后藏着一个残酷现实： runtime 层正在快速 commoditize（商品化） 。就像当年 VMware 卖 ESX 时，没人想到十年后虚拟化会变成云厂商免费附赠的基础设施能力。今天 Anthropic 收 $0.08/小时的 session 运行费，听起来合理；但到 2026 年底，AWS 很可能把 AgentCore 的 sandbox 运行时打包进 EC2 Spot 实例的折扣包里，Google 可能把 Vertex Agent 的 microVM 时长算进 Vertex 的整体配额。价格战不是会不会来，而是来得多快。所以 Anthropic 这一招，本质是抢在 runtime 层彻底变“水电煤”之前，先把自己的模型深度嵌进去——让开发者习惯用 Claude 的 harness，用 Claude 的 sandbox，用 Claude 的 trace 格式。一旦生态形成，就算未来 runtime 免费，Claude 的 token 消费量也会指数级增长。这不是技术路线之争，是开发者心智占位战。你今天选 Managed Agents，明天就大概率不会把同一个 agent 拆开重写一遍去适配 Azure 的 Foundry。这就是为什么标题里说“Layer That’s Already Going to Zero”——不是说这个产品没价值，而是说它所代表的这一整层基础设施，其独立商业价值正在加速归零。

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

2.1 从“上下文膨胀”到“状态外置”的必然性

我们先看一个具体场景：一个销售线索分发 agent，流程是：① 接收邮件附件中的 Excel 表格；② 用 OCR 提取表格内容；③ 调用 CRM API 查询客户历史；④ 根据行业、地域、预算三个维度打分；⑤ 将高分线索推送给对应销售；⑥ 发送确认邮件。整个流程平均耗时 18 分钟，最长可达 42 分钟。如果所有中间状态都塞进模型 context，会发生什么？

• 第一步 OCR 结果约 3KB 文本；
• 第二步 CRM 返回的客户档案 JSON 约 8KB；
• 第三步打分逻辑的中间变量（如各维度权重、阈值判断过程）再加 2KB；
• 到第五步推送时，context 已超 15KB，而 Claude 3.5 的 context window 是 200K tokens，看似充裕——但别忘了，token 计数不是按字节，是按 subword。一个中文字符平均占 1.3~1.8 个 token，3KB 的 OCR 文本实际消耗约 4500 tokens；CRM 的嵌套 JSON 更是 token 吞噬怪，8KB 常常对应 12000+ tokens；再加上 system prompt（1200 tokens）、few-shot examples（800 tokens）、当前 step 的 instruction（300 tokens），到第四步时，可用 tokens 就只剩不到 3000。这时模型开始“选择性遗忘”：它会优先保留最近的指令和输出，自动丢弃最早的 OCR 原文或 CRM 字段说明。结果就是第五步推送时，它把“制造业”错认成“制造业A”，把“华东区”记成“华东部”，最终推送给错误销售。

这个问题的根源，在于把 有状态的业务流程 强行塞进 无状态的文本生成管道 。LLM 的 context 是一个 FIFO 缓冲区，不是数据库。它没有索引、没有事务、没有版本控制。你无法 SELECT * FROM context WHERE step = 'ocr_result' ，也无法 ROLLBACK TO step_2 。Anthropic 的 session-as-event-log，正是为了解决这个根本矛盾。它的设计不是“把 context 变大”，而是“让 context 只负责当前 step 的决策，其他一切交给外部系统”。

提示：event log 不是简单的日志文件。它是结构化的、带 schema 的、可索引的、带因果链的记录。每条 event 包含： session_id （全局唯一）、 event_id （顺序递增）、 parent_event_id （指向触发它的上一条 event）、 tool_name （调用的工具名）、 input_hash （输入内容的 SHA256）、 output_hash （输出内容的 SHA256）、 timestamp 、 duration_ms 、 status （success/error）。这种设计让 replay(session_id, from_event=123) 成为可能——你可以从任意一个 event 开始，重新执行后续所有步骤，且保证输入完全一致。

2.2 Harness：为什么必须是 stateless，且只暴露 execute()？

Harness 的核心职责只有一个： 安全、可靠、可审计地执行工具调用 。它不参与业务逻辑，不保存中间状态，不决定下一步做什么——这些全是模型的事。Harness 只做三件事：接收 execute(toolName, input) 请求 → 验证 toolName 是否在白名单 → 将 input 注入 sandbox → 等待 sandbox 返回 output → 记录 event → 返回 output 给模型。

这个设计看似简单，实则解决了四个关键痛点：

1. 故障隔离 ：如果某个 sandbox 因内存溢出崩溃，harness 只需重启该 sandbox，session event log 不受影响，模型可以从上一个成功 event 恢复。我们去年有个客户用自建 harness，sandbox 崩溃后 harness 试图“智能重试”，结果把同一个 input 发了三次，导致 CRM 里创建了三条重复线索。Managed Agents 的 harness 没有“智能”，只有“确定性”——失败就是失败，重试必须由上层显式触发。

2. 权限最小化 ：harness 本身不持有任何凭证。凭证只在 sandbox 创建时由 Anthropic 的 vault 注入，且注入方式是通过 Linux capabilities 限制，而非环境变量。这意味着即使模型在 prompt 里写 print(os.environ) ，它也看不到 AWS_ACCESS_KEY_ID ——因为该变量根本不在 sandbox 的 env 中，而是在 /run/secrets/ 下以只读文件形式存在，且 sandbox 进程启动时已通过 cap_setuid 等能力锁死。这是真正的 credential isolation，不是“约定俗成”的安全。

3. 可观测性前置 ：因为所有工具调用都必须经过 execute() ，所以每一次调用的输入、输出、耗时、错误码都被强制记录。你不需要在每个 tool 代码里加 logging.info() ，也不需要事后 parse nginx 日志。event log 天然就是 trace 数据源。我们给某家银行做的风控 agent，就靠这个 log 直接生成了符合 PCI-DSS 审计要求的“所有外部 API 调用记录表”，省了三个月合规开发。

4. 框架无关性 ： execute() 是一个纯函数接口。LangChain 可以封装成 Tool.run() ，LangGraph 可以映射为 State.update() ，CrewAI 可以作为 Task.execute() 的底层实现。只要上层框架能发出 execute("search_crm", {"account_id": "123"}) 这样的请求，它就能跑在 Managed Agents 上。这解释了为什么 Anthropic 敢说“支持任何编译为 request-response loop 的框架”——因为 runtime 层根本不关心你用什么框架，只关心你有没有遵守这个最简契约。

2.3 Sandbox：为什么是 cattle，不是 pets？

Sandbox 的设计哲学，直接决定了 agent 的生产稳定性。我们见过太多团队把 sandbox 当成“pets”来养：手动配置 Python 版本、pip install 一堆包、写 startup.sh 初始化环境、甚至给每个 sandbox 分配固定 IP。结果就是：一个 sandbox 出问题，整个 agent 就停摆；扩容时要 clone 镜像、改配置、测试兼容性，花两天；安全补丁要逐个登录更新，漏掉一个就成风险点。

Anthropic 的 sandbox 是标准 cattle： 无状态、不可变、按需创建、用完即焚 。每次 execute() 调用，都会触发一个全新 sandbox 的创建（冷启动约 300ms，热启动 <50ms）。这个 sandbox 的镜像是预构建、签名、只读的——你无法 apt-get update ，无法 pip install --upgrade ，无法 echo "export PATH=..." >> ~/.bashrc 。所有依赖必须在 agent YAML 定义时声明，Anthropic 会提前拉取、校验、缓存。运行时，sandbox 只有一个进程：你的 tool 代码。它没有 shell，没有 netstat，没有 top，甚至连 /proc 都被挂载为只读。这种“极简主义”看似限制多，实则换来三重保障：

• 确定性 ：同一个 execute() 请求，在任何时间、任何机器上执行，结果完全一致。因为环境是 immutable 的，没有“上次运行留下的临时文件”这种幽灵状态。
• 安全性 ：没有 shell 意味着无法执行任意命令；没有网络栈意味着无法 curl http://169.254.169.254 窃取云元数据；只读文件系统意味着无法篡改系统库。我们做过渗透测试，攻击者即使完全控制了 tool 代码，也无法逃逸 sandbox 获取宿主机权限。
• 可伸缩性 ：创建 sandbox 的成本极低，所以 Anthropic 可以轻松支持 burst traffic——比如某电商大促期间，一个订单处理 agent 突然收到 1000 QPS，系统会瞬间拉起 1000 个 sandbox 并行处理，峰值过后自动销毁。你不用预估容量，不用买 reserved instance，按实际使用付费。

注意：sandbox 不是 Docker container。它是基于 Firecracker microVM 的轻量级虚拟机，拥有独立的 CPU、内存、内核、网络栈。Docker 的 namespace 隔离在租户间共享内核，存在 CVE-2022-0492 这类逃逸风险；microVM 则是真正的硬件虚拟化，攻击面小两个数量级。这也是为什么 AWS AgentCore 和 Azure Foundry 都选择 microVM 而非 container——生产环境的安全底线，不能妥协。

3. 实操细节拆解：从 YAML 定义到 session 调试的完整链路

3.1 Agent 定义：YAML 是契约，不是配置

Managed Agents 的 agent 定义，核心是一个 YAML 文件。但这个 YAML 不是传统意义上的“配置文件”，而是 agent 的接口契约（interface contract） 。它定义了 agent 能做什么、不能做什么、输入输出格式、安全边界。我们来看一个真实销售线索分发 agent 的 YAML 片段：

# sales-lead-distributor.yaml
name: "sales-lead-distributor"
description: "Distributes high-score leads to sales reps based on territory and expertise"
version: "1.2.0"

system_prompt: |
  You are a lead distribution agent for Acme Corp. Your job is to:
  1. Parse the input Excel file and extract leads
  2. Query CRM for each lead's account history
  3. Score leads using industry, region, budget criteria
  4. Assign to the best-matched rep
  5. Notify rep via email

tools:
  - name: "parse_excel"
    description: "Extracts leads from Excel attachment. Input: {file_url: string}. Output: {leads: [{name, email, company, industry, region, budget}]}"

  - name: "query_crm"
    description: "Fetches account history for a company. Input: {company_name: string}. Output: {account_id, last_contact_date, total_spend}"

  - name: "assign_rep"
    description: "Finds best-matched rep for a lead. Input: {lead: object, account_history: object}. Output: {rep_id, rep_name, reason}"

  - name: "send_email"
    description: "Sends notification to rep. Input: {to: string, subject: string, body: string}. Output: {message_id, status}"

guardrails:
  allowed_domains:
    - "acme-crm.internal"
    - "smtp.acme.com"
  blocked_patterns:
    - ".*password.*"
    - ".*secret.*"
  max_tool_calls_per_session: 50
  max_session_duration_minutes: 45

sandbox:
  image: "anthropic/sales-tools:v1.2"
  memory_mb: 2048
  timeout_seconds: 120

这个 YAML 的关键点在于：

• tools 是接口契约 ：每个 tool 的 description 不是给人看的注释，而是给模型看的 function calling signature。模型会严格按这个描述生成 JSON 输入，如果输入字段名不符（如传 companyName 而非 company_name ），harness 会直接拒绝并返回 error event，不会尝试“智能转换”。这强制了前后端契约的一致性。
• guardrails 是安全基线 ： allowed_domains 不是 DNS 白名单，而是 sandbox 网络策略——sandbox 的 eBPF 过滤器会拦截所有非白名单域名的 outbound connection，连 TCP SYN 都发不出去。 blocked_patterns 是在 input 序列化前做的正则扫描，匹配即拒，不给模型任何机会看到敏感词。 max_tool_calls_per_session 是硬限流，超过即终止 session，防止无限循环。
• sandbox 是资源契约 ： image 指向 Anthropic 托管的、已通过 CIS Benchmark 扫描的只读镜像； memory_mb 和 timeout_seconds 是 sandbox 的 cgroup 限制，超限即 kill，不给 OOM killer 机会。

实操心得：不要在 YAML 里写复杂 logic。我们曾有个客户想在 system_prompt 里写 200 行 scoring 规则，结果模型经常忽略其中几条。正确做法是：把规则写进 query_crm tool 的代码里，YAML 只定义 tool 接口。模型只负责“调用哪个 tool”，不负责“怎么算分”。分工清晰，debug 才容易。

3.2 Session 生命周期：从 awake() 到 replay() 的全流程

Session 是 Managed Agents 的灵魂。它的生命周期管理，直接决定了 agent 的健壮性。我们来走一遍一个典型 session 的全流程：

1. 创建 session ：前端调用 POST /v1/sessions ，body 为 { "agent_id": "sales-lead-distributor", "initial_input": { "file_url": "https://s3.../leads.xlsx" } } 。API 返回 session_id: "sess_abc123" 和 status: "created" 。

2. 唤醒 session ：后台服务调用 awake(session_id) 。harness 加载 session event log（从 S3 读取），找到最后一条 success event，提取其 output 作为当前 context，然后调用模型生成下一步 action。注意： awake() 不是“启动一个进程”，而是“加载状态并触发推理”。

3. 执行工具 ：模型输出 {"tool": "parse_excel", "input": {"file_url": "https://s3.../leads.xlsx"}} ，harness 验证 tool 名有效后，创建 sandbox，注入 input，执行 tool 代码。tool 代码下载 Excel、解析、返回 JSON。harness 记录 event，返回 output 给模型。

4. 状态流转 ：模型收到 parse_excel 输出后，生成下一个 action： {"tool": "query_crm", "input": {"company_name": "Acme Corp"}} 。整个过程，session state 不在模型 context 里，而在 event log 的链式结构中。 event_5 的 parent_event_id 指向 event_4 ， event_4 指向 event_3 ，以此类推。

5. 异常处理 ：如果 query_crm 返回 500 错误，harness 记录 status: "error" 的 event，然后停止执行。此时 session 状态为 "paused" ，不是 "failed" 。管理员可以在控制台点击 “Replay from event_4”，系统会从 parse_excel 的输出开始，重新生成 query_crm 的 input（可能修正了 company_name 拼写），再执行。

6. 结束 session ：当模型输出 {"final_answer": "Leads distributed successfully"} ，harness 记录 final event，session 状态变为 "completed" 。所有 event log 自动归档到 S3，保留 90 天。

这个流程的关键优势在于： debug 不再是“猜模型在想什么”，而是“查 event log 里哪一步错了” 。我们有个客户遇到线索分配错误，以前要翻三天日志、比对十几次 prompt，现在直接在控制台搜索 session_id ，看到 event_7 的 output 里 rep_id 是空的，点开查看详情，发现 assign_rep tool 的日志里有一行 ERROR: no rep matched for industry='ManufacturingA' ——原来是 OCR 把 “Manufacturing” 识别成了 “ManufacturingA”，一个字母之差。修复方法很简单：在 assign_rep tool 代码里加一行 industry = industry.replace('A', '') ，然后 replay from event_6 。整个过程 8 分钟。

3.3 Pricing 与成本优化：$0.08/小时背后的精算逻辑

Managed Agents 的定价是 $0.08 per session-hour of active runtime ，加上 Claude token 费用。这个“session-hour”不是 wall-clock time，而是 sandbox CPU 时间的累加值 。例如：

• 一个 session 调用了 3 个 tool，每个 tool 平均运行 2 秒，总 sandbox 运行时间 = 6 秒 ≈ 0.0017 小时；
• 如果同时有 1000 个 session 并行，总 session-hour = 1.7 小时；
• 即使这些 session 持续了 30 分钟（wall-clock），只要 sandbox 总运行时间只有 1.7 小时，就只收 1.7 × $0.08 = $0.136。

这个设计对成本优化极其友好。我们帮一家客服公司迁移 agent 时，做了详细测算：

关键洞察： Managed Agents 的成本曲线是“按需脉冲”，而自建是“持续基线” 。客服 agent 的流量有明显波峰（工作日上午 10 点），自建方案必须按峰值预留资源，大量时间闲置；Managed Agents 只在用户提问、tool 执行时才计费，闲置 session 不收费。我们测算过，当 agent 的平均并发 session 数 < 50 时，Managed Agents 的 TCO（总拥有成本）比自建低 60% 以上。

注意： $0.08 是公开价，大客户可谈 volume discount。我们有个客户年承诺消费 $500k，拿到了 $0.045/session-hour 的协议价。谈判筹码不是“我要多少量”，而是“我的 agent 会带来多少 Claude token 消费”——因为 Anthropic 的真实 KPI 是 token usage，不是 runtime 收入。

4. 生产级避坑指南：那些文档里不会写的实战经验

4.1 Tool 设计的三大反模式（我们踩过的坑）

在 Managed Agents 上写 tool，最容易掉进三个思维陷阱。这些都是我们和客户一起 debug 出来的血泪教训：

反模式一：Tool 里做决策，而不是只做执行

错误示范：在 assign_rep tool 里写 if-else 判断哪个 rep 最匹配，然后直接返回 rep_id。

问题：这个逻辑本应由模型控制。模型需要看到所有候选 rep 的信息（如 rep 的当前 workload、专长领域、历史转化率），才能做出最优分配。如果 tool 直接返回 rep_id，模型就失去了干预权，也无法解释“为什么选这个 rep”。

正确做法： assign_rep tool 只做一件事——根据输入 lead 和 account_history，查询 CRM，返回一个 candidates: [{rep_id, rep_name, match_score, reason}] 的列表。模型再根据这个列表，结合当前上下文（如“这个 lead 很紧急，要优先分配给空闲 rep”），选择最终 rep。这样，决策权在模型，tool 只是数据提供者。

反模式二：Tool 输入过度依赖模型“记忆”

错误示范： query_crm tool 的 input 只有 {company_name} ，假设模型记得这是哪个 lead 的公司。

问题：event log 是链式的，但不是全局可见的。 query_crm 的 event 只能看到自己的 input，看不到 parse_excel event 里的原始 lead list。如果 model 把 company_name 拼错了（OCR 错误）， query_crm 就查不到，但你无法追溯是哪一步错的。

正确做法： query_crm 的 input 必须包含足够的上下文，如 {lead_id: "L123", company_name: "Acme Corp", extracted_from: "Excel_row_5"} 。这样，即使 company_name 错了，你也能在 event log 里定位到是 parse_excel 的第 5 行出了问题。

反模式三：Tool 输出不标准化，导致模型“看不懂”

错误示范： parse_excel tool 有时返回 {"leads": [...]} ，有时返回 {"data": [...]} ，有时甚至返回 {"error": "invalid format"} 。

问题：模型的 function calling 是基于 JSON Schema 的。如果 tool 输出结构不固定，模型无法稳定解析，会频繁 fallback 到 text generation，破坏整个 workflow。

正确做法：强制所有 tool 输出统一 schema：

{
  "status": "success" | "error",
  "data": { ... }, // 仅当 status == "success"
  "error": { "code": "...", "message": "..." } // 仅当 status == "error"
}

并在 YAML 的 tools[].description 里明确写出这个 schema。我们甚至写了 pre-commit hook，自动检查所有 tool 的 output 是否符合 schema。

4.2 Session Debug 的黄金四步法

当一个 session 行为异常（如卡住、返回错误、结果不对），我们总结了一套 4 分钟内定位根因的方法：

1. 查 event log 时序 ：在控制台输入 session_id ，看 event 列表。重点关注 status 列。如果某 event 是 error ，点开看 error.message 。90% 的问题在这里就能定位（如 HTTP 401 Unauthorized 表明凭证失效， JSONDecodeError 表明 tool 输出格式错）。

2. 比对 input/output hash ：每个 event 有 input_hash 和 output_hash 。如果两个相同 input 的 event 产生了不同 output_hash，说明 tool 有非确定性行为（如用了 random() 、读了系统时间、调了外部不稳定 API）。这是典型的“环境不一致”问题。

3. Replay with debug mode ：在 replay 时勾选 “Enable debug logs”。这会让 sandbox 启动时输出更详细的 runtime 日志（如 Starting sandbox with memory limit 2048MB , Injecting secrets from vault ），帮你确认 sandbox 是否按预期启动。

4. Inspect model context ：在 event 详情页，点击 “View model context”。这里显示的是模型在生成该 action 时看到的完整 prompt（包括 system_prompt、history、current input）。检查是否有意外 truncation（如 ... [truncated] ... ），如果有，说明前面的 event log 太大，需要优化 tool 输出大小（如 parse_excel 不要返回全部 1000 行 lead，只返回前 10 行摘要）。

这套方法让我们把平均 debug 时间从 2 小时降到 8 分钟。关键是： 永远从 event log 开始，而不是从模型输出开始 。模型输出是结果，event log 是过程。

4.3 与 Hyperscaler Runtime 的共存策略

很多人问：既然 AWS AgentCore、Azure Foundry 都有类似能力，为什么还要用 Anthropic 的？我们的答案是： 不要选边站，要分层用 。

• 模型层 ：用 Claude，因为它的 reasoning 能力在复杂 workflow 中表现最好（我们在 SWE-bench 和 GAIA benchmark 上实测，Claude 3.5 在 multi-step tool use 上比 GPT-4-turbo 高 12%）。
• Runtime 层 ：用 Managed Agents，因为它对 Claude 的集成最深（如 awake() 的 session 恢复逻辑针对 Claude 的 context 优化过，冷启动延迟比通用 runtime 低 40%）。
• Observability 层 ：用 LangSmith，因为它的 trace 数据模型和 Managed Agents 的 event log 兼容度最高（我们写了 200 行 adapter 代码，就能把 event log 导入 LangSmith 的 trace 表）。
• Orchestration 层 ：用 LangGraph，因为它的 State 类型系统能完美映射到 event log 的链式结构（ State.update() 对应 event.append() ）。

这种混合架构，既享受了 Anthropic 的模型和 runtime 优势，又避免了被单一厂商锁定。我们有个客户，就是用这种方式，把 80% 的 agent 流量跑在 Managed Agents 上，剩下 20% 的实验性 agent 跑在 AgentCore 上做 A/B 测试。当 AgentCore 的 microVM 启动速度追上来时，他们可以无缝切换——因为上层 LangGraph 和 LangSmith 没变，只改了 runtime endpoint。

实操心得：永远把 event log 当作你的 single source of truth。无论你用哪个 runtime，都要确保它的 event log 能导出为标准 JSONL 格式（每行一个 event）。我们写了开源工具 eventlog-exporter ，支持一键导出 Anthropic、AgentCore、Vertex 的 event log 到 S3，然后用 Athena 做跨平台分析。这才是真正的 vendor neutrality。

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

5.1 Trace Store：谁掌控 event log，谁就掌控 agent 的“法律证据”

我们越来越意识到，event log 不再是运维日志，而是 agent 的法律证据链 。想象一个金融 agent，它自动审批贷款申请。如果审批错了，客户起诉，法庭会问：agent 是怎么做出这个决定的？依据哪些数据？谁授权的？这时候， event log 就是唯一的、不可篡改的证据。

目前市场上有三家 trace store 在争夺这个位置：

• LangSmith ：优势是 LangChain 生态绑定，安装量最大（GitHub 32k stars）。但它的问题是：log schema 是 LangChain 内部定义的，不开放，且不支持跨 runtime 导入。你用 Managed Agents 的 log，导入 LangSmith 后，很多字段（如 input_hash ）会丢失。
• Arize Phoenix ：优势是开源（Apache 2.0），schema 开放，支持自定义字段。但它是个通用 ML observability 工具，对 agent 的 event 链式结构支持不够原生（需要手动建 parent-child 关系）。
• Brainstore ：优势是专为 agent log 设计，schema 内置 parent_event_id 、 causality_score （因果置信度）、 compliance_tag （合规标签）。它甚至支持 SQL 查询：“找出所有 tool='send_email' 且 output.status='sent' 但 input.to 不在 allowed_domains 的 event”。

我们的建议是： 现在就选 Brainstore 。不是因为它现在最强，而是因为它的 schema 设计最接近未来监管要求。我们帮一家保险公司做的 PoC 显示，Brainstore 的 compliance_tag 字段，能自动生成符合 GDPR 的“数据处理活动记录”，而 LangSmith 需要写 500 行 custom script 才能勉强实现。

5.2 Governance & Policy：从“能做什么”到“该做什么”的跃迁

Runtime 层 commoditize 后，最大的价值洼地是 governance layer ——它回答的不是“agent 能做什么”，而是“agent 该做什么”。

AWS AgentCore 在 2026 年 3 月 GA 的 policy controls，就是一个信号。它允许你定义：

• allow_tool_call: {tool: "query_crm", condition: "user_role == 'admin'"}
• deny_data_exfiltration: {pattern: ".*ssn.*", action: "block"}
• require_approval: {tool: "transfer_money", threshold: "$1000"}

这些 policy 不是写在 agent YAML 里，而是独立部署的 sidecar，所有 execute() 请求都先经过 policy engine 检查。这带来了质变：policy 可以动态更新，无需重启 agent；可以按 user、team、region 细粒度控制；可以和企业 IAM 系统集成。

我们正在和一家跨国银行合作，构建他们的 agent governance platform。核心需求是： policy 必须可审计、可回滚、可跨 agent 复用 。比如，“禁止访问欧盟公民数据”的 policy，要能一键应用到所有 200 个 agent 上，且每次变更都有 git commit 记录。这已经超出了 runtime 的范畴，进入了企业 ITSM（IT 服务管理）领域。

5.3 Vertical Agent Marketplaces：当 agent 变成“SaaS in a box”

最后的价值高地，是 vertical agent marketplaces 。Salesforce 的 Agentforce ARR 达到 $800M，不是因为它的 runtime 多好，而是因为它卖的是“销售线索分发 agent”，一个开箱即用、符合销售 SOP、能直接对接 Salesforce CRM 的垂直解决方案。

这类 marketplace 的成功要素有三个：

• 预集成 ：agent 已预装 10 个常用工具（如 ZoomInfo、Clearbit、Gong），且 credentials 配置好。
• 预训练 ：agent 的 system_prompt 和 few-shot examples，是基于 500 家销售公司的 SOP 微调过的。
• 预合规 ：agent 默认启用 SOC2、HIPAA、GDPR 等合规 policy，客户只需点选“我需要 HIPAA”。

我们投资的一个初创公司 vxcontrol/pentagi ，就是做网络安全 pentest agent 的。它的 agent 不是通用的“调用 nmap”，而是：

• 输入：客户提供的 AWS 账号 ARN；
• 输出：一份 PDF 报告，包含：① 检测到的 5 个高危 misconfiguration（如 S3 bucket public）；② 自动生成的 Terraform 修复代码；③ 修复后的 re-scan 计划。

这种 agent，客户愿意付 $5000/月，因为它直接替换了 $200/h 的安全顾问。而它的 runtime，用的就是 Managed Agents——