วิศวกรรมบริบทสำหรับเอเจนต์ AI ที่ทำงานระยะยาว

เมื่อมองรวมกัน การวิเคราะห์ ของ Arize, งานวิจัย arXiv เรื่อง context window overflow, คำอธิบายสำหรับการใช้งานจริง ของ Redis และการเปรียบเทียบด้านวิศวกรรมฮาร์เนส ของ Atlan ชี้ไปสู่การเปลี่ยนแปลงเชิงปฏิบัติในการออกแบบเอเจนต์ เอเจนต์ที่ทำงานต่อเนื่องถูกตัดสินจากขนาดหน้าต่างบริบทของโมเดลน้อยลง และถูกตัดสินจากเลเยอร์ควบคุมรอบ ๆ หน้าต่างนั้นมากขึ้น Arize ทำให้การเปลี่ยนแปลงนี้จับต้องได้ โดยระบุชื่อเครื่องมือเอเจนต์และระบบหน่วยความจำ/ฮาร์เนสที่เปิดใช้งานแล้ว เช่น Pi, OpenClaw, Claude Code และ Letta เป็นตัวอย่างของ context engineering ระดับฮาร์เนส และอธิบายซิมูเลเตอร์แบบอินเทอร์แอ็กทีฟที่แสดงให้เห็นว่าหน้าต่าง 200K token ถูกเติมจนเต็มอย่างไร

รายละเอียดสาธารณะที่มีอยู่ในแหล่งอ้างอิงเหล่านี้ไม่สม่ำเสมอ Arize ให้ตัวเลขการใช้งานจริงสำหรับ Pi, OpenClaw, Claude Code และ Letta งานวิจัยเรื่องการแก้ปัญหา context window overflow ในเอเจนต์ AI ให้กลไกที่ทั่วไปกว่าในการจัดการผลลัพธ์จากเครื่องมือที่อาจเกินหน้าต่างใด ๆ ที่ใช้งานได้จริง คำอธิบายของ Redis เรื่อง context window overflow สรุปอาการในการผลิตจริง ได้แก่ ข้อผิดพลาด API แบบแข็ง คุณภาพที่ลดลงแบบเงียบ ๆ การสะสมผลลัพธ์จากเครื่องมือ และ latency ที่ยาวขึ้นเมื่อ prompt โตขึ้น การเปรียบเทียบของ Atlan เรื่อง prompt, context และ harness engineering ให้คำเปรียบเทียบแบบสแต็กที่มีประโยชน์: prompt engineering กำหนดรูปแบบข้อความ, context engineering กำหนดสิ่งที่โมเดลเห็น และ harness engineering กำหนดสภาพแวดล้อมทั้งหมดของเอเจนต์

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

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

วิธีอ่านชุดข้อจำกัดแรกที่ชัดเจนกว่าคือ:

• Pi: การอ่านไฟล์หยุดที่ 2,000 บรรทัดหรือ 50KB แล้วแต่ว่าอะไรถึงก่อน เนื้อหาที่ส่งกลับมีคำใบ้สำหรับการอ่านต่อ โดยบอกโมเดลว่าช่วงบรรทัดใดถูกแสดงไปแล้ว และจะอ่านต่อด้วย offset และ limit ได้อย่างไร OpenClaw สืบทอดพฤติกรรมนั้น แล้วเพิ่มเพดานแยกต่างหาก: ไฟล์ bootstrap ถูกจำกัดไว้ที่ 12,000 อักขระต่อไฟล์ และรวมทั้งหมด 60,000 อักขระ ผลลัพธ์จากเครื่องมือมีงบประมาณอีกชุดหนึ่งที่ 16,000 อักขระหรือ 30% ของหน้าต่างบริบท แล้วแต่ว่าอะไรน้อยกว่า

Claude Code ใช้การออกแบบแบบสองด่าน ตามข้อมูลจาก Arize ระบบตรวจเพดานไบต์ที่ 256KB ก่อนเปิดไฟล์ จากนั้นนับ token ของผลลัพธ์เทียบกับงบประมาณ 25,000 token หลังการอ่าน แม้แต่ไฟล์ที่ต่ำกว่าเพดาน ระบบตั้งค่าเริ่มต้นให้ส่งคืน 2,000 บรรทัดจากจุดเริ่มต้น และตัดบรรทัดที่ยาวกว่า 2,000 อักขระ หากโมเดลอ่านช่วงไฟล์เดิมซ้ำและไฟล์ไม่ได้เปลี่ยน Claude Code สามารถส่งคืน stub แทนการทำซ้ำเนื้อหาทั้งหมดได้

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

