上下文工程是甚麼？為何 AI 智能體再強，也會因上下文膨脹而失靈

โดย Nokka (นก-กา) | ตรวจข้อมูล 28 ต.ค. 2026 · บทที่ 1 ของชุด Agentic Engineering เจาะลึก

บทความนี้เขียนโดย AI (deepseek-v4.1-flash · ผู้ให้บริการโมเดล: ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา)

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

หลายครั้งสาเหตุไม่ได้อยู่ที่โมเดล แต่อยู่ที่สิ่งที่มันถืออยู่ในมือตอนนั้น

Anthropic เรียกงานนี้ว่า context engineering และนิยามว่าคือชุดกลยุทธ์ในการจัดและดูแลชุดโทเคนที่เหมาะสมที่สุดระหว่างการอนุมาน รวมถึงข้อมูลทุกอย่างที่ไหลเข้ามานอกเหนือจากคำสั่งของผู้ใช้ [1]

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

context engineering ต่างจาก prompt engineering ยังไง

ขอบเขตที่กว้างกว่าเดิม

prompt engineering คือวิธีเขียนและจัดคำสั่งให้โมเดลตอบได้ตามที่ต้องการ

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

เมื่อ agent ทำงานเป็นลูป มันจะสร้างข้อมูลใหม่ทุกเทิร์น และข้อมูลเหล่านั้นแย่งที่กันในหน้าต่าง context เดียวกัน

Anthropic เขียนไว้ตรง ๆ ว่ายิ่งงานยืดเยื้อเท่าไร ปัญหาการปนเปื้อนของ context ก็ยิ่งชัด และวิธีที่เขาใช้แก้มีสามตัวคือ compaction, structured note-taking และ multi-agent [1]

attention budget หมดได้จริง

งบความสนใจที่มีจำกัด

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

เปรียบเทียบง่าย ๆ ว่าโมเดลมี "งบความสนใจ" จำกัด และทุกโทเคนที่เพิ่มเข้ามาก็เผางบนั้นไปทีละนิด [1]

ฟังดูเป็นอุปมา แต่มีงานทดลองรองรับ

Chroma ทดสอบโมเดล 18 ตัว รวมถึง GPT-4.1, Claude 4, Gemini 2.5 และ Qwen3 แล้วพบว่าความแม่นยำลดลงเมื่อ input ยาวขึ้น และลดลงแบบไม่สม่ำเสมอ ไม่ใช่แบบเส้นตรงที่คาดเดาง่าย [2]

ทีมวิจัยชี้ว่าการทดสอบแบบ Needle in a Haystack ที่โมเดลทำคะแนนเกือบเต็มนั้นวัดการค้นคำตรงตัว ซึ่งง่ายกว่าการใช้งานจริงมาก [2]

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

compaction คือด่านแรกที่ต้องมี

ย่อแล้วเริ่มใหม่

compaction คือการย่อบทสนทนาที่ใกล้เต็มหน้าต่าง แล้วเริ่มหน้าต่างใหม่ด้วยบทสรุปนั้น [1]

Anthropic วางมันเป็นคันโยกแรกของ context engineering เพราะมันแก้ปัญหาได้ตรงจุดที่สุดเมื่อบริบทเริ่มเน่า

เครื่องมืออย่าง Claude Code มีคำสั่ง /compact สำหรับงานนี้ และมี /clear สำหรับเคลียร์งานที่ไม่เกี่ยวกันออกไปเลย [3]

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

ข้อควรระวังคือ compaction ที่ aggressive เกินไปจะพาเอารายละเอียดสำคัญหายไปด้วย เช่น ชื่อไฟล์ที่ตกลงกัน หรือข้อจำกัดที่ลูกค้ากำหนด

ทางแก้คือเขียนสิ่งที่ห้ามหายไว้ในไฟล์สถานะแยก ไม่ปล่อยให้มันอยู่ในบทสนทนาที่จะถูกย่อ

note-taking ทำให้ agent มีสมุดโน้ต

เขียนสิ่งที่เรียนรู้ลงไฟล์

structured note-taking คือการให้ agent เขียนสิ่งที่เรียนรู้ลงไฟล์ภายนอก แล้วอ่านกลับเมื่อจำเป็น [1]

Anthropic อธิบายว่าวิธีนี้ทำให้ agent ประกอบความเข้าใจทีละชั้น และเก็บไว้เฉพาะสิ่งที่ต้องใช้ในหน่วยความจำทำงาน [1]

ตัวอย่างไฟล์สถานะที่ผมใช้บ่อยมีหน้าตาแบบนี้

# สถานะงาน
## ตกลงแล้ว
- ใช้ postgres 15 ห้ามอัปเกรด
- API ต้องตอบ p95 ต่ำกว่า 200ms

## ทำเสร็จแล้ว
- migration 004 (เพิ่ม index)

## ค้างอยู่
- เขียนเทสต์ integration ของ endpoint /orders

