开发者分享大模型软件开发经验：复杂多智能体设计无益

开发者@realWeZZard分享了自己在纯软件开发领域使用大模型的个人经验教训。他认为不需要追求复杂花哨的多智能体设计，让模型能够和验证设施互动，才是旗舰大模型真正提升任务成功率的关键。

Fable 5的计算机使用（computer-use）能力进步，正好补齐了这块能力短板，而GPT系列模型的这项能力一直表现不错。基于这些体验，他给出了具体的配置建议：Claude Code用Fable 5 Max做调度，Sonnet负责执行；Codex直接用GPT 5.6 Sol Ultra加目标从头做到底。

他建议别浪费订阅套餐里宝贵的令牌（token）陪OpenAI测试子智能体（subagents）功能，OpenAI的子智能体功能支持比竞品晚了一年，而月之暗面早就认识到子智能体的重要性。最多只引入一个其他厂商的模型做结果审核就足够。

反对复杂设计有三点具体原因。第一，GPT模型检测到自己编辑过的文件被其他人员或智能体修改后，有一定概率会重置git变更，因此任何跨智能体委托任务的设计都必须做好git worktrees隔离。

第二，任务编排器（Orchestrator）必须使用最优质的模型，因为它能看到全部任务细节或摘要，可以做出质量更高的判断。第三，把「顾问」拆分成独立智能体必然需要搭建任务路由，路由质量会成为整个系统的短板，而且优质模型会自行判断，不需要交给其他智能体，拆分「顾问」的设计往往需要用较差模型做编排器，和第二点要求冲突。

在Opus 4.8时代，他自己的Claude Code harness就曾把部分执行和审核任务委托给Codex并行处理，最终发现只把Codex用作审核的效果最好。这是因为Codex只读取内容，还能引入不同的模型偏见。

Fable 5推出后，他就停用了之前的这套工具。他认为借助浏览器使用（browser-use）和计算机使用能力搭建完整的端到端验证闭环才是正确方向。

如果处理高价值任务，可以多开通几个Claude Max或ChatGPT Pro账号。如果搭建重复性任务管线，可以购买DeepSeek的API，搭配评估调试打磨提示词，视觉输入接入Kimi即可。