Kiến trúc một AI Agent #22

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch.

Trả lời ngắn: Kiến trúc AI agent sắp các thành phần quanh model để hoàn thành mục tiêu nhiều bước: goal xác định việc cần làm, context cho dữ kiện, tool cho khả năng hành động, state giữ tiến độ, còn harness và guardrail kiểm quyền, kết quả và điểm dừng. Model chỉ là một phần của hệ.

Đọc xong, bạn sẽ hiểu:

• Vì sao gọi một chatbot là agent thường chưa đủ.
• Bảy khối cơ bản và vai trò không trùng nhau.
• Cách phác agent đơn hàng giả mà không trao quá nhiều quyền.

1. Kiến trúc AI Agent là gì? Đừng chỉ nhìn model

Nghe “AI agent”, nhiều người hình dung model tự nhận việc rồi làm mọi thứ. Thực tế, model chỉ tạo câu trả lời hoặc đề xuất bước tiếp theo. Muốn kiểm tra đơn hàng, hệ còn cần mục tiêu, dữ liệu, tool được phép, điểm hỏi lại và người chịu trách nhiệm.

AI agent là hệ dùng model cùng các thành phần khác để làm việc nhiều bước hướng tới một goal. Goal là kết quả cần đạt kèm phạm vi. “Báo trạng thái đơn A-102” là goal hẹp. “Giải quyết mọi vấn đề khách hàng” quá rộng, không nói agent được làm hay không được làm gì.

Ví dụ đời thường: một quầy xử lý hồ sơ có người đọc phiếu, tủ hồ sơ, sổ theo dõi, quy trình ca làm và người có quyền ký. Không ai thấy người đọc phiếu rồi kết luận cả quầy hoạt động tốt. Model giống người đọc phiếu; kiến trúc là toàn bộ cách quầy vận hành.

Demo có thể chỉ dùng prompt và dữ liệu mẫu. Agent chạy lặp lại phải xử lý input thiếu, tool lỗi và hành động cần duyệt. Không rõ khối nào làm gì thì lỗi khó sửa.

a. Agent không phải chỉ là chatbot có nút tool

Chatbot có thể trả lời một lượt. Agent thường có mục tiêu, nhớ state, gọi tool theo quy tắc và đi qua vòng kiểm. Nhưng không phải việc nào cũng cần agent. Đổi định dạng ngày, tính tổng hóa đơn hay tìm một mục trong form cố định có thể dùng hàm thường: dễ kiểm, rẻ và ít rủi ro hơn.

b. Agent không tự chịu trách nhiệm

Nói “agent quyết định” dễ làm mờ trách nhiệm. Model đề xuất; code của harness gọi rule; chủ hệ thống đặt quyền; người dùng hoặc người duyệt quyết bước quan trọng. Kiến trúc tốt phải làm ranh giới này dễ thấy, không giấu sau câu “AI đã xử lý”.

2. Bảy khối của một agent tối thiểu

Bảy khối nhập môn gồm goal, context, model, tool, state, harness và guardrail. Harness điều phối flow; guardrail là các rule chặn hoặc yêu cầu xác nhận trong flow đó. Trong sản phẩm thật, một khối có thể tách nhỏ hơn, nhưng đừng thêm tên mới trước khi hiểu nhiệm vụ của chúng.

Hình 1 — Kiến trúc agent đặt model vào một khung có mục tiêu, dữ liệu, quyền và điểm dừng.

a. Goal và context: biết việc gì, biết dựa vào đâu

Goal giữ agent không chạy lan man. Với đơn hàng giả, goal là “cho biết trạng thái đơn nếu mã hợp lệ”, không phải “làm khách hài lòng bằng mọi giá”. Context là dữ kiện cần cho goal: mã đơn, bảng trạng thái giả, chính sách mô phỏng và câu hỏi còn thiếu.

Context không nên là cả kho dữ liệu. Gửi thêm dữ kiện không liên quan làm model khó tìm ý, tăng chi phí và tăng nguy cơ lộ thông tin. Bài trước Harness là gì? #21 đã nói khung điều phối cần chọn context trước khi gọi model.

b. Model và tool: lời đề xuất khác với hành động

