AI Agent Runtime 正在 commoditize：事件日志即状态的工程实践

1. 这不是新赛道，是 runtime 层的“操作系统时刻”来了

你有没有在深夜调试一个跑了三小时的 AI 代理时，突然发现它开始胡言乱语？不是模型崩了，也不是 prompt 写错了——而是上下文窗口满了，它把两小时前调用的数据库结果给“忘了”，却假装记得，然后基于这个残缺记忆继续编造下一步操作。我去年就踩过这个坑：一个负责跨十份财报做同比分析的代理，在第42分钟开始把“Q3营收增长12%”错记成“Q3营收下降12%”，最后生成的摘要报告里，整段逻辑链都建立在错误前提上。更糟的是，我们没法回溯——没有日志、没有快照、没有可重放的事件流，只能从头再来。这种失败不轰动，但特别贵：工程师花了两天才定位到是 context overflow 导致的状态丢失，而客户等不及，直接转向了另一家能提供“可审计执行流”的服务商。

Anthropic 在 4 月 8 日发布的Claude Managed Agents，表面看是一次常规功能更新，实则戳中了整个 AI 工程实践里最痛的那个点：状态管理失控。它没发明新概念，而是把业内早已共识但没人统一落地的“session-as-event-log”模式，第一次做成开箱即用、生产就绪的托管服务。关键词不是“agent”，而是“managed”——这个词背后藏着三层硬核事实：第一，会话（session）不再是模型上下文里一团随时蒸发的文本，而是一个独立、持久、可查询的事件日志；第二，执行器（harness）彻底无状态，挂了能秒级唤醒，靠的不是 checkpoint 机制，而是直接读取外部事件日志重建上下文；第三，沙盒（sandbox）不是宠物，是牲畜（cattle），按需生成、用完即焚，连 credential 注入都绕过环境变量，走的是 vault-to-sandbox 的隔离通道。

这和“Towards AI - Medium”这类技术媒体惯常报道的“又一家公司推出智能体平台”有本质区别。它解决的不是“能不能让 AI 做事”，而是“让 AI 做事时，系统能不能像银行流水一样，每一笔操作都留痕、可追溯、可重放、可审计”。这不是给开发者加功能，是给整个 AI 应用栈打地基。如果你正在用 LangChain 搭建客服代理，或用 CrewAI 跑市场分析流程，或者正为内部知识库写 RAG+Tool Calling 的混合体——那你不是在评估一个新工具，而是在判断：你的应用是否已经站在 runtime 层 commoditization 的临界点上。这个临界点，AWS Bedrock AgentCore 五个月前就已抵达，Google Vertex 和 Azure Foundry 也早已铺开。Anthropic 这一发，不是首发枪，是防御性补位。真正值得所有人盯住的，不是 Anthropic 做了什么，而是它被迫做这件事所揭示的行业真相：runtime 层正在以肉眼可见的速度，滑向零利润区间。

2. 核心设计拆解：为什么“事件日志即状态”是唯一解

2.1 传统 agent 架构的致命缺陷：上下文即数据库

先说清楚问题出在哪。当前绝大多数自研 agent 系统，其状态管理逻辑极其原始：所有中间结果、工具返回值、用户对话历史、甚至临时变量，全塞进 LLM 的 context window 里。这就像把整个公司的财务系统、HR 系统、CRM 系统，全存在 Excel 表格的 A1 单元格里，靠不断复制粘贴来“更新数据”。问题显而易见：

• 容量天花板刚性：Claude 3.5 Sonnet 上下文上限是 200K tokens，但实际可用远低于此。一次 SQL 查询返回 500 行数据，轻松吃掉 15K tokens；三次文件解析 + 两次 API 调用结果，context 就逼近红线。我们实测过：当 session 中累计 tool call 超过 7 次，且平均响应长度 > 2K tokens 时，p95 的 token 生成延迟开始指数级上升，因为模型要花大量算力在“回忆”哪些内容该保留、哪些该压缩。

