Context Engineering ที่ได้ผลสำหรับ AI Agents

เกี่ยวกับบทแปลนี้

บทความนี้เป็น บทแปลภาษาไทยอย่างไม่เป็นทางการ ของ “Effective context engineering for AI agents” เขียนโดยทีม Applied AI ของ Anthropic — Prithvi Rajasekaran, Ethan Dixon, Carly Ryan และ Jeremy Hadfield โดยมี Rafi Ayub, Hannah Moran, Cal Rueb และ Connor Jennings ร่วมสมทบ

เผยแพร่บน Anthropic Engineering เมื่อ 29 กันยายน 2025

แปลและเรียบเรียงเพื่อการศึกษา — ไดอะแกรมเชิงแนวคิดวาดใหม่เป็นภาษาไทย (label ของ node คงเป็นภาษาอังกฤษ) และศัพท์เทคนิคคงไว้เป็นภาษาอังกฤษพร้อมคำอธิบายไทยเมื่อพบครั้งแรก ลิขสิทธิ์ของเนื้อหาต้นฉบับเป็นของ Anthropic

Context (บริบท — ชุดข้อมูลทั้งหมดที่ model เห็นในหนึ่งครั้งของการอนุมาน) เป็นทรัพยากรที่สำคัญยิ่งแต่ก็ มีจำกัด สำหรับ AI agent บทความนี้รวบรวมกลยุทธ์ในการ ดูแล (curate) และจัดการ context ที่ขับเคลื่อน agent ซึ่งสร้างขึ้นบน LLM ให้เกิดประสิทธิภาพสูงสุด

Context engineering คือวิวัฒนาการตามธรรมชาติที่ต่อยอดมาจาก prompt engineering เมื่อเราขยับจากการเขียน prompt แบบครั้งเดียวจบ ไปสู่การสร้าง agent ที่ทำงานเป็นวงรอบยาว ๆ โจทย์ก็เปลี่ยนจาก “เขียนคำสั่งให้ดี” ไปเป็น “จะจัดสรรพื้นที่ใน context window อันจำกัดอย่างไรให้คุ้มที่สุดในทุก ๆ ก้าว”

Context engineering เทียบกับ prompt engineering

ในยุคแรกของ LLM งานส่วนใหญ่ของวิศวกร AI คือ prompt engineering เพราะ use case ส่วนใหญ่ที่ไม่ใช่การแชตในชีวิตประจำวัน มักเป็นงานแบบ single-shot (ทำครั้งเดียวจบ) เช่น การจัดหมวดหมู่ (classification) หรือการสร้างข้อความ (text generation)

หัวใจจึงอยู่ที่การเลือกถ้อยคำและวิธีเรียบเรียงคำสั่งให้ได้ผลลัพธ์ที่ต้องการ

แต่เมื่อเราสร้าง agent ที่ทำงานต่อเนื่องเป็นวงรอบ โจทย์ก็ใหญ่กว่าตัว prompt มาก agent ทำงานเป็นวงรอบ และในแต่ละรอบมันสร้างข้อมูลใหม่ ๆ ที่ อาจจะ มีความเกี่ยวข้องขึ้นมาเรื่อย ๆ ข้อมูลเหล่านี้ต้องถูกกลั่นกรองซ้ำเป็นวงจร

คำถามหลักจึงไม่ใช่แค่ “prompt ควรเขียนว่าอะไร” แต่เป็น “อะไรบ้างที่ควรอยู่ใน context ของ model ณ จุดนี้”

นิยามที่ใช้ในบทความนี้

Prompt engineering หมายถึงวิธีการเขียนและจัดระเบียบคำสั่งของ LLM เพื่อให้ได้ผลลัพธ์ที่ดีที่สุด
Context engineering หมายถึง ชุดของกลยุทธ์ในการดูแลและรักษาชุด token (ข้อมูล) ที่เหมาะสมที่สุดตลอดการอนุมานของ LLM ซึ่งครอบคลุมข้อมูล ทุกอย่าง ที่อาจไหลเข้ามาใน context นอกเหนือจากตัว prompt ด้วย
Agent ในบทความนี้หมายถึง LLM ที่ใช้ tool อย่างอิสระแบบวนเป็นวงรอบ (LLMs autonomously using tools in a loop)

