Bốn paper, một kết luận: agent khá lên ở lớp vỏ, không ở lõi model

Bối cảnh: hai cần gạt chưa từng được kéo cùng lúc

Một agent thực chất là hai thứ chồng lên nhau. Bên dưới là model — trọng số, thứ bạn đổi bằng fine-tune. Bên trên là harness — system prompt, danh sách tool, các hook thực thi, toàn bộ scaffolding điều phối vòng lặp. Ngành đã có nhiều công trình về từng cái riêng lẻ: tự động tiến hoá harness là một dòng, distill từ model mạnh là dòng kia. Nhóm Salesforce đặt câu hỏi hiển nhiên mà chưa ai đo: nếu làm cả hai, chúng cộng vào nhau hay chống nhau?

Cách làm, từng bước

(1) Tiến hoá harness quanh model yếu trên tập task chuyên ngành. Đây là bước cho kết quả dương, đúng như kỳ vọng: harness được may đo cho đúng năng lực của model đang dùng.

(2) Cho model mạnh chạy trên chính harness đã tiến hoá đó để thu trajectory chuẩn. Đây là công thức distill kinh điển.

(3) Fine-tune model yếu trên trajectory đó — và đây là chỗ mọi thứ gãy. Vấn đề nằm ở chữ on-policy: trajectory của model mạnh là chuỗi hành động tối ưu cho năng lực của model mạnh. Model mạnh có thể lên kế hoạch năm bước rồi thực thi trơn tru; model yếu học thuộc cái kế hoạch năm bước ấy nhưng gãy ở bước thứ ba, và giờ nó vừa mất kế hoạch cũ (kế hoạch nó thực thi được) vừa không hoàn thành kế hoạch mới.

(4) On-policy correction. Thay vì thay thế toàn bộ trajectory, để model yếu tự chạy sinh rollout của chính nó. Một agent MLE cấp meta xác định lượt đầu tiên mà việc thực thi đổ vỡ. Chuyên gia chỉ viết lại đúng lượt đó, giữ nguyên toàn bộ ngữ cảnh trước và sau. Model yếu học một bản sửa nằm trong tầm với của nó, chứ không phải một phong cách xa lạ.

Số liệu đáng nhớ

Hạn chế

Bản abstract không liệt kê hạn chế rõ ràng. Ba chỗ đáng tự soi khi đọc bản đầy đủ: tập task là doanh nghiệp và chỉ có bảy cái, nên mức phổ quát chưa rõ; quy trình cần một model mạnh và một agent MLE cấp meta, tức đắt hơn distill thường; và "lượt bị gãy" được xác định tự động, nên chất lượng của bộ định vị đó là điểm gãy tiềm tàng của cả pipeline.

Bối cảnh: vì sao "trí nhớ nén" là một ràng buộc, không phải một tính năng

Cách phổ biến để cho agent xử lý tài liệu dài là bắt nó đọc tuần tự và mang theo một bản tóm tắt đang lớn dần. Nghe hợp lý, nhưng nó gắn chặt hai thứ vốn nên rời nhau. Đọc là thao tác mở rộng theo bề ngang — càng nhiều mắt càng tốt. Suy luận là thao tác đi theo chiều sâu — cần nhiều vòng trên cùng một tập bằng chứng. Ép hai thứ vào một vòng lặp tuần tự khiến mỗi bên đều bị bên kia giới hạn: bạn không thể suy luận sâu về phần cuối tài liệu cho tới khi đã đọc qua, và bạn không thể đọc lại phần đầu mà không trả giá bằng độ trễ.

Hệ quả đo được là hiện tượng quen thuộc: bằng chứng nằm ở giữa tài liệu thì độ chính xác tụt, đổi thứ tự đoạn văn thì điểm số nhảy. Đó là dấu hiệu hệ thống đang phụ thuộc vào vị trí chứ không vào nội dung.

Cách hoạt động, từng bước

(1) Chia và phát. Tài liệu được cắt thành chunk, mỗi chunk gán một subagent nhẹ. Toàn bộ chạy song song, nên bước đọc tốn thời gian bằng một chunk chứ không bằng tổng.

(2) Scatter. Lead agent phát một truy vấn tới toàn bộ subagent cùng lúc. Mỗi subagent chỉ nhìn phần của mình và trả về bằng chứng liên quan.

(3) Gather. Lead agent gom các mẩu bằng chứng lại và đánh giá: đã đủ để trả lời chưa, còn thiếu mắt xích nào.

(4) Lặp sâu dần. Dựa trên những gì vừa tìm được, lead agent soạn truy vấn tiếp theo — cụ thể hơn, nhắm vào mắt xích còn thiếu. Đây chính là chỗ "reason in depth": chiều sâu đến từ số vòng hỏi, không đến từ việc đọc thêm.

(5) Huấn luyện có chọn lọc. Chỉ lead agent được luyện bằng RL — nó học cách hỏi. Subagent giữ nguyên model off-the-shelf, đóng băng. Thiết kế này rẻ: bạn train một model nhỏ để điều phối, không train cả bầy.

Số liệu đáng nhớ

Hạn chế

Abstract không nêu hạn chế cụ thể. Cái giá lộ rõ từ thiết kế: mỗi vòng scatter gọi model một lần cho mỗi chunk, nên số lời gọi song song lớn — nhanh về thời gian thực nhưng không nhất thiết rẻ về token. Bài đo trên multi-hop QA; loại việc cần tổng hợp toàn cục (ví dụ "tóm tắt cả cuốn") có thể không hưởng lợi giống vậy.

