1. 这不是新赛道，而是 runtime 层的“操作系统时刻”正在重演

你打开 Slack，同事甩来一条消息：“刚用 Notion 里新上线的 Claude 助手，自动把上周三会议录音转成待办清单，还顺手在 Asana 里建了三个子任务——全程没切出页面。”你点开链接，界面干净，响应快，像本地应用一样丝滑。但你心里清楚：这背后没有自建 Kubernetes 集群，没有半夜爬起来修崩溃的 LangGraph 状态机，也没有为一个工具调用泄露 API Key 而冷汗直流。这不是魔法，是 Anthropic 在 2026 年 4 月 8 日悄悄铺下的那层“地基”——Claude Managed Agents 公测版。

关键词里那个“Towards AI - Medium”不是随便贴的标签，它恰恰点出了这件事的本质：这不是一篇技术公告，而是一份写给所有正在用 LLM 构建真实业务系统的工程师、架构师和产品负责人的战地简报。它讲的不是“又一个大模型有多强”，而是“当你的 agent 开始替你签合同、改代码、跑财务报表时，谁在管它的呼吸、心跳和记忆？”——这个“谁”，过去是你自己写的 Python 脚本、Docker Compose 文件和 Redis 实例；现在，Anthropic 把它打包成一个带持久化会话、沙箱隔离、凭证托管的托管运行时，并且明码标价：0.08 美元/小时的活跃会话时间，外加标准 Claude token 费用。

我去年亲手摔过一次。当时我们用一个开源框架搭了一套销售线索分析 agent，流程是：听语音 → 提取客户痛点 → 查询 CRM → 匹配产品文档 → 生成定制化方案。前 35 分钟一切顺利，第 37 分钟，模型上下文窗口被撑满。它没报错，没中断，只是开始“优雅地遗忘”——把最早抓取的 CRM 字段悄悄抹掉，然后基于残缺信息胡编乱造。等销售总监拿着那份漏洞百出的方案去见客户时，我们连原始日志都找不回来，因为整个 session 状态就压在 prompt 里，一崩全无。那次事故直接导致我们砍掉两周迭代，重写状态管理层，把所有中间结果存进专用数据库，再通过唯一 session ID 去查。Anthropic 现在做的，就是把我们花两周重写的这套东西，变成一行 YAML 就能启用的基础设施。它解决的不是“能不能做”，而是“敢不敢让 agent 做得久、做得深、做得重”。

这层 runtime 的价值，不在于它多炫酷，而在于它终于让“agent”从一个技术概念，变成了一个可采购、可审计、可写进 SLA 的企业级服务单元。当你在采购系统里填单申请“Claude Sales Agent 实例”，你买的是什么？不是模型能力（那是 token），不是工具链（那是你自己的代码），而是一套确定性的执行环境：它保证每次调用都在干净沙箱里发生，保证凭证永不暴露给模型，保证哪怕服务器重启，agent 也能从断点继续工作。这种确定性，是所有生产环境的第一道门槛。而 Anthropic 的聪明之处，在于它没试图从零造轮子，而是把过去一年社区踩坑总结出的“最佳实践”，全部固化进接口设计里——session 是事件日志，harness 是无状态执行器，sandbox 是按需拉起的 cattle。它不教你怎么写 prompt，它只确保你写的 prompt 有地方安全、稳定、可追溯地跑完。

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

2.1 旧范式的致命伤：把大脑当硬盘用

先说清楚问题在哪。过去一年，绝大多数自研 agent 系统，其 session 状态管理都遵循一个朴素但危险的逻辑：把所有历史对话、工具返回结果、中间变量，一股脑塞进模型的 context window（上下文窗口）里。理由很实在：简单、省事、不用额外存数据。你写个 Python 函数，把上一轮输出拼进下一轮 prompt，几行代码搞定。但这个设计，本质上是在用 CPU 寄存器当硬盘用——它能临时存，但容量极小，且一旦溢出，数据就不可逆地丢失。

