Codex 现在可以在等待回复时继续编码

长期运营编码代理当他们需要开发者的意见时，会面临尴尬的选择。他们可以停下来等待，也可以假设自己继续工作。现在，OpenAI 正在为 Codex 测试第三种选项，允许代理提问，继续处理不依赖答案的工作，然后在开发者回复时调整。

周二，OpenAI将send_user_message_async合并进了公开的Codex仓库。一旦Codex发送消息，工具会立即返回接受的回复给模型。Codex 随后可以调用其他工具、检查另一个文件，或继续生成答案，而不是闲置。

该功能尚未作为通用Codex功能宣布，公开代码也未说明将优先接收哪个模型或Codex接口，但这证明OpenAI正在处理编码代理与开发者监督之间的不同关系。

OpenAI在发布前未回应新堆栈的问题。

异步消息取代了屏蔽

Codex 已经有一个request_user_input工具，可以向开发者提问;它的工作原理是等待响应后再将控制权交还给模型。

使用异步工具时，Codex 不会等待，直接向开发者发送问题或更新，收到消息被接受的确认后，继续当前回合。任何回复都会以新用户消息的形式返回。

随变更附带的积分测试展示了这种差异。测试中Codex发送了“仍在调查中”的更新。工具返回已接受的结果，模型在同一回合内获得另一次回应机会，然后才发送最终消息。

Codex可以报告其工作内容或请求决策，同时继续工作，而这些工作不依赖于回答。

OpenAI还避免在模型输入中插入面向开发者的更新的第二个合成副本。原始工具调用及其接受结果仍属于交换，但该消息不会作为正常助手响应再次添加。

作为一种副渠道，Codex可以报告其工作内容或请求决策，同时继续工作，不依赖于回复。

根据合并代码中的注册逻辑，子代理不会接收该工具。使用多个子代理的Codex任务仍然会有一名负责通信的代理和开发商一起。

旗帜数小时内被移除

该工具最初要求两个条件。开发者必须启用实验性send_async_message功能标志，所选型号必须宣传对该工具的支持。OpenAI不到一天后就取消了第一个要求。

第二个合并拉取请求将本地标志标记为移除，使模型支持成为唯一剩余的交换机。

现在，只要所选模型将send_user_message_async列为支持的实验工具之一，Codex 就会为根代理注册该工具。包含旧标志的现有配置仍然可以接受，但设置不再控制该工具是否出现。

这一变化表明，OpenAI打算通过模型元数据来控制可用性，而不是要求开发者启用实验性的Codex设置。公开仓库未公布支持模型，未提供发布日期，也未说明该工具是否会优先出现在ChatGPT工作中，Codex 桌面应用， CLI，或 IDE 扩展。

没有检查点，就没有回滚

保持Codex移动可以节省时间，但也会产生一个时间问题.比如Codex问一个项目应该用PostgreSQL还是SQLite。它可以在等待时检查仓库或运行测试，但没有任何强制要求在该决定影响代码之前停止。

Codex 可以在开发者回复 PostgreSQL 之前开始实现 SQLite。

没有检查点阻止代理人越过决策，Codex也不会自动撤销与开发者最终决定冲突的工作。

如果Codex在等待回复期间继续工作，拉取请求并不会引入解决冲突的方法：问题永远不会失效，没有检查点阻止代理越过决策，Codex也不会自动撤销与开发者最终决定冲突的工作。

回复也没有明确附着在促使它提问的问题上。虽然发出消息包含内部工具调用ID，但开发者的回答以普通用户输入的形式返回，而非与该特定问题相关的结构化响应。

转向或重启，而不是调和

Codex Core暴露了一条起始或引导的路径。如果线程很忙，输入端可以引导主动转弯。如果Codex在消息到达时处于空闲状态，同一输入可以开始新一回合。

这些检查只会确定消息应该去哪里，但它们不能判断指令是否已经过时。

如果开发者在原回合仍在进行时回应，Codex可以在下一次模型调用中使用该答案。如果回合已经结束，答案会变成后续请求。无论哪种情况，Codex 都必须将新指令与已完成的工作进行比较，决定哪些需要更改，这可能意味着撤销它刚写好的代码，因为它朝着开发者从未打算的方向发展。

当工作超出等待的决定时，Codex就得自己管理后果。

该岗位Codex 现在可以在等待你回答的同时继续编码最初发表于新书堆.