OpenAI vừa ship một loạt tính năng quan trọng cho Responses API, và với những ai đang xây dựng hệ thống AI production, đây thay đổi đáng kể cách chúng ta thiết kế hệ thống “agentic” thực tế.
Suốt năm vừa qua, team tôi phải tự ghép nối agent loop thủ công — quản lý state, xử lý retry, theo dõi tool call sequence. Những tính năng mới này cảm giác như OpenAI cuối cùng cũng nhận ra những gì team production thực sự cần.
Hãy cùng đi qua từng tính năng mới và ý nghĩa thực tế của chúng.
Những Gì Mới Trong Responses API
1. Shell Tool
Responses API giờ có built-in shell tool. Thay vì tự wrap bash execution, model có thể trực tiếp gọi shell commands trong reasoning loop.
Điều này mạnh hơn bạn nghĩ. Trước đây, nếu muốn model đọc file, chạy linter, rồi fix code, bạn phải tự orchestrate tất cả. Giờ model có thể làm:
đọc file → chạy mypy → parse lỗi → fix → chạy lại mypy → xác nhậnTất cả trong một agentic loop duy nhất, không cần orchestration code tùy chỉnh.
Rủi ro hiển nhiên? Shell access không giới hạn từ LLM là ác mộng bảo mật. Câu trả lời của OpenAI là hosted container workspace (chi tiết bên dưới). Shell tool được thiết kế để chạy trong môi trường sandbox, không phải trên server production của bạn.
2. Built-in Agent Execution Loop
Trước đây, xây agent với tool use nghĩa là viết loop riêng:
while True:
response = client.chat.completions.create(...)
if response.choices[0].finish_reason == "tool_calls":
# thực thi tools
# append kết quả
# loop lại
else:
breakCách này hoạt động, nhưng mỗi team viết một version hơi khác nhau, với bug hơi khác nhau. Responses API giờ có loop này built-in — bạn khai báo tools, đặt exit condition, và API xử lý vòng lặp.
from openai import OpenAI
client = OpenAI()
response = client.responses.create(
model="gpt-4.1",
input="Phân tích test failures trong repo này và đề xuất cách fix",
tools=[
{"type": "shell"},
{"type": "file_search", "file_search": {"vector_store_ids": ["vs_abc123"]}}
],
max_iterations=10 # giới hạn an toàn
)
print(response.output_text)API chạy model, thực thi tool calls, đưa kết quả về, và chỉ return khi model tạo ra final text response (hoặc đạt giới hạn iterations). Đây là abstraction đúng cho 90% use case agentic.
3. Hosted Container Workspace
Đây là bổ sung quan trọng nhất. OpenAI giờ provision ephemeral container workspace cho mỗi session — môi trường Linux sandbox với internet access tắt, file system, và khả năng cài packages.
Điều này cho phép:
- Thực thi code an toàn: Shell tool chạy trong container, không phải infrastructure của bạn
- Stateful file operations: Files được ghi trong một tool call sẽ tồn tại cho các tool call tiếp theo trong cùng session
- Cài packages: Model có thể
pip installdependencies cần thiết
Trong thực tế, điều này có nghĩa bạn có thể gửi Python files hoặc requirements.txt, để model setup môi trường, chạy tests, fix failures, và trả kết quả — tất cả mà không ảnh hưởng production environment.
# Upload files vào container
with open("myapp.py", "rb") as f:
file = client.files.create(file=f, purpose="assistants")
response = client.responses.create(
model="gpt-4.1",
input="Chạy tests cho myapp.py và fix mọi lỗi",
tools=[{"type": "shell"}, {"type": "code_interpreter"}],
container={"files": [file.id]},
)Về bảo mật, đây là mô hình đúng: thực thi được isolation mặc định, và bạn opt-in để cho container truy cập files thay vì ngược lại.
4. Context Compaction
Ai đã chạy multi-step agentic workflows đều biết vấn đề context window. Tool output dài (ví dụ: log test failure 500 dòng) ăn context budget nhanh chóng, và đến turn thứ 8 của agent loop 20 turns, bạn đang hoặc truncate hoặc hit token limits.
Context compaction tự động tóm tắt các turns cũ để giữ active context có thể quản lý, trong khi vẫn giữ semantic information mà model cần. Hãy nghĩ nó như lớp lossy compression cho conversation history — turns cũ được nén, turns gần đây giữ nguyên.
Điều này thực sự hữu ích. Theo kinh nghiệm của tôi, hầu hết lỗi multi-step agent đến từ:
- Model mất track những gì đã xảy ra trong các bước trước, hoặc
- Tool output bloat làm đầy context trước khi task xong
Context compaction giải quyết cả hai.
5. Reusable Agent Skills
Bổ sung cuối cùng là “skills” — các bundle tái sử dụng được của tool configurations và system prompt fragments. Hãy nghĩ chúng như function calls cho agent capabilities.
OpenAI đang xây dựng skills library cho các tác vụ phổ biến: web search, code review, data analysis. Bạn cũng có thể định nghĩa custom skills và reference chúng bằng ID:
response = client.responses.create(
model="gpt-4.1",
input="Review PR này để tìm lỗ hổng bảo mật",
skills=["security-code-review-v1", "my-org/custom-standards"]
)Điều này hữu ích nhất cho các tổ chức muốn chuẩn hóa cách agents thực hiện các tác vụ cụ thể. Thay vì mỗi team viết system prompt “code review” riêng, bạn định nghĩa một lần, version nó, và reference ở mọi nơi.
Ý Nghĩa Kiến Trúc
Trước những update này, xây production agent nghĩa là chọn giữa:
Option A: Tự viết loop — Toàn quyền kiểm soát, nhưng bạn maintain orchestration logic, retry handling, context management, và tool execution.
Option B: Dùng framework — LangChain, LlamaIndex, AutoGen, etc. Ít code hơn, nhưng framework abstractions bị leak, debug khó hơn, và bạn phụ thuộc vào framework updates.
Responses API giờ cung cấp Option C: Hosted orchestration — OpenAI quản lý loop, execution environment, và context. Bạn viết declarative tool definitions và xử lý I/O.
Với hầu hết use cases, Option C thắng về độ đơn giản. Các đánh đổi:
| Tự Viết | Framework | Responses API | |
|---|---|---|---|
| Kiểm soát | Cao | Trung bình | Thấp |
| Maintenance | Cao | Trung bình | Thấp |
| Vendor lock-in | Không | Framework | OpenAI |
| Cost visibility | Rõ ràng | Rõ ràng | Ít rõ hơn |
| Debug production | Khó nhất | Trung bình | Tùy logging |
Khuyến nghị của tôi: Dùng Responses API cho greenfield agentic features nơi bạn chưa có orchestration investments. Giữ nguyên cách tiếp cận hiện tại cho các workflows trưởng thành nơi bạn đã xử lý được độ phức tạp.
Bức Tranh Toàn Cảnh: Hạ Tầng Agent Đang Đi Đâu
Các update Responses API theo một pattern rõ ràng: OpenAI (và mọi lab lớn) đang di chuyển lên stack từ “model API” thành “agent execution environment.”
Điều này không đáng ngạc nhiên. Các models đang trở nên commodity. Sự khác biệt chuyển sang:
- Execution environments — Hệ thống có thể chạy multi-step tasks đáng tin cậy đến mức nào?
- Tool ecosystems — Có bao nhiêu integrations sẵn có out of the box?
- Observability — Các team có thể debug và monitor agent behavior trong production không?
- Cost efficiency — Hệ thống quản lý context và compute như thế nào để giữ chi phí có thể dự đoán?
Hosted container workspace là câu trả lời của OpenAI cho câu hỏi “agent chạy ở đâu?”. Reusable skills là câu trả lời cho “các team chia sẻ agent capabilities như thế nào?”
Cả hai đều đúng câu hỏi. OpenAI có thực thi tốt hay không còn phải chờ xem — nhưng hướng đi là đúng.
Takeaways Thực Tế
Nếu bạn đang xây dựng hoặc maintain AI systems hôm nay:
-
Đánh giá built-in loop — Nếu bạn đang maintain custom agent loop, đo xem migrate sang Responses API có giảm maintenance burden không.
-
Pilot container workspace — Với code-execution use cases (chạy test, linting, code generation), hosted container là lựa chọn thay thế hợp lệ cho việc tự quản lý execution sandbox.
-
Theo dõi pricing — Hosted containers có cost dimensions mới (compute time, không chỉ tokens). Model hóa actual usage trước khi commit.
-
Đừng bỏ framework hiện tại quá nhanh — LangChain, LlamaIndex, etc. có mature ecosystems. Responses API còn mới và sẽ có rough edges. Migration nên incremental.
-
Thiết kế cho observability — Dù bạn chọn execution model nào, instrument các agent runs của bạn. Bạn không thể debug những gì không thể observe.
Responses API năm 2026 đang bắt đầu trông ít giống một model API và nhiều hơn như một platform cho autonomous software work. Đây là sự thay đổi quan trọng — và đáng theo dõi sát sao.