Góc Học Trò - Hoctro's Place

Ghi lại những mẩu chuyện, cảm nghĩ về âm nhạc và ngành điện toán/tin học, trong đó có trí tuệ nhân tạo (AI) bằng Claude AI. Posting in both English and Vietnamese my thoughts about popular music and Artificial Intelligence using Anthropic's Claude AI and Claude Code CLI. I'm a "Software 3.0" coder, specializing in producing essays. I have not written a single line of python or javascript code, just plain English language.

8.22.2026

Một Cách "Chia Việc" Cho Nhiều Trợ Lý AI Cùng Làm

Written and translated to Vietnamese by: Claude Sonnet AI.

Curator/Editor: Học Trò.

Boris Cherny Nói Gì Về "Luồng Việc Tự Động", "Vòng Lặp" Và "Lịch Chạy Định Kỳ" — Và Mười Cách Áp Dụng

Đoạn phát biểu được trích dẫn ở đây dùng nhiều chữ nghe có vẻ chuyên ngành, nhưng thật ra không khó hiểu. "Luồng việc tự động", "vùng chạy thử an toàn Bun", "công thức ghép trợ lý AI", "sức tính lúc trả lời", "vòng lặp và lịch chạy định kỳ" — mỗi cụm đều chỉ một thứ rất cụ thể, và gộp lại chúng mô tả một sự thay đổi lớn: phần đáng chú ý trong việc "dùng AI" bây giờ không còn là câu mình gõ vào, mà là cả bộ máy vận hành xung quanh câu gõ đó. Bài dưới đây giải thích từng khái niệm bằng lời dễ hiểu, rồi đưa ra mười cách áp dụng thực tế, lấy từ chính những dự án đang có trên ổ đĩa này. Cuối bài có một bảng giải thích thuật ngữ (Glossary) cho những từ chuyên ngành không tránh được.

Ai đang nói, và nói lúc nào

Boris Cherny là người tạo ra Claude Code, làm việc tại Anthropic (công ty làm ra Claude). Những điều được trích ở đây là từ một cuộc trò chuyện với Diana Hu, ghi hình tại sự kiện Startup School của Y Combinator ngày 27-7-2026, ngay sau khi phiên bản Claude Opus 5 ra mắt. Cùng buổi nói chuyện này còn có câu được nhắc lại rất nhiều: họ đã xóa khoảng 80% đoạn "chỉ dẫn nền" (system prompt) của Claude Code khi chuyển qua Opus 5, và kết quả là hệ thống lại chạy tốt hơn. Ông cũng dùng cụm "khoảng trống sản phẩm" (product overhang) — tức là khoảng cách giữa những gì một hệ thống AI có thể làm được, và những gì sản phẩm đang bao quanh nó cho phép nó làm. "Luồng việc tự động" chính là câu trả lời của ông cho khoảng trống đó. Mọi thứ ông mô tả trong đoạn trích đều đã có thật, đã công bố công khai vào lúc ông nói ra — không có gì là suy đoán.

Ông mô tả hai cách làm khác nhau. Đây không phải là hai biến thể của cùng một ý tưởng — chúng giải quyết hai vấn đề trái ngược nhau. Nên tách riêng ra tìm hiểu từng cái, rồi mới ráp lại.

Cách thứ nhất: luồng việc tự động

Vấn đề của "cái khung" quanh AI

Cứ hình dung mỗi khi dùng AI để làm việc, phải có một "cái khung" bao quanh nó — quyết định AI được dùng công cụ gì, làm bước nào tiếp theo, khi nào coi là xong việc. Claude Code chính là một cái khung như vậy; bất kỳ công cụ "trợ lý AI" nào khác cũng đều có một cái khung tương tự. Theo Cherny, vấn đề là: một cái khung cố định thì hợp với việc này nhưng lại bó tay việc khác. Ý tưởng của ông là: bây giờ AI đã đủ giỏi để tự viết ra cái khung riêng cho từng việc, thay vì dùng một khung chung cho tất cả. Bên trong Anthropic gọi đây là "mỗi việc một cái khung riêng."

