វង់តន្ត្រី Code Agent៖ អ្វីដែលធ្វើឱ្យ Multi-Agent Coding ដំណើរការពិតប្រាកដ

រឿងចំណងជើងនៃ agentic coding ក្នុងឆ្នាំ ២០២៦ មិនមែនថា agents ឆ្លាតជាងទេ។ វាជាការដែលមានចំនួនច្រើនជាងរបស់ពួកវា ហើយពួកវាបានចាប់ផ្ដើមធ្វើការជាមួយគ្នា។ AI pair-programmer តែមួយ — agent មួយ context window មួយ អ្នកឃ្លាំមើលរាល់ចលនា — កំពុងផ្ដល់កន្លែងឱ្យអ្វីមួយដែលមើលទៅមិនសូវដូចសហការី ហើយដូចក្រុមដែលអ្នកគ្រប់គ្រងជាង។ Addy Osmani ហៅវាថាការផ្លាស់ពី conductor ទៅ orchestrator ហើយវាជាការផ្លាស់ប្ដូរជំនាញសំខាន់បំផុតដែលវិស័យបានឃើញ ចាប់តាំងពី loops បានជំនួស prompts។

លេខនិយាយថាវាពិតប្រាកដ មិនមែន hype ទេ។ របាយការណ៍និន្នាការ Agentic Coding ឆ្នាំ ២០២៦ របស់ Anthropic រកឃើញថា ៩៥% នៃអ្នកអភិវឌ្ឍអាជីពឥឡូវនេះប្រើឧបករណ៍ AI ប្រចាំសប្ដាហ៍ ហើយ workflow multi-agent កំពុងផ្ដល់ ការបង្កើនល្បឿនចែកចាយរួម ២–៤ ដង។ សហគ្រាសមួយ Rakuten បានបង្រួមគម្រោង ២៤ ថ្ងៃទៅ ៥ ថ្ងៃ ឯអ្នកប្រើ TELUS បានសន្សំម៉ោងសរុបកន្លះលាន។ ប៉ុន្តែទិន្នន័យដូចគ្នាផ្ទុកការព្រមាន៖ អ្នកអភិវឌ្ឍ ប្រគល់ ភារកិច្ចទាំងស្រុងតែ ០–២០% ប៉ុណ្ណោះ។ សមត្ថភាពធំធេង ហើយការទុកចិត្តស្ដើង — ហើយគម្លាតរវាងពួកវាគឺពិតជាជំនាញដែលអត្ថបទនេះនិយាយអំពី។

Conductor ធៀបនឹង orchestrator

ចាប់ផ្ដើមជាមួយភាពខុសគ្នា ព្រោះអ្វីៗទាំងអស់តាមមកពីវា។ Conductor ធ្វើការដោយសមកាលជាមួយ agent មួយ៖ អ្នកផ្ដល់ការណែនាំពេលវេលាជាក់ស្ដែង context window ជាពិដានរបស់អ្នក ហើយអ្នកនៅក្នុង loop លើរាល់ជំហាន។ នេះជាកន្លែងដែលអ្នកអភិវឌ្ឍភាគច្រើនរស់នៅ ហើយវាពិតជាមានផលិតភាព — វគ្គឥឡូវនេះដំណើរការ ២៣ នាទីជាមធ្យម (កើនពី ៤ កាលពីមួយឆ្នាំមុន) ដោយ agent ធ្វើសកម្មភាពស្វយ័ត ~២០ និងការហៅឧបករណ៍ ~៤៧ មុនពេលវាត្រូវការអ្នក។

Orchestrator ខុសគ្នាតាមប្រភេទ មិនមែនកម្រិតទេ។ ឥឡូវនេះអ្នកកំពុងដំណើរការ agents ច្រើន នីមួយៗមាន context window ផ្ទាល់ខ្លួន ធ្វើការមិនសមកាល ខណៈអ្នករៀបផែនការ និងពិនិត្យ។ ដូច Osmani និយាយ នេះ “ត្រូវការសំណុំជំនាញខុសគ្នាជាមូលដ្ឋាន៖ specs ច្បាស់លាស់ ការបំបែកការងារ និងការផ្ទៀងផ្ទាត់ output ជាជាងការសរសេរកូដដោយខ្លួនឯង”។ ការវាយតម្លៃត្រង់ៗរបស់គាត់៖ អ្នកអភិវឌ្ឍភាគច្រើនជាប់នៅកម្រិត ៣–៤ នៃសមត្ថភាព ឯ orchestration ចាប់ផ្ដើមនៅកម្រិត ៦ ហើយការលោតគឺជាច្រាំងថ្ម មិនមែនជម្រាល។

