Bending a Public MCP Server Without Breaking It — Nimrod Hauser, Baz

• Việc sử dụng các công cụ tác nhân của bên thứ ba không được quản lý tốt có thể dẫn đến hiệu suất kém, hành vi không mong muốn và rủi ro bảo mật nghiêm trọng cho ứng dụng, minh chứng qua sự cố "máy chủ MCP bốc cháy".
• Các công cụ này thường được cung cấp với mô tả chung chung, không được tối ưu hóa cho trường hợp sử dụng cụ thể, khiến tác nhân khó đưa ra quyết định chính xác và hiệu quả.
• Để giải quyết các vấn đề này, cần áp dụng khung làm việc gồm các phương pháp hay nhất như quản lý, tùy chỉnh, bảo vệ và tạo ra các công cụ mới từ những công cụ hiện có, nhằm làm cho hệ thống trở nên mạnh mẽ và đáng tin cậy hơn.

• Các công cụ tác nhân của bên thứ ba thường quá chung chung, có thể gây ra "ảo giác" hoặc hành vi không mong muốn cho tác nhân và làm giảm hiệu suất tổng thể.
• Thực hiện quản lý công cụ bằng cách loại trừ các công cụ không cần thiết cho trường hợp sử dụng cụ thể, giúp giảm cửa sổ ngữ cảnh của tác nhân và cải thiện khả năng ra quyết định.
• Đóng gói công cụ bên thứ ba bằng các mô tả tùy chỉnh và thêm logic tiền/hậu xử lý để điều chỉnh chức năng của chúng phù hợp với ngữ cảnh ứng dụng của bạn.
• Thêm hàng rào bảo vệ xác định để ngăn chặn các vấn đề bảo mật nghiêm trọng và rò rỉ dữ liệu, đặc biệt quan trọng trong các kiến trúc đa đối tượng thuê.
• Tạo các công cụ mới chuyên biệt hơn bằng cách sử dụng các công cụ hiện có làm khối xây dựng để tối ưu hóa quy trình làm việc tác nhân.
• Đối với các phần quy trình làm việc đòi hỏi độ tin cậy cao, cân nhắc coi công cụ như các hàm đơn giản hoặc chuyển các bước ra khỏi luồng tác nhân để kiểm soát trực tiếp và tránh sự không xác định.

• máy chủ MCP — MCP server
• tác nhân — agent
• AI tạo sinh — Generative AI
• công cụ — tool
• out of the box — out-of-the-box
• quy trình làm việc tác nhân — agent workflow
• đa đối tượng thuê — multi-tenant
• hàng rào bảo vệ — guardrails
• lời nhắc — prompt
• ảo giác — hallucination (AI context)
• cửa sổ ngữ cảnh — context window
• hiểu danh sách — list comprehension

Giới thiệu và Vấn đề

Chào mừng tất cả mọi người đến với buổi nói chuyện của chúng tôi hôm nay về cách khai thác một máy chủ MCP công khai mà không làm hỏng nó. Nhưng hôm nay, có lẽ chúng tôi đã làm hỏng nó vì máy chủ MCP của chúng tôi dường như đã bốc cháy. Chúng tôi rất vui vì các bạn ở đây. Chúng tôi cần mọi sự giúp đỡ có thể. Hãy cùng đi qua buổi nói chuyện của chúng tôi và xem cách chúng ta có thể cải thiện bất cứ điều gì đang diễn ra ngay tại đây. Tôi là Nymrod Houseer, tôi làm việc tại Buzz. Chúng tôi đã xây dựng các tác nhân đánh giá mã nguồn trong vài năm qua, cũng như một loạt các tính năng khác. Bất cứ điều gì có thể giúp cuộc sống của những người làm việc tại bộ phận R&D dễ dàng và tốt đẹp hơn, dù họ là dev, PM, hay bất cứ ai khác. Nếu đó là AI tạo sinh, chúng tôi có thể đang mày mò với nó. Nhưng hãy bắt đầu ngay và xem xét điều gì đang xảy ra với máy chủ MCP của chúng tôi. Tôi nghi ngờ đó là các công cụ. Chúng ta sẽ nói về các công cụ của bên thứ ba và lý do chúng có thể gây lỗi cho ứng dụng của chúng ta.

Giới thiệu về Diễn giả

Trước hết, tôi là Nymrod Houseer, một kỹ sư sáng lập tại Buzz. Tôi đã làm việc tại công ty từ khi nó được thành lập vào năm 2023. Tôi đã làm việc trong lĩnh vực dữ liệu trong khoảng 20 năm qua. Trong sự nghiệp của mình, tôi đã có một thời gian ngắn làm việc tại Salesforce, và sau đó chủ yếu là các công ty khởi nghiệp trong lĩnh vực an ninh mạng, tiền điện tử và hiện nay là công cụ dành cho nhà phát triển. Ngày nay, tôi chủ yếu muốn nói chuyện với các bạn về các công cụ tác nhân. Đúng vậy, các công cụ tác nhân, và đặc biệt là các công cụ của bên thứ ba.

Thách thức với các Công cụ của Bên thứ ba

Các công cụ này có thể là một lực lượng tuyệt vời, một sự bổ sung tuyệt vời cho ứng dụng của chúng ta. Nhưng chúng không phải lúc nào cũng hoạt động out of the box. Chúng ta kỳ vọng chúng sẽ làm cho ứng dụng của mình tốt hơn. Đôi khi chúng ta sẽ thấy sự suy giảm về hiệu suất và chúng ta sẽ cố gắng hiểu tại sao điều đó lại xảy ra. Sau đó, chúng ta sẽ khám phá một khung làm việc gồm năm phương pháp hay nhất mà chúng ta có thể tuân theo để thay đổi tình thế và làm cho ứng dụng của chúng ta trở nên mạnh mẽ. Trong quá trình đó, hy vọng chúng ta sẽ khắc phục được máy chủ MCP của Buzz mà chúng ta vừa thấy bốc cháy, làm cho nó hoạt động và làm cho các tác nhân của chúng ta hoạt động theo cách chúng ta muốn. Vâng, điều này trông khá tệ. Tôi nghĩ chúng ta nên đi sâu vào.

Chúng ta sẽ nói về các công cụ tác nhân khi chúng ta sử dụng máy chủ MCP. Chúng ta nhận được các công cụ đến từ máy chủ MCP. Vì vậy, miễn là chúng ta đang nói về các công cụ của bên thứ ba, tôi không quan tâm liệu chúng đến từ một máy chủ MCP, từ một thư viện, hay có thể chúng ta đã sao chép và dán chúng từ một nơi nào đó. Nếu chúng là các công cụ tác nhân và được viết bởi một nhóm khác, chúng đều phù hợp cho cuộc thảo luận này.

Công cụ là gì?

