Apideck CLI – Giao diện tác nhân AI với mức tiêu thụ ngữ cảnh thấp hơn nhiều so với MCP
Backend·Hacker News·2 lượt xem

Apideck CLI – Giao diện tác nhân AI với mức tiêu thụ ngữ cảnh thấp hơn nhiều so với MCP

Apideck CLI – An AI-agent interface with much lower context consumption than MCP

AI Summary

Các framework AI agent hiện tại như MCP gặp phải một vấn đề cốt lõi là tiêu thụ quá nhiều context cho các định nghĩa tool (schemas, descriptions, v.v.). Điều này làm hạn chế nghiêm trọng khả năng xử lý hội thoại và suy luận của agent, khiến việc xây dựng các agent phức tạp tương tác với nhiều service trở nên khó khăn. "Context tax" này là một gánh nặng đáng kể. Apideck CLI đưa ra một giải pháp thực tế bằng cách sử dụng giao diện dòng lệnh (CLI) làm mô hình tương tác cho agent. Cách tiếp cận này mô phỏng cách các lập trình viên thực thụ khám phá và sử dụng tool theo từng bước. Các developer nên cân nhắc kỹ về overhead context trong chiến lược tooling của agent. CLI cung cấp một phương án tiết kiệm token và có khả năng mở rộng tốt cho việc tích hợp API phức tạp. Nó tránh được nhược điểm của việc tải toàn bộ định nghĩa tool ngay từ đầu như MCP, cũng như các rủi ro bảo mật liên quan đến việc thực thi code.

TL;DR: Định nghĩa công cụ MCP có thể ghi hơn 55.000 mã thông báo trước khi tác nhân xử lý một tin nhắn của người dùng. Thay vào đó, chúng tôi đã xây dựng Apideck CLI dưới dạng giao diện tác nhân AI: lời nhắc tác nhân ~80 mã thông báo thay thế hàng chục nghìn mã thông báo lược đồ, với khả năng tiết lộ lũy tiến thông qua `--help` và tính năng an toàn về cấu trúc được đưa vào hệ nhị phân. Bất kỳ tác nhân nào có thể chạy lệnh shell đều có thể sử dụng nó. Không cần hỗ trợ giao thức.

Vấn đề không ai nói đến ở quy mô demo

Đây là một tình huống quen thuộc nếu bạn kết nối máy chủ MCP cho bất kỳ mục đích nào ngoài bản demo.

Bạn kết nối GitHub, Slack và Sentry. Ba dịch vụ, có thể có tổng cộng 40 công cụ. Trước khi nhân viên hỗ trợ của bạn đọc một tin nhắn của người dùng, 55.000 mã thông báo định nghĩa công cụ sẽ nằm trong cửa sổ ngữ cảnh. Đó là hơn một phần tư giới hạn 200k của Claude. Đi rồi.

Nó trở nên tồi tệ hơn. Mỗi công cụ MCP có giá 550–1.400 mã thông báo cho tên, mô tả, lược đồ JSON, mô tả trường, enum và hướng dẫn hệ thống. Kết nối một bề mặt API thực, chẳng hạn như nền tảng SaaS với hơn 50 điểm cuối và bạn đang xem hơn 50.000 mã thông báo chỉ để mô tả những gì tác nhân có thể làm, hầu như không còn gì cho những gì nó nên làm.

Một nhóm đã báo cáo ba máy chủ MCP tiêu thụ 143.000 trong số 200.000 mã thông báo. Đó là 72% cửa sổ ngữ cảnh được ghi trên các định nghĩa công cụ. Người đại diện còn lại 57.000 mã thông báo cho cuộc trò chuyện thực tế, truy xuất tài liệu, lý luận và phản hồi. Chúc may mắn xây dựng được mọi thứ hữu ích trong không gian đó.

Đây không phải là mối lo ngại về mặt lý thuyết. David Zhang (@dzhng), xây dựng Duet, đã mô tả việc loại bỏ hoàn toàn tích hợp MCP của họ, ngay cả sau khi OAuth và đăng ký ứng dụng khách động hoạt động. Sự đánh đổi là không thể:

  • Tải mọi thứ lên phía trước → mất trí nhớ làm việc cho lý luận và lịch sử
  • Hạn chế tích hợp → nhân viên chỉ có thể nói chuyện với một số dịch vụ
  • Xây dựng tải công cụ động → thêm độ trễ và độ phức tạp của phần mềm trung gian

