Graph Engineering là gì?

Mấy tuần gần đây tui thấy cụm từ Graph Engineering bắt đầu xuất hiện ngày càng nhiều trong các cuộc thảo luận về AI agents, coding agents và multi-agent systems.

Nghe cái tên khá mới. Khá sang. Khá có mùi “một ngành engineering mới vừa được phát minh cuối tuần rồi” :))))

Cảnh báo: bài dài lắm nhaaaaa!

Nhưng trước khi đi sâu hơn, có một chuyện cần làm rõ ngay từ đầu:

Graph Engineering không hề mới.

Nếu bỏ chữ “AI” ra khỏi câu chuyện thì engineers đã thiết kế systems dưới dạng graph từ rất lâu rồi.

Dependency graphs, state machines, workflow engines, dataflow systems, build systems, schedulers, distributed systems... tất cả đều có chung một tư duy nền tảng:

Một công việc lớn → chia thành nhiều đơn vị nhỏ → xác định quan hệ giữa chúng → quản lý state, dependency, execution order và failure

Nói đơn giản hơn:

A phải xong trước B
B và C có thể chạy song song
D chỉ chạy nếu C thành công
Nếu D fail thì quay lại B
Nếu mọi thứ pass thì đi tiếp E

Đó đã là một graph rồi!

Ngày xưa node trong graph có thể là một function, một compiler task, một database job, một HTTP request hay một worker process.

Bây giờ node có thể là một AI agent tự suy nghĩ, tự dùng tools, tự sửa code, tự spawn subagents và chạy trong vài phút hoặc vài tiếng.

Cái mới nằm nhiều hơn ở chỗ này nè.

Chứ không phải ở cái graph đâu.

Tui nghĩ gọi thẳng như vậy luôn đi cho khỏe.

Graph Engineering là một buzzword.

Méo cãi được đâuuuuuu.

Nó đứng cạnh một dàn anh em khá quen thuộc:

• Prompt Engineering

• Context Engineering

• Harness Engineering

• Loop Engineering

Nhìn y như cây tiến hóa Pokémon của AI engineering :))))

Mỗi vài tháng chúng ta lại có thêm một thuật ngữ mới để diễn tả một layer abstraction mới.

Ban đầu câu hỏi là:

Viết prompt thế nào để model trả lời tốt hơn?

Rồi model mạnh hơn, agents chạy lâu hơn, câu hỏi trở thành:

Cho model thấy context nào?

Sau đó:

Cho nó tools gì? Runtime gì? Sandbox gì? Memory gì? Permissions gì?

Rồi:

Làm sao để agent tự chạy nhiều vòng, tự kiểm tra và tự sửa cho tới khi hoàn thành công việc?

Và cuối cùng:

Nếu một agent chưa đủ thì nhiều agents, tools, evaluators và human phối hợp với nhau như thế nào?

Tèn tén.

Chúng ta có…

Graph Engineering.

Cái tên mới, nhưng câu hỏi engineering phía sau nó không mới.

Công bằng mà nói là như vậy, “buzzword” cũng có ý nghĩa riêng của nó, ở đây chắc là việc nó làm cho nhiều người chú ý, tò mò & thắc mắc…

Trong giới tech có hai kiểu phản ứng rất phổ biến mỗi khi một buzzword mới xuất hiện.

Kiểu thứ nhất:

“Cái này là tương lai! Ai không học ngay sẽ bị bỏ lại!”

Kiểu thứ hai:

“Xàm. Lại là buzzword. Bỏ qua.”

Tui thấy cả hai đều hơi cực đoan. Chúng ta cần đủ sáng suốt để cân bằng việc đó.

Một thuật ngữ có thể vừa là buzzword, vừa mô tả một vấn đề engineering thật.

“Cloud”, “DevOps”, “Microservices”, “Serverless”, “Platform Engineering”... đều từng có những giai đoạn bị marketing buff lên tận mây xanh.

Nhưng điều đó không có nghĩa những ý tưởng phía sau chúng không hữu ích.