Bối cảnh: kiến thức ngầm là kiến thức không sửa được

Khi agent quyết định bước kế tiếp bằng cách đọc lại toàn bộ lịch sử, quy trình mà nó đang theo là có thật nhưng vô hình. Bạn không chỉ tay vào được, không kiểm tra được, và quan trọng nhất là không sửa được — muốn đổi hành vi thì chỉ còn cách viết lại prompt hoặc train lại. Đó là lý do agent dài hơi hay hỏng theo ba kiểu rất giống nhau: quên mục tiêu ban đầu, gọi tool sai thứ tự, và lặp lại chính thao tác vừa thất bại.

Ý tưởng của nhóm Google là mượn đúng bước chuyển mà knowledge graph từng làm cho kiến thức sự kiện. Knowledge graph khiến "Paris là thủ đô của Pháp" thành một cạnh tra cứu được thay vì một câu chìm trong văn bản. Procedural graph làm điều tương tự cho quy trình.

Cách hoạt động, từng bước

(1) Biểu diễn. Đồ thị lưu bộ ba (thủ tục, quan hệ, thủ tục). Node là các bước; cạnh mang thông tin về thứ tự và điều kiện áp dụng.

(2) Định vị node đang hoạt động. Ở mỗi bước quyết định, framework xác định agent đang đứng ở đâu trên đồ thị.

(3) Trích và diễn giải. Lấy subgraph quanh node đó, đưa qua một guidance model để biến thành gợi ý ở mức từng bước.

(4) Bias, không dictate. Gợi ý làm lệch phân phối hành động kế tiếp của solver chứ không thay nó quyết. Đây là lựa chọn thiết kế then chốt: giữ được quyền tự chủ để agent vẫn xử lý được tình huống ngoài đồ thị.

(5) Vòng tự tiến hoá. Một LLM refiner đối chiếu trajectory thất bại với trajectory thành công rồi sửa topology và thuộc tính của đồ thị. Thay đổi chỉ được commit nếu điểm trên tập validation giữ nguyên hoặc tốt lên. Thay đổi bị bác vẫn được lưu hồ sơ, nên cùng một đề xuất không bị đưa ra hai lần.

Số liệu đáng nhớ

Abstract không công bố bảng số cụ thể; các con số chi tiết nằm trong bản đầy đủ.

Hạn chế

Không nêu hạn chế tường minh. Hai điểm cần soi: cổng validation bảo vệ chất lượng đồ thị nhưng cũng khiến vòng tiến hoá chỉ tốt bằng tập validation — một tập hẹp sẽ commit những thay đổi overfit; và framework thêm hai lời gọi model mỗi bước (định vị + guidance), nên chi phí trên mỗi hành động tăng.

Bối cảnh: khi abstraction hỏng nhanh hơn tốc độ bạn vá

Hầu hết tranh luận "agent viết code" xoay quanh việc agent viết được bao nhiêu. Paper này hỏi câu khác: nếu agent viết code đủ rẻ, thì artifact nào mới đáng giữ lâu dài? Với đa số phần mềm, câu trả lời vẫn là source code. Nhưng mô hình hoá hiệu năng ML là một miền đặc biệt tàn nhẫn — mỗi thế hệ phần cứng và mỗi kiến trúc model mới làm vô hiệu chính những abstraction mà thư viện được xây quanh. Vá thì được, nhưng nợ kỹ thuật tích lại nhanh hơn tốc độ trả.

Lựa chọn của nhóm là đảo vai: giữ design doc làm artifact bền, coi code là sản phẩm build.

Cách hoạt động, từng bước

(1) Repo là một DAG các design doc. Mỗi doc tự chứa, viết bằng ngôn ngữ tự nhiên, và nối với nhau thành đồ thị có hướng.

(2) Doc được viết quanh ví dụ đã làm từng bước. Đây không phải văn phong cho đẹp — các ví dụ đó đóng vai trò in-context demonstration cho agent sinh code. Doc vừa là đặc tả cho người vừa là prompt cho máy.

(3) Neo vào một IR tối thiểu. Hệ thống dựng trên một operator IR định nghĩa đệ quy, nhỏ, với biểu thức chi phí dạng ký hiệu bằng SymPy. Đây là phần chống trôi: agent có tự do diễn đạt nhưng phải hạ cánh xuống một biểu diễn cố định, kiểm tra được.

(4) Hai chế độ phân tích. Một chế độ giải tích nhanh để quét tham số diện rộng; một chế độ modulo-scheduling chậm và chi tiết để nghiên cứu lịch trình ở mức mịn.

(5) Sinh lại khi đổi version. Các coding sub-agent dựng lại toàn bộ implementation từ doc. Người không chạm vào code sinh ra.

Số liệu đáng nhớ

Hạn chế

Bản trích không liệt kê hạn chế. Ranh giới áp dụng khá rõ từ chính thiết kế: cách này sống được vì miền bài toán có oracle kiểm chứng khách quan — mô hình hiệu năng đúng hay sai đối chiếu được bằng số. Ở miền không có oracle như vậy, "sinh lại từ doc" mất đúng cái lưới an toàn khiến nó dùng được. Và tính xác định là câu hỏi mở: hai lần sinh từ cùng một doc không đảm bảo ra cùng một code.