小模型运行编程Agent，工具精简可能更快

dev.to · AI#Agent#小模型#工具测评

Editor brief · 编辑速览

一项使用Qwen3.5-4B的十款Agent测试中，Pi、Goose和Crush均完成五项基础任务，Pi以96秒总耗时领先。作者推测精简工具和短系统提示可能有帮助，但测试尚未证明原因。

文章思维导图

Knowledge map

拖拽缩放

AI deep read

AI 深度解读

同一个 Qwen3.5-4B，换一套 Agent 工具，完成日常编程任务的速度能差多少？这次测试里，Pi 用 1 分 36 秒完成全部五项任务，Goose 和 Crush 也全部通过，但耗时更长。

结果很直观，原因却没坐实。原文最有价值的地方，是把「谁跑得快」和「为什么跑得快」分开了。对准备尝试本地小模型的程序员来说，它提供了一份工具候选名单，也展示了评测时容易漏掉的证据。

一位 r/openclaw 用户让十个 Agent 使用 Qwen3.5-4B，执行五项普通任务：从 YAML 读取端口，编写并运行统计脚本，修复 slugify 缺陷，统计多个日志文件中的错误，以及跨三个文件重命名函数。

每项限时十分钟，每次使用全新的测试样本，由自动检查脚本判定结果。这类任务贴近日常开发，也容易核验，比让模型自评完成质量更有参考价值。

前三名都完成了五项任务：

Pi 的领先幅度确实明显，但原文没有给出重复运行的统计。评论者因此追问：每个 Agent 与任务的组合，是不是只跑了一次？

这份结果证明了 Pi 在这批运行中领先，还不能证明它能稳定领先。

要判断稳定性，需要重复每个组合，同时报告通过率和耗时中位数。否则，一次幸运的执行路径就可能改变排名。启动失败也应单独记录：连不上后端，与启动后改错代码，反映的是两类问题。

作者猜测，Pi 的优势来自工具少、系统提示词短。它只提供 read、write、edit、bash 四个工具，模型理解调用格式的负担可能更轻。对于小模型，额外指令也可能增加处理时间。

这个解释合理，却缺少直接证据。测试没有记录 token 数量，也没有记录工具调用次数，因此无法区分提示词开销、工具格式负担、其他功能开销和偶然因素。

同一批 50 次运行的后续分析，还让解释变得更复杂：Pi、Goose、Crush、Cline、Atomic Agent、Opencode 六个 Agent 都通过了全部五项任务。主要失败原因也不是工具调用，而是精确匹配编辑出错、针对可见测试数据过拟合、计数错误，以及机械执行含糊指令。

这里的「过拟合」可以理解为：只照顾眼前样例，换一份输入就可能失效。工具调用成功，并不代表工作完成正确。

所以，后续结果没有否定「工具少可能更快」，但也没有支持它成为确定结论。若要验证，至少要补上 token 和工具调用日志，再用相同样本加入低于 2B 的模型作比较。

原文还给了一组硬件建议：5B 模型采用 Q4 量化时，文件约为 2.7 GB；作者称，8 GB 或 16 GB Mac，以及具有 6–8 GB 显存的 GPU 都能运行，测试所用的 M5 机器配置偏高。

对于 16 GB 机器，作者建议选择 Q4 的 4B–9B 模型，把上下文控制在 16,000–32,000 tokens，因为较长上下文会拖慢小内存 Mac。

这些属于经验建议，没有对应的硬件对照测试。这里的 5B 文件大小，也不能直接当成前面 Qwen3.5-4B 的实测内存占用。

我认可它用普通任务和自动检查来评估 Agent：读取配置、修改代码、统计日志，都是开发者能理解和复现的工作。但它更适合帮助筛选下一轮测试对象，还不足以决定团队该用哪一款工具。

「工具越少越快」目前仍是经验假说。相比直接删工具，更可靠的做法是先测清楚时间花在哪里，以及任务有没有做对。原文也没有提供精简工具集与完整工具集的同条件对照，不能替这个解释背书。

另外，五项小任务没有覆盖大型仓库和长流程协作。对前端、Node 团队而言，这张榜单可以作为试用起点，不能直接推导出复杂项目中的表现。

试用本地 Agent 时，可以复用这五类任务，换成自己的 YAML、Node 脚本、日志和跨文件修改样本，并准备独立的自动检查。
比较工具时，对每个任务重复运行，同时记录通过率、耗时中位数、token 数量和工具调用次数，把启动失败单独列出。
检查 AI 修改时，除了确认命令执行成功，还应关注精确替换是否漏改、统计结果是否正确，以及代码是否只适配了可见样例。
在 16 GB Mac 上试用时，可以把 Q4、4B–9B 和 16,000–32,000 tokens 作为作者建议的起点，再根据自己的任务测量速度与内存占用。