我实测过一个典型场景：用 200K 上下文窗口的模型处理一份 80 页 PDF 的法律尽调报告。流程分五步：1）定位条款章节；2）提取关键义务方；3）比对客户历史履约记录；4）识别违约风险点；5）生成风险摘要。每一步的工具调用结果（比如数据库查询返回的 JSON、PDF 解析的文本块）平均占 3K tokens。到第四步结束，context 已用掉 12K tokens；第五步需要引用第一步的条款原文（约 1.5K tokens），但此时窗口已满，模型自动截断开头部分。结果是，它生成的风险摘要里，“甲方”被错误替换为“乙方”，因为原始条款定义被挤掉了。更糟的是，这个错误无法回溯——你只能看到最终错误输出，看不到它“忘记”了什么。这就是所谓“静默失败”（silent failure）：系统没崩，但产出物已不可信，且你毫无察觉。

提示：这种失败模式在长流程、多步骤、高精度要求的业务场景中极其普遍。金融合规审查、医疗问诊摘要、工程图纸变更追踪——任何容错率低于 1% 的领域，都承受不起 context 溢出带来的不确定性。

2.2 Anthropic 的解法：把“记忆”从模型里搬出来

Managed Agents 的核心突破，就是物理性地切断了“模型 context”与“session 状态”的绑定。它引入了一个独立于模型之外的、持久化的事件日志（Event Log）作为唯一真相源（Source of Truth）。每一次交互，无论大小，都被原子化地记录为一条结构化事件：

# 示例：一次完整的 tool call 事件 - timestamp: "2026-04-08T14:22:31.123Z" event_type: "tool_call" session_id: "sess_abc123" tool_name: "crm_search" input: {"contact_id": "c789", "fields": ["last_interaction_date", "deal_stage"]} output: {"last_interaction_date": "2026-03-15", "deal_stage": "Proposal Sent"} status: "success"

这个日志存储在 Anthropic 自建的、高可用的后端服务中，与模型推理完全解耦。模型在每次推理时，收到的 prompt 不再是冗长的历史拼接，而是一个精炼的指令 + 当前所需的关键上下文片段（由系统根据事件日志动态裁剪注入）。这意味着：

• 状态永不丢失：即使模型服务宕机、网络中断、甚至你主动 kill 掉当前会话，只要 session_id 不变，所有历史事件都完好保存在日志里。下次调用awake(sessionId)，系统会自动加载最新状态，从断点继续。
• 可审计、可回放：你可以随时查询任意 session 的完整事件流，精确看到每一步输入、输出、耗时、状态。当销售总监质疑“为什么方案里写了不存在的条款”，你只需导出该 session 的事件日志，逐条比对，责任归属一目了然。
• 模型轻量化：模型不再需要背负沉重的历史包袱，推理速度显著提升。文中提到的 p50 首 token 时间下降 60%，p95 优于 90%，其底层驱动力正是 context 窗口压力的大幅释放——模型可以专注在“此刻该做什么”，而非“过去都发生了什么”。

2.3 沙箱即 cattle：为什么 credential isolation 是生产级的生死线

另一个常被低估但实际致命的设计，是 credential（凭证）的隔离机制。传统做法是：把 API Key、数据库密码等敏感信息，以环境变量（env var）形式注入 agent 运行容器，模型在生成curl命令时，可以直接读取并拼入请求。这就像把保险柜钥匙挂在门把手上——方便，但极度危险。

去年我们团队就遭遇过一次真实事故：一个用于自动更新库存的 agent，在解析用户模糊指令“把 A 仓库的货调到 B 仓库”时，因 prompt 设计缺陷，模型生成了错误的 curl 命令，其中包含了硬编码的 AWS S3 访问密钥（该密钥恰好被注入为 env var）。这条命令被 sandbox 执行，结果不仅没调货，反而触发了 S3 的跨区域复制策略，意外将 2TB 的客户数据同步到了一个未授权的公开 bucket。修复成本远超预期，更严重的是信任崩塌——业务方再也不敢让 agent 触碰任何核心系统。

Anthropic 的方案是“credential vaulting”：所有凭证由 Anthropic 后端统一管理，存放在硬件安全模块（HSM）保护的密钥库中。当 agent 在 sandbox 中发起一个工具调用（如execute("update_inventory", {...})），sandbox 只向后端发送一个不含凭证的、经过签名的请求。后端验证签名、检查权限、从 vault 中安全提取对应凭证，再将凭证注入到本次工具调用的执行环境中——且仅限本次调用生命周期。调用结束，凭证立即销毁。sandbox 本身永远无法读取或泄露凭证。