Ông ấy gọi đó là "bộ ba bất khả thi". Điều đó có vẻ đúng.

Và những con số này vẫn được duy trì trong quá trình thử nghiệm có kiểm soát. Một điểm chuẩn gần đây của Scalkit đã thực hiện 75 so sánh trực tiếp (cùng một mô hình, Claude Sonnet 4, cùng nhiệm vụ, cùng lời nhắc) và nhận thấy MCP có giá cao hơn 4 đến 32 lần mã thông báo so với CLI cho các hoạt động giống hệt nhau. Nhiệm vụ đơn giản nhất của họ, kiểm tra ngôn ngữ của repo, đã tiêu thụ 1.365 mã thông báo qua CLI và 44.026 qua MCP. Chi phí gần như hoàn toàn là lược đồ: 43 định nghĩa công cụ được đưa vào mỗi cuộc hội thoại, trong đó tổng đài viên sử dụng một hoặc hai.

Ba cách tiếp cận cùng một vấn đề

Ngành công nghiệp đang tập trung vào ba giải pháp ứng phó với sự phình to của bối cảnh. Mỗi người đều có một điểm thú vị.

MCP với thủ thuật nén

Phản ứng đầu tiên là giữ MCP nhưng chống lại sự phình to. Các nhóm nén lược đồ, sử dụng công cụ tìm kiếm để tải định nghĩa theo yêu cầu hoặc xây dựng phần mềm trung gian giúp chia các thông số OpenAPI thành các phần nhỏ hơn.

Tính năng này phù hợp với các tương tác nhỏ, được xác định rõ ràng như tra cứu sự cố, tạo yêu cầu hoặc tìm nạp tài liệu. Các lệnh gọi công cụ có cấu trúc và lược đồ đã nhập của MCP thực sự hữu ích khi bạn có một tập hợp chặt chẽ các hoạt động mà các tổng đài viên thường xuyên sử dụng.

Nhưng nó bổ sung thêm cơ sở hạ tầng. Bạn cần đăng ký công cụ, logic tìm kiếm, bộ nhớ đệm và định tuyến. Bạn đang xây dựng một dịch vụ để quản lý các dịch vụ của mình. Và bạn vẫn phải trả chi phí mã thông báo cho mỗi công cụ mỗi khi nhân viên quyết định rằng họ cần một khả năng mới.

Thực thi mã (phương pháp Duet)

Câu trả lời của Duet là đối xử với nhân viên như một nhà phát triển có không gian làm việc ổn định. Khi tác nhân cần một tiện ích tích hợp mới, nó sẽ đọc tài liệu API, viết mã dựa vào SDK, chạy mã đó và lưu tập lệnh để sử dụng lại.

Điều này rất hiệu quả đối với các tác nhân không gian làm việc tồn tại lâu dài, duy trì trạng thái qua các phiên và cần các quy trình làm việc phức tạp (vòng lặp, điều kiện, bỏ phiếu, thao tác hàng loạt). Những điều khó diễn đạt khi các lệnh gọi công cụ riêng lẻ trở nên tự nhiên trong mã.

Nhược điểm: tác nhân của bạn hiện đang viết và thực thi mã tùy ý đối với các API sản xuất. Bề mặt an toàn là rất lớn. Bạn cần có hộp cát, cơ chế xem xét và rất nhiều sự tin tưởng vào phán đoán của đại lý.

CLI là giao diện tác nhân

Phương pháp thứ ba là phương pháp chúng tôi đã thực hiện. Thay vì tải lược đồ vào cửa sổ ngữ cảnh hoặc để tác nhân viết mã tích hợp, bạn cung cấp cho nó một CLI.

Một CLI được thiết kế tốt về bản chất là một hệ thống tiết lộ tiến bộ. Khi nhà phát triển con người cần sử dụng một công cụ mà họ chưa từng chạm tới trước đây, họ sẽ không đọc toàn bộ tài liệu tham khảo API. Họ chạy tool --help, tìm lệnh phụ họ cần, chạy tool subcommand --help và nhận các cờ cụ thể cho thao tác đó. Họ chú ý đến chi phí tỷ lệ thuận với những gì họ thực sự cần.