รูปแบบถัดมาคือการปฏิบัติกับบริบทเหมือน viewport ไม่ใช่ที่เก็บข้อมูล

Pi และ Claude Code เปิดใช้ pagination ผ่าน offset และ limit OpenClaw เพิ่มการตัดแบบ head/tail ในบางจุด โดยเก็บส่วนต้นและส่วนท้ายไว้เมื่อส่วนกลางมีแนวโน้มสำคัญน้อยกว่า Arize ระบุว่า OpenClaw ใช้สัดส่วนส่วนต้น 75% / ส่วนท้าย 25% สำหรับไฟล์ bootstrap ที่ใหญ่เกินไป และอาจเก็บทั้งส่วนต้นและส่วนท้ายสำหรับผลลัพธ์จากเครื่องมือเมื่อส่วนท้ายดูสำคัญ เช่น ข้อผิดพลาด วงเล็บปีกกาปิดของ JSON หรือคีย์เวิร์ดที่ดูเหมือนสรุป

Letta ไปไกลกว่านั้นด้วยการทำให้ไฟล์อยู่นอก prompt ไฟล์ที่อัปโหลดจะถูก parse, chunk และ embed เข้าไปใน vector store ทำให้เอเจนต์สามารถดูโดยตรง ค้นหาแบบตรงตัว และค้นหาเชิงความหมายได้ เมื่อไฟล์เปิดอยู่ในบริบท Letta จะแสดงมุมมองที่จัดการได้ ซึ่งขนาดปรับตามบริบทของโมเดล: 5,000 อักขระสำหรับบริบท 8K, 15,000 สำหรับ 32K, 25,000 สำหรับ 128K และ 40,000 สำหรับ 200K+ จำนวนไฟล์ที่เปิดพร้อมกันก็ปรับตามเช่นกัน ตั้งแต่ 3 ไฟล์สำหรับโมเดลขนาดเล็ก ไปจนถึง 15 ไฟล์สำหรับโมเดลขนาดใหญ่มาก โดยใช้นโยบาย LRU เพื่อขับไฟล์ที่เข้าถึงนานที่สุดออก

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

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

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

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

Arize รายงานว่า Pi เริ่มบีบอัดเมื่อ token บริบทโดยประมาณเกินหน้าต่างบริบทลบด้วย token สำรอง โดยค่าเริ่มต้นสำรองไว้ 16,384 token ระบบเก็บประมาณ 20,000 token ล่าสุด และสรุปเนื้อหาเก่ากว่าเป็นข้อความผู้ใช้สังเคราะห์ที่ถูกเติมไว้หน้าส่วนท้ายที่เก็บไว้ นอกจากนี้ยังหลีกเลี่ยงการตัดกลางคู่ tool-call/tool-result

OpenClaw เพิ่มนโยบายประวัติที่ก้าวร้าวกว่า เมื่อประวัติเกิน 50% ของหน้าต่างบริบท ระบบจะแบ่งข้อความเป็น chunk ที่มีมวล token เท่า ๆ กัน ทิ้ง chunk ที่เก่าที่สุด สรุปเนื้อหาที่ถูกทิ้งผ่านการสรุปหลายรอบแบบเป็นขั้นตอน และซ่อมการจับคู่ tool-call/result นอกจากนี้ยังทำ pre-compaction flush: เทิร์นแบบ agentic ที่เงียบจะให้โอกาสเอเจนต์บันทึกสถานะลงไฟล์หน่วยความจำก่อนที่ประวัติจะหายไป แยกต่างหาก ระบบยัง prune ผลลัพธ์จากเครื่องมือในหน่วยความจำด้วยพฤติกรรม soft-trim และ hard-clear บน cache TTL 5 นาที

Claude Code บีบอัดใกล้จุดสิ้นสุดของหน้าต่าง Arize ระบุว่า trigger ของระบบคือหน้าต่างบริบทที่มีผลลบด้วยบัฟเฟอร์ 13,000 token ซึ่งทำให้การบีบอัดเกิดราว 167K token สำหรับโมเดลบริบท 200K prompt สำหรับการสรุปของระบบขอส่วนที่มีโครงสร้าง ครอบคลุมคำขอหลัก แนวคิดทางเทคนิค ไฟล์และโค้ด ข้อผิดพลาดและการแก้ไข การแก้ปัญหา ข้อความของผู้ใช้ งานค้าง งานปัจจุบัน และขั้นตอนถัดไป หลังการบีบอัด ระบบสามารถแนบไฟล์ที่เพิ่งอ่านล่าสุดได้สูงสุด 5 ไฟล์ภายในงบประมาณ token

