Forem: Sebastian Petrus

Gemini 3.5 Flash đấu với GPT-5.5 và Opus 4.7: Liệu Mô Hình Nhanh Có Thắng Được Các Đối Thủ Hàng Đầu?

Sebastian Petrus — Wed, 20 May 2026 02:44:29 +0000

Ba bản phát hành thuộc phân khúc tiên tiến đã ra mắt trong 33 ngày: Claude Opus 4.7 của Anthropic ngày 16/4, GPT-5.5 của OpenAI ngày 23/4, và Gemini 3.5 Flash của Google ngày 19/5. Gemini 3.5 Pro dự kiến ra mắt vào tháng 6.

Dùng thử Apidog hôm nay

Đây không phải là so sánh “ngang hạng”. Opus 4.7 và GPT-5.5 là mô hình hàng đầu với giá cao. Gemini 3.5 Flash là biến thể nhanh, chi phí thấp. Câu hỏi thực tế cho developer là: Flash có đủ tốt để chạy production workload rẻ hơn 5–10 lần không?

Câu trả lời ngắn: có, với nhiều workload. Flash thắng về chi phí, tốc độ, ngữ cảnh dài và một số benchmark tác nhân. Opus 4.7 vẫn mạnh nhất ở refactor code khó. GPT-5.5 nổi bật ở hiệu quả token và tác nhân CLI.

Câu trả lời trong 30 giây

Câu hỏi	Lựa chọn tốt nhất
Vòng lặp tác nhân production rẻ nhất	Gemini 3.5 Flash
Sửa lỗi đã xác minh trên SWE-Bench	Opus 4.7
Hiệu quả token ở quy mô lớn	GPT-5.5
Truy xuất ngữ cảnh dài 1M token	Gemini 3.5 Flash
Hiểu biểu đồ và tài liệu	Gemini 3.5 Flash
Tác nhân CLI chạy dài	GPT-5.5
Thực hiện hướng dẫn đa bước	Opus 4.7
Streaming token nhanh nhất	Gemini 3.5 Flash
Refactor toàn bộ repository	Opus 4.7

Không có một mô hình thắng mọi tình huống. Cách triển khai hợp lý là route workload theo loại tác vụ, chi phí và độ trễ.

1. Định vị từng mô hình

Opus 4.7 — phát hành 16/4/2026. Mô hình suy luận hàng đầu của Anthropic, tối ưu cho code, refactor đa bước và workflow dài.
GPT-5.5 — phát hành 23/4/2026. Mô hình cơ sở được đào tạo lại hoàn toàn đầu tiên của OpenAI kể từ GPT-4.5, tập trung vào hiệu quả tác nhân và giảm token đầu ra.
Gemini 3.5 Flash — phát hành 19/5/2026. Biến thể nhanh của dòng Gemini 3.5, tập trung vào tốc độ, chi phí thấp và tác nhân production.

Nếu bạn đang so sánh trong bối cảnh coding tool, xem thêm Cursor Composer 2.5 so với Opus 4.7 so với GPT-5.5. Để xem thế hệ trước cạnh tranh thế nào, xem Gemini 3.1 Pro so với Opus 4.6 so với GPT-5.3.

2. So sánh giá

Mô hình	Đầu vào / 1M token	Đầu ra / 1M token	Ghi chú
Gemini 3.5 Flash	~1,50 USD	~9,00 USD	Có gói miễn phí
GPT-5.5	~10 USD	~30 USD	Đầu vào được lưu trữ rẻ hơn
Claude Opus 4.7	~15 USD	~75 USD	Giá niêm yết cao nhất

Flash rẻ hơn khoảng 6–10 lần ở đầu vào và 3–8 lần ở đầu ra. Với agent loop chạy hàng trăm lượt trên mỗi task, khác biệt này rất lớn.

Tuy nhiên, GPT-5.5 có lợi thế ở hiệu quả token: cùng một tác vụ có thể tạo ít token đầu ra hơn đáng kể, đôi khi ít hơn 72% so với Opus 4.7. Vì vậy, khi tính chi phí production, đừng chỉ nhìn giá token; hãy đo:

chi phí / task =
(input_tokens * input_price)
+ (output_tokens * output_price)
+ retry_cost
+ tool_call_cost

Tham khảo thêm phân tích giá Gemini 3.5 Flash và giá GPT-5.5.

3. Benchmark coding

SWE-Bench Verified

Mô hình	Điểm số
Opus 4.7	87,6%
GPT-5.5	~85%
Gemini 3.5 Flash	Chưa được báo cáo riêng

Opus 4.7 dẫn đầu ở các task sửa lỗi biệt lập. GPT-5.5 rất gần. Flash không công bố số tương đương, và thử nghiệm không chính thức cho thấy nó thấp hơn hai mô hình hàng đầu — điều hợp lý với một mô hình phân khúc nhanh.

SWE-Bench Pro

Mô hình	Điểm số
Opus 4.7	64,3%
GPT-5.5	58,6%
Gemini 3.5 Flash	Chưa được báo cáo riêng

Nếu workload của bạn là refactor đa tệp, migration lớn hoặc thay đổi toàn repo, Opus 4.7 là lựa chọn an toàn hơn. Điều này đặc biệt đúng với workflow kiểu Cursor Composer hoặc Claude Code.

Flash vẫn phù hợp cho thay đổi thông thường, bug nhỏ, giải thích code, review nhanh và tạo test ở chi phí thấp.

Terminal-Bench 2.0 / 2.1

Mô hình	Điểm số	Benchmark
GPT-5.5	82,7%	Terminal-Bench 2.0
Gemini 3.5 Flash	76,2%	Terminal-Bench 2.1
Opus 4.7	69,4%	Terminal-Bench 2.0

Hai benchmark 2.0 và 2.1 không hoàn toàn giống nhau, nhưng hướng chính khá rõ:

GPT-5.5 mạnh nhất ở agent CLI chạy dài.
Flash thu hẹp phần lớn khoảng cách với chi phí thấp hơn nhiều.
Opus 4.7 tốt ở chất lượng từng lượt, nhưng chậm và đắt hơn cho loop dài.

MCP Atlas

Gemini 3.5 Flash đạt 83,6% trên MCP Atlas, chỉ số Google dùng cho phối hợp đa công cụ. OpenAI và Anthropic chưa công bố số tương đương trên cùng benchmark, nên không nên suy luận quá xa. Nhưng về mặt triển khai, cả ba đều đủ tốt cho tool calling production nếu bạn kiểm soát schema và retry.

4. Cách chọn cho agent workload

Với tác nhân chạy từ vài phút đến vài giờ, hãy ưu tiên theo thứ tự này:

1. Task success rate
2. Chi phí / task
3. Độ trễ end-to-end
4. Tỷ lệ retry
5. Độ ổn định schema/tool call

Gemini 3.5 Flash phù hợp khi

Bạn chạy số lượng task lớn.
Chi phí/token là ràng buộc chính.
Cần streaming nhanh.
Agent cần đọc nhiều tài liệu, log, transcript hoặc repo lớn.
Bạn chấp nhận “đủ tốt” để đổi lấy throughput.

GPT-5.5 phù hợp khi

Task thiên về CLI agent.
Bạn muốn output ngắn, kỷ luật token tốt.
Cần giảm biến thiên chi phí giữa các lần chạy.
Team đã dùng OpenAI/Codex/Responses API.

Opus 4.7 phù hợp khi

Task khó, nhiều bước, ít được phép sai.
Refactor code đa tệp hoặc thay đổi kiến trúc.
Output dài, cẩn thận, có tính bàn giao.
Chi phí không phải giới hạn chính.

Nếu bạn đang xây agent tự động theo mẫu như lệnh /goal với Codex và Claude Code, hãy đo chi phí theo task hoàn chỉnh, không đo từng prompt riêng lẻ.

5. Context window và truy xuất dài

Mô hình	Đầu vào tối đa	Đầu ra tối đa
Gemini 3.5 Flash	1M token	64K token
GPT-5.5	400K token	128K token
Opus 4.7	1M token beta	64K token

Flash dẫn đầu trong bảng công bố của Google trên benchmark MRCR v2 1M token. Với các task kiểu:

tìm thông tin trong PDF dài,
phân tích nhiều tài liệu,
đọc log lớn,
hỏi đáp trên codebase,
tổng hợp transcript hoặc report,

Flash là lựa chọn mặc định thực dụng nhất vì kết hợp 1M context + giá thấp + tốc độ cao.

Opus 4.7 có cửa sổ 1M token ở beta, nhưng chi phí cao hơn. GPT-5.5 có 400K token, đủ rộng cho nhiều use case, nhưng không bằng Flash về quy mô thô.

6. Đa phương thức

Flash dẫn đầu ở khả năng suy luận biểu đồ và tài liệu:

CharXiv Reasoning: 84,2%
MMMU-Pro: 83,6%

Nếu workload của bạn gồm PDF scan, biểu đồ, dashboard screenshot, tài liệu kỹ thuật có hình, hoặc phân tích UI, Flash là lựa chọn mạnh.

Nếu bạn route cả phần tạo ảnh trong pipeline, xem thêm so sánh Gemini 3 Pro Image vs Seedream.

7. Tốc độ output

Mô hình	Tốc độ đầu ra tương đối
Gemini 3.5 Flash	~4x baseline
GPT-5.5	baseline
Opus 4.7	~0,7x baseline

Số cụ thể thay đổi theo khu vực và tải hệ thống, nhưng hướng nhất quán là: Flash streaming nhanh hơn rõ rệt.

Điều này quan trọng với:

chatbot có streaming response,
coding assistant trực tiếp,
agent UI có log realtime,
dashboard phân tích tài liệu,
sản phẩm cần cảm giác phản hồi tức thì.

8. Suy luận, toán học và viết dài

Điểm chuẩn / khả năng	Flash	GPT-5.5	Opus 4.7
GPQA Diamond	Mạnh theo bảng Google	Cao	Cao
Suy luận toán học	Mạnh	Mạnh	Mạnh
Viết dài	Tốt	Tốt	Tốt nhất

Ba mô hình đều mạnh về reasoning. Khác biệt lớn hơn nằm ở style output:

Flash: nhanh, thực dụng, tốt cho xử lý khối lượng lớn.
GPT-5.5: gọn, hiệu quả token.
Opus 4.7: văn phong dài, cẩn thận, phù hợp output chất lượng cao.

9. Hệ sinh thái công cụ

Opus 4.7: Claude Code, MCP, Anthropic API, hệ sinh thái tool trưởng thành, Bitwarden Agent, hỗ trợ IDE rộng.
GPT-5.5: OpenAI Codex, Responses API, tích hợp ChatGPT, lịch sử function calling dài.
Gemini 3.5 Flash: Antigravity, Gemini Agent Platform, Gemini CLI, Android Studio, Google Cloud/Workspace.

Anthropic có hệ sinh thái adapter bên thứ ba sâu. OpenAI có mức độ chấp nhận developer rộng. Google đang bắt kịp nhanh với Gemini CLI, Antigravity và nền tảng tác nhân.

10. Ma trận chọn mô hình

Chọn Gemini 3.5 Flash khi

Bạn cần chi phí thấp trên mỗi task.
UI cần streaming nhanh.
Input dài tới 1M token.
Task có biểu đồ, PDF, screenshot.
Agent workload lớn và cần throughput.
Bạn đang dùng Google Cloud hoặc Workspace.
“Đủ tốt, nhanh, rẻ” quan trọng hơn “tối ưu tuyệt đối”.

Chọn GPT-5.5 khi

Hiệu quả token là ưu tiên.
Task là CLI agent hoặc automation nhiều bước.
Bạn cần output gọn và ít lan man.
Team đã dùng ChatGPT/OpenAI.
Bạn muốn thiết lập API theo hướng dẫn Cách sử dụng API GPT-5.5.

Chọn Opus 4.7 khi

Task là refactor đa tệp hoặc thay đổi toàn repo.
Chất lượng từng lượt quan trọng hơn tốc độ.
Output dài, cẩn thận là sản phẩm bàn giao.
Bạn đã dùng Claude Code với gói Claude.
Chi phí không phải ràng buộc chính.

Chọn kết hợp khi

Production stack thường không nên chỉ dùng một mô hình. Một số pattern thực tế:

Flash để truy xuất và chuẩn bị, Opus để quyết định cuối.
GPT-5.5 cho CLI agent, Flash cho phân tích tài liệu/biểu đồ.
Flash xử lý 80% traffic, Opus hoặc GPT-5.5 xử lý 20% task khó.
Router mỏng chọn model theo loại task, độ dài input và ngân sách.

Ví dụ pseudo-router:

type Task = {
  kind: "code_refactor" | "cli_agent" | "doc_qa" | "vision_doc" | "chat";
  inputTokens: number;
  priority: "cost" | "quality" | "latency";
};

function selectModel(task: Task) {
  if (task.kind === "code_refactor" && task.priority === "quality") {
    return "claude-opus-4.7";
  }

  if (task.kind === "cli_agent") {
    return "gpt-5.5";
  }

  if (
    task.kind === "doc_qa" ||
    task.kind === "vision_doc" ||
    task.inputTokens > 400_000 ||
    task.priority === "cost" ||
    task.priority === "latency"
  ) {
    return "gemini-3.5-flash";
  }

  return "gemini-3.5-flash";
}

11. Gói miễn phí

Cả ba đều có đường dùng thử:

Gemini 3.5 Flash: API key từ AI Studio, khoảng 1.500 request/ngày. Xem hướng dẫn miễn phí Flash.
GPT-5.5: truy vấn miễn phí có giới hạn trong ChatGPT và các cổng được nêu trong hướng dẫn miễn phí GPT-5.5.
Opus 4.7: giới hạn hằng ngày trên Claude.ai, cộng với các cách trong hướng dẫn miễn phí Opus 4.7.

Trong ba lựa chọn, đường API miễn phí của Flash thân thiện với developer nhất vì AI Studio cung cấp key hoạt động mà không cần thẻ tín dụng và có hạn ngạch hữu ích.

12. Cách tự benchmark với workload của bạn

Benchmark công khai chỉ cho biết mô hình hoạt động trung bình. Bạn cần đánh giá trên dữ liệu thật.

Tạo một eval nhỏ theo các bước sau:

Chọn 20 task đại diện từ workload thật.
Chạy cả ba mô hình trên cùng input.
Chấm theo ba tiêu chí:
- task có thành công không,
- tổng chi phí,
- độ trễ end-to-end.
Ghi lại lỗi:
- JSON sai schema,
- tool call sai tham số,
- hallucination,
- timeout,
- retry,
- output quá dài,
- không tuân thủ instruction.

Một cấu trúc log đơn giản:

{
  "task_id": "bugfix-014",
  "model": "gemini-3.5-flash",
  "success": true,
  "latency_ms": 8420,
  "input_tokens": 18200,
  "output_tokens": 2100,
  "estimated_cost_usd": 0.046,
  "failure_mode": null
}

Đây là nơi Apidog hữu ích. Bạn có thể lưu ba endpoint API — Gemini, OpenAI, Anthropic — dưới dạng request có tham số, lưu API key bằng environment variable, rồi chạy cùng một prompt trên cả ba để so sánh response cạnh nhau.

Thiết lập thực tế:

Tải xuống Apidog
Tạo workspace tên Frontier Model Eval

Tạo ba request:
- POST Gemini 3.5 Flash
- POST GPT-5.5
- POST Claude Opus 4.7
Lưu API key trong environment variables.
Dùng cùng một prompt template cho cả ba.
Thêm assertion:
- response là JSON hợp lệ,
- có field bắt buộc,
- latency dưới ngưỡng,
- không có chuỗi lỗi,
- tool call đúng schema.
Chạy lại hằng tuần để phát hiện thay đổi model.

Hai ngày thiết lập eval tốt hơn ba tháng tranh luận xem model nào “cảm giác” tốt hơn.

13. Điều gì sẽ thay đổi tiếp theo

Ba điểm cần theo dõi trong 90 ngày tới:

Gemini 3.5 Pro GA

Khi Pro ra mắt vào tháng 6, so sánh sẽ thay đổi. Flash vẫn giữ lợi thế chi phí/tốc độ, còn Pro sẽ cạnh tranh trực tiếp với Opus và GPT-5.5.
Phản hồi của OpenAI

GPT-5.5 là bản phát hành tháng 4. Nếu Gemini 3.5 Pro mạnh, một bản cập nhật giữa chu kỳ hoặc biến thể mới có thể xuất hiện.
Bước tiếp theo của Anthropic

Opus 4.7 là flagship hiện tại. Một bản làm mới Sonnet hoặc Opus 4.8 trong quý tới sẽ phù hợp chu kỳ.

Thị trường hiện thay đổi theo tháng. Cách an toàn là duy trì eval suite, route model theo kết quả mới và tránh khóa chặt vào một nhà cung cấp.

Câu hỏi thường gặp

Gemini 3.5 Flash có thực sự cạnh tranh với Opus 4.7 và GPT-5.5 không?

Có, trong đúng phân khúc. Flash vượt hạng ở chi phí, tốc độ, ngữ cảnh dài và một số workload tác nhân. Với task khó nhất như refactor đa tệp phức tạp hoặc viết dài chất lượng cao, Opus và GPT-5.5 vẫn có lợi thế.

Tại sao so sánh mô hình Flash với flagship?

Vì chi phí chênh lệch quá lớn. Câu hỏi production không phải “Flash có tốt nhất mọi thứ không?”, mà là “Flash có đủ tốt cho 80% workload không?”.

Opus 4.7 có đáng giá cao hơn không?

Có, nếu chất lượng code hoặc output dài là yếu tố quan trọng nhất. Với agent loop khối lượng lớn, Flash thường thắng về chi phí/task.

Tôi có thể dùng cả ba qua một API không?

Không trực tiếp. Mỗi nhà cung cấp có endpoint và credential riêng. Cách rõ ràng nhất là viết wrapper mỏng hoặc router nội bộ để trừu tượng hóa call model.

Khi nào Gemini 3.5 Pro ra mắt?

Tháng 6/2026. Đây sẽ là đối thủ flagship trực tiếp của Opus 4.7 và GPT-5.5.

Làm sao theo dõi chi phí khi dùng ba nhà cung cấp?

Ghi log token, model, latency và cost cho từng request. Bạn có thể theo dõi trong lịch sử request của Apidog hoặc tổng hợp từ dashboard của từng nhà cung cấp. Nên đặt budget alert theo model.

Tổng kết

Ba mô hình mạnh ở ba hướng khác nhau:

Gemini 3.5 Flash: rẻ, nhanh, mạnh về ngữ cảnh dài, đa phương thức và agent workload khối lượng lớn.
GPT-5.5: tốt cho CLI agent, tự động hóa nhiều bước và tối ưu token.
Opus 4.7: tốt nhất cho refactor code chất lượng cao, task phức tạp và viết dài.

Cách triển khai thực tế: xây eval suite của riêng bạn, kiểm tra bằng workload thật, route task theo kết quả và cập nhật khi model thay đổi. Tháng 6 sẽ đáng chú ý vì Gemini 3.5 Pro có thể định hình lại toàn bộ cuộc so sánh này.

Cách Sử Dụng Gemini 3.5 Flash Miễn Phí

Sebastian Petrus — Wed, 20 May 2026 02:26:04 +0000

Gemini 3.5 Flash ra mắt vào ngày 19 tháng 5 năm 2026 và Google vẫn duy trì tầng truy cập miễn phí. Bạn có thể gọi Flash bằng khóa API miễn phí ngay hôm nay; phiên bản Pro dự kiến ra mắt vào tháng 6. Nếu muốn dùng Flash mà không trả phí, dưới đây là các cách thực tế nhất để bắt đầu.

Dùng thử Apidog ngay hôm nay

Hướng dẫn này tập trung vào thiết lập thực tế: lấy khóa miễn phí, chạy thử bằng code, kiểm tra giới hạn và chọn đúng đường dẫn cho từng nhu cầu.

Tóm tắt nhanh

Đường dẫn	Bạn nhận được gì	Giới hạn
Ứng dụng Gemini	Trò chuyện đầy đủ + nhập ảnh trên Flash	Giới hạn tin nhắn hằng ngày trên tầng miễn phí
Google AI Studio	Giao diện web để thử Flash và chỉnh tham số	Không có hạn ngạch cứng trong UI
Khóa API AI Studio	Truy cập REST/SDK tới `gemini-3.5-flash`	Khoảng 1.500 yêu cầu/ngày
Tín dụng tài khoản mới Vertex AI	Truy cập Flash theo kiểu production	300 USD tín dụng, 90 ngày
Gemini CLI	Dùng Flash từ terminal bằng tài khoản Google	1.000 yêu cầu/ngày
OpenRouter/cổng bên thứ ba	Truy cập Flash qua dịch vụ trung gian	Phụ thuộc từng nhà cung cấp

Mỗi cách phù hợp với một trường hợp khác nhau: thử nhanh, thiết kế prompt, xây dựng app, test tải hoặc chạy script từ terminal.

Cách 1: Dùng ứng dụng Gemini nếu chỉ cần chat

Nếu bạn chỉ muốn trò chuyện với Gemini 3.5 Flash, đây là cách nhanh nhất.

Mở gemini.google.com
Đăng nhập bằng tài khoản Google
Trong bộ chọn model, chọn 3.5 Flash
Nhập prompt và bắt đầu dùng

Ứng dụng Gemini hỗ trợ văn bản, ảnh, tải tệp và chỉnh sửa tài liệu kiểu Canvas. Người dùng miễn phí có giới hạn tin nhắn hằng ngày và giới hạn này được đặt lại mỗi ngày.

Phù hợp cho:

Nghiên cứu, viết nội dung, brainstorming
Phân tích hình ảnh không cần API
So sánh nhanh với các mô hình chat miễn phí khác

Không phù hợp cho:

Tích hợp vào ứng dụng
Xử lý hàng loạt
Workflow cần response có thể lập trình được

Cách 2: Dùng Google AI Studio để thiết kế prompt

Google AI Studio là sân chơi dành cho developer. Nó chạy trên trình duyệt, miễn phí và cho phép bạn chỉnh các tham số của Flash trước khi đưa vào code.

Cách chạy thử:

Mở aistudio.google.com
Đăng nhập
Chọn Create new prompt hoặc dùng template có sẵn
Trong dropdown model, chọn gemini-3.5-flash
Nhập prompt và bấm Run

AI Studio hữu ích hơn app Gemini khi bạn cần:

Điều chỉnh temperature, top-K, top-P
Đặt system instruction
Kiểm tra JSON structured output
Chạy prompt đa phương thức với nhiều ảnh
Lấy code Python/Node tương ứng
Xuất prompt thành một lời gọi API Flash

Nếu bạn đang xây tính năng AI, hãy dùng AI Studio để tinh chỉnh prompt trước, sau đó mới chuyển sang API.

Cách 3: Lấy khóa API Gemini 3.5 Flash miễn phí

Đây là cách phù hợp nhất nếu bạn muốn tích hợp Flash vào ứng dụng. Cùng tài khoản AI Studio có thể tạo khóa API miễn phí dùng với gemini-3.5-flash.

Lấy khóa API

Mở AI Studio
Nhấp Get API key ở thanh điều hướng bên trái
Chọn project hiện có hoặc tạo project mới
Nhấp Create API key
Sao chép khóa và lưu vào biến môi trường

Không cần thẻ tín dụng. Khóa có thể dùng ngay với Flash. Nếu cần hướng dẫn chi tiết hơn, xem hướng dẫn lấy khóa API Gemini miễn phí.

Hạn ngạch miễn phí của Flash

Tính đến tháng 5 năm 2026, tầng miễn phí cho gemini-3.5-flash khoảng:

1.500 yêu cầu/ngày
1 triệu token/phút
15 yêu cầu/phút

Các con số này có thể thay đổi. Trước khi build production, hãy kiểm tra trang giá chính thức của Google. Nếu cần phân tích chi phí khi vượt tầng miễn phí, xem phân tích giá Gemini 3.5 Flash.

Chạy thử bằng Python

Cài SDK:

pip install google-genai

Đặt biến môi trường:

export GEMINI_API_KEY="your-api-key"

Gọi model:

import os
from google import genai

client = genai.Client(api_key=os.environ["GEMINI_API_KEY"])

response = client.models.generate_content(
    model="gemini-3.5-flash",
    contents="Give me three startup ideas for API tooling in 2026."
)

print(response.text)

Chạy thử bằng Node.js

Cài SDK:

npm install @google/genai

Code mẫu:

import { GoogleGenAI } from "@google/genai";

const ai = new GoogleGenAI({
  apiKey: process.env.GEMINI_API_KEY,
});

const response = await ai.models.generateContent({
  model: "gemini-3.5-flash",
  contents: "Give me three startup ideas for API tooling in 2026.",
});

console.log(response.text);

Chạy thử bằng curl

curl "https://generativelanguage.googleapis.com/v1beta/models/gemini-3.5-flash:generateContent" \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "contents": [
      {
        "parts": [
          {
            "text": "Hello Gemini 3.5 Flash"
          }
        ]
      }
    ]
  }'

Để triển khai đầy đủ hơn với streaming và tool calls, xem hướng dẫn API Gemini 3.5 Flash.

Kiểm tra request Flash miễn phí trong Apidog

Khi chỉ có khoảng 1.500 request/ngày, bạn nên tránh lãng phí hạn ngạch vào các request sai format hoặc prompt chưa ổn định. Apidog giúp lưu endpoint Flash, quản lý API key bằng biến môi trường và chạy lại request mà không cần viết curl nhiều lần.

Quy trình đề xuất:

Tải Apidog
Tạo request mới
Dán curl Gemini Flash ở trên
Chuyển API key sang biến môi trường
Lưu request
Thêm assertion cho response
Chạy lại request khi bạn thay đổi prompt

Cách này giúp bạn kiểm tra prompt có kiểm soát hơn và tránh gọi API lặp lại không cần thiết.

