Làm thế nào để sử dụng Dynamic Workflows của Claude cho nghiên cứu chuyên sâu

Trong ba năm qua, tôi đã không thể thiếu việc sử dụng AI để hỗ trợ nghiên cứu ngành, thậm chí còn xây dựng một loạt các skill và hệ thống hỗ trợ để giải quyết việc sàng lọc, tổng hợp, kết nối, xác minh và lưu trữ thông tin.

Cho đến tuần này, sau khi trải nghiệm sâu sắc quy trình làm việc động (Dynamic Workflows) của Claude Code, tôi mới hiểu được ý nghĩa thực sự của câu nói "con người đừng chống lại xu thế của thời đại".

Suy nghĩ lại một lần nữa: Nghiên cứu chuyên sâu mà con người nên làm trong kỷ nguyên AI là gì, và làm thế nào để xây dựng mối quan hệ cộng tác bổ trợ giữa tôi và AI.

I. Bắt đầu từ cạm bẫy của việc nghiên cứu

Thực hiện nghiên cứu kỹ thuật thực chất là một việc đầy cạm bẫy (dù là với con người hay AI), bởi vì ngay từ khi bắt đầu nghiên cứu, chúng ta sẽ tiếp nhận một lượng lớn thông tin, càng ngày càng có nhiều quan điểm, và kết luận càng ngày càng mơ hồ. Vì vậy, luôn phải biết quay trở lại với mục tiêu ban đầu.

Đây cũng chính là điểm mà AI từ lâu vẫn chưa đủ tốt, bởi vì từ góc nhìn của sự chú ý và liên tưởng, nó sẽ bị mắc kẹt trong khối lượng thông tin hiện tại hơn con người, và khả năng liên kết chéo thực sự có giá trị giữa các lĩnh vực còn rất yếu.

Tất nhiên, điểm mạnh của AI nằm ở khả năng thực thi, nó có thể hoạt động như một tác nhân (agent) để từng lớp tìm kiếm, tổng hợp và kết luận, hoàn toàn có thể tránh được sự hao tổn về chi tiết.

Mặc dù nửa năm nay tôi ít đăng bài trên WeChat Official Account, nhưng hầu hết các lĩnh vực chiến trường chính thống trong ngành, tôi đều đang theo dõi và nghiên cứu toàn diện. Và thứ hỗ trợ cho quá trình đầu vào và đầu ra này chính là một hệ thống deep-research của riêng tôi.

Và đối mặt với tính năng Dynamic Workflows mà Claude Code vừa ra mắt tuần trước, tôi muốn thử thách nó một chút, xem khả năng mặc định của nó có thể hoàn toàn vượt qua hệ thống của tôi hay không.

II. Dynamic Workflows là gì?

Dynamic Workflows (Quy trình làm việc động) có ý tưởng cốt lõi là: Trước khi thực hiện một nhiệm vụ, AI sẽ tự động thiết kế xem nên sử dụng quy trình làm việc nào để hoàn thành nhiệm vụ đó, sau đó mới bắt đầu thực thi.

Điều này khác biệt về bản chất so với "chế độ lập kế hoạch" và "skill" mà chúng ta đã từng sử dụng. Chế độ lập kế hoạch chỉ đơn thuần chia nhỏ nhiệm vụ, nhưng không nhất thiết phải tuân theo một quy trình làm việc hợp lý nào. Chỉ khi bạn sắp xếp các prompt, nó mới có thể thêm các tiêu chí kiểm tra (điều này cực kỳ quan trọng đối với Research), và cũng vậy, chỉ khi bạn có prompt, nó mới có thể thiết lập trước một số quy tắc harness tốt hơn.

Nhưng quy trình làm việc động sẽ tự động tích hợp logic xác nhận, hội tụ kết quả, xác minh đối kháng và những thứ tương tự vào trong đó.

Cách kích hoạt rất đơn giản, chỉ cần sử dụng /deep-research trong cc, sau đó cung cấp một số mẫu nghiên cứu và tài liệu đầu vào. Nếu muốn sử dụng riêng khả năng quy trình làm việc động, hãy sử dụng prompt hoặc nói trực tiếp "ultracode". Lưu ý trước khi sử dụng, mức tiêu thụ token sẽ cao gấp hàng chục lần bình thường.