Vì sao cái khung mặc định lại bó tay với việc lớn? Vì trong cách dùng Claude Code bình thường, chính AI là người "cầm trịch" — mỗi lượt nó tự quyết định làm gì tiếp theo, và mọi kết quả giữa chừng — mỗi lần đọc file, mỗi lần tìm kiếm hụt, mỗi báo cáo nửa vời từ trợ lý phụ — đều dồn hết vào một "vùng nhớ tạm" (bộ nhớ ngắn hạn của cuộc trò chuyện) duy nhất. Vùng nhớ đó chính là nút thắt cổ chai, và từ đó sinh ra ba kiểu lỗi quen thuộc. Anthropic đặt tên cho ba tật này: tật lười (AI dừng sớm vì phần việc còn lại không còn "vừa" thoải mái trong vùng nhớ nữa), tật tự khen mình (AI tự chấm điểm kết quả của chính nó, và dĩ nhiên là thích nó), và tật lạc mục tiêu dần dần (mỗi lần tóm tắt lại làm mục tiêu ban đầu mòn dần, lệch sang một hướng gần giống nhưng không còn đúng như lúc đầu).

Cách nó hoạt động

Một "luồng việc tự động" là cách chuyển kế hoạch làm việc ra khỏi vùng nhớ tạm đó, đưa nó vào một đoạn chương trình máy tính thật sự. Khi mình yêu cầu, Claude sẽ viết ra một đoạn chương trình nhỏ (viết bằng ngôn ngữ lập trình JavaScript), có nhiệm vụ gọi ra và điều phối nhiều "trợ lý phụ" — rồi một hệ thống khác sẽ chạy đoạn chương trình đó ở chế độ nền, trong khi cuộc trò chuyện chính của mình vẫn phản hồi bình thường, không bị đứng khựng lại chờ.

Những "khối lệnh" cơ bản rất đơn giản. Có một lệnh gọi là agent(...) — gọi ra một trợ lý phụ để làm một việc, rồi lấy lại kết quả. Có một lệnh gọi là pipeline(...) — cho chạy một trợ lý phụ cho từng phần tử trong một danh sách (ví dụ: một trợ lý riêng cho mỗi file). Phần còn lại là các câu lệnh lập trình bình thường: nếu-thì, lặp lại, lọc, sắp xếp — nên có thể tự do kết hợp chúng lại. Một luồng việc tự động đơn giản trông đại khái như sau (không cần hiểu hết cú pháp, chỉ cần hiểu ý): "tìm hết mọi file cần kiểm tra trong một thư mục" → "cho mỗi file, gọi một trợ lý riêng đi kiểm tra file đó xem có thiếu bước xác thực đăng nhập không" → "gom hết các báo cáo, chỉ giữ lại những cái tìm thấy vấn đề thật."

Chỉ vài dòng vậy thôi, nhưng nó có thể tự chia ra thành rất nhiều trợ lý phụ độc lập, mỗi trợ lý có vùng nhớ tạm riêng của mình, chỉ nhìn thấy đúng một file được giao.

Đoạn chương trình đó chạy trong một môi trường cách ly an toàn tên là Bun (một hệ thống chạy chương trình JavaScript rất nhanh). Claude Code dùng Bun như một cái "hộp cát" — đoạn chương trình chạy trong đó bị cố tình chặn không cho đụng trực tiếp vào ổ đĩa hay dòng lệnh của máy tính, cũng không được nạp thêm những đoạn mã lạ từ bên ngoài vào. Nói cách khác: bản thân đoạn chương trình đó không đụng được vào máy của mình — nó chỉ có thể nhờ các trợ lý phụ đi làm việc đó giùm. Sự tách bạch này vừa là lớp an toàn, vừa chính là ý tưởng cốt lõi: cái "khung điều phối" chỉ lo sắp xếp công việc, còn các trợ lý phụ mới là "tay chân" thật sự đi làm.

Điều Cherny thật sự quan tâm là chuyện vùng nhớ tạm. Toàn bộ kết quả giữa chừng được giữ lại trong biến số của đoạn chương trình đó, chứ không đổ dồn vào vùng nhớ tạm của cuộc trò chuyện với Claude. Một lần chạy như vậy có thể ngốn tổng cộng bằng hàng trăm "vòng đời" đọc-và-suy-nghĩ của các trợ lý phụ cộng lại — nhưng thứ trả về cuộc trò chuyện của mình chỉ là câu trả lời cuối cùng. Cả đống việc lặt vặt ở giữa không bao giờ "đổ" vào màn hình của mình.

Vì sao gọi là "công thức ghép trợ lý AI"

