title: "AI Agent Architecture: Kiến trúc của các hệ thống tự vận hành (Autonomous Agents)"
series: "Software Architecture Masterclass"
part: "Phần 5 — AI-Augmented & Future-Proofing"
order: 40
audience: "Solutions Architect & Technical Lead"
reading_time: "14 phút"
tags: ["ai-agent", "autonomous-agents", "human-in-the-loop", "guardrails", "llm", "audit-trail"]

AI Agent Architecture: Kiến trúc của các hệ thống tự vận hành (Autonomous Agents)

Có một buổi demo mà rất nhiều kiến trúc sư đã chứng kiến trong hai năm gần đây, và nó luôn đi theo cùng một kịch bản: một AI agent nhận yêu cầu bằng ngôn ngữ tự nhiên, tự lập kế hoạch, tự gọi một chuỗi tool, và hoàn thành việc gì đó trước đây cần một kỹ sư ngồi cả buổi chiều. Phòng họp trầm trồ. Sếp hỏi "bao giờ đưa lên production được?". Và đó chính xác là câu hỏi sai — không phải vì agent không đủ giỏi, mà vì câu hỏi đúng phải là: "Nếu agent này suy luận sai ở bước thứ ba, nó có thể gây ra thiệt hại gì trước khi có ai đó nhận ra?"

Sự khác biệt giữa một chatbot trả lời câu hỏi và một AI agent thực thi hành động thật (real actions) là sự khác biệt giữa một hệ thống chỉ có thể nói sai và một hệ thống có thể làm sai. Một chatbot bịa (hallucinate) một câu trả lời tệ nhất cũng chỉ gây khó chịu cho người đọc. Một agent tự trị có quyền gọi API xóa dữ liệu, gửi email cho khách hàng, hay thực hiện một giao dịch thanh toán mà "bịa" ra một hành động sai — thì hậu quả đã rời khỏi màn hình chat và bước vào thế giới thật, nơi không có nút "undo" mặc định.

Bài này khép lại series 40 bài về kiến trúc phần mềm, và nó khép lại đúng ở nơi mọi nguyên lý trước đó hội tụ: một hệ thống agentic (có khả năng hành động tự trị) không cần một bộ nguyên lý kiến trúc mới — nó cần áp dụng lại, nghiêm ngặt hơn, những nguyên lý đã có: giới hạn (boundaries), thiết kế cho thất bại (design for failure), và khả năng quan sát (observability). Thứ thay đổi không phải là công việc của kiến trúc sư — mà là thành phần đang được kiến trúc hóa.

The Problem

Một AI agent, theo định nghĩa vận hành, là một hệ thống dùng LLM (Large Language Model) để lập kế hoạch và tự quyết định chuỗi hành động cần thực hiện nhằm đạt một mục tiêu — thay vì chỉ trả lời một câu hỏi đơn lẻ. Nó khác một chatbot RAG (Retrieval-Augmented Generation — bài 38) ở một điểm cốt lõi: agent không chỉ đọc và tổng hợp, nó hành động — gọi tool, ghi dữ liệu, gửi request ra hệ thống bên ngoài, và lặp lại chu trình quan sát-suy luận-hành động (thường gọi là vòng lặp ReAct hoặc tương tự) cho đến khi tự đánh giá là đã hoàn thành mục tiêu.

Vấn đề kiến trúc nảy sinh chính xác từ đặc tính đó. Một service truyền thống có hành vi được lập trình tường minh: input X luôn dẫn tới hành động Y theo một đường đi có thể trace được trong code. Một AI agent thì không — nó suy luận bằng một mô hình xác suất, chuỗi hành động của nó phụ thuộc vào cách nó "diễn giải" ngữ cảnh tại thời điểm chạy, và cùng một input có thể dẫn tới hai chuỗi hành động khác nhau ở hai lần chạy khác nhau. Đây không phải một lỗi cần sửa — đó là bản chất của cách LLM hoạt động, và nó tồn tại vĩnh viễn dưới mọi cải tiến mô hình.

