Agent Runtime 正在 commoditization：从操作系统时刻看基础设施归零

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

你点开这篇文字，大概率是因为标题里那个刺眼的“Zero”——不是零错误、零延迟，而是“走向归零”的零。这不是危言耸听，也不是媒体标题党，而是我过去三年亲手搭过七套生产级 agent 系统、踩过至少四次“上下文爆炸”导致整单客户交付失败后，看到 Anthropic Managed Agents 发布时的第一反应：这层东西，真要被压成薄片了。

核心关键词就三个：Managed Agents、runtime layer、commoditization。它们不是孤立概念，而是一条正在加速下坠的价值链。Anthropic 没有发明 agent，也没创造 sandbox，更没定义 session——它只是把一套已经被 AWS、Google、Microsoft 用不同名字跑通半年以上的基础设施，用 Claude 的品牌重新打包、加了一层 YAML 配置语法糖、再配上一篇写得极漂亮的工程叙事，推到了聚光灯下。而真正值得所有人盯住的，是那篇工程博客里反复出现的类比：“像 90 年代操作系统虚拟化硬件一样”。这个比喻太精准，也太危险——因为它指向的不是荣耀，而是宿命。

我去年在给一家跨境 SaaS 公司做智能客服 agent 时，把 session state 全塞进 context window，结果第 37 轮多轮对话后，模型开始把用户前天问的退货政策，当成今天刚提的新需求来“补全”，生成了一段逻辑自洽但完全虚构的退款流程。没有报错，没有中断，只有静默的幻觉。我们花了两天时间翻日志、重放 trace、对比 token embedding，最后发现是 context 窗口满了，模型自动做了“无损压缩”——把早期 tool call 的 JSON 结果，替换成“用户之前问过退货”。这不是 bug，是 context-as-storage 这个设计范式本身的结构性缺陷。Anthropic 的 session-as-event-log，本质就是把这块“内存”从模型脑袋里，搬进一个带事务、带索引、带 TTL 的外部数据库。这不是创新，是补课；不是领先，是止损。而 AWS Bedrock AgentCore 在 2025 年底 GA 时，就已经默认启用 microVM + 外部 state store 架构，连 session 最长存活时间都设为 8 小时——比 Anthropic 的“days”更具体、更可测、更面向生产环境。

所以，当你听到“Anthropic 推出 Managed Agents”，请立刻在脑子里替换为：“Claude 官方 runtime 终于上线，比 AWS 晚五个月，比 Google Vertex AI Agent Builder 晚四个月，比 Azure AI Foundry 整合 AutoGen 的节奏慢一个季度”。这不是谁先发谁赢的游戏，而是谁家 runtime 更快变成“水电煤”——免费、稳定、无感、不可见。就像你现在不会说“我在用 VMware ESX 写代码”，只会说“我在 AWS 上跑服务”。Agent runtime 正在走同一条路。而这条路的终点，不是 Anthropic 多卖了多少 token，而是 LangChain 团队要不要把langgraph.runtime模块彻底删掉，转而直接对接 AgentCore 的 SDK。

2. 架构解剖：为什么“Harness + Session + Sandbox”是必然，而非选择

2.1 Harness：无状态执行器的底层逻辑

先说最反直觉的一点：Harness 本身不应该是“智能”的。很多团队在自建 agent runtime 时，总想在 harness 层加一层“决策路由”或“子任务编排”，比如让 harness 根据当前 step 类型，动态选择调用哪个 tool 或切换哪个子 agent。这是典型的“把不该承担的责任硬塞给执行层”。Anthropic 把 harness 定义为纯粹的execute(name, input) → string，背后是三重硬约束：