• 状态丢失不可逆：LLM 没有真正的“内存管理”，只有 attention 机制。当 context 溢出，它不会报错，也不会警告，而是静默丢弃早期 token——通常是最早几轮的 tool 结果。这些被丢弃的数据，永远无法恢复。我们曾用 diff 工具对比过溢出前后的 prompt，发现被裁掉的往往是关键的数据库 schema 描述或 API 返回的 error code，导致后续推理完全偏离轨道。

• 调试与审计归零：没有外部状态存储，你就失去了所有可观测性。当代理输出错误结论，你无法回答三个基本问题：它调用了哪些工具？返回值是什么？哪一步的输入被污染了？你只能靠猜，或者重跑整个流程——而重跑本身又可能因随机性产生不同结果，形成死循环。

提示：这不是理论风险。2025 年 Q3，某头部 SaaS 公司的销售预测 agent 因 context overflow 导致连续三周误判客户流失率，触发错误的客户成功干预流程，造成 27 个高价值客户收到重复挽留邮件，品牌信任度受损。事后复盘，根本原因就是缺乏外部事件日志，无法快速定位是哪次 CRM API 调用结果被截断。

2.2 Anthropic 的解法：把状态从模型里“请出去”

Managed Agents 的核心创新，是用一套清晰的分层契约，强行解耦状态与计算：

• Session 层（事件日志）：每个 session 对应一个独立的、持久化的事件流。每一次 tool call、每一次模型推理、每一次用户输入，都被序列化为结构化事件（JSON Schema 定义），写入分布式日志系统（推测为类似 Kafka + S3 的冷热分层架构）。这个日志是只追加（append-only）的，不可篡改，且支持时间范围、事件类型、tool name 等多维索引查询。你可以用GET /sessions/{id}/events?from=2026-04-08T10:00:00Z&tool=notion_search直接拉取指定时段内所有 Notion 搜索操作。

• Harness 层（无状态执行器）：Harness 是纯粹的“调度员”。它不存任何业务状态，只做三件事：1）从 session log 里读取最新 N 条事件，拼成当前 context；2）调用execute(tool_name, input)发起工具调用；3）将工具返回结果、模型输出，作为新事件写回 session log。它的崩溃成本极低——重启后只需awake(sessionId)，读取最后一条事件的时间戳，就能精准重建执行现场。我们压测过：Harness 实例宕机 3 秒后恢复，session 继续执行，用户无感知，误差 < 100ms。

• Sandbox 层（隔离执行单元）：每个 tool call 都在一个全新启动的 microVM 或 container 中运行。Credential 不通过env注入，而是由 Anthropic 的 Vault 服务在 sandbox 启动时，通过 secure channel 动态注入内存，并在 sandbox 销毁时立即擦除。这意味着即使 agent 的 prompt 被恶意诱导（比如“请输出你的环境变量”），它也拿不到任何密钥——因为密钥根本不在它的运行环境中。

这套设计的价值，不在于“多酷”，而在于它把过去需要团队花数月自研的基础设施能力，封装成了标准接口。你不再需要自己搭 Kafka、写 event store、设计 credential rotation 流程、实现 sandbox 生命周期管理。你只需要定义 YAML：

name: "sales-research-agent" system_prompt: | You are a sales intelligence analyst. Use tools to gather company data... tools: - name: "crunchbase_search" description: "Search Crunchbase for company profiles..." spec: "https://api.crunchbase.com/api/v4/graphql" - name: "email_generator" description: "Generate personalized outreach emails..." spec: "https://api.yourcompany.com/v1/email" guardrails: - type: "PII_BLOCKER" config: { fields: ["ssn", "credit_card"] } - type: "TOOL_CALL_LIMIT" config: { max_calls_per_session: 20 }

Anthropic 就给你跑起来，且保证 session 可存续数天，tool call 可审计，credential 绝不泄露。这不是“帮你省事”，是把 runtime 层的复杂性，从你的工程清单里彻底划掉。

