你让 AI 替你改三份文件里的函数名。它明明找对了地方，却因为复制旧代码时漏掉一个空行，编辑工具拒绝执行。接下来，它没有重新检查，而是把同一份错误修改又交了五次，直到系统强制叫停。这个略显荒诞的循环，正是本次横测想弄清的问题：本地小模型做 Agent 时，究竟坏在哪一步？
这里的 Agent，不只是模型。它还有一套 Agent harness——连接模型、提示词、工具、文件系统和执行循环的外层“线束”。同一个模型接上不同线束，收到的提示、工具反馈和重试策略都会变化，表现也可能完全不同。
不换模型，只换线束
Reddit 用户 GapNew4766 在同一台 32GB M5 MacBook Pro 上固定使用 Qwen3.5-4B Q4_K_M，横测了 10 种 Agent 线束和 5 个小任务，共计 50 次运行。Q4_K_M 是量化版本：量化用较低精度保存模型权重，可以减少内存占用、方便本地运行，但也可能损失少量能力。
所有 Agent 都以 headless mode 运行，也就是不打开交互界面，由命令自动执行；同时开启 auto-approve，允许工具操作自动获批。每次运行使用全新的任务文件副本，最后由 pass/fail oracle 判定结果——它其实就是一段自动验收脚本，检查文件或测试是否符合要求。
据作者自述，Pi 1.3.0、goose 1.55.0、Crush 0.98.1、Cline 3.0.73、Atomic Agent 0.6.9 和 OpenCode 1.19.3 全部通过了五项任务。六套线束拿到满分，但作者认为，更值得看的不是总分，而是另外几次运行为何跌倒。
它知道要做什么，却走不出失败循环
最典型的故障，就是开头那次跨三个文件重命名函数。模型的修改方向没错，只是待匹配的旧文本少了一个空行。工具报告“找不到原文”后，它仍连续五次提交完全相同的编辑，最终触发线束的循环保护。
这说明至少在该案例里，失败不等于“不懂代码”。更准确地说，模型没能根据工具反馈改变策略。帖子下的讨论把改进方向指向更受约束的工具，例如按函数名整段替换，或用 AST——把代码拆成结构树——定位函数。不过这些只是讨论中的建议，并未在这次横测中验证。
第二类故障像“只复习了公开例题”。slugify 是把标题转换成适合网址的短字符串。某个 Agent 针对可见测试里的字符打了补丁，却在隐藏用例“C++ & Rust 2026”上输出错误的“c++-&-rust-2026”。它通过了眼前检查，却没有归纳出完整规则。
第三类故障更朴素：数不准。某个 Agent 把三份日志中的 43 行 ERROR 计成了 40 行，虽然仍正确找出了最常见的错误。这里更可靠的做法本应是调用计数工具，而不是让语言模型自己心算。材料还提到模型会机械理解含糊指令，但原帖在具体案例处截断，无法进一步判断。
工具调用反而不是这次的主角
作者原本预计，4B 模型最容易生成格式损坏的工具调用。但据其检查 Agent 日志和服务器日志，在启用 --jinja 与原生工具调用的这组实验中，没有发现解析错误、格式错误调用或未知工具。因此，这几次失败不能简单归咎于“模型不会调用工具”。
这个结论必须收窄理解：日志没有检出格式错误，只能说明这套配置下的 50 次运行没有出现相关记录；它不能证明所有4B模型、所有工具或所有线束都不存在调用问题。语法正确，也不代表工具选择和参数在语义上正确。
为什么值得关注
这次横测最有价值的地方，是把“模型行不行”拆成了更具体的问题：失败可能发生在精确匹配、失败后的重试、从样例归纳规则、计数，以及解释含糊指令等环节。线束也不是透明包装。提示词长度、工具设计、反馈方式、上下文组织和循环保护，都可能改变最终结果。
换句话说，给本地小模型做 Agent，不能只盯着一个总分。还要观察它失败后会不会换路，工具是否把任务变得足够明确，以及验收脚本有没有覆盖真正关心的结果。
局限与未知
- 全部结果来自一篇 Reddit 用户自述，没有公开代码、原始日志或独立复核，所有效果结论都属于单一信源。
- “50次运行”实际是 个组合各跑一次，无法衡量随机性、稳定性或显著性；任务较小、auto-approve 和测试覆盖也可能抬高通过率。
- 不同线束的提示词、工具实现和适配质量是重要混杂变量。现有材料不足以把观察到的差异全部归因于 Qwen3.5-4B，也不足以证明这些就是小模型 Agent 的普遍或主要故障模式。