ខាងក្នុង Agent Loop៖ លំនាំនៅពីក្រោយ AI Agent ដែលអាចទុកចិត្តបាន

នៅក្នុងអត្ថបទចុងក្រោយរបស់យើង យើងបានលើកឡើងថា ការសរសេរកូដកំពុងក្លាយជារង្វិលជុំ មិនមែនជាការគោះគ្រាប់ចុចទេ៖ ហៅ model ដំណើរការឧបករណ៍ បញ្ជូនលទ្ធផលត្រឡប់មកវិញ ហើយធ្វើម្ដងទៀត។ នោះជាចំណងជើង។ អត្ថបទនេះគឺជាវិស្វកម្មនៅពីក្រោមវា។

ព្រោះនេះជារឿងដែលគ្រប់ក្រុមដែលសាងសង់ agent ទីបំផុតរកឃើញ៖ ការប្ដូរទៅ model ឆ្លាតជាងមុន កម្រនឹងជួសជុល agent ដែលមិនស្ថិតស្ថេរបានទេ។ អ្នកធ្វើ upgrade ពី frontier model មួយទៅមួយបន្ទាប់ មើលឃើញ benchmark របស់អ្នកកើនពីរពិន្ទុ ហើយ agent របស់អ្នកនៅតែ loop គ្មានទីបញ្ចប់លើភារកិច្ចដដែល នៅតែភ្លេចអ្វីដែលវាបានរៀនកាលពីដប់ជំហានមុន នៅតែប្រកាសជ័យជម្នះលើកូដដែលមិនដំណើរការ។ ភាពឆ្លាតវៃប្រសើរឡើង។ Agent មិនបានប្រសើរទេ។

មូលហេតុគឺថា agent មិនមែនជា model ទេ។ Agent គឺជារង្វិលជុំដែលមានរចនាសម្ព័ន្ធ (loop with structure) — ហើយរចនាសម្ព័ន្ធនោះគឺជាកន្លែងដែលភាពអាចទុកចិត្តបានត្រូវ​ឈ្នះ ឬ​ចាញ់។ នេះជាផ្នែកដែលមិនសមនៅក្នុង tweet បង្ហាញ ដូច្នេះវាត្រូវបានគេមិនយកចិត្តទុកដាក់។ កុំឱ្យយើងមិនយកចិត្តទុកដាក់វា។ នេះជាលំនាំ agent loop ដែលត្រូវបានវិភាគ។

Loop ក្នុងមួយដង្ហើម

ចាប់ផ្ដើមពីស្នូលដែលមិនអាចបំបែកបាន។ ដូចដែល Simon Willison និយាយ agent គឺជា “អ្វីមួយដែលដំណើរការឧបករណ៍នៅក្នុង loop ដើម្បីសម្រេចគោលដៅ”។ កំណែតិចតួចបំផុតពិតជា while loop មែន៖ ផ្ដល់គោលដៅ និងឧបករណ៍មួយចំនួនដល់ model ឱ្យវាស្នើសុំ tool call មួយ ដំណើរការឧបករណ៍ បញ្ជូនលទ្ធផលត្រឡប់ ហើយធ្វើម្ដងទៀតរហូតដល់វាប្រាប់ថាវាបានចប់។

អ្នកអាចសាងសង់វាក្នុងពេលរសៀលមួយ។ អ្វីដែលអ្នក មិនអាច សាងសង់ក្នុងពេលរសៀលមួយ គឺ loop ដែលនៅជាប់លាប់រហូតដល់ហាសិបជំហាន មិនបំផ្ទុះថវិកា context របស់វា និងមិនចែកចាយការងារខូចដោយទំនុកចិត្ត។ Naive loop និង reliable loop មានគ្រោងឆ្អឹងដូចគ្នា ប៉ុន្តែមានអត្រារស់រានមានជីវិតខុសគ្នាទាំងស្រុង។ ភាពខុសគ្នាគឺជាអ្វីៗទាំងអស់ដែលយើងរៀបនឹងពិពណ៌នា — ដោយរួមគ្នាគឺ harness៖ runtime ដែលមិនមែនជា model ដែលរុំ​រង្វិលជុំ​នៃ​ការវែកញែក​ជាមួយ tool dispatch ការគ្រប់គ្រង context សុវត្ថិភាព និង verification។ ដូចដែលសៀវភៅណែនាំរបស់ Firecrawl អំពី agent harness រៀបរាប់ model គឺគ្រាន់តែជាពាក់កណ្ដាលនៃប្រព័ន្ធ harness គឺជាពាក់កណ្ដាលម្ខាងទៀត ហើយវាជាពាក់កណ្ដាលដែលអ្នកទិញភាគច្រើនមិនដឹងថាមាន។

ដំណាក់កាលនៃ loop ពិតប្រាកដមួយ

Agent loop កម្រិតផលិតកម្មមិនមែនជាជំហាន “គិត និងធ្វើសកម្មភាព” តែមួយដែលមិនបានបែងចែកនោះទេ។ វាជា pipeline នៃដំណាក់កាលនានា ដែលនីមួយៗធ្វើការងារ​ដាច់​ដោយ​ឡែក​នៅរាល់ការ iteration៖

1. Pre-check / compaction។ មុនពេល model គិត harness សម្រេចថា វាត្រូវបានអនុញ្ញាតឱ្យឃើញអ្វីខ្លះ។ ប្រសិនបើការសន្ទនាកំពុងវែងឡើង វា compact — សង្ខេប ឬទម្លាក់ context ចាស់ ដើម្បីឱ្យ state សំខាន់ៗនៅរស់រាន។
2. គិត (Think)។ Model វែកញែកអំពីគោលដៅ និង state បច្ចុប្បន្ន ហើយស្នើសកម្មភាពបន្ទាប់ (ច្រើនតែនៅក្នុងទម្រង់ ReAct បែប “thought → action”)។
3. ធ្វើសកម្មភាព / ប្រតិបត្តិ (Act / execute)។ Harness dispatch tool call ដែលបានស្នើ — អានឯកសារ ដំណើរការ command ស្វែងរក API — ហើយចាប់យកលទ្ធផល។ នេះក៏ជាកន្លែងដែល guardrail រស់នៅ៖ ឧបករណ៍ណាដែលអនុញ្ញាត អ្វីដែលត្រូវការការបញ្ជាក់ អ្វីដែលហាមឃាត់ដាច់ខាត។
4. សង្កេត (Observe)។ លទ្ធផលរបស់ឧបករណ៍ត្រូវបានបញ្ជូនត្រឡប់ទៅក្នុង context ជាភស្តុតាងថ្មីរបស់ model អំពីការពិត។
5. ផ្ទៀងផ្ទាត់ / ដំណើរការក្រោយ (Verify / post-process)។ មុនពេល loop ត្រឡប់ harness (ឬ model ទីពីរ) ពិនិត្យថាតើជំហាននោះពិតជាបានឈានទៅរកគោលដៅឬអត់ — ហើយថាតើ agent កំពុងបោកប្រាស់ខ្លួនវាផ្ទាល់ឬអត់។

Naive loop បង្រួមជំហានទី ១ និងទី ៥ ឱ្យទៅជាគ្មានអ្វីសោះ៖ វាគ្រាន់តែគិត ធ្វើសកម្មភាព ហើយបន្ថែមអ្វីៗទាំងអស់ទៅក្នុង transcript ដែលកើនឡើងជានិច្ច។ វាដំណើរការសម្រាប់ដប់ជំហាន ហើយដួលរលំនៅពេលហាសិបជំហាន។ Reliable loop ចាត់ទុក pre-check និង verify ជាដំណាក់កាល first-class។ នោះជាល្បែងទាំងមូល។

Context engineering៖ ការផ្ដល់ចំណីដល់ loop

កត្តាកំណត់ដ៏ធំបំផុតមួយថាតើ loop ដែលដំណើរការយូរ​នឹង​រស់រាន​ឬអត់ គឺ អ្វីដែលអ្នកដាក់នៅពីមុខ model នៅរាល់ជំហាន — អ្វីដែល Anthropic ហៅថា context engineering។ Context window របស់ model គឺជាថវិកា មិនមែនជាកាបូបស្ពាយទេ។ អ្នកមិនអាចគ្រាន់តែបន្តញាត់របស់ចូលក្នុងវាបានទេ។

រាល់ការ iteration loop បន្ថែម token៖ ឯកសារដែលអាន លទ្ធផល command ការវែកញែកមុនៗ លទ្ធផលឧបករណ៍។ នៅលើ codebase ពិតប្រាកដ ព័ត៌មានពាក់ព័ន្ធទីបំផុតលើសពី window ហើយ model ចាប់ផ្ដើមភ្លេចអ្វីដែលវាបានរៀនពីមុននៅក្នុង run នោះ។ Context engineering គឺជាវិន័យនៃការសម្រេចចិត្ត នៅរាល់ជំហាន ថា instruction ភស្តុតាង និង state ណាដែលពិតជាត្រូវ​មាន​វត្តមាន — ហើយដកអ្វីដែលនៅសល់ចេញដោយឥតមេត្តា។

សម្រាប់ run ដែលលើស context window តែមួយពិតប្រាកដ លំនាំក្លាយជាមានចេតនាជាងមុន។ Long-running agent harness របស់ Anthropic ដែលត្រូវបានកត់ត្រានៅក្នុង ZenML LLMOps database ប្រើការរចនាមានពីរផ្នែក៖ initializer ដែលរៀបចំការងារ និង coding agent ដែលប្រតិបត្តិ ដោយមាន context reset និង handoff artifact រវាង window នានា។ ជំនួសឱ្យ agent តែមួយដែលព្យាយាមកាន់ភារកិច្ចរយៈពេលជាច្រើនម៉ោងនៅក្នុងក្បាលរបស់វា ការងារត្រូវបាន checkpoint ទៅជា artifact ស្ថិតស្ថេរដែល context ស្រស់អាចបន្តយក។ Agent ភ្លេច — ដោយចេតនា — ហើយ harness ធានាថា គ្មានអ្វីសំខាន់បាត់បង់នៅពេលវាភ្លេច។

នេះជាការពិតមិនទាក់ទាញនៃ agent horizon វែង៖ វិស្វកម្មភាគច្រើនគឺអំពីការគ្រប់គ្រងការភ្លេច មិនមែនការបន្ថែមភាពឆ្លាតវៃទេ។

Verification loop៖ generator ធៀបនឹង evaluator

នេះជា failure mode ដែលធ្វើឱ្យគ្រប់ក្រុមថ្នាក់ចុះ៖ agent មិនពូកែដាក់ពិន្ទុការងារផ្ទាល់ខ្លួនរបស់វាទេ។ សួរ model ថា “តើអ្នកបានធ្វើវាត្រឹមត្រូវឬទេ?” ភ្លាមៗបន្ទាប់ពីវាបានធ្វើរឿងនោះ ហើយវាភាគច្រើននឹងនិយាយថា បាទ/ចាស — រួមទាំងពេលដែលចម្លើយគឺ ទេ។ Self-critique ក្នុងដង្ហើមតែមួយជាមួយ generation គឺខ្សោយ ព្រោះ model ត្រូវបាន anchor ទៅនឹងការងារដែលវាទើបតែបង្កើត។

ដំណោះស្រាយគឺផ្នែករចនាសម្ព័ន្ធ មិនមែន prompt ល្អជាងមុនទេ។ អ្នកបំបែក loop ទៅជាពីរតួនាទី។ Model មួយ បង្កើត (generates) ហើយ model ដាច់ដោយឡែកមួយដែលសង្ស័យ វាយតម្លៃ (evaluates) — ដោយ adversarial ដោយ framing ខុសគ្នា និងគួរតែភស្តុតាងខុសគ្នា។ Epsilla ពិពណ៌នាវានេះថាជា GAN-style agent loop៖ Generator ស្នើ Evaluator ព្យាយាមរុះវាចោល ហើយមានតែការងារដែលរស់រានពី Evaluator ប៉ុណ្ណោះដែលឆ្ពោះទៅមុខ។ ឈ្មោះនេះគឺជាការគោរពទៅ generative adversarial network ហើយ intuition គឺដូចគ្នា — សម្ពាធ adversarial បង្កើតលទ្ធផលល្អជាង model តែមួយដែលដាក់ពិន្ទុកិច្ចការផ្ទះរបស់ខ្លួនវាផ្ទាល់។

