Dynamic workflow Opus 4.8: điều phối 94 subagent thật

Anthropic ra Claude Opus 4.8 ngày 28/05/2026. Hôm sau tôi quay video này, ra đúng một đề bài, và nó tự thuê 94 nhân công đi làm cho tôi trong 22 phút. Bài này tôi có chia sẻ nguyên chuyến chạy đó, kèm số token thật đọc được trên màn hình, và phần quan trọng nhất là khi nào gọi nhiều agent thì lỗ.

Video gốc dài 15 phút 30. Bài viết này bổ sung ba thứ video không có: số token cụ thể của từng agent, các giới hạn kỹ thuật lấy từ tài liệu Anthropic, và một bảng để anh em tự quyết khi nào nên gọi cả đàn agent.

Mọi con số trong bài chốt tại thời điểm cuối tháng 5/2026. Đây là phần mô hình mau cũ nhất, nên anh em đọc xong nhớ đối chiếu lại với tài liệu hãng.

Mô hình mới ra thì nên đọc gì trước?

Bỏ qua bảng thông số. Đọc danh sách tính năng mới.

Hãng nào ra mô hình cũng có một trang so sánh. Opus 4.8 so với 4.7, so với GPT 5.5, so với Gemini 3.1 Pro. Điểm lập trình, điểm computer use, khách hàng khen. Ông nào ra báo cáo chẳng nói ngon.

Quan điểm của tôi, nếu anh em là chủ doanh nghiệp, nếu anh em không làm nghề lập trình, thì bỏ hết phần đó. Anh em chỉ cần biết một điều: mình là người trả tiền, và bộ não mình thuê ngày càng tốt lên. Thế là đủ.

Thứ đáng đọc là cái mới. Ở Opus 4.8 có đúng một thứ mới đáng để anh em bỏ thời gian, đó là dynamic workflow.

Dynamic workflow là gì?

Dynamic workflow là chế độ để Claude tự viết ra một kịch bản điều phối, rồi tự chạy hàng chục tới hàng trăm subagent song song trong cùng một phiên, tự kiểm tra kết quả trước khi trả về cho anh em.

Bản chất nó là gì? Nó đổi vai người điều phối.

Trước đây anh em có một dự án lớn, ví dụ chuyển dữ liệu từ hệ thống A sang hệ thống B, hoặc một việc phân tích chạy rất lâu. Anh em phải là người viết kịch bản. Anh em phải là người quyết agent nào làm gì, chạy theo thứ tự nào. Mệt ở chỗ đó.

Bây giờ anh em thuê một ông quản trị dự án chuyên nghiệp. Anh em ra đề bài, anh em trả tiền. Ông ấy tự lên kế hoạch, tự đi thuê nhân công, tự giao việc, tự nghiệm thu rồi mới trả kết quả về.

Có một chi tiết kỹ thuật đáng chú ý. Kịch bản đó là một file JavaScript thật, chạy trong môi trường tách rời khỏi cuộc hội thoại. Nên kết quả trung gian nằm trong biến của kịch bản, không đổ vào đầu con Claude đang nói chuyện với anh em. Chỗ này quyết định luôn phần chất lượng, tôi có phân tích ở mục dưới.

Bật ultracode thế nào?

Bật bằng lệnh /effort rồi kéo sang phải tới nấc ultracode. Không cần cài VS Code, không cần cài gì thêm.

Ba bước, anh em chép về dùng luôn:

[1] Mở command line, gõ:
    claude

[2] Kiểm tra dòng đầu phải thấy:
    Opus 4.8 (1M context)

[3] Đổi mức nỗ lực cho cả phiên:
    /effort
    Bấm mũi tên phải tới nấc "ultracode", rồi Enter

[4] Cách 2, chỉ bật cho một việc:
    Gõ thẳng từ khoá ultracode vào trong câu lệnh
    Ví dụ: ultracode phân tích toàn bộ thư mục hợp đồng năm 2026

[5] Xem chuyến đang chạy, xem token từng agent:
    /workflows

Hai cách này khác nhau ở chỗ nào? Bật /effort ultracode là bật cho cả phiên, mọi việc đáng kể Claude đều dựng workflow. Gõ từ khoá ultracode trong một câu lệnh thì chỉ việc đó thôi. Anh em mới thử thì dùng cách hai, đỡ tốn.

Tính năng này cần Claude Code từ bản v2.1.154 trở lên. Bản tôi chạy trong video là v2.1.156.

94 subagent chạy thật trông ra sao?

