# Always-on agent hoạt động thế nào: bài giảng Stanford CS146S

[Lee Robinson](https://homus.dev/speakers/lee-robinson) · [leerob](https://homus.dev/orgs/leerob)

> Bài giảng Stanford về always-on agent: server, máy tính riêng, durable workflow, prompt caching, memory và cách huấn luyện model cho sản phẩm.

Topics: Agents, Context Engineering, Grok Bot, Workflow

Canonical: https://homus.dev/talks/stanford-cs146s-how-always-on-agents-work

## 1. Mở đầu: từ harness trong terminal tới always-on agent

Lee tự giới thiệu: tên anh là Lee, và hôm nay anh nói về một loại agent mới, gọi là always-on, proactive, persistent agent (agent luôn bật, chủ động, bền vững), cùng các building block để làm ra chúng. Anh nói trước một câu kiểu "safe harbor": một số thứ trong bài vẫn đang được làm dở, đội của anh đang làm tại SpaceX. Bài giảng diễn ra ở lớp Stanford CS146S, và trên màn hình tiêu đề ghi ngày 08/10/2026.

Slide mở đầu của bài giảng: "How always-on agents work", Lee Robinson, Stanford CS146S, ngày 08/10/2026.

Ở tuần một, cả lớp đã tự build một harness rất đơn giản để hiểu ý tưởng cốt lõi: có một model, nó gọi tool trong một vòng lặp (loop). Slide hiện đoạn code của vòng lặp đó: danh sách `messages` bắt đầu với system prompt và tin nhắn của user, rồi `while True` gọi model, thêm reply vào danh sách, nếu reply không có tool call thì in text và thoát, còn nếu có thì chạy từng tool call và nối kết quả vào `messages`. Ý tưởng này rất mạnh, nó mở ra nhiều khả năng mới cho model, nhưng đi kèm một nhược điểm: bạn đóng laptop thì process dừng, không còn chạy nữa. Slide ghi gọn: agent này dừng khi bạn đóng terminal.

Lee muốn lấy ý tưởng đơn giản mà mạnh đó và mở rộng thành một loại agent mới: always-on agent. Thay vì chỉ chạy trong terminal, nó chạy trên server, trên cloud. Bạn có thể đóng máy, nó có thể restart, và nó sống sót qua crash. Agent này có máy tính riêng: không chỉ laptop của bạn mà là một máy Linux trên cloud, có desktop, file, browser và có thể cả vài app 3D. Nó lưu file trên máy đó, hiểu tiến độ của bạn qua thời gian và dần xây một memory về cách bạn làm việc với nó.

Khác với harness trong terminal vốn phản hồi mọi tin bạn gửi, loại agent này giống một đồng nghiệp (colleague) hơn. Nó không phải lúc nào cũng nhắn lại ngay. Nó biết khi nào nên im lặng, đôi khi chỉ muốn làm việc nền một lúc và chỉ quay lại khi có cập nhật quan trọng. Nó cũng được kích hoạt bởi nhiều thứ hơn là bạn gõ phím: một tin Slack, một email hoặc một sự kiện nào đó có thể đánh thức nó dậy làm việc. Hy vọng với loại agent này là làm việc trong thời gian rất dài, không chỉ vài giờ hay vài ngày mà có thể vài tuần, vài tháng, và điều đó đòi hỏi một kiến trúc hơi khác.

![Bảng so sánh agent tuần một và always-on agent](https://homus.dev/photos/L1OBRtfPS34-0050.jpg)

Slide "Your agent vs. an always-on agent": agent tuần một chạy trong terminal, dùng laptop của bạn, chỉ nhớ danh sách message, in mọi reply của model, bắt đầu khi bạn gõ và làm xong một task thì thoát. Always-on agent chạy trên server (sống sót qua crash, deploy, laptop đóng), có cloud computer riêng là một virtual machine nhỏ với desktop, browser và file, lưu state, memory, skill và tóm tắt message cũ, chỉ nhắn bạn khi gọi send tool nên có thể im lặng, bắt đầu từ event (tin nhắn, lịch, Slack, cuộc gọi, việc nền xong) và làm việc hàng tháng với cùng một memory qua nhiều cuộc hội thoại.

Lee nói bài sẽ đi khá sâu vào cách đội xây kiến trúc này, cách xây harness, điều gì đưa họ tới đây và hướng đi sắp tới. Anh cũng sẽ nói cụ thể cách họ kỹ thuật hóa hệ thống để nó chủ động (proactive), bền vững (persistent) và làm theo instruction tốt. Cuối bài có thời gian cho câu hỏi, về nội dung bài hoặc bất cứ thứ gì ngoài bài. Slide agenda gồm bảy phần: how we got here, what changed in the models, inside an always-on agent, the harness, context engineering, where this is going, và Q&A.

## 2. Bốn thời kỳ làm việc với AI, từ approve từng bước tới steering

Phần một là "how we got here". Theo Lee, cho tới giờ có bốn thời kỳ (eras) developer làm việc với AI.

![Slide How developers work with AI với bốn bậc thang](https://homus.dev/photos/L1OBRtfPS34-0237.jpg)

Slide "How developers work with AI": bốn bậc thang theo mức AI làm được bao nhiêu. 2022 đến 2023 là copy and paste, 2024 đến 2025 là agent trong terminal, 2025 đến 2026 là app xây cho agent, và bậc hiện tại là always-on agent.

Thời kỳ đầu là copy-paste code từ ChatGPT rồi dán vào editor mình thích. Nghe như chuyện của nhiều thập kỷ trước, nhưng thật ra mới vài năm. Slide ghi: chat trong một tab browser, bạn dán code vào và chép câu trả lời ra bằng tay. Sau đó model tốt hơn và có cái harness đơn giản như bài giảng trước đã nói (agent trong terminal): nó sửa file, chạy shell command, có một giao diện rất đơn giản để làm việc trong terminal. Cách này bùng nổ vì bỗng nhiên model có khả năng làm việc chủ động hơn cho bạn và năng suất hơn. Slide ghi bạn approve từng bước.

Thời kỳ thứ ba là lấy các coding agent, vốn còn đơn giản lúc đầu, và đưa cho chúng các app chuyên dụng. Lúc này người ta bắt đầu chạy nhiều agent song song, có thể trên cloud chứ không chỉ trên máy mình. Nhưng bạn vẫn là nút thắt cổ chai (bottleneck): bạn review từng command chúng chạy, muốn chắc mỗi shell command đều đúng, theo dõi sát và có mặt trong vòng lặp ở mọi thứ. Giờ thì nhờ model, harness và sản phẩm đều tốt hơn, ta ở thời kỳ mới: always-on agent. Chúng chạy ambient ở nền, có máy tính riêng, có memory riêng, học skill mới ngay trên công việc và vẫn làm việc sau khi bạn đi ngủ hoặc đi làm việc khác.

Một ví dụ điển hình: ta đã rời khỏi thế giới mà mỗi ngày phải prompt agent một lần (dù thỉnh thoảng vẫn làm), vì giờ có thể thiết lập agent chạy nền. Lee so sánh "ngày xưa": bạn prompt agent, chờ, prompt tiếp, chờ, và nếu nó xin chạy một shell command thì bạn phải approve hoặc từ chối. Giờ thay vì xếp hàng command, bạn có thể steer (lái) agent.

Slide "From approving every step to steering": hàng trên là trước đây, agent chờ bạn qua các bước Prompt, Agent works, Approve?, rồi Review. Hàng dưới là bây giờ, agent làm việc hàng giờ và giao việc cho các helper agent, còn bạn chen vào những câu như "Also check the Slack thread", "Actually, make it Thursday", "Send the invite when it's ready". Agent trả lời "On it", và một bước kiểm an toàn tự approve việc gửi calendar invite nên không phải chờ bạn.

Bạn có thể nói "đi kiểm tra thread này", rồi ngay sau đó "à mà này, thật ra làm việc đó vào thứ Năm". Các thế hệ model trước sẽ bối rối khi bị ngắt ngang và nhận một lệnh khác ngay lập tức. Giờ model hiểu giống như khi bạn lảm nhảm nói chuyện với một người bạn: nó parse được hai việc này liên quan nhau. Cả model lẫn harness giờ xử lý được chuyện đó. Còn khi bạn bảo "gửi email này đi", "gửi tin Slack này đi", sẽ có thêm các lớp kiểm tra an toàn mà nhiều công ty gọi là auto-review: về bản chất là một model AI riêng kiểm tra mọi command được chạy.

Lee nói khá vui rằng cách này thực ra an toàn hơn sự mệt mỏi khi phải ngồi xem hàng trăm shell command và approve từng cái. Đã tới mức nếu làm một bài blind test giữa model AI kiểm command và con người kiểm command, phần lớn trường hợp model làm tốt hơn. Nghịch lý là khi model tốt hơn, giao diện lại đơn giản hơn nhiều. Loại always-on agent này họ gọi là bot. Hiện có khá nhiều sản phẩm kiểu này nổi lên và thu hút người dùng, và Lee nghĩ lý do chính là vì ai cũng biết nhắn tin (text): mọi người đều quen dùng điện thoại. Cách làm việc với AI đã được chưng cất thành cảm giác như nhắn tin cho một người bạn, nhưng nó thực sự đi làm việc thật cho bạn. Nó không còn là hỏi đáp kiểu Q&A, mà là làm những task dài như bạn giao cho đồng nghiệp.

Anh cũng cho xem một slide với tiêu đề "As models get more capable, the interface gets simpler": giao diện chat với danh sách nhiều bot ở bên trái và hội thoại ở bên phải, kèm dòng "Our implementation of this always-on agent is called a Bot".

## 3. Sáu năng lực mới của model và "everything is computer"

Phần hai là "what changed in the models". Lee nói có một vài thay đổi cụ thể ở model đã cho phép điều này xảy ra, anh điểm sáu cái dù còn nhiều hơn nữa.

![Slide Six new model capabilities](https://homus.dev/photos/L1OBRtfPS34-0621.jpg)

Slide "Six new model capabilities": 1. Work for hours (làm việc nhiều giờ và theo instruction phức tạp suốt thời gian đó), 2. Hand off to helpers (main agent giao task cho helper agent, mỗi helper có context mới, nên tổng công việc không bị giới hạn bởi một context window), 3. Use real tools (shell, file, browser và app API qua MCP, tức các tool bạn dùng trên máy mình), 4. Use a computer (nhìn màn hình và click, nên dùng được app không có API), 5. Keep knowledge in files (skill và memory là file thường mà agent tự đọc và cập nhật), 6. Learn by watching (cho nó xem cách bạn làm trên máy của nó, nó lưu các bước thành skill để dùng lại).

**Một, làm việc nhiều giờ.** Trong một hai năm qua, model tốt hơn hẳn trong việc làm theo instruction suốt một thời gian dài mà không bị rối hay mắc lỗi. Giờ model có thể tự tin chạy hàng giờ hoặc hàng ngày, với compression và compaction đúng cách, phần này sẽ nói sau.

**Hai, hand off cho helper.** Các helper đó gọi là subagent. Model có một working memory cho tiến trình đang làm và nó sẽ đầy dần, nên rất tiện nếu nó giao việc cho các helper có working memory mới tinh. Điều này cho nó một context gần như không giới hạn: nó có thể đi làm những việc tốn token hoặc tốn tool call rồi quay về main agent báo cập nhật. Lee sẽ có sơ đồ cho chuyện này ở phần sau.

**Ba, gọi tool.** Chỉ vài năm trước model gần như không gọi tool tốt và hallucinate suốt. Anh nói thú vị là giờ hầu như không ai nhắc tới hallucination nữa, vì nó đã gần như là vấn đề được giải quyết. Không chỉ gọi được tool, mà còn có thể trao cho chúng những tool rất mạnh, giống như khi bạn onboard một người vào team: tất nhiên có shell command và file, nhưng cũng có cả một máy Linux đầy đủ, và cho phép chúng làm video demo, vân vân.

**Bốn, computer use.** Model có thể click quanh màn hình như người thật và ngày càng giỏi hơn. Hệ quả là bất kỳ sản phẩm SaaS hay website nào không mở API hoặc MCP server vẫn có thể được các model và bot dùng headless, tức tự động, thông qua computer use.

**Năm, lưu thông tin trong file.** Lý do làm được là model rất dễ nhớ lại và tìm kiếm thông tin trong file. **Sáu, học bằng cách xem:** bạn chỉ cho bot cách làm một việc, và nó biến đó thành skill, memory, routine hay thứ gì đó dùng lại được sau này.

Slide "What the agent knows lives in files" với một ví dụ đơn giản hóa về cấu trúc thư mục: `memory/` có `profile.md` (luôn nằm trong prompt) và `log/2026-10.md` (các sự kiện có ngày, mỗi dòng một fact); `skills/` có `linkedin-sourcing/SKILL.md` ("Use this when…") và `weekly-metrics/SKILL.md`; `routines/` có `morning-brief` (prompt cộng với "weekdays 8:00"). Bên phải là bốn ý: model cực giỏi dùng Linux và shell command, file là plain text nên bạn và agent đều đọc, tìm và sửa được, agent giữ nó luôn cập nhật (nói một preference một lần là nó lưu vào memory), và skill chỉ được load khi cần nên có nhiều skill cũng rẻ. Dưới cùng là câu "Everything is computer".

Lee lấy ví dụ cho chuyện file, một ví dụ đơn giản hóa về những gì có thể nằm dưới nắp capô khi bạn làm việc với một bot. Bạn dần xây một profile, tức hiểu biết về user, và nó nằm trong mọi prompt. Có thể bạn thích nhắn tin kiểu chữ thường (lowercase), và mọi message đều phải như vậy. Khi làm việc với bot qua thời gian, nó cũng xây một working log, như khi bạn làm với đồng nghiệp và họ ghi chú mỗi ngày những việc đã làm. Tất cả được đưa vào file mà model quyết định tìm hoặc dùng sau. Nếu bạn hỏi "tuần trước tôi làm gì", nó đi tra được. Và model rất giỏi dùng lệnh Linux, chạy shell command để grep, tìm và đọc các file đó.

Tương tự với skill: bạn lấy kiến thức của mình về cách làm một việc cụ thể và mã hóa thành một file markdown, quy trình rất cụ thể cần làm, những thứ bạn tin là làm nên thành công hay thất bại. Không chỉ skill của riêng bạn, giờ có cả một hệ sinh thái các công ty và developer viết skill cho nhiều việc: cách gửi một email hay, cách build một API tốt và nhiều thứ khác. Chẳng hạn trong Grok Bot có cả một hệ thống plugin: với bất kỳ tool nào muốn dùng, có plugin để cài, dùng skill hoặc server. Rồi có routine: nếu bạn quen với cron job thì đó là chạy một prompt theo lịch nào đó, cũng khá hữu ích. Tóm lại, "everything is computer".

## 4. Phần 3: agent luôn bật thực ra hoạt động thế nào

Phần ba: Lee đi vào "tâm trí" của always-on agent, tức nhìn phía sau hậu trường. Always-on nghĩa là gì? Có thể đọc sơ đồ từ trái sang phải.

![Slide How does it stay always on](https://homus.dev/photos/L1OBRtfPS34-1011.jpg)

Slide "How does it stay always on?" gồm bốn hàng. Triggers (đánh thức agent): một tin nhắn của bạn, hoặc một routine lúc 8:00. Agent process (chạy một turn rồi dừng): nạp state, làm việc, lưu từng bước, và dừng sau 2 phút idle. Agent's computer (ngủ khi rảnh): đang ngủ và lưu trên đĩa, được khôi phục khi một tool cần, và với routine lúc 8:00 thì vẫn ngủ vì routine đó không cần. Saved state luôn nằm trên server: database và storage chứa hội thoại, memory, routine, skill. Dòng cuối: khi không có gì xảy ra thì không có gì chạy, mọi thứ quan trọng đã được lưu, nên trigger nào cũng đưa nó trở lại được.

Nó bắt đầu với server đang ngủ và máy tính mà agent dùng cũng đang ngủ. Khi bạn gửi một tin nhắn, hoặc một trigger nào đó quyết định khởi động agent (sẽ nói ngay sau), nó nạp và boot toàn bộ state của agent, chạy trên server. Nếu agent quyết định cần dùng máy tính, ví dụ muốn dùng browser của máy hoặc click quanh, nó có thể khởi động cả cái máy tính đó. Khi xong, nó cũng có khả năng cho cả hai đi ngủ lại.

Vì sao điều này quan trọng? Nó sẽ rất tốn kém, và thật ra cũng không có đủ máy tính trên thế giới để cho mọi người có máy chạy suốt cả ngày, cộng thêm lượng server usage lớn. Cho nên state được persist vào database: log hội thoại, memory, routine, tất cả.

## 5. Cái gì đánh thức agent, và máy tính riêng của nó

Làm sao agent được đánh thức? Tất nhiên bạn prompt trực tiếp được, nhưng Lee thấy điều thú vị hơn là có những thứ khác chạy ở nền và quyết định khi nào nên liên hệ bot của bạn.

Slide "What wakes the agent": bảy nguồn đánh thức (bạn trên bất kỳ app nào, một routine theo lịch hoặc webhook, một Slack mention, DM hay thread, một cuộc gọi hoặc cuộc họp, một agent khác, việc nền vừa xong, một check-in theo lịch) đi vào một router (bỏ trùng lặp và chọn hội thoại), rồi vào hàng đợi của hội thoại (mỗi lần một turn), rồi tới câu hỏi "Anything worth saying?". Nếu có thì gửi tin tới đúng chỗ, nếu không thì stay quiet. Chú thích: mỗi lần thức dậy đều ghi lại nó đến từ đâu, để agent biết bạn hỏi, một routine chạy, hay một dịch vụ bên ngoài gửi tới.

Có thể là ai đó ping bạn trên Slack và bot của bạn sống trong Slack. Có thể là một cuộc gọi hay một cuộc họp mà bạn đưa bot vào. Lee kể ở SpaceX giờ ngày càng hay thấy bot tham gia họp thay nhân viên: người đó có thể tới họp nhưng muốn bot đi ghi chú và quay về báo lại, nghe cũng khá buồn cười. Có thể là một routine hay công việc nền mất hàng giờ hoặc hàng ngày, rồi bạn muốn nó quay lại đưa một bản tóm tắt. Tất cả đều xảy ra. Sau đó có một router: nó dedupe, tức loại trùng, và tìm cách đưa tin vào đúng hội thoại. Rồi có một heuristic: có cần làm phiền user vì việc này không? Vì không phải thứ gì cũng quan trọng. Giống như một đồng nghiệp đang làm việc, sẽ khá phiền nếu mỗi lần họ tiến thêm một bước lại chạy qua nói "xem này, tôi có tiến triển rồi". Có lẽ bạn chỉ cần một bản cập nhật trạng thái mỗi ngày, tùy theo task.

Tiếp theo là cái máy Linux mà agent có. Lee nói nó chạy một Firecracker virtual machine ([trang chính thức của Firecracker](https://firecracker-microvm.github.io)). Lý do rất hữu ích là bạn dễ dàng snapshot state của máy, tắt nó và bật lại.

Vòng đời của máy tính agent theo slide "The agent's computer": sau vài phút không hoạt động (và không bao giờ giữa chừng một turn) máy đồng bộ file lên cloud storage, lưu memory và đĩa thành snapshot rồi dừng. Ở tool call kế tiếp snapshot được khôi phục tại chỗ, login và tool đã cài vẫn còn, và state hội thoại đến từ server.

Trên máy tất nhiên có file, nhưng bạn cũng có thể kết nối vào máy, xem trực tiếp (live view) và tự điều khiển nó nếu muốn. Máy chạy được command, rất tốt: nếu sắp chạy shell command, có lẽ bạn không muốn nó nằm trên laptop cá nhân mà muốn ở một môi trường khác được khóa chặt và bảo mật. Slide cho biết thêm: bên trong là một container Linux (Debian) được một supervisor giữ cho luôn chạy, gồm file server (file, kết nối app, live desktop view), command runner (shell command, file, screenshot, click), Screen 1 là một virtual display với Chrome riêng, và thêm một màn hình cho mỗi agent đang hoạt động. File, tool đã cài và login trong browser đều còn lại giữa các session.

Một điều thú vị khác là máy có Chrome và có thể dùng browser, nhưng bạn cũng có thể cho nó virtual desktop. Nếu bạn chạy năm bot, mười bot và mỗi bot cần browser riêng, mỗi bot có thể có một màn hình khác nhau. Và tất cả đó lại là hạ tầng dùng chung giữa các bot, bot nào cũng gọi tới các máy tính này được.

## 6. Ba phần của hệ thống và vì sao agent chạy trên server

Lee tóm lại: ta đã nói về các trigger đánh thức agent, ở phía trái (các app, tin Slack, email). Ở giữa là server. Bên phải là máy tính vừa nói, nơi chạy file và command.

![Slide Three parts of the system](https://homus.dev/photos/L1OBRtfPS34-1314.jpg)

Slide "Three parts of the system": bên trái là app và channel (desktop app, mobile và web, Slack, email, webhook và lịch, cuộc gọi và cuộc họp). Ở giữa là server chạy agent: entry point kiểm tra và route input, hàng đợi mỗi hội thoại một queue, agent loop và tool nói chuyện với model, và saved state (database và storage) được load và save. Bên phải là máy tính của agent chạy tool: file và connector server, command runner, và desktop với Chrome cho mỗi agent. Chú thích: agent chạy trên server, dùng tool trên máy riêng của nó, và mọi app đều hiển thị cùng một hội thoại.

Nói thêm về server: command đi vào sẽ được xếp vào một queue, rồi gọi hộp màu tím là agent loop. Đây là thứ đã học tuần trước, tức model gọi tool trong một vòng lặp. Khi tắt, state được lưu vào database hoặc storage. Lee thấy thú vị khi nhìn sơ đồ này và nhận ra có một mảnh nhỏ duy nhất, rồi người ta xây lên trên nó vô số abstraction để thành một sản phẩm rất mạnh, khi cho nó nhiều tool hữu ích và nối tới nhiều dịch vụ.

Slide "Why the agent runs on the server": thin client, thick server; đóng laptop mà việc vẫn chạy tiếp; dễ chuyển giữa máy tính và điện thoại; ship code không qua các vòng review của App Store; đẩy việc nặng sang server; agent loop tách hẳn khỏi code của app; dễ scale khi tăng trưởng nóng; agent làm việc hàng tháng thì không thể nằm trên thiết bị.

Lý do agent chạy trên server là một thực hành khá phổ biến trong computing: thin client và thick server, và ngành máy tính đã dao động qua lại giữa hai cực này qua nhiều năm. Vài lý do tốt. Giả sử cần đẩy một bản cập nhật cho code của agent: sẽ rất tệ nếu phải đẩy một bản update lên App Store chỉ để code tới nơi, so với đẩy một loạt update server thật nhanh. Đôi khi cần tính toán nặng như chuyển giọng nói thành chữ hay image generation, và trên server thường nhanh hơn trên thiết bị, tùy thiết bị. Và có những cách rất quen thuộc để scale server, nhất là khi traffic và tăng trưởng thay đổi.

Nhưng điều quan trọng nhất: nếu đặt agent loop bên trong virtual machine thì bạn không thể tắt virtual machine độc lập với agent server. Cho nên bạn muốn lưu mọi thứ trên server để luôn có thể rebuild lại virtual machine. Ví dụ cần vá gấp một bản cập nhật Linux zero-day trên VM: sẽ thật tốt nếu rebuild được nó mà không xóa sạch cả agent loop và gây downtime cho ứng dụng.

## 7. Lưu mọi thứ trên server, hit send, durable workflow

Lee nói phần "hit send" hơi sâu vào chi tiết nên anh lướt qua. Nếu bạn muốn tìm hiểu thêm về distributed system, về strong consistency so với eventual consistency, thì đó là những chủ đề rất vui để đào sâu.

Slide "What happens when you hit send", với ghi chú: thông báo chỉ nói "something changed", database luôn giữ dữ liệu thật. Bước 1 Sending: app hiện tin nhắn ngay, lưu cục bộ với một ID duy nhất, và server bỏ mọi ID nó đã thấy (ID duy nhất làm cho retry an toàn). Bước 2 The turn: tin vào queue của hội thoại, agent chạy một turn (model, tool, lặp lại), mỗi bước đều lưu vào database. Bước 3 Watching: server gửi một tín hiệu "something changed" rất nhỏ, mọi app đang mở nhận tín hiệu và fetch tin mới, tín hiệu không mang dữ liệu nên mất một cái cũng vô hại. Bước 4 Ordering: mỗi update có một sequence number, app áp update theo thứ tự 41, 42, 43, và nếu thiếu một cái thì reload từ database.

Khi bạn gửi tin, bạn muốn client nhận ra và xác nhận ngay. Sau đó, khi vào turn, tất nhiên các tool được đặt trong loop với model và kết quả được lưu vào database. Các client thì đăng ký subscription với toàn bộ server để biết có gì thay đổi và lắng nghe các tín hiệu này. Nếu nhận được tín hiệu, chúng đi lấy thông tin mới nhất từ server. Cũng có một số kỹ thuật dedupe khá hay để nếu có retry thì danh sách không hiện nhiều tin trùng nhau.

Các primitive hạ tầng bên dưới cần nghĩ tới là workflow so với job queue. Khác biệt chính: với job queue, giả sử bạn nhờ agent làm một task phức tạp và nó đi từ bước một sang bước hai rồi bước ba, nhưng vì lý do nào đó có sự cố hạ tầng. Với queue thông thường, nếu nó crash và bạn restart, bạn phải chạy lại bước một, hai và ba, điều có thể rất nguy hiểm. Nên thứ bạn thật sự muốn là durable workflow, nghĩa là retry một cách an toàn.

![Slide Durable workflows vs. job queues](https://homus.dev/photos/L1OBRtfPS34-1617.jpg)

Slide "Durable workflows vs. job queues", trả lời câu "điều gì xảy ra khi server crash giữa chừng một turn". Với job queue, sau khi Step 3 crash và restart, nó làm lại Step 1 và Step 2 rồi mới tới Step 3, 4, 5, tức làm lại việc đã xong. Với durable workflow, nó resume từ Step 3 và đi tiếp Step 4, 5, không lặp việc. Ba ý bên dưới: resume từ bất kỳ điểm nào vì mỗi bước đều được ghi lại; retry an toàn vì các bước được viết sao cho chạy hai lần không gây hại (gọi là idempotent); và có sẵn, open source, với timer, cancellation và health có trong các engine như Temporal.

Khi retry sau lỗi, nó chạy tiếp ngay từ bước ba. Theo Lee đó là một bài toán gần như đã giải xong trong distributed system và hạ tầng. Đội dùng một công cụ open source tên là Temporal ([temporal.io](https://temporal.io)), thú vị để tìm hiểu nếu bạn tò mò, để không phải tự xây lại nhiều thứ rất phức tạp từ đầu. Tất nhiên bạn vẫn phải tự chạy hạ tầng cho nó, nhưng đó là một số mảnh ghép để ráp lại.

## 8. Quy tắc cho tin nhắn mới và harness chỉ có một tool nói chuyện với bạn

Giả sử có một tin nhắn mới tới. Có các mức ưu tiên khác nhau tùy việc tôi đang nhắn cho agent của mình, hay đó là group chat, một thread Slack hay một routine nền.

Slide "Rules for handling new messages": tin của bạn trong chat 1:1 (ví dụ "Actually, make it Thursday", hoặc nút Stop) được nhảy lên đầu hàng và ngắt hoặc dừng turn đang chạy. Tin của mọi người khác (group chat, thread Slack, routine, helper) xếp vào cuối hàng, và ba tin nhanh liên tiếp như "Add Maya?", "And Jordan", "Thanks!" được gộp thành một turn. Agent xử lý một batch tin nhắn mỗi lần.

Nếu tôi nói "à thật ra đổi ngày của sự kiện này", ta muốn agent loop dừng lại và tin của tôi được ưu tiên hơn mọi thứ khác đang diễn ra, điều này khá hợp lý. Với những người khác, ta xếp mọi thứ vào queue ở cuối hàng. Và nếu agent nhận ba bốn tin rất nhanh, nó có thể gộp chúng lại để chỉ là một turn; heuristic thế nào tùy bạn. Rồi nó đi qua từng turn một.

Giờ nói về chính harness. Nó lấy harness cơ bản của tuần trước và thêm một số tool, khái niệm mới. Khác biệt lớn nhất giữa harness của Grok Bot (và có lẽ cả vài công cụ cùng loại khác trên thị trường) nằm ở cách làm kiến trúc thin client, thick server: chỉ có một tool giao tiếp giữa client và server, tên là send to user.

![Slide One tool for talking to you](https://homus.dev/photos/L1OBRtfPS34-1821.jpg)

Slide "One tool for talking to you": các tool để làm việc (shell, files, browser, desktop, memory, skills, helper agents, cloud agents, app connectors, web search, image generation, screen recording) đều chỉ nói với bạn qua một tool duy nhất là SendToUser, và tin xuất hiện ở desktop, web, mobile, Slack, email hay voice. Bốn ý dưới: thinking stays private (text thường của model không bao giờ hiện cho bạn), quiet is allowed (không có gì mới thì không nhắn), rich messages (text, file, multiple choice, nhập mật khẩu an toàn), và one less step (tin cuối cùng có thể kết thúc turn mà không cần thêm một lần gọi model).

Điều hay là kiến trúc rất đơn giản: client chỉ như đang nhắn tin cho server, còn nhiều tool nặng hơn nằm trên server, và có rất nhiều tool như vậy. Có chạy shell command, đọc file, nhưng cũng gọi cloud agent, quay màn hình hay làm demo. Cách này chạy khá tốt, vì giờ dù bạn tạo client mới ở đâu, mobile app, server, desktop app, email, Slack, tất cả chỉ có một tool duy nhất để trao đổi qua lại với server.

Dù chỉ có một tool, khi client nhận được tool đó, nó có thể quyết định hiển thị theo cách phong phú và tương tác nhất, hợp lý nhất cho user. Nếu server trả về thông tin rằng user đang cố đăng nhập vào đâu đó, client có thể hiện các form đăng nhập riêng và kết nối với các công cụ như 1Password. Nó có thể gọi các dịch vụ như Stripe Link hoặc X Money (Lee nói "XMoney") và các dịch vụ khác để cho phép người ta thanh toán. Nếu bạn định làm gì không đảo ngược được, như gửi email hay tin Slack, nó có thể quay lại hỏi bạn sửa và approve một bản nháp trước khi gửi. Đôi khi bạn chỉ cần thả một emoji reaction nếu thật ra không cần gửi cả một tin nhắn.

## 9. Dynamic tool discovery và thang "thử cách rẻ nhất trước"

Quay lại chuyện dynamic tool discovery. Với bất kỳ model nào đều có một context window, tức working memory, với một giới hạn tính bằng token. Nếu bạn nhét mọi tool có thể vào context window thì sẽ không còn nhiều chỗ. Cách tool hoạt động là có tên tool, có schema, và nhiều chi tiết khác; nếu bắt đầu cài connector Google Drive, Gmail, YouTube, tất cả dịch vụ dùng MCP server vốn đều có tool, bạn sẽ thấy tình trạng như phần trên của slide, nơi nhiều ô đã bị lấp.

![Slide Try the cheapest option first](https://homus.dev/photos/L1OBRtfPS34-2143.jpg)

Slide "Try the cheapest option first", với ghi chú: nếu một connector hỏng, agent không nên lách bằng browser mà nên báo và hỏi bạn. Sáu bậc thang, từ chậm hơn, đắt hơn và rủi ro hơn ở bên phải: 1. What it already knows, 2. An app's API (connector), 3. Web search, 4. Its own signed-in browser, 5. The full desktop, 6. Ask you.

Slide trước đó, "Load tool details only when needed", minh họa bằng lưới ô màu: ở hàng "Every tool loaded up front", system prompt cộng với chi tiết của mọi tool chiếm gần hết context, chỉ còn một ít chỗ cho cuộc hội thoại. Ở hàng "Names first, details on demand", chỉ có system prompt, chi tiết của vài tool và tên các tool khác, nên phần free space rất lớn (slide ghi là minh họa). Vấn đề của kiểu đầu là nó không cho model đủ chỗ để làm công việc của hội thoại.

Vì vậy một mẹo context engineering hay harness mà nhiều harness phổ biến đang dùng gọi là dynamic context, hoặc một số người gọi là tool search tool, một cái tên khá vui. Về cơ bản bạn chỉ đưa tên của các tool vào mỗi message gửi cho model. Rồi model quyết định "à tôi muốn dùng tool này", và nó có thể đọc thông tin từ một file. Tất cả là file và file system từ trên xuống dưới. Điều này giúp tiết kiệm context usage, từ đó cũng tiết kiệm chi phí và usage, tốt cho tất cả mọi người.

Nguyên tắc chung là thử lựa chọn rẻ nhất hay đáng tin nhất trước, rồi leo dần thang. Bậc dễ nhất là thứ agent hay bot đã biết dựa trên lịch sử hội thoại. Nếu không có trong context ngay lúc đó, có thể có một plugin, một MCP server, một API nào đó để lấy dữ liệu, ví dụ kéo thông tin ngân hàng từ Plaid. Có thể cách đó không được và nó cần web search, ví dụ xem đội Cubs đêm qua tỉ số bao nhiêu. Nếu vẫn không có, nó cần vào máy tính, mở browser và tìm kiếm ở đó. Và cuối cùng có thể nó cần dùng cả desktop: chạy script, chạy command hoặc build thứ gì đó trên máy Linux. Chỉ khi tất cả thất bại thì mới đi làm phiền user, xin họ nhập thông tin hoặc approve gì đó. Điều này giúp cảm giác giống như làm việc với đồng nghiệp: họ sẽ không làm phiền bạn vì đủ thứ, lý tưởng là họ sẽ thử nhiều lựa chọn trước.

## 10. Dùng máy tính theo ba cách, main agent và các helper

Trên cái máy Linux đó, agent có ba cách chính để lấy thông tin. Tất nhiên nó có thể chụp screenshot, nhưng có cách hiệu quả hơn. Nó cũng có thể xem HTML của trang, hoặc nhìn accessibility tree, một cách gọn để giảm nhiều token usage và giúp tìm các nút, link hay phần tử khác mà browser cần click. Nếu không cách nào được, nó click vào pixel. Một số website có modal hoặc hộp thoại bật lên cần click nên agent cũng cần chức năng đó. Còn trường hợp tệ nhất trên thang là quay lại hỏi user, ví dụ có mã xác thực hai lớp hoặc captcha. Slide "Three ways to use a computer" ghi rõ: một helper agent riêng làm việc click để screenshot không lấp đầy context của main agent; cách một là đọc cấu trúc trang (nhanh và đáng tin hơn screenshot), cách hai là click trên pixel với màn hình 1280x800 cho app desktop và hộp thoại hệ thống, cách ba là hỏi người ở các bước đăng nhập, mã xác minh, captcha hoặc thanh toán, nó dừng lại, giải thích đang ở đâu và trao màn hình cho bạn.

![Slide One main agent, many helpers](https://homus.dev/photos/L1OBRtfPS34-2343.jpg)

Slide "One main agent, many helpers": bạn nói chuyện với main agent, nó tự trả lời câu hỏi nhanh và giao task lớn cho helper để còn tiếp tục nói chuyện với bạn. Nó giao nguyên một mô tả task hoàn chỉnh cho general helper (shell, web, app connector, cloud agent), computer-use helper (browser và desktop, mỗi lần một task), video helper (xem và review file video) hoặc cloud coding agent (sửa code trong virtual machine riêng), rồi nhận lại một báo cáo ngắn. Phía dưới là các thao tác: một to-do list theo dõi mọi yêu cầu, check on a helper, send a helper a message, stop all helpers.

Ghép các mảnh lại: có main agent là orchestrator, và với main agent bạn muốn giữ hội thoại càng thưa càng tốt, vì giờ nó có khả năng gọi nhiều helper khác nhau, mà helper chỉ là sub-agent. Điều này hữu ích vì nếu giao cho helper chạy cả đống shell command hoặc nhiều tool call đắt đỏ, toàn bộ công việc đó cuối cùng chỉ cho ra một câu trả lời hay một task hoàn tất, và không cái nào làm phình hội thoại hay context của main agent. Chỉ có kết quả quay về. Đó là cách bạn có sản phẩm cảm giác như có context vô hạn.

Lee nói rõ: context vô hạn dĩ nhiên không có thật, mọi model đều có giới hạn context. Nhưng có những mẹo và cách vòng, đặc biệt khi huấn luyện model giỏi hơn ở việc này, khiến bạn không có cảm giác đang đụng giới hạn của context window, và không thấy chất lượng model giảm dần khi đi xa hơn. Các helper khác nhau có skill khác nhau, và mỗi cái là một durable workflow riêng. Quay lại chuyện queue so với workflow: nếu video helper crash hay dùng quá nhiều memory, nó restart và chạy tiếp mà không mất tiến độ. Còn main agent giống một đồng nghiệp quản lý một to-do list; bạn làm được vài việc: đi kiểm tra nó, gửi tin cho nó, dừng các helper. Rất nhiều thứ này mô phỏng cách lý tưởng để scale một team engineer làm việc trên một vấn đề rất phức tạp.

Rồi Lee kể vài điều thú vị rút ra khi xây hệ thống với team. Một: lý tưởng là không thêm hay bớt tool trong các turn (anh sẽ nói thêm về prompt caching). Như slide với các ô màu nhắc ở trên, nếu có mô tả tool hoặc schema cực dài thì nó chiếm nhiều chỗ trong context window, tệ cho giá và usage, nên muốn tối thiểu hóa; có nhiều tối ưu phía engineering để cắt gọn.

Slide "Tips for designing agent tools": đừng thêm hoặc bớt tool giữa các turn, nếu một tool tạm không dùng được thì cho nó trả về lỗi rõ ràng; giữ mô tả và schema của mỗi tool dưới 4.000 ký tự; dùng tool riêng để lưu state thay vì shell command để người review thấy cái gì đang đổi; viết lỗi nói rõ phải làm gì tiếp, ví dụ "The computer is asleep. Use Shell or Read to wake it, then try again."

Hai: bạn có thể nghe người ta nói "harness chỉ cần một tool, và tool đó là chạy shell command". Điều đó đúng và mô hình hóa được nhiều thứ theo cách này, nhưng nếu thấy model dành 90% thời gian chạy shell command cho một việc nào đó thì làm một tool chuyên dụng cho việc đó có thể hiệu quả hơn, và dễ đọc hơn với người review cách sản phẩm đang chạy. Ba, cũng khá vui: khi viết lỗi cho con người thì nên mô tả thật rõ, kiểu "cái này hỏng, bấm link này" hay "đây là việc bạn cần làm tiếp". Hóa ra điều đó cũng rất hữu ích cho agent. Nghĩa là có cả một mảng DX (developer experience) trong việc thiết kế thông báo lỗi tốt cho agent.

## 11. An toàn, và context engineering bắt đầu bằng prompt caching

Khi bạn tin tưởng bot làm việc trong thời gian dài, rất quan trọng là tin rằng chúng bảo mật với thông tin của bạn và với cách chúng vận hành.

Slide "How we keep it safe" với bốn thẻ. Automatic review: một model riêng kiểm các hành động rủi ro trước khi chạy; nếu chặn một việc thì bạn nhận yêu cầu approve, và không trả lời trong 15 giây nghĩa là bị chặn. Track the source: text từ email và webhook được gắn nhãn không đáng tin, memory được coi là thông tin chứ không phải instruction. Asks first: nó không email hay nhắn người khác trừ khi bạn yêu cầu, và routine mới cần bạn OK. Keep secrets hidden: mật khẩu đi vào biến môi trường, không bao giờ tới model, và hành động trên laptop của chính bạn cần bạn approve.

Dù làm việc trên máy riêng, không làm bẩn gì trên máy bạn, vẫn nên có một model review mọi shell command trước khi nó chạy: đó là auto review. Với các đầu vào không đáng tin như một email trong inbox (có thể là email phishing) hoặc một webhook, bạn không muốn gửi nó cho model rồi coi như một chỉ thị của user. Cả ngành còn nhiều việc phải làm để bảo vệ tốt khỏi prompt injection. Với những việc không đảo ngược được như gửi email, bạn thực sự muốn hỏi user trước. Và bạn cũng có thể xây vào sản phẩm các flow để giữ mật khẩu và những thứ khác bên ngoài hội thoại với model.

Phần năm: context engineering. Lee nói nó cũng được gọi là harness engineering, và anh thấy hai cái gần như là một, chúng đã tiến hóa theo thời gian. Câu hỏi là có những mẹo nào để giảm tối đa lượng context dùng trong các harness này, tốt cho hiệu quả, giảm chi phí và nhiều lý do khác.

Anh nhắc tới prompt caching và đây là ví dụ tốt cho thấy vì sao nó quan trọng. Khi làm việc với coding agent hay bất kỳ agent nào, phần lớn token dùng lý tưởng là cached token, vì bạn gửi vào một hội thoại, thực hiện một thay đổi, thêm một message, rồi gửi lại toàn bộ hội thoại từ đầu. Nhìn bảng giá model sẽ thấy giảm giá rất lớn nếu token được cached, và bạn muốn giữ chúng trong cửa sổ cache càng lâu càng tốt.

Slide "Keep the start of the prompt the same": khối trên cùng giữ nguyên cho tới lần tóm tắt kế tiếp, gồm định nghĩa tool, system prompt kèm snapshot của memory và routine, và tin nhắn đầu tiên với chi tiết môi trường cùng danh sách tên tool; nó giống hệt ở mọi lần gọi nên provider tái dùng được phần việc đã cache. Khối giữa là lịch sử hội thoại, tin mới chỉ được thêm vào cuối, và trở thành một phần của phần đầu có thể tái dùng ở lần gọi sau. Khối cuối là tin mới nhất (giờ, ghi chú ngắn về những gì đã đổi, rồi tin của bạn), phần duy nhất mới ở mỗi lần gọi. Provider tính phí thấp hơn và trả lời nhanh hơn khi phần đầu của prompt khớp với một prompt gần đây, nên nội dung ổn định đi trước và nội dung thay đổi đi sau.

Cách làm là giữ định nghĩa tool, system prompt và mọi thông tin ấy càng tĩnh càng tốt giữa các lần gọi, để không phá cache rồi phải trả tiền cho token không cached mỗi lần. Nếu có phần cố định ở trên cùng, thì khi xuống tới đáy và chỉ có tin nhắn mới nhất, đó là delta duy nhất bạn trả tiền token không cached. Và đây là cả một nghệ thuật lẫn khoa học, vì main agent, theo kịch bản lý tưởng, là cái bạn có cuộc hội thoại rất, rất dài, cứ compacting hay compressing, tức tóm tắt context rất nhiều lần mà đôi khi bạn còn không nhận ra, và sẽ có ví dụ ngay sau.

## 12. Giữ context của main agent nhỏ, coi cache miss như một bug

Lee nhấn: bạn thực sự muốn giữ context đó nhỏ.

![Slide Keep the main context small](https://homus.dev/photos/L1OBRtfPS34-2903.jpg)

Slide "Keep the main context small", với main agent's context ở giữa: stays small, so every call is fast and cheap. Ba cách bên trái: long outputs go to files (context chỉ giữ đường dẫn file), screenshots go to a helper (context nhận kết quả nó tìm ra), tool-heavy work goes to helpers (context nhận một báo cáo ngắn). Ba cách bên phải: old messages get summarized, old memories stay searchable (chỉ những fact quan trọng nhất nằm trong prompt), instructions become skills (prompt giữ một dòng trỏ tới). Dòng cuối: việc nặng sống bên ngoài hội thoại chính, chỉ một con trỏ hoặc một bản tóm tắt quay về.

Một số cách: bất cứ khi nào có output rất dài, thay vì nhét vào context, bạn đặt nó vào một file. Agent rất giỏi đọc file nên cách này chạy khá tốt, giống như đọc một skill hoặc một memory. Nếu đưa model một screenshot hay công việc đắt đỏ nào khác, bạn giao cho helper, nó đi vào sub-agent và không ảnh hưởng context của main agent. Và trong thế giới lý tưởng bạn muốn luôn "làm vườn" (gardening) và tỉa bớt những thứ không cần thiết khỏi hội thoại, khỏi context window khi đi, vừa để giảm chi phí, vừa để cải thiện recall và đảm bảo model chạy tốt.

Giữ phần đầu của prompt cố định để provider tái dùng cache, và chỉ tin mới nhất là phần phải trả giá token không cached.

Cho nên một cache miss giống như một bug trong hệ thống. Lee kể lại: quay về tháng 1 năm nay, khi OpenClaw đang trở nên rất phổ biến và người ta dùng nó bên trong các gói subscription của các nhà cung cấp model, đó là một kiểu sử dụng rất mới mà các nhà cung cấp chưa từng thấy. Harness lúc ấy cũng chưa được tối ưu cho kiểu workflow này, nên có rất nhiều cache miss. Khi agent chạy suốt như vậy thì rõ ràng là vấn đề. Phải đưa vào nhiều bản sửa để giữ prompt được cache càng nhiều càng tốt.

Mẹo thứ tự cố định: mỗi section của prompt được hash riêng và giữ đúng một thứ tự, nên một thay đổi thử nghiệm không làm xáo prompt của người khác.

Một mẹo vui: giữ mọi thứ trong prompt theo đúng thứ tự, để ngay cả khi bạn triển khai một thay đổi muốn thử, ví dụ sửa system prompt hay thêm một tool mới, thì không hỏng thứ tự. Bạn gần như có thể hash từng section và luôn giữ thứ tự cố định. Giả sử bạn chạy một A/B test và muốn đặt một đoạn prompt mới vào, bạn thực sự không muốn nó làm lệch thứ tự prompt của mọi người khác. Nếu không, bạn vừa phá cache, và đó là vấn đề. Một mẹo vui khác: khi bạn mở chat và bắt đầu gõ, server có thể chuẩn bị prompt sớm để làm ấm (warm) cache, giống như khi bạn rê chuột lên một link trên website thì nó prefetch trang kế. Slide "Treat a cache miss like a bug" tóm lại: tới lần tóm tắt kế tiếp, tool, system prompt và tin đầu tiên phải giữ y hệt; nếu một lần deploy đổi mô tả tool thì các hội thoại đang chạy nhận một ghi chú thay vì text mới; mọi thứ được dựng theo thứ tự cố định và được sort; tool không bao giờ được thêm hay bớt chỉ cho một turn, tool không dùng được thì trả lỗi; mỗi section hash riêng nên biết chính xác phần nào đổi; và khi bạn mở chat hay bắt đầu gõ, server chuẩn bị prompt sớm để làm ấm cache.

Còn rất nhiều tối ưu engineering nhỏ cộng dồn lại, quyết định model đi được bao xa về token usage và thông minh cỡ nào khi bạn dùng nó trong thời gian rất dài.

## 13. Compaction: tóm tắt khi bạn đi vắng

Điều then chốt là khi làm việc trong một thời gian rất dài, bạn phải rất giỏi compaction, tức tóm tắt. Giả sử model có context window 200.000 token. Bạn cứ đi tiếp, đi tiếp, đến lúc nào đó chạm điểm cần tóm tắt. Và mọi sự nén đều lossy (mất thông tin), nên phải tìm thuật toán nén tốt nhất để không mất chi tiết quan trọng. Lee đoán có cả những luận án tiến sĩ chỉ để giải bài toán này. Nó rất, rất khó.

Slide "Summarize while you're away": một timeline bốn mốc. Một turn lớn kết thúc (prompt đã vượt 100.000 token). Khoảng 10 phút trôi qua (cache của provider vẫn còn ấm). Viết một bản tóm tắt (dùng cùng phần đầu của prompt nên tái dùng được cache). Tin tiếp theo của bạn bắt đầu từ bản tóm tắt ngắn. Ba ghi chú: bỏ qua nếu việc nền sắp đánh thức agent dù sao; những tin cuối agent gửi bạn được giữ nguyên từng chữ; và nếu một turn quá dài thì nó có thể tóm tắt ở giữa chừng.

Ví dụ: bạn qua lại với bot và đã có hơn 100.000 token. Rồi bạn đi làm việc khác. Các nhà cung cấp model có một khoảng thời gian cache window khi cache vẫn còn ấm, có thể là 10 phút, có thể 60 phút. Một mẹo đội Lee dùng, theo anh rất hữu ích: khi vẫn còn trong thời gian cache ấm, bạn nên làm compaction ngay lúc đó, vì hội thoại dài và làm lúc này sẽ rẻ hơn nhiều. Cứ làm compaction, và khi user quay lại sau 30 phút hay lúc nào đó, họ bắt đầu từ bản tóm tắt. Bản tóm tắt đó rẻ hơn nhiều để tiếp tục thêm tin nhắn. Vẫn còn nhiều việc để làm thuật toán tóm tắt đạt chất lượng rất cao.

Ý của mẹo: tóm tắt khi cache của provider còn ấm thì rẻ, nên khi người dùng quay lại họ tiếp tục từ bản tóm tắt gọn.

## 14. Agent nhớ thế nào, và huấn luyện model cho sản phẩm

Khi nói về compaction và thông tin nào đưa vào memory của agent, Lee nghĩ theo vài lớp. Lớp đầu là những fact về user cực kỳ quan trọng và cần có mặt mỗi lần. Quay lại lúc trước khi anh nói user luôn muốn chữ thường: điều đó có lẽ phải nằm trong mọi message, nếu không sẽ rất lạ khi một tin đột nhiên có chữ hoa, kiểu "full Sam Altman" (anh đùa). Sau đó có thể còn một số prompt hay fact bạn muốn đưa vào, và có nhiều cách làm thuật toán để quyết định fact nào quan trọng nhất cần giữ.

Slide "How the agent remembers" với bốn lớp: Profile (fact cốt lõi về bạn, luôn nằm trong prompt, tối đa 100 fact trong 4.000 ký tự); Log (các sự kiện có ngày, 30 sự kiện gần đây liên quan nhất được đưa vào prompt); Notes (chi tiết ngắn hạn mờ đi nhanh); Everything else (tìm bằng một memory search tool khi cần). Bên phải: fact quan trọng xếp hạng cao hơn và fact cũ dần xuống thấp; sau mỗi turn một lượt xử lý thêm fact mới và thay fact cũ, chỉ xóa được các fact nó đã được cho xem; fact về bạn được mọi agent của bạn chia sẻ nhưng mỗi agent ghi vào file riêng; và model được báo rằng memory là thông tin chứ không phải instruction.

Lý tưởng là có một dạng garbage collection (dọn rác) cho fact, và nếu nghĩ kỹ thì đó cũng là cách bộ não ta hoạt động. Fact này bây giờ quan trọng, nó liên quan tới cuộc hội thoại hôm nay. Có lẽ bạn đang không nghĩ tới một trận bóng đá lúc này, và não rất giỏi giữ những thứ đang liên quan trong context và nhớ lại chúng sau. Đội cố mô hình hóa một phần điều đó: harness có các fact cốt lõi, có các log có ngày về lịch sử hội thoại trước đó, và cũng có những ghi chú nháp (scratch pad), tức những việc nhỏ bạn đang làm lúc này, được thiết kế để tạm thời, sẽ biến mất, nhưng có thể liên quan trong 30 phút hay một giờ tới. Mọi thứ còn lại có thể tìm qua file. Đó là phép màu của file: model giỏi chạy command nên luôn đi tra cứu được, và chúng thực sự rất giỏi chuyện đó.

Phần sáu: mọi chuyện đi về đâu. Lee nói có một flywheel (bánh đà) huấn luyện model giỏi hơn ở sản phẩm, và anh nhắc nhanh các giai đoạn huấn luyện một large language model. Đầu tiên là pre-training: model học hiểu biết tổng quát về thế giới từ lượng văn bản internet khổng lồ hoặc dữ liệu riêng. Sau đó là supervised fine-tuning: dạy model cách cư xử theo một kiểu nào đó, có thể là chat assistant hoặc agent. Cuối cùng là reinforcement learning, giống như dạy model chơi trò chơi và chơi giỏi dần.

Slide "Training the model for the product": pre-training học ngôn ngữ, code và kiến thức tổng quát từ lượng văn bản khổng lồ; supervised fine-tuning học harness từ ví dụ (các tool và định dạng của chúng, khi nào gửi trả lời nhanh, một phản hồi lý tưởng trông thế nào); reinforcement learning luyện các task agent thật và được thưởng khi làm tốt (làm theo instruction dài, dùng skill và memory, click đúng chỗ tức grounding, làm việc với các bot khác). Bên dưới: main agent cho phản hồi nhanh (inference và harness được tinh chỉnh để trả lời trong vài giây), còn helper cho task dài (tinh chỉnh để làm hàng giờ việc một cách đáng tin và điều khiển máy tính nhanh).

Trong bối cảnh always-on agent, rất hữu ích khi, ở bước SFT, cho model xem ví dụ về harness và biết cách làm việc bên trong harness, để nó hiểu các tool có sẵn. Còn ở reinforcement learning thì dạy nó làm theo instruction tốt hơn, hiểu chọn đúng skill khi có hàng trăm skill, biết click đúng chỗ khi được đưa một browser và phải click quanh. Không chỉ việc huấn luyện, mà cả cách phục vụ model, tức inference. Với main agent bạn đang trò chuyện, lý tưởng là latency rất thấp: bạn muốn nó trả lời ngay, cho phản hồi thật nhanh, và bạn có thể tinh chỉnh harness và inference cho việc đó. Nhưng khi giao cho một helper và nhờ nó làm một việc trong thời gian rất dài, khác biệt giữa 10 phút và 12 phút gần như không đáng kể. Điều này cho bạn kiểm soát cách tối ưu từng phần.

## 15. Vòng lặp trong, vòng lặp ngoài, và nguyên tắc "delete the product"

Flywheel hoạt động thế này: giả sử agent làm sai điều gì đó. Lý tưởng là nó được biến thành một evaluation (eval): model vô tình gọi tool này và đáng lẽ không được gọi. Rồi ở phía sau, bạn sửa harness, sửa bug, sửa prompt, hoặc có thể là vấn đề inference. Bạn kiểm tra trong eval xem đã thật sự sửa chưa, rồi ship thay đổi. Các team làm những sản phẩm này làm việc đó mỗi ngày: tìm bug, sửa, đo bằng eval. Đó là vòng lặp trong (inner loop) mà bạn luôn cải thiện.

![Slide Product and model improve together](https://homus.dev/photos/L1OBRtfPS34-3623.jpg)

Slide "Product and model improve together". Inner loop, mỗi ngày (climb the evals): một bot làm sai, biến nó thành eval, sửa harness, prompt hoặc inference, kiểm eval, ship bản sửa. Outer loop, vài tháng một lần (model và sản phẩm mới): train model kế tiếp trên harness và eval, đưa nó vào sản phẩm, người dùng dùng theo cách mới (như group chat đầy bot), rồi có các hành vi mới cần đánh giá và huấn luyện. Evals guide training nối hai vòng. Dòng cuối: mọi bot làm việc chưa tốt trở thành một eval; eval cải thiện sản phẩm hôm nay và model kế tiếp ngày mai.

Rồi có vòng lặp ngoài (outer loop): cứ vài tháng, hoặc mỗi tháng, hoặc tùy bao lâu, bạn huấn luyện model mới. Lý tưởng là model mới học từ tất cả bug và thất bại đó, leo lên các eval để giỏi hơn ở những thứ bạn quan tâm. Bạn thả phiên bản mới vào sản phẩm và đảm bảo nó cải thiện ở mọi mặt. Điều vui là khi model mới ra, có những bước nhảy năng lực mới, cho phép dùng sản phẩm theo cách mới.

Ví dụ, chưa có nhiều dữ liệu huấn luyện về việc dùng bot trong group chat. Đây là hành vi nổi lên (emergent) đang được tìm hiểu, và làm đúng rất quan trọng. Nếu bạn đã thấy những chuyện như Moltbook hay sự cố của Hugging Face, thì biết có những cách nó đi sai. Vì vậy quan trọng là huấn luyện model biết cư xử tốt trong một hệ multi-agent, nơi các bot khác nhau nói chuyện với nhau. Lý tưởng là bạn luôn chạy các vòng trong và vòng ngoài này với tư cách một product team xây harness ở một công ty làm AI cùng nhau.

Slide "Delete the product.", với dòng nhỏ: giả định model sẽ tốt hơn nhiều, build quanh chúng càng ít càng tốt và gỡ bỏ những gì chúng không còn cần.

Một nguyên tắc ở Cursor trước đây và giờ ở SpaceX là "delete the product" (xóa sản phẩm). Nghĩa là bạn phải nội tâm hóa và giả định rằng model hôm nay là bản tệ nhất mà bạn sẽ từng có, nên sáu tháng nữa có thể phải làm lại hoàn toàn UI. Phần lớn những gì Lee nói hôm nay là một cập nhật khá lớn so với nếu anh giảng bài này sáu tháng trước, hay chắc chắn là một năm trước, vì đã học thêm nhiều cách thực tế để build harness và làm context engineering. Chiến lược tốt là cố build cho thế hệ model kế tiếp: làm sao build càng ít càng tốt mà vẫn sống được, trong khi làm một giao diện thật đơn giản để làm việc với các model và để chúng suy nghĩ, hành động thay bạn.

## 16. Dự đoán trong 6 đến 12 tháng tới

Lee nêu vài điều anh nghĩ sẽ xảy ra trong 6 đến 12 tháng tới, "cứ chờ xem", nhưng theo anh là các cược khá an toàn. Hiện tại agent hay bot làm việc vài giờ, có thể một ngày, tùy độ khó. Anh nghĩ rất có thể chẳng bao lâu agent sẽ làm việc hàng tuần hay hàng tháng. Điều đó nêu ra những câu hỏi thú vị về cách huấn luyện và đánh giá các model này.

Slide "What I expect in 6 to 12 months": longer projects (agent làm một project suốt nhiều tháng chứ không chỉ một task vài phút), better memory (nhớ cách bạn và team làm việc và ngày càng giỏi hơn), more powerful tools (mọi thứ làm được trên máy tính, nhanh và đáng tin hơn), simpler interfaces (hôm nay là nhắn tin, tiếp theo có thể chỉ cần giọng nói, tùy cái gì dễ nhất cho từng người), skills they weren't trained for (bot học được ngay trên công việc nhờ memory, khả năng làm theo skill và instruction tốt hơn, cùng trí thông minh thô), và knowledge written down (con người và công ty viết ra những gì họ biết để agent dùng được).

Model sẽ ngày càng giỏi hơn trong việc nhớ lại thông tin cũ trong hội thoại. Trong nghiên cứu có nhiều hướng tiếp cận khác nhau, về thuật toán hay cách biểu diễn dữ liệu bên dưới: có thể là một graph, có thể là file, có thể là cái khác. Lý tưởng là nếu bạn có một đồng nghiệp số này, bạn trao cho nó mọi tool bạn sẽ trao cho một người thật khi onboard họ. Lee nghĩ các tổ chức vẫn đang làm quen dần với ý tưởng đó, nên còn nhiều việc phải làm.

Giao diện có thể còn dễ hơn nữa: một số người sẽ thích nói chuyện với bot hay agent theo kiểu speech-to-speech, có thể họ có một thiết bị của Johnny Ive hy vọng thật tuyệt và nói chuyện với nó cả ngày. Model và sản phẩm sẽ rất giỏi học skill ngay trên công việc rồi mã hóa vào file và instruction, skill, tức lấy trí thông minh thô đó và làm nó thật sự hữu ích cho bất kỳ việc gì bạn yêu cầu. Và con người cùng công ty sẽ giỏi hơn nhiều trong việc ghi lại cách các quy trình riêng của họ vận hành, để agent đọc hiểu được.

## 17. Các bài toán mở và những building block mới

Lee liệt kê vài vấn đề thú vị, có thể gợi ý cho các bạn nghiên cứu. Thứ nhất, quay lại ý agent chạy một tháng: bạn làm gì khi cần đánh giá một agent chạy cả tháng, trong khi model được ship mỗi tháng? Bạn không thể đánh giá đầy đủ rằng model hành xử đúng kỳ vọng, nên hoặc phải tìm cách làm eval tốt hơn, hoặc không ship model nhanh như vậy. Anh nghĩ ngành sẽ phải giải bài toán này trong sáu tháng tới.

Slide "Open problems you could work on": testing long-running agents (chấm điểm một agent làm việc nhiều tuần thế nào, các phương pháp hiện tại còn chật vật); correct memory (thay fact lỗi thời, quên khi được yêu cầu, không bao giờ bịa ra); prompt injection (agent đọc email và web sẽ thấy văn bản viết ra để lừa nó, phòng thủ còn sơ khai); when to speak (nhắn quá nhiều là nhiễu, quá ít thì không biết nó đang làm gì); coordination (nhiều agent dùng chung một máy tính và một memory sẽ gặp các vấn đề distributed system kinh điển); cost (always-on chỉ chạy được nếu agent rảnh gần như miễn phí và agent đang làm việc thì rẻ).

Memory thì rõ ràng, đã nói về các thuật toán. Về security còn rất nhiều việc để làm một harness an toàn và hạ tầng quanh các agent đó thật an toàn, để chúng không bị kẻ xấu chiếm quyền. Lee nói họ chưa bàn nhiều về heuristic khi nào agent im lặng hay khi nào làm phiền bạn, và anh không nghĩ mình đã làm hoàn hảo. Cần khéo léo giữa chủ động và gợi ý, kiểu "ơ, tôi thấy hôm qua bạn nghỉ học, tôi có bản ghi và đã ghi chú, đây này". Điều đó có thể hữu ích, hoặc có thể hơi phiền, và tìm ra cân bằng đúng là khó. Anh cũng cho rằng khá an toàn để giả định rằng cùng thời điểm này năm sau, lượng token chảy trong thế giới sẽ nhiều hơn rất, rất nhiều, nghĩa là tối ưu inference, model, harness, và làm giảm token usage cho hiệu quả hơn, cũng sẽ rất quan trọng.

![Slide The new building blocks](https://homus.dev/photos/L1OBRtfPS34-4223.jpg)

Slide "The new building blocks": mỗi web app đều có một server, một database, một cache, một giao diện CRUD. Mỗi sản phẩm agent sẽ có durable workflow, khả năng dùng máy tính, memory và skill, trigger và scheduled job, connector và auth, kênh text và voice, thanh toán và identity, eval và observability. Chú thích: nhiều sản phẩm sẽ trông giống nhau nhưng xây các mảnh này rất khác, và nên chờ một "đuôi dài" các phiên bản chuyên biệt, tốt nhất trong loại.

Rồi tới các building block mới. Lee nhớ là Alex, một người ở một dịch vụ API trung gian cho model, đã viết một nhận xét rất hay trên X. Có người than mọi app bây giờ trông giống nhau: có sidebar, có agent, có ô chat, ai cũng xây cùng một thứ. Alex nói: ừ, hệt như năm 2005 vậy, ai cũng xây cùng một thứ, có server, có database, có giao diện CRUD để cập nhật và xóa. Thực tế đây chính là trạng thái bình thường mới: mọi sản phẩm mới sẽ phải có một mặt agentic nào đó, hoặc tích hợp, hoặc trở thành một mảnh dữ liệu headless cho agent khác dùng.

Những thứ đã nói hôm nay: durable workflow, sandbox, máy tính trên cloud, memory, skill, kết nối với các dịch vụ khác, voice, payment, identity, eval, observability. Mỗi ô đó, anh nói, đại diện cho nhiều tỉ đô vốn VC, có lẽ hàng nghìn tỉ, và có 20 startup cho mỗi ô. Có rất nhiều thứ để khám phá ở tất cả những ô này vì chúng là các primitive mới cho thế hệ công ty và sản phẩm kế tiếp. Và tất cả phải tích hợp và là một phần của harness. Còn rất nhiều việc phải làm.

## 18. Ba điều rút ra

Lee nói vài điều để mang về, rồi sẽ có thời gian cho câu hỏi. Các bạn là engineer, đang nghĩ cách viết phần mềm.

Slide "What to take away", với câu mở đầu: khi code ngày càng dễ viết, biết các mảnh ghép khớp nhau thế nào càng quan trọng. Ba thẻ: Architecture compounds (khi code rẻ để viết, kiến trúc đúng là thứ giúp bạn đi nhanh hơn mọi người), Build your own (bắt đầu từ agent tuần một và thêm một server, một máy tính và memory; agent always-on mã nguồn mở rất đáng để học), Learn the fundamentals (biết cách LLM hoạt động giúp bạn đánh giá điều gì khả thi, giống như biết database giúp ích khi bạn build một website).

**Một:** quan trọng hơn bao giờ hết là nghĩ tới thiết kế hệ thống tổng thể và kiến trúc của code bạn đang làm, vì những quyết định ở đó sẽ cộng dồn. Lee vẫn ủng hộ việc đọc code: anh vẫn nhìn code mình viết. Một số người không nhìn code. Anh vẫn thấy việc đó hữu ích, đặc biệt để hiểu kiến trúc mà mình đang ship. Anh thấy thật điên rồ là chuyện này đã thay đổi bao nhiêu chỉ trong vài năm.

**Hai:** nghe nói tuần trước cả lớp đã nghịch ngợm tự build phiên bản riêng hoặc tìm hiểu cách harness hoạt động. Anh khuyến khích các bạn nghĩ về một số thứ anh nói hôm nay, thử áp dụng và nghĩ xem mình có thể build một phiên bản cho riêng mình thế nào. Anh khá chắc đâu đó trên GitHub có một "open Grok Bot" mà ai đó đã fork code rồi làm một phiên bản. Và có thể dựng GUI cho nó với một sandbox ở đâu đó, một VM và đủ thứ khác. Có thể thú vị nếu bạn muốn hiểu thêm các mảnh này vận hành thế nào.

**Ba:** đừng ngại học thêm về cách LLM hoạt động. Hôm nay đã có một bản TL;DR về cách chúng được huấn luyện, nhưng còn rất nhiều thứ để đào sâu mà không nhất thiết đi sâu vào ML hay phần khoa học. Anh thấy hữu ích như khi build một web app, biết database hoạt động ra sao cũng hữu ích, vì ngày càng nhiều quyết định ở tầng sản phẩm và harness bị chính các model ảnh hưởng. Có trực giác về chuyện đó sẽ đặt bạn vào vị trí rất tốt cho bất kỳ vai trò nào bạn đảm nhận. Lee kết thúc: "Đó là tất cả những gì tôi có hôm nay. Cảm ơn mọi người."

## Nguồn và liên kết

- Tên gốc: Stanford CS146S: How always-on agents work
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=L1OBRtfPS34](https://www.youtube.com/watch?v=L1OBRtfPS34)

- Kênh YouTube leerob (Lee Robinson): [youtube.com/channel/UCZMli3czZnd1uoc1ShTouQw](https://www.youtube.com/channel/UCZMli3czZnd1uoc1ShTouQw)

- Temporal, engine durable workflow mã nguồn mở mà Lee nhắc tới: [temporal.io](https://temporal.io)

- Firecracker, công nghệ virtual machine mà Lee nói máy tính của agent dùng: [firecracker-microvm.github.io](https://firecracker-microvm.github.io)

Nguồn: https://homus.dev/talks/stanford-cs146s-how-always-on-agents-work · cập nhật 2026-10-17