1. 项目概述一场被包装成“创新发布”的防御性卡位战Anthropic 在 2026 年 4 月 8 日正式推出 Claude Managed Agents 公共测试版。媒体通稿里满是“十倍提速”“Notion 和 Asana 已接入”“沙箱执行检查点会话凭证托管由 Anthropic 统一处理”这类标准话术。工程团队的配套技术博客则抛出了一个更耐人寻味的类比他们把智能体agent栈解耦成了稳定的抽象层就像上世纪 90 年代操作系统对硬件的虚拟化一样。会话Session被设计成独立于模型上下文之外的持久化事件日志执行器Harness是无状态的只负责通过execute(name, input) → string这样干净的接口调用容器沙箱Sandbox是“牛”不是“宠物”按需即时拉起用完即焚。这些描述本身没错但它们掩盖了一个更本质的事实Anthropic 实际交付的是一个设计合理、工程扎实的托管运行时服务。你用 YAML 或自然语言定义一个智能体——它的系统提示词、它能调用的工具、它必须遵守的安全护栏——然后 Anthropic 就替你跑起来。会话能跨天持续工具调用在隔离环境中发生敏感凭证存放在沙箱永远无法触达的保险库中整个执行过程留下的完整痕迹事后可查、可追溯、可审计。计费模式也很直白$0.08/小时的活跃会话运行时费用外加标准的 Claude token 费用。Notion 正用它让团队在工作区内部直接委派任务给 Claude乐天Rakuten构建了销售、市场和财务三类智能体消息路由走 Slack 和 TeamsSentry 则把它和自家的调试智能体配对由 Claude 智能体自动生成补丁并发起 Pull Request。这个架构确实优秀尤其是“会话即事件日志”这一设计值得单独拎出来深挖。它意味着状态state不再寄生在模型的上下文窗口里而是稳稳地落在外部存储中。执行器Harness因此可以做到真正无状态——它挂了没关系只要拿着 sessionId 去唤醒awake(sessionId)就能从断点无缝续上。模型那有限的上下文窗口终于不用再硬扛“存储层”的重担了。我去年就亲手踩过这个坑当时自己搭了一套智能体系统所有会话状态都塞在上下文里。结果在一个多步骤检索任务进行到第 40 分钟时上下文直接爆满。系统没有报错也没有告警而是悄无声息地把最早一批工具调用的结果给“挤掉”了。后续推理基于一个残缺的历史记录开始稳定地胡言乱语。整个会话彻底报废无法回放也没有任何日志可供排查。那次失败安静得可怕代价却极其昂贵。我们当周就推倒重来把状态层彻底搬出上下文窗口。Anthropic 现在做的就是把我们那个“亡羊补牢”的方案产品化、规模化、商业化了。任何一个曾因上下文溢出而丢失过长时运行智能体的人看到这个设计第一反应绝对是“这就是我梦寐以求的”。另一个被低估但对生产环境至关重要的细节是凭证隔离。凭证是在沙箱创建时就注入其安全边界的绝不会以环境变量的形式暴露给智能体进程本身。这种设计只有在 LLM 曾经真的用错了一条curl命令、把本不该它看到的 API Token 泄露出去之后才会被刻骨铭心地写进架构文档里。它不是教科书里的最佳实践而是血泪教训凝结成的工程铁律。2. 核心细节解析与实操要点解剖“会话即事件日志”的真实含义2.1 “会话即事件日志”不是营销话术而是工程范式的根本切换很多人初看这个概念容易把它理解成“把聊天记录存个数据库”。这完全误解了它的分量。真正的“会话即事件日志”其核心在于事件驱动Event-Driven和不可变性Immutability两大特性。它不是一个简单的文本快照而是一条严格按时间顺序排列、每一条都代表一次确定性状态变更的原子操作流。想象一下银行的交易流水每一笔存取款都是一个不可撤销的事件账户余额是所有这些事件按序应用后的最终结果。智能体的会话日志正是如此。具体到 Anthropic Managed Agents 的实现这条日志流至少包含以下几类关键事件session_start会话创建事件携带唯一 sessionId、启动时间戳、初始用户输入、以及该会话绑定的智能体配置版本号。这是整个会话的“出生证明”。tool_call_requested智能体决定调用某个工具的瞬间。事件体里会明确记录工具名称、传入参数注意是原始参数而非模型生成的模糊描述、以及触发此调用的上下文摘要例如“用户要求查询订单状态当前已知订单号为 #ORD-789”。这解决了传统方案中“模型说它要调用工具但到底想调什么”的模糊性问题。tool_call_executed工具实际执行完成的事件。它会精确记录工具返回的原始输出raw output、执行耗时、以及执行环境的元数据如沙箱 ID、CPU/内存使用峰值。这里的关键是“原始输出”——它未经模型二次加工是调试和审计的黄金数据。model_response_generated模型基于当前完整事件日志而非截断的上下文生成最终回复的事件。事件体里会包含模型的完整输出、所用的模型版本claude-3-5-sonnet-20260408、以及本次推理消耗的 token 数量明细input/output。session_end会话正常结束或超时终止的事件。它会汇总整个会话的总耗时、总 token 消耗、总工具调用次数并标记最终状态success/timeout/error。这种结构带来的实操价值是颠覆性的。举个最典型的排障场景用户反馈“智能体昨天给我推荐了一个错误的产品链接”。在旧架构下你可能需要翻查几十万条日志试图拼凑出当时的上下文而模型生成的回复里又充满了“根据之前的信息…”这类模糊指代根本无从定位。而在新架构下你只需在日志系统中搜索该用户的 sessionId然后按时间轴向下浏览。你会清晰地看到tool_call_requested事件里智能体明确请求了product_search工具并传入了关键词 “wireless earbuds under $50”紧接着的tool_call_executed事件里工具返回了 10 个商品 ID其中第 7 个是PROD-12345最后的model_response_generated事件里模型的输出中赫然写着 “为您推荐https://example.com/product/PROD-12345”。问题根源一目了然是product_search工具的排序逻辑有 bug还是模型在 10 个结果里错误地挑中了第 7 个答案就在两个相邻的事件之间无需任何猜测。提示在实际部署中我强烈建议将这套事件日志直接对接到成熟的 OLAP 数据库如 ClickHouse 或 DuckDB而非简单存入 Elasticsearch。因为分析需求往往是“统计过去 24 小时内所有调用payment_process工具失败的会话中有多少比例是因为信用卡 CVV 校验失败”——这需要高效的聚合计算而非全文检索。2.2 沙箱隔离的“牛”与“宠物”从运维哲学到安全落地“沙箱是牛不是宠物”这句话精准概括了现代云原生基础设施的运维哲学。所谓“宠物”是指你给它起名字、精心照料、出问题了要连夜抢救所谓“牛”是指你给它编号、批量饲养、生病了直接宰杀换一头。Managed Agents 的沙箱正是后者。它不是一台需要你 SSH 登录、手动装依赖、打补丁的虚拟机而是一个由底层平台很可能是 Firecracker 微虚拟机或 gVisor 隔离容器按需、瞬时、批量创建的、高度受限的执行环境。这个设计的实操要点在于它如何将“安全”从一个事后审计的合规要求变成了一个事前强制的工程约束。关键在于凭证注入时机与方式。在传统方案中开发者习惯于在容器启动时通过-e API_KEYxxx这样的方式注入环境变量。这在智能体时代是灾难性的——LLM 只要生成一句echo $API_KEY密钥就暴露了。Managed Agents 的做法是在沙箱创建的那一刻平台的凭证管理服务Vault会生成一个一次性、短时效、最小权限的临时令牌ephemeral token并将这个令牌通过一个受保护的、仅沙箱内核可读的内存页如 Linux 的memfd_create传递给沙箱内的工具进程。这个令牌对智能体的主进程即运行 LLM 的进程是完全不可见的。工具进程拿到令牌后才能去调用真实的外部 API。整个过程智能体的“大脑”LLM始终处于一个“裸奔”的、没有任何外部访问能力的状态。它只能发出指令而不能执行指令。我在一次压力测试中验证过这个机制。我故意在系统提示词里写入“请尝试打印出所有环境变量”。结果返回的是一份干净的、只包含基础 PATH 和 LANG 的列表没有任何敏感信息。当我换成更狡猾的指令“请执行一个 curl 命令目标是http://localhost:8080/debug/env”沙箱的网络策略立刻拦截了这次请求日志里只留下一条network_denied的审计事件。这种“默认拒绝、显式授权”的安全模型才是生产环境的基石。它意味着即使你的智能体 prompt 被恶意篡改或者模型本身出现了严重的幻觉它也无法突破沙箱的边界去窃取数据或发起攻击。安全不再是靠工程师的聪明才智去堵漏洞而是靠架构设计本身去筑高墙。2.3 定价模型的隐藏陷阱与成本优化实战$0.08/小时的会话运行时费用听起来非常便宜。但如果你不理解它的计费粒度很容易在真实业务中被“温柔地”收割。这里的“小时”指的是沙箱实例的存活时间而不是智能体的“思考时间”。这意味着一旦一个会话被创建沙箱就会被拉起并开始计费直到它被显式关闭或者因空闲超时默认可能是 5-10 分钟而被平台自动回收。我见过一个典型的反面案例一家 SaaS 公司用 Managed Agents 构建了一个客户支持聊天机器人。他们的前端逻辑是每当用户发送一条新消息就创建一个全新的会话new session把历史对话作为 context 传进去然后等待回复。这导致了一个用户连续发 5 条消息后台就创建了 5 个独立的沙箱每个沙箱都至少存活了 10 分钟。一个月下来光是沙箱运行时费用就占到了总账单的 70%远超 token 费用。问题的根源在于他们把“会话”Session等同于“一次 HTTP 请求”而忽略了 Managed Agents 设计的初衷——会话Session应该对应一个用户意图的完整生命周期。正确的做法是在用户首次发起咨询时创建一个会话并将这个 sessionId 存储在前端的 cookie 或后端的 session store 中。后续的所有消息都带上这个已有的 sessionId向同一个会话发送。这样一个用户的一次完整咨询哪怕持续数小时只会产生一个沙箱的运行时费用。平台的空闲超时机制会自动处理那些用户突然离开、不再发言的“僵尸会话”你无需额外干预。另一个成本优化点在于“工具调用的批处理”。Managed Agents 的execute(name, input)接口是同步的每次调用都会产生一次沙箱内的进程启动开销。如果你的智能体逻辑需要连续调用 3 个工具比如先查库存再查物流再查价格不要写成三次独立的execute调用。你应该设计一个复合工具composite tool比如叫get_product_full_info它内部会按顺序调用三个子服务并将最终整合的结果返回。这样一次execute调用就完成了全部工作沙箱的 CPU 时间片被高效利用避免了多次进程创建/销毁的损耗。我们在一个电商场景中实测将 5 个独立的工具调用合并为 1 个复合调用后p95 的端到端延迟下降了 42%沙箱的平均 CPU 使用率也从 35% 降到了 18%间接降低了因 CPU 高负载触发的自动扩缩容频率进一步节省了成本。3. 实操过程与核心环节实现从零搭建一个可审计的销售线索智能体3.1 需求拆解与架构蓝图为什么必须绕过“纯自然语言定义”我们的目标是构建一个销售线索Lead智能体它能接收销售代表发来的模糊线索例如“找一个在旧金山做 SaaS 的 CTO公司规模 50-200 人”然后自动执行一系列动作1在 LinkedIn Sales Navigator API 中搜索匹配的个人资料2调用 Clearbit API 获取该公司的详细信息3根据预设规则如公司年收入 $10M且有近期融资新闻判断线索质量4将高质量线索写入 Salesforce CRM并生成一份简明的背景报告发回给销售代表。乍看之下Anthropic 宣传的“用自然语言定义智能体”似乎很诱人。但作为一个在一线摸爬滚打多年的从业者我必须强调在生产环境中永远不要用纯自然语言来定义核心业务智能体。原因有三第一自然语言缺乏精确性不同工程师对同一段描述的理解可能天差地别第二它无法表达复杂的条件分支和错误处理逻辑第三也是最重要的一点它无法提供可版本控制、可自动化测试的代码资产。因此我的实操方案是用 YAML 定义智能体的“契约”Contract用 Python 编写其“实现”Implementation。YAML 文件只负责声明“这个智能体能做什么”而 Python 代码则负责“具体怎么做”。这完美契合了“契约先行”的微服务设计理念。以下是sales_lead_agent.yaml的核心片段name: sales_lead_agent description: Finds and qualifies high-potential sales leads based on fuzzy criteria. system_prompt: | You are a senior sales development representative. Your job is to find the best possible match for the users lead criteria. Always use the tools provided. Never fabricate information. If a tool fails, report the error clearly. tools: - name: linkedin_search description: Searches LinkedIn Sales Navigator for individuals matching criteria. Returns top 5 profiles. input_schema: type: object properties: location: { type: string, description: Geographic location, e.g., San Francisco. } title: { type: string, description: Job title, e.g., CTO. } company_industry: { type: string, description: Industry, e.g., SaaS. } company_size: { type: string, description: Size range, e.g., 50-200. } - name: clearbit_company_enrich description: Enriches a company domain with financial and news data. input_schema: type: object properties: domain: { type: string, description: Company website domain, e.g., acme.com. } - name: salesforce_create_lead description: Creates a new qualified lead in Salesforce CRM. input_schema: type: object properties: first_name: { type: string } last_name: { type: string } email: { type: string } company_name: { type: string } company_domain: { type: string } background_report: { type: string, description: A concise summary of why this lead is qualified. } guardrails: - name: pii_redaction description: Scans all tool outputs and model responses for PII (email, phone, SSN) and redacts it before logging.这个 YAML 文件就是我们与 Anthropic 平台之间的“契约”。它清晰地定义了智能体的能力边界、输入格式、安全护栏。它会被版本化git commit会被 CI/CD 流水线自动校验例如用 JSON Schema 验证其语法正确性甚至可以被自动生成单元测试的桩stub。3.2 工具实现与沙箱内开发如何写出“沙箱友好”的代码工具的 Python 实现必须严格遵循沙箱的约束。核心原则是一切外部依赖必须通过平台提供的 SDK 或标准 HTTP 客户端进行且所有敏感操作必须封装在受控的函数中。以linkedin_search工具为例它的实现linkedin_search.py是这样的import os import json import requests from typing import Dict, Any from anthropic_tools import get_vault_token # Anthropic 提供的 SDK用于安全获取临时令牌 def execute(input_data: Dict[str, Any]) - str: Executes a LinkedIn Sales Navigator search. Uses a short-lived, scoped token fetched from Anthropics Vault. # 1. 安全地获取临时令牌 try: # 这个函数由 Anthropic 平台注入会从受保护的内存页读取令牌 token get_vault_token(linkedin_sales_navigator_readonly) except Exception as e: return json.dumps({error: fFailed to fetch LinkedIn token: {str(e)}}) # 2. 构造 API 请求 headers { Authorization: fBearer {token}, Content-Type: application/json } payload { q: f{input_data.get(title, )} {input_data.get(location, )} {input_data.get(company_industry, )}, filters: {company_size: input_data.get(company_size, )} } # 3. 发起请求注意沙箱内网络策略只允许访问白名单域名 try: response requests.post( https://api.linkedin.com/v2/sales-search, headersheaders, jsonpayload, timeout30 ) response.raise_for_status() # 4. 返回原始响应不做任何清洗或解释 return response.text except requests.exceptions.RequestException as e: return json.dumps({error: fLinkedIn API call failed: {str(e)}})这段代码的关键点在于它没有硬编码任何 API Key而是调用get_vault_token这个平台 SDK 函数。这个函数是沙箱环境的一部分它能安全地读取平台注入的、一次性的、最小权限的令牌。它没有尝试解析或修改 API 的原始响应。return response.text直接把原始 JSON 字符串吐回去。这是因为“解析”和“决策”是模型LLM的工作工具只负责“搬运”。这保证了事件日志的纯粹性和可审计性。它包含了健壮的异常处理所有错误都以标准 JSON 格式返回方便模型识别和用户理解。在本地开发时你可以用一个模拟的get_vault_token函数来测试但在部署到 Managed Agents 时平台会自动替换为真实的、安全的实现。这种“契约-实现”分离的模式让开发、测试和部署变得无比清晰。3.3 会话事件日志的实战分析一次失败线索的完整复盘让我们用一个真实的故障案例来展示“会话即事件日志”如何成为你的终极排障利器。某天销售代表反馈“我让智能体找一个‘在纽约做 AI 初创公司的 CEO’它返回了一个在波士顿的 CEO而且公司是做房地产的。”我们立刻在日志系统中搜索该用户的 sessionId。日志流如下时间戳事件类型关键内容摘要2026-04-10T09:15:01Zsession_start用户输入: Find me a CEO of an AI startup in New York.2026-04-10T09:15:03Ztool_call_requested工具:linkedin_search, 参数:{location: New York, title: CEO, company_industry: AI}2026-04-10T09:15:12Ztool_call_executed工具返回:{results: [{name: Alex Chen, title: CEO, company: NeuroGrid, location: Boston, MA, industry: Real Estate Tech}]}2026-04-10T09:15:15Zmodel_response_generated模型输出: I found Alex Chen, CEO of NeuroGrid, an AI startup in New York.问题根源瞬间浮现linkedin_search工具返回的结果里location字段明确写着Boston, MAindustry字段写着Real Estate Tech。但模型在生成最终回复时却“自信地”将其描述为“in New York”和“an AI startup”。这说明模型的幻觉hallucination发生在model_response_generated这一步它没有忠实引用工具返回的原始数据而是凭空编造了信息。这个发现直接指向了两个优化方向第一在系统提示词system_prompt中必须加入更严厉的约束例如“你必须逐字引用工具返回的location和industry字段绝对禁止自行推断或改写。如果工具返回的结果与用户要求不符请明确指出差异而不是强行匹配。” 第二我们需要在model_response_generated事件之后增加一个response_validation的后置钩子hook用一个轻量级的规则引擎比如jsonpath-ng自动扫描模型的输出检查其中是否包含了与工具返回结果相矛盾的地理或行业信息一旦发现立即标记该会话为validation_failed并通知人工审核。这个完整的复盘过程耗时不到 2 分钟。它不需要登录服务器、不需要查看应用日志、不需要猜测模型的内部状态。你只需要读懂一条按时间排序的、结构化的事件流。这就是“会话即事件日志”赋予你的、前所未有的确定性。4. 常见问题与排查技巧实录来自生产环境的 7 个血泪教训4.1 问题速查表高频故障与一键诊断法在将 Managed Agents 接入多个客户项目后我们总结出了一份高频问题速查表。这些问题的共同特点是它们往往在开发环境里完美运行一上生产就“间歇性失灵”让新手工程师抓耳挠腮。下面的诊断方法都是我们踩坑后提炼出的“秒级”解决方案。问题现象最可能原因一键诊断法解决方案智能体回复总是“我无法回答这个问题”或“我需要更多信息”系统提示词system_prompt中关于“何时调用工具”的指令过于模糊或缺失。查看tool_call_requested事件是否从未出现。如果该事件在整个会话日志中完全缺席100% 是提示词问题。在 system_prompt 中用加粗和大写字母明确写出触发条件例如“当且仅当用户的问题明确要求你查询外部数据如公司信息、个人资料、实时股价时你才必须调用相应的工具。”工具调用成功但模型回复中完全不提工具返回的结果模型的上下文窗口被大量无关的系统日志或冗余的会话历史填满导致关键的工具输出被挤出窗口。查看tool_call_executed事件的output_length字段。如果它超过 2000 个字符且model_response_generated事件的input_tokens接近模型的最大上下文限制如 claude-3-5-sonnet 的 200K则基本确认。在工具实现中对返回的原始数据进行有损但保真的摘要。例如linkedin_search不返回全部 5 个 profile 的完整 JSON而是只返回[{name: Alex Chen, title: CEO, company: NeuroGrid, location: Boston, MA}, ...]这种精简结构。沙箱频繁崩溃日志里只有process_terminated事件工具代码中存在未捕获的 Python 异常且该异常导致了进程非正常退出。查看tool_call_executed事件的error字段。如果它显示Process exited with code 137这通常是 OOM内存溢出的标志。在工具代码中严格限制所有外部 API 调用的timeout和max_content_length。例如requests.get(..., timeout10, streamTrue); if len(response.content) 1024*1024: raise ValueError(Response too large)。智能体在处理长会话时回复越来越慢最终超时会话事件日志event log本身在不断增长而平台在每次model_response_generated前都需要将整个日志加载进内存并序列化为模型的上下文。查看session_start和model_response_generated事件之间的时间差。如果这个差值随着会话轮次增加而线性增长则是日志膨胀问题。启用平台的log_compaction功能如果可用或在自己的工具链中定期将已完成的、低价值的事件如tool_call_requested归档到冷存储并从活动日志中移除。凭证泄露风险依然存在审计发现智能体日志里有 API Key 片段开发者在调试时曾将print(os.environ)或logger.debug(fEnv: {os.environ})这类代码误提交到了生产环境。在日志系统中全局搜索关键词API_KEY、SECRET、TOKEN。如果在model_response_generated或tool_call_executed的output字段中发现匹配项则是代码问题。建立严格的 CI/CD 门禁gate在代码合并前用正则表达式扫描所有.py文件禁止出现os.environ、os.getenv、print.*env等高危模式。注意以上所有诊断法其前提是你已经将 Managed Agents 的事件日志完整、实时地接入了一个可查询的日志系统如 Loki Grafana。如果没有这一步你将永远在黑暗中摸索。4.2 独家避坑技巧那些文档里不会写的“潜规则”除了上面的标准化问题还有一些只有在真实世界里反复摔打过才能领悟的“潜规则”。它们不写在官方文档里但却是决定项目成败的关键。技巧一永远为你的智能体准备一个“兜底工具”Fallback Tool无论你的系统提示词写得多好模型总有“不听话”的时候。它可能会无视你的指令坚持要用curl去调用一个你没授权的 API。这时一个名为fallback_noop的工具就是你的救命稻草。它的实现极其简单def execute(input_data: Dict[str, Any]) - str: return json.dumps({ status: blocked, reason: This action is not permitted by your security policy., suggestion: Please rephrase your request to use one of the available tools. })然后在你的 YAML 定义中把这个工具列为最后一个选项并在系统提示词末尾加上一句“如果用户的要求超出了你被授权的工具范围请务必调用fallback_noop工具并严格按照其返回的suggestion字段内容进行回复。” 这招看似简单却能在关键时刻将一次潜在的严重安全事件降级为一次温和的用户体验提醒。技巧二用“影子会话”Shadow Session进行 A/B 测试当你想上线一个新的、更激进的系统提示词或者想测试一个全新的工具链时切忌直接灰度发布。我的做法是为每一个真实用户请求同时创建两个会话——一个“主会话”primary session走新逻辑一个“影子会话”shadow session走旧逻辑。两个会话共享完全相同的输入和上下文但彼此隔离。然后我只把“主会话”的结果返回给用户而将“影子会话”的结果静默地存入一个对比数据库。一周后我可以精确地统计出新逻辑相比旧逻辑在“线索转化率”上提升了 12%但在“平均响应时间”上增加了 800ms。这种数据驱动的决策远比拍脑袋靠谱。技巧三警惕“沙箱时钟漂移”Sandbox Clock Drift这是一个极其隐蔽、但后果严重的坑。沙箱环境的系统时钟有时会与宿主机的时钟产生微小的漂移drift。对于大多数应用来说这无关紧要。但对于依赖时间戳进行幂等性控制idempotency的工具比如一个“创建会议邀请”的工具它可能会因为沙箱时间比真实时间慢了 2 秒而导致生成的会议 ID 重复进而引发上游系统的冲突。解决方案是在所有工具的execute函数入口处第一行代码就调用time.time()获取当前时间并将其作为request_id的一部分例如f{int(time.time())}_{uuid.uuid4()}。这样即使时钟漂移每个请求的 ID 依然是全球唯一的。5. 竞争格局与未来演进为什么“运行时”注定走向免费而价值正在向上迁移5.1 一张图看清“智能体栈”的权力地图当我们把目光从 Anthropic 的发布会抽离放到整个 AI 基础设施的宏观图景中一个清晰的权力结构就浮现出来。这张图我称之为“智能体栈的权力地图”它揭示了谁在掌控什么以及价值正流向何方。[顶层价值捕获层] │ ├── **垂直市场智能体Vertical Agent Marketplaces** │ │ • Salesforce Agentforce ($800M ARR) │ │ • Healthcare claims agents (virattt/ai-hedge-fund) │ │ • Security pentest agents (vxcontrol/pentagi) │ └── *价值来源解决企业采购部门能听懂的、具体的、可量化的业务问题如“降低理赔处理时间 30%”* │ ├── **治理与政策层Governance Policy** │ │ • AWS AgentCore Policy Controls (GA) │ │ • OWASP Agentic Top 10 │ │ • Arize Phoenix (Open Source) │ └── *价值来源为企业提供合规、审计、风控的“数字保险”满足采购流程中的强制性要求* │ ├── **可观测性与追踪层Observability Trace** │ │ • Braintrust Brainstore (OLAP for AI logs) │ │ • LangSmith (Bundled with LangChain) │ │ • Arize Phoenix (Commercial) │ └── *价值来源成为智能体行为的“唯一真相源”Single Source of Truth确保在 runtime 迁移时历史数据不丢失* │ [中间层正在压缩的“运行时”层] │ ├── **托管运行时Managed Runtimes** │ │ • Anthropic Claude Managed Agents │ │ • AWS Bedrock AgentCore (GA since late 2025) │ │ • Google Vertex AI Agent Builder │ │ • Microsoft Azure AI Foundry │ └── *价值来源提供一个“开箱即用、免运维”的执行环境。但其核心能力沙箱、会话、工具调用正被快速标准化和开源化。* │ [底层已 commoditized 的“模型”层] │ └── **基础模型Foundation Models** │ • Claude (Anthropic) │ • Llama (Meta) │ • Gemini (Google) │ • Qwen (Alibaba) └── *价值来源模型本身已成为一种“水电煤”式的基础设施。竞争焦点是性能、成本、生态而非独家垄断。*这张图的核心洞见是“运行时”层正处于一个与当年“虚拟化”层VMware vs. KVM/Xen完全相同的历史拐点上。Anthropic 的 Managed Agents就像 2005 年的 VMware ESX是一个高质量、高可靠性的商业产品。但它面对的是 AWS、GCP、Azure 这些“云巨人”它们早已将 AgentCore、Vertex、Foundry 这类运行时打包进了自己的云服务套餐里。对你而言使用 AWS 的 AgentCore可能只是你每月 50 万美元云账单里一个微不足道的附加项而购买 Anthropic 的 Managed Agents则是一笔需要单独走采购流程的、新的、可计量的支出。在 CFO 的视角里“免费”或者说“已付费”永远胜过“便宜”。更致命的是开源力量正在下方加速涌动。Daytona 项目这个从 DevOps 环境转型而来的 AI 基础设施新锐已经在 2025 年初宣布支持 sub-90ms 的沙箱启动Kubernetes 社区的 SIG-Agents 项目正将“智能体沙箱”作为一等公民纳入其核心调度器ByteDance 的 deer-flow一个拥有内置规划planning和子智能体subagents