Ngày 9 · Multi-agent và kết nối hệ thống

Ý chínhGiảng viên đặt câu hỏi xuyên suốt ngày học và giới thiệu bốn đầu ra học viên sẽ đạt được sau ngày học — nhận biết đúng lúc một agent quá tải, chọn đúng pattern để chia việc, kết nối được với tool và với agent khác, và đọc được trace để debug một hệ nhiều agent — đồng thời nhắc lại rằng ngày học tiếp nối trực tiếp từ hệ thống đã xây ở Ngày 8.

Kỹ năngHọc viên biết mình sẽ đạt được gì sau ngày học và ngày học tiếp nối từ đâu.

Hình thứcVideo giảng viên, 3 phút, giọng dẫn dắt.

Ý chínhMột agent phải tự làm hết mọi vai trò trong cùng một lượt suy luận — lập kế hoạch, gọi tool, tổng hợp — nên gặp bốn giới hạn cố hữu: cửa sổ ngữ cảnh có hạn nên thông tin quan trọng dễ bị "quên" khi tài liệu dài; ôm nhiều vai thì prompt dài và không vai nào thực sự giỏi; việc độc lập vẫn phải xếp hàng chờ nhau vì agent thường chạy tuần tự; và hiểu sai đầu vào ở bước đầu kéo lệch toàn bộ luồng vì không có ranh giới để khoanh vùng lỗi. Nhầm lẫn phổ biến là cho rằng chỉ cần một model có cửa sổ ngữ cảnh lớn hơn là giải quyết được giới hạn này; trên thực tế không có kích thước ngữ cảnh nào là đủ cho mọi bài toán, và vấn đề nằm ở cách tổ chức công việc chứ không chỉ ở năng lực model.

Kỹ năngHọc viên nêu được bốn giới hạn của một agent đơn và giải thích được vì sao chỉ tăng cửa sổ ngữ cảnh không giải quyết triệt để vấn đề.

Hình thứcVideo 7 phút, mỗi giới hạn có một ví dụ số liệu minh hoạ, ví dụ một cửa sổ ngữ cảnh 24.000 token bị chiếm gần hết bởi lịch sử hội thoại và kết quả tool trước khi agent kịp suy luận.

Ý chínhHọc viên nhập một tác vụ có tài liệu dài, tool trả kết quả lớn, và lịch sử hội thoại đã tích luỹ; hệ mô phỏng trừ dần số token còn lại cho phần suy luận, và học viên dự đoán agent sẽ "quên" phần nào trước khi xem kết quả thật. Hoạt động cho thấy trực tiếp vì sao câu trả lời thiếu thông tin ở giữa tài liệu, vì sao agent lặp lại bước đã làm, và vì sao một lượt gọi tool có thể chạy với ngữ cảnh gần như rỗng.

Kỹ năngHọc viên nhận diện được các dấu hiệu quá tải ngữ cảnh trong nhật ký chạy thực tế của một agent.

Hình thứcTương tác mô phỏng 4 phút, dữ liệu cấu hình sẵn theo bốn mốc token giảm dần. Phương án thay thế: video minh hoạ 3 phút.

Ý chínhCách đặt câu hỏi thay đổi cách thiết kế. Tư duy cũ hỏi làm sao agent thông minh hơn, prompt nào khiến nó làm được nhiều việc hơn, thêm tool nào để nó đủ sức — và thường dẫn tới một agent ôm hết mọi việc mà không ai giải thích được nó đang làm gì. Tư duy hệ thống hỏi bốn câu khác: tác vụ này gồm bao nhiêu loại trách nhiệm, ai cần biết gì và khi nào, lỗi cần được khoanh vùng ở đâu, và điểm nào cần con người xem lại. Đây là bước chuyển tư duy quan trọng nhất trước khi học bất kỳ pattern cụ thể nào.

Kỹ năngHọc viên đặt được bốn câu tư duy hệ thống cho một bài toán mới thay vì chỉ hỏi agent có đủ thông minh không.

Hình thứcVideo 5 phút.

