AI Agent 运行时基建：从 Session 日志到沙箱隔离的生产级实践

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

我第一次在生产环境里跑一个需要连续交互 30 分钟以上的 AI agent，是在 2025 年初。当时用的是自建 LangGraph + FastAPI + Redis 状态后端的方案。系统上线第三天，销售团队反馈：一个客户资料自动归档流程，在执行到第 7 步时突然把前 4 步的结果全丢了，最后生成的 PDF 里连客户公司名都错了。我们翻日志、查 Redis、重放 trace——全无异常。直到我把整个 session 的 context token 数打出来，才发现：它在第 28 分钟时悄悄越过了 Claude-3.5-sonnet 的 200K 上限，模型没报错，只是默默截断了最老的 3 个 tool call 历史，然后基于残缺上下文继续推理。没有崩溃，没有告警，只有静默的失效。那一次，我们花了 17 小时重建状态层，把所有中间结果存进 PostgreSQL，用 event sourcing 模式重写 session 管理逻辑。

Anthropic 在 4 月 8 日发布的 Claude Managed Agents ，本质上就是把我们当年踩坑后连夜重写的那一整套 state management + sandbox isolation + credential vaulting + trace persistence，封装成一个开箱即用的托管服务。它不解决“agent 能不能思考”这个根本问题，它解决的是“agent 思考完之后，能不能活下来、被看见、不闯祸”。关键词不是“agent”，而是 Managed —— 管理态，是运行时基础设施的工业化表达。

你不需要懂 Kubernetes，也不用配置 Istio 的 mTLS；你只需要写一段 YAML，定义 system prompt、允许调用的 tools（比如 Notion API、Asana webhook）、以及几条 guardrails（比如“禁止访问 /admin 路径”、“输出必须含中文摘要”），Anthropic 就给你一个带持久化 session、隔离沙箱、自动凭证轮换、全链路可审计的运行环境。它的 p50 首 token 延迟下降 60%，p95 改善超 90%，这些数字背后不是模型变快了，而是 runtime 层去掉了所有“不该由模型承担的负担”：状态不再挤在 context window 里，工具调用不再裸奔在容器网络中，凭证不再以 env var 形式暴露给 LLM 的 prompt 工程师。

这和 1990 年代 Linux 内核把硬件抽象成统一的文件描述符（/dev/ttyS0, /dev/sda）一样，Anthropic 把 agent 生命周期抽象成了三个稳定接口： Session（事件日志） 、 Harness（无状态执行器） 、 Sandbox（按需牲畜化环境） 。Session 不再是内存里的一段 JSON，而是一条写入 durable log store 的 append-only 流；Harness 不再维护任何本地状态，收到 awake(sessionId) 就从 log 中 replay 最后 checkpoint，然后调用 execute(toolName, input) ；Sandbox 更是彻底 cattle 化——每次 tool call 都启一个全新 microVM，用完即焚，连磁盘都是只读挂载。这种分层，让 model update 和 runtime update 完全解耦：明天 Claude-4 上线，你不用改一行 agent 代码，只要 Anthropic 更新 Harness 实现即可。

所以，这不是“Anthropic 又出了个新模型”，这是 runtime 层的“操作系统时刻”正式到来。它意味着： AI 应用开发的重心，正从“怎么让模型说对”加速转向“怎么让系统活久一点、别乱来、出事能查” 。如果你还在纠结 prompt engineering 的微调技巧，而没开始设计你的 event log schema 或 sandbox policy matrix，那你已经在基建迁移的列车外站台上了。

2. 核心架构拆解：为什么 Session-as-Event-Log 是唯一正确的起点

2.1 Session 不是存储，而是不可篡改的事实流

绝大多数早期 agent 框架（包括我们自己第一版）把 session 当作一个 key-value 存储： session_id → { "history": [...], "state": {...} } 。这看似合理，实则埋下三重隐患：

• 容量陷阱 ：context window 是硬上限。Claude-3.5-sonnet 的 200K tokens 听起来很大，但实际算一笔账：一次 Notion page 查询返回 5KB JSON，一次 Slack message 发送含 2KB payload，加上 system prompt（约 3KB）、tool description（平均 1.5KB/个）、LLM 自身推理 token（每次响应约 1.2KB），15 次交互就逼近 150K。第 16 次调用时，模型必须丢弃旧历史——而它不会告诉你丢的是哪一段，更不会保证丢弃的是“不重要”的部分。我们曾遇到过 agent 因为丢掉一条 get_customer_contact() 的返回，后续所有邮件发送都发给了错误邮箱，且全程无报错。

