五个 27B 小模型组队，真能把 Fable 5 拉下马？

开场小对谈

拾闻：今天早上海外论坛在传一个 GitHub 项目，说五个 Qwen3.8-27B 智能体组队，在 LiveCodeBench Hard 前十题上把 Fable 5 的单次调用打败了。消息来源是 Memdoor 的一个工作流示例，而且作者把 50 次运行的完整记录都放出来了。你先别管标题是不是在吹，单看这件事，值得聊吗？

永亮：值得聊，但不是聊「小模型打赢了大模型」这个爽文叙事。真正有意思的是：它把一个已经被验证过的多智能体方法，做成了一个 YAML 工作流，任何人可以换模型、换温度、加审批门。这相当于把 GVS5H 那套学术实现，拆成了工程团队能直接接进 CI 的零件。至于 Fable 5 是不是真的被打败，反而要打折听。

Q1：这个「击败」到底怎么发生的？

拾闻：Memdoor 的 README 写得挺明白：前五 pass 平均 9.8/10，原作者同模型同提示是 9.6，Fable 5 单次调用是 8.0。这个数据怎么理解？

永亮：先看清楚口径。它是拿 Qwen3.8-27B 跑了一个多智能体循环：planner 出方案，两个 ideator 出提案，solver 写代码，manager 做评审，还有一个 repair worker 修 bug。每个角色都是新上下文，通过磁盘上的文件通信。五 pass 下来平均 9.8，比 GVS5H 原作者自己的 9.6 略高，比 Fable 5 在那十道题上的单次调用 8.0 高出一截。

拾闻：也就是说，不是模型本身变强了，是用法变强了？

永亮：对。Fable 5 那 8.0 来自 GVS5H 作者文件里的单次调用数据，不是 Memdoor 在同一个 harness 里重跑的。所以严格说，这是「同一组题、同一口径下，多智能体 27B 比单次调用 Fable 5 表现更好」，而不是「27B 模型全面超过 Fable 5」。但即便如此，这个差距也足以说明：把多个小模型组织好，确实能在特定任务上摸到甚至超过 frontier 模型的边。更值得记住的是，Memdoor 把这套方法做成了 YAML 工作流，意味着你可以把 planner、ideator、manager 换成自己的模型和温度，把审批门插在任何一步，这对工程团队来说比分数本身更有用。

Q2：模型大小已经不再是硬通货了吗？

拾闻：这几年行业默认「模型越大越能打」。这个项目似乎在说，编排才是新的杠杆。你同意吗？

永亮：我同意一半。模型大小仍然决定上限，但编排决定你能把上限发挥出多少。Memdoor 这个例子里，真正的杠杆是四个东西：第一，分工，每个 agent 只负责一小段任务，上下文更干净；第二，持久状态，plan、notes、current solution 都写在文件里，角色之间不用把全部历史塞进 prompt；第三，多轮验证，manager 不只看代码，还要看测试结果；第四，可恢复，YAML 工作流带审批门和断点续跑，坏了能从失败步骤接着来。

拾闻：Memdoor 还提到一个「决策模型」前置省 token，这个怎么理解？

永亮：这是一个很实用的工程点。普通 chat 模型每次都要把整段对话历史、文件内容、工具结果全部吃进去，token 费用线性增长。决策模型先过一遍输入，决定这一步需要哪些工具、哪些文件、哪些上下文，只把精简后的必要信息丢给大模型。Memdoor 在自己的测试里说，有些任务能省掉 74% 的输入 token。对多智能体循环来说，这一点尤其关键，因为每个角色之间会反复读写文件，如果不做过滤，上下文会迅速膨胀。

拾闻：那是不是意味着以后买 frontier API 的性价比会下降？

永亮：要看场景。任务短、上下文不深、对延迟敏感，单次 frontier 调用仍然最省事。任务能拆成多个子任务、需要多轮迭代、可审计或本地跑，「决策模型 + 多个 worker + 持久化工作流」就更划算。未来工程团队会更像在设计流水线，而不是在跟模型死磕 prompt。

Q3：成本账怎么算？本地模型真能省钱？

拾闻：Memdoor 强调 BYOK 和本地模型，Ollama、llama.cpp、vLLM 都能接。GVS5H 原论文也说成本降到 frontier 的九分之一。这个账靠谱吗？

永亮：Memdoor 这次复现其实是在 OpenRouter 上跑的，不是本地机器。50 次有效运行花了 35.79 美元，加上 16 次被截断或修复的尝试一共 38.77 美元。中位单次 0.39 美元，中位运行时间 40 分钟，最长一次 4 小时。如果按本地 vLLM FP8 跑，作者原话是能在单 GPU 上跑顺。所以本地确实可以省掉 API 调用费，但你要付的是硬件、电费和运维。

拾闻：那是不是说，个人开发者也能在家跑？

