• 请不要在回答技术问题时复制粘贴 AI 生成的内容
HakuZero
V2EX  ›  程序员

5X 的 Codex 一天半烧完了,晒晒我的智障多 agent 工作流

  •  
  •   HakuZero · 16h 2m ago · 2832 views

    充了 100 刀 codex 想做点正经东西,结果一天半就没了,项目还卡在半路,越想越亏,来吐槽一下。

    我干了个挺蠢的事:一个项目塞了好几个 agent ,产品、测试、运营、后端、桌面端。本来想的是流程正规一点,学大厂那套需求评审测试验收,能少返工。

    10 个智能体列表

    结果实际流程变成了这样——需求来了先丢给运营 agent 去"调研",调研完产品 agent 出方案,方案出来测试 agent 要先写测试用例,都齐了后端和桌面端才开始写代码。写完你以为完事了?天真,还要挨个过审:测试审一遍,产品审一遍,UI 审一遍,UX 单独再审一遍。我当时不知道哪根筋搭错,UI 和 UX 还拆成了俩 agent 。

    agent 工作流

    它们审起来一个比一个能说。产品动不动就"不符合用户心智",UX 说交互路径太长要重做,测试说边界情况没覆盖要补用例,UI 说视觉规范不统一。最离谱的是,它们提的问题最后基本都得我自己动手改,返工不但没少,我还多了个活儿:给几个 agent 的意见当裁判。

    钱主要烧在上下文上。每个 agent 都得喂历史记录,喂一次几百条 message ,光"对齐需求"就对齐了好几轮,我自己都不知道在干嘛了。

    codex 额度消耗

    现在纠结要不要再充 100 刀。充吧,怕两天又烧没了;不充吧,东西不上不下的很难受。

    就想问问,到底是我这流程本身有病——AI 干活根本不需要模拟人类团队那套官僚流程,还是我用法不对,应该让它们并行干而不是串行开会,还是单纯额度买少了,其实再充 100 刀就能成了?

    45 replies    2026-09-03 07:13:02 +08:00
    zed1018
        1
    zed1018  
       16h 1m ago
    再充 100 刀不如直接升级到 20X
    HakuZero
        2
    HakuZero  
    OP
       16h 0m ago
    @zed1018 感觉我这套工作流 20X 都顶不住,太麻烦,太慢了
    sampeng
        3
    sampeng  
       15h 53m ago   ❤️ 1
    我也在解决这个问题,有几个点可以优化。你可以看看 cf 和 google 怎么解决的:
    https://blog.cloudflare.com/ai-code-review/
    https://cloud.google.com/blog/topics/threat-intelligence/staying-ahead-of-adversarial-ai-through-agentic-source-code-review

    你这一套我用了半年,干个活要 1 小时才能干好一个需求,太慢了,于是我在优化这个过程。这个痛点是显而易见的,因为每个模型都喜欢扣细节,然后就对不上。越多就越扯皮。我认可 cf 和 google 的处理方式,我也在测试,不要每个角色都给最牛逼的模型,按情况用低一档的就行,比如你说的那个 ui ,说实话,这是很机械的活,用用 opus/sol 是大炮打蚊子,不要给每个角色喂重复上下文,我的处理方式是我用 pi 来做,所以每个 agent 是一个独立的 session ,这一件事不完 session 是不结束的。这样就后面的重复其实缓存命中率非常高。

    效果怎么样不好说,我要解决的是干活太慢,不是干活质量的问题。目标是 review 一次 5 分钟内解决战斗。
    zzl93
        4
    zzl93  
       15h 53m ago
    原来如此,那感觉是不是 AI 开发不能这么拆,是不是应该有一个大脑,其它智能体都是下级,子智能体是否调用看大脑,大脑需要有一定的 token 焦虑
    homcrazy1
        5
    homcrazy1  
       15h 53m ago
    直接实现功能,顶多写写单元测试
    Fooooo0
        6
    Fooooo0  
       15h 52m ago
    op 用的这个是什么工具啊?
    HakuZero
        7
    HakuZero  
    OP
       15h 45m ago
    @sampeng 学到了,我也研究下,主要是不想返工,返工的时候 AI 又会整一堆的兼容写法,太麻烦了,就想着让它一次性处理好。
    sampeng
        8
    sampeng  
       15h 43m ago
    @HakuZero 倒不是返工,实话实说,我跑你这一套最的的困扰不是写出来的东西不能用,是能用,但实际代码里到处所谓兜底,你要全用 codex 的 sol ,就是他会考虑完全不存在的情况,各种莫名其妙的兜底,提示词都拉不回来那种。悄悄咪咪的加。一些简单的还好,每轮+1 个点,一跑就是 6-10 轮起步。就是 10 几坨屎进去了。我也很苦恼
    HakuZero
        9
    HakuZero  
    OP
       15h 42m ago
    @Fooooo0 agency-agents 有很多 agent ,挑几个安装就行,然后再调整下每个 agent 用什么模型,像 UX 、UI 这类的就用 gpt-5.6-terra 之类的模型。
    HakuZero
        10
    HakuZero  
    OP
       15h 41m ago
    @zzl93 是的,token 消耗太快了,消耗在反复的 出方案、评审、打回、继续出方案评审,也有可能是我模型指定的都太高了的原因
    HakuZero
        11
    HakuZero  
    OP
       15h 39m ago
    @sampeng 是的,现在很多时候我都需要盯着思考过程,让它不要想那么多
    HakuZero
        12
    HakuZero  
    OP
       15h 37m ago
    @homcrazy1 单一功能是这么干的,新的项目,涉及的端比较多,避免返工所以尝试一下这种模式是否可行
    winnerczwx
        13
    winnerczwx  
       15h 27m ago
    这个流程真可以吗, 看似每个环节都有, 但实则每个环节都缺少灵魂

    产品不懂需求, 测试没有边界, 后端不懂架构
    molicloud
        14
    molicloud  
       15h 23m ago
    可以试试多智能体协作,而不是人参与每个环节,特别是你使用了这么多 agent:
    https://docs.codeg.app/zh/guide/multi-agent
    ktyang
        15
    ktyang  
       15h 10m ago
    这么多 agent 还开极高还开快速模式,也不知道到底是缺 token 还是不缺 token
    gitxuzan
        16
    gitxuzan  
       15h 3m ago   ❤️ 1
    不要装太多工具 mcp ,skill 和插件,针对项目针对性的,我平时全部关掉,按需开启
    nanwangnongfu
        17
    nanwangnongfu  
       15h 1m ago
    我也有这种疑问,从零开始构建系统,想各种节点都有产出,需求分析的,原型,测试用列,proto 文件,代码,尝试了很多,最终都不太满意。AI 的产出总感觉缺少什么,review AI 的产出一言难尽
    Dylan89
        18
    Dylan89  
       14h 58m ago
    我现在都是手动创建 Agent ,遇到的问题是 figma 的圆形,AI 根本实现的稀碎,有没有好的 Skill 。。。
    hackyuan
        19
    hackyuan  
       14h 55m ago
    258K 上下文的这么玩根本玩不了,AI 评审就是智障互相骗,最关键的产品品味、技术架构需要人工判断。GPT-5.6 Sol Max 也不行。
    xycoder01
        20
    xycoder01  
       13h 50m ago
    多 agent 没有问题,问题是不要所有 agent 都使用最高级别,比如 xhigh 。其他的子 agent 要适当调整。否则,20x 的也不一定顶得住。
    CodeCodeStudy
        21
    CodeCodeStudy  
       13h 47m ago
    嚯嚯,自费打工
    tylerrrrrr
        22
    tylerrrrrr  
       12h 46m ago
    流程本身有点过重:产品/测试/UI/UX 串行评审会把同一份上下文喂很多遍,额度主要死在对齐和复述,不在写代码。更省的做法是 1 个 agent 出短方案、1 个按 worktree 实现、必要时再开独立会话做审查,别让它们互相开会。并行只适合目录隔离的活,同一套需求别叠五层官僚。我这边 Claude Code / Codex 仍当 CLI 用,只是不想五个终端对不上谁在改哪,才用本机工作台收会话和 diff: https://github.com/yy36295238/caravel-releases
    NotNEO
        23
    NotNEO  
       12h 31m ago
    我想学习下你这个多 agent 在 codex 的工作流 感觉再多调调 就能用起来
    xylitolLin
        24
    xylitolLin  
       12h 6m ago
    看起来花里胡哨的多 Agent 编排,实际都没有什么效果。唯一的效果是烧掉更多 token 。
    lifei6671
        25
    lifei6671  
       12h 3m ago
    你这个流程完全就是大厂的研发流程。
    XTTX
        26
    XTTX  
       11h 46m ago
    agent 调研需求能调研出个什么。所有的 AI 都有谄媚缺陷,它只想说它认为你喜欢听的。这个市场调研,到具体需求到 ux ui 人搞完了才能开始写代码吧。 想一键 app 5x 当然不够烧了。
    latifrons
        27
    latifrons  
       11h 5m ago
    满满的马拉火车味儿。先做出来个垃圾,然后让 AI 进行快速迭代,哪里不行改哪里。
    MAVETRICK
        28
    MAVETRICK  
       11h 5m ago via iPhone
    @ktyang 哈哈哈哈 我也想吐槽这点
    HakuZero
        29
    HakuZero  
    OP
       10h 58m ago
    @xycoder01 是的我也发现了,这两天也尝试着调整每个 agent
    HakuZero
        30
    HakuZero  
    OP
       10h 55m ago
    @tylerrrrrr 是的太重了,项目中一个小功能的实现就得跑好几个小时
    HakuZero
        31
    HakuZero  
    OP
       10h 54m ago
    @ktyang 主要是想看下快速,到底快在哪里了,哈哈
    HakuZero
        32
    HakuZero  
    OP
       10h 50m ago
    @XTTX 我这里的 调研主要就是让它去搜索下同类产品的做法还有功能实现,也写了一些抓取社交平台的评论分析,找出用户痛点,再结合自己的产品做出适当的修改。
    aaoo3333
        33
    aaoo3333  
       9h 49m ago
    op 用的是什么呢
    ntdll
        34
    ntdll  
       9h 44m ago
    >> 需求来了先丢给运营 agent 去"调研",调研完产品 agent 出方案,方案出来测试 agent 要先写测试用例

    通常来说,调研/方案,这些都是需要人来决定。agent 并不知道你的真实需求,场景。

    而且多 agent 讨论,听起来很美好,至少现阶段,大概率变成萝卜开会,token 空转,不产生任何收益。
    nsjs
        35
    nsjs  
       8h 31m ago via iPhone
    🤣🤣🤣萝卜开会。
    之前写了个 skill ,让 ai 围绕一个话题,盖楼,像贴吧那样,结果得到一堆废话。人至少水贴的时候就是为水而水,ai 是一本正经地水
    shakaraka
        36
    shakaraka  
       8h 13m ago
    我觉得你压根没用过 Dynamic Workflows ,去了解下吧。

    原生的话只有 grok build ,claude code 有。但是这两 cli 接入 gpt 使用 dynamic workflows 会很难受,cc 会经常超时,并且 gpt 没有训练过使用 cc 的 dynamic workflows 就会很难受。grok build 的话因为有 bug ,在使用 gpt 模型会导致上下文死循环堆积。

    建议你买个临时 cc 号,20x 那种,来体验体验,当然,仅限体验,因为这种号用不了一会就会被封。

    pi agent 在开源社区有 dynamic workflows 插件。但是呢 pi 这个东西太简陋了,体验断崖式下降。
    Yien
        37
    Yien  
       8h 5m ago
    AI 想太多了,同一份 PRD,免费的 hy3 写出来的可用且可继续维护,gpt5.5 高写出来的臃肿且无法维护,一环扣一环的.
    heirtheloong
        38
    heirtheloong  
       7h 40m ago
    模型存在过度工程化的问题,多加 agent 不一定能提高工作效率,如果你引入第三方模型审计,很可能会发现它们在为你根本没提出过的需求造轮子,还是那种大概率会在迭代中因为你一个需求就彻底丢掉的轮子。

    甚至还会给你:“为了适老化/为了无障碍,我不会动 xx”。接着“适老化和无障碍”就变成它不可改动的铁则。之前因为测试加了个按钮,你不讲它就把这个按钮保存到地老天荒,你一说删了那个该死的按钮,它就“我将删除这个按钮,并将此要求写入开发文档”。然后过一阵子,又变成“我将再次检查某某按钮是否如预期中并不存在”、“某某按钮绝对不能加入”。

    加什么 skill 都不好使。

    我这种 vibe coding 的,只能是先 grill me ,列出详尽的需求文档。然后 sol high 写多个阶段的实现计划,接着就某一个阶段扩展成可供更低智能的 agent 实现的计划。

    然后拿着计划让 sol medium 或更低的照计划办理,并让它用 pc 控制和 Chrome 控制插件自己先查一遍。

    接着人肉审核一遍,把不顺心地改一遍,再新写下一阶段计划,继续实现。

    绝不把犯轴的可能带进下一个对话。

    现在的上下文压缩是厉害,但是一个对话中久了,它还是越来越轴,越来越钻牛角尖。

    当然,这么干可能前面做好的功能,下一个对话的 agent 又会“抱歉,为了修你的某个 bug ,我引出了更多的 bug”,又或者为了实现某个功能,把前面写的全部重写等等难绷事情。

    但是我实在是没辙了,这玩意始终是个放大器,不是心想事成的神器,不会用就是会很难绷。
    chemzqm
        39
    chemzqm  
       7h 21m ago
    * 你不该用极高推理强度,这个强度只适合解决复杂问题使用
    * 需要优化提示词避免 agent 死循环长时间不干活
    * 简单的项目或者需求根本不需要多 agent ,agent 沟通都是成本
    * 快速开发还是 1M 上下文的大模型最强,GPT 上下文低个别模型还非常擅长过度设计
    * 大模型不是真实用户,它经常做不到理解真实的需求,最好自己明确了再开发
    wfls2008
        40
    wfls2008  
       7h 4m ago
    最近的额度水分挺高的。。
    xujinkai
        41
    xujinkai  
       6h 58m ago via Android
    我是觉得 AI 不能当裁判,AI 又不是人根本搞不明白人的需求(甚至人类的程序员也经常搞不明白产品经理的需求),所以多个 AI 自己循环,肯定会偏差越来越多
    particlec
        42
    particlec  
       6h 35m ago
    一定要最小化流程开始! 所有阶段性的结果必须人工检查一下!
    个人经验,然后就是我是官方中转聚合一起用,deepseek 现在太贵了不合适
    HermanH
        43
    HermanH  
       5h 25m ago
    我当时也遇到这个问题,grill 了之后确定根目标。

    ```markdown
    ## 根目标

    > 在一次持续的 Codex 任务中,当一个已有计划能够产生明确交付物和验收证据时,使主 Agent 根据实际净收益选择单 Agent 或多 Agent 执行,并在不改变根目标、验收标准和用户边界的前提下,随着执行中新信息的出现动态调整尚未完成的执行计划,最终以适当的质量、成本和速度完成可验证交付。

    对应的需求树是:

    ```
    执行 Codex 计划的主 Agent 需要改变

    当前同时承担全局控制和大量具体执行,
    容易产生上下文污染、资源错配和过早固定计划

    必须形成最小有效执行组织,
    并能根据执行证据调整剩余工作,
    同时保留目标、边界和最终验收控制
    ```

    ```

    最终找到个比较合适的 skill 。https://github.com/lixuvip/codex-agent-orchestration-skill
    已经非常能满足需求了。我觉得你出的问题就是非要搞一个死板的 team 出来,但如果从快速人机交互的逻辑来讲,你这套是摩擦成本最高的,不要把整个流程定死。
    HermanH
        44
    HermanH  
       5h 19m ago   ❤️ 1
    你要有一个绝对的话事人,话事人就是当前你对话的那个 session 。它不做任何执行,唯一的任务就是拆任务,验收,控制路线。不要让你的 agent 都有独立话事权,一定乱套,干啥都要返工。
    qf19910623
        45
    qf19910623  
       5 mins ago via Android
    我算是明白你们为什么烧 token 这么离谱了,我都是自己去 opendesign 用 AI 设计几个原型页面,然后导出来,在项目里写提示词让 AI 帮我还原,然后一个模块一个模块的让模型给我实现,我自己去测试验证。合着你们这是完全当甩手掌柜跑一边喝茶去了啊,也太信任 AI 了
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Privacy   ·   Solana   ·   1155 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 75ms · UTC 23:18 · PVG 07:18 · LAX 16:18 · JFK 19:18
    ♥ Do have faith in what you're doing.