ให้โมเดลตัดสินใจ ไม่ใช่ decision tree ตายตัว
แนวคิด
การออกแบบ agent มีสองปรัชญาที่ต่างกันชัดเจน แบบแรกคือ model-driven ปล่อยให้ Claude เป็นคนตัดสินใจเองว่ารอบนี้ควรเรียก tool ตัวไหน โดยดูจากบริบทและคำอธิบายของแต่ละ tool แบบที่สองคือ decision tree หรือลำดับ tool ที่เรากำหนดตายตัวไว้ล่วงหน้า แล้วบังคับให้เดินตามทีละก้าว
ในโหมด tool_choice แบบ auto ซึ่งเป็นค่าเริ่มต้น Claude จะพิจารณาทุก turn ว่าควรเรียก tool หรือจะตอบตรง ๆ มันเลือกเรียก tool เมื่อคำขอตรงกับความสามารถที่ tool อธิบายไว้ และคำตอบยังไม่มีอยู่ในบริบท นี่คือหัวใจของ model-driven ความรู้เชิงสถานการณ์อยู่ในตัวโมเดล เราแค่จัดหาเครื่องมือกับคำอธิบายที่ดีให้
decision tree เหมาะกับงานที่ลำดับตายตัวจริง ๆ และเป็น business logic ที่ห้ามพลาด แต่ถ้าเอามาครอบงานปลายเปิดที่ขั้นตอนขึ้นกับสิ่งที่ค้นพบระหว่างทาง มันจะแข็งเกินไป โมเดลปรับตัวไม่ได้เมื่อเจอสถานการณ์ที่ต้นไม้ไม่ได้เตรียมไว้
ทำไมสำคัญ
ที่ต้องแยกให้ออก เพราะการฝืนธรรมชาติของโมเดลทำให้เกิด anti-pattern ที่บั่นทอนความน่าเชื่อถือ กับดักคลาสสิกคือการอ่านข้อความภาษาธรรมชาติเพื่อชี้ว่าควรจบ loop เมื่อไร แทนที่จะเชื่อ stop_reason วิธีนี้เปราะ เพราะถ้อยคำของโมเดลเปลี่ยนไปมาได้ตลอด
กับดักที่สองคือการตั้งเพดานจำนวนรอบไว้เป็นกลไกหยุดหลัก แทนที่จะเป็นแค่ตาข่ายกันหลุด งานที่ต้องใช้หลายก้าวจริงจะถูกตัดจบก่อนเสร็จ กับดักที่สามคือการเช็กว่ามีข้อความ assistant โผล่มาไหมแล้วเหมาว่างานเสร็จ ทั้งที่โมเดลอาจแทรกข้อความก่อนเรียก tool ต่อ
สัญญาณเตือนที่ดีคือ ถ้าคุณพบว่าตัวเองกำลังเขียน regex เพื่อสกัด "การตัดสินใจ" ออกจากข้อความของโมเดล นั่นแปลว่าการตัดสินใจนั้นควรเป็น tool call หรือควรอ่านจาก stop_reason ตั้งแต่แรก
ตัวอย่าง
# Anti-pattern: อ่านข้อความเพื่อตัดสินว่าจบ
if "เสร็จเรียบร้อย" in resp.text:
stop() # เปราะ ภาษาเปลี่ยนได้
# Model-driven ที่ถูกต้อง: เชื่อสัญญาณของโมเดล
if resp.stop_reason != "tool_use":
stop() # โมเดลเป็นคนบอกเองว่าหยุด
การชี้นำว่าเมื่อไรควรเรียก tool ทำผ่าน system prompt และคำอธิบาย tool ที่ดี ไม่ใช่การฮาร์ดโค้ดลำดับ เช่น เพิ่มประโยค "ใช้เครื่องมือค้นข้อมูลก่อนตอบ" จะดันให้เรียก tool มากขึ้นโดยไม่ต้องล็อกเส้นทาง
เช็คความเข้าใจ
การใช้เพดานจำนวนรอบเป็นกลไกหยุดหลักของ loop เป็น anti-pattern เพราะอะไร
ในโหมด model-driven เราชี้นำว่าเมื่อไรควรเรียก tool ผ่านอะไร