Graph Engineering cũng vậy.

Cái đáng quan tâm không phải là:

“Graph Engineering có phải một discipline hoàn toàn mới không?”

Mà là:

“Tư duy graph giúp chúng ta xây AI systems đáng tin cậy hơn ở điểm nào?”

Đây mới là câu hỏi đáng bỏ thời gian ra tìm hiểu.

Nói trước cho đỡ mất công bảo cha này phông bạt 😁

Tui là dân kỹ thuật. Có based engineer đàng hoàng.
Tui biết code từ 2006 tới giờ (à giờ thì hết rồi, AI làm hết trơn còn đâu, chịu thua 😂)

Càng không phải AI Researcher, cũng chẳng phải chuyên gia về multi-agent systems, distributed AI hay gì cao siêu hết.

Do tính chất công việc phải nghiên cứu, build và triển khai mấy hệ thống này vào project thực tế nên tui buộc phải hiểu chúng hoạt động ra sao.

Gọi là “vọc sĩ” đi thì đúng nhất, mà thôi, lại lan man rồi…

Cách tui thường tiếp cận một buzzword cũng khá đơn giản:

• Buzzword

• Bóc lớp marketing

• Tìm nguyên lý bên dưới là gì?

• Tìm xem khoa học máy tính đã giải bài toán này chưa?

• Hiểu trade-off là gì?

• Mang vào project thật như thế nào?

Một khi đi tới layer nguyên lý, rất nhiều thứ tự nhiên bớt đáng sợ.

Chúng ta sợ những gì chúng ta không hiểu mà, đúng không? 😁

“Graph Engineering” nghe như phải học thêm một ngành mới.

Nhưng bóc xuống thì chúng ta gặp lại mấy “người bạn cũ” sau:

• node

• edge

• state

• dependency

• branching

• parallelism

• loop

• retry

• checkpoint

• validation

• failure handling

Toàn từ khoá chuyên ngành engineering hết!

Nếu phải tự định nghĩa theo cách dễ hiểu nhất, tui sẽ nói:

Graph Engineering là việc thiết kế cách nhiều units of work như agents, tools, deterministic code, evaluators và humans phối hợp với nhau dưới dạng một graph có state, rules và failure boundaries rõ ràng.

(Nghe như mấy cái node trong n8n á heng? Mà hình dung như vậy cũng đúng á! n8n cũng là Graph Engineering chứ gì hehe)

Một graph cơ bản có thể nhìn như vầy:

Có ba thành phần cơ bản nhất cần hiểu trước:

Node  = ai/cái gì đang làm việc
Edge  = xong bước này thì đi đâu
State = thông tin nào được mang theo trong quá trình chạy

Nếu hiểu được ba món này thì coi như đã hiểu phần lớn cách tư duy rồi.

Phần còn lại là “engineering” cho chúng chạy ngon ngoài đời.

Node là đơn vị thực thi trong graph.

Một node có thể cực kỳ đơn giản:

read_file()

Hoặc:

call API

Hoặc:

run tests

Nhưng trong agentic systems, node có thể phức tạp hơn nhiều:

Coding Agent
    ↓
inspect repository
    ↓
reason
    ↓
edit 12 files
    ↓
run tests
    ↓
fix bugs
    ↓
result output

Tức là một node bản thân nó có thể chứa một loop hoàn chỉnh.

Nhiều người tưởng Graph Engineering thay thế Loop Engineering.

Thật ra hợp lý hơn nếu nhìn như vầy:

Một node thậm chí có thể là graph con.

Cho nên graph không nhất thiết thay loop.

Graph có thể chứa cả loop trỏng luôn.

Ví dụ một coding workflow:

Ở đây Coding Agent Loop có thể tự chạy hàng chục bước bên trong.

Graph bên ngoài chỉ quan tâm contract:

• Input là gì?

• Output là gì?

• Pass/fail thế nào?

• Được quyền làm gì?

• Chạy xong thì đi đâu?

Đây là một pattern rất mạnh.

