Author: Yanhua
Antonio Gullí là Giám đốc Kỹ thuật của Google. Ông đã viết một cuốn sách 453 trang, chia nhỏ việc phát triển AI Agent thành 21 mẫu thiết kế.
Nhưng đây không phải là một bài đánh giá sách. Động cơ của tôi khi đọc cuốn sách này rất cụ thể: tôi đã từng viết về Harness Engineering, về kinh nghiệm đụng độ với Clawdbot, về bài viết “Agent AI không phải là phép màu” với bảy bước chuyển biến từ việc tiêu tốn Token đến khi trở nên thực sự hữu dụng; sau mỗi lần viết xong, đều còn tồn tại một câu hỏi chưa suy nghĩ thấu đáo: Liệu đằng sau những điều này có tồn tại một logic nền tảng có thể tái sử dụng không?
This book gave me the answer, and it went deeper than I thought.
Bạn viết có lẽ hoàn toàn không phải là Agent
Phán斷 sắc sảo nhất trong cuốn sách nằm ở phần prologue.
Hầu hết mọi người đang sử dụng “AI” chỉ là Level 0: LLM trần trụi, không có công cụ, không có trí nhớ, không thể hành động. Bạn hỏi nó phim nào sẽ giành giải Oscar năm 2025, nó sẽ đoán. Sách nói rất rõ ràng: những thứ ở Level 0 không phải là Agent.
Đi lên mới là thật Agent:
Cấp độ 1: Người sử dụng công cụ
Agent bắt đầu sử dụng công cụ: tìm kiếm, API, cơ sở dữ liệu. Nhưng nó không chỉ đơn thuần là “có thể gọi API”, mà còn phải tự mình phán đoán khi nào nên gọi, gọi cái gì, và sử dụng kết quả ra sao. Sách đưa ra một ví dụ rất cụ thể: người dùng hỏi “Gần đây có phim mới nào không?”, Agent tự nhận ra thông tin này không có trong dữ liệu huấn luyện, nên chủ động gọi công cụ tìm kiếm để tìm kiếm, sau đó tổng hợp kết quả. Bước then chốt nằm ở “tự nhận ra”. Không phải con người bảo nó “hãy đi tìm kiếm”, mà chính nó tự phán đoán rằng cần phải tìm kiếm. Khả năng phán đoán này là ngưỡng của Level 1.
Cấp độ 2: Người suy nghĩ chiến lược
Có thêm hai thứ: lập kế hoạch và Context Engineering. Sách định nghĩa Context Engineering: không tích lũy thông tin, mà là lựa chọn, cắt xén và đóng gói bối cảnh một cách tinh vi. Ví dụ rất hay: người dùng muốn tìm cửa hàng cà phê giữa hai địa điểm. Agent trước tiên gọi công cụ bản đồ để lấy về một lượng lớn dữ liệu, sau đó tự mình phán đoán “bước tiếp theo chỉ cần tên đường”, cắt xén đầu ra của bản đồ thành một danh sách ngắn, rồi cung cấp cho công cụ tìm kiếm địa phương. Mỗi bước đều thực hiện việc loại bỏ nhiễu thông tin.
Trong sách có một câu tôi đã đọc đi đọc lại vài lần: “Để AI đạt độ chính xác cao nhất, phải cung cấp cho nó ngữ cảnh ngắn gọn, tập trung và mạnh mẽ.” Context Engineering chính là làm công việc này.
Ở cấp độ này, Agent còn có thể tự phản tư. Sau khi hoàn thành công việc, tự kiểm tra lại và tự sửa lỗi nếu phát hiện vấn đề. Tôi sẽ trình bày chi tiết sau.
Cấp độ 3: Hợp tác đa Agent
Quan điểm của cuốn sách rất rõ ràng: Đừng luôn nghĩ đến việc tạo ra một siêu tác nhân toàn năng. Cách tiếp cận đáng tin cậy thực sự là xây dựng như một đội nhóm: Agent quản lý dự án + Agent nghiên cứu + Agent thiết kế + Agent biên tập. Ví dụ trong sách là việc ra mắt sản phẩm mới: Một “Agent quản lý dự án” điều phối tổng thể, phân công nhiệm vụ cho “Agent nghiên cứu thị trường”, “Agent thiết kế sản phẩm”, “Agent tiếp thị”. Chìa khóa là giao tiếp: Các Agent truyền dữ liệu, đồng bộ trạng thái và xử lý xung đột như thế nào. Chương này minh họa sáu cấu trúc giao tiếp, từ đơn giản nhất là một Agent đến linh hoạt nhất là hỗn hợp tùy chỉnh, mỗi loại đều có giải thích về bối cảnh phù hợp.
Xem xong bốn cấp độ này, tôi đột nhiên hiểu vì sao nhiều người nói “Agent của tôi dùng không tốt”. Mô hình không có vấn đề, vấn đề là bạn đang dùng nó như một chatbot, và nó có thể chưa đạt đến Level 1.
Context Engineering: Khái niệm bị đánh giá thấp nhất trong sách
Tôi đã từng viết một bài về Harness Engineering, nói rằng thiết kế đường đua quan trọng hơn công suất động cơ. Sau khi đọc xong cuốn sách này, tôi nhận ra rằng Context Engineering chính là sự ánh xạ của Harness Engineering ở cấp độ prompt.
Prompt Engineering truyền thống chỉ quan tâm đến “bạn hỏi thế nào”. Context Engineering trong cuốn sách lại quan tâm đến “trước khi hỏi, Agent đang thấy gì trước mặt”. Nó bao gồm bốn lớp thông tin:
Lớp đầu tiên, system prompt. Định nghĩa Agent là ai, giọng điệu nào, ranh giới nào. Hầu hết mọi người chỉ viết lớp này.
Lớp thứ hai, dữ liệu bên ngoài. Tài liệu được truy xuất bởi RAG, giá trị trả về từ việc gọi công cụ, dữ liệu API thời gian thực. Đây là nơi phần lớn mọi người gặp khó khăn: biết rằng cần cung cấp dữ liệu, nhưng không biết cách cung cấp sao cho không làm ngập mô hình.
Lớp thứ ba: dữ liệu ngầm. Danh tính người dùng, lịch sử tương tác, trạng thái môi trường. Những điều bạn không nói rõ nhưng Agent nên biết. Ví dụ: khi bạn nói với Agent “giúp tôi gửi email cho John xác nhận cuộc họp ngày mai”, nó nên biết cuộc họp ngày mai trong lịch của bạn là gì và bạn quan hệ với John như thế nào.
Lớp thứ tư, vòng phản hồi. Sau mỗi lần đầu ra, Agent tự động đánh giá chất lượng và điều chỉnh chiến lược ngữ cảnh cho lần tiếp theo. Sách gọi đây là “tối ưu hóa ngữ cảnh tự động”, và Google Vertex AI Prompt Optimizer là sự triển khai kỹ thuật của ý tưởng này.
Khi đọc đến đây, tôi nhớ lại bài viết trước đây của mình “Các tác nhân AI không phải là phép màu”, trong đó có một kinh nghiệm là “Tác nhân của bạn cần các quy tắc, và rất nhiều quy tắc”. Giờ nhìn lại, những quy tắc đó về bản chất là phiên bản thủ công của Context Engineering, và cuốn sách này đã hệ thống hóa chúng.
Reflection: Hai Agent thực sự tốt hơn một
Đây là Pattern có giá trị thực tiễn nhất đối với tôi trong toàn bộ cuốn sách.
Cốt lõi của Reflection rất đơn giản: Agent sau khi hoàn thành công việc sẽ tự kiểm tra lại và tự sửa lỗi. Nhưng cách triển khai cần có sự tinh tế. Sách đã nêu rõ: Producer và Critic phải sử dụng hai Agent khác nhau, với các system prompt khác nhau. Một persona tự kiểm tra chính mình chắc chắn sẽ có những điểm mù. Nếu bạn yêu cầu cùng một LLM vừa viết mã vừa kiểm tra mã do chính nó viết, nó rất có khả năng sẽ nói “khá tốt”.
The book provides a complete code example.
Producer's prompt is “You are a Python developer, write a function to calculate factorial, handling edge cases and exceptions”.
Prompt của Critic là “Bạn là một kỹ sư cao cấp chỉ trích khắt khe, kiểm tra từng dòng mã, phát hiện lỗi, phong cách, điều kiện biên bị bỏ sót và những điểm có thể cải thiện. Nếu hoàn hảo, hãy đầu ra
CODE_IS_PERFECT, nếu không, liệt kê tất cả các vấn đề”.Sau đó là một vòng lặp for: Producer viết mã → Critic kiểm tra → Producer điều chỉnh theo góp ý → Critic kiểm tra lại → cho đến khi Critic nói
CODE_IS_PERFECThoặc đạt đến số lần lặp tối đa.
Đơn giản vậy thôi. Nhưng cuốn sách cảnh báo một chi phí dễ bị bỏ qua: mỗi vòng phản hồi đều là một lần gọi LLM mới, càng nhiều vòng lặp thì chi phí càng cao. Hơn nữa, khi lịch sử hội thoại ngày càng dài, cửa sổ ngữ cảnh bị các phiên bản trước và ý kiến phê bình chiếm đầy, không gian suy luận thực sự có sẵn đang thu hẹp. Do đó, thực hành tốt nhất cho Reflection là: đặt một số lần lặp tối đa hợp lý (cuốn sách dùng con số 3),一旦 Critic hài lòng thì dừng lại, đừng tìm kiếm sự hoàn hảo.
Ứng dụng không chỉ dừng lại ở việc viết mã. Viết bài, lập kế hoạch, tóm tắt tài liệu, giải các bài toán logic—mô hình Producer-Critic đều có thể áp dụng. Sách liệt kê bảy ứng dụng thực tế, với logic cốt lõi giống nhau: tạo ra trước, sau đó kiểm tra và chỉnh sửa.
Multi-Agent không phải càng phức tạp càng tốt
Chương Hợp tác Đa Agent mà tôi thích nhất là sáu sơ đồ kết nối giao tiếp. Nhiều người ngay từ đầu đã đi vào những thứ phức tạp, nhưng thực ra trong phần lớn tình huống, ba loại là đủ:
Đơn Agent (thực thi độc lập): Nhiệm vụ có thể chia thành các vấn đề con không phụ thuộc lẫn nhau, mỗi Agent tự xử lý công việc của mình. Đơn giản, dễ bảo trì.
Mạng ngang hàng (Peer-to-Peer): Các Agent giao tiếp trực tiếp với nhau mà không có nút điều khiển trung tâm. Phi tập trung, khả năng chịu lỗi cao, một Agent bị lỗi không ảnh hưởng đến toàn hệ thống. Nhưng chi phí phối hợp cao, dễ trở nên hỗn loạn.
Giám sát viên (điều phối trung tâm): Một Giám sát viên Agent quản lý một nhóm Worker Agent. Phân công nhiệm vụ, thu thập kết quả, giải quyết xung đột. Cấu trúc phân cấp rõ ràng, dễ quản lý. Nhưng Giám sát viên là điểm lỗi duy nhất và cũng là điểm nghẽn hiệu năng.
Ba loại còn lại (Supervisor-as-Tool, phân cấp, hỗn hợp tùy chỉnh) là các biến thể và kết hợp của ba loại đầu tiên. Sách nói rất thực tế: cấu trúc topo bạn cần phụ thuộc vào độ phức tạp của nhiệm vụ. Nhiệm vụ càng được chia nhỏ, chi phí giao tiếp càng cao, và đến một mức độ nào đó, mô hình Supervisor lại hiệu quả hơn mô hình phân cấp.
Kinh nghiệm của tôi là nhiều người khi xây dựng Multi-Agent đã dành 80% thời gian cho giao thức truyền thông, nhưng lại quên đặt câu hỏi cơ bản hơn: Liệu nhiệm vụ này thực sự cần nhiều Agent không? Sách đã viết rất rõ ràng, Level 2 với single Agent + Reflection thường đã đủ dùng. Level 3 là dành cho những tình huống mà single Agent thực sự không thể xử lý được.
Mô hình ba lớp của Memory, tôi từng có cảm giác mơ hồ về nó nhưng chưa đặt tên
Chương Memory tôi đồng cảm nhất, vì khi viết hai bài viết về Obsidian + Claude, tôi luôn suy nghĩ về một câu hỏi: Làm thế nào để phân cấp bộ nhớ của Agent?
Sách đã đưa ra câu trả lời:
Lớp phiên (Session): Cửa sổ ngữ cảnh của cuộc hội thoại hiện tại, đây là bộ nhớ ngắn nhất và biến mất khi cuộc hội thoại kết thúc. Các mô hình ngữ cảnh dài chỉ mở rộng cửa sổ này, nhưng về bản chất vẫn là tạm thời, và mỗi lần suy luận đều phải xử lý toàn bộ cửa sổ, vừa tốn kém vừa chậm.
Trạng thái (State): Dữ liệu tạm thời trong quá trình thực hiện nhiệm vụ hiện tại. Ví dụ: “Nhiệm vụ đang thực hiện là gì”, “Đã hoàn thành đến bước nào”, “Đã tạo ra những dữ liệu trung gian nào”. Dài hơn Session, nhưng sẽ được xóa ngay sau khi nhiệm vụ kết thúc; sách đã sử dụng cơ chế State của Google ADK để cung cấp ví dụ đầy đủ.
Bộ nhớ (lớp lưu trữ bền vững): Bộ nhớ dài hạn xuyên phiên, xuyên nhiệm vụ. Sở thích người dùng, kinh nghiệm học được, các quyết định lịch sử quan trọng được lưu trữ trong cơ sở dữ liệu hoặc kho vector, truy vấn theo ngữ nghĩa. Sách nhấn mạnh một điểm rất quan trọng: Bộ nhớ không chỉ đơn thuần là lưu trữ, mà còn cần thiết kế toàn bộ chiến lược về “lưu gì, lưu khi nào, và truy vấn như thế nào”. Lưu quá nhiều sẽ gây nhiễu, lưu quá ít thì không đủ dùng.
Trong bài viết trước tôi viết về Clawdbot, tôi đã đề cập đến “tệp trạng thái” và “tài liệu không gian làm việc”, về bản chất là tự xây dựng lớp State và lớp Memory, còn sách này đã hệ thống hóa việc này.
Năm giả định, giả định thứ năm là kỳ quặc nhất
Cuối sách đưa ra năm giả định về tương lai của Agent, bốn giả định đầu vẫn nằm trong phạm vi suy luận hợp lý: Agent tổng quát từ viết mã đến quản lý dự án, phát hiện chủ động nhu cầu của bạn với mức độ cá nhân hóa sâu sắc, trí tuệ nhúng thoát khỏi màn hình và bước vào thế giới vật lý, Agent trở thành thực thể kinh tế độc lập.
Điều thứ năm khiến tôi choáng ngợp: Biến dạng Multi-Agent.
Bạn chỉ nêu mục tiêu, ví dụ: “Xây dựng một doanh nghiệp thương mại điện tử bán cà phê cao cấp.” Hệ thống tự động quyết định: trước tiên tạo “Agent nghiên cứu thị trường” và “Agent thương hiệu.” Sau khi chạy một vòng dữ liệu, hệ thống tự đánh giá thấy không cần Agent thương hiệu nữa, tách thành ba Agent mới: “Agent thiết kế logo,” “Agent xây dựng trang web,” và “Agent chuỗi cung ứng.” Nếu Agent xây dựng trang web trở thành điểm nghẽn, hệ thống tự động nhân bản ra ba Agent chạy song song để xử lý các trang khác nhau. Trong suốt quá trình này, hệ thống liên tục tự điều chỉnh prompt cho từng Agent và tái cấu trúc kiến trúc đội ngũ.
Sách gọi đây là “hệ thống đa tác nhân có mục tiêu và tự biến đổi”. Nó không thực hiện kế hoạch bạn viết ra, mà tự sinh ra kế hoạch, tự điều chỉnh kế hoạch và tự tái tổ chức đội ngũ thực thi.
Điều này khiến tôi nhớ đến AutoResearch của Karpathy: viết một program.md, xác định mục tiêu, chỉ số, giới hạn, rồi nhấn “khởi động”. Con người nằm ngoài vòng lặp. Nhưng cuốn sách này đi xa hơn: ngay cả cách组建 và tái tổ chức đội ngũ Agent cũng được giao cho hệ thống tự quyết định. Con người chỉ cần tuyên bố “muốn gì”.
Ba việc bạn có thể làm ngay lập tức
Sau khi đọc xong cuốn sách này, tôi có ba hành động có thể thực hiện ngay lập tức:
Đầu tiên, thêm một Critic vào Agent hiện tại của bạn. Dù bạn đang dùng Claude Code, CrewAI hay tự xây dựng khung, hãy thêm một bước cuối vào workflow hiện tại: để một Agent khác (sử dụng system prompt khác) kiểm tra đầu ra của bước trước đó. Sinh mã thì đi kèm kiểm tra mã, viết bài thì kèm kiểm tra sự thật, lập kế hoạch thì kèm đánh giá tính khả thi. Dù phải gọi thêm một lần LLM, nhưng chất lượng thường tăng gấp đôi. Mô hình Producer-Critic trong sách có thể sử dụng ngay lập tức.
Thứ hai, bắt đầu thực hiện Context Engineering, không chỉ là Prompt Engineering. Quay lại xem các hướng dẫn bạn đã viết cho Agent. Nếu toàn bộ là các quy tắc dạng “bạn cần làm gì” mà thiếu bối cảnh “bạn đang đối mặt với môi trường nào”, hãy bổ sung. Hãy thông báo cho Agent biết nó đang tham gia dự án nào, đã đưa ra những quyết định nào trước đó, và sở thích của người dùng là gì. Chương về Context Engineering trong cuốn sách và
AGENTS.mdcủa bạn là hai cách diễn đạt của cùng một sự việc.Thứ ba, đừng vội vàng sử dụng Multi-Agent. Hãy đưa Agent đơn của bạn lên Level 2: có công cụ, có Reflection và có Memory. Sách nhấn mạnh nhiều lần rằng một Agent Level 2 kết hợp với Producer-Critic và Context Engineering có thể bao quát hầu hết các tình huống thực tế. Level 3 là dành cho những nhiệm vụ thực sự xuyên lĩnh vực, nhiều giai đoạn và cần phân công song song. Vấn đề của đa số mọi người không phải là Agent không đủ nhiều, mà là một Agent duy nhất cũng chưa được điều chỉnh tốt.
Cuốn sách này gồm 453 trang, xuất bản bởi Springer năm 2025. Các ví dụ mã bao gồm LangChain/LangGraph, Google ADK, CrewAI, OpenAI API. Lời mở đầu do Phó chủ tịch AI của Google Cloud viết, kèm theo lời giới thiệu của CIO Goldman Sachs, bất ngờ là rất hay.
Lý do tôi khuyên dùng nó không phải vì “toàn diện”. Sau khi đọc xong, bạn sẽ nhận ra một điều: những bẫy bạn đã gặp phải trong sáu tháng qua khi dùng Agent, đều đã được người ta tổng hợp thành các mô hình rồi. Bạn không cần phải tự tạo lại Reflection, không cần phải đoán Memory nên phân tầng thế nào, cũng không cần phải thử nghiệm xem Multi-Agent nên dùng kiến trúc giao tiếp nào.
Ai đó đã vẽ bản đồ cho bạn, phần còn lại chỉ là đi thôi.
Bạn có đang phát triển bằng AI Agent không? Agent hiện tại của bạn đã đến Level mấy?