Pydantic AI หรือ LangGraph: typed Python ไม่ได้แทน state machine ทุกงาน

ถ้า agent รับข้อมูล เรียกเครื่องมือ สร้างผลลัพธ์ที่ตรวจรูปแบบได้ แล้วจบภายในคำขอเดียว Pydantic AI กับ control flow แบบ Python มักเป็นทางเลือกที่ตรงงานกว่า เอกสารเปรียบเทียบของ Pydantic วาง typed Agent และ Python เป็นแนวทางหลักสำหรับเส้นทางเช่นนี้ แต่ถ้างานต้องหยุดรอคน เก็บตำแหน่งที่ค้างไว้ และกลับมาทำต่อ LangGraph เป็นตัวเลือกที่ควรประเมินจากการจัดการสถานะ ไม่ใช่จากชนิดของผลลัพธ์เพียงอย่างเดียว

คำถามสำคัญคือสถานะของงานต้องอยู่ต่อหลังการเรียกครั้งแรกสิ้นสุดหรือไม่ การตรวจว่าร่างคำตอบมีฟิลด์ครบช่วยป้องกันข้อมูลผิดรูปแบบ แต่ไม่ได้บอกว่างานกำลังรอใคร ผ่านการอนุมัติแล้วหรือยัง หรือทำขั้นที่มีผลภายนอกไปแล้วหรือไม่ หากต้องตอบคำถามเหล่านี้หลังโปรเซสหยุด โครงสร้างของ state machine และวิธีบันทึกสถานะจะมีน้ำหนักมากขึ้น

งานคืนเงินเดียวกันเผยให้เห็นเส้นแบ่ง

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

แบบแรก เจ้าหน้าที่อยู่ในขั้นตอนเดียวกับคำขอและตอบกลับทันที แอปเรียก agent เพื่อสร้างร่าง ตรวจผลลัพธ์ แล้วใช้เงื่อนไข Python ตัดสินว่าจะขอให้แก้ร่างหรือส่งต่อ ขั้นตอนทั้งหมดจบได้โดยไม่ต้องมีงานค้างที่ระบบจะกลับมารับช่วงในภายหลัง ข้อมูลที่ส่งระหว่างฟังก์ชันยังเป็นตัวแปรและออบเจ็กต์ของแอปตามปกติ

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

ความต่างจึงอยู่ที่อายุของสถานะและความชัดของทางเปลี่ยน ไม่ได้อยู่ที่จำนวนครั้งที่เรียกโมเดลเท่านั้น งานที่มีหลายการเรียกโมเดลแต่ทำต่อเนื่องจนจบอาจยังอ่านง่ายใน Python ขณะที่งานซึ่งเรียกโมเดลครั้งเดียวแต่ต้องรออนุมัติข้ามคำขออาจต้องมีสถานะถาวรที่ออกแบบอย่างจริงจัง

เมื่อ Python ธรรมดายังพอและเมื่อเริ่มแบกภาระ

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

ข้อดีของรูปแบบนี้คือขอบเขตความรับผิดชอบเห็นได้ชัด agent รับผิดชอบการโต้ตอบกับโมเดลและผลลัพธ์ที่ต้องตรวจ ส่วนฟังก์ชันของแอปรับผิดชอบการดึงข้อมูล สิทธิ์ของเจ้าหน้าที่ และการส่งข้อความ การเพิ่มกราฟให้เส้นทางสั้นเช่นนี้จะเพิ่มนิยามโหนดและทางเชื่อม โดยยังไม่ช่วยแก้ปัญหาการเก็บงานที่แอปไม่มี

แต่ Python ธรรมดาเริ่มรับหน้าที่ของ state machine เมื่อเงื่อนไขกระจายออกไป เช่น คำขอบางประเภทต้องให้หัวหน้าอนุมัติ คำขอที่ข้อมูลไม่ครบต้องย้อนกลับไปหาลูกค้า และคำขอที่รออยู่อาจถูกยกเลิก หากแต่ละฟังก์ชันมีเงื่อนไขตรวจสถานะของตัวเอง การเพิ่มเส้นทางใหม่จะต้องตามแก้หลายจุด และยากขึ้นที่จะตอบว่างานหนึ่งควรไปขั้นใดต่อ

จุดเปลี่ยนที่มีประโยชน์กว่าการนับฟังก์ชันคือการระบุสถานะที่มีความหมายต่อธุรกิจ ลองแยกให้ได้ว่าคำขออยู่ระหว่างร่าง รออนุมัติ ขอข้อมูลเพิ่ม อนุมัติแล้ว หรือส่งแล้ว จากนั้นดูว่าทางเปลี่ยนใดต้องอยู่ต่อข้ามการเรียกแอป ถ้าคำตอบทั้งหมดเกิดและจบในโปรเซสเดียว เงื่อนไข Python อาจยังชัดที่สุด ถ้าแอปต้องกู้คืนตำแหน่งเหล่านั้น การกำหนดสถานะเป็นโครงสร้างจะช่วยให้เหตุผลของงานปรากฏในโค้ด