• 一致性漏洞 ：当多个前端（Web App、Slack Bot、iOS Widget）同时向同一 session 发起请求，KV 存储的并发更新极易导致状态撕裂。我们曾复现过：用户在 Web 端点击“重试上一步”，Slack 机器人同时收到新消息触发 analyze_new_lead() ，两个请求并发写入 Redis，最终 session history 里出现两条时间戳完全相同的记录，LLM 在下一步推理时看到矛盾事实，直接 hallucinate 出一个虚构的客户地址。

• 审计盲区 ：KV 存储只保存“当前快照”，无法回答“谁在什么时间触发了什么操作”“某次失败的 tool call 输入是什么”。当合规部门要求提供某次金融咨询 agent 的完整决策链时，我们只能交出一份缺失中间步骤的 summary，因为那些被 GC 掉的临时状态早已消失。

Anthropic 的 Session-as-Event-Log 直接绕过这三重陷阱。它强制采用 append-only WAL（Write-Ahead Log） 模式：每一次 agent action（model output、tool call request、tool response、guardrail trigger）都作为一条结构化 event 写入持久化 log store（底层很可能是 Amazon QLDB 或类似 immutable ledger）。每条 event 包含：

• event_id : UUIDv7（带时间戳，天然有序）
• session_id : 关联会话
• timestamp : 精确到纳秒
• type : "model_output", "tool_call", "tool_response", "guardrail_violation"
• payload : JSON 序列化内容（含完整 input/output）
• metadata : 执行 harness ID、sandbox ID、trace_id

这意味着：
✅ 你可以随时 SELECT * FROM events WHERE session_id = 'xxx' ORDER BY timestamp 得到完整、不可篡改的操作流水；
✅ 你可以 REPLAY FROM event_id = 'xxx' 让任意 harness 从任意 checkpoint 恢复执行，无需担心状态丢失；
✅ 你可以 WHERE type = 'tool_call' AND payload.tool_name = 'send_email' 快速审计所有邮件发送行为；
✅ 你甚至可以 JOIN events e1 ON e1.session_id = e2.session_id AND e1.timestamp < e2.timestamp 构建因果图谱，分析“某次失败是否由前序某次 API 限流导致”。

提示：这种设计并非 Anthropic 首创，而是将数据库领域的 WAL 思想迁移到 AI runtime。其核心价值在于—— 把“发生了什么”从模型的黑盒记忆，变成系统可编程、可查询、可审计的白盒事实 。这不再是工程优化，而是生产级 AI 系统的合规底线。

2.2 Harness：无状态执行器的“函数即服务”本质

Harness 是 Managed Agents 架构中最反直觉也最关键的一环。它被刻意设计成 100% 无状态 ：不缓存任何 session 数据，不维护 connection pool，不持有任何 credentials。它的全部职责只有一个：接收 awake(sessionId, lastEventId) 请求，从 event log 中读取 lastEventId 之后的所有 events，replay 出当前 session state，然后执行 execute(toolName, input) 并返回 string。

这种设计带来三个硬性约束，每个都直指生产痛点：

• Crash Safety ：Harness 进程崩溃？没关系。下次 awake() 调用时，它会自动从 log 中 replay 到崩溃前最后一个 event，继续执行。我们曾在线上环境故意 kill harness pod，验证过：从崩溃到恢复 service 的 MTTR（Mean Time To Recovery）小于 800ms，且零数据丢失。对比传统方案中“进程挂了 session 就死”，这是质的飞跃。

• 弹性伸缩 ：Harness 实例可以无限水平扩展。因为所有状态都在 log 里，新实例启动后只需拉取 log 片段即可工作。我们压测过：当并发 session 数从 1000 突增至 5000 时，AWS Auto Scaling 在 42 秒内完成 12 个新 harness 实例的部署与注册，所有新增请求均被正确路由，无 session 中断。这得益于 Harness 与 log store 的松耦合——log 是 shared storage，harness 是 stateless worker。

• 模型无关性 ：Harness 不绑定任何特定模型。Anthropic 当前用 Claude，但理论上它可以调度任何支持标准 JSON-RPC 的 LLM endpoint。这意味着：当你未来想把某个高敏感度的 finance agent 切换到本地部署的 Llama-3-70B（满足数据不出域要求），只需修改 harness 的 routing config，无需重构整个 agent 逻辑。这种解耦，正是 OS 层虚拟化的精髓——硬件细节（模型实现）被抽象掉，上层应用（agent behavior）得以自由迁移。

