🕸️ Graph Engineering: Khi xây agent không còn chỉ là viết một vòng lặp

Nếu vài tháng trước cuộc nói chuyện về AI agent thường xoay quanh một mẫu quen thuộc — model gọi tool, nhận kết quả, suy nghĩ tiếp rồi lặp lại — thì gần đây một cách gọi mới bắt đầu lan trên X: Graph Engineering.

Ngày 18/07/2026, Peter Steinberger hỏi ngắn gọn: “Are we still talking loops or did we shift to graphs yet?” Bài đăng đạt mức hiển thị lớn và kéo theo hơn một nghìn phản hồi hiển thị trên X. Carlos E. Perez sau đó mở rộng câu hỏi thành bài “From Loop Engineering to Graph Engineering?”. Nhưng trước khi mở tiệc đặt tên cho một ngành mới, mình cần nói rõ:

Graph Engineering hiện là một nhãn đang nổi lên, chưa phải tiêu chuẩn chính thức hay một discipline có định nghĩa thống nhất. Nó không phải tên của LangGraph, AutoGen hay bất kỳ framework riêng lẻ nào.

Giá trị của thuật ngữ nằm ở một chuyển dịch tư duy có thật: khi agent dài hơi hơn, có nhiều công cụ, nhiều vai trò và nhiều điểm rủi ro, đơn vị thiết kế không còn chỉ là một vòng lặp. Nó trở thành đồ thị của hành động, trạng thái, thông tin, đánh giá và quyền kiểm soát.

Loop Engineering là gì?

Một agent loop cơ bản thường gồm năm bước:

1. nhận nhiệm vụ;
2. suy luận hoặc lập kế hoạch;
3. gọi công cụ;
4. đọc kết quả;
5. lặp lại đến khi trả lời hoặc dừng.

Mẫu này mạnh vì dễ dựng, dễ hiểu và đủ tốt cho nhiều tác vụ. Thực ra graph không loại bỏ loop: một graph thường chứa nhiều loop nhỏ.

Giới hạn xuất hiện khi hệ thống cần làm đồng thời những việc như:

• nghiên cứu, viết nháp, kiểm chứng rồi sửa lại;
• fan-out các phần việc độc lập và fan-in kết quả;
• rẽ nhánh theo kết quả của bước xác minh;
• chặn thao tác nhạy cảm để chờ human approval;
• retry có giới hạn, fallback hoặc escalation;
• giữ state và điều kiện dừng nhất quán qua một quy trình dài.

Một loop chỉ nhìn thấy tín hiệu mà ta giao cho nó tối ưu. Nếu tín hiệu sai hoặc thiếu, loop vẫn có thể chạy “đúng” mà toàn hệ thống đi sai. Đây là biến thể rất gần với Goodhart: khi một chỉ số trở thành mục tiêu, nó dễ thôi còn là chỉ số tốt.

Ví dụ đời thường: một chiến dịch ra mắt sản phẩm

Hãy hình dung công ty chuẩn bị chạy chiến dịch truyền thông cho một sản phẩm mới.

Loop có thể là quy trình của từng phòng ban. Marketing nghiên cứu khách hàng, xây thông điệp, xem phản hồi rồi chỉnh sửa. Media sản xuất hình ảnh hoặc video, nhận review rồi sửa lại. Sales thử nghiệm kịch bản tư vấn, ghi nhận những câu hỏi của khách hàng rồi tối ưu tiếp. Mỗi nhóm có một vòng lặp riêng: làm → kiểm tra → điều chỉnh → kiểm tra lại cho đến khi đạt yêu cầu.

Nhưng một chiến dịch lớn không chỉ là nhiều phòng ban cùng làm việc. Nó cần một graph điều phối để mô tả quan hệ giữa các công việc:

• Marketing phải hoàn thành thông điệp trước khi Media bắt đầu sản xuất.
• Sales và Media có thể chạy song song sau khi nhận brief.
• Nếu pháp lý từ chối một claim, chỉ phần thông điệp quay lại Marketing để sửa, thay vì bắt toàn bộ chiến dịch làm lại.
• Nếu dữ liệu thử nghiệm không đạt KPI, quy trình rẽ sang nhánh điều chỉnh nội dung.
• Chỉ khi các nhánh quan trọng cùng đạt điều kiện và được phê duyệt, chiến dịch mới đi tới nút Launch.

