Bài 2 — Mô hình Planner / Worker / Critic

Đây là "tam giác vàng" mà bạn sẽ thấy lặp lại trong hầu hết hệ multi-agent nghiêm túc. Hiểu vai trò từng đỉnh và cách chúng phối hợp là nền tảng cho mọi pattern phức tạp hơn.

Ba vai trò

• Planner: nhận mục tiêu, chia thành các bước/nhiệm vụ con có thứ tự. Không thực thi, chỉ ra kế hoạch. Đầu ra thường là danh sách task có cấu trúc.
• Worker (executor): nhận một task cụ thể, dùng tool để thực thi, trả kết quả. Có thể có nhiều worker chuyên biệt (worker tra cứu, worker viết code, worker gọi API).
• Critic (reviewer/evaluator): kiểm tra kết quả của worker so với tiêu chí, chỉ ra lỗi, quyết định đạt/chưa đạt và yêu cầu làm lại nếu cần.

Vì sao tách Critic ra khỏi Worker

Nếu để một agent tự làm rồi tự chấm, nó thiên vị chính mình ("tôi làm đúng rồi"). Critic là một ngữ cảnh sạch: nó chỉ thấy đầu ra và tiêu chí, không thấy worker đã vật lộn thế nào. Điều này cho phản biện khách quan hơn nhiều — giống code review giữa hai người khác nhau.

Ví dụ cụ thể: agent viết truy vấn SQL

Mục tiêu: "Doanh thu theo tháng của sản phẩm A năm 2025"

Planner  -> [1] xác định bảng liên quan
            [2] viết SQL
            [3] kiểm tra SQL có lọc đúng năm & sản phẩm
Worker   -> sinh: SELECT month, SUM(amount) ... WHERE product='A'
Critic   -> phát hiện THIẾU điều kiện năm=2025 -> TRẢ VỀ "chưa đạt: thiếu WHERE year"
Worker   -> sửa lại, thêm AND YEAR(order_date)=2025
Critic   -> "đạt"

Vòng worker-critic lặp lại cho tới khi đạt hoặc hết số lần thử.

Pseudocode vòng lặp cơ bản

def planner_worker_critic(goal, max_rounds=3):
    plan = planner.run(goal)          # -> list[task]
    results = []
    for task in plan:
        output = worker.run(task)
        for _ in range(max_rounds):
            verdict = critic.run(task, output)   # {passed: bool, feedback: str}
            if verdict["passed"]:
                break
            output = worker.run(task, feedback=verdict["feedback"])
        results.append(output)
    return results

Hai chi tiết quan trọng: max_rounds để tránh lặp vô hạn, và feedback của critic phải được truyền lại cho worker — nếu không worker sẽ lặp lại lỗi cũ.

Khung tư duy: Critic cần tiêu chí, không phải cảm tính

Một critic tốt được cấp một rubric rõ ràng trong prompt: "đạt khi (a) SQL chạy được, (b) lọc đúng mọi điều kiện trong yêu cầu, (c) không SELECT *". Critic không có rubric sẽ chấm lung tung, lúc gắt lúc lỏng, gây lặp không hội tụ.

Các bước xây dựng

• Viết prompt Planner: nhấn mạnh chỉ lập kế hoạch, xuất ra danh sách task có schema cố định.
• Viết prompt Worker: nhận đúng một task + (tùy chọn) feedback, tập trung thực thi.
• Viết rubric cho Critic thành các tiêu chí kiểm được, yêu cầu xuất {passed, feedback}.
• Ghép vòng lặp với max_rounds và ghi log mỗi lượt để quan sát hội tụ.
• Thử với 3–5 ca thật, xem critic có bắt đúng lỗi và worker có sửa được không.

Checklist thiết kế

• [ ] Planner không được tự thực thi tool.
• [ ] Worker nhận feedback của critic ở lượt sau.
• [ ] Critic có rubric kiểm được, xuất kết quả có cấu trúc.
• [ ] Có giới hạn số vòng lặp và hành vi khi chạm giới hạn.

Sai lầm thường gặp

• Critic không nhận được tiêu chí gốc. Nó sẽ chấm theo cảm tính, gây lặp lê thê.
• Không truyền feedback lại cho worker. Worker "làm lại" nhưng lặp y nguyên lỗi cũ.
• Bỏ max_rounds. Worker-critic đá qua đá lại vô hạn, cháy token.
• Planner làm luôn cả việc. Ranh giới vai trò vỡ, mất lợi ích cô lập ngữ cảnh.

Bài 3 ta sẽ đi sâu vào cơ chế hand-off: cách chuyển việc và dữ liệu giữa các agent sao cho không mất mát hay hiểu sai.