API cho AI Agent: từ MCP đến endpoint tùy chỉnh

Khi LLM học cách gọi hàm

Trong thời GPT-3, tương tác với một LLM nghĩa là đưa cho nó một prompt và nhận lại văn bản. Kiến thức của mô hình rất lớn nhưng tĩnh, bị đóng băng ở những gì dữ liệu huấn luyện chứa. Bạn có thể yêu cầu nó giải thích điện toán lượng tử hoặc soạn email, và nó sẽ tạo ra văn bản có vẻ hợp lý. Nhưng nó không thể kiểm tra thời tiết hôm nay, truy vấn cơ sở dữ liệu, hoặc thực hiện bất kỳ hành động nào trong thế giới thực.

Tính năng đã thay đổi điều này lại ít được ghi nhận một cách đáng ngạc nhiên. Nó cho mô hình một lựa chọn giữa việc tạo văn bản và gọi một hàm. Thay vì luôn tạo token tiếp theo, giờ đây mô hình có thể xuất ra một đối tượng JSON có cấu trúc, chỉ định tên hàm và các đối số của hàm đó. Runtime sẽ thực thi hàm đó, đưa kết quả trở lại cho mô hình, và mô hình sẽ tiếp tục từ đó. Bài báo ReAct (Yao et al., 2022) đã chính thức hóa cơ chế này thành vòng lặp Thought-Action-Observation. Mô hình suy luận về việc cần làm, thực hiện một hành động (gọi một công cụ), quan sát kết quả, rồi lặp lại. Mọi AI agent nghiêm túc trong năm 2026 đều chạy trên một phiên bản nào đó của mẫu này.

Vòng lặp

Claude Code, OpenClaw, Codex, Devin và hàng chục hệ thống agentic khác đều vận hành theo cùng một cách. Gọi một công cụ, quan sát kết quả, quyết định việc cần làm tiếp theo, lặp lại. Simon Willison diễn đạt rất gọn: “Một LLM agent chạy các công cụ trong một vòng lặp để đạt được mục tiêu.”

Ví dụ, Claude Code dùng một single-threaded master loop, không có swarm đa agent hay đồ thị điều phối phức tạp: while(tool_call) -> execute -> feed results -> repeat.

Nghiên cứu về tính tự chủ của agent của Anthropic cho thấy thời lượng lượt trong Claude Code gần như tăng gấp đôi trong ba tháng, từ 25 lên hơn 45 phút. Người dùng ngày càng tin tưởng để vòng lặp tự chạy. Dữ liệu cho thấy người dùng có kinh nghiệm ngắt thường xuyên hơn (chuyển từ phê duyệt từng hành động sang giám sát chiến lược), trong khi bản thân agent yêu cầu làm rõ nhiều hơn gấp đôi so với số lần người dùng ngắt nó.

Mẫu vòng lặp này xuất hiện ở khắp nơi, trong coding agent, bot hỗ trợ khách hàng và cả bộ điều khiển robot.

Thế nào được tính là một công cụ?

LLM cho chúng ta mức độ tự do đáng kể khi quyết định một công cụ nên hoạt động ở tầng trừu tượng nào. Ở một cực, bạn có các endpoint API rất cụ thể: “tạo một contact HubSpot với 12 trường này.” Ở cực còn lại, bạn có các công cụ như “chạy lệnh bash này” hoặc “thực thi đoạn mã Python này”, về bản chất là “muốn làm gì thì làm.”

Devin vận hành với ba công cụ: shell, trình chỉnh sửa mã, trình duyệt. Công cụ chính của Claude Code cũng là shell. OpenClaw dùng một hệ thống plugin kỹ năng động. Xu hướng trong các công cụ lập trình agentic là hướng tới ít công cụ hơn nhưng tổng quát hơn, thay vì nhiều công cụ cụ thể.

Simon Willison nhận xét rằng MCP “ban đầu bùng nổ nhưng sau đó có vẻ bớt trung tâm hơn” đối với coding agent, vì bash là công cụ phổ quát. File và script là primitive có chi phí thấp hơn so với triển khai máy chủ MCP đầy đủ. Nếu agent có thể viết và thực thi mã, nó có thể làm gần như mọi thứ mà không cần định nghĩa công cụ chuyên dụng.

