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 Machine-Readable

Một coding agent (tác nhân lập trình) nếu mã hóa cứng (hardcode) tên mô hình thì sớm muộn gì cũng sẽ gây ra sự cố vào lúc 2 giờ sáng. Danh mục mô hình MCP dành cho các coding agent sẽ thay đổi phương thức lỗi đó. Thay vì một chuỗi ký tự bị chôn vùi trong mã nguồn, agent sẽ đọc một danh sách có cấu trúc bao gồm các mô hình hiện tại, chi phí, phương thức (modalities) và các trường trạng thái tại thời điểm yêu cầu. Chúng tôi duy trì một danh mục tương tự tại TokenLab và coi danh mục này là nguồn sự thật duy nhất cho việc định tuyến. Trong pipeline của chúng tôi, việc lựa chọn mô hình là một thao tác tra cứu, không phải là một hằng số.

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 giống như các tích hợp API từ một thập kỷ trước. Một nhà phát triể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 đó vẫn ổn cho đến khi nhà cung cấp ngừng hỗ trợ mô hình, thay đổi giá cả hoặc phát hành một tùy chọn tốt hơn. Khi đó, nhóm phát triển sẽ không có quy trình nào để áp dụng thay đổi.

Một danh mục mà máy có thể đọc được sẽ thay đổi phương thức lỗi này. Khi một mô hình bị loại bỏ, agent 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 hỗ trợ (deprecated), và chuyển sang một giải pháp thay thế đã được ghi nhận. Thay vì nhà phát triển phải tự tay benchmark từng bản phát hành mới, các công cụ có thể so sánh các cửa sổ ngữ cảnh (context windows), hỗ trợ phương thức và các trường chi phí trước khi chuyển đổi.

Đây cũng là điều kiện tiên quyết cho việc định tuyến mô hình nghiêm túc. Bạn có thể muốn các tác vụ hoàn thiện văn bản (completions) giá rẻ, khối lượng lớn trên DeepSeek V4 Flash hoặc Gemini 3.5 Flash. Bạn có thể dành riêng Claude Sonnet 5 cho các tác vụ tái cấu trúc nhiều tệp tin. Logic định tuyến vẫn cần một nguồn sự thật. Nguồn đó phải cho biết mô hình nào là hiện tại, chi phí bao nhiêu và hỗ trợ những gì. Nếu không có nó, các quy tắc định tuyến sẽ bị lỗi thời giống như cách các tên mô hình được hardcode.

TokenLab đã viết trực tiếp về vấn đề này. Xem agent-readable model truth để biết lập luận rộng hơn, và agent-first API để biết cách 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 nhà phát triển con người.

Các điểm chính cần lưu ý

• Danh mục mô hình biến việc lựa chọn mô hình từ một chuỗi hardcode thành một thao tác tra cứu trong thời gian chạy (runtime), 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 (tự động hoàn thiện, tái cấu trúc, tạo kiểm thử, đánh giá) đế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 định dạng resource-list hoặc tool-call; hãy xác minh schema chính xác dựa trên tài liệu của chính nhà cung cấp trước khi xây dựng dựa trên đó.
• TokenLab xuất bản Trung tâm Dữ liệu Mô hình (Model Data Center) tại /models/data và danh 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.

Những gì cần có trong một mục danh mục mô hình MCP

Một mục danh mục hữu ích cho coding agent cần nhiều hơn là chỉ tên mô hình. Tối thiểu, các nhà xây dựng và người tiêu dùng nên mong đợi thấy:

• Định danh mô hình (Model identifier): chuỗi chính xác mà API yêu cầu, vì các nhà cung cấp thường đánh phiên bản tên rất chính xác (sự không khớp ở đâ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 cung cấp mô hình, điều này quan trọng khi một danh mục tổng hợp từ nhiều nhà cung cấp.
• Hỗ trợ phương thức (Modality support): văn bản, mã nguồn, hình ảnh hoặc video. Một danh mục kết hợp 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.
• Cửa sổ ngữ cảnh (Context window): giới hạn token cực kỳ quan trọng đối với các coding agent làm việc trên các kho lưu trữ lớn.
• Trường chi phí (Cost fields): giá cho 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 lớn (ngữ cảnh tệp lớn, đầu ra diff nhỏ).
• Trạng thái (Status): hiện tại, không còn hỗ trợ (deprecated), hoặc đã lên lịch loại bỏ. Đây là trường ngăn chặn sự cố im lặng.
• 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 schema thực tế được ghi lại tại nhà cung cấp mà bạn sử dụng. Đối với các mô hình do TokenLab cung cấp cụ thể, hãy xác minh tập hợp trường hiện tại và nhịp độ cập nhật tại /models/data thay vì giả định rằng chúng khớp với bài viết này. Schema 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 tuân theo mô hình resource-list chung của MCP. Đây không phải là tuyên bố về schema 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à các trường phản hồi chính xác với https://docs.tokenlab.sh hoặc tài liệu của chính 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 schema đã đượ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ị cửa sổ 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 cho thấy hình dạng của một yêu cầu và phản hồi, không phải giá cả hoặc các con số về khả năng. Hãy lấy những con số đó từ tài liệu hiện tại của nhà cung cấp hoặc từ /models/data khi bạn xây dựng.

Lựa 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 nhà phát triể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 kết quả benchmark. Hãy 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ụ coding agent	Điều quan trọng nhất	Ví dụ mô hình cần đánh giá
Tự động hoàn thiện / 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	Cửa sổ 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, khả năng suy luận vừa phải	Kimi K2.7 Code, Claude Sonnet 5
Đánh giá mã / tóm tắt PR	Khả năng 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 ràng buộc giấy phép)	Open weights, có thể triển khai bên 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 vớ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 hardcode?
3. Bạn có thể đặt trầ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 nhất (và đắt nhất)?
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ì Trung tâm Dữ liệu Mô hình tại /models/data và danh mục mô hình tại /models, cả hai đều được quan sát tính đến ngày 2026-07-14. Hãy kiểm tra các bề mặt này để biết 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. 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 schema yêu cầu và phản hồi chính xác trước khi tích hợp.

Bạn có thể xây dựng một coding agent định tuyến giữa một vài mô hình. Sử dụng Claude Sonnet 5 cho các tác vụ đánh giá, DeepSeek V4 Flash cho các tác vụ hoàn thiện khối lượng lớn giá rẻ, và Kimi K2.7 Code cho việc tạo kiểm thử. Hãy coi định danh mô hình là một biến số. Giải quyết nó 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. Bước thực tế là kiểm tra /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 TokenLab. Chỉ đưa logic định tuyến vào sản xuất sau khi đã thực hiện các kiểm tra đó.

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 (cửa sổ ngữ cảnh, trường chi phí, trạng thái, thẻ tác vụ) chính xác theo hình dạng này. Schema, 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à schema đã đượ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à cửa sổ 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 schema 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ả, cửa sổ 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 đó. Hãy xác minh schema cụ thể với server hoặc nhà cung cấp mà bạn đang tích hợp.

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ư tự động hoàn thiện rất nhạy cảm với độ trễ và chi phí, trong khi việc tái cấu trúc nhiều tệp tin đượ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 với 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 sử dụng 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.

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 TokenLab trước khi đưa logic định tuyến vào sản xuất.