ហេតុអ្វីវង់តន្ត្រីឈ្នះ (នៅពេលវាឈ្នះ)

ករណីសម្រាប់ multi-agent មិនមែនគ្រាន់តែ “កម្មករច្រើនជាង” ទេ។ អំណះអំណាងរបស់ Osmani គឺថាគុណសម្បត្តិបួន គុណ ជាជាងបូក៖

• ភាពប៉ារ៉ាឡែល — agent បីសាងសង់ frontend, backend, និង tests ក្នុងពេលតែមួយ គឺ throughput ៣ ដង មិនមែនលឿនជាង ១០% ទេ។
• ឯកទេសកម្ម — “agent ដែលស្គាល់តែ db.js សរសេរកូដ database ល្អជាង agent ដែលកំពុងលេងសៀក codebase ទាំងមូលរបស់អ្នក”។ Context តូចចង្អៀតជាគុណសម្បត្តិ។
• ភាពឯកោ (Isolation) — git worktrees អនុញ្ញាតឱ្យ agent ប៉ារ៉ាឡែលធ្វើការដោយមិនជាន់លើការផ្លាស់ប្ដូររបស់គ្នាទៅវិញទៅមក merge conflicts ឈប់ជាពន្ធសម្របសម្រួល។
• ការរៀនបង្គរ — AGENTS.md ដែលរៀបចំដោយមនុស្សបង្គរលំនាំឆ្លងកាត់វគ្គ ដូច្នេះរាល់ការដំណើរការចាប់ផ្ដើមឆ្លាតជាងលើកមុន។

ចំណុចចុងក្រោយនោះមកជាមួយការប្រុងប្រយ័ត្នមុតស្រួចដែលទិន្នន័យធ្វើឱ្យច្បាស់៖ AGENTS.md ត្រូវតែ រៀបចំដោយមនុស្ស។ ការស្រាវជ្រាវដែលដកស្រង់ក្នុងរបាយការណ៍រកឃើញថា ឯកសារ AGENTS.md ដែលបង្កើតដោយ LLM មិនផ្ដល់អត្ថប្រយោជន៍ ហើយពិតជាអាចកាត់បន្ថយអត្រាជោគជ័យប្រហែល ៣%។ ផ្ទុយទៅវិញ ឯកសារ context សរសេរដោយដៃផលិត កំហុស agent តិចជាង ៤០% និង ការបញ្ចប់ភារកិច្ចលឿនជាង ៥៥%។ ការបង្គរពិតប្រាកដ ប៉ុន្តែលុះត្រាតែមនុស្សជាម្ចាស់ឯកសារ។

កន្លែងដែលវង់តន្ត្រីដួលរលំ

ការរៀបចំ agent តែមួយ ប៉ះជញ្ជាំងរឹងបី — context overload គ្មានឯកទេសកម្ម និងគ្មានវិធីសម្របសម្រួល dependencies — ហើយជញ្ជាំងទាំងនោះជាមូលហេតុដែល orchestration មាន។ ប៉ុន្តែ orchestration ណែនាំរបៀបបរាជ័យដ៏គ្រោះថ្នាក់ជាងផ្ទាល់ខ្លួនរបស់វា ហើយវាមានតម្លៃក្នុងការនិយាយយ៉ាងច្បាស់៖

“ឧបសគ្គមនុស្សជាលក្ខណៈពិសេស មិនមែនជា bug ទេ។ នៅល្បឿនមនុស្ស កំហុសបង្គរយឺត ហើយការឈឺចាប់បង្ខំការកែតម្រូវដំបូង។ ជាមួយកងទ័ព agent កំហុសតូចៗបង្គរក្នុងអត្រាដែលលឿនជាងសមត្ថភាពអ្នកក្នុងការចាប់។” — Addy Osmani