Cách 4: Dùng tín dụng tài khoản mới của Vertex AI

Nếu tạo tài khoản Google Cloud mới, bạn có thể nhận 300 USD tín dụng trong 90 ngày. Khoản tín dụng này dùng được cho endpoint Gemini 3.5 Flash trên Vertex AI.

Cách thiết lập:

Đăng ký tại cloud.google.com và nhận tín dụng 300 USD
Bật Vertex AI API
Tạo service account
Gán quyền aiplatform.user
Tải file credential JSON
Gọi Flash bằng Vertex AI SDK

Ví dụ Python:

import vertexai
from vertexai.generative_models import GenerativeModel

vertexai.init(
    project="your-project-id",
    location="us-central1"
)

model = GenerativeModel("gemini-3.5-flash")

response = model.generate_content("Explain CAP theorem.")
print(response.text)

Vertex AI không dùng cùng giới hạn request/ngày như tầng miễn phí của AI Studio. Bạn bị giới hạn bởi lượng tín dụng còn lại. Với mức giá Flash khoảng 1,50 USD/9 USD cho mỗi 1 triệu token, 300 USD có thể đủ cho vài tuần sử dụng vừa phải.

Lưu ý:

Tín dụng hết hạn sau 90 ngày
Tín dụng không dùng sẽ mất
Hãy kiểm tra cài đặt thanh toán để tránh bị tính phí ngoài ý muốn
Vertex AI phức tạp hơn AI Studio, nhưng phù hợp hơn cho môi trường production

Cách 5: Dùng Gemini CLI từ terminal

Gemini CLI là client terminal mã nguồn mở của Google. Nó xác thực bằng tài khoản Google và cung cấp hạn ngạch miễn phí khoảng 1.000 request/ngày, không cần API key.

Cài đặt và chạy:

# Cài đặt
npm install -g @google/gemini-cli

# Chạy CLI
gemini

# Trong CLI, chọn gemini-3.5-flash

CLI phù hợp khi bạn muốn dùng Flash trực tiếp trong terminal, ví dụ:

Tóm tắt file hoặc thư mục code
Viết script nhanh
Kết hợp với grep, cat, jq hoặc các tool shell khác
Dùng như một giải pháp thay thế Claude Code miễn phí

Không nên dùng CLI cho:

Tích hợp production
Workflow cần kiểm soát HTTP streaming thô
Service backend cần auth và retry logic rõ ràng

Với production, hãy dùng API key hoặc Vertex AI.

Cách 6: Dùng OpenRouter và các cổng bên thứ ba

Một số cổng bên thứ ba tổng hợp quyền truy cập model AI và có thể định tuyến request Flash miễn phí hoặc gần miễn phí. Cách này được đề cập trong bài Lấy API Gemini không giới hạn miễn phí.

Cần lưu ý:

Chất lượng và tốc độ phụ thuộc từng dịch vụ
Một số cổng throttle rất mạnh
Prompt của bạn đi qua bên thứ ba
Không nên gửi dữ liệu nhạy cảm
Chính sách thanh toán và giới hạn có thể thay đổi

Hãy xem đây là phương án dự phòng. Nếu đang xây sản phẩm nghiêm túc, AI Studio hoặc Vertex AI vẫn là lựa chọn ổn định hơn.

Nên chọn cách nào?

Một cây quyết định ngắn:

Chỉ muốn chat: dùng ứng dụng Gemini
Muốn thiết kế prompt: dùng Google AI Studio
Muốn build app: dùng khóa API AI Studio
Cần test với hạn ngạch cao hơn: dùng tín dụng Vertex AI
Muốn chạy từ terminal: dùng Gemini CLI
Chấp nhận dịch vụ trung gian: thử OpenRouter hoặc cổng tương tự

Với đa số developer, cấu hình thực tế nhất là:

Dùng AI Studio để thiết kế prompt
Dùng API key miễn phí để build prototype
Dùng Apidog để kiểm tra request/response
Chuyển sang Vertex hoặc tài khoản trả phí khi cần production

Khi nào nên nâng cấp từ Flash miễn phí sang trả phí?

Tầng miễn phí đủ cho nhiều prototype và side project. Bạn nên nâng cấp khi gặp một trong ba trường hợp sau:

Bạn chạm giới hạn 1.500 request/ngày nhiều ngày liên tiếp

Lúc này chi phí xử lý workaround hạn ngạch có thể cao hơn chi phí trả phí.
Bạn cần throughput mỗi phút cao hơn

Tầng miễn phí bị giới hạn khoảng 15 RPM. Nếu app có nhiều user đồng thời, giới hạn này sẽ nhanh chóng trở thành bottleneck.
Bạn cần logging, kiểm soát dữ liệu hoặc audit tốt hơn

Với yêu cầu production, Vertex AI trên tài khoản thanh toán thường phù hợp hơn.

Để tính chi phí theo token, batch discount và các kịch bản thực tế, xem hướng dẫn định giá Gemini 3.5 Flash.

Bạn cũng nên so sánh với các model khác. GPT-5.5 và Claude Opus 4.7 có các đường miễn phí riêng. Nếu cần chọn model theo workload, xem bài so sánh Gemini 3.5, GPT-5.5 và Opus 4.7.

Mẹo kéo dài tầng miễn phí của Flash

Một vài thói quen giúp 1.500 request/ngày dùng được lâu hơn:

Cache response

Với truy vấn lặp lại, hãy trả kết quả từ cache thay vì gọi API lại.
Validate input trước khi gọi model

Kiểm tra URL, JSON schema, độ dài input và field bắt buộc trước khi gửi request.
Dùng structured output

Nếu cần JSON, hãy yêu cầu model trả về JSON theo schema ngay từ đầu. Điều này giảm số lần retry và parse lỗi.
Dùng batch mode cho tác vụ không realtime

Batch mode của Gemini API có thể giúp giảm chi phí cho workload không cần phản hồi tức thì.
Kiểm tra request trong Apidog trước khi đưa vào code

Assertion của Apidog giúp bắt lỗi response sớm, tránh tiêu tốn hạn ngạch vào request sai.
Ưu tiên Flash cho tác vụ thường ngày

Khi Pro ra mắt, hãy chỉ dùng Pro cho tác vụ thật sự cần chất lượng cao hơn. Các workflow thông thường nên tiếp tục dùng Flash.

FAQ

Gemini 3.5 Flash có thật sự miễn phí không?

Có, nhưng có giới hạn. Ứng dụng Gemini, AI Studio và khóa API AI Studio đều cho phép dùng Flash miễn phí với hạn ngạch hằng ngày.

Tôi có cần thẻ tín dụng để lấy khóa API Flash miễn phí không?

Không. Tầng miễn phí của AI Studio không yêu cầu thẻ tín dụng. Vertex AI cần thẻ để nhận tín dụng 300 USD, nhưng bạn không bị tính phí nếu chưa nâng cấp hoặc vượt điều kiện thanh toán.

Có thể dùng khóa Flash miễn phí trong production không?

Về mặt kỹ thuật là có, nhưng không nên phụ thuộc lâu dài vào hạn ngạch miễn phí. Giới hạn 1.500 request/ngày và 15 RPM có thể không đủ cho production.

Gemini 3.5 Pro có miễn phí không?

Google trước đây thường mở quyền truy cập miễn phí cho các model Pro khi GA, nhưng hạn ngạch thường chặt hơn. Với thông tin hiện tại, Pro dự kiến ra mắt sau Flash.

Có thể dùng Flash miễn phí trong Cursor hoặc VS Code không?

Có, nếu công cụ đó hỗ trợ API key tùy chỉnh. Cách làm tương tự hướng dẫn Gemini 3.0 Pro với Cursor, chỉ cần đổi model thành gemini-3.5-flash.

Có xem được usage log không?

Có. Trong AI Studio, mở project của bạn và kiểm tra tab Activity.

Có rủi ro gì khi dùng tầng miễn phí không?

Có hai điểm cần chú ý:

Prompt trên tầng miễn phí có thể được dùng để cải thiện model của Google, tùy cài đặt.
Rate limit của tầng miễn phí có thể thay đổi mà không báo trước.

Không nên đặt deadline production phụ thuộc hoàn toàn vào hạn ngạch miễn phí.

Dự án khởi đầu: API tóm tắt URL bằng Flash

Một bài tập thực tế: viết một script nhận URL, tải nội dung trang và dùng Flash để tóm tắt.

import os
import requests
from google import genai

client = genai.Client(api_key=os.environ["GEMINI_API_KEY"])

def summarize_url(url):
    html = requests.get(url).text

    response = client.models.generate_content(
        model="gemini-3.5-flash",
        contents=f"Summarize this webpage in 3 bullets:\n\n{html[:50000]}"
    )

    return response.text

print(summarize_url("https://blog.google/"))

Sau đó, bạn có thể đưa endpoint này vào Apidog để kiểm tra request/response, thêm assertion và chạy regression test mỗi khi chỉnh prompt. Khi workflow ổn định, triển khai lên Cloud Run hoặc nền tảng hosting bạn đang dùng.

Hướng Dẫn Sử Dụng Gemini 3.5 Flash API

Sebastian Petrus — Wed, 20 May 2026 02:15:29 +0000

API Gemini 3.5 Flash ra mắt cùng phiên bản mô hình vào ngày 19 tháng 5 năm 2026. Flash hiện là biến thể duy nhất của dòng 3.5; Pro sẽ ra mắt vào tháng 6. Bài viết này hướng dẫn cách thiết lập Flash từ đầu: lấy API key, gọi request đầu tiên, xử lý đầu vào đa phương thức, streaming, function calling, JSON output và kiểm thử tích hợp bằng Apidog.

Dùng thử Apidog ngay hôm nay

Nếu bạn đã dùng Gemini API trước đây, luồng tích hợp gần như không đổi. Điểm cần thay là tên mô hình: gemini-3.5-flash. Nếu bạn mới bắt đầu, bạn có thể chạy request Flash đầu tiên trong khoảng 10 phút.

Bạn nhận được gì với Gemini 3.5 Flash API

Ba điểm cần nắm trước khi triển khai:

Model name: gemini-3.5-flash
API pattern tương tự các phiên bản Gemini trước: dễ chuyển từ Gemini 3 hoặc Gemini 3.1
Có free tier trên Google AI Studio: khoảng 1.500 request/ngày, không cần thẻ tín dụng

Các khả năng chính của Flash:

Ngữ cảnh đầu vào 1 triệu token, đầu ra 64 nghìn token
Đầu vào văn bản + hình ảnh
Đầu ra văn bản hoặc có cấu trúc
Function calling và tool use gốc
Streaming response
Phù hợp cho truy xuất ngữ cảnh dài, phân tích tài liệu và biểu đồ

Để xem chi tiết chi phí theo token và batch mode, tham khảo hướng dẫn định giá Gemini 3.5 Flash.

Bước 1: Lấy API key cho Gemini 3.5 Flash

Bạn có hai lựa chọn: Google AI Studio cho thử nghiệm/free tier hoặc Vertex AI cho môi trường production.

Cách A: Google AI Studio

Truy cập aistudio.google.com
Đăng nhập bằng tài khoản Google
Chọn Get API key ở thanh điều hướng bên trái
Chọn project có sẵn hoặc tạo project mới
Nhấn Create API key
Sao chép API key và lưu vào biến môi trường

Ví dụ:

export GEMINI_API_KEY="your_api_key_here"

Quy trình này giống với hướng dẫn lấy Gemini API key miễn phí. Key có thể dùng ngay với gemini-3.5-flash.

Cách B: Vertex AI cho production

Nếu bạn cần billing, IAM, audit log và quản trị theo tổ chức, dùng Vertex AI:

Mở Google Cloud Console
Bật Vertex AI API
Tạo service account có quyền aiplatform.user
Tải file credentials JSON
Xác thực bằng một trong hai cách:

gcloud auth application-default login

Hoặc đặt biến môi trường:

export GOOGLE_APPLICATION_CREDENTIALS="/path/to/service-account.json"

Hầu hết team nên bắt đầu bằng AI Studio, sau đó chuyển sang Vertex AI khi cần kiểm soát production.

Bước 2: Cài đặt SDK

Google cung cấp GenAI SDK cho Python, Node.js, Go và Java.

# Python
pip install -U google-genai

# Node.js
npm install @google/genai

# Go
go get google.golang.org/genai

Nếu không muốn dùng SDK, bạn có thể gọi trực tiếp REST API bằng curl.

Bước 3: Gọi request Flash đầu tiên

Python

import os
from google import genai

client = genai.Client(api_key=os.environ["GEMINI_API_KEY"])

response = client.models.generate_content(
    model="gemini-3.5-flash",
    contents="Explain how OAuth 2.0 PKCE flow works in 3 short paragraphs."
)

print(response.text)

Node.js

import { GoogleGenAI } from "@google/genai";

const ai = new GoogleGenAI({ apiKey: process.env.GEMINI_API_KEY });

const response = await ai.models.generateContent({
  model: "gemini-3.5-flash",
  contents: "Explain how OAuth 2.0 PKCE flow works in 3 short paragraphs.",
});

console.log(response.text);

curl

curl "https://generativelanguage.googleapis.com/v1beta/models/gemini-3.5-flash:generateContent" \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "contents": [{
      "parts": [{"text": "Explain how OAuth 2.0 PKCE flow works in 3 short paragraphs."}]
    }]
  }'

Đến đây, bạn đã có request Gemini 3.5 Flash cơ bản. Các phần tiếp theo là những tính năng thường cần khi đưa vào ứng dụng thật.

Streaming response

Streaming giúp UI phản hồi nhanh hơn vì người dùng thấy token xuất hiện dần thay vì chờ toàn bộ kết quả.

Python

stream = client.models.generate_content_stream(
    model="gemini-3.5-flash",
    contents="Write a 5-step tutorial on writing a REST API client in Go."
)

for chunk in stream:
    print(chunk.text, end="", flush=True)

Node.js

const stream = await ai.models.generateContentStream({
  model: "gemini-3.5-flash",
  contents: "Write a 5-step tutorial on writing a REST API client in Go.",
});

for await (const chunk of stream) {
  process.stdout.write(chunk.text);
}

Với REST API, đổi endpoint từ:

:generateContent

thành:

:streamGenerateContent

Đầu vào đa phương thức với Flash

Gemini 3.5 Flash hỗ trợ đầu vào hình ảnh cùng với văn bản. Mẫu phổ biến là trích xuất thông tin từ dashboard, biểu đồ, ảnh chụp màn hình hoặc tài liệu scan.

Python: gửi ảnh từ ổ đĩa

import os
from google import genai
from google.genai import types

client = genai.Client(api_key=os.environ["GEMINI_API_KEY"])

with open("dashboard.png", "rb") as f:
    image_bytes = f.read()

response = client.models.generate_content(
    model="gemini-3.5-flash",
    contents=[
        types.Part.from_bytes(data=image_bytes, mime_type="image/png"),
        "Extract every metric in this dashboard as a JSON object."
    ]
)

print(response.text)

Các MIME type hình ảnh được hỗ trợ:

image/png
image/jpeg
image/webp
image/heic
image/heif

PDF và video cũng có thể xử lý qua types.Part.from_uri().

Function calling và tool use

Function calling cho phép model chọn tool phù hợp, trả về tên hàm và arguments để ứng dụng của bạn thực thi.

Python

from google.genai import types

weather_tool = types.Tool(
    function_declarations=[{
        "name": "get_current_weather",
        "description": "Get the current weather for a city.",
        "parameters": {
            "type": "object",
            "properties": {
                "city": {
                    "type": "string",
                    "description": "City name"
                },
                "unit": {
                    "type": "string",
                    "enum": ["celsius", "fahrenheit"]
                }
            },
            "required": ["city"]
        }
    }]
)

response = client.models.generate_content(
    model="gemini-3.5-flash",
    contents="What's the weather in Singapore right now?",
    config=types.GenerateContentConfig(tools=[weather_tool])
)

for part in response.candidates[0].content.parts:
    if part.function_call:
        print(f"Call: {part.function_call.name}")
        print(f"Args: {dict(part.function_call.args)}")

Luồng xử lý thường là:

Gửi prompt + tool schema cho Flash
Nhận function_call
Thực thi hàm trong backend của bạn
Gửi kết quả hàm lại cho model
Nhận câu trả lời cuối cùng

Mẫu này tương tự cách các team đã dùng với Gemini 3 Flash API.

Đầu ra có cấu trúc bằng JSON mode

Nếu bạn cần output ổn định cho backend, hãy ép Flash trả về JSON bằng response_mime_type và response_schema.

import json
from google.genai import types

response = client.models.generate_content(
    model="gemini-3.5-flash",
    contents="List 3 popular API testing tools with their pricing.",
    config=types.GenerateContentConfig(
        response_mime_type="application/json",
        response_schema={
            "type": "array",
            "items": {
                "type": "object",
                "properties": {
                    "name": {"type": "string"},
                    "price_per_month": {"type": "number"},
                    "free_tier": {"type": "boolean"}
                },
                "required": ["name", "free_tier"]
            }
        }
    )
)

data = json.loads(response.text)
print(data)

Cách này giúp giảm nhu cầu parse bằng regex hoặc viết retry loop chỉ để sửa JSON sai định dạng.

Giá cả tính đến tháng 5 năm 2026

Mức giá pay-as-you-go cho gemini-3.5-flash:

Cấp độ	Đầu vào	Đầu ra
Tiêu chuẩn	~$1.50 / 1 triệu token	~$9.00 / 1 triệu token
Đầu vào được lưu vào bộ nhớ cache	giá giảm	không áp dụng
Chế độ hàng loạt	giảm ~50%	giảm ~50%

Với workload không yêu cầu độ trễ thời gian thực, batch mode của Gemini API có thể giảm khoảng 50% chi phí.

Để xem phân tích chi phí theo workload SaaS, agent loop và token usage thực tế, đọc thêm phân tích giá Gemini 3.5 Flash. Tài liệu chính thức của Google nằm tại Gemini Developer API pricing.

Kiểm thử tích hợp Gemini 3.5 Flash bằng Apidog

Một request SDK chạy được chưa đủ cho production. Bạn vẫn cần kiểm thử:

Streaming chunks
Function calling schema
Payload đa phương thức
Retry khi lỗi
Rate limit
JSON output validation

Apidog giúp bạn kiểm thử toàn bộ API surface của Gemini Flash trong một workspace:

Lưu endpoint Flash thành request: dán URL, thêm header x-goog-api-key, nhấn Send
So sánh nhiều model: đổi gemini-3.5-flash sang gemini-3-flash trong cùng request để so sánh output
Debug streaming response: xem từng chunk khi được trả về
Validate JSON schema: thêm assertion để phát hiện output lệch schema
Mock endpoint: tạo response giả để test downstream code mà không tốn quota
Test agent loop: xâu chuỗi nhiều request và kiểm tra function call giữa các bước

Cách bắt đầu nhanh:

Tải Apidog
Tạo request mới
Dán endpoint Flash:

https://generativelanguage.googleapis.com/v1beta/models/gemini-3.5-flash:generateContent

Thêm header:

x-goog-api-key: {{GEMINI_API_KEY}}
Content-Type: application/json

Dán body từ ví dụ curl
Gửi request và lưu lại làm test case

Xử lý lỗi và rate limit

Các mã lỗi thường gặp:

400: request không hợp lệ, thường do contents sai format hoặc MIME type không hỗ trợ
401: API key không hợp lệ
403: hết quota hoặc model chưa được bật
429: bị rate limit
500/503: lỗi server, nên retry với exponential backoff

Ví dụ retry đơn giản trong Python:

import time
from google import genai

def call_with_retry(client, model, prompt, max_retries=3):
    for attempt in range(max_retries):
        try:
            return client.models.generate_content(
                model=model,
                contents=prompt
            )
        except Exception:
            if attempt == max_retries - 1:
                raise

            sleep_seconds = 2 ** attempt
            time.sleep(sleep_seconds)

Free tier được reset hằng ngày, khoảng 15 request/phút và khoảng 1.500 request/ngày cho Flash. Production quota thường được kiểm soát theo phút và theo ngày.

Nếu workload cần thông lượng cao, hãy cân nhắc:

Batch mode cho tác vụ không realtime
Retry queue
Circuit breaker
Fallback sang Gemini 3 Flash khi chạm giới hạn

Di chuyển từ Gemini 3.1 sang 3.5 Flash

Trong nhiều dự án, thay đổi chính chỉ là model name.

# Trước đây
model = "gemini-3.1-pro"  # hoặc gemini-3.1-flash

# Sau khi chuyển
model = "gemini-3.5-flash"

Sau khi đổi model, nên kiểm tra lại:

Tool schema: đảm bảo arguments vẫn đúng với schema bạn định nghĩa
Streaming UI: Flash có thể trả output nhanh hơn, UI có thể cần throttle
Token budget: giới hạn vẫn là 1M input / 64K output, nhưng output thực tế có thể khác
Safety behavior: các phản hồi từ chối có thể khác ở edge cases
JSON schema validation: chạy lại test để tránh breaking change trong backend

Tham khảo thêm hướng dẫn Gemini 3.1 Pro API nếu bạn đang migrate từ SDK pattern cũ.

Các mẫu triển khai phổ biến

1. Phân tích tài liệu ngữ cảnh dài

from google.genai import types

with open("large_report.pdf", "rb") as f:
    pdf_bytes = f.read()

response = client.models.generate_content(
    model="gemini-3.5-flash",
    contents=[
        types.Part.from_bytes(
            data=pdf_bytes,
            mime_type="application/pdf"
        ),
        "Summarize the financial outlook from this report in 5 bullet points."
    ]
)

print(response.text)

Ngữ cảnh 1 triệu token giúp xử lý tài liệu lớn mà không cần chia nhỏ thủ công trong nhiều trường hợp.

2. Trích xuất dữ liệu từ biểu đồ sang JSON

response = client.models.generate_content(
    model="gemini-3.5-flash",
    contents=[
        types.Part.from_bytes(
            data=open("chart.png", "rb").read(),
            mime_type="image/png"
        ),
        "Return the chart data as JSON with labels, values, and units."
    ],
    config=types.GenerateContentConfig(
        response_mime_type="application/json"
    )
)

chart_data = json.loads(response.text)

Mẫu này hữu ích cho dashboard screenshot, báo cáo vận hành hoặc tài liệu phân tích.

3. Agent loop với function calling

conversation = [
    {
        "role": "user",
        "parts": [{"text": "Book me a flight to Tokyo"}]
    }
]

while True:
    response = client.models.generate_content(
        model="gemini-3.5-flash",
        contents=conversation,
        config=types.GenerateContentConfig(
            tools=[flight_search_tool, booking_tool]
        )
    )

    part = response.candidates[0].content.parts[0]

    if not part.function_call:
        print(part.text)
        break

    result = execute_tool(part.function_call)

    conversation.append({
        "role": "model",
        "parts": [part]
    })

    conversation.append({
        "role": "user",
        "parts": [{"function_response": result}]
    })

Đây là pattern cơ bản để xây dựng agent có khả năng gọi API nội bộ, tra cứu dữ liệu và thực hiện hành động.

Câu hỏi thường gặp

Có free tier cho Gemini 3.5 Flash API không?

Có. Bạn có thể dùng thông qua Google AI Studio với quota hằng ngày khoảng 1.500 request/ngày. Không cần thẻ tín dụng.

Flash có hỗ trợ endpoint tương thích OpenAI không?

Có. Google cung cấp shim tương thích OpenAI tại:

/v1beta/openai/

Bạn có thể trỏ OpenAI SDK đến endpoint này bằng base_url và dùng Gemini API key. Model name vẫn là:

gemini-3.5-flash

Có dùng Flash với LangChain hoặc LlamaIndex được không?

Có. Cả hai đều có tích hợp Gemini. Truyền model name tương ứng:

model="gemini-3.5-flash"

Khi nào Gemini 3.5 Pro ra mắt?

Theo thông báo ra mắt của Google, Gemini 3.5 Pro dự kiến ra mắt vào tháng 6 năm 2026. Trước thời điểm đó, Flash là biến thể 3.5 duy nhất có sẵn.

Kích thước hình ảnh tối đa nên dùng là bao nhiêu?

Khuyến nghị 3072×3072. Ảnh lớn hơn có thể được lấy mẫu lại. Nếu workload tập trung vào OCR, bạn có thể tham khảo thêm quy trình OCR với Gemini 2.0 Flash; pattern triển khai tương tự vẫn áp dụng.

Làm thế nào để test streaming endpoint trong Apidog?

Tạo request với hậu tố endpoint:

:streamGenerateContent

Apidog sẽ hiển thị các SSE chunk khi chúng đến, giúp debug response bị thiếu hoặc bị ngắt giữa chừng.

Xem API log ở đâu?

AI Studio: mục Activity
Vertex AI: Logs Explorer trong Google Cloud Console

Nên xây dựng gì đầu tiên?

Nếu bạn muốn thử Gemini 3.5 Flash trong tuần đầu tiên, bắt đầu với một trong các project nhỏ sau:

PDF Q&A bot: đưa PDF vào context 1 triệu token, hỏi đáp và trả về câu trả lời có trích dẫn
Chart-to-JSON pipeline: gửi ảnh dashboard, trích xuất dữ liệu có cấu trúc
Customer support agent: dùng function calling để đọc CRM hoặc ticket system
Code review assistant: phân tích nhiều file, trả output JSON với severity
Internal search agent: kết hợp long context với tool call đến API nội bộ

Quy trình triển khai nên giữ đơn giản:

Viết prompt nhỏ và rõ
Gọi gemini-3.5-flash bằng SDK hoặc REST
Ép output JSON nếu backend cần dữ liệu có cấu trúc
Thêm retry/backoff cho lỗi 429 và 5xx
Kiểm thử request, streaming và schema bằng Apidog
Đưa vào production sau khi đã có test case ổn định

Gemini Omni là gì? Mô hình video lý luận ưu tiên hàng đầu của Google

