1. 这不是新赛道，是 runtime 层的“操作系统时刻”来了

你有没有在深夜调试一个跑了三小时的 AI 代理，突然发现它开始胡言乱语？不是模型崩了，不是 prompt 写错了，而是——它的“记忆”被挤掉了。上下文窗口就那么大，工具调用日志、中间结果、用户多轮对话、系统指令……全塞进去，像往一个20升的桶里硬灌35升水。最后溢出的不是水，是逻辑：它忘了自己上一步查了什么数据库，忘了用户明确说“别联系销售”，甚至把两个不同客户的订单号搞混。更糟的是，你没法回溯——没有日志、没有快照、没有时间线，只有最后一段残缺的输出。这种失败不炸裂，但特别贵：重跑要钱，重写要人，客户信任一跌再跌。

这就是 Anthropic 在 2026 年 4 月 8 日发布的Claude Managed Agents真正解决的问题。它不是又一个“让 AI 更聪明”的玩具，而是一套为生产环境量身打造的、可审计、可恢复、可隔离的代理运行时基础设施（Agent Runtime Infrastructure）。关键词是“运行时”——不是模型，不是工具，不是 prompt 工程，而是让所有这些组件能稳定、安全、可追踪地协同工作的底层土壤。它把过去散落在开发者代码里的状态管理、沙箱调度、凭证分发、会话持久化，全部抽出来，做成一个由 Anthropic 托管的、有明确定义接口的服务层。你可以把它理解成 AI 代理世界的“Linux 内核”：你不用自己从头写内存管理器，也不用反复造进程调度器，Anthropic 把 session 当作一个持久化的事件日志（event log），把 harness（执行器）做成无状态的函数调用，把 sandbox（沙箱）当成随时可销毁重建的“牲畜”（cattle），而不是需要精心呵护的“宠物”（pets）。这个设计背后，是过去一年里无数团队踩过的坑：Notion 用它让团队在工作区里直接委派任务给 Claude；Rakuten 用它构建销售、市场、财务三套跨 Slack 和 Teams 的代理流水线；Sentry 则把它和自己的调试代理深度耦合，让 Claude 自动写补丁、开 PR。它们要的不是“更聪明的模型”，而是“更可靠的执行”。这正是 Managed Agents 的核心价值：它把 AI 代理从一个脆弱的、上下文驱动的“临时脚本”，升级为一个有状态、有生命周期、有审计线索的“生产服务”。它解决的不是“能不能做”，而是“敢不敢在关键业务里用”。

2. 核心设计拆解：为什么是“Session-as-Event-Log”，而不是“Context-as-Storage”

2.1 旧范式的致命伤：上下文即一切，上下文即牢笼

在 Managed Agents 出现之前，绝大多数自研代理系统都遵循一个简单粗暴的范式：把所有状态都塞进 LLM 的上下文窗口里。系统提示词、用户历史、工具调用返回的 JSON、中间思考链、甚至临时变量，全靠 token 堆砌。这套方法在 demo 阶段很炫酷，但在真实场景中，它是一颗定时炸弹。我去年就亲手埋过一颗。我们搭建了一个用于多源财报分析的代理，流程是：先从 SEC EDGAR 抓取 PDF，OCR 提取文本，用 RAG 检索关键条款，再调用金融计算 API 得出风险评分，最后生成高管简报。整个流程设计了 7 个步骤，平均每个步骤产生 1200 tokens 的中间结果。问题在第 4 步爆发：当 OCR 结果和 RAG 摘要同时涌入上下文，再加上前面三步的完整记录，token 数轻松突破 Claude 3.5 Sonnet 的 200K 上限。模型没有报错，它只是“优雅地”把最老的 OCR 文本片段从上下文中抹去，然后基于一个残缺的、丢失了原始数据来源的记忆，开始编造后续的计算逻辑。我们花了整整两天才定位到问题根源——不是模型幻觉，是上下文截断导致的“记忆性失真”。更绝望的是，我们无法复现：因为那个被截断的上下文，连同它承载的所有中间状态，已经永远消失了。没有日志，没有备份，没有“时光机”。这暴露了旧范式最根本的缺陷：它把 LLM 的推理能力，和系统的状态存储能力，强行捆绑在同一个、容量有限、且不可靠的载体上。这就像让一个外科医生一边做手术，一边用脑子记住所有器械的位置、病人的实时生命体征、以及每一步操作的精确时间戳——他不是不能做，但只要注意力稍有松懈，整个系统就可能崩溃。

