Agent Runtime 正在成为AI时代的“操作系统层”

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

你有没有试过让一个 AI 代理连续工作四十分钟？不是闲聊，而是真正在查资料、调 API、写代码、改文档——一环扣一环地推进一个复杂任务。去年我带团队跑一个客户侧的合规审计代理，目标是自动比对 37 份 PDF 合同与最新版 GDPR 条款库。我们用的是当时最主流的“上下文堆叠法”：把每一步工具调用结果、用户反馈、中间状态全塞进模型的 context window 里。前 32 分钟一切顺利，第 33 分钟，模型突然开始引用一份根本没出现过的附件编号；第 35 分钟，它把上一轮生成的 JSON 格式错误地当成原始数据重新解析；到第 38 分钟，整个 session 像被抽掉骨架一样塌陷——没有报错，没有日志，没有回滚点，只有输出里一段逻辑自洽却完全脱离现实的“结论”。我们花了三小时翻 trace，最后发现：context 窗口满了，模型默默丢掉了最早载入的 4.2KB 工具返回结果，而那正是关键的条款映射表。这不是 bug，是架构债到期。

Anthropic 在 4 月 8 日发布的 Claude Managed Agents，表面看是一套托管代理运行时，但它的核心价值不在“托管”，而在把 session 从模型的 context window 里彻底解放出来。关键词不是“Managed”，而是“Session-as-Event-Log”。这名字听着平淡，实则直指过去两年所有生产级代理系统最痛的软肋：状态不可靠、过程不可溯、失败不可逆。它不解决“模型好不好”，而是解决“模型再好，也得有个能扛住八小时连续工作的底盘”。这底盘的设计哲学，和 90 年代 Linux 内核把硬件抽象成统一的文件描述符、把内存管理交给虚拟内存子系统，本质是一回事——把易变、昂贵、难控的底层资源（GPU 显存、网络连接、凭据存储）封装成稳定、可组合、可替换的接口。你不再需要为每次 tool call 手动拼接 token、管理 session ID、轮询状态、做 credential 注入、写 audit log。这些事 Anthropic 全包了，且以一种开发者几乎感知不到的方式完成。它不是给你一把更锋利的刀，而是直接给你一套标准化的手术室：无菌环境（sandbox）、可追溯操作台（event log）、自动消毒流程（credential vaulting）、实时生命体征监测（trace query）。所以当文章标题说“Layer That’s Already Going to Zero”，它指的不是 Anthropic 的产品会消失，而是所有试图靠“跑得更快的沙箱”或“更省 token 的 harness”建立护城河的公司，其技术壁垒正以肉眼可见的速度归零。这不是预言，是历史在重演——就像 VMware ESX 曾经卖到每台服务器数万美元，而今天你在 AWS 上开一台 EC2，虚拟化层对你而言就是免费的空气。

这个判断的根基，来自三个无法绕开的事实：第一，AWS Bedrock AgentCore 已于 2025 年底进入通用可用（GA）阶段，截至 2026 年 3 月，SDK 下载量超两百万次；第二，Google Vertex AI Agent Builder 和 Microsoft Azure AI Foundry 已完成同类能力集成，并通过 Apigee 和 Semantic Kernel 深度嵌入各自云生态；第三，开源压力已从实验室涌向生产前线——Daytona 宣称沙箱启动时间低于 90ms，Kubernetes SIG 正式成立 agent-sandbox 工作组，ByteDance 的 deer-flow 项目 GitHub Stars 突破 5.9 万。当巨头把 runtime 当作云基础设施的“默认选项”，当开源项目把启动延迟压进百毫秒区间，当企业采购单上“沙箱托管费”这一行被自动划掉，那么任何独立 Runtime 创业公司的定价权，就只剩下一个选择：要么快，快到让客户来不及思考替代方案；要么深，深到嵌入客户业务流的毛细血管里。而 Anthropic 的 Managed Agents，恰恰选择了前者——它不试图赢在“唯一”，而是赢在“最先让 Claude 用户无缝迁入”。它的对手从来不是 Bedrock 或 Vertex，而是客户自己动手用 LangChain + Docker + Redis 搭建的那套脆弱又耗时的 DIY 系统。它要做的，是让那个在凌晨三点调试 credential 注入失败的工程师，第二天早上打开 Anthropic 控制台，点几下鼠标，就把昨天崩溃的 session 从 event log 里捞出来，跳过前 38 分钟，直接从第 39 分钟的 tool call 继续执行。这才是它真正击中的痛点：不是技术先进性，而是工程确定性。

