Danh mục mô hình MCP cho các Coding Agent: Giúp việc lựa chọn mô hình trở nên máy đọc được

Danh mục mô hình MCP dành cho các coding agent là một danh sách có cấu trúc, có thể truy vấn về các mô hình khả dụng mà một agent có thể đọc thông qua Model Context Protocol thay vì dựa vào tên mô hình được mã hóa cứng (hardcoded) trong mã nguồn. Nó cho phép một agent, một plugin IDE hoặc một lớp điều phối chọn mô hình tại thời điểm chạy (runtime) dựa trên loại tác vụ, ngữ cảnh (context window) hoặc giới hạn chi phí, thay vì dựa vào một chuỗi ký tự mà lập trình viên đã nhập từ sáu tháng trước và quên cập nhật.

Điều này quan trọng hơn vẻ ngoài của nó. Các coding agent liên tục gọi các mô hình để tự động hoàn thiện mã (autocomplete), tái cấu trúc nhiều tệp (multi-file refactors), tạo kiểm thử (test generation) và soạn thảo thông điệp commit. Mỗi tác vụ này đều có một mô hình lý tưởng khác nhau. Nếu agent không thể khám phá những mô hình nào tồn tại và chúng phù hợp với việc gì, thì ai đó sẽ phải liên tục chỉnh sửa tệp cấu hình mỗi khi nhà cung cấp phát hành một phiên bản mới. Bài viết này sẽ hướng dẫn nội dung cần có trong một mục danh mục mô hình, cách định hình các yêu cầu kiểu MCP cho danh mục đó và cách quyết định mô hình nào sẽ được chuyển hướng cho các tác vụ lập trình nào.

Các điểm chính

• Danh mục mô hình giúp việc lựa chọn mô hình chuyển từ một chuỗi hardcoded sang tra cứu tại thời điểm chạy, giúp giảm bớt gánh nặng bảo trì khi các nhà cung cấp phát hành mô hình mới.
• Các coding agent được hưởng lợi từ việc định tuyến các loại tác vụ khác nhau (autocomplete, refactor, test generation, review) đến các mô hình khác nhau thay vì sử dụng một mô hình cho mọi thứ.
• Các yêu cầu MCP cho dữ liệu danh mục mô hình thường tuân theo hình thức resource-list hoặc tool-call; lược đồ chính xác cần được xác minh dựa trên tài liệu của chính nhà cung cấp trước khi bạn xây dựng dựa trên đó.
• TokenLab xuất bản Model Data Center tại /models/data và thư mục mô hình tại /models; hãy coi đây là nơi để xác minh tên mô hình hiện tại, không phải bài viết này, vì danh sách mô hình thay đổi thường xuyên.

Tại sao các Coding Agent cần dữ liệu mô hình mà máy có thể đọc được

Hầu hết các tích hợp coding agent vẫn hoạt động theo cách mà các tích hợp API đã làm cách đây một thập kỷ: một lập trình viên chọn tên mô hình, dán nó vào cấu hình hoặc biến môi trường và triển khai. Cách đó hoạt động cho đến khi nhà cung cấp ngừng hỗ trợ (deprecate) mô hình, thay đổi giá cả hoặc phát hành một tùy chọn tốt hơn mà nhóm không có quy trình để áp dụng.

Một danh mục mà máy có thể đọc được sẽ thay đổi kiểu lỗi này. Thay vì một agent bị hỏng âm thầm khi một mô hình bị loại bỏ, nó có thể truy vấn danh mục, thấy rằng mô hình đó đã biến mất hoặc được đánh dấu là không còn được hỗ trợ, và chuyển sang một giải pháp thay thế đã được ghi lại. Thay vì một lập trình viên phải tự tay đo điểm chuẩn (benchmark) cho mỗi bản phát hành mới, agent (hoặc công cụ của lập trình viên) có thể so sánh các ngữ cảnh, hỗ trợ phương thức (modality) và các trường chi phí được liệt kê trước khi chuyển đổi.