Nó cũng chính là pattern mà mình áp dụng trong việc build workflow cho AgentKit từ đầu tới giờ, mà thật ra hồi đầu cũng có biết tên gọi khỉ đâu =))

Nếu node là “ai làm việc”, edge là:

Sau khi node này chạy xong thì chuyện gì xảy ra?

Edge đơn giản nhất là tuần tự (sequential):

A → B → C

Ví dụ:

Research → Draft → Review

Nhưng thực tế chúng ta cần nhiều dạng hơn.

(Nhìn giống Git workflow ha!)

B chỉ chạy sau khi A xong.

Đây về bản chất là conditional routing.

Ba node có thể chạy song song nếu chúng không phụ thuộc nhau.

Nhiều kết quả được gom lại trước khi bước tiếp theo chạy.

Đây chính là trạng thái loop.

Nói cách khác:

Một loop đơn giản cũng chỉ là một graph có cycle.

Thế nên tui không thích framing kiểu “Loop Engineering chết rồi, bạn còn chưa Graph Engineering sao?”.

Nghe rất đã tai nhưng về mặt kỹ thuật hơi… “lùa gà” 😆

Theo tui đây mới là phần khó nhất khi build graph thật.

Một diagram nhìn rất đẹp (AgentKit/ClaudeKit thời kỳ đầu cũng chỉ có như vầy 😂):

Planner → Coder → Reviewer

Vấn đề thật sự là:

Planner truyền cái gì cho Coder?
Coder truyền cái gì cho Reviewer?
Reviewer fail thì Coder nhận lại toàn bộ conversation hay chỉ review comments?Agent mới có được đọc mọi thứ agent trước đã đọc không?
State nào được quyền đọc/sửa?

Giả sử state của coding graph là:

issue: "Add Stripe subscriptions"
requirements:
  - monthly plan
  - annual plan
  - webhook handling
repo_commit: abc123
plan: ...
changed_files: ...
test_results: ...
review_feedback: ...
attempt: 2
budget_remaining: 48000

Mỗi node chỉ nên nhận phần state nó thực sự cần thôi.

Ví dụ:

Planner
  receives: issue + requirements
  produces: plan
Coder
  receives: requirements + plan + repository
  produces: patch + test results
Reviewer
  receives: requirements + patch + test results
  produces: approval / feedback

Nếu cứ nhét toàn bộ mọi thứ cho mọi agent thì chúng ta lại quay về một vấn đề khác:

Context Pollution (ô nhiễm ngữ cảnh, có người gọi là “Context Poisoning”)

Nghe quen không?

Graph Engineering và Context Engineering vì vậy liên quan với nhau rất chặt chẽ.

Graph quyết định ai chạy lúc nào.

Còn Context Engineering quyết định node đó được thấy cái gì khi chạy.

Giả sử Research Agent trả về:

“Theo tui thì Stripe setup kiểu này chắc được.”

• Coder lấy câu đó làm ground truth.

• Coder implement sai.

• Reviewer lại tin output của coder.

Chúc mừng, ta vừa tạo ra một dây chuyền sản xuất “hallucination” quy mô công nghiệp :))))

Graph chỉ hữu ích khi boundaries giữa các nodes rõ ràng.

Ví dụ thay vì output tự do:

research_result: một đoạn text dài 8 cây số

chúng ta có contract rõ ràng (dạng JSON):

{
  "findings": [],
  "evidence": [],
  "unknowns": [],
  "confidence": 0.82
}

Hoặc coding node phải trả:

{
  "changed_files": [],
  "tests_run": [],
  "tests_passed": true,
  "known_risks": []
}

Reviewer không approve vì coder nói “done”.

Reviewer approve vì có evidence ! ← đây rồi, đọc lại cái bài tui viết về update quan trọng này của AgentKit nha! 👇

Đây là chỗ tui nghĩ nhiều multi-agent demo nhìn rất cool ngầu nhưng méo có giá trị gì khi chạy productio…

Ae mất rất nhiều thời gian đặt tên agents:

CEO Agent
CTO Agent
Architect Agent
Senior Engineer Agent
QA Agent

Nhưng không xác định được output contract là gì.

Xong cả “công ty AI” nói chuyện với nhau rất hăng, còn task thì cô đơn trên sofa mãi méo thấy được claim là xong :))))

Trời ơi cái này tui hiểu lắm, làm cái task board cho GoClaw debug muốn lòi trĩ vụ này.

Thật ra, chữ “contract” này dịch theo kiểu loài người chúng ta thì sẽ thấy rất dễ hiểu: “hợp đồng” - làm việc giữa 2 cá thể, hay 2 thực thể (cty này vs cty kia), thì đều cần ràng buộc bằng HỢP ĐỒNG, đúng không? Khi nào xong thì mới có cơ sở làm “THANH LÝ HỢP ĐỒNG” (liquidation) mà đòi tiền được chứ :)))

Một trong những ý tưởng quan trọng nhất của Graph Engineering là:

Không phải decision nào cũng nên giao cho LLM.

Nếu test có thể kiểm tra bằng code:

npm test

thì đừng hỏi một agent:

“Bạn cảm thấy code này có chạy không?”

Nghe “cảm thấy” là thấy “vibe vibe” rồi =))

• Nếu schema có thể validate bằng JSON Schema thì validate.

• Nếu build có thể kiểm bằng compiler thì compile.

• Nếu lint có thể chạy deterministic thì chạy lint.

• …

Bài trước mình cũng đã nói đi nói lại việc này rồi:

tiếp…

Probabilistic intelligence
        +
Deterministic verification

Ví dụ:

Ở đây agent được dùng ở nơi cần reasoning.

Compiler được dùng ở nơi compiler giỏi hơn agent.

Human được giữ ở nơi cần judgment hoặc chịu trách nhiệm.

Theo tui đây mới là design ngon.

Không phải “AI everywhere”.

Mà là đặt AI zô đúng chỗ.

Vẽ graph demo thì rất dễ. Build graph chạy production đi rồi thấy cảnh :))))

Giả sử cái flow nó như sau:

Agent A → Agent B → Agent C

Agent B đang chạy thì crash.

Câu hỏi bắt đầu xuất hiện:

• Chạy lại B hay chạy lại cả graph?

• B đã gọi API tạo resource rồi thì sao?

• retry có tạo duplicate resource không?

• B đã sửa repo nhưng chưa commit thì sao?

• State đã persist chưa?

• Model provider timeout thì retry mấy lần?

• Hết budget thì graph dừng ở đâu?

Mấy câu hỏi này nghe rất “AI agent” - nhưng thực ra trong cái Github Actions nó nằm đó cả thập kỷ rồi, vẫn giải quyết mấy cái y boong.

Và mấy ông engineers xưa giờ làm distributed workflows đã vật lộn với chúng từ lâu.

Thấy thấu hiểu cho engineers thời chưa có AI chưa? :))

Một graph production cần nghĩ ít nhất về:

A done ✓
B done ✓
C crashed ✗

Resume từ C nếu có thể, thay vì:

quay lại A rồi burn credits lại từ đầu

Nếu node bị retry:

create_invoice()

thì phải tránh tạo hai invoices.

Agent sida thì không được phép suy nghĩ về ý nghĩa cuộc đời trong 11 tiếng.

max attempts
max tokens
max cost
max wall-clock time

Fail quá N lần:

Agent → Agent → Agent → Agent → Agent

không phải lúc nào cũng là giải pháp.

Đôi khi output tốt nhất là:

DỪNG LẠI -> hỏi mấy con human đi

Agent chưa đủ thông minh để làm mọi thứ đâu… quan trọng là… chúng không có chịu trách nhiệm được đâu…

Giả sử task:

“Thêm subscription billing vào SaaS hiện tại.”

Cách đơn giản nhất là giao hết cho một coding agent:

Và nói thiệt, nếu cách này chạy tốt thì ae cứ dừng ở đây.