Sebastian Petrus — Wed, 20 May 2026 02:04:12 +0000

Blog của Google vừa công bố Gemini Omni, dòng mô hình kết hợp suy luận Gemini với tạo sinh đa phương thức. Biến thể đầu tiên là Gemini Omni Flash: nhận văn bản, hình ảnh, âm thanh hoặc video và tạo đầu ra video. Hiện mô hình đã có trong ứng dụng Gemini, Google Flow, YouTube Shorts và YouTube Create; API cho nhà phát triển dự kiến được triển khai trong vài tuần tới.

Dùng thử Apidog hôm nay

Nếu bạn đang xây dựng workflow API bằng Apidog, có thể bạn đã tích hợp các mô hình văn bản, trình tạo ảnh như Nano Banana 2, hoặc mô hình video như Veo 3.1. Gemini Omni là endpoint tiếp theo nên chuẩn bị sẵn: khác Veo ở chỗ nó không chỉ tạo video từ prompt, mà còn suy luận trước khi tạo.

Tóm tắt nhanh

Gemini Omni Flash hiện được định vị như một mô hình:

Nhận đầu vào: văn bản, hình ảnh, âm thanh, video.
Tạo đầu ra: video ở thời điểm ra mắt.
Đầu ra hình ảnh và âm thanh: được Google nói là sẽ bổ sung sau.
Có mặt trong: ứng dụng Gemini, Google Flow, YouTube Shorts, YouTube Create.
API nhà phát triển và doanh nghiệp: dự kiến trong vài tuần tới.
Watermark: SynthID.

Nếu bạn muốn chuẩn bị trước, việc cần làm ngay là thiết kế abstraction cho model provider, mock response video, và cấu hình sẵn auth trong Apidog để có thể thay endpoint khi API chính thức mở.

Gemini Omni là gì?

Gemini Omni là dòng mô hình tạo sinh mới của Google, được xây trên hướng “suy luận + tạo sinh”. Theo nhóm Google DeepMind, Omni sử dụng kiến thức thế giới của Gemini để suy luận về điều sẽ xảy ra tiếp theo, bao gồm các yếu tố trực quan như trọng lực, động năng hoặc động lực học chất lỏng.

Ví dụ: nếu prompt là “tạo video quả bóng nảy xuống cầu thang”, Omni không chỉ nội suy khung hình. Mô hình sẽ cố gắng suy luận về chuyển động, mất động lượng sau mỗi lần va chạm, rồi tạo video tương ứng.

Điểm khác biệt chính:

Đầu vào đa phương thức bản địa: có thể kết hợp text, image, audio, video trong cùng request.
Tham chiếu nhiều nguồn: dùng ảnh tham chiếu, cảnh mẫu, màu thương hiệu hoặc script để giữ tính nhất quán.
Chỉnh sửa nhiều lượt: tạo clip trước, sau đó yêu cầu “thêm tuyết vào nền” hoặc “đổi mèo thành cáo” mà vẫn giữ phần không liên quan.

Tên “Flash” cho thấy Omni Flash nằm ở lớp tối ưu cho tốc độ và khả dụng rộng, tương tự cách Google phân tầng Gemini 3 Pro và Gemini 3 Flash. Google chưa công bố biến thể Omni lớn hơn. Xem thêm về Gemini 3 Flash nếu bạn đang theo dõi dòng Flash.

Gemini Omni khác Veo 3 và Gemini 3 Pro như thế nào?

Mô hình	Mục đích	Đầu vào	Đầu ra	Suy luận
Gemini 3 Pro	Suy luận văn bản + đa phương thức nặng	Văn bản, hình ảnh, âm thanh, video, mã	Văn bản, mã	Mạnh
Veo 3.1	Tạo video	Văn bản, hình ảnh	Video	Hạn chế, chủ yếu theo prompt
Gemini Omni Flash	Suy luận + tạo sinh video	Văn bản, hình ảnh, âm thanh, video	Video	Bản địa, áp dụng vào quá trình tạo

Veo 3 vẫn phù hợp khi bạn cần video đơn cảnh có chất lượng cao và prompt rõ ràng. Bạn có thể xem thêm trong hướng dẫn API Veo 3 và bài về Veo 3.1.

Omni phù hợp hơn khi:

Prompt cần được diễn giải.
Người dùng muốn chỉnh sửa qua hội thoại.
Đầu vào gồm nhiều loại dữ liệu: ảnh sản phẩm, audio, video tham chiếu, script.
Bạn cần model lập kế hoạch trước khi tạo cảnh.

Với tác vụ văn bản thuần túy, Gemini 3 Pro vẫn là lựa chọn hợp lý hơn. Với tạo video thuần túy, Veo 3.1 vẫn là baseline ổn định. Omni nên được xem như lựa chọn cho workflow sáng tạo có nhiều vòng lặp.

Hiện tại có thể dùng Gemini Omni ở đâu?

Giao diện	Chi phí	Truy cập
YouTube Shorts	Miễn phí	Nhà sáng tạo trên nền tảng
YouTube Create	Miễn phí	Nhà sáng tạo di động
Ứng dụng Gemini	Trả phí	Google AI Plus / Pro / Ultra
Google Flow	Trả phí	Google AI Plus / Pro / Ultra
API nhà phát triển	Chưa công bố	Trong vài tuần tới
API doanh nghiệp	Chưa công bố	Trong vài tuần tới

Mọi video do Omni tạo ra đều có watermark SynthID. Watermark này vô hình với người xem, nhưng có thể được công cụ của Google đọc để xác minh nguồn gốc nội dung.

Google cũng giới thiệu tính năng Avatars, cho phép tạo phiên bản kỹ thuật số có giọng nói riêng. Với API, Google chưa công bố chi tiết quy trình đồng ý và xác minh. Nếu bạn định xây tính năng avatar, nên thiết kế trước lớp kiểm soát consent thay vì chờ đến khi API mở.

Cách hiểu “suy luận + tạo sinh” bằng ví dụ

Prompt:

Cho tôi xem một ly nước bị đổ khỏi mép bàn và rơi xuống sàn gỗ.

Một mô hình video thuần túy sẽ tạo chuỗi khung hình “trông giống” ly nước rơi. Một mô hình có suy luận sẽ cần xử lý các câu hỏi như:

Khi trọng tâm vượt khỏi mép bàn, ly nghiêng nhanh thế nào?
Nước tràn ra trước hay sau khi ly chạm sàn?
Ly vỡ, nảy hay lăn?
Chất lỏng văng theo hướng nào?
Chuyển động có hợp lý theo trọng lực không?

Omni không phải engine mô phỏng vật lý. Nó không thay thế Houdini, Blender, pipeline VFX hay editor phi tuyến tính. Nhưng mục tiêu của nó là tạo kết quả “hợp lý về mặt trực giác” mà không cần prompt quá chi tiết từng frame.

Bạn sẽ thấy lợi ích rõ nhất ở:

Quỹ đạo: vật rơi, nảy, trượt hợp lý hơn.
Vật liệu: nước, vải, khói, tóc có chuyển động tự nhiên hơn.
Va chạm: phản ứng khi vật thể tiếp xúc ít bị “ảo” hơn.

Chuẩn bị API trước khi Gemini Omni mở

Google chưa công bố endpoint, giá, rate limit hoặc region. Tuy nhiên, dựa trên cách Gemini 3 được triển khai, nhiều khả năng developer sẽ gặp Omni qua Google AI Studio và Vertex AI. Xem thêm hướng dẫn Gemini 3 API.

Những gì nên chuẩn bị ngay:

Không hard-code model name

VIDEO_MODEL=gemini-omni-flash
VIDEO_PROVIDER=google

Bọc provider sau một interface nội bộ

export interface VideoGenerationInput {
  prompt: string;
  images?: string[];
  audio?: string;
  videoRefs?: string[];
  durationSeconds?: number;
}

export interface VideoGenerationResult {
  id: string;
  status: "queued" | "running" | "succeeded" | "failed";
  videoUrl?: string;
  error?: string;
}

export interface VideoModelProvider {
  generate(input: VideoGenerationInput): Promise<VideoGenerationResult>;
  getStatus(id: string): Promise<VideoGenerationResult>;
}

Cho phép swap Veo, Omni hoặc provider khác

function createVideoProvider(provider: string): VideoModelProvider {
  switch (provider) {
    case "google-veo":
      return new VeoProvider();
    case "google-omni":
      return new OmniProvider();
    default:
      throw new Error(`Unsupported provider: ${provider}`);
  }
}

Mock response trước khi gọi API thật

Video generation thường chậm và tốn quota. Dùng mock để frontend, job queue, retry logic và UI trạng thái chạy được trước khi API có thật.

Bạn có thể tải Apidog, import schema Gemini/Veo hiện có, rồi tạo mock endpoint cho Omni. Apidog hỗ trợ auth, environment variables và mock response, giúp bạn kiểm thử client mà chưa cần endpoint thật.

Thiết kế endpoint Omni trong Apidog

Khi API Omni phát hành, workspace Apidog nên có ba phần.

1. Auth

Chuẩn bị cả hai kiểu auth có thể gặp:

Google AI Studio: header x-goog-api-key
Vertex AI: OAuth hoặc service account

Trong Apidog, tạo environment riêng:

GEMINI_API_KEY={{your_api_key}}
GOOGLE_PROJECT_ID={{project_id}}
GOOGLE_LOCATION={{location}}
VIDEO_MODEL=gemini-omni-flash

2. Schema request/response

Nếu Google phát hành OpenAPI spec, import trực tiếp vào Apidog. Nếu chưa có, bạn có thể phác thảo schema dựa trên Gemini multimodal API hiện tại.

Ví dụ request dự kiến:

curl -X POST https://generativelanguage.googleapis.com/v1beta/models/gemini-omni-flash:generateContent \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "contents": [{
      "parts": [
        {
          "text": "Generate a 6s product shot of the attached phone rotating on a white background"
        },
        {
          "inline_data": {
            "mime_type": "image/jpeg",
            "data": "<base64-image>"
          }
        }
      ]
    }],
    "generationConfig": {
      "responseMimeType": "video/mp4",
      "durationSeconds": 6
    }
  }'

Lưu ý: đây chỉ là hình dạng suy đoán dựa trên API Gemini đa phương thức hiện có. Google có thể đổi tên field khi Omni API ra mắt.

3. Mock response

Tạo response mẫu để client có thể xử lý cả trường hợp synchronous và asynchronous.

Ví dụ response đồng bộ:

{
  "id": "vid_omni_mock_001",
  "status": "succeeded",
  "videoUrl": "https://example.com/mock/generated-video.mp4",
  "mimeType": "video/mp4",
  "durationSeconds": 6,
  "watermark": {
    "type": "SynthID",
    "present": true
  }
}

Ví dụ response async:

{
  "id": "job_omni_mock_001",
  "status": "queued",
  "pollUrl": "/v1/video/jobs/job_omni_mock_001"
}

Trong Apidog, thêm test assertions:

pm.test("response has job id", function () {
  pm.expect(pm.response.json().id).to.exist;
});

pm.test("status is valid", function () {
  const status = pm.response.json().status;
  pm.expect(["queued", "running", "succeeded", "failed"]).to.include(status);
});

Mô hình mock này cũng phù hợp với cách chuẩn bị được mô tả trong hướng dẫn API văn bản thành video.

Omni so với Sora 2, Veo 3.1 và Nano Banana 2

Mô hình	Nhà cung cấp	Suy luận	Đầu vào đa phương thức	Chỉnh sửa	Watermark
Gemini Omni Flash	Google	Bản địa	Văn bản, hình ảnh, âm thanh, video	Nhiều lượt	SynthID
Veo 3.1	Google	Hạn chế	Văn bản, hình ảnh	Chủ yếu prompt lại	SynthID
Sora 2	OpenAI	Một phần	Văn bản, hình ảnh	Chủ yếu prompt lại	C2PA
Nano Banana 2	Google	Một phần	Văn bản, hình ảnh	Hạn chế	SynthID

Veo 3.1 vẫn là lựa chọn ổn định nếu bạn cần chất lượng video đơn cảnh. Sora 2 được OpenAI định vị mạnh về mô phỏng thế giới; xem thêm bài Sora 2. Omni nổi bật ở chỉnh sửa nhiều lượt và đầu vào đa phương thức, đặc biệt là audio/video reference.

Nếu đang chọn model cho production hôm nay, Veo 3.1 + mock layer trong Apidog là phương án ít rủi ro hơn. Nếu đang xây sản phẩm nơi người dùng nói chuyện với model để chỉnh video, Omni đáng để chuẩn bị. Xem thêm bảng so sánh mô hình video.

Use case thực tế

Một số workflow phù hợp với Omni:

Marketing sản phẩm: tạo video demo từ ảnh sản phẩm, script và guideline thương hiệu.
Giáo dục: minh họa hiện tượng vật lý bằng video có chuyển động hợp lý.
Hỗ trợ khách hàng: tạo video hướng dẫn ngắn với avatar hoặc nhân vật thương hiệu.
Tin cậy và an toàn: kiểm tra SynthID trong pipeline moderation.
Prototype game/app: tạo cinematic sequence trước khi có asset 3D hoàn chỉnh.

Checklist triển khai cho developer

Trước khi API Gemini Omni ra mắt, nên hoàn tất các việc sau:

[ ] Tạo abstraction VideoModelProvider.
[ ] Không hard-code tên model.
[ ] Thêm environment cho GEMINI_API_KEY, VIDEO_MODEL, VIDEO_PROVIDER.
[ ] Mock endpoint generate video trong Apidog.
[ ] Thiết kế polling job nếu API chạy async.
[ ] Cache output theo prompt + input reference.
[ ] Thêm retry logic cho lỗi quota, timeout, policy.
[ ] Không block main thread khi tạo video.
[ ] Chuẩn bị bước kiểm tra SynthID nếu nội dung được publish.
[ ] Giữ fallback sang Veo 3.1 hoặc provider khác.

Một lỗi phổ biến: xem Omni như trình chỉnh sửa video hoàn chỉnh. Nó là model tạo sinh, không phải NLE. Bạn vẫn cần bước hậu kỳ trong DaVinci, Premiere hoặc Google Flow để cắt, chỉnh màu và trộn âm thanh.

FAQ

Gemini Omni là gì?

Gemini Omni là dòng mô hình mới của Google, kết hợp suy luận Gemini với tạo sinh đa phương thức. Biến thể đầu tiên là Gemini Omni Flash, nhận văn bản, hình ảnh, âm thanh và video, rồi tạo đầu ra video.

Gemini Omni có giống Veo 3 không?

Không. Veo là mô hình tạo video chuyên dụng. Omni là mô hình suy luận có khả năng tạo video, hỗ trợ prompt phức tạp hơn, chỉnh sửa nhiều lượt và đầu vào đa phương thức phong phú hơn. Xem thêm hướng dẫn API Veo 3.

Khi nào API Gemini Omni ra mắt?

Google nói API nhà phát triển và doanh nghiệp sẽ được triển khai “trong vài tuần tới” kể từ thông báo tháng 5 năm 2026. Chưa có ngày cụ thể.

Gemini Omni có giá bao nhiêu?

Với người dùng cuối, Omni miễn phí trong YouTube Shorts và YouTube Create, đồng thời có trong các gói Google AI Plus, Pro và Ultra. Giá API chưa được công bố.

Gemini Omni có tạo âm thanh không?

Chưa. Ở thời điểm ra mắt, đầu ra là video. Google nói đầu ra âm thanh và hình ảnh sẽ đến sau, nhưng chưa có mốc thời gian cụ thể.

Gemini Omni có watermark không?

Có. Video do Omni tạo ra có watermark SynthID, có thể xác minh qua ứng dụng Gemini, Gemini trong Chrome và Google Search.

Apidog có hỗ trợ Gemini Omni API không?

Có thể chuẩn bị theo cùng cách bạn đang dùng Apidog cho Gemini 3, Veo 3 hoặc Nano Banana. Khi Google công bố OpenAPI spec, bạn có thể import trực tiếp. Trước đó, hãy mock schema và response để kiểm thử client.

Tổng kết

Gemini Omni không chỉ là một phiên bản Veo nhanh hơn. Điểm đáng chú ý là mô hình suy luận trước khi tạo video, nhận nhiều loại đầu vào và hỗ trợ chỉnh sửa qua nhiều lượt hội thoại.

Nếu bạn đang xây sản phẩm với video generation, hãy làm ngay 5 việc:

Theo dõi Google AI Studio và Vertex AI để biết khi nào Omni Flash có endpoint.
Cấu hình sẵn auth và environment trong Apidog.
Mock request/response Omni để frontend và backend có thể phát triển trước.
Thiết kế provider abstraction để swap Veo, Omni hoặc model khác.
Lập kế hoạch cache, async job và xác minh SynthID.

Khi API chính thức mở, nhóm đã chuẩn bị schema, mock và integration test sẽ có thể thử nghiệm trong vài giờ thay vì bắt đầu đọc tài liệu từ đầu.

Claude Managed Agents vs Agent SDK (2026): Nên Chọn Cái Nào?

Sebastian Petrus — Tue, 19 May 2026 10:30:39 +0000

Bạn đã quyết định triển khai một tác nhân AI sản xuất trên Claude. Ngã rẽ đầu tiên không nằm ở prompt, mà ở runtime: để Anthropic chạy vòng lặp tác nhân và sandbox bằng Claude Managed Agents, hay tự giữ vòng lặp trong dịch vụ của bạn bằng Claude Agent SDK. Hai lựa chọn này có thể giống nhau trong demo, nhưng sẽ kéo theo kiến trúc, chi phí, vận hành và kiểm soát dữ liệu rất khác nhau.

Dùng thử Apidog ngay hôm nay

TL;DR

Chọn Claude Managed Agents nếu bạn muốn Anthropic lưu trữ vòng lặp tác nhân, sandbox và trạng thái phiên cho các tác vụ dài hoặc không đồng bộ.

Chọn Claude Agent SDK nếu bạn cần vòng lặp chạy trong hạ tầng của mình, kiểm soát công cụ, dữ liệu, quyền hạn và chi phí vận hành.

Cả hai đều hỗ trợ MCP và các mô hình Claude.

Bối cảnh: bạn đang chọn runtime, không chỉ chọn SDK

Vào năm 2026, “xây dựng tác nhân AI” không còn đơn giản là bọc một vòng while quanh API chat completion. Với Claude, bạn có hai cách chính để chạy tác nhân trong production:

Claude Managed Agents: Anthropic chạy vòng lặp tác nhân, sandbox và trạng thái phiên. Ứng dụng của bạn gửi sự kiện và nhận stream kết quả.
Claude Agent SDK: bạn cài thư viện Python hoặc TypeScript, rồi chạy vòng lặp tác nhân trong chính process và hạ tầng của bạn.

Cùng một lớp mô hình bên dưới, nhưng hợp đồng vận hành khác nhau:

Dữ liệu nằm ở đâu?
Ai vận hành sandbox?
Ai xử lý khi tool call bị treo lúc 2 giờ sáng?
Chi phí được tính theo runtime được quản lý hay compute tự vận hành?

Hầu hết tác nhân production đều làm việc bằng cách gọi API: hoàn tiền, tạo ticket, tra cứu inventory, đọc log, gọi endpoint nội bộ. Vì vậy, độ tin cậy của tác nhân phụ thuộc rất nhiều vào API và tool mà nó gọi.

Trước khi chọn runtime, bạn nên thiết kế, mock và kiểm thử các endpoint đó. Một nền tảng như Apidog phù hợp cho phần này: mock dependency, chạy contract test, kiểm thử MCP server và quan sát request/response mà tác nhân tạo ra. Nếu muốn đào sâu riêng về hướng được lưu trữ, xem thêm hướng dẫn Claude Managed Agents.

Claude Managed Agents là gì?

Claude Managed Agents là runtime tác nhân được Anthropic quản lý. Thay vì tự viết vòng lặp tác nhân, sandbox và lớp thực thi tool, bạn định nghĩa agent rồi để Anthropic chạy nó.

Managed Agents được ra mắt dưới dạng public beta vào tháng 4 năm 2026 và yêu cầu beta header:

anthropic-beta: managed-agents-2026-04-01

SDK có thể thiết lập header này cho bạn.

Managed Agents xoay quanh bốn khái niệm:

Agent: model, system prompt, tool, MCP server và skill. Bạn tạo một lần, sau đó tham chiếu bằng ID.
Environment: template container với package cài sẵn như Python, Node.js, Go và rule truy cập mạng.
Session: một agent đang chạy trong một environment. Session có filesystem và lịch sử hội thoại liên tục.
Events: thông điệp giữa ứng dụng và agent, ví dụ user turn, tool result, status update. Events được stream qua SSE và được lưu phía server.

Luồng triển khai điển hình:

Tạo agent.
Cấu hình environment.
Bắt đầu session.
Gửi user message dưới dạng event.
Nhận stream phản hồi.
Gửi thêm event hoặc interrupt nếu cần đổi hướng.

Managed Agents cung cấp sẵn một số tool:

Bash
Đọc/ghi/chỉnh sửa file
Glob, grep
Web search và web retrieval
Kết nối MCP server

Theo Anthropic, lựa chọn này phù hợp với các tác vụ:

Chạy vài phút đến vài giờ
Có nhiều tool call
Cần sandbox cloud an toàn
Cần trạng thái phiên tồn tại qua nhiều interaction
Muốn giảm phần hạ tầng tự vận hành

Managed Agents cũng có trên Claude Platform on AWS, nhưng cần kiểm tra khác biệt về tính năng và session behavior nếu bạn bị ràng buộc bởi một cloud cụ thể.

Hai điểm cần nhớ:

Custom tool vẫn do ứng dụng của bạn thực thi. Claude quyết định gọi tool, nhưng app của bạn chạy tool và trả kết quả qua event stream.
Một số tính năng như result và multi-agent có thể nằm sau research preview riêng. Đừng giả định mọi tính năng đều bật mặc định.

Để hiểu mẫu kiến trúc tổng quát hơn, xem bài kiến trúc AI tác nhân.

Claude Agent SDK là gì?

Claude Agent SDK là thư viện Python/TypeScript cho phép bạn chạy vòng lặp tác nhân trong process của mình. Trước đây nó được gọi là Claude Code SDK; việc đổi tên phản ánh phạm vi rộng hơn ngoài coding task.

Cài đặt:

pip install claude-agent-sdk

hoặc:

npm install @anthropic-ai/claude-agent-sdk

Một agent tối thiểu trong Python có dạng:

from claude_agent_sdk import query, ClaudeAgentOptions

options = ClaudeAgentOptions(
    allowed_tools=["Read", "Write", "Edit", "Bash", "Grep"]
)

async for message in query(
    prompt="Đọc project này và đề xuất các bước refactor an toàn.",
    options=options,
):
    print(message)

Khác với Client SDK thông thường, bạn không cần tự viết vòng lặp kiểu:

while response.stop_reason == "tool_use":
    run_tool()
    send_tool_result()

Agent SDK đã đóng gói vòng lặp, quản lý context và tool execution.

Các thành phần quan trọng:

Built-in tools: Read, Write, Edit, Bash, Glob, Grep, WebSearch, WebFetch, Monitor, AskUserQuestion.
Hooks: callback tại các điểm như PreToolUse, PostToolUse, Stop, SessionStart, SessionEnd, UserPromptSubmit. Dùng để audit, validate, log hoặc chặn hành vi.
Subagents: tạo agent chuyên biệt cho task phụ. Message có parent_tool_use_id để trace.
MCP: kết nối database, browser và API qua Model Context Protocol.
Permissions: phê duyệt trước tool an toàn, chặn tool nguy hiểm hoặc yêu cầu approval cho hành động nhạy cảm.
Sessions: lưu session ID, resume sau này hoặc branch để thử hướng khác. Trạng thái là JSONL trên filesystem của bạn.

Vì vòng lặp chạy trong hạ tầng của bạn, SDK có thể đọc cấu hình Claude Code như:

.claude/skills/
slash command
CLAUDE.md
plugin

SDK hỗ trợ xác thực qua Anthropic API, Amazon Bedrock, Claude Platform on AWS, Google Vertex AI và Azure AI Foundry. Điều này hữu ích nếu bạn muốn inference đi qua hợp đồng cloud hiện có.

Nếu muốn bắt đầu bằng ví dụ thực hành, xem hướng dẫn thiết lập Claude Agent SDK với một gói Claude và bài xây dựng Claude Code của riêng bạn.

Lưu ý về billing: từ ngày 15 tháng 6 năm 2026, việc sử dụng Agent SDK và claude -p trên các gói đăng ký sẽ lấy từ một khoản tín dụng Agent SDK hàng tháng riêng, khác với giới hạn dùng Claude tương tác. Hãy kiểm tra điều khoản hiện tại trực tiếp từ Anthropic trước khi dự báo chi phí.

So sánh nhanh: Managed Agents vs Agent SDK

Xem hàng chi phí như định hướng. Luôn xác nhận với trang giá của Anthropic và tài liệu Managed Agents.

Tiêu chí	Claude Managed Agents	Claude Agent SDK
Nơi vòng lặp chạy	Hạ tầng do Anthropic quản lý	Process và hạ tầng của bạn
Giao diện	REST API + SSE event stream	Thư viện Python hoặc TypeScript
Kiểm soát vòng lặp	Cấu hình, điều khiển qua event	Kiểm soát bằng code, hook, permission
Chi phí	Token Claude + phí runtime theo giờ session hoạt động	Token Claude + compute bạn tự vận hành
Ops burden	Thấp hơn: không vận hành sandbox/session store/scaling	Cao hơn: bạn vận hành service, sandbox, monitoring
Observability	Event log được lưu và có thể lấy lại	Bạn tự instrument bằng hook/log/tracing
Latency profile	Phù hợp tác vụ async dài	Kiểm soát gần dữ liệu và service nội bộ
Data residency	Sandbox và session state ở Anthropic hoặc AWS option	File, state và tool execution ở hạ tầng của bạn
Custom tool	Claude yêu cầu, app của bạn thực thi qua event	Function Python/TypeScript trong process
Phù hợp nhất	Agent async dài, muốn giảm hạ tầng	Agent cần kiểm soát dữ liệu, quyền hạn, VPC