Về cơ bản, công cụ chỉ là các hàm có thể gọi được, được bao bọc bởi một mô tả rõ ràng. Mô tả này rất quan trọng vì nó cho phép các tác nhân biết khi nào nên sử dụng mã và cách sử dụng mã. Chúng ta sẽ đi sâu vào các khía cạnh này của mô tả. Nhưng một lần nữa, nó giống như mã tích hợp được nâng cấp, được viết bởi bên thứ ba. Trong buổi nói chuyện hôm nay, chúng ta sẽ lấy máy chủ MCP của Playwright làm ví dụ. Về cơ bản, chúng ta đang xem xét mã tích hợp được viết bởi những người tốt ở nhóm Playwright, được bao bọc bởi các mô tả của họ. Và chúng ta sẽ xem cách chúng ta có thể làm cho các công cụ này hoạt động tốt hơn, điều chỉnh chúng cho trường hợp sử dụng cụ thể của chúng ta.

Các thách thức cụ thể

Vâng, các công cụ của bên thứ ba có những thách thức riêng. Đầu tiên và quan trọng nhất, chúng có thể khiến các tác nhân của chúng ta hoạt động không mong muốn. Bạn biết đấy, các tác nhân vốn đã là những thứ không xác định và khó đoán. Bạn cung cấp cho chúng các công cụ và bạn sẽ nhận được sự khó đoán ở quy mô lớn. Nhưng chúng cũng có thể làm giảm hiệu suất. Bạn có thể muốn tác nhân thực hiện một việc nhất định và bạn nhận được kết quả kém, kết quả sai, hoặc có thể nó chỉ thực hiện được nhưng theo một cách không tối ưu. Và thông qua các phương pháp hay nhất hôm nay, hy vọng chúng ta có thể thấy cách chúng ta có thể làm cho việc triển khai các công cụ của bên thứ ba trong các quy trình làm việc tác nhân của chúng ta tốt hơn nhiều.

Vấn đề về Hiệu suất và Bảo mật

Cuối cùng và quan trọng nhất, những hiệu suất kém và hành vi không mong muốn đó cũng có thể có nghĩa là các vấn đề bảo mật nghiêm trọng. Hãy tưởng tượng một kịch bản khá kinh điển: một kiến trúc đa đối tượng thuê (multi-tenant architecture) và tác nhân của bạn có thể không biết tất cả những gì cần biết về kiến trúc của bạn và sự phân chia thành các thư mục hoặc cơ sở dữ liệu và sơ đồ. Nó chỉ không có các hàng rào bảo vệ phù hợp và nó có thể làm rò rỉ dữ liệu khách hàng từ khách hàng này sang khách hàng khác. Những điều thuộc bản chất đó. Bạn thực sự muốn bảo vệ tác nhân của mình, và điều này trở nên quan trọng hơn khi xử lý các công cụ của bên thứ ba không nhận thức được kiến trúc của bạn. Vì vậy, chúng ta cũng sẽ đề cập đến điều đó.

Trường hợp sử dụng: Trình đánh giá đặc tả của Buzz

Được rồi, tôi nghĩ chúng ta sẽ bắt đầu xem xét một trường hợp sử dụng. Để xem xét một số mã, trên thực tế. Nhưng chúng ta sẽ cần một trường hợp sử dụng, và với sự cho phép của các bạn, chúng ta sẽ chọn một trong số của chúng tôi. Vì vậy, hôm nay trường hợp sử dụng của chúng tôi sẽ là Trình đánh giá đặc tả của Buzz. Vậy Trình đánh giá đặc tả là gì? Đó là một trong những sản phẩm của chúng tôi, về cơ bản là một tác nhân đánh giá biết cách so sánh các yêu cầu với việc triển khai.

Cách hoạt động của Trình đánh giá đặc tả

Là bước đầu tiên, nó cần thu thập các yêu cầu. Nó sẽ truy cập vào các hệ thống quản lý vé của bạn như Jira hoặc Linear hoặc bất cứ thứ gì tương tự và đọc một vé. Nó cũng có thể truy cập Figma và xem các thiết kế trực quan theo một cách hoạt động đa mô hình. Nó sẽ thực sự xem thiết kế dự định. Và phần đó là các yêu cầu. Khi nó hiểu được một nhà phát triển đã được giao nhiệm vụ gì, đó là lúc nó sẽ khởi chạy máy chủ MCP của Playwright để thực sự mở một trình duyệt, truy cập hệ thống của bạn, kiểm tra nhánh, xem việc triển khai và nó sẽ cần đánh giá xem việc triển khai có đáp ứng yêu cầu hay không. Nó sẽ cung cấp cho chúng ta một loại phán quyết, nó sẽ chụp ảnh màn hình làm bằng chứng liệu điều này đã được hoàn thành hay chưa. Và nó thực hiện tất cả điều này tự động và có thể tiết kiệm cho mọi người, chủ yếu là các PM, rất nhiều thời gian làm công việc xác thực thủ công. Vì vậy, chúng tôi đã xây dựng một ví dụ minh họa về trình đánh giá đặc tả của chúng tôi. Và chúng ta sẽ xem cách chúng ta xử lý các công cụ để tận dụng tối đa nó. Tôi hy vọng điều này có ý nghĩa. Ở cấp độ cao, tôi nghĩ đã đến lúc xem xét một số mã và hy vọng mọi thứ sẽ rõ ràng hơn nhiều.

Mã nguồn minh họa – Phiên bản ban đầu (v0)

Được rồi, vậy chúng ta có một ví dụ minh họa về trình đánh giá đặc tả của chúng tôi. Chúng ta sẽ xem xét nó một cách nhanh chóng. Chúng ta không cần đi sâu vào mọi khía cạnh của nó. Đó là một dự án khá nhỏ. Và chúng ta sẽ xem điều gì đang xảy ra và tập trung vào những phần chúng ta quan tâm. Vì vậy, chúng ta bắt đầu ở đây với hàm main của chúng ta. Và chúng ta có một thư mục nơi chúng ta muốn lưu các ảnh chụp màn hình, chúng ta sẽ nói về điều đó sau. Nhưng ngay lập tức, chúng ta có cấu hình máy chủ MCP của chúng ta. Chúng ta chỉ sử dụng một máy chủ MCP của Playwright. Điều này khá tiêu chuẩn. Vì vậy, chúng ta có một MCP.

Cấu hình Máy chủ MCP và Công cụ

Khi chúng ta đi vào hàm main của chúng ta, bạn có thể thấy rằng chúng ta đang định nghĩa máy khách MCP của chúng ta. Và chúng ta sẽ sử dụng nó trong một chút nữa, chúng ta sẽ đặt nó vào tác nhân của chúng ta. Nhưng tôi muốn tập trung vào điều này, đây là nơi phép thuật của buổi nói chuyện này diễn ra. Chúng ta đã xây dựng một lớp cơ sở để lấy các công cụ, và tất cả những gì nó làm là có một hàm gọi là get_tools. Khi chúng ta đi qua buổi nói chuyện, chúng ta sẽ tăng độ phức tạp và cải thiện cách chúng ta xử lý các công cụ đến từ máy chủ MCP của bên thứ ba. Vì vậy, đây là nó. Chúng ta đang bắt đầu với đường cơ sở. Chúng ta sẽ xem xét nó trong giây lát và khi chúng ta bắt đầu phiên của mình, đây là nơi sự kế thừa này sẽ diễn ra. Mỗi khi chúng ta chạy điều này, hàm get_tools sẽ làm điều gì đó phức tạp hơn một chút.