Đây cũng là điều kiện tiên quyết cho bất kỳ chiến lược định tuyến mô hình nghiêm túc nào. Nếu bạn muốn gửi các yêu cầu hoàn thiện mã giá rẻ, khối lượng lớn đến một mô hình chi phí thấp như DeepSeek V4 Flash hoặc Gemini 3.5 Flash, và dành riêng một mô hình mạnh hơn như Claude Sonnet 5 cho việc tái cấu trúc nhiều tệp, logic định tuyến cần một nguồn thông tin xác thực về mô hình nào đang hiện hành, chi phí bao nhiêu và hỗ trợ những gì. Nếu không có điều đó, các quy tắc định tuyến sẽ trở nên lỗi thời giống như cách các tên mô hình hardcoded bị lỗi thời.

TokenLab đã viết về vấn đề này trực tiếp trong bối cảnh biến thông tin mô hình thành thứ mà một agent có thể tin tưởng thay vì thứ mà con người phải xác minh lại bằng tay. Xem agent-readable model truth để biết lập luận rộng hơn về thông tin mô hình mà agent có thể đọc được, và agent-first API để biết thiết kế API thay đổi như thế nào khi người gọi chính là một agent thay vì một lập trình viên con người.

Những gì thuộc về một mục danh mục mô hình MCP

Một mục danh mục hữu ích cho một coding agent cần nhiều hơn là chỉ tên mô hình. Tối thiểu, các nhà phát triển xây dựng hoặc sử dụng nó nên mong đợi thấy:

• Định danh mô hình (Model identifier): chuỗi chính xác mà API mong đợi, vì các nhà cung cấp thường đặt phiên bản tên rất chính xác (sai lệch ở đây là một trong những lỗi tích hợp phổ biến nhất).
• Nhà cung cấp (Provider): công ty hoặc nền tảng nào phục vụ mô hình, điều này quan trọng khi một danh mục tổng hợp nhiều nhà cung cấp.
• Hỗ trợ phương thức (Modality support): văn bản, mã, hình ảnh hoặc video. Một danh mục trộn lẫn các mô hình lập trình như Kimi K2.7 Code với các mô hình hình ảnh như Nano Banana Pro cần một trường cho phép agent lọc theo những gì nó thực sự cần.
• Ngữ cảnh (Context window): giới hạn token rất quan trọng đối với các coding agent làm việc trên các kho lưu trữ lớn.
• Các trường chi phí (Cost fields): giá token đầu vào và đầu ra, lý tưởng nhất là tách biệt, vì các coding agent thường có khối lượng công việc đầu vào nặng (ngữ cảnh tệp lớn, đầu ra diff nhỏ).
• Trạng thái (Status): hiện tại, không còn được hỗ trợ (deprecated) hoặc đã lên lịch ngừng hoạt động. Đây là trường ngăn chặn sự cố hỏng hóc âm thầm.
• Thẻ phù hợp tác vụ (Task suitability tags): siêu dữ liệu tùy chọn nhưng hữu ích như "coding", "low-cost routing" hoặc "open-weight", để agent có thể lọc mà không cần biết đặc điểm của từng mô hình trước.

Không có trường nào trong số này được đảm bảo tồn tại trong định dạng danh mục của mọi nhà cung cấp. Trước khi xây dựng một tích hợp, hãy kiểm tra lược đồ thực tế được ghi lại tại nhà cung cấp mà bạn đang sử dụng. Đối với các mô hình do TokenLab phục vụ cụ thể, tập hợp trường và nhịp độ cập nhật hiện tại nên được xác minh tại /models/data thay vì giả định từ bài viết này, vì lược đồ danh mục thay đổi khi các mô hình và phương thức mới được thêm vào.

Ví dụ: Yêu cầu danh mục mô hình qua MCP

MCP thường giao tiếp qua JSON-RPC 2.0. Một client yêu cầu server liệt kê các tài nguyên mô hình khả dụng có thể gửi một yêu cầu có hình dạng như sau. Ví dụ này minh họa cho mô hình resource-list chung của MCP và không phải là tuyên bố về lược đồ trực tiếp của bất kỳ nhà cung cấp cụ thể nào; hãy xác nhận tên phương thức và trường phản hồi chính xác với https://docs.tokenlab.sh hoặc tài liệu của server MCP của bạn trước khi viết mã sản xuất dựa trên đó.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "resources/list",
  "params": {
    "filter": {
      "modality": "text",
      "tag": "coding"
    }
  }
}

