Context engineering คืออะไร

จบคอร์สที่ 15 คุณถือของจริงติดมือมาแล้วหนึ่งชิ้น — agent support ลูกค้าบน domain Order ที่ รันได้: model claude-opus-4-8 (ใช้เป็นตัวอย่าง ณ 2026-07 — id เลื่อนไหวตามเวลา) บวก tool สามตัว getOrder / getDeliveryStatus / issueRefund บวก loop ที่ป้อนผลของ tool กลับเข้า model จนงานเสร็จ #15 สอนคุณ ถือ model ให้ถูก คอร์สนี้สอนสิ่งเดียวที่ตัดสินว่า agent ตัวนั้น ดีหรือไม่ — คือ บริบท (context) ที่มันเห็นในทุกเทิร์น และก้าวแรกของทั้งคอร์สคือปรับสายตา: มองสิ่งที่คุณสร้างเสร็จแล้วใหม่ ไม่ใช่ในฐานะ “code ที่เรียก model” แต่ในฐานะ สิ่งที่เราป้อนให้ model เห็น

📦 code ตัวอย่าง

คอร์สนี้ต่อยอดจาก agent Order ตัวเดิมของคอร์สที่ 15 (repo kaen-food-ordering) โดยจะค่อยๆ ประกอบ context layer คร่อมมันทีละชั้น — retrieval, memory, การจัดงบ token, compaction และการจัดระเบียบผลของ tool — บทนี้เป็นบทวางกรอบความคิด ยังไม่มี code ให้รัน (ตั้งใจให้เป็นเช่นนั้น เพื่อให้ retrieval ตัวแรกที่ลงมือสร้างในบทที่ 2 มีน้ำหนัก) ทุกบทหลังจากนี้สร้างอยู่บนกรอบที่บทนี้วางไว้

ทุกอย่างที่ model เห็น คือ context — ไม่ใช่แค่ข้อความของผู้ใช้

คนส่วนใหญ่พอได้ยินคำว่า “context” จะนึกถึงข้อความล่าสุดที่ผู้ใช้พิมพ์เข้ามา แต่นั่นแคบเกินไปมาก Anthropic นิยามกว้างกว่านั้น — “Context refers to the set of tokens included when sampling from a large-language model (LLM).” แล้วไล่ส่วนประกอบทั้งหมดว่าคือ “the entire context state (system instructions, tools, [Model Context Protocol / MCP], external data, message history, etc).”

ลอง map ประโยคนั้นกลับลงบน agent ของคุณจากคอร์สที่ 15 ตรงๆ ในทุกเทิร์นที่คุณเรียก model สิ่งที่เดินทางเข้าไปไม่ได้มีแค่คำถามของลูกค้า แต่มีทั้ง:

system prompt — บทบาทและกติกาที่คุณตั้งให้ agent
นิยามของ tool ทั้งสามตัว — schema ของ getOrder / getDeliveryStatus / issueRefund ที่บอก model ว่าเรียกอะไรได้บ้าง
ผลของ tool ที่สะสมพอกขึ้นทุกรอบ — record ออเดอร์ สถานะเดลิเวอรี ผลการคืนเงิน ที่ loop ป้อนกลับเข้าไป
ประวัติบทสนทนา — ทุกข้อความก่อนหน้าใน running list ที่คุณส่งเข้าไปซ้ำทุกครั้ง
ข้อความล่าสุดของผู้ใช้ — ที่คนมักเข้าใจผิดว่าเป็น context ทั้งหมด ทั้งที่เป็นแค่ชิ้นเดียว

ทั้งกองนี้รวมกันคือสิ่งที่ model เห็นก่อนพิมพ์ token แรกของคำตอบ และการดูแลกองนี้ให้ดีคือศาสตร์ที่บทนี้เปิด — context engineering ที่ Anthropic นิยามไว้ว่า “the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference, including all the other information that may land there outside of the prompts.” — สังเกตวรรค “outside of the prompts” ให้ดี เพราะนั่นคือหัวใจ: งานนี้ไม่ได้จบที่การเขียน prompt

