Quan điểm thẳng trước khi vào: tôi nghĩ debate “BG vs sync” sẽ outdate trong vòng 12 tháng. Mọi agent đang converge về cùng một thứ, switch tự động giữa hai mode dựa trên task. Nhưng ngay bây giờ, tháng 5 năm 2026, vẫn cần quyết định cho từng task cụ thể, và pattern thực tế nhất tôi thấy ở mọi team đang ship thật là hybrid: sync để explore và plan, BG để execute mechanical work.
Bốn bài trước của series đã đi qua định nghĩa, kiến trúc Claude Code BG, deep dive Cursor BG, và so sánh Devin/OpenDevin/Replit. Bài này khép series bằng câu hỏi gốc mà mọi người hay hỏi tôi: “Khi nào dùng BG, khi nào dùng sync, khi nào pha trộn cả hai?”. Trả lời ngắn: phụ thuộc vào task. Trả lời dài là phần dưới.
Recap nhanh hai loại
Sync agent là cách dùng AI coding truyền thống. Bạn gõ prompt trong IDE hoặc CLI, agent chạy, bạn nhìn từng tool call, từng diff, có thể can thiệp giữa chừng. Claude Code interactive, Cursor Chat, Aider, Copilot inline. Bạn ngồi đó từ đầu đến cuối.
BG agent chạy trong sandbox riêng, thường là VM hoặc worktree riêng. Bạn launch task, agent tự chạy hàng phút hoặc hàng giờ, output là một PR hoặc patch. Claude Code BG mode, Cursor Background Agent, Devin, OpenDevin, Replit Agent đều thuộc loại này.
Khác biệt cốt lõi nằm ở hai thứ: ai cầm cursor và ai cầm thời gian. Sync, bạn cầm cả hai. BG, agent cầm cả hai. Mọi tradeoff khác đi ra từ chỗ đó.
Năm trục so sánh
Trục đầu là cost. Sync agent tính tiền theo token hoặc seat: Claude Code Pro $20/tháng, Cursor Pro $20/tháng, GitHub Copilot $10/tháng. Cost mỗi task nhỏ và predictable, bạn ngồi xem và hết task là hết tiền. BG agent tính theo compute time hoặc “agent compute unit”: Cursor BG metered riêng trên hệ thống credit ngoài Pro plan, Devin $500/tháng Team tier với pool ACU shared, một task phức tạp đốt 5-10 ACU. Devin trung bình ra $2.40 mỗi 1000 dòng code, đắt hơn Copilot và Windsurf 12-20 lần. Tradeoff thực tế: BG tự chạy hàng giờ và bạn không nhìn, nên dễ vượt budget. Tôi đã có lần để Devin chạy qua đêm task tưởng nhanh, sáng dậy thấy đốt 7 ACU vì agent loop lặp lại không tìm ra root cause. Sync agent không có vấn đề này vì bạn thấy nó đi sai là ngắt ngay.
Trục thứ hai là latency. Sync có hai latency: latency mỗi tool call (vài giây) và latency tổng task (bạn quyết định khi nào dừng). Bạn cảm thấy nhanh vì progress visible. BG chỉ có một latency: từ launch đến khi PR xuất hiện, có thể 5 phút có thể 2 tiếng. Replit Agent 3 quảng cáo 200 phút autonomous trong một task. Trong khoảng thời gian đó bạn không biết gì đang xảy ra trừ khi mở status panel. Tradeoff: cần kết quả trong 30 giây thì sync; cần kết quả trong 2 tiếng và muốn làm việc khác thì BG. Latency tổng của BG thường dài hơn sync với cùng task vì agent đi explore nhiều hơn (không có human can thiệp để cắt ngắn).
Trục thứ ba là observability. Sync có observability miễn phí: bạn ngồi xem. Mọi tool call hiện ra terminal hoặc IDE, mọi diff hiện trước mắt. BG cần observability layer riêng. Theo Braintrust và Laminar (observability survey 2026), traditional APM dashboard không show được agent picked wrong tool, drifted from plan, hay retrieved stale memory; cần typed trace schema với tool-call span, reasoning span, state span, memory span để debug. Cursor BG có status panel cơ bản, Devin có session replay, Claude Code BG ghi log vào ~/.claude/projects/<slug>/. Tất cả thua kinh nghiệm “ngồi nhìn” của sync. Tradeoff: task cần debug nhiều thì sync thắng; task đơn giản đủ để trust agent một lần thì BG ổn.
Trục thứ tư là failure mode. Sync fail thấy ngay: tool call sai schema, agent loop hang, code không compile, bạn thấy trong 30 giây và ngắt. Cost của failure là 30 giây cộng một câu prompt sửa lại. BG fail kín. Agent có thể chạy 1 tiếng trong loop sai, đến cuối ra PR với code broken hoặc không phải cái bạn muốn. Cost của failure là 1 tiếng compute cộng cost review PR cộng cost retry. Theo paper “Debugging the Debuggers” (arxiv 2605.08717), non-determinism của LLM agent vẫn tồn tại ngay cả khi temperature=0, nên cùng prompt có thể ra kết quả khác nhau. Tradeoff: requirement chưa rõ thì sync để bạn refine khi đi; requirement đã rõ và test có sẵn thì BG vì failure visible qua test fail là OK.
Trục thứ năm là control. Sync, bạn cầm vô-lăng, agent đề xuất và bạn approve hoặc reject mỗi bước, mức control cao nhất. BG, agent cầm vô-lăng, bạn launch và đợi, can thiệp được khi nhìn status panel nhưng default là không, mức control thấp nhất. Tradeoff: task chạm code nhạy cảm (auth, payment, schema migration) thì sync; task refactor mechanical, generate test, update doc thì BG ổn vì failure recover được.
Khi nào BG là đáp án đúng
Pattern phổ biến 2026 cho thấy BG fit với bốn loại task. Long refactor như rename API ngang qua 30 file, đổi naming convention toàn project, migrate framework version: mechanical, repeatable, test cover được; sync làm cũng được nhưng phí thời gian bạn ngồi xem. Batch test generation kiểu viết unit test cho 20 module, mỗi module 5-10 phút, tổng 2-3 tiếng: BG launch một lần, sáng dậy review batch PR. Documentation update sau khi refactor API (update README, docstring, type hint): không cần phán đoán nhiều, chỉ cần consistent format. Deploy hoặc CI fix kiểu agent thử fix CI fail (lint, format, type error), tự push tự retry: failure mode nhẹ vì CI là gate.
Pattern chung: task có ground truth rõ (test pass, lint clean, schema match), agent loop tự đánh giá được kết quả, human chỉ review cuối.
Khi nào sync mới đúng
Bốn loại khác sync thắng rõ. Debug live khi bạn đang chạy app và thấy bug, cần fix gấp, cần thấy log thấy state thử hypothesis; BG không help được vì agent không thấy môi trường runtime của bạn. Exploratory coding khi bạn chưa biết architecture cuối ra sao và đang prototype, mỗi bước thay đổi design; sync để bạn tweak mỗi vòng. Learning code mới khi bạn đang đọc một codebase mới và muốn agent giải thích; sync vì conversation là phần chính, không phải output. Touch sensitive code kiểu auth, billing, schema migration, deploy script; cost của failure cao, BG không đủ control.
Pattern chung: task không có ground truth rõ, hoặc cost của failure quá cao để giao agent một mình.
Hybrid pattern, default 2026
Đây là pattern tôi thấy ở mọi team đang ship thật. Theo Kilo và Microsoft Azure Architecture blog, default agentic workflow 2026 là hybrid: plan trong IDE, agent execute local sandbox, gate bằng CI plus PR review trước khi merge.
Flow cụ thể như sau. Sync phase 15-30 phút: bạn dùng Claude Code interactive hoặc Cursor Chat để explore problem, đọc code, viết test stub, draft API signature. Mục tiêu phase này là ra một plan file (markdown), không phải code. Handoff: lưu plan file vào repo hoặc paste vào BG launch prompt. Plan càng chi tiết, BG càng ít drift. BG phase 1-3 tiếng: launch BG agent với plan và scope file, agent execute, viết code, chạy test, fix CI; bạn làm task khác. Review phase 15-30 phút: BG ra PR, bạn review diff, chạy test local, merge hoặc bounce lại BG sửa.
Total time khoảng 2-4 tiếng cho task lớn, trong đó bạn chỉ ngồi 30-60 phút. So với pure sync (4-6 tiếng ngồi liên tục) hoặc pure BG (3-5 tiếng đợi plus risk drift cao), hybrid là sweet spot.
Một số team đẩy xa hơn: sync agent ở mức “tech lead”, BG agent ở mức “junior dev”. Sync agent đọc requirement, viết plan và test, spawn BG agent cho từng sub-task, review PR khi BG xong. Đây là multi-agent pattern, một bài riêng đáng viết khi có dịp.
Decision framework, dán vào wiki
| Câu hỏi | Trả lời “có” | Trả lời “không” |
|---|---|---|
| Task có test cover rõ? | BG candidate | Sync |
| Task chạm code nhạy cảm (auth, billing, schema)? | Sync | BG candidate |
| Bạn đã làm task tương tự trước? | BG OK | Sync để học |
| Task lớn hơn 1 tiếng? | BG candidate | Sync nhanh hơn |
| Bạn cần multi-task khi nó chạy? | BG | Sync OK |
| Failure cost cao (production, customer-facing)? | Sync hoặc hybrid | BG OK |
| Requirement đã chốt rõ? | BG candidate | Sync để refine |
| Bạn cần review từng bước? | Sync | BG (review cuối) |
Đếm số “BG candidate” vs số “Sync”. Đa số “BG candidate” thì pick BG. Đa số “Sync” thì pick sync. Tie thì pick hybrid: sync 30 phút plan, BG execute.
Checklist trước khi launch BG
Tôi hỏi năm câu này mỗi lần launch BG, đặc biệt cho task lớn hơn 30 phút, để tránh tình huống đốt 7 ACU qua đêm như tôi: plan file có đủ context không (agent đoán quá nhiều dễ drift); test có chạy được không (test fail từ đầu agent loop lặp lại không recover); scope file đã giới hạn chưa (đừng cho BG quyền chạm package.json, wrangler.toml, hoặc CI config nếu task không cần); timeout và budget cap set chưa (Cursor có credit cap, Devin có ACU cap, Claude Code BG có thể cap qua --max-turns); có gate manual không (PR review luôn, đừng auto-merge BG output).
Một dự đoán về 12 tháng tới
Architecture của agent type đang converge. Theo Dave Patten (Medium “State of AI Coding Agents 2026”) và Kilo blog, Claude Code, Codex, Copilot, Gemini, Cursor, Devin, Windsurf bắt đầu trông giống nhau dưới hood: execution loop, tool layer, sandbox, PR output. Khác biệt UI và pricing nhiều hơn khác biệt kiến trúc.
Tôi đoán BG vs sync sẽ không còn là phân loại có ý nghĩa trong 12 tháng tới. Mọi agent sẽ có cả hai mode, switch qua lại tự động dựa trên task. Khi đó decision framework ở bài này không còn cần thiết, framework mới sẽ hỏi: “task này cần human-in-the-loop bao nhiêu phần trăm” thay vì “BG hay sync”. Đến lúc đó tôi viết lại series. Bây giờ, hybrid là default tốt nhất, sync cho debug, BG cho mechanical task.
Tổng kết series Background Agents 2026
Năm bài đi qua: bài 1 anatomy của async coding cho định nghĩa và kiến trúc chung, bài 2 Claude Code BG mode plus FleetView hands-on Claude Code BG, bài 3 Cursor Background Agent deep dive kiến trúc Cursor BG, bài 4 Devin vs OpenDevin vs Replit so sánh ba platform, và bài này framework chọn.
Pick agent type theo task, không theo hype. Hybrid là default mới của 2026, và bạn không sai khi bắt đầu từ đó.