พูดอีกอย่าง prompt engineering เป็นเพียง ส่วนย่อยหนึ่ง ของ context engineering เพราะการเขียน system prompt ก็คือส่วนหนึ่งของงานดูแล context ส่วน context engineering เองเป็นภาพที่กว้างกว่า — มันคือการกลั่นกรองอย่างซ้ำ ๆ (iterative refinement) ว่าจะให้อะไรอยู่ใน context ในแต่ละก้าวของการทำงาน

context ที่ agent ต้องบริหารประกอบด้วยหลายส่วน

system prompt
tools
Model Context Protocol (MCP — โพรโทคอลมาตรฐานสำหรับเชื่อม agent เข้ากับข้อมูล/เครื่องมือภายนอก)
ตัวอย่าง (examples)
ประวัติข้อความ (message history)
file ความจำ (memory files)
ข้อมูลที่ดึงมา (retrieved data)
state ระหว่างรัน

ทั้งหมดนี้ต้องหลอมรวมกันภายใน context window ที่มีขนาดจำกัด

flowchart LR
  SP[System Prompt]
  TL[Tools]
  MCP[Model Context Protocol]
  EX[Examples]
  MH[Message History]
  MEM[Memory Files]
  RD[Retrieved Data]
  RS[Runtime State]
  CW[Context Window]
  SP --> CW
  TL --> CW
  MCP --> CW
  EX --> CW
  MH --> CW
  MEM --> CW
  RD --> CW
  RS --> CW
  CW --> LLM[LLM Inference]

ภาพ 1 — context ไม่ได้มีแค่ prompt แต่เป็นทุกแหล่งข้อมูลที่ไหลมารวมกันใน context window เดียวกันก่อนถึงการอนุมานของ model งานของ context engineering คือการเลือกว่าจะให้อะไรเข้ามาบ้าง

เพราะ agent สร้างข้อมูลเพิ่มขึ้นเรื่อย ๆ ในทุกรอบ งานจึงกลายเป็นวงจรของการกลั่นกรอง: ดูแลชุด token ที่มีสัญญาณสูงสุด → ให้ model อนุมาน → agent เรียกใช้ tool → มีข้อมูลใหม่ไหลเข้า context → ตัดแต่ง/กลั่นกรอง context ใหม่ แล้ววนกลับไปเริ่มรอบถัดไป

flowchart LR
  Curate[Curate high signal tokens] --> Infer[LLM generates response]
  Infer --> Act[Agent calls tools]
  Act --> Grow[New data enters context]
  Grow --> Refine[Refine and prune context]
  Refine --> Curate

ภาพ 2 — วงจรของ context engineering: ในทุกก้าวเราต้องกลั่นกรองว่าจะเก็บอะไรและตัดอะไรทิ้ง context จึงไม่ใช่สิ่งที่ตั้งไว้ครั้งเดียวจบ แต่ต้องดูแลอย่างต่อเนื่อง

ทำไม context engineering จึงสำคัญต่อการสร้าง agent ที่เก่ง

แม้ context window จะใหญ่ขึ้นเรื่อย ๆ แต่ LLM ก็ยังมี “งบความสนใจ” (attention budget) ที่จำกัด และจะร่อยหรอลงเมื่อประมวลผล token มากขึ้นเรื่อย ๆ

ปรากฏการณ์นี้มักถูกเรียกว่า context rot (ภาวะที่คุณภาพการเรียกคืนข้อมูลของ model เสื่อมลงเมื่อ context ยาวขึ้น) คือยิ่งจำนวน token ใน context เพิ่มขึ้น ความสามารถของ model ในการเรียกคืนข้อมูลได้อย่างแม่นยำก็ยิ่งลดลง

รากของปัญหานี้อยู่ที่สถาปัตยกรรมของ transformer เอง ในกลไก attention ทุก token จะต้องพิจารณาความสัมพันธ์กับทุก ๆ token อื่น หมายความว่าสำหรับ n token เราจะมีคู่ความสัมพันธ์ราว n² คู่ เมื่อ context ยาวขึ้น ความสามารถของ model ในการเก็บความสัมพันธ์เหล่านี้ก็ถูกยืดจนบางลง

ยิ่งไปกว่านั้น model ถูกฝึกจากข้อมูลที่เป็นลำดับสั้น ๆ เสียเป็นส่วนใหญ่ มันจึงมีประสบการณ์กับ long-range dependency (ความสัมพันธ์ระหว่าง token ที่อยู่ห่างกันมาก) น้อยกว่า