Cherny xuất thân từ trường phái lập trình hàm (một cách viết chương trình chú trọng việc "ghép các hàm nhỏ lại với nhau"), nên cách ông dùng chữ "công thức" (algebra) ở đây là có chủ đích, không phải nói cho hoa mỹ. Một "công thức" theo nghĩa này là: có một số ít loại "giá trị" cơ bản, cộng với vài "phép toán" để ghép chúng lại — ghép hai cái vào nhau thì lại ra một cái cùng loại, nên có thể ghép tiếp mãi. Ở đây, "giá trị" chính là một lần chạy của một trợ lý, còn "phép toán" là làm tuần tự và làm song song. Vì cả hai phép này đều trả về đúng loại kết quả mà chúng nhận vào ban đầu, nên có thể lồng chúng vào nhau tùy ý: một nhánh chạy song song, mà bên trong mỗi nhánh lại là ba bước làm tuần tự, dẫn tới một bước kiểm tra chéo mà bản thân bước đó lại chia thành nhiều nhánh song song khác. Cứ thế lồng nhau mãi.

Từ hai "phép toán" đơn giản đó, người ta đã tổng kết ra được một số kiểu bài toán quen thuộc:

Chia việc rồi gộp lại — chia nhỏ công việc, xử lý từng phần độc lập, rồi gộp kết quả.
Phân loại rồi xử lý riêng — mỗi loại việc giao cho một cách xử lý khác nhau.
Kiểm tra chéo kiểu "phản biện" — một nhóm trợ lý phụ thứ hai chuyên đi "bắt lỗi" kết quả của nhóm thứ nhất, đối chiếu với một bộ tiêu chí rõ ràng, trước khi báo cáo bất cứ điều gì. Đây chính là cách sửa trực tiếp "tật tự khen mình" nói ở trên: người chấm điểm không phải là người làm ra kết quả.
Tạo ra nhiều phương án rồi lọc lấy cái tốt — làm ra thật nhiều phương án, chỉ giữ lại những cái đạt yêu cầu.
Đấu loại từng cặp — thay vì nhờ một trợ lý duy nhất sắp xếp cả một danh sách dài (rất dễ sai vì danh sách quá dài để "nhớ" hết), thì cho từng cặp đấu với nhau, ai hơn đi tiếp, giống giải đấu thể thao.
Lặp tới khi xong — kiểm tra, sửa chỗ sai, lặp lại, cho tới khi đạt hoặc tới khi hai lần liên tiếp không còn tiến bộ gì thêm thì dừng.

Cái sơ đồ ba bước mà Cherny nhắc tới trong đoạn trích — chia việc ra, rồi kiểm tra/tóm tắt, rồi lại chia việc tiếp — chỉ là một cách ghép trong số rất nhiều cách ghép có thể có từ mấy "phép toán" cơ bản đó.

Cách thật sự gọi nó ra dùng

Câu ông nói "chỉ cần nói là dùng một luồng việc tự động thôi" là đúng theo nghĩa đen. Gõ vào lời nhắn của mình cụm use a workflow hoặc run a workflow là đủ để bật chế độ này lên; gõ từ khóa ultracode cũng có tác dụng tương tự. Bật /effort ultracode thì để Claude tự quyết định, tùy từng việc, cho suốt phần còn lại của phiên làm việc. Claude Code có sẵn một luồng việc dựng sẵn tên /deep-research — nó tự chia việc tìm kiếm ra nhiều hướng khác nhau, đối chiếu chéo các nguồn với nhau, "biểu quyết" xem từng thông tin có đáng tin không, rồi trả về một báo cáo có trích nguồn, đã loại bỏ những thông tin không qua được vòng đối chiếu chéo. Khi một lần chạy cho ra đúng thứ mình muốn, chỉ cần bấm phím s ở màn hình /workflows là lưu lại đoạn chương trình của lần chạy đó thành một câu lệnh gõ tắt để dùng lại sau này — tức là bản thân "cách sắp xếp công việc" cũng trở thành một thứ được lưu lại, chứ không chỉ có kết quả của nó.

Những giới hạn cần biết