กราฟของ Pydantic เป็นทางเลือก แต่ persistence ต้องแยกดู

การเลือก Pydantic AI ไม่ได้ผูกทีมไว้กับเส้นทางแบบฟังก์ชันอย่างเดียว pydantic-graph ให้กำหนดโหนดและทางออกด้วย type hints เมื่อการแตกแขนงของงานควรเป็นกราฟ ในตัวอย่างคำขอคืนเงิน อาจแยกโหนดสร้างร่าง ตรวจความครบถ้วน ขอข้อมูลเพิ่ม และรอผลอนุมัติ ทำให้สถานะและทางเปลี่ยนเป็นส่วนที่มองเห็นได้แทนการซ่อนอยู่ในเงื่อนไขหลายฟังก์ชัน

อย่างไรก็ดี กราฟที่ระบุทางเดินได้กับกราฟที่กู้สถานะหลังหยุดโปรเซสเป็นคนละความสามารถ เอกสาร Graph Builder ของ Pydantic ระบุว่า API ของ pydantic-graph ใน V2 ไม่ทำ snapshot ของ graph state และแพ็กเกจ persistence เดิมถูกถอดออก หากต้องบันทึกและกลับมาทำต่อในระดับการรันของ agent เอกสารชี้ไปที่ StepPersistence ใน Harness ส่วนงานที่ต้องรอดจากการหยุดกลางขั้นต้องใช้ระบบ durable execution

ข้อแตกต่างนี้มีผลต่อการประเมินงานอนุมัติที่ค้างข้ามวัน ทีมอาจชอบรูปแบบโหนดของ pydantic-graph แต่ยังต้องกำหนดว่าจะบันทึกสถานะธุรกิจไว้ที่ใด จะเชื่อมการอนุมัติกับคำขอใด และจะกู้ขั้นที่หยุดอย่างไร การเห็นคำว่า graph ในชื่อเครื่องมือจึงยังไม่ใช่คำตอบครบสำหรับ pause และ resume

หากทีมใช้ Pydantic AI อยู่แล้ว ทางเลือกอาจเป็นการเก็บสถานะคำขอในฐานข้อมูลของแอป ใช้ pydantic-graph เพื่อทำทางเปลี่ยนให้ชัด และเพิ่มกลไก persistence ที่ตรงกับระดับงานจริง วิธีนี้เหมาะเมื่อข้อมูลธุรกิจและรอบการอนุมัติอยู่ภายใต้ระบบเดิมอยู่แล้ว แต่ภาระการเชื่อมสถานะเหล่านั้นยังเป็นงานออกแบบที่ต้องนับรวมในการเปรียบเทียบ

LangGraph ทำให้จุดหยุดและการกลับมาเป็นส่วนของการรัน

ในแบบที่รอเจ้าหน้าที่ LangGraph สามารถวางขั้นดึงข้อมูล สร้างร่าง ขออนุมัติ และส่งคำตอบเป็นโหนดของ StateGraph แล้วหยุดที่โหนดอนุมัติ เอกสาร interrupt ของ LangGraph ระบุว่าการหยุดต้องมี checkpointer และ thread ID เพื่อเก็บสถานะและชี้กลับไปยังงานเดิม ก่อนส่งคำตอบของคนกลับเข้าไปด้วย Command(resume=...)

สำหรับคำขอคืนเงิน thread ID ต้องผูกกับงานที่ถูกต้องอย่างคงที่ เมื่อเจ้าหน้าที่อนุมัติ ระบบจึงเรียกงานเดิมด้วยตัวระบุนั้นและส่งผลการอนุมัติกลับไป หากใช้ตัวระบุใหม่ จะกลายเป็นเส้นทางงานใหม่แทนการรับช่วงจาก checkpoint เดิม ส่วน checkpointer ที่เก็บเพียงในหน่วยความจำเหมาะกับตัวอย่างการทำงานมากกว่างานที่ต้องอยู่ต่อหลังโปรเซสหยุด

การกลับมาทำต่อมีรายละเอียดที่กระทบโค้ดในโหนดโดยตรง โหนดซึ่งเรียก interrupt จะเริ่มทำงานตั้งแต่ต้นโหนดอีกครั้งเมื่อ resume ดังนั้นการเปลี่ยนฐานข้อมูลหรือส่งข้อความที่เกิดก่อนจุดหยุดอาจเกิดซ้ำได้ งานตัวอย่างจึงควรแยกขั้นส่งข้อความออกจากขั้นรออนุมัติ และกำหนดวิธีป้องกันการส่งซ้ำด้วยข้อมูลของคำขอเอง

กราฟช่วยบอกว่าขณะนี้งานอยู่ตรงไหน แต่ยังต้องกำหนดความหมายของการอนุมัติให้ครบ หากเจ้าหน้าที่ปฏิเสธ ทางเดินควรกลับไปแก้ร่าง ปิดคำขอ หรือขอข้อมูลเพิ่มตามกฎของแอป ข้อมูลที่รับจากคนต้องถูกตรวจสิทธิ์และผูกกับร่างฉบับที่อนุมัติ การมี checkpoint ไม่ได้ตัดสินกฎธุรกิจเหล่านี้ให้แทนทีม