Đừng “graph hóa cuộc đời” chỉ vì mới đọc xong mấy bài kiểu này =))

Mình chưa bao giờ là fan của cái vụ “điều phối 224 subagents” để làm nhiệm vụ gì đó, có thể trong tương lai sẽ làm được, nhưng bây giờ thì KHÔNG, rất vô nghĩa, ĐỪNG THỬ DÙ CHỈ MỘT LẦN.

Nhưng giả sử bây giờ bạn có 1 project đủ lớn:

• frontend và backend ở hai codebase

• database migration có risk

• payment flow cần security review

• docs phải update

• integration tests mất 20 phút

Lúc đó graph bắt đầu… nhìn đã đã nè 😂

Nhìn vào graph này, chúng ta có thể define rõ được:

• Không code.

• Nó chỉ phân tích dependencies và tạo task graph.

• Chạy song song.

• Mỗi scout inspect một vùng codebase và trả structured findings.

• Có thể chạy parallel sau khi interfaces được thống nhất.

• Tốt hơn nữa, mỗi agent chạy trong worktree hoặc isolated workspace riêng.

• Ghép artifacts lại.

• Resolve conflicts nếu có.

• Deterministic gate.

• Không pass thì không đi tiếp.

• Review payment flow, secrets handling, webhook verification, authorization boundaries.

• Giữ quyền quyết định cuối trước một thay đổi có blast radius lớn.

Đây mới là Graph Engineering vì nó có giá trị thực tế:

Graph phản ánh dependency và risk structure thật của công việc.

Không phải tạo “multi-agent cho ngầu chơi” đồ đâu.

Đây là cái bẫy dễ lọt vô nhất nè.

Một task ban đầu:

Fix typo in README

Sau khi đọc quá nhiều bài về agents của các khầy trên mạng:

Thôi xin :))))

Bay ngay 8M tokens rồi ngồi than sao nay usage limit tụt nhanh thế…

Multi-agent systems có một hidden cost rất lớn: coordination.

Mỗi lần thêm node, chúng ta thêm:

• thêm context transfer

• thêm latency

• thêm tokens

• thêm failure point

• thêm state cần quản lý

• thêm khả năng agents hiểu sai nhau

• thêm observability requirement

• thêm debugging surface

Nếu một agent làm được trong 30 giây, không cần tạo 7 agents để hoàn thành trong 4 phút với chi phí gấp 12 lần rồi viết blog gọi đó là “enterprise-grade agent swarm” - nghe mắc ẻ lắm =))

Một rule rất hữu ích theo tui là:

Start with one agent loop.
Chỉ split thành graph khi có một boundary thật sự.

(Mấy cái này tui cũng học được trong mấy tháng qua khi làm việc ở dự án GoClaw, quá nhiều kiến thức hữu ích!)

Boundary đó có thể là:

• Task B thật sự cần output của A.

• A, B, C độc lập và chạy song song giúp giảm thời gian đáng kể.

• Một agent không nên phải ôm context của cả hệ thống.

• Researcher chỉ được đọc web.

• Coder được sửa repo.

• Deployment node mới có production credentials.

• Node này fail không nên làm toàn workflow fail theo.

• Một model mạnh về reasoning làm planning.

• Một model rẻ hơn xử lý mechanical tasks.

• Một số quyết định cần người thật approve.

• Nếu không có boundary nào trong số này, rất có thể graph đang là một khu phức hợp hỗn loạn...

Nếu học Graph Engineering mà chỉ học: node, edge, graph thì cũng hơi phí.

Cái đáng học là các nguyên lý computer science nằm bên dưới.

Nhưng mà thường thì mấy cái này khó khô khan buồn ngủ, ngta thích nghe mấy cái thuật ngữ fancy lấp lánh hơn, nhỉ? :))

Học cách biểu diễn valid states và transitions.

PENDING
  ↓
RUNNING
 ↙    ↘
FAIL  SUCCESS

Nó giúp system không đi vào những trạng thái vô nghĩa.

