Tuần thứ ba của tháng 7/2026, X có một trend mới toanh: "graph engineering". Mình đọc xong 5 bài liên tiếp, thấy nửa số đó đúng là hype, nửa còn lại là thứ đáng đưa vào workflow thật. Bài này viết cho phe thứ hai.
Trước khi vào nội dung, nói thẳng luôn kết luận để bạn khỏi mất thời gian: 90% task bạn đang làm không cần graph. Nếu bạn đang định build 5 node cho một việc mà 1 agent chạy loop là xong, dừng lại, quay về đọc phần "Decision table" bên dưới trước.
Bối cảnh: từ loop leo lên graph
Mỗi năm leverage trong AI engineering lại lùi ra một tầng, xa dần khỏi con model:
2023-24 Prompt → cái request bạn gửi → vai trò: Operator 2024 Context → thứ model nhìn thấy → vai trò: Editor 2025 Harness → tool, memory, scaffolding → vai trò: Toolmaker Đầu 2026 Loop → chu trình 1 agent lặp tới xong → vai trò: System designer Giữa 2026 Graph → sự phối hợp giữa nhiều agent → vai trò: Org designer
Từ "graph engineering" nổ ra trên X khoảng 18-19/7/2026, bắt nguồn từ một câu hỏi buông lửng của Peter Steinberger (người tạo OpenClaw): đại ý là liệu mọi người còn nói về loop hay đã chuyển sang graph rồi. Chỉ vậy thôi — không phải một launch, không phải một paper. Một câu hỏi. Rồi timeline tự trả lời trong vòng 24 giờ, với đủ kiểu diễn giải: "loop engineering đã chết", "agent đang tốt nghiệp từ while-loop lên sơ đồ tổ chức".
Điểm mấu chốt cần giữ lại xuyên suốt bài: không có capability nào mới ra đời ngày 18/7. Cái thay đổi chỉ là cái tên người ta đặt cho một vấn đề thiết kế mà họ đã gặp từ trước — vấn đề một cái loop không còn đúng hình dạng cho công việc nữa.
Một agent graph có đúng 3 thành phần
Bỏ hết từ ngữ marketing đi, một graph chỉ gồm:
- Node — đơn vị làm việc. Thường là một agent chuyên biệt ("researcher", "writer", "reviewer") hoặc một bước xử lý thuần túy (function, tool call, data fetch). Mỗi node một việc.
- Edge — đường định tuyến giữa các node. Có thể là tuần tự (A xong tới B), có điều kiện (pass thì ship, fail thì quay lại), fan-out (1 node bắn ra 3 node chạy song song), fan-in (3 kết quả gộp lại thành 1).
- Shared state — đối tượng di chuyển theo edge. Là thứ mọi node đọc/ghi vào: task, draft, ghi chú, verdict. Không có state thì đống agent đó chỉ là một group chat mất trí nhớ.
Graph kinh điển nhất — researcher nuôi writer, reviewer kiểm tra draft, edge có điều kiện quyết định ship hay quay lại:
┌──────────────┐
task ───────► │ RESEARCHER │ gom nguồn, viết notes
└──────┬───────┘
│ state: {task, notes}
▼
┌──────────────┐
│ WRITER │ biến notes thành draft
└──────┬───────┘
│ state: {task, notes, draft}
▼
┌──────────────┐
│ REVIEWER │ chấm draft theo tiêu chuẩn
└──────┬───────┘
│
pass? ─┴─ no ──► quay lại WRITER (conditional edge / loop)
│
yes
▼
┌──────┐
│ SHIP │
└──────┘
3 node, 4 edge — 1 edge có điều kiện, 1 edge loop ngược về writer. State phình dần theo dòng chảy: notes của researcher đi theo tới writer, draft đi theo tới reviewer, verdict của reviewer quyết định bước tiếp theo.
Điều giữ cho cả khái niệm này không biến thành "vũ trụ hoàn toàn mới": một loop chỉ là graph 1 node với edge trỏ về chính nó. Mọi thứ bạn đã học về thiết kế loop — chu trình discover/plan/execute/verify, stop condition, verifier — chính là phần bên trong của một node. Graph không thay thế loop. Graph là thứ bạn có khi nhiều loop cần bàn giao cho nhau.
Decision table: khi nào thật sự cần graph
Đây là bảng quan trọng nhất bài, đọc kỹ trước khi mở IDE:
| Tín hiệu | Loop là đủ | Nên chuyển sang graph |
|---|---|---|
| Hình dạng task | Một việc, một điểm kết thúc rõ ràng | Tách thành nhiều chuyên môn cần bàn giao nhau |
| Song song hóa | Các bước tuần tự | Cần fan-out (chạy song song) rồi join lại |
| Tool/model mỗi bước | Dùng chung tool xuyên suốt | Mỗi bước cần model hoặc tool khác nhau |
| Control flow | 1 agent tự do xử lý an toàn | Cần định tuyến rõ ràng, có thể audit |
| Cách ly lỗi | Bước lỗi thì retry là xong | Muốn 1 node hỏng không lan sang node khác |
| Ai verify | Agent tự kiểm tra output của chính nó | Cần 1 node reviewer riêng, kiểm tra node khác |
Không cần cả 6 dấu hiệu đều nghiêng về cột phải. Nhưng nếu phần lớn câu trả lời thật của bạn rơi vào cột trái, build graph là cách biến một task 2 tiếng thành một dự án framework 2 ngày.
❌ Over-engineered — graph không cần thiết
Task: "Tóm tắt file PDF này." ❌ Build 5 node: fetcher → chunker → summarizer → reviewer → formatter, với conditional edge và shared state object đầy đủ. Kết quả: chậm hơn để build, khó debug hơn, chi phí chạy cao hơn — so với việc chỉ cần MỘT agent chạy loop đọc file và viết summary. Bạn vừa dựng một sơ đồ tổ chức để trả lời một cái email.
✅ Right-sized — graph xứng đáng tồn tại
Task: "Mỗi sáng tạo ra một bản market brief đã research và fact-check." ✅ Researcher node fan-out qua 5 nguồn song song ✅ Synthesizer join kết quả lại ✅ Writer soạn draft ✅ Reviewer node (model khác, read-only) chấm điểm, fail thì loop lại Mỗi node cầm một việc mà một loop đơn không kham nổi. Hand-off chính là lý do graph tồn tại.
Phép thử đơn giản: nếu gộp cả 5 node lại thành 1 loop mà không mất gì, thì nên gộp.
5 tầng của AI engineering
1. Prompt → request đơn lẻ → Câu hỏi: mình hỏi đã ổn chưa? 2. Context → thứ model nhìn thấy → Câu hỏi: model có đủ thông tin chưa? 3. Harness → tool, memory, scaffold → Câu hỏi: agent hành động & nhớ được không? 4. Loop → chu trình lặp 1 agent → Câu hỏi: khi nào tự kiểm tra & dừng? 5. Graph → phối hợp nhiều agent → Câu hỏi: ai làm gì, thứ tự nào, chia sẻ state gì?
Stack này cộng dồn, không phải cái thang bạn leo rồi bỏ tầng dưới. Một graph chứa đầy node; một node tốt là một loop thiết kế tốt; một loop tốt cần một harness thật (context, tool, orchestration, state, evaluation, recovery). Bỏ qua tầng dưới, graph phía trên chỉ fail theo cách phức tạp hơn thôi. Node yếu thì org chart cũng yếu.
Có phải chỉ là LangGraph mặc áo mới?
Câu trả lời thẳng: phần lớn đúng vậy. Ý tưởng build hệ agent thành graph gồm node/edge/state đã có trong sản phẩm thật từ trước khi cụm từ "graph engineering" trend:
- LangGraph (LangChain) — theo tài liệu chính thức, đây là framework orchestration cấp thấp để build, quản lý, deploy agent stateful chạy dài. Bạn define một
StateGraph, add node, add edge — chính xác mô hình node/edge/state ở trên. - Microsoft AutoGen — GraphFlow — mang orchestration đa-agent theo graph vào AutoGen: mô tả cách một team agent kết nối và bàn giao nhau, thay vì chạy 1 agent đơn độc.
- Google ADK (Agent Development Kit) — đưa mô hình graph thành tính năng chủ đạo, có sẵn sequential/parallel/loop workflow agent và agent routing (fan-out/fan-in, loop) như building block có sẵn.
- A2A (Agent2Agent) — giao thức mở cho agent ủy quyền lẫn nhau xuyên hệ thống, là bằng chứng rõ nhất rằng ý tưởng multi-agent đã có lịch sử thật từ trước cả buzzword.
Vậy cái gì thật sự mới giữa 2026? Không phải công nghệ — công nghệ có từ trước. Cái mới, nhỏ hơn nhiều so với "paradigm mới", là: một cái tên chung cho những quyết định thiết kế mà các framework này vốn đã yêu cầu bạn làm (node là gì, edge là gì, state chứa gì), và một nhận thức đang lớn dần rằng đây là một kỹ năng riêng đáng dạy, chứ không chỉ là chi tiết kỹ thuật của một framework.
Có phải chỉ là slop?
Phe hoài nghi không phải dân nghiệp dư. Một vài lập luận đáng nghe:
- Người tạo ra XState — dân chuyên state machine — nhắc thẳng: đồ thị có hướng gồm state và transition là khoa học máy tính đã có từ hàng chục năm nay, chẳng có gì mới để "công bố".
- Một ý kiến khác chỉ ra: việc đặt tên cơ chế (loop, graph) đang bị nhầm lẫn với bản chất thật sự (mục tiêu và cách đo thành công). Thay vì đặt tên cơ chế, nên cho agent biết objective, lý do nó quan trọng, và tiêu chí đo thành công.
- Có người chỉ ra A2A và các bài LinkedIn từ 2025 đã nói về multi-agent delegation rồi — coi đây là buzzword ra đời muộn, không phải sớm.
Nhận hết những điểm đó, vì chúng đều đúng: cơ chế graph có hướng, state machine, orchestration engine, giao thức agent-to-agent — tất cả có trước buzzword nhiều năm. Phần lớn content ăn theo trend đúng là slop. Và bản thân từ "graph engineering" là tùy chọn — bạn build được mọi hệ thống trong bài này mà chẳng cần gọi tên nó.
Nhưng tách cái tên ra khỏi cái dịch chuyển thật sự: dưới lớp ồn ào, có một sự leo thang thiết kế thật đang xảy ra — team nào đã thuần thục việc chạy 1 agent trong loop đang gặp tường, nơi 1 loop không còn đúng hình dạng nữa, và họ chủ động tách việc thành các node chuyên biệt phối hợp qua shared state. Sự leo thang đó có thật, dù bạn gọi nó là gì. Phe hoài nghi không phủ nhận điều đó — họ chỉ đang phủ nhận cái hype quanh một cái tên, và ở điểm đó họ đúng.
Checklist trước khi tách loop thành graph
[ ] 1. Thử giữ nguyên loop trước.
Một agent chạy loop với verifier tốt có làm được không?
Nếu có → dừng lại, xong việc.
[ ] 2. Chỉ đặt tên node nếu là chuyên môn thật.
Mỗi node phải cầm một việc mà loop đơn không kham nổi
(model khác, toolset khác, vai trò reviewer read-only).
"Bước có thể inline" KHÔNG phải là node.
[ ] 3. Vẽ edge trước khi code.
Cái gì tuần tự, cái gì fan-out, cái gì fan-in,
edge điều kiện/loop-back nằm ở đâu.
Không vẽ được trên khăn ăn → quá phức tạp.
[ ] 4. Thiết kế shared state object rõ ràng.
Cái gì đi theo edge, ai được ghi vào state.
State trôi dạt (drift) là cách #1 khiến graph mục ruỗng.
[ ] 5. Cho reviewer node có "răng".
Node giá trị cao nhất thường là verifier read-only,
tách biệt khỏi agent tạo ra kết quả.
[ ] 6. Cách ly lỗi.
1 node fail và retry được, không được làm hỏng
shared state hay đầu độc node phía sau.
[ ] 7. Dùng framework có sẵn, đừng tự viết runtime.
LangGraph, AutoGen GraphFlow, Google ADK đã có sẵn
node/edge/state/fan-out/fan-in/loop.
[ ] 8. Đặt spend cap và hard bound.
Graph = nhiều loop cộng lại; verifier yếu giờ đốt token
song song, không phải tuần tự nữa.
Nếu build graph tuần này, thắng lợi không nằm ở "nhiều node nhất". Nó nằm ở: mỗi node làm việc mà loop không làm được, và bạn vẫn giải thích được toàn bộ hệ thống trong một hơi thở.
Kết
Graph engineering không phải capability mới — LangGraph, AutoGen GraphFlow, Google ADK đã làm chuyện này từ trước. Cái thật sự mới chỉ là cái tên, và một nhận thức rằng thiết kế node/edge/state là kỹ năng riêng đáng học, tách khỏi việc thiết kế một loop đơn.
Thứ tự học vẫn không đổi: nắm loop trước — một agent, một verifier rõ ràng, một stop condition tường minh — rồi mới tách thành graph khi công việc thật sự ép bạn phải làm vậy. Đừng vẽ sơ đồ tổ chức để trả lời một cái email.
Bài viết này phân tích và tổng hợp lại cuộc tranh luận "graph engineering" nổ ra trên X giữa tháng 7/2026, cùng góc nhìn phản biện từ cộng đồng.