Xây dựng một Agent AI sử dụng Giao thức Mô hình Bối cảnh (MCP)

Trong thế giới AI và các mô hình ngôn ngữ lớn (LLM) đang phát triển nhanh chóng, một trong những thách thức lớn nhất là kết nối các mô hình mạnh mẽ này với dữ liệu và công cụ thực tế. Để giải quyết vấn đề này, Anthropic đã giới thiệu Model Context Protocol (MCP) vào năm 2024. Đây là một tiêu chuẩn mở mang tính đột phá, thay đổi cách các ứng dụng AI tương tác với các hệ thống bên ngoài.

Bài viết này sẽ hướng dẫn chi tiết về MCP thông qua một dự án thực tế: xây dựng một AI agent đa công cụ có khả năng lấy dữ liệu thời tiết và tìm kiếm web. Dù bạn là người đam mê AI, nhà phát triển hay đơn giản là tò mò về tương lai của tích hợp AI, bài viết sẽ cung cấp những kiến thức thực tiễn để xây dựng các ứng dụng vận hành bởi MCP.

Tại sao cần MCP?

MCP đóng vai trò là cầu nối giữa các mô hình AI và các công cụ cần thiết, cho phép xây dựng các AI agent phức tạp có thể tương tác mượt mà với thế giới bên ngoài. Bằng cách loại bỏ các rào cản tích hợp và tiêu chuẩn hóa cách chia sẻ ngữ cảnh, MCP giúp AI kết nối tốt hơn, mạnh mẽ hơn và sẵn sàng cho triển khai doanh nghiệp.

**Những vấn đề chính mà MCP giải quyết:**
* **Ngôn ngữ chung:** Thay vì mỗi công cụ có một cách giao tiếp riêng, giờ đây tất cả đều sử dụng một ngôn ngữ chung, giúp việc truyền tải thông tin trở nên dễ dàng.
* **Tích hợp dễ dàng:** Nhà phát triển không còn phải xây dựng các bộ kết nối riêng biệt cho từng ứng dụng; một chuẩn kết nối duy nhất sẽ hoạt động cho mọi công cụ.
* **Truy cập công cụ an toàn:** AI có thể truy cập an toàn vào các công cụ và dữ liệu bên ngoài thông qua một giao thức thống nhất.
* **Khả năng tái sử dụng:** Các công cụ MCP có thể hoạt động với bất kỳ mô hình nào tương thích với MCP, thay vì bị bó buộc vào một mô hình cụ thể.
* **Thúc đẩy đổi mới:** Việc sử dụng tiêu chuẩn chung giúp tránh việc “tái phát minh bánh xe”, từ đó đẩy nhanh tốc độ phát triển và sáng tạo.

Các thành phần chính của MCP

1. **MCP Host:** Là môi trường ứng dụng/agent AI nơi diễn ra tương tác với người dùng (ví dụ: Claude Desktop, IDE hoặc ứng dụng hội thoại). Host điều phối nhiều client, quản lý luồng công việc và quyết định khi nào cần gọi các MCP client.
2. **MCP Client:** Hoạt động bên trong ứng dụng host và quản lý giao tiếp với các MCP Server. Client chịu trách nhiệm thiết lập kết nối, yêu cầu thông tin về khả năng của server, chuyển đổi ý định của mô hình thành các thông điệp giao thức MCP và xử lý phản hồi trả về.
3. **MCP Server:** Cung cấp các khả năng cụ thể và quyền truy cập vào các nguồn dữ liệu/công cụ (như cơ sở dữ liệu, API, hệ thống tệp, CRM, email…). Một server có thể chứa nhiều công cụ. Server sẽ chờ yêu cầu, thực thi chức năng hoặc truy xuất dữ liệu, sau đó trả kết quả có cấu trúc về cho Client.
* **Tools (Công cụ):** Các hàm cho phép LLM thực hiện hành động (ví dụ: tìm kiếm, gọi API).
* **Resources (Tài nguyên):** Dữ liệu hoặc nội dung mà LLM có thể truy cập (tài liệu, dữ liệu người dùng).
* **Prompts (Gợi ý):** Các mẫu hoặc luồng công việc có thể tái sử dụng để hướng dẫn tạo ra đầu ra cụ thể.
4. **Protocol (Giao thức):** Sử dụng JSON-RPC 2.0 để giao tiếp giữa client và server, định nghĩa các loại thông điệp, ngữ nghĩa cho công cụ, tài nguyên, gợi ý và thông báo. Giao thức này cũng quản lý vòng đời kết nối và bảo mật (thường qua OAuth).
5. **Transport Layer (Lớp vận chuyển):** Trừu tượng hóa cách gửi thông điệp. Hai phương thức phổ biến là:
* **STDIO:** Dùng cho thiết lập cục bộ, đồng bộ.
* **SSE (Server-Sent Events):** Dùng cho các server từ xa, hỗ trợ truyền dữ liệu thời gian thực.

