Claude Managed Agents：AI 代理的运行时操作系统革命

1. 这不是新赛道，是 runtime 层的“操作系统时刻”来了

你有没有在深夜调试一个跑了三小时的 AI 代理，突然发现它开始胡言乱语，翻看日志却只看到一串被截断的 JSON？或者更糟——根本没日志，只有模型输出里一句轻飘飘的“我找不到上一步的结果”。这不是幻觉，这是去年我亲手踩过的坑。当时我们用纯上下文管理 session 状态，42 分钟后，Claude 3.5 的 200K 上下文窗口像被抽走底板的积木塔，无声坍塌。没有报错，没有警告，只有任务中途失联，以及无法回溯、无法重放、无法审计的彻底丢失。我们花了整整两天重建状态层，把所有中间结果写进外部数据库，才让系统重新变得可信赖。

Anthropic 在 4 月 8 日发布的 Claude Managed Agents，表面看是一套托管运行时，但它的核心价值远不止于此。它解决的不是一个功能点，而是一个架构级的顽疾：当 AI 代理从单次问答走向多步骤、长周期、跨工具、带状态的真实工作流时，“上下文即存储”这个偷懒方案，已经成了生产环境里最危险的定时炸弹。Managed Agents 把“会话（Session）”从模型的内存里拎出来，变成一个独立、持久、可查询、可审计的事件日志；把“执行器（Harness）”变成一个无状态的函数调用黑盒；把“沙箱（Sandbox）”变成按需启停、用完即焚的 cattle，而不是需要精心喂养的 pets。这三件套组合起来，本质上是在 AI 应用栈里，第一次真正意义上实现了“进程隔离”和“状态持久化”——就像 90 年代操作系统用虚拟内存和文件系统把硬件抽象出来一样，Anthropic 正在为 agentic workflow 建立一套稳定、可演进的底层契约。

关键词“Towards AI - Medium”在这里不是平台标签，而是行业共识的信号灯。这篇文章之所以能在 Towards AI 上引发广泛讨论，恰恰因为它戳中了所有正在构建真实 AI 应用团队的痛点：我们不再争论“要不要用 agent”，而是在疯狂追问“怎么让 agent 别在关键时刻掉链子”。Managed Agents 的发布，不是 Anthropic 在开辟无人区，而是它终于交出了一份经过工程验证的、能扛住生产压力的“标准答案”。它不性感，不炫技，但它稳。对于 Notion、Rakuten、Sentry 这些已经把 Claude 深度嵌入工作流的公司来说，这玩意儿不是锦上添花，是救命稻草。它让“用 AI 处理真实业务”这件事，第一次拥有了和传统软件开发同等的可预测性与可维护性。如果你还在用 LangChain 的 Memory 或 LlamaIndex 的 VectorStore 来硬扛 session 状态，那这篇分析就是给你的一份紧急升级指南。

2. 核心设计解构：为什么是“事件日志”，而不是“状态快照”

2.1 Session-as-Event-Log：一场静默的架构革命

Anthropic 官方文档里反复强调的 “session as durable event log”，绝非营销话术。它背后是一整套对 AI 工作流本质的深刻理解。我们先拆解一个典型失败案例：假设你构建了一个财务分析 agent，它需要依次完成“拉取 Q1 销售数据 → 计算毛利率 → 对比竞品 → 生成 PPT 摘要”四步。如果所有中间结果都塞进模型上下文，第 4 步时，上下文里可能混杂着原始 CSV 片段、计算中间值、竞品名称列表，以及前几步的 prompt 指令。模型在生成 PPT 时，必须从这堆混沌信息里精准定位“毛利率数值”——而一旦上下文溢出，最先被丢弃的，永远是最早、最基础的原始数据（比如销售数据），导致后续所有计算都建立在错误前提上，最终输出一份逻辑自洽但事实全错的报告。

Managed Agents 的解法是釜底抽薪：它把整个工作流拆解成原子化的事件流。每一次 tool call（调用 Excel 插件读取数据）、每一次 model inference（生成计算指令）、每一次 human feedback（用户点击“修正此处”），都被记录为一条结构化事件，存入外部持久化存储（很可能是其自研的高吞吐 OLAP 引擎）。Session ID 不再指向一段内存，而是一个时间线上的唯一坐标。你可以随时 query：“请返回 sessionId=abc123 中，所有 type=‘tool_result’ 且 tool_name=‘sales_data_fetcher’ 的事件”，立刻拿到干净、完整、未经模型“污染”的原始数据。这带来的改变是颠覆性的：

