ពេល Agent កាន់តែអាក្រក់ ពេលវាដំណើរការកាន់តែយូរ

រឿងបរាជ័យភាគច្រើនអំពី coding agent គឺអំពីចម្លើយអាក្រក់តែមួយ៖ agent អានភារកិច្ចខុស ប្រឌិត API, ដឹក bug ចេញ។ ប៉ុន្តែមានរបៀបបរាជ័យស្ងាត់ជាង និងថ្លៃជាង ដែលលេចឡើងតែពេលអ្នកឱ្យ agent បន្តធ្វើការ។ វាមិនបរាជ័យនៅវេនទីមួយទេ។ វាជោគជ័យ — ហើយបន្ទាប់មកវាជោគជ័យម្ដងទៀត ហើយម្ដងទៀត ហើយជាមួយរាល់ iteration ដែលកន្លងផុត កូដដែលវាកំពុងសាងសង់កាន់តែអាក្រក់បន្តិច រហូតដល់អ្វីដែលចាប់ផ្ដើមជាដំណោះស្រាយស្អាតក្លាយជារបស់ដែលហើម ស្មុគស្មាញ ដែលតាមបច្ចេកទេសឆ្លងកាត់ការត្រួតពិនិត្យរបស់វា ហើយវេទនាក្នុងការថែទាំ។ Agent កាន់តែ អាក្រក់ ពេលវាដំណើរការកាន់តែយូរ ហើយសម្រាប់ផ្នែកភាគច្រើននៃ run នោះ គ្មាននរណាកត់សម្គាល់ទេ។

នេះមិនមែនជាអារម្មណ៍ទេ។ ក្នុងឆ្នាំ ២០២៦ សំណុំការវាស់ស្ទង់មួយត្រូវបានសាងសង់ឡើងជាក់លាក់ដើម្បីវាស់ឥរិយាបថ agent long-horizon ហើយលេខគួរឱ្យព្រួយ។ ពួកវាប្រាប់រឿងស៊ីសង្វាក់៖ agent ខ្សោយជាងច្រើនលើការងារទ្រទ្រង់ iterative កម្រិតពិតប្រាកដ ជាងអ្វីដែលការវាស់ស្ទង់ single-shot បង្ហាញ — ហើយផ្នែកធំនៃគម្លាតនោះជាការ degradation ដែលធ្វើដោយខ្លួនឯង។

ការវាស់ស្ទង់ដែលសាងសង់ឡើងដើម្បីវាស់ decay

មុតស្រួចបំផុតក្នុងចំណោមនេះគឺ SlopCodeBench (arXiv 2603.24755) ហើយការរចនាទាំងមូលរបស់វាសំដៅទៅបញ្ហាខាងលើ។ ជំនួសឱ្យភារកិច្ច one-shot វាផ្ដល់ឱ្យ agent នូវ specification ដែលវិវត្ត ហើយធ្វើឱ្យវា ពង្រីកដំណោះស្រាយដំបូងផ្ទាល់របស់វាដដែលៗ — បញ្ហា ៣៦ ឆ្លងកាត់ checkpoint ១៩៦ — ខណៈទុករចនាសម្ព័ន្ធខាងក្នុងនៃកូដទាំងស្រុងឱ្យ agent។ ផ្នែកចុងក្រោយនោះសំខាន់៖ ការវាស់ស្ទង់ iterative ភាគច្រើនកំណត់លំហរចនាតឹងពេក រហូតអ្នកមិនអាចមើលឃើញពីរបៀបដែលការសម្រេចចិត្តដំបូងរបស់ agent ពុលដល់ការសម្រេចចិត្តក្រោយៗ។ SlopCodeBench ដោយចេតនាមិនធ្វើដូច្នេះទេ។

