Context Engineering: 4 กลไกแก้ปัญหาบริบทเต็มและเป้าหมายหลุด
เจาะลึก 4 กลไกจัดการ Context ใน LangChain, Claude Code, Manus และ AWS เพื่อแก้ปัญหาความจำล้นและเป้าหมายหลุดในงานระยะยาว
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- งานเอเจนต์ทั่วไปต้องใช้การเรียกใช้งานเครื่องมือถึง 50 ครั้งต่อภารกิจ โดยมีอัตราส่วนโทเค็นอินพุตต่อเอาต์พุตราว 100:1
- Deep Agents ตั้งกฎลดภาระด้วยการเขียนไฟล์ลงดิสก์เมื่อการตอบสนองเกิน 20,000 โทเค็น
- Claude Code จำกัดหน่วยความจำอัตโนมัติไว้ที่ 200 บรรทัดแรกหรือ 25KB พร้อมเลื่อนการโหลดสีมาจนกว่าจะเรียกใช้งาน
- Amazon Bedrock AgentCore ใช้โคออร์ดิเนเตอร์กระจายงานให้เบราว์เซอร์ซับเอเจนต์ทำงานขนานกัน 3 ตัวใน MicroVM
บทความนี้พาไปสำรวจเบื้องหลังการทำงานของระบบเอเจนต์ปัญญาประดิษฐ์รุ่นใหม่ ซึ่งประกอบด้วยกลไกการบีบอัดข้อมูล กลยุทธ์หน่วยความจำ การจัดสรรงบประมาณบริบท และสถานะรายการสิ่งที่ต้องทำ โดยมีเครื่องมือชั้นนำอย่าง LangChain Deep Agents, Claude Code, Manus, OpenAI Codex และ Amazon Bedrock AgentCore เป็นกรณีศึกษาในการจัดการภาระงานระยะยาว
สำหรับวงรอบการทำงานของเอเจนต์แล้ว ปัญหาความจำล้นถือเป็นเรื่องท้าทายอย่างมาก โดยทาง Manus รายงานว่าภารกิจทั่วไปต้องเรียกใช้เครื่องมือประมาณ 50 ครั้ง และมีอัตราส่วนโทเค็นอินพุตต่อเอาต์พุตอยู่ที่ราว 100:1 ข้อมูลจากการสังเกตการณ์ทุกรายการจะถูกสะสมไว้ในหน้าต่างบริบท ทำให้คำสั่งเริ่มต้นถูกดันไปอยู่ตรงกลาง ซึ่งเป็นจุดที่ประสิทธิภาพการเรียกคืนข้อมูลลดลงอย่างเห็นได้ชัด การสูญเสียเป้าหมายจึงไม่ใช่แค่บั๊กของโมเดล แต่เป็นผลลัพธ์ที่พบได้ทั่วไปเมื่อปล่อยให้หน้าต่างบริบทไร้การควบคุมในงานที่มีความยาวต่อเนื่อง
งานแรกของระบบควบคุมคือการตัดสินใจว่าข้อมูลส่วนใดไม่ควรถูกนำเข้าสู่หน้าต่างบริบทตั้งแต่แรก โดย Deep Agents กำหนดกฎการถ่ายโอนข้อมูลออกภายนอกด้วยตัวเลขที่ชัดเจน เมื่อผลลัพธ์จากเครื่องมือเกิน 20,000 โทเค็น ข้อมูลจะถูกบันทึกรูปลงในระบบไฟล์และแทนที่ด้วยเส้นทางไฟล์พร้อมตัวอย่าง 10 บรรทัดแรก และเมื่อบริบทของเซสชันแตะระดับ 85% ของหน้าต่างโมเดล การเรียกใช้เครื่องมือเขียนและแก้ไขรุ่นเก่าๆ จะถูกตัดทอนให้เหลือเพียงพอยเตอร์
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ในฝั่งของ Claude Code ใช้การจัดสรรงบประมาณในลักษณะเดียวกันกับข้อมูลที่โหลดก่อนพรอมต์แรก หน่วยความจำอัตโนมัติถูกจำกัดไว้ที่ 200 บรรทัดแรกหรือ 25KB สถาปัตยกรรมซับเอเจนต์ของ Anthropic แสดงให้เห็นถึงประสิทธิภาพของการจัดการนี้ โดยซับเอเจนต์แต่ละตัวอาจเผาผลาญโทเค็นนับหมื่นในการสำรวจ แต่จะส่งคืนเฉพาะสรุปที่กลั่นกรองแล้วราว 1,000 ถึง 2,000 โทเค็นเท่านั้น ขณะที่ระบบของ AWS AgentCore สามารถประสานงานให้เบราว์เซอร์ซับเอเจนต์ 3 ตัวทำงานแบบคู่ขนานใน MicroVM แยกกันได้
เมื่อการถ่ายโอนข้อมูลออกภายนอกยังไม่เพียงพอ ระบบควบคุมจะหันมาใช้กระบวนการบีบอัดข้อมูล ซึ่งเป็นการสรุปบทสนทนาที่กำลังจะเต็มขีดจำกัดหน้าต่างและเริ่มบริบทใหม่ด้วยข้อมูลสรุปนั้น การดำเนินการนี้มีความเสี่ยงที่ข้อมูลสรุปแบบสูญเสียรายละเอียดจะทำให้ข้อจำกัดสำคัญหลุดหายไป แต่อุปกรณ์แต่ละตัวก็มีแนวทางรับมือที่แตกต่างกัน เช่น Claude Code ที่ช่วยรักษาการตัดสินใจทางสถาปัตยกรรมและบั๊กที่ยังไม่ถูกแก้ไขไว้
การทำ Context Engineering ในเอเจนต์ยุคใหม่สะท้อนให้เห็นว่า หน้าต่างบริบท (Context Window) ไม่ใช่พื้นที่เก็บข้อมูลแบบถาวร แต่เป็นทรัพยากรที่มีต้นทุนสูง การออกแบบระบบจึงต้องมองข้ามแค่ความสามารถของ LLM ไปสู่การสร้างโครงสร้างพื้นฐานภายนอก เช่น การใช้ระบบไฟล์ การทำซับเอเจนต์ และการเก็บบันทึกสถานะแยกต่างหาก เพื่อให้เอเจนต์สามารถทำงานต่อเนื่องหลายชั่วโมงโดยไม่สูญเสียทิศทาง
ด้าน OpenAI ได้นำการบีบอัดข้อมูลเข้าสู่ชั้น API ด้วยเช่นกัน โดยResponses API มีระบบบีบอัดฝั่งเซิร์ฟเวอร์ผ่าน parameter context_management ควบคู่กับจุดเชื่อมต่อ /responses/compact ที่ส่งคืนหน้าต่างบริบทแบบเข้ารหัส ขณะที่ในส่วนของสถานะรายการสิ่งที่ต้องทำ (todo-state) มีผลการประเมินที่หลากหลาย โดย Deep Agents เคยใช้เครื่องมือ write_todos เป็นค่าเริ่มต้นจนถึงเดือนกรกฎาคม 2026 ก่อนจะปรับให้เป็นแบบเลือกเปิดใช้งานภายหลังจากการประเมินพบว่าต้นทุนลดลงเมื่อปิดการใช้งานในบางประเภทงาน
โดยสรุปแล้ว รูปแบบเบื้องหลังกลไกเหล่านี้คือการทำให้เป้าหมายดำรงอยู่เป็นวัตถุที่สามารถปรับเปลี่ยนได้ แทนที่จะเป็นเพียงข้อความในประวัติการสนทนา ข้อความทั่วไปจะเสื่อมสภาพและถูกย่อสรุป แต่ไฟล์ที่ถูกเขียนทับทุกๆ ไม่กี่รอบการทำงานจะมีขนาดสั้นและคงอยู่เสมอไม่ว่าจะผ่านการรีเซ็ตระบบกี่ครั้งก็ตาม
ที่มา: MarkTechPost
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น