Tôi ra một đề bài mà bình thường làm bằng cơm thì mất cả tuần: quét toàn bộ dữ liệu khách hàng và học viên, tìm xem họ đang vướng gì, tôi cần bổ sung giá trị gì.

Nguồn của tôi nằm rải rác. Các buổi Zoom tư vấn. Các buổi Zoom đào tạo. Cộng đồng học viên riêng. Nó phải chọc được vào từng chỗ đó thì mới làm được.

Ra đề xong, nó tự chia việc:

Anh em để ý con số 16. Đó không phải tôi chọn, đó là trần cứng của runtime. Nó giới hạn số agent chạy đồng thời để khỏi ăn hết CPU máy anh em.

Trước khi phóng bản đầy đủ, nó tự chạy thử 2 agent để xác nhận đọc được cả transcript Zoom lẫn nội dung cộng đồng. Chạy thử xong, ok=true, mới phóng bản chính. Chỗ này là nó tự làm, tôi không dặn.

Xem được token của từng agent ở đâu?

Gõ /workflows rồi bấm Enter vào chuyến đang chạy. Nó liệt kê từng agent một, kèm token, số lần gọi công cụ, và thời gian.

Đây là thứ tôi thích nhất ở màn hình này. Nó không giấu giá. Anh em nhìn được từng ông nhân sự tiêu bao nhiêu, gọi bao nhiêu công cụ, chạy bao lâu. Muốn dừng thì bấm x, phần đã xong vẫn giữ.

Vì sao chia gần 100 agent mà nó không bịa?

Vì mỗi agent có bình nước riêng, và ông tổng thầu chỉ nhận nước cốt chứ không nhận cả bình.

Hình dung thế này cho dễ. Bộ não AI là mô hình ngôn ngữ, nó có một lượng ngữ cảnh nhớ được trong đầu, gọi là context. Opus 4.8 là 1 triệu context. Coi như cái bình 10 lít.

Anh em đổ nước vào. Quá 10 lít thì tràn. Tràn thì nó không nhớ. Không nhớ thì nó bịa, hoặc trả lời sai.

Bây giờ bắt nó phân tích 87 buổi Zoom, mỗi buổi 2 tới 3 tiếng. Đó là 100 lít nước. Một cái bình 10 lít không cách nào chứa nổi.

Nhưng khi tôi thuê ông CEO, ông ấy đi thuê 94 ông nhân sự. Mỗi ông nhân sự lại có một cái bình 10 lít của riêng mình. Ông nhân sự nhận đề bài phân tích buổi Zoom ngày 01 tháng 3, đọc hết 2 tiếng rưỡi nội dung, rồi chỉ trả ra một bản đúc kết ngắn.

Cái bản đúc kết ngắn đó mới là thứ gửi lên ông CEO. Quá trình đọc nằm lại trong bình của ông nhân sự. Ông CEO không quan tâm quá trình. Nên bình của ông CEO vẫn rộng rãi, ông xử lý được.

Đấy là toàn bộ lý do kỹ thuật đằng sau. Chia nhiều agent không phải để trông cho oai. Chia để mỗi ông có một bình riêng.

Anthropic có số liệu củng cố đúng điểm này. Trong bài phân tích hệ nhiều agent của họ, riêng lượng token đã giải thích 80% chênh lệch hiệu quả giữa các kiến trúc, và ba yếu tố gồm token, số lần gọi công cụ, lựa chọn mô hình giải thích tới 95%. Nói cách khác, hệ nhiều agent chạy tốt chủ yếu vì nó tiêu được nhiều token hơn vào cùng một bài toán.

Giới hạn thật: chuyến chạy đó tốn bao nhiêu?

Đây là phần tôi muốn anh em đọc kỹ nhất, vì nó là chỗ dễ mất tiền nhất.

Một chuyến tốn bao nhiêu?

Chuyến trong video: gần 7 triệu token, 94 agent, chạy 22 phút 35 giây. Từng agent Zoom tiêu từ khoảng 38 nghìn tới 444 nghìn token.

Đây là số đọc thẳng trên màn hình, anh em soi lại được trong hai ảnh phía trên.

Anthropic công bố con số nền để so sánh: agent thường tiêu khoảng 4 lần token so với một lượt chat, còn hệ nhiều agent tiêu khoảng 15 lần. Họ nói thẳng trong cùng bài đó rằng hệ nhiều agent chỉ đáng về mặt kinh tế khi giá trị công việc đủ lớn để trả cho phần hiệu quả tăng thêm.

Tài liệu Claude Code còn nói rõ hơn. Khi một chuyến vượt 25 agent, hoặc token dự phóng vượt 1,5 triệu, nó bật cảnh báo Large workflow ngay trên thanh tiến trình. Nhưng phiên nào đã bật ultracode thì không hiện cảnh báo nữa, vì bật ultracode tức là anh em đã đồng ý chạy lớn rồi.

Chỗ tiền thì tách làm hai trường hợp, đừng nhầm:

Tôi dùng thuê bao nên tôi không trả tiền token. Nhưng đừng vì thế mà tưởng nó miễn phí. Chạy vài chuyến kiểu này là hết hạn mức của ngày, lúc cần gấp lại không có mà dùng.

Khi nào gọi cả đàn agent, khi nào một con là đủ?

Đây là bảng tôi tự dùng để quyết. Anh em chép về sửa theo việc của mình.

Anthropic nói thẳng một điều mà tôi thấy ít người nhắc: phần lớn việc lập trình có ít phần chạy song song được thật sự hơn việc nghiên cứu. Và những việc mà mọi agent đều cần chung một ngữ cảnh, hoặc các phần phụ thuộc chằng chịt vào nhau, thì hiện tại chưa hợp với hệ nhiều agent.

Nên đừng thấy nó chạy 94 con mà nghĩ việc gì cũng ném vào đó. Ném sai loại việc là vừa lâu vừa tốn vừa ra kết quả tệ hơn một con agent chạy tử tế.

Những thứ workflow không làm được

Bốn giới hạn cứng, nằm trong tài liệu Claude Code, không phải tôi suy đoán:

• Không chen vào giữa chừng. Chuyến đang chạy thì anh em không nhắn thêm được. Muốn có chốt chặn giữa các chặng thì tách mỗi chặng thành một chuyến riêng.
• Bản thân kịch bản không đụng được vào file hay shell. Chỉ các agent mới đọc, ghi, chạy lệnh. Kịch bản chỉ điều phối.
• Không nạp được thư viện. Kịch bản có import() là hỏng ngay từ trước khi chạy. Việc nào cần thư viện thì đẩy vào trong task của agent.
• Trần 16 agent chạy đồng thời, và tối đa 1000 agent cho một chuyến. Cái trần 1000 là để chặn kịch bản chạy loạn.

Cách tôi chặn lỗ

QUY TẮC TRƯỚC KHI PHÓNG MỘT CHUYẾN LỚN

1. Chạy thử trên một lát cắt nhỏ trước.
   Một thư mục thay vì cả kho. Ba file Zoom thay vì 87.
   Xem nó tiêu bao nhiêu token cho 3 file, rồi nhân lên.

2. Đặt cỡ chuyến trong /config
   /config workflowSizeGuideline=small    # dưới 5 agent
   /config workflowSizeGuideline=medium   # dưới 15 agent, mặc định
   /config workflowSizeGuideline=large    # dưới 50 agent

3. Trong lúc chạy, mở /workflows và nhìn cột token.
   Thấy một agent ăn gấp 5 lần các agent khác là đề bài của nó sai.
   Bấm x để dừng. Phần đã xong vẫn giữ.

4. Ra đề bài có tiêu chí hoàn thành rõ ràng.
   Sai:  "phân tích dữ liệu khách hàng cho anh"
   Đúng: "mỗi buổi Zoom trả về tối đa 10 gạch đầu dòng,
          mỗi gạch gồm nỗi đau, trích dẫn nguyên văn, mốc thời gian"
   Đầu ra càng gọn thì bình của ông tổng thầu càng rộng.

5. Việc nào có bước sau phụ thuộc bước trước thì đừng dùng workflow.

Điểm số 4 là chỗ ăn tiền. Đề bài mơ hồ thì 94 ông nhân sự cùng đoán, mỗi ông đoán một kiểu, và anh em trả tiền cho toàn bộ phần đoán đó.

Bảy ngày tới anh em làm được gì?