第一，模型即唯一智能源。所有规划、反思、工具选择、错误恢复，必须发生在 LLM 的 prompt context 里。Harness 只负责把 prompt 送进去、把 response 拿出来、把 tool call 的 name 和 input 提取出来、再把 tool result 塞回去。任何在 harness 里做的“智能判断”，都会导致行为不可预测——因为 LLM 的输出格式稍有变化（比如多了一个空格、少了一个引号），harness 的正则解析就可能崩。我见过最惨的一次，是某团队在 harness 里写了个 JSON Schema 校验器，结果模型返回了"status": "success"，而 schema 要求"status": true，校验失败后 harness 直接抛异常终止 session，客户订单卡在支付确认页整整 17 分钟。

第二，可测试性优先于灵活性。一个纯函数式的 harness，意味着你可以用固定输入，100% 复现输出。我们给 harness 写单元测试时，只 mock 两个东西：LLM 的 response（固定字符串）和 tool 的返回值（固定 JSON）。测试用例覆盖所有边界：tool call 返回空、返回超大 JSON、返回非 JSON 字符串、LLM 返回不含 tool_call 的纯文本……这些测试在 CI 里跑 10 秒，而如果 harness 里掺了业务逻辑，测试就得启动整个 agent 流程，耗时从秒级变成分钟级，CI 成本指数上升。

第三，升级隔离性。当 Anthropic 下周发布 Claude 4，只要它保持execute(name, input)的接口契约不变，你的 harness 一行代码都不用改。但如果你的 harness 里写了“如果当前 step 是支付，则调用 Stripe API”，那么每次模型输出格式微调，你都得同步改 harness。这就是为什么 Anthropic 强调“harness can crash and resume from awake(sessionId)”——crash 不可怕，可怕的是 crash 后无法 resume，而 resume 的前提是 harness 不保存任何 state，state 全在外部 event log 里。

2.2 Session：事件日志为何必须是“持久化、可查询、带因果链”的

Anthropic 把 session 定义为“durable event log living outside the model context”，这句话里藏着三个必须满足的条件，缺一不可：

• Durable（持久化）：不是存在 Redis 缓存里，而是写入带 WAL（Write-Ahead Log）的 OLAP 数据库。我们用 ClickHouse 存 session event，每条 event 包含session_id,event_type（prompt_sent / tool_called / tool_result / response_received）,timestamp,payload_hash,parent_event_id。其中parent_event_id是关键——它把一次 tool call 和它触发的 response，以及 response 里可能包含的下一个 tool call，串成一条因果链。没有这个字段，你就只能看到一堆离散的时间戳，无法回答“用户问完价格后，agent 为什么去查库存而不是下单？”这种问题。

• Queryable（可查询）：不是简单地SELECT * FROM events WHERE session_id = ?。我们构建了专用视图：v_session_steps展示每一步的输入输出摘要；v_tool_latency按 tool name 统计 P50/P95 延迟；v_hallucination_candidates用规则匹配“response_received”事件中是否包含“根据我的知识”、“我无法访问”等高风险短语，并关联其前序 tool_result 是否为空。这些视图每天凌晨自动物化，BI 工具直接连上去就能看 dashboard。如果 session log 只是 JSON 文件堆在 S3，查询成本会高到没人愿意查。

• Causal Chain（因果链）：这是最容易被忽略的。很多团队以为存下 prompt 和 response 就够了，但 agent 的灵魂在于 tool interaction。一次完整的 session 至少包含：prompt_sent → tool_called → tool_result → response_received → (可能) next_tool_called。我们强制要求每个 event 必须记录causality_id（同一因果链内相同）和sequence_number（递增）。这样当某个 step 出问题，你可以用WHERE causality_id = 'xxx' ORDER BY sequence_number一键拉出完整链条，而不是在上千行日志里肉眼找关联。

提示：不要用 UUID 作为causality_id。我们试过，结果发现同一个 session 里，模型可能并行发起多个 tool call（比如同时查天气和查航班），它们的causality_id应该相同，但sequence_number不同。后来改用session_id + step_counter的组合，step_counter 在每次tool_called时递增，确保因果链严格有序。

2.3 Sandbox：为什么“cattle, not pets”是生产环境的生死线