รูปแบบนั้นชัดเจน: การบีบอัดไม่ใช่ “สรุปแชต” แต่มันคือการทำ checkpoint เอเจนต์ที่ทำงานต่อเนื่องต้องมีสิ่งเทียบเท่า save file: เป้าหมาย ข้อจำกัด การตัดสินใจ handle ที่เปิดอยู่ หลักฐานล่าสุด และการกระทำถัดไป

ผลลัพธ์บางอย่างไม่ควรถูกวางไว้ในหน้าต่างบริบทเลย

งานวิจัย arXiv ทำให้เรื่องนี้เป็นรูปธรรมด้วย workflow ด้านวัสดุศาสตร์ เครื่องมือหนึ่งสร้างโครงสร้างกริดอิเล็กทรอนิกส์สำหรับโมเลกุล: เมทริกซ์ 3D ขนาด 128 × 128 × 128 รวมทั้งหมด 2,097,152 องค์ประกอบ float32 ผลลัพธ์นั้นเกินหน้าต่างบริบทของ LLM ที่ใช้กันแพร่หลายไปมาก แต่เครื่องมือถัดไปต้องใช้กริดเป็นอินพุต

โซลูชันที่เสนอคือเก็บค่าขนาดใหญ่ไว้นอกบริบทของโมเดล และส่งคืนตัวระบุสั้น ๆ หรือพอยน์เตอร์ wrapper ของเครื่องมือจะตรวจอินพุตเพื่อดูว่าเป็นค่าดิบหรือ path ในหน่วยความจำ ผลลัพธ์ที่ใหญ่เกินไปจะถูกเก็บไว้ใน runtime memory ภายใต้ path และเครื่องมือภายหลังสามารถรับพอยน์เตอร์แล้ว resolve ภายในได้ โมเดลจัดการ reference ขณะที่ฮาร์เนสรักษาข้อมูลเต็มไว้ ในการทดลองเปรียบเทียบหนึ่งที่ทั้งสองวิธีสำเร็จ วิธีที่ใช้พอยน์เตอร์ใช้ token น้อยกว่าวิธีดั้งเดิมประมาณเจ็ดเท่า ตามข้อมูลในงานวิจัย

นี่คือการแยก reasoning ออกจาก data transport ที่สะอาดที่สุด โมเดลไม่จำเป็นต้อง “เห็น” เมทริกซ์ 2 ล้านองค์ประกอบเพื่อส่งต่อให้เครื่องมืออีกตัว มันต้องรู้ว่าเมทริกซ์นั้นมีอยู่ แทนอะไร และการดำเนินการใดควรใช้มันต่อไป

ตรรกะเดียวกันใช้ได้เกินกว่าอาร์เรย์ทางวิทยาศาสตร์ คำตอบ JSON ขนาดใหญ่, PDF, log, embedding, ไฟล์มีเดีย และ export จากฐานข้อมูลมักควรอยู่ใน storage ไม่ใช่ใน prompt สำหรับระบบที่สร้างรอบเครื่องมือ MCP หรือ connector API แบบกำหนดเอง การส่งผ่านพอยน์เตอร์ควรเป็นตัวเลือกการออกแบบระดับแรก ไม่ใช่แพตช์หลังเกิด overflow ครั้งแรก

หน้าต่างบริบท 200K-token ดูใหญ่จนกว่าเอเจนต์จะเริ่มลงมือทำ System prompt, คำจำกัดความเครื่องมือ, เอกสารที่ดึงมาไม่กี่ชุด, การอ่านไฟล์, log, error trace และสรุปต่าง ๆ สามารถใช้พื้นที่หมดเร็วกว่าที่คาด กรอบคิดเชิงปฏิบัติไม่ใช่ว่าหน้าต่างดูใหญ่แค่ไหนบนกระดาษ แต่คือเอเจนต์ใช้มันเร็วแค่ไหนตอน runtime คำแนะนำด้านหน่วยความจำเอเจนต์ของ Redis ชี้ไปยังหน่วยความจำภายนอกที่คงทนสำหรับสถานะที่ควรอยู่รอดข้ามการเรียก ขณะที่กรอบ context-engineering ของ Atlan แยก prompt ที่ดีกว่าออกจากการประกอบบริบทที่ดีกว่า เมื่อนำมารวมกัน พวกเขาปฏิบัติกับหน้าต่างบริบทเหมือนคลังสินค้าน้อยลง และเหมือน working set ที่มีข้อจำกัดมากขึ้น