• Hiểu upstream/downstream dependency.

• Biết khi nào có thể chạy song song và khi nào buộc phải chờ.

• Các workers độc lập giao tiếp qua “messages” thay vì cùng đụng một đống mutable state.

• Cách tư duy này rất hợp với multi-agent systems.

• Scheduling, retry, timeout, branching, signals, human-in-the-loop.

• Đây là bài toán mà n8n, Airflow và rất nhiều workflow systems đã giải từ trước AI agents.

• Latency, partial failure, concurrency, idempotency, ownership, consistency.

• Một remote agent cũng chỉ là một distributed component.

• Long-running agent bị crash thì resume ở đâu?

• State tồn tại thế nào?

• Retry semantics ra sao?

• Graph thật sự chạy đường nào?

• Node nào tốn tiền?

• Node nào retry nhiều nhất?

• Agent nào là bottleneck?

• Một agent không nhìn thấy được là một agent méo thể improve được :))

• Thứ quyết định graph có tốt hay không.

• Không có eval thì việc thêm graph, agent hay prompt mới chủ yếu dựa trên cảm tính. Chẳng biết đâu là đúng / sai.

Nói chung là:

Graph Engineering
=
workflow orchestration + state machines + distributed systems + dependency management + verification + AI agents

Nếu graph xưa như trái đất rồi thì vì sao tới 2026 mới thấy người ta nói “Graph Engineering”?

Tui đoán vầy:

Ngày trước LLM call thường là:

input -> generate text -> output

Hết fim.

Graph chủ yếu orchestration nhiều LLM calls nhỏ.

Bây giờ một node có thể là:

Coding Agent -> plan -> search repository -> run shell commands -> spawn subagent -> validate -> return artifact

Tức là độ chi tiết của node đã lớn hơn rất nhiều.

Chúng ta không còn chỉ điều phối bằng prompts.

Mà đang điều phối cả những autonomous workers cmnr…

Đây là thay đổi đáng kể nhất.
Cuối năm ngoái dự đoán cuối 2026 có Agent Fleet, giờ thành sự thật thiệt, còn sớm hơn nữa… công nghệ giờ đi với tốc độ ánh sáng luôn!

—

Khi task đủ lớn, một agent phải giữ:

• quá nhiều context

• quá nhiều responsibilities

• quá nhiều permissions

• quá nhiều tools

• quá nhiều objectives

Tới một mức nào đó, việc chia nhỏ thành specialists hoặc isolated workers bắt đầu hợp lý.

Không khác software architecture là mấy.

Một function 8,000 dòng rồi thì chia module không phải vì “module-driven engineering” đang trend.

Mà vì cái cục đó bắt đầu khó quản lý.

Ae engineer ra rả nhau cái vụ viết code mô-đun hoá để dễ maintainable phát ngấy suốt chục năm qua đó thôi…

—

Nếu ba tasks độc lập mất mỗi task 10 phút:

sequential = 30 phút
parallel = khoảng 10 phút + coordination overhead

Khi inference và infrastructure cho phép chạy nhiều agents đồng thời, graph trở thành cách tự nhiên để mô hình hóa parallel work.

—

Một autonomous agent hoàn toàn tự do rất linh hoạt.

Nhưng flexibility và predictability thường kéo ngược nhau.

more autonomy
    ↑
flexibility
    ↑
variance
    ↑
debugging difficulty

Graph cho phép chúng ta nói:

Đoạn này agent tự quyết nè.
Đoạn này bắt buộc đi qua validator nè.
Đoạn này phải hỏi human nè.
Đoạn này không được có production permission nè.

Đại loại là như thế.

Nó trộn lẫn giữa phán đoán và tất định (determinism).

Model ngày càng mạnh và ngày càng giống commodity hơn ở application layer.

Khác biệt của một sản phẩm agent tốt không chỉ nằm ở:

model nào?

mà ngày càng nằm ở:

model được đặt trong system nào?
context nào?
tools nào?
loop nào?
evals nào?
permissions nào?
graph nào?

