Memdoor team-solve：五个 Qwen3.8-27B 智能体在 LiveCodeBench Hard 上媲美 Fable 5

Memdoor 的 team-solve 工作流在 Qwen3.8-27B 上复现了 GVS5H 多智能体方法，在 LiveCodeBench Hard 前十个问题上五次运行的平均得分为 9.8/10，而原始作者的测试框架为 9.6，Fable 5 单独回答为 8.0。这一结果意义重大，因为它表明一个较小的开源权重模型，在纪律严明的多智能体框架下，能够在困难的编码基准上达到前沿模型的水平——每次运行大约花费 0.39 美元，模型时间中位数为 40 分钟。

该工作流是 memdoor 仓库中的一个公开示例，并在 Hacker News 上发布，获得了 385 分和 188 条评论。讨论分为两派：一派热衷于本地模型的平价表现，另一派则对仅十个问题的样本量持怀疑态度。

team-solve 到底是什么

team-solve 是一个用于编程问题的多智能体框架，以 Memdoor 工作流的形式编写。五个角色——规划者、两个构思者、一个解决者和一个管理者——外加一个修复工人，各自从全新的上下文开始，仅通过磁盘上的文件进行通信。由脚本而非模型来决定运行是否成功。

该方法源自 GVS5H（Lee, 2026），一篇报告称五个 Qwen3.8-27B 模型在 LiveCodeBench Hard 上媲美 Fable 5。Memdoor 的贡献是在其自己的工作流引擎中重新实现了该循环，使用了作者的确切提示词。

工作流文件由编码器本身根据 2026-10-25 的方法描述生成；没有人手写它们。

基准测试数据

Memdoor 将 GVS5H 的测试框架重建为 Memdoor 工作流，使用相同的模型——Qwen3.8-27B、128K 回复上限、作者的提示词和循环——并对其 LiveCodeBench Hard 列表中的前十个问题进行了五次运行。每个程序都在所有公开和隐藏测试上使用作者修正后的评分器进行评分。

运行	Memdoor 工作流	作者的 27B 框架	Fable 5 单独
1	10 / 10	9	7
2	10 / 10	10	8
3	10 / 10	10	10
4	10 / 10	9	8
5	9 / 10	10	7
平均	9.8	9.6	8.0

作者列的数据来自其仓库中的重新评分结果文件（q38_multiagent_pN、fable5_single_pN），与论文中的数字一致。所有 50 次运行都发布在 bench/results/parity-5pass/ 中，包括每个请求和回复、生成的程序、评分器的完整输出、每次调用的成本和提供主机，以及所有未计入的尝试。

50 次运行中有 49 次解决了问题。计入的 50 次运行花费 35.79 美元（1530 万输出 token）；包括因时钟中断、为修复而停止或暂停的 16 次尝试，总计 38.77 美元。一次运行的中位模型时间为 40 分钟，最长 4 小时，成本约 0.39 美元。

与原始框架相同之处与不同之处

Memdoor 的平价测试 lib/test_parity.py 将作者的 multiagent_solve 和 Memdoor 工作流针对一个脚本化模型运行，并比较每个请求。四个案例逐字节相同，一个字符的更改就会使它们不同。

匹配的设置包括温度（规划 0.3，构思 0.4，管理和工人 0.2）、top_p 0.95、top_k 20（作者的 vLLM 从模型自身配置中应用的）、128K 回复上限、最多 10 轮、被截断的工人被总结，以及无文本回复由推理回答。

主要区别在于主机。作者运行了自己的 FP8 vLLM。Memdoor 在 OpenRouter 上运行，按 Modal、CoreWeave、Parasail、Wafer 的顺序请求主机，直到 Modal 速度降至 14 token/s，然后限制为 FP8 主机（Wafer、Parasail、CoreWeave）。调用中，203 次由 Modal 提供，27 次由 CoreWeave 提供，115 次由 Wafer 提供；FP8 专用顺序中的所有调用都去了 Wafer。三次运行在运行中迁移，保留了已完成步骤，记录在 log/host-switch.txt 中。

问题文本是难点

Memdoor 的第一个版本为每个问题编写了自己的任务文件，27B 模型从该文件规划的效果不如从作者的确切 LiveCodeBench 文本。在问题 arc196_c 上，使用重写的任务文本时，计划成功 0/2 次，而使用原始文本则为 2/2。

