Parallel vs Sequential Agents: Khi nào dùng gì?

Định nghĩa

Parallel Agents là mô hình nhiều Agent chạy đồng thời trên các tác vụ độc lập, tận dụng tính toán bất đồng bộ để giảm tổng thời gian xử lý. Sequential Agents là mô hình Agent chạy theo pipeline tuần tự, trong đó output của Agent trước trở thành input của Agent sau, tạo chuỗi phụ thuộc chặt chẽ.

Sự khác biệt này không chỉ là "chạy nhanh hay chậm" — nó quyết định kiến trúc tổng thể, chi phí vận hành, và khả năng debug khi hệ thống scale.

Giải thích chi tiết

Parallel Agents: Tốc độ và Khám phá không gian

Khi bạn cần xử lý nhiều tác vụ không phụ thuộc lẫn nhau, Parallel là lựa chọn tự nhiên. Ví dụ trong Claude Code, mô hình Fork cho phép tạo nhiều Worktree độc lập để chỉnh sửa song song các file khác nhau — thay vì chờ sửa xong file A mới sửa file B.

Lợi ích rõ ràng: latency giảm đáng kể. Nếu bạn cần phân tích 10 file log, chạy 10 Agent cùng lúc sẽ nhanh gấp 10 lần so với chạy tuần tự (lý thuyết).

Tuy nhiên, chi phí tính toán tăng tuyến tính. Bạn trả tiền cho tất cả các instance chạy song song. Trong ví dụ nổi tiếng về chi phí "$9 solo vs$200 full harness", phần lớn sự chênh lệch đến từ việc chạy Parallel Agents để đảm bảo độ chính xác — bạn đổi tiền lấy thời gian và coverage.

Sequential Agents: Chất lượng và Phụ thuộc logic

Kiến trúc Planner → Generator → Evaluator của Anthropic là ví dụ điển hình cho Sequential bắt buộc. Bạn không thể để Evaluator kiểm tra code khi Generator chưa sinh ra code. Bạn cũng không thể bắt Generator viết code đúng khi chưa có spec từ Planner.

Mô hình này tạo ra dependency chain: output của bước trước là context bắt buộc của bước sau. Điều này đảm bảo tính nhất quán và cho phép validation tại từng stage.

Trade-off là latency tích lũy. Nếu mỗi Agent mất 5 giây, pipeline 3 bước sẽ mất ít nhất 15 giây (thực tế còn lâu hơn do overhead chuyển context). Nhưng bù lại, bạn có thể dừng sớm nếu Planner tạo ra spec tệ — tiết kiệm chi phí chạy Generator và Evaluator cho tác vụ vô nghĩa.

Hidden cost: Debuggability

Đây là yếu tố ít người nghĩ đến khi thiết kế. Parallel Agents tạo ra race conditions và conflicting states nếu chúng cố gắng ghi vào cùng một resource. Khi có lỗi, bạn khó biết "Agent nào gây ra" vì chúng chạy đồng thời.

Ngược lại, Sequential Agents tạo ra execution trace rõ ràng: log từng bước, biết chính xác Agent nào fail và tại sao. Điều này cực kỳ quan trọng trong production khi bạn cần rollback hoặc hotfix.

Chi phí thực tế và Quyết định kiến trúc

Quy tắc ngón tay cái:

• Dùng Parallel khi các tác vụ độc lập và bạn ưu tiên throughput (xử lý nhiều item cùng lúc)
• Dùng Sequential khi có phụ thuộc dữ liệu và bạn ưu tiên correctness (đảm bảo bước sau kiểm tra bước trước)

Nhưng có ngoại lệ: đôi khi bạn chạy Parallel để "voting" — cho 3 Agent cùng phân tích một vấn đề và dùng kết quả trùng nhau để tăng confidence. Đây là dạng Parallel nhưng lại phục vụ mục đích quality (redundancy), không phải speed.

Ví dụ thực tế

Claude Code và 3 mô hình Subagent

Trong kiến trúc Claude Code, bạn thấy cả hai mô hình:

• Fork (Parallel): Khi cần refactor codebase lớn, Claude tạo nhiều Worktree độc lập để chỉnh sửa song song từng module. Các thay đổi không ảnh hưởng lẫn nhau nên chạy parallel giảm thời gian từ 30 phút xuống 5 phút.
• Teammate (Sequential): Khi debug lỗi phức tạp, Agent chạy theo luồng "Tìm nguyên nhân → Tạo fix → Kiểm thử". Bắt buộc tuần tự vì bạn không thể kiểm thử fix khi chưa biết nguyên nhân lỗi.

Anthropic v1 vs v2

So sánh hai phiên bản kiến trúc:

• v1 (Initializer + Coding): Có thể song song hóa một số bước khởi tạo (tìm file liên quan, đọc config) trước khi vào coding chính.
• v2 (Planner + Generator + Evaluator): Bắt buộc sequential. Planner xong mới đến Generator, Generator xong Evaluator mới kiểm định. Không có cách nào rút ngắn pipeline này mà không mất chất lượng.

Code Review tự động

Trong hệ thống review tự động:

• Parallel: Chạy đồng thời 3 Agent chuyên biệt — Security Agent (tìm lỗ hổng), Style Agent (check format), Logic Agent (tìm bug logic). Ba Agent này độc lập nên chạy song song cho nhanh.
• Sequential: Chạy tuần tự "Lint → Test → Review". Bạn không muốn chạy Test nếu Lint đã fail (code chưa đúng syntax), và không muốn Review logic nếu Test chưa pass.

Ứng dụng

Sinh viên và Researcher

Dùng Parallel cho việc nghiên cứu tài liệu: cho 3-4 Agent tìm kiếm đồng thời trên các nguồn khác nhau (arXiv, Wikipedia, GitHub) về cùng một chủ đề, sau đó tổng hợp kết quả. Tiết kiệm thời gian chờ đợi khi viết luận văn.

Developer và Tech Lead

Dùng Sequential cho workflow coding nghiêm ngặt: Plan → Implement → Test → Refactor. Đặc biệt với AI code generation, bạn không muốn AI refactor code chưa qua test — sẽ tạo ra "đống lộn xộn" khó debug.

Doanh nghiệp và Production System

Dùng Hybrid Architecture: Parallel cho extraction phase (đọc nghìn document cùng lúc), Sequential cho approval phase (Extract → Validate → Approve → Archive). Điều này tối ưu cả chi phí (không chạy validation trên data chưa extract xong) và thời gian (extract song song cho nhanh).

So sánh

Kết luận: Parallel và Sequential không phải đối thủ — chúng là công cụ cho hai loại bài toán khác nhau. Điểm mấu chốt là nhận ra dependency trong luồng công việc của bạn. Nếu không có dependency dữ liệu, chạy Parallel để tiết kiệm thời gian. Nếu có dependency, ép buộc Sequential để tránh lỗi logic lan truyền.

Bài viết liên quan

Cùng cụm

Tại sao cần Multi-Agent?

Khi nào single agent không đủ và tại sao separation of concerns lại quan trọng trong kiến trúc AI

Kiến trúc 3-Agent của Anthropic

Phân tích chi tiết luồng Planner → Generator → Evaluator — ví dụ điển hình cho Sequential bắt buộc

3 mô hình Subagent

Fork, Teammate, Worktree — ba cách tổ chức subagent trong Claude Code và khi nào dùng mô hình nào

Đọc tiếp

Nền tảng Harness Engineering

Quay lại nền tảng để hiểu rõ hơn về ACI (Agent-Computer Interface) và cách thiết kế environment cho Agent

State và Session Management

Khi chạy Parallel hay Sequential, state được quản lý thế nào? Persistence và consistency trong multi-agent systems

Security và Guardrails

Chạy nhiều Agent song song tạo ra attack surface mới — cách thiết lập guardrails và kiểm soát permission khi architecture phức tạp hóa