Ý chínhThêm agent không phải bản nâng cấp miễn phí — đó là một đánh đổi chỉ nên chọn khi cần thật sự. Học viên xét từng tình huống theo các dấu hiệu nên tách (nhiều vai trò khác hẳn nhau, có việc chia được độc lập, cần khoanh vùng lỗi rõ, cần mở rộng dần, ngữ cảnh một agent không đủ) đối chiếu với các trường hợp nên giữ nguyên một agent, ví dụ dữ liệu đơn giản, cùng một ngữ cảnh, hoặc một quy trình tuyến tính đã đủ dùng. Nhầm lẫn phổ biến là cho rằng đã học multi-agent thì bài toán nào cũng nên chia thành nhiều agent, kể cả khi một agent đơn giản đã giải quyết tốt.

Kỹ năngHọc viên phân loại đúng một tình huống mới là nên tách hay nên giữ một agent, và giải thích được lý do.

Hình thứcỞ nhà: bài tập phân loại mười tình huống, 5 phút, phản hồi ngay khi chọn sai. Trên lớp: thảo luận nhóm hai tình huống mơ hồ nhất, 4 phút, so góc nhìn giữa các nhóm. Phương án thay thế: trang tóm tắt dấu hiệu dạng checklist để tự đối chiếu.

Ý chính3 câu kiểm tra: bốn giới hạn của một agent đơn, vì sao tăng cửa sổ ngữ cảnh không giải quyết triệt để vấn đề, và cách phân biệt tình huống nên tách với tình huống nên giữ nguyên.

Kỹ năngHọc viên tự kiểm tra ba ý chính của module.

Hình thứcQuiz 3 câu, chấm ngay, có giải thích khi sai.

Ý chínhSupervisor-worker cho một agent điều phối phân việc cho nhiều agent chuyên biệt, điểm mạnh là khả năng kiểm soát và truy vết rõ; pipeline cho agent này làm xong mới chuyển cho agent sau, điểm mạnh là tính ổn định và dễ kiểm tra từng bước; debate cho nhiều agent cùng giải một bài toán rồi tổng hợp hoặc bỏ phiếu, điểm mạnh là giảm điểm mù; và hierarchical dùng nhiều tầng supervisor lồng nhau, điểm mạnh là khả năng mở rộng quy mô lớn. Mỗi pattern giải quyết một loại phức tạp khác nhau và có điểm cảnh báo riêng: supervisor-worker dễ biến supervisor thành nút thắt nếu nó ôm quá nhiều việc, còn pipeline kém linh hoạt khi luồng xử lý cần thay đổi động.

Kỹ năngHọc viên phân biệt được bốn pattern và nêu được điểm mạnh, điểm cảnh báo của mỗi pattern.

Hình thứcVideo 6 phút, bốn pattern hiện lần lượt kèm sơ đồ và ví dụ. Kèm bảng tra cứu một trang: pattern, dùng khi nào, điểm mạnh, cảnh báo.

Ý chínhHọc viên đọc ba tình huống thực tế — một tác vụ cần định tuyến tới đúng vai trò, một quy trình các bước gần như cố định, và một quyết định cần nhiều góc nhìn cùng đánh giá — dự đoán pattern phù hợp trước khi xem gợi ý, sau đó so sánh lựa chọn của mình với lựa chọn của một nhóm khác trên cùng dữ liệu. Hoạt động rèn phản xạ chọn pattern theo loại phức tạp của bài toán, không theo pattern nghe hay nhất.

Kỹ năngHọc viên chọn được pattern phù hợp cho một tình huống mới và giải thích được vì sao ba pattern còn lại kém phù hợp hơn.

Hình thứcTương tác 5 phút, ba tình huống cấu hình sẵn, có người hướng dẫn tổng hợp các lựa chọn khác nhau giữa các nhóm. Phương án thay thế: bài tập cá nhân ghép pattern với tình huống trên giấy.

Ý chínhKhi dùng nhiều agent để phản biện lẫn nhau, hoặc để một agent chấm điểm agent khác trong pattern debate, cần cẩn trọng với thiên vị: một agent có xu hướng chấm cao hơn cho câu trả lời có phong cách giống mô hình sinh ra nó, ngay cả khi chất lượng không hơn. Đây là lý do nên dùng nhiều model khác nhau cho vai trò trả lời và vai trò chấm điểm, và nên có tiêu chí chấm rõ ràng thay vì để việc chấm điểm diễn ra tự do theo cảm tính. Rủi ro lớn nhất của pattern debate không nằm ở việc thiếu góc nhìn mà nằm ở cách tổng hợp kết luận cuối từ nhiều góc nhìn đó.

