Giới thiệu

Bài viết này được viết như một phần trong dự án của tôi tham gia Hackathon GKE Turns 10. Thách thức là xây dựng một ứng dụng microservices tiêu chuẩn, Online Boutique, và "tăng cường" nó với AI mà không cần thay đổi bất kỳ dòng mã nào của mã gốc. Mục tiêu là xây dựng một "bộ não" bên ngoài, container hóa, có thể thêm một lớp trí tuệ mới.

Câu trả lời của tôi? Tôi đã xây dựng một đội ngũ AI tự động hoàn toàn, đa tác nhân trên Google Kubernetes Engine (GKE). Dưới đây là cách tôi thực hiện và cách mà các tính năng của GKE là rất quan trọng để làm cho kiến trúc phức tạp này hoạt động.

Nền Tảng: GKE và Khám Phá Dịch Vụ

Toàn bộ dự án phụ thuộc vào nhiều microservices mới (tác nhân, máy chủ, giao diện người dùng) giao tiếp với nhau và với ứng dụng Online Boutique gốc. Khám phá dịch vụ tích hợp của GKE khiến điều này trở nên cực kỳ đơn giản.

Bằng cách định nghĩa một Service trong Kubernetes, tôi có thể gán cho mỗi thành phần một tên DNS ổn định. Ví dụ, Service của Tác nhân Marketing trông như sau:

apiVersion: v1
kind: Service
metadata:
  name: marketing-campaigner-service
spec:
  selector:
    app: marketing-campaigner-agent
  ports:
  - port: 8080
    targetPort: 8080

Cấu hình YAML đơn giản này cho phép tác nhân phân tích kinh doanh của tôi có thể gửi tin nhắn A2A một cách đáng tin cậy chỉ bằng cách gọi http://marketing-campaigner-service:8080/goal. GKE quản lý tất cả các mạng phức tạp ở phía sau.

Các "Giác Quan": Một Máy Chủ MCP với Sidecar Bảo Mật

Thành phần đầu tiên tôi xây dựng là một Máy Chủ MCP để hoạt động như "giác quan" của hệ thống. Nó tiếp nhận các sự kiện "thêm vào giỏ hàng" theo thời gian thực từ frontend-proxy của ứng dụng. Để kết nối an toàn với cơ sở dữ liệu Cloud SQL, tôi đã sử dụng Cloud SQL Auth Proxy chạy như một container sidecar, một thực tiễn tốt được GKE hỗ trợ dễ dàng nhờ kiến trúc pod của nó.

spec:
  serviceAccountName: mcp-toolbox-sa
  containers:
  - name: server # Ứng dụng Python của tôi
    image: ...
    env:
      - name: DB_HOST
        value: "127.0.0.1"
  - name: cloud-sql-proxy # Sidecar
    image: gcr.io/cloud-sql-connectors/cloud-sql-proxy:2.8.0
    args: ["..."]

"Nhà Chiến Lược": Một Tác Nhân Được Lập Lịch với CronJob

Tác nhân phân tích kinh doanh của tôi không cần hoạt động 24/7; nó chỉ cần thức dậy định kỳ để kiểm tra xu hướng. Một CronJob của GKE là công cụ hoàn hảo cho điều này. Với một biểu thức schedule đơn giản, tôi có thể định nghĩa vòng lặp "giác quan-nghĩ-hành động" này để chạy tự động.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: business-analyst-agent
spec:
  # Chạy mỗi 5 phút
  schedule: "*/5 * * * *"
  jobTemplate:

Sau khi triển khai, GKE sẽ lo phần còn lại, tự động khởi động và tắt pods theo lịch trình. Việc theo dõi các pods chuyển sang trạng thái Completed chứng minh rằng vòng lặp tự động đang hoạt động.

"Người Thực Thi": Hợp Tác Tác Nhân qua A2A

Khi tác nhân phân tích tìm thấy một xu hướng, nó ủy thác một nhiệm vụ cho tác nhân Marketing. Giao tiếp Agent2Agent (A2A) này chỉ là một yêu cầu POST đơn giản, được thực hiện nhờ Service GKE mà chúng tôi đã định nghĩa trước đó.

def send_a2a_goal(self, product_name):
    # GKE DNS giải quyết 'marketing-campaigner-service' thành IP pod đúng
    self.marketing_agent_url = "http://marketing-campaigner-service:8080/goal"

    a2a_message = {
        "goal": "create_promotional_content",
        "payload": { "product_name": product_name }
    }
    requests.post(self.marketing_agent_url, json=a2a_message)

Tác nhân Marketing, chạy trong Deployment của riêng nó, chỉ cần lắng nghe các yêu cầu đến này và thực hiện logic của riêng nó.

Tác Nhân 3: Chuyên Gia AI (A2A & MCP Client)

Đây là bước tham vọng nhất. Tôi đã thay thế recommendationservice gốc bằng Tác nhân Gợi Ý của riêng tôi, được hỗ trợ bằng AI. Tác nhân này là một ví dụ điển hình về thiết kế tác nhân nâng cao, sử dụng cả hợp tác A2A và mẫu MCP. Nó hoạt động như một máy chủ gRPC, và khi nhận được yêu cầu từ giao diện người dùng:

