Một Đội Claude Cho Một Nhiệm Vụ: Khám Phá Tính Năng Dynamic Workflows

Một Đội Claude Cho Một Nhiệm Vụ: Khám Phá Tính Năng Dynamic Workflows

Trong hầu hết năm 2024 và 2025, giải pháp mặc định cho các tác vụ AI phức tạp rất đơn giản: giao toàn bộ việc cho một tác nhân duy nhất, sử dụng cửa sổ ngữ cảnh (context window) lớn nhất có thể và chờ đợi. Đôi khi nó hoạt động, nhưng thường thì mô hình sẽ "mất mạch" giữa chừng.

Anthropic đã chỉ ra vấn đề này một cách trực diện: các nhiệm vụ dài hạn yêu cầu tác nhân phải duy trì sự mạch lạc qua nhiều bước, thường vượt quá khả năng hỗ trợ đáng tin cậy của một cửa sổ ngữ cảnh. Việc mở rộng cửa sổ giúp ích một phần, nhưng không giải quyết triệt để gốc rễ vấn đề.

Khi một "cái đầu" không đủ

Dù là một tác nhân đơn lẻ hay một tác nhân chính điều phối một đội nhỏ, việc gán toàn bộ trách nhiệm cho một ngữ cảnh duy nhất thường dẫn đến ba chế độ thất bại phổ biến:

1. Sự lười biếng của tác nhân (Agentic laziness): Nó bắt đầu nhiệm vụ nhưng không hoàn thành đầy đủ. Có thể dừng sớm, bỏ qua một số tệp hoặc giả định phần việc còn lại tương tự nhau, sau đó tự tin báo cáo đã xong.
2. Thiên kiến tự ưu (Self-preferential bias): AI không quá nghiêm ngặt khi đánh giá kết quả của chính mình. Nếu hỏi "Bạn có làm theo hướng dẫn không?", nó thường nói có vì có xu hướng nghiêng về lợi ích nghi ngờ cho bản thân.
3. Lạc mục tiêu (Goal drift): Trong các nhiệm vụ dài, AI dần quên mục tiêu ban đầu, quên các chi tiết quan trọng như "không bao gồm X", "không bỏ qua tệp nào" hay "chỉ dùng định dạng này".

Đây không phải là lỗi, mà là hệ quả tự nhiên khi kế hoạch chỉ là một "ý nghĩ" trong đầu mô hình, và ý nghĩ thì sẽ bị suy giảm theo thời gian.

Sơ đồ so sánh Subagents, Agent Teams và Dynamic Workflow

Dynamic Workflows: Chuyển kế hoạch từ "đầu" sang "mã"

Đây chính là vấn đề mà Dynamic Workflows của Claude giải quyết. Thay vì để Claude giữ toàn bộ kế hoạch trong đầu, Dynamic Workflows chuyển kế hoạch đó vào code.

Một "harness" (khung kiểm soát) là mã đáy bao quanh mô hình: phần quyết định cách một tác vụ được lập kế hoạch, chia nhỏ, kiểm tra và thực thi. Khác với các khung tĩnh (static harness) được xây sẵn, Dynamic Harness do Claude tự viết ngay tại thời điểm bạn yêu cầu, được tùy chỉnh riêng cho nhiệm vụ đó.

Trong Dynamic Workflow, kế hoạch nằm trong một tệp chương trình (thường là JavaScript). Các tác nhân con làm việc riêng biệt, kết quả đầu ra của họ được lưu trong biến, và chỉ có kết quả tổng hợp cuối cùng mới được trả về cho bạn.

Sự khác biệt chính nằm ở câu hỏi: "Ai giữ kế hoạch?"

• Subagent (Tác nhân phụ): Kế hoạch nằm ở Claude chính (người điều phối).
• Agent team (Đội tác nhân): Kế hoạch nằm giữa các đồng nghiệp ngang hàng.
• Dynamic Workflow: Kế hoạch nằm trong code (JavaScript).

6 Mẫu thiết kế phổ biến trong Dynamic Workflows

Anthropic giới thiệu 6 mẫu workflow chính, nhưng nổi bật nhất là hai mẫu:

1. Phân tán và Tổng hợp (Fan-out-and-synthesize)

Chia nhỏ công việc, sau đó hợp nhất chúng. Mỗi phần việc được giao cho một tác nhân với ngữ cảnh sạch sẽ; một bộ tổng hợp chờ tất cả hoàn thành mới kết hợp kết quả.

Sơ đồ mô tả quy trình Fan-out-and-synthesize

2. Xác minh đối kháng (Adversarial verification)

Với mọi phát hiện, sinh ra một tác nhân riêng có nhiệm vụ bác bỏ nó. Một người hoài nghi kiểm tra những gì người lạc quan tìm ra.

Sơ đồ mô tả quy trình Adversarial verification

Thử nghiệm thực tế: Kiểm toán kho mã (Repo Audit)

Để hiểu rõ sức mạnh của Dynamic Workflows, chúng ta hãy xem xét bài toán kiểm toán một kho chứa mã nguồn nhiều tệp.