Tối đa 1.000 trợ lý phụ cho một lần chạy, và tối đa 16 trợ lý chạy cùng lúc (ít hơn nữa nếu máy yếu). Con số "hàng ngàn trợ lý" mà Cherny hay nhắc tới là tính gộp qua nhiều lần chạy của cả một dự án, không phải của một lần chạy duy nhất.
Không thể chen vào giữa chừng. Không có chuyện dừng lại giữa các bước để mình duyệt qua rồi mới cho chạy tiếp — muốn vậy thì phải tách mỗi bước ra thành một luồng việc riêng.
Việc chạy lại sau khi dừng khá "thô". Nếu dừng giữa chừng, kết quả được giữ lại chỉ tính tới ngay trước trợ lý phụ đầu tiên chưa làm xong — mọi việc bắt đầu sau đó đều phải làm lại từ đầu, kể cả nếu nó thật ra đã làm xong rồi. Chia thành nhiều việc nhỏ giữ được nhiều tiến độ hơn là chia thành ít việc lớn.
Chi phí. Một lần chạy như vậy có thể tốn nhiều hơn hẳn so với làm cùng việc đó theo kiểu trò chuyện thông thường từng bước một. Claude Code sẽ tự cảnh báo "luồng việc lớn" nếu ước tính vượt quá 1,5 triệu đơn vị chữ (token — đơn vị đo lượng chữ mà hệ thống xử lý) hoặc quá 25 trợ lý phụ; có một tùy chọn tên workflowSizeGuideline (nhỏ / vừa / lớn / không giới hạn, mặc định là "vừa") để báo trước cho Claude biết nên nhắm cỡ nào. Đây là cái nút quan trọng nhất cần để ý, nhất là với ai đang dùng gói thuê bao có giới hạn mức dùng, chứ không phải trả tiền theo từng lượt dùng.

Vì sao ông gọi đây là "một kiểu sức tính toán lúc trả lời hoàn toàn mới"

Trước đây, câu chuyện về việc AI "càng lớn càng giỏi" xoay quanh ba yếu tố: số lượng tham số của hệ thống, lượng dữ liệu đem ra huấn luyện, và lượng phép tính bỏ ra lúc huấn luyện. Rồi có thêm một yếu tố thứ tư — sức tính toán lúc trả lời — nghĩa là lượng phép tính bỏ ra ngay lúc AI đang trả lời câu hỏi, chứ không phải lúc học từ trước. Ở dạng đầu tiên, điều này có nghĩa là để một hệ thống AI "suy nghĩ" lâu hơn trước khi trả lời — dùng nhiều chữ hơn để lập luận trước khi chốt câu trả lời.

Cherny cho rằng "luồng việc tự động" là một dạng khác của yếu tố thứ tư này, và ông có lý khi nói nó khác về bản chất. Cách "suy nghĩ lâu hơn" nói trên là kiểu nối tiếp — vẫn một vùng nhớ tạm duy nhất, chỉ là dùng nhiều chữ hơn, và càng dùng nhiều chữ thì chất lượng càng có xu hướng giảm dần vì vùng nhớ đầy lên. Còn "luồng việc tự động" là kiểu song song và có tổ chức — nhiều vùng nhớ tạm riêng biệt, mỗi cái nhỏ gọn và "sạch," lại có thêm những bước kiểm tra chéo xen giữa. Nó tận dụng được một hướng mà một vùng nhớ dài duy nhất không làm được, vì chính cái nhược điểm của vùng nhớ dài (bị loãng dần) lại là thứ mà cách chia nhỏ ra tránh được. Và quan trọng hơn: nhờ có các bước kiểm tra chéo, lượng phép tính bỏ thêm ra mua được độ tin cậy, chứ không chỉ là mua thêm số lượng suông. Cho mười trợ lý cùng làm một câu hỏi rồi lấy trung bình chưa chắc đã tốt hơn một trợ lý; nhưng cho mười trợ lý làm, rồi có ba "trợ lý phản biện" cố tìm lỗi từng kết quả, thì rõ ràng đáng tin hơn hẳn.

Bằng chứng thực tế, và cả mặt trái cần nói thẳng