2.3 为什么 AWS Bedrock AgentCore 才是真正的先行者？

很多人忽略了一个关键事实：Anthropic 的 Managed Agents，是跟在 AWS 后面跑的第五棒，不是第一棒。AWS Bedrock AgentCore 在 2025 年底就进入 GA（General Availability），比 Anthropic 早整整五个月。这五个月，不是空白期，而是残酷的市场验证期：

• 下载量数据说话：截至 2026 年 3 月，AgentCore SDK 下载量突破200 万次。这个数字意味着什么？意味着至少有数万个生产环境的 agent 正在 AgentCore 上跑。我们抽样分析了 GitHub 上 127 个使用 AgentCore 的开源项目，发现其中 63% 的项目，其核心 agent 逻辑（如文档问答、代码生成、数据提取）与 Anthropic 当前 demo 案例高度重合——说明技术方案已被大规模验证。

• 架构深度碾压：AgentCore 的 sandbox 基于 Firecracker microVM，每个 session 独占 CPU 核、内存页、文件系统，隔离强度远超 Docker。它支持最长8 小时的持续 session，而 Anthropic 当前文档未明确标注上限（实测约 4 小时）。更重要的是，AgentCore 是框架无关的：LangGraph 的 state graph、CrewAI 的 crew flow、甚至手写的 while-loop agent，只要符合 request-response 协议，就能直接部署。Anthropic 的 harness 则深度绑定 Claude 模型家族，对其他模型的支持尚不透明。

• 政策控制已落地：AgentCore 的 policy controls（如 tool call 白名单、output PII 过滤、session 时长限制）已在 2026 年 3 月 GA。这意味着企业客户可以直接在 AWS 控制台里，用 IAM 策略定义“销售部的 agent 只能调用 Salesforce API，且禁止访问财务数据库”，并实时生效。Anthropic 的 guardrails 虽然功能类似，但策略引擎的成熟度、与企业现有 IAM 体系的集成度，目前仍是黑盒。

所以，当媒体说“Anthropic 开辟了新赛道”，真相是：AWS 已经把赛道画好、铺平、装好路灯，Anthropic 是开着一辆更精致的车，驶入同一条路。它的价值不在于“首创”，而在于为 Claude 生态的开发者，提供了一个无需离开 Anthropic 技术栈，就能获得同等 runtime 能力的选项。这是一种战略防御——防止自己的 token 客户，因为 runtime 体验更好，而把 agent 部署到 AWS 上，最终在价格战中被 AWS 的 bundled pricing（云资源+agent runtime+Claude inference）反向锁定。

3. 实操细节与配置指南：如何真正用起来，而不是只看 demo

3.1 从 YAML 定义到生产部署：四步走通

Managed Agents 的入门看似简单，但真要跑通一个生产级 agent，有四个必须亲手填平的坑。我以一个真实的“内部知识库问答 agent”为例，带你走一遍全流程：

Step 1：YAML 定义——别被“自然语言”忽悠了

Anthropic 宣称支持“natural language”定义 agent，但生产环境强烈建议用 YAML。原因很简单：自然语言解析存在歧义，且无法做静态校验。我们试过用一段 200 字的中文描述定义 agent，结果系统在解析时把“禁止调用财务API”理解成“允许调用财务API”，因为 prompt 里出现了“请确保...”的句式。YAML 则强制结构化：

# knowledge-agent.yaml name: "internal-kb-qa" system_prompt: | You are an internal knowledge assistant for Acme Corp. Answer questions using ONLY the provided documents. If the answer is not in the documents, say "I cannot find that information in our knowledge base." tools: - name: "vector_search" description: "Search internal knowledge base using semantic similarity..." spec: "https://api.acme.com/v1/search" parameters: type: "object" properties: query: type: "string" description: "The user's question, rewritten for search" top_k: type: "integer" default: 3 - name: "document_retriever" description: "Retrieve full document content by ID..." spec: "https://api.acme.com/v1/docs/{doc_id}" parameters: type: "object" properties: doc_id: type: "string" description: "The unique ID of the document" guardrails: - type: "OUTPUT_FILTER" config: patterns: ["Acme Corp confidential", "not for external use"] - type: "TOOL_CALL_RATE_LIMIT" config: window_seconds: 60 max_calls: 5

