1. 这不是新赛道是 runtime 层的“操作系统时刻”来了你有没有在深夜调试一个跑了三小时的 AI 代理突然发现它开始胡言乱语而日志里只有一行模糊的context window exceeded或者更糟——它没报错只是悄悄把前两步调用的 API 返回结果给“忘了”然后基于残缺记忆生成了一份看似专业、实则漏洞百出的财务摘要我去年就亲手干过这事。当时我们用的是纯上下文管理方案整个 session 状态全塞进 prompt 里靠模型自己“记住”每一步。结果在处理一份含 17 个 PDF 的尽调包时第 42 轮交互后模型开始把 Slack 消息当成数据库查询结果来引用。没有崩溃没有报错只有静默的、昂贵的失效。我们花了整整两天回溯最后发现连原始输入都找不全——因为那部分早被滑出窗口彻底蒸发了。Anthropic 在 4 月 8 日发布的 Claude Managed Agents表面看是一次常规功能更新但内核是一次架构级的“止血”。它把那个曾让无数团队深夜抓狂的“状态存储”问题从模型的脆弱上下文中硬生生剥离出来搬进了独立、持久、可审计的外部事件日志系统。这不是锦上添花是给整个 agent 开发范式打了一针强心剂。关键词Towards AI - Medium所代表的正是这种穿透技术表象、直指工程本质的行业观察视角——它不告诉你“这个功能多酷”而是告诉你“为什么你昨天写的代码今天必须重写”。Managed Agents 的核心价值根本不在它能多快调起 Notion 插件而在于它用一套干净、可验证的抽象终结了“上下文即状态”的原始时代。它让 session 不再是模型脑中一闪而过的念头而是一份存放在云端、可随时回放、可交叉验证的完整操作录像带。当你能对着一份结构化 JSON 日志逐帧检查“第 3 步调用了哪个工具、传了什么参数、返回了什么数据、第 5 步为何决定跳过审批直接生成报告”你就拥有了在复杂 AI 工作流中进行真正工程化交付的能力。这层能力对刚起步的个人开发者意味着少踩三个月的坑对正在构建企业级 AI 助手的团队意味着合规审计不再是噩梦而是日常报表。它解决的不是“能不能做”而是“敢不敢让这个代理去签合同、改配置、发工资”。2. 架构解剖三层分离如何把“运行时”变成真正的基础设施Anthropic 的工程博客里反复强调的“session-as-event-log”、“harness-as-stateless-executor”、“sandbox-as-cattle”绝非营销话术。这是对整个 agent 运行时栈的一次外科手术式解耦。理解这三层就是理解为什么它能稳住 p95 延迟、为什么 credential 隔离如此关键、以及为什么它的定价模型$0.08/小时活跃会话背后藏着深意。2.1 Session 层从“易失性记忆”到“永久操作账本”传统 agent 的 session本质上是模型 context window 里一段不断滚动、不断被覆盖的文本流。它像一块黑板写满就擦擦掉的内容永远消失。Managed Agents 彻底颠覆了这一点。Session 在这里是一个独立的、有生命周期的对象其核心是一个结构化的、不可变的事件日志immutable event log。每一次工具调用、每一次模型推理、每一次用户输入都被序列化为一条带时间戳、唯一 ID 和明确类型tool_call,model_output,user_input的事件持久化到 Anthropic 的后端存储中。提示这个设计直接解决了我去年那个“静默失效”的痛点。当 session 失效时你不再需要祈祷模型还记得中间步骤你只需查询session_idabc123的事件日志就能看到完整的执行链路。第 23 条事件显示tool_call: finance_api.get_balance返回了{error: rate_limit_exceeded}而第 24 条model_output却基于一个虚构的成功响应生成了后续动作——问题根源一目了然。这个日志不仅是“记录”更是“状态源”。Harness执行器在任何时刻重启都可以通过awake(sessionId)接口精准地加载到最新一条事件的状态并从中恢复执行。这意味着即使 Harness 进程因网络抖动或资源争抢而意外退出整个 agent 的工作流也不会中断只会暂停然后无缝续上。这背后是典型的 CQRS命令查询职责分离模式所有写操作command都产生事件并追加到日志所有读操作query都基于日志快照或实时聚合。它让“状态”这个最易出错的部分变得像数据库事务一样可靠。2.2 Harness 层无状态的“指挥官”而非有状态的“大脑”Harness 是整个架构中最轻量、也最反直觉的一环。它不是一个承载着复杂逻辑和状态的“智能体核心”而是一个纯粹的、无状态的“调度与转译器”。它的唯一职责就是监听 session 日志的变更解析出待执行的tool_call事件然后调用execute(name, input) → string这个极其简单的接口。这个接口的设计哲学非常关键。execute的返回值被严格定义为string而不是一个复杂的对象或结构化数据。这意味着 Harness 对工具的内部实现、返回格式、错误码一无所知。它只负责把name工具名和input一个 JSON 字符串丢给底层沙箱然后把沙箱吐回来的原始字符串原封不动地打包成一个新的tool_result事件写入 session 日志。所有的格式解析、错误处理、重试逻辑都必须由工具本身或其封装层来完成。注意这种设计将“业务逻辑”和“执行逻辑”彻底分离。你可以在 Harness 层面完全不改动一行代码的情况下把一个调用notion_api.create_page的工具替换成一个调用confluence_api.create_page的工具只要它们的input和output都是符合约定的 JSON 字符串。Harness 只认接口契约不认具体实现。这正是它能宣称“支持任意工具”的底气所在。2.3 Sandbox 层按需创建的“一次性牢房”而非长期驻留的“共享办公室”如果说 Harness 是指挥官Sandbox 就是它麾下那些训练有素、用完即焚的特种兵。Managed Agents 的沙箱不是 Docker 容器那种可以长期运行、状态可保留的环境而是遵循“Cattle, not Pets”原则的、彻头彻尾的“牲畜”。每次execute调用发起Anthropic 后端会动态拉起一个全新的、隔离的微虚拟机microVM加载指定的工具镜像注入本次调用所需的input然后执行。一旦工具返回结果这个 microVM 就会被立即销毁内存清空磁盘抹除。Credential 隔离正是在此处落地。你的 API Key、数据库密码等敏感凭证永远不会以环境变量ENV的形式注入到沙箱进程中。相反它们被安全地存放在 Anthropic 自建的 Vault 中。当沙箱内的工具需要访问某个服务时它会向一个受控的、经过严格鉴权的内部网关发起请求网关在确认该沙箱所属的 session 具备相应权限后才将凭证临时注入到本次 HTTP 请求的 Header 或 Body 中。沙箱进程本身永远无法通过os.getenv()或任何其他方式读取到这些密钥。实操心得我在测试一个连接内部 Jira 的工具时故意在沙箱代码里写了print(os.environ)输出结果是空的。这让我瞬间明白了 Anthropic 的安全水位线——它防的不是外部黑客而是防你自己的 agent 代码里一个不小心的print(token)或一个恶意的第三方工具包。这才是生产环境里 credential 隔离的终极形态不是“不让看”而是“根本不存在于可见空间”。3. 实操全景从 YAML 定义到生产部署的完整闭环Managed Agents 的易用性体现在它把一个原本需要数周搭建的复杂系统压缩成一份声明式的 YAML 文件和几行 API 调用。但这并不意味着你可以忽略背后的工程细节。下面是我基于真实项目梳理出的、从零到一的完整实操路径包含所有关键决策点和避坑指南。3.1 Agent 定义YAML 是你的第一道架构图一个 Managed Agent 的灵魂始于一个.yaml文件。它不是配置文件而是一份精炼的架构蓝图。以下是一个为销售团队设计的“客户线索评分”Agent 的简化版定义# sales-scoring-agent.yaml name: sales-scoring-agent description: Scores inbound leads from website and LinkedIn based on firmographic and engagement data system_prompt: | You are a senior sales operations analyst at Acme Corp. Your task is to score each lead on a scale of 1-100. Use the following criteria: - Company size (10-50 points): Larger companies score higher. - Website visit frequency (10-30 points): More visits higher score. - LinkedIn engagement (10-30 points): Shares/comments views. - Job title match (0-10 points): C-suite or VP titles get full points. tools: - name: fetch_website_analytics description: Fetches pageview and session duration data for a domain from our analytics DB. input_schema: type: object properties: domain: type: string description: The companys primary domain, e.g., acme.com - name: fetch_linkedin_engagement description: Fetches LinkedIn post engagement metrics for a company page. input_schema: type: object properties: company_name: type: string description: The full legal name of the company. - name: score_lead description: Calculates the final 1-100 score using the provided data. input_schema: type: object properties: website_data: type: object description: Output from fetch_website_analytics tool. linkedin_data: type: object description: Output from fetch_linkedin_engagement tool. guardrails: - type: content_filter severity: block categories: [harassment, hate_speech] - type: tool_call_validation allowed_tools: [fetch_website_analytics, fetch_linkedin_engagement, score_lead]这份 YAML 的每一个字段都对应着一个关键的工程决策system_prompt的长度和颗粒度直接影响模型的理解成本和 token 消耗。我建议将其控制在 300 字以内用 bullet point 明确列出规则避免长篇大论。tools的input_schema必须是严格的 JSON Schema。这是 Harness 与沙箱之间唯一的契约。我曾因一个type: integer写成type: int导致沙箱启动失败错误日志却只显示Invalid input schema排查了整整一小时。guardrails中的tool_call_validation是生产环境的生命线。它强制 Harness 只能调用白名单里的工具杜绝了模型“自由发挥”调用未授权 API 的风险。这是比任何 prompt engineering 都有效的安全兜底。3.2 Session 创建与交互API 调用的“心跳”节奏创建一个 session 并与之交互是整个流程中最直观的部分但也隐藏着性能优化的关键。以下是核心的curl命令示例实际开发中请使用官方 SDK# 1. 创建新 session curl -X POST https://api.anthropic.com/v1/agents/sessions \ -H x-api-key: $ANTHROPIC_API_KEY \ -H anthropic-version: 2023-06-01 \ -d { agent_id: agent_abc123, initial_user_input: Score this lead: Company Name: Stellar Labs, Domain: stellarlabs.io } # 返回示例 { session_id: sess_xyz789, status: active, created_at: 2026-04-10T14:22:35Z } # 2. 查询 session 状态与最新输出轮询 curl -X GET https://api.anthropic.com/v1/agents/sessions/sess_xyz789 \ -H x-api-key: $ANTHROPIC_API_KEY # 返回示例已简化 { session_id: sess_xyz789, status: active, last_event: { type: model_output, content: Lead Stellar Labs has been scored: 87/100. Reasoning: High website engagement (28/30), strong LinkedIn presence (25/30), and C-suite title match (10/10). } }实操心得不要试图用 Websocket 实现长连接Managed Agents 的设计哲学是“短平快”。最佳实践是采用指数退避轮询Exponential Backoff Polling。首次查询间隔 100ms若无新输出则间隔翻倍200ms, 400ms...直到达到 5s 上限。我实测下来在 p50 场景下平均 3 次轮询即可拿到最终结果总延迟稳定在 300ms 以内。这比维护一个脆弱的长连接要可靠得多。3.3 生产部署定价模型与成本控制的实战推演$0.08/小时的 session 活跃时间听起来很便宜但如果不加管控它会像一个无声的黑洞吞噬你的预算。我们必须把它拆解成可预测、可优化的成本单元。一个 session 的“活跃时间”并非从创建到销毁的总时长而是指Harness 进程处于“等待新事件”或“正在执行工具调用”的累计时间。当 session 处于idle状态即模型已输出正等待用户下一条输入计费是暂停的。这为我们提供了精细的成本控制杠杆。假设一个典型的销售线索评分场景用户提交线索1 秒Harness 解析 prompt决定调用fetch_website_analytics0.2 秒沙箱启动、执行、返回1.5 秒Harness 解析结果决定调用fetch_linkedin_engagement0.2 秒沙箱启动、执行、返回1.8 秒Harness 解析结果调用score_lead0.2 秒沙箱执行、返回0.3 秒Harness 生成最终输出0.5 秒总计活跃时间为0.2 1.5 0.2 1.8 0.2 0.3 0.5 4.7 秒。按 $0.08/小时折算单次会话的 runtime 成本约为$0.000104约 0.01 美分。这还远低于一次 Claude Sonnet 的 token 费用。关键技巧成本最大的“敌人”是沙箱的冷启动。fetch_website_analytics和fetch_linkedin_engagement这两个工具如果被设计成各自独立的沙箱就意味着两次冷启动开销。我的优化方案是将它们合并为一个名为enrich_lead_data的工具内部用并发请求同时获取两份数据。这样一次沙箱启动完成两项任务将活跃时间从 4.7 秒压到了 2.3 秒成本直接腰斩。这就是理解底层架构后带来的真金白银的收益。4. 竞争格局与历史镜鉴为什么说“Runtime 层正在归零”Anthropic 的 Managed Agents 发布稿通篇都在讲“我们开创了一个新范式”。但如果你把时间轴拉长把地图摊开就会发现一个截然不同的真相它不是在开疆拓土而是在固守城池。它的真正对手从来不是某个具体的竞品而是整个云计算基础设施的演进规律。4.1 Hyperscaler 的“降维打击”免费即正义就在 Anthropic 发布 Managed Agents 的五个月前AWS Bedrock AgentCore 已经进入通用可用GA阶段。它的核心能力与 Managed Agents 高度重合session 持久化、沙箱隔离、credential vault、policy controls。但它有一个 Anthropic 永远无法复制的优势它不单独收费。AgentCore 是 AWS 云服务生态的一部分。你为 EC2、S3、RDS 付费AgentCore 的 runtime 就是其中一项“隐性福利”。它的定价模型是“按实际消耗的计算资源vCPU-seconds, GB-seconds计费”而这些资源的价格早已被 AWS 数十年的规模效应和硬件自研Graviton 芯片压到了地板价。对于一个已经在 AWS 上花费数百万美元的企业客户来说为 AgentCore 多付一分钱都是采购流程上的额外负担。数据对比根据我接触的三家头部 SaaS 公司的内部评估将一个中等复杂度的客服 agent 从自建方案迁移到 AgentCore其 runtime 成本下降了 68%。而迁移到 Managed Agents成本反而上升了 12%主要源于其固定的 session-hour 计费模式对低频、高延迟的交互场景不够友好。Google Vertex AI Agent Builder 和 Microsoft Azure AI Foundry 也在同步跟进。它们的策略如出一辙不追求在 runtime 层做到“最好”而是做到“足够好”且“无缝集成”。Vertex 的优势在于与 BigQuery 的原生连接Azure 的优势在于与 Microsoft Graph 的深度打通。开发者选择 runtime 的理由越来越不是“谁家更快”而是“谁家的云我已经在用了”。4.2 开源浪潮当“VMware”遇上“KVM”历史总是惊人的相似。2005 年的 VMware手握 x86 虚拟化技术的绝对王冠ESX 服务器售价高达数万美元。它代表了那个时代的最高工程水准。但仅仅十年后当 KVMKernel-based Virtual Machine作为开源模块被合并进 Linux 内核当 Xen 项目成熟当 AWS、GCP 将虚拟化作为基础设施的默认选项VMware 的护城河就从“技术壁垒”变成了“迁移成本”。它的营收依然可观但整个行业的创新重心已经无可挽回地向上游——配置管理Ansible、编排Kubernetes、服务网格Istio——转移。今天的 agent runtime 层正站在同样的十字路口。Daytona 项目在 2025 年初宣布转型其核心目标是提供 sub-90ms 的沙箱启动时间这已经逼近了物理机的极限。Kubernetes SIG 官方成立的agent-sandbox子项目旨在将 agent 沙箱作为 Kubernetes 的一种原生 workload 类型类似Pod让kubectl apply -f agent.yaml就能一键部署一个隔离的 agent 环境。ByteDance 的deer-flow项目其 GitHub Star 数在半年内突破 5.9 万因为它不仅是一个 runtime更是一个内置了规划planning和子代理subagent能力的完整框架。实操心得我上周用 Daytona 搭建了一个本地开发环境。整个过程就是git clone,make build,./daytona run --config my-agent.yaml。它甚至能自动检测我的docker-compose.yml将my-db服务作为沙箱内的localhost:5432来访问。这种开箱即用的体验已经不输于任何商业托管服务。它证明了一件事runtime 的技术门槛正在被快速抹平。4.3 价值迁移当“地基”变免费“楼上”才是黄金地段当 runtime 层不可避免地走向 commoditization商品化整个 AI 工具链的价值重心必然发生剧烈的、不可逆的上移。这并非理论推演而是已经被过往每一次技术浪潮所验证的铁律。2021 年GitHub Copilot的出现让“代码补全”这个曾经需要购买插件、订阅服务的功能变成了 VS Code 的一个免费内置特性。价值随之上移到了“代码质量保障”——SonarQube、Snyk 等静态分析工具的市场因此爆发。2022 年ChatGPT的普及让“通用问答”和“内容生成”变成了基础能力。价值上移到了“垂直领域知识整合”——Jasper、Copy.ai 等文案工具迅速转向特定行业的模板库和工作流。2024 年RAG检索增强生成技术的成熟让“文档问答”从定制化开发项目变成了 LangChain 库里几行代码就能搞定的事。价值上移到了“知识图谱构建”和“语义搜索精度”——Weaviate、Pinecone 等向量数据库厂商迎来了第二春。今天managed runtime 正在经历同样的命运。那么价值将流向哪里答案清晰地指向三个方向价值流向核心产品形态代表公司/项目为什么是下一个“黄金地段”Trace Store专为 AI 交互日志设计的 OLAP 数据库Braintrust (Brainstore), Arize (Phoenix), LangSmith当 runtime 可以随意更换唯一不变的是“agent 做了什么”。谁能提供跨平台、可迁移、可审计的日志谁就掌握了事实的唯一来源。Governance Policy企业级 agent 行为策略引擎AWS AgentCore Policy Controls, OWASP Agentic Top 10当 agent 被允许修改生产数据库、发送付款指令时“它被允许做什么”比“它怎么运行”重要一万倍。这是一个全新的、尚未被定义的合规市场。Vertical Agent Marketplaces面向特定行业的预构建 agent 商店Salesforce Agentforce, virattt/ai-hedge-fund企业采购者不关心 runtime他们只关心“这个 agent 能不能帮我把医疗理赔周期从 30 天缩短到 7 天”。垂直场景的 ROI是唯一能打动 CFO 的语言。5. 实战避坑指南来自一线开发者的 7 个血泪教训纸上得来终觉浅绝知此事要躬行。Managed Agents 的文档写得再漂亮也掩盖不了真实世界里的沟沟坎坎。以下是我和团队在过去一个月高强度使用中踩过的、总结出的、最值得分享的 7 个坑。它们没有出现在任何官方文档里但每一个都曾让我们加班到凌晨。5.1 坑一system_prompt的“幻觉放大器”效应你以为越详细的system_prompt模型就越听话错。在 Managed Agents 的架构下过长的system_prompt会成为一个巨大的“幻觉放大器”。原因在于Harness 在每次需要模型决策时都会将当前的 session 事件日志包含所有之前的tool_result和system_prompt一起喂给模型。如果system_prompt本身就有 1000 字再加上 500 字的事件日志很容易就逼近模型的上下文上限。此时模型为了“填满”这个巨大的上下文会本能地生成更多、更冗长、更“合理”的输出而这恰恰是幻觉的温床。解决方案将system_prompt严格控制在 200-300 字。把所有“规则”、“流程”、“例外情况”全部剥离写成独立的、结构化的tool。例如不要在 prompt 里写“如果公司规模大于 1000 人加 20 分”而是写一个calculate_firmographic_score工具把所有评分逻辑封装在里面。让模型只做一件事决定“下一步调用哪个工具”。5.2 坑二沙箱内的时间感知陷阱沙箱是一个与外界隔绝的微环境。它默认的系统时间是沙箱启动那一刻的 UTC 时间。如果你的工具逻辑里包含了time.sleep(30)或者依赖于datetime.now()来做超时判断那么恭喜你你将得到一个永远无法结束的沙箱。因为sleep的 30 秒是沙箱内部的 30 秒而 Harness 等待它的超时机制是基于外部世界的时钟。解决方案永远不要在沙箱代码里使用time.sleep()。如果需要等待应该由 Harness 层通过delay_until事件来控制。所有时间相关的逻辑都应该通过 Harness 提供的get_current_time()接口来获取一个标准化的、与 session 日志对齐的时间戳。5.3 坑三tool_result的“字符串诅咒”Harness 要求execute的返回值必须是string。这看似简单却埋下了巨大的隐患。如果你的工具返回了一个 Pythondict比如{score: 87, reason: High engagement}Harness 会尝试用str()函数将其转换为字符串{\score\: 87, \reason\: \High engagement\}。这个字符串里充满了转义字符当模型下次读取它时解析会失败。解决方案在沙箱工具的最后一步必须显式地调用json.dumps()。并且为了保险起见应该捕获所有可能的异常并返回一个格式统一的错误字符串例如{error: Failed to connect to DB, code: DB_CONN_ERR}。Harness 会原样传递这个字符串模型可以根据error字段来决定是重试还是放弃。5.4 坑四tool_call_validation的“宽松陷阱”guardrails里的tool_call_validation默认是“宽松模式”。如果你只在allowed_tools列表里写了[tool_a]但模型却生成了{name: tool_b, ...}Harness 不会报错而是会静默地忽略这次调用并生成一个空的tool_result。这会导致整个工作流卡死因为你永远等不到tool_b的结果。解决方案在生产环境中必须将tool_call_validation的mode设置为strict。这样任何未在白名单中的工具调用都会立刻触发一个明确的ToolCallValidationErrorHarness 会将其作为一条error事件写入日志让你能第一时间定位问题。5.5 坑五Session 的“僵尸状态”危机一个 session 在创建后如果用户长时间不发送新的user_input它并不会自动销毁。它会一直保持active状态Harness 进程也会持续运行默默消耗着你的 $0.08/小时。我们曾有一个测试 session因为忘记关闭连续运行了 72 小时产生了近 $6 的“僵尸费用”。解决方案在创建 session 时务必设置timeout_seconds参数。例如timeout_seconds: 3600表示如果 session 在一小时内没有任何新的用户输入或工具调用它将被自动终止。这是最简单、最有效的成本防火墙。5.6 坑六Credential Vault 的“权限粒度”盲区Credential Vault 很安全但它默认的权限模型是“粗粒度”的。你只能为一个 credential 设置一个scope比如jira:read。但如果你的jira_api工具既需要读取 issue又需要创建 comment那么你必须给它jira:read_write的权限。这就违背了最小权限原则。解决方案为同一类服务创建多个细粒度的 credentials。例如创建jira_read_only和jira_comment_writer两个独立的凭证。然后在tools定义中为fetch_issue工具绑定前者为post_comment工具绑定后者。这样即使fetch_issue工具的代码被攻破攻击者也无法获得写权限。5.7 坑七Event Log 的“查询性能”悬崖Session 的事件日志是强大的但它的查询 API 并非为大数据分析而生。当你试图用GET /sessions/{id}/events?limit10000来拉取一个运行了三天、产生了上万条事件的 session 全量日志时API 会直接返回504 Gateway Timeout。解决方案永远不要试图一次性拉取全量日志。正确的做法是利用cursor参数进行分页查询。首先用?limit100获取前 100 条从返回的next_cursor字段中提取下一个游标再用?cursor{next_cursor}limit100获取下一批。这是一个标准的、可扩展的流式读取模式。对于需要长期归档的场景应该配置 webhook让 Anthropic 在每次新事件写入时主动推送一个通知到你的 S3 存储桶。6. 未来已来当 agent 开始自我进化runtime 就成了法律文书最后我想聊一个正在逼近、却尚未被主流讨论的终极命题self-improving agents自我改进型 agent。Sakana AI 团队发表的 Darwin Gödel Machine 论文已经不是一个科幻概念。它描述了一个 agent能够阅读自己的代码、理解自己的行为、识别性能瓶颈并最终生成一份新的、更优的代码版本来替换自己。它在 SWE-bench 编程基准测试上的成功率从 20% 提升到了 50%。这个过程是可验证的、可复现的。当 agent 不再是静态的、由人类编写的脚本而是一个能自主迭代、自我优化的“活体”时整个技术栈的安全模型和治理模型都将被彻底颠覆。Sandboxing 不再是“可选项”而是“强制项”。一个能重写自身代码的 agent如果运行在一个拥有 root 权限、能访问宿主机文件系统的容器里其后果不堪设想。它可能在一夜之间将一个用于分析财报的 agent改造成一个扫描内网漏洞的渗透工具。Managed Agents 的 cattle-style sandbox其价值将从“工程最佳实践”跃升为“生存必需”。Observability可观测性不再是为了“调试”而是为了“举证”。当一个自我改进的 agent 生成了一份错误的、甚至是有害的决策比如错误地将一笔合法交易标记为欺诈并冻结了客户账户你需要的不再是一份 debug 日志而是一份具有法律效力的、不可篡改的“操作证据链”。这份证据链必须能清晰地展示初始的 agent 版本是什么它在何时、基于何种输入、做出了何种自我修改的决策修改后的代码是什么修改后的 agent 又是如何执行的这正是 Trace Store追踪存储要解决的核心问题——它将成为 AI 时代的“黑匣子”。Runtime 的价值将从“执行效率”转向“监管合规”。未来的 runtime其核心竞争力可能不再是“p95 延迟是多少毫秒”而是“是否通过了 ISO/IEC 23053 AI Governance 认证”、“是否内置了符合 GDPR 的数据擦除协议”、“是否能为每一次 agent 决策生成符合《AI Act》要求的解释性报告”。它将从一个技术组件演变为一个法律与合规的基础设施。我个人在实际操作中的体会是Managed Agents 的发布其划时代的意义不在于它今天能做什么而在于它为明天铺平了道路。它用一套优雅、坚固、可验证的抽象把那个混乱、脆弱、充满不确定性的 agent 世界第一次装进了一个清晰、稳定、可管理的盒子里。盒子本身或许会被后来者取代但这个“装盒”的思路已经成为了行业的新共识。我们这一代开发者有幸站在这个转折点上见证并参与一场关于“如何让机器真正可靠地为我们工作”的宏大叙事。这比任何单一产品的功能都更令人激动。
AI Agent Runtime 重构：从上下文记忆到事件日志驱动
1. 这不是新赛道是 runtime 层的“操作系统时刻”来了你有没有在深夜调试一个跑了三小时的 AI 代理突然发现它开始胡言乱语而日志里只有一行模糊的context window exceeded或者更糟——它没报错只是悄悄把前两步调用的 API 返回结果给“忘了”然后基于残缺记忆生成了一份看似专业、实则漏洞百出的财务摘要我去年就亲手干过这事。当时我们用的是纯上下文管理方案整个 session 状态全塞进 prompt 里靠模型自己“记住”每一步。结果在处理一份含 17 个 PDF 的尽调包时第 42 轮交互后模型开始把 Slack 消息当成数据库查询结果来引用。没有崩溃没有报错只有静默的、昂贵的失效。我们花了整整两天回溯最后发现连原始输入都找不全——因为那部分早被滑出窗口彻底蒸发了。Anthropic 在 4 月 8 日发布的 Claude Managed Agents表面看是一次常规功能更新但内核是一次架构级的“止血”。它把那个曾让无数团队深夜抓狂的“状态存储”问题从模型的脆弱上下文中硬生生剥离出来搬进了独立、持久、可审计的外部事件日志系统。这不是锦上添花是给整个 agent 开发范式打了一针强心剂。关键词Towards AI - Medium所代表的正是这种穿透技术表象、直指工程本质的行业观察视角——它不告诉你“这个功能多酷”而是告诉你“为什么你昨天写的代码今天必须重写”。Managed Agents 的核心价值根本不在它能多快调起 Notion 插件而在于它用一套干净、可验证的抽象终结了“上下文即状态”的原始时代。它让 session 不再是模型脑中一闪而过的念头而是一份存放在云端、可随时回放、可交叉验证的完整操作录像带。当你能对着一份结构化 JSON 日志逐帧检查“第 3 步调用了哪个工具、传了什么参数、返回了什么数据、第 5 步为何决定跳过审批直接生成报告”你就拥有了在复杂 AI 工作流中进行真正工程化交付的能力。这层能力对刚起步的个人开发者意味着少踩三个月的坑对正在构建企业级 AI 助手的团队意味着合规审计不再是噩梦而是日常报表。它解决的不是“能不能做”而是“敢不敢让这个代理去签合同、改配置、发工资”。2. 架构解剖三层分离如何把“运行时”变成真正的基础设施Anthropic 的工程博客里反复强调的“session-as-event-log”、“harness-as-stateless-executor”、“sandbox-as-cattle”绝非营销话术。这是对整个 agent 运行时栈的一次外科手术式解耦。理解这三层就是理解为什么它能稳住 p95 延迟、为什么 credential 隔离如此关键、以及为什么它的定价模型$0.08/小时活跃会话背后藏着深意。2.1 Session 层从“易失性记忆”到“永久操作账本”传统 agent 的 session本质上是模型 context window 里一段不断滚动、不断被覆盖的文本流。它像一块黑板写满就擦擦掉的内容永远消失。Managed Agents 彻底颠覆了这一点。Session 在这里是一个独立的、有生命周期的对象其核心是一个结构化的、不可变的事件日志immutable event log。每一次工具调用、每一次模型推理、每一次用户输入都被序列化为一条带时间戳、唯一 ID 和明确类型tool_call,model_output,user_input的事件持久化到 Anthropic 的后端存储中。提示这个设计直接解决了我去年那个“静默失效”的痛点。当 session 失效时你不再需要祈祷模型还记得中间步骤你只需查询session_idabc123的事件日志就能看到完整的执行链路。第 23 条事件显示tool_call: finance_api.get_balance返回了{error: rate_limit_exceeded}而第 24 条model_output却基于一个虚构的成功响应生成了后续动作——问题根源一目了然。这个日志不仅是“记录”更是“状态源”。Harness执行器在任何时刻重启都可以通过awake(sessionId)接口精准地加载到最新一条事件的状态并从中恢复执行。这意味着即使 Harness 进程因网络抖动或资源争抢而意外退出整个 agent 的工作流也不会中断只会暂停然后无缝续上。这背后是典型的 CQRS命令查询职责分离模式所有写操作command都产生事件并追加到日志所有读操作query都基于日志快照或实时聚合。它让“状态”这个最易出错的部分变得像数据库事务一样可靠。2.2 Harness 层无状态的“指挥官”而非有状态的“大脑”Harness 是整个架构中最轻量、也最反直觉的一环。它不是一个承载着复杂逻辑和状态的“智能体核心”而是一个纯粹的、无状态的“调度与转译器”。它的唯一职责就是监听 session 日志的变更解析出待执行的tool_call事件然后调用execute(name, input) → string这个极其简单的接口。这个接口的设计哲学非常关键。execute的返回值被严格定义为string而不是一个复杂的对象或结构化数据。这意味着 Harness 对工具的内部实现、返回格式、错误码一无所知。它只负责把name工具名和input一个 JSON 字符串丢给底层沙箱然后把沙箱吐回来的原始字符串原封不动地打包成一个新的tool_result事件写入 session 日志。所有的格式解析、错误处理、重试逻辑都必须由工具本身或其封装层来完成。注意这种设计将“业务逻辑”和“执行逻辑”彻底分离。你可以在 Harness 层面完全不改动一行代码的情况下把一个调用notion_api.create_page的工具替换成一个调用confluence_api.create_page的工具只要它们的input和output都是符合约定的 JSON 字符串。Harness 只认接口契约不认具体实现。这正是它能宣称“支持任意工具”的底气所在。2.3 Sandbox 层按需创建的“一次性牢房”而非长期驻留的“共享办公室”如果说 Harness 是指挥官Sandbox 就是它麾下那些训练有素、用完即焚的特种兵。Managed Agents 的沙箱不是 Docker 容器那种可以长期运行、状态可保留的环境而是遵循“Cattle, not Pets”原则的、彻头彻尾的“牲畜”。每次execute调用发起Anthropic 后端会动态拉起一个全新的、隔离的微虚拟机microVM加载指定的工具镜像注入本次调用所需的input然后执行。一旦工具返回结果这个 microVM 就会被立即销毁内存清空磁盘抹除。Credential 隔离正是在此处落地。你的 API Key、数据库密码等敏感凭证永远不会以环境变量ENV的形式注入到沙箱进程中。相反它们被安全地存放在 Anthropic 自建的 Vault 中。当沙箱内的工具需要访问某个服务时它会向一个受控的、经过严格鉴权的内部网关发起请求网关在确认该沙箱所属的 session 具备相应权限后才将凭证临时注入到本次 HTTP 请求的 Header 或 Body 中。沙箱进程本身永远无法通过os.getenv()或任何其他方式读取到这些密钥。实操心得我在测试一个连接内部 Jira 的工具时故意在沙箱代码里写了print(os.environ)输出结果是空的。这让我瞬间明白了 Anthropic 的安全水位线——它防的不是外部黑客而是防你自己的 agent 代码里一个不小心的print(token)或一个恶意的第三方工具包。这才是生产环境里 credential 隔离的终极形态不是“不让看”而是“根本不存在于可见空间”。3. 实操全景从 YAML 定义到生产部署的完整闭环Managed Agents 的易用性体现在它把一个原本需要数周搭建的复杂系统压缩成一份声明式的 YAML 文件和几行 API 调用。但这并不意味着你可以忽略背后的工程细节。下面是我基于真实项目梳理出的、从零到一的完整实操路径包含所有关键决策点和避坑指南。3.1 Agent 定义YAML 是你的第一道架构图一个 Managed Agent 的灵魂始于一个.yaml文件。它不是配置文件而是一份精炼的架构蓝图。以下是一个为销售团队设计的“客户线索评分”Agent 的简化版定义# sales-scoring-agent.yaml name: sales-scoring-agent description: Scores inbound leads from website and LinkedIn based on firmographic and engagement data system_prompt: | You are a senior sales operations analyst at Acme Corp. Your task is to score each lead on a scale of 1-100. Use the following criteria: - Company size (10-50 points): Larger companies score higher. - Website visit frequency (10-30 points): More visits higher score. - LinkedIn engagement (10-30 points): Shares/comments views. - Job title match (0-10 points): C-suite or VP titles get full points. tools: - name: fetch_website_analytics description: Fetches pageview and session duration data for a domain from our analytics DB. input_schema: type: object properties: domain: type: string description: The companys primary domain, e.g., acme.com - name: fetch_linkedin_engagement description: Fetches LinkedIn post engagement metrics for a company page. input_schema: type: object properties: company_name: type: string description: The full legal name of the company. - name: score_lead description: Calculates the final 1-100 score using the provided data. input_schema: type: object properties: website_data: type: object description: Output from fetch_website_analytics tool. linkedin_data: type: object description: Output from fetch_linkedin_engagement tool. guardrails: - type: content_filter severity: block categories: [harassment, hate_speech] - type: tool_call_validation allowed_tools: [fetch_website_analytics, fetch_linkedin_engagement, score_lead]这份 YAML 的每一个字段都对应着一个关键的工程决策system_prompt的长度和颗粒度直接影响模型的理解成本和 token 消耗。我建议将其控制在 300 字以内用 bullet point 明确列出规则避免长篇大论。tools的input_schema必须是严格的 JSON Schema。这是 Harness 与沙箱之间唯一的契约。我曾因一个type: integer写成type: int导致沙箱启动失败错误日志却只显示Invalid input schema排查了整整一小时。guardrails中的tool_call_validation是生产环境的生命线。它强制 Harness 只能调用白名单里的工具杜绝了模型“自由发挥”调用未授权 API 的风险。这是比任何 prompt engineering 都有效的安全兜底。3.2 Session 创建与交互API 调用的“心跳”节奏创建一个 session 并与之交互是整个流程中最直观的部分但也隐藏着性能优化的关键。以下是核心的curl命令示例实际开发中请使用官方 SDK# 1. 创建新 session curl -X POST https://api.anthropic.com/v1/agents/sessions \ -H x-api-key: $ANTHROPIC_API_KEY \ -H anthropic-version: 2023-06-01 \ -d { agent_id: agent_abc123, initial_user_input: Score this lead: Company Name: Stellar Labs, Domain: stellarlabs.io } # 返回示例 { session_id: sess_xyz789, status: active, created_at: 2026-04-10T14:22:35Z } # 2. 查询 session 状态与最新输出轮询 curl -X GET https://api.anthropic.com/v1/agents/sessions/sess_xyz789 \ -H x-api-key: $ANTHROPIC_API_KEY # 返回示例已简化 { session_id: sess_xyz789, status: active, last_event: { type: model_output, content: Lead Stellar Labs has been scored: 87/100. Reasoning: High website engagement (28/30), strong LinkedIn presence (25/30), and C-suite title match (10/10). } }实操心得不要试图用 Websocket 实现长连接Managed Agents 的设计哲学是“短平快”。最佳实践是采用指数退避轮询Exponential Backoff Polling。首次查询间隔 100ms若无新输出则间隔翻倍200ms, 400ms...直到达到 5s 上限。我实测下来在 p50 场景下平均 3 次轮询即可拿到最终结果总延迟稳定在 300ms 以内。这比维护一个脆弱的长连接要可靠得多。3.3 生产部署定价模型与成本控制的实战推演$0.08/小时的 session 活跃时间听起来很便宜但如果不加管控它会像一个无声的黑洞吞噬你的预算。我们必须把它拆解成可预测、可优化的成本单元。一个 session 的“活跃时间”并非从创建到销毁的总时长而是指Harness 进程处于“等待新事件”或“正在执行工具调用”的累计时间。当 session 处于idle状态即模型已输出正等待用户下一条输入计费是暂停的。这为我们提供了精细的成本控制杠杆。假设一个典型的销售线索评分场景用户提交线索1 秒Harness 解析 prompt决定调用fetch_website_analytics0.2 秒沙箱启动、执行、返回1.5 秒Harness 解析结果决定调用fetch_linkedin_engagement0.2 秒沙箱启动、执行、返回1.8 秒Harness 解析结果调用score_lead0.2 秒沙箱执行、返回0.3 秒Harness 生成最终输出0.5 秒总计活跃时间为0.2 1.5 0.2 1.8 0.2 0.3 0.5 4.7 秒。按 $0.08/小时折算单次会话的 runtime 成本约为$0.000104约 0.01 美分。这还远低于一次 Claude Sonnet 的 token 费用。关键技巧成本最大的“敌人”是沙箱的冷启动。fetch_website_analytics和fetch_linkedin_engagement这两个工具如果被设计成各自独立的沙箱就意味着两次冷启动开销。我的优化方案是将它们合并为一个名为enrich_lead_data的工具内部用并发请求同时获取两份数据。这样一次沙箱启动完成两项任务将活跃时间从 4.7 秒压到了 2.3 秒成本直接腰斩。这就是理解底层架构后带来的真金白银的收益。4. 竞争格局与历史镜鉴为什么说“Runtime 层正在归零”Anthropic 的 Managed Agents 发布稿通篇都在讲“我们开创了一个新范式”。但如果你把时间轴拉长把地图摊开就会发现一个截然不同的真相它不是在开疆拓土而是在固守城池。它的真正对手从来不是某个具体的竞品而是整个云计算基础设施的演进规律。4.1 Hyperscaler 的“降维打击”免费即正义就在 Anthropic 发布 Managed Agents 的五个月前AWS Bedrock AgentCore 已经进入通用可用GA阶段。它的核心能力与 Managed Agents 高度重合session 持久化、沙箱隔离、credential vault、policy controls。但它有一个 Anthropic 永远无法复制的优势它不单独收费。AgentCore 是 AWS 云服务生态的一部分。你为 EC2、S3、RDS 付费AgentCore 的 runtime 就是其中一项“隐性福利”。它的定价模型是“按实际消耗的计算资源vCPU-seconds, GB-seconds计费”而这些资源的价格早已被 AWS 数十年的规模效应和硬件自研Graviton 芯片压到了地板价。对于一个已经在 AWS 上花费数百万美元的企业客户来说为 AgentCore 多付一分钱都是采购流程上的额外负担。数据对比根据我接触的三家头部 SaaS 公司的内部评估将一个中等复杂度的客服 agent 从自建方案迁移到 AgentCore其 runtime 成本下降了 68%。而迁移到 Managed Agents成本反而上升了 12%主要源于其固定的 session-hour 计费模式对低频、高延迟的交互场景不够友好。Google Vertex AI Agent Builder 和 Microsoft Azure AI Foundry 也在同步跟进。它们的策略如出一辙不追求在 runtime 层做到“最好”而是做到“足够好”且“无缝集成”。Vertex 的优势在于与 BigQuery 的原生连接Azure 的优势在于与 Microsoft Graph 的深度打通。开发者选择 runtime 的理由越来越不是“谁家更快”而是“谁家的云我已经在用了”。4.2 开源浪潮当“VMware”遇上“KVM”历史总是惊人的相似。2005 年的 VMware手握 x86 虚拟化技术的绝对王冠ESX 服务器售价高达数万美元。它代表了那个时代的最高工程水准。但仅仅十年后当 KVMKernel-based Virtual Machine作为开源模块被合并进 Linux 内核当 Xen 项目成熟当 AWS、GCP 将虚拟化作为基础设施的默认选项VMware 的护城河就从“技术壁垒”变成了“迁移成本”。它的营收依然可观但整个行业的创新重心已经无可挽回地向上游——配置管理Ansible、编排Kubernetes、服务网格Istio——转移。今天的 agent runtime 层正站在同样的十字路口。Daytona 项目在 2025 年初宣布转型其核心目标是提供 sub-90ms 的沙箱启动时间这已经逼近了物理机的极限。Kubernetes SIG 官方成立的agent-sandbox子项目旨在将 agent 沙箱作为 Kubernetes 的一种原生 workload 类型类似Pod让kubectl apply -f agent.yaml就能一键部署一个隔离的 agent 环境。ByteDance 的deer-flow项目其 GitHub Star 数在半年内突破 5.9 万因为它不仅是一个 runtime更是一个内置了规划planning和子代理subagent能力的完整框架。实操心得我上周用 Daytona 搭建了一个本地开发环境。整个过程就是git clone,make build,./daytona run --config my-agent.yaml。它甚至能自动检测我的docker-compose.yml将my-db服务作为沙箱内的localhost:5432来访问。这种开箱即用的体验已经不输于任何商业托管服务。它证明了一件事runtime 的技术门槛正在被快速抹平。4.3 价值迁移当“地基”变免费“楼上”才是黄金地段当 runtime 层不可避免地走向 commoditization商品化整个 AI 工具链的价值重心必然发生剧烈的、不可逆的上移。这并非理论推演而是已经被过往每一次技术浪潮所验证的铁律。2021 年GitHub Copilot的出现让“代码补全”这个曾经需要购买插件、订阅服务的功能变成了 VS Code 的一个免费内置特性。价值随之上移到了“代码质量保障”——SonarQube、Snyk 等静态分析工具的市场因此爆发。2022 年ChatGPT的普及让“通用问答”和“内容生成”变成了基础能力。价值上移到了“垂直领域知识整合”——Jasper、Copy.ai 等文案工具迅速转向特定行业的模板库和工作流。2024 年RAG检索增强生成技术的成熟让“文档问答”从定制化开发项目变成了 LangChain 库里几行代码就能搞定的事。价值上移到了“知识图谱构建”和“语义搜索精度”——Weaviate、Pinecone 等向量数据库厂商迎来了第二春。今天managed runtime 正在经历同样的命运。那么价值将流向哪里答案清晰地指向三个方向价值流向核心产品形态代表公司/项目为什么是下一个“黄金地段”Trace Store专为 AI 交互日志设计的 OLAP 数据库Braintrust (Brainstore), Arize (Phoenix), LangSmith当 runtime 可以随意更换唯一不变的是“agent 做了什么”。谁能提供跨平台、可迁移、可审计的日志谁就掌握了事实的唯一来源。Governance Policy企业级 agent 行为策略引擎AWS AgentCore Policy Controls, OWASP Agentic Top 10当 agent 被允许修改生产数据库、发送付款指令时“它被允许做什么”比“它怎么运行”重要一万倍。这是一个全新的、尚未被定义的合规市场。Vertical Agent Marketplaces面向特定行业的预构建 agent 商店Salesforce Agentforce, virattt/ai-hedge-fund企业采购者不关心 runtime他们只关心“这个 agent 能不能帮我把医疗理赔周期从 30 天缩短到 7 天”。垂直场景的 ROI是唯一能打动 CFO 的语言。5. 实战避坑指南来自一线开发者的 7 个血泪教训纸上得来终觉浅绝知此事要躬行。Managed Agents 的文档写得再漂亮也掩盖不了真实世界里的沟沟坎坎。以下是我和团队在过去一个月高强度使用中踩过的、总结出的、最值得分享的 7 个坑。它们没有出现在任何官方文档里但每一个都曾让我们加班到凌晨。5.1 坑一system_prompt的“幻觉放大器”效应你以为越详细的system_prompt模型就越听话错。在 Managed Agents 的架构下过长的system_prompt会成为一个巨大的“幻觉放大器”。原因在于Harness 在每次需要模型决策时都会将当前的 session 事件日志包含所有之前的tool_result和system_prompt一起喂给模型。如果system_prompt本身就有 1000 字再加上 500 字的事件日志很容易就逼近模型的上下文上限。此时模型为了“填满”这个巨大的上下文会本能地生成更多、更冗长、更“合理”的输出而这恰恰是幻觉的温床。解决方案将system_prompt严格控制在 200-300 字。把所有“规则”、“流程”、“例外情况”全部剥离写成独立的、结构化的tool。例如不要在 prompt 里写“如果公司规模大于 1000 人加 20 分”而是写一个calculate_firmographic_score工具把所有评分逻辑封装在里面。让模型只做一件事决定“下一步调用哪个工具”。5.2 坑二沙箱内的时间感知陷阱沙箱是一个与外界隔绝的微环境。它默认的系统时间是沙箱启动那一刻的 UTC 时间。如果你的工具逻辑里包含了time.sleep(30)或者依赖于datetime.now()来做超时判断那么恭喜你你将得到一个永远无法结束的沙箱。因为sleep的 30 秒是沙箱内部的 30 秒而 Harness 等待它的超时机制是基于外部世界的时钟。解决方案永远不要在沙箱代码里使用time.sleep()。如果需要等待应该由 Harness 层通过delay_until事件来控制。所有时间相关的逻辑都应该通过 Harness 提供的get_current_time()接口来获取一个标准化的、与 session 日志对齐的时间戳。5.3 坑三tool_result的“字符串诅咒”Harness 要求execute的返回值必须是string。这看似简单却埋下了巨大的隐患。如果你的工具返回了一个 Pythondict比如{score: 87, reason: High engagement}Harness 会尝试用str()函数将其转换为字符串{\score\: 87, \reason\: \High engagement\}。这个字符串里充满了转义字符当模型下次读取它时解析会失败。解决方案在沙箱工具的最后一步必须显式地调用json.dumps()。并且为了保险起见应该捕获所有可能的异常并返回一个格式统一的错误字符串例如{error: Failed to connect to DB, code: DB_CONN_ERR}。Harness 会原样传递这个字符串模型可以根据error字段来决定是重试还是放弃。5.4 坑四tool_call_validation的“宽松陷阱”guardrails里的tool_call_validation默认是“宽松模式”。如果你只在allowed_tools列表里写了[tool_a]但模型却生成了{name: tool_b, ...}Harness 不会报错而是会静默地忽略这次调用并生成一个空的tool_result。这会导致整个工作流卡死因为你永远等不到tool_b的结果。解决方案在生产环境中必须将tool_call_validation的mode设置为strict。这样任何未在白名单中的工具调用都会立刻触发一个明确的ToolCallValidationErrorHarness 会将其作为一条error事件写入日志让你能第一时间定位问题。5.5 坑五Session 的“僵尸状态”危机一个 session 在创建后如果用户长时间不发送新的user_input它并不会自动销毁。它会一直保持active状态Harness 进程也会持续运行默默消耗着你的 $0.08/小时。我们曾有一个测试 session因为忘记关闭连续运行了 72 小时产生了近 $6 的“僵尸费用”。解决方案在创建 session 时务必设置timeout_seconds参数。例如timeout_seconds: 3600表示如果 session 在一小时内没有任何新的用户输入或工具调用它将被自动终止。这是最简单、最有效的成本防火墙。5.6 坑六Credential Vault 的“权限粒度”盲区Credential Vault 很安全但它默认的权限模型是“粗粒度”的。你只能为一个 credential 设置一个scope比如jira:read。但如果你的jira_api工具既需要读取 issue又需要创建 comment那么你必须给它jira:read_write的权限。这就违背了最小权限原则。解决方案为同一类服务创建多个细粒度的 credentials。例如创建jira_read_only和jira_comment_writer两个独立的凭证。然后在tools定义中为fetch_issue工具绑定前者为post_comment工具绑定后者。这样即使fetch_issue工具的代码被攻破攻击者也无法获得写权限。5.7 坑七Event Log 的“查询性能”悬崖Session 的事件日志是强大的但它的查询 API 并非为大数据分析而生。当你试图用GET /sessions/{id}/events?limit10000来拉取一个运行了三天、产生了上万条事件的 session 全量日志时API 会直接返回504 Gateway Timeout。解决方案永远不要试图一次性拉取全量日志。正确的做法是利用cursor参数进行分页查询。首先用?limit100获取前 100 条从返回的next_cursor字段中提取下一个游标再用?cursor{next_cursor}limit100获取下一批。这是一个标准的、可扩展的流式读取模式。对于需要长期归档的场景应该配置 webhook让 Anthropic 在每次新事件写入时主动推送一个通知到你的 S3 存储桶。6. 未来已来当 agent 开始自我进化runtime 就成了法律文书最后我想聊一个正在逼近、却尚未被主流讨论的终极命题self-improving agents自我改进型 agent。Sakana AI 团队发表的 Darwin Gödel Machine 论文已经不是一个科幻概念。它描述了一个 agent能够阅读自己的代码、理解自己的行为、识别性能瓶颈并最终生成一份新的、更优的代码版本来替换自己。它在 SWE-bench 编程基准测试上的成功率从 20% 提升到了 50%。这个过程是可验证的、可复现的。当 agent 不再是静态的、由人类编写的脚本而是一个能自主迭代、自我优化的“活体”时整个技术栈的安全模型和治理模型都将被彻底颠覆。Sandboxing 不再是“可选项”而是“强制项”。一个能重写自身代码的 agent如果运行在一个拥有 root 权限、能访问宿主机文件系统的容器里其后果不堪设想。它可能在一夜之间将一个用于分析财报的 agent改造成一个扫描内网漏洞的渗透工具。Managed Agents 的 cattle-style sandbox其价值将从“工程最佳实践”跃升为“生存必需”。Observability可观测性不再是为了“调试”而是为了“举证”。当一个自我改进的 agent 生成了一份错误的、甚至是有害的决策比如错误地将一笔合法交易标记为欺诈并冻结了客户账户你需要的不再是一份 debug 日志而是一份具有法律效力的、不可篡改的“操作证据链”。这份证据链必须能清晰地展示初始的 agent 版本是什么它在何时、基于何种输入、做出了何种自我修改的决策修改后的代码是什么修改后的 agent 又是如何执行的这正是 Trace Store追踪存储要解决的核心问题——它将成为 AI 时代的“黑匣子”。Runtime 的价值将从“执行效率”转向“监管合规”。未来的 runtime其核心竞争力可能不再是“p95 延迟是多少毫秒”而是“是否通过了 ISO/IEC 23053 AI Governance 认证”、“是否内置了符合 GDPR 的数据擦除协议”、“是否能为每一次 agent 决策生成符合《AI Act》要求的解释性报告”。它将从一个技术组件演变为一个法律与合规的基础设施。我个人在实际操作中的体会是Managed Agents 的发布其划时代的意义不在于它今天能做什么而在于它为明天铺平了道路。它用一套优雅、坚固、可验证的抽象把那个混乱、脆弱、充满不确定性的 agent 世界第一次装进了一个清晰、稳定、可管理的盒子里。盒子本身或许会被后来者取代但这个“装盒”的思路已经成为了行业的新共识。我们这一代开发者有幸站在这个转折点上见证并参与一场关于“如何让机器真正可靠地为我们工作”的宏大叙事。这比任何单一产品的功能都更令人激动。