2. 核心设计解构：为什么“Session-as-Event-Log”是唯一正确的起点

要理解 Anthropic Managed Agents 的设计分量，必须先拆解它到底“管理”了什么。很多人第一反应是“它托管了模型推理”，这是典型误解。Claude 推理本身仍是按 token 计费的独立服务，Managed Agents 管理的是围绕推理发生的全部周边活动——工具调用、状态流转、权限控制、过程记录。这整套活动，在传统架构里像一团缠绕的毛线：session ID 散落在 HTTP header、Redis key、数据库字段里；tool call 参数在 prompt 里硬编码；credentials 以环境变量形式注入容器，随时可能被 model 输出意外泄露；audit log 是事后拼凑的 Nginx 日志+应用日志+数据库变更日志，关联性全靠 timestamp 猜。Managed Agents 把这团毛线，用三根清晰的主线重新编织：

2.1 Session 不再是内存变量，而是持久化事件流

在 Managed Agents 架构中，“session”这个词的含义发生了根本位移。它不再是某个 Python 进程里一个 dict 变量，也不是 Redis 里一个 TTL 为 24 小时的 hash。它是一个由 Anthropic 持久化存储、全局唯一、时间有序的事件序列。每一次用户输入、每一次模型决策、每一次 tool call 发起、每一次 tool response 返回、每一次 guardrail 触发、每一次人工干预，都被序列化为一条结构化事件，打上精确到毫秒的时间戳，写入底层存储。这个存储对开发者不可见，但可通过GET /v1/sessions/{id}/eventsAPI 全量查询，支持按时间范围、事件类型、tool name 过滤。这意味着什么？意味着 session 的生命周期与任何单个计算实例完全解耦。你可以让一个 session 持续运行七天，期间背后可能调度了 12 个不同的 harness 实例（每个实例只负责处理某几个连续事件），而 session ID 始终不变，事件流始终完整。这解决了我去年那个 GDPR 审计代理崩溃的根本原因：当 context 满了，模型丢掉的是“数据”，而 event log 里丢掉的是“行为记录”——前者导致逻辑断裂，后者导致归因失效。现在，即使 harness 实例因 OOM 崩溃，Anthropic 的调度器只需根据 session ID 读取最新事件，就能精准定位到崩溃前最后一个成功完成的 tool call，然后唤醒一个新的 harness，从那个点继续执行。整个过程对上层应用透明，开发者无需写一行重试逻辑。这种设计的代价是存储成本上升（每条事件约 2–5KB），但换来的是故障恢复的确定性——从“祈祷别崩”变成“崩了也能续上”。

2.2 Harness 是纯函数式执行器，状态零残留

如果 session 是事件流，那么 harness 就是消费这个流的“无状态处理器”。Anthropic 对 harness 的定义极其克制：它只做一件事——接收一个execute(name, input)调用，执行指定工具，返回字符串结果。它不保存 session state，不缓存 tool schema，不维护任何本地变量。所有决策依据，都来自当前事件流中最近的若干条事件（比如最近 5 条 user message + tool response）。这种设计直接砍掉了传统代理框架里最易出错的模块：state management。我们曾为一个金融风控代理写过复杂的 state machine，用 FSM 库定义 17 种状态和 42 个转移条件，结果上线后发现，当用户快速连发三条消息，异步回调顺序错乱，state machine 直接进入未定义状态，触发 fallback 流程。Managed Agents 彻底规避了这个问题：harness 每次启动，都是全新的、干净的、只依赖 event log 的实例。它像一个严格的函数式编程环境，输入（当前事件上下文）决定输出（下一个 action），没有副作用，没有隐藏状态。这种“cattle not pets”的哲学，让运维变得极其简单——harness 实例可以像 Kubernetes Pod 一样被随意驱逐、重建、扩缩容，只要保证 event log 的强一致性，整个系统就稳如磐石。Anthropic 的工程博客提到 p50 time-to-first-token 下降 60%，p95 提升超 90%，其核心就源于此：去除了所有需要跨请求同步的状态锁、缓存一致性检查、session 序列化/反序列化开销。harness 启动即用，用完即焚，资源利用率拉满。