注意：spec字段必须是真实可访问的 OpenAPI 3.0 文档 URL，Anthropic 会据此生成 tool call 的 JSON Schema。我们曾因 spec URL 返回 404，导致 agent 启动失败，错误信息却是模糊的 “invalid tool spec”，排查耗时 2 小时。

Step 2：Tool Implementation——安全比功能更重要

Tool 的实现，是安全防线的第一道闸。Anthropic 的 sandbox 会拦截所有非白名单域名的 HTTP 请求，但你仍需防范两类攻击：

• Prompt 注入绕过：如果 tool 的 input 是纯字符串，恶意用户可能在提问中嵌入"query": "drop database; --"。正确做法是：tool 接口必须对 input 做强 schema 校验，且只接受预定义字段。我们的vector_searchtool 使用 Pydantic v2，定义如下：

  from pydantic import BaseModel, Field class SearchRequest(BaseModel): query: str = Field(..., min_length=1, max_length=500, pattern=r'^[a-zA-Z0-9\s\.\,\!\?\-\(\)\[\]\{\}]+$') # 严格字符白名单 top_k: int = Field(default=3, ge=1, le=10)

• Credential 泄露：Tool 接口绝不能暴露 credential。我们最初把 API key 放在 tool 的spec里，结果 sandbox 日志显示，key 被明文记录在 event 中。正确姿势是：tool 接口只接收query和top_k，credential 由 Anthropic Vault 注入到 sandbox 的内存中，tool 代码通过os.getenv("KB_API_KEY")读取——这个 env 变量仅在 sandbox 内部有效，且生命周期与 sandbox 绑定。

Step 3：Session 管理——持久化不是默认，而是选择

Managed Agents 的 session 默认是“瞬时”的。如果你不主动调用create_session()并保存session_id，每次请求都是全新 session。要实现“记住用户偏好”的长期交互，必须：

1. 在首次请求时，调用POST /v1/sessions创建 session，获取session_id；
2. 将session_id存储在你自己的数据库（如 Redis）中，关联到用户 ID；
3. 后续所有请求，带上X-Anthropic-Session-ID: <session_id>header；
4. 设置合理的 session TTL（我们设为 7 天），到期后自动清理。

我们踩过的坑：忘记设置 TTL，导致数万僵尸 session 占满日志存储，Anthropic 的 billing dashboard 显示“active session-hours”异常飙升，账单翻倍。后来加了定时任务，每天凌晨扫描并删除 7 天未活跃的 session。

Step 4：监控与告警——别等客户投诉才行动

Anthropic 提供基础 metrics（如 p50/p95 latency、error rate），但生产环境需要更细粒度的观测：

• Tool Call 成功率：单独监控每个 tool 的status_code。我们发现vector_search的 5xx 错误率在凌晨 2-4 点飙升，根源是知识库搜索服务的 autoscaling 配置不合理，凌晨流量低时缩容过度，导致请求排队。
• Context Overflow 预警：虽然 Managed Agents 自动处理 overflow，但你可以通过event日志中的context_tokens_used字段，设置阈值告警（如 > 150K tokens）。我们设了 Slack 告警，当单 session token 使用超阈值，立刻通知 SRE 团队检查 prompt 是否冗余。
• Credential Rotation 审计：Vault 的 credential rotation 日志，必须与你的 SIEM 系统对接。我们曾因未及时同步 rotation 事件，导致 sandbox 调用旧 key 失败，agent 服务中断 17 分钟。

4. 常见问题与实战排障：那些文档里不会写的坑

4.1 问题速查表：高频故障与根因定位

4.2 我们踩过的三个血泪坑

