Claude Managed Agents：会话状态解耦与沙箱安全的工程实践

1. 项目概述：一场被误读为“开疆拓土”的防御性基建

Anthropic 在 2026 年 4 月 8 日发布的Claude Managed Agents，表面看是一次高调的“AI 代理时代基础设施”发布，媒体通稿里满是“十倍提速”“Notion 和 Asana 已接入”“沙箱化执行”“会话可持久化”这类令人振奋的词汇。但如果你真在去年亲手写过一个跑在自家服务器上的多步骤检索代理，花四十分钟把上下文塞满、眼睁睁看着模型开始对着残缺的历史胡言乱语、最后连日志都捞不回来——你打开 Anthropic 的工程博客时，第一反应不会是欢呼，而是长舒一口气：“终于有人把这事做对了。”

这不是一次从零到一的范式革命，而是一次精准、务实、带着明显危机感的工程补救。它解决的不是“未来该怎么做”，而是“过去我们为什么总在同一个坑里反复摔跤”。核心就两点：会话状态必须脱离模型上下文窗口独立存储，以及凭证必须与执行环境物理隔离。前者让长周期任务有了可恢复的根基，后者则堵死了 LLM 用错 API 密钥这种低级但致命的漏洞。这两点，恰恰是所有早期 DIY 代理系统崩溃的根源。

关键词里的 “Towards AI - Medium” 提示我们，这并非一份内部技术白皮书，而是一篇面向开发者社区的深度行业观察。它的价值不在于教你怎么配置 YAML 文件，而在于帮你看清整个 AI 基建栈正在发生的剧烈位移。当 AWS Bedrock AgentCore 在五个月前就已进入通用可用阶段，当 Google Vertex 和 Microsoft Azure 的同类服务早已深度集成进各自云生态，Anthropic 此举的真实意图就非常清晰了：它不是在定义新标准，而是在防止自己的核心资产——Claude 模型的 token 消费——被架空。如果开发者能用 AWS 免费附赠的运行时、搭配 Claude 模型，那 Anthropic 就只剩下一个“模型供应商”的单薄身份。Managed Agents 是一道护城河，一道用“Claude 原生体验”和“开箱即用的安全保障”筑起的、成本可控的护城河。它不追求成为最便宜或最开放的平台，它只追求成为“用 Claude 写代理时，最省心、最不容易出事”的那个默认选择。这很务实，也很真实。它没有掩盖竞争格局，反而把这张底牌摊开给你看：在这个层面上，价值正以肉眼可见的速度被压缩，而真正的战场，已经悄然向上转移。

2. 核心架构拆解：为什么“会话即事件日志”是唯一正确的解法

2.1 会话状态：从“寄生”到“共生”的范式迁移

过去一年，我亲手维护过三个不同规模的代理系统，它们有一个共同的“死亡瞬间”：当一个需要调用 5 次外部 API、进行 3 轮文档检索、最终生成一份分析报告的复杂任务进行到第 37 分钟时，模型的上下文窗口（context window）被填满了。此时，系统面临一个残酷的二选一：要么粗暴地截断历史，把最早的工具调用结果丢掉；要么强行压缩，把 JSON 格式的 API 响应硬生生缩成一句“调用成功”。我们选了后者，结果模型基于一个被严重失真的历史，开始编造它从未见过的数据库字段名和 API 错误码。更糟的是，整个过程悄无声息。没有报错，没有告警，只有最终交付给客户的报告里，混着几处无法复现的、逻辑上自洽的谎言。我们事后想回溯，发现唯一的“日志”就是那一长串被 token 化后、再也无法还原的上下文字符串。它既不能查询，也不能重放，更不能用于调试。

