เอเจนต์มีประโยชน์เพราะช่วยให้เราทำงานอัตโนมัติโดยการดำเนินการในโลกจริง แต่การทำให้เอเจนต์ทำงานที่มีคุณค่าได้อย่างน่าเชื่อถือนั้นต้องการมากกว่าแค่โมเดลที่ดี: มันต้องมีฮาร์เนสที่ออกแบบอย่างรอบคอบซึ่งเหมาะกับชุดงาน
อัลกอริทึมหลักของเอเจนต์นั้นง่าย: ให้บริบทแก่ LLM แล้วปล่อยให้มันเรียกใช้เครื่องมือในลูปจนกว่าจะเสร็จ นี่คือลูปพื้นฐานที่สุด แต่มันไม่ใช่ลูปเดียวที่ขับเคลื่อนเอเจนต์ @swyx เพิ่งเขียนบทความที่ยอดเยี่ยมเกี่ยวกับ "loopcraft: ศิลปะแห่งการซ้อนลูป" แนวคิดที่ว่าคุณสามารถซ้อนและขยายลูปเพื่อสร้างเอเจนต์ที่มีประสิทธิภาพมากขึ้น
นี่คือวิธีที่เราคิดเกี่ยวกับสแต็กนั้น และวิธีติดตั้งเครื่องมือในแต่ละระดับด้วย LangChain primitives
ลูป 1: เอเจนต์
โดยแก่นแล้ว เอเจนต์ก็แค่โมเดลที่เรียกใช้เครื่องมือในลูปจนกว่างานจะเสร็จ

นี่คือสิ่งที่ LangChain's create_agent มอบให้ เลือกโมเดลใดก็ได้ เสียบเครื่องมือ แล้วคุณจะได้ลูปเอเจนต์ที่ทำงานได้ เครื่องมือคือสิ่งที่ทำให้เอเจนต์มีพลังในการดำเนินการในโลกจริง
ยกตัวอย่างเอเจนต์เอกสารภายในของเรา (ซึ่งเราจะใช้เป็นตัวอย่างกระตุ้นสำหรับส่วนที่เหลือของบล็อกนี้) ในระดับลูปแรก มันได้รับคำขอให้ปรับปรุงเอกสาร โมเดลวางแผนและร่างการเปลี่ยนแปลง และใช้เครื่องมือเพื่อโคลน repos อ่านไฟล์ เขียนเอกสาร เปิด pull request ฯลฯ

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

ลูปการตรวจสอบเพิ่มตัวให้คะแนน: สิ่งที่ตรวจสอบผลลัพธ์ของเอเจนต์กับเกณฑ์การให้คะแนน และหากล้มเหลว ก็ส่งผลลัพธ์กลับไปพร้อมคำติชม ตัวให้คะแนนสามารถเป็นได้ทั้งแบบกำหนดตายตัวหรือแบบเอเจนต์ (LLM ในฐานะผู้ตัดสินเป็นตัวอย่างคลาสสิกในที่นี้)
RubricMiddleware จัดการรูปแบบนี้ หรือคุณสามารถเชื่อมต่อมันด้วย after_agent hook บน create_agent
สำหรับตัวอย่างนักเขียนเอกสารของเรา ตัวให้คะแนนจะรันการทดสอบหลังจากแต่ละครั้ง โดยตรวจสอบว่าลิงก์ทั้งหมดใช้งานได้ การตรวจ CI ทั้งหมดผ่าน และ diff อยู่ในขอบเขตของสิ่งที่ถูกร้องขอจริง ไม่จำเป็นต้องตรวจสอบด้วยตนเองเพื่อจับข้อผิดพลาดประเภทนั้น