Định nghĩa Tác nhân và Lời nhắc

Vì vậy, chúng ta bắt đầu, chúng ta muốn bắt đầu quy trình của mình. Chúng ta có hàm này gọi là login_to_buzz bởi vì đối với buổi nói chuyện này, ví dụ của chúng ta sẽ là đăng nhập vào hệ thống của chúng ta. Và chúng ta sẽ nói về lý do tại sao chúng ta cần điều này vào cuối. Thực ra có một điểm thú vị ở đây. Chúng ta sẽ định nghĩa một LLM, sẽ tạo một tác nhân. Chúng ta sẽ cung cấp cho nó một thông điệp hệ thống và một thông điệp người dùng để bắt đầu. Đây là những thông điệp mà nó sẽ nhận được và chúng ta sẽ gọi nó. Có lẽ bạn đang tự hỏi, có lẽ bạn muốn xem một chút sâu hơn, có lẽ xem xét các lời nhắc. Vì vậy, điều này nên tương đối đơn giản, bạn biết đấy.

Lời nhắc hệ thống. Đây chủ yếu là AI tạo sinh nói những điều như bạn là một tác nhân QA tỉ mỉ. Bạn cần xem xét các yêu cầu từ vé cũng như xác minh trực quan. Mọi thứ chúng ta đã nói ở cấp độ cao đều ở đây. Một số hướng dẫn: đầu tiên đọc vé, hiểu nó, điều hướng qua hệ thống, và sau đó ở cuối như chúng ta đã nói, nó cần đưa ra một phán quyết đạt hoặc không đạt, các quan sát cụ thể và tham chiếu mọi thứ bằng ảnh chụp màn hình làm bằng chứng. Lời nhắc người dùng rất giống nhau. Nó có một khía cạnh đa mô hình nơi chúng ta lấy hình ảnh và nhúng chúng vào lời nhắc người dùng. Nhưng ngày nay nó rất đơn giản và bất kỳ tác nhân tạo mã nào cũng có thể tạo ra điều đó cho bạn nếu bạn cần.

Ví dụ về hình ảnh và Yêu cầu

Nói về hình ảnh, chúng ta có hai hình ảnh ở đây. Chúng ta có một vé mà chúng ta đã chụp ảnh màn hình từ sản phẩm thực của chúng tôi. Sản phẩm thực không lấy vé dưới dạng ảnh chụp màn hình. Chúng tôi chỉ lười biếng. Nhưng tác nhân chắc chắn có thể đọc điều này. Hiểu yêu cầu. Có một thiết kế đi kèm. Đó là cái này. Vì vậy, vé ghi rõ rằng chúng ta muốn có một ngăn cấu hình cho trình đánh giá đặc tả của chúng ta trong hệ thống của chúng tôi ở Buzz. Nó giải thích nó nên trông như thế nào và một thiết kế được cung cấp. Vì vậy, tác nhân nên hiểu rằng nó đang tìm kiếm một ngăn kéo bên trong tab tác nhân của chúng tôi cho trình đánh giá đặc tả và nó nên trông đại khái như thế này.

Chạy thử nghiệm ban đầu

Tuyệt vời. Tôi nghĩ đã đến lúc chúng ta khởi chạy cái này và hy vọng nó sẽ làm cho mọi thứ rõ ràng hơn nhiều. Chúng ta có một điểm dừng ở đây ngay sau khi chúng ta lấy các công cụ. Gần như quên mất. Lần chạy đầu tiên của chúng ta sẽ là với v0, điểm chuẩn. Điểm chuẩn của chúng ta là gì? Nếu chúng ta đi đến get_tools của chúng ta, chúng ta thấy rằng những gì chúng ta làm cho v0 là cổ điển, out of the box. Chúng ta chỉ sử dụng phương thức load_mcp_tools của LangChain. Đó là tất cả cho lần chạy đầu tiên. Chúng ta không can thiệp vào các công cụ chút nào. Hãy xem nó hoạt động như thế nào một cách nguyên bản.

Kết quả chạy thử nghiệm ban đầu

Được rồi, vậy là nó đang khởi động và chúng ta có các công cụ của mình. Hãy xem chúng ta có gì ở đây. Ngay lập tức, những người giỏi ở Playwright đã cung cấp cho chúng ta 21 công cụ và mọi thứ liên quan đến việc thao tác với trình duyệt: browser_close, browser_resize, console_messages, handle_dialog, file_upload, fill_form, install_all_the_press_key. Và sau đó chúng ta có thể xem các mô tả. Mô tả cho một công cụ gọi là press_key là gì? "Nhấn một phím trên bàn phím." Mô tả cho một thứ gì đó như resize là gì? "Thay đổi kích thước cửa sổ trình duyệt." browser_close? "Đóng trang."

Phân tích Công cụ và Mô tả

Những mô tả này có vẻ rất nông cạn và rất chung chung, nhưng chúng ta không trách họ. Những người ở Playwright không biết trường hợp sử dụng cụ thể của chúng ta là gì. Máy chủ MCP này sẽ cần phục vụ cho tôi không biết bao nhiêu trường hợp sử dụng khác nhau. Nó phải là chung chung. Nhưng đối với chúng ta khi sử dụng cái này, và chúng ta sẽ thấy điều này tiếp theo, chúng ta có thể muốn đưa vào các mô tả riêng của chúng ta thực sự phù hợp với trường hợp sử dụng của chúng ta. Nhưng chúng ta chưa đến đó. Chúng ta vẫn đang ở đường cơ sở. Vì vậy, hãy tiếp tục và chúng ta sẽ thấy rằng điều này đang chạy.

Được rồi. Playwright đang chạy, nó đang khởi động một trình duyệt. Và bây giờ nó sẽ đăng nhập. Và một khi nó đã đăng nhập, tác nhân sẽ tiếp quản và bắt đầu chạy theo lời nhắc. Và nó bắt đầu. Nó đang mở hoặc nó đã đăng nhập. Đây là trang chủ của chúng tôi, đó là màn hình thay đổi và bây giờ nó sẽ cần tìm trang liên quan, đó là tab tác nhân. Vì vậy, nó sẽ cần khám phá hệ thống một chút. Và nó có thể hoạt động, nó có thể không hoạt động. Hãy nhớ rằng các công cụ không được tối ưu hóa vào thời điểm này và nó đã xong.

Kết quả không mong muốn

Hãy xem nó đã làm như thế nào. Nhìn vào kết quả. Nó nói với tôi rằng yêu cầu không được triển khai, rằng trạng thái là một phán quyết thất bại. Nó đưa ra một quan sát và nó nói với tôi rằng yêu cầu không được đáp ứng vì nó không thể điều hướng đến một trang dường như được tạo ra gọi là "buzz.co/spec_reviewer".

Nâng cao Công cụ tác nhân: Chẩn đoán và Khái niệm Cốt lõi