ไฟล์แบบนี้ทำให้ agent กลับมาอ่านได้ทุกเมื่อโดยไม่ต้องแบกทั้งบทสนทนา และทำให้คุณตรวจงานมันได้ง่ายขึ้นด้วย

sub-agent คือการแบ่งห้องทำงาน

แบ่งงานให้ตัวย่อยเริ่มด้วย context สะอาด

วิธีที่สามคือใช้ sub-agent หลายตัว โดยตัวหลักถือแผนระดับสูง แล้วส่งงานเฉพาะทางให้ตัวย่อยที่เริ่มด้วย context สะอาด [1]

ข้อดีคือตัวย่อยสามารถสำรวจลึกได้โดยไม่ทำให้ context ของตัวหลักบวม

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

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

just-in-time retrieval ไม่ใช่การยัดทุกอย่างไว้ก่อน

ค้นเมื่อจำเป็น ดีกว่ายัดไว้ก่อน

Anthropic เปรียบเทียบสองแนวทางคือโหลดข้อมูลไว้ล่วงหน้าทั้งกอง กับการให้ agent ค้นเมื่อจำเป็นผ่านเครื่องมืออย่าง glob และ grep [1]

แนวหลังเลี่ยงปัญหาดัชนีเก่าและโครงสร้างโค้ดที่ซับซ้อนได้ แต่แลกมาด้วยเวลาและจำนวนรอบที่เพิ่มขึ้น [1]

ในงานที่ข้อมูลเปลี่ยนบ่อย การค้นสดได้เปรียบชัด ส่วนงานที่ข้อมูลนิ่งอย่างเอกสารกฎหมาย การโหลดไว้ก่อนอาจคุ้มกว่า [1]

system prompt ต้องอยู่ที่ระดับความสูงที่ถูก

มีอีกจุดที่คนมองข้าม คือระดับรายละเอียดของคำสั่งระบบ

Anthropic เรียกว่าต้องอยู่ที่ "right altitude" คือสูงพอให้ยืดหยุ่น แต่ต่ำพอให้ชัดเจน โดยเลี่ยงสองความผิดพลาดคือเขียนตรรกะแข็งทื่อลงใน prompt กับการปล่อยให้กำกวมจนเดาไม่ได้ [1]

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

ถ้าเปลี่ยนเป็น "ห้ามแก้ migration เดิม ให้สร้างไฟล์ใหม่และรัน migration ตามลำดับ" agent จะทำงานต่อได้เองโดยไม่ฝ่าฝืนกฎ

วิธีวัดว่า context กำลังพัง

สี่สัญญาณที่เห็นได้โดยไม่ต้องมีเครื่องมือ

สัญญาณที่ผมใช้สังเกตมีสี่ข้อ และสังเกตได้โดยไม่ต้องมีเครื่องมือพิเศษ

• agent เริ่มถามสิ่งที่คุณบอกไปแล้วในรอบแรก
• คำตอบยาวขึ้นเรื่อย ๆ แต่ข้อมูลใหม่ลดลง
• มันอ้างชื่อไฟล์หรือฟังก์ชันที่ไม่มีอยู่
• งานเริ่มแกว่งไปแก้สิ่งที่ไม่ได้ขอ

ถ้าเจอสองข้อขึ้นไป ให้หยุดแล้วเริ่มรอบใหม่ด้วยไฟล์สถานะ ไม่ใช่พยายามดันต่อ

เรื่องนี้เกี่ยวกับ agentic engineering ยังไง

ทักษะพื้นฐานที่มาก่อนเครื่องมือ

ถ้า agentic engineering คือการกำกับ agent ให้ได้งานคุณภาพโดยไม่ลดมาตรฐาน [4] การจัดการ context คือทักษะพื้นฐานที่สุดของมัน และเป็นทักษะที่คนใช้ agent ทุกวันควรมีก่อนเรื่องอื่น

เพราะ agent ที่ context เสียจะทำงานเร็วแต่ผิด และคนที่ต้องตามแก้คือคุณ

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

คำตอบของคำถามตั้งต้น

context engineering คือการยอมรับว่าโมเดลไม่ได้จำทุกอย่างได้เท่ากัน และการออกแบบว่ามันควรเห็นอะไรในแต่ละช่วงคือส่วนหนึ่งของงานวิศวกรรม ไม่ใช่เรื่องของ prompt สวย ๆ

ถ้าจะสรุปเป็นประโยคเดียว งานของเราคือทำให้ agent เห็นน้อยลงแต่เห็นสิ่งที่ถูกต้อง

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

REF

[1] Anthropic (29 ก.ย. 2025) · Effective context engineering for AI agents. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

[2] Chroma Research (2025) · Context Rot: How Increasing Input Tokens Impacts LLM Performance. https://research.trychroma.com/context-rot

[3] Anthropic (2026) · Claude Code best practices และเอกสารประกอบ. https://www.anthropic.com/engineering/claude-code-best-practices

[4] Andrej Karpathy (4 ก.พ. 2026) · นิยาม agentic engineering (X (Twitter)). https://x.com/karpathy/status/2019137879310836075