个人目前体验下来的GPTplus用户节省Token的子Agent最佳用法

celeus 2026-08-02 13:26 1

网上有人分享使用Sol作为主线程Agent,lunamax作为子线程subAgent的操作。实际使用下来会发现子线程subAgent和主线程Agent的沟通成本会极大的提高整体的用量。


对于Pro用户来说Sol直接处理全部的事情反而比上面说的这种方法会更好。(除非太慢了,额外开一个别的模型的执行子线程即可)


但如果你在主线程里使用lunamax,复杂任务交给Sol子线程(让Luna自己判断)则会节省很多的简单任务的执行消耗。复杂任务可以主动提及或者由模型自行判断。在此基础上,还可以增加Grok和Deepseekv4Flash作为快速且相对廉价的执行子线程Agent。


直接和你的ChatGPT说:


我想要主Agent使用luna(max)的模型。
然后创建一个Sol(xhigh)的专家subAgent用于处理复杂场景的任务。
对应的修改全局`AGENTS.md`和`~/.codex/agents/`还有`~/.codex/config.toml`文件。


如果你有DS或者Grok的api(需要支持responses格式,需要按DS和Grok修改下面的内容,不支持的订阅建议通过CCSwitch等转换):


在`~/.codex/agents/`创建一个DS/Grok的subAgent(无识图能力),他们能够快速的执行相关的任务,很好的根据具体要求修改代码,(grok额外加一句:有较好的web_search能力)。

补充修改全局AGENTS.md里的描述。

模型的调用端点是:`https://xxx.xxx.xxx/v1`(按实际修改),模型为:`grok-4.5`(按实际修改)API_KEY为:`XXXXX` (可以考虑先配置到环境变量或者是让大模型先写一个demo你自己去改文件)

当你感觉lunamax不适合作为主Agent的时候,可以直接在客户端上切换,比如Sol的其它档位。


另外如果是没有订阅而使用deepseek或者grok接入的用户,也可以参考这个逻辑搞个多模态模型的子Agent,主Agent在AGENTS.md里约束其把图片识别相关的交给subAgent。

最新回复 (8)
  • OpenAI 08-02 13:31
    1

    这思路有点类似于Claude Code Advisor,不过Codex里面线程是什么意思?就是一个子Agent的会话吗?

  • celeus 楼主 08-02 13:32
    2

    对的对的,其实严谨点应该说是subAgent/子智能体

  • lmarch2 08-02 13:38
    3

    诶那为什么主sol子luna沟通成本会高^-^

    而反过来不会呢

  • SUN 08-02 13:40
    4

    普通人对聪明人说一个模糊的意图,聪明人一般可以实现

    聪明人对普通人说一个模糊的意图配上一堆操作步骤,普通人得反复试错,求助于聪明人,才能成功

    因此主sol子luna沟通成本会高

  • AlickFine 08-02 13:47
    5

    Sol 作为主线程,lunamax 作为子线程的操作。实际使用下来会发现子线程和主线程的沟通成本会极大的提高整体的用量



    有没有一种可能,增加的agent互相沟通的成本,会大于你节省下来的子agent使用不同价格的模型省下的差价?

  • Gary_AI-user 08-02 13:51
    6

    思路不错,支持全用sol的想法,也就是贵了1倍,也许效果更好。

  • celeus 楼主 08-02 14:07
    7

    但其实大部分任务是用不到sol的专家能力的。复杂任务里sol也是1-2次的调用和沟通用于规划整体路径。

    就如你引用的下面说的那样,如果真的觉得任务需要交给sol来全权执行,那么就全程sol。


    另外我个人的一个观点是,使用不同的模型(指的是ds/grok和gpt订阅混用)能各自的发挥其在代码上的优点。比如grok的能力其实是比lunamax强的,但luna能在grok修改后的地方发现不足(因为其实很多时候模型就是多家各自有各自奇特的擅长的地方),总体下来2个相对廉价的模型配合的效果甚至会比自身的能力更高。

  • Ryan77 08-02 14:11
    8

    我直接网页端sol拆任务,不消耗codex额度,本地codex用luna max执行,执行推送github完建pr,再让网页端的sol审核

* 帖子来源Linux.do
返回