注意：Harness 的 execute() 接口看似简单，但其背后是严格的 sandbox lifecycle management。每次调用都会触发：1) 创建新 microVM；2) 注入 tool spec（不含 credentials）；3) 挂载只读 rootfs + tmpfs /tmp；4) 执行 tool binary；5) 捕获 stdout/stderr；6) 销毁 microVM。整个过程平均耗时 320ms（p95），其中 210ms 花在 VM boot，这解释了为什么 Anthropic 强调 “sandbox as cattle”——你永远不该期待单次 sandbox 启动有多快，而应设计成“批量预热 + 快速销毁”的模式。

2.3 Sandbox：凭证隔离的“零信任”实践

Credential isolation 是 Managed Agents 在企业级场景中真正立住脚的关键。Anthropic 的做法极其激进： credentials 从不进入 sandbox 环境，更不会以 environment variable 形式暴露给 LLM 的 prompt 。

具体实现分三层：

1. Vault Integration ：所有 credentials（Notion API keys、Slack bot tokens、Salesforce OAuth refresh tokens）统一存入 Anthropic 托管的 Vault（底层应为 HashiCorp Vault Enterprise with PKI backend）。每个 credential 有独立 TTL（如 Slack token 90 天自动轮换）、access policy（仅允许 sales-agent harness 调用）、audit logging。

2. Sandbox Provisioning ：当 harness 决定调用 notion_search_pages 时，它向 Anthropic control plane 发起 get_tool_credential(tool_id='notion_search_pages', session_id='xxx') 请求。control plane 验证 session 权限、tool binding 策略、credential TTL 后，动态生成一个 short-lived, scoped, one-time-use credential （例如：一个 5 分钟有效期、仅允许 POST /v1/search 的 JWT），并将其注入 sandbox 的 secure enclave（非普通 env var）。

3. Tool Runtime Binding ：sandbox 内的 tool binary（如 notion-cli ）在启动时，从 enclave 读取该临时 credential，并直接用于 HTTP Authorization header。LLM 的 prompt 中永远看不到任何 token 字符串——它只看到 "notion_search_pages(input: str) -> List[Page]" 的 function signature。

这种设计堵死了所有已知的 credential leak 通道：

• ❌ Prompt injection：攻击者无法通过 {{user_input}} 注入恶意指令窃取 env var；
• ❌ Log leakage：sandbox stdout/stderr 不含 credential，log store 中的 tool_call event 只记录 {"tool": "notion_search_pages", "input": "Q4 report"} ，无 credential 字段；
• ❌ Memory dump：microVM 内存中 credential 存于 CPU secure enclave（如 AMD SEV-SNP），物理内存 dump 无法读取；
• ❌ Accidental exposure：开发者无法在 debug 时 print(os.environ) 泄露 token。

我们曾用 Burp Suite 模拟 prompt injection 攻击，尝试让 LLM 输出 os.environ ，结果得到 {'PATH': '/usr/bin:/bin', 'LANG': 'en_US.UTF-8'} —— credential 字段根本不存在。这才是真正的 zero-trust。

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

3.1 Agent 定义：YAML 是声明式运维的起点

Managed Agents 的入口是 YAML 文件，它不是配置文件，而是 agent 的 IaC（Infrastructure as Code）定义 。一个典型的企业级 sales agent 定义如下（已脱敏）：

# sales-agent.yaml
name: "enterprise-sales-agent"
description: "Handles qualified leads from website forms and routes to correct rep"
version: "1.2.0"

system_prompt: |
  You are a senior sales development representative at Acme Corp.
  Your goal is to qualify leads and assign them to the right account executive.
  Rules:
  - Only assign leads with company_revenue >= $10M and industry in ['Finance', 'Healthcare', 'Tech']
  - If lead is unqualified, send polite rejection email via SendGrid
  - Always output final decision in JSON format with keys: assigned_to, reason, next_step

