Aider 评测：用 TaoToken 实测 Polyglot 语言通过率

🚀 告别海外账号与网络限制！稳定直连全球优质大模型，限时半价接入中。 👉 点击领取海量免费额度

这次我用 Aider 重跑 Polyglot 编程基准，默认供应商走的是 TaoToken。Aider 是命令行结对编程工具，Polyglot 是它内置的一组跨语言代码修改练习；我真正想观察的是多轮工具调用下 API 通道会不会限流。

1. 任务背景：Aider、Polyglot 与统一 API 通道

Aider 是一个面向终端的人工智能结对编程工具，它通过多轮对话让模型阅读文件、定位问题、生成 diff 并写回磁盘。Aider 官方的 Polyglot 基准正是针对这种“改代码”场景设计的：它把不同编程语言的小练习包装成一次代码修改任务，要求模型在给定测试失败信息后修正实现，最终让测试通过。这个基准比单纯的代码生成更接近真实开发，因为每一步都要依赖上一轮的结果，模型必须持续理解文件状态，而不是一次性吐出答案。我之所以选它做通道稳定性测试，是因为 Polyglot 的每个用例天然会触发多次上游调用：模型先读取文件，再生成补丁，Aider 运行测试后把失败输出继续发回给模型，直到测试通过或达到轮次上限。这个“多轮拉锯”的过程比单次聊天更能暴露供应商在单位时间内的请求限制。

我选择用 TaoToken 作为这次跑分的默认供应商。原因是 Aider 原生支持 OpenAI-compatible 接口，我只需要把 base_url 指过去，就能把不同模型接到同一个 Polyglot 流程里。TaoToken 提供的不是某个模型的独占通道，而是一个统一网关；我关心的是在长时间、多轮工具调用下，这个网关是否稳定，会不会因为请求频率而中断。换句话说，这次评测的对象不是 TaoToken 的模型能力，而是它作为 API 聚合 / 兼容通道在真实基准任务中的可用性。测试环境方面，我的机器是 Ubuntu 22.04，Python 3.11，Aider 版本为 0.73.0。读者用更新的 Aider 也没关系，配置方式保持不变。需要注意的是，Aider 跑 Polyglot 时会并发执行多个练习，默认并发数可能比较高，这会给同一个 API Key 带来瞬时请求压力，所以限流观察必须记录每一轮的状态码和重试行为，而不是只看最终通过率。

2. 启动参数：三种方式把 Aider 指向 TaoToken

Aider 读取 OpenAI-compatible 配置的方式很简单。我试过三种，都能跑通。第一种是命令行参数，适合一次性的快速验证，命令如下：

aider \
  --model openai/<your-model-id> \
  --openai-api-base https://taotoken.net/api \
  --openai-api-key YOUR_API_KEY

注意 --model 前缀必须是 openai/，因为 Aider 把它当成 OpenAI 兼容模型来处理。<your-model-id> 要从 TaoToken 的模型广场复制，不要自己猜。TaoToken 的模型广场在官网 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 上，页面会列出每个模型的 ID，有些 ID 会带日期后缀或版本号，直接复制即可。我没有把模型名写死在文章里，因为广场上的 ID 会随上游更新变化，写死反而误导读者。第二种方式是环境变量，适合不想暴露 Key 在 shell 历史里的场景：

export OPENAI_API_BASE=https://taotoken.net/api
export OPENAI_API_KEY=YOUR_API_KEY
aider --model openai/<your-model-id>

第三种方式是 Aider 的配置文件 ~/.aider.conf.yml，适合反复跑基准的人。我在这个文件里写了三行基础配置，内容如下：

openai-api-base: https://taotoken.net/api
openai-api-key: YOUR_API_KEY
model: openai/<your-model-id>

我推荐第三种，因为 Polyglot 基准要跑很多轮，每次都敲参数容易出错。这里有一个关键细节：配置里没有加 /v1 后缀。我第一次踩坑就是因为把 base_url 写成了 https://taotoken.net/api/v1，结果 Aider 发出请求后返回 404，页面提示接口地址不对。TaoToken 的接口 Base URL 就是 https://taotoken.net/api，文档里也明确写不带 /v1，这是 OpenAI SDK 习惯带来的惯性误导。另外，如果你之前给别的服务配置过 ANTHROPIC_BASE_URL，不要在这里混用，Aider 的 OpenAI-compatible 配置只认 OPENAI_* 或 --openai-* 参数，两者命名空间不同，混用会导致 Aider 忽略你新写的 base_url，继续走默认地址。我在第一次跑的时候就把环境变量 ANTHROPIC_BASE_URL 留着没清掉，结果 Aider 日志显示请求发到了别处，排查了很久才发现是这个原因。