Đại lý có thể thực hiện chính xác điều tương tự. Và nền kinh tế mã thông báo có sự khác biệt đáng kể.

Tại sao CLI lại là điểm thú vị mang tính thực tế

Tiết lộ lũy tiến giúp tiết kiệm mã thông báo

Đây là lời nhắc của nhân viên hỗ trợ Apideck CLI. Đây là toàn bộ điều mà một tác nhân AI cần có trong lời nhắc hệ thống của nó:

Sử dụng `apideck` để tương tác với API hợp nhất Apideck.
Các API có sẵn: `apideck --list`
Liệt kê tài nguyên: `apideck  --list`
Trợ giúp thao tác: `apideck    --help`
API: kế toán, ats, crm, thương mại điện tử, hris, ...
Auth được cấu hình sẵn. NHẬN được tự động phê duyệt. Lời nhắc POST/PUT/PATCH (sử dụng --yes). XÓA bị chặn (sử dụng --force).
Sử dụng --service-id  để nhắm mục tiêu tích hợp cụ thể.
Để có đầu ra sạch: -q -o json

Đó là ~80 mã thông báo. So sánh điều đó với các lựa chọn thay thế:

Phương pháp tiếp cậnMã thông báo được sử dụngKhi
Thông số OpenAPI đầy đủ trong ngữ cảnh30.000–100.000+Trước thông báo đầu tiên
Công cụ MCP (~3.600 mỗi API)10.000–50.000+Trước tin nhắn đầu tiên
Lời nhắc của nhân viên CLI~80Trước tin nhắn đầu tiên
CLI --help gọi ~50–200Chỉ khi cần thiết

Nhân viên bắt đầu với 80 mã thông báo hướng dẫn và khám phá các khả năng theo yêu cầu:

# Cấp độ 1: Có những API nào? (đầu ra ~ 20 mã thông báo) $ apideck --list kế toán ats kết nối crm thương mại điện tử hris ... # Cấp độ 2: Tôi có thể làm gì với kế toán? (~200 đầu ra token) $ apideck kế toán --list Tài nguyên trong API kế toán: hoá đơn danh sách NHẬN/kế toán/hóa đơn nhận GET /accounting/invoices/{id} tạo POST/kế toán/hóa đơn xóa DELETE /accounting/invoices/{id} khách hàng danh sách GET /kế toán/khách hàng ... # Cấp độ 3: Làm cách nào để tạo hóa đơn? (đầu ra ~ 150 mã thông báo) $ apideck tạo hóa đơn kế toán --help Cách sử dụng: apideck tạo hóa đơn kế toán [cờ] Cờ: --data chuỗi nội dung yêu cầu JSON (hoặc @file.json) --service-id string Nhắm mục tiêu một trình kết nối cụ thể --yes Bỏ qua xác nhận ghi -o, --output string Định dạng đầu ra (json|table|yaml|csv) ...

Mỗi bước tốn 50–200 mã thông báo, chỉ được tải khi tác nhân quyết định cần thông tin đó. Một tác nhân xử lý một truy vấn kế toán có thể sử dụng tổng cộng 400 mã thông báo qua ba lệnh gọi --help. Bề mặt tương tự thông qua MCP sẽ tiêu tốn hơn 10.000 mã thông báo được tải trước cho dù đại lý có sử dụng chúng hay không.

Điều này phản ánh cách Kỹ năng đặc vụ Claude hoạt động. Đầu tiên là siêu dữ liệu, chi tiết đầy đủ chỉ khi được chọn, chỉ tài liệu tham khảo khi cần. CLI đang thực hiện điều tương tự thông qua một cơ chế khác.

Điểm chuẩn của Scalkit đã xác thực mẫu này một cách độc lập. Họ nhận thấy rằng ngay cả một "tệp kỹ năng" tối thiểu ~ 800 mã thông báo (tài liệu về các mẹo CLI và quy trình công việc phổ biến) đã giảm các lệnh gọi công cụ xuống 1/3 và độ trễ xuống 1/3 so với CLI thông thường. Cách tiếp cận của chúng tôi còn tiến xa hơn nữa: lời nhắc đại lý ~ 80 mã thông báo cung cấp khả năng khám phá lũy tiến tương tự với chi phí bằng 1/10. Nguyên tắc là như nhau. Một gợi ý nhỏ, trực tiếp về cách điều hướng công cụ có giá trị hơn hàng nghìn mã thông báo của lược đồ đầy đủ.

