在同一个工具集中跨 Claude Code、Codex 和 Ollama 路由编码智能体会话——按会话挑选模型

Reddit r/AI_Agents 工具

摘要

一位开发者描述了如何构建一个多引擎智能体编码工具集,在 Claude Code、Codex 和 Ollama 之间路由会话,并根据任务价值为每个会话从十二个模型中进行选择。

过去几个月我一直在为团队构建智能体编码环境。我最坚持的设计决策是拒绝绑定单一提供商,主要因为我投入使用的每个模型大约六周后就会被淘汰。所有内容都通过一个会话抽象层运行。其下有三个执行引擎:Claude Code CLI——Opus/Sonnet,负责真正的重构重型工作;Codex CLI——GPT-5.6 变体;Ollama——通过云端使用 minimax-m3 和 glm-5.2,同一路径也可完全本地运行。共十二个模型,每次会话从下拉菜单中挑选。会话及其历史记录和工作目录并不关心背后是哪个引擎。为什么值得这么做:按任务价值路由。修改变量名并不需要前沿模型,无论前沿模型多乐意做这件事。配置调整用廉价模型,多文件重构用前沿模型,任何不能离开本机的内容用本地模型。新模型发布时,只需添加一条配置,而不是搭上一个周末。真正烦人的地方是这三个 CLI 在各方面都不一致。会话恢复、流式格式、审批提示、token 报告——全都不同,而且都相当自信地不同。大约 80% 的工作是把这些统一成一个接口。另外 20% 是我最初开始做这件事时觉得有趣的部分。到目前为止已经跑过 1,851 个会话,团队 15 人。还有其他人运行多引擎吗?我还在像原始人一样手动挑选模型——很好奇有没有人已经实现了路由自动化。
查看原文

相似文章

面向长时应用开发的Harness设计

Anthropic Engineering

Anthropic工程师详细介绍了一种多智能体Harness设计,利用生成器与评估器智能体提升Claude在长时间内自主构建完整、高质量前端应用的能力。

最喜欢的代理式编码工具

Reddit r/LocalLLaMA

作者比较了几种代理式编码工具(Codex CLI、Claude Code、Gemini CLI、OpenCode、Pi),认为Pi最精简且最适合本地模型,赞赏其简洁性以及与Qwen 27B-MXFP8的兼容性。

同一模型,不同运行框架:编码智能体的差异化表现

arXiv cs.AI

本研究探讨了在模型固定不变的情况下,改变编码智能体中的运行框架配置如何影响其在代码基准测试上的表现。研究结果表明,一种能自动缩短早期工具输出以管理上下文的“优化框架”,可提升任务完成率,尤其在上下文长度受限的场景下效果显著。