- GitHub's MCP server gặp thử thách lớn về hiệu suất tác nhân do quá tải công cụ và tràn cửa sổ ngữ cảnh, bởi người dùng có xu hướng giữ cấu hình mặc định dù đã có giải pháp tối ưu.
- Đội ngũ đã nỗ lực đáng kể trong việc giảm thiểu ngữ cảnh và mã thông báo bằng cách tối ưu hóa các tập công cụ và tinh chỉnh đầu ra, đồng thời cải thiện tỷ lệ thành công của công cụ lên trên 95% thông qua tối ưu hóa phía máy chủ.
- Bảo mật là mối quan tâm hàng đầu, giải quyết các vấn đề về mã thông báo truy cập kém an toàn và các cuộc tấn công injection, đồng thời thúc đẩy việc sử dụng OAuth với PKCE và quản lý quyền truy cập công cụ dựa trên phạm vi mã thông báo.
Lessons from Scaling GitHub's Remote MCP Server — Sam Morrow, GitHub
- Tối ưu hóa ngữ cảnh và mã thông báo: Giảm thiểu đáng kể lượng ngữ cảnh và mã thông báo tiêu thụ bằng cách tập trung các công cụ cụ thể, nhóm các công cụ liên quan (như CRUD) và tinh chỉnh đầu ra của các lệnh gọi công cụ.
- Thiết kế cho người dùng mặc định: Chấp nhận rằng hầu hết người dùng sẽ sử dụng cài đặt mặc định; do đó, hãy đảm bảo các cấu hình mặc định là an toàn, hiệu quả và cung cấp trải nghiệm tốt nhất mà không yêu cầu cấu hình thủ công phức tạp.
- Xử lý logic phức tạp ở phía máy chủ: Thực hiện các cuộc gọi API phức tạp và logic cần nhiều vòng lặp ở phía máy chủ để giảm lượt đi về, tiết kiệm ngữ cảnh và tăng tỷ lệ thành công của tác nhân.
- Đánh giá công cụ tổng thể: Thay vì tối ưu hóa từng mô tả công cụ riêng lẻ, hãy kiểm tra và điều chỉnh chúng cùng nhau như một tập hợp để đảm bảo chúng được gọi vào đúng thời điểm và không cạnh tranh lẫn nhau.
- Ưu tiên các giải pháp xác thực an toàn: Tránh sử dụng mã thông báo dạng văn bản thuần túy bằng cách khuyến khích sử dụng vòng khóa hệ thống hoặc bộ lưu trữ được mã hóa, và triển khai các giao thức OAuth mạnh mẽ (như OAuth 2.1 với PKCE) cho các ứng dụng client.
- Quản lý quyền truy cập công cụ động: Tự động lọc các công cụ có sẵn dựa trên phạm vi quyền hạn của mã thông báo xác thực người dùng, hỗ trợ nguyên tắc quyền hạn tối thiểu và giảm thiểu nguồn gây lỗi.
- Triển khai kiến trúc máy chủ phi trạng thái: Xây dựng máy chủ hoàn toàn phi trạng thái, sử dụng các giải pháp như Redis để lưu trữ phiên, nhằm tăng khả năng mở rộng và độ bền.
- Chuẩn bị cho tự động hóa và phát hiện công cụ: Hướng tới một tương lai nơi việc khám phá máy chủ và lựa chọn công cụ hoàn toàn tự động, làm cho trải nghiệm người dùng liền mạch và không yêu cầu họ phải hiểu về các cơ chế dưới nền như MCP.
- MCP — Máy chủ MCP
- Agent — Tác nhân
- Context window — Cửa sổ ngữ cảnh
- Tool — Công cụ
- Token — Mã thông báo
- Specification — Đặc tả kỹ thuật
- Prompt injection — Tấn công injection lệnh
- OAuth — (Giữ nguyên)
- Stateless server — Máy chủ phi trạng thái
- Tool call — Lượt gọi công cụ
Giới thiệu và Hành trình MCP của GitHub
Xin chào London! Tôi hy vọng mọi người đã có khoảng thời gian tuyệt vời tại sự kiện AI Engineer Europe. Có rất nhiều diễn giả xuất sắc. Tôi đã xem các bài nói chuyện và trò chuyện với mọi người trong nhiều ngày qua, thật sự rất bổ ích. Tôi là Sam, kỹ sư phát triển chủ chốt (lead developer) cho máy chủ MCP của GitHub. Và hôm nay, tôi ở đây để chia sẻ về những thử thách mà chúng tôi đã đối mặt khi xây dựng và mở rộng máy chủ từ xa của mình, cũng như cách chúng tôi vượt qua chúng.
Trước khi bắt đầu, tôi thích tạo sự tương tác một chút. Xin hãy nhanh chóng giơ tay cho tôi biết: Ai đã sử dụng máy chủ MCP? Tốt, tốt. Ai đã sử dụng GitHub Copilot? Ai có hot take (quan điểm gây tranh cãi) nào không? Không à? Vâng, có ai đang xây dựng máy chủ hay ứng dụng client không? Ồ, khá nhiều đấy. Và có ai đã đóng góp vào specification (đặc tả kỹ thuật) không? Ồ, vâng, tôi thấy một người! Đó là người đầu tiên tôi thấy, ngoại trừ sự kiện MCP dev summit (hội nghị thượng đỉnh nhà phát triển MCP). Có khá nhiều người ở đó. Dù sao đi nữa, thật tuyệt vời khi thấy nhiều cánh tay như vậy. Tôi rất vui vì mình đã đến đúng nơi.
Hành trình MCP của chúng tôi bắt đầu, ít nhất là công khai, vào tháng Tư năm ngoái. Chúng tôi đã mở mã nguồn MCP cục bộ của mình cũng vào tháng Tư năm ngoái và giờ đây nó vừa tròn một tuổi. Tôi thực sự rất phấn khích về điều đó. Thời điểm đó, có một làn sóng chú ý khổng lồ. Chúng tôi là kho lưu trữ GitHub được gắn star nhiều nhất trong tuần đó. Sự tiếp cận rộng rãi này đã mang lại cho chúng tôi một lượng lớn đóng góp từ cộng đồng, nhanh chóng lấp đầy những khoảng trống về khả năng hỗ trợ nền tảng mà mọi người muốn thêm công cụ và nhiều thứ khác.
Thử thách về Số lượng Công cụ và Cửa sổ Ngữ cảnh
Tuy nhiên, không phải mọi thứ đều hoàn hảo. Sau khoảng một tháng với các tính năng mới, các agent (tác nhân), ở một khía cạnh nào đó, lại hoạt động kém hiệu quả hơn trong việc sử dụng GitHub và các cửa sổ ngữ cảnh thì bị tràn nhanh hơn. Chúng tôi đã chọn, tôi nghĩ là, hơn 100 công cụ. Chắc chắn vào thời điểm đó, số lượng này là quá nhiều. LangChain đã công bố nghiên cứu vào tháng Hai về chính xác những vấn đề mà chúng tôi đang gặp phải: Nhiều công cụ hơn không làm cho agent tốt hơn. Chúng trở nên bối rối và hay quên. Hay nói chính xác hơn, không phải là nhiều công cụ nói chung, mà là nhiều ngữ cảnh và nhiều công cụ được nhồi trực tiếp vào ngữ cảnh.
Vâng, GitHub là một nền tảng thực sự rộng lớn. Chúng tôi đã cung cấp các công cụ cho các repo, issue, PR (pull request), action, project và thậm chí nhiều thứ khác nữa. Nhưng phần khó khăn trong việc giải quyết vấn đề này là chúng tôi không ngăn người dùng có từng công cụ riêng lẻ mà họ cần và sử dụng. Và có thể nói rằng, lượng người dùng của chúng tôi khá đa dạng. Có lẽ ngay cả trên nền tảng GitHub hiện tại, cũng có thể có một hoặc hai clause [transcript bị gián đoạn]. Nhân tiện, có một đội ngũ chúng tôi cùng làm việc về vấn đề này, không chỉ riêng tôi. Và đội của tôi thật tuyệt vời.
Các Giải pháp Ban đầu và Thói quen Người dùng
Để cố gắng khắc phục một số vấn đề này, tôi đã nhanh chóng thêm vào khái niệm tool sets (tập công cụ), một dạng nhóm các công cụ sản phẩm liên quan. Người dùng có thể chọn những công cụ họ muốn và cấu hình chúng. Tôi cũng thêm một tính năng lựa chọn công cụ động, nơi các agent có thể khám phá các tập hợp công cụ và sau đó bật chúng theo từng khối. Mặc dù chúng tôi chưa bao giờ phát hành nó, tôi đã tạo một phiên bản RAG (Retrieval-Augmented Generation) tương tự để tìm kiếm và khám phá công cụ dựa trên ngữ nghĩa.
Nhưng bạn nghĩ điều gì đã xảy ra dù đã có tất cả những nỗ lực này? Mọi người đều sử dụng cài đặt mặc định. Điều đó thực sự khó chịu vì theo một cách nào đó, chúng tôi đã có tất cả những giải pháp tinh tế này. Tất cả những gì chúng yêu cầu là người dùng phải cấu hình JSON một chút. Và hầu hết người dùng thì không làm vậy.
Có lẽ đây một phần là vấn đề về specification, bởi vì mọi đề xuất từ trước đến nay để nhóm các công cụ vào specification MCP đều bị từ chối vì nhiều lý do khác nhau. Đã có nhiều nỗ lực nhưng không thành công. Và theo một nghĩa nào đó, mỗi mode hoặc cấu hình chúng tôi thêm vào, có thể được coi là đang che đậy những lỗ hổng tiềm ẩn, hoặc những lỗ hổng trong các triển khai client. Chẳng hạn, chúng tôi có chế độ chỉ đọc (read-only mode). Khoảng 17% người dùng của chúng tôi sử dụng nó, và nó tương ứng một-một với chú thích gợi ý chỉ đọc (read-only hint annotation). Nhưng không có client nào hiển thị điều đó như một phương pháp lọc máy chủ. Tôi nghĩ một số gateway hiện nay đã làm được điều đó, nhưng dù sao đi nữa, đây là một chiến thắng dễ dàng và thú vị cho các trường hợp sử dụng trong doanh nghiệp, nơi mọi người thường chỉ muốn quyền truy cập đọc.
Giảm thiểu Ngữ cảnh và Tối ưu hóa Mã thông báo
Vâng, chúng tôi cần tìm ra những giải pháp tốt hơn để giảm thiểu ngữ cảnh. Bạn không cần phải quá lo lắng về các chi tiết cụ thể, vì thông tin này hiện đã cũ rồi. Nhưng chúng tôi đã bắt đầu cố gắng tối ưu hóa và xem xét các usage pattern (kiểu sử dụng) trên máy chủ từ xa của mình. Ban đầu, chúng tôi đã giảm lượng ngữ cảnh được sử dụng bằng cách tập trung các công cụ cụ thể hơn vào các trường hợp tổng quát và dựa trên mức độ sử dụng, đạt được khoảng 49% mức giảm tải ban đầu. Sau đó, chúng tôi tiếp tục nhóm các công cụ CRUD (Create, Read, Update, Delete) và giảm mức sử dụng xuống thấp hơn nữa. Tôi nghĩ rằng bạn sẽ có khoảng 40 công cụ nếu sử dụng cấu hình mặc định. Và sau đó, bạn có thể mở rộng hoặc thu hẹp số lượng đó dựa trên sở thích cá nhân của mình.
Vâng, nó rất dễ tùy chỉnh. Gần đây, chúng tôi cũng đã nỗ lực rất lớn để giảm mã thông báo đầu ra của nhiều công cụ. Ví dụ này cho thấy, chỉ bằng cách tinh chỉnh chính xác những gì đi kèm với list pull requests, chúng tôi thực sự đã giảm hơn 75% mã thông báo được sử dụng trong đầu ra. Vì vậy, về mức độ tiêu thụ mã thông báo của máy chủ GitHub, đó là một mục tiêu luôn thay đổi. Chúng tôi liên tục điều chỉnh để cải thiện nó. Nếu bạn đã lâu không sử dụng, có lẽ nó đã rất khác so với vài tháng trước. Dù sao đi nữa, chúng tôi vẫn chưa loại trừ các cách tiếp cận tiên tiến hơn như code mode và chúng tôi luôn thử nghiệm nội bộ.
Cải thiện Tỷ lệ Thành công của Công cụ
Tiếp nối điều này, chúng tôi cũng đã đào sâu vào dữ liệu của mình và tìm thấy thêm một số cơ hội. Chúng tôi đã nỗ lực lớn để giảm thiểu lỗi công cụ. Tỷ lệ thành công hiện tại của chúng tôi, tôi nghĩ là, trên 95%. Tuy nhiên, không phải tất cả các lỗi đều có thể ngăn chặn được, bởi vì các agent không nhất thiết phải biết chúng có quyền phù hợp trên repo nào. Chúng vẫn có thể bị "ảo giác".
Nhưng chúng tôi đã có thể xác định được số lượng đáng kể các lĩnh vực có thể được khắc phục chủ yếu bằng cách mã hóa agent intent (ý định của tác nhân) vào tool surface (giao diện công cụ) của chúng tôi. Và bạn có thể phải thực hiện năm cuộc gọi API để làm cho nó mạnh mẽ hơn. Nhưng trong trường hợp đó, chúng tôi thực hiện điều đó ở phía máy chủ (server side) để giảm các round trip (lượt đi về), bởi vì điều đó giúp tiết kiệm ngữ cảnh, tiết kiệm thời gian và thường mang lại trải nghiệm tốt hơn đáng kể, giúp các agent thành công hơn.
Đánh giá Công cụ (Evals)
Và vâng, chúng tôi cũng bắt đầu chạy eval vào năm ngoái. Tôi sẽ không đi sâu vào chi tiết. Đường dẫn đó sẽ đưa bạn đến một bài viết blog mà các đồng nghiệp của tôi đã viết về việc thực hiện nó. Nhưng một trong những ý chính là thay vì tối ưu hóa vi mô (micro-optimizing) các mô tả công cụ riêng lẻ, bạn cố gắng kiểm tra chúng với nhau để đảm bảo rằng chúng được gọi vào đúng thời điểm và không bị gọi vào sai thời điểm. Để trong một tập hợp, chúng không cạnh tranh nhau để có mô tả công cụ hoàn hảo khiến agent luôn gọi nó một cách tệ hại, cũng như không để xảy ra điều ngược lại. Vì vậy, bạn cần cố gắng làm cho điều đó càng chặt chẽ càng tốt. Đây có thể là một chủ đề cho cả một bài nói chuyện khác.
Thử thách Bảo mật: Mã thông báo và Tấn công Injection
Mặt khác, bảo mật là một mối đe dọa thường trực trong tất cả những điều này. Tôi đã thấy rất nhiều người nói về vấn đề này. Và đó là một vấn đề thực sự đối với chúng tôi ở một số khía cạnh, bởi vì chúng tôi có rất nhiều người đang sử dụng mã thông báo truy cập plain text (dạng văn bản thuần túy) cho MCP một cách công khai. Chúng thường được lưu trữ ở đâu đó mà agent có thể truy cập. Chúng thường có tuổi thọ dài, thường có quyền quá mức (overprivileged), và cứ nằm đó chờ bị lạm dụng.
Người dùng cuối, tôi không nghĩ họ chọn cách này. Thực tế là rất khó để vừa làm cho cấu hình dễ dàng vừa đảm bảo an toàn cùng lúc. Và các client phải sử dụng system key rings (vòng khóa hệ thống) hoặc bộ lưu trữ được mã hóa (encrypted storage), giống như VS Code đã làm. Nhưng spec của MCP cũng cung cấp một cách tốt hơn với Remote HTTP, điều này cũng đã có từ tháng Tư năm ngoái. Tất nhiên, chúng tôi đã chấp nhận cách này. Và chúng tôi muốn tạo ra một con đường kết nối an toàn với ít rào cản nhất. Chúng tôi không muốn người dùng phải tải xuống một runtime cục bộ.
Và máy chủ từ xa của chúng tôi hỗ trợ OAuth 2.1. Đội của tôi thậm chí còn giúp thêm hỗ trợ Proof Key for Code Exchange (thường được gọi là PKCE hoặc Pixie) vào máy chủ cấp phép (authorization server) của GitHub để cải thiện security posture (tư thế bảo mật) cho các ứng dụng client.
Nhưng như tôi đã nói, chúng tôi hy vọng OAuth sẽ là con đường ít trở ngại nhất. Và một lần nữa, có lẽ một số bạn đã biết điều gì đã xảy ra. Mọi người đều mong đợi chúng tôi hỗ trợ đăng ký client động (dynamic client registration). Và đối với chúng tôi, nó tạo ra nhiều vấn đề hơn là giải quyết được. Bởi vì nếu bạn triển khai nó một cách đúng đắn, rất khó để tránh sự tăng trưởng không giới hạn của các cơ sở dữ liệu ứng dụng và những thách thức về cách phân loại chúng cho các giới hạn rate limit (tỷ lệ yêu cầu). Hơn nữa, không có app identity (danh tính ứng dụng) đáng tin cậy. Vì vậy, chúng tôi đã cân nhắc và từ chối nó. Chúng tôi cảm thấy đó là một sai lầm có chủ ý tốt. Và chúng tôi không phải là máy chủ cấp phép duy nhất không hỗ trợ điều này. Ngay cả bản thân MCP cũng đã quyết định rằng client ID metadata có lẽ là hướng đi đúng đắn. Tôi không thể hứa rằng chúng tôi sẽ hỗ trợ nó. Nhưng tôi hứa rằng tôi đang cố gắng để chúng tôi hỗ trợ nó. Và điều đó sẽ giúp việc đăng nhập dễ dàng hơn rất nhiều. Nhưng chúng ta sẽ nói thêm về điều đó trong tương lai.
Ngoài ra, nói về bảo mật, một số bạn có thể đã thấy điều này. Đó là một ngày thú vị. Invariant Labs đã công bố một cuộc tấn công prompt injection X-Fill được thực hiện chính xác để lấy dữ liệu riêng tư từ GitHub. Vấn đề là, họ đã chỉ đích danh máy chủ MCP của GitHub. Và tôi nghĩ rằng chúng tôi thực sự cung cấp các công cụ có thể kích hoạt điều đó nếu bạn chỉ cần bật tất cả chúng lên.
Nhưng điều này áp dụng cho hầu hết mọi thiết lập agent. Dù chúng có sử dụng MCP hay không, hay chúng có sử dụng GitHub MCP hay không. Ví dụ như những vấn đề về lethal trifecta (bộ ba gây chết người) mà tôi sẽ không nhắc lại chi tiết ở đây, vì tôi nghĩ nhiều bạn có thể đã biết. Hoặc bạn có thể tìm kiếm thông tin về nó. Bài đăng blog của Simon Wilson về chủ đề này rất xuất sắc. Nhưng tính hữu dụng của các agent đang mâu thuẫn trực tiếp với việc bảo vệ những thông tin này. Đây là một lĩnh vực đang được tích cực nghiên cứu để tìm cách ngăn chặn những vấn đề này. Tuy nhiên, nó vẫn chưa được giải quyết và không hề là vấn đề riêng của GitHub.
Chúng tôi có những người dùng với các risk profile (hồ sơ rủi ro) rất khác nhau. Chúng tôi thậm chí có những người có các phiên bản máy chủ GitHub Enterprise được air-gapped (cách ly mạng) trong môi trường bảo mật cao hơn nhiều. Và sau đó, rõ ràng là các clubbers (người dùng thông thường), v.v., cũng trực tiếp chạy trên GitHub với quyền truy cập mã thông báo đầy đủ vào agent và mọi thứ. Điều đó cũng rất thú vị. Và tôi không có ý phán xét bất kỳ điều gì trong số này. Chỉ là thật tuyệt khi thấy mọi người làm gì và liệu chúng tôi có thể hỗ trợ các trường hợp sử dụng (use cases) và security posture khác nhau trong khi mọi người đang thử nghiệm những thứ này hay không.
Quản lý Công cụ bằng Quyền truy cập
Và chúng tôi cũng dựa vào auth (xác thực) để quản lý các công cụ. Đây là điều mà tôi khá hài lòng. Nếu bạn đăng nhập vào GitHub MCP bằng một mã thông báo cụ thể, chúng tôi sẽ ngay lập tức lọc các công cụ dựa trên các scope (phạm vi quyền hạn) mà mã thông báo đó có. Bạn không cần phải làm gì khác ngoài việc cung cấp mã thông báo.
Với OAuth, chúng tôi hỗ trợ step-up, tức là chúng tôi có thể trả về một scope challenge (thử thách phạm vi quyền hạn) và sau đó sẽ tương tác hỏi người dùng xem họ có muốn cho phép scope đó hay không. Nếu người dùng đồng ý, bạn có thể tiếp tục thực hiện cuộc gọi công cụ. Nó sẽ không thất bại, điều mà tôi nghĩ cũng rất tốt. Và VS Code, ví dụ, hỗ trợ điều đó. Ban đầu tôi đã làm việc với họ về tính năng này bởi vì họ đã có một mã thông báo để sử dụng GitHub. Điều họ muốn là nếu mã thông báo được tích hợp sẵn không có quyền sử dụng mọi thứ, thì thay vì chỉ thất bại, sẽ có một cơ chế cho người dùng thực hiện cài đặt sạch (clean install) và sau đó upscoping (nâng cấp phạm vi quyền hạn) nếu họ cần.
Và cuối cùng, mã thông báo máy chủ (server tokens) nữa. Chúng không có trên các action hay các thứ tương tự. Chúng không có các công cụ dành riêng cho người dùng. Và bằng cách loại bỏ những thứ đó, chúng tôi chỉ đơn giản là loại bỏ các nguồn gây lỗi liên tục và đồng thời giảm lãng phí ngữ cảnh.
Kiến trúc Máy chủ Phi trạng thái
Chúng tôi đã triển khai một thiết lập máy chủ hoàn toàn phi trạng thái (stateless server). Và chúng tôi đã sử dụng Redis để lưu trữ phiên (session storage). Đó là khả năng quan sát tiêu chuẩn (standard observability) trong stack của tôi. Đây không phải là một hình ảnh kỳ lạ. Nhưng tôi đoán một trong những điều kỳ lạ đối với một số người là rất nhiều người đang chạy một quy trình máy chủ MCP có trạng thái (stateful MCP server process) duy nhất và đã gặp khó khăn trong việc đưa nó về hình dạng này.
Nhưng đối với chúng tôi, chúng tôi đã làm một vài điều vì nó rất động. Nhưng một trong những điều thú vị mà chúng tôi đã làm là chúng tôi thực sự tạo ra một phiên bản máy chủ hoàn toàn mới (server instance), theo nghĩa SDK (Software Development Kit), trên mỗi yêu cầu duy nhất. Và chúng tôi thêm các công cụ vào đó ngay từ đầu. Vì vậy, bất kể cấu hình của bạn là gì, nó chỉ đơn giản là xây dựng nên điều này.
Mở rộng quy mô và Lượt gọi Công cụ
Và sau đó bạn nhận được những gì bạn đã yêu cầu hoặc những gì bạn được phép sử dụng, bởi vì một số thứ có chính sách ảnh hưởng đến việc bạn có công cụ hay không. Và vâng, chúng tôi đã có thể mở rộng quy mô đến thời điểm này. Chúng tôi tiết kiệm khoảng 7 triệu lượt gọi công cụ (tool calls) mỗi tuần. Và chúng tôi không có session affinity. Ngay cả các phiên (session), chúng tôi thường chỉ sử dụng chúng để xác định; đó là cách duy nhất để xác định client identity tự báo cáo đi qua MCPS. Vì vậy, điều này hữu ích cho chúng tôi để hiểu những client nào mọi người đang sử dụng với máy chủ (server). Vâng, chúng tôi sử dụng các phiên cho mục đích đó.
Các Tính năng Thử nghiệm và Ứng dụng MCP
Nhưng chúng tôi cũng muốn mang đến các thử nghiệm cho tất cả các bạn và mọi người. Và chúng tôi có một thứ đang ở chế độ Insiders mode. Tất cả những gì nó làm là bật một số feature flags và những thứ khác cho các thử nghiệm mà chúng tôi sẵn lòng cung cấp cho bất kỳ ai muốn sử dụng chúng. Và điều này chỉ đưa bạn đến tài liệu. Nhưng một ví dụ về điều mà chúng tôi chưa phát hành rộng rãi nhưng đang có trên Insiders là các ứng dụng MCP (MCP apps) của chúng tôi. Tôi đã thiết lập ví dụ trước khi đến đây. Thật tuyệt vời khi bạn nói chuyện với tác nhân (agent) mà có cơ hội chỉnh sửa issue do AI tạo ra, đặc biệt nếu bạn đang làm việc nhiều trong các dự án mã nguồn mở (open source) chuyên nghiệp. Và bạn muốn đảm bảo rằng đó là bài đăng của bạn, và nó sẽ không bị đóng như một thứ do bot tạo ra. Đây là một cơ chế human-in-the-loop (con người trong vòng lặp) tuyệt vời mà MCP cho phép. Ban đầu tôi không chắc mình sẽ thích nó đến mức nào, nhưng sau đó tôi đã yêu thích nó vì tôi quan tâm đến cách các issue và những thứ khác của mình được mọi người đón nhận. Và đây chỉ là một cách thực sự tuyệt vời để tôi có thể kiểm tra điều đó.
Tương lai của Sử dụng Công cụ và Tự động hóa
Vì vậy, vâng, về nơi tôi nghĩ nó sẽ đi đến, một điều gì đó tương tự, tôi nghĩ việc khám phá máy chủ (server discovery) trong tương lai gần hy vọng sẽ tự động. Và sử dụng công cụ (tool use) có lẽ sẽ trở nên có tính tổng hợp hơn, giống như bash hoặc piping tools và các công cụ khác truyền dữ liệu cho chúng, hoặc phương pháp code mode của CloudFavours, hoặc API Tìm kiếm Công cụ (Tool Search API) của Anthropic, vừa được ra mắt trong Claude Code vài tuần trước. Và OpenAI gần đây cũng đã thêm một API tương tự. Vì vậy, OpenAI cũng đã thêm một API tương tự. Và tôi hoàn toàn mong đợi rằng hàng nghìn công cụ sẽ trở nên bình thường rất sớm. Chúng tôi đang cố gắng giải quyết tất cả các vấn đề đã ngăn cản điều đó ngay từ đầu. Và tôi có thể sẽ đảo ngược nhiều quyết định về "ít công cụ hơn". Và người dùng hy vọng thậm chí sẽ không cần biết MCP là gì. Họ sẽ chỉ truyền đạt những gì họ muốn làm. Và thiết lập offset (offset setup) cũng như chọn công cụ (tool selection), mọi thứ sẽ trở nên thực sự tự động (autonomous). Và tôi không nghĩ chúng ta còn xa điều này, nhưng chúng ta đang ở trong một giai đoạn thử nghiệm (experimental phase) mà chúng ta chưa thực sự đạt được điều đó. Nhưng tôi nghĩ rằng các khung làm việc (harnesses) như Pye cũng rất thú vị bởi vì bạn có thể tự xây dựng một client kỳ lạ mà có thể tối ưu hóa điều này một cách thực sự tốt. Vì vậy, tôi khuyến khích mọi người thử nghiệm với các client kỳ lạ. Tôi cảm thấy bạn không bao giờ biết được, bạn có thể là người tiếp theo... Nếu bạn cực kỳ may mắn, bạn có thể là Claure tiếp theo. Bạn có thể xuất bản một thứ gì đó lan truyền (viral) đến mức thay đổi hoàn toàn trò chơi tác nhân (agentic game).
Thống kê và Sự tham gia của Cộng đồng
Tôi muốn kết thúc bằng một điểm nhấn ấn tượng và xem xét một số con số. Bản thân GitHub đã có hơn 11 triệu lượt tải xuống Docker của máy chủ IO (IO server) tiêu chuẩn của chúng tôi, mà đây cũng không phải là phiên bản được sử dụng nhiều nhất. Chúng tôi hiện có 126 người đóng góp (contributors) và hơn 2.300 issue và PR (pull request), với tần suất hơn bảy issue/PR mỗi ngày, liên tục trong hơn một năm nay, và tôi thực sự đã xem xét gần như mọi thứ cuối cùng. Vì vậy, đây là một năm khá bận rộn. Ý tôi là, các bài tóm tắt (summary posts) khác còn tệ hơn, nhưng tôi cũng yêu thích công việc này. Vì vậy, hãy tiếp tục làm điều đó nhé. Và vâng, chúng tôi có gần 4.000 fork, điều này làm tôi kinh ngạc. Tôi muốn biết những điều kỳ lạ hơn mà mọi người đã làm nhưng chưa đóng góp trở lại (contributed back). Vâng, gần 30.000 star. Và chúng tôi đang nhanh chóng đạt gần 8 triệu lượt gọi công cụ (tool calls) mỗi tuần. Và bản thân GitHub cũng đang đối mặt với một thách thức mới. Điều này thực sự căng thẳng, phải không? Và nó không có dấu hiệu chậm lại. Tôi vẫn muốn các bạn tiếp tục mở issue và PR cho chúng tôi. Chúng tôi sẽ xoay sở được, nhưng đây là một lãnh thổ mới. Và mọi thứ đều hơi hỗn loạn đối với mọi người, tôi nghĩ vậy, trong những ngày này. Và nó chỉ là thú vị và vui vẻ.
Lời kêu gọi thử nghiệm
Nhưng vâng, cảm ơn rất nhiều vì đã mời tôi. Tôi nghĩ tôi còn khoảng 30 giây. Tôi không biết có ai muốn hỏi gì không, nhưng tôi nghĩ những thứ như thử nghiệm MCP CLI và những thứ tương tự là một con đường thú vị. Tôi không nghĩ nó đã hoàn toàn được giải quyết, nhưng một điều bạn có thể làm: lấy các công cụ chỉ đọc (read-only tools) từ một MCP nào đó, gói nó trong một CLI, và chỉ cần cung cấp trợ giúp (help) thích hợp và xem tác nhân (agent) thực hiện như thế nào. Những thứ như vậy hiệu quả một cách đáng ngạc nhiên. Và như tôi đã nói, tôi muốn mọi người mày mò với những thứ này. Vì vậy, tôi khuyến khích bạn hãy thử nếu bạn quan tâm. Được rồi, tôi hết giờ rồi. Tôi sẽ trả lời bạn trực tiếp, nếu được.
TL;DR
- GitHub's MCP server gặp thử thách lớn về hiệu suất tác nhân do quá tải công cụ và tràn cửa sổ ngữ cảnh, bởi người dùng có xu hướng giữ cấu hình mặc định dù đã có giải pháp tối ưu.
- Đội ngũ đã nỗ lực đáng kể trong việc giảm thiểu ngữ cảnh và mã thông báo bằng cách tối ưu hóa các tập công cụ và tinh chỉnh đầu ra, đồng thời cải thiện tỷ lệ thành công của công cụ lên trên 95% thông qua tối ưu hóa phía máy chủ.
- Bảo mật là mối quan tâm hàng đầu, giải quyết các vấn đề về mã thông báo truy cập kém an toàn và các cuộc tấn công injection, đồng thời thúc đẩy việc sử dụng OAuth với PKCE và quản lý quyền truy cập công cụ dựa trên phạm vi mã thông báo.
Điểm chính
- Tối ưu hóa ngữ cảnh và mã thông báo: Giảm thiểu đáng kể lượng ngữ cảnh và mã thông báo tiêu thụ bằng cách tập trung các công cụ cụ thể, nhóm các công cụ liên quan (như CRUD) và tinh chỉnh đầu ra của các lệnh gọi công cụ.
- Thiết kế cho người dùng mặc định: Chấp nhận rằng hầu hết người dùng sẽ sử dụng cài đặt mặc định; do đó, hãy đảm bảo các cấu hình mặc định là an toàn, hiệu quả và cung cấp trải nghiệm tốt nhất mà không yêu cầu cấu hình thủ công phức tạp.
- Xử lý logic phức tạp ở phía máy chủ: Thực hiện các cuộc gọi API phức tạp và logic cần nhiều vòng lặp ở phía máy chủ để giảm lượt đi về, tiết kiệm ngữ cảnh và tăng tỷ lệ thành công của tác nhân.
- Đánh giá công cụ tổng thể: Thay vì tối ưu hóa từng mô tả công cụ riêng lẻ, hãy kiểm tra và điều chỉnh chúng cùng nhau như một tập hợp để đảm bảo chúng được gọi vào đúng thời điểm và không cạnh tranh lẫn nhau.
- Ưu tiên các giải pháp xác thực an toàn: Tránh sử dụng mã thông báo dạng văn bản thuần túy bằng cách khuyến khích sử dụng vòng khóa hệ thống hoặc bộ lưu trữ được mã hóa, và triển khai các giao thức OAuth mạnh mẽ (như OAuth 2.1 với PKCE) cho các ứng dụng client.
- Quản lý quyền truy cập công cụ động: Tự động lọc các công cụ có sẵn dựa trên phạm vi quyền hạn của mã thông báo xác thực người dùng, hỗ trợ nguyên tắc quyền hạn tối thiểu và giảm thiểu nguồn gây lỗi.
- Triển khai kiến trúc máy chủ phi trạng thái: Xây dựng máy chủ hoàn toàn phi trạng thái, sử dụng các giải pháp như Redis để lưu trữ phiên, nhằm tăng khả năng mở rộng và độ bền.
- Chuẩn bị cho tự động hóa và phát hiện công cụ: Hướng tới một tương lai nơi việc khám phá máy chủ và lựa chọn công cụ hoàn toàn tự động, làm cho trải nghiệm người dùng liền mạch và không yêu cầu họ phải hiểu về các cơ chế dưới nền như MCP.
Từ vựng
- MCP — Máy chủ MCP
- Agent — Tác nhân
- Context window — Cửa sổ ngữ cảnh
- Tool — Công cụ
- Token — Mã thông báo
- Specification — Đặc tả kỹ thuật
- Prompt injection — Tấn công injection lệnh
- OAuth — (Giữ nguyên)
- Stateless server — Máy chủ phi trạng thái
- Tool call — Lượt gọi công cụ
Nội dung chi tiết
Giới thiệu và Hành trình MCP của GitHub
Xin chào London! Tôi hy vọng mọi người đã có khoảng thời gian tuyệt vời tại sự kiện AI Engineer Europe. Có rất nhiều diễn giả xuất sắc. Tôi đã xem các bài nói chuyện và trò chuyện với mọi người trong nhiều ngày qua, thật sự rất bổ ích. Tôi là Sam, kỹ sư phát triển chủ chốt (lead developer) cho máy chủ MCP của GitHub. Và hôm nay, tôi ở đây để chia sẻ về những thử thách mà chúng tôi đã đối mặt khi xây dựng và mở rộng máy chủ từ xa của mình, cũng như cách chúng tôi vượt qua chúng.
Trước khi bắt đầu, tôi thích tạo sự tương tác một chút. Xin hãy nhanh chóng giơ tay cho tôi biết: Ai đã sử dụng máy chủ MCP? Tốt, tốt. Ai đã sử dụng GitHub Copilot? Ai có hot take (quan điểm gây tranh cãi) nào không? Không à? Vâng, có ai đang xây dựng máy chủ hay ứng dụng client không? Ồ, khá nhiều đấy. Và có ai đã đóng góp vào specification (đặc tả kỹ thuật) không? Ồ, vâng, tôi thấy một người! Đó là người đầu tiên tôi thấy, ngoại trừ sự kiện MCP dev summit (hội nghị thượng đỉnh nhà phát triển MCP). Có khá nhiều người ở đó. Dù sao đi nữa, thật tuyệt vời khi thấy nhiều cánh tay như vậy. Tôi rất vui vì mình đã đến đúng nơi.
Hành trình MCP của chúng tôi bắt đầu, ít nhất là công khai, vào tháng Tư năm ngoái. Chúng tôi đã mở mã nguồn MCP cục bộ của mình cũng vào tháng Tư năm ngoái và giờ đây nó vừa tròn một tuổi. Tôi thực sự rất phấn khích về điều đó. Thời điểm đó, có một làn sóng chú ý khổng lồ. Chúng tôi là kho lưu trữ GitHub được gắn star nhiều nhất trong tuần đó. Sự tiếp cận rộng rãi này đã mang lại cho chúng tôi một lượng lớn đóng góp từ cộng đồng, nhanh chóng lấp đầy những khoảng trống về khả năng hỗ trợ nền tảng mà mọi người muốn thêm công cụ và nhiều thứ khác.
Thử thách về Số lượng Công cụ và Cửa sổ Ngữ cảnh
Tuy nhiên, không phải mọi thứ đều hoàn hảo. Sau khoảng một tháng với các tính năng mới, các agent (tác nhân), ở một khía cạnh nào đó, lại hoạt động kém hiệu quả hơn trong việc sử dụng GitHub và các cửa sổ ngữ cảnh thì bị tràn nhanh hơn. Chúng tôi đã chọn, tôi nghĩ là, hơn 100 công cụ. Chắc chắn vào thời điểm đó, số lượng này là quá nhiều. LangChain đã công bố nghiên cứu vào tháng Hai về chính xác những vấn đề mà chúng tôi đang gặp phải: Nhiều công cụ hơn không làm cho agent tốt hơn. Chúng trở nên bối rối và hay quên. Hay nói chính xác hơn, không phải là nhiều công cụ nói chung, mà là nhiều ngữ cảnh và nhiều công cụ được nhồi trực tiếp vào ngữ cảnh.
Vâng, GitHub là một nền tảng thực sự rộng lớn. Chúng tôi đã cung cấp các công cụ cho các repo, issue, PR (pull request), action, project và thậm chí nhiều thứ khác nữa. Nhưng phần khó khăn trong việc giải quyết vấn đề này là chúng tôi không ngăn người dùng có từng công cụ riêng lẻ mà họ cần và sử dụng. Và có thể nói rằng, lượng người dùng của chúng tôi khá đa dạng. Có lẽ ngay cả trên nền tảng GitHub hiện tại, cũng có thể có một hoặc hai clause [transcript bị gián đoạn]. Nhân tiện, có một đội ngũ chúng tôi cùng làm việc về vấn đề này, không chỉ riêng tôi. Và đội của tôi thật tuyệt vời.
Các Giải pháp Ban đầu và Thói quen Người dùng
Để cố gắng khắc phục một số vấn đề này, tôi đã nhanh chóng thêm vào khái niệm tool sets (tập công cụ), một dạng nhóm các công cụ sản phẩm liên quan. Người dùng có thể chọn những công cụ họ muốn và cấu hình chúng. Tôi cũng thêm một tính năng lựa chọn công cụ động, nơi các agent có thể khám phá các tập hợp công cụ và sau đó bật chúng theo từng khối. Mặc dù chúng tôi chưa bao giờ phát hành nó, tôi đã tạo một phiên bản RAG (Retrieval-Augmented Generation) tương tự để tìm kiếm và khám phá công cụ dựa trên ngữ nghĩa.
Nhưng bạn nghĩ điều gì đã xảy ra dù đã có tất cả những nỗ lực này? Mọi người đều sử dụng cài đặt mặc định. Điều đó thực sự khó chịu vì theo một cách nào đó, chúng tôi đã có tất cả những giải pháp tinh tế này. Tất cả những gì chúng yêu cầu là người dùng phải cấu hình JSON một chút. Và hầu hết người dùng thì không làm vậy.
Có lẽ đây một phần là vấn đề về specification, bởi vì mọi đề xuất từ trước đến nay để nhóm các công cụ vào specification MCP đều bị từ chối vì nhiều lý do khác nhau. Đã có nhiều nỗ lực nhưng không thành công. Và theo một nghĩa nào đó, mỗi mode hoặc cấu hình chúng tôi thêm vào, có thể được coi là đang che đậy những lỗ hổng tiềm ẩn, hoặc những lỗ hổng trong các triển khai client. Chẳng hạn, chúng tôi có chế độ chỉ đọc (read-only mode). Khoảng 17% người dùng của chúng tôi sử dụng nó, và nó tương ứng một-một với chú thích gợi ý chỉ đọc (read-only hint annotation). Nhưng không có client nào hiển thị điều đó như một phương pháp lọc máy chủ. Tôi nghĩ một số gateway hiện nay đã làm được điều đó, nhưng dù sao đi nữa, đây là một chiến thắng dễ dàng và thú vị cho các trường hợp sử dụng trong doanh nghiệp, nơi mọi người thường chỉ muốn quyền truy cập đọc.
Giảm thiểu Ngữ cảnh và Tối ưu hóa Mã thông báo
Vâng, chúng tôi cần tìm ra những giải pháp tốt hơn để giảm thiểu ngữ cảnh. Bạn không cần phải quá lo lắng về các chi tiết cụ thể, vì thông tin này hiện đã cũ rồi. Nhưng chúng tôi đã bắt đầu cố gắng tối ưu hóa và xem xét các usage pattern (kiểu sử dụng) trên máy chủ từ xa của mình. Ban đầu, chúng tôi đã giảm lượng ngữ cảnh được sử dụng bằng cách tập trung các công cụ cụ thể hơn vào các trường hợp tổng quát và dựa trên mức độ sử dụng, đạt được khoảng 49% mức giảm tải ban đầu. Sau đó, chúng tôi tiếp tục nhóm các công cụ CRUD (Create, Read, Update, Delete) và giảm mức sử dụng xuống thấp hơn nữa. Tôi nghĩ rằng bạn sẽ có khoảng 40 công cụ nếu sử dụng cấu hình mặc định. Và sau đó, bạn có thể mở rộng hoặc thu hẹp số lượng đó dựa trên sở thích cá nhân của mình.
Vâng, nó rất dễ tùy chỉnh. Gần đây, chúng tôi cũng đã nỗ lực rất lớn để giảm mã thông báo đầu ra của nhiều công cụ. Ví dụ này cho thấy, chỉ bằng cách tinh chỉnh chính xác những gì đi kèm với list pull requests, chúng tôi thực sự đã giảm hơn 75% mã thông báo được sử dụng trong đầu ra. Vì vậy, về mức độ tiêu thụ mã thông báo của máy chủ GitHub, đó là một mục tiêu luôn thay đổi. Chúng tôi liên tục điều chỉnh để cải thiện nó. Nếu bạn đã lâu không sử dụng, có lẽ nó đã rất khác so với vài tháng trước. Dù sao đi nữa, chúng tôi vẫn chưa loại trừ các cách tiếp cận tiên tiến hơn như code mode và chúng tôi luôn thử nghiệm nội bộ.
Cải thiện Tỷ lệ Thành công của Công cụ
Tiếp nối điều này, chúng tôi cũng đã đào sâu vào dữ liệu của mình và tìm thấy thêm một số cơ hội. Chúng tôi đã nỗ lực lớn để giảm thiểu lỗi công cụ. Tỷ lệ thành công hiện tại của chúng tôi, tôi nghĩ là, trên 95%. Tuy nhiên, không phải tất cả các lỗi đều có thể ngăn chặn được, bởi vì các agent không nhất thiết phải biết chúng có quyền phù hợp trên repo nào. Chúng vẫn có thể bị "ảo giác".
Nhưng chúng tôi đã có thể xác định được số lượng đáng kể các lĩnh vực có thể được khắc phục chủ yếu bằng cách mã hóa agent intent (ý định của tác nhân) vào tool surface (giao diện công cụ) của chúng tôi. Và bạn có thể phải thực hiện năm cuộc gọi API để làm cho nó mạnh mẽ hơn. Nhưng trong trường hợp đó, chúng tôi thực hiện điều đó ở phía máy chủ (server side) để giảm các round trip (lượt đi về), bởi vì điều đó giúp tiết kiệm ngữ cảnh, tiết kiệm thời gian và thường mang lại trải nghiệm tốt hơn đáng kể, giúp các agent thành công hơn.
Đánh giá Công cụ (Evals)
Và vâng, chúng tôi cũng bắt đầu chạy eval vào năm ngoái. Tôi sẽ không đi sâu vào chi tiết. Đường dẫn đó sẽ đưa bạn đến một bài viết blog mà các đồng nghiệp của tôi đã viết về việc thực hiện nó. Nhưng một trong những ý chính là thay vì tối ưu hóa vi mô (micro-optimizing) các mô tả công cụ riêng lẻ, bạn cố gắng kiểm tra chúng với nhau để đảm bảo rằng chúng được gọi vào đúng thời điểm và không bị gọi vào sai thời điểm. Để trong một tập hợp, chúng không cạnh tranh nhau để có mô tả công cụ hoàn hảo khiến agent luôn gọi nó một cách tệ hại, cũng như không để xảy ra điều ngược lại. Vì vậy, bạn cần cố gắng làm cho điều đó càng chặt chẽ càng tốt. Đây có thể là một chủ đề cho cả một bài nói chuyện khác.
Thử thách Bảo mật: Mã thông báo và Tấn công Injection
Mặt khác, bảo mật là một mối đe dọa thường trực trong tất cả những điều này. Tôi đã thấy rất nhiều người nói về vấn đề này. Và đó là một vấn đề thực sự đối với chúng tôi ở một số khía cạnh, bởi vì chúng tôi có rất nhiều người đang sử dụng mã thông báo truy cập plain text (dạng văn bản thuần túy) cho MCP một cách công khai. Chúng thường được lưu trữ ở đâu đó mà agent có thể truy cập. Chúng thường có tuổi thọ dài, thường có quyền quá mức (overprivileged), và cứ nằm đó chờ bị lạm dụng.
Người dùng cuối, tôi không nghĩ họ chọn cách này. Thực tế là rất khó để vừa làm cho cấu hình dễ dàng vừa đảm bảo an toàn cùng lúc. Và các client phải sử dụng system key rings (vòng khóa hệ thống) hoặc bộ lưu trữ được mã hóa (encrypted storage), giống như VS Code đã làm. Nhưng spec của MCP cũng cung cấp một cách tốt hơn với Remote HTTP, điều này cũng đã có từ tháng Tư năm ngoái. Tất nhiên, chúng tôi đã chấp nhận cách này. Và chúng tôi muốn tạo ra một con đường kết nối an toàn với ít rào cản nhất. Chúng tôi không muốn người dùng phải tải xuống một runtime cục bộ.
Và máy chủ từ xa của chúng tôi hỗ trợ OAuth 2.1. Đội của tôi thậm chí còn giúp thêm hỗ trợ Proof Key for Code Exchange (thường được gọi là PKCE hoặc Pixie) vào máy chủ cấp phép (authorization server) của GitHub để cải thiện security posture (tư thế bảo mật) cho các ứng dụng client.
Nhưng như tôi đã nói, chúng tôi hy vọng OAuth sẽ là con đường ít trở ngại nhất. Và một lần nữa, có lẽ một số bạn đã biết điều gì đã xảy ra. Mọi người đều mong đợi chúng tôi hỗ trợ đăng ký client động (dynamic client registration). Và đối với chúng tôi, nó tạo ra nhiều vấn đề hơn là giải quyết được. Bởi vì nếu bạn triển khai nó một cách đúng đắn, rất khó để tránh sự tăng trưởng không giới hạn của các cơ sở dữ liệu ứng dụng và những thách thức về cách phân loại chúng cho các giới hạn rate limit (tỷ lệ yêu cầu). Hơn nữa, không có app identity (danh tính ứng dụng) đáng tin cậy. Vì vậy, chúng tôi đã cân nhắc và từ chối nó. Chúng tôi cảm thấy đó là một sai lầm có chủ ý tốt. Và chúng tôi không phải là máy chủ cấp phép duy nhất không hỗ trợ điều này. Ngay cả bản thân MCP cũng đã quyết định rằng client ID metadata có lẽ là hướng đi đúng đắn. Tôi không thể hứa rằng chúng tôi sẽ hỗ trợ nó. Nhưng tôi hứa rằng tôi đang cố gắng để chúng tôi hỗ trợ nó. Và điều đó sẽ giúp việc đăng nhập dễ dàng hơn rất nhiều. Nhưng chúng ta sẽ nói thêm về điều đó trong tương lai.
Ngoài ra, nói về bảo mật, một số bạn có thể đã thấy điều này. Đó là một ngày thú vị. Invariant Labs đã công bố một cuộc tấn công prompt injection X-Fill được thực hiện chính xác để lấy dữ liệu riêng tư từ GitHub. Vấn đề là, họ đã chỉ đích danh máy chủ MCP của GitHub. Và tôi nghĩ rằng chúng tôi thực sự cung cấp các công cụ có thể kích hoạt điều đó nếu bạn chỉ cần bật tất cả chúng lên.
Nhưng điều này áp dụng cho hầu hết mọi thiết lập agent. Dù chúng có sử dụng MCP hay không, hay chúng có sử dụng GitHub MCP hay không. Ví dụ như những vấn đề về lethal trifecta (bộ ba gây chết người) mà tôi sẽ không nhắc lại chi tiết ở đây, vì tôi nghĩ nhiều bạn có thể đã biết. Hoặc bạn có thể tìm kiếm thông tin về nó. Bài đăng blog của Simon Wilson về chủ đề này rất xuất sắc. Nhưng tính hữu dụng của các agent đang mâu thuẫn trực tiếp với việc bảo vệ những thông tin này. Đây là một lĩnh vực đang được tích cực nghiên cứu để tìm cách ngăn chặn những vấn đề này. Tuy nhiên, nó vẫn chưa được giải quyết và không hề là vấn đề riêng của GitHub.
Chúng tôi có những người dùng với các risk profile (hồ sơ rủi ro) rất khác nhau. Chúng tôi thậm chí có những người có các phiên bản máy chủ GitHub Enterprise được air-gapped (cách ly mạng) trong môi trường bảo mật cao hơn nhiều. Và sau đó, rõ ràng là các clubbers (người dùng thông thường), v.v., cũng trực tiếp chạy trên GitHub với quyền truy cập mã thông báo đầy đủ vào agent và mọi thứ. Điều đó cũng rất thú vị. Và tôi không có ý phán xét bất kỳ điều gì trong số này. Chỉ là thật tuyệt khi thấy mọi người làm gì và liệu chúng tôi có thể hỗ trợ các trường hợp sử dụng (use cases) và security posture khác nhau trong khi mọi người đang thử nghiệm những thứ này hay không.
Quản lý Công cụ bằng Quyền truy cập
Và chúng tôi cũng dựa vào auth (xác thực) để quản lý các công cụ. Đây là điều mà tôi khá hài lòng. Nếu bạn đăng nhập vào GitHub MCP bằng một mã thông báo cụ thể, chúng tôi sẽ ngay lập tức lọc các công cụ dựa trên các scope (phạm vi quyền hạn) mà mã thông báo đó có. Bạn không cần phải làm gì khác ngoài việc cung cấp mã thông báo.
Với OAuth, chúng tôi hỗ trợ step-up, tức là chúng tôi có thể trả về một scope challenge (thử thách phạm vi quyền hạn) và sau đó sẽ tương tác hỏi người dùng xem họ có muốn cho phép scope đó hay không. Nếu người dùng đồng ý, bạn có thể tiếp tục thực hiện cuộc gọi công cụ. Nó sẽ không thất bại, điều mà tôi nghĩ cũng rất tốt. Và VS Code, ví dụ, hỗ trợ điều đó. Ban đầu tôi đã làm việc với họ về tính năng này bởi vì họ đã có một mã thông báo để sử dụng GitHub. Điều họ muốn là nếu mã thông báo được tích hợp sẵn không có quyền sử dụng mọi thứ, thì thay vì chỉ thất bại, sẽ có một cơ chế cho người dùng thực hiện cài đặt sạch (clean install) và sau đó upscoping (nâng cấp phạm vi quyền hạn) nếu họ cần.
Và cuối cùng, mã thông báo máy chủ (server tokens) nữa. Chúng không có trên các action hay các thứ tương tự. Chúng không có các công cụ dành riêng cho người dùng. Và bằng cách loại bỏ những thứ đó, chúng tôi chỉ đơn giản là loại bỏ các nguồn gây lỗi liên tục và đồng thời giảm lãng phí ngữ cảnh.
Kiến trúc Máy chủ Phi trạng thái
Chúng tôi đã triển khai một thiết lập máy chủ hoàn toàn phi trạng thái (stateless server). Và chúng tôi đã sử dụng Redis để lưu trữ phiên (session storage). Đó là khả năng quan sát tiêu chuẩn (standard observability) trong stack của tôi. Đây không phải là một hình ảnh kỳ lạ. Nhưng tôi đoán một trong những điều kỳ lạ đối với một số người là rất nhiều người đang chạy một quy trình máy chủ MCP có trạng thái (stateful MCP server process) duy nhất và đã gặp khó khăn trong việc đưa nó về hình dạng này.
Nhưng đối với chúng tôi, chúng tôi đã làm một vài điều vì nó rất động. Nhưng một trong những điều thú vị mà chúng tôi đã làm là chúng tôi thực sự tạo ra một phiên bản máy chủ hoàn toàn mới (server instance), theo nghĩa SDK (Software Development Kit), trên mỗi yêu cầu duy nhất. Và chúng tôi thêm các công cụ vào đó ngay từ đầu. Vì vậy, bất kể cấu hình của bạn là gì, nó chỉ đơn giản là xây dựng nên điều này.
Mở rộng quy mô và Lượt gọi Công cụ
Và sau đó bạn nhận được những gì bạn đã yêu cầu hoặc những gì bạn được phép sử dụng, bởi vì một số thứ có chính sách ảnh hưởng đến việc bạn có công cụ hay không. Và vâng, chúng tôi đã có thể mở rộng quy mô đến thời điểm này. Chúng tôi tiết kiệm khoảng 7 triệu lượt gọi công cụ (tool calls) mỗi tuần. Và chúng tôi không có session affinity. Ngay cả các phiên (session), chúng tôi thường chỉ sử dụng chúng để xác định; đó là cách duy nhất để xác định client identity tự báo cáo đi qua MCPS. Vì vậy, điều này hữu ích cho chúng tôi để hiểu những client nào mọi người đang sử dụng với máy chủ (server). Vâng, chúng tôi sử dụng các phiên cho mục đích đó.
Các Tính năng Thử nghiệm và Ứng dụng MCP
Nhưng chúng tôi cũng muốn mang đến các thử nghiệm cho tất cả các bạn và mọi người. Và chúng tôi có một thứ đang ở chế độ Insiders mode. Tất cả những gì nó làm là bật một số feature flags và những thứ khác cho các thử nghiệm mà chúng tôi sẵn lòng cung cấp cho bất kỳ ai muốn sử dụng chúng. Và điều này chỉ đưa bạn đến tài liệu. Nhưng một ví dụ về điều mà chúng tôi chưa phát hành rộng rãi nhưng đang có trên Insiders là các ứng dụng MCP (MCP apps) của chúng tôi. Tôi đã thiết lập ví dụ trước khi đến đây. Thật tuyệt vời khi bạn nói chuyện với tác nhân (agent) mà có cơ hội chỉnh sửa issue do AI tạo ra, đặc biệt nếu bạn đang làm việc nhiều trong các dự án mã nguồn mở (open source) chuyên nghiệp. Và bạn muốn đảm bảo rằng đó là bài đăng của bạn, và nó sẽ không bị đóng như một thứ do bot tạo ra. Đây là một cơ chế human-in-the-loop (con người trong vòng lặp) tuyệt vời mà MCP cho phép. Ban đầu tôi không chắc mình sẽ thích nó đến mức nào, nhưng sau đó tôi đã yêu thích nó vì tôi quan tâm đến cách các issue và những thứ khác của mình được mọi người đón nhận. Và đây chỉ là một cách thực sự tuyệt vời để tôi có thể kiểm tra điều đó.
Tương lai của Sử dụng Công cụ và Tự động hóa
Vì vậy, vâng, về nơi tôi nghĩ nó sẽ đi đến, một điều gì đó tương tự, tôi nghĩ việc khám phá máy chủ (server discovery) trong tương lai gần hy vọng sẽ tự động. Và sử dụng công cụ (tool use) có lẽ sẽ trở nên có tính tổng hợp hơn, giống như bash hoặc piping tools và các công cụ khác truyền dữ liệu cho chúng, hoặc phương pháp code mode của CloudFavours, hoặc API Tìm kiếm Công cụ (Tool Search API) của Anthropic, vừa được ra mắt trong Claude Code vài tuần trước. Và OpenAI gần đây cũng đã thêm một API tương tự. Vì vậy, OpenAI cũng đã thêm một API tương tự. Và tôi hoàn toàn mong đợi rằng hàng nghìn công cụ sẽ trở nên bình thường rất sớm. Chúng tôi đang cố gắng giải quyết tất cả các vấn đề đã ngăn cản điều đó ngay từ đầu. Và tôi có thể sẽ đảo ngược nhiều quyết định về "ít công cụ hơn". Và người dùng hy vọng thậm chí sẽ không cần biết MCP là gì. Họ sẽ chỉ truyền đạt những gì họ muốn làm. Và thiết lập offset (offset setup) cũng như chọn công cụ (tool selection), mọi thứ sẽ trở nên thực sự tự động (autonomous). Và tôi không nghĩ chúng ta còn xa điều này, nhưng chúng ta đang ở trong một giai đoạn thử nghiệm (experimental phase) mà chúng ta chưa thực sự đạt được điều đó. Nhưng tôi nghĩ rằng các khung làm việc (harnesses) như Pye cũng rất thú vị bởi vì bạn có thể tự xây dựng một client kỳ lạ mà có thể tối ưu hóa điều này một cách thực sự tốt. Vì vậy, tôi khuyến khích mọi người thử nghiệm với các client kỳ lạ. Tôi cảm thấy bạn không bao giờ biết được, bạn có thể là người tiếp theo... Nếu bạn cực kỳ may mắn, bạn có thể là Claure tiếp theo. Bạn có thể xuất bản một thứ gì đó lan truyền (viral) đến mức thay đổi hoàn toàn trò chơi tác nhân (agentic game).
Thống kê và Sự tham gia của Cộng đồng
Tôi muốn kết thúc bằng một điểm nhấn ấn tượng và xem xét một số con số. Bản thân GitHub đã có hơn 11 triệu lượt tải xuống Docker của máy chủ IO (IO server) tiêu chuẩn của chúng tôi, mà đây cũng không phải là phiên bản được sử dụng nhiều nhất. Chúng tôi hiện có 126 người đóng góp (contributors) và hơn 2.300 issue và PR (pull request), với tần suất hơn bảy issue/PR mỗi ngày, liên tục trong hơn một năm nay, và tôi thực sự đã xem xét gần như mọi thứ cuối cùng. Vì vậy, đây là một năm khá bận rộn. Ý tôi là, các bài tóm tắt (summary posts) khác còn tệ hơn, nhưng tôi cũng yêu thích công việc này. Vì vậy, hãy tiếp tục làm điều đó nhé. Và vâng, chúng tôi có gần 4.000 fork, điều này làm tôi kinh ngạc. Tôi muốn biết những điều kỳ lạ hơn mà mọi người đã làm nhưng chưa đóng góp trở lại (contributed back). Vâng, gần 30.000 star. Và chúng tôi đang nhanh chóng đạt gần 8 triệu lượt gọi công cụ (tool calls) mỗi tuần. Và bản thân GitHub cũng đang đối mặt với một thách thức mới. Điều này thực sự căng thẳng, phải không? Và nó không có dấu hiệu chậm lại. Tôi vẫn muốn các bạn tiếp tục mở issue và PR cho chúng tôi. Chúng tôi sẽ xoay sở được, nhưng đây là một lãnh thổ mới. Và mọi thứ đều hơi hỗn loạn đối với mọi người, tôi nghĩ vậy, trong những ngày này. Và nó chỉ là thú vị và vui vẻ.
Lời kêu gọi thử nghiệm
Nhưng vâng, cảm ơn rất nhiều vì đã mời tôi. Tôi nghĩ tôi còn khoảng 30 giây. Tôi không biết có ai muốn hỏi gì không, nhưng tôi nghĩ những thứ như thử nghiệm MCP CLI và những thứ tương tự là một con đường thú vị. Tôi không nghĩ nó đã hoàn toàn được giải quyết, nhưng một điều bạn có thể làm: lấy các công cụ chỉ đọc (read-only tools) từ một MCP nào đó, gói nó trong một CLI, và chỉ cần cung cấp trợ giúp (help) thích hợp và xem tác nhân (agent) thực hiện như thế nào. Những thứ như vậy hiệu quả một cách đáng ngạc nhiên. Và như tôi đã nói, tôi muốn mọi người mày mò với những thứ này. Vì vậy, tôi khuyến khích bạn hãy thử nếu bạn quan tâm. Được rồi, tôi hết giờ rồi. Tôi sẽ trả lời bạn trực tiếp, nếu được.