4.1 Tại sao dùng đa agent thay vì đơn agent
Một lưu ý về những gì chương này mô tả và những gì không. Kiến trúc dưới đây — một orchestrator duy nhất, các chuyên gia theo từng lĩnh vực, vòng lặp hai tầng cảm nhận-và-xử lý, cùng ranh giới token hóa — là mẫu mà các triển khai thực tế đang hội tụ về, không phải thiết kế riêng của một nhà cung cấp nào. Sự hội tụ này có thể quan sát được trong thực tiễn độc lập: hệ thống nghiên cứu đa agent đã được Anthropic công bố sử dụng đúng hình dạng orchestrator-và-workers này, còn các agent vận hành đã được Microsoft và AWS đưa ra thị trường được xây dựng từ các chuyên gia phối hợp dưới một tầng điều khiển với thông tin xác thực có phạm vi và quyền tối thiểu cho từng agent. Việc một nền tảng cụ thể — CloudThinker, đơn vị phát hành cuốn sách này — triển khai mẫu đó như thế nào là một câu hỏi riêng, được công bố và trình bày trong §10.3; chương này bàn về hình dạng mà lĩnh vực đang định hình, điều đó đúng bất kể bạn chọn nền tảng nào. Lĩnh vực này đã chuyển dứt khoát từ các agent đơn năng sang các nhóm chuyên gia được điều phối. Gartner ghi nhận mức tăng 1.445% trong số lượng yêu cầu tư vấn về hệ thống đa agent giữa Q1 2024 và Q2 2025 — tín hiệu cầu cao nhất trong danh mục này. Lý do mang tính thực tế, không phải thời thượng:- Chiều sâu vượt chiều rộng. Một chuyên gia Kubernetes với bộ công cụ, prompt và các mẫu đã học dành riêng cho K8s sẽ hoạt động tốt hơn một agent đa năng trên các bài toán K8s — giống như cách các nhóm người làm chuyên môn hóa.
- Giới hạn phạm vi ảnh hưởng. Mỗi chuyên gia chỉ nắm giữ thông tin xác thực mà lĩnh vực của mình yêu cầu. Một agent cơ sở dữ liệu không thể sửa đổi security groups; một agent chi phí không thể xóa bảng.
- Tiến hóa độc lập. Các chuyên gia có thể được nâng cấp, đánh giá và thu hồi một cách độc lập — bài học từ microservices áp dụng cho agent.
- Bàn giao có thể kiểm toán. Việc ủy thác giữa các agent tạo ra dấu vết rõ ràng về ai quyết định gì, điều mà lập luận đơn khối che giấu.
4.2 Kiến trúc tham chiếu
Một nền tảng vận hành agentic trong môi trường thực tế có năm tầng:- Orchestrator (SuperAgent). Một agent điều phối sở hữu lập luận xuyên suốt: nó nhận mục tiêu và sự cố, phân rã chúng, định tuyến công việc cho các chuyên gia, tích hợp phát hiện của họ, quản lý leo thang lên con người, và sở hữu cuộc hội thoại với nhóm vận hành. Mọi thứ đều chảy qua nó; các chuyên gia mở rộng nó thay vì cạnh tranh với nó.
- Agent chuyên gia. Các chuyên gia theo lĩnh vực — thường là cloud engineering, bảo mật, cơ sở dữ liệu và Kubernetes — mỗi người với bộ công cụ, kiến thức chuyên môn và thông tin xác thực có phạm vi riêng. Các tổ chức thêm chuyên gia tùy chỉnh cho các bề mặt của họ: tối ưu chi phí, hiệu suất ứng dụng, nền tảng nội bộ.
- Vòng lặp vận hành. Một pipeline có kỷ luật mà mọi công việc đều chảy qua: Detect → Analyze → Resolve → Validate (DARV). Phát hiện nhận tín hiệu; phân tích tạo ra giả thuyết nguyên nhân gốc rễ có bằng chứng; giải quyết lên kế hoạch và thực thi bản sửa lỗi theo chính sách; xác thực xác nhận kết quả và cung cấp thông tin học. Giai đoạn xác thực là điều phân biệt vận hành agentic với tự động hóa — hệ thống kiểm tra công việc của chính mình.
- Tầng công cụ và tích hợp. Các MCP server và tích hợp gốc exposing các cloud API, nền tảng quan sát, CI/CD, ITSM và các kênh truyền thông (Slack, Teams) với thông tin xác thực quyền tối thiểu cho từng agent.
- Tầng ngữ cảnh và bộ nhớ. Đồ thị cấu trúc mạng, thư viện runbook, bộ nhớ sự cố quá khứ, các quy ước tổ chức và siêu dữ liệu môi trường. Đây là nơi các agent tích lũy: mỗi sự cố được giải quyết làm cho sự cố tiếp theo nhanh hơn.
Hình 4 — Kiến trúc tham chiếu: một orchestrator, các agent chuyên gia, vòng lặp Detect→Analyze→Resolve→Validate, công cụ và bộ nhớ.
4.3 Mẫu xử lý sâu
Các thiết kế agent ngây thơ chạy một lần gọi model cho mỗi cảnh báo và sụp đổ ở quy mô thực tế. Các nền tảng trưởng thành tách hai engine: một engine cảm nhận luôn bật, nhẹ nhàng (một “pulse”) liên tục theo dõi tín hiệu với chi phí thấp, và một engine xử lý nặng kích hoạt lập luận đa bước đầy đủ chỉ khi pulse phát hiện điều gì đó đáng điều tra. Thiết kế hai tầng này là điều làm cho phạm vi bao phủ agentic 24/7 khả thi về mặt kinh tế — lập luận mô hình frontier được dành cho những khoảnh khắc cần đến nó, trong khi nhận thức rẻ tiền chạy liên tục. Tối ưu hóa chi phí agent đã trở thành mối quan tâm kiến trúc hàng đầu vào năm 2026, giống hệt cách tối ưu hóa chi phí đám mây trở nên thiết yếu trong kỷ nguyên microservices.4.4 Bảo vệ dữ liệu trong pipeline
Trong các ngành được quản lý, dữ liệu đo từ xa cực kỳ nhạy cảm: log và truy vấn làm lộ PII của khách hàng, thông tin xác thực và dữ liệu tài khoản. Thực hành tốt nhất đang nổi lên là ranh giới token hóa — một tầng nhận biết PII phát hiện và thay thế các giá trị nhạy cảm bằng các token có thể đảo ngược trước khi bất kỳ dữ liệu nào đến mô hình, và giải token hóa chỉ trong ranh giới tin cậy của khách hàng khi một hành động yêu cầu giá trị thực. Kết hợp với triển khai self-hosted hoặc BYOC (bring-your-own-cloud), điều này cho phép các ngân hàng và tổ chức tài chính áp dụng vận hành agentic mà không có dữ liệu đo từ xa nào rời khỏi vành đai của họ. Chương 6 trình bày đầy đủ câu hỏi về lưu trú dữ liệu và kiểm soát — các mô hình triển khai, chủ quyền, và các câu hỏi cần hỏi nhà cung cấp — một cách sâu sắc.DANH SÁCH KIỂM TRA KIẾN TRÚC
- ✓ Một orchestrator sở hữu lập luận xuyên suốt và leo thang lên con người
- ✓ Các chuyên gia với thông tin xác thực quyền tối thiểu theo từng lĩnh vực
- ✓ Vòng lặp Detect → Analyze → Resolve → Validate rõ ràng với xác thực được tích hợp sẵn
- ✓ Cảm nhận/xử lý hai tầng để kiểm soát chi phí mô hình
- ✓ Token hóa PII trước ranh giới mô hình; tùy chọn BYOC/self-host cho các workload được quản lý
- ✓ Bộ nhớ bền vững để hệ thống tích lũy thay vì bắt đầu từ đầu