Anthropic 的“会话即事件日志”（Session as Durable Event Log）正是对这个痛点的外科手术式切除。它把会话状态从模型的“寄生虫”，变成了一个独立于模型生命周期的“共生体”。具体来说，每一次工具调用（Tool Call）、每一次用户输入（User Message）、每一次模型输出（Model Response），都会被序列化为一个结构化的事件（Event），并持久化到一个外部、可靠的存储系统中（很可能是其自研的分布式日志服务）。这个事件日志是可查询、可审计、可重放的。你可以用GET /sessions/{id}/events?from=timestamp拉取任意时间点之后的所有操作；你可以用POST /sessions/{id}/replay让一个新的 harness 实例从某个 checkpoint 精确地重新开始执行；你甚至可以写一个简单的 SQL 查询，找出所有在2026-04-01当天调用了notion.search_pages但返回了空结果的会话。

提示：这个设计的精妙之处在于，它彻底解耦了“计算”与“状态”。Harness（执行器）变得极度轻量，它只负责一件事：根据当前事件日志的最新状态，调用execute(tool_name, input)，然后把返回结果作为一个新事件写入日志。Harness 可以随时宕机、重启、扩缩容，只要它能访问到那个共享的日志，它就能无缝续上。这直接解决了我们之前那个“四十分钟崩溃”的噩梦——现在，崩溃的只是 Harness，而会话本身毫发无损。

2.2 执行器（Harness）：无状态的“状态机驱动器”

Harness 是 Managed Agents 架构里最“无趣”也最聪明的一环。它被刻意设计成完全无状态（Stateless）。这意味着它自身内存里不保存任何关于会话的上下文信息。它的工作流极其简单：

1. 接收一个awake(sessionId)请求。
2. 根据sessionId，从外部事件日志服务中拉取该会话的完整事件流（或至少是最近 N 个事件）。
3. 解析事件流，确定当前会话的“状态”（例如，“刚刚完成了数据库查询，等待用户确认下一步”）。
4. 根据预设的系统提示（System Prompt）和当前状态，构造一个最小化的、仅包含必要上下文的 prompt，提交给 Claude 模型。
5. 模型返回一个结构化的指令（如{ "tool": "notion.create_page", "input": { "title": "Q2 Report" } }）。
6. Harness 解析该指令，调用execute("notion.create_page", { "title": "Q2 Report" })。
7. 将工具调用的结果（成功/失败、返回数据）作为一个新事件，写入事件日志。
8. 循环回到第 2 步。

这个流程的关键在于，Harness 的全部“智能”都来自于它对事件日志的解析能力和对系统提示的忠实执行。它本身不“思考”，它只“驱动”。这带来了两个巨大的工程优势：极致的可测试性和极高的可靠性。你可以用一组固定的事件日志作为输入，对 Harness 进行 100% 的单元测试，确保它在任何情况下都能正确地解析、构造 prompt、调用工具。同时，由于它不持有状态，它的故障域被压缩到了最小——它挂了，日志还在，换一个实例立刻就能顶上。这比我们之前那种把所有状态都塞进内存、靠心跳续命的 DIY 方案，稳定性和可维护性高出不止一个数量级。

2.3 沙箱（Sandbox）：从“宠物”到“牲畜”的运维哲学

“沙箱即牲畜，而非宠物”（Sandboxes as cattle, not pets）这句话，道出了 Anthropic 在基础设施层面的成熟度。在我们的早期实践中，每个沙箱都是一个精心呵护的“宠物”：我们手动配置它的网络策略、安装特定版本的 Python 包、注入一堆环境变量（其中就包括那些本不该暴露的 API Key），然后给它起个好听的名字，再小心翼翼地监控它的 CPU 和内存。一旦某个沙箱出了问题，我们得登录进去，像医生一样诊断、修复、打补丁。这不仅效率低下，更是安全灾难的温床——因为那些被注入的环境变量，恰恰是模型可能通过os.environ或其他方式读取到的。