លទ្ធផលចំណងជើងគ្រោងបាក់។ ឆ្លងកាត់ coding agent ១៥ ទាំងបើកនិងបិទ គ្មាន agent ណាដោះស្រាយបញ្ហាតែមួយ end-to-end ពេញលេញ ហើយ agent ល្អបំផុតឆ្លងកាត់តែ ១៤,៨% នៃ checkpoint។ ប៉ុន្តែលេខគួរឱ្យចាប់អារម្មណ៍ជាងគឺអំពី គុណភាពតាមពេលវេលា។ ការវាស់ស្ទង់តាមដាន decay ពីរប្រភេទ៖ ការសឹករិចរិលរចនាសម្ព័ន្ធ (ភាពស្មុគស្មាញកកកុញនៅកន្លែងខុស) និង ភាពច្រើនពាក្យ (កូដច្រំដែល ហើម)។ ការសឹករិចរិលរចនាសម្ព័ន្ធកើនឡើងឆ្លងកាត់ checkpoint ក្នុង ៧៧% នៃគន្លង ឯភាពច្រើនពាក្យកើនឡើងក្នុង ៧៥,៥%។ បើប្រៀបធៀបនឹង repository Python open-source ពិតប្រាកដ ៤៧៣ កូដ agent មាន ពាក្យច្រើនជាង ២,៣ ដង និងសឹករិចរិលជាង ២,០ ដង — ឯ repository របស់មនុស្ស ដែលវាស់ឆ្លងកាត់ប្រវត្តិ git ផ្ទាល់របស់ពួកវា ថយចុះ តិចជាង និងតិចតួចជាង។

ម្យ៉ាងទៀត៖ agent ឆ្លងកាត់ checkpoint ខណៈផលិតកូដដែល សឹករិចរិល និងហើមជាមួយរាល់វេន។ ភារកិច្ចត្រូវបានបញ្ចប់។ Codebase កាន់តែអាក្រក់។ នោះជា slop ហើយវាកកកុញ។

វាមិនត្រឹមតែ “slop” ទេ — horizon វែងខ្លួនវាពិបាក

អ្នកអាចអាន SlopCodeBench ជារឿងគុណភាពកូដ។ ការវាស់ស្ទង់ដៃគូពីរបង្ហាញថាវាក៏ជារឿងសមត្ថភាពឆៅផងដែរ៖ agent ដួលរលំនៅកម្រិតវិស្វកម្មពិតប្រាកដ។

RoadmapBench (arXiv 2605.15846) ចាក់គ្រឹះភារកិច្ចរបស់វាក្នុងការ upgrade កំណែ open-source ពិតប្រាកដ — ភារកិច្ច long-horizon ១១៥ ឆ្លងកាត់ repository ១៧ និងភាសា ៥ ដោយនីមួយៗតម្រូវ មេដ្យាន ៣.៧០០ បន្ទាត់នៃការផ្លាស់ប្ដូរ ឆ្លងកាត់ឯកសារ ៥១។ នេះជាអ្វីដែល iteration កំណែពិតប្រាកដមើលទៅ មិនមែនការជួសជុល bug ឯកសារតែមួយ។ សាកល្បងលើ frontier model ដប់បី ខ្លាំងបំផុត — Claude-Opus-4.7 — ដោះស្រាយតែ ៣៩,១% នៃភារកិច្ច ខណៈខ្សោយបំផុតគ្រប់គ្រងបាន ៥,២%។ អ្នកនិពន្ធត្រង់ៗថានេះ “ផ្ទុយយ៉ាងខ្លាំងនឹងការវាស់ស្ទង់ជួសជុល bug ដែលមានស្រាប់” ដែលពិន្ទុខ្ពស់ជាងច្រើន៖ បង្រួម horizon ហើយ agent មើលទៅល្អ ពង្រីកវាទៅកម្រិតពិតប្រាកដ ហើយសមត្ថភាពភាគច្រើនរលាយបាត់។