Dự án thực hiện

Chúng ta sẽ xây dựng một LangGraph agent với các đặc điểm:
* Tích hợp các công cụ MCP (tìm kiếm web, thời tiết) để thực hiện hành động bên ngoài.
* Sử dụng LLM của OpenAI để điều phối và tạo phản hồi.
* Quản lý hội thoại có trạng thái với luồng công việc có cấu trúc.
* Có khả năng mở rộng với nhiều công cụ hoặc đồ thị (graph) phức tạp hơn.

**Cấu trúc dự án:**

mcp-server/
├── mcp_server.py # Triển khai MCP server (FastMCP)
├── mcp_client.py # MCP client + LangGraph agent
├── mcp-server.ipynb # Notebook để thử nghiệm
├── requirements.txt # Thư viện Python cần thiết
├── .env # Biến môi trường (API keys)
└── README.md
“`

1. Thiết lập & Cài đặt

1. Cài đặt và Thiết lập
* **Clone kho lưu trữ:** `git clone //github.com/alphaiterations/mcp-server`
* **Cài đặt thư viện:** `pip install -r requirements.txt`
* **Cấu hình môi trường:** Tạo file `.env` với `OPEN_AI_KEY` và `SERPER_API_KEY`.

#.env
# Khóa API OpenAI (bắt buộc)
OPEN_AI_KEY =your_openai_api_key_here

# Khóa API Serper (bắt buộc cho tìm kiếm trên web)
SERPER_API_KEY =your_serper_api_key_here

Lấy khóa API:

• OpenAI://platform.openai.com/api-keys
• Serper://serper.dev/(có gói miễn phí)

2. Thiết lập MCP Server
Sử dụng file `mcp_server.py` để tạo một server công cụ MCP chuyên nghiệp với hai tính năng:
* `get_weather`: Trả về thời tiết thời gian thực cho bất kỳ thành phố nào.
* `web_search`: Thực hiện tìm kiếm Google thân thiện với AI.

Cả hai công cụ đều tự động xác thực đầu vào, xử lý lỗi chặt chẽ và trả về JSON có cấu trúc, tối ưu cho việc tích hợp LLM.

**Chi tiết triển khai:**
* **Thư viện:** Sử dụng `fastmcp`, `pydantic`, `requests`.

#mcp_server.py
from fastmcp import FastMCP
from pydantic import BaseModel
import os
import requests
from dotenv import load_dotenv

Thao tác này đọc khóa API từ các biến môi trường. Tham sốOPENWEATHER_API_KEYnày là tùy chọn vì công cụ thời tiết sử dụng dịch vụ dự phòng miễn phí.

#mcp_server.py 
# ---------------- CẤU HÌNH API ---------------- 
SERPER_API_KEY = os.getenv( "SERPER_API_KEY" ) 
OPENWEATHER_API_KEY = os.getenv( "OPENWEATHER_API_KEY" , "" )   # Tùy chọn, sử dụng API thời tiết miễn phí

* **Khởi tạo:** Tạo server bằng lệnh `mcp = FastMCP(“multi-tool-server”)`.
* **Công cụ thời tiết:** Sử dụng API miễn phí từ `wttr.in` để trích xuất các thông tin như nhiệt độ, độ ẩm, tốc độ gió và tình trạng thời tiết, đảm bảo an toàn thông qua khối `try/except`.

#mcp_server.py 
@mcp.tool() 
def  get_weather ( input : WeatherInput ): 
    """Lấy thông tin thời tiết hiện tại của một thành phố bằng WeatherAPI.com (gói miễn phí)""" 
    try : 
        # Sử dụng gói miễn phí của WeatherAPI.com (không cần khóa API cho việc sử dụng cơ bản) 
        # Phương án thay thế: OpenWeatherMap nếu bạn có khóa API
         url = f"//wttr.in/ { input .city} ?format=j1"
         response = requests.get(url, timeout= 5 ) 
        
        if response.status_code == 200 : 
            data = response.json() 
            current = data [ " current_condition " ] [ 0 ] 
            location = data[ " nearest_area" ][ 0 ] 
            
            weather_info = { 
                "location" : f" {location[ 'areaName' ][ 0 ][ 'value' ]} , {location[ 'country' ][ 0 ][ 'value' ]} " , 
                "temperature" : f" {current[ 'temp_C' ]} °C / {current[ 'temp_F' ]} °F" , 
                "condition" : current[ "weatherDesc" ][ 0 ][ "value" ], 
                "humidity" : f" {current[ 'humidity' ]} %" , 
                "wind" : f" {current[ 'windspeedKmph' ]} km/h" , 
                "feels_like" : f" {current[ 'FeelsLikeC' ]} °C"
             } 
            return weather_info 
        else : 
            return { "error" : f"Không thể lấy thông tin thời tiết cho { input .city} " } 
    except Exception as e: 
        return { "error" : f"Lỗi API thời tiết: { str (e)} " }

