Graph engineering là gì? Cách thiết kế workflow AI agent chạy song song

Graph engineering là kỹ năng vẽ một quy trình làm việc của AI thành sơ đồ gồm các nút (mỗi nút là một việc) và các mũi tên (việc nào phải chờ việc nào), để những việc không phụ thuộc nhau chạy cùng lúc. Thay vì xếp các bước thành một hàng dài, bạn tách chúng thành nhiều nhánh song song rồi gộp kết quả lại. Quy trình chạy nhanh hơn, ít điểm hỏng hơn, và có chỗ đặt bước kiểm tra độc lập cho từng kết quả.

Mô hình "hình thoi" trong graph engineering: tách việc, chạy song song, kiểm tra bằng một AI khác, gộp lại. Sơ đồ: OPCAIOS.

Bài viết dựa trên ý tưởng trong bài "Graph Engineering explained: what it is, when to use it and when not to" của Anatoli Kopadze (@AnatoliKopadze) trên X (24/7/2026). OPCAIOS viết lại bằng cách trình bày riêng, bổ sung ví dụ Việt Nam và kinh nghiệm thực tế. Số liệu về tốc độ và chi phí do tác giả gốc đưa ra, OPCAIOS chưa kiểm chứng độc lập.

Graph engineering là gì?

Graph engineering là việc thiết kế quy trình AI dưới dạng đồ thị: một kế hoạch được vẽ ra để nhìn thấy hai điều, những việc nào cần làm và việc nào phải chờ việc nào. Khái niệm chỉ có hai phần.

• Nút (node): một việc duy nhất do một AI agent làm, có một thứ đi vào và một thứ đi ra. Ví dụ: nghiên cứu giá của một đối thủ, viết một bản nháp, kiểm tra một nhận định.
• Cạnh (edge): mũi tên nối hai nút, nghĩa là việc sau cần kết quả của việc trước nên phải chờ. Mũi tên chỉ có nghĩa khi có dữ liệu thật chạy qua.

Để một nút dùng được trong đồ thị, nút cần một "hợp đồng": một việc có giới hạn rõ, đầu vào xác định và đầu ra có khuôn cố định. Một nút trả về đoạn văn tự do chỉ người đọc được; một nút trả về khuôn cố định, ví dụ giá, gói, nguồn, ngày, thì nút kế tiếp đọc thẳng được mà không cần đoán. Ý tưởng không mới: các hệ thống điều phối công việc đã dùng sơ đồ phụ thuộc nhiều thập kỷ, và điều mới chỉ là áp dụng cho các AI agent.

Cạnh giả là gì và làm sao tìm ra?

Cạnh giả là mũi tên trong quy trình nhưng không có dữ liệu nào đi qua, nên việc chờ ở đó chỉ lãng phí thời gian. Phép thử chỉ có một câu hỏi, đặt ở mỗi bước: bước này có thật sự cần kết quả của bước ngay trước không? Nếu có, giữ nguyên thứ tự. Nếu không, hai việc đó chạy cùng lúc được.

Ví dụ: yêu cầu "kiểm tra lỗi file A, rồi kiểm tra lỗi file B" đọc như một chuỗi, nhưng việc kiểm tra file B không hề dùng kết quả của file A. Hai việc chỉ chạy lần lượt vì người viết gõ theo thứ tự đó. Chạy song song, tổng thời gian bằng thời gian của file chậm hơn, không bằng tổng hai file cộng lại.

Gần như quy trình nào cũng có hai ba cạnh giả. Tác giả gốc ước tính một quy trình tuần tự 40 bước có thể thu về chỉ 3–5 phụ thuộc thật khi vẽ lại, nghĩa là từ vài phút xuống vài giây với cùng khối lượng công việc. Đây là ước tính minh hoạ của tác giả, không phải số đo; tốc độ thật phụ thuộc vào từng quy trình. Điều rút ra vẫn đúng: nút cổ chai thường là cách bạn xếp hàng, không phải mô hình AI.

Mô hình hình thoi: tách việc, kiểm tra, gộp lại