Nhưng công cụ đa dụng phù hợp với agent đa dụng. Với AI agent theo miền cụ thể (hỗ trợ khách hàng, bán hàng, vận hành nội bộ), bạn cần công cụ theo miền cụ thể. Agent hỗ trợ của bạn không nên viết Python để kiểm tra trạng thái đơn hàng. Nó nên gọi một endpoint API được định nghĩa rõ ràng, với tham số rõ ràng và phản hồi có thể dự đoán. Thiết kế bộ công cụ của bạn trở thành một quyết định sản phẩm.

Endpoint API hiện nay có nghĩa là gì

Đối với AI agent, một endpoint API hoạt động như một tuyên bố năng lực. Việc công bố một endpoint nói rằng bạn (hoặc AI agent của bạn) giờ đây có thể làm một việc trước đây không thể làm.

Điều này hoạt động theo cả hai chiều. Một nhà cung cấp phần mềm công bố API để người khác có thể tích hợp với sản phẩm của họ. Nhưng một AI agent cũng có thể tự khám phá endpoint bằng cách tìm kiếm tài liệu, đọc đặc tả OpenAPI, hoặc theo đúng nghĩa đen là google cách hoàn thành một tác vụ.

Một máy chủ MCP là một gói endpoint API được tuyển chọn, với một quan niệm sẵn có về cách chúng nên được sử dụng. Người tạo MCP đã đưa ra quyết định về endpoint nào được expose, đặt tên chúng thế nào, đưa ra những tham số nào, và ngầm định hỗ trợ những workflow nào. Việc tuyển chọn đó vừa là điểm mạnh (tiện lợi, chuẩn hóa) vừa là điểm yếu (cứng nhắc, phạm vi mang tính áp đặt). Máy chủ của Notion là một ví dụ cụ thể: nó công bố 28 công cụ, và một help-center agent cần bốn công cụ trong số đó, được chia trên hai kết nối.

MCP đánh đổi quyền kiểm soát để lấy sự dễ dùng. Năm 2026, AI viết phần lớn mã tích hợp. Nếu một agent có thể đọc tài liệu API và tự viết phần tích hợp, lập luận “dễ dùng” cho MCP yếu đi. Lớp MCP có thể quan trọng nhất trong giai đoạn chuyển tiếp, khi công cụ hỗ trợ chưa bắt kịp năng lực của mô hình. Hướng dẫn về các mẫu thiết kế sử dụng công cụ của Anthropic là một tài liệu tham khảo thực tế để cấu trúc schema công cụ, bất kể bạn dùng MCP hay từng endpoint riêng lẻ.

Một diễn biến liên quan: llms.txt là một tiêu chuẩn được đề xuất, trong đó website công bố file /llms.txt để hướng dẫn mô hình AI tới các tài nguyên có giá trị cao. Anthropic, Cloudflare, Docker và Stripe đã áp dụng nó. MCP chuẩn hóa việc gọi công cụ, llms.txt chuẩn hóa việc khám phá tài liệu. Cả hai đều cố gắng làm cho web dễ đọc hơn đối với máy móc, từ các góc độ khác nhau.

Endpoint API là gì trong ngữ cảnh AI agent?

Endpoint API là một URL cụ thể nhận đầu vào có cấu trúc và trả về đầu ra có cấu trúc. Đối với AI agent, mỗi endpoint đại diện cho một năng lực rời rạc, một việc agent có thể làm trong thế giới thực. Phần mô tả endpoint, định nghĩa tham số và phản hồi lỗi đóng vai trò như sổ tay hướng dẫn của agent. Endpoint càng được tài liệu hóa tốt, agent càng có thể sử dụng nó một cách đáng tin cậy.

Khác với lập trình viên con người, những người có thể đọc tutorial và debug lặp đi lặp lại, agent dựa vào schema và mô tả của endpoint để thực hiện một lệnh gọi đúng ngay trong một lần. Đây là lý do tài liệu API được thiết kế cho AI tiêu thụ quan trọng hơn bao giờ hết. Chỉ 24% lập trình viên hiện thiết kế API với AI agent trong đầu, dù 89% dùng AI trong workflow của họ.

