HungPH Blog Logo
Series
Claude Certified Architect - Professional Prep Course
Kỹ Thuật & Công Nghệ28 tháng 9, 2026•3 phút đọc•33 lượt xem

Khi cơ chế fan-out ẩn đi một đơn vị công việc bị bỏ sót

Một đội ngũ tuân thủ (compliance team) đã xây dựng một multi-agent system để kiểm tra một hợp đồng nhà cung cấp gồm 50 điều khoản so với danh mục kiểm tra chính sách nội bộ. Orchestrator đã thực hiện fan-out công việc tới mỗi subagent cho từng điều khoản, mỗi subagent trả về kết quả đánh giá pass/flag (đạt/gắn cờ), và tổng hợp (synthesized) thành một bản tóm tắt gọn gàng: "Đã xem xét 48 điều khoản, 3 điều khoản bị gắn cờ." Bản tóm tắt trông có vẻ hoàn chỉnh và được chuyển tới trưởng nhóm pháp lý. Tuy nhiên, có 2 điều khoản chưa từng được xem xét. Một subagent đã bị timeout và không trả về gì cả; một subagent khác thất bại trong việc phân tích (parse) một trang tài liệu dạng ảnh quét (scanned page) và trả về kết quả rỗng. Do không có cơ chế coverage check (kiểm tra độ bao phủ), orchestrator chỉ đếm các kết quả mà nó nhận được và báo cáo "đã xem xét 48", trong khi hợp đồng có 50 điều khoản và không có quy định nào yêu cầu bước tổng hợp (synthesis) phải đối soát lại (reconcile) số lượng.

Điều gì đã đổ vỡ và tại sao

  • Không có coverage check ở bước tổng hợp: Orchestrator chỉ tổng hợp trên các kết quả mà nó vô tình nhận được, không có quy tắc nào bắt buộc số lượng kết quả nhận về phải bằng đúng số lượng đơn vị công việc đã phát đi (units dispatched).

  • Thất bại có thể khôi phục (recoverable failure) lại không bao giờ được khôi phục: Một subagent bị timeout là trường hợp hoàn toàn có thể khôi phục được, nhưng chỉ khi có cơ chế thử lại (retry) hoặc gắn cờ cảnh báo khoảng trống. Ở đây, sự cố diễn ra trong im lặng vì không có thành phần nào giám sát ranh giới đó.

  • Tổng hợp tự tin trên một kết quả chưa hoàn chỉnh: Sự trôi chảy của đầu ra đã che đậy khoảng trống dữ liệu. Một multi-agent system thất bại nguy hiểm nhất là khi bản tóm tắt trông có vẻ rất hoàn chỉnh nhưng thực chất lại không phải.

Tại sao thiết kế này thất bại?

  • Tính đầy đủ được mặc định chứ không được xác minh (Completeness was assumed, not verified): Orchestrator đã gửi đi 50 đơn vị công việc và chỉ báo cáo dựa trên các kết quả nhận về. 2 đơn vị không bao giờ quay trở lại, và không có gì trong thiết kế nhận ra sự chênh lệch đó.

  • Số lượng không bao giờ được đối soát (reconciled): Bước synthesis chỉ đơn thuần cộng các đánh giá nhận được và dừng lại ở đó. Không có quy tắc nào yêu cầu số kết quả trả về phải khớp với số đơn vị đã gửi đi, do đó 48 kết quả trả về nghiễm nhiên biến thành "48 điều khoản đã xem xét" thay vì "đang thiếu 2 điều khoản".

  • Thất bại có thể khôi phục lại không có thành phần nào theo dõi: Việc subagent bị timeout hay kết quả parse rỗng đều là những trường hợp có thể khôi phục được (recoverable case), nhưng chỉ khi có thành phần thực hiện retry hoặc báo cờ. Không thành phần nào chịu trách nhiệm quản lý ranh giới subagent, nên cả hai lỗi đều trôi qua một cách lặng lẽ.

  • Đầu ra tạo cảm giác hoàn chỉnh: Bản tóm tắt trôi chảy và đúng định dạng – chính điều đó lại làm cho lỗ hổng trở nên vô hình.

Giải pháp: Thêm một bước coverage check tại giai đoạn synthesis: số kết quả trả về bắt buộc phải bằng số đơn vị công việc đã gửi đi, nếu không hệ thống phải gắn cờ báo lệch trước khi bất kỳ ai đọc bản tóm tắt đó.

Bản quyền & Nguồn tài liệu gốc

Nội dung bài viết thuộc lộ trình chuẩn bị chứng chỉ Claude Certified Architect, được tổng hợp và biên dịch từ tài liệu đào tạo chính thức của Anthropic PBC. Bản quyền nội dung gốc thuộc về Anthropic PBC. Bản dịch tiếng Việt và chú giải thực hành bởi HungPH Blog.

pochiro1996

Thành viên gia nhập từ 19/09/2026

Bình luận (0)

Hỗ trợ bình luận văn minh và tôn trọng quan điểm đa chiều.
Đang tải bình luận...
0% • Lên đầu trang