🚀Codex也能玩Graph Engineering了！ 🚀Graph Engineering范式：Codex Multi-agent V2支持Kimi、MiniMax、GPT多模型混用+动态派生subagent，并行执行、Pi Agent工具调用，效率倍增 🚀🚀🚀视频简介： Codex也能玩Graph Engineering了！Multi-agent V2完整配置教程，第三方模型、工具与Skill全部接入 ✅OpenAI最新Codex正式推出稳定的Multi-agent V2多智能体系统！ 🔥本期深度演示如何让主agent充当调度者，理解拆解任务后将代码探索、方案设计、功能开发、测试验证、代码审查等分别交给不同subagent并行执行，最终统一收集判断并合并结果 支持为每个subagent配置独立模型与推理层级（Kimi K3、MiniMax、GPT-5.6等）、控制并发数量、任务恢复后保持角色分工，并提供清晰的agent导航管理 通过cc switch轻松调用第三方模型，还可动态派生subagent或内嵌工具与技能 ⚡️实测多模型对抗代码审计发现严重Bug，完全具备Graph Engineering初级特征，可在很大程度上替代Claude Code的Dynamic Workflows 升级只需一行命令，桌面版同步支持。 带你从配置到实战，全面掌握这套真正的agent调度系统！ #aigc #ai编程 #Codex #ai #graphengineering