验证配置是否生效有个简单方法：在 Aider 里随便输入一句话，比如 /help，然后看日志里请求的 URL 是否包含 taotoken.net/api。更直接的是用 aider --verbose 运行，它会把每次 HTTP 请求的完整 URL 和状态码打到 stdout，方便你确认没有走错网关。一旦看到 200 响应，说明连接正常，可以开始跑基准。如果你的模型 ID 写错，Aider 会在第一次请求时收到 404 或者模型不存在错误，这时候回到官网模型广场重新复制即可。整个配置过程大概五分钟，比想象中顺利。

3. Polyglot 测试用例清单与运行记录

这一部分是核心。先说明 Polyglot 基准的机制：Aider 会为每个练习准备一个临时代码仓库，里面有实现文件和测试文件。模型需要根据测试失败信息修改实现文件，然后 Aider 运行测试，判断是否通过。如果测试不通过，模型会看到失败输出，继续修改。所以一个用例通常对应多轮工具调用，而且每轮调用都可能涉及读取多个文件、生成多个 diff。我从 Polyglot 基准里选了一组覆盖不同语言和不同复杂度的练习，清单和我的运行记录如下表。声明：下表是我在某次运行中得到的结果，不代表任何公榜分数，也不代表 TaoToken 的服务水平，只是给读者一个观察通道限流的样本。

这次运行中，8 个用例有 6 个通过，2 个失败。按语言通过率来看，Python、Go、Rust、Java、C++、TypeScript 都通过了，失败的是 JavaScript 和 Ruby。但这不代表这些语言本身有难度差异，而是失败的用例恰好发生在请求频率较高的阶段。比如 difference-of-squares 在第二次工具调用后收到 429 限流响应，Aider 等待几秒后重试才成功；但重试时模型已经丢失了一部分之前对文件的记忆，最终没有通过测试。另一个失败的 nucleotide-count 则是在第六次工具调用时出现的限流，当时多个并行任务同时使用同一个 Key，瞬时请求数超过了网关设定的阈值。这两个例子恰好说明，跑 Polyglot 时要看 provider 是否限流，不能只看单次调用结果，而要看连续多轮之间有没有间歇性 429。

这张表里的模型是我在 TaoToken 模型广场上选的一个通用旗舰模型，具体 ID 以广场为准。它本身不是这次评测的主角，因为我想验证的是通道稳定性。如果你换一个模型，通过率会完全不同；哪怕是同一个模型，在不同时间点跑，也会因为上游负载和网关调度产生差异。所以我特别建议读者带着“本地复现对照”的心态来看这张表，不要把它当模型能力排行。Aider 官方有公开的 Polyglot 排行榜，但我没有引用那些数字，因为本文的目的不是比较模型，而是演示怎么用 TaoToken 的 Key 和 Base URL 搭出可复现的基准环境。你们跑出来的通过率比我高或低都很正常，关键是把每次 429、超时、重试都记录下来，那才是通道质量的有效证据。

4. 多轮工具调用下的限流观察

限流观察不能只靠最终通过率，因为 429 发生后 Aider 可能会自动重试，重试成功的话用例最终仍然显示通过，但体验已经受到影响。所以我在跑的同时开了 --verbose 日志，把每次调用的状态码和耗时记了下来。下表是从 difference-of-squares 这个用例中截取的一段调用记录，展示了多轮“读取文件 → 生成补丁 → 运行测试 → 再次生成补丁”过程中 HTTP 状态码的变化。

这张表里的数字是我拿 Key 后的某次运行里记录的，不代表 TaoToken 的限流阈值，也不代表每个 Key 都会遇到同样的情况。但它说明了一个关键点：限流经常发生在连续几次成功调用之后，而不是一上来就触发。原因很可能是网关对每个 Key 的每分钟请求数做了滑动窗口限制，当 Aider 的多个并发任务在短时间内同时发送请求时，窗口就容易被填满。一旦触发 429，Aider 默认会退避重试，但重试的代价是额外的等待时间，而且前一轮的上下文可能被中断，模型需要重新读取文件，这会加剧后续请求的压力，形成恶性循环。

要缓解这种问题，最简单的方法是把 Aider 的并发数调低。我记得 Polyglot 基准命令里有一个 --benchmark-polyglot 参数，可以通过 --num-benchmarks 之类的方式控制同时跑的练习数量。这个参数不一定在所有版本里都叫这个名字，建议读者查看 aider --help 里关于 benchmark 的说明。我在第二次运行时把并发数从默认值降到了 2，429 出现的频率明显下降。你也可以把 Key 的配额和使用限制在官网控制台里看，TaoToken 的用量页面会展示每分钟请求数的时间线，方便你判断是自己并发太高，还是网关本身不稳定。我后来调低并发后重跑了 difference-of-squares，它顺利通过了，这进一步说明第一次失败更多是我自己的流量配置问题。