永亮：理论上可以。Memdoor 支持 Ollama、llama.cpp、vLLM、LM Studio，也支持自己的 janis 网关。论坛上有人提到，Bonsai 2 量化之后，Qwen3.8-27B 能在普通游戏机上跑到 50 token/s。HN 里有评论说「Fable 5 级别的编码性能可以在本地实现，只要 harness 设计得好」。但这里有两个坑：一是量化会不会损失推理质量，二是多智能体循环的等待时间。你在本地跑一个 agent 可能很快，但五个 agent 串起来回跑，再加上文件读写和测试，整体耗时会被放大。

拾闻：那和 frontier API 比呢？

永亮： frontier API 是按 token 计费，好处是弹性、快、不用管机器。本地模型是一次性硬件投入，边际成本低。以 Qwen3.8-27B 为例，Bonsai 2 量化后能在普通游戏机上跑到 50 token/s，这对个人开发者和小团队很有吸引力。但要注意，Memdoor 这次复现里多智能体循环最长跑了 4 小时，如果本地 GPU 慢，体验会大打折扣。成本不是只看账单，还要看时间、复杂度和故障率。

Q4：标题里的「beats」要打多少折扣？

拾闻：你刚才一直提醒要打折扣。具体有哪些 caveat？

永亮：第一条，样本只有前十题。GVS5H 论文自己是 100 题，Memdoor 这次只做了前十，代表性有限。第二条，污染说不清楚。这十题来自 2025 年 3 月底到 4 月初的比赛题，Qwen3.8-27B 的训练数据很可能见过，作者也明确说 contamination cannot be ruled out。第三条，Fable 5 不是同环境重跑，数据来自 GVS5H 作者文件，不能排除 harness 差异。第四条，多智能体的时间成本很高，中位 40 分钟，最长 4 小时，这和单次调用完全不是一回事。第五条，OpenRouter 上不同 host 的精度不透明，作者本地是 FP8 vLLM，云端可能不一样。

拾闻：论坛上的评论怎么看？

永亮：Hacker News 上也有人指出，前十题可能已饱和，LiveCodeBench Hard 本身也年代不短。还有人希望看到 Qwen3.8-flash-next 的测试，因为 flash-next 在很多编码任务上比 27B 更快、更强。作者自己也承认，调调 prompt 和温度，说不定能拿到满分 10。这说明结果对参数敏感，不是一套固定配方就能复制到所有场景。另外有个评论问得好：「五个 27B 能打过五个 Fable 5 吗？」这个问题直击要害，因为真正公平的对比应该是多智能体 vs 多智能体，而不是多智能体小模型 vs 单 call 大模型。

拾闻：那是不是说「五个 27B 击败 Fable 5」这个标题在标题党？

永亮：在特定口径下是事实，但离普遍结论还很远。它更像是一个工程复现 + 方法验证，而不是一个可以写进选购指南的结论。我作为读者，会把标题里的「beats」理解为「在限定条件下展示了可比性」，而不是「全面超越」。

Q5：对一线工程师来说，这件事最大的启示是什么？

拾闻：最后一个问题，如果这件事是真的、且可推广，对普通工程师的工作意味着什么？

永亮：意味着我们的工作重心会继续从「写代码」向「设计工作流和验收门槛」迁移。过去两年，大家拼的是 prompt 工程；接下来，拼的是怎么把任务拆成可验证的步骤、怎么设计 agent 之间的协作协议、怎么设定审批门和回滚点。Memdoor 这个工作流里有几个很值得学的点：用 YAML 定义步骤，独立步骤并行跑，失败步骤能重试，关键步骤加人工审批，结果写回磁盘而不是全塞进上下文。

拾闻：这种转变对团队结构有什么影响？

永亮：最直接的影响是，「会用 AI 写代码」不再是稀缺能力，「会设计 agent 流程」才是。以前一个高级工程师的价值在于能写出复杂算法，现在更在于能判断哪些问题适合单 agent、哪些需要多 agent、哪些步骤必须留人工审批。团队里会出现 workflow designer、agent reviewer 这类新职责。对管理者来说，考核指标也要变：不能只看代码行数，而要看流程的稳定性、可复现性和错误回退能力。

拾闻：那会不会以后工程师都不需要写代码了？

永亮：不会。但「写代码」会变成更小的环节，更大的价值在于定义问题、拆解流程、设计验收标准。就像当年 DevOps 把运维和开发打通一样，现在 agent workflow 把需求分析、代码生成、测试验证、人工审批串成一条流水线。未来一个工程师的核心能力，可能是把业务问题翻译成 agent 能执行的流程图，而不是单纯比拼谁能写出更漂亮的函数。

拾闻：对于想尝试的团队，你会有什么建议？

永亮：先从自己真实的代码任务试起，不要用 benchmark 数字指导选型。拿一个具体的 bug 修复或重新设计任务，用 Memdoor 或 GVS5H 的方法跑一遍，记录时间、token 成本、正确率。同时一定要设定验收门槛，比如单元测试必须过、人工 review 必须过，否则多智能体很容易自己把自己绕进去。最后，别把本地模型当成免费午餐，硬件、量化精度、推理延迟都要算进去。如果团队没有运维本地 GPU 的经验，从 OpenRouter 这种 BYOK 方案开始试反而更现实。

---

署名：永亮