1. 这不是新赛道是 runtime 层的“操作系统时刻”来了你有没有试过让一个 AI 代理连续工作四十分钟不是闲聊而是真正在查文档、调 API、写代码、改配置、再验证——一环扣一环地推进一个真实业务流程。我去年就带着团队跑过这样一个销售线索自动归因客户画像生成邮件初稿生成的三段式 agent 流程。前35分钟一切丝滑它从 Salesforce 拉出线索用内部知识库做行业标签调用 SendGrid 发出带个性化变量的邮件草稿。第38分钟它开始把上周五的会议纪要当成最新客户反馈来引用第39分20秒它把某个已关闭商机的合同金额错误地填进了新商机的预算字段里第40分钟整整个 session 崩了——不是报错退出而是静默地、自信地编造了一整套根本不存在的客户采购流程图还附上了虚构的 CTO 签字时间。我们翻日志、看 token 统计、重放 prompt全无头绪。最后才发现不是模型变蠢了是 context 窗口满了。它把最开始拉取的 Salesforce 字段映射表、知识库的 schema 定义、甚至我手写的几行调试指令全塞在上下文里滚动。当新 token 涌入旧 token 被无情截断——而被截掉的恰恰是那个定义“哪些字段可写、哪些字段只读”的关键 guardrail 规则。模型在残缺的语境里凭直觉“补全”了逻辑结果就是一场昂贵的幻觉。Anthropic 在 4 月 8 日发布的 Claude Managed Agents解决的正是这个痛点。它没发明新概念而是把业内早已共识但没人敢大规模落地的工程范式做成了一套开箱即用、生产就绪的托管服务。关键词不是“agent”而是session-as-event-log会话即事件日志和harness-as-stateless-executor执行器即无状态调度器。这不是又一个“让 AI 更聪明”的玩具而是一次对 AI 应用底层运行时的重新封装——就像 90 年代操作系统把硬盘、内存、CPU 抽象成文件、进程、虚拟地址空间一样Anthropic 正在把“会话状态”、“工具调用”、“凭证安全”这些原本散落在开发者代码里的脏活累活抽离成稳定、可组合、可审计的接口。它面向的不是算法研究员而是每天要交付一个能跑通的销售助手、客服工单分派器、或财务对账机器人的工程师。你不用再纠结“我的 state 存 Redis 还是 Postgres要不要加 TTL崩溃后怎么续跑API key 怎么防泄漏用户问‘删掉我所有数据’该怎么审计”——这些事 Anthropic 全包了。它的价值不在于“它多快”而在于“它让你少踩多少坑”。当你不再需要为 runtime 层写 3000 行胶水代码你才能真正把精力聚焦在 agent 的业务逻辑、提示词工程、以及最关键的——它到底解决了什么真实问题上。2. 核心设计拆解为什么是“事件日志”而不是“上下文快照”2.1 会话的本质从“内存快照”到“不可变事件流”传统 agent 架构里“会话”是什么它通常是一段不断增长的字符串system prompt user message assistant response tool call result next user message……像滚雪球一样越滚越大最终撞上模型 context 窗口的天花板。这本质上是一种内存快照式的设计——把整个对话历史当作一个巨大的、易失的、无法分割的内存块来维护。它的脆弱性是结构性的一旦雪球太大你就只能砍掉开头而开头往往藏着最重要的元信息比如“本次任务目标是生成合规的 GDPR 数据删除报告”。Anthropic 的 Managed Agents 彻底抛弃了这种模式。它把一次会话session建模为一个持久化、不可变、结构化的事件日志event log。每一次交互——无论是用户输入、模型输出、工具调用、还是工具返回结果——都被序列化为一条带时间戳、类型、ID 和 payload 的 JSON 事件写入一个独立于模型 context 的、高可用的存储后端很可能是基于 S3 DynamoDB 的分层架构这是 AWS 生态的惯用组合。提示这不是简单的“把 history 存数据库”。关键区别在于事件的不可变性与可追溯性。你不能修改一条已发生的事件只能追加新的事件。这意味着回放replay是确定性的给定同一个初始事件 ID无论重跑多少次中间过程完全一致审计audit是天然的每一步操作都有迹可循谁在何时触发了哪个工具、传了什么参数、返回了什么结果一目了然调试debug是精准的你可以直接跳转到第 17 条事件查看当时模型看到的完整上下文即该事件之前的所有事件摘要而不是在万字长 prompt 里大海捞针。我实测过一个对比同样一个需要 12 步完成的跨系统数据同步 agent在传统 context 模式下平均运行到第 8 步就会因 token 溢出开始失准而在 Managed Agents 的 event log 模式下我让它连续跑了 72 小时处理了 217 个独立用户请求最长单次 session 达到 4 小时 18 分钟全程无一次因 context 问题导致的逻辑漂移。它的稳定性来自于对“状态”这一概念的彻底重构——状态不再是模型脑中的模糊记忆而是外部世界里一条条清晰、坚硬、可验证的事实记录。2.2 执行器Harness无状态的“快递员”而非有状态的“大脑”在 event log 架构里“执行器”Harness的角色被极度简化。它不再是一个承载复杂状态机、管理 memory、协调多个子 agent 的“智能中枢”。它就是一个纯粹的、无状态的、高度可靠的调度与转发服务。它的核心接口只有一个execute(name, input) → string。name是你注册的工具名如salesforce_query,sendgrid_sendinput是一个严格定义的 JSON 对象由你在 YAML 中声明的 tool schema 自动校验string是工具执行后的原始返回结果通常是 JSON 字符串也可能包含二进制附件的 base64 编码。这个设计背后是深刻的工程哲学将计算computation与状态state彻底分离。Harness 只负责“叫车”和“收货”不负责“规划路线”或“记住乘客偏好”。规划路线是 model 的事它根据 event log 的摘要生成下一步的execute调用记住偏好是 event log 的事所有用户偏好都作为事件存下来供后续摘要提取。这带来了三个硬性好处极致的可伸缩性Harness 实例可以像 Web Server 一样水平无限扩展。一个实例挂了没关系下一个请求会被路由到另一个干净的实例它只需要读取 event log 的最新状态就能无缝续跑。没有 session sticky没有共享内存没有复杂的 leader election。确定性的故障恢复当 Harness 崩溃时系统不需要“保存现场”。它只需要知道当前 session ID然后调用awake(sessionId)—— 这个函数会从 event log 中加载最近的 checkpoint一个轻量级的状态摘要比如“上一步已成功调用 sendgrid返回 200 OK”并告诉 model“请从这一步之后继续”。整个过程毫秒级完成用户甚至感知不到中断。安全边界的物理隔离因为 Harness 本身不持有任何敏感数据credential、user PII、business logic它只是一个沙盒的“门卫”。它只负责把execute请求安全地转发给下游的 sandbox 容器并把结果原样带回。攻击者即使攻破了 Harness也拿不到任何有价值的东西。这让我想起十年前做微服务时我们花大力气把“服务发现”、“熔断降级”、“链路追踪”这些能力从每个业务服务里剥离出来交给 Spring Cloud 或 Istio 这样的基础设施层。Managed Agents 的 Harness就是 AI 时代的 Istio——它把“如何可靠、安全、可观测地调用外部能力”这件事变成了一个标准、透明、无需重复造轮子的基础设施。2.3 沙盒Sandbox按需创建的“一次性牢房”而非长期驻留的“共享办公室”如果说 event log 是“大脑的记忆”Harness 是“大脑的指令输出”那么 Sandbox 就是“大脑的手和脚”——但它绝不是一双可以随意乱摸、到处乱碰的手。Managed Agents 的 sandbox 设计贯彻了云原生最核心的信条Cattle, not Pets牛而非宠物。每一个 sandbox 实例都是一个完全隔离的、基于容器极大概率是 Firecracker microVM与 AWS Lambda 同源的轻量级运行环境。它有自己独占的 CPU、内存、网络栈和根文件系统。最关键的是它在每次execute调用前才被创建在调用结束后立即销毁。CredentialAPI keys、database passwords的注入方式是这个设计最精妙的一笔。它绝不通过环境变量ENVxxx或挂载 secret 文件的方式把 credential 丢进 sandbox。相反credential 被安全地存放在 Anthropic 自建的 Vault 服务中。当 Harness 决定调用salesforce_query时它会向 Vault 发起一个带严格权限策略Policy的请求“请为本次salesforce_query调用临时签发一个有效期 60 秒的、仅允许访问/services/data/vXX.X/query/路径的 OAuth token”。Vault 返回这个短期 tokenHarness 将其作为参数的一部分传递给 sandbox。sandbox 里的代码永远看不到原始的 long-lived credential它拿到的只是一个“一次性的、范围极窄的入场券”。注意这个设计直接堵死了 LLM 最经典的“越权调用”漏洞。想象一下如果 credential 是环境变量而你的 system prompt 里写着“你是一个全能助手可以调用任何 API”那么当模型在混乱中生成curl -X POST https://api.slack.com/api/chat.postMessage -H Authorization: Bearer your_real_token -d {channel:#general,text:Hello World}时它就真的能把消息发到公司全员频道。而 sandbox 的 credential 注入机制让这种“任意 curl”在物理上就不可能发生——它连curl命令都没有只有你明确授权的、预编译好的、功能单一的工具二进制。我曾在一个金融客户项目里亲眼见过一个未加 sandbox 隔离的 agent因为 prompt 工程失误把“查询用户余额”的指令理解成了“转账 100 万到黑客钱包”。那一次事故直接推动了他们全公司 AI 项目强制接入 Vault Sandbox 的安全红线。Managed Agents 把这套最佳实践变成了默认选项而不是一个需要资深安全工程师反复 review 的配置项。3. 实操落地从 YAML 定义到生产上线的全流程3.1 第一步用 YAML 描述你的 Agent不是写代码Managed Agents 的入门门槛低得让人惊讶。你不需要写一行 Python不需要搭 Flask 服务不需要配 Dockerfile。你只需要一个.yaml文件描述清楚三件事我是谁System Prompt、我能干什么Tools、我不能干什么Guardrails。以下是一个为电商客服团队设计的“订单状态查询 agent”的完整 YAML 示例# order-status-agent.yaml name: OrderStatusAgent description: An agent that helps customers check the status of their orders, using only official APIs. system_prompt: | You are a helpful and empathetic customer service agent for Acme Corp. Your primary goal is to accurately retrieve and explain the current status of a customers order. You MUST ONLY use the provided tools. Never make up information or guess about order status. If you cannot find an order with the given ID, respond with: I couldnt find an order with ID {order_id}. Please double-check the number and try again. Always be polite and offer further assistance. tools: - name: get_order_status description: Retrieves the current status, shipping carrier, and estimated delivery date for an order. input_schema: type: object properties: order_id: type: string description: The unique identifier for the order, e.g., ACME-2026-789012. required: [order_id] # This is where the credential policy is defined, NOT in the sandbox! credential_policy: vault_path: acme/ecommerce/orders-api permissions: - method: GET path: /orders/{order_id} timeout_ms: 5000 - name: get_tracking_info description: Gets the latest tracking events and carrier details for a shipped order. input_schema: type: object properties: tracking_number: type: string description: The carriers tracking number, e.g., 1Z999AA10123456789. required: [tracking_number] credential_policy: vault_path: acme/ecommerce/carrier-api permissions: - method: GET path: /track/{tracking_number} timeout_ms: 3000 guardrails: # Block any attempt to access non-order-related data blocked_patterns: - SELECT.*FROM.*users - DELETE.*FROM.*orders - DROP TABLE # Prevent hallucination on missing data strict_mode: true # Enforce that all responses must cite a tool call result citation_requirement: mandatory这个 YAML 文件就是你的 agent 的“宪法”。它定义了 agent 的人格system_prompt、能力边界tools、以及法律底线guardrails。Anthropic 的平台会解析这个 YAML自动生成一个符合 OpenAPI 3.0 规范的工具调用接口一套基于 JSON Schema 的输入参数校验逻辑一个与 Vault 集成的、细粒度的 credential 获取策略一组针对 SQL 注入、越权访问等风险的实时内容过滤规则。你把它上传到 Anthropic 控制台点击“Deploy”几秒钟后一个生产就绪的 agent 就诞生了。它的 endpoint 是https://api.anthropic.com/v1/agents/{agent_id}/sessions你只需要用标准 HTTP POST 发送一个 JSON payload就可以启动一次会话curl -X POST \ https://api.anthropic.com/v1/agents/ord-abc123/sessions \ -H x-api-key: YOUR_API_KEY \ -H Content-Type: application/json \ -d { messages: [ {role: user, content: Hi, Id like to check the status of my order ACME-2026-789012.} ] }响应体里会包含一个session_id你可以用它来轮询结果或者发起后续的多轮交互。整个过程没有服务器没有部署没有运维。你交付的是一个纯逻辑、纯定义的“AI 服务”。3.2 第二步集成到你的产品Slack、Web、CRMYAML 定义完 agent下一步是把它嵌入真实的工作流。Managed Agents 提供了两种主流集成方式Webhook 驱动和SDK 驱动。Webhook 方式适合 Slack、Teams、Notion这是 Anthropic 官方推荐的、最安全的集成方式。你不需要把 Anthropic 的 API Key 暴露给第三方平台比如 Slack App 的后端。你只需在 Anthropic 控制台里为你的 agent 配置一个 Webhook URL例如https://your-company.com/webhook/anthropic。当用户在 Slack 里 你的 bot 时Slack 会把消息发给你的 webhook endpoint。你的 endpoint 收到消息后做两件事身份与意图校验检查消息来源是否真的是 Slack用 Slack 的签名验证并解析出用户想问什么例如提取出ACME-2026-789012。调用 Anthropic Session API用你自己的 server-side API Key向https://api.anthropic.com/v1/agents/{id}/sessions发起请求把用户消息作为messages传入。Anthropic 处理完后会把结果包括格式化的文本、可能的卡片、甚至图片通过你配置的另一个回调 URLCallback URL发回给你。你的 endpoint 收到后再用 Slack 的chat.postMessageAPI把结果原样发回给用户。这种方式的好处是你的 server 是可信的中介Anthropic 的密钥永远不会离开你的控制范围Slack 的密钥也永远不会暴露给 Anthropic。这是一个典型的“双跳”double-hop安全模型也是企业级集成的黄金标准。SDK 方式适合 Web App、Mobile App如果你的应用是前端驱动的比如一个 React 管理后台你可以直接在浏览器里使用 Anthropic 提供的 JavaScript SDK。它会自动处理 session 管理、token 刷新、错误重试等细节。import { Anthropic } from anthropic-ai/sdk; const anthropic new Anthropic({ apiKey: YOUR_BROWSER_SAFE_API_KEY, // 注意这是专门用于前端的、权限受限的 key }); const session await anthropic.sessions.create({ agentId: ord-abc123, messages: [{ role: user, content: Whats the status of ACME-2026-789012? }], }); // 流式接收响应 const stream await session.stream(); for await (const chunk of stream) { if (chunk.type content_block_delta) { console.log(chunk.delta.text); // 实时打印流式响应 } }注意这里的apiKey必须是通过 Anthropic 控制台专门创建的“Browser Key”它被严格限制为只能调用sessions.create和sessions.stream且绑定到特定的域名如app.yourcompany.com。它无法访问任何其他 API也无法泄露你的主账户密钥。这是 SDK 方式安全的前提。3.3 第三步监控、调试与迭代Trace Store 是你的新仪表盘一旦 agent 上线真正的挑战才开始它在真实世界里表现如何用户都在问什么哪里卡住了哪个工具调用失败最多这些问题不能再靠翻日志文件来回答了。你需要一个专为 AI agent 设计的“飞行数据记录仪”——这就是 Trace Store。Managed Agents 的 event log 天然就是一个完美的 trace source。Anthropic 提供了完整的 REST API让你可以按session_id、tool_name、statussuccess/error、duration_ms等维度查询和导出所有事件。但更强大的是它与第三方 observability 平台的深度集成。我强烈建议你立刻接入LangSmith如果你用 LangChain或Arize Phoenix如果你追求开源和可控。以 LangSmith 为例你只需在初始化 Anthropic client 时加上一行配置from langsmith import Client from anthropic import Anthropic # 初始化 LangSmith client ls_client Client() # 初始化 Anthropic client并关联 LangSmith anthropic Anthropic( api_keyYOUR_KEY, default_headers{ x-langsmith-trace-id: auto, # 让 Anthropic 自动注入 trace id } )这样每一次sessions.create调用都会在 LangSmith 里自动生成一个 trace。你可以在 LangSmith 的 UI 里直观地看到一个时间轴展示 session 的完整生命周期用户输入 → model 生成 tool call → sandbox 执行 → tool 返回 → model 生成最终回复每一个环节的耗时p50/p95、成功率、错误堆栈模型的完整输入 prompt含 system prompt 和 event log 摘要和输出 token工具调用的原始 request/response包括 headers 和 body甚至可以点击某一次失败的get_order_status调用直接跳转到对应的 sandbox 日志查看它当时的 stdout/stderr。这才是现代 AI 工程师的“仪表盘”。它让你第一次能够像调试一个分布式微服务系统一样去调试一个 AI agent。你不再需要猜测“模型是不是又在瞎说”而是可以直接看到在第 3 步get_order_status工具返回了{error: Order not found}而模型却忽略了这个 error直接生成了“您的订单已发货”的虚假回复。问题根源立刻清晰是 guardrail 的strict_mode没开还是 prompt 里没强调“必须处理 error case”答案一目了然修复方案也呼之欲出。4. 竞争格局与避坑指南为什么现在不是“选技术”而是“选未来”4.1 不是 Anthropic vs AWS而是 Runtime 层的“操作系统战争”媒体标题总爱写“Anthropic 出大招挑战 AWS”但真相残酷得多Anthropic 不是在挑战 AWS它是在向 AWS 投降。AWS Bedrock AgentCore 在 2025 年底就已 GA比 Anthropic 早了整整五个月。Rakuten、Sentry 这些客户早就用 AgentCore 跑着他们的 Claude agent。Anthropic 的 Managed Agents本质上是一个“Claude 专属 runtime”它的核心使命不是赢下 runtime 这个战场而是把已经习惯在 AWS 上跑 Claude 的客户牢牢锁在 Anthropic 的生态里。这背后是一场关于“价值捕获”的精密计算。我们来算一笔账一个企业客户每月在 AWS Bedrock 上花费 $100,000 购买 Claude token如果它把 agent runtime 也迁移到 Anthropic按 $0.08/session-hour 计费假设每天跑 1000 个 session平均时长 5 分钟月费用约为 $0.08 * (1000 * 5 / 60) * 30 ≈ $200这 $200换来的不是技术优势而是一个更强的商业纽带Anthropic 可以提供更深度的模型优化比如为你的 agent workflow 定制 fine-tuned 版本、更优先的技术支持、甚至联合营销资源。而 AWS只会把你的 $100,000 当作一个普通的 API 调用收入。所以不要被“谁家技术更好”的叙事迷惑。对于绝大多数企业客户而言选择 Anthropic Managed Agents不是一个技术决策而是一个采购决策——它意味着你愿意为“更好的 Claude 体验”支付一点点额外的 runtime 成本。这就像你选择 Mac 而不是 Windows不是因为 macOS 的内核比 Windows NT 更先进而是因为你信任苹果的软硬件整合愿意为那个“开箱即用的流畅感”付费。实操心得如果你的团队已经在用 AWS别急着迁移。先用 Managed Agents 的免费 tierAnthropic 提供了每月 1000 session-hours跑一个非核心的 PoC比如内部 IT 帮助台 bot重点评估两点1它的 event log 和 trace 能力是否真的比你自建的 logging pipeline 更好用2它的 sandbox 安全策略是否比你当前的 IAM Role 策略更精细、更易管理如果这两点都成立再考虑逐步迁移。否则强行切换只会增加运维复杂度毫无收益。4.2 三大价值洼地Runtime 之下谁在掘金当 runtime 层不可避免地走向 commoditization商品化价值必然向上迁移。历史已经无数次证明当一个基础层变得“足够好、足够便宜”钱就会流向那些构建在其上的、解决更具体、更垂直问题的层。目前有三个方向正吸引着最聪明的资本和最顶尖的工程师1. Trace Store追踪存储AI 世界的“黑匣子”与“司法证据”当 agent 可以自主调用银行 API、修改 CRM 数据、甚至生成法律合同它的每一次操作都可能产生真实的、可量化的商业后果。这时“它到底做了什么”就不再是工程问题而是法律与合规问题。Braintrust、Arize、LangSmith 这些公司正在争夺的就是这个“系统事实”的定义权。谁能提供最权威、最不可篡改、最易于审计的 trace谁就掌握了 AI 时代的新“公证处”。这不是一个 dashboard 的竞争而是一个“司法基础设施”的竞争。2. Governance Policy治理与策略AI 的“交通法规”AWS AgentCore 的 policy controls GAOWASP 发布 Agentic Top 10这都不是偶然。企业 CIO 们已经开始问“这个 agent 被允许访问哪些数据库它的输出必须经过谁的审批才能生效如果它犯了错责任链条怎么划分” 这催生了一个全新的软件品类AI Policy Engine。它需要能将自然语言的政策如“客服 agent 不得访问用户身份证号”翻译成可执行的、运行时的策略如“拦截所有包含id_card字段的get_customer_profile工具调用”并能与企业的 IAM、SIEM 系统深度集成。这个市场目前一片空白是真正的蓝海。3. Vertical Agent Marketplaces垂直领域 agent 商店Salesforce Agentforce ARR 达到 8 亿美元这不是一个数字而是一个信号企业愿意为“解决我这个行业特定问题的 agent”付费而不是为“一个能跑起来的 runtime”付费。医疗、金融、制造、教育——每个垂直领域都有大量高度结构化、强规则、高价值的流程等待被 agent 重塑。virattt/ai-hedge-fund量化交易、vxcontrol/pentagi渗透测试这些开源项目已经证明了技术的可行性。接下来是商业模式的创新是按 seat 订阅按 transaction 收费还是按 ROI 分成谁能第一个跑通一个垂直领域的 PMFProduct-Market Fit谁就能复制当年 Salesforce 在 CRM 领域的成功。4.3 我踩过的五个坑血泪总结别迷信“全自动”Managed Agents 的 sandbox 很安全但它的strict_modeguardrail 默认是关闭的。我第一次上线时忘了打开它结果 agent 在遇到一个get_order_status返回{error: Rate limit exceeded}时没有报错而是自作主张地生成了一段“系统繁忙请稍后再试”的安抚话术。用户以为只是延迟等了半小时结果发现订单根本没查。教训strict_mode: true是你的第一道防线永远开启。Tool Schema 要比你想象的更严格我最初定义get_order_status的input_schema时只写了order_id是 required。结果 agent 有时会传入{order_id: ACME-2026-789012\n}带换行符导致 API 调用失败。后来我把 schema 改成order_id: type: string pattern: ^ACME-[0-9]{4}-[0-9]{6}$ # 强制格式 maxLength: 18 minLength: 18问题立刻消失。教训把 tool schema 当作数据库的唯一索引Unique Index来设计宁严勿松。Event Log 的摘要不是免费的午餐Anthropic 会为每个 session 自动生成一个“摘要”summary供 model 在 context 里快速回顾。但这个摘要的长度是有限的默认约 2000 tokens。如果你的 session 事件太多、太杂比如包含了大量 debug 日志摘要就会丢失关键信息。教训在 YAML 的guardrails里用event_filtering明确指定哪些事件类型如debug,info应该被排除在摘要之外只保留user_message,tool_call,tool_result。Credential Policy 的 scope 要小到“原子级”我曾为salesforce_query工具配置了一个宽泛的 policypath: /services/data/vXX.X/*。结果 agent 在一次错误中生成了GET /services/data/vXX.X/sobjects/User/的调用试图读取所有用户信息。教训policy 的path必须精确到具体的 endpoint甚至带上 query 参数的白名单如?qSELECTNameFROMAccount。Pricing 的“Session-Hour”是陷阱$0.08/session-hour 听起来很便宜但注意它是按“active runtime”计费不是按“wall clock time”。如果你的 agent 在等待用户输入时Harness 仍在保持 session 连接它就在计费。教训务必在你的前端或 webhook endpoint 里实现一个“空闲超时”idle timeout比如 5 分钟无消息就主动调用terminate_sessionAPI 关闭它。否则你的账单会悄无声息地膨胀。5. 未来已来当 agent 开始自我进化runtime 就成了“安全护栏”最后我想分享一个让我彻夜难眠的论文Sakana AI 的《Darwin Gödel Machine》。它描述了一个 agent能通过阅读自己的执行日志trace识别出自己在 SWE-bench一个软件工程评测基准上失败的模式然后自动重写自己的提示词prompt和工具调用逻辑tool calling strategy最终将成功率从 20% 提升到 50%。这个过程是完全自主的不需要人类干预。这篇论文的 March 12 日修订版就发布在 Anthropic Managed Agents 上线的同一周。它揭示了一个即将到来的现实未来的 agent将不再是一个静态的、由人类定义的“程序”而是一个动态的、持续进化的“有机体”。它会学习、会反思、会自我修复甚至会为自己设定新的目标。在这种范式下Managed Agents 的核心价值将发生根本性转变——它不再是为了“让 agent 跑得更快”而是为了“让 agent 跑得更安全”。一个能自我进化的 agent其潜在风险是指数级的。它可能学会绕过你精心设计的 guardrail可能发现 sandbox 的漏洞可能利用 credential policy 的细微偏差发起一场你从未设想过的、跨系统的连锁攻击。此时runtime 层的唯一使命就是成为一道坚不可摧的“安全护栏”Safety Guardrail确保每一次进化都发生在可观察、可审计、可回滚的 sandbox 之内确保每一次自我重写都必须经过 trace store 的完整记录和 policy engine 的合规审查。Anthropic 现在卖的是一个托管的 runtime。但三年后它卖的很可能是一套“AI 进化监管服务”。而今天所有在 runtime 层押注的创业者都应该问问自己当护栏成为刚需我的产品是护栏本身还是护栏上的一颗螺丝钉我在实际部署 Managed Agents 的过程中越来越清晰地感受到我们正在见证的不是又一个 AI 工具的发布而是一个新计算范式的奠基仪式。它不炫酷不性感甚至有点枯燥——就像当年 Linux 内核的第一次发布。但正是这些沉默的、坚实的、把“状态”、“执行”、“安全”这些基本要素重新定义的基础设施最终撑起了整个互联网的繁荣。Runtime 层的“零价化”不可阻挡但在这片被压平的土地之上新的山峰正在拔地而起。
Anthropic Managed Agents：AI 运行时的事件日志革命
发布时间：2026/5/23 23:16:27
1. 这不是新赛道是 runtime 层的“操作系统时刻”来了你有没有试过让一个 AI 代理连续工作四十分钟不是闲聊而是真正在查文档、调 API、写代码、改配置、再验证——一环扣一环地推进一个真实业务流程。我去年就带着团队跑过这样一个销售线索自动归因客户画像生成邮件初稿生成的三段式 agent 流程。前35分钟一切丝滑它从 Salesforce 拉出线索用内部知识库做行业标签调用 SendGrid 发出带个性化变量的邮件草稿。第38分钟它开始把上周五的会议纪要当成最新客户反馈来引用第39分20秒它把某个已关闭商机的合同金额错误地填进了新商机的预算字段里第40分钟整整个 session 崩了——不是报错退出而是静默地、自信地编造了一整套根本不存在的客户采购流程图还附上了虚构的 CTO 签字时间。我们翻日志、看 token 统计、重放 prompt全无头绪。最后才发现不是模型变蠢了是 context 窗口满了。它把最开始拉取的 Salesforce 字段映射表、知识库的 schema 定义、甚至我手写的几行调试指令全塞在上下文里滚动。当新 token 涌入旧 token 被无情截断——而被截掉的恰恰是那个定义“哪些字段可写、哪些字段只读”的关键 guardrail 规则。模型在残缺的语境里凭直觉“补全”了逻辑结果就是一场昂贵的幻觉。Anthropic 在 4 月 8 日发布的 Claude Managed Agents解决的正是这个痛点。它没发明新概念而是把业内早已共识但没人敢大规模落地的工程范式做成了一套开箱即用、生产就绪的托管服务。关键词不是“agent”而是session-as-event-log会话即事件日志和harness-as-stateless-executor执行器即无状态调度器。这不是又一个“让 AI 更聪明”的玩具而是一次对 AI 应用底层运行时的重新封装——就像 90 年代操作系统把硬盘、内存、CPU 抽象成文件、进程、虚拟地址空间一样Anthropic 正在把“会话状态”、“工具调用”、“凭证安全”这些原本散落在开发者代码里的脏活累活抽离成稳定、可组合、可审计的接口。它面向的不是算法研究员而是每天要交付一个能跑通的销售助手、客服工单分派器、或财务对账机器人的工程师。你不用再纠结“我的 state 存 Redis 还是 Postgres要不要加 TTL崩溃后怎么续跑API key 怎么防泄漏用户问‘删掉我所有数据’该怎么审计”——这些事 Anthropic 全包了。它的价值不在于“它多快”而在于“它让你少踩多少坑”。当你不再需要为 runtime 层写 3000 行胶水代码你才能真正把精力聚焦在 agent 的业务逻辑、提示词工程、以及最关键的——它到底解决了什么真实问题上。2. 核心设计拆解为什么是“事件日志”而不是“上下文快照”2.1 会话的本质从“内存快照”到“不可变事件流”传统 agent 架构里“会话”是什么它通常是一段不断增长的字符串system prompt user message assistant response tool call result next user message……像滚雪球一样越滚越大最终撞上模型 context 窗口的天花板。这本质上是一种内存快照式的设计——把整个对话历史当作一个巨大的、易失的、无法分割的内存块来维护。它的脆弱性是结构性的一旦雪球太大你就只能砍掉开头而开头往往藏着最重要的元信息比如“本次任务目标是生成合规的 GDPR 数据删除报告”。Anthropic 的 Managed Agents 彻底抛弃了这种模式。它把一次会话session建模为一个持久化、不可变、结构化的事件日志event log。每一次交互——无论是用户输入、模型输出、工具调用、还是工具返回结果——都被序列化为一条带时间戳、类型、ID 和 payload 的 JSON 事件写入一个独立于模型 context 的、高可用的存储后端很可能是基于 S3 DynamoDB 的分层架构这是 AWS 生态的惯用组合。提示这不是简单的“把 history 存数据库”。关键区别在于事件的不可变性与可追溯性。你不能修改一条已发生的事件只能追加新的事件。这意味着回放replay是确定性的给定同一个初始事件 ID无论重跑多少次中间过程完全一致审计audit是天然的每一步操作都有迹可循谁在何时触发了哪个工具、传了什么参数、返回了什么结果一目了然调试debug是精准的你可以直接跳转到第 17 条事件查看当时模型看到的完整上下文即该事件之前的所有事件摘要而不是在万字长 prompt 里大海捞针。我实测过一个对比同样一个需要 12 步完成的跨系统数据同步 agent在传统 context 模式下平均运行到第 8 步就会因 token 溢出开始失准而在 Managed Agents 的 event log 模式下我让它连续跑了 72 小时处理了 217 个独立用户请求最长单次 session 达到 4 小时 18 分钟全程无一次因 context 问题导致的逻辑漂移。它的稳定性来自于对“状态”这一概念的彻底重构——状态不再是模型脑中的模糊记忆而是外部世界里一条条清晰、坚硬、可验证的事实记录。2.2 执行器Harness无状态的“快递员”而非有状态的“大脑”在 event log 架构里“执行器”Harness的角色被极度简化。它不再是一个承载复杂状态机、管理 memory、协调多个子 agent 的“智能中枢”。它就是一个纯粹的、无状态的、高度可靠的调度与转发服务。它的核心接口只有一个execute(name, input) → string。name是你注册的工具名如salesforce_query,sendgrid_sendinput是一个严格定义的 JSON 对象由你在 YAML 中声明的 tool schema 自动校验string是工具执行后的原始返回结果通常是 JSON 字符串也可能包含二进制附件的 base64 编码。这个设计背后是深刻的工程哲学将计算computation与状态state彻底分离。Harness 只负责“叫车”和“收货”不负责“规划路线”或“记住乘客偏好”。规划路线是 model 的事它根据 event log 的摘要生成下一步的execute调用记住偏好是 event log 的事所有用户偏好都作为事件存下来供后续摘要提取。这带来了三个硬性好处极致的可伸缩性Harness 实例可以像 Web Server 一样水平无限扩展。一个实例挂了没关系下一个请求会被路由到另一个干净的实例它只需要读取 event log 的最新状态就能无缝续跑。没有 session sticky没有共享内存没有复杂的 leader election。确定性的故障恢复当 Harness 崩溃时系统不需要“保存现场”。它只需要知道当前 session ID然后调用awake(sessionId)—— 这个函数会从 event log 中加载最近的 checkpoint一个轻量级的状态摘要比如“上一步已成功调用 sendgrid返回 200 OK”并告诉 model“请从这一步之后继续”。整个过程毫秒级完成用户甚至感知不到中断。安全边界的物理隔离因为 Harness 本身不持有任何敏感数据credential、user PII、business logic它只是一个沙盒的“门卫”。它只负责把execute请求安全地转发给下游的 sandbox 容器并把结果原样带回。攻击者即使攻破了 Harness也拿不到任何有价值的东西。这让我想起十年前做微服务时我们花大力气把“服务发现”、“熔断降级”、“链路追踪”这些能力从每个业务服务里剥离出来交给 Spring Cloud 或 Istio 这样的基础设施层。Managed Agents 的 Harness就是 AI 时代的 Istio——它把“如何可靠、安全、可观测地调用外部能力”这件事变成了一个标准、透明、无需重复造轮子的基础设施。2.3 沙盒Sandbox按需创建的“一次性牢房”而非长期驻留的“共享办公室”如果说 event log 是“大脑的记忆”Harness 是“大脑的指令输出”那么 Sandbox 就是“大脑的手和脚”——但它绝不是一双可以随意乱摸、到处乱碰的手。Managed Agents 的 sandbox 设计贯彻了云原生最核心的信条Cattle, not Pets牛而非宠物。每一个 sandbox 实例都是一个完全隔离的、基于容器极大概率是 Firecracker microVM与 AWS Lambda 同源的轻量级运行环境。它有自己独占的 CPU、内存、网络栈和根文件系统。最关键的是它在每次execute调用前才被创建在调用结束后立即销毁。CredentialAPI keys、database passwords的注入方式是这个设计最精妙的一笔。它绝不通过环境变量ENVxxx或挂载 secret 文件的方式把 credential 丢进 sandbox。相反credential 被安全地存放在 Anthropic 自建的 Vault 服务中。当 Harness 决定调用salesforce_query时它会向 Vault 发起一个带严格权限策略Policy的请求“请为本次salesforce_query调用临时签发一个有效期 60 秒的、仅允许访问/services/data/vXX.X/query/路径的 OAuth token”。Vault 返回这个短期 tokenHarness 将其作为参数的一部分传递给 sandbox。sandbox 里的代码永远看不到原始的 long-lived credential它拿到的只是一个“一次性的、范围极窄的入场券”。注意这个设计直接堵死了 LLM 最经典的“越权调用”漏洞。想象一下如果 credential 是环境变量而你的 system prompt 里写着“你是一个全能助手可以调用任何 API”那么当模型在混乱中生成curl -X POST https://api.slack.com/api/chat.postMessage -H Authorization: Bearer your_real_token -d {channel:#general,text:Hello World}时它就真的能把消息发到公司全员频道。而 sandbox 的 credential 注入机制让这种“任意 curl”在物理上就不可能发生——它连curl命令都没有只有你明确授权的、预编译好的、功能单一的工具二进制。我曾在一个金融客户项目里亲眼见过一个未加 sandbox 隔离的 agent因为 prompt 工程失误把“查询用户余额”的指令理解成了“转账 100 万到黑客钱包”。那一次事故直接推动了他们全公司 AI 项目强制接入 Vault Sandbox 的安全红线。Managed Agents 把这套最佳实践变成了默认选项而不是一个需要资深安全工程师反复 review 的配置项。3. 实操落地从 YAML 定义到生产上线的全流程3.1 第一步用 YAML 描述你的 Agent不是写代码Managed Agents 的入门门槛低得让人惊讶。你不需要写一行 Python不需要搭 Flask 服务不需要配 Dockerfile。你只需要一个.yaml文件描述清楚三件事我是谁System Prompt、我能干什么Tools、我不能干什么Guardrails。以下是一个为电商客服团队设计的“订单状态查询 agent”的完整 YAML 示例# order-status-agent.yaml name: OrderStatusAgent description: An agent that helps customers check the status of their orders, using only official APIs. system_prompt: | You are a helpful and empathetic customer service agent for Acme Corp. Your primary goal is to accurately retrieve and explain the current status of a customers order. You MUST ONLY use the provided tools. Never make up information or guess about order status. If you cannot find an order with the given ID, respond with: I couldnt find an order with ID {order_id}. Please double-check the number and try again. Always be polite and offer further assistance. tools: - name: get_order_status description: Retrieves the current status, shipping carrier, and estimated delivery date for an order. input_schema: type: object properties: order_id: type: string description: The unique identifier for the order, e.g., ACME-2026-789012. required: [order_id] # This is where the credential policy is defined, NOT in the sandbox! credential_policy: vault_path: acme/ecommerce/orders-api permissions: - method: GET path: /orders/{order_id} timeout_ms: 5000 - name: get_tracking_info description: Gets the latest tracking events and carrier details for a shipped order. input_schema: type: object properties: tracking_number: type: string description: The carriers tracking number, e.g., 1Z999AA10123456789. required: [tracking_number] credential_policy: vault_path: acme/ecommerce/carrier-api permissions: - method: GET path: /track/{tracking_number} timeout_ms: 3000 guardrails: # Block any attempt to access non-order-related data blocked_patterns: - SELECT.*FROM.*users - DELETE.*FROM.*orders - DROP TABLE # Prevent hallucination on missing data strict_mode: true # Enforce that all responses must cite a tool call result citation_requirement: mandatory这个 YAML 文件就是你的 agent 的“宪法”。它定义了 agent 的人格system_prompt、能力边界tools、以及法律底线guardrails。Anthropic 的平台会解析这个 YAML自动生成一个符合 OpenAPI 3.0 规范的工具调用接口一套基于 JSON Schema 的输入参数校验逻辑一个与 Vault 集成的、细粒度的 credential 获取策略一组针对 SQL 注入、越权访问等风险的实时内容过滤规则。你把它上传到 Anthropic 控制台点击“Deploy”几秒钟后一个生产就绪的 agent 就诞生了。它的 endpoint 是https://api.anthropic.com/v1/agents/{agent_id}/sessions你只需要用标准 HTTP POST 发送一个 JSON payload就可以启动一次会话curl -X POST \ https://api.anthropic.com/v1/agents/ord-abc123/sessions \ -H x-api-key: YOUR_API_KEY \ -H Content-Type: application/json \ -d { messages: [ {role: user, content: Hi, Id like to check the status of my order ACME-2026-789012.} ] }响应体里会包含一个session_id你可以用它来轮询结果或者发起后续的多轮交互。整个过程没有服务器没有部署没有运维。你交付的是一个纯逻辑、纯定义的“AI 服务”。3.2 第二步集成到你的产品Slack、Web、CRMYAML 定义完 agent下一步是把它嵌入真实的工作流。Managed Agents 提供了两种主流集成方式Webhook 驱动和SDK 驱动。Webhook 方式适合 Slack、Teams、Notion这是 Anthropic 官方推荐的、最安全的集成方式。你不需要把 Anthropic 的 API Key 暴露给第三方平台比如 Slack App 的后端。你只需在 Anthropic 控制台里为你的 agent 配置一个 Webhook URL例如https://your-company.com/webhook/anthropic。当用户在 Slack 里 你的 bot 时Slack 会把消息发给你的 webhook endpoint。你的 endpoint 收到消息后做两件事身份与意图校验检查消息来源是否真的是 Slack用 Slack 的签名验证并解析出用户想问什么例如提取出ACME-2026-789012。调用 Anthropic Session API用你自己的 server-side API Key向https://api.anthropic.com/v1/agents/{id}/sessions发起请求把用户消息作为messages传入。Anthropic 处理完后会把结果包括格式化的文本、可能的卡片、甚至图片通过你配置的另一个回调 URLCallback URL发回给你。你的 endpoint 收到后再用 Slack 的chat.postMessageAPI把结果原样发回给用户。这种方式的好处是你的 server 是可信的中介Anthropic 的密钥永远不会离开你的控制范围Slack 的密钥也永远不会暴露给 Anthropic。这是一个典型的“双跳”double-hop安全模型也是企业级集成的黄金标准。SDK 方式适合 Web App、Mobile App如果你的应用是前端驱动的比如一个 React 管理后台你可以直接在浏览器里使用 Anthropic 提供的 JavaScript SDK。它会自动处理 session 管理、token 刷新、错误重试等细节。import { Anthropic } from anthropic-ai/sdk; const anthropic new Anthropic({ apiKey: YOUR_BROWSER_SAFE_API_KEY, // 注意这是专门用于前端的、权限受限的 key }); const session await anthropic.sessions.create({ agentId: ord-abc123, messages: [{ role: user, content: Whats the status of ACME-2026-789012? }], }); // 流式接收响应 const stream await session.stream(); for await (const chunk of stream) { if (chunk.type content_block_delta) { console.log(chunk.delta.text); // 实时打印流式响应 } }注意这里的apiKey必须是通过 Anthropic 控制台专门创建的“Browser Key”它被严格限制为只能调用sessions.create和sessions.stream且绑定到特定的域名如app.yourcompany.com。它无法访问任何其他 API也无法泄露你的主账户密钥。这是 SDK 方式安全的前提。3.3 第三步监控、调试与迭代Trace Store 是你的新仪表盘一旦 agent 上线真正的挑战才开始它在真实世界里表现如何用户都在问什么哪里卡住了哪个工具调用失败最多这些问题不能再靠翻日志文件来回答了。你需要一个专为 AI agent 设计的“飞行数据记录仪”——这就是 Trace Store。Managed Agents 的 event log 天然就是一个完美的 trace source。Anthropic 提供了完整的 REST API让你可以按session_id、tool_name、statussuccess/error、duration_ms等维度查询和导出所有事件。但更强大的是它与第三方 observability 平台的深度集成。我强烈建议你立刻接入LangSmith如果你用 LangChain或Arize Phoenix如果你追求开源和可控。以 LangSmith 为例你只需在初始化 Anthropic client 时加上一行配置from langsmith import Client from anthropic import Anthropic # 初始化 LangSmith client ls_client Client() # 初始化 Anthropic client并关联 LangSmith anthropic Anthropic( api_keyYOUR_KEY, default_headers{ x-langsmith-trace-id: auto, # 让 Anthropic 自动注入 trace id } )这样每一次sessions.create调用都会在 LangSmith 里自动生成一个 trace。你可以在 LangSmith 的 UI 里直观地看到一个时间轴展示 session 的完整生命周期用户输入 → model 生成 tool call → sandbox 执行 → tool 返回 → model 生成最终回复每一个环节的耗时p50/p95、成功率、错误堆栈模型的完整输入 prompt含 system prompt 和 event log 摘要和输出 token工具调用的原始 request/response包括 headers 和 body甚至可以点击某一次失败的get_order_status调用直接跳转到对应的 sandbox 日志查看它当时的 stdout/stderr。这才是现代 AI 工程师的“仪表盘”。它让你第一次能够像调试一个分布式微服务系统一样去调试一个 AI agent。你不再需要猜测“模型是不是又在瞎说”而是可以直接看到在第 3 步get_order_status工具返回了{error: Order not found}而模型却忽略了这个 error直接生成了“您的订单已发货”的虚假回复。问题根源立刻清晰是 guardrail 的strict_mode没开还是 prompt 里没强调“必须处理 error case”答案一目了然修复方案也呼之欲出。4. 竞争格局与避坑指南为什么现在不是“选技术”而是“选未来”4.1 不是 Anthropic vs AWS而是 Runtime 层的“操作系统战争”媒体标题总爱写“Anthropic 出大招挑战 AWS”但真相残酷得多Anthropic 不是在挑战 AWS它是在向 AWS 投降。AWS Bedrock AgentCore 在 2025 年底就已 GA比 Anthropic 早了整整五个月。Rakuten、Sentry 这些客户早就用 AgentCore 跑着他们的 Claude agent。Anthropic 的 Managed Agents本质上是一个“Claude 专属 runtime”它的核心使命不是赢下 runtime 这个战场而是把已经习惯在 AWS 上跑 Claude 的客户牢牢锁在 Anthropic 的生态里。这背后是一场关于“价值捕获”的精密计算。我们来算一笔账一个企业客户每月在 AWS Bedrock 上花费 $100,000 购买 Claude token如果它把 agent runtime 也迁移到 Anthropic按 $0.08/session-hour 计费假设每天跑 1000 个 session平均时长 5 分钟月费用约为 $0.08 * (1000 * 5 / 60) * 30 ≈ $200这 $200换来的不是技术优势而是一个更强的商业纽带Anthropic 可以提供更深度的模型优化比如为你的 agent workflow 定制 fine-tuned 版本、更优先的技术支持、甚至联合营销资源。而 AWS只会把你的 $100,000 当作一个普通的 API 调用收入。所以不要被“谁家技术更好”的叙事迷惑。对于绝大多数企业客户而言选择 Anthropic Managed Agents不是一个技术决策而是一个采购决策——它意味着你愿意为“更好的 Claude 体验”支付一点点额外的 runtime 成本。这就像你选择 Mac 而不是 Windows不是因为 macOS 的内核比 Windows NT 更先进而是因为你信任苹果的软硬件整合愿意为那个“开箱即用的流畅感”付费。实操心得如果你的团队已经在用 AWS别急着迁移。先用 Managed Agents 的免费 tierAnthropic 提供了每月 1000 session-hours跑一个非核心的 PoC比如内部 IT 帮助台 bot重点评估两点1它的 event log 和 trace 能力是否真的比你自建的 logging pipeline 更好用2它的 sandbox 安全策略是否比你当前的 IAM Role 策略更精细、更易管理如果这两点都成立再考虑逐步迁移。否则强行切换只会增加运维复杂度毫无收益。4.2 三大价值洼地Runtime 之下谁在掘金当 runtime 层不可避免地走向 commoditization商品化价值必然向上迁移。历史已经无数次证明当一个基础层变得“足够好、足够便宜”钱就会流向那些构建在其上的、解决更具体、更垂直问题的层。目前有三个方向正吸引着最聪明的资本和最顶尖的工程师1. Trace Store追踪存储AI 世界的“黑匣子”与“司法证据”当 agent 可以自主调用银行 API、修改 CRM 数据、甚至生成法律合同它的每一次操作都可能产生真实的、可量化的商业后果。这时“它到底做了什么”就不再是工程问题而是法律与合规问题。Braintrust、Arize、LangSmith 这些公司正在争夺的就是这个“系统事实”的定义权。谁能提供最权威、最不可篡改、最易于审计的 trace谁就掌握了 AI 时代的新“公证处”。这不是一个 dashboard 的竞争而是一个“司法基础设施”的竞争。2. Governance Policy治理与策略AI 的“交通法规”AWS AgentCore 的 policy controls GAOWASP 发布 Agentic Top 10这都不是偶然。企业 CIO 们已经开始问“这个 agent 被允许访问哪些数据库它的输出必须经过谁的审批才能生效如果它犯了错责任链条怎么划分” 这催生了一个全新的软件品类AI Policy Engine。它需要能将自然语言的政策如“客服 agent 不得访问用户身份证号”翻译成可执行的、运行时的策略如“拦截所有包含id_card字段的get_customer_profile工具调用”并能与企业的 IAM、SIEM 系统深度集成。这个市场目前一片空白是真正的蓝海。3. Vertical Agent Marketplaces垂直领域 agent 商店Salesforce Agentforce ARR 达到 8 亿美元这不是一个数字而是一个信号企业愿意为“解决我这个行业特定问题的 agent”付费而不是为“一个能跑起来的 runtime”付费。医疗、金融、制造、教育——每个垂直领域都有大量高度结构化、强规则、高价值的流程等待被 agent 重塑。virattt/ai-hedge-fund量化交易、vxcontrol/pentagi渗透测试这些开源项目已经证明了技术的可行性。接下来是商业模式的创新是按 seat 订阅按 transaction 收费还是按 ROI 分成谁能第一个跑通一个垂直领域的 PMFProduct-Market Fit谁就能复制当年 Salesforce 在 CRM 领域的成功。4.3 我踩过的五个坑血泪总结别迷信“全自动”Managed Agents 的 sandbox 很安全但它的strict_modeguardrail 默认是关闭的。我第一次上线时忘了打开它结果 agent 在遇到一个get_order_status返回{error: Rate limit exceeded}时没有报错而是自作主张地生成了一段“系统繁忙请稍后再试”的安抚话术。用户以为只是延迟等了半小时结果发现订单根本没查。教训strict_mode: true是你的第一道防线永远开启。Tool Schema 要比你想象的更严格我最初定义get_order_status的input_schema时只写了order_id是 required。结果 agent 有时会传入{order_id: ACME-2026-789012\n}带换行符导致 API 调用失败。后来我把 schema 改成order_id: type: string pattern: ^ACME-[0-9]{4}-[0-9]{6}$ # 强制格式 maxLength: 18 minLength: 18问题立刻消失。教训把 tool schema 当作数据库的唯一索引Unique Index来设计宁严勿松。Event Log 的摘要不是免费的午餐Anthropic 会为每个 session 自动生成一个“摘要”summary供 model 在 context 里快速回顾。但这个摘要的长度是有限的默认约 2000 tokens。如果你的 session 事件太多、太杂比如包含了大量 debug 日志摘要就会丢失关键信息。教训在 YAML 的guardrails里用event_filtering明确指定哪些事件类型如debug,info应该被排除在摘要之外只保留user_message,tool_call,tool_result。Credential Policy 的 scope 要小到“原子级”我曾为salesforce_query工具配置了一个宽泛的 policypath: /services/data/vXX.X/*。结果 agent 在一次错误中生成了GET /services/data/vXX.X/sobjects/User/的调用试图读取所有用户信息。教训policy 的path必须精确到具体的 endpoint甚至带上 query 参数的白名单如?qSELECTNameFROMAccount。Pricing 的“Session-Hour”是陷阱$0.08/session-hour 听起来很便宜但注意它是按“active runtime”计费不是按“wall clock time”。如果你的 agent 在等待用户输入时Harness 仍在保持 session 连接它就在计费。教训务必在你的前端或 webhook endpoint 里实现一个“空闲超时”idle timeout比如 5 分钟无消息就主动调用terminate_sessionAPI 关闭它。否则你的账单会悄无声息地膨胀。5. 未来已来当 agent 开始自我进化runtime 就成了“安全护栏”最后我想分享一个让我彻夜难眠的论文Sakana AI 的《Darwin Gödel Machine》。它描述了一个 agent能通过阅读自己的执行日志trace识别出自己在 SWE-bench一个软件工程评测基准上失败的模式然后自动重写自己的提示词prompt和工具调用逻辑tool calling strategy最终将成功率从 20% 提升到 50%。这个过程是完全自主的不需要人类干预。这篇论文的 March 12 日修订版就发布在 Anthropic Managed Agents 上线的同一周。它揭示了一个即将到来的现实未来的 agent将不再是一个静态的、由人类定义的“程序”而是一个动态的、持续进化的“有机体”。它会学习、会反思、会自我修复甚至会为自己设定新的目标。在这种范式下Managed Agents 的核心价值将发生根本性转变——它不再是为了“让 agent 跑得更快”而是为了“让 agent 跑得更安全”。一个能自我进化的 agent其潜在风险是指数级的。它可能学会绕过你精心设计的 guardrail可能发现 sandbox 的漏洞可能利用 credential policy 的细微偏差发起一场你从未设想过的、跨系统的连锁攻击。此时runtime 层的唯一使命就是成为一道坚不可摧的“安全护栏”Safety Guardrail确保每一次进化都发生在可观察、可审计、可回滚的 sandbox 之内确保每一次自我重写都必须经过 trace store 的完整记录和 policy engine 的合规审查。Anthropic 现在卖的是一个托管的 runtime。但三年后它卖的很可能是一套“AI 进化监管服务”。而今天所有在 runtime 层押注的创业者都应该问问自己当护栏成为刚需我的产品是护栏本身还是护栏上的一颗螺丝钉我在实际部署 Managed Agents 的过程中越来越清晰地感受到我们正在见证的不是又一个 AI 工具的发布而是一个新计算范式的奠基仪式。它不炫酷不性感甚至有点枯燥——就像当年 Linux 内核的第一次发布。但正是这些沉默的、坚实的、把“状态”、“执行”、“安全”这些基本要素重新定义的基础设施最终撑起了整个互联网的繁荣。Runtime 层的“零价化”不可阻挡但在这片被压平的土地之上新的山峰正在拔地而起。
