Các loại AI agent: giải thích và cách tự host

Các loại AI agent

Các loại AI agent được chia theo một hệ phân loại: agent phản xạ đơn giản, agent phản xạ dựa trên model, agent dựa trên mục tiêu, agent dựa trên utility và agent có khả năng học. Mỗi tên mô tả một đặc điểm: agent ghi nhớ được bao nhiêu và lập kế hoạch xa đến đâu trước khi hành động. Hai thuật ngữ khác là multi-agent và phân cấp. Chúng mô tả cách kết nối nhiều agent với nhau, không phải cách từng agent đưa ra quyết định.

Danh sách này có từ trước mọi model bạn từng dùng. Nó xuất phát từ giáo trình AI tiêu chuẩn và vẫn được sử dụng sau khi large language model xuất hiện, vì nó đặt ra câu hỏi vẫn quyết định thiết kế của bạn: thành phần này cần biết gì trước khi hành động? Nếu bạn vẫn đang xác định ranh giới giữa một agent và một trợ lý chat, trước tiên hãy đọc sự khác biệt giữa AI agent và LLM mà nó sử dụng. Trang này bắt đầu sau phần đó.

Agent phản xạ đơn giản: một điều kiện, một hành động

Agent phản xạ đơn giản ánh xạ input hiện tại thành một hành động và không lưu memory của bất kỳ điều gì trước đó. Nếu nhiệt độ cao hơn 25, bật quạt. Toàn bộ cơ chế chỉ có vậy.

Gần như chắc chắn bạn đã chạy một agent như vậy. Một webhook kích hoạt workflow n8n, đọc dữ liệu gửi từ form rồi ghi một row vào database, là một agent phản xạ đơn giản. Nó vẫn là loại agent này ngay cả khi một language model nằm ở giữa để chọn category cho row đó. Hỏi nó đã làm gì một giờ trước, nó không thể trả lời vì không có thành phần nào lưu lại câu trả lời.

Loại agent này hoạt động đúng thường xuyên hơn mọi người nghĩ. Nó rẻ để chạy và lỗi của nó dễ xác định: điều kiện đã khớp hoặc chưa khớp. Khi công việc thực sự là “khi X đến thì thực hiện Y”, memory chỉ tạo thêm cách để xảy ra lỗi mà không mang lại lợi ích gì. Agent n8n được kích hoạt bằng webhook là mục này trong taxonomy, có thêm user interface ở phía trên.

Nó hỏng ngay khi hành động đúng phụ thuộc vào lịch sử. Một reply bot không có thread state sẽ tự mâu thuẫn ở tin nhắn thứ ba vì hai tin nhắn đầu chưa bao giờ nằm trong input của nó.

Tác tử phản xạ dựa trên model: duy trì state giữa các event

Tác tử phản xạ dựa trên model lưu một bức tranh nội bộ về môi trường và cập nhật bức tranh đó khi có input mới. Từ "model" ở đây có nghĩa là model về thế giới, không phải neural network. Thuật ngữ này xuất hiện trước nghĩa hiện tại khoảng bốn mươi năm, nên gần như ai đọc lần đầu cũng thấy khó hiểu.

Một rule tự động hóa nhà tắt đèn sau hai mươi phút không phát hiện chuyển động là một hệ thống dựa trên model. Bắt buộc phải như vậy. "Hiện tại không có chuyển động" và "không có chuyển động kể từ 21:40" là cùng một input đối với tác tử phản xạ đơn giản, nên chỉ state được lưu mới phân biệt được hai trường hợp này.

Phiên bản dùng LLM là bất kỳ tác tử nào có memory store phía sau: một bản tóm tắt conversation dạng rolling, hoặc một file markdown đơn giản được tác tử đọc khi bắt đầu mỗi lần chạy. Một memory service cục bộ cho tác tử là cách đóng gói ý tưởng đó. Cơ chế không thay đổi. Bức tranh của tác tử về thế giới tồn tại lâu hơn event đã tạo ra nó.

State có cái giá của nó. Một thông tin đã lỗi thời còn tệ hơn không có thông tin, vì tác tử hành động dựa trên thông tin đó với đầy đủ sự tự tin và không có cảnh báo. Mọi thứ được lưu cần có cơ chế hết hạn hoặc cơ chế kiểm tra lại; nếu không, tác tử sẽ tiếp tục suy luận về một server mà bạn đã decommission vào tháng 3.

