Workflow hay agent, và khi nào chia cho subagent

Nhiều đội bắt đầu bằng câu "mình làm một agent cho việc này", trong khi việc đó chỉ cần vài bước viết sẵn trong code. Ngược lại, có việc mà quy trình cố định cứ gãy mãi vì không đoán trước được bước nào sẽ cần.

Bài này giúp bạn trả lời: khi nào dùng workflow, khi nào dùng agent, và khi nào nên chia một agent thành nhiều agent?

Ví dụ xuyên suốt: trường dạy lái xe nhận hồ sơ đăng ký

Một trường dạy lái xe nhận khoảng 300 hồ sơ đăng ký học mỗi tháng qua biểu mẫu trên web. Đường đi thông thường của một hồ sơ:

1. Đọc biểu mẫu và ảnh giấy tờ đính kèm (căn cước, giấy khám sức khoẻ).
2. Kiểm hồ sơ đã đủ giấy tờ cho hạng bằng đăng ký chưa.
3. Xếp vào lớp còn chỗ theo hạng bằng và ca học.
4. Gửi email xác nhận kèm lịch học.

Khoảng một phần mười hồ sơ không đi theo đường này: ảnh giấy khám bị mờ, học viên đã có bằng B muốn học lên C1, hoặc ghi chú "tôi chỉ học được tối thứ Bảy". Những hồ sơ này cần ai đó đọc kỹ rồi quyết định: xin bổ sung giấy tờ, xếp lớp đặc biệt, hay chuyển cho giáo vụ.

Ai quyết định bước tiếp theo

Bài viết "Building effective agents" của Anthropic chia hệ thống dùng LLM thành hai loại:

• Workflow: LLM và tool được điều phối theo đường đi viết sẵn trong code. Code của bạn quyết định bước tiếp theo.
• Agent: LLM tự điều khiển quá trình làm và tự chọn tool, quyết định cách hoàn thành việc. Model quyết định bước tiếp theo.

Lời khuyên của bài viết là tìm giải pháp đơn giản nhất có thể, chỉ thêm độ phức tạp khi cần, kể cả khi điều đó nghĩa là không làm agent. Hệ thống agent thường đổi độ trễ và chi phí lấy kết quả tốt hơn. Bạn có thể hình dung một cái thang:

Agent tự chủ nên tốn hơn, và lỗi có thể chồng lên nhau qua nhiều bước. Bài viết khuyên thử kỹ trong môi trường sandbox và có guardrail phù hợp trước khi giao việc cho agent.

Trong ví dụ, chín phần mười hồ sơ đi đúng bốn bước biết trước, nên làm workflow: dễ test, chạy giống nhau mỗi lần. Chỉ ở chỗ "hồ sơ lạ" mới cần một agent đọc hồ sơ và chọn giữa ba hướng xử lý.

1. Các bước biết trước và không đổi?Workflow, các bước viết trong code
2. Đường chính biết trước, chỉ vài chỗ cần phán đoán?Workflow cho đường chính, gọi agent ở điểm quyết định
3. Không đoán được cần mấy bước, bước nào?Agent, có giới hạn số vòng và guardrail
4. Còn lạiMột lần gọi model là đủ

Manager/supervisor: orchestrator giao việc cho subagent

Khi một agent phải lo nhiều mảng, cách phổ biến là dựng một tầng quản lý. Đề thi gọi đây là cấu trúc manager/supervisor; tài liệu Anthropic gọi là orchestrator-workers hay orchestrator và subagent. Một agent chính (orchestrator, lead agent) đọc yêu cầu, chia thành việc nhỏ, giao cho các subagent, rồi gộp kết quả.

Mùa cao điểm, trường lái xe muốn thêm trợ lý trả lời học viên. Câu hỏi của học viên thường dính ba mảng: học phí và trả góp, lịch học và sân tập, trạng thái hồ sơ thi sát hạch. Thiết kế:

• Orchestrator đọc câu hỏi, xác định mảng nào liên quan, giao cho subagent tương ứng, rồi gộp thành một câu trả lời.
• Mỗi subagent có system prompt riêng và chỉ có tool của mảng mình: subagent học phí có tra_hoc_phi, subagent lịch có tra_lich_san, subagent hồ sơ có tra_ho_so.
• Mỗi subagent chạy trong context riêng (isolated context): không thấy hội thoại của orchestrator hay của subagent khác. Docs Agent SDK nói các lần gọi tool trung gian nằm lại trong subagent, chỉ tin nhắn cuối cùng được trả về cho agent chính.

Vì subagent không thấy hội thoại gốc, thứ duy nhất nó nhận là lời giao việc. Bài viết về hệ thống nghiên cứu nhiều agent của Anthropic nói mỗi subagent cần: mục tiêu, định dạng kết quả, hướng dẫn dùng tool và nguồn nào, ranh giới việc rõ ràng. Thiếu những thứ đó, các subagent làm trùng việc của nhau, bỏ sót, hoặc không tìm ra thông tin cần.

Tầng quản lý không chỉ giao việc. Nó còn phải kiểm những gì subagent trả về trước khi chuyển tiếp: giới hạn số lần gọi tool và token cho mỗi subagent, kiểm kết quả theo một schema định trước, và thống nhất "hợp đồng bàn giao" giữa các bước (bước trước trả gì, bước sau cần gì).

Khi nào subagent giúp, và cái giá phải trả

Bài blog "When to use multi-agent systems" của Claude nêu ba tình huống mà nhiều agent làm tốt hơn một agent:

Ngoài ba tình huống này, chi phí điều phối thường lớn hơn lợi ích. Cái giá cụ thể:

• Token: blog trên nói hệ nhiều agent thường tốn gấp 3–10 lần token so với một agent cho cùng một việc. Bài viết về hệ thống nghiên cứu đo được agent dùng khoảng 4 lần token so với chat thường, hệ nhiều agent khoảng 15 lần.
• Thời gian: chạy song song giúp phủ rộng hơn, không chắc nhanh hơn. Tổng thời gian của hệ nhiều agent thường còn dài hơn một agent vì khối lượng tính toán tăng.
• Mất thông tin ở mỗi lần bàn giao: nếu chia theo loại việc (một agent lập kế hoạch, một agent viết, một agent test cho cùng một tính năng), mỗi lần chuyển tay lại mất ngữ cảnh. Blog khuyên chia theo ranh giới ngữ cảnh: chỉ tách khi phần việc đó thật sự độc lập.

Nếu agent khó chọn tool chỉ vì có quá nhiều tool, blog gợi ý thử Tool Search Tool (Claude tìm tool khi cần thay vì nạp hết định nghĩa từ đầu) trước khi tách thành nhiều agent.

Câu luyện thi khác hỏi mẫu cho việc nghiên cứu nhiều bước: chia nhỏ, giao từng phần cho một subagent tập trung, rồi tổng hợp. Đáp án là orchestrator và subagent chuyên trách cho từng phần. Các lựa chọn còn lại (lưu trước toàn bộ lịch sử nghiên cứu, cắt bỏ nội dung mỗi phần sau khi xong, một vòng lặp tool có mọi tool) là kỹ thuật quản lý bộ nhớ và context, không trả lời câu hỏi về cách điều phối.