Đây có thể là một ảo giác hoặc một lỗi phán đoán của tác nhân, cùng với một số vấn đề khác. Nó đưa ra bằng chứng về ảnh chụp màn hình lỗi 404, có lẽ đã được chụp và chúng ta có thể kiểm tra trong thư mục ảnh chụp màn hình. Thậm chí nó còn không chụp được ảnh màn hình đúng cách. Rất nhiều thứ đã sai, và đây thực sự là một kết quả tuyệt vời cho phần mở đầu của buổi nói chuyện mà toàn bộ khái niệm là tối ưu hóa việc sử dụng công cụ tác nhân của chúng ta.

Hãy xem chúng ta có thể làm gì để cải thiện công cụ của mình. Chúng ta sẽ chạy lại và xem liệu có thể đảo ngược tình thế này không. Được rồi, tốt. Máy chủ MCP của chúng ta đã bắt đầu trông tốt hơn một chút, lửa đã tắt. Bây giờ chỉ còn lại tia lửa này, và điều này có lẽ là do chúng ta đã xem xét một số mã. Chúng ta bắt đầu hiểu vấn đề, nhưng chúng ta vẫn cần bắt đầu thực sự triển khai những cải tiến của mình và xem điều gì có thể được thực hiện để thực sự làm cho hệ thống tốt hơn.

Đã đến lúc giới thiệu năm khái niệm mà chúng ta sẽ xem xét. Chúng ta sẽ xem cách chúng ta có thể quản lý công cụ bên thứ ba, bao bọc công cụ bên thứ ba bằng các mô tả của riêng chúng ta và có thể một số điều bổ sung. Thêm hàng rào bảo vệ xác định bất cứ khi nào chúng ta cảm thấy cần thiết và chúng ta sẽ đưa ra một ví dụ. Tạo công cụ mới từ các công cụ hiện có, thực sự sử dụng các công cụ hiện có làm khối xây dựng. Và cuối cùng, luôn có lựa chọn coi công cụ là các hàm đơn giản, chỉ cần gọi chúng, sử dụng chúng làm mã tích hợp mà chúng ta đã nói đến, được viết cho chúng ta bởi những người tốt bụng trong nhóm Playwright. Bạn biết đấy, đưa một số phần của quy trình làm việc ra ngoài luồng tác nhân bất cứ khi nào chúng ta cảm thấy cần thiết. Chúng ta sẽ nói về điều này vào cuối buổi. Vì vậy, nó cũng là một công cụ trong kho vũ khí của chúng ta. Tôi đã chia những điều này thành hai nhóm: một thuộc về kỹ thuật ngữ cảnh, nhóm còn lại là hàng rào bảo vệ xác định. Cuối cùng thì điều đó không thực sự quan trọng, bất cứ điều gì khiến ứng dụng của chúng ta hoạt động theo cách chúng ta muốn, đó là điều chúng ta cần sử dụng. Vì vậy, bây giờ chúng ta sẽ đi qua từng điểm một, xem mã và xem cách chúng ta có thể cải thiện ví dụ minh họa mà chúng ta vừa thấy.

Quản lý Công cụ Bên Thứ ba

Bắt đầu với điểm đầu tiên của chúng ta: quản lý công cụ bên thứ ba. Được rồi, hãy xem điểm này trông như thế nào. Được rồi, chúng ta đã quay lại dự án quen thuộc của mình và thông qua phép thuật của chỉnh sửa video, chúng ta hiện đã nhập v1. Trước đây là v0 original. Bây giờ là v1 curated. Sự khác biệt duy nhất, như chúng ta đã thấy, là bây giờ chúng ta có cái này là v1, và như chúng ta đã nói, đây là lớp kế thừa từ lớp cơ sở. Nếu trước đây chỉ có get tools vanilla sử dụng hàm của LangChain, thì bây giờ chúng ta có thể thấy những gì chúng ta đã triển khai ở đây.

Vì vậy, chúng ta đi vào và trước đây chúng ta trả về cái này, nhưng bây giờ chúng ta có danh sách lớn tất cả các tên công cụ mà chúng ta nhận được từ MCP Playwright của mình. Và danh sách nhỏ hơn này khá là tiêu chuẩn trong Python. Hiểu danh sách (list comprehension), vì vậy chúng ta chỉ tạo danh sách các công cụ mà chúng ta muốn loại trừ. Chúng ta chỉ cần xem qua chúng và chúng ta biết các công cụ mà chúng ta đã sử dụng máy chủ MCP này một thời gian, và chúng ta quyết định rằng đối với trường hợp sử dụng của mình, chúng ta có thể không cần thay đổi kích thước trình duyệt. Chúng ta không muốn tác nhân của mình kéo các mục. Chúng ta không muốn tự chạy mã bên trong trình duyệt. Đây không phải là những việc mà người đánh giá thông số kỹ thuật của chúng ta cần làm như một phần của hoạt động của nó. Có thể đối với trường hợp sử dụng của bạn, điều này là cần thiết, nhưng đối với chúng ta thì không nhiều. Vì vậy, tất cả những gì chúng ta làm là lấy tất cả các công cụ và thay vì chỉ trả về chúng, chúng ta đơn giản loại trừ những cái chúng ta không muốn. Vì vậy, có sáu công cụ ở đây mà chúng ta sẽ không sử dụng. Chúng ta khởi động cái này, chúng ta có điểm ngắt của mình, và thay vì 21 công cụ như trước đây, tôi mong đợi thấy ít hơn, và chúng ta có 16, thật tuyệt vời.

Vì vậy, điều này có nghĩa là cửa sổ ngữ cảnh của chúng ta đã có ít công cụ hơn. Tác nhân của chúng ta có ít lựa chọn hơn, vì vậy mọi thứ có thể trở nên đơn giản hơn. Chúng ta sẽ thấy rằng không phải tất cả các hướng dẫn mà chúng ta sẽ xem xét đều nhất thiết làm giảm số lượng mục trong cửa sổ ngữ cảnh của chúng ta; một số thực sự sẽ thêm vào đó. Nhưng đây đều là một phần của sự đánh đổi, hành động cân bằng mà chúng ta sẽ nói đến.

Bao bọc Công cụ Bên Thứ ba với Mô tả Nâng cao

Chuyển sang điểm tiếp theo của chúng ta: thực hành bao bọc công cụ bên thứ ba. Điều này thật tuyệt vời. Chúng ta đã nói về cách các mô tả cụ thể đến từ MCP Playwright rất hời hợt và rất chung chung, và điều đó hoàn toàn dễ hiểu vì chúng cần phục vụ mọi trường hợp sử dụng có thể trên thế giới mà có thể muốn sử dụng trình duyệt. Nhưng nếu bạn thực sự muốn tối ưu hóa, bạn có thể muốn bắt đầu điều chỉnh nội dung cho trường hợp sử dụng của riêng mình. Hãy xem điều này xảy ra như thế nào.

