Nói tóm lại: Các tác nhân AI đang âm thầm loại bỏ giao diện người dùng khỏi phần mềm doanh nghiệp. Lớp dữ liệu, được hiển thị thông qua API và MCP, đang trở thành bề mặt sản phẩm mới. Năm thay đổi mà các nhóm API cần thực hiện trong quý này, cộng với một vấn đề mà chưa ai giải quyết được.
Giao diện người dùng từng là hàng rào bảo vệ vững chắc nhất trong phần mềm B2B. Nhân viên kinh doanh làm việc chủ yếu trong Salesforce. Các nhóm hỗ trợ làm việc trong Zendesk. Các nhóm mua sắm làm việc trong SAP. Tần suất truy cập, trí nhớ cơ bắp, cách giao diện đảm bảo tính sạch sẽ của dữ liệu bằng cách buộc mọi đầu vào phải qua một biểu mẫu: đó chính là hàng rào bảo vệ. Dữ liệu là thứ được lưu trữ trong quá trình đó.
Kỷ nguyên đó đang khép lại. Giờ đây, các tác nhân AI có thể đọc và ghi dữ liệu doanh nghiệp trực tiếp thông qua API mà không cần mở trình duyệt. Salesforce đã công bố một sản phẩm headless (không giao diện) cho phép các tác nhân truy cập trực tiếp vào lớp dữ liệu của nó. Các hệ thống lưu trữ dữ liệu khác chỉ chậm vài tuần, không phải vài năm. Nếu giao diện người dùng không còn là hàng rào bảo vệ, thì API chính là nó. Điều đó làm thay đổi bản chất của API.
“Phần mềm Headless” có nghĩa là gì trong thực tế
Phần mềm headless là phần mềm doanh nghiệp hiển thị lớp dữ liệu của nó thông qua API để các tác nhân có thể đọc và ghi trực tiếp. Giao diện người dùng không biến mất. Nó chỉ không còn là cánh cửa duy nhất nữa.
Điều này khác với “API-first” (một phương pháp thiết kế) và “headless CMS” (một kiến trúc nội dung). Cả hai đều mô tả cách phần mềm được xây dựng. Phần mềm headless mô tả một sự thay đổi của người tiêu dùng. Thứ đang đọc và ghi dữ liệu của bạn không còn là một con người với trình duyệt nữa. Đó là một tác nhân có quyền truy cập MCP và một mục tiêu.
Ba yếu tố đã đồng thời làm điều này khả thi: Các mô hình ngôn ngữ lớn (LLM) có thể lập kế hoạch và chọn công cụ mà không cần giám sát, MCP chuẩn hóa cách các tác nhân khám phá hệ thống bên ngoài, và việc trích xuất dữ liệu rẻ đến mức việc đóng kín API không còn bảo vệ được những gì bên dưới nữa.
Nếu API của bạn được thiết kế dựa trên giả định rằng một nhà phát triển chỉ viết một client để sử dụng nó một lần, và sau đó một người dùng sử dụng client đó hàng ngày, thì bạn có nhiều việc phải làm.
Năm yếu tố giữ chân người dùng không còn hiệu quả
Theo lịch sử, năm yếu tố đã giữ chân người dùng với các hệ thống doanh nghiệp. Hãy nhìn vào từng yếu tố qua lăng kính của một tác nhân và hầu hết chúng sẽ không còn đúng nữa.
Tần suất truy cập giữ chân người dùng thông qua trí nhớ cơ bắp. Nhân viên kinh doanh đã đăng nhập vào Salesforce tám lần một ngày trong nhiều năm. Các tác nhân không có cơ bắp, và chi phí chuyển đổi công cụ của chúng chỉ là chi phí chỉnh sửa một tệp cấu hình.
Các quy trình làm việc đọc-ghi làm cho việc di chuyển dữ liệu trở nên nguy hiểm vì dữ liệu luôn trong trạng thái chuyển động. Các tác nhân đọc và ghi với tốc độ máy; chúng không quan tâm cơ sở dữ liệu nào nằm phía sau API miễn là hợp đồng ổn định.
SOP không có tài liệu là những quy tắc không ai viết ra: “Các giao dịch trên 100 nghìn đô la cần có sự chấp thuận của Phó chủ tịch.” Vẫn khó để các tác nhân xử lý, điều này mang lại cho các công ty đương nhiệm một chút thời gian. Nhưng mỗi tác nhân thực hiện quy trình làm việc đều học được các quy tắc, và các quy tắc cuối cùng được mã hóa ở một nơi nào đó có thể đọc được.
Các vòng lặp thói quen nội bộ, cách cuộc họp giao ban hàng ngày của một nhóm được hình thành xung quanh công cụ mà tất cả họ chia sẻ, sẽ tan biến khi công việc hàng ngày của nhóm được thực hiện thông qua các tác nhân thay vì đó.
Tính quan trọng của tuân thủ là yếu tố duy nhất còn tồn tại. Rủi ro về quy định không quan tâm liệu con người hay tác nhân di chuyển dữ liệu; dấu vết kiểm toán vẫn phải tồn tại. Chúng ta sẽ quay lại vấn đề này.
Bốn trong số năm hàng rào bảo vệ đang suy yếu. Yếu tố thứ năm là điểm giao thoa nơi khả năng phòng thủ mới sẽ phát triển.
Năm điều các nhóm API cần thay đổi trong quý này
Nếu API là bề mặt sản phẩm mới, đây là những điều cần phải khác biệt về nó.
1. Coi API của bạn là bề mặt sản phẩm, không phải là đường ống dẫn
Một endpoint REST tồn tại “để frontend có thể gọi nó” là một tạo phẩm khác so với một endpoint REST mà một tác nhân cân nhắc và chọn để gọi. Cái đầu tiên có thể không nhất quán, không có tài liệu, và được định hình bởi bất cứ thứ gì mà giao diện người dùng cần trong quý này. Cái thứ hai thì không thể như vậy.
Nếu bạn đang thiết kế API cho các tác nhân AI, hợp đồng phải là giao diện. Điều đó có nghĩa là tên mô tả, hình dạng dự đoán được, không có các trường bị quá tải nghĩa ba thứ khác nhau tùy thuộc vào ngữ cảnh, và các phản hồi lỗi cho biết điều gì đã sai bằng ngôn ngữ mà một mô hình có thể hành động dựa trên đó. “400 Bad Request” là không đủ. “400: thiếu trường bắt buộc customer_id; hãy truyền ID của khách hàng mà hóa đơn này thuộc về” mới là đủ.
Thử nghiệm then chốt: một tác nhân có năng lực có thể gọi API của bạn một cách chính xác chỉ với thông số kỹ thuật OpenAPI và các mô tả trường không? Nếu câu trả lời yêu cầu phải đọc cả mã nguồn giao diện người dùng cũ của bạn để hiểu một endpoint làm gì, thì API vẫn chỉ là đường ống dẫn.
2. Phát hành MCP cùng với REST và GraphQL
REST là cách các tác nhân gọi API của bạn một khi chúng biết nó tồn tại. MCP là cách chúng khám phá xem API có thể làm gì ngay từ đầu. Một API REST không có máy chủ MCP giống như một trang web không có robots.txt và không có sitemap; về mặt kỹ thuật có thể gọi được, nhưng thực tế lại vô hình đối với các hệ thống muốn tiếp cận nó.
Đây không phải là vấn đề thay thế bề mặt API hiện có của bạn. Hãy giữ lại REST. Giữ lại GraphQL nếu bạn có. Thêm MCP như một phương ngữ thứ ba hiển thị cùng các khả năng thông qua một giao thức mà các tác nhân đã 'nói'. Thông số kỹ thuật Anthropic MCP bao gồm hợp đồng; Apidog bao gồm công việc kiểm thử và tài liệu cần thiết xung quanh nó.
Nếu bạn muốn tìm hiểu cơ bản về MCP là gì và tại sao nó lại quan trọng đối với các nhóm API nói riêng, hãy xem bài phân tích chuyên sâu của chúng tôi.
3. Thiết kế lại lược đồ xung quanh ý định và kết quả, không phải các đối tượng CRUD
Mô hình dữ liệu của Salesforce có Cơ hội, Khách hàng tiềm năng, Tài khoản, Liên hệ. Một tác nhân không suy nghĩ bằng những danh từ đó. Nó suy nghĩ bằng mục tiêu: “tìm mọi tài khoản sắp rời bỏ,” “soạn thảo đề xuất cho giao dịch đã chốt hôm qua,” “nâng cấp tài khoản đã mở một ticket P0 qua đêm.”
Thế hệ tiếp theo của các hệ thống lưu trữ dữ liệu sẽ được xây dựng xoay quanh các tác vụ, ý định, chuỗi, chính sách và kết quả, chứ không phải các đối tượng CRUD mà chúng ta đã mô hình hóa từ đầu những năm 2000.
Điều đó không có nghĩa là viết lại lược đồ của bạn ngay lập tức. Nó có nghĩa là thêm một lớp trên nó. Một endpoint /intents/capture nhận “khách hàng tiềm năng này đang mua” và trả về các bản ghi Cơ hội + Hoạt động + Nhiệm vụ phù hợp, thay vì buộc tác nhân phải kết hợp ba thao tác ghi riêng biệt. Ý định trở thành API; CRUD trở thành một chi tiết triển khai.
Hướng dẫn của chúng tôi về chuẩn bị API của bạn cho các tác nhân AI đi sâu hơn vào các mẫu này.
4. Giải quyết danh tính tác nhân và quyền được cấp phạm vi
Đây là vấn đề mà chưa ai giải quyết triệt để, vì vậy nó sẽ có một phần riêng bên dưới. Phiên bản ngắn gọn: mọi lệnh gọi của tác nhân cần một danh tính không phải của người dùng, được giới hạn quyền không phải của người dùng và được kiểm toán như một loại hành động riêng biệt. Nếu API của bạn không thể phân biệt giữa “Alice đã nhấp vào nút” và “Tác nhân của Alice đã nhấp vào nút thay mặt cô ấy lúc 3 giờ sáng khi cô ấy đang ngủ,” thì bạn đang có vấn đề.
Xem chính sách bảo mật MCP để biết các mẫu hiện tại.
5. Xây dựng lớp hành động với dấu vết kiểm toán và phản hồi vòng lặp kín
Khả năng phòng thủ mới không nằm ở việc lưu trữ bản ghi. Nó nằm ở việc thực hiện hành động, ghi lại kết quả và sử dụng phản hồi đó để cải thiện các quyết định trong tương lai. Một sản phẩm SaaS lưu trữ dữ liệu CRM của bạn là một cơ sở dữ liệu có giao diện người dùng. Một sản phẩm SaaS thực hiện hành động thay mặt bạn, quan sát những gì đã xảy ra và trở nên tốt hơn trong hành động theo thời gian là một thứ hoàn toàn khác.
Đối với các nhóm API, điều này có nghĩa là ba thay đổi. Các endpoint hành động cần các callback kết quả hoặc webhook để tác nhân biết được điều gì đã xảy ra. Mọi hành động đều phải có khả năng phát lại, nếu không bạn không thể gỡ lỗi những gì tác nhân đã làm. Và mọi hành động cần một hàng kiểm toán với đầu vào, đầu ra, danh tính tác nhân và dấu vết lý do nếu bạn có thể lấy được.
Kiểm thử quy trình làm việc của tác nhân mà không mất dữ liệu là phiên bản vận hành của sự thay đổi này.
Phần chưa được giải quyết: cấp quyền cho tác nhân
Trong tất cả các khoảng trống trong phần mềm sẵn sàng cho tác nhân, đây là vấn đề ít được giải quyết nhất và có hệ quả lớn nhất. Những tác nhân nào được ủy quyền làm gì, thay mặt ai, với khả năng kiểm toán như thế nào?
Câu trả lời chân thật vào năm 2026 là hầu như chưa ai thực hiện tốt điều này. OAuth được xây dựng cho quyền truy cập người dùng được ủy quyền, không phải cho tác nhân. RBAC được xây dựng cho vai trò của con người. Nhật ký kiểm toán được xây dựng để theo dõi những gì người dùng đã làm, không phải tác nhân của người dùng nào đã làm gì theo chính sách nào.
Bốn mẫu đang nổi lên và hoạt động tốt hiện nay, ngay cả trước khi các tiêu chuẩn được ban hành.
Token được giới hạn phạm vi cho mỗi danh tính tác nhân. Không bao giờ tái sử dụng token phiên của người dùng cho một tác nhân hoạt động thay mặt họ. Cấp một token riêng biệt với phạm vi riêng biệt, ngay cả khi nó hẹp hơn quyền đầy đủ của người dùng, và xoay vòng nó một cách độc lập. Nếu token bị rò rỉ, bạn thu hồi quyền của tác nhân, không phải của người dùng.
Metadata ủy quyền trên mọi yêu cầu. Mọi lệnh gọi API nên mang theo một header như X-Acting-On-Behalf-Of: user_id và X-Agent-Identity: agent_name@version. Hai header bổ sung, không thay đổi logic endpoint của bạn, và câu chuyện kiểm toán của bạn sẽ tốt hơn gấp mười lần.
Nhật ký kiểm toán chỉ ghi thêm cho các hành động của tác nhân. Các hành động của tác nhân thuộc về một bảng kiểm toán riêng biệt so với các hành động của người dùng. Các mẫu truy vấn khác nhau; các nhóm tuân thủ sẽ muốn trả lời “các tác nhân đã làm gì trong tuần này” mà không cần cuộn qua hoạt động của con người.
Chính sách dưới dạng mã. Khai báo, trong một tệp cấu hình có phiên bản, những gì mỗi lớp tác nhân được phép làm. “Tác nhân hỗ trợ khách hàng có thể đọc hóa đơn và hoàn tiền lên đến 50 đô la; không thể xóa tài khoản.” Kiểm tra nó. Thử nghiệm nó. So sánh nó. Chính sách cấp quyền phải là một tạo phẩm xây dựng, không phải một trang wiki.
Không có điều nào trong số này là một tiêu chuẩn hoàn chỉnh. Tất cả đều có thể triển khai ngay bây giờ.
Apidog phù hợp ở đâu
Nếu bạn định coi API của mình là sản phẩm, bạn cần một công cụ tích hợp xử lý thiết kế, hợp đồng, mocking, MCP, kiểm thử và kiểm toán tại một nơi. Đó là lý do chúng tôi xây dựng Apidog, và năm thay đổi này khớp hoàn hảo với công việc mà nó đã hỗ trợ.
- Thay đổi 1 (API là sản phẩm): thiết kế theo lược đồ (schema-first) và tài liệu tự động tạo, để hợp đồng là nguồn thông tin đáng tin cậy duy nhất mà các tác nhân của bạn đọc.
- Thay đổi 2 (MCP cùng với REST): công cụ kiểm thử máy chủ MCP chuyên dụng để xác minh máy chủ MCP của bạn trước khi phát hành.
- Thay đổi 3 (API định hình theo ý định): mocking với các phản hồi động, để bạn có thể tạo nguyên mẫu một endpoint ý định và cho tác nhân client của bạn gọi nó trước khi backend tồn tại.
- Thay đổi 4 (cấp quyền): quản lý môi trường để tách biệt token tác nhân khỏi token người dùng, cộng với kiểm thử khẳng định để thực thi chính sách.
- Thay đổi 5 (lớp hành động + kiểm toán): Trình gỡ lỗi tác nhân AI và Trình gỡ lỗi A2A được phát hành vào tháng 4 cho phép bạn theo dõi, phát lại và khẳng định các lệnh gọi API do tác nhân điều khiển từ đầu đến cuối.
Nếu bạn chưa thử, hãy tải Apidog và chạy thông số kỹ thuật OpenAPI hiện có của bạn qua nó. Chỉ riêng máy chủ mock cũng thường đủ để bù đắp chi phí di chuyển.
Lời đặt cược
Lời đặt cược mà các nhóm API nên thực hiện ngay bây giờ là rất rõ ràng. Chính API là sản phẩm. Nếu nó chỉ là đường ống dẫn, nó là một mặt hàng thông thường. Nếu nó là bề mặt mà các tác nhân suy luận, chọn lựa, tin tưởng và hành động dựa trên đó, thì nó là hàng rào bảo vệ.
Các nhóm triển khai trong quý này sẽ có các bề mặt API trông không giống với những gì được xây dựng năm năm trước. Các nhóm chờ đợi sẽ phải viết lại chúng dưới áp lực thời hạn vào năm 2027, sau khi một khách hàng lớn hỏi tại sao tích hợp tác nhân “không hoạt động đúng cách.”