tools:
  - id: "fetch_lead_data"
    name: "fetch_lead_data"
    description: "Fetch full lead details from CRM by lead_id"
    spec: |
      {
        "type": "http",
        "method": "GET",
        "url": "https://api.acme-crm.com/v2/leads/{lead_id}",
        "headers": {"Authorization": "Bearer <token>"}
      }
    # Note: <token> is NOT literal — it's injected by vault at runtime

  - id: "assign_to_rep"
    name: "assign_to_rep"
    description: "Assign lead to AE based on territory rules"
    spec: |
      {
        "type": "function",
        "name": "assign_lead",
        "parameters": {
          "type": "object",
          "properties": {
            "lead_id": {"type": "string"},
            "territory": {"type": "string"}
          }
        }
      }

  - id: "send_rejection_email"
    name: "send_rejection_email"
    description: "Send polite rejection email via SendGrid"
    spec: |
      {
        "type": "http",
        "method": "POST",
        "url": "https://api.sendgrid.com/v3/mail/send",
        "headers": {"Authorization": "Bearer <token>", "Content-Type": "application/json"}
      }

guardrails:
  - id: "prevent_pii_leak"
    type: "output_filter"
    config:
      patterns:
        - "SSN: [0-9]{3}-[0-9]{2}-[0-9]{4}"
        - "credit_card: [0-9]{4} [0-9]{4} [0-9]{4} [0-9]{4}"
      action: "redact"

  - id: "block_admin_access"
    type: "tool_call_filter"
    config:
      blocked_tools: ["delete_lead", "update_crm_config"]
      action: "deny"

policies:
  - id: "data_residency"
    type: "region_constraint"
    config:
      allowed_regions: ["us-west-2", "us-east-1"]

这个 YAML 文件包含四个关键维度：

• Behavioral Contract （ system_prompt ）：用自然语言定义 agent 的角色、目标、规则。Anthropic 的 parser 会将其编译为 structured prompt template，确保 LLM 严格遵循格式（如强制 JSON 输出）。
• Capability Interface （ tools ）：每个 tool 的 spec 是 OpenAPI-like 描述，明确输入/输出 schema、HTTP method、URL 模板。Harness 会据此生成类型安全的 client stub，避免 runtime 类型错误。
• Safety Boundary （ guardrails ）： output_filter 在 LLM 输出后做正则扫描并脱敏； tool_call_filter 在调用前拦截危险操作。二者均支持 custom Python hook（需 Anthropic 审批）。
• Compliance Envelope （ policies ）： region_constraint 强制 sandbox 必须部署在指定 AWS region，满足 GDPR/CCPA 数据驻留要求。

实操心得：不要试图在 system_prompt 中写复杂逻辑。我们曾把“根据 12 个字段计算 lead score”的规则全塞进 prompt，结果 LLM 经常漏算某项。正确做法是：1) 将 score 计算封装为独立 tool（ calculate_lead_score ）；2) 在 prompt 中只写“调用 calculate_lead_score 获取分数，然后按分数阈值决策”。这样既保证计算精度，又让逻辑可测试、可审计。

3.2 Session 生命周期管理：从创建到归档的七步闭环

Managed Agents 的 session 不是“启动即存在”，而是 按需创建、显式管理、自动归档 。一个典型 session 的完整生命周期如下（以 Notion 集成场景为例）：

1. Session Creation （Webhook Trigger）
   用户在 Notion 页面点击 “Delegate to Claude”，Notion webhook 发送 POST 到 https://api.anthropic.com/v1/agents/sales-agent/sessions ，body 包含：

   {
     "initial_input": "Lead ID: lead_abc123",
     "metadata": {"notion_page_id": "p-xyz789", "triggered_by": "user@acme.com"},
     "timeout_minutes": 1440  // 24 hours
   }
   

   Anthropic 返回 session_id: sess_xyz789 和 session_url: https://api.anthropic.com/v1/sessions/sess_xyz789 。

2. Harness Activation & Replay
   Harness 实例收到 awake(session_id='sess_xyz789') ，从 log store 读取所有 events（当前为空），初始化 state，准备执行。

3. First Tool Call
   LLM 输出： {"tool": "fetch_lead_data", "input": {"lead_id": "lead_abc123"}} 。Harness 验证 tool binding 策略，调用 get_tool_credential('fetch_lead_data', 'sess_xyz789') ，获取临时 token，启动 sandbox 执行 HTTP GET。

4. Tool Response Handling
   sandbox 返回 {"company_name": "Acme Finance", "revenue": 12500000, "industry": "Finance"} 。Harness 将此 event 写入 log，然后 replay 新 state，触发 LLM 下一轮推理。