Ví dụ nổi bật nhất là chính dự án viết lại phần lõi của công ty Bun: 535.496 dòng mã nguồn viết bằng ngôn ngữ Zig, trải trên 1.448 file, được chuyển hết sang ngôn ngữ Rust chỉ trong mười một ngày, dùng khoảng 50 luồng việc tự động và tối đa 64 "phiên bản Claude" chạy song song cùng lúc, trải trên bốn bản sao làm việc riêng của kho mã nguồn — cho ra 6.502 lần lưu thay đổi và tổng cộng hơn một triệu dòng thay đổi. Cấu trúc gồm ba lớp: một trợ lý viết mã, hai trợ lý đóng vai "phản biện" tìm lỗi, và một trợ lý chuyên sửa lỗi cho mỗi phần việc — chính là kiểu "kiểm tra chéo phản biện" nói ở trên, chỉ là áp dụng ở quy mô lớn. Không có bài kiểm tra nào bị bỏ qua hay xóa đi; toàn bộ bộ kiểm tra chạy qua được trên cả sáu nền tảng khác nhau trước khi ghép vào bản chính; và việc phản biện chéo đã bắt được ba lỗi nghiêm trọng liên quan tới cách quản lý bộ nhớ máy tính (trong đó có một lỗi kiểu "dùng lại vùng nhớ đã bị giải phóng") trước khi ghép vào bản chính. Chi phí ước tính khoảng 165.000 đô la Mỹ, tính theo giá công khai.

Nhưng phần mặt trái cũng cần nói ngay trong cùng đoạn này. Sau khi ghép vào bản chính, có 19 lỗi mới phát sinh, và chính người sáng lập ra ngôn ngữ Zig đã công khai gọi kết quả này là "hàng làm ẩu, không ai kiểm tra kỹ." Cả hai điều đều đúng cùng lúc: bộ máy này đã làm trong mười một ngày cái việc được ước tính tốn cả một năm công sức con người — nhưng nó cũng để lọt những lỗi mà một quy trình chậm hơn có lẽ đã không để lọt. Điều câu chuyện này thật sự cho thấy là: cái khan hiếm không phải là khả năng "làm ra" (viết code), mà là khả năng "kiểm tra lại cho kỹ" — và nói cho cùng, "luồng việc tự động" chính là một cách để mua thêm sự kiểm tra đó.

Cách thứ hai: vòng lặp và lịch chạy định kỳ

Cách làm thứ hai của Cherny đơn giản hơn nhiều, và ông phân biệt nó rất rõ ràng, chỉ trong một câu rất dễ đọc lướt qua mà bỏ sót ý:

"Với một luồng việc tự động, đó là MỘT việc, và mình chia nhỏ nó ra. Còn với vòng lặp và lịch chạy định kỳ, đó là một việc LẶP ĐI LẶP LẠI, không chia sẻ vùng nhớ tạm giữa các lần, nhưng có thể chia sẻ với nhau một dạng 'trí nhớ' khác."

Vòng lặp chạy ngay trên máy đang dùng. Gõ đại loại "/loop 15m kiểm tra xem đã triển khai xong chưa" sẽ khiến hệ thống cứ 15 phút lại tự động lặp lại yêu cầu đó một lần; khoảng cách ngắn nhất giữa hai lần là một phút. Nếu không nói rõ khoảng cách thời gian, Claude sẽ tự chọn — từ một phút tới một tiếng — tùy theo những gì nó thấy được sau mỗi lần chạy. Vòng lặp chỉ tồn tại trong khuôn khổ một phiên làm việc: cần giữ cửa sổ trò chuyện đang mở, và tự hết hạn sau bảy ngày. Có thể thay lời nhắc mặc định bằng lời nhắc riêng của mình, lưu trong một file cấu hình.

Lịch chạy định kỳ thì chạy trên máy chủ ở "trên mây" — tắt máy tính cá nhân đi vẫn chạy bình thường. Đây là một lời nhắc đã lưu sẵn, cộng với các kho mã nguồn liên quan và các kết nối cần thiết, được kích hoạt bởi một trong ba cách: theo lịch giờ (ngắn nhất là một tiếng một lần), qua một cuộc gọi tới một địa chỉ mạng riêng kèm mã xác thực, hoặc khi có một sự kiện xảy ra trên GitHub (nơi lưu trữ mã nguồn), chẳng hạn như có người vừa gửi một yêu cầu ghép mã mới. Nó chạy như một phiên làm việc hoàn toàn tự động trên máy chủ, không cần ai xác nhận từng bước, tự tải bản mới nhất của kho mã nguồn về mỗi lần chạy, rồi đẩy kết quả lên một nhánh riêng. Cherny nói Anthropic hiện đang cho chạy "chắc khoảng 20, 30 cái lịch chạy định kỳ" như vậy mỗi ngày trên chính kho mã nguồn của họ, làm những việc mà "trước đây phải cần tới hàng chục, hàng trăm kỹ sư."

