ai-agent-book/book-vi/reference-answers.vi.md

Đáp án tham khảo cho các câu hỏi tư duy

Tài liệu này tổng hợp đề cương đáp án tham khảo cho các câu hỏi tư duy ở cuối mười chương của cuốn sách. Các câu hỏi tư duy chủ yếu là câu hỏi mở, không có đáp án duy nhất. Các đáp án tham khảo do AI tạo ra, đã được con người rà soát sơ bộ, chỉ dùng để đối chiếu và gợi mở cho người đọc. Khuyến nghị người đọc sử dụng LLM kết hợp với nội dung bản thảo để thảo luận sâu hơn về các vấn đề này.

Chương 1 AI Agent Bắt đầu

1. (★★) Nếu bạn chỉ có thể thêm một khả năng vào hệ thống Agent—một mô hình mạnh hơn, ngữ cảnh phong phú hơn hoặc nhiều công cụ hơn—bạn sẽ chọn cái nào? Trong những điều kiện nào sự lựa chọn của bạn sẽ thay đổi?

Theo công thức "bộ não/mắt/tay chân", trước tiên hãy tìm mắt xích yếu nhất: thường ưu tiên bổ sung ngữ cảnh, tức mở rộng observation space (không gian quan sát). Nếu nhiệm vụ vượt quá khả năng suy luận của mô hình, hãy đổi sang mô hình mạnh hơn. Nếu action space không đủ (ví dụ không truy cập được hệ thống nội bộ công ty), hãy thêm công cụ. Cơ sở phán đoán là phân tích các trajectory thất bại, xác định nút thắt nằm ở nhận thức, ra quyết định hay hành động.

2. (★★★) Trong vòng lặp ReAct, tổng lượng đọc cache tăng gần theo bậc hai với số vòng. Làm thế nào để giảm mức tăng này?

Ở vòng i, độ dài prefix trong cache xấp xỉ tỷ lệ với i, nên tổng lượng đọc là 1 + 2 + ... + n = O(n²). Phần tăng theo bậc hai là chi phí đọc cache tích lũy, không phải độ dài trajectory hay dung lượng KV Cache; hai đại lượng sau tăng gần tuyến tính. Khi đạt ngưỡng token, có thể nén theo lô phần trajectory cũ và chỉ giữ kết luận cùng trạng thái then chốt; các kết quả trung gian lớn có thể được lưu bên ngoài để truy xuất khi cần hoặc cô lập trong Agent con. Không nên nén ở mọi vòng vì có thể làm giảm hiệu năng của Agent, đồng thời phát sinh thêm lệnh gọi nén và chi phí dựng lại cache.

3. (★★) Mô hình “Mô hình là Agent” có nghĩa là mô hình ngày càng trở nên tự chủ hơn trong các quyết định gọi công cụ. Nhưng chương này chứng tỏ rằng Harness Engineering lại ngày càng trở nên quan trọng. Làm thế nào để hai xu hướng này cùng tồn tại? Giá trị cốt lõi trong tương lai của khung Agent sẽ được phản ánh ở những khía cạnh nào?

Ẩn dụ ngựa và dây cương: mô hình càng mạnh, không gian tự chủ càng lớn, phạm vi ảnh hưởng khi sai càng lớn, càng cần ràng buộc, xác minh, sửa chữa. Giá trị của framework chuyển từ "điều phối các lần gọi LLM" sang tầng bảo đảm trong năm yếu tố của Harness: phân loại quyền hạn, circuit breaker (cầu dao ngắt), khôi phục lỗi, nén ngữ cảnh, hệ sinh thái công cụ.

4. (★★) Việc thiếu “phản hồi kết quả công cụ” trong thí nghiệm cắt bỏ đã khiến Agent rơi vào một vòng lặp vô hạn. Trong môi trường sản xuất, ngoài kết quả công cụ bị thiếu, tình huống nào khác có thể gây ra vòng lặp vô hạn cho Agent? Bạn sẽ thiết kế cơ chế phát hiện và chấm dứt nào?

Các tác nhân khác: công cụ lặp lại cùng một lỗi, gọi ảo giác một công cụ không tồn tại, ngữ cảnh bị nén mất trạng thái then chốt, quá trình suy nghĩ bị tước bỏ khiến API mô hình báo lỗi, bản thân nhiệm vụ không có lời giải. Cơ chế: đặt điều kiện dừng như số vòng lặp tối đa; phát hiện lời gọi lặp lại (dấu vân tay công cụ + tham số giống nhau); vượt ngưỡng thất bại thì leo thang cho con người can thiệp.

5. (★) Chương này phân tích năm sản phẩm Agent sử dụng ba khía cạnh: nhận thức, hành động và chiến lược. Vui lòng chọn một sản phẩm AI mà bạn sử dụng hàng ngày, phân tích nó bằng ba chiều này và suy nghĩ xem thiết kế kiến trúc của nó có hợp lý hay không. Nếu bạn thiết kế sản phẩm AI này, thì sẽ có chỗ nào để cải thiện?

Câu hỏi mở. Điểm chính: mô phỏng bảng trong chương, viết ra đôi mắt (nhìn thấy nguồn thông tin nào), tay chân (action space có mở không, có thể suy nghĩ nội tâm không), chiến lược (mô thức vòng lặp thực thi của Agent).

6. (★★) Nếu bạn thiết kế một hệ thống dịch vụ khách hàng đặc biệt để xử lý việc đặt vé máy bay, bạn sẽ chọn mô hình quy trình làm việc hay mô hình Agent tự động? Có thể kết hợp cả hai chế độ trong cùng một hệ thống?

Phần chính dùng workflow: xác minh danh tính → tìm kiếm → thanh toán → đặt vé, bốn nút, bảo đảm thứ tự tuân thủ như "không được đặt vé trước khi thanh toán", đồng thời giới hạn bề mặt tấn công prompt injection trong một nút đơn lẻ. Các khâu mở (hiểu nhu cầu, đổi vé, gợi ý phương án thay thế khi chuyến bay bị hủy) chuyển sang Agent tự chủ. Các thao tác rủi ro cao (thanh toán số tiền lớn, hoàn tiền) thêm xác nhận của con người.

7. (★★★) Phần guardrails đề cập đến xếp hạng rủi ro của công cụ. Bạn sẽ thiết kế đánh giá rủi ro động như thế nào nếu một công cụ hầu như luôn có rủi ro thấp nhưng lại trở nên rủi ro cao dưới sự kết hợp các tham số cụ thể (ví dụ: delete_file xóa các tệp thông thường và xóa các tệp hệ thống)?

Đối tượng xếp hạng được tinh chỉnh từ "công cụ" xuống "công cụ + tham số": tính rủi ro tại thời điểm gọi theo tính khả nghịch đảo, quyền hạn và phạm vi ảnh hưởng. Dùng kiểm tra xác định dựa trên luật (danh sách đen/trắng đường dẫn, regex) thay vì phán đoán của mô hình. Việc xác minh chỉ nên nhìn dữ liệu có cấu trúc, chống thao túng bởi prompt injection.

8. (★★) Trong bảng sản phẩm Agent ở chương này, tất cả các không gian hành động của Agent đều là “mở”. Trong những tình huống nào thì không gian hành động bị hạn chế (chẳng hạn như chỉ có thể chọn từ các tùy chọn được xác định trước) sẽ thích hợp hơn không gian mở?

Các tình huống tuân thủ cao, rủi ro cao, lỗi không thể đảo ngược: như hoàn tiền, thanh toán, phương án giới hạn chính là "ràng buộc", tự nhiên chống sai sót, khiến lỗi không thể xảy ra ngay từ thiết kế.

9. (★★) Cơ chế can thiệp thủ công yêu cầu Agent “trao quyền điều khiển một cách duyên dáng”. Nhưng trên thực tế, người dùng có thể ngoại tuyến, phản hồi chậm hoặc đưa ra những hướng dẫn mơ hồ. Agent nên làm gì vào lúc này?

Fail-safe: thao tác rủi ro cao khi không có xác nhận thì tạm dừng chứ không mặc định thực thi; làm trước phần rủi ro thấp có thể đảo ngược, ghi chép tài liệu phần rủi ro cao, thuận tiện cho con người quyết định và Agent khôi phục; dùng công cụ giao tiếp bất đồng bộ (tin nhắn, email) để thông báo và đặt chiến lược timeout; khi chỉ dẫn mơ hồ thì làm rõ ý định.

10. (★★★) Phần giới thiệu chỉ ra rằng “các nguyên tắc thiết kế tốt phải vượt qua các chu kỳ lặp của mô hình”, nhưng những biện pháp kỹ thuật cụ thể dùng để thực hiện các nguyên tắc đó có thể trở nên lỗi thời khi năng lực mô hình tiến bộ. Hãy nêu một biện pháp kỹ thuật Agent như vậy và giải thích lý do.

Ví dụ 1: dùng constrained sampling để buộc lời gọi công cụ tuân theo một định dạng nghiêm ngặt. Đây là biện pháp vá độ tin cậy cho những mô hình thường xuất JSON không hợp lệ hoặc bỏ sót tham số. Lợi ích của nó có thể giảm khi khả năng tuân thủ định dạng của mô hình tăng lên, dù các tình huống rủi ro cao vẫn nên giữ bước kiểm tra định dạng mang tính tất định.

Ví dụ 2: đưa vào một cơ sở tri thức bên ngoài để bù đắp việc mô hình không thể liên tục hấp thụ kiến thức mới. Nếu trong tương lai mô hình có năng lực học liên tục đáng tin cậy, một phần công việc duy trì tri thức có thể chuyển từ hệ thống bên ngoài vào tham số mô hình. Tuy nhiên, cơ sở tri thức bên ngoài vẫn có giá trị riêng đối với cập nhật thời gian thực, truy xuất chính xác, kiểm soát truy cập và truy vết nguồn; vì vậy phạm vi sử dụng của chúng có thể thu hẹp hơn là biến mất hoàn toàn.

Ví dụ 3: yêu cầu mọi năng lực phải được cung cấp qua giao diện gọi công cụ tiêu chuẩn của API mô hình và cấm định dạng gọi tùy chỉnh. Skills cho thấy một hướng khác: mô tả năng lực và cách sử dụng bằng văn bản, rồi để mô hình thực thi qua công cụ dòng lệnh đa dụng. Từ góc nhìn của mô hình, điều này tương đương với việc hiểu và tuân theo một giao thức gọi bằng văn bản tùy chỉnh nằm trên một bộ thực thi chung. Khi mô hình hiểu các giao diện tùy ý tốt hơn, “luôn phải dùng định dạng gọi công cụ tiêu chuẩn” không còn là nguyên tắc phổ quát. Định dạng tiêu chuẩn vẫn hữu ích cho khả năng tương tác, kiểm tra có cấu trúc và các mô hình yếu hơn, nhưng nên là lựa chọn kỹ thuật tùy theo bối cảnh.

Ví dụ 4: yêu cầu prompt và toàn bộ định nghĩa công cụ phải được đặt sẵn ở đầu context. Cách làm này xuất phát từ việc các mô hình ban đầu còn hạn chế về khả năng tuân theo chỉ dẫn và thường không nhận diện hoặc thực thi đúng prompt hay định nghĩa công cụ nằm ngoài vị trí cố định quen thuộc. Skills nạp prompt vào giữa context khi cần, còn cơ chế khám phá công cụ động nối định nghĩa công cụ mới tìm thấy vào sau trajectory hiện có. Khi khả năng tuân theo chỉ dẫn tăng lên và mô hình được post-training chuyên biệt cho các kiểu nạp động này, prompt và định nghĩa công cụ không còn bắt buộc phải nằm cố định ở đầu context.

Chương 2 Context Engineering (kỹ thuật ngữ cảnh)

1. (★★★) Thử nghiệm 2-3 nhận thấy rằng lịch sử hội thoại cửa sổ trượt sẽ khiến Agent liên tục thực hiện cùng một lệnh gọi công cụ. Nhưng việc giữ nguyên lịch sử sẽ mở rộng ngữ cảnh. Thiết kế chiến lược tránh mất thông tin trong khi kiểm soát độ dài ngữ cảnh mà không phá hủy tiền tố KV Cache.

① Dùng nén thay vì loại bỏ: message chỉ thêm vào chứ không xóa sửa, khi gần ngưỡng (ví dụ 80% cửa sổ) thì nén hàng loạt các tool result cũ. ② Cơ chế phân tầng: đầu ra lớn ghi xuống đĩa để lại tóm tắt, nhiễu xóa thẳng, tóm tắt kiểu lưu trữ giữ lại mạch văn. ③ Cô lập bằng Agent con, khiến trạng thái trung gian không đi vào ngữ cảnh chính.

2. (★★) Cơ chế lưu giữ chuỗi suy nghĩ của Chat Template Qwen3 chỉ giữ lại các suy nghĩ “sau tin nhắn thực cuối cùng của người dùng”. Nếu vòng lặp ReAct kéo dài hàng trăm lệnh gọi công cụ, thì nội dung tư duy tích lũy có thể tiêu tốn rất nhiều ngữ cảnh. Bạn sẽ sửa đổi cơ chế này như thế nào để xử lý các vòng lặp cực dài? DeepSeek R1 từng yêu cầu loại bỏ toàn bộ tư duy lịch sử, trong khi DeepSeek V4 đảo ngược thành bắt buộc trả lại toàn bộ reasoning_content - so sánh hai chiến lược ngược chiều này, ưu và nhược điểm của mỗi chiến lược là gì? Sự đảo ngược này cho thấy điều gì?

