OpenAI 最近发布了 Agents API，把 Codex 的 agent harness 变成开发者可以直接调用的托管服务——目前最强的 agent harness 之一，从此成为可以围绕它搭应用的基础设施。
这次发布背后有一个更重要的架构主张。OpenAI 明说：要发挥新模型的能力，往往需要同步修改 harness，所以它会随模型一起维护和改进 Codex harness。Anthropic 的 Claude Managed Agents 讲的是同一套逻辑——前沿实验室在同时造模型和 harness，并且声称因为掌握模型所以能造出更好的 harness，反过来也可能因为掌握 harness 而造出更好的模型。
做托管 agent 基础设施的不止这两家。AWS 有 AgentCore Harness，微软有 Foundry Agent Service，Vercel 则从另一个方向切入同一层——用 AI SDK 和配套基础设施跑在 harness 周围。区别在于：AWS 和微软可以提供托管 harness，但不要求底层模型来自同一家。
这留给 agent 开发者两个相关的架构问题：agent loop 里还有多少该自己掌握？harness 必须出自造模型的那家公司吗？看清这些平台在托管 harness 里到底放了什么，才能决定要把 agent 技术栈的哪一层交出去。
#1. Agent 变成声明式资源
最清晰的一个模式，是把 agent 本身当作声明式资源。OpenAI 的 Agents API 用一次调用就能创建 Codex agent：声明任务、模型、工具、运行环境和多智能体设置，OpenAI 在这份声明之下替你运行 harness，开发者不需要自己实现 loop。
AWS AgentCore Harness 把这个思路推得更远：单次调用可以覆盖模型或工具，而不必改动 harness 定义本身。如果托管抽象太受限，harness 还能导出成 Strands 代码、放到 AgentCore Runtime 里跑。微软在 Foundry Agent Service 里做了类似的分层：prompt agent 从声明运行，hosted agent 则允许开发者自带实现。
托管 harness 把编排从应用代码挪进了配置——就像 Kubernetes 和 Helm 当年对基础设施做的事。只有当需要托管 harness 表达不了的行为时，开发者才需要自己持有 agent loop。
#2. Agent 的发布工程
当 agent 从本地实验走向真实生产环境，它就需要自己的发布流程。AWS 给 AgentCore harness 配了不可变版本和命名 endpoint：更新模型、工具或 skill 会产生一个新版本，而不是原地修改现有版本。
AgentCore 还支持用生产流量在 agent 版本之间做 A/B 测试——一次实验可以比两个 prompt，另一次可以比不同模型或完全不同的 agent 配置。微软也在 Foundry Agent Service 里构建类似的部署原语：agent 可以版本化、发布在稳定 endpoint 后面，而不是把可变的开发配置直接暴露给应用。
OpenAI 处理版本化的边界略有不同。Agents API 给开发者的是随模型发布而版本化的 harness 能力，harness 本身由 OpenAI 维护更新。这不等于 AWS 那种"开发者持有自己 agent 配置的不可变版本"，但它同样在应用之下，为 harness 建立了独立的发布生命周期。
#3. 模型选择可以发生在会话内部
传统 agent 架构把模型绑在 agent 上，换模型等于改 agent 配置。一些托管 harness 开始把两者分离：agent 会话保持不变，模型在底下换。
AgentCore Harness 允许一个 harness 混用 Bedrock 模型、OpenAI、Gemini 或其他兼容 provider，甚至能在同一会话的两轮之间切换模型而不丢上下文——比如用一个模型做规划、另一个做执行。微软的 model router 思路相近：同一次对话里按请求选模型，简单轮次路由给便宜模型，复杂工作交给强模型。
两种做法里，模型选择都在跟 agent 定义解耦。运行时可以决定下一部分工作交给哪个模型，而不必重建会话或改应用接口。这打开了按任务类型、价格、延迟或实测表现做路由的空间——一个 agent 会话可以为不同工作用好几个模型，身份和接口都不变。
#4. 工具正在移出 Agent
新的 Codex Agents API 已经把工具当成可以独立于 harness 发现和加载的资源：agent 可以挂 MCP server、自定义函数和内置工具，而 OpenAI 的 tool search 只在需要时加载相关工具定义，而不是把整个工具面都塞进 context。
微软的 Foundry Toolboxes 把这个分离推得更彻底：组织可以独立于任何具体 agent 定义一套工具集合，通过托管 MCP endpoint 暴露出去，认证和治理都收敛在 toolbox 层。AWS 的 AgentCore Gateway 是同样的路子——API 和 MCP server 放在共享基础设施后面，被多个 agent 消费。
agent 可以变而工具层不动，工具层可以变而不必重新部署每个用到它的 agent。认证和访问策略留在工具侧，不用在每个 agent 里各实现一遍。规模上来之后，把同一套系统逐个接进每个 agent 是纯粹的浪费——GitHub 不该被实现 50 次，Salesforce、内部数据库、公司搜索也一样。这些平台正在把公共集成搬进多 agent 共享的基础设施。
#5. Skills 可以活在 agent 定义之外
跟直接嵌进 agent 的 prompt 文本不同，skills 可以脱离使用它的 agent 单独维护，由 harness 在需要时发现和加载，而不是把所有指令都写进 agent 定义。
Codex 有这个模式的具体实现：Agents API 的托管沙箱可以预置文件、包、skills 和插件，API 自己的示例就把一个 skills 目录作为环境配置的一部分指给 agent。AWS AgentCore Skills 则把指令和支持资源打包成可复用单元挂到 harness 上，来源可以是 Git、S3 或 AWS 托管目录。
这等于把"做一件事的流程"和"做这件事的 agent"拆开了。一家公司可以维护一个竞品调研 skill、一个事故排查 skill，然后开放给多个不同 agent 使用。在托管框架下，agent 定义本身可以保持很小，越来越多的能力在定义之外独立维护。
#6. Agent Loop 外面的那个优化 Loop
微软的 Agent Optimizer 会评估一个现有 agent，然后生成替代配置：改指令、优化工具描述、修改 skills、或者推荐换模型。候选方案先经过评估，再由开发者决定是否 promote。AWS 在 AgentCore 里组装类似的机制——生产 trace 和评估结果可以产出针对 prompt 或工具描述的修改建议，再用真实流量跟当前版本对比测试。
这些框架实际上是在 agent loop 外面套了第二个 loop：外层 loop 用生产行为生成新的 agent 配置、跟当前版本对比验证。人仍然要在 promote 前点头，但平台已经能自己生成并评估候选配置。
OpenAI 目前没有（至少今天没有）在 Agents API 里开放这种面向客户的优化 loop，但它在更低一层做着相关的事：持续改进 Codex harness 本身，随新模型一起发布版本化的 harness 能力。
#7. Harness 成为 API 边界
Anthropic 把 Claude Managed Agents 的一个重要设计目标说得很明白：开发者对稳定接口编程，Anthropic 保留在接口下面改实现的自由。OpenAI 的 Agents API 是同样的姿态——开发者调用托管服务，OpenAI 运营它所说的"持续演进的 Codex harness"，随模型发布提供版本化的 harness 能力。
托管 harness 藏在 provider API 后面的远不止推理。一个任务在内部可能触发多次模型调用、沿途调工具、起 subagent，而不把每个内部决策暴露给应用。Codex 甚至在 harness 内部处理 context compaction——应用可以横跨多个 context window，而不必自己实现这套机制。
这样，OpenAI 或 Anthropic 就能把模型和 harness 的改进打包发布：一个新模型能力可以带着 context 管理或工具使用的改动一起上线，而不要求每个应用开发者更新自己的编排层。
#谁该真正拥有 Agent Loop？
托管 agent API 把开发者的边界从 model API 上移到了 agent harness。provider 由此获得了随模型变化而改动模型周边机制的空间。
前沿实验室在这里有独特优势：模型和 harness 一起造，context 管理、工具使用、规划和 loop 其他部分的改动，可以跟它们所支撑的模型能力同步发布。
但这不意味着 provider 的 harness 永远是你的应用的最优解。围绕特定产品设计的 harness，能吃透这个产品的工作流、工具、数据和约束——这是通用托管 harness 做不到的。对某些产品来说，这些优化的价值会盖过"让 harness 跟着模型一起演进"的好处。