坏了, 我成 eventloop 了

我算是理解为什么网上有多开浏览器窗口和多开终端 Agent 的流程了.

等待 Gemini 3 Pro 返回选型方案, 等待 GPT 5.2 Pro 生成详细设计文档, 等待 Claude Opus 4.6 生成项目框架, 等待 Gemini 3 Pro 生成前端代码, 等待 GPT-5.3-Codex 生成后端代码和 /review, 等待 Gemini 3 Pro 执行 E2E 测试等待 Gemini 3 Flash 更新文档和生成 git commit message

我感觉自己现在和代码里的 eventloop 一样, 处理各个 Agent 的执行完成时的 callback, 期间倒杯水, 站起来走走, 有种在现实世界扮演 async 代码的感觉.

cellsyx

2 月 12 日

主要考虑的点有两个: 成本, 以及特定需求下的输出质量

Gemini 3 Flash 是这上面成本最低的模型, 且指令遵从性比 Gemini 3 Pro 要好的多. 从生成 commit message 中的统计文件改动数量和类型以及输出格式这个任务就可以看出来.

Gemimi 3 Pro 是这上面成本第二低的模型, 拿来生成前端 React 代码还行, 出错不多. 但是 Debug 消耗的对话轮次和要求用户输入额外提示信息要明显多于 5.3-Codex 和 Opus 4.6. 有时候改个 3-4 轮可以解决 bug, 但是代价就是代码越改越乱. 后端代码我目前只大量生成过 Python, 但是经常会有重复代码, 偶尔遗漏修改或者误删代码. 即便有 GEMINI.md 规定代码格式要求, 还是有不遵守指令的情况, 比如 import 会无理由地放在函数内而不是文件顶部, 即时你写明了 Rules 也一样会出现. 明明没有循环引用这个问题, 它还是倾向于把改动放到一块连续的区域, 不考虑整体代码需求.

5.3-Codex 的成本比 Opus 4.6 低, 生成后端 Python 代码的质量显著高于 Gemini 3 Pro , 而且工程的严谨性更强. 最明显的就是 5.3-Codex 写出的测试代码质量更高, 生成项目过程中的返工次数和 Bug 明显更少.

Opus 4.6/4.5 成本最高, 我是拿他来生成框架或者解决前几个模型尝试多次都解决不了的需求. 比如在前端实现一个搜索并预览本地 PDF 文件, 预览界面需要高亮关键词. 这个需求由于要处理 PDF 中特殊的文字切分或者编码以及字体情况, Gemini 3 pro 对话 5-6 轮都实现不了, Opus 3 轮完成任务.
Claude 系模型(4.5) 在 windows 环境下(Antigravity 中) Debug 时 Agent 执行动作的准确率不如 Gemini 3 pro, 经常是在 cmd 或者 powershell 中使用 linux 的命令格式. 4.6 的 Agent 表现我还没怎么测, 正在使用中.