Hãy nhìn xem đội của bạn đã tạo ra gì trong tuần trước. Một phần nhỏ trong đó là tính năng được bàn trong buổi standup. Phần lớn còn lại là những thứ xung quanh: phân loại bug, gắn nhãn, viết changelog, nhận xét sơ bộ cho mười một pull request, dựng khung test cho một module chẳng ai muốn nhận, cập nhật dependency, một trang tài liệu bị lỗi thời khi cấu trúc response thay đổi. Khối lượng lớn, chẳng ai khen, và cho đến tuần này, nó vẫn ngốn chi phí trên mỗi token y hệt như công việc thú vị, bởi vì cả hai đều chạy trên cùng một runtime.
OpenAI ra mắt GPT-6 Luna vào ngày 22 tháng 9 với giá $0.10 cho mỗi triệu token đầu vào và $0.50 cho mỗi triệu token đầu ra, API id gpt-6-luna, cửa sổ ngữ cảnh 1M. Đó chính là tầng dành cho 80 phần trăm công việc nhàm chán kia. Câu hỏi hữu ích không phải là Luna có tốt hay không, mà là những việc nào nên chuyển xuống đó, việc nào tuyệt đối không, và làm sao để viết một Task mà một runtime rẻ có thể hoàn thành.
TL;DR
Hãy định tuyến công việc xuống tầng rẻ dựa trên khả năng kiểm chứng, chứ không phải độ khó. Nếu kết quả có thể được xác minh mà không cần làm lại, và một câu trả lời sai chỉ khiến người review tốn một phút thay vì cả buổi chiều, thì nó thuộc về Luna. Giữ lại những quyết định mang tính phán đoán, bất cứ thứ gì mà bảng điều khiển tự động hóa dựa vào, và bất cứ thứ gì không ai buồn kiểm tra, cho runtime đắt tiền. Viết tiêu chí nghiệm thu mà máy có thể đánh giá, giữ mức effort vừa phải cho các tác vụ ngắn, và để mọi kết quả quay về Task nơi có người phê duyệt.
Luna được định giá thế nào, và được so với cái gì
Những so sánh về Luna mà OpenAI công bố là chi phí trên mỗi tác vụ chứ không phải thứ hạng trên bảng xếp hạng, và đó mới là cách nhìn đúng cho công việc này.
| Kết quả công bố | Luna | So với |
|---|---|---|
| DeepSWE 1.1 | 66.6% ở mức effort tối đa | Tương đương Claude Opus 5 và Fable 5 ở mức medium, với chi phí mỗi tác vụ thấp hơn Opus 5 93%, thấp hơn Fable 5 96% |
| AutomationBench 1.0.6 | +5.4pp so với phiên bản tiền nhiệm ở mức effort cao | Chi phí mỗi tác vụ thấp hơn 58% |
| OSWorld 2.0 offline | Vượt GPT-5.6 Sol ở mức effort medium | Chi phí chỉ còn khoảng một phần mười |
| Factuality | Ngang ngửa GPT-5.6 Sol ở mức effort cao hơn | Chi phí chỉ còn khoảng một phần trăm |
Có hai điều cần lưu ý kèm theo những con số đó. OpenAI mô tả Sol và Luna là rẻ hơn 50% so với mức giá khuyến mãi của GPT-5.6. "Khuyến mãi" là từ của chính OpenAI và điều này quan trọng: mốc so sánh là giá giảm, không phải giá niêm yết. So với giá niêm yết của GPT-5.6 Luna mà chính bài đưa tin ra mắt của chúng tôi đã ghi lại, $1 cho mỗi triệu token đầu vào và $6 cho mỗi triệu token đầu ra, thì mức giảm xuống $0.10 và $0.50 thực ra gần 90% ở đầu vào và 92% ở đầu ra. Mức cắt thật lớn hơn con số tiêu đề, còn con số tiêu đề thì lại được đo so với một đợt xả hàng.
Và mọi so sánh với Anthropic trong bảng đó đều là so với Claude Opus 5. Anthropic đã thay Opus 5 bằng Opus 5.5 đúng ngày OpenAI công bố, với giá $4 cho mỗi triệu token đầu vào và $20 cho mỗi triệu token đầu ra, so với mức $5 và $25 của Opus 5. Hãy đọc những chênh lệch đó như là so với thế hệ trước, vì đúng là như vậy. Chúng tôi không tuyên bố bên nào thắng giữa hai mẫu flagship hiện tại, và cả hai nhà cung cấp đều chưa công bố so sánh trực diện đó.
Artificial Analysis, một bên thứ ba chứ không phải nhà cung cấp nào, xếp Luna ở vị trí 37 trên chỉ số thông minh của họ, so với 58 của Opus 5.5. Luna không phải là một mô hình tiên tiến và cũng không được bán như vậy. Nó là một công nhân đủ năng lực với mức giá như một tiện ích, và đó chính là điểm mấu chốt.
Đặc tính quyết định việc gì nên được chuyển
Các đội thường sắp xếp công việc cho agent theo độ khó. Đó là trục sai: độ khó là thuộc tính của vấn đề, còn rủi ro của bạn là thuộc tính của vòng review. Hãy sắp xếp theo khả năng kiểm chứng.
Công việc thuộc về tầng rẻ khi cả hai điều sau đều đúng. Kết quả có thể được xác minh mà không cần làm lại, bằng một bài test, một diff, một quy tắc lint, hoặc mười giây đọc. Và một kết quả sai chỉ khiến người review tốn một phút chứ không phải cả buổi chiều, bởi vì phạm vi ảnh hưởng chỉ là một nhãn, một bình luận, hoặc một file.
Chính cặp tiêu chí đó giải thích vì sao dựng khung test thì đủ điều kiện còn review bảo mật thì không, dù cả hai đều là sinh văn bản trên cùng một repository. Một bài test được tạo ra hoặc chạy được hoặc không, và bạn biết kết quả ngay trong cùng một phút. Còn một lỗ hổng phân quyền bị bỏ sót trong một bình luận review thì trông y hệt như một bình luận sạch.
Những việc nên giao phó
| Công việc | Agent trả về gì | Cách kiểm tra | Phạm vi ảnh hưởng nếu sai |
|---|---|---|---|
| Phân loại báo cáo bug mới | Tóm tắt, component nghi ngờ, đã thử tái hiện hay chưa, gợi ý mức ưu tiên | Đọc bốn dòng khi tiếp nhận Task | Một Task bị định tuyến sai |
| Gắn nhãn và metadata | Nhãn và loại Task, kèm tên quy tắc đã áp dụng | Hiển thị ngay trên bảng điều khiển | Một nhãn sai |
| Changelog và ghi chú phát hành | Bản nháp ghi chú từ các diff đã merge trong một Sprint | So diff với các commit | Lỗi biên tập, bị phát hiện trước khi phát hành |
| Nhận xét review sơ bộ | Các quan sát dưới dạng bình luận, nói rõ không phải là phê duyệt | Người review đọc hoặc bỏ qua | Gây nhiễu, nếu không có gì phụ thuộc vào nó |
| Dựng khung test | Các file test biên dịch và chạy được, với những lỗ hổng rõ ràng được đánh dấu | Lần chạy test | Build đỏ |
| Cập nhật dependency | Mỗi Task một bản nâng cấp, kèm trích đoạn changelog và kết quả test | CI | Một lần revert |
| Cập nhật tài liệu sau khi merge | Chỉnh sửa tài liệu kèm dẫn nguồn diff | Review diff | Một trang lỗi thời tiếp tục lỗi thời |
Điểm chung của tất cả: mỗi thứ đều trả về một sản phẩm mà người khác đánh giá trong vài giây, dựa trên bằng chứng mà Agent đính kèm. Không thứ nào là kết luận cuối cùng cho bất cứ điều gì, và đó chính là phép thử cần áp dụng khi bạn mở rộng danh sách sang bất cứ thứ gì đội của bạn sẽ nhận tiếp theo.
Những việc không nên giao phó
Có ba ranh giới đáng nói rõ, vì một tầng rẻ thường mời gọi những sai lầm này.
Review sơ bộ không phải là review. Một Agent đăng các quan sát lên một diff chỉ tạo ra tài liệu để đọc. Nó không phải là phê duyệt, và khoảnh khắc một đội coi một lượt review sơ bộ sạch sẽ như tín hiệu rằng thay đổi đó an toàn, thì tầng rẻ đã bị thăng cấp thành người ra quyết định phê duyệt. Hãy nói rõ về những gì một review agent có thể và không thể xác minh, và ghi rõ trong chính bình luận rằng đây là lượt review sơ bộ.
Một nhãn mà bảng điều khiển tự động hóa dựa vào là một quyết định, không phải một ghi chú. Nếu việc chuyển một Task sang một trạng thái kích hoạt một lượt chạy, hoặc mức ưu tiên quyết định việc đội sẽ nhận gì tiếp theo, thì Agent gắn nhãn đang định hướng công việc. Hoặc là tắt tự động hóa trên những trường đó, hoặc là giữ việc gắn nhãn ở tầng mà bạn tin tưởng giao cho việc định hướng.
Công việc không ai kiểm tra không trở nên rẻ hơn, nó trở nên vô hình. Một câu trả lời sai rẻ chỉ rẻ khi có người nhận ra nó. Nếu một công việc không có người đọc, thì cách xử lý là xóa bỏ công việc đó, chứ không phải tìm một runtime rẻ hơn.
Vậy nên đây là cặp quyết định. Dùng Luna khi công việc có khối lượng lớn, có giới hạn rõ ràng, và được xác minh bằng thứ gì đó ngoài lòng tin. Dùng Sol hoặc Opus 5.5 khi một Task phải giữ ngữ cảnh xuyên suốt nhiều giờ, trải qua nhiều module, hoặc tốn nhiều chi phí để dừng giữa chừng hơn là tiền token. Nếu bạn chỉ chạy một Agent trên một repository, thì đừng tách tầng làm gì: hãy chọn runtime phù hợp với công việc khó nhất của bạn.
Viết một Task mà runtime rẻ có thể hoàn thành
Một Agent trong Sharkly là một cấu hình làm việc đã lưu chứ không phải một prompt dùng một lần. Chỉ dẫn, Runtime, Skills, repository, môi trường và cài đặt chạy của nó định hình cách nó xử lý công việc, nên đơn vị đúng là một Agent cho mỗi loại công việc nhàm chán, chứ không phải một Agent thông minh làm hết cả bảy việc. Một đội có thể giữ các Agent riêng cho thay đổi code, review, testing, tài liệu, hoặc phân loại vận hành mà không cần viết lại chỉ dẫn cho mỗi Task.
Một runtime rẻ cần phạm vi hẹp và một đích đến mang tính máy móc:
SH-312 Triage: 9 unassigned bug reports from this week
Assignee: Triage Agent (Codex Runtime, gpt-6-luna)
For each report, return on the Task:
- one-sentence restatement of the observed behavior
- the suspected component, with the file or module that led you there
- whether you could reproduce it locally, and the exact command you ran
- a priority suggestion with one reason
Do not change files. Do not close or merge anything.
Finish with any question that must be answered before implementation.
Có ba điểm trong Task đó làm nên công việc. Phạm vi chỉ là một lượt quét qua chín mục, nên nếu thất bại thì bỏ đi cũng rẻ. Mỗi khẳng định đều kèm bằng chứng, nên việc kiểm tra chỉ là đọc chứ không phải điều tra lại. Và hai dòng cuối thiết lập ranh giới: Agent này báo cáo, nó không hành động.
Có một cài đặt đáng để quyết định một cách có chủ đích. Những chiến thắng được công bố của Luna nằm ở mức reasoning effort cao và tối đa, và effort là một quyết định về chi phí và độ trễ chứ không phải một núm chất lượng bạn cứ để ở mức cao nhất. Artificial Analysis, cũng là một bên thứ ba, đo được biến thể reasoning tối đa đạt 153.9 token đầu ra mỗi giây đối với Luna, với khoảng 124 giây để có token đầu tiên. [VERIFY] Dù con số hiện tại là bao nhiêu, hình dạng vẫn giữ nguyên: ở mức effort tối đa, các mô hình rẻ không phải là những mô hình khởi động nhanh. Một công việc gắn nhãn mà suy nghĩ mất hai phút sẽ trông như bị treo trên bảng điều khiển. Hãy chạy các tác vụ ngắn ở mức effort vừa phải và để dành các cài đặt cao cho những Task xứng đáng với chúng.
Hai lưu ý về quyền truy cập, vì đây chính là tầng mà các đội bắt đầu làm quen. Luna chạy trong Codex và ChatGPT Work cho các gói Plus, Pro, Business, Enterprise và Edu, còn tài khoản Free và Go thì có nó trong ứng dụng desktop. Hiện nó chưa có trong Chat. Trong Sharkly, mô hình được cài đặt trong cấu hình Runtime hoặc công cụ Computer, không bao giờ trên Agent, và Sharkly sẽ không hiển thị lại tên mô hình cho bạn.
Phần mà việc giảm giá không thể sửa được
Chín bản tóm tắt triage với mức giá của Luna gần như chẳng tốn gì. Chúng vẫn tạo ra chín thứ mà một người phải đọc. Một đội chuyển toàn bộ phần việc xung quanh sang tầng rẻ không hề giảm bớt số quyết định đang chờ con người, mà chỉ làm cho chúng rẻ hơn để tạo ra, điều này không giống với rẻ hơn để phê duyệt. Đó là lý do vì sao hàng đợi review vẫn là giới hạn trên bất kể giá token thay đổi thế nào.
Điều bạn có thể thay đổi là mức độ dễ đọc của hàng đợi đó. Hãy giữ mục tiêu, lượt chạy, bằng chứng, các điểm tắc nghẽn và phần review của con người trên Task từ lúc yêu cầu đến lúc phát hành, để một bình luận review sơ bộ hiển nhiên là lượt sơ bộ, một bản tóm tắt triage mang theo câu lệnh đã tạo ra nó, và những mục thật sự đang chờ bạn có thể tách biệt khỏi những mục chỉ đơn thuần gây nhiễu. Agent nghiên cứu, thực thi, kiểm thử và báo cáo. Con người định hướng, trao quyền và phê duyệt kết quả.
Nếu bạn chạy nhiều agent và những agent rẻ sắp nhân lên nhanh chóng, Sharkly cho bạn một nơi để giao Task cho chúng, xem mỗi lượt chạy đã tạo ra gì, và quyết định cái gì được phát hành. Kết nối một Computer, tạo một Agent cho công việc nhàm chán nhất của bạn, và giao cho nó một Task thực sự.