• Nó thực hiện một cuộc gọi A2A tới tác nhân Marketing để hỏi sản phẩm nào đang được khuyến mãi, cho thấy sự hợp tác tác nhân theo thời gian thực.
• Nó hoạt động như một MCP Client, sử dụng dịch vụ productcatalogservice của ứng dụng như một "công cụ" trực tiếp (thông qua gRPC) để lấy ngữ cảnh phong phú, có căn cứ về các mặt hàng trong giỏ hàng của người dùng.
• Nó sử dụng Gemini để tạo ra các gợi ý thông minh dựa trên tất cả ngữ cảnh kết hợp này.

# recommendation-agent/agent.py
def ListRecommendations(self, request, context):
    # Hợp tác A2A: Hỏi một tác nhân khác về trạng thái của nó
    promoted_product = requests.get(MARKETING_AGENT_URL).json().get('product_name')

    # Hành động MCP Client (Sử dụng công cụ): Lấy dữ liệu từ ứng dụng
    cart_product_names = [self.get_product_name_from_id(pid) for pid in request.product_ids]

    # Nghĩ với Gemini sử dụng ngữ cảnh phong phú
    prompt = f"Giỏ hàng của người dùng: {cart_product_names}, Sản phẩm được khuyến mãi: '{promoted_product}'..."
    response = model.generate_content(prompt)
    # ...

Tác Nhân 4: Trợ Lý Đàm Thoại (MCP Client Được Căn Cứ)

Để thêm một yếu tố tương tác, tôi đã xây dựng một Tác nhân Hỗ trợ Khách hàng. Tác nhân này là một ví dụ điển hình về MCP Client được thiết kế để phục vụ người dùng và không sử dụng A2A. Mục tiêu duy nhất của nó là giúp người dùng. Nó sử dụng dịch vụ productcatalogservice của ứng dụng như một công cụ (thông qua gRPC) để lấy dữ liệu theo thời gian thực. Quan trọng là, nó được "căn cứ" một cách rõ ràng—được chỉ định chỉ trả lời câu hỏi dựa trên dữ liệu mà nó thu thập. Điều này ngăn AI tạo ra thông tin sai lệch và xây dựng niềm tin cho người dùng.

final_prompt = f"""
Trả lời câu hỏi của người dùng chỉ DỰA TRÊN dữ liệu sản phẩm đã cung cấp. Đừng tạo ra thông tin.

Câu hỏi của người dùng: "{question}"
Dữ liệu sản phẩm: "{product_context}"
"""
final_response = model.generate_content(final_prompt)

Yếu Tố Ấn Tượng: Giao Diện Công Khai với LoadBalancer

Để hoàn thành bài nộp, tôi cần các URL công khai cho ban giám khảo. GKE làm điều này trở nên cực kỳ đơn giản. Bằng cách thay đổi một dòng trong định nghĩa Service của giao diện điều khiển của tôi thành type: LoadBalancer, GKE tự động cung cấp một địa chỉ IP công khai.

apiVersion: v1
kind: Service
metadata:
  name: dashboard-ui-service
spec:
  type: LoadBalancer
  selector:
    app: dashboard-ui
  ports:
  - port: 80
    targetPort: 8080

Điều này cho phép tôi xây dựng và công khai hai thành phần hướng tới người dùng: Bảng điều khiển Mission Control và một chatbot Hỗ trợ Khách hàng tương tác.

Bảng Điều Khiển Chính

Chat Hỗ Trợ Khách Hàng

Tại Sao GKE Là Lựa Chọn Hoàn Hảo

Xây dựng hệ thống phức tạp này trong một khoảng thời gian ngắn như vậy sẽ không thể thực hiện được nếu không có GKE. Nó đã giúp quá trình bằng cách cung cấp:

• Hạ Tầng Khai Báo: Tôi có thể định nghĩa toàn bộ hệ thống của mình trong một vài tệp YAML.
• Khám Phá Dịch Vụ Liền Mạch: DNS nội bộ của GKE cho phép các tác nhân của tôi tìm và giao tiếp với nhau một cách dễ dàng.
• Công Cụ Phù Hợp Cho Công Việc: Sử dụng CronJobs cho các tác vụ định kỳ và Deployments cho các dịch vụ 24/7 là điều rất đơn giản.
• Khả Năng Chịu Đựng Tích Hợp: GKE đảm bảo rằng nếu một pod gặp sự cố, nó sẽ tự động khởi động lại.
• Khả Năng Mở Rộng Dễ Dàng: Nếu các tác nhân của tôi chịu tải nặng, việc mở rộng lên sẽ đơn giản như thay đổi replicas: 1 thành replicas: 5.

GKE thực sự là nền tảng tối ưu để xây dựng và chạy thế hệ AI tiếp theo.

Kiến Trúc Cuối Cùng

🚀 Demo Trực Tiếp & Kho Lưu Trữ Mã

Kho Lưu Trữ Mã: https://github.com/ki3ani/thanos

Demo Trực Tiếp: Bảng Điều Khiển Mission Control: http://34.9.104.63/

Demo Trực Tiếp: Chatbot Hỗ Trợ Khách Hàng AI: http://34.123.10.111/