และเทคนิคอย่างการ interpolate ตำแหน่ง (positional encoding) เพื่อยืดหน้าต่างให้ยาวขึ้นก็แลกมาด้วยความแม่นยำที่ลดลงบ้าง

บทเรียนสำคัญคือ ควรมอง context เป็น ทรัพยากรที่มีจำกัดและมีผลตอบแทนส่วนเพิ่มที่ลดลง (diminishing marginal returns) เปรียบได้กับ working memory ที่จำกัดของมนุษย์ ทุก ๆ token ที่ใส่เข้าไปล้วนดึงงบความสนใจของ model ออกไปบางส่วน ดังนั้นเราจึงต้องประหยัด

เป้าหมายของ context engineering

ค้นหา ชุด token ที่มีสัญญาณสูงสุด (high-signal) ที่เล็กที่สุดเท่าที่จะเป็นไปได้ ซึ่งเพิ่มโอกาสให้เกิดผลลัพธ์ที่ต้องการมากที่สุด — ไม่ใช่การยัดทุกอย่างที่อาจเกี่ยวข้องเข้าไปให้มากที่สุด

กายวิภาคของ context ที่ดี

เมื่อยึดหลัก “น้อยแต่มีสัญญาณสูง” แล้ว มาดูว่าองค์ประกอบแต่ละส่วนของ context ควรออกแบบอย่างไร

System prompts

System prompt ควรชัดเจนอย่างที่สุด ใช้ภาษาที่เรียบง่ายและตรงไปตรงมา และอยู่ที่ “ระดับความสูงที่พอเหมาะ” (the right altitude) ซึ่งเป็นจุดสมดุลระหว่างสองความล้มเหลวที่พบบ่อย:

สูงเกินไป (vague): ให้คำแนะนำกว้าง ๆ ระดับนามธรรมจนไม่มีสัญญาณที่จับต้องได้ สมมติเอาว่า model “เข้าใจกันอยู่แล้ว” ทั้งที่จริงมันไม่มี context ร่วมนั้น
ต่ำเกินไป (brittle): ฮาร์ด code ตรรกะ if-else ที่ซับซ้อนและเปราะ พยายามระบุพฤติกรรมที่ต้องการแบบเป๊ะ ๆ สำหรับทุกสถานการณ์ ผลคือดูแลยากขึ้นเรื่อย ๆ และแตกหักง่ายเมื่อเจอกรณีที่ไม่ได้เตรียมไว้

จุดที่เหมาะสมอยู่ตรงกลาง คือ เจาะจงพอที่จะชี้นำพฤติกรรมได้ แต่ยืดหยุ่นพอที่จะให้ heuristic (แนวทางตัดสินใจ) ที่แข็งแรงแก่ model แทนที่จะสั่งทุกฝีก้าว

flowchart LR
  Vague["Too high - vague, overly general"] --- Right["Right altitude - Goldilocks zone"] --- Brittle["Too low - brittle if-else"]

ภาพ 3 — spec ตรัมของ system prompt: ปลายด้านหนึ่งคือ prompt ที่ ต่ำเกินไป (brittle) ฮาร์ด code if-else จนเปราะ อีกด้านคือ prompt ที่ สูงเกินไป (vague) กว้างและนามธรรมจนถือเอาว่า model มี context ร่วมกันอยู่แล้ว ทั้งที่ไม่มี ระดับที่พอเหมาะ (Goldilocks / the right altitude) อยู่ตรงกลาง

เชิงโครงสร้าง แนะนำให้แบ่ง system prompt ออกเป็นส่วน ๆ อย่างชัดเจน เช่น ข้อมูลพื้นหลัง (background), คำสั่ง (instructions), แนวทางการใช้ tool และรูปแบบผลลัพธ์ (output description) โดยใช้ XML tag หรือหัวข้อ Markdown ช่วยจัดระเบียบ

อย่างไรก็ตาม เมื่อ model เก่งขึ้น รูปแบบการจัดวางที่เป๊ะ ๆ ก็สำคัญน้อยลง หัวใจที่แท้จริงคือ ความชัดเจน