Đó là lý do hết Prompt Engineering tới Context Engineering, Harness Engineering, Loop Engineering rồi Graph Engineering lần lượt xuất hiện.

Không hẳn vì mấy khứa trên X thích đẻ thuật ngữ mới.

À mà cái đó cũng có :))))

Nhưng sâu hơn là vì cái vụ AI engineering thật sự đang lớn dần rồi.

Đây là suy đoán cá nhân của tui.

Giai đoạn đầu của generative AI tạo cảm giác rằng software engineering truyền thống sắp trở nên bớt quan trọng.

• Prompt vài câu là có code.

• Model càng ngày càng giỏi.

• “AI sẽ tự làm hết.”

Có thể.

Nhưng càng đẩy agents vào production, chúng ta càng đụng lại mấy vấn đề y như cũ: state, permissions, transactions, concurrency, failure, recovery, observability, security, cost, latency, interfaces, contracts,…

Tức là trí khôn của AI tăng lên không làm engineering biến mất.

Nó chuyển engineering sang một lé-vồ (level) khác :)))

Ngày trước engineer phải tự viết từng function, từng module, từng UI.

Bây giờ có thể engineer sẽ dành nhiều thời gian hơn để thiết kế:

• agent boundaries

• execution topology

• context boundaries

• verification gates

• state transitions

• failure recovery

Như một Solution Architect thiên về kiến trúc AI system.

Tui thấy chuyện này khá zui à nha.

Vì cuối cùng chúng ta đi một vòng rất xa, rồi gặp lại Distributed Systems, State Machines và Software Architecture đứng đó cười :))))

Bởi vì có thể đây là một cú “come back” ngoạn mục của những “engineer thực thụ” còn trụ vững tới giờ này mà chưa nản bỏ nghề + chịu khó tìm tòi về AI =))))

Anyway, chỉ là suy đoán thôi, hehe.

Bài dài quá, gõ từ 3PM tới 6PM thao thao bất tuyệt tui cũng hơi mỏi tay rồi :))))

Ps. có sự trợ giúp của Claude & Codex trong quá trình research, tạo ảnh minh hoạ (và tóm gọn bên dưới) 😁

Tóm gọn lại:

1. Graph Engineering không mới

2. Graph Engineering đúng là buzzword

3. Graph không thay thế loop

4. Ba nguyên lý cần hiểu trước
   Node = ai/cái gì làm việc

   Edge = tiếp theo đi đâu

   State = thông tin nào được mang theo

   Rồi mới mở rộng sang branching, parallelism, retry, checkpoint, evaluators và human gates.

5. Boundary quan trọng hơn số lượng agents

6. Verification quan trọng hơn orchestration đẹp

7. Bắt đầu đơn giản: đừng bắt đầu bằng 18 agents rồi mới đi tìm vấn đề để chúng giải quyết.

8. Thứ thật sự đáng học là engineering phía sau

   Học mấy món đó thì dù năm sau Twitter đổi tên Graph Engineering thành Agent Topology Engineering Ultra Pro Max chúng ta vẫn không cần học lại từ đầu :))))

Model có thể thay đổi mỗi vài tháng.
Framework có thể hot năm nay rồi biến mất năm sau.
Buzzword chắc chắn sẽ còn đẻ thêm (sure luôn!)

Nhưng mấy nguyên lý engineering thì vẫn nằm đó, y xì không thay đổi, mà nó là nền tảng còn khuya mới biến mất được.

Hiểu được mấy cái gốc này, còn lại chủ yếu là implementation details.

Hiểu được mấy cái gốc này, hết sợ! haha

(*) Disclaimer: Đây là cách tui hiểu và diễn giải Graph Engineering dưới góc nhìn của một người làm kỹ thuật và ứng dụng AI systems vào công việc thực tế. Có thể đúng, có thể sai, và chắc chắn còn nhiều góc nhìn khác. Anh em có thêm tài liệu hoặc trải nghiệm hay thì cứ góp ý để cùng học nghen!