Agentic AI là gì? Trong giai đoạn đầu của Generative AI, cách chúng ta sử dụng AI khá đơn giản. Người dùng nhập một yêu cầu, mô hình xử lý yêu cầu đó và tạo ra câu trả lời. Chúng ta có thể yêu cầu AI viết email, tóm tắt tài liệu, giải thích code, tạo câu SQL hoặc phân tích một đoạn văn bản. Khả năng này rất mạnh, nhưng phần lớn quá trình thực hiện công việc vẫn nằm ở con người.
Ví dụ, AI có thể tạo câu SQL nhưng con người vẫn phải chạy câu SQL trên Database. AI có thể viết email nhưng con người vẫn phải kiểm tra và gửi email. AI có thể phát hiện một vấn đề trong báo cáo nhưng con người vẫn phải mở một hệ thống khác để xử lý vấn đề đó.
Agentic AI mở rộng cách tiếp cận này. Thay vì chỉ đặt câu hỏi "AI có thể trả lời yêu cầu này không?", chúng ta bắt đầu đặt câu hỏi "AI có thể hoàn thành công việc này không?". Sự khác biệt giữa tạo ra một câu trả lời và thực hiện một chuỗi hành động để hoàn thành mục tiêu chính là điểm quan trọng để bắt đầu tìm hiểu Agentic AI.
Mục lục
- Agentic AI là gì?
- Chatbot, Workflow và Agent khác nhau như thế nào?
- Kiến trúc cơ bản của một AI Agent
- Model, Instructions và Context
- Tools biến khả năng suy luận thành hành động
- Một Agent phân tích doanh thu hoạt động như thế nào?
- Planning và Task Decomposition
- Context, Memory và RAG
- Autonomy, Permissions và Human-in-the-loop
- Evaluation biến Agent Development thành Engineering
- Observability và Debugging
- Agentic AI Engineer thực sự làm gì?
- Người mới nên bắt đầu từ đâu?
- Điều quan trọng nhất cần nhớ
- Kết luận
- Tài liệu tham khảo
Agentic AI là gì?
Google Cloud mô tả AI Agent là hệ thống phần mềm sử dụng AI để theo đuổi mục tiêu và hoàn thành nhiệm vụ thay mặt người dùng. Những hệ thống này có thể kết hợp các khả năng như reasoning, planning, memory và sử dụng công cụ để tương tác với những hệ thống bên ngoài.
Anthropic đưa ra một cách phân biệt rất hữu ích khi xây dựng Agent trong thực tế. Theo Anthropic, Workflow là hệ thống trong đó LLM và Tools hoạt động theo những luồng xử lý đã được lập trình trước, trong khi Agent cho phép LLM chủ động điều khiển quá trình xử lý và lựa chọn cách sử dụng Tools để hoàn thành nhiệm vụ.
Có thể hiểu đơn giản rằng Generative AI tập trung nhiều vào việc tạo ra kết quả, còn Agentic AI tập trung vào việc hoàn thành mục tiêu.
Giả sử một người quản lý hỏi:
"Doanh thu hôm qua là bao nhiêu?"
Một ứng dụng AI được kết nối với dữ liệu có thể truy vấn hệ thống và trả lời rằng doanh thu hôm qua là 520 triệu đồng. Đây chủ yếu vẫn là bài toán Question Answering.
Nhưng nếu người quản lý yêu cầu:
"Kiểm tra tình hình kinh doanh hôm qua và cho tôi biết có vấn đề gì cần xử lý."
Bài toán lúc này đã thay đổi. Hệ thống có thể phải lấy dữ liệu doanh thu, so sánh với những ngày trước, phân tích từng chi nhánh, tìm các biến động bất thường, lấy thêm dữ liệu liên quan, kiểm tra giả thuyết và cuối cùng mới đưa ra kết luận. Một yêu cầu duy nhất của người dùng có thể dẫn đến nhiều hành động khác nhau bên trong hệ thống.
Đó là tư duy nền tảng của Agentic AI.
Chatbot, Workflow và Agent khác nhau như thế nào?
Ba khái niệm Chatbot, Workflow và Agent thường được sử dụng lẫn lộn, nhưng chúng đại diện cho những mức độ khác nhau trong cách AI tham gia vào một hệ thống.
Chatbot chủ yếu nhận input và tạo output. Người dùng đặt câu hỏi, hệ thống xử lý Context và tạo câu trả lời. Một Chatbot hiện đại vẫn có thể kết nối với dữ liệu hoặc sử dụng một số công cụ, nhưng mục tiêu chính thường là phục vụ tương tác hỏi đáp.
Workflow đi xa hơn khi một nhiệm vụ được chia thành nhiều bước. Ví dụ, một hệ thống xử lý hóa đơn có thể đọc hóa đơn, trích xuất thông tin, kiểm tra dữ liệu, lưu kết quả vào Database và gửi thông báo. AI có thể tham gia vào một hoặc nhiều bước, nhưng Developer đã xác định trước luồng xử lý của hệ thống.
Agent khác ở chỗ mô hình có thể tham gia quyết định bước tiếp theo nên làm gì. Nếu người dùng yêu cầu "Tìm nguyên nhân doanh thu giảm", Developer không nhất thiết phải lập trình trước rằng hệ thống luôn kiểm tra sản phẩm trước, sau đó kiểm tra khu vực rồi mới kiểm tra tồn kho. Agent có thể nhìn vào dữ liệu ban đầu, nhận thấy một chi nhánh có biến động lớn và quyết định phân tích chi nhánh đó trước. Nếu kết quả cho thấy một nhóm sản phẩm giảm mạnh, Agent có thể tiếp tục kiểm tra tồn kho của nhóm sản phẩm đó.
Như vậy, kết quả của một bước có thể ảnh hưởng đến quyết định ở bước tiếp theo. Đây là một đặc điểm quan trọng của Agentic System.
Tuy nhiên, Agent không phải lúc nào cũng tốt hơn Workflow. Anthropic khuyến nghị bắt đầu bằng giải pháp đơn giản nhất có thể và chỉ tăng mức độ tự chủ khi điều đó thực sự mang lại giá trị. Với những quy trình rõ ràng, lặp lại và yêu cầu tính dự đoán cao, Workflow thường dễ kiểm soát hơn. Agent phù hợp hơn với những nhiệm vụ mà đường đi khó xác định hoàn toàn từ trước.
Kiến trúc cơ bản của một AI Agent
Một AI Agent không đơn giản là một LLM được gắn thêm Prompt. Trong thực tế, nó là một hệ thống phần mềm gồm nhiều thành phần phối hợp với nhau. Google Cloud mô tả kiến trúc Agent thông qua các thành phần như Model, Grounding, Tools, Data Architecture, Orchestration và Runtime.
Đối với người mới, chúng ta có thể đơn giản hóa kiến trúc đó như sau:
Model thường là LLM chịu trách nhiệm hiểu yêu cầu, phân tích Context và lựa chọn hành động. Instructions xác định vai trò, nhiệm vụ và giới hạn của Agent. Context chứa những thông tin mà Model cần ở thời điểm hiện tại. Tools cung cấp khả năng tương tác với hệ thống bên ngoài, còn Memory giúp hệ thống duy trì hoặc lấy lại những thông tin cần thiết qua thời gian.
Orchestration hoặc Agent Runtime chịu trách nhiệm điều phối toàn bộ quá trình. Nó quản lý việc gọi Model, thực thi Tool, đưa kết quả trở lại Context, kiểm tra điều kiện dừng và xử lý lỗi. Khi hệ thống được đưa vào production, các thành phần như Guardrails, Permissions, Logging, Tracing và Evaluation cũng trở nên rất quan trọng.
Điểm cần nhớ ở đây là LLM chỉ là một thành phần của Agent, không phải toàn bộ Agent.
Model, Instructions và Context
Model đóng vai trò quan trọng trong việc reasoning và lựa chọn hành động. Giả sử người dùng yêu cầu "Kiểm tra xem khách hàng nào có nguy cơ rời bỏ dịch vụ". Model cần hiểu khách hàng nằm ở nguồn dữ liệu nào, những tín hiệu nào có thể liên quan đến churn, cần sử dụng Tool nào và liệu dữ liệu hiện tại đã đủ để đưa ra nhận định hay chưa.
Model cũng cần Instructions rõ ràng. Một Sales Analytics Agent có thể được yêu cầu chỉ phân tích dữ liệu bán hàng, giải thích kết luận dựa trên dữ liệu được cung cấp, không được thay đổi dữ liệu production và phải yêu cầu phê duyệt trước khi thực hiện bất kỳ hành động nào ảnh hưởng đến khách hàng. Instructions càng rõ thì phạm vi hoạt động của Agent càng dễ kiểm soát.
Context là toàn bộ thông tin Model có thể sử dụng trong một lần xử lý. Nó có thể bao gồm System Instructions, câu hỏi của người dùng, lịch sử hội thoại, Tool definitions, tài liệu được Retrieval lấy về và kết quả của những Tool đã chạy trước đó.
Điều này dẫn đến một nguyên tắc rất quan trọng trong Agentic AI Engineering: không phải cứ cung cấp nhiều Context hơn thì Agent sẽ tốt hơn. Context không liên quan có thể tạo noise, làm tăng chi phí và khiến Model khó tập trung vào những thông tin thực sự quan trọng.
Tools biến khả năng suy luận thành hành động
Một LLM có thể rất giỏi xử lý ngôn ngữ nhưng bản thân nó không tự nhiên có quyền truy cập vào Database, CRM, Data Warehouse hoặc hệ thống kế toán của doanh nghiệp. Muốn Agent thực hiện công việc, chúng ta cần cung cấp Tools.
Một Tool có thể đơn giản là một function như:
get_sales_data()
get_inventory()
search_customer()
create_report()
Trong hệ thống thực tế, Tool có thể kết nối với PostgreSQL, MySQL, BigQuery, CRM, ERP, Email, Search Engine, Python hoặc một API nội bộ. Model nhận được mô tả của các Tool, xác định Tool phù hợp với nhiệm vụ và tạo arguments cần thiết. Agent Runtime sau đó thực thi Tool và đưa kết quả trở lại cho Model.
Ví dụ, Agent cần kiểm tra tồn kho của sản phẩm P001 tại chi nhánh HCM_02. Nó có thể yêu cầu thực thi:
get_inventory(
product_id="P001",
store_id="HCM_02"
)
Tool trả về:
{
"product_id": "P001",
"store_id": "HCM_02",
"quantity": 0
}
Model không cần đoán số lượng tồn kho. Nó sử dụng dữ liệu được Tool trả về để tiếp tục reasoning. Có thể hiểu Model chịu trách nhiệm lựa chọn và phân tích, trong khi Tool cung cấp khả năng tương tác với dữ liệu và hệ thống thật.
Tool Calling vì vậy là một trong những cơ chế nền tảng nhất của Agentic AI.
Một Agent phân tích doanh thu hoạt động như thế nào?
Hãy xem một ví dụ hoàn chỉnh hơn. Người quản lý yêu cầu:
"Phân tích doanh thu hôm qua và cho tôi biết có vấn đề gì cần xử lý."
Agent trước tiên xác định Goal là tìm những biến động đáng chú ý trong hoạt động bán hàng. Nó có thể quyết định lấy doanh thu hôm qua theo từng chi nhánh và so sánh với dữ liệu lịch sử.
Agent gọi:
get_sales_by_store(date="2026-09-14")
Giả sử kết quả cho thấy HCM_01 đạt 180 triệu đồng, HCM_02 đạt 92 triệu đồng và HCM_03 đạt 171 triệu đồng. Những con số này chưa đủ để kết luận điều gì, vì Agent chưa có dữ liệu tham chiếu.
Agent tiếp tục lấy doanh thu trung bình 30 ngày của từng chi nhánh. Kết quả cho thấy HCM_01 trung bình 175 triệu đồng, HCM_02 trung bình 138 triệu đồng và HCM_03 trung bình 168 triệu đồng. Lúc này HCM_02 trở thành điểm cần chú ý vì doanh thu thấp đáng kể so với mức tham chiếu.
Một hệ thống Question Answering đơn giản có thể dừng ở đây và báo rằng doanh thu HCM_02 giảm mạnh. Agent có thể đi xa hơn. Nó quyết định phân tích doanh thu theo sản phẩm tại HCM_02 và phát hiện sản phẩm P001 đóng góp phần lớn vào mức giảm. Sau đó Agent gọi Tool kiểm tra tồn kho và nhận được thông tin P001 đã hết hàng từ 14:05.
Agent lúc này có nhiều bằng chứng hơn để đưa ra nhận định:
"Chi nhánh HCM_02 có doanh thu thấp đáng kể so với mức trung bình 30 ngày. Sản phẩm P001 đóng góp lớn vào mức giảm và dữ liệu tồn kho cho thấy sản phẩm này hết hàng từ 14:05."
Một chi tiết quan trọng là Agent không nên lập tức kết luận rằng "doanh thu giảm là do hết hàng". Dữ liệu hiện tại cho thấy hai hiện tượng có liên quan và việc hết hàng có thể là một yếu tố đáng chú ý, nhưng chưa đủ để chứng minh toàn bộ quan hệ nhân quả.
Đây là một vấn đề quan trọng trong thiết kế Agent. Một Agent tốt không chỉ cần tìm được dữ liệu mà còn phải hiểu giới hạn của kết luận mà dữ liệu đó hỗ trợ.
Planning và Task Decomposition
Những nhiệm vụ thực tế thường không thể giải quyết bằng một Tool Call duy nhất. Một yêu cầu như "Tìm nguyên nhân doanh thu quý này giảm" có thể cần phân tích doanh thu tổng, khu vực, sản phẩm, số lượng khách hàng, giá trị đơn hàng trung bình, tỷ lệ hủy, tồn kho và nhiều yếu tố khác.
Agent có thể chia nhiệm vụ lớn thành những nhiệm vụ nhỏ hơn. Khả năng này thường được gọi là Task Decomposition. Sau mỗi bước, Agent sử dụng kết quả vừa nhận được để quyết định liệu kế hoạch hiện tại có còn phù hợp hay cần thay đổi.
Tuy nhiên, Planning càng nhiều bước không có nghĩa hệ thống càng thông minh. Mỗi bước bổ sung có thể làm tăng latency, chi phí, số lần gọi Tool và xác suất xảy ra lỗi. Một Agent thực hiện 15 bước để giải quyết bài toán chỉ cần 3 bước không phải là một Agent tốt.
Đây là lý do thiết kế Agent luôn phải cân bằng giữa autonomy và control, giữa khả năng linh hoạt của Model và tính ổn định của phần mềm truyền thống.
Context, Memory và RAG
Context và Memory là hai khái niệm liên quan nhưng không giống nhau. Context là những thông tin Model đang có để xử lý nhiệm vụ hiện tại, trong khi Memory là cơ chế giúp hệ thống lưu hoặc lấy lại thông tin có ích qua thời gian.
Ví dụ, người dùng yêu cầu "Phân tích doanh thu miền Nam", sau đó hỏi "So sánh với tháng trước". Context của cuộc hội thoại giúp Agent hiểu rằng câu hỏi thứ hai vẫn đang nói về doanh thu miền Nam. Với những hệ thống hoạt động dài hạn, Memory có thể được sử dụng để lưu một số thông tin cần thiết qua nhiều phiên làm việc.
Memory không nên được hiểu là lưu toàn bộ mọi thứ. Dữ liệu được lưu có thể lỗi thời, không chính xác, chứa thông tin nhạy cảm hoặc không còn phù hợp với nhiệm vụ hiện tại. Vì vậy, Agentic AI Engineer cần xác định thông tin nào được lưu, lưu trong bao lâu, thuộc về người dùng nào và ai có quyền truy cập.
Một thành phần khác thường xuất hiện trong Agentic System là Retrieval-Augmented Generation, hay RAG. LLM có kiến thức từ quá trình training, nhưng doanh nghiệp cần Agent làm việc với dữ liệu riêng như chính sách nội bộ, tài liệu sản phẩm, hợp đồng, Database và Data Warehouse.
Nếu người dùng hỏi về chính sách hoàn tiền, hệ thống không nên để Model trả lời dựa trên kiến thức chung. Nó có thể tìm phiên bản chính sách hiện tại, đưa nội dung liên quan vào Context rồi yêu cầu Model trả lời dựa trên tài liệu đó.
Đối với Agent, Retrieval đặc biệt quan trọng vì thông tin lấy được không chỉ ảnh hưởng đến câu trả lời mà còn có thể ảnh hưởng đến hành động tiếp theo. Nếu Retrieval lấy sai tài liệu, Agent có thể không chỉ trả lời sai mà còn thực hiện sai hành động.
Autonomy, Permissions và Human-in-the-loop
Một trong những hiểu lầm phổ biến về Agentic AI là Agent càng tự động càng tốt. Trong thực tế, mức độ tự chủ cần được thiết kế dựa trên mức độ rủi ro của nhiệm vụ.
Một Tool chỉ đọc dữ liệu như get_sales() thường có phạm vi ảnh hưởng thấp hơn Tool như update_customer(). Những hành động như gửi email hàng loạt, xóa dữ liệu, thay đổi giá sản phẩm hoặc thực hiện giao dịch tài chính có thể tạo hậu quả lớn nếu Agent đưa ra quyết định sai.
Khi thiết kế Tool, chúng ta cần quan tâm đến blast radius, tức phạm vi thiệt hại có thể xảy ra nếu Tool được sử dụng sai. Những Tool có rủi ro cao có thể cần permission, validation, rate limit, audit log, khả năng rollback hoặc sự phê duyệt của con người.
Human-in-the-loop vì vậy vẫn đóng vai trò quan trọng. Một Agent có thể phân tích dữ liệu và đề xuất giảm giá cho khách hàng có nguy cơ churn, nhưng con người có thể cần phê duyệt trước khi chương trình giảm giá thực sự được áp dụng. Với một nhiệm vụ khác có rủi ro thấp hơn, Agent có thể được phép tự thực hiện.
Không tồn tại một mức autonomy phù hợp với mọi Agent. Một hệ thống tốt phải xác định AI được phép tự quyết định đến đâu đối với từng loại hành động.
Evaluation biến Agent Development thành Engineering
Một lỗi phổ biến khi phát triển Agent là Developer thử vài câu hỏi, thấy Agent trả lời tốt rồi kết luận hệ thống đã hoạt động ổn định. Đây chưa phải Evaluation.
Giả sử chúng ta xây một Sales Analytics Agent. Thay vì kiểm thử bằng cảm giác, nhóm phát triển có thể xây dựng một tập nhiệm vụ gồm các tình huống như tìm chi nhánh bất thường, so sánh doanh thu, xác định sản phẩm suy giảm, xử lý câu hỏi thiếu thông tin và từ chối yêu cầu vượt quyền.
Sau đó hệ thống có thể đo các chỉ số như Task Success Rate, Correct Tool Selection, Tool Call Accuracy, Permission Violation, Latency, Cost và Failure Rate.
Ví dụ:
Task Success Rate: 91%
Correct Tool Selection: 96%
SQL Execution Success: 98%
Unauthorized Actions: 0%
Average Latency: 8.4s
Nếu nhóm phát triển thay đổi Model, Prompt hoặc Tool description, cùng một bộ Evaluation có thể được chạy lại. Khi Version A đạt Task Success Rate 91% còn Version B đạt 94%, chúng ta bắt đầu có bằng chứng để đánh giá thay đổi thay vì chỉ dựa vào cảm giác.
Evaluation chính là một trong những yếu tố giúp chuyển việc xây dựng Agent từ một bản demo thành một quá trình Engineering có thể đo lường.
Observability và Debugging
Agent khó Debug hơn một API truyền thống vì một yêu cầu có thể tạo ra nhiều LLM Call và Tool Call. Nếu kết quả cuối cùng sai, Developer cần biết Agent đã chọn Tool nào, arguments là gì, Tool trả về dữ liệu nào, bước nào mất nhiều thời gian và lỗi xuất hiện ở đâu.
Vì vậy Agent production cần Logging và Tracing. Một Trace có thể ghi lại toàn bộ quá trình thực hiện nhiệm vụ:
Task ID: 82931
Step 1: classify_request
Step 2: get_sales_data
Step 3: analyze_sales
Step 4: get_inventory
Step 5: generate_findings
Duration: 7.8s
Tool calls: 2
Status: success
Observability giúp đội ngũ hiểu Agent đang hoạt động như thế nào trong môi trường thật. Khi Agent thất bại, chúng ta có dữ liệu để điều tra thay vì đoán.
Điều này càng quan trọng khi Agent có mức autonomy cao, vì cùng một nhiệm vụ Model có thể lựa chọn những đường đi khác nhau.
Agentic AI Engineer thực sự làm gì?
Đến đây có thể thấy Agentic AI Engineering không chỉ là Prompt Engineering. Một Agent production có thể liên quan đến LLM, Prompt, Context, Tool Calling, API, Database, RAG, Memory, Workflow, Authentication, Authorization, Guardrails, Evaluation, Logging, Tracing, Deployment và Monitoring.
Vì vậy Agentic AI Engineering nằm ở giao điểm của Software Engineering, Data, AI và Automation. Người làm Agentic AI không nhất thiết phải là AI Researcher và cũng không cần tự train một LLM từ đầu. Nhưng họ cần hiểu cách biến khả năng của Model thành một hệ thống phần mềm có thể hoạt động ổn định, đo lường được và kiểm soát được.
Đây cũng là lý do kiến thức Software Engineering và Data Engineering rất có giá trị khi bước vào Agentic AI. Một Agent cuối cùng vẫn phải làm việc với API, dữ liệu, authentication, permissions, state, error handling và infrastructure giống những hệ thống phần mềm khác.
Người mới nên bắt đầu từ đâu?
Một sai lầm phổ biến là bắt đầu ngay bằng Multi-Agent System, Agent Swarm hoặc những kiến trúc có nhiều Agent phối hợp với nhau. Những khái niệm này hấp dẫn, nhưng chúng làm tăng rất nhanh độ phức tạp của hệ thống.
Một điểm bắt đầu tốt hơn là xây một Agent có một nhiệm vụ và một Tool. Ví dụ, Agent nhận câu hỏi về doanh thu, gọi một Tool lấy dữ liệu từ Database rồi trả lời dựa trên kết quả thật.
Khi hệ thống này hoạt động ổn định, có thể thêm nhiều Tools như get_sales(), get_inventory() và get_customer(). Lúc này bài toán mới xuất hiện: Agent có chọn đúng Tool hay không? Sau đó có thể thêm RAG để Agent đọc tài liệu, thêm Memory để duy trì State, thêm Evaluation để đo chất lượng và cuối cùng thêm Guardrails cùng Human Approval khi Agent bắt đầu thực hiện những hành động có ảnh hưởng thật.
Cách học này giúp người mới hiểu từng thành phần thay vì che giấu toàn bộ độ phức tạp phía sau một framework.
Điều quan trọng nhất cần nhớ
Agentic AI không phải phép thuật. Một Agent vẫn là một hệ thống phần mềm với input, state, model, data, tools, permissions, business logic, output và những failure mode cần được kiểm soát. Điểm khác biệt là một phần logic ra quyết định trước đây phải được Developer xác định cứng bằng code giờ có thể được giao cho Model dựa trên mục tiêu và Context.
Ví dụ, trong phần mềm truyền thống Developer có thể viết:
if condition_a:
call_tool_a()
elif condition_b:
call_tool_b()
Trong Agentic System, Model có thể được cung cấp nhiều Tools và tự lựa chọn Tool phù hợp dựa trên nhiệm vụ hiện tại. Điều này tạo ra khả năng thích ứng rất lớn, nhưng đồng thời khiến hệ thống ít deterministic hơn. Cùng một nhiệm vụ, Agent có thể lựa chọn những đường đi khác nhau hoặc mắc lỗi ở những bước khác nhau.
Vì vậy, khi autonomy tăng lên, nhu cầu về Evaluation, Guardrails, Permissions và Observability cũng tăng theo. Đây là một trong những tư duy quan trọng nhất khi chuyển từ việc thử nghiệm LLM sang xây dựng Agentic System trong thực tế.
Học tiếp về Agentic AI là gì và cách xây dựng hệ thống
Sau khi hiểu Agentic AI là gì, bạn có thể đọc tiếp bài cấu tạo AI Agent và tham khảo roadmap Agentic AI Engineer để học theo từng giai đoạn.
Kết luận
Generative AI giúp máy tính ngày càng giỏi tạo ra nội dung, còn Agentic AI mở rộng khả năng đó sang việc thực hiện công việc hướng đến một mục tiêu. Một Agent có thể nhận mục tiêu, hiểu Context, lập kế hoạch, lựa chọn Tool, thực hiện hành động, quan sát kết quả và điều chỉnh bước tiếp theo.
Nhưng xây dựng Agent không chỉ là làm cho AI tự động hơn. Khi Agent bắt đầu truy cập Database, gọi API và thực hiện hành động thật, chúng ta đồng thời phải giải quyết các vấn đề về Accuracy, Security, Permissions, Evaluation, Observability, Cost, Reliability và Human Oversight.
Đó là lý do Agentic AI Engineering nên được nhìn nhận như một lĩnh vực Engineering chứ không chỉ là một kỹ thuật Prompt. Nó kết hợp Software Engineering, Data, AI và Automation để biến khả năng reasoning của các mô hình AI thành những hệ thống có thể thực sự tham gia vào công việc.
Nếu bạn mới bắt đầu, đừng vội xây một hệ thống có 10 Agent. Hãy bắt đầu bằng một Agent, một nhiệm vụ và một Tool. Hiểu cách Model lựa chọn hành động, cách Tool Calling hoạt động, cách dữ liệu đi vào Context, cách Agent thất bại và quan trọng nhất là cách đo xem Agent có thực sự hoàn thành nhiệm vụ hay không.
Khi những nền tảng này đã chắc, các kiến trúc Agentic AI phức tạp hơn sẽ trở nên dễ hiểu hơn rất nhiều.
Tài liệu tham khảo
- Google Cloud. What are AI agents? Definition, examples, and types. Tài liệu tổng quan về AI Agent, reasoning, planning, memory, tools và mức độ tự chủ.
- Google Cloud. Core concepts of AI agents. Tài liệu mô tả các thành phần của AI Agent gồm Model, Grounding, Tools, Data Architecture, Orchestration và Runtime.
- Google Cloud Documentation. Generative AI glossary: AI agents. Tài liệu kỹ thuật về Agent, Orchestration, Model, Tools, Memory, Reasoning và Planning.
- Anthropic. Building Effective Agents. Anthropic Engineering, 2024. Tài liệu phân biệt Workflow và Agent, đồng thời trình bày các pattern để xây dựng Agentic System.
- Anthropic. Writing Effective Tools for AI Agents. Anthropic Engineering, 2025. Tài liệu về thiết kế, mô tả và đánh giá Tools dành cho AI Agent.
- National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. NIST AI 600-1, 2024. Tài liệu về quản trị, đánh giá và kiểm soát rủi ro đối với hệ thống Generative AI.
TechData.AI - Leading The Future.
Hoàng Minh.