ហេតុអ្វី Multi-Agent System បរាជ័យ៖ មិនមែន Model ទេ វាជា Org Chart

យើងបានធ្វើករណីសុទិដ្ឋិនិយមរួចហើយ។ ក្នុង វង់តន្ត្រី Code Agent យើងបានអះអាងថាការផ្លាស់ប្ដូរពិតប្រាកដនៃឆ្នាំ ២០២៦ មិនមែន agent ឆ្លាតជាងទេ ប៉ុន្តែ ច្រើនជាង ធ្វើការប៉ារ៉ាឡែល ផ្ដល់ការបង្កើនល្បឿន ២–៤x ពេលរៀបចំបានល្អ។ អត្ថបទនោះអំពីអ្វីដែលធ្វើឱ្យវង់តន្ត្រីលេងតន្ត្រី។ អត្ថបទនេះជាគូស្មោះត្រង់របស់វា ហើយវាអំពីលទ្ធផលម្ខាងទៀត៖ សំឡេងរំខាន។ ព្រោះពេលអ្នកភ្ជាប់ agent ច្រើនជាមួយគ្នា អ្នកមិនគ្រាន់តែគុណសមត្ថភាពរបស់ពួកវាទេ — អ្នកគុណផ្ទៃបរាជ័យរបស់ពួកវា ហើយការបរាជ័យថ្មីមើលមិនដូចអ្វីដែល agent តែមួយផលិតទេ។

សភាវគតិ ពេល multi-agent system ធ្វើឱ្យខកចិត្ត គឺបន្ទោស model។ ប្ដូរ model ខ្លាំងជាងចូល សរសេរ prompt ឡើងវិញ ហើយព្យាយាមម្ដងទៀត។ ការសិក្សាប្រុងប្រយ័ត្នឆ្នាំ ២០២៦ ពីរនិយាយថាសភាវគតិនោះខុសភាគច្រើន — ហើយទិន្នន័យពីក្រោយពួកវាជារបស់មានប្រយោជន៍បំផុតដែលបានកើតឡើងចំពោះវិស្វកម្ម multi-agent ឆ្នាំនេះ។

ទីបំផុតមាននរណាម្នាក់រាប់ការបរាជ័យ

ការសិក្សាទីមួយមានចំណងជើងត្រង់ៗថា Why Do Multi-Agent LLM Systems Fail? (arXiv 2503.13657) ហើយវាបានធ្វើការងារគ្មានភ្លឺថ្លាដែលគ្មាននរណាផ្សេងបានធ្វើ។ អ្នកស្រាវជ្រាវ hand-annotate execution trace ជាង ១.៦០០ ឆ្លងកាត់ multi-agent framework ពេញនិយម ៧ សាងសង់ taxonomy ពី trace ១៥០ ដំបូងជាមួយ inter-annotator agreement ខ្លាំង (Cohen’s κ = 0,88 — មានន័យថាមនុស្សពីរនាក់អាន trace ដូចគ្នាយល់ស្របគ្នាលើអ្វីដែលខុស)។ លទ្ធផលគឺ MAST៖ failure mode ផ្សេងគ្នា ១៤ ដែលដាក់ជា ៣ ប្រភេទ។ ប្រភេទទាំងនោះមានតម្លៃក្នុងការទន្ទេញ ព្រោះវាជាកាយវិភាគនៃរបៀបក្រុម agent ដួលរលំ៖

• Specification & system design — ការបរាជ័យត្រូវដុតចូលមុនពេល agent ដំណើរការផង៖ និយមន័យភារកិច្ចមិនច្បាស់ ព្រំដែនតួនាទីគូសខុស រចនាសម្ព័ន្ធការសន្ទនាមានកំហុស។ វង់តន្ត្រីត្រូវបានប្រគល់ score អាក្រក់។
• Inter-agent misalignment — agent មានសមត្ថភាពម្នាក់ៗ ប៉ុន្តែនិយាយឆ្លងគ្នា៖ មួយមិនអើពើ input របស់មួយទៀត ពួកវា reset context ហើយបាត់ខ្សែ ពួកវាចរចារខ្លួនឯងចូលជ្រុង។ តន្ត្រីករនីមួយៗអាចលេងបាន ប៉ុន្តែពួកវាមិនស្ដាប់គ្នាទៅវិញទៅមកទេ។
• Task verification & termination — គ្មាននរណាពិនិត្យការងារ ឬការពិនិត្យរាក់ពេកមិនអាចចាប់កំហុស ឬប្រព័ន្ធបញ្ឈប់លឿនពេក ហើយរាប់ការងារពាក់កណ្ដាលថាបញ្ចប់។ ការសម្ដែងបញ្ចប់ ហើយអ្នកគ្រប់គ្នាទះដៃកោតសរសើរ note ខុស។