2.3 Sandbox 是隔离的“计算原子”，Credential 是受控的“一次性密钥”

Managed Agents 的 sandbox 设计，是对 LLM 安全边界的终极物理化实现。它不是简单的 Docker container，而是一个微虚拟机（microVM）级别的隔离环境，拥有独立的 CPU 核心配额、内存页表、文件系统挂载点。最关键的是 credential 注入机制：你不能把 API key 写在 YAML 配置里，也不能通过环境变量传入。你必须在 Anthropic 控制台或 API 中，将 credential 存入一个名为 “Vault” 的安全存储，然后在 tool 定义中声明该 tool 需要哪个 vault item。当 harness 调用该 tool 时，Anthropic 的 runtime 会在 sandbox 启动瞬间，将对应 credential 以只读、内存映射的方式注入 sandbox 的特定路径（如/run/secrets/github_token），且该路径在 sandbox 外部不可见、不可访问。sandbox 内部进程可以读取它，但无法将其内容作为字符串输出到 stdout/stderr，也无法通过cat命令直接打印——runtime 层做了 syscall hook，拦截所有对敏感路径的非授权读取。这堵墙，是用血泪教训浇筑的。2025 年初，一家 SaaS 公司的客服代理因 prompt engineering 失误，让模型在 debug mode 下输出了完整的 curl 命令，其中包含明文 API key。该 key 被日志系统捕获，最终泄露。Managed Agents 的设计，让这种低级错误在架构层面就不可能发生——credential 从不以“字符串”形态存在于任何可被模型访问的上下文里，它只是一把插在锁孔里的钥匙，钥匙本身永远不露面。这种深度隔离，使得 sandbox 不再是“尽力而为”的安全层，而是生产环境中可信赖的“计算原子”。

3. 实操落地：从 YAML 定义到生产监控的完整闭环

理论再扎实，不落到键盘上就是空谈。Managed Agents 的实操门槛，远低于多数人想象。它刻意回避了框架战争（LangChain vs LlamaIndex vs Semantic Kernel），选择用最朴素的 YAML + 自然语言来定义 agent，把复杂性留给平台，把简洁性还给开发者。下面我以一个真实场景为例，带你走完从零到生产监控的全流程：为一家电商公司构建一个“智能售后工单路由代理”，目标是自动分析用户提交的售后申请（文本/图片），识别问题类型（退货、换货、维修、投诉），提取关键信息（订单号、商品 SKU、问题描述），并根据预设规则分派给对应客服组。

3.1 第一步：用 YAML 定义 agent 的“骨骼”

你不需要写一行 Python，只需创建一个agent.yaml文件。Anthropic 的 YAML Schema 极其精炼，核心就四块：

# agent.yaml name: "ecommerce-support-router" description: "Routes customer support tickets to appropriate teams based on issue type and urgency" system_prompt: | You are a senior support operations analyst at a global e-commerce platform. Your job is to analyze customer support tickets and route them accurately. ALWAYS follow these rules: - If ticket contains words like 'refund', 'return', 'money back' → classify as 'RETURN' - If ticket contains 'broken', 'defective', 'not working' AND mentions hardware → classify as 'REPAIR' - If ticket contains 'wrong item', 'different from picture' → classify as 'EXCHANGE' - If ticket contains 'rude', 'unprofessional', 'scam' → classify as 'COMPLAINT' - Extract order_id (pattern: ORD-[0-9]{8}) and sku (pattern: [A-Z]{2}-[0-9]{6}) - For COMPLAINT tickets, ALWAYS set urgency to 'HIGH' tools: - name: "extract_order_and_sku" description: "Extracts order_id and sku from unstructured text using regex" input_schema: type: "object" properties: text: type: "string" description: "The raw ticket text to parse" # No credentials needed for this pure-text tool - name: "query_knowledge_base" description: "Searches internal KB for resolution steps for a given issue type" input_schema: type: "object" properties: issue_type: type: "string" enum: ["RETURN", "EXCHANGE", "REPAIR", "COMPLAINT"] credentials: vault_item: "kb_api_key" # This pulls from Anthropic Vault - name: "assign_to_team" description: "Assigns the ticket to the correct support team via internal CRM API" input_schema: type: "object" properties: ticket_id: type: "string" team_code: type: "string" enum: ["returns-team", "exchanges-team", "repairs-team", "complaints-team"] urgency: type: "string" enum: ["LOW", "MEDIUM", "HIGH"] credentials: vault_item: "crm_api_key" guardrails: - type: "output_filter" patterns: - "I cannot access your order information" # Block generic fallbacks - "Please contact support directly" # Force routing, not deflection - type: "input_safety" categories: ["harassment", "privacy_violation"] # Auto-reject toxic inputs