AgencyBench (arXiv 2601.11044) រុញ horizon ឱ្យឆ្ងាយជាងទៀត — សេណារីយ៉ូពិភពពិត ៣២ ភារកិច្ច ១៣៨ ដោយនីមួយៗតម្រូវ ជាមធ្យម ការហៅឧបករណ៍ ៩០, token ១ លាន និងម៉ោងនៃការ execution ដើម្បីដោះស្រាយ។ សូម្បីថ្នាក់ model ល្អបំផុត គឺប្រព័ន្ធ frontier closed-source ប៉ះតែ ៤៨,៤% (ធៀបនឹង ៣២,១% សម្រាប់ open-source)។ ពេលភារកិច្ចតែមួយចំណាយការហៅឧបករណ៍កៅសិប និង token មួយលាន រាល់ភាពខ្សោយក្នុងការវែកញែកទ្រទ្រង់ទទួលបានឱកាសកៅសិបក្នុងការគុណ។

ដាក់ទាំងបីបញ្ចូលគ្នា ហើយលំនាំមិនអាចច្រឡំបាន។ ការវាស់ស្ទង់ដែល agent ភ្លឺគឺខ្លី។ ពេល horizon វែង — iteration ច្រើន ឯកសារច្រើន ការហៅឧបករណ៍ច្រើន — ដំណើរការដួលរលំ ហើយចំណែកមានន័យនៃការដួលរលំនោះគឺ agent degrade ការងារផ្ទាល់របស់វាតាមផ្លូវ។

ហេតុអ្វីគុណភាពថយចុះពេល iteration កើនឡើង

វាមានតម្លៃក្នុងការ​ច្បាស់លាស់អំពី ហេតុអ្វី រឿងនេះកើតឡើង ព្រោះវាជាយន្តការខុសពីយន្តការដែលយើងបានគ្របដណ្ដប់ក្នុង វិស្វកម្ម context។ Context rot គឺអំពី recall របស់ model ថយចុះពេល window ពេញដោយសំឡេងរំខាន — បញ្ហានៃការយល់ឃើញ។ Long-horizon degradation ស្ថិតនៅខាងក្រោមនោះ ប៉ុន្តែខុសគ្នា៖ វាអំពី artifact ថយចុះពេលរាល់វេនសាងសង់លើវេនមុន។

នេះជា loop គុណ។ Agent ធ្វើការជ្រើសរើសរចនាសម្ព័ន្ធដំបូង — function ទូលាយបន្តិចពេក, ផ្លូវកាត់, abstraction ដែលបាត់។ Checkpoint បន្ទាប់ស្នើឱ្យវាពង្រីកកូដនោះ។ ជាជាង refactor (ដែលប្រថុយ ហើយគ្មានអ្វីក្នុង loop រង្វាន់) វាបាញ់ feature ថ្មីភ្ជាប់ទៅទម្រង់ដែលមានស្រាប់។ ឥឡូវគ្រឹះសឹករិចរិលបន្តិច ហើយការពង្រីក បន្ទាប់ ត្រូវសាងសង់លើ នោះ។ រាល់វេនឆ្លងកាត់ checkpoint របស់វា ដូច្នេះគ្មានសញ្ញាថាមានអ្វីខុស — ប៉ុន្តែរចនាសម្ព័ន្ធកំពុងប្រមូលផ្ដុំភាពស្មុគស្មាញ និងកកកុញភាពច្រំដែលស្ងាត់ៗ។ ត្រឹម checkpoint ម្ភៃ agent កំពុងវែកញែកលើ codebase ដែលវេនដំបូងផ្ទាល់របស់វាធ្វើឱ្យពិបាកវែកញែកជាង។ Slop បង្កើត slop។

