Cho AI agent gọi trực tiếp công cụ khoa học: bài học từ đội KnowledgeIsPower

Trong hai ngày hackathon, một AI agent đã hỏi về phức hợp protein 26S proteasome, gọi công cụ qua máy chủ MCP, và lấp được 607 trên 638 giá trị protein còn thiếu từ protein đối tác cùng phức hợp. Con số này không phải điểm chính xác. Nó là độ phủ: phần giá trị thiếu được xử lý bằng tri thức sinh học thay vì phương pháp dự phòng. Sự khác biệt đó đáng đọc kỹ, vì nó quyết định cách bạn đánh giá mọi demo agent khoa học sau này.

Vì sao protein đo được luôn thiếu

Proteomics tế bào đơn đo protein trong từng tế bào riêng lẻ. Nhưng thí nghiệm khối phổ thường không đo đủ. Tùy thí nghiệm, chỉ khoảng 20–60% protein của một tế bào được định lượng. Phần còn lại là giá trị thiếu, và nhà nghiên cứu phải ước lượng chúng. Việc ước lượng này gọi là imputation, tức điền giá trị thiếu bằng suy luận từ dữ liệu sẵn có.

Cách truyền thống là kNN, tức k láng giềng gần nhất. Phương pháp này nhìn protein tương tự trong cùng tập dữ liệu rồi suy ra giá trị thiếu. Đội KnowledgeIsPower đặt câu hỏi khác: quan hệ sinh học giữa các protein có giúp điền tốt hơn không? Protein cùng nằm trong một phức hợp thường tăng giảm cùng nhau. Nếu biết protein A thuộc phức hợp nào, ta có thêm căn cứ để đoán protein B.

MCP là cầu nối, không phải phép màu

MCP là viết tắt của Model Context Protocol, một chuẩn mở để ứng dụng AI kết nối với công cụ và nguồn dữ liệu ngoài. Máy chủ MCP công bố các công cụ. Client tương thích với MCP cho phép agent phát hiện và gọi các công cụ đó. Nhờ vậy, đội không phải viết một tích hợp riêng cho từng client AI.

Máy chủ scp-graphfs-mcp công bố sáu công cụ:

Công cụ	Việc làm
get_complexes	Lấy thông tin phức hợp protein
explain_protein	Tra cứu thông tin sinh học của một protein
build_prior	Xây tri thức nền từ quan hệ sinh học
propagate_scores	Lan truyền thông tin qua quan hệ trên đồ thị
impute_with_prior	Điền giá trị thiếu bằng tri thức nền sinh học
select_panel	Hỗ trợ chọn panel protein cần đo

Một câu hỏi nghiên cứu bằng ngôn ngữ tự nhiên đi qua sáu công cụ này và trở thành các thao tác khoa học có cấu trúc. Đó là toàn bộ ý tưởng. Agent không tự bịa số liệu. Agent gọi công cụ, công cụ trả kết quả, và mọi bước đều lưu lại được.

Thí nghiệm thật: phức hợp 26S proteasome

Tác giả Abdullah Javed phụ trách phần tích hợp client MCP, kiểm thử và tài liệu. Anh đăng ký máy chủ cho hai client khác nhau. Với Claude Code, lệnh đăng ký qua giao thức STDIO, tức giao tiếp qua luồng vào ra chuẩn, trông như sau:

claude mcp add --transport stdio --scope local scp-graphfs -- ".\.venv\Scripts\scp-graphfs-mcp.exe"

Đường dẫn tuyệt đối thường đáng tin hơn đường dẫn tương đối. Sau khi đăng ký, anh kiểm tra bằng lệnh liệt kê và lệnh xem cấu hình. Kết nối được xác nhận, nhưng anh không chạy được phiên Claude Code hoàn chỉnh vì không có quyền truy cập Claude. Bài viết nói rõ giới hạn này. Đây là điểm đáng tin: tác giả không phóng đại phần mình chưa làm được.

Phiên làm việc thật chạy bằng GitHub Copilot CLI. Câu hỏi nghiên cứu: trong tập dữ liệu Petrosius 2023, những tiểu đơn vị nào của phức hợp 26S proteasome được đo, và bao nhiêu giá trị thiếu của chúng lấp được từ protein đối tác? Agent gọi get_complexes với protein PSMB5 và nguồn Complex Portal. Kết quả: phức hợp có 33 tiểu đơn vị, 31 tiểu đơn vị được đo, hai tiểu đơn vị PSMB3 và SEM1 không được đo.

Agent chuẩn bị tập con chỉ chứa protein 26S đã đo. Sau đó agent gọi impute_with_prior với tri thức nền từ Complex Portal. Kết quả:

Chỉ số	Giá trị
Tổng giá trị thiếu	638
Lấp từ protein đối tác	607
Lấp bằng kNN dự phòng	31
Độ phủ từ đối tác	95,1%

Con số 95,1% chỉ nói 607 trên 638 giá trị thiếu được xử lý bằng quan hệ đối tác. Nó không phải điểm chính xác, và không chứng minh phương pháp này vượt kNN. Tác giả nhấn mạnh đúng điểm này trong bài gốc. Người đọc nên giữ ranh giới đó khi trích dẫn con số.