Được rồi, đây đã trở thành lãnh thổ quen thuộc. Và như mọi khi, thông qua phép thuật của chỉnh sửa video, chúng ta có v2 đã được nhập và bao bọc. Lần này chúng ta đang bao bọc công cụ. Đi xuống, chúng ta thấy rằng chúng ta đang gọi lớp v2 sẽ triển khai get tools, và chúng ta sẽ xem điều gì đang xảy ra ở đây. Nếu tôi đi đến v2 wrapped, tôi thấy rằng như trước, chúng ta lấy tất cả các công cụ. Nhưng bây giờ chúng ta có lớp mới này được gọi là tool wrapper có một phương thức mà chúng ta đang gọi là wrap playwright tools. Hãy xem điều gì đang xảy ra ở đây. Như trước, chúng ta vẫn có danh sách tất cả các tên công cụ này. Chúng ta sẽ thực hiện lọc xa hơn một chút. Nhưng thay vì chỉ có tên công cụ, chúng ta cũng có tất cả các mô tả này, và vì vậy, đối với mỗi công cụ, chúng ta muốn chỉ định điều gì cần xảy ra. Và từ kinh nghiệm, chúng ta có sự nhấn mạnh nhỏ của riêng mình mà chúng ta muốn dành cho tác nhân của mình. Chúng ta có thể nói với nó, bạn biết đấy, trước khi gọi công cụ trình duyệt, hãy gọi công cụ khác này trước. Công cụ này chúng ta thấy đặc biệt hữu ích. Nó có một cái tên hơi gây hiểu lầm. Nó được gọi là công cụ chụp ảnh nhanh. Nó thực sự không phải là ảnh chụp màn hình trực quan. Đó là ảnh chụp màn hình hỗ trợ tiếp cận hiển thị cho bạn tất cả các nút khác nhau và tất cả các mục menu khác nhau bằng văn bản. Và chúng ta cảm thấy rằng tác nhân thực sự hiểu rõ về những gì có trên một trang khi nó gọi công cụ đó. Vì vậy, chúng ta nói với nó, đối với một loạt các công cụ, bạn biết đấy, trước khi gọi hover, trước khi gọi click, vui lòng sử dụng công cụ này trước. Vì vậy, chúng ta thực sự có thể ảnh hưởng đến hành vi của nó. Chúng ta có thể làm cho nó sẵn lòng chọn công cụ này hơn công cụ khác. Chúng ta có thể làm nhiều điều. Ví dụ, đây là công cụ tôi vừa nói về ảnh chụp màn hình hỗ trợ tiếp cận. Chúng ta sẽ nói với nó luôn ưu tiên cái này hơn là chụp ảnh chụp màn hình trực quan thực tế, đó là công cụ này. Vì vậy, bạn thực sự có thể cung cấp rất nhiều hướng dẫn từ kinh nghiệm của riêng bạn cho trường hợp sử dụng cụ thể của riêng bạn, và điều này rất, rất mạnh mẽ.

Ở đây, chúng ta có từ điển này chỉ ánh xạ tên công cụ với các mô tả nâng cao mới của chúng. Vẫn còn các công cụ để lọc ở cuối. Chúng ta có hàm mà chúng ta đã gọi là wrap playwright tools. Và nó chỉ đi qua tất cả các công cụ mà chúng ta nhận được từ Playwright ngay từ đầu. Chúng ta lọc những gì cần lọc và đối với các công cụ khác, chúng ta nhận được mô tả nâng cao của chúng dựa trên tên công cụ và chúng ta tạo công cụ này và thêm vào danh sách các công cụ được bao bọc. Vì vậy, chúng ta nhận được công cụ nâng cao. Phương thức tạo công cụ nâng cao này là gì? Chà, đó là một phương thức lấy công cụ gốc và mô tả nâng cao, tạo công cụ mới và trả về nó. Vậy thì công cụ mới tuyệt vời này làm gì? Chính xác những gì công cụ cũ đã làm, nó chỉ gọi công cụ gốc. Nó chỉ có một mô tả nâng cao.

Vì vậy, nếu chúng ta chạy cái này, quay lại chính và chúng ta chạy cái này và chúng ta vẫn có điểm ngắt của mình, chúng ta có thể thấy rằng chúng ta vẫn có ít công cụ hơn như chúng ta mong muốn từ trước, thậm chí còn ít hơn, chúng ta đã lọc thêm một số. Nhưng khi chúng ta nhìn vào các mô tả, bạn thấy rằng chúng dài hơn nhiều và chúng là những gì chúng ta muốn. Ví dụ, đây là công cụ chúng ta đã nói về browser snapshot capture (chụp ảnh nhanh trình duyệt) và accessibility snapshot of the current page (ảnh chụp màn hình hỗ trợ tiếp cận của trang hiện tại), blah blah blah, tất cả những điều chúng ta đã nói. Nếu chúng ta nhìn vào một công cụ khác, browser click (nhấp trình duyệt), đây là hướng dẫn của chúng ta cho việc trước tiên hãy gọi công cụ kia và sau đó gọi công cụ này. Bây giờ tác nhân của chúng ta biết chúng ta muốn nó hành xử như thế nào.

Áp dụng Hàng rào Bảo vệ Xác định

Được rồi, sang điểm tiếp theo. Đầu tiên, máy chủ MCP của chúng ta, tôi không biết bạn có nhận thấy không, nhưng mọi thứ đang trông tốt hơn nữa. Một số giao diện dường như hoạt động, đèn nhấp nháy, mọi thứ kích hoạt, nhưng chúng ta vẫn còn xa đích. Chúng ta sẽ chuyển sang điểm số ba và tiếp tục cải thiện điều này.

Bây giờ chúng ta đang đi vào lĩnh vực hàng rào bảo vệ xác định, và đây là việc đưa vào hàng rào bảo vệ xác định, kiểm soát các khía cạnh nhạy cảm hoặc quan trọng của nhiệm vụ của chúng ta bằng logic xác định không phụ thuộc vào quá trình ra quyết định của tác nhân. Đôi khi có những khía cạnh của nhiệm vụ của bạn quá nhạy cảm để giao cho tác nhân. Chúng ta đã nói trước đây về các kịch bản như kiến trúc đa người thuê và các kịch bản mà tác nhân có thể không hoàn toàn nhận thức được kiến trúc của bạn, những điều tương tự. Và tất nhiên, bạn cần chỉ định mọi thứ bạn có thể trong mô tả công cụ và lời nhắc. Nhưng đôi khi thực sự muốn thực thi rằng nó không làm bất cứ điều gì kỳ lạ. Bạn biết đấy, tác nhân là những thứ không xác định, và đôi khi chúng sẽ bỏ qua bạn. Chúng ta biết về tất cả các hiện tượng này như kim trong đống cỏ khô và mất giữa chừng và nhiều trường hợp tác nhân sẽ không hoạt động như bạn dự định. Đây là nơi bạn muốn đặt một số thực thi xác định.