flowchart LR
  SP["system prompt<br/>บทบาท + กติกา"]
  TD["นิยาม tool 3 ตัว<br/>getOrder · getDeliveryStatus · issueRefund"]
  TR["ผลของ tool ที่สะสม<br/>ทุกเทิร์น"]
  H["ประวัติบทสนทนา<br/>สะสมพอกขึ้นทุกรอบ"]
  U["ข้อความล่าสุด<br/>ของผู้ใช้"]
  SP --> CW
  TD --> CW
  TR --> CW
  H --> CW
  U --> CW
  CW["context window<br/>งบ token จำกัด — ใช้แล้วหมด"] --> M["LLM สุ่มคำตอบ"]
  classDef budget fill:#0891b2,stroke:#064e5b,color:#f8fafc;
  class CW budget;

คำบรรยายภาพ: ทั้งห้าแหล่ง — system prompt, นิยาม tool, ผลของ tool ที่สะสม, ประวัติบทสนทนา และข้อความล่าสุดของผู้ใช้ — ไหลรวมเข้า context window ก้อนเดียวก่อน model จะสุ่มคำตอบ ข้อความของผู้ใช้เป็นแค่หนึ่งในห้า ที่เหลือคือสิ่งที่ คุณ เป็นคนคัดว่าจะใส่ และช่องสีฟ้าคือ context window ที่ไม่ใช่ถังเปล่ารอเติม แต่เป็นงบ token ที่ใช้แล้วหมด

context window คืองบที่ใช้แล้วหมด ไม่ใช่ถังที่เติมได้

ในคอร์สที่ 15 คุณรู้จัก Context Window มาแล้วในฐานะ “หน่วยความจำใช้งาน” ที่มีเพดาน บทนี้ขอเปลี่ยนวิธีมองมันหนึ่งองศาที่สำคัญมาก: อย่ามองมันเป็น ถัง ที่ยิ่งเติมยิ่งดี แต่ให้มองเป็น งบประมาณ ที่ทุกการใช้จ่ายมีต้นทุน Anthropic พูดชัด — “Every new token introduced depletes this budget by some amount, increasing the need to carefully curate the tokens available to the LLM.” และสรุปหลักไว้ว่า “Context, therefore, must be treated as a finite resource with diminishing marginal returns.” — ทรัพยากรจำกัดที่ให้ผลตอบแทนลดลงต่อเนื่อง ยิ่งอัดเข้าไปมาก ไม่ได้แปลว่าดีขึ้นตามส่วน

ทำไมถึงเป็นเช่นนั้น? Anthropic อธิบายด้วยกรอบคิดชื่อ Attention Budget — “LLMs have an ‘attention budget’ that they draw on when parsing large volumes of context.” เหตุผลเชิงกลไกคือความสัมพันธ์ระหว่าง token เป็นแบบ “n² pairwise relationships for n tokens.” ยิ่ง token เยอะ ความสัมพันธ์ที่ model ต้องแบ่งความสนใจไปดูแลก็โตแบบกำลังสอง

จุดที่ต้องระวังไว้ให้ขึ้นใจ: “attention budget” เป็นกรอบเชิงสัญชาตญาณ ไม่ใช่ตัวเลขที่วัดออกมาได้ ไม่มี field ไหนใน API คืนค่า “งบความสนใจที่เหลือ” ให้คุณอ่าน มันคือ วิธีคิด ที่ช่วยอธิบายว่าทำไม context ถึงต้องถือเป็นทรัพยากรจำกัด ไม่ใช่มาตรวัดจริง (สิ่งที่ วัดได้จริง คือจำนวน token จาก field usage ซึ่งเราจะลงมือวัดกันในบทที่ 4) การแยกสองอย่างนี้ให้ขาด — intuition กับ measurement — คือวินัยเดียวกับที่คอร์ส #15 ยึดมาตลอด

