Haiku 5.5 ควรใช้เป็น Subagent หรือ Agent เดี่ยว: งานต้นทุนต่ำควรอยู่ที่ไหน

Anthropic ได้เปิดตัว Claude Haiku 5.5 ไปเมื่อวันที่ 7 ตุลาคม พร้อมสรุปหน้าที่ของมันไว้ในประโยคเดียวว่า “ทำงานร่วมกับ Opus 5.5 และ Sonnet 5.5 ได้เป็นอย่างดีในฐานะ subagent สำหรับงานเขียนโค้ด” โดยในบทความเปิดตัวระบุราคาไว้ที่ 0.10 ดอลลาร์ต่อ 1 ล้าน input tokens และ 0.50 ดอลลาร์ต่อ 1 ล้าน output tokens สำหรับ prompt ที่ไม่เกิน 100K tokens และขยับขึ้นเป็น 0.50 ดอลลาร์ กับ 2.50 ดอลลาร์เมื่อเกินกว่านั้น นอกจากนี้ ความคิดเห็นจากลูกค้า 2 ใน 6 รายที่ยกมาในหน้าเว็บยังสะท้อนรูปแบบการใช้งานแบบเดียวกัน นั่นคือ Rogo ใช้ Haiku 5.5 เป็น subagent เพื่อดึงตัวเลขรายได้จากรายงาน 10-K ระหว่างที่โมเดลตัวใหญ่กำลังสร้างสไลด์นำเสนอ ส่วน Cognition ก็นำไปใช้เป็น “คู่หู” (sidekick) ภายใต้ Opus 5.5 ใน Devin Fusion

แต่นั่นเป็นเพียงมุมมองในแง่ของตัวโมเดล เพราะสำหรับทีมที่ต้องบริหารจัดการหลายเอเจนต์ คำถามที่ยากกว่าคือเรื่องของการจัดการบนบอร์ดงาน เนื่องจาก subagent จะทำงานอยู่ภายในการรันของตัวอื่น มันจึงไม่มี Task ไม่มี Assignee และไม่มีสถานะเป็นของตัวเอง ทำให้เวลาที่มันทำอะไรผิดพลาด ความผิดพลาดนั้นจะปรากฏภายใต้ชื่อของเอเจนต์ตัวหลัก (lead) ตอนนี้งานที่ต้นทุนต่ำมีราคาถูกลงมากพอให้เราสั่งทำได้คราวละมากๆ การตัดสินใจที่แท้จริงจึงอยู่ที่ว่า งานเหล่านั้นควรแสดงให้เห็นตรงจุดไหน

สรุปสั้นๆ (TL;DR)

เลือกใช้ Haiku 5.5 เป็น in-run subagent เมื่อผลลัพธ์ของมันถูกนำไปใช้ต่อและตรวจสอบโดยเอเจนต์ตัวหลัก เช่น การค้นหาข้อมูล การสรุปเนื้อหา การสำรวจโค้ด หรือการย่อข้อความ แต่ควรกำหนดให้เป็น Agent แยกต่างหากพร้อมมี Task เป็นของตัวเอง เมื่อผลลัพธ์นั้นต้องถูกส่งมอบ (ship) มีคนต้องคอยอนุมัติรับงาน หรือเมื่องานนั้นอาจล้มเหลวได้ด้วยตัวมันเอง สำหรับใน Claude Code ให้ระบุ model: claude-haiku-5-5 แบบเจาะจงในไฟล์ subagent แทนที่จะใช้ alias อย่าง haiku และพึงระลึกไว้เสมอว่า Explore subagent ในตัวนั้นจะทำงานด้วยโมเดลของการสนทนาหลัก ไม่ใช่ Haiku ส่วนใน Sharkly คุณสามารถสร้าง Agent ราคาประหยัดได้ผ่านการตั้งค่า Custom arguments ทำให้ทั้งสองรูปแบบแชร์ Computer ร่วมกันได้ โดยหลักการคือ เอเจนต์มีหน้าที่ค้นคว้า ลงมือทำ ทดสอบ และรายงานผล ส่วนมนุษย์มีหน้าที่กำหนดทิศทาง มอบหมายสิทธิ์ และตรวจรับผลงาน