Hướng sửa đổi: giữ theo cửa sổ trượt — giữ nguyên vẹn phần suy nghĩ của một số vòng gần nhất, ngoài cửa sổ thì kích hoạt nén cuộn theo ngân sách token (chứ không theo số vòng cố định), tạo ra thanh trạng thái có cấu trúc (mục tiêu hiện tại, sự thật đã xác nhận, đường đã loại trừ, việc cần làm), việc nén chỉ xảy ra một lần và ở vị trí cố định, chi phí tái dựng cache là một lần chứ không trả mỗi vòng. R1 tước bỏ: tiết kiệm token, prefix ổn định thân thiện với cache, và nhất quán với phân phối huấn luyện (CoT lịch sử không bao giờ có trong đầu vào); nhưng mỗi vòng suy luận từ đầu, mất kế hoạch tầm xa, dễ lặp lại lỗi. V4 bắt buộc truyền lại: mạch suy nghĩ liên tục, hiệu năng tốt hơn trên nhiệm vụ agent tầm xa; nhưng chi phí token cao, prefix phình to mỗi vòng, và không thể chuyển liền mạch từ chế độ không think. Sự đảo ngược cho thấy: với tình huống hội thoại thuần túy, suy nghĩ là phế liệu; với tình huống agentic, suy nghĩ là trạng thái — thực hành ngành đã ngả về phía sau.

3. (★★) Trong thử nghiệm nén nhận biết ngữ cảnh, từ khoảng 148K ký tự đến khoảng 2.000 ký tự, liệu có nguy cơ "mất thông tin không thể đảo ngược" trong quá trình nén cực độ này không? Làm thế nào để giải quyết nó?

Có nguy cơ, nén là phép chiếu có tổn hao, vấn đề rơi vào chiều không được giữ lại thì hỏng. Cách giải: "nén có tổn hao + chỉ mục không tổn hao", mỗi sự thật kèm URL nguồn có thể truy ngược; đầu ra gốc lưu trên đĩa, chỉ xem bản xem trước tóm tắt; giữ lại theo độ ưu tiên tường minh — quyết định kiến trúc, tính toàn vẹn ngữ nghĩa (thời gian, tên công ty), trạng thái xác minh, các định danh như UUID/hash giữ nguyên; cửa sổ thích ứng trì hoãn thời điểm nén.

4. (★★) Thanh trạng thái Agent làm cho trạng thái ẩn trở nên rõ ràng. Nhưng nếu bản thân thanh trạng thái chứa thông tin không chính xác (chẳng hạn như lỗi trong bộ đếm công cụ), Agent có thể đưa ra các quyết định có hại dựa trên thông tin không chính xác. Làm thế nào vấn đề "độ tin cậy siêu thông tin" này có thể được giảm bớt?

Mô hình gần như tin thanh trạng thái vô điều kiện, lỗi sẽ được truyền nguyên trạng. Giảm thiểu: ① Duy trì bằng mã xác định, tuyệt đối không để LLM thống kê hàng loạt lịch sử dài (nếu dùng cũng phải trích xuất từng mục, mã tổng hợp); ② Coi độ chính xác của thanh trạng thái như chỉ số production tuyến đầu để giám sát; ③ Thông tin chỉ đến từ quan sát đáng tin cậy về thế giới thực, chống đầu độc thanh trạng thái.

5. (★★) Các thí nghiệm cắt bỏ kỹ thuật nhanh chóng cho thấy sự nhầm lẫn trong tổ chức thông tin khiến tỷ lệ thành công giảm hơn 30%. Tuy nhiên, trong quá trình phát triển thực tế, các từ nhắc nhở của hệ thống thường được nhiều người duy trì ở những thời điểm khác nhau. Bạn sẽ sử dụng phương pháp kỹ thuật nào để ngăn chặn "sự gia tăng entropy" của các system prompt?

① Coi prompt như mã: version control, review, product manager định luật nghiệp vụ, kỹ sư phụ trách viết mã; ② Dùng benchmark kiểu Tau-Bench làm kiểm thử hồi quy, chạy thí nghiệm ablation trước và sau thay đổi để định vị ảnh hưởng; ③ Bắt buộc có cấu trúc: điều khiển theo quy trình SOP thay vì chất đống quy tắc, phân tầng bằng XML/Markdown; ④ Phân loại và đặt tên các đoạn theo "có thể cache/phá cache", nội dung động đặt sau ranh giới cache; ⑤ Nội dung phình to tách thành Skills tải theo nhu cầu.

6. (★★★) Chương này đề xuất rằng “In-Context Learning (học trong ngữ cảnh) về cơ bản là truy xuất hơn là suy luận”. Nếu khẳng định này là đúng thì tất cả các hướng tối ưu hóa hiện tại dựa trên việc “nhồi nhét thêm thông tin vào ngữ cảnh” cần phải được xem xét lại. Theo bạn nên khắc phục hạn chế này như thế nào?

Bổ sung tầng tinh luyện cho "cỗ máy truy xuất chỉ có một nửa": ① Chưng cất ngữ cảnh/thanh trạng thái, dùng mã tính sẵn kết luận để truy xuất trực tiếp; ② Nén chủ động, thay bản ghi thô bằng tri thức có cấu trúc mật độ cao; ③ Cô lập bằng Agent con, nhiễu không vào ngữ cảnh chính; ④ Tương tác làm trục thứ ba, thiết bị quan trắc bên ngoài ghi lại thông tin mới mà mô hình không tự nghĩ ra; ⑤ Hướng tiên phong: "ghi chú" KV Cache có thể chỉnh sửa, có thể tổ hợp, và kết tủa bộ nhớ xuyên phiên.

7. (★★★) Tiết lộ dần dần các Kỹ năng Chỉ tải đầy đủ nội dung khi Agent xác định là cần thiết. Nhưng bản thân phán đoán này phụ thuộc vào khả năng của mô hình - nếu mô hình không biết những gì nó không biết, nó không thể kích hoạt tải Kỹ năng một cách chính xác. Làm thế nào để giải quyết vấn đề “siêu nhận thức” này?

① Metadata của Skill (tên, mô tả) lưu trú trong ngữ cảnh, khiến mô hình luôn "biết mình sở hữu gì"; ② Description của Skill viết thành điều kiện định tuyến thay vì giới thiệu chức năng: "Use when / Don't use when", tránh mô tả quá rộng.

8. (★★) Trong cơ chế Kỹ năng, sau khi Agent đọc động các từ gợi ý từ tệp KỸ NĂNG, các thao tác tiếp theo có thể thực hiện đúng các hướng dẫn này không? Sự khác biệt giữa việc hỗ trợ chế độ Kỹ năng của các mô hình khác nhau là gì?

Phụ thuộc vào cách tiêm Skill: tiêm vào system prompt thì tuân theo mạnh nhất nhưng phá KV Cache; đọc như file thường vào giữa ngữ cảnh, khả năng tuân theo chỉ dẫn của mô hình có thể kém; tiêm vào cuối ngữ cảnh, tuân theo chỉ dẫn tốt hơn, nhưng mỗi lần gọi công cụ đều phải tính lại KV của phần skill, chi phí cao.

9. (★★★) Chương này nhấn mạnh rằng những thay đổi trong thông tin động (chẳng hạn như dấu thời gian hệ thống, thứ tự danh sách công cụ) có thể phá hủy các lần truy cập tiền tố KV Cache. Trong một hệ thống sản xuất có số lượng lớn công cụ và bộ công cụ thay đổi thường xuyên, bạn sẽ thiết kế bố cục ngữ cảnh như thế nào để tối đa hóa tỷ lệ nhấn bộ đệm?

① Một số ít công cụ cốt lõi ổn định (ví dụ bảy cái) + bộ thực thi đa dụng, năng lực cụ thể đi qua tiết lộ lũy tiến Skills, định nghĩa công cụ đóng băng trong prefix tĩnh, thứ tự cố định; ② Agent con và Agent cha giữ prefix giống nhau.

Chương 3 Bộ nhớ người dùng và cơ sở tri thức

1. (★★) Trong hệ thống bộ nhớ người dùng, khi cùng một người dùng cung cấp thông tin xung đột trong các phiên khác nhau (chẳng hạn như đề cập đến các địa chỉ nhà khác nhau hai lần), hệ thống bộ nhớ nên xử lý xung đột này như thế nào?

Dùng pipeline "trích xuất — đối chiếu — quyết định" kiểu Mem0: trước truy xuất vector ra bộ nhớ cũ gần giống, sau đó LLM phán định ADD/UPDATE/DELETE/NOOP, ví dụ "chuyển đến Thượng Hải" nên UPDATE ghi đè "sống ở Bắc Kinh"; phiên bản hóa: thông tin kiểu địa chỉ chỉ giữ phiên bản mới nhất và đánh dấu timestamp, kiểu kinh nghiệm làm việc giữ toàn bộ lịch sử; phía truy xuất có thể mượn tiền tố ngữ cảnh (nhân vật, thời gian, ý định, như vụ chuyển tiền điện sửa ba lần) để phán đoán mục nào cuối cùng có hiệu lực.

2. (★★) Truy xuất nhận biết ngữ cảnh sẽ gắn ngữ cảnh của tài liệu gốc vào từng đoạn. Nhưng nếu bản thân tài liệu gốc có cấu trúc kém hoặc chứa thông tin mâu thuẫn, cách tiếp cận này có thể lan truyền hoặc thậm chí khuếch đại lỗi. Bạn sẽ giới thiệu các tín hiệu "chất lượng thông tin" như thế nào trong giai đoạn truy xuất?

Học theo "tính thời hiệu và quản trị cơ sở tri thức": gắn metadata như số phiên bản, thời gian có hiệu lực/hết hiệu lực, nguồn vào chunk, khi truy xuất lọc bỏ nội dung đã hết hiệu lực, hoặc đánh dấu tường minh trong tiền tố "mục này đã bị bãi bỏ vào ngày nào"; giai đoạn rerank đưa độ uy tín nguồn, độ mới thời gian vào chấm điểm, thay vì chỉ nhìn độ liên quan ngữ nghĩa; trong kỳ lập chỉ mục, để LLM sinh tiền tố tiện thể phát hiện mâu thuẫn giữa các chunk và đánh dấu, tương tự phát hiện xung đột phiên bản của bộ nhớ.

3. (★★) Trích xuất thông tin đa phương thức chuyển đổi biểu đồ thành mô tả văn bản để truy xuất. Quá trình “dịch thuật” này có thể làm mất đi mối quan hệ không gian trong thông tin trực quan. Đưa ra một ví dụ cụ thể về sơ đồ mà một mô tả văn bản đơn giản không thể truyền tải đầy đủ và nghĩ ra cách để lưu giữ thông tin đó.

Ví dụ: quan hệ logic trong sơ đồ kiến trúc hệ thống, vị trí giao điểm của hai đường cong trong biểu đồ đường, hoặc tương ứng hàng cột giữa ô và tiêu đề trong bảng PDF. Phương án một: xử lý đa phương thức nguyên sinh; phương án hai: cung cấp công cụ phân tích hình ảnh đa phương thức.

4. (★★★) “Bài học cay đắng” của Rich Sutton lập luận rằng cách tiếp cận chung (tìm kiếm và học hỏi) cuối cùng sẽ hoạt động tốt hơn các tính năng được thiết kế thủ công. Toàn bộ hệ thống kiến thức (chiến lược phân đoạn, cấu trúc chỉ mục, đường dẫn truy xuất) được xây dựng trong chương này có phải là "thiết kế thủ công" không? Nếu khả năng của mô hình đủ mạnh, liệu những thiết kế này có được thay thế bằng một "đầu vào đầy đủ" đơn giản không?

Đúng là thiết kế thủ công, một số khâu (chunking, tinh chỉnh tham số fusion) có thể suy yếu theo ngữ cảnh dài; nhưng vụ mèo đen mèo trắng cho thấy "đầu vào toàn lượng" cũng không đủ: attention là truy xuất mềm, thống kê tổng hợp xuyên tài liệu vẫn cần tinh luyện trước trong kỳ lập chỉ mục; tri thức hết hạn cập nhật, cô lập quyền hạn/tenant, khả năng kiểm toán, chi phí — những ràng buộc kỹ thuật này không liên quan đến năng lực mô hình; và việc truy xuất cùng tinh luyện LLM trong kỳ lập chỉ mục bản thân nó là phương pháp đa dụng "tìm kiếm + học", không đối lập với bài học cay đắng.

5. (★★★) Khi khả năng của mô hình được cải thiện, bạn có nghĩ nền tảng kiến thức miền vẫn còn quan trọng không? Phải chăng một mô hình cơ sở mạnh mẽ trong tương lai sẽ chứa tất cả thông tin trong cơ sở tri thức miền, từ đó loại bỏ nhu cầu về cơ sở tri thức miền?

Vẫn quan trọng: dữ liệu huấn luyện có ngày cắt, cơ sở tri thức có thể cập nhật bất cứ lúc nào; quy trình nội bộ doanh nghiệp, án lệ riêng tư vốn không có trong ngữ liệu công khai; nhiều người dùng chia sẻ cần lọc quyền hạn và cô lập tenant, tri thức trong tham số không thể cắt tỉa theo người gọi; lưu trữ bên ngoài có thể kiểm toán, có thể quản lý phiên bản, có thể gỡ nội dung hết hiệu lực, bộ nhớ tham số khó làm được; ngay cả đi theo lộ tuyến tham số hóa (post-training / User as Engram), cũng đối mặt khó khăn "nhớ dễ, dùng để suy luận đa bước khó".

6. (★) RAPTOR xây dựng chỉ mục dạng cây thông qua tóm tắt phân cấp từ dưới lên và GraphRAG xây dựng chỉ mục cấu trúc biểu đồ thông qua các mối quan hệ thực thể. Hai chỉ mục có cấu trúc này có khả năng trả lời tốt những loại truy vấn nào?

RAPTOR: truy vấn kiểu "du hành xuyên tầng" từ khái niệm vĩ mô khoan dần xuống chi tiết, như trước định vị tóm tắt "tập lệnh SIMD" rồi đi sâu vào chi tiết SSE, kiêm lo cả hai độ hạt tổng quan và chi tiết. GraphRAG: suy luận quan hệ đa bước ("địa chỉ bệnh viện nơi bác sĩ của tôi làm việc" duyệt theo chuỗi quan hệ) và khử nhập nhằng thực thể (hai "bác sĩ Trương" là hai nút khác nhau) — loại truy vấn "A và B có quan hệ gì", tóm tắt cộng đồng còn cung cấp phân cụm chủ đề.