Mô hình hình thoi là khuôn thiết kế phổ biến nhất trong graph engineering, gồm ba nhịp: tách việc ra nhiều nhánh chạy song song (fan out), gộp và rút gọn kết quả bằng mã thông thường (reduce), rồi để một agent cuối viết câu trả lời từ phần đã gộp (synthesize). Giữa nhịp một và hai thường có thêm bước kiểm tra.

Hình thoi xuất hiện ở hầu hết hệ thống agent nghiêm túc. Tính năng nghiên cứu sâu của nhiều trợ lý AI chạy theo đúng khuôn này: một agent lập kế hoạch các góc tìm hiểu, các agent phụ thu thập song song, kết quả được kiểm tra, rồi một báo cáo duy nhất đến tay người dùng. Khi nhìn ra khuôn này, câu hỏi đổi từ "làm sao cho agent làm thêm nhiều bước" sang "chỗ nào tách, chỗ nào gộp", và câu hỏi thứ hai mới mở rộng được.

Hai mẹo thiết kế đi kèm: dùng model rẻ cho các nút tẻ nhạt (thu thập, trích xuất), dùng model mạnh ở nút cần phán đoán (kiểm tra, tổng hợp); và để phần gộp chạy bằng mã, vì mã không tốn token. Về cách chọn model theo việc, xem bài Nên chọn model AI nào?.

Vì sao người kiểm tra phải có ngữ cảnh riêng?

Người kiểm tra (verifier) phải là một agent khác, bắt đầu từ ngữ cảnh trống, vì AI chấm bài của chính mình thường quá dễ dãi với bản thân. Theo tác giả gốc, các thử nghiệm tự đánh giá của AI đều cho thấy mô hình bỏ sót phần lớn lỗi của chính nó.

Nếu người kiểm tra dùng chung cuộc trò chuyện với người làm, đó không còn là kiểm tra, chỉ là gật đầu với chính mình bằng một kiểu chữ khác. Một đồ thị mà mọi agent dùng chung một ngữ cảnh thực chất là một vòng lặp đơn mặc áo đồ thị: hỏng theo cách cũ, chỉ muộn hơn và đắt hơn.

Nguyên tắc cho nút kiểm tra:

1. Đầu vào chỉ là một nhận định cần kiểm, không kèm lịch sử trò chuyện của người làm.
2. Ngữ cảnh mới, trống, chưa từng thấy việc đang được chấm.
3. Kiểm theo tín hiệu thật: không phải "agent nói đã xong" mà là "bài kiểm thử có thật sự chạy qua".
4. Chia ba góc nhìn: có đúng không, có còn mới không, nguồn có thật không. Ba góc khác nhau bắt được thứ mười góc giống nhau bỏ sót.

Đồ thị hay hỏng ở đâu?

Đồ thị hay hỏng ở ba chỗ, mỗi chỗ có cách chữa cụ thể.

Ngữ cảnh tràn. Tách ra hàng nghìn nút rồi dồn hết kết quả vào một bước cuối sẽ vượt giới hạn ngữ cảnh trước khi bắt đầu tổng hợp. Cách chữa: gộp theo lớp, chia kết quả thành lô, tóm tắt từng lô rồi mới gộp các bản tóm tắt, không bao giờ gộp đống dữ liệu thô.

Độc lập giả. Hai nút trông độc lập vì lời yêu cầu không nhắc nhau, nhưng cùng ghi vào một tệp hoặc cùng gọi một API có giới hạn tốc độ. Đó là một cạnh ẩn. Cách chữa: cho mỗi agent một không gian làm việc riêng, chẳng hạn mỗi agent một nhánh git worktree, và kiểm tra tài nguyên dùng chung chứ không chỉ dữ liệu dùng chung.

Nút chết âm thầm. Trong chuỗi, một bước lỗi làm cả chuỗi dừng, khó chịu nhưng dễ thấy. Trong đồ thị, một nút chết giữa hai trăm nút có thể lọt vào báo cáo trông đầy đủ. Cách chữa: mỗi bước gộp đếm số kết quả nhận được so với số kỳ vọng, và cảnh báo khi thiếu thay vì chạy tiếp với một nửa dữ liệu.

Khi nào không nên dùng graph?

Đồ thị mua được độ rộng, không mua được phán đoán tốt hơn. Khi công việc không rộng, đường thẳng chưa bao giờ là vấn đề. Nên bỏ qua đồ thị trong các trường hợp:

• Việc nhỏ hoặc đơn lẻ, như thêm một hàm hay sửa một lỗi: điều phối chỉ thêm chi phí, một agent làm nhanh và rẻ hơn.
• Bạn muốn duyệt từng bước: đồ thị sinh ra để chạy rộng khi bạn vắng mặt, kiểm soát chặt đi ngược mục đích đó.
• Chưa biết mình tìm gì: việc khám phá hợp với một agent bạn lái được hơn là một đội bị khoá vào kế hoạch.
• Các bước thật sự phụ thuộc nhau: ép đồ thị vào việc tuần tự chỉ tốn thêm tiền mà không nhanh hơn.

Cách nhận biết nhanh là phép thử cạnh giả: nếu không tìm được hai việc nào không có mũi tên giữa chúng, không có đồ thị nào để dựng, và một vòng lặp là đủ.

Chi phí và "điểm neo": đồ thị chỉ trung thực khi có thứ không cãi được

Đồ thị tốn tiền hơn một cuộc trò chuyện thường, vì việc điều phối rẻ đi nhưng các agent vẫn dùng token và một đội agent dùng rất nhiều. Tác giả gốc kể một ví dụ công khai về việc dùng cách này để viết lại một runtime phần mềm lớn trong khoảng 11 ngày với tới 64 agent chạy cùng lúc, tốn khoảng 165.000 USD tiền sử dụng và cần người thiết kế, giám sát liên tục; con số này chưa được OPCAIOS kiểm chứng. Bài học không nằm ở con số mà ở hai điều: đặt giới hạn cứng cho số agent trong lần chạy đầu, và theo dõi chi phí trước khi mở rộng.

Điều quan trọng hơn là điểm neo (anchor). Một đồ thị gồm các nút kiểm tra nhìn nhau và đọc báo cáo của nhau vẫn có thể "nhất quán nhưng không được kiểm chứng": kiểm toán đối chiếu số liệu với số liệu tài chính, mà cả hai cùng đến từ một hệ thống. Cấu trúc đồ thị không tự mua được sự thật. Cần các điểm neo không cãi được: bài kiểm thử đã chạy thật và đã qua, doanh thu thật sự vào ngân hàng, khách hàng thật sự ở lại. Đồ thị chỉ trung thực khi được đo bằng những thứ không thể thương lượng.

Quy trình Bài SEO tự động của opcaios.org có phải là đồ thị không?

Có, một đồ thị nhỏ và hoàn toàn tuần tự. Đây là kinh nghiệm thực tế của chính chúng tôi, không phải ví dụ giả định. Bài SEO tự động mỗi ngày của website chạy: chọn chủ đề, viết dàn ý, viết bài, chấm điểm SEO và GEO (viết lại một lần nếu điểm thấp), rồi một lời gọi AI riêng chỉ đọc bài hoàn chỉnh và liệt kê các khẳng định cần người kiểm lại, như số liệu, giá, ngày tháng.

Hai điểm của quy trình khớp với bài học trên. Bước liệt kê khẳng định là một người kiểm tra có ngữ cảnh riêng: AI đó không thấy quá trình viết, chỉ đọc kết quả. Và có một cổng người duyệt: mọi bài chỉ ở dạng bản nháp, người duyệt bấm đồng ý thì mới lên site; AI không tự đăng. Quy trình này tuần tự vì mỗi bước cần kết quả bước trước, đúng tinh thần phép thử cạnh giả: không có việc nào đáng tách song song, nên không cần ép thành đồ thị rộng.

Làm sao viết một "bản đặc tả đồ thị" bằng tiếng Việt?

Bản đặc tả đồ thị là một đoạn yêu cầu mô tả mục tiêu, các việc song song, bước gộp, bước kiểm tra, nơi lưu và cổng người duyệt, để agent dựng đúng quy trình. Ví dụ cho việc tạo bản nháp bài SEO, người duyệt vẫn là bước cuối:

MỤC TIÊU: một bản nháp bài viết sẵn sàng xếp hạng cho chủ đề [chủ đề]