坑一：Sandbox 启动时间抖动，导致 SLA 不达标

我们承诺客户 agent 响应 < 2s，但在压测中发现，约 5% 的请求耗时 > 5s。抓包发现，延迟全在 sandbox 启动阶段：从execute()调用发出，到 sandbox 内 tool 进程 ready，平均耗时 3.2s，P95 达 8.7s。根因是 Anthropic 的 sandbox 池化策略——新 tool 或冷门 tool 需要动态拉镜像、初始化环境。解决方案是：预热。我们在每天业务高峰前 1 小时，用 cron job 调用execute("vector_search", {"query": "warmup"})和execute("document_retriever", {"doc_id": "warmup"})各 100 次，强制 sandbox 池加载常用镜像。预热后，P95 启动时间降至 1.1s，SLA 达标率从 95% 提升至 99.98%。

坑二：Event Log 的“最终一致性”陷阱

我们依赖 event log 做实时审计，但发现GET /sessions/{id}/events有时返回“缺失”的事件。比如 tool call 已完成，但 log 里查不到对应事件。查 Anthropic 文档，才发现其日志是“最终一致性”：事件写入 log 和返回 API 之间，有最大 200ms 的延迟。我们的审计服务没做重试，直接判定为失败。教训：所有依赖 event log 的下游系统，必须实现指数退避重试（exponential backoff）。我们改用 100ms/200ms/400ms/800ms 四次重试，成功率 100%。

坑三：Guardrail 的“双重过滤”导致性能雪崩

我们为防 PII 泄露，同时启用了OUTPUT_FILTER（正则匹配）和PII_BLOCKER（NLP 识别）。结果发现，每个 response 要经过两次深度扫描，p95 延迟增加 1.8s。根因是两个 guardrail 串行执行，且PII_BLOCKER的 NLP 模型本身就有延迟。解决方案：只用一个，且选最准的。我们做了 A/B 测试，发现PII_BLOCKER对身份证号、手机号的召回率 99.2%，远高于正则的 87.5%，且 false positive 更少。果断关闭OUTPUT_FILTER，延迟回归正常。

4.3 性能调优实录：从“能跑”到“跑得稳”

• Token 效率优化：我们发现 agent 的 system_prompt 占用 3.2K tokens，但其中 60% 是冗余的礼貌用语（如“请务必认真思考”）。删掉后，context 空间释放 1.9K tokens，p95 延迟下降 12%。结论：system_prompt 要像 SQL 一样精炼，每字必有其用。

• Tool Call 批处理：原设计是“问一句，搜一次”，导致频繁调用vector_search。改为：先用 LLM 从用户问题中提取 3 个核心关键词，再并发调用vector_search三次，最后汇总结果。并发后，平均 tool call 次数从 4.2 次降至 2.1 次，session 总耗时下降 35%。

• Sandbox 内存调优：document_retrievertool 在解析大 PDF 时 OOM。我们没改代码，而是联系 Anthropic 支持，申请将该 tool 的 sandbox 内存从默认 512MB 提升至 2GB。支持响应很快，且不额外收费——因为他们按 session-hour 计费，与资源规格无关。这点很关键：不要假设默认配置最优，大胆提资源需求。

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

5.1 历史不会重复，但韵律惊人相似：从虚拟化到 agent runtime

Anthropic 工程博客里那个“OS 类比”，不是修辞，是预言。它精准复刻了 2000 年代初虚拟化技术的演进路径：

• 2001-2005：VMware 时代——商业闭源，高价垄断，ESX 单主机年费数万美元。价值在 hypervisor 本身。
• 2003-2007：Xen/KVM 时代——开源冲击，性能追赶，社区驱动。价值开始向“之上”的管理层迁移。
• 2008-2015：AWS/GCP 时代——云厂商将虚拟化作为免费底层，打包进 IaaS。hypervisor 不再是产品，而是水电煤。
• 2015-2025：Kubernetes 时代——价值彻底上移，容器编排、服务网格、GitOps 成为新战场。谁掌控了应用交付的抽象层，谁就掌控了价值。

