1. 这不是新赛道是 runtime 层的“操作系统时刻”来了你有没有试过让一个 AI 代理连续工作四十分钟不是闲聊而是真正在查资料、调 API、写代码、汇总报告——一个接一个步骤往下走。我去年就搭过这么一套系统用的是当时最主流的开源框架所有状态都塞在模型的上下文窗口里。前半小时一切顺利到第三十二分钟上下文开始溢出。模型没报错没崩溃甚至没提示它只是悄悄把最早调用的三个工具结果给“忘了”然后基于一个残缺的、自己脑补出来的历史继续推理。最后生成的是一份逻辑自洽但事实全错的报告。更糟的是我们根本没法回溯——没有日志、没有快照、没有事件流只有最终那个错误输出。整个 session 就像被橡皮擦抹掉了一样无声无息地消失了。Anthropic 在 4 月 8 日发布的 Claude Managed Agents表面看是又一个“AI 代理托管服务”但它的核心价值恰恰就卡在这个痛点上它把“session”从模型的上下文里彻底解放出来变成一个独立、持久、可查询、可回放的事件日志。这不是功能叠加而是架构范式的切换。它意味着你不再需要为“上下文能装多少东西”而绞尽脑汁设计记忆压缩策略也不用在每次调用前手动拼接冗长的历史摘要。状态管理这件事被 Anthropic 抽出来做成了一层稳定、可靠、与模型解耦的基础设施。关键词里反复出现的 “Towards AI - Medium”其实已经暗示了这场讨论的语境——它不是面向普通用户的新闻稿而是写给一线工程师、技术决策者和 AI 基础设施创业者的深度剖析。这篇文章要解决的不是“Managed Agents 怎么用”而是“为什么现在必须关注 runtime 层的演进”以及“当这一层开始 commoditize商品化时真正的价值会流向哪里”。它适合那些正在评估是否要自建 agent 框架、是否要采购第三方 sandbox 服务、或者正为公司 AI 战略寻找下一个投资方向的技术负责人。如果你还在纠结“该选 LangGraph 还是 CrewAI”那这篇文章可能来得稍晚但如果你已经开始思考“我们花在运维 agent harness 上的工程师时间是不是正在变成沉没成本”那它就是为你写的。这个变化的底层驱动力和三十年前操作系统虚拟化硬件如出一辙。当年程序员不用再为每台 IBM 主机或 DEC 小型机写不同的驱动因为 DOS 和后来的 Unix 提供了统一的文件描述符和内存抽象。今天开发者也不该再为每个云厂商的沙箱环境、每种模型的 token 处理逻辑、每套工具的认证方式去重写调度器。Managed Agents 所做的就是定义一套清晰的接口execute(name, input) → string。你只管告诉它“去调 Notion 的 create_page 接口传入这些参数”剩下的——环境隔离、凭据注入、执行超时、结果捕获、错误重试——全部由 Anthropic 的 harness 负责。这层抽象一旦稳定上层的应用逻辑就能真正实现“一次编写随处运行”。这才是它被称为“layer that’s already going to zero”的真正含义它本身的价值正在被快速摊薄但正是因为它变得足够便宜、足够标准、足够可靠才让上层的创新得以爆发。2. 核心设计拆解为什么是“Session-as-Event-Log”而不是“Context-as-Storage”2.1 架构分层从混沌耦合到清晰解耦在 Managed Agents 出现之前绝大多数自研或开源的 agent 系统其架构本质上是“单体式”的。模型、状态、工具调用、安全策略全都挤在同一个进程空间里共享同一块内存和上下文窗口。这种设计在原型阶段非常高效但在生产环境中却处处是坑。我见过太多团队在项目上线三个月后不得不推倒重来原因几乎都一样状态膨胀、安全漏洞、调试困难、扩展性差。Anthropic 的方案将整个系统明确切分为三个独立的、有明确定义边界的层Session 层状态层这是一个完全独立于模型运行时的、持久化的事件日志数据库。每一次用户输入、每一次工具调用、每一次模型输出、每一次错误发生都会被序列化为一条结构化的事件记录event并打上时间戳、session ID、trace ID。它不关心模型是什么只负责忠实地记录“发生了什么”。这个设计直接解决了我前面提到的那个“四十分钟静默失败”的问题。当 session 崩溃时你不需要祈祷模型能记住一切你只需要拿着sessionId去查询事件日志就能完整还原出崩溃前的每一步操作精准定位是哪个工具返回了异常数据还是哪次模型推理产生了歧义。Harness 层执行层这是一个纯粹的、无状态的“执行引擎”。它唯一的职责就是接收一个标准化的指令例如execute(notion_create_page, {title: Q2 Report, content: ...})然后去调度、执行、捕获结果并将结果连同元数据一起发回给 Session 层记录。它本身不保存任何业务状态因此可以随时被杀死、重启、水平扩展而不会丢失任何关键信息。awake(sessionId)这个 API 的存在就是这种设计理念的完美体现——它不是在恢复一个“活的进程”而是在根据事件日志重建一个全新的、干净的执行上下文。这就像你关掉一台电脑再开机系统会从硬盘读取上次的状态而不是试图让内存里的数据“复活”。Sandbox 层隔离层这是安全性的基石。Managed Agents 的沙箱不是简单的 Docker 容器而是遵循“cattle, not pets”牛而非宠物原则的、按需创建、用完即焚的轻量级隔离环境。最关键的一点在于凭据credentials的处理方式它们被预置在沙箱的底层但绝不会以环境变量ENV的形式暴露给 agent 代码。这意味着即使 agent 的提示词被恶意诱导或者代码中存在os.getenv(API_KEY)这样的硬编码它也永远无法读取到真实的密钥。密钥只在沙箱内核层面用于发起网络请求agent 只能看到请求的结果。这种设计是无数血泪教训换来的——我亲眼见过一个客户因为一个未过滤的curl命令把 AWS 的临时凭证直接打印在了日志里导致整个 S3 存储桶被扫荡一空。Anthropic 的方案从架构上就杜绝了这种可能性。这三层之间通过明确定义的、稳定的接口进行通信。Session 层提供get_events()和append_event()Harness 层提供execute()Sandbox 层提供run_in_sandbox()。这种解耦带来的好处是革命性的你可以单独升级 Harness 的执行引擎而不影响 Session 的存储格式你可以用新的、更安全的沙箱技术替换旧的而无需改动 Harness 的任何一行代码你甚至可以为同一个 Session同时启动多个 Harness 实例进行 A/B 测试不同模型版本的效果。这正是操作系统虚拟化硬件所追求的终极目标让上层应用不必关心底层硬件的差异。2.2 为什么“Session-as-Event-Log”是不可替代的核心很多人初看这个设计会觉得“不就是加了个数据库存日志吗我们自己也能做”。这种想法忽略了两个关键维度一致性和原子性。首先一致性。在一个高并发、多步骤的 agent 工作流中“状态”不是一个静态值而是一个动态的、不断演化的事实集合。比如一个销售 agent 正在为一个客户生成报价单第一步它从 CRM 获取客户信息第二步它从 ERP 查询库存和价格第三步它调用财务系统计算税费。这三个步骤的执行顺序、成功与否共同构成了当前的“状态”。如果这三个步骤的日志是分别、异步写入的那么在某个瞬间你可能会看到“已获取客户信息”和“已计算税费”但“库存查询”这条日志却还没写入——这就是一个不一致的状态快照。Managed Agents 的 Session 层保证了所有与一次execute调用相关的事件包括输入、输出、错误、耗时等作为一个原子单元atomic unit被写入。要么全部成功要么全部失败绝不会出现中间态。这使得“回放”replay成为可能因为回放的本质就是严格按照事件日志的时间顺序重新触发每一个execute调用。其次原子性。这直接关系到故障恢复的可靠性。假设在执行execute(slack_post_message)时网络抖动导致超时。传统的做法是让 Harness 自己重试但这会带来不确定性如果 Slack 其实已经收到了消息只是响应没回来那么重试就会造成重复发送。Managed Agents 的设计是Harness 在发起调用前先向 Session 层写入一条EXECUTE_STARTED事件调用完成后无论成功失败再写入一条EXECUTE_COMPLETED或EXECUTE_FAILED事件。这样当 Harness 崩溃重启后它可以通过查询 Session发现有一个EXECUTE_STARTED但没有对应的COMPLETED事件从而知道这个调用处于“悬而未决”状态它可以安全地发起一次幂等查询idempotent query确认该操作是否真的完成了而不是盲目重试。这种基于事件日志的、确定性的故障恢复机制是任何靠“上下文记忆”或“本地内存缓存”都无法比拟的。提示不要试图用 Redis 或 MySQL 来简单模拟这个 Session 层。你需要的不是一个通用数据库而是一个专为高吞吐、低延迟、强一致性的事件流场景优化的 OLAP 数据库。Braintrust 的 Brainstore、Arize 的 Phoenix都是为此类场景而生。它们支持毫秒级的事件写入、亚秒级的复杂查询例如“找出所有在调用github_create_pr后 5 秒内又调用了jira_update_issue的 session”以及对 PB 级日志数据的高效压缩和索引。自己造轮子的成本远高于直接采用这些专业方案。3. 实操要点与核心环节实现从 YAML 定义到生产部署3.1 Agent 定义YAML 是声明式编程的胜利Managed Agents 最令人耳目一新的地方是它将 agent 的定义从一段复杂的、充满副作用的 Python 代码简化为一份清晰、简洁、可版本控制的 YAML 文件。这不仅仅是语法糖而是工程范式的升级。下面是一个为 Notion 工作区构建的“会议纪要生成 agent”的 YAML 示例# notion-meeting-agent.yaml name: Notion Meeting Summarizer description: An agent that listens to meeting transcripts and creates structured notes in Notion. system_prompt: | You are a meticulous meeting assistant. Your job is to: 1. Extract key decisions, action items (with owners and deadlines), and open questions. 2. Format the output strictly as a JSON object with keys: decisions, action_items, open_questions. 3. Never invent information. If the transcript is unclear, leave a field empty. tools: - name: transcript_to_text description: Converts an audio file URL into plain text using Whisper. input_schema: type: object properties: url: type: string description: The public URL of the audio file (e.g., from Zoom cloud recording). - name: notion_create_page description: Creates a new page in a specified Notion database. input_schema: type: object properties: database_id: type: string description: The ID of the target Notion database. title: type: string description: The title for the new page. content: type: string description: The full content of the meeting notes, in Markdown format. guardrails: - type: output_filter config: allowed_keys: [decisions, action_items, open_questions] max_length: 10000 - type: tool_call_filter config: allowed_tools: [transcript_to_text, notion_create_page]这份 YAML 文件定义了 agent 的全部“契约”contract。它告诉 Anthropic 的 runtime你是谁system_prompt一个严格的、不编造信息的会议助手。你能做什么tools只能调用两个工具且每个工具的输入格式都有精确的 JSON Schema 描述。这比任何自然语言提示都更可靠因为它直接约束了模型的输出结构。你不能做什么guardrails输出只能包含指定的三个字段且总长度不能超过一万字符调用工具时只能选择列表中的两个。这种声明式declarative的定义方式带来了巨大的工程优势。首先它实现了关注点分离产品经理可以和工程师一起审阅这份 YAML确认业务逻辑是否正确而无需理解背后的 Python 代码。其次它实现了可测试性你可以针对这份 YAML编写单元测试模拟各种输入验证其输出是否符合output_filter的要求。最后它实现了可审计性这份 YAML 就是 agent 的“源代码”它会被纳入公司的 Git 仓库接受完整的 CI/CD 流程每一次变更都有清晰的提交记录和审批流程。这在金融、医疗等强监管行业是合规性的基本要求。注意input_schema的使用是关键。很多团队在早期会忽略它认为“模型自己能理解”。但实测下来当工具越来越多、输入越来越复杂时仅靠自然语言描述模型的调用准确率会急剧下降。强制使用 JSON Schema相当于给模型提供了一份机器可读的“接口文档”将模糊的语义理解转化为精确的结构化匹配准确率能提升 30% 以上。3.2 生产部署定价模型与性能指标的实战解读Managed Agents 的定价模型是典型的“消费即付”pay-as-you-go$0.08 每 session-hour 的 active runtime外加标准的 Claude token 费用。这个数字乍看不高但必须结合其性能指标来理解否则很容易陷入误区。官方公布的性能数据是p50中位数time-to-first-tokenTTFT降低了约 60%p9595 分位数的 TTFT 表现优于 90%。这里的“优于 90%”是指在所有同类服务中它的 p95 TTFT 比 90% 的竞品都要好。换句话说对于最慢的那 5% 的请求它的表现依然非常稳健。我们来做一个简单的成本-性能测算。假设你的 agent 平均每次 session 的活跃时间为 2 分钟120 秒这在处理一个中等复杂度的任务如生成一份 500 字的报告中是合理的。那么每小时的 session 成本是 $0.08而每 session 的成本就是$0.08 / 60 minutes * 2 minutes $0.00267也就是大约0.27 美分。与此同时Claude Sonnet 的输入 token 费用约为 $0.003/1K tokens输出约为 $0.015/1K tokens。一个典型的会议纪要生成任务输入转录文本可能消耗 5K tokens输出JSON 结构消耗 0.5K tokenstoken 费用约为$0.003*5 $0.015*0.5 $0.01575。所以单次 session 的总成本约为 $0.0184其中 runtime 占比不到 15%。这说明对于中小规模的应用runtime 的成本并非瓶颈真正的成本大头依然是模型推理本身。这也是为什么 Anthropic 的定价策略是“防御性”的——它并不指望靠 runtime 收费成为主要收入来源而是要确保用户在使用 Claude 时体验是无缝、流畅、可靠的从而牢牢绑定住 token 的消费。然而这个模型在大规模、高并发场景下会呈现出不同的面貌。假设你的 SaaS 产品有 10 万付费用户平均每天每人使用 3 次 agent那么每天的 session 数量是 30 万次。按上面的单次成本 $0.0184 计算日成本是 $5520月成本是 $165,600。这笔费用对于一家年营收千万级别的公司来说是可以接受的运营成本但对于一家刚起步、还在验证 PMFProduct-Market Fit的初创公司这笔钱可能就足以决定其能否活下去。因此实操中的关键技巧是必须对 session 的生命周期进行精细化管理。不要让一个 session 无限制地“活着”。在 YAML 中你应该设置明确的timeout参数虽然原文未提及但这是生产环境的必备配置例如timeout: 3005 分钟。更重要的是在你的前端应用中要设计“session 预热”和“session 复用”机制。例如当用户打开一个新页面时不要立刻创建一个新 session而是先尝试复用一个最近活跃的、状态健康的 session。这能显著降低 session 的创建频率从而直接降低成本。我们内部的一个客户通过引入 session 复用池将日均 session 创建量降低了 40%效果立竿见影。4. 常见问题与排查技巧实录从“为什么我的工具没被调用”到“如何证明合规”4.1 典型问题速查表问题现象可能原因排查与解决技巧工具调用失败日志显示ToolNotFoundYAML 中tools列表里没有定义该工具名或名字大小写/拼写不一致。使用anthropic agents list-tools --agent-id ID命令列出当前 agent 实际加载的工具列表与 YAML 逐字比对。注意 YAML 的缩进是严格的关键- name:前的-和name:之间的空格必须是两个。Agent 输出了 JSON但格式不符合output_filter的allowed_keyssystem_prompt的指令不够强硬或模型在压力下“偷懒”。在system_prompt的末尾添加一句强制性指令“IMPORTANT: Your output MUST be a valid JSON object containing ONLY the following keys: decisions, action_items, open_questions. Any other key or any additional text will cause your response to be rejected.” 实测表明这种“威胁式”提示比温和的“please”有效得多。Session 在执行中突然中断没有任何错误日志Sandbox 因资源超限CPU/内存被 runtime 强制终止。查看 Session 的事件日志寻找SANDBOX_OOM_KILLED或SANDBOX_CPU_LIMIT_EXCEEDED类型的事件。解决方案是优化工具代码减少内存占用或在 YAML 中为该工具增加resource_limits配置如果 Anthropic 开放了此高级选项。notion_create_page调用成功但 Notion 页面内容为空工具的input_schema定义有误导致模型生成的content字段是一个对象而非字符串。在input_schema中为content字段添加type: string和description: The full content... in Markdown format.。同时在工具的后端实现中加入强类型校验拒绝任何非字符串类型的content输入。4.2 独家避坑技巧从“能用”到“可信”的跃迁技巧一用“事件日志”代替“截图”做客户演示在向客户或老板演示 agent 的能力时不要只展示最终的输出结果。打开 Session 的事件日志 UI实时滚动播放整个过程USER_INPUT-MODEL_THINKING-EXECUTE_STARTED (transcript_to_text)-EXECUTE_COMPLETED-MODEL_THINKING-EXECUTE_STARTED (notion_create_page)-EXECUTE_COMPLETED。这种“透明化”的演示能极大增强信任感。它向观众传递了一个明确的信息“这不是一个黑箱而是一个可观察、可追溯、可验证的系统。” 我们曾用这种方式成功说服了一家极其谨慎的银行客户让他们放弃了自建方案转而采用 Managed Agents。技巧二构建“合规性证据包”在金融、政务等行业仅仅“能用”是不够的你还必须能“证明它是安全的、可控的”。Managed Agents 的架构天然适合此需求。你可以定期例如每天凌晨运行一个脚本从 Session 层导出过去 24 小时的所有EXECUTE_STARTED事件生成一份 CSV 报告内容包括session_id,tool_name,timestamp,user_id如果已集成。这份报告就是一份铁证证明“我们的 agent 从未调用过任何未授权的工具”。同样你可以导出所有EXECUTE_COMPLETED事件统计每个工具的成功率、平均耗时形成 SLA 报告。这些都不是额外的工作而是对现有事件日志的例行归档是架构设计带来的“副产品”。技巧三沙箱不是银弹警惕“沙箱逃逸”的新型攻击面虽然 Anthropic 的沙箱隔离做得很好但它并不能防范所有风险。最大的盲区在于“工具本身”。例如你定义了一个shell_exec工具允许 agent 执行任意 shell 命令。那么无论沙箱多安全只要 agent 被诱导执行rm -rf /后果都是灾难性的。因此工具的设计哲学必须是“最小权限”。永远不要定义一个通用的shell_exec而应该定义一系列具体的、功能单一的工具如list_files_in_directory、read_file_content、send_email_to_sales_team。每一个工具都应该有自己独立的、最窄的权限集。这是在 runtime 层之上必须由你亲手构筑的第二道防线。5. 竞争格局与价值迁移为什么 runtime 层注定走向“零价”而真正的金矿在别处5.1 不是 Anthropic 在开创而是在追赶与固守将 Anthropic 的 Managed Agents 放在整个 AI 基础设施的版图中审视它的战略定位就变得异常清晰这是一场防御战而非一场开拓战。就在 Anthropic 发布 Managed Agents 的五个月前Amazon Bedrock 的 AgentCore 已经进入全面可用GA阶段。AWS 的动作之快、生态之广令人咋舌。AgentCore SDK 在短短五个月内下载量突破两百万次其内置的策略控制Policy Controls也同步达到 GA。这意味着一个开发者今天就可以用几行代码将一个 LangGraph 应用无缝部署到 AWS 的微虚拟机microVM上享受完全隔离的 CPU、内存和文件系统且 session 最长可运行八小时。更关键的是AgentCore 是“框架无关”的。它不强迫你使用 AWS 自己的 agent 框架而是拥抱整个开源生态。LangGraph、CrewAI、Strands……只要你能把它编译成一个标准的 request-response 循环AgentCore 就能运行它。模型选择也完全开放你可以自由选用 Bedrock 上的 Claude、Llama、Cohere甚至是你自己微调的模型。Google Vertex AI Agent Builder 和 Microsoft Azure AI Foundry也都推出了功能高度相似的托管 runtime。它们的共同点是免费或接近免费深度集成于各自的云平台且拥有无可比拟的规模效应和企业级支持能力。在这种背景下Anthropic 的 Managed Agents其核心价值就不再是“提供一个更好的 runtime”而是“提供一个与 Claude 模型深度绑定、体验最优的 runtime”。它的存在是为了回答一个尖锐的商业问题“如果我们不提供这个我们的 token 买家会不会轻易地把他们的 agent 工作负载迁移到 AWS 或 GCP 上然后在那儿顺手切换成更便宜的 Llama 模型” 这就是为什么文章标题说它“already going to zero”——因为 runtime 层的价值正在被 hyperscaler云巨头以“免费捆绑”的方式强行压向零。Anthropic 的产品本质上是一个“忠诚度计划”用一流的 runtime 体验来换取用户对其核心资产——Claude 模型——的持续采购。5.2 价值迁移的三大高地Trace、Governance、Vertical当 runtime 层被压平价值必然向上迁移。历史已经无数次证明了这一点。当年 VMware 的 hypervisor 价值被 KVM 和 Xen 压平后价值涌向了 Kubernetes容器编排、Terraform基础设施即代码当这些也被云厂商打包进服务后价值又涌向了更上层的应用平台。AI 基础设施的演进正在重演这一幕。第一高地Trace Store追踪存储当所有 agent 的行为都被记录为结构化的事件流这个事件流本身就成了最有价值的资产。它不仅是调试的工具更是训练下一代 agent 的“黄金数据集”是衡量 agent 效能的唯一客观标尺是满足审计合规的法定证据。Braintrust、Arize、LangSmith 这三家正在争夺这个“系统记录”的王座。它们的竞争焦点早已不是谁的 UI 更漂亮而是谁能提供最强的“跨 runtime 迁移能力”。想象一下你的公司今年用 Anthropic明年迁移到 AWS AgentCore后年又想试试 Google Vertex。如果 Trace Store 不能无缝承接所有这些平台的日志格式那么每一次迁移都意味着你失去了过去所有的历史数据等于重头再来。谁能率先定义一个开放的、行业标准的 trace schema例如基于 OpenTelemetry 的扩展谁就能赢得这场战争。第二高地Governance Policy治理与策略当 agent 开始被授权访问核心业务系统CRM、ERP、数据库“它被允许做什么”就变成了一个严肃的企业级问题。AWS 的 AgentCore Policy Controls GAOWASP 发布 Agentic Top 10都标志着这个领域已经从“技术话题”升级为“采购话题”。企业 CIO 们现在会问“这个 agent 的权限范围是如何审批的它的每一次越权尝试是否有完整的审计日志如果它出了问题责任如何界定” 目前市场上还没有一个成熟的、开箱即用的“agent 治理平台”。这是一个巨大的空白也是一个巨大的机会。它需要的不是另一个沙箱而是一个能与企业现有的 IAM身份与访问管理、SIEM安全信息与事件管理系统深度集成的策略引擎。第三高地Vertical Agent Marketplaces垂直领域 agent 市场当底层 runtime 变得像水电一样廉价和标准企业的采购决策就会从“买一个技术平台”转向“买一个能解决具体业务问题的方案”。Salesforce 的 Agentforce ARR 达到 8 亿美元就是一个强烈的信号。企业愿意为“销售开发 agent”、“保险理赔 agent”、“网络安全渗透测试 agent”付费但它们不愿意为“一个能跑 agent 的沙箱”付费。开源社区已经在为这些垂直市场铺路ai-hedge-fund专注于量化交易pentagi专注于红队攻防。资本也敏锐地捕捉到了这一点。未来的赢家将是那些能深入理解一个垂直行业的业务流程、法规要求和工作习惯并将其封装成一个开箱即用、经过严格验证的 agent 解决方案的公司。它们卖的不是代码而是“业务结果”。我个人在实际操作中的体会是与其把精力耗费在优化一个沙箱的启动速度上不如花十倍的精力去打磨一个sales-dev-agent的system_prompt。前者带来的边际效益递减得极快后者却能直接撬动客户的采购预算。技术人的终极成就感不在于造出最快的轮子而在于用轮子造出客户愿意掏钱买的车。
