OpenClaw 采用 Codex 引擎优化 OpenAI 代理运行时
OpenClaw 现在默认使用 Codex 应用服务器引擎来驱动 OpenAI 代理的模型循环，将底层模型推理与上层产品功能分离。这一变化减少了工具重复、提示膨胀和翻译开销，带来了动态工具加载、更加清晰的消息传递和心跳机制，以及基于订阅的认证。未来，这些改进将逐步惠及其他模型提供商。
OpenClaw 近日宣布了一项重要更新：其平台现在默认使用 Codex 应用服务器引擎来驱动 OpenAI 代理的模型推理循环。这一改变旨在解决此前 OpenClaw 自行驱动模型循环时面临的翻译开销、工具重复和提示膨胀等问题。
在旧架构中，OpenClaw 需要在其自身框架与 OpenAI 正在积极构建的代理运行时之间进行转换。而现在，Codex 接管了底层的 OpenAI 循环，包括原生线程状态、工具延续、压缩、代码模式和动态工具搜索。OpenClaw 则专注于使其代理成为用户专属助手的产品功能：渠道、个性、记忆、会话、定时任务、媒体、浏览器、网关以及 OpenClaw 工具。
这一重新划分边界带来了多项实际改进。首先，模型现在可以直接使用 Codex 原生的读写、编辑、修补、执行、进程和规划工具，而无需在重复的工作空间工具之间做出选择。其次，可见回复现在通过 OpenClaw 消息工具有意发送，使内部推理保持私密，只有代理真正有话要说时才会产生可见输出。心跳机制也得到升级，不再依靠“HEARTBEAT_OK”之类的标记文本，而是使用结构化心跳响应工具，明确表达“无报告”、“通知用户”或“安排跟进”等状态。
最显著的改进之一是动态工具加载。OpenClaw 代理可能拥有大量工具，包括消息、会话、媒体、定时任务、浏览器、节点、网关控制、网络搜索、MCP 服务器、插件工具和特定于渠道的动作。过去，所有工具模式都会加载到初始提示中，导致提示庞大且模型容易选错工具。现在，Codex 允许将 OpenClaw 产品能力作为动态工具传递，模型通过原生工具搜索按需发现并加载所需工具。这不仅减小了初始上下文，还提高了工具选择的准确性。
对于非 OpenAI 用户而言，这一改进同样有意义。OpenClaw 计划将从 Codex 学到的模式应用到其默认的 PI 工具搜索中，允许所有模型受益于更紧凑的搜索、描述和调用接口。目前，PI 工具搜索仍处于实验阶段，尚未默认启用。
在认证方面，用户可以使用 ChatGPT/Codex 账户登录 OpenClaw，即可通过订阅获得 Codex 认证配置文件，无需为同一模型付费两次。API 密钥可作为备份选项。OpenClaw 还为每个代理隔离了 Codex 状态，确保个人 Codex CLI 设置不会被意外导入代理。
安全方面，Codex 引擎支持无限制本地执行和审核批准模式。OpenClaw 保留了外部审批路由、渠道交付、插件钩子和可见故障报告，同时利用 Codex 的原生安全机制。
长远来看，OpenClaw 旨在成为多模型平台，支持 Anthropic、Google、本地模型、OpenRouter、DeepSeek、Kimi、MiniMax 等。此次与 Codex 的整合是双向的：在 Codex 最擅长的领域使用它，同时将优秀的设计思想（如更清晰的工具边界、延迟目录、结构化静默结果、更好的提示范围）带回 OpenClaw 自身的 PI 引擎，最终提升所有模型的处理能力。