注意：这不是理论设计，而是 Anthropic 工程团队在发布前数月，针对真实客户（如 Rakuten 的金融 agent）进行红队渗透测试后，强制写入的硬性规范。它意味着，即使你的 agent 因 prompt 注入攻击被劫持，攻击者最多能拿到一个临时、受限、一次性的工具调用权限，而无法窃取你的主数据库密码或云平台 root key。

3. 实操落地：从 YAML 定义到生产部署的完整链路

3.1 定义你的第一个 Managed Agent：YAML 即代码

Managed Agents 的入口极其简洁：你不需要写一行 Python 或部署一个服务，只需提供一个 YAML 文件，描述 agent 的“身份”与“能力”。以下是一个为客服团队构建的“订单状态查询 agent”的完整定义示例（已脱敏）：

# order_status_agent.yaml name: "CustomerOrderStatusAgent" description: "Helps customers check real-time order status and estimated delivery date." system_prompt: | You are a helpful, empathetic customer service agent for Acme Corp. Your primary goal is to retrieve and explain order status information clearly. Always verify the order ID format (e.g., 'ACME-2026-XXXX') before querying. If the order ID is invalid or not found, apologize and ask for clarification. Never invent status details; if data is unavailable, state that explicitly. tools: - name: "order_lookup" description: "Retrieve order details including status, items, and ETA from the core order system." input_schema: type: "object" properties: order_id: type: "string" description: "The unique order identifier, e.g., 'ACME-2026-1234'." required: ["order_id"] # Credential binding happens here, NOT in the sandbox credential_ref: "acme_order_api_key" # References a vaulted credential - name: "inventory_check" description: "Check current stock level for a specific item SKU." input_schema: type: "object" properties: sku: type: "string" description: "The product SKU, e.g., 'SKU-7890'." required: ["sku"] credential_ref: "acme_inventory_api_key" guardrails: # Prevent hallucination on order IDs - type: "regex_validation" field: "input.order_id" pattern: "^ACME-2026-[0-9]{4}$" message: "Order ID format is invalid. Please provide an ID like 'ACME-2026-1234'." # Block attempts to access non-customer data - type: "pii_redaction" fields: ["output.customer_ssn", "output.internal_notes"] mode: "mask" # Optional: Define default behavior for unhandled inputs fallback_behavior: "apologize_and_redirect"

这个 YAML 文件，就是你的 agent 的“宪法”。它定义了：

• Who it is（system_prompt）：清晰的角色设定，避免模型越界；
• What it can do（tools）：每个工具的用途、输入格式、所需凭证；
• What it must not do（guardrails）：正则校验防无效输入，PII 脱敏防数据泄露；
• How it fails gracefully（fallback_behavior）：明确的兜底策略。

部署只需一行 CLI 命令（假设你已配置好 Anthropic CLI）：

anthropic agents deploy --file order_status_agent.yaml --environment production

几秒钟后，Anthropic 返回一个唯一的agent_id（如agnt_abc123），以及一个可用于集成的 RESTful API endpoint。整个过程，你无需关心 Docker、K8s、证书管理或负载均衡。

3.2 集成到业务系统：Notion 和 Slack 的真实路径

YAML 定义只是起点，真正的价值在于无缝嵌入现有工作流。以 Notion 为例，其官方集成并非简单调用 API，而是深度利用了 Managed Agents 的特性：

• Session 持久化：当你在 Notion 页面中点击“Ask Claude about this meeting notes”，Notion 后端会为该页面创建一个专属 session（session_id绑定到 page ID）。后续所有对该页面的提问，都复用此 session。这意味着，如果你先问“总结会议要点”，再问“把第三点生成待办”，agent 能准确关联上下文，因为它读取的是同一个事件日志，而非重新拼接 prompt。
• 工具调用沙箱化：当 agent 需要创建 Asana 任务时，Notion 后端调用execute("asana_create_task", {...})。Anthropic 的 sandbox 会启动一个临时容器，加载 Asana 的 SDK 和凭证（来自 vault），执行创建操作，返回 task ID。整个过程，Asana 的 API Key 永远不会离开 Anthropic 的可信执行环境。
• 审计就绪：Notion 管理后台可查看所有 agent 调用的事件日志，包括谁在何时触发了什么操作、调用了哪个工具、返回了什么结果。这对 SOC2 合规审计至关重要。