ข้อแลกเปลี่ยนหนึ่ง: การเพิ่มการตรวจสอบจะเพิ่มเวลาแฝงและต้นทุนต่อการรัน มันคุ้มค่าเมื่อคุณภาพสำคัญกว่าความเร็ว ซึ่งเป็นกรณีการใช้งานใน production ส่วนใหญ่
ระดับ 3: ลูปที่ขับเคลื่อนด้วยเหตุการณ์
ส่วนที่สำคัญที่สุดส่วนหนึ่งของการพัฒนาเอเจนต์คือเลเยอร์การบูรณาการ: การเชื่อมต่อเอเจนต์ของคุณกับระบบนิเวศของคุณ เพื่อให้มันสามารถทำงานในเบื้องหลังได้
ลูปที่ขับเคลื่อนด้วยเหตุการณ์เชื่อมต่อเอเจนต์ของคุณกับระบบนิเวศของคุณ เหตุการณ์ถูกกระตุ้น — เอกสารใหม่มาถึง, ตารางเวลาถูกเรียก, webhook มาถึง — และเอเจนต์ก็ทำงาน เอเจนต์ไม่ใช่สิ่งที่คุณเรียกใช้ด้วยตนเอง มันเป็นคอมโพเนนต์ที่ทำงานอย่างต่อเนื่องภายในระบบที่ใหญ่กว่า

LangSmith Deployment รองรับโครงสร้างพื้นฐานทริกเกอร์ รวมถึงการรองรับ cron schedules และ webhooks ตัวอย่างยอดนิยมของ crons ในการทำงานคือ "heartbeats" ใน openclaw ซึ่งเปลี่ยนเอเจนต์ของคุณให้เป็นผู้ช่วยที่ทำงานตลอดเวลาและเชิงรุก
เอเจนต์เอกสารของเราขับเคลื่อนโดย Fleet เครื่องมือสร้างเอเจนต์แบบไม่ต้องเขียนโค้ดของเรา channels และ schedules ของ Fleet จัดการทริกเกอร์แบบ event-driven และ cron-style เราใช้ channel เพื่อเรียกใช้เอเจนต์เอกสารทุกครั้งที่มีข้อความถูกส่งใน Slack channel #docs-plz ของเรา

ระดับ 4: ลูปการปีนเขา
สามลูปแรกทำให้งานเป็นอัตโนมัติ ลูปที่สี่ (และอาจสำคัญที่สุด) ทำให้การปรับปรุงเป็นอัตโนมัติ!

ทุกครั้งที่รันเอเจนต์จะสร้าง trace: บันทึกว่าโมเดลทำอะไร เรียกใช้เครื่องมืออะไร คำติชมจาก grader ฯลฯ trace เหล่านั้นประกอบด้วยสัญญาณที่มีค่าสูงเกี่ยวกับสิ่งที่ใช้ได้และสิ่งที่ไม่ได้ผล ลูปการปีนเขาจะรัน analysis agent เหนือ trace เหล่านั้นและใช้สิ่งที่ค้นพบเพื่อเขียนฮาร์เนสใหม่ด้วยการกำหนดค่าที่ดีขึ้น ซึ่งอาจรวมถึงการปรับแต่ง prompt/เครื่องมือ หรือการปรับแต่ง grader
ใน LangSmith คุณสามารถใช้ Engine analysis agent trace ของเรา เพื่อติดตั้งเครื่องมือสำหรับลูปที่สี่นี้
สรุปการเปรียบเทียบเอเจนต์เอกสาร เราใช้ Engine กับ traces ของเอเจนต์เอกสารเพื่อตรวจจับปัญหาใดๆ เมื่อ traces หลายตัวส่งสัญญาณถึงปัญหาที่อาจเกิดขึ้น ปัญหาจะถูกยื่นเพื่อขอเปลี่ยนแปลง prompt หรือเครื่องมือที่ผิด

