OpenAI AgentKit là gì

OpenAI AgentKit là bộ công cụ để xây dựng, triển khai và đo lường AI agents trên nền tảng OpenAI. Nếu bạn từng phải tự viết orchestration code, tự nối connectors, tự dựng eval scripts và tự kiểm thử từng API mà agent gọi, AgentKit là nỗ lực của OpenAI nhằm gom các phần đó vào một quy trình thống nhất. Tuy nhiên, có một điểm quan trọng trong năm 2026: Agent Builder và Evals đang bị ngừng hoạt động, vì vậy nếu bạn muốn xây dựng lâu dài, hãy ưu tiên hướng code-first với Agents SDK. Bài viết này đi thẳng vào các thành phần của AgentKit, cách triển khai thực tế và vị trí của công cụ kiểm thử API như Apidog trong pipeline agent.

Dùng thử Apidog ngay hôm nay

AgentKit là gì

OpenAI giới thiệu AgentKit tại DevDay ngày 6 tháng 10 năm 2025. Đây không phải là một sản phẩm đơn lẻ, mà là một tập hợp thành phần nằm trên OpenAI API và OpenAI Agents SDK, giúp rút ngắn khoảng cách từ “có ý tưởng về agent” đến “có agent chạy được trước người dùng”.

Trước AgentKit, một agent thường cần nhiều phần rời rạc:

• Logic điều phối không có versioning rõ ràng
• Connector tùy chỉnh cho từng nguồn dữ liệu
• Pipeline đánh giá tự viết
• Prompt tuning thủ công
• Giao diện frontend riêng trước khi có thể demo hoặc triển khai

AgentKit gom các phần này thành một hệ thống gồm Agent Builder, ChatKit, Connector Registry, Evals và Agents SDK.

Điểm cần lưu ý: ngày 3 tháng 6 năm 2026, OpenAI thông báo ngừng phát triển hai phần của AgentKit là Agent Builder và Evals. Vì vậy, nếu bạn đang bắt đầu một dự án mới, hãy xem Agent Builder như công cụ tạo mẫu, còn hướng triển khai bền vững là Agents SDK.

Các thành phần chính của AgentKit

1. Agent Builder

Agent Builder là giao diện trực quan để thiết kế workflow nhiều bước cho agent. Bạn có thể:

• Kéo thả các node
• Kết nối node thành flow
• Chạy thử với input thực tế
• Xuất bản version workflow
• Dùng template để bắt đầu nhanh

Điểm hữu ích cho developer là Agent Builder không khóa bạn trong giao diện no-code. Nó có tab Agents SDK để xuất workflow thành mã Python hoặc TypeScript có thể chạy được. Điều này cho phép bạn prototype bằng UI, sau đó chuyển sang code để mở rộng.

Tuy nhiên, theo trang deprecations của OpenAI, Agent Builder đang bị ngừng phát triển và sẽ ngừng hoạt động vào ngày 30 tháng 11 năm 2026.

Cách dùng hợp lý trong năm 2026:

1. Dùng Agent Builder để phác thảo flow nhanh.
2. Xuất sang Agents SDK.
3. Đưa code vào repo của bạn.
4. Tiếp tục phát triển bằng Python hoặc TypeScript.

2. ChatKit

ChatKit là giao diện chat có thể nhúng để đưa agent đến người dùng. Thay vì tự xây UI chat, bạn có thể dùng component có sẵn, trỏ nó đến workflow đã publish và tùy chỉnh giao diện.

ChatKit xử lý các phần thường gặp như:

• Streaming response
• Luồng hội thoại
• UI chat cơ bản
• Kết nối với workflow agent

ChatKit vẫn khả dụng và là cách được khuyến nghị nếu bạn cần triển khai trải nghiệm agent dạng chat.

3. Connector Registry

Connector Registry là nơi quản trị viên quản lý dữ liệu và công cụ mà agent có thể truy cập trên các sản phẩm OpenAI, gồm ChatGPT và API.

Nó hỗ trợ:

• Connector dựng sẵn như Dropbox, Google Drive, SharePoint, Microsoft Teams
• MCP server của bên thứ ba
• Kiểm soát quyền truy cập tập trung
• Quản trị công cụ mà agent được phép gọi

Nếu bạn muốn hiểu phần MCP, bài viết về máy chủ MCP và OpenAI Agents SDK giải thích cách agent gọi tool thông qua Model Context Protocol.

4. Evals và tối ưu hóa

Evals cung cấp các tính năng để đo chất lượng agent:

• Dataset đánh giá
• Chấm điểm trace
• Chấm điểm từng bước trong workflow đa agent
• Tối ưu prompt tự động
• Hỗ trợ model chấm điểm từ bên thứ ba, không chỉ OpenAI

