Graph engineering là gì? Cách thiết kế AI agent bằng đồ thị

Thay vì để mô hình ngôn ngữ lớn (LLM) tự "bơi" trong một cửa sổ chat vô định, bạn dùng đồ thị để kiểm soát chặt từng bước đi của nó.

LLM là loại phần mềm không xác định (non-deterministic). Graph engineering chính là nỗ lực biến sự mơ hồ đó thành một hệ thống ổn định, rẻ hơn và dễ dự đoán hơn, bằng cách ghép mã nguồn truyền thống với khả năng suy luận của mô hình. Thuật ngữ này bùng nổ trên X gần đây, gắn liền với thành công của LangGraph — công cụ hiện đạt hơn 65 triệu lượt tải mỗi tháng.

Graph engineering là gì?

Graph engineering không phải là một khái niệm "từ trên trời rơi xuống". Nó là bước tiến hóa tất yếu của lập trình agent: đi từ việc viết những prompt đơn lẻ sang xây dựng các luồng công việc (workflow) có cấu trúc. Trong hệ thống này, "kiến trúc nhận thức" là cách bạn tổ chức để mô hình suy luận, sử dụng công cụ và xử lý phản hồi.

Thay vì nhồi nhét mọi thứ vào một cửa sổ chat khổng lồ rồi hy vọng mô hình làm đúng — nơi nó vừa phải lập kế hoạch vừa phải thực thi — bạn chia hệ thống thành các node chuyên biệt. Mô hình lúc này chỉ đảm nhận một số node nhất định.

Lộ trình của ngành đã đi từ prompt engineering sang context engineering, và giờ là graph engineering, với sự ra đời của LangGraph từ ba năm trước. Giới kỹ sư đang dần lấy lại quyền kiểm soát luồng thực thi từ tay AI.

Vì sao một vòng lặp agent không còn đủ?

Khi nhiệm vụ phức tạp hơn — review code hay phân loại bug tự động — một vòng lặp đơn lẻ rất dễ sa vào trạng thái mà Carlos Perez gọi là "nonsense có tổ chức" (organized nonsense). Khi nhiều agent dùng chung một ngữ cảnh lỗi, chúng có xu hướng đồng thuận với cái sai của nhau. Để một mô hình tự kiểm tra chính nó chẳng khác gì để học sinh tự ra đề rồi tự chấm bài mình: kết quả luôn là "đạt", giá trị thực tế bằng không.

Các hệ thống thiếu cấu trúc đồ thị thường vấp phải ba lỗi hệ thống sau:

• Mất kiểm soát trạng thái (state). Không thể theo dõi dữ liệu biến đổi qua từng bước.
• Lãng phí ngân sách token. Gửi đi gửi lại toàn bộ lịch sử một cách vô tội vạ.
• Thiếu điểm veto. Không có cơ chế dừng lại hay chuyển hướng khi agent đi chệch.

Để xử lý, bạn cần các nhánh song song nhằm giảm độ trễ, và các bộ lọc kiểm định (gate) để tách bạch nhiệm vụ thực thi khỏi nhiệm vụ giám sát.

Node, edge và state: ba thành phần của một đồ thị agent

Một đồ thị agent gồm ba thành phần cốt lõi:

1. Node (nút). Nơi thực hiện công việc. Nó có thể là code Python thuần, một lần gọi LLM, hoặc một sub-agent.
2. Edge (cạnh). Xác định luồng di chuyển. Cần phân biệt cạnh cố định với cạnh có điều kiện (conditional edge) — thứ cho phép đồ thị rẽ nhánh dựa trên kết quả của node trước đó.
3. State (trạng thái). Cấu trúc dữ liệu dùng chung (TypedDict hoặc Pydantic), đóng vai trò "bộ nhớ" của hệ thống.

Một kỹ thuật quan trọng là dùng reducer để xử lý các bản cập nhật trạng thái — ví dụ gộp danh sách kết quả tìm kiếm thay vì ghi đè hoàn toàn dữ liệu cũ.

Đây là một mẫu thiết kế đồ thị cơ bản có dùng cạnh có điều kiện:

from typing import Literal, TypedDict
from langgraph.graph import StateGraph, START, END
 
# Định nghĩa trạng thái của hệ thống
class AgentState(TypedDict):
    task: str
    is_valid: bool
    feedback: str
 
# Node thực hiện công việc
def worker_node(state: AgentState):
    # Giả định logic kiểm định kết quả tại đây
    return {"is_valid": False, "feedback": "Cần bổ sung dữ liệu"}
 
# Router để quyết định luồng đi (cạnh có điều kiện)
def router(state: AgentState) -> Literal["retry", "end"]:
    if state["is_valid"]:
        return "end"
    return "retry"
 
builder = StateGraph(AgentState)
builder.add_node("worker", worker_node)
 
builder.add_edge(START, "worker")
# Nếu router trả về 'retry', quay lại worker
builder.add_conditional_edges("worker", router, {"retry": "worker", "end": END})
 