Sandbox 不是容器，是 microVM。这是 AWS AgentCore 和 Anthropic Managed Agents 的根本差异，也是后者在安全合规场景下可能被绕过的硬伤。我们给一家银行做信贷审批 agent，客户明确要求：“所有外部 API 调用，必须运行在与主应用网络完全隔离、CPU/内存/磁盘 I/O 严格配额、且启动后不可修改的环境中”。AWS 的 microVM 满足全部：每个 session 独占一个轻量级虚拟机，内核级隔离，启动时注入只读 rootfs，network namespace 完全独立，连/proc/sys/net/ipv4/ip_forward都被禁用。而 Anthropic 的 sandbox，从文档描述看，仍是基于 containerd 的容器沙箱——它能防住大部分越界，但防不住内核级逃逸或 cgroup 配额绕过。

“Cattle, not pets” 的实操含义是：sandbox 生命周期必须短于 5 分钟，且绝不复用。我们线上集群的 sandbox 默认 TTL 是 300 秒，无论 session 是否结束。一旦超时，进程被 SIGKILL，容器被 unmount，rootfs 被 shred 清除。为什么？因为长生命周期 sandbox 会积累状态：临时文件、DNS 缓存、TCP 连接池、甚至被注入的恶意共享库。我们曾遇到一个 case：某 sandbox 运行了 47 小时，内部 curl 缓存了某个过期的 OAuth token，后续所有 tool call 都因 401 失败，但日志里只显示“API 调用失败”，没人想到去查 sandbox 内部的 curl cache。改成 5 分钟 TTL 后，问题消失。

注意：不要试图用 “sandbox reuse” 来优化性能。我们做过压测：复用 sandbox 能降低 12% 的冷启动延迟，但代价是 300% 的故障排查时间。当一个 session 出问题，你得在 100 个复用过的 sandbox 里定位是哪个出了问题；而用 cattle 模式，直接按session_id查 sandbox ID，5 秒定位。这笔账，运维团队算得比谁都清。

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

3.1 Agent 定义：YAML 不是配置，而是契约

Anthropic 允许用 YAML 或自然语言定义 agent，但生产环境必须用 YAML。原因很简单：YAML 是机器可读、可 diff、可版本控制的契约。我们团队的 agent.yaml 模板强制包含四个 section：

# agent.yaml metadata: name: "sales-lead-qualifier" version: "1.3.0" # 语义化版本，每次 tool schema 变更必升 description: "Qualifies inbound leads via email parsing and CRM lookup" system_prompt: | You are a sales lead qualifier for Acme Corp. Your job is to: - Parse email content to extract company name, contact person, use case. - Look up company in Salesforce CRM using the 'crm_lookup' tool. - If company exists and has >50 employees, route to Sales Dev team. - If company is new or <50 employees, route to Marketing for nurturing. tools: - name: "email_parser" description: "Extracts structured data from raw email text" input_schema: type: "object" properties: raw_email: {type: "string", description: "Full email body as string"} required: ["raw_email"] output_schema: type: "object" properties: company_name: {type: "string"} contact_person: {type: "string"} use_case: {type: "string"} - name: "crm_lookup" description: "Searches Salesforce CRM for company by name" input_schema: type: "object" properties: company_name: {type: "string"} required: ["company_name"] output_schema: type: "object" properties: sf_account_id: {type: "string"} employee_count: {type: "integer"} industry: {type: "string"} guardrails: - type: "output_safety" policy: "block_if_contains_pii" - type: "tool_call_limit" max_calls_per_session: 5 max_calls_per_tool: 2

这个 YAML 的每个字段都在解决一个真实痛点：