2.2 新范式的核心：三层解耦，各司其职

Anthropic 的 Managed Agents 用一套清晰的三层架构，彻底打破了这个捆绑。这不是营销话术，而是工程上必须做的解耦。

第一层：Session（会话）——作为持久化、可查询的事件日志
这是整个设计的基石。Session 不再是一个存在内存里的、易失的字符串，而是一个独立于模型之外的、存储在 Anthropic 后端的、结构化的事件流。每一次用户输入、每一次工具调用（包括输入参数和返回结果）、每一次模型生成的思考步骤（Thought）、每一次状态变更（State Update），都会被序列化为一个带时间戳、唯一 ID 和类型标签的事件，追加到这个日志里。这个日志是“只追加”（append-only）的，不可篡改，且默认持久化数天甚至数周。这意味着，无论你的代理运行了多久，无论模型上下文如何刷新，你都可以随时通过GET /sessions/{id}/eventsAPI 拉取完整的、按时间顺序排列的操作轨迹。它解决了“无法回溯”的问题。更重要的是，它让“状态”变成了一个可编程的对象。你可以写一个简单的 SQL 查询，找出所有在“财务分析”阶段失败的会话；你可以用一个 Python 脚本，自动提取所有调用了calculate_risk_score工具的会话，并对比它们的输入参数差异；你甚至可以训练一个小型分类器，基于事件日志的模式，预测某个会话是否会最终失败。这不再是“黑盒推理”，而是“白盒审计”。

第二层：Harness（执行器）——一个纯粹、无状态的函数调用器
Harness 是真正执行execute(name, input)这个动作的组件。它的设计哲学是极致的“无状态”（stateless）。它不保存任何关于会话的上下文，不缓存任何中间结果，它的唯一职责就是：拿到一个工具名和一个输入对象，启动一个沙箱，把输入传进去，等待输出，然后把输出原封不动地返回给上层。它像一个高效的快递员，只负责把包裹（input）送到指定地址（tool），再把收件人签收的回执（output）带回来。如果 Harness 进程意外崩溃了怎么办？答案是：完全不影响。因为所有状态都在 Session 日志里。一个新的 Harness 实例启动后，只需要调用awake(sessionId)，就能从 Session 日志的最新位置读取到上一次中断前的状态，然后无缝继续执行。这解决了“单点故障”的问题。你不需要为 Harness 设计复杂的容错机制，因为它天生就是可丢弃、可重建的。这种设计极大简化了运维复杂度，也提升了系统的整体韧性。

第三层：Sandbox（沙箱）——按需创建、隔离、销毁的“一次性容器”
这是安全与隔离的保障层。每一个工具调用，都在一个全新的、隔离的沙箱环境中执行。这个沙箱拥有独立的 CPU、内存、网络栈和文件系统。最关键的是，凭证（Credentials）的注入方式发生了根本性变革。在旧方案里，开发者习惯把 API Key、数据库密码等敏感信息，以环境变量（ENV）的形式注入沙箱，然后让代理代码去读取。这相当于把一把万能钥匙，直接塞进了执行代码的口袋里。一旦代理被诱导或被攻破，这把钥匙就立刻暴露。Managed Agents 彻底杜绝了这种做法。它采用的是“凭证代理”（Credential Proxy）模式：沙箱内部根本看不到任何明文凭证。当工具代码需要访问一个 AWS S3 存储桶时，它调用的是一个预定义的、受控的s3_read_object接口，传入的是一个安全的、有时效性的、作用域受限的临时令牌（Temporary Token），这个令牌由 Anthropic 的凭证 Vault 动态签发，并且只对本次调用有效。沙箱本身，就是一个“盲人”——它知道要做什么，但不知道凭什么是它能做。这解决了“凭证泄露”的问题，是生产环境部署的绝对红线。

