Skip to content
TL;DR — สรุปไว้ก่อน
ปี 2026 Context Engineering กลายเป็นทักษะหลักของคนที่สร้าง AI agent ในระดับ production ไม่ใช่ Prompt Engineering อีกต่อไปแล้วครับ ทาง Anthropic, Thoughtworks, และทีม Manus ออกมายืนยันตรงกันว่า “weaker model + good context > stronger model + bad context”
5 เทคนิคที่เราต้องรู้ในปี 2026 คือ:
- Just-in-Time (JIT) Context Retrieval — ให้ agent โหลดข้อมูลเองตอนต้องการใช้
- Progressive Disclosure ผ่าน Agent Skills — เปิดเผยข้อมูลเป็นชั้นๆ ตามความต้องการ
- Compaction & Structured Note-Taking — บีบอัดบทสนทนาเก่า เก็บ memory แบบ structured
- Sub-Agent Architecture — แบ่งงานยากให้ agent ลูกที่มี context สะอาด
- MCP Volume Control — คุมจำนวน MCP server ที่โหลดเข้า context window
💡 Key insight ของผม — ถ้ายังเขียน prompt ยาวเป็นหน้าๆ แล้วยัดทุกอย่างลงไปอยู่ ปี 2026 นี่คือสัญญาณว่ายังตามไม่ทันแล้วครับ context window คือ scarce resource ที่ต้องบริหารเหมือน RAM ในยุคคอมพิวเตอร์ยุคแรก
ทำไม Prompt Engineering อย่างเดียวไม่พอแล้วในปี 2026
เมื่อปลายปี 2024 เวลาผมไปสอน workshop เรื่อง AI ให้ทีม IT ของบริษัทใหญ่ๆ ในไทย คำถามแรกที่ทุกคนถามคือ “พี่ครับ prompt ที่ดีต้องเขียนยังไง” ผมก็ตอบไปแบบมาตรฐาน — role + context + task + constraint + output format ครบสูตร
มาถึงตอนนี้ ปี 2026 คำถามมันเปลี่ยนไปแล้วครับ จาก “จะเขียน prompt ยังไงให้ดี” กลายเป็น “ทำไม agent ของผมที่ใช้ Claude Sonnet 4.5 มีบางครั้งทำงานเก่ง บางครั้งเพี้ยน ทั้งๆ ที่ prompt เหมือนกัน” คำตอบคือ — context ที่ส่งเข้าไปไม่เหมือนกัน
ทาง Anthropic ในบทความ “Effective context engineering for AI agents” ระบุชัดว่าทุกโมเดลมี context rot — ยิ่ง context ยาวขึ้น ความแม่นยำในการดึงข้อมูลกลางๆ ของ context ก็แย่ลง การวิจัยจาก Chroma เรียกปรากฏการณ์นี้ว่า “Context Rot: How Increasing Input Tokens Impacts LLM Performance”
ที่เจอตอนทำงานจริง — เคยมีลูกค้ากลุ่มประกันเอาเอกสาร compliance 200 หน้ายัดเข้า prompt แล้วถาม Claude ตรงๆ ว่าข้อ 47 บอกว่ายังไง ผลคือมันตอบผิดเป็นประจำ ไม่ใช่เพราะโมเดลไม่เก่ง แต่เพราะข้อมูลกลางๆ ของ 200K tokens มันหายไปในความยาวของ context นั่นเอง
“Context engineering treats the context window as a design surface and intentionally constructs the AI’s information environment.” — Thoughtworks Technology Radar, April 2026
นี่คือเหตุผลที่ Prompt Engineering ในปี 2026 ต้องโตขึ้นเป็น Context Engineering — ไม่ใช่แค่เขียนคำสั่งให้ดี แต่ต้องออกแบบทั้งระบบที่ feed ข้อมูลให้ AI
เทคนิคที่ 1: Just-in-Time (JIT) Context Retrieval
แนวคิดพื้นฐาน — แทนที่จะ preload ข้อมูลทั้งหมดเข้า context ตั้งแต่ต้น ให้ agent โหลดเอง ตอนที่ต้องการใช้
วิธีนี้ Anthropic ใช้ใน Claude Code มาตั้งแต่ปลายปี 2025 แล้วครับ เวลาเปิดโปรเจกต์ Claude Code ไม่ได้อ่านทุกไฟล์ในโปรเจกต์ของเราเข้า context มันแค่อ่าน CLAUDE.md ก่อน แล้วใช้ glob, grep, Read tool ไปดูไฟล์ทีหลังตอนที่ต้องแก้
ข้อดี:
- ลด token consumption ตั้งต้น (cold start เร็ว)
- หลีกเลี่ยง stale indexing — เพราะอ่านล่าสุดทุกครั้ง
- Agent ใช้ทักษะ “exploration” ตามธรรมชาติ ค้นเจอ context ที่จำเป็นเองได้
💡 Opinion ของผม — เทคนิคนี้คล้ายๆ กับเวลาให้พนักงานใหม่ทำงาน ผมไม่ได้ส่ง 50 หน้ากระดาษเอกสารทุกอย่างให้อ่านวันแรก แต่บอกว่า “เอกสาร X อยู่ใน drive Y ส่วน SOP เปิด confluence” เขาก็ไปอ่านเองตอนต้องใช้ AI agent ก็เหมือนกันครับ
วิธีทำในระบบของเราเอง:
- ตั้ง file system + bash tool ให้ agent
- เก็บข้อมูลเป็น file path identifier ไม่ใช่ผลลัพธ์ที่ดึงออกมา
- ออกแบบ tool description ให้ agent รู้ว่าจะไปหาอะไรที่ไหน
เทคนิคที่ 2: Progressive Disclosure ผ่าน Agent Skills
ตุลาคม 2025 ทาง Anthropic เปิดตัว Agent Skills เป็น open standard และตอนนี้กลายเป็นรูปแบบมาตรฐานที่ AI infra ทั้งวงการเริ่มเอาไปใช้แล้ว
หลักการของ Skills คือ Progressive Disclosure — เปิดเผย context เป็น 3 ระดับ:
- Level 1 (Always loaded — ~100 tokens): YAML metadata ที่บอกชื่อ skill + description สั้นๆ ทุก skill ใน system จะมีบรรทัดนี้อยู่ใน system prompt เพื่อให้ Claude รู้ว่ามี skill อะไรบ้าง
- Level 2 (Loaded on demand):
SKILL.mdตัวเต็ม โหลดเข้ามาตอนที่ Claude คิดว่า skill นี้เกี่ยวกับงานปัจจุบัน - Level 3 (Reference files): ไฟล์ลูกที่
SKILL.mdอ้างถึง เช่นreferences/colors.md,scripts/generate.pyโหลดเฉพาะตอนต้องใช้จริง
เคสจริงที่ผมเอามาใช้ — ในระบบ Data-Espresso ผมมี skill ชื่อ arty-voice ที่เก็บโปรไฟล์การเขียนของผมไว้ Claude ไม่ได้โหลดทุกครั้ง แต่จะโหลดเฉพาะตอนที่ผมขอให้เขียน blog post หรือ social media — ถ้ากำลังถามเรื่อง coding ก็ไม่จำเป็นต้องโหลดเข้ามาเปลือง token
ตามรายงานจาก daily.dev “State of Context Engineering in 2026” Pattern ของ Progressive Disclosure ตอนนี้กลายเป็น 1 ใน 5 รูปแบบหลักของ production agent แล้วครับ
💡 Insight — ถ้าทีมไหนยังเขียน system prompt ยาว 4000 tokens แล้วยัดทุกอย่างใส่ ลองดู Skills เป็นทางเลือก จะประหยัด token ได้เยอะมาก โดยที่ความสามารถไม่หาย
เทคนิคที่ 3: Compaction และ Structured Note-Taking
ปัญหาที่ทุกคนเจอเวลาทำ agent ที่ต้องคุยยาวๆ คือ — conversation history มันยาวจนเต็ม context window
วิธีแก้ของ Anthropic มี 2 ขั้น:
3.1 Compaction (การบีบอัดบทสนทนา)
วิธีคือ — ตอน context เริ่มเต็ม ให้โมเดลเอง summarize บทสนทนาเก่า เก็บแต่:
- การตัดสินใจสถาปัตยกรรม (architectural decisions)
- Bug ที่ยังไม่ได้แก้
- รายละเอียดการ implement
ทิ้งสิ่งที่ไม่จำเป็น เช่น tool output ที่เก่า, ข้อความที่ซ้ำ ผลลัพธ์คือบทสนทนา 100K tokens อาจกลายเป็น summary 5K tokens แล้วต่องานต่อได้
3.2 Structured Note-Taking (เก็บ memory นอก context)
วิธีนี้คือให้ agent เขียน “working notes” เก็บไว้นอก context window เลย — ใช้ file system หรือ memory tool ที่ Anthropic ปล่อยมาตอนเปิดตัว Sonnet 4.5
ตอนต้องการข้อมูลค่อยอ่านกลับเข้ามา ไม่ต้องเก็บทุกอย่างใน chat history
💡 ที่ผมเอามาใช้จริง — ในระบบ Cowork ของผมมี memory directory ที่ Claude เขียนเอง ทุกครั้งที่ผมเริ่ม session ใหม่ มันอ่าน MEMORY.md เป็น index ก่อน แล้วค่อยอ่านไฟล์ลูกตามต้องการ — เหมือนเปิด Notion ของตัวเองดูก่อนเริ่มงาน
เทคนิคที่ 4: Sub-Agent Architecture
เทคนิคนี้คือ — แทนที่จะให้ agent ตัวเดียวทำงานทุกอย่าง แบ่งงานให้ sub-agent ที่มี context สะอาด
ตัวอย่าง: ถ้าผมต้องวิเคราะห์ข้อมูลคู่แข่ง 5 ราย แบบ deep research แต่ละราย
- Main agent — เป็น coordinator วางแผน และสรุปผลรวม
- Sub-agent 1-5 — แต่ละตัวรับหน้าที่ research บริษัท 1 ราย ใช้ tens of thousands tokens ในการ explore
- Output — sub-agent ส่งคืนแค่ summary 1,000-2,000 tokens ให้ main agent
Main agent ไม่ต้องเห็น tool call และ exploration history ของแต่ละ sub-agent เลย เห็นแค่ผลสรุป — เหมือนเป็น manager ที่ delegate งาน
ตามที่ Anthropic เผยใน บทความเกี่ยวกับ multi-agent research system เทคนิคนี้แสดงผลดีกว่า single-agent อย่างชัดเจนใน complex research tasks
💡 Note — ใน Claude Code, sub-agent คือ feature ที่มีตั้งแต่กลางปี 2025 แล้ว เรียกใช้ผ่านคำสั่ง Task tool ใครยังไม่ลองแนะนำให้ลองครับ มันเปลี่ยนวิธีทำงานเยอะ
เทคนิคที่ 5: MCP Volume Control
Model Context Protocol (MCP) คือ standard ที่ใช้เชื่อม agent กับ external tools/data sources ปัญหาที่เกิดขึ้นในปี 2026 คือ — ทุกบริษัทออก MCP server ของตัวเอง
ลองดูสภาพในเครื่องผมตอนนี้ครับ — มี MCP ของ GitHub, Notion, Linear, Atlassian, Supabase, Gmail, Calendar, Slack, Figma, Canva, n8n… รวมๆ แล้ว tool description ของทุก MCP server กินไปแล้วเกือบ 30K tokens
ปัญหา: Replyant รายงานว่า ถ้า MCP tool descriptions เกิน 10% ของ context window ทาง Claude Code จะ switch ไปใช้ two-step search-then-call process เพื่อลดภาระ context — แต่นี่หมายความว่าเพิ่ม latency ขึ้นทันที
วิธีแก้:
- Lazy-load MCP servers — โหลดเฉพาะตัวที่ใช้ในงานนี้ ไม่ใช่ทุกตัวพร้อมกัน
- Token budget ต่อ MCP query — ตั้ง limit เช่น 500 tokens ต่อ tool call เพื่อไม่ให้ JSON ยาวๆ จาก database query กิน context จนเต็ม
- Context quarantining — แต่ละ subtask ใช้ context thread ของตัวเอง ไม่ปนกัน
- Summarization pipelines — ก่อน feed MCP output เข้าหา main agent ให้ LLM ตัวเล็กๆ summarize ก่อน
เคสจริงที่ผมเจอ — ตอนทำ agent วิเคราะห์ Stripe subscription data ลูกค้าผม MCP ของ Stripe คืน JSON 50 rows ของ subscription มาเลย กิน 8K tokens ทันที พอใช้ปกติๆ 5 ครั้งเข้ายังไม่ทันได้คุยอะไร context ก็เต็มแล้ว วิธีแก้ — สร้าง wrapper tool ใหม่ที่คืนแค่ aggregated metrics เท่าที่ต้องตอบคำถาม ไม่ส่ง raw data ทั้งหมด
ตัวอย่าง Implementation: Layered Context Management (LCM)
ถ้าจะเอา 5 เทคนิคข้างบนมาใช้จริง โครงสร้างที่นิยมในปี 2026 คือ Layered Context Management — แบ่ง context window เป็น layer ตามความสำคัญ
Priority order (จากสำคัญที่สุด):
- System prompt — role, behavioral constraints (ห้ามตัด)
- Tool definitions — function signatures (ห้ามตัด)
- Agent memory — persistent cross-session state
- MCP results — live data จากระบบที่ connected
- Retrieved documents — RAG results
- Conversation history — ตัด oldest first
เวลา context ใกล้เต็ม — ตัดจาก layer 6 ขึ้นมา layer 1 conversation history หายไม่เป็นไรเพราะ agent ถามต่อได้ แต่ tool definitions หายปุ๊บคือเจ๊งแน่นอน
ทีม Manus (สร้าง autonomous agent ที่ดังในต้นปี 2026) แชร์ใน blog ว่า — “การดูแลเรื่อง context curation สำคัญกว่าการออกแบบ reasoning logic” และพวกเขาใช้เวลา engineering ส่วนใหญ่ไปกับการตัดสินใจว่าอะไร ไม่ควร เข้า context — ผลคือ task completion rate เพิ่มขึ้นกว่า 30%
Anti-Patterns ที่ต้องระวัง
1. Blind Vector Stuffing
เอา vector database ดึงทุก chunk ที่ “เกี่ยวๆ” ใส่ context — ผลคือมีเสียงรบกวนเยอะ โมเดลโดน distract ความแม่นยำลด
2. Front-Loading Everything
ยัดทุกข้อมูล ทุก instruction ไว้ตั้งแต่ต้น “เผื่อใช้” — ทำให้ context rot, signal-to-noise ratio แย่
3. Loading All MCP Servers
เปิด MCP ทุกตัวที่มีพร้อมกันทุก session — กินไปแล้ว 30K tokens ก่อนเริ่มงาน
4. ไม่มี Token Budget
ไม่มีการกำหนด limit ต่อ tool call ทำให้ JSON ยาวๆ จาก API กิน context จนเต็มเร็วเกินไป
สรุป — Context Engineering คือทักษะหลักของปี 2026
ทุกอย่างที่พูดมาวนกลับมาที่หลักเดิมครับ — context window คือ scarce resource ต้องบริหารเหมือน RAM ในยุคแรกของคอมพิวเตอร์ ใครที่ยังคิดว่า “ใส่ๆ เข้าไปเถอะ ปัจจุบัน Claude มี 1M context อยู่แล้ว” — ระวังจะเจอ context rot จนงานพัง
ในมุมของผม Context Engineering ไม่ใช่ทักษะที่ต้องเรียนเป็นปี — แต่ต้องเริ่มฝึกตั้งแต่วันนี้ครับ:
- เริ่มจากเปลี่ยน mindset — จาก “เขียน prompt ยาวๆ” เป็น “ออกแบบ context แบบ progressive”
- ทดลองใช้ Claude Skills ในงานที่ทำซ้ำๆ
- ใช้
CLAUDE.md+ JIT retrieval แทนการ paste ทุกอย่าง - วาง MCP server ให้เปิดเฉพาะที่ต้องใช้
- ทำ sub-agent สำหรับงานยากๆ ที่ต้อง explore เยอะ
Context Engineering ก็เหมือนการจัดร้านกาแฟครับ ของเยอะไม่ได้แปลว่าดี — แต่ของที่จัดวางถูกที่ ถูกเวลา ลูกค้าหยิบใช้ง่าย นั่นคือร้านที่อยู่รอด ไม่ต่างกันสำหรับ AI agent ในปี 2026 เลยล่ะครับ
FAQ
Context Engineering ต่างกับ Prompt Engineering ยังไง?
Prompt Engineering สนใจการ เขียนคำสั่ง (wording) Context Engineering สนใจ ทุกอย่างที่ feed เข้าโมเดล — system prompt, tool definitions, MCP results, memory, retrieved docs, conversation history เปรียบเทียบให้เห็นภาพ — Prompt Engineering คือการเขียนข้อสอบ แต่ Context Engineering คือการเตรียม environment การสอบทั้งห้อง
ทีมเล็กที่งบจำกัด เริ่ม Context Engineering ยังไงดี?
เริ่มที่จุดที่ฟรีและได้ผลเร็วที่สุด — ใช้ Claude Skills เปลี่ยน system prompt ยาวๆ ของคุณให้กลายเป็น progressive skill ลด token cost ทันที 30-50% ตามด้วย CLAUDE.md ใน Claude Code ใช้ JIT แทน preload ไฟล์ทั้งโปรเจกต์ ส่วน sub-agent + MCP volume control ทำหลังเมื่อ scale ขึ้น
ใช้ Claude API หรือ Claude Code ดีกว่ากันสำหรับ Context Engineering?
Claude Code มี infrastructure พร้อมใช้ทันที (Skills, sub-agents, MCP, memory tool) ส่วน Claude API ให้ flexibility สูงสุด — ขึ้นกับว่าทีมจะ build product เอง (API) หรือใช้ tool ที่มีแล้ว (Code) สำหรับงาน internal automation ผมแนะนำ Claude Code ก่อน ส่วน customer-facing AI agent ค่อยใช้ API
Context window ใหญ่ขึ้น (1M tokens) จะทำให้ Context Engineering ไม่จำเป็นไหม?
ไม่ครับ — ในทางกลับกัน context window ใหญ่ทำให้ context rot ชัดเจนขึ้นด้วย เพราะข้อมูลกลางๆ ของ 1M tokens หายไปง่าย Anthropic ออกมาบอกชัดว่า “context windows of all sizes will be subject to context pollution” สรุปคือ context window จะใหญ่ขึ้นเรื่อยๆ แต่ Context Engineering ก็จะสำคัญขึ้นเรื่อยๆ ตามกัน
Agent Skills กับ MCP ต่างกันยังไง?
MCP คือ tool connection — เชื่อม agent กับ external system (database, API) ส่วน Skills คือ procedural knowledge — ชุดคำสั่ง + script + resource ที่ทำงานเฉพาะอย่าง โดยทั่วไป — ใช้ Skills สำหรับ workflow ที่ทำซ้ำๆ ใช้ MCP สำหรับเชื่อมข้อมูลภายนอก ใช้ทั้งสองตัวรวมกันสำหรับงาน complex ที่สุด