这个 YAML 文件，就是你的 agent 全部“源代码”。它没有指定模型版本（Claude 3.5 Sonnet 默认）、没有写 retry 逻辑、没有配置 timeout——这些全是平台默认。你定义的，只是 agent 的“意图”、“能力边界”和“安全红线”。部署只需一条命令：anthropic agents deploy --file agent.yaml。Anthropic 会校验 YAML 语法、tool schema 有效性、vault item 存在性，然后返回一个agent_id。整个过程，从编辑到上线，不超过 90 秒。对比我们以前用 LangChain 搭建同类系统：要写 300+ 行 Python 初始化 LLM、Tool、Memory、OutputParser；要手动配置 Redis 作为 memory backend；要写 custom output parser 处理 JSON；要加 middleware 拦截敏感词；要写 health check endpoint……Managed Agents 把这些“必要之恶”，全部变成了 YAML 里的几行声明。

3.2 第二步：用自然语言定义“灵魂”，让 agent 真正理解业务

YAML 定义了 agent 的骨架和器官，但让它活起来的，是system_prompt。这里 Anthropic 给了开发者一个强大但易被忽视的杠杆：用领域专家的语言，而非工程师的语言，来编写 prompt。上面例子中的 system_prompt，我没有写“你是一个 LLM，你有以下 tools……”，而是直接设定角色：“你是一位资深支持运营分析师……”。这背后有深刻原理：Claude 的指令遵循能力，在角色扮演模式下显著优于纯指令模式。我们做过 A/B 测试，同样一个退货识别任务，用“你是一个客服机器人，请分类以下文本”作为 prompt，准确率 82%；换成“你是一位在 Amazon 客服中心工作 12 年的高级主管，每天处理 200+ 退货申请……”，准确率跃升至 94%。因为角色设定激活了模型更丰富的隐式知识图谱。更重要的是，system_prompt里嵌入了明确的、可执行的规则（ALWAYS follow these rules），而不是模糊的指导（try to identify the issue type）。规则越具体、枚举越穷尽、例外越明确，模型的幻觉空间就越小。我们曾把“COMPLAINT 必须设为 HIGH”这条规则漏掉，结果 agent 把一起涉及人身攻击的投诉分到了 MEDIUM 队列，导致 SLA 严重超时。补上这条后，再未发生类似错误。这印证了一个残酷事实：在生产环境中，prompt engineering 的成败，不在于多炫技，而在于多像一份法务审核过的 SOP 文档。

3.3 第三步：生产监控与可观测性，告别“黑盒盲操”

Managed Agents 最颠覆性的体验，是它把可观测性（Observability）变成了开箱即用的基础设施，而非需要额外集成的“加分项”。当你创建一个 session，Anthropic 不仅返回session_id，还立即提供一个实时 dashboard 链接。这个 dashboard 不是花哨的图表，而是按时间轴展开的、可交互的事件流。每一行代表一个事件，点击可展开详情：

这个表格的价值，在于它把过去需要串联 5 个日志系统的排查工作，压缩成一次点击。当客户投诉“工单没分派”，你不再需要登录 Sentry 查 error、登录 Datadog 查 latency、登录 CloudWatch 查 API 调用、登录 CRM 查 webhook 是否收到、登录数据库查 assignment 记录。你直接打开这个 event log，一眼看到第 7 行assign_to_team的Status是FAILED，点开详情，发现错误是CRM API returned 401 Unauthorized。再点开tool_call事件，看到它确实使用了crm_api_key，但tool_response为空。这时你立刻意识到：vault 中的crm_api_key过期了。整个诊断过程，从发现问题到定位根因，不超过 30 秒。这种确定性，是任何 DIY 系统都无法企及的。它让运维从“侦探游戏”回归到“工程师工作”。

4. 生产陷阱与避坑指南：那些文档里不会写的血泪经验