នេះជាការរកឃើញដែលគួររៀបចំរបៀបអ្នកគិតអំពីរឿងនេះ៖ គ្មានប្រភេទតែមួយគ្របដណ្ដប់ទេ។ ការបរាជ័យបែងចែកប្រហែលស្មើគ្នាឆ្លងកាត់ទាំងបី។ នោះជាចំណុចទាំងមូល។ បើការបរាជ័យប្រមូលផ្ដុំនៅកន្លែងតែមួយ អ្នកមានរបស់តែមួយត្រូវជួសជុល។ ផ្ទុយទៅវិញ multi-agent system អាចដួលរលំនៅ spec ក្នុងការសន្ទនា ឬនៅខ្សែបញ្ចប់ ដោយលទ្ធភាពប្រហែលគ្នា — ហើយតែមួយក្នុងបីនោះទើបនៅជិត “model មិនឆ្លាតគ្រប់គ្រាន់”។ ពីរទៀតជាការបរាជ័យបែបអង្គការសុទ្ធ។ មិនមែន model ទេ។ វាជា org chart។

ការសិក្សាទីពីរយល់ស្របពីមុំខុសគ្នាទាំងស្រុង

អ្នកសង្ស័យអាចបដិសេធឯកសារមួយថាជាសិប្បនិម្មិតនៃវិធីសាស្ត្ររបស់វា។ ដូច្នេះវាសំខាន់ដែលការសិក្សាឆ្នាំ ២០២៦ ទីពីរ Characterizing Faults in Agentic AI (arXiv 2603.06847) ឈានដល់ការសន្និដ្ឋានដែលត្រូវគ្នាដោយធ្វើស្ទើរផ្ទុយគ្នា។ ជំនួសឱ្យការអាន trace ដែលរៀបចំដោយដៃ វាបានទៅកន្លែងដែល agentic software រស់នៅ និងបែកពិតប្រាកដ៖ closed issue និង merged pull request ១៣.៦០២ ឆ្លងកាត់ open-source agentic project ៤០។ ពីពួកនោះ អ្នកនិពន្ធ stratified-sample fault ពិត ៣៨៥ ហើយអនុវត្ត grounded theory ដើម្បីទាញ taxonomy នៃ architectural fault dimension ៥ symptom class ១៣ និង root-cause category ១២ — បន្ទាប់មកធ្វើសុពលកម្មទាំងមូលជាមួយ អ្នកអភិវឌ្ឍដែលអនុវត្ត ១៤៥ នាក់។

symptom ដែលអ្នកអភិវឌ្ឍ file bug អំពីពិតប្រាកដគួរឱ្យកត់សម្គាល់៖ structured output ខូច tool call ដែលបាញ់ខុស runtime execution ផ្ទុះ exception ដែលត្រូវលេបជំនួសការដោះស្រាយ។ ហើយ root cause ពីក្រោមពួកវា — schema mismatch dependency drift ភាពស្មុគស្មាញសុទ្ធនៃការគ្រប់គ្រង state ឆ្លងកាត់ប្រព័ន្ធ model interface មិនស្ថិតស្ថេរ — ម្ដងទៀតភាគច្រើនលើសលប់ជាបញ្ហា engineering មិនមែនបញ្ហាបញ្ញាទេ។ ឯកសារនេះថែមទាំងប្រើ association-rule mining ដើម្បីតាមដានរបៀប fault មួយ រាលដាល ទៅមួយទៀត៖ ការរអិលតូចនៅខាងលើក្លាយជា cascade នៅខាងក្រោម។ នោះជាពន្ធ multi-agent ក្នុងប្រយោគមួយ។ ក្នុង agent តែមួយ កំហុសតូចជាកំហុសតូច។ ក្នុងប្រព័ន្ធដែលសម្របសម្រួល កំហុសតូចជា គ្រាប់ពូជ។

ការសិក្សាពីរ វិធីសាស្ត្រពីរ — មួយ annotate trace ដោយដៃ មួយ mine bug report ពិភពពិត — ស្របគ្នាលើការពិតមិនស្រួលចិត្តដូចគ្នា៖ failure mode លេចធ្លោនៃ multi-agent system ជារចនាសម្ព័ន្ធ បែបអង្គការ និងឆ្លងកាត់។ ពួកវាមិនមែនភាគច្រើនអំពីរបៀប model គោលឆ្លាតប៉ុណ្ណាទេ។

ហេតុអ្វី “គ្រាន់តែប្រើ model ល្អជាង” មិនជួយសង្គ្រោះអ្នក