这三层解耦带来的直接效果，是性能指标的跃升：p50 首 token 时间下降约 60%，p95 首 token 时间优于 90%。但这数字背后，是架构的胜利：Session 日志的异步写入，避免了阻塞主推理流；Harness 的无状态化，让它可以水平无限扩展；Sandbox 的轻量化启动，让工具调用延迟大幅降低。它不是一个“更快的模型”，而是一个“更高效、更可靠、更安全的执行引擎”。

3. 实操要点解析：从 YAML 定义到生产部署的全流程

3.1 定义你的第一个 Agent：YAML 是声明式契约

Managed Agents 的入口，不是写一堆 Python 代码，而是一份简洁的 YAML 文件。这本身就是一种范式转变：它把 Agent 的定义，从“如何实现”（imperative）提升到了“是什么”（declarative）的层面。一份典型的sales_agent.yaml可能长这样：

# sales_agent.yaml name: "Sales-Development-Agent" description: "Qualifies leads and schedules demos for enterprise prospects" system_prompt: | You are a senior sales development representative at Acme Corp. Your goal is to qualify inbound leads by asking targeted questions about their company size, use case, and budget. Only schedule a demo if the lead meets all three criteria: >100 employees, has a clear AI/ML use case, and budget >$50k/year. Use the tools provided to verify information. tools: - name: "search_company_db" description: "Search our internal CRM for company details (size, industry, last contact)" input_schema: type: "object" properties: domain: { type: "string" } output_schema: type: "object" properties: company_name: { type: "string" } employee_count: { type: "integer" } industry: { type: "string" } - name: "schedule_demo" description: "Schedule a 30-min demo with the sales team" input_schema: type: "object" properties: lead_email: { type: "string" } preferred_time: { type: "string" } # 注意：这里没有 output_schema！因为 credential proxy 会处理返回，你只关心是否成功 guardrails: - type: "content_moderation" severity: "block" - type: "pii_redaction" fields: ["email", "phone", "address"] runtime: timeout_seconds: 300 max_tool_calls: 10

这份 YAML 就是你和 Anthropic 之间的“契约”。它清晰地定义了：

• 你是谁（system_prompt）：不是一段模糊的描述，而是精确的角色设定。
• 你能做什么（tools）：每个工具都有严格的输入/输出 Schema，这强制你在设计阶段就思考接口契约，而不是等到运行时报错。
• 你不能做什么（guardrails）：内容审核和 PII（个人身份信息）脱敏是内置的，无需你额外集成第三方 SDK。
• 你的边界在哪（runtime）：超时和最大调用次数，防止一个失控的代理吃光你的预算。

提示：system_prompt的长度在这里不再是个瓶颈。因为它的作用仅限于初始化 Harness 的初始状态，真正的“记忆”由 Session 日志承担。你可以放心地写一份详尽、包含所有业务规则的提示词，而不必担心它会挤占宝贵的上下文空间。

3.2 本地开发与沙箱调试：告别“黑盒测试”

在将 Agent 部署到 Anthropic 托管环境之前，你可以在本地进行完整的端到端测试。Anthropic 提供了一个 CLI 工具claude-agent-dev，它能模拟整个托管环境：

# 1. 启动本地开发服务器 claude-agent-dev serve --config sales_agent.yaml # 2. 在另一个终端，向本地 API 发送测试请求 curl -X POST http://localhost:8000/v1/sessions \ -H "Content-Type: application/json" \ -d '{ "messages": [{"role": "user", "content": "Hi, I'm from acme.com"}] }' # 3. 查看实时日志和事件流 claude-agent-dev logs --session-id <session_id>

这个本地环境会严格遵循 YAML 中定义的tools和guardrails。当你调用search_company_db时，CLI 会启动一个 Docker 容器来模拟沙箱，并将input_schema中定义的domain字段作为环境变量传入。你甚至可以在这个容器里挂载一个本地的 SQLite 数据库，用来模拟真实的 CRM 查询。最大的好处是，所有的事件都会被记录下来，并且格式与线上环境完全一致。你可以在本地反复调试system_prompt的措辞，观察它如何影响工具调用的顺序，或者故意触发guardrails来验证内容过滤是否生效。这个过程，让你在上线前就对 Agent 的行为建立了坚实的信心。

