首先感谢前端时间分享api使用的几位佬
这两天用几位佬的api的时候出现个使用codex中出现的比较常见的问题：
上下文丢失。
codex在进行比较大型的项目，或者是工作量比较大的任务时，当进行上下文太多，则会进行上下文压缩。压缩后的上下文可能会丢失一部分你所给的提示词，或者你的提示词中的要求他就观察不到从而直接结束任务。
这两天实践出来的几个方法，第一，goal模式，goal模式可以让codex一直朝着这个方向前进，这个goal被遗忘的概率会比较低。所以我们其实可以在goal里面告诉他我们的工作流程，这样用goal设计一条工作流。
第二，goal，有字符限制，并且在goal中你说太多实操细节，可能会导致你真正要实现的goal被忽略。那么我们可以把提示词放在markdown文档中，设计一条工作流，由goal来规定整体的工作流，把提示词放在markdown文档中，作为某一步的具体提示词。也就是goal告诉codex markdown文档的地址，你先去读这个markdown文档，把这个markdown文档作为提示词输入。那么就可以保证codex按照你的流程去做，并且每一步的提示词都不会损失，因为是储存在markdown文档中的，需要时再读。
第三，虽然上述可以让codex较好的完成工作流了，但是你上下文会包括不同阶段的输入输出，其实不利于codex完成任务，每个任务的上下文会被污染。那么我的解决办法是，主对话只进行组织调度，也就是只是按照goal的流程走，而不参与各个阶段的任务工作，具体每一步的工作让主对话使用spawn agent生成子agent，并把对应阶段的markdown文档中的提示词输入给子agent，那么这样就可以实现模型完成具体任务时，上下文只有这个任务的提示词，并且主对话也只有每个流程是否完成，当然如果需要知道对应阶段的结果，主对话也可以去查看子agent的结果，这是可以做到的。
最后，因为我们隔绝了上下文的影响，子agent不可避免的对我们现在的项目的了解就比较少，那它想要更好的完成任务，我觉得可以再加一步。思路是，在每个阶段的提示词中加一个约束，做之前，有不了解的地方，应该进行提问（这里的提示词根据个人需要去写就可以）。然后在主agent增加一个约束，即回答子agent。这样就可以保证子agent是在主agent的指导下，完成的这个任务，他就会更加贴近于我们的项目需要。
上述就是我这两天实操下来的一些经验，如果各位佬又更好的想法，可以回复指导
1 个帖子 - 1 位参与者