Công cụ này đăng ký mộtcông cụ tra cứu thời tiếtcó thể truy cập thông qua MCP.

Hành vi chính bên trong:

• Sử dụngwttr.in, một API thời tiết miễn phí (không cần khóa).
• Trích xuất các trường thông tin thân thiện với người dùng như nhiệt độ, độ ẩm, tốc độ gió.
• Gói gọn mọi thứ vào mộttry/exceptkhối để xử lý lỗi một cách an toàn.

Ví dụ:

Đầu vào: {"city": "Mumbai"} 
Đầu ra: { 
    "location": "Mumbai, India", 
    "temperature": "28°C / 82°F", 
    "condition": "Party cloudy", 
    "humidity": "70%", 
    "wind": "15 km/h" 
}

**2.5 Công cụ Tìm kiếm Web**
Đoạn mã này đăng ký một công cụ tìm kiếm tương tự Google thông qua Serper API.

#mcp_server.py 

@mcp.tool() 
def  web_search ( input : WebSearchInput ): 
    """Tìm kiếm trên web bằng API Serper""" 
    if  not SERPER_API_KEY: 
        return { "error" : "SERPER_API_KEY chưa được cấu hình" } 
    
    try : 
        url = "//google.serper.dev/search"
         headers = { 
            "X-API-KEY" : SERPER_API_KEY, 
            "Content-Type" : "application/json"
         } 
        payload = { "q" : input .query, "num" : 5 } 
        
        response = requests.post(url, json=payload, headers=headers, timeout= 10 ) 
        
        if response.status_code == 200 : 
            data = response.json() 
            results = [] 
            
            # Trích xuất kết quả tìm kiếm tự nhiên 
            for item in data.get( "organic" , [])[: 5 ]: 
                results.append({ 
                    "title" : item.get( "title" ), 
                    "link" : item.get( "link" ), 
                    "snippet" : item.get( "snippet" ) 
                }) 
            
            # Bao gồm biểu đồ tri thức nếu có sẵn
             knowledge = data.get( "knowledgeGraph" , {}) 
            
            return { 
                "query" : input.query , 
                "results" : results, 
                "knowledge_graph" : knowledge.get( "description" , "" ) if knowledge else  None
             } 
        else : 
            return { "error" : f"Lỗi API Serper: {response.status_code} " } 
    except Exception as e: 
        return { "error" : f"Lỗi tìm kiếm web: { str (e)} " }

Thao tác này đăng ký mộtcông cụ tìm kiếm tương tự Googleđược hỗ trợ bởi API của Serper.

Điểm nổi bật:

• Kiểm tra tính hợp lệ của khóa API trước khi chạy.
• Gửi yêu cầu POST kèm theo truy vấn và truy xuất tối đa5 kết quả.
• Phân tích: Tiêu đề, Liên kết và Đoạn trích

Nếu có bất kỳ lỗi nào xảy ra, nó sẽ trả về một thông báo lỗi JSON có cấu trúc.

Ví dụ:

Đầu vào : {"query": "tin tức mới nhất về AI" } 
Đầu ra: { 
    "query": "tin tức mới nhất về AI" , 
    "results" : [ 
        { 
            "title": "Đột phá về AI..." , 
            "link" : "//..." , 
            "snippet" : "..."
         } 
    ] 
}

* **Đặc điểm chính:** Kiểm tra sự tồn tại của API key trước khi chạy; gửi yêu cầu POST để lấy tối đa 5 kết quả; trích xuất Tiêu đề, Đường dẫn và Đoạn trích (Snippet). Nếu xảy ra lỗi, hệ thống sẽ trả về thông báo lỗi định dạng JSON.
* **Ví dụ:** Đầu vào `{“query”: “tin tức AI mới nhất”}` sẽ trả về danh sách các kết quả tìm kiếm tương ứng.

**2.6 Điểm khởi chạy Server**
Khối mã này khởi động MCP server khi thực thi script. Khi chạy, các công cụ như `get_weather` và `web_search` có thể được gọi bởi các tác nhân AI, khung làm việc LangChain/LLM hoặc bất kỳ client nào tương thích với MCP.