Đó cũng là cách dễ hình dung nhất về mối quan hệ giữa loop và graph: loop tối ưu cách một công việc tự hoàn thành; graph điều phối cách nhiều công việc và nhiều loop cùng hoàn thành một mục tiêu lớn. Và cũng giống trong công ty, graph không chỉ gồm các vòng lặp: nó còn có bước chạy một lần, nhánh điều kiện, điểm bàn giao, nơi hợp nhất kết quả và checkpoint cần con người quyết định.

Graph Engineering thêm điều gì?

Cách hiểu thực dụng nhất gồm bốn lớp.

1. Node — ai chịu trách nhiệm việc gì?

Mỗi node nên có vai trò hẹp và kiểm tra được: truy xuất nguồn, gọi tool, tạo bản nháp, kiểm chứng claim, xin phê duyệt hoặc xuất bản.

Một node tốt phải trả lời được: dùng input nào, được gọi tool gì, phải trả output theo contract nào, và thất bại trông ra sao. Nếu mọi node đều chỉ là “general agent nhưng prompt khác”, graph có thể đang che sự mơ hồ thay vì giảm nó.

2. Edge — bước nào được phép dẫn tới bước nào?

Edge không chỉ là mũi tên để slide trông xịn hơn. Nó là luật chuyển trạng thái: điều kiện kích hoạt, dữ liệu chuyển tiếp, timeout, retry, approval và đường thoát.

Microsoft AutoGen minh họa khá rõ bằng GraphFlow: directed graph có thể mô tả chuỗi tuần tự, fan-out song song, nhánh có điều kiện và loop có điều kiện thoát. Một writer có thể gửi kết quả cho hai editor chạy song song, rồi hợp nhất ở final reviewer.

3. State và information flow — chạy theo thứ tự nào chưa đủ

Tài liệu AutoGen phân biệt hai khái niệm:

• execution graph quyết định agent nào được chạy;
• message graph quyết định agent nào thực sự nhận được thông tin nào.

Đây là chi tiết rất đáng tiền. Một team có thể chạy đúng thứ tự nhưng vẫn đưa toàn bộ lịch sử cho mọi agent, khiến context phình to, vai trò nhiễu lẫn nhau và reviewer bị ảnh hưởng bởi thông tin không liên quan.

Nguyên tắc tốt là: mỗi agent chỉ nhận lượng context tối thiểu cần cho quyết định kế tiếp. Đó vừa là tối ưu token, vừa là ranh giới quản trị.

4. Anchor — bằng chứng nào nằm ngoài việc AI tự khen AI?

Perez nhấn mạnh rằng topology đẹp không tự tạo ra độ tin cậy. Một graph đầy reviewer, evaluator và retry vẫn có thể nhất quán nội bộ nhưng sai với thế giới thật.

Các anchor nên nằm ngoài vòng tự xác nhận của model:

• test thực thi trên hệ thống thật;
• nguồn có thể truy xuất và kiểm tra;
• policy hoặc budget agent không tự sửa;
• human review ở quyết định tác động lớn;
• outcome thật của người dùng hay doanh nghiệp;
• rollback khi quan sát thấy thất bại.

Các framework hiện tại phản ánh hướng đi này ra sao?

LangGraph tự mô tả là framework orchestration cấp thấp cho agent và workflow có trạng thái, chạy dài hạn. Tài liệu nhấn mạnh persistence, durable execution, human-in-the-loop, memory và observability. Ở ví dụ cơ bản, developer tạo StateGraph, thêm node và nối edge từ START đến END.

AutoGen GraphFlow đưa directed graph vào việc điều phối team agent, hỗ trợ sequence, parallel fan-out, conditional branching và loop có exit condition.

Hai framework này là bằng chứng rằng graph-oriented orchestration đã là kỹ thuật thật. Chúng không phải bằng chứng rằng “Graph Engineering” đã trở thành một chuẩn ngành mới. Đây là chỗ cần tách technology trend khỏi social-media label.