บทเรียนที่ลึกกว่าคือหน้าต่างบริบทเป็นทรัพยากร runtime ที่มีจำกัด การมองมันเป็น “หน่วยความจำ” มีประโยชน์ แต่ก็ต่อเมื่อฮาร์เนสทำตัวเหมือนระบบปฏิบัติการ: จัดสรร ขับออก page บีบอัด deduplicate และ persist ความแตกต่างของเลเยอร์จาก Atlan มีประโยชน์ตรงนี้ Prompt engineering แก้ตัวอ่านไฟล์ที่เท token ไม่เกี่ยวข้อง 80,000 token ลงในการเรียกถัดไปไม่ได้ Context engineering ปรับปรุง working set ได้ Harness engineering เป็นตัวตัดสินว่า working set นั้นถูกปกป้องตั้งแต่แรกหรือไม่

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

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

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

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

ข้อสี่ ย้ายค่าขนาดใหญ่ออกจาก prompt เก็บไว้ ตั้งชื่อ และส่งพอยน์เตอร์ผ่านเครื่องมือ สิ่งนี้สำคัญเป็นพิเศษสำหรับเอเจนต์ที่เรียก API ประมวลผลเอกสาร หรือประสานระบบหลายเอเจนต์

สุดท้าย ทดสอบ goal loss แยกจาก overflow เอเจนต์อาจยังอยู่ใต้หน้าต่างแบบแข็งแต่ยัง drift ได้ คำถามที่ถูกต้องไม่ใช่แค่ “API รับ prompt หรือไม่” แต่คือ “การกระทำถัดไปยังรับใช้ภารกิจเดิมอยู่หรือไม่”

สรุปด้านล่างเปลี่ยนรูปแบบเหล่านี้ให้เป็น checklist สั้น ๆ ก่อน FAQ

• เอเจนต์ที่ทำงานระยะยาวล้มเหลวได้ทั้งจาก context overflow และ goal loss ดังนั้นฮาร์เนสต้องจัดการมากกว่าความยาวของ prompt
• ระบบเอเจนต์ในโปรดักชันใช้งบประมาณแบบแข็งกับไฟล์ ผลลัพธ์จากเครื่องมือ และประวัติ ก่อนที่ข้อมูลดิบจะไปถึงโมเดล
• Pagination, search และมุมมองที่จัดการได้ ปฏิบัติกับบริบทเหมือน viewport ที่จำกัด ไม่ใช่ storage ถาวร
• การบีบอัดทำงานได้ดีที่สุดเมื่อเป็น checkpointing: มันรักษาเป้าหมาย ข้อจำกัด การตัดสินใจ งานค้าง และความครบถ้วนของการเรียกเครื่องมือ
• ผลลัพธ์จากเครื่องมือขนาดใหญ่มักควรอยู่ใน storage ภายนอก พร้อมส่งพอยน์เตอร์สั้น ๆ ระหว่างเครื่องมือ แทนการใส่ค่าทั้งหมดใน prompt

ส่วนนี้ตอบคำถามเชิงปฏิบัติที่อยู่เบื้องหลัง context engineering สำหรับเอเจนต์ที่ทำงานระยะยาว: อะไร overflow, เป้าหมายหายไปได้อย่างไร และรูปแบบฮาร์เนสใดช่วยให้งานไม่หลุดราง

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

Goal loss เกิดขึ้นเมื่องานเดิมยังปรากฏอยู่ที่ใดสักแห่งในทรานสคริปต์ แต่ไม่ชี้นำการกระทำถัดไปของเอเจนต์อีกต่อไป มักเกิดหลังประวัติยาว ๆ หรือการสรุปที่ไม่ดี

ฮาร์เนสตั้งงบประมาณรายแหล่ง ทำ pagination สำหรับการอ่านไฟล์ ดึงเฉพาะมุมมองที่เกี่ยวข้อง บีบอัดประวัติรอบสถานะ deduplicate การอ่านซ้ำ และเก็บผลลัพธ์ขนาดใหญ่นอก prompt

พอยน์เตอร์ทำให้โมเดลอ้างถึงค่าขนาดใหญ่ที่เก็บไว้ใน runtime memory ได้ เช่น เมทริกซ์ log หรือ PDF ขณะที่เครื่องมือปลายน้ำ resolve ข้อมูลเต็มโดยไม่ต้องวางไว้ในหน้าต่างบริบท

ไม่เพียงพอ หน้าต่างที่ใหญ่ขึ้นช่วยได้ แต่ system prompt, คำจำกัดความเครื่องมือ, เอกสารที่ดึงมา, log และประวัติยังคงแย่งพื้นที่กัน และข้อมูลที่เกี่ยวข้องอาจถูกฝังก่อนจะชนขีดจำกัดแบบแข็ง