នេះជាហានិភ័យកណ្ដាលរបស់ orchestrator។ នៅពេលអ្នកដឹកនាំ agent ហាសិបប៉ារ៉ាឡែល spec មិនច្បាស់មិនធ្វើឱ្យអ្នកយឺតទេ — វា គុណ ហាសិបដង មុនពេលអ្នកបានពិនិត្យណាមួយ។ ដែលនាំទៅប្រយោគសំខាន់បំផុតក្នុងការពិភាក្សាទាំងមូល៖ ឧបសគ្គលែងជាការបង្កើតទៀតហើយ វាជាការផ្ទៀងផ្ទាត់។ ការបង្កើតកូដឥឡូវនេះថោក លឿន និងប៉ារ៉ាឡែល។ ការដឹងថាតើកូដត្រឹមត្រូវឬអត់ជាឧបសគ្គ — ហើយវង់តន្ត្រីប៉ារ៉ាឡែលផលិតការងារខុសលឿនដូចការងារត្រឹមត្រូវ។ យើងបានធ្វើអំណះអំណាងដូចគ្នានេះពីខាង loop តែមួយក្នុង ការរចនា Agent Loops ដែលដំណើរការខណៈអ្នកដេក៖ loop អាក្រក់ ship កូដអាក្រក់លឿនជាង។ គុណវាដោយហាសិប។

លំនាំដែលទប់វាជាមួយគ្នា

Orchestration ដែលដំណើរការមិនមែនជាការធ្វើតាមអំពើចិត្តទេ វាជាលំនាំមានវិន័យពីរបី៖

• Subagents — parent បង្កើតកូនឯកទេសសម្រាប់ភារកិច្ចឯករាជ្យ ហើយគ្រប់គ្រងក្រាហ្វ dependency ដោយដៃ។ អព្យាក្រឹតលើថ្លៃដើម ប៉ុន្តែការសម្របសម្រួលនៅតែលើអ្នក។
• ក្រុម Agent — ការប្រតិបត្តិប៉ារ៉ាឡែលពិតប្រាកដជាមួយ team lead បញ្ជីភារកិច្ចរួម (ជាមួយការតាមដាន dependency និង file locking) និងសមាជិកក្រុមដំណើរការក្នុង panes ដាច់ដោយឡែក។ ការផ្ញើសារ peer រក្សា lead កុំឱ្យក្លាយជាឧបសគ្គ។
• Ralph loop — ភារកិច្ច atomic តូចក្នុងវដ្តគ្មានស្ថានភាព-ប៉ុន្តែ-ឡើងវិញ៖ ជ្រើស → អនុវត្ត → ធ្វើសុពលកម្ម → commit → reset។ វាគេចពី context overflow ដោយរក្សាការបន្តក្នុងប្រវត្តិ git និងការចងចាំខាងក្រៅ ជាជាង window រីកធំមួយ។

ហើយនៅពីក្រោមពួកវាទាំងអស់ គឺ quality gates ដូចគ្នា៖ តម្រូវឱ្យមាន ផែនការមុនកូដ (វាថោកជាងច្រើនក្នុងការជួសជុលផែនការអាក្រក់ ជាងកូដអាក្រក់) ភ្ជាប់ hooks ស្វ័យប្រវត្តិដែលដំណើរការ tests មុនពេលភារកិច្ចត្រូវបានរាប់ថាបញ្ចប់ និងរក្សា AGENTS.md ឱ្យបានរៀបចំ។ Gates ទាំងនេះជាស្រទាប់ផ្ទៀងផ្ទាត់ — harness ដែលពង្រីកឆ្លងកាត់ក្រុម agent ទាំងមូល។

ប្រគល់ភារកិច្ច មិនមែនការវិនិច្ឆ័យ

