Một cuộc kiểm toán mới đối với 2.465 "kỹ năng" (skills) của AI-agent được niêm yết công khai cho thấy hơn một nửa vi phạm các thông số kỹ thuật đã công bố, và 7,8% thậm chí không thể được agent lựa chọn do thiếu siêu dữ liệu (metadata) cần thiết. Những lỗi này đe dọa đến độ tin cậy của bất kỳ hệ thống nào tự động khám phá và tải các kỹ năng này.
Tại sao cuộc kiểm toán này lại quan trọng
Các danh mục kỹ năng của agent (agent-skill registries) cho phép các nhà phát triển công bố các khả năng có thể tái sử dụng—đó là các gói mã nguồn mà một agent tự hành có thể gọi theo yêu cầu. Một agent sẽ quét danh mục, đọc phần YAML frontmatter của mỗi kỹ năng (một khối văn bản có cấu trúc nhỏ phải chứa ít nhất tên và mô tả), và quyết định xem kỹ năng đó có phù hợp với mục tiêu của nó hay không. Nếu frontmatter bị thiếu hoặc sai định dạng, kỹ năng đó sẽ biến mất khỏi menu của agent. Trong một thế giới nơi các agent tự hành lên lịch họp, khắc phục sự cố máy chủ và nhiều việc khác, một kỹ năng bị lỗi sẽ làm gián đoạn toàn bộ quy trình làm việc.
Những con số tiết lộ điều gì
- 57,8% kỹ năng có ít nhất một vi phạm thông số kỹ thuật.
- 29,2% liệt kê tên không khớp với slug của danh mục (định danh URL).
- 18,1% chứa các đường dẫn gói bị lỗi hoặc các liên kết chết.
- 7,8% (192 kỹ năng) hoàn toàn không có YAML frontmatter, khiến chúng không có tên và không có mô tả.
- 3,8% nhúng các đường dẫn tệp tuyệt đối chỉ tồn tại trên máy của tác giả.
- 2,4% sử dụng sai trường
allowed-tools, khiến agent không thể đọc được. - 2,1% để lộ các khóa API thông qua các biến môi trường, một dấu hiệu cảnh báo bảo mật.
- 1,3% gọi các công cụ dòng lệnh bên ngoài mà không khai báo chúng, vi phạm quy tắc về tính di động (portability).
Tính di động là vấn đề xuất hiện thường xuyên nhất. Một đường dẫn tuyệt đối như /home/USER/.local/bin/tool có thể hoạt động với nhà phát triển đã viết kỹ năng đó nhưng sẽ thất bại với mọi người dùng khác, gây ra các lỗi thực thi (runtime errors) mà các bước kiểm tra tĩnh (static checks) không bao giờ phát hiện được.
Phân tích sâu hơn: trường hợp openclaw
Cuộc kiểm toán cũng đã xem xét 46 kỹ năng được đóng gói trong kho lưu trữ openclaw. Sau khi tinh chỉnh kịch bản kiểm thử để loại bỏ các cảnh báo giả, người kiểm tra đã phát hiện ra 59 lỗi thực sự—một lời nhắc nhở rằng các công cụ linter quá khắt khe có thể phản tác dụng. Khi một công cụ gắn cờ quá nhiều vấn đề vô hại, các nhà phát triển sẽ ngừng sử dụng nó, và các vấn đề thực sự sẽ bị bỏ lọt.
Hai trong số các lỗi của openclaw chỉ ra các tệp không còn tồn tại trong kho lưu trữ. Người duy trì (maintainer) đã hợp nhất một bản sửa lỗi giúp khôi phục các tham chiếu bị thiếu, cho thấy một pull request duy nhất có thể dọn dẹp một chuỗi phụ thuộc (dependency chain) bị lỗi như thế nào.
Phản ứng của các nhà phát triển
Người kiểm toán đã mở các issue trên các kho lưu trữ kỹ năng gốc. Một báo cáo đã bị từ chối; người duy trì lập luận rằng trạng thái "bị lỗi" nên được đánh giá dựa trên hành vi thực thi thực tế, chứ không phải bằng việc kiểm tra tệp tĩnh. Người kiểm toán đồng ý rằng một định nghĩa nghiêm ngặt về lỗi phải phù hợp với cách kỹ năng đó thực thi trong thực tế. Một issue khác đã được chấp nhận, và bản sửa lỗi tương ứng hiện đã được triển khai.
Ai là người được lợi—hoặc chịu thiệt
- Các agent và người dùng cuối sẽ được tận hưởng hành vi mượt mà và dễ dự đoán hơn khi danh mục chỉ chứa các kỹ năng tuân thủ và có tính di động.
- Các tác giả kỹ năng sẽ có các quy tắc xác thực rõ ràng hơn để phát hiện lỗi trước khi công bố, giúp giảm bớt việc trao đổi qua lại trong quá trình phân loại issue.
- Các nhà vận hành danh mục phải xây dựng hoặc tích hợp các quy trình xác thực nghiêm ngặt hơn; nếu không, hệ sinh thái sẽ có nguy cơ làm xói mòn lòng tin.
Việc xác thực lỏng lẻo khuyến khích các bản nộp theo kiểu "làm cho xong" (quick-and-dirty), điều này có thể làm hỏng các agent trong môi trường production, tiềm ẩn nguy cơ gây ra thời gian ngừng hoạt động tốn kém hoặc các lỗ hổng bảo mật.
Quan điểm ngược lại: liệu tất cả các vi phạm đều nghiêm trọng?
Một số người lập luận rằng một số "lỗi" nhất định là vô hại. Một cái tên không khớp có thể không ảnh hưởng đến một agent chọn kỹ năng bằng slug thay vì bằng tên hiển thị. Việc đọc các khóa API từ môi trường có thể là một lựa chọn thiết kế có chủ đích cho việc phát triển cục bộ. Tuy nhiên, các tỷ lệ phần trăm trong cuộc kiểm toán coi bất kỳ sự sai lệch nào so với thông số kỹ thuật là một vi phạm, điều này có thể phóng đại tác động thực tế của một số vấn đề.
Những điều cần theo dõi tiếp theo
- Các công cụ linter cải tiến giúp phân biệt các lỗi di động thực sự với các điểm khác biệt vô hại.
- Các hook xác thực phía danh mục để từ chối các bản nộp thiếu frontmatter bắt buộc hoặc chứa các đường dẫn tuyệt đối.
- Các cuộc kiểm toán do cộng đồng dẫn dắt nhằm làm lộ ra các lỗi ẩn trước khi chúng đến với các agent trong môi trường production.
- Các bản sửa đổi thông số kỹ thuật tiềm năng nhằm làm rõ các trường mơ hồ như
allowed-toolsvà định nghĩa việc sử dụng các biến môi trường một cách chấp nhận được.
Làn sóng công cụ tiếp theo có khả năng sẽ nhúng các bước kiểm tra này vào các quy trình tích hợp liên tục (continuous-integration pipelines), biến việc tuân thủ từ một bước bổ sung thủ công thành một cổng kiểm soát tự động.
Bài học rút ra
Phần lớn các kỹ năng của AI-agent được niêm yết công khai không vượt qua được các bước kiểm tra tuân thủ cơ bản, và một tỷ lệ đáng kể thậm chí không thể được lựa chọn được. Những phát hiện này nhấn mạnh nhu cầu rõ ràng về việc xác thực nghiêm ngặt hơn, các công cụ linting tốt hơn, và một văn hóa cộng đồng coi việc tuân thủ đặc tả (spec) là điều kiện tiên quyết để xuất bản. Cho đến khi các cơ chế bảo vệ đó được thiết lập, các agent sẽ tiếp tục vấp phải những kỹ năng kém bền vững và thiếu tính di động.