ਤੁਹਾਡਾ ਪਹਿਲਾ ਏਜੰਟ ਵਰਕਫਲੋ ਇੱਕ ਪ੍ਰੋਂਪਟ ਅਤੇ ਕੁਝ ਟੂਲਜ਼ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ। ਇਹ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਇਹ ਆਰਡਰ ਦੀ ਸਥਿਤੀ (order status) ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ। ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਤੁਸੀਂ ਇਸਨੂੰ ਲਾਂਚ ਕਰ ਦਿੰਦੇ ਹੋ।
ਫਿਰ ਉਤਪਾਦ (product) ਵਧਦਾ ਹੈ। ਸੇਲਜ਼ ਵਿਭਾਗ ਇੱਕ CRM ਅਪਡੇਟਰ ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ ਜੋ ਮੀਟਿੰਗ ਨੋਟਸ ਨੂੰ ਸਿੰਕ ਕਰਦਾ ਹੈ। ਸਪੋਰਟ ਨੂੰ ਇੱਕ ਰਿਫੰਡ ਵਰਕਫਲੋ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜੋ ਤਿੰਨ ਅੰਦਰੂਨੀ ਪ੍ਰਣਾਲੀਆਂ (internal systems) ਨਾਲ ਜੁੜਿਆ ਹੋਵੇ। ਇੰਜੀਨੀਅਰਿੰਗ ਵੈਂਡਰ ਫਾਰਮ ਭਰਨ ਲਈ ਬ੍ਰਾਊਜ਼ਰ ਐਕਸ਼ਨ ਜੋੜਦੀ ਹੈ। ਹਰ ਬੇਨਤੀ ਛੋਟੀ ਲੱਗਦੀ ਹੈ। ਹਰ ਇੱਕ ਲਈ ਆਪਣੀ ਵੱਖਰੀ ਪ੍ਰੋਂਪਟ ਫਾਈਲ, ਆਪਣਾ ਵੱਖਰਾ Slack ਥ੍ਰੈਡ ਅਤੇ ਆਪਣਾ ਵੱਖਰਾ "quick fix" ਹੁੰਦਾ ਹੈ। ਛੇ ਮਹੀਨਿਆਂ ਬਾਅਦ, ਤੁਹਾਡਾ ਏਜੰਟ ਹੁਣ ਇੱਕ ਪ੍ਰਣਾਲੀ ਨਹੀਂ ਰਿਹਾ। ਇਹ ਕਾਪੀ ਕੀਤੇ ਪ੍ਰੋਂਪਟਸ, ਲੁਕਵੇਂ ਕਾਰੋਬਾਰੀ ਨਿਯਮਾਂ (business rules) ਅਤੇ ਪੁਰਾਣੇ ਚੈਟ ਥ੍ਰੈਡਾਂ ਵਿੱਚ ਲਏ ਗਏ ਫੈਸਲਿਆਂ ਦਾ ਇੱਕ ਖਿੰਡਿਆ ਹੋਇਆ ਢੇਰ ਬਣ ਜਾਂਦਾ ਹੈ ਜਿਸ ਨੂੰ ਕੋਈ ਲੱਭ ਨਹੀਂ ਸਕਦਾ। ਇਸ ਨੂੰ prompt sprawl ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਤੁਹਾਡੇ AI ਉਤਪਾਦ ਨੂੰ ਟੈਸਟ ਕਰਨਾ, ਰਿਵਿਊ ਕਰਨਾ ਮੁਸ਼ਕਲ ਬਣਾ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਭਰੋਸੇ ਨਾਲ ਰੋਲਬੈਕ (roll back) ਕਰਨਾ ਅਸੰਭਵ ਬਣਾ ਦਿੰਦਾ ਹੈ।
ਇਸਦਾ ਹੱਲ ਇੱਕ AI agent skill registry ਹੈ।
ਇੱਕ Skill ਅਸਲ ਵਿੱਚ ਕੀ ਹੁੰਦੀ ਹੈ
ਇੱਕ skill ਸਿਰਫ਼ ਇੱਕ ਫੋਲਡਰ ਵਿੱਚ ਸੇਵ ਕੀਤਾ ਗਿਆ ਪ੍ਰੋਂਪਟ ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ versioned, testable ਪੈਕੇਜ ਹੈ ਜੋ ਇਹ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਏਜੰਟ ਕੀ ਕਰਦਾ ਹੈ, ਉਹ ਕਿਹੜੇ ਟੂਲਸ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਉਸਨੂੰ ਕੀ ਕਦੇ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ। ਇਸਨੂੰ ਆਪਣੀ ਟੀਮ ਅਤੇ ਮਸ਼ੀਨ ਵਿਚਕਾਰ ਇੱਕ ਇਕਰਾਰਨਾਮੇ (contract) ਵਜੋਂ ਸਮਝੋ। ਜਦੋਂ ਕੋਈ ਏਜੰਟ ਕਿਸੇ skill ਨੂੰ ਲੋਡ ਕਰਦਾ ਹੈ, ਤਾਂ ਉਸਨੂੰ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਉਸਦੀਆਂ ਸੀਮਾਵਾਂ ਕਿੱਥੇ ਹਨ ਅਤੇ ਸਫਲਤਾ ਕਿਵੇਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ।
ਇਸ ਢਾਂਚੇ ਤੋਂ ਬਿਨਾਂ, ਹਰ ਪ੍ਰੋਂਪਟ ਇੱਕ ਛੋਟੀ, ਅਘੋਸ਼ਿਤ (undeclared) production system ਬਣ ਜਾਂਦਾ ਹੈ। ਇਸ ਵਿੱਚ ਲੁਕੀਆਂ ਹੋਈਆਂ ਇਜਾਜ਼ਤਾਂ (permissions), ਅੰਦਰੂਨੀ ਕਾਰੋਬਾਰੀ ਨਿਯਮ ਅਤੇ ਲਾਗਤ ਪ੍ਰਭਾਵ ਹੁੰਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਦਾ ਕਿਸੇ ਨੇ ਧਿਆਨ ਨਹੀਂ ਰੱਖਿਆ। ਇਹ ਅਸਲ ਉਤਪਾਦ ਤੋਂ ਦੂਰ ਹੁੰਦਾ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ product roadmap ਅੱਗੇ ਵਧ ਗਿਆ ਪਰ ਪ੍ਰੋਂਪਟ ਪਿੱਛੇ ਰਹਿ ਗਿਆ। ਸਭ ਤੋਂ ਮਾੜੀ ਗੱਲ ਇਹ ਹੈ ਕਿ ਇਸਦੀ ਕਾਪੀ ਬਣਾਈ ਜਾਂਦੀ ਹੈ। ਕੋਈ ਡੈਮੋ ਲਈ ਇਸਨੂੰ fork ਕਰਦਾ ਹੈ, ਜਾਂ ਇਸਨੂੰ ਕਿਸੇ ਨਵੇਂ microservice ਵਿੱਚ ਪੇਸਟ ਕਰ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਹੁਣ ਤੁਹਾਡੇ ਕੋਲ ਸੱਚ ਦੇ ਦੋ ਸਰੋਤ ਹਨ ਜੋ ਅੰਧੇਰੇ ਵਿੱਚ ਇੱਕ ਦੂਜੇ ਤੋਂ ਵੱਖ ਹੋ ਰਹੇ ਹਨ।
ਸਿਰਫ਼ ਪ੍ਰੋਂਪਟਸ ਕਿਉਂ ਅਸਫਲ ਹੋ ਜਾਂਦੇ ਹਨ
ਪ੍ਰੋਂਪਟਸ ਟੈਕਸਟ ਵਾਂਗ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ, ਇਸ ਲਈ ਟੀਮਾਂ ਉਹਨਾਂ ਨਾਲ configuration ਵਾਂਗ ਪੇਸ਼ ਆਉਂਦੀ ਹੈ। ਅਸਲ ਵਿੱਚ, ਉਹ ਕਿਸੇ ਦੇ ਮੰਨਣ ਨਾਲੋਂ ਕਿਤੇ ਜ਼ਿਆਦਾ code ਦੇ ਨੇੜੇ ਹਨ। ਇੱਕ production prompt ਆਮ ਤੌਰ 'ਤੇ sequencing, formatting, error handling, ਅਤੇ access control ਬਾਰੇ logic ਨੂੰ ਇਨਕੋਡ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਉਹ logic ਸਿਰਫ਼ ਕੁਦਰਤੀ ਭਾਸ਼ਾ (natural language) ਵਿੱਚ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਉਲਝਣ ਪੈਦਾ ਹੁੰਦੀ ਹੈ। ਕੀ ਏਜੰਟ ਕੋਲ CRM ਨੂੰ ਅਪਡੇਟ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਹੈ, ਜਾਂ ਪ੍ਰੋਂਪਟ ਨੇ ਸਿਰਫ਼ ਸੁਝਾਅ ਦਿੱਤਾ ਸੀ? ਜੇਕਰ billing API ਡਾਊਨ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਕੀ ਪ੍ਰੋਂਪਟ ਨੂੰ ਪਤਾ ਹੈ ਕਿ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਕਿਵੇਂ ਫੇਲ੍ਹ ਹੋਣਾ ਹੈ, ਜਾਂ ਕੀ ਇਹ ਸਫਲਤਾ ਦਾ ਕੋਈ ਗਲਤ ਸੁਨੇਹਾ (hallucinate) ਦਿਖਾਉਂਦਾ ਹੈ?
ਲਾਗਤ (Cost) ਇੱਕ ਹੋਰ ਚੁੱਪ ਰਹਿਣ ਵਾਲਾ ਕਤਲ ਕਰਨ ਵਾਲਾ ਕਾਰਕ ਹੈ। ਇੱਕ ਪ੍ਰੋਂਪਟ ਜੋ ਏਜੰਟ ਨੂੰ "ਕਦਮ-ਦਰ-ਕਦਮ ਸੋਚਣ ਅਤੇ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਖੋਜ ਕਰਨ" ਲਈ ਕਹਿੰਦਾ ਹੈ, ਉਹ ਹਰ ਇੱਕ ਰਨ 'ਤੇ tokens ਖਤਮ ਕਰ ਸਕਦਾ ਹੈ। ਜਦੋਂ ਉਸ ਪ੍ਰੋਂਪਟ ਨੂੰ ਉੱਚ-ਟ੍ਰੈਫਿਕ ਵਾਲੇ support flow ਵਿੱਚ ਕਾਪੀ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡਾ ਮਹੀਨਾਵਾਰ inference ਬਿੱਲ ਦੁੱਗਣਾ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਕਿਸੇ ਨੂੰ ਨਹੀਂ ਪਤਾ ਹੁੰਦਾ ਕਿ ਕਿਉਂ।
Drift ਉਦੋਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕਾਰੋਬਾਰ ਬਦਲਦਾ ਹੈ ਪਰ ਟੈਕਸਟ ਨਹੀਂ ਬਦਲਦਾ। ਤੁਹਾਡੀ ਰਿਫੰਡ ਨੀਤੀ ਹੁਣ ਇੱਕ ਨਿਸ਼ਚਿਤ ਸੀਮਾ ਤੋਂ ਉੱਪਰ ਮੈਨੇਜਰ ਦੀ ਮਨਜ਼ੂਰੀ ਦੀ ਮੰਗ ਕਰਦੀ ਹੈ। ਜੇਕਰ ਉਹ ਨਿਯਮ ਕਿਸੇ policy layer ਦੀ ਬਜਾਏ ਪ੍ਰੋਂਪਟ ਦੇ ਅੰਦਰ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਅਪਡੇਟ ਕਰਨ ਦੀ ਲੋੜ ਵਾਲੀਆਂ ਕਾਪੀਆਂ ਲੱਭਣ ਲਈ ਹਰ deployment ਵਿੱਚ ਖੋਜ ਕਰਨੀ ਪਵੇਗੀ। ਜੇਕਰ ਇੱਕ ਵੀ ਰਹਿ ਗਿਆ, ਤਾਂ ਤੁਹਾਡੇ ਏਜੰਟ ਅਜਿਹੀ ਪੈਸੇ ਵੰਡਣ ਲੱਗ ਜਾਣਗੇ ਜੋ ਉਹਨਾਂ ਨੂੰ ਨਹੀਂ ਦੇਣਾ ਚਾਹੀਦਾ।
ਇੱਕ Production Skill ਦੀ ਬਣਤਰ
ਜੇਕਰ ਤੁਸੀਂ ਇਸ ਉਲਝਣ ਤੋਂ ਬਚਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਹਰ skill ਨੂੰ ਇੱਕ software artifact ਵਜੋਂ ਮੰਨੋ। ਇੱਕ ਉਪਯੋਗੀ production skill ਵਿੱਚ ਸਿਰਫ਼ ਟੈਕਸਟ ਤੋਂ ਵੱਧ ਕੁਝ ਹੁੰਦਾ ਹੈ। ਇਸਨੂੰ ਲੋੜ ਹੈ:
- ਨਾਮ ਅਤੇ ਉਦੇਸ਼। "prompt_v3_final" ਨਹੀਂ, ਬਲਕਿ ਕਾਰੋਬਾਰੀ ਟੀਚੇ ਦੇ ਸਪਸ਼ਟ ਵੇਰਵੇ ਦੇ ਨਾਲ "process_standard_refund"।
- Input schema ਅਤੇ ਲੋੜੀਂਦਾ context। ਉਹ ਸਹੀ ਫੀਲਡਸ (fields) ਤੈਅ ਕਰੋ ਜਿਨ੍ਹਾਂ ਦੀ skill ਉਮੀਦ ਕਰਦੀ ਹੈ। ਕੀ ਇਸਨੂੰ user ID, conversation history, ਜਾਂ tenant identifier ਦੀ ਲੋੜ ਹੈ? ਇੱਥੇ strong typing ਏਜੰਟ ਨੂੰ ਅੰਦਾਜ਼ੇ ਲਗਾਉਣ ਤੋਂ ਰੋਕਦੀ ਹੈ।
- Tool permissions ਅਤੇ ਸੁਰੱਖਿਆ ਸੀਮਾਵਾਂ। ਸਪਸ਼ਟ ਰੂਪ ਵਿੱਚ ਸੂਚੀਬੱਧ ਕਰੋ ਕਿ skill ਕਿਹੜੇ ਟੂਲਸ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੀ ਹੈ। Retries, spending limits, ਅਤੇ rate caps 'ਤੇ guardrails ਸੈੱਟ ਕਰੋ। ਜੇਕਰ skill ਨੂੰ user deletion API ਨੂੰ ਛੂਹਣਾ ਨਹੀਂ ਚਾਹੀਦਾ, ਤਾਂ ਇਸਨੂੰ ਸਿਰਫ਼ ਲਿਖਤ ਵਿੱਚ ਹੀ ਨਹੀਂ, ਸਗੋਂ code ਵਿੱਚ ਵੀ ਦੱਸੋ।
- ਸਫਲਤਾ ਦੇ ਮਾਪਦੰਡ (Success criteria) ਅਤੇ test cases। ਇੱਕ skill ਸਿਰਫ਼ ਇਸ ਲਈ "ਕੰਮ" ਨਹੀਂ ਕਰਦੀ ਕਿਉਂਕਿ ਇਹ ਚੱਲ ਰਹੀ ਹੈ। ਤੈਅ ਕਰੋ ਕਿ output ਵਿੱਚ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇੱਕ ਰਿਫੰਡ skill ਲਈ, ਸਫਲਤਾ ਦਾ ਮਤਲਬ ਇੱਕ ਵੈਲਿਡੇਟਡ transaction record, ਭੇਜਿਆ ਗਿਆ email confirmation, ਅਤੇ ਬਣਾਇਆ ਗਿਆ audit log entry ਹੋ ਸਕਦਾ ਹੈ।
- Version history ਅਤੇ ਮਾਲਕ ਦੀ ਸਥਿਤੀ। ਕਿਸੇ ਨੂੰ ਇਸਦਾ ਮਾਲਕ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇੱਕ changelog ਇਹ ਦੱਸਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ v2.3 ਕਿਉਂ ਮੌਜੂਦ ਹੈ ਅਤੇ v2.2 ਵਿੱਚ ਕੀ ਖਰਾਬ ਹੋਇਆ ਸੀ।
ਆਪਣੀਆਂ Layers ਨੂੰ ਵੱਖ ਕਰੋ
ਟੀਮਾਂ ਵੱਲੋਂ ਕੀਤੀ ਜਾਣ ਵਾਲੀ ਸਭ ਤੋਂ ਵੱਡੀ ਗਲਤੀ ਸਭ ਕੁਝ ਇੱਕ ਹੀ ਪ੍ਰੋਂਪਟ ਵਿੱਚ ਭਰ ਦੇਣਾ ਹੈ। ਉਹ ਮਦਦਗਾਰ ਮਾਰਗਦਰਸ਼ਨ, tool documentation
- Instructions ਏਜੰਟ ਲਈ ਮਾਰਗਦਰਸ਼ਨ ਹਨ। ਇਹ ਲਹਿਜੇ, ਫਾਰਮੈਟ ਅਤੇ ਆਮ ਪਹੁੰਚ ਦੀ ਵਿਆਖਿਆ ਕਰਦੀਆਂ ਹਨ।
- Tool Rules ਏਜੰਟ ਨੂੰ ਦੱਸਦੇ ਹਨ ਕਿ ਕਿਹੜੇ ਟੂਲ ਮੌਜੂਦ ਹਨ ਅਤੇ ਉਹ ਕੀ ਕਰਦੇ ਹਨ। ਇਹ ਖੋਜ (discovery) ਹੈ, ਇਜਾਜ਼ਤ ਨਹੀਂ।
- Policy ਕੋਡ ਦੁਆਰਾ ਲਾਗੂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਉਮੀਦ ਨਾਲ ਨਹੀਂ। ਜੇਕਰ $500 ਤੋਂ ਵੱਧ ਰਿਫੰਡ ਲਈ ਦੂਜੀ ਨਜ਼ਰ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਉਹ ਚੈੱਕ ਇੱਕ ਵੈਲੀਡੇਸ਼ਨ ਫੰਕਸ਼ਨ ਵਿੱਚ ਹੁੰਦਾ ਹੈ ਜੋ ਟੂਲ ਨੂੰ ਕਾਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਚੱਲਦਾ ਹੈ।
- Evals ਉਹ ਟੈਸਟ ਹਨ ਜੋ ਸਾਬਤ ਕਰਦੇ ਹਨ ਕਿ ਕਿਸੇ ਵੀ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਹੁਨਰ ਅਜੇ ਵੀ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ।
ਉਦਾਹਰਨ ਲਈ, ਇਹ ਨਾ ਲਿਖੋ, "ਕਿਰਪਾ ਕਰਕੇ ਗਾਹਕ ਦੇ ਕ੍ਰੈਡਿਟ ਕਾਰਡ ਦਾ ਪੂਰਾ ਨੰਬਰ ਕਦੇ ਵੀ ਪ੍ਰਗਟ ਨਾ ਕਰੋ।" ਇਸ ਦੀ ਬਜਾਏ, ਇੱਕ ਡਾਟਾ ਫਾਰਮੈਟਰ ਬਣਾਓ ਜੋ ਏਜੰਟ ਦੇ ਦੇਖਣ ਤੋਂ ਪਹਿਲਾਂ PANs ਨੂੰ ਲੁਕਾ (redact) ਦੇਵੇ। ਨੀਤੀ ਕੋਡ ਵਿੱਚ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਕਿਉਂਕਿ ਇੱਕ ਚਲਾਕ ਯੂਜ਼ਰ ਇਨਪੁਟ ਰਾਹੀਂ ਕੋਡ ਨੂੰ ਉਸਦੇ ਕੰਮ ਤੋਂ ਨਹੀਂ ਰੋਕ ਸਕਦਾ।
ਪ੍ਰੋਡਕਸ਼ਨ ਨੂੰ "Latest" 'ਤੇ ਨਿਰਧਾਰਤ ਕਰਨਾ ਬੰਦ ਕਰੋ
ਸ਼ੁੱਕਰਵਾਰ ਦੀ ਸ਼ਾਮ ਨੂੰ ਇੱਕ ਚੁੱਪ ਪ੍ਰੋਂਪਟ ਅਪਡੇਟ ਤੋਂ ਬਦਤਰ ਕੁਝ ਨਹੀਂ ਹੋ ਸਕਦਾ। ਜੇਕਰ ਤੁਹਾਡਾ ਪ੍ਰੋਡਕਸ਼ਨ ਏਜੰਟ ਹਮੇਸ਼ਾ ਕਿਸੇ skill ਦਾ "latest" ਵਰਜ਼ਨ ਲੈਂਦਾ ਹੈ, ਤਾਂ main ਵਿੱਚ ਹਰ ਮਰਜ (merge) ਇੱਕ ਸੰਭਾਵੀ ਲਾਈਵ ਘਟਨਾ ਹੋ ਸਕਦੀ ਹੈ। ਤੁਹਾਨੂੰ dev, staging, ਅਤੇ prod ਵਰਗੇ ਐਲੀਏਸ (aliases) ਦੀ ਲੋੜ ਹੈ। ਇੱਕ ਜਾਣੇ-ਪਛਾਣੇ, ਟੈਸਟ ਕੀਤੇ ਹੋਏ ਵਰਜ਼ਨ ਨੂੰ ਇਹਨਾਂ ਪੜਾਵਾਂ ਰਾਹੀਂ ਅੱਗੇ ਵਧਾਓ। ਜਦੋਂ prod v2.1.4 ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇਸਨੂੰ ਚੱਲਦੇ ਹੋਏ ਦੇਖ ਸਕਦੇ ਹੋ, ਇਸਦੇ ਵਿਵਹਾਰ ਨੂੰ ਮਾਪ ਸਕਦੇ ਹੋ, ਅਤੇ ਸਕੂਨ ਨਾਲ ਸੌਂ ਸਕਦੇ ਹੋ। ਜੇਕਰ ਕੁਝ ਗਲਤ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਐਲੀਏਸ ਨੂੰ ਪਿੱਛੇ ਲੈ ਜਾਂਦੇ ਹੋ। ਤੁਸੀਂ ਅੱਧੀ ਰਾਤ ਨੂੰ ਦਬਾਅ ਹੇਠ ਕੁਦਰਤੀ ਭਾਸ਼ਾ (natural language) ਨੂੰ ਡੀਬੱਗ ਨਹੀਂ ਕਰਦੇ।
ਇਹ ਅਨੁਸ਼ਾਸਨ ਤੁਹਾਡੀ ਟੀਮ ਨੂੰ ਪਿਛਲੀ ਅਨੁਕੂਲਤਾ (backwards compatibility) ਬਾਰੇ ਸੋਚਣ ਲਈ ਵੀ ਮਜਬੂਰ ਕਰਦਾ ਹੈ। ਕੀ v2.2 ਉਹੀ ਇਨਪੁਟ ਸ਼ੇਪ ਸੰਭਾਲ ਸਕਦਾ ਹੈ ਜੋ v2.1 ਕਰਦਾ ਸੀ? ਜੇਕਰ ਨਹੀਂ, ਤਾਂ ਪ੍ਰੋਮੋਸ਼ਨ staging ਵਿੱਚ ਫੇਲ ਹੋ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਇਸਨੂੰ ਗਾਹਕ ਤੋਂ ਪਹਿਲਾਂ ਫੜ ਲੈਂਦੇ ਹੋ।
ਸੁਰੱਖਿਆ ਪੈਕੇਜ ਦੇ ਅੰਦਰੋਂ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ
ਬਿਨਾਂ ਆਡਿਟ ਕੀਤੇ ਪ੍ਰੋਂਪਟਾਂ ਨਾਲ ਭਰੀ ਰਜਿਸਟਰੀ ਇੱਕ ਅਜਿਹੀ ਕਮਜ਼ੋਰੀ ਹੈ ਜੋ ਕਦੇ ਵੀ ਵਾਪਰ ਸਕਦੀ ਹੈ। ਤੁਹਾਨੂੰ ਆਪਣੇ skills ਨੂੰ ਉਹਨਾਂ ਹੀ ਜੋਖਮਾਂ ਲਈ ਸਕੈਨ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਜਿਨ੍ਹਾਂ ਲਈ ਤੁਸੀਂ ਕੋਡ ਨੂੰ ਸਕੈਨ ਕਰੋਗੇ।
ਪ੍ਰੋਂਪਟ ਟੈਂਪਲੇਟਾਂ ਵਿੱਚ ਦਬੇ ਹੋਏ ਹਾਰਡਕੋਡਡ ਸੀਕਰੇਟਸ ਜਾਂ API ਕੀਜ਼ ਦੀ ਭਾਲ ਕਰੋ। ਬਾਹਰੀ ਵੈੱਬਹੁਕਸ (webhooks) ਜਾਂ ਸ਼ੈੱਲ ਕਮਾਂਡਾਂ ਦੀ ਜਾਂਚ ਕਰੋ ਜੋ ਡਾਟਾ ਬਾਹਰ ਭੇਜਦੀਆਂ ਹਨ। ਸਿਸਟਮ ਨੀਤੀ ਨੂੰ ਬਦਲਣ ਦੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ 'ਤੇ ਨਜ਼ਰ ਰੱਖੋ, ਜਿਵੇਂ ਕਿ ਉਹ ਪ੍ਰੋਂਪਟ ਜਿਨ੍ਹਾਂ ਵਿੱਚ "ignore previous instructions" ਸ਼ਾਮਲ ਹੈ ਜਾਂ ਏਜੰਟ ਨੂੰ ਆਪਣੀ ਕੌਂਫਿਗਰੇਸ਼ਨ ਦੱਸਣ ਲਈ ਕਹਿੰਦੇ ਹਨ। ਇਹ ਸਿਰਫ਼ ਸਿਧਾਂਤਕ ਨਹੀਂ ਹਨ। ਇਹ ਪ੍ਰੋਂਪਟ-ਇੰਜੈਕਸ਼ਨ ਹਮਲਿਆਂ ਵਿੱਚ ਆਮ ਪੈਟਰਨ ਹਨ, ਅਤੇ ਉਹ ਖ਼ਤਰਨਾਕ ਹਨ ਕਿਉਂਕਿ ਉਹ ਅਕਸਰ ਕਾਪੀ ਕੀਤੇ ਗਏ ਟੈਕਸਟ ਦੇ ਨਾਲ ਆਉਂਦੇ ਹਨ ਜਿਸਦੀ ਕਿਸੇ ਨੇ ਸਮੀਖਿਆ ਨਹੀਂ ਕੀਤੀ ਹੁੰਦੀ।
ਆਪਣੇ skill ਪੈਕੇਜਾਂ ਨੂੰ ਸਟੈਟਿਕ ਵਿਸ਼ਲੇਸ਼ਣ (static analysis) ਰਾਹੀਂ ਚਲਾਓ। ਜੇਕਰ ਕਿਸੇ skill ਫਾਈਲ ਵਿੱਚ ਕੋਈ ਅਜਿਹਾ URL ਹੈ ਜੋ allowlist 'ਤੇ ਨਹੀਂ ਹੈ, ਤਾਂ ਬਿਲਡ ਨੂੰ ਫੇਲ ਕਰ ਦਿਓ। ਜੇਕਰ ਇਹ ਕਿਸੇ ਅਜਿਹੇ ਟੂਲ ਦਾ ਹਵਾਲਾ ਦਿੰਦਾ ਹੈ ਜੋ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਮੈਨੀਫੈਸਟ (manifest) ਵਿੱਚ ਨਹੀਂ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਰੱਦ ਕਰ ਦਿਓ।
ਜੇਕਰ ਤੁਸੀਂ ਇਸਦਾ ਟੈਸਟ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਤੁਸੀਂ ਇਸ 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰ ਸਕਦੇ
ਮੁਲਾਂਕਣਾਂ (evaluations) ਤੋਂ ਬਿਨਾਂ ਰਜਿਸਟਰੀ ਸਿਰਫ਼ ਪ੍ਰੋਂਪਟਾਂ ਦਾ ਇੱਕ ਫੋਲਡਰ ਹੈ। ਹਰੇਕ skill ਨੂੰ ਇੱਕ ਟੈਸਟ ਸੈੱਟ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜੋ happy path, edge cases, ਅਤੇ failure modes ਦੀ ਜਾਂਚ ਕਰੇ। ਉੱਚ-ਜੋਖਮ ਵਾਲੇ skills ਲਈ, ਤੁਹਾਨੂੰ ਫੰਕਸ਼ਨਲ ਟੈਸਟਾਂ ਤੋਂ ਵੱਧ ਦੀ ਲੋੜ ਹੈ। ਤੁਹਾਨੂੰ ਇਜਾਜ਼ਤ ਦੀਆਂ ਸੀਮਾਵਾਂ ਦੀ ਜਾਂਚ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਤਾਂ ਜੋ ਇਹ ਯਕੀਨੀ ਬਣਾਇਆ ਜਾ ਸਕੇ ਕਿ ਏਜੰਟ ਦੂਜੇ ਉਪਭੋਗਤਾ ਦਾ ਡਾਟਾ ਨਹੀਂ ਦੇਖ ਸਕਦਾ। ਤੁਹਾਨੂੰ refusal behavior ਦੀ ਜਾਂਚ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਤਾਂ ਜੋ ਇਹ ਪੁਸ਼ਟੀ ਕੀਤੀ ਜਾ ਸਕੇ ਕਿ ਜਦੋਂ ਨੀਤੀ ਕਿਸੇ ਕਾਰਵਾਈ ਨੂੰ ਰੋਕਦੀ ਹੈ ਤਾਂ ਉਹ 'ਨਾ' ਕਹਿੰਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਪ੍ਰੋਂਪਟ-ਇੰਜੈਕਸ਼ਨ ਵਿਰੋਧੀ ਟੈਸਟਾਂ ਦੀ ਲੋੜ ਹੈ ਤਾਂ ਜੋ ਇਹ ਪੁਸ਼ਟੀ ਕੀਤੀ ਜਾ ਸਕੇ ਕਿ ਵਿਰੋਧੀ ਇਨਪੁਟ ਤੁਹਾਡੇ ਕੋਡ-ਪੱਧਰ ਦੇ ਸੁਰੱਖਿਆ ਪ੍ਰਬੰਧਾਂ ਨੂੰ ਬਾਈਪਾਸ ਨਹੀਂ ਕਰਦੇ।
ਆਪਣੇ ਟੈਸਟਾਂ ਨੂੰ ਸਪੱਸ਼ਟ ਰੂਪ ਵਿੱਚ ਨਾਮ ਦਿਓ। "refund_skill_rejects_negative_amount" ਨਾਮ ਦਾ ਟੈਸਟ ਅਗਲੇ ਇੰਜੀਨੀਅਰ ਨੂੰ ਬਿਲਕੁਲ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਵਿਵਹਾਰ ਸੁਰੱਖਿਅਤ ਹੈ। ਜਦੋਂ ਵਰਜ਼ਨ ਪ੍ਰੋਮੋਸ਼ਨ ਦੌਰਾਨ ਕੋਈ ਟੈਸਟ ਫੇਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਪੱਕਾ ਸਬੂਤ ਹੁੰਦਾ ਹੈ ਕਿ ਉਮੀਦਵਾਰ ਬਿਲਡ ਅਸੁਰੱਖਿਅਤ ਹੈ।
ਅਸਲ ਟੀਚਾ ਕੰਟਰੋਲ ਹੈ
Reuse ਵਧੀਆ ਹੈ, ਪਰ ਕੰਟਰੋਲ ਹੀ ਤੁਹਾਨੂੰ ਨੌਕਰੀ 'ਤੇ ਬਣਾਈ ਰੱਖਦਾ ਹੈ। ਇੱਕ skill ਰਜਿਸਟਰੀ ਤੁਹਾਡੀ ਟੀਮ ਨੂੰ ਯਕੀਨ ਨਾਲ ਕਹਿਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ: ਇਹ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਵਰਕਫਲੋਅ ਹੈ। ਇਹ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਚੱਲ ਰਿਹਾ ਵਰਜ਼ਨ ਹੈ। ਇਹ ਉਹ ਟੂਲ ਹਨ ਜੋ ਇਹ ਵਰਤ ਸਕਦਾ ਹੈ। ਅਸੀਂ ਇਸਨੂੰ ਬਿਲਕੁਲ ਇਸ ਤਰ੍ਹਾਂ roll back ਕਰਦੇ ਹਾਂ।
ਉਹ ਸਪੱਸ਼ਟਤਾ ਤੁਹਾਨੂੰ ਚਲਾਕ demos ਭੇਜਣ ਤੋਂ ਇੱਕ ਭਰੋਸੇਯੋਗ ਸੌਫਟਵੇਅਰ ਚਲਾਉਣ ਵੱਲ ਲੈ ਜਾਂਦੀ ਹੈ। Demos ਦਸ ਮਿੰਟ ਲਈ ਸਟੇਕਹੋਲਡਰਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ। ਭਰੋਸੇਯੋਗ ਸੌਫਟਵੇਅਰ ਤੜਕੇ ਤਿੰਨ ਵਜੇ ਚੱਲਦਾ ਹੈ, exceptions ਨੂੰ ਸੁਚਾਰੂ ਰੂਪ ਵਿੱਚ ਸੰਭਾਲਦਾ ਹੈ, ਅਤੇ ਸਿਰਫ਼ ਇਸ ਲਈ ਆਪਣਾ ਵਿਵਹਾਰ ਨਹੀਂ ਬਦਲਦਾ ਕਿਉਂਕਿ ਕਿਸੇ ਨੇ ਮੰਗਲਵਾਰ ਦੁਪਹਿਰ ਨੂੰ ਇੱਕ pull request ਮਰਜ ਕੀਤੀ ਹੈ।
ਆਪਣੀ ਰਜਿਸਟਰੀ ਬਣਾਓ। ਆਪਣੇ skills ਦਾ ਵਰਜ਼ਨ ਬਣਾਓ। ਆਪਣੀਆਂ ਨੀਤੀਆਂ ਨੂੰ ਕੋਡ ਵਿੱਚ ਲਾਗੂ ਕਰੋ। ਇਸ ਤਰ੍ਹਾਂ ਟੈਸਟ ਕਰੋ ਜਿਵੇਂ ਕਿ ਤੁਹਾਡਾ ਸੌਣ ਦਾ ਸਮਾਂ ਇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੋਵੇ। ਤੁਹਾਡਾ ਭਵਿੱਖ ਦਾ ਰੂਪ ਤੁਹਾਡਾ ਧੰਨਵਾਦ ਕਰੇਗਾ।