Chạy AI Agent triệu token: Bài toán nằm ở khâu đánh giá, không phải tốc độ

Gemini 4 Argon đã chính thức phát hành rộng rãi (GA) từ ngày 13 tháng 10 năm 2026, nâng trần output của Google từ 64K token lên khoảng 1M token, cho phép mô hình “tạo ra hàng trăm nghìn token chỉ trong một quỹ đạo duy nhất.” Tài liệu dành cho nhà phát triển của Google đã hướng dẫn chi tiết cách thực hiện. Theo mặc định, một yêu cầu thông thường vẫn dừng ở 65.536 output token. Nếu bạn thiết lập max_output_tokens cao hơn trên Interactions API cùng với background: true, máy chủ sẽ tiếp tục sinh nội dung theo từng bước nhảy tối đa 64K cho đến khi chạm giới hạn—lên tới 1.048.576 token trừ đi lượng input của bạn. Google cũng lưu ý rằng các prompt phức tạp có thể mất vài phút để xử lý.

Chi tiết đáng đọc lại lần thứ hai trong bài viết công bố không nằm ở con số giới hạn, mà là cách Google tận dụng dung lượng output khổng lồ đó. Google cho biết họ đã ứng dụng Argon trong nội bộ để chuyển đổi mã nguồn từ C/C++ sang Rust, với quy mô từ “hàng chục nghìn dòng mã trong các thư viện cốt lõi như re2, libgav1 cho tới hơn 800K dòng mã cho kernel Fuchsia Zircon.” Đồng thời, các phần mã viết lại này đang “trải qua quy trình kiểm thử mô phỏng, audit tự động lẫn thủ công và review nghiêm ngặt trước khi triển khai lên production.” Ngay cả phòng thí nghiệm tạo ra mô hình vẫn phải review kỹ lưỡng trước khi đưa vào thực tế. Vì vậy, một đội ngũ mà các agent giờ đây có thể trả về kết quả dưới mức trần cao gấp mười sáu lần sẽ cần một kế hoạch review trước khi nghĩ đến việc dùng mô hình.

Tóm tắt nhanh (TL;DR)

Giới hạn output một triệu token đã dịch chuyển điểm nghẽn từ khâu tạo mã sang khâu phê duyệt và tiếp nhận mã. Giờ đây, khi một lần chạy có thể trả về khối lượng dữ liệu lớn đến vậy, hãy chia nhỏ công việc thành các Task mà một người có thể review trong một lần ngồi, mỗi Task đều có định nghĩa hoàn thành bằng văn bản rõ ràng và thời gian timeout riêng, yêu cầu đầy đủ bằng chứng kiểm thử trên từng Task, đồng thời tính toán năng lực review trước tiên. Agent phụ trách nghiên cứu, thực thi, kiểm thử và báo cáo. Con người đóng vai trò định hướng, phân quyền và phê duyệt kết quả.

Điều gì thay đổi khi một lần chạy có thể trả về nhiều đến thế

Năng lực review là số lượng kết quả hoàn chỉnh của agent mà một đội ngũ có thể đọc, đánh giá và tiếp nhận trong một ngày—và giới hạn này do con người quyết định chứ không phải mô hình. Trần output cao hơn chỉ đơn thuần làm tăng lượng dữ liệu có thể ập đến cùng một lúc.

Mức trần cũ vô tình đóng vai trò kiểm soát phạm vi: vì phản hồi chỉ dài đến một mức nhất định, nên công việc buộc phải trả về từng phần kèm theo các điểm dừng ngắt quãng. Lý do Google đưa ra cho giới hạn mới lại đi theo hướng ngược lại: tạo dư địa để “giải quyết các bài toán khó chỉ trong một lần duy nhất.” Nhưng đối với người review, “trong một lần duy nhất” đồng nghĩa với một kết quả, một quyết định, và không hề có checkpoint nào để con người kịp can thiệp rằng “đang đi sai hướng rồi.”

Hơn nữa, mức trần này là dùng chung. Khung cửa sổ 1.048.576 token của Argon bao gồm cả input, thinking và output gộp lại. Vì thế, một lượt chạy đọc 300K token mã nguồn sẽ còn khoảng 748K token cho phần suy nghĩ và viết mã. Dù vậy, con số đó vẫn vượt xa lượng mã mà bất kỳ ai có thể đọc tỉ mỉ từng dòng trong một lần ngồi.