#mcp_server.py 
if __name__ == "__main__" : 
    print ( "Máy chủ MCP đang chạy..." ) 
    mcp.run()

Khối lệnh này khởi động máy chủ MCP khi tập lệnh được thực thi trực tiếp.
Sau khi chạy, các công cụ nhưget_weathervàweb_searchsẽ có thể được gọi bởi:

• Các tác nhân AI
• Khung LangChain / LLM
• Bất kỳ máy khách nào tương thích với MCP

**3. Thiết lập MCP Client**
**3.1 Cài đặt Môi trường và Thư viện**
Sử dụng các thư viện:
* **LangGraph:** Xây dựng luồng làm việc của agent dựa trên trạng thái (state-based).
* **OpenAI:** Xử lý suy luận và hội thoại của LLM.
* **subprocess/threading:** Khởi chạy và giao tiếp với MCP server.
* **dotenv/os:** Quản lý API key an toàn.

# mcp_client.py

import subprocess, json, sys, threading, time
from langgraph.graph import StateGraph, END
from typing import TypedDict, Any , Dict
from openai import OpenAI
from dotenv import load_dotenv
import os

# Tải các biến môi trường
load_dotenv()

**3.2 Khởi tạo OpenAI Client**
Tạo client OpenAI bằng API key lấy từ biến môi trường.

# mcp_client.py
client = OpenAI(api_key=os.getenv( “OPEN_AI_KEY” ))

**3.3 Khởi chạy MCP Server**
Tạo một tiến trình con (subprocess) để chạy `mcp_server.py`, giúp lộ diện các công cụ đã tạo. Một luồng (thread) riêng được sử dụng để đọc thông báo khởi động mà không làm treo chương trình chính.

# mcp_client.py
server = subprocess.Popen(
[sys.executable, “mcp_server.py” ],
stdin=subprocess.PIPE,
stdout=subprocess.PIPE,
stderr=subprocess.PIPE,
text= True ,
bufsize= 1
)

print ( “Đã kết nối đến máy chủ MCP” )

**3.4 Hỗ trợ Giao tiếp MCP**
Định nghĩa các hàm gửi yêu cầu (`send_request`) và thông báo (`send_notification`) thông qua giao thức JSON-RPC của MCP, sau đó thực hiện khởi tạo kết nối.

**3.5 Gọi Công cụ MCP**
Hàm `call_mcp_tool` cho phép agent gọi bất kỳ công cụ nào đã đăng ký trên server với các tham số cụ thể và trả về kết quả hoặc thông báo lỗi.

**3.6 Đồ thị Trạng thái của Agent (Agent State Graph)**
Định nghĩa lược đồ trạng thái bằng `TypedDict` gồm: tin nhắn (`msg`), kết quả công cụ (`tool_result`) và kết quả cuối cùng (`result`).

**Logic của Agent gồm hai chức năng chính:**

**1. Điều hướng yêu cầu đến công cụ (Routing):**
Sử dụng LLM để phân tích yêu cầu của người dùng và quyết định chọn công cụ nào (`get_weather`, `web_search` hoặc không dùng công cụ nào). LLM sẽ trả về định dạng JSON gồm tên công cụ, tham số và lý do lựa chọn. Nếu chọn công cụ, agent sẽ gọi `call_mcp_tool` để lấy dữ liệu.

**2. Tạo phản hồi ngôn ngữ tự nhiên:**
Hàm này đảm bảo agent trả lời người dùng một cách tự nhiên, dù có sử dụng dữ liệu từ công cụ hay chỉ hội thoại thông thường.
**1. Điều hướng và Tạo phản hồi**

Agent sử dụng LLM để quyết định công cụ nào phù hợp nhất (`get_weather`, `web_search` hoặc không dùng công cụ nào) và trích xuất các tham số cần thiết. Nếu không cần công cụ, agent sẽ tiếp tục cuộc trò chuyện thông thường.

Hàm `generate_response` đảm bảo agent phản hồi một cách tự nhiên. Nếu không có dữ liệu từ công cụ, LLM sẽ trả lời trực tiếp. Nếu có, dữ liệu từ công cụ sẽ được định dạng lại và gửi cho LLM để tổng hợp thành câu trả lời súc tích, thân thiện (dưới 100 chữ).

**2. Xây dựng Luồng công việc với LangGraph**

Luồng hoạt động được thiết lập thông qua `StateGraph` với hai nút chính:
* **Nút Route:** Điểm bắt đầu, quyết định việc sử dụng công cụ.
* **Nút Respond:** Định dạng đầu ra và trả lời người dùng.