需要对 Memdoor 进行四项更改，才能使工作流准确提出作者框架所提出的问题：

当任务未产生文本时，用模型的推理回答。
可以在模型行上设置 top_p 和 top_k。
mark_cutoff 处理在上限处被截断的回复。
调用可以在自己的四小时时钟上运行。

工作流失败之处

两次失败都追溯到作者循环中的两个相同缺口，而非模型问题。

第 5 次，abc399_e（44 个隐藏测试中通过 32 个）： 第 1 轮的程序是正确的。管理者发明了一个预期答案错误的反例，团队重写了程序，新版本通过了公开样本，但公开样本未覆盖该情况。
第 4 次，arc196_c 和 arc196_d： 一个通过所有隐藏测试的程序被后续轮次覆盖，因为管理者从未宣布工作完成。两者都在循环结束前恢复了正确程序——arc196_d 在第 8 轮，arc196_c 通过最终调用——分别花费 3.44 美元和 4.24 美元，是最昂贵的两次运行。

Memdoor 指出，两者都可以在不改变方法的情况下修复：检查管理者的反例是否与小型输入的暴力破解一致，并保留最后通过样本的程序。这两个修复均未包含在报告的数字中。

工作流的结构

步骤图是 steps/ 中 YAML 文件的有向无环图（DAG），使用 Memdoor 底层引擎 mario 的格式：

plan ──┬── ideate-a ──┬── solve ── test ── review ── repair ── verify
       └── ideate-b ──┘

步骤	类型	读取	写入
`plan`	智能体	`task.md`	`plan.md`，以及一个 `notes.md` 账本，每个构思者一个锚点
`ideate-a`、`ideate-b`	智能体，并行	`task.md`、`plan.md`、`notes.md`	在其锚点处提出建议：A 最直接可证明的算法，B 来自不同技术家族
`solve`	智能体	两个建议	`notes.md` 中的决策、`solution.py`
`test`	命令	`tests/`	`test-output.log`、`test-status.txt`（永不导致运行失败）
`review`	智能体	捕获的测试输出，而非模型的声明	`review.md`、`notes.md` 中的修复指令
`repair`	智能体	管理者的指令	修复后的 `solution.py`，如果样本通过则为空
`verify`	命令	`tests/`	`final-test-output.log`；非零退出导致运行失败

每个智能体提示都指示模型从全新上下文开始，读取文件，不依赖聊天历史。论文将收益归功于这种账本纪律。只有一个修复轮次，没有人工门控。最终的 verify 步骤是整个裁决：它运行 check-samples.sh，写入 final-test-output.log，如果任何样本失败则非零退出。

运行它

curl -fsSL https://memdoor.ai/install.sh | bash
memdoor connect openrouter                 # 或 anthropic、openai、gemini、chatgpt
# 或完全不需要密钥：memdoor connect local   # 本机上的 Ollama、llama.cpp、vLLM、LM Studio
git clone --depth 1 https://github.com/guregodevo/memdoor

