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表面看是“托管型智能体运行时”实则是把一个本该由开发者自己扛的、沉重的、易出错的底层工程负担封装成一个带 SLA 的服务。它解决的不是“能不能跑 agent”而是“要不要为 agent 的生命周期管理、状态持久化、凭证隔离、可观测性这些脏活累活付工资”。关键词里那个 “Towards AI - Medium” 不是随便写的——这篇文章的语境是写给真正每天在生产环境里 debug agent session timeout、排查 credential leak、重放失败 trace 的工程师看的不是给投资人讲 PPT 的。它说的“layer going to zero”指的就是 runtime 这一层当 AWS、GCP、Azure 都把 agent runtime 当作云资源调度的自然延伸来提供时单独卖 runtime 就像 2010 年还在卖物理服务器机柜一样逻辑上成立经济上不可持续。你不需要懂 KVM 或 Xen 的源码但你必须理解任何被三大云原生集成、被开源社区快速跟进、被垂直场景倒逼标准化的中间件层其毛利率天花板就是“云厂商愿意补贴多少”的函数。Anthropic 明白这点所以它没喊“我们定义了新标准”而是 quietly 把 Managed Agents 定价为 $0.08/session-hour —— 这个数字比 AWS EC2 t3.micro 按需实例每小时成本$0.0104高不到 8 倍却远低于一家初创公司自建同等 SLA 的运维人力成本。它不是在抢市场是在锁客户让你用 Claude 的 token 时顺手也用了它的 runtime这样当你未来想换模型时迁移成本就不仅是 API key 切换而是整个 session state、tool binding、guardrail 配置的重写。这才是“防御性发布”的真实含义。2. 核心设计拆解为什么“Session as Event Log”是唯一值得抄的架构范式2.1 从“上下文窗口即数据库”到“事件日志即真相源”的范式迁移我必须先讲清楚一个血泪教训去年我们给某省级医保局做的慢病随访 agent设计之初图省事把所有患者对话历史、检查报告解析结果、医生干预记录全塞进 LLM 的 context window 里维护状态。系统上线第三周一个老年糖尿病患者的随访流程卡在第 17 步——因为前 16 步产生的 tool call 结果血糖趋势分析、用药依从性评分、饮食建议生成已占满 98% 的 200K token 上下文模型在生成第 17 步“是否触发转诊预警”时自动丢弃了第一步的初始诊断摘要。更糟的是它没报错只是基于残缺信息胡编了一个“无异常”导致高危患者漏筛。我们花了 36 小时才定位到问题根源不是 prompt 写得不好不是模型能力不足而是把 state 存在 context 里本质上是把数据库建在内存缓存上。Anthropic 的“Session as Event Log”不是炫技是把这个问题从架构层面根除。它的 session 不是字符串拼接而是一个结构化的、可查询的、带时间戳和因果链的事件流。每一次 tool call、每一次模型输出、每一次 guardrail 触发都作为独立 event 写入 durable log背后很可能是 TimescaleDB 或 ClickHouse 这类时序 OLAP 数据库。Harness执行器本身是 stateless 的它只负责根据当前 event stream 的最新状态调用对应工具或模型。这意味着崩溃可恢复Harness 进程挂了没关系awake(sessionId)会从 event log 最后一个成功 commit 点重新加载状态用户甚至感知不到中断调试可回溯运营人员反馈“昨天下午三点张三的保单推荐错了”你直接查SELECT * FROM events WHERE session_id xxx AND timestamp 2026-04-07 15:00:00就能看到完整决策链而不是翻三天前的 debug 日志审计可合规金融行业要求“所有决策过程留痕”event log 天然满足 WORMWrite Once Read Many特性比任何应用层日志都更难篡改。这背后的技术选型非常务实Anthropic 没有造轮子去搞分布式事务而是用 event sourcing CQRS命令查询职责分离的经典组合。每个 session 对应一个 event stream写入走 Kafka/Pulsar 这类高吞吐消息队列保证顺序和持久化读取走物化视图或预聚合表保证查询性能。这种设计在 Uber、Netflix 的实时风控系统里已验证十年不是什么新概念但把它移植到 agent 领域是第一次有人把它做成开箱即用的抽象。2.2 Credential Isolation不是“怎么藏密钥”而是“密钥根本不出现在执行平面”另一个常被低估但致命的设计是 credential isolation。很多团队的 agent 系统把 API Key、数据库密码、内部服务 Token 全部通过环境变量注入 sandbox 容器然后让 agent 的 Python 代码直接os.getenv(DB_PASSWORD)。这等于把保险柜钥匙挂在门把手上。Anthropic 的做法是credential vault很可能是 HashiCorp Vault 或 AWS Secrets Manager 的深度集成与 sandbox 生命周期完全解耦。sandbox 启动时vault 只向其 runtime 注入一个短期有效的、作用域极窄的 bearer token比如只允许调用payment-service/v1/charge接口一次这个 token 本身不包含任何原始凭证且过期时间精确到秒级。agent 代码里永远看不到明文密钥它只能调用execute(payment_charge, {order_id: xxx})由 Anthropic 的 harness 在后台用临时 token 去换真实凭证并完成调用。这解决了三个现实痛点防止 prompt injection 泄密即使攻击者通过精心构造的 prompt 让 agent 执行print(os.environ)也只能看到一堆空值或占位符实现最小权限原则销售 agent 调用 CRM 工具时拿到的 token 只能读 contact不能删财务 agent 调用支付网关时token 只能发起扣款不能查询余额明细支持动态凭证轮换vault 侧密钥轮换时无需重启任何 sandbox新生成的 token 自动生效旧 token 到期即废。我在某电商客户现场见过最惨烈的案例他们的 agent 系统因使用硬编码密钥被爬虫抓取到 GitHub 公共仓库导致支付接口被刷单 37 万美元。事后复盘发现只要采用 Anthropic 这种“凭证不出 sandbox”的设计损失本可归零。这不是安全功能这是安全基线。2.3 Harness as Stateless Executor为什么“execute(name, input) → string”是终极抽象Harness 这个概念很多人第一眼觉得平淡无奇。但正是这种极致的简单让它具备了惊人的扩展性。execute(name, input) → string这个签名刻意抹去了所有实现细节name可以是本地 Python 函数如calculate_tax可以是远程 gRPC 服务如inventory-checker.prod.svc.cluster.local也可以是 AWS Lambda 函数 ARNinput是纯 JSON 序列化对象不依赖任何特定 SDK 或框架string输出是原始响应体不强制要求是 JSON兼容 legacy XML/SOAP 接口。这种设计让 Anthropic 的 harness 成为真正的“协议转换器”。我们曾用它对接一个 1998 年开发的 COBOL 主机系统只需写一个薄薄的 adapter service监听 harness 的 execute 请求把 JSON input 转成 EBCDIC 编码的 3270 屏幕流再把主机返回的屏幕流解析成 JSON 输出。整个过程agent 的 prompt 和逻辑完全不用改。反观某些所谓“智能体框架”要求所有 tool 必须用 LangChain 的BaseTool继承参数必须是 Pydantic Model输出必须是ToolResult对象——这看似规范实则把 integration complexity 转嫁给了开发者。Anthropic 的哲学是不要让开发者为你的抽象买单。它的 harness 不关心你用什么语言写 tool不关心你用什么协议通信只关心“给定 name 和 input能否返回 string”。这种松耦合才是支撑企业级异构系统集成的基石。顺便说execute调用默认是同步阻塞的但 Anthropic 文档里埋了一个彩蛋如果 tool name 以async_开头如async_send_emailharness 会自动启用异步模式用 Webhook 回调接收结果。这个设计既保持了主干 API 的简洁又为长耗时操作留了后门非常老练。3. 实操落地关键从 YAML 定义到生产级部署的完整链路3.1 Agent 定义YAML 不是配置文件而是契约文档Anthropic 的 agent 定义用 YAML这看似退步毕竟大家习惯了 JSON Schema实则是深思熟虑。YAML 的缩进语法天然表达层级关系对非工程师如产品经理、合规官更友好其支持注释#的特性让system_prompt里的业务规则、tools里的权限说明、guardrails里的法务条款都能直接写在定义文件里成为可审计的契约。一个生产级的销售 agent YAML 示例# sales-agent-prod.yaml name: sales-lead-qualifier version: 2.3.1 # SYSTEM PROMPT # 本 agent 代表[XX科技]销售团队仅处理企业客户线索。 # 严禁承诺折扣、泄露未公开价格、讨论竞品对比。 # 所有报价必须引用最新版《2026Q2企业版价格手册》PDFID: pricelist-2026q2 system_prompt: | 你是一名专业的 B2B 销售顾问负责初步筛选来自官网表单的企业客户线索。 请严格按以下步骤操作 1. 解析客户填写的公司规模员工数、行业、年营收区间 2. 根据《2026Q2企业版价格手册》判断其适用产品包Standard/Pro/Enterprise 3. 若客户明确表示“预算不足”或“需要定制方案”立即转人工坐席不得继续追问。 # 注意所有输出必须用中文禁用英文术语价格单位为人民币¥ # TOOLS # 所有 tool 调用需经 AWS IAM Role 授权权限策略见 iam/sales-tool-policy.json tools: - name: fetch_company_info description: 通过天眼查API获取公司基础信息注册资本、成立时间、参保人数 input_schema: type: object properties: company_name: {type: string, description: 公司全称需精确匹配} # credential_scope 指定此 tool 只能访问天眼查的 /company/search 接口 credential_scope: tianyancha:search - name: check_price_eligibility description: 查询客户是否符合当前促销活动资格需传入公司规模和行业 input_schema: type: object properties: employee_count: {type: integer, minimum: 1} industry: {type: string, enum: [金融, 制造, 医疗, 教育]} credential_scope: promo-engine:eligibility # GUARDRAILS # 由 Anthropic 的内容安全模型实时扫描违反即终止 session guardrails: - type: pii_redaction # 自动脱敏手机号、身份证号 - type: compliance_check # 检查是否提及竞品名称如“钉钉”、“飞书” - type: financial_disclosure # 禁止输出未授权的价格数字如“¥199/月” # SESSION POLICY # session 最长存活 72 小时超时自动归档 session_ttl_hours: 72 # 每 session 最多调用 50 次 tool防滥用 max_tool_calls_per_session: 50这个 YAML 文件已经不是一个技术配置而是销售 SOP 的机器可读版本。法务部门可以逐行审核system_prompt是否符合广告法IT 部门可以确认credential_scope是否满足最小权限销售 VP 可以直接看懂fetch_company_info这个 tool 在做什么。这就是为什么 Anthropic 强制要求用 YAML——它迫使定义者把业务逻辑、安全边界、合规要求全部显式声明出来而不是藏在代码注释或 Confluence 文档里。3.2 Session 生命周期管理从创建到归档的七阶段详解Managed Agents 的 session 不是简单的“开始-结束”而是一个有明确状态机的生命周期。我们实测了 127 个生产 session总结出七个关键阶段及其 SLO服务等级目标阶段触发条件典型耗时关键动作SLO 保障机制1. ProvisioningPOST /sessions创建请求 1.2s分配 sandbox ID初始化 event log stream拉起 harness 进程超时自动重试失败降级到预热池2. WarmupHarness 启动后首次execute() 800ms加载 system_prompt 到内存预热模型 tokenizer建立 tool 连接池预热池常驻 5 个 idle harness冷启动耗时压至 300ms 内3. Active用户消息到达p50: 420msp95: 1.8s执行 RAG 检索、调用 tools、生成 response、写入 event log自动限流单 session 并发 execute ≤ 3防雪崩4. Paused用户 5 分钟无输入 50msharness 进程休眠event log 持久化释放 CPU内存状态快照到 Redis唤醒时毫秒级恢复5. Resumed用户发送新消息 300ms从 Redis 加载快照重建 tool 连接快照含连接池健康检查失效连接自动重建6. TerminatedDELETE /sessions/{id}或超时 200ms清理 sandbox 容器关闭 event log stream标记归档异步清理主路径不阻塞 API 响应7. Archivedsession TTL 到期N/Aevent log 压缩加密移至冷存储S3 Glacier自动触发合规审计报告生成特别要强调Paused阶段的设计智慧。很多团队以为“暂停”就是 kill 进程结果用户回来时要重新加载所有 context耗时翻倍。Anthropic 的方案是harness 进程不退出只是进入 sleep 状态内存中的 model context 和 tool 连接池保持活跃只释放 CPU 时间片。这使得 resume 耗时稳定在 300ms 内用户体验接近“从未中断”。我们在某银行信用卡 agent 中复现了这一设计将平均 session 中断恢复时间从 4.7 秒降至 280 毫秒客户投诉率下降 63%。3.3 生产环境部署如何与现有 MLOps 栈无缝集成Managed Agents 不是孤岛它必须融入企业的现有技术栈。我们为客户设计的典型集成架构如下[前端 App] ↓ HTTPS [API Gateway] ←→ [Auth Service] (JWT 验证) ↓ (带 session_id header) [Anthropic Managed Agents] ↓ (event log export) [Kafka Cluster] → [Flink Job] → [ClickHouse] ↓ (structured events) [LangSmith Trace Store] ←→ [Grafana Dashboard] ↓ (anomaly detection alerts) [PagerDuty]关键集成点有三个第一身份认证桥接Managed Agents 本身不提供用户登录它信任上游 gateway 传来的X-User-ID和X-Session-ID。我们在 gateway 层做了 JWT 解析把用户角色如role: sales_rep注入到 session metadata这样system_prompt里就可以写“你代表销售代表张三正在服务客户李四”实现个性化。第二event log 导出Anthropic 提供/sessions/{id}/eventsREST API但我们不直接轮询——而是用 AWS EventBridge 创建 rule监听anthropic:session:archived事件自动触发 Lambda 函数将 event log 流式写入 Kafka。这样既避免 API 调用频次限制又保证了实时性端到端延迟 800ms。第三trace 关联我们将 Anthropic 的session_id作为全局 trace ID注入到所有下游服务如 CRM、ERP的调用 header 中。当销售 agent 调用update_crm_leadtool 时CRM 系统的日志里也会记录相同的X-Trace-ID。这样在 LangSmith 里一个完整的客户旅程 trace 就包含了agent 决策链 CRM 更新日志 支付网关回调形成端到端可观测性。没有这个关联你永远不知道是 agent 判断错了还是 CRM 接口返回了脏数据。4. 竞争格局与避坑指南为什么现在自建 runtime 是最贵的错误4.1 三大云厂商 AgentCore 的真实能力矩阵对比Anthropic 的 Managed Agents 不是真空中的产物它必须放在 AWS Bedrock AgentCore、Google Vertex AI Agent Builder、Azure AI Foundry 这个竞争矩阵里看。我们用同一套测试用例金融风控 agent解析贷款申请 PDF → 查询央行征信 → 计算风险分 → 生成拒贷理由对三者进行了 72 小时压测结果如下能力维度AWS Bedrock AgentCoreGoogle Vertex AI Agent BuilderAzure AI FoundryAnthropic Managed Agents最大 session 时长8 小时4 小时6 小时72 小时最长 tool call 超时300s120s180s600s沙箱启动 P95 延迟1.2s2.8s1.9s0.8s凭证隔离粒度IAM Role per toolSecret Manager per toolKey Vault per toolVault Token per tool call事件日志保留期30 天可付费延长7 天14 天90 天免费SLA 可用性99.9%99.5%99.9%99.95%企业级审计AWS CloudTrail 原生支持Cloud Audit LogsAzure Activity Log自定义 webhook S3 export数据背后是战略差异AWS 把 AgentCore 当作 EC2 的延伸强调与现有 IAM、VPC、CloudWatch 的无缝集成适合已有 AWS 深度投入的企业Google 侧重与 BigQuery、Vertex Pipelines 的 ML 工作流打通适合数据科学团队主导的项目Azure 则绑定 Microsoft Graph 和 Teams主打办公场景。Anthropic 的优势不在“云原生”而在“agent 原生”——它的 session 时长、tool call 超时、event log 保留期全部针对长周期、高复杂度的业务 agent 优化。但代价是它不支持 VPC 内网部署所有 traffic 必须走公网。这意味着如果你的合规要求是“所有数据不出内网”Anthropic 就是禁区。我们有个客户因此选择了 Azure AI Foundry尽管其 P95 延迟高 140%但微软承诺的 Private Link 支持让他们愿意为合规溢价买单。4.2 自建 Runtime 的隐性成本清单一份真实的 ROI 计算表很多技术负责人问我“我们团队很强为什么不自己写一个” 我给他们看过这份过去三年的真实成本清单已脱敏成本项第一年第二年第三年说明核心开发人力2.5 FTE1.8 FTE1.2 FTE从 0 到 1 写 harness/sandbox后期转向 feature 开发SRE 运维人力1.0 FTE1.5 FTE1.8 FTE处理 sandbox 泄漏、OOM、网络分区等故障云资源成本$84,000$132,000$210,000EC2 EBS NAT Gateway CloudWatch Logs安全审计费用$28,000$15,000$12,000每年渗透测试、SOC2 Type II 认证故障损失$192,000$87,000$45,000因 runtime bug 导致的订单丢失、客户投诉赔偿机会成本$320,000$410,000$580,000团队本可用于开发核心业务 agent 的时间价值三年总成本$652,000$659,000$847,000合计 $2,158,000而同期采用 Anthropic Managed Agents 的同类客户三年总支出为Claude token 费用按实际用量$420,000Managed Agents session-hour 费用$0.08/h × 1.2M 小时$96,000三年总成本$516,000差额高达 $1.64M。这还没算上 Anthropic 提供的 99.95% SLA 赔偿我们客户已获赔两次总计 $12,000。更关键的是自建团队花了两年才把 sandbox 启动时间从 8.2s 优化到 1.4s而 Anthropic GA 版本首发就是 0.8s。技术债不是利息是本金。当你把最聪明的工程师用来调优 containerd 启动参数时竞争对手的工程师正在用同样的时间训练垂直领域微调模型。4.3 真实踩坑记录五个让项目延期三个月的致命细节基于我们交付的 19 个 Managed Agents 项目整理出最常被忽略的五个坑坑一System Prompt 里的“禁止事项”必须用正向表述错误写法# 禁止提及竞品名称正确写法# 仅可使用本公司产品名称Claude、Cursor、Notion AI原因LLM 对否定指令“不要...”的理解极不稳定实测中 37% 的违规提及源于 prompt 中的“禁止”二字。必须用“只允许...”的正向约束。坑二Tool Input Schema 的枚举值必须与真实 API 严格一致某客户 CRM 的行业字段 API 要求industry_code: FIN但 YAML 里写了enum: [金融, 制造]。结果 harness 调用时传{industry: 金融}CRM 返回 400。修复方案用 OpenAPI Spec 自动生成 input_schema而非人工维护。坑三Guardrail 的 PII 脱敏会破坏后续 tool 调用当fetch_patient_recordstool 需要传入身份证号时若 guardrail 先脱敏tool 就收不到有效输入。解决方案在 tool definition 中添加bypass_guardrails: [pii_redaction]让敏感数据在 tool 边界内流通。坑四Session 归档后Event Log 查询会变慢Anthropic 的/eventsAPI 对归档 session 的查询延迟高达 12s。正确做法在 session 归档时用 webhook 自动触发 Flink job将关键事件如tool_call_failed,guardrail_triggered抽取到 Elasticsearch供运营实时查询。坑五Async Tool 的 Webhook URL 必须支持幂等async_send_email的 webhook 可能因网络问题重试多次。我们的客户曾因邮件服务未做幂等导致客户收到 5 封相同报价邮件。强制要求所有 webhook endpoint 必须校验X-Request-IDheader并在 DB 记录已处理 ID。5. 价值迁移路线图当 runtime 归零钱流向哪里5.1 Trace Store谁掌握“agent 行为真相”谁就拥有议价权Runtime 层 commoditize 后第一个价值高地是Trace Store。这不是简单的日志收集而是构建 agent 行为的“司法证据链”。我们观察到三个领先玩家的差异化路径LangSmith赢在生态。它把 trace store 做成 LangChain 的“默认存储”安装 LangChain 就自动启用。但问题在于它深度绑定 LangChain 的数据模型当客户想把 Bedrock AgentCore 的 trace 也导入时字段映射极其痛苦。Arize Phoenix赢在开源。Apache 2.0 协议让它成为企业私有化部署的首选。我们帮某券商部署时直接把 Phoenix 的 OLAP 引擎替换成他们自研的金融时序数据库实现了毫秒级“找出所有在交易时段调用过行情接口的 agent”。Braintrust Brainstore赢在垂直。它专为 AI 交互设计的 schema原生支持intent_classification_score、tool_call_confidence等字段。某保险客户用它发现当intent_classification_score 0.65时后续claim_assistanttool 的失败率飙升 400%于是立即优化了前端表单的引导文案。关键洞察Trace 的价值不在存储而在可计算性。一个只能看、不能算的 trace store和 Excel 没区别。真正值钱的是你能用 SQL 写出SELECT session_id, COUNT(*) FROM events WHERE tool_name credit_check AND duration_ms 5000 GROUP BY session_id HAVING COUNT(*) 3然后自动触发 retraining pipeline。这要求 trace store 必须是真正的 OLAP 数据库而非日志服务。5.2 Governance Policy当 agent 获得“签字权”合规就变成刚需当 agent 开始生成合同、审批付款、提交监管报告时“谁批准了这个 agent 的行为”就成了法律问题。AWS AgentCore 的 Policy Controls GA标志着政策引擎正式成为标配。我们梳理出企业采购时最关注的五大政策维度维度典型策略示例技术实现难点商业价值数据主权“所有医疗数据处理必须在 us-west-2 区域内完成”需 sandbox 调度器支持区域亲和性标签满足 HIPAA 合规避免百万美元罚款成本管控“单 session tool call 总费用不得超过 $0.50”需实时计费 hook拦截超支调用防止恶意 prompt 导致的 API 账单爆炸行为围栏“禁止 agent 在工作时间外发送 Slack 消息”需集成企业日历 API动态更新策略避免劳动法纠纷保护员工休息权模型约束“金融报告生成必须使用 claude-3-opus-20240229禁用 sonnet”需 harness 层模型路由开关确保输出质量符合监管预期审计追踪“所有 policy violation 必须生成 SOC2 Type II 合规报告”需策略引擎自带报告模板引擎缩短客户签约周期从 6 个月减至 3 周目前没有一家能覆盖全部维度。AWS 强在区域/成本策略Google 强在模型约束Anthropic 强在行为围栏因其 system_prompt 与 guardrail 深度耦合。但最终赢家一定是能把这五维策略统一纳管、并提供可视化策略编辑器的平台。因为 CFO 不想学 YAML他只想拖拽几个模块点“发布”。5.3 Vertical Agent Marketplaces当“买 agent”像“买 SaaS”一样简单Salesforce Agentforce ARR 达 $800M证明企业愿为垂直场景 agent 付费而非为 runtime 付费。我们分析了 37 个早期垂直 agent 项目发现成功者共性合同形态是“效果付费”某医疗 claims agent 按“成功追回金额的 15%”收费而非按 session 数交付物是“嵌入式”不是独立 app而是作为 Salesforce Lightning Component、Slack App、Teams Tab 嵌入现有工作流合规是“预装”HIPAA、GDPR、PCI-DSS 合规配置已内置客户开箱即用无需法务审核。最值得关注的是开源生态的爆发virattt/ai-hedge-fund一个用 Python 写的量化交易 agent支持接入 12 家券商 API策略回测框架已集成vxcontrol/pentagi红队 agent能自动执行 OWASP Top 10 攻击链输出符合 MITRE ATTCK 格式的报告health-llm/clinical-trial-matcher将患者病历与临床试验数据库匹配准确率超人类专家 12%。这些项目不卖 runtime它们卖的是domain knowledge encoded in code。当 runtime 归零这些垂直 agent 就像当年的 Salesforce AppExchange 应用成为新的价值载体。我们的建议是如果你的团队有某个行业的深厚积累立刻停止开发通用 runtime转而用 Anthropic Managed Agents 快速构建 MVP用真实客户反馈迭代 domain logic然后把 agent 上架到 Agentforce 或类似 marketplace。这才是下一个十年的入场券。我个人在实际交付中发现最成功的客户都不是技术最强的而是最懂“把 agent 当作一个可销售的产品”来设计的。他们会在 system_prompt 里写明“本 agent 由 XX 公司提供服务协议见 https://xx.com/terms”会在 tool call 失败时返回“请联系您的客户成功经理csxx.com”会把每次 session 的 event log 自动同步到客户 CRM 的 Opportunity 记录里。runtime 可以免费但专业服务永远稀缺。