มองจากภาพรวมด้านบน Subagent คือสิ่งที่คุณมองไม่เห็น

Subagent เปรียบเสมือนผู้ช่วยที่เอเจนต์ตัวหลักสร้างขึ้นมาภายในเซสชันของตัวเอง เพื่อมอบหมายงานเฉพาะทางที่ขอบเขตแคบๆ ให้ทำ แล้วรอรับคำตอบกลับมา ซึ่งนับเป็นการออกแบบที่เหมาะสมสำหรับงานหลายประเภท แต่ก็ถือเป็นขอบเขตที่จำกัดเช่นกัน เพราะทุกสิ่งที่ subagent ทำจะเกิดขึ้นอยู่ภายในการรันเพียงรอบเดียว

หากมองจากมุมมองของบอร์ดบริหารงาน การเลือกวางตำแหน่งทั้งสองแบบนี้ให้คำตอบที่แตกต่างกันในทุกๆ คำถามที่ผู้จัดการต้องการรู้

ปัญหาในลักษณะนี้สำหรับเวอร์ชัน Codex เคยถูกพูดถึงไปแล้วในบล็อกนี้ นั่นคือ เมื่อเซสชันหนึ่งกระจายงานออกไปยัง subagents จำนวนมาก คำตอบรวมเพียงชุดเดียวจะกลายเป็นสิ่งเดียวที่ผู้ตรวจทานมองเห็น ซึ่ง Haiku 5.5 ยิ่งทำให้ข้อแลกเปลี่ยนนี้ดูน่าดึงดูดยิ่งขึ้น เนื่องจาก Anthropic ออกแบบและตั้งราคามาเพื่อรองรับบทบาทนี้โดยเฉพาะ รูปแบบของ Rogo นั้นได้ผลดีเพราะเอเจนต์ตัวหลักเป็นผู้นำตัวเลขรายได้ไปใช้งานต่อ และผลลัพธ์จะไปปรากฏอยู่ในสไลด์นำเสนอ ซึ่งเป็น artifact ที่คนจะต้องตรวจทานก่อนนำไปใช้งานจริงอยู่แล้ว ข้อผิดพลาดของ subagent (หากมี) จึงจะถูกตรวจพบในขั้นตอนการรีวิวนั้น

แต่ลองนึกภาพเมื่อนำโมเดลเดียวกันนี้ไปใช้กับงานที่ตัวผลลัพธ์คือ artifact โดยตรง เช่น การทำ migration, การแก้ไข config, การแก้ข้อมูล หรือการตอบกลับลูกค้า หากทำในฐานะ subagent งานชิ้นนั้นจะปรากฏขึ้นบนบอร์ดเพียงแค่ในฐานะส่วนหนึ่งของสรุปจากเอเจนต์ตัวหลักเท่านั้น จะไม่มีใครเห็นเลยว่า diff ส่วนไหนมาจากโมเดลราคาประหยัด และคนที่ต้องอนุมัติ Task นั้นก็กำลังอนุมัติงานที่ตนเองไม่สามารถระบุที่มาได้อย่างชัดเจน

หลักเกณฑ์ที่สรุปออกมาเป็นลายลักษณ์อักษร

บทความเกี่ยวกับ Luna ได้เคยตอบคำถามไปแล้วว่างวดงานประเภทใดควรส่งให้โมเดลระดับราคาประหยัดทำ: นั่นคือให้เลือกจากความง่ายในการตรวจสอบ (checkability) ไม่ใช่ระดับความยาก (difficulty) แต่ Haiku 5.5 ได้เพิ่มแกนที่สองเข้ามา เมื่อต้นทุนงานถูกลงมากพอ ให้ตัดสินใจว่างานควรไปอยู่ที่ไหนโดยดูจากว่าใครเป็นผู้ใช้ผลลัพธ์นั้น

Haiku 5.5 placement rule