Một hình dạng phản hồi hợp lý, một lần nữa mang tính minh họa thay vì là một lược đồ đã được xác minh:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resources": [
      {
        "id": "claude-sonnet-5",
        "provider": "Anthropic",
        "modality": ["text", "code"],
        "context_window": "verify at provider docs",
        "status": "current",
        "tags": ["coding", "review"]
      },
      {
        "id": "deepseek-v4-flash",
        "provider": "DeepSeek",
        "modality": ["text", "code"],
        "context_window": "verify at provider docs",
        "status": "current",
        "tags": ["low-cost", "coding"]
      }
    ]
  }
}

Đừng coi các giá trị ngữ cảnh, tên trường chính xác hoặc các mô hình cụ thể được liệt kê ở trên là sự thật đã được xác nhận về bất kỳ API trực tiếp nào. Chúng tồn tại ở đây để hiển thị hình dạng của một yêu cầu và phản hồi, không phải để nêu giá cả hoặc con số khả năng. Luôn lấy những con số đó từ tài liệu hiện tại của chính nhà cung cấp hoặc từ /models/data tại thời điểm bạn xây dựng.

Chọn mô hình theo tác vụ: Danh sách kiểm tra quyết định

Một danh mục mô hình chỉ hữu ích nếu agent (hoặc lập trình viên cấu hình agent) có quy tắc khớp loại tác vụ với mô hình. Bảng dưới đây là một khung làm việc ban đầu, không phải là kết quả điểm chuẩn. Xác minh các tuyên bố về giá cả và khả năng hiện tại dựa trên tài liệu của nhà cung cấp và /models trước khi cam kết thực hiện quy tắc định tuyến trong sản xuất.

Tác vụ của coding agent	Điều quan trọng nhất	Mô hình ví dụ để đánh giá
Autocomplete / gợi ý nội dòng	Độ trễ thấp, chi phí thấp mỗi lần gọi	DeepSeek V4 Flash, Gemini 3.5 Flash, Laguna XS 2.1
Tái cấu trúc nhiều tệp	Ngữ cảnh lớn hơn, khả năng suy luận mã mạnh	Claude Sonnet 5, DeepSeek V4 Pro
Tạo kiểm thử	Định dạng nhất quán, suy luận vừa phải	Kimi K2.7 Code, Claude Sonnet 5
Đánh giá mã / tóm tắt PR	Suy luận mạnh, khả năng tham chiếu diff chính xác	Claude Sonnet 5, Gemini 3.5 Flash
Tác vụ hàng loạt khối lượng lớn (linting, chú thích tài liệu)	Chi phí mỗi token quan trọng hơn khả năng thô	GLM-5.2, Qwen3.7 Plus, MiniMax M3
Yêu cầu open-weight (tự lưu trữ hoặc hạn chế giấy phép)	Open weights, có thể triển khai ngoài API được quản lý	GLM-5.2, DeepSeek V4 Pro, DeepSeek V4 Flash, Qwen3.7 Plus, Kimi K2.7 Code

Một danh sách kiểm tra thực tế để xây dựng chính logic định tuyến:

1. Mục danh mục có bao gồm trường trạng thái không, để bạn có thể phát hiện việc ngừng hỗ trợ trước khi một cuộc gọi thất bại?
2. Danh mục có tách biệt các mô hình có khả năng lập trình khỏi các mô hình văn bản hoặc hình ảnh chung không, để việc lọc không yêu cầu các danh sách hardcoded?
3. Bạn có thể đặt giới hạn chi phí cho mỗi loại tác vụ và để agent chọn mô hình rẻ nhất đáp ứng được nó, thay vì luôn mặc định chọn tùy chọn có khả năng cao nhất (và đắt nhất) không?
4. Có mô hình dự phòng (fallback) được xác định cho mọi danh mục tác vụ không, trong trường hợp lựa chọn chính không khả dụng hoặc bị giới hạn tốc độ?
5. Bạn có đang kiểm tra lại danh mục theo lịch trình không, không chỉ ở lần tích hợp đầu tiên, vì danh sách mô hình thay đổi theo thời gian?

