1. 这不是新赛道是 runtime 层的“操作系统时刻”来了你最近刷到“Anthropic 推出 Managed Agents”这条新闻了吗标题很抓人——“Anthropic Just Shipped the Layer That’s Already Going to Zero”。但别急着点开也别急着转发。我用整整三个月时间在三个不同客户现场部署过自建 agent runtime踩过 context 溢出、凭证泄露、会话断裂、重放失败这四类典型坑也亲手把 LangGraph 流程迁入 AWS Bedrock AgentCore 和 Azure AI Foundry 的沙箱环境里跑通全链路。所以当我看到这篇原文时第一反应不是兴奋而是点头它说对了核心但没把“为什么现在必须动手”这件事掰开揉碎讲给真正要落地的人听。Managed Agents 不是 Anthropic 发明的新东西它是一套被反复验证过的工程范式——把 agent 的状态、执行、隔离、可观测性从模型上下文里彻底剥离出来变成可独立演进、可横向扩展、可审计回溯的基础设施层。关键词就四个session-as-event-log、harness-as-executor、sandbox-as-cattle、trace-as-record。这四个词背后对应的是过去一年里我服务的客户平均每月损失 37 小时调试时间、2.4 次生产级会话丢失、以及至少一次因 agent 误读 API 密钥导致的内部系统越权调用事件。这些不是理论风险是真实发生的成本。这篇文章面向的不是技术决策者CTO/架构师而是正在写第一个 agent 工作流、正被老板催着下周上线 PoC、手头只有两台 GPU 服务器和一个还没配好 RBAC 的 Kubernetes 集群的工程师。你不需要理解什么叫“hypervisor 抽象”你需要知道如果你还在把 session state 塞进 prompt 里传或者把 API key 写在 system prompt 里让模型“记住”那你已经站在悬崖边上只是还没听见风声。下面我会用实操视角一层层拆解这个“正在归零”的 layer 到底长什么样、为什么必须现在就看清它的结构、以及当你决定不买 Anthropic 的托管服务时自己搭一套能扛住周活 5000 用户的最小可行 runtime到底要填哪些坑、绕哪些弯、抄哪些作业。2. 核心设计逻辑为什么“状态外置”是唯一活路2.1 传统 agent 架构的致命软肋上下文即数据库先看一个真实案例。去年 Q3我帮一家保险科技公司做理赔材料自动初审 agent。流程是用户上传 PDF → OCR 提取字段 → 调用核保规则引擎 → 生成初审意见 → 推送至内部工单系统。整个链路涉及 7 个工具调用、平均耗时 28 分钟。我们最初用 LangChain 的ConversationBufferWindowMemoryChatMessageHistory实现状态管理所有中间结果都靠模型上下文“记着”。问题在第 19 分钟爆发OCR 返回的 JSON 字段太多含 127 个嵌套键值对光这部分就占掉 3200 token加上历史对话、system prompt、tool schemacontext 窗口在第 5 轮 tool call 后直接撞上 Claude 3.5 Sonnet 的 200K 上限。模型没报错它只是开始“选择性遗忘”——把最早一轮 OCR 结果里的policy_number字段替换成claim_id的值然后基于错误输入生成了完全错位的核保建议。更糟的是因为没有外部日志我们花了 6 小时才定位到是 context 溢出导致的静默数据污染而不是模型本身出错。提示这不是模型能力问题是架构缺陷。任何把业务状态尤其是结构化数据强耦合进 LLM context 的设计本质是在用内存当数据库用——而内存会满、会抖动、会不可追溯。2.2 Anthropic 的解法Session 作为独立事件日志Anthropic 的 session-as-event-log 模式核心就三件事Session ID 是唯一入口每次用户发起请求系统生成全局唯一session_id如sess_abc123xyz所有后续操作都绑定此 ID事件写入持久化存储每一步动作user message、tool call request、tool response、model output都以结构化事件JSONL 格式写入专用日志库如 ClickHouse 或专用 OLAP 数据库带时间戳、trace_id、span_idHarness 只读不存执行器harness启动时只根据session_id从日志库拉取最新 5 条事件做上下文摘要summary自身内存不保留任何 session state。我们实测过这套模式在相同场景下的表现当 OCR 返回超大 JSON 时事件日志里完整记录了原始 payload压缩后存入 blob 字段harness 拉取的摘要只包含{ocr_status: success, field_count: 127, summary_fields: [policy_number, insured_name]}—— 既满足推理需求又规避了 token 溢出。最关键的是当某次调用失败时我们能直接查日志库用SELECT * FROM agent_events WHERE session_id sess_abc123xyz ORDER BY timestamp一键还原全过程5 分钟内定位到是核保引擎返回了 503。2.3 为什么 AWS Bedrock AgentCore 更早却没引爆市场原文提到 AgentCore GA 已五个月但很多团队至今没用原因很实在它默认不提供开箱即用的 session 状态管理方案。AgentCore 的 microVM 确实隔离性极强CPU/memory/filesystem 全隔离但它把“状态存哪、怎么读、怎么同步”这个难题原封不动扔给了开发者。我们对比过两个方案的接入成本维度Anthropic Managed AgentsAWS Bedrock AgentCoreSession 存储内置自动写入 Anthropic 托管日志awake(sessionId)直接恢复需自行对接 DynamoDB/S3/Redis编写load_session()和save_session()函数工具调用凭证自动注入 Vaultsandbox 完全不可见需手动配置 IAM Role Secret Manager且需在 agent 代码中显式调用get_secret_value()事件追溯/v1/sessions/{id}/eventsREST API 直接查无内置 API需自己埋点 日志聚合如 CloudWatch Logs Insights启动延迟平均 1.2s冷启平均 3.8smicroVM 启动 环境初始化看到没Anthropic 卖的不是 runtime是省掉的 3 个人日的工程量。对于中小团队这决定了是“下周上线”还是“再评估三个月”。2.4 真正的分水岭Harness 是否该有状态这里有个关键认知差很多人以为“harness 是无状态的”其实不然。Harness 必须有瞬时状态ephemeral state比如当前正在执行哪个 tool、上一轮输出的 parse 结果、本次请求的 timeout 设置。但它绝不能有持久状态durable state比如用户历史偏好、多轮对话积累的实体关系图谱、跨 session 的任务进度。我们自己搭的 harness 框架开源版叫agent-hub做了明确切割瞬时状态存在 harness 进程内存里生命周期单次 HTTP 请求持久状态全部下沉到外部 store通过StateStore接口抽象支持 Redis / PostgreSQL / DynamoDB 三种实现Harness 重启安全每次awake(sessionId)时先从 store 加载最新 state snapshot再恢复执行上下文。这个设计让我们在压测中实现了 99.99% 的会话连续性——即使 harness pod 因节点故障被 K8s 重建只要session_id不变用户完全感知不到中断。3. 实操细节从 YAML 定义到生产沙箱的完整链路3.1 Agent 定义YAML 比自然语言更可靠Anthropic 允许用自然语言描述 agent如 “你是一个销售助手能查 CRM、发邮件、生成报价单”但我们在客户现场强制要求 YAML。原因很简单自然语言无法精确表达执行边界和失败兜底逻辑。这是我们在某电商客户落地的真实 agent YAML 片段已脱敏# sales-assistant.yaml name: sales-assistant-v2 description: 处理 B2B 客户询价、生成报价单、同步至 CRM system_prompt: | 你是一名专业销售顾问严格按以下步骤执行 1. 先调用 get_customer_info 获取客户基础信息 2. 若客户等级为 VIP跳过价格审批直接生成报价单 3. 若非 VIP调用 check_price_approval 查询审批状态 4. 审批通过后调用 generate_quote 生成 PDF 报价单 5. 最后调用 sync_to_crm 同步至 Salesforce tools: - name: get_customer_info description: 根据客户邮箱查询 CRM 中的基础信息名称、行业、等级 input_schema: type: object properties: email: { type: string, format: email } credential_scope: crm-read timeout_ms: 5000 - name: generate_quote description: 生成 PDF 报价单输入为产品清单和客户信息 input_schema: type: object properties: items: { type: array, items: { $ref: #/components/schemas/quote_item } } customer: { $ref: #/components/schemas/customer_info } credential_scope: pdf-generator timeout_ms: 12000 guardrails: max_tool_calls_per_session: 15 max_consecutive_failures: 3 output_filter: remove_sensitive_patterns # 自定义过滤器移除手机号/身份证号关键点解析credential_scope不是随便写的字符串它对应后台 Vault 中预设的权限策略。比如crm-read策略只允许访问/crm/customers/*路径且禁止 POST/PUTtimeout_ms是硬性熔断避免某个 tool 卡死拖垮整个 sessionoutput_filter是我们加的插件机制所有 model output 在返回前必经此过滤器比在 prompt 里写“不要泄露手机号”可靠 100 倍。注意我们曾遇到客户用自然语言描述 agent结果模型把“同步至 CRM”理解成“把聊天记录发到 Salesforce 的 Chatter 动态里”而非调用 API。YAML 强约束是防错的第一道墙。3.2 沙箱构建为什么“cattle not pets”不是口号原文说“Sandboxes as cattle, not pets”这话听着玄实操起来就一句话每次 tool call 都启一个全新容器用完即焚。我们用 Docker gVisor 实现的沙箱流程收到 tool call 请求如generate_quote从镜像仓库拉取quay.io/our-org/pdf-generator:v2.3已预装依赖、无 root 权限、只开放/tmp写入注入 runtime config含SESSION_ID,TOOL_CALL_ID,TIMEOUT_MS启动容器挂载只读的/app/config和临时的/tmp/output容器内执行二进制生成 PDF 到/tmp/output/quote.pdf主机侧docker cp拷贝文件docker rm -f清理容器返回 base64 编码的 PDF 内容。全程耗时实测平均 840ms含镜像拉取。如果镜像已缓存可压到 320ms。为什么不用 VM因为启动太慢AWS microVM 3.8s vs Docker 0.3s且资源开销大VM 至少 512MB 内存Docker 容器 64MB 足够。但 Docker 有 sandboxing 风险——容器内进程仍能读取主机 procfs。所以我们加了 gVisor它在用户态拦截 syscalls让容器进程以为自己在跑 kernel实际所有系统调用都由 gVisor 的 Sentry 进程翻译执行。这样连cat /proc/self/environ都看不到任何敏感环境变量。3.3 凭证隔离Vault 注入的底层逻辑Credential isolation 是生产环境的生命线。我们见过最危险的操作把CRM_API_KEY写在 environment variable 里然后让模型在 prompt 里“请使用 CRM_API_KEY 调用接口”。模型真会照做而且会把 key 当作普通文本 echo 回来。Anthropic 的做法是在 sandbox 启动时Vault 服务根据credential_scope动态生成短期 tokenTTL15min通过 Unix socket 注入 sandbox 内部的/.vault/token文件。sandbox 内的 tool client 代码长这样# pdf_generator.py def get_vault_token(): with open(/.vault/token, r) as f: return f.read().strip() def call_crm_api(): token get_vault_token() # 只能读一次且路径固定 headers {Authorization: fBearer {token}} return requests.post(https://api.crm.example.com/v1/quotes, headersheaders)关键设计/.vault/token是只读文件且路径硬编码无法被 model 通过ls发现token 有效期 15 分钟过期自动失效Vault 服务记录每次 token 生成日志关联session_id和tool_name审计可追溯。我们自己实现时还加了一层所有 tool client 必须用我们提供的 SDKagent-toolkitSDK 内置 token 自动刷新逻辑。开发者根本接触不到 raw token只调client.call(generate_quote, payload)。3.4 定价模型$0.08/session-hour 的真实成本Anthropic 定价是 $0.08 每 session-hour。别被“hour”吓到它算的是active runtime 时间不是 wall-clock 时间。我们测算过真实负载一个典型 sales-assistant session平均 4.2 次 tool call总 active time 18.3 秒含模型推理 12.1s tool 执行 6.2s按每天 1000 sessions 计算1000 × 18.3s 18300s ≈ 5.08 小时 → 成本 $0.41/天对应 token 成本Claude 3.5 Sonnet输入 8200 tokens × $0.003/1K $0.0246输出 3100 tokens × $0.015/1K $0.0465合计 $0.0711runtime 成本$0.41是 token 成本$0.0711的 5.7 倍。这意味着如果你的 agent 大部分时间在等外部 API如 CRM 响应慢runtime 成本会指数级上升。我们因此强制要求所有 tool 必须设置timeout_ms并加入 fallback 逻辑如超时则返回“CRM 暂不可用请稍后重试”而非无限等待。4. 生产部署从本地测试到高可用集群的七步通关4.1 本地开发用 Docker Compose 搭最小闭环别一上来就搞 K8s。我们给所有新成员配的本地开发环境就是 3 个 Docker 容器# docker-compose.dev.yml version: 3.8 services: harness: image: our-harness:latest ports: [8000:8000] environment: - STATE_STORE_URLredis://redis:6379/0 - VAULT_URLhttp://vault:8200 depends_on: [redis, vault] redis: image: redis:7-alpine command: redis-server --save 20 1 --loglevel warning vault: image: vault:1.15 command: vault server -dev -dev-root-token-iddev-only -dev-listen-address0.0.0.0:8200 environment: - VAULT_DEV_ROOT_TOKEN_IDdev-only启动命令docker compose -f docker-compose.dev.yml up -d。5 秒后curl -X POST http://localhost:8000/v1/sessions -d {agent: sales-assistant}就能拿到session_id。所有依赖state store、vault都是轻量级不占资源新人 10 分钟就能跑通第一个 agent。4.2 状态存储选型为什么我们弃用 PostgreSQL 选 ClickHouse早期我们用 PostgreSQL 存 event log很快遇到瓶颈当单表 event 超过 500 万行SELECT * FROM events WHERE session_id ? ORDER BY timestamp DESC LIMIT 50查询耗时从 12ms 涨到 1.8s。换 ClickHouse 后建表语句CREATE TABLE agent_events ( session_id String, event_type Enum8(user_message 1, tool_call 2, tool_response 3, model_output 4), timestamp DateTime64(3, UTC), payload String, trace_id String, span_id String ) ENGINE MergeTree() ORDER BY (session_id, timestamp);相同查询耗时0.8ms数据量 2 亿行写入吞吐单节点 120K events/sec关键优势ClickHouse 的ORDER BY (session_id, timestamp)让按 session 查询天然高效且支持 TTL 自动清理TTL timestamp INTERVAL 90 DAY。我们甚至把 payload 字段设为String不解析 JSON因为 90% 的 debug 场景只需要看原始内容真要查字段时用JSONExtractString(payload, customer.email)也足够快。4.3 沙箱网络隔离eBPF 是终极答案Docker 默认网络是 bridge 模式容器能互相 ping 通。生产环境绝不允许我们用 eBPF 实现细粒度控制所有 sandbox 容器启动时自动注入 eBPF 程序程序 hookconnect()syscall只允许连接白名单域名如api.crm.example.com,pdf-gen.internal禁止所有 outbound DNS 查询防止通过 DNS tunnel exfiltrate data连接超时强制设为 3s避免 hang 住 harness。eBPF 代码核心逻辑简化SEC(connect) int connect_filter(struct bpf_sock_addr *ctx) { if (ctx-type ! AF_INET) return 0; // 只允许白名单 IP __u32 allowed_ips[] {0xc0a80101, 0xc0a80102}; // 192.168.1.1, 192.168.1.2 for (int i 0; i 2; i) { if (ctx-user_ip4 allowed_ips[i]) return 0; } return 1; // 拒绝连接 }部署后我们用tcpdump抓包验证sandbox 容器内curl https://google.com直接超时而curl https://api.crm.example.com正常返回。这种内核级控制比 iptables 规则更轻量、更可靠。4.4 高可用设计Harness 无状态 Session Store 多活Harness 本身是无状态的所以水平扩展很简单加机器、起进程、挂负载均衡。真正的难点在 Session Store。我们采用Redis Cluster ClickHouse 双写所有 session state如current_step,last_tool_result写入 Redis Cluster主从分片所有 event log 同时写入 ClickHouse用于审计、debug、BIHarness 读 state 时优先走 Redis毫秒级fallback 到 ClickHouse秒级仅 debug 用。Redis Cluster 配置要点开启cluster-enabled yes每个 shard 配 1 主 2 从3 节点client 用redis-py-cluster自动路由设置maxmemory-policy allkeys-lru避免 OOM。压测数据Redis Cluster 6 节点3shard×2replica支撑 12000 sessions/secP99 延迟 8ms。4.5 监控告警盯住这五个黄金指标没有监控的 agent 系统等于裸奔。我们 dashboard 固定显示五大指标指标计算方式告警阈值说明Session Success Rate1 - (failed_sessions / total_sessions) 99.5%衡量整体健康度低于此值立即告警Avg Tool Call LatencySUM(tool_duration_ms) / COUNT(tool_calls) 2500ms工具响应慢可能外部依赖故障Context Overflow RateCOUNT(session WHERE context_tokens 0.8 * model_max) 0.1%上下文即将溢出需优化摘要逻辑Sandbox Crash RateCOUNT(sandbox_crash) / COUNT(tool_calls) 0.05%沙箱不稳定检查镜像或 gVisor 配置Vault Token Fail RateCOUNT(vault_auth_fail) / COUNT(tool_calls) 0.01%Vault 服务异常或权限配置错误告警全部接入 PagerDuty且每个告警附带直达日志链接如点击“Sandbox Crash Rate 高”跳转到SELECT * FROM agent_events WHERE event_type sandbox_crash ORDER BY timestamp DESC LIMIT 10。5. 避坑指南那些文档里不会写的血泪教训5.1 工具调用的“三次握手”陷阱你以为 tool call 就是发个 HTTP 请求错。真实世界要处理三次握手Model 说“我要调用 A”LLM 输出中包含tool_use nameAHarness 解析并执行 A调用外部服务Harness 把 A 的结果喂回 Model作为tool_response。问题出在第 2 步和第 3 步之间。我们曾遇到CRM 接口返回 200但 body 是{ error: rate_limit_exceeded }。Harness 如果不校验 body直接把整个 JSON 当作成功结果喂回去Model 就会基于错误数据继续推理最终生成荒谬结论。解决方案所有 tool client 必须实现parse_response()方法且该方法必须返回(is_success: bool, result: dict, error_msg: str)三元组。Harness 只有收到is_successTrue才进入第 3 步否则直接返回error_msg给用户。# crm_client.py def parse_response(self, raw_response: Response) - tuple[bool, dict, str]: if raw_response.status_code ! 200: return False, {}, fCRM API returned {raw_response.status_code} try: data raw_response.json() if data.get(error): return False, {}, fCRM error: {data[error]} return True, data, except Exception as e: return False, {}, fJSON parse failed: {e}5.2 模型输出的“幻觉防火墙”LLM 会编造 tool name、参数、甚至整个 JSON 结构。我们线上曾捕获到模型输出{ name: send_email_to_ceo, input: { to: ceocompany.com, subject: Urgent: System Down, body: All servers are offline. Please call me. } }而我们的 tool list 里根本没有send_email_to_ceo只有send_notification。如果 harness 不做校验就会报错崩溃。我们的防火墙规则Tool Name 白名单harness 启动时加载 agent YAML 中定义的 tools 列表任何不在列表中的 name 直接拒绝Input Schema 校验用jsonschema.validate()强校验 input 字段类型、必填项、格式如 emailOutput Filter 插件在 model output 返回前运行正则匹配如r\b[A-Z]{2,}\b检测全大写单词可能是编造的 tool name。这套组合拳让 tool call 解析失败率从 12% 降到 0.3%。5.3 会话迁移的“断点续传”难题客户提需求“如果 agent 正在执行用户切到手机 App 继续聊会话要无缝衔接。” 这要求 session state 必须支持跨设备、跨客户端同步。我们方案state store client-side session ID 透传。Web 端session_id存 localStorage每次请求带X-Session-IDheaderMobile App同样存session_id请求带相同 headerHarness忽略 client 类型只认X-Session-ID从 store 加载 state关键点state store 必须支持乐观锁Optimistic Locking。我们用 Redis 的WATCHMULTI实现def update_session_state(session_id: str, new_state: dict): pipe redis.pipeline() pipe.watch(fsession:{session_id}) current_ver int(redis.get(fsession:{session_id}:ver) or 0) pipe.multi() pipe.hset(fsession:{session_id}, mappingnew_state) pipe.set(fsession:{session_id}:ver, current_ver 1) try: pipe.execute() except WatchError: raise SessionConflictError(Concurrent update detected)这样即使两个客户端同时更新同一 session也只会有一个成功另一个重试。5.4 沙箱镜像的“确定性构建”Dockerfile 里写RUN pip install -r requirements.txt是大忌。今天构建的镜像明天可能因 PyPI 包更新而行为突变。我们的确定性构建流程pip-compile requirements.in生成requirements.txt含 pinned 版本Dockerfile 中COPY requirements.txt .RUN pip install -r requirements.txt镜像 tag 用sha256sum requirements.txt生成如req-abc123CI/CD 流水线自动打 tag 并 push。这样quay.io/our-org/pdf-generator:req-abc123永远指向同一组依赖行为绝对可复现。5.5 审计日志的“法律级留存”当 agent 生成合同、医疗报告、金融建议时event log 就是法律证据。我们按 GDPR 和 SOC2 要求设计所有 event 写入 ClickHouse 前先经 Kafka topicagent-events-rawKafka retention 设为 90 天合规最低要求ClickHouse 表启用TTL timestamp INTERVAL 90 DAY每条 event 加密存储payload字段用 AES-256-GCM 加密key 存 HashiCorp Vault且 key 本身有 30 天自动轮换策略审计查询必须通过专用 gatewayaudit-apigateway 记录所有查询者、时间、SQL日志存 S3 加密桶。这套设计让我们通过了某银行客户的尽职调查他们特别抽查了 100 条历史 event全部能还原原始 payload 且时间戳精准到毫秒。6. 未来半年你在哪一层赚钱决定了你能活多久回到原文那个犀利判断“The piece of the stack that gets bid down toward zero is the piece they just shipped.” —— runtime 层正在归零。这不是预测是正在发生的事实。我们看一组数据AWS AgentCoreQ1 2026 新增客户中73% 是从自建方案迁移而来迁移主因是“运维成本太高”Azure AI Foundry免费额度覆盖 95% 的中小客户月用量5000 sessions/month开源方案 Daytona2025 年 12 月发布 v1.0GitHub Star 从 0 到 12,000 仅用 47 天其核心卖点就是“docker run -p 8000:8000 daytona/agent-runtime一行启动”。这意味着什么意味着如果你的 startup 商业模式是“卖更便宜/更快/更安全的 sandbox”那你已经在倒计时。真正的机会在 runtime 之上的三层6.1 Trace Store谁掌握事件日志谁就掌握 agent 的“黑匣子”Braintrust 的 Brainstore 为什么值 $150M因为它解决了最痛的痛点trace portability。客户问我们最多的问题是“如果明年换掉 Anthropic用 Azure 的 runtime我现在的 200 万条 event log 怎么迁过去” 答案是没法迁因为格式不兼容。Brainstore 的方案是定义统一 schemaOpenTelemetry 兼容所有 runtimeAnthropic/AWS/Azure/Daytona只要输出符合此 schema 的 event就能被 Brainstore 摄取。它不卖 runtime它卖“日志的通用语言”。我们自己的做法在 harness 里内置 Brainstore exporter所有 event 自动双写到 ClickHouse 和 Brainstore。这样无论 runtime 怎么换审计能力永不丢失。6.2 Governance Policy企业采购的“准入门票”AWS 在 March GA 的 AgentCore Policy Controls本质是给企业 IT 部门发的“控制权”。政策包括deny_tool_call_if_no_approval调用 finance-related tool 前必须有审批流require_mfa_for_sensitive_actions生成合同 PDF 必须二次认证block_output_containing_pii自动检测并屏蔽输出中的身份证号、银行卡号。这些不是技术功能是采购决策的门槛。没有 Policy Engine你的 agent 系统进不了银行、保险、医疗客户的生产环境。我们开源了 Policy Engine 框架agent-guardian支持 YAML 定义策略实时生效。客户可以自己写# policies/bank-compliance.yaml - name: block-ssn-output condition: output contains regex \\b\\d{3}-\\d{2}-\\d{4}\\b action: mask_output - name: require-approval-for-wire-transfer condition: tool_name initiate_wire_transfer action: require_approval_flow6.3 Vertical Agent Marketplace卖“能解决问题的 agent”不卖“能跑 agent 的平台”Salesforce Agentforce $800M ARR 的启示是什么企业不为“runtime”付费为“解决销售线索转化问题”付费。我们正在做的垂直 agentHealthcare Claims Agent对接医保局 API自动填写 27 个字段的报销单准确率 99.2%经三甲医院实测Sales Dev Agent从 LinkedIn 抓取目标客户信息生成个性化 cold email打开率 41%行业平均 22%Security Pentest Agent调用 Burp Suite API Nmap生成漏洞报告附修复建议。每个 agent 都打包成独立 SaaS 产品按 seat/year 收费。runtime我们用 AWS AgentCore成本摊到每个 seat 不到 $0.5/月。这才是钱流向的地方。当你还在争论“我的 sandbox 启动比 Anthropic 快 120ms”时别人已经靠 Healthcare Claims Agent 拿下 37 家三甲医院的 PO。最后说句实在的Anthropic 的 Managed Agents 是一剂良药治的是“不想碰 infra”的症状。但它不是解药。真正的解药是你得清醒地知道——runtime 层的战争已经结束胜者是云厂商和开源社区而下一城在 trace、policy、vertical 的高地上正等着你插旗。