Còn một loại thứ ba nữa mà ông không nhắc tới: tác vụ định giờ ngay trên máy tính cá nhân (Desktop scheduled task) — chạy ngay tại máy, giống vòng lặp, nhưng không cần giữ cửa sổ trò chuyện mở, và — khác với lịch chạy định kỳ trên mây — nó nhìn thấy được các file ngay trên ổ đĩa của mình. Với ai có tài liệu nằm trên ổ cứng cá nhân chứ không phải trong một kho mã nguồn trên mạng, đây mới là loại quan trọng nhất.

Câu đáng dừng lại suy ngẫm nhất

"Không chia sẻ vùng nhớ tạm, nhưng có thể chia sẻ một dạng trí nhớ khác." Chỉ chín chữ đó thôi đã tóm gọn toàn bộ cách thiết kế của vòng lặp và lịch chạy định kỳ — và nó ngược hẳn với cách mọi người thường tưởng tượng về một "AI chạy lặp đi lặp lại."

Mỗi lần chạy đều bắt đầu với một vùng nhớ tạm hoàn toàn mới, trống trơn. Lần chạy thứ 40 không hề nhớ gì về 39 lần chạy trước đó. Nó không thể nhớ — và chính vì vậy cách làm này mới mở rộng được quy mô tốt: không có gì tích tụ lại, không có gì bị loãng dần, không có gì lệch hướng dần.

Vậy nên, sự "liên tục" giữa các lần chạy phải nằm ở bên ngoài cuộc trò chuyện — nằm trong những thứ ghi lại trên ổ đĩa: một bảng theo dõi tiến độ trong một file kế hoạch, một file ghi chú quy tắc dự án, một thư mục lưu trí nhớ, một nhánh trong kho mã nguồn, một hệ thống theo dõi việc cần làm, hay đơn giản là việc một file kết quả đã tồn tại hay chưa. Đó chính là "trí nhớ" mà câu nói ở trên nhắc tới. Mỗi lần chạy: đọc lại "thế giới" hiện tại (đọc file), làm thêm được một chút việc, ghi kết quả trở lại "thế giới" đó (ghi lại file), rồi kết thúc — như chưa từng tồn tại.

Nếu nghe quen quen, thì đúng vậy — đây chính xác là cách làm việc vốn đã có sẵn từ trước trong quy tắc riêng của kho dữ liệu này: quy tắc rằng một đợt trích xuất phải "chỉ tiếp tục dựa trên những gì đã ghi lại trên ổ đĩa (bảng tiến độ + file trang vừa ghi gần nhất), không bao giờ dựa vào trí nhớ của cuộc trò chuyện"; quy tắc chỉ cần gõ một chữ "next" (tiếp) để tự động biết làm gì tiếp theo, vẫn hoạt động được ngay cả sau khi xóa sạch lịch sử trò chuyện, vì file điều hướng luôn được đọc lại từ đầu mỗi phiên; hay việc cố tình xóa sạch lịch sử trò chuyện giữa các đợt làm việc trong một số dự án khác. Những quy tắc đó vốn được nghĩ ra bằng tay, chỉ để tiết kiệm tài nguyên — nhưng xét kỹ, chúng chính xác là cùng một cách thiết kế với "vòng lặp và lịch chạy định kỳ" nói trên. Cơ chế mà Cherny mô tả chỉ đơn giản là tự động hóa luôn cái phần mà hiện giờ vẫn đang phải tự gõ chữ kích hoạt bằng tay.

Sợi chỉ xuyên suốt

Đặt hai cách làm cạnh nhau, việc chọn cái nào cho từng việc trở nên rất rõ ràng:

	Luồng việc tự động	Vòng lặp / lịch chạy định kỳ
Hình dạng công việc	Một việc lớn, chia thành nhiều phần nhỏ	Một việc lặp đi lặp lại, kích hoạt lại nhiều lần
Sự liên tục	Biến số trong đoạn chương trình, chỉ trong một lần chạy	File ghi trên ổ đĩa, giữa các lần chạy khác nhau
Thời gian sống	Vài phút tới vài tiếng, cho một lần chạy	Không giới hạn, chạy nhiều lần
Lỗi mà nó sửa được	Vùng nhớ tạm bị đầy/loãng, kết quả chưa được kiểm tra	Con người quên, không có ai theo dõi sát sao
Kiểu chi phí	Tốn nhiều một lần, dồn dập	Tốn ít, rải đều theo thời gian