III. Sáu chế độ quy trình làm việc được tích hợp sẵn

Nền tảng của quy trình làm việc động là sáu chế độ điều phối cốt lõi đã được nhóm phát triển tổng kết. Đây là lý do tại sao nó mạnh hơn so với các cuộc hội thoại / agent / skill thông thường.

Trên thực tế, đằng sau sáu chế độ này chỉ có hai vấn đề cốt lõi: Làm thế nào để chia nhỏ nhiệm vụ? Làm thế nào để tổng hợp kết quả? Sáu chế độ về bản chất là sự kết hợp và sắp xếp của hai yếu tố này.

3.1 Chế độ định tuyến (Classify-And-Act)

Đầu tiên, một agent sẽ phân loại loại nhiệm vụ, sau đó phân phối nhiệm vụ cho agent chuyên biệt phù hợp nhất để thực hiện. Logic cốt lõi là logic lựa chọn định tuyến, chứ không phải song song hay lặp lại. Một nhiệm vụ chỉ đi theo một con đường duy nhất, các con đường khác hoàn toàn không được thực thi.

Ví dụ, tôi có thể thiết lập sẵn ba vai trò subagent: một agent phân tích chuyên xác minh dữ liệu chặt chẽ, một agent xuất bản giỏi viết lách, và một agent thách thức chuyên tìm lỗ hổng. Lớp định tuyến sẽ quyết định nhiệm vụ phụ hiện tại phù hợp để giao cho ai, thay vì để một agent làm tất cả.

Giá trị của chế độ này nằm ở: sự chính xác và tiết kiệm. Prompt của mỗi agent có thể độc lập ở mức độ cao, không bị can thiệp bởi các mục tiêu khác, hình thành sự khám phá theo chiều sâu theo chiều dọc. Mức tiêu thụ token thấp nhất, tốc độ phản hồi nhanh nhất. Ranh giới trách nhiệm rất rõ ràng.

Nhược điểm cũng rất rõ ràng, khả năng xử lý các nhiệm vụ có ranh giới mơ hồ (ví dụ "vừa là vấn đề kỹ thuật vừa là vấn đề tài khoản") còn yếu.

3.2 Phân tách và hợp nhất (Fan-out & Merge)

Đây cũng là chế độ tôi thường dùng nhất. Logic cốt lõi là song song + hợp nhất. Nhiệm vụ được chia thành N nhiệm vụ phụ độc lập chạy đồng thời, sau khi tất cả hoàn thành sẽ được hợp nhất thống nhất.

Ưu điểm nằm ở tốc độ và sự cách ly. Tổng thời gian thực hiện gần bằng nhiệm vụ phụ chậm nhất, chứ không phải tổng thời gian của tất cả các nhiệm vụ phụ. Mỗi nhiệm vụ phụ có ngữ cảnh độc lập, không ảnh hưởng lẫn nhau, và nhiễu từ một nhiệm vụ phụ sẽ không làm ô nhiễm các nhiệm vụ phụ khác.

Điểm yếu là chi phí token cao gấp N lần so với xử lý tuần tự, và bản thân lớp tổng hợp (Synthesize) cũng có độ khó nhất định — làm thế nào để hợp nhất đầu ra từ N luồng không đồng nhất về cấu trúc là một thách thức thiết kế. Việc phân chia nhiệm vụ phụ không tốt có thể dẫn đến thiếu sót hoặc trùng lặp bao phủ.

3.3 Xác minh đối kháng (Adversarial Verification)

Logic cốt lõi là kiểm tra. Đối với cùng một kết luận, hãy để nhiều agent thách thức từ góc độ "phản bác", chỉ khi quá nửa số phiếu đồng ý mới được thông qua.

Ưu điểm là vì Verifier không biết logic của Worker, chỉ nhìn vào kết quả, nên về mặt cấu trúc đã loại bỏ được sự sai lệch tự đánh giá khi "yêu cầu mô hình kiểm tra chính mã do nó viết".