In-run subagent when ALL of these hold:
  - the output is read by the lead agent, not shipped
  - the lead checks or uses it before continuing
  - a wrong answer shows up downstream, inside reviewed work
  examples: file lookups, codebase exploration, log and doc summaries,
            classification, pulling one fact from a long document

Own Agent and own Task when ANY of these hold:
  - the output ships (a diff, a message, a record, a submitted form)
  - a person has to accept it
  - it can fail, stall, or need a human answer independently
  - you want its acceptance rate measured separately from the lead's

ให้ใช้ subagent เมื่องานนั้นมุ่งไปสู่คำตอบเดียวที่เอเจนต์ตัวหลักต้องการ และให้ใช้ Task แยกต่างหากเมื่องานนั้นเป็นสิ่งที่ทีมจำเป็นต้องระบุชื่อผู้รับผิดชอบกำกับไว้

อย่างไรก็ตาม ใน Sharkly ยังมีทางเลือกตรงกลาง นั่นคือใน Crew ตัว leader Agent สามารถแท็กเรียกสมาชิกเข้ามาร่วมทำงานเฉพาะเรื่องได้ โดยสมาชิกเหล่านั้นจะทำงานบน Task เดียวกันและส่งผลลัพธ์เข้ามาในแชตของ Task นั้น สมาชิกที่เป็น Haiku 5.5 จึงปรากฏให้เห็นบน Task ได้โดยไม่จำเป็นต้องสร้าง Task แยกเป็นของตัวเอง ให้ใช้รูปแบบนี้เมื่อมีคนคนเดียวเป็นผู้ตรวจรับผลลัพธ์รวมทั้งหมด แต่ให้แยกเป็นคนละ Task เมื่อมีผู้ตรวจทานหลายคนที่ต้องตรวจทานงานคนละส่วนกัน

การตั้งค่าการทำงานทั้งสองรูปแบบ

ทั้งสองรูปแบบมีจุดตั้งค่าจุดหนึ่งที่มักจะทำผิดกันได้ง่าย

รูปแบบ subagent ใน Claude Code: Claude Code ต้องเป็นเวอร์ชัน v2.1.293 ขึ้นไปจึงจะรองรับ Haiku 5.5 โดยฟิลด์ model ของ subagent สามารถกำหนดค่าเป็น sonnet, opus, haiku, fable, รหัสโมเดลแบบเต็ม (full model id) หรือ inherit ตามที่ระบุไว้ในเอกสารคู่มือ subagents แนะนำให้ระบุรหัสโมเดลแบบเต็มเสมอ:

---
name: lookup
description: Find files, symbols and config values. Read-only.
model: claude-haiku-5-5
---
Answer with paths and line numbers. Do not edit files.

การใช้ alias คือกับดัก เพราะจากเอกสารคู่มือการกำหนดค่าโมเดลระบุว่า haiku จะแปลงเป็น Haiku 5.5 เฉพาะบน Anthropic API เท่านั้น แต่บน Amazon Bedrock, Google Cloud, Microsoft Foundry และ Claude Platform on AWS ค่านี้จะยังคงถูกแปลงเป็น Haiku 4.5 ดังนั้น ไฟล์ subagent เดียวกันที่แชร์ข้าม Computers บนผู้ให้บริการคนละราย อาจรันโมเดลคนละตัวกันภายใต้ชื่อเดียวกันได้ ทั้งนี้ ตัวแปร ANTHROPIC_DEFAULT_HAIKU_MODEL จะเป็นตัวกำหนดความหมายของ haiku และสิ่งที่ Claude Code จะเลือกใช้สำหรับการทำงานเบื้องหลังบนแต่ละโฮสต์