Kỹ năngHọc viên giải thích được vì sao một agent cùng loại với bên được chấm dễ thiên vị, và nêu được cách giảm thiên vị đó.

Hình thứcVideo 5 phút.

Ý chínhTrong bốn pattern, supervisor-worker được chọn làm trục chính của ngày học vì hai lý do. Về mặt học tập: học viên dễ nhìn ra vai trò, dễ giải thích logic định tuyến, và dễ nối trực tiếp với hệ thống đã xây trước đó. Về mặt triển khai: chỉ cần bắt đầu từ hai đến ba worker là đủ để thấy giá trị, dễ gắn thêm một kết nối MCP, và supervisor thường chỉ cần một lượt gọi model nhỏ chứ không cần là model mạnh nhất. Ba pattern còn lại vẫn quan trọng để nhận diện đúng tình huống, nhưng phần thực hành sâu của ngày học tập trung vào supervisor-worker.

Kỹ năngHọc viên giải thích được vì sao supervisor-worker phù hợp làm điểm bắt đầu để thực hành xây một hệ nhiều agent.

Hình thứcVideo 4 phút.

Ý chính3 câu kiểm tra: đặc điểm nhận diện bốn pattern, rủi ro thiên vị trong debate, và lý do chọn supervisor-worker làm trục chính.

Kỹ năngHọc viên tự kiểm tra ba ý chính của module.

Hình thứcQuiz 3 câu, chấm ngay.

Ý chínhSupervisor không cần giỏi chuyên môn nhất — vai trò chính của nó là phân tích yêu cầu, quyết định worker nào cần tham gia, theo dõi trạng thái để thử lại khi cần, và tổng hợp kết quả cuối. Một worker tốt có ba đặc điểm: chỉ giữ một năng lực chính như truy xuất, gọi tool, hay tóm tắt; càng ít phụ thuộc vào lịch sử toàn hệ thống càng dễ kiểm tra độc lập; và có đầu vào, đầu ra đủ rõ để test riêng trước khi cắm vào supervisor. Nhầm lẫn phổ biến là nghĩ supervisor phải là model mạnh nhất trong hệ; thực tế nếu supervisor quá "thông minh", nó có xu hướng tự trả lời bằng kiến thức sẵn có thay vì định tuyến đúng việc cho worker.

Kỹ năngHọc viên phân biệt được vai trò supervisor và worker, và nêu được ba đặc điểm của một worker thiết kế tốt.

Hình thứcVideo 6 phút, sơ đồ supervisor và ba worker — truy xuất, gọi tool, tổng hợp — hiện dần.

Ý chínhBốn lỗi thiết kế lặp lại nhiều nhất: supervisor ôm luôn việc của worker và thực chất trở lại thành một agent đơn được đổi tên; worker liên tục hỏi ngược supervisor khiến chi phí giao tiếp tăng nhanh; thông tin bị truyền qua biến toàn cục nên không ai biết hệ đang ở bước nào; và worker gặp lỗi không trả về gì khiến supervisor chờ mãi. Đây cũng là chỗ dễ nhầm lẫn nhất: worker không phải là năng lực mà chỉ là nơi thực hiện công việc, còn năng lực — một hướng dẫn, một kỹ năng cụ thể — là thứ supervisor gọi ra khi cần; và không phải cứ tách được một phần việc thì nó đáng trở thành một worker riêng, đôi khi nó chỉ nên là một tool mà supervisor gọi trực tiếp.

Kỹ năngHọc viên nhận diện được bốn lỗi thiết kế trong một luồng cho sẵn, và phân biệt được khi nào một phần việc nên là worker, khi nào chỉ nên là tool.

Hình thứcVideo 7 phút, mỗi lỗi thiết kế có một đoạn luồng minh hoạ ngắn; phần ranh giới worker và tool có một ví dụ đối chiếu cụ thể.