5. Guardrail Enforcement
   LLM 输出中包含 "reason": "Qualified: revenue $12.5M > $10M" ，但 output_filter 检测到 revenue: 12500000 可能泄露敏感数值，自动 redact 为 revenue: [REDACTED] ，并记录 guardrail_violation event。

6. Session Persistence
   每次 event 写入 log 后，Harness 更新 session 的 last_active_at timestamp。如果 30 分钟内无新 event，session 进入 idle 状态，harness 释放资源，但 log 保留。

7. Auto-Archive & Cleanup
   session 达到 timeout_minutes （24h）或显式调用 DELETE /sessions/sess_xyz789 后，Anthropic 执行：

   • 标记 log 为 archived （仍可查询，但不计入 active session-hour 计费）；
   • 删除所有关联 sandbox artifacts（VM images, tmpfs）；
   • 触发 S3 lifecycle rule 将 log segment 转为 Glacier IR（低成本长期归档）。

注意：session-hour 计费只计算 active runtime ，即 harness 处理请求的时间（从 awake() 到返回响应），不包括 idle 时间。我们测算过：一个平均处理 8 步的 sales lead session，active time 约 4.2 分钟，即使 session 存活 24 小时，计费也仅为 (4.2/60) * $0.08 ≈ $0.0056 。这比自建 Kubernetes cluster 的固定成本低两个数量级。

3.3 生产部署实战：与现有 MLOps 栈的集成策略

Managed Agents 并非要取代你的 MLOps 栈，而是作为 runtime layer 无缝嵌入 。我们在一家金融科技客户落地时，采用了以下集成模式：

最关键的集成点是 event log export 。Anthropic 允许你配置 S3 bucket 作为 log sink，每 5 分钟将新 events 以 Parquet 格式写入 s3://my-bucket/anthropic/events/year=2026/month=04/day=08/ . 我们用 Snowflake 的 CREATE EXTERNAL TABLE 直接查询：

CREATE OR REPLACE EXTERNAL TABLE anthropic_events (
  event_id STRING AS (value:event_id::STRING),
  session_id STRING AS (value:session_id::STRING),
  type STRING AS (value:type::STRING),
  payload VARIANT AS (value:payload::VARIANT),
  timestamp TIMESTAMP_NTZ AS (value:timestamp::TIMESTAMP_NTZ)
)
LOCATION = @anthropic_s3_stage/events/
FILE_FORMAT = (TYPE = PARQUET);

这样，业务分析师可以直接用 SQL 分析：“过去 7 天，哪些 tool_call 的失败率 > 5%？”、“ assign_to_rep 的平均响应时间是否随 territory 数量增加而线性上升？”——这不再是工程师的 debug 工具，而是产品迭代的数据基石。

4. 竞争格局与避坑指南：为什么现在入场还来得及，但必须选对楼层

4.1 四大 runtime 竞争者的真实能力矩阵

Anthropic Managed Agents 并非孤例。截至 2026 年 4 月，主流云厂商和开源社区已形成四股力量。我们基于真实 PoC（Proof of Concept）测试，整理出关键能力对比表：

这张表揭示了一个残酷现实： 没有一家 runtime 是完美的，但每家都在自己最擅长的领域筑起高墙 。Anthropic 胜在架构纯粹性（WAL + cattle sandbox），AWS 胜在生态开放性（任何框架都能跑），Google 胜在数据工程深度（BigQuery 原生支持），Azure 胜在企业治理（Azure Policy 无缝集成）。

实操心得：不要迷信“一家通吃”。我们为客户设计的混合架构是：核心金融 agent（强合规）跑在 Azure AI Foundry（利用其 Azure Policy）；内部运营 agent（快速迭代）跑在 Anthropic（享受其 YAML 简洁性）；而数据分析 agent（需调用 Spark）跑在 AWS AgentCore（因其框架无关性）。runtime 层本就不该是单点依赖。

4.2 三大致命陷阱：90% 的早期 adopter 正在踩

基于我们协助 12 家企业落地 Managed Agents 的经验，总结出三个最高频、最昂贵的陷阱：

陷阱一：把 Managed Agents 当作“免运维”幻觉
很多团队以为“用了托管服务就不用管 infra”，结果在 production 环境遭遇：

• Sandbox Cold Start Latency ：首次 tool call 平均 420ms，p95 达 850ms。当用户期望“点击即响应”，这个延迟不可接受。
  ✅ 正确解法：对高频 tool（如 search_knowledge_base ）实施 pre-warm 。我们用 Lambda 每 5 分钟调用一次 execute('search_knowledge_base', 'test') ，保持 sandbox pool 热备，将 p95 降至 210ms。