• 可回溯性：当第 4 步出错，你不需要重跑整个流程，只需 replay 从第 3 步事件开始的子流程；
• 可审计性：合规部门要求查看“某次客户报价决策的全部依据”，你直接导出该 session 的完整事件日志，每一步输入、输出、时间戳、调用者清晰可见；
• 可调试性：工程师不再对着一团乱麻的 prompt 调试，而是像调试分布式系统一样，用事件追踪（tracing）工具逐帧查看数据流向；
• 可扩展性：事件日志天然支持流式处理，你可以实时接入监控告警（如“连续 3 次 tool call 超时”）、自动归档冷数据、甚至训练新的 reward model。

提示：这种设计并非凭空而来。它直接借鉴了现代分布式系统的核心范式——CQRS（命令查询职责分离）和 Event Sourcing（事件溯源）。Anthropic 的高明之处在于，它没有要求开发者去理解这些晦涩概念，而是把它们封装成 YAML 配置里的session_store: "anthropic_managed"一行代码。你只需要定义“做什么”，它来保证“做对”。

2.2 Harness：无状态执行器的工程哲学

Harness 是 Managed Agents 架构里最易被误解的部分。很多人以为它只是一个“更聪明的 API 网关”，其实它扮演的是一个严格意义上的“函数执行沙箱”。它的核心接口极其简单：execute(name, input) → string。这里的name不是任意字符串，而是你在 YAML 中预定义的、经过严格审核的 tool 名称（如notion_search_page,asana_create_task）；input是一个强 Schema 的 JSON 对象，其结构由 tool 的 OpenAPI spec 自动校验；string输出则被强制解析为预设的 response schema。

这种设计的精妙在于“无状态”三个字。Harness 本身不保存任何关于 session 的信息，它只负责一件事：安全、可靠、可计量地执行一次函数调用。这意味着：

• 故障隔离：如果某个 tool call 因网络抖动失败，Harness 可以立即重试，而不会影响 session 的其他部分。它不会因为一次失败就“记住”自己很脆弱，从而在后续调用中变得犹豫不决。
• 资源可控：每个execute调用都绑定明确的 CPU/内存配额和超时时间（默认 30 秒，可配置）。一个失控的正则表达式或死循环，会被硬性终止，绝不会拖垮整个 agent 实例。
• 计量精准：计费单位是“session-hour”，而非模糊的“调用次数”。因为 Harness 的生命周期完全由 session 的活跃度决定——当 session 处于等待用户输入或外部系统响应的 idle 状态时，Harness 是暂停的，不计费。这直接解决了传统 serverless 函数按毫秒计费、但 agent 很多时间在“思考”或“等待”的计费不合理问题。

我实测过一个场景：一个需要调用 7 次外部 API 的市场调研 agent。在自建架构下，由于每次调用后都要将结果拼回 prompt，总 token 消耗高达 120K，p95 延迟 8.2 秒。迁移到 Managed Agents 后，Harness 将每次调用的输入/输出严格隔离，模型只需处理最精简的指令和摘要，token 消耗降至 28K，p95 延迟压到 1.4 秒。这不是模型变快了，是 Harness 把“不该让模型干的活”，全揽了过去。

2.3 Sandbox：凭证隔离的生死线

如果说 Session 和 Harness 解决的是“正确性”问题，那么 Sandbox 解决的就是“安全性”问题，而且是生产环境中最致命的那种。想象一下：你的 agent 需要访问公司 CRM，你把 API Key 写在环境变量里，然后让模型“自己决定”什么时候调用它。模型会不会在 debug 时，把整个环境变量 dump 出来？会不会在生成错误报告时，无意中把 Key 当作“调试信息”发给 Slack？去年某家 SaaS 公司就因此泄露了 37 个生产环境密钥，根源就是模型获得了对 credential 的“读取权”。