នេះជាហេតុអ្វីវាភ្ជាប់ត្រង់ៗទៅចំណុចដែលយើងបានធ្វើពីមុន៖ loop អាក្រក់ដឹកកូដអាក្រក់លឿនជាង។ Run ស្វយ័តវែងដោយគ្មាន quality gate មិនត្រឹមតែប្រថុយ commit អាក្រក់មួយទេ — វាប្រថុយការសឹករិចរិលយឺតៗដែលមើលមិនឃើញរហូតដល់អ្នកអាន diff។ ការវាស់ស្ទង់ថែមទាំងសាកល្បងការដោះស្រាយជាក់ស្ដែង៖ ការណែនាំគុណភាពច្បាស់លាស់ក្នុង prompt។ វាជួយ ចំណុចចាប់ផ្ដើម — កាត់បន្ថយភាពច្រើនពាក្យ និងការសឹករិចរិលដំបូងរហូតដល់មួយភាគបី — ប៉ុន្តែវា មិនផ្លាស់ប្ដូរអត្រា degradation ទេ។ ប្រាប់ agent ថា “សរសេរកូដស្អាត” ធ្វើឱ្យវេនទីមួយស្អាតជាង។ វាមិនធ្វើអ្វីចំពោះជម្រាលនៃការធ្លាក់ចុះទេ។

Harness មិនមែន prompt ជាដំណោះស្រាយ

បើការណែនាំគុណភាពមិនអាចបញ្ឈប់ decay អ្វីអាច? ចម្លើយស្មោះត្រង់ពីអក្សរសិល្ប៍ agent ដែលដំណើរការយូរគឺ រចនាសម្ព័ន្ធ មិនមែនពាក្យសំដី — ហើយវាជាវិន័យដូចគ្នាដែលយើងតែងតែត្រឡប់មកវិញ៖ loop ត្រូវតែរចនា មិនមែនត្រឹមតែ prompt។

ចលនាបីធ្វើការលើកធ្ងន់។ កំណត់វិសាលភាពឯកតាការងារនីមួយៗឱ្យតូច។ ខ្សែកោង degradation ជា function នៃចំនួនវេនដែលជិះលើគ្រឹះសឹករិចរិលដដែល បើអ្នកបំបែក feature ទៅភារកិច្ចរងឯករាជ្យ មានព្រំដែនល្អ ឯកតានីមួយៗចាប់ផ្ដើមពី baseline រចនាសម្ព័ន្ធស្អាត ជាជាងទទួលមរតក slop ម្ភៃវេន។ កំណត់ context ឡើងវិញក្នុងភារកិច្ចនីមួយៗ។ Window ស្រស់សម្រាប់ឯកតាដែលកំណត់វិសាលភាពនីមួយៗបដិសេធ rot នូវកន្លែងកកកុញ — state គង់វង្សរស់នៅក្នុង artifacts មិនមែនក្នុងប្រតិចារិកដែលរីកធំជានិច្ច។ ហើយ checkpoint ជាមួយចំណុចសង្គ្រោះពិតប្រាកដ។ Commit state ដែលដំណើរការទៅ git បន្ទាប់ពីឯកតាដែលផ្ទៀងផ្ទាត់នីមួយៗ ដូច្នេះ branch ដែល degrade អាចបោះបង់ ជាជាងពង្រីក។ នេះពិតជាស្ថាបត្យកម្មពីរផ្នែក feature មួយក្នុងពេលតែមួយ ដែលយើងបានពិពណ៌នាក្នុង harness ជាផលិតផល៖ initializer ដែលរៀបចំ state គង់វង្ស បន្ទាប់មក coding agent ដែលជ្រើស feature មួយ ផ្ទៀងផ្ទាត់វា end-to-end commit ហើយប្រគល់ artifacts ស្អាតទៅវគ្គបន្ទាប់។

