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

再充 100 刀不如直接升级到 20X

@zed1018 感觉我这套工作流 20X 都顶不住，太麻烦，太慢了

我也在解决这个问题，有几个点可以优化。你可以看看 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 分钟内解决战斗。

原来如此，那感觉是不是 AI 开发不能这么拆，是不是应该有一个大脑，其它智能体都是下级，子智能体是否调用看大脑，大脑需要有一定的 token 焦虑

直接实现功能，顶多写写单元测试

op 用的这个是什么工具啊？

@sampeng 学到了，我也研究下，主要是不想返工，返工的时候 AI 又会整一堆的兼容写法，太麻烦了，就想着让它一次性处理好。

@HakuZero 倒不是返工，实话实说，我跑你这一套最的的困扰不是写出来的东西不能用，是能用，但实际代码里到处所谓兜底，你要全用 codex 的 sol ，就是他会考虑完全不存在的情况，各种莫名其妙的兜底，提示词都拉不回来那种。悄悄咪咪的加。一些简单的还好，每轮+1 个点，一跑就是 6-10 轮起步。就是 10 几坨屎进去了。我也很苦恼

@Fooooo0 agency-agents 有很多 agent ，挑几个安装就行，然后再调整下每个 agent 用什么模型，像 UX 、UI 这类的就用 gpt-5.6-terra 之类的模型。

@zzl93 是的，token 消耗太快了，消耗在反复的 出方案、评审、打回、继续出方案评审，也有可能是我模型指定的都太高了的原因

@sampeng 是的，现在很多时候我都需要盯着思考过程，让它不要想那么多

@homcrazy1 单一功能是这么干的，新的项目，涉及的端比较多，避免返工所以尝试一下这种模式是否可行

这个流程真可以吗, 看似每个环节都有, 但实则每个环节都缺少灵魂

产品不懂需求, 测试没有边界, 后端不懂架构

可以试试多智能体协作，而不是人参与每个环节，特别是你使用了这么多 agent：
https://docs.codeg.app/zh/guide/multi-agent

这么多 agent 还开极高还开快速模式，也不知道到底是缺 token 还是不缺 token

不要装太多工具 mcp ，skill 和插件，针对项目针对性的，我平时全部关掉，按需开启

我也有这种疑问，从零开始构建系统，想各种节点都有产出，需求分析的，原型，测试用列，proto 文件，代码，尝试了很多，最终都不太满意。AI 的产出总感觉缺少什么，review AI 的产出一言难尽

我现在都是手动创建 Agent ，遇到的问题是 figma 的圆形，AI 根本实现的稀碎，有没有好的 Skill 。。。

258K 上下文的这么玩根本玩不了，AI 评审就是智障互相骗，最关键的产品品味、技术架构需要人工判断。GPT-5.6 Sol Max 也不行。

多 agent 没有问题，问题是不要所有 agent 都使用最高级别，比如 xhigh 。其他的子 agent 要适当调整。否则，20x 的也不一定顶得住。

嚯嚯，自费打工

流程本身有点过重：产品/测试/UI/UX 串行评审会把同一份上下文喂很多遍，额度主要死在对齐和复述，不在写代码。更省的做法是 1 个 agent 出短方案、1 个按 worktree 实现、必要时再开独立会话做审查，别让它们互相开会。并行只适合目录隔离的活，同一套需求别叠五层官僚。我这边 Claude Code / Codex 仍当 CLI 用，只是不想五个终端对不上谁在改哪，才用本机工作台收会话和 diff： https://github.com/yy36295238/caravel-releases

我想学习下你这个多 agent 在 codex 的工作流 感觉再多调调 就能用起来

看起来花里胡哨的多 Agent 编排，实际都没有什么效果。唯一的效果是烧掉更多 token 。

你这个流程完全就是大厂的研发流程。

agent 调研需求能调研出个什么。所有的 AI 都有谄媚缺陷，它只想说它认为你喜欢听的。这个市场调研，到具体需求到 ux ui 人搞完了才能开始写代码吧。 想一键 app 5x 当然不够烧了。

满满的马拉火车味儿。先做出来个垃圾，然后让 AI 进行快速迭代，哪里不行改哪里。

@ktyang 哈哈哈哈 我也想吐槽这点

@xycoder01 是的我也发现了，这两天也尝试着调整每个 agent

