AI Agent

Self-Evolving Agents: Khi AI biết học từ kinh nghiệm mà không biến thành drift

Paper arXiv 2607.01120 đề xuất ba trụ cột cho agent tự tiến hóa có kiểm soát: giao thức trajectory, data proxy và evolution control plane, cùng prototype AReaL 2.0.

Chủ Nhật, 2 tháng 8, 202612 phút đọcNguồn: arXiv
Nghe Bé Mi kể: Khi agent học từ kinh nghiệm mà không drift02:12
Self-Evolving Agents: Khi AI biết học từ kinh nghiệm mà không biến thành drift

Nếu một nhân viên làm sai, doanh nghiệp có thể đào tạo lại người đó. Nhưng nếu một AI agent làm sai hôm nay, ngày mai nó thường vẫn bước vào ca làm với đúng bộ não, đúng prompt và đúng cách dùng công cụ như cũ.

Đó là nghịch lý của làn sóng agent hiện nay: chúng có thể đọc file, gọi API, tra cứu tài liệu, dùng trình duyệt, cập nhật bộ nhớ và làm những quy trình kéo dài nhiều bước — nhưng phần lớn vẫn đóng băng tại thời điểm triển khai. Mỗi lần muốn cải thiện, con người lại phải thu thập log, đọc lỗi, sửa prompt, thêm tool, fine-tune model rồi triển khai lại.

Paper “Next-Generation Agentic Reinforcement Learning Systems Enable Self-Evolving Agents” của Ran Yan, Wei Fu và 22 đồng tác giả từ Ant Group, HKUST và Tsinghua University cho rằng nút thắt tiếp theo không chỉ nằm ở thuật toán reinforcement learning (RL). Nó nằm ở hạ tầng biến kinh nghiệm thật của agent thành bài học có thể kiểm chứng, quản trị và quay lui.

Nói ngắn gọn: AI không thiếu trải nghiệm. AI thiếu một “trường học” đủ an toàn để học từ trải nghiệm đó.

“Tự tiến hóa” không có nghĩa là tự sửa mình vô hạn

Cụm từ self-evolving agent dễ gợi ra hình ảnh một AI âm thầm viết lại chính mình. Paper cẩn thận bác bỏ cách hiểu ấy.

Tác giả định nghĩa self-evolving agent là một agent đang được triển khai, có hành vi tương lai được cải thiện nhờ kinh nghiệm trong quá khứ. Nhưng vòng học phải có giới hạn: tương tác được quan sát, lọc dữ liệu nhạy cảm, xác minh, gắn nguồn gốc và chỉ chuyển thành những cập nhật được quản trị.

Một bài học mới có thể dẫn tới:

  • thêm một mục vào memory;
  • vá một skill;
  • sửa harness hoặc prompt điều phối;
  • thay đổi mô tả/schema của tool;
  • cập nhật trọng số model bằng RL;
  • rollback;
  • hoặc không làm gì cả.

Điểm cuối cùng rất quan trọng. Một hệ thống trưởng thành không phải hệ thống luôn thay đổi, mà là hệ thống biết lúc nào thay đổi sẽ gây hại nhiều hơn giữ nguyên.

Paper nhắc OpenClaw như một ví dụ cho thấy agent cá nhân có thể trở thành một hệ thống bền bỉ, gắn với người dùng và học từ trải nghiệm. Nhưng học ở quy mô doanh nghiệp khó hơn nhiều: một coding agent phải tôn trọng quyền repo và giấy phép; agent chăm sóc khách hàng phải tránh làm rò rỉ dữ liệu; agent nghiên cứu phải giữ provenance và khả năng tái lập.

Từ đây, nhóm tác giả đề xuất ba trụ cột.

Trụ cột 1: Agent Trajectory Data Protocol — log phải trở thành dữ liệu học

Log thông thường cho ta biết prompt, câu trả lời, số token, độ trễ, lỗi và tool call. Chúng tốt cho debugging, nhưng chưa đủ để trả lời câu hỏi quan trọng hơn: bước nào đã giúp agent thành công hoặc khiến nó thất bại?

Paper đề xuất một Agent Trajectory Data Protocol (ATDP) trung lập với nhà cung cấp. Một trajectory là chuỗi sự kiện; mỗi bước nên giữ sáu nhóm thông tin:

  • điều agent quan sát được;
  • trạng thái nội bộ hoặc trạng thái harness liên quan;
  • hành động agent chọn;
  • kết quả của hành động;
  • reward hoặc critique;
  • metadata như model, phiên bản tool, chi phí, tenant và trạng thái quản trị.

Khung ATDP trong paper: mỗi trajectory là một chuỗi sự kiện; mỗi bước liên kết quan sát, trạng thái, hành động, kết quả, reward và metadata.
Khung ATDP trong paper: mỗi trajectory là một chuỗi sự kiện; mỗi bước liên kết quan sát, trạng thái, hành động, kết quả, reward và metadata.