MCP (Model Context Protocol) là gì?

MCP là một giao thức mở do Anthropic giới thiệu, chuẩn hóa cách AI agent kết nối với công cụ và nguồn dữ liệu bên ngoài. Hãy xem nó như USB-C cho AI. Một đầu nối duy nhất mà bất kỳ nhà cung cấp công cụ nào cũng có thể triển khai và bất kỳ AI agent nào cũng có thể sử dụng. Một máy chủ MCP expose một tập công cụ (về cơ bản là các endpoint API) với schema được chuẩn hóa, và một MCP client (agent) có thể khám phá và gọi chúng mà không cần mã tích hợp tùy chỉnh. Để có phần giải thích kỹ thuật sâu hơn, xem bài Giải thích MCP của chúng tôi. Để có tường thuật thực tế về MCP trong production, xem phân tích của chúng tôi về các thách thức thực tế khi xây dựng trên MCP của Shopify.

Phổ kiểm soát trong Quickchat AI

Quickchat AI cung cấp cho bạn ba cách để trang bị công cụ bên ngoài cho một AI Agent. Chúng nằm trên một phổ từ tự động hóa nhiều nhất đến kiểm soát nhiều nhất. Mỗi cách tiếp cận tạo ra một đánh đổi khác nhau giữa tốc độ thiết lập và độ chính xác của hành vi.

Remote MCP: cắm vào và chạy

Remote MCP là cách nhanh nhất để kết nối một AI Agent với chức năng bên ngoài. Bạn cung cấp URL máy chủ MCP, Quickchat AI kết nối tới đó, khám phá tất cả công cụ có sẵn, và cho phép bạn chọn công cụ nào agent của bạn nên dùng.

Cách thiết lập:

