Dạo này đi đâu cũng nghe nhắc tới “Graph Engineering”, như thể đây là một ngành kỹ thuật mới toanh. Nhưng nhìn kỹ lại, cụm từ này đang được dùng cho hai thứ khác nhau. Một là graph để biểu diễn ngữ cảnh, tri thức, tài liệu, giúp AI biết cái gì liên quan tới cái gì. Hai là graph để định nghĩa và điều phối luồng thực thi cho agent, kiểu LangGraph, áp dụng cho cả một quy trình kỹ thuật phần mềm thay vì một tác vụ đơn lẻ. Hiện tại với cách chúng tôi đang làm, với workflow.yaml và agent orchestrator, thật ra cũng đang làm việc thứ hai này, dù không gọi bằng tên đó. Bài viết này tách bạch hai nghĩa, đi sâu vào từng nghĩa, và nêu quan điểm cá nhân về cách gọi tên phù hợp hơn.
1. “Graph Engineering” là graph nào?
Câu hỏi đầu tiên đáng hỏi: “Graph Engineering” có phải một ngành riêng không? Câu trả lời ngắn gọn của tôi là: không hẳn, và còn tuỳ nghĩa nào. Nếu tách bạch ra thì ngành công nghệ AI hiện đang xoay quanh bốn “lớp” kỹ thuật, xây chồng lên nhau như bốn tầng của một cái tháp. Prompt engineering là tầng thấp nhất, lo chuyện viết một câu lệnh cho thật rõ ràng, đúng ý. Context engineering là tầng quyết định model được “nhìn thấy” cái gì, kiến thức nào, dữ liệu nào, cấu trúc ra sao trước khi nó trả lời. Harness engineering lo phần “sân chơi” cho AI hoạt động: công cụ, bộ nhớ, cơ chế phản hồi. Và loop engineering là tầng trên cùng, thiết kế cái vòng lặp quan sát, hành động, kiểm tra, sửa sai, để AI có thể tự chạy mà không cần người nhắc từng bước.
Vậy graph nằm ở đâu trong bốn tầng này? Câu trả lời phụ thuộc vào nghĩa nào của graph đang được nói tới. Nếu graph là cách biểu diễn ngữ cảnh, dữ liệu (nghĩa 1), nó chỉ là một kỹ thuật nằm trong context engineering, không xứng đứng ngang hàng với bốn tầng ở trên, giống như gọi “viết SQL” là một ngành riêng ngang với backend engineering vậy. Nhưng có một nghĩa khác của graph đang rộ lên gần đây, khoảng giữa tháng 7/2026: graph như cách điều phối nhiều agent hay nhiều loop cùng lúc, kiểu LangGraph, được không ít người coi là hẳn một tầng thứ năm, nằm ngay trên loop engineering. Đây là nghĩa 2, không liên quan gì tới context.
Ba cách để đưa ngữ cảnh vào cho AI
Bên trong tầng context engineering, có ba cách chính để tìm và định hình thông tin. Không cách nào thay thế được cách nào, mỗi cách hợp với một loại nội dung khác nhau. Chọn sai chỗ là lỗi phổ biến nhất tôi thấy các team hay mắc.
| Cách | Là gì | Hợp với |
|---|---|---|
| Graph có cấu trúc | Nối các thứ lại với nhau bằng liên kết rõ ràng, có thể là cấu trúc dự án của tôi, hoặc entity rút ra từ tài liệu (GraphRAG). | Trả lời “cái này liên quan gì tới cái kia”, “đổi cái này thì cái gì bị ảnh hưởng”. |
| Agentic search | Grep, duyệt cây thư mục, tra symbol, chạy trực tiếp trên mã nguồn thật. | Mặc định cho code. Luôn chính xác, không bao giờ lỗi thời vì chẳng có gì được xây trước để mà lỗi thời. |
| Vector RAG | Embedding và so khớp theo nghĩa. | Văn bản ít thay đổi: RFP, chính sách, tài liệu kiến thức, nơi ý nghĩa quan trọng hơn từ ngữ chính xác. |
Hai nghĩa của “graph”, tóm tắt trong một bảng
Đây là chỗ dễ nhầm lẫn nhất. “Graph Engineering” đang bị dùng cho hai thứ không liên quan gì tới nhau ngoài việc cùng là một cấu trúc node và edge. Bảng dưới đây là phép thử nhanh: gặp ai nhắc “graph engineering”, hỏi luôn họ đang nói nghĩa nào.
| Nghĩa 1: Graph ngữ cảnh / tri thức | Nghĩa 2: Graph điều phối (workflow, kiểu LangGraph) | |
|---|---|---|
| Node là gì | Một thực thể tĩnh: Story, Module, Test Case, Document, Person, Topic… | Một agent chuyên trách hoặc một bước xử lý: researcher, writer, reviewer, hoặc một skill/tool call. |
| Edge là gì | Một quan hệ tĩnh giữa hai thực thể: traces_to, depends_on, mentions… | Một đường điều khiển luồng chạy: tuần tự, rẽ nhánh theo điều kiện, hoặc quay vòng lại khi chưa đạt. |
| Trả lời câu hỏi | “Cái này liên quan gì tới cái kia?”, “đổi cái này thì gãy chỗ nào?” | “Bước tiếp theo là gì?”, “ai làm việc này?”, “khi nào được đi tiếp, khi nào phải quay lại?” |
| Khi nào graph “chạy” | Graph là dữ liệu tĩnh, được đọc để lấy ngữ cảnh trước khi model trả lời. Bản thân graph không tự thực thi. | Graph được một runtime duyệt qua thật sự lúc chạy, quyết định node nào chạy kế tiếp, có thể lặp lại một node nhiều lần. |
| Nằm ở tầng nào | Bên trong context engineering (tầng 2 trong bốn tầng ở trên), đứng cạnh agentic search và vector RAG. | Một tầng riêng, nằm bên trên loop engineering: mỗi node bên trong vẫn chạy một loop, nhưng graph quyết định các loop đó nối với nhau ra sao. |
| Công cụ tiêu biểu | context-graph.yaml tự viết tay, GraphRAG, Graphify, Understand-Anything. | LangGraph, Microsoft AutoGen GraphFlow, Google ADK, và (theo tôi) chính workflow.yaml cộng orchestrator của Amplify SDLC Kit. |
Mục 2 ngay sau đây đi sâu vào nghĩa 1. Mục 3 nói riêng về nghĩa 2, đàng hoàng và đủ chi tiết, thay vì nhét chung vào rồi lại gây hiểu lầm thêm một lần nữa.
2. Graph ngữ cảnh và tri thức (nghĩa 1)
Đây là nghĩa quen thuộc hơn: dùng graph để biểu diễn ngữ cảnh và tri thức, giúp AI trả lời được những câu hỏi mà tìm kiếm thông thường không trả lời nổi.
Graph cấu trúc dự án và GraphRAG
Nói tới graph, thực ra người ta đang gộp chung hai thứ khác nhau. Một graph đơn giản là một tập các node có kiểu (như Story, Module, Test Case, ADR, Skill) nối với nhau bằng các edge có kiểu (như implements, depends_on, traces_to, constrains, owns). Ý tưởng không có gì phức tạp. Nhưng trong thực tế, nó xuất hiện dưới hai dạng, và tách bạch ra sẽ dễ nói chuyện với nhau hơn.
| Graph cấu trúc dự án | GraphRAG (graph tri thức từ tài liệu) | |
|---|---|---|
| Map cái gì | Codebase và các sản phẩm bàn giao của chính dự án: story, requirement, module, test, quyết định thiết kế. | Entity và relationship rút ra từ một tập tài liệu hay kho tri thức. |
| Dùng để làm gì | Phân tích tác động, truy vết, hỗ trợ người mới. Ví dụ: “sửa cái này thì gãy chỗ nào?”, “story này được test bởi gì?”, “module này bị ràng buộc bởi quyết định nào?” | Trả lời câu hỏi trải rộng trên nhiều tài liệu, nơi câu trả lời phải ghép thông tin từ nhiều nơi. Ví dụ: “người này liên quan gì tới dự án kia?” |
| Quy mô thường thấy | Nhỏ: vài trăm node, cập nhật theo nhịp sprint. | Có thể rất lớn, phục vụ truy xuất trên khối lượng văn bản lớn. |
| Xây bằng cách nào | Chủ yếu phân tích tĩnh (static analysis) cộng thêm chút chỉnh tay. | Trích xuất entity bằng LLM, gộp trùng lặp, nối relationship, rồi ép theo schema. |
Xây graph nào thì cũng chỉ có ba việc phải làm
Dù là graph cấu trúc dự án hay GraphRAG, quy trình xây dựng đều quy về ba việc giống nhau.
| Việc | Nghĩa là gì | Ví dụ đơn giản |
|---|---|---|
| 1. Thiết kế schema | Chọn loại node và loại edge trước tiên, dựa trên câu hỏi thật sự cần trả lời. Đừng mô hình hoá thứ mà tôi sẽ chẳng bao giờ hỏi tới. | Nếu không bao giờ hỏi “ai đang phụ trách cái này?”, thì chưa cần edge owns vội. |
| 2. Đổ dữ liệu vào | Lấy các relationship vào graph, thường phối hợp ba nguồn: phân tích tĩnh cho liên kết chính xác trong code, LLM trích xuất cho liên kết nằm trong văn bản, và con người chỉnh tay cho những chỗ cần phán đoán. | Import trong code lấy từ phân tích tĩnh; “ADR này ảnh hưởng module kia” có khi cần người xác nhận. |
| 3. Giữ cho graph luôn mới | Định kỳ kiểm tra lại graph so với thực tế. Đây là việc các team hay bỏ qua nhất, mà lại là việc quan trọng nhất. | Một graph không ai kiểm tra lại sẽ âm thầm trở thành một câu chuyện nghe có vẻ đúng nhưng sai bét. |
Các loại node
| Node | Đại diện cho | Trường dữ liệu chính |
|---|---|---|
| Story | Một hạng mục công việc. | id, title, status, sprint |
| Requirement | Điều hệ thống phải làm được. | id, text, priority |
| Module | Một thành phần trong code. | id, name, path |
| Test Case | Một phép kiểm tra hành vi. | id, name, result |
| ADR | Một quyết định kiến trúc. | id, title, status |
| Skill | Một automation tái sử dụng được. | id, name, purpose |
Các loại edge
Mỗi edge chỉ nên tồn tại nếu nó trả lời được một câu hỏi thật.
| Edge | Nối gì với gì | Trả lời câu hỏi |
|---|---|---|
| traces_to | Story → Requirement | Story này đáp ứng requirement nào? |
| realizes | Module → Story | Code nào hiện thực hoá story này? |
| verifies | Test Case → Story | Test nào đang phủ story này? |
| depends_on | Module → Module | Đổi module này thì gãy chỗ nào? |
| constrains | ADR → Module | Quyết định nào đang ràng buộc thành phần này? |
| owns | Skill → Artifact | Automation nào đang bảo trì cái này? |
Ra file thật thì trông như vầy
Với một graph dự án nhỏ, một file phẳng là đủ dùng. Không cần database gì cả.
# context-graph.yaml (trích đoạn)nodes: - id: STORY-14 type: Story title: "Reset mật khẩu qua email" status: in_progress - id: REQ-3 type: Requirement text: "Người dùng tự khôi phục truy cập, không cần support" - id: MOD-auth type: Module path: src/auth/edges: - from: STORY-14 rel: traces_to to: REQ-3 - from: MOD-auth rel: realizes to: STORY-14meta: last_checked: 2026-07-20 # dấu hiệu tin cậy
Giữ nó tinh gọn: bắt đầu với hai, ba loại edge tôi truy vấn nhiều nhất, thêm ngày last_checked, và chỉ mở rộng schema khi có câu hỏi mới thật sự cần tới.
Schema GraphRAG
Khi trích xuất entity và relationship từ một tập tài liệu (cách làm của GraphRAG) và quyết định lưu chúng vào một graph database, schema chính là thứ giữ cho kết quả có thể truy vấn được, thay vì trở thành một mớ bòng bong. Đây là hình mẫu khởi điểm cho entity và relationship rút ra từ một tài liệu hay kho tri thức.
Các loại entity (node)
| Entity | Đại diện cho | Trường dữ liệu chính |
|---|---|---|
| Document | Một file nguồn hay bài viết. | id, title, source, date |
| Chunk | Một đoạn văn bản trong tài liệu, giữ lại để truy vết ngược về nguyên văn. | id, text, embedding |
| Person | Một cá nhân có tên. | id, name, role |
| Organization | Một công ty hoặc team. | id, name, type |
| Topic | Một chủ đề hay khái niệm. | id, label |
| Event | Một sự kiện xảy ra tại một thời điểm. | id, name, date |
Các loại relationship (edge)
| Relationship | Nối gì với gì | Ý nghĩa |
|---|---|---|
| part_of | Chunk → Document | Đoạn văn này thuộc tài liệu đó. |
| mentions | Chunk → Person / Org / Topic | Đoạn văn này nhắc tới entity đó. |
| authored_by | Document → Person | Ai là người viết. |
| works_for | Person → Organization | Trực thuộc tổ chức nào. |
| related_to | Topic → Topic | Các khái niệm liên quan tới nhau. |
| occurred_on | Event → Date | Xảy ra khi nào. |
// entity(d:Document {id:"DOC-42", title:"Đánh giá đối tác Q2", date:"2026-04-11"})(p:Person {id:"PER-7", name:"A. Nguyễn", role:"Trưởng nhóm"})(o:Org {id:"ORG-2", name:"Acme Health"})(t:Topic {id:"TOP-9", label:"chuyển đổi dữ liệu"})// relationship(d)-[:AUTHORED_BY]->(p)(p)-[:WORKS_FOR]->(o)(d)-[:MENTIONS]->(t)// một câu hỏi schema này giờ trả lời được trong một, hai hop:// "tổ chức nào đang liên quan tới chuyển đổi dữ liệu?"
Graph được xây theo trình tự nào
Pipeline chạy theo thứ tự này, và bỏ qua một bước là lý do phổ biến nhất khiến một pilot ban đầu làm người ta thất vọng.
- Trích xuất entity từ văn bản thô bằng LLM.
- Gộp trùng lặp để cùng một entity được gọi tên khác nhau trở thành một node duy nhất. Bỏ qua bước này là nguyên nhân phổ biến nhất khiến kết quả ban đầu tệ.
- Liên kết các relationship giữa những entity đã được gộp.
- Ép theo schema để dữ liệu mới luôn đúng loại node, loại edge đã định, không phải nhiễu tự do.
Vậy có thật sự cần một graph database không?
Thường là không cần. Graph chỉ là node và edge, còn graph database chỉ là một cách để lưu chúng. Chỉ nên tính tới một graph database thật sự (hay cả pipeline GraphRAG) khi một trong các điều sau đúng:
- Câu hỏi cần duyệt multi-hop thật sự, mà nếu làm bằng join lặp đi lặp lại thì rất cực.
- Graph quá lớn, không thể nhét vừa vào context window hay một lần truy vấn.
- Cần các thuật toán graph có sẵn như shortest path, community detection.
- Nhiều agent hoặc hệ thống cùng đọc và ghi vào một graph đang thay đổi liên tục.
Còn nếu không cần database, thì lưu graph kiểu gì?
Node và edge mới là điều quan trọng, còn cách lưu chỉ là chi tiết kỹ thuật. Nếu không rơi vào bốn trường hợp ở trên, một trong các lựa chọn nhẹ nhàng sau thường là đủ, và tất cả vẫn giữ nguyên schema y như trên.
| Lựa chọn | Trông như thế nào | Truy vấn ra sao | Hợp khi nào |
|---|---|---|---|
| File phẳng (YAML / JSON) | Một danh sách node và edge, commit thẳng vào git cạnh code. | Load cả file, lọc bằng một script ngắn, hoặc đưa thẳng vào context của model. | Vài trăm node, cập nhật theo nhịp sprint. Dễ đọc, dễ so sánh diff. |
| Bảng quan hệ (relational) | Một bảng source, relationship, target trong database tôi đã có sẵn (ví dụ Postgres). | SQL thuần. Mỗi hop là một self-join. | Đã có sẵn database quan hệ và ít khi cần hơn một, hai hop. |
| Graph trong bộ nhớ (in-memory) | Xây lại từ nguồn mỗi lần chạy, giữ trong một đối tượng graph, rồi bỏ đi. | Duyệt bằng code (ví dụ thư viện nhỏ như networkx). | Xây lại rẻ, không cần lưu lại giữa các lần chạy. |
| Vector store và metadata | Các đoạn tài liệu vẫn nằm trong vector store bình thường; liên kết entity nằm trong metadata của đoạn đó hoặc một bảng phụ nhỏ. | Vector search tìm ra đoạn văn, rồi tra metadata để lần theo liên kết. Đây là kiểu “GraphRAG-lite”. | Muốn phần lớn lợi ích “nối các điểm lại với nhau” của GraphRAG mà không cần dựng graph database. |
Có cần nhúng (embed) toàn bộ code vào vector store không?
Không cần, và với code thì cả ngành đang đi ngược lại với những gì mọi người hay mặc định. Claude Code và các công cụ tương tự không hề dựng sẵn một index nào cả. Chúng duyệt hệ thống file, đọc file, grep đúng thứ cần tìm, và lần theo tham chiếu, y như một kỹ sư thật sự làm, tất cả chạy tại chỗ, không cần index nào phải xây, bảo trì, hay upload lên đâu cả.
Vì sao embed toàn bộ codebase là rủi ro
Các công cụ dùng vector sẽ embed code và lấy các đoạn theo độ tương đồng lúc truy vấn. Với một team đang code liên tục, pipeline embed không theo kịp, nên một câu truy vấn có thể trả về một hàm đã bị đổi tên hai tuần trước, hoặc một module đã bị xoá từ sprint trước, mà chẳng có gì báo hiệu là nó đã lỗi thời. Chính đội ngũ Anthropic từng chia sẻ rằng bản đầu của Claude Code có thử dùng vector database, và nhận ra agentic search hoạt động tốt hơn hẳn khi thử nghiệm thật, một kết quả mà chính họ cũng thấy bất ngờ.
Vậy Claude dùng gì thay vào đó?
| Cơ chế | Vai trò |
|---|---|
| CLAUDE.md / bản đồ repo | Chỉ cho agent đúng thư mục cần nhìn trước khi bắt đầu. |
| Grep trực tiếp | Khớp chính xác trên cây thư mục hiện tại, không bao giờ lỗi thời. |
| Tra symbol (LSP) | Lọc theo symbol thật, để một tên hàm phổ biến không trả về hàng trăm kết quả sai. |
| MCP server | Kết nối tới công cụ nội bộ, ticket, tài liệu, hoặc để tự expose search như một tool gọi được. |
| Subagent | Giữ cho một lần tìm kiếm lớn không làm rối context của agent đang thực sự làm việc. |
Vậy vector retrieval có còn chỗ đứng không?
Không phải “RAG đã chết”. Khi tôi không biết chính xác tên của thứ cần tìm, hoặc từ ngữ trong spec không khớp với từ ngữ trong code, một index theo nghĩa sẽ tìm ra thứ mà grep không thể. Đó chính xác là thứ embedding sinh ra để làm, và văn bản tự nhiên thay đổi chậm, nên vấn đề lỗi thời gần như không đáng lo ở đây.
| Loại nội dung | Cách tiếp cận mặc định | Vì sao |
|---|---|---|
| Code và repo có cấu trúc | Agentic search trước (bản đồ repo, grep, symbol). Chỉ thêm index ngữ nghĩa khi có một điểm đau cụ thể. | Khớp chính xác thắng khớp mờ, và lỗi thời là rủi ro thật trên một repo đang hoạt động. |
| Kho văn bản (RFP, BRD, slide, blog) | Kết hợp tìm theo từ khoá và vector, có rerank. | Ý nghĩa quan trọng hơn từ ngữ chính xác, và nội dung thay đổi chậm. |
| Relationship giữa các artifact | Ngữ cảnh dạng graph, không phải search hay embedding. | Chỉ một graph rõ ràng mới trả lời được “cái này phụ thuộc vào cái gì”. |
Khi nào nên thêm tra symbol hay công cụ search: khi grep thường bắt đầu trả về nhiều kết quả sai cho những tên phổ biến, hoặc khi onboard vào repo mất nhiều thời gian hơn mức chỉ đọc một bản đồ repo nên mất. Đó là dấu hiệu agentic search một mình đã chạm trần.
Còn mấy công cụ như Graphify hay Understand-Anything thì sao?
Cả hai đều là công cụ mã nguồn mở (giấy phép MIT), gắn thêm vào các trợ lý code AI như Claude Code, Cursor, Copilot. Chúng quét một dự án, dựng một knowledge graph bền vững gồm file, hàm, class, và dependency, rồi cho phép trợ lý truy vấn graph hoặc dò đường đi thay vì grep từng file thô. Graphify nói rõ họ “không phải vector index, không embedding, mà là một graph thật sự có thể duyệt được”, xây chủ yếu từ cây cú pháp (syntax tree) cộng thêm một ít trích xuất bằng LLM, commit kết quả vào git, và có thể đẩy tuỳ chọn sang Neo4j. Understand-Anything làm tương tự và có thêm một dashboard tương tác để khám phá graph.
Nói theo ngôn ngữ ở phần trên, hai công cụ này chính là graph cấu trúc dự án, chỉ khác là được đóng gói sẵn để cài vào, thay vì tôi tự xây tay. Nên câu trả lời thành thật là “còn tuỳ”, và cái được, cái mất đáng nói thẳng ra như sau:
| Điểm được | Điểm cần cân nhắc |
|---|---|
| Cho câu trả lời multi-hop và phụ thuộc (“cái này nối gì với cái kia”) mà grep một mình không làm được, mà tôi không cần tự thiết kế schema từ đầu. | Đây là thêm một artifact nữa phải xây, giữ mới, và tin tưởng. Một graph bị cũ còn tệ hơn không có graph, đó là lý do cả hai đều dựa vào git hook để tự xây lại. |
| Phần lõi dựa trên cây cú pháp (deterministic) giữ cho phần lớn graph là sự thật, không phải đoán mò. | Lớp trích xuất bằng LLM vẫn tốn token và có thể tạo nhiễu, cả hai dự án còn khá non trẻ với đội duy trì nhỏ. |
| Giấy phép MIT, commit được vào git, để cả team cùng xuất phát từ một bản đồ chung. | Thêm bất kỳ công cụ AI của bên thứ ba nào cũng là một quyết định về chuỗi cung ứng và quản trị. Nên rà soát kỹ (ví dụ bằng một lượt quét độ tin cậy repo) trước khi dùng. |
Tóm lại: với phần lớn công việc tìm kiếm code hàng ngày, các cách làm ở mục Claude dùng gì thay vào đó (bản đồ repo, grep trực tiếp, tra symbol) đơn giản hơn, miễn phí, và không bao giờ lỗi thời, nên hãy bắt đầu từ đó. Xem một công cụ graph như một thử nghiệm có phạm vi rõ ràng, dành cho trường hợp cụ thể là câu hỏi phụ thuộc và tác động xuất hiện thường xuyên, và việc onboard đang thật sự đau đầu, chứ đừng coi nó là nâng cấp mặc định. Nếu có thử, hãy tính luôn chi phí bảo trì, và xác nhận lợi ích về độ chính xác là có thật trước khi phụ thuộc vào nó.
Vậy dự án ngắn hạn, nhỏ và dự án dài hạn, lớn thì có khác nhau không?
Có, cách làm nên thay đổi theo quy mô và thời gian sống của dự án.
| Dự án ngắn hạn, quy mô nhỏ | Dự án dài hạn, quy mô lớn | |
|---|---|---|
| Tìm kiếm code | Chỉ cần agentic search: bản đồ repo, grep, tra symbol. Không cần index dựng sẵn, không cần công cụ graph. | Vẫn agentic search làm nền, thêm tra symbol khi grep bắt đầu nhiễu, và dùng subagent để tìm kiếm lớn không làm rối context chính. |
| Graph cấu trúc | Bỏ qua, hoặc chỉ cần một file nhỏ tự viết tay nếu thật sự cần câu trả lời về phụ thuộc. | Đáng để đầu tư một graph được commit, tự cập nhật (tự xây tay hoặc dùng công cụ như trên) để phân tích tác động và giúp người mới onboard nhanh hơn. |
| Tài liệu | Đọc trực tiếp, hoặc search từ khoá đơn giản là đủ. | Kết hợp tìm từ khoá và vector trên các kho tài liệu thay đổi chậm (RFP, chính sách, kho tri thức). |
| Nơi dồn công sức | Giữ mọi thứ tinh gọn, tránh dựng hạ tầng mà tôi sẽ không bảo trì nổi. | Đầu tư vào vòng lặp bảo trì và kiểm tra định kỳ, vì đó mới là thứ giữ cho bất kỳ index hay graph nào còn đáng tin theo thời gian. |
3. Graph điều phối workflow, kiểu LangGraph (nghĩa 2)
Nghĩa này không nói về việc model nhìn thấy dữ liệu gì. Nó nói về một chuyện khác: khi một công việc lớn cần nhiều agent chuyên trách nối tiếp nhau (một agent nghiên cứu, một agent viết, một agent phản biện, một bước quyết định đi tiếp hay quay lại sửa), thì lấy gì để định nghĩa thứ tự chạy, điều kiện rẽ nhánh, và dữ liệu dùng chung giữa các agent đó? Câu trả lời đang thịnh hành: vẽ nó ra thành một graph, node là từng agent hay từng bước, edge là luồng điều khiển, và một “state” chạy dọc theo các edge mang theo mọi thứ agent sau cần biết.
Chuyện này mới rộ lên từ đâu
Cụm từ “Graph Engineering” theo nghĩa này nổi lên trên X (Twitter) chỉ trong vài ngày, khoảng 18-19 tháng 7 năm 2026, sau một câu hỏi ngắn của Peter Steinberger, người tạo OpenClaw: “Are we still talking loops or did we shift to graphs yet?”. Sau đó nhiều người, đáng chú ý là các bài phân tích tổng hợp trên AI Builder Club và Eigent, đóng khung nó thành tầng thứ năm, ngay trên loop engineering: prompt (tầng 1, viết đúng câu lệnh), context (tầng 2, model thấy gì), harness (tầng 3, công cụ và bộ nhớ), loop (tầng 4, một agent tự lặp quan sát, hành động, kiểm tra), và giờ graph (tầng 5, điều phối nhiều agent hoặc nhiều loop cùng lúc). Ẩn dụ được nhắc nhiều nhất trên X: agent đang “tốt nghiệp” từ vòng lặp while-loop lên thành sơ đồ tổ chức (org chart), mỗi agent một vai trò chuyên biệt, việc được luân chuyển giữa các vai trò, kết quả được gộp ngược lại.
Một graph điều phối trông như thế nào
Ba thành phần, không hơn không kém.
| Thành phần | Là gì | Ví dụ |
|---|---|---|
| Node | Một agent chuyên trách hoặc một bước xử lý xác định, mỗi node chỉ làm một việc. | Agent nghiên cứu, agent viết, agent phản biện, hoặc đơn giản là một tool call. |
| Edge | Đường điều khiển luồng chạy: nối thẳng, rẽ nhánh theo điều kiện, tách ra chạy song song rồi gộp lại, hoặc quay vòng lại một node trước đó. | “Nếu bài viết đạt yêu cầu thì xuất bản, nếu không thì quay lại cho agent viết sửa.” |
| State dùng chung | Một đối tượng dữ liệu đi theo edge, mỗi node đọc vào và ghi thêm vào đó. | Nhiệm vụ ban đầu, ghi chú nghiên cứu, bản nháp, kết quả chấm điểm, tất cả cộng dồn qua từng node. |
Có một cách nhìn hay đáng nhớ: một loop chẳng qua là một graph chỉ có một node, với một edge quay ngược lại chính nó. Mọi thứ đã biết về thiết kế loop (chu trình quan sát, hành động, kiểm tra; điều kiện dừng; cơ chế xác minh) chính là phần bên trong của một node. Graph không thay thế loop, nó là thứ xuất hiện khi có nhiều loop cần bàn giao việc cho nhau.
Đối chiếu với cách chúng tôi đang làm
AI-DLC Kit, bộ tài liệu và skill dùng cho quy trình AI-DLC nội bộ, có cấu trúc khá gần với mô hình graph điều phối vừa nêu, dù không dùng từ “graph” để mô tả. Bộ file trong Harness cộng với skill orchestrator có thể đối chiếu với ba thành phần ở trên như sau.
| Thành phần graph điều phối | Tương ứng trong Amplify SDLC Kit |
|---|---|
| Định nghĩa graph (StateGraph) | workflow.yaml: khai báo các phase (L0 đến L6), các gate (G1 đến G5), các chain nhiều bước có thứ tự, và các intent để khớp yêu cầu bằng lời thường vào đúng node. |
| Node | Mỗi skill vai trò: ba-agent, sa-agent, dev, qc-agent, pm-agent. Mỗi node này bên trong vẫn tự chạy một loop riêng (đọc yêu cầu, soạn artifact, tự kiểm tra trước khi báo xong). |
| Edge tuần tự / rẽ nhánh có điều kiện | Các gate G1 đến G5: mỗi gate đọc bằng chứng (review log, traceability) và chỉ cho đi tiếp khi đạt tiêu chí blocking; không đạt thì dừng lại, trả về đúng skill có thể vá chỗ thiếu, y như “rẽ nhánh theo điều kiện, không đạt thì quay lại”. |
| State dùng chung | CONTEXT-GRAPH.yaml: trạng thái phase, sprint, node nào đã xong, được mọi bước đọc vào và ghi thêm vào, giống hệt vai trò state trong LangGraph. |
| Runtime duyệt graph | Skill orchestrator: đọc bốn file harness, khớp yêu cầu bằng lời với intent, quyết định chạy node hay chain nào, kiểm gate trước khi cho qua, rồi patch lại state. Đây chính là phần “thực thi” graph. |
# workflow.yaml (phác thảo minh hoạ, không phải trích nguyên văn)phases: - id: L4 name: "Implementation" steps: - { id: L4.1, skill: dev/design-memo-generator } - { id: L4.2, skill: dev/implement } gate_out: G4gates: - id: G4 blocking: true criteria: - { check: "design memo exists for every sprint story", evidence: review_log } - { check: "code review has no BLOCKER finding", evidence: review_log }chains: - id: qc-chain order_enforced: true steps: [test-scenario-designer, test-viewpoint-generator, test-case-designer, test-case-generator, testing-traceability-checker]intents: - match: ["what's next", "where are we"] action: next_step
Vậy vì sao tôi vẫn không thích gọi nó là “Graph Engineering”
Đây là quan điểm cá nhân, không phải sự thật tuyệt đối, nên tôi nói rõ lý do để ai không đồng ý có thể phản biện lại.
Ủng hộ cách gọi “graph”: nó gọi đúng tên cấu trúc dữ liệu, cho phép mượn thẳng các khái niệm graph đã có sẵn (chu trình, rẽ nhánh, hội tụ nhiều nhánh, khả năng tới được của một node) thay vì phải diễn giải lại từ đầu. Nói “gate này là một conditional edge có thể quay vòng” chính xác hơn nói “gate này là một bước kiểm tra trong quy trình”.
Không ủng hộ cách gọi “graph”: phần việc khó và có giá trị nhất trong workflow.yaml không nằm ở chỗ nó là một graph. Nó nằm ở việc quyết định phase nào cần tồn tại, tiêu chí nào đủ để coi một gate là “qua”, bằng chứng nào được chấp nhận, và khi nào một chain phải chạy đúng thứ tự tuyệt đối. Toàn bộ những quyết định đó là thiết kế quy trình làm việc, không phải lý thuyết đồ thị. Gọi nó là “graph engineering” dễ khiến người nghe nghĩ việc khó là chọn cấu trúc dữ liệu, trong khi việc khó thật sự là chọn đúng gate, đúng tiêu chí, đúng trình tự. Đó là lý do cá nhân tôi thấy “Workflow Engineering” mô tả đúng bản chất công việc hơn, dù “graph” mô tả đúng hình dạng của nó hơn.
Quy ước dùng trong bài này: khi nói về cấu trúc bên dưới (node, edge, state, có chu trình hay không), dùng từ “graph”. Khi nói về công việc thiết kế thật sự (phase nào, gate nào, tiêu chí nào), dùng từ “workflow”. Cùng một hệ thống, nhưng gọi đúng lớp đang nói tới.
Tóm lại
Quay lại câu hỏi ban đầu: “Graph Engineering” có phải một ngành riêng không? Câu trả lời cần tách theo nghĩa. Nghĩa 1, graph như một cách biểu diễn ngữ cảnh và tri thức, đúng là chỉ một kỹ thuật nằm trong context engineering, không xứng đứng ngang hàng với prompt, harness, hay loop engineering, như đã lập luận từ đầu bài. Nghĩa 2, graph như một tầng điều phối nhiều agent hay nhiều loop, lại đang được nhiều người, không chỉ trên X mà cả trong các framework có sẵn như LangGraph, AutoGen, Google ADK, coi là một tầng thật, nằm ngay trên loop engineering, dù cơ chế bên dưới nó (đồ thị có hướng, máy trạng thái, điều phối đa-agent) đã tồn tại từ lâu trước khi có cái tên này.
Cách kiểm tra đơn giản tôi hay dùng cho mọi thuật ngữ mới nghe được vẫn không đổi: thử diễn giải ý tưởng đó bằng lời thường, không dùng chính thuật ngữ đó. Với nghĩa 1: “đang nối các thứ lại bằng liên kết rõ ràng để AI biết cái gì liên quan tới cái gì”, diễn giải được, đáng học. Với nghĩa 2: “đang định nghĩa nhiều agent chuyên trách, nối chúng theo một thứ tự có điều kiện, và cho chúng chia sẻ một trạng thái chung”, cũng diễn giải được, cũng đáng học, dù cá nhân tôi vẫn thấy gọi việc đó là thiết kế quy trình (Workflow Engineering) sát bản chất công việc hơn là gọi theo tên cấu trúc dữ liệu bên dưới (Graph Engineering). AI-DLC Kit, với workflow.yaml, các gate, và orchestrator, là một ví dụ có thể đối chiếu theo hướng này, dưới một tên gọi khác.
Transforming Leadership 