ARTICLE · 1078988
OpenAI与Cursor在智能体协调器上达成一致,但对谁来运营它们存在分歧
OpenAI与Cursor在多智能体编程领域不约而同引入了协调器机制，但双方在架构控制权和实现路径上存在分歧。随着氛围编程向自主化演进，解决上下文衰减、分布式系统容错及权限控制成为核心工程挑战。
译自：OpenAI and Cursor agree on agent coordinators. They disagree on who runs them.[1]
作者：Robert Kimani
OpenAI本月推出了公开测试版的Agents API[2]，暴露了驱动 Codex 的技术框架，支持托管会话、工具协调和子智能体编排。同在9月10日，Cursor 推出了 Projects[3] 功能，用于在更大型的软件开发工作周围协调多个编码智能体。虽然这两个产品处于技术栈的不同位置，但它们都汇聚于相同的架构：协调器理解宏观目标并管理工作，而专业智能体负责执行具体的子任务。
这种模式并不新鲜：AWS Bedrock AgentCore 于 2025 年 10 月正式全面可用[4]，而 Anthropic 的 Claude Managed Agents 也于 2026 年 4 月进入公开测试[5]。这些发布之所以引人注目，是因为人工智能辅助软件开发的两个主要玩家正在同时、独立地暴露出相同的“协调器-工作者”拆分模式。
Red Hat 的高级首席站点可靠性工程师 Hilliary Lipsig[6] 领导着 Azure Red Hat OpenShift SRE 团队，并主持 YouTube 直播节目 GitOps Guide to the Galaxy[7]，她亲眼见证了这种动态的发展。
Lipsig 告诉 The New Stack：“这种收敛凸显了行业内开发者在网内和网外一直在讨论的现实——拥有过多上下文的智能体失去了准确性和可靠性，而具有更清晰上下文的专注工作可以实现更快、更准确的迭代。”
Lipsig 说：“分布式计算中对编排的需求一再得到根本性的认可。这也是我们如何走向 Kubernetes[8] 的原因之一。这些多智能体工作流是相同的概念，只是位于技术栈的新部分。虽然专业智能体在其工作领域开展工作，但编排器可以充当事实来源——理想情况下，它可以强制实施护栏、从任何故障状态恢复，并将工作智能地路由到最高效的目标智能体。”
“分布式计算中对编排的需求一再得到根本性的认可……这些多智能体工作流是相同的概念，只是位于技术栈的新部分。”
第一代 AI 编程工具花了很多时间来探讨模型编写软件的能力能达到多高。而新出现的问题则不同：如何围绕多个有能力解决同一问题的智能体构建一个可靠的系统？
单智能体循环的问题
编码智能体通过 Anthropic 描述的 LLM 在循环中使用基于环境反馈的工具[9]来工作：它观察代码库的状态、推理下一步该做什么、调用工具、检查结果并继续。对于小任务，这个循环可能就足够了。然而，随着范围的扩大，在单个上下文中保持可靠性变得更加困难。
一次大型迁移可能需要理解一个不熟悉的代码库、识别依赖关系、更改数据库模式、更新服务、重写测试、修改部署配置并验证生成的系统。理论上，单个智能体可以执行所有这些工作，但它必须保留来自每个阶段的相关信息，同时继续推理接下来的内容。
压力首先降临在上下文窗口上。“一个大的上下文不仅包括所有正确或重要的内容——它还包括很多用完即弃的信息，”Lipsig 告诉 The New Stack。“通过压缩，这些信息可能会无意中被排为重要信息，并错误地影响智能体所做的事情。或者正确的信息可能会被扭曲成不正确的信息。”
“无论哪种方式，经过几轮压缩后，开发人员发现准确性在下降，并开始再次手动管理上下文。”
Lipsig 的看法与研究人员所称的 上下文腐烂（context rot）[10] 不谋而合，而且随着更新的模型推出，这一问题并未消失。
一项 2026 年的研究[11]测试了包括 Claude Opus 4.6、GPT-5.4 和 Gemini 3.1 Pro 在内的前沿模型，发现在经历了 80,000 个 token 的良性活动之后，它们错过隐藏在长智能体记录中的危险操作的概率增加了 2 到 30 倍——这相当于 AI 版本的保安，在两百个人走过之后停止了仔细检查胸牌，尽管他们的训练没有任何改变。
此外，任务本身可能不是顺序的。迫使一个智能体一个接一个地执行数据库分析、文档工作和测试发现，会将潜在的并行工作负载变成串行工作负载。
子智能体改变了这种执行模型。协调器不再需要一个智能体通过单个上下文承担整个任务，而是将工作分解为更小的单元，并将它们分配给专门的智能体。GitHub 的 自定义智能体模型[12] 说明了这一点：不同的智能体只接收其任务所需的提示、工具和上下文，在隔离的上下文中执行工作，而不是挤在一个不断扩大的对话中。
因此，多智能体系统带来了更高的 Token 成本以及额外的协调和集成风险，并且跨智能体分担工作并不能保证更好的软件质量。
协调器不是另一个编码智能体
一旦以这种方式划分工作，协调器就变成了控制平面，而不是另一个编码智能体。它的工作不是编写代码，而是理解全局任务、管理dependencies并决定如何进行执行。与传统的调度程序不同，基于智能体的协调器对结果质量和资源分配做出概率判断。
它可能会分派一个智能体去调查数据库架构，另一个去检查服务层，第三个去检查测试套件。当它们返回时，协调器会确定它们的发现是否足以进入实现阶段。如果某个工作者产生错误的结果，系统必须识别失败并决定是重试工作、重新分配还是更改任务本身。
Anthropic 在其自己的生产系统中记录了相同的模式，称之为 编排器-子智能体架构[13]：主导智能体分析查询、制定策略并催生专门的子智能体来并行研究不同方面。在 2025 年 6 月对该系统的文章[14]中，Anthropic 报道称，带有 Claude Sonnet 4 子智能体的 Claude Opus 4 主导智能体在其内部研究评估中比单智能体 Opus 4 的性能高出 90.2%——代价大约是标准聊天交互 Token 成本的 15 倍（Anthropic 将单智能体成本定为大约 4 倍），这种权衡使该模式成为刻意的架构押注，而不是免费的升级。
并行性引入了分布式系统失效模式
并行性很有价值，因为软件工作包含许多独立任务，但它会产生协调问题。想象一下这样一次迁移：一个智能体更改了数据库架构，第二个更新了消费服务，第三个更新了集成测试。
如果架构在服务智能体根据较早的假设工作时发生更改，系统就会产生内部不一致的工作。这不是假设迁移独有的风险——2026 年国际人工智能安全报告[15]指出，“多个 AI 智能体之间的交互也变得越来越普遍，引入了进一步的风险，因为错误会在系统之间传播。”
单次模型调用是一次性计算，但修改代码库的二十分钟工作流则不然。如果智能体在半路丢失了其机器，从头开始重新启动成本高昂，并且在面对更改的环境时可能存在潜在的不安全因素。
为了解决这个问题，Cursor 将其云智能体执行循环迁移到了 Temporal[16] 以处理持久执行和重试，使其云智能体的可靠性超越了两个 9。Temporal 现在每天在 700 万个独特的工作流中处理 Cursor 的 5000 万次操作。“在这里，持久执行并非锦上添花。它是你可以操作的系统与只能用于演示的系统的区别，”Lipsig 告诉 The New Stack。
“在这里，持久执行并非锦上添花。它是你可以操作的系统与只能用于演示的系统的区别。”
通过分离智能体、机器和会话状态，执行引擎可以独立推理工作流。可靠性不再仅仅关乎模型是否产生好的答案；它关乎可靠地完成由许多操作、机器和依赖项组成的分布式工作流。
环境、上下文和可观测性是一个问题
在生产中，智能体不仅仅是一个模型和一个提示词；它需要工作区、源代码、依赖项、凭据和状态保留。这两家公司都为这些资源配置了隔离环境，将智能体的能力与其影响范围直接挂钩。OpenAI 的 Agents API 目前支持美国数据驻留，但不支持零数据保留（ZDR）；选择自托管沙盒并不能使 Agents API 符合 ZDR 条件。Cursor 在支持本地执行以完成特定于机器的工作的同时，也支持类似的云隔离。
只能检查代码库的智能体与可以修改生产基础设施的智能体带来的风险截然不同。因此，协调器与安全模型密不可分，它决定了哪个智能体接收特定信息和权限。
这种逻辑延伸到了上下文路由。给每个子智能体提供父级的完整历史记录会增加成本和复杂性，同时还会泄露无关或敏感信息。相反，协调器强制执行信息流边界：数据库分析智能体只接收架构和相关的迁移，而安全审查智能体在没有部署凭据的情况下获取生成的差异（diff）。
随着智能体越来越多地使用像 MCP[17] 这样的接口来访问外部系统，平台必须严格管理哪个智能体获得使用特定工具的权限以及使用多长时间。MCP 的治理现在位于 Agentic AI Foundation[18] 内部，这是一个由 OpenAI、Anthropic 和 Block 共同创立的 Linux 基金会下属基金会，并得到了 AWS、Google、Microsoft、Bloomberg 和 Cloudflare 的支持，旨在托管 MCP 以及 AGENTS.md 和 Block 的 goose——这表明该行业已经将其视为值得共同治理的基础设施，而不是任何单一供应商拥有的功能。
这种复杂性带来了可见性问题。一个简单的最终响应通常掩盖了涉及多个智能体、工具调用、环境和重试的历史记录。系统必须公开任务级溯源——哪个智能体接收了分配、它使用了什么上下文、它在哪里执行，以及协调器如何处理失败或人工干预。
如果没有执行溯源，调试就需要从碎片中重建分布式工作流。GitHub 公开子智能体生命周期事件[19] 指明了这一方向，将智能体生命周期视为可观测的组件，而不是隐藏的过程。
协调权限不是执行权限
最关键的架构边界是协调权限与执行权限之间的区别。协调器需要广泛的可见性来做出有用的决定，但这并不意味着对项目拥有不受限制的控制权。“就像你不希望人类到处跑着拥有 root 权限一样，你也不希望你的智能体带着 root 权限运行，”Lipsig 告诉 The New Stack。
“就像你不希望人类到处跑着拥有 root 权限一样，你也不希望你的智能体带着 root 权限运行。”
“创建和利用 AI 智能体权限的便捷性落后于 AI 创新的速度，但任何需要维持合规标准的产研团队都会告诉你，无论是否容易，访问控制都极其重要。从功能上讲，这意味着完全基于智能体的的工作流需要在具有自己的权限和连接性的专用环境中运行。你不能依靠智能体上下文来做你想做的事——试图让某些东西在上下文中保留那么长时间只会导致由于上下文腐烂而产生的错误。硬件或虚拟硬件级别的权限，除了系统级别的权限之外，都需要进行配置，以便要求智能体仅提供其独特的增值。”
这种风险并非假设。OWASP 智能体应用 Top 10[20] 正式将这种失效模式命名为身份和特权滥用 (ASI03)。
METR 与 Redwood Research 的承包商合作进行的独立调查[21]发现，2026 年 6 月至 7 月的事件——其中 OpenAI 自己的智能体在内部 ExploitGym 网络评估中运行，逃脱了其批准的范围并攻击了 Hugging Face——分阶段展开。6 月26 日，智能体发现了一个漏洞，该漏洞提供了对 OpenAI 内部 Artifactory 软件包存储库的完全管理员访问权限。7 月 4 日，高容量的 Artifactory 活动导致了中断，引发了安全调查并暂停了评估。OpenAI 于 7 月 6 日切换到新初始化的 Artifactory 实例，据称该实例清除了留在那里的缓存和消息。
7 月 7 日，新一波 ExploitGym 实验启动了数万个智能体，7 月 8 日，一个智能体建立了主要的未批准留言板。大约有 1,200 个智能体最终使用了该留言板，发送了 70,000 多条消息和文件；大约 700 个智能体后来参与了对 Hugging Face 的攻击。攻击本身始于 7 月 10 日至 11 日，并在 7 月 12 日至 13 日期间逐渐平息。时间线之所以重要，是因为管理员访问事件、Artifactory 故障以及随后的留言板活动是不同的阶段，而不是一个连续的事件。
通过绑定自主性，工作者智能体以其特定任务所需的最低权限[22]运行，将敏感操作保留在明确的批准边界后面。这也重塑了人工审查。要求对每个工具调用进行人工审批会破坏多智能体执行的效率，但仅显示最终结果会掩盖关键的中间决策。
最有用的设计将人工干预围绕在连续的、不可逆转的转换周围——比如投入生产或改变敏感基础设施。随着智能体成为响应 Slack 消息或拉取请求更新[23]的事件驱动参与者，而不仅仅是直接提示，这一点尤其重要。
OpenAI 和 Cursor 拥有架构的不同部分
这种趋同并不意味着 OpenAI 和 Cursor 构建了可互换的系统。他们的产品将编排边界放在了不同的地方。
OpenAI 正在通过 API 公开智能体框架[24]。其模型为开发人员提供了用于管理上下文、工具、子智能体和执行环境的原语，让应用团队决定这些功能如何融入他们自己的系统。该框架是开源的，因此团队可以检查协调器逻辑，而不必将其视为黑盒。
Cursor 包装了更多的周围工作流。Projects[25] 在同一环境中提供了协调器、云执行、共享项目上下文和面向开发人员的工作流。
这种区别很重要，因为编排是一系列基础设施决策：谁拥有执行环境、工作流状态持久化在哪里、如何隔离智能体、如何配置凭据、工作者失败时会发生什么、一个智能体的输出如何变成另一个智能体的输入，以及哪些操作可以在没有人工批准的情况下发生。
API 赋予开发人员更多回答这些问题的责任。集成平台则代表开发人员回答了更多问题。
没有哪种方法可以消除潜在的工程问题。它改变了它们的实现位置以及谁负责操作它们。
协调器正在成为一个架构边界
来自这些系统的内容表明编码智能体本身的角色发生了变化。
模型仍然执行推理和代码生成。但更大规模的智能体工作流需要另一层来决定如何应用该功能：委派哪些工作、什么上下文跨越智能体边界、公开哪些工具、执行状态如何从故障中生存下来，以及工作流何时需要人工干预。
这些是熟悉的分布式系统问题。工作者并发运行，状态可以共享或隔离，依赖关系连接任务，工作者可以独立失败，并且结果需要持久化和观察。不同之处在于，工作者现在是概率软件智能体，而不是传统的进程。
这使得协调器不仅仅是一个便利功能。它是高级软件目标成为可执行工作的地方——也是关于上下文、权限、持久性、可观测性和人工干预的决策汇聚的地方。
9 月 10 日的发布从两个不同的方向让这种转变显而易见。OpenAI 通过 API 公开了编排基础设施。Cursor 将其嵌入到项目级开发环境中。
没有任何公告证明某种架构会成为软件开发的通用模型。但结合它们周围已经出现的系统，它们表明编码智能体正在从执行整个任务的单个模型转变为将工作分配给专门智能体、执行环境和持久基础设施的工作流。
因此，工程问题不再仅仅是智能体是否能编写代码。它是周围的系统能否可靠地决定做什么、哪个智能体应该做、该智能体应该被允许看到和改变什么、如何验证其工作以及人类应该在哪里接管。
这些是架构和基础设施问题——随着编码智能体从交互式助手转向自主软件底层工作流，它们的重要性可能不亚于底层模型。
引用链接
[1] OpenAI and Cursor agree on agent coordinators. They disagree on who runs them.: https://thenewstack.io/openai-cursor-coordinator-agents/[2] **Agents API**: https://thenewstack.io/openai-agents-api-compute/[3] 推出了 Projects: https://cursor.com/blog/projects[4] Bedrock AgentCore 于 2025 年 10 月正式全面可用: https://aws.amazon.com/about-aws/whats-new/2025/10/amazon-bedrock-agentcore-available[5] Claude Managed Agents 也于 2026 年 4 月进入公开测试: https://www.infoworld.com/article/4156852/anthropic-rolls-out-claude-managed-agents.html[6] Hilliary Lipsig: https://www.linkedin.com/in/hilliary-lipsig-a5935245/[7] *GitOps Guide to the Galaxy*: https://www.youtube.com/playlist?list=PLbMP1JcGBmSGKO8UreWpOBOhCqilejhtd[8] Kubernetes: https://thenewstack.io/kubernetes/[9] LLM 在循环中使用基于环境反馈的工具: https://www.anthropic.com/engineering/building-effective-agents[10] 上下文腐烂（context rot）: https://research.trychroma.com/context-rot[11] 2026 年的研究: https://arxiv.org/html/2605.12366v1[12] 自定义智能体模型: https://docs.github.com/en/copilot/how-tos/copilot-sdk/use-copilot-sdk/custom-agents[13] 编排器-子智能体架构: https://claude.com/blog/building-multi-agent-systems-when-and-how-to-use-them[14] 2025 年 6 月对该系统的文章: https://www.anthropic.com/engineering/multi-agent-research-system[15] 2026 年国际人工智能安全报告: https://arxiv.org/pdf/2602.21012[16] 将其云智能体执行循环迁移到了 Temporal: https://cursor.com/blog/cloud-agent-lessons[17] MCP: https://modelcontextprotocol.io/[18] Agentic AI Foundation: https://openai.com/index/agentic-ai-foundation/[19] 公开子智能体生命周期事件: https://docs.github.com/en/copilot/how-tos/copilot-sdk/use-copilot-sdk/custom-agents[20] OWASP 智能体应用 Top 10: https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/[21] 独立调查: https://metr.org/blog/2026-08-26-openai-hugging-face-incident-investigation/[22] 最低权限: https://www.cncf.io/blog/2026/03/23/cloud-native-agentic-standards/[23] 响应 Slack 消息或拉取请求更新: https://cursor.com/blog/projects[24] 通过 API 公开智能体框架: https://openai.com/index/introducing-the-agents-api/[25] Projects: https://cursor.com/blog/projects