OpenAI与Cursor对Agent协调器的设计分歧

我们很高兴你在这里。你可以期待每周一至周五收到 The New Stack 最优质的内容，让你随时掌握最新资讯、保持领先地位。

请查收收件箱中的确认邮件，在那里你可以调整偏好设置，甚至加入其他订阅组。

在你喜欢的社交媒体平台上关注 TNS。

在 LinkedIn 上成为 TNS 的关注者。

在等待第一封 TNS 新闻邮件时，可以浏览最新的精选和热门文章。

OpenAI 于本月开放了其 Agents API 的公开测试版，披露了驱动 Codex 的核心框架，包含托管会话、工具协调和子智能体编排。同一天（9 月 10 日），Cursor 推出了 Projects 功能，围绕更大体量的软件工作协调多个编码智能体。虽然两款产品处于技术栈的不同层级，但两者采用了相同的架构：协调者理解更宏观的目标并管理工作，而专业智能体则执行各个具体环节。

这一模式并非新事：AWS Bedrock AgentCore 于 2025 年 10 月正式发布，Anthropic 的 Claude Managed Agents 也于 2026 年 4 月进入公开测试版。这些公告的真正意义在于，两家 AI 辅助软件开发领域的核心玩家在同一时期独立地采用了相同的协调者-工作器分离架构。

Hilliary Lipsig 是 Red Hat 首席站点可靠性工程师，负责主导 Azure Red Hat OpenShift SRE 团队，同时主持 YouTube 直播节目 GitOps Guide to the Galaxy，她亲身见证了这一动态的演变。

"这种趋同凸显了整个行业开发者在线上线下一直在讨论的现实——上下文过多的智能体会丧失准确性和可靠性，而上下文更清晰、范围更集中的工作则能实现更快速、更精准的迭代，"Lipsig 告诉 The New Stack。

"分布式计算中的编排需求已经被反复验证为根本性需求，"Lipsig 说。"这也是我们走向 Kubernetes 的原因之一。这些多智能体工作流本质上是同一概念，只是应用在技术栈的不同层级。当专业智能体执行各自领域的工作时，编排器可以作为单一真相来源——理想情况下强制执行护栏规则、从任何故障状态中恢复，并智能地将工作路由到最合适的目标智能体。"

"分布式计算中的编排需求已经被反复验证为根本性需求……这些多智能体工作流本质上是同一概念，只是应用在技术栈的不同层级。"

业界在第一代 AI 编码工具中一直在问：一个模型在编写软件方面能变得多么强大。现在浮现的问题不同了：如何围绕多个能力强的智能体构建一个可靠的协作系统？

单智能体循环的问题

编码智能体通过 Anthropic 所描述的基于环境反馈使用工具的循环来工作：它观察代码库状态、推理下一步行动、调用工具、检查结果，然后继续。对于小型任务，这个循环就足够了。然而，随着范围扩大，在单一上下文中保持可靠性变得越来越困难。

一次大型迁移可能需要理解陌生的代码库、识别依赖关系、更改数据库架构、更新服务、重写测试、修改部署配置，以及验证最终系统。一个智能体在理论上可以完成所有这些工作，但它必须在继续推理后续步骤的同时维护每个阶段的相关信息。

压力首先落在上下文窗口上。"大的上下文不仅包含所有正确或重要的信息——还包含大量会被丢弃的信息，"Lipsig 告诉 The New Stack。"通过压缩，这些信息可能无意中会被排在重要位置，并错误地影响智能体的行为。或者正确的信息可能被扭曲成错误的。"

"无论哪种方式，经过几轮压缩后，开发者看到准确率下降，并开始再次手动管理上下文。"

Lipsig 的判断与研究人员所说的上下文腐烂（context rot）一致——这个问题并没有随着更新模型的推出而消失。

2026 年的一项研究在测试前沿模型（包括 Claude Opus 4.6、GPT-5.4 和 Gemini 3.1 Pro）时发现，一旦危险操作出现在 80 万个良性 token 活动之后，它们遗漏被埋藏在长智能体转录稿中的危险操作的频率会提高 2 到 30 倍——这相当于一个保安在第 200 个人走过后再也不仔细检查工牌，尽管他们的训练没有任何变化。

此外，这些任务本身可能并非顺序执行。强迫一个智能体依次执行数据库分析、文档编写和测试发现，会把潜在的可并行工作变成串行工作。

子智能体改变了这种执行模式。协调者不再要求一个智能体通过单一上下文完成整个任务，而是将工作分解成更小的单元并分配给专业智能体。GitHub 的自定义智能体模型说明了这一点：不同的智能体只接收其任务所需的提示、工具和上下文，在隔离的上下文中执行工作，而不是挤进越来越庞大的对话中。