Retry และ validation แก้ปัญหาคนละช่วง

ระหว่างสร้างร่าง โมเดลอาจคืนผลลัพธ์ที่ขาดฟิลด์หรือเรียกเครื่องมือด้วยอาร์กิวเมนต์ผิด เอกสาร Agent ของ Pydantic AI อธิบายว่าข้อผิดพลาดจากการตรวจพารามิเตอร์ของ tool และผลลัพธ์แบบมีโครงสร้างส่งกลับให้โมเดลลองใหม่ได้ภายใต้งบ retry ที่กำหนด นี่คือการแก้ข้อผิดพลาดภายในการรันของ agent

การรอเจ้าหน้าที่หลายชั่วโมงเป็นปัญหาอีกแบบ ไม่มีเหตุผลให้โมเดลสร้างร่างซ้ำเพียงเพราะยังไม่มีคำอนุมัติ แอปต้องบันทึกว่างานหยุดตรงไหน เก็บข้อมูลที่คนต้องใช้ตัดสินใจ และเปิดทางให้ผลการตัดสินใจกลับเข้าสู่คำขอเดิม การเพิ่มจำนวน retry ของโมเดลไม่ทำให้สถานะงานคงอยู่หลังโปรเซสจบ

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

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

Benchmark ใช้จำกัดข้อสรุปเรื่องความเร็ว

งาน AgentRace ประเมินประสิทธิภาพของ framework หลายตัวรวมถึง PydanticAI และพบว่ารายละเอียดการติดตั้ง tool กับการออกแบบ prompt ส่งผลต่อผลลัพธ์อย่างมาก การทดลองด้านฮาร์ดแวร์ยังพบว่าเวลาในการรันบางกรณีเปลี่ยนไปตามเครื่องที่ใช้ ผลเช่นนี้เตือนว่าตัวเลขเวลาของ framework เป็นผลของทั้งชุดการติดตั้ง ไม่ใช่คุณสมบัติของชื่อ framework เพียงตัวเดียว

ชุดประเมินนั้นไม่ได้วัด LangGraph เป็นคู่เทียบโดยตรง จึงใช้ประกาศผู้ชนะระหว่างสองทางเลือกในบทความนี้ไม่ได้ อีกทั้งงาน benchmark ที่วัด agent ทำงานจนเสร็จไม่ได้แทนคำถามว่าสถานะอนุมัติค้างข้ามวันจะถูกเก็บและกู้คืนอย่างไร ประเด็นด้านสถาปัตยกรรมนี้ต้องดูจากลักษณะงานที่ต้องหยุดจริง

หากจะเปรียบเทียบการติดตั้งสำหรับงานคืนเงินแบบสมมติ ต้องให้ทั้งสองแบบใช้ข้อมูลคำขอ นโยบาย โมเดล เครื่องมือ และเงื่อนไขความสำเร็จที่ใกล้กัน แล้วแยกเวลาสร้างร่างออกจากเวลาที่รอคน ความเร็วที่ดูดีเพราะแบบหนึ่งข้ามขั้นอนุมัติไม่ใช่คำตอบว่าวิธีนั้นจัดการงานระยะยาวได้ดีกว่า

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

เลือกจากสิ่งที่ต้องคงอยู่หลังงานหยุด

เลือก Pydantic AI กับ Python ธรรมดาเมื่อ agent ทำงานเป็นช่วงสั้น ลำดับงานชัด เงื่อนไขแตกแขนงไม่มาก และผลลัพธ์ที่ต้องตรวจเป็นจุดเสี่ยงหลัก หากต่อมาทางเปลี่ยนซับซ้อนขึ้น pydantic-graph ช่วยแสดงสถานะในชุดเครื่องมือเดียวกันได้ แต่ควรประเมิน persistence ของงานแยกจากรูปแบบกราฟ

เลือกประเมิน LangGraph เมื่อการหยุดรอ การกลับมาด้วยงานเดิม และการติดตามสถานะระหว่างโหนดเป็นแกนของระบบ โดยเฉพาะเมื่อมีหลายทางอนุมัติหรือหลายขั้นที่อาจล้มเหลวแยกกัน ความคุ้มค่าของกราฟอยู่ที่ทำให้ทางเปลี่ยนและตำแหน่งที่บันทึกงานตรงกับพฤติกรรมจริงของระบบ ส่วนกฎอนุมัติ การตรวจข้อมูลภายนอก และการป้องกันการส่งซ้ำยังต้องออกแบบให้ครบ

อ่านเพิ่มเติม:

• Docker หรือ DigitalOcean: sandbox สำหรับ AI agent คิดเงินคนละจังหวะ
• LangChain หรือ LlamaIndex: งาน RAG ซับซ้อนกับงานค้นคืนเลือกคนละตัว