Codex钩子让代理框架真正成形

OpenAI于2026年5月14日将Codex接入ChatGPT移动应用。公告中更关键的变化写在后面：Remote SSH和钩子已正式可用，Business与Enterprise方案也获得了程序化访问令牌。¹

这改变了工作的性质。Codex不再像一个守在单个终端里的编程助手。它更像一个操作层，能够跟随工作穿过机器、审批、线程、差异、测试、截图、插件、凭据和本地工具。²

Codex钩子让代理框架真正成形。 当代理可以从手机上工作、触达远程开发环境，并运行生命周期钩子时，团队就需要围绕模型建立一套控制系统：证据、审批、Git管护、来源纪律和品味。

简要概览

Codex现在支持了代理团队长期在内部搭建的工作流形态：长时间运行的工作、远程执行、移动端调度、审批、钩子、作用域受限的凭据，以及审计信号。¹²³ 提示词仍然重要，但操作层更重要。

真正的问题不是“如何给Codex写提示词？”真正的问题是“Codex必须证明什么，我们才信任结果？”团队应使用钩子和配置来编码审查关口、安全边界、公共写作标准和发布纪律。私有机制应保持私有；公开的应该是模式、验收标准和经过验证的结果。

关键要点

对于工程团队： - 将Codex钩子视为流程基础设施，而不是装饰。 - 先建立证据、审批、Git管护和发布检查，再添加更聪明的自动化。

对于代理工具构建者： - 围绕Codex的真实表面构建：移动端控制、Remote SSH、沙箱模式、审批策略、项目指令、钩子、遥测和版本控制。 - 迁移待完成的工作，而不是照搬旧的斜杠命令形态。

对于公共写作者： - 使用OpenAI官方文档确认当前Codex行为。 - 将私有实践标注为作者分析，不要把私有提示词、钩子实现、文件路径、来源列表、凭据和评分内部逻辑写入公开文本。

5月14日发生了什么？

OpenAI在5月14日的公告中，让Codex更接近一个持久的工作界面。ChatGPT移动应用中的Codex可以连接到运行Codex的机器，加载该环境中的实时状态，并允许用户在手机上审查输出、批准命令、更换模型、启动工作，以及跟踪差异、终端输出、测试结果、审批和截图。¹

同一则公告称，Remote SSH已正式可用。Codex可以连接到远程环境，从SSH配置中检测主机，创建项目，并在远程机器上运行线程。¹ 开发者文档对远程连接的表述更具体：远程访问会使用已连接主机上的项目、线程、文件、凭据、权限、插件、Computer Use、浏览器设置和本地工具。²

OpenAI还将钩子推进到正式可用阶段。公告列出了具体用途：扫描提示词中的密钥、运行验证器、记录对话、创建记忆，以及为仓库和目录定制Codex行为。¹ 钩子文档将钩子定义为一种可扩展框架，用于向Codex循环注入脚本；配置参考则公开了features.hooks，用于加载来自hooks.json或内联配置的生命周期钩子。⁷⁶

这些细节很重要，因为它们把代理工作从聊天交换变成了受治理的操作。

为什么钩子比移动端更重要

移动端访问改变的是人可以在哪里介入。钩子改变的是系统可以强制执行什么。

手机让操作者离开桌面时也能回答问题。钩子则可以在高风险操作前、文件编辑后、完成前，或发布检查期间拦住代理。手机解决延迟问题。钩子解决标准问题。

Codex已经围绕沙箱和审批提供了官方控制表面。OpenAI的安全文档称，Codex结合了沙箱模式与审批策略：前者定义代理在技术上能做什么，后者定义Codex在行动前何时必须暂停并询问。³ 同一文档还说明，网络访问默认关闭；默认本地workspace-write模式也会保持网络访问关闭，除非用户主动启用。³

钩子位于这些控制旁边。当前钩子事件包括SessionStart、PreToolUse、PermissionRequest、PostToolUse、UserPromptSubmit和Stop；PreToolUse可以拦截受支持的Bash调用、通过apply_patch进行的文件编辑，以及MCP工具调用，但OpenAI文档也提醒，它不会拦截所有shell路径、WebSearch，或其他非shell、非MCP工具调用。⁷ 因此，钩子是审查和引导层，而不是沙箱的替代品。

钩子可以让本地标准可执行：

模型可能忘记规则。钩子可以在规则真正重要的时刻重新运行规则。

代理框架就是操作层

代理框架是模型周围的操作层：权限、记忆、工具、钩子、来源检查、发布关口、审查包和回滚纪律。这个词听起来可能私有或复杂，但任务很朴素：这一层把意图转化为可追责的工作。

Codex现在公开了足够多的官方表面，可以让这一层变得明确。远程连接携带主机环境。沙箱模式和审批策略定义行动边界。配置文件定义模型、项目、权限、MCP服务器、技能、钩子、遥测和功能。⁶ OpenTelemetry可以记录用户提示词、审批决策、工具执行结果、MCP使用情况和网络代理决策等事件。³⁴

这组表面形成了一个有用的分工：

提供方应该持续改进执行环境。团队仍然拥有判断。

团队应该先编码什么？

从4个关口开始。它们会立刻产生价值。

证据关口

