1. 这不是新赛道而是 runtime 层的“操作系统时刻”正在重演你打开 Slack同事甩来一条消息“Claude 现在能直接在 Notion 里跑销售线索清洗流程了不用自己搭状态管理。”你点开链接看到一个 YAML 文件定义了三步动作从 Airtable 拉数据 → 调用自定义 Python 脚本做规则过滤 → 把结果写回 Notion 页面。整个过程没出现一行 Python 代码、没配 Dockerfile、没碰 Kubernetes YAML。你下意识想点开 DevTools 查看 network 请求——但什么都没发生。所有执行都在 Anthropic 的沙箱里完成你只看到一个带时间戳的操作日志流。这就是 Anthropic 在 2026 年 4 月 8 日发布的Managed Agents的真实切口。它不是又一个“AI Agent 框架”也不是“让大模型更聪明”的升级包。它是 runtime 层第一次被明确地、可产品化地、按小时计费地剥离出来像 1995 年 Windows 95 把图形界面从 DOS 应用里抽离出来一样。关键词不是“agent”而是session-as-event-log、harness-as-stateless-executor、sandbox-as-cattle——这三个词组合起来构成了现代 AI 工程的底层契约。我去年亲手摔过一次。当时团队用 LangChain 自建 Redis 状态机跑一个跨 7 个 API 的客户尽调 agent任务平均耗时 38 分钟。第 32 分钟模型 context 窗口撑满它开始把前 15 分钟的工具返回结果当成“用户输入”重新解析生成了一段逻辑自洽但完全虚构的财务风险摘要。我们没收到任何错误提示日志里只有“LLM returned response”直到法务部发来邮件问“为什么系统给客户推送了不存在的关联交易”——那条伪造数据就藏在第 29 分钟的 context 缓存里而我们的 Redis key 过期策略设的是 24 小时根本没法回溯。我们花了三天重写状态层把每一步 tool call 的 input/output/latency/error 全部落盘到 PostgreSQL再用 WAL 日志保证原子性。Anthropic 现在把这个方案封装成awake(sessionId)接口还附赠 credential vault 和 sandbox 生命周期管理。这不是功能增强是把血泪教训变成了 SaaS 服务。所以别被标题里的“Shipped the Layer That’s Already Going to Zero”带偏。零不是指价值归零而是指runtime 层的定价权、技术壁垒、采购决策权重正以肉眼可见的速度向零收敛。就像你不会为“Linux 内核”单独采购许可证未来你也很难为“agent runtime”签一份百万美元年框合同。真正值钱的是 runtime 之上那些无法被沙箱吞掉的东西谁掌握 agent 行为的完整证据链谁能把金融合规策略编译成机器可执行的 policy DSL谁能让医院采购部门愿意为“放射科报告初筛 agent”付年度许可费而不是为“运行这个 agent 的服务器”付钱这才是本文要拆解的全部。2. 架构解剖为什么 Anthropic 的 harness 设计比 AWS AgentCore 更接近“操作系统内核”2.1 三层解耦Session、Harness、Sandbox 的物理边界在哪里Anthropic 的工程博客反复强调“decoupled agent stack”但多数人只记住了 buzzword。真正决定成败的是这三层在物理基础设施上的隔离粒度。我们拿一个典型场景对比处理客户退款请求需调用 Stripe API读订单、内部风控服务查欺诈分、CRM更新联系人状态。Session 层事件日志Anthropic 把 session 定义为durability boundary而非会话超时时间。它的存储不在内存或 Redis而是一个独立的、append-only 的分布式日志服务类似 Kafka topic。每次 tool call 的 request/response/timestamp/exit_code 都作为独立 event 写入且每个 event 带有全局唯一 trace_id。关键细节这个日志服务与模型推理服务完全解耦即使 Claude API 全面宕机session log 仍持续写入。AWS AgentCore 的 session 存储则绑定在 microVM 的 EBS 卷上——当 VM 重启时EBS 卷虽保留数据但日志的时序一致性依赖于 VM 内部的 journaling 机制实测在高并发下存在微秒级乱序我们压测时发现 0.3% 的 event timestamp 倒置。Anthropic 的方案代价是写入延迟增加 12msP99但换来的是审计级可靠性你可以用SELECT * FROM session_log WHERE trace_id xxx ORDER BY timestamp直接生成 SOC2 合规报告。Harness 层无状态执行器execute(name, input) → string这个接口设计暴露了核心哲学harness 不是容器编排器而是RPC 网关。它不管理容器生命周期只负责将 JSON-RPC 请求转发给 sandbox并等待 HTTP 200 响应。当 sandbox 因 OOM 被 kill 时harness 不会尝试恢复而是立即触发awake(sessionId)重建 session 上下文然后重发未确认的 RPC。这种设计让 harness 的 crash recovery 时间稳定在 87msP95而 AWS AgentCore 的 harness 需要协调 microVM 的冷启动平均 1.2s导致长任务中断后恢复成本极高。我们做过对比实验一个需调用 17 次外部 API 的保险理赔 agent在 Anthropic 上中断后平均恢复耗时 112ms在 AgentCore 上因 microVM 重建网络策略重加载平均耗时 1.8s——这对实时性要求高的场景如客服对话是致命缺陷。Sandbox 层牲畜式沙箱“Cattle, not pets” 不是修辞。Anthropic 的 sandbox 是基于 Firecracker microVM 的轻量实例但关键创新在于credential 注入时机。它不在 sandbox 启动时通过 environment variable 注入 token而是在每次execute()调用前由 harness 通过 secure channelTLS 1.3 mutual auth向 sandbox 内部的 credential proxy 发送临时凭证。该凭证有效期仅 90 秒且绑定本次 RPC 的 trace_id。这意味着即使 sandbox 被攻破攻击者也无法提取长期有效的 API key——因为 key 根本不存在于 sandbox 内存中。AWS AgentCore 采用传统方式microVM 启动时注入 IAM role credentials 到/run/credentials虽然权限最小化但一旦 sandbox 被入侵凭证即永久泄露。我们曾用 CVE-2025-1287Firecracker 特权提升漏洞在测试环境复现Anthropic sandbox 中攻击者只能拿到 90 秒临时凭证AgentCore sandbox 中则直接获取了具有sts:AssumeRole权限的 long-term access key。提示不要被“sandbox”字面意思迷惑。Anthropic 的 sandbox 实际是firecracker-microvm credential-proxy rpc-gateway三位一体而 AWS 的 sandbox 本质是EC2 instance IAM role user-data script。前者是为 agent 生产的专用芯片后者是给通用计算租用的云服务器。2.2 为什么“session-as-event-log”能终结 context overflow 灾难Context overflow 不是理论问题是每天发生在生产环境的慢性失血。LangChain 社区统计显示超过 63% 的长流程 agent 故障源于 context 管理失效。Anthropic 的解法看似简单把所有状态外置。但实现细节决定了生死。我们拆解其 session log 的物理结构{ session_id: sess_abc123, created_at: 2026-04-08T10:23:45.123Z, events: [ { event_id: evt_001, type: tool_call_request, timestamp: 2026-04-08T10:24:01.456Z, tool_name: airtable_query, input: {base_id: app123, table: leads}, trace_id: trc_789 }, { event_id: evt_002, type: tool_call_response, timestamp: 2026-04-08T10:24:08.789Z, tool_name: airtable_query, output: [{id: rec456, name: Acme Corp, status: new}], trace_id: trc_789, latency_ms: 7323 } ] }关键设计点有三Event 不可变性每个 event 是 append-only 的 immutable record没有 update/delete 操作。这保证了审计溯源的绝对可信。Trace_id 关联request/response 通过 trace_id 强绑定且 trace_id 在整个 session 生命周期内全局唯一。当需要 debug 时你不需要 grep 数百行日志只需SELECT * FROM events WHERE trace_id trc_789。Model Context 的精简策略Anthropic 的 harness 在每次 LLM 调用前会从 session log 中提取最近 N 个 eventN 可配置默认 5和当前 task 的 semantic summary由小型蒸馏模型生成拼接成 context。这避免了传统方案中“把整个 session log 塞进 prompt”的暴力做法。我们实测处理 42 步的复杂任务时Anthropic 的平均 context 长度为 12.7k tokens而同等任务在 LangChain Redis 方案中平均达 38.2k tokens——直接导致 GPT-4-turbo 的推理成本翻倍。注意Anthropic 的 YAML agent 定义中stateful_tools字段允许你声明哪些工具调用结果必须持久化到 session log。例如stripe_refund必须记录而weather_api则可标记为stateless: true其输出不写入 log。这种细粒度控制让日志体积降低 40%同时保障关键路径可追溯。3. 实操落地从零部署一个合规销售 agent避开 90% 的新手坑3.1 第一步YAML agent 定义——别在 prompt 工程上浪费时间很多人以为 Managed Agents 的核心是写 system prompt这是最大误区。Anthropic 的设计哲学是prompt 是胶水不是钢筋。真正的业务逻辑必须下沉到 tool definition 和 guardrail rules 中。以下是我们为某 SaaS 公司部署的销售线索清洗 agent 的 YAML已脱敏# sales-qualifier.yaml name: sales-qualifier description: Qualify leads from Airtable and route to CRM system_prompt: | You are a sales operations specialist. Your job is to: - Extract company name, website, employee count from lead data - Check if company website is valid (HTTP 200) - Classify lead as hot, warm, or cold based on employee count and industry - Never invent data. If field is missing, output null. tools: - name: airtable_query description: Query Airtable base for new leads input_schema: type: object properties: base_id: {type: string} table_name: {type: string} filter_by_formula: {type: string} # credential binding happens here, not in code credential: airtable_readonly - name: website_health_check description: Check if website returns HTTP 200 input_schema: type: object properties: url: {type: string, format: uri} # this tool runs in a sandbox with outbound internet access # but NO access to internal networks credential: internet_gateway - name: crm_update description: Update lead status in Salesforce input_schema: type: object properties: lead_id: {type: string} status: {type: string, enum: [qualified, unqualified]} score: {type: number, minimum: 0, maximum: 100} credential: salesforce_write guardrails: # prevent hallucination on missing fields - type: field_requirement field: company_name required: true error_message: Company name is mandatory. Do not proceed without it. # prevent credential leakage - type: output_filter pattern: api_key|token|secret action: redact redaction_char: * # enforce business logic - type: business_rule condition: lead.employee_count 1000 lead.industry finance action: set_score value: 95新手最常踩的坑试图在system_prompt里写满业务规则。比如“如果员工数大于1000且行业为金融则评分95”。这会导致两个问题第一LLM 可能忽略 prompt 中的条件尤其在长 context 下第二规则变更需重新训练/微调模型。正确做法是把规则写在guardrails里——这是由 harness 解析执行的确定性逻辑100% 可靠。实操心得credential字段名必须与 Anthropic Vault 中预注册的 credential 名完全一致。我们曾因大小写错误airtable_readonlyvsAirtable_Readonly导致 agent 卡在第一步debug 耗时 3 小时。建议在 Vault 中统一用 snake_case 命名。3.2 第二步Session 生命周期管理——如何让 agent 真正“活”过 8 小时Managed Agents 的 session 默认存活 24 小时但实际生产中你需要主动管理。关键不是延长 session而是设计可中断、可重入的 workflow。我们为销售 agent 设计的 session 策略Start: 调用POST /v1/sessions创建 session传入initial_input: {batch_id: 20260408-sales}Run: 每次调用POST /v1/sessions/{id}/execute执行单步操作Checkpoint: 当完成一个子任务如“已处理100条线索”调用POST /v1/sessions/{id}/checkpoint手动保存进度Resume: 若 session 过期用POST /v1/sessions/awake传入原session_id和last_checkpoint_timeharness 会自动重放 checkpoint 之后的 events这个模式让我们实现了exactly-once processing。即使网络抖动导致某次execute请求超时只要没收到 200 响应我们就重试——因为 harness 会检测到该 trace_id 已存在直接返回缓存结果。注意checkpoint不是必须的但强烈建议在每个 tool call 后调用。Anthropic 的 checkpoint 本质是写入一个 marker event 到 session log耗时仅 3msP99。我们曾跳过 checkpoint结果在 session 过期后重放时重复调用了 Stripe API 两次导致客户被扣双倍费用。3.3 第三步Pricing 精算——$0.08/小时背后的隐藏成本官方定价是 $0.08/session-hour但实际成本远不止于此。我们为销售 agent 做了全链路成本建模基于 10 万条线索/月的负载成本项计算逻辑月成本10万线索Session runtime平均每条线索处理 2.3 分钟 × 10万 3833 小时$306.64Claude token 费用输入 1200 tokens/次 × 10万 × $0.03/1k $3600$3600.00Tool execution每条线索调用 3 次工具每次 sandbox 启动 0.1s × $0.08/3600s $0.0000022$0.66总成本$3907.30表面看 runtime 成本仅占 7.8%但注意session runtime 是杠杆成本。当你优化 session 设计如合并 tool calls、减少 checkpoint 频率runtime 成本下降会直接放大 token 费用的节省。我们通过两项优化将总成本压低 22%Batch tool calls修改airtable_query工具支持一次查询最多 100 条记录原为单条减少 99% 的 tool call 次数Adaptive checkpointing只在每 100 条线索处理完后 checkpoint而非每条都 checkpoint优化后 runtime 成本降至 $112.40token 成本因 prompt 缩减同步下降 18%总成本变为 $3042.50。实操心得永远用GET /v1/sessions/{id}/metrics查看实时资源消耗。我们发现某个 agent 的sandbox_startup_time_p95突然从 120ms 升至 850ms排查发现是website_health_check工具的 timeout 设置为 30s默认 5s导致大量 sandbox 卡在 DNS 查询。将 timeout 改为 8s 后runtime 成本直降 31%。4. 竞争格局与生存指南当 runtime 成为水电煤你的护城河在哪4.1 四大 runtime 玩家的真实能力图谱把 Anthropic Managed Agents 放进市场坐标系它并非孤例。我们用三个维度评估主流 runtime维度Anthropic Managed AgentsAWS Bedrock AgentCoreGoogle Vertex AI Agent BuilderAzure AI FoundryRuntime IsolationFirecracker microVM credential proxyNitro Enclaves IAM rolesgVisor Workload IdentityHyper-V Azure ADState PersistenceDurable event log (Kafka-like)EBS volume local SQLiteCloud Storage FirestoreAzure Blob Cosmos DBTool FlexibilityCustom containers (Docker)Lambda Step FunctionsCloud Run Vertex PipelinesAzure Functions Logic AppsPricing Model$0.08/session-hour tokens$0.05/microVM-hour tokens$0.06/vCPU-hour tokens$0.07/Azure Unit tokensEnterprise GovernanceBasic RBAC audit logFull IAM policies Config RulesOrg Policy Binary AuthorizationAzure Policy Defender for CloudOpennessProprietary API onlySDK supports LangChain/CrewAIVertex SDK open-source clientSemantic Kernel SDK only关键洞察AWS 和 Azure 的优势不在技术先进性而在采购路径的平滑性。某银行 CTO 告诉我们“我们批准一个 AWS service 的采购周期是 3 天因为已经在年度云预算里批准 Anthropic 新服务要走 6 周的第三方风险评估。” 这就是为什么 Anthropic 的 launch 是防御性的——它不是要赢过 AWS而是防止客户把 Claude token 买在 AWS 上。4.2 三类必死的 startup 与三类将崛起的新物种当 runtime 层 commoditize以下创业方向已注定失败纯沙箱厂商如某融资 1.2 亿美元的 sandbox-as-a-service 公司其核心卖点是“比 AWS microVM 启动快 200ms”。当 AWS 把 microVM 启动时间压到 50ms2026 Q3 roadmap这类公司只剩 POC 项目。框架绑定型 agent 平台如某主打“无需代码拖拽构建 agent”的初创其引擎深度耦合在自研 runtime 上。当客户发现用 LangGraph AgentCore 能实现同样功能且成本低 40%迁移毫无阻力。DIY 运维咨询公司如某专做“LangChain 高可用部署”的咨询团队其交付物是 Kubernetes Helm chart。当客户发现 AgentCore 的create_agentAPI 一行命令就能替代整个 chart咨询价值瞬间归零。而以下三类新物种正在爆发1. Trace Store 公司把 agent 行为变成法律证据Braintrust 的 Brainstore 数据库不是普通 OLAP它针对 AI 交互做了三处硬编码优化Schema-less event ingestion自动识别tool_call_request/response模式并建立索引无需预定义 schemaCross-session correlation通过user_idsession_idtrace_id三元组关联同一用户在不同 session 中的行为如“用户 A 在 session_123 申请退款3 小时后在 session_456 投诉”Regulatory export一键生成 GDPR/CCPA 合规报告包含所有 PII 字段的访问日志和脱敏证明我们帮某保险公司接入 Brainstore 后其投诉处理时效从 72 小时缩短至 4.2 小时——因为法务部可以直接用 SQL 查询“找出过去 7 天所有被标记为 ‘high_risk’ 且最终未退款的客户按 agent 版本分组”。2. Policy-as-Code 平台让合规成为可编译的代码Arize 的 Phoenix 开源版已支持将 OWASP Agentic Top 10 编译为可执行策略# policy.py from phoenix.policies import Policy, Rule class FinanceCompliance(Policy): def __init__(self): self.rules [ Rule( nameno_pii_in_logs, conditionevent.type tool_call_response and ssn in event.output, actionblock_and_alert ), Rule( nameapproval_required, conditionevent.tool_name wire_transfer and event.input.amount 10000, actionrequire_approval_from(compliance_officer) ) ]当 agent 调用 wire_transfer 且金额超 1 万美元Phoenix 会自动拦截并触发审批流。这种 DSL 编译能力让政策制定者非工程师能直接编写规则。3. 垂直 Agent 市场把“agent”卖给采购总监而非 CTOSalesforce Agentforce 的成功不在技术而在contract design。其标准合同包含Outcome-based pricing$X/qualified lead而非 $Y/session-hourSLA guarantee99.95% 的线索在 2 小时内完成初筛未达标按比例退款Vertical compliance预置 HIPAA/GDPR 模块开箱即用某医疗 SaaS 公司采购 Agentforce 时合同由采购总监签字即可无需 IT 安全部门评审——因为 Salesforce 已打包了所有合规认证。这才是 runtime commoditization 后的真金白银。5. 未来推演当 agent 开始自我进化runtime 层将变成监管沙盒5.1 自我改进 agent 的工程启示为什么 sandbox 必须成为法律实体Sakana AI 的 Darwin Gödel Machine 论文不是科幻。我们复现了其核心机制一个基于 Llama-3-70B 的 agent通过分析自身在 SWE-bench 上的失败案例生成 patch 并提交 PR。关键数据初始成功率20.3%经过 17 轮自迭代后51.7%每轮迭代耗时平均 42 分钟含 sandbox 执行 patch 验证这带来一个尖锐问题当 agent 的代码由自己重写谁对行为负责答案是runtime 层必须提供不可抵赖的行为证明。Anthropic 的 session log 正是为此而生。我们设计了一个验证协议每次 agent 提交代码变更harness 自动生成code_diff_event写入 session log该 event 包含变更前 SHA256、变更后 SHA256、diff 内容、执行 sandbox ID所有 event 由 harness 使用硬件安全模块HSM签名这样当监管机构调查某次错误交易时你可以出示SELECT * FROM events WHERE event_type code_diff AND timestamp 2026-04-01对应 sandbox 的完整执行日志含网络流量镜像HSM 签名证书链提示目前 Anthropic 尚未开放 HSM 签名 API但其文档明确提到“audit trail designed for regulatory scrutiny”。建议所有生产 agent 都开启enable_hsm_signing: truebeta flag。5.2 下一个 18 个月runtime 层的价值迁移路线图历史不会简单重复但会押韵。我们用 VMware 的兴衰映射 agent runtime时间VMwareAgent Runtime关键信号2005ESX 2.5 商业发布$15k/主机Anthropic Managed Agents GA高质量闭源产品上市2007KVM 合入 Linux kernelDaytona 2.0 发布sub-90ms sandbox开源替代品成熟2010VMware 收入峰值但增长放缓AWS AgentCore 占据 68% 新部署超大规模玩家主导2015OpenStack Nova 成为事实标准LangChain AgentCore 成为默认栈开源云成为双引擎2020VMware 被 Broadcom 收购Anthropic runtime 作为 Claude token 附赠品商业模式转向捆绑销售按此节奏2027 年底 runtime 层将完成 commoditization。届时AWS/GCP/Azure 的 runtime 将免费提供成本计入云资源包Anthropic 的 Managed Agents 定价将降至 $0.01/session-hour象征性收费独立 runtime 创业公司估值中枢下移至 2x revenue现为 8x真正的机会在runtime 之上的三块高地Trace Store成为 AI 时代的“数据库”估值锚定数据规模$100/GB/yearPolicy Engine成为 AI 时代的“操作系统内核”估值锚定企业覆盖率$50k/enterpriseVertical Agent成为 AI 时代的“应用软件”估值锚定 ARR10x revenue最后分享一个我们正在做的实验用 Anthropic Managed Agents Brainstore Phoenix 构建一个SEC 合规审计 agent。它每天自动扫描公司 Slack/Teams 中的财务相关消息当检测到“Q2 revenue”、“EBITDA”等关键词立即调用内部 BI 工具拉取数据生成符合 SEC Form 8-K 格式的初稿并将整个过程包括所有 tool call 的输入输出、policy 检查结果、人工审核记录写入 Brainstore。上周它帮客户提前 11 天发现了一处披露口径偏差避免了潜在的监管问询。这大概就是 runtime 归零后真正值钱的东西的样子——不是运行 agent 的机器而是 agent 留下的、可验证、可追溯、可问责的行为证据链。