3个hook，让fable5调度gpt5.6完成复杂长任务 #howto入门codex[话题]# #howto实现一万种vibecoding[话题]# #vibecoding[话题]# #claudecode[话题]# #大模型[话题]# #codex[话题]# #gpt5[话题]# #hook[话题]# #AI工具[话题]# #fable[话题]#

最近我在Cloud Code里面经常使用的一种工作方式，就是用Fable模型去做任务规划和编排的角色，然后去启动Workflow，在Workflow里面去调用一些相对比较便宜的模型，比如说Opus、Sonet以及Codex的模型，去完成一些子任务。 我用这种工作方式完成了很多以前可能需要我人工做大量干预的工作，现在交给这个Workflow，然后用Fable模型去做编排，基本上可以做到90%的完成度，之后我再基于Workflow完成之后的工作结果，做一些小的优化，就已经完全足够达到我要的交付标准了。 但是这个Workflow我实际用下来，现在其实存在几个问题，所以今天就给大家分享一下，我针对这个Workflow，以及Workflow里面调用Agent的这个工作流里，我设置的一些Hook。尤其是当你用Fable模型去做编排的话，这几个Hook我觉得对于这个工作流程还是会有很大帮助的。 首先第一个问题就是，在默认情况下，Cloud Code里面去调用Workflow，它可能会启动几十上百个Agent，但是在默认情况下，它所有的子Agent的模型都会继承。 最开始我们在这里指定的模型，这就会导致一个问题，就是飞波模型既做了编排，又做了执行。这就会导致，即使我们开的是Cloud Max的会员，如果你一次性去启动几十上百个子Hook，它都是用飞波模型的话，完成的任务的质量肯定会很高，但是它的成本也是非常巨大的。 所以我写的这个第一个钩子，就是当我的提示词里面出现workflow或者auto code的时候，它就会在我的提示词后面自动注入一段固定的提示词，就是告诉它不要全部用飞波模型，要去给每一个子任务指定合适的模型。并且这里我也提到了，就是可以把部分的任务交给Codex这个模型去做，尤其是在AI生图部分的代码任务的编写，以及交叉review的时候，用Codex模型其实能够更好的提升我们这个任务的交付质量。 第一个钩子会配合第二个钩子去使用，因为第一个钩子本质上是一种软性的提示词，第二个钩子就有点类似于一个硬性的守门员。当这个agent要去触发一个workflow的时候，它会去检查是否每个agent都指定了模型，如果没有的话，它就会触发一个提示，让这个主编排的agent一定要去指定好模型，要不然就有可能出现我的软性提示虽然说了要让它去分配合适的模型。 但它最终可能没有完成分配任务的情况。 第二个问题，就是当我们在Workflow里面希望编排Agent去调用Codex的模型来完成任务的时候，Codex会倾向于把这个任务放到后台去执行，然后直接返回给主Agent，说这个任务已经完成了。 那么这个问题在Workflow里面就会非常严重，因为Workflow的工作流是提前编排好的。当一个子Agent反馈给主Agent说我的任务已经完成的时候，这个编排任务就会直接往下一步推进，Workflow的工作质量就会受到很大的影响。 所以第三个钩子就是用来防止这个问题：当主线程使用子Agent去调用Codex的这个子Agent的时候，它会注入一些固定的输入，让这个Codex的子Agent必须保持前台同步运行，并且禁止它以“任务已启动”作为返回值返回给主Agent，从而避免出现任务实际上没完成，但子Agent回报的信息说它已完成的情况。配合这三个钩子一起生效的话，就能够实现用非大模型去做编排，然后利用一些比较便宜的模型去做实现，并且Codex也可以在这个编排里面作为其中的某一些Agent去完成它的任务，而不会破坏Workflow的整体调度。 那我们可以看一下实际的一个情况，我给了它一个相对来说比较严、比较长的任务，这个任务它已经干了十个小时左右了，然后做了三轮的workflow，这是它的第三轮。 然后我们就可以看到这里，虽然说它这里写的是Sonnet，但实际上它调的是Codex的模型。 然后比如说它这里跑了二十一分钟，才返回这个结果。如果说我们没有前面的这个workflow的话，那这里可能在第二分钟、第三分钟的时候，这个Codex就会返回“这个任务已经完成”，但实际上它是把任务放到后台去完成了。那我们加了这个hook之后，这个任务它就会一直在前台跑着，所以它就能够保持这个workflow调度的正确性。 所以如果大家也在用这个workflow去做这种长程、长时间的开发任务的话，我觉得这些hook都还是很有帮助的。当然后面这个workflow cloud code本身可能也会去做一些优化，如果它做了一些优化，我们可以把这些没必要的hook再删掉就可以了。 在当前这个版本下面，我觉得这些hook还是非常有必要的。尤其是我们希望这个飞博模型来做编排，然后把一些任务派发给Codex去完成的这种业务场景下面。