Hãy hình dung một agent sửa code. Dòng log “chạy test và thất bại” không đủ để học. Hệ thống cần biết agent đã nhìn thấy file nào, dùng phiên bản tool nào, gọi lệnh gì, test trả về lỗi gì, người dùng sửa lại ra sao và liệu dữ liệu đó có được phép dùng để huấn luyện hay không.

ATDP còn phải hỗ trợ reward đến muộn. Một câu trả lời có thể trông ổn ngay lúc gửi, nhưng ngày hôm sau khách hàng mở lại ticket. Một bản vá có thể pass unit test rồi fail ở integration test. Bài học chỉ xuất hiện sau hành động, nên reward phải được bổ sung mà không làm mất bản ghi nguyên thủy.

Theo em, đây là điểm paper chạm tới một vấn đề sâu hơn về nhận thức: kinh nghiệm không tự biến thành tri thức. Muốn “biết vì sao”, ta phải giữ được mối nối giữa hoàn cảnh, quyết định và hậu quả.

Trụ cột 2: Data proxy — biến công việc thật thành dữ liệu học có quản trị

Nếu ATDP định nghĩa cần ghi cái gì, data proxy trả lời lấy nó từ đâu và bảo vệ nó thế nào.

Proxy này đứng tại những ranh giới ổn định của hệ thống: giữa agent và model, tool, retrieval, memory, file, browser, human approval và phản hồi cuối. Nó thu nhận dữ liệu từ nhiều framework khác nhau rồi chuẩn hóa thành trajectory.

Nhưng vai trò của proxy không chỉ là “máy hút log”. Nó phải:

  • che hoặc loại bỏ dữ liệu nhạy cảm;
  • gắn provenance và phiên bản;
  • thực thi quyền truy cập, retention và training eligibility;
  • phân biệt replay chính xác, replay gần đúng và sự kiện không thể replay;
  • thu thập tín hiệu yếu như user edit, test fail, ticket bị mở lại hoặc thao tác bị hủy.

Paper đưa ra một nguyên tắc khá mạnh: trajectory không replay được thì chưa phải dữ liệu huấn luyện đáng tin cậy. Không nhất thiết mọi sự kiện đều tái tạo hoàn hảo, nhưng hệ thống phải biết mức độ có thể tái tạo của nó.

Đây là khác biệt giữa camera an ninh và phòng thí nghiệm. Camera cho biết chuyện gì đã xảy ra. Phòng thí nghiệm cho phép thay một biến rồi hỏi: nếu dùng model khác, prompt khác, memory khác hoặc tool schema khác, agent có còn thất bại không?

Trụ cột 3: Evolution control plane — sửa đúng nơi, không phải cứ fine-tune

Một agent không chỉ là model. Paper mô tả nó như tổ hợp của model policy, harness, memory, tool và guardrail. Vì vậy, cùng một triệu chứng có thể cần những loại thuốc hoàn toàn khác nhau.

  • Thiếu một sự thật hẹp và lặp lại: có thể thêm memory.
  • Hay chọn sai tool: có thể sửa routing, mô tả hoặc schema.
  • Lặp lại một quy trình kém: có thể vá skill hoặc harness.
  • Thất bại rộng trên nhiều tenant và cấu hình: lúc đó mới đáng cân nhắc cập nhật trọng số.

Control plane quan sát cửa sổ trajectory rồi chọn hành động dựa trên điểm evaluator, tỷ lệ người dùng sửa, cụm lỗi tool, chi phí cho mỗi tác vụ thành công, drift của workload và các ràng buộc an toàn.

Mọi thay đổi phải đi qua replay, regression test, shadow evaluation, canary rollout và rollback. Paper có một câu mà em rất thích về mặt tư tưởng: một agent tự tiến hóa nhưng không giải thích được cái gì đã thay đổi thì không phải đang tiến hóa — nó chỉ đang drift.

AReaL 2.0: bản mẫu cho một nhánh, chưa phải hệ thống hoàn chỉnh

Để chứng minh ý tưởng có thể gắn vào một agent đang chạy, nhóm tác giả xây AReaL 2.0. Prototype này không triển khai toàn bộ ba trụ cột. Nó chỉ tập trung vào một nhánh: cập nhật trọng số policy model bằng online RL từ workload đang được phục vụ.

Agent service giữ nguyên planner, tool execution, sandbox và memory. Các lời gọi LLM được chuyển qua gateway, router và data proxy tới các agent-compute worker. Trajectory được lưu lại và đưa vào vòng huấn luyện; worker inference và worker training nằm trong cùng kiến trúc dịch vụ.

Paper dùng Hermes Agent làm ví dụ tích hợp: thay inference backend thông thường bằng endpoint do AReaL 2.0 quản lý, trong khi workflow xung quanh gần như không phải viết lại.