Ví dụ gần gũi: dây chuyền viết bài này

Một loop mong manh có thể là:

research → write → self-review → publish

Graph có kiểm soát hơn sẽ là:

brief → source discovery → source verification → outline → draft → claim check → human approval → publish

Trong đó:

• source discovery chỉ trả về ứng viên, chưa được gọi là fact;
• source verification phải gắn claim với bằng chứng;
• draft chỉ dùng claim đã xác minh;
• style review không được âm thầm đổi nội dung thực tế;
• claim check có quyền trả bài về revision;
• publish là transition riêng, cần quyền rõ ràng.

Không nhất thiết phải dùng nhiều model. Một model có thể vận hành nhiều node; graph vẫn hữu ích vì input, quyền, contract và exit criterion khác nhau.

Khi nào đáng dùng graph — và khi nào không?

Graph phù hợp khi có ít nhất một dấu hiệu:

• bước sau không được chạy trước khi điều kiện được xác minh;
• nhiều nhánh độc lập cần hợp nhất;
• reviewer có thể từ chối và gửi về sửa;
• tool rủi ro cao cần checkpoint;
• lỗi cần retry, fallback hoặc escalation rõ ràng;
• đội vận hành cần biết “vì sao agent đi đường này”.

Ngược lại, hỏi–đáp đơn giản, một tool call có giới hạn hoặc loop ngắn với điểm dừng rõ không nhất thiết cần workflow engine. Over-engineering graph tạo thêm code điều phối, latency, hand-off và ảo giác rằng sơ đồ đẹp đồng nghĩa hệ thống an toàn.

Câu hỏi đúng không phải “vẽ được graph không?”, mà là:

“Việc làm rõ các boundary này có cải thiện đáng kể khả năng kiểm soát, độ tin cậy, an toàn hoặc khả năng debug không?”

Graph có thay thế Loop không?

Không theo nghĩa loại bỏ. Loop vẫn là primitive quan trọng: quan sát, hành động, nhận phản hồi, lặp lại. Graph là lớp tổ chức và quản trị quanh các loop.

Vì vậy, câu “Graph Engineering sẽ thay thế Loop Engineering” nghe bắt tai nhưng quá mạnh so với bằng chứng hiện có. Cách nói chính xác hơn là:

Khi agent chuyển từ demo sang hệ thống nhiều bước có ảnh hưởng thật, kỹ thuật tối ưu một loop sẽ dần được bao quanh bởi kỹ thuật thiết kế cả graph điều khiển.

Đây là một dự báo hợp lý, chưa phải sự thật đã hoàn tất. Những gì đã có hôm nay là framework graph, nhu cầu observability, bounded retries, human gates và information boundaries. Tên gọi “Graph Engineering” có thể sống lâu hoặc bị thay bởi một nhãn khác; bài toán mà nó chỉ ra thì khó biến mất.

Kết luận

Loop Engineering hỏi: làm sao để vòng lặp này tốt hơn?

Graph Engineering hỏi rộng hơn: loop nằm ở đâu, nhìn thấy gì, được phép làm gì, ai có quyền chặn, và bằng chứng nào xác nhận nó đã làm đúng?

Đó là lý do thuật ngữ đang gây chú ý. Nó gọi đúng tên một bước trưởng thành của agent engineering: từ prompt và tool calling sang orchestration, observability và governance. Chưa phải chuẩn. Chưa phải phép màu. Nhưng là một lăng kính rất đáng dùng.

Nguồn tham khảo

• Peter Steinberger, bài đăng X ngày 18/07/2026: https://x.com/steipete/status/2078277297791189132
• Carlos E. Perez, “From Loop Engineering to Graph Engineering?”: https://x.com/IntuitMachine/status/2078419526354378975
• Bản lưu bài của Perez trong GitHub issue: https://github.com/FeeiCN/FEEI.CN/issues/466#issuecomment-5013905127
• LangGraph overview: https://docs.langchain.com/oss/python/langgraph/overview
• LangGraph repository: https://github.com/langchain-ai/langgraph
• Microsoft AutoGen GraphFlow: https://microsoft.github.io/autogen/stable/user-guide/agentchat-user-guide/graph-flow.html