这篇文章回答一个具体问题：Codex 里的 Computer Use / bundled skill / plugin 在做什么，Hermes 有没有同类能力，社区有没有正在把这些东西打通的 PR 或 issue？
结论很直接：Hermes 已经把 Computer Use 做成了一个模型无关的 computer_use toolset，底层通过 MCP stdio 连接 cua-driver；Codex 也已经出现了 computer_use feature requirement、bundled plugin / skill 发现路径和桌面端问题单，但它现在更像是围绕 Codex Desktop 与 bundled plugins 演进的一套能力。CUA 社区正在推进一条更通用的路线：让 cua-driver 作为 MCP 层进入 Codex、Claude SDK 和其他 agent harness。
上一篇 千问 Token Plan 调研 解决的是“千问 Token Plan 怎么接进 Codex、Hermes 和 CRS”。但接完以后还有一个更容易混淆的问题：模型 API 是 OpenAI-compatible，并不代表 agent 改文件也按 OpenAI Codex 的 patch 方式来。
这篇文章专门拆开这个问题：OpenAI、Anthropic、Qwen、Gemini 这些 provider 的 wire API 是一层；Codex、Claude Code、Qwen Code、Gemini CLI、OpenCode、Aider、Roo Code、Cline、Cursor 这些 agent client 暴露给模型的文件工具是另一层；最后 client 在本地到底怎么落盘，又是第三层。
很多“AI 编程套餐”看起来都像一个简单问题：多少钱、给多少量、能不能接到我现有的 coding 工具里？ 但千问 AI 平台的 Token Plan 更像一个新的供应侧形态：它不是传统按量 API 余额，也不是单一 IDE 插件会员，而是面向 Claude Code、Codex、Cursor、Qwen Code、Qoder、OpenCode 等工具的 Credits 订阅。
本文的结论很直接：Token Plan 可以接 Codex，也可以作为 OpenAI-compatible API-key 账号接进 CRS；但要把它纳入 ChatArch 的 CRS 运维生态，需要把“Credits 窗口、账号类型、禁用/启用、Key 绑定、用量回读”当成一套独立 Provider 管理，而不是把它粗暴塞进普通 OpenAI OAuth 账号池。