ஒவ்வொரு ஏஜென்ட் சிஸ்டமும் (agent system) ஒரே மாதிரியான சங்கடமான சமரசத்தை (trade-off) எதிர்கொள்கிறது. குறியீடு ஆய்வுகள் (code reviews) மற்றும் git வரலாற்றைத் தாங்கி நிற்கும் ஆழமான, நன்கு ஒழுங்கமைக்கப்பட்ட அறிவுத் தளத்தை (knowledge base) நீங்கள் விரும்புகிறீர்கள். ஆனால் ரன்டைம் (runtime) வேகமாகவும், கவனச்சிதறல் இல்லாமலும் இருக்க வேண்டும் என்றும் நீங்கள் விரும்புகிறீர்கள். இந்த இரண்டுத் தேவைகளும் ஒன்றுக்கொன்று எதிராகச் செயல்படுகின்றன. நீங்கள் எவ்வளவு அதிகமான அறிவுறுத்தல்களை (instructions) சேமித்து வைக்கிறீர்களோ, அவ்வளவு அதிகமாக அவற்றை அப்படியே பிராம்ப்ட்டில் (prompt) கொட்டிவிட்டு, எல்லாம் சரியாக நடக்கும் என்று நம்புவது தூண்டுதலாக இருக்கும். அந்த நம்பிக்கை விலை உயர்ந்தது.
Agent Project Context சூழலில் (ecosystem), இந்தத் பதற்றம் இரண்டு அடுக்குகளாகத் தெளிவாகப் பிரிக்கப்பட்டுள்ளது. APC நீடித்து நிலைத்தலை (durability) கையாள்கிறது. APX வேகத்தைக் கையாள்கிறது. அவை எவ்வாறு ஒன்றோடொன்று தொடர்பு கொள்கின்றன என்பதையும்—ஏன் APX ஒவ்வொரு திறனையும் (skill definition) முன்கூட்டியே ஏற்ற மறுக்கிறது என்பதையும்—புரிந்துகொள்வது, பெரும்பாலான மேம்படுத்தல் வழிகாட்டிகளை (optimization guides) விட பிராம்ப்ட் இன்ஜினியரிங் (prompt engineering) பற்றி உங்களுக்கு அதிகம் கற்பிக்கும்.
ஆர்க்கிவ் மற்றும் என்ஜின் (The Archive and the Engine)
APC-இன் பணி நிலைத்தன்மை (permanence) ஆகும். இது மீண்டும் பயன்படுத்தக்கூடிய திறன் கோப்புகளை (skill files) .apc/skills/ என்பதன் கீழ் சாதாரண Markdown ஆவணங்களாகச் சேமிக்கிறது. இந்த கோப்புகள் உங்கள் ரெப்போசிட்டரிக்குள் (repository) இருப்பதால், அவை பதிப்பு கட்டுப்பாட்டுடன் (version control) இணைந்துச் செல்கின்றன. நீங்கள் ஒரு deployment முறையை மாற்றும் ஒரு pull request-ஐத் திறக்கலாம். ஆறு வாரங்களுக்கு முந்தைய ஒரு பாதுகாப்பு கொள்கை மாற்றத்தை (security policy rollback) diff செய்யலாம். ஏஜென்ட் எப்போது, எதை அறிந்திருக்க வேண்டும் என்பதைத் துல்லியமாகத் தணிக்கை (audit) செய்யலாம். ஒரு தவறான deployment நேரலையில் வரும்போதோ அல்லது ஒரு இணக்கத் தணிக்கையாளர் (compliance auditor) கேள்விகள் கேட்கத் தொடங்கும்போதோ, இந்த மறுஆய்வுத் திறன் (reviewability) முக்கியத்துவம் பெறுகிறது.
மறுபுறம், APX தற்போதைய தருணத்தில் இயங்குகிறது. இது உங்களுக்கும் மாடலுக்கும் இடையிலான உண்மையான உரையாடலை நிர்வகிக்கிறது. இதன் நோக்கம் அறிவைச் சேமிப்பதே அல்ல, மாறாக அதைத் துல்லியமாகப் பயன்படுத்துவதே ஆகும். APX திறன்களை நிரந்தரச் சுமையாகக் கருதும்போது, முழு அமைப்பும் மெதுவாகிறது. Context window நிரம்பிவிடுகிறது. டோக்கன் (token) செலவுகள் அதிகரிக்கின்றன. அதைவிட மோசமாக, தற்போதைய கோரிக்கையுடன் தொடர்பில்லாத அறிவுறுத்தல்களால் மாடலின் கவனம் சிதறுகிறது.
இதனால்தான் திறன் விவரங்கள் (skill bodies) தேவைப்படும்போது மட்டும் ஏற்றப்படுகின்றன (on demand).
ஒரு பருமனான பிராம்ப்ட்டின் (Bloated Prompt) உண்மையான விலை
டோக்கன்களுக்குப் பணம் செலவாகும் என்பதைப் பெரும்பாலான குழுக்கள் புரிந்துகொள்கிறார்கள். ஆனால் தேவையற்ற டோக்கன்கள் துல்லியத்தன்மையைக் (accuracy) குறைக்கின்றன என்பதை மிகச் சிலரே உணர்கிறார்கள்.
APX ஒவ்வொரு முறையும் கிடைக்கக்கூடிய அனைத்துத் திறன்களையும் உள்ளிடும்போது, பிராம்ப்ட் இரைச்சலாக (noisy) மாறுகிறது. மாடலுக்கு deployment runbook, பாதுகாப்பு வழிகாட்டி, API பாணி குறிப்பு, சோதனைப் பட்டியல் மற்றும் onboarding FAQ ஆகிய அனைத்தும் ஒரே நேரத்தில் கிடைக்கின்றன. ஒரு பெரிய context window இருந்தாலும், சிக்னலைக் (signal) கண்டறிய முதலில் இரைச்சலை (noise) வடிகட்ட வேண்டியிருக்கும் போது, மாடலின் பகுத்தறியும் திறன் (reasoning quality) குறைகிறது. உள்ளூர் சோதனை அமைப்பைப் (local test setup) பற்றிய கேள்விக்கு பதிலளிக்கும்போது, அது தயாரிப்பு பயன்பாட்டிற்கான (production deployments) பாதுகாப்புத் தேவையைத் தவறாகப் பிடித்துக்கொள்ளலாம். ஒரு சாதாரண பிழைத் திருத்தத்தின் (bug fix) போது, அது ஒரு வெளியீட்டுப் பட்டியலிலிருந்து (release checklist) படிநிலைகளைத் தவறாகக் கற்பனை செய்து கூறலாம் (hallucinate). தொடர்பில்லாத ஒவ்வொரு கூடுதல் பத்தியும் ஒரு கவனச்சிதறலாகும்.
இதன் கணக்கீடு எளிமையானது. பெரும்பாலான உரையாடல்களுக்கு பெரும்பாலான திறன்கள் தேவையில்லை. நீங்கள் ஒரு பிழைப் பதிவிற்கு (error log) விரைவான தீர்வை (quick fix) கேட்கும்போது, உங்களுக்கு ஒரு deployment runbook அல்லது பாதுகாப்பு வழிகாட்டியின் முழு உரை தேவையில்லை. மாடல் பிழையைப் பார்த்து, உங்கள் திட்டக் கட்டுப்பாடுகளைப் (project conventions) புரிந்துகொண்டு, சரியான கோப்பைத் திருத்த வேண்டும் என்பதே உங்களுக்குத் தேவை. தேவையற்ற திறன் விவரங்களை ஏற்றுவது மாடலுக்கு இதில் உதவாது. மாறாக, உங்கள் உண்மையான சிக்கலில் வேலை செய்யத் தொடங்குவதற்கு முன்பே, பயனற்ற தரவை வடிகட்ட அது மாடலைத் தூண்டுகிறது.
தேவைக்கேற்ப ஏற்றுதல் (On-Demand Loading) எவ்வாறு செயல்படுகிறது
இந்த நுட்பம் எளிமையானது ஆனால் திட்டமிடப்பட்டது. APC தொடர்ந்து உண்மையான தரவை (ground truth) வைத்திருக்கிறது. உங்கள் திறன் வரையறைகள் (skill definitions) அவை இருக்க வேண்டிய இடத்திலேயே இருக்கும்: .apc/skills/<name>.md-இல்.
APX அந்த கோப்புகளைச் செயலில் உள்ள நினைவகத்தில் (active memory) பிரதிபலிக்காது. அதற்குப் பதிலாக, அது திறன் பெயர்களின் ஒரு சுருக்கமான பதிவேட்டை (compact registry) உருவாக்குகிறது. மாடல் இந்த பட்டியலைப் பார்த்து, ஒரு பட்டியல் (catalog) இருப்பதை உணர்ந்து கொள்ளும். கிடைக்கக்கூடிய திறன்களைப் பார்க்க அல்லது உறுதிப்படுத்த வேண்டுமானால், அது list_skills அழைப்பைச் (call) செய்ய முடியும். இது அதிக அளவு தரவின்றி (volume) தெளிவான பார்வையை (visibility) வழங்குகிறது.
ஒரு பணிக்குத் துல்லியமான தொடரியல் (syntax), விரிவான படிநிலைகள் அல்லது ஒரு திறன் கோப்பில் குறியீடு செய்யப்பட்ட குறிப்பிட்ட கட்டுப்பாடுகள் தேவைப்படும்போது, மாடல் load_skill-ஐ அழைக்கிறது. அந்தத் தருணத்தில் மட்டுமே, APX முழுமையான Markdown உள்ளடக்கத்தை APC-யிலிருந்து எடுத்து பிராம்ப்ட்டில் சேர்க்கிறது. அந்த அறிவுறுத்தல் தேவைப்படும்போது மட்டும் வந்து, அதன் நோக்கத்திற்காக ஒருமுறை பயன்படுத்தப்படுகிறது; இதனால் சிஸ்டம் அதை ஒரு தேவையற்ற சுமையாகச் சுமந்து திரிய வேண்டியதில்லை.
ஒரு லைப்ரரியை (library) இறக்குமதி செய்வதற்கும் (importing), ஒவ்வொரு செயல்பாட்டு வரையறையையும் (function definition) உங்கள் முதன்மை கோப்பில் ஒட்டுவதற்கும் (pasting) இடையிலான வித்தியாசத்தை நினைத்துப் பாருங்கள். ஒரு அணுகுமுறை உங்கள் குறியீட்டுத் தளத்தை (codebase) எளிதாகக் கையாள உதவும். மற்றொன்று ஒரு குழப்பத்தை உருவாக்கி, தற்செயலாக மட்டுமே இயங்கும் (compiles by accident) நிலையை ஏற்படுத்தும்.
திறன்கள் மோதும்போது யார் வெற்றி பெறுவார்கள்
APX திறன்களை ஏற்றும்போது ஒரு தெளிவான முன்னுரிமை வரிசையையும் (priority order) நடைமுறைப்படுத்துகிறது. எல்லாச் சூழல்களும் (environments) ஒன்றல்ல, பொதுவான ஆலோசனைகள் ஒருபோதும் உள்ளூர் அறிவை (local knowledge) விட மேலோங்கி இருக்கக்கூடாது.
திட்டத் திறன்கள் (Project skills) முதன்மையான முன்னுரிமையைப் பெறுகின்றன. இந்த கோப்புகள் உங்கள் தற்போதைய repository-இல் .apc/skills/ என்பதன் கீழ் இருக்கும். இவை உங்கள் குழுவின் குறிப்பிட்ட விதிமுறைகள், உங்கள் தனிப்பயனாக்கப்பட்ட wrappers, உங்கள் பழைய பெயரிடல் தரநிலைகள் மற்றும் உங்கள் குறிப்பிட்ட toolchain ஆகியவற்றை உள்ளடக்கியது. உங்கள் திட்டம் தரவுத்தள இடமாற்றங்களை (database migrations) கையாள்வதற்குத் தனக்கென ஒரு முறையை வரையறுத்தால், அந்த வரையறைதான் இறுதியானது.
அடுத்ததாக Global skills வருகின்றன. திட்டம் எதையும் குறிப்பிடாதபோது, நிறுவனம் முழுவதற்கும் பொருந்தும் பொதுவான முறைகளை இவை உள்ளடக்குகின்றன. இவை ஒரு standard library போலச் செயல்படுகின்றன.
Built-in runtime skills மிகக் கடைசியாக, ஒரு மாற்று வழியாக (fallback) அமைகின்றன. ஒவ்வொரு ஏஜென்ட்டும் (agent) புரிந்துகொள்ள வேண்டிய பொதுவான திறன்களை இவை கையாளுகின்றன, ஆனால் எந்தவொரு குறிப்பிட்ட திட்டமும் இவற்றை மறுவரையறை செய்யத் தேவையில்லை.
இந்த அடுக்குமுறை அணுகுமுறை மூலம், உங்கள் repository தனது சொந்த செயல்பாட்டின் மீது கட்டுப்பாட்டைத் தக்கவைத்துக் கொள்கிறது. உங்கள் குழுவினர் வேண்டுமென்றே தனிப்பயனாக்கிய ஒரு பணிப்பாய்வை (workflow), ஒரு global அல்லது built-in திறன் தற்செயலாகக் கையகப்படுத்த முடியாது.
இது நடைமுறையில் எப்படி இருக்கும்
ஒரு சாதாரண பராமரிப்புப் பணியைக் கற்பனை செய்து பாருங்கள். ஒரு குழு உறுப்பினர் சாட்டில் (chat) ஒரு பிழைப் பதிவை (error log) ஒட்டுகிறார். அந்த traceback ஒரு utility module-இல் உள்ள ஒரு தனிப்பட்ட null reference-ஐக் காட்டுகிறது. அதற்கான தீர்வு பெரும்பாலும் இரண்டு வரிகள் கொண்ட defensive coding ஆகத்தான் இருக்கும்.
தேவைக்கேற்ப ஏற்றும் (on-demand loading) வசதி இல்லாத ஒரு அமைப்பில், APX தனக்குத் தெரிந்த அனைத்துத் திறன்களையும் சூழலில் (context) திணிக்கும். அந்த இரண்டு வரிகளைத் தொடுவதற்கு முன்பே, அந்த மாடல் (model) நாற்பது பக்க உரையைப் பரிசீலிக்க வேண்டியிருக்கும். அது release checklist-ஐப் பார்த்து, பதிப்பைப் (version) புதுப்பிக்க வேண்டுமா என்று யோசிக்கும். அது security guide-ஐப் பார்த்து, வெறும் null check மட்டும் தேவைப்படும் ஒரு செயல்பாட்டிற்கு (function) input validation செய்ய வேண்டுமா என்று சிந்திக்கும். அது deployment runbook-ஐப் பார்த்து, staging environments பற்றிச் சிந்திக்கத் தொடங்கும். இதனால் மாடல் திசைமாறுகிறது. பதில் கிடைக்க அதிக நேரம் எடுக்கிறது. Token அளவு வேகமாக அதிகரிக்கிறது.
APX-இன் on-demand வடிவமைப்பால், மாடல் பெயர்களை மட்டுமே பார்க்கும். [release-checklist], [security-guide], [deployment-runbook], மற்றும் [error-handling] ஆகியவை இருப்பதை அது அறியும். அது முதல் மூன்றையும் புறக்கணிக்கும். உங்கள் திட்டத்தின் null safety விதிமுறைகள் குறிப்பிட்டதாக இருந்தால், அது [error-handling] திறனை ஏற்றலாம். அது பிழையைச் சரிசெய்யும். தொடர்பில்லாத திறன்கள் சூழல் சாளரத்திற்குள் (context window) வந்ததே இல்லை. Prompt சுத்தமாக இருந்ததால், மாடல் கவனத்துடன் இருந்தது.
பணி உண்மையில் சிக்கலானதாக இருக்கும்போதும் இதே தர்க்கம் பொருந்தும். நீங்கள் பின்னர் ஒரு production deployment-ஐத் தயார் செய்யுமாறு ஏஜென்ட்டிடம் கேட்டால், அந்தப் படிநிலைகள் தேவைப்படும்போது அது deployment runbook-ஐ ஏற்றவும், security guide-ஐ ஆலோசிக்கவும் மற்றும் release checklist-ஐப் பின்பற்றவும் முடியும். அந்த அறிவு எப்போதும் அங்கேயே இருந்தது. அது சரியான தருணத்திற்காகக் காத்திருந்தது, அவ்வளவுதான்.
கட்டமைப்பு ரீதியான Prompt ஒழுக்கம்
APC மற்றும் APX இடையிலான வேறுபாடு என்பது வெறும் செயல்படுத்தும் முறை பற்றிய விவரம் மட்டுமல்ல. அது prompt ஒழுக்கம் குறித்த ஒரு தத்துவம். APC அறிவை என்றென்றும் பாதுகாக்கிறது, அதன் மூலம் அதை மறுஆய்வு செய்யவும், பதிப்புப்படுத்தவும் (versioned) மற்றும் பாதுகாப்பாக வைத்திருக்கவும் முடியும். APX அந்த அறிவில் எவ்வளவு இப்போது செயல்பாட்டுச் சூழலில் (active context) இருக்க வேண்டும் என்பதைத் தீர்மானிக்கிறது.
ஒரு சிறந்த திறன் பட்டியல் (skill catalog) ஒரு சொத்து. ஆனால் அதிகப்படியான தகவல்கள் கொண்ட prompt ஒரு சுமை. உங்கள் சூழலை (context) எப்போதும் செயல்பாட்டில் வைத்திருக்காமல், அதை எளிதாகக் கையாளக்கூடியதாக (portable) வைத்திருப்பதே இலக்கு. உங்கள் repository-இல் உங்கள் குழு எழுதிய அனைத்து அறிவுறுத்தல்களும் இருக்க வேண்டும், ஆனால் ஏஜென்ட் உடனடிப் பணிக்கு உதவும் அறிவுறுத்தல்களை மட்டுமே படிக்க வேண்டும்.
உங்கள் அமைப்பு ஒவ்வொரு முறையும் மாடல் அனைத்துத் திறன்களையும் சுமந்து செல்லுமாறு கட்டாயப்படுத்தினால், நீங்கள் ஒரு புத்திசாலித்தனமான உதவியாளரை உருவாக்கவில்லை. மாறாக, ஒவ்வொரு கேள்விக்கும் முழு ஆவணக் காப்பகத்தையும் இழுத்து வரும் ஒரு நூலகரைத்தான் உருவாக்குகிறீர்கள். அனைத்தையும் சேமித்து வையுங்கள். முக்கியமானவற்றை மட்டும் ஏற்றவும். அவ்வாறு செய்வதன் மூலம் மட்டுமே ஏஜென்ட்களை வேகமாகவும், சூழலைச் சுத்தமாகவும் மற்றும் சிந்தனைத் திறனைத் துல்லியமாகவும் வைத்திருக்க முடியும்.