Chi phí

Managed Agents tính token Claude tiêu chuẩn cộng phí runtime cho thời gian session hoạt động. Nếu agent “suy nghĩ” trong một giờ, bạn có thể trả phí runtime cho khoảng thời gian đó.

Agent SDK không có phí runtime Anthropic theo giờ, nhưng bạn trả tiền cho:

server
autoscaling
sandbox
queue/worker
monitoring
on-call

Rẻ hơn trên bảng giá không nhất thiết rẻ hơn khi tính cả vận hành.

Gánh nặng vận hành

Managed Agents loại bỏ nhiều phần khỏi trách nhiệm của bạn:

sandbox
session store
scaling
event history

SDK trao lại cho bạn toàn quyền kiểm soát, phù hợp khi agent phải chạy trong VPC cạnh database riêng tư hoặc service nội bộ.

Nơi lưu trú dữ liệu

Với SDK, tool execution và session state nằm trong hạ tầng của bạn; chỉ inference request đi đến Claude.

Với Managed Agents, sandbox và event log nằm trong môi trường của Anthropic hoặc AWS option. Với dữ liệu regulated, đây thường là tiêu chí quyết định.

Observability

Managed Agents cho bạn event log được lưu sẵn.

SDK cho bạn hook để tự đưa event vào stack hiện có:

async def pre_tool_use_hook(context):
    tool = context.tool_name
    args = context.tool_input

    audit_log.write({
        "event": "pre_tool_use",
        "tool": tool,
        "args": args,
        "session_id": context.session_id,
    })

    if tool == "refund_payment" and args["amount"] > 500:
        raise PermissionError("Refund vượt ngưỡng cần human approval")

Cách kiểm thử API mà agent gọi

Dù chọn Managed Agents hay Agent SDK, agent chỉ đáng tin cậy bằng các API và MCP server mà nó gọi.

Một agent hoàn tiền có reasoning tốt nhưng gọi endpoint thanh toán không ổn định thì vẫn là agent không ổn định.

Bạn nên kiểm thử ba lớp sau trước khi production.

1. Contract API

Mọi tool mà agent gọi đều là API có schema. Hãy mock endpoint và xác nhận request/response shape.

Ví dụ, agent hoàn tiền có thể kỳ vọng endpoint:

POST /refunds
Content-Type: application/json

Request:

{
  "transaction_id": "txn_123",
  "amount": 49.99,
  "reason": "duplicate_charge"
}

Response:

{
  "refund_id": "ref_456",
  "status": "pending"
}

Nếu backend đổi refund_id thành id, agent có thể hỏng trong production. Contract test nên bắt lỗi này trước.

Với Apidog, bạn có thể mock service thanh toán hoặc ticketing, định nghĩa schema và chạy contract test theo lịch. Xem thêm hướng dẫn cách kiểm thử các tác nhân AI gọi API.

2. MCP server

Cả Managed Agents và Agent SDK đều có thể dùng MCP để kết nối tool bên ngoài. MCP server cũng là một service cần test:

Tool có được liệt kê đúng không?
Input schema có ổn định không?
Output có cấu trúc không?
Timeout được xử lý thế nào?
Error path có trả JSON thay vì plain text không?

Hãy kiểm thử MCP server trực tiếp trước khi gắn vào agent. Xem hướng dẫn kiểm thử máy chủ MCP với Apidog. Apidog cũng có AI agent và A2A debugger để quan sát request/response do agent tạo ra.

3. Hành vi request của agent

Agent gọi API khác người dùng:

retry liên tục
gọi cùng endpoint nhiều lần trong một vòng reasoning
đọc partial data rồi gọi lại
tạo request gần đúng nhưng sai schema
gây “retry storm” khi timeout

Hãy replay traffic agent tạo ra đối với mock trước khi gọi service thật. Đây là nơi debugger request trực tiếp có giá trị: bạn phát hiện storm trong staging thay vì trong incident call.

Bạn có thể Tải xuống Apidog để mock dependency, chạy contract test và debug luồng request của agent.

Khung ra quyết định

Trả lời các câu hỏi sau theo thứ tự. Câu “có” mạnh đầu tiên thường chỉ ra lựa chọn phù hợp.

Chọn Claude Managed Agents nếu

Agent chạy dài hoặc async, từ vài phút đến vài giờ.
Bạn không muốn vận hành task runner, sandbox và session store.
Nhóm nhỏ, nhân sự vận hành là giới hạn chính.
Bạn muốn event log được lưu sẵn.
Data posture cho phép sandbox và session state nằm trong môi trường Anthropic hoặc AWS.
Bạn chấp nhận trạng thái beta và một số tính năng cần research preview.

Chọn Claude Agent SDK nếu

Agent phải chạy trong VPC của bạn.
Agent cần truy cập database hoặc service nội bộ không public.
Session state không được rời khỏi hạ tầng công ty.
Bạn cần hook để audit, policy, approval hoặc chặn tool.
Bạn cần custom permission chi tiết.
Bạn muốn inference đi qua Bedrock, Vertex hoặc Azure contract hiện có.
Bạn đang prototype local và muốn agent thao tác trực tiếp trên filesystem.

Lộ trình phổ biến

Một cách làm thực tế:

Prototype local bằng Agent SDK.
Xác định tool, permission và API contract.
Mock dependency và chạy test.
Nếu workload async dài và yêu cầu data cho phép, chuyển sang Managed Agents cho production.
Nếu cần VPC/data residency, giữ Agent SDK và đầu tư vào vận hành.

Việc chuyển từ SDK sang Managed Agents không phải chỉ là đổi config. Bạn sẽ thay đổi interface, cách custom tool được thực thi và nơi lưu session state. Hãy coi đó là một migration project.

Nếu bạn cũng so sánh mô hình hoặc coding agent, xem bài so sánh Claude vs Codex năm 2026.

Trường hợp sử dụng thực tế

1. Agent hoàn tiền thanh toán

Một nhóm fintech muốn agent xử lý yêu cầu hoàn tiền:

Đọc ticket.
Tra cứu giao dịch.
Kiểm tra policy hoàn tiền.
Gọi payment API.
Ghi tóm tắt vào ticket.

Vì liên quan đến tiền, mọi API call cần contract test và audit log.

Lựa chọn phù hợp: Claude Agent SDK.

Lý do:

Agent nên chạy trong VPC cạnh service thanh toán.
Session state không nên rời khỏi hạ tầng công ty.
Hook PreToolUse có thể enforce approval cho refund vượt ngưỡng.

Ví dụ policy hook:

async def pre_tool_use(context):
    if context.tool_name == "create_refund":
        amount = context.tool_input["amount"]

        if amount > 500:
            return {
                "action": "require_approval",
                "reason": "Refund vượt ngưỡng 500"
            }

    return {"action": "allow"}

Trước khi launch, nhóm nên:

mock payment API trong Apidog
viết contract test cho refund và lookup
replay ticket lịch sử
kiểm tra agent có retry sai sau lỗi 504 hay không

Một lỗi phổ biến: refund thực tế đã thành công, nhưng agent retry vì nhận timeout. Đây là kiểu lỗi phải bắt bằng test trước production.

2. Agent phân loại ticket hỗ trợ async

Một công ty SaaS nhận hàng ngàn ticket mỗi ngày và muốn agent:

Phân loại ticket.
Kéo log liên quan.
Soạn phản hồi.
Resolve hoặc escalate.

Mỗi ticket mất vài phút, chạy liên tục cả ngày, dữ liệu có độ nhạy thấp.

Lựa chọn phù hợp: Claude Managed Agents.

Lý do:

Workload async dài.
Nhóm không muốn tự chạy worker autoscaling.
Event log được lưu sẵn giúp trace theo từng ticket.
Hạ tầng quản lý session và sandbox được giảm đáng kể.

Tuy nhiên, API correctness vẫn là trách nhiệm của bạn. Nên mock logging API và MCP server ticketing trong Apidog để schema change không âm thầm làm giảm chất lượng phân loại.

3. Agent vận hành dữ liệu nội bộ sau firewall

Một platform team muốn agent xử lý yêu cầu nội bộ như:

“Khôi phục các phân vùng ETL bị lỗi ngày hôm qua.”

Agent cần:

Query job API nội bộ.
Chạy script khắc phục.
Báo cáo trạng thái.
Ghi audit log.

Các API không public internet và dữ liệu nhạy cảm.

Lựa chọn phù hợp: Claude Agent SDK.

Lý do:

Agent phải chạy nơi có thể truy cập service riêng tư.
Session state không được nằm trong sandbox bên thứ ba.
Hook SDK có thể ghi mọi lệnh vào audit pipeline hiện có.
MCP server nội bộ có thể được kiểm thử riêng trước khi kết nối agent.

Đây là trường hợp “chạy trong process của bạn” không còn là sở thích, mà là yêu cầu. Xem thêm bài các tác nhân AI là người tiêu dùng API mới.

Checklist triển khai

Dùng checklist này trước khi chọn runtime:

[ ] Agent có cần chạy trong VPC không?
[ ] Session state có được phép nằm ngoài hạ tầng của bạn không?
[ ] Tác vụ chạy vài giây, vài phút hay vài giờ?
[ ] Bạn có đội vận hành sandbox/worker không?
[ ] Bạn cần hook approval trước tool call không?
[ ] Bạn cần audit log theo từng tool call không?
[ ] Các API mà agent gọi đã có schema rõ ràng chưa?
[ ] MCP server đã được test riêng chưa?
[ ] Bạn đã mô phỏng timeout, retry và partial failure chưa?
[ ] Bạn đã xác nhận pricing và trạng thái beta từ nguồn chính thức chưa?

Kết luận

Quyết định giữa Managed Agents và Agent SDK thực chất là quyết định về vận hành và quản trị dữ liệu.

Ghi nhớ các điểm chính:

Managed Agents lưu trữ vòng lặp và sandbox; SDK chạy chúng trong process của bạn.
Chi phí là mô hình vận hành, không chỉ là giá token.
Data residency thường quyết định lựa chọn.
Nhóm nhỏ thường hưởng lợi nhiều từ runtime được quản lý.
Agent production cần test API và MCP dependency nghiêm túc.
Prototype bằng SDK rồi chuyển sang Managed Agents là hợp lý, nhưng migration không miễn phí.
Luôn kiểm tra pricing và beta status tại nguồn chính thức.

Bước tiếp theo: trước khi kết nối agent với bất kỳ hệ thống customer-facing nào, hãy đưa API và MCP dependency vào kiểm thử. Tải xuống Apidog để mock endpoint, chạy contract test và debug request thực tế của agent.

Câu hỏi thường gặp

Sự khác biệt cốt lõi giữa Claude Managed Agents và Claude Agent SDK là gì?

Managed Agents là REST API được lưu trữ, nơi Anthropic chạy vòng lặp tác nhân và sandbox theo session. Bạn gửi event và nhận stream kết quả. Agent SDK là thư viện Python/TypeScript chạy vòng lặp trong process và hạ tầng của bạn.

Claude Agent SDK có giống Claude Code SDK cũ không?

Có. Claude Code SDK đã được đổi tên thành Claude Agent SDK để phản ánh phạm vi rộng hơn ngoài coding task. Vòng lặp tác nhân, built-in tool và quản lý context là cùng cơ chế cung cấp sức mạnh cho Claude Code.

Tùy chọn nào rẻ hơn?

Phụ thuộc workload. Managed Agents tính token Claude cộng phí runtime cho thời gian session hoạt động. SDK không có phí runtime Anthropic theo giờ, nhưng bạn trả compute và vận hành. Luôn xác nhận trên trang giá của Anthropic.

Tôi có thể dùng MCP server với cả hai không?

Có. Cả hai đều hỗ trợ Model Context Protocol. Vì vậy, bạn nên test MCP server trước khi kết nối với agent. Xem hướng dẫn kiểm thử máy chủ MCP với Apidog.

Làm thế nào để giữ dữ liệu khách hàng không nằm trong hạ tầng Anthropic?

Dùng Agent SDK và chạy vòng lặp trong môi trường của bạn. Với SDK, tool execution và session state nằm trên hạ tầng của bạn; chỉ inference request đi đến Claude. Với Managed Agents, sandbox và event log nằm trong môi trường Anthropic hoặc AWS option.

Claude Managed Agents đã sẵn sàng cho production chưa?

Managed Agents được ra mắt dưới dạng public beta vào tháng 4 năm 2026 và yêu cầu header managed-agents-2026-04-01. Một số tính năng có thể cần research preview riêng. Hãy kiểm tra tài liệu hiện tại trước khi triển khai production.

Làm thế nào để kiểm thử agent trước khi nó gọi API thật?

Mock mọi API và MCP server mà agent gọi, viết contract test cho request/response schema, rồi replay traffic thực tế của agent đối với mock. Apidog hỗ trợ mock, contract test, AI agent và A2A debugger. Xem hướng dẫn cách kiểm thử các tác nhân AI gọi API.

Tôi có thể bắt đầu với một lựa chọn rồi chuyển sang lựa chọn khác không?

Có. Một lộ trình phổ biến là prototype bằng Agent SDK local rồi chuyển sang Managed Agents nếu workload production phù hợp. Nhưng đây không phải đổi config đơn giản: interface khác nhau, custom tool execution khác nhau và session state nằm ở nơi khác. Hãy lập kế hoạch như một migration project.

So sánh Cursor Composer 2.5 với Opus 4.7 với GPT-5.5: Nên Dùng Mô Hình Lập Trình Nào?

Sebastian Petrus — Tue, 19 May 2026 02:28:53 +0000

Tuyên bố của Cursor về Composer 2.5 khá rõ: chất lượng mã hóa gần nhóm dẫn đầu với chi phí khoảng một phần mười. Để kiểm tra tuyên bố đó theo góc nhìn triển khai thực tế, bài viết này so sánh Composer 2.5 với Claude Opus 4.7 và GPT-5.5 trên bốn tiêu chí mà developer quan tâm: benchmark, tốc độ, chi phí và cách chọn mô hình cho workflow hằng ngày.

Dùng thử Apidog ngay hôm nay

Nếu bạn muốn đọc toàn bộ thông tin nền về mô hình này, hãy bắt đầu với hướng dẫn Cursor Composer 2.5 của chúng tôi. Ở đây, trọng tâm là câu hỏi thực dụng hơn: với một codebase thật và ngân sách thật, mô hình nào nên được dùng mặc định?

Câu trả lời ngắn gọn

Composer 2.5 không phải mô hình đứng đầu tuyệt đối trên mọi bảng xếp hạng. Điểm mạnh của nó là đưa bạn đến rất gần Opus 4.7 trong các tác vụ phần mềm thực tế, thường chỉ kém một hoặc hai điểm benchmark, nhưng với chi phí dưới một đô la cho mỗi tác vụ thay vì vài đô la.

Với hầu hết team dùng AI agent để sửa bug, refactor, thêm tính năng nhỏ hoặc xử lý nhiều file mỗi ngày, đây là sự đánh đổi đáng chọn:

Dùng Composer 2.5 làm mặc định cho phần lớn tác vụ coding agent.
Dùng Opus 4.7 khi cần chất lượng suy luận cao nhất và chi phí không phải vấn đề chính.
Dùng GPT-5.5 khi workflow nặng về terminal, shell automation hoặc chuỗi lệnh dài.

So sánh benchmark

Cursor công bố ba bộ thử nghiệm chính. Bảng dưới đây đặt Composer 2.5 cạnh Opus 4.7, GPT-5.5 và Composer 2 để thấy mức cải thiện:

Điểm chuẩn	Composer 2.5	Opus 4.7	GPT-5.5	Composer 2
SWE-bench Đa ngôn ngữ	79.8%	80.5%	77.8%	73.7%
Terminal-bench 2.0	69.3%	69.4%	82.7%	k.á
CursorBench v3.1	63.2%	64.8% tối đa / 61.6% mặc định	59.2% mặc định	k.á

Cách đọc bảng này trong thực tế:

1. SWE-bench Đa ngôn ngữ gần như hòa

SWE-bench Đa ngôn ngữ đo khả năng sửa lỗi GitHub thực tế trên nhiều ngôn ngữ. Composer 2.5 đạt 79,8%, chỉ kém Opus 4.7 0,7 điểm và vượt GPT-5.5.

Điểm đáng chú ý hơn là bước nhảy từ Composer 2: từ 73,7% lên 79,8%. Nếu bạn từng dùng Composer 2, Composer 2.5 không chỉ là bản cập nhật nhỏ. Nó thuộc một lớp hiệu năng khác. Bạn có thể xem lại hướng dẫn Composer 2 để thấy điểm xuất phát của phiên bản trước.

2. CursorBench ưu tiên Composer 2.5 ở cấu hình mặc định

Trên bộ tác vụ riêng của Cursor, Composer 2.5 đạt 63,2%, vượt Opus 4.7 ở cấu hình mặc định 61,6% và GPT-5.5 ở cấu hình mặc định 59,2%.

Opus 4.7 chỉ vượt lên khi chạy ở cài đặt tối đa, đạt 64,8%. Đổi lại, cấu hình này thường đắt hơn và chậm hơn. Nếu bạn đang chọn mô hình mặc định cho team, cấu hình mặc định mới là dữ liệu gần với thực tế sử dụng hằng ngày hơn.

3. GPT-5.5 thắng rõ trên Terminal-bench

GPT-5.5 đạt 82,7% trên Terminal-bench 2.0, trong khi Composer 2.5 đạt 69,3%. Nếu công việc của bạn chủ yếu là:

viết script shell,
chạy chuỗi lệnh dài,
tự động hóa CLI,
debug môi trường build/test qua terminal,

thì GPT-5.5 có lợi thế rõ ràng.

Để kiểm tra nguồn số liệu, bạn có thể đọc thêm bài viết của The Decoder và thông báo chính thức về Cursor Composer 2.5.

Chi phí: khác biệt lớn nhất nằm ở đây

Benchmark chỉ chênh nhau một hoặc hai điểm. Nhưng khi nhân lên hàng trăm hoặc hàng nghìn tác vụ mỗi tháng, chi phí mới là yếu tố quyết định.

Mô hình	Đầu vào / M token	Đầu ra / M token	Chi phí ước tính cho mỗi tác vụ
Composer 2.5 tiêu chuẩn	$0.50	$2.50	Dưới $1
Composer 2.5 nhanh	$3.00	$15.00	Vài đô la, nhưng vẫn ở mức thấp
Opus 4.7 / GPT-5.5	Cấp độ tiên tiến	Cấp độ tiên tiến	Vài đô la, có thể lên đến khoảng $11

Cursor báo cáo Composer 2.5 đạt khoảng 63% trên CursorBench với chi phí trung bình dưới 1 đô la cho mỗi tác vụ. Trong khi đó, Opus 4.7 và GPT-5.5 có thể tốn vài đô la cho mỗi tác vụ với kết quả tương tự hoặc chỉ nhỉnh hơn trong một số tình huống.

Ví dụ đơn giản:

Khối lượng	Chi phí / tác vụ	Tổng chi phí / tháng
2.000 tác vụ agent	$1	~$2.000
2.000 tác vụ agent	$5	~$10.000
2.000 tác vụ agent	$11	~$22.000

Với cùng khối lượng công việc, khoảng cách benchmark có thể chỉ là một điểm, nhưng khoảng cách hóa đơn có thể là một bậc độ lớn. Vì vậy, câu hỏi thực tế không phải là “mô hình nào đứng đầu bảng?”, mà là “mô hình nào đủ tốt để dùng mặc định với chi phí hợp lý?”.

Để hiểu sâu hơn về cách Cursor tính chi phí này, xem hướng dẫn định giá Cursor Composer. Với các mô hình tiên tiến, bạn có thể tham khảo thêm bài viết về định giá GPT-5.5 và hướng dẫn Claude Opus 4.7.

Tốc độ và hành vi khi dùng trong workflow coding

Chất lượng benchmark và giá chưa đủ để chọn mô hình. Bạn cũng cần xem cách mỗi mô hình hoạt động trong vòng lặp phát triển.

Composer 2.5

Composer 2.5 được tối ưu cho tác vụ agent dài trong Cursor:

xử lý nhiều file,
giữ ngữ cảnh qua nhiều bước,
điều chỉnh mức nỗ lực theo yêu cầu,
phù hợp với vòng lặp “đọc code → sửa code → chạy test → chỉnh tiếp”.

Phiên bản nhanh giữ cùng mức thông minh nhưng giảm độ trễ, phù hợp khi bạn cần phản hồi nhanh hơn.

Opus 4.7

Opus 4.7 mạnh nhất ở các tác vụ suy luận khó, đặc biệt khi bật cấu hình tối đa. Đổi lại, bạn thường phải chấp nhận:

chi phí cao hơn,
độ trễ lớn hơn,
ít phù hợp hơn để chạy mọi tác vụ nhỏ trong ngày nếu ngân sách bị giới hạn.

GPT-5.5

GPT-5.5 nổi bật ở workflow terminal:

chuỗi lệnh shell dài,
debug CLI,
automation script,
xử lý môi trường build phức tạp.

Nếu phần lớn công việc của bạn nằm trong terminal thay vì chỉnh sửa nhiều file trong IDE, GPT-5.5 đáng được ưu tiên hơn.

Composer 2.5 được xây dựng trên checkpoint Moonshot Kimi K2.5 mã nguồn mở và được Cursor hậu huấn luyện kỹ cho workflow agent. Trong khi đó, Opus 4.7 và GPT-5.5 là các mô hình tiên tiến đa năng có năng lực coding mạnh. Khác biệt này thể hiện rõ khi làm việc trong Cursor: Composer 2.5 được điều chỉnh cụ thể cho vòng lặp biên tập-agent.

Nên chọn mô hình nào?

Thay vì xem đây là bảng xếp hạng tuyệt đối, hãy dùng nó như ma trận quyết định.

Chọn Composer 2.5 nếu

Bạn dùng Cursor hằng ngày.
Bạn có nhiều tác vụ coding agent mỗi tháng.
Bạn cần sửa bug, thêm tính năng nhỏ, refactor hoặc chỉnh nhiều file.
Bạn muốn chất lượng gần nhóm dẫn đầu nhưng chi phí thấp hơn đáng kể.
Bạn đang tìm mô hình mặc định cho team.

Với phần lớn team phần mềm, đây là lựa chọn mặc định hợp lý nhất.

Chọn Opus 4.7 nếu

Bạn cần điểm số cao nhất cho các bài toán suy luận khó.
Chi phí không phải yếu tố chính.
Bạn đã có workflow tập trung vào Claude.
Bạn chỉ dùng mô hình cao cấp cho một số tác vụ phức tạp.

Nếu bạn đang so sánh hệ sinh thái Claude và Cursor, xem thêm so sánh Claude Code và Cursor.

Chọn GPT-5.5 nếu

Công việc chính của bạn là terminal automation.
Bạn thường yêu cầu mô hình tạo và chạy chuỗi lệnh dài.
Bạn cần một mô hình đa năng kiêm luôn mô hình coding.
Bạn ưu tiên Terminal-bench hơn CursorBench.

Chiến lược thực tế cho team

Một cấu hình hợp lý cho nhiều team là:

Mặc định: Composer 2.5
Tác vụ suy luận rất khó: Opus 4.7
Tác vụ terminal/shell automation: GPT-5.5

Cách này giúp bạn kiểm soát chi phí mà vẫn có đường thoát cho những bài toán cần mô hình mạnh hơn. Nếu bạn vẫn đang chọn công cụ coding agent, bài tổng hợp Codex vs Claude Code vs Cursor vs Copilot sẽ cho bạn bức tranh rộng hơn.

Cách tự benchmark trên codebase của bạn

Benchmark công khai chỉ cho biết mức trung bình. Codebase của bạn có conventions, test suite, API contract và technical debt riêng. Vì vậy, hãy chạy một phép thử nhỏ trước khi chọn mô hình mặc định.

Bước 1: Chọn một tác vụ thật

Chọn một tác vụ mà bạn thường giao cho AI agent, ví dụ:

sửa một bug có bước tái tạo rõ ràng,
thêm một endpoint nhỏ,
refactor một module có test,
cập nhật SDK/client theo thay đổi API,
thêm validation hoặc error handling.

Tránh dùng task quá giả lập. Mục tiêu là đo hiệu năng trên công việc mà team thật sự làm.

Bước 2: Viết một prompt cố định

Ví dụ:

Bạn đang làm việc trong codebase hiện tại.

Nhiệm vụ:
- Sửa lỗi khi endpoint GET /users/:id trả về 500 nếu user không tồn tại.
- Thay vì 500, API phải trả về 404 với JSON body:
  { "error": "USER_NOT_FOUND" }

Yêu cầu:
- Tìm vị trí xử lý request hiện tại.
- Sửa code tối thiểu.
- Cập nhật hoặc thêm test liên quan.
- Không thay đổi public API khác.
- Sau khi sửa, chạy test phù hợp và báo lại kết quả.

Dùng cùng prompt này cho cả ba mô hình để kết quả công bằng hơn.

Bước 3: Chạy lần lượt trong Cursor

Chạy cùng tác vụ ba lần, chỉ đổi model selector:

composer-2.5
Opus 4.7
GPT-5.5

Giữ nguyên:

prompt,
branch hoặc trạng thái repo,
test command,
dữ liệu đầu vào,
thời điểm đánh giá.

Nếu có thể, reset repo về cùng commit trước mỗi lần chạy.

Bước 4: Chấm điểm bằng tiêu chí thực tế

Tạo bảng đánh giá đơn giản:

Tiêu chí	Composer 2.5	Opus 4.7	GPT-5.5
Code có compile không?
Test có pass không?
Có sửa đúng phạm vi không?
Có tạo bug phụ không?
Thời gian hoàn thành
Chi phí trong Cursor usage
Cần bao nhiêu lần can thiệp thủ công?