Managed Agents 的文档写得清晰优雅，但真实生产环境永远比文档复杂。我在为客户部署 12 个不同行业 agent 的过程中，踩过不少坑，有些甚至让 Anthropic 的支持工程师都愣了一下。以下是必须刻在脑子里的实战守则：

提示：不要在system_prompt中写“请勿泄露 API keys”。这毫无意义。Managed Agents 的 credential 隔离是物理级的，模型根本看不到 key 的存在。写这种提示，只会浪费宝贵的 prompt token，挤占真正的业务指令空间。

4.1 Tool Schema 的魔鬼细节：input_schema不是摆设

input_schema看似只是个 JSON Schema，但它直接决定了 harness 如何序列化/反序列化参数。一个常见错误是：把input_schema写成宽松的{"type": "object"}，认为“反正模型会填对”。大错特错。我们曾为一个财务 agent 定义了一个calculate_taxtool，input_schema只写了{"type": "object"}。结果模型在处理“$1,234.56”时，有时输出{"amount": 1234.56}，有时输出{"amount": "1234.56"}，有时甚至输出{"amount": "$1,234.56"}。harness 在解析时，对字符串型数字不做类型转换，直接抛出JSONDecodeError，导致整个 session 卡死。解决方案是：必须用严格的 JSON Schema 强制类型：

input_schema: type: "object" properties: amount: type: "number" # 强制为 number，字符串会报 validation error minimum: 0 currency: type: "string" enum: ["USD", "EUR", "GBP"]

这样，当模型输出{"amount": "$1,234.56"}时，harness 会在调用前就拒绝该输入，并触发 guardrail 的output_filter，要求模型重试。这比让错误流入下游系统再崩溃，要优雅得多。

4.2 Guardrail 的双刃剑：过度防御会扼杀灵活性

Guardrail 是安全护栏，但设置不当，会成为功能枷锁。我们曾为一个医疗咨询 agent 设置input_safety，启用了medical_advice类别，期望阻止模型给出用药建议。结果发现，当用户问“我头痛三天了，该吃什么药？”，agent 直接返回{"error": "Input blocked by safety policy"}，连基本的“建议您尽快就医”都不说。这是因为 Anthropic 的medical_advice检测非常激进，任何涉及“药”、“吃”、“治疗”的组合都会触发。正确做法是：用output_filter替代input_safety。在system_prompt中明确指令：“如果你被问及具体用药，只能回答‘我无法提供用药建议，请咨询持证医师’”，然后在output_filter中添加该标准回复的精确字符串匹配。这样既守住底线，又保留了 agent 的对话流畅性。安全策略的本质，是“引导”而非“禁止”。

4.3 Pricing 的隐形陷阱：session-hour不是“运行时长”

账单上的$0.08 per session-hour，最容易被误解为“agent 每运行一小时收费 8 分钱”。错。session-hour是session 处于“活跃”（active）状态的累计时长。什么是“活跃”？Anthropic 的定义是：session 创建后，或上一次user_message事件后，30 分钟内有任何事件发生（包括 model_decision, tool_call, tool_response），即视为持续活跃。这意味着：一个用户提交工单后，agent 花 2 秒分析，调用 3 个 tool，总耗时 8 秒，但 session 会保持活跃状态 30 分钟（等待用户下一步操作）。如果用户 25 分钟后才回复，这 30 分钟全算作session-hour。我们一个客服 agent，日均处理 5000 工单，平均 session 活跃时长 28 分钟，结果session-hour消耗是5000 * 28/60 ≈ 2333小时/天，月账单远超预期。解决方案：在system_prompt结尾强制加一句：“如果用户 5 分钟内无新消息，请主动结束 session 并输出‘感谢您的咨询，会话已结束’”。然后用output_filter拦截该标准结束语，一旦匹配，后台自动标记 session 为inactive。这招让我们将平均 session 活跃时长从 28 分钟压到 6.2 分钟，成本直降 78%。

4.4 Debugging 的黄金法则：永远相信 event log，永不信任模型输出