Ý chínhHọc viên nhận một tình huống — một nhân viên hỏi được nghỉ theo chế độ bao lâu — và thử hai phiên bản phiếu giao việc: một phiên bản chỉ ghi "tìm chính sách liên quan", và một phiên bản ghi rõ nhiệm vụ, bối cảnh về diện áp dụng và quy định đang có hiệu lực, cùng định dạng đầu ra mong đợi. Học viên dự đoán worker sẽ trả lời đúng hay sai với từng phiên bản trước khi xem kết quả mô phỏng, từ đó thấy trực tiếp vì sao phiếu giao việc thiếu bối cảnh dễ khiến worker chọn nhầm dữ liệu cũ và đưa ra câu trả lời nghe hợp lý nhưng sai thực tế. Nguyên tắc rút ra là chỉ đưa đúng phần bối cảnh worker thực sự cần, không thêm không bớt.

Kỹ năngHọc viên viết được một phiếu giao việc đủ nhiệm vụ, bối cảnh và định dạng đầu ra cho một worker cụ thể.

Hình thứcỞ nhà: tương tác dự đoán rồi so sánh hai phiên bản phiếu giao việc, 5 phút. Trên lớp: viết phiếu giao việc cho một tình huống mới, 5 phút, có người hướng dẫn nhận xét. Phương án thay thế: đọc ví dụ hai phiên bản kèm giải thích, không tự viết.

Ý chínhMột trạng thái chung tối thiểu cho hệ supervisor-worker cần sáu trường: nhiệm vụ gốc, kế hoạch phân việc, kết quả từng worker, trạng thái xử lý, câu trả lời tổng hợp cuối, và nhật ký trace có mốc thời gian. Không có trace trong trạng thái chung, sau khi hệ chạy xong không ai biết agent nào đã đi con đường nào để ra kết quả đó — lỗi thường nằm ở tầng ngữ nghĩa, tức worker hiểu sai việc, chứ không phải một lỗi kỹ thuật dễ thấy, nên trace phải ghi lại nội dung vào ra thật chứ không chỉ thời gian chạy. Nên chuyển thông tin qua trạng thái chung có quy tắc rõ ai được đọc, ai được ghi, hơn là để các agent tự do trao đổi trực tiếp với nhau, vì cách sau dễ dẫn tới việc hai agent cùng ghi đè lên một phần dữ liệu.

Kỹ năngHọc viên liệt kê được sáu trường tối thiểu của trạng thái chung và giải thích được vì sao thiếu trace khiến hệ thống không debug được.

Hình thứcVideo 6 phút, từng trường trạng thái hiện kèm ví dụ giá trị thật.

Ý chính4 câu kiểm tra: vai trò supervisor và worker, một trong bốn lỗi thiết kế hay gặp, cách viết phiếu giao việc đủ rõ, và các trường bắt buộc trong trạng thái chung.

Kỹ năngHọc viên tự kiểm tra bốn ý chính của module.

Hình thứcQuiz 4 câu, chấm ngay.

Ý chínhTrước khi có một chuẩn chung, mỗi công cụ bên ngoài cần một đoạn tích hợp riêng: đăng nhập riêng, xử lý lỗi riêng, và khi công cụ đó đổi API thì đoạn tích hợp phải viết lại. Nếu nhiều nhóm cùng dùng một dịch vụ nội bộ nhưng mỗi nhóm tự viết một lớp kết nối riêng, dịch vụ đó chỉ cần đổi một chỗ là mọi lớp kết nối cùng phải sửa theo. MCP là một chuẩn giao tiếp chung để agent kết nối với năng lực bên ngoài: đổi phía cung cấp năng lực chỉ cần sửa ở MCP server, đổi phía agent không ảnh hưởng đến năng lực đang được dùng — lợi ích đi theo cả hai chiều.

Kỹ năngHọc viên giải thích được vấn đề MCP giải quyết bằng một ví dụ tích hợp cụ thể.

Hình thứcVideo 6 phút, ví dụ trước và sau khi có MCP trên cùng một dịch vụ nội bộ.

