Trong file luật tôi viết cho AI của mình có một dòng nằm im từ nhiều tháng nay: giai đoạn nào phải đọc nhiều thì đừng đọc trong phiên chính, hãy đẩy sang một agent phụ. Dòng đó đúng, tôi đã đo nó, và tôi vẫn giữ nó cho đến hôm nay. Chuyện đáng kể là sáng 17 tháng 9, Claude Code làm đúng dòng đó, làm rất bài bản, và trong mười tám phút nó tiêu hết quota năm giờ của tôi cùng gần ba phần tư quota tuần. Lúc ấy tôi không ngồi trước máy.
Thứ làm tôi ngồi xuống viết bài này không phải con số. Là chuyện tôi đọc lại từng bước của nó, chậm rãi, hai lần, và không tìm ra bước nào sai.
Mười hai agent chạy đúng, và quota năm giờ bay trong mười tám phút
Việc hôm đó là một pipeline trích xuất: 84 video, 23 MB transcript, cần rút ra các phát biểu kèm mốc thời gian và câu trích nguyên văn. Tôi bảo nó vá ba chỗ còn lỗi rồi chạy lại trên corpus thật, rồi tôi rời bàn.
Nó nhận ra corpus quá lớn so với ngữ cảnh của chính nó, nên theo đúng luật tôi viết, nó chạy một agent phụ thử nghiệm trên một nguồn trước. Kết quả đạt: 318 trên 318 câu trích khớp nguyên văn với transcript, và nó kiểm bằng script chứ không tin báo cáo tự chấm của agent kia. Đến đây mọi thứ vẫn là thứ tôi muốn thấy.
Rồi nó viết một câu rất hợp lý: chạy nốt mười một nguồn còn lại. Trong ba mươi chín giây, mười một agent nữa được tạo. Đây là số đo lấy thẳng từ file nhật ký phiên, đã khử trùng lặp theo mã lượt gọi:
| Chỉ số | Giá trị |
|---|---|
| Cửa sổ thời gian | 09:55:08 → 10:12:45, đúng 18 phút |
| Số agent chạy song song lúc đỉnh | 11 |
| Model của 501 trên 502 lượt gọi | Opus, vì không ai khai model nên nó kế thừa của phiên cha |
| Token tiêu thụ | 117.700.000 |
| Phần rơi vào cache read | 95% |
| Ngữ cảnh mỗi lượt gọi của một agent | trung vị 363.000, đỉnh 638.000 |
| Tổng output hữu ích của cả 12 agent | khoảng 57.000 token |
| Tỉ lệ vào trên ra | khoảng 2000 trên 1 |
Chất lượng công việc không hề tệ. Các agent làm đúng việc, output sạch, validator chạy qua. Đây không phải chuyện AI làm sai.
Chỗ này đáng nói thêm một câu, vì nó là ràng buộc của tôi chứ không phải của một phòng kỹ thuật có ngân sách. Tôi làm một mình, trả tiền theo gói thuê bao, và quota là thứ cả ngày làm việc dùng chung. Một đợt đốt trong mười tám phút không hiện ra thành hóa đơn cuối tháng để tôi cân nhắc sau, nó hiện ra thành một buổi chiều không làm được gì.
Phép nhân mà không ai buộc phải viết ra
Trực giác sai mà hầu hết chúng ta đều mang theo là thế này: đọc một file 40.000 ký tự thì tốn khoảng 10.000 token, đọc xong là trả xong.
Trong một agent nhiều lượt thì không. Mỗi lượt gửi lại toàn bộ ngữ cảnh, nên file bạn nạp vào ở lượt thứ năm bị tính tiền lại ở lượt thứ sáu, thứ bảy, thứ tám, cho đến khi agent đó kết thúc.
Chi phí thật của một lần đọc bằng dung lượng nội dung nhân với số lượt còn lại sau đó, rồi nhân tiếp với số agent đang cùng giữ nội dung ấy.
Thay số của hôm đó vào: khoảng 227.000 token tài liệu, nhân với khoảng 70 lượt, nhân với 12 agent, ra đúng cái khối 117,7 triệu. Đó cũng là lý do 95% khối lượng rơi vào cache read — tiền trả cho việc đọc lại thứ đã đọc, thứ tôi đã tách đơn giá trong bài về luật giữ cache. Và mỗi agent còn mang theo cái sàn ngữ cảnh riêng của nó, khoảng chín mươi nghìn token trước khi nó kịp đọc chữ nào, đúng cái sàn tôi đã bóc tách trong bài về sàn ngữ cảnh.
Bốn nguyên nhân dẫn tới đó, và không nguyên nhân nào là "AI ngu".
Luật của tôi có chiều đi mà không có chiều giá. Nó viết rằng giai đoạn đọc nặng thì đẩy sang agent phụ, hoàn toàn đúng cho một agent, và hoàn toàn im lặng về chuyện gì xảy ra khi con số đó thành mười một. Không có phép nhân nào được yêu cầu, nên không có phép nhân nào được thực hiện.
Pilot đạt bị hiểu thành được phép nhân bản. Pilot chứng minh chất lượng, nó không nói gì về chi phí. Trớ trêu là chính pilot vừa trao đúng con số cần thiết — 27,6 triệu token cho một nguồn — và con số đó không được ai nhìn.
Không khai model thì kế thừa model của phiên cha. Cả mười hai con chạy model mạnh nhất để đi dò chuỗi và chép mốc thời gian, tức là loại việc không có một chút phán đoán nào và model rẻ nhất làm cũng đạt, vì đầu ra được kiểm bằng script chứ không bằng cảm nhận.
Và không có cái phanh cơ học nào. Máy tôi để chế độ bỏ qua hỏi quyền vì tôi cần agent tự chạy, lại không cài hook nào, nghĩa là không tồn tại điểm nào trong hệ thống có thể dừng lại và hỏi một câu. Khi tôi vắng mặt, hệ thống mặc định chạy tiếp.
Agent được điều phối, nhưng không được giữ dữ liệu
Hook và luật chỉ chặn thiệt hại. Thứ làm thiệt hại biến mất là thiết kế lại chính công việc, nên tôi bắt đầu từ đây trước.
Câu hỏi để nhận diện chỉ có một: kết quả của đơn vị X có đổi không nếu đơn vị Y không tồn tại? Với việc trích phát biểu từ transcript, câu trả lời là không đổi. Vậy đó là một phép map thuần túy, và map thì không cần agent có trí nhớ.
Tôi viết lại giai đoạn đó: một script cắt transcript thành các chunk khoảng 16.000 ký tự, chồng lấn 800 ký tự để câu trích không bị cắt đôi ở mép; mỗi chunk là một lời gọi model độc lập; kết quả ghi ra file riêng theo từng chunk; rồi một bước gộp cuối gán mã, khử trùng lặp và áp trần số dòng. Đo lại trên đúng corpus cũ:
| Cách làm | Token đầu vào, một lượt chạy đầy đủ |
|---|---|
| 12 agent cùng giữ transcript trong ngữ cảnh | 117.700.000 |
| 225 chunk độc lập, cùng corpus | 1.074.304 |
Chênh khoảng 110 lần, và chất lượng không đổi — vì mỗi dòng đầu ra vẫn bị kiểm bằng máy: mốc thời gian phải là cue marker có thật trong chunk, câu trích phải là chuỗi con thật sau khi chuẩn hoá khoảng trắng, schema phải đủ trường. Dòng nào sai bị đẩy sang file loại bỏ kèm lý do, không bao giờ bị vứt im lặng.
Bốn thứ cần giữ nếu bạn làm tương tự. Agent được phép điều phối map nhưng cấm giữ dữ liệu: agent gọi script, script gọi model theo từng chunk, agent chỉ đọc lại kết quả đã gộp. Mỗi chunk ghi ra file riêng để chạy lại thì bỏ qua chunk đã có, vì không có tính chất đó thì một lần gián đoạn giữa chừng bắt bạn trả tiền lại từ đầu. Trần cứng nằm trong script dưới dạng một tham số số token tối đa, vượt thì thoát với mã lỗi, để cái phanh nằm trong tay bạn chứ không phụ thuộc vào việc model có tỉnh táo hay không. Và đo một chunk trước rồi mới nhân, để ngân sách là con số bạn biết trước khi bấm chạy chứ không phải con số bạn đọc được sau đó.
Cái phanh cho lúc tôi không ngồi trước máy
Thiết kế lại công việc là thứ đúng về lâu dài. Nhưng hôm đó tôi vắng mặt, và thứ duy nhất có thể cứu được một buổi chiều là một cái phanh chạy độc lập với sự tỉnh táo của cả tôi lẫn model.
Hook trong Claude Code làm được đúng việc đó. Nó chạy như một tiến trình riêng, trước khi công cụ được thực thi, và theo tài liệu của Anthropic thì nó chạy kể cả khi bạn đang ở chế độ bỏ qua hỏi quyền — nên bạn không phải từ bỏ chế độ tự động để có được nó. Cơ chế rất gọn: Claude Code đẩy vào đầu vào chuẩn của script một khối JSON mô tả lời gọi công cụ, script in ra một khối JSON quyết định cho chạy, chặn, hoặc dừng lại hỏi người dùng. Giá trị tôi dùng cho vế thứ ba là ask, và trên máy tôi nó bật hộp thoại hỏi thật — quan trọng hơn, khi tôi vắng mặt thì nó đứng chờ thay vì cháy.
Cái phanh của tôi nằm ở ~/.claude/hooks/agent-fanout-guard.py, khoảng 150 dòng Python thư viện chuẩn, và nó chỉ có bốn quyết định:
| Điều kiện | Quyết định |
|---|---|
| Lần spawn thứ 3 trở đi trong 10 phút | Hỏi lại, kèm yêu cầu nêu ngân sách thành số |
| Lần spawn thứ 6 trở đi trong 10 phút | Chặn thẳng |
| Prompt có dấu hiệu đọc hàng loạt và model không được khai | Hỏi lại, yêu cầu dùng model rẻ |
| Có file ngân sách đã khai báo còn hạn | Cho chạy tới đúng số agent đã khai |
Vì sao ngưỡng là ba: một agent là bình thường, hai agent là hai việc song song, còn ba trong mười phút thì về bản chất không còn là giao việc nữa mà đã là nhân bản — và nhân bản là thứ duy nhất có khả năng đốt sạch quota trong vài phút. Ngưỡng này gần như không bao giờ phiền tôi trong một ngày làm việc bình thường.
Một chi tiết mà tôi chỉ hiểu ra sau khi viết hỏng lần đầu: bộ đếm phải ghi ra đĩa. Mười một lệnh spawn kia đến từ một lượt trả lời duy nhất, trong ba mươi chín giây, và mỗi lệnh là một tiến trình hook riêng biệt không biết gì về nhau. Đếm trong bộ nhớ thì con số luôn bằng một, và cái phanh trở thành đồ trang trí.
Script cố ý hỏng theo hướng mở: nếu chính nó lỗi thì công việc vẫn chạy. Một cái phanh hỏng không nên khoá cứng bánh xe.
Tôi không dán 150 dòng đó vào đây, vì thứ đáng chép không phải là chữ trong script mà là bốn dòng quyết định ở bảng trên. Đưa bảng đó cho chính con agent của bạn kèm một câu — hook loại chạy trước khi công cụ thực thi, đọc JSON ở đầu vào chuẩn, in JSON quyết định ra đầu ra chuẩn, bộ đếm ghi ra đĩa, lỗi thì cho qua — nó viết lại trong hai phút, đúng đường dẫn và đúng hệ điều hành của bạn. Hai chỗ tôi vấp khi cài, nói trước để bạn khỏi vấp: đừng dùng jq trong lệnh hook vì rất nhiều máy Windows không có nó và hook sẽ hỏng âm thầm, và để đường dẫn không có khoảng trắng, không bọc ngoặc kép, vì quy tắc trích dẫn khác nhau giữa các loại shell.
Tài liệu của Anthropic không nói sai chỗ nào
Điểm tôi muốn đối chiếu ra ngoài nằm ở đây. Tài liệu chính thức về subagent của Anthropic viết rằng mỗi subagent chạy trong cửa sổ ngữ cảnh riêng của nó, và lý do nên dùng subagent là để phần việc đọc nhiều không làm ngập phiên chính. Bạn đọc được nguyên văn ở trang tài liệu subagent của Claude Code.
Cả hai câu đều đúng, và số đo của tôi không phủ nhận câu nào. Chỗ dễ trượt nằm ở chữ "riêng". Mặt được của nó là phiên chính sạch. Mặt phải trả tiền là mỗi cửa sổ riêng phải tự nạp lại từ đầu, tự mang cái sàn của nó, và không cửa sổ nào biết cửa sổ bên cạnh đang giữ đúng thứ mình vừa đọc.
Tài liệu mô tả lợi ích ở số ít. Hóa đơn xuất hiện ở số nhiều. Giữa hai chỗ đó không có ai đặt sẵn một phép nhân, và đó chính xác là khoảng trống mà luật của tôi cũng bỏ trống.
Vì sao cách cũ vẫn không biến mất
Người phản đối mạnh nhất sẽ nói thế này, và họ đúng phần lớn.
Viết script cắt chunk, viết schema, viết validator là công phải trả trước, và nó tốn một buổi. Với một việc chỉ chạy đúng một lần rồi thôi, nhân bản mười hai agent vẫn rẻ hơn khi tính bằng thời gian người chứ không bằng token. Quan trọng hơn, có cả một lớp công việc mà kết quả của đơn vị này phụ thuộc vào đơn vị kia, và "xong" chỉ xác định được bằng phán đoán chứ không bằng một lệnh thoát với mã 0 — đọc một codebase lạ để hiểu kiến trúc, dò một lỗi vắt qua nhiều file, đọc phản hồi review từng mục. Ở lớp đó, agent có trí nhớ thắng script, và thắng rõ.
Nên cái tôi bỏ không phải là subagent, và cũng không phải là chạy song song. Cái tôi bỏ là chạy song song mà không khai ngân sách trước.
Ranh giới nằm ở hai câu hỏi, hỏi theo đúng thứ tự. Kết quả của đơn vị X có đổi không nếu đơn vị Y không tồn tại, và "xong" có kiểm được bằng máy không. Hai câu cùng trả lời có thì đó là map, và map giao cho script; một trong hai trả lời không thì đó là việc cần phán đoán, giữ agent — chỉ là trước lần spawn thứ nhất của đợt, viết ra một dòng: bao nhiêu agent, nhân bao nhiêu ngữ cảnh mỗi agent, nhân bao nhiêu lượt dự kiến. Một dòng số học lớp ba, và nó là thứ duy nhất hôm đó không ai viết.
Ai không nên làm theo, và cái giá nếu tôi sai
Cái phanh này không dành cho tất cả. Ai chạy agent qua gói API trả theo lượng, có hạn mức của công ty và có người theo dõi hóa đơn thì ngưỡng ba lần trong mười phút chỉ làm phiền, vì thứ họ cần là cảnh báo chi tiêu chứ không phải chặn hành vi. Ai dùng agent chủ yếu cho việc cần phán đoán thì gần như không bao giờ chạm ngưỡng, nên cài vào cũng chỉ để đó. Và bộ đếm này là toàn cục theo máy, nên hai phiên chạy song song mỗi phiên hai agent là đã bốn lần trong cửa sổ và bạn sẽ bị hỏi — làm việc kiểu đó thì nâng ngưỡng lên, đừng gỡ phanh.
Còn cái giá nếu tôi sai ở bài này. Bạn cài phanh với ngưỡng quá chặt thì mất vài phút mỗi lần bị hỏi, và có thể lỡ một đợt song song hoàn toàn hợp lệ. Bạn viết lại một pipeline thành map mà hoá ra công việc đó thật sự cần trí nhớ vắt qua các chunk thì mất một buổi và phải quay lại chỗ cũ. Đó là cái giá của việc tin tôi: một buổi làm việc, hỏng thì biết ngay trong ngày. Cái giá của việc không có phanh thì tôi đã trả rồi, và nó không báo trước.
Điều gì sẽ làm tôi đổi ý
Nếu ai chỉ ra được một phép đo cho thấy mười hai agent song song trên cùng corpus rẻ hơn hoặc ngang với map theo chunk khi đã tính cả thời gian người bỏ ra để viết script, thì phần lõi của bài này sập, và tôi sẽ viết lại nó. Tôi cũng sẽ tự chạy lại phép đo trên đúng corpus đó vào cuối tháng 11 năm 2026, khi pipeline đã chạy đủ nhiều vòng để có biên độ chứ không chỉ một lần chạy, và tôi sẽ đăng kết quả kể cả khi nó phủ nhận bài này.
Một dấu ngày cho phần kỹ thuật: mọi số ở đây đo trên Claude Code ngày 17 tháng 9 năm 2026, một máy, một sự cố, đọc từ file nhật ký phiên của chính công cụ. Đủ để tin vào cơ chế, không đủ để trích dẫn như một con số ngành. Tên trường trong hook và cách khai báo hoàn toàn có thể đổi ở bản sau, nên kiểm lại ở tài liệu trước khi chép. Toàn bộ số đo chi phí của chuỗi bài này nằm trong hub số liệu chi phí token.
Hai chặng để bạn bắt đầu tuần này
Chặng thứ nhất mất năm phút và làm được ngay hôm nay: dựng cái phanh. Đưa bảng bốn quyết định ở trên cho agent của bạn, bảo nó viết script và khai báo vào cấu hình, rồi khởi động lại công cụ vì cấu hình chỉ nạp ở phiên mới. Thử bằng cách bảo nó tạo ba agent rác; con thứ ba phải bật hộp thoại hỏi. Không bật thì gần như chắc chắn sai đường dẫn, vì hook hỏng thì im lặng chứ không báo lỗi.
Chặng thứ hai mất một buổi: lấy giai đoạn đọc nặng nhất trong việc của bạn ra, hỏi đúng hai câu ở trên. Cả hai cùng trả lời có thì đổi hình dạng công việc đó thành map trước khi nghĩ đến chuyện giao cho bao nhiêu agent. Còn khi nó là việc cần phán đoán thì để nguyên, và chỉ thêm một dòng ngân sách trước lần spawn đầu tiên. Cách tôi chia loại việc nào cho công cụ nào, tôi đã viết trong bài về phối hợp nhiều công cụ.
Điều tôi nhận ra
Tôi đi tìm câu trả lời cho câu hỏi "vì sao đợt đó đắt thế", và tìm thấy câu trả lời cho một câu hỏi khác hẳn: dữ liệu nên nằm ở đâu. Ngữ cảnh của một agent không phải chỗ chứa dữ liệu, nó là chỗ chứa việc đang làm dở. Mọi thứ tôi nhét vào đó vì tiện đều bị đọc lại ở mọi lượt còn lại, trên mọi agent đang giữ nó.
Nhưng thứ tôi nhớ lâu hơn cả con số là điều này: không có bước nào trong chuỗi hôm đó là ngu ngốc. Đẩy việc đọc nặng ra khỏi phiên chính là đúng. Chạy pilot trước khi chạy thật là đúng. Kiểm bằng script thay vì tin báo cáo tự chấm là đúng. Chi phí không nằm trong bước nào cả, nó nằm ở tích của chúng — và cái tích thì không ai nhìn thấy, trừ khi có một chỗ nào đó trong hệ thống buộc phải viết nó ra thành một con số trước khi bấm chạy.
