AI Agent Runtime 重构：Session 作为事件日志的工程实践
1. 这不是新赛道，是 runtime 层的“操作系统时刻”来了
你有没有试过让一个 AI 代理连续工作四十分钟，处理一份需要反复查文档、调 API、比对数据、生成报告的复杂任务？我去年就干过这事。当时我们把所有中间状态——用户原始提问、每一轮检索结果、API 返回的 JSON、临时生成的表格草稿——全塞进模型的上下文窗口里。开始很顺，到第三十七分钟，系统突然开始胡说八道：它把前两轮查到的关键合同条款给“忘了”，却一本正经地引用一个根本不存在的条款编号，还据此生成了错误的法律意见。更糟的是，我们没法回溯——没有日志、没有快照、没有时间戳。整个 session 就像一盘没保存的棋局，啪一下，全没了。我们花了三天重写状态管理模块，把所有中间产物存到外部数据库，用唯一 session ID 串起来。做完那天，我盯着控制台里那条session_state_saved: true的日志，第一次真正理解什么叫“状态外置”。Anthropic 这次发布的 Claude Managed Agents，核心就干了这一件事：把 session 做成一个独立、持久、可查询的事件日志。它不新鲜，但它是对过去一年无数团队踩坑后最痛共识的工程实现。关键词不是“agent”，而是“managed”——这个词背后是运维成本、是故障恢复、是审计合规、是团队协作时那个“谁在什么时候改了什么”的确定性。它解决的不是“能不能跑”，而是“敢不敢让关键业务跑”。这不是给技术爱好者玩的玩具，这是给 SRE、给安全工程师、给法务、给采购经理看的基础设施公告。Notion 用它让团队在内部 workspace 里直接委派任务给 Claude，Rakuten 用它把销售线索自动分发到 Slack 和 Teams，Sentry 用它让 AI 自动写补丁、提 PR——这些都不是 demo，是真实世界里已经签单、走流程、上生产环境的用例。它们共同指向一个事实：AI 代理正在从“能对话”走向“可交付”，而交付的前提，是 runtime 层必须像操作系统一样可靠、可观察、可治理。你不需要立刻上手写 YAML，但你得明白，当你的团队开始讨论“要不要自己搭一套 LangGraph + Redis + Docker 的 agent 框架”时，Anthropic 已经把这套框架的运维负担，打包成 $0.08/小时的账单，放在你面前了。
2. 架构解剖：为什么“Session as Event Log”是这次发布真正的支点
2.1 三层解耦：Harness、Session、Sandbox 的各自归位
Anthropic 的工程博客里反复强调“decoupled agent stack”，这绝不是营销话术，而是对过去两年行业混乱的一次精准外科手术。我们来拆开看这三层到底怎么各司其职：
Harness（执行器）：它被设计成彻底无状态的“瘦客户端”。你调用
execute(name, input) → string，它只负责一件事：拉起一个容器、传入参数、等返回、吐出字符串。它不存任何东西，不记任何事，挂了就挂了。下次awake(sessionId)调用时，它会从外部存储里重新加载 session 状态，然后接着干。这就像一个只管开车、不管导航、不记路过的司机。它的价值在于轻量和可替换——今天用 Claude Sonnet，明天换成 Opus，只要接口不变，Harness 层完全不用动。Session（会话）：这才是真正的“大脑”。它不再是一个漂浮在内存里的 JSON 对象，而是一个结构化的、带时间戳的、可持久化到磁盘的事件流（event log）。每一次工具调用、每一次模型推理、每一次用户输入、每一次错误发生，都被记录为一条原子事件。你可以像查数据库一样，用
SELECT * FROM session_events WHERE session_id = 'xxx' AND event_type = 'tool_call' ORDER BY timestamp来回溯整个决策链。更重要的是，这个 log 是 durable 的——它活在 Anthropic 的托管存储里，哪怕 Harness 容器重启十次，log 依然完整。这解决了我们去年那个四十分钟崩溃案的根本问题：状态不再是易失的上下文，而是坚不可摧的记录。Sandbox（沙箱）：它被明确定义为“cattle, not pets”（牛，而非宠物）。每次工具调用，都动态创建一个全新的、隔离的微虚拟机（microVM），执行完立刻销毁。凭证（API keys、DB passwords）不是通过环境变量注入——那是把钥匙挂在门把手上——而是由 Anthropic 的密钥管理服务（Vault）在沙箱启动时，以只读方式挂载进指定路径，且沙箱进程无法访问 Vault 的网络端点。这意味着，即使模型 prompt engineering 出了致命漏洞，让 agent “误以为”自己需要 curl 一个危险 endpoint，它也拿不到那个 curl 命令里本不该出现的 token。这种设计，是血泪教训换来的：我们曾因一个未过滤的
os.environ注入，在测试环境里意外泄露了 staging 数据库密码。
提示：这三层解耦的终极价值，不是性能，而是“可治理性”。当你需要向审计部门证明“这个 agent 在 3 月 15 日下午 2 点调用了哪个 API，传了什么参数，返回了什么数据”，答案不在某个工程师的本地日志里，而在 Anthropic 提供的、带数字签名的事件日志中。这就是企业级落地的门槛。
2.2 为什么“Session as Event Log”比“Context Window as State”先进一个时代
把状态塞进 context window，本质上是一种“寄生式”架构。它把计算层（模型）和存储层（状态）强行绑在一起，带来了三个无法回避的硬伤：
容量天花板即失败点：Claude 3.5 Sonnet 的上下文是 200K tokens，听起来很大。但实际场景中，一个包含多张表格、数份 PDF 文本摘要、数次 API 返回的 JSON 的 session，轻松就能吃掉 150K。剩下的 50K，要留给 system prompt、当前指令、以及模型生成回复的空间。一旦超限，模型不会报错，它会“优雅降级”——自动丢弃最早的部分。这个过程对开发者完全黑盒。你看到的只是输出越来越离谱，却找不到原因。我们那个四十分钟的案例，就是典型的“静默坍塌”。
调试与可观测性为零：你想知道 agent 为什么在第 7 步开始胡说？你得把整个 200K tokens 的 context dump 下来，手动翻找。没有时间戳，没有事件类型标记，没有调用栈。它就像一锅煮糊的粥，所有信息都混在一起，无法分离。
协作与复用成本爆炸：如果 A 同学写的 agent 需要 B 同学写的工具，B 同学就得把工具的完整描述、输入输出 schema、错误码列表，全部塞进自己的 system prompt 里。A 同学想升级工具版本？B 同学的 prompt 得跟着改。这根本不是工程协作，这是人肉 API 同步。
而 Session as Event Log 彻底重构了这个范式。它引入了清晰的“契约”：
- 工具契约：每个工具只需定义
name,description,input_schema。Harness 只认这个 schema，不关心工具内部怎么实现。 - 事件契约：每次调用，无论成功失败，都产生一条标准格式的事件：
{ "event_id": "...", "session_id": "...", "timestamp": "...", "type": "tool_call_start", "tool_name": "search_docs", "input": { ... } }。 - 状态契约：Session 存储只提供
get_state(session_id)和append_event(event)两个原子操作。Harness 不需要知道 state 存在哪，怎么存。
这种契约化，让“组合”变成了乐高积木式的拼接。Notion 可以把他们的create_notion_page工具注册进 Anthropic 的 registry，Rakuten 的销售 agent 就能直接调用，无需任何代码修改。这正是操作系统虚拟化硬件后带来的生态效应：应用开发者不再需要为每台服务器写不同的驱动，他们只写一次，就能跑在 VMware、KVM、AWS Nitro 上。
3. 实操指南：从零部署一个生产级 Claude Agent（含避坑清单）
3.1 第一步：定义你的 Agent（YAML vs Natural Language）
Anthropic 允许你用两种方式定义 agent：严格的 YAML 或宽松的自然语言。别被“自然语言”迷惑，它只适合快速原型，生产环境请务必用 YAML。原因很简单：自然语言解析有歧义，而 YAML 是机器可验证的契约。
一个典型的sales_agent.yaml长这样：
# sales_agent.yaml name: "Sales Development Representative" description: "Qualifies inbound leads and schedules demos for enterprise sales team." system_prompt: | You are a senior SDR at Acme Corp. Your goal is to qualify leads by asking up to 3 targeted questions about their company size, use case, and timeline. If qualified (company > 100 employees, clear use case, timeline < 6 months), schedule a demo with the sales team. Never ask more than 3 questions. tools: - name: "search_company_db" description: "Search our internal CRM for company details by domain name." input_schema: type: "object" properties: domain: type: "string" description: "The company's website domain, e.g., 'acme.com'" required: ["domain"] - name: "schedule_demo" description: "Schedule a 30-min demo slot with the sales team calendar." input_schema: type: "object" properties: lead_name: type: "string" lead_email: type: "string" preferred_time: type: "string" description: "ISO 8601 datetime, e.g., '2026-04-15T14:00:00Z'" required: ["lead_name", "lead_email", "preferred_time"] guardrails: - type: "content_policy" policy: "block" rules: - "Do not discuss pricing or discounts." - "Do not make promises about product features not yet released." - type: "tool_call_policy" policy: "allowlist" allowed_tools: ["search_company_db", "schedule_demo"]注意：
input_schema必须严格遵循 JSON Schema v7。我见过太多团队因为type: "string"写成type: "str"，导致工具调用永远失败，排查了两天才发现是 YAML 格式错误。建议用 VS Code 安装YAML插件，它能实时校验 schema。
3.2 第二步：部署与配置（CLI 与 Console 的双轨制）
Anthropic 提供了claude-cli工具，这是最高效的部署方式。安装后，一行命令即可上线：
# 登录（使用 Anthropic 提供的 API Key） claude login --api-key sk-ant-api03-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx # 部署 agent（假设 yaml 文件在当前目录） claude agents deploy --file sales_agent.yaml --name "sales-sdr-prod" --environment "production" # 输出类似： # ✅ Agent 'sales-sdr-prod' deployed successfully. # 📌 Session ID prefix: sess_prod_sdr_ # 💰 Estimated cost: $0.08/hour active runtime + Claude token fees实操心得：不要跳过--environment参数！它会在后台为你创建独立的资源命名空间和权限策略。我们最初为了省事没加，结果测试 agent 和生产 agent 共享同一个 sandbox pool，导致测试流量偶尔触发了生产告警。后来强制要求所有部署都带--environment，并用prod,staging,dev严格区分。
如果你偏好图形界面，Anthropic Console 的 Agent Management 页面也很直观。但要注意一个隐藏细节：Console 里创建的 agent 默认是public，意味着任何拥有你账户read权限的人都能看到它的定义。而 CLI 部署的 agent 默认是private。对于包含敏感工具描述（比如delete_customer_data）的 agent，务必用 CLI 部署，或在 Console 里手动将 visibility 改为 private。
3.3 第三步：集成到你的应用（REST API 与 Webhook）
Managed Agents 提供了标准的 REST API。核心是两个 endpoint：
POST /v1/agents/{agent_id}/sessions：创建新 session，返回session_id。POST /v1/sessions/{session_id}/messages：向 session 发送用户消息，触发 agent 执行。
一个完整的 Python 集成示例（使用requests）：
import requests import json # 1. 创建 session response = requests.post( "https://api.anthropic.com/v1/agents/agent_abc123/sessions", headers={"x-api-key": "sk-ant-api03-...", "anthropic-version": "2023-06-01"}, json={"metadata": {"source": "web_app", "user_id": "u_789"}} ) session_id = response.json()["id"] # e.g., "sess_prod_sdr_456" # 2. 发送用户消息 user_message = { "role": "user", "content": [{"type": "text", "text": "Hi, I'm from Acme Corp. We're looking for a CRM solution."}] } response = requests.post( f"https://api.anthropic.com/v1/sessions/{session_id}/messages", headers={"x-api-key": "sk-ant-api03-...", "anthropic-version": "2023-06-01"}, json={"messages": [user_message]} ) # 3. 处理响应（可能是 tool_use, content_block_delta, 或 final answer） result = response.json() if result.get("stop_reason") == "tool_use": # agent wants to call a tool, handle it tool_use = result["content"][0] if tool_use["name"] == "search_company_db": # 调用你自己的公司数据库 API db_result = call_your_crm_api(tool_use["input"]["domain"]) # 把结果送回 agent requests.post( f"https://api.anthropic.com/v1/sessions/{session_id}/messages", json={"messages": [{"role": "assistant", "content": [{"type": "tool_result", "tool_use_id": tool_use["id"], "content": json.dumps(db_result)}]}]} )关键避坑点：
tool_result的tool_use_id必须和 agent 返回的tool_use中的id完全一致，包括大小写和下划线。我们曾因前端 JS 代码里.toLowerCase()了这个 id，导致 agent 一直卡在“等待工具结果”状态，日志里全是tool_use_id not found。解决方案是：永远原样透传，不做任何字符串处理。
3.4 第四步：监控与调试（Event Log 的实战价值）
部署后，别急着庆祝。打开 Anthropic Console 的Sessions标签页，你会看到一个按时间排序的 session 列表。点击任意一个，进入详情页。这里就是你的“数字取证室”。
- Timeline View（时间线视图）：这是最强大的功能。它把 session 的整个生命周期，按毫秒级时间戳展开：
00:00:00.000: User message received00:00:00.123: Model started thinking (p50 TTFB: 123ms)00:00:00.456: Tool callsearch_company_dbinitiated00:00:01.789: Sandboxsbx_abcprovisioned00:00:02.345: Tool call completed, returned{ "employees": 250, "industry": "SaaS" }00:00:03.012: Model generated next question: "What's your primary use case for a CRM?"
这个时间线，让你一眼就能定位瓶颈。如果Sandbox provisioned到Tool call completed耗时超过 2 秒，说明你的工具 API 响应慢；如果Model started thinking到Tool call initiated耗时过长，说明 system prompt 或当前上下文太复杂，模型在“思考”如何调用工具。
- Raw Events（原始事件）：点击右上角
View Raw Events，你会看到一个 JSON 数组，每一条都是一个标准事件。你可以复制这段 JSON，粘贴到你的内部日志分析平台（如 Datadog、Elasticsearch），用 KQL 查询：“找出所有tool_call_failed事件，并关联其前 3 个user_message事件”。这比在一堆杂乱的console.log里大海捞针高效一万倍。
实操心得：我们给所有生产 session 的
metadata字段，都加上了{"team": "sales", "channel": "slack"}。这样在 Console 里，可以用team:sales这样的 filter 快速筛选，避免被其他团队的 session 干扰。这是小技巧，但每天能节省工程师 15 分钟。
4. 竞争格局与生存法则：为什么 Runtime 层注定“归零”
4.1 Hyperscaler 的碾压式入场：不是竞争，是“吸收”
Anthropic 的发布会通稿里，把 Managed Agents 描绘成一个开创性的新类别。但现实是，就在五个月前，AWS Bedrock AgentCore 已经进入通用可用（GA）阶段。截至 2026 年 3 月，它的 SDK 下载量已突破两百万次。这不是一个“友商产品”，这是你云账单里已经存在的、免费的基础设施。
AgentCore 的架构，和 Anthropic 如出一辙：session 作为事件日志、harness 无状态、sandbox 按需创建。但它有一个 Anthropic 永远无法复制的优势：深度绑定。当你在 AWS 控制台里创建一个 AgentCore agent 时，它默认使用你账户里已有的 IAM 角色来调用工具。你的search_company_db工具，就是一个普通的 Lambda 函数，它的权限策略（IAM Policy）已经写好了。AgentCore 的 sandbox，直接运行在你的 VPC 里，可以无缝访问你的 RDS、ElastiCache、甚至你的私有 Kubernetes 集群。这一切，都不需要额外配置，因为它们本就是你云环境的一部分。
这就像当年 VMware 卖 ESX 的时候，AWS 说：“我们不卖 hypervisor，我们卖的是 EC2。你买一台 t3.micro，里面已经装好了 KVM，还配好了网络、存储、监控，价格是 $0.0104/hour。” Anthropic 的 $0.08/hour，对标的是 EC2 的t3.micro，而不是 VMware 的 $15,000/年。这不是价格战，这是商业模式的降维打击——AWS 不是在卖一个更好的 runtime，它是在把你整个云基础设施，包装成一个 runtime。
Google Vertex AI Agent Builder 和 Microsoft Azure AI Foundry 也在做同样的事。Vertex 的优势在于 BigQuery 和 Vertex Matching Engine 的原生集成；Azure 的优势在于与 Microsoft Graph 和 Power Automate 的深度打通。它们都在把“runtime”变成一个“默认选项”，而不是一个“需要评估的采购项”。
提示：如果你的公司已经在用 AWS，现在就去控制台，花 5 分钟创建一个 AgentCore agent。你会发现，它比 Anthropic 的 CLI 部署更快、更顺滑。这不是 Anthropic 不好，而是 AWS 的“默认集成”优势，是任何独立厂商都无法撼动的护城河。
4.2 开源压力曲线：Daytona、K8s SIG、Deer-flow 的合围
如果说 hyperscaler 是“吸收”，那么开源社区就是“瓦解”。2025 年初，Daytona 从一个 DevOps 工具转型为 AI agent 基础设施，其核心卖点是sub-90ms sandbox spin-up。这意味着，它能在不到 0.1 秒内，从零创建一个隔离的、预装了 Python 和常用工具的容器。这个速度，已经逼近了函数计算（Function-as-a-Service）的冷启动水平。它不卖 SaaS，它卖一个 Helm Chart，你helm install daytona，就能在自己的 Kubernetes 集群里，拥有一套和 Anthropic 几乎同构的 agent runtime。
更可怕的是 Kubernetes SIG（特别兴趣小组）的动作。他们在 2026 年 3 月，正式发布了kubernetes-sigs/agent-sandbox项目。这是一个官方支持的、符合 OCI（Open Container Initiative）标准的 sandbox 运行时。它不是一个完整的 agent 框架，而是一个“标准化的沙箱引擎”。任何 agent 框架（LangGraph、CrewAI、甚至 Anthropic 的 Harness）都可以对接它。这就像 Linux 内核提供了fork()和exec()系统调用，所有编程语言的 runtime 都基于此构建进程模型。K8s SIG 正在为 agent 世界，定义那个最底层的fork()。
ByteDance 的deer-flow项目，则代表了另一个方向：长周期、强规划的 agent。它内置了 sub-agent（子代理）机制，允许一个主 agent 把“研究竞品”、“撰写 PPT”、“准备演讲稿”拆分成三个独立的子任务，分别交给三个 specialized agent 去执行。它的 GitHub Stars 已破 59,000，这意味着，已经有近六万开发者，在用它构建自己的 agent 应用。而 deer-flow 的核心，恰恰是那个可插拔的、标准化的 harness 接口。
这三股力量——Daytona 提供极致性能的沙箱、K8s SIG 提供标准化的沙箱引擎、deer-flow 提供高级的 agent 编排能力——正在共同编织一张网，把“runtime”这个概念，从一个封闭的、商业化的、需要付费的产品，变成一个开放的、标准化的、可以自由组合的基础设施层。这正是 VMware 当年面对 Xen 和 KVM 时的处境。
4.3 价值迁移的三大高地：Trace Store、Governance、Vertical Marketplace
当 runtime 层不可避免地走向 commoditization（商品化），钱会流向哪里？答案不是“更快的 sandbox”，而是“sandbox 之上的三座高地”。
第一座高地：Trace Store（追踪存储）
当所有 agent 都在用差不多的 runtime，你凭什么收费？答案是：你拥有那个不可替代的、关于“agent 到底做了什么”的真相。Braintrust 的 Brainstore，是一个专为 AI 交互日志设计的 OLAP 数据库。它能让你在毫秒级内，回答这样的问题：“过去 24 小时，所有调用schedule_demo工具的 sessions 中，有多少比例的preferred_time是在工作时间（9am-5pm）之外？” 这种洞察，对销售运营团队的价值，远超 runtime 本身。
Arize 的 Phoenix 项目，选择了一条更聪明的路：它把核心的 trace ingestion 和 query engine 以 Apache 2.0 许可证开源。这意味着，任何公司都可以免费部署一个 Phoenix，获得基础的可观测性。而 Arize 的商业产品，则建立在这个开源基座之上，提供企业级的 SSO、RBAC、SLA 保证和定制化报表。这是一种“开源捕获，商业变现”的经典模式，它确保了 Phoenix 成为事实上的 trace 标准。
LangSmith 的优势在于生态绑定。它随 LangChain 一起安装，几乎成了 LangChain 用户的默认选择。它的价值不在于技术有多领先，而在于“你已经装了它”。当你的团队有 50 个 LangGraph agent 都在往 LangSmith 里打日志时，切换到另一个 trace store 的迁移成本，就高到无法承受。
实操心得：我们做过一个实验，把同一个 agent 的日志，同时发给 LangSmith 和自建的 Elasticsearch。三个月后，团队 90% 的 debug 工作，都发生在 LangSmith 的 UI 里。不是因为 LangSmith 更好，而是因为它的 UI 专门为 agent 日志设计：时间线视图、工具调用高亮、一键重放 session。而我们的 ES Kibana 仪表板，需要工程师自己写复杂的 KQL 查询。这就是“默认选择”的力量。
第二座高地：Governance & Policy（治理与策略）
AWS AgentCore 在 2026 年 3 月 GA 的政策控制（Policy Controls），标志着一个拐点。它允许你在 agent 级别设置规则：“禁止调用任何delete_*命名的工具”、“禁止在finance环境中调用send_email工具”、“所有search_*工具的返回结果，必须经过pii_redactor工具脱敏”。这些规则，不是写在 agent 的 YAML 里，而是写在 AWS IAM Policy 里，由 AgentCore 的 control plane 强制执行。
OWASP Agentic Top 10 的发布，则为企业采购提供了标准话术。当 CISO 问“你们的 agent 怎么防止 prompt injection？”，销售不能再回答“我们用了最好的 model”，而必须拿出一份文档，说明“我们集成了 OWASP Top 10 的第 3 条（Insecure Output Handling），并通过 Policy Controls 实现了自动拦截”。
这个领域目前是一片蓝海。没有巨头垄断，没有事实标准。谁能第一个提供一套既满足 OWASP 要求，又能无缝集成到 AWS/GCP/Azure 策略引擎里的商业产品，谁就能吃下未来三年的企业级 agent 治理市场。
第三座高地：Vertical Agent Marketplace（垂直领域 Agent 商店）
Salesforce 的 Agentforce ARR 达到 8 亿美元，这个数字不是靠卖 runtime 卖出来的。它是靠卖“销售开发代理”、“客户服务代理”、“财务报销代理”这些具体、可感知、能放进采购预算的垂直解决方案卖出来的。它的客户不是工程师，而是销售 VP、客服总监、CFO。
这个模式的成功，源于一个简单事实：企业愿意为“解决一个明确的业务问题”付费，而不是为“拥有一套先进的 AI 基础设施”付费。当 runtime 变得免费且无处不在时，“agent”本身就成了可交易的商品。
开源社区已经嗅到了这个味道。virattt/ai-hedge-fund项目，提供了一个开箱即用的量化交易 agent，它能连接 Yahoo Finance、执行回测、生成交易信号。vxcontrol/pentagi项目，则是一个红队渗透测试 agent，它能自动扫描目标、识别漏洞、生成 exploit PoC。这些项目，不是玩具，它们是垂直市场的种子。
最后分享一个小技巧：如果你想评估一个 agent-infra 初创公司的长期价值，不要问“你们的 sandbox 启动速度是多少？”。去问他们：“你们的 trace store，是否支持跨 runtime 迁移？如果我的客户今天用你们的 trace store，明天把 agent 迁移到 AWS AgentCore，日志还能无缝接入吗？” 如果答案是“不能”，那它大概率只是一个过渡期的工具。如果答案是“能，并且我们提供 migration toolkit”，那它才真正抓住了 commodity layer 之上的价值。
5. 终极拷问：你的技术选型，是在买“hypervisor”，还是在建“应用平台”？
我最后一次部署一个纯 runtime 的 agent 框架，是在 2025 年 6 月。我们花了三周时间，用 LangGraph 搭建了 workflow，用 Redis 做了 session state，用 Docker Compose 管理了 sandbox，最后用 Prometheus 监控了 TTFB。上线后，它稳定运行了两个月。然后，AWS AgentCore GA 了。我们开了个会，会议纪要只有两行：“1. 评估迁移成本。2. 结论：零成本，因为 AgentCore 的 LangGraph adapter 是官方维护的，一行代码都不用改。” 我们删掉了那三周写的全部代码，把docker-compose.yml换成了aws cloudformation create-stack，然后把省下的工程师时间，全部投进了打磨我们的sales-sdragent 的业务逻辑里——优化提问话术、增加行业知识库、对接更多 CRM 字段。
这就是 runtime commoditization 的真实面貌：它不是一场你死我活的战争，而是一次集体性的“卸载”。我们卸载了那些本不该由业务团队操心的、关于沙箱、关于状态、关于监控的底层细节，把宝贵的精力，重新聚焦在“如何让 agent 更好地完成销售任务”这个核心命题上。
Anthropic 的 Managed Agents，是一个优秀的、及时的、工程上无可挑剔的产品。它证明了“session as event log”是正确的架构方向。但它发布的时机，注定了它不是开山者，而是守门人。它在守护的，不是 runtime 这个即将消失的层，而是 Claude 这个模型的 token 生态。它的定价策略（$0.08/hour）非常精妙：对小团队，它足够便宜，值得尝试；对大客户，它又贵得恰到好处，让你认真考虑“是不是该把 agent 迁到 AWS 上，顺便把 compute、storage、networking 全部打包进一张账单”。
所以，回到最开始的问题：你现在该做什么？我的建议是，立刻动手，用 Anthropic 的 CLI 部署一个最简单的 agent。不是为了长期使用它，而是为了亲身体验那个“session as event log”的范式。感受一下 Timeline View 的威力，试试 Raw Events 的 JSON 结构，把它集成到你的 Slack bot 里。然后，花一天时间，去 AWS 控制台，用同样的 YAML，部署一个 AgentCore agent。对比两者的体验差异。最后，打开 GitHub，搜索daytona agent和kubernetes-sigs/agent-sandbox，看看它们的 README 和 issue list。
这个过程，不是为了选一个 winner，而是为了确认一件事：你正在构建的，是一个可以轻松迁移到任何 runtime 的、真正有价值的 agent。而那个 agent 的价值，永远不在于它跑在哪家的 sandbox 里，而在于它能帮你签下多少单、节省多少工时、规避多少风险。Runtime 层归零，不是终点，而是起点——一个让我们终于可以把全部注意力，放回“AI 能为业务做什么”这个本质问题上的，干净的起点。