Độ tin cậy: nhịp đập cục bộ từ xa

Có một khía cạnh của vấn đề MCP chưa được quan tâm đầy đủ: tính sẵn có.

Điểm chuẩn của Scalkit ghi lại tỷ lệ lỗi 28% đối với các lệnh gọi MCP tới máy chủ Copilot của GitHub. Trong số 25 lần chạy, 7 lần không thành công do hết thời gian kết nối ở cấp độ TCP. Máy chủ từ xa không phản hồi kịp thời. Không phải lỗi giao thức, không phải cuộc gọi công cụ tồi. Kết nối không bao giờ hoàn tất.

Tác nhân CLI không có chế độ lỗi này. Hệ nhị phân chạy cục bộ. Không có máy chủ từ xa nào hết thời gian chờ, không có nhóm kết nối nào bị cạn kiệt, không có trung gian ngừng hoạt động. Khi đại lý của bạn chạy danh sách hóa đơn kế toán apideck, nó sẽ thực hiện lệnh gọi HTTPS trực tiếp tới API Apideck. Một bước nhảy chứ không phải hai.

Điều này quan trọng ở quy mô lớn. Với 10.000 hoạt động mỗi tháng, tỷ lệ thất bại 28% có nghĩa là khoảng 2.800 lần thử lại, mỗi lần đốt thêm mã thông báo và độ trễ. Scalkit ước tính chênh lệch chi phí hàng tháng ở mức 3,20 USD cho CLI so với 55,20 USD cho MCP trực tiếp, hệ số nhân chi phí là 17×, với thuế độ tin cậy ở trên cùng.

Các máy chủ MCP từ xa sẽ được cải thiện. Nhóm kết nối, cơ sở hạ tầng tốt hơn và các lớp cổng sẽ thu hẹp khoảng cách. Nhưng "tệp nhị phân nằm trên máy của bạn" là sự đảm bảo về độ tin cậy mà không có kỹ thuật cơ sở hạ tầng nào ở phía máy chủ có thể sánh được.

An toàn về kết cấu vượt trội hơn so với an toàn dựa trên lời nhắc

Việc yêu cầu nhân viên "không bao giờ xóa dữ liệu sản xuất" trong lời nhắc của hệ thống cũng giống như dán một tờ giấy dán lên nút phóng hạt nhân. Nó có thể hoạt động. Có lẽ. Cho đến khi nội dung nhắc nhở sáng tạo bóc ghi chú ra.

Nghiên cứu bảo mật về tác nhân AI trong CI/CD đã cho thấy cách tiêm kịp thời có thể thao túng các tác nhân có mã thông báo đặc quyền cao để rò rỉ bí mật hoặc sửa đổi cơ sở hạ tầng. Quy luật luôn giống nhau: đầu vào không đáng tin cậy được đưa vào lời nhắc, tác nhân có quyền truy cập rộng rãi vào công cụ và điều tồi tệ sẽ xảy ra.

Apideck CLI áp dụng cách tiếp cận mang tính cấu trúc. Phân loại quyền được đưa vào hệ nhị phân dựa trên phương thức HTTP:

// Từ nội bộ/permission/engine.go
chuyển op.Permission {
thông số trường hợp.PermissionRead:
    trả về ActionAllow // GET → tự động phê duyệt
thông số trường hợp.PermissionWrite:
    trả về ActionPrompt // POST/PUT/PATCH → yêu cầu xác nhận
trường hợp cụ thể.QuyềnNguy hiểm:
    trả về ActionBlock // XÓA → bị chặn theo mặc định
}

Không có lời nhắc nào có thể ghi đè lên điều này. Thao tác DELETE bị chặn trừ khi người gọi chuyển --force một cách rõ ràng. POST yêu cầu --yes hoặc xác nhận tương tác. Các thao tác GET chạy tự do vì chúng không thể sửa đổi trạng thái.

Các khung tác nhân củng cố điều này. Claude Code, Cursor và GitHub Copilot đều có hệ thống cấp phép kiểm soát việc thực thi lệnh shell. Vì vậy, bạn nhận được hai lớp bảo mật về cấu trúc: khung tác nhân hỏi "tôi có nên chạy lệnh này không?" và chính CLI thực thi "thao tác này có được phép không?"