Chúng ta đã làm điều này xung quanh công cụ chụp ảnh chụp màn hình trực quan thực tế, không phải ảnh chụp màn hình hỗ trợ tiếp cận chúng ta đã nói trước đây, mà là ảnh chụp màn hình trực quan thực tế. Chúng ta có một thư mục mà chúng ta đã định nghĩa và chúng ta nói đây là thư mục đầu ra. Đây là nơi chúng ta muốn bạn đặt hình ảnh. Nhưng có khả năng tác nhân sẽ vượt khỏi kiểm soát và chỉ lưu trữ hình ảnh ở những nơi khác. Vì vậy, đó là nơi chúng ta muốn vạch ranh giới và đảm bảo điều này không bao giờ xảy ra. Được rồi.

Vì vậy, như mọi khi, bây giờ chúng ta có v3 là cái chúng ta muốn xem. Vì vậy, quay lại chính, chúng ta thấy chúng ta có cái này ở đây v3 guardrailed. Chúng ta đi sâu vào và chúng ta thấy rằng chúng ta lại có wrap playwright tools của mình. Rõ ràng lần này nó sẽ làm điều gì đó hơi khác. Khi chúng ta tăng dần mỗi lần, vì vậy chúng ta vẫn có tên, chúng ta vẫn có mô tả và đi xuống, xuống, xuống, xuống, xuống. Nhân tiện, chúng ta đã có thể thấy rằng ngoài v3 mà chúng ta luôn có trông như thế này và tool wrapper mà chúng ta có trước đây, bây giờ chúng ta có một lớp khác được gọi là path validation. Hãy xem chúng ta sử dụng nó ở đâu. Vì vậy, chúng ta đang đi xuống, xuống, xuống. Chúng ta đi qua từ điển, qua các công cụ để lọc. Chúng ta đang ở trong phương thức đó, phương thức mà chúng ta luôn nhập wrap playwright tools. Và wrap playwright tools như trước, nó đi qua tất cả các công cụ gốc mà chúng ta nhận được từ MCP Playwright của chúng ta, lọc những gì cần lọc, cung cấp mô tả nâng cao cho mỗi công cụ nếu chúng ta tìm thấy nó, và sau đó như trước, chúng ta có cùng một hàm hỗ trợ create playwright tool wrapper (tạo trình bao bọc công cụ Playwright), hàm đó lấy một công cụ, cung cấp cho nó một mô tả nâng cao và tạo một công cụ mới từ nó, cùng chức năng, mô tả mới. Hãy xem điều gì đã thay đổi bây giờ.

Vì vậy, khi chúng ta muốn tạo công cụ mới, đúng không? Vì vậy, đây là công cụ chúng ta đang tạo. Như chúng ta đã nói, một công cụ chỉ là một hàm có thể gọi với một số mô tả. Chúng ta đưa ra mô tả mới. Và trước đây chúng ta có phần này vì chúng ta nói công cụ mới làm gì? Chính xác những gì công cụ cũ đã làm. Nhưng chúng ta đã thêm phần này. Chúng ta đang nói rằng nếu công cụ hiện đang được kích hoạt, nếu đó là công cụ chụp ảnh màn hình (takes screenshot tool) và chúng ta đã nghiên cứu công cụ đó và chúng ta biết rằng nó sử dụng path (đường dẫn) hoặc file name (tên tệp) làm từ khóa ít nhất là từ khóa có liên quan đối với chúng ta. Vì vậy, nếu bạn đang cố gắng gọi công cụ và đó là công cụ này, thì hãy tìm các từ khóa này và xác thực chúng, và chúng ta có một số hàm hỗ trợ, path validation (xác thực đường dẫn) này. Đây chỉ là các hàm hỗ trợ.

Hàng Rào Bảo Vệ Xác Định (Deterministic Guardrails) cho Công Cụ

Chúng ta không cần đi sâu quá nhiều vào chi tiết, nhưng đây là logic xác định: chúng ta lấy đường dẫn mà công cụ đã chọn và đường dẫn của chúng ta, nơi chúng ta muốn buộc các nội dung phải được lưu trữ. Chúng ta gọi đó là đường dẫn ảnh chụp màn hình (screenshots route) và chúng ta chỉ sử dụng phương pháp này. Chúng ta muốn biết liệu đường dẫn đó có tương đối với ảnh chụp màn hình hay không, liệu đường dẫn đã chọn có tương đối với đường dẫn ảnh chụp màn hình hay không. Vì vậy, đây là một cách xác định: một khi chúng ta hiểu công cụ có ý định lưu ảnh ở đâu, chúng ta sẽ biết liệu nó có nằm trong thư mục phù hợp hay không.

Quay lại hàm trợ giúp của chúng ta, mỗi khi công cụ được gọi, trước khi nó thực sự được gọi, chúng ta sẽ trích xuất đường dẫn mà nó có ý định lưu vào để gọi nó. Chúng ta cố gắng xác thực và nếu đó không phải là đường dẫn hợp lệ, nó sẽ không được gọi mà sẽ đưa ra lỗi. Đây là một cách xác định để chúng ta có thể ngăn chặn công cụ ngay lập tức, hay còn gọi là guardrail xác định.

Xử Lý Lỗi Rõ Ràng Cho Tác Nhân

Một điều hay khác cần lưu ý là chúng ta có thể đưa ra một ngoại lệ hỗn hợp. Chúng ta không trả về một ngoại lệ. Chúng ta không muốn toàn bộ quá trình tác nhân (agent) thất bại. Thay vào đó, chúng ta xử lý vấn đề này một cách khéo léo bằng cách tạo ra một giải thích rất rõ ràng cho tác nhân và những gì tác nhân sẽ nhận được là một thông báo dễ hiểu, nói rằng: "Nghe này, quyền truy cập bị từ chối. Bạn không thể lưu ở đó. Bạn cần lưu ở đây. Vui lòng cung cấp tên tệp và đường dẫn phù hợp." Một tác nhân nhận được thông báo này rất có thể sẽ thử lại. Đây là cách chúng ta điều chỉnh (aligning) nó, và nó sẽ thử lại, cung cấp một đường dẫn chính xác, xử lý việc này và lưu hình ảnh. Đó chính xác là những gì chúng ta muốn xảy ra trong các tình huống nhạy cảm về bảo mật này. Điều đó thật tuyệt vời.

Cá nhân tôi rất thích điểm này. Tôi nghĩ nó rất phổ biến và là một công cụ mà mọi người nên có trong kho vũ khí của mình. Nhưng đã đến lúc tiếp tục. Chúng ta còn hai điểm nữa. Điều này có thể hơi ngách hơn, thuộc về phía nâng cao hơn, nhưng đáng để tìm hiểu và biết rằng đó là một khả năng.

Kết Hợp Các Công Cụ Hiện Có

Nội dung này nói về việc kết hợp các công cụ mới từ các công cụ hiện có, và nơi chúng ta đã làm điều đó khá thú vị. Nó thực ra cũng liên quan đến cùng một công cụ chụp nhanh (take snapshot tool). Chúng tôi cảm thấy đôi khi chúng ta muốn chụp nhanh nói chung, đó là một việc khá chung chung. Nhưng khi chúng ta chụp ảnh màn hình trong ngữ cảnh thu thập bằng chứng ở cuối luồng (flow), chúng ta cảm thấy rằng có một công cụ riêng cho việc đó là cần thiết. Tại sao? Chúng ta có thể tạo một công cụ mới mà chức năng của nó về cơ bản khá giống với việc chụp nhanh thông thường (take regular snapshot).