Luồng di chuyển: `route` $\rightarrow$ `respond` $\rightarrow$ `END`. Hệ thống cũng hỗ trợ xuất sơ đồ luồng ra file `langgraph_diagram.png` để dễ dàng theo dõi.

**3. Kiểm thử Agent**

Khi chạy file `mcp_client.py`, agent xử lý các truy vấn như sau:
* **Truy vấn thời tiết tại Mumbai:** Agent nhận diện nhu cầu, gọi công cụ `get_weather` và trả về thông tin chi tiết về nhiệt độ, độ ẩm và tình trạng không khí.
* **Tìm kiếm tin tức AI mới nhất:** Agent sử dụng công cụ `web_search` để tổng hợp các tin tức cập nhật từ các nguồn uy tín như SoftBank, MIT và TechCrunch.

**Sơ đồ luồng hoạt động:**
`USER INPUT` $\rightarrow$ `LANGGRAPH AGENT (Routing $\rightarrow$ Response)` $\rightarrow$ `MCP CLIENT (JSON-RPC)` $\rightarrow$ `MCP SERVER (Tools: Weather/Search)` $\rightarrow$ `EXTERNAL APIs`.

**Kết luận**

Hướng dẫn này đã xây dựng một MCP server đa công cụ, cho phép tra cứu thời tiết thời gian thực và tìm kiếm web. Việc sử dụng FastMCP kết hợp với Pydantic giúp tạo ra các công cụ mô-đun, có khả năng xác thực đầu vào chặt chẽ và xử lý lỗi hiệu quả.

Mô hình này mang lại ba lợi ích chính:
* **Khả năng mở rộng:** Dễ dàng thêm công cụ mới mà không ảnh hưởng đến các công cụ hiện có.
* **Độ an toàn:** Đầu vào có cấu trúc giúp ngăn chặn các yêu cầu không hợp lệ.
* **Sự linh hoạt:** Có thể thay đổi API hoặc nguồn dữ liệu mà không cần thay đổi giao diện.

Đây là nền tảng lý tưởng để phát triển các trợ lý AI, chatbot hoặc agent nghiên cứu thông minh và linh hoạt hơn.

Tham khảo: medium.com

Cấu trúc các tác nhân, kỹ năng và MCP

Các tác nhân AI đang ngày càng mạnh mẽ hơn, nhưng chỉ sức mạnh thôi thì chưa đủ để làm cho hệ thống tác nhân trở nên đáng tin cậy.

Một mô hình có thể suy luận tốt nhưng vẫn hoạt động khó đoán nếu kiến ​​trúc xung quanh lộn xộn. Nó có thể gọi các công cụ, truy xuất tài liệu, tạo kế hoạch và tạo ra kết quả đầu ra, nhưng nếu không có ranh giới rõ ràng, hệ thống sẽ nhanh chóng trở nên khó kiểm toán, khó tái sử dụng và tiềm ẩn rủi ro đối với dữ liệu nhạy cảm.

Đó là lý do tại sao kiến ​​trúc tác nhân hiện đại cần nhiều hơn một lời nhắc thông minh.

Nó cần có cấu trúc.

Hình ảnh này thể hiện một ý tưởng quan trọng: các hệ thống tác nhân mạnh mẽ được xây dựng bằng cách tách biệtcác kỹ năng,tác nhânvàcác kết nối MCPthành các lớp riêng biệt. Mỗi lớp có một trách nhiệm rõ ràng. Mỗi lớp phát triển độc lập. Và quan trọng nhất, mỗi lớp làm giảm khả năng một lỗi lan rộng ra toàn bộ hệ thống.

Nói cách khác, kiến ​​trúc tác nhân tuyệt vời không chỉ đơn thuần là làm cho mô hình thông minh hơn. Nó còn là việc làm cho hệ thống xung quanh mô hình trở nên dễ dự đoán, có thể kiểm toán và an toàn.

Kiến trúc ba lớp của hệ thống tác nhân

Một hệ thống trợ lý ảo được thiết kế tốt không nên chỉ là một hệ thống nhắc nhở khổng lồ cố gắng thực hiện mọi việc.

Cách tiếp cận đó có thể hiệu quả trong bản demo, nhưng sẽ trở nên dễ gặp lỗi trong môi trường sản xuất. Mô hình tốt hơn là tách hệ thống thành ba lớp: kỹ năng , tác nhân và bộ kết nối MCP .

