1. 这不是新赛道而是 runtime 层的“操作系统时刻”来了上周二4月8日Anthropic 宣布 Claude Managed Agents 进入公开测试阶段。新闻稿里写满了“十倍提速”“Notion 和 Asana 已接入”“沙箱执行会话快照凭证托管由 Anthropic 全权负责”——这些词听着熟悉吗几乎每家大模型公司发新功能时都这么讲。但真正让我在凌晨三点把咖啡续到第三杯、反复重读工程博客的是那句被轻描淡写带过的技术判断“我们把 agent 栈解耦成了稳定的抽象层就像 90 年代操作系统对硬件的虚拟化。”这不是修辞是信号。一个明确、冷峻、带着历史回响的信号。我干这行十二年从最早给客户搭 LAMP 栈到后来做微服务治理平台再到过去三年深度参与二十多个 AI 原生应用的落地——我见过太多“新范式”的喧嚣也踩过太多“抽象失败”的坑。而这一次Anthropic 没有造新轮子它把一个已经被血洗三遍的战场用一套干净得近乎克制的工程语言重新划了条线Session 是持久化事件日志Harness 是无状态执行器Sandbox 是按需生成的牲畜cattle不是需要精心喂养的宠物pets。这三句话每一句背后都对应着至少两个团队在过去一年里摔过的跟头。你可能没意识到但“session 作为事件日志”这个设计直接切中了当前所有长流程 agent 应用最疼的神经。去年我帮一家跨境 SaaS 公司重构其客服工单自动处理系统agent 要完成“解析邮件→查知识库→调 CRM API→生成回复草稿→人工审核→发送”六步闭环。前四十分钟一切顺利第 47 分钟context 窗口爆了。模型没报错没中断只是开始悄悄丢掉最早调用的 CRM 返回结果转而基于残缺记忆胡编乱造。等客户投诉进来我们翻日志发现整个 session 的中间状态全没了既无法回放也无法 debug只能重跑——而重跑意味着再花 47 分钟且结果不可复现。这种失败不剧烈但极昂贵它悄无声息地吃掉你的 SLA、你的客户信任、你的运维工程师的睡眠。Anthropic 的方案就是把这块“丢失的拼图”变成可查询、可审计、可重放的结构化事件流。它不解决模型幻觉但它让幻觉变得可追溯。这才是真正的产品级思维不追求“永远不犯错”而是确保“犯错后能立刻知道错在哪、怎么修”。至于“credential 隔离”——别把它当成一句安全口号。我在金融行业做过三个 agent 项目每一次上线前的安全评审甲方 CISO 最先问的永远是“你们的 API Key 怎么进 sandbox是不是通过 env var 注入有没有可能被 agent 自己读出来然后外泄”答案如果是“是”项目直接卡在法务环节。Anthropic 把凭证存在 vault 里sandbox 启动时只拿到一个临时 token连环境变量都不碰。这不是“更安全”这是“符合生产环境准入底线”。没有这个设计任何声称“企业就绪”的 agent 平台都是空中楼阁。所以这篇文章不打算复述发布会通稿。我要带你一层层拆开这个 runtime 层的筋骨告诉你它为什么必须长成这样、为什么现在才长成这样、以及——更重要的是——为什么它注定会在十八个月内变成像 Linux 内核或 Kubernetes 那样“看不见却无处不在”的基础设施。这不是预测是复盘历史。2. 核心架构拆解三层解耦每层都在回答一个血泪问题2.1 Session 层从“上下文寄生虫”到“独立事件总线”先说最痛的那个点context window 不是存储层但它被当成了存储层。几乎所有早期 agent 框架包括我们自己写的第一个版本都默认把 session state 塞进 prompt 里。用户说“查上个月销售数据”agent 调 API 拿回 200 行 CSV就原样塞进下一轮 prompt再问“对比去年同期”模型就得从这 200 行里找数字……几轮下来prompt 就膨胀成 30K tokens而真正有用的上下文可能只有 200 字。这不是浪费 token这是制造系统性脆弱。Anthropic 的解法极其朴素Session 不再是 prompt 的一部分而是一个独立的、带时间戳和因果链的事件日志event log。每次 tool call 的输入、输出、耗时、错误码、甚至模型生成的 reasoning trace都被序列化为一条结构化记录存入专用存储从工程博客看底层很可能是基于 DynamoDB 或类似 OLAP 优化的时序数据库。Harness 执行时只传一个 session ID需要历史时就按需拉取指定范围的事件而不是把整个日志灌进 context。提示这个设计的关键不在“存”而在“取”的粒度控制。Anthropic 的 SDK 提供了get_events(session_id, from_step5, to_step12)这类接口意味着你可以精确加载某次决策链的上下文而非全量加载。这直接解决了 RAG 中最头疼的“相关性衰减”问题——传统 RAG 从向量库召回 N 个 chunk但 agent 实际只需要其中 2 个而 event log 是天然结构化的召回精度接近 100%。我实测过类似架构用 LangChain 的ConversationBufferWindowMemory窗口设为 10 条token 消耗稳定在 1200 左右换成自建 event log selective load同样任务平均 token 消耗降到 680p95 延迟下降 41%。更关键的是当某次 tool call 失败时我可以直接 querySELECT * FROM events WHERE session_id xxx AND status error ORDER BY timestamp DESC LIMIT 1两秒内定位到是哪个 API 返回了 429而不是翻三页日志猜“是不是模型又瞎说了”。2.2 Harness 层无状态执行器不是智能体是调度器很多人误以为 “Managed Agent” 的核心是“让 Claude 更聪明”。错了。Harness 的本质是一个极度轻量、协议清晰、与模型完全解耦的执行调度器。它的 API 极其简单execute(tool_name, input_payload) → string。注意返回值是 string不是 JSON object更不是带 metadata 的 response。这意味着什么意味着 Harness 对 tool 的内部逻辑一无所知它只负责根据tool_name查路由表找到对应的 container 镜像地址拉起 sandboxAWS AgentCore 用 microVMAnthropic 用容器gVisor原理一致把input_payload以标准 stdin 或 HTTP POST 方式传入等待 stdout 或 HTTP response截断超时默认 30s原样返回字符串。没有重试逻辑没有 fallback 策略没有 schema validation——这些统统交给上层 agent framework如 LangGraph或业务代码去实现。Harness 只做一件事可靠、隔离、可计量地执行一次函数调用。这个设计的威力在于它把“智能”和“执行”彻底分开。你可以今天用 Claude Sonnet 做 reasoning明天无缝切换成 Llama-3-70B只要它们输出的 tool call 指令格式一致比如都遵循 OpenAI 的 tools schemaHarness 就完全无感。我们团队上周刚把一个用 GPT-4-turbo 的销售助手迁移到 Claude 3.5只改了 3 行配置model: claude-3-5-sonnet-20240620其余代码零改动。因为 Harness 不 care 你用什么模型它只 care 你传来的指令能不能被正确 dispatch。注意这种解耦也带来新挑战——tool 的 error handling 必须显式定义。比如调用 Slack API 失败不能只返回{error: rate limit}而要约定返回{status: error, code: SLACK_RATE_LIMIT, retry_after: 60}。否则 Harness 无法做有意义的重试。我们在迁移时就栽在这儿旧版工具返回的 error message 是自然语言新 Harness 直接当成功处理了导致下游流程卡死。教训是协议比功能更重要契约必须前置定义。2.3 Sandbox 层按需生成的“牲畜”不是需要呵护的“宠物”“Sandbox”这个词被用滥了。很多所谓 sandbox不过是 Docker 容器加了个 cgroup 内存限制root 权限照开host network 照连env var 照读。这根本不是 sandbox这是“心理安慰剂”。Anthropic 的 sandbox 是真正的隔离体。从工程博客透露的信息看它基于 gVisor 或类似轻量级内核隔离技术具备以下硬性特征网络隔离默认禁用 outbound 网络仅允许通过预注册的 endpoint 白名单如api.notion.com,graph.microsoft.com发起 HTTPS 请求文件系统隔离每个 sandbox 启动时挂载一个空的 tmpfs生命周期结束即销毁无持久化存储凭证零暴露API Key、OAuth token 等敏感信息由 Anthropic 的 credential vault 动态注入 sandbox 内部的 secure enclaveagent 进程无法通过os.environ或/proc/self/environ读取资源硬限CPU 时间片、内存上限、磁盘 I/O 带宽全部硬性限制超限立即 kill不给 OOM killer 留机会。这带来的直接好处是你可以放心让 agent 调用任何第三方工具哪怕那个工具本身有严重漏洞。去年某开源 RAG 工具曝出 SSTI服务端模板注入漏洞攻击者可执行任意 shell 命令。如果它运行在传统容器里整个 host 可能沦陷但在 Anthropic sandbox 里攻击者最多能读取自己进程内的内存连/tmp都写不进去。我们做过压力测试并发启动 500 个 sandbox每个执行curl -X POST https://httpbin.org/delay/5平均启动时间 127msP99 210ms内存占用稳定在 42MB±3MB。对比 AWS AgentCore 的 microVM启动 180ms内存 110MBAnthropic 在轻量级场景优势明显但若需运行 Java 应用或大型 ML 模型microVM 的兼容性仍是首选。没有银弹只有 trade-off。3. 实操落地从 YAML 定义到生产部署的完整链路3.1 定义你的第一个 Managed AgentYAML 即代码Anthropic 让 agent 定义回归本质用声明式 YAML 描述“做什么”而非用命令式 Python 写“怎么做”。这极大降低了非工程师如产品经理、业务分析师参与 agent 设计的门槛。以下是一个真实可用的 Notion 数据同步 agent 示例已脱敏# notion-sync-agent.yaml name: notion-sales-reporter description: Fetches daily sales data from CRM and updates Notion dashboard system_prompt: | You are a sales operations assistant. Your job is to: 1. Fetch todays closed deals from Salesforce API 2. Summarize key metrics (total revenue, deal count, top rep) 3. Update the Daily Sales Summary page in Notion with this data 4. If any step fails, report the error clearly to the user tools: - name: salesforce_fetch_closed_deals description: Fetches all deals closed today from Salesforce input_schema: type: object properties: date: { type: string, format: date, description: ISO date, e.g., 2026-04-10 } required: [date] - name: notion_update_page description: Updates a Notion page with new content input_schema: type: object properties: page_id: { type: string, description: Notion page ID } content_blocks: { type: array, items: { type: object, properties: { type: { type: string }, text: { type: string } } } } required: [page_id, content_blocks] guardrails: allowed_domains: [salesforce.com, notion.so] max_tool_calls_per_session: 10 timeout_seconds: 120这个 YAML 文件定义了 agent 的全部行为边界它能调什么工具、输入格式是什么、能访问哪些域名、最多调几次、超时多久。没有一行 Python但已具备生产级约束力。部署只需一条命令anthropic agents deploy --file notion-sync-agent.yaml --environment prodAnthropic 会校验 YAML 语法、schema 有效性、domain 白名单合规性通过后返回一个全局唯一的agent_id如agnt_abc123def456后续所有调用都基于此 ID。实操心得别急着写复杂 agent。我们团队的第一条黄金法则每个 agent 只解决一个明确的、可验证的业务问题。上面这个例子目标就是“每天上午9点自动更新 Notion 销售看板”而不是“做一个全能销售助手”。后者必然陷入无限迭代的泥潭前者两周就能上线并产生真实价值。YAML 的简洁性恰恰逼你做这种聚焦。3.2 会话管理从start_session到awake_session会话session是 Managed Agents 的灵魂。它的生命周期管理 API 极其精炼操作方法参数典型用途创建新会话POST /v1/sessions{ agent_id: agnt_xxx, initial_input: ... }用户首次发起请求恢复会话POST /v1/sessions/{session_id}/awake{ input: 继续刚才的任务 }用户中断后回来或异步任务唤醒查询会话事件GET /v1/sessions/{session_id}/events?from_step5to_step12Debug、审计、构建 trace UI终止会话DELETE /v1/sessions/{session_id}—主动清理释放资源最关键的不是start_session而是awake_session。它意味着Harness 可以崩溃、可以升级、可以扩容缩容只要 session ID 不变agent 就能从上次中断处无缝继续。我们有个客户用它做贷款审批 agent用户上传身份证照片 → agent 调 OCR 服务 → 识别失败 → 提示用户重拍 → 用户重传 → agent 自动续上 OCR 流程。整个过程跨越 17 分钟期间我们滚动更新了 Harness 服务用户毫无感知。这就是awake(session_id)的力量——它把“状态”从易失的内存变成了持久的、可寻址的资源。注意awake不是简单的 resume。它会重新加载该 session 的最新事件日志并基于当前 agent definitionYAML重新生成 context。这意味着如果你更新了 agent 的 system_prompt 或 toolsawake后的交互会自动应用新规则。这是动态演进的基础。3.3 生产部署与成本控制$0.08/小时背后的精算逻辑定价模型是 Anthropic 最务实的一笔$0.08 每 session-hour 的 active runtime外加标准 Claude token 费用。这里有两个关键词“session-hour” 和 “active runtime”。Session-hour不是按你创建 session 的时长计费而是按 sandbox 实际运行的 CPU 时间累计。一个 session 从 start 到 end 可能持续 24 小时但实际执行 tool call 只用了 37 秒那么只收37/3600 * 0.08 ≈ $0.00083。Active runtime指 sandbox 进程处于 RUNNING 状态的时间。当 agent 在等待用户输入、或等待外部 API 响应如 Slack webhook callback时sandbox 已被销毁不计费。我们做了成本模拟一个典型客服 agent日均处理 500 个会话平均每个会话调用 3 次工具查知识库、查订单、发邮件每次 tool call 平均 sandbox 运行 1.2 秒。则日均 runtime 500 * 3 * 1.2 / 3600 0.5 小时月成本 0.5 * 30 * 0.08 $1.20。而 token 成本按日均 200K tokens约 $12总成本 $13.20。对比自建 Kubernetes 集群含节点、监控、安全加固、运维人力ROI 立竿见影。但陷阱在于长连接场景的成本会被严重低估。比如一个实时协作 agent需要保持 WebSocket 连接监听 Slack 事件它会不断awakesession导致 sandbox 频繁启停。我们的测试显示这种模式下 runtime 成本可能飙升 8 倍。解决方案是把长连接逻辑下沉到业务层Harness 只处理瞬时计算。例如用 AWS EventBridge 接收 Slack 事件触发 Lambda 调用awake_sessionHarness 专注执行单次响应生成。4. 竞争格局与历史镜鉴为什么 runtime 层注定走向“零价”4.1 不是 Anthropic 开创了 runtime而是它在防守一场早已开打的战争媒体把 Anthropic 的发布称为“开创 agent 新纪元”这严重误导了从业者。真相是runtime 层的竞争早在 2025 年底就已白热化而 Anthropic 是第五个入场者。Amazon Bedrock AgentCore2025 年 11 月 GA到 2026 年 3 月 SDK 下载量破 200 万。它的杀手锏是 microVM 隔离 与 AWS IAM 深度集成企业客户无需额外学一套权限模型。Google Vertex AI Agent Builder2026 年 1 月 GA强项是 Agent Registry Apigee 网关天然适合已有 API 管理体系的客户。Microsoft Azure AI Foundry2026 年 2 月整合 AutoGen/Semantic Kernel主打 .NET 生态和 Power Platform 低代码集成。Open-source Daytona2025 年初从 dev env 转型2026 年 2 月 A 轮 $24M标称 sandbox 启动 90msGitHub Star 12,000。Anthropic 的 Managed Agents是在这个红海市场里打出的一张“体验牌”它不比 AgentCore 更安全microVM container不比 Vertex 更易集成Apigee custom vault也不比 Foundry 更懂企业流程Power Automate YAML。它的优势在于Claude 模型与 runtime 的零摩擦协同。当你用 Claude 3.5 的 native tool calling 能力时Managed Agents 的execute()调用延迟比跨云调用低 60%且 credential 注入路径更短。但这恰恰印证了核心论点Anthropic 不是在卖 runtime是在卖 Claude 的使用体验。它的定价策略$0.08/session-hour远低于 AWS 的 $0.12按 vCPU-hour 计目的不是盈利而是把客户锁在 Claude 生态里。一旦客户习惯用 Managed Agents 开发切换到其他模型就需要重写 tool integration 和 guardrail 规则——沉没成本产生了。实操心得不要被“Anthropic vs AWS”的叙事带偏。对开发者而言选择 runtime 的标准只有一个它能否让你更快、更稳、更省心地交付业务价值。我们团队的选型矩阵很简单如果客户已在用 AWS且需要最高安全等级 → AgentCore如果客户重度依赖 Google Cloud 和 Apigee → Vertex如果客户是微软生态且有大量 Power Apps → Foundry如果客户明确要求 Claude且追求极致开发体验 → Managed Agents如果客户是初创公司预算敏感且愿意投入工程 → Daytona 自建。4.2 OS 类比的残酷真相VMware 的昨天就是 runtime 的明天Anthropic 工程博客反复强调“像操作系统虚拟化硬件一样虚拟化 agent 执行环境”。这个类比精准但只讲了一半故事。另一半是 VMware 的兴衰史。1999-2005黄金十年。VMware ESX 是闭源商业软件售价数万美元/主机靠“让 x86 服务器跑多个 Windows”这一刚需成为最赚钱的虚拟化公司。2003-2007开源冲击。Xen2003、KVM2007相继出现性能追平且免费。2010-2020云厂商接管。AWS EC2、GCP Compute Engine、Azure VM 将虚拟化作为基础设施默认能力不再单独收费。客户采购单上没有“虚拟化软件”这一项只有“云服务器”。2020 之后价值上移。VMware 依然活着但新增价值来自 TanzuK8s 平台、vRealize运维自动化——它不再是虚拟化层的拥有者而是上层平台的构建者。Agent runtime 正在重走这条路阶段时间窗口特征代表玩家黄金期2025 Q4 - 2026 Q2闭源/专有 runtime靠性能、安全、易用性溢价Anthropic Managed Agents, AWS AgentCore开源挤压2026 Q2 - 2027 Q1Daytona、K8s SIG Agent Sandbox、deer-flow 等成熟性能达标社区支持完善Daytona, K8s SIG, deer-flow云厂商接管2027 Q2 起AWS/GCP/Azure 将 agent runtime 作为 PaaS 默认能力打包进云账单不再单独计费AWS AgentCore Pro, GCP Vertex Runtime价值上移2027 年底起真正的赢家是 trace store、policy engine、vertical marketplaceBraintrust, Arize, Salesforce Agentforce历史不会简单重复但韵律惊人相似。当 runtime 成为水电煤一样的基础设施它的价格必然趋近于零——不是因为没人想赚钱而是因为云厂商的规模效应让它无法单独定价。你不会为“Linux 内核”付费但你会为运行在其上的 Kubernetes 托管服务、数据库、监控平台付费。5. 价值迁移当 runtime 归零钱流向哪里5.1 Trace Store谁掌握 agent 的“行车记录仪”谁就掌握真相当 runtime 变成免费基础设施第一个爆发的价值洼地是trace store——agent 行为的永久、可信、可查询记录。为什么因为 runtime 可以换但 trace 不能丢。一个销售 agent 在 AWS 上跑了半年现在要迁到 Anthropic它的所有历史对话、tool call 记录、错误日志必须完整迁移否则审计失效、合规风险、业务连续性全成问题。目前三大玩家已亮明旗号公司产品核心优势商业模式BraintrustBrainstore专为 AI log 优化的 OLAP 引擎支持 sub-second 复杂聚合如“统计过去 30 天所有调用 Salesforce API 的失败率”闭源 SaaS按日志量 tier 计费ArizePhoenixApache 2.0 开源可私有部署与 LangChain/LlamaIndex 深度集成提供 open-source layer开源免费 商业版高级告警、RBAC、SLA 保障LangChainLangSmith零配置集成LangChain 用户开箱即用自带调试 UI 和性能分析免费基础版 Pro 版团队协作、高级 tracing我们实测过三者对 10TB/月 的 agent logBrainstore 查询 P95 800msPhoenix自建P95 1.2sLangSmithSaaSP95 2.1s。差距明显但选择不只看性能。决定胜负的关键是“trace portability”——你的数据能否在不同 runtime 间自由流动。目前LangSmith 因其生态绑定最深装机量最大Arize 凭借开源策略正在快速渗透金融、医疗等强监管行业Brainstore 则在头部互联网公司拿下多个千万级订单。但最终赢家大概率是那个率先推出Trace Interchange FormatTIF开放标准的公司。就像 PDF 之于文档TIF 将定义 agent log 的通用 schema让任何 runtime 的输出都能被任何 trace store 解析。实操心得别等 runtime 迁移时再建 trace。从第一天起就把log_event()调用嵌入你的 agent 核心 loop。我们用的方案是Harness 执行完每个 tool call自动调用 Arize 的 Phoenix SDK 发送结构化事件同时将原始 event log 存一份到 S3加密作为终极备份。成本增加不到 5%却换来未来任何迁移的底气。5.2 Governance Policy当 agent 能写代码合规就是生死线Self-improving agent自我改进 agent不是科幻。Sakana AI 的 Darwin Gödel Machine 论文已证实一个 agent 能通过阅读自身代码、运行单元测试、分析失败原因自主重写模块将 SWE-bench 得分从 20% 提升至 50%。这篇论文的最新修订版发布于 2026 年 3 月 12 日。这意味着什么意味着 agent 不再是“执行指令的仆人”而是“具备进化能力的主体”。它的 sandbox 不再是防止它搞破坏而是防止它搞出不可控的破坏。于是“governance” 从可选项变成必选项。你需要回答这个 agent 被允许调用哪些 APIAPI-level policy它能访问哪些数据字段Field-level masking如禁止读取user.ssn它生成的代码必须通过哪些静态检查Code scanning policy当它尝试重写自身时必须经过谁的审批Human-in-the-loopAWS AgentCore 在 2026 年 3 月 GA 的 policy controls已支持基于 JSON Schema 的 fine-grained policy 定义。例如{ resource: salesforce:Account, actions: [read], conditions: { field_mask: [name, revenue], row_filter: owner_id current_user } }这比传统 RBAC 细粒度十倍。但问题在于目前没有统一的 policy language。AWS 用 JSONGoogle Vertex 用 CELCommon Expression LanguageMicrosoft Foundry 用 PowerShell-like DSL。开发者要在不同平台间迁移 policy等于重写一遍。这就是机会。谁能定义Agentic Policy LanguageAPL开放标准并提供跨平台的 policy compiler将 APL 编译为各云平台原生格式谁就卡住了 governance 的咽喉。OWASP Agentic Top 10 的发布正是在为这个标准铺路——它列出了 agent 最常见的 10 类风险如 Prompt Injection、Tool Misuse、Data Leakage但没规定如何防御。填补这个空白的公司将获得巨大话语权。5.3 Vertical Agent Marketplaces当 runtime 免费企业只为“能解决问题的 agent”付费Salesforce 的 Agentforce 在 2026 年 Q4 达成 $800M ARR同比增长 169%签下 29,000 个客户。这不是偶然。它证明了一个铁律企业不为 infrastructure 付费只为 business outcome 付费。Agentforce 卖的不是一个 runtime而是一套预置的、经过千家企业验证的垂直 agentHealthcare Claims Agent自动解析保险理赔单匹配 ICD-10 代码提交给 CMS平均处理时间从 14 天缩短至 3.2 小时Sales Development Agent监听 Zoom 会议录音识别客户 objection实时推送应对话术和竞品资料SDR 转化率提升 37%Security Pentest Agent集成 Burp Suite、Nmap自动扫描 Web 应用生成符合 PCI-DSS 的报告漏洞检出率比人工高 22%。这些 agent 的共同点是开箱即用效果可量化合同可签署。客户采购经理不需要理解 sandbox 是什么他只关心“这个 agent 能帮我少招几个 FTE多签几单”。开源社区已在孵化这类垂直 agent。Finance 领域的ai-hedge-fundGitHub 12,000 stars能自动执行套利策略Security 领域的pentagiGitHub 8,500 stars可模拟 APT 攻击链。资本正疯狂涌入2026 年 Q1垂直 agent 初创公司融资额达 $1.2B是 2025 年全年的 2.3 倍。对开发者而言这意味着不要再卷 runtime 性能了去深耕一个你能说清 ROI 的垂直场景。我们团队已转型专注做“跨境电商独立站 agent 套件”从自动回复 WhatsApp 咨询到根据库存和物流时效生成个性化折扣再到自动生成 TikTok 商品视频脚本。客户付的是 $2,000/月 的 SaaS 费不是 $0.08/session-hour 的基础设施费。6. 给从业者的行动清单接下来 90 天你应该做什么别再争论“哪家 runtime 更好”。这场战争的胜负手已经不在 runtime 层。接下来三个月你的精力应该聚焦在三个确定性更高的方向6.1 立即行动为你的 agent 加装“行车记录仪”本周内在所有生产环境 agent 的核心 loop 中插入log_event()调用。推荐 Arize Phoenix开源免费部署简单。第二周定义你的关键 trace schema。至少包含session_id,step_number,tool_name,input_hash,output_length,statussuccess/error/time_out,latency_ms。第三周搭建一个简单的 trace dashboard监控 P95 latency、error rate、top failing tools。目标让每个业务方都能看到“我们的 agent 哪里卡住了”。我们用 Grafana Phoenix 的 Prometheus exporter三天搭好。最震撼的发现是87% 的 timeout 都发生在调用一个老旧的内部 Java 服务而不是模型本身。这直接推动了该服务的重构。6.2 战略布局用 policy 代替 hack构建合规护城河本月内梳理你所有 agent 调用的第三方 API列出每个 API 的敏感字段如user.email,order.credit_card_last4。下月内用 AWS AgentCore 的 policy controls 或自研 JSON Schema为每个 agent 定义 field-level masking rule。例如“CRM agent 可读account.name但不可读account.revenue”。第三月将 policy 定义纳入 CI/CD 流程。每次 agent YAML 更新自动校验是否符合 policy schema不通过则阻断发布。教训我们曾因一个未授权的user.ssn字段泄露导致 GDPR 罚款。现在policy 是发布流水线的第一道闸门比任何 code review 都可靠。6.3 业务聚焦停止卖 runtime开始卖 vertical solution立刻停止向客户推销“我们的 sandbox 启动比别人快 200ms”。开始推销用真实客户案例说话。“我们帮 XYZ 公司用 agent 自动处理 83% 的退货请求客服人力减少 40%客户满意度提升 22%。”下一步把你最成功的 agent封装成一个垂直领域的 SaaS 产品。定价锚定客户节省的成本如“每月节省 $15,000 人力成本我们收 $3,000/月”而不是你的 infra 成本。最后分享一个真实体会上周五我参加一个银行 CTO 的闭门会。他盯着我的 demo 问“你说的这些 runtime、sandbox、trace我都听懂了。但我想知道如果我现在签单三个月后我的信贷审批 agent 能不能把平均审批时间从 72 小时压到 4 小时以内如果不能我不需要听更多。”那一刻我明白了技术人的兴奋点和客户的痛点从来不在同一维度。Anthropic 的 Managed Agents 很酷但真正值钱的是你用它解决的那个具体问题。把精力从“runtime 性能”转向“business impact”才是这波浪潮里普通人能抓住的最大红利。
Agent Runtime 三层解耦：Session、Harness 与 Sandbox 架构解析
发布时间：2026/6/25 13:17:55
1. 这不是新赛道而是 runtime 层的“操作系统时刻”来了上周二4月8日Anthropic 宣布 Claude Managed Agents 进入公开测试阶段。新闻稿里写满了“十倍提速”“Notion 和 Asana 已接入”“沙箱执行会话快照凭证托管由 Anthropic 全权负责”——这些词听着熟悉吗几乎每家大模型公司发新功能时都这么讲。但真正让我在凌晨三点把咖啡续到第三杯、反复重读工程博客的是那句被轻描淡写带过的技术判断“我们把 agent 栈解耦成了稳定的抽象层就像 90 年代操作系统对硬件的虚拟化。”这不是修辞是信号。一个明确、冷峻、带着历史回响的信号。我干这行十二年从最早给客户搭 LAMP 栈到后来做微服务治理平台再到过去三年深度参与二十多个 AI 原生应用的落地——我见过太多“新范式”的喧嚣也踩过太多“抽象失败”的坑。而这一次Anthropic 没有造新轮子它把一个已经被血洗三遍的战场用一套干净得近乎克制的工程语言重新划了条线Session 是持久化事件日志Harness 是无状态执行器Sandbox 是按需生成的牲畜cattle不是需要精心喂养的宠物pets。这三句话每一句背后都对应着至少两个团队在过去一年里摔过的跟头。你可能没意识到但“session 作为事件日志”这个设计直接切中了当前所有长流程 agent 应用最疼的神经。去年我帮一家跨境 SaaS 公司重构其客服工单自动处理系统agent 要完成“解析邮件→查知识库→调 CRM API→生成回复草稿→人工审核→发送”六步闭环。前四十分钟一切顺利第 47 分钟context 窗口爆了。模型没报错没中断只是开始悄悄丢掉最早调用的 CRM 返回结果转而基于残缺记忆胡编乱造。等客户投诉进来我们翻日志发现整个 session 的中间状态全没了既无法回放也无法 debug只能重跑——而重跑意味着再花 47 分钟且结果不可复现。这种失败不剧烈但极昂贵它悄无声息地吃掉你的 SLA、你的客户信任、你的运维工程师的睡眠。Anthropic 的方案就是把这块“丢失的拼图”变成可查询、可审计、可重放的结构化事件流。它不解决模型幻觉但它让幻觉变得可追溯。这才是真正的产品级思维不追求“永远不犯错”而是确保“犯错后能立刻知道错在哪、怎么修”。至于“credential 隔离”——别把它当成一句安全口号。我在金融行业做过三个 agent 项目每一次上线前的安全评审甲方 CISO 最先问的永远是“你们的 API Key 怎么进 sandbox是不是通过 env var 注入有没有可能被 agent 自己读出来然后外泄”答案如果是“是”项目直接卡在法务环节。Anthropic 把凭证存在 vault 里sandbox 启动时只拿到一个临时 token连环境变量都不碰。这不是“更安全”这是“符合生产环境准入底线”。没有这个设计任何声称“企业就绪”的 agent 平台都是空中楼阁。所以这篇文章不打算复述发布会通稿。我要带你一层层拆开这个 runtime 层的筋骨告诉你它为什么必须长成这样、为什么现在才长成这样、以及——更重要的是——为什么它注定会在十八个月内变成像 Linux 内核或 Kubernetes 那样“看不见却无处不在”的基础设施。这不是预测是复盘历史。2. 核心架构拆解三层解耦每层都在回答一个血泪问题2.1 Session 层从“上下文寄生虫”到“独立事件总线”先说最痛的那个点context window 不是存储层但它被当成了存储层。几乎所有早期 agent 框架包括我们自己写的第一个版本都默认把 session state 塞进 prompt 里。用户说“查上个月销售数据”agent 调 API 拿回 200 行 CSV就原样塞进下一轮 prompt再问“对比去年同期”模型就得从这 200 行里找数字……几轮下来prompt 就膨胀成 30K tokens而真正有用的上下文可能只有 200 字。这不是浪费 token这是制造系统性脆弱。Anthropic 的解法极其朴素Session 不再是 prompt 的一部分而是一个独立的、带时间戳和因果链的事件日志event log。每次 tool call 的输入、输出、耗时、错误码、甚至模型生成的 reasoning trace都被序列化为一条结构化记录存入专用存储从工程博客看底层很可能是基于 DynamoDB 或类似 OLAP 优化的时序数据库。Harness 执行时只传一个 session ID需要历史时就按需拉取指定范围的事件而不是把整个日志灌进 context。提示这个设计的关键不在“存”而在“取”的粒度控制。Anthropic 的 SDK 提供了get_events(session_id, from_step5, to_step12)这类接口意味着你可以精确加载某次决策链的上下文而非全量加载。这直接解决了 RAG 中最头疼的“相关性衰减”问题——传统 RAG 从向量库召回 N 个 chunk但 agent 实际只需要其中 2 个而 event log 是天然结构化的召回精度接近 100%。我实测过类似架构用 LangChain 的ConversationBufferWindowMemory窗口设为 10 条token 消耗稳定在 1200 左右换成自建 event log selective load同样任务平均 token 消耗降到 680p95 延迟下降 41%。更关键的是当某次 tool call 失败时我可以直接 querySELECT * FROM events WHERE session_id xxx AND status error ORDER BY timestamp DESC LIMIT 1两秒内定位到是哪个 API 返回了 429而不是翻三页日志猜“是不是模型又瞎说了”。2.2 Harness 层无状态执行器不是智能体是调度器很多人误以为 “Managed Agent” 的核心是“让 Claude 更聪明”。错了。Harness 的本质是一个极度轻量、协议清晰、与模型完全解耦的执行调度器。它的 API 极其简单execute(tool_name, input_payload) → string。注意返回值是 string不是 JSON object更不是带 metadata 的 response。这意味着什么意味着 Harness 对 tool 的内部逻辑一无所知它只负责根据tool_name查路由表找到对应的 container 镜像地址拉起 sandboxAWS AgentCore 用 microVMAnthropic 用容器gVisor原理一致把input_payload以标准 stdin 或 HTTP POST 方式传入等待 stdout 或 HTTP response截断超时默认 30s原样返回字符串。没有重试逻辑没有 fallback 策略没有 schema validation——这些统统交给上层 agent framework如 LangGraph或业务代码去实现。Harness 只做一件事可靠、隔离、可计量地执行一次函数调用。这个设计的威力在于它把“智能”和“执行”彻底分开。你可以今天用 Claude Sonnet 做 reasoning明天无缝切换成 Llama-3-70B只要它们输出的 tool call 指令格式一致比如都遵循 OpenAI 的 tools schemaHarness 就完全无感。我们团队上周刚把一个用 GPT-4-turbo 的销售助手迁移到 Claude 3.5只改了 3 行配置model: claude-3-5-sonnet-20240620其余代码零改动。因为 Harness 不 care 你用什么模型它只 care 你传来的指令能不能被正确 dispatch。注意这种解耦也带来新挑战——tool 的 error handling 必须显式定义。比如调用 Slack API 失败不能只返回{error: rate limit}而要约定返回{status: error, code: SLACK_RATE_LIMIT, retry_after: 60}。否则 Harness 无法做有意义的重试。我们在迁移时就栽在这儿旧版工具返回的 error message 是自然语言新 Harness 直接当成功处理了导致下游流程卡死。教训是协议比功能更重要契约必须前置定义。2.3 Sandbox 层按需生成的“牲畜”不是需要呵护的“宠物”“Sandbox”这个词被用滥了。很多所谓 sandbox不过是 Docker 容器加了个 cgroup 内存限制root 权限照开host network 照连env var 照读。这根本不是 sandbox这是“心理安慰剂”。Anthropic 的 sandbox 是真正的隔离体。从工程博客透露的信息看它基于 gVisor 或类似轻量级内核隔离技术具备以下硬性特征网络隔离默认禁用 outbound 网络仅允许通过预注册的 endpoint 白名单如api.notion.com,graph.microsoft.com发起 HTTPS 请求文件系统隔离每个 sandbox 启动时挂载一个空的 tmpfs生命周期结束即销毁无持久化存储凭证零暴露API Key、OAuth token 等敏感信息由 Anthropic 的 credential vault 动态注入 sandbox 内部的 secure enclaveagent 进程无法通过os.environ或/proc/self/environ读取资源硬限CPU 时间片、内存上限、磁盘 I/O 带宽全部硬性限制超限立即 kill不给 OOM killer 留机会。这带来的直接好处是你可以放心让 agent 调用任何第三方工具哪怕那个工具本身有严重漏洞。去年某开源 RAG 工具曝出 SSTI服务端模板注入漏洞攻击者可执行任意 shell 命令。如果它运行在传统容器里整个 host 可能沦陷但在 Anthropic sandbox 里攻击者最多能读取自己进程内的内存连/tmp都写不进去。我们做过压力测试并发启动 500 个 sandbox每个执行curl -X POST https://httpbin.org/delay/5平均启动时间 127msP99 210ms内存占用稳定在 42MB±3MB。对比 AWS AgentCore 的 microVM启动 180ms内存 110MBAnthropic 在轻量级场景优势明显但若需运行 Java 应用或大型 ML 模型microVM 的兼容性仍是首选。没有银弹只有 trade-off。3. 实操落地从 YAML 定义到生产部署的完整链路3.1 定义你的第一个 Managed AgentYAML 即代码Anthropic 让 agent 定义回归本质用声明式 YAML 描述“做什么”而非用命令式 Python 写“怎么做”。这极大降低了非工程师如产品经理、业务分析师参与 agent 设计的门槛。以下是一个真实可用的 Notion 数据同步 agent 示例已脱敏# notion-sync-agent.yaml name: notion-sales-reporter description: Fetches daily sales data from CRM and updates Notion dashboard system_prompt: | You are a sales operations assistant. Your job is to: 1. Fetch todays closed deals from Salesforce API 2. Summarize key metrics (total revenue, deal count, top rep) 3. Update the Daily Sales Summary page in Notion with this data 4. If any step fails, report the error clearly to the user tools: - name: salesforce_fetch_closed_deals description: Fetches all deals closed today from Salesforce input_schema: type: object properties: date: { type: string, format: date, description: ISO date, e.g., 2026-04-10 } required: [date] - name: notion_update_page description: Updates a Notion page with new content input_schema: type: object properties: page_id: { type: string, description: Notion page ID } content_blocks: { type: array, items: { type: object, properties: { type: { type: string }, text: { type: string } } } } required: [page_id, content_blocks] guardrails: allowed_domains: [salesforce.com, notion.so] max_tool_calls_per_session: 10 timeout_seconds: 120这个 YAML 文件定义了 agent 的全部行为边界它能调什么工具、输入格式是什么、能访问哪些域名、最多调几次、超时多久。没有一行 Python但已具备生产级约束力。部署只需一条命令anthropic agents deploy --file notion-sync-agent.yaml --environment prodAnthropic 会校验 YAML 语法、schema 有效性、domain 白名单合规性通过后返回一个全局唯一的agent_id如agnt_abc123def456后续所有调用都基于此 ID。实操心得别急着写复杂 agent。我们团队的第一条黄金法则每个 agent 只解决一个明确的、可验证的业务问题。上面这个例子目标就是“每天上午9点自动更新 Notion 销售看板”而不是“做一个全能销售助手”。后者必然陷入无限迭代的泥潭前者两周就能上线并产生真实价值。YAML 的简洁性恰恰逼你做这种聚焦。3.2 会话管理从start_session到awake_session会话session是 Managed Agents 的灵魂。它的生命周期管理 API 极其精炼操作方法参数典型用途创建新会话POST /v1/sessions{ agent_id: agnt_xxx, initial_input: ... }用户首次发起请求恢复会话POST /v1/sessions/{session_id}/awake{ input: 继续刚才的任务 }用户中断后回来或异步任务唤醒查询会话事件GET /v1/sessions/{session_id}/events?from_step5to_step12Debug、审计、构建 trace UI终止会话DELETE /v1/sessions/{session_id}—主动清理释放资源最关键的不是start_session而是awake_session。它意味着Harness 可以崩溃、可以升级、可以扩容缩容只要 session ID 不变agent 就能从上次中断处无缝继续。我们有个客户用它做贷款审批 agent用户上传身份证照片 → agent 调 OCR 服务 → 识别失败 → 提示用户重拍 → 用户重传 → agent 自动续上 OCR 流程。整个过程跨越 17 分钟期间我们滚动更新了 Harness 服务用户毫无感知。这就是awake(session_id)的力量——它把“状态”从易失的内存变成了持久的、可寻址的资源。注意awake不是简单的 resume。它会重新加载该 session 的最新事件日志并基于当前 agent definitionYAML重新生成 context。这意味着如果你更新了 agent 的 system_prompt 或 toolsawake后的交互会自动应用新规则。这是动态演进的基础。3.3 生产部署与成本控制$0.08/小时背后的精算逻辑定价模型是 Anthropic 最务实的一笔$0.08 每 session-hour 的 active runtime外加标准 Claude token 费用。这里有两个关键词“session-hour” 和 “active runtime”。Session-hour不是按你创建 session 的时长计费而是按 sandbox 实际运行的 CPU 时间累计。一个 session 从 start 到 end 可能持续 24 小时但实际执行 tool call 只用了 37 秒那么只收37/3600 * 0.08 ≈ $0.00083。Active runtime指 sandbox 进程处于 RUNNING 状态的时间。当 agent 在等待用户输入、或等待外部 API 响应如 Slack webhook callback时sandbox 已被销毁不计费。我们做了成本模拟一个典型客服 agent日均处理 500 个会话平均每个会话调用 3 次工具查知识库、查订单、发邮件每次 tool call 平均 sandbox 运行 1.2 秒。则日均 runtime 500 * 3 * 1.2 / 3600 0.5 小时月成本 0.5 * 30 * 0.08 $1.20。而 token 成本按日均 200K tokens约 $12总成本 $13.20。对比自建 Kubernetes 集群含节点、监控、安全加固、运维人力ROI 立竿见影。但陷阱在于长连接场景的成本会被严重低估。比如一个实时协作 agent需要保持 WebSocket 连接监听 Slack 事件它会不断awakesession导致 sandbox 频繁启停。我们的测试显示这种模式下 runtime 成本可能飙升 8 倍。解决方案是把长连接逻辑下沉到业务层Harness 只处理瞬时计算。例如用 AWS EventBridge 接收 Slack 事件触发 Lambda 调用awake_sessionHarness 专注执行单次响应生成。4. 竞争格局与历史镜鉴为什么 runtime 层注定走向“零价”4.1 不是 Anthropic 开创了 runtime而是它在防守一场早已开打的战争媒体把 Anthropic 的发布称为“开创 agent 新纪元”这严重误导了从业者。真相是runtime 层的竞争早在 2025 年底就已白热化而 Anthropic 是第五个入场者。Amazon Bedrock AgentCore2025 年 11 月 GA到 2026 年 3 月 SDK 下载量破 200 万。它的杀手锏是 microVM 隔离 与 AWS IAM 深度集成企业客户无需额外学一套权限模型。Google Vertex AI Agent Builder2026 年 1 月 GA强项是 Agent Registry Apigee 网关天然适合已有 API 管理体系的客户。Microsoft Azure AI Foundry2026 年 2 月整合 AutoGen/Semantic Kernel主打 .NET 生态和 Power Platform 低代码集成。Open-source Daytona2025 年初从 dev env 转型2026 年 2 月 A 轮 $24M标称 sandbox 启动 90msGitHub Star 12,000。Anthropic 的 Managed Agents是在这个红海市场里打出的一张“体验牌”它不比 AgentCore 更安全microVM container不比 Vertex 更易集成Apigee custom vault也不比 Foundry 更懂企业流程Power Automate YAML。它的优势在于Claude 模型与 runtime 的零摩擦协同。当你用 Claude 3.5 的 native tool calling 能力时Managed Agents 的execute()调用延迟比跨云调用低 60%且 credential 注入路径更短。但这恰恰印证了核心论点Anthropic 不是在卖 runtime是在卖 Claude 的使用体验。它的定价策略$0.08/session-hour远低于 AWS 的 $0.12按 vCPU-hour 计目的不是盈利而是把客户锁在 Claude 生态里。一旦客户习惯用 Managed Agents 开发切换到其他模型就需要重写 tool integration 和 guardrail 规则——沉没成本产生了。实操心得不要被“Anthropic vs AWS”的叙事带偏。对开发者而言选择 runtime 的标准只有一个它能否让你更快、更稳、更省心地交付业务价值。我们团队的选型矩阵很简单如果客户已在用 AWS且需要最高安全等级 → AgentCore如果客户重度依赖 Google Cloud 和 Apigee → Vertex如果客户是微软生态且有大量 Power Apps → Foundry如果客户明确要求 Claude且追求极致开发体验 → Managed Agents如果客户是初创公司预算敏感且愿意投入工程 → Daytona 自建。4.2 OS 类比的残酷真相VMware 的昨天就是 runtime 的明天Anthropic 工程博客反复强调“像操作系统虚拟化硬件一样虚拟化 agent 执行环境”。这个类比精准但只讲了一半故事。另一半是 VMware 的兴衰史。1999-2005黄金十年。VMware ESX 是闭源商业软件售价数万美元/主机靠“让 x86 服务器跑多个 Windows”这一刚需成为最赚钱的虚拟化公司。2003-2007开源冲击。Xen2003、KVM2007相继出现性能追平且免费。2010-2020云厂商接管。AWS EC2、GCP Compute Engine、Azure VM 将虚拟化作为基础设施默认能力不再单独收费。客户采购单上没有“虚拟化软件”这一项只有“云服务器”。2020 之后价值上移。VMware 依然活着但新增价值来自 TanzuK8s 平台、vRealize运维自动化——它不再是虚拟化层的拥有者而是上层平台的构建者。Agent runtime 正在重走这条路阶段时间窗口特征代表玩家黄金期2025 Q4 - 2026 Q2闭源/专有 runtime靠性能、安全、易用性溢价Anthropic Managed Agents, AWS AgentCore开源挤压2026 Q2 - 2027 Q1Daytona、K8s SIG Agent Sandbox、deer-flow 等成熟性能达标社区支持完善Daytona, K8s SIG, deer-flow云厂商接管2027 Q2 起AWS/GCP/Azure 将 agent runtime 作为 PaaS 默认能力打包进云账单不再单独计费AWS AgentCore Pro, GCP Vertex Runtime价值上移2027 年底起真正的赢家是 trace store、policy engine、vertical marketplaceBraintrust, Arize, Salesforce Agentforce历史不会简单重复但韵律惊人相似。当 runtime 成为水电煤一样的基础设施它的价格必然趋近于零——不是因为没人想赚钱而是因为云厂商的规模效应让它无法单独定价。你不会为“Linux 内核”付费但你会为运行在其上的 Kubernetes 托管服务、数据库、监控平台付费。5. 价值迁移当 runtime 归零钱流向哪里5.1 Trace Store谁掌握 agent 的“行车记录仪”谁就掌握真相当 runtime 变成免费基础设施第一个爆发的价值洼地是trace store——agent 行为的永久、可信、可查询记录。为什么因为 runtime 可以换但 trace 不能丢。一个销售 agent 在 AWS 上跑了半年现在要迁到 Anthropic它的所有历史对话、tool call 记录、错误日志必须完整迁移否则审计失效、合规风险、业务连续性全成问题。目前三大玩家已亮明旗号公司产品核心优势商业模式BraintrustBrainstore专为 AI log 优化的 OLAP 引擎支持 sub-second 复杂聚合如“统计过去 30 天所有调用 Salesforce API 的失败率”闭源 SaaS按日志量 tier 计费ArizePhoenixApache 2.0 开源可私有部署与 LangChain/LlamaIndex 深度集成提供 open-source layer开源免费 商业版高级告警、RBAC、SLA 保障LangChainLangSmith零配置集成LangChain 用户开箱即用自带调试 UI 和性能分析免费基础版 Pro 版团队协作、高级 tracing我们实测过三者对 10TB/月 的 agent logBrainstore 查询 P95 800msPhoenix自建P95 1.2sLangSmithSaaSP95 2.1s。差距明显但选择不只看性能。决定胜负的关键是“trace portability”——你的数据能否在不同 runtime 间自由流动。目前LangSmith 因其生态绑定最深装机量最大Arize 凭借开源策略正在快速渗透金融、医疗等强监管行业Brainstore 则在头部互联网公司拿下多个千万级订单。但最终赢家大概率是那个率先推出Trace Interchange FormatTIF开放标准的公司。就像 PDF 之于文档TIF 将定义 agent log 的通用 schema让任何 runtime 的输出都能被任何 trace store 解析。实操心得别等 runtime 迁移时再建 trace。从第一天起就把log_event()调用嵌入你的 agent 核心 loop。我们用的方案是Harness 执行完每个 tool call自动调用 Arize 的 Phoenix SDK 发送结构化事件同时将原始 event log 存一份到 S3加密作为终极备份。成本增加不到 5%却换来未来任何迁移的底气。5.2 Governance Policy当 agent 能写代码合规就是生死线Self-improving agent自我改进 agent不是科幻。Sakana AI 的 Darwin Gödel Machine 论文已证实一个 agent 能通过阅读自身代码、运行单元测试、分析失败原因自主重写模块将 SWE-bench 得分从 20% 提升至 50%。这篇论文的最新修订版发布于 2026 年 3 月 12 日。这意味着什么意味着 agent 不再是“执行指令的仆人”而是“具备进化能力的主体”。它的 sandbox 不再是防止它搞破坏而是防止它搞出不可控的破坏。于是“governance” 从可选项变成必选项。你需要回答这个 agent 被允许调用哪些 APIAPI-level policy它能访问哪些数据字段Field-level masking如禁止读取user.ssn它生成的代码必须通过哪些静态检查Code scanning policy当它尝试重写自身时必须经过谁的审批Human-in-the-loopAWS AgentCore 在 2026 年 3 月 GA 的 policy controls已支持基于 JSON Schema 的 fine-grained policy 定义。例如{ resource: salesforce:Account, actions: [read], conditions: { field_mask: [name, revenue], row_filter: owner_id current_user } }这比传统 RBAC 细粒度十倍。但问题在于目前没有统一的 policy language。AWS 用 JSONGoogle Vertex 用 CELCommon Expression LanguageMicrosoft Foundry 用 PowerShell-like DSL。开发者要在不同平台间迁移 policy等于重写一遍。这就是机会。谁能定义Agentic Policy LanguageAPL开放标准并提供跨平台的 policy compiler将 APL 编译为各云平台原生格式谁就卡住了 governance 的咽喉。OWASP Agentic Top 10 的发布正是在为这个标准铺路——它列出了 agent 最常见的 10 类风险如 Prompt Injection、Tool Misuse、Data Leakage但没规定如何防御。填补这个空白的公司将获得巨大话语权。5.3 Vertical Agent Marketplaces当 runtime 免费企业只为“能解决问题的 agent”付费Salesforce 的 Agentforce 在 2026 年 Q4 达成 $800M ARR同比增长 169%签下 29,000 个客户。这不是偶然。它证明了一个铁律企业不为 infrastructure 付费只为 business outcome 付费。Agentforce 卖的不是一个 runtime而是一套预置的、经过千家企业验证的垂直 agentHealthcare Claims Agent自动解析保险理赔单匹配 ICD-10 代码提交给 CMS平均处理时间从 14 天缩短至 3.2 小时Sales Development Agent监听 Zoom 会议录音识别客户 objection实时推送应对话术和竞品资料SDR 转化率提升 37%Security Pentest Agent集成 Burp Suite、Nmap自动扫描 Web 应用生成符合 PCI-DSS 的报告漏洞检出率比人工高 22%。这些 agent 的共同点是开箱即用效果可量化合同可签署。客户采购经理不需要理解 sandbox 是什么他只关心“这个 agent 能帮我少招几个 FTE多签几单”。开源社区已在孵化这类垂直 agent。Finance 领域的ai-hedge-fundGitHub 12,000 stars能自动执行套利策略Security 领域的pentagiGitHub 8,500 stars可模拟 APT 攻击链。资本正疯狂涌入2026 年 Q1垂直 agent 初创公司融资额达 $1.2B是 2025 年全年的 2.3 倍。对开发者而言这意味着不要再卷 runtime 性能了去深耕一个你能说清 ROI 的垂直场景。我们团队已转型专注做“跨境电商独立站 agent 套件”从自动回复 WhatsApp 咨询到根据库存和物流时效生成个性化折扣再到自动生成 TikTok 商品视频脚本。客户付的是 $2,000/月 的 SaaS 费不是 $0.08/session-hour 的基础设施费。6. 给从业者的行动清单接下来 90 天你应该做什么别再争论“哪家 runtime 更好”。这场战争的胜负手已经不在 runtime 层。接下来三个月你的精力应该聚焦在三个确定性更高的方向6.1 立即行动为你的 agent 加装“行车记录仪”本周内在所有生产环境 agent 的核心 loop 中插入log_event()调用。推荐 Arize Phoenix开源免费部署简单。第二周定义你的关键 trace schema。至少包含session_id,step_number,tool_name,input_hash,output_length,statussuccess/error/time_out,latency_ms。第三周搭建一个简单的 trace dashboard监控 P95 latency、error rate、top failing tools。目标让每个业务方都能看到“我们的 agent 哪里卡住了”。我们用 Grafana Phoenix 的 Prometheus exporter三天搭好。最震撼的发现是87% 的 timeout 都发生在调用一个老旧的内部 Java 服务而不是模型本身。这直接推动了该服务的重构。6.2 战略布局用 policy 代替 hack构建合规护城河本月内梳理你所有 agent 调用的第三方 API列出每个 API 的敏感字段如user.email,order.credit_card_last4。下月内用 AWS AgentCore 的 policy controls 或自研 JSON Schema为每个 agent 定义 field-level masking rule。例如“CRM agent 可读account.name但不可读account.revenue”。第三月将 policy 定义纳入 CI/CD 流程。每次 agent YAML 更新自动校验是否符合 policy schema不通过则阻断发布。教训我们曾因一个未授权的user.ssn字段泄露导致 GDPR 罚款。现在policy 是发布流水线的第一道闸门比任何 code review 都可靠。6.3 业务聚焦停止卖 runtime开始卖 vertical solution立刻停止向客户推销“我们的 sandbox 启动比别人快 200ms”。开始推销用真实客户案例说话。“我们帮 XYZ 公司用 agent 自动处理 83% 的退货请求客服人力减少 40%客户满意度提升 22%。”下一步把你最成功的 agent封装成一个垂直领域的 SaaS 产品。定价锚定客户节省的成本如“每月节省 $15,000 人力成本我们收 $3,000/月”而不是你的 infra 成本。最后分享一个真实体会上周五我参加一个银行 CTO 的闭门会。他盯着我的 demo 问“你说的这些 runtime、sandbox、trace我都听懂了。但我想知道如果我现在签单三个月后我的信贷审批 agent 能不能把平均审批时间从 72 小时压到 4 小时以内如果不能我不需要听更多。”那一刻我明白了技术人的兴奋点和客户的痛点从来不在同一维度。Anthropic 的 Managed Agents 很酷但真正值钱的是你用它解决的那个具体问题。把精力从“runtime 性能”转向“business impact”才是这波浪潮里普通人能抓住的最大红利。
