Chiến Lược Phân Rã Nhiệm Vụ
Những điều bạn cần biết
Phân rã nhiệm vụ (task decomposition) là cách bạn chia nhỏ công việc phức tạp thành các phần có thể quản lý được cho một hệ thống agentic. Kỳ thi kiểm tra hai mẫu (pattern) riêng biệt và mong đợi bạn chọn đúng mẫu dựa trên đặc điểm của nhiệm vụ. Kỳ thi cũng kiểm tra một chế độ lỗi cụ thể — pha loãng chú ý (attention dilution) — xảy ra khi việc phân rã không đủ.
Mẫu 1: Pipeline Tuần Tự Cố Định (Prompt Chaining)
Pipeline tuần tự cố định chia công việc thành các bước được xác định trước, thực thi theo thứ tự. Mỗi bước lấy đầu ra của bước trước làm đầu vào.
Cách hoạt động: Quy trình làm việc được xác định trước. Bước 1 chạy, đầu ra của nó đưa vào Bước 2, đầu ra của Bước 2 đưa vào Bước 3, và cứ thế tiếp tục. Trình tự không thay đổi dựa trên kết quả trung gian.
Ví dụ — Pipeline review code:
- Với mỗi file, chạy một lượt phân tích cục bộ (style, lỗi, độ phức tạp).
- Sau khi tất cả các lượt cục bộ hoàn thành, chạy một lượt tích hợp liên file (luồng dữ liệu, tính nhất quán API, chuỗi import).
- Tổng hợp kết quả thành một báo cáo review thống nhất.
Phù hợp nhất cho: Các nhiệm vụ có thể dự đoán, có cấu trúc, nơi các bước đã được biết trước. Review code, xử lý tài liệu, pipeline trích xuất dữ liệu, và kiểm tra tuân thủ đều phù hợp với mẫu này.
Ưu điểm: Nhất quán và đáng tin cậy. Cùng một đầu vào luôn đi theo cùng một đường. Dễ debug — bạn biết chính xác bước nào tạo ra đầu ra nào. Dễ giám sát — bạn có thể ghi log đầu ra của từng bước.
Hạn chế: Không thể thích ứng với các phát hiện bất ngờ. Nếu Bước 2 phát hiện điều gì đó cần thay đổi cách tiếp cận cho Bước 3, pipeline không thể điều chỉnh. Các bước là cố định bất kể những gì được phát hiện trên đường đi.
Khái niệm chính
Pipeline tuần tự cố định (prompt chaining) phù hợp nhất cho các nhiệm vụ có thể dự đoán, có cấu trúc. Chúng mang lại tính nhất quán và độ tin cậy nhưng không thể thích ứng với các phát hiện bất ngờ trong quá trình thực thi.
Mẫu 2: Phân Rã Thích Ứng Động
Phân rã thích ứng động sinh ra các nhiệm vụ con dựa trên những gì được phát hiện ở mỗi bước. Kế hoạch phát triển khi agent tìm hiểu thêm về vấn đề.
Cách hoạt động: Agent bắt đầu với một mục tiêu cấp cao, thực hiện điều tra ban đầu, và sinh ra một kế hoạch dựa trên những gì nó tìm thấy. Khi thực thi kế hoạch, nó phát hiện thông tin mới có thể thay đổi các bước còn lại. Agent điều chỉnh kế hoạch tương ứng.
Ví dụ — Thêm test vào một codebase cũ (legacy):
- Lập bản đồ cấu trúc codebase (thư mục, module, phụ thuộc).
- Xác định các khu vực có tác động cao (module dùng nhiều nhất, module có nhiều lỗi nhất, các đường dẫn quan trọng chưa được test).
- Tạo một kế hoạch test được ưu tiên hóa dựa trên việc lập bản đồ.
- Bắt đầu viết test. Phát hiện Module A phụ thuộc vào Module B, vốn không có test nào.
- Ưu tiên lại: test Module B trước để test của Module A có thể dựa vào nó.
- Tiếp tục thích ứng khi các phụ thuộc và vấn đề mới xuất hiện.
Phù hợp nhất cho: Các nhiệm vụ điều tra mở, nơi phạm vi đầy đủ chưa được biết ngay từ đầu. Khám phá hệ thống cũ, kiểm toán bảo mật, dự án nghiên cứu, và debug các codebase không quen thuộc đều hưởng lợi từ mẫu này.
Ưu điểm: Thích ứng với vấn đề. Có thể phát hiện và phản ứng với độ phức tạp bất ngờ. Tạo ra kết quả kỹ lưỡng hơn cho các nhiệm vụ mở vì nó không ép buộc theo một kế hoạch định trước.
Hạn chế: Kém khả năng dự đoán hơn. Thời gian thực thi thay đổi tùy theo những gì được phát hiện. Khó ước tính thời gian hoàn thành hoặc mức sử dụng tài nguyên hơn. Khó debug hơn khi có sự cố xảy ra.
Chọn Đúng Mẫu
Kỳ thi kiểm tra khả năng khớp mẫu với nhiệm vụ của bạn:
| Đặc Điểm Nhiệm Vụ | Mẫu | Lý Do |
|---|---|---|
| Các bước đã biết trước, đầu vào có cấu trúc | Pipeline cố định | Tính nhất quán và độ tin cậy quan trọng hơn khả năng thích ứng |
| Mở, phạm vi chưa biết | Phân rã động | Khả năng thích ứng là thiết yếu khi vấn đề chưa được xác định đầy đủ |
| Review code nhiều file | Pipeline cố định | Phân tích theo từng file + tích hợp liên file là có thể dự đoán |
| Khám phá codebase cũ | Phân rã động | Các phụ thuộc và vấn đề xuất hiện trong quá trình điều tra |
| Trích xuất tài liệu | Pipeline cố định | Các trường và định dạng đã được xác định trước |
| Debug một hệ thống không quen thuộc | Phân rã động | Nguyên nhân gốc rễ chưa được biết; việc điều tra phải thích ứng |
Bẫy thi: Exam Trap
Kỳ thi có thể trình bày một pipeline cố định như giải pháp cho một nhiệm vụ điều tra mở, hoặc phân rã động cho một nhiệm vụ xử lý có cấu trúc. Hãy khớp mẫu với đặc điểm của nhiệm vụ, không phải với những gì nghe có vẻ tinh vi hơn.
Vấn Đề Pha Loãng Chú Ý
Pha loãng chú ý (attention dilution) là một chế độ lỗi cụ thể xảy ra khi một agent xử lý quá nhiều mục trong một lượt duy nhất. Kết quả là độ sâu không nhất quán — agent tạo ra phân tích kỹ lưỡng cho một số mục và bỏ sót các vấn đề rõ ràng ở những mục khác.
Các triệu chứng đặc trưng:
- Phản hồi chi tiết cho vài file đầu tiên, phân tích ngày càng hời hợt cho các file sau.
- Một mẫu (pattern) bị gắn cờ là có vấn đề trong một file trong khi mã giống hệt được chấp thuận trong một file khác.
- Các lỗi rõ ràng bị bỏ sót trong một số file trong khi các vấn đề style nhỏ lại được phát hiện ở những file khác.
Vì sao điều này xảy ra: Mô hình phân bổ sự chú ý trên tất cả các mục trong ngữ cảnh. Khi có quá nhiều mục, sự chú ý cho mỗi mục giảm xuống. Các mục đầu tiên nhận được sự chú ý không cân xứng; các mục sau bị lướt qua.
Cách khắc phục: Kiến trúc đa lượt (multi-pass). Chia công việc thành hai lớp:
- Các lượt phân tích cục bộ theo từng mục: phân tích từng file (hoặc tài liệu, hoặc module) riêng lẻ trong lượt riêng của nó. Mỗi lượt có toàn bộ ngân sách chú ý tập trung vào một mục duy nhất.
- Lượt tích hợp liên mục: sau khi tất cả các lượt cục bộ hoàn thành, chạy một lượt riêng biệt xem xét trên tất cả các mục để tìm các mối quan tâm xuyên suốt (vấn đề luồng dữ liệu, sử dụng mẫu không nhất quán, các phụ thuộc liên file).
Các lượt theo từng mục phát hiện các vấn đề cục bộ một cách nhất quán vì mỗi mục nhận được sự chú ý riêng. Lượt tích hợp phát hiện các vấn đề liên mục vì nó tập trung cụ thể vào các mối quan hệ giữa các mục thay vì cố gắng làm mọi thứ cùng một lúc.
Ví Dụ Thực Tế: Review 14 File Code
Một agent review code xử lý 14 file trong một lượt duy nhất. Kết quả:
- File 1-5: phản hồi chi tiết với tham chiếu dòng cụ thể, xác định lỗi, và đề xuất cải tiến.
- File 6-9: phản hồi vừa phải với một số vấn đề được xác định nhưng phân tích kém kỹ lưỡng hơn.
- File 10-14: phản hồi hời hợt bỏ sót các lỗi con trỏ null rõ ràng và lỗ hổng SQL injection.
- Một vòng lặp
forEachbị gắn cờ là kém hiệu quả trong File 3, trong khi mã giống hệt trong File 11 không nhận được bình luận nào.
Đây là pha loãng chú ý. Cách khắc phục không phải là một mô hình tốt hơn, một cửa sổ ngữ cảnh lớn hơn, hay một prompt chi tiết hơn. Cách khắc phục mang tính cấu trúc: chia thành 14 lượt phân tích theo từng file (mỗi lượt tập trung vào một file) cộng với một lượt tích hợp liên file (kiểm tra các vấn đề luồng dữ liệu và tính nhất quán mẫu trên tất cả các file).
Cách tiếp cận đa lượt phát hiện các lỗi con trỏ null trong File 10-14 (vì mỗi file nhận được lượt riêng dành cho nó) và xác định việc đánh giá forEach không nhất quán (vì lượt tích hợp kiểm tra cụ thể tính nhất quán mẫu liên file).
Bẫy thi
Bẫy thi: Suggesting a more powerful model or larger context window as the fix for attention dilution
Pha loãng chú ý là một vấn đề kiến trúc, không phải vấn đề khả năng của mô hình. Xử lý quá nhiều mục trong một lượt duy nhất tạo ra độ sâu không nhất quán bất kể sức mạnh mô hình hay kích thước ngữ cảnh. Cách khắc phục là kiến trúc đa lượt.
Bẫy thi: Proposing a single-pass review with better prompts as equivalent to multi-pass architecture
Prompt tốt hơn cải thiện chất lượng trung bình nhưng không giải quyết vấn đề phân bổ chú ý cơ bản. Kiến trúc đa lượt đảm bảo mỗi mục nhận được sự chú ý riêng, điều mà một cách tiếp cận một lượt duy nhất không thể đảm bảo.
Bẫy thi: Applying fixed pipelines to open-ended investigation tasks
Các nhiệm vụ mở đòi hỏi khả năng thích ứng. Pipeline cố định không thể phản ứng với các phát hiện bất ngờ. Phân rã thích ứng động là mẫu đúng khi phạm vi đầy đủ chưa được biết ngay từ đầu.
Bẫy thi: Batching files into groups without adding a cross-file integration pass
Việc gộp nhóm (batching) giảm pha loãng chú ý trong mỗi nhóm nhưng bỏ sót các vấn đề liên nhóm. Nếu không có một lượt tích hợp liên file riêng biệt, các vấn đề luồng dữ liệu và sự không nhất quán mẫu giữa các nhóm sẽ không bị phát hiện.
Tình huống luyện tập
Không tìm thấy câu hỏi luyện tập "q-1-6-001".
Bài tập thực hành
Xây Dựng Pipeline Review Code Đa Lượt
Bạn sẽ học được gì
- Vì sao pha loãng chú ý tạo ra độ sâu phân tích không nhất quán trên các file trong các review một lượt duy nhất
- Cách kiến trúc đa lượt (theo từng mục + liên mục) giải quyết vấn đề phân bổ chú ý mang tính cấu trúc
- Sự khác biệt giữa pipeline tuần tự cố định và phân rã thích ứng động
- Vì sao việc gộp nhóm mà không có lượt tích hợp liên file vẫn bỏ sót các vấn đề xuyên suốt
- Cách xác định các dấu vết pha loãng chú ý: cùng một mẫu bị gắn cờ trong một file, được chấp thuận trong file khác
Các bước
Vì sao: Ngưỡng 10+ file là nơi pha loãng chú ý trở nên có thể quan sát được. Kỳ thi sử dụng một ví dụ 14 file trong đó phản hồi chi tiết cho các file đầu tiên suy giảm thành phân tích hời hợt cho các file sau. Thiết lập của bạn phải tái tạo quy mô này.
Bạn sẽ thấy: Một hàm review code đọc tất cả các file trong một thư mục và chuẩn bị chúng để phân tích. Nó phải xử lý được ít nhất 10 file mã nguồn TypeScript hoặc JavaScript.
Vì sao: Cách tiếp cận một lượt duy nhất là cơ sở chứng minh pha loãng chú ý. Kỳ thi mong đợi bạn nhận ra các triệu chứng: phân tích kỹ lưỡng cho các file đầu tiên, phân tích hời hợt cho các file sau, và đánh giá mẫu mâu thuẫn.
Bạn sẽ thấy: Một kết quả review trong đó các file đầu tiên nhận được phản hồi chi tiết với tham chiếu dòng cụ thể và xác định lỗi, trong khi các file sau nhận được phản hồi ngày càng ngắn gọn hoặc thiếu sót. Đây là mẫu pha loãng chú ý.
Vì sao: Các lượt theo từng file cho mỗi file toàn bộ ngân sách chú ý. Đây là lớp đầu tiên của kiến trúc đa lượt. Kỳ thi đối chiếu điều này với một lượt duy nhất để cho thấy việc phân rã cấu trúc giải quyết pha loãng chú ý, chứ không phải prompt tốt hơn hay cửa sổ ngữ cảnh lớn hơn.
Bạn sẽ thấy: Độ sâu phân tích nhất quán trên tất cả các file. File cuối cùng nhận được cùng mức độ chi tiết như file đầu tiên. Mỗi review bao gồm số lượng lỗi, xếp hạng mức độ nghiêm trọng, và tham chiếu dòng cụ thể theo định dạng có cấu trúc.
Vì sao: Các lượt theo từng file phát hiện các vấn đề cục bộ nhưng bỏ sót các mối quan tâm xuyên suốt. Kỳ thi kiểm tra xem bạn có bao gồm một lượt tích hợp liên file hay không — việc gộp nhóm mà không có nó vẫn bỏ sót các vấn đề luồng dữ liệu và sự không nhất quán mẫu giữa các file.
Bạn sẽ thấy: Một phân tích riêng biệt lấy các bản tóm tắt theo từng file và kiểm tra các vấn đề liên file: sử dụng API không nhất quán, các vấn đề luồng dữ liệu giữa các module, và các mẫu được sử dụng khác nhau trên các file.
Vì sao: So sánh này chứng minh lập luận của kỳ thi một cách định lượng. Pha loãng chú ý không phải là vấn đề khả năng mô hình — đó là vấn đề kiến trúc. Cùng một mô hình tạo ra kết quả tốt hơn với kiến trúc đa lượt, chứng minh cách khắc phục mang tính cấu trúc.
Bạn sẽ thấy: Một bảng so sánh cho thấy: tổng số vấn đề phát hiện được nhiều hơn bởi đa lượt, số lượng vấn đề nhất quán trên các file (không có sự sụt giảm cho các file sau), và các vấn đề liên file chỉ được phát hiện bởi lượt tích hợp.
Vì sao: Việc đánh giá mẫu mâu thuẫn là triệu chứng rõ ràng nhất của pha loãng chú ý. Kỳ thi sử dụng ví dụ forEach: bị gắn cờ là kém hiệu quả trong File 3, được chấp thuận không bình luận trong File 11. Việc ghi lại các dấu vết này chứng minh bản chất cấu trúc của vấn đề.
Bạn sẽ thấy: Ít nhất một trường hợp trong đó review một lượt duy nhất xử lý các mẫu mã giống hệt nhau khác nhau trên các file. Review đa lượt nên xử lý cùng một mẫu một cách nhất quán.
Nguồn tham khảo
- Claude Agent SDK Overview — Anthropic
- Claude Code in Action (Skilljar) — Anthropic
- Anthropic Prompt Engineering Guide — Anthropic