AI Digest — 03/09/2026

Hôm nay trong 30 giây

Quan trọng nhất — quyền dùng model mạnh nhất không còn mua được bằng tiền: trong 48 giờ, Anthropic ra Mythos 5.1 (cùng model với Fable 5.1, chỉ khác mức rào chắn, mở cho người đã được thẩm định), Google ra Gemini 3.8 Flash Cyber chỉ phát qua chương trình Fairwind (650+ đối tác), và OpenAI tuyên bố Astra là model đầu tiên vượt ngưỡng "Critical" về năng lực tấn công mạng. Ba lab độc lập cùng chọn một mô hình phân phối: xác minh danh tính thay cho bảng giá.
Giá cache đọc giảm 75% (Anthropic): input vẫn $10/triệu token, output $50/triệu, nhưng cache read còn $0,25/triệu. Với việc agentic đọc đi đọc lại cùng một context, hãng ước tính giảm ~25% chi phí thực tế, tới 45% cho tác vụ agentic nặng.
Trọng tài của bạn đang đụng trần (AgentJudgeBench): 6 LLM judge chấm chuỗi gọi tool theo DAG. Ở mức khó, cả sáu hội tụ về 77–82% — model frontier chỉ hơn model nhỏ khoảng 2 điểm. Đáng lo hơn: đưa thêm đáp án đúng vào lại làm GPT-5.4 tệ đi 1,5 điểm.
Agent code liên tục nhiều ngày thì tốt lên thật (Harness-of-Harness): vòng lặp 3 vai plan–code–QA chạy 70 vòng dựng được một game FPS chơi được. GameCraft-Bench: Codex 49,58 → 71,52. Và 2 vòng HoH rẻ hơn 3 lần chạy thẳng mà điểm cao hơn.
Cho agent điều hành cửa hàng suốt một năm (E-Commerce Bench): 18 model, mỗi model 365 ngày mô phỏng, vốn 100.000₫. Khoảng cách giữa giỏi nhất và tệ nhất là 1.264 lần — GPT-5.6 kết năm 1,43 tỷ, một model khác phá sản 4/5 lần chạy.
Tách "lệnh" khỏi "nội dung" trong prompt (Control-Data Flow Separation): khi tối ưu prompt đa-agent, một chỉnh sửa nhằm cải thiện nội dung có thể phá vỡ giao thức định tuyến và làm sập cả pipeline. Tách hai kênh ra: 100% giao thức hợp lệ, trong khi TextGrad ngây thơ có lúc 0%.

🔥 Mạch chính: năng lực frontier vừa đổi đơn vị đo — từ giá sang danh tính

Ba chuyện tưởng rời rạc, xảy ra trong cùng 48 giờ, thực ra là một chuyện.

01/09	OpenAI nói Astra là model đầu tiên của hãng vượt ngưỡng "Critical" về năng lực mạng: tự tìm lỗ hổng chưa ai biết và khai thác, không cần người hướng dẫn từng bước. Sẽ phát hành nhưng giới hạn riêng phần năng lực mạng.
02/09	Anthropic ra Fable 5.1 (mở chung) và Mythos 5.1 — cùng một model, khác duy nhất ở mức rào chắn, chỉ mở cho người được thẩm định qua CVP (an ninh mạng phòng thủ) và LSVP (khoa học sự sống, làm cùng chính phủ Mỹ, hiện chỉ tổ chức tại Mỹ).
02/09	Google ra Gemini 3.8 Flash Cyber, phát chỉ qua chương trình Fairwind: cơ quan nhà nước, hạ tầng trọng yếu, và người bảo trì phần mềm lõi. 650+ đối tác, trong đó có CrowdStrike, Palo Alto Networks, Wiz.

Vì sao đây là bước ngoặt. Từ trước tới nay, thứ quyết định bạn dùng được model nào là số tiền bạn trả. Ba thông báo trên thay bằng một thứ khác: bạn là ai, và ai bảo lãnh cho bạn. Anthropic nói thẳng ra điều này bằng cách phát hành hai cái tên cho cùng một mạng nơ-ron — Fable 5.1 và Mythos 5.1 khác nhau không phải ở trọng số, mà ở việc bạn đã qua thẩm định hay chưa. Đó là lần đầu ranh giới sản phẩm được vẽ hoàn toàn bằng quy trình cấp phép thay vì bằng năng lực model.

Chỗ tinh tế: rào chắn không phải bật/tắt, mà được cắt theo lát. Fable 5.1 được phép chỉ ra lỗ hổng phần mềm nhưng không được viết mã khai thác. Câu hỏi sinh học bị chuyển hướng sang dòng Opus. Google thì thiết kế Flash Cyber ưu tiên vá lỗi hơn khai thác lỗi — 47,2% pass@1 trên CWE-Bench (vá) là con số họ chọn để khoe, không phải điểm khai thác.

Một con số đáng chú ý mà ít ai để ý: Anthropic nói rào chắn an ninh mạng mới giảm ~60% báo động giả. Đây là thừa nhận gián tiếp rằng phiên bản trước chặn nhầm rất nhiều việc chính đáng — vấn đề thực tế lớn nhất của rào chắn không phải là nó chặn kẻ xấu, mà là nó cản người dùng bình thường.

Ý nghĩa cho bạn: nếu công việc của bạn có phần bảo mật (đọc code tìm lỗ hổng, viết PoC, phân tích malware), hãy chuẩn bị tinh thần rằng tài khoản trả tiền là chưa đủ — sẽ cần đăng ký chương trình xác minh. Và nếu bạn xây sản phẩm trên API, đây là rủi ro kiến trúc mới cần ghi vào tài liệu: một tính năng có thể biến mất không phải vì hết tiền, mà vì bạn không nằm trong danh sách.

📄 Papers đáng đọc nhất

Từ 27 paper HF Daily Papers trong cửa sổ 02–03/09; con số cạnh tiêu đề là upvote. Mỗi paper 3 lớp: BLUF → 30 giây → Đọc sâu (bấm mở).

▲ 16

PaperEvalsAgentJudgeBench: chấm điểm người chấm điểm, trên chuỗi gọi tool