Khi một team gắn cho agent này quyền gọi tool thật — tạo record trong CRM, gửi email, thực hiện refund, xóa file, deploy một thay đổi cấu hình — bài toán không còn là "agent có thông minh không" mà là "hệ thống có giới hạn được agent không, khi nó suy luận sai". Và nó sẽ suy luận sai, không phải nếu mà là khi nào: prompt injection từ dữ liệu bên ngoài (một email độc hại chứa chỉ dẫn ẩn), một tool trả về kết quả gây hiểu nhầm, hoặc đơn giản là một chuỗi suy luận hợp lý về mặt ngôn ngữ nhưng sai về mặt nghiệp vụ. Rủi ro thực sự không phải "agent trả lời sai" — mà là "agent thực hiện một hành động không thể đảo ngược, dựa trên một suy luận sai, và không ai biết cho tới khi hậu quả đã xảy ra".

Đây chính là khoảng trống mà rất nhiều team bỏ qua khi chuyển từ demo sang production: demo được thiết kế để phô diễn mức độ tự trị càng cao càng ấn tượng; production cần phô diễn mức độ kiểm soát được càng cao càng đáng tin cậy. Hai mục tiêu này xung khắc trực tiếp, và không có cách nào dung hòa mà không phải trả giá ở một phía.

The Theory

Kiến trúc cho một hệ thống agentic có trách nhiệm được xây trên ba trụ cột, và cả ba đều là biến thể của một nguyên lý cũ hơn rất nhiều so với AI: đừng bao giờ trao một quyền lực mà không có giới hạn và không có khả năng quan sát nó được sử dụng như thế nào.

1. Không gian hành động giới hạn (bounded action space). Agent không được phép gọi "bất kỳ tool nào nó thấy hữu ích" — nó chỉ được cấp quyền truy cập vào một tập tool đã được whitelist tường minh, mỗi tool có một schema đầu vào chặt (thường là JSON schema), một phạm vi quyền hạn rõ ràng (scope), và lý tưởng nhất là một giới hạn về mức độ ảnh hưởng (ví dụ: tool send_email chỉ được gọi tối đa N lần trong một phiên, tool update_record chỉ được sửa các trường đã khai báo trước). Đây là bản dịch trực tiếp của nguyên tắc least privilege (bài 32 — Zero Trust) sang ngữ cảnh agent: agent không "được tin tưởng" theo mức độ nó tỏ ra thông minh, nó chỉ được cấp đúng quyền cần thiết cho tác vụ, không hơn.

2. Cổng phê duyệt con người (human-in-the-loop) cho hành động không thể đảo ngược. Nguyên tắc phân loại quan trọng nhất: mọi hành động agent có thể thực hiện được chia làm hai nhóm — hành động có thể đảo ngược (reversible), như đọc dữ liệu, tạo một bản nháp, gắn nhãn tạm thời; và hành động không thể đảo ngược hoặc khó đảo ngược (irreversible/costly-to-reverse), như xóa dữ liệu, gửi giao tiếp ra bên ngoài tổ chức, thực hiện thanh toán, thay đổi quyền truy cập. Nhóm đầu agent có thể tự thực hiện trong bounded action space đã định nghĩa. Nhóm sau bắt buộc phải dừng lại ở một điểm kiểm tra (checkpoint) và chờ một con người xác nhận trước khi thực thi — agent chỉ được phép đề xuất hành động, không được thực thi nó.

3. Observability và audit trail cho toàn bộ chuỗi suy luận. Vì hành vi của agent không xác định trước (non-deterministic) và phụ thuộc ngữ cảnh runtime, cách duy nhất để chẩn đoán "tại sao agent làm việc này" sau khi sự việc xảy ra là có một log đầy đủ: input nhận được, chuỗi suy luận trung gian (reasoning trace hoặc chain-of-thought nếu mô hình lộ ra được), tool nào được gọi với tham số gì, kết quả trả về, và quyết định cuối cùng. Đây là phiên bản mở rộng của observability (bài 28) cho một hệ thống mà "logic" không nằm trong code có thể đọc được, mà nằm trong một quá trình suy luận ẩn. Không có audit trail này, mọi sự cố agent đều trở thành hộp đen không thể điều tra — và không thể cải thiện có hệ thống, chỉ có thể vá từng trường hợp sau khi đã xảy ra.