1. Đi tới AI Actions trong dashboard Quickchat AI
2. Nhấp “Add Remote MCP”
3. Dán URL máy chủ MCP của bạn (ví dụ: https://mcp.example.com/sse)
4. Tùy chọn thêm token xác thực hoặc header tùy chỉnh (hai tùy chọn này loại trừ lẫn nhau)
5. Nhấp “Connect.” Quickchat AI khám phá tất cả công cụ có sẵn và hiển thị tên của chúng
6. Bật hoặc tắt từng công cụ để kiểm soát công cụ nào agent của bạn có thể dùng
7. Đặt cờ “default tool is active” để kiểm soát việc các công cụ mới được khám phá sẽ tự động được bật hay bị tắt

Điều xảy ra bên dưới:

Khi bạn nhấp Connect, Quickchat AI tự động phát hiện giao thức transport từ URL. Nếu URL chứa sse, transport SSE được sử dụng, nếu không thì mặc định là streamable_http. Khi bạn cung cấp auth token, token đó được gửi dưới dạng token Bearer trong header Authorization.

Lọc công cụ hoạt động thông qua một hệ thống ba tầng. Mỗi công cụ từ máy chủ MCP được kiểm tra với hai tập: công cụ được bật rõ ràng luôn được đưa vào, công cụ bị tắt rõ ràng luôn bị loại trừ, và bất kỳ công cụ nào không thuộc hai tập đó sẽ quay về thiết lập “default tool is active” mà bạn đã chọn. Điều này có nghĩa là khi một máy chủ MCP thêm công cụ mới, bạn kiểm soát việc chúng có tự động khả dụng cho agent của bạn hay yêu cầu kích hoạt rõ ràng.

Tại runtime, khi một cuộc trò chuyện bắt đầu, tất cả kết nối Remote MCP đang hoạt động của agent được tải. Các công cụ được lấy và lọc theo cấu hình của từng kết nối, và tính duy nhất của tên công cụ được xác minh trên tất cả nguồn (kèm cảnh báo nếu tìm thấy trùng lặp).

Đánh đổi: bạn có quyền truy cập ngay vào mọi thứ MCP expose, nhưng bạn có quyền kiểm soát hạn chế đối với mô tả công cụ, định nghĩa tham số, hoặc cách agent quyết định sử dụng chúng. Như chúng tôi đã thấy khi xây dựng một AI Agent trên MCP của Shopify, việc đi từ demo tới production đòi hỏi tinh chỉnh cẩn thận, điều mà cách tiếp cận gói của MCP có thể làm trở nên khó khăn.

Xem thêm: kết nối agent của bạn với máy chủ MCP từ xa, Cách khởi chạy Quickchat AI MCP của bạn, cân nhắc bảo mật MCP, tài liệu Quickchat AI: kênh MCP.

AI Actions (HTTP Request): một endpoint, toàn quyền kiểm soát

Một AI Action trong Quickchat AI là một endpoint HTTP API duy nhất mà bạn cấu hình riêng cho AI Agent của mình. Trong khi MCP nhập một gói công cụ cùng lúc, mỗi AI Action cho bạn toàn quyền kiểm soát một năng lực cụ thể. Để xem một ví dụ hoàn chỉnh, bốn action tạo và làm giàu contact, ghi deal và mở ticket trong CRM, xem tutorial AI Actions cho HubSpot.

Cấu hình một AI Action:

1. Name (tối đa 64 ký tự): tên này trở thành tên công cụ mà LLM nhìn thấy. Nó được chuẩn hóa thành một định danh hợp lệ (ví dụ: “Check Order Status” trở thành Check_Order_Status)
2. Description (tối đa 1.000 ký tự): đây là trường quan trọng nhất. Phần mô tả cho LLM biết khi nào dùng công cụ này. Mô tả tốt nêu rõ nên gọi công cụ trong hoàn cảnh hội thoại nào, cần thu thập thông tin gì từ người dùng trước, và kết quả nên được truyền đạt lại như thế nào
3. HTTP method: GET, POST, PATCH, DELETE, hoặc PUT
4. URL (tối đa 10.000 ký tự): có thể chứa placeholder {{parameter_name}} cho giá trị động
5. Headers: cặp key-value cho xác thực và content type
6. Body items / Body JSON: request body với cơ chế chèn tham số
7. Query parameters: giá trị query string của URL
8. Parameters (tối đa 10): mỗi tham số có tên, mô tả (tối đa 500 ký tự), kiểu (str, int, float, bool, hoặc custom), cờ bắt buộc và giá trị mặc định tùy chọn

Placeholder {{parameter_name}} là cơ chế chính. Khi LLM gọi công cụ, nó cung cấp giá trị cho từng tham số dựa trên ngữ cảnh cuộc trò chuyện. Quickchat AI sau đó chèn các giá trị đó vào URL, header, body và template query string trước khi thực hiện HTTP request. Cũng có bốn biến tích hợp có thể được chèn theo cách này: scenario_id, conversation_id, conversation_channel, và conversation_url.

Một AI Action được cấu hình để kiểm tra trạng thái đơn hàng, hiển thị template URL với placeholder tham số, header và định nghĩa tham số.

Bên dưới: Quickchat AI xây dựng động một schema có kiểu từ định nghĩa tham số của bạn cho mỗi AI Action. Năm kiểu được hỗ trợ (str, int, float, bool, custom) được ánh xạ sang các kiểu native tương ứng, và schema này được dùng để xác thực đầu vào của LLM trước khi thực hiện HTTP request.

Ví dụ AI Action để kiểm tra trạng thái đơn hàng:

{
  "name": "check_order_status",
  "description": "Khi người dùng hỏi về trạng thái đơn hàng của họ và đã cung cấp mã đơn hàng, hãy gọi endpoint này để lấy trạng thái hiện tại. Báo lại cho người dùng trạng thái, ngày giao hàng dự kiến và mã theo dõi (nếu có).",
  "method": "GET",
  "url": "https://api.example.com/orders/{{order_id}}",
  "headers": [
    { "name": "Authorization", "value": "Bearer YOUR_API_KEY" },
    { "name": "Content-Type", "value": "application/json" }
  ],
  "parameters": [
    {
      "name": "order_id",
      "description": "Mã đơn hàng do người dùng cung cấp (ví dụ: ORD-12345)",
      "type": "str",
      "is_required": true
    }
  ]
}

Kiểm thử: Dashboard có nút “Test” cho phép bạn cung cấp giá trị tham số mẫu và xem HTTP request thực tế (bao gồm lệnh curl được tạo) cùng phản hồi trước khi triển khai.

Mẹo viết mô tả AI Action hiệu quả:

• Hãy cụ thể về thời điểm agent nên gọi nó: “Khi người dùng hỏi về trạng thái đơn hàng và cung cấp mã đơn hàng, hãy gọi endpoint này”
• Nêu thông tin cần thu thập trước: “Trước khi gọi, hãy đảm bảo bạn có địa chỉ email và mã đơn hàng của người dùng”
• Mô tả cách xử lý phản hồi: “Nếu trạng thái là ‘shipped’, hãy cho người dùng biết mã theo dõi từ phản hồi”
• Với workflow nhiều bước, hãy mô tả trình tự trong system prompt chính của agent thay vì trong từng mô tả action riêng lẻ, và để mang một giá trị giữa các action và chặn thao tác ghi dựa trên giá trị đó, hãy dùng Save to memory cộng với run-condition

Ví dụ hoàn chỉnh: để xem AI Action từng bước ghi lead, câu hỏi chưa được trả lời và yêu cầu demo trực tiếp vào bảng tính, xem cách kết nối AI agent với Google Sheets.

Generate from Text: để AI tự tìm cách

Tùy chọn thứ ba dành cho người dùng biết họ muốn agent của mình làm gì, nhưng không biết endpoint API nào (hoặc thậm chí dịch vụ nào) cần dùng.

Cách hoạt động:

1. Bạn nhập mô tả bằng ngôn ngữ tự nhiên về điều bạn muốn, ví dụ: “Tôi muốn AI Agent của mình có thể khởi động Tesla của người dùng khi họ yêu cầu”
2. Quickchat AI gửi nội dung này tới một LLM có bật công cụ web_search
3. Mô hình nghiên cứu web để tìm API phù hợp, đọc tài liệu chính thức, và tạo một đặc tả AI Action hoàn chỉnh bao gồm URL, method, header, tham số và yêu cầu xác thực
4. Kết quả trả về với cấu hình action đầy đủ, trích dẫn tới tài liệu đã sử dụng, và một thông điệp giải thích nêu các giả định và khoảng thiếu
5. Bạn rà soát, điền thông tin đăng nhập, và kích hoạt

Nhập mô tả bằng ngôn ngữ tự nhiên về năng lực mong muốn.

Cấu hình AI Action được tạo, kèm trích dẫn tới tài liệu API đã sử dụng.

Việc tạo AI Action tự động được cấu trúc quanh ba ưu tiên:

• Ưu tiên 1: Hiểu ý định. Xác định năng lực chính xác mà lập trình viên muốn và endpoint API cụ thể cung cấp năng lực đó
• Ưu tiên 2: Bám vào tài liệu. Dùng tìm kiếm web để tìm tài liệu chính thức của nhà cung cấp, không phỏng đoán
• Ưu tiên 3: Thiết kế ngữ nghĩa lấy hội thoại làm trung tâm. Tên và mô tả được tạo nên nói về thời điểm trong cuộc trò chuyện công cụ này được sử dụng, không chỉ là API làm gì về mặt kỹ thuật

Prompt dùng hai quy ước placeholder. {{param}} đánh dấu tham số runtime mà LLM điền từ ngữ cảnh cuộc trò chuyện. [[secret_name]] (hai cặp ngoặc vuông) đánh dấu hằng số của lập trình viên, như API key và account ID, phải được cấu hình thủ công trước khi kích hoạt. Mọi tên tham số phải xuất hiện dưới dạng placeholder {{that_exact_name}} ở đâu đó trong định nghĩa request, và không được có placeholder mồ côi.

Hệ thống dùng chính sách fail-closed. Nếu mô hình không thể xác nhận một thông tin quan trọng từ tài liệu (HTTP method, URL, sơ đồ xác thực, hoặc cấu trúc payload bắt buộc), không action nào được tạo. Thay vào đó, hệ thống trả về một giải thích ngắn gọn về nội dung còn thiếu thay vì phỏng đoán.

Đây là nơi luận điểm mang tính triết lý về việc AI agent khám phá API kết nối với một tính năng sản phẩm cụ thể. Tính năng Generate from Text đúng nghĩa là một AI agent (một LLM có tìm kiếm web) xây dựng định nghĩa công cụ cho một AI agent khác (agent Quickchat AI sẽ dùng nó trong các cuộc trò chuyện).

Ví dụ hoàn chỉnh: để xem tutorial đầy đủ biến hai câu được nhập thành hai action hoạt động trực tiếp và đã kiểm thử (một tra cứu thời tiết không cần key và một action NASA cần key, bao gồm cả từ chối fail-closed), xem cách kết nối AI agent của bạn với bất kỳ API nào bằng tiếng Anh đơn giản.

Tại runtime, tất cả loại công cụ này được ghép lại với nhau. Quickchat AI thu thập công cụ AI Action dạng HTTP request, công cụ Shopify MCP, công cụ knowledge base, công cụ remote MCP, công cụ Discord và các công cụ tùy chỉnh khác vào một tập hợp để trình bày cho LLM. Mô hình không thấy sự khác biệt giữa chúng. Một công cụ Remote MCP và một AI Action được cấu hình thủ công trông giống hệt nhau khi đã nằm trong danh sách công cụ.

API mở như SEO mới

Nếu AI agent sẽ tự khám phá và sử dụng API, thì việc có một API được tài liệu hóa tốt, dễ dùng sẽ trở thành một tài sản phân phối. Gartner dự đoán rằng hơn 30% mức tăng nhu cầu API sẽ đến từ AI agent vào năm 2026.

Các công ty có API mở với rào cản credential tối thiểu có thể nhận ra rằng API của họ trở thành kênh thu hút tốt nhất. Thay vì lượt hiển thị trên Google Search, “lượt hiển thị” là các AI agent chọn dùng dịch vụ của bạn thay vì dịch vụ của đối thủ.

Logic tương tự áp dụng ở tầng cao hơn. Một AI agent trả lời từ tài liệu của bạn tự nó có thể được expose dưới dạng máy chủ MCP để ChatGPT, Claude và Cursor gọi như một công cụ, giúp tri thức của bạn, không chỉ API của bạn, có thể được agentic web khám phá.

Chất lượng tài liệu API của bạn quyết định liệu một AI agent có thể tích hợp thành công với bạn trong một lần thử hay không. Mô tả tham số, thông báo lỗi và phản hồi ví dụ phục vụ cùng chức năng như meta description và dữ liệu có cấu trúc trong SEO truyền thống. Một phản hồi lỗi khó hiểu hoặc một trường bắt buộc không được tài liệu hóa sẽ khiến agent thất bại, và không có con người ở phía bên kia để debug.

Các công ty có API không được tài liệu hóa hoặc bị chặn sau yêu cầu credential nặng nề có thể thấy mình vô hình đối với agentic web, giống như các công ty không có website đã trở nên vô hình với Google trong những năm 2000.

Computer Use so với API

Có khoản đầu tư đáng kể vào việc dạy mô hình AI “computer use” (nhấp nút, điền form, điều hướng UI). Anthropic, OpenAI (Operator) và các dự án mã nguồn mở như Browser Use đều cung cấp các phiên bản của hướng này.

Nhưng việc dùng trình duyệt là một giải pháp vòng khi thiếu API. Một lệnh gọi POST /orders mất vài mili giây và trả về dữ liệu có cấu trúc. Một browser agent điều hướng luồng thanh toán mất vài phút và có thể hỏng khi một nút dịch sang trái ba pixel. API nhanh hơn, xác định hơn và rẻ hơn khi thực thi.

Phản biện là có cơ sở: API không tồn tại cho mọi thứ. Hệ thống legacy, phần mềm doanh nghiệp không có bề mặt API, thiết bị vật lý được điều khiển qua GUI. Computer use lấp một khoảng trống thực sự trong những trường hợp đó.

Phản hồi dài hạn tốt hơn cho câu “chúng tôi không có API cho việc này” có lẽ là xây API, thay vì dạy AI dùng GUI. Khi ngày càng nhiều phần mềm được viết bởi AI agent cho AI agent, chi phí xây dựng và bảo trì API giảm xuống. Phép tính kinh tế từng khiến việc scrape UI rẻ hơn xây API đang thay đổi.

Cũng có một góc độ bảo mật. “Lethal trifecta” của Simon Willison mô tả tổ hợp nguy hiểm gồm quyền truy cập dữ liệu riêng tư + tiếp xúc với nội dung không đáng tin cậy + giao tiếp bên ngoài. Điều này áp dụng cho cả hai cách tiếp cận, nhưng công cụ dựa trên API dễ audit và ràng buộc hơn. Bạn có thể log mọi lệnh gọi API, xác thực mọi tham số, và rate-limit mọi endpoint. Làm điều tương đương cho một browser agent có thể nhấp vào bất cứ thứ gì khó hơn nhiều.

Công cụ cho thế giới vật lý

Mọi thứ đã bàn tới cho đến nay đều nói về phần mềm. Mẫu tương tự cũng xuất hiện trong thế giới vật lý.

RT-2 và Gemini Robotics của Google DeepMind dùng cùng kiến trúc, ngoại trừ việc các công cụ điều phối tới bộ truyền động thay vì API. Framework SPCA (Sense-Plan-Code-Act) chính thức hóa điều này cho robot: quét môi trường, lập kế hoạch cách tiếp cận, tạo mã có thể thực thi, thực thi mã đó, quan sát kết quả.

Không có API cho việc “dịch cái cây trên bàn của tôi sang phải.” Nhưng một robot có camera có thể định nghĩa move_object(object_id="plant_01", direction="right", distance_cm=15) như một công cụ ngay tại thời điểm đó rồi gọi nó. Định nghĩa công cụ đóng vai trò giao diện giữa tầng suy luận và tầng thực thi vật lý, cùng vai trò mà endpoint API đảm nhiệm trong phần mềm.

Kiến trúc LLM + công cụ + vòng lặp là đa dụng. Hiện nay nó dễ triển khai nhất trong phần mềm, nhưng robot đang bắt kịp.

API do AI viết, cho AI

Trong khoảng hai năm (2024 đến 2026), chúng ta đã đi từ việc phần lớn mã được con người viết sang phần lớn mã được AI viết. Đây là thời điểm tốt để xem xét lại endpoint API là gì. Ngày càng nhiều, một endpoint là một tuyên bố năng lực được thiết kế để máy móc khám phá và thực thi, không phải một giao diện kỹ thuật để lập trình viên con người đọc tài liệu rồi tích hợp thủ công.

MCP là một lớp chuẩn hóa hữu ích, nhưng chúng cũng là một lớp tuyển chọn gây ra thiên kiến. Người tạo MCP quyết định công cụ nào được expose và đóng khung chúng như thế nào. Với AI agent trong production, cách đóng khung đó có thể không khớp với điều bạn thực sự cần. (Chúng tôi đã viết chi tiết về điều này khi phân tích các thách thức với MCP của Shopify.)

Phổ mà chúng tôi đã đi qua trong Quickchat AI Agents phản ánh một điểm rộng hơn. Mức kiểm soát phù hợp phụ thuộc vào trường hợp sử dụng của bạn. Remote MCP phù hợp để tạo prototype nhanh. AI Actions riêng lẻ cho bạn quyền kiểm soát chi tiết đối với agent đối mặt khách hàng trong production. Generate from Text để AI nghiên cứu API và xây dựng định nghĩa công cụ cho bạn khi bạn vẫn đang khám phá.

Và ở mọi cấp độ, mẫu nền tảng vẫn giống nhau. Một LLM, một tập công cụ, một vòng lặp. Dù công cụ là lệnh bash, endpoint API, máy chủ MCP hay bộ truyền động robot, bên dưới vẫn luôn là các công cụ.