大家好，我是 Dom，在 OpenAI 负责 Codex 的开发体验。我想先做个小调查：有多少人已经构建过自己的 Agent Harness？又有多少人觉得这太令人望而生畏了？在接下来的 18 分钟左右，我想和大家聊聊如何基于 Codex Harness 进行开发，希望这能让你们构建自定义 Agent 界面变得更轻松、不那么可怕，同时也更有趣。
还有一个举手调查：有多少人听说过 Codex App Server？这其实是个陷阱题，因为如果你们昨天参加了主题演讲，应该都举手了。否则可能没听 Roman 讲过。我们昨天简要提到了它，但并未深入解释 App Server 是什么。实际上，App Server 是封装 Codex Harness 的协议。如果你研究过 Agent Client Protocol (ACP)，概念非常相似：这是一种允许你直接在 Harness 之上构建并深度集成的协议。
请记住，Codex Harness 和 App Server 本身都是开源的。我们稍后会介绍如何与之互动，明天下午还会深入探讨其背后的工作原理。当然，你也可以直接让 Codex 阅读代码库进行深入学习。它采用 Apache 2.0 许可证，欢迎 Fork、修改并自由使用。只要模型提供商支持兼容的 Responses API，你甚至可以将它连接到任何其他模型提供商。我们还提供了便捷设置，方便连接 LM Studio 或 Ollama。
App Server 协议是一种 JSON-RPC 风格的协议，我们用它来驱动 Codex App、IDE 扩展以及 VS Code 插件等所有第一方界面，同时也支持第三方应用。如果你通过 Xcode、JetBrains IDE 或 Theos T3 Code、Remote X 等开源项目使用过 Codex，它们背后都由相同的 Harness 和 App Server 驱动。今年早些时候，我们还利用它通过 Cloud Code 插件集成 Codex，用于代码审查或任务处理。
从高层来看，App Server 的工作原理是客户端（你构建的应用）与服务器端（Codex App Server）之间发送消息以执行不同操作并接收事件。为了展示真实情况，我构建了一个拦截器来捕获 Codex App 与 Server 之间的所有事件。现在让我切换到 Codex App，我在浏览器中加载了该拦截器。当我们发送消息时，会看到一系列事件流入。
起初这可能看起来有些复杂，但仔细查看这些消息后，你会发现很多内容相当熟悉。比如线程启动、配置读取、数据流式传输的增量消息等，其中包含大量额外信息。该协议之所以灵活，是因为它暴露了应用中的关键功能。无论是流式传输还是文件搜索，所有信息都在 App Server 和 App 之间来回传递。
目前我们有超过 120 种不同的客户端消息，并持续增加。这涵盖了从初始化配置、线程修改和对话轮次等经典功能，到设置目标模式（Goal Mode）、列出插件、文件搜索及文件系统修改等全方位访问权限。与更通用的 ACP 不同，我们还通过协议提供了对 Harness 各个部分的更多控制权限。
另一个令人兴奋的功能是支持使用 ChatGPT 登录集成此协议的用户可以使用自己的 ChatGPT 订阅，从而计入他们的 Codex 使用限额。如果你使用的是 T3 Code 等类似工具，实际上就在利用这一机制。在自定义 Agent 方面，最重要的两点是开发者指令（用于增强系统提示词）和工具集成。
我们通常建议您在开发者指令中进行追加。这样，您既能利用我们为各个模型微调提示词所做的工作，又能针对您的特定用例对 Harness 进行定制。例如，当您启动 Codex App 时就是这样做的，因为有些功能比 IDE 扩展或 CLI 示例更具体地针对该 App。此外，这部分内容还包括动态工具，您可以暴露希望 Agent 能够使用的额外函数。
您可以使用 MCP 或其他类似于代理客户端协议的方法，也可以直接定义工具，并实际上将它们标记为延迟加载。这意味着它们不会注入到系统提示词中，而是允许 Codex 使用工具搜索功能（我们将在明天的另一场会议中详细介绍），通过工具搜索来发现这些工具，而不是污染整体的上下文窗口。
在此基础上，您还可以针对每个线程修改 Agent 的任何其他配置。例如，设置不同的模型提供商、选择不同的模型，甚至对沙箱进行细粒度控制，比如它应该访问哪些网络连接或可以修改哪些文件。
关于如何使用 App Server，首先要知道的是，App Server 实际上是 Codex CLI 的一部分，它是同一个二进制文件。因此，如果您的系统上已经有 Codex CLI，您可以直接使用它来启动 App Server。
但您也可以查看我们如何将其随 Codex App 一起分发。Codex App 将二进制文件作为实际捆绑包的一部分包含在内。因此，如果您查看已安装的 Codex App，您应该在捆绑包的內容中找到它，并且它会随着每次更新应用版本而变化。
我们在后台分发 CLI 的新版本。在 Windows 上，我们实际上随附了两个版本的二进制文件：Linux 编译版和 Windows 版本。因此，如果您以 WSL 模式加载 App，它将使用 Linux 版；否则，它将在 Windows 原生模式下启动 App Server。
从这里开始，您实际上拥有许多不同的额外便捷功能。首先，您可以让 Codex 为该特定版本的 App Server 生成 TypeScript 绑定或 JSON Schema。这非常有用，因为该协议在版本之间经常发生变化。
这也是为什么您希望将其与应用程序捆绑在一起的原因，就像我们在 Codex App 中所做的那样，以便完全控制您所期望构建的版本具有哪些实际功能。
在协议方面，您可以通过标准输入输出（STDIO）或 WebSocket 启动 App Server。这取决于您的用例，老实说，弄清楚哪种方式更适合您最简单的办法可能是直接询问 Codex。
从这里开始，有两种最容易集成它的方法。第一种是我们最近重新发布的 Python SDK。它为处理许多生命周期管理任务，因此您无需担心这些细节。
此外，它使集成诸如通过 ChatGPT 登录等功能变得更加容易，并为您提供熟悉的界面。话虽如此，我们正处于一场 AI 工程师会议上，所以可能大多数人会选择第二种方式，即直接询问 Codex。
毫不奇怪，Codex 在实现此协议方面非常出色，您基本上只需要指向文档即可。大多数情况下，甚至不需要这样做，但有时有助于推动它进展。
从这里开始，您可以将其与我们任何插件结合使用，例如构建 macOS App 以快速启动某些内容或完全发挥创意。我曾用它通过 Visual Basic 构建一个客户端，以创建一个真正的 Windows 原生 App，而且它在一次操作中就完成了。
因此，您无需学习构建 Agent 的所有繁琐细节，就可以在相当短的时间内使用此技术构建非常令人印象深刻的应用程序。
然而，对我来说，这个 App Server 最有趣的地方在于您不仅限于经典的 Agent 聊天界面。您可以发挥创意，无论是在 UI 和现有应用中如何触发它、是否在后台运行、是否将其放置在像 Maddie 经常做的那样奇怪的硬件上，或者像我一样思考如何将此塞入视频中。
最近我想到了如何实际上在 Doom 中运行 Codex，而不是在 Codex 中运行 Doom。我想让我们现场演示一下，我要取消几条消息。
我有这个 Codex App 的 Doom 版本，但我启动错了窗口，让我把它拉过来。好了。这搞乱了控制设置，抱歉。稍等。这种双显示器设置有时会干扰控件捕获，希望现在能更好地工作。
好的，这是一个 Electron App，它使用 Cloudflare 的 Doom Wasm 渲染器。游戏引擎本身大部分是用 C 实现的，然后它加载 FreeDoom 游戏，但我实际上操纵了 Codex 更改的游戏文件。
您可以看到这是使用其所有游戏引擎原样渲染在视频游戏中的。如果我们在这里与它交互，我们启动 Codex 并再次将其原样渲染在视频游戏中，然后通过 Electron 的 IPC 协议传递给 App Server。
所以如果我们在这里说“你好”，我们可以看到 Codex 实际上正在响应。这是使用 5.5 版本。不过有趣的是，您可以实际使用动态工具来暴露额外功能。
自然地，我们可以获取所有盔甲和生命值，它调用工具给了我所有这些内容，或者说包括所有弹药的所有武器。它在调用不同的工具并与之交互，但请记住这实际上是在我的机器上运行的 App Server。
所以如果我说“目录是什么？”，它实际调用 Z shell 获取当前工作目录，您可以看到这里渲染的是它具有自己的工作空间。所以如果您愿意，可以直接在 Doom 中编写代码。不确定我是否推荐这样做。
我认为 Codex App 对此稍好一些。但您可以在这里真正玩得开心并实现自己的界面。太好了。在演出期间我已经和你们中的一些人谈过了，关于……
关于 App Server，有一个经常被问到的问题是它与 Codex Exec 有什么区别。如果你之前使用过 Codex CLI，你可能对此有所了解。还有一个名为 Codex Exec 的命令，它为你启动一个非交互式界面，以便向 Codex 传递任务或发起操作。这对于脚本编写非常有用。如果你正在构建 CI/CD 实现，并希望自动化某些步骤（例如自动修复 Pull Request），这是一个很好的机会。
但是，如果你试图构建一个更全面的客户端界面来与代理交互；或者更重要的是，如果你想同时启动多个不同的 Codex 线程（例如运行你自己的评估框架 Harness，或使用类似 /goal 的功能），那么 App Server 才能真正发挥其优势。因为它让你对框架拥有完全的控制权，你不需要自己想办法并行化所有的 Codex Exec 调用，而是只需发送新线程事件并以此方式启动任务即可。
在让大家去听主题演讲之前，我再分享三个小贴士，回顾一下我们讨论的内容以及使用 App Server 时需要注意的事项。第一点是你应该自行打包（ship）自己版本的 Harness。如果你依赖用户安装的 CLI，即使我们努力减少破坏性变更，你仍会不断遇到问题；而且如果依赖实验性功能更是如此。
此外，你也不必担心用户是否已更新版本以使用你想要的最新功能，或者是否需要催促他们进行更新。因此，请打包你自己的 Harness 版本。另一部分是你应该将新函数作为接口的一部分暴露出来。例如在 Codex App 中，为了能让代理在线程内控制自身（如启动自动化等），我们会这样做。
但请将这些函数标记为“延迟执行”（deferred）。这样你就不会不必要地污染上下文窗口，避免添加的所有额外函数造成干扰，同时仍能让代理使用它们而不会感到困惑。如果你正在更改指令，请尝试通过添加开发者说明来开始操作，而不是直接修改基础指令。
这可能会让你觉得应该立即着手编写自己的系统提示词（system prompt），但在构建 Harness 时，我们需要考虑许多不同的因素，以确保实际提示词的分布合理并保证代理的良好表现。如果你直接跳进去编写自己的系统提示词，就会失去所有这些优势。所以如果这样做请谨慎小心。
非常感谢大家的时间。如果你想获取幻灯片，欢迎扫描那个二维码。我将在 OpenAI 展位停留大约15分钟，如果你有任何问题可以随时来问我。非常感谢。