បើការបរាជ័យជាបញ្ហាសមត្ថភាព model ខ្លាំងជាងនឹងរំលាយពួកវា។ អ្នកនិពន្ធ MAST បានសាកល្បងវាដោយផ្ទាល់ ហើយលទ្ធផលជាការរកឃើញជាក់ស្ដែងសំខាន់បំផុតក្នុងឯកសារទាំងពីរ។ ពួកគេបានអនុវត្ត tactical fix ច្បាស់ៗ — prompt ល្អជាង orchestration logic កែលម្អ — ហើយវាស់ការទទួលបាន។ វា តិចតួច៖ ប្រហែល ៣–៥ ពិន្ទុភាគរយ ហើយតាមពាក្យរបស់ពួកគេផ្ទាល់ ការអន្តរាគមន៍ “មិនបង្កើតការកែលម្អជាសារវន្ត”។ ការសន្និដ្ឋានរបស់ពួកគេត្រង់ៗ៖ ការបរាជ័យដែលកំណត់ “ត្រូវការដំណោះស្រាយស្មុគស្មាញជាង” — ការរចនាឡើងវិញរចនាសម្ព័ន្ធ មិនមែន prompt-patching ទេ។

អង្គុយជាមួយវា ព្រោះវាកាត់ផ្ទុយនឹងសភាវគតិទាំងមូលនៃវិស័យ។ ពេលក្រុម agent របស់អ្នកផលិតសំរាម ចលនាថោកគឺកែ prompt ហើយឈោងទៅ model ថ្មីបំផុត។ ទិន្នន័យនិយាយថាចលនានោះទិញពិន្ទុពីរបី ហើយទុក failure mode ពិតប្រាកដនៅដដែល។ specification មិនច្បាស់នៅមិនច្បាស់ មិនថា model ដែលអានវាខ្លាំងប៉ុណ្ណា agent ពីរ misalign អំពីនរណាជាម្ចាស់អ្វីនៅ misalign ជំហាន verification ដែលអវត្តមាននៅអវត្តមាន។ អ្នកមិនអាច prompt ខ្លួនអ្នកចេញពី org chart ដែលបាត់បានទេ។

នេះជាមេរៀនដូចគ្នាដែលយើងតែងតែឈានដល់ពីគ្រប់ទិសដៅ។ វាជាហេតុអ្វីយើងអះអាងថា harness ជាផលិតផល — តម្លៃគង់វង្សមិនមែន model នៅកណ្ដាលទេ វាជារចនាសម្ព័ន្ធជុំវិញវា។ វាជាហេតុអ្វី loop អាក្រក់ដឹកកូដអាក្រក់លឿនជាង៖ ការបន្ថែម parallelism ទៅដំណើរការខូចមិនជួសជុលដំណើរការទេ វាធ្វើមាត្រដ្ឋានការខូច។ ហើយវាភ្ជាប់ផ្ទាល់ទៅកំណែ agent-តែមួយនៃរឿងនេះក្នុង គម្លាតភាពជឿជាក់៖ នៅទីនោះ model ដែលមានសមត្ថភាពបំផុត meltdown ខ្លាំងបំផុត លើភារកិច្ចវែង ព្រោះវាឈោងទៅផែនការមហិច្ឆតាដែលវិលជុំ។ នៅទីនេះ agent ដែលមានសមត្ថភាពបំផុតនិយាយឆ្លងគ្នា និងរំលង verification ងាយដូច model ខ្សោយជាងដែរ។ សមត្ថភាព និងភាពពឹងផ្អែកមិនដែលជាលក្ខណៈដូចគ្នាទេ — ហើយនៅកម្រិត ប្រព័ន្ធ គម្លាតកាន់តែធំ។

taxonomy បរាជ័យប្រាប់អ្នកឱ្យសាងសង់អ្វី

របស់មានប្រយោជន៍អំពី taxonomy បរាជ័យគឺវាបញ្ច្រាសទៅជាបញ្ជីសាងសង់។ ប្រភេទនីមួយៗជាវិន័យដែលអ្នកត្រូវផ្គត់ផ្គង់ ព្រោះ model នឹងមិនធ្វើ៖

