Một câu hỏi ngắn trên r/hermesagent đang kéo khá nhiều bình luận: nếu mới dùng Hermes Agent thì nên cài hoặc tự xây những skill nào trước? Đây là câu hỏi đáng chú ý, vì skill rất dễ bị biến thành “kho đồ chơi” nếu mình thêm quá nhiều thứ trước khi có workflow thật.
Góc nhìn thực dụng của mình: đừng bắt đầu bằng danh sách skill dài nhất. Hãy bắt đầu bằng vài skill giúp hệ thống ổn định hơn, kiểm chứng được hơn, rồi mới mở rộng sang tự động hóa mạnh hơn.
Vì sao skill quan trọng
Trong Hermes, skill không chỉ là một prompt mẫu. Skill tốt thường đóng vai trò như một quy trình nhỏ có thể tái sử dụng:
- biết khi nào nên dùng
- biết gọi công cụ nào
- có checklist an toàn
- có tiêu chuẩn đầu ra
- giảm việc phải giải thích lại cùng một workflow nhiều lần
Điểm hay là skill giúp agent làm việc giống một operator có quy trình hơn là một chatbot phản ứng theo từng câu lệnh rời rạc.
Nhưng điểm rủi ro cũng nằm ở đó: skill dở, quá rộng, hoặc thiếu ranh giới sẽ làm agent tự tin làm sai nhanh hơn.
Nhóm skill nên ưu tiên trước
1. Skill đọc và tóm tắt nguồn
Đây thường là nhóm có lợi tức cao nhất. Một skill tốt cho bài viết, tài liệu, issue, Reddit thread, YouTube transcript hoặc changelog có thể giúp anh em biến thông tin thô thành ghi chú dùng được.
Nên có các bước tối thiểu:
- lấy nguồn gốc và ngày truy cập
- tách claim chính khỏi ý kiến cá nhân
- ghi rõ điểm chưa chắc chắn
- trích link nguồn
- kết thúc bằng phần “có thể hành động gì tiếp”
Nếu cộng đồng hoặc team của anh em thường phải theo dõi tin AI, changelog model, repo mới, tài liệu API, đây là skill nên có sớm.
2. Skill kiểm tra trước khi chạy lệnh
Với các workflow có shell, file, API, GitHub hoặc hệ thống production, mình thích có một skill kiểu “preflight”. Nó không làm thay mình toàn bộ công việc, nhưng bắt agent dừng lại để kiểm tra rủi ro.
Checklist nên gồm:
- lệnh có ghi/xóa/sửa gì không
- có đụng file ngoài workspace không
- có cần backup hoặc dry-run không
- có token, key, thông tin riêng tư trong output không
- sau khi chạy sẽ kiểm chứng bằng cách nào
Nhóm này nghe không hào nhoáng, nhưng là nền cho mọi tự động hóa dài hơi.
3. Skill làm việc với GitHub hoặc mã nguồn
Nếu anh em dùng Hermes cho coding, một skill GitHub/code review có thể tiết kiệm rất nhiều thời gian. Nhưng nên bó hẹp rõ:
- đọc issue và tái hiện yêu cầu
- tìm file liên quan
- đề xuất patch nhỏ
- chạy test hoặc linter tối thiểu
- tóm tắt diff và rủi ro còn lại
Đừng để skill coding mặc định “sửa mọi thứ thấy được”. Với agent, phạm vi nhỏ thường đáng tin hơn phạm vi lớn.
4. Skill quản lý memory và project log
Memory mạnh nhưng cũng dễ lộn xộn. Một skill chuyên cho việc ghi nhớ nên ép agent phân loại trước khi lưu:
- đây là sở thích lâu dài hay chỉ là thông tin phiên hiện tại
- có nên lưu vào memory không, hay chỉ ghi vào project file
- nội dung có cần ngày tháng, nguồn, quyết định liên quan không
- sau này truy lại bằng từ khóa nào
Với dự án nhiều ngày, mình vẫn thích project log hoặc manifest hơn là nhét mọi thứ vào memory. Memory phù hợp cho facts và preferences; project file phù hợp cho tiến độ, nguồn, quyết định, trạng thái.
5. Skill tự động hóa trình duyệt hoặc desktop có rào chắn
Đây là nhóm rất hấp dẫn: đặt lịch, điền form, thao tác dashboard, lấy dữ liệu từ web app nội bộ. Nhưng cũng là nhóm cần ranh giới chặt.
Một skill tốt nên quy định rõ:
- chỉ đọc hay được phép ghi
- khi nào phải xin xác nhận trước khi submit
- không xử lý tiền, pháp lý, nhân sự, hoặc dữ liệu nhạy cảm nếu chưa có phê duyệt
- luôn chụp trạng thái hoặc ghi lại URL/kết quả sau thao tác
Với browser automation, thành công không chỉ là “click được”, mà là biết khi nào không nên click tiếp.
Cách đánh giá một skill có đáng giữ không
Mình dùng bốn câu hỏi đơn giản:
- Skill này có dùng lại ít nhất vài lần mỗi tháng không?
- Nó có giảm lỗi hoặc giảm thời gian thật không?
- Nó có ranh giới rõ về quyền hạn và dữ liệu không?
- Nếu agent dùng sai skill, hậu quả có được giới hạn không?
Nếu câu trả lời là không, skill đó có thể chỉ là prompt rời rạc hoặc ghi chú tạm, chưa cần đưa vào “bộ skill chính”.
Một cấu trúc skill gọn
Khi tự viết skill, mình sẽ giữ nó ngắn và có cấu trúc như sau:
# Tên skill
Dùng khi:
- tình huống A
- tình huống B
Không dùng khi:
- tình huống rủi ro X
- cần phê duyệt Y
Quy trình:
1. Kiểm tra đầu vào
2. Thu thập nguồn
3. Thực hiện bước nhỏ nhất
4. Kiểm chứng
5. Báo kết quả và rủi ro
Tiêu chuẩn đầu ra:
- link hoặc file đã tạo
- test/kiểm chứng đã chạy
- việc còn mở
Điểm quan trọng là phần “không dùng khi”. Nhiều skill chỉ ghi cách làm, nhưng không ghi ranh giới. Với agent, ranh giới đôi khi quan trọng hơn hướng dẫn.
Gợi ý cho người mới
Nếu mới bắt đầu, mình sẽ không cài 30 skill một lúc. Một bộ khởi đầu hợp lý hơn là:
- một skill tóm tắt nguồn
- một skill GitHub/code hoặc tài liệu, nếu anh em làm kỹ thuật
- một skill preflight cho lệnh và thay đổi file
- một skill memory/project log
- một skill browser automation chỉ đọc hoặc có xác nhận trước khi ghi
Sau đó, mỗi khi có một workflow lặp lại ba lần, hãy cân nhắc biến nó thành skill. Còn nếu mới làm một lần, cứ để nó là checklist trong project file đã.
Kết luận
Tin hay ở đây là cộng đồng Hermes đang bắt đầu hỏi đúng câu hỏi: không chỉ “agent làm được gì”, mà là “nên đóng gói năng lực đó thành quy trình nào”.
Skill tốt không làm agent tự do hơn một cách mù quáng. Skill tốt làm agent có kỷ luật hơn: ít quên bước, ít vượt quyền, dễ kiểm chứng, và dễ mở rộng khi workflow đã chứng minh được giá trị.
Với mình, nguyên tắc vẫn là: skill phải phục vụ workflow thật, không phải trang trí cho hệ thống. Xây ít nhưng chắc trước, rồi để nhu cầu thực tế quyết định skill tiếp theo.
Top comments (0)