Toàn bộ phiên làm việc thật, gồm cả lần thử thất bại, được lưu thành transcript, tức bản ghi đầy đủ của phiên làm việc, và nộp qua PR số 8, tức yêu cầu hợp nhất mã. PR này đã được merge. Việc giữ transcript là thực hành tốt nhất cho agent khoa học: người khác đọc lại được agent đã gọi công cụ nào, với tham số nào, và nhận kết quả nào.

Kết quả rộng hơn: tri thức tuyển chọn chưa đủ, tri thức tham chiếu mới giúp

Bên cạnh phần tích hợp, đội chạy benchmark so sánh 22 biểu diễn tri thức protein. Kết luận thứ nhất khá dè dặt. Các nguồn tri thức tuyển chọn như Complex Portal, PDB co-structure và CORUM đứng đầu trong nhóm tri thức nền. Nhưng không nguồn nào, đứng một mình, vượt được mốc đối chứng kNN thuần túy theo cổng phát triển của dự án.

Kết luận thứ hai mạnh hơn. Phương pháp tham chiếu học quan hệ protein từ dữ liệu sinh học ngoài, thay vì chỉ dùng phức hợp tuyển chọn. Nó cải thiện kết quả trên tập holdout Brunner 2022, tức tập dữ liệu giữ riêng và chưa từng dùng khi phát triển phương pháp. So với kNN, phương pháp này giảm sai số trong phức hợp 6,0% ở chế độ MCAR và 8,9% ở chế độ MNAR. RMSE là căn trung bình bình phương sai số. MCAR nghĩa là giá trị thiếu hoàn toàn ngẫu nhiên, còn MNAR nghĩa là giá trị thiếu có hệ thống, không ngẫu nhiên. So với kNN cộng low-rank, tức kNN cộng xấp xỉ hạng thấp, mức cải thiện là 2,4% và 5,4%. Cả sáu khoảng tin cậy bootstrap, tức tái lấy mẫu, 95% đều nằm dưới 0.

Nhưng đội cũng ghi rõ một lần holdout trước đó cho kết quả yếu hơn trước baseline dữ liệu mạnh nhất. Vì vậy khả năng lặp lại vẫn là giới hạn cần ghi nhận. Một kết quả holdout tốt chưa đủ để kết luận phương pháp luôn thắng. Nó đủ để nói hướng tham chiếu đáng theo đuổi tiếp.

Bốn thực hành rút ra cho người xây máy chủ MCP khoa học

Thứ nhất, thiết kế công cụ theo thao tác khoa học, không theo từng cổng API riêng lẻ. Mỗi công cụ trong sáu công cụ trên tương ứng một bước lập luận của nhà nghiên cứu. Agent gọi đúng bước, chứ không gọi API thô rồi tự diễn giải.

Thứ hai, đăng ký client bằng STDIO và kiểm tra ngay bằng lệnh liệt kê. Lỗi cấu hình phát hiện sớm rẻ hơn lỗi phiên làm việc muộn rất nhiều. Đường dẫn tuyệt đối và biến môi trường rõ ràng giúp người khác tái tạo được.

Thứ ba, giữ transcript đầy đủ, kể cả lần thử thất bại. Transcript là bằng chứng duy nhất cho thấy agent làm gì, thay vì tuyên bố agent làm được gì. Đội KnowledgeIsPower nộp transcript cùng PR, và PR đó đã merge sau khi soát xét.

Thứ tư, tách độ phủ khỏi độ chính xác trong mọi báo cáo. Độ phủ trả lời câu hỏi bao nhiêu giá trị thiếu được xử lý. Độ chính xác trả lời câu hỏi giá trị điền gần sự thật đến đâu. Trộn hai khái niệm này là cách nhanh nhất để một demo trông ấn tượng hơn thực tế.

Bài học cho người làm agent nói chung cũng nằm ở đây. Agent mạnh lên không chỉ nhờ mô hình lớn hơn. Agent mạnh lên khi công cụ nó gọi là công cụ thật, có kiểm thử ngoại tuyến, có transcript, và có người dám ghi rõ phần chưa làm được. Cùng một tinh thần kiểm chứng xuất hiện ở lĩnh vực khác. Bài về agent-device cho thấy AI agent tự bấm và kiểm tra app Flutter: Để AI agent tự bấm và kiểm tra app Flutter trên iOS lẫn Android.

Kiểm chứng trước khi áp dụng

Bộ kiểm thử ngoại tuyến của dự án báo 19 kiểm thử đạt và 27 kiểm thử xfailed tại thời điểm tác giả chạy. Đây là ảnh chụp môi trường phát triển của tác giả, không phải tổng số kiểm thử cuối cùng của dự án. Đừng trích dẫn hai con số này như thước đo chất lượng toàn dự án.

Trước khi dùng lại mẫu này, hãy kiểm tra ba điểm. Một, repo công khai và giấy phép Apache 2.0 có phù hợp với dự án của bạn không. Hai, dữ liệu của bạn có quan hệ đối tác tương tự phức hợp protein không, vì phương pháp này chỉ phát huy khi quan hệ đó có thật. Ba, bạn có giữ transcript cho phiên agent của mình không, vì không có transcript thì không ai kiểm chứng được kết quả.