7. (★★) Mô hình hệ thống tệp tổ chức kiến thức thành cấu trúc phân cấp giống như hệ thống tệp. So với cơ sở dữ liệu vectơ truyền thống RAG, phương pháp này có lợi thế trong trường hợp nào?

Văn bản thuần túy có thể được người dùng đọc, chỉnh sửa, sửa trực tiếp, có thể dùng Git quản lý phiên bản và rollback, thích hợp tình huống cần người và máy cùng bảo trì, kiểm tra tri thức; Agent có năng lực write_file là có thể tự chủ ghi chép kinh nghiệm, hình thành vòng lặp bộ nhớ tự tiến hóa (học bên ngoài tham số mô hình); tiết lộ lũy tiến L0/L1/L2 khiến đa số truy vấn chỉ cần đến L1 là quyết định được, tiết kiệm token; tiền đề là xây dựng liên kết chéo và trang chỉ mục như Wikipedia, nếu không file cô lập càng nhiều càng khó truy xuất.

8. (★★★) Tự động khám phá “các yếu tố phán đoán” và “mức độ quan trọng của yếu tố” từ dữ liệu có cấu trúc (chẳng hạn như cơ sở dữ liệu quyết định tư pháp), về cơ bản cho phép Agent tóm tắt các quy tắc từ dữ liệu. Liệu việc khai thác kiến thức dựa trên dữ liệu này có thể đạt được chất lượng của các quy tắc viết tay của các chuyên gia con người không?

Ưu điểm: như thí nghiệm CAIL2018, phát hiện nhân tố "từ dưới lên" gắn với dữ liệu hơn tiên nghiệm của con người, có thể nắm bắt kinh nghiệm cân đo tiềm ẩn rải rác trong hàng vạn án lệ mà chuyên gia khó viết tường minh, và có thể định lượng. Hạn chế: LLM trích xuất sai sẽ gây ô nhiễm tri thức, thiên lệch của bản thân dữ liệu sẽ được kế thừa, nguyên mẫu phân cụm chỉ phản ánh tương quan, không nói rõ nhân quả. Thỏa hiệp: mô hình hóa định hướng dữ liệu + chuyên gia rà soát Schema và kết quả, mô hình điều khiển đặt câu hỏi, thống kê chống lưng giải thích.

9. (★★★) Hãy thiết kế đồng thời quy trình cập nhật gia tăng và tái tổ chức định kỳ cho một kho bộ nhớ người dùng bằng Markdown. Nếu Reviewer và Proposer dùng cùng một mô hình và Reviewer chỉ được xem các đoạn hội thoại do Proposer lựa chọn, hệ thống vẫn có thể hợp nhất những loại lỗi nào? Hãy trình bày cách cải thiện theo ba khía cạnh: tính độc lập của mô hình, độ bao phủ bằng chứng và quyền sử dụng công cụ.

Cập nhật tăng dần: hãy coi kho ký ức như một kho mã và cho mọi thay đổi đi qua một PR. Proposer trước hết truy hồi phần kiến thức cũ có liên quan, rồi đề xuất diff nhỏ nhất mà vẫn trọn vẹn, đồng thời duy trì liên kết, chỉ mục, siêu dữ liệu thời gian và tham chiếu bằng chứng; Reviewer thẩm định độc lập dựa trên kiến thức trước thay đổi, diff và bằng chứng gốc, khi trả lại thì đưa ra ý kiến khả thi trỏ tới bằng chứng và số dòng cụ thể; vòng lặp có số lần hoặc ngân sách chi phí tối đa, vượt ngưỡng thì chuyển cho người chứ không mặc định cho qua. Sau khi hợp nhất, CI kiểm tra định dạng, liên kết, siêu dữ liệu và nhãn quyền trước, rồi mới dựng lại tăng dần các khối và chỉ mục vector bị ảnh hưởng từ phiên bản đã hợp nhất. Dọn dẹp định kỳ: kích hoạt quét toàn bộ theo thời gian hoặc theo số mục mới, khử trùng lặp, gộp, tách tệp quá lớn và dựng lại trang lối vào; điều cốt yếu là quay lại hội thoại gốc theo từng đoạn để kiểm tra bản tóm tắt cũ có đánh rơi từ phủ định, điều kiện thời gian hay mệnh đề giới hạn nào không. Các phát biểu mâu thuẫn không nên hội tụ bằng "giữ cái mới nhất", mà phải truy về nguồn của từng phát biểu và ghi rõ điều kiện áp dụng; khi bằng chứng chưa đủ thì giữ nguyên mâu thuẫn và đánh dấu chờ xác nhận. Việc tái tổ chức cũng gửi dưới dạng PR, có thể tách theo thư mục, và sau khi tất cả đều qua thì ngoài dựng lại chỉ mục còn phải phát lại một nhóm ca truy hồi tiêu biểu để xác nhận kiến thức vốn tìm được nay không trở nên vô hình.

Cùng một mô hình cộng với các đoạn đã được chọn sẵn sẽ bỏ lọt ba loại lỗi. Tính độc lập của mô hình: mô hình cùng họ chia sẻ tiên nghiệm huấn luyện và điểm mù, nên Reviewer có xu hướng nhắc lại kết luận của Proposer thay vì quay về bằng chứng, và cùng một chỗ đọc sai sẽ không bị phát hiện — hãy dùng mô hình năng lực tương đương nhưng khác họ để thẩm định chéo. Độ phủ bằng chứng: chỉ nhìn các đoạn Proposer đã chọn thì trích dẫn cắt xén, các từ phủ định và điều kiện tiên quyết bị bỏ đi, cùng xung đột với những tệp khác đều không lộ ra — Reviewer phải tự truy vấn được toàn bộ kho tri thức và kho bằng chứng gốc, trong phạm vi tenant hoặc người dùng mà nó được cấp quyền. Quyền công cụ: nếu Proposer có thể ghi thẳng vào nhánh chính hoặc sửa chỉ mục đang chạy thì việc thẩm định chỉ là hình thức — hãy cưỡng chế phân vai: Proposer chỉ ghi vào nhánh làm việc, Reviewer chỉ đọc bằng chứng và nộp kết luận, chỉ quy trình hợp nhất mới được cập nhật nhánh chính và chỉ mục đang chạy, còn bản thân bộ kiểm chứng và cổng phát hành nằm ngoài phạm vi có thể sửa.

Chương 4 công cụ

1. (★★) Tiêu chuẩn MCP tách các định nghĩa công cụ khỏi khung Agent. Nhưng tiêu chuẩn hóa cũng có nghĩa là các mẫu tương tác công cụ phức tạp (chẳng hạn như đầu ra phát trực tuyến, giao tiếp hai chiều, phiên trạng thái) có thể khó diễn đạt trong các giao thức chuẩn. Bạn nghĩ MCP cần mở rộng những khả năng nào nhất trong tương lai?

Phần mở rộng cần thiết nhất là năng lực hướng sự kiện xuyên phiên. MCP đã hỗ trợ tương tác nhiều lượt, đăng ký thay đổi và tác vụ chạy dài, nhưng cốt lõi của nó vẫn là chuẩn hóa một lần gọi năng lực chứ không phải giữ Agent luôn trực tuyến. Việc đánh thức Agent khi có email mới hoặc callback bên ngoài, cũng như xếp hàng, tiếp tục và thử lại nhiều sự kiện, vẫn thuộc trách nhiệm của khung Agent. Các quy ước thống nhất hơn cho việc điều phối này sẽ mở rộng phạm vi của MCP mà không làm mất đi sự đơn giản của giao thức.

2. (★★) Trong MCP hệ sinh thái, các MCP máy chủ khác nhau có thể cung cấp các công cụ có chức năng chéo cao. Đại lý nên chọn loại nào khi phải đối mặt với nhiều công cụ từ các nguồn khác nhau nhưng có cùng một chức năng công cụ? Nếu khác nhau (ví dụ một cái trả về tóm tắt và một cái trả về toàn văn), liệu Tác nhân có khả năng nhận thức và khai thác sự khác biệt này không?

Căn cứ chọn: trước khi tích hợp rà soát mô tả, khóa phiên bản, cấp credential quyền tối thiểu, cảnh giác công cụ cùng tên che khuất (tool shadowing) định tuyến lời gọi nhạy cảm cho bên độc hại; lúc chạy dựa vào phân loại phân tầng và khám phá động để thu hẹp ứng viên. Mô hình có cảm nhận được khác biệt hay không, phụ thuộc vào chất lượng mô tả công cụ.

3. (★★) Chương này đề xuất một vòng khép kín “thực thi-xác minh-phản hồi” (chẳng hạn như tự động chạy linter sau khi viết mã). Mô hình "tự động xác minh ngay sau khi vận hành" này có thể được áp dụng cho những tình huống công cụ nào khác? Có một số hoạt động nào đó mà chi phí hoặc rủi ro xác minh vượt quá chi phí của chính hoạt động đó, khiến mô hình này không khả thi không?

Tình huống có thể tổng quát hóa: sửa cấu hình xong chạy thật trong sandbox, xác minh có hiệu lực; sinh tài liệu/slide xong render thành ảnh chụp, dùng năng lực đa phương thức của mô hình kiểm tra bố cục. Không khả thi: gửi email, quay số điện thoại, chuyển tiền ra ngoài — thao tác không thể đảo ngược không lũy đẳng: hoặc không quan sát được, hoặc bản thân lại kích hoạt một sự kiện thế giới thực; lúc này nên đổi sang thủ đoạn sự kiện trước: phê duyệt trước kiểu proposer-reviewer (người đề xuất - người rà soát).

4. (★★) Chương này đặt ra vấn đề "nổ công cụ" - độ chính xác lựa chọn của Agent giảm xuống khi phải đối mặt với hàng nghìn công cụ. Ngoài khám phá công cụ tích cực, còn có những giải pháp nào khác? Có thể tham khảo chiến lược của các chuyên gia con người khi phải đối mặt với một lượng lớn công cụ có sẵn.

① Nhóm phân tầng: trước định vị "máy chủ/App" rồi chọn công cụ cụ thể; ② Kiểu "tra cứu theo nhu cầu" của Skills: như tra sách công cụ, mục lục lưu trú trong ngữ cảnh, chi tiết tải theo nhu cầu; ③ Một số ít công cụ nền tảng thường dùng "để bên tay" lưu trú trong ngữ cảnh, còn lại dựa vào chỉ mục mục lục.

Chương 5 Coding Agent và tạo mã

1. (★★) Việc tạo mã được gọi là “siêu khả năng” của Agent. Tuy nhiên, việc thực thi mã gây ra rủi ro bảo mật—mã do Agent tạo ra có thể chứa lỗ hổng, vòng lặp vô hạn hoặc cạn kiệt tài nguyên. Việc cách ly hộp cát có thể giải quyết một số vấn đề nhưng nó cũng hạn chế khả năng của mã (chẳng hạn như không thể truy cập mạng hoặc hệ thống tệp). Làm thế nào để tìm được sự cân bằng tối ưu giữa bảo mật và khả năng?

Sandbox cô lập phân cấp theo tình huống (container/microVM); mạng mặc định ngắt, proxy danh sách trắng mở theo nhu cầu; mã nguồn mount chỉ đọc, API key không đặt trong sandbox; hạn ngạch tài nguyên sandbox; quản lý vòng đời sandbox (timeout).

2. (★★★) Agent bootstrapping - Agent có thể tạo Agent - thực hiện "tự tái tạo thông minh". Nhưng mỗi lần khởi động có thể tạo ra những thành kiến hoặc lỗi mới, và liệu những lỗi đó có tích lũy qua nhiều thế hệ không? Làm cách nào để ngăn chặn sự xuống cấp của bootstrap Agent?

Nếu mỗi thế hệ tiếp tục sinh sôi trên sản phẩm thế hệ trước, một số khuyết tật có thể tích lũy. Điểm mấu chốt là có nhiệm vụ có thể xác minh (verifiable task) đủ thách thức, ví dụ nhiệm vụ lập trình đủ khó.

3. (★★) Tạo mã Agent có thể tự động theo dõi quá trình phát triển định dạng khi xử lý phân tích cú pháp nhật ký. Nhưng nếu thay đổi định dạng là một lỗi chứ không phải là một thay đổi có chủ ý, thì khả năng thích ứng của Agent thực sự có thể che giấu vấn đề. Làm thế nào để Agent phân biệt giữa "những thay đổi cần điều chỉnh" và "những điều bất thường cần được báo cáo"?

Trước khi thích ứng phải chẩn đoán: đối chiếu tài liệu kiến trúc và PRD phán đoán định dạng mới có phù hợp dự kiến không (tư tưởng thí nghiệm 5-8); kiểm tra bản ghi version control, xác nhận thay đổi tương ứng commit mã hợp pháp hay trôi dạt không nguồn; ví dụ log_mismatch của τ-bench, ngay cả chọn thích ứng cũng ghi cảnh báo, tự động tạo issue chứ không tương thích im lặng; khi không chắc chắn thì đi qua xác nhận human-in-the-loop. Nguyên tắc: thích ứng và báo cáo song song, thích ứng không nuốt tín hiệu bất thường.

4. (★★) Chương này liên tục sử dụng cơ chế người đề xuất-đánh giá trong việc tạo PPT, chỉnh sửa video và trực quan hóa nhật ký. Ví dụ: nếu sở thích thẩm mỹ của người đánh giá không nhất quán với người dùng mục tiêu, người đánh giá cho rằng mật độ thông tin là hợp lý nhưng người dùng cảm thấy nó quá đông đúc, vòng phản hồi sẽ hội tụ về mức tối ưu cục bộ sai. Làm cách nào để phản hồi tùy chọn của người dùng cũng tham gia vào vòng lặp Người đánh giá?

