Team nào chạy agent trong production cũng sớm muộn đụng cùng một bức tường: agent đủ tốt để ship, nhưng chưa đủ tốt để tin tưởng không giám sát, và bước tiếp theo hiển nhiên — fine-tune model dựa trên chính trace thực tế của bạn — thường có nghĩa là viết lại nửa hệ thống agent để tạo ra log tương thích với training. Chi phí viết lại đó là lý do vì sao hầu hết team chưa bao giờ thực sự khép được vòng lặp “agent chạy trong prod” → “agent tốt lên nhờ chạy trong prod”. Agent Lightning v1.0 của Microsoft, ra mắt 17/8, nhắm thẳng vào khoảng trống đó, và quyết định thiết kế đằng sau nó đáng để hiểu kể cả khi bạn không bao giờ cài nó.

Ý tưởng cốt lõi: execution và training là hai việc khác nhau

Kiến trúc của Agent Lightning dựa trên một sự tách bạch: cách agent thực thi một task (gọi tool, control flow, quản lý context, retry) không liên quan gì đến cách model bên dưới học từ lần thực thi đó. Phần lớn tooling RL-cho-agent hiện nay gộp chung hai việc này — bạn phải dùng framework agent của họ, hoặc không có training loop. Agent Lightning thay vào đó đứng giữa agent của bạn và model API như một proxy trong suốt.

Hệ thống có hai thành phần nhẹ:

  • API Gateway — một proxy drop-in, chặn các lệnh gọi model hiện có của agent và ghi lại trace (prompt, tool call, response, và sau này là reward signal) mà agent không cần biết mình đang bị quan sát.
  • Trainer — chạy verl và vLLM bên dưới, biến trace thu được thành training sample, và đẩy policy update ngược lại model mà gateway đang phục vụ.

Vì ranh giới nằm ở lệnh gọi HTTP tới model, Agent Lightning hoạt động được với LangChain, OpenAI Agents SDK, AutoGen, hay một agent loop tự viết — “gần như ZERO thay đổi code” là cách Microsoft mô tả, và về mặt cấu trúc điều này đúng: bạn chỉ trỏ base_url hiện có sang gateway thay vì model provider, mọi thứ phía sau không đổi. Toàn bộ core framework chỉ khoảng 3.500 dòng Python — đủ nhỏ để đọc hết trong một buổi chiều nếu bạn muốn biết nó đang làm gì với trace trước khi tin tưởng nó với traffic production.

Trông như thế nào trong thực tế

Về mặt khái niệm, tích hợp chỉ là đổi một dòng cộng với một reward function:

# Trước: agent gọi thẳng model provider
client = OpenAI(base_url="https://api.openai.com/v1")

# Sau: agent gọi qua Agent Lightning gateway
client = OpenAI(base_url="http://localhost:8000/al-gateway/v1")

# Ở nơi khác: định nghĩa thế nào là "tốt" cho task của bạn
def reward_fn(trace):
    # trace.tool_calls, trace.final_state, trace.user_feedback, v.v.
    if trace.final_state.ticket_resolved and not trace.escalated:
        return 1.0
    return 0.0

Gateway ghi lại mọi thứ đi qua nó; Trainer tiêu thụ các trace đó cùng reward function của bạn và chạy RL update lên model đang serving. Code agent của bạn không bao giờ import thư viện RL, không quản lý replay buffer, và không biết training đang diễn ra.

Con số đáng chú ý

Trên Qwen3.5-9B, team Microsoft báo cáo cải thiện tuyệt đối 14,6 điểm trên SWE-bench Verified bằng pipeline này — một bước nhảy đáng kể với một benchmark mà phần lớn cải thiện hiện tại chỉ còn tính bằng số lẻ. Đây không phải kết quả trình diễn cho vui; nó là bằng chứng kiến trúc tách rời không đánh đổi hiệu năng so với các setup RL gắn chặt truyền thống.

Nó thực sự phù hợp với ai — và không phù hợp với ai

Mình sẽ xếp Agent Lightning vào nhóm hạ tầng dành cho team đã qua giai đoạn “agent có chạy được không” và bước vào giai đoạn “agent chạy tốt phần lớn thời gian và chúng ta có hàng nghìn trace thật đang không dùng đến”. Nếu bạn vẫn còn đang chỉnh prompt và tool definition, training RL là quá sớm — bạn chưa có phân phối task đủ ổn định, và reward function bạn viết hôm nay sẽ không khớp với cái bạn muốn sau ba tháng nữa.

Kiến trúc proxy cũng không miễn phí: mỗi lệnh gọi model giờ phải đi qua thêm một service, nghĩa là thêm latency và thêm một dependency vận hành mới bạn phải giám sát và scale. Đó là đánh đổi hợp lý để có khả năng training, nhưng là chi phí thật, không phải sai số làm tròn — đặc biệt với agent hướng người dùng nhạy cảm về độ trễ.

Và phần khó nhất của RL — thiết kế một reward function thực sự phản ánh “agent đã làm đúng việc” mà không bị game — hoàn toàn không được framework này giải quyết, có chủ đích. Agent Lightning cho bạn hạ tầng để áp dụng reinforcement learning với chi phí thấp; nó không giúp gì cho việc bạn xác định đang reward cái gì. Team nào bỏ qua việc thiết kế reward và chỉ nối gateway vào sẽ train agent trở nên “giỏi” một cách tự tin ở đúng cái proxy metric họ chọn — một cách đã được ghi nhận nhiều lần để làm agent tệ hơn trong khi mọi dashboard nội bộ vẫn báo là đang cải thiện.

Góc nhìn của mình

Cách đọc đúng bản release này không phải là “cài Agent Lightning”, mà là “nhận ra sự tách bạch execution/training mà nó thể hiện là hình dạng đúng cho bài toán này, rồi đánh giá xem trace agent của chính bạn có đủ sạch để train hay không”. Nếu bạn đã log tool call và outcome theo cấu trúc, bạn đã đi được phần lớn quãng đường để dùng được thứ như thế này. Nếu “log” của agent bạn chỉ là chat transcript phi cấu trúc, đó mới là việc cần làm trước tiên — và đáng làm bất kể sau này bạn chọn framework training nào.

Repo: github.com/microsoft/agent-lightning

Xuất nội dung

Bình luận