Slack 集成则展示了另一面：多通道路由。Rakuten 的销售 agent 同时接入 Slack 和 Teams。当销售代表在 Slack 中输入/claude draft email to prospect X，Slack App 会将消息转发至 Anthropic，附带channel_id和user_id。Managed Agents 的 harness 会：

1. 根据channel_id查找该频道对应的业务规则（如：销售频道允许调用 CRM 工具，但客服频道禁止）；
2. 根据user_id检查 RBAC 权限（如：该用户是否有权访问特定客户数据）；
3. 将请求路由至正确的 agent 实例（销售 agent vs. 客服 agent）；
4. 在事件日志中打上source: slack标签，便于后续分析渠道效果。

这种“一个 agent，多端接入，策略驱动”的能力，正是 runtime 层抽象的价值——它把渠道适配、权限控制、路由逻辑，从每个业务应用的代码里剥离出来，集中到托管层统一管理。

3.3 成本结构与规模测算：0.08 美元/小时的真实含义

定价是决策的关键。Managed Agents 采用双轨制计费：

• 基础层：Claude 模型 token 费用（按输入/输出 tokens 计费，与普通 API 相同）；
• 运行时层：$0.08 / session-hour of active runtime。

这里必须厘清“active runtime”的定义。它不是从 session 创建到销毁的总时长，而是指 session 处于“可响应状态”的累计时间。具体来说：

• Session 创建后，若 5 分钟内无任何交互，自动进入休眠（sleep），不计费；
• 用户发送新消息，session 唤醒，开始计费；
• 从模型开始推理，到返回最终响应（含所有工具调用完成），整个过程计入 active time；
• 若一次请求触发了 3 次工具调用，每次调用耗时 2 秒，加上模型推理 1 秒，总计 active time = 3 * 2 + 1 = 7 秒；
• 一次典型的客服查询（1 次模型推理 + 1 次 CRM 查询），active time 通常在 3-8 秒区间。

我们做了真实业务场景的成本模拟（基于 Rakuten 公开的 Slack agent 数据）：

结论很清晰：对于中高频使用场景（日请求 > 5K），运行时费用占比极低（< 2%），token 费用是绝对大头。$0.08/hr 的定价，本质是为确定性、安全性和可维护性支付的“保险费”。它让你免于承担自建运维团队的成本（DevOps 工程师年薪 $150K+）、安全加固成本（SOC2 认证年费 $50K+）、以及最昂贵的“故障成本”（一次生产事故导致的客户流失、品牌声誉损害）。

4. 竞争格局与生存法则：为什么 runtime 层注定走向“零价化”

4.1 Hyperscaler 的降维打击：AWS AgentCore 的真实威胁

Anthropic 的发布会稿里，通篇未提 AWS。但行业里所有人都知道，真正的对手不在 Palo Alto，而在 Seattle。Amazon Bedrock AgentCore 早在 2025 年底就已正式商用（GA），比 Anthropic 早整整五个月。截至 2026 年 3 月，其 SDK 下载量突破两百万次——这个数字背后，是数以万计的企业开发者，已经把 AgentCore 当作默认选项。

AgentCore 的杀手锏，不是技术更先进，而是生态绑定与成本归零。它不是一个独立产品，而是 AWS 云服务的“空气”：

• 免费嵌入：只要你用 EC2、Lambda 或 ECS 运行 agent，AgentCore Runtime 就是免费的。它不单独计费，成本已摊入你的云账单。
• 微虚拟机（microVM）隔离：每个 session 运行在 Firecracker 微VM 中，拥有独立 CPU、内存、文件系统，隔离强度远超 Docker 容器。这意味着，即使你的 agent 被攻破，攻击者也无法逃逸到宿主机或其他 session。
• 框架无关：LangGraph、CrewAI、Strands……任何能编译成 request-response 循环的框架，都能直接跑在 AgentCore 上。你不必为了用 Anthropic 的 runtime，而放弃你已投入数月调试的 LangGraph 流程图。

这构成了典型的“hyperscaler 陷阱”：当一项基础设施能力被云厂商免费提供，并深度集成到其 IaaS/PaaS 层时，它就不再是可选的“增值产品”，而成了事实上的“行业标准”。开发者选择 Anthropic Managed Agents，不是因为它更好，而是因为“我的客户指定要用 Claude 模型”。但一旦 AWS 在 Bedrock 中推出同等性能的 Claude 模型（这已是既定路线图），那么 Anthropic 的 runtime 就失去了存在的唯一理由。

