2,465 ਜਨਤਕ ਤੌਰ 'ਤੇ ਸੂਚੀਬੱਧ AI-agent “skills” ਦੇ ਇੱਕ ਤਾਜ਼ਾ ਆਡਿਟ ਵਿੱਚ ਪਾਇਆ ਗਿਆ ਹੈ ਕਿ ਅੱਧੇ ਤੋਂ ਵੱਧ ਪ੍ਰਕਾਸ਼ਿਤ ਸਪੈਸੀਫਿਕੇਸ਼ਨ (specification) ਦੀ ਉਲੰਘਣਾ ਕਰਦੇ ਹਨ, ਅਤੇ 7.8 ਪ੍ਰਤੀਸ਼ਤ ਨੂੰ ਤਾਂ ਇੱਕ ਏਜੰਟ ਦੁਆਰਾ ਚੁਣਿਆ ਵੀ ਨਹੀਂ ਜਾ ਸਕਦਾ ਕਿਉਂਕਿ ਉਹਨਾਂ ਵਿੱਚ ਲੋੜੀਂਦਾ ਮੈਟਾਡਾਟਾ (metadata) ਨਹੀਂ ਹੈ। ਇਹ ਖ਼ਰਾਬੀਆਂ ਕਿਸੇ ਵੀ ਅਜਿਹੇ ਸਿਸਟਮ ਦੀ ਭਰੋਸੇਯੋਗਤਾ ਲਈ ਖ਼ਤਰਾ ਹਨ ਜੋ ਆਪਣੇ ਆਪ ਇਹਨਾਂ skills ਨੂੰ ਲੱਭਦੇ ਅਤੇ ਲੋਡ ਕਰਦੇ ਹਨ।
Why the audit matters
ਏਜੰਟ-ਸਕਿੱਲ ਰਜਿਸਟਰੀਆਂ (Agent-skill registries) ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਮੁੜ ਵਰਤੋਂ ਯੋਗ ਸਮਰੱਥਾਵਾਂ—ਕੋਡ ਪੈਕੇਜ ਜੋ ਇੱਕ ਆਟੋਨੋਮਸ ਏਜੰਟ ਮੰਗ 'ਤੇ ਵਰਤ ਸਕਦਾ ਹੈ—ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀਆਂ ਹਨ। ਇੱਕ ਏਜੰਟ ਰਜਿਸਟਰੀ ਨੂੰ ਸਕੈਨ ਕਰਦਾ ਹੈ, ਹਰੇਕ skill ਦੇ YAML frontmatter (ਸਟ੍ਰਕਚਰਡ ਟੈਕਸਟ ਦਾ ਇੱਕ ਛੋਟਾ ਹਿੱਸਾ ਜਿਸ ਵਿੱਚ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਨਾਮ ਅਤੇ ਵੇਰਵਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ) ਨੂੰ ਪੜ੍ਹਦਾ ਹੈ, ਅਤੇ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਉਹ skill ਉਸਦੇ ਟੀਚਿਆਂ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੈ। ਜੇਕਰ frontmatter ਗੁੰਮ ਹੈ ਜਾਂ ਗਲਤ ਰੂਪ ਵਿੱਚ ਹੈ, ਤਾਂ ਉਹ skill ਏਜੰਟ ਦੇ ਮੀਨੂ ਤੋਂ ਗਾਇਬ ਹੋ ਜਾਂਦੀ ਹੈ। ਇੱਕ ਅਜਿਹੀ ਦੁਨੀਆ ਵਿੱਚ ਜਿੱਥੇ ਆਟੋਨੋਮਸ ਏਜੰਟ ਮੀਟਿੰਗਾਂ ਤੈਅ ਕਰਦੇ ਹਨ, ਸਰਵਰਾਂ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਸੁਲਝਾਉਂਦੇ ਹਨ, ਅਤੇ ਹੋਰ ਬਹੁਤ ਕੁਝ ਕਰਦੇ ਹਨ, ਇੱਕ ਟੁੱਟੀ ਹੋਈ skill ਪੂਰੇ ਕੰਮ ਦੇ ਪ੍ਰਵਾਹ (workflow) ਨੂੰ ਵਿਗਾੜ ਦਿੰਦੀ ਹੈ।
What the numbers reveal
- 57.8% skills ਵਿੱਚ ਘੱਟੋ-ਘੱਟ ਇੱਕ spec ਉਲੰਘਣਾ ਹੈ।
- 29.2% ਅਜਿਹਾ ਨਾਮ ਦੱਸਦੇ ਹਨ ਜੋ ਰਜਿਸਟਰੀ slug (URL identifier) ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ।
- 18.1% ਵਿੱਚ ਟੁੱਟੇ ਹੋਏ ਪੈਕੇਜ ਪਾਥ ਜਾਂ ਡੈੱਡ ਲਿੰਕ ਹਨ।
- 7.8% (192 skills) ਵਿੱਚ ਕੋਈ YAML frontmatter ਨਹੀਂ ਹੈ, ਜਿਸ ਕਾਰਨ ਉਹ ਬਿਨਾਂ ਨਾਮ ਅਤੇ ਵੇਰਵੇ ਦੇ ਰਹਿ ਜਾਂਦੇ ਹਨ।
- 3.8% ਅਜਿਹੇ absolute file paths ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ ਜੋ ਸਿਰਫ਼ ਲੇਖਕ ਦੀ ਮਸ਼ੀਨ 'ਤੇ ਮੌਜੂਦ ਹਨ।
- 2.4%
allowed-toolsਫੀਲਡ ਦੀ ਦੁਰਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਇਹ ਏਜੰਟਾਂ ਲਈ ਅਣਪੜ੍ਹਨਯੋਗ ਹੋ ਜਾਂਦੀ ਹੈ। - 2.1% environment variables ਰਾਹੀਂ API keys ਨੂੰ ਪ੍ਰਗਟ ਕਰਦੇ ਹਨ, ਜੋ ਕਿ ਸੁਰੱਖਿਆ ਦੇ ਪੱਖੋਂ ਇੱਕ ਵੱਡਾ ਖ਼ਤਰਾ ਹੈ।
- 1.3% ਉਹਨਾਂ ਨੂੰ ਡਿਕਲੇਅਰ ਕੀਤੇ ਬਿਨਾਂ ਬਾਹਰੀ command-line tools ਨੂੰ ਕਾਲ ਕਰਦੇ ਹਨ, ਜੋ ਕਿ portability ਨਿਯਮ ਦੀ ਉਲੰਘਣਾ ਹੈ।
Portability ਸਭ ਤੋਂ ਵੱਧ ਵਾਰ ਸਾਹਮਣੇ ਆਉਂਦੀ ਹੈ। /home/USER/.local/bin/tool ਵਰਗਾ ਇੱਕ absolute path ਉਸ ਡਿਵੈਲਪਰ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ ਜਿਸਨੇ skill ਲਿਖੀ ਹੈ, ਪਰ ਬਾਕੀ ਹਰ ਉਪਭੋਗਤਾ ਲਈ ਅਸਫਲ ਰਹਿੰਦਾ ਹੈ, ਜਿਸ ਨਾਲ runtime errors ਪੈਦਾ ਹੁੰਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ static checks ਕਦੇ ਨਹੀਂ ਫੜ ਸਕਦੇ।
A deeper dive: the openclaw case
ਆਡਿਟ ਵਿੱਚ openclaw ਰੈਪੋਜ਼ਟਰੀ ਵਿੱਚ ਬੰਨ੍ਹੇ ਗਏ 46 skills ਦੀ ਵੀ ਜਾਂਚ ਕੀਤੀ ਗਈ। ਗਲਤ ਅਲਾਰਮਾਂ ਨੂੰ ਰੋਕਣ ਲਈ ਟੈਸਟਿੰਗ ਸਕ੍ਰਿਪਟ ਨੂੰ ਸੁਧਾਰਨ ਤੋਂ ਬਾਅਦ, ਰਿਵਿਊਰ ਨੇ 59 ਅਸਲ ਖ਼ਰਾਬੀਆਂ ਲੱਭੀਆਂ—ਇਹ ਇੱਕ ਯਾਦ ਦਿਵਾਉਂਦਾ ਹੈ ਕਿ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹਮਲਾਵਰ linters ਉਲਟ ਪ੍ਰਭਾਵ ਵੀ ਪਾ ਸਕਦੇ ਹਨ। ਜਦੋਂ ਕੋਈ ਟੂਲ ਬਹੁਤ ਜ਼ਿਆਦਾ ਨਿਰਪੱਖ ਮੁੱਦਿਆਂ ਨੂੰ ਫਲੈਗ ਕਰਦਾ ਹੈ, ਤਾਂ ਡਿਵੈਲਪਰ ਇਸਦੀ ਵਰਤੋਂ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਅਸਲ ਸਮੱਸਿਆਵਾਂ ਨਜ਼ਰਅੰਦਾਜ਼ ਹੋ ਜਾਂਦੀਆਂ ਹਨ।
openclaw ਦੇ ਦੋ ਖ਼ਰਾਬੀਆਂ ਅਜਿਹੀਆਂ ਫਾਈਲਾਂ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀਆਂ ਸਨ ਜੋ ਰੈਪੋਜ਼ਟਰੀ ਵਿੱਚ ਹੁਣ ਮੌਜੂਦ ਨਹੀਂ ਹਨ। ਮੇਨਟੇਨਰ ਨੇ ਇੱਕ ਫਿਕਸ ਮਰਜ ਕੀਤਾ ਜੋ ਗੁੰਮ ਹੋਏ ਰੈਫਰੈਂਸਾਂ ਨੂੰ ਬਹਾਲ ਕਰਦਾ ਹੈ, ਜੋ ਇਹ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕਿਵੇਂ ਇੱਕ ਸਿੰਗਲ pull request ਇੱਕ ਟੁੱਟੀ ਹੋਈ dependency chain ਨੂੰ ਸਾਫ਼ ਕਰ ਸਕਦੀ ਹੈ।
Developer reactions
ਆਡਿਟਰ ਨੇ ਅਸਲ skill ਰੈਪੋਜ਼ਟਰੀਆਂ 'ਤੇ issues ਖੋਲ੍ਹੇ। ਇੱਕ ਰਿਪੋਰਟ ਨੂੰ ਰੱਦ ਕਰ ਦਿੱਤਾ ਗਿਆ ਸੀ; ਮੇਨਟੇਨਰ ਨੇ ਦਲੀਲ ਦਿੱਤੀ ਕਿ "broken" ਦਾ ਫੈਸਲਾ ਅਸਲ runtime ਵਿਵਹਾਰ ਦੁਆਰਾ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ static file inspection ਦੁਆਰਾ। ਆਡਿਟਰ ਇਸ ਗੱਲ ਨਾਲ ਸਹਿਮਤ ਹੋਇਆ ਕਿ brokenness ਦੀ ਇੱਕ ਸਖ਼ਤ ਪਰਿਭਾਸ਼ਾ ਇਸ ਗੱਲ ਦੇ ਅਨੁਕੂਲ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਕਿ skill ਅਸਲ ਵਿੱਚ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ। ਇੱਕ ਹੋਰ issue ਨੂੰ ਸਵੀਕਾਰ ਕਰ ਲਿਆ ਗਿਆ ਸੀ, ਅਤੇ ਇਸਦਾ ਸਬੰਧਤ ਫਿਕਸ ਹੁਣ ਲਾਈਵ ਹੈ।
Who stands to gain—or lose
- ਏਜੰਟ ਅਤੇ ਅੰਤ-ਉਪਭੋਗਤਾ (end-users) ਨੂੰ ਉਦੋਂ ਵਧੇਰੇ ਸੁਚਾਰੂ ਅਤੇ ਅਨੁਮਾਨਿਤ ਵਿਵਹਾਰ ਮਿਲਦਾ ਹੈ ਜਦੋਂ ਰਜਿਸਟਰੀ ਵਿੱਚ ਸਿਰਫ਼ ਅਨੁਕੂਲ (compliant) ਅਤੇ portable skills ਹੁੰਦੀਆਂ ਹਨ।
- Skill authors
ਜਨਤਕ ਤੌਰ 'ਤੇ ਸੂਚੀਬੱਧ ਜ਼ਿਆਦਾਤਰ AI-ਏਜੰਟ ਹੁਨਰ ਬੁਨਿਆਦੀ ਅਨੁਕੂਲਤਾ ਜਾਂਚਾਂ ਵਿੱਚ ਅਸਫਲ ਰਹਿੰਦੇ ਹਨ, ਅਤੇ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਹਿੱਸਾ ਤਾਂ ਬਿਲਕੁਲ ਵੀ ਚੁਣਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ। ਇਹ ਨਤੀਜੇ ਸਖ਼ਤ ਵੈਲੀਡੇਸ਼ਨ, ਬਿਹਤਰ ਲਿੰਟਿੰਗ ਟੂਲਜ਼, ਅਤੇ ਇੱਕ ਅਜਿਹੀ ਕਮਿਊਨਿਟੀ ਸੱਭਿਆਚਾਰ ਦੀ ਸਪੱਸ਼ਟ ਲੋੜ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ ਜੋ ਪ੍ਰਕਾਸ਼ਨ ਲਈ ਸਪੈਕ (spec) ਦੀ ਪਾਲਣਾ ਨੂੰ ਇੱਕ ਪੂਰਵ-ਸ਼ਰਤ ਵਜੋਂ ਮੰਨਦੀ ਹੈ। ਜਦੋਂ ਤੱਕ ਉਹ ਸੁਰੱਖਿਆ ਉਪਾਅ ਲਾਗੂ ਨਹੀਂ ਕੀਤੇ ਜਾਂਦੇ, ਏਜੰਟ ਕਮਜ਼ੋਰ ਅਤੇ ਗੈਰ-ਪੋਰਟੇਬਲ ਹੁਨਰਾਂ ਕਾਰਨ ਮੁਸ਼ਕਲਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਦੇ ਰਹਿਣਗੇ।