Nhưng vì nó sẽ có các mô tả riêng biệt, tác nhân có thể chọn cái này hoặc cái kia, và chúng ta cũng có thể yêu cầu nó hoạt động hơi khác trong cả hai trường hợp. Chúng ta cũng có thể cung cấp thêm các hành động bổ sung, thậm chí là các hành động xác định, ngay trước khi gọi công cụ gốc. Vì vậy, chúng ta đã tạo một tác nhân mới gọi là evidence tool (công cụ bằng chứng) và hãy cùng xem chúng ta đã làm gì ở đó.

Triển Khai Công Cụ Bằng Chứng

Lần này, chúng ta đã nhập v4 như mong đợi vào thời điểm này. Vì vậy, chúng ta có thể xem v4 để hiểu cách nó triển khai get tools. Chúng ta đi vào, nó mở ra và trông rất giống trước đây; thực tế, mọi thứ đều trông giống nhau. Chúng ta có tool wrapper, chúng ta có xác thực đường dẫn (path validation), rất rất giống nhau. Vậy sự khác biệt là gì?

Chúng ta inject (chèn) một công cụ mới. Vì vậy, chúng ta có... trong tool wrapper, những gì chúng ta đã mong đợi cho đến bây giờ, chúng ta có tên công cụ, mô tả công cụ, từ điển (dictionary). Chúng ta có các công cụ để lọc, mọi thứ đều giống nhau, và sau đó chúng ta có wrap playwright tool cũ kỹ, lặp lại tất cả các công cụ, lọc những gì cần lọc và tạo bất kỳ công cụ nào chúng ta cần tạo với mô tả nâng cao. Nhưng đây là những gì chúng ta từng có, chúng ta đã hoàn thành vòng lặp và chúng ta có phần này, chèn một công cụ hoàn toàn mới.

Chúng ta chọn, và bạn không cần phải đi theo con đường tương tự, nhưng chúng ta nói rằng vì điều này được xây dựng dựa trên công cụ chụp ảnh màn hình (screenshot tool), thì chỉ tạo công cụ mới này nếu công cụ chụp ảnh màn hình chưa bị loại bỏ hoàn toàn. Hoàn toàn tùy chọn, chỉ là những gì chúng ta đã chọn làm trong trường hợp sử dụng cụ thể này. Và vì vậy, chúng ta có mô tả mới cho công cụ mới này, và chúng ta tạo một công cụ mới. Hãy xem mô tả ảnh chụp màn hình (tôi xin lỗi, mô tả).

Đó là một mô tả như bạn có thể mong đợi từ một mô tả của loại công cụ này: "Chụp ảnh màn hình đặc biệt cho mục đích làm bằng chứng." Và vì lời nhắc (prompt) khi nó mô tả luồng nói rằng điều này kết thúc bằng việc chụp nhanh để làm bằng chứng, tác nhân có thể sẽ biết chọn công cụ này thay vì công cụ chụp ảnh màn hình thông thường. Chúng ta yêu cầu nó chỉ sử dụng công cụ này khi thu thập bằng chứng và chúng ta cũng chỉ định cách thức thực hiện bằng chứng. Ví dụ, khi nó tạo một hình ảnh và muốn lưu nó, chúng ta muốn nó xác định ticket liên quan và đưa số ticket vào tên tệp đang được lưu.

Và vì vậy, bạn có thể thấy một ví dụ hay về cách chúng ta sẽ có hai công cụ. Tác nhân sẽ biết cách phân biệt khi nào sử dụng công cụ này hay công cụ kia, đặc biệt trong ngữ cảnh thu thập bằng chứng. Và khi nó chọn công cụ đó trong ngữ cảnh thu thập bằng chứng, điều này sẽ khiến nó có những cân nhắc khác nhau khi chọn tên hình ảnh, chẳng hạn. Và bạn có thể làm nhiều thứ khác, bạn có thể thêm các guardrails hoặc các hành động xác định cụ thể cho công cụ này, chẳng hạn. Vì vậy, thực sự là không giới hạn, thế giới là của bạn, và knocker giải quyết tất cả.

Các Công Cụ Như Hàm Xác Định (Deterministic Functions)

Đây là điểm thứ năm và cuối cùng của chúng ta, mà chúng ta đã đề cập ngay từ đầu bài nói chuyện: coi các công cụ như các hàm xác định (deterministic functions) hoặc các hàm có thể gọi được (callable functions). Đôi khi chúng ta nhận được tất cả các hàm tuyệt vời này, tất cả mã này từ những người ở các nhóm bên thứ ba, trong trường hợp của chúng tôi là nhóm Playwright. Họ đã cung cấp cho chúng tôi tất cả mã rất hay này, và chúng ta có thể gọi mã này bên ngoài luồng tác nhân (agentic flow), chỉ cần gọi nó, chỉ cần bỏ qua mô tả và chỉ cần sử dụng hàm mà họ đã cung cấp cho chúng ta.

Chúng ta sử dụng điều đó ở đâu? Tôi không biết bạn có nhớ không, nhưng khi chúng ta lần đầu xem codebase, chúng ta có một hàm gọi là login to buzz và chúng ta nói rằng chúng ta sẽ quay lại nó. Đây là lúc chúng ta kết thúc vòng lặp đó. Hãy cùng xem.

Quay lại đầu tệp main.py của chúng ta, chúng ta cuộn xuống. Đây là v4 đã được nhập. Nhưng hôm nay chúng ta quan tâm đến một điều khác, đó là phần này. Khi chúng ta mới bắt đầu, chúng ta định nghĩa MCP client, chúng ta định nghĩa một class triển khai get tools, chúng ta lấy các công cụ của mình và điều đầu tiên chúng ta làm là có hàm xác định này gọi là login to buzz. Chỉ sau khi chúng ta đăng nhập vào buzz, chúng ta mới thực sự tạo một tác nhân và sau đó chúng ta cung cấp cho nó tất cả các tin nhắn cần thiết và gọi nó.

Vậy tại sao việc đăng nhập lại có tính xác định ở đây? Chà, có vẻ như việc đăng nhập khá phức tạp, bởi vì đây lại là một ví dụ minh họa, nhưng trong một sản phẩm thực tế, chúng ta cần đăng nhập vào hệ thống của mình, chúng ta cần đăng nhập vào hệ thống của client. Và mỗi client có thể có cơ chế đăng nhập khác nhau và chúng có thể phức tạp, có thể có secrets. Nhiều thứ có thể làm cho việc này trở nên phức tạp.