BLUF: Ai cũng dùng LLM làm trọng tài để chấm agent gọi tool, nhưng chưa ai kiểm tra trọng tài đó có đáng tin không. Đo 6 judge trên 3.808 tình huống DAG: ở mức khó, cả sáu cùng đụng trần 77–82%, và judge frontier chỉ hơn judge nhỏ khoảng 2 điểm — nghĩa là tiền mua model to không mua được độ tin cậy của trọng tài.

30 giây

Vấn đề: chấm một đoạn văn hay/dở là chuyện chủ quan, LLM judge làm tạm được. Nhưng chấm một chuỗi gọi tool có phụ thuộc (gọi A xong mới có tham số cho B) là chuyện có đáp án đúng — và chưa ai đo xem judge có bắt được sai ở đâu không.
Cách đo: sinh 3.808 bản ghi kiểu BFCL qua 15 lĩnh vực doanh nghiệp, mỗi bản 8–19 tool, viết lại theo 3 mức khó và 6 dạng đồ thị (nối tiếp, rẽ nhánh, hội tụ, kim cương, làm giàu tuỳ chọn, vòng lặp). 5 model sinh × 6 judge × có/không có đáp án = 321.648 lượt chấm.
Kết quả then chốt: dễ 85–92%, trung bình 80–92%, khó 77–82% và tất cả judge hội tụ về đó. Không có judge nào thoát khỏi trần.
Nghịch lý: đưa thêm đáp án đúng cho judge tham khảo lại làm GPT-5.4 giảm 1,5 điểm và Gemini-2.5-Pro giảm 3,9 điểm — chúng bám vào đáp án thay vì thật sự đọc lời giải.
Cần lệch gì để cải thiện: chain-of-thought gần như vô dụng (+0,1–0,3 điểm), nhiệt độ cũng không đổi gì (≤0,6 điểm). Thứ duy nhất có tác dụng đáng kể là prompt có cấu trúc: +4,8 đến +6,5 điểm.

Sơ đồ pipeline AgentJudgeBench — Pipeline AgentJudgeBench: mỗi bản ghi được viết lại theo độ khó, cho model sinh lời giải, rồi chấm song song bằng judge lập trình và judge LLM (có/không đáp án).

Đọc sâu (~3 phút)

Bối cảnh: vì sao "LLM làm trọng tài" lại là điểm yếu ẩn

Khi bạn xây một agent gọi tool, bạn không thể ngồi chấm tay hàng nghìn quỹ đạo. Cách phổ biến là nhờ một LLM mạnh chấm hộ. Vấn đề: toàn bộ vòng lặp cải tiến của bạn nằm trên vai trọng tài đó. Nếu trọng tài sai có hệ thống, bạn sẽ tối ưu agent theo hướng sai mà biểu đồ vẫn đi lên đẹp đẽ.

Điểm mới của bài này là tách bạch hai việc mà cộng đồng hay gộp làm một. Chấm văn bản mở (bài viết nào hay hơn) là bài toán sở thích, không có chuẩn vàng. Chấm chuỗi gọi tool theo DAG thì có chuẩn vàng: gọi đúng tool nào, tham số đúng chưa, thứ tự đúng chưa. Vậy nên ở đây ta đo được trọng tài sai bao nhiêu — điều không làm được ở bài toán kia.

Cách làm, từng bước

(1) Sinh dữ liệu có chuẩn vàng: tạo bản ghi kiểu BFCL trên 15 lĩnh vực, mỗi bản có 8–19 tool khả dụng, và một quỹ đạo đúng đã biết. (2) Điều khiển độ khó: viết lại đề theo ba mức dễ/vừa/khó nhưng giữ nguyên quỹ đạo đúng — nên khi judge sai, ta biết chắc lỗi ở judge chứ không ở đề. (3) Đa dạng cấu trúc: sáu dạng DAG để không bị kết luận chỉ đúng cho chuỗi tuyến tính. (4) Hai loại trọng tài chạy song song: một trọng tài lập trình xác định (chấm bằng luật: chọn đúng tool, cấu trúc tham số theo thang 0/0,5/1, khớp vị trí, độ phủ) làm mốc, và sáu LLM judge từ 20B tới frontier. (5) Hai điều kiện: judge có đáp án đúng trong tay, và judge không có.

Quy mô	3.808 tình huống · 15 lĩnh vực · 6 dạng DAG · 321.648 lượt chấm
Mức dễ	85–92% khớp với trọng tài lập trình
Mức khó	77–82% — trần chung của cả 6 judge
Có đáp án đúng	GPT-5.4 −1,5 điểm · Gemini-2.5-Pro −3,9 điểm (bám đáp án)
Chain-of-thought	+0,1 đến +0,3 điểm (gần như không tác dụng)
Prompt có cấu trúc	+4,8 đến +6,5 điểm (đòn bẩy lớn nhất)
Đồng thuận giữa judge	có đáp án 79,1% (κ≈0,42) · không đáp án 92,6% (κ≈0,56)

Con số cuối cùng trong bảng là chỗ dễ đọc nhầm nhất, nên nói rõ: các judge đồng thuận với nhau nhiều hơn khi không có đáp án (92,6% so với 79,1%). Nghe như tin tốt, nhưng tác giả gọi đó là đồng thuận bị thổi phồng do prompt ép nén câu trả lời — chúng cùng đoán giống nhau, chứ không phải cùng đúng. Đây là lời cảnh báo trực tiếp cho ai đang dùng "nhiều judge bỏ phiếu" như một biện pháp an toàn.

Hạn chế — tác giả nói thẳng

Bản thân trọng tài lập trình chỉ khớp 82,5% với người thật ở phần cấu trúc tham số: nó phạt các khoá thừa mà vẫn hợp schema, trong khi người chấm chấp nhận (99 trong 212 ca bất đồng là do tool dư thừa). Nghĩa là cái thước dùng làm mốc cũng có sai số. Dữ liệu là sinh tổng hợp, không lấy từ log doanh nghiệp thật, nên độ lệch so với thực tế chưa được kiểm chứng. Mức "trung bình" chỉ được xác nhận nhất trí trên 58,1% bản ghi, nên tác giả khuyên coi nó là phép thử độ bền chứ đừng coi là một bậc đã hiệu chuẩn. Và một điểm khó chịu về khoa học: GPT-5.4 vừa là model sinh, vừa là judge, vừa là trọng tài phán xử việc viết lại đề — trên một snapshot Azure không tái lập được.