• ប្រឆាំងការបរាជ័យ specification៖ វិនិយោគលើ spec មុនពេល agent ដំណើរការ។ ព្រំដែនតួនាទីមុតស្រួច និយមន័យភារកិច្ចមិនច្បាស់ រចនាសម្ព័ន្ធការសន្ទនាជាក់លាក់។ នេះជា leverage ថោកបំផុតដែលអ្នកមាន ហើយទិន្នន័យនិយាយថាវាជាកន្លែងដែលមួយភាគបីនៃការបរាជ័យកើត។ ផែនការដែលមនុស្សពិនិត្យចំណាយនាទីពីរបី ឯផែនការអាក្រក់ដែលប្រតិបត្តិដោយ agent ៥ ប៉ារ៉ាឡែលចំណាយមួយថ្ងៃ។
• ប្រឆាំង inter-agent misalignment៖ ធ្វើ coordination ឱ្យជាក់លាក់ ជំនួសការសង្ឃឹមថាវាលេចចេញ។ task list រួមជាមួយ dependency tracking, file locking ដើម្បីកុំឱ្យ agent ជាន់គ្នា, hand-off រចនាសម្ព័ន្ធជំនួស chat សេរី។ ចាត់ទុក protocol រវាង agent ជា artifact ដែលរចនា មិនមែនផលរំខានទេ។
• ប្រឆាំងការបរាជ័យ verification៖ សាងសង់ checker ជាពលរដ្ឋថ្នាក់ទីមួយ មិនមែនការគិតក្រោយ។ gate ស្វ័យប្រវត្តិដែលដំណើរការ test មុនពេលភារកិច្ចត្រូវរាប់ថាបញ្ចប់ termination condition ដែលមានន័យថា “ផ្ទៀងផ្ទាត់បានពេញលេញ” ជាជាង “agent ឈប់និយាយ”។ នេះជាបញ្ហា នរណាវិនិច្ឆ័យអ្នកវិនិច្ឆ័យ ហើយក្នុង multi-agent system វាទ្រទ្រង់៖ គ្មានអ្វីផ្សេងទប់បាន បើ check ចុងក្រោយមិនទប់ទេ។

គ្មានបីនេះណាមួយជាការ upgrade model ទេ។ ទាំងបីជា engineering និងការវិនិច្ឆ័យ — ការងាររចនាសម្ព័ន្ធជាក់លាក់ដែលការសិក្សានិយាយថាបាត់។

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

នេះជាផ្នែកដែលសំខាន់សម្រាប់តំបន់នេះ ហើយវាតាមផ្ទាល់ពីទិន្នន័យ។ បើ failure mode លេចធ្លោនៃ multi-agent system ជាបញ្ហា សមត្ថភាព គុណសម្បត្តិនឹងហូរទៅអ្នកដែលអាចបណ្ដុះបណ្ដាល ឬជួល model ធំបំផុត — ហើយនោះជាល្បែងដើមទុនដែលអាស៊ីអាគ្នេយ៍មិនឈ្នះ។ ប៉ុន្តែការសិក្សានិយាយផ្ទុយ៖ ការបរាជ័យជា specification coordination និង verification — វិន័យនៃការរចនា និងការវិនិច្ឆ័យ មិនមែនកម្លាំងសេះទេ។ ការងារនោះដំណើរការលើ laptop។ វាមិនចំណាយ GPU ទេ។ វាមិនត្រូវការ frontier lab ទេ។

ហើយវាជាគែមពិតប្រាកដ ព្រោះទីផ្សារភាគច្រើនកំពុងធ្វើរបស់ខុស។ ចលនាលំនាំដើមគ្រប់កន្លែងគឺចាប់យក model ខ្លាំងបំផុត ភ្ជាប់ swarm tune prompt ហើយ ship — ដែលទិន្នន័យបង្ហាញថាទុក failure mode ពិតប្រាកដនៅមិនប៉ះ។ ក្រុមតូចមានវិន័យនៅភ្នំពេញ ឬ Da Nang ដែលផ្ទុយទៅវិញចាត់ទុក org chart ជាផលិតផល — spec មុតស្រួច coordination protocol ជាក់លាក់ verification gate ពិតប្រាកដ — នឹង ship multi-agent system ដែលទប់ជាប់ ខណៈគូប្រកួតមានមូលនិធិច្រើនជាងបន្តប្ដូរ model ហើយឆ្ងល់ថាហេតុអ្វីវង់តន្ត្រីនៅស្ដាប់ទៅដូចសំឡេងរំខាន។

អត្ថបទវង់តន្ត្រីអំពីផ្នែកល្អ ហើយផ្នែកល្អពិតប្រាកដ។ ប៉ុន្តែភាពមិនស្មើគ្នាដូចគ្នារត់កាត់ផ្នែកអាក្រក់៖ របស់ដែលធ្វើឱ្យ multi-agent system បរាជ័យ ជារបស់ដែល frontier lab មិនអាចលក់ឱ្យអ្នកបាន។ វានឹងជួល agent ហាសិបឱ្យអ្នកដោយរីករាយ។ វាមិនអាចជួល org chart ដែលប្រែពួកវាទៅជាក្រុមឱ្យអ្នកបានទេ។ នោះជាការងារដែលគួរកាន់កាប់ — ហើយវាមានសម្រាប់នរណាម្នាក់ដែលសុខចិត្តរាប់ការបរាជ័យដោយស្មោះត្រង់ និងសាងសង់សម្រាប់វា។