បើមានខ្សែមួយដែលត្រូវយកពីការផ្លាស់ប្ដូរ orchestration វាជារបស់ Osmani៖ “ប្រគល់ភារកិច្ច មិនមែនការវិនិច្ឆ័យ។” ឱ្យ agents ដោះស្រាយការងារដែលមានវិសាលភាពជាមួយលក្ខណៈវិនិច្ឆ័យ pass/fail ច្បាស់លាស់។ រក្សាសម្រាប់ខ្លួនអ្នកនូវរបស់ដែលមិនបំបែក៖ ស្ថាបត្យកម្ម ការសម្រេចថាអ្វី មិន ត្រូវសាងសង់ ការពិនិត្យជាមួយ context ពេញលេញ និងរសជាតិដែលផលិតប្រព័ន្ធល្អ។ Spec របស់អ្នកជាឥទ្ធិពល នៅពេលវាមិនច្បាស់ វង់តន្ត្រីពង្រីកភាពមិនច្បាស់។

នេះផ្គូផ្គងយ៉ាងស្អាតលើ ការផ្លាស់ប្ដូរតួនាទីរបស់អ្នកអភិវឌ្ឍ ដែលយើងបានសរសេរអំពី។ ការងារផ្លាស់ឡើងលើ stack៖ ពីការសរសេរកូដ ទៅការបញ្ជាក់ការងារ ការបំបែកវា និងការផ្ទៀងផ្ទាត់ output របស់ក្រុមដែលមិនដែលដេក។

ហេតុអ្វីនេះត្រូវបានសាងសង់សម្រាប់ក្រុមនៃអាស៊ីអាគ្នេយ៍

នេះជាផ្នែកដែលសំខាន់បំផុតសម្រាប់តំបន់នេះ។ Orchestration ជាកត្តាគុណដែលធ្វើមាត្រដ្ឋាន output ដោយមិន ធ្វើមាត្រដ្ឋានចំនួនបុគ្គលិក — ហើយភាពមិនស្មើគ្នានោះពេញចិត្តចំពោះក្រុមតូច ស្រាលដើមទុនពិតប្រាកដដែលអាស៊ីអាគ្នេយ៍ពោរពេញ។ ស្ទូឌីយោពីរ ឬបីនាក់នៅភ្នំពេញ ឬ Da Nang ដែលបានរៀន orchestrate អាចទទួលយកវិសាលភាពចែកចាយរបស់ក្រុមធំជាងវាច្រើនដង ព្រោះឧបសគ្គលែងជាចំនួនវិស្វករដែលអ្នកជួល — វាជារបៀបដែលពួកគេពីរបីនាក់អាចបំបែកការងារ សរសេរ specs មុតស្រួច និងផ្ទៀងផ្ទាត់ output បានល្អប៉ុនណា។

នោះជាការភ្នាល់លើ ជំនាញ មិនមែនលើ ដើមទុន។ វាត្រូវការវិស្វករដែលអាចគិតជាប្រព័ន្ធ សរសេរការបញ្ជាក់ច្បាស់លាស់ និងរចនាការផ្ទៀងផ្ទាត់ — សមត្ថភាពគង់វង្ស គ្មាន GPU ដូចគ្នាដែលយើងតែងតែអះអាងថាតំបន់អាចសាងសង់។ Frontier lab នឹងជួលឱ្យអ្នកនូវ agent ហាសិបដោយរីករាយ។ អ្វីដែលវាមិនអាចផ្គត់ផ្គង់គឺការវិនិច្ឆ័យដែលប្រែ agent ហាសិបទៅជាសូហ្វវែរដែល ship ហើយត្រឹមត្រូវ សម្រាប់បញ្ហាដែលវាមិនដែលឃើញ។ ការវិនិច្ឆ័យនោះ — រសជាតិរបស់ conductor ធ្វើមាត្រដ្ឋានទៅជាវង់តន្ត្រី — ជាការងារដែលគួរកាន់កាប់។

Agents ជាអ្នកលេង។ Orchestration ជាបទភ្លេង។ ហើយផ្នែកដែលសម្រេចថាតើវាជាតន្ត្រី ឬសំឡេងរំខាន នៅតែ ច្បាស់លាស់ ជារបស់អ្នក។