Agent phủ rộng vs agent tự học — chọn sai thì sửa đắt
Hermes Agent vượt OpenClaw trên OpenRouter, nhưng với builder câu hỏi thật sự là kiến trúc reach-first hay learn-first phù hợp production của bạn.
Bụi Wire224 tỷ token mỗi ngày. Đó là lượng inference mà Hermes Agent đang xử lý trên OpenRouter — vượt OpenClaw với 186 tỷ. Nhưng nếu bạn đang là tech lead chọn kiến trúc cho hệ thống agent, con số token không phải thứ nên quyết định thay bạn. Phía sau hai cái tên này là hai triết lý kiến trúc đối nghịch: phủ rộng trước hay tự học trước — và chọn sai ở bước này thì chi phí sửa rất đắt.
Hai trường phái đang đụng nhau
OpenClaw — dự án open-source giờ thuộc quản lý của một foundation độc lập sau khi founder Peter Steinberger gia nhập OpenAI đầu 2026 — đặt cược vào reach. Kiến trúc xoay quanh một WebSocket Gateway (lớp định tuyến kết nối liên tục) làm trung tâm, nối hơn 50 kênh nhắn tin: Telegram, Discord, Slack, WhatsApp, Signal... Agent có mặt ở mọi nơi user xuất hiện — đó là mục tiêu thiết kế.
Hermes Agent của Nous Research chọn learn. Kiến trúc xoay quanh vòng lặp "do → learn → improve": hoàn thành task xong, agent tự phân tích hiệu suất rồi sinh ra skill files (file kỹ năng tái sử dụng) cho lần sau. Bộ nhớ chia 3 tầng: identity snapshot, cơ sở dữ liệu full-text search bằng SQLite FTS5, và procedural skill files ghi lại logic task lặp lại. Hermes càng chạy lâu, càng tối ưu cho workflow cụ thể của bạn.
Nhiều team nhìn bảng xếp hạng OpenRouter rồi kết luận: "Hermes #1, vậy dùng Hermes." Đây là chỗ cần dừng lại. Inference volume cho biết ai đang được dùng nhiều — không cho biết ai phù hợp với bài toán production cụ thể của bạn.
Biến số 1: orchestration — một gateway hay một vòng lặp?
Câu hỏi đầu tiên cho builder: agent của bạn cần điều phối cái gì?
Nếu bài toán là "một agent trả lời khách hàng trên Zalo, Telegram, và Slack cùng lúc" — gateway trung tâm của OpenClaw giải quyết gọn. Một lớp routing duy nhất, gần stateless theo channel, scale horizontal dễ dàng. Giả sử team bạn 5 người đang vận hành chatbot hỗ trợ cho một sàn thương mại điện tử: thêm kênh mới chỉ cần cắm adapter, không đụng logic agent.
Nhưng gateway trung tâm cũng đồng nghĩa single point of failure (điểm lỗi duy nhất). Gateway sập thì toàn bộ 50 kênh mất kết nối cùng lúc.
Hermes đi hướng khác. Vòng "do → learn → improve" biến orchestration thành quá trình tự điều chỉnh liên tục. Và đây là điểm nhiều team vấp: agent tự sinh skill files mà không có guardrail (rào chắn kiểm soát) sẽ compound cả lỗi lẫn giá trị. Nếu agent học sai một lần và ghi thành skill file, nó sẽ lặp lại sai lầm đó — mỗi lần tự tin hơn lần trước.
Kịch bản minh họa: Giả sử team DevOps 4 người ở TP.HCM dùng Hermes tự động hóa deploy. Sau 2 tuần, agent sinh skill file cho rollback — nhưng skill đó skip bước verify health check vì lần đầu rollback thành công mà không cần. Ba lần rollback sau đều skip, lần thứ tư hệ thống sập. Đây mới là boss fight thật của kiến trúc learn-first: guardrail phải có trước khi agent được phép tự học.
Biến số 2: memory — phủ kênh hay phủ ngữ cảnh?
OpenClaw thiết kế gần stateless theo session — mỗi kênh là cuộc hội thoại riêng biệt. Đơn giản để vận hành, nhưng agent không "nhớ" gì qua các phiên.
Hermes xây 3 lớp memory:
- Identity snapshot — thông tin cố định về user và agent, giữ nguyên qua mọi phiên
- FTS5 full-text search — tìm kiếm toàn văn qua toàn bộ lịch sử phiên trước
- Procedural skill files — logic task được mã hóa để tái sử dụng tự động
Vấn đề cho builder không phải "memory nhiều hay ít" mà là: ai kiểm soát những gì agent nhớ? Agent tự quyết skill nào đáng ghi mà không có lớp review — memory trở thành nợ kỹ thuật thay vì tài sản.
GitHub gần đây cũng chỉ ra bài toán tương tự khi tối ưu token efficiency (hiệu quả sử dụng token) cho agentic workflows: càng nhiều context agent giữ lại, càng tốn token, và càng dễ nhiễu nếu thiếu cơ chế lọc. Dịch sang bài toán memory: không phải cứ nhớ nhiều là tốt — phải nhớ đúng thứ.
Lúc nào reach, lúc nào learn?
Thay vì hỏi "cái nào tốt hơn", trả lời 3 câu:
| Câu hỏi | Reach-first (OpenClaw) | Learn-first (Hermes) |
|---|---|---|
| Agent cần bao nhiêu kênh? | ≥ 5 kênh user-facing | 1–2 kênh nội bộ |
| Task có lặp lại và cải thiện được? | Task ad-hoc, đa dạng | Task lặp, quy trình rõ |
| Team có bandwidth review skill files? | Không → ít rủi ro tự phát | Có → compound value dài hạn |
Ví dụ cụ thể: Giả sử bạn là tech lead startup fintech ở Việt Nam, team 8 người. Agent hỗ trợ khách hàng chạy trên Zalo, web chat, app nội bộ — 3 kênh, task chủ yếu FAQ và tra cứu giao dịch. Reach-first hợp lý: stateless, dễ debug, agent không tự "sáng tạo" câu trả lời sai. Nhưng nếu bạn xây agent nội bộ review PR và cải thiện pipeline CI/CD hàng ngày — learn-first mới đáng đầu tư, vì task lặp lại mỗi ngày và team dev có thể audit skill files mỗi sprint.
Cả hai đều MIT license, cả hai đều open-source. Rào cản không phải chi phí mà là kiến trúc có khớp với cách team bạn vận hành hay không.
Leaderboard không phải compass
Hermes #1 hôm nay. OpenClaw có thể quay lại tuần sau. Với builder, thứ hạng trên bảng xếp hạng giống checkpoint trong game — ghi nhận tiến trình nhưng không chỉ hướng đi tiếp.
Điều quyết định agent sống hay chết trên production nằm ở hai thứ: orchestration có kiểm soát được không, và guardrail có chạy trước khi agent tự học không. Reach-first hay learn-first là quyết định kiến trúc — và quyết định kiến trúc thì không có nút respawn.
---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng