
Giải pháp duy trì sự nhất quán về ngữ cảnh và quyết định khi chạy song song nhiều AI Agent
Khi triển khai nhiều AI Agent chạy song song, vấn đề lớn nhất không phải là hiệu suất mà là sự phân mảnh ngữ cảnh. Bài viết này phân tích nguyên nhân gây ra sự 'trôi dạt' (drift) trong quyết định giữa các Agent và đề xuất các chiến lược quản lý để duy trì sự đồng bộ trong quy trình làm việc.
Bài viết được dịch và tổng hợp từ tin tức gốc. Bạn có thể đọc bài viết gốc bằng tiếng Anh tại đây.
Điểm tin nhanh:
- Việc chạy song song nhiều AI Agent (như Claude Code) dễ dẫn đến tình trạng "trôi dạt" ngữ cảnh, nơi các Agent đưa ra quyết định mâu thuẫn nhau.
- Nguyên nhân cốt lõi là do mỗi Agent hoạt động trong một session biệt lập, thiếu bộ nhớ dùng chung để lưu trữ các quyết định kiến trúc và thay đổi giao diện.
- Chiến lược hiệu quả nhất bao gồm việc thiết lập tài liệu hướng dẫn (CLAUDE.md), lập kế hoạch tổng thể trước khi phân tách công việc và sử dụng các công cụ quản lý tác vụ chung.

Bạn bắt đầu ngày mới với bốn Agent Claude Code đang chạy, mỗi Agent nằm trong một git worktree riêng biệt và xử lý một tác vụ khác nhau. Đến giữa buổi chiều, mọi thứ bắt đầu trở nên hỗn loạn. Một Agent thực hiện lại một hàm hỗ trợ mà Agent khác đã viết xong. Một Agent thứ hai xây dựng dựa trên một interface đã bị thay đổi bởi Agent thứ ba từ một giờ trước. Một Agent thứ tư đưa ra lựa chọn đặt tên mâu thuẫn với quyết định bạn đã đưa ra vào lúc 9 giờ sáng. Mỗi thay đổi (diff) đều có vẻ hợp lý khi đứng riêng lẻ, nhưng hệ thống tổng thể thì không.
Đây là "chế độ lỗi" xuất hiện ngay khi bạn chuyển từ việc sử dụng một Agent sang nhiều Agent cùng lúc. Vấn đề không nằm ở mã nguồn mà ở sự trôi dạt (drift) về mặt quyết định, quy ước và cấu trúc interface giữa các luồng công việc.
Tại sao các Agent song song lại bị "trôi dạt"?
Ngữ cảnh của một Agent là theo từng phiên (per-session). Mỗi instance của Claude Code có cửa sổ ngữ cảnh riêng, được nạp bởi những gì nó đã đọc và thực hiện trong phiên đó. Không có bộ nhớ chung nào mà tất cả các Agent cùng đọc và ghi vào. Khi Agent A quyết định "chúng ta sử dụng repository pattern để truy cập dữ liệu", quyết định đó chỉ tồn tại trong ngữ cảnh của Agent A và trong đầu bạn. Agent B hoàn toàn không biết về điều này.
Chúng ta có thể phân loại các trạng thái gây ra sự trôi dạt như sau:
| Loại trạng thái | Đặc điểm | Nhu cầu xử lý |
|---|---|---|
| Quyết định đã chốt | Kiến trúc, quy ước đặt tên, cách tiếp cận vấn đề. | Cần ràng buộc mọi Agent (kể cả Agent mới). |
| Hợp đồng hiện tại | Interface, kiểu dữ liệu (types), API dùng chung. | Cần cập nhật thời gian thực để tránh lỗi build. |
| Tác vụ đang thực hiện | Ai đang sửa file nào, module nào đang bị thay đổi. | Cần hiển thị trực quan để tránh xung đột merge. |
Nút thắt cổ chai không phải là cửa sổ ngữ cảnh, mà là chính bạn
Bản năng của chúng ta là đóng vai trò "bộ nhớ dùng chung" – giữ các quyết định trong đầu và truyền đạt lại cho từng Agent. Cách này hiệu quả với 2 Agent, nhưng sẽ sụp đổ khi lên tới 4 hoặc 5. Bạn sẽ trở thành lớp tích hợp (integration layer) duy nhất, nơi mọi luồng song song phải hội tụ. Điều này làm tăng tải trọng nhận thức (cognitive load) của bạn lên gấp nhiều lần so với hiệu suất đạt được.
Câu hỏi thực sự không phải là "làm sao để chạy nhiều Agent hơn", mà là "làm thế nào để các quyết định được đưa ra một lần và ràng buộc mọi Agent mà không cần thông qua tôi mỗi lần".
Các phương pháp quản lý hiện nay
Hiện tại, cộng đồng đang áp dụng một số chiến lược với các ưu nhược điểm khác nhau:
- Tệp ngữ cảnh (CLAUDE.md và tương tự): Đưa các quy ước và quyết định vào một file mà mọi Agent đều đọc khi khởi động. Đây là nền tảng cơ bản cần có, nhưng nó là tĩnh và dễ bị lỗi thời khi công việc tiến triển.
- Bản tóm tắt (Copy-paste briefs): Cung cấp cho mỗi Agent một bản hướng dẫn riêng biệt khi khởi tạo. Cách này linh hoạt nhưng khiến bạn quay lại làm nút thắt cổ chai.
- Hàng đợi tác vụ chung (Shared task queue): Sử dụng các công cụ như Beads hoặc bảng Kanban để quản lý các worktree. Cách này giúp kiểm soát "những gì đang thực hiện" rất tốt.
- Lập kế hoạch trước khi phân tách (Plan first, then fan out): Dành một giờ để giải quyết thiết kế và interface trước khi cho bất kỳ Agent nào bắt đầu. Đây là thói quen có đòn bẩy cao nhất, vì nó ngăn chặn sự trôi dạt ngay từ đầu.
Kết luận: Quyết định bền vững cần một "ngôi nhà chung" mà mọi Agent đều có thể đọc và ghi vào, đồng thời các interface phải được chốt trước khi chia nhỏ công việc. Công cụ hỗ trợ chỉ thực sự hữu ích khi nó ép buộc được các quy tắc này thay vì phó mặc vào trí nhớ của bạn.
Do you like this post?
Upvote to push this post higher on the community feed
