Gọi hàm truyền thống có một hình dạng mà mọi nhà phát triển agent đều quen thuộc: mô hình yêu cầu một công cụ, ứng dụng thực thi công cụ đó, bạn gửi kết quả lại, rồi mô hình yêu cầu lệnh gọi tiếp theo. Bốn công cụ nghĩa là bốn vòng đi; bốn mươi công cụ nghĩa là bốn mươi vòng đi. Mỗi lượt làm tăng độ trễ mạng và chi phí ngữ cảnh. Khi OpenAI đưa GPT-5.6 ra mắt rộng rãi vào ngày 9 tháng 7 năm 2026, họ đã giới thiệu một cách thoát khỏi vòng lặp này: gọi công cụ theo chương trình trong Responses API.
Ý tưởng rất trực tiếp: thay vì trả về từng lệnh gọi công cụ để ứng dụng của bạn chạy trong vòng lặp, mô hình tự viết JavaScript để điều phối nhiều lệnh gọi công cụ. Mã chạy trong V8 runtime biệt lập, không có quyền truy cập mạng. Công cụ của bạn vẫn là con đường duy nhất để mã chạm đến hệ thống bên ngoài, nên ranh giới bảo mật bạn đã thiết kế với lệnh gọi hàm của OpenAI vẫn giữ nguyên.
Điểm thay đổi là nơi điều phối chạy: vòng lặp, điều kiện và logic tổng hợp trước đây nằm trong ứng dụng của bạn giờ có thể do mô hình tạo ra.
Điều này cũng thay đổi cách bạn thiết kế API công cụ. Một công cụ có thể được mô hình gọi hàng chục lần trong cùng một đợt điều phối, thay vì chỉ một lần cẩn thận mỗi lượt. Schema, định dạng lỗi, giới hạn tốc độ và độ trễ giờ quan trọng hơn. Bài viết này giải thích cơ chế mới, những gì không thay đổi, và cách chuẩn bị endpoint công cụ bằng Apidog trước khi giao chúng cho mô hình.
TL;DR
- GPT-5.6 ra mắt rộng rãi vào ngày 9 tháng 7 năm 2026. Responses API bổ sung gọi công cụ theo chương trình.
- Thay vì một lệnh gọi công cụ mỗi vòng đi, mô hình viết JavaScript để thực hiện vòng lặp, điều kiện và tổng hợp trên các công cụ của bạn.
- JavaScript được tạo chạy trong sandbox V8 biệt lập và không có truy cập mạng.
- Các định nghĩa công cụ vẫn là ranh giới bảo mật duy nhất dẫn ra hệ thống bên ngoài.
- Độ trễ và chi phí token không còn tăng tuyến tính theo số vòng đi mô hình như trong vòng lặp agent truyền thống.
- Hãy kiểm tra schema, lỗi, tải và tính bất biến của từng endpoint trước khi bật điều phối theo chương trình.
Những gì ra mắt vào ngày 9 tháng 7
GPT-5.6 ra mắt dưới dạng gia đình ba cấp:
-
gpt-5.6-solcho suy luận sâu nhất -
gpt-5.6-terracho tác vụ cân bằng -
gpt-5.6-lunacho khối lượng công việc nhanh và tối ưu chi phí
Biệt danh gpt-5.6 chuyển hướng đến Sol. Cả ba đều tự phục vụ qua API sau khi giai đoạn xem trước giới hạn kết thúc.
Theo tin tức ra mắt của MarkTechPost và tài liệu OpenAI, Responses API có bốn bổ sung tại thời điểm ra mắt:
- Gọi công cụ theo chương trình
- Đa tác nhân ở bản beta
- Suy luận được duy trì qua các lượt
- Cài đặt chi tiết thị giác bảo toàn kích thước ảnh gốc
Gọi công cụ theo chương trình là phần quan trọng nhất nếu bạn đang xây agent. OpenAI mô tả cơ chế này là mô hình viết JavaScript để điều phối lệnh gọi công cụ, sau đó thực thi mã trong V8 runtime biệt lập không có mạng.
Vòng lặp truyền thống mà tính năng này thay thế
Đây là hình dạng gọi hàm truyền thống với Responses API:
import OpenAI from "openai";
const client = new OpenAI();
const tools = [
{
type: "function",
name: "get_flight_status",
description: "Return live status for a flight by IATA flight number.",
parameters: {
type: "object",
properties: {
flight_number: {
type: "string",
description: "IATA flight number, for example SQ317"
}
},
required: ["flight_number"]
}
}
];
let response = await client.responses.create({
model: "gpt-5.6",
input: "Which of these 12 flights are delayed: SQ317, BA15, UA857...",
tools
});
Mô hình cần dữ liệu chuyến bay nên sẽ trả về một lệnh gọi hàm. Ứng dụng của bạn phải chạy lệnh gọi, đóng gói kết quả thành function_call_output, rồi gửi yêu cầu tiếp theo:
// Một vòng đi cho mỗi lệnh gọi công cụ.
while (hasFunctionCalls(response)) {
const outputs = await executeToolCalls(response);
response = await client.responses.create({
model: "gpt-5.6",
previous_response_id: response.id,
input: outputs,
tools
});
}
Với 12 chuyến bay, vòng lặp có thể chạy 12 lần. Chi phí xuất hiện ở hai nơi:
- Độ trễ: mỗi lượt yêu cầu một vòng đi mạng đến OpenAI, thời gian suy luận của mô hình và thời gian gọi công cụ.
- Token: kết quả công cụ tiếp tục tích lũy trong context, khiến các lượt sau phải xử lý lại nội dung từ các lượt trước.
Nếu bạn ghép nhiều agent với nhau, chi phí tăng nhanh. Ví dụ, agent gồm năm bước, mỗi bước cần mười lệnh gọi công cụ, có thể tạo ra 50 lần gọi mô hình.
Chế độ theo chương trình thay đổi luồng xử lý như thế nào
Với gọi công cụ theo chương trình, mô hình có thể tạo một chương trình JavaScript ngắn để:
- Lặp qua danh sách 12 chuyến bay.
- Gọi
get_flight_statuscho từng chuyến. - Lọc các chuyến bị trễ.
- Sắp xếp theo thời gian trễ.
- Trả về kết quả tổng hợp.
Công cụ của bạn vẫn thực hiện truy vấn dữ liệu thực. Nhưng luồng điều khiển quanh các công cụ—vòng lặp, điều kiện, thoát sớm và tổng hợp—được mô hình tạo ra.
Ba đặc tính chính giúp cơ chế này an toàn và hữu ích:
- Runtime biệt lập: JavaScript chạy trong sandbox V8 không có truy cập mạng. Mã không thể tự gọi URL, mở socket hoặc truy xuất hệ thống bên ngoài.
-
Công cụ là lối thoát duy nhất: mọi hiệu ứng bên ngoài phải đi qua công cụ bạn đã khai báo. Nếu không khai báo
delete_record, mã được tạo không thể xóa bản ghi. - Luồng điều khiển biểu đạt hơn: vòng lặp, điều kiện, lọc và tổng hợp có thể diễn ra trong một chu kỳ phản hồi thay vì N vòng đi tuần tự.
| Lệnh gọi hàm truyền thống | Gọi công cụ theo chương trình | |
|---|---|---|
| Ai viết luồng điều khiển | Ứng dụng của bạn | Mô hình, dưới dạng JavaScript |
| Vòng đi cho N lệnh gọi công cụ | N, tuần tự | Một chu kỳ phản hồi |
| Nơi điều phối chạy | Hạ tầng của bạn | Sandbox V8 biệt lập, không mạng |
| Cách công cụ thực thi | Mã của bạn gọi chúng | Qua bề mặt công cụ đã khai báo |
| Ranh giới bảo mật | Định nghĩa công cụ | Định nghĩa công cụ, không thay đổi |
Những gì vẫn giữ nguyên
Bạn vẫn định nghĩa công cụ bằng tên, mô tả và JSON Schema:
{
type: "function",
name: "get_flight_status",
description: "Return live status for a flight by IATA flight number.",
parameters: {
type: "object",
properties: {
flight_number: {
type: "string",
description: "IATA flight number, for example SQ317"
}
},
required: ["flight_number"]
}
}
Mô hình chỉ có thể gọi các công cụ bạn đã khai báo. Vì vậy, câu hỏi bảo mật vẫn là:
Agent này có thể làm gì với hệ thống của tôi?
Câu trả lời: chỉ những gì bề mặt công cụ của bạn cho phép.
Chất lượng schema còn quan trọng hơn trước. Trong vòng lặp cổ điển, một mô tả mơ hồ có thể chỉ tạo ra một lệnh gọi lỗi để bạn bắt và sửa. Trong chế độ theo chương trình, sự mơ hồ đó có thể bị đưa vào một vòng lặp và lặp lại trên toàn bộ tập đầu vào.
Áp dụng các nguyên tắc tương tự như khi thiết kế đầu ra có cấu trúc:
- Dùng kiểu dữ liệu chặt chẽ.
- Dùng
enumcho tập giá trị đóng. - Ghi rõ đơn vị, định dạng và phạm vi.
- Chỉ đánh dấu
requiredcho trường thực sự bắt buộc. - Tránh mô tả như “ngày hợp lệ” hoặc “trạng thái hiện tại” mà không nêu định dạng và giá trị cho phép.
Ví dụ schema tốt hơn:
parameters: {
type: "object",
properties: {
date: {
type: "string",
description: "Ngày theo định dạng ISO 8601: YYYY-MM-DD."
},
status: {
type: "string",
enum: ["scheduled", "delayed", "cancelled"],
description: "Trạng thái chuyến bay."
}
},
required: ["date"]
}
Giới hạn và câu hỏi mở
Khả năng này mới ra mắt, vì vậy không nên xây lại toàn bộ agent stack ngay lập tức.
Trước khi triển khai, hãy lưu ý:
- Tham số yêu cầu, giới hạn thực thi và hành vi timeout cần được xác minh trong tài liệu tham khảo API và hướng dẫn mô hình của OpenAI.
- Gỡ lỗi là một bề mặt mới. Trước đây, logic điều phối nằm trong repository của bạn và có thể đặt breakpoint. Giờ một phần luồng điều khiển được tạo mới cho mỗi yêu cầu.
- Ghi log chuỗi lệnh gọi công cụ, tham số, thời lượng và kết quả của từng lệnh gọi trở thành yêu cầu quan sát cốt lõi.
- Chưa có lịch sử vận hành sản xuất dài hạn. Ghi chú ngày đầu tiên của Simon Willison về GPT-5.6 là nguồn tham khảo hữu ích cho các kiểm tra độc lập ban đầu.
Một lộ trình triển khai an toàn:
- Bắt đầu với công cụ chỉ đọc.
- Ghi log toàn bộ điều phối được tạo.
- So sánh độ trễ và mức dùng token với vòng lặp cũ.
- Kiểm tra tải endpoint khi nhiều lệnh gọi đến theo đợt.
- Chỉ sau đó mới công khai công cụ có tác dụng phụ.
Các công cụ của bạn giờ là API cho mã do máy tạo gọi
Trong gọi hàm truyền thống, công cụ thường được gọi một lần mỗi vòng đi và ứng dụng của bạn kiểm soát tốc độ, thứ tự. Với gọi công cụ theo chương trình, mã được tạo có thể gọi công cụ theo đợt, phân nhánh theo phản hồi và tổng hợp đầu ra.
Mỗi công cụ trở thành hợp đồng API được tiêu thụ bởi một client do máy viết.
Điều đó nâng tiêu chuẩn ở bốn điểm.
1. Độ chính xác của schema
Nêu rõ đơn vị, định dạng và phạm vi trong mọi tham số. Một trường ngày tháng mơ hồ không chỉ gây ra một request lỗi; nó có thể gây ra cả một chuỗi request lỗi.
2. Hình dạng lỗi
Mã được tạo sẽ phân nhánh theo lỗi. Không nên trả HTTP 200 với thông báo lỗi chôn trong chuỗi văn bản.
Thay vào đó, trả mã trạng thái phù hợp và body lỗi có cấu trúc:
{
"error": {
"code": "FLIGHT_NOT_FOUND",
"message": "Không tìm thấy chuyến bay với mã SQ999."
}
}
Ví dụ HTTP phù hợp:
HTTP/1.1 404 Not Found
Content-Type: application/json
3. Tính bất biến và giới hạn tốc độ
Mười hai lệnh gọi trước đây đến trong một phút giờ có thể đến gần như cùng lúc. Bạn cần biết endpoint phản ứng thế nào khi gặp:
- Request trùng lặp
- Retry sau timeout
- Lưu lượng theo đợt
- Thứ tự gọi không xác định
- Nhiều request cùng cập nhật một tài nguyên
Nếu công cụ có tác dụng phụ, hãy cân nhắc idempotency key:
Idempotency-Key: 2a7cddcb-b9c5-4c90-93ab-519e5c744d1a
4. Độ trễ
Một công cụ mất tám giây có thể chấp nhận được khi gọi đơn lẻ. Nhưng nếu nó nằm trong vòng lặp mười hai lần lặp, nó có thể quyết định toàn bộ thời gian phản hồi của agent.
Cách kiểm tra endpoint công cụ trước khi bật agent
Trước khi giao endpoint cho mô hình, hãy kiểm tra hợp đồng API theo quy trình rõ ràng:
- Định nghĩa hoặc nhập OpenAPI spec cho từng công cụ.
- Gửi request hợp lệ và xác nhận response khớp schema.
- Gửi request thiếu trường bắt buộc, sai kiểu dữ liệu và giá trị ngoài phạm vi.
- Xác nhận mã HTTP và body lỗi nhất quán.
- Chạy thử nhiều request liên tiếp hoặc song song.
- Dùng mock server để kiểm tra điều phối với dữ liệu dự đoán được mà không chạm production.
Bạn có thể dùng Apidog và mock server tích hợp để phục vụ phản hồi theo schema cho các endpoint đã định nghĩa. Điều này cho phép bạn cung cấp cho mô hình một bề mặt công cụ hoàn chỉnh, quan sát cách nó điều phối và phát hiện schema mơ hồ trước khi truy cập bản ghi thật.
Tóm tắt các tính năng GA khác
Gọi công cụ theo chương trình không ra mắt một mình. Hai bổ sung liền kề trong Responses API cũng đáng chú ý:
- Đa tác nhân, bản beta: thực thi agent phụ song song do API quản lý. Đây là tính năng nên theo dõi trước khi đặt cược lớn vào production.
-
Suy luận được duy trì: context suy luận được tái sử dụng qua các lượt thông qua
reasoning.context, giúp các phiên agent dài không phải suy luận lại cùng kết luận ở mỗi lượt.
Hai tính năng này kết hợp tự nhiên với gọi công cụ theo chương trình: agent có thể giữ context suy luận và tự điều phối công cụ, từ đó giảm công việc dư thừa trên mỗi tác vụ.
Gọi công cụ theo chương trình so với chế độ Ultra
Việc ra mắt cũng mang đến chế độ Ultra. Hai tính năng dễ bị nhầm lẫn vì đều giúp làm nhiều việc hơn trong mỗi yêu cầu, nhưng chúng xử lý các điểm nghẽn khác nhau.
Ultra là cài đặt đa tác nhân chạy bốn agent song song theo mặc định, chủ động dùng nhiều token hơn để giảm thời gian thực tế. Theo OpenAI, nó nâng Terminal-Bench 2.1 từ 88,8% lên 91,9%. Ultra có trong ChatGPT Work trên gói Pro và Enterprise, cũng như Codex từ gói Plus trở lên.
Gọi công cụ theo chương trình là khả năng API để một agent điều phối công cụ bằng mã.
- Ultra song song hóa suy nghĩ.
- Gọi công cụ theo chương trình rút gọn các vòng đi thực thi.
Phân tích đầy đủ có trong bài viết chế độ Ultra của GPT-5.6.
Quy tắc chọn nhanh:
- Nếu nút thắt là độ trễ gọi công cụ: dùng gọi công cụ theo chương trình.
- Nếu nút thắt là thời gian suy nghĩ cho bài toán khó: cân nhắc Ultra.
FAQ
Tôi có cần viết lại các định nghĩa công cụ hiện có không?
Không. Công cụ vẫn dùng JSON Schema như trước và các định nghĩa cho gọi hàm truyền thống vẫn có thể dùng lại.
Tuy nhiên, bạn nên siết chặt chúng:
- Thêm
enumkhi tập giá trị là hữu hạn. - Chuẩn hóa định dạng trạng thái.
- Nêu rõ đơn vị và định dạng.
- Viết mô tả đủ cụ thể để mã được tạo không thể hiểu sai.
JavaScript được tạo có thể truy cập internet không?
Không. Mã chạy trong V8 runtime biệt lập không có truy cập mạng. Các công cụ đã khai báo là cách duy nhất để nó tác động ra bên ngoài sandbox.
Vì vậy, hãy xem bề mặt công cụ như một API công khai: kiểm tra quyền, xác thực đầu vào, lỗi, rate limit và hành vi retry.
Những mô hình GPT-5.6 nào hỗ trợ gọi công cụ theo chương trình?
OpenAI tài liệu hóa đây là bề mặt Responses API cho gia đình GPT-5.6. Ba cấp gpt-5.6-sol, gpt-5.6-terra và gpt-5.6-luna đều tự phục vụ cho tài khoản API.
Hãy kiểm tra tài liệu API để xác nhận chi tiết hỗ trợ theo model trước khi triển khai. Để thiết lập khóa và gửi yêu cầu đầu tiên, xem hướng dẫn cách sử dụng API GPT-5.6.
Điều này khác code interpreter như thế nào?
Code interpreter chạy mã để tạo đầu ra cuối cùng, chẳng hạn phân tích dữ liệu, vẽ biểu đồ hoặc chuyển đổi tệp.
Gọi công cụ theo chương trình tạo mã với mục đích điều phối công cụ bạn đã khai báo. Đầu ra cuối cùng là dữ liệu công cụ được tổng hợp, không phải bản thân đoạn mã.
Điều này đặt bạn vào vị trí nào
Vòng lặp request-response là phần ít thú vị nhất của hầu hết agent production. GPT-5.6 biến phần đó thành tùy chọn.
Điều phối chuyển nhiều hơn sang mô hình. Đổi lại, trách nhiệm của bạn với API công cụ—schema rõ ràng, lỗi chuẩn, hiệu năng ổn định, quyền hạn chặt chẽ—trở nên lớn hơn.
Bước tiếp theo nên rất cụ thể:
- Chọn một workflow chủ yếu dùng công cụ chỉ đọc.
- Viết hoặc siết chặt schema cho từng công cụ.
- Kiểm tra request hợp lệ, input xấu và response lỗi.
- Giả lập endpoint bằng client API và mock server của Apidog.
- Quan sát điều phối được tạo trước khi cho phép agent truy cập dữ liệu hoặc thao tác thật.
Khi mô hình bắt đầu viết mã dựa trên công cụ của bạn, hãy đảm bảo nó đang làm việc với một bề mặt API mà bạn đã kiểm thử.
Top comments (0)