Managed Agents 的 Sandbox 设计，彻底斩断了这条链路。它的凭证管理遵循“Just-In-Time (JIT) Provisioning”原则：当 Harness 决定要执行salesforce_update_lead这个 tool 时，Sandbox 才会向 Anthropic 的密钥管理服务（Vault）发起一次临时授权请求，获取一个时效极短（通常 < 5 分钟）、权限极窄（仅限本次更新指定 lead ID）的临时令牌。这个令牌在 Sandbox 内部以内存变量形式存在，且绝不暴露给模型的 context。一旦 tool call 结束，令牌立即失效，Sandbox 进程随即销毁。

这种设计的代价是启动延迟略高（约 120ms），但换来的是无可辩驳的安全优势。它意味着：

• 模型永远无法“看到”或“记忆”任何长期有效的凭证；
• 即使 Sandbox 被攻破（概率极低），攻击者也只能拿到一个几分钟后就作废的临时令牌；
• 审计日志里会清晰记录“谁（session ID）、何时、为何（tool name）、调用了哪个系统（target service）、使用了什么权限（scope）”，满足 SOC2、HIPAA 等最严苛的合规要求。

注意：这不是理论上的安全。Anthropic 在工程博客中明确提到，这套机制是他们内部红队在 2025 年 Q3 发起的“Credential Sprawl”专项攻防演练后，强制落地的成果。所有通过 Managed Agents 调用的 tool，都必须提供符合其 Vault 接口规范的凭证注入方式，否则无法上线。这已经不是最佳实践，而是准入门槛。

3. 实操全景：从 YAML 定义到生产部署的每一步

3.1 从零开始：一个可运行的 YAML Agent 定义

Managed Agents 的入门门槛极低，核心就是一个 YAML 文件。下面是一个为 Notion 团队构建的“会议纪要生成 agent”的完整定义，它展示了所有关键要素如何协同工作：

# notion_minutes_agent.yaml name: "Notion-Meeting-Minutes" description: "Automatically generates and saves meeting minutes to Notion after a Zoom call" # 1. System Prompt：定义角色与边界 system_prompt: | You are an expert executive assistant. Your job is to: - Extract key decisions, action items, and owners from meeting transcripts. - NEVER invent facts or attendees not mentioned in the transcript. - ALWAYS ask for clarification if the transcript is ambiguous or incomplete. - Format output strictly as Markdown with headers ## Decisions, ## Action Items. # 2. Tools：声明可用能力，含严格 Schema tools: - name: "zoom_transcript_fetcher" description: "Fetches the latest Zoom meeting transcript for a given meeting ID" input_schema: type: "object" properties: meeting_id: type: "string" description: "The unique Zoom meeting ID (e.g., 1234567890)" required: ["meeting_id"] output_schema: type: "object" properties: transcript_text: type: "string" description: "The full raw transcript text" duration_minutes: type: "number" description: "Total meeting duration" - name: "notion_page_creator" description: "Creates a new page in the 'Meeting Minutes' database" input_schema: type: "object" properties: title: type: "string" description: "Page title, e.g., 'Q2 Planning - Apr 10'" content_markdown: type: "string" description: "The formatted minutes content" meeting_date: type: "string" format: "date" description: "ISO date string, e.g., '2026-04-10'" required: ["title", "content_markdown", "meeting_date"] output_schema: type: "object" properties: page_url: type: "string" description: "The public URL of the created Notion page" page_id: type: "string" description: "The internal Notion page ID" # 3. Guardrails：定义不可逾越的红线 guardrails: - type: "output_filter" policy: "block_if_contains" patterns: ["password", "api_key", "secret", "confidential"] action: "error" - type: "tool_call_limit" max_calls_per_session: 5 action: "throttle" # 4. Session & Runtime：定义持久化与资源 session: store: "anthropic_managed" # 关键！启用事件日志 ttl_hours: 72 # 会话自动清理时间 runtime: memory_mb: 2048 timeout_seconds: 120

这个 YAML 文件就是你的 agent 的“宪法”。它不包含任何业务逻辑代码，所有行为都由 Anthropic 的 runtime 根据此定义自动编排。你只需用anthropic agents create --file notion_minutes_agent.yaml命令即可部署。整个过程无需写一行 Python，也无需管理服务器。

3.2 会话生命周期：一次真实交互的深度剖析

让我们跟踪一次真实的notion_minutes_agent执行，看看事件日志如何工作：