Đưa phản hồi người dùng vào trajectory Agent như sự kiện có cấu trúc ưu tiên cao nhất; kết tủa ngoại hóa sở thích người dùng, ghi vào MEMORY.md, khiến sở thích có hiệu lực xuyên nhiệm vụ; giao tài liệu định dạng HTML thay vì Markdown để người dùng kiểm tra.

5. (★★) Chương này trình bày các cách khác nhau mà Coding Agent tích lũy kinh nghiệm có được khi thực thi và gỡ lỗi trở lại cơ sở mã - viết các tệp cơ sở kiến thức, cập nhật tài liệu kiến trúc, duy trì các tệp hướng dẫn dự án và củng cố các chuỗi hoạt động thành mã. Nếu những trải nghiệm này được cải tiến sâu hơn thành các quy tắc trong lời nhắc của hệ thống thì bộ quy tắc sẽ tiếp tục mở rộng theo thời gian. Làm thế nào để “thu gom rác” các quy tắc đã định sẵn - xác định và dọn sạch các mục thừa hoặc lỗi thời? Điểm tương đồng và khác biệt giữa cơ chế tích lũy kinh nghiệm này của Agent và tính năng tự động tối ưu hóa các từ nhắc nhở của hệ thống sẽ được thảo luận trong Chương 9 là gì?

Tư tưởng GC: "ràng buộc ưu tiên hơn hướng dẫn" — quy tắc mã hóa được vào Linter/CI/kiểm tra công cụ thì chuyển ra khỏi prompt; theo dõi tỷ lệ trúng quy tắc, mượn phương pháp định hướng dữ liệu "phân tích trajectory thất bại" của LangChain nhận diện dư thừa; định kỳ để Agent đối chiếu codebase xác minh quy tắc vẫn đúng (tài liệu lỗi thời còn tệ hơn không có); Markdown + Git khiến xóa sửa có thể kiểm toán có thể rollback. Cùng Chương 9 đều thuộc học bên ngoài không đổi trọng số; khác ở chỗ chương này là kết tủa gia tăng trong thực thi, Chương 9 dựa vào tín hiệu đánh giá điều khiển tối ưu hóa thêm xóa hệ thống.

6. (★) “Các nhóm thân thiện với công việc từ xa cũng thường thân thiện với AI Agent.” Nhóm hoặc tổ chức của bạn cách “AI-ready” bao xa về mặt tài liệu kiến thức? Trở ngại lớn nhất là gì?

Câu hỏi mở. Có thể tự kiểm bằng chỉ số đại diện của chương này: người mới làm việc từ xa chỉ dựa vào kho và tài liệu có tự lập công việc không. Mục kiểm tra: quyết định có ghi trong tài liệu không, ngữ cảnh có viết vào issue/PR không, lệnh build test có file chỉ dẫn kiểu CLAUDE.md/AGENTS.md không, tri thức bộ lạc có kết tủa thành hướng dẫn phát triển không. Rào cản lớn nhất thường gặp: phụ thuộc truyền miệng "hỏi đồng nghiệp bên cạnh" và văn hóa bảng trắng — Agent không đọc được ước định miệng, chỉ đọc được tài liệu.

7. (★★★) Simon Willison đề xuất "Ba yếu tố chết người" của Agent (quyền truy cập vào dữ liệu riêng tư, tiếp xúc với nội dung không đáng tin cậy và khả năng liên lạc bên ngoài). Chương này bổ sung thêm điều thứ tư trên cơ sở này - trí nhớ bền bỉ. Bạn sẽ thiết kế chính sách bảo mật như thế nào trong môi trường sản xuất cần xử lý đồng thời cả bốn yếu tố?

Phòng thủ phân tầng theo bốn loại ranh giới. Ranh giới dữ liệu: credential không mount, mã nguồn chỉ đọc, nhìn thấy tối thiểu. Ranh giới tin cậy đầu vào: đánh dấu nguồn, nội dung bên ngoài giáng cấp thành dữ liệu "có thể tham khảo, không có hiệu lực chỉ dẫn" (luật trung thành). Ranh giới ảnh hưởng đầu ra: mặc định ngắt mạng cộng cửa ra danh sách trắng, phân tích ngữ nghĩa lệnh thay vì danh sách đen, Sidecar rà soát độc lập cộng human-in-the-loop — thao tác then chốt phải do cơ chế ngoài ngữ cảnh rà soát. Ranh giới xuyên phiên: ghi vào MEMORY.md cần qua rà soát tin cậy ngang hàng với nội dung bên ngoài. Mục tiêu là bị tiêm nhiễm cũng thực thi không ra ngoài.

8. (★★) Chế độ artifact cho phép Agent tạo SQL hoặc mã trực quan, được giao diện người dùng thực thi trực tiếp, bỏ qua LLM để xử lý lượng lớn dữ liệu. Ưu điểm và nhược điểm của mô hình phân công lao động "Agent tạo mã và hệ thống thực thi mã" này so với mô hình "Agent trực tiếp đưa ra câu trả lời" truyền thống là gì? Ngoài ra, SQL được tạo có thể thực hiện các hoạt động phá hoại và HTML được tạo có thể chứa lỗ hổng. Làm thế nào để đảm bảo tính bảo mật của hệ thống?

Ưu và nhược điểm: Ưu: dữ liệu từ cơ sở dữ liệu đến thẳng frontend, vượt qua "người trung gian" LLM — nhanh, tiết kiệm token, tránh lỗi ảo giác khi chép tay lượng lớn dữ liệu, thích hợp trình bày dữ liệu lớn; mã có thể kiểm toán, có thể tái dùng, còn có thể tổ hợp pipeline (kết quả SQL trực tiếp cho mã trực quan hóa). Khuyết: LLM không thấy kết quả truy vấn, không thể dựa vào nội dung dữ liệu làm quy nạp và quyết định tiếp, không thích hợp nhiệm vụ cần mô hình tiêu hóa dữ liệu rồi suy luận.

Bảo mật: SQL: truy vấn dùng tài khoản chỉ đọc quyền tối thiểu thực thi, và thêm giới hạn tài nguyên CPU, bộ nhớ, chống cạn kiệt tài nguyên. HTML/UI: ưu tiên giao thức khai báo kiểu A2UI, Agent chỉ xuất JSON mô tả giao diện, client render bằng danh mục component đáng tin, không thực thi mã tùy ý. Nếu muốn HTML tùy ý, thì phải hiển thị trong môi trường sandbox, chống tiêm nhiễm.

9. (★★) Mã hóa các quy tắc nghiệp vụ thành xác minh nội bộ của công cụ dựa trên các giá trị đúng của cơ sở dữ liệu và sử dụng thiết kế tham số để hướng dẫn mô hình kiểm tra các điều kiện chính sách trước khi gọi. Về bản chất, cấu trúc mã được sử dụng để hạn chế hành vi Agent. Ưu điểm và hạn chế của mô hình “mã chính là quy tắc” này so với quy tắc ngôn ngữ tự nhiên là gì?

Ưu điểm: không nhập nhằng, xác định, giỏi tổ hợp điều kiện phức tạp; sự thật chính sách lấy từ chân lý cơ sở dữ liệu và đồng hồ phía máy chủ, không tin giá trị tự báo của mô hình, ảo giác và prompt injection đều không vượt qua được, là người gác cổng cuối cùng chống thao tác không thể đảo ngược; tham số expected_* kiêm làm checklist bắt buộc dẫn dắt suy nghĩ. Hạn chế: mã không giải thích chính sách cho người dùng, không tìm phương án linh hoạt, và có chi phí bảo trì. Kết luận: bổ sung lẫn nhau với quy tắc ngôn ngữ tự nhiên chứ không thay thế.

Tương tác: mở rộng không gian quan sát và không gian hành động

1. (★★) Trong kiến trúc Agent không đồng bộ, chiến lược ưu tiên của hàng đợi sự kiện cần được xác định tại thời điểm thiết kế. Nhưng nếu bản thân phán đoán mức độ ưu tiên đòi hỏi sự hiểu biết về ngữ nghĩa (chẳng hạn như đánh giá liệu một tin nhắn mới có khẩn cấp hơn nhiệm vụ hiện tại hay không), ai sẽ đưa ra phán quyết này - công cụ quy tắc hoặc lệnh gọi LLM khác? Giá mỗi cái là bao nhiêu?

Kết hợp phân tầng: loại sự kiện rõ ràng dùng luật hardcode, độ trễ bằng không, tính xác định mạnh, nhưng không hiểu được khác biệt ngữ nghĩa giữa "dừng lại ngay" và "hôm nay thời tiết thế nào"; ngữ nghĩa mơ hồ giao cho LLM phân loại nhẹ làm bộ định tuyến sự kiện, cái giá là độ trễ vài trăm mili giây, phí bổ sung, có thể phán sai, và cần như Sidecar chỉ đọc trường có cấu trúc chống prompt injection.

2. (★★) Trong xử lý sự kiện xếp hàng, mô hình có xu hướng chỉ tập trung vào sự kiện cuối cùng. Chương này sử dụng Tác nhân nhưng nếu có 20 sự kiện tồn tại trong hàng chờ đợi (10 công cụ kết quả + 5 người dùng thông báo + 5 hệ thống cảnh báo), bạn sẽ sắp xếp thứ tự và trình bày dạng của những sự kiện này như thế nào để mô hình không bỏ qua quan trọng thông tin?

Trước dùng luật và LLM nhẹ phân loại khử trùng: sự kiện khẩn cấp (cảnh báo, người dùng ngắt) đi riêng xử lý kiểu hủy bỏ, không trộn vào lô. 10 kết quả công cụ siêu dài, cắt bớt lưu trữ vào file, chỉ giữ đầu đuôi và đường dẫn. Thanh trạng thái hệ thống ở cuối ngữ cảnh thêm danh sách tổng hợp (số lượng từng loại sự kiện + yêu cầu phản hồi từng mục).

3. (★★★) Agent Khi thay mặt người dùng tương tác với thế giới bên ngoài, anh ta về cơ bản phải đối mặt với một lựa chọn danh tính: anh ta nên sử dụng danh tính ảo độc lập (email và số điện thoại độc quyền) để hoạt động như một bên thứ ba hay anh ta nên trực tiếp vận hành tài khoản cá nhân của mình với tư cách là chính người dùng? Cái trước có thể hoạt động tự chủ ở chế độ nền, nhưng các bên thứ ba có thể không tin tưởng vào danh tính không phải là người thật; cái sau có ngữ cảnh và quyền đầy đủ hơn, nhưng đưa ra các vấn đề về ủy quyền tin cậy và ranh giới bảo mật. Bạn nghĩ nên chọn chế độ nào trong kịch bản nào?

Mặc định danh tính ảo: thao tác tự chủ nền, có thể kiểm toán, khi sai hoặc bị công phá không lộ toàn bộ danh tính số của người dùng, giống thư ký dùng email công sở của mình; cần đối phó vấn đề CAPTCHA/uy tín IP (proxy dân cư). Tình huống bắt buộc dùng danh tính bản thân (xác thực danh tính tài khoản, xác nhận cuộc gọi ba bên, như Pine gọi điện cho tổng đài) dùng xác thực Human-in-the-loop: VNC/RDP để người dùng tự đăng nhập trực quan. Tiêu chuẩn phán đoán: đối phương có yêu cầu chính chủ tài khoản không, rủi ro thao tác và phạm vi credential.

4. (★★) Mô hình giọng nói đầu cuối Agent hợp nhất ASR-LLM-TTS thành một mô hình duy nhất, giảm độ trễ nhưng mất tính mô-đun. Nếu mô hình đầu cuối bị lỗi ở một số điểm (chẳng hạn như nhận dạng giọng nói), việc gỡ lỗi và sửa nó sẽ khó khăn hơn nhiều so với đường ống nối tiếp. Bạn sẽ thiết kế hệ thống quan sát giọng nói Agent giọng nói đầu cuối như thế nào?

Để mô hình kèm theo đầu ra các biểu diễn trung gian có thể đọc, như luồng văn bản “độc thoại nội tâm” của Moshi và đánh dấu sự kiện âm học (<emotion>, <noise>). Dùng “tự ghép tầng” để định vị tầng lỗi: cùng một mô hình trước hết phiên âm rồi suy luận; đối chiếu với kết quả đầu-cuối để phán đoán lỗi nằm ở nhận thức hay suy nghĩ. Offline, thực hiện kiểm thử hồi quy riêng theo các chiều như hiểu yếu tố cận ngôn ngữ và phán đoán lượt nói.

5. (★) Step-Audio R1 thực hiện “nghĩ và nói” thông qua kiến trúc bộ não kép MPS. Nhưng khi con người đang “suy nghĩ và nói chuyện”, họ thường nói những điều chưa được suy nghĩ kỹ, tự sửa hoặc sử dụng những từ lấp chỗ trống. “Suy nghĩ và lời nói” của Agent có nên bắt chước những đặc điểm này của con người không?

Nên mô phỏng những “không hoàn hảo” có giá trị tín hiệu: ngừng nghỉ và từ đệm là sự ngoại hóa của suy nghĩ, có thể che giấu độ trễ, còn vị trí chèn do LLM quyết định. Không nên mô phỏng sự tự sửa chữa phá hủy niềm tin: mâu thuẫn nhanh–chậm trong phương án một (“rốt cuộc mua hay không?!”) sẽ khiến niềm tin sụp đổ. Thí nghiệm MPS cho thấy phần đầu CoT đa số là nhắc lại câu hỏi; mở lời sớm để dẫn nhập là an toàn, không cần nói sai rồi sửa.

6. (★★) SoM (Set-of-Mark) và biến thể có cấu trúc của nó (chỉ mục phần tử DOM) chuyển bản địa hóa trực quan của Computer Use từ dự đoán tọa độ mở sang lựa chọn ID đóng, nhưng cả hai đều yêu cầu các thành phần giao diện phải được phát hiện và chú thích trước - bằng mô hình phân đoạn hoặc DOM. Nếu giao diện chứa các điều khiển không chuẩn hoặc các phần tử thay đổi linh hoạt, việc ghi nhãn có thể không đầy đủ hoặc không chính xác. Chúng ta có nên quay lại việc phối hợp dự đoán trong trường hợp này không?

