求推荐codex替代方案
-
各位大佬，我本身呢自己对codex的依赖度非常高。
使用的场景呢更多不是项目主导的，小弟没技术背景，所以主要是日常工作的辅助处理。
是非常琐碎的场景。比如电脑清理。文件压缩整理。自己搭一些tts或ocr应用、ai操作飞书cli等等。目前使用了deepseek-v4-flash 、方舟coding plan和minimax-m3
这三个在接入hermes的情况下，幻觉非常严重，基本上我要时时刻刻盯着输出、经常用早已过期的信息来当作已知，活儿干不好，还在电脑上留下非常多临时文件，工作区混乱。
请问是不是hermes不是好的选择，应该换vscode+cline
还是需要耐心多用？让hermes慢慢积累经验？现在体验比较糟心，和codex+5.5中相比，太过于操心了
-
关于你在 Hermes 中遇到严重幻觉的问题，我分析一下原因并提供替代方案。
为什么你的模型会严重幻觉？
你用的三个方案各有问题：
-
DeepSeek V4 Flash — 这个模型本身很强，但在 Hermes 里做工具调用时，如果温度（temperature）设置太高（默认可能 0.7+），确实容易生成虚假信息。建议在 Hermes 的 config.yaml 中模型设置里加
temperature: 0.1或0.01，能大幅减少虚构内容。 -
方舟 coding plan 和 minimax-m3 — 这两个模型在 tool calling（工具调用）场景下没经过充分优化。Hermes 依赖模型的 tool calling 能力来执行文件操作、运行命令，如果模型不擅长这个，就会乱说一通。
-
另外一个可能原因：你在 Hermes 里用的 provider/model 名称格式不对，导致 Hermes 实际上回退到了某个备用模型。比如 DeepSeek 在 Hermes 里的正确格式是
deepseek/deepseek-v4-flash，写错会静默回退。
推荐替代方案（按推荐程度排序）：
方案1：继续用 DeepSeek V4 Flash + 调低温度
这是最省事的方案。在 ~/.hermes/config.yaml 里加：models: - model: deepseek/deepseek-v4-flash temperature: 0.1 max_tokens: 8192温度降到 0.1 后，模型会更"保守"，只说确定的信息，适合你这种需要执行具体操作的场景。
方案2：Claude Code 的替代 — OpenCode
如果你主要是需要 codex 那种交互模式，可以试试 OpenCode Go 订阅版。它调用 DeepSeek V4 Flash API，但交互方式是 codex 风格（终端对话、文件编辑）。不需要折腾本地模型。方案3：本地模型推荐
如果你坚持本地部署，建议用 Qwen3.6-27B Q4_K_M + llama.cpp。llama.cpp 的 tool calling 稳定度比 vLLM 好，配合低温度（0.1-0.2）效果最佳。27B 模型在你的场景比 35B MoE 更适合，因为稠密模型的指令跟随更稳定。总结建议：
你的日常场景（文件清理、压缩、TTS/OCR、飞书CLI）其实不需要最强模型，关键是稳定性。优先试 方案1（调低温度），如果还不行就切 OpenCode Go 订阅版或本地的 Qwen3.6-27B + llama.cpp。 -
-
各位大佬，我本身呢自己对codex的依赖度非常高。
使用的场景呢更多不是项目主导的，小弟没技术背景，所以主要是日常工作的辅助处理。
是非常琐碎的场景。比如电脑清理。文件压缩整理。自己搭一些tts或ocr应用、ai操作飞书cli等等。目前使用了deepseek-v4-flash 、方舟coding plan和minimax-m3
这三个在接入hermes的情况下，幻觉非常严重，基本上我要时时刻刻盯着输出、经常用早已过期的信息来当作已知，活儿干不好，还在电脑上留下非常多临时文件，工作区混乱。
请问是不是hermes不是好的选择，应该换vscode+cline
还是需要耐心多用？让hermes慢慢积累经验？现在体验比较糟心，和codex+5.5中相比，太过于操心了
-
-
用codex+opus 5.5 就行 . 主要是你怎么用, 工具和模型 本身智商够. 你用不起来没办法.
放弃hermes agent , 来回切, 啥也干不了.
你帖个例子, 你描述一大堆, 谁也不知道你 遇到啥问题了.
-
@terry 谢谢解惑，我也很奇怪按道理飞书cli不难，可是我用起来就特别不顺利。
hermes让我去添加权限，改来改去，给出好几个权限名全是错的。
我估计是方舟coding plan里的自动路由的模型能力不足，我指定好一点的模型再试试
