前沿实验室与云服务商正将代理循环转变为托管基础设施，通过API打包编排、版本控制、模型路由、工具、技能和优化等能力。开发者必须权衡哪些通用框架功能应外包托管，哪些产品特定逻辑需自主掌控。

托管代理架构：为何前沿实验室要重构代理循环

近期OpenAI发布Agents API，使开发者可通过API访问托管的Codex编排框架。目前最强大的代理编排框架之一现已作为基础设施开放，开发者可基于其构建应用。

此次发布蕴含重要的架构理念。OpenAI表示，要利用新模型特性通常需调整编排框架，因此计划随模型迭代同步维护改进Codex框架。Anthropic在Claude托管代理中提出了类似观点。

前沿实验室正同步构建模型与编排框架。更重要的是，他们声称凭借对模型的控制能打造更优框架，凭借对框架的控制能培育更佳模型。

OpenAI与Anthropic并非唯二提供托管代理基础设施的企业。AWS推出AgentCore框架，微软发布Foundry代理服务。Vercel则通过AI SDK及相关基础设施从另一角度切入相同技术栈。与前两者不同，AWS和微软可在无需依赖自研模型的前提下提供托管框架。

这给代理构建者带来两个关联架构问题：应保留多少代理循环自主权？框架是否必须来自模型研发方？

理解这些平台在托管框架中集成的能力，有助于决策代理技术栈的外包程度。

1. 代理作为声明式资源

最清晰的模式之一是将代理本身作为声明式资源处理。OpenAI的Agents API可通过单次API调用指定任务、模型、工具、环境及多代理设置，直接创建Codex代理。OpenAI负责运行底层框架，而非要求开发者自主实现循环。

AWS AgentCore框架将此理念进一步深化：允许开发者在不修改底层框架定义的前提下，为单次调用覆盖模型或工具。若托管抽象过于受限，可将框架导出为Strands代码并通过AgentCore Runtime运行。

微软在Foundry代理服务中采用类似分离架构：声明式代理直接运行，托管式代理则提供实现接口。

托管框架将编排从应用代码迁移至配置层面，类似Kubernetes与Helm对基础设施带来的变革。仅当托管框架无法表达所需行为时，开发者才需自主掌控代理循环。

2. 面向代理的发布工程

随着代理从本地实验走向生产环境，需要专属的发布流程。AWS为AgentCore框架提供不可变版本与命名端点，更新模型、工具或技能将生成新版本而非修改现有实例。

AgentCore支持基于生产流量的代理版本A/B测试：可比较两种提示词策略，或对比不同模型/完整代理配置方案。

微软在Foundry代理服务中构建了类似的部署原语，代理可通过稳定端点进行版本管理与发布，而非直接暴露可变开发配置给应用。

OpenAI在不同层面处理版本控制：Agents API随模型发布提供Codex框架能力的版本化访问，同时持续维护更新框架本身。这与AWS提供自研代理配置的不可变版本有所不同，但为应用底层框架确立了独立的发布生命周期。

3. 模型选择可在会话中动态实现

传统代理架构将模型与代理绑定，更换模型需修改代理配置。部分托管框架开始解耦二者，允许代理会话保持固定而动态更换底层模型。

AgentCore框架支持单一框架调用Bedrock、OpenAI、Gemini等兼容模型。AWS还允许开发者在同一会话的交互轮次间切换模型而不丢失上下文。典型场景如：使用模型A进行规划，调用模型B执行任务。

微软在Foundry代理服务中采取类似方案：其模型路由器可在同一对话中为每个请求分配不同模型，将简单轮次路由至经济型模型，复杂任务交由高性能模型处理。

在这两种情况下，模型选择与代理定义的耦合度正在降低。运行时可动态选择处理下一项任务的模型，无需重建对话或修改应用接口。

这为基于任务类型、成本、延迟或实测性能的路由策略开辟了空间。单个代理会话可为不同任务调用多个模型，同时保持身份标识与应用接口统一。

4. 工具正从代理中独立出来