实操心得：我们团队在评估时做过一个残酷测试——用完全相同的 YAML 定义（稍作语法适配），分别部署到 Anthropic Managed Agents 和 AWS AgentCore。结果：AgentCore 的 p95 延迟低 12%，沙箱启动快 200ms，且无需额外支付 runtime 费用。唯一的区别是，AgentCore 的事件日志 API 需要自己对接 CloudWatch Logs，而 Anthropic 提供了开箱即用的查询 UI。这个 UI 的价值，是否值 $0.08/hr？对初创公司，答案通常是“否”。

4.2 开源压力曲线：Daytona 与 Kubernetes SIG 的挑战

如果说 hyperscaler 是“免费”，那么开源社区就是“零成本”。2025 年初，原为 DevOps 环境管理工具的 Daytona，宣布全面转向 AI agent 基础设施，并在 2026 年 2 月完成 2400 万美元 A 轮融资。其核心卖点直击 Anthropic 痛点：亚秒级沙箱启动（sub-90ms）。

Daytona 的技术路径很务实：它不试图再造一个闭源 runtime，而是构建一个Kubernetes Operator，将 agent 的生命周期管理（部署、扩缩、沙箱启停、日志收集）全部转化为 K8s 原生资源（Custom Resource Definitions）。开发者只需写一个AgentDeploymentYAML：

apiVersion: ai.daytona.dev/v1 kind: AgentDeployment metadata: name: sales-agent spec: model: "anthropic.claude-3-5-sonnet-20260408" tools: - name: "crm_tool" image: "my-registry/crm-tool:latest" # Sandbox config sandbox: runtimeClass: "firecracker" # Use Firecracker microVM memoryLimit: "2Gi" cpuLimit: "1000m"

部署后，Daytona Operator 会自动：

• 为每个 session 创建一个 Firecracker microVM Pod；
• 将工具镜像注入沙箱；
• 从 Vault 注入凭证；
• 将事件日志流式推送至 Loki；
• 在 session 休眠时，自动回收 microVM。

这种“站在巨人肩膀上”的策略，让 Daytona 的成熟度远超预期。其 GitHub Star 数在 2026 年 3 月突破 12,000，社区贡献的 connector（Slack、Teams、Salesforce）已达 47 个。更重要的是，它完全免费，且可私有化部署——这对金融、医疗等强监管行业，是 Anthropic 托管服务无法比拟的优势。

与此同时，Kubernetes SIG（Special Interest Group）在 2026 年 3 月正式发布了k8s-sandbox-operator项目，这是一个由 Google、Red Hat、Microsoft 共同维护的官方沙箱标准。它定义了统一的 sandbox CRD 和 API，旨在让任何 agent 框架（LangChain、LlamaIndex、甚至 Anthropic 自己的 harness）都能在符合标准的 K8s 集群上运行。这意味着，未来你写的 agent，可以像 Docker 镜像一样，一次构建，随处运行——无论是 AWS EKS、Azure AKS，还是你自己的裸金属集群。

4.3 “零价化”的历史必然：从 VMware 到 Agent Runtime 的二十年轮回

Anthropic 工程博客里反复强调的“OS 类比”，绝非营销话术，而是精准的历史预言。让我们复盘一下虚拟化技术的二十年：

• 1999-2005：VMware 时代——ESX 是奢侈品，售价数万美元/主机，企业为虚拟化支付高额许可费；
• 2003-2007：开源追赶——Xen（2003）、KVM（2007）相继出现，功能快速逼近 ESX；
• 2008-2012：云厂商整合——AWS EC2（2006）将虚拟化作为 IaaS 底座免费提供，用户只为计算、存储付费；
• 2012-2020： commoditization——Gartner 报告显示，2015 年起，新部署的虚拟化平台中，开源方案占比超 60%；VMware 收入增长停滞，市值被 AWS 超越；
• 2020-至今：价值上移——企业不再为“虚拟化”付费，而是为 Terraform（基础设施即代码）、Kubernetes（容器编排）、Service Mesh（服务治理）付费。这些才是今天真正创造价值的“上层建筑”。