CÁC VIỆC CHẠY SONG SONG:
  1. các trang đang xếp hạng cao hiện bao quát những gì
  2. những câu hỏi thật người dùng hay hỏi về chủ đề
  3. những gì các trang đó bỏ sót
GỘP:      ba kết quả thành một dàn ý, rồi viết bản nháp đầy đủ
KIỂM TRA: một người kiểm chứng độc lập, ngữ cảnh trống, đánh dấu mọi
          nhận định không có nguồn
LƯU:      thư mục bản-nhap/, ghi danh sách nhận định bị đánh dấu ở đầu tệp
CỔNG NGƯỜI DUYỆT: không bao giờ tự đăng bất cứ thứ gì

Theo tác giả gốc, với Claude Code có thể bắt đầu yêu cầu bằng từ "workflow" để công cụ dựng cả đội agent từ một câu; tính năng này thay đổi theo phiên bản công cụ, nên hãy kiểm tra tài liệu Claude Code hiện hành. Dù dùng công cụ nào, nguyên tắc giữ nguyên: lần chạy đầu giới hạn nhỏ (ví dụ 20 tệp), cho mỗi agent không gian riêng, báo số kết quả nhận về, và để mình là người duyệt cuối.

Bắt đầu từ đâu trong một buổi tối?

Cách bắt đầu rẻ nhất không cần công cụ mới, chỉ cần giấy và bút:

1. Vẽ quy trình AI bạn đang dùng thành các hộp nối bằng mũi tên.
2. Ở mỗi mũi tên, hỏi: bước sau có thật sự dùng kết quả của bước trước không? Xoá mũi tên không mang dữ liệu.
3. Nhóm các hộp đã hết phụ thuộc thành một lớp chạy song song, rồi thêm một bước gộp.
4. Đặt một người kiểm tra ngữ cảnh riêng trước bước gộp, và một điểm neo thật (bài kiểm thử, số liệu từ hệ thống gốc).
5. Chạy thử trên một phần nhỏ, ghi lại chi phí, rồi mới mở rộng.

Nếu bạn dựng quy trình bằng công cụ như n8n hoặc script gọi API, cùng nguyên tắc áp dụng được: chạy các nhánh độc lập đồng thời, đếm kết quả ở bước gộp, và giữ một cổng duyệt trước hành động không hoàn tác được.

Câu hỏi thường gặp

Graph engineering khác vòng lặp (loop) ở điểm nào?

Vòng lặp là một agent cải thiện một thứ lặp đi lặp lại: thử, kiểm tra, chỉnh, làm lại. Graph engineering nối nhiều vòng lặp và nhiều việc thành mạng, trong đó các nút kiểm tra và sửa cho nhau thay vì một agent tự chấm điểm bản thân.

Có cần biết lập trình để làm graph engineering không?

Không bắt buộc để hiểu và thiết kế, vì bước vẽ sơ đồ và hỏi "có phụ thuộc thật không" chỉ cần giấy bút. Để chạy thật, bạn dùng công cụ có sẵn như Claude Code, n8n hoặc Make; viết mã chỉ cần khi muốn điều khiển chi tiết.

Đồ thị agent có luôn nhanh hơn quy trình tuần tự không?

Không. Đồ thị nhanh hơn khi công việc có nhiều phần độc lập. Nếu các bước thật sự phụ thuộc nhau hoặc việc nhỏ, đồ thị chỉ thêm chi phí điều phối mà không nhanh hơn.

Làm sao tránh đồ thị tốn tiền ngoài ý muốn?

Đặt giới hạn cứng số agent và số tệp cho lần chạy đầu, theo dõi chi phí của một lần chạy trước khi mở rộng, và dùng model rẻ cho các nút tẻ nhạt. Bước gộp nên chạy bằng mã thay vì AI.

Nên bắt đầu học từ đâu?

Bắt đầu với phép thử cạnh giả trên một quy trình bạn đang dùng. Muốn dựng quy trình AI cho nhóm nhỏ, xem khoá đào tạo ứng dụng AI của OPCAIOS.

Nguồn: ý tưởng và số liệu minh hoạ từ bài của @AnatoliKopadze trên X (24/7/2026), chưa kiểm chứng độc lập; ví dụ Bài SEO tự động là kinh nghiệm của OPCAIOS.