Ý nghĩa cho bạn: ba việc làm được ngay. (1) Nếu bạn đang chấm agent bằng LLM judge, hãy viết một trọng tài lập trình cho phần có chuẩn vàng (tên tool, tham số, thứ tự) — nó rẻ hơn, ổn định hơn, và bài này cho thấy judge LLM không hơn được nó ở mức khó. (2) Bỏ chain-of-thought khỏi prompt trọng tài để tiết kiệm token, thay bằng prompt có cấu trúc (khung đầu ra rõ ràng từng trường) — đó là đòn bẩy duy nhất được đo là có tác dụng. (3) Đừng đưa đáp án đúng cho judge như một cách "giúp" nó: với hai model mạnh nhất trong bài, việc đó làm điểm tệ đi.

🔬 Yêu cầu deep-dive paper này

▲ 10

PaperAgenticHarness-of-Harness: để agent code liên tục nhiều ngày và thật sự khá lên

BLUF: Thay vì hỏi "một lần chạy agent làm được gì", bài này hỏi "70 lần chạy nối nhau làm được gì" — và câu trả lời là một game bắn súng góc nhìn thứ nhất chơi được. Điểm đáng giá nhất không phải con số benchmark (Codex 49,58 → 71,52), mà là: 2 vòng HoH tốn ít token hơn 3 lần chạy thẳng mà điểm cao hơn (64,84 so với 58,24; 5,67M so với 6,33M token).

30 giây

Ý tưởng: HoH là "harness của harness" — nó không thay thế Codex hay agent bạn đang dùng, mà bọc bên ngoài, tổ chức các lần chạy thành vòng lặp lập kế hoạch → viết code → QA.
Ba vai tách bạch: Project Planner đọc bằng chứng từ các vòng trước rồi ra một mục tiêu có giới hạn; Developer làm tiếp từ artifact cũ (không làm lại từ đầu); QA Tester chấm độc lập bằng test hộp đen và hộp trắng, và đóng băng bản ứng viên để không ai sửa giữa lúc đang chấm.
Chìa khoá chống trôi: mỗi vòng chỉ được làm một gia tăng nhỏ, kiểm chứng được, và phải giữ nguyên hành vi đã được xác nhận. Đây là cách họ cân bằng giữa "sửa lỗi cũ" và "thêm năng lực mới" — hai thứ mà agent chạy dài thường đánh đổi sai.
Số liệu: GameCraft-Bench (45 task) Codex 49,58 → 71,52, DeepSeek 26,90 → 48,98, MiniMax 42,16 → 58,78. FrontierSWE: reward 0,31 → 0,54, kéo dài tới 10 vòng thì đạt 72,67% tỷ lệ áp đảo. Mức tăng tương đối trung bình 52,25%, cao nhất 82,86%.
Bằng chứng nhiều ngày: case "Fusepoint" chạy 70 vòng, ra một FPS có cốt truyện, hệ thống chiến đấu, vũ khí, HUD, menu, hoạt cảnh, âm thanh — người chơi được.

Quỹ đạo phát triển game Fusepoint qua các vòng lặp HoH — Case Fusepoint: sản phẩm qua các vòng lặp kế tiếp của Harness-of-Harness, từ khung sơ khai tới một FPS chơi được.

Đọc sâu (~3 phút)

Bối cảnh: vì sao agent code giỏi một lần nhưng dở khi chạy dài

Các benchmark quen thuộc (SWE-bench và họ hàng) đo một lần chạy trên một task đã đóng khung: đây là repo, đây là issue, sửa đi. Phần mềm thật không như vậy — nó là hàng trăm quyết định nối nhau qua nhiều ngày, trong đó quyết định hôm nay phải sống chung với code hôm qua. Khi người ta thử cho agent chạy dài, hai lỗi lặp lại: nó làm lại việc đã làm (vì không nhớ vòng trước đã thử gì), và nó phá thứ đang chạy được khi thêm tính năng mới.

HoH tấn công đúng hai lỗi đó, và tấn công bằng cấu trúc quy trình chứ không bằng model mạnh hơn. Đó là lý do nó cộng dồn được lên bất kỳ harness nào bạn đang có.

Cách làm, từng bước

(1) Planner đọc bằng chứng thực thi của các vòng trước — không phải đọc tóm tắt tự thuật của agent, mà đọc kết quả chạy thật: test nào trượt, lỗi gì. Đây là điều chặn việc lặp lại công cũ. (2) Planner viết một tài liệu phát triển nêu phạm vi và tiêu chí nghiệm thu, nhưng cố tình không quy định cách làm — giữ quyền tự chủ cho Developer, vốn là chỗ agent mạnh. (3) Developer khởi động ấm từ artifact vòng trước, viết code kèm test luôn. (4) QA Tester chấm độc lập theo tiêu chí riêng của kịch bản, cả hộp đen (hành vi) lẫn hộp trắng (nội tại), và đóng băng bản ứng viên trong lúc chấm — chi tiết nhỏ nhưng quan trọng, vì nó ngăn cái bẫy "agent sửa code trong lúc đang bị chấm nên điểm không còn nghĩa gì".

GameCraft-Bench (45 task)	Codex 49,58 → 71,52 · DeepSeek 26,90 → 48,98 · MiniMax 42,16 → 58,78
FrontierSWE (15 task)	reward 0,31 → 0,54 · 10 vòng đạt 72,67%
ProgramBench	tỷ lệ pass test +6,09 đến +16,85 điểm
Hiệu quả token	HoH@2: 64,84 điểm / 5,67M token · 3 lần chạy thẳng: 58,24 / 6,33M
Case nhiều ngày	70 vòng → FPS chơi được
Mức tăng tương đối	trung bình 52,25% · cao nhất 82,86%