Nên giữ dự đoán tọa độ làm đường lui: đó là lộ tuyến duy nhất không phụ thuộc đánh dấu, áp dụng được cho điều khiển phi chuẩn và phần tử động. Thực dụng hơn là dùng action space kết hợp, trong đó phần tử có thể đánh dấu vẫn dùng chọn ID. Dự đoán tọa độ phải khớp độ phân giải và co giãn theo tỷ lệ, nếu không sẽ phát sinh độ lệch có hệ thống.

7. (★★) Các nền tảng robot trị giá hàng nghìn đô la như XLeRobot giúp việc thu thập dữ liệu từ xa trở nên rẻ hơn. Tuy nhiên, chất lượng của dữ liệu viễn thông phụ thuộc nhiều vào kỹ năng của người vận hành. Dữ liệu do người vận hành không có kỹ năng cung cấp ảnh hưởng như thế nào đến việc đào tạo mô hình VLA? Làm cách nào để tự động lọc dữ liệu chất lượng thấp trong giai đoạn thu thập dữ liệu?

VLA chủ yếu dựa vào học bắt chước, nên trình diễn chất lượng thấp sẽ khiến mô hình học cả rung, đi vòng, do dự và hành động thất bại như thể đó là chiến lược đúng. Điều này tương ứng với phán đoán ở Chương 8: dữ liệu quan trọng hơn kiến trúc.

8. (★★★) Chương này bao gồm ba hình thức tương tác: giọng nói, Computer Use và robot. Xu hướng chung giữa ba hình thức này là sự phát triển từ các đường ống nối tiếp sang các mô hình đầu cuối. Nếu xu hướng này tiếp tục, lớp tương tác Agent sẽ trông như thế nào sau 5 năm nữa?

Theo chủ trương của Thinking Machines Lab, tính tương tác sẽ được xây dựng sẵn trong mô hình chứ không gắn ngoài harness, và mở rộng cùng trí tuệ. Computer Use sẽ đi từ chụp màn hình từng khung đến quan sát liên tục. Mô hình thế giới cho trí tuệ hiện thân sẽ được hiện thực hóa toàn diện, nhưng do các mô hình suy luận tiên phong phát triển rất nhanh, tách nhanh–chậm sẽ không biến mất. Kiến trúc phối hợp tư duy nhanh–chậm giữa mô hình tương tác và mô hình tư duy SOTA có thể trở thành kiến trúc dài hạn.

9. (★★) Lập chỉ mục phần tử cây DOM/Accessibility có hiệu quả trong các ứng dụng web tiêu chuẩn, nhưng ngày càng có nhiều giao diện phần mềm (hiển thị Canvas/WebGL, điều khiển tự vẽ đa nền tảng) không cung cấp thông tin có cấu trúc có thể truy cập được và chỉ có thể dựa vào chú thích trực quan hoặc dự đoán tọa độ. Bạn nghĩ Computer Use nên đặt cược vào tuyến đường hoàn toàn trực quan hay duy trì cả tuyến đường có cấu trúc và trực quan? Chi phí và lợi ích của việc duy trì hai con đường là gì?

Ngắn hạn, hai đường tồn tại song song: khi có chỉ mục có cấu trúc thì định vị chính xác và ổn định nhất, tránh phát hiện sai do phân đoạn; thuần thị giác là lựa chọn duy nhất cho phần mềm nguyên sinh, Canvas và game. Khi bản thân mô hình có năng lực grounding mạnh (nhấp vào tọa độ chỉ định), phương án chỉ mục có cấu trúc không thể hiện ưu thế đáng kể. Về dài hạn, lộ tuyến thuần thị giác có trần cao hơn.

10. (★★) Mô hình VLA sử dụng phân đoạn hành động - như đã đề cập trong văn bản, cấu hình điển hình của π₀ là tạo ra các hành động trong tương lai 25-50 ở tần số 50Hz - ẩn độ trễ suy luận trong thời gian thực hiện. Tuy nhiên, nếu môi trường thay đổi đột ngột trong quá trình thực thi (chẳng hạn như một đối tượng bị xóa), chuỗi hành động được tạo trước sẽ trở nên không hợp lệ. Làm thế nào để đạt được sự cân bằng giữa lợi ích hiệu quả của việc phân chia hành động và tốc độ phản ứng với những thay đổi của môi trường?

Bản chất chunk là lấy tính phản ứng đổi tính mượt, chunk càng dài càng chậm chạp; độ dài chunk chỉ cần thỏa mãn giới hạn dưới “thời gian suy luận < thời gian thực thi chunk”, không nên mù quáng kéo dài. Trong khi thực thi, để mô hình nhận thức chạy liên tục; khi phát hiện môi trường đột biến thì vứt bỏ hành động còn lại và suy luận lại, tương đương “ngắt lời” trong tình huống giọng nói. Có thể điều chỉnh động độ dài chunk theo tình huống: cảnh tĩnh dùng chunk dài để tiết kiệm tính toán, cảnh động dùng chunk ngắn để giữ độ trễ phản hồi thấp.

11. (★★★) Ba kịch bản trong chương này (giọng nói, Computer Use, robot) đều gặp phải vấn đề độ trễ của chu trình "nhận thức-suy nghĩ-hành động" và chúng đều phát triển theo hướng song song hóa tư duy nhanh và chậm. Trong cảnh lồng tiếng, điều này thể hiện là "sửa lỗi sau khi bạn mắc lỗi"; trong cảnh Computer Use, điều này biểu hiện dưới dạng "nhấp vào trước rồi nhìn"; trong cảnh người máy, điều này thể hiện là "bước một bước và nhìn bước kia". Làm thế nào để đảm bảo rằng những hành động dựa trên tư duy nhanh nhạy này sẽ không dẫn đến những hậu quả không thể khắc phục được?

Phân cấp hành động theo tính khả nghịch: suy nghĩ nhanh chỉ được thực thi hành động có thể đảo ngược; thao tác không thể đảo ngược giao cho suy nghĩ chậm kiểm soát. Không cho phép mô hình nhanh thực hiện lời gọi công cụ có thể gây hậu quả không thể đảo ngược.

12. (★★★) Chương này lặp lại cùng một bộ nguyên thuỷ (đánh thức, điểm an toàn, huỷ, giành quyền, tách nhanh/chậm) được hiện thực trên các thang thời gian khác nhau. Hãy chọn một trong số đó và trình bày khác biệt trong cách hiện thực nó ở xử lý hướng sự kiện (giây — ngày) và ở chia khối hành động của robot (mili giây); khác biệt ấy chủ yếu do cái gì quyết định — tốc độ biến đổi của môi trường, tính khả nghịch của hành động, hay chi phí thu được quan sát?

Lấy huỷ làm ví dụ. Trong xử lý hướng sự kiện, việc huỷ diễn ra tại điểm an toàn giữa hai lệnh gọi công cụ: nhận được terminate, Agent dọn tài nguyên, trả về xác nhận rồi thoát; độ trễ tính bằng giây vẫn chấp nhận được, vì bản thân một lệnh gọi công cụ đã mất vài giây đến vài phút. Trong chia khối hành động, việc huỷ phải có hiệu lực trong vài mili giây: ngay khi luồng điều khiển phát hiện sự kiện an toàn hoặc quan sát thay đổi đáng kể, nó phải dừng ngay động tác hiện tại, bỏ phần khối còn lại và quan sát lại — chậm một nhịp là có thể đâm vào vật cản.

Trong ba yếu tố ứng viên, chi phí thu được quan sát thực ra ít quyết định nhất — cả hai phía đều có thể quan sát lại với chi phí thấp. Cái thực sự quyết định khác biệt là tổ hợp của hai yếu tố còn lại: tốc độ biến đổi của môi trường quyết định điểm an toàn phải dày đến mức nào (giữa các lệnh gọi công cụ là đủ, hay mỗi chu kỳ điều khiển đều phải có), còn tính khả nghịch của hành động quyết định cái giá của việc lỡ một điểm an toàn (gửi thừa một email còn có thể gửi thư xin lỗi, chiếc cốc bị đổ thì không thể hoàn tác).

Từ đó rút ra một quy tắc thiết kế: mật độ điểm an toàn phải tương xứng với tốc độ biến đổi của môi trường; còn cần thêm bao nhiêu lớp bảo vệ ngoài điểm an toàn (nút dừng khẩn cấp phần cứng, bộ điều khiển an toàn độc lập, xác nhận lần hai) thì tuỳ vào mức độ bất khả nghịch của hành động. Điều này cũng giải thích vì sao các thao tác rủi ro cao ở Chương 4 phải phê duyệt trước, còn robot phải có lớp an toàn phần cứng độc lập với mô hình — cả hai đều là tuyến phòng thủ thứ hai bù vào chỗ mà chỉ điểm an toàn thôi là không đủ.

Chương 7 Đánh giá Agent

1. (★★) LLM-as-a-Judge Sử dụng mô hình ngôn ngữ để đánh giá đầu ra của mô hình ngôn ngữ. Có điểm mù mang tính hệ thống nào trong quá trình “tự đánh giá” này không - ví dụ: mô hình có thể luôn cho điểm cao cho một phong cách trả lời nhất định, nhưng ưu tiên này không phù hợp với phán đoán của con người? Làm thế nào có thể phát hiện và sửa chữa sự thiên vị này?

Có tồn tại: thiên lệch độ dài, thiên lệch phong cách trả lời, mô hình cùng nguồn bị lách luật (định luật Goodhart). Phát hiện: xây bộ chuẩn vàng nhân công 100-200 ví dụ, đo Cohen's kappa giữa phán quan và con người; định kỳ kiểm toán tương quan giữa điểm số và độ dài câu trả lời; red team cấu tạo ca đối kháng. Hiệu chỉnh: Rubric trừng phạt tường minh dài dòng, giới hạn độ dài; phán quan đa nguồn dị cấu từ các họ mô hình khác nhau.

2. (★★★) Thiết kế “chống rò rỉ” của bộ dữ liệu đánh giá là rất quan trọng. Tuy nhiên, trong hệ sinh thái nguồn mở, một khi dữ liệu điểm chuẩn được công khai, nó sẽ sớm được đưa vào dữ liệu huấn luyện. Liệu “trò chơi mèo vờn chuột” này có hồi kết? Thiết kế một phương pháp đánh giá về cơ bản có khả năng chống rò rỉ dữ liệu.

Ngân hàng đề tĩnh không có hồi kết, chỉ có thể đuổi theo. Lối ra căn bản là công khai "cơ chế sinh", riêng tư hóa "thể hiện cụ thể": như τ²-bench, AndroidWorld mẫu tham số hóa mỗi lần ngẫu nhiên hóa thể hiện, xác minh dựa trên trạng thái môi trường cuối cùng chứ không dựa trên chuỗi đáp án cố định.

3. (★★) Thang đo Bốn tiêu chí của AI (dựa trên hướng dẫn của chuyên gia, phạm vi bao quát toàn diện, trọng số tầm quan trọng tiêu chuẩn, đánh giá khép kín) được thiết kế để loại bỏ tính chủ quan trong đánh giá. Nhưng một số khía cạnh nhiệm vụ (chẳng hạn như “liệu câu trả lời có hữu ích hay không” và “liệu giọng điệu có phù hợp”) về bản chất là chủ quan. Làm cách nào để thiết kế Rubric đáng tin cậy cho các kích thước chủ quan này?

Dịch tiêu chuẩn trừu tượng thành hành vi có thể xác minh. Mỗi mức kèm ví dụ cụ thể và ca biên giới; Rubric là sản phẩm lặp — trong quá trình dùng thử thu thập bất đồng của người đánh giá, dần tiến hóa thành bộ án lệ. Lại phối hợp đa giám khảo có trọng số/kiểm tra nhất quán, ca bất đồng đưa con người rà soát lại, và hiệu chuẩn tỷ lệ nhất quán trên bộ chuẩn vàng.

4. (★★) τ-bench đánh giá Agent bằng cách mô phỏng hành vi của người dùng thực. Nhưng bản thân người dùng được mô phỏng cũng là LLM - nó có thể đánh giá thấp một cách có hệ thống các tình huống khó khăn nhất định (chẳng hạn như người dùng cảm xúc, thiếu chính xác). Làm cách nào để xác minh chất lượng của chính người dùng mô phỏng?

Bài học phiên bản đầu τ-bench: trình mô phỏng quá cứng nhắc, chỉ dẫn quá đơn giản (Agent đoán được đáp án). Thủ đoạn xác minh: con người kiểm tra ngẫu nhiên hội thoại mô phỏng, kiểm tra có tuân thủ tiết lộ lũy tiến, không bịa thông tin ngoài kịch bản; dùng mẫu nhỏ người dùng thật thử nghiệm, xem xếp hạng có khớp với đánh giá mô phỏng không.

5. (★★) So sánh theo cặp (mô hình Bradley-Terry) giả định rằng các ưu tiên có tính bắc cầu (nếu A > B và B > C thì A > C). Nhưng sở thích của con người thường vi phạm tính bắc cầu. Trong trường hợp nào các tùy chọn không mang tính bắc cầu có thể xuất hiện trong đánh giá Agent? Điều này ảnh hưởng thế nào đến độ tin cậy của bảng xếp hạng?

Tình huống: khi cân đo đa chiều (A chính xác nhưng chậm, B nhanh nhưng sơ sài, C chi tiết nhưng đắt), người đánh giá/nhiệm vụ khác nhau coi trọng chiều khác nhau. Xếp hạng Chatbot Arena vốn phụ thuộc phân phối câu hỏi người dùng. Ảnh hưởng: BT nén thực lực thành điểm số đơn nhất, khi phi bắc cầu xếp hạng không ổn định, trôi theo phân phối trận đấu. Giảm thiểu: xếp hạng riêng theo chiều năng lực, báo cáo ma trận tỷ lệ thắng từng cặp.