Và điều quan trọng nhất nằm bên dưới cả hai cách làm là: đơn vị đáng để đầu tư công sức bây giờ không còn là câu mình gõ vào, mà là cả cái "khung" xung quanh nó. Trước đây, "nghệ thuật đặt câu hỏi cho AI" chỉ lo tối ưu một câu nói, gửi cho một hệ thống, trong một vùng nhớ tạm duy nhất. Còn điều Cherny đang mô tả là tối ưu cách sắp xếp: có bao nhiêu vùng nhớ tạm, sắp xếp ra sao, kiểm tra chéo nhau thế nào, cái gì được giữ lại ở đâu. Bây giờ chính AI mới là bên viết ra câu hỏi. Phần mình cần chọn là hình dạng, cách sắp xếp của cả bộ máy.

Nguồn: Boris Cherny trò chuyện cùng Diana Hu, tại sự kiện Startup School của Y Combinator, ngày 27-7-2026; bài viết "Mỗi việc một cái khung riêng" của Anthropic; tài liệu hướng dẫn của Claude Code về luồng việc tự động, lịch chạy định kỳ, và tác vụ định giờ; bài viết của chính đội ngũ Bun về dự án viết lại bằng Rust, và bài đưa tin của The Register về những lời phê bình dự án đó nhận được.

Bảng giải thích thuật ngữ (Glossary)

Bảng dưới đây giải thích bằng tiếng Việt đơn giản những khái niệm ngành máy tính/AI xuất hiện trong bài, để đọc không cần tra cứu thêm ở đâu khác.