Dòng "hiệu quả token" là dòng đáng nhớ nhất, và nên đọc chậm. Cách so sánh công bằng với một vòng lặp cải tiến không phải là "một lần chạy", mà là "cùng ngần ấy token, chia thành nhiều lần chạy độc lập rồi lấy cái tốt nhất". HoH thắng ở cả hai đầu: điểm cao hơn mà token ít hơn. Nghĩa là lợi ích không đến từ việc tiêu nhiều tính toán hơn, mà đến từ việc vòng sau biết vòng trước đã làm gì.

Hạn chế — và chỗ bài này im lặng

Bài không có mục hạn chế riêng, đó là điểm trừ. Đọc kỹ thì thấy: chỉ thử ba cấu hình harness–model; giới hạn tính toán khiến FrontierSWE chỉ chạy 15 trên 17 task; và case Fusepoint dùng công cụ và kỹ năng chuyên biệt cho làm game nằm ngoài framework gốc — nên chưa rõ 70 vòng có tổng quát sang lĩnh vực khác không. Con số "72,67% dominance" cũng cần đọc cẩn thận: đó là tỷ lệ áp đảo so với baseline, không phải tỷ lệ giải đúng.

Ý nghĩa cho bạn: đây là paper dễ áp dụng nhất hôm nay vì không đòi bạn đổi model hay đổi agent. Ba thứ bê nguyên được: (1) tách vai người chấm khỏi người viết, và đóng băng bản đang chấm — chỉ riêng việc này đã loại được một lớp kết quả giả; (2) bắt mỗi vòng ra một gia tăng nhỏ có test thay vì một PR to; (3) quan trọng nhất, đưa kết quả chạy thật của vòng trước vào ngữ cảnh lập kế hoạch vòng sau — đừng để agent tự kể lại nó đã làm gì. Nếu bạn đang chạy agent nhiều lần rồi chọn bản tốt nhất, bài này nói thẳng: nối chúng lại còn rẻ hơn.

🔬 Yêu cầu deep-dive paper này

▲ 6

PaperAgenticEvalsE-Commerce Bench: cho 18 model điều hành cửa hàng suốt 365 ngày

BLUF: Một benchmark long-horizon thật sự — mỗi model vận hành nhiều cửa hàng online trong một năm mô phỏng, tự nghiên cứu thị trường, mặc cả với nhà cung cấp, nhập hàng, định giá, xử lý trả hàng và quản dòng tiền. Khoảng cách kết quả là 1.264 lần giữa model giỏi nhất và tệ nhất, và 4 model phá sản. Đây là bài đo sự khác biệt mà các benchmark ngắn không nhìn thấy.

30 giây

Thiết kế: môi trường tất định dựa trên dữ liệu Taobao & Tmall, vốn khởi đầu 100.000₫, tối đa 4 cửa hàng chạy song song, ba tài khoản tiền (ngân hàng, ký quỹ, ví sàn) phải cân đối.
Mẹo hay nhất về phương pháp: phần mặc cả do một nhân lõi tất định quyết định (giá, nhượng bộ, đồng ý hay từ chối); LLM chỉ đóng vai người nói. Nhờ vậy kết quả tái lập được — thứ mà hầu hết benchmark đàm phán không làm được.
Cạm bẫy cài sẵn: 152 trong 576 nhà cung cấp (~26%) là lừa đảo, có kịch bản gạt riêng. Lịch năm có 10 sự kiện thị trường và 8 đợt khuyến mãi, báo trước nhưng giấu tham số — agent phải tự dò.
Kết quả: GPT-5.6 Sol 1.431k₫ (±314), Fable5 805k₫ (±188), Qwen3.8-Max 416k₫ (±111), Qwen3.5-Plus 1,1k₫ — phá sản 4/5 lần chạy. Tổng 18 model, 90 episode, 10 lần phá sản.
Đo 7 chiều, không chỉ tiền: chất lượng đàm phán, tránh lừa đảo (BadSpend%), khả năng thanh toán, hiệu quả vận hành (₫ trên mỗi lần gọi tool), chất lượng thực thi, và khả năng học.

Ảnh minh hoạ paper E-Commerce Bench — Trang paper trên Hugging Face — benchmark vận hành kinh doanh tự chủ dài 365 ngày.

Đọc sâu (~3 phút)

Bối cảnh: "long-horizon" thường bị hiểu nhầm

Rất nhiều benchmark tự nhận là long-horizon thực ra chỉ là nhiều task ngắn nối đuôi: mỗi bước độc lập, sai bước này không ảnh hưởng bước kia. Bài này định nghĩa lại cho đúng: long-horizon là khi môi trường thay đổi theo hành động của bạn và quyết định hôm nay ràng buộc hàng nghìn bước sau. Nhập quá nhiều hàng tháng Ba thì tháng Sáu hết tiền mặt — không có bước nào "sai" cả, nhưng bạn vẫn phá sản.

Đó là lý do phá sản là chỉ số đáng chú ý nhất trong bài, hơn cả điểm số. Có 4 model không chỉ làm kém — chúng chết. Một agent phá sản không phải agent điểm thấp; nó là agent mà bạn không thể triển khai được ở bất kỳ mức nào.

Cách làm, từng bước

(1) Tách tất định khỏi ngẫu nhiên: đây là đóng góp phương pháp quan trọng nhất. Nếu để LLM đóng vai nhà cung cấp và quyết định giá, thì mỗi lần chạy lại ra một thế giới khác và bạn không so sánh được model. Họ giao mọi quyết định cho một nhân lõi tất định, LLM chỉ sinh lời thoại. (2) Giấu tham số, không giấu sự kiện: agent biết sắp có đợt khuyến mãi nhưng không biết nó mạnh cỡ nào — buộc phải thăm dò thay vì tra bảng. (3) Cài lừa đảo vào 26% nhà cung cấp: đây là phép đo mà benchmark thường thiếu — không chỉ "agent có làm được việc không" mà "agent có bị lừa mất tiền không". (4) Chấm 7 chiều để tránh việc một model may mắn trúng một cú lớn rồi được coi là giỏi.

