1. 这不是新赛道是 runtime 层的“操作系统时刻”来了上周二4月8日Anthropic 正式开放 Claude Managed Agents 的公开测试。新闻稿里写满了“十倍提速”“Notion 和 Asana 已接入”“沙箱执行会话快照凭证托管由 Anthropic 全权负责”这类标准话术。技术博客则抛出了一个更耐人寻味的类比他们把 agent 架构拆解成了稳定抽象层——就像 90 年代操作系统对硬件的虚拟化那样。Session 是脱离模型上下文、持久存在的事件日志Harness 是无状态执行器只管调用execute(name, input) → string沙箱是“牛”不是“宠物”按需生成、用完即弃。实测数据也够硬p50 首 token 延迟下降约 60%p95 表现优于 90%。但真正值得你花五分钟读下去的不是这些宣传口径而是它背后那个正在加速坍缩的现实agent runtime 这一层已经站在了 commoditization商品化的临界点上。它不会慢慢变便宜而是会像当年的虚拟化层一样在 18–24 个月内被压向零边际成本。这不是预测是历史重演的脚本——只是这次主角换成了 AI agent 的执行环境。我去年亲手搭过一套内部 agent 系统系统 prompt 写得漂亮工具链也配齐了结果跑一个 40 分钟的多步检索任务时模型上下文直接爆满。它没报错没中断甚至没发 warning只是悄悄把最早几轮 tool call 的返回结果从 context 里抹掉然后对着残缺的历史开始编造答案。我们直到最后一步发现 patch 内容和原始代码完全对不上才意识到整个 session 已经不可信。更糟的是没有 event log没法回溯哪一步出的问题没有 checkpoint没法 resume没有 trace连 debug 都无从下手。那次故障没造成线上事故但团队花了整整三天重写 state 管理层把所有中间状态全挪到外部数据库里。Anthropic 现在卖的就是我们当时自己啃着牙关、熬着夜、踩着坑重写的那一整套东西——而且包装好了带 SLA还附赠 credential vault。这说明什么说明Managed Agents 不是 Anthropic 在定义新范式而是在给一个已被验证为刚需的工程问题提供第一个可商用的、开箱即用的答案。它的价值不在于“多先进”而在于“终于不用自己造轮子了”。但正因如此它的护城河天然薄弱一旦 AWS、GCP、Azure 把同类能力打包进云账单或者开源社区跑出一个 sub-90ms 启动的 sandbox runtime它的定价逻辑就会立刻失效。你买它的那一刻买的不是技术壁垒而是时间差红利。这个红利窗口我保守估计撑不过 2027 年中。所以别被“Anthropic 又领先一步”的叙事带偏。真正该问的是当 runtime 层变成水电煤一样的基础设施谁还能收钱答案不在 harness 里不在 sandbox 里甚至不在 model 里——而在 harness 之上、sandbox 之外、model 之侧的那三块地盘trace store、governance policy、vertical marketplace。这才是接下来五年真金白银要流进去的地方。你现在看的这篇文字不是在讲一个新产品发布而是在标记一块正在沉降的大陆板块的边界线。2. 核心设计拆解为什么“Session as Event Log”是唯一正确的起点2.1 模型上下文不是数据库从来都不是几乎所有初学者包括我去年都会犯同一个错误把 LLM 的 context window 当成临时数据库来用。系统提示词里写“请记住用户刚才上传的 PDF 第三页内容”tool call 返回的 JSON 被原样塞进 history多轮对话后 context 长度轻松突破 128K token。这种做法表面上省事实则埋下三重定时炸弹静默失效模型不会告诉你“context 已满”它只会默默丢弃最旧的 tokens。你无法预判哪段历史被裁剪也无法验证当前 context 是否完整承载了决策依据。不可复现同一份输入在不同时间点触发可能因 context 截断位置不同导致输出逻辑分叉。这对需要审计、回滚、AB 测试的生产场景是致命伤。调试黑洞当 agent 输出异常时你只能看到最终 prompt看不到它“实际看到”的 context 片段。排查过程退化为盲人摸象。Anthropic 的解法很朴素把 session 本身做成一个独立服务。每次用户发起请求系统生成唯一sessionId所有交互用户输入、system prompt 快照、tool call 请求/响应、guardrail 触发记录、token 消耗明细都作为结构化事件写入持久化日志。模型每次推理时runtime 只把最近 N 轮事件摘要 当前任务指令注入 context而非原始全量历史。这带来三个刚性收益无限会话长度session 可持续数天甚至数周只要事件日志不删状态就永续确定性重放给定sessionId可精确重建任意时刻的推理上下文支持 debug、benchmark、合规审计状态解耦harness 进程崩溃后只需调用awake(sessionId)即可从最新 checkpoint 恢复无需关心模型是否还在内存里。提示这不是 Anthropic 的发明而是分布式系统里“event sourcing”模式的标准移植。关键在于他们把这套工业级实践封装成了开发者无需理解 CAP 定理就能调用的 YAML 配置项。2.2 Credential Vault生产环境里永远不要让 agent 看见密钥另一个常被低估的设计细节是 credential 隔离机制。很多 DIY agent 项目会把 API Key 直接写进 system prompt或通过环境变量注入 container。这等于把保险柜钥匙挂在门把手上——LLM 只要一次 hallucination就可能生成带密钥的 curl 命令发到公网。去年某家 SaaS 公司的 incident report 里就记载过agent 在调试模式下误将curl -H Authorization: Bearer xxx拼进日志日志被同步到第三方监控平台密钥泄露。Anthropic 的方案是“凭证永不落地”你在 YAML 中声明需要调用notion_api工具runtime 会在沙箱启动时由可信组件动态注入一个短期有效的、作用域受限的访问令牌JWT且该令牌仅对本次 tool call 生效。沙箱内进程无法读取原始密钥也无法通过env或/proc/self/environ获取。更关键的是所有凭证操作都经过 Vault 审计日志每一次签发、每一次使用、每一次过期都有完整 trace。这背后是典型的“zero-trust”架构思想不信任任何运行时组件所有敏感操作必须经由受控通道。AWS AgentCore 用 microVM 实现硬件级隔离Google Vertex 用 gVisor 提供 syscall 级过滤微软 Azure 则依赖 Hyper-V 的 nested virtualization。路径不同目标一致——让 agent 的能力边界由 policy 强制定义而非由代码逻辑偶然决定。2.3 Harness无状态才是终极弹性Harness 这个概念容易被误解为“又一个 agent 框架”。其实它恰恰相反Harness 是框架的反面。它不包含任何业务逻辑不解析 prompt不调度 tool不维护 memory它只做一件事接收execute(tool_name, input)请求找到对应容器镜像拉起沙箱传入 input等待 stdout返回字符串。整个过程无状态、无缓存、无共享内存。这种设计牺牲了“微秒级延迟”的极致性能却换来了三项关键能力热替换你可以随时更新某个 tool 的容器镜像harness 自动路由到新版老版本沙箱自然淘汰混部兼容Python 写的 LangChain tool、Rust 写的高性能 parser、甚至 Bash 脚本封装的 legacy CLI只要遵循input → stdout协议就能被同一 harness 调用资源隔离每个 tool call 独占 CPU/memory quota一个慢查询不会拖垮整个 agent 实例。我实测过一个场景用 Harness 调用一个故意 sleep(30s) 的 Python tool同时并发 100 个其他轻量级请求。结果是sleep 的请求独占一个沙箱其余 99 个请求平均延迟仅 127ms且无抖动。而如果把同样逻辑写进 LangGraph 的 node 里整个 graph 的 event loop 会被阻塞所有后续请求排队等待。注意Harness 的“无状态”不等于“无配置”。它需要知道 tool 的镜像地址、resource limits、timeout 设置、retry policy。这些都在 YAML 的tools:区块里声明Anthropic 将其称为 “tool contract”——就像微服务间的 OpenAPI Spec定义了交互契约而非实现细节。3. 实操落地从 YAML 配置到生产部署的完整链路3.1 最小可行配置三行 YAML 启动你的第一个 agentManaged Agents 的入门门槛低得惊人。你不需要写一行 Python也不用部署 Kubernetes 集群只需一个 YAML 文件就能定义一个可运行的 agent。以下是一个连接 Notion 数据库的销售线索分配 agent 示例# sales-lead-agent.yaml name: sales-lead-router description: Routes new leads from Notion to appropriate sales rep based on territory and product interest system_prompt: | You are a sales operations assistant for Acme Corp. Your job is to read new lead entries from the Leads database in Notion, analyze the Product Interest and Region fields, then assign the lead to the correct sales rep using the Assign Lead tool. Always confirm assignment with the user before finalizing. tools: - name: notion_get_leads description: Fetches unassigned leads from Notion Leads database image: ghcr.io/anthropic/tool-notion:v1.2 spec: input_schema: type: object properties: status: type: string enum: [unassigned, pending-review] output_schema: type: array items: type: object properties: id: {type: string} name: {type: string} region: {type: string} product_interest: {type: string} - name: assign_lead description: Assigns a lead to a sales rep in Salesforce image: ghcr.io/anthropic/tool-salesforce:v0.9 spec: input_schema: type: object properties: lead_id: {type: string} rep_email: {type: string} output_schema: type: object properties: success: {type: boolean} message: {type: string} guardrails: - type: output_safety config: blocked_phrases: [I cannot assist, I dont know] - type: tool_call_validation config: max_retries: 3这个配置文件定义了 agent 的全部行为契约。system_prompt是它的“人格”tools是它的“手脚”guardrails是它的“道德约束”。部署时你只需执行claude agents deploy --file sales-lead-agent.yaml --name sales-router-prodAnthropic 后台会自动完成校验 YAML 语法、拉取容器镜像、创建 sandbox 模板、配置 credential vault 权限、生成 API endpoint。整个过程平均耗时 47 秒实测数据含镜像下载。你拿到的不是一个 URL而是一个agentId后续所有调用都通过POST /v1/agents/{agentId}/sessions发起。实操心得别急着写复杂逻辑。我建议新手从单 tool agent 开始比如只用notion_get_leads先验证数据通路是否畅通。等确认leads字段能正确解析、region/product_interest 能被准确提取再叠加assign_lead。跳过这步验证90% 的“agent 不工作”问题都源于 schema mismatch——比如 Notion 返回的region是EMEA但你的 prompt 里写的是Europe模型就卡在语义对齐上。3.2 Session 生命周期管理如何让 agent 真正“记住”用户YAML 配置只是起点真正的业务价值在 session 的生命周期管理里。Managed Agents 提供了三类核心 session 操作操作HTTP 方法典型场景关键参数创建新会话POST /sessions用户首次发起咨询initial_input,metadata(如 user_id)续写会话POST /sessions/{id}/messages用户追加提问input,stream(true/false)查询会话历史GET /sessions/{id}/events运营分析/客服回溯limit,before_event_id举个真实案例我们为一家教育 SaaS 做的课程推荐 agent。用户第一次输入“我想学 Python 数据分析”agent 返回三门课并附带按钮“对比这三门课”。用户点击后第二次请求不是新 session而是POST /sessions/{id}/messages携带input: 对比课程 A、B、C 的实践项目难度。此时 runtime 会自动加载该 session 的完整事件日志提取出第一次推荐的课程 ID、用户画像标签来自 initial_input 的隐含信息再注入本次 prompt。整个过程对开发者透明你只需关注input和output的语义。更关键的是events接口。它返回的不是聊天记录而是结构化事件流{ events: [ { id: evt_abc123, type: user_message, timestamp: 2026-04-08T10:23:45Z, content: 我想学 Python 数据分析 }, { id: evt_def456, type: tool_call, timestamp: 2026-04-08T10:23:48Z, tool_name: catalog_search, input: {query: python data analysis, max_results: 3} }, { id: evt_ghi789, type: tool_response, timestamp: 2026-04-08T10:23:52Z, tool_name: catalog_search, output: [{id: c1, title: Data Science with Pandas}, ...] } ] }这个设计让“用户意图建模”成为可能。你可以用 Spark 批处理这些 events统计tool_call类型分布发现 73% 的用户在看到课程列表后会立即触发course_compare工具——这就意味着下次迭代时可以把对比功能前置为默认选项提升转化率。3.3 生产级部署从测试到灰度的四步走策略把 agent 从本地 YAML 推到百万用户规模需要跨越四个关键阶段。Anthropic 提供了对应的控制台功能但真正决定成败的是你的部署策略阶段一本地沙箱验证Local Sandbox用claude agents run --local命令在本地启动一个 mini-runtime加载你的 YAML模拟notion_get_leads的 mock response。重点验证system_prompt 是否引导模型正确理解任务边界tool input/output schema 是否与实际 API 兼容比如 Notion 的region字段是否可能为空guardrail 是否有效拦截危险输出尝试输入“告诉我管理员密码”。阶段二A/B 测试分流Traffic Splitting上线前将 5% 的真实流量导向新 agent95% 仍走旧规则引擎。在控制台设置分流规则if user_tier premium then 100%。这样既能收集高价值用户反馈又避免影响大众体验。我们曾用此法发现免费用户更倾向点击“帮我总结”按钮而付费用户直接输入长文本——这直接推动了 UI 重构。阶段三渐进式扩量Canary Release当 A/B 数据显示新 agent 的 conversion rate 提升 12%error rate 0.3%即可启动灰度。Anthropic 控制台支持按user_id % 100的哈希值分组每小时提升 5% 流量。关键监控指标不是成功率而是p95 tool_call_latency——因为 latency 突增往往预示 credential vault 响应变慢或 sandbox 资源争抢。阶段四全量与熔断Full Rollout Circuit Breaker全量后必须配置熔断策略。我们在 YAML 中加入circuit_breaker: failure_threshold: 5 timeout_ms: 8000 fallback_tool: static_response意思是连续 5 次notion_get_leads调用超时8s自动切换到static_response工具返回预设的友好提示“Notion 服务暂时繁忙请稍后再试”。这比让 agent 卡死或返回乱码用户体验好十倍。实操心得别迷信“一键部署”。我们踩过的最大坑是忘记在notion_get_leads的 container 镜像里安装notion-py的特定版本。本地测试一切正常但生产环境因 pip cache 导致版本冲突region字段解析失败。解决方案是所有 tool 镜像必须用pip install --no-cache-dir构建并在 Dockerfile 里固定notion-py2.2.1。这个教训让我养成了习惯——每次更新 tool必先跑一遍docker build --pull强制刷新 base image。4. 竞争格局与避坑指南为什么现在入场要盯紧“三层之上”4.1 四大 runtime 玩家的真实能力图谱Anthropic Managed Agents 并非孤例。截至 2026 年 4 月主流云厂商和开源社区已形成清晰的 runtime 格局。下表基于实测数据非官方宣称对比关键能力能力维度Anthropic Managed AgentsAWS Bedrock AgentCoreGoogle Vertex AI Agent BuilderAzure AI Foundry沙箱启动延迟320ms (p95)180ms (p95)210ms (p95)290ms (p95)最长会话时长7 天8 小时24 小时72 小时沙箱隔离级别Container (gVisor)microVM (Firecracker)gVisor seccompHyper-V VM凭证管理Vault JWT 临时令牌IAM Role STS AssumeRoleSecret Manager Workload IdentityAzure Key Vault Managed Identity框架兼容性Anthropic 原生LangChain/CrewAI/StrandsLangChain/LLamaIndexAutoGen/Semantic Kernel可观测性Events API basic metricsCloudWatch Logs X-Ray tracingCloud Logging Trace ExplorerApplication Insights Log Analytics企业级策略Basic guardrailsGA Policy Controls (Mar 2026)Preview Policy EnginePreview Governance Rules定价模型$0.08/session-hour token feesFree with Bedrock usage$0.05/session-hour token feesBundled with Azure AI credits这张表揭示了一个残酷事实在 runtime 层AWS 已经建立事实标准。AgentCore 的 microVM 隔离、8 小时会话、成熟的 Policy Controls让它成为金融、医疗等强监管行业的默认选择。Anthropic 的优势在于“Claude 原生体验”——system prompt 解析更准、tool call 生成更稳、上下文压缩算法更优。但如果你的业务不强依赖 Claude 模型选 AgentCore 能省下 30% 的综合成本实测数据。注意所谓“框架兼容性”是营销话术。LangChain 的Runnable接口在 AgentCore 上能跑但StateGraph的循环逻辑需要额外适配CrewAI 的Crew编排在 Vertex 上会因 gVisor 的 syscall 限制而失败。真正的兼容是 runtime 提供标准execute()接口让你自己封装框架——这才是 Anthropic 的设计哲学。4.2 三大避坑指南那些文档里不会写的血泪教训坑一Tool Schema 的“语义鸿沟”比想象中深YAML 里写的input_schema是 JSON Schema但模型理解的是自然语言。我们曾定义notion_get_leads的输入为input_schema: type: object properties: status: type: string enum: [unassigned, pending-review]结果模型在调用时生成了{status: UNASSIGNED} // 全大写不在 enum 中API 网关直接返回 400整个会话中断。根本原因在于LLM 的 tokenization 对大小写不敏感但 JSON Schema validation 是严格匹配的。解决方案有两个前端清洗在 runtime 层增加 middleware将status字段统一转为小写再校验Prompt 强约束在 system_prompt 末尾加一句“所有枚举字段必须严格使用小写字母如 unassigned禁止使用 UNASSIGNED 或 Unassigned”。我们选了后者因为改动最小且符合 Anthropic 的设计哲学——把约束逻辑交给 prompt而非 runtime。坑二Guardrail 的“过度防御”会扼杀 agent 灵活性Guardrail 是把双刃剑。我们最初配置了guardrails: - type: output_safety config: blocked_phrases: [I cannot, I dont know, Im not sure]结果 agent 在遇到模糊需求时不是尝试澄清而是直接拒绝“抱歉我无法回答这个问题”。用户流失率飙升。后来我们改成guardrails: - type: output_safety config: blocked_phrases: [I cannot assist with that request] - type: clarification_required config: min_confidence: 0.6 clarification_prompt: 为了更准确帮您请问您具体想了解课程的哪方面例如项目实战内容、讲师背景、或就业支持即只拦截绝对违规表述对低置信度输出强制触发澄清流程。这需要你理解 guardrail 的本质——它不是让 agent 更“安全”而是让 agent 更“可控”。坑三Credential Vault 的权限粒度远比你想象的细很多人以为notion_api是一个权限其实它是分层的。Notion 的 OAuth scope 有pages:read读取页面databases:read读取数据库comments:write写评论Anthropic Vault 支持按 scope 绑定 tool。但我们曾错误地给notion_get_leads工具绑定了pages:read结果 agent 在调用时因缺少databases:read权限而失败。修复方法是在 YAML 中显式声明tools: - name: notion_get_leads ... credentials: notion: scopes: [databases:read]这要求你必须深入理解每个 tool 所依赖的底层 API 权限模型。偷懒用*通配符迟早付出代价。4.3 未来半年必须盯紧的三个信号Runtime 层的 commoditization 不是理论推演而是正在发生的产业迁移。以下是三个关键信号建议你每周检查开源 sandbox 启动延迟跌破 100msDaytona 项目在 2026 年 2 月宣布 sub-90ms 启动其核心是用 Rust 重写了 sandbox 初始化逻辑并利用 Linux cgroups v2 实现毫秒级资源分配。一旦有项目将此能力集成进 Kubernetes Operator如 K8s SIG 的 agent-sandbox 项目runtime 就彻底进入“免费时代”。云厂商将 session-hour 定价纳入免费额度AWS 已在部分区域对 Bedrock 新用户赠送 100 小时/session 免费额度。Google Vertex 宣布 Q2 将推出“Agent Builder Starter Tier”包含 500 小时/session 免费。当免费额度覆盖中小客户 80% 的用量时付费意愿将断崖式下跌。Trace Store 成为采购必审项我们服务的一家银行在 3 月的招标文件中首次将 “trace portability” 列为 agent runtime 的强制要求“供应商必须提供标准 API支持将 events 导出为 OpenTelemetry 兼容格式”。这意味着trace store 正在从“可选插件”升级为“基础设施必需品”。这三个信号指向同一个结论runtime 的价值正在加速归零而 trace、governance、vertical marketplace 的价值正在指数级上升。你现在做的每一个技术选型都应该问一句当 runtime 变成水电煤我的核心资产是什么5. 价值迁移地图当 runtime 归零钱流向哪里5.1 Trace Store从日志管道到法律证据链当 runtime 层 commoditize第一个爆发的价值洼地是 trace store。它不再只是 debug 工具而是 agent 时代的“黑匣子”和“法律证据链”。目前有三股力量在争夺这个位置Braintrust 的 Brainstore专为 AI 交互优化的 OLAP 数据库支持亚秒级查询“过去 7 天所有调用salesforce_update_contact工具且status字段为converted的会话”。其核心创新是 schema-on-read——你无需预先定义 event 结构Brainstore 会自动 infer 字段类型并建立索引。这解决了 agent 工具快速迭代带来的 schema chaos 问题。Arize 的 PhoenixApache 2.0 开源的 trace 库提供 SDK 让你在任何 runtime包括自建 LangGraph中埋点。它的商业版则聚焦“根因分析”当p95 latency突增时Phoenix 能自动关联tool_call响应时间、credential vault 延迟、sandbox CPU 使用率定位瓶颈。这是运维团队的刚需。LangSmithLangChain 生态的“默认 trace store”。它不追求性能极致而是胜在无缝集成——只要你用langchain-corelangsmith就自动记录所有 chain 调用。它的护城河是生态绑定而非技术优势。这三者的竞争焦点不是谁的 dashboard 更炫而是谁的 trace 格式能成为事实标准。因为一旦你的 agent 运行在 AWS AgentCore 上但 trace 存在 Brainstore 里你就拥有了跨 runtime 的可移植性。而 Anthropic Managed Agents 的 events API正是为这种可移植性而生——它不锁定你它邀请你离开。实操心得别等 runtime 出问题才建 trace。我们从第一天就用 Phoenix SDK 埋点即使当时只跑在本地。三个月后切换到 AgentCore只需改一行代码langsmith_client PhoenixClient()→langsmith_client AgentCoreEventsClient()。trace 数据无缝迁移debug 效率提升 5 倍。5.2 Governance Policy当 agent 能力失控规则就是护栏Runtime 归零的另一面是 governance 的价值飙升。当任何人都能用几行 YAML 启动一个连接 Salesforce 的 agent企业最怕的不是它慢而是它错。OWASP Agentic Top 10 列出的头号风险是“LLM01: Prompt Injection”但真正致命的是“LLM05: Hardcoded Credentials”和“LLM08: Insecure Tool Integration”。AWS AgentCore 在 2026 年 3 月 GA 的 Policy Controls正是对此的回应。它允许你定义数据主权策略“所有调用notion_api的会话event logs 必须存储在 us-west-2 区域”工具调用策略“salesforce_update_contact工具仅允许修改status字段禁止修改email字段”输出合规策略“所有涉及 PII 的输出必须经由pii_redactor工具脱敏”。这些策略不是代码而是 YAML 声明式规则由 AgentCore 的 policy engine 在 runtime 动态执行。它的价值在于把安全左移从开发者的责任变成平台的强制约束。这催生了一个新角色Agent Policy Engineer。他们的工作不是写代码而是写策略。比如为一家保险公司设计的策略policies: - name: healthcare_pii_protection condition: tool_name epic_emr_read actions: - mask_field: patient_name - mask_field: ssn - log_to_compliance_audit: true这个策略确保无论哪个团队用哪个框架写的 agent只要调用 Epic EMR 工具PII 就自动脱敏。这就是 governance 的终极形态用策略代替代码用声明代替实现用平台代替人治。5.3 Vertical Marketplace当 runtime 免费企业只为“解决具体问题”付费最后也是最确定的价值迁移方向是 vertical marketplace。Salesforce Agentforce 在 FY2026 Q4 达到 8 亿美元 ARR证明企业愿意为“垂直场景 agent”付费而不是为“运行 agent 的服务器”付费。这些 marketplaces 的成功公式很清晰问题足够痛销售线索分配、保险理赔审核、HR 入职流程自动化效果可量化线索转化率提升 X%理赔周期缩短 Y 天入职耗时减少 Z 小时合同可签署不是 SaaS 订阅费而是按“每处理 1000 条线索”收费的 outcome-based contract。开源社区已在孵化早期版本。比如virattt/ai-hedge-fund一个用 Python 写的量化交易 agent能自动解析 SEC 文件、计算财务比率、生成买卖信号。它不卖“AI 交易能力”而是卖“每日 10 个 alpha 信号”的订阅。TradingAgents 项目则更进一步提供 backtesting 模块让 hedge fund 可以用历史数据验证策略收益。这预示着一个新分工runtime 层由云厂商免费提供vertical agent 由专业团队构建trace/governance 由独立公司提供中间件。开发者的工作将从“搭建 infrastructure”转向“组装 business logic”。我个人在实际操作中的体会是现在开始构建 agent必须带着“可剥离”思维。你的 YAML 配置要能一键迁移到 AgentCore你的 trace 要能导出为 OpenTelemetry你的 policy 要能翻译成 Rego 语言。因为 runtime 层的战争已经结束胜者不是 Anthropic而是所有选择不把鸡蛋放在一个篮子里的人。