Khi Anthropic xuất bản Building Effective Agents vào cuối năm 2024, họ đã làm được một điều hiếm thấy trong ngành: cung cấp cho các kỹ sư một hệ thống thuật ngữ chung. Thay vì một bản tuyên ngôn khác về trí tuệ nhân tạo tổng quát (AGI), bản hướng dẫn này đã đưa ra sáu mô hình rõ ràng để cấu trúc các hệ thống LLM. Một năm rưỡi sau, vào năm 2026, bối cảnh đã thay đổi hoàn toàn. Model Context Protocol đã trở thành một tiêu chuẩn phổ quát. Claude đã có thêm những khả năng mới. Hầu hết các tổ chức hiện nay đều có ít nhất một agent đang chạy trong môi trường production. Trong bối cảnh đó, việc đặt câu hỏi liệu sáu mô hình kia có còn quan trọng hay không, hay chúng chỉ nên được lưu trữ cùng với các trọng số mô hình (model weights) của năm ngoái, là một câu hỏi hoàn toàn hợp lý.
Tôi đã thử nghiệm cả sáu mô hình này với một mô hình chạy cục bộ (local model) trong một kho lưu trữ phụ để tìm câu trả lời. Kết quả là có. Chúng vẫn đứng vững. Nhưng không phải vì chúng là những quy luật bất biến. Chúng đứng vững vì mười tám tháng kinh nghiệm triển khai thực tế đã xác nhận tính logic cốt lõi của khung làm việc này.
Những gì Khung làm việc thực sự mang lại cho chúng ta
Sáu mô hình này rất đáng để ghi nhớ: Prompt Chaining, Routing, Parallelization, Evaluator-Optimizer, Orchestrator-Workers, và Autonomous Agents. Mô hình cuối cùng về cơ bản là một vòng lặp, trong đó mô hình lập kế hoạch, hành động, quan sát và lặp lại cho đến khi một điều kiện nào đó được đáp ứng.
Rất nhiều kỹ sư đã thực hiện việc xâu chuỗi các prompt hoặc ủy thác nhiệm vụ cho các luồng worker trước khi bản hướng dẫn này xuất hiện. Những gì Anthropic cung cấp chính là hệ thống phân loại. "Agent" của người này có thể là "workflow" của người kia, và là "multi-step tool call" của người thứ ba. Bản hướng dẫn đã sắp xếp sự hỗn loạn đó vào các nhóm với ranh giới rõ ràng. Điều đó giúp chúng ta có thể tranh luận về các sự đánh đổi mà không bị lạc đề hay hiểu lầm ý nhau. Trong một lĩnh vực đang ngập trong những lời quảng cáo thổi phồng, ngôn ngữ sắc bén chính là một loại cơ sở hạ tầng.
Ngành công nghiệp xây dựng dựa trên nó, chứ không phải xây xung quanh nó
Đến năm 2026, các danh mục này đã được tích hợp sâu vào cách các đội ngũ thiết kế hệ thống. Anthropic vẫn giảng dạy chúng trong các khóa học tại Academy của họ. Các bài báo nghiên cứu và blog kỹ thuật vẫn sử dụng sáu nhóm tương tự để mô tả các kiến trúc mới. Sự trường tồn đó là điều bất thường đối với một lĩnh vực vốn thay đổi công nghệ theo từng quý.
Lý do rất đơn giản. Ngành công nghiệp không thay thế khung làm việc này. Họ xây dựng dựa trên nó. Các công cụ mới như MCP và các tiêu chuẩn Agent Skills mới hơn đóng vai trò như hệ thống đường ống (plumbing). Chúng giúp việc kết nối một mô hình với cơ sở dữ liệu, hiển thị một công cụ hoặc quản lý trạng thái trở nên dễ dàng hơn. Nhưng chúng không thay đổi logic về việc khi nào nên sử dụng một router thay vì một orchestrator. Một đường ống tốt hơn không thể viết lại bản thiết kế mặt bằng.
Dữ liệu thực tế vào năm 2026 xác nhận điều này. Mô hình triển khai phổ biến nhất vẫn là một lệnh gọi sử dụng công cụ (tool-use) duy nhất kết hợp với sự kiểm duyệt của con người. Mô hình phổ biến thứ hai là một workflow nhiều bước với đúng một lần bàn giao cho con người. Cả hai đều là hậu duệ trực tiếp của Prompt Chaining và Routing. Các vòng lặp tự trị hoàn toàn (full autonomous loops) vẫn là ngoại lệ chứ không phải là quy tắc trong các hệ thống đang vận hành thực tế.
Sự tiết chế đã giành chiến thắng trên thị trường
Lời khuyên hay nhất trong bản hướng dẫn gốc cũng chính là lời khuyên thường bị phớt lờ nhất vào năm 2024: hãy sử dụng mô hình đơn giản nhất mà vẫn hiệu quả. Đừng triển khai một agent tự trị hoàn toàn nếu một lộ trình được lập trình sẵn (hardcoded path) có thể hoàn thành công việc.
Thị trường cuối cùng đã tiếp thu được điều này. Hầu hết các dự án thử nghiệm agent vẫn thất bại, và chúng thất bại vì cùng một lý do có thể dự đoán trước. Các đội ngũ cứ chồng chất các lớp trừu tượng lên nhau cho đến khi không ai có thể truy vết được ranh giới ra quyết định. Khi hệ thống đi chệch hướng, việc gỡ lỗi trở thành một công cuộc khảo cổ học. Những công ty thành công trong môi trường production là những công ty biết tiết chế. Họ ưu tiên sử dụng công cụ trong một lượt (single-turn tool use). Họ chỉ thêm một lớp routing sau khi thấy rằng một prompt duy nhất không còn nhất quán. Họ coi tính tự trị là một rủi ro cần được chứng minh tính hợp lý, chứ không phải là một tính năng để ăn mừng.
Đây không phải là lập luận chống lại tham vọng. Đây là lập luận ủng hộ sự kết hợp (composition). Các mô hình hoạt động tốt nhất khi bạn kết hợp chúng một cách có tính toán, thay vì phản xạ chọn ngay phương án phức tạp nhất trong thực đơn.
Nơi những vết nứt bắt đầu lộ ra
Khung làm việc này không phải là thuốc chữa bách bệnh. Có những giới hạn cứng sẽ xuất hiện ngay khi bạn rời khỏi giai đoạn thử nghiệm (prototype).
For high-frequency, low-cost tasks, deterministic code still wins. An LLM should not be normalizing a CSV column when pandas can do it in milliseconds without hallucinating. Avoid autonomous loops if you cannot define a crisp evaluation goal. Without a clear stopping condition, the model will iterate until it invents a reason to stop. For high-stakes decisions that require external grounding, do not rely solely on the model’s internal knowledge. And watch for bottlenecks in data retrieval. Any pattern that depends on vector search or external APIs can choke if your database is slow or your context window is clogged with irrelevant chunks.
These are not hypothetical edge cases. They are the constraints that separate a working demo from a system that survives the weekend.
A Rigid Check and a Wrong Failure
I learned the practical value of this framework while building my test repository. I was implementing the Evaluator-Optimizer pattern. My evaluator started as a hardcoded regex that scanned the model’s output for specific keywords. The model returned a correct, well-reasoned answer that happened to use synonyms instead of the exact words I was hunting. The evaluator flagged it as a failure.
The model was right. My check was too rigid.
Fixing it required more than expanding a word list. I switched the evaluator itself to an LLM-based judgment. That cost extra tokens and a few more milliseconds, but it restored the evaluation to the right level of abstraction. The pattern itself was sound. I had simply chosen the wrong implementation for the task. That is exactly the kind of mistake the framework is meant to prevent. Some evaluations need code. Others need a model. Knowing which is which is the whole point.
How to Use Them Now
Treat these six patterns as a starting point, not absolute law. Begin with a single prompt. If quality is inconsistent across input types, add a routing layer to send different requests to specialized prompts. If you need multiple independent perspectives before making a call, use Parallelization. If the task is large and divisible, try Orchestrator-Workers. Only reach for the full autonomous loop when the problem space is too wide to pre-map and when you have a reliable
