Tan sương quanh agent desktop

Tan sương quanh agent desktop

Hermes Desktop đáng chú ý không vì có GUI, mà vì nó buộc builder hỏi lại: agent của mình đang có một lõi vận hành hay chỉ là nhiều cửa sổ chat?

Sáng thứ Hai, lead của một team SaaS ở Đà Nẵng nhắn mình: “Bên em đang tính build agent nội bộ. Có nên chờ model mới không, hay làm cái desktop app cho mọi người dùng trước?”

Câu hỏi nghe như hỏi tool, nhưng thật ra là hỏi kiến trúc.

Vì tuần này có một tín hiệu khá đáng bóc: Hermes Desktop xuất hiện như giao diện native cho Hermes Agent trên macOS, Windows và Linux. Nếu chỉ nhìn bề mặt, đây là một app desktop mới. Nếu nhìn như builder, đây là một ca kiểm tra rất hay: agent nghiêm túc không bắt đầu từ cửa sổ đẹp, mà từ việc lõi agent, memory, tool và evaluation có sống chung được qua nhiều bề mặt hay không.

Sau bài này, thứ bạn nên nghĩ khác là: đừng hỏi agent nào mới nhất; hãy hỏi agent đó có chịu nổi nhiều “mặt trời, mưa gió” của workflow thật không.

Sơ đồ minh họa cho bài Tan sương quanh agent desktop

Sơ đồ tóm tắt ý chính của bài viết.

Cảnh của team Sao Mai: demo đẹp, vận hành lấm lem

Team Sao Mai có 7 dev, 2 ops, 1 product manager. Họ muốn một agent làm ba việc:

Ban đầu, một bạn dev dựng nhanh bản chat web. Demo chạy ổn. Agent trả lời trơn, có vài nút gọi tool, nhìn cũng có vẻ đủ dùng.

Rồi tuần sau bắt đầu có gió ngược:

Đây là chỗ Hermes Desktop đáng để nhìn, không phải vì nó có giao diện. Điểm đáng chú ý là desktop dùng lại cùng agent core với CLI và gateway: configuration, API keys, sessions, skills và memory không bị nhân bản thành một nhánh riêng.

Nói thẳng ra thì: GUI không nên là một agent mới mặc áo khác. GUI chỉ nên là một bề mặt mới trên cùng một lõi.

Mổ lớp đầu: surface không được làm vỡ core

Trong hệ AI agent, surface là nơi người dùng tương tác: desktop app, CLI, TUI, Slack bot, web app. Core là phần thực sự chạy vòng lặp plan-act-observe, tức agent lập kế hoạch, gọi công cụ, quan sát kết quả rồi quyết định bước tiếp.

Hermes Desktop đưa ra một mẫu đáng học: desktop hiển thị streaming response và tool activity theo thời gian thực, có pane bên phải để preview web page, file và output của tool. Nhưng nó không tách thành một agent khác.

Hình dung thế này: nếu team bạn có một agent chạy qua CLI cho dev, qua desktop cho analyst, qua gateway cho Discord hoặc Telegram, thì câu hỏi sống còn là:

Khi đổi surface, agent có còn là cùng một người đang làm việc không?

Nếu câu trả lời là không, bạn sẽ gặp một dạng “áp thấp” kiến trúc: mỗi giao diện giữ một state riêng, mỗi state lệch một chút, rồi đến lúc debug thì không biết lỗi nằm ở model, tool, prompt hay session.

Framework mình sẽ dùng cho team builder là S-C-M-E:

| Lớp | Câu hỏi phải trả lời | Dấu hiệu ổn |
|---|---|---|
| Surface | Người dùng vào từ đâu? | Desktop, CLI, gateway dùng chung session |
| Core | Ai điều phối task? | Một agent core, không fork logic theo UI |
| Memory | Agent nhớ gì và quên gì? | Có memory rõ lớp, có cách sửa và kiểm chứng |
| Evaluation | Làm sao biết agent vẫn cư xử đúng? | Có regression test cho hành vi, tool call và policy |

Điểm này quan trọng hơn việc app có voice input hay file browser. Tính năng UI có thể thêm sau. Còn nếu core đã bị chia nhánh, bạn đang tự tạo nhiều vùng thời tiết khác nhau trong cùng một sản phẩm.

Mổ lớp hai: memory dài hạn không chỉ là lưu chat

Hermes Agent có memory persistent, session search bằng FTS5 và summarization bằng LLM. FTS5 là full-text search trong SQLite, hiểu nôm na là tìm lại nội dung hội thoại theo chữ khóa thay vì chỉ dựa vào embedding. Hermes cũng có cơ chế agent-curated memory, tức agent tự đề xuất hoặc ghi lại tri thức đáng giữ.

Nhưng Memory OS lại cho thấy một phản đề thú vị: memory có sẵn có thể chưa đủ cho công việc nghiêm túc. Dự án này đặt thêm sáu lớp memory quanh Hermes: workspace files, session database, structured facts, fabric recall, vector database và wiki tự curated.

Ở đây có vài thuật ngữ cần neo nhanh:

Với team Sao Mai, lựa chọn không phải là “có memory hay không”. Lựa chọn đúng hơn là:

  1. Memory nhẹ: dùng session search và file memory. Hợp với agent cá nhân, task ngắn, ít ràng buộc.
  2. Memory nhiều lớp: thêm structured facts, vector search, wiki. Hợp với sản phẩm dùng lâu, nhiều người, có domain knowledge.
  3. Không cho agent tự ghi lung tung: cần approval hoặc audit log nếu memory ảnh hưởng đến quyết định kinh doanh.

