Hầu hết người dùng Claude Code vẫn viết workflow bằng tay. Họ xâu chuỗi các prompt, copy kết quả đầu ra, dán vào prompt tiếp theo, sửa lỗi, rồi lặp lại.
9 trên 10 người xây dựng chưa từng thử Dynamic Workflows dù chỉ một lần, mặc dù tính năng này đã được ra mắt cách đây hai tuần.
Họ viết 50 prompt trong khi một workflow có thể giải quyết tất cả. Đây là lộ trình 14 bước và 6 mẫu hình mà chính các kỹ sư của Anthropic thực sự sử dụng - cho việc di chuyển dữ liệu, nghiên cứu, sắp xếp, tìm nguyên nhân gốc rễ, phân loại và đánh giá.
Theo dõi Substack của tôi để nhận thông tin AI mới nhất:
Dynamic Workflows đã được ra mắt trong Claude Code vào ngày 28 tháng 5 năm 2026. Công cụ Claude Code mặc định được xây dựng cho việc lập trình - và nó hoạt động tốt cho hầu hết các tác vụ lập trình. Nhưng có những loại công việc mà một cửa sổ ngữ cảnh duy nhất bắt đầu bộc lộ hạn chế: các tác vụ chạy dài, song song hóa mạnh mẽ, có cấu trúc cao hoặc mang tính đối kháng.
Đối với những tác vụ đó, trước đây Anthropic tự xây dựng các công cụ tùy chỉnh (Nghiên cứu, Đánh giá mã, nhóm agent). Với Dynamic Workflows, Claude tự viết công cụ đó cho bạn ngay lập tức, được tùy chỉnh cho tác vụ của bạn, bằng JavaScript.
14 bước. 6 mẫu hình. Một workflow thay vì năm mươi prompt.
Phần 1 · Mô hình Tư duy
01. Workflow là một công cụ do Claude viết.
Công cụ Claude Code mặc định cho phép Claude lập kế hoạch và thực thi trong cùng một cửa sổ ngữ cảnh. Đối với hầu hết công việc lập trình, điều này rất tốt. Đối với các tác vụ chạy dài, song song hoặc mang tính đối kháng, nó bộc lộ hạn chế.
Dynamic Workflow là việc Claude tự viết công cụ tùy chỉnh cho tác vụ - một tệp JavaScript với một vài hàm đặc biệt để tạo ra và điều phối các subagent, cùng với JavaScript tiêu chuẩn (Math, JSON, Array) để xử lý dữ liệu luân chuyển giữa chúng.
Ba điều mà điều này mang lại cho bạn mà công cụ mặc định không thể:
- Cô lập từng agent. Mỗi subagent có cửa sổ ngữ cảnh riêng với một mục tiêu tập trung. Không có sự nhiễm chéo.
- Lựa chọn mô hình cho từng agent. Workflow chọn mô hình mà mỗi subagent sử dụng - Opus cho suy luận khó, Haiku cho khám phá chi phí thấp, Sonnet cho các tác vụ trung gian.
- Mức độ cô lập cho từng agent. Worktree (bản sao git độc lập) hoặc remote (không cần bản sao). Workflow quyết định mỗi agent cần gì.
Bắt đầu bằng cách yêu cầu trực tiếp Claude ("tạo một workflow để...") hoặc với từ kích hoạt ultracode. Nếu một workflow bị gián đoạn - do hành động của người dùng, thoát terminal - việc tiếp tục phiên làm việc sẽ bắt đầu lại từ nơi nó bị dừng.
02. 3 dạng lỗi mà workflow giải quyết.
Để biết khi nào workflow là công cụ phù hợp, bạn phải hiểu nó sửa lỗi gì. Claude càng làm việc lâu trên một tác vụ phức tạp trong một cửa sổ ngữ cảnh duy nhất, nó càng dễ mắc phải ba dạng lỗi cụ thể - được nêu tên trực tiếp trong bài viết ra mắt của Anthropic:
- Sự lười biếng của agent - Claude dừng lại trước khi hoàn thành một tác vụ phức tạp, nhiều phần và tuyên bố hoàn thành sau khi tiến triển một phần. Giải quyết 20 trong số 50 mục trong một đánh giá bảo mật và gọi phần còn lại là "đã xử lý."
- Thiên vị bản thân - Claude thích kết quả của chính nó hơn khi được yêu cầu xác minh hoặc đánh giá chúng theo một tiêu chí. Một người xác minh có liên quan đến kết quả không thể là một người xác minh công bằng.
- Trôi mục tiêu - sự mất dần độ trung thành với mục tiêu ban đầu qua nhiều lượt tương tác, đặc biệt là sau khi nén. Mỗi bước tóm tắt đều làm mất thông tin. Các ràng buộc "Đừng làm X" âm thầm biến mất ở lượt thứ 47.
Một workflow giải quyết cả ba vấn đề một cách có cấu trúc: các Claude riêng biệt với ngữ cảnh riêng, mục tiêu tập trung và trạng thái cô lập. Nếu tác vụ của bạn gặp phải bất kỳ dạng lỗi nào trong số này - đó là tín hiệu để sử dụng workflow.
03. Workflow tĩnh và động.
Bạn có thể đã xây dựng các workflow tĩnh bằng Claude Agent SDK hoặc claude -p - điều phối nhiều phiên bản Claude Code cùng nhau.
- Workflow tĩnh có tính tổng quát: được viết một lần để xử lý mọi trường hợp ngoại lệ. Chúng hoạt động, nhưng phải thận trọng.
- Dynamic Workflows khác: Claude viết workflow này cho tác vụ này. Công cụ được thiết kế riêng. Dưới đây là cùng một câu hỏi được xử lý theo cả hai cách:
Lý do phiên bản động chiến thắng không phải là bước tìm kiếm - cả hai đều có thể tìm kiếm.
Đó là vì workflow có thể tự định hình theo ngữ cảnh của bạn: đọc mã thanh toán của bạn, kiểm tra từng tính năng với tài liệu của nhà cung cấp mới thực tế, định giá theo khối lượng giao dịch của bạn và chạy một lượt đối kháng "tại sao không nên di chuyển" dựa trên câu trả lời đang nổi lên của chính nó.
Một công cụ tĩnh không thể làm điều này vì nó không biết mã của bạn tồn tại.
04. API cốt lõi. agent(), parallel(), pipeline().
Ba hàm thực hiện hầu hết công việc trong một workflow. Biết chúng là đủ để đọc bất kỳ workflow nào Claude viết cho bạn và để điều chỉnh Claude khi bạn muốn một hình dạng cụ thể.
parallel() là một rào cản: nó phân nhánh ra, sau đó chờ đợi mọi thứ trước khi trả về. pipeline() là luồng: mỗi mục chảy qua mọi giai đoạn một cách độc lập.
Chọn dựa trên câu hỏi: tôi có cần tất cả kết quả trước khi có thể làm bất cứ điều gì tiếp theo không? Có → parallel. Không → pipeline (rẻ hơn, nhanh hơn tổng thể).
05. Phân loại và hành động. Định tuyến công việc trước khi thực hiện.
Một agent phân loại quyết định loại tác vụ, sau đó workflow định tuyến đến các agent hoặc hành vi khác nhau dựa trên câu trả lời. Hoặc một bộ phân loại chạy ở cuối, sắp xếp các kết quả đầu ra thô vào các nhóm cho những gì xảy ra tiếp theo.
Khi mẫu hình này phát huy tác dụng:
- Tác vụ không đồng nhất - các loại phụ khác nhau cần cách xử lý khác nhau.
- Bạn muốn chỉ sử dụng mô hình đắt tiền ở nơi độ phức tạp yêu cầu (bộ phân loại trên mô hình rẻ, sau đó chỉ chuyển đến Opus khi cần).
- Việc phân rã công việc tự nó không hề đơn giản và được hưởng lợi từ việc một mô hình quyết định hình dạng.
Ví dụ: "Giải thích cách module auth hoạt động." Một subagent phân loại đọc cơ sở mã trước, ước tính độ phức tạp, sau đó định tuyến tác vụ giải thích thực tế đến Sonnet cho một module 10 tệp hoặc Opus cho một module 100 tệp. Mô hình phù hợp cho công việc, được quyết định sau khi hiểu rõ công việc.
06. Phân nhánh và tổng hợp. Nhiều bước nhỏ, một kết quả hợp nhất.
Chia một tác vụ thành nhiều bước nhỏ hơn. Chạy một agent trên mỗi bước song song. Tổng hợp kết quả thành một câu trả lời.
Bước tổng hợp là một rào cản - nó chờ đợi mọi agent phân nhánh, sau đó hợp nhất các kết quả đầu ra có cấu trúc của chúng.
Tại sao mẫu hình này chiếm ưu thế trong thực tế: nó giải quyết lỗi "quá nhiều thứ cùng một lúc" của công việc trong một ngữ cảnh duy nhất. Mỗi subagent chỉ thấy phần của nó. Người điều phối không bao giờ bị phân tâm bởi 50 chi tiết không liên quan.
Mỗi bước được hưởng lợi từ cửa sổ sạch riêng của nó để chúng không nhiễm chéo.
Sử dụng khi:
- Bạn có một danh sách các hạng mục công việc có thể liệt kê rõ ràng (50 tệp, 200 endpoint, 100 đánh giá).
- Mỗi hạng mục độc lập - không có hạng mục nào cần kết quả đầu ra của hạng mục khác để bắt đầu.
- Bạn muốn một câu trả lời tổng hợp duy nhất ở cuối, không phải một đống báo cáo một phần.
1// Phân nhánh: một agent cho mỗi tệp. Rào cản: chờ đợi tất cả.2const reviews = await parallel(3 files.map(file => () => agent(4 `Đánh giá ${file} về các vấn đề bảo mật`,5 { model: "haiku", schema: IssueList }6 ))7)89// Tổng hợp: một agent Opus hợp nhất mọi thứ.10const report = await agent(11 `Hợp nhất các đánh giá này thành một báo cáo ưu tiên:\n${JSON.stringify(reviews)}`,12 { model: "opus" }13)
07. Xác minh đối kháng
Đây là giải pháp có cấu trúc cho sự thiên vị bản thân. Đối với mỗi agent được tạo ra, hãy chạy một agent riêng biệt để xác minh đối kháng kết quả đầu ra của nó theo một tiêu chí. Người xác minh chưa bao giờ thấy công việc ban đầu; nó không thể ưu ái nó.
Mẫu hình này quan trọng nhất đối với:
- Kiểm tra tuyên bố - mọi tuyên bố thực tế trong một báo cáo đều có subagent xác minh riêng, kiểm tra dựa trên nguồn gốc ban đầu.
- Đánh giá mã - agent tác giả viết bản sửa lỗi, agent người đánh giá (ngữ cảnh riêng) đánh giá nó. Không bao giờ để cùng một Claude tự đánh giá chính nó.
- Cổng chất lượng - trước khi bất kỳ tạo phẩm nào được phát hành, một đối thủ cố gắng tìm ra trường hợp yếu nhất chống lại nó. Nếu đối thủ không thể, bạn phát hành.
Quy tắc ghép cặp: người xác minh chỉ nên biết tiêu chí và tạo phẩm, chứ không phải ai đã tạo ra nó. Nếu không, sự thiên vị bản thân sẽ len lỏi trở lại qua các gợi ý trong prompt.
08. Tạo và lọc.
Tạo ra một số ý tưởng về một chủ đề, sau đó lọc chúng theo một tiêu chí hoặc bằng cách xác minh. Loại bỏ các bản sao. Chỉ trả về những ý tưởng chất lượng cao nhất, đã được kiểm tra.
Nơi mẫu hình này tỏa sáng:
- Động não - 30 tên sản phẩm, sau đó một người xác minh loại bỏ các sáo ngữ, xung đột nhãn hiệu và ngữ âm yếu. Bạn thấy 3.
- Tạo giả thuyết - 5 cách tiếp cận khác nhau cho một vấn đề, sau đó mỗi cách được chấm điểm dựa trên các ràng buộc của bạn. Người chiến thắng đã xứng đáng.
- Thiết kế giải pháp - 5 cách tiếp cận khác nhau cho một vấn đề, sau đó mỗi cách được chấm điểm dựa trên các ràng buộc của bạn. Người chiến thắng đã xứng đáng.
Ngược lại với việc yêu cầu Claude đưa ra "câu trả lời tốt nhất." Yêu cầu câu trả lời tốt nhất khiến Claude cam kết sớm. Tạo và lọc khiến Claude cam kết muộn, sau khi mọi lựa chọn đã bị thách thức.
09. Giải đấu. So sánh cặp đôi tốt hơn chấm điểm tuyệt đối.
Thay vì chia nhỏ công việc, hãy để các agent cạnh tranh trên đó. Tạo ra N agent, mỗi agent cố gắng thực hiện cùng một tác vụ bằng các cách tiếp cận khác nhau, sau đó đánh giá kết quả theo từng cặp cho đến khi một agent chiến thắng.
Phán đoán so sánh đáng tin cậy hơn chấm điểm tuyệt đối - đặc biệt là đối với công việc dựa trên thị hiếu.
Tại sao điều này đánh bại sắp xếp theo điểm số: cố gắng sắp xếp 1.000 mục trong một prompt thất bại trên hai mặt trận - chất lượng giảm sút và nó sẽ không vừa với ngữ cảnh. Một giải đấu chia nhánh đấu qua các agent mới, mỗi agent chỉ so sánh hai mục.
Bản thân nhánh đấu nằm trong mã vòng lặp xác định, không nằm trong ngữ cảnh. Mỗi so sánh đều nhanh, công bằng và cô lập. Ý tưởng tương tự hoạt động cho xếp hạng dựa trên thị hiếu: lựa chọn thiết kế, lựa chọn ứng viên, ưu tiên nội dung.
10. Lặp cho đến khi hoàn thành.
Đối với các tác vụ có khối lượng công việc không xác định, hãy lặp lại việc tạo agent cho đến khi đáp ứng được điều kiện dừng - không có phát hiện mới, không còn lỗi trong nhật ký, lý thuyết đã được xác minh - thay vì chạy một số lượt cố định.
Mẫu hình này là câu trả lời cho "tiếp tục cho đến khi nó thực sự hoàn thành":
- Gỡ lỗi kiểm tra không ổn định - tái tạo, hình thành lý thuyết, kiểm tra chúng, cho đến khi một lý thuyết đúng.
- Săn lỗi - tiếp tục tìm lỗi cho đến khi một lượt đầy đủ trả về không.
- Khai thác mẫu hình - phân cụm, xác định quy tắc, cho đến khi không có cụm mới nào xuất hiện.
Kết hợp mẫu hình này với /goal để đặt yêu cầu hoàn thành cứng ("không dừng lại cho đến khi một lý thuyết hoạt động") và với /loop nếu bạn muốn toàn bộ workflow tự chạy theo lịch định kỳ.
Nhánh đấu và điều kiện dừng nằm trong mã; chỉ có lần lặp đang hoạt động mới ở trong ngữ cảnh.
11. Kết hợp các mẫu hình cho các trường hợp sử dụng thực tế. Một workflow, nhiều mẫu hình.
6 mẫu hình hiếm khi xuất hiện một mình. Một workflow thực tế kết hợp 2-4 mẫu hình. Ma trận dưới đây ghép nối từng trường hợp sử dụng từ bài viết ra mắt của Anthropic với các mẫu hình mà nó có xu hướng sử dụng:
- Di chuyển và tái cấu trúc. Phân nhánh (một agent cho mỗi callsite/kiểm tra thất bại trong một worktree) → xác minh đối kháng (một agent riêng biệt đánh giá từng bản sửa lỗi) → lặp cho đến khi hoàn thành. Đây là mẫu hình Anthropic đã sử dụng để viết lại Bun từ Zig sang Rust.
- Nghiên cứu chuyên sâu (kỹ năng /deep-research). Phân nhánh (tìm kiếm web song song) → xác minh đối kháng (mỗi tuyên bố được xác minh độc lập) → tổng hợp (một báo cáo có trích dẫn).
- Xác minh chuyên sâu một bản thảo. Xác định tất cả các tuyên bố thực tế (một agent) → phân nhánh (một người xác minh cho mỗi tuyên bố, mỗi agent kiểm tra dựa trên nguồn) → meta-người xác minh (kiểm tra các nguồn của người xác minh có chất lượng cao).
- Sắp xếp hơn 1.000 mục. Giải đấu (bước 5-9) - so sánh cặp đôi, xếp hạng theo nhóm hoặc nhánh đấu. Phán đoán so sánh, không bao giờ chấm điểm tuyệt đối.
- Tuân thủ bộ nhớ và quy tắc. Người xác minh cho mỗi quy tắc (phân nhánh) → persona hoài nghi xem xét các quy tắc để tránh kết quả dương tính giả.
- Điều tra nguyên nhân gốc rễ. Tạo lý thuyết từ các bằng chứng rời rạc (các agent khác nhau đọc nhật ký, tệp, dữ liệu) → hội đồng người xác minh và người bác bỏ cho mỗi lý thuyết → lặp cho đến khi một lý thuyết sống sót.
- Phân loại ở quy mô lớn. Phân loại và hành động → loại bỏ trùng lặp với các ticket hiện có → hoặc cố gắng sửa lỗi hoặc chuyển tiếp. Kết hợp với /loop để phân loại liên tục.
- Khám phá và thị hiếu (thiết kế, đặt tên, lựa chọn UI). Tạo và lọc (5-20 lựa chọn) → giải đấu với một tiêu chí → xếp hạng hoặc chọn.
- Đánh giá nhẹ. Chạy ứng viên trong một worktree → các agent so sánh chấm điểm theo tiêu chí → tinh chỉnh và chấm điểm lại. Cùng hình dạng với giải đấu nhưng để chấm điểm, không phải xếp hạng.
Cách đúng đắn để tiếp thu những điều này: xác định dạng lỗi nào mà tác vụ hiện tại của bạn đang gặp phải, sau đó chọn mẫu hình ngăn chặn nó một cách có cấu trúc.
Trôi mục tiêu → phân nhánh. Thiên vị bản thân → xác minh đối kháng. Kết thúc mở → lặp cho đến khi hoàn thành. Khó chấm điểm → giải đấu.
12. Kết hợp với /goal, /loop và ngân sách token.
Workflows có thể tốn kém. Ba biện pháp kiểm soát biến chúng từ "tuyệt nhưng đắt" thành "một công cụ tôi chạy mà không cần giám sát."
- /goal đặt một yêu cầu hoàn thành cứng. Kết hợp nó với mẫu hình lặp: "không dừng lại cho đến khi một lý thuyết hoạt động." Không có /goal, một workflow dừng lại ở một điểm hoàn thành mềm. Với /goal, nó lặp lại cho đến khi đáp ứng được điều kiện kết thúc thực tế.
- /loop chạy toàn bộ workflow theo lịch định kỳ. Sử dụng nó cho các workflow bạn muốn chạy liên tục - phân loại, cập nhật nghiên cứu hàng tuần, xác minh định kỳ.
- Ngân sách token rõ ràng. Nói với Claude trong prompt: "sử dụng 10k token." Điều này đặt giới hạn cho việc chạy workflow. Nếu không có giới hạn, một workflow tham vọng có thể phình to gấp 5–10 lần số token bạn mong đợi.
1> ultracode đánh giá đối kháng nhanh giả định này:2 "Chuyển sang Postgres loại bỏ việc cân bằng lại shard của chúng tôi."3 Sử dụng 5k token. /goal không dừng lại cho đến khi bạn có4 một phản ví dụ hoặc ba xác nhận độc lập.
Trích dẫn trực tiếp từ nhóm Claude Code: "Các phương pháp hay nhất vẫn đang được phát triển. Dynamic workflows thường sử dụng nhiều token hơn, vì vậy hãy cân nhắc kỹ khi nào và cách sử dụng chúng." Hầu hết các tác vụ lập trình truyền thống không cần một hội đồng gồm 5 người đánh giá.
Hãy tự hỏi: tác vụ này có thực sự cần nhiều sức mạnh tính toán hơn không? Nếu một phiên Claude Code thông thường có thể hoàn thành nó trong năm phút, bạn không cần một workflow.
13. Sử dụng mẫu hình cách ly cho đầu vào không đáng tin cậy.
Bất kỳ workflow nào đọc nội dung công khai không đáng tin cậy - ticket hỗ trợ, báo cáo lỗi, phản hồi của người dùng, dữ liệu được thu thập - đều cần giả định rằng nội dung đó có thể chứa prompt injection.
Giải pháp: cách ly. Ngăn các agent đọc nội dung không đáng tin cậy thực hiện bất kỳ hành động đặc quyền cao nào. Các agent riêng biệt, không tiếp xúc với nội dung thô, thực hiện hành động.
Bất kỳ workflow nào xử lý nội dung do người dùng gửi (ticket hỗ trợ, báo cáo lỗi, phản hồi của khách hàng, mạng xã hội), thu thập các trang web công cộng hoặc chạy dựa trên đầu ra từ API của bên thứ ba.
Nếu đầu vào không phải do bạn hoặc đồng đội đáng tin cậy viết, hãy cách ly nó. Một agent đọc chỉ-đọc 30 dòng hầu như không tốn chi phí và loại bỏ toàn bộ một lớp rủi ro prompt injection.
14. Lưu workflows. Phát hành chúng dưới dạng Skills.
Khi một workflow hoạt động, hãy lưu nó: nhấn s trong menu workflow. Các workflow đã lưu sẽ được đưa vào ~/.claude/workflows. Từ đó bạn có hai lựa chọn:
- Giữ nó ở local - sử dụng lại nó trong các dự án của riêng bạn.
- Phát hành nó dưới dạng Skill - đóng gói tệp JavaScript bên trong một thư mục Skill, tham chiếu nó trong SKILL.md và bất kỳ ai cài đặt Skill sẽ chạy cùng một workflow.
Một sắc thái thực tế đáng biết: khi bạn đóng gói một workflow thành Skill, hãy nhắc Claude coi workflow như một mẫu, không phải một tập lệnh để chạy nguyên văn.
Điều đó để lại chỗ cho Claude điều chỉnh hình dạng workflow cho tác vụ cụ thể trong khi vẫn giữ nguyên cấu trúc tổng thể. Đặc biệt hữu ích cho các workflow như "xác minh chuyên sâu" hoặc "phân loại" cần linh hoạt theo từng trường hợp sử dụng.
Những sai lầm lãng phí token trên workflows
- Sử dụng workflow khi một phiên Claude Code thông thường có thể giải quyết. Hầu hết các tác vụ lập trình truyền thống không cần một hội đồng gồm 5 người đánh giá.
- Không có ngân sách token. Các workflow tham vọng phình to gấp 5–10 lần những gì bạn mong đợi nếu không có giới hạn rõ ràng.
- Một agent làm cả công việc và xác minh. Sự thiên vị bản thân khiến người xác minh ưu ái người làm việc. Chúng phải tách biệt.
- Coi parallel() và pipeline() có thể thay thế cho nhau. Rào cản rất quan trọng - parallel chờ đợi tất cả, pipeline chảy theo luồng.
- Bỏ qua /goal trên các mẫu hình lặp. Workflow dừng sớm tại điểm hoàn thành mềm đầu tiên. /goal buộc hoàn thành cứng.
- Để nội dung không đáng tin cậy đến được agent hành động. Cách ly là không thể bỏ qua khi bạn xử lý bất cứ thứ gì do người dùng gửi.
- Sắp xếp bằng điểm số tuyệt đối. Phán đoán so sánh đáng tin cậy hơn. Sử dụng giải đấu.
- Không bao giờ lưu các workflow đang hoạt động. Yêu cầu lại cùng một hình dạng mỗi tuần. Lưu bằng s, phát hành dưới dạng Skill.
