Hãy tưởng tượng nhóm kỹ sư của bạn vừa triển khai một tác nhân AI để tìm kiếm tài liệu nội bộ và trả lời câu hỏi của nhân viên. Nó hoạt động hoàn hảo trong môi trường phát triển, nhưng khi đưa vào sản xuất, nó liên tục "ảo giác" hoặc bỏ sót các ràng buộc quan trọng. Việc khắc phục điều này hiếm khi đơn giản. Nó đòi hỏi một quy trình thử-và-sai tẻ nhạt, đồng thời tinh chỉnh các chiến lược phân đoạn (chunking), phương pháp truy xuất (retrieval) và lời nhắc hệ thống (system prompts). Vì những điều chỉnh này thường bị "rối" vào nhau, gần như không thể xác định cụ thể điều chỉnh nào đã thực sự giải quyết vấn đề.Để giải quyết thách thức này, các nhà nghiên cứu tại Đại học Nhân dân Trung Quốc và Microsoft Research đã giới thiệu Arbor — một framework nâng cấp quá trình nghiên cứu và tối ưu hóa dựa trên AI từ một chuỗi các phỏng đoán thử-và-sai thành một quá trình học hỏi tích lũy. Arbor tổ chức các giả thuyết, thử nghiệm và thông tin chi tiết vào một cấu trúc dạng cây, giúp hệ thống học hỏi từ các thất bại trước đó để thực hiện các cải tiến thông minh hơn, đã được xác minh theo thời gian. Trong các thử nghiệm thực tế, Arbor đã mang lại hiệu suất cải thiện có thể kiểm chứng được cao hơn 2.5 lần so với các tác nhân mã hóa AI tiêu chuẩn trong các tác vụ kỹ thuật thực tế, trong khi vẫn hoạt động với cùng một ngân sách tài nguyên. Đối với AI doanh nghiệp, kỹ thuật này trực tiếp dẫn đến việc tự động hóa quá trình cải tiến liên tục cho các hệ thống kỹ thuật phức tạp, hoạt động trong thế giới thực.
Hiểu Rõ Nút Thắt Trong Tối Ưu Hóa Tự Động 🚧
Khi các mô hình ngôn ngữ lớn (LLM) và hệ thống AI trở nên mạnh mẽ hơn, chúng được kỳ vọng sẽ thực hiện các hoạt động phức tạp hơn như tối ưu hóa tự động (Autonomous Optimization – AO) các hệ thống phần mềm như công cụ tác nhân hoặc thuật toán huấn luyện mô hình.
AO nắm bắt vòng lặp cơ bản của nghiên cứu tự động. Một tác nhân AI bắt đầu với một "hiện vật" ban đầu có thể thay đổi, chẳng hạn như cơ sở mã máy học hoặc đường ống dữ liệu, và một mục tiêu cụ thể. Mục tiêu của tác nhân là lặp đi lặp lại để cải thiện hiện vật này thông qua phản hồi thử nghiệm mà không cần sự giám sát từng bước của con người.
Thách thức chính của AO thường bị hiểu sai. Nhiều nhóm kỹ thuật nhận thấy rằng việc đơn giản cấp thêm thời gian hoặc năng lực tính toán cho một tác nhân mã hóa để tối ưu hóa cơ sở mã không dẫn đến kết quả tốt hơn. "Tự động hóa có thể giữ cho một AI hoạt động trong một thời gian rất dài – nhưng một vòng lặp không giống như sự tiến bộ," Jiajie Jin, đồng tác giả của bài báo, chia sẻ với VentureBeat. "Nếu mục tiêu mơ hồ, hoặc chỉ số dễ bị 'hack', tự động hóa chạy dài thường chỉ tạo ra những 'cải tiến' nhanh hơn mà không ai thực sự mong muốn."
Jin giải thích rằng các tác vụ phức tạp cần nhiều lần thử để thành công, và kiến trúc tác nhân tiêu chuẩn đang thiếu cấu trúc dữ liệu quan trọng để duy trì trạng thái. "Làm thế nào để bạn đảm bảo thông tin chi tiết và kinh nghiệm từ mỗi lần thử thực sự tích lũy, thay vì bị mất trong một bộ đệm cuộn?" ông nói. Nếu không có cấu trúc này, các tác nhân đơn giản chỉ lặp lại những lỗi tương tự.
Các hệ thống tác nhân hiện tại có thể chạy thử nghiệm hàng giờ với các mục tiêu được xác định rõ: chỉnh sửa mã, gọi công cụ, chạy thử nghiệm tự động. Nhưng chúng xử lý mỗi lần thử một cách riêng lẻ, bỏ lỡ các cơ chế cấu trúc cho phép chúng tích lũy và hành động dựa trên những gì đã học. Chúng thiếu khả năng đồng thời duy trì và so sánh nhiều hướng nghiên cứu cạnh tranh. Không có điều này, chúng không thể giải thích cả thành công và thất bại để định hình sự khám phá trong tương lai, vốn là cơ chế cốt lõi khiến nghiên cứu của con người mang tính tích lũy.
Các tác nhân mã hóa tổng quát thường dựa vào bản ghi hội thoại làm bộ nhớ của chúng. Vì các tác vụ AO kéo dài hàng trăm lượt và dễ dàng vượt quá giới hạn cửa sổ ngữ cảnh, các tác nhân này gặp khó khăn trong việc lưu giữ và tái sử dụng bằng chứng thực tế trong lịch sử dài. Kết quả là, chúng mất đi cấu trúc tổng thể của quá trình nghiên cứu và dễ bị mắc kẹt ở những thất bại ban đầu hoặc theo đuổi những biến động đánh giá "nhiễu". Hệ thống cần một bộ nhớ có cấu trúc, bền vững ghi lại những hướng nào đã được thử, bằng chứng thực tế nào đã được tạo ra và mỗi kết quả thay đổi không gian các giả thuyết trong tương lai như thế nào.
Các framework hiện có cũng dễ bị "thưởng hack" (reward hacking) và "quá khớp" (overfitting) với các chỉ số phát triển. Điều này khiến chúng tạo ra ảo ảnh về sự tiến bộ mà không tạo ra những cải tiến thực sự chuyển giao sang hiệu suất trong thế giới thực.
Cuối cùng, các tác nhân mã hóa đa năng thường xâu chuỗi các lệnh gọi công cụ của chúng trên một cây làm việc chung duy nhất. Hạn chế kiến trúc này ngăn chúng kiểm tra các giả thuyết song song trong các môi trường biệt lập mà không làm hỏng cơ sở mã chính hoặc che khuất giả thuyết nào gây ra một kết quả cụ thể.
Khung Arbor: Giải Pháp Tối Ưu Hóa "Cây Giả Thuyết" 🌳
Arbor giải quyết các thách thức của AO bằng một framework tự động hóa vòng lặp khám phá, thử nghiệm và trừu tượng hóa kéo dài, vốn là đặc trưng của nghiên cứu con người. Arbor tách biệt hướng chiến lược của nghiên cứu khỏi các tác vụ mã hóa cấp thấp với hai thành phần chính:
Người Điều Phối (The Coordinator): Một tác nhân AI tồn tại lâu dài, hoạt động giống như một nhà điều tra chính. Nó không bao giờ trực tiếp chỉnh sửa cơ sở mã mục tiêu. Thay vào đó, nó sở hữu trạng thái chung của nghiên cứu tối ưu hóa, quan sát bằng chứng tích lũy, đưa ra các giả thuyết và hướng khám phá mới, và quyết định phải làm gì với kết quả của các thử nghiệm. Người Thực Thi (Executors): Các tác nhân AI tồn tại ngắn ngủi, tập trung cao độ. Khi người điều phối muốn kiểm tra một ý tưởng, nó sẽ khởi tạo một người thực thi và đặt nó vào một môi trường biệt lập, về cơ bản là một "git worktree" mới. Mỗi người thực thi được giao một giả thuyết. Nó triển khai ý tưởng được giao, chạy đánh giá, gỡ lỗi và báo cáo lại cho người điều phối với các kết quả và hiện vật đã tạo.
Hai thành phần này cộng tác thông qua một cơ chế mà các nhà nghiên cứu gọi là "Cải Tiến Cây Giả Thuyết" (Hypothesis Tree Refinement – HTR). HTR đại diện cho toàn bộ quá trình nghiên cứu dưới dạng một cây phân nhánh, bền vững, nơi mỗi nút liên kết bốn điều: một giả thuyết, hiện vật có thể thực thi, bằng chứng thực tế được tạo ra và một thông tin chi tiết được chắt lọc. Điều này có nghĩa là người điều phối có thể khám phá nhiều hướng cạnh tranh cùng một lúc mà không bị mất dấu.
Người điều phối xây dựng cây bằng cách đặt các ý tưởng rộng ở gần gốc, trong khi các tinh chỉnh cụ thể phân nhánh ra thành các lá. Điều này cho phép Arbor an toàn khám phá nhiều giả thuyết cạnh tranh cùng lúc. Nếu thử nghiệm của một người thực thi thất bại, cây sẽ ghi lại lý do thất bại như một ràng buộc tiêu cực, đảm bảo hệ thống không lặp lại mãi mãi cùng một lỗi.
Để hiểu tại sao sự cô lập của Arbor lại quan trọng, hãy xem xét một kịch bản doanh nghiệp phổ biến: tối ưu hóa một đường ống Retrieval-Augmented Generation (RAG) cho một trợ lý AI nội bộ. "Khi bạn yêu cầu một tác nhân duy nhất như Claude Code hoặc Codex 'cải thiện độ chính xác,' nó thường sẽ thay đổi một loạt thứ trong một lần – phân đoạn, lời nhắc, phương pháp truy xuất," Jin nói. Điều này làm "rối" các thay đổi, khiến không thể quy kết cái nào thực sự giúp ích. Nó cũng trực tiếp thay đổi kho lưu trữ mà không có sự cô lập.
Arbor giải quyết điều này bằng cách coi mỗi đòn bẩy là một giả thuyết riêng biệt. Phân đoạn trở thành một nhánh, truy xuất một nhánh khác, và lời nhắc một nhánh khác – mỗi nhánh được triển khai và đánh giá trong "git worktree" riêng biệt. "Vì vậy, bạn có sự phân bổ rõ ràng: 'phân tích ràng buộc về phía truy xuất cho +X; tìm kiếm theo chiều rộng thực sự gây hại'," Jin nói.
Khi một người thực thi trả về báo cáo, người điều phối ghi bằng chứng vào cây và truyền ngược thông tin chi tiết lên các nút cha. Điều này có nghĩa là một quan sát cục bộ trở thành một ràng buộc tổng quát định hình việc tạo ý tưởng trong tương lai của người điều phối.
Để ngăn chặn "thưởng hack" hoặc "quá khớp" với dữ liệu phát triển, HTR thực thi một "cổng hợp nhất" (merge gate) nghiêm ngặt. Ngay cả khi một người thực thi báo cáo điểm phát triển tuyệt vời, người điều phối sẽ khởi tạo một "worktree" biệt lập để kiểm tra ứng viên với một bộ đánh giá kiểm tra được giữ lại. Hiện vật chỉ được hợp nhất vào nhánh tốt nhất hiện tại nếu nó chứng minh được sự cải thiện điểm kiểm tra, xác minh rằng sự tiến bộ là có thật.
Arbor nhìn chung nằm trong khái niệm "kỹ thuật vòng lặp" (loop engineering), được phổ biến bởi các nhân vật trong ngành như Peter Steinberger (người tạo ra OpenClaw) và Boris Cherny (trưởng nhóm Claude Code). Ý tưởng là vượt ra ngoài các lời nhắc đơn lẻ để thiết kế các chu trình lặp (quan sát, suy luận, hành động, xác minh) thúc đẩy các tác nhân tự động. Tuy nhiên, như Jin chỉ ra, "Một vòng lặp có thể chứa đầy những nỗ lực lộn xộn, không thể truy vết, và bạn kết thúc mà không có gì để thể hiện và không có cách nào để tái tạo những gì đã thay đổi."
Arbor Trong Thực Tế: Hiệu Suất Vượt Trội 🥇
Các nhà nghiên cứu đã đánh giá Arbor trên một bộ tác vụ tối ưu hóa tự động được xây dựng từ các thiết lập nghiên cứu thực tế và benchmark kỹ thuật máy học MLE-Bench Lite. Bộ AO bao gồm các tác vụ từ các lĩnh vực phát triển AI khác nhau, bao gồm huấn luyện mô hình, kỹ thuật công cụ và tổng hợp dữ liệu.
Các nhà nghiên cứu đã sử dụng các mô hình nền tảng khác nhau cho tác nhân điều phối và tác nhân thực thi, bao gồm Claude Opus 4.6, GPT-5.5 và Gemini-3-Flash. Họ đã thử nghiệm Arbor chống lại các tác nhân mã hóa mạnh nhất, Codex và Claude Code. Arbor và các hệ thống cơ sở được cung cấp cùng một tài nguyên. Đối với các tác vụ MLE-Bench Lite, Arbor cũng được so sánh với các hệ thống nghiên cứu tác nhân hàng đầu như AI-Scientist, ML-Master và AIDE.
Arbor liên tục vượt trội hơn các hệ thống cơ sở. Nó đạt được kết quả kiểm tra được giữ lại tốt nhất trên tất cả các tác vụ, đạt được mức tăng tương đối trung bình cao hơn 2.5 lần so với Codex và Claude Code. Trên tác vụ BrowseComp, liên quan đến việc tối ưu hóa một tác nhân tìm kiếm, Arbor đã cải thiện độ chính xác được giữ lại của hệ thống từ mức cơ sở là 45.33% lên 67.67%. Trong khi đó, Codex và Claude Code bị đình trệ ở mức 50% và 53.33% tương ứng. Trên MLE-Bench Lite, khi được trang bị GPT-5.5, Arbor đạt được kết quả mạnh nhất trong số tất cả các hệ thống được benchmark.
Arbor đã chứng tỏ khả năng chống lại "quá khớp". Ví dụ, trong các thử nghiệm tác vụ Terminal-Bench 2.0, Claude Code đạt điểm phát triển cao 75 nhưng điểm của nó giảm xuống 71 trên dữ liệu được giữ lại. Arbor có điểm phát triển thấp hơn 72.22 nhưng đạt điểm cao nhất trên dữ liệu được giữ lại là 77.36, đảm bảo kết quả của nó chuyển giao sang các ứng dụng trong thế giới thực.
Arbor cũng cho thấy khả năng tổng quát hóa trong một thử nghiệm chuyển giao xuyên tác vụ. Sau khi Arbor hoàn thành việc tối ưu hóa công cụ tìm kiếm cho tác vụ BrowseComp, các nhà nghiên cứu đã lấy cơ sở mã đã tối ưu hóa và thử nghiệm nó trên hai tác vụ tác nhân tìm kiếm không liên quan, HLE và DeepSearchQA. Cơ sở mã được tối ưu hóa của Arbor cũng đã cải thiện đáng kể hiệu suất trên các tác vụ chưa từng thấy đó.
Triển Khai Arbor: Lợi Ích và Chi Phí Tiềm Ẩn 💰
Đối với các trưởng nhóm kỹ thuật muốn tích hợp Arbor vào hệ thống công nghệ hiện có của họ, framework này được thiết kế để nằm trên các quy trình làm việc Git hiện có chứ không thay thế chúng. "Đầu ra của nó là một nhánh git thông thường mà quy trình đánh giá mã, CI và đánh giá thủ công hiện có của bạn có thể kiểm tra trực tiếp," Jin nói. Chỉ những cải tiến đã được xác minh mới được hợp nhất vào một nhánh chính cho mỗi lần chạy, để kho lưu trữ chính không bị đụng đến cho đến khi một nhà phát triển tự tay chọn thúc đẩy mã.
Tuy nhiên, việc triển khai Arbor đi kèm với những đánh đổi cụ thể. Jin chỉ ra rằng nhược điểm lớn nhất là chi phí token, vì việc duy trì một người điều phối tồn tại lâu dài liên tục quản lý cây và điều phối các người thực thi là chi phí chiếm ưu thế. Chạy nhiều "worktree" biệt lập đồng thời cũng yêu cầu tài nguyên tính toán và đĩa thực sự để xử lý các thử nghiệm thực.
Vậy điểm ngọt của Arbor là ở đâu? Theo Jin, nó vượt trội trong các tác vụ có chỉ số rõ ràng, đáng tin cậy, khả năng chịu đựng một tầm thời gian dài và một không gian tìm kiếm thực tế với một số hướng khả thi, chẳng hạn như tối ưu hóa đường ống, chất lượng tổng hợp dữ liệu và điều chỉnh công thức huấn luyện mô hình.
Ngược lại, các nhóm nên tránh rõ ràng việc sử dụng Arbor cho các tác vụ có độ trễ thời gian thực, các sửa lỗi một dòng rõ ràng, hoặc khi chỉ số đánh giá cơ bản bị lỗi. Trần chất lượng của toàn bộ lần chạy bị giới hạn nghiêm ngặt bởi chất lượng của bộ đánh giá. "Nếu chỉ số không đáng tin cậy, Arbor sẽ chỉ tối ưu hóa nhanh hơn theo một kết quả không đáng tin cậy," Jin nói.
Jin nhìn thấy sự phát triển tiếp theo vượt ra ngoài các chỉ số vô hướng đơn lẻ. "Một sự phát triển tự nhiên là mỗi hiện vật của nút mang một vector – độ chính xác, độ trễ, chi phí – thay vì một điểm số duy nhất," Jin nói. "Chuyển từ một chỉ số vô hướng duy nhất sang tìm kiếm Pareto đa mục tiêu là một phần mở rộng rất tự nhiên của framework."