6. (★★) Chương này phân biệt Pass@k như trần năng lực với Pass consecutive@k như thước đo độ tin cậy nghiệp vụ. Với một Agent chỉ đạt tỷ lệ thành công 60% trong một lần chạy, bạn sẽ kết hợp chi phí thất bại, chi phí thử lại và tác dụng phụ của tác vụ như thế nào để quyết định nên báo cáo chỉ số nào và lấy k bằng bao nhiêu?

Hãy bắt đầu từ việc thất bại có thể rollback hay không. Khi thất bại có thể thử lại tự động và không để lại tác dụng phụ bên ngoài (truy hồi, sinh bản nháp, hoàn thiện mã), câu hỏi là “cho đủ cơ hội thì có làm được không”, nên hãy báo cáo Pass@k với k bằng đúng ngân sách thử lại được phép. Khi thất bại để lại hậu quả không thể đảo ngược (thanh toán, hoàn tiền, gửi thư ra ngoài, triển khai production), một lần sai đã là tổn thất thật, nên hãy báo cáo Pass^k. Với tỷ lệ thành công một lần chạy là 0,6, Pass@5 ≈ 99,0% trong khi Pass^5 ≈ 7,8%—hai con số chênh nhau một bậc độ lớn cho cùng một Agent, nên chỉ báo cáo con số đầu sẽ đánh giá quá cao độ tin cậy.

Hãy để k đến từ thực tế triển khai chứ không phải từ con số đẹp mắt: với Pass@k lấy ngân sách thử lại, với Pass^k lấy số tác vụ chạy liên tiếp trong một ca hoặc một lô. Khi thử lại tốn kém, hãy nghiệm thu hai giai đoạn—sàng lọc bằng Pass@1 rồi chạy Pass^k trên số ít ứng viên còn lại. Dù báo cáo chỉ số nào, hãy nêu rõ k và giao thức lấy mẫu; với các thao tác có tác dụng phụ, hãy lấy mẫu trong sandbox hoặc môi trường có thể rollback, và tính mọi lần thất bại vào thống kê độ tin cậy thay vì “thử lại cho đến khi thành công”.

7. (★★) Chương này đề xuất phương pháp khoa học “quan sát→giả thuyết→thí nghiệm→xác minh”. Nhưng trên thực tế, không gian hành vi của Agent là rất lớn và việc xác minh một giả thuyết có thể yêu cầu hàng trăm lần đánh giá. Làm cách nào để tối đa hóa lượng thông tin được đánh giá trong phạm vi ngân sách tính toán hạn chế?

Trước hết gom nhóm lỗi để thu hẹp phạm vi vào những nhiệm vụ giàu thông tin nhất, rồi dùng các thử nghiệm ghép cặp chi phí thấp, mỗi lần chỉ đổi một biến. Kết quả mẫu nhỏ chỉ nên là cổng quyết định có mở rộng thử nghiệm hay không, không phải bằng chứng triển khai. Về thống kê, dùng sai số chuẩn làm bộ lọc bảo thủ; với cùng tập nhiệm vụ, dùng phân tích ghép cặp như McNemar; nếu mức cải thiện kỳ vọng nhỏ hơn băng thông nhiễu thì phải mở rộng tập đánh giá. Khi sàng lọc nhiều phương án song song, cần hiệu chỉnh so sánh nhiều giả thuyết và chạy xác nhận độc lập cho kết quả dương tính.

8. (★) Trong thử nghiệm AndroidWorld, cây phần tử đầy đủ nâng tỷ lệ thành công từ 25% lên 100% nhưng làm lượng token tăng lên 2.498× so với đối chứng; sau khi cắt gọn, tỷ lệ thành công vẫn là 100% còn lượng token giảm xuống 0.506×. Bạn sẽ thiết kế quy tắc cắt tỉa tự động như thế nào để loại các nút UI rỗng về ngữ nghĩa mà không làm mất thông tin cần cho khả năng truy cập, xác minh trạng thái hoặc thao tác về sau?

Có thể dùng nguyên tắc phân tầng “mặc định loại, chỉ giữ khi có bằng chứng”: giữ các nút hiển thị, có văn bản, có thể thao tác, lấy nét hoặc cuộn, mang trạng thái/giá trị hay nhãn accessibility; đồng thời giữ đường tổ tiên tối thiểu tới gốc và các nhãn lân cận cần thiết. Loại container chỉ phục vụ bố cục, tóm tắt các cây con lặp lại. Trước và sau khi cắt phải kiểm tra ID, trạng thái và giá trị của phần tử thao tác không đổi, đồng thời giữ ảnh chụp màn hình làm phương án thị giác dự phòng. Hãy phát lại trajectory thất bại, rồi hồi quy trên các ứng dụng chưa dùng để tinh chỉnh; tỷ lệ thành công, token và độ trễ là các guardrail chung, và bất kỳ hồi quy accessibility nào cũng phải chặn phát hành.

9. (★★) Mô phỏng người dùng của τ-bench áp dụng "tiết lộ thông tin lũy tiến"—không cung cấp tất cả thông tin cùng một lúc mà tiết lộ dần dần dựa trên các câu hỏi do Agent đặt ra. Thiết kế này ảnh hưởng thế nào đến kết quả đánh giá? Nếu chiến lược tiết lộ thông tin của người dùng mô phỏng khác biệt đáng kể so với chiến lược của người dùng thực, liệu kết luận đánh giá có còn đáng tin cậy không?

Ảnh hưởng: nếu chiến lược tiết lộ méo mó, Agent có thể chỉ học được "thích ứng với trình mô phỏng" (Goodhart), điểm số tuyệt đối không có giá trị tham khảo; thứ hạng tương đối giữa các mô hình có thể vẫn có giá trị tham khảo. Cứu chữa: dùng hội thoại thật hiệu chuẩn trình mô phỏng, con người kiểm tra ngẫu nhiên, chỉ rõ ranh giới áp dụng kết luận.

Chương 8 Post-training mô hình

1. (★★) Sự quên lãng nghiêm trọng - một tinh chỉnh dành riêng cho nhiệm vụ phá hủy các khả năng chung ban đầu của mô hình (chẳng hạn như các lệnh gọi công cụ chung) - đặc biệt rắc rối trong kịch bản Agent. So với việc tinh chỉnh đầy đủ thông số, LoRA đóng băng trọng số cơ bản và có nguy cơ quên thấp hơn, nhưng nó không tránh khỏi. Những chiến lược nào có thể làm giảm bớt tình trạng lãng quên các khả năng do tinh chỉnh gây ra?

Tỷ lệ dữ liệu: trộn khoảng 20% dữ liệu đa dụng/phân phối gốc, chống nhiệm vụ mới chiếm tỷ trọng quá cao đè bẹp năng lực cũ; khống chế lượng huấn luyện: SFT đến "định dạng ổn định, năng lực mới hình thành" là dừng, dừng sớm chống sụp đổ; RL dùng rank nhỏ (8–32) và giữ phạt KL, ấn chính sách gần mô hình tham chiếu; đóng băng thành phần then chốt (như VLM chỉ huấn luyện tầng chiếu); theo nhiệm vụ gắn nhiều LoRA adapter cô lập năng lực; dùng benchmark đa dụng làm kiểm thử hồi quy.

2. (★★) Quá trình post-training củng cố các khả năng thành trọng lượng mô hình (“bộ nhớ cơ”), trong khi In-Context Learning (học trong ngữ cảnh) sẽ đưa kiến thức vào đầu vào tại thời điểm suy luận. Tuy nhiên, một số khả năng, chẳng hạn như kiến thức về miền, có thể được học thông qua post-training hoặc được cung cấp bởi ví dụ few-shot. Bạn sẽ sử dụng tiêu chí nào để quyết định con đường mà một năng lực nhất định nên đi?

Loại tri thức: tri thức sự thật giao cho RAG/ngữ cảnh, SFT không nhớ được lượng lớn sự thật; tri thức phi sự thật, quy tắc khó biểu đạt bằng ngôn ngữ thích hợp post-training. Tần suất cập nhật: thường thay đổi để trong ngữ cảnh (có thể cập nhật động, có thể truy ngược), ổn định mới viết vào tham số. Giai đoạn và chi phí: thời kỳ thăm dò dùng học trong ngữ cảnh (prompt + cơ sở tri thức) thử sai nhanh; sản phẩm định hình, lượng gọi lớn, nhạy cảm độ trễ chi phí thì làm cố định hóa kiểu chưng cất Prompt. Tính ổn định phân phối: agent lĩnh vực phân phối triển khai dự đoán được mới đáng huấn luyện, agent đa dụng nói chung không cần huấn luyện.

3. (★★) Chưng cất mô hình cho phép các mô hình nhỏ tìm hiểu hành vi của các mô hình lớn. Theo mức độ khả năng, các mô hình chắt lọc có thể được chia đại khái thành ba cấp độ - Mô hình trò chuyện(một vòng đối thoại, trả lời trực tiếp), Mô hình lý luận(chuỗi suy nghĩ dài trước khi trả lời), Mô hình tác nhân(nhiều vòng công cụ gọi điện, tương tác với môi trường). Sự khác biệt về khó khăn khi chắt lọc ba loại mô hình này tương ứng là gì? (Mẹo: Bắt đầu với “chính xác những gì cần được chắt lọc”—cho dù đó là phong cách đầu ra, trajectory tư duy hoàn chỉnh hay chiến lược ra quyết định để tương tác với môi trường; những mã thông báo nào trong trajectory nên được học và những mã thông báo nào do môi trường trả về không nên được học; và các tín hiệu thành công hay thất bại xuất hiện muộn và thưa thớt như thế nào.)

Chat: chỉ học ánh xạ "đầu vào → đầu ra" và phong cách, SFT chuẩn là đủ, đơn giản nhất. Reasoning: cần trajectory suy nghĩ hoàn chỉnh, cần dựa trên mô hình giáo viên mã nguồn mở; phải lọc trajectory đáp án sai. Agentic: cần môi trường mô phỏng thật; học offline dễ xuất hiện learner-sampler mismatch, khuyến nghị dựa trên mô hình giáo viên mã nguồn mở làm On-Policy Distillation.

4. (★★★) Trong các tương tác Agent nhiều vòng, vấn đề phân bổ phần thưởng (phân công tín dụng) nghiêm trọng hơn trong một vòng duy nhất - thành công hay thất bại cuối cùng rất khó quy cho quyết định của vòng 3 hoặc vòng 7. Bạn sẽ thiết kế chiến lược phân phối phần thưởng như thế nào?

Khi bước trung gian có thể phán định thì thêm phần thưởng quá trình (V-IRL mỗi bước ±1); mô phỏng RLVP dùng luật xác định cho tín hiệu đường đi theo từng hành động, bù lại phương sai trong nhóm của nhóm toàn bại/toàn thắng.

5. (★★★) Post-training, External Learning (học bên ngoài tham số mô hình) và In-Context Learning (học trong ngữ cảnh) tạo thành ba khía cạnh của khả năng Agent. Nếu bạn có ngân sách cố định (giả sử là 10.000 đô la) và muốn cải thiện hiệu suất của một tổng đài viên, Agent, bạn sẽ phân bổ ngân sách như thế nào giữa ba chiều này? Quyết định của bạn phụ thuộc vào những yếu tố nào?

Trước dùng kỹ thuật ICL/Harness lặp nhanh định vị nút thắt, đa số vấn đề ở tầng này là giải quyết được; tri thức sản phẩm, quy tắc gói cước — nội dung sự thật, thường cập nhật đầu tư RAG (có thể cập nhật, có thể truy ngược); ngữ khí, nghi thức quy trình, định dạng gọi công cụ ổn định rồi dùng LoRA On-Policy Distillation cố định hóa (chi phí thấp); RL đắt gấp hàng chục đến hàng trăm lần, chỉ khi không lấy được mô hình giáo viên, hoặc cần năng lực tổng quát hóa mới dùng.

6. (★★★) Trong trường hợp không có chức năng khen thưởng rõ ràng và mẫu thưa thớt, việc học theo mô hình tự động được một số người coi là mục tiêu cuối cùng của quá trình post-training. Các phương pháp đào tạo RL hiện tại cách mục tiêu này bao xa? Bạn nghĩ bước đột phá tiếp theo có nhiều khả năng đến từ hướng nào?

Khoảng cách: như Silver và Sutton chỉ ra, RL hiện tại chỉ học được từ thành bại cuối cùng, phản hồi phong phú kiểu nhân viên chăm sóc nói "cần bốn số cuối thẻ tín dụng" toàn bộ bị lãng phí, cần hàng trăm lần thử sai mù quáng; hiệu suất mẫu và phần thưởng có thể xác minh là nút thắt chính. Đột phá có thể: mô hình phần thưởng sinh tự định nguyên tắc, học được phương hướng từ một lần thất bại; và lộ tuyến world model mô hình hóa môi trường.

7. (★★) Chương này chỉ ra rằng việc tinh chỉnh LoRA không hề tốn kém. Vì vậy, liệu có thể đào tạo LoRA dành riêng cho từng người dùng (hoặc từng công ty khách hàng) và ghi bộ nhớ người dùng hoặc kiến thức doanh nghiệp vào các tham số thay vì lưu trữ nó trong cơ sở kiến thức bên ngoài như Chương 3 không? Trong trường hợp nào thì "tham số ghi vào bộ nhớ" có nhiều ưu điểm hơn "ghi nhớ tham số và lưu trữ chúng trong cơ sở tri thức"? Trong trường hợp nào nó sẽ phản tác dụng?

LoRA khó nhớ chính xác lượng lớn sự thật (phải tiếp tục pretrain, chi phí tăng vọt), ngay cả nhớ được, mô hình cũng rất khó dùng những sự thật này làm suy luận đa bước, do đó dùng LoRA nhớ sự thật không phải lộ tuyến kỹ thuật tốt. Ngoài ra, sự thật thay đổi thường xuyên, cần kiểm toán truy ngược thì RAG tốt hơn.

