การเปลี่ยนจากการตอบเป็นการลงมือทำ
ในช่วงไม่กี่ปีที่ผ่านมา พวกเราส่วนใหญ่คงทำความสัมพันธ์กับโมเดลภาษาในลักษณะเดียวกับที่เรามีความสัมพันธ์กับเพื่อนร่วมงานที่อ่านหนังสือมามากเป็นพิเศษ คุณถามคำถาม คุณก็ได้คำตอบ และสิ่งที่เกิดขึ้นต่อจากนั้นก็ขึ้นอยู่กับคุณ วิธีการทำงานแบบนั้นกำลังถูกแทนที่อย่างเงียบๆ ปัญหาที่น่าสนใจในตอนนี้ไม่ใช่เรื่องทำให้โมเดลพูดสิ่งที่ถูกต้อง พวกเขาคือเรื่องทำให้ระบบทำสิ่งที่ถูกต้องในหลายขั้นตอน โดยใช้เครื่องมือที่เป็นของจริง ในสภาพแวดล้อมที่ยุ่งเหยิง ซึ่งโดยมากแผนแรกแทบจะไม่รอดการปะทะกับความเป็นจริง
นี่คือสิ่งที่วิศวกรรมเชิงเอเจนต์ (agentic engineering) เกี่ยวกับ มันเป็นวินัยของการออกแบบ สร้าง และปฏิบัติการระบบที่โมเดลไม่ได้เพียงแค่สร้างข้อความ แต่ลงมือทำ มองเห็นผลลัพธ์ และตัดสินใจว่าจะทำอะไรต่อจนกว่าจะบรรลุเป้าหมาย โมเดลยังคงเป็นศูนย์กลางของทุกอย่างอยู่ แต่ตอนนี้มันเป็นเพียงหนึ่งองค์ประกอบภายในเครื่องจักรที่ใหญ่กว่า และความยากที่แท้จริงจำนวนมากกลับอยู่ในทุกสิ่งที่อยู่รอบตัวมัน
การเปลี่ยนแปลงนี้มีความสำคัญเพราะทักษะต่างกัน การเขียนพรอมป์ตอบแทนด้วยความเฉียบคมของถ้อยคำ แต่วิศวกรรมเชิงเอเจนต์ตอบแทนสิ่งที่ทำให้ซอฟต์แวร์เชื่อถือได้เสมอมา: อินเทอร์เฟซที่ชัดเจน การสังเกตการณ์ที่ดี การจัดการความล้มเหลวอย่างเหมาะสม และลูปที่แน่นระหว่างสิ่งที่คุณส่งมอบกับสิ่งที่คุณได้เรียนรู้ ส่วนผสมใหม่เพียงอย่างเดียวที่เป็นเอกลักษณ์จริงๆ คือองค์ประกอบที่คาดเดาไม่ได้ ซึ่งนั่งอยู่ตรงกลางของทุกอย่าง
แท้จริงแล้วเอเจนต์คืออะไร
คำว่า agent ถูกขยายให้ครอบคลุมแทบทุกอย่าง ดังนั้นจึงควรให้ความหมายที่แม่นยำ เอเจนต์คือระบบที่แสวงหาเป้าหมายด้วยการเลือกการกระทำซ้ำๆ โดยอิงจากสิ่งที่มันสังเกต ไม่ใช่การทำตามสคริปต์ที่ตายตัว คุณสมบัติที่กำหนดชัดคือ “ลูป” ไม่ใช่ “ความฉลาด” เทอร์โมสตัททำตามกฎ เอเจนต์ตัดสินใจ
มันช่วยให้มอง “ความเป็นอิสระ” เป็นสเปกตรัม มากกว่าคำถามว่าใช่หรือไม่ใช่ ปลายด้านหนึ่งคือการเรียกโมเดลเพียงครั้งเดียวที่ทำหน้าที่จัดประเภทอีเมล อีกด้านถัดไปเล็กน้อยคือเวิร์กโฟลว์ที่เชื่อมสายการเรียกหลายครั้งเข้าด้วยกันตามลำดับที่ตายตัว ซึ่งมีประโยชน์แต่ยังเป็นแบบสคริปต์ ต่อไปอีกขั้น โมเดลจะเลือกว่าควรเรียกเครื่องมือใดและเมื่อใด และยังคงทำต่อจนกว่ามันจะประเมินว่าการงานเสร็จแล้ว ที่ปลายสุด ระบบจะตั้งเป้าหมายย่อยเอง จัดการหน่วยความจำของตัวเอง และรันเป็นเวลาหลายชั่วโมง ระบบผลิตจริงส่วนใหญ่ในวันนี้อยู่ตรงกลาง และโดยมากนั่นคือจุดที่เหมาะสม เพราะความเป็นอิสระเต็มรูปแบบมักไม่ใช่สิ่งที่โจทย์ต้องการจริงๆ
การตัดสินใจว่าระบบของคุณวางตัวอยู่บนสเปกตรัมนี้ตรงไหนเป็นหนึ่งในสิ่งที่ทำให้ความเข้าใจชัดขึ้นได้มากที่สุดตั้งแต่เนิ่นๆ มันบอกคุณว่าอยู่ในระดับไหนที่คุณสามารถพึ่งดุลยพินิจของโมเดลได้ ต้องใส่โครงสร้างมากแค่ไหน และความเสี่ยงจะไปรวมตัวกันตรงส่วนใด
ลูปของเอเจนต์
ลอกคราบชื่อกรอบงานและสื่อการตลาดออกไป แล้วเอเจนต์แทบทุกตัวจะใช้ลูปเดียวกัน มันรวบรวมบริบทเกี่ยวกับสถานการณ์ ใช้เหตุผลเกี่ยวกับสิ่งที่ควรทำ ลงมือทำการกระทำ และสังเกตว่ามีอะไรเกิดขึ้น จากนั้นมันก็วนกลับไปอีกครั้ง โดยใช้สิ่งที่เพิ่งเรียนรู้ จนกว่าเป้าหมายจะบรรลุหรือมันจะยอมแพ้
การวนผ่านลูปนี้แต่ละครั้งคือจุดตัดสินใจ และจุดตัดสินใจนี่แหละที่สิ่งต่างๆ ไปได้ดีหรือพังได้ จุดที่ดีของลูปเอเจนต์ไม่ใช่ลูปที่มีพรอมป์ฉลาดที่สุด แต่มันคือหนึ่งที่ในแต่ละช่วงมีข้อมูลเพียงพอที่จะตัดสินใจได้อย่างสมเหตุสมผลและไม่มากไปกว่านั้น ถ้าคุณให้ประวัติทั้งหมดของทุกสิ่งที่เกิดขึ้นแก่โมเดล มันก็จะทำให้สายเรื่องขาดตอน ถ้าคุณให้น้อยเกินไป มันก็จะทำงานแบบตาบอด งานฝีมือจำนวนมากอยู่ที่การตัดสินใจว่าโมเดลควรได้เห็นอะไรในแต่ละรอบ
ลูปยังอธิบายด้วยว่าทำไมการสร้างเอเจนต์ถึงให้ความรู้สึกแตกต่างจากซอฟต์แวร์ทั่วไปมาก ในโค้ดปกติ คุณสามารถใช้เหตุผลกับทุกเส้นทางได้ ที่นี่โมเดลสามารถเลือกเส้นทางที่คุณไม่เคยจินตนาการได้ กู้คืนจากความผิดพลาดในแบบที่คุณไม่ได้วางแผน หรือหลงออกไปในทิศทางที่ดูสมเหตุสมผลได้สามขั้น แล้วค่อยๆ พังทลาย คุณไม่ได้เขียนเส้นทางจริงๆ คุณกำลังปรับแต่ง “พื้นที่ของเส้นทางที่เป็นไปได้” และพยายามทำให้เส้นทางที่ดีๆ หาเจอได้ง่าย
องค์ประกอบของเอเจนต์
มันช่วยให้จินตนาการเอเจนต์เป็นชุดชิ้นส่วนเล็กๆ ที่แต่ละชิ้นทำหน้าที่อย่างใดอย่างหนึ่ง มีโมเดล ซึ่งเป็นผู้ให้เหตุผลและภาษา มีเครื่องมือ ซึ่งทำให้ระบบลงมือกับโลกได้และอ่านกลับมาจากโลกนั้น มีหน่วยความจำและบริบท ซึ่งพาข้อมูลที่เกี่ยวข้องเข้าไปยังการตัดสินใจแต่ละครั้ง และมีการประสานงานรอบๆ ทั้งหมด ซึ่งทำงานลูป บังคับใช้ขีดจำกัด และตัดสินใจว่าจะหยุดเมื่อใด
สิ่งที่โดดเด่นเมื่อคุณสร้างเอเจนต์พวกนี้มาสักจำนวนหนึ่งแล้ว คือแทบไม่มีงานหนักส่วนใดเกี่ยวกับ “ตัวโมเดล” โดยตรงเสียเท่าไรนัก โมเดลเป็นตัวเลือกที่ค่อนข้างคงที่ คุณเลือกมัน คุณป้อนพรอมป์ให้มัน แล้วก็ก้าวต่อไป ความพยายามด้านวิศวกรรมไปอยู่ในส่วนที่อยู่รอบๆ เครื่องมือที่ดี การจัดการบริบทที่ดี และการประสานงานที่ดีคือสิ่งที่แยกเดโมที่เวิร์กเพียงครั้งเดียวออกจากระบบที่คุณปล่อยให้รันต่อได้ ทีมที่มัวแต่ขัดถ้อยคำในพรอมป์แล้วละเลยส่วนเหล่านี้ มักจะสร้างสิ่งที่ดูน่าทึ่งในวันอังคาร และพังในวันศุกร์
เครื่องมือและบริบทคือพื้นผิวที่แท้จริง
ถ้าลูปคือโครงกระดูก เครื่องมือและบริบทคือที่ซึ่งวิศวกรรมเกิดขึ้นจริง
เครื่องมือคือ “มือ” ของโมเดล มันคือวิธีที่เอเจนต์อ่านฐานข้อมูล ส่งข้อความ รันคำสั่งค้น หรือเคลื่อนย้ายไฟล์ คุณภาพของเครื่องมือของคุณเป็นตัวกำหนดเพดานสูงสุดแบบชัดเจนว่เอเจนต์ทำอะไรได้ และการออกแบบเครื่องมือกลับกลายเป็นงานฝีมือในแบบของมันเอง เครื่องมือที่ดีทำสิ่งเดียวที่ชัดเจน มีชื่อและคำอธิบายที่บอกโมเดลได้อย่างแม่นยำว่าควรหยิบมาใช้เมื่อใด ตรวจสอบอินพุตของมัน และส่งผลลัพธ์ที่ทำให้ลงมือทำต่อได้ง่าย เครื่องมือที่คลุมเครือพร้อมคำอธิบายกำกวม แย่ยิ่งกว่าไม่มีเครื่องมือเลย เพราะโมเดลจะใช้มันอย่างมั่นใจและใช้ผิด ความใส่ใจที่คุณจะใส่ในการออกแบบอินเทอร์เฟซสำหรับเพื่อนร่วมงานที่มีความสามารถแต่เป็นคนใหม่โดยประมาณ ก็คือความใส่ใจที่เครื่องมือนั้นสมควรได้รับ เพราะโดยประมาณนี่คือสถานการณ์เดียวกัน
บริบทคืออีกครึ่งหนึ่ง โมเดลรู้เพียงสิ่งที่ถูกวางไว้ตรงหน้า ดังนั้นในทุกครั้งที่วนรอบ คุณกำลังตอบคำถามเงียบๆ: ตอนนี้โมเดลจำเป็นต้องเห็นอะไร เพื่อที่จะเลือกได้ดี นี่คือที่มาของคำว่า context engineering และมันได้กลายเป็นหนึ่งในปัญหาหลักของสาขานี้ แนวทางแบบง่ายๆ คือยัดสิ่งต่างๆ เข้าไปในหน้าต่างให้มากขึ้น ประวัติมากขึ้น เอกสารมากขึ้น คำสั่งมากขึ้น แต่มันไม่สเกล ความสนใจจะถูกเจือจาง ต้นทุนสูงขึ้น และโมเดลเริ่มพลาดสิ่งที่สำคัญจริงๆ แนวทางที่ดีกว่า คือมองบริบทเป็นงบประมาณที่ต้องใช้ “ตามจุดประสงค์” คุณดึงเฉพาะสิ่งที่เกี่ยวข้อง สรุปสิ่งที่เก่าแล้ว ทิ้งสิ่งที่ทำเสร็จแล้ว และทำให้ชุดงานที่กำลังทำอยู่เล็ก