หลักการคือมุ่งหา ชุดข้อมูลที่น้อยที่สุดที่ยังอธิบายพฤติกรรมที่คาดหวังได้ครบถ้วน (“น้อยที่สุด” ไม่ได้แปลว่า “สั้น” — เรายังต้องให้ข้อมูลเบื้องต้นที่จำเป็นครบ) วิธีที่ดีคือเริ่มจากขั้นต่ำสุด แล้วค่อย ๆ เติมคำสั่งหรือตัวอย่างเข้าไปตามรูปแบบความล้มเหลว (failure modes) ที่เจอจริง

Tools

Tools คือช่องทางที่ agent ใช้ปฏิสัมพันธ์กับสภาพแวดล้อมและ ดึง context ใหม่ เข้ามา tool ที่ดีจึงควร:

Self-contained — ทำงานได้ครบในตัวเอง
ทนต่อข้อผิดพลาด (robust to error) — จัดการกรณีผิดพลาดได้อย่างมีเหตุผล
ชัดเจนที่สุดว่าใช้ทำอะไร — มีชื่อและ parameter ที่สื่อความหมาย

ปัญหาที่พบบ่อยคือชุด tool ที่ บวม (bloated) และมีหน้าที่ทับซ้อนกัน จนแม้แต่มนุษย์ก็ตอบไม่ได้ว่าควรใช้ตัวไหนในสถานการณ์หนึ่ง ๆ ถ้าวิศวกรที่เป็นคนยังเลือกไม่ถูก ก็อย่าหวังว่า AI agent จะเลือกถูก

กฎง่าย ๆ เรื่อง tools

ถ้าวิศวกรที่เป็นมนุษย์ยังบอกไม่ได้อย่างชัดเจนว่าควรใช้ tool ไหนในกรณีหนึ่ง ๆ AI agent ก็จะบอกไม่ได้เช่นกัน จงคงไว้เพียง ชุด tool ขั้นต่ำที่ใช้งานได้จริง (minimal viable set) ที่หน้าที่ไม่ทับซ้อนกันและกำกวมน้อยที่สุด ซึ่งจะช่วยให้ทั้งดูแลรักษาง่ายและ agent ตัดสินใจถูกขึ้นด้วย

Examples (few-shot prompting)

การให้ตัวอย่าง (examples) หรือ few-shot prompting ยังเป็นแนวปฏิบัติที่ดีเสมอ แต่ข้อควรระวังคือ อย่ายัดรายการ edge case ยาวเหยียดลงไปใน prompt เพราะจะกลายเป็นสัญญาณรบกวนเสียเอง

แทนที่จะทำอย่างนั้น ให้ คัดเลือกตัวอย่างที่หลากหลายและเป็นแบบฉบับ (canonical) จำนวนหนึ่งที่สื่อพฤติกรรมที่คาดหวังได้อย่างมีประสิทธิภาพ สำหรับ LLM แล้ว ตัวอย่างที่ดีหนึ่งตัวอย่างมีค่าเท่ากับคำอธิบายนับพันคำ

โดยรวม ทั้ง system prompt, tools และ examples ล้วนยึดหลักเดียวกัน คือมุ่งไปที่ ชุดที่น้อยที่สุดแต่มีสัญญาณสูงสุด

Context retrieval และ agentic search

แนวทางดั้งเดิมในการเตรียม context คือการ ดึงข้อมูลที่เกี่ยวข้องล่วงหน้า (pre-retrieval) ก่อนการอนุมาน โดยมากใช้การค้นด้วย embedding แบบ RAG (Retrieval-Augmented Generation — ดึงเอกสารที่ใกล้เคียงมาเสริม prompt) แล้วยัดข้อมูลเหล่านั้นเข้า context ตั้งแต่ต้น

แต่กำลังมีการขยับไปสู่กลยุทธ์แบบ “just in time” (ดึงเมื่อถึงเวลาต้องใช้) แทนที่จะประมวลผลข้อมูลที่เกี่ยวข้องทั้งหมดไว้ล่วงหน้า

agent จะเก็บเพียง ข้อมูลอ้างอิงแบบเบา (lightweight identifiers) เช่น path ของ file คิวรีที่บันทึกไว้ หรือ link แล้วค่อย ๆ โหลดข้อมูลเข้า context ตอน runtime ด้วย tool เมื่อจำเป็นจริง ๆ

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

