AI, SEO và Digital Marketing cho thị trường Việt Namhttps://nguyennlt.com/vi-VNhttps://nguyennlt.com/ai/multi-agent-orchestration-la-gi/https://nguyennlt.com/ai/multi-agent-orchestration-la-gi/Multi-Agent Orchestration là lớp chia việc, gom kết quả và bắt lỗi giữa nhiều AI Agent. Thêm Agent chưa chắc thông minh hơn nếu không có lớp đó.Sat, 22 Aug 2026 14:00:00 GMT> **Trả lời nhanh:** Multi-Agent Orchestration là lớp chia việc, gom kết quả và bắt lỗi giữa nhiều AI Agent, tức nhiều chương trình dùng model để tự chọn bước và gọi tool hướng tới một mục tiêu. Nhiều agent đứng cạnh nhau chưa phải là orchestration, vì chưa có chỗ nào quyết định ai làm gì và chịu kết quả cuối. Vì vậy thêm agent chưa chắc làm hệ thống thông minh hơn. Một shop online mà agent bán hàng báo khách còn hàng trong khi agent kiểm kho thấy đã hết là hình ảnh dễ thấy nhất của việc thiếu lớp này. Khi một AI Agent làm chưa tròn việc, phản xạ phổ biến là thêm một agent nữa. Một agent lo trả lời khách, một agent lo kho, một agent lo hóa đơn, nghe giống một đội ngũ đang lớn dần lên. Đằng sau phản xạ đó là một niềm tin ngầm: hệ thống chưa thông minh vì thiếu agent, cứ thêm là khôn ra. Hình dung một shop online nhận đơn. Agent A trả lời khách rằng mẫu áo còn hàng. Agent B kiểm kho thấy mẫu đó vừa hết. Agent C nhanh nhẹn lập xong hóa đơn. Ba agent đều chăm chỉ, đều làm đúng phần mình, vậy mà khách đang cầm hóa đơn cho một món không còn trên kệ. Đây là minh họa chứ không phải chuyện của một shop cụ thể, nhưng cái giá của kiểu nhầm này rất thật: tiền chạy ba agent tốn đủ, còn lòng tin của khách rơi mất ở đúng bước cuối. Chỗ hỏng không nằm ở số agent. Chỗ hỏng nằm ở việc chưa có ai chia việc, chuyền thông tin, gom kết quả và bắt lỗi trước khi câu trả lời đến tay khách. Mình sẽ cùng bạn tách rõ hai thứ hay bị trộn làm một: một đống agent đứng cạnh nhau và một hệ thống được điều phối. Tách được rồi, bạn sẽ tự trả lời được câu mà nhiều người bỏ qua: khi nào nhiều agent đáng tiền, khi nào một agent là đủ.  _Multi-Agent Orchestration là ba việc đó cộng lại. Thiếu một việc thì nhiều agent vẫn chỉ đứng cạnh nhau._ ## Multi-Agent Orchestration là gì? Multi-Agent Orchestration là việc phối hợp nhiều AI Agent chuyên biệt trong một hệ thống thống nhất, để tất cả cùng hướng về một mục tiêu chung thay vì mỗi agent chạy theo mục tiêu riêng. Theo [IBM](https://www.ibm.com/think/topics/ai-agent-orchestration), lớp phối hợp này lo ba phần việc chính: cho các agent trao đổi thông tin với nhau, phân vai ai làm bước nào và xử lý khi kết quả của hai agent đá nhau. Chỗ đứng ra làm mấy việc đó thường được gọi là orchestrator, tức chỗ quyết định agent nào làm bước nào và chịu kết quả cuối. Trong cảnh shop online ở đầu bài, orchestrator là nơi quy định Agent A chỉ được hứa với khách sau khi Agent B đã báo số tồn kho, còn Agent C chỉ lập hóa đơn khi hai thông tin kia khớp nhau.  _Cùng ba agent đó, khác nhau ở một điểm chịu kết quả cuối. Bên trái mỗi agent đúng phần mình mà khách vẫn nhận sai. Bên phải sai sót bị chặn lại trước khi kịp thành lời hứa._ Điểm dễ nhầm nhất là tưởng cứ cắm nhiều agent vào cùng một hệ thống là xong. Cắm nhiều agent giống thuê ba nhân viên giỏi rồi cho ngồi ba phòng kín, không ai biết hai người kia đang làm gì. Orchestration mới là phần tạo ra hệ thống: nó nối ba phòng đó lại, quy định thông tin chạy theo đường nào và ai được nói câu cuối với khách. Có một điểm nhỏ nhưng đáng nói rõ. Orchestration, tức lớp điều khiển bước, tool, retry và điểm dừng, tồn tại ngay cả khi hệ chỉ có một agent chạy nhiều bước. Mình đã viết riêng chuyện đó trong bài [vì sao AI Agent cần platform thay vì prompt](/ai/vi-sao-ai-agent-can-platform-thay-vi-prompt). Multi-Agent Orchestration là phần việc cộng thêm khi có từ hai agent trở lên cùng chia nhau một kết quả cho khách: ngoài chuyện điều khiển từng agent, còn phải điều phối giữa các agent với nhau. Còn nếu bạn chưa chắc AI Agent khác gì một chatbot chỉ biết trả lời theo kịch bản, bạn có thể đọc trước bài [AI Agent khác chatbot ở điểm nào](/ai/ai-agent-khac-chatbot-o-diem-nao). Phần còn lại của bài này sẽ nhẹ hơn nhiều. ## Nhiều Agent đứng cạnh nhau khác một hệ thống được điều phối ở chỗ nào? Muốn phân biệt, bạn đừng đếm đầu agent. Hãy đọc ba dấu hiệu của một hệ được điều phối, đủ cả ba mới tính. Shop nào thiếu một trong ba, dù chạy năm hay bảy agent, vẫn chỉ là một nhóm nhân viên chăm chỉ không nói chuyện với nhau.  _Ba dấu hiệu này đi cùng nhau. Đếm được năm agent mà thiếu một dấu hiệu thì hệ vẫn chưa được điều phối._ ### Cùng một việc, không phải ba việc rời Nhìn từ phía khách, shop chỉ có một việc: bán được món hàng có thật, đúng giá, kèm hóa đơn khớp. Trả lời khách, kiểm kho và lập hóa đơn chỉ là ba mảnh của việc đó. Một hệ được điều phối định nghĩa kết quả chung trước, rồi mới chia mảnh cho từng agent. Còn khi ba agent đứng cạnh nhau, mỗi agent tự tối ưu mảnh của mình: Agent A muốn trả lời thật nhanh, Agent B muốn số kho thật chuẩn, Agent C muốn hóa đơn thật đúng mẫu. Cả ba đạt chỉ tiêu riêng mà việc chung vẫn đổ, vì không ai được giao chịu trách nhiệm cho kết quả cuối. ### Có chỗ chia việc và chuyền thông tin Dấu hiệu thứ hai là thông tin có đường đi rõ ràng giữa các agent. Trong shop được điều phối, orchestrator quyết định thứ tự: Agent B kiểm kho trước, số tồn kho được chuyền cho Agent A, sau đó Agent A mới được hứa với khách. Bạn có thể thử hỏi bất kỳ hệ nhiều agent nào hai câu: thông tin của agent này sang agent kia bằng đường nào, ai quyết định thứ tự làm việc. Nếu không ai chỉ ra được, các agent chỉ đang đứng cạnh nhau chứ chưa được điều phối. ### Có chỗ gom kết quả và bắt lỗi trước khi trả lời khách Dấu hiệu thứ ba nằm ở cuối đường đi. Trước khi câu trả lời rời khỏi hệ thống, phải có một chỗ gom kết quả của các agent lại và soi xem chúng có khớp nhau không. Lời hứa còn hàng có khớp số tồn kho không. Hóa đơn có khớp món khách đặt không. Ở shop không điều phối, sai sót chỉ lộ ra khi khách phát hiện, tức là lộ ở chỗ đắt nhất. Ở shop có chỗ chịu kết quả cuối, sai sót bị chặn từ bên trong, khách chỉ thấy một câu trả lời đã qua kiểm. ## Vì sao thêm Agent chưa chắc làm hệ thống thông minh hơn? Đọc được ba dấu hiệu rồi, câu hỏi tiếp theo là vì sao thiếu chúng lại tai hại đến vậy. Câu trả lời không phải vì model của bạn yếu. Model, tức hệ thống đã được huấn luyện để sinh văn bản hoặc quyết định, mạnh đến đâu cũng không bù được cấu trúc thiếu điều phối. Vấn đề là cứ tách một việc cho nhiều agent thì bạn phải trả ba cái giá. Điều phối tốt chỉ giúp giảm chứ không xóa được.  _Ba cái giá xuất hiện ngay khi việc được tách cho nhiều agent. Điều phối tốt làm giá rẻ đi, nhưng không biến nó thành miễn phí._ ### Việc bị cắt vụn, mỗi Agent chỉ thấy một mảnh Mỗi agent chỉ đọc được phần thông tin nằm trong context window (cửa sổ ngữ cảnh) của nó, tức phần dữ liệu mà model nhìn thấy trong một lần làm việc. Khi shop tách việc cho ba agent, Agent A chỉ thấy đoạn chat với khách, không thấy số kho. Agent B chỉ thấy số kho, không biết Agent A vừa hứa gì. Không agent nào nắm đủ bức tranh để tự phát hiện mâu thuẫn. [Anthropic, khi kể lại cách họ xây hệ nghiên cứu multi-agent](https://www.anthropic.com/engineering/built-multi-agent-research-system), tức hệ có từ hai AI Agent trở lên cùng làm một việc, cũng nói thẳng: kiểu hệ này hợp với việc tách được thành các nhánh độc lập. Khi mọi agent cần chung một ngữ cảnh hoặc các bước phụ thuộc nhau dày đặc thì đây là lựa chọn tồi. Họ lấy phần lớn việc lập trình làm ví dụ. Nếu muốn hiểu sâu hơn vì sao agent hay quên giữa chừng, mình có bài riêng về [memory (bộ nhớ) trong AI Agent và context window](/ai/memory-trong-ai-agent-context-window). ### Lỗi của một Agent lan sang bước sau Cái giá thứ hai đau hơn vì lỗi không đứng yên. Agent B đọc nhầm tồn kho một lần, Agent C lập hóa đơn dựa trên con số nhầm đó, Agent A lại dùng hóa đơn để trấn an khách. Một lỗi nhỏ ở đầu chuỗi thành ba lỗi ở cuối chuỗi.  _Đọc sơ đồ từ phải sang trái. Khách thấy hóa đơn sai là bước cuối. Gốc lệch nằm ở bước kho._ Một nhóm tác giả từ Google Research, Google DeepMind, MIT và University of Washington đã đo chuyện này trong preprint [Towards a Science of Scaling Agent Systems](https://doi.org/10.21203/rs.3.rs-8414536/v1) công bố ngày 23/01/2026. Họ chạy 180 cấu hình, so năm kiểu kiến trúc từ single-agent, tức hệ một AI Agent làm hết việc, đến các biến thể multi-agent khác nhau, trên ba họ LLM (Large Language Model) và bốn benchmark. Tool, prompt và ngân sách token được giữ ngang nhau. Token là đơn vị chữ mà model đọc và viết, cũng là đơn vị tính tiền. Trong điều kiện đó, các agent độc lập không ai điều phối khuếch đại lỗi lên 17,2 lần, còn điều phối tập trung ghìm mức khuếch đại xuống 4,4 lần. Với các việc phải làm lần lượt theo kế hoạch, mọi biến thể multi-agent họ thử đều làm kết quả giảm 39 đến 70%. Chiều ngược lại cũng có: với dạng suy luận tài chính có cấu trúc, điều phối tập trung cải thiện 80,8% so với một agent đơn trong cùng bài đo. Đây là preprint chưa qua phản biện chính thức, nên hãy đọc nó như xu hướng của một bài đo có kiểm soát chứ không phải định luật cho mọi shop. Điều nó gợi ý khá rõ: thứ quyết định không phải số agent, mà là có ai ghìm lỗi lại giữa các bước hay không. ### Tốn thêm lượt gọi, thời gian và tiền Cái giá thứ ba dễ hiểu nhất: mỗi agent thêm vào là thêm lượt gọi model, thêm thời gian chờ và thêm token. [Anthropic cho biết](https://www.anthropic.com/engineering/built-multi-agent-research-system) trong hệ của họ, một agent thường dùng token gấp khoảng 4 lần một cuộc chat thường, còn cả hệ multi-agent dùng gấp khoảng 15 lần. Họ không nói vậy để chê: với việc giá trị cao và tách được để chạy song song, khoản chi đó đáng. Vấn đề là nhiều việc trong shop không thuộc nhóm đó. Nghiên cứu Google và MIT ở phần trước còn ghi nhận một kiểu trần riêng: khi một agent đơn đã đạt trên khoảng 45% độ chính xác cho một việc trong bốn benchmark của họ, thêm agent thường chỉ mang lại lợi ích giảm dần hoặc âm. Hai con số đó không cùng một phép tính. 15 lần token là số Anthropic đo trên hệ nghiên cứu của họ. Trần khoảng 45% là ngưỡng trong bốn benchmark của Google và MIT. Cùng một bài học: đừng trả thêm lượt gọi nếu hình dạng việc không cần nhiều agent. ## Khi nào nhiều Agent đáng, khi nào một Agent đủ? Ba cái giá đó không có nghĩa là multi-agent luôn dở. Chúng có nghĩa là quyết định không nên bắt đầu từ số agent. Hãy nhìn hình dạng của việc: việc đó tách được không, các mảnh có phải chờ nhau không.  _Việc tách được và chạy song song mới là đất của nhiều agent. Việc phải làm lần lượt, bước sau chờ bước trước, thường một agent làm tốt hơn cả nhóm._ ### Việc tách được và có thể làm cùng lúc Có những việc chia được thành các nhánh gần như không đụng nhau. Shop cần rà tồn kho của 500 mẫu nằm ở ba kho, mỗi nhánh tự tra tự đếm, cuối cùng gom số về một chỗ. Đây là dạng việc Anthropic mô tả là hợp với multi-agent: giá trị đủ cao để bõ tiền token, các nhánh chạy song song nên tổng thời gian ngắn lại rõ rệt. Điều kiện đi kèm vẫn là phải có chỗ gom kết quả, vì ba nhánh chạy nhanh mà số không được đối chiếu vẫn quay về đúng cảnh hóa đơn ma ở đầu bài. ### Việc phải làm lần lượt, bước sau phụ thuộc bước trước Chuỗi nhận đơn của shop là ví dụ ngược lại: phải hỏi khách trước, kiểm kho sau, khớp xong mới được lập hóa đơn. Mỗi bước cần biết bước trước vừa làm gì. Tách chuỗi này cho ba agent nghĩa là liên tục đóng gói ngữ cảnh để chuyền qua lại, mỗi lần chuyền là một lần rơi rớt thông tin. Con số giảm 39 đến 70% ở phần trước đo đúng dạng việc này. Với chuỗi phụ thuộc, một agent đọc được toàn bộ câu chuyện từ đầu đến cuối thường đáng tin hơn một nhóm agent chuyền tay nhau từng mảnh giấy. ### Chưa rõ việc có tách được không Trường hợp phổ biến nhất là bạn chưa biết. Hướng dẫn trong [Cloud Adoption Framework của Microsoft](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai-agents/single-agent-multiple-agents) (bài đăng 01/12/2025, cập nhật 27/02/2026) khuyên khá thẳng: hãy bắt đầu bằng cách thử một agent duy nhất, trừ khi việc buộc phải tách vì ranh giới bảo mật hoặc tuân thủ, vì nhiều đội cùng vận hành, hoặc vì kế hoạch mở rộng đòi tách thành phần từ sớm. Họ cũng lưu ý rằng việc có nhiều vai khác nhau, như người lập kế hoạch, người rà soát, người thực thi, không tự động biện minh cho multi-agent, vì một agent có thể lần lượt đổi vai. Một tài liệu khác của Microsoft về [các mẫu thiết kế AI agent](https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/ai-agent-design-patterns) tóm ý này thành một câu dễ nhớ: chọn mức phức tạp thấp nhất mà vẫn chạy được việc, chỉ thêm agent khi một agent không còn đáng tin cho việc đó. ## Câu hỏi thường gặp Đến đây bạn đã nắm khung chính. Còn lại vài câu hỏi hay xuất hiện khi mới gặp khái niệm này, mình gom vào một chỗ và trả lời theo cơ chế chứ không theo tên sản phẩm. ### Một Agent có cần orchestration không? Có, nếu agent đó chạy nhiều bước. Một agent xử lý đơn hàng vẫn cần lớp điều khiển xem bước nào chạy trước, tool nào được gọi, sai thì thử lại mấy lần và dừng ở đâu. Mình đã viết kỹ trong bài [vì sao AI Agent cần platform thay vì prompt](/ai/vi-sao-ai-agent-can-platform-thay-vi-prompt). Multi-Agent Orchestration là tầng cộng thêm khi xuất hiện agent thứ hai trở đi: lúc đó phải lo thêm chuyện chia việc giữa các agent và ai chịu kết quả cuối. ### Chạy nhiều chatbot cạnh nhau đã là Multi-Agent Orchestration chưa? Chưa, vì hai lý do. Thứ nhất, chatbot chỉ trả lời theo lượt chứ không tự chọn bước và gọi tool hướng tới mục tiêu, nên chatbot chưa phải agent, khác biệt này mình giải thích trong bài [AI Agent khác chatbot ở điểm nào](/ai/ai-agent-khac-chatbot-o-diem-nao). Thứ hai, kể cả khi thay chatbot bằng agent thật, đứng cạnh nhau vẫn thiếu chỗ chia việc, gom kết quả và bắt lỗi. Thiếu lớp đó, bạn có nhiều cái miệng trả lời chứ chưa có một hệ thống. ### Model mạnh hơn có thay được nhiều Agent không? Trong nhiều trường hợp là có. Nghiên cứu của Google và MIT nói ở phần trước tìm thấy một kiểu trần năng lực: khi một agent đơn đã làm tốt một việc, thêm agent thường không cải thiện, có khi còn kéo xuống. Nghĩa là nâng model cho một agent đôi khi hiệu quả hơn dựng cả nhóm. Đây là xu hướng trong bài đo của họ chứ không phải bảo đảm cho từng shop, nhưng đủ để bạn đảo thứ tự câu hỏi: thử làm một agent tốt lên trước, chưa ổn rồi hãy tính chuyện thêm. ### Có cần một framework đặc biệt mới gọi là orchestration không? Không. Orchestration là một phần việc, gồm chia việc, chuyền thông tin, gom kết quả và bắt lỗi, chứ không phải một sản phẩm phải mua. Framework chỉ là công cụ giúp làm phần việc đó đỡ cực. Một hệ tự viết mà có chỗ chịu kết quả cuối vẫn là hệ được điều phối. Ngược lại, cài công cụ xịn đến đâu mà ba agent vẫn mạnh ai nấy trả lời khách, hệ đó vẫn chưa có orchestration. ## Việc nên nhìn trước khi thêm Agent Lần tới khi nghe một lời chào kiểu hệ của bạn cần thêm agent, bạn có thể tự soi bằng ba câu hỏi, không cần biết một dòng code nào. - Việc này tách được thành các nhánh chạy cùng lúc không, hay bước sau phải chờ bước trước? - Nếu thêm agent, chỗ nào sẽ chia việc, gom kết quả và chịu kết quả cuối? - Chi phí token và thời gian chờ sẽ tăng bao nhiêu, kết quả đổi lại có xứng không? Trả lời được ba câu đó, bạn đã đứng ngoài cái bẫy đếm đầu agent. Nhiều agent hay một agent không phải câu hỏi về mức độ chịu chi, đó là câu hỏi về hình dạng của việc. Nhìn đúng hình dạng việc trước, số agent phù hợp sẽ tự lộ ra sau. Nếu muốn hiểu tiếp một agent thật ra chạy như thế nào bên trong, bài [Agent Loop là gì](/ai/agent-loop-la-gi) kể Agent Loop (vòng lặp vận hành của agent) mà một agent đi qua trong mỗi lần làm việc. Còn nếu bạn tò mò về lớp kiểm soát bọc quanh model, bài [Harness Engineering là gì](/ai/harness-engineering-la-gi) nói về Harness Engineering (kỷ luật thiết kế lớp điều khiển hành vi quanh model), người anh em rất gần với những gì bài này vừa bàn.ai-agentmulti-agentorchestrationllmnguyennlthttps://nguyennlt.com/ai/rag-co-du-cho-ai-agent/https://nguyennlt.com/ai/rag-co-du-cho-ai-agent/RAG tìm đoạn gần nghĩa cho một lượt. Knowledge giữ sự thật đang đúng. Long-term memory nhớ từng khách. Ba việc khác nhau, agent thường cần cả ba.Sat, 22 Aug 2026 05:30:00 GMT> **Trả lời nhanh:** RAG (Retrieval-Augmented Generation) không đủ cho một AI Agent, tức chương trình dùng model để tự chọn bước và gọi tool hướng tới một mục tiêu, nếu bạn cần sự thật đang đúng và nhớ từng người. RAG chỉ lấy vài đoạn gần nghĩa từ kho đã lập sẵn rồi đưa vào context window (cửa sổ ngữ cảnh) của lượt này. Vector search (tìm theo độ gần nghĩa) là bước lục những đoạn đó. Knowledge (kho kiến thức đang đúng) giữ sự thật dùng chung. Long-term memory (bộ nhớ dài hạn) ghi những gì sinh ra từ tương tác, theo từng người, qua nhiều phiên. Nhiều người nghe đã gắn RAG rồi yên tâm agent biết hết. Việc RAG làm giống lục một chồng tờ rơi: tờ nào nghe gần câu hỏi thì kéo ra cho lượt này. Gần không có nghĩa là đang đúng, cũng không có nghĩa là tờ đó nói về đúng người đang hỏi. Minh họa một agent hỗ trợ shop. Khách hỏi đổi size áo đã mua tuần trước. Agent lục được FAQ cũ, đọc vanh vách, rồi vẫn hỏi lại mã đơn, hoặc đọc chính sách đã hết hạn. Bạn tưởng thiếu model. Thật ra thiếu kho đang đúng, hoặc thiếu chỗ ghi chuyện của khách này. Bài này tách ba việc đó để bạn biết RAG dừng ở đâu, Knowledge bắt đầu ở đâu, và long-term memory làm việc gì RAG không làm được. Cùng mình xem chỗ nào đang thiếu nhé.  _Ba việc khác nhau. Gọi chung là nhớ thì bạn không biết đang thiếu cột nào._ ## RAG làm được việc gì, và việc đó dừng ở đâu? RAG làm đúng một vòng: tìm vài đoạn liên quan rồi để LLM (Large Language Model), tức model ngôn ngữ lớn, đọc các đoạn đó trước khi trả lời. Nó không tự giữ sự thật mới, không tự biết chính sách vừa đổi, và không tự nhớ khách này là ai.  _RAG lục rồi đọc cho một lượt. Nó không tự giữ sự thật mới, cũng không ghi chuyện khách._ Năm 2020, [Lewis và cộng sự mô tả RAG](https://arxiv.org/abs/2005.11401) là cách ghép hai loại chỗ chứa: kiến thức nằm trong trọng số của model, và một chỉ mục vector dày của Wikipedia nằm ngoài model. Paper gọi chỉ mục đó là memory phi tham số. Chữ memory ở đây là kho tài liệu để lục, không phải chỗ agent ghi chuyện của từng người. Đó là nguồn gốc của sự nhầm sau này: cùng một chữ, hai việc khác nhau. Vòng RAG phổ biến ngày nay vẫn đi theo đúng mạch đó. Tài liệu được cắt thành chunk (đoạn văn đã cắt), mỗi chunk được biến thành embedding, tức cách biến đoạn văn thành dãy số để máy so độ gần nghĩa, rồi cất vào một chỉ mục. Khi có câu hỏi, hệ thống biến câu hỏi thành dãy số, lấy vài chunk gần nhất, rồi nhét chúng vào context window của lượt này. Hết lượt, model không giữ lại gì. Lượt sau muốn dùng lại thì phải lục lại. [Letta viết](https://www.letta.com/blog/rag-vs-agent-memory/) rằng cách này chỉ cho model một lần lấy rồi trả lời, và hoàn toàn bị động: khách nói hôm nay sinh nhật, hệ thống đi tìm những đoạn nghe giống sinh nhật. Sở thích màu xanh hay theme Star Wars nói tuần trước thường không được kéo ra, vì chúng không nằm gần chữ sinh nhật trên thang gần nghĩa. Letta kết luận gọn hơn: RAG là một tool phục vụ memory (bộ nhớ), không phải bản thân memory. Vậy việc RAG dừng lại là việc tìm đoạn gần với câu vừa hỏi. Câu tiếp theo phải hỏi: đoạn gần đó có phải sự thật đang đúng không? ## Vector search khác Knowledge ở chỗ nào? Hai thứ này hay bị gọi chung là đã có kho tài liệu, nhưng chúng trả lời hai câu khác nhau. Vector search trả lời đoạn nào nghe gần câu hỏi. Knowledge trả lời điều gì đang đúng, do ai giữ, và còn hạn đến khi nào. Ba mục dưới đây tách đúng ba mặt của kho dùng chung: cách lục, cái đang đúng, và cái hết hạn.  _Đoạn nghe giống câu hỏi vẫn có thể là bản đã nghỉ. Gần nghĩa không phải đang đúng._ ### Vector search chỉ xếp hạng độ gần nghĩa Vector search không đọc hiểu chính sách. Nó so dãy số. Câu đổi size áo gần với đoạn FAQ có chữ đổi, size, áo, nên đoạn đó thắng. Đoạn bảng giá mới, đoạn thông báo ngừng đổi hàng sale, hay đoạn ghi chú nội bộ về khách này có thể thua, dù chúng mới là thứ bạn cần. Đó không phải lỗi của thuật toán. Việc của nó là tìm cái nghe giống, không phải tuyên bố cái nào còn hiệu lực. [Redis mô tả](https://redis.io/blog/ai-agent-memory-vs-retrieval/) truy xuất kiểu này là một lần đọc không trạng thái: chỉ mục được dựng trước, câu hỏi không ghi gì ngược lại, và mọi phiên lục cùng một kho. ### Knowledge là sự thật đang đúng, không phải đoạn nghe giống Knowledge là kho sự thật dùng chung mà bạn muốn agent bám vào: chính sách đổi trả hôm nay, còn đổi được hàng sale hay không, hạn đổi bảy ngày hay mười bốn ngày. Cùng một câu hỏi, mọi khách phải nhận cùng một câu trả lời, và câu đó phải khớp với điều shop đang áp dụng. Kho này có thể được lục bằng vector search, bằng tìm theo từ khóa, hoặc bằng một bảng dữ liệu. Cách lục không biến nó thành Knowledge. Cái biến nó thành Knowledge là quyền sở hữu và thời điểm còn đúng: ai được sửa, bản nào là bản hiện hành, bản cũ có bị rút không. Quay lại minh họa shop. FAQ PDF năm ngoái nói đổi trong bảy ngày. Tuần này shop đổi thành mười bốn ngày. Vector search vẫn thắng bản bảy ngày nếu bản đó nghe gần câu hỏi hơn, hoặc nằm gần đầu chỉ mục. Agent đọc vanh vách. Khách tin. Shop phải gỡ. Lỗi không nằm ở model bịa, mà ở chỗ hệ thống lấy đoạn giống thay vì sự thật đang đúng. ### Đoạn cũ nghe giống vẫn thắng đoạn mới nếu không ai rút Đây là chỗ Knowledge hỏng thầm. [Redis lấy đúng kiểu hỏng này](https://redis.io/blog/ai-agent-memory-vs-retrieval/): agent nhớ khách, rồi trích một chính sách giá đã nghỉ vài tháng. Model làm đúng việc đọc context được đưa vào. Lớp context đưa nhầm thứ hết hạn. Vì vậy gắn RAG chưa có nghĩa đã có Knowledge. RAG chỉ là đường lấy. Nếu đường lấy không biết bản nào còn hiệu lực, bạn có một máy lục tờ rơi, không có một kho sự thật. Bài [Memory trong AI Agent](/ai/memory-trong-ai-agent-context-window) đã tách cửa sổ nhìn và chỗ lưu. Ở đây mình tách tiếp: chỗ lưu tài liệu dùng chung vẫn chưa phải chỗ nhớ từng khách. ## Long-term memory khác Knowledge ở chỗ nào? Hai kho này đều nằm ngoài context window, nên dễ bị bán chung một gói. Chúng khác nhau ở chủ thể của sự thật và ở chiều ghi. Knowledge nói về shop, giống nhau với mọi người. Long-term memory nói về khách này, và phải được ghi từ chính tương tác. Hai mục dưới đây giữ đúng hai câu đó.  _Cùng nằm ngoài cửa sổ. Một kho nói về shop. Một kho nói về khách này và phải có chiều ghi._ ### Knowledge trả lời shop đang quy định gì Chính sách đổi trả, danh mục size, phí ship nội thành: đó là Knowledge. Khách A hỏi hay khách B hỏi thì câu đúng vẫn là một. [Mem0 tóm đúng việc này](https://mem0.ai/blog/rag-vs-ai-memory): RAG trả lời tài liệu nói gì. Việc đó hợp với kho dùng chung, không hợp với câu chỉ có bạn và shop biết. Nếu agent chỉ cần đọc FAQ rồi dừng, một chatbot có RAG thường đủ. Ranh giới chatbot và agent nằm ở tool, memory và quyền hành động, mình tách ở bài [AI Agent khác chatbot ở điểm nào](/ai/ai-agent-khac-chatbot-o-diem-nao). RAG giúp trả lời. Nó không biến hệ thống thành chỗ nhớ khách. ### Long-term memory trả lời khách này đã từng nói gì Long-term memory giữ chuyện sinh ra từ tương tác: khách đã mua áo xanh size M tuần trước, đã đổi một lần, thích giao buổi chiều, không muốn gọi điện. [LangChain tách](https://docs.langchain.com/oss/python/concepts/memory) short-term memory (bộ nhớ ngắn hạn) trong một luồng hội thoại, và long-term memory đi xuyên nhiều luồng. Thứ Tư khách quay lại là một luồng mới. Lịch sử phiên Thứ Hai không tự bắc cầu. Chỗ khác Knowledge rõ nhất là chiều ghi. RAG điển hình chỉ đọc. Memory phải viết: trích sự thật từ hội thoại, cập nhật khi khách đổi ý, xóa khi khách yêu cầu. [Letta nhấn](https://www.letta.com/blog/agent-memory/) retrieval là tool của memory, không phải memory. Không có chiều ghi thì kho chỉ là bản sao tài liệu, dù bạn gọi nó là nhớ. Minh họa shop tiếp. Knowledge biết hạn đổi là mười bốn ngày. Long-term memory biết đơn này mua ngày 8, size M, đã đổi một lần lên L. Thiếu kho thứ hai, agent đọc chính sách rất hay rồi hỏi lại mã đơn, hoặc cho đổi lần nữa khi shop chỉ cho đổi một lần. Thiếu kho thứ nhất, agent nhớ khách rất thân rồi vẫn đọc hạn bảy ngày của bản cũ. ## Khi nào RAG là đủ, khi nào còn thiếu Knowledge hoặc Memory? Ba trường hợp dưới đây xếp theo việc đang thiếu, không theo tên sản phẩm. Cùng một agent hỗ trợ shop, bạn nhận ra chỗ hỏng khác nhau: chỉ cần đọc tài liệu dùng chung, đọc được nhưng bản đã cũ, hoặc bản đúng mà quên khách.  _Cùng một agent, chỗ hỏng khác nhau. Vá nhầm lớp thì máy lục tờ rơi chỉ to hơn._ ### Chỉ cần RAG khi mọi người hỏi cùng một sự thật tĩnh Dùng RAG khi câu trả lời nằm trong tài liệu, không đổi theo người hỏi, và tài liệu đủ tươi cho việc đó. Câu hạn đổi trả là bao nhiêu ngày, nếu bản FAQ đúng là bản đang dùng, thì lục vài đoạn rồi trả lời là đủ. Không cần nhớ khách là ai. Không cần agent tự lập kế hoạch nhiều bước. [Anthropic xếp retrieval cạnh tool và memory](https://www.anthropic.com/engineering/building-effective-agents) như khối tăng cường cho LLM, nhưng đó là điểm xuất phát, không phải toàn bộ agent. Việc gọn, một lượt, không side effect, thường dừng ở đây cho rẻ và dễ kiểm. ### Thiếu Knowledge khi đoạn lục được nghe đúng mà sự thật đã đổi Bạn thiếu Knowledge khi agent trích được đoạn rất giống câu hỏi, nhưng đoạn đó không còn là bản hiện hành. Dấu hiệu dễ thấy: khách nhận một câu chắc nịch, đội vận hành phải sửa sau vì chính sách, giá, hoặc tồn kho đã đổi. Vá chỗ này không phải đổi model. Vá bằng quyền sở hữu bản hiện hành: bản nào được phép lục, bản cũ có bị rút, và sự thật có cấu trúc như hạn đổi hay tồn kho thì nên tra bảng, đừng phó cho đoạn văn nghe giống. [Microsoft khuyên](https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/ai-agent-design-patterns) đưa state dùng chung ra kho bền vững bên ngoài, và chỉ lưu phần tối thiểu cần thiết. Cùng tinh thần đó, Knowledge cũng cần một bản đang đúng, không phải một đống PDF chồng lên nhau. ### Thiếu long-term memory khi agent thuộc chính sách mà ngơ về khách Bạn thiếu long-term memory khi câu hỏi chỉ có khách và shop biết từ lần trước, mà agent vẫn hỏi lại từ đầu. Dấu hiệu: đọc FAQ trôi chảy, không nhớ đơn tuần trước, không nhớ đã đổi một lần, không nhớ khách dặn giao buổi chiều. Vá chỗ này cũng không phải thêm PDF. Vá bằng chiều ghi và phạm vi theo người: lưu gì, lấy lúc nào, ai được thấy, xóa ra sao. Chỗ vận hành các quyết định đó nằm ở harness (lớp điều khiển hành vi agent), mình viết ở bài [Harness Engineering là gì](/ai/harness-engineering-la-gi). Còn vòng Agent Loop (vòng lặp vận hành của agent) sau khi đã lấy được mảnh đúng nằm ở bài [Agent Loop là gì](/ai/agent-loop-la-gi). Hai chỗ hỏng có thể đứng cùng lúc. Agent vừa đọc chính sách cũ, vừa quên khách. Khi đó gắn thêm RAG chỉ làm máy lục tờ rơi to hơn. ## Câu hỏi thường gặp Bốn câu dưới đây là ranh giới còn sót sau khi đã tách ba việc. Chúng hay xuất hiện trên trang giới thiệu sản phẩm, nên mình trả lời theo cơ chế, không theo tên tính năng. ### Agentic RAG đã đủ để gọi là memory chưa? Chưa. Agentic RAG, tức RAG mà agent tự quyết định tìm lại nhiều lần, sửa được chỗ Letta chỉ ra: một lần lấy rồi dừng. Agent có thể đổi câu lục, mở nguồn khác, rồi mới trả lời. Việc đó vẫn là đọc kho dùng chung cho tốt hơn. Nó không tự tạo chiều ghi cho chuyện của từng khách, cũng không tự rút bản đã hết hạn nếu không ai đặt quy tắc đó. ### Knowledge graph có thay long-term memory không? Không mặc định. Knowledge graph (đồ thị tri thức) giúp nối thực thể với nhau, ví dụ đơn hàng gắn với sản phẩm gắn với chính sách. Nó hữu khi câu hỏi cần đi qua vài mối quan hệ, không chỉ một đoạn nghe giống. Nó vẫn không phải long-term memory nếu không có chiều ghi theo từng người và không có thời hạn của từng sự thật về người đó. Đồ thị của shop không thay hồ sơ của khách. ### Bắt buộc phải có vector database mới có Knowledge hoặc memory? Không. Vector database (cơ sở dữ liệu vector) là một cách cất dãy số để lục theo độ gần nghĩa. Nó tiện khi kho văn bản lớn. Sự thật có cấu trúc như mã đơn, hạn đổi, địa chỉ thì một bảng thường tra đúng hơn. Memory cũng có thể là ghi chú nằm ngoài cửa sổ, đúng như cách Anthropic mô tả việc agent viết note rồi kéo về khi cần, trong [bài về context engineering (kỹ thuật chọn thông tin model được nhìn thấy)](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents). ### Fine-tune model có thay được RAG, Knowledge, hoặc memory không? Không thay được cả ba. Fine-tune nhét thêm thói quen vào trọng số. Nó không cho bạn rút một chính sách hết hạn ngày hôm nay, không cho khách xem đúng hồ sơ của mình, và không cho bạn xóa một số điện thoại khi khách yêu cầu. Lewis và cộng sự vốn đề xuất RAG vì cập nhật kiến thức thế giới trong model vẫn là bài toán mở. Bài toán đó đến 2026 vẫn chưa biến mất. ## Việc nên hỏi trước khi tin agent đã biết đủ Ba câu dưới đây đủ để biết bạn đang mua RAG, Knowledge, hay long-term memory. Đừng hỏi sản phẩm có trí nhớ không. Hỏi nó trả lời được câu nào. - Cùng một câu hỏi, mọi khách có nhận cùng một sự thật đang đúng không, và bản cũ đã bị rút chưa? - Câu chỉ có khách này biết từ lần trước, hệ thống lấy lại được không, hay chỉ đọc lại FAQ? - Khi khách đổi ý hoặc xin xóa, chiều ghi cập nhật hay xóa được chỗ nào? Nếu cả ba câu đều được trả lời bằng chúng tôi đã gắn RAG, bạn đang có một đường lục đoạn gần nghĩa. Đường đó có ích thật. Nó không đủ cho một AI Agent phải nói đúng điều đang áp dụng, và phải nhớ đúng người đang hỏi. Muốn xem vì sao cửa sổ rộng hơn vẫn không thành chỗ nhớ, đọc bài [Memory trong AI Agent](/ai/memory-trong-ai-agent-context-window). Chỗ agent tự chọn bước sau khi đã có mảnh đúng nằm ở [Agent Loop là gì](/ai/agent-loop-la-gi). Phần hạ tầng giữ state, quyền và truy vết nằm ở bài [vì sao AI Agent cần một platform](/ai/vi-sao-ai-agent-can-platform-thay-vi-prompt).ai-agentragvector-searchknowledgememorylong-term-memorynguyennlthttps://nguyennlt.com/ai/memory-trong-ai-agent-context-window/https://nguyennlt.com/ai/memory-trong-ai-agent-context-window/Context window chỉ là chỗ model nhìn trong một lần gọi. Memory mới quyết định lưu gì, lấy lại lúc nào, và giữ bao lâu.Thu, 20 Aug 2026 17:45:00 GMT> **Trả lời nhanh:** Context window (cửa sổ ngữ cảnh) là lượng token model được nhìn thấy trong một lần gọi, và giữa hai lần gọi thì model không tự giữ lại gì. Memory (bộ nhớ) là phần hệ thống quyết định lưu thông tin nào, lấy lại lúc nào, cho ai xem và giữ bao lâu, ở một chỗ nằm ngoài cửa sổ đó. Nới cửa sổ rộng thêm chỉ giúp model đọc nhiều hơn trong một lượt, chứ không tạo ra chỗ lưu nào. Vì vậy một AI Agent, tức chương trình dùng model để tự chọn bước và gọi tool hướng tới một mục tiêu, cần cả hai thứ. Context window giống như mặt bàn làm việc: rộng đến đâu thì bày được nhiều giấy tờ đến đó, nhưng hết giờ làm là dọn sạch. Memory lại giống tủ hồ sơ: cất giữ qua đêm, qua tuần, và quan trọng nhất là biết rút đúng tập hồ sơ khi cần. Hai thứ này khác nhau về bản chất, nhưng đang bị gọi chung bằng một chữ "nhớ". Sự nhầm lẫn đó có giá của nó. Ví dụ một đội xây chatbot chăm sóc khách hàng cứ nghĩ nâng model lên cửa sổ to hơn là bot sẽ nhớ khách lâu hơn, rồi ngạc nhiên khi khách quay lại sau hai ngày và bot hỏi lại từ đầu. Vấn đề không nằm ở model, mà ở chỗ hệ thống chưa có cái tủ hồ sơ. Trong bài viết này, mình sẽ giải thích vì sao mặt bàn to đến mấy cũng không thay được tủ hồ sơ. Mình sẽ viết về những lớp của một hệ thống memory thật sự, và cách bạn tự nhận ra chatbot đang hụt ở lớp nào, bằng ngôn ngữ dễ hiểu để bạn dễ hình dung. Cùng mình tìm hiểu ngay nhé!  _Cửa sổ là chỗ model nhìn trong một lượt. Memory là kho bên ngoài cộng với bộ quy tắc lấy lại._ ## Context window khác memory ở chỗ nào? Khác ở chỗ một cái là phạm vi nhìn, cái kia là một chuỗi quyết định. Context window là số token gửi vào một lần suy luận của LLM (Large Language Model), và [Machine Learning Mastery mô tả](https://machinelearningmastery.com/context-windows-are-not-memory-what-ai-agent-developers-need-to-understand/) gọn phần còn lại: model không giữ state giữa các lần gọi API (Application Programming Interface), mỗi lần gọi là một lần bắt đầu lại từ đầu. Memory là bốn quyết định của hệ thống quanh model, lưu gì, lấy lại lúc nào, ai được thấy, giữ bao lâu. Đó cũng là lý do hình dung bàn làm việc và tủ hồ sơ hữu ích. Bàn là cửa sổ: rộng bao nhiêu thì đặt được bấy nhiêu giấy cho một lượt, cuối lượt dọn sạch. Tủ là memory: giấy nằm đó qua nhiều ngày, có người quyết định hồ sơ nào đáng cất, ai được mở, bao lâu thì hủy. Bàn to gấp mười vẫn không thay được cái tủ. Có một điểm dễ nhầm theo hướng ngược lại. [Letta viết](https://www.letta.com/blog/agent-memory/) rằng thứ agent nhớ ở bất kỳ thời điểm nào chính là thứ đang nằm trong context window, nên thiết kế memory thực chất là context engineering (kỹ thuật chọn thông tin model được nhìn thấy). Hai câu đó không chọi nhau: kho nằm ngoài cửa sổ, nhưng mảnh thông tin phải được kéo trở lại vào cửa sổ ở đúng lượt cần. Khách thường không hỏi lại từ đầu, vì họ tưởng hệ thống đã giữ những gì họ từng nói. Ví dụ chatbot hỗ trợ đơn hàng: Thứ Hai khách nhắn đã mua áo xanh, size M, giao về Hà Nội; Thứ Tư khách quay lại và hỏi đơn tới đâu rồi. Áo xanh, size M, Hà Nội là thứ đáng cất vào tủ vì Thứ Tư còn dùng tới, còn mấy dòng chào hỏi thì không. Hệ thống chỉ có cửa sổ thì giữ cả hai như nhau, rồi mất cả hai như nhau. ## Vì sao cửa sổ lớn hơn vẫn không thành memory? Ba mục dưới đây là ba kiểu hỏng khi lấy cửa sổ làm chỗ nhớ, xếp theo mức khó chịu tăng dần: mất trắng khi hết phiên, còn thông tin nhưng đắt và dễ đọc sót, và không có ai quyết định lưu hay xóa. Ba kiểu độc lập với nhau, nên vá được một cái vẫn không khỏi hai cái kia.  _Nới cửa sổ chỉ đỡ được phần giữa của bức tranh này. Hai đầu vẫn hỏng nguyên._ ### Nó biến mất khi phiên kết thúc Vì model không giữ state giữa các lần gọi, mọi thứ nó tỏ ra là nhớ đều đến từ phần văn bản ứng dụng vừa nhét vào lượt này. Hết phiên, không ai chép lại thì không còn gì. [Tài liệu LangChain](https://docs.langchain.com/oss/python/concepts/memory) tách đúng ranh giới này: short-term memory (bộ nhớ ngắn hạn) là lịch sử tin nhắn trong phạm vi một luồng hội thoại, nằm trong state của agent; long-term memory (bộ nhớ dài hạn) là thứ đi xuyên nhiều luồng. Trong ví dụ chatbot hỗ trợ đơn hàng, Thứ Hai và Thứ Tư là hai luồng khác nhau, nên bộ nhớ ngắn hạn dù đầy đủ tới đâu cũng không bắc được cầu. ### Nó đắt và dễ bỏ sót chỗ giữa Giả sử bạn chấp nhận trả tiền và cứ nhét lại toàn bộ hội thoại mỗi lượt. Vấn đề là dài hơn không đồng nghĩa nhớ tốt hơn. Ngày 29/9/2025, [Anthropic viết trong bài về context engineering](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) rằng context là tài nguyên hữu hạn và có điểm lợi suất giảm dần, kèm hiện tượng họ gọi là context rot (độ chính xác giảm khi context dài ra): token càng tăng thì khả năng nhớ chính xác càng giảm. Phần này đã được đo trước đó. Bài [Lost in the Middle của Liu và cộng sự](https://arxiv.org/abs/2307.03172) thử hai loại tác vụ, hỏi đáp trên nhiều tài liệu và tra cứu theo cặp khóa với giá trị: kết quả cao nhất khi thông tin cần dùng nằm ở đầu hoặc cuối đoạn context, còn nằm giữa thì tệ đi rõ rệt. Đó là lost in the middle (hiện tượng model bỏ sót thông tin nằm giữa đoạn context dài), và nó không tha cả model được quảng cáo là xử lý được context dài. LangChain nói cùng ý ở góc thực dụng: hội thoại dài có thể không vừa cửa sổ, mà vừa rồi thì model vẫn dễ phân tán, chậm hơn và tốn hơn. Có một con số đáng nhìn, kèm điều kiện của nó. [Bài báo Mem0 của Chhikara và cộng sự](https://arxiv.org/abs/2504.19413) chạy trên LOCOMO (bộ dữ liệu hội thoại dài của Maharana và cộng sự, 2024) gồm 10 hội thoại, trung bình khoảng 600 lượt đối thoại và khoảng 26.000 token. Cách nhét cả hội thoại vào cửa sổ đạt điểm J, một cách đo độ đúng của câu trả lời trong bài đó, khoảng 73%, cao hơn Mem0 ở khoảng 67% và Mem0g ở 68,44%. Độ trễ p95 của cách nhét hết là khoảng 17 giây, còn Mem0 khoảng 1,44 giây, thấp hơn chừng 91–92%, với lượng token đưa vào chỉ khoảng 7.000. Đây là đánh đổi chi phí và thời gian chờ trên một bộ bài kiểm tra cụ thể, không phải kết luận rằng memory trả lời đúng hơn cả hội thoại. ### Nó không biết lưu gì, xóa gì, cho ai Kiểu hỏng thứ ba khó thấy nhất, vì nó không báo lỗi. Một cửa sổ ngữ cảnh không có quyền truy cập, không có thời hạn lưu, không có nút xóa theo yêu cầu của khách. Khi khách nhờ xóa số điện thoại đã cung cấp, bạn không có chỗ nào để xóa, cũng không có chỗ nào để chứng minh là đã xóa. Đó là lý do [hướng dẫn kiến trúc của Microsoft](https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/ai-agent-design-patterns) khuyến nghị đưa state dùng chung ra một kho bền vững bên ngoài với tác vụ chạy dài hoặc kéo qua nhiều lượt: tiến độ công việc, kết quả trung gian và lịch sử hội thoại nằm ở đó, đồng thời giới hạn phần được lưu ở mức tối thiểu cần thiết. Chữ tối thiểu quan trọng ngang chữ bền vững, vì lưu tất cả cho chắc là cách nhanh nhất để có một kho không ai dám dùng. ## Agent thực sự nhớ bằng những lớp nào? Cách chia dễ hình dung nhất là theo thời gian sống của thông tin: sống trong một lần chạy, sống trong một phiên, hay sống qua nhiều phiên. Chia theo tên sản phẩm sẽ rối ngay khi bạn đổi nhà cung cấp. Ba lớp dưới đây đều nằm ngoài cửa sổ và đều phải được kéo vào cửa sổ khi cần dùng.  _Cùng một hệ thống, ba thời gian sống khác nhau. Hỏng lớp nào thì triệu chứng khác nhau._ ### State của lần chạy Đây là phần ghi tiến độ của một nhiệm vụ đang chạy: đã tra được mã đơn, đã gọi tool kiểm tra vận chuyển, đang chờ người duyệt. Nó sinh ra khi lần chạy bắt đầu và hết việc khi lần chạy kết thúc. Microsoft xếp đúng những thứ này vào kho bền vững bên ngoài để tác vụ dài không chết theo tiến trình. Muốn xem một lần chạy theo từng nhịp, bài [Agent Loop là gì](/ai/agent-loop-la-gi) đi hết vòng đó. ### Lịch sử phiên Đây là những gì khách đã nói trong phiên làm việc này, tức phần LangChain gọi là bộ nhớ ngắn hạn trong phạm vi một luồng. Nó đủ để agent không hỏi lại size ba lần trong cùng một buổi chat. Trong ví dụ đơn hàng, lớp này không đủ cho Thứ Tư, vì phiên mới là một luồng mới. Lớp này cũng có giới hạn riêng: hội thoại dài lên là vướng đúng hai vấn đề ở mục trước, hóa đơn token và phần giữa bị đọc sót. ### Memory dài hạn Đây là lớp làm được việc mà hai lớp trên không làm, giữ thông tin qua nhiều phiên. LangChain xếp vào đây các dữ kiện, các lần đã trải qua và cả những chỉ dẫn về cách làm. Trong ví dụ đơn hàng, áo xanh size M giao Hà Nội là dữ kiện, và nó là thứ khiến câu hỏi hôm Thứ Tư trả lời được. Lớp này bắt buộc đi kèm phạm vi truy cập và thời hạn, không phải vì thủ tục mà vì nó chứa dữ liệu thật của người thật. Đây cũng là lớp mà [harness, tức lớp điều khiển hành vi agent](/ai/harness-engineering-la-gi), phải vận hành: quyết định ghi, quyết định lấy, quyết định xóa. Một chỗ cần tách cho rõ: RAG (Retrieval-Augmented Generation) trên tài liệu nội bộ không phải memory của khách. RAG đi tìm tri thức có sẵn ở đâu đó, ví dụ chính sách đổi trả, còn memory phải giữ trạng thái sinh ra từ tương tác, ví dụ khách này vừa đổi địa chỉ giao hàng. Letta nói gọn hơn mình: RAG là một tool phục vụ memory, không phải bản thân memory. ## Thông tin nhớ được lấy lại vào context window thế nào? Hai mục dưới đây là hai chiều của cùng một hệ thống, không phải hai sản phẩm: chiều ghi quyết định cái gì rời cửa sổ để vào kho, chiều lấy quyết định cái gì từ kho quay lại cửa sổ cho lượt này. Sai chiều ghi thì kho rỗng hoặc kho rác. Sai chiều lấy thì kho đầy mà model vẫn trả lời như chưa gặp bạn bao giờ.  _Một vòng, hai chiều. Ghi chọn thứ đáng giữ, lấy chọn thứ đáng nhìn ngay bây giờ._ ### Ghi nhớ: chọn cái gì đáng lưu Cơ chế phổ biến nhất đơn giản đến mức dễ coi thường: cho agent ghi chú lại. [Anthropic gọi cách này là ghi chú có cấu trúc](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents), agent viết ghi chú ra một chỗ nằm ngoài context window rồi kéo về khi cần, nên nội dung không mất khi cửa sổ bị dọn. Khi hội thoại gần đầy cửa sổ, còn một nước nữa là compaction (nén ngữ cảnh): tóm tắt phần đã diễn ra rồi bắt đầu lại với bản tóm tắt thay cho toàn bộ chi tiết. Tóm tắt luôn là một lần đánh cược, vì thứ bị lược đi có thể là thứ mai cần. Nên những mảnh phải giữ nguyên văn, mã đơn, size, địa chỉ, thường được ghi thành ghi chú riêng chứ không phó cho bản tóm tắt. Cuốn sổ đó hay được gọi là scratchpad (sổ ghi chú tạm), nhưng cái tên không quan trọng bằng chỗ nó nằm. ### Lấy lại: nhét đúng mảnh vào lần gọi này Chiều lấy chính là truy xuất (retrieval): tìm trong kho ra mảnh liên quan tới câu vừa hỏi rồi đặt vào cửa sổ trước khi gọi model. Anthropic đặt nguyên tắc chọn khá dứt khoát, tìm tập token nhỏ nhất mà vẫn nhiều tín hiệu nhất, chứ không phải nhồi càng nhiều càng an tâm. Cùng bài đó mô tả kiểu lấy just-in-time: hệ thống chỉ giữ những định danh nhẹ, ví dụ mã đơn, rồi dùng tool nạp dữ liệu thật vào đúng lúc cần. Hình dung kho đã giữ sẵn vài mảnh từ lần chat trước, còn lượt này khách chỉ hỏi một câu ngắn. Ví dụ chatbot hỗ trợ đơn hàng: Thứ Tư khách hỏi đơn tới đâu, hệ thống tra ra khách này, lấy từ kho mã đơn cùng ba mảnh đã ghi, gọi tool kiểm tra trạng thái vận chuyển, rồi nhét đúng chỗ đó vào cửa sổ của lượt này. Model đọc một trang gọn thay vì cả tập hội thoại. Kho lưu và quy tắc lấy đều nằm ở lớp hệ thống, không nằm trong model, nên đổi sang model thông minh hơn thì phần này vẫn phải có người dựng. ## Những nhầm lẫn thường gặp khi nghe AI nhớ bạn Ba mục dưới đây là ba thứ hay bị đánh đồng với memory, và cả ba đều nghe rất thuyết phục cho tới lúc hệ thống chạy thật. Mình xếp theo thứ tự bạn sẽ gặp trên trang giới thiệu sản phẩm.  _Ba thứ nghe giống memory trên trang giới thiệu. Cả ba đều trả lời một câu khác với câu bạn đang hỏi._ ### Cửa sổ dài hơn nghĩa là đã có memory Không. Cửa sổ dài hơn nghĩa là một lượt đọc được nhiều hơn, chưa nói gì tới chuyện có chỗ lưu hay không, và model vẫn không giữ state giữa các lần gọi nên hết phiên vẫn là hết. Phần dài ra cũng không miễn phí về chất lượng, đúng như Anthropic mô tả với context rot và Liu mô tả với phần giữa bị đọc sót. Con số token trên trang giới thiệu vì vậy trả lời một câu khác: model nhìn được bao nhiêu trong một lượt, không phải hệ thống lưu lại gì cho lượt sau. ### Nhét hết lịch sử hoặc nhét hết kho dữ liệu là memory Đây là cách làm được, và với việc nhỏ còn hợp lý. Nhưng nó không phải một thiết kế memory, nó là quyết định không chọn gì cả. Bài báo Mem0 cho thấy giá của việc không chọn, độ trễ p95 khoảng 17 giây so với khoảng 1,44 giây trên cùng bộ dữ liệu đã dẫn ở trên. Chiều ngược lại sai theo kiểu tương tự, đổ cả kho dữ liệu vào cửa sổ cho chắc ăn, trong khi nguyên tắc của Anthropic đi ngược hẳn: tập token nhỏ nhất mà nhiều tín hiệu nhất. ### RAG tài liệu nội bộ chính là memory khách hàng Không, và đây là chỗ nhầm tốn tiền nhất, vì hai thứ này thường được bán chung một gói. RAG trả lời câu hỏi về tri thức có sẵn ở đâu đó, ví dụ chính sách đổi trả trong tài liệu nội bộ. Memory trả lời câu hỏi về trạng thái sinh ra từ tương tác. Quay lại ví dụ chatbot hỗ trợ đơn hàng: khách này đã mua gì hôm Thứ Hai là memory, không phải tài liệu nội bộ. Cách kiểm tra nhanh: hỏi hệ thống một câu chỉ có bạn với nó biết từ lần trước. Nếu nó trôi chảy về chính sách nhưng ngơ ngác về bạn, phần bạn đang mua là truy xuất tài liệu. Bài [RAG có đủ cho AI Agent không](/ai/rag-co-du-cho-ai-agent) tách tiếp ba việc hay bị bán chung: vector search, Knowledge và long-term memory. ## Câu hỏi thường gặp Năm câu dưới đây là các ranh giới còn sót lại sau thân bài, chỗ hai khái niệm gần nhau đến mức nhãn sản phẩm nào cũng dùng chung một từ. Mình trả lời theo cơ chế, không theo tên tính năng trên giao diện. ### ChatGPT nhớ hội thoại thì đã là memory của agent chưa? Đúng một phần. Việc chép thông tin lại để dùng cho phiên sau là một cơ chế memory thật. Nhưng memory chỉ là một trục của agent, và [IBM lưu ý](https://www.ibm.com/think/topics/ai-agents) chatbot không agentic thường thiếu tool, memory hay suy luận, phục vụ mục tiêu ngắn và cần người dùng nhập tiếp ở từng lượt. Ranh giới đó mình tách thành ba trục ở bài [AI Agent khác chatbot ở điểm nào](/ai/ai-agent-khac-chatbot-o-diem-nao). ### Agent quên giữa chừng vì model kém? Thường không phải. Hai nguyên nhân phổ biến hơn là không có kho lưu ngoài cửa sổ, và có lưu nhưng lấy lại sai mảnh. Kể cả với model xử lý context dài, Liu và cộng sự vẫn thấy kết quả giảm khi context dài ra và khi thông tin cần dùng nằm ở giữa, nên đổi sang model đắt hơn không vá được phần thiết kế còn thiếu. ### Mọi AI Agent đều cần memory dài hạn? Không. Việc gọn trong một lượt, không cần biết bạn là ai, thì thêm kho lưu chỉ thêm chỗ hỏng và thêm dữ liệu phải bảo vệ. Microsoft nêu nguyên tắc giới hạn phần state được lưu ở mức tối thiểu cần thiết, và mức tối thiểu đôi khi bằng không. ### Memory có nghĩa model đã được huấn luyện lại? Không. Hệ thống nhớ thêm không làm model giỏi thêm. [IBM phân biệt rõ](https://www.ibm.com/think/topics/ai-agents-vs-ai-assistants) agent có thể nhớ và điều chỉnh dựa trên tương tác trước đó, nhưng model nền bên dưới không vì thế được huấn luyện lại. Thông tin nằm ở kho bên ngoài rồi được đưa vào cửa sổ khi cần, chứ không đi vào trọng số của model. ### Bắt buộc phải có vector database mới gọi là memory? Không. Vector database (cơ sở dữ liệu vector) là một cách lưu và tìm theo độ gần nghĩa, dựa trên embedding, tức cách biến đoạn văn thành dãy số để máy so độ gần nghĩa. Nó tiện khi bạn cần dò mảnh liên quan trong một khối văn bản lớn. Nhưng cách ghi chú ra file bên ngoài cửa sổ mà Anthropic mô tả cũng là memory, và với thông tin có cấu trúc rõ như mã đơn hay địa chỉ thì một bảng dữ liệu thường tra nhanh hơn. ## Điều cần mang đi khi một sản phẩm nói nó nhớ bạn Bốn câu hỏi dưới đây đủ để biết bên bán đang có memory thật hay chỉ có một cửa sổ rộng.  _Bốn câu này hỏi về kho lưu và quy tắc, không hỏi cửa sổ rộng bao nhiêu token._ - Thông tin của tôi được lưu ở đâu sau khi phiên chat đóng lại? - Hệ thống chọn lưu cái gì và bỏ cái gì, theo quy tắc nào? - Ở lượt sau, nó lấy lại đúng mảnh nào, và ai quyết định mảnh đó? - Ai được xem phần đã lưu, giữ trong bao lâu, và xóa bằng cách nào? Nếu cả bốn câu trả lời đều xoay quanh con số token của cửa sổ, thứ bạn đang xem là một cửa sổ rộng, không phải memory. Cửa sổ rộng vẫn có giá trị thật, chỉ đừng giao cho nó phần việc bạn tưởng nó nhớ giúp. Muốn đi tiếp, bài [AI Agent khác chatbot ở điểm nào](/ai/ai-agent-khac-chatbot-o-diem-nao) đặt memory cạnh hai trục còn lại là tool và quyền hành động. Chỗ memory được vận hành nằm trong bài [Harness Engineering là gì](/ai/harness-engineering-la-gi), còn phần hạ tầng giữ state, quyền và truy vết nằm ở bài [vì sao AI Agent cần một platform](/ai/vi-sao-ai-agent-can-platform-thay-vi-prompt). Nếu bạn đang lẫn giữa state của một lần chạy và memory dài hạn, [Agent Loop là gì](/ai/agent-loop-la-gi) tách hai thứ đó theo từng nhịp.ai-agentmemorycontext-windowllmragnguyennlthttps://nguyennlt.com/ai/agent-loop-la-gi/https://nguyennlt.com/ai/agent-loop-la-gi/Agent Loop là vòng lặp giúp AI Agent quan sát, chọn hành động, gọi tool, cập nhật state và dừng đúng lúc. Xem một nhiệm vụ chạy từ đầu đến cuối.Wed, 19 Aug 2026 09:40:09 GMT> **Trả lời nhanh:** Agent Loop (vòng lặp vận hành của agent) là cơ chế lặp bên trong một AI Agent, tức chương trình dùng model để tự chọn bước và gọi tool hướng tới một mục tiêu. Mỗi vòng gồm việc ghép context, để model chọn hành động tiếp theo, thực thi hành động đó, nhận kết quả về rồi cập nhật state. Vòng lặp chạy lại cho tới khi đạt mục tiêu, chạm giới hạn, cần người duyệt hoặc gặp lỗi không thể phục hồi. Chính vòng lặp này, chứ không phải bản thân model, là thứ quyết định một agent chạy được hay chạy loạn. Bạn hỏi chatbot một câu, nó trả lời xong thì đứng chờ. Muốn đi tiếp, bạn phải gõ câu mới. Agent không chờ như thế: nó gọi tool, nhận kết quả về, rồi phải tự quyết bước kế, vì lúc đó không có ai ngồi gõ hộ. Khoảng lặng sau kết quả tool chính là chỗ hệ thống phải chọn đi tiếp, hỏi người, hay dừng hẳn. Thiếu chỗ chọn đó thì vòng chạy hỏng ngay. Ví dụ một agent được giao kiểm tra trạng thái đơn hàng: không có vòng lặp có điểm dừng, nó có thể gọi lại đúng cái tra cứu đó vài lần, hoặc tuyên bố xong khi khách vẫn chưa nhận được câu trả lời. Trong bài viết này, mình sẽ giải thích vì sao khoảng lặng sau kết quả tool lại cần một vòng lặp có điểm dừng, chứ không phải một câu trả lời hay hơn. Mình sẽ đi một lần chạy minh họa để bạn thấy chỗ chọn đó hiện ra từng nhịp. Cùng mình tìm hiểu nhé.  _Agent Loop biến một mục tiêu thành chuỗi quyết định và hành động có điểm dừng. Đây là sơ đồ khái niệm, không phải spec của một framework._ ## Agent Loop là gì và nó nằm ở đâu trong một AI Agent? Agent Loop là vòng lặp thực thi: hệ thống lặp lại chu trình quan sát tình hình, chọn một hành động, thực hiện hành động đó, nhận kết quả, rồi dùng kết quả mới để quyết định vòng sau. Nó không phải một sản phẩm, một model hay một thư viện. Nó là cơ chế. AI Agent là cả hệ thống bạn nhìn thấy từ bên ngoài: có giao diện, quyền truy cập dữ liệu, tool và giới hạn. Agent Loop là phần động cơ bên trong. Nói agent chạy được chỉ nhờ model cũng giống nói xe chạy được chỉ nhờ xăng: đúng một phần, nhưng bỏ qua phần cơ khí biến nhiên liệu thành chuyển động. Anthropic mô tả agent theo hướng này: hệ thống tự định hướng quy trình và cách dùng tool của chính nó, chạy theo vòng lập kế hoạch, hành động, quan sát, điều chỉnh, lặp lại cho tới khi xong việc hoặc cần con người can thiệp ([Anthropic, Trustworthy agents in practice](https://www.anthropic.com/research/trustworthy-agents)). Không có nhịp lặp tự định hướng, hệ thống có thể vẫn hữu ích, nhưng chưa phải agent theo cách phân loại này. So với chatbot, khác biệt nằm ở ai quyết định bước kế tiếp. Với chatbot, bạn hỏi, model trả lời, hết lượt. Muốn đi tiếp thì bạn phải gõ câu mới. Với Agent Loop, hệ thống có thể tự chạy vòng tiếp theo dựa trên kết quả trung gian. Bài [AI Agent khác chatbot ở điểm nào?](/ai/ai-agent-khac-chatbot-o-diem-nao) tách kỹ ranh giới này. Một điểm cần giữ từ đầu: model đề xuất, code thực thi. Runtime hoặc harness (lớp điều khiển hành vi agent) mới thực sự gọi tool, bắt lỗi, đếm số vòng và cắt vòng lặp. Bài [Harness Engineering là gì](/ai/harness-engineering-la-gi) giải thích kỹ hơn lớp này. ## Một lần chạy bắt đầu bằng những gì? Trước khi vòng lặp quay vòng đầu tiên, hệ thống phải có một bộ đầu vào đủ rõ. Thiếu một thành phần quan trọng, agent có thể không chạy được, hoặc chạy mà không ai biết khi nào nó nên dừng. | Thành phần | Nó là gì | Thiếu thì sao | |---|---|---| | Goal hoặc input | Mục tiêu hoặc yêu cầu cụ thể của lần chạy này | Agent không biết hướng nào là đúng | | Instructions | Cách hành xử, giọng điệu, ràng buộc, điều không được làm | Agent tự diễn giải theo tín hiệu còn lại trong context | | Danh sách tool và quyền | Những hành động agent được phép thực hiện và phạm vi của từng hành động | Agent hoặc bất lực, hoặc chạm vào thứ không nên chạm | | Context và state | Thông tin hiện có trong lần chạy này, gồm kết quả các bước đã làm | Vòng sau không biết vòng trước đã làm gì | | Điều kiện hoàn thành | Dấu hiệu để biết công việc được coi là xong | Agent không có căn cứ đáng tin để kết thúc | | Giới hạn | Số vòng tối đa, thời gian, chi phí, phạm vi dữ liệu | Vòng lặp có thể chạy dài vô ích | AWS mô tả agent tự chủ quanh một LLM (Large Language Model), tức model ngôn ngữ lớn, được bổ sung truy xuất dữ liệu, tool và memory (bộ nhớ), rồi được orchestration, tức lớp điều khiển vòng chạy và điểm dừng, chạy trong vòng lặp tới khi gặp lý do dừng ([AWS Generative AI Lens](https://docs.aws.amazon.com/wellarchitected/latest/generative-ai-lens/agentic-ai.html)). Đây là mô tả kiến trúc của AWS, không phải chuẩn bắt buộc. Orchestration của một vòng lặp khác việc điều phối nhiều agent cùng một kết quả cho khách; chỗ khác nằm ở bài [Multi-Agent Orchestration là gì](/ai/multi-agent-orchestration-la-gi). State không phải memory. State mô tả tiến độ của một lần chạy, chẳng hạn kết quả tool vừa trả về và việc đã thử. Memory giữ và lấy lại thông tin qua nhiều lần chạy, chẳng hạn sở thích của người dùng. Một phần state có thể được lưu lâu hơn tùy thiết kế; agent vẫn có thể hoàn thành nhiều việc mà không cần memory dài hạn. Chỗ khác nhau giữa cửa sổ của một lần gọi và lớp nhớ qua nhiều phiên nằm ở bài [Memory trong AI Agent](/ai/memory-trong-ai-agent-context-window). Nếu bạn đang hỏi kho tài liệu RAG có thay được memory của từng người không, bài [RAG có đủ cho AI Agent không](/ai/rag-co-du-cho-ai-agent) tách vector search, Knowledge và long-term memory. ## Bên trong một vòng lặp, agent thực sự làm gì? Đầu vào đã đủ, giờ tới phần vòng lặp xử lý chúng. Có thể tách một vòng thành năm bước theo thứ tự xảy ra trong hệ thống. Cách nhóm này dùng một mô hình khái niệm chung, không phải đặc tả của framework cụ thể.  _Đây mới là một vòng. Nhiệm vụ thường cần nhiều vòng, và mỗi vòng phải mang kết quả thật sang vòng sau._ ### 1. Ghép context hiện tại Hệ thống gom mục tiêu, instructions (chỉ dẫn vận hành), danh sách tool và kết quả các vòng trước. Nếu thiếu kết quả cũ, model có thể hành động như chưa từng làm gì; nếu context quá nhiều nhiễu, chi tiết quan trọng dễ bị lấp. ### 2. Model chọn bước tiếp theo Trong một Agent Loop đơn giản, model thường tạo câu trả lời cuối hoặc đề xuất gọi tool kèm tham số. Model chỉ phát ra ý định có cấu trúc, không nắm quyền thực thi. Lập luận nội bộ cũng không mặc định phải được lưu hay hiển thị để vòng lặp hoạt động. ### 3. Hệ thống gọi tool Runtime kiểm tra tool và tham số rồi mới thực thi. Guardrail (hàng rào an toàn) hoặc cổng duyệt có thể chặn tại đây. Quyền của agent nằm ở lớp tool và phân quyền, không nằm trong model. ### 4. Kết quả tool quay lại vòng lặp Tool trả về dữ liệu, lỗi hoặc kết quả rỗng để model đọc ở vòng sau. Lỗi cần được truyền rõ ràng: thông báo không tìm thấy đơn hữu ích hơn một khoảng trống im lặng. ### 5. State được cập nhật và vòng mới bắt đầu Observation được ghi vào state. Vòng tiếp theo bắt đầu với thông tin mới, nhờ đó agent có thể sửa hướng thay vì đoán hết từ đầu. State cập nhật sai có thể khiến agent lặp lại con đường cũ. ## Toàn bộ vòng đời của một nhiệm vụ chạy thật diễn ra ra sao? Một nhiệm vụ thật có thể cần nhiều vòng. Kết quả của vòng trước quyết định vòng sau đi hướng nào. Hãy lấy một ví dụ giả định: agent nhận việc kiểm tra trạng thái đơn hàng rồi soạn câu trả lời cho khách. Đây là kịch bản minh họa để dễ hình dung, không phải log của một hệ thống cụ thể.  _Đường đi không được viết sẵn từng bước. Kết quả của mỗi tool quyết định bước kế tiếp trong ví dụ giả định này._ **Nhận mục tiêu.** Agent nhận yêu cầu kiểm tra đơn và soạn phản hồi, cùng chỉ dẫn, tool được phép dùng và giới hạn số vòng. **Đọc mã đơn.** Model rút mã đơn từ tin nhắn. Nếu thiếu mã, nhánh hợp lý là hỏi lại khách, không phải đoán bừa. **Gọi tool tra cứu.** Model đề xuất tool cùng mã đơn; runtime kiểm tra rồi thực thi. **Quan sát kết quả.** Trong ví dụ này, tool báo đơn đang chờ giao và bị trễ. Observation vào state, làm đổi hướng phần còn lại. **Bổ sung policy hoặc hỏi người.** Agent gọi tool tra policy nếu được phép, hoặc dừng để hỏi người khi vượt phạm vi tự quyết. Đây là human-in-the-loop (có người duyệt trong Agent Loop). **Soạn phản hồi.** Có đủ dữ kiện, model soạn câu trả lời theo chỉ dẫn. **Kiểm tra tiêu chí.** Guardrail bằng code, một bước model riêng hoặc người duyệt kiểm tra trạng thái đơn, nguồn dữ kiện và ràng buộc. **Trả kết quả cuối.** Đạt tiêu chí thì vòng lặp kết thúc; chưa đạt thì quay lại để sửa hoặc chuyển sang một nhánh dừng. Điều đáng để ý là bước tra cứu policy chỉ xuất hiện vì tool tra cứu trả về trạng thái trễ. Nếu đơn giao đúng hạn, đường đi có thể ngắn hơn. Workflow cố định cũng có thể rẽ nhánh theo kết quả trung gian, nhưng các nhánh đã được code định trước. Trong Agent Loop, model tự chọn hành động hoặc tool tiếp theo từ thông tin mới, còn code giữ quyền thực thi và giới hạn. ## Agent biết khi nào phải dừng bằng cách nào? Nhiệm vụ vừa rồi có thể kéo dài tùy tình hình, nên hệ thống phải có cách ngắt vòng. Có thể nhóm kết thúc thành bốn trạng thái dựa trên lý do dừng, không dựa trên việc kết quả tốt hay xấu.  _Dừng không chỉ có nghĩa là làm xong. Một Agent Loop an toàn cũng phải biết dừng khi hết ngân sách, cần người quyết hoặc không thể phục hồi._ ### Hoàn thành mục tiêu Model đưa ra kết quả cuối thay vì đề xuất thêm tool call, và kết quả đó thỏa điều kiện hoàn thành đã đặt từ đầu. Vòng lặp ngắt, trả output. Điều kiện hoàn thành phải kiểm tra được. Một yêu cầu mơ hồ như trả lời tốt cho khách chỉ đẩy việc tự chấm ngược lại cho model. ### Chạm giới hạn cứng Số vòng, thời gian hoặc chi phí vượt ngưỡng thì code cắt Agent Loop dù việc chưa xong. Google Cloud lưu ý vòng lặp phải có điều kiện kết thúc, vì thiết kế sai có thể chạy vô hạn và tăng tài nguyên cùng chi phí ([Google Cloud, design patterns for agentic AI](https://docs.cloud.google.com/architecture/choose-design-pattern-agentic-ai-system)). Trang này nói về loop workflow, không phải đặc tả chung cho mọi framework. ### Cần người duyệt Agent chạm hành động vượt quyền tự quyết, chẳng hạn hoàn tiền hoặc sửa dữ liệu thật. Loop tạm dừng và chuyển quyết định cho người. Đây là điểm dừng có chủ đích, không phải sự cố. ### Gặp lỗi không thể phục hồi Tool tiếp tục hỏng sau khi thử lại, quyền bị từ chối hoặc dữ liệu không thể xử lý. Hệ thống dừng và báo lỗi thay vì cố xoay xở tiếp. Cách hiện thực khác nhau tùy framework. OpenAI Agents SDK (Software Development Kit) là một ví dụ: Runner dừng khi có `final_output`; chạy vòng mới sau handoff (chuyển giao sang agent khác) hoặc tool call; tạo lỗi `MaxTurnsExceeded` nếu vượt `max_turns` ([OpenAI Agents SDK, Running agents](https://openai.github.io/openai-agents-python/running_agents/)). Đây là hành vi theo tài liệu được kiểm tra ngày 19/08/2026, không phải quy tắc chung. ## Agent Loop thường hỏng ở đâu? Biết cách dừng không có nghĩa vòng lặp sẽ chạy trơn. Các lỗi dưới đây được nhóm theo dấu hiệu hiện ra trong trace hoặc kết quả cuối, giúp bạn lần ngược về nguyên nhân mà không cần biết framework bên dưới.  _Năm dấu hiệu nằm ở các lớp khác nhau. Trace giúp xác định vòng nào bắt đầu lệch, thay vì chỉ nhìn câu trả lời cuối._ ### Lặp lại cùng một hành động Agent gọi lại một tool với tham số gần giống nhau nhưng không tiến triển. Kết quả cũ có thể chưa được đưa đủ vào context, nên mỗi vòng lại bắt đầu từ state thiếu thông tin. ### Context phình ra hoặc mất chi tiết quan trọng Vòng lặp càng dài, thông tin mang theo càng lớn. Chi tiết quan trọng có thể bị lấp, bị rút gọn hoặc rơi khỏi context. Agent vì thế có thể quên ràng buộc ban đầu. ### Tool có quyền quá rộng hoặc mô tả mơ hồ Tool mô tả chung chung như cập nhật đơn hàng không nói rõ được cập nhật gì, trong phạm vi nào. Model phải suy diễn cách dùng. Quyền càng rộng, hậu quả của một lần suy diễn sai càng lớn. Đây là rủi ro thuộc về thiết kế hệ thống, không chỉ là lỗi của model. ### Agent tuyên bố xong quá sớm Agent trả kết quả khi việc chưa xong, chẳng hạn thiếu xác minh hoặc dựa trên phỏng đoán. Điều kiện hoàn thành quá lỏng khiến model vừa làm vừa tự chấm mà không có kiểm tra độc lập. ### Không có tracing để biết hỏng ở bước nào Không có tracing, tức bản ghi các bước của lần chạy như tool được gọi, tham số, kết quả và trạng thái kết thúc, bạn chỉ thấy đầu vào cùng đầu ra. Phần giữa vẫn là hộp đen, nên bốn vấn đề trên khó được phân biệt. Tracing ở đây là bằng chứng vận hành, ghi lại hành động và kết quả thực tế của hệ thống. Nó không đồng nghĩa với việc phơi bày quá trình lập luận nội bộ của model. Hai thứ khác nhau về bản chất lẫn mục đích; thứ cần để gỡ lỗi là dấu vết hành động có thể kiểm tra. ## Khi nào bạn không cần Agent Loop? Câu trả lời thẳng: khi các đường đi và điều kiện rẽ nhánh đều có thể định trước. Viết chúng bằng code thường rẻ hơn, nhanh hơn và dễ đoán hơn, kể cả khi quy trình vẫn đọc kết quả trung gian để chọn một nhánh đã biết. | Cách làm | Ai quyết định bước tiếp theo | Hợp với việc | |---|---|---| | Chatbot hoặc một lần gọi model | Người dùng, qua từng lượt gõ | Hỏi đáp, tóm tắt, soạn nháp một lần | | Workflow cố định | Code, theo đường đi và điều kiện rẽ nhánh lập trình sẵn | Quy trình có thể định trước các đường đi hợp lệ | | Agent Loop | Model, tự chọn hành động hoặc tool tiếp theo từ kết quả trung gian | Việc cần thay đổi đường đi theo dữ kiện phát sinh mà code chưa định sẵn từng nhánh | Cái giá phải trả cũng nên nói cho sòng phẳng. Agent Loop chạy nhiều vòng nên có thể cần nhiều lượt gọi model hơn một lần gọi đơn lẻ. Nó cũng có thể chậm hơn vì mỗi vòng phải đợi tool trả kết quả, và phức tạp hơn để vận hành vì phải lo thêm giới hạn, guardrail, tracing cùng điểm duyệt. Mức chênh lệch phụ thuộc vào nhiệm vụ và cách dựng hệ thống, nên một con số chung sẽ dễ gây hiểu sai. Anthropic khuyến nghị bắt đầu từ giải pháp đơn giản nhất và chỉ tăng độ phức tạp khi thực sự cần; workflow phù hợp khi đường đi đã biết trước, còn agent phù hợp khi cần sự linh hoạt và quyết định do model điều hướng. Họ cũng lưu ý hệ thống agentic thường đánh đổi độ trễ và chi phí để lấy khả năng xử lý tốt hơn trên tác vụ khó ([Anthropic, Building Effective AI Agents](https://www.anthropic.com/engineering/building-effective-agents)). Nếu đang cân nhắc đưa agent vào việc thật, bài [Vì sao AI Agent cần một platform, không chỉ một prompt?](/ai/vi-sao-ai-agent-can-platform-thay-vi-prompt) đi tiếp vào runtime và kiểm soát production. ## Câu hỏi thường gặp Năm câu dưới đây xử lý những ranh giới còn dễ nhầm theo cơ chế, không theo nhãn sản phẩm. ### Agent Loop có phải ReAct không? Không hẳn. ReAct (Reasoning and Acting), được đề xuất trong paper công bố lần đầu năm 2022, đan xen lập luận với hành động để lấy thông tin ngoài rồi cập nhật kế hoạch ([ReAct paper](https://arxiv.org/abs/2210.03629)). Agent Loop rộng hơn; ReAct là một cách tổ chức, không phải cách duy nhất. ### Có tool calling là đã có Agent Loop chưa? Chưa. Tool calling chỉ thành Agent Loop khi kết quả được đưa ngược vào để hệ thống tự quyết định bước kế tiếp và quá trình có thể lặp lại. ### Memory có bắt buộc trong mọi Agent Loop không? Không. Agent Loop cần mang đủ state từ bước trước sang bước sau, nhưng memory qua nhiều lần chạy là tùy chọn. Chỉ thêm memory dài hạn khi nhiệm vụ thật sự cần. ### Agent Loop có tự học sau mỗi vòng không? Không theo nghĩa model tự được huấn luyện lại. Agent đổi hướng vì kết quả mới đi vào context; trọng số model không tự thay đổi chỉ vì Agent Loop vừa hoàn tất. ### Human-in-the-loop có làm agent mất tự động không? Không, nó chỉ giới hạn phạm vi tự quyết. Agent vẫn tự chạy những bước được phép, rồi dừng ở hành động có hậu quả thật để chờ người xác nhận. Với việc động tới tiền hoặc dữ liệu khách hàng, đây có thể là lựa chọn kiểm soát hợp lý, không phải dấu hiệu agent thất bại. ## Điều cần nhớ khi nhìn một AI Agent chạy thật Đừng dừng ở câu hỏi hệ thống dùng model gì. Model chỉ là một mắt xích; khả năng hành động và giới hạn vận hành nằm ở cả vòng lặp. Năm câu hỏi đáng đặt ra mỗi khi nhìn một agent: - Mục tiêu của một lần chạy được định nghĩa ra sao, và dựa vào đâu để biết là xong - Agent có những tool nào, và mỗi tool được cấp quyền tới đâu - State trong một lần chạy được giữ và truyền đi thế nào, có memory dài hạn hay không - Vòng lặp dừng ở những điều kiện nào, gồm cả giới hạn cứng và điểm chờ người duyệt - Có tracing để dựng lại từng bước khi kết quả sai hay không Trả lời được năm câu đó, bạn đã nhìn agent như một hệ thống thay vì hộp đen thông minh. Muốn đi tiếp, nếu còn lấn cấn ranh giới khái niệm, bạn có thể đọc [AI Agent khác chatbot ở điểm nào?](/ai/ai-agent-khac-chatbot-o-diem-nao). Nếu muốn xuống thêm một tầng để xem lớp code quanh vòng lặp làm gì, bài [Harness Engineering là gì?](/ai/harness-engineering-la-gi) là chỗ hợp lý để mình nối tiếp câu chuyện.agent-loopai-agentllmtool-callingorchestrationnguyennlthttps://nguyennlt.com/ai/harness-engineering-la-gi/https://nguyennlt.com/ai/harness-engineering-la-gi/Harness Engineering là lớp bọc quanh LLM: tool, memory, vòng lặp và điểm dừng. Nó biến model thành AI Agent, không chỉ chatbot biết trả lời.Mon, 17 Aug 2026 11:48:07 GMT> **Trả lời nhanh:** Harness Engineering là kỷ luật thiết kế lớp bọc quanh một LLM (Large Language Model): chọn tool, nạp context, chạy vòng lặp, kiểm tra kết quả và quyết định khi nào dừng. Model chỉ sinh chữ. Harness (lớp điều khiển hành vi agent) mới cho phép hệ thống hành động, nhớ tiến độ, tự kiểm và dừng khi đạt mục tiêu hoặc chạm giới hạn. LangChain viết tắt: agent bằng model cộng harness. Thiếu lớp đó, bạn đang có một chatbot hoặc một lần gọi model, dù nhãn sản phẩm viết AI Agent. Nếu từng xem một sản phẩm được gắn nhãn “AI Agent”, bạn có thể nhận ra phần lớn nội dung giới thiệu chỉ tập trung vào model: model nào vừa ra mắt, model nào đạt điểm cao hơn. Nhưng khi dùng thử, sản phẩm thường chỉ trả lời rất lịch sự rồi dừng lại. Nó không thể tra cứu đơn hàng, không nhớ mình đã kiểm tra đến đâu, cũng không biết khi nào nên chuyển cuộc trò chuyện cho nhân viên hỗ trợ. Nhìn từ bên ngoài, chúng ta dễ cho rằng model chưa đủ thông minh. Nhưng nguyên nhân thường nằm ở phần hệ thống bao quanh: AI chưa được cung cấp công cụ để hành động, chưa có cơ chế ghi nhớ tiến độ và chưa được đặt ra giới hạn rõ ràng để biết lúc nào cần dừng lại. Bài viết này dành cho người không làm kỹ thuật, nên mình sẽ bỏ qua những đoạn cấu hình phức tạp và tập trung vào cách một AI Agent thực sự hoạt động. Cùng mình tìm hiểu nhé. _Bài này là cách mình đọc tài liệu công khai tới ngày 17/8/2026, không phải kết quả đo từ hệ thống mình tự vận hành._  _Model sinh chữ. Harness cho phép hành động, nhớ, kiểm và dừng. Cộng hai thứ đó mới ra agent._ ## Harness Engineering là gì, và harness khác model ở chỗ nào? Harness Engineering (kỷ luật thiết kế lớp điều khiển hành vi quanh model) là phần bao quanh model, không phải bản thân model. [LangChain định nghĩa harness](https://www.langchain.com/blog/the-anatomy-of-an-agent-harness) là toàn bộ code, cấu hình và logic thực thi không thuộc về model. Cũng theo bài đó, một model trần chưa phải agent; nó thành agent khi harness cấp cho nó state, khả năng thực thi tool, vòng phản hồi để thấy kết quả thật, và những giới hạn có thể cưỡng chế được. Cách viết tắt bài đó dùng, được nhắc lại nhiều trong năm 2026: agent bằng model cộng harness. Một chỗ dễ nhầm tên: harness ở đây chỉ bộ khung điều khiển, không liên quan tới Harness.io, sản phẩm cùng tên trong lĩnh vực triển khai code. Cái tên còn mới. Ngày 5/2/2026, [Mitchell Hashimoto viết](https://mitchellh.com/writing/my-ai-adoption-journey) rằng anh gọi thói quen của mình là harness engineering: mỗi lần agent làm sai, anh sửa luôn môi trường quanh nó để lỗi khó lặp lại. Hai dạng anh kể là viết lại file hướng dẫn cho agent, ví dụ AGENTS.md, và làm sẵn tool để agent tự biết mình sai. Anh nói thẳng là chưa rõ ngành đã có thuật ngữ thống nhất chưa. [Trang Wikipedia về agent harness](https://en.wikipedia.org/wiki/Agent_harness) ghi nhận việc ai đặt ra cụm từ này vẫn còn tranh luận, và các kỹ thuật tương tự đã có trước cái tên. Bỏ hết từ kỹ thuật thì thế này. Model là một bạn thực tập rất nhanh, viết gì cũng trôi chảy. Harness là bản mô tả việc, bộ chìa khóa bạn ấy được phép dùng, checklist phải chạy trước khi báo xong, và quy định rằng bạn ấy không được tự chuyển tiền hoàn cho khách nếu chưa có người duyệt. Thực tập giỏi hơn thì tốt, nhưng thiếu mấy thứ đó thì không ai dám giao việc thật.  _Model viết nhanh. Harness mới là bản mô tả việc, chìa khóa, checklist và lúc phải dừng._ ## Vì sao một LLM chưa phải là AI Agent? Vì model không với tới thế giới bên ngoài: nó nhận chữ và ảnh, rồi trả về chữ. Vẫn theo [bài của LangChain](https://www.langchain.com/blog/the-anatomy-of-an-agent-harness), một model tự nó không giữ được state bền (tiến độ đã lưu), không thực thi code và không truy cập được thông tin đang thay đổi ngoài kia. Ba việc đó nằm ở lớp bọc.  _Model trả lời bằng chữ. Agent phải mở được hệ thống thật trước khi kết luận._ Còn agent, tức chương trình tự gọi tool và lặp bước để hoàn thành một việc, thì phải làm được. [IBM định nghĩa AI agent](https://www.ibm.com/think/topics/ai-agents) là hệ thống tự động thực hiện tác vụ bằng cách tự thiết kế workflow với các tool sẵn có. [Hướng dẫn thực hành của OpenAI](https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/) tách một agent thành ba thành phần: model, tools và instructions. Model nằm trong trọng số; tools và phần lớn vòng chạy quanh instructions nằm trong harness. Mình đã viết riêng một bài về ranh giới này: [chatbot dừng ở câu trả lời](/ai/ai-agent-khac-chatbot-o-diem-nao), còn agent tiếp tục tới khi đạt mục tiêu hoặc chạm giới hạn. Phần tiếp tục đó do harness tạo ra, không phải do model thông minh thêm. Nhịp phổ biến nhất của phần tiếp tục là [ReAct (Reasoning and Acting)](https://arxiv.org/abs/2210.03629), công bố năm 2022: nghĩ, hành động, quan sát, rồi nghĩ tiếp. Model đề xuất hành động; harness thực thi rồi đưa kết quả quan sát ngược lại. ReAct là một pattern phổ biến, không phải kiến trúc duy nhất. Giả sử bạn hỏi: đơn này có được hoàn tiền không? Một model sẽ viết đoạn văn lịch sự, nghe hợp lý, dựa trên chính sách nó đoán là của bạn. Một agent thì phải mở đơn hàng đó ra, đối chiếu chính sách thật, rồi mới trả lời hoặc hành động. Phần mở đơn và phần hành động là việc của harness. ## Harness làm những việc gì quanh model? Năm mục dưới đây là các việc của lớp bọc, không phải năm sản phẩm bạn phải mua. Mình liệt kê để bạn nhận ra hệ thống hụt ở đâu khi chạy nửa vời rồi đứng.  _Đây là vòng nghĩ – hành – kiểm – dừng quanh model. Hai việc harness còn lại ở trên, nhớ và hàng rào an toàn, không nằm trên ảnh này._ ### Cho phép hành động, không chỉ trả lời Model không tự gọi API (Application Programming Interface). Nó chỉ nói ra muốn dùng tool nào với tham số nào, còn ứng dụng của bạn mới là bên thực thi: đó là function calling, tức cơ chế model yêu cầu ứng dụng gọi một hàm hoặc API. Nhưng có tool chưa đủ: [IBM nói rõ](https://www.ibm.com/think/topics/ai-agents-vs-ai-assistants) riêng khả năng gọi tool không biến một LLM thành agent, vì hệ thống còn phải tự quyết định dùng tool nào, khi nào và kết hợp ra sao để đạt mục tiêu. Chỗ quyết định đó nằm trong harness. ### Nhớ đúng thứ, đúng lúc Context window (cửa sổ ngữ cảnh) không phải memory: nó là lượng thông tin nhét được vào một lần gọi model. Memory (bộ nhớ) là các quyết định: lưu gì, lấy lại lúc nào, cho ai, giữ bao lâu. [Databricks mô tả](https://www.databricks.com/blog/ai-harness) đây là việc của lớp bọc: harness có thể ghi tiến độ ra file hoặc một kho riêng để model không phải đọc lại toàn bộ đoạn hội thoại ở mỗi lượt, một đoạn chỉ dài thêm và càng dài càng dễ trôi mất chi tiết. Bài [Memory trong AI Agent](/ai/memory-trong-ai-agent-context-window) đi tiếp chỗ này: vì sao nới cửa sổ vẫn không thành memory, và ba lớp nhớ theo thời gian sống. Bài [RAG có đủ cho AI Agent không](/ai/rag-co-du-cho-ai-agent) tách tiếp việc lục tài liệu dùng chung và việc ghi hồ sơ từng khách.  _Context window là chỗ nhét một lần gọi. Memory là quyết định lưu gì và lấy lại lúc nào._ ### Lặp bước và biết lúc dừng Vòng lặp cần đi kèm điểm dừng: số bước tối đa, thời gian tối đa, điều kiện được coi là xong. [Cloudflare mô tả](https://developers.cloudflare.com/agents/harnesses/) chính harness là nơi quyết định agent nên chạy tiếp hay dừng. Ngày 26/11/2025, [Anthropic viết về harness cho tác vụ chạy dài](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents): những việc kéo dài qua nhiều context window, và thiếu lớp bọc tử tế thì agent hay mắc hai lỗi, làm quá nhiều thứ cùng lúc và tuyên bố xong quá sớm. Cách họ xử lý gợi hình ảnh ca trước để lại giấy nhắn tiến độ cho ca sau. Muốn nhìn phần này theo từng nhịp thay vì theo danh sách năng lực, bài [Agent Loop là gì](/ai/agent-loop-la-gi) đi từ lúc nhận mục tiêu, gọi tool, cập nhật state tới các nhánh dừng của một lần chạy. ### Kiểm tra trước khi tuyên bố xong Ngày 2/4/2026, [Birgitta Böckeler viết trên trang của Martin Fowler](https://martinfowler.com/articles/harness-engineering.html) về hai loại cơ chế: loại định hướng trước khi agent hành động, và loại quan sát sau đó để nó tự sửa. Kiểm tra có thể do máy làm (chạy test, chạy công cụ soát lỗi) hoặc do một model khác đánh giá. Điểm cần nhớ: một dòng dặn trong prompt rằng hãy cẩn thận không phải bước kiểm tra; bước kiểm tra là thứ hệ thống thật sự chạy, và có thể kết luận là chưa đạt. Hashimoto nói cùng ý: hãy cho agent những tool nhanh để nó tự biết mình sai. [LangChain kể một thí nghiệm](https://www.langchain.com/blog/improving-deep-agents-with-harness-engineering) khá thẳng thắn: với coding agent của họ, điểm trên bộ bài kiểm tra Terminal Bench 2.0 gồm 89 tác vụ đi từ 52,8 lên 66,5 trong khi model giữ nguyên là gpt-5.2-codex, và họ nói phần duy nhất thay đổi là harness. Phạm vi con số rất hẹp: một nhà cung cấp, một agent viết code, một bộ bài kiểm tra. Thứ đáng mang đi là kiểu lỗi họ gặp: agent đọc lại việc của chính nó, thấy ổn, rồi dừng. Chỉ một bước kiểm tra độc lập trong harness mới cắt được vòng tự khen đó. ### Chặn việc không được phép Guardrail (hàng rào an toàn) khác hẳn một lời dặn. Prompt có thể xin model đừng làm gì đó; harness phải có khả năng từ chối. Những hành động khó hoàn tác, ví dụ gửi tin cho khách, hoàn tiền, xóa dữ liệu, thường cần cổng phê duyệt của người thật, hoặc bị giới hạn cứng ở lớp tool và phân quyền. Mình viết kỹ hơn trong [bài về platform cho AI Agent](/ai/vi-sao-ai-agent-can-platform-thay-vi-prompt). ## Prompt engineering, context engineering và Harness Engineering khác nhau chỗ nào? Chúng lồng vào nhau, không thay thế nhau. [Databricks xếp ba lớp](https://www.databricks.com/blog/ai-harness) theo phạm vi mở rộng dần: prompt engineering (kỹ thuật tối ưu câu lệnh gửi vào model) lo câu chữ một lượt; context engineering (kỹ thuật chọn thông tin model được nhìn thấy) lo model nhìn thấy gì; Harness Engineering lo cả môi trường quanh model.  _Prompt và context nằm trong harness. Chúng không thay thế nhau._ | Kỷ luật | Tối ưu cái gì | Artifact chính | | --- | --- | --- | | prompt engineering | Cách viết một lượt gửi vào model | Một prompt tốt | | context engineering | Model được nhìn thấy thông tin nào, khi nào | Retrieval, memory, cách chọn ngữ cảnh | | Harness Engineering | Cả môi trường quanh model: tool, vòng lặp, kiểm tra, điểm dừng | Bản thân harness | Hai lớp trong không mất giá trị vì có harness; cả hai nằm bên trong harness. Thứ dịch chuyển là chỗ đặt chú ý: từ cách viết một câu, sang thứ model được nhìn thấy, rồi sang cả hệ thống quanh nó. Đó là cách nhiều người làm nghề mô tả, không phải mốc chuẩn do tổ chức nào công bố. ## Harness khác runtime và platform thế nào? Mình lấy cách tách của [tài liệu Cloudflare Agents](https://developers.cloudflare.com/agents/harnesses/): hai lớp, harness và runtime. Đây là phân lớp của một nhà cung cấp, không phải chuẩn phổ quát. Harness là vòng lặp hành vi quanh model: dựng prompt, nạp memory, chọn tool, xử lý kết quả, và quyết định chạy tiếp hay dừng. Runtime (môi trường chạy bền) là hạ tầng: agent chạy ở đâu, state sống sót qua sự cố thế nào, lịch chạy, và observability (khả năng quan sát hệ thống). Cloudflare nói gọn: runtime trả lời agent sống ở đâu; harness trả lời agent làm gì ở mỗi lượt. Prompt không đứng ngang hàng harness trên tài liệu đó. Dựng prompt là việc của harness.  _Harness lo hành vi từng lượt, kể cả dựng prompt. Runtime lo chỗ chạy. Đây là hai lớp Cloudflare tách, không phải chuẩn phổ quát._ - **Harness:** Dựng prompt, nạp context, cho phép tool nào, vòng lặp chạy ra sao, khi nào dừng. - **Runtime:** Agent chạy ở đâu, state sống sót qua sự cố thế nào, quan sát bằng gì. Còn platform, theo nghĩa mình dùng trên site này, là tập hợp năng lực dùng chung để agent tồn tại được bên ngoài một lần gọi model; harness là lớp hành vi ngồi trên đó. Muốn xem một runtime cụ thể, [GoClaw](/ai/goclaw-la-gi) là ví dụ để đọc. ## Làm sao nhận ra sản phẩm gắn nhãn AI Agent có harness thật? Bạn không cần đọc code mới đoán được. Năm câu hỏi dưới đây đủ cho phần lớn trường hợp, kể cả agent bạn tự dựng. 1. Nó gọi được hệ thống thật nào, hay chỉ trả về văn bản? 2. Nó nhớ tiến độ qua nhiều bước, hay mỗi lượt bắt đầu như chưa từng làm gì? 3. Việc nguy hiểm có cổng duyệt hoặc chặn cứng, hay chỉ có câu dặn trong prompt? 4. Khi nó báo xong, có bước kiểm tra độc lập không? 5. Bạn xem lại được nó đã làm gì không, hay chỉ thấy câu trả lời cuối? Nếu phần lớn câu trả lời là không, thứ bạn đang có là một chatbot. Nói vậy không phải để dìm: chatbot tốt vẫn tiết kiệm nhiều thời gian, và ranh giới giữa hai loại nằm ở việc hệ thống được phép làm gì, không nằm ở nhãn dán. Chỉ nên tránh giao cho nó phần việc bạn đang tưởng nó tự làm xong. ## Khi nào chưa cần Harness Engineering? Khi việc chỉ gọn trong một lượt, chỉ đọc chứ không ghi, và luôn có người xem trước khi bất cứ điều gì xảy ra. Lúc đó thêm vòng lặp và bước kiểm tra chỉ làm chậm hơn. [Anthropic khuyên bắt đầu từ giải pháp đơn giản nhất](https://www.anthropic.com/engineering/building-effective-agents) và chỉ tăng độ phức tạp khi thật cần. [Microsoft xếp cùng ý tưởng thành một thang](https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/ai-agent-design-patterns) và nêu nguyên tắc chọn mức thấp nhất còn chạy được: nếu prompt engineering đã giải quyết xong bài toán thì bạn chưa cần agent. Nhiều nhu cầu nghe như cần agent thực ra chỉ cần một workflow có đường đi biết trước. Bậc nhiều agent cũng vậy: bài [Multi-Agent Orchestration là gì](/ai/multi-agent-orchestration-la-gi) giải thích vì sao thêm agent chưa chắc thông minh hơn. ## Câu hỏi thường gặp Năm câu dưới đây hay xuất hiện khi bạn đã nghe AI Agent nhưng chưa chắc đang thiếu lớp nào. Mỗi câu trả lời theo cơ chế, không theo nhãn sản phẩm. ### Harness trong bài này có phải phần mềm Harness.io không? Không. Harness ở đây là lớp bọc quanh model: tool, nhớ, vòng lặp, kiểm tra và điểm dừng. Harness.io là sản phẩm khác, dùng trong triển khai code. Trùng tên, không cùng việc. ### Chỉ cần model mạnh hơn thì đã có AI Agent chưa? Chưa. Model giỏi hơn thì chữ hay hơn, đoán khéo hơn. Nó vẫn không tự mở đơn hàng, không giữ tiến độ qua nhiều bước, và không tự dừng đúng lúc trừ khi lớp bọc quanh nó làm những việc đó. [LangChain viết](https://www.langchain.com/blog/the-anatomy-of-an-agent-harness) một model trần chưa phải agent. ### Gắn thêm tool vào chatbot đã thành agent chưa? Chưa chắc. [IBM nói rõ](https://www.ibm.com/think/topics/ai-agents-vs-ai-assistants) khả năng gọi tool tự nó không biến một LLM thành agent. Còn thiếu chỗ hệ thống tự chọn tool nào, gọi khi nào, kết hợp ra sao, và theo đuổi mục tiêu qua nhiều bước thay vì chờ bạn ra lệnh từng lượt. ### Harness Engineering có thay prompt engineering không? Không. Chúng lồng nhau. Prompt engineering lo câu chữ một lượt gửi vào model. Context engineering lo model được nhìn thấy thông tin nào. Harness Engineering lo cả môi trường quanh model. [Databricks xếp](https://www.databricks.com/blog/ai-harness) ba lớp theo phạm vi mở rộng dần, không phải ba thứ thay thế nhau. ### Harness khác runtime chỗ nào? Theo [tài liệu Cloudflare Agents](https://developers.cloudflare.com/agents/harnesses/), harness lo hành vi từng lượt, kể cả dựng prompt; runtime lo chỗ agent chạy và state sống sót thế nào. Đây là cách tách của một nhà cung cấp, không phải chuẩn phổ quát. Prompt không đứng thành lớp ngang hàng harness trên tài liệu đó. ## Kết luận: nhìn lớp bọc, không chỉ nhìn model Cách đọc gọn nhất: bỏ qua tên model trên banner, hỏi hệ thống có chạm được dữ liệu thật không, có nhớ đã làm tới đâu không, khi báo xong có bước kiểm không, và ai được quyền dừng. Thiếu mấy thứ đó thì bạn đang có chatbot. Chatbot tốt vẫn đáng dùng; chỉ đừng giao cho nó phần việc bạn tưởng nó tự làm xong. Nếu bạn định thử một agent cho việc của mình, câu hỏi đầu tiên theo mình không phải chọn model nào, mà là ai có quyền dừng nó lại. Muốn đi tiếp thì đọc [ranh giới chatbot và AI Agent](/ai/ai-agent-khac-chatbot-o-diem-nao), chỗ nhãn sản phẩm sai nhiều nhất, rồi [phần platform](/ai/vi-sao-ai-agent-can-platform-thay-vi-prompt), nơi harness và runtime nằm cạnh nhau.harness-engineeringai-agentllmprompt-engineeringagent-platformnguyennlthttps://nguyennlt.com/ai/ai-agent-khac-chatbot-o-diem-nao/https://nguyennlt.com/ai/ai-agent-khac-chatbot-o-diem-nao/Chatbot trả lời rồi dừng. AI Agent dùng tool, memory và quyền hành động để hoàn thành mục tiêu nhiều bước. Đây là ranh giới thực, không phải nhãn marketing.Fri, 14 Aug 2026 16:06:03 GMT> **Trả lời nhanh:** AI Agent khác chatbot ở quyền hành động, không ở giao diện chat. Chatbot nhận văn bản và trả văn bản, mỗi lượt gần như độc lập. Agent nhận một mục tiêu, tự chọn bước, gọi tool, giữ state, quan sát kết quả thật, rồi tiếp tục hoặc dừng khi đạt mục tiêu hay chạm giới hạn đã đặt. Khi mình nhìn một ô chat, mình không hỏi trước "cái này có AI không". Mình hỏi hệ thống sau ô đó có tự đi làm nốt việc không, hay chỉ trả lời rồi dừng. Nhìn ô nhập liệu thì hai hệ thống giống nhau đến mức gọi cả hai là AI Agent cũng nghe xuôi. Khác nhau hiện ra khi có việc thật. Một bên gõ "em đã ghi nhận yêu cầu hoàn tiền". Bên kia đã gọi cổng thanh toán. Tưởng nhầm thì bạn hoặc ngồi chờ máy tự xong, hoặc không thấy nó đã đụng đơn hàng, kho, hay tiền. Mình tách đúng chỗ khác nhau ngay dưới đây: hệ thống được phép làm gì, không phải khung chat trông ra sao.  _Chatbot kết thúc ở câu trả lời. Agent chỉ dừng khi đạt mục tiêu hoặc chạm giới hạn đã đặt trước._ ## Chatbot, workflow và agent nằm trên một phổ, không phải hai hộp tách biệt Chưa phải mọi cửa sổ chat dùng LLM (Large Language Model) đều là agent. Thực tế có một phổ, và nhiều sản phẩm đang nằm ở giữa phổ đó. [IBM định nghĩa AI agent](https://www.ibm.com/think/topics/ai-agents) là hệ thống tự động thực hiện tác vụ bằng cách tự thiết kế workflow với các tool sẵn có. Cũng theo IBM, chatbot không agentic thường không có tool, memory hay suy luận: chúng phục vụ mục tiêu ngắn, không lập kế hoạch trước và cần người dùng nhập tiếp ở từng lượt. [AWS mô tả theo cùng hướng](https://aws.amazon.com/what-is/ai-agents/): con người đặt mục tiêu, còn agent tự chọn những hành động cần làm để đạt mục tiêu đó. - **Chatbot rule-based:** Hệ thống đi theo kịch bản và từ khóa đã định sẵn, không sinh nội dung mới. - **Chatbot dùng LLM:** Hệ thống nhận văn bản và trả văn bản, có thể rất giỏi diễn đạt nhưng không chạm vào hệ thống nào khác. - **Assistant hoặc workflow có tool:** Model được gắn tool nhưng đi theo đường dẫn do code định sẵn, ví dụ luôn tìm kiếm rồi mới tóm tắt. - **Agent:** Model tự quyết định bước tiếp theo và tool cần dùng trong một vòng lặp, dựa trên kết quả nhận được từ môi trường. [Anthropic tách workflow và agent](https://www.anthropic.com/engineering/building-effective-agents) đúng ở ranh giới này trong tài liệu kỹ thuật công bố tháng 12/2024: workflow là LLM và tool được điều phối qua các đường code định trước, còn agent là LLM tự điều khiển quá trình của mình và cách sử dụng tool. [Microsoft xếp cùng ý tưởng thành một thang độ phức tạp](https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/ai-agent-design-patterns) trong hướng dẫn kiến trúc cập nhật năm 2026: gọi model trực tiếp mà không có logic agent và không có tool; một agent có tool, chạy lặp qua các lần gọi model và gọi tool với giới hạn số vòng; nhiều agent chỉ khi một agent không còn xử lý đáng tin cậy. Microsoft nêu rõ nguyên tắc chọn mức thấp nhất: nếu prompt engineering đã giải quyết được bài toán thì bạn chưa cần agent. Hệ quả thực tế là nhiều sản phẩm đang được gọi là AI Agent thực ra nằm ở hai nấc giữa. Đó không phải điều xấu. Vấn đề chỉ xuất hiện khi kỳ vọng được đặt theo nấc cuối cùng. ## Tool: từ nói về việc cần làm sang gọi được hệ thống thật Ba mục tiếp theo tách riêng ba trục tạo nên ranh giới: tool, memory và quyền hành động. Thiếu một trục, hệ thống vẫn có thể hữu ích, nhưng chưa hoàn chỉnh theo nghĩa agent.  _Tool, memory và quyền hành động là ba trục độc lập. Một hệ thống có thể mạnh ở trục này và trống ở trục kia._ Tool cho phép model yêu cầu ứng dụng đọc dữ liệu hoặc thực hiện một việc nằm ngoài trọng số đã huấn luyện. Điểm hay bị hiểu sai: model không tự gọi API (Application Programming Interface). Ứng dụng của bạn mới là bên thực thi. [Tài liệu function calling của OpenAI](https://platform.openai.com/docs/guides/function-calling) mô tả vòng trao đổi này theo năm bước, với tool được khai báo bằng JSON schema: 1. Ứng dụng gửi request kèm danh sách tool khả dụng. 2. Model có thể trả về một tool call thay vì câu trả lời cuối. 3. Ứng dụng thực thi tool đó ở phía mình. 4. Ứng dụng gửi kết quả tool ngược lại cho model. 5. Model trả lời cuối cùng hoặc yêu cầu thêm tool call. Vòng này có thể lặp bao nhiêu lần tùy tác vụ. Đây chính là nơi một chatbot bắt đầu chạm vào hệ thống thật, và cũng là nơi trách nhiệm chuyển từ câu chữ sang phần mềm: ai kiểm tra tham số, ai kiểm tra quyền, ai chặn lệnh sai. Nếu bạn muốn theo dõi phần lặp đó từ lúc nhận mục tiêu tới khi trả kết quả, bài [Agent Loop là gì](/ai/agent-loop-la-gi) mổ riêng toàn bộ vòng đời của một lần chạy. Nhưng có tool chưa đủ để gọi là agent. [IBM nói thẳng trong bài so sánh agent và assistant](https://www.ibm.com/think/topics/ai-agents-vs-ai-assistants) rằng chỉ riêng khả năng gọi tool không biến một LLM thành agent; agent còn phải tự quyết định dùng tool nào, dùng khi nào và kết hợp chúng ra sao để đạt mục tiêu. Cùng bài đó phân biệt assistant mang tính phản ứng, làm việc khi được yêu cầu, với agent mang tính chủ động, tự lập kế hoạch và hành động hướng tới một mục tiêu bằng tool và quyền được cấp. ## Memory: context window không đồng nghĩa với trí nhớ Chatbot nhớ được nội dung hội thoại thì chưa phải agent. Context window (cửa sổ ngữ cảnh) là lượng token được gửi vào một lần gọi model. Memory là cơ chế quyết định thông tin nào được lưu, lấy lại lúc nào, trong phạm vi của ai và sống bao lâu. Nhét toàn bộ lịch sử vào prompt là một cách dùng context window, không phải một thiết kế memory. Một hệ thống vận hành thật thường phải tách ít nhất ba lớp: - **State của run:** Tiến độ hiện tại của tác vụ, ví dụ đã xác minh đơn hàng, đang chờ duyệt. - **Lịch sử session:** Những gì người dùng đã nói trong phiên làm việc này. - **Memory dài hạn:** Thông tin cần giữ qua nhiều phiên, kèm phạm vi truy cập và thời hạn lưu. Với tác vụ chạy dài, Microsoft khuyến nghị lưu tiến độ, kết quả trung gian và lịch sử hội thoại vào một kho bền vững bên ngoài thay vì chỉ dựa vào context trong bộ nhớ tiến trình, đồng thời giới hạn phần state được lưu ở mức tối thiểu cần thiết. Microsoft nêu điều này trong cùng hướng dẫn kiến trúc đã dẫn ở trên. Anthropic mô tả khối xây dựng cơ bản là một LLM được tăng cường bằng retrieval, tool và memory, trong đó model có thể tự sinh truy vấn tìm kiếm, chọn tool và quyết định giữ lại thông tin nào. Cần tránh một ngộ nhận phổ biến: memory không phải là học lại. IBM lưu ý agent có thể nhớ và điều chỉnh dựa trên tương tác trước đó, nhưng model nền bên dưới không vì thế mà được huấn luyện lại liên tục. Hệ thống nhớ hơn không có nghĩa model đã giỏi hơn. Nếu bạn đang lẫn giữa cửa sổ ngữ cảnh và lớp lưu bên ngoài, bài [Memory trong AI Agent: vì sao context window không bao giờ là đủ](/ai/memory-trong-ai-agent-context-window) tách hai thứ đó theo đúng việc hỗ trợ đơn hàng. Nếu chỗ lẫn nằm giữa kho tài liệu dùng chung và hồ sơ từng khách, bài [RAG có đủ cho AI Agent không](/ai/rag-co-du-cho-ai-agent) tách vector search, Knowledge và long-term memory. ## Quyền hành động: vòng lặp, side effect và điểm dừng Quyền hành động là khả năng tạo ra thay đổi thật, ví dụ ghi dữ liệu, gửi tin nhắn, tạo phiếu hoàn tiền, chạy một lệnh, cộng với một vòng lặp quan sát rồi suy luận rồi hành động rồi quan sát tiếp cho tới khi đạt mục tiêu hoặc chạm giới hạn. Thiếu vòng lặp, một lần gọi tool chỉ là một hàm được kích hoạt bởi văn bản. Thiếu giới hạn, vòng lặp đó là rủi ro vận hành. Mô thức đặt tên cho cách đan xen suy luận và hành động là [ReAct (Reasoning and Acting)](https://arxiv.org/abs/2210.03629), công bố năm 2022. ReAct là một pattern phổ biến, không phải kiến trúc duy nhất. IBM mô tả cách áp dụng nó theo nhịp nghĩ, hành động, quan sát lặp lại sau mỗi phản hồi từ tool. Anthropic mô tả agent trong thực tế là LLM dùng tool theo phản hồi từ môi trường trong một vòng lặp, cần dữ liệu đối chiếu thật ở mỗi bước, và cần điều kiện dừng chẳng hạn số vòng lặp tối đa. Tài liệu này cũng cảnh báo chi phí cao hơn và sai số tích lũy qua nhiều bước, nên khuyến nghị chạy thử trong sandbox và đặt guardrail (hàng rào an toàn). Đây là chỗ khác biệt trở nên nghiêm túc. Một chatbot trả lời sai thì sai trong một đoạn văn, người đọc có thể bỏ qua. Một agent hành động sai sẽ ghi vào database, gửi tin cho khách hàng thật, hoặc kích hoạt một giao dịch. Phạm vi thiệt hại rộng hơn hẳn, và không phải hành động nào cũng hoàn tác được. Vì vậy hành động ghi thường cần idempotency (chạy lại không tạo thêm một hành động). Thao tác nhạy cảm cần cổng phê duyệt và checkpoint để có thể tiếp tục sau khi dừng. Microsoft nêu hai điểm đó trong cùng hướng dẫn kiến trúc đã dẫn ở trên. ## Bảng so sánh theo tiêu chí quyết định | Tiêu chí | Chatbot | AI Agent | | --- | --- | --- | | Mục tiêu | Trả lời đúng trong lượt hiện tại | Hoàn thành một việc qua nhiều bước | | Output | Văn bản cho người đọc | Văn bản cộng thay đổi trong hệ thống | | Tool | Không có, hoặc chỉ đọc theo đường cố định | Tự chọn tool và thứ tự gọi theo kết quả nhận được | | Memory | Chủ yếu là context của phiên hiện tại | State của run, lịch sử session, memory dài hạn có phạm vi | | Quyền hành động | Không tạo side effect ngoài hội thoại | Có quyền ghi hoặc gửi, kèm giới hạn và điểm dừng | | Người dùng làm gì | Hỏi tiếp ở từng bước | Đặt mục tiêu, duyệt các bước rủi ro, kiểm tra kết quả | | Rủi ro khi sai | Nội dung sai, người đọc phát hiện được | Dữ liệu, tiền hoặc quan hệ khách hàng bị ảnh hưởng thật | | Khi nào phù hợp | Hỏi đáp, soạn nháp, tra cứu, hỗ trợ tuyến đầu | Việc nhiều bước, cần tool, cần state và hành động thật | Bảng này là công cụ phân loại, không phải bảng xếp hạng. Một chatbot tốt không kém giá trị hơn một agent. Workflow có tool hoặc có ghi theo đường code cố định nằm giữa hai cột: chưa phải chatbot thuần, cũng chưa phải agent. Điều cần đọc từ bảng là mức trách nhiệm: càng đi sang cột phải, bạn càng phải trả lời được các câu hỏi về quyền, giới hạn, khả năng hoàn tác và người chịu trách nhiệm cuối. ## Khi nào chatbot vẫn đủ, khi nào cần agent Dùng chatbot khi công việc là hỏi đáp, đường đi hẹp và output để con người đọc rồi tự quyết. Dùng agent khi công việc gồm nhiều bước không đoán trước, cần gọi tool, cần giữ state qua thời gian và cần tạo ra thay đổi thật. Anthropic khuyên bắt đầu từ giải pháp đơn giản nhất và chỉ tăng độ phức tạp khi cần, bởi hệ thống agentic thường đánh đổi latency và chi phí để lấy kết quả tốt hơn trên tác vụ khó. Với nhiều ứng dụng, tối ưu một lần gọi model kèm retrieval và ví dụ trong prompt đã đủ. Vài tình huống giả định để thấy ranh giới rõ hơn: - **Giả sử bạn bán lẻ online và cần trả lời chính sách đổi trả:** Một chatbot đọc từ tài liệu nội bộ là đủ, vì câu trả lời không cần thay đổi gì trong hệ thống. - **Giả sử bạn cần 20 caption cho một chiến dịch:** Vẫn là chatbot, vì người duyệt là điểm kiểm soát chất lượng và không có side effect nào xảy ra trước khi đăng. - **Giả sử bạn muốn tự động đối chiếu khiếu nại với đơn hàng rồi đề xuất hoàn tiền:** Việc này cần tool để tra cứu đơn, cần state để nhớ đã kiểm tra tới đâu, và cần một bước người duyệt trước khi tiền thật ra khỏi tài khoản. Nếu các bước luôn giống nhau, đó là workflow. Chỉ gọi là agent khi model tự chọn đường đi và tool theo kết quả nhận được. Anthropic dùng chăm sóc khách hàng làm ví dụ vì nó kết hợp hội thoại với tool truy cập dữ liệu khách, đơn hàng, kiến thức nội bộ, cùng các hành động như hoàn tiền hay cập nhật ticket. - **Giả sử bạn muốn gom số liệu quảng cáo từ nhiều kênh rồi soạn báo cáo tuần:** Nếu các bước luôn giống nhau, một workflow cố định gọi API rồi cho model viết phần nhận xét sẽ rẻ hơn và dễ kiểm soát hơn một agent tự do. Ví dụ cuối đáng chú ý nhất: rất nhiều nhu cầu được mô tả là cần agent thực ra chỉ cần một workflow ổn định. Tự chủ chỉ đáng trả giá khi bạn không thể viết trước đường đi. ## Rủi ro khi gắn nhãn agent cho một chatbot có plugin Gọi sai tên gây ra ba loại thiệt hại cụ thể. - **Kỳ vọng sai:** Team tin rằng hệ thống sẽ tự làm xong việc nên bỏ bớt người kiểm tra, trong khi hệ thống thực chất vẫn cần người nhập tiếp ở mỗi bước. - **Chi phí và độ trễ tăng:** Thêm vòng lặp và tool call nghĩa là thêm token, thêm thời gian chờ, và thêm sai số tích lũy qua các bước. - **Hành động sai có hậu quả thật:** Một tool ghi dữ liệu được gọi nhầm sẽ để lại dấu vết trong hệ thống, không chỉ trong đoạn chat. Điểm cần nhớ về kiểm soát: prompt có thể định hướng hành vi, nhưng guardrail phải có khả năng chặn hành vi. Một dòng chữ dặn model đừng hoàn tiền quá một mức nào đó không phải là biện pháp kiểm soát; giới hạn phải nằm ở lớp tool, ở phân quyền và ở hàng đợi phê duyệt. Với hành động khó hoàn tác, human-in-the-loop (có người duyệt trong vòng lặp) vẫn là thiết kế mặc định hợp lý. Microsoft mô tả cổng duyệt có thể gắn vào đúng lần gọi tool nhạy cảm, thay vì bắt mọi bước phải chờ người. Cũng nên tỉnh táo với ngôn ngữ tiếp thị. Từ agent hiện được dùng rất rộng, từ một tính năng tự động hóa nhỏ tới một hệ thống nhiều bước có quyền ghi. Cách kiểm tra nhanh là hỏi nhà cung cấp ba câu: hệ thống được gọi những tool nào, nó lưu state ở đâu, và nó dừng theo điều kiện gì. Bài viết này không chứa liên kết tiếp thị và không giới thiệu sản phẩm trả phí nào. ## Câu hỏi thường gặp Bốn câu dưới đây là chỗ hay bị dán nhãn sai. Mỗi câu trả lời theo cơ chế thật (tool, memory, quyền hành động), không theo tên sản phẩm trên UI. ### ChatGPT có phải AI Agent không? Tùy cách dùng. Khi bạn hỏi và nhận lại văn bản, đó là chatbot. Khi phiên làm việc cho phép model gọi tool, đọc kết quả trả về và lặp thêm bước hướng tới một mục tiêu, phần đó vận hành theo cơ chế agent. Nhãn trên sản phẩm không quyết định; cơ chế bên dưới mới quyết định. ### Chatbot gắn thêm tool đã là agent chưa? Chưa chắc. Theo IBM, khả năng gọi tool tự nó không biến một LLM thành agent. Điều kiện còn thiếu là hệ thống tự chọn tool nào, gọi khi nào, kết hợp ra sao, và theo đuổi mục tiêu qua nhiều bước thay vì chờ người dùng ra lệnh từng lượt. ### Agent có tự học và tự cải thiện theo thời gian không? Không theo nghĩa model tự giỏi lên. Agent có thể nhớ kết quả và điều chỉnh cách làm dựa trên memory, nhưng model nền không được huấn luyện lại liên tục từ các cuộc hội thoại. Cải thiện thật sự thường đến từ việc bạn sửa prompt, sửa tool, sửa dữ liệu và sửa quy trình, rồi đo lại. ### Có cần nhiều agent ngay từ đầu không? Thường là không. Microsoft khuyến nghị chỉ chuyển sang nhiều agent khi một agent có tool không còn xử lý đáng tin cậy. Một agent với bộ tool gọn dễ debug, dễ giới hạn và dễ giải thích hơn nhiều so với một hệ thống nhiều agent trao đổi qua lại. Vì sao thêm agent chưa chắc thông minh hơn nằm ở bài [Multi-Agent Orchestration là gì](/ai/multi-agent-orchestration-la-gi). ## Kết luận: chọn theo việc hệ thống được phép làm Cách phân loại gọn nhất là bỏ qua giao diện và hỏi ba câu: hệ thống có gọi được tool thật không, nó giữ state ở đâu ngoài context window, và nó được phép tạo ra thay đổi nào mà không cần người bấm nút. Trả lời không cho cả ba thì bạn đang có chatbot, và trong nhiều trường hợp như vậy là đủ. Trả lời có cho cả ba thì bạn đang có một hệ thống phần mềm có quyền hành động, cần được thiết kế và vận hành như phần mềm. Nếu use case của bạn đã rơi vào nhóm thứ hai, bước tiếp theo không phải chọn framework mà là dựng lớp bọc quanh model. Bài [Harness Engineering là gì](/ai/harness-engineering-la-gi) tách lớp hành vi đó: tool, nhớ tiến độ, vòng lặp, kiểm tra và điểm dừng. Phần hạ tầng dùng chung, nơi giữ state, quyền, cổng phê duyệt và truy vết, nằm trong bài [Vì sao AI Agent cần một platform, không chỉ một prompt](/ai/vi-sao-ai-agent-can-platform-thay-vi-prompt). Nếu bạn muốn xem một ví dụ kiến trúc cụ thể về cách tách prompt, tool, memory và tracing thành các lớp riêng, [GoClaw](/ai/goclaw-la-gi) là một tham chiếu mã nguồn mở để đọc, không phải một stack cần bê nguyên.ai-agentchatbottool-callingmemoryllmnguyennlthttps://nguyennlt.com/ai/goclaw-la-gi/https://nguyennlt.com/ai/goclaw-la-gi/GoClaw cung cấp runtime, multi-tenancy, tool, memory và tracing cho AI Agent. Nhưng dưới góc Platform Engineering, team vẫn phải tự vận hành những gì?Mon, 10 Aug 2026 22:07:39 GMT> **Trả lời nhanh:** GoClaw là một gateway kiêm runtime tự host để chạy AI Agent theo một pipeline chung, với multi-tenancy, tool, memory, tracing, quota và các control bảo mật cấu hình được. Dưới góc Platform Engineering, nó phù hợp nhất ở **execution plane**. Nó không thay thế toàn bộ Internal Developer Platform (nền tảng cho developer nội bộ), vì identity của tổ chức, secret lifecycle, CI/CD, policy, SLO, eval trước release và quy trình vận hành vẫn cần platform team sở hữu. Khi mình đọc tài liệu GoClaw, câu hỏi không nằm ở runtime có API hay không. Câu hỏi nằm ở chỗ nghe như một AI Agent Platform hoàn chỉnh, nên dễ tưởng mua một runtime là đã có Internal Developer Platform. Nói ngắn, đó là nền tảng ghép sẵn để developer nội bộ tự triển khai và vận hành: CI/CD, identity, secret, môi trường, chứ không phải một phần mềm mua về là xong. Giống mua một cái bếp rồi khoe đã mở nhà hàng. Nấu được. Chưa có thu ngân, giấy phép, hay người trực khi cháy chảo lúc 2 giờ sáng. Runtime này chạy được agent, nhận request, gọi tool và ghi trace. Phần còn lại của nền tảng vẫn phải tự lo. Mình nhìn GoClaw bằng góc Platform Engineering, để bạn biết nó đứng ở lớp nào trước khi đánh giá hay triển khai. _Lưu ý minh bạch: nội dung dưới đây được đối chiếu với tài liệu và mã nguồn công khai của GoClaw vào ngày 11/08/2026. Đây không phải benchmark production độc lập, cũng không phải báo cáo trải nghiệm vận hành thực tế. Những gì tài liệu khẳng định sẽ được ghi là "theo tài liệu"; những gì là suy luận kiến trúc sẽ được ghi rõ là phân tích._  _GoClaw nên được nhìn như một execution gateway nằm trong hệ thống platform lớn hơn, không phải toàn bộ platform._ ## Đang nói về GoClaw nào? Tên "GoClaw" bị trùng giữa vài dự án không liên quan. Trước khi đọc tiếp, hãy chắc bạn đang nhìn đúng thứ: - **Bài này nói về** [`nextlevelbuilder/goclaw`](https://github.com/nextlevelbuilder/goclaw) trên GitHub. Site sản phẩm là [goclaw.sh](https://goclaw.sh); tài liệu đầy đủ nằm ở [docs.goclaw.sh](https://docs.goclaw.sh). - **Không phải** [goclaw.org](https://goclaw.org/), một runtime agent cá nhân khác — site đó mô tả khả năng chạy độc lập hoặc cạnh [OpenClaw](https://goclaw.org/docs/readme/). Docs, lệnh và mô hình vận hành của hai bên không thay thế cho nhau. - Ngoài ra còn có ít nhất một repo cá nhân và một ứng dụng iOS trùng tên. Theo [README chính thức](https://github.com/nextlevelbuilder/goclaw), repo này tự mô tả là Multi-Tenant AI Agent Platform và multi-agent AI gateway built in Go. Nó chạy dưới dạng một binary, đứng giữa ứng dụng của bạn và các nhà cung cấp LLM, nhận request từ nhiều kênh, chạy một pipeline chuẩn hóa, gọi tool, lưu trạng thái hội thoại và ghi trace. Nghe nhỏ nhặt, nhưng trong thực tế đây là nguồn lỗi phổ biến: một kỹ sư copy lệnh cài đặt từ kết quả tìm kiếm của dự án khác rồi kết luận sai về khả năng của sản phẩm. Khi đánh giá, hãy chốt đúng URL repo và đúng nhánh trước khi làm bất cứ điều gì. Về độ mới, snapshot repo ngày 11/08/2026 cho thấy dự án được tạo tháng 02/2026; [stable tag gần nhất là v3.14.0](https://github.com/nextlevelbuilder/goclaw/releases/tag/v3.14.0), phát hành ngày 15/06/2026, trong khi dòng prerelease đã mang version v3.15.0-beta và commit mới nhất của repo là ngày 09/08/2026. Tuy nhiên, lịch sử `main` và `dev` đã diverge, nên không thể chỉ nhìn tên branch rồi mặc định một bên chứa toàn bộ thay đổi của bên kia. Khi đánh giá, hãy pin một tag hoặc commit SHA cụ thể — một artifact bất biến, không phải một branch tiếp tục thay đổi. ## Vì sao nên nhìn GoClaw bằng lăng kính Platform Engineering? Platform Engineering là kỷ luật thiết kế và vận hành các toolchain, workflow cho phép developer tự phục vụ (self-service), nhằm giảm cognitive load — tức lượng thứ một kỹ sư phải nhớ và tự lo để đưa được code lên production. Theo [định nghĩa của PlatformEngineering.org](https://platformengineering.org/blog/what-is-platform-engineering), điểm cốt lõi là _platform-as-a-product_: platform team đối xử với developer nội bộ như khách hàng, và cung cấp **paved road** (còn gọi là golden path) — con đường mặc định đã được lát sẵn, có sẵn best practice, để đi nhanh mà vẫn an toàn. [CNCF phân biệt rất rõ](https://www.cncf.io/blog/2023/12/08/internal-developer-platform-vs-internal-developer-portal-vs-paas/) giữa Internal Developer Platform (IDP), portal và PaaS: IDP là _tổng hợp_ các tool và workflow mà platform team ghép lại thành trải nghiệm self-service, chứ không phải một sản phẩm đơn lẻ mua về. Và golden path phải là _đường lát sẵn, không phải cái lồng_ — developer vẫn phải thoát ra được khi có nhu cầu chính đáng. Với AI Agent, khung tư duy này vẫn đúng, chỉ thêm vài concern mới. Một [bài member post của CNCF về Platform Engineering cho agentic enterprise](https://www.cncf.io/blog/2026/07/21/platform-engineering-for-the-agentic-enterprise-managing-applications-resources-and-ai-agents/) lập luận rằng platform dùng chung cho agent cần workflow có quan điểm rõ ràng (opinionated), self-service, môi trường chuẩn hóa và thực hành vận hành đi kèm. Đây là góc framing hữu ích, dù nó không nói gì về GoClaw cụ thể. Từ đó có một câu hỏi thực dụng, và đó cũng là câu hỏi của bài này: > Nếu team bạn cần một paved road để chạy AI Agent, GoClaw lấp được bao nhiêu phần của con đường đó, và bạn còn phải tự lát bao nhiêu mét nữa? Câu trả lời không nằm ở chỗ sản phẩm tự gọi mình là gì. Nó nằm ở chỗ ai chịu trách nhiệm khi có sự cố lúc 2 giờ sáng. ## GoClaw nằm ở đâu trong agent stack? Điểm phân biệt quan trọng nhất: **GoClaw không phải một SDK bạn import vào code, mà là một service bạn triển khai và vận hành.** Bạn gọi nó qua API hoặc qua các kênh nhắn tin nó hỗ trợ, thay vì nhúng thư viện vào ứng dụng. Theo tài liệu [How GoClaw Works](https://github.com/nextlevelbuilder/goclaw-docs/blob/793758b5ed50df2b72459f58f8187576f869e32d/core-concepts/how-goclaw-works.md), luồng cơ bản là: gateway nhận request → định tuyến tới agent phù hợp → gọi LLM provider → thực thi tool nếu model yêu cầu → trả response. Bên trong là một pipeline nhiều giai đoạn, đại ý gồm dựng context, suy luận, cắt tỉa context, gọi tool, quan sát kết quả, kiểm tra điều kiện dừng rồi kết thúc.  _Trong agent stack, GoClaw chuẩn hóa đường thực thi từ input tới model, tool và state._ Vài chi tiết đáng chú ý về mặt vận hành, cũng theo tài liệu này: - Mỗi session có một hàng đợi riêng, tức các request trong cùng một hội thoại được xử lý tuần tự. - Scheduler chia làn (lane) riêng cho main agent, subagent, team và cron job. - Tool chỉ đọc có thể chạy song song trong giới hạn; còn tool có tác dụng thay đổi dữ liệu, tool MCP và tool thực thi lệnh thì chạy tuần tự. Đây là những quyết định thiết kế có ý nghĩa thật với người vận hành: chúng ràng buộc mô hình concurrency và ảnh hưởng trực tiếp tới hành vi dưới tải. Nếu bạn chưa quen với lớp bọc quanh model, [Harness Engineering là gì](/ai/harness-engineering-la-gi) tách harness khỏi việc chọn model. Cách phân tầng prompt / harness / runtime và vì sao agent nghiêm túc cần hạ tầng chứ không chỉ prompt tốt nằm trong bài [vì sao AI Agent cần một platform, không chỉ một prompt](/ai/vi-sao-ai-agent-can-platform-thay-vi-prompt). Ở đây, ta chỉ cần một kết luận từ đó: prompt là _nội dung_, runtime là _nơi nội dung được thực thi có kiểm soát_. GoClaw thuộc về vế thứ hai. ## Platform scorecard: GoClaw đã giải quyết sẵn những gì? Phần này chấm theo từng năng lực platform. Mỗi mục nêu cả lợi ích lẫn giới hạn — vì giới hạn mới là thứ quyết định bạn còn phải làm gì.  _Năm nhóm năng lực đều cần được đọc cùng giới hạn vận hành của chúng, không phải như một bảng điểm._ ### Self-service surface GoClaw có dashboard và API để tạo, cấu hình agent, và theo README nó kết nối được với nhiều kênh nhắn tin phổ biến. Với một product team, đây là self-service thật: người không viết code hạ tầng vẫn dựng được agent và đưa nó tới người dùng. **Giới hạn:** đây là self-service ở tầng _người vận hành agent_, không phải self-service xuyên suốt vòng đời phát triển. Việc cấp môi trường mới, gắn agent vào pipeline CI/CD, quản lý cấu hình theo môi trường (dev/staging/prod), phân quyền ai được sửa agent nào ở môi trường nào — tài liệu không mô tả GoClaw đảm nhận những phần này. Nói cách khác, nó cho bạn một control surface, không cho bạn một developer platform hoàn chỉnh. ### Runtime và orchestration chuẩn hóa Đây là giá trị mạnh nhất và cũng đúng nghĩa "paved road" nhất. Pipeline chung, hàng đợi theo session, scheduler chia làn, cơ chế giới hạn vòng lặp — tất cả nghĩa là mọi agent trong hệ thống chạy theo cùng một mô hình thực thi. Không còn chuyện mỗi team tự viết một vòng lặp agent với một cách xử lý lỗi khác nhau. Theo README, GoClaw còn hỗ trợ team/orchestration nhiều agent và subagent, tức bạn có thể mô hình hóa các workflow phức tạp hơn một agent đơn lẻ. Thêm agent chưa tự thành hệ thống thông minh hơn; ranh giới đó nằm ở bài [Multi-Agent Orchestration là gì](/ai/multi-agent-orchestration-la-gi). **Giới hạn:** pipeline có thể mở rộng nhưng vẫn đưa ra một mô hình thực thi có chủ kiến. Nếu use case của bạn cần một control flow khác hẳn — ví dụ một graph có điều kiện rẽ nhánh phức tạp, hoặc human-in-the-loop ở giữa chuỗi tool — bạn cần kiểm chứng xem hook, quality gate và orchestration mode của GoClaw có diễn đạt được không trước khi cam kết. Golden path chỉ hữu ích khi nó không biến thành cái lồng. ### Providers, tools, MCP, state và memory dùng chung GoClaw gom sẵn một tập lớn LLM provider, một tập tool tích hợp sẵn, hỗ trợ MCP (Model Context Protocol — chuẩn mở để agent kết nối tới nguồn dữ liệu và công cụ bên ngoài), một mô hình memory nhiều tầng và một knowledge vault. Trạng thái lưu trên PostgreSQL ở bản Standard. Đây chính là thứ tiết kiệm nhiều công sức: bạn không phải tự viết lớp trừu tượng provider, không phải tự thiết kế schema lưu hội thoại, không phải tự làm cơ chế cắt tỉa context. **Một lưu ý về con số:** số lượng provider và tool được ghi _khác nhau_ giữa các trang tài liệu chính thức. Tính đến 11/08/2026, [trang What Is GoClaw](https://github.com/nextlevelbuilder/goclaw-docs/blob/793758b5ed50df2b72459f58f8187576f869e32d/getting-started/what-is-goclaw.md) ghi một con số, README ghi con số khác, và trang How It Works ghi con số thứ ba. Vì vậy tốt nhất đừng coi bất kỳ con số cụ thể nào là sự thật ổn định — hãy đọc trực tiếp danh sách trong mã nguồn ở phiên bản bạn định dùng, và chỉ tính những provider/tool bạn thực sự cần. **Giới hạn:** có sẵn tool không đồng nghĩa với có sẵn mô hình quản trị phù hợp với tổ chức của bạn. Ai được bật tool nào, tool nào được phép thay đổi dữ liệu ở production, hành động nào cần phê duyệt — đó vẫn là câu hỏi policy mà tổ chức bạn phải trả lời và cấu hình. ### Isolation theo tenant và các control bảo mật cấu hình được [Tài liệu multi-tenancy](https://github.com/nextlevelbuilder/goclaw-docs/blob/793758b5ed50df2b72459f58f8187576f869e32d/core-concepts/multi-tenancy.md) mô tả hai chế độ dùng chung một binary: Personal và SaaS. Ở chế độ SaaS, tenant được xác định từ API key gắn với tenant, và mọi truy vấn SQL đều gắn điều kiện lọc theo `tenant_id` ở tầng ứng dụng, với thiết kế fail-closed theo tài liệu. Điểm cực kỳ quan trọng, và tài liệu nói thẳng: **ứng dụng của bạn vẫn sở hữu authentication, billing và UI.** Danh tính người dùng cuối được truyền vào qua header `X-GoClaw-User-Id`; GoClaw không tự xác thực end user. Nghĩa là ranh giới bảo mật đầu tiên vẫn nằm ở phía bạn — nếu ứng dụng của bạn truyền sai user id, GoClaw nhận chính identity đó làm ngữ cảnh. Về mặt bảo mật, [tài liệu security hardening](https://github.com/nextlevelbuilder/goclaw-docs/blob/793758b5ed50df2b72459f58f8187576f869e32d/deployment/security-hardening.md) mô tả năm lớp: transport, input, tools, output và isolation. Nhưng cần đọc kỹ giá trị mặc định: - Hành động khi phát hiện prompt injection mặc định là _cảnh báo_, không chặn. - Gateway token để trống sẽ cấp quyền admin — tài liệu nói rõ đây chỉ dành cho phát triển local. - Danh sách CORS để trống nghĩa là cho phép tất cả origin, nhằm tương thích ngược. - Rate limit có thể tắt. - Sandbox cho từng agent là tùy chỉnh được. Cách đọc đúng: đây là một bộ _control có thể cấu hình_, không phải một đảm bảo an toàn mặc định. Nếu bạn triển khai với cấu hình mặc định rồi coi như đã được bảo vệ, bạn đã hiểu sai tài liệu.  _Control chỉ trở thành hàng rào production sau khi team chủ động cấu hình và kiểm chứng._ ### Trace và telemetry [Tài liệu observability](https://github.com/nextlevelbuilder/goclaw-docs/blob/793758b5ed50df2b72459f58f8187576f869e32d/deployment/observability.md) cho biết GoClaw có tracing tích hợp sẵn cho mỗi lượt chạy agent, với span riêng cho lời gọi LLM và tool, kèm thông tin token, thời lượng, trạng thái, và một dashboard đọc dữ liệu từ PostgreSQL. Có tùy chọn xuất OTLP nếu build với build tag `otel` — tức muốn đẩy trace sang hệ thống quan sát chung của công ty, bạn phải build đúng cách chứ không chỉ bật config. Tài liệu cũng cảnh báo chế độ trace chi tiết có thể lưu toàn bộ input/output, và khuyến nghị chỉ dùng ở môi trường phát triển. Đây là một cảnh báo về quyền riêng tư dữ liệu cần được xử lý nghiêm túc trước khi bật ở production. **Giới hạn:** có telemetry chưa phải có observability như một mô hình vận hành. Trace cho bạn _dữ liệu_; SLO, ngưỡng cảnh báo, chính sách lưu trữ, quy trình on-call và incident review vẫn là thứ team phải xây. ## Platform team vẫn phải sở hữu những gì? Bảng dưới đây là phần thực dụng nhất của bài. Cột giữa là những gì tài liệu mô tả GoClaw cung cấp; cột phải là phần trách nhiệm không chuyển giao được. Lưu ý cách diễn đạt: "tài liệu không mô tả" khác với "sản phẩm thiếu" — nhiều mục dưới đây vốn dĩ _không phải_ việc của một execution runtime.  _GoClaw nằm trong execution plane; quyền sở hữu control plane vẫn thuộc về platform team._ | Concern | GoClaw cho sẵn | Team còn phải làm | | --------------------- | -------------------------------------------- | ----------------------------------------------- | | Identity & auth | Tenant-bound API key, RBAC, nhận user id | Xác thực end user, IAM/SSO, ánh xạ vai trò | | Secrets & tool policy | Mã hóa provider key, tool controls, approval | Vault, luân chuyển key, policy theo môi trường | | Deploy & rollback | Binary/container, lệnh cập nhật | CI/CD, pin version, version cấu hình, rollback | | Capacity & cost | Usage analytics, quota, cost tracking, cap | Bảng giá, ngân sách tổ chức, alert, chargeback | | Backup & DR | PostgreSQL, backup/restore và tenant backup | Lịch chạy, off-site, RPO/RTO, restore drill | | SLO & incident | Trace, span, dashboard, OTLP tùy chọn | Alert, on-call, runbook, postmortem | | Eval & quality | Hook, evaluate loop, quality gate trong run | Regression suite và gate trước release | | Developer experience | Dashboard, API, docs | Template, hướng dẫn nội bộ, hỗ trợ, đo mức dùng | Hai hàng đáng chú ý nhất là **eval** và **cost governance**. GoClaw có hook, evaluate loop và quality gate để kiểm soát output trong một lượt chạy. Tuy nhiên, tài liệu công khai chưa cho thấy một vòng đời regression evaluation hoàn chỉnh: tập test có phiên bản, chạy lại khi đổi model/prompt/tool, so sánh kết quả và chặn release. Với hệ thống dựa trên LLM, phần này không phải chuyện tùy chọn: thay một model, sửa một prompt, hoặc chính provider cập nhật model đều có thể làm chất lượng thay đổi mà không có lỗi kỹ thuật nào được ném ra. Về cost governance, GoClaw đã đi xa hơn việc chỉ ghi token. [Usage & Quota](https://github.com/nextlevelbuilder/goclaw-docs/blob/793758b5ed50df2b72459f58f8187576f869e32d/advanced/usage-quota.md) mô tả quota request theo user, group, channel và provider; request bị chặn trước khi agent chạy khi vượt hạn mức. [Cost Tracking](https://github.com/nextlevelbuilder/goclaw-docs/blob/793758b5ed50df2b72459f58f8187576f869e32d/advanced/cost-tracking.md) mô tả cost analytics và ngân sách tháng theo agent, có thể chặn lượt chạy khi vượt ngưỡng. Nhưng những control này không xóa trách nhiệm của platform team. Cost chỉ chính xác khi bảng giá model được cấu hình và cập nhật đúng; tổ chức vẫn phải định nghĩa ngân sách dùng chung, cảnh báo cho người chịu trách nhiệm, chargeback/showback, ngoại lệ và quy trình xử lý khi cap bị chạm. Với agent tự gọi tool nhiều vòng, một thay đổi nhỏ vẫn có thể làm chi phí tăng mạnh trước khi policy phù hợp được thiết lập. Backup cũng không bắt đầu từ con số không: [CLI của GoClaw](https://github.com/nextlevelbuilder/goclaw-docs/blob/793758b5ed50df2b72459f58f8187576f869e32d/reference/cli-commands.md) có lệnh backup/restore toàn hệ thống và theo tenant. Phần team phải sở hữu là biến các primitive đó thành chiến lược production: lịch chạy, mã hóa, lưu off-site, retention, RPO/RTO và restore drill định kỳ. ## Một reference architecture thực tế Cách gọn nhất để định vị GoClaw là chia hệ thống thành bốn lớp:  _Reference architecture đặt GoClaw đúng vào lớp execution, giữa control plane và các dependency hạ tầng._ **Lớp 1 — Product teams và interfaces.** Ứng dụng web, mobile, các kênh nhắn tin, các dịch vụ nội bộ gọi agent. Lớp này sở hữu trải nghiệm người dùng, xác thực end user và logic nghiệp vụ. **Lớp 2 — Platform control plane.** CI/CD, quản lý cấu hình và phiên bản, IAM, secret management, policy engine, cấp phát môi trường, giám sát và cảnh báo, quản lý ngân sách. Đây là nơi platform team đặt paved road của tổ chức. GoClaw _không_ chiếm chỗ của lớp này. **Lớp 3 — Execution plane.** GoClaw ngồi ở đây: nhận request, định tuyến, chạy pipeline, gọi tool, giữ state theo session và tenant, sinh trace. Đây là nơi nó mạnh nhất và cũng là nơi nó nên được đánh giá. **Lớp 4 — Providers, tools, data và telemetry.** LLM provider, MCP server, hệ thống nội bộ mà tool truy cập, PostgreSQL, và backend quan sát nhận OTLP. Kết luận kiến trúc: **GoClaw là một component của lớp 3, không phải toàn bộ control plane.** Nếu bạn định dùng nó, hãy vẽ đúng lớp 2 của mình trước — vì đó là phần bạn phải tự xây dù chọn công cụ nào ở lớp 3. ## Khi nào GoClaw là lựa chọn hợp lý?  _GoClaw phù hợp theo điều kiện vận hành, không phải là lựa chọn mặc định cho mọi agent._ **Đáng cân nhắc pilot khi:** - Bạn cần chạy nhiều agent cho nhiều khách hàng hoặc nhiều nhóm, và ranh giới dữ liệu giữa họ là yêu cầu bắt buộc. - Bạn muốn tự host gateway, runtime và state để kiểm soát tốt hơn hạ tầng và vòng đời dữ liệu; nếu dùng LLM provider bên ngoài, payload gửi tới provider vẫn rời hạ tầng của bạn theo cấu hình đã chọn. - Bạn đã có sẵn PostgreSQL và năng lực vận hành nó. - Team bạn đang có nhiều triển khai agent rời rạc, mỗi cái một kiểu, và bạn muốn hợp nhất về một mô hình thực thi. - Bạn cần nhiều kênh nhắn tin mà không muốn viết integration cho từng kênh. - Sử dụng của bạn là phi thương mại, hoặc bạn sẵn sàng đi làm rõ vấn đề giấy phép (xem phần sau). **Có thể là lựa chọn sai khi:** - Bạn chỉ cần một agent duy nhất, đơn giản, gắn trong một ứng dụng — một thư viện gọn nhẹ sẽ ít chi phí vận hành hơn nhiều. - Bạn cần control flow rất đặc thù mà các hook và orchestration mode hiện có không diễn đạt được. - Bạn đang xây sản phẩm thương mại và chưa giải quyết được điều khoản giấy phép. - Team bạn không có ai sẵn sàng nhận vai trò vận hành một service stateful thêm nữa. - Bạn cần một sản phẩm có SLA thương mại và lộ trình ổn định đã được cam kết. ## Checklist đánh giá GoClaw trong một ngày Mục tiêu của checklist này là ra quyết định kiến trúc, **không phải triển khai production**. Toàn bộ nên chạy trong môi trường cô lập, với dữ liệu giả.  _Mười bước tạo thành một vòng đánh giá: từ license gate tới ownership gap trước khi quyết định pilot._ 1. **Kiểm tra giấy phép trước tiên.** Đọc [file LICENSE](https://github.com/nextlevelbuilder/goclaw/blob/main/LICENSE) và đối chiếu với mục đích sử dụng dự kiến của bạn. Nếu không hợp, dừng ở đây và tiết kiệm cả ngày. 2. **Chốt đúng repo và đúng nhánh.** Xác nhận bạn đang ở `nextlevelbuilder/goclaw`. Theo tài liệu quickstart, nhánh mặc định là nhánh phát triển còn nhánh ổn định là `main` — hãy đánh giá trên nhánh ổn định, không phải nhánh dev. 3. **Dựng môi trường cô lập.** Quickstart từ source yêu cầu Go khá mới (README ghi Go 1.26+ tính đến 11/08/2026). Với database, [tài liệu cài đặt](https://github.com/nextlevelbuilder/goclaw-docs/blob/master/getting-started/installation.md) ghi PostgreSQL 15+ kèm pgvector, trong khi README và Docker path thường nêu PostgreSQL 18. Kiểm tra đúng yêu cầu của bản bạn pin — riêng điều này đã có thể là yếu tố quyết định. 4. **Chạy một agent tối giản.** Một model, một tool chỉ đọc. Xác nhận vòng đời request hoạt động đúng như tài liệu mô tả. 5. **Kiểm thử ranh giới tenant và user.** Tạo hai tenant, gửi request chéo, và thử cố tình truyền sai user id qua header. Ghi lại chính xác hành vi quan sát được — đây là kiểm chứng quan trọng nhất nếu bạn làm multi-tenant. 6. **Thử một tool có tác dụng thay đổi dữ liệu.** Xem cơ chế phê duyệt, giới hạn và sandbox thực tế hoạt động ra sao, và bạn cấu hình được tới đâu. 7. **Bật trace và thử xuất OTLP.** Kiểm tra xem dữ liệu trace có đủ để chẩn đoán một lượt chạy hỏng không, và bạn cần build như thế nào để đẩy được sang hệ thống quan sát sẵn có. 8. **Mô phỏng lỗi và khởi động lại.** Ngắt service giữa một lượt chạy dài, khởi động lại, quan sát điều gì xảy ra với session đang dở và với hàng đợi. 9. **Thử backup và rollback.** Backup database, thay đổi cấu hình agent, rồi quay lại trạng thái cũ. Đo xem quy trình này mất bao lâu và có bao nhiêu bước thủ công. 10. **Viết ra danh sách ownership gap.** Dùng bảng ở phần trên làm khung: với mỗi hàng, ghi rõ ai trong tổ chức bạn sẽ sở hữu nó và bằng công cụ gì. Nếu có hàng nào không có tên người, đó là rủi ro chưa được nhận diện. ## Rủi ro cần đọc trước khi chọn  _Năm nhóm rủi ro cần due diligence trước khi đầu tư pilot hoặc production._ **Giấy phép là ràng buộc lớn nhất.** GoClaw dùng CC BY-NC 4.0 — yêu cầu ghi nhận tác giả và **không cấp phép sử dụng cho mục đích thương mại**. Vì vậy không nên mô tả nó bằng cụm "open source" một cách chung chung mà bỏ qua điều kiện này. Nếu bạn định dùng trong sản phẩm thương mại, hãy làm rõ với chủ dự án và bộ phận pháp lý của bạn trước khi đầu tư kỹ thuật. Đây không phải tư vấn pháp lý. **Dự án thay đổi nhanh và tài liệu chưa nhất quán.** Như đã nêu, số lượng provider và tool khác nhau giữa các trang chính thức tính đến 11/08/2026. Dòng prerelease mang version minor cao hơn stable, nhưng lịch sử `main` và `dev` đã diverge. Với hệ thống chạy production, điều này nghĩa là bạn cần pin tag hoặc commit SHA, đọc changelog cẩn thận và tự kiểm chứng thay vì tin vào tên branch hay con số trên trang giới thiệu. **Đã có lỗ hổng công khai ở các bản cũ, và không nên suy ra là đã vá xong.** [CVE-2026-10218](https://www.cve.org/CVERecord?id=CVE-2026-10218) mô tả lỗi phân quyền trên các bản 3.11.0–3.11.3, được dự án theo dõi tại [issue #1120](https://github.com/nextlevelbuilder/goclaw/issues/1120). [Release v3.14.0](https://github.com/nextlevelbuilder/goclaw/releases/tag/v3.14.0) có liệt kê một nhóm security fixes, nhưng changelog không nêu CVE này. Tính đến 24/06/2026, issue vẫn mở và maintainer ghi nhận endpoint evolution suggestion trên `dev` lúc đó vẫn thiếu cổng tenant-admin. Vì vậy: pin bản đã chọn, đối chiếu advisory với đúng commit, rồi tự threat model — đừng coi tên version mới hơn là bằng chứng đã vá. **Bảo mật là kết quả của cấu hình, không phải mặc định.** Một số giá trị mặc định thiên về dễ khởi động và tương thích ngược. Toàn bộ phần hardening phải được coi là việc bắt buộc trước khi tiếp xúc dữ liệu thật, không phải việc để dành. **Chưa có benchmark độc lập trong mẫu kết quả đã kiểm tra.** Các con số về hiệu năng, mức tiêu thụ tài nguyên và tiết kiệm chi phí xuất hiện trong tài liệu là claim của nhà phát triển. Trong các trang đã kiểm tra ngày 11/08/2026, chưa có benchmark production độc lập đủ phương pháp để xác nhận. Điều đó không khẳng định các con số sai, nhưng cũng không nên dùng chúng làm cơ sở duy nhất cho một quyết định kiến trúc. Nếu hiệu năng quan trọng với bạn, hãy tự đo trên workload của mình. ## Câu hỏi thường gặp Những câu này lặp lại ranh giới đã nêu ở trên, vì đó là chỗ quyết định hay bị kéo lệch. Trả lời ngắn theo đúng lớp: GoClaw là runtime, không phải cả platform. ### GoClaw có phải là Internal Developer Platform không? Không, theo cách CNCF định nghĩa IDP. GoClaw là một execution runtime cho agent — một component có thể trở thành paved road trong IDP của bạn. IDP là tổng hợp của nhiều tool và workflow do platform team ghép lại, bao gồm CI/CD, IAM, secrets, policy, môi trường và giám sát. GoClaw không thay thế những phần đó. ### GoClaw có thay thế LangGraph hay n8n không? Chúng giải quyết những vấn đề khác nhau và không nằm cùng một lớp. Về mặt hình thái, GoClaw là một service tự host với runtime, multi-tenancy và tracing tích hợp — bạn triển khai và vận hành nó. Một thư viện orchestration thì được import vào ứng dụng của bạn và để bạn tự lo hạ tầng. Câu hỏi đúng không phải "cái nào tốt hơn" mà là "tôi muốn sở hữu lớp runtime hay muốn nó có sẵn". Việc so sánh chi tiết nên dựa trên use case cụ thể của bạn, không dựa trên bảng tính năng. ### Khác nhau giữa bản Lite và Standard là gì? Theo README, bản Lite dùng SQLite và bị giới hạn — trong đó có giới hạn số agent và số team, đồng thời không có đầy đủ các kênh, knowledge graph, RBAC và mô hình multi-tenant như bản Standard. Bản Standard dùng PostgreSQL và là bản có đủ năng lực multi-tenancy. Thực tế: Lite phù hợp để thử và cho use case cá nhân; nếu bạn quan tâm tới góc platform trong bài này, bạn đang nói về Standard. ### Tôi có dùng GoClaw cho sản phẩm thương mại được không? Giấy phép CC BY-NC 4.0 không cấp quyền sử dụng thương mại. Nếu đó là ý định của bạn, hãy liên hệ chủ dự án để hỏi về điều khoản riêng và xác nhận với bộ phận pháp lý. Đừng suy diễn từ việc mã nguồn công khai — công khai không đồng nghĩa với được phép dùng thương mại. ### Có cần Kubernetes để chạy GoClaw không? Không bắt buộc. Theo README, GoClaw là một binary duy nhất, nên nó chạy được trên VPS thường, trong container, hoặc trên orchestrator tùy hạ tầng của bạn. Câu hỏi thực sự không phải là Kubernetes, mà là: ai vận hành PostgreSQL, ai lo backup, ai nhận cảnh báo khi service chết. Trả lời được ba câu đó thì cách đóng gói chỉ còn là chi tiết triển khai. ## Quyết định thế nào Quy tắc quyết định gọn nhất: **Chọn GoClaw nếu vấn đề lớn nhất của bạn nằm ở lớp execution** — nhiều agent, nhiều tenant, nhiều kênh, và bạn muốn thống nhất chúng về một runtime thay vì để mỗi team tự viết. Đó là chỗ nó tạo ra giá trị rõ ràng nhất. **Đừng chọn nó như một cách để né việc xây platform.** Nếu vấn đề lớn nhất của bạn là không ai sở hữu identity, secrets, deployment, eval và chi phí, thì thêm một service nữa vào hệ thống sẽ làm vấn đề đó nặng hơn chứ không nhẹ đi. Bước tiếp theo cụ thể: dành nửa ngày làm ba việc theo đúng thứ tự — (1) kiểm tra giấy phép so với mục đích sử dụng của bạn, (2) chạy bước 5 trong checklist trên, tức kiểm thử ranh giới tenant, và (3) điền tên người sở hữu vào từng hàng của bảng ownership. Nếu cả ba đều cho kết quả chấp nhận được, hãy chạy pilot đầy đủ. Nếu bước 1 hoặc bước 3 tắc, kết quả kỹ thuật của bước 2 không cứu được quyết định. Các bài khác về chủ đề ứng dụng AI trong thực tế nằm ở [chuyên mục AI](/ai).goclawai-agentplatform-engineeringagent-platformself-hostednguyennlthttps://nguyennlt.com/ai/vi-sao-ai-agent-can-platform-thay-vi-prompt/https://nguyennlt.com/ai/vi-sao-ai-agent-can-platform-thay-vi-prompt/Prompt hướng dẫn AI Agent. Platform giúp agent dùng công cụ, giữ trạng thái, kiểm soát rủi ro, đo chất lượng và phục hồi khi lỗi.Tue, 04 Aug 2026 04:44:08 GMT> **Trả lời nhanh:** Prompt quyết định agent nghĩ gì. Platform quyết định agent làm được gì, đi được bao xa, và chuyện gì xảy ra khi nó làm sai. Prompt đủ khi tác vụ một lượt, chỉ đọc, có người duyệt. Cần runtime khi agent phải giữ state, gọi tool có rủi ro, hoặc phục hồi sau lỗi. Khi mình nhìn một agent hoàn tiền chạy ngoài production, chỗ hỏng hiếm khi nằm ở câu chữ trong prompt. Nó quên đã xác minh đơn, gọi API lần hai, hoặc không giải thích được vì sao hoàn sai. Vậy khi nào prompt còn đủ, khi nào nên dùng workflow tất định, và khi nào thật sự cần runtime? Mình tách từng kiểu hỏng của ca hoàn tiền ra đúng lớp hệ thống ngay dưới đây.  _Prompt quyết định agent nghĩ gì. Platform quyết định agent làm được gì, đi được bao xa, và chuyện gì xảy ra khi nó làm sai._ ## Khi nào prompt là đủ? Prompt thường là đủ khi tác vụ nằm gọn trong một lần suy luận và kết quả chưa trực tiếp tạo tác động ra bên ngoài. Cụ thể hơn, prompt đơn thuần thường phù hợp khi: - Đầu vào đã được cung cấp sẵn, agent không phải tự đi tìm dữ liệu. - Tác vụ kết thúc trong một hoặc hai lượt, không cần nhớ gì qua lần chạy sau. - Không có hành động ghi dữ liệu, gửi thông tin ra ngoài hay chuyển tiền. - Luôn có người đọc và duyệt kết quả trước khi dùng. Tóm tắt tài liệu, phân loại phản hồi khách hàng, viết bản nháp email, gợi ý tiêu đề: đây là địa hạt của prompt. Với các tác vụ này, lớp vận hành phức tạp thường chưa mang lại lợi ích tương xứng với chi phí. Có một lựa chọn trung gian hay bị bỏ qua: workflow tất định. Anthropic phân biệt rõ hai thứ trong [bài viết về xây dựng agent hiệu quả](https://www.anthropic.com/engineering/building-effective-agents): workflow là hệ thống trong đó LLM (Large Language Model) và tool được điều phối theo các đường dẫn đã được code định sẵn, còn agent là hệ thống trong đó LLM tự định hướng quá trình và cách sử dụng tool. Anthropic khuyến nghị bắt đầu từ giải pháp đơn giản nhất và chỉ tăng độ phức tạp khi kết quả thực sự tốt hơn, vì hệ thống agentic đánh đổi độ trễ và chi phí để lấy hiệu quả trên tác vụ khó. Nếu đường đi từ input đến output đã biết trước, và business rule biểu diễn được bằng code, thì một workflow tất định gọi LLM ở vài điểm sẽ dễ kiểm chứng hơn một agent tự lập kế hoạch. Anthropic cũng mô tả khối xây dựng cơ bản là **augmented LLM**: model được bổ sung khả năng truy xuất, sử dụng tool và ghi nhớ. Đó là điểm xuất phát tự nhiên trước khi nghĩ tới bất cứ kiến trúc nào phức tạp hơn. Microsoft mô tả cùng một ý dưới dạng nấc thang trong [tài liệu về design pattern cho AI agent](https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/ai-agent-design-patterns): đi từ gọi model trực tiếp, lên single agent, rồi mới tới multi-agent. Mỗi nấc chỉ nên leo khi nấc dưới không còn đáp ứng được.  _Bắt đầu từ lựa chọn đơn giản nhất. Prompt khi tác vụ một lượt. Workflow khi đường đi đã biết. Agent khi model phải tự định hướng tool._ ## Sáu dấu hiệu bạn đã vượt khỏi phạm vi của prompt Hãy đưa agent hoàn tiền vào vận hành thật. Nhiệm vụ mô tả trong prompt nghe rất gọn: kiểm tra đơn hàng, đối chiếu chính sách, xác nhận lý do với khách, hoàn tiền nếu đủ điều kiện. Ngoài production, cùng nhiệm vụ ấy trở thành một chuỗi hành động: xác thực người yêu cầu, lấy đơn hàng, tra đúng phiên bản chính sách, kiểm tra giao dịch đã từng hoàn chưa, tính số tiền, xin phê duyệt nếu vượt ngưỡng, gọi API (Application Programming Interface) thanh toán, ghi nhận kết quả, thông báo cho khách, và xử lý khi một bước bất kỳ thất bại. Sáu dấu hiệu dưới đây cho biết bạn đã bước ra khỏi vùng mà prompt còn giải quyết được. Mỗi dấu hiệu đi kèm lớp hệ thống chịu trách nhiệm, và phần sau của bài sẽ mở từng lớp ra. | Kiểu hỏng cụ thể trong ca hoàn tiền | Lớp hệ thống cần bổ sung | | --- | --- | | Tiến trình restart giữa chừng, agent quên đã xác minh đơn hàng và hoàn tiền lần thứ hai | Trạng thái bền vững và khóa chống trùng | | Agent gọi API thanh toán bằng credential của một nhân viên khác, hoặc gọi tool nó không được phép dùng | Danh tính và quyền ở lớp tool | | Agent lặp vô hạn giữa tra chính sách và hỏi lại khách, đốt token không giới hạn | Orchestration có giới hạn | | Agent tự quyết hoàn một khoản vượt ngưỡng vì khách hàng gây áp lực trong hội thoại | Nhiều lớp chặn hành vi và phê duyệt của người | | Khách khiếu nại, team chỉ có câu trả lời cuối, không biết agent đã đọc gì và gọi gì | Trace để điều tra từng bước | | Sửa prompt để xử lý tốt ca hoàn trễ hạn, vô tình làm hỏng ca đơn đã hoàn một phần | Evals chạy trước và sau thay đổi | Điểm chung của sáu dòng trên: không dòng nào sửa được bằng cách viết lại câu chữ. Bạn có thể ghi đừng hoàn tiền hai lần trong prompt, nhưng câu đó không tạo ra một khóa chống trùng.  _Mỗi dấu hiệu trỏ tới một lớp hệ thống. Không dấu hiệu nào được giải bằng cách viết lại câu chữ trong prompt._ ## Platform là gì: prompt, harness và runtime Platform ở đây không nhất thiết là một sản phẩm SaaS (Software as a Service). Nó là tập hợp năng lực dùng chung giúp agent tồn tại được bên ngoài một lần gọi model. Một cách tách ba lớp dễ nhớ: - **Prompt** trả lời: agent nên làm gì trong lượt này, theo nguyên tắc nào, xuất ra định dạng gì. - **Harness** (lớp điều khiển hành vi agent): nạp context nào, cho phép tool nào, chạy vòng lặp ra sao, khi nào dừng. - **Runtime** duy trì hoạt động: agent chạy ở đâu, giữ trạng thái thế nào, phục hồi ra sao, được quan sát bằng gì. Ranh giới giữa harness và runtime lấy từ [tài liệu Cloudflare Agents](https://developers.cloudflare.com/agents/harnesses/): harness lo model call, xây dựng prompt, chọn tool và chiến lược memory; runtime cung cấp state, session, routing, scheduling, thực thi bền vững và observability. Đây là cách phân lớp của Cloudflare, không nên xem là một chuẩn thuật ngữ phổ quát. Giá trị của cách chia này nằm ở việc nó buộc bạn hỏi phần này thuộc lớp nào, chứ không nằm ở bản thân từ ngữ. Mình tách riêng lớp hành vi quanh model trong [Harness Engineering là gì](/ai/harness-engineering-la-gi), vì nó hay bị nhầm với việc chọn model mạnh hơn.  _Prompt nằm trong harness. Harness quyết định context và tool. Runtime giữ cho toàn bộ chạy được qua thời gian và lỗi._ Prompt vẫn là thành phần bắt buộc, không phải thứ bị thay thế. OpenAI mô tả trong [hướng dẫn thực hành xây dựng agent](https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/) rằng một agent có ba thành phần cốt lõi: model, tools và instructions. Prompt chính là nơi chứa phần lớn instructions. Vấn đề chỉ phát sinh khi ta kỳ vọng prompt kiêm luôn vai trò của database, hệ thống phân quyền, hàng đợi, log và bộ kiểm thử. Sáu phần tiếp theo là sáu năng lực tối thiểu để một agent hành động thật đứng vững. ## 1. Trạng thái bền vững và idempotency Đây là lớp trả lời câu hỏi: agent có tiếp tục được qua thời gian, lỗi và restart không? Một yêu cầu hoàn tiền hiếm khi kết thúc trong vài giây. Nó có thể phải chờ khách bổ sung ảnh chụp sản phẩm, chờ quản lý duyệt khoản vượt ngưỡng, chờ cổng thanh toán phản hồi. Trong khoảng chờ đó, tiến trình có thể bị restart, deploy đè lên, hoặc timeout. Nếu toàn bộ tiến độ chỉ nằm trong context của model, tiến trình bị mất thì agent không có một bản ghi bền vững để tiếp tục. Vì vậy tác vụ chạy dài cần lưu state và kết quả trung gian bên ngoài bộ nhớ tiến trình. Cũng nên tách rõ **context** và **memory**. Context window là dữ liệu bạn gửi vào một lần suy luận. Memory là cơ chế quyết định thông tin nào được lưu, lấy lại khi nào, trong phạm vi của ai, và giữ bao lâu. Trong ca hoàn tiền, ít nhất ba loại trạng thái nên nằm riêng: - **Trạng thái run**: đã xác minh đơn hàng, đang chờ duyệt. Cần chính xác và có checkpoint. - **Lịch sử hội thoại**: lý do khách đưa ra. Cần giới hạn theo session và theo user. - **Memory dài hạn**: kênh liên lạc khách ưa dùng. Cần consent, thời hạn lưu và khả năng xoá. Nối tất cả lịch sử vào prompt là cách làm dễ nhất và tệ nhất: chi phí tăng, nhiễu tăng, quyền riêng tư khó kiểm soát. Bài [Memory trong AI Agent](/ai/memory-trong-ai-agent-context-window) giải thích vì sao cửa sổ lớn hơn vẫn không thành memory, và tách ba lớp đó theo thời gian sống. Nếu chỗ lẫn là kho tài liệu RAG với hồ sơ từng khách, bài [RAG có đủ cho AI Agent không](/ai/rag-co-du-cho-ai-agent) tách vector search, Knowledge và long-term memory. Phần khó nhất của lớp này là **idempotency** (chạy lại không tạo thêm một hành động). Không có nó, mọi cơ chế retry đều trở thành nguồn rủi ro: agent thử lại một lệnh hoàn tiền tưởng như thất bại, trong khi giao dịch đầu đã thành công. Về mặt năng lực cụ thể, tài liệu [persistence của LangGraph](https://docs.langchain.com/oss/javascript/langgraph/persistence) là một ví dụ đọc được: nó mô tả checkpoint lưu lại state tại từng bước, khả năng chịu lỗi và resume từ điểm gần nhất, cùng human-in-the-loop (có người duyệt trong vòng lặp) dựa trên chính cơ chế checkpoint đó. Bạn không cần dùng đúng thư viện này. Thứ đáng giữ là hình dung về việc một run có thể tạm dừng và tiếp tục trông như thế nào trong thiết kế.  _Mỗi bước ghi checkpoint. Run có thể dừng chờ người duyệt rồi tiếp tục. Lệnh thanh toán đi qua khóa chống trùng._ ## 2. Danh tính và quyền ở lớp tool Model chỉ sinh ra dự đoán. Agent trở nên hữu ích khi đọc được dữ liệu thật và tác động được vào hệ thống thật qua API, function, database hay các tool khác. Nhưng có tool chưa phải là có kiểm soát. Platform còn phải trả lời được: - Tool nhận input và trả output theo schema nào. - Người dùng đang được phục vụ có quyền kích hoạt tool đó không. - Hành động là chỉ đọc, hay có ghi và khó hoàn tác. - Credential được cấp, giới hạn phạm vi và thu hồi ra sao. - Lỗi tạm thời khác lỗi nghiệp vụ thế nào. Prompt có thể nhắc model tôn trọng quyền hạn. Nhưng quyền thật phải được thực thi ở nơi model không sửa được luật. [Hướng dẫn kiến trúc agentic AI của AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/govern-architect-agentic-ai/agents-layer.html) xếp identity, authorization và audit trail vào ngay trong lớp agent, cùng với circuit breaker để ngắt khi hành vi vượt ngưỡng an toàn. Tức là coi chúng là thành phần kiến trúc, không phải một đoạn văn trong instructions. Với agent hoàn tiền, điều này có nghĩa rất cụ thể: tool `refund` không chạy dưới một credential vạn năng dùng chung, mà chạy dưới danh tính có phạm vi giới hạn, có audit trail ghi lại ai đã kích hoạt, cho đơn hàng nào, ở thời điểm nào. Google nhấn mạnh cùng hướng trong [tài liệu về core concept của AI agent](https://cloud.google.com/resources/core-concepts-ai-agents): bảo mật là một trong những mối quan tâm nền tảng khi đưa agent lên production, bên cạnh runtime, trace và evaluation. ## 3. Orchestration có giới hạn Orchestration là lớp quyết định bước nào chạy trước, output nào chuyển tiếp cho bước sau, khi nào rẽ nhánh, khi nào thử lại, khi nào kết thúc và khi nào giao lại cho người. JetBrains mô tả vòng lặp này trong [bài về orchestration cho AI agent](https://www.jetbrains.com/pages/ai-agents/architecture/ai-agent-orchestration/) như chu trình lập kế hoạch, định tuyến, thực thi, quan sát và điều chỉnh, và lưu ý rằng orchestration cần thiết ngay cả với một agent duy nhất, chứ không phải chỉ khi có nhiều agent. OpenAI cũng mô tả agent vận hành theo một run loop chạy tới khi đạt điều kiện thoát, và khuyến nghị bắt đầu bằng single agent trước khi nghĩ đến kiến trúc nhiều agent. Prompt chaining cố định chỉ chạy được A → B → C. Một orchestration loop thật phải xử lý được tình huống hệ thống trả về đơn hàng này đã được hoàn một phần: nghĩa là rẽ nhánh sang một quy trình khác, chứ không phải đi tiếp bước C như kế hoạch ban đầu. Phần quan trọng nhất là các giới hạn được thực thi. Đây là nơi bạn chặn vòng lặp vô hạn và chi phí mất kiểm soát bằng những điều kiện nằm trong code: - Số bước tối đa của một run. - Ngân sách token và chi phí. - Số lần gọi mỗi tool. - Thời gian chạy tối đa. - Số lần retry trước khi bàn giao cho người.  _Bốn bước của vòng lặp. Năm giới hạn được thực thi bằng code, không bằng câu chữ trong prompt._ Microsoft nêu thẳng giới hạn số vòng lặp như một biện pháp thiết kế cần thiết, chứ không phải tùy chọn nâng cao. Một câu đừng thử quá nhiều lần đặt cuối prompt không có hiệu lực cưỡng chế nào. ## 4. Guardrail nhiều lớp và phê duyệt của người Quyền của agent càng lớn, một quyết định sai càng đắt. Vì vậy **guardrail** (hàng rào an toàn) không nên là một lớp đơn. OpenAI khuyến nghị tiếp cận **layered defense**: kết hợp nhiều loại guardrail thay vì dựa vào một cơ chế duy nhất, cùng với authentication, authorization và các biện pháp bảo mật phần mềm thông thường. Các lớp thường gặp gồm kiểm tra dữ liệu đầu vào, lọc thông tin nhạy cảm, giới hạn phạm vi hành động, tách quyền đọc khỏi quyền ghi, và kiểm tra đầu ra trước khi nó biến thành hành động. Lớp cuối cùng là can thiệp của con người. OpenAI nêu hai tình huống kích hoạt rõ ràng: khi agent vượt ngưỡng lỗi hoặc thất bại lặp lại, và khi hành động thuộc nhóm rủi ro cao. Với agent hoàn tiền, ranh giới đó vẽ được rất cụ thể. Khoản dưới ngưỡng chính sách thì agent tự xử lý; khoản vượt ngưỡng thì dừng lại và chờ người duyệt. Điểm mấu chốt phân biệt guardrail với prompt: prompt định hướng hành vi, còn guardrail phải có khả năng **chặn** hành vi. Nếu một cơ chế chỉ hoạt động khi model chịu hợp tác, nó không phải guardrail. Đây cũng là lý do human-in-the-loop cần được thiết kế ở lớp runtime chứ không phải lớp giao diện. Một điểm chờ phê duyệt chỉ hoạt động được nếu run có thể tạm dừng, giữ nguyên state, và tiếp tục sau khi người duyệt trả lời. Đó chính là cơ chế checkpoint đã nói ở phần 1.  _Prompt định hướng hành vi. Guardrail phải chặn được hành vi. Khoản vượt ngưỡng dừng lại chờ người duyệt._ ## 5. Observability và trace Khi một khoản hoàn tiền sai xảy ra, câu hỏi đầu tiên là vì sao. Nếu bạn chỉ log câu trả lời cuối, câu hỏi đó không có lời đáp. **Observability** (khả năng quan sát hệ thống) ở đây nghĩa là team đọc được toàn bộ run, không chỉ output. Một trace đủ dùng cho agent thường ghi lại: - Phiên bản model và phiên bản prompt. - Context hoặc tài liệu đã truy xuất. - Từng tool call: tham số, kết quả, độ trễ. - Các lần retry và các lần bàn giao. - Token, chi phí, thời gian. - Quyết định phê duyệt hoặc từ chối. - Trạng thái cuối của run.  _Một trace đủ dùng để lần từ kết quả sai về đúng nhóm lỗi: model, context, tool, hoặc workflow._ Giá trị lớn nhất của trace là giúp phân biệt bốn nguyên nhân dễ bị nhầm lẫn: lỗi model, lỗi truy xuất context, lỗi tool, và lỗi workflow. Trong ca hoàn tiền, agent hoàn sai số tiền có thể là model tính sai, có thể là tool trả về đơn hàng cũ, cũng có thể là workflow bỏ qua bước kiểm tra hoàn một phần. Ba nguyên nhân đó cần ba cách sửa hoàn toàn khác nhau, và không cái nào đoán được nếu chỉ nhìn output. Google xếp trace cùng nhóm với runtime, bảo mật và evaluation trong các mối quan tâm khi vận hành agent ở production. Tức là hạ tầng quan sát không phải thứ thêm sau, mà là điều kiện để agent vận hành được. ## 6. Evals chạy trước và sau mỗi thay đổi Prompt thường được tinh chỉnh bằng vài lần thử tay. Cách này nhanh ở giai đoạn đầu và mù ở giai đoạn sau: bạn sửa một câu để xử lý tốt hơn ca hoàn trễ hạn, rồi không biết mình vừa làm hỏng ca đơn đã hoàn một phần. Bộ eval cho agent nên bao gồm: - Tập tình huống đại diện, kèm các edge case đã từng gây lỗi thật. - Tiêu chí thành công cho từng bước, không chỉ cho kết quả cuối. - Kiểm tra tất định với schema, quyền và business rule. - Đánh giá bằng người hoặc bằng model khi tiêu chí mang tính ngữ nghĩa. - So sánh giữa các phiên bản prompt, model, tool và workflow. Điểm cần nhấn: đánh giá agent khác đánh giá một câu trả lời. Một run có thể cho ra kết quả đúng qua một chuỗi bước sai, ví dụ hoàn đúng số tiền nhưng đã bỏ qua bước kiểm tra trùng lặp. Chỉ chấm output cuối sẽ cho điểm cao cho một hành vi nguy hiểm. Về mặt triển khai, tài liệu [evaluate và monitor GenAI app của Databricks](https://docs.databricks.com/aws/en/mlflow3/genai/eval-monitor) (cập nhật 2026-07-28) là một ví dụ về cách nối vòng đời này: dùng trace làm đơn vị dữ liệu chung, chấm điểm bằng scorer trong giai đoạn phát triển, rồi tiếp tục chấm trên lưu lượng production để phát hiện suy giảm chất lượng. Đây chỉ là một cách hiện thực hóa. Thứ nên giữ lại là nguyên tắc dùng cùng một bộ tiêu chí ở cả development lẫn production, để tốt hơn là một kết luận đo được chứ không phải cảm giác. ## Ba mức trưởng thành Yêu cầu một platform không có nghĩa phải mở đầu bằng Kubernetes, multi-agent và một dashboard lớn. Ba mức dưới đây là ba điểm dừng hợp lý khác nhau. ### Mức 1: Prompted feature Tác vụ một lượt, chỉ đọc dữ liệu được đưa sẵn, không tạo tác động bên ngoài, luôn có người kiểm tra output. Đủ dùng: quản lý phiên bản prompt và một tập test nhỏ. ### Mức 2: Agent runtime tối thiểu Tác vụ nhiều bước, gọi vài tool, cần giữ trạng thái xuyên suốt một run: đúng ca hoàn tiền. Cần: run ID và state store, tool schema kèm permission, timeout và giới hạn vòng lặp, structured logs, phê duyệt trước hành động rủi ro, eval cho các luồng quan trọng. Đây thường là điểm dừng hợp lý cho một team nhỏ. Trong mã nguồn mở, [GoClaw](/ai/goclaw-la-gi) minh họa khá rõ cách phân lớp này: prompt chỉ là một stage trong agent pipeline, còn history, tool, memory, multi-agent orchestration và tracing được xử lý như các thành phần riêng. Đây nên được xem là một ví dụ kiến trúc để tham khảo, không phải lý do để team nhỏ bê nguyên cả stack. ### Mức 3: Shared agent platform Nhiều agent hoặc nhiều team lặp lại cùng nhu cầu: registry cho agent và tool, identity và policy dùng chung, secrets, quota và cost control tập trung, deployment kèm versioning và rollback, observability ở cấp tổ chức. IBM mô tả nhu cầu này trong [bài về AI agent management](https://www.ibm.com/think/topics/ai-agent-management): khi số lượng agent tăng lên, tổ chức cần một control plane (lớp điều khiển nền tảng) dùng chung để quản lý và giám sát chúng một cách nhất quán, thay vì để mỗi agent tự mang theo cơ chế riêng.  _Mỗi mức là một điểm dừng hợp lệ. Leo lên mức cao hơn khi mức hiện tại không còn giữ được rủi ro thực tế._ Nếu bạn mới có đúng một use case, dựng hạ tầng mức 3 trước thường tốn nhiều hơn giá trị nó mang lại. ## Kiến trúc tối thiểu cho một team nhỏ Gọn hơn bạn nghĩ. Một platform mức 2 đủ cho agent hoàn tiền có thể chỉ gồm bảy thành phần: 1. **API nhận goal** và tạo `run_id`. 2. **Orchestrator có giới hạn** chạy agent loop với số bước và ngân sách rõ ràng. 3. **Tool registry nhỏ** khai báo schema, quyền, timeout và mức rủi ro của từng tool. 4. **Database** lưu trạng thái run, checkpoint và kết quả tool quan trọng. 5. **Approval queue** cho các hành động ghi, gửi hoặc chuyển tiền. 6. **Trace store** ghi model, prompt version, tool call, latency, cost và lỗi. 7. **Eval suite** chạy trước mỗi lần đổi prompt, model hoặc workflow.  _Bảy thành phần này đã là một platform theo nghĩa kiến trúc. Chúng có thể nằm gọn trong một codebase và phục vụ đúng một agent hoàn tiền._ Bảy thứ này đã là một platform theo nghĩa kiến trúc: một đường chạy chuẩn, có policy và có khả năng quan sát. Chúng hoàn toàn có thể nằm gọn trong một codebase, dùng hạ tầng sẵn có, và phục vụ đúng một agent. Nguyên tắc nên giữ: **chuẩn hóa những gì lặp lại, đừng trừu tượng hóa những gì chưa tồn tại**. Đến khi agent thứ hai cần đúng cơ chế tool permission hoặc tracing đó, hãy tách nó thành capability dùng chung. ## Checklist quyết định Trước khi viết dòng code đầu tiên, chạy qua sáu câu hỏi này: 1. **Đường đi từ input đến output đã biết trước chưa?** Nếu rồi, dùng workflow tất định, không cần agent. 2. **Agent có thực hiện hành động khó hoàn tác không?** Nếu có, cần tool schema, permission và bước phê duyệt cho đúng hành động đó. 3. **Một run có thể bị gián đoạn hoặc phải chờ bên khác không?** Nếu có, cần state bền vững, checkpoint và idempotency. 4. **Hành động có nguy cơ lặp lại gây hậu quả kép không?** Nếu có, cần khóa chống trùng ở lớp tool, không phải ghi chú trong prompt. 5. **Khi sự cố xảy ra, team có giải thích được agent đã làm gì không?** Nếu không, cần trace chi tiết theo bước. 6. **Bạn có cách chứng minh phiên bản mới không làm hỏng ca cũ không?** Nếu không, cần eval chạy trước và sau thay đổi. Câu trả lời không ở câu 1 và có ở bất kỳ câu nào từ 2 đến 6 đều chỉ tới một lớp hệ thống cụ thể cần bổ sung, không phải một prompt cần viết lại. ## Câu hỏi thường gặp Những câu dưới đây hay xuất hiện khi team đã có prompt khá ổn nhưng chưa chắc đang thiếu lớp nào. Trả lời ngắn, rồi mới quyết định có cần thêm harness hay runtime. ### Prompt engineering có còn quan trọng khi đã có platform không? Có. Prompt vẫn định nghĩa mục tiêu, nguyên tắc và cách model sử dụng context. Platform không sửa được một chỉ dẫn mơ hồ; nó chỉ đảm bảo chỉ dẫn ấy nhận đúng dữ liệu, chạy trong giới hạn và được đo qua từng phiên bản. ### Dùng framework agent có nghĩa là đã có platform chưa? Không hẳn. Framework thường giúp dựng agent loop, tool calling hoặc workflow. Hệ thống production còn cần state bền vững, identity, permission, secrets, deployment, tracing, eval, approval và quy trình xử lý sự cố. Hãy đối chiếu danh sách năng lực thực tế thay vì nhìn nhãn. ### Một agent duy nhất có cần orchestration không? Có, nếu nó chạy nhiều bước. Orchestration ở đây là cơ chế theo dõi state, gọi tool, xử lý kết quả, giới hạn retry và quyết định điểm dừng. Multi-agent chỉ là một topology phức tạp hơn, không phải điều kiện để có orchestration. ### Có nên bắt đầu bằng multi-agent không? Thường là không. Cả OpenAI lẫn Microsoft đều khuyến nghị tối ưu single agent trước. Chỉ tách nhiều agent khi một agent không còn xử lý đáng tin cậy vì prompt quá phức tạp, tool quá tải, hoặc cần cô lập quyền giữa các domain thật sự khác nhau. Bài [Multi-Agent Orchestration là gì](/ai/multi-agent-orchestration-la-gi) tách việc cắm nhiều agent với lớp chia việc, gom kết quả và bắt lỗi. ### Có tiêu chí số nào quyết định lúc nào được phép xây platform không? Không. Chỉ một hành động tạo tác động thật cũng đã có thể cần schema, permission, guardrail và approval. Ngược lại, một agent chạy mười bước nhưng chỉ đọc dữ liệu công khai thì rủi ro thấp hơn nhiều. Rủi ro của hành động, chứ không phải số bước, mới là thứ quyết định. ## Việc nên làm tiếp theo Đừng bắt đầu bằng việc chọn platform. Hãy bắt đầu bằng một bài tập cụ thể, làm được trong một buổi: Lấy agent bạn đang có. Viết ra chuỗi bước thật của nó khi chạy ngoài production, kèm mọi lần nó chạm vào hệ thống bên ngoài. Với mỗi bước, trả lời ba câu: bước này có ghi dữ liệu không, bước này có thể bị gián đoạn không, và nếu bước này sai thì tôi biết bằng cách nào? Bước đầu tiên trả lời có cho câu 1 hoặc câu 2, hoặc không biết cho câu 3, chính là failure mode đầu tiên prompt không giải quyết được. Thêm đúng lớp hệ thống cho bước đó: một khóa chống trùng, một điểm phê duyệt, một trace, rồi dừng lại. Lặp lại khi bước tiếp theo cần đến. Đó là cách một platform hình thành: từ các rủi ro có thật, không phải từ một sơ đồ kiến trúc vẽ trước. Bạn có thể đọc thêm các bài về [ứng dụng AI thực tế](/ai) tại nguyennlt.com.ai-agentagent-platformllmorchestrationai-engineeringnguyennlt