托管代理框架与自托管代理循环：你得到什么，失去什么

“自托管代理”这个说法如今至少隐藏了三种不同的架构。你可以使用由 OpenAI 托管计算资源的托管式执行框架，也可以使用连接到你自己运营的基础设施的托管式执行框架，或者自行运行执行框架和代理循环。这些选择在控制权、恢复能力、上下文管理、安全性、延迟和运维负担方面有着截然不同的影响。

错误：把自托管当作一个单一决策

在传统软件中，“自托管”通常意味着应用程序运行在你控制的基础设施上。代理系统使这个定义变得复杂，因为运行时可以被拆分。模型与工具的循环可以在一个地方运行，而代码执行、文件和私有网络访问则在另一个地方进行。

OpenAI 当前的 Agents API 架构明确体现了这种拆分：OpenAI 运行执行框架，而执行环境可以不存在、由 OpenAI 托管或自托管。因此，自托管环境并不意味着代理循环是自托管的。

这种区分很重要，因为许多团队选择了比实际需要更复杂的运行时。他们想要私有网络访问或自定义软件包，于是断定整个代理都必须自托管，结果意外地承担了本可以保持托管的上下文管理、编排、恢复和生命周期管理。

三种常被称为“自托管”的架构

双平面模型

托管式执行框架：你实际获得了什么

托管式执行框架消除的不仅仅是一个 while 循环。OpenAI 当前的 Agents API 管理会话、编排、上下文压缩和恢复。Anthropic 在托管代理方面的工作描述了同样的更广泛动机：执行框架包含关于模型行为的假设，而这些假设需要随着模型的改进而演变。

这意味着好处不仅仅是更少的代码行数。平台可以更新运行时行为、长周期上下文处理、子代理协调和恢复，而无需每个应用团队重新构建这些机制。

• 更少的应用自有编排代码。
• 托管的持久会话行为。
• 托管的上下文压缩和恢复。
• 能够随模型能力演变的运行时。
• 更简单地采用平台原生的子代理和长时间运行代理功能。
• 对于差异化不在于执行框架本身的团队，可能降低运维负担。

托管式执行框架：你需要放弃什么

将执行框架委托出去，也意味着委托出部分控制权。你的应用不再拥有迭代、上下文策略、编排和运行时演进的每一个细节。平台更新可以改进系统，但也可能改变你的产品隐式依赖的行为。

这带来了一种不同的工程需求：强大的评估、明确的产品边界，以及一个集成层，防止托管会话行为成为你的业务事实来源。

自托管执行环境：中间架构

OpenAI 的自托管环境模型很重要，因为它将私有计算与执行框架所有权解耦。平台仍然运行 Codex 执行框架，而执行器在你的环境中运行，并通过出站连接接收命令。

你控制资源调配、文件、依赖、网络访问和清理。因此，执行框架可以针对私有基础设施或自定义软件工作，而无需将整个代理运行时迁移到你的应用中。

代价是生命周期责任。你的应用必须将会话映射到计算资源，避免重复调配，重新连接环境，协调关闭，并保留任何必须比环境存活更久的文件。

何时自托管执行就足够了

• 代理需要访问私有 VPC 或内部服务。
• 代理需要自定义二进制文件、软件包、驱动程序或系统软件。
• 工作负载必须在你控制的硬件或云账户上运行。
• 文件必须保留在受控环境中。
• 你需要自己的沙箱提供商或隔离模型。
• 你想要平台管理的编排，但由基础设施控制的执行。

何时你可能也需要拥有执行框架

当执行框架本身成为产品差异化或约束集的一部分时，拥有执行框架就变得合理。OpenAI 当前的运行时概览将 Codex SDK 定位为在你运营的基础设施中运行 Codex 执行框架，而当你想要自己拥有代理循环时，Responses 是更低层级的选择。

关键在于识别一个真正存在于执行框架层面而非执行层面的需求。

控制升级测试

使用满足实际需求的最少自托管架构。一次只升级一层控制。

当你拥有执行框架时，运维负担会非线性增长

自运营循环在演示中听起来很简单：调用模型、检查工具调用、执行工具、追加结果、重复。生产环境增加了持久状态、重试、重复事件、取消、审批、上下文溢出、工具超时、进程重启、跟踪持久化、背压、并发工作和部分副作用后的恢复。

Anthropic 的长期运行代理研究反复表明，框架设计对性能有实质性影响。他们在长期运行应用程序开发方面的工作使用显式规划、结构化产物和评估代理，因为朴素循环往往会丢失进度或过早终止。因此，框架是生产逻辑，而不是管道。

安全边界：自托管计算不会自动使代理私有

自托管执行环境控制命令运行的位置和文件所在的位置，但托管框架和模型交互仍然跨越服务边界。因此，团队应明确映射数据流，而不是将“自托管”用作隐私属性的简写。

OpenAI 的自托管执行器使用受限的环境凭据和出站连接。这是有用的隔离，但你的应用程序仍然需要自己的规则来处理机密、私有网络暴露、用户到环境的隔离、文件保留、工具授权和数据分类。

延迟和成本：控制可以移动瓶颈，而不是消除瓶颈

自托管可能会减少一些数据路径或环境启动成本，但也可能增加配置时间、WebSocket 生命周期、冷启动、沙箱清理、可观测性基础设施和工程开销。托管环境可能每单位计算成本更高，但在低量或不规则量下运营成本更低。

正确的比较是总系统成本：模型和工具使用、环境时间、基础设施、工程努力、待命负担、故障恢复以及较慢迭代的成本。

生产决策矩阵

混合不是妥协——它通常是清晰的架构

托管框架与自托管执行不是“半自托管”。这是有意的关注点分离。平台拥有长周期代理运行时的复杂性，而你的基础设施拥有执行、私有连接和文件。

该边界类似于其他云架构：托管控制平面，客户控制的数据或执行平面。重要的设计工作是定义它们之间的契约——会话身份、环境身份、凭据、文件、工具权限、生命周期事件和清理。

什么会改变这个答案？

如果托管框架暴露更多的运行时控制，如果自托管框架获得更简单的持久会话和恢复原语，或者如果法规要求整个代理循环和模型交互保持在你运营的基础设施内，那么建议会改变。

它也会随着模型能力的变化而变化。Anthropic 明确指出，随着模型改进，harness 假设可能会过时。今天必不可少的控制机制，以后可能变得不再必要，而新的模型能力则可能产生新的治理要求。

局限性

本文区分的是架构职责；它并不声称某一种托管模型普遍更安全、更便宜或更可靠。这些结果取决于实现、工作负载、合规要求、团队技能和提供商行为。

OpenAI Agents API 仍处于公开测试阶段，不同供应商的托管代理产品暴露出不同的边界。双平面模型旨在帮助比较这些架构，而不假设每个供应商都使用相同的术语。

结论

有用的问题不是“我们应该自托管代理吗？”而是：我们实际需要控制哪个平面？

如果需求是私有计算、自定义包、本地文件或内部网络访问，就自托管执行平面，并保持 harness 托管。如果需求是编排语义、上下文策略、提供商控制或运行时生命周期本身，那么 harness 所有权可能是合理的。只按需求所要求的程度升级控制。

常见问题

术语表

主要来源与延伸阅读