OpenClaw vs Hermes: bài học thiết kế agent vận hành từ một chia sẻ thực tế

Có một chia sẻ khá đáng chú ý trên r/openclaw: một người dùng thử chuyển từ OpenClaw sang Hermes vài ngày và ghi lại cảm giác rất thẳng. Bỏ qua phần “fan tool nào”, bài này chạm đúng một câu hỏi thực tế hơn: khi dùng AI agent để vận hành công việc hằng ngày, mình đang cần một “trợ lý cá nhân” hay một “coding harness” có agent bên trong?

Với anh em đang dựng hệ thống agent cho cá nhân hoặc doanh nghiệp nhỏ, khác biệt này không chỉ là cảm giác dùng. Nó ảnh hưởng trực tiếp tới memory, cron, bảo mật, khả năng remote control và chi phí vận hành.

Điểm đáng chú ý trong trải nghiệm OpenClaw vs Hermes

Theo chia sẻ gốc, OpenClaw tạo cảm giác giống một trợ lý cá nhân hơn vì nó tích cực giữ ngữ cảnh về người dùng, thói quen, workspace và các quyết định trước đó. Còn Hermes được mô tả gần hơn với một harness: gọn, thiên về coding, ít “tính cá nhân” hơn, memory về user bị giới hạn chặt hơn.

Điểm này không tự động khiến bên nào thắng. Nó là trade-off:

• Memory sâu giúp agent hiểu việc đang làm, ít hỏi lại, xử lý công việc đời thật mượt hơn.
• Memory ngắn giúp hệ thống dễ kiểm soát, ít phình ngữ cảnh, ít rủi ro lộ dữ liệu không cần thiết.
• Agent “có cá tính” hợp với trợ lý vận hành dài hạn.
• Agent “như harness” hợp với job kỹ thuật hẹp, có input/output rõ.

Nếu anh em chỉ cần chạy code task rời rạc, memory cá nhân sâu có khi là thừa. Nhưng nếu muốn agent theo dõi forum, email, lịch, dự án, các quyết định trong workspace, memory và continuity lại là phần lõi.

Cron là nơi lộ rõ triết lý thiết kế

Một điểm người dùng nhấn mạnh là cron của Hermes có nhiều rào hơn: môi trường khác main agent, phải khai báo lại PATH, env, skill, thư mục script bị quy định chặt, đôi khi phải viết wrapper. Cảm giác nhận được là “an toàn hơn trên giấy, nhưng dễ vấp hơn khi vận hành”.

Ở chiều ngược lại, họ khen một ý tưởng rất hay: cron có thể quyết định có đánh thức LLM hay không. Với các việc cơ học như kiểm tra inbox, đọc trạng thái API, scan log, nếu không có gì mới thì không cần gọi model. Đây là mẫu thiết kế nên học, bất kể dùng tool nào.

Một cron agent tốt nên có 2 tầng:

1. Tầng script rẻ, deterministic, chỉ kiểm tra tín hiệu.
2. Tầng LLM chỉ thức dậy khi có việc cần hiểu ngữ cảnh, ra quyết định hoặc viết nội dung.

Cách này giảm chi phí và giảm nhiễu rất mạnh. Đừng để LLM thức dậy chỉ để kết luận “không có gì”.

Bảo mật thật không nên làm hỏng đường vận hành

Bài gốc gọi một số rào là “security theatre”. Cách nói hơi gắt, nhưng vấn đề là thật: nếu cơ chế an toàn khiến mọi tác vụ hợp lệ đều hỏng ở lần chạy đầu, người vận hành sẽ bắt đầu viết wrapper, bypass, hoặc copy env lung tung. Lúc đó hệ thống không an toàn hơn, chỉ khó hiểu hơn.

Thiết kế tốt hơn là phân quyền theo loại hành động:

• Đọc file workspace: thường cho phép rộng hơn.
• Gọi URL public để lấy dữ liệu: cho phép nhưng không eval nội dung tải về.
• Gửi email, đăng bài, xoá dữ liệu, gọi API write: cần chốt rõ và log lại.
• Cron có quyền external write: phải có input, scope và idempotency rõ.

Nói ngắn gọn: bảo mật nên chặn hành động nguy hiểm, không nên biến hành động bình thường thành mê cung.

Bài học vận hành cho anh em đang dựng agent

Nếu đang chọn hoặc tự thiết kế workflow agent, mình sẽ không hỏi “tool nào hay hơn” đầu tiên. Mình sẽ hỏi 5 câu này:

• Agent này cần nhớ người dùng bao lâu và nhớ loại gì?
• Việc nào phải chạy bằng script trước, chỉ gọi LLM khi có tín hiệu?
• Cron có nhìn thấy đủ context để làm việc không, hay bị tách đến mức vô dụng?
• Khi đi xa, mình có cấu hình và sửa lỗi được từ Telegram, Discord, web hay bắt buộc SSH?
• Có log/dedupe/idempotency để tránh đăng trùng, gửi trùng, chạy trùng không?

Với doanh nghiệp, câu cuối rất quan trọng. Agent càng tự động thì càng phải có dấu vết: đã đọc nguồn nào, chọn topic nào, publish bài nào, vì sao bỏ qua bài nào. Không có lớp này thì sau vài tuần automation sẽ thành “hộp đen biết tiêu tiền”.

Kết luận thực dụng

OpenClaw mạnh khi anh em muốn một trợ lý vận hành dài hạn: có memory, có heartbeat, có workspace, có khả năng chủ động làm việc theo ngữ cảnh. Hermes, theo trải nghiệm được chia sẻ, có vẻ nghiêng hơn về hướng harness gọn cho coding và job có biên rõ.

Điểm mình thấy đáng lấy nhất không phải là chọn phe, mà là nguyên tắc thiết kế: agent cá nhân cần continuity, còn automation định kỳ cần tầng lọc rẻ trước khi đánh thức LLM. Ghép được hai thứ đó thì hệ thống vừa “thông minh” hơn, vừa đỡ tốn tiền và đỡ gây phiền.