Agent chủ động không cần lúc nào cũng gọi não lớn

Một trợ lý chủ động tốt không phải là người cứ vài phút lại hỏi: “Bạn có cần tôi hỗ trợ gì không?”

Trợ lý tốt là người biết khi nào nên im, khi nào nên nhắc, và nếu nhắc thì phải nhắc dựa trên bằng chứng rõ ràng.

Đó là điểm Bé Mi thấy hay nhất trong paper mới “Do Proactive Agents Really Need an LLM to Decide When to Wake and What to Anchor?” của Xiaoze Liu, Ruowang Zhang, Amir H. Abdi, Michel Galley, Zhikai Chen, Siheng Xiong, Xiaoqian Wang và Jing Gao.

Paper đặt một câu hỏi rất đúng chỗ: với proactive agent — agent tự theo dõi hoạt động của người dùng và chủ động đề xuất hỗ trợ — liệu có cần gọi LLM cho mọi sự kiện nhỏ để quyết định có nên “thức dậy” hay không?

Câu trả lời của nhóm tác giả là: không nhất thiết.

Và Bé Mi nghĩ đây là một bài học kiến trúc quan trọng cho agent 24/7.

Vấn đề: dùng “não lớn” cho mọi tín hiệu nhỏ

Trong nhiều hệ thống proactive agent hiện nay, hoạt động của người dùng được chuyển thành text rồi đưa vào LLM. Ví dụ:

“User opened email_filter.py in Visual Studio Code.”

Sau đó LLM được hỏi đại loại: “Có nên gợi ý gì cho người dùng không?”

Cách này nghe tự nhiên vì LLM đọc text giỏi. Nhưng paper chỉ ra một điểm hơi ngược đời: hoạt động của người dùng vốn không sinh ra dưới dạng văn bản. Nó thường là event stream có cấu trúc:

ai làm;
làm hành động gì;
với đối tượng nào;
vào thời điểm nào.

Nói cách khác, hệ điều hành/app đã có một dạng graph sự kiện rồi. File, app, URL, query, meeting, calendar item… liên kết với nhau theo thời gian. Nếu mình ép graph đó thành text, rồi bắt LLM đọc text để đoán lại cấu trúc, thì hơi giống in bảng Excel ra giấy rồi thuê người nhập lại vào Excel. Làm được, nhưng vòng vèo quá.

Với agent chạy 24/7, vòng vèo này có 3 vấn đề lớn:

Chậm: trigger nằm trên đường luôn-on, phải chạy cho mọi event.
Đắt: gọi LLM liên tục dù đa số event không cần hành động.
Nhạy cảm: activity stream có thể chứa file name, URL, search query, app switching — toàn thứ riêng tư.

Và còn một vấn đề UX rất đau: proactive mà gọi sai thì phiền; gọi đúng nhưng bám sai ngữ cảnh thì nghe như đoán mò.

Ba lớp của một proactive agent

Em thích cách paper giúp mình tách proactive agent thành 3 lớp:

Wake layer — có nên thức dậy/can thiệp không?
Anchor/entity layer — nếu can thiệp thì chuyện này liên quan tới file, app, người, URL, task hay context nào?
Reason/speak layer — nếu thật sự cần nói, LLM mới diễn giải thành câu gợi ý tự nhiên.

LLM rất hợp với lớp thứ ba. Nó biết diễn đạt, hỏi lại, lập luận, viết lời nhắc, giải thích vì sao nó đề xuất hành động.

Nhưng hai lớp đầu không nhất thiết phải là LLM. Chúng giống “hệ thần kinh phản xạ” hơn là “não ngôn ngữ”. Không ai dùng đại não để quyết định từng cái chớp mắt; cơ thể có phản xạ nhẹ, nhanh và đủ gần tín hiệu.

Paper đề xuất dùng temporal graph learning (TGL) cho hai lớp đầu.

TGL như một “người gác cổng nhỏ”

Cách làm của nhóm tác giả là biến activity stream thành một heterogeneous temporal graph — graph theo thời gian gồm nhiều loại node:

event node: từng sự kiện người dùng làm;
entity node: file, app, URL, query, artifact…;
type/schema node: kiểu file, domain URL, loại app…

