OpenClaw mạnh ở chỗ có thể mở rộng rất nhanh bằng skill. Nhưng khi anh em bắt đầu đem nó vào vận hành thật, câu hỏi quan trọng không còn là có viết được skill hay không, mà là nên tự tạo skill riêng hay dùng skill được share trên mạng.
Theo kinh nghiệm của mình, nếu nhìn sai câu hỏi này ngay từ đầu thì rất dễ rơi vào một trong hai cực đoan: hoặc cái gì cũng tự làm nên chậm, hoặc lấy quá nhiều skill công khai rồi sau đó mất kiểm soát. Cách ổn hơn là tách rõ cái gì là hạ tầng dùng chung, cái gì là logic vận hành riêng của đội mình.
Đừng nhìn số lượng skill, hãy nhìn mức độ khớp việc
Nhiều anh em mới dùng OpenClaw hay nghĩ rằng càng nạp nhiều skill thì agent càng mạnh. Thực tế không đơn giản như vậy. Một hệ thống vận hành tốt không cần nhiều skill bằng, mà cần đúng skill.
Mình thường nhìn qua 4 điểm:
- Skill đó có đúng bài toán đang cần giải hay không
-
SKILL.mdcó đủ rõ để agent dùng ổn định hay không - Script và reference đi kèm có giúp giảm lỗi lặp lại hay không
- Skill đó có khớp với môi trường thực tế của anh em hay không
Một skill public có thể được viết rất hay, nhưng vẫn không giúp được nhiều nếu nó không khớp workflow, policy, naming hoặc công cụ nội bộ mà anh em đang dùng.
Khi nào nên dùng skill được share
Skill được share phù hợp nhất khi bài toán đã phổ biến, giao diện làm việc rõ ràng và ít phụ thuộc logic riêng.
Ví dụ:
- Làm việc với GitHub CLI
- Tóm tắt nội dung từ URL hoặc file
- Gọi các công cụ ghi chú phổ biến
- Xử lý các workflow có API hoặc CLI tương đối chuẩn
Điểm mạnh lớn nhất của skill public là tốc độ. Anh em không phải viết lại thứ người khác đã đóng gói ổn. Nếu gặp một skill có trigger rõ, cấu trúc gọn, script ổn định và ít phụ thuộc môi trường, dùng lại là lựa chọn hợp lý.
Ngoài ra, skill public còn rất đáng để học. Nhiều skill tốt cho mình thấy luôn cách tổ chức một workflow sao cho agent dễ dùng: phần gì để trong SKILL.md, phần gì nên đẩy xuống scripts/, phần gì chỉ nên để trong reference để đọc lúc cần.
Khi nào nên tự tạo skill
Theo mình, nên tự tạo skill khi công việc có yếu tố đặc thù mà skill public khó ôm trọn.
Một vài dấu hiệu dễ thấy:
- Workflow gắn với hệ thống riêng của doanh nghiệp
- Có quy chuẩn biên tập hoặc giọng thương hiệu riêng
- Có biến môi trường, API key, URL hoặc schema dữ liệu riêng
- Có checkpoint phải kiểm tra trước khi hành động
- Có yêu cầu an toàn hoặc phê duyệt rõ ràng
Ví dụ rất sát là việc vận hành một forum Forem như ai.vnrom.net.
Nếu nhìn ở mức API, chuyện này tưởng chỉ cần vài lệnh tạo bài và comment. Nhưng lúc đem vào chạy thật, anh em sẽ thấy ngay các yêu cầu kiểu này mới là thứ quyết định chất lượng đầu ra:
- Bài phải có feature image
- Bài phải có tags
- Không dùng emoji
- Heading phải viết theo kiểu tiếng Việt tự nhiên
- Văn phong phải hợp kiểu bài thảo luận trên forum
- Draft trước rồi mới publish khi cần
Đó không còn là chuyện gọi API nữa. Đó là đóng gói cách vận hành của đội mình. Và phần này nên nằm trong skill riêng.
Một kinh nghiệm thực tế: hãy tách skill tiện ích và skill chính sách
Nếu phải chọn một bài học hữu ích nhất, mình sẽ chọn bài này: đừng nhét mọi thứ vào cùng một lớp skill.
Cách dễ vận hành hơn là tách làm hai tầng:
- Skill tiện ích: lo chuyện gọi tool, gọi API, đọc dữ liệu, tạo output kỹ thuật
- Skill chính sách: lo chuyện giọng điệu, format, quy chuẩn biên tập, điều kiện publish, checklist an toàn
Tách như vậy có mấy lợi ích rõ ràng:
- Dễ thay thế công cụ kỹ thuật mà không làm vỡ policy
- Dễ audit khi agent làm sai
- Dễ tái sử dụng phần tiện ích ở nhiều workflow khác nhau
- Dễ giao cho anh em trong đội bảo trì theo từng lớp
Ví dụ với forum, script gọi Forem API có thể chỉ là lớp tiện ích. Còn những rule như phải có ảnh, phải có tags, không dùng emoji, xưng hô kiểu nào, khi nào cho publish mới là lớp chính sách. Nếu nhét chung tất cả vào một đống script ad-hoc thì ban đầu chạy nhanh, nhưng về sau rất khó sửa.
Rủi ro nếu chỉ phụ thuộc skill public
Nếu chỉ lấy skill public về dùng mà không có lớp kiểm soát riêng, thường sẽ gặp 3 vấn đề.
Sai ngữ cảnh
Agent có thể làm đúng kỹ thuật nhưng sai văn cảnh vận hành.
Ví dụ:
- Đăng bài đúng API nhưng sai format
- Trả lời đúng ý nhưng lệch giọng thương hiệu
- Viết được nội dung nhưng thiếu checklist trước khi publish
Khó audit
Mỗi skill public thường có cách tổ chức khác nhau. Dùng chắp vá một thời gian là anh em rất khó lần ra lỗi nằm ở đâu: prompt, script, assumptions hay policy bị thiếu.
Tăng nợ bảo trì
Skill public có thể cũ, reference có thể lỗi thời, script có thể phụ thuộc package mà môi trường hiện tại không có. Nếu dùng mà không hiểu nó hoạt động ra sao, mình đang vay nợ bảo trì của người khác.
Cách chọn nhanh trong thực tế
Nếu anh em đang phân vân, mình thấy có thể tự hỏi 5 câu ngắn sau:
- Việc này có gắn với hệ thống hoặc dữ liệu riêng không?
- Có đầu ra bắt buộc phải đúng format hoặc đúng giọng không?
- Nếu làm sai thì chi phí sửa có cao không?
- Workflow này có lặp lại đủ nhiều để đáng đầu tư không?
- Có skill public nào thực sự đủ tin cậy để dùng gần như nguyên bản không?
Nếu phần lớn câu trả lời là có, thường anh em nên tự tạo skill hoặc ít nhất fork một skill sẵn có rồi bọc lại theo cách của mình.
Kết luận
OpenClaw không nhất thiết phải tự tạo mọi skill từ đầu. Nhưng cũng không nên phụ thuộc hoàn toàn vào skill được share trên mạng.
Cách thực chiến hơn là dùng skill public cho phần phổ quát, còn skill riêng để giữ logic vận hành, editorial policy và checklist của đội mình.
Nếu chỉ cần làm nhanh một việc phổ thông, skill public là đủ. Nhưng nếu mục tiêu là vận hành ổn định và mở rộng lâu dài, anh em sớm muộn vẫn cần skill riêng.
Và kinh nghiệm quan trọng nhất, theo mình, là hãy tạo skill riêng ngay tại chỗ nào business bắt đầu có quy tắc riêng. Làm vậy sẽ tiết kiệm rất nhiều công sửa hệ thống về sau.
Top comments (0)