Ý chínhMột agent kết nối tới một MCP server qua một client; máy chủ đó công bố ba loại năng lực: tool là thao tác có thể thực thi, ví dụ tra cứu hoặc tạo yêu cầu; resource là tài nguyên chỉ đọc như một schema hay danh mục dữ liệu, giúp agent sinh truy vấn chính xác hơn; và prompt là một cách gọi năng lực đã chuẩn hoá để giảm lỗi. Luồng khám phá diễn ra theo sáu bước: agent kết nối, lấy danh sách tool, đọc mô tả và schema từng tool, chọn tool phù hợp, gọi tool với đúng tham số, và nhận kết quả — agent không cần được lập trình sẵn để biết một tool tồn tại, nó khám phá được tool đó ngay khi chạy.

Kỹ năngHọc viên phân biệt được tool, resource và prompt trong MCP, và mô tả được luồng khám phá tool.

Hình thứcVideo 6 phút, sơ đồ kiến trúc và luồng sáu bước hiện dần.

Ý chínhHọc viên kết nối tới một MCP server mẫu, đọc schema của một tool có tham số kiểu số, và dự đoán điều gì xảy ra nếu gọi tool đó với một giá trị kiểu chữ trước khi thử thật. Kết quả cho thấy máy chủ tự chối tham số sai kiểu dựa trên schema đã công bố, không cần agent hay người dùng viết thêm logic kiểm tra — hoạt động cho thấy trực tiếp vì sao khai báo schema rõ ràng ở MCP server giúp toàn hệ thống an toàn hơn, kể cả khi phía agent có lỗi.

Kỹ năngHọc viên tự thực hiện được một lượt gọi tool qua MCP và giải thích được vì sao schema giúp chặn lỗi từ sớm.

Hình thứcTương tác thực hành 5 phút trên MCP Inspector nhúng sẵn, có hướng dẫn từng bước. Cần người hướng dẫn hỗ trợ thiết lập kết nối ban đầu. Phương án thay thế: video ghi màn hình thao tác tương tự, 4 phút.

Ý chínhVì mọi năng lực bên ngoài đều phải đi qua MCP server, đây là nơi đặt các lớp phòng thủ trước khi worker chạm vào dữ liệu thật: quyền tối thiểu, tức chỉ công bố đúng tool cần thiết và không công bố thao tác nguy hiểm nếu worker không cần; yêu cầu người duyệt cho thao tác thay đổi dữ liệu nhạy cảm; và chạy trong môi trường cô lập cho các thao tác rủi ro cao. Một chỉ dẫn ẩn trong nội dung mà tool trả về, ví dụ một đoạn văn bản cố tình yêu cầu agent bỏ qua hướng dẫn ban đầu, cũng nên bị chặn ở tầng này trước khi tới agent, vì xử lý ở tầng prompt sau khi nội dung đã vào ngữ cảnh thường là quá muộn.

Kỹ năngHọc viên nêu được ba lớp phòng thủ đặt ở MCP server và giải thích được vì sao chặn ở đó hiệu quả hơn chặn ở tầng prompt.

Hình thứcVideo 5 phút.

Ý chính3 câu kiểm tra: vấn đề MCP giải quyết, phân biệt tool, resource và prompt, và một lớp phòng thủ bảo mật đặt ở MCP server.

Kỹ năngHọc viên tự kiểm tra ba ý chính của module.

Hình thứcQuiz 3 câu, chấm ngay.

Ý chínhMCP trả lời câu hỏi agent lấy năng lực từ đâu — nó nối agent với tool hoặc dữ liệu, và bên nhận không tự quyết định gì, chỉ thực thi đúng như được gọi. A2A trả lời câu hỏi khác: giao việc cho agent nào — bên nhận là một agent khác có thể tự quyết cách làm, có thể từ chối, và có thể chạy trong một khoảng thời gian dài trước khi trả kết quả. Nhầm lẫn phổ biến là coi A2A chỉ là một loại tool khác; điểm khác biệt cốt lõi nằm ở việc bên nhận công việc trong A2A có quyền tự chủ, còn một tool thì không.

Kỹ năngHọc viên phân biệt được MCP với A2A qua ba tiêu chí: bên nhận có tự quyết không, có thể từ chối không, và có thể chạy lâu không.

Hình thứcỞ nhà: tương tác đối chiếu MCP và A2A trên cùng một sơ đồ, 5 phút. Trên lớp: bài tập phân loại sáu tình huống là MCP hay A2A, 4 phút, có người hướng dẫn giải thích các trường hợp gây tranh cãi. Phương án thay thế: bảng đối chiếu một trang, tự đọc và tự kiểm.