នៅក្នុងការអនុវត្ត នេះជាមូលហេតុដែល coding agent ដែលមាន test ខ្លាំង​ដំណើរការ​ល្អជាង agent ដែលគ្មាន ដោយគម្លាតធំ៖ test suite គឺ Evaluator។ ពេលអ្នកខ្វះ​សញ្ញានោះ — test coverage ស្ដើង គ្មានលក្ខណៈវិនិច្ឆ័យជោគជ័យច្បាស់លាស់ — ដំណាក់កាល verification របស់ loop ងងឹតភ្នែក ហើយ agent នឹងជិះកប៉ាល់កាត់ bug ដោយទំនុកចិត្ត។ Feedback សំរាមចូល ទំនុកចិត្តសំរាមចេញ។ ប្រសិនបើអ្នកយករឿងមួយចេញពីអត្ថបទនេះ៖ គុណភាពនៃដំណាក់កាល verification របស់អ្នកកំណត់ដែនកំពូលនៃគុណភាព agent របស់អ្នក។

ឧបសគ្គគឺជាមុខងារ មិនមែនជាដែនកំណត់ទេ

សភាវគតិពេល agent ប្រព្រឹត្តខុស គឺឱ្យសេរីភាពកាន់តែច្រើន និង model ឆ្លាតជាងមុនដល់វា។ មេរៀនផ្ទុយ​ពី​ការ​រំពឹង​ទុក​ពីក្រុមដែលចែកចាយប្រព័ន្ធពិតប្រាកដ គឺផ្ទុយគ្នា៖ ឧបសគ្គនៅក្នុង harness គឺជាអ្វីដែលធ្វើឱ្យ agent អាចទុកចិត្តបាន។ អត្ថបទរបស់ Augment Code អំពី harness engineering សម្រាប់ coding agent ប្រកែកយ៉ាងពិតប្រាកដចំណុចនេះ — ថា ឧបសគ្គ មិនមែន model ធំជាងមុនទេ ដែលជាអ្វីដែលចែកចាយកូដដែលអាចពឹងផ្អែកបាន។

ជាក់លាក់ ឧបសគ្គដែលផ្ដល់ផល៖

• ឧបករណ៍តឹង និងពិពណ៌នាបានល្អ។ ឧបករណ៍មុតស្រួចមួយចំនួនដែល model យល់ ឈ្នះលើផ្ទៃ API ដែលរាលដាល។ ការរចនាឧបករណ៍គឺ prompt engineering ក្នុងឈ្មោះមួយផ្សេងទៀត។
• ច្រកការអនុញ្ញាត (Permission gates)។ សម្រេចថា agent អាចធ្វើអ្វីដោយស្វយ័ត ធៀបនឹងអ្វីដែលត្រូវការមនុស្សនៅក្នុង loop។ “YOLO mode” មានកន្លែងរបស់វា — ប៉ុន្តែវាជាជម្រើសមានចេតនា មិនមែនជាលំនាំ​ដើម​ទេ។
• ជំហាន និងថវិកាមានព្រំដែន។ Loop ដែលអាចដំណើរការគ្មានទីបញ្ចប់នឹងធ្វើដូច្នោះ។ ដែនកំណត់លើ iteration token និង wall-clock ប្រែ runaway ទៅជាការ​បោះបង់​ដោយ​ស្រួលបួល។
• Observability។ អ្នកមិនអាចជួសជុល loop ដែលអ្នកមើលមិនឃើញទេ។ ការ log រាល់ដំណាក់កាល — អ្វីដែល model ឃើញ អ្វីដែលវាជ្រើស អ្វីដែលឧបករណ៍បញ្ជូនត្រឡប់ — គឺជាភាពខុសគ្នារវាងការ debug និងការស្មាន។

គ្មានមួយណានៃទាំងនេះមកពី model ទេ។ ទាំងអស់នេះមកពី harness។ នេះជាបេះដូងនៃមូលហេតុដែល model upgrade មិនជួសជុល agent ដែលមិនស្ថិតស្ថេរ៖ ការបរាជ័យមិនដែលនៅក្នុង weights ទេ។

កន្លែងណាដែលត្រូវដាក់ការខំប្រឹងរបស់អ្នក