Đừng chỉ đo “có sinh code không”. Hãy đo “code đó có thể merge được không”.

Bước 5: Nếu task liên quan đến API, xác minh bằng request thật

Nếu agent tạo hoặc sửa API, hãy gửi request thật qua Apidog thay vì chỉ dựa vào unit test.

Ví dụ checklist:

[ ] Status code đúng
[ ] Response body đúng schema
[ ] Error case đúng
[ ] Auth header được xử lý đúng
[ ] Query/path params đúng
[ ] Contract không lệch với tài liệu API

Điều này giúp “test pass” có nghĩa là endpoint thật sự trả về dữ liệu như code mong đợi, không chỉ là mock hoặc unit test xanh.

Điểm benchmark thường bỏ lỡ: API contract

Có một lỗi phổ biến mà benchmark không phản ánh đầy đủ: mô hình viết code API trông rất tự tin nhưng dựa trên endpoint mà nó tự suy đoán, không phải endpoint thật sự tồn tại.

Vấn đề này có thể xảy ra với cả:

Composer 2.5,
Opus 4.7,
GPT-5.5.

Ví dụ prompt mơ hồ:

Thêm logic gọi API lấy thông tin user profile.

Nếu không có API spec thật, mô hình có thể tự tạo ra endpoint kiểu:

GET /api/profile/:userId

Trong khi hệ thống thật dùng:

GET /v2/users/{id}/profile

Code sinh ra có thể sạch, dễ đọc và compile được, nhưng vẫn sai.

Cách xử lý không phụ thuộc vào mô hình bạn chọn:

Cung cấp API specification thật cho Cursor.
Cho mô hình coding dựa trên schema thực tế.
Chạy request được tạo bằng Apidog.
Xác minh status code, payload, auth và validation trước khi merge.

Bạn có thể thiết lập API spec trong Cursor thông qua MCP theo hướng dẫn về thông số kỹ thuật API trong Cursor.

Mô hình bạn chọn ảnh hưởng đến tốc độ và chi phí. Nhưng vòng lặp xác minh mới là thứ ngăn tốc độ đó biến thành nợ debug.

Workflow đề xuất cho tác vụ API với Cursor và Apidog

Một workflow thực tế có thể như sau:

1. Đồng bộ API spec vào Apidog.
2. Kết nối spec với Cursor qua MCP.
3. Yêu cầu model sửa hoặc tạo code dựa trên spec.
4. Chạy test trong repo.
5. Gửi request thật bằng Apidog.
6. Nếu response lệch schema, đưa lỗi ngược lại cho model.
7. Chỉ merge khi test và request thật đều pass.

Prompt mẫu:

Dựa trên API specification đã kết nối qua MCP, hãy thêm client method gọi endpoint tạo order.

Yêu cầu:
- Không tự suy đoán endpoint.
- Dùng đúng method, path, request body và response schema từ spec.
- Thêm test cho success case và validation error.
- Sau khi sửa, liệt kê các request cần kiểm tra trong Apidog.

Với prompt này, bạn giảm khả năng mô hình “bịa” API và buộc nó bám vào contract thật.

Các câu hỏi thường gặp

Composer 2.5 có tốt hơn Opus 4.7 không?

Không phải trong mọi trường hợp. Trên SWE-bench Đa ngôn ngữ, Composer 2.5 đạt 79,8%, chỉ kém Opus 4.7 ở mức 80,5%. Trên CursorBench cấu hình mặc định, Composer 2.5 nhỉnh hơn Opus 4.7. Opus 4.7 chỉ dẫn đầu khi chạy ở cài đặt tối đa.

Nếu xét giá trị trên mỗi đô la, Composer 2.5 phù hợp hơn cho phần lớn workload hằng ngày.

Composer 2.5 có tốt hơn GPT-5.5 không?

Composer 2.5 vượt GPT-5.5 trên SWE-bench Đa ngôn ngữ và CursorBench. Nhưng GPT-5.5 thắng rõ trên Terminal-bench 2.0.

Nếu bạn làm việc chủ yếu trong Cursor với nhiều file và agent task, Composer 2.5 là lựa chọn tốt hơn. Nếu bạn làm nhiều terminal automation, GPT-5.5 đáng cân nhắc.

Vì sao Composer 2.5 rẻ hơn nhiều?

Composer 2.5 được xây dựng trên nền tảng Kimi K2.5 mã nguồn mở và được tinh chỉnh cho vòng lặp agent của Cursor. Điều này giúp Cursor kiểm soát chi phí tốt hơn. Các mô hình tiên tiến đa năng như Opus 4.7 và GPT-5.5 thường đi kèm mức giá cao hơn.

Có thể dùng cả ba mô hình trong Cursor không?

Có. Model selector của Cursor cho phép bạn đổi mô hình theo từng tác vụ. Đây là lý do chiến lược kết hợp rất thực tế: dùng Composer 2.5 cho phần lớn tác vụ, rồi chuyển sang Opus 4.7 hoặc GPT-5.5 khi bài toán phù hợp hơn. Xem hướng dẫn Cursor Composer 2.5 để thiết lập.

Kết luận

Nếu chỉ nhìn vào đỉnh benchmark, Opus 4.7 và GPT-5.5 đều có điểm mạnh rõ ràng. Nhưng nếu bạn đo chất lượng trên mỗi đô la cho tác vụ phần mềm thực tế, Composer 2.5 là mô hình nên được dùng mặc định trong nhiều team.

Cách chọn thực dụng:

Composer 2.5: default cho coding agent hằng ngày
Opus 4.7: tác vụ suy luận khó, ngân sách ít quan trọng
GPT-5.5: terminal automation và chuỗi lệnh dài

Dù chọn mô hình nào, đừng để agent viết code dựa trên giả định API. Hãy gắn nó với contract thật và xác minh output bằng request thật. Bạn có thể tải xuống Apidog để gửi request trực tiếp đến endpoint được tạo và đưa các lệnh gọi hoạt động vào test tự động.

Cách xây dựng API với Cursor Composer 2.5

Sebastian Petrus — Tue, 19 May 2026 02:27:09 +0000

Cursor Composer 2.5 đủ nhanh và rẻ để một tác nhân có thể viết client API và kết nối luồng xử lý cho bạn. Nhưng nếu mô hình không đọc hợp đồng API thực tế, nó có thể tạo request tới /v2/orders trong khi service của bạn chỉ có /orders, hoặc dùng payload sai. Code vẫn compile, nhưng lỗi chỉ lộ ra khi chạy với backend thật.

Thử Apidog ngay hôm nay

Bài viết này hướng dẫn workflow thực tế: kết nối Composer 2.5 với spec API thật thông qua MCP, để nó sinh code theo hợp đồng hiện có, rồi xác minh request trong Apidog trước khi gửi cho team. Nếu bạn mới dùng mô hình này, xem thêm hướng dẫn về Cursor Composer 2.5.

Vì sao mô hình tác nhân hay đoán sai API

Composer 2.5 được thiết kế cho tác vụ tác nhân dài, nhiều bước. Bạn có thể yêu cầu:

“Thêm client cho service thanh toán và kết nối nó vào luồng checkout.”

Mô hình sẽ lập kế hoạch, chỉnh sửa nhiều file và chạy test. Đây là nâng cấp hữu ích so với Composer 2.

Vấn đề là: nếu spec API không nằm trong ngữ cảnh, mô hình sẽ tự suy luận dựa trên các pattern phổ biến:

Endpoint gần đúng: /api/users/{id} thay vì /users/{userId}
Body request có field thừa, thiếu hoặc sai tên
Auth được xử lý theo kiểu chung chung thay vì theo schema thật
Error response được giả định thay vì đọc từ spec

Prompt có thể giảm lỗi, nhưng dán toàn bộ OpenAPI vào chat không ổn định và tốn context. Cách bền vững hơn là cho mô hình truy cập spec qua một nguồn có cấu trúc.

Giải pháp: cho Composer 2.5 đọc spec API qua MCP

Model Context Protocol, hay MCP, là chuẩn mở để cung cấp tool và dữ liệu cho mô hình AI. Cursor hỗ trợ MCP server. Apidog MCP server expose spec API trong Apidog dưới dạng nguồn có cấu trúc để Composer có thể truy vấn khi viết code.

Thay vì đoán endpoint, parameter, schema và response, Composer 2.5 có thể đọc chúng từ hợp đồng thật. Đây cũng là ý tưởng trong vibe coding với Apidog MCP server, nhưng áp dụng cho workflow triển khai tính năng hoàn chỉnh.

Bước 1: Chuẩn bị spec API trong Apidog

Trước tiên, đảm bảo API contract của bạn nằm trong Apidog và được cập nhật.

Bạn có thể:

Thiết kế API trực tiếp trong Apidog.
Import OpenAPI spec hiện có.
Import Postman collection.
Bổ sung request body, response schema, auth, header và ví dụ.

Spec này sẽ là nguồn chân lý cho Composer 2.5. Nếu spec sai hoặc lỗi thời, mô hình vẫn có thể sinh code sai theo đúng thông tin sai đó.

Bước 2: Kết nối Apidog MCP server với Cursor

Cursor đọc MCP server từ file cấu hình trong project, thường là:

.cursor/mcp.json

Một cấu hình điển hình:

{
  "mcpServers": {
    "apidog-api-spec": {
      "command": "npx",
      "args": [
        "-y",
        "apidog-mcp-server@latest",
        "--project=<your-project-id>"
      ],
      "env": {
        "APIDOG_ACCESS_TOKEN": "<your-access-token>"
      }
    }
  }
}

Thay các giá trị sau bằng thông tin thật:

<your-project-id>: ID project Apidog
<your-access-token>: access token của bạn
package/version server: dùng đúng theo hướng dẫn cài đặt Apidog MCP

Sau khi lưu file, khởi động lại Cursor để nhận MCP server mới.

Bước 3: Kiểm tra Composer 2.5 có đọc được spec không

Mở một phiên agent trong Cursor, chọn composer-2.5, rồi hỏi một câu chỉ đọc:

Sử dụng MCP server apidog-api-spec, liệt kê các endpoint thuộc resource orders và các field bắt buộc để tạo order.

Nếu Composer trả về endpoint, parameter và field đúng với project của bạn, kết nối đã hoạt động.

Nếu nó trả lời chung chung kiểu REST phổ biến, hãy kiểm tra lại:

File .cursor/mcp.json
Tên MCP server
Project ID
Access token
Cursor đã được restart chưa

Bước 4: Yêu cầu Composer sinh code theo hợp đồng

Khi MCP đã hoạt động, prompt nên chỉ rõ nguồn spec:

Sử dụng MCP server apidog-api-spec làm nguồn chân lý.

Viết một TypeScript client được định kiểu cho Orders API, bao gồm:
- createOrder
- getOrder

Yêu cầu:
- Khớp chính xác request schema và response schema trong spec
- Dùng đúng endpoint và HTTP method
- Thêm xử lý lỗi cho response validation 422 mà spec định nghĩa
- Không tự tạo field ngoài spec

Ví dụ output mong muốn có thể là một client dạng:

type CreateOrderRequest = {
  customerId: string;
  items: Array<{
    productId: string;
    quantity: number;
  }>;
};

type OrderResponse = {
  id: string;
  status: string;
  createdAt: string;
};

export async function createOrder(payload: CreateOrderRequest): Promise<OrderResponse> {
  const res = await fetch("/orders", {
    method: "POST",
    headers: {
      "Content-Type": "application/json"
    },
    body: JSON.stringify(payload)
  });

  if (res.status === 422) {
    const errorBody = await res.json();
    throw new Error(`Validation failed: ${JSON.stringify(errorBody)}`);
  }

  if (!res.ok) {
    throw new Error(`Failed to create order: ${res.status}`);
  }

  return res.json();
}

Tên field, endpoint và error shape trong code thực tế phải đến từ spec của bạn, không phải từ ví dụ trên.

Xác minh trước khi tin: vòng lặp kiểm thử với Apidog

Cho mô hình đọc spec giúp giảm mạnh lỗi ảo giác, nhưng không thay thế kiểm thử. Spec có thể lệch so với service đang chạy, hoặc mô hình có thể xử lý sai một edge case.

Workflow nên là:

Sinh code từ spec
- Composer 2.5 đọc API contract qua MCP.
- Code được tạo theo endpoint, schema, auth và response thật.
Chạy request thật trong Apidog
- Lấy endpoint mà Composer dùng.
- Gửi request trong Apidog.
- Kiểm tra status code, response body, validation và auth.
Lưu request thành test
- Với request đã chạy đúng, lưu thành test scenario.
- Đưa vào quy trình regression để lỗi được phát hiện trước khi tới người dùng.
Mock endpoint chưa triển khai
- Nếu backend chưa sẵn sàng, dùng mock server của Apidog.
- Frontend/client vẫn có response thực tế để phát triển tiếp.
- Cách này phù hợp với các pattern trong AI agents và kiểm thử API.

Nguyên tắc đơn giản: mô hình viết bản nháp đầu tiên dựa trên hợp đồng, còn bạn xác minh bản nháp đó với server thật hoặc mock đáng tin cậy.

Ví dụ workflow từ đầu đến cuối

Giả sử bạn đang thêm tính năng hoàn tiền cho service thanh toán.

1. Spec đã có trong Apidog

Trong project Apidog đã có:

Endpoint tạo refund
Request body
Response schema
Header idempotency-key
Error khi refund trùng lặp

2. Cursor đã kết nối Apidog MCP

Bạn có .cursor/mcp.json trỏ tới project Apidog và đã restart Cursor.

3. Prompt cho Composer 2.5

Sử dụng apidog-api-spec làm nguồn chân lý.

Xây dựng refund client và một React hook gọi client đó.

Yêu cầu:
- Tuân thủ chính xác schema trong spec
- Bao gồm header idempotency-key nếu spec yêu cầu
- Xử lý lỗi 409 khi refund bị trùng
- Thêm type cho request và response
- Chạy test hiện có sau khi chỉnh sửa

4. Composer sinh code

Composer có thể tạo:

refundClient.ts
TypeScript types
React hook như useCreateRefund
Test hoặc cập nhật test hiện có

5. Xác minh trong Apidog

Sau đó bạn mở Apidog và kiểm tra:

Request tạo refund thành công
Header idempotency-key được gửi đúng
Trường hợp trùng lặp trả về lỗi 409 như mong đợi
Response body khớp với code đã xử lý

Nếu mọi thứ đúng, lưu các request này thành test scenario.

Điều bạn tránh được là một client quên header idempotency, gây refund trùng trong staging. Đây là loại lỗi mà workflow “spec-driven generation + verification” xử lý tốt.

FAQ

Composer 2.5 có hỗ trợ MCP không?

Có. Composer 2.5 có thể dùng bộ công cụ agent của Cursor, bao gồm MCP server. Chọn composer-2.5 trong model picker và cấu hình MCP server trong project. Xem thêm hướng dẫn Composer 2.5.

Tôi có bắt buộc phải dùng Apidog để dùng MCP với Composer 2.5 không?

Bạn cần một nguồn spec có cấu trúc. Apidog MCP server là hướng được dùng trong bài này vì nó kết hợp spec, testing và mocking trong cùng một nơi. Ngoài ra vẫn có các lựa chọn khác trong danh sách MCP server tốt nhất cho Cursor.

Việc cho mô hình đọc spec có loại bỏ toàn bộ ảo giác không?

Không hoàn toàn. Nó loại bỏ nhóm lỗi lớn nhất: endpoint, schema và parameter bị đoán sai. Nhưng bạn vẫn cần kiểm thử vì spec có thể không khớp hoàn toàn với service đang chạy.

Dự án nhỏ có cần workflow này không?

Có, nếu mô hình đang viết code gọi API thật. Chi phí thiết lập chỉ là một file cấu hình, còn lợi ích là mỗi request được sinh ra dựa trên hợp đồng của bạn thay vì phỏng đoán.

Tổng kết

Composer 2.5 đủ mạnh để xử lý công việc API thực tế, nhưng chỉ đáng tin khi nó đọc hợp đồng thật. Kết nối spec qua Apidog MCP để Composer sinh code theo API contract, sau đó dùng Apidog để gửi request, xác minh response và lưu các case hoạt động thành test hoặc mock. Đây là workflow giúp biến tốc độ của agent thành tính năng có thể triển khai.

Bitwarden Agent Access: Chia Sẻ Mật Khẩu An Toàn với AI Coding Agents

Sebastian Petrus — Fri, 15 May 2026 08:12:55 +0000

Nếu bạn dùng Claude Code, Codex hoặc Cursor để làm việc với API thật, vấn đề xuất hiện rất nhanh: tác nhân cần thông tin đăng nhập, còn trình quản lý mật khẩu của bạn được thiết kế để không để lộ chúng. Dán API key vào chat khiến nó nằm trong context của mô hình. Đặt secret vào .env thì công cụ bash của tác nhân vẫn có thể cat và gửi nó đi. Cách đúng hơn là cấp secret theo phạm vi, tại runtime, và không đưa chúng vào context LLM.

Dùng thử Apidog hôm nay

Dự án mã nguồn mở mới của Bitwarden, Agent Access, là một cách tiếp cận nghiêm túc cho bài toán này. Nó gồm một giao thức chia sẻ thông tin đăng nhập, CLI (aac) và SDK Rust + Python để tạo đường hầm mã hóa giữa trình quản lý mật khẩu và một tiến trình từ xa: tác nhân AI, CI runner hoặc script.

Ý tưởng chính: tác nhân chỉ nhận đúng credential cần dùng, theo domain hoặc vault item ID. Nó không thấy toàn bộ vault, không cần đọc .env, và không cần bạn dán secret vào prompt.

Bài viết này hướng dẫn cách cài đặt Agent Access, dùng aac connect, dùng aac run, và tích hợp nó vào workflow với Claude Code, Codex, Cursor và kiểm thử API bằng Apidog. Nếu bạn cần bối cảnh rộng hơn về hygiene cho API credential của AI agent, xem thêm Cách bảo mật thông tin đăng nhập API của tác nhân AI.

Agent Access là gì?

Agent Access là một giao thức mở kèm triển khai tham chiếu do Bitwarden xây dựng. Mục tiêu là để bất kỳ trình quản lý mật khẩu nào cũng có thể đóng vai trò provider.

CLI aac tạo đường hầm mã hóa đầu cuối bằng giao thức Noise. Mô hình gồm hai phía:

Provider: lắng nghe request và quyết định credential nào được trả về.
Consumer: agent, script hoặc CI job cần credential để chạy một tác vụ.

Consumer có thể yêu cầu credential theo:

domain, ví dụ github.com
vault item ID

Consumer không thể liệt kê toàn bộ vault. Provider cũng không thấy consumer làm gì với credential sau khi cấp. Audit log tồn tại ở cả hai phía.

Hiện Agent Access vẫn ở giai đoạn xem trước ban đầu. README của dự án cảnh báo rằng API và giao thức có thể thay đổi. Bitwarden cũng nói rõ rằng không nên nhập trực tiếp credential nhạy cảm vào LLM hoặc AI agent.

Vì vậy, pattern nên dùng là: lấy secret tại runtime bằng aac run, inject vào tiến trình con dưới dạng biến môi trường, và không để secret xuất hiện trong prompt hoặc log của agent.

Tại sao điều này quan trọng?

AI coding agent không còn chỉ sửa file. Claude Code, Codex, Cursor và các công cụ tương tự có thể:

đọc repository
chạy test
gọi API
tạo pull request
chạy script deploy
tương tác với CI

Các bước này thường cần credential. Nếu credential nằm trong .env, shell history, log hoặc context LLM, rủi ro tăng rất nhanh.

Sự cố khóa API bị lộ của Postman cho thấy credential management đã khó ngay cả khi chỉ có con người thao tác. Khi thêm agent tự động vào workflow, cách tiếp cận cần chặt hơn.

Nguyên tắc nên áp dụng:

Đừng tin agent nhiều hơn. Hãy đưa cho agent ít dữ liệu nhạy cảm hơn.

Agent Access làm việc này ở cấp giao thức:

credential được giới hạn phạm vi
dữ liệu được mã hóa khi truyền
secret được lấy tại runtime
secret biến mất khi tiến trình kết thúc
agent không cần nhìn thấy giá trị thật

Các công cụ quản lý key truyền thống vẫn quan trọng. Xem thêm Công cụ quản lý khóa API. Điểm khác của Agent Access là nó được thiết kế trực tiếp cho use case agent và script runtime.

Cài đặt `aac`

Chọn bản phù hợp với hệ điều hành của bạn.

macOS Apple Silicon

curl -L https://github.com/bitwarden/agent-access/releases/latest/download/aac-macos-aarch64.tar.gz | tar xz
sudo mv aac /usr/local/bin/

macOS Intel

curl -L https://github.com/bitwarden/agent-access/releases/latest/download/aac-macos-x86_64.tar.gz | tar xz
sudo mv aac /usr/local/bin/

Linux x86_64

curl -L https://github.com/bitwarden/agent-access/releases/latest/download/aac-linux-x86_64.tar.gz | tar xz
sudo mv aac /usr/local/bin/

Windows x86_64

Tải aac-windows-x86_64.zip từ trang phát hành mới nhất, sau đó giải nén vào một thư mục nằm trong PATH.

Kiểm tra cài đặt:

aac --help

Nếu Bitwarden CLI (bw) nằm trong PATH, aac sẽ dùng nó làm credential provider mặc định. Nếu chưa dùng Bitwarden CLI, bạn có thể thử nhanh với provider demo:

aac --provider example --help

Quickstart: ghép nối và lấy credential

Chạy listener trên máy chứa vault hoặc provider. Thường đây là laptop của bạn:

aac listen

Lệnh này sẽ in ra pairing token.

Ở phía consumer — có thể là máy từ xa, CI runner, hoặc một terminal khác trên cùng máy — dùng token để kết nối và yêu cầu credential theo domain:

aac connect --token <pairing-token> --domain github.com --output json

Output có dạng:

{
  "credential": {
    "notes": null,
    "password": "alligator5",
    "totp": null,
    "uri": "https://github.com",
    "username": "example"
  },
  "domain": "github.com",
  "success": true
}

Script của bạn có thể parse JSON này và dùng các field cần thiết.

Nếu muốn lấy credential theo vault item ID thay vì domain:

aac connect --id <vault-item-id> --output json

Lưu ý:

--id và --domain loại trừ lẫn nhau
nếu item có cấu hình TOTP, mã TOTP sẽ nằm trong cùng payload
không nên in output này vào log CI nếu có chứa secret

Pattern nên dùng: `aac run`

aac connect hữu ích khi bạn tự xử lý JSON. Nhưng với AI agent và CI, pattern an toàn hơn thường là aac run.

aac run lấy credential rồi chạy tiến trình con với các field được inject dưới dạng biến môi trường. Secret không cần xuất ra stdout, không cần ghi vào disk, và không cần hiện trong prompt của agent.

Inject field cụ thể

Ví dụ inject password và username vào lệnh psql:

aac run \
  --domain example.com \
  --env DB_PASSWORD=password \
  --env DB_USER=username \
  -- psql

Trong tiến trình psql, bạn có thể đọc:

$DB_PASSWORD
$DB_USER

Inject tất cả field với prefix mặc định

aac run --domain example.com --env-all -- ./deploy.sh

Các biến môi trường sẽ có prefix AAC_.

Kết hợp `--env-all` và override tên biến

aac run \
  --domain example.com \
  --env-all \
  --env CUSTOM_PW=password \
  -- ./deploy.sh

Các field có thể map gồm:

username
password
totp
uri
notes
domain
credential_id

Đây là model Bitwarden khuyến nghị cho AI agent. Thay vì đưa secret vào context LLM, bạn chỉ cho agent chạy script:

aac run --domain api.stripe.com --env-all -- ./deploy.sh

Agent nhìn thấy command, nhưng không nhìn thấy giá trị thật của secret. Secret chỉ tồn tại trong tiến trình con deploy.sh.

Đây cũng là nguyên tắc cô lập được đề cập trong Cách bảo mật thông tin đăng nhập API của tác nhân AI, nhưng được triển khai bằng công cụ cụ thể.

Dùng SDK Python và Rust

Nếu CLI chưa đủ, bạn có thể tích hợp Agent Access trực tiếp vào ứng dụng.

Python

from agent_access import RemoteClient

client = RemoteClient("python-remote")
client.connect(token="ABC-DEF-GHI")

cred = client.request_credential("example.com")
print(cred.username, cred.password)

client.close()

Module Python được hỗ trợ bởi PyO3, nên phần xử lý giao thức vẫn chạy trên Rust và dùng cùng implementation Noise bên dưới.

Trong ứng dụng thật, tránh print() password như ví dụ demo. Hãy truyền credential trực tiếp vào client hoặc tiến trình cần dùng.

Rust

SDK Rust cung cấp interface RemoteClient ở cấp thư viện. Các ví dụ tham chiếu nằm trong:

examples/rust-remote/

Dùng Rust SDK khi bạn đang viết:

CLI nội bộ
build runner
service cần binary đã biên dịch
consumer chạy trong môi trường hạn chế

Với các nhóm đã có hệ thống secrets enterprise, Agent Access có thể bổ sung cho các tích hợp như HashiCorp Vault hoặc Azure Key Vault. Nó không thay thế hoàn toàn vault doanh nghiệp, nhưng phù hợp cho laptop developer, script cục bộ và CI runner.

Tích hợp với AI coding agent

Claude Code

Tạo một wrapper script để Claude Code gọi thay vì gọi deploy trực tiếp.

# deploy.sh
#!/usr/bin/env bash
set -euo pipefail

aac run --domain prod.example.com --env-all -- ./run-deploy.sh

Cấp quyền thực thi:

chmod +x deploy.sh

Sau đó hướng workflow Claude Code vào:

./deploy.sh

Claude Code chỉ thấy script và command aac run. Credential thật chỉ xuất hiện trong tiến trình con run-deploy.sh.