Ý chínhMột agent công bố năng lực của mình qua agent card — một bản mô tả gồm định danh, các kỹ năng cụ thể nó làm được, và điểm kết nối — để agent khác biết nên gọi ai cho việc gì, tương tự một hồ sơ năng lực công khai. Một phiếu giao việc tối thiểu giữa hai agent cần ba phần: việc cần làm, bối cảnh để làm đúng việc đó, và định dạng đầu ra mong đợi; quá ít bối cảnh khiến bên nhận phải hỏi lại nhiều lần, quá nhiều bối cảnh khiến việc xử lý chậm và khó bảo trì khi phiếu đổi. Nguyên tắc áp dụng giống với worker ở module 3: chỉ đưa đúng phần bối cảnh bên nhận thực sự cần.

Kỹ năngHọc viên viết được một phiếu giao việc ba phần cho một tình huống giao việc giữa hai agent.

Hình thứcVideo 6 phút, ví dụ phiếu giao việc quá ít và đủ bối cảnh đặt cạnh nhau để so sánh.

Ý chínhHai cách một agent chờ kết quả từ agent khác: cách thứ nhất là bên gọi dừng lại và chờ đến khi có kết quả, đơn giản để hiểu và debug nhưng dễ kéo dài toàn bộ luồng; cách thứ hai là bên gọi tiếp tục việc khác và bên nhận báo lại khi xong, tận dụng được việc chạy song song nhưng cần quản lý trạng thái và thời hạn chờ chặt hơn. Học viên dự đoán cách nào phù hợp hơn cho hai tình huống — một tình huống cần trả lời ngay cho người dùng đang chờ, một tình huống chạy báo cáo định kỳ không ai chờ trực tiếp — trước khi xem kết quả mô phỏng độ trễ của từng lựa chọn.

Kỹ năngHọc viên chọn được cách chờ phù hợp cho một tình huống cụ thể.

Hình thứcTương tác mô phỏng 3 phút, hai tình huống cấu hình sẵn hiển thị độ trễ khác nhau. Phương án thay thế: video so sánh hai tình huống, 3 phút.

Ý chínhA2A là một chuẩn còn khá mới và phạm vi ứng dụng thực tế trong một sản phẩm đơn lẻ hiện còn hẹp — phần lớn hệ thống nhiều agent hiện nay vẫn giao tiếp trong cùng một tiến trình thay vì qua một chuẩn mở như A2A. A2A trở nên cần thiết khi các agent thực sự chạy ở môi trường khác nhau, tổ chức khác nhau, hoặc dùng công nghệ nền khác nhau, và cần một cách giao tiếp không phụ thuộc vào việc bên kia được viết bằng gì. Với phần lớn hệ thống trong ngày học này, việc nắm vững khái niệm A2A quan trọng hơn việc thuộc chi tiết đặc tả giao thức.

Kỹ năngHọc viên xác định được khi nào A2A thật sự cần thiết so với khi nào giao tiếp nội bộ trong một hệ thống là đủ.

Hình thứcVideo 4 phút.

Ý chính3 câu kiểm tra: phân biệt MCP với A2A, ba phần của một phiếu giao việc giữa hai agent, và lựa chọn cách chờ theo tình huống.

Kỹ năngHọc viên tự kiểm tra ba ý chính của module.

Hình thứcQuiz 3 câu, chấm ngay.

Ý chínhKhông có một framework điều phối, logic định tuyến thường nằm trong một prompt dài, khó biết hệ đang ở bước nào, và thêm một nhánh xử lý mới nghĩa là phải sửa lại cả prompt đó. LangGraph, framework điều phối dùng xuyên ngày học, biểu diễn luồng chạy bằng ba khái niệm: node là một bước xử lý — một agent hoặc một hành động; edge là đường đi giữa các bước, có thể cố định hoặc có điều kiện tuỳ theo trạng thái hiện tại; và trạng thái là dữ liệu được truyền qua từng bước. Cách biểu diễn này giúp logic định tuyến trở thành mã có thể đọc và kiểm tra được, thay vì ẩn trong một đoạn văn bản dài.