OpenAI最近为Codex最新版，也就是0.145.0版，推出了全新的Multi Agent V2，也就是更加稳定的多智能体系统。这次升级之后，它们终于可以在Codex中更加灵活地使用和管理Sub Agent。目前，Multi Agent V2已经进入相对稳定阶段，它不仅支持为不同的子Agent配置不同的模型和推理层级，还可以控制并发数量。当任务恢复之后，也能快速继续保持原来的角色分工。它还提供了更加清晰的Agent导航和管理能力。这意味着，Codex正从过去的单个超级Agent逐渐升级，成为一个真正的Agent调度系统。它并不是简单地启动几个Sub Agent，让它们各自完成各自的任务，而是让一个主Agent充当整个任务的调度者。主Agent可以先理解和拆解任务，再把代码探索、方案设计、功能开发、测试、验证、代码审查等不同工作分别交给不同的Sub Agent。这些Sub Agent完成各自的任务之后，主Agent还会统一收集、判断，并且合并它们的执行结果，最终形成完整的解决方案。 更值得关注的是，Codex现在这种工作方式在设计思路上已经越来越接近Cloud Code的Dynamic Workflow功能。而且最近Graph Engineering这个概念在AI编程领域非常火。像过去我们更多是在研究如何写好一条Prompt，或者是让一个Agent在Agent Loop中不断执行检查和修复。而Graph Engineering关注的是更高一层的问题，也就是如何把多个Agent、多个工具、多个验证点以及不同的反馈循环组织成一张可以实际执行的任务图。Cloud Code的Dynamic Workflows本身就是Graph Engineering的一种典型实现，它可以根据用户的目标来生成一套工作流，再通过多个Sub Agent和条件分支、并行任务、验证点完成更加复杂的任务。而这一次，Codex通过Multi Agent V2，让用户能够更加自由地构建和配置不同的Sub Agent。虽然目前它还不能完全等同于Cloud Code的Dynamic Workflows，也还不是一套完整的Graph Workflow运行时，但从主Agent调度、决策分工、并行执行和结果汇总这些能力来看，Codex的Multi Agent V2已经具备了非常鲜明的Graph Engineering特征。 好，本期视频就为大家深度演示Codex中新增的Multi Agent V2这个功能，它在多种场景中的使用方式，以及如何配置才能让Codex的Multi Agent V2更加接近Graph Engineering。想使用这个新特性非常简单，我们直接将Codex升级到最新版，只需要在终端命令行中执行codex update这一条命令，就可以将我们的Codex CLI升级到最新版。在Codex桌面版的最新版中，我们同样可以使用Multi Agent V2这个新特性。 为了让大家能够更直观地感受到，在Codex中Sub Agent的灵活性有多强，在这里我先让Codex列出我已经配置好的Sub Agent，然后我们再调用Sub Agent来启动一个任务进行测试。好，Codex这里列出了我配置好的这四个Sub Agent。第一个Sub Agent，它的任务是Code Review，我为它设置的模型是Kimi K3。第二个Sub Agent，它的使用场景是UI产品设计与评审，我为它设置的模型也是Kimi K3。第三个Sub Agent，它的任务也是代码审查，我为它设置的模型是Minimax模型。第四个Sub Agent，它的任务也是代码审查，我为它设置的模型是GPT-5.6。 这样一来，我们在Codex中就可以调用已经配置好的这些Sub Agent，也可以直接让Codex根据任务的复杂度来自动派生不同的Sub Agent。在Codex中，这里的主Agent我使用的模型就是GPT-5.6 Soul模型。然后我们就可以来测试一下，让主Agent调用我们已经配置好的Sub Agent来执行任务。这里我输入的提示词是，让它用这三个Sub Agent对代码进行对抗审查，然后我们就直接发送。 当我们发送这个任务之后，这个任务会被当前的主Agent接收，也就是我们设置的GPT-5.6 Soul模型。然后这个主Agent就会调用我们刚才配置好的这三个Sub Agent，对我们的项目代码进行对抗性审查。好，这里Codex提示三个审查轨道都已经启动。在这里我们就可以看到正在运行的这三个Sub Agent，然后我们可以点击第一个进行查看。好，第一个Sub Agent，它这里正在运行，已经运行了一分钟，然后我们再点击查看第二个Agent，这个Agent调用的是Minimax模型。我们点击，好，这里我们就可以看到它正在执行，然后我们再点击查看第三个Sub Agent。第三个Sub Agent，我是让它单独调用的Pi Agent来执行了代码审查任务。也就是说，在Codex的这些Sub Agent中，我们不仅可以为这些Sub Agent配置非OpenAI官方的模型，比如说第三方的这些Kimi模型或者是Minimax等模型，我们还能让Sub Agent来调用不同的这些工具。比如说这里调用Pi Agent，我们就可以将不同任务分配给不同的模型，这样就可以更加节省Codex中GPT-5.6的Token消耗。 好，再等了几分钟之后，这里就提示审查完成，而且还发现了这些严重的Bug。而且我们还可以点击查看这些不同Sub Agent的输出结果。这里是这个使用了Minimax模型的Sub Agent，这是它的输出结果，这里发现了比较严重的代码中的问题，它输出的这些内容都非常详细。然后这三个Sub Agent的执行结果，最后都会被主Agent进行整理和分析，并给出最终的结论。像这样的话，我们就完成了在Codex中调用不同的Sub Agent来完成代码的对抗性审查。 然后我们可以看一下这些Sub Agent它们的配置方式，我们可以直接在Codex中点击查看。这里是这个Sub Agent的完整路径，它会放在Codex的agents这个文件夹中，然后这是这个文件名，这里就是这个Sub Agent的名称，然后这里就是描述，也就是使用Kimi K3模型进行代码审查，然后这里就是具体的提示词，在下面的模型这里，我们给它设置的就是Kimi K3。因为我是使用的CC Switch，所以在模型提供者这里就是设置的CC Switch。在模型的推理级别这里，我设置的是high。像这样的话，我们就可以在Codex中用我们配置的Sub Agent来调用第三方的模型。 然后我们可以打开CC Switch，在这里我们可以看到Codex，我们直接点击这个Codex，然后在这里我们就看到我添加了Kimi K3，然后我们点击编辑，可以看一下我是如何配置的。然后这里就是模型提供者的这个名称，这里是Kimi的URL，然后这里就是API Key，在这里就是Kimi它的API的链接，然后这里这个默认模型就是Kimi K3模型。在Prompt Cache这里我设置成了enable，在模型映射这里就对应Kimi K3。像这样的话，我们就可以通过CC Switch这个项目，将Kimi的API转换为支持Codex的API的格式，我们就可以在Codex的Sub Agent中来调用这个模型，也可以将主Agent的模型改成第三方模型。但我这里还是默认使用的GPT-5.6 Soul模型，因为为主模型设置一个更加强大的模型，它在调度和分配这些