แนวคิดนี้เลียนแบบการรับรู้ของมนุษย์ เราไม่ได้ท่องจำทุกอย่าง แต่พึ่งพาระบบจัดระเบียบภายนอก เช่น ระบบ file บุ๊กมาร์ก หรือดัชนี แล้วค่อยไปเปิดหาเมื่อต้องใช้

ที่สำคัญคือ metadata (ข้อมูลกำกับ file) ก็เป็นสัญญาณ: file ชื่อ test_utils ใน folder tests ให้ความหมายต่างจาก file ชื่อเดียวกันใน folder src/core_logic โครงสร้าง folder ธรรมเนียมการตั้งชื่อ และ timestamp ล้วนบอกใบ้ถึงความเกี่ยวข้องและวิธีใช้งาน

จุดแข็งของแนวทางนี้คือ progressive disclosure (การเปิดเผยทีละขั้น) — agent ค่อย ๆ ค้นพบ context ที่เกี่ยวข้องผ่านการสำรวจ แต่ละปฏิสัมพันธ์ให้ข้อมูลที่ช่วยชี้ก้าวถัดไป และเก็บไว้ใน working memory เพียงเท่าที่จำเป็นในขณะนั้น

flowchart TB
  Choice{How to prepare context}
  subgraph Pre[Pre Retrieval RAG]
    P1[Index all data ahead of time]
    P2[Embed and retrieve relevant chunks]
    P3[Load everything into context before inference]
    P1 --> P2 --> P3
  end
  subgraph JIT[Just in Time]
    J1[Keep lightweight identifiers]
    J2[Agent explores at runtime]
    J3[Load only what is needed now]
    J1 --> J2 --> J3
  end
  Choice --> P1
  Choice --> J1

ภาพ 4 — สองแนวทางเตรียม context: pre-retrieval ดึงและยัดทุกอย่างไว้ก่อนอนุมาน ส่วน just-in-time เก็บแค่ตัวชี้แล้วให้ agent สำรวจและโหลดเฉพาะสิ่งที่ต้องใช้ในขณะนั้น

แน่นอนว่าแนวทาง just-in-time มี ข้อแลกเปลี่ยน: การสำรวจตอน runtime ช้ากว่าการดึงข้อมูลที่คำนวณไว้ล่วงหน้า และต้องออกแบบ tool อย่างพิถีพิถัน หากไม่มีแนวทางกำกับที่ดี agent อาจใช้ tool ผิด หลงทาง หรือถูกดึงความสนใจออกนอกเรื่องได้

ในทางปฏิบัติ ทางออกที่ดีมักเป็น hybrid — ดึงข้อมูลบางส่วนไว้ล่วงหน้าเพื่อความเร็ว ผสมกับการสำรวจแบบ just-in-time

ตัวอย่างเช่น Claude Code จะดึง file อย่าง CLAUDE.md ขึ้นมาไว้ล่วงหน้า ขณะเดียวกันก็ใช้ primitive (คำสั่งพื้นฐาน) อย่าง glob และ grep เพื่อค้นหาและดึงข้อมูลแบบ just-in-time ได้ตลอด ทำให้ไม่ต้องพึ่งดัชนีหรือ syntax tree ที่อาจเก่าเก็บและตกยุค

การออกแบบที่เหมาะสมขึ้นอยู่กับงาน — งานสายกฎหมายหรือการเงินที่ต้องการความครบถ้วนและเร็ว อาจได้ประโยชน์จากการดึงข้อมูลไว้ล่วงหน้ามากกว่า

Context engineering สำหรับงานระยะยาว (long-horizon tasks)

งานระยะยาวที่กินเวลานานหลายนาทีจนถึงหลายชั่วโมง — เช่น การ migrate codebase ขนาดใหญ่ หรือ project วิจัยที่ครอบคลุมกว้าง — ต้องการเทคนิคพิเศษ เพราะเมื่อเวลาผ่านไป ปริมาณข้อมูลจะ ล้นเกิน context window ที่มีอยู่ ต่อไปนี้คือสามเทคนิคหลักในการรักษาความต่อเนื่องข้ามขอบเขตของ context window

1. Compaction (การบีบอัดสรุป)

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