@tylerrrrrr 是的太重了，项目中一个小功能的实现就得跑好几个小时

@ktyang 主要是想看下快速，到底快在哪里了，哈哈

@XTTX 我这里的 调研主要就是让它去搜索下同类产品的做法还有功能实现，也写了一些抓取社交平台的评论分析，找出用户痛点，再结合自己的产品做出适当的修改。

op 用的是什么呢

>> 需求来了先丢给运营 agent 去"调研"，调研完产品 agent 出方案，方案出来测试 agent 要先写测试用例

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

而且多 agent 讨论，听起来很美好，至少现阶段，大概率变成萝卜开会，token 空转，不产生任何收益。

🤣🤣🤣萝卜开会。
之前写了个 skill ，让 ai 围绕一个话题，盖楼，像贴吧那样，结果得到一堆废话。人至少水贴的时候就是为水而水，ai 是一本正经地水

我觉得你压根没用过 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 这个东西太简陋了，体验断崖式下降。

AI 想太多了,同一份 PRD,免费的 hy3 写出来的可用且可继续维护,gpt5.5 高写出来的臃肿且无法维护,一环扣一环的.

模型存在过度工程化的问题，多加 agent 不一定能提高工作效率，如果你引入第三方模型审计，很可能会发现它们在为你根本没提出过的需求造轮子，还是那种大概率会在迭代中因为你一个需求就彻底丢掉的轮子。

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

加什么 skill 都不好使。

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

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

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

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

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

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

但是我实在是没辙了，这玩意始终是个放大器，不是心想事成的神器，不会用就是会很难绷。

* 你不该用极高推理强度，这个强度只适合解决复杂问题使用
* 需要优化提示词避免 agent 死循环长时间不干活
* 简单的项目或者需求根本不需要多 agent ，agent 沟通都是成本
* 快速开发还是 1M 上下文的大模型最强，GPT 上下文低个别模型还非常擅长过度设计
* 大模型不是真实用户，它经常做不到理解真实的需求，最好自己明确了再开发

最近的额度水分挺高的。。

我是觉得 AI 不能当裁判，AI 又不是人根本搞不明白人的需求（甚至人类的程序员也经常搞不明白产品经理的需求），所以多个 AI 自己循环，肯定会偏差越来越多

一定要最小化流程开始！ 所有阶段性的结果必须人工检查一下！
个人经验，然后就是我是官方中转聚合一起用，deepseek 现在太贵了不合适

我当时也遇到这个问题，grill 了之后确定根目标。

```markdown
## 根目标

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

对应的需求树是：

```
执行 Codex 计划的主 Agent 需要改变
↓
当前同时承担全局控制和大量具体执行，
容易产生上下文污染、资源错配和过早固定计划
↓
必须形成最小有效执行组织，
并能根据执行证据调整剩余工作，
同时保留目标、边界和最终验收控制
```

```

最终找到个比较合适的 skill 。https://github.com/lixuvip/codex-agent-orchestration-skill
已经非常能满足需求了。我觉得你出的问题就是非要搞一个死板的 team 出来，但如果从快速人机交互的逻辑来讲，你这套是摩擦成本最高的，不要把整个流程定死。

你要有一个绝对的话事人，话事人就是当前你对话的那个 session 。它不做任何执行，唯一的任务就是拆任务，验收，控制路线。不要让你的 agent 都有独立话事权，一定乱套，干啥都要返工。

我算是明白你们为什么烧 token 这么离谱了，我都是自己去 opendesign 用 AI 设计几个原型页面，然后导出来，在项目里写提示词让 AI 帮我还原，然后一个模块一个模块的让模型给我实现，我自己去测试验证。合着你们这是完全当甩手掌柜跑一边喝茶去了啊，也太信任 AI 了

你分一下工好嘞，写代码和方案用 GPT ，其他的测试等交给别的模型来做，基本上就够用了

1.流程有问题，传统组织流程那一套不适用；
2.项目想清楚了，建议上 20x 更合适，退一万步想，你打游戏不也充钱么，娱乐消费不也是消费么，难得你有这爱好折腾，干就完事儿
注意休息，劳逸结合

因为 sol 高推理强度的过度设计和开发特别严重，你需要用相关 skill 去限制他们，不然代码仓库会无限膨胀

@chemzqm 是的，最近也在想办法优化这块

@HermanH 有道理，我试着优化下看看