Bản chất thật sự: memory càng mạnh thì chi phí kiểm soát càng cao. Một agent nhớ dai nhưng nhớ sai còn mệt hơn agent hay quên.

Mổ lớp ba: model mới không thay thế evaluation

Qwen3.7-Plus thêm vision, deep reasoning, tool invocation và autonomous iteration trên Bailian. tool invocation là khả năng gọi API hoặc hàm bên ngoài, không chỉ trả lời bằng chữ. NVIDIA Cosmos 3 lại đi hướng physical AI với kiến trúc Mixture-of-Transformers, tức nhiều thành phần transformer phối hợp theo vai trò; nó nhắm vào reasoning, world generation và action generation cho robotics, xe tự hành, warehouse monitoring.

Những release này có giá trị, nhưng chúng không trả lời thay câu hỏi của team Sao Mai: agent có làm đúng policy sản phẩm của mình không?

Đó là lý do ASSERT của Microsoft đáng đặt cạnh các release model. ASSERT biến mô tả hành vi bằng ngôn ngữ tự nhiên thành test case có điểm số. Nó còn ghi lại intermediate actions và tool calls, tức các bước giữa đường agent đã đi qua.

Ví dụ cụ thể: giả sử team bạn có agent nghiên cứu tài liệu nội bộ. Bạn mô tả policy:

Agent không được gửi email ra ngoài domain công ty.
Agent chỉ được tóm tắt tài liệu mật cho nhóm C-level.
Agent phải trích dẫn nguồn nội bộ khi đưa ra kết luận.

Một evaluation framework kiểu ASSERT sẽ sinh tình huống kiểm tra: người dùng cố yêu cầu gửi email ra Gmail cá nhân, hỏi thông tin mật dưới vai trò không phù hợp, hoặc yêu cầu tóm tắt mà không có nguồn. Quan trọng hơn, nó cho bạn xem agent fail ở đâu: prompt, tool permission, retrieval, hay decision step.

Đây là chỗ nhiều team hiểu sai: model giỏi hơn không tự động làm sản phẩm an toàn hơn. Model có thể reasoning tốt hơn, nhìn ảnh tốt hơn, gọi tool khéo hơn — nhưng nếu không có evaluation theo policy riêng, bạn chỉ đang hy vọng trời lặng gió.

Điều đáng giữ từ Hermes Desktop

Hermes Desktop đáng giữ ở ba quyết định kiến trúc.

Một: surface dùng chung core.
Nếu bạn đang build agent cho nhiều nhóm người dùng, đừng để mỗi UI có logic agent riêng. Hãy tách rõ:

Hai: tool output phải nhìn thấy được.
Streaming tool output không chỉ để nhìn cho vui. Nó là observability ở mức người dùng. Khi agent gọi browser, đọc file, chạy lệnh, hoặc tạo skill, bạn cần thấy nó đang làm gì trước khi nó kết luận.

Ba: session phải đi qua nhiều bề mặt.
Một cuộc hội thoại bắt đầu ở desktop rồi nối tiếp trong CLI là một yêu cầu vận hành rất thật. Với team dev, CLI là nơi debug. Với người dùng business, desktop là nơi làm việc. Nếu session không chia sẻ được, bạn đang bắt người dùng kể lại cùng một chuyện nhiều lần.

Mini-checklist cho một buổi chiều:

[ ] Liệt kê tất cả surface hiện tại: web, CLI, desktop, chat gateway.
[ ] Kiểm tra mỗi surface có dùng cùng agent core không.
[ ] Chọn một session thật, thử resume qua surface khác.
[ ] Bật log cho tool calls và intermediate actions.
[ ] Viết 5 policy hành vi rồi biến chúng thành test case.
[ ] Kiểm tra memory: dữ kiện nào được lưu, ai sửa được, xóa thế nào.

Nếu làm xong checklist này, bạn sẽ biết agent của mình là một hệ thống có lõi hay chỉ là nhiều demo đứng cạnh nhau.

Điều nên bỏ qua khi đọc release agent

Có vài thứ dễ làm mình mất tập trung.

Đừng quá bám vào việc có desktop app hay chưa. Desktop chỉ là một surface. Nếu core yếu, desktop đẹp cũng không cứu được production.

Đừng xem memory như tính năng cộng thêm. Với agent làm việc nhiều ngày, memory là một phần của correctness. Nó quyết định agent có nhớ yêu cầu, hiểu người dùng và tái sử dụng kỹ năng đúng cách hay không.

Đừng để model release kéo bạn ra khỏi bài toán evaluation. Qwen3.7-Plus, Cosmos 3 hay bất kỳ model mạnh nào đều chỉ là một thành phần. Với sản phẩm thật, bạn vẫn cần test hành vi theo domain, policy và tool permission của chính mình.

Nếu là mình, mình sẽ dùng Hermes Desktop như một tín hiệu thiết kế hơn là một món đồ phải chạy ngay: thiết kế agent sao cho surface thay đổi được, core không vỡ, memory có kiểm soát, evaluation chạy định kỳ.

Chốt lại: khi sương hype tan bớt, thứ còn lại không phải cái cửa sổ app sáng bóng, mà là câu hỏi rất bụi — agent của bạn có còn tỉnh táo sau vài phiên làm việc không?

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo