Model mới ra mắt, doanh nghiệp chạy AI Agent phải làm gì

Trong vòng hai tháng, Anthropic ra ba model mạnh: Fable 5, rồi Opus 5, rồi Fable 5.1. Tôi theo dõi hơn 50 video nói về model mới nhất. Họ khen chỉ số, họ so hạn mức, họ tính giá tiền. Đủ cả.

Nhưng có hai thứ gần như không ai nói. Mà đúng hai thứ đó mới là thứ anh em đang chạy AI Agent trong doanh nghiệp cần biết.

Thứ nhất, model mới không đơn giản là giỏi hơn. Nó cư xử khác. Thứ hai, cứ hai tháng lại có ba model mới thì chiến lược nào để anh em không phải chạy theo?

Video gốc tôi quay ngày 04/09/2026. Bài viết này bổ sung phần video không có: trích dẫn nguyên văn tài liệu của Anthropic cho từng hành vi tôi nêu, một mục "Giới hạn thật" chỉ ra chỗ tôi nói giản lược so với tài liệu hãng, và các mẫu copy về dùng được luôn.

Anh em sẽ đi qua những gì?

1. Vì sao đổi model mới lại làm vỡ hệ thống đang chạy ngon
2. Bốn hành vi đổi giữa Opus 5 và Fable 5.1, có dẫn tài liệu hãng
3. Vì sao chuyện này giống hệt bài toán nâng cấp phiên bản database
4. Công thức tách bất biến khỏi biến thiên
5. Cách viết tiêu chí thành công đếm được, kèm mẫu copy về dùng
6. Cách tôi đưa model mới vào hệ thống mà không thay thẳng con đang chạy

Vì sao đổi model mới lại làm vỡ hệ thống đang chạy ngon?

Vì phần lớn anh em coi model mới là bản nâng cấp năng lực, trong khi hãng coi nó là một cái máy có tính nết riêng. Chỉ số thì model nào mới ra cũng ngon. Đọc chỉ số không cho anh em biết nó sẽ cư xử thế nào lúc chạy việc thật.

Anh em muốn biết nó cư xử ra sao thì đọc tài liệu của hãng, đừng đọc video review. Anthropic không viết một trang chung cho tất cả. Mỗi model một trang riêng.

Chính trang tổng hợp của Anthropic viết thẳng ra: "Each of these models has its own prompting page. Read the one for your model first, then the techniques that follow." Tạm dịch: mỗi model có trang hướng dẫn riêng, đọc trang của model anh em đang dùng trước đã.

Hãng viết riêng từng trang nghĩa là gì ạ? Nghĩa là hãng thừa nhận hành vi mặc định của chúng khác nhau. Anh em hình dung không? Nếu chỉ là chuyện giỏi hơn thì cần quái gì năm trang.

Model mới khác model cũ ở chỗ nào ngoài chuyện giỏi hơn?

Khác ở bốn chỗ, và cả bốn đều đụng thẳng vào tiền và vào tiến độ. Tôi sẽ đi từng cái, mỗi cái kèm câu nguyên văn của hãng để anh em tự kiểm. Lần trước tôi có chia sẻ kiểu so sánh này ở bài Fable 5 vs Opus 4.8: giao diện agent báo cáo doanh nghiệp, anh em đọc thêm để thấy nhịp đổi hành vi qua từng đời.

Cách tôi làm việc này rất đơn giản. Tôi vứt tài liệu hướng dẫn của từng model vào một notebook, cái đó là chỗ chứa dữ liệu, nó chỉ trích xuất từ đúng nguồn tôi đưa nên nó không bịa. Rồi tôi cắm con Claude vào notebook đó để nó chọc vào đọc và lập bảng so sánh cho tôi. Một thằng giữ dữ liệu, một thằng làm bộ não phân tích. Được chưa ạ?

Nó trả lời dài hay ngắn?

Đây là chỗ đổi rõ nhất. Con Opus 5 mặc định trả lời dài. Lên Fable 5.1 thì ngược hẳn, nó viết ngắn lại, ít in đậm, ít tiêu đề, ít danh sách.

Tài liệu Opus 5 viết: "Claude Opus 5's default user-facing responses run longer than prior Opus models'." Còn trang Fable 5.1 xếp riêng một mục tên "Writing density" cho tình huống "Prose runs long and dense".

Hệ quả với anh em là gì ạ? Là câu prompt anh em từng viết cho model cũ kiểu "đừng trả lời dài dòng, tóm tắt lại thôi" giờ có thể thừa. Thừa thì chưa chết. Nhưng nó ăn token của anh em mỗi lượt gọi, tháng nào cũng ăn. Chuyện token ăn tiền thế nào tôi có phân tích riêng trong bài Token là gì và vì sao chat AI càng dài càng tốn tiền.

