- Hầu hết các nhóm xây dựng hệ thống dựa trên LLM đều cố bắt đầu từ agent, nhưng đa số dễ sụp đổ vì độ phức tạp, khó điều phối và khó gỡ lỗi
- Mẫu agent thực thụ, nơi bộ nhớ, RAG, dùng công cụ và điều khiển workflow đều cần thiết, trên thực tế khá hiếm; phần lớn vấn đề có thể được giải quyết hiệu quả hơn bằng workflow đơn giản (chaining, parallelization, routing, v.v.)
- Khuyến nghị nên áp dụng trước 5 mẫu workflow LLM hữu ích trong thực tế, và chỉ dùng agent một cách thận trọng khi thật sự cần
- Prompt chaining, parallelization, routing, orchestrator-worker, evaluator-optimizer
- Ngay cả khi cần agent, điều cốt lõi vẫn là sự tham gia của con người, khả năng kiểm soát rõ ràng và khả năng quan sát (Observability)
AI agent, có thực sự cần thiết?
- Những góc nhìn của Hugo Bowne-Anderson, người cung cấp tư vấn và đào tạo về xây dựng hệ thống LLM cho nhiều kỹ sư và đội ngũ như Netflix, Meta, Không quân Mỹ
Khởi đầu sai lầm: Vì sao ai cũng ám ảnh với agent
- Nhiều nhóm khi bắt đầu dự án LLM thường ưu tiên đưa vào các cấu trúc phức tạp như agent, memory, routing, dùng tool, tính cách nhân vật
- Khi triển khai thực tế, các vấn đề bất thường và thất bại liên tục xuất hiện ở nhiều khía cạnh như cộng tác giữa các agent, chọn công cụ, bộ nhớ dài hạn
- Ví dụ, trong một dự án agent nghiên cứu dựa trên CrewAI, từng vai trò (researcher, summarizer, coordinator) đã không thể phối hợp như kỳ vọng và sụp đổ hoàn toàn
Agent là gì?
- 4 đặc tính của hệ thống LLM: bộ nhớ, truy xuất thông tin (RAG), dùng công cụ, điều khiển workflow
- Đặc tính cuối cùng là điều khiển workflow, tức LLM tự quyết định bước tiếp theo hoặc có dùng công cụ hay không, được gọi là tính chất agentic
- Trong phần lớn công việc thực tế, workflow đơn giản (chaining, routing, v.v.) cho độ ổn định cao hơn
Những mẫu workflow LLM nên dùng thay vì agent, thực sự hữu ích trong thực chiến
1. Prompt Chaining
- Mô tả: Chia nhiều tác vụ thành một chuỗi bước và để LLM xử lý tuần tự từng bước
- Ví dụ: Trích xuất tên, chức danh và công ty từ hồ sơ LinkedIn → thêm thông tin bổ sung về công ty đó (sứ mệnh, tuyển dụng, v.v.) → viết email cá nhân hóa dựa trên hồ sơ + thông tin công ty
- Ưu điểm: Mỗi bước được tách biệt rõ ràng nên khi có lỗi rất dễ truy vết nguyên nhân/sửa chữa; thuận lợi cho gỡ lỗi và bảo trì
- Hướng dẫn:
- Phù hợp với các tác vụ được nối tuần tự
- Chỉ cần một bước thất bại là cả chuỗi có thể sụp đổ
- Nếu chia thành các đơn vị công việc nhỏ, có thể đạt kết quả dễ dự đoán và dễ gỡ lỗi
2. Parallelization
- Mô tả: Chạy đồng thời nhiều tác vụ độc lập để tăng tốc toàn bộ quy trình
- Ví dụ: Trích xuất song song nhiều mục như học vấn, kinh nghiệm, kỹ năng từ hồ sơ của nhiều người để rút ngắn thời gian xử lý tổng thể
- Ưu điểm: Hiệu quả với dữ liệu quy mô lớn trong các bài toán trích xuất/xử lý độc lập; rất hợp với môi trường xử lý phân tán
- Hướng dẫn:
- Khi các tác vụ độc lập với nhau, chạy song song có thể cải thiện tốc độ tổng thể đáng kể
- Cần lưu ý các ngoại lệ như race condition, timeout trong lúc chạy song song
- Phù hợp cho xử lý dữ liệu lớn, phân tích đồng thời nhiều nguồn
3. Routing
- Mô tả: LLM phân loại dữ liệu đầu vào rồi tự động rẽ nhánh sang workflow phù hợp cho từng loại
- Ví dụ: Trong công cụ hỗ trợ khách hàng, phân loại nội dung đầu vào là câu hỏi về sản phẩm, sự cố thanh toán hay yêu cầu hoàn tiền rồi tự động xử lý theo workflow tương ứng; nếu loại không rõ ràng thì chuyển sang handler mặc định
- Ưu điểm: Áp dụng logic xử lý chuyên biệt theo từng loại đầu vào, giúp tách bạch nhiều trường hợp khác nhau một cách gọn gàng
- Hướng dẫn:
- Hữu ích khi cần xử lý riêng cho các loại đầu vào/tình huống khác nhau
- Ở các trường hợp biên hay ngoại lệ, routing có thể thất bại hoặc bỏ sót
- Nhất định phải thiết kế một catch-all handler cho trường hợp chưa phân loại/ngoại lệ
4. Orchestrator-Worker
- Mô tả: LLM ở vai trò orchestrator phân rã/đánh giá công việc rồi giao các tác vụ chi tiết cho worker (LLM thực thi), đồng thời trực tiếp kiểm soát toàn bộ luồng và thứ tự
- Ví dụ: Phân loại hồ sơ mục tiêu thành tech/non-tech → nếu là tech thì giao cho worker chuyên môn tạo email, nếu là non-tech thì giao cho worker khác
- Ưu điểm: Tách biệt việc ra quyết định (phân loại/đánh giá) và thực thi (xử lý riêng lẻ), thuận lợi cho điều khiển luồng động và mở rộng
- Hướng dẫn:
- Phù hợp khi mỗi tác vụ cần cách xử lý chuyên biệt, hoặc cần rẽ nhánh phức tạp và điều phối theo từng bước
- Nếu orchestrator phân rã hoặc ủy quyền sai, toàn bộ luồng sẽ phát sinh lỗi
- Hãy giữ logic đơn giản một cách tường minh, và thiết kế rõ việc ủy quyền/thứ tự/điều kiện kết thúc
5. Evaluator-Optimizer
- Mô tả: LLM đánh giá đầu ra (điểm số/phản hồi), nếu chưa đạt chuẩn thì lặp lại việc sửa đổi/cải thiện
- Ví dụ: Tạo bản nháp email → evaluator cho điểm chất lượng/phản hồi → nếu đạt ngưỡng hoặc vượt số lần lặp tối đa thì dừng, nếu không thì tiếp tục sửa lại
- Ưu điểm: Có thể cải thiện lặp đi lặp lại chất lượng đầu ra cuối cùng đến mức mục tiêu; phù hợp khi dùng tiêu chí định lượng
- Hướng dẫn:
- Phù hợp với tình huống chất lượng quan trọng hơn tốc độ, hoặc workflow cần tối ưu lặp lại
- Nếu không có điều kiện dừng, hệ thống có thể rơi vào vòng lặp vô hạn
- Bắt buộc phải đặt tiêu chí chất lượng rõ ràng và giới hạn số vòng lặp
Khi nào thật sự cần agent
- Agent phát huy giá trị mạnh nhất trong môi trường có đảm bảo Human-in-the-loop theo thời gian thực
- Ví dụ 1: Trợ lý khoa học dữ liệu - LLM thử nghiệm sáng tạo với truy vấn SQL, trực quan hóa, gợi ý phân tích dữ liệu, còn con người đánh giá/chỉnh sửa kết quả
- Ví dụ 2: Đối tác sáng tạo - trong việc gợi ý ý tưởng copywriting, đề xuất headline, cấu trúc văn bản, việc chỉnh hướng và thẩm định chất lượng của con người là then chốt
- Ví dụ 3: Trợ lý refactor code - nhà phát triển phê duyệt/bổ sung các đề xuất về design pattern, phát hiện edge case, tối ưu code
- Đặc điểm: Agent không phải là thứ “tự lo mọi thứ”, mà hiệu quả nhất trong môi trường nơi con người sửa lỗi/chỉnh hướng theo thời gian thực
Khi agent không phù hợp
- Hệ thống enterprise hoặc mission-critical (tài chính, y tế, pháp lý, v.v.):
- Vì độ tin cậy của tự động hóa và hành vi mang tính quyết định là quan trọng, cấu trúc để LLM agent tự phán đoán là rủi ro
- Cần dùng các mẫu kiểm soát rõ ràng như orchestrator, routing
- Mọi tình huống mà tính ổn định và khả năng dự đoán là quan trọng
- Trường hợp bất thường: agent liên tục chọn sai công cụ vì thiếu ngữ cảnh/bộ nhớ, hoặc thất bại trong phân công/điều phối khiến toàn bộ luồng sụp đổ
- Các nguyên nhân thất bại của hệ thống agent thường gặp trong thực tế
- Không thiết kế hệ thống bộ nhớ tường minh nên bị mất ngữ cảnh
- Thiếu ràng buộc trong việc chọn công cụ (dùng tool không cần thiết/sai công cụ)
- Quá phụ thuộc vào cấu trúc ủy quyền tự do nên thất bại trong điều phối hợp tác
Bài học khi thiết kế hệ thống thực tế
- Ngay cả khi đưa agent vào, vẫn bắt buộc phải có thiết kế, khả năng quan sát và cơ chế kiểm soát ở mức một hệ thống phần mềm hoàn chỉnh
- So với framework agent phức tạp, thiết kế dựa trên Observability, vòng lặp đánh giá rõ ràng và cấu trúc có thể kiểm soát trực tiếp sẽ nhanh hơn và an toàn hơn
Kết luận (TL;DR)
- Agent thường bị đánh giá quá cao và bị lạm dụng
- Phần lớn bài toán thực chiến phù hợp hơn với các mẫu workflow đơn giản
- Agent phát huy giá trị thật trong môi trường con người tham gia trực tiếp
- Trong hệ thống cần ổn định, agent ngược lại có thể là yếu tố rủi ro
- Hãy thiết kế với khả năng quan sát, kiểm soát tường minh và cấu trúc đánh giá lặp
- Thay vì framework agent phức tạp, bí quyết để phát triển dịch vụ dựa trên LLM nhanh hơn và an toàn hơn trong thực tế là thiết kế với Observability, vòng lặp đánh giá rõ ràng và cấu trúc có thể kiểm soát trực tiếp
6 bình luận
Một tháng trước, tôi bắt tay phát triển một framework để vừa học xem AI coding là gì bằng cách tận dụng CURSOR.
Trong khoảng 3 tuần, tôi liên tục lặp lại cảnh thành công rồi lại để mã nguồn từng được AI Agent kiểm chứng bị phá hỏng, và đã cố gắng bằng mọi cách để kiểm soát AI Agent nhưng vẫn thất bại.
Rồi tôi nhận ra rằng trước khi phát triển framework, ưu tiên trước hết phải là phát triển mã nguồn để kiểm soát AI Agent.
Cuối cùng, đúng tròn 1 tháng kể từ khi bắt đầu để tìm hiểu AI thực sự là gì, tôi đã đạt được thành quả hoàn tất phát triển phần mềm có thể được AI triển khai 100% và vận hành 100% một cách hoàn toàn kiểm soát được AI Agent (chính xác hơn là không cần LLM bên ngoài hay AI Agent).
Hiện tại đã là ngày thứ 14, tôi đang tiếp tục huấn luyện bổ sung META AI đó để nâng cấp thêm, đồng thời xây dựng và buộc nó tuân thủ các quy định vận hành; song song đó, tôi cũng đang tiến hành migration, cải tiến và chuẩn hóa cùng lúc 3 hệ thống MES vốn trước đây do con người làm ra một cách chưa hoàn chỉnh, và hiện đã bước vào giai đoạn hoàn tất.
Và lúc này, tôi đang chuẩn bị cho một sự tiến hóa khác nữa.
Nhưng trong prompt chaining, liệu có thể xem là không vấn đề gì nếu gọi riêng LLM thực thi từng prompt, worker thực thi, worker điều phối, LLM đánh giá, v.v. là các agent hay không?
À, hóa ra có đoạn “quyền kiểm soát quy trình cuối cùng (LLM tự quyết định bước tiếp theo hoặc có dùng công cụ hay không) được gọi là tính chất tác tử”. Tôi hiểu rồi. Đây là bài viết nhắm tới autonomous agent. Vì tôi vẫn chưa hiểu rõ về agent nên...
Ý kiến trên Hacker News
https://github.com/astronomer/airflow-ai-sdk
Hiện tại tôi cũng đang làm một Computer-use Agent tên là UseDesktop.
https://youtu.be/aBkbsvMxP_A?si=uaugxKQEu4ZEz7jq
usedesktop.com
Vì vậy tôi đồng ý với phần lớn nội dung.
Bài này thiên về bức tranh tổng quan hơn là các mẹo thực chiến, nên nếu bổ sung thêm vài kinh nghiệm khi phát triển agentic/agent dựa trên LLM thì cuối cùng, LLM là thứ dựa trên transformer (tức là suy luận dựa trên xác suất, dự đoán token tiếp theo từ token/state hiện tại theo ngữ cảnh/ngữ nghĩa chứ không thực sự “hiểu” và nói ra từ tiếp theo), nên dù có viết
sys prompttốt đến đâu thì cũng khá thường xuyên không trả ra câu trả lời như mong muốn (ví dụ yêu cầu trả lời bằng JSON output nhưng thỉnh thoảng lại quên mất}chẳng hạn). Vì vậy, việc luôn thêm nhiều fallback function dựa trên regex là bắt buộc.Ngoài ra, khi viết
sys promptđể buộc structured output thì thường nên dùng non-reasoning model, và context càng dài thì hallucination càng hay xảy ra, nên thà tạo nhiềusys promptrồi chain chúng lại còn tốt hơn.Khi phát triển dịch vụ, có thể phát sinh nhiều loại lỗi, nên mấu chốt là phải thiết kế cấu trúc service theo hướng mô-đun hóa và fault-tolerant (ví dụ supervisor agent chạy async còn các agent khác chạy sync), đặc biệt là với các hệ agentic/agent vốn thường xuyên tạo ra unexpected output.
Vì thế, ngay từ đầu khi viết code thì nên cố gắng tuân thủ SRP và viết theo hướng declarative; tôi muốn nói rằng tiếp cận theo kiểu functional sẽ tốt hơn (= không có side effect và flow trực quan).
Ngoài ra, còn tùy bạn dùng LLM qua API hay tự phục vụ model, nhưng nếu định tự phục vụ SLM hoặc LLM thì đừng model serving trên cùng server đang host backend; nên tách riêng IO bound task và CPU bound tasks (tức các tác vụ cần GPU, phép nhân ma trận v.v.) sang các server khác nhau để fault-tolerant hơn và tốt hơn (ví dụ host CPU bound task trên runpod).
Ngoài những điều này còn nhiều mẹo phát triển khác nữa, nhưng sợ dài quá nên tôi chỉ viết đến đây thôi.
Hy vọng sẽ giúp ích cho ai đó.
Thật sự cảm ơn bạn đã chia sẻ những trải nghiệm và ý kiến quý giá. Những ý kiến từ người đang trực tiếp làm việc tại hiện trường như thế này thực sự giúp ích rất nhiều.