context engineering ยกระดับต่อจาก prompt engineering

ถ้าคุณเคยได้ยินคำว่า “prompt engineering” มาก่อน คำถามที่ถูกต้องคือ context engineering ต่างจากมันตรงไหน คำตอบของ Anthropic ตรงไปตรงมา — “At Anthropic, we view context engineering as the natural progression of prompt engineering.” ไม่ใช่ศาสตร์คนละเรื่องที่มาแทนที่ แต่คือขั้นถัดไปที่กว้างกว่า

เส้นแบ่งอยู่ที่ จังหวะเวลา prompt engineering คือการเขียนคำสั่งที่ดี ครั้งเดียว — งานเขียน (authoring) ที่ทำจบแล้วจบเลย ส่วน context engineering เป็นงานที่ทำ ซ้ำทุกเทิร์น: “context engineering is iterative and the curation phase happens each time we decide what to pass to the model.” ทุกครั้งที่ loop ของคุณจะเรียก model รอบใหม่ คุณ (หรือ code ของคุณ) ต้องตัดสินใจอีกครั้งว่าคราวนี้จะใส่อะไรเข้าไปในงบ

และนี่คือเหตุผลที่ agent ทำให้เรื่องนี้คมกว่าแชตบอตตอบครั้งเดียวจบมาก — “An agent running in a loop generates more and more data that could be relevant for the next turn of inference, and this information must be cyclically refined.” agent ที่วนเป็น loop สร้างข้อมูลใหม่พอกขึ้นทุกรอบ (ผลของ tool ที่คุณเห็นในไดอะแกรมข้างบน) ข้อมูลกองนั้นต้องถูก คัดสรรซ้ำเป็นวงจร ไม่ใช่ปล่อยให้พอกจนล้น การเขียน prompt ดีๆ ครั้งเดียวจึงไม่พออีกต่อไป

ถ้าจะให้เห็นภาพในภาษาที่วิศวกรสาย ML คุ้น Chip Huyen เทียบไว้ตรงๆ — “Context construction for foundation models is equivalent to feature engineering for classical ML models…” การประกอบ context ให้ model ก็เหมือนการทำ feature engineering ให้ model ML แบบดั้งเดิม: คุณไม่ได้โยนข้อมูลดิบทั้งหมดเข้า model แล้วหวังผล แต่คัดและปั้น input ให้เป็นสัญญาณที่ดีที่สุดเท่าที่ทำได้

ดาวเหนือ: หา token สัญญาณสูงชุดที่เล็กที่สุด

ทุกเทคนิคในคอร์สนี้เล็งไปที่ประโยคเดียวกัน — ดาวเหนือที่ Anthropic วางไว้ว่า “good context engineering means finding the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome.” อ่านช้าๆ อีกรอบ เพราะทุกคำมีน้ำหนัก: smallest possible (เล็กที่สุดเท่าที่ทำได้ — เพราะงบจำกัด) high-signal (สัญญาณสูง — ไม่ใช่แค่เยอะ) และ maximize the likelihood of some desired outcome (เพื่อผลลัพธ์ที่ต้องการจริงๆ ไม่ใช่ใส่ให้ครบไว้ก่อน)

หลักข้อนี้ไม่เปลี่ยนไม่ว่าคุณจะทำเทคนิคไหน Anthropic ย้ำว่า “Whether you’re implementing compaction for long-horizon tasks, designing token-efficient tools, or enabling agents to explore their environment just-in-time, the guiding principle remains the same…” — และมันคือแกนที่ร้อยทั้งแปดบทของคอร์สนี้เข้าด้วยกัน แต่ละบทที่เหลือคือ วิธีหนึ่งวิธี ในการเข้าใกล้ดาวเหนือดวงนี้

