Twinny 与 Continue：发生了什么变化，以及现在该用哪个

Twinny 和 Continue 已不再服务于相同的用途：Continue 的开发已结束，但软件仍能运行；Twinny 则是一款功能范围更窄、仍在持续发布的工具。 continue.dev 自己的页面标题显示“Continue（已被 Cursor 收购）”，其 README 称该仓库已不再积极维护且为只读；与此同时，Twinny 在同一天（2026-09-18）推送了 4.1.1、4.1.2 和 4.1.3 版本。但 Twinny 有意不提供代理模式和 MCP 工具，因此它只能替代 Continue 的部分功能，而不是全部功能。

先澄清一个问题，因为这个名称对应多个对象。有两家无关的公司都以 Twinny 为名开展业务：西班牙的企业自动化平台 twinny.es 和韩国的机器人公司 twinny.ai；截至 2026 年 9 月 19 日核查时，两者都在运营。它们的价格或融资信息都不属于本页面。本文所指的产品是 twinny.dev 上的 VS Code 扩展，发布标识为 rjmacarthy.twinny，来自 twinnydotdev/twinny 仓库，文档位于 twinny-docs。

Continue 究竟发生了什么

简而言之，产品结束了，但代码没有。Continue 的 README 写得很明确：该仓库“已不再积极维护，并且对所有用户均为只读”。主页的元描述只有一句话——Continue 已被 Cursor 收购。不过，只读并不等于已归档，而这正是大多数文章弄错的区别。

所有条目均于 2026 年 9 月 19 日核查。在你制定计划前，其中两点值得强调。首先，README 称最终的 2.0.0 涵盖 VS Code 扩展、CLI 和 JetBrains 插件，但已发布的构件中有两个与之不一致：CLI 从未超过 1.5.47，JetBrains 插件从未超过 1.0.67。本指南报告这一差异，而不解释其原因，因为没有一手来源对此作出说明。其次，文档站点比 hub 存续更久构成了一个仍然存在的陷阱：docs.continue.dev 仍在教授 uses: <owner>/<slug> 语法，用于从一个已无法解析的主机拉取模型或规则。现在，只有完全本地的 config.yaml 文件，并明确填写 provider、apiBase 和 apiKey 条目，才能保证解析成功。

应该选择哪一款

如果你在 Continue 中实际使用的是自动补全、关于代码的聊天、行内编辑、审查和提交消息，并且希望使用仍有人维护的代码库，请选择 Twinny。其仓库采用 MIT 许可证，未归档；截至 2026 年 9 月 19 日，最近的提交是版本更新 4.1.1 至 4.1.3，日期均为 2026-09-18。如果你在自己的硬件上运行模型，更应选择它：Twinny 的整体设计以本地服务器为中心，其填充中间内容自动补全能很好地配合 1.5B 至 7B 的基础模型。

如果你依赖 Twinny 没有的功能，请选择 Continue，或者说继续使用它。代理模式和 MCP 工具服务器是最明显的情况——Continue 的 MCP 文档写明，MCP“只能在代理模式中使用”，因此两者要么一起可用，要么一起不可用。CLI 和 JetBrains 插件是另一种情况：Twinny 要求 Visual Studio Code 1.93 或更高版本，或 VSCodium 等兼容构建版本，并且不提供命令行客户端或 JetBrains 版本。冻结的 Continue 安装仍能继续工作，只是不会再改进。

真正的分界线在于执行模型，这不是一次发布就能弥合的功能差距。Twinny 的 FAQ 对“twinny 会自行运行代理来编辑我的文件吗？”的回答是：“不会。每项更改都是你请求的，并且在保留之前你都能看到：你接受一条建议、接受一个差异，或确认一条命令。这是设计如此。”如果你使用 Continue 是为了交接多步骤任务并审查结果，Twinny 会是你从第一天就能感受到的降级。如果你使用 Continue 的聊天和编辑模式，并且觉得代理模式令人不安，那么 Twinny 提供的是相同的工作流，只是不包含你不想要的那部分。

迁移成本很低，但并非为零。 Continue 将所有模型放在一个带有 roles 列表的 YAML 文件中；Twinny 完全没有配置文件，而是在侧边栏中一次创建一个工作角色的提供商，因此一个包含三个角色的 Continue 条目会变成最多三个 Twinny 提供商。Twinny 没有任何功能会读取 Continue 配置。预计重写需要大约一小时，另加重建工作区索引的时间——不同嵌入模型生成的向量不能混用，因此更换嵌入模型意味着重新建立索引。

