Năm ngoái mình dùng ChatGPT như cái dictionary thông minh — hỏi gì trả lời nấy, copy paste kết quả vào code. Năm nay mình đang dùng một con AI agent tự đọc email support hàng ngày, phân loại ticket, tìm tài liệu liên quan trong knowledge base, draft câu trả lời, rồi chờ mình approve trước khi gửi. Mình chỉ review 5 phút mỗi sáng thay vì ngồi 2 tiếng xử lý email.
Sự khác biệt giữa hai thứ đó — chatbot và agent — là chủ đề bài viết này. Không phải lý thuyết trên mây, mà nhìn từ góc developer: agent hoạt động thế nào ở tầng kỹ thuật, build bằng gì, và tại sao nó đang thay đổi cách chúng ta thiết kế phần mềm.
Chatbot vs Agent: một khác biệt cốt lõi
Chatbot — kể cả ChatGPT — hoạt động theo mô hình request-response. Bạn hỏi, nó trả lời. Một lượt. Xong. Nó không tự làm gì nếu bạn không hỏi, không biết kết quả của câu trả lời trước đó ảnh hưởng thế nào, không tự sửa nếu sai.
Agent hoạt động theo mô hình goal-oriented loop. Bạn đưa mục tiêu, nó tự lặp nhiều bước cho đến khi đạt được:
Chatbot:
User hỏi → LLM trả lời → Xong.
Agent:
User đặt goal → Agent observe → Agent think (plan) → Agent act (tool)
↑ ↓
└────────── reflect: đã đạt goal chưa? ←────────────────┘
Chưa → lặp lại
Rồi → trả kết quả
Cái loop observe-think-act-reflect đó là bản chất của agent. Nó không chỉ generate text — nó hành động trong thế giới thật: gọi API, đọc database, gửi email, chạy code, navigate web. Và sau mỗi hành động, nó kiểm tra kết quả, quyết định bước tiếp theo.
Ví dụ cụ thể. Bạn bảo chatbot: "Tìm chuyến bay Sài Gòn đi Tokyo tuần sau giá rẻ nhất". Nó trả lời một đoạn text generic về cách tìm vé rẻ, có thể list vài hãng bay. Bạn phải tự vào từng trang mà search.
Bạn bảo agent cùng câu đó. Nó: (1) gọi API Skyscanner search chuyến bay, (2) nhận 50 kết quả, (3) filter và sort theo giá, (4) kiểm tra baggage policy vì bạn từng nói thích mang vali lớn, (5) cross-check với Google Flights xem giá có consistent không, (6) trả về top 3 lựa chọn kèm link booking. Nếu API nào fail, nó retry hoặc thử nguồn khác.
Bốn thành phần tạo nên một agent
1. LLM — bộ não reasoning
LLM là thành phần trung tâm — nó đọc hiểu tình huống, lập kế hoạch, và quyết định action tiếp theo. Không phải mọi LLM đều đủ mạnh cho agent — model cần khả năng:
- Instruction following tốt: hiểu complex prompt với nhiều rule
- Tool/function calling: biết khi nào cần gọi tool, gọi tool nào, truyền parameter gì
- Multi-step reasoning: plan nhiều bước, không chỉ trả lời một lượt
GPT-4o, Claude Sonnet/Opus, Gemini Pro — những model này đủ mạnh cho agent. Model nhỏ hơn (7B, 13B) hoạt động được cho agent đơn giản nhưng reasoning kém với task phức tạp.
2. Tools — tay chân của agent
Tool là function mà agent có thể gọi để tương tác với thế giới bên ngoài. Không có tool, agent chỉ là chatbot fancy.
// ví dụ khai báo tools cho agent
const tools = [
{
name: "search_products",
description: "Tìm sản phẩm theo keyword, trả về danh sách kèm giá",
parameters: {
keyword: { type: "string", required: true },
category: { type: "string" },
maxPrice: { type: "number" }
}
},
{
name: "get_order_status",
description: "Kiểm tra trạng thái đơn hàng theo mã đơn",
parameters: {
orderId: { type: "string", required: true }
}
},
{
name: "send_email",
description: "Gửi email cho khách hàng",
parameters: {
to: { type: "string", required: true },
subject: { type: "string", required: true },
body: { type: "string", required: true }
}
}
];
LLM nhìn vào danh sách tool descriptions, hiểu mỗi tool làm gì, rồi quyết định gọi tool nào dựa trên goal hiện tại. Đây là "function calling" hay "tool use" — feature quan trọng nhất biến LLM thành agent.
Tool có thể là bất kỳ thứ gì: REST API, database query, file system operation, web scraping, code execution, gọi một LLM khác. Agent không cần biết tool implement thế nào — nó chỉ cần biết tool description và parameter schema.
3. Memory — nhớ context qua các bước
Agent cần nhớ:
Short-term memory: conversation history + kết quả các tool call trong session hiện tại. "Tôi vừa search sản phẩm, nhận được 5 kết quả, user nói muốn cái rẻ nhất — nên tôi pick kết quả đầu tiên."
Long-term memory: thông tin persist qua nhiều session. "User này thường mua đồ điện tử, thích giao nhanh, đã từng complain về đóng gói kém." Thường implement bằng vector database — embed thông tin về user, retrieve khi cần.
Không có memory, agent mỗi lần chạy lại như mới sinh — không biết gì về user, không nhớ đã làm gì trước đó. Memory biến agent từ stateless function thành assistant thực sự hiểu context.
4. Planning — lập kế hoạch trước khi hành động
Agent đơn giản hoạt động kiểu reactive: nhận input → chọn tool → chạy → xong. Agent phức tạp hơn có khả năng plan nhiều bước:
Goal: "Tạo báo cáo doanh thu tháng này và gửi cho sếp"
Plan:
1. Query database lấy dữ liệu doanh thu tháng 3
2. Tính tổng theo category
3. So sánh với tháng trước (query thêm data tháng 2)
4. Generate biểu đồ
5. Tạo email với attachment báo cáo
6. Gửi cho sếp (email: boss@company.com)
Agent tạo plan trước, rồi thực thi từng bước. Nếu bước 3 fail (database timeout), nó replan — retry hoặc dùng cached data. Planning giúp agent xử lý task phức tạp mà single-step không đủ.
Agent loop: code thực tế
Để hiểu rõ, đây là một agent loop tối giản bằng pseudocode:
public class SimpleAgent
{
private readonly IChatClient _llm;
private readonly Dictionary<string, Func<JsonElement, Task<string>>> _tools;
private readonly List<ChatMessage> _memory = new();
public async Task<string> RunAsync(string userGoal, int maxSteps = 10)
{
_memory.Add(new ChatMessage("user", userGoal));
for (var step = 0; step < maxSteps; step++)
{
// THINK: gửi memory + tools cho LLM, nhận quyết định
var response = await _llm.SendAsync(_memory, _tools.Keys);
// LLM trả lời text → goal đã đạt, return
if (response.Type == ResponseType.Text)
{
return response.Text;
}
// LLM muốn gọi tool → ACT
if (response.Type == ResponseType.ToolCall)
{
var toolName = response.ToolCall.Name;
var toolArgs = response.ToolCall.Arguments;
// thực thi tool
var toolResult = await _tools[toolName](toolArgs);
// OBSERVE: lưu kết quả vào memory
_memory.Add(new ChatMessage("assistant",
$"Gọi {toolName}({toolArgs})"));
_memory.Add(new ChatMessage("tool",
$"Kết quả: {toolResult}"));
// REFLECT: loop tiếp → LLM sẽ thấy kết quả
// và quyết định bước tiếp theo
}
}
return "Đã đạt giới hạn bước. Không hoàn thành được mục tiêu.";
}
}
Mỗi iteration: LLM nhìn toàn bộ history (goal + previous actions + results), quyết định gọi tool tiếp hay trả lời. Loop tiếp cho đến khi LLM quyết định "tôi đã có đủ thông tin để trả lời" hoặc hết bước.
Đây chính xác là cách AutoGen, LangChain Agent, và Semantic Kernel Agent hoạt động ở core — chỉ thêm nhiều abstraction xung quanh.
Ví dụ thực tế: Customer Support Agent
Để thấy rõ agent khác chatbot thế nào, xem scenario thật:
Customer email: "Tôi đặt đơn ORD-4521 tuần trước, giờ muốn đổi sang size L. Được không?"
Chatbot sẽ: trả lời template kiểu "Cảm ơn bạn đã liên hệ. Để đổi size, vui lòng liên hệ hotline 1900-xxx hoặc gửi yêu cầu qua form..."
Agent sẽ:
Step 1: THINK — User muốn đổi size đơn ORD-4521. Cần kiểm tra đơn hàng.
ACT → get_order_status("ORD-4521")
Step 2: OBSERVE — Đơn hàng: áo thun, size M, status "đang giao",
shipped 2 ngày trước.
THINK — Đơn đang giao, cần check chính sách đổi trả.
ACT → search_policy("đổi size khi đang giao")
Step 3: OBSERVE — Policy: "Đơn đang giao có thể đổi size nếu chưa
nhận hàng. Khách cần từ chối nhận, hoàn trả, đặt lại."
THINK — Có thể đổi được nhưng phải theo quy trình.
Cần check size L còn hàng không.
ACT → check_inventory("SKU-AT001", "L")
Step 4: OBSERVE — Size L còn 23 cái.
THINK — Đủ thông tin để trả lời. Draft email.
ACT → Trả lời khách:
"Chào anh/chị, em đã kiểm tra đơn ORD-4521 (áo thun size M).
Đơn đang trong quá trình giao hàng. Anh/chị có thể đổi sang
size L — hiện còn hàng. Cách thực hiện:
1. Khi shipper giao, từ chối nhận hàng
2. Đơn sẽ tự động hoàn về kho (2-3 ngày)
3. Em sẽ tạo đơn mới size L gửi lại cho anh/chị
Anh/chị xác nhận để em tiến hành nhé?"
4 bước, 3 tool calls, câu trả lời chính xác dựa trên data thật. Chatbot không thể làm điều này vì nó không truy cập được order system, inventory, hay policy database.
Tại sao developer cần quan tâm ngay bây giờ?
1. Agent đang thay đổi cách thiết kế software
Trước AI: bạn thiết kế UI → user click button → backend xử lý → trả kết quả. Mọi flow đều deterministic, bạn biết chính xác path nào sẽ chạy.
Với agent: user nói ý muốn bằng ngôn ngữ tự nhiên → agent tự quyết định gọi function nào, theo thứ tự nào, dựa trên context. Flow không deterministic — cùng một goal có thể chạy khác nhau tùy data.
Điều này đòi hỏi developer tư duy khác: thay vì viết code xử lý từng case, bạn viết tools (functions) và tool descriptions rõ ràng. Agent sẽ tự orchestrate. Kỹ năng mới cần: thiết kế tool API sao cho agent hiểu đúng, viết description sao cho không ambiguous, handle error sao cho agent recover được.
2. Agentic pattern đang xâm nhập mọi sản phẩm
GitHub Copilot Workspace — agent đọc issue, plan changes, viết code, tạo PR. Devin — agent viết software end-to-end. Cursor Composer — agent sửa nhiều file theo instruction. Google Gemini Deep Research — agent tự search web, đọc nhiều nguồn, tổng hợp report.
Không phải tương lai xa — những sản phẩm này đang chạy production ngay bây giờ. Nếu bạn build SaaS, e-commerce, hay bất kỳ product nào — sớm muộn sẽ có yêu cầu "thêm AI agent cho tính năng X".
3. Tool ecosystem đã mature đủ để build
Hai năm trước, build agent cần viết mọi thứ từ đầu. Giờ:
- Framework: AutoGen, CrewAI, LangGraph, Semantic Kernel — agent framework sẵn cho Python và .NET
- LLM với tool use: GPT-4o, Claude, Gemini đều support function calling native
- Vector database: pgvector, Qdrant, Pinecone — memory layer sẵn
- Observability: LangSmith, Phoenix, Helicone — debug agent loop
Stack đã đủ. Rào cản không còn là tooling — mà là hiểu cách thiết kế agent đúng.
Các pattern agent phổ biến
ReAct (Reasoning + Acting)
Pattern cơ bản nhất — agent suy nghĩ (reason) rồi hành động (act), xen kẽ:
Thought: User hỏi thời tiết Hà Nội. Tôi cần gọi weather API.
Action: get_weather("Hanoi")
Observation: 28°C, mưa nhẹ, độ ẩm 85%
Thought: Đã có dữ liệu. Trả lời user.
Answer: Hà Nội hiện tại 28°C, mưa nhẹ, độ ẩm 85%.
Đơn giản, hiệu quả cho task 1-3 bước. Phần lớn agent hiện tại dùng ReAct.
Plan-and-Execute
Agent tạo plan trước, rồi thực thi từng bước. Phù hợp cho task phức tạp nhiều bước:
Plan:
1. Lấy danh sách sản phẩm bán chạy tháng này
2. Phân tích trend so với tháng trước
3. Tìm sản phẩm có stock thấp cần reorder
4. Tạo báo cáo PDF
5. Gửi email cho inventory manager
Execute: [step 1] → [step 2] → [replan if needed] → ...
Nếu bước 3 phát hiện dữ liệu bất thường, agent có thể replan — thêm bước verify data trước khi tiếp tục.
Multi-Agent
Nhiều agent chuyên biệt cộng tác. Mỗi agent có role và toolset riêng:
Researcher Agent: search web, đọc tài liệu, tổng hợp thông tin
Writer Agent: viết draft từ research
Reviewer Agent: review draft, chỉ ra lỗi, suggest sửa
Publisher Agent: format, tạo hình ảnh, đăng bài
Orchestrator: điều phối 4 agent trên theo workflow
AutoGen và CrewAI được thiết kế cho pattern này. Mỗi agent đơn giản hơn (ít tool, ít responsibility), nhưng kết hợp lại xử lý task phức tạp.
Giới hạn cần biết — không phải phép thuật
Hallucination lan truyền
Agent gọi tool, nhận kết quả, rồi interpret sai. Ví dụ: tool trả về {"status": "cancelled"}, agent hiểu nhầm thành "đơn đã giao" rồi trả lời sai cho user. Error lan truyền qua nhiều step — càng nhiều step, càng rủi ro.
Giải pháp: thêm validation layer sau mỗi tool call, output rõ ràng unambiguous, và luôn có human-in-the-loop cho critical actions.
Cost cao hơn chatbot
Mỗi step trong agent loop = 1 LLM call. Agent 5 bước = 5 lần gọi API, gấp 5 lần cost so với chatbot trả lời một lần. Với GPT-4o ở khoảng $5-15/1M tokens, agent xử lý 1000 requests/ngày có thể tốn $50-200/tháng — đáng kể hơn chatbot nhiều.
Optimize: dùng model nhỏ cho bước đơn giản (classify, extract), model lớn chỉ cho bước reasoning. Cache tool results khi có thể.
Latency
Chatbot: 1-3 giây. Agent: 10-30 giây cho task nhiều bước (mỗi LLM call 2-5 giây, nhân 5 bước). User experience cần streaming progress: "Đang kiểm tra đơn hàng... Đang tra cứu chính sách... Đang soạn câu trả lời..."
Unpredictable behavior
Cùng input, agent có thể chọn path khác nhau — gọi tool khác, theo thứ tự khác. Debug khó hơn deterministic code. Log mọi step (thought, action, observation) là bắt buộc. Không log = không debug.
Security surface rộng hơn
Agent gọi tool = execute code/API dựa trên LLM decision. Nếu LLM bị prompt injection, nó có thể gọi delete_all_data() thay vì search_products(). Mọi tool phải có permission boundary, rate limit, và confirmation cho destructive action.
Framework nào để bắt đầu?
.NET Developer
Semantic Kernel (Microsoft) — tích hợp sâu với .NET ecosystem, support Azure OpenAI, có plugin system cho tools:
var kernel = Kernel.CreateBuilder()
.AddOpenAIChatCompletion("gpt-4o", apiKey)
.Build();
kernel.Plugins.AddFromType<OrderPlugin>();
kernel.Plugins.AddFromType<EmailPlugin>();
var agent = new ChatCompletionAgent
{
Name = "SupportAgent",
Kernel = kernel,
Instructions = "Bạn là agent hỗ trợ khách hàng..."
};
Python Developer
LangGraph — state machine cho agent workflow, từ team LangChain. Flexible, dành cho custom agent logic.
CrewAI — multi-agent framework, role-based. Setup nhanh, opinionated. Phù hợp khi cần nhiều agent cộng tác.
AutoGen (Microsoft) — conversation-based multi-agent. Mạnh cho complex orchestration.
Recommend cho người mới
Bắt đầu với ReAct agent đơn giản — 1 agent, 2-3 tools, goal cụ thể. Hiểu agent loop hoạt động thế nào trước khi nhảy vào multi-agent hay complex planning.
Build agent đầu tiên: checklist
- Chọn use case cụ thể. "Agent trả lời câu hỏi về sản phẩm dựa trên catalog" — không phải "agent làm mọi thứ".
- Định nghĩa tools. Liệt kê API/function agent cần gọi. Viết description rõ ràng — đây là "prompt engineering cho tools".
- Viết system prompt. Cho agent biết role, rules, khi nào gọi tool nào, khi nào nên hỏi lại user thay vì tự đoán.
- Implement agent loop. Dùng framework (Semantic Kernel, LangGraph) hoặc viết loop đơn giản như pseudocode trên.
- Test với edge cases. User hỏi ngoài scope? Tool trả lỗi? Hai tool mâu thuẫn kết quả? Agent cần handle gracefully.
- Thêm observability. Log mọi step: thought, tool call, tool result, final answer. Không log = không debug = không improve.
- Human-in-the-loop. Cho critical actions (gửi email, tạo order, xóa data) — agent đề xuất, human approve.
Tổng kết
AI Agent không phải chatbot thêm plugin. Nó là paradigm shift — từ "AI trả lời câu hỏi" sang "AI tự hành động để đạt mục tiêu". Bốn thành phần cốt lõi: LLM (não), tools (tay chân), memory (trí nhớ), planning (chiến lược). Agent loop observe-think-act-reflect chạy liên tục cho đến khi goal đạt được.
Với developer, điều quan trọng nhất không phải học framework nào — mà là hiểu tư duy thiết kế: thay vì code mọi flow bằng tay, bạn thiết kế tools tốt, viết description rõ ràng, và để LLM orchestrate. Kỹ năng mới cần: tool API design, prompt engineering cho agent, error handling cho non-deterministic system, và observability cho debug.
Agent không thay thế software truyền thống — nó bổ sung. Button "Mua hàng" vẫn cần. Form nhập địa chỉ vẫn cần. Nhưng bên cạnh đó, agent xử lý những task mà trước đây cần con người ngồi đọc, suy nghĩ, và hành động qua nhiều hệ thống. Đó là cơ hội lớn nhất cho developer năm 2026.
Leave a comment
Your email address will not be published. Required fields are marked *