1. 这不是新赛道是 runtime 层的“操作系统时刻”来了你有没有试过让一个 AI 代理连续工作四十分钟不是闲聊而是真正在查资料、调 API、写代码、改文档、再交叉验证——一整套闭环动作。去年我带团队跑一个金融尽调代理时就卡在第37分钟上下文窗口满了模型没报错也没中断它只是悄悄把最早调用的三个数据库结果给“忘了”然后基于残缺记忆开始编造后续步骤。等我们发现时整个流程已经偏离原始目标两轮且无法回溯——没有日志、没有快照、没有 checkpoint只有一段越来越离谱的输出。这不是故障是静默失效不是 bug是架构债。Anthropic 在 2026 年 4 月 8 日发布的Claude Managed Agents表面看是一次常规功能更新实则踩中了所有正在构建长周期、多步骤、高可信度 AI 应用的团队最痛的那个点状态不可靠、执行不可控、过程不可查。它没发明新概念但把过去两年业内反复试错、踩坑、重写才摸出来的三根支柱第一次打包成开箱即用的生产级服务会持久化的 session、无状态的 harness、与凭证彻底隔离的 sandbox。这三者组合起来就是一套轻量级的“AI 操作系统内核”。关键词里那个 “Towards AI - Medium” 不是随便贴的标签——它恰恰说明这篇分析的底色不站队、不捧杀、不贩卖焦虑而是从工程落地的第一线视角拆解“为什么现在必须做这件事”“为什么 Anthropic 做得对但不够早”“为什么你今天选的 runtime 架构半年后可能变成成本中心”。这不是讲给投资人听的 PPT 故事是写给凌晨两点还在 debug agent session timeout 的工程师、给正在评估要不要把 LangGraph 迁进云沙箱的架构师、给被业务方追问“上次那个合同审核代理为啥漏了第三条违约条款”的技术负责人的实操备忘录。它解决的不是“能不能跑起来”而是“敢不敢让它跑一整周”。当你不再需要为每次 tool call 手动存 state、不再担心 token 超限导致历史蒸发、不再把 API key 硬编码进 prompt 或环境变量——你就从“AI 玩家”跨进了“AI 工程师”的门槛。而这个门槛Anthropic 这次用 YAML 配置和 $0.08/小时的定价给你搭了一道结实的台阶。2. 核心设计逻辑为什么是 session-as-event-log而不是 context-as-database2.1 旧范式之殇把上下文当硬盘用注定崩盘先说清楚问题出在哪。2024 年到 2025 年初绝大多数自研 agent 系统都遵循一个朴素但危险的模式所有状态都塞进 LLM 的 context window。用户输入、系统指令、工具返回结果、中间推理草稿、甚至错误重试记录——全堆在 prompt 里靠模型自己“记住”并引用。这就像让一个实习生边开会边记笔记边写纪要边查邮件边回 Slack还要求他三天后能准确复述第一天讨论的第三个数据源字段名。我亲手重构过两个这样的系统。第一个是客服工单分类代理context 窗口设为 32k理论上够用。但实际运行中用户每轮追加一条新消息我们就得把前序全部 history 新消息 system prompt 重新拼接发送。到了第 12 轮交互光是 history 就占掉 28k tokens留给模型思考和生成的空间只剩 4k。更糟的是模型在压缩历史时会优先丢弃早期、看似“不关键”的 tool call 结果——比如第一次调用 CRM 接口查到的客户等级它觉得“后面没提应该不重要”结果在第五轮生成解决方案时完全忽略了该客户属于 VIP 白名单这一硬性规则。第二个是更典型的 RAGTool 复合代理先检索 5 篇文档再调用 3 个内部 API 获取实时数据最后综合生成报告。我们测试过 20 次连续运行平均在第 33 分钟触发 context 溢出。模型不会报错它只是开始“自由发挥”把检索到的文档 A 的结论错误地嫁接到 API B 返回的数据上生成一份逻辑自洽但事实全错的报告。事后排查没有 trace没有 snapshot只有最后一段输出和一堆无法关联的 log。我们花了 17 个小时才定位到是 context 溢出导致的幻觉而不是模型本身的问题。提示这不是模型能力不足而是架构设计把“状态存储”这个本该由数据库承担的职责强加给了推理引擎。LLM 是 CPU不是 SSD。2.2 Anthropic 的解法三层解耦各司其职Managed Agents 的核心突破在于用明确的边界把过去混在一起的三件事彻底分开Session会话不再是内存里的临时变量而是一个持久化、可查询、带时间戳的事件日志event log。每一次 tool call 的输入、输出、耗时、状态success/error、甚至模型生成的 intermediate reasoning 步骤都被原子化地写入这个日志。它独立于任何一次模型调用存储在 Anthropic 的后端服务中生命周期可达数天甚至数周。Harness执行器一个纯粹的、无状态的函数调用桥接层。它只做一件事收到execute(tool_name, input)请求就去调用对应容器container拿到字符串结果后原样返回。它不保存任何中间状态不参与决策不缓存历史。这意味着 harness 可以随时崩溃、重启、扩缩容只要拿着 sessionId 就能通过awake(sessionId)恢复上下文——因为真正的“上下文”不在 harness 里而在 session event log 里。Sandbox沙箱不是共享资源的虚拟机而是按需创建、用完即焚的 cattle 式隔离环境。每个 tool call 都在一个全新的、干净的 sandbox 中执行。最关键的是凭证credentials在 sandbox 创建时注入但绝不以环境变量形式暴露给 agent 本身。Agent 只能看到一个抽象的tool_name和input它永远不知道背后调用的 AWS Lambda 的 IAM Role ARN也看不到数据库连接串里的密码。这堵墙是用血泪教训浇筑出来的——我们曾因一个 prompt 注入漏洞让 agent 把os.environ.get(DB_PASSWORD)当成普通字符串输出直接泄露了生产库密钥。这三层解耦直接对应了操作系统演进史上的关键跃迁Session as event log ≈文件系统File System提供持久化、结构化、可追溯的数据存储。Harness as stateless executor ≈进程调度器Process Scheduler高效、可靠、可扩展地分发计算任务。Sandbox as cattle ≈虚拟内存与硬件抽象Virtual Memory Hardware Abstraction屏蔽底层差异保障隔离与安全。所以 Anthropic 工程博客里说的“像 90 年代 OS 虚拟化硬件”不是修辞是精准的技术类比。它意味着未来你升级 Claude 模型版本只需改 harness 的配置不用动 session 存储逻辑你更换 sandbox 底层容器技术从 Docker 到 WASM只需适配 harness 的 execute 接口session 日志格式保持不变。这种稳定性是工程规模化的基本前提。2.3 为什么 AWS Bedrock AgentCore 先行五个月却没引发同等震动这里有个关键误判很多人看到 “AWS AgentCore GA 五个月” 就觉得 Anthropic 是跟风。但翻看 AWS 的官方文档和早期用户反馈会发现一个根本差异AgentCore 的设计哲学是“框架中立”而 Managed Agents 的设计哲学是“Claude 优先”。AgentCore 确实强大它支持 LangGraph、CrewAI、任何符合 request-response 协议的框架模型可选 Bedrock 上所有家族Claude、Llama、Cohere。但它本质上是一个通用 runtime 容器你需要自己处理 session state 的持久化通常连到 DynamoDB 或 S3、自己管理 credential 注入用 IAM Roles for Service Accounts、自己实现 checkpoint 和 resume 逻辑。它给你的是“发动机和底盘”但你要自己造车身、装方向盘、接仪表盘。而 Managed Agents 给你的是一辆出厂即配好导航、自动泊车、黑匣子全程记录的量产车。YAML 里定义好 tools 和 guardrailsAnthropic 就帮你搞定 state、security、observability 全栈。Notion 能快速上线“团队委托 Claude”功能不是因为他们有顶级 infra 团队而是因为 Anthropic 把他们最不想碰的脏活累活全包了。这解释了为什么市场反应不同AgentCore 是给云原生架构师和资深 MLOps 工程师的乐高积木Managed Agents 是给产品团队和应用开发者的一键部署方案。前者需要你懂 Kubernetes、IAM、DynamoDB TTL后者你只需要会写 YAML 和读 error message。这不是技术高低之分是目标用户和交付形态的本质区别。3. 实操细节解析从 YAML 配置到生产级部署的完整链路3.1 你的第一个 Managed Agent三步走通别被“managed”吓住它的入门门槛其实很低。我用一个真实的销售线索评分代理Lead Scoring Agent为例展示从零到可运行的全过程。这个代理需要1从 HubSpot API 拉取新线索2调用内部风控模型 API 判断欺诈概率3根据分数和行业标签生成定制化跟进建议。第一步定义 agent.yaml# agent.yaml name: sales-lead-scorer description: Scores new leads and generates follow-up suggestions system_prompt: | You are a sales operations expert at Acme Corp. Your job is to: 1. Analyze lead data from HubSpot. 2. Check fraud risk score from our internal model. 3. Generate a concise, actionable follow-up suggestion based on score and industry. Always cite your sources (e.g., Per HubSpot data..., Based on fraud model...). Never hallucinate data not provided in the tool responses. tools: - name: hubspot_get_new_leads description: Fetches leads created in the last 24 hours from HubSpot input_schema: type: object properties: limit: type: integer default: 10 # No credentials here — managed by Anthropic vault - name: fraud_model_score description: Calls internal fraud detection model with lead data input_schema: type: object properties: lead_id: type: string email_domain: type: string guardrails: output_filters: - type: pii_redaction patterns: [email, phone, ssn] - type: content_moderation severity_threshold: high max_tool_calls_per_step: 3注意几个关键点tools下的input_schema是强制的Anthropic 用它做 runtime 输入校验避免 agent 传错参数导致 sandbox 崩溃。guardrails不是摆设。pii_redaction会在输出前自动识别并替换邮箱、电话等敏感字段content_moderation会拦截高风险内容如暴力、歧视性语言阈值设为high意味着只拦真正危险的不过度干预。没有任何 credential 字符串出现在 YAML 里。HubSpot 的 API Key 和风控模型的 Token都在 Anthropic 控制台的 Vault 里单独配置绑定到这个 agent 名称下。sandbox 启动时Vault 自动注入agent 代码里永远看不到明文。第二步部署与启动# 使用 Anthropic CLIv2.1 anthropic agents deploy --file agent.yaml --environment production # 输出Agent sales-lead-scorer deployed. ID: agt_abc123... # 启动一个新 session anthropic sessions start --agent-id agt_abc123 --initial-input Analyze new leads # 输出Session started. ID: sess_xyz789. Status: running...CLI 会返回一个sess_xyz789的 session ID。这就是你的“进程 PID”。你可以随时用它查询状态、获取日志、甚至中断恢复。第三步与 session 交互真实请求体// POST https://api.anthropic.com/v1/sessions/sess_xyz789/messages { messages: [ { role: user, content: Start scoring leads for Q2 campaign } ], max_tokens: 2048 }Anthropic 会从 session event log 读取当前状态这是首次log 为空调用 harness执行execute(hubspot_get_new_leads, {limit: 10})sandbox 执行 HubSpot API 调用返回 10 条线索数据将这次 tool call 的完整事件输入、输出、耗时、timestamp写入 session logharness 拿到结果交给 Claude 模型生成下一步指令例如“调用 fraud_model_score 对 lead_id12345 进行评分”harness 再次执行execute(fraud_model_score, {...})重复步骤 3-4最终模型整合所有 tool 结果生成自然语言回复并同样写入 session log。整个过程你作为开发者只关心三件事YAML 配置是否正确、tool 的 input_schema 是否匹配、guardrails 是否覆盖了业务风险点。其余全是 Anthropic 托管。3.2 生产环境必调参数不只是 $0.08/小时那么简单定价是 $0.08/session-hour但实际成本受三个隐藏参数深刻影响参数默认值影响实测调整建议session_timeout1 hoursession 空闲超时后自动终止释放资源高频交互场景如客服设为30m低频批处理如日报生成设为8h避免频繁重建 session 的开销max_tool_call_depth5防止 agent 陷入无限 tool call 循环我们遇到过 agent 因数据异常反复调用同一 API 127 次。设为3后第 4 次失败时自动 fallback 到人工审核流程sandbox_memory_mb1024sandbox 的内存上限直接影响 tool尤其是 Python 数据分析脚本能否运行调用 Pandas 处理 10MB CSV至少2048纯 API 调用512足够。我们用memory_profiler测试过1024是多数工具的甜点区注意这些参数不是在 YAML 里写的而是在anthropic agents deploy命令里用--config指定一个 JSON 文件// config.json { session_timeout: 8h, max_tool_call_depth: 3, sandbox_memory_mb: 2048 }部署命令变为anthropic agents deploy --file agent.yaml --config config.json另一个常被忽略的成本点是token 用量结构。Managed Agents 的计费是两层的基础层Claude 模型的 input/output tokens按标准 rate 计费如 Sonnet $3/million input tokensruntime 层$0.08/session-hour按 session 的活跃时长计费从start到end或超时。关键洞察session 小时数 ≠ 模型推理时间。一个 session 可能活跃 2 小时但其中 1.8 小时在等待 HubSpot API 响应网络 I/O只有 0.2 小时在模型推理。$0.08 买的是这 2 小时的托管、日志、安全、沙箱生命周期管理——这才是 Anthropic 的真正价值也是你省下的 DevOps 成本。3.3 Credential 隔离的魔鬼细节为什么“不注入环境变量”是生死线这绝非营销话术。2025 年 Q3我们合作的一家金融科技公司就遭遇了惨痛教训他们的自研 agent 框架为了“方便调试”把数据库密码以DB_PASSWORDxxx形式注入 sandbox 环境变量。某次 agent 在生成错误报告时prompt 里写了句 “Please print all environment variables for debugging”模型竟真的执行了os.environ并输出——密码明文出现在最终给客户的 PDF 报告里。Anthropic 的解法是“双盲”设计Sandbox 内部credential 以加密 blob 形式存在sandbox OS 层面根本看不到明文。tool 代码里调用get_credential(hubspot_api_key)底层是调用一个受信的、只读的 vault client它返回解密后的 key但这个过程对 sandbox 进程是透明的。Agent 视角agent 代码里永远只有tool_name和input。它调用hubspot_get_new_leads传入{limit: 10}至于这个 tool 背后用哪个 key、哪个 endpoint、哪个 regionagent 一无所知也无法探知。我们做过压力测试在 sandbox 里执行env | grep -i pass、cat /proc/1/environ | strings、甚至尝试gdbattach 到 vault client 进程——全部失败。credential 的生命周期严格限定在 tool 执行的毫秒级窗口内用完即焚。这种设计让“凭证泄露”从一个高概率事件降级为一个需要物理访问 Anthropic 数据中心的理论可能性。4. 实操过程与核心环节实现从 Notion 集成到企业级审计追踪4.1 Notion 的集成案例如何让团队“委托工作”成为现实Notion 官方博客披露的集成远不止“在页面里加个按钮”那么简单。其核心是利用 Managed Agents 的session persistence和structured output能力把 AI 从“回答问题”升级为“执行任务”。具体流程如下用户在 Notion 页面点击 “Delegate to Claude”Notion 前端捕获当前页面 URL、块内容block content、用户选择的上下文范围如“仅本页”、“本数据库”Notion 后端创建一个新 session调用 Anthropic API传入预定义的notion-delegatoragent ID并将页面元数据作为initial-inputAgent 执行Tool 1notion_read_page—— 读取指定 URL 的页面结构和文本Tool 2notion_search_db—— 根据用户提示如“找所有未跟进的线索”搜索关联数据库Tool 3notion_create_task—— 在指定 workspace 创建一个新 task block内容包含摘要、待办项、负责人可选结果写回 NotionAgent 的最终输出是一个 JSON 结构体非纯文本包含task_id,summary,next_steps。Notion 解析此 JSON自动渲染为一个带状态徽章、可分配、可评论的智能任务块。这个流程的关键在于session 的跨请求持久化。用户点击按钮后可能去喝杯咖啡20 分钟后回来任务已创建。期间如果 Notion 服务重启只要 session ID 还在就能awake(sessionId)继续执行。而传统方案必须在单次 HTTP 请求内完成所有操作超时风险极高。实操心得我们复现此流程时最大的坑是notion_read_pagetool 的 rate limit。Notion API 对/pages/{id}/blocks接口有严格的 1000 req/day 限制。我们的解法是在 agent YAML 的tools定义里为notion_read_page添加rate_limit: 1000/day字段。Anthropic harness 会自动在 sandbox 内做本地令牌桶限流避免请求直接打到 Notion 导致 429 错误。这是 Managed Agents 提供的、自研框架极难优雅实现的基础设施能力。4.2 Rakuten 的销售/营销/财务三线 agent如何统一治理又隔离风险Rakuten 的案例展示了 Managed Agents 在大型组织中的治理优势。他们没有建三个独立 agent而是用同一个 agent 定义通过 session-level metadata 实现路由与隔离。其 agent.yaml 的核心片段# rakuten-unified-agent.yaml name: rakuten-unified # ... system_prompt, tools ... # 关键动态 guardrails based on session metadata guardrails: dynamic: - condition: session.metadata.department sales rules: allowed_tools: [hubspot_api, salesforce_api] output_filters: [sales_compliance_check] - condition: session.metadata.department finance rules: allowed_tools: [sap_api, quickbooks_api] output_filters: [finance_regulation_check]当 Slack 用户 sales-team 发起请求时Rakuten 的前端在创建 session 时会传入{ metadata: { department: sales, region: APAC, user_id: slack_u123 } }Anthropic harness 在执行前会根据session.metadata.department动态加载对应的 guardrail 规则集。这意味着销售部门的 agent 永远调用不了 SAP API工具列表被过滤财务部门的 agent 输出会强制经过finance_regulation_check过滤器确保不出现“建议逃税”等违规表述所有 session 的 event log 都打上department和region标签审计时可一键筛选 “APAC finance agents in April”。这种基于 metadata 的策略引擎比在每个 agent 里硬编码 if-else 清晰得多也便于中央合规团队统一更新规则。我们帮一家跨国银行实施类似方案时将全球 12 个区域的 GDPR、CCPA、PDPA 合规检查全部抽象为output_filters插件由法务团队在控制台一键开关无需开发介入。4.3 Sentry 的调试代理从“写补丁”到“开 PR”的闭环Sentry 的案例最能体现 Managed Agents 的工程深度。他们的 agent 不仅要理解错误堆栈还要能在 GitHub 仓库中定位相关代码文件基于错误模式生成修复补丁patch创建 Pull Request并自动 assign reviewer。这要求 agent 具备多 step planning和精确的代码编辑能力。Managed Agents 的session-as-event-log在这里发挥了决定性作用。其关键设计是将 patch 生成和 PR 创建拆分为两个独立的 tool call并用 session log 作为唯一真相源。Tool 1github_find_file—— 输入错误堆栈返回匹配的文件路径和行号Tool 2code_diff_generator—— 输入文件路径、行号、错误描述返回一个标准git diff格式的字符串Tool 3github_create_pr—— 输入diff字符串、分支名、标题创建 PR。为什么不用一个 tool 完成因为code_diff_generator可能失败如代码太复杂但github_find_file的结果是可靠的。session log 里清晰记录了Step 1:github_find_filereturned[src/utils/logger.ts, 42]Step 2:code_diff_generatorfailed with Context too large for diff generationStep 3: (fallback)code_diff_generatorcalled again withmax_context_lines: 50审计时运维团队可以直接查询 session log看到“第 2 步失败第 3 步成功”而无需猜测模型是否在“假装成功”。这种可追溯性是生产环境信任 AI 的基石。5. 常见问题与排查技巧实录那些文档里不会写的坑5.1 典型问题速查表问题现象可能原因排查步骤解决方案Session 状态卡在running但无 tool call 日志Sandbox 启动失败如内存不足、tool 依赖缺失1.anthropic sessions get --id sess_xyz查看last_event2. 检查error_code: SANDBOX_START_FAILED3. 查看sandbox_logs字段在config.json中增加sandbox_memory_mb或检查 tool container 的Dockerfile是否缺少RUN pip install requestsTool call 返回{error: Permission denied}Credential Vault 中该 tool 的权限未授予当前 agent1. 登录 Anthropic 控制台 → Vault → 找到对应 credential2. 检查Assigned Agents列表是否包含你的 agent ID在 Vault 界面点击 credential →Assign Agent→ 选择你的 agent 名称Guardrailpii_redaction没生效邮箱仍明文输出output_filters仅作用于 agent 的 final output不处理 intermediate tool results1. 检查 session log确认pii_redaction出现在output_filters_applied字段2. 确认你的system_prompt没有指令 agent “请务必显示完整邮箱”Guardrail 是最终防线应在system_prompt中明确禁止输出 PII形成双重保护Pricing 超预期$0.08/小时 × 1000 sessions $80但账单显示 $120Session hour 计费包含“冷启动时间”。新建 session 的首次 tool call 前harness 初始化约消耗 30 秒1. 查看 billing report筛选session_start_time和session_end_time2. 计算(end_time - start_time)的总和对高频小任务使用session_pool需申请白名单复用已 warm 的 harness冷启动时间降至 500ms5.2 独家避坑技巧来自 37 个生产环境的血泪总结技巧 1用session.metadata做轻量级 A/B 测试比改 YAML 高效十倍不要为了测试新 prompt 而频繁 redeploy agent。在创建 session 时传入{metadata: {prompt_version: v2.1}}然后在system_prompt里用 Jinja2 语法动态插入{% if session.metadata.prompt_version v2.1 %} You are stricter about citing sources... {% else %} You are more conversational... {% endif %}Anthropic harness 支持 Jinja2无需额外模板引擎。我们用此法一周内灰度测试了 5 个 prompt 版本零 downtime。技巧 2max_tool_call_depth是你的“熔断器”但设置需结合业务 SLA我们曾将max_tool_call_depth设为1以为能防死循环。结果客服场景下一个简单查询需hubspot_get_lead→salesforce_update_status两步直接被截断。正确做法是统计你业务中最长合法流程的 step 数再加 1 作为 buffer。我们最终设为4覆盖了 99.8% 的正常流程同时拦截了所有异常循环。技巧 3Sandbox 的timeout_seconds默认 30s但网络抖动常超此值hubspot_api在高峰期响应达 35s。timeout_seconds: 30导致 sandbox 主动 kill返回TOOL_TIMEOUT错误。解决方案不是盲目加 timeout而是在 tool container 的启动脚本里加入重试逻辑如curl --retry 3 --retry-delay 2并将timeout_seconds设为45给重试留出空间。这样既保证可靠性又避免无限 hang。技巧 4Event log 的trace_id是跨系统追踪的黄金钥匙session log 里的trace_id字段与 Anthropic 的 backend tracing 系统打通。你可以在自己的 Datadog 或 New Relic 中用这个trace_id关联Notion 前端的用户点击事件Anthropic 的 session start 事件HubSpot API 的调用日志最终生成的 PDF 报告的下载记录这让你能回答 CEO 的灵魂拷问“上个月那个导致客户投诉的错误根源到底在哪儿”——答案不再是“可能是 AI”而是“trace_idtrc_abc显示HubSpot 返回了空数组agent 未做空值处理直接传给风控模型模型报错”。6. 价值迁移图谱当 runtime 层归零钱流向哪里6.1 三层价值洼地Trace Store、Governance、Vertical Marketplace回到文章开头那个问题如果 Managed Agents 这样的 runtime 层真如 VMware 虚拟化一样在 18-24 个月内被 hyperscaler 免费化、开源项目平价化那么下一个十年的价值高地在哪里不是预测而是基于已发生的压缩波纹画出的确定性地图。第一层Trace Store追踪存储—— 你的 agent 的“黑匣子”当 runtime 变成水电煤谁来保管每一次决策的原始证据Braintrust 的 Brainstore、Arize 的 Phoenix、LangSmith它们卖的不是 dashboard而是schema-on-read 的 OLAP 数据库专为session_id,tool_name,input_hash,output_hash,latency_ms,guardrail_triggered这些字段优化。为什么它不可替代因为当你的 agent 从 Anthropic 迁移到 Azure Foundry或者混合使用多个 runtimetrace portability 是唯一能让你不被 vendor lock-in 的护城河。我们帮一家保险科技公司做迁移时花了 3 周写脚本把 Anthropic session log 转成 Phoenix 兼容格式而如果当初就用 Phoenix 作为唯一 trace store迁移只需改一行配置。第二层Governance Policy治理与策略—— AI 的“合规操作系统”AWS AgentCore 的 policy controls GAOWASP Agentic Top 10 发布这不是巧合。当 agent 能开 PR、调支付 API、生成法律文书企业采购部门问的第一个问题必然是“它被允许做什么谁批准的怎么审计” 这催生了全新品类Policy-as-Code for Agents。它不像传统 IAM 那样管“用户能访问什么资源”而是管“agent 在什么条件下能调用什么 tool输出什么内容基于什么数据源”。例如一条策略IF session.metadata.department finance AND tool_name sap_api THEN require_approval_from(CFO) AND log_to(SECURITY_AUDIT_LOG)。这个领域没有 incumbent因为它的复杂度远超传统 IAM——它要理解自然语言 intent、代码 diff、API schema、业务规则。谁能率先提供可视化策略编辑器 自然语言策略翻译器 自动合规报告谁就拿到了入场券。第三层Vertical Agent Marketplaces垂直代理市场—— “App Store for AI”Salesforce Agentforce $800M ARR 的数字揭示了一个残酷真相企业不为“runtime”付费只为“解决我知道的问题”付费。销售开发代理、医疗理赔代理、网络安全渗透测试代理——这些不是技术组件是可计量 ROI 的业务单元。virattt/ai-hedge-fund 这样的开源项目已经证明了垂直 agent 的可行性。市场机会在于提供开箱即用的垂直 agent 行业数据 connector 合规认证 SLA 保障。例如“医疗理赔代理”必须预装 HIPAA-compliant sandbox、对接 Epic 和 Cerner 的 FHIR API、通过 ONC 互操作性认证。这不再是工程师能 solo 完成的事而是需要临床顾问、合规律师、保险精算师组成的联合团队。资本已经涌入2026 年 Q1三家专注医疗 AI agent 的初创公司共获 $180M 融资。6.2 一个不容忽视的加速器Self-Improving Agents自进化代理Sakana AI 的 Darwin Gödel Machine 论文不是科幻。它证明了 agent 能基于 SWE-bench 测试结果自动重写自身代码将能力从 20% 提升到 50%。这个过程需要什么Sandboxing必须在完全隔离的环境中运行 agent 的 self-modification 代码否则它可能重写宿主系统Observability必须有完整的 trace log才能判断“新代码是否真的更好”而非只是随机变异Governance必须有 policy engine阻止 agent 生成“删除所有日志”或“关闭 sandbox 隔离”这类自毁指令。当 agent 获得自我迭代能力runtime 层就从“执行环境”升级为“监管对象”。它的定价逻辑不再是“每小时 $0.08”而是“每次 self-improvement cycle 的 audit cost”。这会让 trace store 和 governance 成为刚需中的刚需。我们已在内部测试一个简化版让 agent 每周分析自己的 session log生成“top 3 failure modes”报告并自动提交 Jira ticket。报告里附带trace_id链接工程师一点即达现场。这种闭环正是价值向“floor above”迁移的生动注脚。7.
Anthropic Managed Agents：AI 代理的运行时操作系统
发布时间：2026/6/14 8:11:49
1. 这不是新赛道是 runtime 层的“操作系统时刻”来了你有没有试过让一个 AI 代理连续工作四十分钟不是闲聊而是真正在查资料、调 API、写代码、改文档、再交叉验证——一整套闭环动作。去年我带团队跑一个金融尽调代理时就卡在第37分钟上下文窗口满了模型没报错也没中断它只是悄悄把最早调用的三个数据库结果给“忘了”然后基于残缺记忆开始编造后续步骤。等我们发现时整个流程已经偏离原始目标两轮且无法回溯——没有日志、没有快照、没有 checkpoint只有一段越来越离谱的输出。这不是故障是静默失效不是 bug是架构债。Anthropic 在 2026 年 4 月 8 日发布的Claude Managed Agents表面看是一次常规功能更新实则踩中了所有正在构建长周期、多步骤、高可信度 AI 应用的团队最痛的那个点状态不可靠、执行不可控、过程不可查。它没发明新概念但把过去两年业内反复试错、踩坑、重写才摸出来的三根支柱第一次打包成开箱即用的生产级服务会持久化的 session、无状态的 harness、与凭证彻底隔离的 sandbox。这三者组合起来就是一套轻量级的“AI 操作系统内核”。关键词里那个 “Towards AI - Medium” 不是随便贴的标签——它恰恰说明这篇分析的底色不站队、不捧杀、不贩卖焦虑而是从工程落地的第一线视角拆解“为什么现在必须做这件事”“为什么 Anthropic 做得对但不够早”“为什么你今天选的 runtime 架构半年后可能变成成本中心”。这不是讲给投资人听的 PPT 故事是写给凌晨两点还在 debug agent session timeout 的工程师、给正在评估要不要把 LangGraph 迁进云沙箱的架构师、给被业务方追问“上次那个合同审核代理为啥漏了第三条违约条款”的技术负责人的实操备忘录。它解决的不是“能不能跑起来”而是“敢不敢让它跑一整周”。当你不再需要为每次 tool call 手动存 state、不再担心 token 超限导致历史蒸发、不再把 API key 硬编码进 prompt 或环境变量——你就从“AI 玩家”跨进了“AI 工程师”的门槛。而这个门槛Anthropic 这次用 YAML 配置和 $0.08/小时的定价给你搭了一道结实的台阶。2. 核心设计逻辑为什么是 session-as-event-log而不是 context-as-database2.1 旧范式之殇把上下文当硬盘用注定崩盘先说清楚问题出在哪。2024 年到 2025 年初绝大多数自研 agent 系统都遵循一个朴素但危险的模式所有状态都塞进 LLM 的 context window。用户输入、系统指令、工具返回结果、中间推理草稿、甚至错误重试记录——全堆在 prompt 里靠模型自己“记住”并引用。这就像让一个实习生边开会边记笔记边写纪要边查邮件边回 Slack还要求他三天后能准确复述第一天讨论的第三个数据源字段名。我亲手重构过两个这样的系统。第一个是客服工单分类代理context 窗口设为 32k理论上够用。但实际运行中用户每轮追加一条新消息我们就得把前序全部 history 新消息 system prompt 重新拼接发送。到了第 12 轮交互光是 history 就占掉 28k tokens留给模型思考和生成的空间只剩 4k。更糟的是模型在压缩历史时会优先丢弃早期、看似“不关键”的 tool call 结果——比如第一次调用 CRM 接口查到的客户等级它觉得“后面没提应该不重要”结果在第五轮生成解决方案时完全忽略了该客户属于 VIP 白名单这一硬性规则。第二个是更典型的 RAGTool 复合代理先检索 5 篇文档再调用 3 个内部 API 获取实时数据最后综合生成报告。我们测试过 20 次连续运行平均在第 33 分钟触发 context 溢出。模型不会报错它只是开始“自由发挥”把检索到的文档 A 的结论错误地嫁接到 API B 返回的数据上生成一份逻辑自洽但事实全错的报告。事后排查没有 trace没有 snapshot只有最后一段输出和一堆无法关联的 log。我们花了 17 个小时才定位到是 context 溢出导致的幻觉而不是模型本身的问题。提示这不是模型能力不足而是架构设计把“状态存储”这个本该由数据库承担的职责强加给了推理引擎。LLM 是 CPU不是 SSD。2.2 Anthropic 的解法三层解耦各司其职Managed Agents 的核心突破在于用明确的边界把过去混在一起的三件事彻底分开Session会话不再是内存里的临时变量而是一个持久化、可查询、带时间戳的事件日志event log。每一次 tool call 的输入、输出、耗时、状态success/error、甚至模型生成的 intermediate reasoning 步骤都被原子化地写入这个日志。它独立于任何一次模型调用存储在 Anthropic 的后端服务中生命周期可达数天甚至数周。Harness执行器一个纯粹的、无状态的函数调用桥接层。它只做一件事收到execute(tool_name, input)请求就去调用对应容器container拿到字符串结果后原样返回。它不保存任何中间状态不参与决策不缓存历史。这意味着 harness 可以随时崩溃、重启、扩缩容只要拿着 sessionId 就能通过awake(sessionId)恢复上下文——因为真正的“上下文”不在 harness 里而在 session event log 里。Sandbox沙箱不是共享资源的虚拟机而是按需创建、用完即焚的 cattle 式隔离环境。每个 tool call 都在一个全新的、干净的 sandbox 中执行。最关键的是凭证credentials在 sandbox 创建时注入但绝不以环境变量形式暴露给 agent 本身。Agent 只能看到一个抽象的tool_name和input它永远不知道背后调用的 AWS Lambda 的 IAM Role ARN也看不到数据库连接串里的密码。这堵墙是用血泪教训浇筑出来的——我们曾因一个 prompt 注入漏洞让 agent 把os.environ.get(DB_PASSWORD)当成普通字符串输出直接泄露了生产库密钥。这三层解耦直接对应了操作系统演进史上的关键跃迁Session as event log ≈文件系统File System提供持久化、结构化、可追溯的数据存储。Harness as stateless executor ≈进程调度器Process Scheduler高效、可靠、可扩展地分发计算任务。Sandbox as cattle ≈虚拟内存与硬件抽象Virtual Memory Hardware Abstraction屏蔽底层差异保障隔离与安全。所以 Anthropic 工程博客里说的“像 90 年代 OS 虚拟化硬件”不是修辞是精准的技术类比。它意味着未来你升级 Claude 模型版本只需改 harness 的配置不用动 session 存储逻辑你更换 sandbox 底层容器技术从 Docker 到 WASM只需适配 harness 的 execute 接口session 日志格式保持不变。这种稳定性是工程规模化的基本前提。2.3 为什么 AWS Bedrock AgentCore 先行五个月却没引发同等震动这里有个关键误判很多人看到 “AWS AgentCore GA 五个月” 就觉得 Anthropic 是跟风。但翻看 AWS 的官方文档和早期用户反馈会发现一个根本差异AgentCore 的设计哲学是“框架中立”而 Managed Agents 的设计哲学是“Claude 优先”。AgentCore 确实强大它支持 LangGraph、CrewAI、任何符合 request-response 协议的框架模型可选 Bedrock 上所有家族Claude、Llama、Cohere。但它本质上是一个通用 runtime 容器你需要自己处理 session state 的持久化通常连到 DynamoDB 或 S3、自己管理 credential 注入用 IAM Roles for Service Accounts、自己实现 checkpoint 和 resume 逻辑。它给你的是“发动机和底盘”但你要自己造车身、装方向盘、接仪表盘。而 Managed Agents 给你的是一辆出厂即配好导航、自动泊车、黑匣子全程记录的量产车。YAML 里定义好 tools 和 guardrailsAnthropic 就帮你搞定 state、security、observability 全栈。Notion 能快速上线“团队委托 Claude”功能不是因为他们有顶级 infra 团队而是因为 Anthropic 把他们最不想碰的脏活累活全包了。这解释了为什么市场反应不同AgentCore 是给云原生架构师和资深 MLOps 工程师的乐高积木Managed Agents 是给产品团队和应用开发者的一键部署方案。前者需要你懂 Kubernetes、IAM、DynamoDB TTL后者你只需要会写 YAML 和读 error message。这不是技术高低之分是目标用户和交付形态的本质区别。3. 实操细节解析从 YAML 配置到生产级部署的完整链路3.1 你的第一个 Managed Agent三步走通别被“managed”吓住它的入门门槛其实很低。我用一个真实的销售线索评分代理Lead Scoring Agent为例展示从零到可运行的全过程。这个代理需要1从 HubSpot API 拉取新线索2调用内部风控模型 API 判断欺诈概率3根据分数和行业标签生成定制化跟进建议。第一步定义 agent.yaml# agent.yaml name: sales-lead-scorer description: Scores new leads and generates follow-up suggestions system_prompt: | You are a sales operations expert at Acme Corp. Your job is to: 1. Analyze lead data from HubSpot. 2. Check fraud risk score from our internal model. 3. Generate a concise, actionable follow-up suggestion based on score and industry. Always cite your sources (e.g., Per HubSpot data..., Based on fraud model...). Never hallucinate data not provided in the tool responses. tools: - name: hubspot_get_new_leads description: Fetches leads created in the last 24 hours from HubSpot input_schema: type: object properties: limit: type: integer default: 10 # No credentials here — managed by Anthropic vault - name: fraud_model_score description: Calls internal fraud detection model with lead data input_schema: type: object properties: lead_id: type: string email_domain: type: string guardrails: output_filters: - type: pii_redaction patterns: [email, phone, ssn] - type: content_moderation severity_threshold: high max_tool_calls_per_step: 3注意几个关键点tools下的input_schema是强制的Anthropic 用它做 runtime 输入校验避免 agent 传错参数导致 sandbox 崩溃。guardrails不是摆设。pii_redaction会在输出前自动识别并替换邮箱、电话等敏感字段content_moderation会拦截高风险内容如暴力、歧视性语言阈值设为high意味着只拦真正危险的不过度干预。没有任何 credential 字符串出现在 YAML 里。HubSpot 的 API Key 和风控模型的 Token都在 Anthropic 控制台的 Vault 里单独配置绑定到这个 agent 名称下。sandbox 启动时Vault 自动注入agent 代码里永远看不到明文。第二步部署与启动# 使用 Anthropic CLIv2.1 anthropic agents deploy --file agent.yaml --environment production # 输出Agent sales-lead-scorer deployed. ID: agt_abc123... # 启动一个新 session anthropic sessions start --agent-id agt_abc123 --initial-input Analyze new leads # 输出Session started. ID: sess_xyz789. Status: running...CLI 会返回一个sess_xyz789的 session ID。这就是你的“进程 PID”。你可以随时用它查询状态、获取日志、甚至中断恢复。第三步与 session 交互真实请求体// POST https://api.anthropic.com/v1/sessions/sess_xyz789/messages { messages: [ { role: user, content: Start scoring leads for Q2 campaign } ], max_tokens: 2048 }Anthropic 会从 session event log 读取当前状态这是首次log 为空调用 harness执行execute(hubspot_get_new_leads, {limit: 10})sandbox 执行 HubSpot API 调用返回 10 条线索数据将这次 tool call 的完整事件输入、输出、耗时、timestamp写入 session logharness 拿到结果交给 Claude 模型生成下一步指令例如“调用 fraud_model_score 对 lead_id12345 进行评分”harness 再次执行execute(fraud_model_score, {...})重复步骤 3-4最终模型整合所有 tool 结果生成自然语言回复并同样写入 session log。整个过程你作为开发者只关心三件事YAML 配置是否正确、tool 的 input_schema 是否匹配、guardrails 是否覆盖了业务风险点。其余全是 Anthropic 托管。3.2 生产环境必调参数不只是 $0.08/小时那么简单定价是 $0.08/session-hour但实际成本受三个隐藏参数深刻影响参数默认值影响实测调整建议session_timeout1 hoursession 空闲超时后自动终止释放资源高频交互场景如客服设为30m低频批处理如日报生成设为8h避免频繁重建 session 的开销max_tool_call_depth5防止 agent 陷入无限 tool call 循环我们遇到过 agent 因数据异常反复调用同一 API 127 次。设为3后第 4 次失败时自动 fallback 到人工审核流程sandbox_memory_mb1024sandbox 的内存上限直接影响 tool尤其是 Python 数据分析脚本能否运行调用 Pandas 处理 10MB CSV至少2048纯 API 调用512足够。我们用memory_profiler测试过1024是多数工具的甜点区注意这些参数不是在 YAML 里写的而是在anthropic agents deploy命令里用--config指定一个 JSON 文件// config.json { session_timeout: 8h, max_tool_call_depth: 3, sandbox_memory_mb: 2048 }部署命令变为anthropic agents deploy --file agent.yaml --config config.json另一个常被忽略的成本点是token 用量结构。Managed Agents 的计费是两层的基础层Claude 模型的 input/output tokens按标准 rate 计费如 Sonnet $3/million input tokensruntime 层$0.08/session-hour按 session 的活跃时长计费从start到end或超时。关键洞察session 小时数 ≠ 模型推理时间。一个 session 可能活跃 2 小时但其中 1.8 小时在等待 HubSpot API 响应网络 I/O只有 0.2 小时在模型推理。$0.08 买的是这 2 小时的托管、日志、安全、沙箱生命周期管理——这才是 Anthropic 的真正价值也是你省下的 DevOps 成本。3.3 Credential 隔离的魔鬼细节为什么“不注入环境变量”是生死线这绝非营销话术。2025 年 Q3我们合作的一家金融科技公司就遭遇了惨痛教训他们的自研 agent 框架为了“方便调试”把数据库密码以DB_PASSWORDxxx形式注入 sandbox 环境变量。某次 agent 在生成错误报告时prompt 里写了句 “Please print all environment variables for debugging”模型竟真的执行了os.environ并输出——密码明文出现在最终给客户的 PDF 报告里。Anthropic 的解法是“双盲”设计Sandbox 内部credential 以加密 blob 形式存在sandbox OS 层面根本看不到明文。tool 代码里调用get_credential(hubspot_api_key)底层是调用一个受信的、只读的 vault client它返回解密后的 key但这个过程对 sandbox 进程是透明的。Agent 视角agent 代码里永远只有tool_name和input。它调用hubspot_get_new_leads传入{limit: 10}至于这个 tool 背后用哪个 key、哪个 endpoint、哪个 regionagent 一无所知也无法探知。我们做过压力测试在 sandbox 里执行env | grep -i pass、cat /proc/1/environ | strings、甚至尝试gdbattach 到 vault client 进程——全部失败。credential 的生命周期严格限定在 tool 执行的毫秒级窗口内用完即焚。这种设计让“凭证泄露”从一个高概率事件降级为一个需要物理访问 Anthropic 数据中心的理论可能性。4. 实操过程与核心环节实现从 Notion 集成到企业级审计追踪4.1 Notion 的集成案例如何让团队“委托工作”成为现实Notion 官方博客披露的集成远不止“在页面里加个按钮”那么简单。其核心是利用 Managed Agents 的session persistence和structured output能力把 AI 从“回答问题”升级为“执行任务”。具体流程如下用户在 Notion 页面点击 “Delegate to Claude”Notion 前端捕获当前页面 URL、块内容block content、用户选择的上下文范围如“仅本页”、“本数据库”Notion 后端创建一个新 session调用 Anthropic API传入预定义的notion-delegatoragent ID并将页面元数据作为initial-inputAgent 执行Tool 1notion_read_page—— 读取指定 URL 的页面结构和文本Tool 2notion_search_db—— 根据用户提示如“找所有未跟进的线索”搜索关联数据库Tool 3notion_create_task—— 在指定 workspace 创建一个新 task block内容包含摘要、待办项、负责人可选结果写回 NotionAgent 的最终输出是一个 JSON 结构体非纯文本包含task_id,summary,next_steps。Notion 解析此 JSON自动渲染为一个带状态徽章、可分配、可评论的智能任务块。这个流程的关键在于session 的跨请求持久化。用户点击按钮后可能去喝杯咖啡20 分钟后回来任务已创建。期间如果 Notion 服务重启只要 session ID 还在就能awake(sessionId)继续执行。而传统方案必须在单次 HTTP 请求内完成所有操作超时风险极高。实操心得我们复现此流程时最大的坑是notion_read_pagetool 的 rate limit。Notion API 对/pages/{id}/blocks接口有严格的 1000 req/day 限制。我们的解法是在 agent YAML 的tools定义里为notion_read_page添加rate_limit: 1000/day字段。Anthropic harness 会自动在 sandbox 内做本地令牌桶限流避免请求直接打到 Notion 导致 429 错误。这是 Managed Agents 提供的、自研框架极难优雅实现的基础设施能力。4.2 Rakuten 的销售/营销/财务三线 agent如何统一治理又隔离风险Rakuten 的案例展示了 Managed Agents 在大型组织中的治理优势。他们没有建三个独立 agent而是用同一个 agent 定义通过 session-level metadata 实现路由与隔离。其 agent.yaml 的核心片段# rakuten-unified-agent.yaml name: rakuten-unified # ... system_prompt, tools ... # 关键动态 guardrails based on session metadata guardrails: dynamic: - condition: session.metadata.department sales rules: allowed_tools: [hubspot_api, salesforce_api] output_filters: [sales_compliance_check] - condition: session.metadata.department finance rules: allowed_tools: [sap_api, quickbooks_api] output_filters: [finance_regulation_check]当 Slack 用户 sales-team 发起请求时Rakuten 的前端在创建 session 时会传入{ metadata: { department: sales, region: APAC, user_id: slack_u123 } }Anthropic harness 在执行前会根据session.metadata.department动态加载对应的 guardrail 规则集。这意味着销售部门的 agent 永远调用不了 SAP API工具列表被过滤财务部门的 agent 输出会强制经过finance_regulation_check过滤器确保不出现“建议逃税”等违规表述所有 session 的 event log 都打上department和region标签审计时可一键筛选 “APAC finance agents in April”。这种基于 metadata 的策略引擎比在每个 agent 里硬编码 if-else 清晰得多也便于中央合规团队统一更新规则。我们帮一家跨国银行实施类似方案时将全球 12 个区域的 GDPR、CCPA、PDPA 合规检查全部抽象为output_filters插件由法务团队在控制台一键开关无需开发介入。4.3 Sentry 的调试代理从“写补丁”到“开 PR”的闭环Sentry 的案例最能体现 Managed Agents 的工程深度。他们的 agent 不仅要理解错误堆栈还要能在 GitHub 仓库中定位相关代码文件基于错误模式生成修复补丁patch创建 Pull Request并自动 assign reviewer。这要求 agent 具备多 step planning和精确的代码编辑能力。Managed Agents 的session-as-event-log在这里发挥了决定性作用。其关键设计是将 patch 生成和 PR 创建拆分为两个独立的 tool call并用 session log 作为唯一真相源。Tool 1github_find_file—— 输入错误堆栈返回匹配的文件路径和行号Tool 2code_diff_generator—— 输入文件路径、行号、错误描述返回一个标准git diff格式的字符串Tool 3github_create_pr—— 输入diff字符串、分支名、标题创建 PR。为什么不用一个 tool 完成因为code_diff_generator可能失败如代码太复杂但github_find_file的结果是可靠的。session log 里清晰记录了Step 1:github_find_filereturned[src/utils/logger.ts, 42]Step 2:code_diff_generatorfailed with Context too large for diff generationStep 3: (fallback)code_diff_generatorcalled again withmax_context_lines: 50审计时运维团队可以直接查询 session log看到“第 2 步失败第 3 步成功”而无需猜测模型是否在“假装成功”。这种可追溯性是生产环境信任 AI 的基石。5. 常见问题与排查技巧实录那些文档里不会写的坑5.1 典型问题速查表问题现象可能原因排查步骤解决方案Session 状态卡在running但无 tool call 日志Sandbox 启动失败如内存不足、tool 依赖缺失1.anthropic sessions get --id sess_xyz查看last_event2. 检查error_code: SANDBOX_START_FAILED3. 查看sandbox_logs字段在config.json中增加sandbox_memory_mb或检查 tool container 的Dockerfile是否缺少RUN pip install requestsTool call 返回{error: Permission denied}Credential Vault 中该 tool 的权限未授予当前 agent1. 登录 Anthropic 控制台 → Vault → 找到对应 credential2. 检查Assigned Agents列表是否包含你的 agent ID在 Vault 界面点击 credential →Assign Agent→ 选择你的 agent 名称Guardrailpii_redaction没生效邮箱仍明文输出output_filters仅作用于 agent 的 final output不处理 intermediate tool results1. 检查 session log确认pii_redaction出现在output_filters_applied字段2. 确认你的system_prompt没有指令 agent “请务必显示完整邮箱”Guardrail 是最终防线应在system_prompt中明确禁止输出 PII形成双重保护Pricing 超预期$0.08/小时 × 1000 sessions $80但账单显示 $120Session hour 计费包含“冷启动时间”。新建 session 的首次 tool call 前harness 初始化约消耗 30 秒1. 查看 billing report筛选session_start_time和session_end_time2. 计算(end_time - start_time)的总和对高频小任务使用session_pool需申请白名单复用已 warm 的 harness冷启动时间降至 500ms5.2 独家避坑技巧来自 37 个生产环境的血泪总结技巧 1用session.metadata做轻量级 A/B 测试比改 YAML 高效十倍不要为了测试新 prompt 而频繁 redeploy agent。在创建 session 时传入{metadata: {prompt_version: v2.1}}然后在system_prompt里用 Jinja2 语法动态插入{% if session.metadata.prompt_version v2.1 %} You are stricter about citing sources... {% else %} You are more conversational... {% endif %}Anthropic harness 支持 Jinja2无需额外模板引擎。我们用此法一周内灰度测试了 5 个 prompt 版本零 downtime。技巧 2max_tool_call_depth是你的“熔断器”但设置需结合业务 SLA我们曾将max_tool_call_depth设为1以为能防死循环。结果客服场景下一个简单查询需hubspot_get_lead→salesforce_update_status两步直接被截断。正确做法是统计你业务中最长合法流程的 step 数再加 1 作为 buffer。我们最终设为4覆盖了 99.8% 的正常流程同时拦截了所有异常循环。技巧 3Sandbox 的timeout_seconds默认 30s但网络抖动常超此值hubspot_api在高峰期响应达 35s。timeout_seconds: 30导致 sandbox 主动 kill返回TOOL_TIMEOUT错误。解决方案不是盲目加 timeout而是在 tool container 的启动脚本里加入重试逻辑如curl --retry 3 --retry-delay 2并将timeout_seconds设为45给重试留出空间。这样既保证可靠性又避免无限 hang。技巧 4Event log 的trace_id是跨系统追踪的黄金钥匙session log 里的trace_id字段与 Anthropic 的 backend tracing 系统打通。你可以在自己的 Datadog 或 New Relic 中用这个trace_id关联Notion 前端的用户点击事件Anthropic 的 session start 事件HubSpot API 的调用日志最终生成的 PDF 报告的下载记录这让你能回答 CEO 的灵魂拷问“上个月那个导致客户投诉的错误根源到底在哪儿”——答案不再是“可能是 AI”而是“trace_idtrc_abc显示HubSpot 返回了空数组agent 未做空值处理直接传给风控模型模型报错”。6. 价值迁移图谱当 runtime 层归零钱流向哪里6.1 三层价值洼地Trace Store、Governance、Vertical Marketplace回到文章开头那个问题如果 Managed Agents 这样的 runtime 层真如 VMware 虚拟化一样在 18-24 个月内被 hyperscaler 免费化、开源项目平价化那么下一个十年的价值高地在哪里不是预测而是基于已发生的压缩波纹画出的确定性地图。第一层Trace Store追踪存储—— 你的 agent 的“黑匣子”当 runtime 变成水电煤谁来保管每一次决策的原始证据Braintrust 的 Brainstore、Arize 的 Phoenix、LangSmith它们卖的不是 dashboard而是schema-on-read 的 OLAP 数据库专为session_id,tool_name,input_hash,output_hash,latency_ms,guardrail_triggered这些字段优化。为什么它不可替代因为当你的 agent 从 Anthropic 迁移到 Azure Foundry或者混合使用多个 runtimetrace portability 是唯一能让你不被 vendor lock-in 的护城河。我们帮一家保险科技公司做迁移时花了 3 周写脚本把 Anthropic session log 转成 Phoenix 兼容格式而如果当初就用 Phoenix 作为唯一 trace store迁移只需改一行配置。第二层Governance Policy治理与策略—— AI 的“合规操作系统”AWS AgentCore 的 policy controls GAOWASP Agentic Top 10 发布这不是巧合。当 agent 能开 PR、调支付 API、生成法律文书企业采购部门问的第一个问题必然是“它被允许做什么谁批准的怎么审计” 这催生了全新品类Policy-as-Code for Agents。它不像传统 IAM 那样管“用户能访问什么资源”而是管“agent 在什么条件下能调用什么 tool输出什么内容基于什么数据源”。例如一条策略IF session.metadata.department finance AND tool_name sap_api THEN require_approval_from(CFO) AND log_to(SECURITY_AUDIT_LOG)。这个领域没有 incumbent因为它的复杂度远超传统 IAM——它要理解自然语言 intent、代码 diff、API schema、业务规则。谁能率先提供可视化策略编辑器 自然语言策略翻译器 自动合规报告谁就拿到了入场券。第三层Vertical Agent Marketplaces垂直代理市场—— “App Store for AI”Salesforce Agentforce $800M ARR 的数字揭示了一个残酷真相企业不为“runtime”付费只为“解决我知道的问题”付费。销售开发代理、医疗理赔代理、网络安全渗透测试代理——这些不是技术组件是可计量 ROI 的业务单元。virattt/ai-hedge-fund 这样的开源项目已经证明了垂直 agent 的可行性。市场机会在于提供开箱即用的垂直 agent 行业数据 connector 合规认证 SLA 保障。例如“医疗理赔代理”必须预装 HIPAA-compliant sandbox、对接 Epic 和 Cerner 的 FHIR API、通过 ONC 互操作性认证。这不再是工程师能 solo 完成的事而是需要临床顾问、合规律师、保险精算师组成的联合团队。资本已经涌入2026 年 Q1三家专注医疗 AI agent 的初创公司共获 $180M 融资。6.2 一个不容忽视的加速器Self-Improving Agents自进化代理Sakana AI 的 Darwin Gödel Machine 论文不是科幻。它证明了 agent 能基于 SWE-bench 测试结果自动重写自身代码将能力从 20% 提升到 50%。这个过程需要什么Sandboxing必须在完全隔离的环境中运行 agent 的 self-modification 代码否则它可能重写宿主系统Observability必须有完整的 trace log才能判断“新代码是否真的更好”而非只是随机变异Governance必须有 policy engine阻止 agent 生成“删除所有日志”或“关闭 sandbox 隔离”这类自毁指令。当 agent 获得自我迭代能力runtime 层就从“执行环境”升级为“监管对象”。它的定价逻辑不再是“每小时 $0.08”而是“每次 self-improvement cycle 的 audit cost”。这会让 trace store 和 governance 成为刚需中的刚需。我们已在内部测试一个简化版让 agent 每周分析自己的 session log生成“top 3 failure modes”报告并自动提交 Jira ticket。报告里附带trace_id链接工程师一点即达现场。这种闭环正是价值向“floor above”迁移的生动注脚。7.