3.3 生产部署与可观测性：从“能用”到“可信”

部署到生产环境，只需一条命令：

claude-agent deploy --config sales_agent.yaml --env production

Anthropic 会为你分配一个唯一的 Agent ID（如agent_abc123），并返回一个 HTTPS endpoint（如https://api.anthropic.com/v1/agents/agent_abc123/sessions）。你的前端应用或后端服务，就可以像调用任何 REST API 一样，向这个 endpoint 发送请求。

但真正的生产级部署，远不止于此。Managed Agents 的一大优势，是它与生俱来的可观测性（Observability）：

• 会话追踪（Session Tracing）：每一个sessionId都是一个黄金线索。你可以将它贯穿你的整个技术栈：前端埋点记录用户点击，后端日志记录 API 请求，数据库记录业务状态变更。当用户反馈“我的 demo 没被安排”，你只需拿到他的sessionId，就能在 Anthropic 的控制台里，看到从他第一句问候，到 CRM 查询，再到最终schedule_demo调用的完整、带时间戳的事件链。这比翻几十个微服务的日志要高效一万倍。

• 性能仪表盘（Performance Dashboard）：Anthropic 控制台提供开箱即用的仪表盘，显示关键指标：

  • p95 Tool Call Latency：95% 的工具调用耗时低于多少毫秒？
  • Session Success Rate：有多少会话成功走完了全流程？
  • Guardrail Trigger Rate：内容审核被触发的频率，是模型在胡说八道，还是你的system_prompt太宽松？

• 成本透明化（Cost Transparency）：账单不再是模糊的“token 总数”。它被精确拆解为：

  • $0.08 / session-hour：你的 Agent 实际在后台运行了多少小时（从创建到关闭）。
  • Claude token cost：模型推理本身的费用。 这让你能精准地计算 ROI。例如，一个销售代理平均每次会话耗时 4 分钟（0.067 小时），那么它的固定运行时成本就是$0.00536，加上 token 成本。如果它帮你转化了一个 $10,000 的订单，这笔投入就非常值得。

注意：不要试图在system_prompt里写“请记住，你是一个销售代理”。这是多余的。Harness 的无状态性决定了，它每次启动都是“清零”的。真正的“角色”和“状态”，是由 Session 日志中的事件流动态构建出来的。你的system_prompt应该专注于定义“行为准则”，而不是“身份认同”。

4. 竞争格局与生态位：为什么说“Runtime 层正在归零”

4.1 Hyperscaler 的降维打击：免费即正义

Anthropic 的 Managed Agents 绝非孤例。就在它发布前五个月，AWS Bedrock AgentCore 已经进入通用可用（GA）阶段。这并非巧合，而是一场早已打响的战争。AgentCore 的设计哲学与 Anthropic 高度相似：每个会话运行在一个独立的 microVM（微型虚拟机）中，拥有隔离的 CPU、内存和文件系统；会话最长可运行 8 小时；它完全框架无关，LangGraph、CrewAI、Strands，只要你能把它编译成 request-response 循环，它就能跑。但 AgentCore 的杀手锏，在于它的“免费”属性。它不单独收费，而是作为 AWS 云服务的一部分，其成本被摊销在你已有的 EC2、S3、Lambda 等云资源账单里。对于一个已经在 AWS 上花费数百万美元的企业来说，为 AgentCore 支付额外的$0.08/session-hour，无异于在已经支付的“水电费”之外，再为“空气”单独付费。这正是 Anthropic 所面临的残酷现实：它不是在开创一个新市场，而是在一个已经被巨头用“免费”重新定义的战场上，艰难地建立自己的护城河。

Google Vertex AI Agent Builder 和 Microsoft Azure AI Foundry 也在同一时间点完成了布局。Vertex 的强项在于其内置的 Agent Registry，它与 Google Cloud 的 Apigee API 网关深度集成，让企业可以像管理传统 API 一样，对 AI Agent 进行版本控制、流量管理、配额限制和访问审计。Azure 则选择将 AutoGen 和 Semantic Kernel 这两大开源框架，直接“焊接”进 Foundry 平台，为微软生态的开发者提供了无缝的迁移路径。这三家巨头的共同策略是：不卖“Runtime”，而是把它变成“云平台的默认能力”。它们的目标不是成为 Runtime 的供应商，而是成为 Runtime 的“土地所有者”。当 Runtime 变成像虚拟机、对象存储一样的基础设施时，“Runtime 公司”的价值就会急剧萎缩。

