分享一种多agent coding策略（包爽）

因为codex居高不下的成本和限额，从两个礼拜前开始尝试各种多agent coding。最开始是直接用api转接，告诉codex自己ds的api，让他们俩根据api通信，在效率巨差、巨不稳定的同时还是一个黑箱，很快就放弃了。后面尝试用cc-switch配合api将国产大模型植入codex做subagent，克服了很多困难（工具调用、模型路由等等）好在最后效果相当出色，codex定位为ceo：分包和验收任务还有写工单，ds干苦力：flash检索文件和代码落点，pro啃哧啃哧写代码。mimo pro审代码。qwen负责简单的多模态和ocr。大家在一个聊天框里干活共享skill和agent.md，最顺的一次连续执行15个小时任务，codex28k的上下文窗口都没跑满，很爽。但这个方案也有局限，那就是所有模型都得配合codex那孱弱的28k上下文窗口，哪怕是上下文能力1m的ds。不过瑕不掩瑜，本以为这个方案会一直运行下去，直到昨天gpt大更新，一刀切，让所有subagent都没法自定义model provider了，于是被迫找新方案，先尝试用各种cli让codex和模型用命令符沟通，但还是一样，不能可视化，也看不到实时情况。也尝试了几个github项目，比如ccb，这个项目一次能同时打开四个tui界面，模型间相互沟通协作。还有很火的aion ui，可以给多个agent组一个工作群，让他们相互协作。试下来，只能说这些项目理念都很好。但是稳定性都相当差劲，用户没法做甩手掌柜，动不动就崩溃或者消息队列叠叠乐，很不方便。最后化繁为简，直接tmux并联两个tui接口（deepcode+opencode皮下grok4.5）+codex主界面，发现用下来比原来的subagent还要爽，首先模型的能力得到最大化了（今天我一个goal跑了5h任务，愣是没把deepcode 1m上下文窗口跑满），配合最近grok逆天的价格和性能还有oc对code这件事的优化，狠狠蹬了一天。协作方式是（deepcode检索找落点审代码、grok狠狠蹬代码、codex视觉审核写工单分派任务）这个loop可以说转的跟飞轮一样。强烈向所有vibecoder推荐！#转码 #个人开发者