Cách tiếp cận mặc định là yêu cầu Claude: "audit the repo with a workflow: fan out finders and verify each finding, synthesize a severity-ranked report." (Kiểm toán kho bằng workflow: phân tán các tác nhân tìm kiếm và xác minh mỗi phát hiện, tổng hợp báo cáo xếp mức độ nghiêm trọng).

Claude sẽ tự động tạo ra workflow với 3 giai đoạn: Find (Tìm kiếm) -> Verify (Xác minh) -> Synthesis (Tổng hợp).

Chi phí và Hiệu quả: Opus vs. Sonnet vs. Haiku

Một bài học quan trọng khi sử dụng Dynamic Workflows là tối ưu hóa chi phí mô hình.

• Người điều phối (Orchestrator) và Bộ tổng hợp (Synthesizer): Nên dùng mô hình mạnh nhất (Opus 4.8) vì chúng phải thiết kế workflow, chia task và tổng hợp kết quả phức tạp.
• Tác nhân tìm kiếm/xác minh (Agents): Có thể dùng các mô hình rẻ hơn như Sonnet hoặc Haiku.

Thử nghiệm cho thấy việc sử dụng Haiku cho các tác nhân tìm kiếm không hẳn đã rẻ hơn. Dù giá token thấp hơn, Haiku lại cần nhiều bước tư duy hơn (tiêu thụ nhiều token hơn) để đạt được kết quả tương tự Sonnet. Do đó, một mô hình nhỏ hơn không tự động rẻ hơn trong thực tế.

So sánh với Tác nhân đơn lẻ

Khi chạy cùng một kho mã với một tác nhân đơn lẻ (không dùng team, không xác minh), nó tìm thấy nhiều vấn đề hơn (47 so với 44 của workflow) nhưng với ít token hơn một phần ba. Tuy nhiên, do không có bước xác minh đối kháng, tác nhân đơn lẻ đã bỏ sót một số kết quả sai mà workflow đã bắt được.

Nếu bạn ưu tiên độ phủ thô và tự rà soát lại, tác nhân đơn lẻ là lựa chọn kinh tế hơn. Nhưng nếu cần độ chính xác cao và xác thực chéo, Dynamic Workflow là lựa chọn vượt trội.

Khi nào nên sử dụng Dynamic Workflow?

Dynamic Workflows tiêu tốn nhiều token hơn một phiên Claude Code bình thường, do đó bạn không nên dùng cho mọi tác vụ. Dưới đây là các tín hiệu để quyết định:

1. Tác vụ có thể chia nhỏ: Nếu mỗi tác nhân phụ thuộc vào đầu ra của tác nhân khác, lợi ích của song song hóa sẽ bị giảm.
2. Tác vụ đủ lớn để cần nhiều ngữ cảnh: Workflows shine brightest khi công việc quá lớn cho một cửa sổ ngữ cảnh.
3. Cần xác minh (Verification): Khi câu trả lời sai gây tốn kém (ví dụ: lỗ hổng bảo mật, báo cáo lỗi giả), việc dùng thêm tác nhân để kiểm tra chéo là đáng giá.
4. Tác vụ mang tính xác định (Deterministic): Workflow hoạt động tốt khi tác vụ có hình dạng rõ ràng và có thể chia thành các bước biết trước. Nó phù hợp với các tác vụ "rộng" (wide) hơn là các tác vụ "sâu" (deep) tuần tự.

Kết luận

Dynamic Workflows là bước nhảy vọt trong việc sử dụng AI, biến Claude từ một trợ lý đơn lẻ thành một người quản lý dự án tự động, có thể viết mã điều phối (harness) ngay lập tức để giải quyết vấn đề.

Để bắt đầu, bạn chỉ cần thêm từ khóa "workflow" vào câu lệnh của mình hoặc chuyển chế độ nỗ lực (effort) thành ultracode. Tuy nhiên, hãy nhớ dùng chúng khôn ngoan: chỉ khi lợi ích của việc song song hóa và xác minh chéo vượt quá chi phí token tiêu tốn.

Ví dụ câu lệnh (Prompt) tham khảo:

• Kiểm tra kế hoạch kinh doanh: "Lấy kế hoạch dưới đây và chạy workflow nơi các tác nhân riêng biệt chỉ trích nó — một nhà đầu tư hoài nghi, một khách hàng khó tính, một đối thủ cạnh tranh — mỗi người độc lập. Sau đó tổng hợp ba phản đối sắc bén nhất và câu trả lời mạnh mẽ nhất cho từng cái."
• Kiểm toán kho mã: "Chạy workflow để kiểm toán repository này. Phân tán tác nhân cho lỗi logic, route không an toàn, xác thực yếu, bị lộ secret, dependency rủi ro. Với mỗi phát hiện, sinh một tác nhân để xác minh đối kháng — cố gắng chứng minh nó không thật. Tổng hợp báo cáo xếp mức độ nghiêm trọng. Dùng Sonnet cho các tác nhân và Opus cho người điều phối."