4.2 开源压力曲线：从 VMware 到 Kubernetes 的历史重演

Anthropic 的工程师在技术博客里，将 Managed Agents 比喻为“AI 时代的操作系统”，这个类比非常精准，但也暗含了巨大的风险。他们提到了虚拟化技术的历史，却刻意回避了那个必然的结局。让我们重温一下这段历史：

• 1999年：VMware 推出商业 x86 虚拟化产品 ESX，售价高达数万美元/主机，成为企业数据中心的标配。
• 2003年：开源项目 Xen 发布，提供了功能相近的免费替代品。
• 2007年：KVM（Kernel-based Virtual Machine）被合并进 Linux 主线内核，虚拟化从此成为操作系统的一个内置特性。
• 2020年代初：企业新部署中，开源虚拟化方案占比已达 70%。VMware 依然存在，但其增长引擎已经熄火，价值创造的重心，早已向上转移到了 Kubernetes（容器编排）、Terraform（基础设施即代码）、Prometheus（监控）等更高层的抽象。

今天 AI Runtime 层的格局，几乎就是当年虚拟化市场的翻版。开源力量正在加速集结：

• Daytona：这家曾以 DevOps 环境闻名的公司，在 2025 年初战略转向 AI Agent 基础设施，其核心产品 Daytona Sandbox 声称能在 90ms 内完成沙箱的冷启动，这对于需要高频、低延迟工具调用的场景（如实时客服）至关重要。它在 2026 年 2 月完成了 2400 万美元的 A 轮融资。
• Kubernetes SIG Agent：K8s 社区官方成立的 Special Interest Group，正在将 Agent Sandbox 作为一项核心能力纳入 K8s 生态。这意味着，未来你可能只需一个kubectl apply -f agent.yaml，就能在你的私有 K8s 集群里，一键部署一个符合 Anthropic 规范的、可审计、可伸缩的 Agent 运行时。
• Deer-flow：ByteDance 开源的长周期 Agent 框架，GitHub Star 数已突破 5.9 万。它内置了强大的子代理（Sub-agent）规划和自我反思（Self-reflection）能力，证明了开源社区在 Agent “智能”层面的创新速度，已经超越了闭源商业产品的迭代节奏。

历史不会简单重复，但押韵。当一个技术层被多个巨头免费提供，又被强大的开源社区快速跟进时，它的商品化（Commoditization）就只是一个时间问题。预计在未来 18-24 个月内，AI Agent Runtime 将像虚拟化一样，从一个高价值的“产品”，退化为一个基础的、默认的、“免费即正义”的“平台能力”。Anthropic 的 Managed Agents，此刻正站在 2005 年 VMware 的位置上：技术领先，架构优秀，但历史的车轮，已经轰隆作响。

5. 价值迁移：当 Runtime 归零，钱流向哪里？

5.1 Trace Store：谁掌握了“Agent 的 DNA”，谁就拥有了未来

当 Runtime 层变得廉价甚至免费，整个 AI 工具链的价值重心，必然向上迁移。第一个也是最重要的迁移方向，是Trace Store（追踪存储）。一个 Agent 的每一次决策、每一次工具调用、每一次失败，都沉淀为一条结构化的事件日志。这些日志，就是 Agent 的“DNA”，是它所有行为的、不可篡改的、法律意义上的证据。谁能成为这个“DNA”的权威存储和分析平台，谁就抓住了下一个十年的命脉。

目前，这个领域已经形成了三足鼎立的格局：