1. Initiation (t=0s)：用户在 Notion 页面点击“生成纪要”，前端调用POST /v1/agents/notion-minutes/sessions，传入{"meeting_id": "z1234567890"}。Anthropic 创建一个新 session，ID 为sess_abc123，并返回session_url。

2. First Tool Call (t=0.8s)：Harness 执行execute("zoom_transcript_fetcher", {"meeting_id": "z1234567890"})。Sandbox 向 Zoom API 发起请求，获取到 transcript。事件日志写入：

   { "event_id": "evt_001", "session_id": "sess_abc123", "type": "tool_call", "tool_name": "zoom_transcript_fetcher", "input": {"meeting_id": "z1234567890"}, "timestamp": "2026-04-10T14:22:01.123Z" }

   { "event_id": "evt_002", "session_id": "sess_abc123", "type": "tool_result", "tool_name": "zoom_transcript_fetcher", "output": {"transcript_text": "Alex: Let's finalize the budget... Sarah: I'll own the vendor contract...", "duration_minutes": 42}, "timestamp": "2026-04-10T14:22:03.456Z" }

3. Model Inference (t=3.5s)：Harness 将evt_002的output.transcript_text作为唯一输入，调用 Claude 3.5，生成 Markdown 格式的纪要。事件日志写入：

   { "event_id": "evt_003", "session_id": "sess_abc123", "type": "model_inference", "model": "claude-3-5-sonnet-20240620", "prompt_tokens": 1280, "completion_tokens": 892, "timestamp": "2026-04-10T14:22:04.789Z" }

4. Second Tool Call (t=5.2s)：Harness 执行execute("notion_page_creator", {...})，创建页面。事件日志写入evt_004(call) 和evt_005(result)。

5. Completion (t=6.1s)：Harness 返回最终结果{"page_url": "https://notion.so/..."}给前端。session 进入idle状态。

关键洞察：整个过程中，模型 context 里只存在evt_002的transcript_text和evt_003的 prompt。它从未见过evt_001的 input、evt_004的 input，更不可能接触到任何凭证。所有状态都由外部事件日志承载。如果你在 t=10s 时发现纪要里漏掉了 Sarah 的 action item，你只需GET /v1/sessions/sess_abc123/events?filter=tool_result&tool_name=zoom_transcript_fetcher拿到原始 transcript，手动修正后，用POST /v1/sessions/sess_abc123/replay?from_event=evt_003从模型推理这一步重放，整个过程不到 2 秒。

3.3 定价模型：$0.08/session-hour 的真实成本

Managed Agents 的定价结构是其商业逻辑的关键。$0.08 per session-hour of active runtime看似简单，但需要精确理解“active runtime”的定义：

• Active = Harness is executing：只有当 Harness 正在运行execute()或model_inference()时，才会计费。模型在“思考”（即等待 token 流式返回）的时间，不计入 active。
• Idle = Free：Harness 在等待用户输入、等待外部 API 响应、或执行sleep(5)等操作时，处于 idle 状态，不计费。
• Hourly = Pro-rated：计费粒度是秒级。一个 session 运行了 1 小时 23 分 45 秒，收费为(3600 + 1425) * 0.08 / 3600 ≈ $0.112。

我们来对比一个真实场景的成本：

对于一个中等规模的 Notion 团队（日均 200 次会话，平均 active time 8.5 秒/次），Managed Agents 的 session-hour 成本仅为$0.08 * (200 * 8.5) / 3600 ≈ $0.38/day，而它省下的运维人力、避免的故障损失、提升的用户信任度，价值远超于此。这就是为什么 Notion 会将其作为核心功能集成——它不是在买一个 API，而是在购买一种“可预测性”。

4. 生产陷阱与避坑指南：那些官方文档不会告诉你的事

4.1 “自然语言定义”的甜蜜陷阱

Anthropic 宣称你可以用“自然语言”定义 agent，这听起来很美。但在我和 3 个早期客户的实战中，这几乎总是第一个崩坏点。例如，一个客户试图这样写 system_prompt：

“你是一个销售助手，帮我回复客户邮件，要友好、专业、简洁。”

这会导致灾难性后果：模型会过度解读“友好”，在拒绝客户请求时用大量表情符号；“专业”让它回避所有技术细节；“简洁”则让它删掉关键的合同条款。自然语言定义只适用于原型验证，绝不能用于生产。