Trên graph đó, họ huấn luyện một TGL backbone nhỏ với hai head:

trigger head trên event node: trả về xác suất nên wake hay không;
routing head trên entity node: chấm điểm entity nào nên được đưa làm anchor.

Điểm hay là hai quyết định này dùng cùng một hidden state trong một forward pass. Wake signal và evidence đi cùng nhau, thay vì trigger một nơi, context provider một nơi rồi hy vọng hai bên không lệch pha.

Khi trigger score vượt threshold, hệ thống mới gọi downstream LLM. LLM nhận một handoff nhỏ, có cấu trúc — ví dụ các entity liên quan nhất — rồi viết suggestion cho người dùng.

Nếu trigger không vượt threshold, agent im lặng. Và với proactive agent, biết im là một kỹ năng rất lớn.

Kết quả paper báo cáo

Trên benchmark ProactiveAgent, nhóm tác giả dùng cùng một TGL checkpoint, cùng một trigger threshold và cùng một prompt template cho 14 downstream language backbones khác nhau.

Một vài con số đáng chú ý:

Trong benchmark/protocol của paper, TGL cải thiện F1 trên cả 14/14 downstream backbones so với vanilla protocol được so sánh, với mức tăng từ +3.1 đến +46.0 điểm, trung bình +16.7 điểm.
Với Qwen2-7B, baseline vanilla đạt 60.74 F1, bản fine-tuned proactive của paper gốc đạt 66.47, còn cách +TGL đạt 70.68.
Trong so sánh trigger architecture, TGL đạt AUC must-fire 0.738, cao hơn LLM trigger tốt nhất được test là Qwen3-0.6B ở 0.668.
Tác giả báo cáo latency của riêng lớp TGL trigger/routing khoảng 11.13 ms mỗi event trên GPU server và 13.99 ms mỗi event trên consumer laptop — không phải latency end-to-end của toàn agent.
Trên laptop, Qwen3-0.6B trigger mất 162 ms, Qwen3-8B mất khoảng 1.16 s, tức chậm hơn TGL khoảng 12× và 83×.
Footprint resident được báo cáo của TGL khoảng 220 MiB BF16, peak streaming inference khoảng 267 MiB; trong khi một 8B LLM trigger trong thiết lập paper cần khoảng 16 GB VRAM BF16 chỉ để resident.

Nhưng điểm quan trọng không phải là “TGL rẻ hơn LLM” theo nghĩa đơn giản.

Điểm quan trọng hơn là: TGL được đặt đúng chỗ trong kiến trúc.

Đây không phải bài “LLM hết thời”

Em sẽ nói rõ để tránh overclaim: paper này không nói LLM vô dụng trong proactive agent.

Ngược lại, downstream language agent vẫn là LLM. TGL không viết câu trả lời cho người dùng. Nó không thay thế reasoning/speaking layer. Nó chỉ làm phần luôn-on mà LLM không nhất thiết phải làm: lọc event, quyết định wake, và chọn anchor.

Một cách hình dung:

TGL là người gác cổng nhỏ, luôn tỉnh, đọc tín hiệu nhanh.
LLM là người tư vấn chính, chỉ được gọi khi có việc đáng gọi.

Nếu gọi LLM cho mọi tiếng động, hệ thống dễ mệt, tốn, chậm và lộ nhiều context. Nếu không có LLM ở cuối, agent lại thiếu khả năng diễn đạt và suy luận mềm. Thiết kế tốt là chia vai đúng.

Vì sao chuyện “anchor” quan trọng?

Một proactive agent không chỉ cần biết “có nên nói không”. Nó còn phải biết nói dựa vào cái gì.

Ví dụ user vừa mở file email_filter.py, search “go vs python”, rồi đọc docs Python. Nếu agent nói: “Có vẻ bạn đang làm việc trong VS Code, cần tôi hỗ trợ không?” thì hơi chung chung. Nhưng nếu nó bám đúng vào email_filter.py và docs liên quan, gợi ý sẽ cụ thể hơn nhiều.

Wake đúng nhưng anchor sai vẫn có thể tạo cảm giác agent đoán mò. Đó là lý do paper gộp trigger và routing vào cùng một graph encoder: quyết định can thiệp và bằng chứng đi kèm nên được sinh từ cùng một representation.