Ba trụ cột này thường được ghép lại thành một mô hình gọi là agent orchestrator với policy layer: một lớp trung gian đứng giữa LLM (nơi ra quyết định) và tool thật (nơi hành động xảy ra), có nhiệm vụ chặn, lọc, và định tuyến mọi lời gọi tool qua đúng chính sách đã định nghĩa trước khi nó chạm tới hệ thống thật.

The Trade-off

Đây là phần không được phép mơ hồ — và với agent, sự mơ hồ dễ xảy ra nhất vì "tự trị" nghe hấp dẫn hơn "bị giới hạn" trong mọi buổi trình bày.

Được gì khi giới hạn quyền tự trị (bounded tools, approval gate, audit log):

Blast radius của một suy luận sai bị chặn lại ở đúng ranh giới đã định nghĩa. Nếu agent suy luận sai và cố gọi một tool ngoài whitelist, lời gọi bị từ chối trước khi chạm hệ thống thật — thiệt hại dừng lại ở "agent bị chặn", không lan ra "dữ liệu đã bị xóa".
Hành động không thể đảo ngược luôn có một con người chịu trách nhiệm cuối cùng. Đây không chỉ là kiểm soát kỹ thuật — nó là kiểm soát trách nhiệm giải trình (accountability). Khi một refund sai được thực hiện, tổ chức cần trả lời được "ai đã phê duyệt", không phải "agent tự quyết định".
Audit trail biến sự cố thành bài học, không phải bí ẩn. Khi có audit trail đầy đủ, một hành vi bất thường của agent có thể được phân tích nguyên nhân gốc (root cause) và sửa ở tầng policy hoặc prompt — thay vì lặp lại vô hạn vì không ai biết nó đã xảy ra như thế nào.
Niềm tin của người dùng và tổ chức tăng dần theo thời gian, có cơ sở. Một hệ thống agent có giới hạn rõ ràng có thể được mở rộng quyền dần dần dựa trên dữ liệu thực tế về độ tin cậy — thay vì phải đặt cược toàn bộ niềm tin ngay từ ngày đầu.

Mất gì — và đây là phần không được phép né tránh:

Tốc độ và trải nghiệm "ma thuật" giảm rõ rệt. Phần hấp dẫn nhất của agent tự trị hoàn toàn là nó chạy xong việc trong khi người dùng đi pha cà phê. Một cổng phê duyệt con người phá vỡ chính xác trải nghiệm đó — agent giờ dừng lại, chờ, và có thể chờ hàng giờ nếu người phê duyệt không online. Với các use case cần phản hồi tức thời (real-time), approval gate có thể làm agent trở nên vô dụng về mặt thực tiễn.
Chi phí xây dựng và vận hành tăng đáng kể. Một policy layer, một hệ thống approval workflow, một audit log có cấu trúc đủ để điều tra sau này — đây là hạ tầng bổ sung không tầm thường, không phải một cấu hình bật/tắt. Team phải xây và duy trì thêm một tầng kiến trúc hoàn toàn mới, song song với chính agent.
Giới hạn hành động sai cũng giới hạn giá trị đúng. Một whitelist quá chặt khiến agent không thể xử lý các trường hợp hợp lệ nằm ngoài dự đoán ban đầu — mất đi chính khả năng thích ứng linh hoạt là lý do người ta chọn agent thay vì workflow cứng ngay từ đầu. Đây là căng thẳng cố hữu: giới hạn càng chặt, agent càng an toàn nhưng càng giống một workflow được lập trình sẵn — và nếu vậy, tại sao không dùng workflow truyền thống rẻ hơn, dễ debug hơn?
Approval fatigue là rủi ro vận hành có thật. Nếu mọi hành động đều cần phê duyệt, con người sẽ bắt đầu phê duyệt theo phản xạ mà không thực sự xem xét — đúng hiện tượng đã xảy ra với alert fatigue (bài 28) và code review rubber-stamp. Approval gate chỉ có giá trị nếu tần suất và chất lượng của nó được thiết kế để con người thực sự xem xét, không phải chỉ ký tên qua loa.
Đây không phải giải pháp một lần — nó cần bảo trì liên tục. Whitelist tool, ranh giới reversible/irreversible, và ngưỡng approval phải được xem lại định kỳ khi nghiệp vụ thay đổi. Một tool từng được coi là "an toàn" (đọc dữ liệu) có thể trở thành rủi ro khi dữ liệu đó bắt đầu chứa thông tin nhạy cảm mới.