គំនិតរួបរួម៖ degradation ជាលក្ខណៈនៃរូបរាងរបស់ loop មិនមែន IQ របស់ model ទេ។ Frontier model ក្នុង loop long-horizon ដែលអាក្រក់នឹងសឹករិចរិលការងារផ្ទាល់របស់វា។ Model មធ្យមក្នុង loop ដែលកំណត់វិសាលភាពតឹង ផ្ទៀងផ្ទាត់ខ្លាំង និងកំណត់ឡើងវិញញឹកញាប់ នឹងរក្សាគុណភាពយូរជាងច្រើន។ ការវាស់ស្ទង់វាស់ agent ក្នុង run វែង មិនដាច់ ពិតព្រោះនោះជាករណីពិបាកបំផុត — ហើយវាជាករណីដែល harness ល្អត្រូវបានរចនាដើម្បីជៀសវាងមិនឱ្យចូលដែរ។

ហេតុអ្វីនេះអនុគ្រោះអាស៊ីអាគ្នេយ៍

នេះជាផ្នែកដែលសំខាន់សម្រាប់តំបន់នេះ ហើយវាជាអំណះអំណាងដូចគ្នាដែលធ្វើឱ្យមុតស្រួច។ ដំណោះស្រាយសម្រាប់ long-horizon degradation មិនមែន model ធំជាង ឬ GPU ច្រើនជាងទេ — វាជា ការវិនិច្ឆ័យអំពីការបំបែក ការផ្ទៀងផ្ទាត់ និងពេលណាត្រូវកំណត់ឡើងវិញ។ នោះជាវិស្វកម្មប្រព័ន្ធ ហើយវាដំណើរការលើ laptop។

ក្រុមដែលធ្វើឱ្យរឿងនេះក្លាយជារបស់ខ្លួនមានគែមពិតប្រាកដ។ សភាវគតិដែលអ្នកឯទៀតៗកំពុងតាម — ចង្អុល frontier agent ទៅភារកិច្ចធំ ហើយឱ្យវាដំណើរការច្រើនម៉ោង — ពិតជារបបដែលការវាស់ស្ទង់ទាំងនេះបង្ហាញ decay អាក្រក់បំផុត និងវិក្កយបត្រ token ខ្ពស់បំផុត។ ក្រុមនៅភ្នំពេញ ឬ Da Nang ដែលផ្ទុយទៅវិញកំណត់វិសាលភាពការងារទៅឯកតាដែលផ្ទៀងផ្ទាត់តូចៗ ទទួលលទ្ធផល ល្អជាង សម្រាប់ token តិចជាង ដែលដូចយើងបានអះអាងក្នុង សេដ្ឋកិច្ចនៃ agentic AI ជាឥទ្ធិពលដែលគុណពិតប្រាកដ។ ការហៅឧបករណ៍កៅសិប និង token មួយលានក្នុងភារកិច្ចមួយជាផ្ទៃចំណាយដ៏ធំ វិន័យដែលបង្រួម horizon បង្រួមវិក្កយបត្រក្នុងពេលដែលវាលើកគុណភាព។

ហើយវាគង់វង្ស។ ការដឹង របៀបរក្សា run វែងពីការ rot — កន្លែងណាត្រូវកាត់ភារកិច្ច gate អ្វីត្រូវបញ្ចូល ពេលណាត្រូវបោះ branch ហើយចាប់ផ្ដើមស្រស់ — ជាការវិនិច្ឆ័យវិស្វកម្មដែលឈ្នះមកដោយលំបាក ដែលគ្មានការចេញ model ណាធ្វើឱ្យលែងប្រើ។ Frontier lab នឹងបន្តដឹក agent ដែលអាចដំណើរការយូរជាង។ អ្វីដែលវាមិនអាចដឹកគឺវិន័យក្នុងការដំណើរការពួកវា ឱ្យបានល្អ។ វិន័យនោះជាជំនាញភាពជឿជាក់ដែលត្រូវបានគេមើលស្រាលបំផុតក្នុង stack agentic ហើយវាមានសម្រាប់នរណាម្នាក់ដែលសុខចិត្តរចនា loop ជាជាងទុកចិត្ត run។