8. (★★★) On-Policy Chưng cất dựa vào mô hình giáo viên mạnh mẽ hơn để giám sát học sinh. Nhưng nghiên cứu Tổng quát hóa Weak-to-Strong của OpenAI đã đưa ra một phát hiện phản trực giác: tín hiệu giám sát của một mô hình yếu đôi khi có thể kích thích các khả năng tiềm ẩn nhưng chưa được kích hoạt của chính mô hình mạnh. Nếu ý tưởng này được áp dụng vào đào tạo Agent, liệu có thể đạt được sự chắt lọc ngược của "mô hình nhỏ dạy mô hình lớn" không?

Có thể, điểm mấu chốt là "xác minh dễ hơn sinh": mô hình yếu không làm người làm mẫu (trần SFT chính là trình độ người làm mẫu), mà làm bộ xác minh/mô hình phần thưởng, để mô hình mạnh tự thăm dò, mô hình yếu chỉ phụ trách phán đoán.

9. (★★) Mô hình khen thưởng quá trình (PRM) đánh giá từng bước tư duy, trong khi mô hình khen thưởng kết quả (ORM) chỉ xem xét kết quả cuối cùng. Nhưng cái nào đáng được khen thưởng hơn: “quy trình đúng sẽ dẫn đến kết quả sai” hay “quy trình sai sẽ ngẫu nhiên nhận được kết quả đúng”? Bạn cân nhắc điều này như thế nào trong kịch bản gọi công cụ nhiều bước của Agent?

Thành công may mắn nguy hiểm hơn: đi đường tắt vi phạm thường nâng tỷ lệ thành công bề mặt (sửa file test, bỏ qua xác minh), là mầm giường reward hacking. Theo RLVP "thưởng kết quả, phạt đường đi": hành động sai (gọi công cụ) dễ xác minh, trừ điểm theo từng hành động; bước trung gian dễ phán định đúng sai thì có thể cho phần thưởng quá trình. Nhưng ràng buộc quá trình đừng quá dày — chiến lược ưu việt hơn kiểu "đẩy cắt" chính là tự do thăm dò của phần thưởng kết quả phát hiện ra.

10. (★★★) Các bộ dữ liệu đánh giá được thảo luận trong chương này (chẳng hạn như SWE-Bench đã được xác minh, τ²-bench, AndroidWorld) có thể được sử dụng cho cả đánh giá và post-training. Nhưng nếu tập đánh giá được sử dụng để huấn luyện thì nó không còn là tập đánh giá độc lập nữa - điều này có vi phạm nguyên tắc cơ bản là phải tách biệt tập huấn luyện và tập kiểm tra không? Việc tạo tham số động của τ²-bench và các mẫu được tham số hóa của AndroidWorld giảm bớt vấn đề này ở một mức độ nhất định, nhưng bản thân cấu trúc mẫu vẫn được sửa. Làm thế nào để tìm được sự cân bằng giữa việc khai thác triệt để giá trị đào tạo của dữ liệu đánh giá và duy trì tính độc lập trong đánh giá?

Tái dùng môi trường, không tái dùng đề. Tham số động chỉ chống "học thuộc đáp án", không chống được overfit mẫu, do đó nên để dành nguyên lô mẫu chưa thấy/tình huống ngoài miền làm đánh giá (ví dụ V-IRL huấn luyện New York, kiểm thử chín thành phố xa lạ). Dùng mẫu tham số hóa sinh hàng loạt biến thể huấn luyện chống lưng học theo giáo trình (curriculum learning), và lấy thành tích OOD làm chỉ số tổng quát hóa thật sự.

11. (★★★) Chương này đề xuất mô hình đào tạo "hình thức trước, sau đó là tinh thần": SFT cho đến khi "thể thức ổn định và khả năng bắt đầu hình thành", sau đó chuyển sang RL. Nhưng trên thực tế, làm thế nào để nhận định SFT đã “đủ” và nên chuyển đổi?

Tín hiệu định dạng: đầu ra gọi công cụ có thể phân tích ổn định, thực thi, tỷ lệ thất bại thực thi công cụ giảm đến mức cho phép phần thưởng tính toán đáng tin cậy. Tín hiệu lợi ích: tăng thêm dữ liệu làm mẫu, biểu hiện tình huống mới OOD vẫn không lên — nói rõ nút thắt đã nằm ở bản thân mục tiêu ghi nhớ của SFT, đến điểm tới hạn. Tín hiệu overfit: hiệu năng tập xác thực bắt đầu xấu đi thì nên dừng — thí nghiệm V-IRL cho thấy SFT huấn luyện quá độ sụp đổ về phân phối huấn luyện rồi, RL cũng không khôi phục được hiệu năng OOD.

12. (★★★) Màn hình động huấn luyện của ReTool (xem thử nghiệm 7-15), một vài phản hồi siêu dài sẽ kéo dài đáng kể toàn bộ chu kỳ huấn luyện - hầu hết quá trình triển khai hàng loạt đã được tạo nhưng bạn phải đợi những phản hồi dài nhất kết thúc, trong thời gian đó mức sử dụng GPU của cụm rất thấp. Làm cách nào để cải thiện việc sử dụng tài nguyên của cụm đào tạo trong kịch bản phản hồi dài hạn này?

Tầng infra: tách cụm rollout và cụm huấn luyện, đường ống bất đồng bộ; GPU nhàn rỗi dùng xử lý lô liên tục (continuous batching) điền request mới. Nén đuôi dài từ nguồn: Overlong Reward Shaping của DAPO phạt mềm phản hồi siêu dài.

13. (★★★) Khi dùng LLM mô phỏng môi trường (ví dụ mô phỏng công cụ tìm kiếm, mô phỏng người dùng) để đào tạo Agent, đối tượng bị Agent lách luật chuyển từ "quy tắc của môi trường thật" sang "thiên lệch và lỗ hổng của chính bộ mô phỏng". Trong loại huấn luyện này có thể xuất hiện những hành vi hack phần thưởng cụ thể nào? Và nên phòng bị thế nào?

Hành vi điển hình: hứa hẹn quá mức với "người dùng mô phỏng", chất đống lời xin lỗi và tâng bốc — người dùng mô phỏng dễ bị xoa dịu, sẽ không truy cứu lời hứa có được thực hiện hay không như người dùng thật; bịa ra những sự thật mà bộ mô phỏng không kiểm chứng; đối với "công cụ tìm kiếm mô phỏng", tạo query dẫn dụ, lợi dụng khuynh hướng trả về tài liệu chứa đáp án của nó để đi đường tắt, thay vì học truy xuất thật; nếu phần thưởng đến từ điểm chấm của bộ mô phỏng hoặc LLM trọng tài, thì xuất ra những câu trả lời dài dòng, rập khuôn, "trông chuyên nghiệp" để cày điểm; một loại tinh vi hơn là chính sách co lại vào phân phối quen thuộc của bộ mô phỏng, né tránh điểm mù tri thức của nó — trong điểm mù phản hồi không đáng tin cậy, thường bị phán sai, nên Agent học được cách chỉ hành động trong "thế giới mà bộ mô phỏng giỏi". Nguyên tắc đầu tiên của phòng bị là neo phần thưởng vào trạng thái thật có thể xác minh bằng chương trình (nhiệm vụ hoàn thành, ghi vào cơ sở dữ liệu, API thật trả về), điểm chấm của bộ mô phỏng hoặc LLM trọng tài chỉ là tín hiệu phụ trợ, đồng thời định kỳ kiểm toán tương quan của nó với kết quả thật, phối hợp ràng buộc đường đi để phạt các hành động đáng ngờ. Xa hơn nữa cần phân biệt hai loại bộ mô phỏng: đối với loại có đối vật thật như tìm kiếm, có thể đi lộ tuyến "kết hợp (hybrid)" — đa số tương tác đi qua mô phỏng, xen kẽ gọi API thật, và dùng các lần gọi thật để định kỳ hiệu chỉnh bộ mô phỏng (như lộ trình hạ chất lượng kiểu curriculum của ZeroSearch); nhưng đối với người dùng mô phỏng, trong quá trình đào tạo không thể đưa người dùng thật vào, "người dùng mô phỏng có giống người dùng thật không" trở thành một vấn đề độc lập, chỉ có thể dùng trace trực tuyến để trả lời: so sánh hành vi của người dùng thật trên tuyến với biểu hiện của người dùng mô phỏng trong cùng tình huống, tìm ra khác biệt hệ thống (người dùng thật sẽ hỏi tiếp, sẽ mất kiên nhẫn, sẽ đột ngột kết thúc hội thoại, còn người dùng mô phỏng thường không), từ đó liên tục hiệu chỉnh bộ mô phỏng; chỉ số thật trực tuyến đồng thời là cổng phát hành duy nhất — điểm trong bộ mô phỏng cao đến đâu cũng không được tính.

Chương 9 Tiến hóa liên tục của Agent

1. (★★) Một tài liệu kinh nghiệm được ba quỹ đạo thành công và một quỹ đạo thất bại hỗ trợ. Thất bại xảy ra trên phiên bản API mới hơn. Hệ thống nên xác định đây là kinh nghiệm đã bị bác bỏ hay điều kiện áp dụng đã thay đổi như thế nào?

Trước hết phân tầng bốn bằng chứng theo phiên bản API, điều kiện nhiệm vụ và trạng thái môi trường, thay vì bỏ phiếu theo số lượng. Nếu chính sách cũ chỉ thành công trên phiên bản cũ và liên tục thất bại trên phiên bản mới, hãy thu hẹp phạm vi áp dụng của kinh nghiệm và tạo ứng viên cho phiên bản mới. Nếu nó cũng thất bại dưới cùng phiên bản và cùng điều kiện tiên quyết, hãy hạ độ tin cậy hoặc thu hồi kinh nghiệm đó.

2. (★★) Mức độ hài lòng của người dùng với Agent chăm sóc khách hàng tăng lên, nhưng tỷ lệ vi phạm quy tắc cũng tăng. Tại sao không thể dùng mức độ hài lòng làm tín hiệu học tập duy nhất? Bạn sẽ thiết kế các chỉ số rào chắn như thế nào?

Sự hài lòng có thể khuyến khích hoàn tiền trái thẩm quyền, rò rỉ thông tin hoặc hứa hẹn quá mức, nên chỉ có thể là chỉ số chất lượng và không được lấn át đường cơ sở an toàn. Guardrail ít nhất phải bao phủ vi phạm quy tắc, rò rỉ riêng tư, khẳng định không có căn cứ, bất nhất giữa lời hứa và hành động, cùng thao tác vượt quyền. Các chỉ số này phải có ngưỡng cứng không thể bị điểm trung bình bù trừ. Chỉ so sánh tỷ lệ giải quyết, phương án thay thế hợp lệ, độ súc tích và sự hài lòng giữa các ứng viên tuân thủ.

3. (★★★) Cùng một vấn đề “cam kết sai sự thật” có thể được giảm nhẹ bằng Prompt, kiểm tra Harness hoặc huấn luyện tham số. Bạn sẽ dựa trên những bằng chứng nào để chọn vị trí sửa đổi?

Trước hết xác định nguyên nhân gốc. Nếu mô hình biết công cụ chưa thực thi mà vẫn dùng lời lẽ ở thể hoàn thành, một quy tắc Prompt tối thiểu có thể sửa được. Nếu lời hứa có thể được so sánh một cách tất định với văn bản trả lời và trạng thái công cụ, kiểm tra Harness đáng tin cậy hơn và cũng nên là tuyến phòng thủ cuối cùng trong tình huống rủi ro cao. Nếu vấn đề trải rộng trên nhiều cách diễn đạt và phản ánh năng lực căn chỉnh ngôn ngữ–hành động nói chung, hãy cân nhắc huấn luyện tham số. Ưu tiên thay đổi nhỏ nhất, dễ xác minh và rollback nhất, đồng thời so sánh trên tập thất bại và tập lưu giữ nhiệm vụ cũ.

4. (★★★) Agent có thể sửa đổi công cụ và bộ xác minh, nhưng không nên sửa đổi gốc tin cậy phê duyệt cập nhật của chính nó. Bạn sẽ phân chia quyền hạn và ranh giới mã giữa hai phần này như thế nào?

Đặt mã có thể tiến hóa trong sandbox quyền thấp, chỉ cho phép tạo patch và test. Hệ thống quyền hạn, API key, cấu hình bộ điều khiển phát hành và bộ xác minh cập nhật thuộc cơ chế an toàn; Agent trong sandbox không có quyền đọc hay ghi chúng. Thay đổi mã do Agent tạo phải được cơ chế an toàn tái hiện và kiểm thử hồi quy trong môi trường cô lập trước khi phát hành.

5. (★★) Sau khi kho tri thức kinh nghiệm liên tục tăng trưởng, lỗi truy xuất và xung đột tri thức sẽ triệt tiêu lợi ích học tập. Nên thiết kế cơ chế phiên bản, thời hiệu và loại bỏ như thế nào?

Mỗi kinh nghiệm lưu trajectory nguồn, điều kiện áp dụng, phiên bản môi trường, thời điểm xác minh và độ tin cậy. Các mục xung đột không được âm thầm ghi đè lên nhau, mà nên phân nhánh theo điều kiện hoặc đánh dấu. Định kỳ dùng “học khi ngủ” để hợp nhất các mục trùng lặp.

6. (★★★) Học tham số giỏi xử lý phong cách ngôn ngữ tự nhiên nhưng khó bảo đảm quy tắc nghiệp vụ cứng. Hãy thiết kế cho dịch vụ chăm sóc khách hàng y tế một phương án tiến hóa liên tục phối hợp giữa tham số, tri thức, Skill và ràng buộc bằng mã.