Nói ngắn gọn: agent tự trị hoàn toàn nhanh hơn, ấn tượng hơn, và rẻ hơn để xây trong một demo — nhưng đặt cược toàn bộ hệ thống vào giả định rằng LLM sẽ luôn suy luận đúng, một giả định không bao giờ đúng 100% với bất kỳ mô hình nào hiện có. Agent có giới hạn chậm hơn, kém "ma thuật" hơn, và tốn công xây dựng thêm một tầng kiểm soát — để đổi lấy việc một suy luận sai không biến thành một sự cố không thể cứu vãn trong hệ thống thật.

The Architecture Diagram

Sơ đồ dưới đây minh họa một agent orchestrator với ba lớp kiểm soát: bounded tool access, approval gate cho hành động không thể đảo ngược, và audit log ghi lại toàn bộ chuỗi quyết định.

flowchart TB
    USER["Người dùng / Hệ thống trigger"] -->|"yêu cầu bằng ngôn ngữ tự nhiên"| AGENT["AI Agent<br/>(LLM lập kế hoạch + suy luận)"]

    AGENT -->|"đề xuất hành động"| POLICY["Policy Layer / Orchestrator<br/>(kiểm tra whitelist + phân loại rủi ro)"]

    POLICY -->|"tool nằm ngoài whitelist"| DENY["Từ chối<br/>(trả lỗi về agent, ghi log)"]

    POLICY -->|"hành động reversible<br/>(đọc dữ liệu, tạo nháp, gắn nhãn tạm)"| TOOLS_SAFE["Tool an toàn<br/>(whitelist: read, draft, tag)"]

    POLICY -->|"hành động irreversible<br/>(xóa, thanh toán, gửi ra ngoài)"| GATE["Cổng phê duyệt con người<br/>(Human-in-the-loop)"]

    GATE -->|"con người từ chối"| DENY
    GATE -->|"con người phê duyệt"| TOOLS_CRITICAL["Tool nhạy cảm<br/>(delete, payment, external comms)"]

    TOOLS_SAFE --> SYSTEM["Hệ thống thật<br/>(CRM, DB, email, payment gateway)"]
    TOOLS_CRITICAL --> SYSTEM

    AGENT -.->|"mọi bước suy luận + quyết định"| AUDIT[("Audit Trail<br/>input, reasoning trace,<br/>tool call, tham số, kết quả,<br/>phê duyệt/từ chối, timestamp")]
    POLICY -.-> AUDIT
    GATE -.-> AUDIT
    DENY -.-> AUDIT

    SYSTEM -->|"kết quả thực thi"| AGENT

Điểm mấu chốt của sơ đồ nằm ở nhánh giữa: mọi hành động agent đề xuất đều phải đi qua Policy Layer trước khi chạm hệ thống thật — không có đường tắt trực tiếp từ Agent sang System. Nhánh phải (hành động irreversible) luôn rẽ qua cổng phê duyệt con người, dù agent có "tự tin" đến đâu trong suy luận của nó. Và mọi nhánh, kể cả nhánh bị từ chối, đều ghi vào Audit Trail — vì một hành động bị chặn cũng là dữ liệu quan trọng để hiểu agent đang cố làm gì.

Implementation Guardrails