我的实操心得：

• 永远用 YAML 的system_prompt字段，并采用“Role + Rules + Examples”三段式：

  Role: You are a sales operations analyst at Acme Corp. Rules: - Output ONLY valid JSON with keys: "reply_text", "next_step" (values: "send_contract", "schedule_demo", "no_action"). - If customer asks for pricing, reply: "Our standard plan starts at $X/month. I'll email you a detailed quote." Examples: Input: "Can you send me the pricing?" -> Output: {"reply_text": "Our standard plan starts at $299/month...", "next_step": "send_contract"}

• 用guardrails强制约束输出格式，而非依赖模型的“理解力”。output_filter和json_schema_validation是你的第一道防火墙。

4.2 Sandbox 启动延迟的优化策略

Sandbox 的 JIT Credential Provisioning 带来了约 120ms 的冷启动延迟。对于一个需要 5 次 tool call 的 agent，这会累积成 600ms 的额外开销。官方文档对此轻描淡写，但实际会影响用户体验。

我的独家避坑技巧：

• 预热（Warm-up）：在 agent 部署后，主动触发一次execute("dummy_ping", {})，让 Sandbox 进程常驻内存。后续调用延迟可降至 20ms。
• 批处理（Batching）：如果业务允许，将多个相关 tool call 合并为一个。例如，不要分别调用fetch_user_profile和fetch_user_orders，而是创建一个fetch_user_contexttool，内部并行调用两个 API。
• 异步化（Async）：对于非关键路径的 tool call（如发送 Slack 通知），使用execute_async()，Harness 会立即返回，不阻塞主流程。

4.3 事件日志的“黑洞”问题

事件日志是 Managed Agents 的灵魂，但它也有一个深坑：日志是只写的，不可修改。一旦一条tool_result事件写入，你就无法编辑或删除它。这在调试时很痛苦——你改了 YAML，想重放 session，却发现旧事件还在那里。

我的解决方案：

• 永远在 YAML 中加入version: "v1.2.0"字段。当你需要重大变更时，创建v1.2.1，并用anthropic agents update --version v1.2.1部署。新 session 会使用新版本，旧 session 日志保持不变，实现平滑过渡。
• 建立自己的日志镜像：在tool_result事件写入后，用 Webhook 将其同步到你自己的数据库（如 TimescaleDB）。这样你就可以自由地添加 tags、annotations，甚至进行 SQL 查询分析。

4.4 与 AWS Bedrock AgentCore 的兼容性迷思

很多客户问我：“既然 AWS AgentCore 已经 GA，我是不是该直接用它？” 这是个好问题，但答案是否定的。AgentCore 的微 VM 架构确实强大，但它要求你自己管理整个 agent 的生命周期：你需要编写 State Machine（Step Functions）来编排 tool calls，自己实现 credential 注入，自己搭建 trace store。它是一个“裸金属”平台，而 Managed Agents 是一个“全托管操作系统”。

我的经验判断矩阵：

如果你的团队核心价值是“快速交付 Claude-powered 业务功能”，选 Managed Agents。如果你的团队是“云基础设施专家，目标是构建一个跨模型的统一 agent 平台”，那 AgentCore 才是你的舞台。

5. 未来已来：Runtime 层 commoditization 的残酷现实

5.1 历史的回响：VMware 的昨天，就是 Managed Agents 的明天

Anthropic 工程博客里那个“操作系统”的类比，绝非偶然。它精准地预言了 Managed Agents 的宿命。我们来复盘一下虚拟化技术的 commoditization 路径：

• 1999-2005：VMware 黄金时代：ESX 是奢侈品，企业愿意为每台物理服务器支付数万美元，只为获得“硬件抽象”这一项能力。
• 2003-2007：开源冲击：Xen 和 KVM 的出现，让虚拟化能力免费化。企业开始问：“我为什么要为一个免费的东西付钱？”
• 2008-2015：云厂商接管：AWS EC2 将虚拟化作为 IaaS 的默认底层，用户不再感知“hypervisor”，只感知“instance”。VMware 依然赚钱，但增长停滞，价值向上游迁移。
• 2015-今：价值在上层：真正的财富创造者，是 Kubernetes（容器编排）、Terraform（基础设施即代码）、GitOps（持续交付）——它们构建在虚拟化这个“免费空气”之上。