Kỹ năngHọc viên giải thích được vai trò của node, edge và trạng thái trong một framework điều phối.

Hình thứcVideo 6 phút, sơ đồ luồng có nhánh điều kiện và một điểm dừng để con người xem lại.

Ý chínhMột đoạn định nghĩa StateGraph điển hình gồm ba phần: khai báo cấu trúc trạng thái được truyền qua các bước, một hàm quyết định bước tiếp theo dựa trên trạng thái hiện tại, và phần ghép các bước cùng đường đi có điều kiện thành một luồng hoàn chỉnh. Đọc kỹ đoạn định nghĩa này cho thấy quyết định định tuyến nằm ở đâu và dựa trên trường dữ liệu nào — đây là kỹ năng cần thiết trước khi tự viết một luồng tương tự trong lab.

Kỹ năngHọc viên đọc hiểu được một đoạn định nghĩa luồng điều phối và chỉ ra được chỗ quyết định bước tiếp theo.

Hình thứcVideo 7 phút ghi màn hình, đọc từng phần của đoạn định nghĩa và giải thích.

Ý chínhHọc viên nhận một trace của một luồng xử lý yêu cầu hoàn tiền: một worker trả về kết quả rỗng nhưng trạng thái vẫn ghi "thành công", và agent tổng hợp phía sau tạo ra một câu trả lời nghe hợp lý dựa trên kết quả rỗng đó. Học viên dự đoán lỗi nằm ở bước nào trước khi xem lời giải, từ đó rút ra nguyên tắc thiết kế: một worker không tìm thấy kết quả phải báo rõ không tìm thấy, thay vì trả về trạng thái thành công với dữ liệu rỗng.

Kỹ năngHọc viên đọc được một trace để xác định lỗi nằm ở bước định tuyến, bước xử lý, hay bước tổng hợp.

Hình thứcBài tập 5 phút trên một trace cấu hình sẵn, có người hướng dẫn thảo luận sau khi học viên đưa ra dự đoán. Phương án thay thế: đọc lời giải có chú thích từng bước, không cần dự đoán trước.

Ý chínhThêm agent không miễn phí — mỗi agent thường tốn ít nhất một lượt gọi model, và một hệ nhiều agent có thể tốn nhiều lần số token so với một lượt hỏi đáp đơn, tuỳ vào số bước và số lần thử lại. Đổi lại, hệ nhiều agent thường dễ debug hơn nhờ có trace rõ, chuyên biệt hoá tốt hơn theo từng vai trò, và dễ mở rộng thêm worker mới hơn một agent đơn đã cồng kềnh. Khi một worker thất bại, nguyên tắc thiết kế là hỏng có kiểm soát: có thời hạn chờ rõ ràng, có giới hạn số lần thử lại, và khi không đủ tự tin thì trả lời với phần đã có kèm lời báo rõ phần còn thiếu, thay vì để hệ thống im lặng hoặc đoán bừa.

Kỹ năngHọc viên nêu được sự đánh đổi chính giữa một agent và nhiều agent, và mô tả được thế nào là hỏng có kiểm soát.

Hình thứcVideo 6 phút, bảng so sánh một agent và nhiều agent theo chi phí, độ trễ, khả năng debug và khả năng mở rộng.

Ý chính4 câu kiểm tra: vai trò của node, edge và trạng thái, cách đọc một trace để tìm bước sai, đánh đổi chi phí khi thêm agent, và nguyên tắc hỏng có kiểm soát.

Kỹ năngHọc viên tự kiểm tra bốn ý chính của module trước khi vào lab.

Hình thứcQuiz 4 câu, chấm ngay.

Ý chínhGiảng viên trả lời câu hỏi mở đầu bằng năm điểm chính: multi-agent là một đánh đổi chỉ nên chọn khi một agent thật sự quá tải chứ không phải mặc định tốt hơn; chọn pattern theo loại phức tạp của bài toán chứ không theo pattern nghe hay nhất; một phiếu giao việc đủ rõ quyết định phần lớn chất lượng của một hệ nhiều agent; MCP giải quyết việc kết nối agent với tool còn A2A giải quyết việc giao việc cho agent khác — hai việc khác nhau và không thay thế nhau; và trace là điều kiện bắt buộc để debug và cải thiện một hệ nhiều agent theo thời gian.