TokenLab phù hợp như thế nào trong quy trình làm việc này

TokenLab duy trì một Model Data Center tại /models/data và một thư mục mô hình tại /models, cả hai đều được quan sát tính đến ngày 2026-07-14. Đây là những bề mặt để kiểm tra danh sách mô hình hiện tại, thay vì dựa vào bất kỳ bài viết tĩnh nào, vì các danh mục mô hình vốn dĩ nhạy cảm với thời gian. Tài liệu API của TokenLab tại https://docs.tokenlab.sh là nơi để xác minh lược đồ yêu cầu và phản hồi chính xác trước khi tích hợp.

Nếu bạn đang xây dựng một coding agent cần định tuyến giữa các mô hình như Claude Sonnet 5 cho các tác vụ đánh giá, DeepSeek V4 Flash cho các hoàn thiện mã khối lượng lớn giá rẻ, và Kimi K2.7 Code cho việc tạo kiểm thử, mô hình thực tế là coi định danh mô hình như một biến được giải quyết tại thời điểm yêu cầu dựa trên một danh mục, không phải là một hằng số được biên dịch vào mã nguồn của agent của bạn. Hãy bắt đầu bằng cách xem xét các danh sách hiện tại tại /models/data và xác nhận hình dạng yêu cầu mà MCP client của bạn cần dựa trên tài liệu API của TokenLab trước khi đưa logic định tuyến vào sản xuất.

Hạn chế

Bài viết này mô tả một mô hình chung cho các danh mục mô hình MCP và định tuyến coding agent. Nó không xác nhận rằng bất kỳ nhà cung cấp cụ thể nào, bao gồm cả TokenLab, đều hiển thị mọi trường được mô tả ở trên (ngữ cảnh, trường chi phí, trạng thái, thẻ tác vụ) theo đúng hình dạng này. Lược đồ, tên trường và các mô hình khả dụng thay đổi thường xuyên. Hãy coi các ví dụ JSON trong bài viết này là minh họa cho mô hình yêu cầu và phản hồi chung của MCP, không phải là lược đồ đã được xác minh cho bất kỳ endpoint trực tiếp nào. Trước khi triển khai, hãy xác nhận các định danh mô hình, giá cả và ngữ cảnh chính xác dựa trên tài liệu hiện tại của nhà cung cấp và dựa trên /models/data.

Câu hỏi thường gặp

Bản thân MCP có định nghĩa một lược đồ danh mục mô hình tiêu chuẩn không? MCP định nghĩa các mô hình chung cho tài nguyên và công cụ qua JSON-RPC, nhưng các trường chính xác trong một danh mục mô hình (giá cả, ngữ cảnh, trạng thái) phụ thuộc vào cách server triển khai MCP chọn hiển thị dữ liệu đó. Xác minh lược đồ cụ thể với server hoặc nhà cung cấp mà bạn đang tích hợp.

Một coding agent có nên luôn sử dụng mô hình có khả năng nhất hiện có không? Không nhất thiết. Các tác vụ như autocomplete nhạy cảm với độ trễ và chi phí, trong khi tái cấu trúc nhiều tệp được hưởng lợi từ khả năng suy luận mạnh hơn và ngữ cảnh lớn hơn. Một danh mục có thẻ tác vụ và trường chi phí cho phép bạn định tuyến theo tác vụ thay vì mặc định chọn một mô hình cho mọi thứ.

Tôi nên kiểm tra lại danh mục mô hình mà agent của tôi phụ thuộc vào bao lâu một lần? Danh sách mô hình thay đổi đủ thường xuyên để việc tích hợp một lần là không đủ. Hãy xây dựng logic định tuyến của bạn để truy vấn danh mục thay vì lưu trữ vĩnh viễn các định danh mô hình, và kiểm tra /models/data hoặc tài liệu của nhà cung cấp của bạn theo lịch trình thường xuyên.