Bạn cũng có thể tùy chỉnh chính sách cho mỗi thao tác:

# ~/.apideck-cli/permissions.yaml mặc định: đọc: cho phép viết: nhắc nhở nguy hiểm: chặn ghi đè: Accounting. Payments.create: khối # thanh toán rất nhạy cảm crm.contacts.delete: dấu nhắc # liên hệ có thể bị xóa mềm

Đây chính là nguyên tắc đằng sau Duda chặn các hành động phá hoại MCP , nhưng được thực thi một cách có cấu trúc ở dạng nhị phân, không phải thông qua các hướng dẫn nhắc nhở cạnh tranh với mọi thứ khác trong cửa sổ ngữ cảnh.

Khả năng tương thích phổ quát, không cần chi phí giao thức

Mọi khung tác nhân nghiêm túc đều có "lệnh chạy shell" dưới dạng nguyên thủy. Mã Claude có Bash. Con trỏ có quyền truy cập đầu cuối. GitHub Copilot SDK hiển thị việc thực thi shell. Gemini CLI chạy các lệnh nguyên bản.

MCP yêu cầu hỗ trợ khách hàng chuyên dụng, kết nối và quản lý vòng đời máy chủ. CLI yêu cầu tệp nhị phân trên PATH.

Điều này quan trọng hơn những gì bạn tưởng. Khi bạn đang xây dựng một tác nhân cần tương tác với API, đường dẫn tích hợp cho CLI là:

  1. Cài đặt nhị phân
  2. Đặt biến môi trường cho auth
  3. Thêm ~80 mã thông báo vào lời nhắc hệ thống
  4. Xong

Con đường tích hợp cho MCP là:

  1. Triển khai hoặc định cấu hình ứng dụng khách MCP
  2. Thiết lập kết nối máy chủ (truyền tải, xác thực, vòng đời)
  3. Xử lý đăng ký công cụ và tải lược đồ
  4. Quản lý trạng thái kết nối và kết nối lại
  5. Giải quyết ngân sách mã thông báo cho các định nghĩa công cụ

Phương pháp CLI cũng có nghĩa là việc tích hợp tác nhân của bạn không bị giới hạn trong bất kỳ khuôn khổ cụ thể nào. Hệ nhị phân apideck tương tự hoạt động từ Claude Code, Cursor, tác nhân Python tùy chỉnh, tập lệnh bash hoặc đường dẫn CI/CD.

Cách chúng tôi xây dựng nó

Apideck CLI là một tệp nhị phân tĩnh duy nhất phân tích thông số OpenAPI của chúng tôi khi khởi động và tạo động toàn bộ cây lệnh của nó.

OpenAPI gốc, không tạo mã. Tệp nhị phân nhúng thông số API hợp nhất Apideck mới nhất. Khi khởi động, nó phân tích thông số kỹ thuật bằng libopenapi và xây dựng các lệnh cho mọi nhóm API, tài nguyên và hoạt động. Khi API thêm điểm cuối mới, apideck sync sẽ lấy thông số kỹ thuật mới nhất. Không có sự tái tạo SDK, không có sự thay đổi về phiên bản.

Mặc định đầu ra thông minh. Khi chạy trong thiết bị đầu cuối, đầu ra mặc định là một bảng được định dạng có màu sắc. Khi được dẫn hoặc gọi từ một máy không phải TTY (đó là cách các đại lý gọi nó), đầu ra sẽ mặc định là JSON. Tác nhân nhận được đầu ra có thể phân tích cú pháp bằng máy mà không cần phải nhớ --output json.

# Tác nhân gọi cái này (không phải TTY) → tự động nhận JSON
$ apideck danh sách hóa đơn kế toán -q
[{"id": "inv_12345", "số": "INV-001", "tổng": 1500,00, ...}]
# Con người chạy lệnh tương tự trong terminal → lấy một bảng
$ apideck danh sách hóa đơn kế toán
┌──────────┬─────────┬──────────┐
│ ID │ Số │ Tổng │
├──────────┼─────────┼──────────┤
│ inv_12345│ INV-001 │ 1.500,00 │
└──────────┴─────────┴──────────┘

