LangGraph hay CrewAI: kiểm soát trạng thái đổi lấy tốc độ dựng agent

Chọn LangGraph khi quy trình nhiều bước cần trạng thái tường minh, nhánh xử lý rõ và điểm dừng để con người phê duyệt. Tài liệu LangGraph mô tả một đồ thị có thể kết hợp bước do mã quyết định với bước do mô hình quyết định, đồng thời lưu trạng thái để tiếp tục sau gián đoạn. Mức kiểm soát đó đòi hỏi nhóm phát triển tự định nghĩa state, node và đường chuyển giữa chúng.

Chọn CrewAI khi công việc chia được theo vai trò và nhóm muốn dựng nhanh luồng cộng tác giữa các agent. Trong kiến trúc CrewAI, Crew giao việc cho các agent, còn Flow quản lý trạng thái, thứ tự và điều kiện thực thi. Khi ứng dụng cần kiểm soát chặt, đối tượng nên đặt cạnh LangGraph là Flow có thể gọi Crew, chứ không chỉ một Crew chạy các nhiệm vụ tuần tự.

Cùng một yêu cầu hỗ trợ khách hàng được tổ chức ra sao?

Giả sử khách hàng yêu cầu hoàn tiền. Hệ thống cần nhận yêu cầu, tra cứu giao dịch, kiểm tra điều kiện, soạn phương án, chờ nhân viên duyệt rồi gửi phản hồi. Đây là tình huống giả định để đối chiếu kiến trúc; chính sách hoàn tiền và dữ liệu giao dịch thuộc về ứng dụng cụ thể.

Với LangGraph, nhóm có thể đặt mã yêu cầu, kết quả tra cứu, kết luận về điều kiện hoàn tiền và quyết định phê duyệt vào state. Mỗi thao tác trở thành một node. Kết quả kiểm tra đưa hồ sơ đủ điều kiện sang bước soạn phản hồi, còn hồ sơ thiếu dữ liệu sang nhánh bổ sung thông tin. Cách dựng này làm lộ rõ dữ liệu nào phải có trước khi chuyển bước và bước nào có quyền thay đổi quyết định.

Với CrewAI, Flow có thể giữ mã yêu cầu, gọi công cụ tra cứu và rẽ nhánh theo kết quả. Một bước trong Flow có thể giao cho Crew gồm agent phân tích chính sách và agent soạn câu trả lời. Nếu bước kiểm tra điều kiện chỉ cần một quy tắc nghiệp vụ, Flow có thể xử lý trực tiếp; việc thêm agent chỉ hợp lý khi phần việc cần suy luận hoặc cộng tác. Nhờ đó, ranh giới giữa quyết định của ứng dụng và đề xuất của mô hình vẫn rõ ràng.

Trạng thái và quyền phê duyệt nằm ở đâu?

Giá trị của state tường minh xuất hiện khi một yêu cầu phải chờ nhân viên duyệt hoặc khi cần giải thích vì sao hệ thống đi vào một nhánh. Ở LangGraph, nhóm xác định dữ liệu đầu vào, phần cập nhật và điều kiện chuyển tiếp cho từng node. Người duyệt có thể được đặt tại một điểm dừng trước thao tác gửi phản hồi, nơi phương án đã soạn và quyết định cuối cùng có thể được phân biệt trong state.

CrewAI cũng quản lý state thông qua Flow. Trong ví dụ hoàn tiền, Flow có thể giữ kết quả xác minh và trạng thái phê duyệt, còn Crew tạo phương án trả lời từ những dữ liệu được giao. Vì thế, khác biệt không phải một bên có trạng thái còn bên kia không có. Khác biệt là LangGraph đặt đồ thị trạng thái ở trung tâm thiết kế, trong khi CrewAI cho phép bắt đầu từ vai trò và nhiệm vụ rồi dùng Flow để kiểm soát quy trình bao quanh.

Cách chia việc này ảnh hưởng đến công sức phát triển. Một quy trình nhiều ngoại lệ sẽ buộc nhóm viết rõ các nhánh, dữ liệu thiếu và quyền sửa state trong LangGraph. Một Crew đơn giản thường dễ mô tả hơn lúc đầu, nhưng các quy tắc phê duyệt và chuyển bước vẫn phải được định nghĩa khi luồng đi vào vận hành. Tốc độ dựng phiên bản đầu vì vậy không đồng nghĩa với việc có thể bỏ qua thiết kế nghiệp vụ.

Khi một bước lỗi, hệ thống tiếp tục từ đâu?

Khả năng phục hồi phụ thuộc vào ranh giới lưu tiến độ và nơi lưu. Cơ chế persistence của LangGraph phân biệt checkpointer lưu state theo từng luồng chạy với store lưu dữ liệu dùng qua nhiều luồng. Checkpoint trong bộ nhớ sẽ mất khi tiến trình khởi động lại. Với yêu cầu hỗ trợ phải chờ phê duyệt, nhóm cần một nơi lưu bền vững và định danh ổn định để tìm lại đúng lần chạy.