สิ่งที่น่าประหลาดใจอีกข้อคือ Explore subagent ที่ติดตั้งมาในตัวจะใช้โมเดลเดียวกับการสนทนาหลัก ไม่ใช่ Haiku หากเอเจนต์ตัวหลักใช้ Opus 5.5 การสำรวจก็จะทำงานบน Opus 5.5 ไปด้วย คำแนะนำในเอกสารคู่มือระบุไว้ว่า ให้สร้าง subagent ระดับ user หรือ project ที่ตั้งชื่อว่า Explore ขึ้นมาเพื่อ override ทับตัวที่มากับระบบ พร้อมระบุ model: haiku เพื่อให้การสำรวจทำงานบนโมเดลที่ต้นทุนต่ำกว่า คุณสามารถตั้งชื่อไฟล์ด้านบนตามนี้ได้เลย แต่ยังคงแนะนำให้ใส่รหัสโมเดลแบบเต็ม

รูปแบบ Agent ใน Sharkly: Sharkly ไม่ได้เป็นผู้เลือกโมเดลให้ โดยในเอกสารคู่มือ Agents ระบุไว้ว่า: “Agent จะทำงานตามโมเดลเริ่มต้นของ Runtime โดยไม่มีการรับประกันหรือแสดงชื่อโมเดลเฉพาะเจาะจง หากต้องการเปลี่ยนโมเดล ให้ระบุใน Custom arguments ที่ตัว Agent หรือ Runtime” บนหน้าจอ Agent จึงไม่มีเมนูดรอปดาวน์ให้เลือกโมเดลและไม่มีส่วนควบคุมความลึกในการคิด (thinking depth) ดังนั้น เอเจนต์ราคาประหยัดจึงถูกสร้างขึ้นเป็น Agent ตัวที่สองบน Computer เดียวกันและรันไทม์ Claude Code เดียวกัน โดยระบุ claude-haiku-5-5 ในช่อง Custom arguments ขณะที่เอเจนต์ตัวหลักยังคงใช้ค่าเริ่มต้นเดิม ซึ่งในคู่มือแนะนำอย่างเป็นทางการเรื่อง การรันเอเจนต์ Claude Haiku 5.5 ใน Sharkly ได้อธิบายขั้นตอนไว้อย่างละเอียดแล้ว

เนื่องจากตัว Task ไม่ได้แสดงชื่อโมเดล จึงควรเพิ่มคำสั่งเข้าไปอีกหนึ่งบรรทัดในคำแนะนำ (instructions) ของเอเจนต์ราคาประหยัดว่า: ให้รายงานชื่อโมเดลในคำตอบสุดท้ายด้วย สำหรับใน Claude Code นั้น Haiku 5.5 จะถูกตั้งค่า effort เริ่มต้นไว้ที่ medium และไม่สามารถปิด thinking ได้ ดังนั้นระดับ effort ที่คุณกำหนดไว้จึงเป็นตัวตัดสินค่าใช้จ่ายในการรันแต่ละครั้ง

ผลกระทบจากจุดตัดราคาที่ 100K tokens

การตัดสินใจเลือกตำแหน่งการวางเอเจนต์ยังเป็นตัวกำหนดราคาที่คุณต้องจ่ายอีกด้วย เพราะ Haiku 5.5 จะคิดราคา 0.10/0.50 ดอลลาร์ต่อล้านโทเคนเฉพาะเมื่อ prompt มีขนาดไม่เกิน 100K tokens เท่านั้น หากเกินกว่านั้น ราคาจะปรับขึ้นเป็น 0.50/2.50 ดอลลาร์ ซึ่งสูงขึ้นถึง 5 เท่า ทั้งนี้ Anthropic ระบุว่าคำขอใช้งาน Haiku 4.5 ราว 90% มักจะอยู่ต่ำกว่าเกณฑ์ดังกล่าว

การเรียกใช้งาน subagent มักมีลักษณะที่ไม่เกินเกณฑ์นี้ ได้แก่ บรีฟงานที่กระชับ การอ่านข้อมูลสั้นๆ และการส่งคำตอบกลับมาครั้งเดียว ในขณะที่การทำงานของ Agent แบบแยกเดี่ยวบน Task ขนาดยาวมักจะเกินขีดจำกัดนี้ไป โดยปกติแล้ว Claude Code จะทำการย่อบริบท (compact) สำหรับโมเดลที่รองรับ 1M โดยกำเนิดอย่าง Haiku 5.5 ที่ประมาณ 967K tokens ซึ่งเกิน 100K ไปไกลมาก ทำให้การรัน Haiku 5.5 ที่ยาวนานอาจต้องจ่ายค่าบริการในอัตราที่สูงขึ้นในรอบหลังๆ เกือบทั้งหมด ทางออกสำหรับ Task ขนาดยาวคือการซอยงานย่อย ไม่ใช่การย้ายมันกลับเข้าไปไว้ภายในการรันของเอเจนต์ตัวหลัก