Nó có báo cho anh em biết nó đang làm gì không?

Con Opus 5 hay thông báo. Nó nói trước nó định làm gì, làm xong bước một nó kể bước một. Nghe thì yên tâm, nhưng mỗi dòng kể là một dòng tính tiền.

Ông Fable 5.1 thì ngược lại. Nó im ỉm nó làm.

Tài liệu Fable 5.1 mô tả đúng cảnh này: "Claude Fable 5.1's default behavior is to write fewer user-facing updates during long tool-calling turns than Claude Fable 5 does... Users see the agent go quiet for minutes at a time."

Hai kiểu cư xử ngược nhau hoàn toàn. Một thằng làm đến đâu nói đến đấy, một thằng im ỉm nó làm.

Nó có tự dừng lại hỏi giữa chừng không?

Có. Và đây là cái nguy hiểm nhất với doanh nghiệp.

Tài liệu Fable 5.1 liệt kê thẳng tình huống này trong bảng tra cứu đầu trang: "Turn ends before the work is done, or the model asks permission for work you already requested." Tức là nó xin phép làm cái việc mà anh em đã giao rồi.

Với một người ngồi cạnh máy thì đây là hành vi lịch sự. Với một dây chuyền chạy đêm thì đây là hỏng. Đúng không ạ?

Nó sửa một dòng hay viết lại cả file?

Fable 5.1 có xu hướng viết lại cả file thay vì vá đúng chỗ cần sửa. Nó còn đẻ ra kha khá file test rồi để lại trong hệ thống.

Tài liệu hãng có hẳn hai mục cho hai chuyện này: "Whole files rewritten for small changes" và "more committed test files than the task called for". Cả hai đều ăn token, và cái thứ hai còn làm bẩn thư mục dự án của anh em.

Gom bốn hành vi lại thành bảng cho dễ nhìn:

Chuyện này giống hệt cái gì trong nghề database?

Giống hệt chuyện nâng cấp phiên bản database rồi câu lệnh chạy chậm đi. Tôi làm tối ưu cơ sở dữ liệu cho ngân hàng với chứng khoán 15 năm, gặp cảnh này nhiều rồi.

Bản chất nó là thế này. Ngày xưa lập trình viên muốn ép database chạy theo ý mình thì họ gắn một cái hint vào câu lệnh.

Lúc viết thì đúng. Bộ tối ưu của phiên bản cũ hay chọn nhầm đường, nên người ta gắn hint để ép nó đi đường A cho nhanh.

Rồi nâng cấp phiên bản. Bộ tối ưu đời mới chọn đường khác, tính toán khác, có khi đường A không còn là đường tốt nữa.

Rất nhiều dự án dính đúng chỗ này. Họ nâng cấp xong thì hiệu năng tụt, mà nhìn vào code thì chẳng ai sửa gì cả. Tôi có phân tích kỹ cơ chế này trong bài Hiệu năng MySQL 8: Nâng cấp lớn trong Query Optimizer khi xử lý SQL và bài Vì sao có Index mà câu SQL vẫn chậm.

Giờ anh em thay chữ "hint" bằng chữ "prompt", thay "database" bằng "model". Y hệt.

Cái prompt anh em nhét vào file cấu hình để ép model cũ đừng làm này đừng làm kia, lên model mới nó thành cái hint chết.

Chỗ này hay ở đây: chính hãng cũng nói đúng như vậy. Tài liệu Fable 5.1 dặn: "audit your prompt for instructions that suppress narration. Some earlier models were eager to give updates while working, which led to system prompt lines such as 'hold all findings for the final response.' Remove lines like that before adding anything." Tức là hãng bảo anh em đi rà lại và gỡ những dòng viết cho model đời trước, gỡ xong rồi mới thêm gì thì thêm.

Trang tổng hợp còn nói rộng hơn: "Tune anti-laziness prompting: If your prompts previously encouraged the model to be more thorough or use tools more aggressively, dial back that guidance."

Và cả cái mức effort anh em đã dò kỹ ở model cũ cũng không mang sang được: "Re-run the sweep even if you already ran one on Claude Fable 5: effort level names don't correspond to the same amount of thinking across models."

Đấy. Không phải tôi suy diễn. Hãng viết trong tài liệu chính thức của hãng.

Vậy công thức để không phải chạy theo model là gì?

Công thức chỉ có ba vế, và anh em vẽ ra giấy là thấy ngay chỗ nào mình nắm được, chỗ nào mình buông.

Quy trình cộng Model bằng Kết quả.

Cái Model đừng nhìn thành một cục. Bổ nó ra làm hai: phần bất biến và phần biến thiên.

Biến thiên là gì ạ? Là đúng bốn thứ tôi vừa nói ở trên. Đổi model là đổi hết.

Còn bất biến là gì? Là những thứ model nào cũng vậy, đời nào cũng vậy:

• Kết quả nó trả ra là xác suất. Nó trông có vẻ đúng, chứ không chắc chắn đúng như một câu lệnh database. Cùng một đề bài, chạy hai lần có thể ra hai kiểu.
• Nó làm việc dựa trên ví dụ. Anh em mô tả suông thì nó hiểu lỗ mỗ. Đưa cho nó một ví dụ mẫu thì nó bám theo được ngay.
• Mọi thứ đưa vào đều là token. Chữ, tài liệu, ảnh, tất cả bị cắt nhỏ thành token rồi nó mới đọc. Nên độ dài đầu vào là tiền, không phải chuyện văn phong. Cách tôi kéo tiền token xuống khi cho AI chạy nguyên một kênh nội dung thì nằm ở bài Tối ưu chi phí token.

Ba thứ đó không đổi. Anh em xây hệ thống dựa trên ba thứ đó thì đổi model không việc gì.

Còn nếu anh em xây hệ thống dựa trên nhánh biến thiên, tức là dựa trên mấy câu prompt ép nó cư xử theo ý mình, thì mỗi lần hãng ra model mới là một lần anh em phải làm lại. Cực kỳ mệt.

Kiểm soát cụ thể bằng cách nào?

Bằng hai thứ nằm ở vế Quy trình chứ không nằm ở vế Model: tiêu chí thành công đếm được, và quy tắc làm việc bám quy trình.

Tiêu chí thành công phải đếm được. Tôi ví dụ một quy trình rất đời thường: dùng AI trả lời bình luận khán giả. Tiêu chí thành công là số bình luận chưa trả lời bằng 0. Bằng 0 là đạt. Khác 0 là chưa đạt. Hết.

Anh em thấy chỗ hay chưa ạ? Cái tiêu chí đó không quan tâm model trả lời dài hay ngắn, im lặng hay bô bô. Nó đo cái kết quả cuối cùng.

Quy tắc làm việc cũng thế. Đừng viết "hãy trả lời ngắn gọn". Ngắn gọn là bao nhiêu? Viết "trả lời trong vòng 10 chữ, đếm số chữ trước khi trả về". Đếm được thì máy nào chạy cũng ra một kết quả.

Đây là mẫu tôi để anh em copy về sửa lại theo nghiệp vụ của mình:

NHIEM VU
Mo ta viec can lam trong 1 cau.

DAU VAO
[1] Nguon du lieu, duong dan hoac ten bang
[2] Pham vi xu ly, tu ngay nao toi ngay nao

TIEU CHI THANH CONG (dem duoc, khong dung tinh tu)
[1] So ban ghi chua xu ly con lai = 0
[2] Moi ban ghi ket qua deu co truong nguon, khong duoc de trong
[3] Do dai moi cau tra loi <= 10 chu, tu dem truoc khi tra ve

TIEU CHI THAT BAI
[1] Bat ky ban ghi nao thieu truong nguon
[2] Bat ky cau tra loi nao vuot 10 chu

QUY TAC LAM VIEC
[1] Ghi log tung buoc: lam gi, tren ban ghi nao, ket qua ra sao
[2] Chi sua dung phan can sua, khong tao lai file moi
[3] Khong tao them file test ngoai danh sach da neu
[4] Lam het viec roi moi bao cao, khong dung lai xin phep giua chung

CACH BAO CAO
In ra bang 3 cot: so ban ghi da xu ly, so con lai, so ban ghi loi.

Bốn dòng trong mục quy tắc làm việc chính là chỗ chặn bốn hành vi biến thiên tôi nêu ở trên. Anh em để ý là tôi không hề viết "hãy trả lời ngắn gọn nhé" ở đâu cả. Tôi chỉ ra tiêu chí và quy tắc, còn nó cư xử thế nào là việc của nó.

Chuyện tiêu chí đạt và người duyệt tôi có chia sẻ kỹ hơn trong bài AI Agent làm sai hoài: thiếu tiêu chí đạt và người duyệt. Còn cách dựng cả một sơ đồ vận hành trước khi giao việc cho đội agent thì nằm ở bài AI Agent tự chia việc: tấm bản đồ khiến chúng chạy đúng.

Có model mới thì thay luôn hay làm gì?

Đừng thay vội, đừng thay vội.

Hệ thống của tôi đang chạy trên Opus 5. Fable 5.1 ra, tôi không rút Opus 5 ra rồi cắm Fable 5.1 vào. Tôi đưa nó vào một vai khác.

Cách làm gồm ba bước:

1. Ghi log toàn bộ quy trình đang chạy. Bước một làm gì, bước hai làm gì, dẫn chứng ở đâu. Không có log thì không có gì để soát.
2. Đưa model mới vào đọc log đó. Nhiệm vụ của nó là tìm chỗ làm chưa đúng, tìm giải thuật nào có thể làm gọn hơn.
3. Nhận đề xuất, tự quyết sửa hay không. Nó đề xuất, anh em duyệt. Nó không được tự tay sửa hệ thống đang chạy.

Tôi mượn một cái đầu suy luận tốt hơn để nghiệm thu việc của con đang chạy. Thay thẳng thì anh em ôm nguyên đống rủi ro của bốn hành vi biến thiên vào hệ thống đang ra tiền. Được chưa ạ?

Đây là mẫu đề bài tôi giao cho vai giám sát, anh em sửa lại theo hệ của mình:

VAI CUA MAY
May la nguoi soat viec, khong phai nguoi lam viec.
May khong duoc sua bat ky file nao trong he thong.

DAU VAO
File log quy trinh: tung buoc, dau vao, dau ra, dan chung.

VIEC CAN LAM
[1] Doc het log, dung lai chuoi buoc that su da chay.
[2] Voi tung buoc, tra loi 3 cau:
    - Buoc nay co dan chung khong, hay chi la ket luan suong?
    - Buoc nay co the bo di ma ket qua khong doi khong?
    - Co cach lam nao it token hon ma cung ket qua khong?
[3] Chi ra buoc nao dang lam sai so voi tieu chi thanh cong da neu.

DAU RA
Bang 4 cot: ten buoc, van de tim thay, muc do (cao/vua/thap),
de xuat sua cu the.
Xep buoc muc do cao len dau.

KHONG DUOC LAM
Khong sua file. Khong chay lai quy trinh. Khong tu y doi tieu chi.

Bức tranh tổng, gói lại trong một bảng

Giới hạn thật

Mục này tôi viết ra để anh em không bê nguyên bài đi áp mà vấp.

Một, tôi có nói giản lược một chỗ so với tài liệu hãng. Trong video tôi nói Anthropic khuyên mặc định dùng Opus 5, đo thấy chưa đạt thì mới lên Fable 5.1. Tôi đọc lại các trang tài liệu công khai thì hãng không viết thành một luật như vậy. Hãng đưa bảng chọn theo đầu việc: Opus 5 cho việc code phức tạp và việc doanh nghiệp, Fable 5 cho việc cần năng lực cao nhất và agent chạy dài. Rồi hãng bảo tự dựng bộ test trên chính nghiệp vụ của mình mà đo. Tinh thần thì giống nhau, đo trước rồi hãy đổi. Nhưng cái luật "mặc định Opus 5" thì tôi chưa tìm được câu chữ chính thức, anh em đừng trích tôi khi đi họp.

Hai, có một cần gạt tôi không nói trong video. Tài liệu hãng viết: "Tuning effort is often a better lever than switching models." Tức là chỉnh mức effort trong cùng một model nhiều khi lợi hơn là đổi hẳn sang model khác. Cái này rẻ hơn và ít rủi ro hơn cách tôi làm nhiều. Anh em thử cái này trước khi tính chuyện thay model.

Ba, bốn hành vi tôi nêu là hành vi mặc định, không phải hằng số. Chúng đổi theo mức effort, đổi theo cách cái công cụ anh em đang dùng gọi API, và hãng cập nhật tài liệu liên tục. Đọc bài này xong vẫn phải mở trang tài liệu của đúng model mình dùng ra đọc.

Bốn, tôi chỉ nói về model của Anthropic. Cách tư duy tách bất biến khỏi biến thiên thì hãng nào cũng dùng được. Nhưng bốn hành vi cụ thể trong bảng là của Opus 5 với Fable 5.1, đừng bê sang hãng khác.

Năm, số liệu trong bài là tính tới đầu tháng 09/2026. Hai tháng ra ba model thì tài liệu cũng đổi theo nhịp đó.

Anh em làm được gì trong bảy ngày?

