តើយើង Setup Multi-Agent AI ដើម្បី Build DineOS ដោយ Human មិនប៉ះ Codebase យ៉ាងណា?

តើអ្នកអាចសង់ desktop POS ពេញលេញមួយ ដោយ human មិនចាំបាច់សរសេរ code សូម្បីតែមួយបន្ទាត់ បានទេ? នៅ DineOS យើងបានសាកល្បង — ហើយវាដំណើរការ។ Blog នេះនិយាយអំពីរបៀបដែលយើង setup ក្រុម multi-agent AI ឲ្យធ្វើការជាមួយគ្នា ដើម្បី build project នេះ ខណៈ human គ្រាន់តែ review និង deploy ប៉ុណ្ណោះ។

គំនិតសំខាន់ (The core idea)

ជំនួសឲ្យ AI តែមួយធ្វើគ្រប់យ៉ាង យើងបែងចែកការងារទៅ agent ជាច្រើន ដែលម្នាក់ៗមាន role ច្បាស់លាស់ ដូចក្រុមវិស្វករពិតប្រាកដ។ Agent ទាំងអស់ចែករំលែក task queue តែមួយ (យើងប្រើ ORBIT តាម MCP) ដែលដើរតួជា "ខួរក្បាលរួម" — កន្លែងដែល task ត្រូវបានបង្កើត, assign, និង track តាម tag។

គោលការណ៍ដ៏សំខាន់បំផុត៖ មាន agent តែមួយប៉ុណ្ណោះដែលអាចកែ source code បាន (គឺ coder)។ Agent ដទៃទៀត read បាន តែ write មិនបាន។ ចំណែក human? យើងមិនប៉ះ codebase ទាល់តែសោះ — យើងគ្រាន់តែ approve diff និង run release script។

ក្រុម Agent របស់យើង (Meet the team)

Agent	Role	កែ code បានទេ?
coder	Implement task, run pnpm lint + pnpm build, រួច route ទៅ reviewer	✅ (តែម្នាក់ឯង)
code-reviewer	Read-only diff gate — approve ឬ file change-request ត្រឡប់ទៅ coder	❌
qa-agent	បើក app ពិត (pnpm tauri:dev), exercise flow, file wf:bug ជាមួយ repro steps	❌
advisor	Prioritize backlog, បង្កើត wf:coder-task ដែល spec ច្បាស់	❌
ux-agent	Audit UI/UX ម្ដងមួយ page, រក layout ខូច និង bilingual gap, file fix task	❌

Agent នីមួយៗមាន tool ដែលកំណត់ច្បាស់៖ មានតែ coder ទេដែល run បាន pnpm build, មានតែ qa-agent ទេដែលបើក app, ហើយមានតែ ux-agent ទេដែលថត Playwright screenshots។ ការបែងចែក permission បែបនេះ ធ្វើឲ្យគ្មាន agent ណាមួយ "over-reach" បានឡើយ។

Workflow ដំណើរការយ៉ាងណា (The tag state machine)

ការងារទាំងអស់ហូរតាម tag state machine មួយ។ Task ចាប់ផ្ដើមពី advisor (ឬ human) ហើយ agent នីមួយៗ hand off ទៅគ្នាតាម tag៖

  advisor / human បង្កើត task
        │  wf:coder-task + assign:coder
        ▼
   [ coder ] implement → pnpm lint → pnpm build (tsc)
        │  wf:done + assign:code-reviewer
        ▼
   [ code-reviewer ] read diff, check convention + security
        │
     ┌──┴──┐
   PASS   FAIL
     │      │  wf:change-request + assign:coder ──┐
     ▼      └──────────────────────────────────────┘ (coder កែម្ដងទៀត)
  wf:approved
     │
     ▼
  [ HUMAN ] review diff → ./release.ps1 → CI build → GitHub Release

ចំណុចសំខាន់៖ coder មិនអាចmark task ថា done បានទេ បើ pnpm build (ដែល run tsc ពេញលេញ) fail។ ដូច្នេះ code ដែលមិន compile មិនអាចទៅដល់ reviewer បានឡើយ។ ហើយ reviewer ជា read-only gate — បើ diff មិនត្រូវតាម acceptance criteria ឬ convention វា file wf:change-request ត្រឡប់ទៅ coder វិញ ដោយស្វ័យប្រវត្តិ។

Track ដែល run ស្របគ្នា (Parallel tracks)

ក្រៅពី flow សំខាន់ខាងលើ យើងមាន track ផ្សេងទៀតដែល run ស្របគ្នា៖

• QA loop — qa-agent exercise app រកឃើញ bug → file wf:bug → coder ជួសជុល → back ទៅ review flow ដដែល។
• Error loop — ពេលមាន runtime ឬ CI failure វា auto-file wf:error → code-reviewer វិភាគ root cause, សរសេរ prevention rule ចូល .claude/docs/coder-lessons.md, រួច file fix task។ Agent ក្រោយៗអាន lessons ទាំងនោះ ដើម្បីកុំធ្វើខុសម្ដងទៀត។
• UX loop — ux-agent audit page ម្ដងមួយ រក wf:i18n (bilingual gap) និង wf:money-critical (លុយ display ខុស) — bug ដ៏គ្រោះថ្នាក់បំផុតសម្រាប់ POS។

Guardrail ដែលធ្វើឲ្យវាមិនផ្ទុះ (Why it doesn't go off the rails)

Autonomy ច្រើនពេក ដោយគ្មាន guardrail = គ្រោះថ្នាក់។ ដូច្នេះយើងដាក់ច្បាប់រឹង៖

1. គ្មាន agent ណា push, deploy, ឬ run release.ps1 ទេ — នេះជាការងាររបស់ human ជានិច្ច បន្ទាប់ពី wf:approved។
2. coder ជា agent តែមួយគត់ដែលកែ source — កាត់បន្ថយ conflict និង "surprise change"។
3. Build ត្រូវ pass មុន review — គ្មាន code ខូច compile ឆ្លងកាត់ gate បានទេ។
4. Escalation — ពេល agent ណាមួយ ជាប់ blocker វា file wf:needs-human, បញ្ឈប់ខ្លួនឯង ហើយរង់ចាំ human សម្រេច។
5. Token discipline — agent ពឹងលើ .claude/docs/project-context.md ជំនួសឲ្យ re-read repo ទាំងមូលរាល់ cycle, ហើយ loop តាម tasks.next ម្ដងមួយ task ។

លទ្ធផល (Result)

DineOS — desktop POS បែប offline-first ពេញលេញ (Tauri 2 + Next.js 16 + Rust, dual currency USD/KHR, bilingual Khmer/English, Turso cloud sync, auto-updater) — ត្រូវបាន build ភាគច្រើន តាមរយៈ pipeline agent នេះ។ Human មិនបានវាយ code នៅក្នុង editor ទេ; យើងគ្រាន់តែ កំណត់ acceptance criteria, review diff, និងចុច deploy។

នេះមិនមែនជា "AI ជំនួស engineer" ទេ។ វាជា engineer ក្លាយជា orchestrator — កំណត់ទិសដៅ, ដាក់ guardrail, ហើយទុកឲ្យក្រុម agent ធ្វើ execution។ ហើយនោះ ជាការផ្លាស់ប្ដូរដ៏ធំបំផុត។