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过滤sessionIdxxx AND step13看到完整的输入、模型思考过程、tool call 参数、返回结果一目了然。不用再翻几十页 debug 日志猜模型“当时脑子里想的是啥”。审计可合规金融、医疗客户最怕什么不是 agent 出错而是出错后无法证明“它当时看到了什么、基于什么决策、谁授权了这个动作”。event log 天然是 WORMWrite 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_TOKENxxx构建。问题来了这个 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, {...})返回的永远是 stringHarness 不解析 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 AgentYAML 全解析假设你要为销售团队做一个“客户背景速查 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: Companys 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.2xlarge8vCPU/16GB常年运行月租 $320$0Anthropic 承担运维人力0.5 FTE部署、监控、扩缩容、安全审计≈ $8,000/月$0Anthropic 承担安全合规渗透测试、SOC2 审计、日志留存系统 ≈ $15,000/年已包含在服务中Session 成本按 10,000 session/月每 session 平均耗时 45 秒CPU 利用率 30%折算 $0.02/session45秒 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 只在有工作时才唤醒。所以对于间歇性、任务型 agentManaged 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 IAMsession logs 自动流入 CloudWatchtrace 数据无缝接入 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、authenticationJWT/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-flowByteDance 开源的 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-readBrainstore 不要求你提前定义所有字段。agent 的 event log 是动态的今天加一个tool_call_metadata字段明天加一个model_reasoning_traceBrainstore 自动识别、索引、优化查询。OLAP 优化它底层是列式存储对SELECT COUNT(*) FROM events WHERE tool_namefda_search AND response LIKE %black box% GROUP BY session_id这种查询亚秒级响应。ELK 在同样数据量下要 15 秒。Portability FirstBrainstore 的 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 Controlsales-agent只能调用crm_lookupfinance-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”必须能对接你们的 CRMSalesforce, 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% 在 integration20% 在 AI。先搞定和客户现有系统的连接再优化 AI。6. 终极拷问你的技术栈站在哪一层我最后想分享一个我们团队内部用的“三层健康度检查表”。每次评审一个新项目我们都会坐在一起用这张表打分1-5 分分数决定资源投入优先级层级关键问题健康信号5 分危险信号1 分我们的行动Runtime 层“我们的核心竞争力是否依赖于 runtime 的性能、安全或成本优势”我们使用云厂商的托管 runtimeAgentCore/Vertex只做 minimal config我们自研了 sandbox manager并把它作为核心专利立即启动迁移计划目标 6 个月内下线自研 runtimeTrace Governance 层“我们能否在 5 分钟内向 CEO/CISO 展示任意一个 agent 的完整执行链并证明其合规”我们有统一的 trace storeBrainstore所有 agent 的 event log 格式一致policy 通过 IaC 管理日志分散在各个服务的 stdoutpolicy 配置在不同 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 归零答案就在那一行里。