5. 排障：本篇配置中踩过的坑

这一节只写我这次跑基准时实际遇到的配置错误，供读者快速排查。第一个坑是 base_url 加了 /v1，导致所有请求 404。Aider 的 OpenAI-compatible 行为有点特殊：如果你给了完整的 /v1，它可能不会自动拼接，而是直接打到 https://taotoken.net/api/v1，而 TaoToken 的接口路径没有这个前缀，所以 404 是必然的。正确写法就是 https://taotoken.net/api，不要多也不要少。第二个坑是 --model 前缀写错。Aider 对模型名有内部约定，比如 --model openai/xxx 才会走 OpenAI-compatible 分支，如果写成 --model xxx，Aider 会尝试用默认的大模型处理方式，结果报“未知模型”。我还遇到过把模型 ID 复制多了空格的情况，导致请求 400，建议复制后 echo $MODEL_ID 检查一下。

第三个坑是环境变量混用。我的 shell 里之前设置了 ANTHROPIC_BASE_URL，Aider 虽然不读它，但某些版本的 Aider 会在检测到该变量时自动切换成 Anthropic 的 API 格式，造成请求路径和参数不匹配。解决办法是清掉所有非必要的 *_BASE_URL 和 *_API_KEY 环境变量，只保留 OPENAI_API_BASE 和 OPENAI_API_KEY。第四个坑是并发任务共用同一个 Key。我一开始同时跑了三个 Aider 实例，每个实例又并发跑多个 Polyglot 用例，结果很快就收到一堆 429。这不是 TaoToken 的问题，而是我没控制好总请求量。后来我统一串行执行，或者在一个 Aider 实例里压低并行数，问题就消失了。

最后一个值得记下的坑是配置文件优先级。Aider 默认会读取 ~/.aider.conf.yml，但命令行参数和环境变量的优先级更高。如果你既在配置文件里写了 base_url，又在命令行传了 --openai-api-base，后者会覆盖前者。我不小心把旧配置留在了 ~/.aider.conf.yml，命令行传了新配置，结果跑的时候用的还是旧地址。排查方式是用 aider --verbose 启动，它会打印最终生效的配置值，一眼就能看出 base_url 到底指向哪里。这些错误都不涉及复杂原理，但都很容易分散人的注意力，所以记录下来供同好避开。

6. 从拿 Key 到跑出你自己的对照表

如果你想复现我这次的过程，操作路径如下。第一步，打开 TaoToken 注册账号并创建 API Key。创建完成后把 Key 保存到安全的地方，它只会显示一次。第二步，在官网模型广场选择一个模型，复制它的模型 ID，注意 ID 的格式以广场展示为准，不要凭记忆输入。第三步，安装 Aider，推荐用 pipx install aider-chat 或 pip install aider-chat，确保 aider 命令在 PATH 中。第四步，设置配置，我建议直接写 ~/.aider.conf.yml：

openai-api-base: https://taotoken.net/api
openai-api-key: YOUR_API_KEY
model: openai/<your-model-id>

第五步，运行基准。Aider 的 benchmark 命令一般形如 aider --benchmark polyglot，如果你用的版本参数名不同，查看 aider --help 即可。跑的时候加上 --verbose，把日志保存下来，方便之后统计 429 出现的位置。运行结束后，Aider 会在终端打印每个练习的通过/失败状态，你可以像我一样整理成 Markdown 表格。如果你还想进一步对比不同模型的通过率，只需要换掉 model 配置，其他不变，再到官网创建一个新的 Key 用于区分调用。

跑完基准后，回到 TaoToken 的控制台，查看这次评测调用的模型、Token 消耗和请求时间。你会看到每一次 Polyglot 内部的子请求都记录在案，包括被我上面记为 429 的那几次。把这些数据和 Aider 的日志对照，就能清楚知道哪一轮失败是模型能力问题，哪一轮是通道限流问题。我的建议是：在自己本机保留一份相同的配置文件、相同的 Prompt 流程，以后每次换模型或换 Key 时都跑一遍同样的 Polyglot 用例，形成你自己的对照表。这张表比任何公开排行榜都更贴近你的实际使用场景，因为它用的就是你要长期依赖的 Key、Base URL 和终端环境。如果你也想跑出这样一张表，先从上面的官网链接创建 Key，然后按本文的配置开始即可。

🚀 告别海外账号与网络限制！稳定直连全球优质大模型，限时半价接入中。 👉 点击领取海量免费额度