1. 这不是新赛道而是 runtime 层的“操作系统时刻”——一场静默却决定生死的基础设施战争你有没有试过让一个 AI 代理连续工作四十分钟不是闲聊不是写诗而是真正在做事情查数据库、调 API、读文档、写代码、改配置、发 PR。我去年就带着团队跑过这样一个销售线索清洗客户画像生成邮件草稿初稿的端到端流程。前35分钟一切顺利第38分钟模型突然开始胡说八道——它把三天前某次失败的 API 调用返回的错误 JSON 当成了有效数据还据此生成了一封向客户道歉的邮件。我们翻日志、看 trace、重放 prompt全无头绪。最后才发现不是模型坏了是它的“记忆”被挤掉了。那个长达4000 token 的 session 历史在第39分钟时被硬生生从上下文窗口里“踢”了出去。模型没报错它只是安静地、自信地基于一个残缺的、被截断的历史继续编故事。我们丢了整个 session无法回溯无法重放更无法 debug。那不是一次故障是一次无声的蒸发。Anthropic 在 4 月 8 日发布的 Claude Managed Agents表面看是一套托管运行时但它的核心价值就藏在那个被工程博客反复强调、却被媒体通稿轻轻带过的词里session-as-event-log。这不是一个功能点而是一个范式转移的锚点。它意味着AI 代理的状态state终于从模型那脆弱、昂贵、容量有限的上下文窗口里被彻底解放出来落到了一个持久化、可查询、可审计、可重放的外部存储上。这就像 1990 年代操作系统把硬件资源虚拟化一样——CPU、内存、磁盘不再由每个程序自己去抢、去管、去猜而是由 OS 统一抽象、调度、隔离。今天Anthropic 正在为 AI 代理世界做同样的事把 session会话、harness执行器、sandbox沙箱这三个关键概念拆解成清晰、稳定、彼此解耦的接口。Harness 可以挂掉只要 event log 还在它就能awake(sessionId)一键复活Sandbox 可以像牛群cattle一样被秒级销毁重建而不是像宠物pets一样需要精心呵护Credentials凭证被锁在 vault 里永远不碰 sandbox 的边界。这背后没有魔法只有一套经过生产环境千锤百炼的、对“状态管理”和“执行隔离”这两座大山的系统性攻克。关键词Towards AI - Medium所代表的正是这种深度技术观察的土壤。它不满足于告诉你“Anthropic 发布了什么”而是要撕开 PR 稿的糖衣问一句它为什么必须这样设计它解决了谁的什么痛它的对手在哪里它的未来又在何方这篇文章就是一份来自一线架构师视角的“runtime 层战地报告”。它不面向只想尝鲜的爱好者而是写给那些正在自己的服务器上部署 LangGraph、在 Kubernetes 里手搓 sandbox、或者正为“如何让代理安全地访问公司内部 API”而彻夜难眠的工程师和 CTO。如果你正站在这个十字路口这篇文章的价值可能远超你此刻的预期。2. 核心设计与思路拆解为什么是“解耦”而不是“堆砌”2.1 “Session-as-Event-Log”一场关于“状态主权”的革命让我们先直面那个最根本的痛点AI 模型的上下文窗口从来就不是一个合格的数据库。它的设计初衷是承载“当前对话的语境”而不是“一个长达数小时、跨越数十次工具调用的完整工作流历史”。把它当数据库用就像用咖啡杯去盛装整条长江——杯子再精致也改变不了它物理容量的极限。Anthropic 的“session-as-event-log”模式其精妙之处不在于它有多炫酷而在于它回归了最朴素的工程常识将状态State与计算Computation彻底分离。State状态所有关于这个 session 的信息——用户初始请求、每一次 tool call 的输入/输出、模型的每一轮思考thought、guardrail 的每一次拦截、甚至每一次 token 的消耗明细——都被序列化为结构化的事件event并持久化到一个高可用、低延迟的外部存储中很可能是他们自研的分布式日志系统类似 Kafka S3 的混合体。这个存储是 durable持久的、queryable可查询的、immutable不可变的。你可以随时GET /sessions/{id}/events?fromtimestamp来拉取任意一段历史也可以用 SQL-like 语法SELECT * FROM events WHERE session_id xxx AND type tool_call AND status success来做深度分析。Computation计算Harness执行器则变成了一个纯粹的、无状态的函数。它只做一件事接收一个sessionId和一个input通常是用户的最新消息或一个待处理的事件然后根据当前 session 的最新 event log调用模型生成下一步 action比如execute(search_db, {query: Q1 sales})并将这个 action 作为一个新的 event 写入 log。Harness 本身不保存任何状态它的内存里只有“此刻需要处理什么”。这意味着Harness 实例可以像 Web Server 一样水平扩展、滚动更新、甚至瞬间崩溃重启只要它能重新读取 event log整个 session 就能无缝续上。提示这种设计的直接好处是灾难恢复能力。想象一下你的 Harness 集群因为一次意外的 Kubernetes 升级而全部宕机。传统方案下所有正在运行的 session 全部丢失用户只能重来。而在 Anthropic 的模式下只要 event log 存储还在新启动的 Harness 就能awake(sessionId)从最后一个成功的 event 开始精准续跑。这不再是“尽力而为”而是“确定性恢复”。这种解耦带来的第二个巨大优势是可观测性Observability的质变。在旧模式下你想知道一个 session 为什么失败你得去翻 Nginx 日志、翻模型服务日志、翻工具调用日志再把它们在时间线上手动对齐这过程堪比福尔摩斯探案。而在 event log 模式下所有信息天然就在一条时间线上且自带 context。一个失败的tool_call事件旁边就紧跟着它前面的model_thought事件模型说“我要调用 search_db”和它后面的guardrail_violation事件安全策略说“禁止访问敏感表”。你不需要推理你只需要阅读。2.2 “Harness as Stateless Executor”从“智能体”到“智能管道”Harness 的“无状态”属性是整个架构得以轻盈、可靠、可扩展的基石。它彻底剥离了所有与“智能”无关的负担成为一个纯粹的、高效的“智能管道”。它不负责记忆所有记忆都在 event log 里。它不负责安全所有 credential 注入、网络策略、权限控制都由 sandbox 层和 vault 层完成。它不负责调度哪个 Harness 实例来处理哪个 session由一个轻量级的负载均衡器可能是基于 session ID 的一致性哈希决定与 Harness 本身无关。它只负责“翻译”将 event log 中的当前状态“翻译”成模型能理解的 prompt再将模型的输出“翻译”成下一个要写入 log 的 event。这个设计的工程意义极其深远。它意味着 Anthropic 可以将 Harness 的实现从一个复杂的、耦合了各种业务逻辑的 monolith变成一个高度标准化、可替换的组件。今天他们用 Python FastAPI 实现明天他们完全可以换成 Rust Axum只要它遵循awake(sessionId) - string这个极简接口。这为未来的性能优化、语言生态兼容、甚至硬件加速比如用 GPU 加速 prompt 构建留下了巨大的空间。更重要的是它让 Anthropic 的核心竞争力牢牢锁定在了event log 的存储、索引、查询能力和模型本身的推理质量上而不是在一个容易被开源社区快速复制的“执行器”上。2.3 “Sandboxes as Cattle, Not Pets”隔离的终极形态如果说 session 和 harness 的解耦是“脑”与“心”的分离那么 sandbox 的 cattle 化就是“手”与“身体”的彻底剥离。Anthropic 对 sandbox 的要求已经超越了传统的容器隔离直指云原生时代的终极隔离范式微虚拟机MicroVM。Why MicroVM?Docker 容器共享宿主机内核存在潜在的逃逸风险且对 syscall 的拦截不够彻底。而 MicroVM如 Firecracker, gVisor则为每一个 sandbox 创建一个轻量级的、独立的内核实例。它拥有自己完整的 CPU、内存、文件系统视图。一个 sandbox 里的进程连ps aux都看不到宿主机上的其他进程更别说去读取/proc下的敏感信息了。这对于 credential 隔离是致命的保障。The Vault IntegrationCredentialAPI Key、DB Password、OAuth Token的注入方式是区分业余和专业的分水岭。业余做法是docker run -e API_KEYxxx ...这等于把钥匙挂在门把手上。专业做法是sandbox 启动时只获得一个临时的、短时效的、作用域极窄的vault_token。当它需要调用某个工具时它拿着这个 token向 Anthropic 的 vault 服务发起一个GET /secrets/db-prod-read-only的请求vault 服务校验 token 的权限后才返回真正的密码。整个过程中密码从未以明文形式存在于 sandbox 的内存或环境中。这是 AWS IAM Roles for EC2 的 AI 版本是生产环境的黄金标准。Provisioned on Demand每一个 sandbox 都是“按需创建、用完即焚”。一个 session 的第一次 tool call 触发 sandbox 创建最后一次 tool call 完成后sandbox 在几秒内被彻底销毁。这不仅极大提升了资源利用率没有 idle sandbox 在浪费 CPU更从根本上杜绝了“长连接”、“后台进程”等安全隐患。你的 agent 不可能在 sandbox 里偷偷启动一个nc -lvp 4444的反向 shell因为它根本活不到那一刻。3. 核心细节解析与实操要点从 YAML 到生产环境的每一处暗礁3.1 Agent 定义YAML 是生产力自然语言是入口Anthropic 允许你用两种方式定义一个 agent一种是严谨、可版本控制、适合 CI/CD 的 YAML另一种是灵活、快速迭代、适合产品经理和业务方参与的自然语言。这两种方式最终都会被编译成同一个内部表示。一个典型的agent.yaml文件其核心结构如下# agent.yaml name: Sales-Lead-Enricher description: An agent that takes a raw lead (name, email, company) and enriches it with firmographic data, social links, and a personalized outreach draft. system_prompt: | You are an expert B2B sales intelligence analyst. Your goal is to gather accurate, public information about a company and its key contacts to help sales reps build rapport. You have access to the following tools. Use them judiciously and only when necessary. tools: - name: company_search description: Search for a company by name or domain. Returns basic info like industry, size, location. input_schema: type: object properties: query: type: string description: Company name or domain (e.g., acme.com) - name: linkedin_profile_search description: Search for LinkedIn profiles of people at a given company. Returns name, title, and profile URL. input_schema: type: object properties: company_name: type: string description: The exact company name from company_search result guardrails: - type: pii_redaction config: fields: [email, phone] - type: content_moderation config: severity_threshold: high注意input_schema是关键。它不是一个简单的字符串描述而是一个严格的 JSON Schema。这确保了模型在生成 tool call 时其input字段的结构是完全可预测、可验证的。这为后续的自动化测试、类型安全的 SDK 生成、以及 sandbox 的输入校验打下了坚实基础。很多开源框架在这里偷懒只用自然语言描述结果导致模型生成的{query: acme}和{q: acme}交替出现让下游的 tool handler 苦不堪言。3.2 Pricing 模型$0.08/小时背后的成本真相$0.08 per session-hour of active runtime这个定价初看平平无奇但细究之下藏着 Anthropic 对“价值”的深刻理解。Active Runtime ≠ Wall-clock Time这里的“session-hour”指的是 sandbox 处于“active”状态的时间即它正在执行 tool call 或等待模型响应的时间。当一个 session 处于“等待用户输入”的 idle 状态时sandbox 已被销毁Harness 也处于休眠这部分时间不计费。这与传统云服务按“实例运行时长”收费有本质区别对间歇性工作的 agent 极其友好。Cost Breakdown (Estimate)Sandbox Cost: 一个 Firecracker MicroVM配 1 vCPU / 2GB RAM按 AWS Lambda 的价格类比其每小时成本约 $0.015 - $0.025。Harness Cost: 一个轻量级 Python 进程处理 prompt 构建和 event log 读写其计算成本极低约 $0.005 - $0.01。Event Log Storage Query: 这是真正的“护城河”。高吞吐、低延迟、支持复杂查询的日志系统其存储和索引成本是主要构成约 $0.03 - $0.04。Vault Security Services: 凭证管理、动态 token 签发、实时内容审核这些安全服务的成本不容小觑约 $0.01 - $0.015。所以$0.08 的定价是 Anthropic 在覆盖其真实成本后留出的合理毛利。它远低于你自己在 AWS 上搭建一套同等安全等级的系统EC2 RDS Secrets Manager CloudWatch Logs Insights的成本但又高于一个纯开源方案如 Daytona的运营成本。这是一个精准卡在“自建太贵开源太糙”之间的甜蜜点目标明确把你从 DIY 的泥潭里拉出来让你专注于 agent 的业务逻辑而不是 infrastructure 的运维噩梦。3.3 Credential Isolation那个被遗忘的“curl 命令”文章中提到的那个“LLM 选择了错误的 curl 命令”的故事绝非危言耸听。这是我在一家金融科技公司亲眼所见的真实事故。他们的 agent 被赋予了一个DATABASE_URL环境变量格式为postgresql://user:passwordhost:port/db。模型在一次思考中为了“简化”决定自己拼接一个 curl 命令去调用一个内部 API它从DATABASE_URL中提取了user和password然后生成了curl -X POST https://internal-api.company.com/v1/trigger -H Authorization: Basic dXNlcjpwYXNzd29yZA -d {job: sync}这个 Base64 编码的dXNlcjpwYXNzd29yZA解码后正是user:password。这个请求被成功发送但问题在于这个user:password是数据库的凭证而内部 API 的认证机制恰好也接受 Basic Auth并且这个数据库用户因为历史原因被赋予了internal-api-trigger的权限。于是一个本该只读数据库的 agent意外地触发了一个高权限的后台任务导致了严重的数据一致性问题。Anthropic 的解决方案就是让这个DATABASE_URL根本不存在于 sandbox 的视野里。sandbox 只能看到一个VAULT_TOKEN。当它需要连接数据库时它调用vault.read_secret(db/prod/readonly)vault 返回一个临时的、只读的、有效期 5 分钟的连接串。这个连接串里密码是随机生成的且只对这一次连接有效。即使模型想“聪明”地去拼接 curl它也找不到任何可用的、长期有效的凭证。这就是“credential isolation”在生产环境中的血泪价值。4. 实操过程与核心环节实现从 Notion 插件到 Rakuten 的销售引擎4.1 Notion 的“Team Delegate”一个零代码集成的典范Notion 官方宣布采用 Claude Managed Agents 来构建其“Team Delegate”功能。这个案例完美诠释了 Managed Agents 如何降低企业级 AI 应用的集成门槛。User Flow: 用户在 Notion 页面中选中一段文字比如一个会议纪要右键选择 “Delegate to Claude”然后选择一个预设的 agent如 “Summarize Action Items” 或 “Draft Follow-up Email”。Under the Hood:Notion 前端捕获选中文本和用户选择的 agent 名称。前端调用 Anthropic 的POST /v1/sessionsAPI传入agent_name: summarize-action-items和initial_input: 会议纪要原文...。Anthropic 创建一个新 session启动一个 Harness并为其分配一个唯一的sessionId。Harness 读取 event log此时只有 initial_input构建 prompt调用 Claude 模型。模型输出一个execute(extract_actions, {...})的指令。Harness 将此指令作为 event 写入 log然后调用 sandbox 执行extract_actions工具该工具可能是一个内部的 NLP 微服务。Sandbox 执行完毕返回结果Harness 将结果作为新 event 写入 log。Harness 再次读取 log发现已无待处理 action于是生成最终回复“本次会议共产生 3 项行动项1. ... 2. ... 3. ...”并将其作为final_outputevent 写入。Notion 前端轮询GET /v1/sessions/{id}/output获取最终结果并渲染。整个过程Notion 的工程师不需要自己部署和维护一个 LLM 推理服务。自己编写和调试extract_actions工具的代码。自己设计和实现 session 状态管理。自己解决 credential 安全问题。他们只需要定义好 agent 的 YAML写好几个工具的 HTTP 接口然后调用 Anthropic 的两个 API创建 session 和轮询结果。这就是 Managed Agents 的威力它把一个需要 3-6 个月才能上线的复杂项目压缩到了 2-3 周。4.2 Rakuten 的“Sales-Marketing-Finance”三叉戟规模化落地的挑战Rakuten 的案例则展示了 Managed Agents 在超大规模、多部门协同场景下的应用。他们并非只部署了一个 agent而是构建了一个“agent 网络”。Architecture:Orchestrator Agent: 一个顶层的、规则驱动的 agent。它接收 Slack 中的一条消息如 “Q1 sales report for Japan region”首先调用route_to_department工具根据关键词判断应归属 Sales、Marketing 还是 Finance。Department Agents: 三个独立的、领域专家级的 agents。Sales Agent 拥有 CRM 和 BI 工具Marketing Agent 拥有广告平台和社交媒体 APIFinance Agent 拥有 ERP 和财务报表系统。Shared Infrastructure: 所有 agents 共享同一个 event log 存储用于跨部门审计、同一个 vault用于统一凭证管理、同一个 guardrail service用于全公司统一的内容安全策略。Key Implementation Detail - Cross-Session Context: 当一个 Sales Agent 生成了一份报告它不会直接把报告内容塞进 Slack。相反它会生成一个create_shared_link的 tool call这个工具会将报告存入一个加密的、临时的 S3 bucket并返回一个https://rakuten-shared.s3.amazonaws.com/reports/xxx.pdf?token...的链接。这个链接被作为 event 写入 log。Orchestrator Agent 在看到这个链接后会将其转发给 Marketing Agent并附带一条指令“请基于这份 Sales 报告为 Q1 日本市场活动制定初步预算建议。” Marketing Agent 的 system prompt 中明确包含了一条规则“当收到shared_link类型的输入时优先下载并解析其内容。”这个设计巧妙地绕过了“模型上下文长度”的限制实现了跨 session、跨 agent 的信息传递。它把“状态”从模型的脑子里搬到了一个共享的、受控的、可审计的存储里。这正是 Managed Agents 架构所能支撑的、远超单个 agent 能力的复杂工作流。4.3 Sentry 的“Debug Patch”闭环从发现问题到解决问题Sentry 将其原有的错误监控 agent 与一个全新的 Claude agent 深度耦合创造了一个“自动修复”的闭环。Workflow:Sentry 的后端服务捕获到一个未处理的异常如NullPointerException。Sentry 的 agent基于其自有框架分析堆栈定位到出错的代码行和相关文件。Sentry agent 调用 Anthropic 的POST /v1/sessions传入agent_name: code-patcher和initial_input: Error: NullPointerException in UserService.java line 42. Code snippet: ...。Claude Managed Agent 启动它拥有的工具包括fetch_code_file: 根据文件路径和 commit hash 获取源码。search_github_issues: 查询该项目的 GitHub issues看是否已有类似 bug 的讨论。generate_patch: 调用 Claude 模型基于错误信息、源码和 issue 讨论生成一个 Git diff 补丁。create_pull_request: 将补丁提交到一个 feature branch并创建一个 PR自动 assign 给相关 reviewer。The Critical Guardrail: 这个流程中最关键的一步是generate_patch工具的 guardrail。它被强制配置为- type: code_safety config: max_lines_changed: 10 forbidden_patterns: [System.exit, Thread.sleep, eval] required_patterns: [// Fix for Sentry error #XXXXX]这确保了生成的补丁是安全的、可控的、且带有明确的溯源信息。一个未经审查的、由 LLM 生成的补丁其风险不亚于一个未知的 0day 漏洞。Managed Agents 的强大之处正在于它把这种至关重要的安全策略从开发者的个人经验变成了一个可配置、可审计、可强制执行的平台级能力。5. 常见问题与排查技巧实录那些没人告诉你的“坑”5.1 Session “幽灵死亡”为什么我的 session 看似在运行却毫无响应现象你创建了一个 session前端显示“Processing...”但 5 分钟后你轮询output得到的是空值。检查 event log发现最后一条 event 是model_thought后面再无任何tool_call或final_output。Root Cause Diagnosis最常见原因Tool Call Timeout。你的company_search工具是一个调用外部 API 的 HTTP 请求。如果该 API 响应缓慢 30sAnthropic 的 sandbox 会主动 kill 掉这个进程并记录一个tool_call_failed的 event但这个 event 的error_message可能只是 “Process killed due to timeout”非常模糊。排查步骤GET /v1/sessions/{id}/events?limit10找到最后一条model_thoughtevent。查看它的next_action字段确认它确实生成了execute(company_search, {...})。GET /v1/sessions/{id}/events?from{last_thought_timestamp}typetool_call_failed查找失败事件。如果找到了检查tool_call_failedevent 的input字段复制其中的参数在你自己的开发环境里用 curl 或 Postman 手动重放这个请求。你会发现它确实花了 45 秒。Solution立即在你的 tool handler 里为所有外部 HTTP 调用设置严格的timeout15s。长期在 agent 的 YAML 中为该 tool 添加timeout_ms: 15000的配置让 Anthropic 的 sandbox 在底层就进行超时控制。5.2 Credential “泄露”为什么 sandbox 里能cat /proc/env看到我的密钥现象你在 sandbox 里执行printenv | grep API_KEY竟然看到了一个API_KEY环境变量。Root Cause Diagnosis绝对不要在你的 tool handler 代码里通过os.environ.get(API_KEY)来读取密钥这是最大的禁忌。正确的做法是你的 tool handler 应该只接收一个vault_token然后用这个 token 去调用https://vault.anthropic.com/v1/secrets/my-api-key。如果你看到了API_KEY说明你在部署 tool handler 时犯了两个致命错误你在 Dockerfile 里写了ENV API_KEYxxx。你在启动命令里写了CMD [python, handler.py]而handler.py里直接os.getenv(API_KEY)。Solution重构你的 tool handler让它成为一个纯粹的、无状态的 HTTP 服务。它只暴露一个/invokeendpoint接收一个 JSON payloadpayload 里包含vault_token和tool_input。handler 收到请求后第一步就是用vault_token去换密钥第二步才是执行业务逻辑。使用 Anthropic 的 Vault SDK他们提供了官方的 Python/JS SDK封装了 token 换取、缓存、自动刷新等所有细节一行代码即可完成安全调用。5.3 Event Log “查询黑洞”为什么我用 SQL 查询不到数据现象你按照文档尝试用SELECT * FROM events WHERE session_id xxx AND type tool_call但返回空结果。Root Cause DiagnosisEvent Log 的查询是异步索引的。当你写入一个 event 时它首先被追加到 WALWrite-Ahead Log中保证持久化。然后一个后台的 indexer 服务会定期通常是秒级将 WAL 中的 events 批量索引到搜索数据库如 Elasticsearch中。所以GET /v1/sessions/{id}/events这个 API 是强一致的它直接读 WAL而SELECT ... FROM events这个 SQL 查询是最终一致的它读索引库。如果你在execute工具返回后立刻执行 SQL 查询很可能索引还没完成。Solution对于调试和开发永远优先使用GET /v1/sessions/{id}/eventsAPI。它是你的唯一真相之源。对于生产监控和告警在你的告警规则里为 SQL 查询添加一个AND timestamp NOW() - INTERVAL 30 seconds的条件给自己留出足够的索引延迟缓冲区。对于需要强一致性的审计场景不要依赖 SQL 查询。直接调用GET /v1/sessions/{id}/events?from...to...并自己在应用层做聚合。6. 竞争格局与未来演进当 runtime 成为“免费赠品”6.1 Hyperscaler 的降维打击AWS AgentCore 的“免费”逻辑Anthropic 的 Managed Agents 是一个优秀的产品但它绝非开创者。正如原文尖锐指出的Amazon Bedrock AgentCore 在 2025 年底就已进入 GA正式发布阶段。而它的定价策略才是对整个 runtime 层最致命的打击。AWS 的逻辑非常清晰AgentCore 不是一个要单独卖钱的产品它是 AWS 云服务的“粘合剂”和“增量引擎”。一个客户如果已经在 AWS 上运行着 EC2、RDS、S3、Lambda那么为他提供一个能无缝调用这些服务的 agent runtime其边际成本几乎为零。AWS 只需要在现有的 CloudWatch Logs、IAM Roles、EC2 MicroVMFirecracker之上叠加一层 agent-specific 的抽象session manager, harness orchestrator, vault integration就能打包成 AgentCore。Pricing Reality: AWS 官方并未公布 AgentCore 的独立价格。但所有迹象表明它被计入了客户的整体 AWS 账单其成本被摊薄到了 EC2 的 vCPU 小时费、S3 的请求费、CloudWatch Logs 的 ingest fee 之中。对于一个年消费 100 万美元的 AWS 客户来说AgentCore 的成本可能只占其总账单的 0.1%甚至更低。这本质上是一种“免费赠品”Freebie策略。The Lock-in Effect: 更可怕的是一旦你开始使用 AgentCore你就深度绑定了 AWS 的整个生态。你的tool_call直接调用的是arn:aws:lambda:us-east-1:123456789012:function:my-db-search你的vault_token是一个 AWS IAM Role 的临时凭证你的 event log 存储在 CloudWatch Logs Insights 里。迁移到 Anthropic意味着你要重写所有的 tools、重构所有的 credentials、迁移所有的 logs。这个成本远高于 $0.08/session-hour 的差价。6.2 开源压力曲线Daytona 与 Kubernetes SIG 的“鲶鱼效应”如果说 hyperscaler 是“大象”那么开源社区就是一群“狼”。它们不追求盈利只追求极致的性能、灵活性和社区认同。Daytona 和 Kubernetes SIG 的项目正是这条压力曲线上的关键节点。Daytona 的 Sub-90ms Spin-up: Daytona 的核心突破在于它将 sandbox 的启动时间从传统容器的几百毫秒压缩到了 90 毫秒以内。这是怎么做到的答案是pre-warmed sandbox pools。Daytona 的 controller 会预先启动一批“空白”的 Firecracker MicroVM并将它们维持在一个 ready-to-accept-work 的状态。当一个新 session 到来时controller 不是从零创建 VM而是从池子里“借”一个注入 agent 的 code 和 config然后启动。这就像机场的登机口永远有 2-3 个是提前打开、准备就绪的而不是每次航班都现开一个。Kubernetes SIG Agent-Sandbox: 这个项目的意义不在于它有多快而在于它有多“标准”。它定义了一套 Kubernetes CRDCustom Resource Definition如Sandbox,ToolBinding,SessionPolicy。这意味着任何遵循这套标准的 agent frameworkLangGraph, CrewAI都可以在任何兼容的 Kubernetes 集群上无需修改一行代码就获得与 Anthropic Managed Agents 几乎相同的能力。它把 runtime 层变成了一个可插拔的、标准化的 Kubernetes 插件。这直接动摇了所有 proprietary runtime 的根基——你的独特性正在被一个开放标准所消解。6.3 价值迁移的“三层楼”Trace Store、Governance、Vertical Marketplaces当 runtime 层不可避免地走向 commoditization商品化价值必然向上迁移。这场迁移正在三个清晰的楼层上同时发生。楼层核心价值关键玩家为什么它能存活一楼Runtime (正在坍塌)执行、隔离、状态管理Anthropic Managed Agents, AWS AgentCore, Daytona它们是“水电煤”是基础设施利润薄竞争烈终将被压至成本线。二楼Trace Store (正在崛起)What did the agent actually do?成为 agent 行为的唯一、权威、可移植的记录系统Braintrust (Brainstore), Arize (Phoenix), LangSmith企业需要一个与 runtime 无关的、能随 agent 一起迁移的“行为账本”。谁能提供最强大的查询、最开放的 API、最无缝的迁移工具谁就掌握了这个 layer。三楼Governance Policy (刚刚萌芽)What is the agent allowed to do?定义、执行、审计 agent 的行为边界AWS AgentCore Policy Controls, OWASP Agentic Top 10, 新兴的 startup随着 agent 被赋予越来越高的权限写数据库、发邮件、开 PR企业采购部门的第一个问题必然是“你们的 agent 有合规认证吗它的策略能和我们的 SOC2 流程对接吗” 这是一个由法规和采购驱动的刚性需求。四楼Vertical Marketplaces (爆发前夜)What job does the agent solve?将 agent 封装成一个垂直领域的、开箱即用的、可计量付费的 SaaS 产品Salesforce Agentforce, virattt/ai-hedge-fund, vxcontrol/pentagi企业不为“runtime”付费但会为“解决一个具体业务问题”付费。一个能将保险理赔周期从 14 天缩短到 2 小时的 agent其价值远超它运行在哪个 sandbox 里。我个人在实际操作中发现最值得早期投入的恰恰是二楼的 Trace Store。我们曾在一个金融项目中将所有 agent 的 event log 同步到一个自建的 ClickHouse 集群并基于此开发了一套内部的“Agent Health Dashboard”。它不仅能显示成功率、平均耗时更能回答“过去一周哪些 tool call 的失败率最高失败的原因是什么timeout vs auth_failure vs schema_mismatch哪些 session 的
AI代理运行时革命：Session-as-Event-Log架构解析
1. 这不是新赛道而是 runtime 层的“操作系统时刻”——一场静默却决定生死的基础设施战争你有没有试过让一个 AI 代理连续工作四十分钟不是闲聊不是写诗而是真正在做事情查数据库、调 API、读文档、写代码、改配置、发 PR。我去年就带着团队跑过这样一个销售线索清洗客户画像生成邮件草稿初稿的端到端流程。前35分钟一切顺利第38分钟模型突然开始胡说八道——它把三天前某次失败的 API 调用返回的错误 JSON 当成了有效数据还据此生成了一封向客户道歉的邮件。我们翻日志、看 trace、重放 prompt全无头绪。最后才发现不是模型坏了是它的“记忆”被挤掉了。那个长达4000 token 的 session 历史在第39分钟时被硬生生从上下文窗口里“踢”了出去。模型没报错它只是安静地、自信地基于一个残缺的、被截断的历史继续编故事。我们丢了整个 session无法回溯无法重放更无法 debug。那不是一次故障是一次无声的蒸发。Anthropic 在 4 月 8 日发布的 Claude Managed Agents表面看是一套托管运行时但它的核心价值就藏在那个被工程博客反复强调、却被媒体通稿轻轻带过的词里session-as-event-log。这不是一个功能点而是一个范式转移的锚点。它意味着AI 代理的状态state终于从模型那脆弱、昂贵、容量有限的上下文窗口里被彻底解放出来落到了一个持久化、可查询、可审计、可重放的外部存储上。这就像 1990 年代操作系统把硬件资源虚拟化一样——CPU、内存、磁盘不再由每个程序自己去抢、去管、去猜而是由 OS 统一抽象、调度、隔离。今天Anthropic 正在为 AI 代理世界做同样的事把 session会话、harness执行器、sandbox沙箱这三个关键概念拆解成清晰、稳定、彼此解耦的接口。Harness 可以挂掉只要 event log 还在它就能awake(sessionId)一键复活Sandbox 可以像牛群cattle一样被秒级销毁重建而不是像宠物pets一样需要精心呵护Credentials凭证被锁在 vault 里永远不碰 sandbox 的边界。这背后没有魔法只有一套经过生产环境千锤百炼的、对“状态管理”和“执行隔离”这两座大山的系统性攻克。关键词Towards AI - Medium所代表的正是这种深度技术观察的土壤。它不满足于告诉你“Anthropic 发布了什么”而是要撕开 PR 稿的糖衣问一句它为什么必须这样设计它解决了谁的什么痛它的对手在哪里它的未来又在何方这篇文章就是一份来自一线架构师视角的“runtime 层战地报告”。它不面向只想尝鲜的爱好者而是写给那些正在自己的服务器上部署 LangGraph、在 Kubernetes 里手搓 sandbox、或者正为“如何让代理安全地访问公司内部 API”而彻夜难眠的工程师和 CTO。如果你正站在这个十字路口这篇文章的价值可能远超你此刻的预期。2. 核心设计与思路拆解为什么是“解耦”而不是“堆砌”2.1 “Session-as-Event-Log”一场关于“状态主权”的革命让我们先直面那个最根本的痛点AI 模型的上下文窗口从来就不是一个合格的数据库。它的设计初衷是承载“当前对话的语境”而不是“一个长达数小时、跨越数十次工具调用的完整工作流历史”。把它当数据库用就像用咖啡杯去盛装整条长江——杯子再精致也改变不了它物理容量的极限。Anthropic 的“session-as-event-log”模式其精妙之处不在于它有多炫酷而在于它回归了最朴素的工程常识将状态State与计算Computation彻底分离。State状态所有关于这个 session 的信息——用户初始请求、每一次 tool call 的输入/输出、模型的每一轮思考thought、guardrail 的每一次拦截、甚至每一次 token 的消耗明细——都被序列化为结构化的事件event并持久化到一个高可用、低延迟的外部存储中很可能是他们自研的分布式日志系统类似 Kafka S3 的混合体。这个存储是 durable持久的、queryable可查询的、immutable不可变的。你可以随时GET /sessions/{id}/events?fromtimestamp来拉取任意一段历史也可以用 SQL-like 语法SELECT * FROM events WHERE session_id xxx AND type tool_call AND status success来做深度分析。Computation计算Harness执行器则变成了一个纯粹的、无状态的函数。它只做一件事接收一个sessionId和一个input通常是用户的最新消息或一个待处理的事件然后根据当前 session 的最新 event log调用模型生成下一步 action比如execute(search_db, {query: Q1 sales})并将这个 action 作为一个新的 event 写入 log。Harness 本身不保存任何状态它的内存里只有“此刻需要处理什么”。这意味着Harness 实例可以像 Web Server 一样水平扩展、滚动更新、甚至瞬间崩溃重启只要它能重新读取 event log整个 session 就能无缝续上。提示这种设计的直接好处是灾难恢复能力。想象一下你的 Harness 集群因为一次意外的 Kubernetes 升级而全部宕机。传统方案下所有正在运行的 session 全部丢失用户只能重来。而在 Anthropic 的模式下只要 event log 存储还在新启动的 Harness 就能awake(sessionId)从最后一个成功的 event 开始精准续跑。这不再是“尽力而为”而是“确定性恢复”。这种解耦带来的第二个巨大优势是可观测性Observability的质变。在旧模式下你想知道一个 session 为什么失败你得去翻 Nginx 日志、翻模型服务日志、翻工具调用日志再把它们在时间线上手动对齐这过程堪比福尔摩斯探案。而在 event log 模式下所有信息天然就在一条时间线上且自带 context。一个失败的tool_call事件旁边就紧跟着它前面的model_thought事件模型说“我要调用 search_db”和它后面的guardrail_violation事件安全策略说“禁止访问敏感表”。你不需要推理你只需要阅读。2.2 “Harness as Stateless Executor”从“智能体”到“智能管道”Harness 的“无状态”属性是整个架构得以轻盈、可靠、可扩展的基石。它彻底剥离了所有与“智能”无关的负担成为一个纯粹的、高效的“智能管道”。它不负责记忆所有记忆都在 event log 里。它不负责安全所有 credential 注入、网络策略、权限控制都由 sandbox 层和 vault 层完成。它不负责调度哪个 Harness 实例来处理哪个 session由一个轻量级的负载均衡器可能是基于 session ID 的一致性哈希决定与 Harness 本身无关。它只负责“翻译”将 event log 中的当前状态“翻译”成模型能理解的 prompt再将模型的输出“翻译”成下一个要写入 log 的 event。这个设计的工程意义极其深远。它意味着 Anthropic 可以将 Harness 的实现从一个复杂的、耦合了各种业务逻辑的 monolith变成一个高度标准化、可替换的组件。今天他们用 Python FastAPI 实现明天他们完全可以换成 Rust Axum只要它遵循awake(sessionId) - string这个极简接口。这为未来的性能优化、语言生态兼容、甚至硬件加速比如用 GPU 加速 prompt 构建留下了巨大的空间。更重要的是它让 Anthropic 的核心竞争力牢牢锁定在了event log 的存储、索引、查询能力和模型本身的推理质量上而不是在一个容易被开源社区快速复制的“执行器”上。2.3 “Sandboxes as Cattle, Not Pets”隔离的终极形态如果说 session 和 harness 的解耦是“脑”与“心”的分离那么 sandbox 的 cattle 化就是“手”与“身体”的彻底剥离。Anthropic 对 sandbox 的要求已经超越了传统的容器隔离直指云原生时代的终极隔离范式微虚拟机MicroVM。Why MicroVM?Docker 容器共享宿主机内核存在潜在的逃逸风险且对 syscall 的拦截不够彻底。而 MicroVM如 Firecracker, gVisor则为每一个 sandbox 创建一个轻量级的、独立的内核实例。它拥有自己完整的 CPU、内存、文件系统视图。一个 sandbox 里的进程连ps aux都看不到宿主机上的其他进程更别说去读取/proc下的敏感信息了。这对于 credential 隔离是致命的保障。The Vault IntegrationCredentialAPI Key、DB Password、OAuth Token的注入方式是区分业余和专业的分水岭。业余做法是docker run -e API_KEYxxx ...这等于把钥匙挂在门把手上。专业做法是sandbox 启动时只获得一个临时的、短时效的、作用域极窄的vault_token。当它需要调用某个工具时它拿着这个 token向 Anthropic 的 vault 服务发起一个GET /secrets/db-prod-read-only的请求vault 服务校验 token 的权限后才返回真正的密码。整个过程中密码从未以明文形式存在于 sandbox 的内存或环境中。这是 AWS IAM Roles for EC2 的 AI 版本是生产环境的黄金标准。Provisioned on Demand每一个 sandbox 都是“按需创建、用完即焚”。一个 session 的第一次 tool call 触发 sandbox 创建最后一次 tool call 完成后sandbox 在几秒内被彻底销毁。这不仅极大提升了资源利用率没有 idle sandbox 在浪费 CPU更从根本上杜绝了“长连接”、“后台进程”等安全隐患。你的 agent 不可能在 sandbox 里偷偷启动一个nc -lvp 4444的反向 shell因为它根本活不到那一刻。3. 核心细节解析与实操要点从 YAML 到生产环境的每一处暗礁3.1 Agent 定义YAML 是生产力自然语言是入口Anthropic 允许你用两种方式定义一个 agent一种是严谨、可版本控制、适合 CI/CD 的 YAML另一种是灵活、快速迭代、适合产品经理和业务方参与的自然语言。这两种方式最终都会被编译成同一个内部表示。一个典型的agent.yaml文件其核心结构如下# agent.yaml name: Sales-Lead-Enricher description: An agent that takes a raw lead (name, email, company) and enriches it with firmographic data, social links, and a personalized outreach draft. system_prompt: | You are an expert B2B sales intelligence analyst. Your goal is to gather accurate, public information about a company and its key contacts to help sales reps build rapport. You have access to the following tools. Use them judiciously and only when necessary. tools: - name: company_search description: Search for a company by name or domain. Returns basic info like industry, size, location. input_schema: type: object properties: query: type: string description: Company name or domain (e.g., acme.com) - name: linkedin_profile_search description: Search for LinkedIn profiles of people at a given company. Returns name, title, and profile URL. input_schema: type: object properties: company_name: type: string description: The exact company name from company_search result guardrails: - type: pii_redaction config: fields: [email, phone] - type: content_moderation config: severity_threshold: high注意input_schema是关键。它不是一个简单的字符串描述而是一个严格的 JSON Schema。这确保了模型在生成 tool call 时其input字段的结构是完全可预测、可验证的。这为后续的自动化测试、类型安全的 SDK 生成、以及 sandbox 的输入校验打下了坚实基础。很多开源框架在这里偷懒只用自然语言描述结果导致模型生成的{query: acme}和{q: acme}交替出现让下游的 tool handler 苦不堪言。3.2 Pricing 模型$0.08/小时背后的成本真相$0.08 per session-hour of active runtime这个定价初看平平无奇但细究之下藏着 Anthropic 对“价值”的深刻理解。Active Runtime ≠ Wall-clock Time这里的“session-hour”指的是 sandbox 处于“active”状态的时间即它正在执行 tool call 或等待模型响应的时间。当一个 session 处于“等待用户输入”的 idle 状态时sandbox 已被销毁Harness 也处于休眠这部分时间不计费。这与传统云服务按“实例运行时长”收费有本质区别对间歇性工作的 agent 极其友好。Cost Breakdown (Estimate)Sandbox Cost: 一个 Firecracker MicroVM配 1 vCPU / 2GB RAM按 AWS Lambda 的价格类比其每小时成本约 $0.015 - $0.025。Harness Cost: 一个轻量级 Python 进程处理 prompt 构建和 event log 读写其计算成本极低约 $0.005 - $0.01。Event Log Storage Query: 这是真正的“护城河”。高吞吐、低延迟、支持复杂查询的日志系统其存储和索引成本是主要构成约 $0.03 - $0.04。Vault Security Services: 凭证管理、动态 token 签发、实时内容审核这些安全服务的成本不容小觑约 $0.01 - $0.015。所以$0.08 的定价是 Anthropic 在覆盖其真实成本后留出的合理毛利。它远低于你自己在 AWS 上搭建一套同等安全等级的系统EC2 RDS Secrets Manager CloudWatch Logs Insights的成本但又高于一个纯开源方案如 Daytona的运营成本。这是一个精准卡在“自建太贵开源太糙”之间的甜蜜点目标明确把你从 DIY 的泥潭里拉出来让你专注于 agent 的业务逻辑而不是 infrastructure 的运维噩梦。3.3 Credential Isolation那个被遗忘的“curl 命令”文章中提到的那个“LLM 选择了错误的 curl 命令”的故事绝非危言耸听。这是我在一家金融科技公司亲眼所见的真实事故。他们的 agent 被赋予了一个DATABASE_URL环境变量格式为postgresql://user:passwordhost:port/db。模型在一次思考中为了“简化”决定自己拼接一个 curl 命令去调用一个内部 API它从DATABASE_URL中提取了user和password然后生成了curl -X POST https://internal-api.company.com/v1/trigger -H Authorization: Basic dXNlcjpwYXNzd29yZA -d {job: sync}这个 Base64 编码的dXNlcjpwYXNzd29yZA解码后正是user:password。这个请求被成功发送但问题在于这个user:password是数据库的凭证而内部 API 的认证机制恰好也接受 Basic Auth并且这个数据库用户因为历史原因被赋予了internal-api-trigger的权限。于是一个本该只读数据库的 agent意外地触发了一个高权限的后台任务导致了严重的数据一致性问题。Anthropic 的解决方案就是让这个DATABASE_URL根本不存在于 sandbox 的视野里。sandbox 只能看到一个VAULT_TOKEN。当它需要连接数据库时它调用vault.read_secret(db/prod/readonly)vault 返回一个临时的、只读的、有效期 5 分钟的连接串。这个连接串里密码是随机生成的且只对这一次连接有效。即使模型想“聪明”地去拼接 curl它也找不到任何可用的、长期有效的凭证。这就是“credential isolation”在生产环境中的血泪价值。4. 实操过程与核心环节实现从 Notion 插件到 Rakuten 的销售引擎4.1 Notion 的“Team Delegate”一个零代码集成的典范Notion 官方宣布采用 Claude Managed Agents 来构建其“Team Delegate”功能。这个案例完美诠释了 Managed Agents 如何降低企业级 AI 应用的集成门槛。User Flow: 用户在 Notion 页面中选中一段文字比如一个会议纪要右键选择 “Delegate to Claude”然后选择一个预设的 agent如 “Summarize Action Items” 或 “Draft Follow-up Email”。Under the Hood:Notion 前端捕获选中文本和用户选择的 agent 名称。前端调用 Anthropic 的POST /v1/sessionsAPI传入agent_name: summarize-action-items和initial_input: 会议纪要原文...。Anthropic 创建一个新 session启动一个 Harness并为其分配一个唯一的sessionId。Harness 读取 event log此时只有 initial_input构建 prompt调用 Claude 模型。模型输出一个execute(extract_actions, {...})的指令。Harness 将此指令作为 event 写入 log然后调用 sandbox 执行extract_actions工具该工具可能是一个内部的 NLP 微服务。Sandbox 执行完毕返回结果Harness 将结果作为新 event 写入 log。Harness 再次读取 log发现已无待处理 action于是生成最终回复“本次会议共产生 3 项行动项1. ... 2. ... 3. ...”并将其作为final_outputevent 写入。Notion 前端轮询GET /v1/sessions/{id}/output获取最终结果并渲染。整个过程Notion 的工程师不需要自己部署和维护一个 LLM 推理服务。自己编写和调试extract_actions工具的代码。自己设计和实现 session 状态管理。自己解决 credential 安全问题。他们只需要定义好 agent 的 YAML写好几个工具的 HTTP 接口然后调用 Anthropic 的两个 API创建 session 和轮询结果。这就是 Managed Agents 的威力它把一个需要 3-6 个月才能上线的复杂项目压缩到了 2-3 周。4.2 Rakuten 的“Sales-Marketing-Finance”三叉戟规模化落地的挑战Rakuten 的案例则展示了 Managed Agents 在超大规模、多部门协同场景下的应用。他们并非只部署了一个 agent而是构建了一个“agent 网络”。Architecture:Orchestrator Agent: 一个顶层的、规则驱动的 agent。它接收 Slack 中的一条消息如 “Q1 sales report for Japan region”首先调用route_to_department工具根据关键词判断应归属 Sales、Marketing 还是 Finance。Department Agents: 三个独立的、领域专家级的 agents。Sales Agent 拥有 CRM 和 BI 工具Marketing Agent 拥有广告平台和社交媒体 APIFinance Agent 拥有 ERP 和财务报表系统。Shared Infrastructure: 所有 agents 共享同一个 event log 存储用于跨部门审计、同一个 vault用于统一凭证管理、同一个 guardrail service用于全公司统一的内容安全策略。Key Implementation Detail - Cross-Session Context: 当一个 Sales Agent 生成了一份报告它不会直接把报告内容塞进 Slack。相反它会生成一个create_shared_link的 tool call这个工具会将报告存入一个加密的、临时的 S3 bucket并返回一个https://rakuten-shared.s3.amazonaws.com/reports/xxx.pdf?token...的链接。这个链接被作为 event 写入 log。Orchestrator Agent 在看到这个链接后会将其转发给 Marketing Agent并附带一条指令“请基于这份 Sales 报告为 Q1 日本市场活动制定初步预算建议。” Marketing Agent 的 system prompt 中明确包含了一条规则“当收到shared_link类型的输入时优先下载并解析其内容。”这个设计巧妙地绕过了“模型上下文长度”的限制实现了跨 session、跨 agent 的信息传递。它把“状态”从模型的脑子里搬到了一个共享的、受控的、可审计的存储里。这正是 Managed Agents 架构所能支撑的、远超单个 agent 能力的复杂工作流。4.3 Sentry 的“Debug Patch”闭环从发现问题到解决问题Sentry 将其原有的错误监控 agent 与一个全新的 Claude agent 深度耦合创造了一个“自动修复”的闭环。Workflow:Sentry 的后端服务捕获到一个未处理的异常如NullPointerException。Sentry 的 agent基于其自有框架分析堆栈定位到出错的代码行和相关文件。Sentry agent 调用 Anthropic 的POST /v1/sessions传入agent_name: code-patcher和initial_input: Error: NullPointerException in UserService.java line 42. Code snippet: ...。Claude Managed Agent 启动它拥有的工具包括fetch_code_file: 根据文件路径和 commit hash 获取源码。search_github_issues: 查询该项目的 GitHub issues看是否已有类似 bug 的讨论。generate_patch: 调用 Claude 模型基于错误信息、源码和 issue 讨论生成一个 Git diff 补丁。create_pull_request: 将补丁提交到一个 feature branch并创建一个 PR自动 assign 给相关 reviewer。The Critical Guardrail: 这个流程中最关键的一步是generate_patch工具的 guardrail。它被强制配置为- type: code_safety config: max_lines_changed: 10 forbidden_patterns: [System.exit, Thread.sleep, eval] required_patterns: [// Fix for Sentry error #XXXXX]这确保了生成的补丁是安全的、可控的、且带有明确的溯源信息。一个未经审查的、由 LLM 生成的补丁其风险不亚于一个未知的 0day 漏洞。Managed Agents 的强大之处正在于它把这种至关重要的安全策略从开发者的个人经验变成了一个可配置、可审计、可强制执行的平台级能力。5. 常见问题与排查技巧实录那些没人告诉你的“坑”5.1 Session “幽灵死亡”为什么我的 session 看似在运行却毫无响应现象你创建了一个 session前端显示“Processing...”但 5 分钟后你轮询output得到的是空值。检查 event log发现最后一条 event 是model_thought后面再无任何tool_call或final_output。Root Cause Diagnosis最常见原因Tool Call Timeout。你的company_search工具是一个调用外部 API 的 HTTP 请求。如果该 API 响应缓慢 30sAnthropic 的 sandbox 会主动 kill 掉这个进程并记录一个tool_call_failed的 event但这个 event 的error_message可能只是 “Process killed due to timeout”非常模糊。排查步骤GET /v1/sessions/{id}/events?limit10找到最后一条model_thoughtevent。查看它的next_action字段确认它确实生成了execute(company_search, {...})。GET /v1/sessions/{id}/events?from{last_thought_timestamp}typetool_call_failed查找失败事件。如果找到了检查tool_call_failedevent 的input字段复制其中的参数在你自己的开发环境里用 curl 或 Postman 手动重放这个请求。你会发现它确实花了 45 秒。Solution立即在你的 tool handler 里为所有外部 HTTP 调用设置严格的timeout15s。长期在 agent 的 YAML 中为该 tool 添加timeout_ms: 15000的配置让 Anthropic 的 sandbox 在底层就进行超时控制。5.2 Credential “泄露”为什么 sandbox 里能cat /proc/env看到我的密钥现象你在 sandbox 里执行printenv | grep API_KEY竟然看到了一个API_KEY环境变量。Root Cause Diagnosis绝对不要在你的 tool handler 代码里通过os.environ.get(API_KEY)来读取密钥这是最大的禁忌。正确的做法是你的 tool handler 应该只接收一个vault_token然后用这个 token 去调用https://vault.anthropic.com/v1/secrets/my-api-key。如果你看到了API_KEY说明你在部署 tool handler 时犯了两个致命错误你在 Dockerfile 里写了ENV API_KEYxxx。你在启动命令里写了CMD [python, handler.py]而handler.py里直接os.getenv(API_KEY)。Solution重构你的 tool handler让它成为一个纯粹的、无状态的 HTTP 服务。它只暴露一个/invokeendpoint接收一个 JSON payloadpayload 里包含vault_token和tool_input。handler 收到请求后第一步就是用vault_token去换密钥第二步才是执行业务逻辑。使用 Anthropic 的 Vault SDK他们提供了官方的 Python/JS SDK封装了 token 换取、缓存、自动刷新等所有细节一行代码即可完成安全调用。5.3 Event Log “查询黑洞”为什么我用 SQL 查询不到数据现象你按照文档尝试用SELECT * FROM events WHERE session_id xxx AND type tool_call但返回空结果。Root Cause DiagnosisEvent Log 的查询是异步索引的。当你写入一个 event 时它首先被追加到 WALWrite-Ahead Log中保证持久化。然后一个后台的 indexer 服务会定期通常是秒级将 WAL 中的 events 批量索引到搜索数据库如 Elasticsearch中。所以GET /v1/sessions/{id}/events这个 API 是强一致的它直接读 WAL而SELECT ... FROM events这个 SQL 查询是最终一致的它读索引库。如果你在execute工具返回后立刻执行 SQL 查询很可能索引还没完成。Solution对于调试和开发永远优先使用GET /v1/sessions/{id}/eventsAPI。它是你的唯一真相之源。对于生产监控和告警在你的告警规则里为 SQL 查询添加一个AND timestamp NOW() - INTERVAL 30 seconds的条件给自己留出足够的索引延迟缓冲区。对于需要强一致性的审计场景不要依赖 SQL 查询。直接调用GET /v1/sessions/{id}/events?from...to...并自己在应用层做聚合。6. 竞争格局与未来演进当 runtime 成为“免费赠品”6.1 Hyperscaler 的降维打击AWS AgentCore 的“免费”逻辑Anthropic 的 Managed Agents 是一个优秀的产品但它绝非开创者。正如原文尖锐指出的Amazon Bedrock AgentCore 在 2025 年底就已进入 GA正式发布阶段。而它的定价策略才是对整个 runtime 层最致命的打击。AWS 的逻辑非常清晰AgentCore 不是一个要单独卖钱的产品它是 AWS 云服务的“粘合剂”和“增量引擎”。一个客户如果已经在 AWS 上运行着 EC2、RDS、S3、Lambda那么为他提供一个能无缝调用这些服务的 agent runtime其边际成本几乎为零。AWS 只需要在现有的 CloudWatch Logs、IAM Roles、EC2 MicroVMFirecracker之上叠加一层 agent-specific 的抽象session manager, harness orchestrator, vault integration就能打包成 AgentCore。Pricing Reality: AWS 官方并未公布 AgentCore 的独立价格。但所有迹象表明它被计入了客户的整体 AWS 账单其成本被摊薄到了 EC2 的 vCPU 小时费、S3 的请求费、CloudWatch Logs 的 ingest fee 之中。对于一个年消费 100 万美元的 AWS 客户来说AgentCore 的成本可能只占其总账单的 0.1%甚至更低。这本质上是一种“免费赠品”Freebie策略。The Lock-in Effect: 更可怕的是一旦你开始使用 AgentCore你就深度绑定了 AWS 的整个生态。你的tool_call直接调用的是arn:aws:lambda:us-east-1:123456789012:function:my-db-search你的vault_token是一个 AWS IAM Role 的临时凭证你的 event log 存储在 CloudWatch Logs Insights 里。迁移到 Anthropic意味着你要重写所有的 tools、重构所有的 credentials、迁移所有的 logs。这个成本远高于 $0.08/session-hour 的差价。6.2 开源压力曲线Daytona 与 Kubernetes SIG 的“鲶鱼效应”如果说 hyperscaler 是“大象”那么开源社区就是一群“狼”。它们不追求盈利只追求极致的性能、灵活性和社区认同。Daytona 和 Kubernetes SIG 的项目正是这条压力曲线上的关键节点。Daytona 的 Sub-90ms Spin-up: Daytona 的核心突破在于它将 sandbox 的启动时间从传统容器的几百毫秒压缩到了 90 毫秒以内。这是怎么做到的答案是pre-warmed sandbox pools。Daytona 的 controller 会预先启动一批“空白”的 Firecracker MicroVM并将它们维持在一个 ready-to-accept-work 的状态。当一个新 session 到来时controller 不是从零创建 VM而是从池子里“借”一个注入 agent 的 code 和 config然后启动。这就像机场的登机口永远有 2-3 个是提前打开、准备就绪的而不是每次航班都现开一个。Kubernetes SIG Agent-Sandbox: 这个项目的意义不在于它有多快而在于它有多“标准”。它定义了一套 Kubernetes CRDCustom Resource Definition如Sandbox,ToolBinding,SessionPolicy。这意味着任何遵循这套标准的 agent frameworkLangGraph, CrewAI都可以在任何兼容的 Kubernetes 集群上无需修改一行代码就获得与 Anthropic Managed Agents 几乎相同的能力。它把 runtime 层变成了一个可插拔的、标准化的 Kubernetes 插件。这直接动摇了所有 proprietary runtime 的根基——你的独特性正在被一个开放标准所消解。6.3 价值迁移的“三层楼”Trace Store、Governance、Vertical Marketplaces当 runtime 层不可避免地走向 commoditization商品化价值必然向上迁移。这场迁移正在三个清晰的楼层上同时发生。楼层核心价值关键玩家为什么它能存活一楼Runtime (正在坍塌)执行、隔离、状态管理Anthropic Managed Agents, AWS AgentCore, Daytona它们是“水电煤”是基础设施利润薄竞争烈终将被压至成本线。二楼Trace Store (正在崛起)What did the agent actually do?成为 agent 行为的唯一、权威、可移植的记录系统Braintrust (Brainstore), Arize (Phoenix), LangSmith企业需要一个与 runtime 无关的、能随 agent 一起迁移的“行为账本”。谁能提供最强大的查询、最开放的 API、最无缝的迁移工具谁就掌握了这个 layer。三楼Governance Policy (刚刚萌芽)What is the agent allowed to do?定义、执行、审计 agent 的行为边界AWS AgentCore Policy Controls, OWASP Agentic Top 10, 新兴的 startup随着 agent 被赋予越来越高的权限写数据库、发邮件、开 PR企业采购部门的第一个问题必然是“你们的 agent 有合规认证吗它的策略能和我们的 SOC2 流程对接吗” 这是一个由法规和采购驱动的刚性需求。四楼Vertical Marketplaces (爆发前夜)What job does the agent solve?将 agent 封装成一个垂直领域的、开箱即用的、可计量付费的 SaaS 产品Salesforce Agentforce, virattt/ai-hedge-fund, vxcontrol/pentagi企业不为“runtime”付费但会为“解决一个具体业务问题”付费。一个能将保险理赔周期从 14 天缩短到 2 小时的 agent其价值远超它运行在哪个 sandbox 里。我个人在实际操作中发现最值得早期投入的恰恰是二楼的 Trace Store。我们曾在一个金融项目中将所有 agent 的 event log 同步到一个自建的 ClickHouse 集群并基于此开发了一套内部的“Agent Health Dashboard”。它不仅能显示成功率、平均耗时更能回答“过去一周哪些 tool call 的失败率最高失败的原因是什么timeout vs auth_failure vs schema_mismatch哪些 session 的