Với Claude Code GitHub Actions, pattern tương tự có thể mở rộng sang CI:

cài aac trong runner
ghép nối runner với provider
chạy test hoặc deploy qua aac run
không lưu API key trong repo hoặc prompt

OpenAI Codex

Với Codex CLI, bạn cũng nên để model gọi wrapper script thay vì gọi trực tiếp công cụ cần secret.

Ví dụ:

# test-api.sh
#!/usr/bin/env bash
set -euo pipefail

aac run --domain staging.example.com --env API_TOKEN=password -- ./run-api-tests.sh

Codex có thể chạy:

./test-api.sh

Nhưng không cần biết API_TOKEN là gì.

Bài viết Codex từ điện thoại của bạn nói về bề mặt sử dụng Codex rộng hơn. Agent Access giải quyết phần credential trong workflow đó.

Cursor

Với Cursor, pattern thực tế là wrap các lệnh terminal hoặc Composer workflow bằng aac run.

Ví dụ:

# local-contract-test.sh
#!/usr/bin/env bash
set -euo pipefail

aac run --domain api.example.com --env-all -- npm run test:contract

Vì Cursor thường chạy cục bộ, listener có thể chạy trên cùng máy:

aac listen

Sau đó script test hoặc deploy chạy như bình thường, nhưng secret không nằm trong .env.

OpenClaw

Agent Access có một kỹ năng OpenClaw chính thức ngay từ đầu, dưới dạng file SKILL.md trong repository. Nếu nhóm của bạn dùng workflow theo kiểu OpenClaw, đây là hướng tích hợp sẵn tốt nhất hiện tại.

Kỹ năng biết cách:

kết nối theo giao thức
lấy credential
chuyển credential cho tool downstream

Xem thêm Hướng dẫn khóa API OpenClaw để đặt Agent Access vào bối cảnh credential management rộng hơn.

Mô hình bảo mật

Agent Access cung cấp ba điểm bảo vệ chính.

1. Mã hóa đầu cuối qua Noise

Traffic giữa consumer và provider được mã hóa bằng Noise Protocol Framework, cùng lớp giao thức được dùng trong các hệ thống như WireGuard và Signal.

2. Credential được giới hạn phạm vi

Consumer chỉ nhận credential mà nó yêu cầu:

một domain
hoặc một vault item ID

Nó không thể duyệt hoặc liệt kê toàn bộ vault.

3. Không cần ghi secret ra disk

Với aac run, secret được truyền vào tiến trình con qua biến môi trường. Không cần:

ghi .env
in ra stdout
lưu vào shell history
dán vào prompt LLM

Những gì Agent Access không giải quyết

Agent Access không phải lớp bảo vệ tuyệt đối. Bạn vẫn cần hiểu các giới hạn sau.

Consumer bị xâm nhập

Nếu agent hoặc tiến trình con độc hại, credential đã được cấp vẫn có thể bị rò rỉ. Phòng thủ ở đây là giảm phạm vi credential, không phải đảm bảo consumer luôn an toàn.

Provider bị xâm nhập

Nếu vault Bitwarden hoặc provider của bạn bị compromise, Agent Access không thể bảo vệ secret gốc.

Dán secret vào LLM

Nếu bạn copy credential vào chat, mọi lớp giao thức phía sau đều vô nghĩa. README của dự án nói rõ: không nhập trực tiếp credential nhạy cảm vào LLM hoặc AI agent.

Dùng aac run thay cho việc dán secret.

Workflow phổ biến: agent viết code, Apidog kiểm tra API

Một workflow thực tế cho team API có thể như sau:

Agent viết code

Claude Code, Codex hoặc Cursor sửa endpoint và mở pull request.
CI chạy test

Test runner gọi aac run để lấy API key theo phạm vi, rồi chạy test trên staging.
Apidog xác minh contract

Apidog chạy kiểm tra OpenAPI contract như một bước CI riêng, cũng thông qua aac run.

Ví dụ script CI:

#!/usr/bin/env bash
set -euo pipefail

aac run \
  --domain staging.example.com \
  --env API_TOKEN=password \
  -- npm run test:contract

Kết quả:

agent triển khai code
contract API được kiểm tra
secret không nằm trong repo
secret không xuất hiện trong prompt
secret không cần lưu trong .env

Xem thêm Cách kiểm tra các tác nhân AI gọi API của bạn nếu bạn đang xây pipeline kiểm thử cho agent-driven API changes.

Hạn chế cần biết

Vẫn là bản preview

API và giao thức có thể thay đổi. Không nên khóa chặt production workflow vào v0 nếu bạn không có ngân sách bảo trì.
Mặc định cần Bitwarden CLI

Provider mặc định là bw. Cài Bitwarden CLI trước, hoặc dùng --provider example để thử nghiệm.
Chưa có file cấu hình ổn định

Hiện Agent Access chủ yếu được điều khiển bằng flag. Các workflow lặp lại nên được đóng gói trong script.
Không thay thế hygiene cơ bản

Vẫn cần rotate key, dùng scope tối thiểu, không log secret, và không đưa secret vào prompt.

FAQ

Agent Access có miễn phí không?

Có. CLI, SDK và giao thức là mã nguồn mở trong GitHub organization của Bitwarden. Nếu dùng Bitwarden làm vault, chi phí Bitwarden phụ thuộc vào gói bạn đang sử dụng.

Có hoạt động với trình quản lý mật khẩu khác ngoài Bitwarden không?

Giao thức được thiết kế để không phụ thuộc nhà cung cấp. Triển khai tham chiếu hiện hỗ trợ Bitwarden và provider ví dụ. Các provider khác có thể triển khai theo giao thức này trong tương lai.

Có thể dùng mà không cần trình quản lý mật khẩu không?

Có, để thử nghiệm:

aac connect --provider example --domain test.com --output json

Nhưng cho production, bạn cần provider thật như Bitwarden hoặc provider tương thích khác.

Consumer có cần truy cập mạng không?

Có. Consumer cần truy cập network để kết nối tới listener của provider. Nếu chạy cục bộ, listener và consumer có thể nằm trên cùng một máy.

Khác gì so với `.env`?

File .env nằm trên disk, có thể bị commit nhầm, bị đọc bởi script, hoặc bị agent truy cập qua shell command.

aac run giữ secret trong phạm vi tiến trình con. Khi tiến trình thoát, secret cũng biến mất khỏi runtime đó.

Có thay thế HashiCorp Vault hoặc AWS Secrets Manager không?

Không. Vault doanh nghiệp vẫn phù hợp cho service-to-service secrets ở quy mô lớn.

Agent Access phù hợp hơn cho:

laptop developer
AI coding agent
script cục bộ
CI runner
workflow cần cấp credential tạm thời theo phạm vi

Anthropic, OpenAI hoặc các nhà cung cấp agent đã tích hợp trực tiếp chưa?

Chưa có công bố chính thức. Cách tích hợp hiện tại là wrap script bằng aac run.

Báo lỗi hoặc đóng góp ở đâu?

Tại GitHub repository. Issue, PR và thảo luận giao thức đều diễn ra ở đó.

Thử ngay

Cài aac, sau đó chạy listener:

aac listen

Trong terminal khác, thử provider demo:

aac connect --provider example --domain test.com --output json

Nếu JSON trả về đúng, bạn đã có vòng lặp tối thiểu.

Bước tiếp theo:

thay provider demo bằng Bitwarden CLI (bw)
tạo wrapper script với aac run
cho Claude Code, Codex hoặc Cursor gọi wrapper script
bỏ thói quen dán API key vào prompt

Kết hợp Agent Access với Apidog cho phần kiểm thử API, bạn sẽ có ranh giới rõ ràng: vault giữ secret, Apidog kiểm tra contract, agent triển khai code, và credential không rời khỏi máy dưới dạng plain text.

Top 7 Phần Mềm Quản Lý API Tốt Nhất 2026, Xếp Hạng Bởi G2

Sebastian Petrus — Fri, 15 May 2026 07:40:58 +0000

Bảng xếp hạng G2 Spring 2026 cho Quản lý API đã được công bố. Bảy công cụ được xếp vào ba nhóm: Dẫn đầu gồm Apidog và viaSocket; Hiệu suất cao gồm Traefik Labs, Rasayel và Backendless; Ngách gồm Moesif/WSO2 và Thunder Client. Điểm quan trọng không phải là công cụ nào “tốt nhất” nói chung, mà là công cụ nào khớp với cách nhóm của bạn thiết kế, kiểm thử, vận hành và đo lường API.

Dùng thử Apidog ngay hôm nay

Tóm tắt

Apidog và viaSocket dẫn đầu Bảng xếp hạng Quản lý API G2 Spring 2026, nhưng giải quyết hai bài toán khác nhau.

Apidog phù hợp khi nhóm cần thiết kế API, viết test, tạo mock và xuất tài liệu trong cùng một workspace.
viaSocket phù hợp khi nhóm vận hành, marketing hoặc revenue cần tự động hóa workflow không mã bằng webhook và API hook.
Traefik Labs, Rasayel, Backendless, Moesif (WSO2) và Thunder Client giải quyết các phạm vi hẹp hơn: gateway, WhatsApp Business API, BaaS, API analytics/monetization và REST client trong VS Code.

Cách chọn đúng: xác định trước “quản lý API” trong hệ thống của bạn nghĩa là gì — thiết kế, gateway, analytics, automation hay testing cục bộ.

Những tín hiệu từ Bảng xếp hạng G2 Spring 2026

Các báo cáo Spring 2026 của G2 công bố 27.019 báo cáo vào ngày 17 tháng 3 năm 2026, tăng 1,72% theo quý. Theo Phó Chủ tịch Marketing Palmer Houchins, chỉ 3% sản phẩm trên G2 nhận được huy hiệu Dẫn đầu trên tất cả danh mục. Vì vậy, vị trí Dẫn đầu là một tín hiệu bên thứ ba đáng chú ý trong một thị trường mà nhiều nhà cung cấp đều tự nhận là “dẫn đầu ngành”.

G2 sử dụng hai trục:

Mức độ hài lòng của khách hàng: dựa trên đánh giá người dùng.
Hiện diện thị trường: quy mô, phạm vi tiếp cận và số lượng đánh giá.

Trong danh mục Quản lý API Spring 2026:

Dẫn đầu: Apidog, viaSocket
Hiệu suất cao: Traefik Labs, Rasayel, Backendless
Ngách: Moesif/WSO2, Thunder Client

Tuy nhiên, nhóm xếp hạng không thay thế cho phân tích kỹ thuật. Một công cụ Ngách có thể là lựa chọn đúng nếu nó khớp với use case của bạn. Một công cụ Dẫn đầu vẫn có thể sai nếu nó giải quyết vấn đề bạn không gặp.

Tổng quan bảy công cụ

Công cụ	Nhóm G2	Phù hợp nhất	Mã nguồn mở?	Mô hình định giá
Apidog	Dẫn đầu	Thiết kế, thử nghiệm, tạo mock, tài liệu API tất cả trong một	Gói miễn phí + trả phí	SaaS theo người dùng
viaSocket	Dẫn đầu	Tự động hóa workflow không mã với API hook	Không	Gói khởi điểm 50 USD/tháng
Traefik Labs	Hiệu suất cao	API gateway cloud-native + quản lý GitOps	Có, Proxy OSS	OSS miễn phí, Hub trả phí
Rasayel	Hiệu suất cao	WhatsApp Business messaging + REST API	Không	SaaS theo chỗ ngồi
Backendless	Hiệu suất cao	BaaS với REST và GraphQL tự động tạo	Không	Gói miễn phí + trả phí
Moesif (WSO2)	Ngách	Phân tích, giám sát, kiếm tiền từ API	Không	Dựa trên mức sử dụng
Thunder Client	Ngách	REST client trong VS Code cho kiểm thử cá nhân	Không	Miễn phí + Pro

G2 gộp nhiều loại sản phẩm vào cùng danh mục: nền tảng vòng đời API, iPaaS automation, gateway, analytics và extension IDE. Vì vậy, hãy đọc bảng xếp hạng theo hướng “công cụ này tối ưu cho bước nào trong vòng đời API?” thay vì “công cụ nào đứng cao hơn?”.

Apidog: Công cụ dẫn đầu cho workflow API từ đầu đến cuối

Apidog giành vị trí Dẫn đầu nhờ gom bốn bước chính của vòng đời API vào một workspace:

Thiết kế API
Kiểm thử API
Tạo mock server
Xuất tài liệu API

Thay vì dùng nhiều công cụ riêng lẻ cho OpenAPI, Postman collection, mock server và documentation site, nhóm có thể quản lý tất cả trong cùng một nơi.

Khi nào nên dùng Apidog?

Dùng Apidog nếu nhóm của bạn cần:

Viết và duy trì đặc tả OpenAPI 3.0/3.1
Tạo request/test case từ cùng một schema
Cho frontend gọi mock API trước khi backend hoàn tất
Xuất tài liệu công khai hoặc nội bộ
Review thay đổi API theo nhánh
Đồng bộ backend, frontend và QA trên một nguồn sự thật chung

Một workflow thực tế có thể là:

1. Backend định nghĩa endpoint trong Apidog
2. QA tạo test case từ endpoint đó
3. Frontend dùng mock response để phát triển UI
4. Tech lead review thay đổi API theo branch
5. Nhóm publish documentation cho người dùng nội bộ hoặc khách hàng

Ví dụ workflow thiết kế trước

Giả sử nhóm cần thêm endpoint tạo đơn hàng:

POST /orders
Content-Type: application/json

Request body:

{
  "customerId": "cus_123",
  "items": [
    {
      "sku": "book_001",
      "quantity": 2
    }
  ]
}

Response thành công:

{
  "id": "ord_789",
  "status": "created",
  "total": 420000
}

Trong Apidog, nhóm có thể:

Định nghĩa schema cho Order, OrderItem, Customer
Sinh mock response từ schema
Tạo test kiểm tra status code 201
Kiểm tra field bắt buộc như id, status, total
Publish endpoint vào tài liệu API

Ví dụ assertion cơ bản:

pm.test("Status code is 201", function () {
  pm.response.to.have.status(201);
});

pm.test("Response has order id", function () {
  const json = pm.response.json();
  pm.expect(json.id).to.be.a("string");
});

Điểm mạnh

Apidog phù hợp với các nhóm khoảng 100 kỹ sư trở xuống muốn có một nguồn thông tin duy nhất cho đặc tả API. Backend thiết kế endpoint, QA viết test, frontend lấy mock, còn tài liệu được tạo từ cùng một định nghĩa.

Theo nội dung gốc, các nhóm báo cáo giảm 50–60% thời gian từ đặc tả đến kiểm thử tích hợp đầu tiên. Các đánh giá G2 Spring 2026 cũng nhắc đến review thiết kế theo branch và trình chỉnh sửa OpenAPI 3.1 như điểm khác biệt so với Stoplight và SwaggerHub.

Bạn có thể tải xuống Apidog và nhập Postman collection chỉ với một cú nhấp chuột. Không yêu cầu thẻ tín dụng; gói miễn phí đủ cho nhiều nhóm nhỏ.

viaSocket: Dẫn đầu cho tích hợp không mã

viaSocket là công cụ Dẫn đầu còn lại, nhưng không cùng loại với Apidog. Đây là một nền tảng tự động hóa workflow AI, gần với Zapier hoặc Make hơn là API gateway truyền thống.

viaSocket phù hợp khi bạn cần kết nối các ứng dụng SaaS bằng:

Webhook
Logic điều kiện
API call tùy chỉnh
JavaScript tùy chỉnh
Workflow không cần nhóm kỹ thuật triển khai riêng

Khi nào nên dùng viaSocket?

Dùng viaSocket nếu workflow của bạn giống như:

1. Có lead mới trong CRM
2. Gửi dữ liệu sang Google Sheets
3. Gọi webhook nội bộ
4. Gửi thông báo Slack
5. Tạo ticket trong helpdesk

Pseudo-flow:

Trigger: New HubSpot Contact
Condition: contact.country == "VN"
Action 1: Send custom API request to internal endpoint
Action 2: Notify sales channel in Slack
Action 3: Add row to Google Sheets

Điểm mạnh

Nhiều tích hợp SaaS có sẵn
Hỗ trợ custom API call và webhook
Phù hợp với người không phải developer
Thiết lập nhanh cho workflow vận hành

Điểm yếu

viaSocket không phải API gateway. Nó không thay thế được:

Rate limiting
OAuth flow
Contract testing
API design workflow
Mock server
Developer documentation

Giá bắt đầu từ 50 USD/tháng cho tài khoản tạo sau tháng 9 năm 2025, có thể không phù hợp với thử nghiệm cá nhân giá rẻ.

Chọn viaSocket nếu nhóm vận hành, marketing hoặc revenue cần kết nối công cụ SaaS. Nếu bạn đang phát hành API công khai hoặc quản lý microservice nội bộ, hãy chọn công cụ khác.

Traefik Labs: Gateway mã nguồn mở với quản lý API đi kèm

Traefik Proxy là proxy ứng dụng cloud-native mã nguồn mở. Traefik Hub là lớp thương mại bổ sung các tính năng quản lý API như developer portal, lifecycle control và GitOps management.

Traefik đạt nhóm Hiệu suất cao nhờ mức độ hài lòng tốt; hiện diện thị trường trên G2 có thể bị ảnh hưởng bởi việc nhiều người dùng OSS không xuất hiện trong đánh giá G2.

Khi nào nên dùng Traefik?

Dùng Traefik nếu bạn đang chạy:

Kubernetes
Microservices
Ingress routing
Dynamic service discovery
GitOps-based infrastructure
Edge routing hoặc API gateway layer

Ví dụ cấu hình IngressRoute:

apiVersion: traefik.io/v1alpha1
kind: IngressRoute
metadata:
  name: orders-api
spec:
  entryPoints:
    - websecure
  routes:
    - match: Host(`api.example.com`) && PathPrefix(`/orders`)
      kind: Rule
      services:
        - name: orders-service
          port: 8080

Điểm mạnh

Cloud-native, hợp với Kubernetes
Hỗ trợ service discovery và cấu hình động
Tự động Let’s Encrypt
Quản lý GitOps với API, route và policy trong Git
Có tính năng AI Gateway trong năm 2026, bao gồm hỗ trợ OpenAI Responses API như một endpoint được quản lý

Điểm khó

Traefik không phải công cụ thiết kế API hoặc kiểm thử API. Nếu bạn cần quản lý schema, mock, test và docs, hãy kết hợp Traefik ở lớp gateway với Apidog ở giai đoạn thiết kế và kiểm thử.

Các tính năng doanh nghiệp như LDAP, portal nâng cao và RBAC nằm trong Traefik Hub, không phải trong OSS Proxy.

Đọc thêm: công cụ quản lý API mã nguồn mở và nền tảng quản lý API hàng đầu cho nhóm doanh nghiệp.

Rasayel: Nền tảng WhatsApp Business API

Rasayel nằm trong danh mục này vì cung cấp REST API và GraphQL API, giới hạn tốc độ 200 request/phút trên REST, cùng giao diện quản lý API key với quyền đọc/ghi theo scope.

Tuy nhiên, về bản chất, Rasayel là nền tảng WhatsApp Business với:

Team inbox
Chatbot
Bulk messaging
Tích hợp CRM như HubSpot hoặc Pipedrive
Webhook cho sự kiện WhatsApp

Khi nào nên dùng Rasayel?

Dùng Rasayel nếu bạn cần:

WhatsApp Business
→ shared team inbox
→ chatbot
→ webhook
→ CRM sync
→ API access

Ví dụ use case:

Khi khách hàng gửi tin nhắn WhatsApp, tạo lead trong CRM
Khi trạng thái đơn hàng thay đổi, gửi thông báo qua WhatsApp
Khi agent phản hồi, đồng bộ lịch sử hội thoại về hệ thống nội bộ

Khi nào không nên dùng?

Bỏ qua Rasayel nếu bạn:

Đang quản lý microservice nội bộ
Cần API gateway biên
Không dùng WhatsApp trong hệ thống
Cần contract testing, mock server hoặc API documentation workflow

Rasayel mạnh trong một use case hẹp. Nó không phải điểm khởi đầu cho hầu hết quyết định về nền tảng API tổng quát.

Backendless: BaaS với REST và GraphQL tự động tạo

Backendless là nền tảng backend-as-a-service. Khi bạn định nghĩa mô hình dữ liệu, Backendless tự tạo endpoint REST và GraphQL.

Workflow điển hình:

1. Tạo bảng dữ liệu
2. Định nghĩa field và quan hệ
3. Backendless sinh REST/GraphQL API
4. Ứng dụng mobile/web gọi API qua SDK hoặc HTTP
5. Theo dõi request theo method, client type và trạng thái thành công/lỗi

Khi nào nên dùng Backendless?

Dùng Backendless nếu bạn muốn tránh xây backend từ đầu, đặc biệt cho:

MVP
Mobile app
Internal tool
Startup nhỏ
Nhóm không muốn vận hành backend riêng

Ví dụ cách nghĩ:

Tôi cần user auth, database, file storage, REST API và GraphQL API nhanh.
Tôi không muốn tự dựng server, ORM, auth layer và dashboard.

Điểm mạnh

Low-code backend
SDK cho Android, iOS, JavaScript và .NET
Role-based security theo từng operation
Theo dõi service-level call
Tạo API từ mô hình dữ liệu

Điểm yếu

Backendless không phù hợp nếu bạn:

Đã có backend/microservice và cần gateway phía trước
Muốn contract-first API design
Cần triển khai tại chỗ để tránh vendor lock-in
Cần kiểm soát sâu hạ tầng runtime

Backendless phù hợp khi câu hỏi là “làm sao có backend nhanh?”. Nếu câu hỏi là “làm sao quản lý các service hiện có?”, hãy xem gateway, API design platform hoặc analytics layer.

Moesif, một công ty của WSO2: API analytics và monetization

Moesif nằm nhóm Ngách theo thiết kế. Nó không phải gateway, không phải công cụ thiết kế API, mà là lớp quan sát và kiếm tiền từ API đã chạy.

WSO2 mua lại Moesif vào tháng 5 năm 2025 và đang tích hợp nó như một lớp phân tích cho nền tảng Choreo của WSO2. Moesif vẫn hoạt động như một công ty con độc lập với lộ trình riêng.

Moesif giải quyết vấn đề gì?

Dùng Moesif khi bạn cần biết:

Ai đang gọi API?
Endpoint nào được dùng nhiều nhất?
Khách hàng nào gây lỗi nhiều nhất?
Request tăng bất thường ở khu vực nào?
Gói giá nào đang tạo doanh thu?
Người dùng API có bị drop ở bước nào trong funnel?

Một luồng triển khai điển hình:

API Gateway / Backend
→ Moesif middleware hoặc plugin
→ Event tracking
→ Usage analytics
→ Customer dashboard
→ Billing hoặc monetization workflow

Khi nào nên dùng?

Moesif phù hợp nếu bạn:

Đã phát hành API công khai
Cần phân tích usage theo user, endpoint, region
Đang chuyển sang pricing theo usage
Cần billing dựa trên metered usage
Cần dashboard khách hàng cho API product

Khi nào không nên dùng?

Moesif không phù hợp nếu:

Bạn chưa có API public
Bạn cần gateway thay vì analytics
Bạn cần thiết kế API, mock hoặc documentation
Bạn là developer độc lập chỉ cần test endpoint

Moesif nằm bên cạnh gateway và backend, không thay thế chúng.

Thunder Client: REST client trong VS Code

Thunder Client là extension VS Code để gửi HTTP request, tương tự Postman hoặc Insomnia nhưng chạy ngay trong editor. Vị trí Ngách phản ánh sự hài lòng cao của developer cá nhân: nhẹ, nhanh, không cần app riêng.

Khi nào nên dùng Thunder Client?

Dùng Thunder Client nếu bạn là developer cá nhân và muốn test endpoint ngay trong VS Code:

GET http://localhost:3000/api/users
Authorization: Bearer {{token}}

Ví dụ collection được lưu dưới dạng JSON trong repository:

{
  "name": "Local API",
  "requests": [
    {
      "method": "GET",
      "url": "http://localhost:3000/api/users"
    }
  ]
}

Điểm mạnh

Không cần rời VS Code
Nhẹ và nhanh
Collection lưu dạng JSON, thân thiện với Git
Hỗ trợ environment variable
Có scripting và assertion cơ bản

Không phù hợp cho

Thunder Client không phải:

Nền tảng cộng tác nhóm đầy đủ
Công cụ thiết kế API
API gateway
Mock server
Công cụ tạo documentation
Nền tảng quản lý vòng đời API

Các tính năng cộng tác nằm sau tường phí Pro, đây là điểm gây khó chịu với nhiều nhóm. Xem thêm: Thunder Client cho nhóm: hạn chế về cộng tác.

Nếu “quản lý API” của bạn chỉ là “gửi request khi đang code”, Thunder Client đủ tốt. Nếu nhóm cần cộng tác, mock, docs và test chung, Apidog bao phủ rộng hơn.

Cách chọn công cụ phù hợp cho nhóm của bạn

Hãy bắt đầu bằng câu hỏi kỹ thuật, không phải bằng bảng xếp hạng.

1. “Quản lý API” trong hệ thống của bạn nghĩa là gì?

Nhu cầu chính	Công cụ phù hợp
Thiết kế, test, mock, docs	Apidog
Gateway, routing, JWT, rate limiting	Traefik
Analytics và monetization cho API đã phát hành	Moesif
Kết nối SaaS app bằng webhook	viaSocket
Tạo backend nhanh từ đầu	Backendless
WhatsApp Business API	Rasayel
Test REST trong VS Code	Thunder Client

2. Bao nhiêu người sẽ dùng?