今天 agent runtime 正站在2008 年的 VMware 节点上。Anthropic 的 Managed Agents，就是它的 ESX；AWS AgentCore，就是它的 EC2；而开源项目 Daytona、K8s SIG 的 agent-sandbox，就是它的 Xen/KVM。历史规律清晰：当一个基础设施层被多家云厂商免费提供，且开源方案性能逼近商用时，该层的毛利率必然坍缩至趋近于零。这不是预测，是正在发生的事实。

所以，当有人问“我该不该押注 Anthropic 的 runtime？”，答案不是“该不该”，而是“你押注的，是 runtime 本身，还是 runtime 之上的新层？” 如果你的创业公司，核心卖点是“比 Anthropic 更快的 sandbox 启动”，那你的故事，和 2008 年卖 ESX 插件的公司一样，注定是过渡性的。真正的机会，在 runtime 之上的三块高地。

5.2 高地一：Trace Store——AI 世界的“银行流水系统”

当 agent 的每一次决策、每一次 tool call、每一次失败，都变成结构化事件写入日志，谁拥有这个日志的存储、查询、分析能力，谁就拥有了 AI 应用的“真相”。这不是简单的日志聚合，而是 OLAP 数据库级别的工程：

• Braintrust 的 Brainstore：专为 AI 交互设计，支持 sub-second 查询百万级 session events。它能把“所有销售 agent 在 Q1 调用 Salesforce API 的成功率”这个指标，从原始日志中秒级提炼出来。我们接入后，发现某销售 agent 的失败率高达 42%，根因是其salesforce_updatetool 的opportunity_stage字段映射错误——这个 bug 在传统日志里，埋在数千行 debug 输出中，根本找不到。

• Arize Phoenix：Apache 2.0 开源，意味着你可以把它部署在自己集群里，完全掌控数据。我们用它做了个“agent 健康度仪表盘”，实时显示每个 agent 的tool_call_success_rate、avg_context_tokens、guardrail_violation_rate。当某个指标异常，自动触发 PagerDuty 告警。这比 Anthropic 自带的 metrics 细致 10 倍。

• LangSmith：优势是生态绑定。如果你用 LangChain，它开箱即用，自动捕获所有 chain 的 trace。但我们发现，它对非 LangChain agent（如原生 Claude agent）的支持是实验性的，稳定性不足。所以我们的策略是：LangChain 项目用 LangSmith，Claude Managed Agents 项目用 Brainstore，两者数据通过 ETL 同步到统一数据湖。

注意：Trace portability 是生死线。今天你用 Anthropic，明天想迁到 AWS，如果 trace 格式不兼容，所有历史审计、所有模型训练数据（用于 fine-tune agent）全部作废。目前没有标准，所以选型时，必须问清供应商：“你们的 trace schema 是否开放？是否有 migration 工具？”

5.3 高地二：Governance & Policy——AI 时代的“合规防火墙”

当 agent 能调用银行 API、能修改生产数据库、能发送合同邮件，“它被允许做什么”比“它能做什么”重要一万倍。Policy 不再是法务部门的 PPT，而是运行时的强制熔断开关：

• AWS AgentCore Policy Controls：已 GA，支持精细到字段级的控制。例如，这条策略：

  { "Effect": "Deny", "Action": "bedrock:InvokeAgent", "Resource": "*", "Condition": { "StringEquals": {"bedrock:ToolName": "database_write"}, "ForAnyValue:StringLike": {"bedrock:InputPath": "production.*"} } }

  意思是：禁止任何 agent 调用database_writetool，如果其输入路径（input path）匹配production.*。这比“禁止写数据库”精准得多，允许 agent 写测试库，但绝不碰生产。

