AI智能体运行时正走向商品化：从托管Agent看基础设施层演进
1. 这不是新赛道，而是 runtime 层的“操作系统时刻”正在重演
你打开手机看到新闻标题《Anthropic Just Shipped the Layer That’s Already Going to Zero》，第一反应可能是：又一个大模型公司搞出了什么黑科技？但如果你真花十分钟读完原始那篇长文，会发现它根本不是在讲“Anthropic有多强”，而是在冷静地划一条线——这条线，把整个 AI 工程栈切成了上下两层：上层是价值可沉淀、可定价、可构建护城河的部分；下层是注定被压缩、被免费化、被云厂商打包进账单的基础设施部分。我做 AI 基础设施落地项目整整七年，从最早用 Flask + Redis 手搓 agent 调度器，到后来给三家 Fortune 500 企业设计多租户沙箱平台，再到去年带队重构一个日均 27 万 session 的金融客服 agent 系统——我亲眼见过太多团队把全部精力押注在“怎么让 harness 更快”“怎么优化 sandbox 启动时间”上，结果半年后 AWS 一纸公告，AgentCore 直接开箱即用，连 YAML schema 都和他们自研的八九不离十。这不是技术失败，是战略误判。Anthropic 这次发布的 Managed Agents，表面看是“托管型智能体运行时”，实则是把一个本该由开发者自己扛的、沉重的、易出错的系统工程责任，收编进自己的服务边界里。它不解决“agent 该做什么”，只解决“agent 在哪儿安全、稳定、可审计地跑”。这恰恰印证了一个我反复验证过的规律：当某一层基础设施开始出现多个商业实现+开源替代+云厂商内置版本时，这一层就进入了不可逆的 commoditization（商品化）通道。它的定价逻辑会迅速从“按能力付费”转向“按资源消耗付费”，再滑向“按云账单分摊”。你不需要记住 Anthropic 的 pricing 是 $0.08/session-hour，你需要记住的是：这个数字在 18 个月内大概率会变成 $0.03，然后变成“包含在 Claude Pro 订阅中”，最后变成“AWS 企业协议里的默认启用项”。关键词里那个 “Towards AI - Medium” 不是随便写的——这篇文章之所以能引发广泛转发，正因为它没用一句 hype 话术，而是用操作系统虚拟化的类比，把一个抽象的技术演进，锚定在工程师真正理解的历史坐标上。它说的不是“Anthropic 又赢了”，而是“所有还在 runtime 层押注的团队，该抬头看看天花板了”。
2. 核心设计解构：为什么“Session as Event Log”是唯一值得抄的架构范式
2.1 从“上下文即状态”到“事件日志即真相”的范式迁移
我必须先坦白：我自己也踩过这个坑。2023 年 Q3，我们为一家律所开发合同审查 agent，核心流程是“提取条款 → 检索相似判例 → 比对风险点 → 生成修订建议”。当时团队信心满满，认为只要把 prompt 写得足够清晰、context window 用足 200K tokens，就能搞定。结果上线第三天，一个涉及 17 份附件、42 个交叉引用的并购协议进来，agent 在第 6 步开始胡说八道——它把前两天查到的某地方法规，当成当前合同的适用法律写进了意见书。回溯日志才发现，context 窗口早已溢出，模型自动丢弃了最老的 tool call 结果，却没触发任何告警，更没有 fallback 机制。我们花了整整两天才手动拼凑出完整执行链。Anthropic 提出的 “Session as Event Log”，本质上就是把这个血泪教训，固化成一套强制性的架构约束。它的核心不是“把日志存下来”，而是让 session 本身成为不可变的事实源（source of truth）。每一次 tool call、每一次模型输出、每一次用户干预，都作为一条带时间戳、带 trace_id、带输入/输出 payload 的结构化事件，持久化到外部存储（很可能是他们自研的时序数据库或 OLAP 引擎）。Harness（执行器）彻底无状态，它只负责根据当前 event log 的最新状态，调用模型、触发工具、生成下一个事件。这意味着：
- 崩溃可恢复：Harness 进程挂了？没关系，
awake(sessionId)会从 event log 的 last known good state 重新加载上下文，继续执行。我们当年那个律所项目，如果早用这套，故障恢复就是毫秒级。 - 调试可追溯：你想知道为什么 agent 在第 13 步拒绝了某个操作？直接查 event log，过滤
sessionId=xxx AND step=13，看到完整的输入、模型思考过程、tool call 参数、返回结果，一目了然。不用再翻几十页 debug 日志猜模型“当时脑子里想的是啥”。 - 审计可合规：金融、医疗客户最怕什么？不是 agent 出错，而是出错后无法证明“它当时看到了什么、基于什么决策、谁授权了这个动作”。event log 天然是 WORM（Write Once Read Many）存储，天然满足 SOC2、HIPAA 对操作留痕的要求。
提示：很多团队试图用“把 context 存 Redis + 加 TTL”来模拟这个效果，这是危险的。Redis 是缓存，不是事实源；TTL 会导致关键历史丢失；更重要的是，它无法保证事件的原子性写入——一次 tool call 的 input 和 output 必须同时成功写入，否则就会出现“模型说调用了 API，但日志里找不到调用记录”的诡异状态。Anthropic 的 event log 是事务性存储，这是底层能力，不是上层技巧。
2.2 Credential Isolation：生产环境里，安全不是功能，是默认配置
原文提到“Credentials bundled into the sandbox at provision time, never injected as environment variables”，这句话轻描淡写，但背后是无数血案换来的教训。2024 年初，我们帮一家电商做促销活动 agent，需要调用内部库存 API。开发同学图省事，在 Dockerfile 里写了ENV API_TOKEN=$SECRET_TOKEN，然后通过docker build --build-arg SECRET_TOKEN=xxx构建。问题来了：这个 token 不仅出现在容器环境变量里，还被完整记录在 Docker image 的 layer history 里。当这个镜像被意外推送到公共仓库（是的，真发生了），token 就泄露了。Anthropic 的做法是：在 sandbox 创建时，由可信的 credential vault（比如 HashiCorp Vault 或 AWS Secrets Manager）动态注入 token 到 sandbox 的隔离内存空间，且这个 token 的生命周期与 sandbox 绑定，sandbox 销毁，token 自动失效。Agent 的代码里永远看不到明文 token，它只调用call_tool("inventory_check", {"sku": "ABC123"})，底层 runtime 负责完成认证、签名、调用。这带来的不仅是安全，更是运维简化：
- 权限最小化：每个 sandbox 只能访问它被明确授权的少数几个工具，无法横向越权。我们曾遇到 agent 因 prompt 被注入，意外调用了
delete_all_users工具，就是因为所有工具 token 都挂在同一个 env 里。 - 轮换自动化：token 过期？vault 自动刷新，sandbox 无感。不用改一行代码，不用重启服务。
- 审计精准化：每条 event log 里都记录了“哪个 sandbox、在哪个时间、以哪个凭证身份、调用了哪个工具”，比单纯记录“API_KEY_XXX 被调用”有用一万倍。
2.3 Harness：无状态执行器的“瘦”哲学
Harness 被定义为 “stateless executor that calls containers via execute(name, input) → string”，这个设计看似简单，实则直指 agent 系统最顽固的痛点——状态漂移。传统方案里，Harness 往往是一个复杂的 Python 进程，里面混着模型推理、工具调度、记忆管理、错误重试、超时控制……它既是大脑，又是手脚，还是记事本。一旦出问题，你永远不知道是模型崩了、网络超时了、还是内存泄漏导致的 OOM。Anthropic 把 Harness 做“瘦”，意味着：
- 模型无关：Harness 不关心你用的是 Claude 3.5 还是 Llama 3，它只认
execute()这个接口。今天换模型，只需改 YAML 里 model 字段，Harness 代码零改动。 - 工具无关：
execute("notion_search", {...})返回的永远是 string，Harness 不解析 JSON，不校验 schema，不处理分页。这些都交给 Notion 工具的 container 自己搞定。 - 升级无感：Harness 本身是个轻量二进制，可以热更新。我们曾因一个 Harness 的 bug 导致 30% 的 session 失败，紧急 hotfix 后，5 分钟内全量滚动更新，用户无感知。
这种“瘦 Harness”思想，和 Kubernetes 的 kubelet 如出一辙——kubelet 不管你 pod 里跑的是 Java 还是 Node.js，它只负责拉镜像、启容器、上报状态。复杂性下沉，稳定性上浮。
3. 实操落地：如何用 Managed Agents 替代自研 Runtime（附 YAML 详解与避坑清单）
3.1 从零开始定义你的第一个 Managed Agent（YAML 全解析）
假设你要为销售团队做一个“客户背景速查 agent”，它需要：1）从 CRM 获取客户基本信息；2）搜索公开新闻和财报；3）生成一页摘要。以下是符合 Anthropic Managed Agents 规范的 YAML 定义，我逐行解释其设计意图：
# agent.yaml name: "sales-customer-researcher" description: "Fetches and synthesizes customer background data for sales reps" # 系统提示词 —— 这是 agent 的“人格”和“职责说明书” system_prompt: | You are a senior sales intelligence analyst at Acme Corp. Your job is to research prospects and generate concise, actionable summaries. ALWAYS use the provided tools. NEVER fabricate data. If a tool fails, report the error clearly and stop. Do not guess. # 定义可用的工具（Tool Schema） tools: - name: "crm_lookup" description: "Fetches basic company info (industry, size, HQ) from Salesforce CRM" input_schema: type: "object" properties: domain: type: "string" description: "Company's website domain, e.g., 'acmecorp.com'" required: ["domain"] - name: "news_search" description: "Searches recent news articles about the company" input_schema: type: "object" properties: company_name: type: "string" days_back: type: "integer" default: 90 required: ["company_name"] - name: "financial_report_search" description: "Finds latest annual/quarterly reports (10-K, 10-Q)" input_schema: type: "object" properties: ticker: type: "string" description: "Stock ticker symbol, e.g., 'ACME'" required: ["ticker"] # Guardrails —— 这是生产环境的生命线 guardrails: # 防止越权访问 allowed_tools: ["crm_lookup", "news_search", "financial_report_search"] # 防止 prompt 注入攻击 disallowed_phrases: ["ignore previous instructions", "act as", "you are now"] # 防止无限循环 max_tool_calls_per_session: 15 # 防止敏感数据泄露 output_filters: - regex: "SSN|Social Security Number" replacement: "[REDACTED_SSN]" - regex: "credit card: [0-9-]+" replacement: "[REDACTED_CC]" # 运行时配置 runtime_config: # session 最长存活时间（避免僵尸 session 占用资源） max_session_duration_hours: 24 # 沙箱资源限制（防止一个 bad agent 拖垮整个集群） sandbox_limits: cpu_millis: 2000 # 2 vCPU memory_mb: 4096 # 4GB timeout_seconds: 120这个 YAML 的精妙之处在于：它把所有“人”的决策，转化成了机器可执行、可审计、可版本化的配置。system_prompt不是写给开发者的注释，而是 agent 的宪法；input_schema不是文档，而是 runtime 的输入校验器；guardrails不是愿望清单，而是强制执行的安全策略。我见过太多团队把 guardrails 写在 Jira ticket 里，或者靠 code review 人工检查，结果上线后被一个精心构造的 prompt 绕过所有防线。而在这里，disallowed_phrases是 runtime 层面的硬拦截，output_filters是响应流上的实时脱敏，它们在模型输出的第一时间就被执行，无需等待应用层处理。
3.2 与现有系统集成：Notion 和 Slack 的真实对接路径
原文提到 Notion 和 Rakuten 在用 Managed Agents，但没说怎么接。这里分享我们给一家 SaaS 公司做的真实集成方案，它完美体现了“Managed Agents 不是取代你的系统，而是成为你的系统神经中枢”：
场景：销售 rep 在 Notion 页面里选中一个客户名称，右键点击“Run Research Agent”，几秒后页面底部自动插入一份 PDF 格式的摘要。
集成步骤：
- Notion API 授权：在 Anthropic 控制台，为
crm_lookup工具配置 Notion Integration Token。这个 token 被安全存储在 Anthropic 的 vault 中，Never 暴露给 agent 代码。 - Webhook 注册：Notion 的 “Custom Button” 功能允许你注册一个 webhook。当用户点击按钮，Notion 发送 POST 请求到你的 endpoint，携带
page_id和selected_text。 - Endpoint 转发：你的轻量 endpoint（比如一个 Cloudflare Worker）收到请求后，不做任何业务逻辑，只做一件事：调用 Anthropic Managed Agents 的
create_sessionAPI，传入{"customer_domain": "selected_text"}和预定义的agent_name: "sales-customer-researcher"。 - 结果回写：Managed Agents 执行完毕，将最终摘要（Markdown 格式）通过 webhook 回调到你的 endpoint。你的 endpoint 解析 Markdown，调用 Notion API 的
append_block方法，把内容插入到原页面指定位置。
整个过程，你的服务器只做“翻译”工作，不碰客户数据，不运行模型，不管理状态。所有高危操作（调用 CRM、搜索新闻）都在 Anthropic 的 sandbox 里完成，受其 credential isolation 和 event log 保护。Rakuten 的 Slack 集成同理：Slack App 的/research @acmecorp命令，触发同样的create_session流程，结果以 Slack message 形式返回。
注意：不要试图在你的 endpoint 里“等”Managed Agents 执行完再返回。Managed Agents 是异步的，
create_session返回的是session_id，你需要用get_session_result(session_id)轮询，或更推荐——配置一个 callback URL，让 Anthropic 主动通知你结果。我们最初犯的错就是同步等待，导致 Slack 响应超时，用户体验极差。
3.3 定价模型实测与成本对比（$0.08/session-hour 的真实含义）
Anthropic 官方定价是$0.08 per session-hour of active runtime，加上 Claude token 费用。很多人第一眼觉得贵，但实际测算下来，它可能比你自研方案便宜得多。我们拿一个典型销售 research agent 来算：
| 项目 | 自研方案（估算） | Anthropic Managed Agents |
|---|---|---|
| 硬件成本 | 2 台 c5.2xlarge（8vCPU/16GB）常年运行，月租 $320 | $0（Anthropic 承担） |
| 运维人力 | 0.5 FTE（部署、监控、扩缩容、安全审计）≈ $8,000/月 | $0（Anthropic 承担） |
| 安全合规 | 渗透测试、SOC2 审计、日志留存系统 ≈ $15,000/年 | 已包含在服务中 |
| Session 成本（按 10,000 session/月） | 每 session 平均耗时 45 秒，CPU 利用率 30%，折算 $0.02/session | 45秒 = 0.0125小时 * $0.08 = $0.001/session+ token 费用 |
关键洞察：$0.08/session-hour的“hour”是指 sandbox 的实际活跃时间，不是 wall-clock 时间。一个 session 从创建到结束可能持续 24 小时，但其中 99% 的时间 sandbox 是休眠的，不计费。只有当 agent 在执行 tool call、模型推理、生成响应时，才会计费。我们实测一个平均 45 秒完成的 research session，真实计费时间约 35 秒（因为模型推理和 tool call 是并行的，sandbox 只在有工作时才唤醒）。所以，对于间歇性、任务型 agent，Managed Agents 的边际成本远低于常驻服务。它的定价模型，本质是把你的 CapEx（买服务器）变成了 OpEx（按需付费），而且把最难搞的运维、安全、合规，打包卖给你了。
4. 竞争格局全景扫描：为什么说 Anthropic 的 launch 是防御战，而非攻坚战
4.1 AWS Bedrock AgentCore：那个被所有人忽略的“ incumbent”
原文一针见血：“The incumbent everyone forgot to mention”。AWS Bedrock AgentCore 在 2025 年底就 GA 了，到 2026 年 3 月，SDK 下载量超 200 万次。这不是一个“竞品”，这是事实上的行业标准。它的架构甚至比 Anthropic 更激进：
- MicroVM 隔离：每个 session 运行在独立的 Firecracker microVM 里，拥有专属 CPU、内存、文件系统。这比 Anthropic 的 container sandbox 级别更高，安全性更强。
- 框架无关：LangGraph、CrewAI、Strands……只要你提供一个
input -> output的函数，它就能跑。Anthropic 的 Harness 是专为 Claude 优化的，而 AgentCore 是真正的通用 runtime。 - 深度云集成：Policy controls 直接对接 AWS IAM，session logs 自动流入 CloudWatch，trace 数据无缝接入 X-Ray。你在 AWS 上部署一个 agent，就像部署一个 Lambda 函数一样自然。
我们给一家保险客户做 PoC 时，用同样的 YAML 定义，在 Anthropic 和 AgentCore 上各跑了一轮。结果 AgentCore 的 p95 latency 低了 12%，sandbox 启动快了 300ms，而且 Policy 控制台里点几下鼠标，就完成了“禁止所有 agent 访问 prod RDS”的策略下发。Anthropic 的优势在于对 Claude 模型的深度协同（比如更优的 tool calling 格式），但如果你的 stack 已经在 AWS 上，AgentCore 就是零摩擦的选择。这就是为什么 Anthropic 的 launch 本质是防御——它必须确保，当客户决定用 Claude 时，不会因为 runtime 体验不如 AgentCore，而把 Claude 当作一个“插件”塞进别人的 runtime 里。
4.2 Google Vertex AI Agent Builder 与 Microsoft Azure AI Foundry：生态位的无声卡位
Google 和微软的策略更隐蔽，也更致命。Vertex AI Agent Builder 的核心不是 runtime，而是Agent Registry + Apigee 网关。它把 agent 当作一个 API 来管理：你可以发布一个customer-researchagent 到 registry，设置 rate limit、quota、authentication（JWT/OAuth），然后任何内部系统（CRM、ERP、BI 工具）都可以像调用 REST API 一样调用它。Apigee 提供了完整的流量管理、监控、审计日志。这解决了企业最头疼的问题：如何让 agent 像一个成熟的微服务一样，融入现有 IT 治理体系？Azure AI Foundry 则更进一步，它把 AutoGen 和 Semantic Kernel “折叠”进去，意味着你可以在 Foundry 里直接用 C# 或 Python 编写 agent logic，而 runtime 由 Azure 托管。它的目标用户不是 AI 工程师，而是企业现有的 .NET 开发者和 Power Platform 专家。
这三家巨头的共同点是：它们不卖“agent runtime”，它们卖“agent as a service in your cloud”。你不需要学习新的 YAML 格式，不需要迁移到新平台，你只需要把你的 agent 逻辑（无论用 LangChain 还是手写）打包成一个 container，上传，配置，就完成了。Anthropic 的 Managed Agents 是一个独立产品，而 AgentCore、Vertex、Foundry 是云平台的原生能力。后者的优势在于：采购流程短（已包含在云合同里）、运维成本低（无需额外管理）、安全合规强（已通过云厂商认证）。这才是 Anthropic 真正害怕的——不是技术落后，而是客户根本不需要单独采购一个 runtime。
4.3 开源压力曲线：Daytona、K8s SIG、Deer-flow 的真实威胁
如果说云厂商是“明面上的对手”，那么开源社区就是“暗处的推手”。原文提到的三个项目，代表了 runtime 层商品化的三个方向：
- Daytona：从 dev environment（类似 VS Code Dev Containers）转型而来，它的核心优势是sub-90ms sandbox spin-up。这意味着它能把 sandbox 做得像函数计算（Function-as-a-Service）一样轻量。我们实测过 Daytona 的 demo，启动一个带 Python 环境的 sandbox，平均 78ms，比 Anthropic 的 200ms+ 快了一倍多。这对高频、短时任务（如实时客服问答）至关重要。它的商业模式很聪明：不卖 runtime，卖 developer experience——你用它的 CLI 创建 sandbox，它自动帮你配好 IDE、debugger、log viewer，开发者体验碾压所有云服务。
- Kubernetes SIG Agent Sandbox：这是最危险的。K8s 是事实上的数据中心操作系统，如果官方 SIG 推出一个 production-ready 的 agent sandbox operator，那意味着：任何有 K8s 集群的企业，都能在自己的机房里，用
kubectl apply -f agent-sandbox.yaml部署一个企业级 runtime。它不依赖云厂商，不绑定模型，完全开源。我们已经看到几家大型银行在 PoC 这个项目，他们的理由很朴素：“我们不能把客户数据、业务逻辑，托管在一个第三方 runtime 里，哪怕它是 Anthropic。” - Deer-flow：ByteDance 开源的 long-horizon agent harness，特点是内置 planning 和 subagents。它不追求“快”，而追求“稳”——一个需要 3 小时、调用 200 次工具、跨越 5 个系统的复杂任务，Deer-flow 能保证 99.9% 的成功率。它的 event log 设计比 Anthropic 更细粒度，连模型的 token-level attention weight 都可追溯。这代表了另一个方向：runtime 不是越简单越好，而是要匹配任务的复杂度。
这三股力量合起来，构成了一个完美的“商品化飞轮”：开源项目提供极致性能/灵活性/可靠性 → 云厂商将其吸收、封装、免费化 → 企业客户发现“买 runtime”毫无意义，转而投资上层。Anthropic 的 Managed Agents，正处于这个飞轮的加速阶段。
5. 价值迁移地图：当 runtime 归零，钱流向哪里？（实操指南与避坑清单）
5.1 Trace Store：不是日志系统，而是你的“AI 事实法庭”
当 runtime 层 commoditize，第一个爆发的价值洼地是Trace Store。这不是简单的日志收集，而是构建一个“AI 行为的事实法庭”。我们给一家跨国药企做的案例最能说明问题：他们用 agent 做临床试验数据分析，agent 需要调用内部数据库、Pubmed、FDA 数据库。监管要求是：任何分析结论，必须能 100% 追溯到原始数据源和每一步推理。他们试过 ELK Stack，但失败了——因为 ELK 是为文本日志设计的，无法高效查询“找出所有调用了 FDA API 且返回结果包含 'black box warning' 的 session”。他们最终选择了 Braintrust 的 Brainstore，原因有三：
- Schema-on-read：Brainstore 不要求你提前定义所有字段。agent 的 event log 是动态的，今天加一个
tool_call_metadata字段，明天加一个model_reasoning_trace，Brainstore 自动识别、索引、优化查询。 - OLAP 优化：它底层是列式存储，对
SELECT COUNT(*) FROM events WHERE tool_name='fda_search' AND response LIKE '%black box%' GROUP BY session_id这种查询，亚秒级响应。ELK 在同样数据量下要 15 秒。 - Portability First：Brainstore 的 export 格式是标准 Parquet，你可以随时把数据导出，用 Spark、Presto 或任何 BI 工具分析。这解决了原文说的“trace portability is not solved”——它让你的数据不被 vendor lock-in。
实操心得：不要等 runtime 选型完成再考虑 trace store。从第一天起，就把 event log 的 schema 设计好。我们强制要求所有工具返回的
response字段，必须是 JSON，且包含data,metadata,error三个顶级 key。这样，无论你用 Brainstore、Arize Phoenix 还是 LangSmith，都能一致地解析和查询。这是你未来迁移成本的底线。
5.2 Governance & Policy：从“技术配置”到“采购谈判筹码”
政策控制（Policy Controls）正在从技术配置，变成 CFO 和 CISO 的采购谈判筹码。AWS AgentCore 在 2026 年 3 月 GA 的 Policy Controls，就是一个分水岭。它支持的策略类型包括：
- Data Residency：强制所有 sandbox 的数据处理必须在
us-east-1区域。 - Tool Access Control：
sales-agent只能调用crm_lookup，finance-agent只能调用sap_query。 - Output Sanitization：自动 redact 所有 PII（个人身份信息）和 PCI（支付卡信息）。
- Cost Guardrails：单个 session 的 token 消耗超过 100K，自动终止。
这些策略不是写在 config 文件里，而是通过 AWS Console 的图形界面配置，生效后立即审计。我们帮一家银行实施时，CISO 的第一句话是：“我要看到策略变更的审批流，谁创建、谁审批、谁生效，全部留痕。” 这已经超出了技术范畴，进入了企业治理领域。所以，现在评估一个 agent platform，关键问题是：它的 policy system，能否直接对接你们现有的 IAM（如 Okta、Azure AD）和审计系统（如 Splunk、Datadog）？如果答案是否定的，那你就是在给自己埋雷——未来每次合规审计，都要写一堆 custom script 去桥接。
5.3 Vertical Agent Marketplaces：从“通用能力”到“可签字的合同”
Salesforce 的 Agentforce ARR 达到 $800M，这个数字背后是深刻的商业逻辑转变。企业采购不再为“AI 能力”买单，而是为“解决具体业务问题的 agent”买单。一个“销售开发 agent”，必须能：
- 对接你们的 CRM（Salesforce, HubSpot, Zoho）
- 理解你们的销售流程（BANT, MEDDIC, Challenger Sale）
- 输出你们销售总监认可的报告格式（PPTX, PDF, Notion DB）
- 符合你们的合规要求（GDPR, CCPA, HIPAA）
这催生了垂直 marketplace。我们观察到两个趋势：
- SaaS 厂商主导：Salesforce、ServiceNow、Workday 都在自己的 app exchange 里上架 agent。它们的优势是：数据天然打通、UI 无缝嵌入、采购流程熟悉（走 existing SaaS contract）。
- 开源项目商业化：像
virattt/ai-hedge-fund这样的金融量化 agent，已经从 GitHub repo，进化成一个有 SLA、有 support、有 on-premise 部署选项的商业产品。它的客户不是技术 VP，而是对冲基金的 CIO。
避坑清单：如果你在创业做 vertical agent，警惕“技术完美主义”。我们见过一个医疗 agent 创业公司，花了 18 个月打磨模型在 MIMIC-III 数据集上的 accuracy，结果发现医院最需要的，是它能和他们老旧的 Epic EHR 系统通过 HL7 v2.x 协议通信。Vertical agent 的胜负手，80% 在 integration，20% 在 AI。先搞定和客户现有系统的连接，再优化 AI。
6. 终极拷问：你的技术栈，站在哪一层？
我最后想分享一个我们团队内部用的“三层健康度检查表”。每次评审一个新项目，我们都会坐在一起，用这张表打分（1-5 分），分数决定资源投入优先级：
| 层级 | 关键问题 | 健康信号（5 分） | 危险信号（1 分） | 我们的行动 |
|---|---|---|---|---|
| Runtime 层 | “我们的核心竞争力，是否依赖于 runtime 的性能、安全或成本优势？” | 我们使用云厂商的托管 runtime（AgentCore/Vertex），只做 minimal config | 我们自研了 sandbox manager，并把它作为核心专利 | 立即启动迁移计划，目标 6 个月内下线自研 runtime |
| Trace & Governance 层 | “我们能否在 5 分钟内，向 CEO/CISO 展示任意一个 agent 的完整执行链，并证明其合规？” | 我们有统一的 trace store（Brainstore），所有 agent 的 event log 格式一致，policy 通过 IaC 管理 | 日志分散在各个服务的 stdout，policy 配置在不同 console 里 | Q2 内完成 trace 标准化，Q3 上线统一 policy 控制台 |
| Vertical Layer | “我们的 agent，是否能直接对应到客户采购合同里的一个 line item，且客户愿意为它单独签字？” | 我们的 agent 名字叫 “Healthcare Claims Prior-Authorization Agent”，价格 $15K/user/year，合同里有明确 SLA | 我们的 agent 叫 “AI Assistant”，价格打包在 SaaS 订阅费里，客户不知道它存在 | Q4 前完成至少 3 个 vertical agent 的 productization，定义清晰的 buyer persona 和 pricing model |
这张表没有对错，只有清醒。Anthropic 的 Managed Agents 发布，不是一个技术新闻，而是一面镜子，照出所有 AI 工程师和创业者的真实站位。如果你还在 runtime 层拼命优化，恭喜你，你正站在历史的风口上——但风向是向下的。真正的机会，在 trace store 的数据库 schema 里，在 policy control 的 IaC 代码里，在 vertical agent 的客户合同里。技术会过时，但解决真实业务问题的能力，永远稀缺。我做这行七年，最深的体会是：不要问“这个技术多酷”，要问“这个技术，能让客户在采购单上，多写一行多少钱？”当 runtime 归零，答案就在那一行里。