អត្ថបទ
ឈប់ Fan-out ដោយមិនគិត៖ ការអនុវត្តជាក់ស្តែងនៃស្ថាបត្យកម្មរៀបចំការងារ 4 ស្រទាប់ជាមួយ Claude Haiku 5.5
Claude Haiku 5.5 ទាំងលឿនទាំងថោក ប៉ុន្តែការបោះ task ទាំងអស់ឱ្យវាធ្វើស្របគ្នានឹងរឹតតែពង្រីកការវិនិច្ឆ័យខុស, ភាពលម្អៀងក្នុងការវាយតម្លៃ និងហានិភ័យ Supply Chain។ អត្ថបទនេះនឹងពន្យល់លម្អិតអំពីស្ថាបត្យកម្មបែងចែកស្រទាប់ដែលប្រើ Fable សម្រាប់វិនិច្ឆ័យ, Opus សម្រាប់រៀបចំចាត់ចែង, Sonnet និង Haiku សម្រាប់ implement, CI សម្រាប់ផ្ទៀងផ្ទាត់ និង Opus សម្រាប់ត្រួតពិនិត្យទទួលយក ព្រមទាំងបញ្ជាក់ថាតើ task បែបណាខ្លះដែលស័ក្តិសមនឹងធ្វើ Fan-out។
· អាន 2 នាទី
Claude Haiku 5.5 ត្រូវបានដាក់ឱ្យដំណើរការនៅថ្ងៃទី 7 ខែតុលា ឆ្នាំ 2026។ នៅពេល prompt ស្ថិតក្នុងរង្វង់ 10 ម៉ឺន tokens (100,000 tokens) តម្លៃរបស់វាគឺត្រឹមតែមួយភាគម្ភៃនៃ Sonnet 5.5 ប៉ុណ្ណោះ ហើយ latency ក៏លឿនជាងគេបំផុតក្នុងចំណោមជំនាន់ Claude បច្ចុប្បន្ននេះផងដែរ។
ដោយសារវាទាំងថោកហើយលឿន វាងាយនឹងធ្វើឱ្យគេចង់ធ្វើបែបនេះ៖ បំបែក task coding ទាំងអស់ ហើយបោះឱ្យ Haiku មួយក្រុមដំណើរការស្របគ្នាឱ្យតែចប់ការងារ។
ពេលធ្វើ prototype វិធីនេះប្រហែលជាដំណើរការទៅមុខបាន។ ប៉ុន្តែបើដាក់ចូលទៅក្នុងបរិស្ថាន engineering ផ្លូវការ វានឹងជួបបញ្ហាបីយ៉ាងយ៉ាងឆាប់រហ័ស៖
- ម៉ូឌែលតូចមិនស័ក្តិសមនឹងដោះស្រាយភាពមិនច្បាស់លាស់ (ambiguity) នោះទេ។ គោលដៅផ្លូវការរបស់ Haiku 5.5 គឺសម្រាប់ការងារដែលមានទំហំធំ និង latency ទាប ដូចជា classification, extraction, routing និង subagent។ នៅពេល requirement នៅមានភាពមិនច្បាស់លាស់ខាង business ឬត្រូវការ context នៃប្រព័ន្ធទាំងមូល វាងាយនឹងបញ្ចេញលទ្ធផលដែលមើលទៅដូចជាពេញលេញ ប៉ុន្តែតាមពិតទាយខុសទិសដៅ។
- ការឱ្យម៉ូឌែលជាអ្នកជ្រើសរើសចម្លើយ នឹងបង្កើតឱ្យមានភាពលម្អៀងក្នុងការវាយតម្លៃ (evaluation bias)។ ការបោះ output រាប់សិបឱ្យម៉ូឌែលធំអាន វាងាយនឹងរើសយក version ដែល «មើលទៅមាន architecture ស្អាត» ជាជាង version ដែលត្រឹមត្រូវទាំង logic និងការ execute ពិតប្រាកដ។
- permission នឹងកើនឡើងតាមចំនួន Worker។ ប្រសិនបើអនុញ្ញាតឱ្យ subagent ដែលរត់ស្របគ្នា install package ដោយស្វ័យប្រវត្ត ឬកែប្រែ configuration នោះការបើក N Worker គឺស្មើនឹងការបន្ថែមច្រកចូល N ទៀតដែលអាចនាំចូល malicious package។
ដូច្នេះហើយ ទើបខ្ញុំប្តូរមកប្រើ Hierarchical Orchestration៖ ស្រទាប់នីមួយៗធ្វើតែអ្វីដែលខ្លួនពូកែ ហើយសមត្ថភាពរត់ស្របគ្នារបស់ Haiku ត្រូវបានប្រើតែនៅកន្លែងដែលត្រូវការចាំបាច់ប៉ុណ្ណោះ។
សរុបសេចក្តីជាមុន៖ Fable ទទួលខុសត្រូវគិតឱ្យច្បាស់លាស់, Opus ទទួលខុសត្រូវបែងចែកនិងត្រួតពិនិត្យទទួលយក, Sonnet ទទួលខុសត្រូវ implement ចម្បង ហើយ Haiku ធ្វើតែ task បែបមេកានិក និង task បែបស្វែងរកដែលអាចផ្ទៀងផ្ទាត់ដោយស្វ័យប្រវត្ត។ ដំណោះស្រាយដែលជាបេក្ខភាពត្រូវឆ្លងកាត់ CI ជាមុនសិន ទើបបញ្ជូនឱ្យម៉ូឌែលពិនិត្យ។
ស្ថាបត្យកម្ម 4 ស្រទាប់៖ ការវិនិច្ឆ័យ, ការចាត់ចែង, ការផ្ទៀងផ្ទាត់ និងការត្រួតពិនិត្យទទួលយក#
Input នៃតម្រូវការ
│
▼
[ស្រទាប់វិនិច្ឆ័យ] Fable៖ ការសម្រេចចិត្តលើ architecture, ការបំបែក task, Acceptance Criteria
│
▼
[ស្រទាប់ចាត់ចែង] Opus Main Session៖ គ្រាន់តែបែងចែក មិនបំបែក task ឡើងវិញទេ
├─► ផ្លូវ A៖ ស្មុគស្មាញតែ boundary ច្បាស់លាស់ ──► Sonnet implement
├─► ផ្លូវ B៖ task បែបមេកានិក ──► Haiku តែមួយ
├─► ផ្លូវ C៖ បែបស្វែងរក, មានដំណោះស្រាយច្រើន ──► Haiku ច្រើន, ម្នាក់ៗ Git Worktree មួយដាច់ដោយឡែក
│
▼
[ស្រទាប់ផ្ទៀងផ្ទាត់] Build, Type Check, Test, Benchmark (ផ្លូវ C ទុកតែលំដាប់កំពូល 2–3)
│
▼
[ស្រទាប់ទទួលយក] Opus សម្រេចបង្រួមតាម Acceptance Criteria
បើបរាជ័យគឺ escalate៖ Haiku កែ 2 ដងនៅតែបរាជ័យ ➔ Sonnet ➔ ត្រឡប់ទៅ Opus
ការដាក់ម៉ូឌែលនីមួយៗនៅស្រទាប់ណា គឺផ្អែកលើការកំណត់គោលដៅផ្លូវការ និងតម្លៃរបស់វា។ ខាងក្រោមនេះជាតួលេខពីឯកសារផ្លូវការរបស់ Anthropic កាលពីថ្ងៃទី 8 ខែតុលា ឆ្នាំ 2026 ដោយតម្លៃគិតជាដុល្លារក្នុងមួយលាន tokens៖
| ម៉ូឌែល |
គោលដៅផ្លូវការ |
Latency |
តម្លៃ Input / Output |
| Claude Fable 5.1 |
ការវែកញែកកម្រិតខ្ពស់ និងការងារ agentic រយៈពេលវែង |
រាងយឺត |
$10 / $50 |
| Claude Opus 5.5 |
ការងារ agentic coding និងការងារចំណេះដឹងរយៈពេលវែង |
មធ្យម |
$4 / $20 |
| Claude Sonnet 5.5 |
ការរួមបញ្ចូលគ្នាយ៉ាងល្អបំផុតរវាងល្បឿននិងសមត្ថភាព |
លឿន |
$2 / $10 |
| Claude Haiku 5.5 |
ការងារ classification, extraction, routing និង subagent ដែលមានទំហំធំ និង latency ទាប |
លឿនបំផុត |
ចាប់ពី $0.10 / $0.50 |
តម្លៃរបស់ Haiku 5.5 ត្រូវបែងចែកជាពីរដំណាក់កាល៖ នៅពេល prompt លើសពី 10 ម៉ឺន tokens (100,000 tokens) វានឹងក្លាយជា $0.50 / $2.50។
ស្រទាប់វិនិច្ឆ័យ៖ Fable ទទួលខុសត្រូវលើការសម្រេចចិត្ត architecture និង Acceptance Criteria#
មិនមែនគ្រប់ requirement ទាំងអស់សុទ្ធតែត្រូវការ Fable នោះទេ។ វាជាស្រទាប់ដែលថ្លៃជាងគេ និងយឺតជាងគេ ខ្ញុំប្រើវាលុះត្រាតែ requirement មាន ambiguity, ពាក់ព័ន្ធនឹងការធ្វើ integration ឆ្លងប្រព័ន្ធ ឬត្រូវការធ្វើការសម្រេចចិត្តលើ architecture ស្នូលប៉ុណ្ណោះ។
Fable ត្រូវប្រគល់លទ្ធផលបីយ៉ាង៖
- ការរចនាដំណោះស្រាយ (solution design)
- ការបំបែក task
- Acceptance Criteria សម្រាប់ subtask នីមួយៗដែលអាចផ្ទៀងផ្ទាត់បានដោយ automated test
ការវែកញែកនិងការបំបែក task ត្រូវតែធ្វើឡើងដោយស្រទាប់តែមួយ។ ស្រទាប់ដែលអាចគិតយល់ច្បាស់ពីចំណុចខ្វះខាតរបស់ប្រព័ន្ធ ទើបអាចកំណត់ subtask ដែលមាន boundary ស្អាតបាន។ បើប្រគល់ architecture ឱ្យ A ហើយការបំបែក task ឱ្យ B នោះ interface definition ជាទូទៅនឹងប្រែជាស្រពិចស្រពិល។
ការងារ security គឺជាករណីលើកលែង។ បច្ចុប្បន្ន ម៉ូឌែលជំនាន់ Claude នេះសុទ្ធតែមាន safety classifier នៅពេល request ត្រូវបានរារាំង វានឹង return មកវិញនូវ stop_reason: "refusal" ដែលសូម្បីតែការងារ security ត្រឹមត្រូវស្របច្បាប់ក៏អាចត្រូវបានរារាំងខុសដែរ។ classifier របស់ Fable 5.1 គ្របដណ្តប់លើ content security ភាគច្រើន ហើយឯកសារផ្លូវការបានបញ្ជាក់ថាវាមិនត្រូវបានរចនាឡើងសម្រាប់វិស័យ security ឡើយ រីឯ Opus 5.5 វិញ គឺត្រូវបានអនុញ្ញាតឱ្យស្វែងរក vulnerability ក្នុង source code។ ដូច្នេះសម្រាប់ requirement ដូចជាការជួសជុល security vulnerability គឺការវិភាគដំណាក់កាលដំបូងខ្ញុំប្រគល់ឱ្យ Opus ផ្ទាល់តែម្តង។
ស្រទាប់ចាត់ចែង៖ Opus គ្រាន់តែបែងចែក មិនបំបែក task ឡើងវិញទេ#
Opus ដើរតួជា Main Session ដែលទទួលខុសត្រូវលើការធ្វើ routing និងចាត់ចែងការងារ។ ស្រទាប់នេះមិនកែប្រែ architecture ឡើងវិញ ហើយក៏មិនធ្វើការបំបែក task ជាលើកទីពីរដែរ។
- ផ្លូវ A, ស្មុគស្មាញតែ boundary ច្បាស់លាស់៖ task ដែលមាន logic ស្មុគស្មាញ ប៉ុន្តែ interface boundary ត្រូវបានកំណត់ច្បាស់លាស់ហើយ ត្រូវប្រគល់ឱ្យ Sonnet។ វាជាកម្លាំងស្នូលសម្រាប់ implementation។
- ផ្លូវ B, task បែបមេកានិកធម្មតា៖ Boilerplate, ការប្តូរឈ្មោះ variable, ការបន្ថែម unit test សាមញ្ញៗ, ការបំពេញ documentation ត្រូវប្រគល់ឱ្យ Haiku មួយដំណើរការ។
- ផ្លូវ C, task បែបស្វែងរក និង optimization៖ ការធ្វើ performance tuning, វិធីសរសេរច្រើនបែបនៃ SQL ឬ Regex ស្មុគស្មាញ, ការដោះស្រាយ Flaky Test គឺទើបចាប់ផ្តើម Fan-out៖ ចាត់តាំង Haiku ច្រើន ដោយម្នាក់ៗដំណើរការលើ Git Worktree ដាច់ដោយឡែកពីគ្នា ដើម្បីសាកល្បងដំណោះស្រាយផ្សេងៗគ្នា។
មិនថារត់តាមផ្លូវណានោះទេ output ទាំងអស់សុទ្ធតែត្រូវបញ្ជូនទៅស្រទាប់ផ្ទៀងផ្ទាត់។
ស្រទាប់ផ្ទៀងផ្ទាត់៖ ម៉ាស៊ីនមុន ម៉ូឌែលក្រោយ#
វិធីសាស្ត្រដែលគេឧស្សាហ៍ឃើញធ្វើ គឺការយក code ដែល generate ស្របគ្នាទាំងអស់នោះបោះទៅឱ្យ Opus ឬ Sonnet ហើយឱ្យវា review តាមរយៈ prompt។
បញ្ហាគឺនៅពេលម៉ូឌែលអាន code វាងាយនឹងទាក់ចិត្តដោយចម្លើយដែលមាន formatting មានរបៀបរៀបរយ និងមាន type declaration ពេញលេញ ប៉ុន្តែវាមិនមានន័យថា code នោះអាចដំណើរការឆ្លងកាត់ edge case test នោះឡើយ។ ដូច្នេះ បេក្ខភាពដំណោះស្រាយត្រូវតែឆ្លងកាត់ដំណាក់កាលម៉ាស៊ីនជាមុនសិន៖
- Build និង Type Check៖ អាច compile ចេញ និងមាន type ត្រឹមត្រូវ
- Unit / Integration Tests៖ ដំណើរការ unit test និង integration test ជាប់
- Benchmark / Profiling៖ វាស់ស្ទង់ performance និង memory
ដំណោះស្រាយណាដែលមិនជាប់ automated test នឹងត្រូវជម្រុះចោលភ្លាមៗ។ សម្រាប់បេក្ខភាពនៃផ្លូវ C គឺ Opus នឹងពិនិត្យមើលតែដំណោះស្រាយលំដាប់កំពូល 2–3 ដែលបានឆ្លងកាត់ការ verify និងមាន metric ល្អបំផុតប៉ុណ្ណោះ ដែលនេះជួយសន្សំទាំង context window និង token ផងដែរ។
ស្រទាប់ទទួលយក៖ Opus បង្រួមលទ្ធផល បើបរាជ័យត្រូវ escalate ឡើងលើ#
ចុងក្រោយ Opus នឹងបង្រួមនិងជ្រើសរើសលទ្ធផលផ្អែកលើ Acceptance Criteria ដែលបានកំណត់ដោយស្រទាប់វិនិច្ឆ័យ។ ប្រសិនបើ Worker ជួបការរាំងស្ទះ វានឹង escalate ឡើងលើតាមលំដាប់ (Escalation Path)៖
- Haiku បរាជ័យ ហើយព្យាយាម fix ដោយស្វ័យប្រវត្ត 2 ដងនៅតែមិនជាប់ ត្រូវបញ្ឈប់ការ retry។
- ប្តូរឱ្យ Sonnet មកទទួលបន្ទុក fix ជំនួសវិញ។
- ប្រសិនបើ Sonnet នៅតែមិនអាចឆ្លងកាត់ការត្រួតពិនិត្យទទួលយកបានទៀត នោះច្រើនតែមានន័យថាការបំបែក task ឬការសន្មតជាមុនមានភាពផ្ទុយគ្នា។ task នឹងត្រូវបញ្ជូនត្រឡប់ទៅ Opus ហើយ Opus នឹងវិនិច្ឆ័យថាតើត្រូវផ្ញើត្រឡប់ទៅ Fable ដើម្បីបំបែក task ឡើងវិញឬអត់។
វិធាន 3 យ៉ាងមុនពេលដាក់ឱ្យដំណើរការលើ production#
កុំធ្វើ Fan-out ដោយងងឹតងងុល#
task សាមញ្ញមិនត្រូវការ Worker ច្រើនទេ ហើយ task ដែលមាន ambiguity ខ្ពស់ ម៉ូឌែលតូចក៏ដោះស្រាយមិនចេញដែរ។ មានតែ task បែបស្វែងរកដែលមាន «ចន្លោះដំណោះស្រាយធំ» ហើយ «អាចផ្ទៀងផ្ទាត់បានយ៉ាងរហ័សដោយ automated test» ប៉ុណ្ណោះ ទើបស័ក្តិសមឱ្យ Haiku ច្រើនដំណើរការស្របគ្នា។
ញែកបរិស្ថានឱ្យដាច់ និងចាក់សោ Lockfile#
Git Worktree ញែកតែការផ្លាស់ប្តូរ code ប៉ុណ្ណោះ ដើម្បីកុំឱ្យ Worker ដែលរត់ស្របគ្នា overwrite file លើគ្នាទៅវិញទៅមក ប៉ុន្តែវាមិនបានកម្រិត network ឬ scope ដែល program អាច access បាននោះទេ។ ដើម្បីការពារ Supply Chain Attack គឺនៅតែត្រូវការ sandbox ហើយត្រូវហាមឃាត់ Worker មិនឱ្យ install package ដែលមិនទាន់បាន audit ដោយខ្លួនឯង ឬកែប្រែ Lockfile ឡើយ។ ការបើកសិទ្ធិ install ដោយសេរី គឺស្មើនឹងការបណ្តោយឱ្យ Agent នាំយក package និង script ដែលគ្មានប្រភពច្បាស់លាស់ចូលមកក្នុង codebase។
ទទួលយកលទ្ធផលដោយ metrics ជាក់ស្តែង មិនមែនដោយការផ្តល់មតិយោបល់របស់ម៉ូឌែល#
លទ្ធផល test, coverage, ទំហំ memory ដែលប្រើ និង latency ទើបជាមូលដ្ឋានដែលអាចបង្កើតឡើងវិញបាន (reproducible) និងអាចប្រៀបធៀបបានពិតប្រាកដ។ ការវាយតម្លៃជាអក្សររបស់ម៉ូឌែលអាចទុកជាឯកសារយោងបាន ប៉ុន្តែមិនអាចយកមកប្រើជាការត្រួតពិនិត្យទទួលយកគុណភាពនៃ code នោះឡើយ។
ម៉ូឌែលដែលមានតម្លៃថោក ត្រូវប្រើឱ្យត្រូវកន្លែង#
Haiku 5.5 ធ្វើឱ្យការដំណើរការស្របគ្នាមានតម្លៃកាន់តែថោក ប៉ុន្តែការរត់ស្របគ្នាតាមបែបធម្មតាមិនអាចធ្វើឱ្យលទ្ធផលត្រឹមត្រូវដោយឯកឯងនោះទេ។ ការបែងចែកការវិនិច្ឆ័យ, ការចាត់ចែង, ការផ្ទៀងផ្ទាត់ និងការត្រួតពិនិត្យទទួលយកឱ្យដាច់ពីគ្នាជាមុន ទើបធ្វើឱ្យភាពថោកនិងលឿនក្លាយជាប្រៀបខ្លាំងពិតប្រាកដ។
ការបែងចែកជាស្រទាប់នេះ តាមពិតទៅគឺជា Graph ដែលខ្ញុំបានលើកឡើងនៅក្នុង AI Agent តាមពិតគឺជាក្រុម Agile មួយទាំងមូល៖ ថានរណាត្រូវធ្វើមុន, ធ្វើចប់ត្រូវប្រគល់ឱ្យនរណា ហើយបើមានបញ្ហាត្រូវបញ្ជូនបន្តទៅឱ្យនរណា។