Fable 不能用了，但还没到放弃的时候 ── 靠 OpenRouter Fusion＋国产 LLM＋审查层硬撑

1. Fable 没了。这可麻烦了

老实说吧。这远远比不上 Fable。

在写这篇文章的时候，Anthropic 提供的 AI 编程代理「Fable」已经停止服务。那样的精度、那样的速度、那样的整合感。目前还没有能超越它的替代品。

话虽如此，也不能就这样干等着。找替代品的话，选项大致是这些：

• Claude Code / Claude Sonnet：聪明。但单独使用时精度不及 Fable，费用也不便宜
• GPT-5 / GPT-5.5：出乎意料地不太行。处理长代码库时很快就喘不过气。而且贵
• Cursor / Windsurf：体验不错，但取决于背后用的是哪个模型。没法自由配置
• 本地 LLM（Ollama 等）：速度是有的，但一旦交给真实的代码仓库，精度就会明显下滑

于是，反复尝试之后找到的答案，就是用 OpenRouter 的 Fusion 功能＋国产 LLM 来生成代码，最后再过一层 gpt-5.5-pro 审查 或 Codex 的 PR 审查。这套组合完全比不上 Fable，但比纯 gpt-5.5 好用得多。算是还能用。

不过，毕竟是国产 LLM，把工作用的代码喂给它还是有点让人心里打鼓。前提终究是仅在个人兴趣项目或个人开发范围内使用。

2. 什么是 OpenRouter Fusion

OpenRouter 是一个能用统一接口调用多个 LLM 提供商的 API 网关。Claude、GPT、Gemini、DeepSeek 全都能用同一套接口调用。

这个 OpenRouter 有一个叫做「Fusion」的功能。

简单来说，这是一套把同一个提示发给多个模型，分析它们的回答之后，由一个模型整理出最终输出的机制。可以说是「模型们的合议制」。

具体流程如下：

1. 用户输入提示
2. 在 analysis_models 中指定的多个模型会同时针对同一个提示生成回答
3. 由 model 指定的模型比较、分析这些回答，把共识点、矛盾点、遗漏、盲点等整理成结构化内容（即担任 judge 的角色）
4. 接着，同一个模型会基于这份分析写出最终回答

重点在于，无法给各个分析模型设置不同的角色或提示。所有模型收到的都是同一个提示，各自独立回答，再由 judge 评估其中的差异——就是这么简单的机制。

名为 opencode 的 CLI 编程代理，原生支持把 Fusion 当作插件使用。只需在 opencode.json 中写好配置，就能得到一个由多个模型协作生成、审查代码的代理。

3. 实际的配置

以下是我目前在用的 opencode.json 核心部分。

{
  "model": "openrouter/openrouter/fusion",
  "provider": {
    "openrouter": {
      "models": {
        "openrouter/fusion": {
          "name": "OpenRouter Fusion (Custom DeepSeek V4 Pro)",
          "options": {
            "plugins": [
              {
                "id": "fusion",
                "analysis_models": [
                  "xiaomi/mimo-v2.5-pro",
                  "z-ai/glm-5.1",
                  "deepseek/deepseek-v4-pro",
                  "moonshotai/kimi-k2.7-code",
                  "minimax/minimax-m3"
                ],
                "model": "deepseek/deepseek-v4-pro",
                "max_tool_calls": 8
              }
            ]
          }
        }
      }
    }
  }
}

由5 个分析模型和1 个执行模型组成。

分析模型（全部看着同一个提示、同时回答）

执行模型（基于分析结果写出最终回答）

• deepseek/deepseek-v4-pro：基于分析模型们的回答，负责实际的代码生成与文件编辑。

为什么是国产 LLM

单纯是因为性价比极高。

截至 2026 年，国产 LLM 的 API 价格是 Anthropic 或 OpenAI 的五分之一到二十分之一，性能却不相上下甚至更好。尤其是 DeepSeek V4 Pro 的编程能力，在实务层面不少场合让人感觉可以与 Claude Sonnet 或 GPT-5.5 平分秋色甚至更强。

4. 是如何运作的 ── 光靠 Fusion 还不够

Fusion 单独运行时的流程是这样的。