• version：当crm_lookup的output_schema从{employee_count: integer}变成{employee_range: string}（如 "1-50"），我们必须升版到1.4.0，否则旧版 agent 会把"1-50"当成整数解析失败。
• input_schema/output_schema：不是为了“类型安全”，而是为了自动生成 tool call 的 validation logic。我们的 harness 在调用 tool 前，会用 Pydantic V2 动态生成 validator，对input做严格校验，失败则直接返回 error message 给 LLM，而不是让 tool 自己崩溃。
• guardrails：tool_call_limit是血泪教训。某次模型陷入循环：parse_email → crm_lookup → parse_email → crm_lookup…，连续调用 237 次后耗尽 token 预算。现在所有生产 agent 都强制设置max_calls_per_session，超限后 harness 直接终止 session 并标记reason: "tool_call_limit_exceeded"。

3.2 Credential 隔离：Vault 注入的精确到毫秒

Credential 不进 sandbox，是底线。但 Anthropic 文档只说“credentials live in vaults the sandbox never sees”，没说怎么实现。我们的方案是：Vault Token + Init Container + Runtime Mount。

流程分三步：

1. Harness 启动时，向 HashiCorp Vault 请求一个 short-lived token（TTL=300s），权限仅限读取secret/data/agents/sales-lead-qualifier路径；
2. 启动一个 init container，用该 token 从 Vault 拉取 credentials（如 Salesforce API key），写入一个 tmpfs volume（内存盘，无落盘风险）；
3. 主 harness container 以readOnly: true方式挂载该 volume，路径为/run/credentials，且该 volume 不在 container 的PATH中，无法被 shell 命令直接访问。

关键细节在于init container 的镜像必须是白名单的、无 shell 的最小镜像。我们用gcr.io/distroless/static:nonroot，里面只有/bin/sh的符号链接，且被 chmod 000。即使攻击者突破 harness container，也无法执行sh来读取 credentials。

实操心得：Vault 的 secret path 必须按 agent name + version 命名，如secret/data/agents/sales-lead-qualifier/1.3.0。这样当 agent 升级到 1.4.0，可以无缝切换 credentials，旧版本 agent 仍用旧密钥，避免滚动更新时的密钥错配。

3.3 生产监控：P50/P95 只是起点，真正要看的是“Session Health Score”

Anthropic 宣称 p50 time-to-first-token 下降 60%，p95 更好于 90%。这数字很美，但对运维毫无意义。我们定义了Session Health Score（SHS），一个 0-100 的综合指标，由五个维度加权计算：

SHS 每 5 分钟计算一次，低于 80 触发告警。去年 Q3，我们发现 SHS 突然跌到 72，排查发现是email_parsertool 的响应时间 P95 从 1.2s 涨到 4.7s，原因是其依赖的 NLP 模型服务器内存泄漏。但传统 APM 只监控 HTTP 5xx，而email_parser返回 200 但耗时暴涨，SHS 是唯一能捕捉到的指标。

4. 竞争格局与价值迁移：为什么 runtime 创业公司正在失去定价权

4.1 Hyperscaler 的“免费-邻近”策略：不是补贴，而是采购卡绑定

AWS Bedrock AgentCore 的定价是“$0.00 per session-hour”，但有个隐藏条款：“需绑定最低 $5000/月的 Bedrock token spend”。这根本不是定价，是采购卡绑定术。企业 CIO 的年度云预算早已批好，$5000/月的 Bedrock 预算卡在财务系统里，AgentCore 就是这张卡的“默认支付通道”。你不用 AgentCore，就得单独申请一笔“agent runtime 专项预算”，走额外审批流——在大多数企业，这比技术选型难十倍。

我们帮一家零售巨头评估 runtime 方案时，财务总监直接说：“你们告诉我 Anthropic Managed Agents 每小时 $0.08，那我一年要多付多少？算清楚，我签字。” 我们算了：按他们预估的 200 万 session/year，约 $128,000。他听完笑了：“我们 Bedrock 预算卡里还有 $370,000 没花完，AgentCore 白用。你这 $128,000 是纯成本，不是投资。” ——这就是现实。Hyperscaler 不是在打价格战，是在把 runtime 变成云账单里的一个“已付费项”。

4.2 开源压力曲线：Daytona 和 Kubernetes SIG 的真实威胁