Vì vậy, một mặt nó phức tạp, và mặt khác, đó là một hành động mà chúng ta sẽ luôn muốn thực hiện; không có luồng tác nhân nào cho spec reviewer mà không bắt đầu bằng đăng nhập. Và vì vậy, chúng ta sử dụng các công cụ mà chúng ta nhận được từ MCP server để đạt được điều này. Chúng ta chỉ không để tác nhân tự cố gắng thực hiện vì chúng ta thấy nó đã mang lại những kết quả không hỗ trợ. Vì vậy, đối với những trường hợp sử dụng rất cụ thể, đôi khi bạn có thể muốn tự mình giải quyết vấn đề.

Ở đây, nếu chúng ta đi vào hàm, không có nhiều điều đang xảy ra. Lại là ví dụ minh họa, sản phẩm thực tế hoạt động rất khác, nhưng ở đây tôi chỉ ẩn một số JWT tokens dưới dạng environment variables, và hàm này chấp nhận tất cả các công cụ từ MCP server. Chúng ta chọn những công cụ mình muốn, và cốt lõi là chúng ta sẽ inject các JWT tokens này vào local storage của browser. Và sau đó khi chúng ta nhấp vào nút đăng nhập, chúng ta sẽ đăng nhập như thể có phép màu.

Vì vậy, chúng ta chỉ thực hiện việc này một cách xác định. Khi chúng ta đã đăng nhập, chúng ta nắm quyền và trao cho tác nhân. Chúng ta nói: "Bạn đã đăng nhập. Bạn có thể bắt đầu." Và đó là cách chúng ta giảm gánh nặng cho tác nhân khỏi hành động hơi cồng kềnh mà nó cần thực hiện, điều mà chúng ta có thể tự làm mà không làm phiền tác nhân và context của nó. Tuyệt vời, điều đó đơn giản hóa mọi thứ, ít nhất là đối với chúng ta.

Chạy Thử Nghiệm Và Xác Minh

Ôi, suýt quên, tôi vẫn nợ bạn một điều cuối cùng. Tôi nghĩ chúng ta nên khởi động hệ thống này ngay bây giờ với tất cả các cải tiến và xem kết quả. Chúng ta đã thất bại trong lần chạy trước phải không? Được rồi, hãy xem nó hoạt động như thế nào.

Quay trở lại codebase quen thuộc, vòng lặp chính của chúng ta và chúng ta chạy nó. Chúng ta không cần điểm dừng (breakpoint) nữa. Tôi nghĩ tôi đã bỏ nó ra rồi. Vâng, và đây chỉ là đang chạy. Được rồi, vì vậy điều này sẽ bắt đầu bằng cách thực hiện tất cả phép thuật JWT ở phía sau, mà bây giờ chúng ta đã biết cách nó hoạt động. Và hãy xem nó diễn ra như thế nào. Tôi sẽ dành thời gian để nhắc bạn rằng chúng ta đã cung cấp cho nó một ticket và một thiết kế, và nó cần phải xem drawer này. Đó là những gì nó đang thực sự làm bây giờ.

Được rồi, nó đã tải lại. Tôi nghĩ có lẽ các JWT tokens đã có hiệu lực. Nó đang đi vào trang chủ của chúng ta có tên là changes. Và nó có lẽ sẽ thực hiện một chút reasoning (suy luận) và nó sẽ cần tìm cách điều hướng trong hệ thống đến tab agents. Nó không phải lúc nào cũng hiển thị. Nó có nhiều độ trễ và lag (độ trễ) ít nhất là theo kinh nghiệm của chúng ta. Nhưng nó đã chụp một ảnh màn hình làm bằng chứng. Nó đã hoàn thành. Hãy xem nó đã làm gì.

Nó nói rằng điều này đã qua. Nó tuyên bố rằng cấu hình có mặt và bao gồm các phần cần có. Nó có một ảnh chụp màn hình, ảnh chụp màn hình có tên tệp bao gồm ticket như chúng ta đã nói. Nó có reasoning. Hãy xem ảnh chụp màn hình. Vì vậy, bạn thấy hình ảnh chúng ta cung cấp là chế độ tối (dark mode) và nó đang điều hướng ở chế độ sáng (light mode) và nó đã chụp được và trông rất tuyệt. Có vẻ như nó đã hoàn thành và chính xác.

Bây giờ tôi phải nói rằng nó đã thấy một cấu hình, một drawer. Nó đã thấy mọi thứ lẽ ra phải có trong đó. Nó có thể không phải là pixel perfect (hoàn hảo từng pixel). Nhưng xác minh pixel perfect là điều mà chúng ta đã làm việc rất chăm chỉ trong sản phẩm thực tế của mình. Vì vậy, ngoài ví dụ minh họa này, pixel perfect thực sự hoạt động vì nó cực kỳ quan trọng đối với xác thực front-end, đảm bảo padding và margins và tất cả style đúng như mong muốn.

Tổng Kết

Tuyệt vời. Với việc đó đã hoàn thành, tôi nghĩ đã đến lúc nói lời tạm biệt. Vì vậy, tôi nghĩ đây là lúc mọi lời nói bắt đầu sẵn sàng kết thúc. Hãy nhìn server của chúng ta, nó thật tuyệt vời. Nó đẹp đẽ, nó đang hoạt động, đèn xanh nhấp nháy, động cơ gầm rú, GPU hoạt động, hàng triệu spec reviewer đang được thực thi và tỷ lệ chấp nhận rất cao. Cảm ơn vì tất cả sự giúp đỡ của bạn.

Hãy cùng thực hiện bản tóm tắt cuối cùng này trước khi chia tay. Như chúng ta đã nói, hôm nay chúng ta đã xem xét các công cụ tác nhân (agentic tools), cho dù chúng đến từ các thư viện, MCP server hay bất kỳ nơi nào khác. Chúng ta thấy rằng đôi khi chúng sẽ thất bại ngay lập định. Chúng có thể rất chung chung, có thể không được điều chỉnh đủ cho trường hợp sử dụng của chúng ta, và việc điều chỉnh chúng là điều sẽ khiến các tác nhân của chúng ta nổi bật.

Đôi khi chúng ta muốn quản lý các công cụ và giảm tải cho cửa sổ ngữ cảnh (context window). Đôi khi chúng ta muốn có các mô tả dài và nhiều hơn nữa về cả hai công cụ của chúng ta. Vì vậy, không có giải pháp nào phù hợp với tất cả (one size fits all). Chủ yếu là câu hỏi làm thế nào để tôi điều chỉnh các công cụ để phù hợp nhất với trường hợp sử dụng của mình. Đôi khi chúng sẽ có tính xác định, đôi khi chúng sẽ linh hoạt. Điều đó phụ thuộc và bạn sẽ cần phải mày mò với nó và biến nó thành của riêng mình, đồng thời nỗ lực để có được thiết lập tốt nhất có thể để đạt được mục tiêu của mình.

Tôi hy vọng điều này đã cung cấp cho bạn một vài gợi ý, những điều bạn có thể thử. Điều này thật tuyệt vời và rất vui. Tôi sẽ lên đây bây giờ vì tôi có một lời quảng cáo không công khai sau khi cảm ơn bạn đã lắng nghe, vì vậy hãy luôn thoải mái liên hệ. Hẹn gặp lại các bạn trong lần tới. Xin chào!