Mọi API sẽ được xây dựng lại dành cho các Agent

MCP giải quyết vấn đề kết nối. Nó không giải quyết được khoảng cách về động từ (verb gap).

Bạn có thể bọc một REST API hoàn hảo vào MCP chỉ trong một buổi chiều. Ngay cả khi đó, một coding agent vẫn sẽ gặp khó khăn. Nó sẽ chọn sai endpoint. Nó sẽ gọi ba công cụ trong khi chỉ cần một. Nó có thể thực hiện một thao tác ghi mang tính hủy diệt mà không cần hỏi trước.

API không hề bị lỗi. Nó chỉ được xây dựng cho sai đối tượng sử dụng.

Trong suốt hai mươi năm qua, các API được xây dựng cho con người. Con người mang theo ý định và một mô hình tư duy (mental model). Các agent thì không có cả hai. Chúng phải tái cấu trúc cả hai từ bề mặt giao diện của bạn.

Khi đối tượng sử dụng chính thay đổi nhiều đến mức này, giao diện cũng phải thay đổi theo.

Tôi tin rằng các bề mặt sản phẩm nghiêm túc sẽ không chỉ đơn thuần là bọc các API hiện có. Họ sẽ xây dựng lại chúng xoay quanh các thao tác dành riêng cho agent (agent-native operations).

Điều này có nghĩa là chuyển dịch từ các API định dạng theo tài nguyên (resource-shaped APIs) sang các hợp đồng định dạng theo ý định (intent-shaped contracts). Chúng ta phải thiết kế lại xoay quanh các mục tiêu, trạng thái, tác dụng phụ (side-effects), sự phê duyệt và khả năng phục hồi.

MCP là một tiêu chuẩn tuyệt vời cho việc kết nối và truyền tải. Nhưng trong đặc tả (spec), một công cụ chỉ là một hàm với một cái tên và một schema. Nó không quyết định thứ tự các thao tác hay thao tác nào là nguy hiểm.

Điều này tạo ra khoảng cách về động từ. Các API cung cấp cho agent các danh từ và các thao tác CRUD. Các agent cần các động từ mang theo ý định.

Hãy nhìn vào GitHub. Họ đang thu hẹp bộ công cụ của mình để cải thiện khả năng lập luận của agent. Họ đang nhận ra rằng việc ánh xạ 1:1 từ API sản phẩm sang các công cụ cho agent là không hiệu quả.

Nghiên cứu cho thấy một API có thể hợp lệ về mặt cấu trúc nhưng lại vô dụng về mặt ngữ nghĩa đối với một agent. Một API dành riêng cho agent (agent-native API) trả lời nhiều hơn là chỉ câu hỏi "tôi nên trả về cái gì". Nó trả lời:

  • Mục tiêu là gì?
  • Tôi đang ở trạng thái nào?
  • Các tác dụng phụ là gì?
  • Tôi có cần sự phê duyệt không?
  • Làm thế nào để tôi phục hồi?

Thay vì một thao tác ghi thô (raw write), bạn cần chia nhỏ nó ra:

  • Xem trước hành động.
  • Nhận sự phê duyệt rõ ràng.
  • Xác nhận thay đổi (commit).
  • Hoàn tác (rollback) nếu thất bại.

Đây không chỉ là một "phiên bản dành cho agent". Đây đơn giản là một API tốt hơn. Các nhà phát triển cũng muốn có các bản xem trước, các lỗi quyền hạn rõ ràng và khả năng hoàn tác. Cuối cùng, thiết kế dành riêng cho agent sẽ thay thế thiết kế lấy con người làm trung tâm.

Sự chuyển dịch này là rất lớn. Nó ảnh hưởng đến API, CLI và nhật ký (logs). Chúng ta phải chuyển từ văn bản dễ đọc cho con người sang trạng thái có thể phân tích được bởi máy móc.

Sự an toàn không phải là một lớp bọc (wrapper) mà bạn thêm vào sau đó. Sự an toàn là một thuộc tính mà bạn phải thiết kế ngay vào chính thao tác đó.

Source: https://dev.to/gyu07/every-api-will-be-rebuilt-for-agents-2hj4

Optional learning community: https://t.me/GyaanSetuAi