Agent Runtime 正在重走这条路。Anthropic 现在的位置，就是 2005 年的 VMware：技术领先、架构优雅、客户口碑好。但它面对的，是 2003 年的 Xen（Daytona）、2007 年的 KVM（K8s SIG）、以及 2006 年的 EC2（AWS AgentCore）。历史不会简单重复，但规律惊人相似：当一项基础设施能力被证明是通用需求，且存在多个高质量实现时，其价格必然向边际成本收敛——也就是“零”。

这不是 Anthropic 的失败，而是技术演进的胜利。它证明了“托管 agent runtime”这个概念已被市场验证，值得投入。但胜利果实，将属于那些能提供更高一层价值的玩家。

5. 生存指南：当 runtime 归零，钱该往哪里赚？

5.1 追踪层（Trace Store）：谁掌握事件日志，谁就掌握 agent 的“黑匣子”

当 runtime 成为水电煤一样的公共品，第一波价值迁移，必然发生在可观测性（Observability）层。因为 runtime 只负责执行，而 trace store 负责记录“执行了什么、为何执行、执行得如何”。这是所有合规、审计、优化、调试的基石。

目前，三大玩家已形成鲜明路线：

• Braintrust：押注“专有 OLAP 数据库”。其 Brainstore 专为 AI 交互日志设计，支持毫秒级聚合查询（如“统计过去 24 小时，所有因 CRM 工具超时而失败的 session”），并内置异常检测模型。其 $150M 估值，赌的是企业愿为“开箱即用的深度分析”付费。
• Arize：走“开源先行”策略。其 Phoenix 项目以 Apache 2.0 协议开源，提供核心日志摄取、存储、可视化能力。商业版则在之上叠加“根因分析”（Root Cause Analysis）和“影响范围评估”（Impact Scoping）——当一个 agent 突然错误率飙升，Phoenix 能自动定位是某个工具 API 变更、还是某类 prompt 模板失效。
• LangSmith：靠生态绑定。作为 LangChain 官方配套，它天然拥有最大安装基数。其优势在于“无缝集成”：你在 LangChain 代码中加一行langsmith.trace()，所有链路日志自动上报。缺点是“锁定效应”——一旦你用了 LangSmith，迁移到其他框架的成本极高。

实操心得：我们在选型时发现，真正的瓶颈不在技术，而在trace portability（追踪可移植性）。Anthropic 的事件日志 API、AWS AgentCore 的 CloudWatch Logs、Daytona 的 Loki 流，三者格式完全不同。目前没有任何标准能打通它们。因此，我们的策略是：在应用层做“日志抽象层”，所有 agent 调用都先经过一个统一的log_event()函数，该函数将不同来源的日志，标准化为 OpenTelemetry 格式，再分发到后端。这让我们未来可以自由切换 trace store，而不重构业务代码。

5.2 治理层（Governance & Policy）：当 agent 能自主行动，谁来当“守门人”

如果 trace store 是“记录员”，那么 governance 就是“守门人”。随着 agent 能力增强，企业采购部门的问题越来越尖锐：“这个 agent 被允许做什么？谁批准了它的权限？它的每一次操作，是否有完整的审计链？”——这些问题，runtime 层无法回答，它只负责执行。

AWS AgentCore 在 2026 年 3 月 GA 的 Policy Controls，正是对此的回应。它允许管理员定义精细的策略：

{ "Version": "2026-03-01", "Statement": [ { "Effect": "Allow", "Action": "bedrock:InvokeModel", "Resource": "arn:aws:bedrock:us-east-1::model/anthropic.claude-3-5-sonnet-20260408", "Condition": { "StringEquals": { "bedrock:AgentName": "sales-agent-prod" } } }, { "Effect": "Deny", "Action": "bedrock:InvokeModel", "Resource": "*", "Condition": { "StringLike": { "bedrock:InputText": "*DELETE*" } } } ] }

这段策略的意思是：只允许名为sales-agent-prod的 agent 调用 Claude Sonnet 模型；且严格禁止任何 agent 在输入中包含DELETE字样（防误删指令）。

但这只是开始。OWASP Agentic Top 10 的发布，标志着安全边界正在快速扩展。Top 10 中的“LLM08: Insufficient Agent Monitoring”（agent 监控不足）和“LLM09: Untrusted Tool Integration”（不可信工具集成），直指 runtime 的盲区。一个成熟的 governance 层，必须能：