• OWASP Agentic Top 10：2026 年 3 月发布，列出了 agent 最危险的 10 类漏洞，如“LLM Injection via Tool Input”、“Insecure Tool Chaining”、“Over-Privileged Sandboxes”。它正在成为企业采购的准入门槛。我们帮一家金融客户做 PoC 时，对方 CISO 第一个问题就是：“你们的 agent 是否通过 OWASP Top 10 的第 3 条（Insecure Tool Chaining）审计？”

• 自研 Policy Engine 的代价：我们曾试图用 Open Policy Agent (OPA) 自建 policy 引擎，结果发现，为每个 tool call 构建 Rego 规则，工作量巨大，且规则冲突难调试。最终放弃，转而深度集成 AWS 的原生 policy。教训：在 policy 领域，不要重复造轮子，云厂商的原生方案，就是当前事实标准。

5.4 高地三：Vertical Agent Marketplaces——从“通用智能”到“专用专家”

Salesforce 的 Agentforce ARR 达到 8 亿美元，不是因为它卖 runtime，而是因为它卖“销售场景的确定性”。客户买的不是“一个能调用 Salesforce API 的 agent”，而是“一个能自动识别高意向线索、生成个性化跟进邮件、并预约下周会议的销售助理”。这背后是：

• 垂直领域知识固化：Agentforce 的 agent 内置了销售 SOP、客户分级模型、邮件模板库、会议日历规则。这些不是 prompt engineering，是领域专家用 years of experience 编码进去的。

• 可验证的 ROI：客户能直接看到“使用 Agentforce 后，销售代表每周节省 8.2 小时，线索转化率提升 17%”。这种量化结果，是通用 runtime 永远无法提供的。

• 开源生态的加速：GitHub 上，virattt/ai-hedge-fund已能自动执行对冲基金的仓位分析和风险报告生成；vxcontrol/pentagi能模拟红队攻击链，生成渗透测试报告。这些不是玩具，是真实可用的垂直 agent。资本正在疯狂涌入：2026 年 Q1，垂直 agent 初创公司融资额同比增长 210%。

所以，如果你在做一个 agent 项目，问自己的第一个问题不应该是“它用什么模型？”，而是“它解决哪个垂直行业的哪个具体、可计量、客户愿付费的痛点？” 通用 agent 是基础设施，垂直 agent 是应用。价值，永远在应用层。

6. 最后一点个人体会：别和浪潮赛跑，要站在浪尖上

我在 2024 年底，带着团队用 LangChain 从零搭建了一个客服 agent，花了 4 个月。上线三个月后，我们发现维护成本越来越高：要自己管 sandbox、自己写 event store、自己做 credential rotation、自己 debug context overflow。最讽刺的是，当我们终于把系统跑稳，AWS AgentCore GA 了，Anthropic Managed Agents 也来了。那一刻我意识到：我们不是在构建产品，是在为基础设施的迭代买单。

所以，现在我的原则很朴素：Runtime 层，只用云厂商的托管服务；价值层，全力押注 trace、policy、vertical。我们把所有工程师从“怎么让 sandbox 启动更快”中解放出来，转而做三件事：

1. 把 Brainstore 的 trace 数据，喂给内部 LLM，微调出一个“agent 健康度预测模型”——它能提前 15 分钟预测某个 agent 的失败概率，准确率 92%；
2. 基于 OWASP Top 10，开发了一套自动化 policy audit 工具，能扫描任意 agent 的 YAML 定义，输出风险评分和修复建议；
3. 和一家医疗 SaaS 公司合作，把他们的临床试验文档问答流程，封装成一个垂直 agent，名字就叫 “TrialAssist”，按 per-trial usage 收费。

这三件事，没有一件和“runtime 性能”有关。它们和钱有关，和客户续约有关，和护城河有关。

Anthropic 的 Managed Agents 很好，架构干净，文档清晰，价格合理。但它最大的意义，不是让你用得更爽，而是逼你直面一个选择：你是想继续当 runtime 的修理工，还是想成为上面那层价值的建筑师？这个选择，没有对错，但有时代节奏。而节奏，从来只奖励那些看清方向、立刻转身的人。