至于成本，两个客户端都免费，真正收费的都不是客户端本身。 Continue 完全没有价格：continue.dev 已不再提供价格页面，其 FAQ 关于软件唯一说明是，Apache-2.0 源代码和文档仍保留在 GitHub 上。Twinny 的扩展采用 MIT 许可证且免费，但其团队网关才是出现价格数字的地方，而这两部分很容易混淆。

功能与许可证对照

信息读取自两个 Marketplace 条目、各仓库以及项目文档，核查日期为 2026 年 9 月 19 日。安装数量每天都会变化，反映的是历史记录而非当前使用情况——Continue 作为受维护产品运营了三年，其数量是在这期间累积的。还要注意，Twinny 的 Marketplace 简介（“Locally hosted AI code completion plugin for vscode”）和其 GitHub 描述都早于 twinny.dev 上的产品定位；后者现在以团队网关为主。描述 Twinny 点对点“Symmetry”网络的旧文章介绍的是已移除的功能；其 FAQ 说明 Symmetry 已被移除并由 Devices 替代，而 Devices 仅连接你自己的机器。

每个产品的费用

Twinny 的方案价格读取自其许可证与席位页面，核查日期为 2026 年 9 月 19 日；Continue 的情况则来自 continue.dev 本身。需要诚实说明两点。席位是一个活跃访问密钥，而不是一个人；撤销密钥后，席位会立即释放。此外，这些是公布的价格，而不是本指南实际结账验证的价格——网站将 rjmacarthy.xyz 列为许可证发行方，而其背后的销售实体未经调查。Twinny 自己的主页对比还引用了托管助手“通常每个席位 $19–39”的价格；这是其营销说法，并非本文验证过的数字。

任一客户端通过 OpenAI 兼容网关可访问的功能

两种工具在这里不再具有可互换性，而这是任何功能表都无法展示的。两者都将工作拆分为不同角色，但只有部分角色能够与聊天补全网关通信。

聊天从理论上可行。 Twinny 的 提供商概览说明，对于聊天，API 路径就是基础路径，Twinny 会追加 /chat/completions，因此针对 api.kunavo.com 使用 /v1 这样的 API 路径与 Kunavo 自己的路由相匹配。问题在于选择哪种预设：Twinny 的 托管 API 页面写道，使用托管 API 的聊天请求“会通过供应商的 SDK 发送到其固定端点，因此主机名、端口和路径字段会被隐藏”。OpenAI 和 Anthropic 预设仍会要求密钥——但它们会将密钥发送给相应供应商，而不是你选择的地址，这就是为什么网关密钥不应填入这些预设。地址字段在本地服务器预设中仍可见，而通用的“OpenAI-compatible server”预设正是为 Twinny 没有专用预设的服务器准备的。将 https://api.kunavo.com/v1 粘贴到 Hostname 中，表单会自动将其拆分为协议、主机、端口和路径；密钥会作为 Authorization: Bearer 标头发送。

自动补全无法适用，原因有两个且彼此独立。 Twinny 的通用预设通过 /v1/completions 风格的路由驱动补全，而 Kunavo 没有此类路由——其 API 中不存在旧式文本补全端点，只有 /v1/chat/completions 及其他聊天类接口。另一方面，Twinny 的 支持模型页面明确说明，只有使用填充中间内容 token 训练的模型，才能根据光标前后的内容进行补全；而指令模型“往往会闲聊或解释，而不是完成补全”。Kunavo 的目录包含指令模型和聊天模型，其中没有任何填充中间内容基础模型。任一阻碍单独存在都足以得出结论。Continue 自己的自动补全指南也指向相同结论，只是没有使用 Twinny 的术语：对于该角色，它推荐 Codestral 和 Qwen2.5-Coder 的 1.5B 与 7B 版本，并警告思考型模型不适合此用途。请使用小型本地模型提供自动补全——这也是两个项目共同推荐的配置。

Kunavo 完全不提供嵌入服务。目录中的任何模型都没有嵌入端点，因此 /v1/embeddings 会解析出一个模型并拒绝请求。请将 Twinny 的嵌入提供商或 Continue 的 embed 角色指向本地服务器或外部嵌入提供商。Twinny 的文档推荐使用 nomic-embed-text。