Tuy nhiên, Evals cũng đang bị ngừng hoạt động:

• Chuyển sang chế độ chỉ đọc vào ngày 31 tháng 10 năm 2026
• Ngừng hoạt động hoàn toàn vào ngày 30 tháng 11 năm 2026

Nếu bạn đang xây hệ thống lâu dài, hãy chuẩn bị phương án đánh giá riêng hoặc dùng các công cụ khác thay vì phụ thuộc vào Evals.

AgentKit liên quan thế nào đến Agents SDK

Agents SDK là lớp code-first. Đây là nơi bạn định nghĩa:

• Agent
• Tool
• Handoff
• Guardrail
• Logic chạy thực tế

Agent Builder nằm trên Agents SDK như một lớp trực quan để tạo workflow và xuất code. ChatKit nằm bên cạnh như lớp giao diện triển khai cho người dùng cuối.

Lớp	Nó là gì	Tình trạng năm 2026
Agents SDK	Framework code-first để định nghĩa agent, tool và guardrail	Đang hoạt động, hướng lâu dài được khuyến nghị
Agent Builder	Giao diện trực quan xuất mã Agents SDK	Ngừng phát triển, ngừng hoạt động ngày 30 tháng 11 năm 2026
ChatKit	Giao diện chat có thể nhúng, liên kết với workflow ID	Khả dụng
Connector Registry	Bảng điều khiển quản trị connector và MCP server	Khả dụng
Evals	Chấm điểm trace và tối ưu prompt	Chỉ đọc ngày 31 tháng 10 năm 2026, ngừng hoạt động ngày 30 tháng 11 năm 2026

Hướng dẫn di chuyển của OpenAI khá rõ:

• Workflow cần tồn tại dưới dạng code: chuyển sang Agents SDK.
• Trường hợp sử dụng ngôn ngữ tự nhiên không cần code: dùng Workspace Agents trong ChatGPT.
• Nhóm kỹ thuật xây sản phẩm lâu dài: bắt đầu với Agents SDK.

AgentKit dành cho ai

AgentKit phù hợp với nhiều nhóm khác nhau, nhưng cách tiếp cận nên thay đổi theo mục tiêu triển khai.

Nếu bạn là product team cần prototype nhanh:

• Dùng Agent Builder để mô hình hóa flow.
• Dùng ChatKit để demo giao diện chat.
• Xuất code nếu workflow cần được duy trì.

Nếu bạn là enterprise team cần kiểm soát dữ liệu:

• Dùng Connector Registry để quản lý nguồn dữ liệu và tool.
• Kiểm soát quyền truy cập trước khi agent gọi dữ liệu nội bộ.

Nếu bạn là engineering team:

• Bắt đầu trực tiếp với Agents SDK.
• Định nghĩa tool bằng code.
• Kiểm thử API mà tool gọi.
• Dựng pipeline đánh giá riêng thay vì phụ thuộc vào Evals.

Quy trình xây dựng agent thực tế

Dù bắt đầu bằng UI hay bằng code, quy trình triển khai agent thường gồm các bước sau.

Bước 1: Xác định nhiệm vụ của agent

Trước khi viết code, hãy trả lời rõ:

• Agent cần giải quyết tác vụ gì?
• Người dùng sẽ nhập gì?
• Agent cần gọi những API nào?
• Agent có cần truy cập dữ liệu nội bộ không?
• Kết quả cuối cùng phải có format nào?

Ví dụ: agent hỗ trợ khách hàng có thể cần:

• Tra cứu đơn hàng
• Kiểm tra trạng thái giao hàng
• Tạo ticket hỗ trợ
• Đọc chính sách đổi trả

Mỗi hành động này thường tương ứng với một API hoặc tool.

Bước 2: Thiết kế workflow

Nếu dùng Agent Builder, bạn kéo thả node để tạo flow.

Nếu dùng Agents SDK, bạn định nghĩa agent, tool và handoff bằng code. Ví dụ ở mức khái niệm:

const supportAgent = new Agent({
  name: "Customer Support Agent",
  instructions: "Hỗ trợ khách hàng tra cứu đơn hàng và trạng thái giao hàng.",
  tools: [getRecentOrders, getShippingStatus]
});

Mục tiêu ở bước này là xác định rõ agent có thể làm gì và khi nào nó nên gọi tool.

Bước 3: Thêm guardrails

Guardrails giúp giảm rủi ro khi agent xử lý input hoặc output. Bạn có thể dùng guardrail để:

• Che hoặc gắn cờ PII
• Phát hiện jailbreak attempt
• Kiểm tra output trước khi trả về người dùng
• Ngăn agent gọi tool không phù hợp

Với các workflow có dữ liệu nhạy cảm, guardrail nên được thêm trước khi agent gọi API nội bộ.

Bước 4: Kết nối dữ liệu và tool

Tool là phần agent dùng để hành động ngoài mô hình. Trong thực tế, tool thường là wrapper quanh HTTP API.

Ví dụ:

• get_recent_orders gọi Orders API
• create_support_ticket gọi Ticketing API
• search_docs gọi Search API
• check_inventory gọi Inventory API

Bạn có thể kết nối qua Connector Registry, MCP server hoặc function tool trong Agents SDK.

Bước 5: Kiểm thử từng tool độc lập

Đây là bước dễ bị bỏ qua nhưng rất quan trọng. Trước khi để agent gọi API, hãy kiểm tra:

• API có trả đúng status code không?
• Response có đúng schema không?
• Field có đúng tên và kiểu dữ liệu không?
• API xử lý lỗi thế nào?
• Timeout và rate limit ra sao?
• Có dữ liệu giả lập cho môi trường dev/staging không?

Nếu tool trả dữ liệu sai, agent sẽ suy luận trên dữ liệu sai.

Bước 6: Triển khai

Có hai hướng phổ biến:

• Dùng ChatKit để nhúng giao diện chat.
• Chạy Agents SDK trong hạ tầng riêng của bạn.

Nếu cần kiểm soát logging, secret, observability và deployment pipeline, hướng Agents SDK trong hạ tầng riêng thường phù hợp hơn cho team kỹ thuật.

Ví dụ thực tế: tool mà agent gọi

Một agent chỉ đáng tin cậy nếu các tool của nó đáng tin cậy. Trong phần lớn trường hợp, tool là HTTP API.

Khi đăng ký function tool với Agents SDK, bạn mô tả tool bằng JSON schema để model biết khi nào và cách gọi.

Ví dụ tool tra cứu đơn hàng gần đây:

{
  "type": "function",
  "name": "get_recent_orders",
  "description": "Look up a customer's recent orders by customer ID.",
  "parameters": {
    "type": "object",
    "properties": {
      "customer_id": {
        "type": "string",
        "description": "The customer's unique identifier"
      },
      "limit": {
        "type": "integer",
        "description": "How many orders to return",
        "default": 5
      }
    },
    "required": ["customer_id"],
    "additionalProperties": false
  }
}

Khi model quyết định gọi get_recent_orders, code của bạn nhận arguments, gọi API thật và trả kết quả về cho agent.

Ví dụ request:

curl https://api.your-company.com/v1/customers/cus_8842/orders?limit=5 \
  -H "Authorization: Bearer $ORDERS_API_KEY" \
  -H "Content-Type: application/json"

Vấn đề là hành vi của agent phụ thuộc trực tiếp vào response từ API này.

Nếu API:

• Chậm
• Trả sai schema
• Thiếu field
• Trả lỗi không nhất quán
• Dùng dữ liệu khác giữa dev và production

thì agent có thể đưa ra kết luận sai hoặc trả lời không ổn định.

Vị trí của kiểm thử API và mocking

Apidog không phải framework để xây agent. AgentKit và Agents SDK làm việc đó. Vai trò của Apidog nằm ở lớp thấp hơn: kiểm thử, mock và ghi tài liệu cho các API mà agent gọi.

1. Mock API trước khi backend sẵn sàng

Nếu agent cần gọi Orders API nhưng backend chưa hoàn thành, bạn có thể thiết lập mock API để trả về response theo schema đã thống nhất.

Cách làm thực tế:

1. Định nghĩa endpoint, ví dụ GET /v1/customers/{customer_id}/orders.
2. Khai báo response schema.
3. Tạo dữ liệu mẫu cho các case phổ biến:
   • Có đơn hàng
   • Không có đơn hàng
   • Customer không tồn tại
   • API lỗi
   • Response chậm
4. Trỏ tool của agent đến mock endpoint trong môi trường dev.
5. Chạy agent với input thực tế để xem nó xử lý từng case thế nào.

Lợi ích là frontend, agent logic và prompt có thể phát triển song song với backend.

2. Xác thực contract của từng tool

Một API trả 200 OK nhưng sai tên field có thể gây lỗi khó phát hiện hơn một API trả 500.

Ví dụ agent mong đợi:

{
  "orders": [
    {
      "id": "ord_123",
      "status": "shipped",
      "total": 42.5
    }
  ]
}

Nhưng API thực tế trả:

{
  "data": [
    {
      "order_id": "ord_123",
      "state": "shipped",
      "amount": 42.5
    }
  ]
}

