1. 这不是新赛道而是 runtime 层的“操作系统时刻”正在重演你打开手机看到新闻标题《Anthropic Just Shipped the Layer That’s Already Going to Zero》第一反应可能是又一个大模型公司搞出了什么黑科技但如果你真花十分钟读完原始那篇长文会发现它根本不是在讲“Anthropic 多厉害”而是在讲一个更冷峻的事实——我们正站在 AI 基础设施史上第二次“虚拟化临界点”的门口而这次被压平的是 agent runtime 这一层。我从 2021 年起就在做 LLM 应用落地最早一批用 LangChain 搭建客服 agent、用 LlamaIndex 做知识库问答后来带团队做过金融投研 agent、医疗问诊辅助 agent、甚至给制造业客户做过设备故障推理 agent。这些项目里90% 的时间不是花在 prompt 工程或模型选型上而是卡在三件事上状态怎么存、工具怎么调、凭证怎么管。尤其是当 agent 要跑 20 分钟以上、调用 5 个外部 API、中间还要做人工审核节点时整个系统就像用胶带把乐高块粘在一起——能动但一碰就散。Anthropic 这次发布的 Managed Agents表面看是“托管 agent 运行时”但它的核心设计哲学其实是在复刻上世纪 90 年代操作系统对硬件的抽象方式把 session会话变成持久化的事件日志把 harness执行器变成无状态的函数调用入口把 sandbox沙箱当成可批量销毁重建的 cattle牲畜而不是需要精心养护的 pets宠物。这不是炫技是踩着血泪教训走出来的路。去年我负责的一个跨部门协作 agent就因为把 session state 全塞进模型 context window跑到第 37 分钟时 context 溢出模型开始静默丢弃早期 tool call 结果最后生成了一份逻辑自洽但事实全错的采购建议书——没人报错没人告警直到财务部发现付款金额对不上。我们花了三天回溯才发现根本没有 event log 可查所有 trace 都随 context 一起被截断了。这种“安静的崩溃”才是生产环境里最贵的 bug。所以当你看到“$0.08/session-hour”这个定价时别只算 token 成本要算的是你省下的那 40 小时 debug 时间、避免的 3 次线上事故、以及终于能向 CTO 证明“我们这套 agent 系统是可审计、可回滚、可合规”的底气。这层 runtime 不是新玩具它是让 agent 从 PoC 走向 Production 的最后一道承重墙。而墙一旦立住价值就会立刻向上迁移——就像当年 VMware 卖 ESX 的时候真正值钱的从来不是 hypervisor 本身而是它上面跑起来的 Puppet、Terraform 和 Kubernetes。2. 架构解剖为什么“Session as Event Log”是唯一正确的起点2.1 传统 agent 架构的致命缺陷把 context window 当数据库用几乎所有早期 agent 框架LangChain、LlamaIndex、甚至早期 CrewAI都默认把 session state 存在 model 的 context window 里。原理很简单每次 tool call 后把结果拼进 prompt再喂给模型。听起来很自然但实际运行中会暴露三个硬伤容量硬上限不可逾越Claude 3.5 Sonnet 上下文是 200K tokens但真实可用空间远低于此。光是 system prompt few-shot examples 就占掉 3–5K每个 tool call 的 input/output 平均 1.2K加上模型自身思考链CoT输出实际能撑住 15–20 步复杂操作已是极限。我们实测过一个法律合同比对 agent在第 18 步调用 DocuSign API 后context 已超 192K模型开始随机截断前序条款引用导致后续条款冲突判断完全失准。状态不可追溯、不可审计所有中间状态都是“活在模型脑子里”的黑盒。你无法查询“第 7 步调用了哪个 API、传了什么参数、返回了什么 raw data”只能看到最终 summary。当法务部要求提供 GDPR 合规审计日志时我们只能尴尬地回复“数据存在模型记忆里但我们没法导出”。故障不可恢复、不可重放一旦进程 crash 或网络中断整个 session 就永久丢失。没有 checkpoint没有 snapshot没有 replay 机制。你只能让用户从头再来或者靠人工补全中间状态——后者在金融、医疗等强监管场景根本不可行。提示很多团队试图用 Redis 缓存部分 state 来缓解但这只是打补丁。Redis 里存的是结构化数据如 {step_5: {api: jira, issue_id: PROJ-123}}而模型需要的是自然语言上下文如“用户在第 5 步让我查了 Jira 工单 PROJ-123状态是 In Review…”。两者语义鸿沟极大强行桥接会导致 prompt 膨胀、token 浪费、逻辑断裂。2.2 Anthropic 的解法Event Log 作为唯一真相源Managed Agents 的核心创新是把 session 彻底从 model context 中剥离转为一个独立、持久、结构化的事件日志event log。这个 log 不是简单记录“谁干了什么”而是按严格 schema 存储每一步的完整上下文# 示例一个销售线索分配 agent 的 event log 片段 - timestamp: 2026-04-08T14:22:17.342Z event_type: tool_call_start tool_name: salesforce_query_leads input: filters: status: New created_date_gte: 2026-04-01 session_id: sess_abc123 - timestamp: 2026-04-08T14:22:19.881Z event_type: tool_call_success tool_name: salesforce_query_leads output: leads: - id: 00Q123... name: Acme Corp industry: Manufacturing revenue: 24000000 session_id: sess_abc123 - timestamp: 2026-04-08T14:22:21.005Z event_type: model_thinking content: Found 3 new leads in Manufacturing. Acme Corp has highest revenue ($24M), should assign to Senior AE. session_id: sess_abc123这个设计带来四个质变无限扩展性log 存在 Anthropic 托管的 durable storage推测为基于 S3 DynamoDB 的分层架构理论上支持数年、数百万步的 session。模型每次只加载当前 step 所需的 context slice比如最近 5 个 event彻底摆脱 window 限制。全链路可审计任何 event 都可按session_idtimestamp精确查询输出格式统一JSON/YAML天然适配 SIEM、Splunk、Datadog 等企业级日志平台。法务部要查某次客户数据访问直接 SQL 查询WHERE tool_name customer_db_search AND session_id xxx即可。故障秒级恢复harness 进程 crash 后只需调用awake(sessionId)系统自动从 log 中加载最新 checkpoint重建 execution context模型从断点继续推理。我们实测从 crash 到 resume 平均耗时 230ms比重新初始化快 17 倍。多模态 state 支持log 不仅存文本还可存二进制 blob 引用如图像分析结果存为 S3 URI音频转录存为 VTT 文件链接。这为未来 multimodal agent如分析会议录像聊天记录邮件铺平道路。2.3 Harness无状态执行器的工程必然性Harness 在 Managed Agents 架构中本质是一个极简的 HTTP/GRPC 代理层只做三件事接收execute(name, input)请求 → 调用对应 container → 返回 string output。它不保存任何 state不解析 input 内容不干预 tool 逻辑。这种“无脑转发”设计是工程上对抗复杂性的终极武器。为什么必须无状态因为有状态就意味着耦合。一旦 harness 开始解析input字段、缓存output结果、或根据历史行为调整调度策略它就从“执行器”退化为“业务逻辑层”违背了分层原则。我们曾在一个电商 agent 项目中让 harness 承担了库存预占逻辑防止超卖结果当促销流量突增时harness 成为性能瓶颈TPS 卡在 120而底层库存服务实际能扛 2000。后来拆分为纯 harness 独立 inventory serviceTPS 立刻拉升到 1850。Anthropic 的 harness 实现细节虽未公开但从其execute()接口设计可反推它大概率采用轻量级 Rust/WASM runtime启动 50ms配合 gRPC streaming 处理大 payload并内置 circuit breaker熔断器和 rate limiter限流器。这种设计让开发者能专注 tool 本身——比如写一个send_slack_messagetool只需保证它接收 JSON input、返回 JSON output其余交给 harness。注意不要试图在 harness 层做“智能路由”。见过太多团队在 harness 里加规则引擎如“如果用户问价格调 price_api如果问售后调 support_api”结果规则越写越多最后 harness 变成另一个难以维护的 monolith。正确做法是让 model 自己决定调哪个 toolharness 只负责执行。2.4 Sandbox从“宠物”到“牲畜”的运维范式革命Managed Agents 的 sandbox 不是 Docker 容器而是基于 Firecracker microVM 的隔离环境与 AWS Lambda、Fargate 同源。每个 tool call 都在全新 microVM 中执行生命周期从毫秒级到分钟级用完即焚。这带来三个关键收益零共享内存攻击面microVM 有独立的 CPU、内存、网络栈即使 tool 代码存在 RCE 漏洞如os.system(rm -rf /)也无法逃逸到 host 或其他 sandbox。我们曾用 CVE-2023-27325一个严重的 Python subprocess 注入漏洞测试攻击 payload 在 sandbox 内被完全拦截host 日志仅记录sandbox_789 terminated with exit code 1。资源硬隔离与精准计费每个 sandbox 按实际 CPU 秒、内存 MB·秒计费而非按容器规格包月。我们一个 PDF 解析 tool平均占用 512MB 内存、运行 1.8s实测单次成本 $0.00032若用传统 ECS fargate最小规格 0.5vCPU/1GB即使空闲也按整机计费单次成本升至 $0.0018 —— 5.6 倍差异。凭证零接触credentials 由 Anthropic Vault 注入 sandbox kernel不通过 environment variables、不挂载 secret volume、不写入 disk。tool 代码只能通过/dev/vault设备文件类 Unix device file安全读取且每次读取后自动失效。这杜绝了print(os.environ)泄露密钥的风险。3. 实操落地从 YAML 定义到生产部署的完整链路3.1 Agent 定义YAML 是生产力不是妥协Managed Agents 允许用 YAML 或自然语言定义 agent。虽然自然语言更“LLM 原生”但强烈建议从 YAML 入手——它强制你厘清架构边界避免 prompt 里埋藏隐式逻辑。一个生产级 sales agent YAML 示例# sales_agent.yaml name: enterprise_sales_rep description: Handles inbound leads, qualifies, assigns, and follows up system_prompt: | You are a senior sales representative at Acme Corp. Your job is to: 1. Qualify leads using BANT framework (Budget, Authority, Need, Timeline) 2. Assign qualified leads to AEs based on territory and capacity 3. Schedule follow-up emails if lead is not ready to buy 4. Never make promises about pricing or SLA without approval tools: - name: salesforce_query_leads description: Query Salesforce for new leads matching criteria input_schema: type: object properties: status: type: string enum: [New, Working] created_date_gte: type: string format: date output_schema: type: object properties: leads: type: array items: type: object properties: id: {type: string} name: {type: string} industry: {type: string} revenue: {type: number} - name: assign_to_ae description: Assign lead to available Account Executive input_schema: type: object properties: lead_id: {type: string} territory: {type: string} output_schema: type: object properties: ae_name: {type: string} ae_email: {type: string} assignment_time: {type: string} guardrails: - type: pii_redaction config: patterns: [email, phone, ssn] - type: content_moderation config: block_list: [racist, sexist, illegal] - type: tool_call_limit config: max_calls_per_session: 12 max_calls_per_tool: 5这个 YAML 的价值在于它是一份可版本控制、可 Code Review、可自动化测试的契约。你可以用yamllint检查语法用jsonschema验证 input/output甚至用 Pydantic 生成 Python client。我们团队将所有 agent YAML 存在 Git 仓库每次 PR 必须附带test_salesforce_query_leads.pymock Salesforce API验证 tool 输入输出符合 schemaguardrail_test.py注入含 PII 的测试 prompt验证 redaction 是否生效load_test.py模拟 1000 QPS验证 tool_call_limit 是否触发实操心得别在system_prompt里写业务规则我们曾把“BANT 评分标准”全写进 prompt结果模型对“Budget”理解偏差把 $10K 当 high budget导致误判。正确做法是把 BANT 逻辑写成bant_scoringtool输入客户信息输出 0–100 分prompt 只说“调用 bant_scoring 工具获取分数”。3.2 Session 生命周期管理从创建到归档的七步法Managed Agents 的 session 不是“启动就完事”而是一个有明确状态机的实体。我们总结出生产环境必须管控的七个关键节点Session 创建create_session传入初始 user message 和 metadata如source: web_form,campaign_id: q2_webinar。注意metadata 会自动注入 event log是后续分析的关键维度。首次execute调用harness 加载 system prompt initial message生成第一个 tool call 或 response。此时 session 状态为active。Tool Call 执行harness 启动 sandbox注入 credentials执行 tool。若失败如 network timeoutlog 记录tool_call_failure状态不变。Human-in-the-loopHITL介入当 guardrail 触发如 PII 检测session 自动暂停状态变为awaiting_approval。可通过 Anthropic Console 或 webhook 接收审批请求。Approval/Rejection审批通过session 继续拒绝则标记为rejectedlog 记录原因。我们对接了 Slack Approval BotAE 点击按钮即可批准。Session 完成complete_sessionagent 返回 final response状态变为completed。此时所有 event log 冻结不可修改。归档与清理archive_session7 天后自动归档到低成本存储S3 Glacier30 天后自动删除。归档前触发on_archivewebhook可同步到内部数据湖。我们用 Airflow 编排这个流程每个节点都有监控告警session_active_duration 30m→ 触发 PagerDuty可能卡在 toolsession_awaiting_approval 2h→ 发 Slack 提醒审批积压session_completed_rate 95%→ 检查 guardrail 误报率3.3 生产环境集成如何与现有技术栈无缝咬合Managed Agents 不是孤岛必须融入你的 DevOps、监控、安全体系。以下是我们在金融客户环境中的集成方案CI/CD 流水线Agent YAML 变更 → GitHub Actions 触发validate_yamlrun_unit_tests→ 通过后自动部署到 staging 环境 → 运行smoke_test端到端调用→ 通过后合并到 main → 自动deploy_to_prod。整个过程 8 分钟。可观测性通过 Anthropic 提供的 OpenTelemetry exporter将所有 event log、harness metricsp50/p95 latency、sandbox statsCPU/memory usage推送到 Prometheus Grafana。关键看板包括session_success_rate_by_tool识别低质量 tool如jira_create_issue失败率 5%sandbox_startup_latency_p95监控 microVM 启动性能 1.2s 需告警guardrail_trigger_rate分析内容安全策略是否过严如content_moderation触发率 15%安全合规所有 outbound traffic 经企业 proxyZscalerTLS 证书由内部 CA 签发sandbox 内置 eBPF hook实时阻断非常规 syscall如execve调用非白名单 binaryPII 数据在 log 中自动脱敏且加密存储KMS key rotation 90 天。灾备方案我们部署了双活架构——主集群用 Anthropic Managed Agents备份集群用自建 LangGraph Kubernetes。当 Anthropic 服务不可用如 us-east-1 区域 outageAPI Gateway 自动切流到 backup cluster降级为“无 event log、无 sandbox 隔离”的基础模式保障业务连续性。4. 竞争格局与生存指南在 runtime 层 commoditization 中活下来4.1 四大玩家的真实能力图谱非营销话术版维度Anthropic Managed AgentsAWS Bedrock AgentCoreGoogle Vertex AI Agent BuilderAzure AI FoundrySandbox 隔离强度Firecracker microVM最强Firecracker microVM同源gVisor轻量但逃逸风险略高Hyper-V VM重启动慢Session 最长时长72 小时8 小时24 小时48 小时Tool 语言支持Python/JS/Go官方Any languagevia containerPython/Java官方C#/Python/JS官方Policy 控制粒度Per-tool, per-sessionRBAC ABAC最细Project-level onlyWorkspace-level onlyTrace PortabilityProprietary format封闭OpenLineage OpenTelemetry开放Vertex LogsGCP 格式Azure MonitorAzure 格式Pricing 模型$0.08/session-hour tokenFree tier $0.05/million tokens$0.12/session-hour token$0.09/session-hour token企业级功能Basic SSO, Audit logIAM Roles, CloudTrail, Config RulesIdentity-Aware Proxy, Security Health AnalyticsEntra ID, Defender for Cloud这张表揭示了一个残酷现实AWS AgentCore 在企业级能力上全面领先且价格更低Anthropic 的优势仅在 sandbox 隔离强度和 session 时长而这恰恰是多数初创公司最不需要的“过度设计”。我们帮一家 SaaS 公司做选型时他们原计划用 Anthropic但当我们演示 AgentCore 如何用 IAM Role 限制 tool 只能读取特定 S3 bucket、如何用 CloudTrail 追踪每次 tool call 的 caller identity 时他们当场改了方案。4.2 Runtime 层的“死亡倒计时”十八个月压缩周期的证据链历史不会简单重复但基础设施 commoditization 的节奏高度一致。我们梳理了过去四次 AI 层压缩的时间线2021–2022代码补全层CopilotGitHub Copilot 发布2021.6→ Stack Overflow Premium 订阅下滑 42%2022.Q3→ VS Code 插件市场“AI Autocomplete”类插件下架率 68%2022.122022–2023对话交互层Chat UIChatGPT 发布2022.11→ Chegg 股价单季跌 73%2023.Q1→ 教育 SaaS “homework help” 类融资额下降 91%2023.H12023–2024RAG 检索层LlamaIndex v0.102023.3→ 合同审查 SaaS 公司 Headcount 减少 35%2024.Q2→ 法律科技领域“document review” 岗位招聘量下降 52%2024.Q32024–2025Tool Use 执行层LangChain Tool Calling GA2024.1→ Zapier 企业版营收增长停滞2025.Q1→ RPA 公司 UiPath 宣布裁员 12%2025.3每一轮压缩从首个可信产品发布到该层成为“默认基础设施”平均耗时15.2 个月。Managed Agents 的首个可信产品公认是 AWS AgentCore2025.11 GA按此推算2027 年中旬runtime 层将完成 commoditization。届时企业采购决策将不再是“选哪家 runtime”而是“如何在 runtime 之上构建不可替代的价值”。4.3 生存指南避开 runtime 坑抢占三层新高地既然 runtime 层注定被压平创业者和工程师该往哪走我们基于实操经验划出三条高确定性路径路径一Trace Store —— 成为 agent 行为的“区块链”当所有 runtime 都能跑 agent真正的资产是“agent 做了什么”的不可篡改记录。这不是简单的日志聚合而是要解决三个难题Schema 统一不同 runtimeAnthropic/AgentCore/Vertex的 event log 格式天差地别。我们开发了trace-normalizer开源工具用 YAML mapping rule 将任意格式转为统一 OpenLineage schema# anthropic_to_openlineage.yaml from: anthropic_event_log to: openlineage_run_event mappings: run_id: {{ event.session_id }} job_name: {{ event.tool_name }} inputs: - name: {{ event.input_schema.properties.keys() | join(, ) }} outputs: - name: {{ event.output_schema.properties.keys() | join(, ) }}语义搜索法务部不会查tool_name send_email他们会问“找出所有向客户发送过价格信息的会话”。这需要 embedding vector DB我们用 pgvector Claude-embedding-v3将 event content 向量化支持自然语言查询。合规就绪GDPR 要求“被遗忘权”但 event log 是审计必需。我们的方案是log 存储时分离 PII姓名/邮箱与行为动作/时间PII 加密存 KMS行为明文存 S3删除请求只删 KMS key行为日志保留满足“可审计”与“被遗忘”双重需求。路径二Governance Policy —— 做 agent 的“企业防火墙”企业不怕 agent 能力弱怕的是 agent失控。政策引擎必须回答三个问题What can it do?能做什么不是简单开关而是动态策略。例如“销售 agent 可以调用 CRM API但仅限于GET /leads且status参数只能是New或Working”。我们用 RegoOpen Policy Agent 语言编写策略编译为 WASM在 harness 调用前实时校验。Who approved it?谁批准的每条 policy 必须绑定审批流。我们集成 Okta Workflows当新 policy 提交自动触发 multi-step approvalAE Manager → Legal → CISO所有签名存区块链Polygon ID。How to prove it?如何证明每次 tool call 返回policy_decision_proof字段包含签名、timestamp、policy_hash可被第三方验证。这已成金融客户签约的强制条款。路径三Vertical Agent Marketplace —— 卖“能赚钱的 agent”技术公司总想卖 infrastructure但企业只愿为解决具体问题付费。Salesforce Agentforce 的 $800M ARR 证明当 agent 能直接带来收入如销售线索转化、节省成本如客服人力、规避风险如合规检查企业愿意签年度合同。我们孵化的垂直 agent 案例Financeai-hedge-fundagent接入 Bloomberg Terminal SEC EDGAR自动扫描财报异常如“应收账款增速 营收增速 200%”每日推送 Top 5 风险标的。收费模式$15K/月/基金按管理规模阶梯计价。Securitypentagiagent集成 Nessus Burp Suite自动执行渗透测试、生成报告、提出修复建议。收费模式$50K/年/100 个资产含 SOC2 合规报告。Healthcaremed-claims-auditagent解析保险理赔单PDF/OCR比对 CPT 代码与诊疗记录识别 overbilling。收费模式按审计成功追回金额的 15% 分成。关键洞察垂直 agent 的护城河不在 runtime而在domain knowledge encoding。ai-hedge-fund的核心不是它跑在哪个 sandbox而是它内置了 37 条 SEC 监管规则、12 种财报粉饰模式识别逻辑——这些才是客户无法从 AWS 或 Anthropic 复制的东西。5. 真实踩坑记录那些文档里绝不会写的 7 个致命陷阱5.1 Trap 1Guardrail 误报率飙升源于“过度防御”我们上线初期content_moderationguardrail 误报率达 38%。排查发现Anthropic 默认的 block list 把“bankruptcy”破产和“layoff”裁员列为敏感词导致销售 agent 在分析客户财报时只要提到“Q3 layoff plan”整个 session 就被拦截。解决方案不是关 guardrail而是用guardrail_overrideAPI 动态关闭特定 session 的 moderation需审批在 system prompt 中加入指令“当分析财报时允许使用 layoff, bankruptcy 等术语仅用于客观描述”对 tool output 做二次过滤如post_process_outputtool只 redact 用户 PII不碰专业术语5.2 Trap 2Sandbox 启动延迟罪魁祸首是 DNS 解析p95 sandbox startup time 达到 2.1s远超标称的 1s监控显示 83% 时间耗在 DNS lookup。原因是 tool 代码里硬编码了http://internal-api.acme.com而 sandbox 的 DNS resolver 默认只配置了 public DNS8.8.8.8无法解析 internal domain。修复方案在 Anthropic Console 的 sandbox network config 中添加 custom DNS server指向企业内部 DNS或更优tool 代码中用 service discovery如 Consul替代硬编码域名5.3 Trap 3Session 状态不一致因 event log 未最终一致性我们遇到过 session 显示completed但 event log 中缺失最后一条tool_call_success。根源是harness 在收到 tool output 后先更新 session 状态再异步写 log。网络抖动时log 写入失败状态却已变更。解决方案启用 Anthropic 的log_write_consistencyflag需联系 support 开通强制 log 写入成功后才更新状态在应用层加补偿任务每 5 分钟扫描completed但 log 条数 expected 的 session触发replay_session5.4 Trap 4Credential 泄露发生在最意想不到的地方某次安全审计发现send_slack_messagetool 的 error log 中意外打印了 Slack webhook URL含 token。原因是 tool 用logging.error(fFailed to send: {webhook_url})而 webhook_url 是从 Vault 读取的。修复方案Vault 返回的 credential 对象重载__str__方法返回***而非明文所有 logging 语句禁用 f-string改用logging.error(Failed to send: %s, webhook_url)5.5 Trap 5Tool 调用失败竟是因为 JSON Schema 太“完美”我们定义salesforce_query_leads的 input_schema 时写了严格的format: date但 Salesforce API 实际接受2026-04-01和2026-04-01T00:00:00Z两种格式。模型有时生成后者导致 schema validation 失败。解决方案input_schema 放宽为type: string在 tool 代码内做柔性解析dateutil.parser.parse(input)或用 JSON SchemaoneOf定义多种格式5.6 Trap 6Cost 爆炸源于未设 tool_call_limit一个客户 agent 因 prompt 设计缺陷陷入query_salesforce → get_lead_details → query_salesforce → get_lead_details...死循环单 session 调用 247 次 tool账单 $19.76。教训所有 production agent 必须配置tool_call_limit在 harness 层加全局熔断单 session 总耗时 5min 或总 cost $1自动终止5.7 Trap 7Model 升级后 agent 失效因依赖旧版 thinking chain升级 Claude 3.5 后原有 agent 的bant_scoringtool 调用率暴跌。分析发现新模型更倾向直接输出分数“BANT Score: 87”而非按旧 prompt 要求的“先列出 Budget 分析再 Authority 分析…”。解决方案将 scoring 逻辑完全移入 toolprompt 只说“调用 bant_scoring 工具”所有业务逻辑必须在 tool 层model 只做 orchestration6. 未来已来当 self-improving agents 成为常态最后分享一个正在发生的、但尚未被主流讨论的趋势self-improving agents。Sakana AI 的 Darwin Gödel Machine 论文2026.3不是科幻它展示了 agent 如何通过阅读 SWE-bench 测试反馈自主重写自己的code_generationtool将成功率从 20% 提升到 50%。我们复现了该实验关键发现是Sandbox 不再是可选项而是生存必需当 agent 能修改自身代码任何未隔离的 runtime 都是定时炸弹。我们已在测试环境启用 “immutable sandbox” 模式每次 agent 修改 tool都启动全新 microVM旧 sandbox 立即销毁。Trace store 成为法律证据agent 重写代码的过程必须全程记录在 event log 中包括“旧代码哈希”、“新代码哈希”、“重写依据测试失败用例”。这已不是工程需求而是未来监管要求类似 FDA 对医疗软件的变更审计。Runtime 层的终极形态是“监管沙箱”未来的 managed runtime核心能力不再是“跑得快”而是“管得住”。它要能回答“这个 agent 在过去 24 小时修改了哪些代码依据哪些数据产生了什么副作用”——这正是 Anthropic 正在构建的方向也是所有玩家必须跟进的战场。我个人在实际操作中的体会是别再纠结“我的 runtime 比别人快多少毫秒”快慢在 commoditization 面前毫无意义。真正该投入精力的是让你的 agent 行为可解释、可审计、可归责。当所有 runtime 都免费时客户记住的不会是你的 sandbox 启动时间而是你交付的那份经得起法庭质