โดย 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
Top comments (0)