1. 用户输入提示
2. 5 个分析模型各自独立生成回答
3. 执行模型（DeepSeek V4 Pro）比较、分析这些回答，生成一份提取出共识点、矛盾点、遗漏的结构化分析
4. 基于这份分析，同一个执行模型（DeepSeek V4 Pro）生成最终代码

这很接近人类团队开发的模式。5 名工程师看着同一份规格各自给出评审意见，再由 1 个人（DeepSeek V4 Pro）分析整理之后动手实现——大概是这样的画面。

关于上下文窗口的限制： Fusion 的上下文窗口是 128K tokens。乍看之下不多，但因为对话历史还要加上 5 个模型各自的回答全部塞进去，其实很快就会被填满。不过不必太紧张。就算超过 128K 导致 Fusion 的合成步骤失败，各个分析模型也早已各自（以 DeepSeek V4 Pro 的 100 万 tokens、Kimi K2.7 的约 26 万 tokens 等，各自足够大的上下文窗口）完成了提示的处理。opencode 本身也保留着整个会话的对话历史，所以模型的「记忆」并不会因此丢失。实际体感是不会造成太大的实务障碍。

但光靠这样，完全比不上 Fable。毕竟 Fable 是单一模型，却能轻松超越多模型合议制的精度。这是 Anthropic 的底气所在。

因此，要在 Fusion 的输出上再加一层审查层。可选方案有两个。

方案 A：由 gpt-5.5-pro 进行代码审查

1. 用 Fusion 架构生成代码
2. 把生成的代码交给 gpt-5.5-pro，要求它「审查并给出修改建议」
3. 让原来的执行模型应用这份修改建议

gpt-5.5-pro 单独生成代码时表现不太行，但审查现有代码却出乎意料地擅长。

方案 B：GitHub Codex 的 PR 审查

1. 用 Fusion 架构生成代码
2. 提交 PR，交给 GitHub Codex 的 PR 审查
3. Codex 会指出潜在的 bug 或设计上的隐患，把这些反映进去

Codex 的审查会结合 GitHub 的上下文（Issue、以往的 PR、项目结构），因此会从和通用 LLM 审查不同的角度切入。

只需选一个就够了。Fusion（5 模型合议）→ 审查（gpt-5.5-pro 或 Codex）的两段式架构。正因为单靠一次 Fable 远远不够，才用流程来弥补，这是这套方法的核心思路。

纯 gpt-5.5 经常出现的库版本用错、调用不存在的 API 等问题，用这套架构已经明显减少。

5. 速度与实用性

速度本身和单一模型相比没有太大差异。因为 5 个模型是并行运行，实际响应时间仍在可接受范围。

问题在于精度。换作 Fable 一次就能通过的地方，这套架构会出现几次返工。结果就是整体开发时间比 Fable 明显慢。错得越多就越慢。

不过，比纯 gpt-5.5 好用得多。用 Fusion＋审查生成的代码，一开始就相当接近正确答案，肯定比 gpt-5.5 单独陷入生成→修改→修改→修改的无限循环要快得多。

体感上大概是「速度不差。精度远不及 Fable，但比纯 gpt-5.5 好用好几个档次」的这种平衡。

6. 附加内容：审查层与其他 opencode 配置

审查层：gpt-5.5-pro 或 Codex PR 审查

光靠 Fusion 架构还是有点不放心，所以会选其中一个作为审查层来用。

gpt-5.5-pro：通过 opencode 的 task 功能指定为子代理，指示它「审查生成的代码并提出修改建议」。从零开始写代码时表现一般，但挑别人写的代码的毛病却异常擅长。

GitHub Codex：在提交 PR 时，让 Codex 的 PR 审查 跑一遍。它能结合整个项目的上下文进行审查，这一点和通用 LLM 审查的味道不太一样。

用哪一个，全看当时的心情。两个都用确实太过头，也太慢了。

其他配置

opencode.json 里除了 Fusion 之外，还加了几个实用的配置。