1 developer: Thunder Client hoặc gói miễn phí của Apidog
5–50 người: Apidog cho workflow API end-to-end; Backendless nếu cần BaaS; Traefik Hub nếu trọng tâm là gateway
100+ developer: thường kết hợp nhiều lớp:
- Traefik hoặc Kong ở edge/gateway
- Moesif cho analytics
- Apidog cho thiết kế, mock, test và docs

3. Hạn chế chính là tiền, thời gian hay quản trị?

Hạn chế	Lựa chọn thực tế
Tiền	Gói miễn phí Apidog, Traefik Proxy OSS, gói miễn phí Backendless
Thời gian	Apidog cho thiết kế + test nhanh; viaSocket cho no-code automation
Quản trị	Traefik Hub cho GitOps; Apidog cho branch-based design review; Moesif cho analytics có thể audit

Đọc thêm: công cụ kiểm thử API cho nhóm 50 kỹ sư và so sánh nền tảng API thiết kế trước.

Một stack API thực tế có thể trông như thế nào?

Không phải lúc nào bạn cũng chọn một công cụ duy nhất. Với nhóm đang xây API nghiêm túc, stack có thể tách theo lớp:

API Design + Mock + Test + Docs
→ Apidog

Gateway + Routing + TLS + Policy
→ Traefik

Usage Analytics + Monetization
→ Moesif

Internal SaaS Automation
→ viaSocket

Ví dụ workflow triển khai:

1. Product và backend định nghĩa contract API trong Apidog
2. Frontend dùng mock API để phát triển song song
3. QA tạo test suite từ spec
4. Backend triển khai service thật
5. Traefik route traffic đến service
6. Moesif thu thập usage analytics
7. viaSocket xử lý workflow SaaS phụ trợ nếu cần

Cách tách lớp này giúp tránh dùng sai công cụ. Gateway không nên thay thế API design tool. REST client cá nhân không nên thay thế collaboration platform. Analytics layer không nên thay thế mock server.

Những gì Bảng xếp hạng Spring 2026 dạy bạn

Bảy công cụ trong Bảng xếp hạng Quản lý API G2 Spring 2026 không hoàn toàn cạnh tranh trực tiếp với nhau. Chúng cạnh tranh với công cụ bạn sẽ chọn nếu không phân tách rõ bài toán.

Các điểm cần nhớ:

Hai công cụ Dẫn đầu giải quyết hai vấn đề khác nhau: Apidog cho workflow vòng đời API, viaSocket cho no-code integration.
Nhóm Hiệu suất cao mạnh ở các phạm vi cụ thể: Traefik cho gateway, Rasayel cho WhatsApp, Backendless cho BaaS.
Nhóm Ngách không có nghĩa là yếu; Moesif và Thunder Client rất mạnh trong phạm vi riêng.
Stack tiết kiệm có thể bắt đầu bằng gói miễn phí Apidog + Traefik Proxy OSS + gói miễn phí Moesif.

Nếu nhóm của bạn đang xử lý thiết kế, kiểm thử, mock và tài liệu API, hãy bắt đầu với Apidog. Đây là công cụ Dẫn đầu vì bao phủ phần workflow mà hầu hết nhóm API dành nhiều thời gian nhất. Bạn có thể tải xuống Apidog và nhập thiết kế API từ Postman trong vài phút.

Nếu trọng tâm của bạn là gateway, hãy xem thêm top 10 API gateway tốt nhất cho developer năm 2026.

Hướng Dẫn Sử Dụng OpenAI Codex Trên Điện Thoại: iOS & Android 2026

Sebastian Petrus — Fri, 15 May 2026 03:09:30 +0000

OpenAI đã ra mắt Codex trên thiết bị di động trong tuần này. Vào ngày 14 tháng 5 năm 2026, ứng dụng ChatGPT trên iOS và Android đã bổ sung trải nghiệm Codex đầy đủ tính năng cho mọi gói, bao gồm Free và Go. Bạn có thể giám sát tác vụ đang chạy, phê duyệt lệnh, đổi mô hình và bắt đầu công việc mới từ điện thoại, ngay cả khi laptop không còn mở trước mặt bạn.

Dùng thử Apidog ngay hôm nay

Độc giả của Apidog đã hỏi khi nào công cụ lập trình AI nghiêm túc sẽ có mặt trên điện thoại. Câu trả lời là: bây giờ. Bài viết này tập trung vào những gì đã được phát hành, cách thiết lập và các workflow nên thử trước.

Nếu bạn muốn bắt đầu từ terminal, Apidog có hướng dẫn thiết lập cho Codex CLI. Nếu muốn so sánh với Anthropic và Cursor trên di động, hãy xem bài viết về Claude Code trên di động và bài đăng Chạy Cursor trên điện thoại của bạn. Hoặc tải Apidog để bắt đầu xây dựng các API mà Codex trên điện thoại của bạn có thể sử dụng khi bạn di chuyển.

"Codex từ mọi nơi" có nghĩa là gì

Thông báo của OpenAI không chỉ nói về mobile. "Codex từ mọi nơi" bao gồm bốn bề mặt sử dụng chính:

Codex trong ứng dụng di động ChatGPT: iOS, Android, bản xem trước, hỗ trợ mọi gói.
Codex trong Slack: dành cho Plus, Pro, Business, Enterprise, Edu; gọi bằng @Codex trong cuộc trò chuyện.
Tiện ích mở rộng Codex Chrome: ra mắt ngày 7 tháng 5 năm 2026; hoạt động trên các tab mà không chiếm quyền điều khiển trình duyệt.
Codex SDK: điều khiển Codex bằng lập trình từ script, scheduler hoặc CI.

Mobile là phần dễ thấy nhất, nhưng Slack và SDK mới là phần quyết định Codex có đi vào workflow nhóm hay không. Ví dụ: một kỹ sư có thể giao việc cho Codex từ Slack, sau đó kiểm tra diff và phê duyệt từ điện thoại khi tác vụ hoàn tất.

Codex trên iOS và Android: cách thiết lập

Trải nghiệm mobile nằm trong ứng dụng ChatGPT hiện có. Bạn không cần cài app Codex riêng.

Bước 1: Cập nhật ứng dụng ChatGPT

Mở App Store trên iOS hoặc Play Store trên Android, sau đó cập nhật ChatGPT lên phiên bản mới nhất.

Theo nhật ký thay đổi của Codex, Codex di động yêu cầu bản phát hành ngày 13 tháng 5 năm 2026 trở lên.

Bước 2: Đăng nhập đúng tài khoản

Đăng nhập bằng cùng tài khoản OpenAI mà bạn dùng cho ChatGPT, Codex web hoặc Codex CLI.

Codex mobile sẽ hiển thị cùng các cuộc trò chuyện, môi trường và máy chủ đã kết nối với tài khoản đó.

Bước 3: Kết nối môi trường đám mây

Nếu trước đây bạn chỉ dùng Codex từ terminal, bạn cần cấu hình ít nhất một môi trường đám mây để ứng dụng di động có thể giao tiếp.

Trên web app:

Mở Settings.
Vào Codex.
Chọn Environments.
Liên kết GitHub.
Cấu hình một repository.

Sau khi hoàn tất, ứng dụng mobile sẽ kế thừa cấu hình này.

Bước 4: Mở tab Codex trên điện thoại

Trong ứng dụng ChatGPT, chạm vào tab Codex ở thanh điều hướng dưới cùng.

Bạn sẽ thấy danh sách tác vụ, cuộc trò chuyện và trạng thái các lần chạy đang hoạt động.

Bước 5: Chạy một tác vụ nhỏ để kiểm tra

Đừng bắt đầu bằng refactor lớn. Hãy thử một tác vụ nhỏ trước, ví dụ:

Thêm docstring cho hàm validateUserInput trong src/utils/validation.ts.
Không đổi logic hiện tại.

Hoặc:

Cập nhật README với một ví dụ curl cho endpoint /health.

Sau đó:

Chờ Codex tạo diff.
Mở diff trên điện thoại.
Kiểm tra file thay đổi.
Chạm Approve nếu đúng.
Xác nhận PR hoặc thay đổi đã được cập nhật trong repository.

Nếu vòng lặp nhỏ này chạy ổn, bạn có thể chuyển sang các tác vụ dài hơn như thêm test, chỉnh tài liệu hoặc refactor nhiều file.

Bạn có thể làm gì từ điện thoại?

Codex mobile không thay thế IDE. Nó đóng vai trò là bảng điều khiển để giao việc, theo dõi và phê duyệt.

Từ điện thoại, bạn có thể:

Xem các lần chạy trực tiếp trên laptop, devbox hoặc môi trường từ xa đã kết nối.
Duyệt các cuộc trò chuyện và chuyển giữa nhiều tác vụ song song.
Xem diff trước khi thay đổi được merge vào branch.
Phê duyệt lệnh mà Codex muốn chạy trên môi trường của bạn.
Chuyển đổi mô hình nếu tác vụ cần mô hình mạnh hơn.
Bắt đầu tác vụ mới từ prompt hoặc issue GitHub.
Bình luận trên pull request do Codex mở trong repository.

OpenAI mô tả workflow này như sau: "Từ điện thoại của bạn, bạn có thể làm việc trên tất cả các cuộc trò chuyện của mình, xem lại kết quả đầu ra, phê duyệt lệnh, thay đổi mô hình hoặc bắt đầu điều gì đó mới."

Hạn chế quan trọng: mobile chưa phải là trình soạn thảo mã đầy đủ. Bạn không nên kỳ vọng viết code trực tiếp như trong VS Code. Codex viết mã; bạn điều phối, review và phê duyệt.

Slack: giao việc cho Codex từ cuộc trò chuyện nhóm

Tích hợp Slack được phát hành cùng mobile. Đây là cách đưa Codex vào workflow nhóm mà không yêu cầu mọi người mở dashboard riêng.

Cách hoạt động

Sau khi quản trị viên workspace cài ứng dụng Codex Slack từ Marketplace, thành viên có thể gọi Codex bằng cách gắn thẻ @Codex trong kênh hoặc thread.

Ví dụ:

@Codex kiểm tra issue #142 và đề xuất bản sửa lỗi tối thiểu.

Hoặc chỉ định repository rõ hơn:

@Codex trong repo apidog/awesome-api, thêm test cho endpoint GET /projects/{id}.

Bot sẽ:

Chọn môi trường phù hợp từ cấu hình hiện có.
Mặc định dùng repository đầu tiên trong environment map nếu bạn không chỉ định repo.
Phản hồi bằng emoji, đăng link tác vụ và bắt đầu chạy.
Trả kết quả trong thread khi tác vụ hoàn tất.

Những gì bạn cần

Để dùng Codex trong Slack, bạn cần:

Gói ChatGPT Plus, Pro, Business, Enterprise hoặc Edu.
Tài khoản GitHub đã kết nối.
Ít nhất một môi trường đám mây đã cấu hình.
Quyền cài ứng dụng hoặc phê duyệt từ quản trị viên Slack workspace.

Lưu ý: gói Free không có tích hợp Slack.

Với doanh nghiệp, quản trị viên có thể tắt việc Codex đăng câu trả lời trực tiếp vào kênh và buộc bot chỉ chia sẻ link tác vụ. Cách này giúp mã được tạo không xuất hiện trong lịch sử Slack.

Workflow nên thử

Một workflow thực tế:

Issue mới được thảo luận trong kênh Slack.
Một kỹ sư gọi @Codex để yêu cầu đề xuất bản sửa.
Codex mở tác vụ hoặc PR.
Người phụ trách review diff trên điện thoại.
CI chạy test.
Nếu đạt, người phụ trách approve hoặc merge.

Nếu bạn quan tâm đến tự động hóa triage issue GitHub, Bot phân loại vấn đề GitHub OpenClaw cũng là một mô hình đáng tham khảo.

Codex SDK: điều khiển bằng lập trình

Codex SDK phù hợp với nhóm muốn tích hợp Codex vào script, scheduler hoặc CI.

Một dạng sử dụng phổ biến:

from openai import Codex

client = Codex()

task = client.tasks.create(
    repo="apidog/awesome-api",
    prompt="Add OpenAPI examples to every endpoint missing them.",
    environment="prod-mirror",
)

for event in client.tasks.stream(task.id):
    print(event.summary)

Bạn có thể dùng SDK trong các workflow như:

Job hằng đêm để mở PR xử lý issue cũ.
Bước pre-merge để yêu cầu Codex viết test còn thiếu.
Script nội bộ để cập nhật tài liệu API.
Công cụ triage tự động cho repository lớn.

Với Enterprise workspace, bạn có thể tạo access token cho các luồng không tương tác. Khả năng này được phát hành vào ngày 5 tháng 5 năm 2026.

Nếu nhóm của bạn đã chạy Claude Code với GitHub Actions, Codex SDK lấp đầy khoảng trống tương tự ở phía OpenAI.

Các gói, giá cả và tính khả dụng

Bản xem trước trên mobile mở cho mọi gói, bao gồm Free và Go. Các nền tảng khác có giới hạn theo cấp độ.

Nền tảng	Miễn phí	Go	Plus	Pro	Business	Enterprise / Giáo dục
Di động (iOS + Android)	Có (xem trước)	Có	Có	Có	Có	Có
Tích hợp Slack	Không	Không	Có	Có	Có	Có
Tiện ích mở rộng Chrome	Có (xem trước)	Có	Có	Có	Có	Có
Codex SDK	Giới hạn	Giới hạn	Có	Có	Có	Có
Mã thông báo truy cập Enterprise	Không	Không	Không	Không	Không	Có

Để đọc sâu hơn về chi phí theo cấp độ, xem bảng phân tích giá GPT-5.5. Nếu muốn thử Codex mà không phải trả phí, hướng dẫn Codex miễn phí cho mã nguồn mở sẽ hướng dẫn cách đăng ký.

Codex trên điện thoại so với các lựa chọn thay thế

Các tác nhân lập trình trên mobile đã trở thành một danh mục riêng. Ba lựa chọn đáng chú ý:

OpenAI Codex: UX mobile mạnh, tích hợp chặt với ChatGPT, có sẵn trên gói Free.
Claude Code trên di động: Thiết lập Claude Code di động thường dựa trên phiên tmux và SSH client. Tự làm nhiều hơn, nhưng phù hợp với công việc terminal chạy dài.
Cursor trên điện thoại: Workflow mobile của Cursor dựa vào remote development và web preview của Cursor. Hợp lý nếu bạn đã dùng Cursor trên desktop.

Nếu muốn so sánh chi tiết trước khi chọn workflow mobile, hãy đọc phân tích Claude Code vs Codex 2026. Bài so sánh Copilot vs Claude vs Cursor vs Codex bao quát nhiều lựa chọn hơn.

Còn API của bạn thì sao?

Một tác nhân lập trình trên điện thoại chỉ hữu ích nếu mã nó tạo ra hoạt động đúng trong môi trường thật. Với nhiều nhóm, API là phần dễ hỏng nhất.

Apidog cung cấp API client, trình soạn thảo OpenAPI và test runner tự động có thể chạy trên laptop hoặc trong CI.

Một workflow thực tế:

Codex, từ mobile hoặc Slack, mở PR liên quan đến một endpoint.
CI chạy bộ kiểm thử OpenAPI hiện có bằng Apidog trên preview deployment của PR.
Nếu test pass, bạn review diff trên điện thoại.
Nếu diff hợp lý, bạn approve hoặc merge.
Nếu test fail, bạn yêu cầu Codex sửa theo log lỗi.

Ví dụ prompt có thể dùng sau khi CI fail:

CI đang fail ở test OpenAPI cho endpoint POST /orders.
Đọc log lỗi, xác định nguyên nhân và đề xuất bản sửa tối thiểu.
Không thay đổi schema nếu không cần thiết.

Hướng dẫn kiểm thử API ChatGPT bằng Apidog và bài Cách kiểm thử các tác nhân AI gọi API của bạn bao gồm các phần kết nối. Bạn cũng có thể tải Apidog nếu muốn thử workflow này.

Các câu hỏi thường gặp

Codex trên di động có hoạt động ngoại tuyến không?

Không. Codex chạy trên đám mây của OpenAI hoặc môi trường đã kết nối của bạn. Khi không có mạng, ứng dụng có thể hiển thị trạng thái cuối cùng đã biết, nhưng không thể bắt đầu tác vụ mới.

Tôi có thể chỉnh sửa mã trực tiếp trong ứng dụng di động không?

Không theo cách bạn chỉnh trong IDE. Bạn có thể viết prompt, xem diff, bình luận và phê duyệt. Mobile là giao diện điều khiển cho tác nhân từ xa, không phải trình soạn thảo mã đầy đủ.

Phiên bản di động có chậm hơn máy tính để bàn không?

Tác nhân vẫn chạy trên cùng backend. Điểm chậm hơn thường đến từ màn hình nhỏ: diff dài khó đọc hơn trên điện thoại. Workflow hợp lý là đọc tóm tắt và phê duyệt thay đổi nhỏ trên mobile, còn review lớn thì chuyển sang desktop.

Codex di động có hỗ trợ nhập liệu bằng giọng nói không?

Có, thông qua chế độ giọng nói hiện có của ChatGPT. Bạn có thể đọc prompt cho Codex giống như khi nhập một tin nhắn ChatGPT khác.

Điều gì xảy ra nếu tôi mất tín hiệu khi đang phê duyệt?

Tác vụ vẫn tiếp tục chạy phía cloud. Khi kết nối lại, trạng thái sẽ được cập nhật. Codex không yêu cầu phiên mobile luôn mở để tiếp tục hoạt động.

Quản trị viên doanh nghiệp có thể tắt Codex di động không?

Có. Chủ sở hữu workspace có thể hạn chế quyền truy cập Codex từ bảng quản trị. Các nút chuyển đổi kiểm soát quyền truy cập trên desktop cũng áp dụng cho mobile.

Codex trên di động có tốn thêm chi phí không?

Không có phí riêng cho ứng dụng mobile. Chi phí phụ thuộc vào gói và năng lực Codex cơ bản bạn đang sử dụng. Bài viết về giá Codex có phân tích chi tiết hơn.

Cái này có khác với mô hình "Codex" cũ không?

Có. Codex hiện tại là sản phẩm tác nhân lập trình, không phải mô hình Codex 2021 đã ngừng phát triển. Nếu bạn vẫn nghĩ đến endpoint API cũ, phần giới thiệu Codex CLI sẽ giúp bạn cập nhật cách sản phẩm hoạt động trong năm 2026.

Hãy thử ngay tối nay

Vòng lặp nhỏ nhất:

Cập nhật ứng dụng ChatGPT.
Đăng nhập đúng tài khoản.
Liên kết một môi trường Codex.
Chọn một repository nhỏ.
Yêu cầu Codex sửa một dòng trong README.
Review diff trên điện thoại.
Phê duyệt nếu đúng.

Sau khi workflow đó chạy ổn, hãy thêm Slack để giao việc từ cuộc trò chuyện nhóm, rồi dùng SDK nếu bạn muốn tự động hóa bằng CI hoặc script nội bộ.

Nếu muốn giữ hợp đồng API chính xác trong khi Codex tạo mã từ điện thoại, hãy kết hợp nó với Apidog. Tác nhân viết mã; bộ kiểm thử phát hiện lỗi hồi quy.

Hướng Dẫn Sử Dụng API ERNIE 5.1 Chi Tiết

Sebastian Petrus — Thu, 14 May 2026 08:39:35 +0000

ERNIE 5.1 ra mắt ngày 9 tháng 5 năm 2026, và trong vòng một tuần, API Qianfan đã hỗ trợ mô hình này. Nếu bạn muốn gọi ERNIE 5.1 từ mã nguồn, định tuyến tool call, hoặc đưa nó vào vòng lặp tác nhân với Apidog, bài viết này hướng dẫn từng bước: tạo tài khoản, lấy khóa, gửi request, streaming, tool calling và xử lý lỗi.

Dùng thử Apidog ngay hôm nay

Mục tiêu là có thể chạy được ngay. Bạn sẽ có ví dụ curl, Python, Node.js và một bộ request có thể nhập vào Apidog để kiểm thử.

Nếu bạn chưa đọc bài phân tích ra mắt ERNIE 5.1, hãy đọc lướt trước; bài đó bao gồm benchmark và so sánh với DeepSeek V4 và Kimi K2.6. Bài này tập trung vào phần triển khai.

Bước 1: Lấy khóa API Qianfan

ERNIE 5.1 được cung cấp qua nền tảng Qianfan của Baidu Intelligent Cloud. Không có “API ERNIE” riêng biệt; tất cả request đều đi qua Qianfan.

Thực hiện các bước sau:

Truy cập cloud.baidu.com và tạo hoặc đăng nhập tài khoản Baidu Intelligent Cloud. Nhà phát triển quốc tế có thể đăng ký bằng email; một số tính năng doanh nghiệp vẫn yêu cầu số điện thoại Trung Quốc đại lục.
Mở bảng điều khiển Qianfan tại console.bce.baidu.com/qianfan.
Vào Quản lý khóa API (API Key 管理) và chọn Tạo khóa API.
Chọn workspace và cấp quyền truy cập dịch vụ chat-completions.
Sao chép khóa. Khóa có dạng bce-v3/ALTAK-xxxx/xxxx.

Không hard-code khóa trong source code. Lưu vào biến môi trường:

export QIANFAN_API_KEY="bce-v3/ALTAK-xxxx/xxxx"

Có hai điểm cần lưu ý:

Endpoint v2 dùng Bearer token duy nhất. Luồng access_token OAuth v1 cũ đang bị loại bỏ, không nên dùng cho mã mới.
ERNIE 5.1 là mô hình trả phí ngay từ đầu. Hãy nạp một số dư nhỏ, ví dụ ¥10, trước khi gửi request đầu tiên.

Bước 2: Gửi request bằng curl tới endpoint tương thích OpenAI

Qianfan cung cấp endpoint chat-completions tương thích với OpenAI. Nếu hệ thống của bạn đã dùng định dạng OpenAI, bạn chỉ cần đổi base URL và model ID.

Base URL: https://qianfan.baidubce.com/v2
Model ID: ernie-5.1
Model preview: ernie-5.1-preview cho một số tính năng truy cập sớm

Request tối thiểu:

curl https://qianfan.baidubce.com/v2/chat/completions \
  -H "Authorization: Bearer $QIANFAN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "ernie-5.1",
    "messages": [
      {"role": "system", "content": "You are a senior API designer."},
      {"role": "user", "content": "Sketch a REST schema for a GitHub-style PR review API. Be concise."}
    ],
    "temperature": 0.3
  }'

Response có dạng tương thích OpenAI:

{
  "id": "chatcmpl-...",
  "object": "chat.completion",
  "created": 1746780000,
  "model": "ernie-5.1",
  "choices": [
    {
      "index": 0,
      "message": { "role": "assistant", "content": "..." },
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 42,
    "completion_tokens": 318,
    "total_tokens": 360
  }
}

Cách xử lý lỗi nhanh:

401 Unauthorized: khóa sai hoặc đã hết hạn.
403: khóa hợp lệ nhưng workspace chưa bật model ERNIE 5.1. Vào console và thêm model vào danh sách được phép.

Bước 3: Gọi ERNIE 5.1 từ Python

Vì endpoint tương thích OpenAI, bạn có thể dùng SDK Python openai và chỉ cần đổi base_url.

Cài SDK nếu chưa có:

pip install openai

Ví dụ gọi chat completion:

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["QIANFAN_API_KEY"],
    base_url="https://qianfan.baidubce.com/v2",
)

response = client.chat.completions.create(
    model="ernie-5.1",
    messages=[
        {"role": "system", "content": "You explain APIs in plain English."},
        {"role": "user", "content": "Why would I use server-sent events over WebSockets for a chat UI?"},
    ],
    temperature=0.4,
)

print(response.choices[0].message.content)
print(f"\nTokens used: {response.usage.total_tokens}")

Nếu bạn đã có wrapper quanh OpenAI SDK, thử nghiệm A/B với ERNIE 5.1 thường chỉ cần đổi base_url và model. Cách này cũng tương tự với API của DeepSeek và nhiều nhà cung cấp mô hình Trung Quốc khác.

Bước 4: Streaming token cho giao diện chat

Với UI chat, nên bật streaming để người dùng thấy phản hồi ngay khi model sinh token.

Trong Python, đặt stream=True:

stream = client.chat.completions.create(
    model="ernie-5.1",
    messages=[{"role": "user", "content": "Write a haiku about API versioning."}],
    stream=True,
)

for chunk in stream:
    delta = chunk.choices[0].delta.content
    if delta:
        print(delta, end="", flush=True)

Request curl tương đương để debug:

curl https://qianfan.baidubce.com/v2/chat/completions \
  -H "Authorization: Bearer $QIANFAN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "ernie-5.1",
    "stream": true,
    "messages": [{"role": "user", "content": "Stream a 3-sentence joke."}]
  }' \
  --no-buffer

Định dạng stream giống OpenAI: các dòng data: {...} và kết thúc bằng:

data: [DONE]

Bước 5: Dùng ERNIE 5.1 với tool calling

ERNIE 5.1 được nhấn mạnh ở khả năng dùng công cụ. Theo thông tin ra mắt, mô hình đạt điểm cao hơn DeepSeek-V4-Pro trên τ³-bench và SpreadsheetBench-Verified, nghĩa là tool calling được tối ưu cho các tình huống thực tế hơn là chỉ demo.

Schema tool giống function calling của OpenAI:

tools = [
    {
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "Get current weather for a city.",
            "parameters": {
                "type": "object",
                "properties": {
                    "city": {"type": "string", "description": "City name, e.g. Singapore"},
                    "unit": {"type": "string", "enum": ["celsius", "fahrenheit"]},
                },
                "required": ["city"],
            },
        },
    }
]

response = client.chat.completions.create(
    model="ernie-5.1",
    messages=[{"role": "user", "content": "What's the weather in Tokyo right now?"}],
    tools=tools,
    tool_choice="auto",
)

tool_calls = response.choices[0].message.tool_calls

if tool_calls:
    call = tool_calls[0]
    print(f"Model wants to call: {call.function.name}({call.function.arguments})")