Xác thực là vô hình. Thông tin xác thực được phân giải từ các biến môi trường (APIDECK_API_KEY, APIDECK_APP_ID, APIDACK_CONSUMER_ID) hoặc tệp cấu hình và tự động được đưa vào mọi yêu cầu. Tác nhân không bao giờ xử lý mã thông báo, không bao giờ nhìn thấy tiêu đề xác thực, không bao giờ cần quản lý phiên.

Nhắm mục tiêu theo trình kết nối. Cờ --service-id cho phép tổng đài viên nhắm mục tiêu các tích hợp cụ thể. danh sách hóa đơn kế toán apideck --service-id quickbooks truy cập QuickBooks. Hoán đổi sang --service-id xero và lệnh tương tự sẽ chạm vào Xero. Giao diện giống nhau, phần phụ trợ khác nhau. Đó là API hợp nhất đang thực hiện công việc của nó.

Khi CLI không phải là câu trả lời

CLI không phải lúc nào cũng tốt hơn. Đây là nơi các phương pháp tiếp cận khác vẫn giành chiến thắng.

MCP phù hợp hơn với các công cụ tần suất cao, có phạm vi chặt chẽ. Nếu nhân viên hỗ trợ của bạn gọi cùng một công cụ 5–10 hàng trăm lần mỗi phiên thì chi phí lược đồ trả trước sẽ được khấu hao tốt. Nhân viên hỗ trợ khách hàng chỉ tra cứu yêu cầu, cập nhật trạng thái và gửi phản hồi không cần tiết lộ dần dần. Nó cần những công cụ đó sẵn sàng ngay lập tức.

Việc thực thi mã sẽ tốt hơn đối với các quy trình công việc phức tạp và có trạng thái. Nếu tác nhân của bạn cần thăm dò API cứ sau 30 giây, tổng hợp kết quả trên các điểm cuối được phân trang hoặc sắp xếp các giao dịch nhiều bước bằng logic khôi phục, thì việc viết mã sẽ tự nhiên hơn so với việc tạo chuỗi lệnh gọi CLI. Cách tiếp cận của Duet có ý nghĩa đối với các đại lý về cơ bản là nhà phát triển tự chủ.

MCP sẽ tốt hơn khi nhân viên hỗ trợ của bạn hành động thay mặt cho người dùng của người khác. Đây là khía cạnh mà hầu hết các so sánh CLI-vs-MCP đều bỏ qua và nó đáng để nói thẳng. Khi nhân viên hỗ trợ của bạn tự động hóa quy trình làm việc của riêng bạn, thông tin xác thực xung quanh sẽ ổn. Bạn là người dùng và người duy nhất gặp rủi ro là bạn. Nhưng nếu bạn đang xây dựng một sản phẩm B2B trong đó các tổng đài viên hành động thay mặt cho nhân viên của khách hàng, trong các tổ chức mà khách hàng đó kiểm soát, thì vấn đề nhận dạng sẽ trở thành ba lớp: tổng đài viên nào đang gọi, người dùng nào đã ủy quyền và ranh giới dữ liệu của đối tượng thuê nào được áp dụng. OAuth cho mỗi người dùng với quyền truy cập có phạm vi, luồng đồng ý và quy trình kiểm tra có cấu trúc là những yêu cầu thực sự ở ranh giới đó và đó là những yêu cầu mà xác thực CLI thô (đăng nhập gh auth, biến môi trường) không được thiết kế để giải quyết. Mô hình ủy quyền của MCP, bất kể chi phí hiệu quả của nó, giải quyết vấn đề này một cách tự nhiên.

Điều đó cho thấy khoảng cách này hẹp hơn so với vẻ ngoài của kiến trúc API hợp nhất. Apideck đã tập trung hóa quá trình xác thực thông qua Vault: thông tin đăng nhập được quản lý theo từng người tiêu dùng, mỗi kết nối và trong phạm vi dịch vụ. Cờ --service-id nhắm mục tiêu tích hợp cụ thể trong kho tiền của người tiêu dùng cụ thể. Hệ thống cấp phép cấu trúc thực thi các ranh giới đọc/ghi/xóa trong tệp nhị phân. Điều còn thiếu là luồng đồng ý OAuth của mỗi người dùng và quy trình kiểm tra trong phạm vi đối tượng thuê, những khoảng trống thực sự, nhưng những khoảng trống nằm ở lớp nền tảng chứ không phải lớp giao diện tác nhân. CLI có thể là giao diện trong khi phần phụ trợ xử lý ủy quyền được ủy quyền. Những điều này không loại trừ lẫn nhau.