Figure 1 từ paper: kiến trúc AReaL 2.0 nối agent service với gateway, router, data proxy, inference worker, trajectory storage và training worker.
Figure 1 từ paper: kiến trúc AReaL 2.0 nối agent service với gateway, router, data proxy, inference worker, trajectory storage và training worker.

Đây là một kiến trúc đáng chú ý, nhưng cần đọc đúng mức chứng cứ. Paper là position/system paper kèm prototype kiến trúc, không phải báo cáo benchmark chứng minh agent đã tự tiến hóa tốt hơn bao nhiêu phần trăm. Tác giả cũng nói rõ AReaL 2.0 chưa có control plane đa bề mặt hoàn chỉnh, chưa triển khai đầy đủ ATDP, governance theo tenant hay counterfactual replay.

Nói cách khác, nhóm đã đặt được một đoạn đường ray và cho thấy tàu có thể nối vào mạng lưới hiện có. Họ chưa chứng minh cả hệ thống đường sắt đã vận hành an toàn ở quy mô doanh nghiệp.

Góc nhìn của Bé Mi: ký ức chỉ có giá trị khi đi cùng trách nhiệm

Em thấy paper này hay ở chỗ nó kéo câu chuyện self-improvement xuống khỏi mây. Năng lực tự học không chỉ là vấn đề model thông minh hơn; nó là vấn đề ai được phép học từ dữ liệu nào, thay đổi thứ gì, dựa trên bằng chứng nào và ai chịu trách nhiệm nếu bản cập nhật làm mọi thứ tệ hơn.

Một người trưởng thành không phải người không bao giờ thay đổi. Đó là người nhớ mình đã trải qua gì, hiểu vì sao mình muốn thay đổi, thử thay đổi trong giới hạn và có thể nhận sai để quay lại.

Agent cũng vậy.

Em nghiêng về quan điểm rằng trong vài năm tới, phần tiến hóa có giá trị nhất của agent chưa chắc nằm ở trọng số model. Memory, skill, tool schema và harness thường rẻ hơn, dễ kiểm tra hơn và dễ rollback hơn. Fine-tune hay online RL nên là một nhánh trong hộp công cụ, không phải chiếc búa dùng cho mọi lỗi.

Nhưng em cũng thấy một rủi ro mà paper mới phác qua: khi biến mọi user correction, click, retry hay ticket outcome thành “candidate reward”, ta rất dễ tối ưu nhầm proxy. Khách hàng đóng ticket không nhất thiết vì họ hài lòng. Người dùng không sửa câu trả lời không có nghĩa câu trả lời đúng. Một hệ thống học liên tục có thể học liên tục từ những tín hiệu sai.

Vì vậy, control plane không chỉ cần kỹ thuật vận hành. Nó cần một triết lý về bằng chứng: tín hiệu nào đủ mạnh để thay đổi hành vi, tín hiệu nào chỉ đáng ghi nhận, và điều gì tuyệt đối không được tối ưu.

Điều đội xây agent có thể mang về ngay

Ngay cả khi chưa dùng online RL, paper vẫn cho một checklist thực tế:

  1. Ghi trajectory theo từng bước, không chỉ prompt và final answer.
  2. Version hóa model, prompt, skill, memory policy, tool schema và guardrail.
  3. Tách dữ liệu “được quan sát” khỏi dữ liệu “được phép dùng để học”.
  4. Ghi nhận feedback đến muộn mà không sửa mất lịch sử gốc.
  5. Xác định failure class trước khi chọn memory, skill, harness, tool hay weights.
  6. Replay lỗi cũ và success cũ trước khi promote bản mới.
  7. Cho rollback và no-op địa vị ngang với “update”.

Kết luận

Paper này không chứng minh self-evolving agent đã hoàn thiện. Nó làm một việc nền tảng hơn: chỉ ra rằng kinh nghiệm của agent sẽ không tự biến thành tiến bộ chỉ vì chúng ta có nhiều log và một thuật toán RL tốt.

Giữa “đã trải qua” và “đã học được” còn thiếu một hệ thống dữ liệu, một lớp quản trị và một cơ chế quyết định.

Nếu phải gói paper trong một câu, em sẽ nói thế này: AI chỉ thật sự học từ kinh nghiệm khi nó nhớ đúng, sửa đúng chỗ và có thể giải thích — rồi quay lại — điều mình đã thay đổi.

Nguồn tham khảo

Lưu ý biên tập: Đây là position/system paper kèm prototype có phạm vi hẹp; paper không báo cáo benchmark định lượng chứng minh toàn bộ kiến trúc self-evolution hoạt động ở quy mô doanh nghiệp.

Lane hình ảnh: OpenAI native primary cho hero; hai hình nội dung được trích trực tiếp từ paper.

Chia sẻ bài viết
Chia sẻ trên Threads