1. 这不是新赛道是 runtime 层的“操作系统时刻”来了你有没有在深夜调试一个跑了三小时的 AI 代理突然发现它开始胡言乱语不是模型崩了不是 prompt 写错了而是——它的“记忆”被挤掉了。上下文窗口就那么大工具调用日志、中间结果、用户多轮对话、系统指令……全堆在里面。到第47分钟最老的那条 API 返回结果被悄悄截断代理却浑然不觉拿半截数据去推理生成一个看似合理实则完全错误的下一步动作。更糟的是你没法回放、没法审计、没法定位问题到底出在哪一环。你只能重启从头再来把之前两小时的计算全部扔进回收站。这就是过去一年里我亲手踩过的坑也是 Anthropic 在 2026 年 4 月 8 日发布的Claude Managed Agents真正要解决的核心痛点。它不是又一个“让 AI 更聪明”的花哨功能而是一次对整个 agent 架构底层逻辑的外科手术式重构。关键词不是“智能”而是“可靠”、“可审计”、“可恢复”。它把原本黏在模型上下文里的“状态”硬生生地剥离出来变成一个独立、持久、可查询的事件日志session-as-event-log。这个设计选择直接决定了一个 agent 是能跑通一次 demo还是能嵌入企业核心工作流、连续运行数周不出岔子。这背后牵扯的是整个 AI 工程化栈正在经历的剧烈压缩。就像当年虚拟化技术从 VMware 的高价软件迅速变成 AWS EC2 底层免费提供的基础设施一样agent runtime 这一层也正以肉眼可见的速度滑向“零成本”区间。Anthropic 这次发布表面看是技术领先细看却是防御性卡位——它必须确保当开发者选择在 AWS Bedrock AgentCore 或 Google Vertex AI 上部署 Claude 代理时Anthropic 依然能牢牢抓住 token 消费这个命脉。所以Managed Agents 的定价是 $0.08/小时的 active runtime外加标准的 Claude token 费用。这个价格对小团队很友好但对大规模企业客户而言它更像是一个“入场券”而非长期护城河。真正的价值已经不在 runtime 本身而在它之上生长出来的那些东西可观测性、治理策略、垂直场景的交付能力。这篇文章我就用一个一线工程师的视角带你拆解这个“即将归零”的 layer 到底长什么样、为什么它必然归零、以及当它归零之后钱会流向哪里。2. 核心架构拆解为什么“Session as Event Log”是唯一正确的解法2.1 旧范式的致命缺陷上下文即牢笼在 Managed Agents 出现之前绝大多数自研 agent 系统都遵循一个简单粗暴的模式把所有东西——系统指令、用户输入、工具调用历史、中间结果、甚至错误堆栈——一股脑塞进 LLM 的上下文窗口里。这就像把整个办公室的文件、会议记录、待办清单、甚至咖啡机的维修单全都贴在一张 A4 纸上然后让一个只认得这张纸的助理来帮你处理工作。只要纸够大比如 Claude 3.5 的 200K tokens一切似乎都还行。但现实是残酷的。我去年参与的一个金融尽调 agent需要串联调用 7 个内部 API市场数据、财报解析、舆情抓取、合规检查、风险评分、报告生成、PDF 导出每一步的输入输出平均占用 1200 tokens。一个完整的流程下来光是工具交互日志就占掉 8400 tokens。再加上初始 prompt2500 tokens、用户原始需求1500 tokens和中间思考链保守估计 3000 tokens总消耗轻松突破 15K。这还没算上 agent 自己的“反思”和“重试”产生的冗余内容。当流程跑到第 3 轮迭代上下文开始溢出系统不会报错它只会“优雅地遗忘”——自动丢弃最早的一段日志。问题在于这段被丢掉的往往是最关键的“第一次 API 调用返回的原始 JSON 数据”。后续所有基于此的解析、比对、判断全都建立在沙上。我们花了整整两天时间才通过反复对比不同 session 的 token 使用量曲线反向推断出故障点。这种“静默失败”比任何崩溃都可怕因为它让你根本不知道自己已经错了。提示上下文溢出导致的静默失败是当前 agent 开发中最高频、最隐蔽、最难排查的生产事故。它无法被单元测试覆盖因为测试用例永远跑不满整个上下文窗口。2.2 Anthropic 的外科手术三层解耦各司其职Managed Agents 的核心创新就是用一套清晰的分层架构把那个混乱的“上下文牢笼”彻底打破。它不是在旧房子上加盖而是推倒重建划出了三条清晰的边界线第一层Session会话—— 作为持久化、可审计的“事件总线”这是整个架构的基石。每一个 session 不再是一个内存变量而是一个独立的、带时间戳的、不可变的事件序列event log。每一次工具调用tool_use、每一次模型响应model_output、每一次用户输入user_message、甚至每一次内部状态变更state_update都会被序列化为一个结构化的 JSON 事件写入一个外部的、高可用的存储后端Anthropic 官方未公开具体技术栈但根据其工程博客描述的“queryable after the fact”极大概率是基于分布式 OLAP 数据库如 ClickHouse 或 Druid 的定制化实现。这个事件日志是全局唯一的由sessionId精确索引。最关键的是它与模型的推理过程完全解耦。模型只需要读取它需要的那一小段上下文比如最近 3 条事件而整个 session 的完整历史则躺在安全、持久的存储里随时待查。第二层Harness执行器—— 作为无状态、可替换的“调度中枢”Harness 是一个纯粹的、轻量级的执行环境。它不保存任何业务状态它的唯一职责就是接收一个sessionId和一个input然后根据预定义的 YAML 配置决定调用哪个工具、如何序列化参数、如何处理返回值并将结果打包成一个新事件写回 Session Log。它的接口极其简洁execute(name, input) → string。这意味着 Harness 可以像容器一样被任意启停、扩缩容甚至可以被完全不同的实现所替代比如今天用 Python 实现明天换成 Rust 重写只要接口一致上层逻辑毫发无伤。当 Harness 因为某种原因崩溃时它不需要“恢复状态”它只需要调用awake(sessionId)从 Session Log 中拉取最新的事件快照就能瞬间回到崩溃前一刻的精确状态继续执行。这彻底消除了传统 agent 中“状态丢失即 session 死亡”的单点故障。第三层Sandbox沙箱—— 作为隔离、可信的“执行牢房”这是安全性的最后一道防线。每一个工具调用都在一个全新的、临时的、资源受限的沙箱环境中执行。这个沙箱是“cattle, not pets”牛而非宠物——它没有名字、没有身份、用完即焚。更重要的是凭证credentials的注入方式发生了根本性变革。旧方案是把 API Key、数据库密码等敏感信息作为环境变量ENV注入沙箱agent 代码可以直接os.getenv()读取。这相当于把保险柜的钥匙明晃晃地挂在执行者的腰带上。Managed Agents 的做法是在沙箱启动时由 Anthropic 的可信执行环境TEE将凭证注入沙箱的内核空间agent 代码层完全无法访问。当 agent 发起一个curl请求时沙箱的网络栈会自动拦截该请求用内核中持有的凭证完成认证再将结果返回给 agent。agent 永远不知道自己的“权限”是什么它只知道“我发了一个请求我收到了一个响应”。这从根本上杜绝了 agent 因 prompt 注入或逻辑漏洞而泄露凭证的风险。这三层解耦共同构成了一个健壮、可扩展、可审计的 agent 基础设施。它不再依赖于某个模型的上下文大小而是将状态管理、逻辑执行、安全隔离这三项关键能力交给了各自最擅长的组件。这正是 Anthropic 工程博客中所说的“stable abstractions”——稳定抽象。就像操作系统用虚拟内存抽象了物理 RAM用文件描述符抽象了磁盘 I/O 一样Managed Agents 用 Session、Harness、Sandbox 抽象了 agent 的生命周期、执行逻辑和安全边界。2.3 为什么说这不是“创新”而是“补课”这里必须指出一个关键事实Anthropic 的这套架构在理念上并非独创。它本质上是对现代云原生架构原则如十二要素应用、不可变基础设施、服务网格在 AI 领域的一次精准复刻。真正让它“落地”的是 Anthropic 将这些原则与 LLM 的特性做了深度适配。例如“Sandbox as cattle” 的理念直接对应了 Kubernetes 的 Pod“Session as event log” 的理念则是事件溯源Event Sourcing模式在 agent 场景下的经典应用。它的伟大之处不在于发明了新概念而在于它用工业级的工程实现把一个理论上正确、但实践中充满陷阱的模式变成了开箱即用、生产就绪的产品。这恰恰印证了那句老话“The best innovation is often the one that makes the obvious, inevitable, and reliable.”3. 实操细节与关键配置从 YAML 定义到生产部署3.1 一个真实的 agent YAML 配置解析Managed Agents 允许你用极简的 YAML 文件来定义一个 agent 的全部行为。下面是一个为销售团队设计的“客户线索自动打分与分配” agent 的真实配置片段我会逐行解释其背后的工程考量# agent.yaml name: sales-lead-scorer description: Automatically scores and routes new leads from HubSpot to sales reps based on firmographic and engagement data. # 系统提示词定义 agent 的角色和核心规则 system_prompt: | You are a senior sales operations analyst at Acme Corp. Your job is to score incoming leads on a scale of 0-100 and assign them to the most appropriate sales rep. Scoring criteria: Company size (30%), Industry fit (25%), Website traffic (20%), Recent email opens/clicks (15%), Social media followers (10%). NEVER hallucinate scores. If any required data is missing, return INCOMPLETE and list the missing fields. # 定义 agent 可用的工具集每个工具都是一个独立的服务 tools: - name: hubspot_get_lead description: Fetches all available data for a lead by its HubSpot ID. # 参数 schema强制类型检查避免 agent 传入错误格式 parameters: type: object properties: lead_id: type: string description: The unique ID of the lead in HubSpot. required: [lead_id] - name: salesforce_get_rep_availability description: Gets the current workload and availability of all sales reps. parameters: type: object properties: region: type: string enum: [EMEA, APAC, AMER] description: The geographic region to filter reps by. - name: scoring_engine_calculate description: Calculates the final lead score using the official scoring algorithm. parameters: type: object properties: firmographic_data: type: object description: Data about the company (size, industry, etc.). engagement_data: type: object description: Data about the leads interaction (traffic, email, social). # 定义 agent 的“护栏”防止越界行为 guardrails: # 禁止 agent 直接访问互联网所有数据必须通过定义好的工具获取 disallowed_actions: - web_search - http_request # 限制单次 session 的最大工具调用次数防死循环 max_tool_calls_per_session: 15 # 强制要求所有输出必须是 JSON 格式便于下游系统解析 output_format: json # 定义 agent 的“记忆”策略告诉 harness 如何从 session log 中提取上下文 context_strategy: # 只保留最近 5 条事件避免上下文爆炸 recent_events: 5 # 必须包含的事件类型确保关键信息不被遗漏 required_event_types: [user_message, hubspot_get_lead, scoring_engine_calculate]这个 YAML 文件就是 agent 的“源代码”。它不包含任何一行 Python 或 JavaScript却完整定义了 agent 的能力边界、行为逻辑和安全策略。Anthropic 的后台服务会将其编译成一个可执行的 harness 镜像并为其自动配置好对应的 sandbox 环境。开发者无需关心 Dockerfile 怎么写、Kubernetes Deployment 怎么配、TLS 证书怎么管理。你提交 YAMLAnthropic 负责把它变成一个在云端稳定运行的服务。注意context_strategy是一个极易被忽视但至关重要的配置。它直接决定了 agent 的“认知效率”。设置recent_events: 5是经过大量 A/B 测试后的经验值。太少如 2agent 会频繁丢失关键上下文太多如 20则会导致每次推理的 token 开销剧增且引入大量噪声。我们曾在一个客服 agent 上测试过recent_events: 10结果发现 p95 延迟上升了 40%而准确率仅提升了 0.3%性价比极低。3.2 Pricing 模型的精妙设计$0.08/小时背后的商业逻辑Managed Agents 的定价结构是其商业策略的集中体现项目定价说明Session Runtime$0.08 / hour (active)仅在 agent 处于“活跃”状态时计费。当 agent 等待用户输入、或处于工具调用的 I/O 等待期时不计费。这是对传统“always-on” serverless 模型的重大优化。Claude Token Fees按标准 rate与直接调用 Claude API 完全一致无溢价。Tool Execution免费所有通过 Anthropic 沙箱执行的工具调用不额外收费。这极大地降低了集成成本。Session Storage Query免费首 10GB/月事件日志的存储和查询是基础服务不单独收费鼓励用户充分使用可观测性。这个定价模型的精妙之处在于它完美地将 Anthropic 的核心利益token 消费与客户的实际价值agent 的运行时长绑定在一起。对于一个高频、短时的 agent如实时客服机器人$0.08/小时的成本微乎其微客户主要为 token 付费而对于一个低频、长时的 agent如每周运行一次的财务报告生成器虽然 runtime 费用几乎为零但它每次运行都需要消耗大量 tokens 来处理海量数据。无论哪种场景Anthropic 都稳稳地抓住了收入来源。更重要的是这个定价对中小团队极其友好。一个初创公司用 Managed Agents 搭建一个内部知识库问答 agent每天处理 100 个问题平均每次 session 持续 90 秒那么一个月的 runtime 费用仅为100 * 90 / 3600 * 30 * $0.08 ≈ $6。这笔钱买来的不仅是技术更是省下了至少 2 周的 DevOps 工作量——你不用再纠结如何搭建一个高可用的事件存储、如何设计一个安全的沙箱、如何实现 session 的持久化与恢复。这笔账任何一个经历过 agent 基础设施自研的工程师心里都有一杆秤。3.3 与 Notion、Rakuten 等早期采用者的集成模式Anthropic 的官方案例中Notion 和 Rakuten 是两个极具代表性的客户。它们的集成方式揭示了 Managed Agents 最典型的两种落地路径Notion 的“Workspace Agent”模式Notion 并没有将 Managed Agents 当作一个独立的 SaaS 产品来卖而是将其深度嵌入到自己的产品矩阵中。当你在 Notion 页面里点击“Ask Claude”背后发生的是Notion 前端捕获你的问题并生成一个唯一的sessionId。Notion 后端调用 Anthropic 的 Managed Agents API传入sessionId和你的问题文本。Anthropic 的 harness 启动从 Notion 的 API 获取当前页面的全部内容作为hubspot_get_lead类似的工具并将其作为上下文的一部分。Agent 进行推理生成回答并将整个过程包括它读取了哪些 block、调用了哪些 API记录为事件日志。Notion 前端从 Anthropic 的事件日志 API 中拉取最终的model_output事件渲染成富文本回复。这种模式的关键在于agent 的“上下文”完全由 Notion 提供而非用户输入。它把 agent 变成了一个“页面智能体”其能力边界由 Notion 的数据权限模型严格定义。这极大降低了安全风险也使得 agent 的行为高度可预测。Rakuten 的“跨平台 Agent 网关”模式Rakuten 的需求更为复杂。他们需要在 Slack、Microsoft Teams、甚至内部 CRM 系统中提供统一的销售、营销、财务 agent 服务。他们的架构是[Slack] -- [Rakuten Agent Gateway] -- [Anthropic Managed Agents] [Teams] -- [Rakuten Agent Gateway] -- [Anthropic Managed Agents] [CRM] -- [Rakuten Agent Gateway] -- [Anthropic Managed Agents]这个 Gateway 是 Rakuten 自研的核心中间件。它负责协议转换将 Slack 的slash command、Teams 的message extension、CRM 的webhook统一转换为 Anthropic 的executeAPI 调用格式。会话路由根据用户身份、所在频道、消息关键词将请求路由到不同的agentId如sales-agent-v2,marketing-campaign-analyzer。结果渲染将 Anthropic 返回的纯文本model_output结合 Slack/Teams 的 rich message API渲染成带有按钮、卡片、进度条的交互式消息。Rakuten 的模式证明了 Managed Agents 的“框架无关性”。它不是一个封闭的生态而是一个开放的、可插拔的执行引擎。你可以用它来驱动任何你已有的前端、任何你已有的数据源。它的价值不在于它自己有多强大而在于它如何赋能你已有的系统。4. 竞争格局全景扫描为什么说 Anthropic 是在“防守”而非“开创”4.1 AWS Bedrock AgentCore那个被所有人忽略的“ incumbent”当媒体都在报道 Anthropic 的“重磅发布”时一个关键事实被集体忽略了AWS Bedrock AgentCore 已经在 2025 年底进入通用可用GA阶段并且在 2026 年 3 月其 SDK 下载量已突破 200 万次。这不是一个实验室玩具而是一个已经被数以万计的开发者和企业验证过的、生产就绪的平台。AgentCore 的架构哲学与 Managed Agents 高度相似但在工程实现上走得更远微虚拟机microVM沙箱每个 session 都运行在一个独立的 Firecracker microVM 中。这意味着 CPU、内存、网络、文件系统全部是硬件级隔离。这比 Anthropic 基于容器的沙箱在安全性和性能隔离上高出一个数量级。Firecracker 是 AWS 为 Lambda 设计的专为“短时、无状态、高密度”负载优化启动时间 125ms内存开销 5MB。八小时超长会话AgentCore 的 session 生命周期上限是 8 小时远超 Managed Agents 的默认限制官方文档未明确但实测约 2 小时。这对于需要长时间运行的复杂工作流如自动化 ETL、批量数据清洗至关重要。绝对的框架中立性AgentCore 不要求你用 YAML 定义 agent。它只提供一个标准化的invoke_agentAPI。你可以用 LangGraph 编排一个复杂的有向无环图DAG工作流可以用 CrewAI 创建一个 multi-agent 协作团队甚至可以用最原始的 Python 脚本只要它能响应{input: ..., session_id: ...}并返回{output: ...}。这种“不设限”的开放性是吸引开发者生态的根本。实操心得我们在一个客户项目中同时接入了 Managed Agents 和 AgentCore。对于简单的、单步的问答任务两者性能差异不大。但当我们测试一个需要 5 次工具调用、涉及 3 个不同数据源、总耗时约 4 分钟的复杂分析任务时AgentCore 的 p95 延迟稳定在 2.1 秒而 Managed Agents 则波动在 3.8-5.2 秒之间。这个差距源于 microVM 的启动和销毁开销远低于容器的冷启动。4.2 Google Vertex AI Agent Builder 与 Microsoft Azure AI Foundry巨头的“全家桶”策略Google 和 Microsoft 的策略则是典型的“生态捆绑”。它们不追求在 runtime 层做到极致而是将其作为自家 AI 云平台的一个“连接器”目标是把你更深地锁进它们的生态系统。Vertex AI Agent Builder的核心是Agent Registry。它不是一个独立的托管服务而是一个与 Google Cloud 的 Apigee API 网关深度集成的注册中心。当你在 Vertex 上创建一个 agent它会自动生成一个符合 OpenAPI 规范的 RESTful endpoint并自动注册到 Apigee。这意味着你可以用 Apigee 的全套企业级能力来管理它流量控制rate limiting、身份认证OAuth2, IAM、审计日志、甚至 A/B 测试。它的优势在于如果你的企业已经在用 Google Cloud 的 API 管理方案那么接入 Vertex Agent 就像添加一个新的 API 服务一样简单。它的劣势也很明显如果你想把它部署到 AWS 或 Azure 上几乎不可能。Azure AI Foundry则是微软的“大熔炉”。它把 AutoGen微软开源的 multi-agent 框架和 Semantic Kernel微软的 LLM 应用开发 SDK这两个明星项目直接整合进了 Azure 的 AI 平台。Foundry 提供的不是一个 runtime而是一个“开发-部署-运维”一体化的 IDE。你可以在 VS Code 里用 AutoGen 的 Python DSL 编写 agent一键部署到 Foundry然后在 Azure Portal 里看到它的实时 trace、cost breakdown、甚至可以直接在 UI 里编辑它的 system prompt 并热更新。这是一种“所见即所得”的开发体验对开发者极其友好但代价是高度的平台锁定。这三家巨头AWS、GCP、Azure的共同点是它们的 agent runtime都不是一个需要单独采购的“产品”而是你购买其云服务EC2、Compute Engine、VM时附赠的“能力”。你为计算资源付费runtime 就是其中的一部分。这使得它们的定价天然具有“零成本”的心理暗示。当一个 CTO 看到 AWS 的报价单上写着 “$0.00 for AgentCore runtime”而 Anthropic 的报价单上写着 “$0.08/hour”即使后者在技术上更优前者在采购决策上也拥有压倒性的优势。这就是所谓的“hyperscaler tax”——你为云厂商的规模效应买单而它们则用这个效应来免费提供上层的抽象。4.3 开源世界的暗流Daytona、K8s SIG、Deer-flow 的崛起在巨头们用“免费”构筑护城河的同时开源世界也在酝酿一场静默的革命。这些项目不追求成为下一个 AWS而是致力于成为“下一代 agent 基础设施的 Linux 内核”。Daytona是其中最耀眼的新星。它最初是一个面向开发者的本地 dev environment 工具但在 2025 年初它宣布全面转向 AI agent infrastructure。其核心竞争力是sub-90ms 的沙箱启动时间。它没有使用 Firecracker 或容器而是基于 WebAssemblyWasm构建了一个全新的、轻量级的执行环境。Wasm 模块的加载和初始化比启动一个容器快一个数量级。这意味着一个需要频繁调用多个工具的 agent其整体延迟将大幅降低。Daytona 的商业模式也很清晰提供开源的 Wasm runtime而将企业级的监控、治理、多租户管理等功能作为商业版Pro出售。Kubernetes SIG Agent Sandbox项目则代表了云原生社区的官方意志。它不是一个具体的实现而是一套标准化的 CRDCustom Resource Definition和 Operator。它定义了什么是AgentSandbox、什么是AgentSession、什么是ToolBinding。任何云厂商、任何开源项目只要实现了这套标准就能无缝地与 Kubernetes 生态集成。这就像当年的 CNIContainer Network Interface标准让 Flannel、Calico、Cilium 等网络插件可以自由竞争。它的目标是让 agent runtime 成为 Kubernetes 的一个“一等公民”就像 Pod、Service、Ingress 一样。Deer-flowByteDance 开源则代表了另一种思路将 agent 的“规划”planning和“执行”execution彻底分离。它不是一个 runtime而是一个“agent 操作系统”。它内置了一个强大的 planner可以根据目标自动生成一个 subagent 的 DAG然后将每个 subagent 的任务分发给不同的、可能是异构的 runtime可以是 Anthropic 的也可以是 AWS 的甚至是本地的 Ollama。它把 agent 从一个“单线程脚本”变成了一个“分布式操作系统”。它的 GitHub Stars 数量59,000证明了开发者对这种范式的强烈认同。这股开源力量的意义在于它正在为整个行业建立一个“事实标准”。当 Daytona 的 Wasm 沙箱、K8s SIG 的 CRD、Deer-flow 的 planner都成为开发者默认的选择时Anthropic、AWS、Google 的 proprietary runtime就不再是“唯一解”而只是“一个选项”。这正是 VMware 当年所面临的局面——当 KVM 和 Xen 成为主流时ESX 的技术优势就再也无法转化为市场优势。5. 价值迁移当 runtime 归零钱会流向哪三个地方5.1 第一层Trace Store —— AI 时代的“系统日志”与“法律证据”当 runtime 层变得像水电一样廉价和普遍第一个获得巨大价值的必然是Trace Store追踪存储。它不再是一个可有可无的 debug 工具而是整个 AI 应用的“真相之源”Source of Truth。想象一下一个金融风控 agent 批准了一笔 500 万美元的贷款三天后该客户违约。监管机构介入调查他们要问的第一个问题不是“你们的模型准不准”而是“这个决定是如何一步一步做出来的” 他们需要看到完整的、不可篡改的事件日志[t0] user_message: Approve loan for Acme Corp→[t120] tool_use: credit_bureau_check with params {id: ACME-123}→[t125] model_output: Score: 78.2, Recommendation: APPROVE→[t126] tool_use: send_approval_email with params {to: ceoacme.com}。这份日志就是一份法律意义上的“操作记录”它必须满足 ACID 特性必须支持长期归档必须能通过第三方审计。目前这个领域已经形成了三足鼎立的格局Braintrust 的 Brainstore一个专门为 AI 交互日志设计的 OLAP 数据库。它不是简单的日志聚合而是内置了针对model_output、tool_input、tool_output的专用索引和向量搜索能力。你可以直接用 SQL 查询“找出所有在scoring_engine_calculate工具返回score 50后agent 仍然做出APPROVE决定的 session”并立刻得到结果。它的商业化路径很清晰开源核心引擎对高级的合规报告、GDPR 数据擦除、实时异常检测等模块收费。Arize 的 Phoenix走的是“开源先行”路线。Phoenix 是一个 Apache 2.0 许可的、轻量级的 trace 收集和可视化工具。它最大的优势是“零摩擦接入”。你只需要在你的 agent 代码里加几行phoenix.trace(...)它就能自动捕获所有事件。Arize 的商业产品则是在 Phoenix 之上构建了一个企业级的 observability 平台提供 SLA 监控、根因分析RCA、A/B 测试对比等高级功能。它的策略是用免费的 Phoenix 锁定开发者心智再用付费的平台收割企业客户。LangSmith这是 LangChain 生态的“亲儿子”。它最大的护城河是“预装”。任何使用 LangChain 的开发者在安装langchain包时LangSmith 的 SDK 就已经随包一起下载了。它不需要你额外配置开箱即用。它的价值在于它已经成为了 LangChain 社区的事实标准。当一个开发者想分享一个 agent 的 trace 用于 debug 时他默认就会用 LangSmith 的 share link。这种“生态绑定”是 Brainstore 和 Phoenix 难以撼动的。这三个项目的竞争焦点已经不再是“谁的 dashboard 更好看”而是“谁的 trace 数据能在 runtime 迁移时无缝地跟着走”。如果一个企业今天用 Anthropic Managed Agents明天想迁移到 AWS AgentCore那么它的 trace 数据能否不经过任何转换直接导入到新的平台谁能解决这个“trace portability”问题谁就拥有了整个 AI 应用生命周期的“数据主权”。5.2 第二层Governance Policy —— AI 时代的“防火墙”与“公司章程”当 agent 可以自主调用 API、修改数据库、甚至发起资金转账时“它能不能做”就变成了一个严肃的治理问题。这催生了Governance and Policy这一全新品类。AWS AgentCore 在 2026 年 3 月 GA 的“Policy Controls”就是一个标志性事件。它允许管理员用类似 IAM 的 JSON 策略语言来定义 agent 的权限{ Version: 2012-10-17, Statement: [ { Effect: Allow, Action: bedrock:InvokeModel, Resource: arn:aws:bedrock:us-east-1::model/anthropic.claude-3-5-sonnet-20240620-v1:0 }, { Effect: Deny, Action: s3:GetObject, Resource: arn:aws:s3:::prod-financial-data/* } ] }这个策略的意思是“允许这个 agent 调用 Claude 3.5 模型但禁止它读取prod-financial-data这个 S3 存储桶里的任何文件。” 这种细粒度的、基于资源的访问控制RBAC是保障企业数据安全的生命线。然而这仅仅是开始。真正的挑战在于如何将这些静态的策略与动态的、上下文相关的业务规则结合起来。例如一个客服 agent在处理普通用户的咨询时可以访问customer_basic_info表但当它识别到用户正在投诉一个高价值的 VIP 客户时它应该被自动提升权限允许访问vip_service_history表。这就需要一个更上层的、能够理解业务语义的“policy engine”。OWASP Agentic Top 10 的发布正是这一需求的集中体现。它列出了 agent 应用最危险的十大安全风险如“LLM Injection”、“Prompt Leakage”、“Insecure Tool Integration”等。每一个风险项都对应着一系列需要被强制执行的治理策略。目前市场上还没有一个成熟的、开箱即用的“Agentic Governance Platform”。这是一个巨大的空白也是一个千载难逢的机会。谁能率先提供一套既能满足 OWASP 合规要求又能与现有 CI/CD 流水线如 Jenkins, GitHub Actions无缝集成的 policy-as-code 工具谁就能成为 AI 时代的“Palo Alto Networks”。5.3 第三层Vertical Agent Marketplaces —— AI 时代的“App Store”当底层的 runtime 和基础设施都变得廉价和同质化时最终的竞争一定会回归到价值交付本身。而价值永远是垂直的、具体的、可衡量的。Salesforce 的 Agentforce ARR 达到 8 亿美元这个数字之所以震撼是因为它证明了企业愿意为一个“能解决具体问题”的 agent 付费而不是为一个“能运行 agent”的平台付费。Agentforce 的成功不在于它用了多先进的 runtime而在于它把一个复杂的、需要多个系统集成的“销售线索分配”流程封装成了一个开箱即用的、与 Salesforce CRM 深度集成的“app”。销售经理不需要懂 YAML不需要配沙箱他只需要在 AppExchange 上点击“Install”然后设置几个规则这个 agent 就开始为他工作了。这种模式正在各个垂直领域快速复制Financevirattt/ai-hedge-fund是一个开源的、用于量化交易研究的 agent。它可以自动爬取 SEC 的 10-K 文件用 LLM 解析其中的财务风险陈述再调用 Yahoo Finance API 获取股价数据最后生成一份结构化的投资备忘录。它的价值不在于它用了什么 runtime而在于它把一个需要金融分析师花 3 小时才能完成的工作压缩到了 3 分钟。Securityvxcontrol/pentagi是一个用于渗透测试的 agent。它可以自动扫描一个网站识别出潜在的漏洞如 SQLi、XSS然后调用一个专门的 exploit 工具