Daytona 宣称 sub-90ms sandbox spin-up，很多人觉得是营销话术。我们实测了：在 m6i.2xlarge（8vCPU/32GB）上，Daytona 启动一个 Python-based sandbox（含 requests、pydantic），平均 83ms，P99 112ms。而 Anthropic Managed Agents 的 cold start，我们实测是 1.2s（P50）到 3.8s（P99）。差距在哪？Daytona 用 Rust 写 runtime，预热时就把常用 tool 的二进制 cache 到内存，且 sandbox 启动不加载完整 Python 解释器，而是用micromamba按需安装最小依赖集。

更致命的是 Kubernetes SIG 的 agent-sandbox 项目。它不是一个 runtime，而是一个CRD（Custom Resource Definition）规范。定义了AgentSandbox这个资源对象，包含spec.toolImage,spec.resources,spec.vaultRef等字段。任何符合该 CRD 的 controller（比如 AWS 的、GCP 的、或者你自研的），都能创建 sandbox。这意味着：runtime 的接口标准正在被 Kubernetes 社区收编。未来你写 agent，不再关心是跑在 Anthropic 还是 AWS，只关心你的AgentSandboxYAML 是否合法。这比 Anthropic 的 YAML 更底层、更通用。

4.3 价值上移的三大锚点：Trace、Governance、Vertical

Trace Store：不是日志，是法律证据

Braintrust 的 Brainstore 为什么敢融 $36M？因为它把 session event 定义为“AI 交互的原始凭证”。我们给一家医疗科技公司做 HIPAA 合规 agent，监管要求：“任何 patient data 的处理，必须留存完整、不可篡改的操作链”。Brainstore 的 OLAP 表结构里，events表有is_phi_flag（是否含受保护健康信息）字段，由 harness 在写入前调用 AWS Comprehend Medical API 实时标注。一旦is_phi_flag=true，该 event 自动加密并写入专用 KMS 密钥保护的分区。审计时，只需提供session_id，Brainstore 生成 PDF 报告，包含每一步的 timestamp、operator（LLM 名称）、data_flow（哪些 PHI 被传入/传出）、signer（vault token 的签发者）。这已经不是可观测性，是合规基础设施。

Governance：OWASP Agentic Top 10 是采购准入门槛

OWASP Agentic Top 10 的第一条就是 “A1: Prompt Injection”。但企业采购部门不关心技术细节，只问：“你们如何证明 agent 不会被 prompt injection 攻击？” 我们的答案是：Policy-as-Code + 自动化扫描。我们用 Rego 语言写 policy rule：

