告别海外账号与网络限制稳定直连全球优质大模型限时半价接入中。 点击领取海量免费额度1. 把 Roo Code 接进一个真实会红的 Python 仓库Roo Code 这类 Agent 工具最容易被高估的地方是它在空仓库里写个hello world很顺最容易被低估的地方是它面对一个已经存在、测试已经红了的 Python 仓库时能不能按失败用例一条条改到绿。这次我拿一个刻意留了 bug 的小仓库做实验让 Roo Code 当执行者TaoToken 当默认供应商用一把 Key 把请求打到 https://taotoken.net/api看它能不能把pytest从 5 failed 跑到 0 failed。注册和创建 Key 在 TaoToken 完成后面所有配置都围绕这条通道展开。先说清楚角色分工被评测的是 Roo Code 这个 Agent 的修复链能力TaoToken 不是被评测对象它是 Key、Base URL 和对照基线。Roo Code 负责读文件、改代码、跑命令TaoToken 负责把模型调用稳定地送出去。这个区分很重要因为一旦把供应商当成被测产品文章就会变成「谁家 API 更快」的口水账而不是「Agent 能不能把测试改绿」的工程记录。我用的仓库叫invoice-kata一个处理发票金额计算的小项目故意在折扣、税费、四舍五入三个地方埋了错。目录树如下invoice-kata/ ├── pyproject.toml ├── README.md ├── src/ │ └── invoice_kata/ │ ├── __init__.py │ ├── discount.py │ ├── tax.py │ └── rounding.py └── tests/ ├── test_discount.py ├── test_tax.py └── test_rounding.pypyproject.toml里声明了pytest和pytest-cov源码用src布局测试通过pythonpath指向src。这样 Roo Code 在改代码时不会误改测试文件除非它明确判断测试本身写错了——这次实验里测试是对的错在实现。从零到能跑命令序列是这样的cd invoice-kata python -m venv .venv source .venv/bin/activate pip install -e .[dev] pytest -q第一次pytest -q的输出是 5 个失败分布在三个测试文件里。这个「红」的状态就是 Roo Code 的起点。如果一上来就是绿的Agent 没有可修的目标整个实验就失去意义。所以我在写这篇文章前特意确认了失败用例的数量和分布后面 Agent 的每一步都要对着这些失败走。Roo Code 的安装不复杂VS Code 扩展市场搜 Roo Code 装上即可。真正要配的是供应商。Roo Code 支持 OpenAI Compatible 模式这意味着只要有一个兼容 OpenAI 协议、能返回标准chat/completions结构的端点就能接进来。TaoToken 的 Base URL 是https://taotoken.net/api注意末尾不带/v1这一点在配置时容易写错。模型 ID 以模型广场为准不要凭记忆填一个不存在的名字。配置路径是 Roo Code 设置里的 API Provider 选 OpenAI Compatible然后填三样东西Base URL、API Key、Model ID。API Key 用YOUR_API_KEY占位实际值从控制台创建。填完之后 Roo Code 会做一次连通性检查如果 401多半是 Key 没复制全或者带了多余空格如果 404多半是 Base URL 多写了/v1或者模型 ID 不存在。这一步做完Roo Code 就有了一个能对话、能读文件、能执行命令的后端。接下来才是真正的修复链让它按失败用例逐个改每改一处就重跑pytest直到全绿。这个循环听起来简单但实际跑起来会遇到上下文管理、命令权限、失败信息回传三个坑后面几节会逐个拆。2. Roo Code 的 Harness 配置与失败用例修复循环Roo Code 在这个任务里扮演的是 Harness 角色它把「读文件、改代码、跑命令、看输出」串成一个循环。要让这个循环转起来得先理解它的工具集和权限模型。Roo Code 默认会请求文件读写和终端执行权限第一次跑命令时会弹确认。如果每次都手动点修复链会被打断所以我在设置里把终端命令的自动批准打开但只限pytest和python开头的命令。这样既不会让它乱跑rm也不会让每次重跑都卡在确认框上。Harness 的配置分三块模型、工具、上下文。模型这块Roo Code 的 OpenAI Compatible 配置里Base URL 填https://taotoken.net/apiAPI Key 填YOUR_API_KEYModel ID 从模型广场选一个适合代码修复的。选模型时不要只看名字要看它是否支持长上下文和工具调用。修复链里 Agent 需要反复读测试文件、读源码、读 pytest 输出上下文会累积得很快。如果模型上下文窗口太小跑到第三个失败用例时前面的信息就被挤掉了Agent 会开始重复改同一个地方。工具这块Roo Code 的核心工具是read_file、write_to_file、execute_command、list_files。修复链里最常用的是前三个。read_file读测试和源码write_to_file改实现execute_command跑pytest。这里有个细节Roo Code 执行命令时是在工作区根目录下跑的所以pytest -q能直接找到pyproject.toml。如果仓库结构是嵌套的需要在命令里cd到子目录或者用pytest tests/ -q指定路径。上下文这块Roo Code 有一个「上下文窗口」的概念它会自动把最近的文件读取和命令输出放进对话。修复链跑到后面pytest 输出会越来越长因为通过的用例也会打印。为了控制上下文我在pyproject.toml里加了addopts -q --tbshort让 pytest 只输出失败摘要和短回溯。这样 Agent 拿到的失败信息更聚焦不会把通过的用例也塞进上下文。配置完成后我给了 Roo Code 第一条指令这个仓库的 pytest 有 5 个失败。请逐个修复每次只改一个文件改完立刻跑 pytest -q确认失败数减少后再改下一个。不要修改 tests/ 下的文件。这条指令的关键约束是「每次只改一个文件」和「不要修改测试」。前者防止 Agent 一次性大改导致失败原因混淆后者防止它把测试改成通过而不是把实现改对。Roo Code 收到指令后先list_files看目录然后read_file读tests/test_discount.py再读src/invoice_kata/discount.py接着write_to_file改实现最后execute_command跑pytest -q。第一次循环它改了discount.py里的折扣计算。原来的实现是price * discount正确应该是price * (1 - discount)。这个错误很典型把折扣率直接乘上去而不是乘剩余比例。Roo Code 从测试断言里推断出了正确语义改完跑 pytest失败数从 5 降到 4。第二次循环它读tests/test_tax.py和tax.py。税费的错误是税率用反了price * rate写成了price / rate。Roo Code 改完跑 pytest失败数降到 3。第三次循环它读tests/test_rounding.py和rounding.py。四舍五入的错误是用了round()的银行家舍入而测试期望的是标准四舍五入。Roo Code 把round(x, 2)改成了Decimal的quantize配合ROUND_HALF_UP。改完跑 pytest失败数降到 0。整个循环跑了三轮每轮都有明确的「读-改-跑」三步。这里能看出 Roo Code 的修复链是否可靠取决于两件事一是它能不能从 pytest 输出里准确提取失败原因二是它能不能在改完后正确判断失败数是否减少。如果 pytest 输出被截断或者 Agent 没看清失败数它可能会误以为改对了继续改下一个结果错误累积。为了验证它没有「假绿」我在最后一轮之后手动跑了一次完整 pytest确认 5 个用例全过。Agent 交出的 diff 如下diff --git a/src/invoice_kata/discount.py b/src/invoice_kata/discount.py --- a/src/invoice_kata/discount.py b/src/invoice_kata/discount.py -1,4 1,4 def apply_discount(price, discount): - return price * discount return price * (1 - discount) diff --git a/src/invoice_kata/tax.py b/src/invoice_kata/tax.py --- a/src/invoice_kata/tax.py b/src/invoice_kata/tax.py -1,4 1,4 def apply_tax(price, rate): - return price / rate return price * (1 rate) diff --git a/src/invoice_kata/rounding.py b/src/invoice_kata/rounding.py --- a/src/invoice_kata/rounding.py b/src/invoice_kata/rounding.py -1,6 1,8 from decimal import Decimal, ROUND_HALF_UP def round_money(amount): - return round(amount, 2) return float(Decimal(str(amount)).quantize(Decimal(0.01), roundingROUND_HALF_UP))最终 pytest 输出5 passed in 0.42s这个结果说明 Roo Code 在这个任务上的修复链是通的。但要注意这是一次运行不代表它在所有仓库上都能这样。失败用例的复杂度、测试断言的清晰度、模型对 Python 语义的理解都会影响结果。下一节讲怎么用同一把 Key 复现这个对照表。3. 用同一把 Key 复现修复链对照表复现这件事最怕的是「我这边能跑你那边跑不起来」。所以这一节把环境、命令、配置都写死你照着做应该能得到接近的结果。先声明下面的对照表是一次运行的结果不是公榜分数也不代表模型在 SWE-bench 这类榜单上的表现。公榜上的是模型读者用 TaoToken 的 Key 和 Base URL 接的是同一个模型但本地跑出来的数字只对这次任务负责。环境准备cd invoice-kata python -m venv .venv source .venv/bin/activate pip install -e .[dev] pytest -q确认初始状态是 5 failed。如果不是说明仓库版本或依赖版本有差异先对齐pyproject.toml里的依赖。Roo Code 配置{ apiProvider: openai-compatible, baseUrl: https://taotoken.net/api, apiKey: YOUR_API_KEY, modelId: 以模型广场为准 }注意baseUrl末尾不带/v1modelId不要凭记忆填。填完后在 Roo Code 里发一条测试消息确认能收到回复。如果 401检查 Key如果 404检查 Base URL 和模型 ID。修复链指令这个仓库的 pytest 有 5 个失败。请逐个修复每次只改一个文件改完立刻跑 pytest -q确认失败数减少后再改下一个。不要修改 tests/ 下的文件。然后观察 Roo Code 的执行过程。它应该会先列文件、读测试、读源码、改实现、跑 pytest重复三轮。每轮结束后失败数应该从 5 降到 4、3、0。对照表如下记录的是这次运行的关键指标阶段失败数改动文件pytest 耗时备注初始5无0.38s确认红第一轮4discount.py0.40s折扣语义修正第二轮3tax.py0.41s税率方向修正第三轮0rounding.py0.42s舍入模式修正这张表里没有 Token 消耗数字因为我没有在 Roo Code 里开用量统计也不想凭感觉编一个。如果你要看 Token 用量可以在 TaoToken 控制台看这次调用的入账记录。控制台入口在 TaoToken创建 Key 也在那里。复现时容易遇到的偏差第一模型 ID 不同修复链的轮数可能不同。有的模型一次就能改对三个文件有的模型需要多轮试探。轮数少不代表模型强可能只是它一次改得多风险也更大。第二pytest 输出格式不同Agent 提取失败信息的能力会受影响。--tbshort比默认回溯更友好建议保留。第三Roo Code 的自动批准设置不同交互节奏会变。如果每次命令都要手动确认修复链会变成「半自动」耗时统计就没意义了。第四仓库初始状态不同。如果你拿到的仓库已经是绿的或者失败数不是 5对照表就对不上。复现的前提是初始状态一致。这张对照表的价值不在于数字本身而在于它把「Agent 修复链」拆成了可观察的步骤。你能看到它每一步改了什么、失败数怎么变、最终 diff 长什么样。这比只看一个「5 passed」的结论有用得多。如果你想让对照更完整可以换一个模型 ID 再跑一遍把两张表放在一起看。但要注意换模型 ID 时 Base URL 和 Key 不变这样变量只有一个。TaoToken 在这里的作用就是提供统一的通道让你换模型时不用换 Key、不用换 Base URL只改一个 Model ID 就行。4. 排障Roo Code 接 TaoToken 时最容易错的几处排障这一节只写本篇配置相关的错误不写泛泛的「网络问题」。Roo Code 接 TaoToken 时错误基本集中在四个地方Base URL、API Key、模型 ID、命令权限。Base URL 最常见的错是加了/v1。TaoToken 的 Base URL 是https://taotoken.net/api末尾不带/v1。如果你写成https://taotoken.net/api/v1Roo Code 请求的路径会变成/api/v1/chat/completions而正确的路径是/api/chat/completions。结果就是 404。这个错很隐蔽因为很多 OpenAI 兼容端点确实带/v1但 TaoToken 的写法是不带。改的时候直接把/v1删掉。API Key 最常见的错是复制时带了空格或换行。Roo Code 的 Key 输入框不会自动 trim如果你从控制台复制时多选了一个换行Key 就会变成YOUR_API_KEY\n请求时 401。解决办法是粘贴后手动检查一遍或者先在文本编辑器里过一道。另外Key 创建后如果没复制控制台不会再显示完整值只能重新创建。所以创建时就要存好。模型 ID 最常见的错是凭记忆填。比如你记得某个模型叫gpt-5但广场上根本没有这个 ID请求就会 404 或者返回模型不存在。正确做法是打开模型广场复制准确的 ID。模型 ID 以模型广场为准不要自己拼。如果你不确定哪个模型适合代码修复可以先在模型对话里试一条确认能正常返回再填进 Roo Code。命令权限的错是自动批准没开或者开得太大。没开的话每次pytest都要手动确认修复链断断续续。开得太大比如允许所有命令Agent 可能跑一些你没预期的操作。建议只批准pytest和python开头的命令这样既流畅又安全。还有一个错是工作区路径不对。Roo Code 默认在工作区根目录执行命令如果你的pyproject.toml在子目录pytest -q会找不到配置。解决办法是在 Roo Code 里把工作区设到invoice-kata根目录或者在指令里明确写cd invoice-kata pytest -q。最后一个是上下文溢出。修复链跑到第三轮时对话里已经累积了三次文件读取和三次 pytest 输出。如果模型上下文窗口小前面的失败信息会被挤掉Agent 可能忘记已经改过discount.py又去改一遍。解决办法是开--tbshort减少输出或者在每轮结束后让 Roo Code 总结一下当前状态。Roo Code 有一个「压缩对话」的功能可以在上下文快满时手动触发。这些错我都踩过至少一个。最耽误时间的是 Base URL 多写/v1因为 404 的报错信息不会直接告诉你路径错了只会说模型不存在。后来我养成了一个习惯配置完先发一条最简单的消息确认通道通了再开始修复链。这样能把配置错误和 Agent 能力问题分开。排障的顺序建议是先确认 Key 能创建、能复制再确认 Base URL 不带/v1再确认模型 ID 从广场复制最后确认命令权限和工作区路径。这四步都对了修复链跑不起来才可能是 Agent 本身的问题。5. 修复链跑通之后怎么把这次调用对账修复链跑通、pytest 全绿之后还有一件事值得做确认这次调用在控制台里入了账。这不是为了看数字好看而是为了确认你用的通道是正规的、可对账的。临时通道最麻烦的地方就是调用完了查不到记录出了问题找不到人。TaoToken 的控制台能看到调用记录和用量这对长期跑 Agent 的人来说很重要。对账的路径是打开 TaoToken进控制台看这次修复链的调用是否出现。如果出现了说明 Key 和 Base URL 都配对了。如果没出现回去检查 Roo Code 的配置多半是请求没打到https://taotoken.net/api。对账之后如果你打算长期用 Roo Code 跑修复链可以看两个东西。一个是 模型对话用来确认模型 ID 和广场一致避免填错。另一个是 Coding Plan适合长期开发场景。Key 在 控制台 创建Claude Code 和 CC Switch 的接入对照 接入文档。这次实验的结论是Roo Code 在一个有明确失败用例的 Python 仓库里能按「读-改-跑」的循环把测试改绿。TaoToken 在这里提供的是稳定的 Key 和 Base URL让这个循环不因为通道问题中断。修复链本身的能力取决于模型和 Harness 的配合通道只负责把请求送出去、把结果带回来。如果你要复现建议从 5 个失败用例的小仓库开始不要一上来就找大项目。失败用例越清晰Agent 的修复链越容易观察。等你熟悉了「读-改-跑」的节奏再换更复杂的仓库那时候你就能判断哪些失败是 Agent 能修的哪些需要人先拆解。最后提醒一句AI 工具不能直连你的生产库或生产机执行操作。Roo Code 生成的命令和 diff应该由你在本地或测试环境执行确认无误后再上生产。这次实验全程在本地虚拟环境里跑没有碰任何线上资源。 告别海外账号与网络限制稳定直连全球优质大模型限时半价接入中。 点击领取海量免费额度