新型Codex Agents API已将工具视为可独立于框架发现和加载的资源。代理可连接MCP服务器、自定义函数及内置工具，而OpenAI的工具搜索仅在需要时加载相关工具定义，而非将全部工具集置于上下文中。

微软通过Foundry Toolboxes进一步推进分离：组织可独立于特定代理定义工具集，通过托管MCP端点暴露该集合，认证与治理在工具箱层面统一处理。

AWS通过AgentCore Gateway采取类似架构：API与MCP服务器可依托共享基础设施，供多个代理共同调用。

这使得代理变更无需改动工具层，工具层更新也无需重部署所有使用它的代理。认证与访问策略可与工具绑定，而非在每个代理内部重复实现。

在规模化场景中，为每个代理单独接入相同系统将造成资源浪费。GitHub访问、Salesforce集成、内部数据库及企业搜索等能力，不应各自重复实现50次。这些平台正将通用集成能力迁移至可被多个代理复用的共享基础设施。

5. 技能可独立于代理定义存在

与直接嵌入代理的提示文本不同，技能可独立于使用它的代理进行维护。框架可在需要时发现并加载技能，而无需将所有指令纳入代理定义。

Codex提供了具体实现范例：OpenAI托管的Agents API沙箱可配置文件、包、技能和插件，官方示例将技能目录作为环境配置的一部分指向代理。

AWS AgentCore Skills将指令与支持资源打包为可复用单元，可附着于框架。技能可源自Git、S3或AWS托管目录。

这实现了工作流程与执行代理的分离。企业可维护一个竞争分析技能和一个事件调查技能，使这些能力服务于多个不同代理。

在托管代理框架下，代理定义可保持精简，更多能力通过外部维护实现。

6. 代理循环外的优化闭环

微软的Agent Optimizer可评估现有代理并生成替代配置，包括调整指令、优化工具描述、修改技能或推荐不同模型。

生成的方案经评估后，开发者可选择推广实施。AWS在AgentCore中构建了类似机制：生产追踪数据与评估结果可生成提示词或工具描述的改进建议，随后通过实时流量测试验证效果。

这些框架正在构建包裹代理循环的二次优化闭环：外层循环利用生产数据生成新代理配置，并与当前版本对比测试。虽然仍需人工审核后推广，但平台已具备自动生成与评估能力。

OpenAI目前未在Agents API中开放同类客户侧优化循环，但在更低层面实施相关优化：持续改进Codex框架本身，并随模型发布同步更新框架能力版本。

7. 框架作为API边界

Anthropic明确了Claude托管代理的重要设计目标：开发者应基于稳定接口编程，同时保留Anthropic持续优化底层实现的权利。

OpenAI在Agents API中采取了类似策略：开发者调用托管服务，OpenAI则运营其描述为持续演进的Codex框架。OpenAI承诺将随模型迭代同步维护改进框架，并提供框架新能力的版本化访问。

托管框架在服务提供商API后封装的不仅是推理能力。处理单个任务时可能发起多次模型调用、调用工具链或使用子代理，同时无需向应用暴露每个内部决策。Codex还在框架内部处理上下文压缩，使应用可跨越多个上下文窗口而无需自主实现该机制。

OpenAI或Anthropic可同步发布模型与框架改进。例如，新模型特性可伴随上下文管理或工具使用的架构调整而推出，无需每个应用开发者更新自身编排逻辑。

谁应真正掌控代理循环？

托管代理API将开发者边界从模型API提升至代理框架层。服务商获得空间，可在模型演进过程中同步调整其外围机制。

前沿实验室在此具备独特优势：他们可同步构建模型与框架。上下文管理、工具调用、任务规划等循环模块的改进，可随其支持的模型能力同步发布。

但这并不意味着服务商总能构建最适合您应用的框架。围绕特定产品设计的框架，可利用其工作流、工具、数据和约束实现通用托管框架难以企及的优化。

对某些产品而言，这些定制化优化可能比框架与模型同步开发的优势更为重要。