Kỹ năng thể hiện kiến ​​thức chuyên môn có thể tái sử dụng. Chúng hướng dẫn hệ thống cách thực hiện một nhiệm vụ một cách hiệu quả. Một kỹ năng có thể giải thích cách tóm tắt hợp đồng pháp lý, phân loại phiếu hỗ trợ, xem xét mã nguồn, tạo báo cáo tuân thủ hoặc đánh giá vấn đề chất lượng dữ liệu. Ý tưởng cốt lõi là một kỹ năng phải có thể tái sử dụng và kết hợp được. Nó không nên bị ràng buộc chặt chẽ với một tác nhân cụ thể hoặc một quy trình làm việc cụ thể.

Các tác nhân (agent) nằm trên các kỹ năng. Chúng là những người điều phối quy trình làm việc. Một tác nhân quyết định điều gì cần xảy ra, khi nào nó nên xảy ra và theo thứ tự nào. Tác nhân có định danh, sản phẩm đầu ra, quy tắc quy trình và các giới hạn. Nó có thể sử dụng nhiều kỹ năng để hoàn thành một nhiệm vụ, nhưng nó không nên giữ kín tất cả kiến ​​thức bên trong mình. Nhiệm vụ của nó là điều phối, chứ không phải tích trữ mọi chỉ dẫn.

Các trình kết nối MCP nằm bên dưới các tác nhân. Chúng cung cấp quyền truy cập tiêu chuẩn hóa vào các hệ thống bên ngoài như cơ sở dữ liệu, kho lưu trữ tài liệu, API, dịch vụ đám mây, hệ thống tệp hoặc các công cụ nội bộ. Trình kết nối MCP giữ cho logic kết nối tách biệt khỏi các tác nhân và kỹ năng. Điều này rất quan trọng vì quyền truy cập bên ngoài cần được quản lý tập trung, có thể hoán đổi và có thể kiểm toán.

Sự tách biệt các mối quan tâm này chính là điều giúp cho các hệ thống tác nhân dễ bảo trì. Kỹ năng có thể được cải thiện mà không cần thay đổi các bộ kết nối. Các bộ kết nối có thể được cập nhật mà không cần viết lại tác nhân. Các tác nhân có thể được thiết kế lại mà không cần sao chép kiến ​​thức ở khắp mọi nơi.

Đó chính là nền tảng của kiến ​​trúc tác nhân có khả năng mở rộng.

Kỹ năng là một trong những khía cạnh bị đánh giá thấp nhất trong thiết kế nhân vật.

Nhiều nhóm đưa quá nhiều thao tác hành vi trực tiếp vào lời nhắc của tác nhân. Họ viết những hướng dẫn dài dòng bên trong mỗi tác nhân, lặp lại cùng một logic trên nhiều tác nhân và dần dần tạo ra sự sai lệch. Một tác nhân học được quy trình cập nhật, tác nhân khác vẫn giữ phiên bản cũ, và đột nhiên hệ thống hoạt động không nhất quán.

Một cách tiếp cận tốt hơn là tạo ra các kỹ năng một lần và đồng bộ hóa chúng ở mọi nơi.

Một kỹ năng nên đóng vai trò như một nguồn kiến ​​thức chuẩn mực về nhiệm vụ. Nếu tổ chức của bạn có một quy trình chuẩn để xem xét các yêu cầu kéo (pull request), thì quy trình đó nên được tích hợp trong một kỹ năng có thể tái sử dụng. Nếu bạn có một quy trình chuẩn để tạo ra các bản tóm tắt dành cho khách hàng, thì quy trình đó cũng nên được tích hợp trong một kỹ năng. Nếu quy trình thay đổi, chỉ cần cập nhật kỹ năng một lần và mọi nhân viên đều có thể hưởng lợi.

Hình ảnh này cũng nhấn mạnh rằng kỹ năng nên được giữ ở dạng thụ động. Điều này tuy tinh tế nhưng rất quan trọng.

Một kỹ năng nên giải thích cách thực hiện một việc gì đó, chứ không phải quyết định khi nào thực hiện nó. Nó không nên chứa logic trình tự, các quyết định điều phối, hoặc quyền truy cập công cụ ẩn. Những trách nhiệm đó thuộc về lớp tác nhân.

Điều này giúp các kỹ năng được giữ nguyên vẹn. Chúng trở thành những khối xây dựng có thể tái sử dụng thay vì những “tác nhân” thu nhỏ giả vờ làm hướng dẫn.

Một số hệ thống cũng cung cấp các kỹ năng ở chế độ “bộ công cụ”, nơi con người hoặc các tác nhân có thể trực tiếp gọi các lệnh, chẳng hạn như so sánh, phân loại tài liệu hoặc phân tích thu nhập. Điều đó có thể rất mạnh mẽ, nhưng nguyên tắc vẫn không thay đổi: kỹ năng phải có tính mô-đun, dễ hiểu và có thể tái sử dụng.

