Pi 在 4B 模型上的 10 个智能体测试中拿了第一，问题是：为什么？
Pi 赢了。Goose 和 Crush 紧随其后。这个小测试最实在的地方在于，它不告诉你为什么——而这恰恰值得一读。
r/openclaw 上一位用户用 Qwen3.5-4B 跑了十个智能体（Agent），做了五个刻意普通的小任务：从 YAML 里读端口号、写并运行一个统计脚本、修一个 slugify 的 bug、统计多个日志文件里的错误数、在三个文件里重命名一个函数。每个任务限时十分钟，每次都用全新的文件环境，用自动化检查脚本当裁判。没有对“智能”的大话，就是一场工作台实操测试——而实操测试往往是营销话术现原形的地方。
Pi 不只是赢了，是大幅领先
Pi（1.3.0）用 1 分 36 秒跑完了全部五个任务——每个任务分别用时 10、14、24、19 和 29 秒。Goose（1.55.0）用了 2 分 51 秒，Crush（0.98.1）用了 3 分 31 秒，这两个也完成了全部五个任务。
这不是四舍五入的误差。在 4B 模型上，每一个浪费的 token 都是你能感受到的时间，Pi 的领先是实打实的——即便原因还没被证明。
最诱人的解释，仍然只是猜测——作者自己也这么说
作者的猜测是：Pi 赢是因为它只带了四个工具（read、write、edit、bash）和一个简短的系统提示，模型几乎不用琢磨工具格式。在小模型上，每多一个指令 token，时间上都能看出来。
这个理论很吸引人。但按作者自己的说法，它没有被实际测量。测试没有记录 token 数，也没有记录工具调用次数，所以没法把工具格式带来的摩擦，和功能臃肿、提示词开销或纯粹的运气区分开。
该表扬就表扬：大多数基准测试文章会把这种猜测包装成“发现”，这篇没有。
后续分析反而让事情更复杂了
同一批 50 次运行的后续分析发现，有六个智能体完成了全部五个任务——Pi、Goose、Crush、Cline、Atomic Agent 和 Opencode——而且工具调用并不是主要的失败原因。失败集中在精确匹配编辑、对可见测试数据过拟合、数错数，以及把模糊指令照字面执行。换句话说：这些智能体基本上不是败在调工具上。
它们在认真干活这件事上失败了。这并不能推翻工具格式理论，但确实说明：仅凭这项测试就向你推销“工具越少 = 代理越快”的人，是在过度推销。评论者提出了真正重要的问题：这些是单次运行吗？重复每个代理-任务配对，报告通过率和中位时间，否则一次幸运的运行就可能改变整个排名。把启动失败和任务失败分开。一个无法与后端启动的代理，告诉你的是兼容性问题，而不是它在任务上会有怎样的表现——把它们同等计数会搅乱排名。加入 token 和工具调用日志，并在相同测试样本上增加 2B 以下的对比。在此之前，这是一个提出问题的排名，而不是回答问题的测试。硬件建议清新而不装腔作势：不，你不需要昂贵的新配置。Q4 的 5B 模型大约是一个 2.7 GB 的文件，作者说它在 8 或 16 GB 的 Mac 或任何有 6–8 GB VRAM 的 GPU 上运行良好——用于测试的 M5 机器是杀鸡用牛刀。他对 16 GB 机器的规则是：坚持使用 Q4 的 4B–9B 模型，将上下文保持在 16,000–32,000 个 token，因为在较小的 Mac 上，大上下文才是速度杀手。这是建议，不是测量结果——但这正是代理工具世界可以多使用一些的那种实际诚实。深入探讨这是浓缩版本——完整分析涵盖逐个任务的时间、失败模式，以及能将这个排名变成真正测试的下一轮问题：Pi 在 4B 模型上的 10 代理测试中率先完成。问题是为什么最初发布于 Agentic Affairs ( https://agentic-affairs.com )
Pi 赢了，Goose 和 Crush 紧随其后。这个小型基准测试最实在的地方，恰恰是它不愿意告诉你 Pi 为什么赢——这也是它值得一读的原因。
r/openclaw 上有位用户用 Qwen3.5-4B 跑了十个智能体，完成了五个刻意挑选的普通任务：从 YAML 里读端口、写一个统计脚本并运行、修一个 slugify 的 bug、统计多个日志文件里的错误数、在三个文件中重命名一个函数。每个任务限时十分钟。