GPT-5.6 Sol	1.431k₫ ± 314 · 3.668 lần gọi tool · 0 phá sản
Fable5	805k₫ ± 188 · 1.469 lần gọi tool · 0 phá sản
Qwen3.8-Max	416k₫ ± 111 · 1.826 lần gọi tool · 0 phá sản
Qwen3.5-Plus	1,1k₫ ± 11 · 1.076 lần gọi tool · 4/5 phá sản
Quy mô	18 model (8 đóng, 10 mở) · 90 episode · 576 nhà cung cấp
Vốn ban đầu	100k₫ — mọi cột trên tính từ mốc này

Có một chi tiết dễ bỏ qua trong bảng: GPT-5.6 gọi tool 3.668 lần, gấp 2,5 lần Fable5 (1.469) để đạt gấp 1,8 lần tài sản. Nếu tính theo chiều "₫ trên mỗi lần gọi tool" mà nhóm tác giả đo, Fable5 hiệu quả hơn trên mỗi hành động. Đây chính là lý do bài này chấm 7 chiều: câu trả lời "model nào tốt nhất" đổi tuỳ theo bạn trả tiền cho kết quả hay cho số lần gọi.

Hạn chế — tác giả thừa nhận

Thẳng thắn nhất là câu "năm episode là mẫu nhỏ" — với độ lệch chuẩn ±314k trên trung bình 1.431k, thứ tự xếp hạng giữa các model gần nhau không đáng tin. Chỉ số AnchorRatio phải loại hai episode phá sản của GPT-5.5 vì không có đơn đặt lại. Chỉ số phát hiện lừa đảo chịu nhiễu kép: nhiễu do model chọn hành động, cộng nhiễu do LLM sinh lời thoại khác nhau mỗi lần. Và không có mốc người thật — nên ta biết model nào hơn model nào, nhưng không biết có model nào bằng một chủ shop bình thường hay chưa.

Ý nghĩa cho bạn: nếu bạn định giao cho agent một quy trình chạy dài và có tiêu tiền (mua sắm, vận hành, phân bổ tài nguyên), hãy lấy hai ý thiết kế từ bài này. (1) Đo tỷ lệ chết, không chỉ đo điểm trung bình: một agent có 20% khả năng đưa hệ thống vào trạng thái không cứu được thì điểm trung bình của nó vô nghĩa. (2) Tách phần tất định ra khỏi phần LLM khi làm môi trường thử: cho LLM đóng vai người nói, còn luật chơi để code quyết định — đó là cách duy nhất khiến hai lần chạy so sánh được với nhau. Và (3) hãy nhớ cài sẵn đối tác xấu vào môi trường thử của bạn: 26% nhà cung cấp lừa đảo là con số làm lộ ra sự khác biệt mà môi trường "toàn người tốt" giấu đi.

🔬 Yêu cầu deep-dive paper này

▲ 7

PaperAgenticControl-Data Flow Separation: tối ưu prompt mà không làm sập pipeline

BLUF: Trong hệ đa-agent, một prompt đang gánh hai vai trộn lẫn: sinh nội dung, và ra lệnh cho code (định tuyến tới agent nào, định dạng gì, khi nào dừng). Trình tối ưu prompt chỉnh vai một thì vô tình phá vai hai và cả pipeline sập. Tách hai kênh và khoá phần giao thức khỏi tay trình tối ưu: hợp lệ 100%, trong khi TextGrad ngây thơ có lúc 0%.

30 giây

Quan sát gốc: hai vai này có hình dạng khác nhau — giao thức thì có cấu trúc (tập giá trị đóng, kiểu xác định), nội dung thì tự do. Đã khác hình dạng thì không nên để chung một chỗ.
Kênh điều khiển: một object có kiểu (Python dataclass hoặc Pydantic, dùng Literal để đóng tập giá trị), do controller đọc, chứa đích định tuyến và tín hiệu kết thúc.
Kênh dữ liệu: văn bản tự do, do các agent khác và trình tối ưu đọc, chứa tóm tắt, phản biện, nội dung tác vụ.
Cơ chế chặn: phần khung schema nằm trong một ô prompt đóng băng mà trình tối ưu không được sửa. Lúc chạy, phản hồi được parse và kiểm tra theo schema; object điều khiển sai thì thử lại hoặc dùng phương án dự phòng — chỉ object đã hợp lệ mới tới được router.
Số liệu: BBH 78,3% (so với 74,3% của DSPy BootstrapFewShot); underwriting đã kiểm chứng thực tế 36,7% so với 31,7% (partner-fixed) và 23,3% (DSPy tốt nhất) — chênh lệch lớn nhất nằm ở bài toán thật, không phải benchmark học thuật.

Ảnh minh hoạ paper Control-Data Flow Separation — Trang paper trên Hugging Face — tách kênh điều khiển khỏi kênh dữ liệu trong tối ưu prompt đa-agent.

Đọc sâu (~3 phút)

Bối cảnh: một lỗi mà ai xây hệ đa-agent cũng từng dính

Giả sử bạn có pipeline ba agent, và prompt của agent giữa kết thúc bằng: "Sau khi phân tích xong, trả về NEXT: reviewer hoặc NEXT: done". Code của bạn đọc chuỗi NEXT: đó để biết đi tiếp đâu. Giờ bạn chạy một trình tối ưu prompt (DSPy, TextGrad, GEPA) để cải thiện chất lượng phân tích. Trình tối ưu thấy câu đó không giúp gì cho chất lượng phân tích, nên viết lại thành "Sau đó chuyển cho người review". Chất lượng phân tích tăng thật. Nhưng router không tìm thấy NEXT: nữa và toàn bộ pipeline dừng.

Đây không phải lỗi hiếm gặp — nó là hệ quả tất yếu của việc lấy ngôn ngữ tự nhiên làm giao thức giữa các thành phần phần mềm. Ngôn ngữ tự nhiên vốn được phép diễn đạt nhiều cách; giao thức thì không được phép.

Cách làm, từng bước