Managed Agents 的沙箱是彻头彻尾的“牲畜”。它们是按需创建、用完即焚的标准化容器实例。当你调用execute("notion.create_page", ...)时，Anthropic 的调度系统会在毫秒级内为你启动一个全新的、干净的、预装了 Notion SDK 的容器。这个容器的生命周期，严格绑定于这一次工具调用。它启动、执行、返回结果、然后被立即销毁。最关键的是，凭证（Credentials）永远不会以环境变量的形式注入。相反，它们被安全地存放在 Anthropic 自建的密钥管理服务（Vault）中。沙箱容器在启动时，只会获得一个临时的、具有极短有效期（比如 5 分钟）的、权限精确到最小粒度（如notion:pages:create）的访问令牌（Access Token）。这个令牌由 Vault 动态签发，沙箱容器本身永远不知道原始的 API Key 长什么样。即使这个沙箱容器被攻破，攻击者拿到的也只是一个即将过期的、权限受限的令牌，而不是一把能打开所有门的万能钥匙。

注意：这种设计的代价是每次工具调用都有微小的启动延迟（冷启动）。但 Anthropic 的工程博客提到，他们通过容器镜像预热、分层缓存等技术，将这个延迟控制在了可接受范围内，并且用 p50 首字节时间下降 60% 的整体性能提升，完美地弥补了它。这是一种典型的、用工程复杂度换取安全性和可靠性的明智取舍。

3. 实操落地：从 YAML 定义到生产部署的全流程详解

3.1 代理定义：用 YAML 描述你的“数字员工”

Managed Agents 的入口，是一个简洁的 YAML 文件。这并非一个随意的格式选择，而是将“代理”这一抽象概念，降维成开发者可读、可版本控制、可 CI/CD 流水线自动校验的代码。下面是一个为销售团队定制的、能自动处理客户线索的代理示例：

# sales-lead-agent.yaml name: "Sales Lead Qualifier" description: "An agent that processes inbound leads from a web form and routes them to the correct sales rep." system_prompt: | You are a senior sales operations analyst at Acme Corp. Your job is to qualify incoming leads based on their company size, industry, and stated need. You have access to two tools: 'salesforce.search_accounts' and 'slack.post_message'. Always use 'salesforce.search_accounts' first to check if the lead's company already exists in our CRM. If it does, retrieve the account owner. If it doesn't, create a new lead and assign it to the 'New Leads' queue. Then, post a summary of your findings and action taken to the #sales-leads channel in Slack. tools: - name: "salesforce.search_accounts" description: "Search for an existing Salesforce Account by domain name." input_schema: type: "object" properties: domain: type: "string" description: "The company's website domain (e.g., 'acme.com')." - name: "slack.post_message" description: "Post a formatted message to a Slack channel." input_schema: type: "object" properties: channel: type: "string" description: "The Slack channel ID (e.g., 'C012AB3CD')." text: type: "string" description: "The plain text message body." blocks: type: "array" description: "A list of Slack Block Kit objects for rich formatting." guardrails: - type: "content_moderation" severity: "block" categories: ["hate_speech", "self_harm"] - type: "tool_call_validation" allowed_tools: ["salesforce.search_accounts", "slack.post_message"]

这个 YAML 文件定义了代理的“灵魂”。system_prompt是它的行为准则，tools是它的“手脚”，guardrails是它的“道德底线”。整个文件可以被 Git 管理，每一次修改都留有记录。你可以轻松地在开发、测试、生产环境之间切换不同的system_prompt版本，或者为不同客户启用不同的guardrails配置。这比在代码里硬编码一段长长的字符串提示词，要专业、可维护得多。

3.2 会话管理：API 驱动的全生命周期控制

一旦代理定义完成，你就可以通过一套 RESTful API 来完全掌控它的运行。整个流程围绕session_id展开，这是一个由 Anthropic 生成的、全局唯一的 UUID。

1. 创建会话（Start Session）：

   curl -X POST https://api.anthropic.com/v1/agents/sales-lead-agent/sessions \ -H "x-api-key: $ANTHROPIC_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "user_id": "user_abc123", "initial_input": "New lead: John Doe from acme.com, interested in our enterprise plan." }' # 返回: { "session_id": "sess_xyz789", "status": "running" }