Model có thể vẫn cố suy luận, nhưng kết quả sẽ không ổn định. Vì vậy, bạn nên viết test case API để kiểm tra:

• Status code
• Response schema
• Required fields
• Kiểu dữ liệu
• Giá trị biên
• Error response

3. Quản lý environment và secret

Tool của agent thường cần secret như:

$ORDERS_API_KEY
$CRM_API_KEY
$SEARCH_API_KEY

Không nên hard-code các key này vào source code hoặc prompt. Hãy tách theo environment:

• dev
• staging
• production

Với một nền tảng API, bạn có thể quản lý base URL, header, token và biến môi trường cho từng môi trường. Bạn có thể tải xuống Apidog và đưa các endpoint tool vào một project riêng để kiểm thử độc lập với runtime của agent.

4. Kiểm thử agent tool như API thông thường

Một nguyên tắc đơn giản: mọi tool mà agent gọi đều nên được kiểm thử như API.

Checklist tối thiểu:

• [ ] Endpoint có tài liệu rõ ràng
• [ ] Request schema khớp với tool schema
• [ ] Response schema ổn định
• [ ] Có mock response cho dev
• [ ] Có test case cho success và error
• [ ] Có timeout hợp lý
• [ ] Có logging cho request và response
• [ ] Secret được quản lý bằng environment variable

Nếu muốn đi sâu hơn, bài viết về cách kiểm thử các lệnh gọi công cụ của tác nhân AI trình bày cách coi tool call của agent như một test harness có thể kiểm soát.

FAQ

OpenAI AgentKit có miễn phí không?

Các công cụ của AgentKit chạy trên usage OpenAI API của bạn. Bạn vẫn trả tiền cho token model và các lệnh gọi tool mà agent tạo ra. Không có phí đăng ký AgentKit riêng biệt được nêu trong nội dung gốc; chi phí chính là usage model và API. Luôn kiểm tra trang giá hiện tại của OpenAI vì giá model có thể thay đổi.

Khác biệt giữa AgentKit và Agents SDK là gì?

Agents SDK là framework code-first để định nghĩa agent, tool, handoff và guardrail. AgentKit là bộ sản phẩm rộng hơn gồm Agent Builder, ChatKit, Connector Registry và Evals nằm quanh SDK đó.

Vì Agent Builder và Evals bị ngừng hoạt động cuối năm 2026, Agents SDK là hướng bền vững cho team kỹ thuật. Bạn có thể đọc thêm trong hướng dẫn về Agents SDK.

Agent Builder có bị loại bỏ không?

Có. OpenAI thông báo ngày 3 tháng 6 năm 2026 rằng họ sẽ ngừng phát triển Agent Builder và nền tảng Evals. Cả hai sẽ ngừng hoạt động vào ngày 30 tháng 11 năm 2026. Evals chuyển sang chế độ chỉ đọc vào ngày 31 tháng 10 năm 2026.

ChatKit vẫn khả dụng. OpenAI khuyến nghị chuyển workflow ưu tiên code sang Agents SDK và workflow ngôn ngữ tự nhiên sang Workspace Agents trong ChatGPT.

Tôi có nên dùng Agent Builder cho dự án mới không?

Chỉ nên dùng nếu bạn cần prototype nhanh và có kế hoạch xuất sang Agents SDK. Không nên phụ thuộc lâu dài vào Agent Builder cho production workflow vì nền tảng này đã có lịch ngừng hoạt động.

Tôi có thể kiểm thử các API mà AgentKit agent gọi không?

Có, và bạn nên làm vậy. Mỗi tool mà agent gọi thường là một HTTP API với request, response, auth và error behavior riêng. Bạn có thể mock API khi backend chưa sẵn sàng, kiểm tra response có khớp schema không và quản lý secret theo environment.

Kết luận

AgentKit giúp developer xây agent nhanh hơn bằng cách cung cấp Agent Builder, ChatKit, Connector Registry và Evals trên nền OpenAI Agents SDK. Nhưng từ cuối năm 2026, Agent Builder và Evals sẽ bị ngừng hoạt động, nên hướng bền vững cho các nhóm kỹ thuật là Agents SDK, kết hợp ChatKit và Connector Registry khi cần.

Dù bạn triển khai theo hướng nào, độ tin cậy của agent vẫn phụ thuộc vào các API mà nó gọi. Hãy mock API sớm, kiểm thử response schema, quản lý environment rõ ràng và xác thực từng tool trước khi đưa vào production. Apidog cung cấp một nơi để kiểm thử, mock và quản lý tài liệu cho các endpoint mà agent của bạn phụ thuộc vào.