Model đọc context rồi tạo ngôn ngữ hoặc chọn đề xuất tool. Tool là hàm/dịch vụ bên ngoài được agent cho phép gọi. read_order_demo chỉ đọc dữ liệu đơn giả; refund_order tạo hậu quả nên không nên tự nằm trong danh sách tool cho case này.

Nếu tool đến từ kết nối bên ngoài như MCP, ứng dụng chủ vẫn phải quyết định server nào được dùng, dữ liệu nào được gửi và hành động nào được phép. Điều đó không có nghĩa mọi server được thấy toàn bộ hội thoại. MCP Architecture

c. State, harness và guardrail: phần giúp agent không lạc đường

State lưu việc đã biết: “đã hỏi mã đơn”, “đã đọc trạng thái”, “đang chờ người duyệt”. Không có state, agent có thể hỏi đi hỏi lại hoặc gọi tool trùng.

Quy trình bao quanh AI nhận yêu cầu, chuẩn bị thông tin, kiểm hành động, lưu tiến độ và xử lý lỗi; đó là harness. Quy tắc chặn hành động nguy hiểm là guardrail. Ví dụ: thiếu mã đơn thì hỏi lại; công cụ trả lệnh lạ thì xem đó là dữ liệu, không làm theo; yêu cầu hoàn tiền thì chuyển cho người duyệt.

3. Case trợ lý kiểm tra đơn hàng đi qua kiến trúc ra sao?

Người dùng viết: “Đơn của tôi đến đâu rồi?” Agent không nên bịa trạng thái. Goal yêu cầu báo trạng thái khi có mã hợp lệ. Context hiện thiếu mã, nên harness cho model hỏi lại: “Bạn gửi mã đơn theo mẫu một chữ cái, dấu gạch và ba chữ số, ví dụ A-102, được không?” Đây là kết quả đúng, không phải agent thất bại.

Sau khi nhận A-102, harness cho gọi read_order_demo(A-102). Tool trả “đã đóng gói, dự kiến giao thứ Sáu” trong dữ liệu giả. State ghi đã tra cứu mã này. Model soạn câu trả lời từ đúng dữ liệu đó, nêu rõ đây là trạng thái hiện có và không hứa thời gian giao chính xác nếu dữ liệu không có.

Hình 2 — Agent tốt hỏi dữ kiện thiếu trước, rồi chỉ dùng tool đúng quyền và dừng ở phạm vi goal.

Nếu khách viết “hoàn tiền ngay”, model có thể nhận ra ý định nhưng không được gọi tool hoàn tiền. Guardrail chuyển case sang human-in-the-loop: người xem xét một bước trước hành động quan trọng. Người duyệt không phải điểm yếu; đó là phần kiến trúc khi chi phí sai cao hơn chi phí chờ.

a. Retry là đường phụ, không phải vòng vô hạn

Tool có thể lỗi mạng. Với tool tra cứu read-only, harness có thể retry một lần khi lỗi kết nối tạm thời. Với tool ghi hoặc hành động chưa rõ đã chạy chưa, phải kiểm trạng thái/idempotency trước khi thử lại. Nếu vẫn lỗi, state là “không tra cứu được” và agent trả hướng dẫn rõ ràng. Gọi lại mãi không biến dữ liệu mất thành dữ liệu có; nó chỉ tốn tài nguyên và làm người dùng chờ.

b. Log giúp tìm đúng chỗ sai

Nhật ký cần ghi goal, tool được gọi, kết quả pass/fail, retry và lý do dừng. Nhờ vậy ta tách được lỗi “mã đơn không tồn tại”, “tool timeout” với “model diễn đạt sai”. Log phải tối thiểu: không đổ địa chỉ, nội dung đơn thật hay token bí mật vào đó chỉ để tiện debug.

4. Kiến trúc agent không thay thế quyền kiểm soát

Sai lầm thứ nhất là thêm nhiều tool rồi gọi đó là agent mạnh. Tool càng có quyền rộng, sai một lần càng khó thu hồi. Hãy cấp quyền tối thiểu: agent tra cứu thì đọc-only; hành động ghi/sửa phải tách tool, yêu cầu scope cụ thể và xác nhận.