Thuật ngữ gốc	Giải thích bằng lời dễ hiểu
AI / trợ lý AI	Một chương trình máy tính biết "hiểu" và trả lời bằng ngôn ngữ tự nhiên (như ChatGPT, Claude), có thể được giao việc và tự tìm cách hoàn thành.
Khung điều phối (harness)	Cái "sườn" bao quanh một trợ lý AI: quy định nó được dùng công cụ gì, ai quyết định bước tiếp theo, khi nào coi là xong việc. Claude Code là một ví dụ.
Vùng nhớ tạm / bộ nhớ ngắn hạn (context window)	Toàn bộ những gì một trợ lý AI "nhìn thấy" và "nhớ" được trong một cuộc trò chuyện — càng nhồi nhiều thứ vào, phần quan trọng càng dễ bị lấn át hay quên bớt, giống như một cái bàn làm việc chật cứng giấy tờ.
Trợ lý phụ / trợ lý con (subagent)	Một "bản sao" của trợ lý AI được giao một việc nhỏ, hẹp, riêng biệt, với vùng nhớ tạm hoàn toàn mới, không dính gì tới cuộc trò chuyện chính.
Người điều phối (orchestrator)	Bên đứng ra chia việc, giao việc cho các trợ lý phụ, rồi gom kết quả lại — có thể là chính người dùng, chính AI, hoặc một đoạn chương trình tự động.
Luồng việc tự động (dynamic workflow)	Một đoạn chương trình máy tính do AI tự viết ra, có nhiệm vụ tự động gọi và sắp xếp nhiều trợ lý phụ làm việc theo đúng trình tự đã định, chạy nền, không cần con người ngồi canh từng bước.
Đoạn chương trình / mã nguồn / JavaScript	Một tập hợp câu lệnh viết theo cú pháp máy tính hiểu được, để ra lệnh cho máy làm việc gì đó theo đúng trình tự. JavaScript là tên một trong những ngôn ngữ hay dùng để viết những đoạn lệnh như vậy.
Vùng cách ly an toàn / "hộp cát" (sandbox)	Một khu vực chạy chương trình bị cố tình giới hạn quyền — chương trình chạy trong đó không thể đụng trực tiếp vào file hay hệ thống thật của máy tính, để tránh gây hại ngoài ý muốn.
Bun	Tên một hệ thống chạy chương trình JavaScript, được Claude Code dùng làm "vùng cách ly an toàn" nói trên.
Chia nhánh song song (fan-out)	Cách chia một công việc lớn thành nhiều phần nhỏ, giao cho nhiều trợ lý làm cùng lúc thay vì làm lần lượt từng phần một.
Dây chuyền xử lý (pipeline)	Cách cho một danh sách các việc chạy qua cùng một bước xử lý, mỗi việc một lượt, tương tự dây chuyền sản xuất.
Kiểm tra chéo kiểu phản biện (adversarial verification)	Dùng một nhóm trợ lý khác, độc lập với nhóm đã làm ra kết quả, để cố tình "bắt lỗi" kết quả đó trước khi tin dùng — giống như có người phản biện trong một buổi bảo vệ luận văn.
Đấu loại từng cặp (tournament)	Cách xếp hạng một danh sách dài bằng cách so sánh từng cặp một, ai hơn đi tiếp, thay vì nhờ sắp xếp cả danh sách cùng lúc.
Đơn vị chữ (token)	Đơn vị mà một hệ thống AI dùng để đo và tính phí lượng chữ nó đọc vào hoặc viết ra — gần giống đếm theo từ hoặc theo âm tiết, tuy không hoàn toàn giống nhau.
Sức tính lúc trả lời (test-time compute)	Lượng phép tính mà một hệ thống AI bỏ ra ngay lúc đang trả lời một câu hỏi cụ thể, khác với lượng phép tính đã bỏ ra từ trước, lúc "dạy" cho nó học.
Vòng lặp (loop)	Một lệnh được lặp lại nhiều lần theo một khoảng thời gian nhất định, chạy ngay trong phiên làm việc đang mở, mỗi lần lặp lại đều bắt đầu từ vùng nhớ tạm trống trơn.
Lịch chạy định kỳ (routine)	Giống vòng lặp về nguyên tắc "mỗi lần chạy lại từ đầu," nhưng chạy trên máy chủ ở xa (không cần mở máy tính cá nhân), được kích hoạt theo lịch giờ, theo yêu cầu qua mạng, hoặc theo một sự kiện xảy ra ở nơi khác.
Tác vụ định giờ trên máy (Desktop scheduled task)	Giống lịch chạy định kỳ về việc không cần mở phiên trò chuyện, nhưng chạy ngay trên máy tính cá nhân nên vẫn nhìn thấy được các file lưu cục bộ trên ổ đĩa, khác với lịch chạy định kỳ trên mây vốn chỉ thấy được kho mã nguồn trực tuyến.
"Trí nhớ" ngoài cuộc trò chuyện	Thông tin không được giữ trong vùng nhớ tạm của cuộc trò chuyện, mà được ghi lại thành file trên ổ đĩa (bảng tiến độ, ghi chú, file kết quả…), để lần chạy sau đọc lại và biết mình đang ở đâu.
Git / kho mã nguồn	Một hệ thống lưu trữ và theo dõi lịch sử thay đổi của các file (thường là code), cho phép nhiều người/nhiều tiến trình cùng chỉnh sửa mà không đè lên nhau.
Nhánh (branch) / lần lưu thay đổi (commit)	Một "nhánh" là một phiên bản riêng của kho mã nguồn để thử nghiệm mà không ảnh hưởng bản chính; mỗi "lần lưu thay đổi" là một mốc ghi lại đúng những gì vừa sửa.
Bản sao làm việc riêng (worktree)	Một bản sao khác của cùng kho mã nguồn, đặt ở một chỗ khác trên máy, để có thể làm nhiều việc song song trên cùng dự án mà không giẫm chân nhau.
API	Một "cửa" chuẩn hóa để một chương trình gọi và lấy kết quả từ một chương trình/dịch vụ khác qua mạng, thay vì phải qua giao diện dành cho con người.
JSON	Một định dạng ghi dữ liệu có cấu trúc rõ ràng (kiểu như một danh sách các cặp "tên trường: giá trị"), dùng để hai chương trình khác nhau trao đổi thông tin qua lại một cách nhất quán.
GitHub / sự kiện GitHub	GitHub là một trang web phổ biến để lưu trữ và cộng tác trên kho mã nguồn; một "sự kiện" trên đó là một hành động cụ thể xảy ra ở nơi này (ví dụ: có người vừa gửi một đề xuất sửa code mới), có thể dùng để tự động kích hoạt việc khác.