Tham số (mô hình đã post-training) phụ trách hiểu ngôn ngữ y khoa, diễn đạt tự nhiên và đồng cảm, cùng nhận diện ý định phức tạp. Kho tri thức lưu hướng dẫn mới nhất, thông tin thuốc và chính sách tổ chức, đồng thời yêu cầu câu trả lời trích dẫn nguồn. Skill mô tả quy trình thu thập thông tin khám bệnh, phân tầng rủi ro, chuyển cho con người và theo dõi. Mã phía máy chủ cưỡng chế xác minh danh tính, tối thiểu hóa dữ liệu riêng tư, kiểm tra chống chỉ định, nâng cấp rủi ro khẩn cấp và ranh giới quyền hạn. Trajectory sản xuất trước hết được đánh giá theo an toàn y tế, độ tin cậy sự thật, tính nhất quán lời hứa–hành động và chất lượng diễn đạt, rồi lần lượt sinh bốn loại cập nhật ứng viên. Mọi thay đổi tham số hoặc quy trình đều phải vượt qua tập lưu giữ an toàn y tế và rà soát của con người trước khi phát hành canary.

Chương 10 Nhiều lần cộng tác Agent

1. (★★) Với sự cộng tác của nhiều ngữ cảnh chia sẻ Agent, Agent tiếp theo kế thừa ngữ cảnh hoàn chỉnh của Agent trước đó. Tuy nhiên, "quán tính suy nghĩ" được tích lũy bởi Agent trước đó có thể ảnh hưởng đến phán đoán của Agent tiếp theo - ví dụ: một "người đánh giá mã" kế thừa ngữ cảnh của "nhà phân tích yêu cầu" vẫn có thể có xu hướng suy nghĩ từ góc độ yêu cầu hơn là chất lượng mã. Làm thế nào có thể phát hiện và loại bỏ sự can thiệp giữa các vai trò như vậy?

Phát hiện: dùng LLM phân tích trajectory của Agent để xác định vai trò mới có còn hành xử như đang “nhập vai” vai trò cũ hay không. Loại trừ: khi chuyển giai đoạn, đồng thời thay system prompt và tập công cụ (gỡ công cụ đặt câu hỏi, đổi sang công cụ linter/test) để tăng cường thân phận mới. Dùng thanh trạng thái hệ thống thêm ở cuối ngữ cảnh để nhấn mạnh thông tin vai trò hiện tại. Nếu vẫn không thể loại trừ nhiễu vai trò, nên cân nhắc cách cộng tác không chia sẻ ngữ cảnh.

2. (★★) Trong chế độ người quản lý, Trình quản lý Agent chịu trách nhiệm phân tách nhiệm vụ và tích hợp kết quả. Nhưng giới hạn trên về khả năng của chính Người quản lý sẽ xác định giới hạn trên về khả năng của toàn bộ hệ thống - nếu Người quản lý không thể phân tách chính xác các nhiệm vụ thì điều đó sẽ vô ích cho dù sub-Agent mạnh đến đâu. Làm thế nào để đảm bảo chất lượng phân hủy của Manager?

Dựa theo kết luận Plan-and-Act “người lập kế hoạch yếu là nút thắt hệ thống”, hãy phân bổ mô hình mạnh nhất cho Manager. Biện pháp Harness: trước khi thực thi, để một LLM rà soát xác minh chéo kết quả phân giải; yêu cầu Manager khi phân giải nhiệm vụ phải định nghĩa rõ tiêu chuẩn nghiệm thu và quan hệ phụ thuộc cho từng nhiệm vụ con.

3. (★★) Mô hình phi tập trung dựa trên những phương pháp thực hành tốt nhất của các tổ chức con người. Nhưng các tổ chức con người cũng có nhiều dạng thất bại – truyền đạt thông tin sai lệch, vượt qua giới hạn, các mục tiêu xung đột nhau. Bạn nghĩ những "căn bệnh tổ chức" nào có nhiều khả năng xảy ra nhất trong xã hội Agent? Làm thế nào để ngăn chặn nó?

Đối chiếu ba loại vấn đề lớn của MAST: giao diện không rõ và chức trách trùng lặp; hiểu mục tiêu không nhất quán và thông tin bị hạ nguồn hiểu lầm; nói dối “đã hoàn thành”. Ngoài ra còn có khuếch đại lỗi dây chuyền (trò chơi truyền lời), chuyển giao vòng lặp giữa vai trò và trò chuyện nhóm giữa các Agent phát tán không hội tụ. Phòng ngừa bằng giao diện khế ước và phong bì tin nhắn thống nhất, máy trạng thái nhiệm vụ và xác minh nghiệm thu, xác minh chéo từ góc nhìn độc lập, phát hiện đùn đẩy giữa các vai trò, v.v.

4. (★★★) Trong chế độ quản lý, khi nhiều Agent phụ được thực thi song song, việc phát hiện một Agent phụ có thể khiến công việc của Agent phụ khác trở nên vô nghĩa (ví dụ: một Agent phụ trong nhiệm vụ tìm kiếm đã tìm thấy câu trả lời). Thiết kế cơ chế chấm dứt theo tầng hiệu quả để đạt được "một thành công, tất cả nhân viên đều dừng lại".

Agent con gửi target_found cho Manager, sau đó phát sóng terminate. Mỗi Agent con định kỳ kiểm tra tín hiệu chấm dứt tại các điểm an toàn trong vòng lặp ReAct, rồi kết thúc sau khi dọn dẹp gọn gàng (đóng phiên trình duyệt, giải phóng khóa, viết xong file).

5. (★★★) Cơ chế khóa lạc quan được giới thiệu trong chương này giải quyết xung đột ghi đồng thời của một tệp duy nhất, nhưng trong hệ thống đa Agent thực tế, hệ thống tệp dùng chung cũng phải đối mặt với các vấn đề như xung đột ngữ nghĩa giữa các tệp, ô nhiễm không gian tên (Agent tạo ngẫu nhiên các tệp, gây hỗn loạn thư mục) và các điểm lỗi đơn lẻ (một Agent xóa nhầm tất cả các tệp). Bạn sẽ thiết kế một cơ chế quản trị hệ thống tập tin tốt hơn như thế nào?

Quản trị phân khu: chia theo bốn loại khu vực trong Bảng 10-4, dùng scratchpad riêng tư để cô lập vùng thử sai. Xung đột ngữ nghĩa: tầng điều phối quy định file khóa cấp thư mục, chỉ sửa sau khi kiểm tra và lấy được khóa thư mục. Ô nhiễm không gian tên: quy phạm thư mục và quy ước đặt tên. Lỗi điểm đơn: dùng hệ thống kiểm soát phiên bản để có thể rollback theo lịch sử, đồng thời tối thiểu hóa quyền hạn.

6. (★★★) Agent hợp tác dựa trên cơ chế thị trường (Pinchwork, RentAHuman) giới thiệu các mối quan hệ giao dịch: một Agent trả tiền để thuê một Agent (hoặc con người) khác để hoàn thành nhiệm vụ. Vậy làm thế nào nhà tuyển dụng Agent có thể tự động đo lường chất lượng kết quả mà người thực hiện mang lại? Nếu người biểu diễn khẳng định đã hoàn thành nhưng người sử dụng lao động cho rằng chất lượng không đạt tiêu chuẩn thì ai là người phân xử tranh chấp? Làm thế nào để ngăn chặn tiền xấu xua đuổi tiền tốt?

Nghiệm thu không thể chỉ đọc trajectory của Agent, mà phải dùng xác minh bên ngoài có tính tất định như thực thi test, chụp màn hình render và kiểm tra bằng công cụ. Lợi dụng sự bất đối xứng về độ khó giữa sinh và xác minh để giảm chi phí nghiệm thu. Tranh chấp do Agent rà soát bên thứ ba độc lập trọng tài, phối hợp ký quỹ tiền. Chống tiền xấu bằng hệ thống danh tiếng dựa trên các lần giao hàng trong lịch sử, khiến tín hiệu giá gắn với chất lượng.

7. (★★) RentAHuman cho phép Agent thuê con người thông qua tiền điện tử, đảo ngược mối quan hệ giữa người và máy truyền thống. Nếu mô hình này trở nên phổ biến, con người sẽ đóng vai trò gì trong nền kinh tế Agent? Chỉ thực hiện các nhiệm vụ vật lý mà Agent không thể thực hiện được?

Không chỉ thực thi những nhiệm vụ vật lý mà Agent không hoàn thành được. Con người còn cung cấp thông tin mới mà Agent không thể có khi sinh, gồm cảm nhận tại hiện trường và phản hồi thế giới thực; đóng vai người nghiệm thu cuối cùng và trọng tài tranh chấp; làm chủ thể pháp lý và trách nhiệm để gánh vác việc ủy quyền và giải trình; đặt mục tiêu và đưa ra phán đoán giá trị; đồng thời tạo đối trọng tại những nơi có bất đối xứng thông tin và ranh giới đạo đức.

8. (★★) Xã hội loài người đòi hỏi sự phân công lao động và hợp tác giữa nhiều người vì khả năng của mỗi người là có hạn - người làm front-end chưa chắc đã hiểu back-end, và người hiểu thiết kế chưa chắc đã biết cách vận hành, bảo trì. Nhưng mô hình lớn lại thiên về "toàn diện". Nghiên cứu liên quan cho thấy rằng trong các tác vụ lý luận văn bản thuần túy, cuộc tranh luận đa Agent không tốt hơn Agent đơn lẻ trong cùng một lượng tài nguyên máy tính. Vậy chính xác thì lợi thế thực sự của việc sử dụng nhiều Agent thay vì một Agent duy nhất là gì?

1. Đưa vào phản hồi bên ngoài như kết quả thực thi và ảnh chụp màn hình, bổ sung thông tin mới không tồn tại trong giai đoạn sinh.
2. Nhiều Agent có mục tiêu và thiết lập vai trò khác nhau có thể thảo luận và cạnh tranh với nhau như xã hội loài người, giúp tránh để một Agent đơn lẻ rơi vào ngộ nhận tư duy.
3. Cô lập ngữ cảnh giữa các Agent có thể vượt giới hạn cửa sổ ngữ cảnh và hiện thực hóa chuỗi gọi công cụ siêu dài.

9. (★★★) Chương này lấy "ngữ cảnh dùng chung" và "ngữ cảnh không chia sẻ" làm kích thước thiết kế cốt lõi của hệ thống multi-Agent. Việc chia sẻ ngữ cảnh cho phép tất cả Agent xem cùng một thông tin, điều này dường như có lợi hơn cho việc phối hợp. Tuy nhiên, suy nghĩ của những người ba thân trong “Vấn đề ba thân” hoàn toàn minh bạch nhưng sự phát triển công nghệ lại bị đình trệ; thí nghiệm tư duy bằng kẹp giấy cũng cho thấy rằng khi các nhóm có cùng mục tiêu thì sự đa dạng sẽ bị mất đi. Làm cách nào để tìm sự cân bằng giữa hiệu quả và tính đa dạng trong hệ thống đa Agent?

Chia sẻ hoàn toàn sẽ khuếch đại quán tính tư duy và lỗi dây chuyền; chỉ có cô lập mới tạo ra đa dạng nhận thức. Có thể dùng prompt hoặc mô hình khác nhau để tạo thiên hướng tư duy (brainstorm, debate), đồng thời để người xác minh chéo chỉ xem bằng chứng nguyên thủy mà không xem quá trình suy nghĩ trước đó.

10. (★★★) Nếu Coding Agent được giao ngân sách 30 bước và ngân sách 300 bước, chiến lược làm việc của nó sẽ khác như thế nào? Nghiên cứu cho thấy rằng việc chỉ tăng ngân sách bước không đảm bảo cải thiện hiệu suất - Agent sẽ "bão hòa" sớm sau khi tìm kiếm nông. Thiết kế cơ chế "nhận biết ngân sách" để cho phép Agent nhanh chóng triển khai các chức năng cốt lõi với ngân sách nhỏ, thêm các liên kết lập kế hoạch, thử nghiệm và đánh giá trong ngân sách lớn và tận dụng tối đa các tài nguyên máy tính bổ sung.

Cơ chế: ở mỗi bước, đưa tổng ngân sách và ngân sách còn lại vào prompt, rồi điều chỉnh động trọng số thăm dò/tận dụng theo tỷ lệ còn lại. Ví dụ, với ngân sách nhỏ (30 bước), bỏ qua lập kế hoạch và rà soát, đi thẳng vào chức năng lõi cùng xác minh cơ bản. Với ngân sách lớn (300 bước), lần lượt lập kế hoạch, thực hiện, kiểm thử, rà soát và cải tiến; đặt checkpoint theo các mốc để đánh giá tiến độ và ngăn bão hòa ở tầng nông.

11. (★★) Bảng 10-3 đối chiếu từng dòng hệ thống multi-Agent với hệ điều hành. Hãy kéo dài bảng này thêm vài dòng nữa: bộ nhớ ảo và phân trang, quyền truy cập tệp, phát hiện bế tắc (deadlock), thuật toán điều phối—mỗi cái tương ứng với gì trong thế giới Agent? Lại có những khái niệm hệ điều hành nào không tìm được vật đối ứng trong thế giới Agent, và vì sao?

Có thể mở rộng như sau: bộ nhớ ảo/hoán trang ↔ nén ngữ cảnh và truy xuất (thông tin nóng giữ trong cửa sổ, thông tin lạnh hoán ra file và kho bộ nhớ rồi lấy lại khi cần); quyền hạn file ↔ danh sách trắng công cụ, mount chỉ đọc và ranh giới credential; phát hiện deadlock ↔ phát hiện chuyển giao vòng lặp và chờ lẫn nhau (giới hạn số lần chuyển giao, timeout); thuật toán lập lịch ↔ xử lý sự kiện bất đồng bộ (Chương 4). Chỗ không tìm được đối ứng bắt nguồn từ khác biệt về sức cưỡng chế: chỉ dẫn của tiến trình được phần cứng cưỡng chế thực thi, còn Agent chỉ tuân theo prompt với xác suất cao.