graph = builder.compile()

Cơ chế "super-step" cho phép các node không phụ thuộc nhau chạy song song, giúp tối ưu hiệu suất khi lên production.

Những mẫu thiết kế đồ thị thường gặp

Bạn không cần nghĩ lại mọi thứ từ đầu. Có sẵn những mẫu (pattern) đã được chứng minh:

• Chaining. Chuỗi xử lý tuần tự.
• Routing. Điều hướng dựa trên phân loại logic.
• Parallelization. Chạy song song để giảm độ trễ.
• Orchestrator-Worker. Một node chính phân rã nhiệm vụ cho các node thợ.
• Evaluator-Optimizer. Vòng lặp phản hồi giữa node tạo nội dung và node kiểm định. Đây là mẫu bắt buộc nếu bạn muốn xây hệ thống tự sửa lỗi.

Graph hay loop: tranh luận này thực sự nói về điều gì?

Cuộc tranh luận trên X giữa Harrison Chase (LangChain), David K (tác giả XState) và Max Weinbach thực chất xoay quanh một câu hỏi: cấu trúc hóa đến mức nào là đủ. David K cho rằng ngành đang tái khám phá những mẫu thiết kế phần mềm cũ như state machine rồi đóng gói lại cho thời đại AI.

Xét về bản chất, loop chỉ là một dạng đồ thị có chu kỳ (cyclic graph). Câu hỏi thật sự nằm ở chỗ cấu trúc đến mức nào thì đủ, chứ không phải chọn bên nào. Đừng xây một đồ thị 40 node cho nhiệm vụ mà một vòng lặp 5 dòng code giải quyết được. Chỉ thêm cấu trúc khi nó thực sự mang lại quyền kiểm soát rõ rệt.

LangGraph có phải lựa chọn duy nhất?

Lựa chọn tùy thuộc vào mức độ bạn tin tưởng mô hình:

Chọn Strands khi bạn tin vào khả năng lập kế hoạch của LLM; chọn LangGraph khi rủi ro mô hình làm sai là quá lớn. Ngoài ra còn có Google ADK và Microsoft Agent Framework nếu bạn muốn tích hợp sâu vào các hệ sinh thái đó.

Những gì sơ đồ không cho bạn thấy khi lên production

Khi đưa vào thực tế, những sơ đồ đẹp đẽ thường sụp đổ vì thiếu các yếu tố sau:

• Tính bền vững (durable execution). Checkpoint của LangGraph chỉ là "điểm lưu". Nếu server sập giữa chừng, hệ thống không tự chạy lại. Bạn cần một cơ chế điều phối (orchestrator) bên ngoài — heartbeat hoặc watchdog — để thực sự đảm bảo công việc hoàn thành.
• Tính lũy đẳng (idempotency). Một node chạy lại do lỗi hệ thống tuyệt đối không được gây tác dụng phụ, ví dụ trừ tiền khách hàng hai lần.
• Cô lập ngữ cảnh và ngân sách token. Lỗi nghiệp dư thường gặp là đưa toàn bộ state vào mọi node. Việc này gây nhiễm độc ngữ cảnh (context poisoning) và đốt tiền token. Chỉ cấp cho node đúng những key dữ liệu nó thực sự cần.
• Kiểm định ngoại vi. Đừng tin lời agent khi nó báo "tôi làm xong rồi". Hãy kiểm bằng chứng cứ thực tế: unit test đã pass chưa, tiền đã vào tài khoản chưa.

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

Đừng lạm dụng đồ thị cho những tác vụ quá linh hoạt, không thể đoán trước lộ trình — Deep Research kiểu khám phá mở là ví dụ điển hình. Ép một tiến trình sáng tạo vào các node cứng nhắc sẽ làm mất chính khả năng xoay sở của mô hình. Với dự án nhỏ hoặc bản prototype, chi phí thiết kế đồ thị cũng thường lớn hơn giá trị nó mang lại.

Lời khuyên thực chiến: bắt đầu đơn giản bằng một vòng lặp. Chỉ nâng lên đồ thị khi hệ thống bắt đầu xuất hiện lỗi lặp lại do thiếu kiểm soát, hoặc khi bạn cần khả năng phục hồi trạng thái phức tạp.

Tài liệu tham khảo

• 3 Years of Graph Engineering with LangGraph — LangChain
• Graph API Overview — LangChain Docs
• Graph Engineering for AI Agents: Beyond the Single-Agent Loop — Analytics Vidhya
• Graph-Based Agentic AI with LangGraph: Workflow Pathways for Long-Running Stateful Business Processes — arXiv
• Graph Engineering Explained: What Actually Changed — Louis Bouchard
• Graphs vs. Loops: The Agentic AI Orchestration Debate — explainX
• Checkpoints Are Not Durable Execution — Diagrid
• Strands vs LangGraph: 2026 Agent SDK Comparison — fp8.co