托管 Agent 与自托管 Agent SDK 之间的选择，本质上是对运行时责任归属的选择。使用 SDK 时，Agent 运行在你负责运营的进程中；使用 Managed Agents 时，Provider 负责服务端 Agent loop 与 Session 状态，你的应用通过 API 和事件流同它通信。执行 Environment 是另一项独立选择：Anthropic 同时提供 Anthropic 托管的云沙箱和 self-hosted Environment。
“自托管”不一定是把服务器放在办公室里。这个进程可以运行在笔记本、CI Worker、Kubernetes 集群或云虚拟机。真正的判断标准是：它由你的团队部署、加固、观察、扩缩容和故障恢复。
本文用 Anthropic 的 Claude Agent SDK 与 Claude Managed Agents 做具体对比，因为官方迁移指南明确记录了每项责任迁移到哪里。这套决策框架也适用于更广的产品：先决定每一层 runtime 应由谁负责，再选择工具。
一句话做决定
当控制 Agent 进程与生命周期本身就是产品能力或合规边界时，选择自托管 Agent SDK；当服务端 Agent loop 与持久 Session 生命周期只是团队不想重复维护的通用基础设施时，选择托管 Agent。然后再单独选择 Environment 的托管方式；self-hosted Environment 并不会把 Managed Agents 变成自托管 Agent SDK。
这不是放之四海而皆准的推荐。托管 runtime 会减少一部分运维面，但也会引入 Provider 合同、受支持的工具模型、数据路径、计费方式和平台生命周期，这些仍需评估。自托管 runtime 保留更多控制，但可靠性和隔离也变成你自己的责任。
错误的决策方式是简单说“托管更容易”或“自托管更安全”。易用性和安全性都取决于具体要求与实现。真正有用的问题是：哪些责任能形成产品优势，哪些责任只是工作量？
运行时责任对比
下面这张表把问题拆成具体责任。
这张表揭示了一个重要细节：托管不代表责任消失，只是你执行责任的接口变了。
例如，把内置 Bash 和文件操作移进 Session Environment 后，应用进程不再需要自己执行这些工具。Environment 由 Anthropic 还是你的团队托管，会改变基础设施边界。但如果自定义工具会写入你的数据库，认证、授权、输入验证、幂等性和可审计 handler 仍然需要由你负责。
托管 Agent 真正移走了什么，又留下了什么
Anthropic 把 Managed Agents 描述为用托管基础设施取代手写 Agent loop。在 Messages API loop 中，应用需要反复发送对话历史、读取 tool_use、执行工具、追加 tool_result，再决定循环何时结束。使用 Managed Agents 后，Session 在服务端保存历史，预置工具在配置好的 Environment 中运行，事件流会在 Session 进入 idle 时发出状态。
从 Claude Agent SDK 迁移时，变化相似但更具体：
- 每次运行创建的
ClaudeAgentOptions变成持久化、版本化的 Agent 定义； query(...)或ClaudeSDKClient进程变成创建 Session 并收发事件；- 内置工具从本机进程和文件系统迁入 Session Environment 的
/workspace；这个 Environment 可以由 Anthropic 托管，也可以 self-hosted； cwd与add_dirs变成上传或挂载的 resources；- SDK permission mode 与 callback 映射成按工具配置的 permission policy 和确认事件。
因此，托管服务确实移走了相当一部分 loop、Session 与生命周期代码。它能移走多少 sandbox 基础设施，则取决于 Environment 是 Anthropic 托管还是 self-hosted。
但它不会移走所有应用责任。官方迁移合同说明，自定义工具会声明在 Agent 上，但客户端仍要处理 agent.custom_tool_use 并发送 user.custom_tool_result。客户端展示功能、回合计数和部分 Hook 行为也会转移到你的应用，而不是自动变成服务端功能。
选择托管 Agent 前，应给每个自定义工具画出责任边界。如果大部分业务价值和故障风险都在这些工具里，即使核心 loop 已经交给 Provider，应用仍然掌握着最难的控制点。
什么时候自托管 Agent SDK 更合适
以下一种或多种约束起决定作用时，由自己运营进程通常更合适。
本地执行环境就是产品的一部分
如果 Agent 必须深度操作开发者 checkout、专有构建系统、本地硬件或既有 runtime identity，把文件搬进远程云沙箱可能增加的转换工作比省下的还多。self-hosted Managed Agents Environment 可以改变执行边界，但 Provider 仍负责 Agent loop 与 Session 合同；Agent SDK 则进一步让 Agent 进程本身也直接运行在这些资源旁边，并使用你自己的部署方式。
你需要高度定制的生命周期
自定义编排器可能需要非标准 checkpoint、确定性的审批阶段、多个模型 Provider、特殊的重试语义，或无法自然映射到托管 Session API 的调度方式。拥有进程后，这些生命周期可以直接实现。
部署或数据边界有硬性要求
有些组织要求特定地区、网络拓扑、硬件、存储系统或审计流水线。托管 Provider 或 self-hosted Environment 可能支持这些要求，但必须从当前合同与架构中证实。如果两者都不满足，就可能需要在经过批准的边界内自己运营完整 runtime。
截至 2026-08-31，Anthropic 的 Managed Agents Overview仍将该产品标为 beta，并说明有状态 Session 当前不支持 Zero Data Retention（ZDR）或 HIPAA BAA。这些是选型边界，不是可以忽略的脚注。处理受监管或对留存敏感的数据前，要重新检查最新官方说明和自己的要求。
深度运行时可观测性不可缺少
事件流只能描述托管服务愿意暴露的内容。自托管进程还可以按团队定义的精度暴露调度决策、内存压力、容器生命周期、自定义 checkpoint 和应用专属 Trace。但只有团队愿意把这套可观测性真正建好、维护好，这种灵活性才有价值。
Runtime 可迁移性是首要要求
如果 Provider 可迁移性本身就是产品的一级要求，把编排和状态保留在自己的服务里，可以降低对某一套托管 Session 合同的依赖。可迁移性仍需要严格的抽象和测试；仅仅用了 SDK，并不会自动获得它。
什么时候托管 Agent 更合适
当运维工作很多、却不能形成差异化优势时，托管 runtime 会更有吸引力。
任务是长时或异步的
Anthropic 的平台介绍把 Managed Agents 定位于长时任务与异步工作，而 Messages API 适合自定义 loop 和细粒度控制。服务端 Session 可以不依赖脆弱的客户端长连接持续存在，前提是应用按照 API 合同正确处理事件与恢复。
你希望 Agent 配置可以版本化
持久化的 Agent 版本可以成为清晰的发布和回滚单位。新 Session 能固定到已知的模型、System Prompt、Toolset 与 Policy 版本，不必把每次变化都绑在应用部署上。
托管云 Environment 可以替代重复平台工作
如果每个团队都要重复构建同样的代码执行隔离、文件处理、Session 状态和 loop 恢复，Anthropic 托管的云 Environment 可以减少重复工程。使用 self-hosted Environment 时，即使服务仍管理 Agent loop 和 Session，你的团队也要继续运营更多 sandbox 基础设施。两种模式下都要验证网络、密钥、资源上限、数据处理和事故流程。
缩小运维面比获得最大灵活性更重要
平台团队较小的组织，可能从一套受支持的 Session 生命周期里获得更多价值，而不是拥有每个调度器和容器细节。代价是接受 Provider 支持的能力范围与发布节奏。
迁移是责任转移，不是更换一个 Package
从 Agent SDK 迁移到 Managed Agents 会改变每个概念所在的位置，应该把它当作架构迁移。
在迁移生产流量前，先端到端跑通一个代表性工作流。核验文件是否最新、工具密钥、取消、重连、重复自定义工具结果、版本回滚和最终 Session 状态。“正常路径给出了正确答案”还算不上 runtime 迁移测试。
Managed Agents Quickstart适合学习 Agent、Environment、Session 与 Event 概念；真正判断责任如何变化时，仍应以迁移指南为准。
Agent.Space 在这套选择中的位置
Agent.Space 与自托管 Claude Agent SDK 服务、Anthropic Managed Agents API 都有不同的产品边界。
Agent.Space 把受支持的 Agent harness、模型访问和云 Workspace 放在一起。Agent.Space 如何工作解释了 harness、模型、Workspace 与资金来源之间的区别。Agent.Space 并不声称自己的 Developer API 实现了 Anthropic Managed Agents 的 Sessions、Environments 或事件合同。
当真实需求并不是“开发自己的 Agent runtime”时，Agent.Space 才会成为相关路径。团队可能真正想用的是成熟 coding harness、让文件与 Session 留在共享 Workspace，或通过 Agent.Space Developer API把受支持的客户端连接到可用模型。
安全性仍取决于选择的边界。在把仓库数据或密钥放进任何路径前，都要检查哪个进程或 Workspace 能读取它们、密钥如何保存，以及哪些操作需要审批。Coding Agent Workspace 安全指南提供了一份实际检查清单。
如果你想要的是成熟 coding harness，而不是新建 SDK runtime，可以比较 Agent.Space 提供的 Agents。这条路径能避免自己编写编排服务，但并不代表它与 Anthropic Managed Agents 功能完全一致，也不暗示双方有官方集成关系。
最实际的结论
列出每一项 runtime 责任，指定负责人，再检查高风险例外。当控制 Agent 进程与生命周期至关重要时，选择 SDK；当持久 Session 与 loop 可靠性是希望由 Provider 负责的基础设施时，选择托管 Agent，再单独决定 Environment 由 Anthropic 还是你的团队托管。如果真实需求只是使用 coding Agent、获得模型访问并共享工作空间，就把它当作第三条路径评估，不要强行塞进 SDK 与托管 runtime 的二选一。