(1) Khai báo schema điều khiển bằng kiểu Python chuẩn: mỗi trường có kiểu, các lựa chọn định tuyến khai bằng Literal nên tập giá trị là đóng — không có "reviewer" viết hoa hay "review-er" lọt qua được. (2) Tự sinh phần khung prompt từ schema đó, và đặt nó vào một ô đóng băng. Đây là điểm mấu chốt: trình tối ưu có toàn quyền viết lại phần nội dung, nhưng không nhìn thấy và không sửa được phần khung. (3) Lúc chạy: parse phản hồi thành cặp (điều khiển, dữ liệu), validate phần điều khiển theo schema. Sai thì retry hoặc fallback. (4) Chỉ object đã hợp lệ mới được đưa vào router — định tuyến chỉ phụ thuộc tín hiệu đã kiểm chứng, không bao giờ phụ thuộc văn bản tự do.

BBH	78,3% vs 74,3% (DSPy BootstrapFewShot)
MARG review	Jaccard 44,4% vs 43,2% (DSPy MIPROv2)
Underwriting tổng hợp	50,0% vs 47,8% (TextGrad ngây thơ)
Underwriting thực tế	36,7% vs 31,7% (partner-fixed) vs 23,3% (DSPy tốt nhất)
Độ hợp lệ giao thức	Ta 100% · TextGrad ngây thơ 0% trên MARG, 56,7% trên underwriting thực tế
DSPy trên underwriting thực tế	schema hợp lệ 83,3% (so với 100%)

Hàng "độ hợp lệ giao thức" là hàng quan trọng nhất, và nó cho thấy vì sao bảng điểm tác vụ ở trên không phản ánh hết vấn đề. Khi TextGrad đạt 0% hợp lệ trên MARG, nghĩa là hệ thống không chạy được lần nào — nhưng loại chỉ số này thường không xuất hiện trong bài báo tối ưu prompt, vì người ta chỉ báo cáo các lần chạy thành công. Đóng góp thật của bài không phải là +4 điểm BBH, mà là biến một chế độ hỏng thầm lặng thành một bất biến được đảm bảo.

Hạn chế — tác giả nói rõ, và rất đúng

Câu quan trọng nhất trong phần hạn chế: ổn định không phải là đúng. Framework đảm bảo điều khiển sai không bao giờ tới được router, chứ không đảm bảo kết quả tác vụ đúng. Bạn có thể có một pipeline chạy hoàn hảo 100% và trả lời sai 100%. Ngoài ra, phần MARG chấm bằng LLM-as-judge nên thừa hưởng mọi hạn chế của cách chấm đó (xem lại paper AgentJudgeBench ở trên — hai bài này nói chuyện với nhau). Cuối cùng, họ giả định vai agent và schema điều khiển được khai báo trước, chưa thử với trường hợp tạo agent động hay schema thay đổi lúc chạy.

Ý nghĩa cho bạn: đây là bài có tỷ lệ "lợi ích trên công sức" cao nhất hôm nay, và bạn không cần chạy trình tối ưu prompt nào cũng dùng được. Nguyên tắc bê nguyên: đừng bao giờ để code của bạn parse quyết định định tuyến ra khỏi văn bản tự do do model sinh. Cho model trả về một object có kiểu với tập giá trị đóng, validate trước khi dùng, và có đường dự phòng khi validate trượt. Nếu bạn có chạy tối ưu prompt, thêm một bước nữa: đánh dấu phần khung giao thức là bất khả xâm phạm và kiểm tra bằng test rằng trình tối ưu không sửa được nó. Chi phí là một buổi chiều; thứ nó ngăn là loại lỗi chạy được trên máy bạn rồi chết lúc 3 giờ sáng.

🔬 Yêu cầu deep-dive paper này

5 paper liếc qua: SMELT (▲75 — luật scaling cho MoE looped transformer khi khớp chặt FLOP, tham số và KV cache; lặp lại nửa giữa số lớp hai lần, scale tới 54B) · From Production Traffic to Post-Training (▲31 — gộp lưu lượng của 200+ ứng dụng nội bộ về một model self-host, vá khoảng cách chất lượng theo lỗi thật trong production) · Safin-1 (▲19 — an toàn như thuộc tính nội tại của model qua memory routing, thay vì rào chắn bên ngoài) · DiagEvo (▲14 — self-play có định hướng: chẩn đoán điểm yếu suy luận rồi mới sinh câu hỏi vòng sau, chống hiện tượng chững lại) · Agents in the Large (▲8 — kiến trúc lấy tri giác làm trung tâm cho agent sống lâu, phục vụ liên tục thay vì giải task đóng khung).

📰 Tin đáng biết

Model & giá cả

Anthropic: Claude Fable 5.1 & Mythos 5.1 — cùng model, khác rào chắn. Terminal-Bench-Science 0.1 52,6% (Fable 5 cũ: 24,7%, tức hơn gấp đôi); Terminal-Bench 4.0 55,8% cho Fable 5.1 và 60,9% cho Mythos 5.1; Humanity's Last Exam 60,9% không tool, 65,0% có tool; OSWorld 2.0 41,7%. Giá: input $10/triệu, output $50/triệu, cache read $0,25/triệu (giảm 75%) → giảm ~25% chi phí thực tế, tới 45% cho agentic nặng. Rào chắn mới: chỉ ra được lỗ hổng nhưng không viết được exploit, câu hỏi sinh học chuyển sang dòng Opus, giảm ~60% báo động giả. Thêm chống chưng cất: tài khoản API mới không được sửa tay context cũ mà vẫn giữ transcript suy nghĩ — bịt một kỹ thuật trích xuất đã biết. (qua TLDR AI 02/09)
Google: Gemini 3.8 Flash & 3.8 Flash Cyber — Flash thường đạt 54,9% HLE-Verified và vượt nhiều model frontier lớn hơn trên DeepSWE v1.1, Vals Finance Agent V2, và benchmark agent pháp lý của Harvey. Giá $0,75/triệu input và $3,75/triệu output — nhưng đây là giá giới thiệu tới 31/12/2026, từ 01/01/2027 tăng gấp đôi lên $1,50 và $7,50. Bản Cyber: >70% thành công trên benchmark lỗ hổng nội bộ qua 20 ngôn ngữ lập trình, 47,2% pass@1 trên CWE-Bench (vá lỗi), và cải thiện rõ độ bền trước prompt injection theo Gray Swan.
OpenAI: Astra vượt ngưỡng "Critical" về năng lực mạng — model đầu tiên của hãng đạt mức này: tự tìm lỗ hổng chưa được biết tới và khai thác chúng mà không cần hướng dẫn từng bước. Sẽ phát hành nhưng hạn chế riêng phần năng lực mạng; chi tiết an toàn hứa công bố trong System Card lúc ra mắt. (qua TLDR AI 02/09)