Tác tử dựa trên mục tiêu: lập kế hoạch để đạt đến một trạng thái có thể kiểm tra

Tác tử dựa trên mục tiêu nhận một trạng thái đích và tìm kiếm chuỗi hành động để đạt đến trạng thái đó. Nó suy luận ngược từ trạng thái cần đạt, nên đường đi không được viết sẵn.

Coding agent là ví dụ rõ nhất mà bạn có thể tự chạy. “Làm cho test đang fail chạy pass” không nêu file hay bước thực hiện nào. Agent đọc test, lập kế hoạch, chỉnh sửa một thành phần, chạy test, đọc lỗi rồi thử lại. Vòng lặp kết thúc bằng một phép kiểm tra mà nó có thể thực sự chạy, nên chỉ dẫn đó hiệu quả còn “cải thiện code này” thì không. Mục tiêu mà agent có thể đánh giá là mục tiêu agent có thể đạt được. Mục tiêu mà agent không thể đánh giá sẽ biến thành một vòng lặp vô hạn kèm theo chi phí. Chạy coding agent trên VPS của bạn đặt vòng lặp đó ở nơi nó có thể tiếp tục chạy mà không chiếm dụng laptop của bạn.

Chi phí nằm trong vòng lặp này. Mỗi bước lập kế hoạch là một lần gọi model khác, mang theo toàn bộ lịch sử đến thời điểm đó, nên một tác vụ 10 bước không chỉ tốn gấp 10 lần một bước mà còn tốn hơn. Phần engineering quan trọng nằm ở cấu trúc của vòng lặp và điều kiện dừng, đây là chủ đề của engineering vòng lặp.

Tác tử dựa trên utility: chọn giữa nhiều phương án tốt

Mục tiêu có tính nhị phân. Utility là một điểm số. Tác tử dựa trên utility gặp nhiều kết quả đều chấp nhận được và chọn kết quả có điểm cao nhất theo một hàm do bạn viết.

Một job backup phải hoàn tất trước khi bắt đầu ngày làm việc mà không làm nghẽn uplink là một bài toán utility. Không có một đáp án duy nhất, chỉ có sự đánh đổi. Router quyết định model nào xử lý request nào, cân nhắc chi phí và chất lượng câu trả lời, cũng có cùng dạng bài toán.

Thuật toán không phải phần khó. Viết một hàm utility trung thực mới là phần khó. Nếu chỉ chấm điểm theo chi phí, bạn sẽ luôn nhận được model rẻ nhất cho mọi request, kể cả request duy nhất cần model đắt hơn. Hệ thống tối ưu chính xác theo những gì bạn đo lường. Đây là vấn đề khi tiêu chí đo lường được chọn chỉ vì nó dễ đo.

Tác tử học: loại mà hầu hết mọi người cho rằng họ đã có sẵn

Tác tử học tự thay đổi hành vi dựa trên phản hồi về các kết quả trước đó. Nó cần một thành phần đánh giá kết quả và một thành phần thay đổi policy để phản hồi.

Rất ít hệ thống self-hosted đáp ứng được điều kiện này. Một tác tử đọc lại các ghi chú do chính nó viết vào tuần trước là model-based agent có một file memory. Weights của nó không đổi. Policy của nó không đổi. Retrieval không phải là learning, và sự khác biệt này có ý nghĩa thực tế: hệ thống dựa trên memory sẽ lặp lại một lỗi mãi mãi trừ khi có thứ gì đó sửa memory, còn hệ thống learning được kỳ vọng sẽ ngừng mắc lỗi đó.

Nếu muốn có phần learning, hãy xây dựng evaluation trước. Một test set có điểm số, một lần chạy thay đổi của bạn trên test set đó và quyết định giữ hoặc loại bỏ thay đổi tạo thành một vòng lặp khép kín, trong đó bạn là thành phần learning. Cách này chậm hơn bạn nghĩ, và hiện là phiên bản duy nhất hoạt động với các thành phần self-hosted. Tự host eval harness là nơi bắt đầu.

Hệ thống multi-agent và phân cấp: cách tổ chức, không phải loại hệ thống

Đây không phải là loại thứ sáu và thứ bảy. Chúng mô tả cách các agent được tổ chức.

