MCP không phải là giao tiếp một chiều — Dưới đây là 5 cách máy chủ của bạn phản hồi

Mọi người đều giải thích cách gọi một máy chủ MCP. Không ai giải thích điều gì xảy ra khi máy chủ gọi lại. Khoảng trống trong hướng dẫn mà không ai nói đến Mọi hướng dẫn về MCP đều đề cập đến cùng một điều. Máy khách gọi một công cụ, máy chủ chạy nó, kết quả trả về. Phần đó dễ dạy và dễ học. Điều mà không ai đề cập là những gì máy chủ có thể tự làm. Trong quá trình thực thi, nó có thể gửi thông báo nhật ký, truyền tiến độ, dừng và hỏi người dùng điều gì đó, yêu cầu LLM (mô hình ngôn ngữ lớn) suy luận về một kết quả, đẩy thông báo khi dữ liệu thay đổi. Không có điều nào trong số đó yêu cầu máy khách phải hỏi trước. Đó là phần mà bài viết này đề cập. Quan niệm sai lầm: MCP là một chiều Mọi bài viết tôi đọc đều vẽ cùng một sơ đồ. Máy khách gọi máy chủ, máy chủ trả về kết quả. Tôi đã tự vẽ nó trên bảng trắng khi tôi lên kế hoạch kiến trúc tác nhân của mình. Vấn đề là sơ đồ đó khiến tôi xây dựng sai thứ. Tôi đã thiết kế toàn bộ giao diện người dùng tác nhân của mình dựa trên mô hình tư duy yêu cầu-phản hồi, giống như tác nhân gọi một công cụ, chờ hoặc chạy một lệnh gọi công cụ khác một cách không đồng bộ, nhận được câu trả lời. Không có khả năng hiển thị những gì đang xảy ra ở giữa. Người dùng chỉ thấy một biểu tượng quay và hy vọng điều tốt nhất. Khi tôi phát hiện ra rằng máy chủ có thể phản hồi – truyền tiến độ, gửi thông báo, yêu cầu máy khách thực hiện một lệnh gọi LLM – tôi đã quay lại và thiết kế lại các phần của giao diện người dùng dựa trên những khả năng đó. Giờ đây, người dùng có thể thấy tác nhân đang làm gì trong thời gian thực. Việc thực thi công cụ trở nên minh bạch thay vì bí ẩn. Mức độ sử dụng tăng lên. Các câu hỏi hỗ trợ về "nó có bị kẹt không?" đã biến mất. Đó không phải là một khám phá tính năng nhỏ. Đó là một quyết định kiến trúc. Và nó bắt đầu bằng việc hiểu rằng giao tiếp MCP không chỉ diễn ra theo một hướng. MCP là hai chiều: máy chủ không chỉ phản hồi mà còn khởi tạo. Ví dụ đang chạy: hr_server Viết định nghĩa công cụ là phần dễ dàng. Bộ trang trí được bật, hàm chạy, nó hoạt động. Điều tốn thời gian là mọi thứ sau đó – tác nhân cụ thể nào nên thấy công cụ nào, làm thế nào để chúng nhận biết trạng thái hội thoại, làm thế nào để thực thi các lược đồ đầu ra nghiêm ngặt để các hệ thống hạ nguồn không bị hỏng. Đó là nơi phần lớn công việc thực sự diễn ra. hr_server là máy chủ được sử dụng trong suốt bài viết này. Nó kết nối một tác nhân AI với cơ sở dữ liệu nhân sự của công ty. Ba công cụ thực hiện bốn cơ chế đầu tiên: get_employee – đọc một bản ghi nhân viên duy nhất theo ID. Chỉ đọc, an toàn để gọi nhiều lần. update_salary – cập nhật mức lương cơ bản. Vĩnh viễn. Yêu cầu xác nhận rõ ràng của người dùng. get_department_report – truy vấn phân tích chạy dài. Công cụ làm cho việc truyền dữ liệu trở nên đáng hiểu. Cơ chế thứ năm hoàn toàn tách rời khỏi hr_server – nó xem xét điều gì xảy ra khi một tài liệu sống được kết nối với một đường ống RAG (truy xuất tăng cường tạo sinh) được sửa đổi. Các công cụ không phải là câu chuyện ở đó. Chuỗi thông báo mới là. Một đối tượng xuất hiện trong mọi cơ chế – đối tượng Context, hay ctx. FastMCP tự động đưa nó vào bất kỳ hàm công cụ nào khai báo nó là một tham số. Không cần khởi tạo, không cần truyền thủ công – chỉ cần khai báo nó và nó sẽ ở đó. Điều nó cung cấp là quyền truy cập trực tiếp vào máy khách trong quá trình thực thi, không phải sau khi công cụ kết thúc mà là trong quá trình. Mọi cơ chế trong bài viết này chỉ là một phương thức khác trên đối tượng này. # hr_server.py — thiết lập cơ bản from fastmcp import FastMCP mcp = FastMCP( name="hr_server", instructions=( "Use this server to query and manage employee records. " "Always confirm with the user before modifying any data." ) ) Cơ chế 1: Thông báo nhật ký – Máy chủ tự tường thuật Điều đầu tiên tôi gõ khi tìm thấy ctx.info() là "Đang truy xuất dữ liệu và hiển thị biểu đồ". Không phải vì nó trang nhã – mà vì tôi chỉ cần biết công cụ có thực sự đang chạy hay không. Nó đã chạy. Vấn đề được giải quyết chỉ trong một dòng. Đó là mục đích của ctx.info(). Nó cho phép máy chủ tường thuật những gì nó đang làm trong khi nó đang làm – không phải sau đó, không phải trong một tệp nhật ký mà bạn phải tìm kiếm sau này, mà là trực tiếp, trở lại máy khách, giữa quá trình thực thi. Và đó không chỉ là ctx.info(). Có ba cấp độ: # Thông báo – công cụ đang chạy, đây là những gì nó đang làm await ctx.info("Đang tìm kiếm hồ sơ nhân viên...") # Đánh dấu điều đáng chú ý – quá trình thực thi tiếp tục await ctx.warning("Đã tìm thấy hồ sơ nhân viên nhưng trạng thái đã chấm dứt. Dữ liệu có thể đã cũ.") # Báo hiệu dừng cứng – bạn kiểm soát những gì xảy ra tiếp theo await ctx.error("Mức lương vượt quá mức tối đa theo chính sách là 500.000 USD. Cập nhật bị từ chối.") Ba dòng. Đó là toàn bộ giao diện API cho các thông báo nhật ký. ctx.info() – hãy sử dụng nó một cách rộng rãi. Mỗi bước không tầm thường trong một công cụ đều xứng đáng có một thông báo. Người dùng và tác nhân không bao giờ nên nhìn chằm chằm vào sự im lặng mà tự hỏi liệu có điều gì đó đã hỏng hay không. ctx.warning() – điều gì đó đáng được đánh dấu mà không làm dừng quá trình thực thi. Một hồ sơ nhân viên đã chấm dứt vẫn trả về dữ liệu – nhưng tác nhân nên biết trước khi hành động. ctx.error() – điều này khiến mọi người bối rối lần đầu tiên. Nó không gây ra một ngoại lệ. Nó phát ra một thông báo và trả lại quyền kiểm soát cho bạn. Bạn quyết định liệu công cụ có tiếp tục, trả về sớm hay làm điều gì đó hoàn toàn khác. Trong một quy trình làm việc của tác nhân, sự khác biệt đó rất quan trọng – một ngoại lệ không được xử lý có thể làm hỏng toàn bộ cuộc trò chuyện. Một thông báo lỗi rõ ràng giúp LLM được thông báo và kiểm soát. Cơ chế 2: Truyền phát tiến độ – Máy chủ hiển thị công việc của nó Chín giây. Đó là thời gian một trong các công cụ của chúng tôi mất để chạy. Không phải vài phút – chín giây. Tuy nhiên, các yêu cầu hỗ trợ vẫn đến. “Tác nhân có bị kẹt không?” “Nó có bị lỗi không?” “Tại sao không có gì xảy ra?” Đó là điều về sự im lặng trong giao diện người dùng của tác nhân. Người dùng không tin tưởng nó. Chín giây không có gì giống như một sản phẩm bị hỏng, ngay cả khi mọi thứ đang hoạt động hoàn hảo. Chúng tôi đã dành thời gian cho các yêu cầu hỗ trợ cho một công cụ đang hoạt động chính xác như thiết kế. ctx.report_progress() đã khắc phục điều đó. Một lệnh gọi bên trong vòng lặp, và đột nhiên người dùng có thể thấy tác nhân đang hoạt động, từng bản ghi, từng phần trăm. Các yêu cầu hỗ trợ đã dừng lại. Đây là những gì nó trông giống như trong get_department_report, một công cụ chạy phân tích lương trên mọi nhân viên trong một bộ phận: # Bên trong vòng lặp – phát ra tiến độ sau khi mỗi bản ghi được xử lý await ctx.report_progres