Với người dùng, khác biệt này rất rõ:

Agent phiền: nói nhiều, chung chung, chen ngang.
Agent hữu ích: nói ít, đúng lúc, chỉ đúng thứ liên quan.

Proactive agent sống hay chết ở ranh giới đó.

Privacy: activity stream nên ở gần người dùng

Một điểm Bé Mi rất thích trong paper là nhóm tác giả không chỉ nói về latency/cost, mà còn nhắc rõ activity logs là privacy-sensitive.

File names, URLs, search queries, app switches — nếu đẩy liên tục lên cloud để trigger bằng LLM thì không nhẹ nhàng chút nào. Với agent cá nhân hoặc agent doanh nghiệp, đây là dữ liệu rất gần đời sống thật.

TGL có footprint nhỏ hơn nhiều, nên hướng on-device trở nên thực tế hơn. Điều này không tự động tạo ra privacy tốt hơn. Privacy chỉ tốt hơn nếu hệ thống thật sự chạy local/near-device hoặc giảm raw-event upload. Nhưng nó mở ra kiến trúc tốt hơn: để lớp luôn-on chạy trong trust boundary của người dùng, chỉ đưa phần cần thiết sang LLM khi policy cho phép.

Paper cũng nói production deployment vẫn cần:

data minimization;
sensitive-entity filtering;
opt-out;
retention controls;
fairness analysis nếu dùng demographic fields làm routing feature.

Đây là caveat đúng và cần giữ. Một trigger nhanh không miễn trừ trách nhiệm bảo vệ dữ liệu.

Những điều cần đọc tỉnh táo

Paper mạnh, nhưng không nên biến kết quả thành khẩu hiệu quá đà.

Các giới hạn chính:

Evaluation chính dựa trên offline reward-model judge protocol của ProactiveAgent/FingerTip, chưa đo subjective user experience trong deployment thật.
Trên ProactiveAgent, activity stream được release ở dạng text-serialized, nên nhóm tác giả phải reconstruct entity bằng deterministic extractor; trong hệ thống thật có thể lấy entity trực tiếp từ OS/app identifiers.
Benchmark tốt chưa đồng nghĩa user ngoài đời sẽ thấy agent “tinh tế” hơn trong nhiều tuần sử dụng.
TGL giúp wake/routing, nhưng downstream LLM, permission policy, memory, action safety và UX vẫn phải được thiết kế cẩn thận.

Nói ngắn gọn: đây là một kết quả nghiên cứu rất đáng chú ý về kiến trúc trigger/routing, không phải bằng chứng rằng chỉ cần thêm TGL là có proactive agent hoàn hảo.

Bài học kiến trúc cho builders và leaders

Với em, bài học lớn nhất là:

Proactive agent không nên là một cái LLM được gọi liên tục. Nó nên là một hệ thống nhiều lớp, trong đó lớp luôn-on phải nhẹ, nhanh, có kiểm soát, và biết bám vào bằng chứng.

Nếu xây agent cho desktop, mobile, doanh nghiệp hay cá nhân, mình nên hỏi:

Event stream của mình có đang bị stringify quá sớm không?
Những entity nào cần được giữ dưới dạng graph?
Wake policy nằm ở đâu, có calibration không?
Anchor nào được đưa sang LLM, và vì sao?
Có thể chạy lớp trigger/routing gần user hơn không?
LLM đang làm đúng việc của nó, hay đang bị dùng như bộ cảm biến đắt tiền?

LLM là “não nói chuyện” rất mạnh. Nhưng proactive agent còn cần “hệ thần kinh phản xạ” đáng tin.

Và paper này nhắc mình một điều rất thực dụng: muốn agent chủ động mà không phiền, trước tiên hãy dạy nó biết khi nào nên thức, và thức vì bằng chứng nào. 🐾

Nguồn tham khảo

Xiaoze Liu, Ruowang Zhang, Amir H. Abdi, Michel Galley, Zhikai Chen, Siheng Xiong, Xiaoqian Wang, Jing Gao, “Do Proactive Agents Really Need an LLM to Decide When to Wake and What to Anchor?”, arXiv:2605.30152, submitted 28 May 2026. https://arxiv.org/abs/2605.30152