Các mẫu agent và framework - vòng lặp tool, subagent, bộ nhớ, context

Phần lớn hệ thống agent chạy tốt được ghép từ vài mẫu đơn giản, không phải từ một kiến trúc phức tạp. Biết tên và đúng chỗ dùng của từng mẫu giúp bạn chọn nhanh, và nhận ra đáp án nào trong đề đang dùng sai mẫu.

Bài này giúp bạn trả lời: việc nhiều bước này hợp với mẫu nào, làm sao để agent chạy lâu mà context không phình, và có nên dùng framework không?

Ví dụ xuyên suốt: nhà xuất bản biên tập bản thảo

Một nhà xuất bản sách nhận khoảng 20 bản thảo mỗi tháng, mỗi bản 25–40 chương. Họ muốn Claude hỗ trợ biên tập viên:

• Soát lỗi chính tả và văn phong của từng chương theo sổ tay biên tập của nhà.
• Kiểm tính nhất quán giữa các chương: tên nhân vật, mốc thời gian, địa danh.
• Viết đoạn giới thiệu in ở bìa sau, đạt tiêu chí của phòng phát hành.

Một bản thảo xử lý mất vài giờ và thường bị ngắt giữa chừng khi biên tập viên hết giờ làm.

Năm mẫu workflow, và khi nào thay bằng agent

Bài viết "Building effective agents" của Anthropic mô tả năm mẫu workflow thường gặp trong thực tế, xếp từ đơn giản tới linh hoạt:

Bài viết nói evaluator-optimizer hợp khi có tiêu chí đánh giá rõ và việc sửa nhiều vòng thật sự làm kết quả tốt lên. Agent tự chủ thì dành cho việc mở, không đoán trước được số bước.

Có những quy trình vừa có các bước tách biệt vừa phải quay lại bước trước tuỳ tình trạng hồ sơ. Đề thi gọi kiểu này là mẫu dựa trên đồ thị (graph-based pattern): mỗi bước là một nút có tiêu chí đạt riêng, và trạng thái của từng hồ sơ quyết định đi sang nút nào, kể cả quay lại.

Ai chạy vòng lặp tool

Mẫu cơ bản nhất của agent là vòng lặp gọi tool (tool-use loop): model gọi tool, nhận kết quả, quyết định bước tiếp. Câu hỏi là ai chạy vòng lặp đó:

Subagent và bộ nhớ: giữ context gọn

Context window là "bộ nhớ làm việc" của model: mọi thứ model đọc được khi trả lời, kể cả câu trả lời. Một agent soát 40 chương mà nhét hết vào một hội thoại sẽ đầy context rất nhanh. Có hai cách giữ context gọn:

Subagent. Docs Agent SDK nói mỗi subagent chạy trong hội thoại riêng; các lần gọi tool trung gian nằm lại trong subagent, chỉ tin nhắn cuối được trả về agent chính. Trong ví dụ, mỗi chương giao cho một subagent soát; agent chính chỉ nhận danh sách lỗi và các tên riêng xuất hiện, không nhận cả chương. Subagent tuỳ chỉnh trả về một agentId; muốn hỏi tiếp subagent đó ở lần gọi query() sau thì chạy lại đúng session đó (resume) và nhắc agent ID trong prompt.

Bộ nhớ ngoài context. Context chỉ sống trong một phiên. Thứ cần nhớ qua nhiều phiên phải lưu ra ngoài. Memory tool của Claude API làm việc này: Claude yêu cầu đọc, ghi file trong thư mục /memories, còn ứng dụng của bạn thực hiện yêu cầu trên kho lưu trữ của mình (tool chạy phía client). Handler của bạn phải từ chối mọi đường dẫn ra ngoài /memories.

{ "tools": [{ "type": "memory_20250818", "name": "memory" }] }

Trong ví dụ, Claude ghi vào bộ nhớ các quyết định biên tập đã chốt ("tên nhân vật viết là Hạnh, không phải Hạnh Nhi"), để phiên sau soát chương 30 vẫn theo đúng quyết định từ chương 3.

Checkpoint cho việc dài

Bài viết về hệ thống nghiên cứu nhiều agent của Anthropic nói agent có trạng thái và lỗi chồng lên nhau qua nhiều bước; khi lỗi xảy ra thì không thể chạy lại từ đầu vì tốn kém và gây bực bội. Họ dựng hệ thống chạy tiếp được từ chỗ agent đang dừng, kết hợp thử lại và lưu checkpoint đều đặn.

Trong ví dụ, sau mỗi chương soát xong, hệ thống lưu ra database: chương đã soát, danh sách lỗi, các quyết định biên tập mới. Bị ngắt ở chương 17 thì lần sau nạp lại trạng thái và làm tiếp từ chương 18. Agent SDK cũng hỗ trợ việc này ở mức hội thoại: lấy session ID từ kết quả, lần sau truyền resume để khôi phục đầy đủ ngữ cảnh.

Framework: giúp gì, giấu gì

Đề thi nhắc các framework trừu tượng hoá agent (agentic abstraction frameworks), ví dụ Strands, LangGraph, PydanticAI. Bài viết của Anthropic liệt kê vài framework, trong đó có Claude Agent SDK và Strands Agents SDK của AWS, và nhận xét:

• Framework giúp bắt đầu nhanh vì lo sẵn việc cấp thấp: gọi model, khai báo và đọc tool, nối các lần gọi.
• Nhưng chúng thêm lớp trừu tượng che mất prompt và phản hồi thật, nên khó gỡ lỗi hơn, và dễ khiến bạn thêm phức tạp khi cách đơn giản đã đủ.
• Lời khuyên: bắt đầu bằng gọi API trực tiếp, nhiều mẫu chỉ cần vài dòng code. Nếu dùng framework thì phải hiểu code bên dưới, vì hiểu sai cái framework làm ngầm là nguồn lỗi hay gặp.

1. Bước biết trước, không quay lại?Nối chuỗi, hoặc song song nếu các phần độc lập
2. Có bước phải quay lại tuỳ trạng thái?Mẫu đồ thị, mỗi bước có tiêu chí riêng
3. Không đoán được việc con?Orchestrator-workers
4. Có tiêu chí chấm rõ và sửa nhiều vòng có ích?Evaluator-optimizer
5. Còn lạiMột lần gọi model, hoặc agent nếu việc thật sự mở