Một hệ thống multi-agent chạy đồng thời nhiều agent trong một môi trường dùng chung, chẳng hạn như queue hoặc git repository. Vì môi trường được dùng chung, các agent có thể xung đột trong đó. Hai agent cùng chỉnh sửa một file là lỗi thường gặp nhất; cách khắc phục là dùng lock hoặc work queue. Không prompt nào giải quyết được vấn đề này.

Một hệ thống phân cấp đặt một supervisor ở trên các worker. Supervisor chia nhỏ task, giao từng phần và hợp nhất kết quả nhận được. Mô hình này phổ biến vì tương tự cách con người phân chia công việc. Tuy nhiên, nó tốn tài nguyên vì context của supervisor tăng lên theo từng report mà nó đọc. Một multi-agent harness cho thấy cách kết nối các thành phần này trong thực tế.

Một agent hoạt động tốt vẫn hơn bốn agent chỉ hoạt động tạm được.

Mỗi lần bàn giao đều có nguy cơ làm thất thoát thông tin. Hãy bắt đầu bằng một loop. Chỉ tách loop khi bạn xác định được bước nào đang là bottleneck.

Vì sao gần như mọi hệ thống thực tế đều là hệ thống hybrid

Hãy xét một deployment agent mà bạn có thể tự chạy. Webhook khởi động agent, nên đây là hành vi phản xạ. Agent đọc trạng thái release hiện tại, nên đây là hành vi dựa trên model. Agent lập kế hoạch các bước từ phiên bản đang chạy đến phiên bản đích, nên đây là hành vi hướng mục tiêu. Agent chọn khoảng thời gian rollout dựa trên tải hiện tại, nên đây là hành vi dựa trên utility. Agent không bao giờ tự sửa policy của mình, nên nó không có khả năng học.

Một hệ thống có thể đồng thời thuộc 4 nhóm trong taxonomy. Taxonomy hữu ích nhất khi dùng làm checklist thiết kế, không phải làm nhãn cho sản phẩm hoàn chỉnh. Khi hệ thống hoạt động sai, câu hỏi cần đặt ra là layer nào bị lỗi. Trigger kích hoạt nhầm event, state bị cũ, kiểm tra goal không bao giờ pass được và score thưởng cho kết quả sai là 4 bug khác nhau, cần 4 cách khắc phục khác nhau.

Loại nào phù hợp với công việc nào

• Trigger cố định, response cố định, không cần history: simple reflex.
• Response phù hợp phụ thuộc vào những gì đã xảy ra trước đó: model-based reflex.
• Có thể kiểm tra trạng thái cuối, nhưng không biết trước đường đi: goal-based.
• Có nhiều kết quả chấp nhận được và phải đánh đổi thực sự giữa chúng: utility-based.
• Cần kết quả được cải thiện theo thời gian: xây dựng một eval loop và chấp nhận rằng bạn là thành phần learning.

Bạn có thể tự host các agent này không, và chi phí là bao nhiêu?

Có. Chi phí chia thành 2 phần. Phần orchestration khá rẻ. Một instance n8n hoặc agent loop viết bằng Python dành phần lớn thời gian để chờ các network call, nên 2 vCPU và 4 GB RAM là đủ. Model mới là phần tốn tiền.

Nếu agent gọi hosted API, server gần như không cần tài nguyên đáng kể và hóa đơn tăng theo số token. Với agent hoạt động theo mục tiêu, chi phí sẽ tăng theo số bước planning bạn cho phép, vì vậy hãy giới hạn loop.

Nếu chạy model trên phần cứng của bạn, RAM quyết định bạn có thể chạy model nào. Các con số dưới đây là kích thước file được công bố phổ biến của weight đã quantise 4-bit tính đến tháng 8 năm 2026, kèm theo mức RAM tổng cộng nên dự trù, vì context window và runtime đều cần thêm dung lượng ngoài phần weight.

[
  {
    "label": "3B model",
    "weights_gb": 2,
    "ram_needed_gb": 6
  },
  {
    "label": "8B model",
    "weights_gb": 4.9,
    "ram_needed_gb": 10
  },
  {
    "label": "14B model",
    "weights_gb": 9,
    "ram_needed_gb": 16
  },
  {
    "label": "32B model",
    "weights_gb": 20,
    "ram_needed_gb": 32
  },
  {
    "label": "70B model",
    "weights_gb": 43,
    "ram_needed_gb": 64
  }
]