Kỹ năngHọc viên tóm tắt được năm điểm chính bằng ngôn ngữ của mình.

Hình thứcVideo giảng viên, 3 phút.

Ý chínhMột luồng điều phối có thể lưu lại trạng thái giữa các bước bằng checkpointer gắn với một định danh phiên (thread id), cho phép tiếp tục đúng chỗ đã dừng thay vì chạy lại từ đầu — đây là nền tảng cho trí nhớ nhiều lượt và cho việc tạm dừng luồng để con người xem lại trước khi đi tiếp. Khi luồng tạm dừng bằng interrupt() để chờ con người quyết định, nó cần được tiếp tục lại đúng từ điểm dừng đó với quyết định của con người được đưa vào, và bước đã tạm dừng có thể chạy lại từ đầu khi tiếp tục, nên các thao tác có hiệu ứng phụ trong bước đó cần được viết sao cho chạy lại nhiều lần vẫn cho cùng kết quả. Mở rộng cho item 6.1 và 6.2.

Kỹ năngHọc viên giải thích được vì sao lưu trạng thái giữa các bước cần thiết cho trí nhớ nhiều lượt và cho điểm dừng có con người xem lại.

Hình thứcVideo 8 phút, ví dụ đoạn mã tối giản có chú thích.

Ý chínhNgoài framework được dùng xuyên ngày học, một vài framework điều phối khác cũng phổ biến: CrewAI để agent tự quyết vai trò khá tự do, phù hợp thử nhanh nhưng khó kiểm soát chặt; AutoGen tổ chức theo lượt hội thoại nhóm; và OpenAI Agents SDK thiên về handoff trực tiếp giữa hai agent, tốt cho supervisor-worker đơn giản nhưng theo dõi trạng thái yếu hơn. Không có framework nào đúng cho mọi trường hợp — lựa chọn phụ thuộc vào mức độ cần kiểm soát luồng chạy so với mức độ cần agent tự do quyết định. Mở rộng cho module 2.

Kỹ năngHọc viên nêu được tiêu chí chọn giữa các framework điều phối theo mức độ kiểm soát cần có.

Hình thứcVideo 7 phút, bảng so sánh bốn framework.

Ý chínhMột trace tự viết ở dạng nhật ký có cấu trúc — thời điểm, agent nào, hành động gì, đầu vào đầu ra tóm tắt, trạng thái — thực chất đã là một dạng đơn giản của việc theo dõi phân tán, nơi mỗi bước xử lý được ghi lại như một đoạn trong một chuỗi lớn hơn, và nhiều đoạn từ nhiều dịch vụ khác nhau có thể nối lại thành một luồng hoàn chỉnh nhờ cùng một định danh xuyên suốt. Công cụ như LangSmith hay Langfuse hiển thị trace này thành cây gọi đọc được; OpenTelemetry là chuẩn mở thống nhất cách đặt tên các trường, giúp một trace ghi ra đọc được bởi nhiều công cụ quan sát khác nhau mà không cần chuyển đổi định dạng. Mở rộng cho item 6.3.

Kỹ năngHọc viên hiểu được cách một trace tự viết mở rộng thành theo dõi phân tán khi hệ thống có nhiều dịch vụ.

Hình thứcVideo 8 phút.

Ý chínhTách hệ thống truy xuất và trả lời của Ngày 8 thành một supervisor và hai đến ba worker chuyên biệt — truy xuất, gọi tool, tổng hợp; thiết kế một trạng thái chung có đủ các trường tối thiểu đã học; kết nối một worker với một năng lực bên ngoài qua MCP; viết phiếu giao việc tối thiểu giữa supervisor và từng worker; và ghi trace cho toàn bộ luồng để có thể giải thích agent nào đã làm gì. Học viên nộp mã nguồn chạy được kèm một bản trace mẫu.

Kỹ năngHọc viên tự xây dựng được một hệ supervisor-worker nhỏ có kết nối MCP và trace đọc được.

Hình thứcLab 150 phút tại lớp với người hướng dẫn, theo repo có sẵn. Kèm bộ khởi tạo trạng thái chung và mã mẫu kết nối MCP, có sẵn vị trí điền cấu hình.