บันไดของคอร์สนี้

ที่เหลือคือการประกอบ context layer คร่อม agent Order ทีละชั้น แต่ละชั้นคือเครื่องมือหนึ่งชิ้นสำหรับหา “token สัญญาณสูงชุดที่เล็กที่สุด”:

Retrieval (บทที่ 2) — เพิ่ม tool ตัวที่สี่ searchOrderKnowledge ที่ดึงเฉพาะข้อมูลที่เกี่ยวข้องจากคลังนโยบาย/FAQ เข้ามาใส่ context ตอน runtime แทนที่จะยัดทุกอย่างไว้ล่วงหน้า
Memory (บทที่ 3) — ให้ agent เขียนโน้ตเก็บไว้ นอก หน้าต่างแล้วอ่านกลับข้าม session — ความจำสั้นกับความจำยาว
งบประมาณ token (บทที่ 4) — วัดการใช้ token จริงของ agent #15 จาก field usage เทิร์นต่อเทิร์น มองหน้าต่างเป็นเพดาน ไม่ใช่เป้า
Compaction สู้ context rot (บทที่ 5) — สรุปประวัติที่ยาวขึ้นให้กระชับ โดยรักษาสิ่งที่ชี้ขาดไว้ ทิ้ง blob ที่จัดการไปแล้ว
จัดระเบียบผลของ tool (บทที่ 6) — ปั้นสิ่งที่ tool คืนกลับมา ให้เหลือแต่ field ที่ agent ต้องใช้จริง ไม่ใช่ JSON ทั้งก้อน
แยก context ด้วย sub-agent (บทที่ 7) — เหตุผลรูปเดียวที่ควรแตกงานให้ agent ตัวที่สอง และทำไมต้องใช้อย่างประหยัด (ต่อเนื่องจากคอร์ส #12)
ประกอบเป็น context layer ตัวเต็ม (บทที่ 8) — ร้อยทุกชั้นเข้าด้วยกันคร่อม agent Order แล้วส่งไม้ต่อให้คอร์สประเมินผล #13

ปลายทางของคอร์สนี้ไม่ใช่ agent ที่ฉลาดขึ้นเพราะ model ใหญ่ขึ้น แต่คือ agent เดิมที่ เห็นของที่ถูกต้อง ในทุกเทิร์น — บทหน้าเราเริ่มลงมือชั้นแรก

🔗 อ้างอิงต้นทางของบทนี้

บทนี้อิงต้นทางที่ลงวันที่กำกับ อ่านต่อได้โดยตรง:

Anthropic, “Effective context engineering for AI agents” (2025-09-29) — นิยาม context engineering, context ว่าคือ token ทั้งชุดที่ model เห็น, “attention budget” กับ context ในฐานะทรัพยากรจำกัดที่ผลตอบแทนลดลง, การเป็นวิวัฒนาการต่อจาก prompt engineering และดาวเหนือ “smallest set of high-signal tokens”
Chip Huyen, “Building A Generative AI Platform” (2024-07-25) — การประกอบ context ให้ foundation model เทียบได้กับ feature engineering ของ ML แบบดั้งเดิม

เช็กความเข้าใจ — บทที่ 1

ข้อ 1 / 3

ในคอร์สนี้ คำว่า context ครอบคลุมอะไรบ้างในแต่ละเทิร์นที่เรียก model?

Context engineering คือ​อะไร

ทุก​อย่าง​ที่ model เห็น คือ context — ไม่ใช่​แค่​ข้อความ​ของ​ผู้​ใช้

context window คือ​งบ​ที่​ใช้​แล้ว​หมด ไม่ใช่​ถัง​ที่​เติม​ได้

context engineering ยก​ระดับ​ต่อ​จาก prompt engineering

ดาว​เหนือ: หา token สัญญาณ​สูง​ชุด​ที่​เล็ก​ที่สุด

บันได​ของ​คอร์ส​นี้