Kiến trúc 3-Agent của Anthropic: Planner → Generator → Evaluator

Định nghĩa

Kiến trúc 3-Agent của Anthropic là pattern separation of concerns trong hệ thống AI, phân tách workflow phức tạp thành ba vai trò chuyên biệt: Planner (lập kế hoạch), Generator (sinh sản), và Evaluator (đánh giá). Thay vì giao toàn bộ nhiệm vụ cho một agent duy nhất (monolithic), hệ thống này tạo ra pipeline kiểm soát chất lượng với feedback loop độc lập, buộc AI phải "nghĩ trước khi làm" và "kiểm tra trước khi xong".

Giải thích chi tiết

Vấn đề của Monolithic Agent

Single agent đóng vai trò "vừa kiến trúc sư vừa thợ xây vừa giám sát" sẽ gặp hai lỗi chết người:

• Premature completion: Agent tuyên bố "xong" khi thực chất chỉ mới hiểu surface-level của yêu cầu. Không có ai kiểm tra độc lập nên nó tự thấy ổn, dẫn đến partial implementation.
• Context pollution: Khi vừa phải thiết kế kiến trúc vừa viết code vừa fix bug, Context Window bị pha trộn giữa "cái cần làm" và "cái đang làm". Agent bắt đầu cắt bớt bước thiết kế để tiết kiệm token, dẫn đến shortcut về mặt kỹ thuật.

Ba vai trò chuyên biệt

Planner (Người lập kế hoạch)

Chỉ làm một việc: đọc hiểu yêu cầu và biến thành roadmap cụ thể. Không viết code, không chạy test. Output là spec chi tiết: cần sửa file nào, thêm hàm gì, giữ nguyên behavior nào. Planner có "quyền" từ chối nếu yêu cầu mơ hồ — buộc người dùng phải làm rõ trước khi tốn token cho Generator. Đây là lớp architectural gate.

Generator (Người thực thi)

Tay to nhưng mù quáng. Generator chỉ nhìn vào spec từ Planner, không nhìn trực tiếp vào yêu cầu gốc (để tránh distraction). Nhiệm vụ: viết code chính xác theo spec. Nếu phát hiện spec bất hợp lý (ví dụ: import file không tồn tại), Generator không tự sửa spec mà báo lại Planner — đảm bảo single source of truth. Đây là lớp execution.

Evaluator (Người đánh giá)

QA độc lập, không tham gia vào quá trình tạo ra output. Evaluator nhận cả "input gốc + spec + output từ Generator" và kiểm tra: có đúng yêu cầu không? Có lỗi logic không? Có violate constraint không? Output là Pass/ Fail kèm lý do cụ thể. Nếu Fail, feedback được gửi lại Generator (hoặc Planner nếu lỗi là architectural). Đây là lớp quality gate.

Sự tiến hóa từ v1 sang v2

Anthropic đã thử nghiệm rõ ràng sự khác biệt qua hai thế hệ:

• v1 (Initializer + Coding): Initializer setup môi trường rồi Coding Agent làm tất. Vấn đề: Coding Agent thường bỏ qua phần "hiểu requirement" và nhảy vào viết code ngay, dẫn đến bỏ sót edge case.
• v2 (Planner + Generator + Evaluator): Thêm Evaluator làm gatekeeper, và tách Planner ra khỏi Generator để buộc phải có design phase. Kết quả: giảm đáng kể lỗi "tưởng là xong" và tăng độ chính xác trong các task multi-file phức tạp.

Luồng feedback loop

Vòng lặp thường thấy trong thực thi:

1. Planner output spec → Generator viết lần 1
2. Evaluator kiểm tra → Fail (ví dụ: thiếu xử lý lỗi)
3. Generator sửa lần 2 (chỉ sửa phần bị chê, không rewrite từ đầu)
4. Evaluator Pass → Kết thúc

Quan trọng: Evaluator có thể trigger quay về Planner nếu phát hiện lỗi architectural (ví dụ: chọn sai data structure từ đầu). Điều này tránh hiện tượng "băng bó vết thương chí mạng" — cố gắng patch thay vì redesign từ gốc.

Ví dụ thực tế

Anthropic v1 vs v2 trong Coding Task

Cùng một task: "Thêm tính năng xác thực JWT vào API endpoint /users với refresh token mechanism".

v1 (Initializer + Coding):

• Initializer đọc repo structure và cung cấp context.
• Coding Agent đọc issue, hiểu lơ mơ "cần auth", liền thêm middleware vào file server.js, tuyên bố xong sau 30 giây.
• Kết quả: Quên không cập nhật env.example cho JWT_SECRET, không thêm validation schema, không viết test cho refresh flow. Khi chạy thử, hệ thống chết vì thiếu env variable.

v2 (Planner + Generator + Evaluator):

• Planner đọc kỹ requirement: phát hiện cần sửa 4 file (server.js, auth.js, env.example, auth.test.js), tạo checklist 9 bước bao gồm cả "thêm test cho edge case token hết hạn" và "cập nhật documentation".
• Generator chỉ viết đúng 4 file theo checklist, không tự ý thêm bớt feature.
• Evaluator chạy test suite, review diff, phát hiện thiếu test cho edge case "refresh token bị reuse" → Fail với lý do cụ thể.
• Generator bổ sung test case và logic chống reuse → Evaluator Pass.

