Graph Engineering: Đừng Xếp Agent Thành Một Hàng Dài

TL;DR

Một thứ nhiều đội agent đang vấp phải: Graph Engineering. Vấn đề không phải lúc nào cũng là model chưa đủ mạnh. Rất nhiều workflow chậm vì ta bắt các agent chạy theo một hàng dài, dù nhiều việc không thật sự phụ thuộc nhau.

Ý cốt lõi: hãy vẽ workflow thành node và edge. Node là một việc có input và output rõ. Edge chỉ tồn tại khi output của node trước thật sự cần cho node sau. Nếu không có dependency thật, đó là fake edge và có thể cắt để chạy song song.

Graph Engineering không bắt agent làm nhiều hơn. Nó bắt workflow nói rõ việc nào phải chờ, việc nào có thể chạy cùng lúc.

Từ loop đến graph

Trong vài tháng qua, nhiều người nói về loop engineering: thiết kế một vòng lặp để agent thử, kiểm tra, sửa và lặp lại cho tới khi đạt mục tiêu. Loop rất hợp với một nhiệm vụ hẹp: sửa một bug, tối ưu một benchmark, cải thiện một đoạn copy.

Nhưng khi workflow lớn hơn, loop đơn bắt đầu lộ giới hạn. Research một thị trường, audit cả repo, viết một bộ go-to-market kit, hay review hàng chục file không còn là một đường thẳng. Những việc đó có nhiều nhánh độc lập, nhiều điểm kiểm tra, nhiều chỗ cần gom kết quả lại.

Graph engineering là cách gọi lớp điều phối đó. Nó không phủ nhận loop. Nó nối nhiều loop, nhiều bước, nhiều verifier thành một hệ thống có control flow rõ ràng.

Node, edge và hợp đồng output

Trong graph, node không nên là một lời nhắc mơ hồ kiểu hãy phân tích giúp tôi. Node tốt có một việc nhỏ, input rõ, output có dạng cố định. Ví dụ: kiểm tra file A theo checklist bảo mật và trả về JSON gồm severity, bằng chứng, dòng code, đề xuất sửa.

Edge là quan hệ chờ. Node B chỉ cần chờ node A khi nó thật sự dùng kết quả của A. Nếu B không đọc output của A, việc bắt B đứng sau A chỉ là thói quen tuyến tính.

Node làm việc. Edge mang kết quả. Nếu edge không mang dữ liệu thật, nó chỉ đang làm workflow chậm đi.

Đây là điểm thường bị bỏ qua: graph chỉ hữu ích khi output của node có hợp đồng đủ chặt để node sau dùng được. Nếu mọi node đều trả về một bức tường chữ, graph sẽ biến thành một đống tóm tắt khó kiểm tra. Output càng có schema, bước merge càng rẻ và đáng tin hơn.

Fake-edge test: câu hỏi nhỏ, lợi ích lớn

Cách thực dụng nhất để bắt đầu là vẽ workflow hiện tại rồi hỏi từng mũi tên: bước sau có thật sự cần kết quả của bước trước không?

Nếu có, giữ edge. Nếu không, cắt edge. Hai bước đó có thể chạy song song.

Ví dụ đơn giản: review file A rồi review file B. Nếu file B không phụ thuộc kết quả file A, chạy tuần tự là lãng phí. Khi tách ra, thời gian hoàn tất gần với file chậm nhất, không phải tổng thời gian của cả hai.

Điều này nghe nhỏ, nhưng tác động rất lớn ở quy mô repo. Một chuỗi 40 bước có latency của 40 bước cộng lại. Một graph 40 node có thể chỉ có 3-5 lớp dependency thật. Cùng một lượng công việc, nhưng thời gian wall-clock khác hẳn.

Diamond pattern: fan out, reduce, synthesize

Mẫu đáng học nhất từ bài gốc là diamond pattern: fan out, reduce, synthesize.

Fan out nghĩa là chia việc ra nhiều hướng độc lập. Reduce nghĩa là gom và nén kết quả bằng logic rẻ, càng deterministic càng tốt. Synthesize nghĩa là chỉ dùng agent mạnh ở bước cuối để viết câu trả lời, quyết định hoặc báo cáo.

Diamond pattern phù hợp với research, code audit, market scan và các việc cần nhiều góc nhìn song song.

Anthropic mô tả hệ thống Research của Claude theo tinh thần tương tự: một lead agent lập kế hoạch, rồi tạo các agent song song để tìm kiếm theo nhiều hướng cùng lúc via Anthropic. Trong tài liệu Building Effective AI Agents, Anthropic cũng tách rõ các mẫu như prompt chaining, parallelization, orchestrator-workers và evaluator-optimizer via Anthropic.

Điểm đáng nhớ: graph không nhất thiết nghĩa là mọi thứ đều do LLM quyết định. Phần reduce có thể là code thường: lọc trùng, kiểm schema, đếm số input, sort theo score, fail nếu thiếu worker result. LLM nên dùng ở nơi cần phán đoán, không phải ở mọi chỗ có thể viết một hàm.

Verifier phải có context sạch