package agent.governance default allow = false allow { input.event_type == "prompt_sent" not re_match(".*\\{\\{.*\\}\\}.*", input.payload) # 禁止 Jinja 模板语法 count(input.payload) < 10000 # 防止超长 prompt } allow { input.event_type == "tool_called" input.tool_name == "http_request" input.tool_input.url == "https://api.salesforce.com/..." }

每次 agent 部署前，CI 流水线自动运行opa eval -d policy.rego -i event.json，只有allow == true才允许上线。这套机制，让采购总监在合同里直接写入：“乙方须通过甲方 OWASP Top 10 Policy Compliance Scan”。

Vertical Marketplace：Salesforce Agentforce 的 ARR 是风向标

Salesforce Agentforce $800M ARR 的真相是：企业只为“能放进采购目录”的 agent 付费。Agentforce 的 catalog 里，每个 agent 都有标准 SKU：SF-AGENT-LEAD-QUALIFY-PRO，含明确 SLA（99.95% uptime, <2s response）、支持矩阵（Salesforce Classic / Lightning / Mobile）、合规认证（SOC2, HIPAA）、以及最关键的——按 seat 许可的定价模型。客户采购经理不需要懂 LLM，只需要知道“买 500 个 seat，每年 $120,000”。

我们自研的“金融风控 agent”，技术上远超 Agentforce，但销售时卡在“如何定价”。按 token？客户说“我们不为 token 付费，我们为减少坏账付费”。按 session？客户说“session 数量不可控”。最后我们学 Agentforce，推出FIN-AGENT-CREDIT-SCORING-ENTERPRISE，年费 $299,000，含 10,000 次评分/月，超量按 $15/千次。采购流程一周走完。技术再强，不变成采购目录里的 SKU，就只是实验室玩具。

5. 未来一年生存指南：Runtime 创业者的三条活路

5.1 如果你还在卖 runtime，立刻做三件事

1. 砍掉所有“runtime 性能对比”营销话术。别再发“我们的 sandbox 比 Anthropic 快 3.2 倍”的 PR。客户已经不在乎。把官网首页的 benchmark 图表，换成客户 logo + 一句：“已集成 AWS AgentCore / Azure AI Foundry / Google Vertex AI”。

2. 把 SDK 重构为“多 runtime 适配层”。你的价值不再是“我们自己的 runtime 多好”，而是“我们帮你无缝切换 runtime”。SDK 接口统一为AgentRuntime.execute(agent_config, session_state)，内部自动识别agent_config.runtime == "anthropic"或"bedrock"，调用对应 provider 的 SDK。客户换云厂商时，你 SDK 升级，他代码零改动。

3. 把 70% 的研发资源，转向 Trace & Governance 模块。在你的 runtime 控制台里，内置 Brainstore 兼容的 event export，内置 OWASP Top 10 自动扫描报告，内置 SOC2 合规检查清单。让客户意识到：“买 runtime，只是入口；买你们的 governance 套件，才是真正的合规保障。”

5.2 如果你是开发者，现在该学什么

• 忘掉“如何写 agent”，专注学“如何定义 agent 的契约”。掌握 OpenAPI 3.1 的x-agent-tool扩展，学会用 JSON Schema 描述 tool 的输入输出，理解callback_url如何替代 webhook 的脆弱性。

• 停止优化 LLM prompt，开始学习“如何审计 prompt”。用 LangSmith 的trace_evaluator写规则：if response contains "I don't know" and tool_call_count > 0 then flag as "tool_underutilization"。把 prompt 质量变成可量化、可告警的指标。

• 别再研究 sandbox 技术，深入理解“如何设计 credential 的最小权限”。学 HashiCorp Vault 的 dynamic secrets，学 AWS IAM Roles Anywhere，学如何让每个 tool 只拥有完成其任务所需的、精确到 API action 的权限。这才是生产环境的护城河。

5.3 如果你在做投资，看这三个信号

• 信号一：团队是否在招“合规工程师”而非“分布式系统工程师”。当一家 runtime 公司的招聘 JD 里，“熟悉 SOC2/ISO27001 审计流程” 出现在 “精通 Kubernetes Operator 开发” 之前，说明他们看清了方向。

• 信号二：产品是否内置“跨 runtime 迁移工具”。如果他们的控制台里，有 “Export to AgentCore YAML” 或 “Import from Vertex AI Agent Registry” 按钮，说明他们接受 commoditization，并把价值锚定在迁移成本上。

• 信号三：客户合同是否包含“vertical outcome guarantee”。比如 “部署 6 个月内，将销售线索转化率提升 15%，否则退还 50% 费用”。这代表他们已从 infrastructure vendor，转型为 outcome vendor。

我上周和 Anthropic 的一位前架构师喝咖啡，他坦言：“Managed Agents 的 OKR 里，没有‘runtime 市场份额’，只有‘Claude token usage growth from agent workloads’。我们卖的不是 runtime，是 token 的放大器。” 这句话道破天机。Runtime 层的战争已经结束，胜者是那些把 runtime 变成“空气”的人——你感觉不到它，但它无处不在。而真正的战场，早已上移到 trace 的深度、governance 的精度、vertical 的厚度。盯着 runtime 看的人，还在数沙粒；抬头看的人，已经在建城堡。