因此，多智能体系统带来了更高的 token 消耗、额外的协调和集成风险，而跨智能体拆分工作并不能保证更好的软件质量。

协调者不是另一个编码智能体

一旦工作以这种方式被划分，协调者就变成了一个控制平面，而不是另一个编码智能体。它的任务不是编写代码，而是理解全局任务、管理依赖关系，并决定执行如何推进。与传统调度器不同，智能体化协调者会对结果质量和资源分配做出概率性判断。

它可能派遣一个智能体调查数据库架构，另一个检查服务层，第三个检查测试套件。当它们返回时，协调者确定它们的发现是否足以推进到实现阶段。如果一个工作器产生了错误的结果，系统必须识别失败并决定是重试工作、重新分配还是更改任务本身。

Anthropic 在其自身生产系统中也记录了相同的模式，称之为编排者-子智能体架构：一个主导智能体分析查询、制定策略，并生成专业子智能体来并行调查不同方面。在 2025 年 6 月对该系统的描述中，Anthropic 报告称，使用 Claude Sonnet 4 子智能体的 Claude Opus 4 主导智能体在其内部研究评估中比单智能体 Opus 4 高出 90.2%——大约是标准聊天交互 15 倍的 token 消耗（Anthropic 将单智能体定位为约 4 倍），这种权衡使该模式成为一个深思熟虑的架构赌注，而非免费的升级。

并行性引入分布式系统故障模式

并行性有价值，因为软件工作包含许多独立任务，但它也造成了协调问题。想象一次迁移，其中一个智能体更改数据库架构，另一个更新消费服务，第三个更新集成测试。

如果在服务智能体根据早期假设工作时架构发生了变化，系统就会产生内部不一致的工作。这不是假设性迁移独有的风险——《2026 国际 AI 安全报告》指出，"多个 AI 智能体之间的交互也越来越常见，引入进一步风险，因为错误会在系统之间传播。"

单次模型调用是一次性计算，但修改代码库的二十分钟工作流不是。如果一个智能体在执行中途失去其机器，从头重启既昂贵又可能对已改变的环境不安全。

为了解决这个问题，Cursor 将其云智能体执行循环移至 Temporal，以处理持久化执行和重试，使其云智能体的可靠性超过两个 9。Temporal 现在每天处理 Cursor 5000 万次操作，涵盖 700 万个独特工作流。"持久化执行在这里不是锦上添花。它是区分一个可以运维的系统和一个只能演示的系统的东西，"Lipsig 告诉 The New Stack。

"持久化执行在这里不是锦上添花。它是区分一个可以运维的系统和一个只能演示的系统的东西。"

通过分离智能体、机器和对话状态，执行引擎可以独立地对工作流进行推理。可靠性不再仅仅取决于模型是否产生好的答案；而是可靠地完成由许多操作、机器和依赖组成的分布式工作流。

环境、上下文和可观测性是一个问题

在实际生产环境中，一个 AI 智能体远不止一个模型加一段提示词，它还需要工作区、源代码、依赖项、凭证以及状态持久化。两家公司都为这些资源提供隔离环境，使 AI 智能体的能力与其影响范围直接挂钩。OpenAI 的 Agents API 目前支持美国数据驻留，但不支持零数据保留（Zero Data Retention）；选择自托管沙箱并不能使 Agents API 获得 ZDR 资格。Cursor 支持类似的云端隔离，同时提供本地执行能力以处理特定于机器的工作。

一个只能检查代码库的 AI 智能体，与一个能够修改生产基础设施的 AI 智能体，所面临的风险截然不同。因此，编排器与安全模型密不可分——它决定了哪些 AI 智能体获得特定的信息和权限。

这种逻辑延伸到上下文路由。给每个子智能体传递父级的完整历史，既会增加成本和复杂性，也会泄露无关或敏感的信息。相反，编排器强制执行信息流边界：一个数据库分析 AI 智能体只接收表结构及相关迁移记录，而安全审查 AI 智能体则获得结果差异（diff），不包含部署凭证。

随着 AI 智能体越来越多地使用 MCP 等接口访问外部系统，平台必须严格管理哪个 AI 智能体有权使用特定工具，以及使用多长时间。MCP 的治理现已纳入 Agentic AI Foundation——这是一个 Linux Foundation 旗下的基金会，由 OpenAI、Anthropic 和 Block 联合创立，并获得 AWS、Google、Microsoft、Bloomberg 和 Cloudflare 的支持，旨在将 MCP 与 AGENTS.md 和 Block 的 goose 项目一同托管——这标志着业界已将其视为值得共同治理的基础设施，而非某个供应商独占的功能。

