Chọn harness open source cho vibe coding: nuôi context thay vì gom tool
Tuần trước có một bạn trong cộng đồng nhắn hỏi:
"Mình mới sang vibe coding, đang thử mấy ông harness open source (OpenCode, Pi, DSH…). Bạn chia sẻ kinh nghiệm với, và bộ tool/skill bạn đang dùng nữa. Mình build web tĩnh với Astro và LMS trên headless CMS, ngân sách hạn chế, ưu tiên open source."
Câu hỏi này đúng chỗ đau của rất nhiều người mới: thị trường harness đang nổ, mỗi tuần một ông mới, và cảm giác chậm chân là có thật.
Bài này trả lời bằng số đo thật từ máy mình — không phải review cảm tính. Cụ thể là log của 1.111 lượt subagent trong 4 ngày, cho ra một kết luận ngược đời: chạy nhiều agent song song làm mọi thứ chậm đi, và mình đã phải sửa lại toàn bộ cách điều phối.
Trước hết: "harness" là gì?
Công thức dễ nhớ: Agent = Model + Harness.
Model là phần suy nghĩ (Claude, GPT, Gemini, DeepSeek…). Harness là phần tay chân — thứ cho model đọc file, chạy lệnh terminal, gọi tool, nhớ ngữ cảnh, biết khi nào dừng.
Điều đó có nghĩa: bạn đổi harness thì model vẫn thế, và đổi model thì harness vẫn thế. Đây là chi tiết quan trọng nhất của cả bài, mình sẽ quay lại ở phần sau.
Bốn harness đang chạy thật trên máy mình
Không phải "đã thử cho biết" — đây là những ông có việc thật chạy qua, tính tới tháng 9/2026:
| Harness | Vai trò | Ghi chú thật |
|---|---|---|
| OpenCode | Trục chính | Open source, cắm được nhiều nhà model. Quan trọng hơn: mình để nó làm nguồn skill duy nhất, các CLI khác symlink sang |
| Pi | Việc nhiều bước | Không có subagent sẵn, phải cài extension. Chạy nhiều nhất trong tháng 9 |
| Claude Code / Codex | Việc chuyên biệt | Dùng khi cần đúng model đó, hoặc khi tính năng riêng của nó tiện hơn |
| DSH (DeepSeek Harness) | Đã chạy thật 2 tuần | Hiện tạm dừng — lý do ở phần dưới, và nó không phải "vì dở" |
Nhìn bảng này dễ tưởng mình sưu tầm tool. Thực tế ngược lại: chi phí chuyển đổi giữa chúng gần như bằng không, vì thứ mình đầu tư không nằm trong tool.
Điều đắt giá nhất không phải harness, mà là context bạn nuôi cho nó
Harness nào cũng thay được trong 5 phút. Thứ không thay được là context. Với mình có ba lớp:
1. AGENTS.md đặt ngay trong repo
Một file markdown ở gốc dự án, viết luật chơi: cấu trúc thư mục, quy ước đặt tên, lệnh build, lệnh deploy, những gì cấm đụng.
Agent đọc một lần là làm đúng ý, khỏi giải thích lại mỗi phiên. Đây là thứ lời nhất trong toàn bộ setup: bỏ ra 30 phút viết, xài cả năm.
Điểm cộng: cả OpenCode, Pi lẫn DSH đều đọc AGENTS.md (DSH đọc luôn cả CLAUDE.md). Nghĩa là file này sống sót qua mọi lần đổi tool.
2. Skills — kiến thức đóng gói, viết một lần dùng mọi nơi
Hiện mình có 324 skill, chia nhóm theo miền: Lark, n8n, tài chính, content, data platform, software engineering…
Mẹo quan trọng: chỉ giữ một nguồn duy nhất. Thư mục skill thật nằm ở OpenCode, các CLI còn lại chỉ symlink sang. Sửa một chỗ, mọi tool cùng cập nhật. Nếu bạn copy skill sang từng tool, ba tháng sau bạn sẽ có bốn phiên bản lệch nhau và không biết bản nào đúng.
Nếu chưa rõ khác biệt giữa agent, command và skill, đọc Agents vs Skills vs Commands trước.
3. Cho agent chạy CLI thật
Đừng dừng ở chat. Cho nó chạy git, chạy build, gọi API CMS, deploy thật. Sức mạnh của vibe coding nằm ở chỗ nó tự tay làm rồi đọc kết quả lỗi để sửa — chứ không phải viết ra đoạn code đẹp cho bạn tự dán.
Bẫy lớn nhất mình dính: tưởng nhiều agent thì nhanh hơn
Đây là phần mình muốn chia sẻ nhất, vì nó tốn tiền thật.
Pi không có subagent built-in; muốn parent điều phối child (scout → worker → reviewer chạy song song) phải cài extension. Mình cài, dựng đủ role, viết cả policy điều phối. Cảm giác lúc đó: đúng bài, chuyên nghiệp, "như có team".
Rồi mọi thứ chậm dần. Chậm tới mức mình phải mở log ra đếm.
Số đo thật
Nguồn: file lịch sử chạy của Pi trên máy mình — 1.111 lượt child trong 4 ngày (3–6/9/2026), thuộc 36 phiên có gọi subagent, tổng 346 lượt yêu cầu của mình.
| p50 | p90 | trung bình | |
|---|---|---|---|
| Một child đơn lẻ | 1,7 phút | 6,4 phút | 3,1 phút |
| Một lượt việc (cả pipeline) | 6,8 phút | 27,6 phút | 13,3 phút |
| Lượt chạy dạng workflow (62% số lượt) | 10,7 phút | 32,5 phút | 18 phút |
| Lượt chỉ dùng 1 thợ | 2,5 phút | 11,5 phút | 5,7 phút |
Đọc bảng này ra được ba điều:
Một — child không hề chậm. 1,7 phút cho một việc con là bình thường. Cảm giác "AI chậm quá" không đến từ đó.
Hai — cái chậm là tổng thời gian chờ của cả lượt. Từ lúc mình gõ xong tới lúc nhận thông báo cuối: trung vị 6,8 phút. Và nếu lượt đó chạy workflow nhiều lane thì lên 10,7 phút, đuôi p90 chạm 32 phút.
Ba — con số then chốt: 6 phút sàn. Một vòng scout (1,3p) + worker (3,3p) + reviewer (1,2p) là 6 phút tối thiểu cho mỗi lần implement, kể cả khi việc đó chỉ là đổi tên một biến.
Mình còn đo phần "cha suy nghĩ trước khi giao việc": chỉ 16 giây. Nút thắt không nằm ở khâu điều phối. Nút thắt là cộng dồn các lane tuần tự — mỗi lane đều phải đọc lại context từ đầu.
Cái làm mình giật mình nhất: reviewer được gọi 366 lần, worker chỉ 321 lần. Tức là gần như mọi việc đều bị review, kể cả những việc chẳng có gì để review. Vì luật mình viết ép loop scout → worker → reviewer cho mọi thứ.
Còn lượt tệ nhất? Một phiên 236 phút — gần 4 tiếng, với 106 lần spawn agent con và 51 lần resume. Nó bắt đầu bằng một câu vô hại: "cứ làm tiếp, tự quyết".
Cách sửa
Mình viết lại policy điều phối theo hướng ngược lại hoàn toàn:
- Mặc định: một thợ, hoặc parent tự làm. Không spawn gì cả.
- Cấm workflow cho các việc kiểu "làm tiếp", đổi tên, tìm-thay-thế.
- Reviewer chỉ khi thật đáng: gửi khách, merge, hoặc động tới tiền.
- Chặn cứng số lần spawn mỗi lượt (mình để 12) — để một câu "tự quyết" không đẻ ra 106 agent.
- Cấm child đẻ cháu (giới hạn độ sâu = 1).
- Hạ mức "suy nghĩ" của worker/reviewer xuống thấp, chỉ giữ model mạnh cho vai trò phản biện.
Bài học rút gọn cho bạn nào mới bắt đầu: đừng bật multi-agent cho tới khi bạn đo được rằng một thợ đang nghẽn thật. Song song chỉ đáng khi các lane thực sự độc lập. Nếu chúng phải chờ nhau, bạn chỉ đang trả tiền cho thời gian chờ.
VPS cho coder & vibe coding
Deploy app, chạy agent dài hoặc giữ môi trường thử nghiệm tách khỏi máy chính
Link affiliate 123HOST: OpenCode Vietnam có thể nhận hoa hồng, giá bạn trả không đổi.
Nhận xét thật về Pi và DSH
Pi
Mạnh khi việc nhiều bước và bạn có luật điều phối rõ. Không có luật thì nó ngốn thời gian như phần trên. Điểm cộng lớn: model routing theo từng vai — vai recon dùng model rẻ, vai phản biện mới dùng model mạnh. Cái này tiết kiệm thật, không phải lý thuyết.
Điểm trừ: phải cài extension mới có subagent, và catalog có cả tá bản fork. Chỉ cài một gói — hai gói cùng đăng ký một tool sẽ đá nhau.
DSH (DeepSeek Harness)
Ra mắt tháng 8/2026, MIT license, và leo lên top star GitHub nhanh khủng khiếp — hơn 200k star chỉ trong khoảng hai tuần.
Kiến trúc thật sự hay: mọi thứ là plugin. Không chỉ tool, mà cả vòng lặp agent, sandbox, storage, lẫn giao diện đều thay được bằng config thay vì fork cả monolith. Nó đọc luôn AGENTS.md/CLAUDE.md, có cầu nối hook cho Claude Code và Codex, làm MCP client. Nghĩa là bê context cũ sang gần như không mất gì — đúng tinh thần phần trên của bài.
Mình chạy nó thật hai tuần giữa tháng 8, trên 4 repo có việc thật. Rồi tạm dừng, vì ba lý do rất cụ thể:
- Vẫn là developer preview. Chính DeepSeek nói thẳng sẽ có thay đổi phá vỡ tương thích. Mình chờ nó ổn định thêm rồi mới đặt việc chạy tiền vào.
- Quản lý session theo từng project chưa tối ưu. Khi bạn nhảy qua lại nhiều repo trong ngày, đây là điểm chạm hàng ngày, khó chịu tích lũy.
- Đang chủ yếu là web UI. Mình chờ bản app hoặc CLI đủ ngon rồi quay lại.
Nói rõ: không phải nó dở. Nó mới, và cái mới thì chưa mượt. Mình vẫn theo dõi.
Lộ trình 1 tuần cho người mới (ví dụ: Astro + headless CMS, ngân sách hạn)
Nếu mình bắt đầu lại từ đầu với stack như bạn kia hỏi:
Ngày 1 — chọn đúng một harness. Ưu tiên open source + multi-provider (OpenCode). Đừng cài ba ông cùng lúc. Bạn chưa có gì để so sánh, và mỗi ông lại tốn thời gian làm quen.
Ngày 2 — cấu hình model theo giá. Model rẻ cho việc lặp lại (đổi text, sinh boilerplate, format), model mạnh chỉ cho việc khó (thiết kế, debug rối). Với ngân sách hạn, đây là đòn bẩy lớn nhất — lớn hơn nhiều so với việc chọn harness nào.
Ngày 3 — viết AGENTS.md cho repo Astro. Cấu trúc thư mục, quy ước đặt tên file content, lệnh build, lệnh deploy, những gì không được sửa tay.
Ngày 4–5 — viết 3–5 skill nhỏ đầu tiên. Đừng viết skill "tổng quát". Viết thứ bạn làm lặp đi lặp lại: tạo bài viết mới đúng schema, deploy lên Cloudflare Pages (free tier quá đủ cho web tĩnh), gọi API headless CMS.
Ngày 6 — cho nó chạy CLI thật. Build, git, deploy. Đo thử: một việc quen mất bao lâu?
Ngày 7 — chỉ tới lúc này mới nghĩ tới nhiều agent. Và chỉ khi bạn chỉ ra được lane nào đang nghẽn.
Kết
Ba câu mình muốn bạn nhớ:
- Harness thay được trong 5 phút, context thì không. Đầu tư vào
AGENTS.mdvà skills — chúng sống sót qua mọi lần đổi tool. - Một nguồn skill duy nhất, các tool khác symlink sang. Copy là bắt đầu của lệch phiên bản.
- Nhiều agent không đồng nghĩa với nhanh hơn. Mình có 1.111 lượt chạy để chứng minh: một lượt workflow trung vị 10,7 phút, trong khi một thợ chỉ 2,5 phút. Đo trước, rồi hãy song song.
Còn chuyện "tuần nào cũng có harness mới"? Cứ thử, vui mà. Nhưng thử với AGENTS.md sẵn trong repo thì bạn mất 5 phút. Thử mà chưa có gì thì mỗi lần là làm lại từ đầu.
Đọc thêm
- Agents vs Skills vs Commands — phân biệt ba khái niệm hay bị lẫn
- Hướng dẫn tạo Custom Agents — khi bạn thật sự cần agent riêng
- OpenCode vs Claude Code — so sánh hai harness phổ biến nhất
Bạn đang chạy harness nào, và đã đo thời gian một lượt việc bao giờ chưa? Chia sẻ trong nhóm OpenCode Vietnam nhé — mình quan tâm số của người khác, nhất là ai đang chạy multi-agent mà thấy nhanh thật.