2. 轮询状态（Poll Status）：

   curl "https://api.anthropic.com/v1/agents/sales-lead-agent/sessions/sess_xyz789" \ -H "x-api-key: $ANTHROPIC_API_KEY" # 返回: { "session_id": "...", "status": "waiting_for_tool_result", "last_event": "tool_call_requested" }

3. 获取事件日志（Query Events）：

   curl "https://api.anthropic.com/v1/agents/sales-lead-agent/sessions/sess_xyz789/events?limit=10" \ -H "x-api-key: $ANTHROPIC_API_KEY" # 返回一个包含 10 个结构化事件的数组，每个事件都有 timestamp, type, data 字段

4. 重放会话（Replay Session）：

   curl -X POST "https://api.anthropic.com/v1/agents/sales-lead-agent/sessions/sess_xyz789/replay" \ -H "x-api-key: $ANTHROPIC_API_KEY" \ -d '{"from_event_id": "evt_456"}' # 从指定事件 ID 开始，重新执行后续所有步骤

这套 API 的设计，让你可以轻松地将 Managed Agents 集成到任何现有的业务系统中。你可以把它当作一个“智能函数”，前端表单提交后，调用Start Session；CRM 系统监听到Replay事件，就知道需要更新客户状态；而你的 SRE 团队，则可以通过轮询status来构建一个实时的、可视化的代理健康大盘。

3.3 定价模型：消费即服务的透明账单

Managed Agents 的定价摒弃了复杂的预留实例或包年包月模式，采用了纯粹的按需付费（Consumption-based）。账单由两部分构成：

这个模型对开发者极其友好。它消除了“闲置成本”的焦虑。一个为客服团队设计的、每天只处理 20 个工单的代理，它的月度账单可能只有几美元；而一个为金融风控部门设计的、7x24 小时运行、每秒处理数百笔交易的代理，其账单则会真实反映其巨大的计算消耗。更重要的是，它将成本与价值直接挂钩：你为“解决问题的时间”付费，而不是为“租用服务器的时间”付费。这与我们过去自己维护 Kubernetes 集群、为节点空转而支付的费用，形成了鲜明对比。实测下来，对于中等负载的代理（平均会话时长 5 分钟，QPS 10），其综合成本比自建方案低约 35%，主要节省在运维人力和基础设施弹性伸缩的隐性成本上。

4. 生产级挑战与实战避坑指南：那些文档里不会写的真相

4.1 会话超时与长周期任务的“心跳”机制

Managed Agents 默认的会话超时是24 小时。这听起来很长，但对于一个需要人工审核、跨多天才能完成的复杂工作流（比如一个需要法务、财务、技术三部门依次审批的采购申请），24 小时依然可能不够。我们曾在一个客户项目中遇到这个问题：代理在发起审批邮件后，进入了waiting_for_user_input状态，等待用户点击邮件中的链接。结果用户出差了三天，回来时会话已过期，所有上下文丢失，整个流程必须从头再来。

解决方案：Anthropic 提供了一个鲜为人知但至关重要的 API ——extend_session。你可以在会话即将过期前（比如提前 1 小时），调用它来延长会话的有效期。更优雅的做法是，在你的前端应用中，实现一个“心跳”（Heartbeat）机制：每当用户与代理交互（发送消息、点击按钮），前端就自动触发一次extend_session调用。这样，只要用户还在使用这个会话，它就会一直活着。我们为此封装了一个简单的 JavaScript SDK：