• Braintrust：背靠 3600 万美元 A 轮融资，其核心产品 Brainstore 是一个专为 AI 交互日志优化的 OLAP（在线分析处理）数据库。它支持亚秒级的复杂查询，比如：“找出所有在‘合同审查’环节，因legal_check工具返回risk_level: high而终止的会话，并统计它们的平均处理时长和地域分布。”
• Arize：这家已累计融资 1.31 亿美元的公司，采取了“开源先行”策略。它将核心的可观测性引擎 Phoenix 以 Apache 2.0 协议开源，迅速吸引了大量开发者。其商业版则提供企业级的 SLA、审计合规报告和与 SIEM（安全信息与事件管理）系统的深度集成。
• LangSmith：作为 LangChain 生态的“亲儿子”，LangSmith 最大的优势是“零摩擦集成”。任何使用 LangChain 构建的 Agent，只需一行代码langsmith_client = Client()，就能自动开启全链路追踪。它继承了 LangChain 庞大的用户基数，成为了事实上的“默认选项”。

实操心得：在选型时，不要只看 Dashboard 是否漂亮。关键问题是：如果你明天决定把 Agent 从 Anthropic 迁移到 AWS AgentCore，你的 Trace 数据能否无缝迁移？目前，Trace Portability（追踪可移植性）仍是行业难题。Brainstore 和 Arize 都在推动自己的 OpenTelemetry 兼容规范，而 LangSmith 则更依赖 LangChain 的生态锁定。你的选择，本质上是在赌“开放标准”和“生态绑定”哪一种路径会胜出。

5.2 Governance & Policy：当 Agent 走进董事会，合规就是生命线

随着 AI Agent 从“辅助工具”走向“业务执行者”，治理（Governance）和策略（Policy）将成为企业采购的第一道门槛。一家银行不会允许一个 Agent 自动批准一笔 1000 万美元的贷款；一家制药公司也不会允许一个 Agent 在未经审核的情况下，修改临床试验数据库。这催生了一个全新的、空白的市场：AI Agent 的策略即代码（Policy-as-Code）。

AWS AgentCore 在 2026 年 3 月 GA 的“Policy Controls”，正是这一趋势的标志性事件。它允许管理员用 YAML 定义精细的策略：

# policy.yaml - name: "Finance-Approval-Limit" condition: "tool == 'approve_payment' && input.amount > 1000000" action: "deny" reason: "Payment amount exceeds $1M. Requires manual CFO approval." - name: "PII-Redaction-Enforcement" condition: "message contains 'ssn' or 'passport_number'" action: "mask" mask_pattern: "XXX-XX-XXXX"

这些策略在 Agent 执行的每一个环节都被实时评估。这不再是事后审计，而是事前拦截。与此同时，OWASP（开放式网络应用安全项目）发布的《Agentic Top 10》安全风险清单，正在成为行业事实标准。它列出了 Agent 特有的十大风险，如“LLM 注入”、“工具权限过度授予”、“会话劫持”等。企业采购部门已经开始要求供应商提供符合 Agentic Top 10 的合规证明。这是一个典型的“防御性市场”：它不直接创造收入，但能规避巨大的法律和声誉风险。因此，它的付费意愿极强，且不受 Runtime 商品化的影响。

5.3 Vertical Agent Marketplaces：当 Agent 成为“SaaS 2.0”

最后一个，也是最具爆发力的价值迁移方向，是垂直领域 Agent 市场（Vertical Agent Marketplaces）。Salesforce 的 Agentforce 在 2026 年 Q4 达成了 8 亿美元的年度经常性收入（ARR），同比增长 169%，这绝非偶然。它揭示了一个深刻的规律：企业愿意为“解决一个具体业务问题”的 Agent 付费，而不是为“运行 Agent 的技术”付费。Agentforce 的成功，是因为它打包了“销售线索培育”、“客户成功健康度监控”、“合同续约提醒”等一系列高度垂直、开箱即用的 Agent，它们与 Salesforce 的 CRM 数据深度打通，销售 VP 可以直接在销售仪表盘里，点击一个按钮，就启动一个 Agent 去分析某个重点客户的流失风险。

这个模式正在被快速复制：

• 金融领域：virattt/ai-hedge-fund是一个开源的、面向对冲基金的 Agent 套件，它能自动抓取全球财经新闻、分析上市公司财报、计算衍生品对冲比例，并生成交易建议。TradingAgents 则专注于高频量化交易，其核心是用 Agent 自动编写和回测交易策略。
• 网络安全领域：vxcontrol/pentagi是一个渗透测试 Agent，它能自动扫描目标资产，识别漏洞，然后调用 Metasploit 或 Cobalt Strike 等工具进行利用，并生成符合 ISO 27001 标准的审计报告。

