最近用 Codex 做项目时，我越来越感觉它更适合当“主控”和“代码审查员”，而不是所有任务都亲自下场做。
我遇到的几个问题比较明显：
Codex 做工程分析、拆任务、审代码挺强
但让它直接做前端页面，审美和 UI 完成度经常不太理想
有些模型写代码速度更快，适合先出初稿
有些模型更适合写文档、解释、补测试、做重构
但最后我还是更信任 Codex 来审核、整合和把关
所以我最近在折腾一个思路：
让 Codex 作为主工具，通过 MCP 调用本机其他 AI CLI，把任务分给不同模型执行，然后 Codex 再负责检查、整合和决策。
不是“多开几个聊天窗口”那种协作，而是更像一个本地 agent 工作流：
Codex 负责拆任务和制定标准
快速模型负责先写代码或生成候选方案
更擅长前端的模型负责 UI/页面初稿
其他工具负责测试、文档、搜索或重构
Codex 最后负责 review、挑问题、决定是否合并
我想解决的核心问题有三个：
-
前端质量问题
Codex 写业务逻辑不错，但做前端经常不够好看。希望能把 UI 初稿交给更适合视觉和页面实现的模型，然后让 Codex 审核代码质量。 -
节约时间
有些代码初稿不一定需要 Codex 慢慢写，可以让更快的模型先跑，Codex 只做检查、修正和最终把关。 -
发挥不同模型的长处
每个模型能力侧重点不同。与其强迫一个模型做所有事情，不如让 Codex 当主控，把合适的任务交给合适的工具。
为此我在做一个 MCP server，方向是把本机已经安装好的 AI CLI 包一层，让 Codex 可以启动其他 CLI 作为后台任务，去干擅长的工作
这个工具本身不直接调用模型 API，也不是新的聊天客户端。它更像是一个“本地 AI CLI 调度层”。
想请教大家几个问题：
- 你们会不会也把 Codex 当主控，而不是让它什么都亲自写？
- “其他模型写初稿，Codex 审核和整合”这个工作流是否自然？
- 前端 UI 这类 Codex 相对弱的任务，交给其他模型先做会不会更合理？
- 多模型协作时，最重要的是并行提速，还是能力互补？
我现在还在验证这个方向是不是一个真实需求。
如果大家觉得这种多模型协作太复杂，或者 Codex 单独用就够了，也欢迎直接拍。
by the way
项目已经在开发中了，我目前自己使用下来感觉还可以，调用antigravity cli来开发前端的内容，感觉还不错，gemini 3.5 flash结合codex下达的指令干活又快又好
后续准备开源出来，在这之前想听听大家的意见，这是mcp的真实工作截图
9 个帖子 - 5 位参与者