Kỹ năng tốt giúp giảm sự lặp lại. Kỹ năng xuất sắc giúp ngăn ngừa sự thay đổi trong thiết kế kiến ​​trúc.

Các đại lý nên xác định rõ kết quả cần đạt được, chứ không phải những mục tiêu mơ hồ

Lớp tác nhân là nơi mà nhiều hệ thống thành công hay thất bại.

Một lời nhắc tự động yếu sẽ nói đại loại như, “Hãy giúp người dùng phân tích thông tin này.” Nghe có vẻ hợp lý, nhưng nó quá mơ hồ. Kết quả cuối cùng nên trông như thế nào? Cần bao gồm những bằng chứng nào? Những công cụ nào được cho phép sử dụng? Hệ thống nên làm gì nếu có điều gì đó không chắc chắn? Khi nào nó nên dừng lại và yêu cầu sự chấp thuận của con người?

Một người đại diện giỏi sẽ xác định rõ ràng các kết quả cần đạt được.

Thay vì giao cho tác nhân một nhiệm vụ chung chung, hãy xác định rõ đầu ra mong muốn. Tác nhân cần biết liệu nó đang tạo ra một báo cáo, một tệp JSON, một bản vá mã, một bản tóm tắt điều tra, một đánh giá rủi ro, hay một khuyến nghị cần được con người xem xét.

Điều này rất quan trọng vì các tác nhân không chỉ tạo ra văn bản. Họ còn điều phối công việc.

Một lời nhắc cho tác nhân tốt thường bao gồm thông tin nhận dạng, sản phẩm đầu ra, quy trình làm việc và các giới hạn an toàn. Thông tin nhận dạng cho tác nhân biết vai trò của nó. Sản phẩm đầu ra xác định những gì nó phải tạo ra. Quy trình làm việc mô tả cách nó nên tiến hành. Giới hạn an toàn xác định những gì nó không bao giờ được làm.

Những nhân viên giỏi nhất không phải là những người có hướng dẫn dài dòng nhất. Họ là những người có trách nhiệm rõ ràng nhất.

Một tác nhân nên xây dựng quy trình làm việc từ các kỹ năng được đặt tên. Nó nên làm rõ các mối quan hệ phụ thuộc. Nó nên để lại dấu vết kiểm toán. Nếu nó sử dụng kỹ năng truy xuất tài liệu, kỹ năng kiểm tra cơ sở dữ liệu và kỹ năng tạo báo cáo cuối cùng, thì đường dẫn đó phải được hiển thị.

Thiết kế cho nhân viên hỗ trợ không chỉ đơn thuần là viết lời nhắc. Đó là thiết kế quy trình làm việc.

Lan can bảo vệ là bắt buộc

Các hệ thống tác nhân trở nên rủi ro khi chúng được phép hoạt động mà không có giới hạn.

Hình ảnh này nêu bật một số nguyên tắc bất khả xâm phạm, và đó chính xác là những quy tắc mà các hệ thống sản xuất cần.

Nhân viên không nên ghi trực tiếp vào hệ thống lưu trữ dữ liệu trừ khi quy trình làm việc cho phép rõ ràng. Họ không nên liên lạc với bên ngoài mà không có sự chấp thuận. Họ nên xác minh nguồn gốc các yêu cầu và gắn cờ bất kỳ yêu cầu nào không có nguồn gốc. Họ nên tạm dừng ở các bước phê duyệt của con người khi các hành động nhạy cảm.

Những quy tắc này có thể gây cảm giác hạn chế, nhưng chính chúng là điều làm cho các tác nhân trở nên hữu dụng trong môi trường thực tế.

Một tác nhân hoàn toàn tự động có thể đọc các tài liệu nhạy cảm, gọi API bên ngoài, cập nhật cơ sở dữ liệu và gửi tin nhắn mà không cần giám sát không phải là một công cụ tăng năng suất. Nó là một bề mặt rủi ro.

Các hệ thống tác nhân tốt hiểu được sự khác biệt giữa suy luận và hành động. Suy luận có thể rộng, còn hành động phải được kiểm soát.

Đó là lý do tại sao các cổng phê duyệt lại quan trọng. Nếu một tác nhân sắp sửa sửa đổi dữ liệu sản xuất, gửi thông báo bên ngoài, cập nhật bản ghi hoặc xuất bản một thành phần, hệ thống nên tạm dừng và yêu cầu xem xét.

Mô hình càng mạnh mẽ thì lan can bảo vệ càng quan trọng.

