எனது OpenClaw உள்ளமைப்பை (config) நான் 48 மணிநேரம் தீவிரமாகச் சோதித்தேன்
பெரும்பாலான மக்கள் OpenClaw-ஐ ஐந்து நிமிடங்கள் மட்டுமே சோதிப்பார்கள். அவர்கள் சில செய்திகளை அனுப்புவார்கள். அது வேலை செய்தால், அதைத் தயாரிப்பு நிலைக்குத் தயாரானது (production-ready) என்று கூறிவிடுவார்கள்.
நான் வித்தியாசமாகச் செய்தேன். எனது ஏஜென்ட்டை (agent) ஒரு முழு வார இறுதி முழுவதும் இயங்கவிட்டேன்.
நான் மூன்று அமைதியான தோல்விகளைக் (silent failures) கண்டறிந்தேன். அவை அமைப்பை முடக்கவில்லை (crash). அவை எனக்குப் பணத்தையும் நேரத்தையும் மட்டுமே வீணடித்தன.
எவை முறிந்து போயின மற்றும் நான் அவற்றை எவ்வாறு சரி செய்தேன் என்பது இதோ.
- சூழல் சிதைவு (Context Decay) 18 மணிநேரத்திற்குப் பிறகு, மாடல் பதில்கள் மிகக் குறைவாகவும் சுருக்கமாகவும் மாறின. அது பிழையைக் காட்டவில்லை (error out). அது வெறுமனே சூழல் இடத்தைப் (context space) பயன்படுத்தாமல் போயிருந்தது. அமர்வு வரலாறு (session history) மிகப் பெரியதாக வளர்ந்தது. இடத்தைச் சேமிக்க மாடல் தனது சொற்களைக் குறைவாகப் பயன்படுத்தத் தொடங்கியது.
தீர்வு: ஒரு அமர்வு நீக்கக் கொள்கையை (session purge policy) அமைக்கவும்.
- வரலாற்றை 50 செய்திகளாகக் கட்டுப்படுத்தவும்.
- ஒவ்வொரு 12 மணிநேரத்திற்கும் அமர்வை மீட்டமைக்கவும் (reset). இது கைமுறை வேலை இன்றி சூழலைத் (context) புத்துணர்ச்சியுடன் வைத்திருக்கும்.
- பணித் தேக்கங்கள் (Task Backlogs) ஒவ்வொரு 15 நிமிடங்களுக்கும் பணிகளை இயக்க நான் ஒரு cron job-ஐப் பயன்படுத்தினேன். சில நேரங்களில் மெதுவான API-களால் ஒரு பணி 15 நிமிடங்களுக்கு மேல் எடுத்துக்கொண்டது. முதல் பணி இன்னும் இயங்கிக்கொண்டிருக்கும்போதே அடுத்த பணி தொடங்கத் தொடங்கியது. இது பணிகளின் ஒரு வளர்ந்து வரும் வரிசையை (queue) உருவாக்கியது.
தீர்வு: ஒரு lockfile உடன் mutex guard-ஐச் சேர்க்கவும்.
- lockfile இருக்கிறதா என்று சரிபார்க்கவும்.
- lockfile 15 நிமிடங்களுக்கும் குறைவாகவே பழமையானது என்றால், புதிய இயக்கத்தைத் தவிர்க்கவும்.
- இது பணிகள் குவிவதைத் தடுக்கிறது.
- கண்ணுக்குத் தெரியாத செலவுகள் (Invisible Costs) எனது முதன்மை மாடல் ஒரு விகித வரம்பை (rate limit) எட்டியபோது, OpenClaw ஒரு மாற்று மாடலுக்கு (fallback model) மாறியது. பணி வெற்றிகரமாக முடிந்தது. இருப்பினும், மாற்று மாடல் ஒவ்வொரு டோக்கனுக்கும் (token) 4 மடங்கு அதிக செலவைச் செய்தது. பதிவுகள் (logs) அனைத்தும் சரியாக இருப்பதாகக் கூறின, ஆனால் எனது பட்ஜெட் வேகமாகத் தீர்ந்து கொண்டிருந்தது.
தீர்வு: தெளிவான செலவுக் கண்காணிப்பைச் சேர்க்கவும்.
- ஒவ்வொரு இயக்கத்திற்குப் பிறகும் டோக்கன் பயன்பாடு மற்றும் செலவைப் பதிவு செய்யவும்.
- வாரந்தோறும் மாடல் வாரியான செலவுகளை ஆய்வு செய்யவும்.
OpenClaw நம்பகமானது, ஆனால் அது எப்போதும் அப்படி இருக்காது. நீங்கள் கவனித்துக் கொண்டிருக்காத போதுதான் பொதுவாகத் தோல்விகள் நிகழ்கின்றன.
இந்த சிக்கல்களைச் சரிசெய்ய நான் 2 மணிநேரம் செலவிட்டேன். 48 மணிநேரச் சோதனைக்கு டோக்கன்களுக்காக எனக்கு 20 டாலர்கள் செலவானது. எனது அமைப்பு மேற்பார்வை இன்றி பல நாட்களுக்கு இயங்குவதை உறுதி செய்ய இது ஒரு நியாயமான வர்த்தகம்.
உங்கள் உள்ளமைப்பை (config) குறைந்தது ஒரு முழு நாளுக்குக் கூட தீவிரமாகச் சோதிக்கவில்லை என்றால், நீங்கள் தயாரிப்பு நிலைக்குத் தயாராக இல்லை.
Optional learning community: https://t.me/GyaanSetuAi
