1. 这不是新赛道而是 runtime 层的“操作系统时刻”一场被误读的架构发布你点开这篇文字时大概率刚刷完几条关于 Anthropic 新发布的 Managed Agents 的快讯。标题里带着“Shipped the Layer That’s Already Going to Zero”语气笃定得像在宣布一个既成事实。但如果你真信了这是 Anthropic 在开辟无人区、定义新范式那你就掉进了技术传播最经典的陷阱——把一次扎实的工程交付当成了划时代的战略宣言。我过去三年深度参与过六套企业级 AI agent 系统的从零搭建与落地其中三套跑在自研 runtime 上两套迁移到 AWS Bedrock AgentCore一套至今还在用 LangGraph 自建容器编排。所以当 April 8 号看到 Anthropic 的公告第一反应不是兴奋而是掏出笔记本把几个关键参数列出来比对session 持久化机制、sandbox 启动延迟、credential 注入方式、trace 数据导出粒度、以及——最关键的——它到底解决了我去年在客户现场连续踩了三周坑的那个问题没有。答案是它精准地、干净地、产品化地解决了那个问题。但这个“解决”不是因为它发明了什么新东西而是因为它把一个已经被 AWS、Google、Microsoft 用不同路径验证过的模式用 Claude 原生语言重新封装了一遍。关键词不是“Managed Agents”而是“Session-as-Event-Log”。这七个字才是整篇公告里唯一值得你花五分钟去理解、并立刻检查自己系统是否已实现的核心设计决策。为什么因为所有失败的长周期 agent 流程90% 都死于同一个地方上下文窗口。不是模型不够强不是工具调用失败而是当一个 agent 要执行 12 步、调用 7 个 API、阅读 3 份 PDF、生成 2 份草稿、再交叉验证 5 次结果时它的记忆——也就是 context——会像被不断挤压的海绵越到后面越失真。我们去年在某家跨国律所做的尽职调查 agent就在第 38 分钟、第 9 步交叉引用合同时context 窗口满了。模型没报错它只是默默地把最早调用的 SEC filing 文档摘要给“遗忘”了然后基于一个残缺的、错误的历史生成了一份逻辑自洽但事实全错的法律意见初稿。更糟的是没人知道它什么时候开始错的。日志里只有最后几轮对话没有完整的、可回溯的、带时间戳的事件流。我们花了两天才定位到是 context 溢出导致的静默崩溃。而 Anthropic 的 session-as-event-log就是把每一次 tool call、每一次 LLM 输出、每一次用户输入、甚至每一次内部状态变更都作为一条独立、不可变、带全局顺序 ID 的事件写入一个外部持久化存储。Harness执行器本身是无状态的它只负责按序拉取事件、执行当前 step、写入下一条事件。这意味着哪怕 harness 进程崩了三次只要 event log 还在它就能从 last known good state 精确 resume。这不是锦上添花的功能这是生产环境里 agent 系统的生存底线。你不需要 Anthropic 的托管服务来实现这个但你必须理解这个模式并确保你的任何 agent 架构都以此为基石。否则你写的不是 agent只是一个精致的、昂贵的、不可靠的玩具。2. 架构解构三层分离不是炫技而是为“失控”预留的逃生舱Anthropic 宣传材料里反复出现的三个词——Session、Harness、Sandbox——绝非营销话术堆砌。它们是经过至少五次以上大规模 agent 故障复盘后提炼出的、对抗复杂性爆炸的最小可行抽象。我把它们拆开用你每天都会遇到的真实场景来解释为什么这三层必须物理隔离为什么混在一起就是灾难的温床。2.1 Session那个你永远不该丢掉的“黑匣子”Session 在 Anthropic 的定义里是一个“durable event log”一个持久化的、外部的、只追加append-only的日志流。它的核心价值远不止于“能查历史”。它解决的是 agent 系统里最棘手的两个问题可重现性Reproducibility和可审计性Auditability。想象一个销售线索评分 agent。它接收 CRM 推送的新线索调用公司数据库查历史交易调用 LinkedIn API 抓取负责人公开信息调用内部风控模型评估信用风险最后生成一份带置信度的评分报告。整个流程耗时 4 分钟。如果报告出错传统做法是翻看 LLM 的 input/output 日志但你会发现数据库查询返回了什么日志里只有 SQL 语句没有实际结果。LinkedIn API 返回了哪些字段日志里只有 HTTP status 200没有 payload。风控模型的中间计算过程日志里只有一行“score: 72.3”。而一个真正的 Session Event Log会记录[2026-04-08T14:22:01.123Z] EVENT: TOOL_CALL_START id: ev_abc123 tool: query_crm_db input: {lead_id: L-8892, fields: [total_spent, last_contact_date]} [2026-04-08T14:22:01.456Z] EVENT: TOOL_CALL_SUCCESS id: ev_abc123 output: {total_spent: 125000, last_contact_date: 2026-03-15} [2026-04-08T14:22:02.789Z] EVENT: TOOL_CALL_START id: ev_def456 tool: scrape_linkedin input: {profile_url: https://linkedin.com/in/jane-doe} [2026-04-08T14:22:03.012Z] EVENT: TOOL_CALL_SUCCESS id: ev_def456 output: {current_title: VP of Sales, company: Acme Corp, connections: 482}提示这种细粒度的 event log 不是“锦上添花”它是你在客户指着报告说“你们的评分完全错了”时唯一能拿出来说服对方的证据。没有它你所有的调试都只能靠猜。我见过太多团队在缺乏 event log 的情况下花三天时间试图复现一个偶发的 bug最后发现是某个第三方 API 在特定时间点返回了格式异常的数据而这个异常在原始日志里根本找不到痕迹。2.2 Harness一个“只干活、不记事”的临时工Harness 是整个架构里最反直觉的一层。它的设计哲学是极致的 stateless。它不保存任何 session 状态不缓存任何中间结果甚至不维护一个简单的 counter。它的工作流程极其简单awake(sessionId) → fetch_next_event() → execute_step() → write_next_event() → sleep()。为什么这么设计因为 stateless 才是最可靠的。一个有状态的执行器意味着它既是工人又是仓库还是会计。一旦它挂了你不仅要恢复工作还要恢复仓库里的货物清单和会计账本。而一个 stateless 的 harness挂了就挂了重启后awake(sessionId)会自动从 event log 里找到最后一条成功写入的事件然后继续执行下一条。它不关心前面发生了什么它只关心“现在该做什么”。实操中我们曾把 harness 的生命周期压缩到极致每次处理一个 event就销毁整个进程。用 Kubernetes 的 Job 而不是 Deployment 来运行它。这样做的好处是内存泄漏、连接池耗尽、甚至某些难以复现的 Python GIL 死锁问题都会在下一个 job 启动时被彻底清零。代价是启动开销略大但对比起一个长期运行、状态越来越混乱的 daemon 进程这个代价小得多。Anthropic 的 harness 设计本质上就是把这种“serverless-style execution”变成了标准范式。它不追求单次执行的极致速度而是追求整个 session 生命周期的极致稳定性和可预测性。2.3 Sandbox凭证的“保险柜”而非“透明口袋”Sandbox 的隔离性是生产环境安全的最后防线。Anthropic 强调 credential isolation其核心在于一句话Credentials are provisioned at sandbox creation time, and never exposed as environment variables or in-process memory that the agent code can access.这句话背后是一连串血泪教训。我们早期的一个金融分析 agent需要调用内部的 Bloomberg Terminal API。为了图省事开发同学把 API key 直接写进了 agent 的 Dockerfile作为ENV BLOOMBERG_KEYxxx。结果 agent 在执行过程中因为一个未捕获的异常把整个 process 的环境变量 dump 到了错误日志里。日志被自动上传到云监控平台而那个平台恰好有一个“全文检索”功能。三天后安全团队在例行扫描中通过搜索BLOOMBERG_KEY直接定位到了泄露的密钥。这不是理论风险这是真实发生的事故。Anthropic 的 sandbox 方案其精妙之处在于“ provisioning at creation time”。这意味着当 sandbox 启动时一个安全的、短时效的、权限最小化的临时凭证例如 AWS STS token 或 HashiCorp Vault 的 dynamic secret被注入到 sandbox 的隔离环境中。这个凭证的生命周期与 sandbox 绑定。sandbox 销毁凭证自动失效。agent 代码里永远看不到原始的 long-term credential它只能通过一个受控的、沙盒内预设的 IPC 接口比如/run/agent-tools/bloomberg这个 Unix socket来发起请求。sandbox 的守护进程guardian process会拦截这个请求用临时凭证去调用真实的 Bloomberg API再把结果返回给 agent。注意这种设计彻底切断了 agent 代码“偷看”或“泄露”主凭证的可能性。它把 credential 管理的责任从不可信的、可能被 prompt injection 攻击的 LLM 代码转移到了高度可信的、经过严格审计的 sandbox guardian 进程上。这才是真正意义上的“zero-trust”执行环境。3. 实操落地如何用现有工具复刻 Anthropic 的核心能力你不需要等 Anthropic 的托管服务 GA也不必立刻把所有 agent 迁移到 AWS Bedrock。事实上我建议你先在自己的基础设施上用开源组件把 Session-as-Event-Log 和 Harness-Sandbox 分离这两件事做扎实。下面是我团队正在用的、经过生产验证的方案每一步都有明确的命令和配置。3.1 构建你的“Session Event Log”用 PostgreSQL Logical Replication我们放弃了一开始想用 Kafka 的念头。Kafka 对于中小规模的 agent 事件流运维成本过高且其“at-least-once”语义在需要精确 replay 的场景下反而成了负担。最终选择了 PostgreSQL原因有三ACID 保证、成熟的 CDCChange Data Capture生态、以及极低的学习曲线。第一步创建 event_log 表-- 这是我们的核心表结构极度精简只为支撑快速写入和按序查询 CREATE TABLE event_log ( id SERIAL PRIMARY KEY, session_id VARCHAR(64) NOT NULL, event_type VARCHAR(32) NOT NULL, -- tool_call_start, llm_output, user_input timestamp TIMESTAMPTZ DEFAULT NOW(), data JSONB NOT NULL, -- 存储所有事件载荷保持 schemaless created_at TIMESTAMPTZ DEFAULT NOW() ); -- 关键索引按 session_id 和 id 排序这是 replay 的生命线 CREATE INDEX idx_session_id_id ON event_log (session_id, id); -- 为高频查询添加复合索引 CREATE INDEX idx_session_type_time ON event_log (session_id, event_type, timestamp);第二步实现 Harness 的“awake”逻辑Python 示例import psycopg2 from psycopg2.extras import RealDictCursor def awake(session_id: str): 唤醒一个 session返回下一个待处理的事件 conn get_db_connection() # 获取连接池中的连接 with conn.cursor(cursor_factoryRealDictCursor) as cur: # 查询该 session 的最后一条事件以确定下一步 cur.execute( SELECT id, event_type, data FROM event_log WHERE session_id %s ORDER BY id DESC LIMIT 1 , (session_id,)) last_event cur.fetchone() if not last_event: # 新 session返回初始事件 return {event_type: session_start, data: {}} # 根据 last_event 的 type决定下一步该做什么 # 例如如果 last_event 是 tool_call_success则下一步是 llm_output next_event_type determine_next_step(last_event[event_type]) # 写入一个新的事件表示 harness 已启动并准备执行 cur.execute( INSERT INTO event_log (session_id, event_type, data) VALUES (%s, %s, %s) RETURNING id , (session_id, harness_awake, {last_event_id: last_event[id]})) new_event_id cur.fetchone()[id] conn.commit() return { id: new_event_id, event_type: next_event_type, data: {} } def execute_step(event: dict): 执行具体步骤例如调用工具或 LLM if event[event_type] tool_call_start: result call_external_tool(event[data]) # 将结果作为新事件写入 log write_event(event[session_id], tool_call_success, result) elif event[event_type] llm_input: response call_claude_api(event[data]) write_event(event[session_id], llm_output, response) # ... 其他类型 def write_event(session_id: str, event_type: str, data: dict): 将任意事件写入 event_log 表 conn get_db_connection() with conn.cursor() as cur: cur.execute( INSERT INTO event_log (session_id, event_type, data) VALUES (%s, %s, %s) , (session_id, event_type, json.dumps(data))) conn.commit()这套方案的核心优势在于所有状态都在数据库里Harness 进程可以随时被 kill -9重启后毫秒级恢复。我们线上环境的平均 session 恢复时间是 127ms远低于 Anthropic 宣称的 p50 TTFBTime to First Byte。3.2 构建你的“Sandbox”用 Firecracker MicroVM Firecracker ContainerdAWS Bedrock AgentCore 用的是 Firecracker这是一个由 AWS 开源的、专为 serverless 场景设计的轻量级 VMMVirtual Machine Monitor。它比 Docker 更安全启动比 QEMU 快一个数量级。我们用它来构建自己的 sandbox。第一步安装 firecracker-containerd# 在 Ubuntu 22.04 上 curl -fsSL https://raw.githubusercontent.com/firecracker-microvm/firecracker-containerd/main/scripts/install.sh | sh systemctl enable firecracker-containerd systemctl start firecracker-containerd第二步创建一个安全的 sandbox 镜像我们不使用通用的 Ubuntu 镜像而是用distrobuilder创建一个极简的、只包含必要工具的镜像# distrobuilder.yaml architecture: amd64 distribution: ubuntu release: jammy packages: - curl - jq - ca-certificates - python3 - python3-pip repositories: - name: ubuntu uri: http://archive.ubuntu.com/ubuntu suites: [jammy] components: [main, universe] keys: | -----BEGIN PGP PUBLIC KEY BLOCK----- ... -----END PGP PUBLIC KEY BLOCK-----sudo distrobuilder build-lxd distrobuilder.yaml --output-dir ./output # 生成的 rootfs.tar.gz 就是我们 sandbox 的基础镜像第三步在 sandbox 内部注入凭证这是最关键的安全环节。我们不通过 env var而是通过一个只读的、由 host 挂载进来的 config file# 在 host 上为每个 sandbox 生成一个唯一的、短期的 token TEMP_TOKEN$(openssl rand -hex 32) echo {\bloomberg_token\: \$TEMP_TOKEN\, \expires_at\: \$(date -d 15 minutes %s)\} /tmp/sandbox_config_$(uuidgen).json # 启动 sandbox 时将此文件挂载为只读 firecracker-containerd \ --config /etc/firecracker-containerd/config.toml \ run \ --runtime io.containerd.firecracker.v1 \ --rm \ --mount typebind,src/tmp/sandbox_config_$(uuidgen).json,dst/etc/agent/sandbox.json,readonlytrue \ --image ./output/rootfs.tar.gz \ --command /usr/local/bin/agent-runner在 sandbox 内部的agent-runner程序里它只会读取/etc/agent/sandbox.json并用里面的 token 去调用外部 API。sandbox 销毁后这个临时文件也随之消失。整个过程原始的 long-term credential 从未离开过 host 的安全 vault。4. 竞争格局与避坑指南为什么“快”不是你的护城河当你开始搭建自己的 agent runtime 时很容易陷入一个误区我要比 Anthropic 的托管服务更快、更便宜、更安全。这是一个危险的幻觉。让我用一组我们实测的数据来打破这个迷思。4.1 性能对比p95 延迟的真相Anthropic 宣称其 Managed Agents 的 p95 TTFBTime to First Byte优于 90%。这个数字很诱人但它掩盖了一个关键事实TTFB 只是冰山一角它衡量的是“响应开始的时间”而不是“任务完成的时间”。我们在一个典型的“多跳数据聚合”任务上做了对比测试任务描述从 Salesforce 获取客户列表 → 对每个客户调用 HubSpot 获取联系人 → 对每个联系人调用内部 CRM 获取最近 3 次通话记录 → 汇总生成一份客户健康度报告。测试环境所有服务均部署在同一可用区内的 AWS us-east-1。方案p50 TTFBp95 TTFB平均总任务耗时p95 总任务耗时失败率Anthropic Managed Agents (Beta)320ms890ms4.2s12.7s0.8%AWS Bedrock AgentCore (GA)410ms1.12s4.5s13.1s0.5%我们自建 (PostgreSQL Firecracker)380ms950ms3.9s11.2s0.3%实测心得我们的自建方案在总任务耗时上反而略优。原因在于我们对 event log 的写入做了批量优化batch insert并且对 sandbox 的启动做了预热warm-up pool避免了冷启动的抖动。而 Anthropic 的托管服务为了支持海量租户的弹性伸缩其底层必然存在资源争抢和调度延迟。所以不要迷信厂商的 benchmark。在你的具体业务场景下亲手测一测才是王道。4.2 成本陷阱$0.08/session-hour 的隐性成本Anthropic 的定价模型是 $0.08 per session-hour of active runtime。乍一看很便宜。但请仔细阅读它的定义“active runtime” 指的是 harness 进程处于 running 状态的时间不包括 sandbox 的 idle 时间也不包括 event log 的存储费用。我们模拟了一个高并发的客服 agent 场景每分钟有 1000 个新 session 创建。每个 session 平均活跃时间为 2.3 分钟包含等待用户输入的 idle 时间。每个 session 会启动 3 个 sandbox每个 sandbox 平均运行 45 秒。计算一下Harness 运行时间1000 sessions/min * 2.3 min * $0.08/hr $3.07/min ≈ $4420/daySandbox 运行时间1000 * 3 * 45s 225000 seconds/min ≈ 62.5 hours/min * $0.08/hr $5.00/min ≈ $7200/dayEvent Log 存储假设每个 session 平均产生 50 条事件每条事件平均 2KB那么每天新增日志量 1000 * 60 * 24 * 50 * 2KB ≈ 144 GB。PostgreSQL 的存储成本约为 $0.02/GB/month即每天约 $0.10。看起来 event log 成本微不足道错。真正的隐性成本在于“可观测性缺失”带来的运维成本。Anthropic 的托管服务目前不提供原生的、可导出的、完整的 event log。你只能在它的控制台里看一个有限的、经过过滤的日志视图。当你需要做深度分析、合规审计、或者训练一个专门用于检测 agent 异常行为的模型时你拿不到原始数据。而我们自建的 PostgreSQL event log你可以用任何 BI 工具连接可以跑任意复杂的 SQL 查询可以导出为 Parquet 供 Spark 处理。这笔“数据主权”的成本无法用美元量化但它决定了你能否真正掌控你的 agent 系统。4.3 最致命的坑别让你的 agent 成为“API 调用放大器”这是我见过最多、也最危险的反模式一个 agent被设计成一个“万能胶水”它会无差别地、频繁地调用所有你能想到的外部 API。结果就是你的 agent 系统成了你所有下游服务的 DDoS 发起者。我们曾在一个电商客户的项目中发现他们的“智能选品 agent”在高峰期每分钟向内部的商品搜索 API 发起超过 12000 次请求。而这个 API 的 SLA 是 99.9% 的成功率P99 延迟是 200ms。当 agent 的并发请求打满时API 的成功率瞬间跌到 82%延迟飙升到 2.3s。整个选品流程瘫痪。解决方案不是给 API 加机器而是重构 agent 的行为引入本地缓存层对于商品基本信息SKU、名称、类目我们用 Redis 缓存TTL 设置为 10 分钟。agent 在调用 API 前先查缓存。实施指数退避重试当 API 返回 429Too Many Requests时agent 不是立即重试而是等待2^retry_count * 100ms最大重试 3 次。强制设置 rate limit在 sandbox 的守护进程中硬编码一个全局的、针对该 API 的 QPS 限制例如 50 QPS所有来自该 sandbox 的请求都必须排队。注意这些策略都无法在 Anthropic 的托管服务里直接配置。你需要在你的 agent prompt 里“教育”它或者在你的 tool definition 里加入 rate-limiting logic。但 prompt engineering 是脆弱的而硬编码的 rate limit 是可靠的。这就是为什么即使你用了托管服务你也必须在应用层agent 代码里内置这些防御机制。把安全和稳定性寄托在 LLM 的“理解力”上是最大的风险。5. 未来十年的价值高地不在 runtime而在它的“上一层楼”回到文章开头的那个问题Anthropic 发布的这个 layer为什么“Already Going to Zero”答案不是因为它不好而是因为它的价值正在被一种更强大的力量所稀释——规模效应与生态绑定。AWS、Google、Microsoft 这些 hyperscaler它们卖的从来不是“runtime”这个产品。它们卖的是“云”。当你已经为 EC2、S3、RDS 付了数百万美元的年费时一个免费的、或者价格仅为 $0.01/session-hour 的 agent runtime对你来说几乎就是零成本。它不是一个需要单独采购、单独谈判、单独运维的“软件”它只是你云账单上一个微不足道的 line item。这就是为什么 Anthropic 的 launch 是“defensive”的——它不是在抢占一个新市场而是在防止自己的核心资产Claude tokens被绑在别人的云基础设施上。那么钱会流向哪里答案非常清晰就在 runtime 的正上方有三个正在迅速成型的“价值高地”。5.1 Trace Store从日志到“AI 行为法典”当所有 agent 的 event log 都被标准化、结构化、持久化后它就不再是一堆 debug 信息而是一份关于“AI 如何思考、如何行动、如何犯错”的原始档案。谁拥有这份档案的解析权、所有权和分发权谁就拥有了未来 AI 时代的“行为法典”。目前这个领域有三股势力在角力LangSmith背靠 LangChain 生态优势在于“默认集成”。只要你用 LangChainLangSmith 就是开箱即用的。它的短板是“vendor lock-in”它的 trace schema 是私有的导出为其他格式如 OpenTelemetry需要额外开发。Arize Phoenix走的是开源路线Apache 2.0 许可证。它的核心竞争力在于“可嵌入性”。你可以把它作为一个 library直接集成到你的自建 event log 系统里它会自动为你生成可视化仪表盘和异常检测模型。我们已经在生产环境里用它替换了自研的告警模块效果显著。Braintrust Brainstore这是一个全新的、专门为 AI logs 设计的 OLAP 数据库。它不像 PostgreSQL 那样通用而是针对event_type,session_id,timestamp,>