An ninh mạng: phía phòng thủ

Google mở chương trình Fairwind (02/09) — kênh phân phối cho Flash Cyber, ghép model với CodeMender để tìm, xác minh và vá lỗ hổng ở quy mô agentic: thay vì nhiều tuần vá tay, hệ thống sinh bản vá sẵn sàng triển khai trong vài phút. Ba nhóm được ưu tiên: cơ quan an ninh mạng quốc gia, hạ tầng trọng yếu (y tế, viễn thông, năng lượng, tài chính), và nền tảng công nghệ lõi. 650+ đối tác gồm CrowdStrike, Palo Alto Networks, Snowflake, Wiz. Ràng buộc bắt buộc: tổ chức tham gia phải giới hạn quyền dùng trong đội bảo mật/ứng cứu/pentest nội bộ và bật xác thực đa yếu tố. Google.org cam kết hơn $100 triệu cho an ninh mạng, trong đó $36 triệu cho 35 "cyber clinic" hỗ trợ miễn phí 1.250+ bệnh viện, trường học và tiện ích công tại Mỹ.

Kỹ thuật đáng lấy về dùng

"Thuế context" của MCP — đo thật, 11 server — trọng lượng khai báo tool chênh nhau hơn 30 lần: Notion ~19.050 token, Firecrawl ~9.870, Supabase ~4.990, Playwright ~4.630, GitHub ~3.960, Filesystem ~3.240, Context7 ~1.215, Puppeteer ~610. Phát hiện thực dụng nhất: đo Claude Code 2.1.204 có và không gắn server filesystem cho ra ~25.300 token cả hai trường hợp — chênh lệch nhỏ hơn nhiễu giữa hai lần chạy nền. Nghĩa là schema chỉ được nạp khi tool được dùng, không nạp lúc mở phiên; chi phí dời từ lúc khởi động sang lúc gọi lần đầu. (qua TLDR 02/09)
Mercor × SkyRL: công thức RL cho agent tri thức ở quy mô 397B — post-train Qwen3.5-397B-A17B trên 1.928 task do chuyên gia soạn, APEX-Agents Pass@1 tăng 70% tương đối (16,11% → 27,29%). Hai bài học đắt giá: (1) đừng token hoá lại khi chuyển đầu ra của engine suy luận sang đầu vào của trainer — họ phải dùng endpoint /completions với đếm token nội bộ thay vì /chat/completions, nếu không train và inference lệch nhau; (2) sáu bản vá cho harness (sửa cài đặt tool MCP, thêm timeout, cho phép cài package Python, bọc ngân sách context êm) nâng baseline 5,9 điểm mà không cần train gì cả. Và câu kết luận thẳng thắn: "lựa chọn thuật toán ít quan trọng hơn dữ liệu" — knob tốt nhất trong năm knob chỉ cho +3,9 điểm, trong khi cả quá trình post-train dịch chuyển 10–12 điểm. (qua TLDR AI 02/09)
44% ARC-AGI-1 với 67 xu — huấn luyện một transformer nhỏ từ đầu trong 1,5 giờ trên một card 5090, vượt nhiều LLM lớn, ngang TRM/HRM, và đạt 7% trên ARC-2. Mục tiêu của tác giả là dò giới hạn hiệu quả mẫu khi chỉ dùng transformer và kỹ thuật deep learning hiện hành. (qua TLDR AI 02/09)
Perplexity: engine "Lily" cho suy luận on-device trên Apple silicon — tận dụng bộ nhớ hợp nhất và phần cứng chuyên dụng, vượt MLX-LM cả ở prefill lẫn decode. Kiến trúc Qwen3.6-35B-A3B (MoE thưa + lớp Gated DeltaNet) cho phép tinh chỉnh engine để chạy gọn trên một máy Mac. (qua TLDR AI 02/09)
Hugging Face: 207 kernel WebGPU — thư viện @huggingface/kernels tăng tốc suy luận chạy thẳng trong trình duyệt. (qua TLDR AI 02/09)
Apple ML: REFACTOR-VLA — học không giám sát ra một thư viện "chương trình vận động" có kiểu từ dữ liệu vision-language-action, tức là tự tìm ra các đơn vị hành động tái dùng được thay vì học thẳng từ pixel tới mô-men.

Hệ sinh thái & sản phẩm