• Ngày 1. Mở tài liệu prompt của đúng model đang chạy trong hệ thống. Đọc mục hành vi mặc định, ghi ra giấy những chỗ khác với thứ anh em đang tưởng.
• Ngày 2. Rà lại toàn bộ file prompt và file cấu hình. Đánh dấu mọi câu ép hành vi kiểu "đừng dài dòng", "hãy báo cáo từng bước". Đó là hint cũ.
• Ngày 3. Gỡ những câu đó ra, chạy thử lại quy trình. Xem kết quả có tệ đi không.
• Ngày 4. Viết tiêu chí thành công cho một quy trình đang chạy. Bắt buộc đếm được. Không có tính từ.
• Ngày 5. Bật ghi log từng bước cho quy trình đó.
• Ngày 6. Đưa model mới vào vai giám sát, cho nó đọc log và trả về bảng đề xuất.
• Ngày 7. Chọn một đề xuất rẻ nhất mà làm. Cứ làm đi sai lại sửa.

Câu hỏi hay gặp

Model mới ra thì có nên đổi ngay không?

Không nên đổi thẳng con đang chạy việc ra tiền. Đưa model mới vào vai giám sát trước, cho nó đọc log của quy trình hiện tại và đề xuất cải tiến. Đo bằng tiêu chí thành công của chính nghiệp vụ mình, thấy hơn hẳn thì mới tính chuyện thay.

Prompt viết cho model cũ có dùng lại được không?

Phần mô tả nghiệp vụ và tiêu chí thì dùng lại được hết. Phần ép hành vi thì phải rà lại. Tài liệu Anthropic dặn thẳng là gỡ những dòng viết cho model đời trước ra trước khi thêm gì mới, vì model mới có thể phản ứng thái quá với đúng câu dặn đó.

Bất biến và biến thiên khác nhau thế nào?

Bất biến là thứ model nào cũng vậy: kết quả là xác suất, làm việc theo ví dụ, mọi đầu vào đều là token. Biến thiên là hành vi mặc định của từng model: dài hay ngắn, có báo tiến độ hay không, có dừng hỏi hay không, sửa file kiểu gì. Xây hệ thống trên bất biến thì đổi model không sao.

Tiêu chí thành công viết thế nào cho đúng?

Viết ra thứ đếm được và kiểm được bằng máy. "Số bản ghi chưa xử lý bằng 0" là tiêu chí. "Làm cho tốt vào" thì không phải tiêu chí. Kèm theo phải có tiêu chí thất bại, để biết lúc nào dừng lại báo người.

Doanh nghiệp không có đội kỹ thuật thì làm được không?

Được. Bốn việc nặng nhất trong bài này là viết quy trình, viết tiêu chí thành công, bật ghi log và duyệt đề xuất. Cả bốn đều là việc nghiệp vụ, không phải việc code.

Đọc chỉ số benchmark có ích gì không?

Ích ít. Model mới nào chỉ số cũng đẹp. Thứ quyết định kết quả của anh em là quy trình và tiêu chí, không phải con số trên bảng xếp hạng. Bỏ qua cho đỡ mất thời gian.

Đúc kết

Model mới không đơn giản là bản giỏi hơn của model cũ. Nó là một người mới, có tính nết mới, và cái prompt anh em viết cho người cũ có thể thành cái hint chết.

Muốn không phải chạy theo hãng thì tách cho rõ: cái gì bất biến, cái gì biến thiên. Xây hệ thống trên phần bất biến với quy trình của mình, đo bằng tiêu chí đếm được. Lúc đó hãng ra model gì cũng được, kết quả của anh em vẫn đứng.

Còn model mới thì cho nó làm người giám sát trước đã. Cứ làm đi, sai lại sửa.

Nếu anh em muốn xem tôi dựng cả một đội agent chạy nghiệp vụ thật thì đọc thêm bài AI Agent vận hành doanh nghiệp: 3 bước tôi đã làm thật và bài Claude Fable 5: ba thay đổi lớn cho doanh nghiệp non-tech. Còn muốn đi cùng tôi để áp vào đúng nghiệp vụ công ty mình thì xem chương trình coaching trên trang này. Tuỳ anh em.

Nguồn tham khảo

• Prompting best practices, Claude Platform Docs. trang tổng hợp, có bảng liệt kê từng model một trang hướng dẫn riêng
• Prompting Claude Fable 5.1. hành vi báo tiến độ, viết lại cả file, dừng lại xin phép, writing density
• Prompting Claude Opus 5. mục Response length and verbosity, mục User-facing progress updates
• Migration guide, Claude Platform Docs. mục gỡ prompt viết cho model đời trước
• Choosing the right model. bảng chọn model theo đầu việc, và câu "tuning effort is often a better lever than switching models"
• Video gốc trên kênh Trần Quốc Huy. bản quay ngày 04/09/2026