我是 Lena。读完那篇 Managed Agents 架构博客之后，我在屏幕上把 Anthropic 的 engineering blog 挂了好一会儿。不是因为我急着要去试——更多是因为它的那个框架，把我的预期打断了。
他们把 agent 基础设施类比成操作系统。操作系统把硬件虚拟化成 process、file、socket 这些抽象——这些抽象比硬件本身活得还久。然后他们说：我们给 agent 做了一样的事情。
我在这一句上坐了一会儿。
Claude Managed Agents 在 2026 年 4 月 8 日进入 public beta。它不是一个新 model。它是一个基础设施层——一个 hosted runtime，Claude 在一个受管环境里作为自主 agent 运行。Anthropic 设计它的方式，有一些东西值得慢下来看一下，尤其是如果你的团队正在决定：agent 的这个层是自建、还是交给别人。
这是我注意到的、以及我还在试着想明白的部分。
Claude Managed Agents 是什么
长时任务的托管服务
本质上，Claude Managed Agents 是一套 API，负责 agent 执行的 runtime。你来定义这个 agent 该做什么——system prompt、工具、约束。Anthropic 在一个隔离的云容器里运行它，Claude 可以在里面读文件、执行代码、浏览网页、通过 基于 MCP 的 connector 调外部服务。
卖点很简单：与其花几个月自己造 agent loop、sandbox、工具编排、错误恢复、credential 管理，不如把那一层交给 Anthropic。根据 官方的 Managed Agents 文档，这个 harness 原生支持 prompt caching、context compaction 和性能优化——这些正是大多数团队最后都要从头写一遍的东西。
定价是 consumption-based：按标准 Claude API token 计费，另加 每 session-hour 运行时 $0.08。idle 时间不算。runtime 精确到毫秒。没有月租。没有按 agent 授权。
……这个定价结构让我看了两遍。它意味着真正的成本驱动因素不是 runtime 本身——而是 session 期间你的 agent tool loop 有多吃 token。每一次 bash 命令、文件读取、网页抓取都在贡献 token。$0.08/hour 相对于一个重度 agentic session 烧掉的推理费用，几乎可以算作凑数。
Session、harness、sandbox 以及事件接口
这里才是架构对我来说变有意思的地方。
Anthropic 的 Managed Agents engineering 博客 描述了三个被虚拟化的组件，每一个都被设计成可以独立演进：
Session 是一份 append-only 的持久事件日志。每一条用户消息、assistant 响应、tool call、tool result，都作为一个 typed event 被记录下来。它完全活在 harness 之外。它能在崩溃、网络断开、容器重启之后还在。两个接口原语：appendEvent() 和 getEvents()。就这些。
Harness 是 agent loop——它调 Claude、路由 tool call、管理 context。关键是：Anthropic 自己持有这一层，并随着 model 的进步去更新它。他们发现，为 Claude Sonnet 4.5 写的 harness 里有一段应对"context anxiety"的 context-reset 逻辑，但等到 Claude Opus 4.5 发布时，那种"anxiety"已经没了。旧 harness 实际上正在拖着新 model 的后腿。正是这个观察，催生了整个架构。
Sandbox 是执行环境——一个 gVisor 隔离的容器，Claude 生成的代码在里面跑。网络出口 default-deny。文件系统访问是 scoped 的。credential 从不落在 sandbox 里——它们保存在一个安全 vault 里，通过 proxy 获取。sandbox 在设计上被视为不可信。
我一直绕回到这个分离上。它干净。但是直到我想清楚"下一个 model 发布之后会发生什么"之前，我并没有真正理解这件事为什么重要。
Managed Agents 解决了什么
Runtime 基础设施、sandboxing、可恢复 session
如果你试过把一个 agent 推上生产，你对这个清单一点都不陌生：sandbox 化的执行、credential 管理、session 持久化、错误恢复、可观测性。一位开发者描述过：为了让一个 agent 在生产上跑起来，他们团队造了六个独立系统——其中四个跟 agent 实际在做的事没什么关系。
Managed Agents 把这一整类工作去掉了。Session 可以跑上几个小时。如果连接断了，session 会从持久事件日志恢复。每一个 tool call 和失败模式都可以通过内建的 observability 追溯。Notion、Asana、Sentry 这样的公司已经把基于这个基础设施的 agent 集成进去了。
实际影响是真实的。 一个读完代码库、规划修复、开 PR 的 coding agent。一个跑上九十分钟、跨几十次网页搜索的 research agent。这些 pattern 过去在开始写 agent 逻辑之前，需要几个月的基础设施工作。
把"大脑"和"手"解耦为什么重要
……就是在这里，有东西卡到位了。
Anthropic 把这个架构框成"大脑"（model 加上决定要做什么的 harness）和"手"（真正执行工作的 tool 和 sandbox）的解耦。这个分离有一个具体后果：当更好的 model 发布时，harness 可以被更新，而不需要去动你的 agent 定义。
在旧的耦合设计里，每个 session 都要付完整的容器启动成本——包括那些从不碰 sandbox 的 session。当 Anthropic 把 harness 从容器里挪出来之后，不需要代码执行的 session 就可以在不等容器 provisioning 的情况下启动。
但更深一层的点，是关于耐久性。Harness 编码的是"model 做不到什么"的那些假设。这些假设随着 model 的进步会过期。如果你的 harness 是你自己造的一个写死的系统，那你就继承了"让那些假设保持当前状态"的维护成本。如果 Anthropic 来持有这个 harness，这份成本就转给了他们。
我不完全确定这个承诺在更长的时间尺度上能兑现多少。但架构上的推理，对我来说是说得通的。
Managed Agents 默认没解决的问题
这是我花时间最多去想的部分。
能力验证、跨 agent 复用、治理生命周期
Managed Agents 把 runtime 这个问题解得很彻底。但有一些相邻问题它没有处理——不是因为有缺陷，而是因为它们坐在它当前 scope 的外面。
能力验证。 当一个 agent 成功完成一个复杂任务——比如说，分诊一类安全告警，或者重构某一种代码 pattern——那次成功不会被捕获成"一个已验证、可复用的能力"。session log 记下了发生了什么，但 没有一个机制能说"这个路子行得通，把它编码成其他 agent 可以继承的 strategy"。 每个 session 都是从头开始。Claude 在一个 session 里学到的东西，不会自动让下一个 session 变得更好。
跨 agent 复用。 你可以定义一次 agent，然后跨 session 按 ID 引用它。那是在配置层面的复用——同一个 prompt、同一套工具、同一套约束。但那不是能力层面的复用。如果 Agent A 发现了一套对某个具体 framework 有效的 debug strategy，Agent B 在做一个类似的问题时不会因此受益——除非有个人手动去更新共享的 system prompt。
治理生命周期。 beta 里包括了 scoped permission、identity 管理、执行 tracing。但更宽的治理问题——在一个 agent 的行为扩散出去之前，由谁来验证它是安全的，随着时间推移你怎么审计 capability drift——这些 pattern 不在当前 surface 里。
我可能过度解读了。这些可能是未来的路线图项目。但目前来看，Managed Agents 提供的是出色的受管执行，而不是内建的能力累积。 如果你考虑的是长期系统改进，而不仅仅是任务自动化，这个区别很重要。
……这里有些东西还不够清楚。我想这个 gap 是有意为之的——Anthropic 在先解基础设施问题，而能力演化是另外一个层。但我目前还不是完全肯定。
Managed Agents vs Claude Code Routines
长时 runtime vs 可触发的自动化
这个对比一开始把我搞糊涂了，但在把两边都看过之后就清晰多了。
Claude Code Routines 是保存下来的配置——prompt、repo、connector——按 schedule、API 调用或响应 GitHub 事件自动跑。它们为 无人值守、可重复 的任务设计，比如每晚 triage、PR review、文档漂移扫描。每次 run 都是一个新的 session。每日有额度（按套餐从 5 到 25 次不等）。它们从你的订阅 usage 里扣。
Claude Managed Agents 是一个为 长时、自主工作 设计的托管 runtime。Session 可以跑几个小时。Harness 管 context compaction、错误恢复、tool 编排。按 token 加按 session-hour 计费。没有每日 run 上限——你用多少付多少。
最简单的区分：Routines 是可触发的自动化。Managed Agents 是 agent 基础设施的 runtime。 Routines 假定任务是有界、可重复的。Managed Agents 假定任务是开放式的，可能要一阵子。
一个规划多文件 refactor、跑 test、开 PR 的 coding agent——那是 Managed Agents 的地盘。一个每晚给新 issue 打标签、往 Slack 发总结的脚本——那是 Routine。
两者都不能替代另一个。但它们俩，没有一个能单独把"成功执行"变成"可复用能力"。
谁应该认真评估 Managed Agents
基于我看到的，如果你的团队符合下面几个条件，Managed Agents 值得认真评估：
你已经做出了 agent 原型，然后撞到了基础设施墙。 从"能跑的 demo"到"生产部署"这一跳，是绝大多数团队卡住的地方。如果你的 backlog 里写着"做 sandbox 隔离""实现 session checkpoint""设计 credential 管理"，Managed Agents 把这一整类工作取消了。
你的 agent 任务是长时、多步的。 如果这个 agent 要读代码库、规划变更、执行代码、跑测试、开 PR——全部在一个可能一个小时的 session 里——这就是 Managed Agents 设计出来处理的那种 workload。短的、同步的任务更适合 标准 Messages API。
你对 beta 边界没有意见。 所有 endpoint 都要求 managed-agents-2026-04-01 beta header。multi-agent 协同和 self-evaluation 还在 research preview 里。行为可能会变。别在还没到 GA 的 surface 上堆 mission-critical 工作流。
你想过了 lock-in 这个问题。 一旦你的 agent 跑在 Anthropic 的基础设施上，换 provider 不是那么轻量。Anthropic 关于 Managed Agents 的博客 把这件事框成一个有意为之的 trade-off：由 Anthropic 负责 harness 的演进，代价是跟一个 runtime 耦合。如果你的架构要求混用多个 provider 的 model，这个约束就有分量。
你没有在默认情况下期待能力继承。 Managed Agents 给你的是出色的受管执行——不是一个"成功行为会在 session 之间累积、自我改进"的系统。
FAQ
Managed Agents 支持哪些 model？
public beta 支持 Claude Sonnet 4.6、Claude Opus 4.6 和 Claude Haiku 4.5。大 context（1M tokens）在 Opus 和 Sonnet 上默认可用。
怎么定价？
model 使用按标准 Claude API token 费率，另加每 session-hour $0.08 的活跃 runtime 费用。Web search 是每 1,000 次搜索 $10。idle 时间不计。没有月租。
beta 和 research preview 有什么区别？
核心平台——session、sandboxing、工具执行——在 public beta。multi-agent 协同和 self-evaluation（outcomes）在 research preview 里，需要单独申请 access。
我能不能设 per-session 的预算上限？
在 Managed Agents 里不能直接设。你可以在 Claude Console 里设一个组织级别的月度花费上限，但 per-session 预算上限目前没有文档说明。把 session 创建包一层你自己的逻辑去跟踪和终止失控 session，是实际的 workaround。
每个 session 都是从头开始的吗？
Session 在单个 session 内会持久化状态——文件系统、对话历史、事件日志。但跨 session 来说，没有内建的记忆或能力转移。每个新 session 都是从一个干净的环境开始。
这跟 Claude Code 一样吗？
不一样。Claude Code 是一个交互式编程的开发者工具。Managed Agents 是一个 API 层的基础设施服务，用来大规模部署自主 agent。它们共享架构 DNA，但服务的是不同的受众。
我还坐在这个架构前面。session、harness、sandbox——每一个都被虚拟化，每一个都可以独立演进。它解决的 runtime 问题是真实的，对于卡在原型和生产之间的团队来说，这把时间线从几个月变成了几天。
但我还是会注意到"受管执行"和"会累积的能力"之间那段空间。session log 记下了发生的一切。它还没有把"发生了什么"变成"下一个 session 可以在上面继续搭的东西"。
Previous Posts：
👉 想搞清楚 Claude Code 怎么接外部工具和 agent？从 MCP 的基础开始：What Is MCP? The AI Tool Connection Standard Explained
👉 想让 agent 走到 prompt 之外？这篇讲清楚 skill 在 Claude Code 里到底怎么工作：Claude Code Skills Explained: Build, Share, and Extend
👉 好奇 agent 基础设施层在真实系统里怎么叠起来？这篇给你完整的架构视角：MCP, CLI, and GEP: The Three Layers of the Agent Stack
👉 在比较"基础设施 vs 能力"？这篇讲清楚大多数团队漏掉的那个关键区别：Agent Skills vs GEP Assets: The Real Difference
👉 想看 agent memory 实际上怎么 scale（以及它在哪里崩）？这篇深入讲真实 tradeoff：Hermes Agent Memory Limits and Tradeoffs
