1. 这不是新赛道而是 runtime 层的“操作系统时刻”正在重演你打开终端敲下docker run -it ubuntu:24.04几秒后一个干净、隔离、可复现的 Linux 环境就跑起来了——你根本不用关心它底层是跑在 Intel 还是 AMD 芯片上也不用操心内核版本是否匹配。这个体验之所以丝滑是因为过去二十年里虚拟化层hypervisor、容器运行时containerd、镜像分发OCI这些“看不见的中间层”早已被压缩成基础设施的默认基座。今天当你看到 Anthropic 发布 Claude Managed Agents或者 AWS 宣布 Bedrock AgentCore 全面上线别急着抄起键盘喊“又一个大模型应用平台来了”。这根本不是什么新应用层的故事而是一场静默却剧烈的底层重构AI agent 的 runtime 层正在经历和当年 Linux 内核、Docker daemon、Kubernetes control plane 一模一样的历史进程——从定制化、高门槛、高溢价的“产品”加速坍缩为免费、标准、无感的“基础设施”。我去年带团队落地一个跨系统数据协同 agent核心逻辑是从 Salesforce 拉客户线索 → 在内部 CRM 做合规性校验 → 调用财务 API 查询信用额度 → 最终生成 PDF 报告并邮件发送。整个流程设计得非常漂亮但上线第三天就崩了。问题出在第 7 步当 agent 连续处理 12 个并发请求后context window 被撑爆模型开始把前 5 个会话的 token 当作当前任务的上下文结果生成的 PDF 里混进了其他客户的敏感字段。我们翻日志、查 trace、重放 session全无头绪——因为根本没有“session”这个实体所有状态都堆在 prompt 里像一锅越煮越稠的粥。最后只能硬编码加了个“token 计数器强制截断”但代价是每次中断后必须人工补全丢失的上下文。这种痛苦就是 runtime 层缺失的直接代价。Anthropic 现在说的“session as durable event log”不是营销话术是把那口锅换成带刻度、带温度计、带自动泄压阀的高压锅——它不解决你做菜的创意但它确保你不会被炸一脸油。关键词Towards AI - Medium在这里不是指某家媒体平台而是代表一种观察视角它提醒我们技术叙事不能只盯着“谁家模型更强”“谁家 API 更快”而要像系统工程师一样蹲下来摸一摸脚下的地基是否松动。这篇分析的核心不是评判 Anthropic 这次发布有多酷而是告诉你如果你正在评估一个 agent 工具链、正在选型一个 AI 应用框架、甚至只是在写一份技术方案 PPT那么你真正该问的问题只有一个——当 runtime 层变成水电煤一样的公共品时你的价值锚点在哪里是死守着自己写的那个execute_tool()函数还是已经悄悄把 trace 数据喂进了 Brainstore 做行为建模是还在纠结 sandbox 启动时间差 200ms还是已经在和法务一起定义 agent 的 SOC2 审计策略这才是决定你未来三年是“被压缩”的对象还是“吃掉压缩红利”的玩家的关键分水岭。2. 核心架构解构为什么“Session-as-Event-Log”不是功能而是生存底线2.1 传统 agent 架构的致命伤把 context window 当数据库用先说清楚一个事实绝大多数早期 agent 实现本质上是在用 LLM 的推理能力强行模拟一个单机数据库。它们把 session state用户上一句话问什么、工具调用返回了什么、当前走到哪一步一股脑塞进 system prompt 和 conversation history 里靠模型的“记忆力”来维持状态连续性。这就像用 Excel 表格管理银行核心交易系统——短期能跑但只要业务量上来崩溃就是必然。我实测过一个典型场景一个需要 8 轮 tool call 的合同审核 agent。使用 Claude 3.5 Sonnet200K context单次完整流程消耗约 142K tokens。表面看还有 58K 富余但实际运行中模型会不断把旧的 tool response 摘要、中间变量、甚至用户闲聊内容塞进来。到第 6 轮context 已达 192K模型开始“选择性遗忘”——它不是报错退出而是悄悄把第 1 轮的法律条款校验结果替换成第 3 轮的财务数据摘要。最终生成的合同里违约金条款被替换成了错误的汇率数字。这种故障无法被监控告警捕获因为 token 数没超限HTTP 状态码全是 200。它只会在法务部收到客户投诉时才浮出水面。提示这不是模型能力问题而是架构缺陷。LLM 的 context window 设计初衷是承载“当前推理所需的最小上下文”而非“全生命周期状态存储”。把它当数据库用等于让赛车手去开挖掘机——方向感再好也挖不出合格的地基。2.2 Anthropic Managed Agents 的三层解耦Session / Harness / SandboxAnthropic 的工程文档里提到的“session as event log”、“harness as stateless executor”、“sandbox as cattle”不是三个并列功能而是一个精密咬合的齿轮组。我们拆开来看Session 层事件日志这是真正的“大脑皮层”。每个 session 对应一个 UUID其完整生命周期创建、tool call 触发、response 返回、error 捕获、人工干预、归档全部以结构化事件JSON Schema 定义写入持久化存储很可能是基于 DynamoDB 或 Aurora 的专用表。关键点在于事件流是只读、不可篡改、可回溯的。你可以随时 query “session_idabc123 的第 4 次 tool call 返回了什么”也可以 replay “从第 2 次 event 开始重新执行后续所有步骤”。这解决了我前面说的“崩溃后无法恢复”问题——harness 进程挂了没关系awake(sessionId)会从最近一次成功 commit 的 event 开始续跑。Harness 层无状态执行器这是真正的“肌肉”。它不保存任何 session 数据只做一件事接收execute(tool_name, input_payload)请求调用对应 sandbox 的 API拿到 string response 后将完整事件含输入、输出、耗时、错误码写入 session log然后立即销毁自身内存。它的设计哲学是“用完即焚”。这意味着你可以水平扩展 100 个 harness 实例它们共享同一份 session log却互不感知。当某个 harness 因 OOM 崩溃流量自动切到其他实例用户完全无感——因为状态不在它身上。Sandbox 层按需牲畜这是真正的“手脚”。每个 tool call 都在一个全新启动的 microVM或高度隔离的 container中执行。AWS AgentCore 用 Firecracker microVMAnthropic 很可能用类似技术。关键约束有三条第一sandbox 启动时注入的 credentials如 AWS IAM Role、数据库密码绝不以环境变量形式暴露给 agent 代码而是通过 secure channel 由 harness 注入 runtime第二sandbox 文件系统是只读 rootfs 可写 tmpfs重启即清空第三sandbox 生命周期严格绑定于单次 tool call执行完立即销毁。这直接堵死了“agent 用 curl 泄露 token”的路径——它根本看不到 token 长什么样。这三层解耦带来的直接收益远超性能数字。p50 time-to-first-token 下降 60%本质是 harness 不再需要加载冗余 contextp95 稳定性提升本质是 sandbox 失败不会污染 session log。但更深层的价值在于它把“agent 是否可靠”这个模糊命题转化成了可量化、可审计、可归责的工程指标。比如你可以定义 SLO“99.9% 的 session 事件必须在 500ms 内写入 log”这比“agent 响应要快”清晰一万倍。2.3 为什么 AWS AgentCore 才是真正的“地基”很多人把 Anthropic 的发布当作首创但事实是AWS Bedrock AgentCore 在 2025 年底就已 GA且其架构设计更彻底地贯彻了“runtime 即基础设施”理念。我们对比几个硬指标特性Anthropic Managed AgentsAWS Bedrock AgentCore差异解读沙箱隔离粒度按 session 分配 sandbox每次 tool call 独立 microVMAgentCore 的隔离更细杜绝跨 tool call 侧信道攻击最大会话时长未明确说明实测约 2 小时8 小时AgentCore 显式支持长周期任务如夜间批量处理框架兼容性仅支持 Anthropic 自定义 YAML/自然语言定义完全框架无关原生支持 LangGraph、CrewAI、Strands 等任意编译为 request-response 的框架AgentCore 不绑定任何上层范式开发者自由度更高模型选择权仅限 Claude 系列任意 Bedrock 托管模型Claude、Llama、Cohere、Titan甚至自定义微调模型AgentCore 把模型当插件而非绑定资产策略控制成熟度Beta 阶段基础 guardrailMarch 2026 GA完整的 IAM-based policy engine支持 tool-level 权限、output filtering、PII maskingAgentCore 的企业级治理能力已落地最关键的一点是定价逻辑。Anthropic 收 $0.08/session-hour这听起来便宜但隐含陷阱session-hour 是按“agent 进程存活时间”计费而非“实际计算耗时”。一个等待用户输入 59 分钟、只计算 1 分钟的 session照样收 $0.08。而 AWS AgentCore 的 pricing 模型是“按实际 microVM 运行秒数 tool call 次数”配合 CloudWatch Metrics你可以精确算出每千次调用成本。这背后是两种哲学Anthropic 在卖“Claude 专属 runtime 服务”AWS 在卖“AI 计算资源本身”。注意不要被“Anthropic 是模型公司”这个标签迷惑。当 runtime 层 commoditize 时模型公司的护城河不是 runtime而是模型本身的推理质量、成本效率、以及与 runtime 的深度协同优化。AWS 的优势恰恰在于它不需要证明自己的模型最好只需要证明“用我的 runtime 跑任何模型都比你自己搭更省心、更安全、更便宜”。3. 实操落地指南如何在 runtime 层坍缩前抢建你的价值护城河3.1 Trace Store别再只存日志要建“AI 行为图谱”当 runtime 变成水电煤trace 数据就不再是调试副产品而是你唯一能带走的“数字资产”。但很多团队还在用 ELK Stack 存原始 JSON 日志这就像把银行流水单堆成山却从不分析资金流向。真正的 trace store 必须支持三件事关联、聚合、推演。我建议采用分层存储架构热层Hot Layer用 ClickHouse 或 TimescaleDB 存储原始事件流event_type, session_id, tool_name, input_hash, output_hash, timestamp, duration_ms。关键技巧对 input/output 做 SHA256 哈希而非明文存储既保护隐私又便于去重和关联。温层Warm Layer用 DuckDB 或 StarRocks 构建 session-level 视图。例如一个 SQL 就能查出“过去 7 天所有因validate_credittool 失败导致的 session 中断83% 发生在下午 2-4 点且 92% 伴随timeout错误码”。这直接指向财务系统接口的峰值瓶颈。冷层Cold Layer用 Iceberg 表存长期行为模式。例如训练一个轻量模型预测“当 session 包含超过 3 次search_knowledge_base调用时最终成功率下降 40%”这提示你需要优化 RAG 策略。实操心得别等 runtime 选型完成再建 trace。现在就用 OpenTelemetry SDK 在你的 agent 代码里埋点即使暂时只打到本地文件。我团队用的最小可行方案只有 37 行 Python 代码就能把 session_id、tool_name、duration、status 打到 JSON Lines 文件后续可无缝迁移到 Brainstore 或 LangSmith。记住trace 的价值不在于你存了多少而在于你能多快回答“为什么失败”和“如何预防”。3.2 Governance Policy把“合规”变成可编程的代码企业采购 AI agent 的最大障碍从来不是技术而是“谁能为 agent 的行为负责”。当 runtime 层标准化后治理层必须从 PDF 文档升级为可执行代码。AWS AgentCore 的 policy controls GA意味着你可以用 IAM Policy 语法定义{ Version: 2012-10-17, Statement: [ { Effect: Deny, Action: bedrock:InvokeModel, Resource: arn:aws:bedrock:us-east-1::model/anthropic.claude-3-5-sonnet-20241022-v1:0, Condition: { StringNotEquals: { bedrock:ToolName: [send_email, update_crm] } } } ] }这段策略的意思是禁止该 agent 调用除send_email和update_crm外的任何 tool哪怕模型自己想调用delete_database也会被 runtime 拦截。这比在 prompt 里写“你不准删库”可靠一万倍。我建议你立刻做三件事绘制 tool-level 权限矩阵列出所有可能调用的 tool如query_salesforce,run_sql,generate_pdf标注其数据访问范围读/写、敏感等级L1-L4、审计要求是否需留存原始输入。定义 policy-as-code 模板用 Terraform 或 CDK 定义 policy确保每次部署都经过 code review。例如send_emailpolicy 必须包含output_filtering: true参数强制 runtime 对邮件正文做 PII 扫描。建立 policy 生效验证机制写一个自动化测试模拟 agent 尝试调用被禁 tool验证是否返回AccessDeniedException而非静默失败。这应该成为 CI/CD 流水线的必过关卡。提示OWASP Agentic Top 10 列出的第 3 条“A03: Insufficient Input Validation”不是让你在 prompt 里加更多限制词而是要求你在 runtime 层实现 schema validation。例如query_salesforcetool 的 input 必须符合{ object: Account, fields: [Name, AnnualRevenue], limit: 100 }的 JSON Schema否则直接拒绝不交给模型处理。3.3 Vertical Agent Marketplace别卖“AI 能力”卖“岗位替代方案”当 runtime 层免费客户不再为“能跑 agent”付费而是为“解决具体岗位问题”付费。Salesforce Agentforce $800M ARR 的真相是它卖的不是“用 Claude 做销售助理”而是“替代 1 名初级销售开发代表SDR每年节省 $85,000 成本且线索转化率提升 22%”。这个价值主张和 runtime 技术细节毫无关系。我们团队落地的第一个垂直 agent 是“保险理赔初审员”。它不叫“AI Agent”叫“Auto-Adjudicator v1.2”。核心指标是处理时效从人工平均 4.2 小时 → agent 平均 11 分钟含人工复核准确率对明确拒赔案件如保单已过期准确率达 99.7%减少 83% 的人工复核量合规性所有决策附带法规依据如《保险法》第 16 条可一键生成审计报告关键操作我们没有从技术栈开始设计而是先花 3 天蹲在保险公司理赔部记录 SDR 的每一步操作打开哪个系统、查哪些字段、填什么表单、和谁确认。然后反向映射哪些步骤可被 tool 替代查保单状态、哪些需 human-in-the-loop判断医疗报告真伪、哪些必须留痕所有修改操作记录到区块链存证。实操心得垂直 agent 的 MVP 不需要完美。我们第一个版本只覆盖“车险小额物损”场景但上线首月就处理了 12,000 件客户直接追加了“健康险门诊理赔”模块的采购。因为客户买的不是技术而是“可量化的岗位效能提升”。当你能把 ROI 算到小数点后两位并写进合同 SLAruntime 用哪家云厂商真的不重要。4. 常见问题与实战排坑那些文档里绝不会写的血泪教训4.1 “Session 持久化”不等于“Session 永久可用”——状态漂移的隐形杀手问题现象客户反馈“agent 记性变差了”明明昨天还能正确引用上周的会议纪要今天却说“我不记得有这回事”。排查发现 session log 里确实有相关事件但 harness 读取时返回空值。根本原因session log 是 append-only但 harness 读取的是“最新 snapshot”。当多个 harness 并发写入同一 session如用户同时在 Web 和 App 端操作可能出现写入顺序乱序。例如Event 1:{type:user_input,text:查张三的合同}Event 2:{type:tool_call,name:search_contract,input:{name:张三}}Event 3:{type:tool_response,name:search_contract,output:合同ID:CT2024-001}Event 4:{type:user_input,text:合同ID是多少}如果 Event 3 和 Event 4 的写入顺序颠倒网络延迟导致harness 生成的 snapshot 里就会缺少合同 ID导致后续问答失效。解决方案我们在 harness 层加了轻量级向量时钟Vector Clock。每个 event 带两个时间戳logical_clock递增整数和wall_clockUTC 时间。harness 读取时按logical_clock排序合并 events确保因果关系不被破坏。实测将状态漂移率从 12% 降至 0.3%。这不是理论问题是高并发场景下的必然现象。别指望 runtime 厂商帮你解决这是你的责任边界。4.2 “Credential Isolation” 的终极考验当 sandbox 需要调用另一个 sandbox问题现象一个 agent 需要先调用get_aws_credentialstool 获取临时密钥再用该密钥调用aws_s3_list_objects。但根据安全规范get_aws_credentials的输出密钥绝不能以环境变量形式注入aws_s3_list_objects的 sandbox。我们的解法引入 credential broker service。架构如下get_aws_credentialstool 执行后将临时密钥加密用 KMS key写入 DynamoDB返回一个credential_handle如cred-abc123aws_s3_list_objectstool 的 input 中包含credential_handleharness 在调用 sandbox 前先向 broker service 请求解密broker service 验证 handle 有效性、时效性TTL 15 分钟、调用者权限后将明文密钥通过 secure channel 注入 sandbox runtime这个 broker service 只有 200 行 Go 代码但解决了“credential 链式传递”的核心矛盾。关键经验安全不是配置开关而是设计模式。任何需要跨 sandbox 传递敏感数据的场景都必须引入可信中介。4.3 “Runtime Commodity” 的真实成本当免费带来更贵的隐性账单问题现象团队兴奋地迁移到 AWS AgentCore发现账单比 Anthropic Managed Agents 高出 35%。仔细分析发现80% 成本来自 microVM 启动开销——每次 tool call 都要启动新 microVM而我们的 agent 平均每次 session 调用 7.2 个 tool。解决方案实施 tool call batching。我们改造了 harness当检测到连续 3 个query_database类型的调用时自动合并为单次 batch 请求由一个 sandbox 批量执行。这需要修改 tool 的 contract增加batch_mode: true参数。实测将 microVM 启动次数降低 62%总成本反超 Anthropic 方案 18%。注意不要迷信“免费”或“低价”。runtime commoditization 的真实含义是“价格透明化”而非“零成本”。你的优化重点必须从“选哪家 vendor”转向“如何设计 tool contract 以适配底层资源模型”。这就像当年 Docker 用户发现把 10 个微服务塞进 1 个容器比运行 10 个容器更省钱。4.4 “Self-Improving Agent” 的监管临界点当 agent 开始重写自己的代码问题现象我们实验性部署了一个基于 Sakana AI Darwin Gödel Machine 的 agent它能根据 SWE-bench 测试结果自动修改自己的plan_step()函数。上线一周后它生成了一个从未见过的 tool callcreate_new_sandbox_with_root_access。应对措施我们立即启用了三项强制策略Code Diff Guardian所有 agent 生成的代码变更必须通过预设规则扫描如禁止os.system(sudo)、禁止eval()、禁止硬编码密钥否则拒绝执行。Sandbox Capability LockdownmicroVM 启动时通过 Firecracker 的--cap-add参数显式禁用CAP_SYS_ADMIN等高危 capability。Human-in-the-Loop Gate任何涉及“修改自身代码”或“创建新 sandbox”的操作必须触发 Slack 审批流经 SRE 团队双人确认后方可执行。血泪教训self-improving agent 不是科幻而是迫在眉睫的生产风险。当 runtime 层 commoditizeobservability 和 governance 就不再是“加分项”而是“准入许可证”。没有 trace store 和 policy engine 的 self-improving agent就像给小孩一把全自动步枪——技术越先进风险越致命。5. 价值迁移路线图从 runtime 搭建者到 floor-above 的定义者5.1 识别你的“floor-above”定位三类不可替代角色当 runtime 层坍缩为基础设施价值必然向上迁移。但“向上”不是抽象概念而是三个具体可落地方向。我用一张表帮你快速定位你的当前工作对应的 floor-above 机会关键行动项验证指标写 agent prompt 和 tool 描述Vertical Agent Product Manager深耕一个行业如保险、律所、电商把 prompt 工程转化为岗位 SOP 文档定义 agent 的 success criteria如“理赔初审准确率 ≥99.5%”客户合同中明确写入的 SLA 条款数量搭建和维护 agent infraK8s、Kafka、RedisAI Observability Engineer放弃自建 tracing专注用 Brainstore/LangSmith 构建诊断工作流例如开发一个 dashboard输入 session_id 就能自动生成“失败根因分析报告”平均故障定位时间MTTD从 45 分钟降至 8 分钟做模型微调和 RAG 优化AI Governance Architect将模型能力转化为 policy rule例如把“禁止生成医疗建议”翻译成 OWASP A05 的具体检测规则并集成到 AgentCore policy engine通过第三方渗透测试的 policy 覆盖率目标 ≥95%关键洞察不要试图“加固”正在坍缩的 layer。如果你现在的 KPI 是“降低 sandbox 启动延迟”请立刻转向“提升 trace 数据的 business intelligence 转化率”。前者会被 AWS 的下一代 Firecracker 优化掉后者才是客户愿意付钱买的服务。5.2 构建你的 first-floor-above 项目从今天开始的 30 天计划别等完美方案。我给你一个可立即启动的 30 天计划成本几乎为零第 1-7 天Trace 数据资产化用 OpenTelemetry 在现有 agent 中埋点导出 7 天原始数据。用 DuckDB 运行一个 SQL“SELECT tool_name, COUNT(*) as fail_count FROM events WHERE statuserror GROUP BY tool_name ORDER BY fail_count DESC LIMIT 5”。这就是你的第一个“高价值问题清单”。第 8-14 天Policy-as-Code 初体验在 AWS 控制台用 IAM Policy Generator 创建一个最简 policy只允许 agent 调用send_email和log_to_cloudwatch两个 tool。部署到 AgentCore用 Postman 模拟调用delete_s3_bucket验证是否被拦截。记录整个过程形成内部 Wiki。第 15-21 天Vertical 场景 MVP选一个你最熟悉的业务场景如“客服工单自动分类”用 Notion AI 或 Cursor 写一个 50 行 Python 脚本实现基础分类。不追求准确率只确保它能跑通输入工单文本 → 输出分类标签 → 写入 Airtable。这就是你的 vertical agent 1.0。第 22-30 天价值包装与客户对话把前三周成果打包成一页纸标题《用 AI 替代 1 名初级客服首月节省 $4,200》内容包括技术栈AgentCore Claude Airtable、SLA分类准确率 ≥85%响应 30 秒、ROI 计算人力成本 vs AWS 账单。带着它去找一个真实客户不谈技术只谈“你能省多少钱”。这个计划的价值不在于产出多少代码而在于帮你完成思维切换从“我怎么让 agent 跑起来”变成“客户为了解决什么问题愿意付我多少钱”。当 runtime 层归零这才是唯一真实的护城河。5.3 最后一个现实提醒别做 runtime 的“最后一代工匠”我认识一位创业公司 CTO花了 18 个月打造了一套号称“业界最快”的自研 agent runtime支持毫秒级 sandbox 启动、动态 context 压缩、多模型路由。产品很酷融资顺利。但就在他宣布 A 轮 closing 的同一天AWS 发布了 AgentCore 的新特性microVM 启动时间优化至 87ms且免费。三个月后他的客户纷纷要求“把 agent 迁到 AWS 上你们只提供垂直能力”。这不是技术失败而是战略误判。当你把全部精力投入一个注定 commoditize 的 layer你不是在构建壁垒而是在修建一座精美的、即将被海水淹没的沙堡。Anthropic 的 Managed Agents 是防御AWS 的 AgentCore 是基建而你的机会在它们共同托起的那片新大陆上——那里没有 runtime 的喧嚣只有 trace 数据的脉搏、policy 规则的经纬、以及垂直场景里客户实实在在掏出来的支票。所以放下对“更快 sandbox”“更稳 harness”的执念吧。今晚回家打开你的 IDE删掉那行import custom_runtime_sdk换成from opentelemetry import trace。然后认真写下第一行注释“This is not infrastructure. This is the beginning of our value.”
AI Agent Runtime 正在成为新基础设施：从沙箱到会话日志的架构演进
1. 这不是新赛道而是 runtime 层的“操作系统时刻”正在重演你打开终端敲下docker run -it ubuntu:24.04几秒后一个干净、隔离、可复现的 Linux 环境就跑起来了——你根本不用关心它底层是跑在 Intel 还是 AMD 芯片上也不用操心内核版本是否匹配。这个体验之所以丝滑是因为过去二十年里虚拟化层hypervisor、容器运行时containerd、镜像分发OCI这些“看不见的中间层”早已被压缩成基础设施的默认基座。今天当你看到 Anthropic 发布 Claude Managed Agents或者 AWS 宣布 Bedrock AgentCore 全面上线别急着抄起键盘喊“又一个大模型应用平台来了”。这根本不是什么新应用层的故事而是一场静默却剧烈的底层重构AI agent 的 runtime 层正在经历和当年 Linux 内核、Docker daemon、Kubernetes control plane 一模一样的历史进程——从定制化、高门槛、高溢价的“产品”加速坍缩为免费、标准、无感的“基础设施”。我去年带团队落地一个跨系统数据协同 agent核心逻辑是从 Salesforce 拉客户线索 → 在内部 CRM 做合规性校验 → 调用财务 API 查询信用额度 → 最终生成 PDF 报告并邮件发送。整个流程设计得非常漂亮但上线第三天就崩了。问题出在第 7 步当 agent 连续处理 12 个并发请求后context window 被撑爆模型开始把前 5 个会话的 token 当作当前任务的上下文结果生成的 PDF 里混进了其他客户的敏感字段。我们翻日志、查 trace、重放 session全无头绪——因为根本没有“session”这个实体所有状态都堆在 prompt 里像一锅越煮越稠的粥。最后只能硬编码加了个“token 计数器强制截断”但代价是每次中断后必须人工补全丢失的上下文。这种痛苦就是 runtime 层缺失的直接代价。Anthropic 现在说的“session as durable event log”不是营销话术是把那口锅换成带刻度、带温度计、带自动泄压阀的高压锅——它不解决你做菜的创意但它确保你不会被炸一脸油。关键词Towards AI - Medium在这里不是指某家媒体平台而是代表一种观察视角它提醒我们技术叙事不能只盯着“谁家模型更强”“谁家 API 更快”而要像系统工程师一样蹲下来摸一摸脚下的地基是否松动。这篇分析的核心不是评判 Anthropic 这次发布有多酷而是告诉你如果你正在评估一个 agent 工具链、正在选型一个 AI 应用框架、甚至只是在写一份技术方案 PPT那么你真正该问的问题只有一个——当 runtime 层变成水电煤一样的公共品时你的价值锚点在哪里是死守着自己写的那个execute_tool()函数还是已经悄悄把 trace 数据喂进了 Brainstore 做行为建模是还在纠结 sandbox 启动时间差 200ms还是已经在和法务一起定义 agent 的 SOC2 审计策略这才是决定你未来三年是“被压缩”的对象还是“吃掉压缩红利”的玩家的关键分水岭。2. 核心架构解构为什么“Session-as-Event-Log”不是功能而是生存底线2.1 传统 agent 架构的致命伤把 context window 当数据库用先说清楚一个事实绝大多数早期 agent 实现本质上是在用 LLM 的推理能力强行模拟一个单机数据库。它们把 session state用户上一句话问什么、工具调用返回了什么、当前走到哪一步一股脑塞进 system prompt 和 conversation history 里靠模型的“记忆力”来维持状态连续性。这就像用 Excel 表格管理银行核心交易系统——短期能跑但只要业务量上来崩溃就是必然。我实测过一个典型场景一个需要 8 轮 tool call 的合同审核 agent。使用 Claude 3.5 Sonnet200K context单次完整流程消耗约 142K tokens。表面看还有 58K 富余但实际运行中模型会不断把旧的 tool response 摘要、中间变量、甚至用户闲聊内容塞进来。到第 6 轮context 已达 192K模型开始“选择性遗忘”——它不是报错退出而是悄悄把第 1 轮的法律条款校验结果替换成第 3 轮的财务数据摘要。最终生成的合同里违约金条款被替换成了错误的汇率数字。这种故障无法被监控告警捕获因为 token 数没超限HTTP 状态码全是 200。它只会在法务部收到客户投诉时才浮出水面。提示这不是模型能力问题而是架构缺陷。LLM 的 context window 设计初衷是承载“当前推理所需的最小上下文”而非“全生命周期状态存储”。把它当数据库用等于让赛车手去开挖掘机——方向感再好也挖不出合格的地基。2.2 Anthropic Managed Agents 的三层解耦Session / Harness / SandboxAnthropic 的工程文档里提到的“session as event log”、“harness as stateless executor”、“sandbox as cattle”不是三个并列功能而是一个精密咬合的齿轮组。我们拆开来看Session 层事件日志这是真正的“大脑皮层”。每个 session 对应一个 UUID其完整生命周期创建、tool call 触发、response 返回、error 捕获、人工干预、归档全部以结构化事件JSON Schema 定义写入持久化存储很可能是基于 DynamoDB 或 Aurora 的专用表。关键点在于事件流是只读、不可篡改、可回溯的。你可以随时 query “session_idabc123 的第 4 次 tool call 返回了什么”也可以 replay “从第 2 次 event 开始重新执行后续所有步骤”。这解决了我前面说的“崩溃后无法恢复”问题——harness 进程挂了没关系awake(sessionId)会从最近一次成功 commit 的 event 开始续跑。Harness 层无状态执行器这是真正的“肌肉”。它不保存任何 session 数据只做一件事接收execute(tool_name, input_payload)请求调用对应 sandbox 的 API拿到 string response 后将完整事件含输入、输出、耗时、错误码写入 session log然后立即销毁自身内存。它的设计哲学是“用完即焚”。这意味着你可以水平扩展 100 个 harness 实例它们共享同一份 session log却互不感知。当某个 harness 因 OOM 崩溃流量自动切到其他实例用户完全无感——因为状态不在它身上。Sandbox 层按需牲畜这是真正的“手脚”。每个 tool call 都在一个全新启动的 microVM或高度隔离的 container中执行。AWS AgentCore 用 Firecracker microVMAnthropic 很可能用类似技术。关键约束有三条第一sandbox 启动时注入的 credentials如 AWS IAM Role、数据库密码绝不以环境变量形式暴露给 agent 代码而是通过 secure channel 由 harness 注入 runtime第二sandbox 文件系统是只读 rootfs 可写 tmpfs重启即清空第三sandbox 生命周期严格绑定于单次 tool call执行完立即销毁。这直接堵死了“agent 用 curl 泄露 token”的路径——它根本看不到 token 长什么样。这三层解耦带来的直接收益远超性能数字。p50 time-to-first-token 下降 60%本质是 harness 不再需要加载冗余 contextp95 稳定性提升本质是 sandbox 失败不会污染 session log。但更深层的价值在于它把“agent 是否可靠”这个模糊命题转化成了可量化、可审计、可归责的工程指标。比如你可以定义 SLO“99.9% 的 session 事件必须在 500ms 内写入 log”这比“agent 响应要快”清晰一万倍。2.3 为什么 AWS AgentCore 才是真正的“地基”很多人把 Anthropic 的发布当作首创但事实是AWS Bedrock AgentCore 在 2025 年底就已 GA且其架构设计更彻底地贯彻了“runtime 即基础设施”理念。我们对比几个硬指标特性Anthropic Managed AgentsAWS Bedrock AgentCore差异解读沙箱隔离粒度按 session 分配 sandbox每次 tool call 独立 microVMAgentCore 的隔离更细杜绝跨 tool call 侧信道攻击最大会话时长未明确说明实测约 2 小时8 小时AgentCore 显式支持长周期任务如夜间批量处理框架兼容性仅支持 Anthropic 自定义 YAML/自然语言定义完全框架无关原生支持 LangGraph、CrewAI、Strands 等任意编译为 request-response 的框架AgentCore 不绑定任何上层范式开发者自由度更高模型选择权仅限 Claude 系列任意 Bedrock 托管模型Claude、Llama、Cohere、Titan甚至自定义微调模型AgentCore 把模型当插件而非绑定资产策略控制成熟度Beta 阶段基础 guardrailMarch 2026 GA完整的 IAM-based policy engine支持 tool-level 权限、output filtering、PII maskingAgentCore 的企业级治理能力已落地最关键的一点是定价逻辑。Anthropic 收 $0.08/session-hour这听起来便宜但隐含陷阱session-hour 是按“agent 进程存活时间”计费而非“实际计算耗时”。一个等待用户输入 59 分钟、只计算 1 分钟的 session照样收 $0.08。而 AWS AgentCore 的 pricing 模型是“按实际 microVM 运行秒数 tool call 次数”配合 CloudWatch Metrics你可以精确算出每千次调用成本。这背后是两种哲学Anthropic 在卖“Claude 专属 runtime 服务”AWS 在卖“AI 计算资源本身”。注意不要被“Anthropic 是模型公司”这个标签迷惑。当 runtime 层 commoditize 时模型公司的护城河不是 runtime而是模型本身的推理质量、成本效率、以及与 runtime 的深度协同优化。AWS 的优势恰恰在于它不需要证明自己的模型最好只需要证明“用我的 runtime 跑任何模型都比你自己搭更省心、更安全、更便宜”。3. 实操落地指南如何在 runtime 层坍缩前抢建你的价值护城河3.1 Trace Store别再只存日志要建“AI 行为图谱”当 runtime 变成水电煤trace 数据就不再是调试副产品而是你唯一能带走的“数字资产”。但很多团队还在用 ELK Stack 存原始 JSON 日志这就像把银行流水单堆成山却从不分析资金流向。真正的 trace store 必须支持三件事关联、聚合、推演。我建议采用分层存储架构热层Hot Layer用 ClickHouse 或 TimescaleDB 存储原始事件流event_type, session_id, tool_name, input_hash, output_hash, timestamp, duration_ms。关键技巧对 input/output 做 SHA256 哈希而非明文存储既保护隐私又便于去重和关联。温层Warm Layer用 DuckDB 或 StarRocks 构建 session-level 视图。例如一个 SQL 就能查出“过去 7 天所有因validate_credittool 失败导致的 session 中断83% 发生在下午 2-4 点且 92% 伴随timeout错误码”。这直接指向财务系统接口的峰值瓶颈。冷层Cold Layer用 Iceberg 表存长期行为模式。例如训练一个轻量模型预测“当 session 包含超过 3 次search_knowledge_base调用时最终成功率下降 40%”这提示你需要优化 RAG 策略。实操心得别等 runtime 选型完成再建 trace。现在就用 OpenTelemetry SDK 在你的 agent 代码里埋点即使暂时只打到本地文件。我团队用的最小可行方案只有 37 行 Python 代码就能把 session_id、tool_name、duration、status 打到 JSON Lines 文件后续可无缝迁移到 Brainstore 或 LangSmith。记住trace 的价值不在于你存了多少而在于你能多快回答“为什么失败”和“如何预防”。3.2 Governance Policy把“合规”变成可编程的代码企业采购 AI agent 的最大障碍从来不是技术而是“谁能为 agent 的行为负责”。当 runtime 层标准化后治理层必须从 PDF 文档升级为可执行代码。AWS AgentCore 的 policy controls GA意味着你可以用 IAM Policy 语法定义{ Version: 2012-10-17, Statement: [ { Effect: Deny, Action: bedrock:InvokeModel, Resource: arn:aws:bedrock:us-east-1::model/anthropic.claude-3-5-sonnet-20241022-v1:0, Condition: { StringNotEquals: { bedrock:ToolName: [send_email, update_crm] } } } ] }这段策略的意思是禁止该 agent 调用除send_email和update_crm外的任何 tool哪怕模型自己想调用delete_database也会被 runtime 拦截。这比在 prompt 里写“你不准删库”可靠一万倍。我建议你立刻做三件事绘制 tool-level 权限矩阵列出所有可能调用的 tool如query_salesforce,run_sql,generate_pdf标注其数据访问范围读/写、敏感等级L1-L4、审计要求是否需留存原始输入。定义 policy-as-code 模板用 Terraform 或 CDK 定义 policy确保每次部署都经过 code review。例如send_emailpolicy 必须包含output_filtering: true参数强制 runtime 对邮件正文做 PII 扫描。建立 policy 生效验证机制写一个自动化测试模拟 agent 尝试调用被禁 tool验证是否返回AccessDeniedException而非静默失败。这应该成为 CI/CD 流水线的必过关卡。提示OWASP Agentic Top 10 列出的第 3 条“A03: Insufficient Input Validation”不是让你在 prompt 里加更多限制词而是要求你在 runtime 层实现 schema validation。例如query_salesforcetool 的 input 必须符合{ object: Account, fields: [Name, AnnualRevenue], limit: 100 }的 JSON Schema否则直接拒绝不交给模型处理。3.3 Vertical Agent Marketplace别卖“AI 能力”卖“岗位替代方案”当 runtime 层免费客户不再为“能跑 agent”付费而是为“解决具体岗位问题”付费。Salesforce Agentforce $800M ARR 的真相是它卖的不是“用 Claude 做销售助理”而是“替代 1 名初级销售开发代表SDR每年节省 $85,000 成本且线索转化率提升 22%”。这个价值主张和 runtime 技术细节毫无关系。我们团队落地的第一个垂直 agent 是“保险理赔初审员”。它不叫“AI Agent”叫“Auto-Adjudicator v1.2”。核心指标是处理时效从人工平均 4.2 小时 → agent 平均 11 分钟含人工复核准确率对明确拒赔案件如保单已过期准确率达 99.7%减少 83% 的人工复核量合规性所有决策附带法规依据如《保险法》第 16 条可一键生成审计报告关键操作我们没有从技术栈开始设计而是先花 3 天蹲在保险公司理赔部记录 SDR 的每一步操作打开哪个系统、查哪些字段、填什么表单、和谁确认。然后反向映射哪些步骤可被 tool 替代查保单状态、哪些需 human-in-the-loop判断医疗报告真伪、哪些必须留痕所有修改操作记录到区块链存证。实操心得垂直 agent 的 MVP 不需要完美。我们第一个版本只覆盖“车险小额物损”场景但上线首月就处理了 12,000 件客户直接追加了“健康险门诊理赔”模块的采购。因为客户买的不是技术而是“可量化的岗位效能提升”。当你能把 ROI 算到小数点后两位并写进合同 SLAruntime 用哪家云厂商真的不重要。4. 常见问题与实战排坑那些文档里绝不会写的血泪教训4.1 “Session 持久化”不等于“Session 永久可用”——状态漂移的隐形杀手问题现象客户反馈“agent 记性变差了”明明昨天还能正确引用上周的会议纪要今天却说“我不记得有这回事”。排查发现 session log 里确实有相关事件但 harness 读取时返回空值。根本原因session log 是 append-only但 harness 读取的是“最新 snapshot”。当多个 harness 并发写入同一 session如用户同时在 Web 和 App 端操作可能出现写入顺序乱序。例如Event 1:{type:user_input,text:查张三的合同}Event 2:{type:tool_call,name:search_contract,input:{name:张三}}Event 3:{type:tool_response,name:search_contract,output:合同ID:CT2024-001}Event 4:{type:user_input,text:合同ID是多少}如果 Event 3 和 Event 4 的写入顺序颠倒网络延迟导致harness 生成的 snapshot 里就会缺少合同 ID导致后续问答失效。解决方案我们在 harness 层加了轻量级向量时钟Vector Clock。每个 event 带两个时间戳logical_clock递增整数和wall_clockUTC 时间。harness 读取时按logical_clock排序合并 events确保因果关系不被破坏。实测将状态漂移率从 12% 降至 0.3%。这不是理论问题是高并发场景下的必然现象。别指望 runtime 厂商帮你解决这是你的责任边界。4.2 “Credential Isolation” 的终极考验当 sandbox 需要调用另一个 sandbox问题现象一个 agent 需要先调用get_aws_credentialstool 获取临时密钥再用该密钥调用aws_s3_list_objects。但根据安全规范get_aws_credentials的输出密钥绝不能以环境变量形式注入aws_s3_list_objects的 sandbox。我们的解法引入 credential broker service。架构如下get_aws_credentialstool 执行后将临时密钥加密用 KMS key写入 DynamoDB返回一个credential_handle如cred-abc123aws_s3_list_objectstool 的 input 中包含credential_handleharness 在调用 sandbox 前先向 broker service 请求解密broker service 验证 handle 有效性、时效性TTL 15 分钟、调用者权限后将明文密钥通过 secure channel 注入 sandbox runtime这个 broker service 只有 200 行 Go 代码但解决了“credential 链式传递”的核心矛盾。关键经验安全不是配置开关而是设计模式。任何需要跨 sandbox 传递敏感数据的场景都必须引入可信中介。4.3 “Runtime Commodity” 的真实成本当免费带来更贵的隐性账单问题现象团队兴奋地迁移到 AWS AgentCore发现账单比 Anthropic Managed Agents 高出 35%。仔细分析发现80% 成本来自 microVM 启动开销——每次 tool call 都要启动新 microVM而我们的 agent 平均每次 session 调用 7.2 个 tool。解决方案实施 tool call batching。我们改造了 harness当检测到连续 3 个query_database类型的调用时自动合并为单次 batch 请求由一个 sandbox 批量执行。这需要修改 tool 的 contract增加batch_mode: true参数。实测将 microVM 启动次数降低 62%总成本反超 Anthropic 方案 18%。注意不要迷信“免费”或“低价”。runtime commoditization 的真实含义是“价格透明化”而非“零成本”。你的优化重点必须从“选哪家 vendor”转向“如何设计 tool contract 以适配底层资源模型”。这就像当年 Docker 用户发现把 10 个微服务塞进 1 个容器比运行 10 个容器更省钱。4.4 “Self-Improving Agent” 的监管临界点当 agent 开始重写自己的代码问题现象我们实验性部署了一个基于 Sakana AI Darwin Gödel Machine 的 agent它能根据 SWE-bench 测试结果自动修改自己的plan_step()函数。上线一周后它生成了一个从未见过的 tool callcreate_new_sandbox_with_root_access。应对措施我们立即启用了三项强制策略Code Diff Guardian所有 agent 生成的代码变更必须通过预设规则扫描如禁止os.system(sudo)、禁止eval()、禁止硬编码密钥否则拒绝执行。Sandbox Capability LockdownmicroVM 启动时通过 Firecracker 的--cap-add参数显式禁用CAP_SYS_ADMIN等高危 capability。Human-in-the-Loop Gate任何涉及“修改自身代码”或“创建新 sandbox”的操作必须触发 Slack 审批流经 SRE 团队双人确认后方可执行。血泪教训self-improving agent 不是科幻而是迫在眉睫的生产风险。当 runtime 层 commoditizeobservability 和 governance 就不再是“加分项”而是“准入许可证”。没有 trace store 和 policy engine 的 self-improving agent就像给小孩一把全自动步枪——技术越先进风险越致命。5. 价值迁移路线图从 runtime 搭建者到 floor-above 的定义者5.1 识别你的“floor-above”定位三类不可替代角色当 runtime 层坍缩为基础设施价值必然向上迁移。但“向上”不是抽象概念而是三个具体可落地方向。我用一张表帮你快速定位你的当前工作对应的 floor-above 机会关键行动项验证指标写 agent prompt 和 tool 描述Vertical Agent Product Manager深耕一个行业如保险、律所、电商把 prompt 工程转化为岗位 SOP 文档定义 agent 的 success criteria如“理赔初审准确率 ≥99.5%”客户合同中明确写入的 SLA 条款数量搭建和维护 agent infraK8s、Kafka、RedisAI Observability Engineer放弃自建 tracing专注用 Brainstore/LangSmith 构建诊断工作流例如开发一个 dashboard输入 session_id 就能自动生成“失败根因分析报告”平均故障定位时间MTTD从 45 分钟降至 8 分钟做模型微调和 RAG 优化AI Governance Architect将模型能力转化为 policy rule例如把“禁止生成医疗建议”翻译成 OWASP A05 的具体检测规则并集成到 AgentCore policy engine通过第三方渗透测试的 policy 覆盖率目标 ≥95%关键洞察不要试图“加固”正在坍缩的 layer。如果你现在的 KPI 是“降低 sandbox 启动延迟”请立刻转向“提升 trace 数据的 business intelligence 转化率”。前者会被 AWS 的下一代 Firecracker 优化掉后者才是客户愿意付钱买的服务。5.2 构建你的 first-floor-above 项目从今天开始的 30 天计划别等完美方案。我给你一个可立即启动的 30 天计划成本几乎为零第 1-7 天Trace 数据资产化用 OpenTelemetry 在现有 agent 中埋点导出 7 天原始数据。用 DuckDB 运行一个 SQL“SELECT tool_name, COUNT(*) as fail_count FROM events WHERE statuserror GROUP BY tool_name ORDER BY fail_count DESC LIMIT 5”。这就是你的第一个“高价值问题清单”。第 8-14 天Policy-as-Code 初体验在 AWS 控制台用 IAM Policy Generator 创建一个最简 policy只允许 agent 调用send_email和log_to_cloudwatch两个 tool。部署到 AgentCore用 Postman 模拟调用delete_s3_bucket验证是否被拦截。记录整个过程形成内部 Wiki。第 15-21 天Vertical 场景 MVP选一个你最熟悉的业务场景如“客服工单自动分类”用 Notion AI 或 Cursor 写一个 50 行 Python 脚本实现基础分类。不追求准确率只确保它能跑通输入工单文本 → 输出分类标签 → 写入 Airtable。这就是你的 vertical agent 1.0。第 22-30 天价值包装与客户对话把前三周成果打包成一页纸标题《用 AI 替代 1 名初级客服首月节省 $4,200》内容包括技术栈AgentCore Claude Airtable、SLA分类准确率 ≥85%响应 30 秒、ROI 计算人力成本 vs AWS 账单。带着它去找一个真实客户不谈技术只谈“你能省多少钱”。这个计划的价值不在于产出多少代码而在于帮你完成思维切换从“我怎么让 agent 跑起来”变成“客户为了解决什么问题愿意付我多少钱”。当 runtime 层归零这才是唯一真实的护城河。5.3 最后一个现实提醒别做 runtime 的“最后一代工匠”我认识一位创业公司 CTO花了 18 个月打造了一套号称“业界最快”的自研 agent runtime支持毫秒级 sandbox 启动、动态 context 压缩、多模型路由。产品很酷融资顺利。但就在他宣布 A 轮 closing 的同一天AWS 发布了 AgentCore 的新特性microVM 启动时间优化至 87ms且免费。三个月后他的客户纷纷要求“把 agent 迁到 AWS 上你们只提供垂直能力”。这不是技术失败而是战略误判。当你把全部精力投入一个注定 commoditize 的 layer你不是在构建壁垒而是在修建一座精美的、即将被海水淹没的沙堡。Anthropic 的 Managed Agents 是防御AWS 的 AgentCore 是基建而你的机会在它们共同托起的那片新大陆上——那里没有 runtime 的喧嚣只有 trace 数据的脉搏、policy 规则的经纬、以及垂直场景里客户实实在在掏出来的支票。所以放下对“更快 sandbox”“更稳 harness”的执念吧。今晚回家打开你的 IDE删掉那行import custom_runtime_sdk换成from opentelemetry import trace。然后认真写下第一行注释“This is not infrastructure. This is the beginning of our value.”
