您的AI投资回报率模型中缺失的一环（赞助内容）
只有 35% 的工程领导者表示人工智能带来了显著的投资回报率，而且大多数投资回报率模型都未能反映全貌。
大部分工程时间都花在了调查警报、诊断事件以及协调不同工具之间的决策上，而这些工具之间又缺乏上下文信息共享。这项工作的成本很少体现在投资回报率模型中。
如果企业只衡量编写代码的成本，就会忽略生产过程中产生的下游成本。
了解 Zscaler、DoorDash 和 Salesforce 的工程团队如何衡量整个工程生命周期中的 AI 投资回报率，并在生产环境中获得最大回报。
OpenAI 发布其基于云的编码代理 Codex 时，他们面临的最棘手的问题几乎与 AI 模型本身无关。
该模型 codex-1 是 OpenAI 的 o3 模型的一个版本，专门针对软件工程进行了微调。它固然重要，但只是一个更大系统中的组件。真正的工程设计体现在它周围的一切。
如何从五个不同的来源收集合适的提示信息？当对话历史记录过于庞大，可能超出模型的内存容量时会发生什么？如何让同一个代理程序在终端、网页浏览器和三个不同的集成开发环境（IDE）中运行，而无需每次都重写代码？
当 Codex 团队需要让他们的智能体在 VS Code 中运行时，他们首先尝试了最直接的方法，即通过 MCP（当时新兴的 AI 模型与工具连接标准）进行公开。但这种方法行不通。真实智能体所需的丰富交互模式，例如实时显示进度、暂停任务等待用户确认以及生成代码差异等，与 MCP 提供的功能并不完全匹配。因此，团队决定从零开始构建一套全新的协议。
在本文中，我们将探讨 OpenAI 如何围绕模型构建合适的编排层。
免责声明：本文基于 OpenAI 工程团队公开分享的信息。如果您发现任何不准确之处，请留言。
什么是法典？
Codex 是一个代码代理，可以编写功能、修复错误、回答有关代码库的问题，并提出拉取请求。
每个任务都在其独立的云沙箱中运行，并预装了您的代码库。您可以并行分配多个任务，并实时监控进度。
Codex 的底层工作原理也相当有趣。该系统包含三个值得理解的层面：代理循环、提示和上下文管理，以及允许一个代理服务于多个不同界面的多界面架构。
代理循环
Codex 的核心是所谓的代理循环。代理接收用户输入，构建提示，将其发送给模型进行推理，并接收返回的响应。
然而，这种响应并非总是最终答案。通常，模型会以工具调用作为回应，例如“运行此 shell 命令并告诉我发生了什么”。此时，代理会执行该工具调用，将输出附加到提示符，并使用这些新信息再次查询模型。这个循环会重复进行，有时甚至数十次，直到模型最终向用户返回消息。
请看下图：
使它不仅仅是一个简单的回路的是安全带在整个过程中所管理的一切。
Codex 可以读取和编辑文件、运行 shell 命令、执行测试套件、调用代码检查器以及运行类型检查器。例如，用户提交的“修复身份验证模块中的错误”这样的请求，可能会触发代理读取多个文件、运行现有测试以查看哪些测试失败、编辑代码、再次运行测试、修复代码检查错误，并在最终提交之前再次运行测试。
模型负责每一步的推理，而框架则负责处理其他所有事情，例如执行命令、收集输出、管理权限以及决定循环何时结束。
模型和工具之间的这种区别至关重要，因为它决定了开发者实际使用 Codex 的方式。OpenAI 自己的工程团队就利用 Codex 来卸载重复性、范围明确的工作，例如重构、重命名、编写测试以及处理值班问题。
智能体循环还有一个外层。每次推理和工具调用构成 OpenAI 所说的“回合”。然而，对话并不会在一个回合后结束。当用户发送后续消息时，之前所有回合的历史记录，包括所有工具调用及其输出，都会包含在下一个提示中。这正是计算成本增加的地方，也是下一层复杂性发挥作用的地方。
请看下图：
构建提示，管理记忆
当你在 Codex 中输入请求时，你的消息会成为更庞大提示信息的底层。在其上方，系统会堆叠环境上下文，例如你当前的工作目录和 shell、仓库中所有 AGENTS.md 文件的内容（这些文件是针对代理的项目特定指令，涵盖编码规范和要运行的测试命令等内容）、沙箱权限规则、配置文件中的开发者指令、模型特定指令、工具定义以及系统消息。
每一层都扮演着不同的角色，可以是系统、开发者或用户，这些角色向模型表明了其优先级。服务器控制着顶层的顺序，客户端控制着其余层。这种分层结构意味着模型始终能够获取其运行环境的丰富上下文信息。然而，这也意味着在用户开口说话之前，提示信息就已经非常庞大，而且只会随着用户说话而不断增加。
模型每次调用工具都会产生输出，并将输出附加到提示信息中。每个新的对话回合都包含之前所有回合的完整历史记录，包括工具调用记录。
请看下图：
这意味着在一次交互过程中，发送到 API 的 JSON 数据总量呈平方级增长。如果第一轮发送了 X 数据，第二轮会重新发送所有 X 数据加上新数据，第三轮会重新发送所有这些数据加上更多内容，依此类推。
OpenAI有意承担了这部分成本。他们本可以使用服务器端参数让API记住之前的对话状态，从而避免重新发送所有内容。但他们没有这样做，因为这样做会破坏每个请求的无状态性，并妨碍对需要零数据保留的客户的支持。因此，每个请求都是独立的，并携带完整的对话内容。
关键的缓解措施是提示缓存。由于 Codex 总是将新内容附加到现有提示的末尾，因此旧提示始终是新提示的精确前缀。这种前缀特性使得 OpenAI 可以重用先前推理调用中的计算结果，因此即使数据传输是二次方的，实际的模型计算也更接近线性。
然而，前缀属性非常脆弱。任何改变提示符开头或中间部分的操作，例如切换模型、更换工具或更改沙箱配置，都会破坏缓存。OpenAI 在添加对 MCP 工具的支持时，意外引入了一个 bug，导致工具在不同请求中的排列顺序不一致。仅此一项不一致性就足以破坏缓存命中。
最终，即使启用了缓存，对话也会达到上下文窗口的限制，即模型在单次推理调用中可以处理的最大词元数。此时，Codex 会压缩对话。它会将完整的历史记录替换为一个更小、更具代表性的版本，该版本通过一个加密的有效载荷来保留模型对事件的理解，该有效载荷承载着模型的潜在状态。实际上，压缩机制比简单的摘要要复杂得多，但核心思想不变：管理上下文窗口是一个重要的工程问题，而不是事后考虑的因素。
这里需要简要提及 AGENTS.md 文件，因为它们体现了关于上下文信息存放位置的设计决策。OpenAI 并没有将项目特定的知识硬编码到系统中，而是允许开发者将 AGENTS.md 文件放在代码仓库中，与代码并列。这些文件告诉 Codex 如何浏览代码库、运行哪些命令进行测试以及如何遵循项目的约定。模型在使用这些文件时性能更佳，但即使没有这些文件也能正常工作。
让它在任何地方都能发挥作用
Codex 最初是一个命令行工具。你可以在终端中运行它，它会操作你的本地代码库。
随后，OpenAI 需要在 VS Code 中使用它，之后又需要在 Web 应用中使用它。此外，它还需要一个 macOS 桌面应用版本。最后，像 JetBrains 和 Xcode 这样的第三方 IDE 也希望集成它。为每个界面重写代理逻辑显然是不可行的。
如前所述，最初的尝试是将 Codex 作为 MCP 服务器运行。然而，团队发现 MCP 的语义无法完全展现智能体对话的实际运作方式。Codex 需要随着模型推理的进行逐步更新进度，需要在执行某些命令前暂停并征求用户许可，还需要生成结构化的差异信息。这些交互模式对于当时的 MCP 来说过于复杂。
于是他们构建了应用服务器。所有核心代理逻辑，包括代理循环、线程管理、工具执行、配置和身份验证，都集成在一个 OpenAI 称为“Codex 核心”的代码库中。应用服务器使用 JSON-RPC 协议封装了这个核心，任何客户端都可以通过标准输入/输出与之通信。
该协议是完全双向的：
-
客户端可以向服务器发送请求（启动线程、提交任务）。
-
服务器还可以向客户端发送请求，例如，在执行 shell 命令之前请求批准。
代理的回合会暂停，直到用户响应“允许”或“拒绝”。这使得代理能够在自主性和人工监督之间取得平衡，而无需将该策略硬编码到代理循环本身中。
不同的地方对这种建筑的运用方式各不相同。
-
VS Code 扩展和桌面应用程序捆绑了 App Server 二进制文件，将其作为子进程启动，并保持双向 stdio 通道打开。
-
Web 应用在云容器内运行应用服务器。工作进程使用检出的代码仓库配置容器，启动二进制文件，并通过 HTTP 将事件流式传输到浏览器。状态存储在服务器上，因此即使用户关闭标签页，工作也会继续进行。
-
像 Xcode 这样的合作伙伴通过保持客户端的稳定性，并在新版应用服务器二进制文件发布后将其指向新版本，从而将自身的发布周期与 OpenAI 的发布周期解耦。该协议的设计具有向后兼容性，因此旧版客户端可以安全地与新版服务器通信。
这种架构并非一开始就规划好的。它从命令行界面 (CLI) 演变而来，经历了 MCP 协议的失败尝试，最终发展成为如今支撑所有 Codex 界面的应用服务器协议。这一发展轨迹本身就为系统设计提供了一个有益的启示：正确的抽象方式往往只有在尝试过错误的抽象方式之后才会出现。
结论
OpenAI 的经验证明，模型只是系统的一个组成部分，而智能体才是系统本身。大部分工程工作都集中在系统层面。
如果您使用 Codex 之类的工具，了解这些机制将有助于您更有效地使用它们。编写清晰的 AGENTS.md 文件可以为代理提供项目特定的上下文，从而显著改善其输出。任务范围限定得越严格越好，而不是模糊不清的开放式请求，因为代理循环在每个周期都有明确的下一步时效率最高。此外，由于上下文窗口限制和压缩，长时间的对话会降低效率，这也解释了为什么为新任务创建新线程通常会带来更好的结果。
Codex 仍然存在一些实际的局限性。它无法接受用于前端工作的图像输入。你无法在任务进行过程中调整代理的运行方向。将任务委托给远程代理比交互式编辑耗时更长，而且这种工作流程的转变需要时间适应。OpenAI 正在努力实现未来与 Codex 的交互体验更接近于与同事的异步协作，但这一愿景与当前产品之间仍然存在显著差距。
参考：