• Ngày 1: Kiểm tra bản Claude Code. Phải từ v2.1.154 trở lên. Gõ claude rồi nhìn dòng đầu có Opus 4.8 (1M context) không.
• Ngày 2: Liệt kê ra giấy những nguồn dữ liệu của anh em đang nằm rời rạc. Zoom, email, file, nhóm chat, cộng đồng.
• Ngày 3: Nối cho được một nguồn. Đúng một thôi. Nguồn nào nhiều dữ liệu nhất thì nối trước.
• Ngày 4: Ra một đề bài nhỏ trên 3 file, gõ từ khoá ultracode trong câu lệnh. Ghi lại số token.
• Ngày 5: Nhân số token đó lên theo số file thật của anh em. Tự quyết có đáng chạy không.
• Ngày 6: Nếu đáng thì đặt workflowSizeGuideline rồi phóng bản đầy đủ. Ra đề có tiêu chí hoàn thành rõ.
• Ngày 7: Đọc kết quả, sửa lại đề bài, chạy lần hai. Lần hai bao giờ cũng ngon hơn lần một.

Cứ làm đi. Sai lại sửa. Chạy được đã, chưa cần đẹp.

Câu hỏi hay gặp

Dynamic workflow có phải là subagent thường không?

Không. Subagent thường do Claude điều phối theo từng lượt, kết quả đổ về cửa sổ ngữ cảnh của nó. Dynamic workflow đẩy kế hoạch vào một kịch bản JavaScript chạy tách rời, nên kết quả trung gian nằm trong biến của kịch bản. Cái lặp lại được ở subagent là định nghĩa agent, còn ở workflow là chính phần điều phối.

Tôi không biết lập trình thì dùng được không?

Được. Anh em không viết dòng kịch bản nào. Anh em ra đề bài bằng tiếng Việt, Claude tự viết kịch bản. Việc của anh em là mô tả đúng đầu ra mình cần và tiêu chí thế nào là xong.

Không phải Max thì có dùng được không?

Gói Pro dùng được nhưng mặc định tắt, phải tự bật trong /config. Max, Team, Enterprise thì bật sẵn. Dùng qua API Anthropic cũng có, và trên Amazon Bedrock, Vertex AI, Microsoft Foundry.

Chạy 94 agent thì kết quả có đáng tin hơn một agent không?

Đáng tin hơn khi việc chia nhỏ được thành các phần độc lập, vì mỗi agent có ngữ cảnh riêng nên không bị tràn. Nhưng với việc mà các phần phụ thuộc lẫn nhau, hoặc mọi agent cần chung một ngữ cảnh, thì hiện tại chia nhiều agent chưa hợp.

Đang chạy dở mà tôi tắt máy thì sao?

Tiến trình được lưu dần trong lúc chạy, nên chuyến bị ngắt sẽ chạy tiếp từ chỗ dở chứ không làm lại từ đầu. Anh em chủ động dừng bằng phím x trong /workflows thì phần đã xong cũng giữ nguyên.

Có nên đổi sang tool khác cho rẻ không?

Quan điểm của tôi là đừng bám vào tool, hãy bám vào hãng. Tool rồi sẽ ra đi. Con trợ lý của tôi dựng từ hồi Opus 4.7, hãng nâng lên 4.8 thì nó được nâng theo, tôi không dựng lại gì. Còn ai bám vào một tool trung gian, tới lúc hãng chặn tool đó thì mất luôn quyền dùng bộ não tốt nhất.

Đúc kết

Opus 4.8 không đáng chú ý vì mấy điểm benchmark. Nó đáng chú ý vì đổi vai người điều phối: anh em thôi làm quản đốc, chuyển sang làm người ra đề và trả tiền.

Nhưng cái giá có thật. Gần 7 triệu token cho một chuyến, gấp khoảng 15 lần một lượt chat theo số liệu chính Anthropic công bố. Việc nào chia nhỏ được và giá trị đủ lớn thì gọi cả đàn. Việc nào bước sau cần bước trước thì một con agent chạy tử tế còn hơn.

Anh em cứ thử trên một lát cắt nhỏ trước, nhìn số token, rồi tự quyết. Tùy anh em, cách nào cũng được.

Tôi có chia sẻ nguyên quy trình dựng đội ngũ agent chạy việc công ty trong bài Cách tôi cho đội ngũ AI agent vận hành cả công ty. Các bài khác nằm ở trang Tài nguyên. Anh em nào muốn làm bài bản từ nghiệp vụ của mình thì xem chương trình đào tạo Agentic AI, hoặc vào cộng đồng hỏi trực tiếp.

Nguồn tham khảo

• Anthropic, Introducing Claude Opus 4.8, 28/05/2026
• Anthropic, Introducing dynamic workflows in Claude Code, 28/05/2026
• Anthropic, Orchestrate subagents at scale with dynamic workflows, tài liệu Claude Code
• Anthropic, How we built our multi-agent research system, 13/06/2025
• Claude Code, ghi chú phát hành v2.1.154