การเคลื่อนไหวสำคัญคือลูกศรกลับไม่ได้แค่วงกลับไปด้านบน — มันเข้าถึงภายในและอัปเดตลูปเอเจนต์โดยตรง แต่ละรอบของลูปภายนอกทำให้ลูปภายในมีประสิทธิภาพมากขึ้น
มองไปข้างหน้า:
การกำหนดค่า prompt และเครื่องมือเป็นสิ่งที่ง่ายที่สุดในการปรับปรุง แต่มันไม่ใช่ตัวเลือกเดียว สำหรับทีมที่รันโมเดล open-weight ลูปการปีนเขาสามารถป้อนเข้าสู่ RL fine-tuning โดยใช้ผลลัพธ์จาก trace หรือ eval เป็นสัญญาณฝึกอบรมเพื่อปรับปรุงโมเดลเอง บริบทเสริม เช่น หน่วยความจำและทักษะที่เรียกคืนสามารถปรับปรุงได้ในลักษณะเดียวกัน ลูปคือรูปแบบ; สิ่งที่มันปรับให้เหมาะสมนั้นขึ้นอยู่กับคุณ
การดูแลและความเชี่ยวชาญของมนุษย์
ระบบอัตโนมัติไม่ได้หมายถึงการเอาคนออกจากลูป ในทุกระดับ มีจุดที่เป็นธรรมชาติที่การดูแลของมนุษย์เพิ่มมูลค่า ตัวให้คะแนนอัตโนมัติสามารถตรวจสอบว่าลิงก์ใช้งานได้หรือไม่; ต้องใช้มนุษย์เพื่อสังเกตว่าการนำเสนอนั้นผิดสำหรับผู้ชม การตัดสินแบบนั้น ซึ่งได้มาจากบริบท ประสบการณ์ และรสนิยม คือสิ่งที่การตรวจสอบของมนุษย์มีที่ทางอย่างแท้จริง
ความเชี่ยวชาญบางอย่างควรถูกบันทึกไว้ใน prompt/เครื่องมือตัวเอง แต่สำหรับการกระทำที่ละเอียดอ่อน การตรวจสอบโดยมนุษย์แบบสดเป็นสิ่งจำเป็น (คิดถึงธุรกรรมทางการเงิน การดำเนินการ DB ฯลฯ) LangChain ทำให้การติดตั้งจุดสัมผัสเหล่านี้ในทุกลูปเป็นเรื่องตรงไปตรงมา:
- ในลูปเอเจนต์ ต้องมีอินพุตของมนุษย์ก่อนการกระทำ/การเรียกเครื่องมือที่ละเอียดอ่อน
- ในลูปการตรวจสอบ มนุษย์สามารถทำหน้าที่เป็น grader สำหรับ workflows ที่ละเอียดอ่อน
- ในลูปแอปพลิเคชัน มนุษย์สามารถอนุมัติผลลัพธ์ก่อนที่จะส่งกลับไปยังผู้ใช้ปลายทาง
- ในลูปการปีนเขา การปรับปรุงฮาร์เนสสามารถผ่านการตรวจสอบของมนุษย์ก่อนการปรับใช้
เฟรมเวิร์กโอเพนซอร์สทั้งหมดของ LangChain ทำให้การเพิ่ม "มนุษย์ในลูป" เป็น first class primitive
รวบรวมทุกอย่างเข้าด้วยกัน
ในกรณีที่คุณต้องการมุมมองแบบตารางมากขึ้น นี่คือวิธีที่สี่ลูปนั้นซ้อนกัน:
นี่คือลักษณะที่ loop engineering — หรือ loopcraft ตามที่ @swyx กล่าว — ดูในทางปฏิบัติจริง ผู้นำด้าน AI เช่น Steipete, Boris, และ Andrej ต่างก็ได้ข้อสรุปเดียวกัน: ศักยภาพของเอเจนต์อยู่ในลูปที่คุณสร้างรอบตัวพวกมัน
เราคิดเกี่ยวกับลูป 1 และ 2 มาระยะหนึ่งแล้ว แต่ควรมุ่งเน้นไปที่ลูป 3 และ 4 ซึ่งมูลค่าทวีคูณโดยการฝังเอเจนต์เข้าไปในระบบนิเวศของคุณที่ปรับปรุงอย่างต่อเนื่องตามเกณฑ์ของคุณ
Satya กำหนดกรอบความเสี่ยงขององค์กร: บริษัทที่สร้าง learning loops ตั้งแต่เนิ่นๆ ที่ซึ่งการตัดสินของมนุษย์และ token capital ทวีคูณร่วมกัน จะสร้างความได้เปรียบที่ยากจะเลียนแบบ
กิตติกรรมประกาศ
ขอบคุณ @Vtrivedy10, @masondrxy, @hwchase17, และ @huntlovell สำหรับการตรวจสอบอย่างรอบคอบ