Sau khi code của bạn chạy công cụ thực tế, hãy nối kết quả vào messages dưới dạng message có role tool, rồi gọi lại model. Vòng lặp kết thúc khi:

finish_reason == "stop"

và tool_calls rỗng.

Một điểm nên xử lý phòng ngừa: ERNIE 5.1 đôi khi trả về arguments của tool dưới dạng JSON được bọc trong code block thay vì chuỗi JSON thuần. Hãy parse bằng json.loads() trong try/except; nếu lỗi, loại bỏ phần

```json trước khi parse lại.

Ví dụ helper đơn giản:


python
import json
import re

def parse_tool_arguments(raw):
    try:
        return json.loads(raw)
    except json.JSONDecodeError:
        cleaned = re.sub(r"^

```json|```

$", "", raw.strip(), flags=re.MULTILINE).strip()
        return json.loads(cleaned)

Bước 6: Gọi ERNIE 5.1 từ Node.js

Với dự án Node.js dùng openai v5+, cấu hình tương tự Python.

Cài package:


bash
npm install openai

Ví dụ:


javascript
import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.QIANFAN_API_KEY,
  baseURL: "https://qianfan.baidubce.com/v2",
});

const completion = await client.chat.completions.create({
  model: "ernie-5.1",
  messages: [
    { role: "user", content: "Return a JSON object with 3 API design tips." },
  ],
  response_format: { type: "json_object" },
});

console.log(completion.choices[0].message.content);

response_format: { type: "json_object" } hoạt động và đáng dùng khi bạn cần JSON. Tuy nhiên, JSON schema nghiêm ngặt (json_schema) vẫn đang được triển khai trên Qianfan, nên hãy validate response trong code thay vì chỉ dựa vào ràng buộc từ model.

Ví dụ validate tối thiểu:


javascript
const raw = completion.choices[0].message.content;

let data;
try {
  data = JSON.parse(raw);
} catch {
  throw new Error("Model did not return valid JSON");
}

if (!Array.isArray(data.tips)) {
  throw new Error("Invalid response shape: expected tips array");
}

Bước 7: Kiểm thử và so sánh bằng Apidog

Nếu bạn đang so sánh ERNIE 5.1, DeepSeek V4 và Kimi K2.6, không nên quản lý mọi thứ bằng nhiều lệnh terminal rời rạc. Dùng Apidog để tạo một workspace duy nhất, mỗi nhà cung cấp là một thư mục, cùng body request và môi trường riêng cho từng API key.

Thiết lập trong khoảng 60 giây:

Mở Apidog và tạo project mới tên “LLM bake-off.”

Thêm environment với các biến:


text
QIANFAN_API_KEY
DEEPSEEK_API_KEY
MOONSHOT_API_KEY

Tạo ba request, mỗi request trỏ tới base URL của từng nhà cung cấp.
Đặt model lần lượt là:


text
ernie-5.1
deepseek-chat
kimi-k2-6

Dùng cùng một mảng messages cho cả ba request.
Dùng tính năng Run của Apidog để chạy song song và so sánh output.

Gói miễn phí đủ để làm việc này. Apidog lưu lịch sử request theo environment, nên bạn có thể quay lại tuần sau và chạy lại cùng một bài đánh giá với phiên bản model mới. Cách này dễ kiểm soát hơn nhiều so với việc giữ nhiều lệnh curl trong tmux.

Để xem thêm về kiểm thử đa nhà cung cấp, đọc Kiểm thử LLM cục bộ dưới dạng API và hướng dẫn API GLM 5.1.

Giá cả, giới hạn tốc độ và hạn mức

Giá công khai của Qianfan cho ERNIE 5.1 không có trong bài phát hành. Hãy kiểm tra bảng giá trực tiếp trong console trước khi báo cáo số liệu nội bộ.

Ba điểm thực tế cần xử lý trong quá trình tích hợp:

Rate limit áp dụng theo workspace. Tài khoản mới thường có QPS thấp. Sau khi thử nghiệm xong, hãy nâng giới hạn trong console nếu cần production traffic.
Token usage có trong response. Trường usage gồm prompt_tokens, completion_tokens và total_tokens. Hãy log các giá trị này cho từng request để tự tính chi phí.
Không có prompt caching tự động. Qianfan hiện không cung cấp cơ chế lưu prompt gốc cho ERNIE 5.1 như Anthropic. Nếu system prompt dài 2.000 token, bạn sẽ trả phí cho phần đó ở mỗi lần gọi. Hãy thiết kế prompt và context window cho phù hợp.

Ví dụ log token usage:


python
response = client.chat.completions.create(
    model="ernie-5.1",
    messages=messages,
)

usage = response.usage

print({
    "prompt_tokens": usage.prompt_tokens,
    "completion_tokens": usage.completion_tokens,
    "total_tokens": usage.total_tokens,
})

Xử lý lỗi thường gặp

Các lỗi bạn sẽ gặp trong thực tế:

Trạng thái	Ý nghĩa	Cách khắc phục
`401`	Bearer token sai hoặc đã hết hạn	Tạo lại khóa từ console
`403`	Model chưa được bật cho workspace	Thêm ERNIE 5.1 trong console
`429`	Đạt giới hạn tốc độ	Dừng lại và retry với jitter
`400`	Message không hợp lệ	Kiểm tra thứ tự role user/assistant
`500/502`	Lỗi tạm thời phía Qianfan	Retry một lần; nếu tiếp diễn, kiểm tra trang trạng thái

Mọi lời gọi production nên có retry với exponential backoff, giới hạn tối đa 3 lần. Nếu chạy production, hãy ghi lại request_id từ response headers; bộ phận hỗ trợ của Baidu cần giá trị này khi debug.

Wrapper Python tối thiểu cho production

Nếu muốn đưa ERNIE 5.1 vào ứng dụng ngay, đây là wrapper nhỏ gọn để xử lý phần lớn tình huống phổ biến:


python
import os
import time
import random
from openai import OpenAI, RateLimitError, APIError

client = OpenAI(
    api_key=os.environ["QIANFAN_API_KEY"],
    base_url="https://qianfan.baidubce.com/v2",
)

def chat(messages, *, model="ernie-5.1", temperature=0.3, max_retries=3):
    for attempt in range(max_retries):
        try:
            return client.chat.completions.create(
                model=model,
                messages=messages,
                temperature=temperature,
            )
        except RateLimitError:
            time.sleep((2 ** attempt) + random.random())
        except APIError as e:
            if e.status_code and e.status_code >= 500 and attempt < max_retries - 1:
                time.sleep(1 + attempt)
                continue
            raise

    raise RuntimeError("ERNIE 5.1 retries exhausted")

Dùng wrapper:


python
messages = [
    {"role": "system", "content": "You are a concise API assistant."},
    {"role": "user", "content": "Design a pagination scheme for a REST API."},
]

response = chat(messages)

print(response.choices[0].message.content)

Wrapper này xử lý phần retry cơ bản. Với streaming và tool calling, hãy mở rộng từ cùng cấu trúc này.

Câu hỏi thường gặp

API ERNIE 5.1 có miễn phí không?

Không. Qianfan hoạt động theo mô hình trả tiền theo mức sử dụng. Không có gói miễn phí vĩnh viễn; tài khoản mới đôi khi nhận được credit thử nghiệm. Nếu muốn thử miễn phí, dùng giao diện chat tại ernie.baidu.com hoặc xem các tùy chọn LLM miễn phí.

Tôi có thể chạy ERNIE 5.1 cục bộ không?

Không. Không có trọng số công khai. Nếu bắt buộc triển khai tại chỗ, hãy xem cách chạy DeepSeek V4 cục bộ hoặc các LLM cục bộ tốt nhất năm 2026.

OpenAI SDK có hoạt động mà không cần sửa nhiều không?

Có. Đặt base_url thành https://qianfan.baidubce.com/v2 và api_key thành khóa Qianfan. Trường model dùng ID model của Qianfan, không phải OpenAI. Function calling, streaming và response_format: json_object đều hoạt động. Xác thực json_schema nghiêm ngặt vẫn đang được triển khai.

ERNIE 5.1 xử lý prompt tiếng Trung và tiếng Anh như thế nào?

Cả hai đều là ưu tiên chính. Điểm Arena Search 1.223 đến từ nhóm bình chọn đa ngôn ngữ. Với tác vụ kỹ thuật tiếng Anh như code và thiết kế API, mô hình cạnh tranh với các model tiên tiến. Với viết sáng tạo tiếng Trung, nó là một trong những model Trung Quốc mạnh nhất.

Chiều dài output tối đa là bao nhiêu?

Chưa được công bố chính thức. Trong thực tế, response đơn lượt thường giới hạn khoảng 8K token trước khi model kết thúc. Với tác vụ tạo văn bản dài, hãy chia nhỏ nội dung và tiếp tục theo từng phần.

Nếu bạn đang xây dựng tác nhân trên ERNIE 5.1, hãy tải Apidog và dùng bộ request tương thích OpenAI để mock, kiểm thử và tài liệu hóa endpoint Qianfan cùng các service còn lại.

ERNIE 5.1 là gì? Mô hình MoE mới của Baidu

Sebastian Petrus — Thu, 14 May 2026 07:16:00 +0000

Baidu đã phát hành ERNIE 5.1 vào ngày 9 tháng 5 năm 2026. Điểm đáng chú ý: đây là mô hình Mixture-of-Experts (MoE) có tổng số tham số khoảng một phần ba ERNIE 5.0, đạt hạng 4 toàn cầu trên Arena Search và đứng đầu trong nhóm mô hình Trung Quốc với điểm 1.223.

Dùng thử Apidog hôm nay

ERNIE 5.1 là phiên bản đầu tiên trong dòng ERNIE được Baidu định vị rõ ràng cho các workload tác nhân: gọi công cụ, suy luận nhiều bước và viết dài. Nếu bạn đang xây dựng hệ thống agent bằng Apidog, hoặc đang so sánh các mô hình Trung Quốc như DeepSeek V4 và Kimi K2.6, ERNIE 5.1 là một lựa chọn đáng đưa vào benchmark nội bộ.

Bài viết này tập trung vào phần triển khai: ERNIE 5.1 là gì, bạn có thể thử ở đâu, cần kiểm thử những gì, và nên đặt nó vào stack LLM như thế nào.

TL;DR: ERNIE 5.1 trong một đoạn

ERNIE 5.1 là mô hình MoE chỉ văn bản. Baidu cho biết chi phí tiền huấn luyện của nó chỉ khoảng 6% so với các mô hình tiên phong tương đương, tổng số tham số khoảng một phần ba ERNIE 5.0, và số tham số hoạt động trên mỗi lượt truyền tiến khoảng một nửa. Mô hình đạt 1.223 điểm trên Arena Search, vượt DeepSeek-V4-Pro trên τ³-bench và SpreadsheetBench-Verified, đồng thời đạt 99.6 trên AIME26 khi dùng công cụ. Bạn có thể thử qua giao diện chat ERNIE, ERNIE 5.1 Playground trên Baidu AI Studio, hoặc API Qianfan.

Vì sao developer nên quan tâm

Có ba điểm đáng chú ý khi đánh giá ERNIE 5.1 cho ứng dụng thực tế.

1. Tỷ lệ chi phí / chất lượng

Baidu tuyên bố chi phí tiền huấn luyện chỉ khoảng 6% so với các mô hình tương đương. Nếu chi phí này được phản ánh vào giá API Qianfan, ERNIE 5.1 có thể trở thành một lựa chọn cloud rẻ hơn cho các workload agent và tìm kiếm tăng cường.

Khi đánh giá, đừng chỉ nhìn benchmark. Hãy đo:

Chi phí mỗi request thực tế
Độ trễ trung bình và p95
Tỷ lệ tool call đúng
Tỷ lệ hallucination trong dữ liệu nghiệp vụ của bạn
Chi phí retry khi model gọi sai công cụ

2. MoE định tuyến theo ba trục

Baidu mô tả ERNIE 5.1 là MoE có định tuyến linh hoạt theo:

Chiều sâu
Chiều rộng
Độ thưa thớt

Điều này giúp giảm số tham số hoạt động mà vẫn giữ hiệu năng ở các tác vụ gọi công cụ. Về mặt triển khai, bạn nên xem ERNIE 5.1 như một model cloud tối ưu chi phí, không phải model có thể self-host.

3. Agent là use case chính

ERNIE 5.0 được nhắc nhiều ở khả năng kiến thức và viết sáng tạo. ERNIE 5.1 được Baidu quảng bá trực tiếp cho tác nhân và tool use. Điều này quan trọng nếu bạn đang xây dựng các workflow như:

Chatbot có gọi API nội bộ
Agent xử lý bảng tính
Trợ lý tìm kiếm có trích dẫn
Workflow nhiều bước có state
LLM router cho nhiều nhà cung cấp

Benchmark: ERNIE 5.1 so với các model khác

Dưới đây là các số liệu Baidu đã công bố và ý nghĩa thực tế khi triển khai.

Benchmark	ERNIE 5.1	Kiểm tra gì	Đối thủ gần nhất
Arena Search	1,223 — hạng 4 toàn cầu, hạng 1 Trung Quốc	QA có nhận thức tìm kiếm, do con người đánh giá	Gemini 3.1 Pro, GPT-5.x
τ³-bench	Vượt DeepSeek-V4-Pro	Tool use đa lượt, tác vụ agent	DeepSeek-V4-Pro
SpreadsheetBench-Verified	Vượt DeepSeek-V4-Pro	Tác vụ bảng tính thực tế	DeepSeek-V4-Pro
AIME26 có công cụ	99.6	Toán với trình thông dịch mã	GPT-5.x, Gemini 3.1 Pro
GPQA	“Tiếp cận các model nguồn đóng hàng đầu”	QA khoa học cấp sau đại học	Claude Sonnet 4.6
MMLU-Pro	“Tiếp cận các model nguồn đóng hàng đầu”	Kiến thức tổng quát	Các model frontier

Cần đọc benchmark này một cách thận trọng:

Arena Search phụ thuộc vào tập prompt và nhóm người đánh giá.
AIME26 được đo trong chế độ có công cụ, không phải suy luận thuần túy.
Baidu mô tả viết sáng tạo là “tiếp cận Gemini 3.1 Pro”, không tuyên bố vượt.
Các benchmark agent như τ³-bench và SpreadsheetBench đáng chú ý hơn nếu bạn đang xây dựng workflow gọi công cụ.

Kiến trúc: những gì đã biết

Baidu chưa công bố chi tiết như một technical paper đầy đủ, nhưng các thông tin sau đã được xác nhận:

Tổng số tham số: khoảng một phần ba ERNIE 5.0
Tham số hoạt động trên mỗi token: khoảng một nửa ERNIE 5.0
Định tuyến: theo chiều sâu, chiều rộng và độ thưa thớt
Chi phí tiền huấn luyện: khoảng 6% so với “các model tương đương”
Phương thức: chỉ văn bản khi ra mắt
Ngôn ngữ: có bản tiếng Trung và tiếng Anh

Những điểm chưa được công bố:

Độ dài context window
Tổng số tham số chính xác
Số expert
Ngân sách token huấn luyện
Trọng số để self-host

Nếu bạn từng tích hợp các mô hình MoE Trung Quốc như GLM 5.1, hãy chuẩn bị quy trình đánh giá tương tự: kiểm tra độ ổn định output, latency, tool calling và khả năng xử lý prompt dài.

Những gì bạn chưa nên thiết kế dựa vào ERNIE 5.1

Trước khi đưa ERNIE 5.1 vào production, cần ghi nhớ các giới hạn sau.

Không có đầu vào hình ảnh. ERNIE 5.1 chỉ xử lý văn bản. Nếu workflow cần thị giác, bạn cần ERNIE-VL hoặc model vision khác.
Không có audio input/output. Không hỗ trợ giọng nói tự nhiên hoặc realtime voice.
Chưa công bố context window. Với tài liệu dài, hãy chunk input và thêm bước retrieval thay vì gửi toàn bộ tài liệu.
Không có trọng số HuggingFace. Đây là model hosted-only. Nếu cần chạy tại chỗ, hãy xem DeepSeek V4 cục bộ hoặc một LLM cục bộ.

Khi nào nên chọn ERNIE 5.1

Nếu bạn đang so sánh ERNIE 5.1 với DeepSeek, Kimi, GLM hoặc Qwen, có thể dùng ma trận quyết định sau.

Chọn ERNIE 5.1 khi

Bạn cần:

Agent gọi công cụ ổn định
Trả lời có hỗ trợ tìm kiếm bằng tiếng Trung hoặc tiếng Anh
Model cloud Trung Quốc có tiềm năng chi phí thấp
API hosted thay vì self-host
Benchmark tốt trên tác vụ bảng tính và tool use

Chọn DeepSeek V4 khi

Bạn cần:

Trọng số mở
Triển khai tại chỗ
Kiểm soát hạ tầng
Suy luận toán học thuần túy mạnh
Tích hợp với stack đã dùng DeepSeek

Xem thêm: DeepSeek V4

Chọn Kimi K2.6 khi

Bạn cần:

Context window dài
Xử lý tài liệu lớn
Workflow phân tích văn bản nhiều trang
Tóm tắt hoặc truy vấn tài liệu dài

Xem thêm: Kimi K2.6

Chọn GLM 5.1 khi

Bạn cần:

Model tổng quát cân bằng
Tích hợp với hệ sinh thái Zhipu hoặc Z.ai
Một lựa chọn ổn định cho nhiều tác vụ không quá chuyên biệt

Xem thêm: GLM 5.1

Không nên chọn model chỉ dựa vào bảng xếp hạng. Hãy chạy một tập đánh giá 20–50 prompt đại diện cho workload thật của bạn.

Cách thử ERNIE 5.1 hôm nay

Có ba cách chính.

1. Dùng giao diện chat ERNIE

Truy cập ernie.baidu.com.

Phù hợp để kiểm tra nhanh:

Viết sáng tạo
Hỏi đáp tiếng Trung
Hỏi đáp tiếng Anh
Suy luận nhiều bước
Chất lượng trả lời tự nhiên

2. Dùng ERNIE 5.1 Playground trên Baidu AI Studio

Playground phù hợp hơn nếu bạn muốn thử:

Tool calling
Agent demo
Prompt nhiều lượt
So sánh hành vi với model khác trước khi viết code

3. Dùng API Qianfan

API Qianfan là đường triển khai cho developer. Theo mô tả của Baidu, request có định dạng tương thích OpenAI và xác thực bằng Bearer token. Hướng dẫn chi tiết nằm trong bài viết Cách sử dụng API ERNIE 5.1.

Một skeleton request có thể được tổ chức như sau:

curl "$QIANFAN_ENDPOINT" \
  -H "Authorization: Bearer $QIANFAN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "ernie-5.1",
    "messages": [
      {
        "role": "system",
        "content": "Bạn là trợ lý kỹ thuật, trả lời ngắn gọn và chính xác."
      },
      {
        "role": "user",
        "content": "Tóm tắt log lỗi này và đề xuất bước debug tiếp theo."
      }
    ]
  }'

Nếu bạn dùng nhiều nhà cung cấp model, Apidog giúp quản lý request template, biến môi trường, API key và so sánh response mà không cần viết script riêng cho từng provider.

Checklist đánh giá ERNIE 5.1 trước production

Thay vì chỉ test vài câu hỏi thủ công, hãy tạo một benchmark nhỏ theo workload thật.

Bước 1: Chọn 20–50 test case

Ví dụ:

10 prompt hỏi đáp nghiệp vụ
10 prompt cần gọi công cụ
10 prompt có dữ liệu bảng
10 prompt dài hoặc nhiều ngữ cảnh
10 prompt gây nhiễu hoặc dễ hallucinate

Bước 2: Xác định tiêu chí chấm điểm

Nên đo ít nhất:

Tiêu chí	Cách đo
Độ chính xác	So với đáp án chuẩn hoặc review thủ công
Tool call đúng	Tên tool, tham số, thứ tự gọi
Latency	p50, p95, timeout
Chi phí	Token input/output, retry
Tính ổn định	Chạy lại cùng prompt nhiều lần
Khả năng từ chối	Có từ chối đúng khi thiếu dữ liệu không

Bước 3: So sánh với model hiện tại

Chạy cùng bộ prompt trên:

ERNIE 5.1
Model production hiện tại
Một model fallback
Một model rẻ hơn nếu có

Bạn có thể dùng workflow trong Kiểm tra LLM dưới dạng API để chuẩn hóa request và response trong Apidog.

Bước 4: Test tool calling riêng

Với agent, đừng chỉ đọc final answer. Hãy log toàn bộ:

Tool nào được gọi
Tham số truyền vào tool
Tool có được gọi đúng thời điểm không
Model có tự sửa khi tool trả lỗi không
Model có gọi tool khi không cần không

Một case test đơn giản:

{
  "input": "Tìm đơn hàng gần nhất của khách hàng A và kiểm tra trạng thái giao hàng.",
  "expected_tool_sequence": [
    "search_customer",
    "list_orders",
    "get_shipping_status"
  ],
  "failure_conditions": [
    "bịa mã đơn hàng",
    "bỏ qua bước xác minh khách hàng",
    "trả lời mà không gọi tool"
  ]
}

Giá cả và triển khai

Baidu cho biết ERNIE 5.1 sẽ được triển khai trên hơn 10 nền tảng sản xuất sáng tạo sau khi ra mắt. Tuy nhiên, bài công bố không đưa ra giá public theo token trên Qianfan.

Vì vậy, khi lập kế hoạch production:

Kiểm tra giá trực tiếp trong dashboard Qianfan.
Ước tính token input/output theo traffic thật.
Thêm chi phí retry và fallback.
Đo latency từ khu vực người dùng của bạn.
Xác nhận yêu cầu pháp lý về lưu trữ dữ liệu.

Nếu chính sách dữ liệu của bạn không cho phép hạ tầng đặt tại Trung Quốc, ERNIE 5.1 có thể không phù hợp dù benchmark tốt.

Khuyến nghị triển khai cho developer

1. Không thay model production ngay

Hãy chạy ERNIE 5.1 ở chế độ shadow hoặc A/B test trước:

Gửi cùng request đến model hiện tại và ERNIE 5.1
Không hiển thị response ERNIE cho user ở giai đoạn đầu
Log output để review
Chỉ chuyển traffic khi metric ổn định

2. Dùng fallback model

Vì ERNIE 5.1 là hosted-only, nên luôn có fallback:

try:
    response = call_ernie_5_1(request)
except TimeoutError:
    response = call_fallback_model(request)
except ProviderError:
    response = call_fallback_model(request)

Fallback nên được kích hoạt khi:

Timeout
Rate limit
Lỗi xác thực
Response không hợp lệ
Tool call thiếu tham số bắt buộc

3. Tách prompt theo loại tác vụ

Không dùng một system prompt cho mọi thứ. Tách theo:

QA
Tool calling
Tóm tắt
Viết dài
Phân tích bảng tính
Trích xuất dữ liệu

Điều này giúp bạn đo chính xác ERNIE 5.1 mạnh ở đâu và yếu ở đâu.

4. Giám sát output sau khi deploy

Các chỉ số nên log:

Model version
Prompt template version
Token input/output
Latency
Tool call trace
Error type
User feedback
Fallback rate

FAQ

ERNIE 5.1 có mã nguồn mở không?

Không. ERNIE 5.1 là model hosted-only, truy cập qua giao diện chat của Baidu, Baidu AI Studio và API Qianfan. Tại thời điểm viết bài, không có trọng số công khai trên HuggingFace.

ERNIE 5.1 có hỗ trợ hình ảnh không?

Không. ERNIE 5.1 chỉ xử lý văn bản khi ra mắt. Với tác vụ thị giác, bạn cần ERNIE-VL hoặc một model multimodal khác. Nếu cần một model multimodal Trung Quốc, có thể xem Qwen 3.5 Omni.

Context window của ERNIE 5.1 là bao nhiêu?

Baidu chưa công bố con số cụ thể. Cho đến khi có thông tin chính thức, nên thiết kế workflow tài liệu dài bằng chunking, retrieval và giới hạn input.

Có thể dùng ERNIE 5.1 bên ngoài Trung Quốc không?

Giao diện chat và API Qianfan có thể truy cập từ nhiều khu vực, nhưng độ trễ, xác minh tài khoản và tính năng doanh nghiệp có thể khác nhau. Một số tính năng có thể yêu cầu số điện thoại hoặc giấy phép kinh doanh tại Trung Quốc đại lục. Xem hướng dẫn Cách sử dụng API ERNIE 5.1 để biết quy trình truy cập.

ERNIE 5.1 có tốt hơn DeepSeek-V4-Pro không?

Theo Baidu, ERNIE 5.1 vượt DeepSeek-V4-Pro trên τ³-bench và SpreadsheetBench-Verified. Tuy nhiên, DeepSeek vẫn có lợi thế nếu bạn cần trọng số mở hoặc triển khai tại chỗ. Với suy luận toán học thuần túy không dùng công cụ, dữ liệu công khai chưa đủ để kết luận chắc chắn.

Kết luận

ERNIE 5.1 đáng chú ý nhất ở ba điểm: thiết kế MoE tiết kiệm chi phí, benchmark agent mạnh, và định hướng rõ ràng cho tool use. Nếu bạn đang xây dựng agent hoặc workflow gọi API, hãy thêm ERNIE 5.1 vào benchmark nội bộ thay vì chỉ đọc điểm số công khai.

Cách tiếp cận thực tế:

Tạo bộ 20–50 prompt đại diện.
Test ERNIE 5.1 qua Qianfan.
So sánh với model hiện tại.
Đo tool call, latency, chi phí và fallback rate.
Chỉ deploy khi metric phù hợp với workload của bạn.

Sẵn sàng bắt đầu xây dựng? Tải Apidog và nhập OpenAPI spec của Qianfan để kiểm thử ERNIE 5.1 cùng các model hiện tại trong một workspace.