CrewAI cũng có cơ chế checkpoint cho Crew, Flow và agent: khi được bật, nó lưu tiến độ để tiếp tục và bỏ qua nhiệm vụ đã hoàn tất. Sự kiện ghi mặc định là lúc một nhiệm vụ hoàn thành; nhóm có thể chọn sự kiện khác để lưu thường xuyên hơn. Điều này làm thay đổi câu hỏi vận hành từ “có tiếp tục được không” sang “mất bao nhiêu việc nếu lỗi xảy ra giữa hai lần lưu”.

Trong tình huống giả định, nếu lỗi xảy ra sau khi đã gửi phản hồi nhưng trước khi ghi nhận hoàn tất, chạy lại có thể tạo phản hồi trùng. Framework lưu tiến độ không tự quyết định liệu thao tác bên ngoài đã thành công. Ứng dụng cần gắn thao tác gửi với mã yêu cầu và kiểm tra kết quả trước khi thử lại. Ranh giới node hoặc nhiệm vụ càng rộng, phần việc phải lặp lại sau lỗi càng lớn; lưu dày hơn lại làm tăng lượng trạng thái cần ghi và quản lý.

Benchmark cho biết gì về độ trễ, token và công sức dựng?

Trong benchmark 80 tác vụ dùng GPT-4o, cấu hình LangGraph đạt trung bình 38,2 giây và 14,3 nghìn token mỗi tác vụ, còn cấu hình CrewAI đạt 42,7 giây và 17,8 nghìn token; nghiên cứu dùng các phiên bản được ghi là LangGraph 0.2.x và CrewAI 0.80.x. Hội đồng kỹ sư chấm trải nghiệm phát triển của CrewAI 4,4/5 so với 3,6/5 cho LangGraph. Trong các lỗi mô phỏng, tỷ lệ phục hồi trung bình được báo cáo lần lượt là 74,0% và 83,3%.

Các kết quả đo cấu hình được thử, không đo mọi cách triển khai hai framework. Bộ tác vụ gồm lập trình, tóm tắt nghiên cứu, phân tích dữ liệu và hỏi đáp nhiều bước; nó không tái hiện đầy đủ một yêu cầu hỗ trợ chờ phê duyệt trong thời gian dài. Đặc biệt, kết quả phục hồi của cấu hình CrewAI trong thử nghiệm không thể dùng để kết luận rằng các phiên bản có checkpoint hiện nay thiếu khả năng tiếp tục sau lỗi.

Độ trễ và token cũng chịu tác động của số lượt gọi mô hình, lượng ngữ cảnh truyền giữa agent và phần việc phải chạy lại. Nếu tác vụ chỉ cần tra cứu rồi trả lời, thêm vai trò có thể tạo thêm lượt trao đổi. Nếu nhiều bước phải được kiểm tra riêng và giữ kết quả qua gián đoạn, công sức viết luồng tường minh có thể đổi lấy khả năng xác định chính xác phần nào đã hoàn tất. Chênh lệch trong benchmark là dữ liệu tham khảo cho lựa chọn kiến trúc, không phải mức tiết kiệm cố định cho mọi workload.

Chọn theo phần việc khó nhất của quy trình

Nếu khó nhất là kiểm soát đường đi sau khi nhân viên bác một phương án, sửa state tại một điểm và tiếp tục từ ranh giới đã biết, LangGraph đưa các quyết định đó vào cấu trúc chính của ứng dụng. Nếu khó nhất là phân công agent chuyên trách để nhanh chóng xây một luồng cộng tác, CrewAI cho điểm khởi đầu gần với cách chia nhiệm vụ; Flow cần đảm nhận quy tắc nghiệp vụ và điểm phê duyệt khi hệ thống mở rộng.

Với yêu cầu hoàn tiền giả định, câu hỏi quyết định là điều kiện hoàn tiền được kiểm tra ở đâu, ai có quyền duyệt, kết quả nào được lưu và thao tác nào có thể lặp lại sau lỗi. Khi những ranh giới đó đã rõ, nhóm có thể chọn mức kiểm soát của LangGraph hoặc cách kết hợp Flow với Crew của CrewAI theo quy trình thực tế, thay vì chọn chỉ dựa vào số agent hay một thứ hạng benchmark.

Đọc thêm:

• PostgreSQL hay MySQL: workload quyết định, không phải một bảng benchmark
• AIR gọi 50 triệu USD để dựng “tường lửa” cho kỹ năng AI agent
• AIR gọi 50 triệu USD: “tường lửa” mới chặn công cụ độc cho AI agent