team-solve: 5 Qwen3.8-27B đấu Fable 5 trên LiveCodeBench Hard
Workflow đa tác tử team-solve của Memdoor dùng 5 vai Qwen3.8-27B, đạt trung bình 9,8/10 trên 10 bài LiveCodeBench Hard, so với 8,0 của Fable 5.

Một workflow mã nguồn mở tên team-solve, chạy trên công cụ CLI Memdoor, vừa lên trang nhất Hacker News. Workflow này tái dựng một phương pháp đa tác tử (multi-agent): nhiều phiên bản Qwen3.8-27B chia vai để giải bài lập trình thi đấu. Trên 10 bài đầu của LiveCodeBench Hard, nó đạt điểm trung bình cao hơn Fable 5 chạy một mình. Điểm đáng chú ý không chỉ nằm ở con số. Tác giả công bố toàn bộ log, chi phí và cả những lần chạy thất bại, nên ai cũng có thể kiểm tra lại.
Memdoor và team-solve là gì
Theo mô tả trên repo, Memdoor là một coding và automation agent gọn nhẹ, đóng gói trong một file CLI duy nhất. Công cụ chạy được trên máy cục bộ hoặc qua SSH, có cơ chế tối ưu lượng token tiêu thụ, và hỗ trợ tự động hóa CI hay cron bằng các workflow "bền" (durable workflows), tức là có thể tiếp tục chạy sau khi bị gián đoạn.
team-solve là một ví dụ trong thư mục examples/workflows của repo guregodevo/memdoor. Đây là một harness đa tác tử cho bài toán lập trình, gồm năm vai:
- planner: đọc đề, lập kế hoạch
- hai ideator (A và B): mỗi bên đề xuất một hướng giải
- solver: chọn hướng và viết code
- manager: đọc kết quả test và ra chỉ dẫn sửa
Ngoài ra còn một repair worker chuyên sửa code. Mỗi vai bắt đầu với context trống và chỉ giao tiếp với nhau qua file trên đĩa. Việc một lời giải "đạt" hay "không đạt" do một shell script chạy test mẫu quyết định, chứ không phải một mô hình tự đánh giá.
Phương pháp này lấy từ công trình GVS5H (Lee, 2026), vốn cho rằng năm mô hình Qwen3.8-27B có thể sánh ngang Fable 5 trên LiveCodeBench Hard. Theo tác giả repo, các file của workflow do chính agent coder của Memdoor viết ra từ một bản mô tả phương pháp (ngày 25/10/2026), không ai viết tay.
Kết quả: 9,8 so với 9,6 và 8,0
Tác giả dựng lại harness của nhóm GVS5H thành một workflow Memdoor. Cấu hình giữ giống bản gốc: cùng mô hình Qwen3.8-27B, giới hạn phản hồi 128K, đúng prompt và vòng lặp của nhóm nghiên cứu. Họ chạy 10 bài đầu trong danh sách LiveCodeBench Hard của nhóm, mỗi bài 5 lượt. Mọi chương trình được chấm trên toàn bộ test công khai lẫn test ẩn, bằng bộ chấm đã được nhóm tác giả sửa lỗi.
| Lượt | Memdoor workflow | Harness 27B của nhóm GVS5H | Fable 5 một mình |
|---|---|---|---|
| 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 |
| Trung bình | 9,8 | 9,6 | 8,0 |
Hai cột của nhóm GVS5H lấy từ các file kết quả đã chấm lại trong repo của họ, cũng chính là số liệu trong bài báo. Toàn bộ 50 lần chạy của Memdoor nằm trong bench/results/parity-5pass/. Thư mục này lưu từng request và reply, chương trình sinh ra, output đầy đủ của bộ chấm, chi phí từng lời gọi, host đã phục vụ, và cả những lần thử không được tính.
Một số con số đáng chú ý:
- 49/50 lần chạy giải đúng.
- Tổng chi phí 50 lần chạy là $35,79 (15,3 triệu output token). Nếu cộng thêm 16 lần thử bị cắt vì hết giờ, bị dừng để sửa hoặc bị tạm dừng thì lên $38,77.
- Mỗi lần chạy mất trung vị 40 phút thời gian mô hình (lâu nhất 4 giờ) và tốn trung vị $0,39.
Các tham số giữ đúng như bản gốc: temperature 0,3 cho bước plan, 0,4 cho ideation, 0,2 cho manager và worker; top_p 0,95, top_k 20; tối đa 10 vòng. Tác giả còn viết lib/test_parity.py để chạy song song code của nhóm nghiên cứu và workflow Memdoor với cùng một mô hình giả lập, rồi so từng request theo từng byte. Theo repo, cả bốn trường hợp kiểm tra đều giống hệt nhau.
Khác biệt lớn nhất nằm ở hạ tầng. Nhóm GVS5H tự host vLLM ở FP8. Bản Memdoor chạy qua OpenRouter, với các nhà cung cấp Modal, CoreWeave, Parasail và Wafer. Kết quả là 203 lời gọi do Modal phục vụ, 27 do CoreWeave và 115 do Wafer. Có ba lần chạy bị chuyển host giữa chừng.
Cách workflow vận hành
Luồng các bước như sau:
plan ──┬── ideate-a ──┬── solve ── test ── review ── repair ── verify
└── ideate-b ──┘
planđọctask.md, ghiplan.mdvà một sổ ghi chépnotes.md.ideate-avàideate-bchạy song song. A đề xuất thuật toán trực tiếp nhất mà chứng minh được, B đề xuất một hướng thuộc họ kỹ thuật khác.solveđọc cả hai đề xuất, chọn một, rồi viếtsolution.py.testlà một lệnh shell chạy test mẫu, ghi log. Bước này không bao giờ làm fail cả workflow.review(manager) đọc output test thật, không dựa vào lời tự khẳng định của mô hình, rồi viết chỉ dẫn sửa.repairsửa code nếu cần.verifychạy lại test. Exit code khác 0 nghĩa là workflow thất bại.
Prompt của mọi agent đều nhắc rõ: context mới, hãy đọc file, đừng dựa vào lịch sử chat. Theo bài báo GVS5H, chính kỷ luật "sổ ghi chép chung" này tạo ra phần lớn mức cải thiện. Mỗi bước là một file YAML trong steps/, theo định dạng của mario, engine nằm bên dưới Memdoor. Trường requires: định nghĩa đồ thị DAG. Muốn thay đổi một vai thì chỉ cần sửa prompt của vai đó.
Vì sao lập trình viên Việt Nam nên để ý
Chi phí API cho các mô hình hàng đầu vẫn là gánh nặng với nhiều cá nhân và startup trong nước. Thí nghiệm này gợi ý một hướng khác: dùng mô hình cỡ trung (27B) nhưng tổ chức quy trình tốt, chia vai rõ, giao tiếp qua file, lấy test thật làm trọng tài. Cách đó có thể đạt kết quả tương đương hoặc tốt hơn một mô hình lớn gọi một lần, ít nhất trên một tập bài nhỏ.
Đây là nhận định của người viết: mô hình 27B nằm trong tầm tự host được với một GPU đủ VRAM hoặc khi đã lượng tử hóa. Vì vậy, đây là hướng đáng thử với các đội cần chạy agent trên hạ tầng riêng vì lý do dữ liệu hay chi phí. Ngay cả khi không dùng Memdoor, mẫu thiết kế "agent không chia sẻ chat, chỉ đọc và ghi file, kết quả do script quyết định" vẫn có thể áp dụng cho pipeline CI hay công cụ review code nội bộ.
Những bài học vận hành mà tác giả ghi lại cũng rất thực tế:
- Văn bản đề bài ảnh hưởng mạnh. Bản đầu tiên tự viết lại đề thành file task riêng, và mô hình 27B lập kế hoạch kém hơn hẳn so với khi dùng nguyên văn đề LiveCodeBench. Với bài arc196_c, kế hoạch đúng 0/2 lần so với 2/2.
- Cần retry. Một nhà cung cấp làm rớt stream giữa câu trả lời. Do agent coder đã đặt
max_retries: 0nên cả lượt chạy chết luôn. Hiện các bước agent đã dùngmax_retries: 1, và lượt chạy được khôi phục bằng--partition, giữ lại phần việc đã xong. - Prompt dễ bị "học tủ". Prompt cho ideator ban đầu nêu thẳng phương pháp của bài mẫu, điều này sẽ dẫn sai với bài khác. Tác giả đã sửa thành yêu cầu chung (ngày 28/10/2026).
Để khớp với harness gốc, Memdoor cũng được bổ sung bốn tính năng. Thứ nhất, task có thể trả về phần reasoning khi mô hình không viết text. Thứ hai, có thể đặt top_p/top_k ngay trên dòng khai báo model. Thứ ba, có mark_cutoff để đánh dấu phản hồi bị cắt ở giới hạn. Thứ tư, một lời gọi có thể chạy với đồng hồ bốn giờ riêng.
Cách thử nhanh
Workflow cần Python 3 và bash. Các lệnh cài đặt theo repo:
curl -fsSL https://memdoor.ai/install.sh | bash
memdoor connect openrouter # hoặc anthropic, openai, gemini, chatgpt; hoặc: memdoor connect local
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/* .
memdoor workflow run team-solve --wait
Lệnh memdoor connect local dùng cho Ollama, llama.cpp, vLLM hoặc LM Studio trên máy. Workflow trả exit code 0 khi mọi test mẫu đều qua. Tiến độ hiển thị trên stderr, hoặc có thể xem trực quan bằng /workflow trong memdoor tui.
Để giải bài của riêng bạn, thay task.md và đặt các cặp test tests/N.in / tests/N.out bên cạnh. Chương trình luôn là solution.py, đọc từ stdin, và được so với kết quả mẫu bằng diff. Nếu muốn gắn workflow với một repo cụ thể, chép thư mục vào .memdoor/workflows/ của project đó. Bản trong project sẽ được ưu tiên. Các bước không chỉ định model nào, nên model đang được pin bằng /model sẽ trả lời, kể cả model chạy cục bộ.
Với bài mẫu đi kèm (đếm số chuỗi con trên bảng chữ {a, b, c} có số lượng mỗi chữ bằng nhau, độ dài tới 200.000 ký tự), lần chạy đầu qua 8/8 bước và 5/5 test. Solver chọn phương pháp prefix-state của ideator A, độ phức tạp O(N), dùng dictionary lưu cặp (a−b, a−c). Đối chiếu với brute force trên 300 chuỗi ngẫu nhiên không thấy sai lệch, và chương trình chạy 0,04 giây ở N = 200.000.
Lưu ý và hạn chế
- Tập thử rất nhỏ. Chỉ 10 bài, mỗi bài 5 lượt, trong khi nhóm GVS5H dùng 100 bài. Tiêu đề "beats Fable 5" cần được đọc trong giới hạn đó.
- Có thể bị nhiễm dữ liệu. Các đề thi diễn ra từ 29/3 đến 6/4/2025, mô hình có thể đã thấy chúng khi huấn luyện. Chính tác giả thừa nhận không loại trừ được khả năng contamination.
- Fable 5 không chạy trong cùng harness. Cột Fable 5 là một lời gọi duy nhất cho mỗi bài, lấy từ file của nhóm nghiên cứu, không chạy lại trong thí nghiệm này.
- Khác hạ tầng. Thí nghiệm chạy qua OpenRouter, không phải máy cục bộ. Modal không công bố độ chính xác số học (precision) mà họ dùng, trong khi bản gốc chạy FP8.
- Vòng lặp vẫn có lỗ hổng. Ở lượt 5, bài abc399_e chỉ qua 32/44 test ẩn: chương trình vòng 1 đã đúng, nhưng manager tự nghĩ ra một phản ví dụ với đáp án sai, khiến cả đội viết lại. Ở lượt 4, hai bài arc196_c và arc196_d có lúc đã có chương trình qua hết test ẩn nhưng bị vòng sau ghi đè vì manager không báo xong. Hai bài này cuối cùng vẫn lấy lại được lời giải đúng, với chi phí $3,44 và $4,24, là hai lượt chạy đắt nhất. Tác giả đề xuất hai cách sửa: kiểm tra phản ví dụ của manager bằng brute force trên input nhỏ, và giữ lại chương trình cuối cùng đã qua test mẫu. Tuy nhiên hai cách này chưa được áp dụng trong các con số trên.
- Không có cổng kiểm duyệt của con người. Workflow mẫu chỉ có một vòng repair.
- Giấy phép: nguồn chưa nêu trong phần trích. Hãy kiểm tra file license của repo trước khi dùng cho mục đích thương mại.
- Bài đăng do chính tác giả Memdoor (guregodevo) gửi lên Hacker News và trỏ về repo của công cụ, nên đây cũng là một cách giới thiệu sản phẩm. Độc giả nên tự cân nhắc. Tính đến ngày 01/11/2026, bài nhận 141 điểm và 77 bình luận.
Kết
team-solve chưa phải bằng chứng rằng mô hình 27B đã vượt mô hình hàng đầu một cách tổng quát. Nhưng đây là một thí nghiệm minh bạch hiếm thấy: công khai từng request, từng đô la chi phí, và cả những chỗ thất bại. Với lập trình viên đang xây agent, phần giá trị nhất có lẽ là các bài học về cách tổ chức quy trình: context sạch, file làm kênh giao tiếp, test thật làm trọng tài. Những bài học này áp dụng được với bất kỳ mô hình nào bạn đang dùng.
Nguồn tham khảo: Hacker News – guregodevo/memdoor
Bài viết liên quan

AI cho lập trình viên8 phút đọc
Gemini 4 Carbon dẫn đầu Intelligence Index v5, chỉ xếp sau Opus 5.5 về coding
Gemini 4 Carbon đạt 59 điểm, đứng đầu Artificial Analysis Intelligence Index v5 và chỉ kém Claude Opus 5.5 ba điểm ở chỉ số coding agent.

AI cho lập trình viên17 phút đọc
OpenAI và Anthropic tặng credit API cho gói ChatGPT, Claude trả phí
OpenAI vừa áp dụng chính sách giống Anthropic: gói trả phí 100, 200, 500 USD/tháng được cấp credit API tương đương, dùng cho tổ chức API của bạn.

AI cho lập trình viên7 phút đọc
LlamaFactory: tinh chỉnh 100+ LLM và VLM trong một repo
LlamaFactory gộp pre-training, SFT, DPO, PPO, LoRA/QLoRA cho hơn 100 mô hình ngôn ngữ và đa phương thức vào một CLI và Web UI, giấy phép Apache-2.0.
Bình luận
Đang tải bình luận…