Bảo mật thông qua cách ly nhiều tầng

Một trong những ý tưởng nổi bật nhất trong hình ảnh này là sự phân tách theo từng tầng .

Thay vì cấp quyền truy cập cho mọi thứ cho một người duy nhất, quy trình làm việc được chia thành các vai trò chuyên biệt: người đọc, người điều phối, người phê bình và người giải quyết.

Trình đọc này xử lý các tài liệu không đáng tin cậy. Nó có thể kiểm tra tệp, tìm kiếm nội dung và trích xuất thông tin liên quan, nhưng không có quyền truy cập MCP và không có công cụ ghi. Điều này hạn chế thiệt hại nếu tài liệu nguồn chứa các chỉ thị độc hại hoặc các nỗ lực chèn mã độc.

Bộ điều phối đảm nhiệm việc điều phối quy trình làm việc. Nó quyết định điều gì sẽ xảy ra tiếp theo, nhưng nó không trực tiếp đọc các tệp bên ngoài không đáng tin cậy. Nó có thể có quyền truy cập MCP chỉ đọc đáng tin cậy, nhưng vai trò của nó là quản lý luồng, chứ không phải tự mình thực hiện mọi hành động.

Nhà phê bình độc lập xác minh các phát hiện. Vai trò này rất quan trọng vì các tác nhân có thể mắc những sai lầm tự tin. Nhà phê bình giúp phân tách giữa quá trình tạo ra kết quả và quá trình xác thực.

Trình phân giải tạo ra sản phẩm đầu ra cuối cùng. Nó có thể có quyền ghi khi cần thiết, nhưng không trực tiếp truy cập vào nội dung bên ngoài không đáng tin cậy hoặc các trình kết nối MCP.

Cấu trúc này tuân theo một nguyên tắc đơn giản nhưng mạnh mẽ: từ chối các công cụ theo mặc định và chỉ cấp quyền tối thiểu cần thiết .

Đó là nguyên tắc đặc quyền tối thiểu được áp dụng cho các tác nhân trí tuệ nhân tạo.

Trong bảo mật phần mềm truyền thống, chúng ta đã hiểu rõ ý tưởng này. Một dịch vụ không nên có quyền ghi vào cơ sở dữ liệu trừ khi cần thiết. Người dùng không nên có quyền quản trị mặc định. Mã thông báo API nên được giới hạn phạm vi hẹp.

Các hệ thống tác nhân cũng cần có sự kỷ luật tương tự.

Thực tế, họ còn cần nó hơn nữa.

Tại sao các đầu nối MCP nên được tập trung hóa

Các bộ kết nối MCP đang trở thành một phần quan trọng của kiến ​​trúc AI hiện đại vì chúng chuẩn hóa cách các tác nhân truy cập vào các hệ thống bên ngoài.

Nhưng nếu mỗi tác nhân tự định nghĩa logic kết nối riêng của mình, thì sẽ dẫn đến hỗn loạn.

URL thay đổi. Xác thực thay đổi. Phạm vi quyền hạn thay đổi. Yêu cầu kiểm toán thay đổi. Nếu những chi tiết này được sao chép giữa các tác nhân và kỹ năng, việc bảo trì sẽ trở nên khó khăn và bảo mật trở nên không nhất quán.

Cách tiếp cận tốt hơn là định nghĩa các trình kết nối một lần trong cấu hình dùng chung.

Một bộ kết nối có thể phục vụ nhiều người dùng. Nếu điểm cuối API thay đổi, bạn chỉ cần cập nhật ở một nơi duy nhất. Nếu thông tin xác thực thay đổi, lớp kết nối sẽ xử lý việc đó một cách tập trung. Nếu cần kiểm toán quyền truy cập, hệ thống có một điểm kiểm soát duy nhất.

Điều này đặc biệt quan trọng đối với các hệ thống nhạy cảm như cơ sở dữ liệu, bảng điều khiển nội bộ, kho lưu trữ tài liệu và cơ sở hạ tầng đám mây.

Hình ảnh minh họa một mô hình truy cập hữu ích: trình đọc không có MCP, trình điều phối nhận được MCP chỉ đọc đáng tin cậy, và trình phân giải không có MCP. Chính sách kết nối dành riêng cho từng vai trò như vậy giúp ngăn ngừa việc tiếp xúc không cần thiết.

MCP không nên trở thành lối tắt để cấp cho mọi nhân viên quyền truy cập vào mọi thứ.

Nó nên trở thành lớp truy cập dữ liệu có kỷ luật cho các hệ thống tác nhân.

Cấu trúc giúp các tác nhân có khả năng mở rộng