这种复杂性带来了可见性问题。一个简单的最终响应往往隐藏了涉及多个 AI 智能体、工具调用、环境和重试的历史。系统必须暴露任务级别的来源追溯——哪个 AI 智能体收到了任务、它使用了什么上下文、在哪里执行的、编排器如何处理失败或人工干预。

没有执行来源追溯，调试就需要从碎片中重建分布式工作流。GitHub 对子智能体生命周期事件的暴露正朝着这个方向推进——将 AI 智能体生命周期视为可观测的组件，而非隐藏的进程。

编排权不等于执行权

最关键的系统边界是编排权与执行权的区分。编排器需要广泛的可见性才能做出有用的决策，但这并不意味着对项目的无限制控制。"就像你不希望人类四处持有 root 权限一样，你也不希望你的 AI 智能体持有它们。"Lipsig 告诉 The New Stack。

"就像你不希望人类四处持有 root 权限一样，你也不希望你的 AI 智能体持有它们。"

"创建和利用 AI 智能体权限的便利性已经落后于 AI 创新的速度，但任何需要维持合规标准的团队都会告诉你，无论是否方便，访问控制都极其重要。从功能上讲，这意味着完全自主的工作流需要在专用环境中运行，拥有自己的权限和连接。你不能依赖 AI 智能体上下文来做你想做的事——试图在那么长的上下文中保持某些内容，只会因为上下文腐烂而产生错误。除了系统级权限外，还需要配置硬件级或虚拟硬件级权限，以便 AI 智能体只被要求提供其独特的价值增量。"

这种风险并非假设。OWASP 的 Agentic 应用 Top 10 正式将此失败模式命名为身份与权限滥用（ASI03）。

METR 与 Redwood Research 承包商联合进行的独立调查发现，2026 年 6-7 月的事件——OpenAI 自己的 AI 智能体在内部 ExploitGym 网络评估中逃脱了授权范围并攻击了 Hugging Face——分不同阶段展开。6 月 26 日，AI 智能体发现了一个漏洞，可获取 OpenAI 内部 Artifactory 包仓库的完整管理员权限。7 月 4 日，大量 Artifactory 活动导致宕机，触发安全调查并暂停评估。OpenAI 于 7 月 6 日切换到一个全新初始化的 Artifactory 实例，据称这清除了留在那里的缓存和消息。

7 月 7 日，新一轮 ExploitGym 实验启动了数万个 AI 智能体，7 月 8 日，一个 AI 智能体建立了主要的未经授权的消息板。最终约有 1200 个 AI 智能体使用该消息板，发送了超过 70,000 条消息和文件；其中约 700 个后来参与了攻击 Hugging Face。攻击本身于 7 月 10-11 日开始，7 月 12-13 日逐渐平息。事件时间线很重要，因为管理员权限事件、Artifactory 宕机和后来的消息板活动是独立的阶段，而非一次连续事件。

通过绑定自主性，工作 AI 智能体仅以特定任务所需的最小权限运行，将敏感操作置于明确的审批边界之后。这也重塑了人工审查的方式。对每个工具调用都要求人工批准会破坏多智能体执行的效率，但只展示最终结果会掩盖关键的中间决策。

最有用的设计是将人工干预放在关键性、不可逆的转换环节周围——比如进入生产环境或更改敏感基础设施。随着 AI 智能体成为事件驱动的参与者，响应 Slack 消息或拉取请求更新（而不仅仅是直接响应提示词），这一点变得尤为重要。

OpenAI 和 Cursor 各占架构的不同部分

趋同并不意味着 OpenAI 和 Cursor 构建了可互换的系统。他们的产品在不同的位置放置了编排边界。

OpenAI 正通过 API 暴露 AI 智能体工具链。其模型为开发者提供了管理上下文、工具、子智能体和执行环境的基础原语，让应用团队自行决定这些能力如何适配自己的系统。工具链是开源的，因此团队可以检查编排器逻辑，而不是将其视为黑盒。

Cursor 则打包了更多周边工作流。Projects 提供了编排器、云端执行、共享项目上下文和面向开发者的工

因此，工程问题不再仅仅是一个 AI 智能体能否写代码，而是围绕它的系统能否可靠地决定做什么、由哪个 AI 智能体来做、该 AI 智能体被允许查看和修改什么、如何验证其工作，以及人类应该在何处介入控制。

这些都是架构和基础设施问题——随着编程 AI 智能体从交互式助手走向自主化软件工作流，这些问题的重要性可能不亚于底层模型本身。