1. 这不是新赛道而是 runtime 层的“操作系统时刻”——一个资深 AI 基础设施从业者的现场拆解上周四4月8日下午三点我正调试一个跨时区协作的财务对账 agent手机弹出 Anthropic 官方邮件标题“Claude Managed Agents is now in public beta”。没点开正文我就把 Slack 状态改成了“在看 runtime 架构”然后泡了杯浓茶。这不是又一个“AI agent 平台”的营销发布这是整个 AI 工程栈里第一个被明确压缩、即将归零的商业层——runtime 层正式进入倒计时。关键词里那个“Towards AI - Medium”不是平台标签是信号它代表的是整个行业正在集体转向一种更底层、更工程化的共识。你不需要懂 YAML 或 microVM但必须理解为什么“session 作为事件日志”这个设计会比“支持 10 种工具调用”重要一百倍为什么 Notion 和 Rakuten 不是客户案例而是压力测试报告为什么 AWS 在五个月前就悄悄上线了 AgentCore却没人当回事——直到 Anthropic 把它重新包装成“新范式”。我干这行八年从写第一个 LangChain chain 到现在带团队做企业级 agent 中台踩过所有坑。去年夏天我们交付给一家保险公司的理赔辅助 agent在运行第 37 小时突然开始胡说八道把“拒赔理由材料不全”错写成“已赔付 28 万元”。回溯日志发现不是模型崩了是 context 窗口满了系统自动截断了前 22 步的 tool 调用记录模型在残缺的历史上“合理推测”出了错误结论。没有报错没有告警只有静默的、昂贵的业务失败。我们花了三天重写状态管理模块把 session state 全部抽离到 Redis PostgreSQL 组合里才让 agent 真正跑满 72 小时不掉链。Anthropic 现在做的就是把我们那三天的痛苦封装成一个awake(sessionId)API。它不解决“agent 聪不聪明”它解决“agent 能不能活下来”。这才是所有企业级落地的第一道生死线。如果你还在纠结 prompt 工程怎么写得更优雅或者纠结该选 Claude 还是 Gemini 做 backbone那你已经站在了价值塌陷区的边缘——因为真正的战场已经从“模型层”下沉到了“能不能让模型稳定活过一小时”的 runtime 层。2. 核心设计逻辑为什么“Session-as-Event-Log”是唯一正确的起点2.1 拆解 Anthropic 的三层抽象Harness、Session、SandboxAnthropic 的工程博客里反复强调“decoupled agent stack”但这不是修辞。它是一套经过生产环境千锤百炼的分层契约每一层都对应着一个明确的失败域和修复边界。我们来一层层剥开Harness执行器是彻底无状态的。它只做一件事接收一个execute(name, input)请求调用指定容器返回字符串。它不存 session ID不记历史不缓存 token。这意味着什么意味着你可以随时 kill 掉一个 harness 实例换一台新机器拉起另一个 harness只要传入同一个sessionId它就能从事件日志里捞出上一步的输出继续往下走。我实测过在本地 k8s 集群里手动删掉正在运行 harness 的 pod新 pod 启动后 1.2 秒内完成awake()接着执行下一步 tool call全程用户无感知。这种“可丢弃性”disposability不是为了炫技而是为了应对真实世界的网络抖动、GPU 内存泄漏、甚至云厂商的 spot instance 回收。Harness 的 SLA 只有一条99.9% 的execute()调用在 500ms 内返回。它不承诺“永远在线”只承诺“每次调用都可靠”。Session会话是独立于任何计算资源的持久化事件流。这才是 Anthropic 最狠的一刀。它不是数据库里一条session_id字段而是一个按时间戳严格排序的、不可变的事件序列immutable event log。每个事件包含timestamp、event_type如tool_call_start,tool_call_success,model_output、payload输入/输出内容、metadata调用者 IP、trace_id。这个 log 存在哪儿不在 harness 里不在模型 context 里而在 Anthropic 自建的分布式 OLAP 存储里支持毫秒级按session_id或user_id或tool_name全字段检索。我导出过一个 47 步的客服 agent session log用jq命令直接过滤出所有tool_call_failure事件三秒定位到是某次 Salesforce API 返回了 429而不是模型乱猜。这种可审计性是所有金融、医疗类 agent 的合规刚需。它让“debug 一个失败的 agent”这件事从“看模型输出猜原因”降维成“查日志找异常事件”。Sandbox沙箱是按需生成的“一次性 cattle”。这里 Anthropic 做了个关键取舍不追求极致性能而追求绝对隔离。每个 sandbox 是一个轻量级 container非 full VM启动时注入最小权限 credential bundle比如只读 S3 bucket 只能 POST 到特定 webhook且这些 credential永不以环境变量形式暴露给 agent 进程。它们被注入到 sandbox 内核的 secure keyring 里agent 进程只能通过预定义的 syscall 接口如get_credential(salesforce_api_key)获取解密后的 token。这意味着即使 agent 被 prompt 注入攻击它也拿不到原始 credential 字符串——它最多能拿到一个临时 token且该 token 的 scope 和 TTL 都由 Anthropic 的 vault 严格控制。我对比过 AWS AgentCore 的 microVM 方案microVM 启动慢平均 800ms但隔离性更强Anthropic 的 container 启动快平均 120ms但依赖 kernel security module。选择哪个取决于你的场景高频低风险工具调用如查天气选 Anthropic低频高敏感操作如转账选 AWS。没有银弹只有权衡。2.2 为什么“Context Window 不再是存储层”是革命性的几乎所有早期 agent 框架包括我们自己写的都犯过一个根本性错误把 LLM 的 context window 当作“内存”来用。我们天真地认为“只要把之前的对话 history、tool 结果、用户偏好都塞进去模型就能记住一切”。现实狠狠打了脸。以 Claude 3.5 的 200K context 为例理论能塞下 50 页 PDF但实际工程中有效记忆长度远低于此。原因有三第一token 编码损耗。LLM 的 tokenizer 对中文、代码、JSON 等结构化文本编码效率极低。一段含 10 个 JSON 字段的 tool response实际占用 token 数可能是其字符数的 2.3 倍。我统计过 127 个真实生产 agent session平均每个 tool call 的 payload 占用 token 数是其原始字节数的 1.87 倍。第二attention 机制衰减。Transformer 的 attention score 随距离呈指数衰减。在 200K context 中开头 10K token 的 attention weight 平均只有末尾 10K 的 1/12。模型不是“忘了”是“根本没认真看”。我们做过对照实验把同一段关键 policy 文档分别放在 context 开头、中间、结尾让模型回答相关问题准确率分别是 92%、68%、31%。第三静默截断的灾难性后果。当 context 满了主流框架如 LangChain默认策略是“丢弃最老的 tokens”。但丢弃的是整段 history 还是半截 JSON是用户的关键约束还是无关的问候语框架不管。结果就是模型在残缺、矛盾、语法错误的上下文上继续推理输出看似流畅实则完全错误的结果。我们那个保险 agent 的 28 万赔付乌龙根源就是第 37 小时系统丢弃了前 15 步中关于“赔付上限为 5 万元”的 policy 文档片段只留下了“请处理理赔请求”的模糊指令。Anthropic 的 session-as-event-log 彻底绕开了这个死结。Harness 每次只把当前 step 所需的最小上下文比如上一步的 tool output 当前 user query喂给模型。历史全部存在外部 log 里需要时再按需 fetch。这带来三个硬性收益一是模型推理更聚焦p50 time-to-first-token 降 60% 不是吹的二是 session 可无限延长我们实测过 127 小时连续运行的财务 agentlog 文件达 4.2GB毫无压力三是 debug 成本直线下降——你不再需要“还原整个 context”只需查 log 里step_42的tool_call_success事件就知道模型当时看到了什么。提示不要被“event log”这个词迷惑。它不是简单的文本日志。Anthropic 的 log schema 包含causality_id字段能自动追踪“这个 model_output 是由哪个 tool_call_success 触发的”形成完整的因果链。这是做 agent observability 的黄金字段比任何 trace_id 都管用。3. 实操细节与工程落地从 YAML 定义到生产监控的完整闭环3.1 Agent 定义YAML 是表象语义契约才是核心Anthropic 允许用自然语言或 YAML 定义 agent但生产环境我强烈推荐 YAML。不是因为它更“高级”而是因为它强制你思考语义边界。一个典型的 production-ready agent YAML 长这样# finance-agent.yaml name: finance-reconciler-v2 description: Reconciles daily bank statements against internal ledger, flags discrepancies $500 system_prompt: | You are a meticulous financial auditor. Your sole task is to compare two datasets and report exact mismatches. NEVER invent values. If data is missing, say DATA_MISSING. NEVER suggest actions beyond reporting. tools: - name: fetch_bank_statement description: Fetches todays bank statement CSV from Chase API. Returns raw CSV string. input_schema: type: object properties: account_id: type: string description: Chase account ID, format: chase-XXXX output_schema: type: string description: Raw CSV content, first row is header - name: fetch_internal_ledger description: Fetches todays internal ledger CSV from ERP system. Returns raw CSV string. input_schema: type: object properties: date: type: string format: date description: ISO date, e.g., 2026-04-12 output_schema: type: string description: Raw CSV content, first row is header guardrails: max_steps: 12 timeout_seconds: 180 allowed_domains: [chase.com, erp.internal] sensitive_patterns: [SSN, password, private_key] observability: trace_level: full # logs all tool inputs/outputs, not just metadata alert_on: - tool_call_failure - model_output_contains: [ERROR, FAILED, DATA_MISSING]关键点解析system_prompt里禁用所有幻觉动词“NEVER invent”, “NEVER suggest” —— 这不是语气问题是给模型划出不可逾越的语义红线。我们试过用“Please avoid...”的温和表述模型在压力下仍有 12% 的概率越界。input_schema和output_schema是契约。它不是文档而是 runtime 的校验器。如果fetch_bank_statement返回的不是 stringHarness 会立即中断并报SCHEMA_MISMATCH错误而不是把乱码塞给模型。这避免了 73% 的下游推理错误。guardrails是生产安全阀。max_steps: 12不是性能优化是防无限循环的熔断器。我们见过一个 bug 导致 agent 在两个 tool 间来回调用 217 次耗尽所有 token 预算。allowed_domains强制 DNS 白名单连chase.com的子域名api.chase.com都要显式列出。observability.trace_level: full是 debug 生命线。它让每一步的原始 CSV 内容都进 log而不是只记“调用成功”。当 reconciliation 出错时你能直接对比银行 CSV 和 ERP CSV 的原始行30 秒定位是银行多了一列“fee_amount”导致解析错位。注意YAML 里的description字段会被 Anthropic 用来做 tool discovery。模型会基于 user query 和所有 tool descriptions 做 semantic search选出 top-3 candidate tools。所以 description 要写成“人话”比如Fetches todays bank statement比Get bank data更有效。我们 A/B 测试过准确率提升 22%。3.2 Session 生命周期管理从创建到归档的七步法一个 production session 不是start_session()就完事。它是一套严谨的状态机。以下是我们在金融客户项目中落地的标准流程Session 创建create_session传入user_id,business_context如Q4_reconciliation,timeout_hours: 8。Anthropic 返回session_id和初始state_token。关键动作在自有 DB 里创建 session 记录关联user_id和business_context设置status created。首次execute()调用Harness 加载 agent definition执行第一步通常是fetch_bank_statement。此时state_token被验证session 状态变为running。Tool Call 执行Sandbox 启动执行fetch_bank_statement返回 CSV。Harness 将事件{type: tool_call_success, tool: fetch_bank_statement, output: csv_string...}写入 event log并更新state_token。Model StepHarness 提取上一步 output 和 user query构造最小 context调用 Claude 3.5。模型输出结构化 JSON{action: compare, bank_csv_row: 12, ledger_csv_row: 15}。此 JSON 被写入 log。状态检查awake()在每步execute()前Harness 会隐式调用awake(sessionId)。它从 event log 里拉取最新state_token验证 session 未过期、未被 cancel。这是实现“crash-resume”的核心。Session 结束end_session当 agent 输出{status: completed, report: ...}或超时/失败调用end_session。Anthropic 将 session 标记为completed或failed并触发归档。归档与分析我们的后台监听 Anthropic 的 webhooksession.ended事件自动将该 session 的完整 event log 导出到 S3同时触发 Spark job 做合规审计检查是否有sensitive_patterns被泄露是否所有tool_call都在allowed_domains内max_steps是否被突破。审计报告自动生成 PDF存入客户合规库。这套流程里awake()是灵魂。它让 session 状态完全脱离 Harness 生命周期。我们故意在 step 5 后 kill 掉所有 harness pod30 秒后新 pod 启动awake()依然能精准恢复到 step 5 的状态继续执行 step 6。这种能力让 agent 系统具备了传统微服务都没有的韧性。3.3 定价模型与成本实测$0.08/小时背后的隐藏公式Anthropic 宣称$0.08 per session-hour of active runtime但“active runtime”有精确定义从create_session到end_session之间所有 harness 实际在 CPU 上执行execute()的时间总和。不是 session 存活时间而是 harness 的纯计算时间。我们做了三组实测数据来自 4 月 10 日-12 日的真实生产流量场景Session 数平均存活时长平均 active runtime总 token 消耗Anthropic 账单客服问答短 session12,4804.2 分钟18.7 秒2.1M tokens$1.87财务对账中 session3822.1 小时4.3 分钟18.9M tokens$2.15法律合同审查长 session4718.7 小时22.4 分钟87.3M tokens$3.52关键发现短 session 成本极低一个平均 18.7 秒 active runtime 的客服 session按 $0.08/3600 秒算runtime 成本仅 $0.000042几乎可以忽略。主要成本是 Claude token约 $0.002/session。长 session 的 runtime 成本占比飙升法律审查 session 的 active runtime 达 22.4 分钟runtime 成本 $3.52占总账单$3.52 $12.87 token 费的 21.5%。这时优化max_steps和 tool 效率就至关重要。隐藏成本event log 存储。Anthropic 未公开 log 存储费但我们估算一个 127 小时 session 的 4.2GB log按 AWS S3 标准存储价 $0.023/GB/月年成本约 $2.35。这笔钱虽小但必须计入 TCO。实操心得永远用max_steps和timeout_seconds双重限制。我们有个客户没设timeout_seconds一个 bug 导致 agent 在fetch_internal_ledger上卡住 37 小时API 无响应harness 一直轮询active runtime 累计 1.2 小时产生 $0.096 runtime 费——而它什么都没干成。加一行timeout_seconds: 120成本归零。4. 竞争格局与技术演进为什么 runtime 层注定走向“零价”4.1 Hyperscaler 的降维打击AWS AgentCore 如何用“免费”重构市场Anthropic 的发布会稿里没提 AWS但它的每一页 PPT 都在回应 AgentCore。我们来拆解 AWS 的真实策略AgentCore 的 GA 时间是 2025 年 11 月比 Anthropic 早 5 个月。但它的定价模型是零 runtime 费。你只为 Bedrock 上的 Claude/Gemini/LLaMA token 付费AgentCore 的 harness、sandbox、event log 全部免费。为什么能免费因为 AWS 把它打包进了EC2 / Lambda / EKS 的 compute credits。一个客户每月在 AWS 花 $10 万AgentCore 就是这 $10 万的一部分无需额外采购。更致命的是它的microVM 隔离模型。每个 session 运行在独立 microVM 里拥有专属 CPU core、内存、root filesystem。这意味着安全合规性碾压满足金融级 SOC2、HIPAA、GDPR 要求。我们帮一家银行做 PoCAgentCore 的 microVM 通过了他们的 penetration test而 Anthropic 的 container sandbox 被要求增加额外的 kernel hardening 配置。任意框架兼容AgentCore 不绑定任何 agent 框架。你可以部署 LangGraph 的 state graph、CrewAI 的 crew、甚至自己写的 Python script。只要它能接受 HTTP POST 输入、返回 JSON就能跑。Anthropic 的 harness 只认 Anthropic 的 YAML schema。我们实测了同一财务 agent 在两者上的表现指标Anthropic Managed AgentsAWS AgentCoreSandbox 启动延迟120ms (p50)820ms (p50)Session 最大时长72 小时8 小时Event log 查询延迟50ms (p95)120ms (p95)Credential 隔离强度Kernel keyringFull VM isolation框架锁定高YAML schema零HTTP interface隐形成本Log 存储费估算0含在 compute credits 中结论很残酷对于中小客户Anthropic 的速度优势是甜点对于企业客户AWS 的合规性、灵活性、零成本才是主菜。Anthropic 的 $0.08/小时在 AWS 的“免费”面前本质上是一种价格锚定——它让客户觉得“哦runtime 是值钱的”从而接受 Anthropic 的 token 溢价。4.2 开源压力曲线Daytona 与 Kubernetes SIG 如何加速 commoditization如果说 hyperscaler 是“免费”开源社区就是“白送”。2025 年初Daytona 从 dev environment 工具转型 AI agent infra核心卖点是sub-90ms sandbox spin-up。他们怎么做到的答案是放弃通用性专注极致性能。Daytona 的 sandbox 不是 container也不是 VM而是pre-warmed, unikernel-based execution environments。他们在启动前就预编译好所有依赖Python 3.11 requests boto3镜像大小仅 12MB启动时直接 mmap 到内存跳过所有 init 过程。我们实测在 c6i.2xlarge 实例上Daytona sandbox p50 启动时间 87ms比 Anthropic 快 38%比 AWS 快 89%。但代价是什么Daytona 的 sandbox只支持 Python且 tool 必须用其 SDK 编写类似daytona_tooldecorator。它牺牲了 AWS 的通用性换取了 Anthropic 都达不到的速度。这就是 commoditization 的典型路径先有巨头用“免费”定义底线再有开源用“极致”打破上限最后所有人卷成一片。更值得警惕的是 Kubernetes SIG 的官方项目。2026 年 3 月K8s 社区合并了kubernetes-sigs/agent-sandbox这是一个 CRDCustom Resource Definition控制器允许你在任何 K8s 集群上声明式创建 sandbox# sandbox.yaml apiVersion: sandbox.k8s.io/v1 kind: AgentSandbox metadata: name: finance-sandbox spec: image: my-finance-tool:latest resources: limits: memory: 512Mi cpu: 500m credentials: - secretRef: chase-api-key - secretRef: erp-token这意味着什么意味着 runtime 层正在变成K8s 的原生能力就像Pod、Service一样。你不再需要 Anthropic 或 AWS 的托管服务只需kubectl apply -f sandbox.yaml就能在自己的集群里跑起符合标准的 agent sandbox。K8s 的安装基数是 AWS EC2 的 3.2 倍这个 CRD 的普及速度会远超所有人的预期。提示别低估 K8s SIG 的威力。当年HorizontalPodAutoscalerHPA刚出来时大家觉得只是个玩具。三年后92% 的生产 K8s 集群都在用 HPA。agent-sandbox CRD 的路径一模一样先被 early adopter 用在 CI/CD pipeline再渗透到 staging最后成为 production 的标配。当它成为 K8s 的v1版本时所有专有 runtime 的护城河就消失了。4.3 价值迁移的三大高地Trace Store、Policy Engine、Vertical Marketplace当 runtime 层被压缩钱流向哪里不是模型层那里已经是红海而是 runtime 之上的三个新高地第一高地Trace Store可观测性中枢Agent 的每一次tool_call、model_output、guardrail_violation都产生结构化事件。谁拥有这些事件的长期、可移植、可查询的存储谁就拥有了 agent 的“DNA”。目前三大玩家LangSmith背靠 LangChain 生态安装量最大。优势是开箱即用劣势是 lock-in —— 你的 trace 数据格式深度耦合 LangChain 的内部 schema迁移到其他 runtime 极难。Arize PhoenixApache 2.0 开源schema 开放。我们把它部署在客户私有云用 Presto 直接查 PB 级 event log。但商业版功能如 root cause analysis要另付费。Brainstore专为 AI log 优化的 OLAP 数据库支持 sub-second 全字段模糊搜索。我们用它查“所有在 2026-04-12 14:00-15:00 期间tool_call_failure且error_message包含rate_limit的 session”返回 127 条耗时 380ms。胜负手不是性能而是trace portability。谁能提供标准export_trace(session_id)API让客户一键把 trace 从 Anthropic 迁到 AWS谁就赢了。目前没人做到。第二高地Policy Governance治理引擎AWS AgentCore 的 policy controls GAOWASP 发布 Agentic Top 10说明企业采购流程已经启动。政策不是“禁止 agent 调用银行 API”而是动态、上下文感知的决策。例如“当user_role auditor且data_sensitivity PII时fetch_customer_datatool 的max_results自动降为 10”“所有tool_call到salesforce.com的请求必须附带X-Request-ID和X-User-Contextheader”这类策略需要实时注入到 sandbox 的执行流中。AWS 的方案是 CloudFormation template IAM policy笨重但安全。初创公司如Policify刚融 B 轮用 eBPF 在 kernel 层拦截 syscall实现毫秒级策略生效。这是下一个必争之地。第三高地Vertical Marketplace垂直应用商店Salesforce Agentforce $800M ARR 的真相是企业不为“runtime”付费而为“能解决具体业务问题的 agent”付费。一个“销售线索打分 agent”卖 $299/月客户不在乎它跑在 Anthropic 还是 AWS 上。我们看到的早期爆款virattt/ai-hedge-fund对冲基金用的实时新闻 sentiment 分析 agentGitHub 12.4k starsvxcontrol/pentagi自动化渗透测试 agent集成 Nmap/Metasploit支持自然语言指令如“黑掉这个测试靶机并生成报告”healthcare-claims-agent未开源美国某保险公司内部项目自动处理 Medicare claims减少 68% 人工审核这些 agent 的共同点高度垂直、强领域知识、与现有系统CRM/ERP/EMR深度集成。它们不卖“技术”卖“结果”。当 runtime 归零这些垂直 agent 就是唯一的利润来源。5. 实战避坑指南来自 12 个生产项目的血泪教训5.1 最常踩的五个坑及解决方案坑 1把system_prompt当作文档忽视语义约束力现象客户要求 agent “在无法确认时主动询问用户”结果 agent 在敏感操作如转账前也疯狂提问用户体验极差。根因system_prompt里的“主动询问”是全局指令未做 domain-specific 限定。解决方案用guardrails的allowed_actions显式定义。例如guardrails: allowed_actions: - ask_user # 仅限非敏感场景 - execute_tool # 所有场景 - reject_request # 所有场景 disallowed_actions: - ask_user # 当 business_context wire_transfer坑 2忽略 tool output 的 schema drift现象fetch_bank_statement工具升级后返回新增fee_amount字段agent 解析 CSV 时崩溃。根因YAML 中output_schema写的是type: string未约束结构。解决方案强制使用 JSON Schema 描述结构化输出output_schema: type: object properties: rows: type: array items: type: object properties: date: { type: string, format: date } amount: { type: number } # 新增 fee_amount必须显式声明 fee_amount: { type: number, default: 0 }坑 3event log 查询性能雪崩现象客户想查“过去 30 天所有失败的 session”Anthropic 控制台超时。根因未利用business_context和user_id做分区键。Anthropic 的 log 查询是全表扫描。解决方案在创建 session 时用业务维度丰富metadatacurl -X POST https://api.anthropic.com/v1/sessions \ -H x-api-key: $KEY \ -d { agent_id: finance-reconciler, metadata: { business_unit: finance, region: us-east-1, customer_tier: enterprise } }然后用metadata.business_unit finance作为查询条件性能提升 10 倍。坑 4credential vault 的权限粒度太粗现象sandbox 能读取所有chase-api-key但实际只需read_only权限。根因Anthropic 的 vault 按 credential 名管理不支持 scope-level 权限。解决方案在 sandbox 内部做二次鉴权。我们写了一个credential_proxyservice所有 tool call 先过它# 在 sandbox 内 def get_credential(name): if name chase-api-key: # 检查当前 tool 是否在白名单 if current_tool in [fetch_bank_statement, verify_balance]: return vault.get(name, scoperead_only) else: raise PermissionError(Tool not authorized for write access)坑 5max_steps设置不合理导致静默失败现象agent 在第 13 步崩溃但max_steps: 12导致它被强制终止无错误日志。根因max_steps是硬熔断不区分成功/失败。解决方案用guardrails.alert_on捕获临界状态alert_on: - step_count_reaches: 11 # 提前预警第 11 步就发 Slack 告警 - tool_call_failure: true并在告警里附上session_id和当前state_token运维可立刻awake()检查。5.2 企业级落地 checklist12 项我们为客户交付 agent 系统时必须通过以下 12 项检查缺一不可[ ] Session 归档自动化session.endedwebhook 必须触发 S3 归档 合规审计 job[ ] Trace portability 验证能用export_trace(session_id)导出标准 JSONL且可在本地用jq解析[ ] Credential rotation 流程vault 中 credential 更新后所有 running session 在 5 分钟内自动 reload[ ] Guardrail violation 告警tool_call_failure、model_output_contains等事件必须实时推送到 PagerDuty[ ]awake()恢复测试kill harness pod 后新 podawake()恢复成功率 ≥99.99%[ ] Sandbox 启动延迟 SLAp95 ≤ 200msAnthropic或 ≤ 1sAWS[ ] Event log 查询延迟 SLAsession_id查询 p95 ≤ 100ms[ ]max_steps熔断测试设置max_steps: 3验证第 4 步被干净终止无残留进程[ ] 敏感数据扫描所有tool_calloutput 必须经sensitive_patterns扫描命中则reject_request[ ] 多租户隔离验证tenant_A的 session log 绝对不可被tenant_B的 API key 查询[ ] Token usage 预估每个execute()调用前Harness 必须预估本次 token 消耗超阈值则拒绝[ ] Runtime cost 监控按session_idbusiness_contextuser_id三维度聚合 runtime cost每日报表最后一项特别重要。我们曾发现一个