Model 8B ở mức 4-bit có khoảng 4.9 GB weight, và máy có 10 GB RAM có thể chạy model này mà không cần swapping. Model 70B với cùng mức quantisation có 43 GB weight và cần khoảng 64 GB RAM. Lưu ý những con số này không nói lên tốc độ. Trên VPS không có GPU, model 8B ở mức 4-bit chỉ tạo được vài token mỗi giây. Mức này phù hợp với agent xử lý một queue qua đêm, nhưng sẽ gây chậm nếu người dùng đang chờ kết quả. Hãy dùng local inference cho các tác vụ batch, còn phần tương tác nên chạy trên GPU hoặc qua API. Danh sách rút gọn các AI agent có thể tự host cho biết project nào đáng dành dung lượng ổ đĩa, còn lộ trình học agent trong năm 2026 cho biết nên học nội dung nào trước.

Khi taxonomy không còn giúp ích

Taxonomy này không nói gì về tool hoặc quyền hạn. Các agent trong sách giáo khoa chỉ nhận biết và hành động. Người viết chương đó không phải lo về việc một agent nắm giữ production API token. Một agent định hướng mục tiêu có quyền shell và một agent định hướng mục tiêu chỉ có một kết nối read-only đến database nằm cùng một hàng trong bảng, nhưng có mức rủi ro hoàn toàn khác nhau. Hãy xác định agent được phép truy cập những gì trước khi quyết định nó cần thông minh đến mức nào, và đọc cách giữ secret ngoài agent AI trước khi cấp credential cho nó.

Taxonomy này cũng không nói gì về điều xảy ra khi một bước bị lỗi. Agent thực tế dành phần lớn thời gian chạy để xử lý lỗi: rate limit hoặc một tool trả về dữ liệu mà model không dự kiến. Phần code đó quyết định hệ thống của bạn có thể sử dụng được hay không, nhưng không có hàng nào trong taxonomy mô tả phần này.

FAQ

5 loại AI agent là gì?

Simple reflex, model-based reflex, goal-based, utility-based và learning agent. Chúng được sắp xếp theo lượng thông tin agent biết trước khi hành động. Simple reflex agent chỉ thấy input hiện tại. Model-based agent lưu state về môi trường của nó. Goal-based agent lập kế hoạch để đạt đến một state mục tiêu. Utility-based agent chấm điểm nhiều kết quả có thể chấp nhận rồi chọn kết quả cao nhất. Learning agent tự thay đổi policy dựa trên feedback; thực tế gần như không có setup self-hosted nào làm việc này.

Tôi nên dùng loại AI agent nào cho một automation đơn giản?

Simple reflex agent, trong thực tế là một webhook hoặc schedule kích hoạt một chuỗi thao tác cố định. Nếu phản hồi đúng chỉ phụ thuộc vào input vừa nhận, memory sẽ tạo thêm các failure mode mà không cung cấp thêm khả năng nào. Chuyển sang thiết kế model-based khi bạn xác định được một quyết định cần biết chuyện gì đã xảy ra trước đó.

Tôi có thể tự chạy AI agent trên VPS không?

Có. Orchestration layer khá nhẹ, nên 2 vCPU và 4 GB RAM đủ để chạy thoải mái một workflow engine hoặc agent loop. Quyết định quan trọng là model chạy ở đâu. Hosted API giữ cho server nhỏ gọn và chuyển chi phí sang token. Local model cần lượng RAM tương ứng với số parameter. Nếu không có GPU, model chỉ tạo được vài token mỗi giây, phù hợp với batch work được xếp hàng hơn là cửa sổ chat.

Một large language model tự nó có phải là AI agent không?

Không. Model ánh xạ input text thành output text rồi dừng lại. Nó trở thành agent khi có một wrapper đặt nó trong loop có thể tác động lên thế giới bên ngoài và đưa kết quả trở lại loop. Việc này cần các tool mà model có thể gọi và một điều kiện cho loop biết khi nào phải dừng. Wrapper mới là agent. Model chỉ là một thành phần bên trong agent.

Tôi có cần multi-agent system không?

Thường là không. Một loop duy nhất với nhiều tool xử lý được phần lớn công việc và dễ debug hơn nhiều. Nhiều agent hữu ích khi các phần của task thực sự độc lập và có thể chạy đồng thời, hoặc khi một phần cần model khác. Đổi lại là chi phí điều phối: shared state và một supervisor có context tăng lên sau mỗi báo cáo của worker mà nó đọc. Chỉ thêm agent thứ hai khi bạn xác định được bước đang chậm.