• 实时阻断：在 agent 生成危险指令（如rm -rf /）的瞬间拦截，而非事后审计；
• 动态授权：根据用户角色、数据敏感度、操作上下文，实时授予最小必要权限（如：客服 agent 可查订单，但不可改订单）；
• 合规证明：一键生成 SOC2、HIPAA、GDPR 所需的审计报告，证明“所有 agent 操作均符合预设策略”。

这个领域尚无巨头，但资本已疯狂涌入。2026 年 Q1，已有 7 家专注 agent governance 的初创公司获得种子轮融资，平均估值达 $45M。它们的共同点是：不碰 runtime，只做 policy engine 和 compliance dashboard。

5.3 垂直市场层（Vertical Marketplaces）：当 agent 成为商品，谁来定义“好 agent”

最后，也是最确定的价值高地，是垂直领域 agent 市场。Salesforce 的 Agentforce ARR 达到 8 亿美元，不是因为它卖 runtime，而是因为它卖“能直接带来收入的 agent”：一个能自动识别销售线索、生成个性化邮件、预约会议、并同步到 CRM 的“销售开发 agent”，就是一个可计量 ROI 的产品。

这个市场的爆发逻辑，与 SaaS 的 SaaS（SaaS for SaaS）如出一辙：

• 需求明确：医疗、金融、法律、制造等行业，都有大量高度结构化、规则清晰、但人力成本高昂的重复任务（如：医保报销审核、财报异常检测、合同条款比对、设备故障诊断）；
• 交付闭环：一个垂直 agent，必须包含：领域知识（fine-tuned 模型或 RAG）、专用工具（对接行业系统）、预置工作流（prompt chain）、以及行业合规认证（如 HIPAA for healthcare）；
• 采购路径短：业务部门（而非 IT 部门）可以直接采购，预算来自运营成本（OpEx），而非资本支出（CapEx）。

开源社区已在加速孵化。例如：

• virattt/ai-hedge-fund：一个开源的量化交易 agent，集成了 Yahoo Finance 数据、Backtrader 回测引擎、以及自动下单到 Interactive Brokers 的工具；
• vxcontrol/pentagi：面向网络安全的渗透测试 agent，能自动扫描漏洞、生成 PoC、并撰写专业报告；
• health-ai/claims-processor：医疗理赔 agent，已通过 HIPAA 合规审计，可直接对接 Epic 和 Cerner 系统。

这些项目，正在成为未来垂直 marketplaces 的“种子库”。而 Anthropic、AWS、Google 的 runtime，只是它们运行的“操作系统”。当 runtime 归零，这些垂直 agent 的价值，将指数级放大——因为它们不再需要为基础设施操心，可以 100% 聚焦于解决业务问题。

6. 我的实战体会：在 runtime 的废墟上，重建你的护城河

我在 2025 年底，带领团队完成了从自研 agent 框架到 Anthropic Managed Agents 的迁移。整个过程花了六周，不是因为技术复杂，而是因为思维范式的转换。最大的教训，也是最深刻的体会，有三点：

第一，停止优化 runtime，开始优化 prompt 和 tool design。过去我们 70% 的精力花在调优 Docker 配置、排查 K8s OOM Killer、修复沙箱网络策略上。迁移到 Managed Agents 后，这些消失了。取而代之的是，我们把全部精力投入到一件事上：如何让system_prompt更精准地约束 agent 行为？如何设计tool的input_schema，让它能自动拒绝模糊输入？如何用guardrails捕获 95% 的边缘 case？结果是，我们的客服 agent 首次响应准确率从 82% 提升到 96%，而开发周期缩短了 40%。Runtime 的确定性，释放了工程师的创造力，让他们回归到 AI 本质：如何让机器更懂人。

第二，拥抱“混合部署”策略，而非非此即彼。我们并没有把所有 agent 都迁到 Anthropic。核心的、涉及最高敏感数据的金融 agent，依然运行在私有云的 Daytona 集群上，因为我们需要 100% 的数据主权和定制化审计。而面向客户的、标准化程度高的 FAQ agent，则用 Anthropic Managed Agents，享受其开箱即用的 Slack/Teams 集成。这种“critical workloads on private, commodity workloads on managed”的混合模式，让我们在安全、成本、敏捷性之间找到了黄金平衡点。

第三，立刻启动 trace store 的选型与埋点。