ដូច្នេះ អ្នកកំពុងសាងសង់ agent ហើយអ្នកមានម៉ោងវិស្វកម្មមានកំណត់។ ពួកវាទៅណា?

មិនមែនទៅក្នុងការដេញតាម model ថ្មីបំផុតទេ — នោះជា setting ដែលអ្នកប្ដូរក្នុងពេលរសៀលមួយ ពេលដែលវាមានតម្លៃ។ Leverage ស្ថិតស្ថេរ​ស្ថិត​នៅ​ក្នុង loop៖ ដំណាក់កាល verification ដែលមានសញ្ញាជោគជ័យពិតប្រាកដ វិន័យ context ដែលរស់រានពី run វែង ឧបករណ៍តឹង និង observability ដើម្បីឱ្យអ្នកពិតជាអាចមើលឃើញអ្វីដែលកំពុងកើតឡើង។ ទាំងនេះជាផ្នែកដែលផ្គុំ​ផល​ឡើង ហើយ — គួរកត់សម្គាល់ — ជាផ្នែកដែល រស់រាន ពី model upgrade។ Model ល្អជាងធ្វើឱ្យ loop ដែលសាងសង់បានល្អ កាន់តែល្អ។ វាស្ទើរតែមិនធ្វើអ្វីសម្រាប់ loop ដែលគ្មាន verification និងគ្មានយុទ្ធសាស្ត្រ context ទេ។

មានកំណែយុទ្ធសាស្ត្រនៃចំណុចនេះផងដែរ។ ខណៈដែល base model ស្រូបយកសមត្ថភាពធ្វើផែនការ និងជ្រើស​ឧបករណ៍​កាន់តែច្រើន scaffolding មួយចំនួនពិតជាត្រូវបាន “លេបយក” ដោយ model — ប៉ុន្តែកង្វល់កម្រិតប្រព័ន្ធ (memory orchestration verification governance) មិនមកពី model តែឯងទេ ហើយប្រកែកបានថា ត្រូវ រីកធំ នៅពេល model កាន់តែមានសមត្ថភាព និងត្រូវបានទុកចិត្តជាមួយការងារ horizon វែងជាងមុន។ ភ្នាល់លើ layer ដែលរស់រានពីការចេញផ្សាយបន្ទាប់។

សេចក្ដីសន្និដ្ឋាន

Agent គឺជា loop ដែលមានរចនាសម្ព័ន្ធ ហើយរចនាសម្ព័ន្ធគឺជាផលិតផល។ Model ផ្គត់ផ្គង់ភាពឆ្លាតវៃ loop សម្រេចថាតើភាពឆ្លាតវៃនោះ​ចុះ​ដល់​គោលដៅ​ឬអត់។ ដំណាក់កាលនានា — pre-check គិត ធ្វើសកម្មភាព សង្កេត ផ្ទៀងផ្ទាត់ — គឺជាកន្លែងដែលភាពអាចទុកចិត្តបានត្រូវបានធ្វើវិស្វកម្ម។ Context engineering រក្សា run វែងឱ្យនៅជាប់លាប់។ Evaluator ដាច់ដោយឡែករក្សា agent ឱ្យស្មោះត្រង់។ ឧបសគ្គរក្សាវាកុំឱ្យរត់ធ្លាក់ចុះច្រាំង។ ប្ដូរ model ឆ្លាតជាងមុនចូល ហើយគ្មានមួយណានៃនោះមកដោយឥតគិតថ្លៃទេ សាងសង់ loop ឱ្យបានល្អ ហើយ model ឆ្លាតជាងមុនធ្វើឱ្យអ្វីៗទាំងអស់នោះកាន់តែល្អ។

នេះជា layer ដែលយើងធ្វើការនៅក្នុង។ ប្រសិនបើក្រុមរបស់អ្នកមាន agent ដែលបង្ហាញ demo យ៉ាងស្អាត ហើយដួលរលំក្នុងផលិតកម្ម — ឬអ្នកកំពុងរចនាមួយ ហើយចង់ឱ្យ loop ត្រឹមត្រូវតាំងពីលើកដំបូង — នោះច្បាស់ជាការងារដែលយើងធ្វើ។

យើងរចនា និងធ្វើ audit លើ agent loop និង harness។ កក់ការពិនិត្យឡើងវិញជាមួយយើង។