สิ่งนี้ทำให้การเลือกระหว่างสองทางมีมิติทางด้านต้นทุนที่ชัดเจนขึ้น คือให้ใช้ in-run subagent สำหรับการเรียกใช้งานสั้นๆ ที่เน้นการอ่านข้อมูล ซึ่งสามารถคุมให้อยู่ในอัตราราคาต่ำได้ง่าย และใช้ Agent แยกสำหรับงานที่ต้องส่งมอบ พร้อมกำหนดขนาด Task ให้จบลงได้ก่อนที่ context จะบวม

สองสิ่งที่ไม่เคยเปลี่ยนไป

Anthropic ชี้แจงถึงขีดจำกัดอย่างตรงไปตรงมาว่า Sonnet 5.5 และ Opus 5.5 “ยังคงเป็นตัวเลือกที่ดีกว่าสำหรับงานเขียนโค้ดที่ซับซ้อนในรูปแบบเอเจนต์” และในตารางวันเปิดตัว Haiku 5.5 ทำคะแนนบน Terminal-Bench 4.0 ได้ 39.2% เมื่อเทียบกับ Sonnet 5.5 ที่ทำได้ 70.6% โดยทั้งคู่รันที่ max effort ดังนั้น Haiku 5.5 จึงเหมาะสำหรับเป็นคนทำงานหรือผู้ช่วย ไม่ใช่เอเจนต์ตัวหลัก

นอกจากนี้ การมีผู้ช่วยราคาถูกลงไม่ได้แปลว่าต้นทุนในการตรวจรับงานจะถูกลงตามไปด้วย ไม่ว่า Haiku 5.5 จะรันในฐานะ subagent หรือรันเป็น Agent ของตัวเอง สุดท้ายก็ต้องมีใครสักคนเป็นผู้รับผิดชอบผลลัพธ์นั้นอยู่ดี โดยรูปแบบ subagent จะซ่อนผู้รับผิดชอบคนนั้นไว้ภายในการรันของเอเจนต์ตัวหลัก ส่วนรูปแบบ Agent จะระบุชื่อและสถานะออกมาอย่างชัดเจน ยิ่งสำหรับงาน browser และ desktop ซึ่งการรันอาจหยุดลงขณะที่งานเสร็จไปเพียงครึ่งเดียว ความแตกต่างตรงนี้จะสร้างต้นทุนแฝงขึ้นอย่างรวดเร็ว ซึ่งเป็นประเด็นที่กล่าวถึงใน browser agents ราคาประหยัดและคิวการตรวจทาน ส่วนการตัดสินใจเลือกระหว่าง Haiku 5.5 กับ GPT-6 Luna ในระดับราคาเดียวกันนั้นเป็นอีกเรื่องหนึ่ง ซึ่งสามารถอ่านเพิ่มเติมได้ใน สอง Runtime ราคาประหยัดในระดับราคาเดียวกัน

จดจำกฎเกณฑ์การวางตำแหน่งนี้ไว้ให้ขึ้นใจ ให้ subagent ทำหน้าที่ค้นหาข้อมูลที่เอเจนต์ตัวหลักเป็นผู้ตรวจสอบ และมอบหมาย Task แยกต่างหากสำหรับงานทุกชิ้นที่จะต้องส่งมอบจริง หากทีมของคุณใช้งานหลายเอเจนต์อยู่แล้ว Sharkly คือแพลตฟอร์มศูนย์กลางที่ช่วยให้คุณจัดการทั้ง tasks และผลลัพธ์ของพวกมันได้ในที่เดียว