Cũng cần lưu ý rằng câu chuyện xác thực của MCP ít được giải quyết hơn so với vẻ ngoài của nó. Vì Hướng dẫn MCP OAuth của Speakeasy cho thấy rõ rằng thông số MCP thực sự không yêu cầu trao đổi OAuth đối mặt với người dùng. Việc chuyển trực tiếp mã thông báo truy cập hoặc khóa API là hoàn toàn hợp lệ. Sự phức tạp thực sự bắt đầu khi máy khách MCP cần xử lý các luồng OAuth một cách linh hoạt, yêu cầu Đăng ký máy khách động (DCR), một khả năng mà hầu hết các nhà cung cấp API hiện nay không hỗ trợ. Các công ty như Stripe và Asana đã bắt đầu bổ sung DCR để phù hợp với MCP, nhưng nó vẫn là một sự tích hợp có ma sát cao. Về mặt lý thuyết, lợi thế xác thực mà MCP có so với CLI là có thật, nhưng trên thực tế, hệ sinh thái vẫn đang bắt kịp thông số kỹ thuật.

CLI yếu hơn trong khả năng truyền phát trực tuyến và giao tiếp hai chiều. Lệnh gọi CLI là phản hồi yêu cầu. Nếu cần sự kiện do máy chủ gửi, luồng WebSocket hoặc kết nối lâu dài, bạn sẽ cần một máy chủ SDK hoặc MCP có thể duy trì kết nối mở.

Việc phân phối có trở ngại. Về mặt lý thuyết, các máy chủ MCP có thể hoạt động sau một URL. CLI cần có tệp nhị phân trên mỗi nền tảng, các bản cập nhật và quản lý PATH. Đối với Apideck CLI, chúng tôi gửi một tệp nhị phân Go tĩnh chạy ở mọi nơi mà không có phần phụ thuộc, nhưng đây vẫn là tệp nhị phân bạn cần cài đặt.

Khung hình trung thực: MCP, thực thi mã và CLI là những công cụ bổ sung. Sai lầm là coi MCP là câu trả lời chung khi, đối với nhiều mẫu tích hợp, CLI thực hiện công việc với chi phí bối cảnh ít hơn hai bậc.

Điều này có ý nghĩa gì đối với các nhà cung cấp API

Nếu bạn xây dựng các công cụ dành cho nhà phát triển vào năm 2026 thì các tác nhân AI sẽ trở thành người tiêu dùng chính trên bề mặt API của bạn. Không phải là người tiêu dùng duy nhất (các nhà phát triển con người vẫn quan trọng) mà là một người tiêu dùng đang phát triển nhanh chóng.

Một số điều đáng cân nhắc:

Thông số OpenAPI của bạn quá lớn so với cửa sổ ngữ cảnh. Nếu bạn có hơn 50 điểm cuối, việc chuyển đổi thông số kỹ thuật của bạn sang công cụ MCP sẽ tiêu tốn ngân sách của hầu hết các tương tác của tổng đài viên. Hãy nghĩ xem điểm vào lệnh tối thiểu trông như thế nào.

Tiết lộ dần dần không còn chỉ là một mẫu UX nữa. Đó là một chiến lược tối ưu hóa mã thông báo. Cung cấp cho tổng đài viên một cách để dần dần khám phá các khả năng thay vì từ bỏ mọi thứ ngay từ đầu.

An toàn về kết cấu là không thể thương lượng. Các lan can theo lời nhắc là biện pháp đảm bảo an ninh tương đương với hệ thống đỗ xe danh dự. Xây dựng mô hình quyền vào công cụ của bạn chứ không phải lời nhắc của bạn. Phân loại hoạt động theo mức độ rủi ro và thực thi phân loại đó trong mã.

Gửi các định dạng đầu ra thân thiện với máy. JSON theo mặc định trong các ngữ cảnh không tương tác. Mã thoát ổn định. Đầu ra xác định. Đây là các nguyên tắc đã được ghi lại cho thiết kế CLI tổng thể và chúng quan trọng vì người dùng thành thạo tiếp theo của bạn có thể không có tay.

Đọc thêm

Tác giả: gertjandewilde

#discussion