Bạn bắt đầu tái cấu trúc mã nguồn lúc bốn giờ chiều và gập máy tính lúc sáu giờ. Sáng hôm sau, lượt chạy đó có thể đã hoàn thành, vẫn đang chạy, hoặc đã dừng lại lúc 9:40 tối để hỏi một câu hỏi mà chẳng có ai ở đó để trả lời. Ba tình huống hoàn toàn khác nhau, nhưng từ bên ngoài nhìn vào, chúng trông giống hệt nhau suốt cả đêm.
Anthropic cho biết Claude Opus 5.5 có thể duy trì thực hiện nhiệm vụ liên tục từ 18 tiếng trở lên. Hãy hiểu điều đó theo nghĩa đen. Một lượt chạy được kích hoạt vào cuối ngày làm việc sẽ chưa kết thúc khi ngày làm việc tiếp theo bắt đầu. Nó đã tự mình đưa ra các quyết định suốt 11 tiếng đồng hồ mà không có bạn, và thứ duy nhất ngăn nó đưa ra một quyết định sai lầm chính là những gì bạn đã kịp ghi lại trước khi ra về.
Một lượt chạy nằm gọn trong ngày làm việc sẽ nhận được sự giám sát trực tiếp. Còn một lượt chạy kéo dài qua đêm đòi hỏi bạn phải quay lại xử lý sau. Đó là hai hệ thống hoàn toàn khác biệt, và phần lớn các đội ngũ hiện nay vẫn đang vận hành theo cách thứ nhất.
Tóm tắt nhanh
Một lượt chạy agent dài hạn là lượt chạy tiếp tục diễn ra vượt quá khoảng thời gian có người túc trực, vì vậy mọi quyết định mà agent không thể tự đưa ra đều phải được lưu lại dưới dạng trạng thái chờ thay vì một dòng nhắc lệnh trên terminal mà chẳng ai đọc tới. Cần thỏa mãn ba điều kiện sau để quy trình đó đảm bảo an toàn: một điều kiện dừng mà chính agent có thể tự áp dụng mà không cần bạn, một trạng thái chờ phản hồi từ con người khác biệt rõ ràng với trạng thái đang chạy và trạng thái lỗi, cùng một hộp thư đến do một người chịu trách nhiệm cụ thể mở ra vào buổi sáng. Agent đảm nhận việc nghiên cứu, thực thi, kiểm thử và báo cáo. Con người định hướng, phân quyền và nghiệm thu kết quả. Sharkly tích hợp cả ba yếu tố này ngay trên Task.
Cục diện đã thay đổi ra sao vào ngày 22/09/2026
Hai phòng lab AI lớn đã đồng loạt phát hành sản phẩm trong cùng một ngày, và cùng nhau họ đã định hình lại cả thời lượng lẫn chi phí cho mỗi lượt chạy agent.
| Claude Opus 5.5 | GPT-6 Sol | GPT-6 Luna | |
|---|---|---|---|
| API id | claude-opus-5-5 |
gpt-6-sol |
gpt-6-luna |
| Input / output per million tokens | $4 / $20 | $2 / $10 | $0.10 / $0.50 |
| Cached input | $0.20 read, $5 write | 90% off reads | 90% off reads |
| Context | 1M | 872k | 1M |
Anthropic tuyên bố chi phí vận hành Opus 5.5 giảm 40% so với Opus 5, tốc độ xuất kết quả nhanh hơn khoảng 30%, độ dài đầu ra tối đa đạt 128k token và có thể duy trì thực hiện nhiệm vụ từ 18 giờ trở lên. OpenAI tuyên bố Sol và Luna đều rẻ hơn 50% so với mức giá ưu đãi của GPT-5.6; “ưu đãi” là từ ngữ chính xác của OpenAI, nghĩa là mức giá này được so sánh với giá đã chiết khấu chứ không phải giá niêm yết. OpenAI cũng công bố mức giảm giá 90% cho việc đọc cached input trên GPT-6 và cho biết việc thay đổi mức độ suy luận (reasoning effort) hoặc danh sách công cụ khả dụng không còn làm vô hiệu hóa bộ nhớ đệm (cache invalidation) — điều có ý nghĩa đặc biệt quan trọng đối với các lượt chạy kéo dài thâu đêm.
Như vậy, một lượt chạy giờ đây vừa có thể kéo dài lại vừa tiết kiệm chi phí. Thế nhưng ngày làm việc của con người thì không hề dài thêm, và khả năng đọc kết quả của chúng ta cũng chẳng tăng lên tương ứng.
Quy trình review bị đảo ngược
Khi bạn theo dõi trực tiếp một lượt chạy, chính bạn là bộ xử lý lỗi (error handler) của nó. Bạn thấy agent mở nhầm file và bạn can thiệp ngay lập tức. Thao tác điều chỉnh đó không bao giờ xuất hiện trong bất kỳ tệp log nào, đơn giản vì nó chưa từng cần phải ghi lại.
Qua đêm, sự can thiệp tức thời đó hoàn toàn biến mất. Mọi điều chỉnh mà lẽ ra bạn sẽ thực hiện giờ đây buộc phải là một quy tắc mà agent đã được nạp sẵn, hoặc là một điểm dừng. Tuyệt đối không có lựa chọn thứ ba. Một agent chạy dài hạn không đơn thuần là một agent chạy ngầm không người trông coi rồi tự hoàn thành. Đó là một agent chắc chắn sẽ chạm tới một quyết định đòi hỏi bạn phải giải quyết trong lúc bạn đang ngủ. Hãy thiết kế hệ thống xoay quanh điểm dừng, chứ không phải xoay quanh điểm hoàn thành.
Anthropic cũng báo cáo rằng các nỗ lực vượt rào (boundary-circumvention) thành công trên Opus 5.5 đã giảm 85%. Tuy nhiên, tỷ lệ rủi ro thấp hơn không phải là một điều kiện dừng. Một mô hình khó bị làm chệch hướng khỏi chỉ dẫn ban đầu thì vào lúc 2 giờ sáng vẫn cần một nơi để gửi câu hỏi lại cho bạn.
Ba điều kiện bắt buộc phải có
1. Điều kiện dừng mà agent có thể tự kích hoạt mà không cần bạn
Gồm hai phần: giới hạn cứng do nền tảng áp đặt, và các điều kiện thành văn do chính agent tự áp dụng.
Giới hạn cứng thuộc về cấu hình. Một Sharkly Agent quy định số lượng Task chạy song song tối đa và thời gian chờ tối đa (timeout) cho từng Task, được thiết lập ở cấp Agent thay vì cho từng lượt chạy riêng lẻ. Hãy đặt timeout cao hơn thời lượng của lượt chạy dài nhất mà bạn mong muốn, nhưng thấp hơn mức chi phí tối đa mà bạn sẵn sàng chi trả. Đây là một cầu dao an toàn (circuit breaker), không phải là một lịch trình.
Các điều kiện thành văn lại là nửa còn lại mà nhiều đội ngũ hay bỏ qua. Một agent không bao giờ dừng lại không phải là chăm chỉ, mà là thiếu kiểm soát.
Stop and wait for a human when:
- a change would touch a file outside the paths named in the Task;
- a check that passed at the start of the run still fails after two attempts;
- the Task description and the code disagree about intended behavior;
- you are about to run a command that writes outside the working directory.
When you stop, leave one comment: what you did, what you need, and the single
question that unblocks you. One question per stop.
Hãy đặt timeout dài khi Task là một thay đổi có phạm vi rõ ràng đi kèm các bài test có thể cho agent biết nó đã hoàn thành hay chưa. Hãy giữ timeout trong khoảng một hoặc hai tiếng khi Task mang tính thăm dò, khi tiêu chí nghiệm thu vẫn là một câu mơ hồ dễ gây tranh cãi, hoặc khi lượt chạy có thể chạm vào những phần mà bạn không muốn bị sửa đổi khi chưa được xem xét. Bài viết về cổng phê duyệt (approval gates) sẽ phân tích chi tiết những vị trí mà agent cần dừng lại, ngay cả khi nó rất tự tin vào kết quả.
2. Trạng thái chờ hoàn toàn tách biệt với trạng thái đang làm việc
Trong Sharkly, trạng thái vòng đời của Task và trạng thái hoạt động của Agent là hai bản ghi riêng biệt. Một Task có thể mang trạng thái In Progress trong khi Agent đang ở trạng thái Working, Waiting for human reply, Waiting for human review, hoặc Error. Lượt chạy bên dưới cũng sở hữu các trạng thái riêng: Queued, Dispatched, Waiting for local directory, Running, Completed, Failed, Canceled.
Điều đó nghe có vẻ rườm rà cho đến khi bạn có tám lượt chạy diễn ra qua đêm. Nếu không có sự phân định này, bảng công việc vào lúc 9 giờ sáng sẽ hiển thị In Progress cho cả một agent đang sửa mã nguồn lẫn một agent đã dừng lại từ 11 tiếng trước để đợi một câu trả lời duy nhất. Bạn sẽ phải mở tung cả tám lượt chạy lên chỉ để biết cái nào đang ra sao.
| Bạn nhìn thấy gì | Điều đó có nghĩa là gì | Cái giá phải trả nếu phớt lờ |
|---|---|---|
| Working | Runtime đang chủ động xử lý Task | Chưa có gì thiệt hại |
| Waiting for human reply | Agent đã dừng lại và đưa ra câu hỏi | Mỗi phút trôi qua là một phút lãng phí tài nguyên |
| Waiting for human review | Công việc đã hoàn tất nhưng chưa được nghiệm thu | Thay đổi chưa được phát hành |
| Error / Failed | Lượt chạy gặp lỗi kết thúc không như ý | Lần chạy lại vẫn chưa được kích hoạt |
Nhật ký thực thi (execution log) giúp bạn hiểu rõ lý do dừng vào sáng hôm sau: vì sao lượt chạy được xếp hàng, thời điểm bắt đầu và kết thúc, các lệnh gọi công cụ (tool call) và sự kiện Runtime, nguồn kích hoạt, cũng như thông tin chi tiết về sự cố hoặc lệnh hủy. Đó là những gì bạn cần nắm bắt một cách nhanh chóng khi đầu óc chưa nhớ lại những gì mình đã yêu cầu trước đó. Tham khảo thêm về trạng thái, nhật ký và tín hiệu lỗi để biết những dữ liệu cần ghi nhận nếu bạn tự xây dựng hệ thống này.
3. Một hộp thư đến do đích danh một người phụ trách kiểm tra
Một trạng thái chờ không có người chịu trách nhiệm sẽ phải chờ đợi mãi mãi. Các lượt chạy qua đêm thường thất bại trong âm thầm theo cách mà các lượt chạy ban ngày không gặp phải, bởi vì không có ai ở đó để nhận ra sự im lặng bất thường.
Hộp thư đến của Sharkly là một hàng đợi cá nhân về hoạt động của các nhiệm vụ, trong đó mục Primary lưu giữ các tín hiệu cần sự can thiệp của con người: chờ phản hồi của bạn, chờ bạn phê duyệt, công việc bị lỗi hoặc bị nghẽn, các lượt nhắc trực tiếp (@mention) và các nhiệm vụ được giao cho bạn. Các thông báo lỗi chạy và tín hiệu nghẽn sẽ được chuyển thẳng tới người phụ trách thay vì gửi tới tất cả người theo dõi, nhờ đó một lượt chạy bị lỗi lúc 3 giờ sáng sẽ đến tay một người cụ thể, tránh tình trạng gửi cho tất cả mọi người nhưng rốt cuộc lại chẳng ai giải quyết.
Hai chế độ xem (View) đã lưu sẽ gánh vác toàn bộ công việc buổi sáng: danh sách các nhiệm vụ đang chờ review, và danh sách các nhiệm vụ được giao cho Agent hiện đang bị nghẽn. Hãy chỉ định rõ ràng ai là người mở các danh sách đó. “Cả nhóm” sẽ không bao giờ tự mở một hộp thư đến cả.
Quy trình rà soát buổi sáng
Thứ tự xử lý rất quan trọng, và nó không giống với thứ tự hiển thị thông thường trên bảng công việc.
- Ưu tiên xử lý trạng thái Waiting for human reply trước tiên. Việc trả lời sẽ tái khởi động ngay một agent đang dừng; trong khi việc review chưa thể bắt đầu chu trình mới ngay. Nếu task SH-312 đã chờ từ 9:40 tối, điều nhanh nhất bạn có thể làm trong cả ngày là phản hồi bằng một bình luận, qua đó tự động kích hoạt lượt chạy tiếp theo cho chính Task đó.
- Xử lý các lượt chạy Failed và bị tắc thứ hai. Hãy đọc kỹ tiêu đề nhật ký thực thi và các thông số kỹ thuật chi tiết trước khi thử chạy lại. Một mã trạng thái HTTP đơn lẻ chỉ là manh mối chứ chưa phải là kết luận chẩn đoán.
- Xử lý trạng thái Waiting for review thứ ba. Đây mới là hàng đợi thực sự, và cũng là hàng đợi ngày càng phình to khi chi phí mỗi lượt chạy ngày càng rẻ đi.
- Cuối cùng mới đến các lượt Still running. Hãy để nó tiếp tục hoặc bấm hủy. Một lượt chạy bị hủy sẽ không thể tiếp tục ngay tại chỗ, nhưng Task cùng toàn bộ lịch sử của nó vẫn được giữ nguyên, vì vậy hãy thẳng tay hủy bỏ khi thấy hướng đi đã sai lệch. Nhớ xem qua log trước khi quyết định.
Vấn đề mà điều này không giải quyết được
Các lượt chạy dài hơn không hề làm giảm bớt khối lượng review. Trái lại, chúng tập trung áp lực review lại một chỗ. Một lượt chạy kéo dài 18 tiếng sẽ trả về một kết quả chứa đựng vô số quyết định sau một đêm, và con người vẫn phải đọc, đánh giá và nghiệm thu nó. Ngay chính các nhà nghiên cứu của OpenAI cũng đã chỉ ra đích đến của xu hướng này: một nhà nghiên cứu ở mức trung vị tiêu tốn hơn 600 USD tiền suy luận (inference) mỗi ngày theo giá API, và ở phân vị thứ 90 con số này vượt mức 7.000 USD/ngày, trong khi số lượng nhân sự có thể đọc được kết quả đầu ra đó vẫn không hề đổi. Chúng tôi đã làm phép tính này khi OpenAI công bố số liệu, và không có bất kỳ yếu tố nào trong đợt ra mắt này làm thay đổi con số ở mẫu số.
Các lượt chạy rẻ hơn và dài hơn mang lại nhiều phép thử song song hơn, chứ không làm giảm bớt số lượng quyết định cần đưa ra. Khâu review của con người chính là điểm nghẽn, và việc giảm giá chỉ làm điểm nghẽn này trở nên trầm trọng hơn trước khi mang lại chuyển biến tích cực. Quá trình tự động hóa sẽ phải dừng lại ở nơi cần đến sự đánh giá của đội ngũ con người, và khi dừng lại, nó phải bàn giao kết quả kèm đầy đủ ngữ cảnh cùng bằng chứng có thể kiểm chứng được.
Câu hỏi thường gặp
Thời gian timeout cho mỗi Task đối với một mô hình chạy được 18 tiếng nên là bao lâu? Hãy đặt dài hơn lượt chạy bạn mong muốn, nhưng ngắn hơn khoảng thời gian bạn sẽ phải hối tiếc. Hãy bắt đầu với một vài giờ cho công việc thông thường và nâng dần lên cho từng Agent đối với những Task thực sự cần chạy qua đêm. Timeout sinh ra để chấm dứt một lượt chạy bị lặp vô tận, chứ không phải để quyết định một công việc chất lượng cần bao nhiêu thời gian hoàn thành.
Chuyện gì sẽ xảy ra với câu hỏi mà agent đưa ra vào lúc 2 giờ sáng? Câu hỏi đó nên được chuyển thành trạng thái chờ phản hồi của con người (waiting-for-human-reply) và xuất hiện như một mục trong Inbox của người phụ trách, chứ không phải là một dòng trôi tuột đi trong bộ đệm dòng lệnh. Nếu hệ thống của bạn làm thất lạc câu hỏi đó, hãy lấp lỗ hổng này trước khi nghĩ đến việc kéo dài bất kỳ mốc timeout nào.
Bài học rút ra cho bạn
Không có nhà cung cấp nào bán sẵn phần cốt lõi của bài toán này, bởi điều quan trọng nhất là điểm dừng của agent sẽ được tiếp nhận ở đâu và ai sẽ là người tiếp quản mọi thứ vào buổi sáng. Vấn đề này hoàn toàn giống nhau trên Claude Code, Codex hay bất kỳ công cụ nào khác, đó là lý do vì sao quyền sở hữu và quản lý phải nằm ở cấp độ nhiệm vụ (task level) thay vì nằm bên trong một phiên làm việc riêng lẻ của một nhà cung cấp cụ thể.
Nếu bạn đã bắt đầu cho agent chạy qua đêm, bài kiểm tra rất đơn giản: Hãy mở bảng công việc của bạn lúc 9 giờ sáng và xem nó có thể phân biệt được một agent đang suy nghĩ với một agent đã dừng lại chờ đợi từ đêm qua hay không. Nếu không thể phân biệt được, đó là điều đầu tiên bạn cần khắc phục, và đó cũng chính là tầng hoạt động của Sharkly: Task lưu giữ mục tiêu, trạng thái lượt chạy, điểm nghẽn, kết quả và quyết định của con người, xuyên suốt từ khi yêu cầu cho đến lúc phát hành.