Chế độ này giải quyết một vấn đề đã làm tôi đau đầu từ lâu: Chúng ta thường trò chuyện với AI bằng ngôn ngữ thông tục, nhưng AI có xu hướng trả lời theo kỳ vọng của bạn, dễ tạo ra "thiên kiến xác nhận". Thông qua xác minh đối kháng, AI buộc phải tìm kiếm các phản ví dụ, xác minh dựa trên dữ liệu và thí nghiệm, thay vì chỉ chiều theo suy nghĩ của bạn.

Tuy nhiên, trong việc xác minh, nếu nó đưa ra nhận định sai, nó có thể dẫn dắt Worker sai lệch, để Worker phải chiều theo Verifier. Vì vậy, tốt nhất nên dựa trên các sự kiện có thể tái tạo, thay vì dựa trên quan điểm.

Nói đùa một chút, nếu bạn để AI tìm vấn đề, nó có thể tìm ra vô số vấn đề, vì vậy bạn phải giới hạn phạm vi tìm kiếm vấn đề cho nó.

3.4 Tạo và lọc (Generate & Filter)

Logic cốt lõi là phân kỳ rồi hội tụ. Đầu tiên cố tình tạo ra quá nhiều ứng viên, sau đó sử dụng rubric để loại bỏ chỉ giữ lại tinh hoa, chỉ xuất ra các kết quả có độ tin cậy cao.

Thay vì để một agent đưa ra một câu trả lời "tàm tạm", tốt hơn là để nó tạo ra mười câu trả lời, sau đó sử dụng lớp xác minh để sàng lọc. Do đó, ưu điểm nằm ở tính đa dạng. Nhiều Generator có thể sử dụng các chiến lược khác nhau, prompt khác nhau để tạo ra các giải pháp mà con người khó có thể tưởng tượng trước, và bước lọc giúp chất lượng đầu ra cuối cùng tập trung ở mức cao.

Điểm yếu là chất lượng của rubric Filter quyết định trực tiếp đến hiệu quả cuối cùng, nếu thiết kế rubric sai thì toàn bộ quy trình coi như hỏng.

Phù hợp với các tình huống không biết trước câu trả lời đúng, cần chọn lọc từ nhiều khả năng, hoặc có yêu cầu rõ ràng về tính đa dạng.

Chỉ giống Fanout-And-Synthesize ở bề ngoài: Cả hai đều là "đa luồng song song → đầu ra duy nhất", dễ bị nhầm lẫn nhất.

Sự khác biệt chính nằm ở mục đích: Mỗi luồng của Fanout xử lý một phần khác nhau của nhiệm vụ, kết quả mang tính bổ trợ, khi hợp nhất tất cả các luồng đều có đóng góp; Mỗi luồng của Generate-And-Filter xử lý cùng một nhiệm vụ, kết quả mang tính cạnh tranh, khi hợp nhất hầu hết sẽ bị loại bỏ. Cái trước là "ghép hình", cái sau là "chọn hoa hậu".

3.5 Chế độ giải đấu (Tournament)

Logic cốt lõi là cạnh tranh và loại trừ. N agent mỗi cái độc lập làm cùng một việc, thông qua so sánh theo cặp để loại trừ dần dần qua từng vòng, cuối cùng chọn ra giải pháp tốt nhất.

Trước đây tôi đã từng làm thủ công việc này — chạy hai ba phiên bản cho cùng một thay đổi mã, sau đó để AI so sánh xem phiên bản nào tốt hơn. Bây giờ có thể tích hợp trực tiếp vào quy trình làm việc.

Ưu điểm nằm ở sự ổn định trong đánh giá. So sánh từng cặp ("A và B cái nào tốt hơn?") ổn định hơn nhiều so với chấm điểm tuyệt đối ("cho A điểm"), vì nó loại bỏ được vấn đề tiêu chuẩn chấm điểm bị trôi. Kết quả trải qua nhiều vòng cạnh tranh, độ tin cậy của người chiến thắng cuối cùng cao.

Cũng chỉ gi