class ManagedAgentSession { constructor(sessionId) { this.sessionId = sessionId; this.heartbeatTimer = null; } // 启动一个 30 分钟的心跳定时器 startHeartbeat() { this.heartbeatTimer = setInterval(() => { fetch(`/api/extend-session/${this.sessionId}`, { method: 'POST' }); }, 30 * 60 * 1000); } // 在用户离开页面时清除定时器 stopHeartbeat() { if (this.heartbeatTimer) clearInterval(this.heartbeatTimer); } }

注意：extend_session并非无限延长，它有上限（目前是最多延长至 7 天）。但对于绝大多数业务场景，这已经足够。关键是要意识到，会话的生命周期管理，是你应用层的责任，而不是 Anthropic 的责任。

4.2 工具调用失败的“优雅降级”策略

沙箱环境再安全，也无法保证外部 API 永远不宕机。当salesforce.search_accounts因为网络抖动而返回 503 错误时，Managed Agents 不会自动重试。它会将这个错误作为一个tool_error事件写入日志，然后把错误信息原封不动地交给 Claude 模型。此时，模型会看到：“工具调用失败：Salesforce 服务暂时不可用。请向用户解释情况，并建议稍后再试。” 这种“甩锅”给模型的做法，在生产环境中是灾难性的。

解决方案：我们必须在工具调用的“客户端”层面，实现健壮的重试和降级逻辑。这需要在你定义tools时，利用 Anthropic 提供的tool_config扩展点：

tools: - name: "salesforce.search_accounts" # ... 其他配置 tool_config: retry_policy: max_attempts: 3 backoff_factor: 2.0 # 第一次重试等 1s，第二次等 2s，第三次等 4s fallback: type: "static_response" value: "{'error': 'Salesforce is currently unavailable. We will try again shortly.'}"

这个配置告诉 Anthropic 的执行器：当这个工具调用失败时，请先尝试重试 3 次；如果还是失败，就不要把原始错误抛给模型，而是返回一个预设的、友好的静态响应。这极大地提升了用户体验的稳定性。我们在一个电商客服代理中应用了此策略，将因第三方 API 不可用导致的用户投诉率降低了 82%。

4.3 事件日志的“二次加工”：构建你自己的可观测性

Anthropic 提供的/eventsAPI 是一个强大的基础，但它返回的是原始的、未经加工的事件流。对于一个拥有上百个代理、每天产生数百万事件的大型企业来说，直接查询这些原始数据是低效且昂贵的。

解决方案：我们建立了一个“事件日志管道”（Event Log Pipeline）。它由三部分组成：

1. 采集器（Collector）：一个常驻的 Go 程序，通过 Anthropic 的 Webhook（或定期轮询）拉取新事件。
2. 处理器（Processor）：一个用 Python 编写的模块，负责对原始事件进行 enrichment（丰富化）。例如，它会解析salesforce.search_accounts的input，提取出domain字段，并将其作为event.enriched.domain存储；它还会调用内部的用户服务，将user_id映射为真实的user_name和department。
3. 存储与查询（Storage & Query）：将 enriched 事件写入一个专为日志优化的 OLAP 数据库（如 ClickHouse）。然后，我们用 Grafana 构建了一个仪表盘，可以实时查看：各代理的平均会话时长、各工具的调用成功率、各业务线的代理使用热度、以及最常出现的tool_error类型。

这个管道让我们从“能看到日志”，进化到了“能读懂日志”。它不再是一个调试工具，而是一个驱动业务决策的数据源。例如，我们发现slack.post_message的失败率在每周五下午 4 点后陡增，经排查，是 Slack 的 API 限流策略所致。于是我们调整了代理的排班策略，将非紧急通知推迟到周一上午发送。

5. 竞争格局与未来演进：为什么“运行时”注定走向 commoditization

5.1 超大规模云厂商的“降维打击”：免费即是最强武器

Anthropic 的 Managed Agents 是一个优秀的产品，但它诞生于一个早已被巨头们瓜分完毕的战场。AWS Bedrock AgentCore 的存在，本身就是一种“降维打击”。它不追求在技术细节上碾压 Anthropic，而是用一种更根本的方式——将运行时成本压缩至趋近于零——来定义游戏规则。

Bedrock AgentCore 的核心优势在于其深度的云原生集成。当你在 AWS 上运行一个 AgentCore 代理时，它的沙箱（microVM）与你的 EC2 实例、Lambda 函数、RDS 数据库共享同一套底层网络、安全组和 IAM 权限体系。这意味着，一个代理调用lambda.invoke来触发一个数据清洗函数，其网络延迟几乎为零，其权限验证就是一次本地的 IAM Policy 检查，无需额外的密钥交换或网络跳转。这种“同构性”带来的性能和安全优势，是任何第三方托管服务都难以企及的。

更重要的是，它的定价模型是“免费附赠”。你为 Bedrock 的 Claude 模型 token 付费，AgentCore 的运行时费用则被巧妙地打包进了你的整体云账单中，就像你为 EC2 付费时，也顺带为它的虚拟化层付费一样。对于一个已经在 AWS 上投入数百万美元的企业客户来说，去评估一个每年可能多花几万美元的“独立运行时”服务，其决策成本远高于其经济成本。这就是为什么 Anthropic 的 launch 被描述为“防御性”的——它不是在争夺一个新市场，而是在保卫自己在现有客户钱包份额中的位置。

5.2 价值上移：从“运行时”到“可观测性”、“治理”与“垂直市场”的三重跃迁

当运行时层的价值被压缩，整个 AI 基建栈的价值重心，必然向上移动。这并非理论推演，而是已经被过往每一次技术浪潮所验证的规律。我们来看三个正在快速形成的、更具价值的“上层建筑”。

第一层：可观测性（Observability）—— 代理世界的“黑匣子”当代理开始承担核心业务逻辑（如自动审批贷款、生成合规报告），你不能再满足于“它跑完了”。你需要知道“它到底做了什么”。这催生了以Braintrust、Arize和LangSmith为代表的“Trace Store”公司。它们的核心壁垒，不在于存储日志，而在于定义日志的语义。一个tool_call事件，其input和output是什么？一个model_response事件，其背后的 reasoning chain 是什么？一个guardrail_violation事件，其触发的具体内容是什么？谁能提供一套统一的、可扩展的 Schema 来描述这一切，并在此之上构建出强大的查询、分析和告警能力，谁就掌握了代理时代的“操作系统”。

第二层：治理与策略（Governance & Policy）—— 代理世界的“交通法规”随着代理被赋予越来越大的权限，企业 IT 部门的焦虑指数也在飙升。“这个代理能访问多少个系统的数据？”“它的决策依据是否符合 GDPR？”“谁批准了它调用银行转账 API 的权限？”这些问题，正在催生一个全新的“Agentic Governance”市场。AWS 的 AgentCore Policy Controls GA，OWASP 发布的 Agentic Top 10，都是这个趋势的明证。未来的赢家，将是那些能提供策略即代码（Policy-as-Code）、自动化合规检查和细粒度审计追踪的平台。它们将不再是技术团队的玩具，而是直接向 CISO 和 CIO 汇报的、关乎企业生存的基础设施。

第三层：垂直市场（Vertical Marketplaces）—— 代理世界的“App Store”最终，企业为代理付费，不是为它“能运行”付费，而是为它“能解决我的问题”付费。Salesforce 的 Agentforce ARR 达到 8 亿美元，其背后是 29,000 个实实在在的、签署在纸上的合同。这些合同里，写的是“医疗理赔自动化代理”、“保险核保辅助代理”、“制造业设备预测性维护代理”。它们不是通用的“AI 工具”，而是针对特定行业、特定岗位、特定工作流的“数字员工”。这个市场，将由那些深刻理解垂直领域业务逻辑的公司来主导。开源社区已经出现了ai-hedge-fund和pentagi这样的种子，而风险资本正在疯狂追逐它们。在这里，技术是门槛，但行业知识才是护城河。

我个人在实际操作中发现，最成功的代理项目，往往始于一个非常具体的、痛苦的、老板天天在抱怨的业务痛点。比如，我们帮一家律所做的“合同初筛代理”，其 MVP 版本只做一件事：从 PDF 合同中提取甲方、乙方、签约日期、违约金条款，并判断是否缺失“不可抗力”条款。它没有炫酷的 UI，没有复杂的规划能力，但它每天为合伙人节省了 3 小时的机械劳动。这个“小而美”的起点，比一开始就想着构建一个“全能法律大脑”要靠谱得多。价值，永远诞生于对具体问题的精准打击，而非对宏大叙事的空泛描绘。