这些垂直 Agent 的共同特点是：它们不关心底层 Runtime 是 Anthropic、AWS 还是开源的 K8s。它们关心的是，能否接入特定领域的数据源（如 Bloomberg Terminal、Nessus Scanner），能否调用特定领域的工具（如 Jira、ServiceNow），以及能否用业务语言（而非技术语言）来描述其价值。当 Runtime 层归零，这些垂直 Agent 就会像雨后春笋般涌现，而连接它们与企业的，将是 Salesforce、ServiceNow、Zendesk 这样的垂直 SaaS 巨头所构建的 Marketplaces。在那里，一个“医疗理赔自动化 Agent”的价格，将由它每年能为客户节省多少人工审核成本来决定，而不是由它消耗了多少$0.08/session-hour来决定。

6. 未来已来：当 Agent 开始自我进化

在所有关于 Runtime 商品化的讨论中，有一个被严重低估的“奇点”事件，它将彻底改写游戏规则：Agent 的自我改进（Self-Improvement）。2026 年 3 月，Sakana AI 团队发布的《Darwin Gödel Machine》论文，给出了一个令人震撼的实证。他们构建了一个名为 Darwin 的 Agent，它的核心能力是：阅读自己的代码、理解自己的失败、然后自动重写代码，以提升在特定任务（SWE-bench，一个软件工程基准测试）上的表现。实验结果显示，Darwin 在没有任何人类干预的情况下，将自己的成功率从 20% 提升到了 50%。更关键的是，这个过程是可验证的：SWE-bench 官方团队独立复现了这一结果。

这个看似遥远的实验室成果，其影响是颠覆性的。它意味着，一个部署在生产环境中的 Agent，将不再是一个静态的、需要人工迭代的“程序”，而是一个持续进化的“有机体”。它会不断学习、不断优化、不断适应新的数据和新的需求。而这一切，都发生在你授权的沙箱之内。

这带来了两个根本性的变化：

• 沙箱和可观测性，从“工程最佳实践”，变成了“生存必需品”。一个能自我重写的 Agent，其行为的不可预测性呈指数级增长。你不能再仅仅依靠system_prompt来约束它。你必须确保它的每一次代码重写，都在一个完全隔离、可审计、可回滚的沙箱中进行。你必须能随时拉取它的“进化日志”，查看它为什么决定删除某段旧代码，又为什么添加了某段新逻辑。Trace Store 不再是用于调试的“锦上添花”，而是用于监管的“雪中送炭”。

• Runtime 层，从一个技术问题，上升为一个法律和伦理问题。当一个 Agent 的自我重写行为，导致了一次错误的金融交易、一次误诊的医疗建议、或一次违规的数据导出，责任在谁？是部署它的企业？是提供 Runtime 的 Anthropic？还是训练了基础模型的 Claude？这个问题的答案，将由 Trace Store 中的事件日志来决定。一份完整、不可篡改、时间戳精确到毫秒的事件链，将成为法庭上的“铁证”。因此，未来的 Trace Store，将不仅仅是技术产品，更是法律意义上的“系统记录”（System of Record），其价值将远超任何 Runtime 的许可费用。

所以，回到最初的那个问题：Anthropic 的 Managed Agents 到底意味着什么？它当然是一项优秀的产品，一个稳健的工程实现。但它的真正意义，远不止于此。它是一面镜子，映照出整个 AI 基础设施层正在发生的剧烈地震。它宣告了一个时代的结束：那个靠售卖“运行 AI 的盒子”就能获得丰厚利润的时代。它也开启了一个新时代：一个价值向上迁移、向更贴近业务、更关乎数据、更直面合规的新时代。对于从业者而言，与其纠结于“哪个 Runtime 更快”，不如立刻开始思考：我的 Trace 数据，该如何存储和分析？我的 Agent 策略，该如何定义和执行？我的业务，又该如何封装成一个能走进客户采购清单的垂直 Agent？因为，当 Runtime 归零的尘埃落定，留下的，将是那些真正理解业务、掌控数据、并敬畏规则的人。