Kế đến là vấn đề chất lượng. Vào thời điểm công bố, Bloomberg dẫn lời các nhân viên ẩn danh của Google cho rằng Argon thể hiện chưa thực sự ấn tượng ở một số tác vụ lập trình và front-end so với các điểm chuẩn; Google khẳng định thông tin đó không chính xác. Tuy nhiên, chính bảng thống kê của Google cũng cho thấy Argon xếp sau ở hai trong số bốn hạng mục lập trình dạng agentic (bài so sánh của chúng tôi đã phân tích chi tiết điều này). Benchmark chỉ là tuyên bố dựa trên một bộ dữ liệu kiểm thử. Còn diff của bạn là thay đổi trực tiếp trên codebase thực tế, và nó chỉ được chấp thuận dựa trên bằng chứng xác thực, bất kể mô hình nào đã viết ra nó.

Xác định phạm vi theo Task, đừng theo ngân sách token

Đơn vị bạn kiểm soát là Task, không phải số lượng token. Nếu để trần giới hạn của mô hình quyết định quy mô công việc, bạn sẽ nhận về kết quả lớn nhất mà nó có thể tạo ra. Nhưng nếu tự mình thiết lập giới hạn, bạn sẽ nhận được kết quả mà con người có thể thẩm định và tiếp nhận. Tài liệu hướng dẫn của chính Google cũng đồng tình với điều này: hãy giữ nguyên mức mặc định 65.536 cho các tác vụ tiêu chuẩn, và chỉ dùng chế độ background ở mức 131.072 hoặc 262.144 token cho các tác vụ lập trình và lập luận phức tạp, thay vì đẩy lên mức tối đa.

Cách Google mô tả quy trình thực tế cũng đã chia tách công việc theo từng thư viện và kernel. Hãy chia nhỏ quá trình chuyển đổi mã theo cách tương tự: mỗi module tương ứng với một Task mà người review có thể hoàn tất trong một lần ngồi. Trong Sharkly, cấu trúc đó là một Task cha kèm theo các sub-task cho từng module, kết hợp các liên kết “blocks / is blocked by” khi có module cần phải hoàn thành trước. Mục tiêu, phạm vi và tiêu chí nghiệm thu đều nằm rõ trong phần mô tả Task, phục vụ cho cả Agent lẫn người review:

SH-412  Port the tokenizer module to Rust
Parent: SH-400  Port the parser library to Rust
Blocked by: SH-411  Port the shared buffer types

Done when:
- the Rust module replaces src/tokenizer/ and nothing outside it changes
- the existing test suite passes against the Rust build without edits
- a differential run over the fixture corpus produces identical output
- the report lists every unsafe block and the reason for it
Out of scope: public API changes, performance work

Hai thiết lập của Agent sẽ hỗ trợ điều này. Thiết lập timeout cho từng Task phải phù hợp với tính chất của Task đó, chứ không phải theo giới hạn của mô hình: nó cần lớn hơn thời gian chạy thực tế dài nhất của một module, nhưng phải thấp hơn ngưỡng chạy khiến bạn phải hối hận vì hóa đơn thanh toán. Thiết lập Max concurrency (số task được giao đồng thời) sẽ giới hạn số lượng module đang được xử lý cùng lúc, bởi vì bốn mươi sub-task chạy song song sẽ tạo ra bốn mươi kết quả cùng xếp hàng chờ một người review duy nhất.

Cặp nguyên tắc đưa ra quyết định: giao toàn bộ công việc cho một lần chạy khi các công cụ kiểm thử tự động có thể bao quát toàn bộ kết quả—chẳng hạn như việc đổi tên biến mang tính máy móc với sự hỗ trợ của trình biên dịch và bộ test suite toàn diện. Hãy chia nhỏ việc khi con người buộc phải thẩm định bất kỳ phần nào, mà đối với việc chuyển đổi ngôn ngữ lập trình thì phần lớn đều cần đến điều đó. Những lượt chạy kéo dài hơn cả ngày làm việc của bạn cũng cần các điều kiện tiên quyết tương tự: một điều kiện dừng, một trạng thái chờ, và một người chịu trách nhiệm kiểm tra vào sáng hôm sau.