World Labs: Atlas — world model cho trí tuệ không gian — pretrain từ đầu để xử lý natively cả text, ảnh, video và 3D, gộp mọi đầu vào vào một ngữ cảnh không gian chung rồi sinh tiếp phần kế theo. Làm được cả sinh thế giới, tái dựng, và mô phỏng; hiệu năng tăng theo compute huấn luyện. (qua TLDR AI 02/09)
Latent Space đọc kỹ Fable/Mythos 5.1 — nêu một đánh đổi mà thông cáo không nói: cache read rẻ hơn 75% nhưng model sinh nhiều hơn ~70% output token. Vì output là phần đắt nhất ($50/triệu), tiết kiệm thực tế phụ thuộc tỷ lệ đọc/ghi trong workload của bạn — đáng tự đo trước khi tin con số 25%.
Cognition huy động ~$1 tỷ ở định giá ~$47 tỷ — doanh thu quy năm đã vượt $900 triệu; vòng gọi vốn bị "quá tải" nhu cầu nên quy mô cuối có thể lớn hơn. (qua TLDR AI 02/09)
Manus hoạt động độc lập trở lại — đội sáng lập tiếp tục dẫn dắt sản phẩm; một số người dùng bị gián đoạn truy cập dữ liệu và phải khôi phục từ sao lưu. (qua TLDR AI 02/09)
Meta: Muse Voice Transcribe — model tri giác âm thanh thời gian thực đầu tiên của Meta: nhận dạng giọng nói dạng streaming, phân tách hơn 20 người nói, phát hiện điểm kết câu, chuyển ngữ giữa chừng, và điều hướng theo ngữ cảnh. (qua TLDR AI 02/09)
"Agentic testing là gì" — lập trình viên nêu mục tiêu, agent tự tìm đường: nhìn → hành động → nhìn lại. Meta chạy vòng này ở quy mô lớn và thấy chỉ một phần tư sản phẩm đầu ra đáng giữ — nhưng vòng lặp vẫn có lãi, vì phần không qua được test bị loại tự động. Đây là lập luận đáng nhớ: khi việc kiểm chứng rẻ, tỷ lệ hỏng cao không còn là vấn đề. (qua TLDR 02/09)
"Hệ kiểu là một tiên tri tìm kiếm" — model viết Rust tốt hơn C++, viết Lean tốt hơn cả hai. Lý do đề xuất: trình biên dịch Rust không thể bị nói khéo cho qua mà không để lại một dòng khai nhận grep được, nên mỗi lần compile mang nhiều thông tin hơn C++. Lean thì có bộ kiểm chứng rẻ nên cho phép vét cạn — giải thích vì sao model giỏi Lean bất thường so với lượng code Lean ít ỏi từng thấy. (qua TLDR 02/09)

Pháp lý & bản quyền

System prompt mới của Claude rất không muốn nhắc lời bài hát (Simon Willison) — đây là hệ quả pháp lý nhìn thấy được trong sản phẩm, nối tiếp vụ kiện của Sony Music Publishing và Warner Chappell. Phần thêm mới: "Claude không tái tạo lời bài hát, thơ, hay đoạn trích từ sách và bài báo, dù toàn bộ hay một phần", và vẫn từ chối khi được yêu cầu diễn đạt lại trong cùng cuộc trò chuyện; tác phẩm trước 1929 thì được. Ràng buộc tương tự áp cho ảnh: không tái tạo "một tác phẩm nghệ thuật cụ thể, bìa album hay bìa sách, poster, logo, bộ icon ứng dụng, hay thiết kế sản phẩm" — và tiêu chí là mức độ nhận ra được, nên đổi màu hay đổi tư thế không lách được. Hai chi tiết phụ thú vị: Claude được dặn tránh dùng chữ "genuinely", "honestly", "straightforward" vì chúng làm giảm độ tin cậy, và không cần xin lỗi khi người dùng thô lỗ vô cớ. Lần đầu tiên system prompt công bố có đường dẫn ra ngoài miền Anthropic (các nguồn giảm thiểu tác hại: dancesafe.org, tripsit.me, psychonautwiki.org).
llm-gemini 0.34 — plugin cập nhật hỗ trợ các model Gemini mới ra hôm nay; đáng ghi nếu bạn dùng CLI llm để so sánh model chéo nhà cung cấp.

Ghi chú vận hành

Deep-dive queue: rỗng — không có thư DEEPDIVE nào trong 2 ngày qua (Gmail subject:DEEPDIVE newer_than:2d trả về 0 kết quả).
Tiếng nói định hình ngành: hôm nay không có bài mới từ Karpathy, Sam Altman, Bengio, Chollet, Chris Olah, Jason Wei, Ruder, Nathan Benaich — cả 8 feed đều 0 mục trong cửa sổ. The Batch vẫn dừng ở số #368 (28/08), đã trích trong digest 31/08 → không có gì mới để lấy. Nhóm chỉ-có-trên-X: không ai có phát ngôn lớn nào nổi lên trong nguồn đã thu, và tin lớn hôm nay đến từ thông cáo chính thức của lab chứ không từ cá nhân — nên không tiêu lượt WebSearch nào (0/3).
Nguồn bổ sung dùng: TLDR 02/09 và TLDR AI 02/09 (2 số, đều chưa dùng vì đến sau khi digest 02/09 đã gửi). AI Agents Weekly không có số mới trong 2 ngày.
Chống trùng: 4 paper feature và 5 paper liếc qua đều chưa từng xuất hiện trong bất kỳ digest nào trước. Không có hai brief nào trỏ trùng một arXiv id. Đã chủ động loại các mục trùng digest 02/09: LMArena Academic Partnerships (cả 2 bài), Anthropic Enterprise Frontier Safeguards, tổng kết chính sách Mỹ tháng 8 của TechPolicy, và Gemini agentic video.
Nguồn scrape: nhắc lại cảnh báo hệ thống — html_listing gán published = ngày đầu nhìn thấy. Các bài Google/Anthropic chọn hôm nay đều đã đọc nội dung xác nhận thật sự mới (Fairwind ghi rõ 02/09/2026; Fable/Mythos 5.1 và Gemini 3.8 Flash đều là thông cáo ra mắt). Hai bài LMArena và bài TechPolicy mang ngày 02/09 nhưng đã dùng hôm qua → bỏ.
Nguồn lỗi: không có (FAILED_SOURCES=none). 51 bài trong cửa sổ 02–03/09 → 27 paper + 11 blog ứng viên.
Hình: 2 hình lấy trực tiếp từ bản HTML arXiv (AgentJudgeBench, Harness-of-Harness), 2 hình dùng social-thumbnail Hugging Face vì trang arXiv của hai id còn lại chỉ trả về logo thay cho hình đầu. Cả 4 nén Pillow còn 64–107KB mỗi hình.
Không kiểm chứng được: bài CNBC về Astra trả HTTP 403 cho trình đọc tự động, nên các con số/khẳng định về Astra lấy từ bản tóm tắt TLDR AI 02/09, không phải từ nguồn gốc. Đã ghi rõ ở chỗ trích.
Headless → không publish artifact (công cụ Artifact cần phiên claude.ai sống). Bản web tự host qua tailscale serve.