ບົດຄວາມ
ເຊົາ Fan-out ແບບບໍ່ຄິດ: ສະຖາປັດຕະຍະກຳຈັດສັນ 4 ຊັ້ນຕົວຈິງດ້ວຍ Claude Haiku 5.5
Claude Haiku 5.5 ທັງໄວ ແລະ ລາຄາຖືກ, ແຕ່ການໂຍນທຸກໜ້າວຽກໃຫ້ມັນແບບຂະໜານກັນນັ້ນ ມີແຕ່ຈະເຮັດໃຫ້ການຕັດສິນຜິດພາດ, ອະຄະຕິໃນການກວດສອບ ແລະ ຄວາມສ່ຽງ Supply Chain ເພີ່ມຂຶ້ນ. ບົດຄວາມນີ້ຈະມາແຍກໂຄງສ້າງຫຼາຍຊັ້ນທີ່ໃຊ້ Fable ຕັດສິນ, Opus ຈັດສັນ, Sonnet ກັບ Haiku ລົງມືຂຽນ, CI ກວດສອບ, ແລະ Opus ກວດຮັບວຽກ, ພ້ອມທັງວິເຄາະວ່າໜ້າວຽກແບບໃດກັນແທ້ທີ່ຄຸ້ມຄ່າກັບການ Fan-out.
· ອ່ານ 2 ນາທີ
Claude Haiku 5.5 ເປີດໂຕໃນວັນທີ 7 ຕຸລາ 2026. ເມື່ອ prompt ບໍ່ເກີນ 100,000 tokens, ລາຄາຂອງມັນແມ່ນພຽງແຕ່ໜຶ່ງສ່ວນຊາວ (1/20) ຂອງ Sonnet 5.5 ເທົ່ານັ້ນ, ແລະ latency ກໍໄວທີ່ສຸດໃນບັນດາລຸ້ນ Claude ຍຸກປັດຈຸບັນ.
ທັງຖືກທັງໄວແບບນີ້, ມັນງ່າຍຫຼາຍທີ່ຈະພາໃຫ້ຄິດຢາກເຮັດແບບນີ້: ແຍກໜ້າວຽກ coding ທັງໝົດອອກ, ແລ້ວໂຍນໃຫ້ຝູງ Haiku ເຮັດແບບຂະໜານກັນໄປເລີຍ, ເຮັດແລ້ວກໍຈົບ.
ຕອນເຮັດ prototype, ມັນອາດຈະພໍໄປໄດ້. ແຕ່ເມື່ອນຳມາໃຊ້ໃນສະພາບແວດລ້ອມ engineering ຕົວຈິງ, ບໍ່ດົນກໍຈະຕຳກັບ 3 ບັນຫາໃຫຍ່:
- Model ນ້ອຍບໍ່ເໝາະກັບການຈັດການຄວາມກຳກວມ. ຕຳແໜ່ງຫຼັກທາງການຂອງ Haiku 5.5 ແມ່ນວຽກ classification, extraction, routing ແລະ subagent ທີ່ຕ້ອງການປະລິມານຫຼາຍ ແລະ latency ຕ່ຳ. ເມື່ອ requirements ຍັງມີຄວາມກຳກວມທາງທຸລະກິດ ແລະ ຕ້ອງການ context ຂອງລະບົບທັງໝົດ, ມັນມັກຈະສົ່ງຜົນລັບທີ່ເບິ່ງຄືສົມບູນ ແຕ່ຄວາມຈິງແລ້ວເດົາທິດທາງຜິດ.
- ໃຫ້ model ເລືອກຄຳຕອບ, ຈະເກີດອະຄະຕິໃນການກວດສອບ. ການໂຍນຜົນງານຫຼາຍສິບອັນໃຫ້ model ໃຫຍ່ອ່ານ, ມັນມັກຈະເລືອກເວີຊັນທີ່ "ເບິ່ງຄືມີສະຖາປັດຕະຍະກຳສວຍງາມ", ແທນທີ່ຈະເປັນເວີຊັນທີ່ logic ແລະ ການທຳງານຖືກຕ້ອງແທ້ໆ.
- ສິດ (Permissions) ຈະຂະຫຍາຍຕາມຈຳນວນ Worker. ຖ້າຫາກອະນຸຍາດໃຫ້ subagent ທີ່ລັນຂະໜານກັນນັ້ນ install package ຫຼື ແກ້ໄຂ config ອັດຕະໂນມັດ, ການເປີດ N Worker ກໍຄືການເພີ່ມອີກ N ຊ່ອງທາງທີ່ອາດຈະດຶງເອົາ malicious package ເຂົ້າມາ.
ດັ່ງນັ້ນ ຂ້ອຍຈຶ່ງປ່ຽນມາໃຊ້ Hierarchical Orchestration: ແຕ່ລະຊັ້ນຈະເຮັດສະເພາະສິ່ງທີ່ຕົນເອງຖະໜັດ, ແລະ ໃຊ້ພະລັງຂະໜານຂອງ Haiku ສະເພາະບ່ອນທີ່ຕ້ອງການແທ້ໆ.
ສະຫຼຸບໃຫ້ຟັງກ່ອນ: Fable ຮັບຜິດຊອບຄິດໃຫ້ລະອຽດ, Opus ຮັບຜິດຊອບມອບໝາຍ ແລະ ກວດຮັບວຽກ, Sonnet ຮັບຜິດຊອບ implementation ຫຼັກ, Haiku ເຮັດສະເພາະວຽກກົນໄກຊ້ຳຊາກ ແລະ ວຽກຄົ້ນຫາທີ່ກວດສອບອັດຕະໂນມັດໄດ້. ຕົວເລືອກຕ່າງໆ ຕ້ອງຜ່ານ CI ກ່ອນ, ແລ້ວຈຶ່ງສົ່ງໃຫ້ model ເບິ່ງ.
ສະຖາປັດຕະຍະກຳ 4 ຊັ້ນ: ຕັດສິນ, ຈັດສັນ, ກວດສອບ, ກວດຮັບ#
Requirements ເຂົ້າມາ
│
▼
[ຊັ້ນຕັດສິນ] Fable: ການຕັດສິນໃຈທາງສະຖາປັດຕະຍະກຳ, ການແຍກໜ້າວຽກ, Acceptance Criteria
│
▼
[ຊັ້ນຈັດສັນ] Opus Main Session: ແບ່ງວຽກຢ່າງດຽວ, ບໍ່ແຍກໜ້າວຽກໃໝ່
├─► ເສັ້ນທາງ A: ຊັບຊ້ອນແຕ່ຂອບເຂດຊັດເຈນ ──► Sonnet implementation
├─► ເສັ້ນທາງ B: ວຽກກົນໄກຊ້ຳຊາກ ──► Haiku ດຽວ
├─► ເສັ້ນທາງ C: ແບບຄົ້ນຫາ, ມີຫຼາຍວິທີແກ້ ──► ຫຼາຍ Haiku, ແຍກ Git Worktree ລະອັນ
│
▼
[ຊັ້ນກວດສອບ] Build, Type Check, Test, Benchmark (ເສັ້ນທາງ C ເກັບໄວ້ສະເພາະອັນດັບ 2–3 ທຳອິດ)
│
▼
[ຊັ້ນກວດຮັບ] Opus ສະຫຼຸບລວມຕາມ Acceptance Criteria
ຖ້າລົ້ມເຫຼວໃຫ້ຍົກລະດັບ: Haiku ແກ້ໄຂ 2 ເທື່ອຍັງລົ້ມເຫຼວ ➔ Sonnet ➔ ສົ່ງກັບຄືນ Opus
ການຈັດວາງ model ແຕ່ລະໂຕໄວ້ໃນຊັ້ນໃດ ແມ່ນອີງຕາມ positioning ທາງການ ແລະ ລາຄາ. ດ້ານລຸ່ມນີ້ແມ່ນຕົວເລກຈາກ official document ຂອງ Anthropic ໃນວັນທີ 8 ຕຸລາ 2026, ຫົວໜ່ວຍລາຄາແມ່ນ USD ຕໍ່ 1 ລ້ານ tokens:
| Model |
Positioning ທາງການ |
Latency |
ລາຄາ Input / Output |
| Claude Fable 5.1 |
Reasoning ລະດັບສູງ ແລະ ວຽກ 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 ເກີນ 100,000 tokens ຈະປ່ຽນເປັນ $0.50 / $2.50.
ຊັ້ນຕັດສິນ: Fable ຮັບຜິດຊອບການຕັດສິນໃຈທາງສະຖາປັດຕະຍະກຳ ແລະ Acceptance Criteria#
ບໍ່ແມ່ນທຸກ requirements ຈະຕ້ອງໃຊ້ Fable. ມັນເປັນຊັ້ນທີ່ແພງທີ່ສຸດ ແລະ ຊ້າທີ່ສຸດ, ຂ້ອຍຈະໃຊ້ສະເພາະເວລາທີ່ requirements ມີຄວາມກຳກວມ, ກ່ຽວຂ້ອງກັບການ integrate ຂ້າມລະບົບ, ຫຼື ຕ້ອງຕັດສິນໃຈເລື່ອງ core architecture ເທົ່ານັ້ນ.
Fable ຕ້ອງສົ່ງມອບ 3 ສິ່ງນີ້:
- Solution design
- ການແຍກໜ້າວຽກ (Task decomposition)
- Acceptance Criteria ຂອງແຕ່ລະ subtask ທີ່ສາມາດກວດສອບໄດ້ດ້ວຍ test
Reasoning ແລະ ການແຍກວຽກຕ້ອງເຮັດໃຫ້ຈົບໃນຊັ້ນດຽວກັນ. ຊັ້ນທີ່ສາມາດມອງເຫັນ blind spot ຂອງລະບົບໄດ້ຢ່າງທະລຸປຸໂປ່ງເທົ່ານັ້ນ ຈຶ່ງຈະແບ່ງ subtask ທີ່ມີຂອບເຂດສະອາດຊັດເຈນໄດ້; ຖ້າໃຫ້ A ອອກແບບ architecture ແຕ່ໃຫ້ B ມາແຍກວຽກ, interface definition ມັກຈະມົວໆໄປ.
ວຽກດ້ານ Security ຖືເປັນຂໍ້ຍົກເວັ້ນ. ປັດຈຸບັນ Claude ລຸ້ນນີ້ມີ safety classifier, ເມື່ອ request ຖືກບລັອກ ມັນຈະ return stop_reason: "refusal", ເຊິ່ງວຽກ security ທີ່ຖືກຕ້ອງກໍອາດຈະຖືກບລັອກຜິດພາດໄດ້ຄືກັນ. Classifier ຂອງ Fable 5.1 ກວມເອົາເນື້ອຫາ security ສ່ວນໃຫຍ່, ແລະ ທາງການກໍລະບຸວ່າມັນບໍ່ໄດ້ຖືກອອກແບບມາສຳລັບວຽກ security; ສ່ວນ Opus 5.5 ນັ້ນອະນຸຍາດໃຫ້ຊອກຫາຊ່ອງໂຫວ່ໃນ source code ໄດ້. ດັ່ງນັ້ນ ສຳລັບວຽກແກ້ໄຂ vulnerability ດ້ານ security, ຂັ້ນຕອນວິເຄາະເບື້ອງຕົ້ນຂ້ອຍຈະສົ່ງໃຫ້ Opus ໂດຍກົງເລີຍ.
ຊັ້ນຈັດສັນ: Opus ແບ່ງວຽກຢ່າງດຽວ, ບໍ່ແຍກໜ້າວຽກໃໝ່#
Opus ຄື Main Session ທີ່ຮັບຜິດຊອບເລື່ອງ routing ແລະ ການມອບໝາຍວຽກ. ຊັ້ນນີ້ຈະບໍ່ມີການລົ້ມລ້າງ architecture ໃໝ່, ແລະ ບໍ່ມີການແຍກໜ້າວຽກຮອບສອງ.
- ເສັ້ນທາງ A, ຊັບຊ້ອນແຕ່ຂອບເຂດຊັດເຈນ: ວຽກທີ່ logic ຊັບຊ້ອນ ແຕ່ interface boundaries ຖືກກຳນົດໄວ້ຢ່າງຊັດເຈນແລ້ວ ຈະສົ່ງໃຫ້ Sonnet. ມັນຄືກຳລັງຫຼັກໃນການ implement.
- ເສັ້ນທາງ B, ວຽກກົນໄກຊ້ຳຊາກ: Boilerplate code, ການ rename ຕົວປ່ຽນ, ການເພີ່ມ unit test ແບບກົງໄປກົງມາ, ການຂຽນ documentation ເພີ່ມ, ສົ່ງໃຫ້ Haiku ດຽວຈັດການ.
- ເສັ້ນທາງ C, ວຽກຄົ້ນຫາ ແລະ optimization: ການຈູນ performance, ການຂຽນ SQL ຫຼື Regex ທີ່ຊັບຊ້ອນໃນຫຼາຍຮູບແບບ, ການໄລ່ຫາ Flaky Test, ຈຶ່ງຄ່ອຍເປີດໃຊ້ Fan-out: ສົ່ງ Haiku ຫຼາຍໆໂຕອອກໄປລອງວິທີແກ້ໄຂທີ່ແຕກຕ່າງກັນໃນ Git Worktree ທີ່ແຍກຕ່າງຫາກຂອງໃຜລາວ.
ບໍ່ວ່າຈະໄປເສັ້ນທາງໃດ, ຜົນງານທັງໝົດຕ້ອງເຂົ້າສູ່ຊັ້ນກວດສອບ.
ຊັ້ນກວດສອບ: ເຄື່ອງກ່ອນ, model ຕາມຫຼັງ#
ວິທີທີ່ເຫັນເລື້ອຍໆ ຄືການໂຍນ code ທີ່ອອກມາພ້ອມກັນທັງໝົດນັ້ນໃຫ້ Opus ຫຼື Sonnet ແລ້ວໃຊ້ prompt ບອກໃຫ້ມັນ review.
ບັນຫາກໍຄື, ເວລາ model ອ່ານ code, ມັນມັກຈະຖືກດຶງດູດດ້ວຍຄຳຕອບທີ່ຈັດ format ສວຍງາມ, ມີ type declaration ຄົບຖ້ວນ, ແຕ່ນັ້ນບໍ່ໄດ້ໝາຍຄວາມວ່າມັນຈະຜ່ານ edge cases. ດັ່ງນັ້ນ ຕົວເລືອກຕ່າງໆ ຕ້ອງຜ່ານດ່ານຂອງເຄື່ອງກ່ອນ:
- Build ແລະ Type Check: compile ຜ່ານ, types ຖືກຕ້ອງ
- Unit / Integration Tests: unit test ແລະ integration test ຜ່ານ
- Benchmark / Profiling: ວັດແທກ performance ແລະ memory
ອັນໃດບໍ່ຜ່ານ automated test ໃຫ້ຄັດອອກທັນທີ. ສຳລັບຕົວເລືອກຈາກເສັ້ນທາງ C, Opus ຈະເບິ່ງສະເພາະ 2–3 ອັນດັບທຳອິດທີ່ຜ່ານການກວດສອບ ແລະ ມີ metrics ດີທີ່ສຸດ, ເຊິ່ງຊ່ວຍປະຢັດທັງ context window ແລະ token ໄປພ້ອມ.
ຊັ້ນກວດຮັບ: Opus ສະຫຼຸບລວມ, ຖ້າລົ້ມເຫຼວໃຫ້ຍົກລະດັບຂຶ້ນໄປ#
ສຸດທ້າຍແມ່ນ Opus ຈະສະຫຼຸບລວມຜົນລັບຕາມ Acceptance Criteria ທີ່ຊັ້ນຕັດສິນກຳນົດໄວ້. ເມື່ອ Worker ຕິດຂັດ, ໃຫ້ຍົກລະດັບຂຶ້ນໄປຕາມລຳດັບ (Escalation Path):
- Haiku ລົ້ມເຫຼວ, ແກ້ໄຂອັດຕະໂນມັດ 2 ເທື່ອແລ້ວຍັງບໍ່ຜ່ານ, ໃຫ້ຢຸດການ retry.
- ປ່ຽນໃຫ້ Sonnet ເຂົ້າມາຮັບໜ້າທີ່ແກ້ໄຂແທນ.
- ຖ້າ Sonnet ກໍຍັງບໍ່ຜ່ານການກວດຮັບ, ສ່ວນຫຼາຍສະແດງວ່າການແຍກໜ້າວຽກ ຫຼື assumption ເບື້ອງຕົ້ນມີຂໍ້ຂັດແຍ້ງກັນ. ໃຫ້ສົ່ງໜ້າວຽກກັບຄືນ Opus ເພື່ອໃຫ້ Opus ຕັດສິນໃຈວ່າຄວນສົ່ງກັບໄປ Fable ເພື່ອແຍກໜ້າວຽກໃໝ່ຫຼືບໍ່.
3 ກົດເຫຼັກກ່ອນນຳໄປໃຊ້ໃນ Production#
ຢ່າ Fan-out ແບບບໍ່ຄິດ#
ວຽກງ່າຍໆ ບໍ່ຈຳເປັນຕ້ອງມີຫຼາຍ Worker, ສ່ວນວຽກທີ່ມີຄວາມກຳກວມສູງ model ນ້ອຍກໍແກ້ບໍ່ໄດ້. ມີພຽງແຕ່ວຽກແບບຄົ້ນຫາທີ່ "ມີ solution space ກວ້າງ" ແລະ "ສາມາດກວດສອບໄດ້ໄວດ້ວຍ automated test" ເທົ່ານັ້ນ ທີ່ຄຸ້ມຄ່າກັບການປ່ອຍໃຫ້ Haiku ຫຼາຍໆໂຕແລ່ນຂະໜານກັນ.
ແຍກ Environment, ລັອກ Lockfile ໄວ້#
Git Worktree ແຍກສະເພາະການປ່ຽນແປງຂອງ code ເພື່ອບໍ່ໃຫ້ Worker ທີ່ລັນຂະໜານກັນຂຽນທັບໄຟລ໌ຂອງກັນແລະກັນ; ມັນບໍ່ໄດ້ຈຳກັດ network ແລະ ບໍ່ໄດ້ຈຳກັດຂອບເຂດທີ່ program ສາມາດ access ໄດ້. ເພື່ອປ້ອງກັນ Supply Chain Attack, ຍັງຈຳເປັນຕ້ອງມີ sandbox, ພ້ອມທັງຫ້າມບໍ່ໃຫ້ Worker ຕິດຕັ້ງ package ທີ່ຍັງບໍ່ຜ່ານການກວດສອບ ຫຼື ແກ້ໄຂ Lockfile ໂດຍພາລະການ. ການເປີດສິດ install ຕາມໃຈ ກໍເທົ່າກັບການປ່ອຍໃຫ້ Agent ນຳເອົາ package ແລະ script ທີ່ບໍ່ຮູ້ທີ່ມາມາໄວ້ໃນ codebase.
ກວດຮັບດ້ວຍ Metrics ທີ່ວັດແທກໄດ້, ບໍ່ແມ່ນຄຳວິຈານຂອງ Model#
Test results, coverage, memory usage ແລະ latency ຕ່າງຫາກທີ່ເປັນຫຼັກຖານທີ່ສາມາດ reproduce ແລະ ປຽບທຽບໄດ້. ຄຳວິຈານເປັນຂໍ້ຄວາມຂອງ model ສາມາດໃຊ້ເປັນບ່ອນອີງໄດ້, ແຕ່ບໍ່ສາມາດເອົາມາໃຊ້ກວດຮັບຄຸນນະພາບຂອງ code ໄດ້.
Model ທີ່ລາຄາຖືກ, ຕ້ອງໃຊ້ໃຫ້ຖືກບ່ອນ#
Haiku 5.5 ເຮັດໃຫ້ການເຮັດວຽກແບບຂະໜານມີລາຄາຖືກລົງ, ແຕ່ການຂະໜານດ້ວຍຕົວມັນເອງບໍ່ໄດ້ເຮັດໃຫ້ຜົນລັບຖືກຕ້ອງຂຶ້ນມາໄດ້. ຕ້ອງແຍກການຕັດສິນ, ການຈັດສັນ, ການກວດສອບ, ແລະ ການກວດຮັບອອກຈາກກັນກ່ອນ, ຄວາມຖືກ ແລະ ຄວາມໄວ ຈຶ່ງຈະກາຍເປັນຂໍ້ໄດ້ປຽບທີ່ແທ້ຈິງ.
ໂຄງສ້າງຫຼາຍຊັ້ນນີ້, ຄວາມຈິງແລ້ວກໍຄື Graph ທີ່ຂ້ອຍເຄີຍເວົ້າໄວ້ໃນ AI Agent ແທ້ຈິງແລ້ວກໍຄືທີມ Agile ທີມໜຶ່ງ: ໃຜເຮັດກ່ອນ, ເຮັດແລ້ວສົ່ງຕໍ່ໃຫ້ໃຜ, ເວລາມີບັນຫາສົ່ງຕໍ່ໃຫ້ໃຜ.