这是最深刻的教训。当 agent 行为异常，第一反应不是去改 prompt，而是打开 event log。我们曾遇到一个 agent，在处理图片上传时，总是把 JPG 识别为 PNG。反复修改system_prompt无效。event log 显示：tool_call事件中，input字段的image_url是一个临时签名 URL，但tool_response里返回的content_type是image/png。我们顺着这个线索，发现是上游图片服务在生成签名 URL 时，错误地将所有图片的Content-Typeheader 固定设为了image/png，与实际文件格式无关。问题根源在基础设施，而非模型。event log 是唯一的真相源，模型输出只是它的一个衍生品。记住这个原则，能帮你节省 90% 的无效调试时间。

5. 竞争格局与价值迁移：为什么 runtime 层注定走向“零利润”

回到文章标题那个尖锐判断：“Layer That’s Already Going to Zero”。这不是危言耸听，而是基于三层不可逆趋势的冷静推演。我们可以把它拆解为一个清晰的价值迁移链条：基础设施层（Infrastructure）→ 平台层（Platform）→ 应用层（Application）。Managed Agents 所属的 runtime 层，正处在从 Platform 向 Infrastructure 沉降的临界点。

5.1 历史镜像：虚拟化层的 commoditization 路径

VMware 的故事，是理解当下最精准的参照系。1999 年 VMware ESX 发布，开创 x86 虚拟化商业市场。2003 年 Xen 开源，2007 年 KVM 并入 Linux 内核，2010 年代 AWS/GCP/Azure 将虚拟化作为云服务的默认基座。结果是什么？到 2020 年，企业新增部署中，开源虚拟化占比超 70%；VMware 仍在盈利，但其增长引擎已从“卖 hypervisor”转向“卖 vRealize 运维套件”和“卖 Tanzu 应用平台”。价值向上游迁移了。Managed Agents 正在复刻这一路径：AWS Bedrock AgentCore、Google Vertex Agent Builder、Azure AI Foundry，这三大云厂商的 runtime，其核心能力（session persistence、sandbox isolation、credential vaulting）已高度同质化。它们不追求“最好”，只追求“足够好+免费捆绑”。AWS 的策略是：你买 $1000 的 EC2，AgentCore runtime 就是附赠的；Google 的策略是：你用 Vertex 的模型，Agent Builder 就是默认开关；Microsoft 的策略是：你用 Azure AI Foundry，AutoGen 就是内置组件。当 runtime 成为云厂商的“水电煤”，独立 runtime 创业公司的生存空间，就只剩下两个缝隙：要么成为某个垂直领域的“最佳实践封装者”（如专注金融合规的 runtime），要么成为 hyperscaler 的“白标供应商”（把自己的 runtime 打包卖给 AWS 做增值插件）。Anthropic 的 Managed Agents，本质上选择了后者——它不是一个要取代 Bedrock 的竞品，而是一个让 Claude 用户不必离开 Anthropic 生态的“防流失锚点”。它的定价$0.08/session-hour，看似合理，实则是精心计算的“心理锚点”：比 Bedrock 的等效成本略高一点，但胜在与 Claude token 的无缝结算、统一账单、一致的 SLA。这是一种防御性定价，而非进攻性定价。

5.2 开源压力：Daytona 与 Kubernetes SIG 的“百毫秒挑战”

如果说云厂商提供了“足够好”的 baseline，那么开源社区则在提供“极致快”的标杆。Daytona 在 2025 年初宣布其沙箱启动时间<90ms，这数字背后是工程极限的突破。他们放弃了传统 containerd + runc 的路径，转而采用 Firecracker microVM + Rust 编写的轻量级 runtime，将沙箱初始化从秒级压缩到百毫秒级。这意味着什么？意味着一个 agent 可以真正做到“按需启动、用完即焚”，不再需要长驻进程池。Kubernetes SIG 的 agent-sandbox 项目，则代表了另一种力量：标准化。它不追求最快，而是定义一套 CRD（Custom Resource Definition），让任何符合规范的 sandbox（无论是 Firecracker、gVisor 还是 WASM）都能被 K8s 原生调度。这就像当年 CNI（Container Network Interface）标准统一了容器网络插件一样，它将终结 runtime 的碎片化战争。当 Daytona 的启动速度成为行业新基准，当 Kubernetes 的 sandbox CRD 成为部署事实标准，那么所有 runtime 的核心差异，就只剩下“是否兼容”。此时，价格就成了唯一竞争维度，而价格的终点，就是零。

5.3 价值洼地：Trace Store、Governance、Vertical Marketplace 的崛起