Codex最初的发布文章强调可验证证据：任务完成过程中应包含终端日志、测试输出和可追踪步骤。⁵ 让这一要求不可协商。一次有意义的完成应说明修改了哪些文件、运行了哪些命令、观察到了什么行为、哪些检查失败，以及还存在哪些缺口。

对于公共工作，证据包括来源链接和声明与来源的一致性。对于网站发布，证据包括渲染路由、元数据、schema、发现文件、部署状态、缓存新鲜度和线上变更标记。对于翻译，证据包括语言覆盖、质量关口、存储行或缓存文件，以及必要时的母语审查状态。

审批关口

不要为所有操作使用同一种审批姿态。OpenAI的审批文档区分了安全的只读浏览、工作区编辑、需要审批的网络访问、不受信任的命令、自动审查模式，以及危险的完全访问。³ 强有力的本地策略也应保持相同形态：低风险读取安静通过；有副作用的工作进入审查；破坏性或外部可见的工作必须提供明确证据。

Git管护关口

代理工作需要回滚把手。Codex自己的安全文档称，Codex最适合与版本控制配合使用：委派前保持状态干净，频繁提交，运行定向验证，审查差异，并在提交消息中记录决策。³

这条建议应该变成流程。在连贯且验证过的保存点之后提交。精确暂存路径。按可独立回滚的关注点拆分提交。除非发布流程已经授予发布权限，否则推送前先询问。不要因为代理碰巧看见了无关脏文件，就把它们一起扫进提交。

品味关口

AI编程让实现更便宜。实现更便宜，品味就更有价值。

品味不是装饰性偏好。它意味着工作改善了整个产品。它意味着代理可以拒绝一条技术上可行但会削弱结果的路径。它意味着公共写作避免私有机制、无依据声明和填充内容。它意味着即使本地补丁正确，只要用户可见路径仍然失败，也仍然不合格。

品味关口应该提出这些问题：

Mozilla展示了同一种模式

Mozilla在5月7日关于使用Claude Mythos Preview加固Firefox的文章中，从另一套技术栈说明了同一个观点。团队表示，早期LLM代码审计尝试展现了潜力，但误报太多，难以规模化。代理式框架改变了成本结构，因为它们可以创建并运行可复现测试用例，动态测试漏洞假设。⁸

Mozilla最重要的一句话并不只是关于模型。团队说，发现问题是必要条件，但并不充分。真正有用的系统必须与完整的安全漏洞生命周期集成：目标、去重、漏洞跟踪、分诊、修复和发布。⁸ 作者还表示，该流水线反映了Firefox代码库的语义、工具和流程。⁸

这正是Codex的启示。更好的模型很重要。模型周围的运营系统决定了工作能否成为可信输出。

什么不该公开

公开的Codex文章不应该倾倒私有工作系统。

这些内容不要写入公开文本：

• 私有提示词和钩子实现；
• 敏感本地路径；
• 精确来源映射和评分内部逻辑；
• 账户标识符和凭据处理方式；
• 私有工作流捷径；
• 未发布的插件行为；
• 任何帮助陌生人重构内部操作的内容。

应公开的是模式：关口保护什么、要求什么证据、能捕获什么失败，以及团队如何使用官方Codex表面实现这个想法。

这条界线保护信任，也让文章更好。私有机制通常读起来像圈内传说。公开的验收标准则能帮助其他团队推理自己的系统。

一张实用的Codex代理框架图

构建最小的控制图，证明有用的工作。

先显式化。运行一个真实任务。记录关口在哪里有帮助，哪里造成阻碍。只提升那些确实改善用户可见结果的部分。

快速总结

Codex钩子、Remote SSH、移动端控制、沙箱、审批、配置、遥测和版本控制都指向同一个方向：编程代理需要围绕自身建立操作系统。¹²³⁴⁶ 代理可以写代码。代理框架决定什么才算工作。

最优秀的团队不会靠产出最多代理结果取胜。它们会靠让代理工作可检查、可回滚、有来源、有品味，并且值得发布而取胜。

常见问题

什么是Codex钩子？

Codex钩子是生命周期钩子能力，可以从hooks.json或内联配置运行。OpenAI公告称，钩子可以扫描提示词中的密钥、运行验证器、记录对话、创建记忆，并为特定仓库和目录定制Codex行为；钩子文档列出了PreToolUse、PermissionRequest、PostToolUse、UserPromptSubmit和Stop等事件。¹⁷

为什么Codex钩子重要？

钩子让团队把标准放在决策点，而不是只依赖提示词。当代理行动或试图完成时，钩子可以检查证据、来源质量、Git状态或发布就绪度。

Codex移动端会取代本地代理工作流吗？

不会。移动端控制让用户可以离开桌面调度工作，但已连接的主机仍然提供项目、文件、凭据、权限、插件和本地工具。² 团队仍然需要本地策略、安全凭据、版本控制和验证。

Codex代理框架最先应该包含什么？

从项目指令、沙箱与审批姿态、密钥边界、证据停止关口、精确路径Git管护、公共声明的来源验证，以及用户可见工作的发布关口开始。

团队应该公开自己的Codex钩子吗？

公开模式和验收标准，不要公开私有钩子实现或敏感工作流细节。一篇有用的公开文章可以解释钩子的职责，而不暴露私有路径、来源映射、提示词、凭据或评分规则。

参考资料