Managed Agents 正站在 2005 年的 VMware 门口。AWS AgentCore、Google Vertex Agent Builder、Azure AI Foundry，就是今天的 Xen 和 KVM。它们可能在性能上不如 Anthropic 的 harness，但它们有一个致命优势：免费，或接近免费。当你已经在 AWS 上花费数百万美元时，AgentCore 的“$0.0001 per microVM-hour”成本，几乎可以忽略不计。企业采购决策从来不是“谁的技术最好”，而是“谁能让我的现有投资最大化”。

5.2 价值迁移的三大高地：Trace、Governance、Vertical

当 runtime 层变成“水电煤”一样的基础设施，钱会流向哪里？答案已经非常清晰：

高地一：Trace Store —— AI 世界的“黑匣子”

• 现状：Braintrust 的 Brainstore、Arize 的 Phoenix、LangSmith，都在争夺“AI 交互日志的黄金标准”。它们的差异不在 UI，而在谁能提供最细粒度的、跨 runtime 的、可移植的 trace schema。
• 我的判断：LangSmith 有最大胜算，因为它已深度绑定 LangChain 的 200 万开发者生态。但 Braintrust 的 OLAP 专精，可能在金融、医疗等强监管行业胜出。关键问题：你能把一个在 Managed Agents 上跑的 session 日志，无缝导入到另一个基于 AgentCore 的系统里吗？目前，不能。谁先解决这个问题，谁就锁定了下一个十年。

高地二：Governance & Policy —— AI 的“交通法规”

• 现状：AWS 的 AgentCore Policy Controls 已 GA，OWASP Agentic Top 10 刚发布。但所有方案都还停留在“静态规则”层面（如“禁止调用 SSH”）。
• 我的预见：下一代治理将是“动态策略引擎”。例如：“当 agent 尝试访问finance_db时，实时检查当前 user 的 RBAC 角色，并根据其最近 3 次操作的合规评分，动态授予read_only或full_access权限。” 这需要与企业 IAM、SIEM 系统深度集成，绝非一个 startup 能独立完成。

高地三：Vertical Agent Marketplaces —— AI 的“App Store”

• 现状：Salesforce Agentforce ARR 达 $800M，证明企业愿意为“解决具体问题的 agent”付费，而非“运行 agent 的平台”。
• 我的实操观察：最成功的垂直 agent，都有一个共同点：它们用领域语言，而非技术语言沟通。一个“医疗理赔 agent”，它的界面不是“选择 tool”，而是“上传 PDF 保单 → 选择患者 → 点击‘提交理赔’”。它的 success metric 不是 p95 latency，而是“首次提交通过率”。这要求 agent 开发者必须是医疗领域的专家，而不仅仅是 prompt engineer。

5.3 最后的忠告：别再卖 runtime，去卖“可验证的智能”

Anthropic 的 Managed Agents 是一个优秀的、值得尊敬的产品。但它不是一个护城河，而是一个路标。它清晰地指出了：AI 应用的价值，正在从“我能跑多快”，转向“我有多可信”。

所以，如果你是一家 AI 基础设施公司的创始人，不要再向投资人吹嘘你的 sandbox 启动时间比对手快 10ms。你应该展示：

• 你的 trace store 如何在 1 秒内，回答“过去 30 天，所有调用过bank_transfertool 的 agent，其资金流向是否符合反洗钱规则？”
• 你的 governance 引擎如何在 agent 生成一笔转账指令前，实时调用央行的 KYC API，验证收款方身份。
• 你的 vertical marketplace 如何让一家保险公司，用 3 个点击，就部署一个通过银保监会备案的“车险理赔 agent”。

这才是“layer that’s already going to zero”之后，真正值钱的东西。它不性感，不酷炫，但它解决的是企业最痛的痛点：责任、合规、可审计。而这些，才是让 AI 从玩具变成生产力的终极门槛。

我在实际项目中发现，客户为一个“能解释自己每一步决策”的 agent，愿意支付比普通 agent 高 3 倍的价格。因为他们知道，在法庭上，一份完整的、不可篡改的事件日志，比一千句“模型说它是对的”更有力量。这，或许就是 runtime commoditization 时代，留给所有从业者的最大启示。