mkdir -p ~/.memdoor/workflows
cp -r memdoor/examples/workflows/team-solve ~/.memdoor/workflows/   # 库：任何项目都能看到它
mkdir my-problem && cd my-problem
cp -r ../memdoor/examples/workflows/team-solve/sample/* .          # task.md + tests/1.in … 5.out
memdoor workflow run team-solve --wait   # 进度在 stderr，所有样本通过时退出 0

memdoor tui 中的 /workflow 实时绘制相同的运行。对于自定义问题，替换 task.md 并添加配对的 tests/N.in 和 tests/N.out 文件。程序是 solution.py，从标准输入读取，并与样本用 diff 比较。它需要 Python 3 和 bash。要将工作流保留在单个仓库中，请将文件夹复制到该项目的 .memdoor/workflows/；项目的副本优先。

步骤不指定模型。无论 /model 固定到什么，都会回答调用，包括通过 memdoor connect local 连接的本地运行时。

首次运行发现的问题

捆绑的示例要求计算字母表 {a, b, c} 上每个字母出现次数相等的子串数量，字符串长度可达 200,000 个字符。在通过 OpenRouter 的默认阶梯上：

8/8 步骤和 5/5 样本通过。解决者选择了构思者 A 的前缀状态方法：使用 (a−b, a−c) 对字典的 O(N) 算法。事后对 300 个随机字符串进行暴力破解未发现不匹配，程序在 N = 200,000 时运行时间为 0.04 秒。管理者未发现需要修复的问题。
一个构思者的提供商在回答中途断流。编码器写了 max_retries: 0，因此运行在那里失败。智能体步骤现在带有 max_retries: 1，并使用 --partition 恢复运行，保留了规划者和另一个构思者的工作。
构思者提示最初指定了示例的特定方法（A：流式前缀状态计数，B：排序前缀状态），这会将任何其他问题引向错误方向。它们现在要求 A 提供最直接可证明的算法，B 提供来自不同技术家族的算法（2026-10-28）。
首次尝试在 0 秒内失败所有步骤，提示“没有名为 coder 的智能体”，因为运行只在其自己的工作区中查找智能体。这在同一天在网关 v1.692.0 中修复。

作者明确陈述的注意事项

结果涵盖十个问题，每个五次运行，而非作者的 100 个问题。竞赛日期为 2025 年 3 月 29 日至 4 月 6 日，因此模型可能在训练期间见过它们，无法排除污染。Fable 5 列是每个问题单次调用，取自作者的结果文件；它未在此框架内运行。循环只看到公开样本，而分数是在隐藏测试上衡量的。

Hacker News 讨论补充的内容

对样本量的怀疑

最常见的反对意见是，十个问题无法支持强有力的声明。@zihotki 写道：

我会等待更多基准测试再下结论，因为这个基准只有“他们 LiveCodeBench Hard 列表的前十个问题”。而且 LiveCodeBench Hard 是一个几年前的老基准。可能已经非常饱和了

@jbellis 报告称在同一问题上花费了数周时间，直接指出了泛化风险：

我的看法：构建一个改进单个评估的框架非常容易，而构建一个能泛化的框架则非常困难。

@0xbadcafebee 提出了计算权衡论点：结果是一个小模型，发出许多请求和大量 token 预算，击败了一个大模型，后者只有一个请求和少量 token 预算，这本身并不令人惊讶。

团队结构为何可能有效

@topspin 认为有趣的变量是框架，而非模型：

我的猜测是，分工使各个上下文更有效。这是围绕上下文限制的优化。其中一部分仅仅是带来的净上下文量：每个团队成员都有一个上下文，因此净上下文量乘以团队成员数。

@yurimo 将机制描述为对解决方案盆地的搜索：多个模型和不同意见可以将系统推向更好的答案，即使没有单个模型足够强大。

@CharlieDigital 将设计联系到埃默里大学关于多智能体进化的论文，认为角色分离使嘈杂的思考 token 和工具调用远离下游智能体的上下文，因此每个后续智能体接收到更小、更集中的输入。

@robertkluin 报告在生产中运行了类似的基于文件的架构——规划者、研究者、实现者和审查者，实现者可以生成助手——并表示使用前沿模型的同事无法区分输出差异。

@mchusma 描述了一个混合模型审查循环，其中更便宜的模型审查由更强模型产生的计划和代码，并指出较小模型经常能发现问题。

本地模型的利害关系

几位评论者关注平价对在自有硬件上运行模型意味着什么。@roenxi 估计，使用 Bonsai 2 量化，Qwen 27B 可以在价格合理的游戏机上以约每秒 50 token 的速度运行，引用了 Steam 硬件调查中 16GB VRAM 和 32GB 系统内存的数据。

@novaRom 报告完全转向本地模型，指出 27B 模型可以在任何具有 64GB RAM 的现代 PC 或笔记本电脑上提供，主要缺点是因 256K 上下文限制而定期压缩。

@fedpost 将这项工作视为对冲提供商控制的策略：

我们迫切需要保持本地模型与超大规模提供商竞争。我不想永远受制于他们和他们的心血来潮。

@cloudking 对以基准为中心的热情提出反驳，询问是否有人构建了具有真实用户的高质量生产应用或游戏，基于本地模型。

对文章本身的反对意见

@vessenes 称工作日志格式难以阅读，并要求提供简短的人工编写摘要。@StilesCrisis 认为文本读起来像模型生成的散文。两种批评都针对呈现方式，而非发布的运行工件。

明显的后续问题

多位评论者提出了自然的对照：如果五个小模型击败一个大模型，那么五个大模型会做什么？@conception 说“五个 fable 模型的团队应该碾压其所有基准”，@amelius 问如何知道 Fable 5 不是已经是群体。已发布的实验没有回答这两个问题，因为 Fable 5 仅作为每个问题单次调用运行。