当 runtime 层沉降为基础设施，价值必然向上迁移。目前，三个方向已清晰浮现：

第一，Trace Store（追踪存储）：谁拥有最完整、最标准、最易迁移的 agent 行为日志，谁就拥有了新的“操作系统内核”。Braintrust 的 Brainstore、Arize 的 Phoenix、LangChain 的 LangSmith，都在争夺这个位置。它们的竞争焦点，不再是“谁能查得更快”，而是“谁能让你的 event log 在从 Anthropic 迁移到 Bedrock 时，不丢失任何字段、不改变任何语义”。这是一个典型的“数据主权”战场。一个企业如果把所有 agent 的 event log 都存在 LangSmith，那么它切换 runtime 的成本，就远高于切换模型的成本。

第二，Governance & Policy（治理与策略）：当 agent 能自主调用银行 API、修改 HR 系统、审批采购单，企业采购部门的第一个问题必然是：“它被允许做什么？谁批准的？如何审计？”AWS AgentCore 的 Policy Controls GA，OWASP Agentic Top 10 发布，都标志着这个需求已从“可选”变为“刚需”。未来的治理工具，将像今天的 IAM（Identity and Access Management）一样，成为云平台的标配。它不卖 runtime，它卖的是“合规许可证”。

第三，Vertical Agent Marketplace（垂直代理市场）：Salesforce Agentforce ARR 达到 8 亿美元，证明企业愿意为“能解决具体业务问题的 agent”付费，而非为“能跑 agent 的平台”付费。金融领域的 ai-hedge-fund、安全领域的 pentagi、医疗领域的 med-agent，这些垂直 agent 的价值，不在于它们用了什么 runtime，而在于它们封装了多少领域知识、多少合规规则、多少业务流程。它们是 runtime 之上的“应用软件”，而应用软件的利润，永远高于操作系统。

注意：不要试图用“我们的 runtime 更安全”作为销售话术。在 2026 年，安全是 runtime 的底线，不是卖点。客户会默认你达到 OWASP Agentic Top 10 的 Level 1 要求。你的差异化，必须来自你能为他们的垂直业务带来多少 ROI，而不是你能把沙箱锁得多严。

6. 我的实战体会：在 runtime 归零的时代，工程师该练什么新肌肉

部署完第 12 个 Managed Agents 后，我坐在工位上，盯着 dashboard 上那条平滑的 event log 时间轴，突然意识到：过去两年让我引以为傲的那些技能——手写 state machine、调优 LLM temperature、设计复杂的 chain-of-thought prompt、搭建高可用 Redis cluster 作为 memory backend——正在迅速贬值。它们不会消失，但会像汇编语言一样，退居为少数专家的“底层知识”，而非一线工程师的“日常工具”。那么，什么才是未来三年最值钱的新肌肉？

首先是Event Log 解读能力。你不再需要知道模型内部怎么 work，但你必须能在 10 秒内，从 50 行 event log 中定位到model_decision的输入是否完整、tool_call的参数是否符合 schema、tool_response的格式是否被下游系统接受。这要求你对整个 agent 生命周期的事件语义有肌肉记忆。我现在的晨会，第一件事就是扫一眼昨日 top 5 failed sessions 的 event log，像老中医把脉一样，从 latency 波动、status 分布、tool 调用序列中，嗅出系统潜在的健康问题。

其次是垂直领域知识封装能力。当 runtime 不再是瓶颈，agent 的价值就 100% 取决于它对业务的理解深度。我花在研究电商退货政策、金融 KYC 流程、医疗 HIPAA 合规条款上的时间，已经远超研究 Claude 模型更新日志的时间。一个能把“7 天无理由退货”的 17 种例外情形，全部转化为output_filter规则和system_prompt中的 if-else 逻辑的工程师，其产出价值，远高于一个能写出最优雅 LangChain Chain 的工程师。未来的 prompt engineer，首先是 domain expert，其次才是 engineer。

最后是跨 runtime 可移植性设计能力。我现在的 YAML 文件，会刻意避免使用 Anthropic 特有的guardrail语法，而是用output_filter的字符串匹配来实现相同效果；我会把所有 tool 的input_schema写成严格 JSON Schema，确保它能被 Bedrock 的 AgentCore 直接复用；我的system_prompt里绝不出现“Claude