Mọi hành động không thể đảo ngược — xóa, thanh toán, giao tiếp ra bên ngoài tổ chức — PHẢI đi qua cổng phê duyệt con người, không có ngoại lệ dựa trên "agent này đã chứng minh đáng tin cậy". Độ tin cậy quan sát được trong quá khứ không phải là bảo chứng cho hành vi tương lai của một hệ thống suy luận xác suất — một agent đã đúng 1000 lần liên tiếp không có gì đảm bảo lần thứ 1001 nó không suy luận sai theo một cách hoàn toàn mới.
Mọi quyết định của agent phải được ghi log kèm đầy đủ chuỗi suy luận, không chỉ hành động cuối cùng. Log "agent đã gọi tool X với tham số Y" là không đủ để điều tra sự cố — cần log cả lý do agent chọn tool đó, thông tin ngữ cảnh nó dựa vào, và các lựa chọn khác nó đã cân nhắc (nếu framework cho phép truy xuất). Không có reasoning trace, mọi sự cố agent đều là hộp đen vĩnh viễn.
Whitelist tool phải là allow-list tường minh (deny-by-default), không phải block-list các tool bị cấm. Agent chỉ được gọi những gì đã được liệt kê rõ ràng; bất kỳ tool mới nào được thêm vào hệ thống mặc định KHÔNG khả dụng cho agent cho tới khi được review và cấp quyền tường minh — đảo ngược thứ tự này (mặc định cho phép, chặn dần từng trường hợp phát hiện) là cách chắc chắn nhất để một tool nguy hiểm lọt qua trước khi ai đó nhận ra.
Approval gate phải có ngưỡng rủi ro rõ ràng để tránh approval fatigue, và phải có đường escalation khi người phê duyệt không phản hồi kịp. Không phải mọi hành động irreversible có cùng mức rủi ro — xóa một bản nháp nội bộ khác xóa một bản ghi khách hàng đã ký hợp đồng. Phân tầng ngưỡng phê duyệt theo mức độ ảnh hưởng thực tế, và định nghĩa rõ điều gì xảy ra nếu không ai phê duyệt trong thời gian hợp lý (timeout mặc định là từ chối, không phải mặc định là cho phép).

Architect's Verdict

Đừng để sự phấn khích về khả năng của LLM đánh lừa bạn tin rằng agentic system cần một tư duy kiến trúc hoàn toàn mới. Nó không cần — nó cần đúng những gì 39 bài trước của series này đã nói đi nói lại dưới các tên gọi khác nhau: giới hạn quyền lực rõ ràng, thiết kế để chịu được thất bại thay vì giả định không có thất bại, và khả năng quan sát để biết chuyện gì đang thực sự xảy ra bên trong hệ thống. Nếu một tổ chức triển khai agent tự trị hoàn toàn cho hành động thật mà không có approval gate và audit trail, họ không đang "đi tiên phong" — họ đang vận hành một hệ thống chưa được kiến trúc hóa, chỉ là được che bởi lớp vỏ ấn tượng của AI.

Và đây cũng là lời kết cho toàn bộ series 40 bài. Chúng ta đã đi qua năm chặng: Phần 1 đặt nền — kiến trúc luôn là đánh đổi, không có lựa chọn đúng tuyệt đối, chỉ có lựa chọn phù hợp với ràng buộc cụ thể. Phần 2 khai triển các pattern cấu trúc — monolith, microservices, event-driven, hexagonal, CQRS — mỗi pattern là một cách phân bổ độ phức tạp khác nhau, không phải một cách xóa bỏ độ phức tạp. Phần 3 bước vào thế giới phân tán — CAP theorem, consistency, caching, sharding — nơi vật lý của mạng và đồng thuận áp đặt giới hạn cứng lên mọi thiết kế. Phần 4 xoay quanh bảo mật và chất lượng — nơi cái giá của một quyết định sai không chỉ là hiệu năng kém mà là breach, mất dữ liệu, mất niềm tin. Và Phần 5, kết thúc ở đây, cho thấy AI không thay đổi luật chơi — nó chỉ đưa ra một thành phần mới, phi xác định và có khả năng hành động thật, buộc ta áp dụng lại đúng những nguyên lý cũ với mức độ nghiêm ngặt cao hơn.

Kiến trúc sư giỏi nhất không phải người biết nhiều pattern nhất, cũng không phải người theo kịp công nghệ mới nhanh nhất. Đó là người, đứng trước bất kỳ quyết định nào — chọn microservices hay monolith, đồng bộ hay bất đồng bộ, cho agent tự trị hay giữ con người trong vòng lặp — biết chính xác mình đang đánh đổi cái gì để lấy cái gì, và biết khi nào cái giá đó đáng trả. Không có kiến trúc hoàn hảo. Chỉ có kiến trúc phù hợp với đúng ràng buộc, đúng thời điểm — và đủ trung thực để thừa nhận nó sẽ cần thay đổi khi ràng buộc đó thay đổi.

🔗 Bài viết liên quan: LLM Gateway & Governance · Zero Trust Architecture

Bài trước: LLM Gateway & Governance