ยกตัวอย่างใน Claude Code เราจะส่งประวัติข้อความให้ model สรุปและบีบอัดรายละเอียดที่สำคัญที่สุดเอาไว้ เช่น การตัดสินใจเชิงสถาปัตยกรรม (architectural decisions) bug ที่ยังแก้ไม่เสร็จ และรายละเอียดการ implement จากนั้นจึงเริ่มต่อด้วย context ใหม่พร้อม file ที่เพิ่งเข้าถึงล่าสุด

ศิลปะของ compaction อยู่ที่ การเลือกว่าจะเก็บอะไรและทิ้งอะไร เพราะการบีบอัดที่ก้าวร้าวเกินไปอาจทำให้สูญเสีย context ที่ดูเล็กน้อยแต่วิกฤต ซึ่งความสำคัญของมันจะเพิ่งมาชัดในภายหลัง

คำแนะนำในการปรับจูน prompt ของ compaction คือ เพิ่ม recall ก่อน (ให้จับทุกชิ้นส่วนที่เกี่ยวข้องไว้ให้ครบ) แล้วจึงค่อย ปรับ precision (ตัดเนื้อหาที่ซ้ำซ้อนหรือเกินจำเป็นออก)

รูปแบบที่ปลอดภัยที่สุดของ compaction คือการ ล้างผลลัพธ์ของ tool (tool result) และการเรียก tool เก่า ๆ ที่ไม่จำเป็นแล้วออก เพราะเนื้อหาเหล่านั้นมักไม่ได้ให้สัญญาณอะไรอีกต่อไป เทคนิคนี้เพิ่งเปิดตัวเป็น feature บน Claude Developer Platform

flowchart LR
  A[Context window near limit]
  B[Summarize critical details]
  C[Discard stale tool results]
  D[Reinitiate fresh context window]
  E[Continue the task]
  A --> B --> C --> D --> E

ภาพ 5 — compaction: เมื่อ context ใกล้เต็ม ให้สรุปรายละเอียดสำคัญ ทิ้งผลลัพธ์ tool ที่ตกยุค แล้วเปิด context window ใหม่เพื่อทำงานต่อโดยไม่ขาดช่วง

2. Structured note-taking (การจดบันทึกแบบมีโครงสร้าง / agentic memory)

Structured note-taking หรือ agentic memory คือการให้ agent เขียนบันทึกอย่างสม่ำเสมอลงในหน่วยความจำที่คงอยู่ นอก context window แล้วดึงกลับเข้ามาใช้ในภายหลัง เทคนิคนี้ให้ ความจำที่คงทน (persistent memory) โดยมี overhead ต่ำ

ด้วยโครงสร้างเรียบง่ายอย่าง to-do list หรือ file NOTES.md เพียง file เดียว agent ก็สามารถติดตามความคืบหน้าและรักษา context ข้ามหลายสิบก้าวได้

ตัวอย่างที่เห็นภาพชัดคือ Claude เล่นเกม Pokémon ที่ต้องเก็บตัวนับสะสม (tally) ต่าง ๆ และแผนที่ความคืบหน้าเอาไว้ เช่น ในช่วง 1,234 ก้าวที่ผ่านมา Claude ฝึก Pikachu อยู่ที่ Route 1 จนได้เลเวลเพิ่มขึ้น 8 เลเวลจากเป้าหมาย 10 เลเวล และยังติดตามสถานะเหล่านี้ได้แม้ context จะถูกรีเซ็ตไปแล้ว

บน Claude Developer Platform ความสามารถนี้เปิดตัวเป็น public beta พร้อมกับการเปิดตัว Sonnet 4.5 ผ่าน memory tool ที่ใช้วิธีจัดเก็บแบบอิง file (file-based) เพื่อให้บันทึกเหล่านี้อยู่คงทนและเรียกกลับมาได้

3. Sub-agent architectures (สถาปัตยกรรมแบบ agent ย่อย)

แทนที่จะให้ agent ตัวเดียวพยายามแบก state ของทั้ง project ไว้ทั้งหมด เราสามารถให้ specialized sub-agents รับผิดชอบงานเฉพาะจุด โดยแต่ละตัวมี context window ที่สะอาด เป็นของตัวเอง

กลไกคือ agent หลัก (lead / orchestrator) ถือแผนระดับสูงและคอยประสานงาน ส่วน sub-agent แต่ละตัวลงลึกทำงานเชิงเทคนิคหรือใช้ tool ค้นหาข้อมูลอย่างเข้มข้น