Đính kèm bằng chứng trực tiếp trên Task

Một kết quả đồ sộ không đi kèm bằng chứng thì không thể gọi là review. Đó thực chất là việc một con người đang tự mình chạy lại toàn bộ quy trình, một cách chậm chạp.

Ví dụ về libgav1 cho thấy một bằng chứng đạt chuẩn trông như thế nào. Google cho biết Argon đã thay thế 32K dòng mã SIMD trong một bản port Rust hiện có, và kết quả là “chạy nhanh hơn 2,7 lần so với bản port Rust ban đầu, với đầu ra video hoàn toàn trùng khớp.” Vế sau của câu nói chính là yếu tố giúp 32K dòng mã đó có thể review được: cùng một tập dữ liệu đầu vào được đưa qua cả mã cũ lẫn mã mới, và kết quả đầu ra hoàn toàn khớp nhau. Đó chính là kiểm thử vi sai, và nó giải phóng người review để tập trung vào những thứ mà phép so sánh tự động không thể chạm tới: mã unsafe, các luồng xử lý lỗi, và liệu hiệu năng tăng tốc có duy trì trên khối lượng công việc thực tế hay không.

Mỗi lượt chạy cần trả về bốn thành phần sau vào Task:

Đó cũng chính là mô hình quy trình làm việc mà Sharkly mô tả: Agent tiến hành typecheck, chạy kiểm thử và build, sau đó đính kèm bản tóm tắt thay đổi, kết quả xác minh cùng các giới hạn đã biết; con người sẽ chấp nhận, yêu cầu chỉnh sửa, hoặc quyết định bước merge và release. Phản hồi cuối cùng của Agent được lưu ngay trên Task và nhật ký thực thi nằm trong tab Executions, giúp bằng chứng luôn hiển thị tập trung trên Task thay vì trôi mất trong terminal. Bài viết Review mã do AI tạo bằng bằng chứng ở cấp độ task hướng dẫn thứ tự đọc tài liệu, và các mẫu bàn giao sẽ chuẩn hóa báo cáo theo một cấu trúc cố định.

Vượt qua các khâu kiểm tra tự động chưa phải là đã được chấp nhận, và việc merge cũng vậy: trong Sharkly, việc merge một pull request liên kết không làm thay đổi trạng thái của Task. Kiểm tra tự động chỉ xác minh những gì trong khả năng của nó, và bài viết về các agent review mã bằng AI sẽ chỉ ra giới hạn đó dừng lại ở đâu. Quyết định xem thay đổi có đáp ứng đúng yêu cầu của Task hay không vẫn thuộc về con người.

Tính toán bài toán năng lực review trước khi chạy

Review thực chất là một hàng đợi: kết quả được gửi đến, con người xử lý chúng, và nếu tốc độ gửi đến nhanh hơn tốc độ xử lý thì hàng đợi sẽ phình to. Việc nâng hạn mức output chỉ làm thay đổi phía đầu vào. Dưới đây là một ví dụ minh họa với các số liệu giả định thay vì một dự án thực tế:

Nếu chỉ xem diff đơn thuần, đợt chuyển đổi sẽ tiêu tốn 80 giờ review của kỹ sư, tương đương khoảng 27 ngày làm việc. Nhưng khi có đầy đủ bằng chứng trên từng Task, con số này chỉ còn 20 giờ, tức khoảng bảy ngày. Dù là một lần chạy khổng lồ hay bốn mươi lần chạy nhỏ hơn, khối lượng công việc phía người review vẫn như nhau.

Điểm khác biệt nằm ở khâu ra quyết định. Bốn mươi Task được gửi đến theo tiến độ bạn kiểm soát và mỗi Task nhận một quyết định độc lập. Trong khi đó, một kết quả ôm đồm cả bốn mươi module chỉ nhận duy nhất một phán quyết—nghĩa là một lỗi ở module thứ 31 sẽ kéo lùi toàn bộ 39 module còn lại. Với các sub-task, một nhận xét yêu cầu sửa ở module lỗi có thể kích hoạt một lượt chạy khắc phục riêng cho Task đó, trong khi các phần việc còn lại vẫn tiếp tục tiến triển.

