How we built our multi-agent research system

Anthropic · 2025 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bài về tính năng Research của Claude. Phần prompt và đánh giá mô hình được tóm tắt ngắn; wiki giữ phần kiến trúc và vận hành. Số liệu do Anthropic tự đo.

Bối cảnh

• Nghiên cứu là bài toán mở, không đoán trước được các bước, nên không viết cứng một pipeline được. Theo Anthropic, bản chất của search là nén: các subagent chạy song song, mỗi cái một context window riêng, rồi cô đặc phần quan trọng gửi về agent chính.

Thay đổi chính

• Orchestrator-worker: agent chính phân tích câu hỏi, lập chiến lược, sinh subagent song song để khám phá từng hướng, rồi tổng hợp. Khác RAG tĩnh (lấy một lần các đoạn giống nhất) ở chỗ tìm nhiều bước và điều chỉnh theo phát hiện.
• Hiệu quả và giá: theo đánh giá nội bộ, Opus 4 làm agent chính + Sonnet 4 làm subagent tốt hơn một agent Opus 4 đơn lẻ 90,2%. Trên BrowseComp, ba yếu tố giải thích 95% khác biệt hiệu năng, riêng lượng token đã dùng giải thích 80%. Đổi lại agent dùng khoảng 4 lần token so với chat, hệ nhiều agent khoảng 15 lần; chỉ đáng dùng cho tác vụ đủ giá trị, và kém với việc cần chia sẻ chung một ngữ cảnh hay phụ thuộc chặt (như phần lớn việc viết code).
• Điều khiển hành vi bằng prompt và công cụ: bản đầu sinh 50 subagent cho câu hỏi đơn giản, tìm mãi nguồn không tồn tại. Họ dạy agent chính giao việc rõ (mục tiêu, định dạng, công cụ, ranh giới), đặt quy tắc tỉ lệ công sức theo độ khó, thiết kế mô tả công cụ cẩn thận (có agent tự viết lại mô tả công cụ lỗi: thời gian hoàn thành giảm 40% với các agent sau), gọi công cụ song song (thời gian nghiên cứu giảm tới 90% với câu hỏi phức tạp).
• Đánh giá: bắt đầu ngay với khoảng 20 câu hỏi thật vì hiệu ứng lúc đầu rất lớn; LLM-as-judge theo rubric; người thử phát hiện điều tự động bỏ sót (agent ưa trang SEO hơn nguồn học thuật).

Vận hành ở production

• Agent có trạng thái và lỗi cộng dồn: chạy lâu qua nhiều lần gọi công cụ; khởi động lại từ đầu thì tốn kém và khó chịu, nên họ làm hệ tiếp tục từ chỗ agent đang dừng khi có lỗi, và báo cho agent biết công cụ đang hỏng để nó tự xoay xở.
• Gỡ lỗi: agent không tất định giữa các lần chạy; thêm tracing production đầy đủ (theo dõi mẫu quyết định và tương tác, không giám sát nội dung hội thoại) để biết vì sao agent thất bại.
• Deploy: hệ là mạng prompt, công cụ, logic chạy gần như liên tục, agent có thể đang ở bất kỳ bước nào khi deploy; họ dùng rainbow deployment, chuyển traffic dần từ phiên bản cũ sang mới và để cả hai chạy song song, thay vì cập nhật mọi agent cùng lúc.
• Nút thắt đồng bộ: agent chính chờ cả lượt subagent xong mới đi tiếp, nên không điều hướng được giữa chừng và cả hệ có thể chờ một subagent chậm; chạy bất đồng bộ sẽ thêm khó về phối hợp, nhất quán trạng thái và lan truyền lỗi.
• Mẹo thêm: subagent ghi kết quả ra hệ file/artifact rồi chỉ trả tham chiếu, tránh "tam sao thất bản" qua agent chính; hội thoại dài thì tóm tắt từng chặng và lưu vào bộ nhớ ngoài.

Bài học cho SWE

• Theo Anthropic, "dặm cuối" từ prototype tới production chiếm phần lớn công sức; lỗi nhỏ trong phần mềm thường có thể đẩy agent sang quỹ đạo hoàn toàn khác.
• Tiến trình sống lâu có trạng thái cần cơ chế tiếp tục sau lỗi và chiến lược deploy để hai phiên bản cùng chạy.
• Song song hoá đổi thời gian lấy chi phí; quyết định dùng nhiều agent là quyết định kinh tế.

Liên quan

• Anthropic 2026 (hạ tầng chạy agent, tách vòng lặp khỏi sandbox) · Anthropic 2025
• Deploy và release an toàn · Tracing phân tán và log theo request