แต่ละ sub-agent อาจใช้ token นับหมื่นในการสำรวจ ทว่า คืนกลับมาให้ agent หลักเพียงบทสรุปที่กลั่นแล้วอย่างกระชับ (ราว 1,000 ถึง 2,000 token) ของงานที่ทำ

ผลคือ การแยกความรับผิดชอบ (separation of concerns) อย่างชัดเจน — รายละเอียดของการค้นหาถูกกักไว้ภายใน sub-agent ส่วน agent หลักโฟกัสที่การสังเคราะห์และวิเคราะห์ภาพรวม

งานวิจัยเรื่อง “How we built our multi-agent research system” ของ Anthropic แสดงให้เห็นว่าสถาปัตยกรรมแบบนี้ให้ผลดีขึ้นอย่างมีนัยสำคัญเมื่อเทียบกับ agent เดี่ยวในงานวิจัยที่ซับซ้อน

flowchart TB
  Lead[Lead Agent keeps high level plan]
  S1[Subagent A focused work]
  S2[Subagent B focused work]
  S3[Subagent C focused work]
  R1[Condensed summary]
  R2[Condensed summary]
  R3[Condensed summary]
  Synth[Lead synthesizes results]
  Lead --> S1
  Lead --> S2
  Lead --> S3
  S1 --> R1
  S2 --> R2
  S3 --> R3
  R1 --> Synth
  R2 --> Synth
  R3 --> Synth

ภาพ 6 — สถาปัตยกรรม sub-agent: agent หลักถือแผนระดับสูง กระจายงานให้ sub-agent ที่มี context สะอาดของตัวเองไปสำรวจเชิงลึก แล้วรับกลับมาเพียงบทสรุปที่กลั่นแล้วเพื่อนำมาสังเคราะห์

จะเลือกเทคนิคไหน

การเลือกขึ้นอยู่กับลักษณะของงาน:

Compaction เหมาะกับงานที่ต้องการความต่อเนื่องของบทสนทนาแบบไปกลับ (back-and-forth)
Structured note-taking เหมาะกับงานพัฒนาแบบวนซ้ำที่มีหมุดหมาย (milestones) ชัดเจน
Sub-agent architectures เหมาะกับงานที่ต้องสำรวจหลายทิศทางแบบขนาน (parallel exploration)

บทสรุป

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

ไม่ว่าจะผ่าน compaction, structured note-taking, sub-agent หรือการดึงข้อมูลแบบ just-in-time หลักการเบื้องหลังล้วนเป็นหนึ่งเดียวกัน นั่นคือ ค้นหาชุด token ที่มีสัญญาณสูงสุดที่เล็กที่สุดเท่าที่จะเป็นไปได้

เทคนิคเฉพาะจะเปลี่ยนไปตามความก้าวหน้าของ model แต่แม้ model จะฉลาดขึ้นและทำงานได้อิสระมากขึ้นเพียงใด การมอง context เป็นทรัพยากรที่มีจำกัด จะยังคงเป็นแก่นกลางของการสร้าง agent ที่เก่งและเชื่อถือได้เสมอ

อ่านต่อในไซต์นี้

หัวข้อนี้เชื่อมโยงกับบทความอื่นในหมวดบทความ เช่น ทำความเข้าใจ Spec-Driven Development และ Structured-Prompt-Driven Development (SPDD) ที่ว่าด้วยการจัดการ context และ prompt ให้เป็นชิ้นงานชั้นหนึ่งของกระบวนการพัฒนา

และเชื่อมโยงกับหลักการออกแบบอย่าง KISS, YAGNI และ Separation of Concerns ที่สะท้อนแนวคิด “น้อยแต่มีสัญญาณสูง” ในบริบทของ code

📄 อ่านต้นฉบับภาษาอังกฤษ: Effective context engineering for AI agents — ทีม Applied AI ของ Anthropic, Anthropic Engineering (29 กันยายน 2025)

Context Engineering ที่​ได้​ผล​สำหรับ AI Agents

Context engineering เทียบ​กับ prompt engineering

ทำไม context engineering จึง​สำคัญ​ต่อ​การ​สร้าง agent ที่​เก่ง

กายวิภาค​ของ context ที่​ดี