Tiếp theo, hãy tính đến bài toán chi phí. Một lượt chạy chạm mức tối đa sẽ tạo ra khoảng 1M output token: tốn chừng 10 USD với mức giá 10 USD/triệu token áp dụng đến hết ngày 30 tháng 11, và khoảng 20 USD từ ngày 1 tháng 12. Ở dự án Tier 1, hạn mức chi tiêu của Google là 10 USD cho mỗi khung 10 phút luân phiên, do đó một lượt chạy tối đa sẽ ngốn sạch hạn mức của cả khung thời gian theo mức giá hiện tại, và vượt gấp đôi hạn mức đó kể từ ngày 1 tháng 12. Hãy luôn giữ giá trị Max concurrency ở mức thấp đối với bất kỳ Agent nào được phép chạy dài như vậy.

Hãy tự tính toán các con số của riêng bạn trước đợt chạy lớn đầu tiên, chứ đừng đợi đến khi hàng đợi bị tắc nghẽn. Bài viết Bài toán năng lực review sẽ phân tích phép tính tương tự ở quy mô nhóm, và bài viết Khâu review của con người là điểm nghẽn sẽ trình bày các trạng thái cùng cổng kiểm soát giúp bạn nhìn rõ hàng đợi công việc.

Checklist trước đợt chạy một triệu token đầu tiên

• [ ] Công việc đã được chia thành các Task mà người review có thể hoàn thành trong một lần ngồi, đi kèm sub-task và các liên kết “blocked by”.
• [ ] Mỗi phần mô tả Task nêu rõ tiêu chí hoàn thành và những gì nằm ngoài phạm vi.
• [ ] Thời gian timeout cho từng Task phù hợp với quy mô của Task đó (các yêu cầu background dài mất vài phút), không đặt theo giới hạn output của mô hình.
• [ ] Một lượt chạy tối đa vẫn nằm trong hạn mức chi tiêu theo API tier của bạn.
• [ ] Mức Max concurrency của Agent cho các Task được giao phải tương ứng với số lượng mà người review có thể xử lý, chứ không phải năng lực máy tính có thể chạy.
• [ ] Mỗi lượt chạy đều trả về bản tóm tắt thay đổi, kết quả kiểm tra, nội dung đã xác minh và các giới hạn đã biết.
• [ ] Các tác vụ bảo toàn hành vi phải có bước kiểm thử vi sai so sánh với mã nguồn cũ.
• [ ] Mỗi Task đều chỉ định rõ người review, và việc chấp thuận phải thông qua hành động đổi trạng thái của người đó, tuyệt đối không phải là tác dụng phụ đi kèm của việc merge mã.

Không có điều nào trong số này phụ thuộc riêng vào Argon, vốn là mô hình mà bất kỳ API key Gemini trả phí nào hiện nay cũng có thể gọi. Tuyên bố của Google chính là hình mẫu chuẩn mực: output dung lượng lớn, tiếp đến là audit, kiểm thử mô phỏng và review, sau đó mới đưa lên production. Dù phòng thí nghiệm nào tung ra bước nhảy vọt tiếp theo về dung lượng output, kế hoạch kiểm soát vẫn phải nằm ở cấp độ Task chứ không phải trong mô hình. Sharkly không chọn sẵn mô hình cho bạn: theo tài liệu về Agent, Agent sẽ sử dụng mô hình mặc định của Runtime, và bạn có thể thay đổi thông qua Custom arguments hoặc cấu hình của công cụ. Khi một mô hình lớn hơn xuất hiện trên Runtime bạn đang sử dụng, giá trị cấu hình đó thay đổi nhưng các Task, bằng chứng và cổng review vẫn được giữ nguyên vẹn. Ngữ cảnh, tiến độ, các điểm nghẽn, kết quả và sự can thiệp review của con người luôn được hiển thị xuyên suốt từ lúc gửi yêu cầu cho tới khi phát hành.

Nếu bạn đang vận hành nhiều agent cùng lúc, Sharkly sẽ là nơi tập trung duy nhất giúp bạn quản lý toàn bộ task và kết quả của chúng.