દરેક એજન્ટ સિસ્ટમ એક જ અસુવિધાજનક ટ્રેડ-ઓફનો સામનો કરે છે. તમે એક ઊંડું, સુવ્યવસ્થિત નોલેજ બેઝ ઈચ્છો છો જે કોડ રિવ્યુ અને git હિસ્ટ્રીમાં ટકી રહે. પરંતુ તમારે રનટાઇમને ઝડપી અને ફોકસ રાખવાની પણ જરૂર છે. આ બંને જરૂરિયાતો એકબીજાની વિરુદ્ધ કામ કરે છે. તમે જેટલા વધુ ઇન્સ્ટ્રક્શન્સ સાચવો છો, તેટલું જ બધાને પ્રોમ્પ્ટમાં નાખી દેવું અને શ્રેષ્ઠ પરિણામની આશા રાખવી વધુ આકર્ષક બની જાય છે. તે આશા મોંઘી પડે છે.
Agent Project Context ઇકોસિસ્ટમમાં, આ તણાવ સ્પષ્ટપણે બે લેયરમાં વહેંચાયેલ છે. APC ટકાઉપણું (durability) સંભાળે છે. APX ઝડપ સંભાળે છે. તેઓ કેવી રીતે એકબીજા સાથે સંપર્ક કરે છે—અને શા માટે APX દરેક સ્કિલ ડેફિનેશનને પ્રીલોડ કરવાનો ઇનકાર કરે છે—તે સમજવાથી પ્રોમ્પ્ટ એન્જિનિયરિંગ વિશે મોટાભાગની ઓપ્ટિમાઇઝેશન ગાઇડ્સ કરતાં વધુ જાણવા મળે છે.
આર્કાઇવ અને એન્જિન
APC નું કામ કાયમીપણું છે. તે .apc/skills/ હેઠળ ફરીથી ઉપયોગ કરી શકાય તેવી સ્કિલ ફાઇલોને સાદા Markdown દસ્તાવેજો તરીકે સ્ટોર કરે છે. કારણ કે આ ફાઇલો તમારા રિપોઝિટરીની અંદર હોય છે, તેઓ વર્ઝન કંટ્રોલ સાથે જ રહે છે. તમે ડિપ્લોયમેન્ટ પ્રક્રિયા બદલતી એક pull request ખોલી શકો છો. તમે છ અઠવાડિયા પહેલાના સિક્યુરિટી પોલિસી રોલબેકનું diff કરી શકો છો. એજન્ટને શું જાણવાનું હતું અને ક્યારે, તેનું તમે ચોક્કસ ઓડિટ કરી શકો છો. જ્યારે કોઈ ખરાબ ડિપ્લોયમેન્ટ લાઈવ જાય અથવા કમ્પ્લાયન્સ ઓડિટર પ્રશ્નો પૂછવાનું શરૂ કરે ત્યારે આ રિવ્યુએબિલિટી મહત્વની બને છે.
બીજી તરફ, APX વર્તમાનમાં જીવે છે. તે તમારા અને મોડેલ વચ્ચેના વાસ્તવિક સંવાદનું સંચાલન કરે છે. તેનો ધ્યેય જ્ઞાનને આર્કાઇવ કરવાનું નથી પરંતુ તેનો ચોક્કસ ઉપયોગ કરવાનો છે. જ્યારે APX સ્કિલ્સને કાયમી બોજ તરીકે લે છે, ત્યારે આખી સિસ્ટમ ધીમી પડી જાય છે. કોન્ટેક્સ્ટ વિન્ડો ભરાઈ જાય છે. ટોકન ખર્ચ વધે છે. વધુ ખરાબ બાબત એ છે કે, મોડેલનું ધ્યાન એવા ઇન્સ્ટ્રક્શન્સ પર વિખરાઈ જાય છે જેનો વર્તમાન વિનંતી સાથે કોઈ સંબંધ નથી.
આ જ કારણ છે કે સ્કિલ બોડીઝ ડિમાન્ડ પર લોડ થાય છે.
બ્લોટેડ પ્રોમ્પ્ટનો સાચો ખર્ચ
મોટાભાગની ટીમો સમજે છે કે ટોકન્સ માટે પૈસા ચૂકવવા પડે છે. પરંતુ ઓછી ટીમો એ સમજે છે કે બિનજરૂરી ટોકન્સ ચોકસાઈનો ખર્ચ કરે છે.
જ્યારે APX દરેક ઉપલબ્ધ સ્કિલને દરેક ટર્નમાં ઇન્જેક્ટ કરે છે, ત્યારે પ્રોમ્પ્ટ ઘોંઘાટભર્યો (noisy) બની જાય છે. મોડેલને ડિપ્લોયમેન્ટ રનબુક, સિક્યુરિટી ગાઇડ, API સ્ટાઇલ રેફરન્સ, ટેસ્ટિંગ ચેકલિસ્ટ અને ઓનબોર્ડિંગ FAQ બધું એકસાથે મળે છે. મોટા કોન્ટેક્સ્ટ વિન્ડો હોવા છતાં, જ્યારે મોડેલે સિગ્નલ શોધવા માટે પહેલા ઘોંઘાટમાંથી પસાર થવું પડે છે, ત્યારે રીઝનિંગની ગુણવત્તા ઘટે છે. તે લોકલ ટેસ્ટ સેટઅપ વિશે પ્રશ્નનો જવાબ આપતી વખતે પ્રોડક્શન ડિપ્લોયમેન્ટ માટેના સિક્યુરિટી રિક્વાયરમેન્ટ પર ધ્યાન કેન્દ્રિત કરી શકે છે. તે સાધારણ બગ ફિક્સમાં રિલીઝ ચેકલિસ્ટના સ્ટેપ્સનું હેલ્યુસિનેશન કરી શકે છે. સંબંધિત ન હોય તેવા ટેક્સ્ટનો દરેક વધારાનો ફકરો એક વિક્ષેપ બની શકે છે.
ગણિત સીધું છે. મોટાભાગના ટર્ન્સમાં મોટાભાગની સ્કિલ્સની જરૂર હોતી નથી. જો તમે એરર લોગ માટે ઝડપી ફિક્સ માંગી રહ્યા હોવ, તો તમારે ડિપ્લોયમેન્ટ રનબુક અથવા સિક્યુરિટી હાર્ડનિંગ ગાઇડના સંપૂર્ણ લખાણની જરૂર નથી. તમારે મોડેલ એરર જુએ, તમારા પ્રોજેક્ટ કન્વેન્શનને સમજે અને સાચી ફાઇલ એડિટ કરે તેવી જરૂર છે. બિનજરૂરી સ્કિલ બોડીઝ લોડ કરવાથી મોડેલને આ કરવામાં મદદ મળતી નથી. તે મોડેલને તમારી વાસ્તવિક સમસ્યા પર કામ કરવાનું શરૂ કરતા પહેલા જ બિનઉપયોગી ડેટાને ફિલ્ટર કરવા માટે મજબૂર કરે છે.
ઓન-ડિમાન્ડ લોડિંગ કેવી રીતે કામ કરે છે
આ પદ્ધતિ સરળ છે પરંતુ ઇરાદાપૂર્વક બનાવવામાં આવી છે. APC સતત ગ્રાઉન્ડ ટ્રુથ જાળવી રાખે છે. તમારી સ્કિલ ડેફિનેશન જ્યાં હોવી જોઈએ ત્યાં જ રહે છે: .apc/skills/<name>.md માં.
APX તે ફાઇલોને એક્ટિવ મેમરીમાં મિરર કરતું નથી. તેના બદલે, તે સ્કિલ નામોની એક કોમ્પેક્ટ રજિસ્ટ્રી બનાવે છે. મોડેલ આ યાદી જુએ છે અને સમજે છે કે એક કેટલોગ અસ્તિત્વ ધરાવે છે. જો તેને ઉપલબ્ધ ક્ષમતાઓ જોવા અથવા તેની પુષ્ટિ કરવાની જરૂર હોય, તો તે list_skills કોલ કરી શકે છે. આ તેને વૉલ્યુમ વગર વિઝિબિલિટી આપે છે.
જ્યારે કાર્યને ખરેખર ચોક્કસ સિન્ટેક્સ, વિગતવાર સ્ટેપ્સ, અથવા સ્કિલ ફાઇલમાં એન્કોડ કરેલી ચોક્કસ મર્યાદાઓની જરૂર હોય, ત્યારે મોડેલ load_skill કોલ કરે છે. તે સમયે, અને ફક્ત તે સમયે જ, APX એ APC માંથી સંપૂર્ણ Markdown બોડી મેળવે છે અને તેને કોન્ટેક્સ્ટમાં ઇન્જેક્ટ કરે છે. ઇન્સ્ટ્રક્શન તરત જ આવે છે, તેનો નિર્ધારિત હેતુ માટે એક જ વાર ઉપયોગ થાય છે, અને સિસ્ટમ તેને વધારાના ભાર તરીકે વહન કરવાનું ટાળે છે.
લાઈબ્રેરી ઇમ્પોર્ટ કરવા અને તમારા મુખ્ય ફાઇલમાં દરેક ફંક્શન ડેફિનેશન પેસ્ટ કરવા વચ્ચેના તફાવત વિશે વિચારો. એક અભિગમ તમારા કોડબેઝને નેવિગેટ કરી શકાય તેવો રાખે છે. બીજો અભિગમ એક એવો ગંદો માહોલ બનાવે છે જે માત્ર અકસ્માતે જ કમ્પાઇલ થાય છે.
જ્યારે સ્કિલ્સ અથડાય ત્યારે કોણ જીતે છે
જ્યારે APX સ્કિલ્સ લોડ કરે છે ત્યારે તે સ્પષ્ટ પ્રાથમિકતા ક્રમ (priority order) પણ લાગુ કરે છે. દરેક એન્વાયરમેન્ટ સમાન નથી હોતું, અને સામાન્ય સલાહ ક્યારેય લોકલ નોલેજ પર હાવી થવી જોઈએ નહીં.
પ્રોજેક્ટ સ્કિલ્સ (Project skills) સર્વોચ્ચ અગ્રતા ધરાવે છે. આ ફાઇલો તમારી વર્તમાન રિપોઝિટરીમાં .apc/skills/ હેઠળ રહેલી હોય છે. તેઓ તમારી ટીમની ચોક્કસ પરંપરાઓ (conventions), તમારા કસ્ટમ રેપર્સ (custom wrappers), તમારા જૂના નામકરણના ધોરણો (legacy naming standards) અને તમારા વિશિષ્ટ ટૂલચેન (toolchain) ને કેપ્ચર કરે છે. જો તમારો પ્રોજેક્ટ ડેટાબેઝ માઈગ્રેશન હેન્ડલ કરવાની પોતાની રીત વ્યાખ્યાયિત કરે છે, તો તે વ્યાખ્યા જ માન્ય રહેશે.
ત્યારબાદ ગ્લોબલ સ્કિલ્સ (Global skills) આવે છે. આ સંસ્થા-સ્તરની પેટર્નને આવરી લે છે જે ત્યારે લાગુ પડે છે જ્યારે પ્રોજેક્ટ પોતે કોઈ સૂચના આપતો નથી. તેઓ એક સ્ટાન્ડર્ડ લાઈબ્રેરી તરીકે કામ કરે છે.
બિલ્ટ-ઇન રનટાઇમ સ્કિલ્સ (Built-in runtime skills) છેલ્લે ફોલબેક (fallback) તરીકે હોય છે. તેઓ સામાન્ય ક્ષમતાઓ સંભાળે છે જે દરેક એજન્ટ સમજી શકવો જોઈએ પરંતુ કોઈ ચોક્કસ પ્રોજેક્ટ તેને ફરીથી વ્યાખ્યાયિત કરવાની જરૂરિયાત અનુભવતો નથી.
આ સ્તરયુક્ત અભિગમનો અર્થ એ છે કે તમારી રિપોઝિટરી તેના પોતાના વર્તણૂક પર નિયંત્રણ રાખે છે. કોઈ ગ્લોબલ અથવા બિલ્ટ-ઇન સ્કિલ ભૂલથી એવા વર્કફ્લોને હાઇજેક કરી શકતી નથી જેને તમારી ટીમે ઇરાદાપૂર્વક કસ્ટમાઇઝ કર્યો હોય.
વ્યવહારમાં આ કેવું દેખાય છે
એક સામાન્ય મેન્ટેનન્સ ટાસ્ક (maintenance task) ની કલ્પના કરો. એક સાથીદાર ચેટમાં એરર લોગ (error log) પેસ્ટ કરે છે. ટ્રેસબેક (traceback) યુટિલિટી મોડ્યુલમાં એક સિંગલ નલ રેફરન્સ (null reference) તરફ નિર્દેશ કરે છે. તેનો ઉકેલ સંભવતઃ ડિફેન્સિવ કોડિંગની બે લાઈન હશે.
ઓન-ડિમાન્ડ લોડિંગ વગરની સિસ્ટમમાં, APX તેની પાસે રહેલી દરેક સ્કિલથી કોન્ટેક્સ્ટ (context) ભરી દેશે. હવે મોડેલ પાસે તે બે લાઈનોને સ્પર્શતા પહેલા વિચારવા માટે ચાલીસ પાના લખાણ હશે. તે રિલીઝ ચેકલિસ્ટ જુએ છે અને વિચારે છે કે શું તેણે વર્ઝન અપડેટ કરવું જોઈએ. તે સિક્યુરિટી ગાઈડ જુએ છે અને એવા ફંક્શન પર ઇનપુટ વેલિડેશન વિશે વિચારવા લાગે છે જેને ફક્ત નલ ચેકની જરૂર છે. તે ડિપ્લોયમેન્ટ રનબુક જુએ છે અને સ્ટેજિંગ એન્વાયરમેન્ટ્સ વિશે વિચારવાનું શરૂ કરે છે. મોડેલ ભટકી જાય છે. પ્રતિસાદ આપવામાં વધુ સમય લાગે છે. ટોકન મીટર ઝડપથી વધે છે.
APX ના ઓન-ડિમાન્ડ ડિઝાઇન સાથે, મોડેલ ફક્ત નામો જ જુએ છે. તે જાણે છે કે [release-checklist], [security-guide], [deployment-runbook], અને [error-handling] અસ્તિત્વ ધરાવે છે. તે પ્રથમ ત્રણને અવગણે છે. જો તમારા પ્રોજેક્ટના નલ સેફ્ટી (null safety) માટેના નિયમો વિશિષ્ટ હોય, તો તે [error-handling] લોડ કરી શકે છે. તે બગ (bug) ને ઠીક કરે છે. બિનસંબંધિત સ્કિલ્સ ક્યારેય કોન્ટેક્સ્ટ વિન્ડોમાં આવી જ નથી. મોડેલ કેન્દ્રિત રહ્યું કારણ કે પ્રોમ્પ્ટ ક્લીન રહ્યો.
જ્યારે કાર્ય ખરેખર જટિલ હોય ત્યારે પણ આ જ તર્ક લાગુ પડે છે. જો તમે પછીથી એજન્ટને પ્રોડક્શન ડિપ્લોયમેન્ટ તૈયાર કરવા માટે કહેશો, તો તે ડિપ્લોયમેન્ટ રનબુક લોડ કરી શકે છે, સિક્યુરિટી ગાઈડનો ઉપયોગ કરી શકે છે અને રિલીઝ ચેકલિસ્ટનું ચોક્કસપણે પાલન કરી શકે છે જ્યારે તે સ્ટેપ્સ સુસંગત બને. જ્ઞાન હંમેશા ત્યાં જ હતું. તે ફક્ત યોગ્ય ક્ષણની રાહ જોતું હતું.
આર્કિટેક્ચર તરીકે પ્રોમ્પ્ટ ડિસિપ્લિન (Prompt Discipline)
APC અને APX વચ્ચેનું વિભાજન માત્ર અમલીકરણની વિગત નથી. તે પ્રોમ્પ્ટ ડિસિપ્લિનનું એક દર્શન છે. APC જ્ઞાનને કાયમ માટે સાચવે છે, તેને રિવ્યુ કરી શકાય તેવું, વર્ઝન કરેલું અને સુરક્ષિત બનાવે છે. APX નક્કી કરે છે કે તેમાંથી કેટલું જ્ઞાન અત્યારે એક્ટિવ કોન્ટેક્સ્ટમાં સ્થાન મેળવશે.
સમૃદ્ધ સ્કિલ કેટલોગ એ એક સંપત્તિ છે. ફૂલેલું (bloated) પ્રોમ્પ્ટ એ જવાબદારી (liability) છે. ધ્યેય એ છે કે તમારા કોન્ટેક્સ્ટને હંમેશા એક્ટિવ રાખ્યા વગર તેને પોર્ટેબલ રાખવો. તમારી રિપોઝિટરીમાં તમારી ટીમે લખેલી દરેક સૂચના હોવી જોઈએ, પરંતુ એજન્ટે ફક્ત તે જ વાંચવી જોઈએ જે તાત્કાલિક કાર્યમાં મદદ કરે છે.
જો તમારી સિસ્ટમ મોડેલને દરેક વખતે દરેક સ્કિલની વિગતો સાથે રાખવા માટે મજબૂર કરે છે, તો તમે ઇન્ટેલિજન્ટ આસિસ્ટન્ટ નથી બનાવી રહ્યા. તમે એક એવા લાઈબ્રેરીયન બનાવી રહ્યા છો જે દરેક સંદર્ભ પ્રશ્ન માટે આખું આર્કાઇવ ખેંચી લાવે છે. બધું જ સ્ટોર કરો. જે મહત્વનું છે તે જ લોડ કરો. આ રીતે તમે એજન્ટ્સને ઝડપી, કોન્ટેક્સ્ટને ક્લીન અને તર્કને તેજ બનાવી શકો છો.