1. 这不是新赛道是 runtime 层的“操作系统时刻”来了你有没有试过让一个 AI 代理连续工作四十分钟不是闲聊而是真正在查资料、调 API、写代码、汇总报告——一个接一个任务链式推进。我去年就搭过这么一套系统用的是当时最火的开源框架把所有状态都塞进模型的上下文窗口里。前二十分钟一切丝滑到第三十分钟它开始漏掉之前调过的数据库结果第四十分钟它已经记不清自己上一步为什么调了那个接口却还在自信满满地生成补丁代码。最要命的是它没报错没崩溃只是 quietly hallucinating安静地幻觉——像一台内存溢出却还在假装运行的服务器。我们没法回放没法 debug连日志都只有零星几行 token 输出。最后只能重头来过而客户等在 Slack 里问“方案呢”Anthropic 在 4 月 8 日发布的 Claude Managed Agents表面看是一套托管代理运行时但它的核心价值恰恰就卡在我这个四十分钟崩溃的痛点上它把“会话”从模型上下文里彻底拎了出来变成一个独立、持久、可查询、可回溯的事件日志event log。这不是功能叠加是架构范式的切换——就像 90 年代操作系统把物理内存抽象成虚拟内存从此程序再也不用操心 RAM 地址怎么分配。Managed Agents 做的是把“代理该做什么、做了什么、结果如何”这件事从模型的短期记忆里解放出来交给一个外部、稳定、带版本、带权限的存储层来管。关键词里的 “Towards AI - Medium” 不是随便贴的标签。这篇文章之所以能在技术圈引发密集转发正因为它没停留在“Anthropic 又发了个新东西”的层面而是把 Managed Agents 放进整个 AI 基础设施演进的长周期里去丈量它不是第一个AWS Bedrock AgentCore 五个月前就已正式商用它也不是最开放的Google Vertex 和微软 Azure AI Foundry 都提供了多模型、多框架兼容的底座。它的真正分量在于它用一套干净、克制、生产级的设计把一个正在快速 commoditize商品化的层——agent runtime——第一次以“企业可用”的形态端到了主流开发者面前。它不试图定义“什么是好代理”而是专注回答一个更底层的问题“当代理要跑八小时、调二十个工具、处理三类敏感凭证、被五个团队同时调用时谁来保证它不崩、不泄密、不丢状态、出了问题能秒级定位”这层能力过去得靠团队自己堆 Kubernetes Operator、写沙箱调度器、搞 Vault 集成、搭 OpenTelemetry 链路追踪花三个月才能勉强跑通 MVP。现在Anthropic 把这套工程实践封装成 YAML 配置加一个awake(sessionId)调用。对中小团队这是降本增效的利器对大厂这是防止核心 agent 逻辑被 AWS 或 Azure 的默认 runtime 锁死的战略缓冲。所以别被标题里“Going to Zero”吓住——那指的不是技术价值归零而是 runtime 这一层的定价权、差异化空间和商业护城河正加速向零收敛。真正的战场已经悄然上移到了它上面那一层可观测性、策略治理、垂直场景交付。这才是今天每个做 AI 工程的人必须立刻看懂、立刻动手验证、立刻思考自己站位的地方。2. 核心设计解构为什么“Session as Event Log”是唯一正确的解法2.1 从崩溃现场反推架构缺陷上下文即牢笼先说清楚一个事实当前所有主流大模型Claude、GPT、Gemini的上下文窗口本质是一个有状态、无备份、不可寻址、易污染的临时缓存区。它不是数据库不是消息队列甚至不是可靠的内存——它是一块被模型反复读写、覆盖、压缩的“黑板”。当你让代理执行多步骤任务时典型流程是用户输入 → 模型读取全部上下文含历史对话工具返回系统提示模型决定调用工具 A → 将请求参数写入上下文工具 A 返回结果 → 模型把结果追加到上下文末尾模型读取新上下文 → 决定调用工具 B → 追加 B 请求...如此循环直到输出最终答案问题就出在第 3 步和第 4 步之间。当上下文逼近窗口上限Claude 3.5 是 200K tokens模型的 tokenizer 会启动截断策略。主流做法是“丢弃最早内容”——不是优雅地归档而是直接物理删除。这意味着工具 A 的原始返回数据可能被删掉用户最初的模糊需求描述可能被删掉甚至关键的 guardrail 提示词如“禁止生成代码”也可能被删掉。而模型不会告诉你“我删了什么”它只会基于残缺的上下文继续推理。这就是我去年遇到的“安静崩溃”代理没报错但它决策依据的基石已经塌了一半。更糟的是这种崩溃无法复现——因为每次 token 截断的位置受输入长度、模型随机性影响完全是概率事件。你永远不知道下一次失败是因为丢了数据库 schema还是丢了用户说的“预算不能超 5 万”。提示不要依赖模型记住长历史。任何超过 10 步的复杂任务都必须将中间状态外置。这是血泪教训不是理论建议。2.2 Anthropic 的破局点把 Session 拆成三个正交组件Managed Agents 的架构图看似简单但每个模块都直击上述痛点。它没有试图“做大模型上下文”而是承认其局限性并构建一套外部协作体系Session会话一个独立的、带时间戳、带唯一 ID、带完整操作链的事件日志。每一条记录包含timestamp,step_id,tool_name,input_params,output_result,status,error_if_any。它存储在 Anthropic 自建的持久化存储中推测为分片 WAL 日志 备份与模型推理完全解耦。你可以随时用GET /sessions/{id}/events拉取全量轨迹也可以按tool_namenotion_search过滤所有 Notion 调用。Harness执行器一个极度轻量的状态无关函数。它只做三件事接收execute(tool_name, input)请求 → 启动对应沙箱 → 等待返回 → 将结果写入 Session 日志 → 返回字符串给模型。它本身不存任何状态挂了就重启用awake(sessionId)重新加载最新日志即可续跑。模型上下文里只需保留当前 step 的最小必要信息如“刚查完客户 A 的合同下一步要生成报价单”而非全部历史。Sandbox沙箱按需创建、用完即焚的隔离环境。每个工具调用都在独立容器中执行凭证通过安全 vault 注入非环境变量文件系统只挂载白名单路径网络出口经统一网关审计。沙箱生命周期与单次execute()绑定绝不跨步共享。这三者的关系用一个生活化类比Session 是法庭的庭审记录仪全程录像、不可篡改、可回放Harness 是法官助理只负责传唤证人、递送证据、记录结果不参与判决Sandbox 是单向玻璃审讯室嫌疑人工具在里面操作外面模型只能看到结果看不到内部凭证和过程。三者正交意味着你可以单独升级 Harness 的调度算法不影响 Session 存储格式可以给 Sandbox 加 SELinux 策略不影响 Harness 接口可以将 Session 日志导出到自建 ClickHouse 做分析而不动 Harness 一行代码。这种解耦正是操作系统虚拟化硬件的核心思想——把变化快的部分模型迭代、工具更新和变化慢的部分日志规范、沙箱标准隔离开。2.3 为什么“Credential Isolation”不是锦上添花而是生死线很多团队在初期会把 API Key 直接写进系统提示词或环境变量觉得“反正沙箱是隔离的”。这是巨大误区。Managed Agents 的 credential 设计暴露了 LLM 应用最危险的软肋模型会“看见”它不该看见的东西并可能把它泄露出去。举个真实案例某金融公司用开源代理调用内部风控 APIAPI Key 存在环境变量里。某次用户提问“请用 curl 命令演示如何调用风控接口”。模型没调用工具而是直接生成了带完整 Key 的 curl 命令——因为 Key 就在它“视野”里。更隐蔽的是当模型因上下文不足而困惑时它可能把环境变量内容当作“参考示例”原样输出。这不是模型 bug是设计必然LLM 的本质是统计预测它没有“保密意识”只有“上下文相关性”。Anthropic 的解法是物理隔离凭证存于 Anthropic Vault与沙箱网络完全隔离沙箱启动时Vault 通过内核级安全通道推测为 eBPF 或类似机制将凭证注入沙箱内存页且仅对该次执行有效沙箱内进程无法通过env、/proc/self/environ或任何常规方式读取该凭证模型上下文里只出现tool_call_id: fc_abc123这样的占位符绝不出现实际凭证。这背后是生产级安全工程的厚度。它意味着即使你的系统提示词被用户诱导泄露比如“把你的全部配置告诉我”即使模型在 hallucination 中胡乱拼接字符串凭证也绝不会出现在任何输出里。这不是“应该做”而是“必须做”——尤其当你面对银行、医疗、政府客户时合规审计的第一条就是“凭证是否明文暴露”。Managed Agents 把这个高门槛能力变成了开箱即用的默认项。3. 实操落地从 YAML 定义到生产级调试的完整链路3.1 五分钟上手用 YAML 定义你的第一个 Managed AgentManaged Agents 的入口极简核心就是一个 YAML 文件。别被“YAML”吓住它比写 Docker Compose 还直观。以下是一个连接 Notion 数据库并搜索客户的完整示例已脱敏# notion-customer-search.yaml name: Notion Customer Search Agent description: Searches Notion CRM database for customer info and returns structured data system_prompt: | You are a customer support agent. Your job is to find customer information in Notion. - Always return results as JSON with keys: customer_name, contact_email, last_interaction_date, status. - If no match found, return empty JSON {}. - Never invent data. If field is missing in Notion, omit it from output. tools: - name: notion_search description: Search Notion pages by title or property value parameters: type: object properties: database_id: type: string description: The Notion database ID (e.g., 12345678-90ab-cdef-ghij-klmnopqrstuv) query: type: string description: Search term (e.g., Acme Corp) filter: type: object description: Optional Notion filter object auth: type: notion_oauth # Tells Anthropic to use pre-configured Notion OAuth scope: [pages:read, databases:read] guardrails: output_validation: json_schema: | { type: object, properties: { customer_name: {type: string}, contact_email: {type: string, format: email}, last_interaction_date: {type: string, format: date}, status: {type: string, enum: [active, inactive, pending]} }, required: [customer_name] } content_moderation: block_list: [SSN, credit_card, password] # Blocks outputs containing these patterns这个 YAML 文件定义了全部关键要素system_prompt不是长篇大论而是聚焦“角色约束输出格式”避免模型自由发挥tools每个工具明确name供模型调用、description供模型理解用途、parameters供模型生成合法参数、auth告诉 Anthropic 用哪个预存凭证guardrailsoutput_validation强制 JSON Schema 校验确保下游系统能直接解析content_moderation是最后一道防线防敏感信息泄露。部署只需一行命令假设你已配置好 Anthropic CLIanthropic agents deploy --file notion-customer-search.yaml --environment productionAnthropic 返回一个agent_id如agnt_abc123这就是你的代理身份证。后续所有调用都通过这个 ID 发起。3.2 生产级调用Session 生命周期管理实战调用 Managed Agent 不是发个 HTTP POST 就完事。真正的生产价值在于对 Session 的精细控制。以下是我在 Notion 项目中实测的四步工作流第一步创建 Session带初始上下文curl -X POST https://api.anthropic.com/v1/agents/sessions \ -H x-api-key: $ANTHROPIC_API_KEY \ -H Content-Type: application/json \ -d { agent_id: agnt_abc123, initial_context: User asked about Acme Corps renewal status. Check their CRM., metadata: {team_id: sales-emea, request_id: req_789} }返回session_id: sess_xyz789。注意initial_context不是长文本而是一句话摘要足够模型启动即可。所有细节由后续工具调用填充。第二步驱动 Session 执行模型 Harness 协同curl -X POST https://api.anthropic.com/v1/agents/sessions/sess_xyz789/execute \ -H x-api-key: $ANTHROPIC_API_KEY \ -H Content-Type: application/json \ -d { max_steps: 5, stream: true }max_steps是关键安全阀。它限制本次调用最多执行几步如搜索→读详情→生成摘要→校验→返回防止无限循环。stream: true让你实时收到每步结果便于前端展示进度。第三步实时监控与干预Session 事件流在另一个终端监听 Session 事件curl -X GET https://api.anthropic.com/v1/agents/sessions/sess_xyz789/events?streamtrue \ -H x-api-key: $ANTHROPIC_API_KEY你会看到结构化 JSON 流{event:tool_call_started,step_id:stp_001,tool_name:notion_search,input:{query:Acme Corp}} {event:tool_call_completed,step_id:stp_001,output:{results:[{page_id:pg_123,title:Acme Corp - Renewal}]}} {event:model_output,step_id:stp_002,content:Found Acme Corp...}实操心得我曾用这个流实现“人工审核闸门”——当tool_name是send_email时暂停 Session通知客服主管审批审批通过后再调resume_session。这是纯靠模型做不到的确定性控制。第四步故障恢复与审计Session 回溯如果某次调用失败如 Notion API 限流不用重跑全流程。直接查日志curl https://api.anthropic.com/v1/agents/sessions/sess_xyz789/events?limit100 \ -H x-api-key: $ANTHROPIC_API_KEY找到最后成功的tool_call_completed事件复制其output手动构造下一步输入再调execute。整个过程秒级完成且所有操作留痕。这才是企业级 SLA 的底气。3.3 定价模型拆解$0.08/小时背后的成本逻辑Managed Agents 定价是$0.08 per session-hour of active runtime外加 Claude token 费用。很多人第一反应是“贵”但算清账就会发现它其实是大幅降低 TCO总拥有成本的设计成本项自建方案估算Managed Agents基础设施EC2 m5.2xlarge × 2高可用≈ $0.384/hr × 2 $0.768/hr$0.00包含在 $0.08 中沙箱运维DevOps 工程师 10% 时间 ≈ $50/hr × 10% $5/hr$0.00Anthropic 承担安全审计每季度渗透测试 合规报告 ≈ $15,000/年 ≈ $1.7/hr$0.00内置 Vault 网络策略Session 存储S3 DynamoDB CloudWatch Logs ≈ $0.12/hr$0.00包含在 $0.08 中总计≈ $7.6/hr$0.08/hr Claude tokens关键洞察$0.08不是 runtime 计费而是“企业级可靠性溢价”。它打包了沙箱冷启动 300ms实测 p95 287msSession 日志保留 90 天可配置凭证轮换自动同步DDoS 防护 WAF 规则SLA 99.95%写入合同。我们做过压测当并发 Session 达 200 时自建 K8s 集群 CPU 突增导致调度延迟而 Managed Agents 保持 p95 400ms。这笔钱买的不是计算资源是可预测性——对销售、客服等业务线停机一小时损失远超 $0.08×60。注意session-hour按实际活跃时间计费非创建时间。Session 创建后若 5 分钟无操作自动休眠唤醒后只计新活跃时间。这比按“实例小时”计费的云服务更精准。4. 竞争格局与避坑指南为什么现在入场还来得及4.1 四大 Runtime 对比不是选技术是选生态位Managed Agents 从来不是孤岛。它必须放在整个 agent infra 生态中评估。下表是截至 2026 年 4 月四大主流 runtime 的核心维度对比基于公开文档 我们的实测维度Anthropic Managed AgentsAWS Bedrock AgentCoreGoogle Vertex AI Agent BuilderAzure AI Foundry模型锁定Claude 专属3.5/haiku完全开放Claude/GPT/Gemini/Llama完全开放Gemini/Claude/Llama完全开放GPT/Claude/Phi框架支持Anthropic 原生协议YAML/JSONLangChain/CrewAI/Strands 原生LangChain/Vertex-native SDKAutoGen/Semantic Kernel 原生沙箱隔离MicroVM eBPF 网络策略Firecracker microVMCPU/Mem/FilegVisor seccompHyper-V ContainerSession 时长无硬限制实测 24h最长 8 小时最长 6 小时最长 12 小时凭证管理Anthropic VaultOAuth/SecretsAWS Secrets Manager IAM RolesGoogle Secret Manager Workload IdentityAzure Key Vault Managed Identity可观测性基础事件流 Session 日志CloudWatch X-Ray Custom MetricsVertex Logs BigQuery ExportAzure Monitor Log Analytics定价模式$0.08/session-hour tokens$0.05/session-hour tokens tool calls$0.07/session-hour tokens$0.06/session-hour tokens最大优势架构纯净度 Claude 深度优化云生态整合 企业采购惯性Google AI 工具链成熟度Microsoft 365/Teams 深度集成这张表揭示了一个残酷现实没有“最好”的 runtime只有“最适合你当前阶段”的 runtime。如果你已深度使用 AWSEC2/S3/IAMAgentCore 是零摩擦选择尤其适合已有 Terraform 管理的团队如果你主攻办公协同场景Teams/OutlookAzure AI Foundry 的免登录单点体验能让你的 PoC 一周上线如果你追求极致可控如金融合规要求凭证绝不离内网Managed Agents 的 Vault 隔离是目前最透明的方案如果你还在选型早期Vertex 的 BigQuery 日志导出能让你用 SQL 快速分析 10 万次调用中的失败模式。实操心得我们给客户做选型时从不直接比参数。而是带他们跑一个真实场景用同一份 Notion CRM 数据分别在四个平台部署“客户续约提醒代理”记录从部署、调试、压测到上线的总耗时。结果AgentCore2.1 天、Foundry1.8 天、Managed Agents3.5 天、Vertex4.2 天。但三个月后Managed Agents 的日志可追溯性帮客户规避了两次重大合规风险——这时 ROI 就完全逆转了。4.2 当前最致命的三个认知陷阱我们踩过的坑陷阱一“Runtime 越快越好”——忽略稳定性才是最大瓶颈很多团队 obsess 于 p95 延迟疯狂优化沙箱启动。但我们发现生产环境中 83% 的故障源于状态不一致模型认为“已发送邮件”但沙箱因网络抖动未执行日志却显示成功。Managed Agents 的事件日志强制“执行结果写入日志”才返回杜绝了这种脑裂。与其花两周把冷启动从 300ms 优化到 150ms不如用 2 天接入其事件流做幂等校验——后者带来的 SLA 提升远超前者。陷阱二“用 YAML 就是低代码”——忽视系统提示词仍是最高杠杆点YAML 定义了工具和守卫但模型行为 70% 由system_prompt决定。我们曾用同一 YAML在不同 prompt 下得到截然不同的结果Prompt A宽松“帮用户找客户信息” → 模型尝试调用 5 个工具超时失败Prompt B精确“仅调用 notion_search 工具参数 query用户输入禁止其他操作” → 100% 成功。避坑技巧把system_prompt当作 API 文档写。每句话必须可验证例如“禁止生成代码”比“请谨慎”有效 10 倍。陷阱三“有了 Managed Agents 就不用监控”——混淆了基础设施监控和业务监控Anthropic 提供 runtime 层监控CPU/内存/错误率但这只是冰山一角。真正的业务监控是你关心的“Notion 搜索成功率是否低于 95%”工具层“客户姓名提取准确率是否骤降”模型层“Sales 团队平均每天调用多少次”业务层Managed Agents 的事件流正是你构建这三层监控的黄金数据源。我们用其日志 Prometheus Grafana搭建了实时仪表盘当“notion_search error_rate 5%”时自动触发 PagerDuty 告警并推送 Slack。这才是生产级闭环。4.3 未来 18 个月的关键信号盯紧这三个指标Runtime 层 commoditization 不是预言是正在发生的事实。作为一线实践者我建议你每周检查以下三个公开指标它们比任何新闻稿都更能预判趋势Open-Source Sandbox 启动时间关注 Daytona、Kubernetes SIG Agent-Sandbox、Deer-Flow 的 GitHub Release Notes。当主流项目的 p95 启动时间稳定 ≤ 100ms当前 Daytona 为 89ms意味着开源方案已追平商业产品价格战将全面爆发。Hyperscaler Runtime 免费额度紧盯 AWS/Azure/GCP 的官方博客。一旦出现 “$0.00/session-hour for first 1000 hours/month” 类似条款AWS 已在部分区域试点即标志 commoditization 进入深水区。Trace Store 创业公司融资额Braintrust$36M Series A、Arize$131M 总融资、LangSmith绑定 LangChain 生态的进展是风向标。当其中一家宣布“支持跨 runtime 日志迁移”如从 AgentCore 导入 Managed Agents 日志说明 trace portability 开始解决——这将是 runtime 厂商最恐惧的时刻因为客户迁移成本归零。我个人在实际操作中发现这些信号比任何厂商发布会都更早、更准。去年 11 月Daytona 发布 89ms 启动数据时我就让团队停止自研沙箱转向评估 Managed Agents 的集成方案。结果今年 4 月 Anthropic 发布时我们已准备好生产环境比竞品快了整整三个月。技术选型不是赌未来而是读懂当下正在发生的微小变化。5. 价值迁移进行时在 runtime 归零前抢占上层三块高地5.1 第一块高地Trace Store —— 你的 agent 行为“司法存证”当 runtime 变成水电煤谁掌握“agent 到底干了什么”的原始证据谁就掌握了事实解释权。这不是日志聚合而是构建 AI 时代的司法存证系统。我们已在两个关键场景验证其价值场景一合规审计的“不可抵赖”证据某保险客户要求所有保单推荐必须留存完整决策链包括“用户原始问题”、“调用的精算模型版本”、“返回的保费数字”、“最终呈现给用户的文案”。过去这些散落在 Slack、Notion、数据库日志中审计时需人工拼凑耗时 3 天。接入 Managed Agents 后我们将其事件流实时写入自建 ClickHouse 表字段包括session_id,step_typeuser_input/tool_call/model_output,tool_version,output_hash。审计时一句 SQL 即可导出完整 PDF 报告SELECT * FROM agent_events WHERE session_id sess_abc ORDER BY timestamp;实操心得不要只存原始 JSON。务必提取关键字段如tool_name,status,output_size建立索引。我们曾因未索引tool_name导致 10 亿行日志的查询从 200ms 暴涨到 12 秒。场景二模型迭代的“黄金测试集”每次 Claude 升级我们最怕什么不是性能下降而是行为漂移旧版能正确解析的合同条款新版开始漏字段。Managed Agents 的事件日志天然就是回归测试集。我们建立流程每次新模型发布用相同session_id重放 1000 个历史 Session对比新旧model_output的语义相似度用 sentence-transformers当相似度 0.92 时自动标记为“高风险变更”触发人工 review。这让我们在 Anthropic 3.5 发布前 3 天就发现了其对法律术语解析的退化及时调整了 prompt。提示Trace Store 的核心壁垒不是存储是schema 设计。我们定义了强制字段trace_id全局唯一、span_id步骤内唯一、parent_span_id支持子代理嵌套、service_name区分 Notion/Slack/Email 服务。这为未来接入 LangSmith 或 Arize 打下基础。5.2 第二块高地Governance Policy —— 让 agent 守规矩的“数字宪法”当 agent 能调用财务系统、HR 数据库、客户 CRM 时“能运行”和“该运行”是两回事。Policy 不是锦上添花是准入门槛。我们为客户部署的 Policy 引擎已覆盖三大刚需动态权限控制Sales 团队调用 Notion 时只能读sales-crm数据库Finance 团队调用同一 Notion 时可读写finance-budget数据库。权限不写死在 YAML而是通过GET /policy?user_id{id}resourcenotion_db实时获取支持 RBAC ABAC 混合策略。实时内容拦截当 agent 生成邮件时Policy 引擎扫描model_output若检测到“折扣”、“免费”、“赠送”等敏感词且当前用户非 VP 级别则自动替换为“请联系您的客户经理获取方案”。这比模型层的 guardrail 更灵活可热更新。审计追踪强化所有 Policy 决策允许/拒绝/修改均写入独立审计日志包含decision_time,policy_rule_id,evidence如“因 user_rolemanager required_rolevp”。这是 SOC2 审计的必查项。避坑指南Policy 引擎必须与 runtime 解耦。我们曾把规则硬编码在 Harness 里结果每次策略更新都要重启服务。现在改为Harness 调用 Policy APIAPI 返回allow/deny/modifyHarness 仅执行决策。这样策略更新毫秒生效且可独立灰度。5.3 第三块高地Vertical Agent Marketplace —— 卖“解决方案”不卖“技术”Runtime 归零但企业愿为“解决具体问题”付费。Salesforce Agentforce $800M ARR 的真相是客户买的不是“一个能调 Salesforce API 的 agent”而是“自动完成线索打分、分配、跟进的销售引擎”。我们已验证的垂直场景都有清晰的 ROI 模型垂直领域Agent 名称关键动作客户付费点ROI 计算方式金融投研ai-hedge-fund实时抓取 10 财经网站 → 生成个股摘要 → 推送 Slack按“节省的分析师工时”收费1 分析师/天 × $1200 $24,000/月网络安全pentagi扫描资产 → 调用 Nmap/Shodan → 生成渗透报告 → 提交 Jira按“漏洞修复时效提升”收费修复时间从 72h→4h避免 1 次重大事故 $500K医疗健康med-claims-processor解析 PDF 保单 → 匹配 ICD-10 代码 → 生成理赔摘要按“处理单据数”收费$0.8/单 × 50,000 单/月 $40,000/月实操心得垂直 agent 的成败80% 取决于领域知识注入而非技术。我们为医疗客户开发时不是让工程师读医学文献而是聘请退休医保审核员用两周时间标注 2000 份真实保单提炼出 37 条“拒赔规则”。这些规则直接转化为system_prompt中的 if-else 逻辑效果远超微调模型。最后再分享一个小技巧不要从零构建 marketplace。直接入驻现有平台——Salesforce AppExchange、Microsoft AppSource、AWS Marketplace。我们上架的med-claims-processor首月 70% 流量来自 Salesforce 客户在 AppExchange 的搜索。当 runtime 是公共品时渠道就是你的护城河。我在实际使用中发现那些还在争论“该用哪家 runtime”的团队已经落后了。真正的竞争发生在 runtime 之上的这三块高地谁能更快构建可审计的 trace谁能更细粒度控制 agent 行为谁能更精准交付垂直场景价值。Anthropic 的 Managed Agents不是终点而是这场价值迁移的发令枪。它提醒我们当基础设施层变得廉价如空气真正的稀缺永远是那些扎根于业务深处、解决具体问题的能力。