name: My Config
version: 0.0.1
schema: v1
models:
  - name: Claude Sonnet 4.6
    provider: openai          # the protocol, not the vendor
    model: claude-sonnet-4-6
    apiBase: https://api.kunavo.com/v1
    apiKey: <your Kunavo key>
    roles: [chat, edit, apply, summarize]
    capabilities: [tool_use]  # only if agent mode stays unavailable

关于这一部分有两点说明。provider: openai描述的是线路协议，而不是供应商，因此适用于任何实现了 /v1/chat/completions 的端点。capabilities 行是不太明显的部分：Continue 的能力文档说明，它会根据提供商和模型名称检测 tool_use，并且“你无法覆盖自动检测——只能添加能力”。如果网关提供的 id 不在 Continue 的表格中，Continue 就不会赋予它 tool_use；能力页面将代理模式不可用列为由此导致的确切结果；添加该行会启用它，而且没有任何设置会将其关闭。还要注意，Kunavo 自己的Continue 设置页面在 autocomplete 角色中提供了一个使用聊天模型的第二个条目。没有任何记录表明该配置经过运行时测试，而 Continue 自己的自动补全指南为该角色推荐的是代码补全模型而非聊天模型——请按照本节所述保持谨慎，不要将其视为已验证的配方。

聊天类工作的 token 估算示例

由于自动补全无法访问该网关，任一客户端通过 Kunavo 产生的 token 费用仅来自聊天流量：聊天回答、行内编辑、代码审查和提交消息。因此，计算量会小于以补全为主的助手，在选择模型前了解规模很有价值。假设一个工作日包含 12 次聊天或编辑交互，每次平均使用 18,000 个未缓存输入 token 和 1,200 个输出 token——总计 216,000 个输入 token 和 14,400 个输出 token。这些假设仅用于举例；预算前请替换为你自己的数据。费率是实时的 Kunavo 目录价格，单位为每百万 token。

这些是用于说明的 token 计算，不是实测任务成本，也不是账单上限。列出的最低费率与完成任务的最低成本是两种不同的说法：一个需要第二次尝试才能完成审查的模型，成本可能高于一次就完成任务的更贵模型。Kunavo 目录中的金额是计费下限，而不是上限——当上游报告其费用时，账单取目录成本与上游成本乘以适用加价两者中的较高者。缓存费用以及你在本地运行的任何内容均不包含在此示例中。最低充值金额为预付余额中的 $10，这是资金充值最低额，而非任务费用或订阅费；请参阅 计费详情。

设置方法

Kunavo 为 Continue 发布了设置指南，但没有为 Twinny 发布；而已发布的配置参考并不等于兼容性测试——两个客户端都没有针对该端点进行运行时测试。在尝试其中一个时，请保持一条可用的路由处于开放状态，运行一个有明确边界的单次任务，然后查看你的账户为此记录的费用。对于 Continue，请从 Continue 集成指南 开始，并结合上面的注意事项阅读。对于 Twinny，请使用此处介绍的通用 OpenAI 兼容提供商，以及 Twinny 自带的 Test provider 按钮；该按钮会为该提供商的任务发送一个小型请求，并显示成功结果或服务器返回的错误，以及它调用的 URL——这是区分路径错误和密钥错误的最快方法。准备好为密钥充值后，请创建 Kunavo 账户。

想进一步比较其他方案？OpenAI 兼容 API介绍了该协议能够和不能够承载的内容；如果 Continue 的代理模式是你无法舍弃的部分，Cline 与 Claude Code则比较了两个代理。

常见问题

于 2026 年 9 月 19 日通过直接获取进行检查：两个 GitHub 仓库的 API 和提交列表、两个 VS Code Marketplace 列表、@continuedev/cli 和 twinny-server 的 npm 条目、JetBrains 插件列表、continue.dev 及其 README、对 hub.continue.dev 的 DNS 查询、docs.continue.dev 上关于 OpenAI 提供商、功能和 MCP 的页面，以及 Twinny 的介绍、提供商、托管 API、支持的模型、许可和 FAQ 页面。未检查：任一客户端向 Kunavo 发出的运行时请求，以及 Twinny 的结账流程。Kunavo 的令牌费率来自实时目录；本文中的所有美元示例均为说明性令牌算术。