Chi phí v2 cao hơn 3-4 lần v1 do nhiều roundtrip giữa các agent, nhưng tránh được technical debt và bug production.

Claude Code và 3 mô hình Subagent

Trong thực thi, Anthropic áp dụng 3-agent pattern qua các mô hình subagent cụ thể trong Claude Code:

Fork (Planner isolation) Tạo bản sao context riêng cho Planner thử nghiệm các giả thuyết thiết kế. Nếu Planner quyết định "dùng Redis thay vì Database cho session", Fork cho phép test giả thuyết này mà không ảnh hưởng đến context chính của Generator. Nếu giả thuyết sai, chỉ Fork bị discard.

Teammate (Evaluator mode) Khi Generator đang code, có thể spawn Teammate đóng vai Evaluator chạy song song (parallel). Teammate không block Generator, chỉ đọc code incrementally và báo cảnh báo sớm qua shared state.

Worktree (Generator sandbox) Tách biệt filesystem hoàn toàn cho Generator thử nghiệm. Nếu Generator quyết định refactor lớn nhưng sai lầm, Worktree bị "nhiễm" còn context chính vẫn sạch — Evaluator chỉ cần discard worktree thay vì rollback phức tạp trên repo chính.

Chi phí $9 vs$200: Trade-off thực tế

Một task refactor codebase cỡ trung bình (thêm tính năng mới vào module có 20 file liên quan):

• $9 solo: Single agent chạy một lần, khoảng 10k tokens, ra kết quả "tạm được" sau 2 phút. Rủi ro: bug ẩn, technical debt, buộc phải có engineer review lại sau.
• $200 full harness: 3-agent với 5 vòng lặp Evaluator→Generator, tổng 200k tokens, thời gian 15 phút. Đắt hơn 20x nhưng output production-ready, không cần human review, deploy ngay.

Khi nào chọn cái nào?

• Chọn $9 cho prototype, internal tool, hoặc khi bạn có engineer senior sẵn sàng review lại code.
• Chọn $200 cho code vào production repo, hotfix cấp bách cần deploy ngay lập tức, hoặc khi xây dựng hệ thống autonomous (không có người trong vòng lặp).

Ứng dụng

Sinh viên nghiên cứu & Developer junior

Hiểu pattern này giúp bạn thiết kế project tốt nghiệp có tính modular. Thay vì viết một đoạn prompt dài ngoằn cho GPT-4, hãy tách thành 3 prompt riêng biệt với input/output rõ ràng. Dễ debug hơn (biết lỗi ở Planner hay Generator), dễ benchmark từng phần để optimize token usage.

AI Engineer & Senior Developer

Áp dụng vào hệ thống RAG hoặc coding assistant nội bộ:

• Planner: Query understanding + route planning (cần tìm trong DB nào, file nào).
• Generator: Synthesis thông tin thành câu trả lời hoặc code snippet.
• Evaluator: Fact-checking (có hallucination không?), safety check (có leak sensitive data không?), style consistency.

Tech Lead & Doanh nghiệp

Dùng để đánh giá ROI của AI automation:

• Tính toán chi phí token (như ví dụ $9 vs$200) so với chi phí nhân công review. Nếu thuê senior engineer review hết $500/giờ, thì$200 cho full harness là bargain.
• Xác định quality gate: những workflow nào bắt buộc phải có Evaluator độc lập (ví dụ: tự động sửa code payment, migration database) vs những workflow có thể chấp nhận single agent (ví dụ: generate documentation, draft email).

So sánh

Kết luận: 3-Agent không phải silver bullet. Giống như bạn không cần microservices cho ứng dụng todo list, bạn không cần 3-agent cho câu hỏi "tóm tắt đoạn văn này". Nhưng với "sửa bug trong hệ thống thanh toán có 50 file liên quan", separation of concerns là sự khác biệt giữa production-ready và thảm họa.

Bài viết liên quan

Cùng cụm (Multi-Agent Architecture)

Tại sao cần Multi-Agent? Khi single agent không đủ

Hiểu rõ failure modes của monolithic agent và các dấu hiệu cho thấy bạn cần tách hệ thống thành nhiều agent chuyên biệt

3 mô hình Subagent: Fork, Teammate, Worktree

Cách Claude Code triển khai cụ thể các mô hình tách biệt context và filesystem cho từng vai trò Planner, Generator, Evaluator

Agent Communication: Mailbox, shared state, event bus

Các agent trao đổi thông tin với nhau như thế nào? Khám phá kỹ thuật giao tiếp giữa Planner, Generator, và Evaluator

Parallel vs Sequential Agents: Khi nào dùng gì?

Nên chạy Evaluator song song với Generator hay tuần tự? So sánh trade-off về latency và chất lượng

Đọc tiếp (Harness Engineering)

Nền tảng Harness Engineering

Quay lại hiểu bản chất Agent-Computer Interface (ACI) — nền tảng để thiết kế các agent tách biệt có kiểm soát

State & Session Management

Làm sao để Planner nhớ được Generator đã làm gì ở vòng lặp trước? Quản lý trạng thái và phiên làm việc giữa các agent

Security & Guardrails

Khi Evaluator và Generator cùng truy cập filesystem, làm sao ngăn chặn prompt injection lan truyền giữa các agent?