Một graph đắt tiền nhưng để worker tự kiểm tra chính mình vẫn là một hệ thống yếu. Model thường bỏ sót lỗi của chính output mình vừa tạo. Nếu verifier đọc cùng context, cùng giả định và cùng lý do với worker, nó rất dễ chỉ hợp thức hóa kết quả cũ.

Vì vậy verifier nên là node riêng, context riêng, tiêu chí riêng. Nó không hỏi agent nói xong chưa. Nó hỏi test có chạy không, source có tồn tại không, số input có đủ không, claim có khớp dữ liệu ngoài không.

Trong code review, điều này có thể là một node chạy test và một node đọc diff với checklist. Trong research, có thể là node kiểm nguồn, node kiểm thời gian, node kiểm xem kết luận có dựa trên bằng chứng ngoài hay không.

Nơi graph hay vỡ

Graph vỡ theo cách khác loop. Loop hỏng thường dừng rõ. Graph hỏng có thể vẫn ra một báo cáo trông rất hoàn chỉnh dù một vài node đã chết im lặng.

Có ba lỗi phổ biến.

• Context collapse: fan out quá nhiều rồi nhét toàn bộ raw output vào một node cuối. Cách sửa là fan-in theo tầng: gom theo batch, tóm tắt từng batch, rồi mới tổng hợp.

• False independence: hai node nhìn có vẻ độc lập nhưng cùng ghi một file, dùng chung workspace, hoặc đụng một API rate limit. Cách sửa là cấp workspace riêng và audit shared resource, không chỉ audit shared data.

• Silent failure: một worker chết nhưng merge step vẫn chạy. Cách sửa là mỗi bước merge phải biết nó kỳ vọng bao nhiêu input và báo thiếu thay vì âm thầm tiếp tục.

Anchors: thứ giữ graph chạm đất

Cảnh báo sắc nhất của Anatoli là: topology không mua được sự thật. Một graph có nhiều checker, meta-checker và node audit vẫn có thể sai nếu tất cả đều kiểm cùng một báo cáo do agent tạo ra.

Graph cần anchor bên ngoài: test đã chạy, tiền đã vào, khách hàng thật, rule không được optimizer tự ý nới.

Anchor là những tín hiệu agent không thể tự tranh luận để làm mềm đi: test thật đã pass, giao dịch thật đã vào ngân hàng, khách hàng thật còn ở lại, nguồn thật còn truy cập được, constraint bảo mật không được tự hạ chuẩn.

Nếu không có anchor, graph chỉ làm sai chậm hơn, đắt hơn và trông chuyên nghiệp hơn.

Khi nào nên dùng graph?

Dùng graph khi công việc có chiều rộng thật: nhiều file độc lập, nhiều giả thuyết research, nhiều persona khách hàng, nhiều benchmark, nhiều luồng kiểm tra có thể chạy cùng lúc.

Đừng dùng graph cho việc nhỏ. Sửa một function, bắt một lỗi rõ, viết một đoạn text ngắn, hay khám phá vấn đề chưa biết hình dạng thường hợp với một agent hoặc một loop đơn hơn. Graph thêm orchestration, token, timeout, log, merge và review. Nếu không có fake edge để cắt, bạn chỉ đang vẽ thêm sơ đồ cho một đường thẳng.

Claude Code hiện có dynamic workflows để orchestrate nhiều subagent bằng script mà Claude tạo và có thể chạy lại via Claude Code docs. Nhưng khả năng spawn nhiều agent không đồng nghĩa với việc nên spawn nhiều agent. Chi phí và review vẫn là trách nhiệm kỹ thuật.

Chi phí và bài học từ Bun

Ca Bun rewrite là ví dụ tốt vì nó có cả mặt hấp dẫn lẫn mặt khó nuốt. The Pragmatic Engineer tóm tắt rewrite khoảng 550K dòng trong 11 ngày, với 64 agent và chi phí API khoảng 165.000 USD via The Pragmatic Engineer. Bun Blog nêu codebase Zig có 535.496 dòng và rewrite thủ công có thể khiến một team nhỏ mất gần một năm via Bun Blog.

Bài học không phải là mọi team nên ném 64 agent vào repo. Bài học là graph có thể đổi kinh tế của một số việc cực rộng, nhưng chỉ khi có test suite, conformance target, ngân sách, reviewer và giới hạn phạm vi đủ rõ.

Kết luận

Graph engineering không phải tên mới cho việc prompt dài hơn. Nó là kỷ luật thiết kế dependency: node nào làm gì, output ra sao, edge nào thật, merge kiểm gì, verifier có độc lập không, anchor nào giữ hệ thống chạm đất.

Thực hành nên bắt đầu rất nhỏ: lấy workflow bạn đang dùng, vẽ ra, hỏi fake-edge test cho từng mũi tên, rồi cắt các edge không mang dữ liệu. Nếu không cắt được edge nào, loop là đủ. Nếu cắt được nhiều edge, graph bắt đầu có đất diễn.

Đa số người vẫn sẽ xếp agent thành một hàng dài. Lợi thế thuộc về người biết lúc nào cần hàng, lúc nào cần mạng, và lúc nào phải dừng lại vì graph chỉ mua chiều rộng chứ không mua được phán đoán.

via Anatoli Kopadze.