การตัดสินใจโดยโมเดลเทียบกับการกำหนดตายตัวในโค้ด
ให้โมเดลตัดสินใจ และสงวนโค้ดไว้สำหรับสิ่งที่ต้องรับประกัน
การตัดสินใจโดยโมเดลเทียบกับการกำหนดตายตัวในโค้ด เป็นบทเรียน Claude Architect ฟรีบน CoddyKit นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Claude Architect และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Claude Architect มีบทเรียนทั้งหมด 4 บทเรียน
สองวิธีในการตัดสินใจ
ตัวกระทำทุกตัวที่คุณสร้างต้องตัดสินใจ ใครเป็นผู้ตัดสินใจคือทางเลือกด้านการออกแบบ
มีสองทางเลือก:
- ขับเคลื่อนโดยโมเดล: Claude พิจารณาสถานการณ์และเลือกขั้นตอนถัดไป
- เขียนตายตัว: โค้ดของคุณบังคับขั้นตอนนั้นไม่ว่าสถานการณ์จะเป็นอย่างไร
กฎสำหรับข้อสอบคือ ให้โมเดลตัดสินใจ และสงวนโค้ดที่เขียนตายตัวไว้สำหรับการรับประกันที่คุณไม่สามารถยอมให้ผิดพลาดได้
เหตุใดโมเดลจึงควรเป็นผู้ขับเคลื่อน
งานจริงเป็นงานปลายเปิด ไม่สามารถทราบลำดับขั้นตอนได้ล่วงหน้า
ข้อความจากลูกค้าอาจต้องค้นหาข้อมูลหนึ่งครั้งหรือสามครั้ง งานวิจัยอาจแตกแขนงไปในทิศทางที่คุณคาดเดาไม่ได้ Claude จะอ่านบริบทปัจจุบันในทุกช่วงการสนทนาและปรับตัว
หากคุณเขียนเส้นทางตายตัว คุณจะทำให้ตัวกระทำติดอยู่ในสคริปต์ที่แข็งตัวเพียงแบบเดียว และสคริปต์จะแตกทันทีเมื่อความเป็นจริงแตกต่างจากแผน ดังนั้นค่าเริ่มต้นคือ มอบเครื่องมือให้ Claude แล้วปล่อยให้ Claude เลือก
วงจรแบบมีตัวกระทำ
นี่คือวงจรที่ขับเคลื่อนโดยโมเดล คุณส่งประวัติข้อความทั้งหมดในทุกช่วงการสนทนา (โมเดลไม่มีสถานะ) จากนั้นตรวจสอบ stop_reason:
tool_use→ เรียกใช้เครื่องมือ เพิ่มผลลัพธ์ต่อท้าย แล้ววนซ้ำอีกครั้งend_turn→ โมเดลทำงานเสร็จแล้ว หยุด
โมเดลตัดสินใจว่าจะทำอะไร ส่วนโค้ดของคุณเพียงดำเนินการและวนซ้ำ
while True:
resp = client.messages.create(
model="claude-opus-4-8",
max_tokens=16000,
tools=tools,
messages=messages, # FULL history every turn
)
messages.append({"role": "assistant", "content": resp.content})
if resp.stop_reason == "end_turn":
break
if resp.stop_reason == "tool_use":
results = run_tools(resp.content)
messages.append({"role": "user", "content": results})หยุดเมื่อได้รับสัญญาณ ไม่ใช่เมื่อพบคำในข้อความ
คุณทราบได้อย่างไรว่าเอเจนต์ทำงานเสร็จแล้ว ให้ยุติการทำงานเมื่อพบ stop_reason — อย่ายุติด้วยการค้นหาคำอย่าง "done" หรือ "finished" ในข้อความเป็นอันขาด
การแยกวิเคราะห์ข้อความเพื่อหาสัญญาณว่างานเสร็จแล้วเป็นรูปแบบการออกแบบที่ควรหลีกเลี่ยงอย่างยิ่ง โมเดลอาจพูดว่า "ฉันคิดเสร็จแล้ว" ระหว่างทำงาน หรืออาจไม่พูดคำว่า "done" เลยก็ได้ ส่วน stop_reason ที่มีโครงสร้างชัดเจนคือสัญญาณจริงที่เชื่อถือได้
# WRONG — parsing text for a completion word
if "done" in resp.content[0].text.lower():
break
# RIGHT — terminate on the structured stop signal
if resp.stop_reason == "end_turn":
breakขีดจำกัดจำนวนรอบคือระบบป้องกัน
คุณอาจกำหนดจำนวนรอบสูงสุดของลูปได้ ซึ่งทำได้ไม่ผิด — แต่ควรเข้าใจ บทบาท ของมัน
ขีดจำกัดจำนวนรอบเป็น ระบบป้องกัน ที่หยุดลูปซึ่งทำงานต่อเนื่องจนควบคุมไม่ได้ แต่ ไม่ใช่กลไกหลักในการหยุด การหยุดหลักต้องเป็น stop_reason == "end_turn" เสมอ
หากตามปกติเอเจนต์ของคุณทำงานเสร็จได้ก็ต่อเมื่อชนขีดจำกัด นั่นหมายความว่าตรรกะการตัดสินใจมีปัญหา — คุณกำลังกำหนดตายตัวในสิ่งที่ควรให้โมเดลเป็นผู้ตัดสินใจ
MAX_TURNS = 20 # safety net only
for turn in range(MAX_TURNS):
resp = client.messages.create(
model="claude-opus-4-8", max_tokens=16000,
tools=tools, messages=messages,
)
messages.append({"role": "assistant", "content": resp.content})
if resp.stop_reason == "end_turn":
break # the REAL exit
messages.append({"role": "user", "content": run_tools(resp.content)})เมื่อโค้ดต้องรับประกันผลลัพธ์
ต่อไปคืออีกด้านหนึ่งของกฎนี้ ผลลัพธ์บางอย่างสำคัญเกินกว่าจะปล่อยให้โมเดลเชิงความน่าจะเป็นเป็นผู้ตัดสินใจ
พรอมต์มีความน่าเชื่อถือประมาณ 90% — โดยทั่วไปโมเดลจะทำตามคำสั่ง แต่ก็ไม่เสมอไป สำหรับกฎที่มีผลกระทบด้าน การเงิน กฎหมาย หรือความปลอดภัย คำว่า "โดยทั่วไป" ยังไม่เพียงพอ
สำหรับกรณีเหล่านั้น คุณควรใช้ โค้ดตายตัว ซึ่งให้ผล แน่นอน 100% นี่คือจุดเดียวที่คุณนำการตัดสินใจออกจากโมเดล
ฮุกบังคับใช้ขีดจำกัดที่ห้ามฝ่าฝืน
เครื่องมือแบบกำหนดผลแน่นอนสำหรับเรื่องนี้คือ ฮุก ฮุกจะดักการกระทำไว้และสามารถบล็อกได้ก่อนที่การกระทำนั้นจะเกิดขึ้น — ด้วยความแน่นอน 100%
ตัวอย่างคลาสสิกคือ "ห้ามคืนเงินเกิน $500" คุณไม่เขียนกฎนี้เป็นคำสั่งในพรอมต์ แต่เขียนเป็นฮุกสำหรับการเรียกออกไป ซึ่งจะบล็อกการคืนเงินที่เกินขีดจำกัดทุกครั้ง
ใช้ฮุกเพื่อการรับประกัน และใช้พรอมต์เพื่อการใช้ดุลยพินิจ
# Deterministic policy hook — runs before the refund tool executes
def before_process_refund(tool_input):
if tool_input["amount"] > 500:
return {
"block": True,
"reason": "Refunds over $500 require human approval.",
}
return {"block": False}เงื่อนไขก่อนทำงานในโปรแกรม
แนวคิดเดียวกันนี้ใช้กับเงื่อนไขก่อนทำงาน — สิ่งที่ต้องเป็นจริงก่อนการกระทำจะเริ่มขึ้น
ตัวอย่างเช่น ห้ามดำเนินการคืนเงินจนกว่าจะยืนยันตัวตนของลูกค้าแล้ว คำแนะนำในพรอมต์ ("โปรดยืนยันตัวตนก่อน") มีความน่าเชื่อถือเพียงประมาณ 90% ส่วนเงื่อนไขก่อนทำงานในโปรแกรม — บล็อก process_refund จนกว่า get_customer จะส่งคืน ID ที่ผ่านการยืนยัน — เป็นการรับประกันที่แน่นอน
โค้ดบังคับใช้เงื่อนไขก่อนทำงาน ส่วนโมเดลยังคงตัดสินใจในเรื่องอื่นทั้งหมด
def before_process_refund(tool_input, state):
# Deterministic precondition: identity must be verified first
if not state.get("customer_verified"):
return {"block": True,
"reason": "Call get_customer and verify identity before refunding."}
return {"block": False}อย่ากำหนดทุกอย่างตายตัวเกินไป
ความผิดพลาดในอีกทิศทางหนึ่งก็มีต้นทุนสูงไม่แพ้กัน นั่นคือการกำหนดตายตัวในเรื่องที่โมเดลควรเป็นผู้ตัดสินใจ
หากคุณครอบทุกขั้นตอนไว้ด้วยตรรกะแตกแขนงแบบ if/else คุณก็ได้สร้างกระบวนการทำงานต่อเนื่องที่แข็งทื่อขึ้นมาใหม่ และทิ้งความสามารถในการปรับตัวของโคลดไป เอเจนต์จะไม่สามารถจัดการกรณีที่ไม่คาดคิดได้อีกต่อไป
ควรสงวนโค้ดตายตัวไว้สำหรับการรับประกันในขอบเขตแคบ ๆ — เงิน กฎหมาย ความปลอดภัย และเงื่อนไขก่อนทำงานที่จำเป็น เรื่องอื่นทั้งหมดควรให้โมเดลเป็นผู้ขับเคลื่อน
การแบ่งหน้าที่อย่างเหมาะสม
สรุปเป็นการแบ่งหน้าที่ได้ดังนี้
- โมเดลตัดสินใจ: จะเรียกเครื่องมือใด เรียกตามลำดับใด งานเสร็จเมื่อใด และจะกู้คืนอย่างไรเมื่อได้ผลลัพธ์ที่ไม่คาดคิด
- โค้ดรับประกัน: เพดานตามนโยบาย (การคืนเงิน ≤ $500) เงื่อนไขก่อนทำงานที่จำเป็น (ID ที่ผ่านการยืนยัน) และการยุติลูปเมื่อพบ
stop_reason
โมเดลเป็นผู้ขับเคลื่อนเส้นทางการทำงาน ส่วนโค้ดเป็นผู้กำหนดขอบเขตที่ห้ามข้ามโดยเด็ดขาด
กระบวนการตายตัวเทียบกับแบบปรับตัวได้
มีข้อควรสังเกตประการหนึ่งคือ ไม่ใช่ทุกงานจะเปิดกว้างไร้จุดสิ้นสุด
- สำหรับกระบวนการที่ทราบลำดับแน่นอน กระบวนการแบบตายตัว (การต่อพรอมต์) ก็เหมาะสม — เพราะขั้นตอนต่าง ๆ ตายตัวอยู่แล้ว
- สำหรับการสืบค้นที่เปิดกว้าง ให้ใช้การแยกย่อยแบบปรับตัวได้ และปล่อยให้โมเดลเลือกเส้นทาง
ดังนั้นคำว่า "ให้โมเดลตัดสินใจ" จึงใช้กับกรณีที่เส้นทางยังไม่แน่นอนจริง ๆ หากทราบลำดับอย่างแท้จริง การกำหนดโครงสร้างก็เหมาะสม — เพียงอย่ายัดเยียดโครงสร้างให้กับปัญหาที่ต้องอาศัยการปรับตัว
ตรวจสอบความเข้าใจอย่างรวดเร็ว
เอเจนต์ฝ่ายสนับสนุนต้องไม่ออกใบคืนเงินเกิน $500 เด็ดขาด ส่วนการคืนเงินไม่เกิน $500 ควรจัดการได้อย่างราบรื่นภายในการสนทนา การออกแบบในระดับสถาปัตยกรรมที่เหมาะสมคืออะไร
ประเด็นสำคัญที่ควรจำ
จำกฎนี้ไว้: ให้โมเดลตัดสินใจ และสงวนโค้ดไว้สำหรับการรับประกัน
- โดยค่าเริ่มต้น ให้การตัดสินใจขับเคลื่อนด้วยโมเดล — โคลดจะปรับตัวตามบริบทขณะทำงาน
- ขับเคลื่อนวงจรเอเจนต์ และยุติเมื่อพบ
stop_reasonอย่าแยกวิเคราะห์ข้อความเพื่อยุติการทำงาน - ขีดจำกัดจำนวนรอบเป็นระบบป้องกัน ไม่ใช่กลไกหลักในการหยุด
- ใช้ฮุกและเงื่อนไขก่อนทำงานในโปรแกรมกับกฎด้านการเงิน กฎหมาย หรือความปลอดภัย — ให้ผลแน่นอน 100% เมื่อเทียบกับพรอมต์ที่มีความน่าเชื่อถือประมาณ 90%
- อย่ากำหนดทุกอย่างตายตัวเกินไป การรับประกันควรเป็นเพียงขอบเขตแคบ ๆ ไม่ใช่ทั้งเอเจนต์
เรียนรู้ Python ด้วย AI tutor — ฟรี
เขียนและเรียกใช้โค้ดจริงในเบราว์เซอร์ของคุณ รับความช่วยเหลือทันทีจาก AI tutor 24/7 และเรียนรู้ต่อจากที่คุณหยุดบนเว็บหรือในแอป
- คอร์ส
- 26
- บทเรียน
- 104
คำถามที่พบบ่อย
บทเรียน “การตัดสินใจโดยโมเดลเทียบกับการกำหนดตายตัวในโค้ด” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “การตัดสินใจโดยโมเดลเทียบกับการกำหนดตายตัวในโค้ด” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Claude Architect ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Claude Architect มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “การตัดสินใจโดยโมเดลเทียบกับการกำหนดตายตัวในโค้ด”
ให้โมเดลตัดสินใจ และสงวนโค้ดไว้สำหรับสิ่งที่ต้องรับประกัน คุณปฏิบัติ Claude Architect ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Claude Architect หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน Claude Architect บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน
บทเรียน “การตัดสินใจโดยโมเดลเทียบกับการกำหนดตายตัวในโค้ด” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน Claude Architect นี้ได้ไหม
ได้ บทเรียน Claude Architect ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- อะไรทำให้ระบบมีพฤติกรรมแบบเอเจนต์
- การตัดสินใจโดยโมเดลเทียบกับการกำหนดตายตัวในโค้ด
- ควรใช้เอเจนต์เมื่อใด
- ภาพรวมลูปแบบเอเจนต์