Tôi vừa làm 4 bài về background agent: định nghĩa, kiến trúc Claude Code BG, deep dive Cursor BG, 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 còn lại của bài.
BG vs sync recap
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 (background) là 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 một 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 ở 2 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ỗ đó.
5 trục so sánh
Tôi chia tradeoff thành 5 trục, mỗi trục là một câu hỏi cụ thể bạn nên hỏi trước khi pick một agent type.
Trục 1: cost
Sync agent tính tiền theo token hoặc theo 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, hết task là hết tiền.
BG agent tính tiền theo compute time hoặc theo “agent compute unit”. Cursor Background Agent 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: BG tự chạy hàng giờ, bạn không nhìn, nên dễ vượt budget. Tôi từng để Devin chạy qua đêm một 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 2: latency
Sync agent có 2 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 agent có 1 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: nếu bạn cần biết kết quả trong 30 giây, sync. Nếu bạn cần kết quả trong 2 tiếng nhưng trong lúc đó muốn làm việc khác, 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 3: observability
Sync agent có observability mặc định 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 agent yêu cầu observability layer riêng. Theo Braintrust và Laminar (2026 observability survey), 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>/. Đều thua kinh nghiệm “ngồi nhìn” của sync.
Tradeoff: nếu task cần debug nhiều, sync thắng. Nếu task đơn giản đủ để trust agent một lần, BG ổn.
Trục 4: failure mode
Sync agent 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: 30 giây + một câu prompt sửa lại.
BG agent fail kín. Agent có thể chạy 1 tiếng trong loop sai, đến cuối ra PR với code bị broken hoặc không phải cái bạn muốn. Cost của failure: 1 tiếng compute + cost review PR + 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: nếu task chưa rõ requirement, sync để bạn refine khi đi. Nếu requirement đã rõ và test có sẵn, BG vì failure visible qua test fail là OK.
Trục 5: control
Sync agent bạn cầm vô-lăng. Agent đề xuất, bạn approve hoặc reject mỗi bước. Mức control: cao nhất.
BG agent agent cầm vô-lăng. Bạn launch và đợi. Bạn có thể can thiệp khi nhìn status panel, nhưng default là không. Mức control: thấp nhất.
Tradeoff: nếu task chạm code nhạy cảm (auth, payment, schema migration), sync. Nếu task là refactor mechanical, generate test, update doc, BG ổn vì failure recover được.
Use case nên BG
Theo kinh nghiệm tôi và pattern phổ biến 2026, BG fit với 4 loại task:
Long refactor: 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: 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: update README, docstring, type hint sau khi refactor API. Không cần phán đoán nhiều, chỉ cần consistent format.
Deploy / CI fix: 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.
Use case nên sync
Sync fit với 4 loại khác:
Debug live: bạn đang chạy app, 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: bạn chưa biết architecture cuối ra sao, đang prototype. Mỗi bước thay đổi design. Sync để bạn tweak mỗi vòng.
Learning code mới: 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: 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: sync explore + BG execute
Đây là pattern tôi thấy phổ biến nhất ở team đang ship thật trong 2026. Theo Kilo và Microsoft Azure Architecture blog, default agentic workflow 2026 là hybrid: plan trong IDE, agent execute local sandbox, gate bằng CI + PR review trước khi merge.
Flow chi tiết:
- 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 + 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: ~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 + risk drift cao).
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 + test, spawn BG agent cho từng sub-task, review PR khi BG xong. Đây là multi-agent pattern, tôi sẽ viết riêng một bài khi có dịp.
Decision framework
Bảng này dán vào wiki team được:
| 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.
Cost-aware checklist trước khi launch BG
Để tránh tình huống đốt 7 ACU qua đêm như tôi:
- Plan file có đủ context không? Nếu agent đoán quá nhiều, dễ drift.
- Test có chạy được không? Nếu test fail từ đầu, agent loop lặp lại không recover được.
- Scope file đã giới hạn chưa? Đừng cho BG agent quyền chạm
package.json,wrangler.toml, hoặc CI config nếu task không cần. - Timeout/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.
5 câu này tôi hỏi mỗi lần launch BG, đặc biệt cho task lớn hơn 30 phút.
Khi nào series này lỗi thờ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.
Trong 12 tháng tới tôi đoán BG vs sync sẽ không còn là phân loại có ý nghĩa. Mọi agent sẽ có cả 2 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ẽ phải 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. Còn 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
5 bài đi qua:
- Anatomy of async coding agent: định nghĩa, kiến trúc chung
- Claude Code BG mode + FleetView: hands-on Claude Code BG
- Cursor Background Agent deep dive: kiến trúc Cursor BG
- Devin vs OpenDevin vs Replit: so sánh 3 platform
- Bài này: decision framework
Pick agent type theo task, không theo hype. Hybrid là default mới của 2026.