陷阱二：Guardrail 设计的“过度自信”
客户曾要求：“禁止 agent 输出任何电话号码”。我们配置了正则 r'\b\d{3}[-.]?\d{3}[-.]?\d{4}\b' ，结果 agent 在输出 +1 (555) 123-4567 时被误判，整个响应被 redact。更糟的是，LLM 因未收到有效输出，反复重试，触发 rate limit。
✅ 正确解法：guardrail 必须 fail open, not fail closed 。我们改为：1) 用 NER 模型（spaCy）精准识别 PII；2) redact only confirmed matches；3) 在 redact 后插入 "[PII REDACTED FOR COMPLIANCE]" 占位符，确保 LLM 输出结构完整。

陷阱三：Session Debugging 的“黑盒依赖”
当 session 失败时，90% 的团队第一反应是看 Anthropic 控制台的 error message。但很多问题（如 tool_call timeout）在控制台只显示 Execution failed ，无 stack trace。
✅ 正确解法： 强制所有 tool 实现 health check endpoint 。我们在每个 tool binary 中加入 /healthz ，返回 { "status": "ok", "latency_ms": 120, "credential_valid": true } 。当 session 失败时，先调用所有关联 tool 的 healthz，快速定位是网络问题、credential 过期还是 tool 本身故障。我们因此将平均 MTTR 从 47 分钟降至 6.3 分钟。

4.3 价值迁移地图：哪里才是你应该押注的“下一楼”

回到文章开头的核心论断： runtime 层正在 commoditize，价值正向上迁移 。基于我们跟踪的 37 个 AI infra 创业公司融资动态，价值高地已清晰浮现：

第一高楼：Trace Store as System of Record
Braintrust 的 Brainstore（OLAP for AI logs）已拿下 3 家 Fortune 500 客户，其核心壁垒不是查询速度，而是 schema evolution resilience 。当 Anthropic 升级 event schema（如新增 tool_response_size_bytes 字段），Brainstore 能自动 backfill 旧数据，且不中断查询。这解决了企业最痛的点： runtime 可以换，但 trace 数据必须永久可查 。如果你在构建 agent，今天就该把 event log 导出到 Brainstore 或 Arize Phoenix，而不是只依赖 Anthropic 的临时查询 API。

第二高楼：Policy-as-Code Engine
AWS AgentCore 的 policy controls GA 后，我们看到一个新趋势：企业不再满足于“禁止调用 delete_api”，而是要求“ 仅当用户角色为 'compliance-officer' 且请求时间在 9AM-5PM EST 时，才允许调用 delete_api ”。这催生了 Policy-as-Code 工具链，如 Open Policy Agent（OPA）的 agentic extension。我们已用 Rego 编写 23 条企业级 policy，例如：

package agent.policy

default allow = false

allow {
  input.session.metadata.user_role == "compliance-officer"
  input.event.type == "tool_call"
  input.event.payload.tool_name == "delete_lead"
  hour_of_day(input.event.timestamp) >= 9
  hour_of_day(input.event.timestamp) <= 17
  timezone_of(input.event.timestamp) == "America/New_York"
}

这种细粒度、可测试、可版本控制的 policy，才是 runtime commoditization 后的真正护城河。

第三高楼：Vertical Agent Marketplace
Salesforce Agentforce 的 $800M ARR 证明： 企业愿为“解决具体问题的 agent”付费，而非“能跑 agent 的 runtime” 。我们正与医疗客户共建 claims-processor-agent ，它不卖 runtime，而是按 processed claim 数收费（$0.12/claim）。其核心资产是：

• 垂直知识库（CMS 1500 个 ICD-10 code 的映射规则）；
• 合规 workflow（HIPAA audit trail 自动生成）；
• 与 payer systems 的 pre-certified connector（已通过 UnitedHealthcare 认证）。
  这些资产无法被 runtime 替代，它们才是客户愿意签 3 年合同的理由。

我个人在实际操作中的体会是： 2026 年的 AI infra 创业，已经从“造轮子”进入“铺铁轨”阶段 。你不必再发明新的 runtime，但必须成为最懂某条垂直铁轨（如保险理赔、跨境支付、临床试验）的铺轨专家。Runtime 会越来越便宜，而铁轨上的专有知识、合规认证、客户信任，才是十年价值的真正来源。