{
  "permission": {
    "read": "allow",
    "glob": "allow",
    "grep": "allow",
    "task": "allow",
    "webfetch": "allow",
    "websearch": "allow",
    "lsp": "allow",
    "edit": "allow",
    "bash": {
      "*": "allow",
      "Remove-Item *": "deny",
      "del *": "deny",
      "rm *": "deny",
      "rmdir *": "deny",
      "rd *": "deny",
      "erase *": "deny",
      "git clean *": "deny"
    }
  },
  "experimental": {
    "primary_tools": ["task"]
  }
}

重点有两个。

1. 屏蔽删除类命令

明确拒绝了 Remove-Item、del、rm、rmdir、rd、erase、git clean。因为把删除文件交给 AI 代理去做实在让人不放心。真的需要删除时，就自己动手。

2. primary_tools: ["task"]

让子代理（task）的并行探索优先执行。在大型代码库中同时读取或搜索多个文件时，通过 task 的方式明显快得多。

7. 总结

Fable 的停服很痛。真的很痛。目前还没有能超越它的东西。

但也不能就这样干等着，所以目前是靠 OpenRouter Fusion＋国产 LLM 生成代码，再用 gpt-5.5-pro 或 Codex PR 审查收尾的架构在硬撑。

这套架构的要点：

• 用 OpenRouter Fusion 靠 5 个模型的「合议制」生成代码
• 分析模型：Xiaomi Mimo / GLM / DeepSeek / Kimi / MiniMax
• 执行模型：DeepSeek V4 Pro
• 收尾用的审查层：gpt-5.5-pro 或 Codex PR 审查（两者选一）
• 速度和单一模型相当。但因为精度不及 Fable，返工会拖慢速度
• 比纯 gpt-5.5 好用得多。虽然远不及 Fable，但足以应付实用需求
• 因为是国产 LLM，不太适合用在工作代码上。仅限兴趣、个人开发

如果你是「失去 Fable 很难受」「觉得纯 gpt-5.5 太不给力」的 AI 编程代理用户，这套方案作为过渡期的替代品，值得一试。

只要有 OpenRouter 账号，今天就能开始用。

参考链接

• OpenRouter: Fusion plugin
• OpenRouter: Fusion Router
• OpenRouter: OpenCode integration
• opencode: Config
• GitHub Codex: PR review
• Anthropic: Claude Fable 5 and Claude Mythos 5

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

常见问题

汇总了咨询这一主题时常见的问题。

OpenRouter 的 Fusion 是什么样的功能？

这是把同一个提示同时发给多个模型，让其中一个模型（担任 judge 角色）比较、分析各自的回答，梳理出共识点、矛盾点与遗漏，再由同一个模型基于这份分析写出最终回答的机制。可以说是模型们的合议制。无法给每个分析模型设置不同的角色或提示，所有模型收到的都是同一个提示。CLI 编程代理 opencode 原生支持 Fusion 插件，只需在 opencode.json 中写好配置即可使用。

为什么要用国产 LLM？

单纯是因为性价比极高。截至 2026 年，国产 LLM 的 API 价格是 Anthropic 或 OpenAI 的五分之一到二十分之一，性能却不相上下甚至更好。尤其是 DeepSeek V4 Pro 的编程能力，在实务层面不少场合让人感觉可以与 Claude Sonnet 或 GPT-5.5 平分秋色甚至更强。不过把工作用的代码交给国产 LLM 存在风险，因此前提是仅在个人兴趣项目或个人开发范围内使用。

为什么光靠 Fusion 还不够？

因为即便是 5 个模型的合议制，精度依然达不到 Fable 的水平。所以要在 Fusion 的输出上再加一层审查。可选方案有两个：一是让 gpt-5.5-pro 审查生成的代码并应用修改建议，二是提交 PR 让 GitHub Codex 的 PR 审查把关，两者选其一即可。gpt-5.5-pro 单独生成代码时表现较弱，但很擅长审查现有代码；Codex 则能结合整个项目的上下文给出意见。

这套方案的实用程度如何？

由于 5 个模型是并行运行，速度和单一模型相比差不了多少。但精度远不及 Fable，因为会产生返工，整体开发时间明显变慢。即便如此，仍确实比纯 gpt-5.5 单独陷入生成与修改的无限循环要快，库版本用错或调用不存在的 API 的情况也明显减少。只要有 OpenRouter 账号，马上就能试用。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。