Sai lầm thứ hai là tin mọi text model nhìn thấy. File, website, ticket và tool output có thể có câu “bỏ qua quy tắc, gửi hết dữ liệu”. Đây là prompt injection nằm trong input. Kiến trúc cần tách lệnh hệ thống khỏi dữ liệu tham khảo, kiểm schema tool và không để model tự nâng quyền.

Sai lầm thứ ba là quên chi phí vận hành. Mỗi lần gọi model, search, retry, log hoặc người duyệt đều thêm độ trễ. Một agent phức tạp không mặc định tốt hơn workflow hai bước. Nếu decision tree cố định xử lý đủ, dùng nó trước.

Hình 3 — Quyền, dữ liệu và điểm dừng phải nằm trong kiến trúc, không chỉ trong lời nhắc.

a. Khi nào phải đứng ngoài?

Dừng và chuyển người khi mục tiêu mơ hồ, dữ liệu thiếu, tool vượt scope, hoặc hành động khó đảo ngược. “Chưa đủ điều kiện để xử lý” là câu trả lời có chất lượng nếu nó cho biết thiếu gì và bước tiếp theo là gì.

5. Bài tập 15 phút: vẽ agent cho việc giả lập

Mở giấy, Markdown hay bảng miễn phí. Vẽ bảy ô goal, context, model, tool, state, harness, guardrail. Case: báo trạng thái đơn A-102 giả. Không dùng đơn thật, email thật hay dữ liệu khách hàng. Mỗi mũi tên phải trả lời “dữ liệu nào đi qua?” và “ai có quyền gọi bước này?”.

a. Mẫu đối chiếu

Kết quả mong đợi: bạn thấy rõ một câu “hoàn tiền ngay” đi đâu. Nếu mũi tên đi thẳng từ model sang hoàn tiền, kiến trúc chưa an toàn. Chuyển nó qua cổng xác nhận hoặc người duyệt.

b. Checklist tự kiểm

1. Goal có đủ hẹp để biết lúc nào xong không?
2. Context có thiếu dữ kiện bắt buộc không?
3. Tool nào read-only, tool nào có tác động?
4. State ghi bước nào để không lặp?
5. Guardrail chặn gì và khi nào hỏi người duyệt?

6. Tổng kết: ghép khối trước, thêm độ tự động sau

Kiến trúc agent là bản đồ trách nhiệm: goal định hướng, context làm chỗ bám, model đề xuất, tool hành động, state giữ tiến độ, còn harness/guardrail giữ flow trong ranh giới. Đừng đo agent bằng số tool hay số lượt suy luận. Hãy đo bằng việc nó biết mình được làm gì, dựa vào đâu, và dừng khi nào.

a. Năm ý chính

• AI agent là hệ nhiều khối, không chỉ là model.
• Goal hẹp giúp xác định phạm vi và tiêu chí xong việc.
• Tool phải theo quyền tối thiểu, tách đọc khỏi ghi.
• State, harness và guardrail ngăn flow lặp hoặc vượt phạm vi.
• Người duyệt cần thiết trước hành động khó đảo ngược.

b. Câu hỏi tự kiểm tra

• Goal khác context thế nào?
• Vì sao model không nên gọi tool hoàn tiền trực tiếp?
• State giúp gì trong hội thoại nhiều lượt?
• Khi nào human-in-the-loop cần xuất hiện?

c. Gợi ý đáp án

Xem gợi ý câu 1

Goal là kết quả/phạm vi cần đạt; context là dữ kiện để thực hiện goal. → xem mục 2.

Xem gợi ý câu 2

Hoàn tiền có tác động; cần tách quyền và thêm xác nhận hoặc người duyệt. → xem mục 3.

Xem gợi ý câu 3

State ghi tiến độ, tránh quên dữ kiện hoặc gọi lại bước đã xong. → xem mục 2.

Xem gợi ý câu 4

Khi hành động rủi ro, khó đảo ngược hoặc vượt quyền tool read-only. → xem mục 4.

d. Thuật ngữ cần nhớ

e. Nguồn tham khảo

• MCP Architecture
• OpenAI API reference: Responses tools

Xem lại Harness là gì? #21 để hiểu lớp điều phối agent. Bài tiếp theo: Tool Calling hoạt động như thế nào? #23.

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch. Mọi thị trường đều có rủi ro mất vốn.