เอเจนต์ AI ของคุณทำงานได้ดีใน 10 ขั้นตอนแรก
จากนั้นที่ประมาณขั้นตอนที่ 15 มันก็เริ่มทำงานสะเพร่า
เรียกใช้เครื่องมือผิดพลาด ลืมคำสั่งดั้งเดิมของคุณ ผลลัพธ์คุณภาพต่ำ
คนส่วนใหญ่โทษว่าเป็นความผิดของโมเดล
แต่แทบจะไม่เคยเป็นที่โมเดลเลย
สิ่งที่เป็นปัญหาคือสิ่งที่โมเดลมองเห็น
การจัดระเบียบสิ่งที่โมเดลมองเห็น เรียกว่า context engineering (วิศวกรรมบริบท)
มันกำลังกลายเป็นทักษะที่สำคัญที่สุดสำหรับใครก็ตามที่กำลังสร้างเอเจนต์ AI อย่างรวดเร็ว
นี่คือคู่มือฉบับสมบูรณ์
Prompt engineering ตายแล้ว Context engineering คือสิ่งที่สำคัญในตอนนี้
คุณคงเคยได้ยินเกี่ยวกับ prompt engineering
การเขียนคำสั่งที่ชัดเจน ตัวอย่างที่ดี บอกโมเดลว่าต้องรับบทบาทอะไร
วิธีนั้นใช้ได้ผลดีสำหรับแชทบอท
แต่มันจะใช้ไม่ได้ผลทันทีที่คุณเริ่มสร้างเอเจนต์
นี่คือเหตุผล
แชทบอทตอบคำถามหนึ่งข้อแล้วหยุด
เอเจนต์ลงมือทำ — ท่องเว็บ, เรียก API, เขียนโค้ด, รันคำสั่ง — ทีละขั้น ทีละขั้น บางครั้งก็หลายสิบขั้นตอน
ทุกๆ ขั้นตอนจะสร้างผลลัพธ์ที่ถูกเพิ่มเข้าไปในบริบทของโมเดล
และบริบทนั้นมีจำกัด
ทีมวิศวกรของ Anthropic นิยามมันไว้แบบนี้:
"บริบทคือชุดของโทเค็นที่รวมอยู่เมื่อคุณสุ่มตัวอย่างจาก LLM Context engineering คือการปรับปรุงประโยชน์ของโทเค็นเหล่านั้นเพื่อให้ได้ผลลัพธ์ตามที่ต้องการอย่างสม่ำเสมอ"
พูดง่ายๆ คือ: ทำให้แน่ใจว่าเอเจนต์ของคุณเห็นข้อมูลที่ถูกต้อง ในรูปแบบที่ถูกต้อง ในเวลาที่ถูกต้อง
Prompt engineering เป็นเพียงส่วนย่อยของ context engineering
Context engineering คือทุกสิ่งทุกอย่าง
หน้าต่างบริบทของเอเจนต์คือ RAM และมันกำลังเต็ม
LangChain มีการเปรียบเทียบที่ถูกต้องสำหรับเรื่องนี้
ลองนึกถึง LLM เหมือนระบบปฏิบัติการรูปแบบใหม่
โมเดลคือ CPU — มันทำหน้าที่คิด
หน้าต่างบริบทคือ RAM — หน่วยความจำทำงานที่เก็บทุกสิ่งที่โมเดลสามารถมองเห็นและใช้เหตุผลได้ในขณะนั้น
เหมือนกับที่คอมพิวเตอร์ของคุณช้าลงเมื่อ RAM เต็ม การใช้เหตุผลของเอเจนต์ก็จะเสื่อมลงเมื่อหน้าต่างบริบทแออัด
สิ่งนี้เรียกว่า context rot (บริบทเสื่อม)
Chroma ทำการศึกษาประเมินโมเดลชั้นนำ 18 รุ่น — GPT-4.1, Claude 4, Gemini 2.5, Qwen3 และอื่นๆ
ทุกโมเดลมีประสิทธิภาพลดลงเมื่อความยาวอินพุตเพิ่มขึ้น
ไม่ใช่ที่ขีดจำกัดสูงสุด แต่ก่อนหน้านั้นมาก
โมเดลที่มีหน้าต่าง 200K โทเค็น อาจแสดงประสิทธิภาพลดลงอย่างมีนัยสำคัญที่ 50K โทเค็น
การลดลงเป็นไปอย่างต่อเนื่อง ไม่ใช่การตกกระทันหัน
ทำไม? Transformer ทำงานโดยให้ทุกโทเค็นสนใจโทเค็นอื่นๆ ทั้งหมด — สร้างความสัมพันธ์แบบ n-squared เมื่องบริบทเพิ่มขึ้น ความสามารถของโมเดลในการรักษาความสัมพันธ์ทั้งหมดนั้นก็จะบางลง
แล้วก็มีปัญหา "Lost in the Middle" (หายไปตรงกลาง)
LLM แสดงเส้นโค้งความสนใจรูปตัว U
→ จุดเริ่มต้นของบริบท: จดจำได้ดี
→ จุดสิ้นสุดของบริบท: จดจำได้ดี
→ ตรงกลาง: ส่วนใหญ่จะถูกละเลย
นักวิจัยวัดความแม่นยำลดลงมากกว่า 30 เปอร์เซ็นต์เมื่อข้อมูลที่เกี่ยวข้องย้ายจากจุดเริ่มต้นบริบทไปอยู่ตรงกลาง
คำสั่งดั้งเดิมของคุณ — ถูกฝังอยู่ภายใต้ผลลัพธ์ของเครื่องมือ 50,000 โทเค็น — จะหายไปโดยสิ้นเชิง
ผู้ใช้ Claude Code พบว่าคุณภาพผลลัพธ์ลดลงที่ 40–60% ของความจุบริบท ก่อนถึงขีดจำกัดสูงสุดเสียอีก
อะไรบ้างที่แย่งชิงพื้นที่ในบริบทของเอเจนต์คุณ
7 หมวดหมู่ ทั้งหมดแย่งชิงหน้าต่างที่มีจำกัดเดียวกัน
1. System Prompt (พรอมต์ระบบ)
ตัวตนของเอเจนต์ กฎพฤติกรรม ตรรกะควบคุมการทำงาน คำแนะนำสำหรับงานประเภทต่างๆ ในเอเจนต์ นี่ไม่ใช่แค่ "จงมีประโยชน์" แต่มันสามารถกำหนดสถาปัตยกรรมทั้งหมดได้
2. Tool Definitions (คำจำกัดความของเครื่องมือ)
ทุกเครื่องมือที่เอเจนต์สามารถเรียกใช้ได้ ต้องมี Schema ที่อธิบายว่ามันทำอะไร พารามิเตอร์อะไรบ้าง และควรใช้เมื่อไหร่
3. Tool Call Results (ผลลัพธ์การเรียกใช้เครื่องมือ)
ทุกครั้งที่เรียกใช้เครื่องมือ จะเพิ่มผลลัพธ์เข้าไปในบริบท การดึงข้อมูลหน้าเว็บ: 5,000–10,000 โทเค็น การอ่านไฟล์: คล้ายกัน สิ่งเหล่านี้สะสมอย่างรวดเร็ว
4. Retrieved Knowledge (RAG) (ความรู้ที่ดึงมา)
เอกสารที่ดึงมาจากฐานข้อมูลเวกเตอร์ ผลการค้นหา การตอบสนองจาก API — อะไรก็ตามที่ถูกดึงมาเพื่อประกอบการตัดสินใจของเอเจนต์
5. Conversation History (ประวัติการสนทนา)
บันทึกการสนทนาทั้งหมดที่เกิดขึ้น ข้อความผู้ใช้ การตอบสนองของเอเจนต์ การใช้เหตุผล การตัดสินใจที่ผ่านมา เพิ่มขึ้นเป็นเส้นตรงทุกครั้งที่มีการโต้ตอบ
6. Memory (ความจำ)
ความจำระยะสั้นจากเซสชันปัจจุบัน ความจำระยะยาวจากเซสชันก่อนหน้า — ความชอบของผู้ใช้ ผลลัพธ์ที่ผ่านมา รูปแบบที่เรียนรู้
7. Agent State (สถานะเอเจนต์)
แผนปัจจุบัน รายการสิ่งที่ต้องทำ ตัวชี้วัดความคืบหน้า บันทึกช่วยคิด ข้อมูลเมตาที่ติดตามว่าเอเจนต์อยู่ที่ไหนในงานหลายขั้นตอน
ทั้งหมด 7 หมวดหมู่แย่งชิงหน้าต่างเดียวกัน
Context engineering คือการตัดสินใจว่าอะไรจะชนะ
4 กลยุทธ์หลัก
LangChain ตีพิมพ์กรอบแนวคิดที่จัดระเบียบเทคนิค context engineering ทั้งหมดออกเป็น 4 กลุ่ม
ทุกเทคนิคที่คุณจะได้เรียนรู้จะอยู่ในหนึ่งในกลุ่มนี้
Write (เขียน). Select (เลือก). Compress (บีบอัด). Isolate (แยก)
กลยุทธ์ที่ 1 — Write (เขียน) (เอเจนต์ลืม ให้วิธีจดจำแก่พวกเขา)
เมื่อบริบทของเอเจนต์เต็มและถูกบีบอัด มันจะสูญเสียข้อมูล
ถ้าเอเจนต์ไม่ได้เขียนอะไรลงไปก่อนที่สิ่งนั้นจะเกิดขึ้น — ข้อมูลนั้นจะหายไปตลอดกาล
Write (เขียน) หมายถึงการให้วิธีแก่เอเจนต์ในการเก็บข้อมูลไว้ภายนอกหน้าต่างบริบท
สามรูปแบบ:
Scratchpads (กระดาษทด)
ให้เครื่องมือแก่เอเจนต์ที่ให้มันจดบันทึกระหว่างทำงาน ผลการค้นหาในระหว่างทาง การตัดสินใจที่ทำ ข้อมูลที่มันรู้ว่ามันจะต้องใช้ในภายหลัง
Anthropic สร้างเครื่องมือ "think" (คิด) — พื้นที่เฉพาะสำหรับให้ Claude ทำงานผ่านปัญหา
ในการทดสอบเกณฑ์ชี้วัด tau-bench สิ่งนี้ช่วยปรับปรุงประสิทธิภาพได้ถึง 54% ในบางงาน
Rules Files (ไฟล์กฎ)
หน่วยความจำขั้นตอนการทำงานแบบถาวร
ถ้าคุณเคยใช้ Claude Code คุณจะเคยเห็น CLAUDE.md
คำแนะนำที่โหลดทุกครั้งที่เริ่มเซสชัน — สถาปัตยกรรมโปรเจกต์ ธรรมเนียมปฏิบัติ วิธีรันเทส สิ่งที่ต้องระวัง
เอเจนต์อ่านมันทุกครั้งที่เริ่มทำงาน
มันไม่มีวันลืมพื้นฐาน
Memory Extraction (การดึงความจำ)
เอเจนต์บันทึกข้อเท็จจริง ความชอบของผู้ใช้ และรูปแบบที่เรียนรู้ เพื่อให้สามารถดึงข้อมูลเหล่านั้นกลับมาใช้ได้ในเซสชันอื่น
อยู่ภายนอกหน้าต่างบริบทโดยสิ้นเชิง
ข้อมูลที่เอเจนต์ต้องการในวันพรุ่งนี้กำลังรออยู่เมื่อพรุ่งนี้มาถึง
กลยุทธ์ที่ 2 — Select (เลือก) (อย่าให้ทุกอย่างแก่เอเจนต์ ให้สิ่งที่มันต้องการในตอนนี้)
เอเจนต์ที่มี 40 เครื่องมือ ฐานความรู้ขนาดใหญ่ และประวัติหลายเซสชัน ไม่สามารถโหลดทั้งหมดนั้นพร้อมกันได้
ต้องมีอะไรสักอย่างที่ตัดสินใจว่าสิ่งใดเกี่ยวข้องสำหรับขั้นตอนนี้
Traditional RAG (RAG แบบดั้งเดิม): ระบบเป็นผู้ตัดสินใจ
ผู้ใช้ถาม → ดึงเอกสาร → ยัดเข้าไปในพรอมต์ → เสร็จ
คงที่ ทำครั้งเดียว โมเดลไม่มีสิทธิ์พูด
Agentic RAG (RAG แบบเอเจนต์): เอเจนต์เป็นผู้ตัดสินใจ มันค้นหาสิ่งที่ต้องการ ปรับแต่งคำค้น เลือกเครื่องมือ กำหนดว่าเมื่อไหร่มีข้อมูลเพียงพอ
การดึงข้อมูลเป็นกระบวนการวนซ้ำ ไม่ใช่ท่อส่งครั้งเดียว
เรื่องนี้สำคัญเพราะสิ่งที่เกี่ยวข้องเปลี่ยนแปลงไปในทุกขั้นตอน — และมีเพียงเอเจนต์เท่านั้นที่รู้ว่ามันต้องการอะไรต่อไป
ปัญหาเรื่องการเลือกเครื่องมือคือสิ่งที่ทำให้คนส่วนใหญ่สะดุดมากที่สุด
ถ้าเอเจนต์ของคุณมี 40+ เครื่องมือ นั่นอาจหมายถึงคำจำกัดความของเครื่องมือ 10,000 โทเค็นที่นั่งอยู่ในบริบทก่อนที่จะเริ่มทำงานใดๆ
วิธีแก้ไข: RAG เหนือคำอธิบายเครื่องมือ
แทนที่จะทิ้งคำจำกัดความของเครื่องมือทั้งหมดไว้ทุกครั้งที่เรียกใช้ ให้ใช้การค้นหาแบบ semantic search เพื่อแสดงเฉพาะเครื่องมือที่เกี่ยวข้องกับขั้นตอนปัจจุบัน
งานวิจัยชื่อ RAG-MCP ทดสอบสิ่งนี้
ความแม่นยำในการเลือกเครื่องมือ: 14% → 43% (ดีขึ้น 3 เท่า) การใช้โทเค็น: ลดลงประมาณครึ่งหนึ่ง
Anthropic เรียกมันว่า hybrid strategy (กลยุทธ์แบบผสม): โหลดบริบทที่จำเป็นล่วงหน้า (เช่น CLAUDE.md) ให้เอเจนต์ดึงข้อมูลแบบทันเวลาพอดี (just-in-time) สำหรับสิ่งอื่นๆ
โหลดพื้นฐานล่วงหน้า ดึงข้อมูลที่เหลือตามความต้องการ
กลยุทธ์ที่ 3 — Compress (บีบอัด) (บริบทสะสม เก็บความหมายไว้ ตัดโทเค็นทิ้ง)
แม้จะมีการเลือกที่ดีแล้ว บริบทก็ยังคงสะสม
ทุกการเรียกใช้เครื่องมือ เอกสารที่ดึงมา และการตัดสินใจ ยังคงอยู่ในหน้าต่าง
ลองนึกภาพว่าเอเจนต์ของคุณเรียกใช้เครื่องมือไป 20 ครั้ง
บริบท: 80,000 โทเค็นของผลลัพธ์เครื่องมือที่สะสม ประวัติการสนทนา ร่องรอยการใช้เหตุผล
ส่วนใหญ่ไม่เกี่ยวข้องอีกต่อไปแล้ว เอเจนต์ได้ดำเนินการกับมันไปแล้ว
แต่มันก็ยังอยู่ตรงนั้น ใช้พื้นที่ ทำให้ความสนใจลดลง เพิ่มต้นทุนและความหน่วง
คุณสามารถบีบอัดได้ 3 จุด
ก่อนที่ข้อมูลจะเข้าสู่บริบท:
→ ตัดเอกสารขนาดใหญ่ออกเป็นชิ้นๆ ที่สอดคล้องกันก่อนดึงข้อมูล
→ จัดลำดับใหม่ (Rerank) เพื่อให้เฉพาะชิ้นส่วนที่มีประโยชน์ที่สุดเข้าไปได้
→ สรุปผลลัพธ์ของเครื่องมือแบบทันที (on the fly) ก่อนที่มันจะเข้าสู่บริบทหลัก
ในขณะที่เอเจนต์กำลังทำงาน:
→ สรุปแบบหมุนเวียน (Rolling summary) ของประวัติการสนทนา — อัปเดตอย่างต่อเนื่อง
→ วิธีผสมที่นิยม: เก็บ 10 ข้อความล่าสุดตามตัวอักษร + สรุปทุกอย่างที่เก่ากว่านั้น
→ การตัดทอนแบบแข็ง (Hard trimming): ลบข้อความเก่าๆ เมื่อบริบทถึงเกณฑ์ขนาดที่กำหนด
→ การบีบอัดอัตโนมัติของ Claude Code: เริ่มทำงานที่ความจุ 95% สรุปร่องรอยทั้งหมดโดยอัตโนมัติ
หลังจากที่เอเจนต์ได้ดำเนินการกับบางสิ่งแล้ว:
→ การล้างผลลัพธ์เครื่องมือ: เมื่อผลลัพธ์เครื่องมือถูกใช้ไปแล้ว 15 ขั้นตอนที่แล้ว ให้ทิ้งมัน
→ แทนที่ด้วยสรุปหนึ่งบรรทัดหรือลบออกทั้งหมด
→ เอเจนต์ไม่ต้องการข้อความเต็มของหน้าเว็บที่มันดึงมาเมื่อ 20 ขั้นตอนที่แล้ว
เป้าหมาย: ลดจำนวนโทเค็น รักษาสิ่งที่สำคัญจริงๆ
กลยุทธ์ที่ 4 — Isolate (แยก) (กลยุทธ์ที่ทรงพลังที่สุด ทำให้ระบบหลายเอเจนต์เป็นไปได้)
นี่คือปัญหาที่ลึกกว่านั้นเกี่ยวกับการทำงานของเอเจนต์ที่ยาวนาน
มันไม่ใช่แค่เรื่องพื้นที่ มันคือการปนเปื้อน
การค้นหาไฟล์อย่างละเอียดจากช่วงการวิจัย (research phase) ยังคงอยู่ในบริบทเมื่อเอเจนต์ย้ายไปเขียนโค้ด
บริบทการวิจัยเก่านั้นกลายเป็นสัญญาณรบกวน มันเบี่ยงเบนความสนใจของโมเดลในช่วงที่มันต้องจดจ่อกับการใช้งานที่สะอาด
Isolation (การแยก) หมายถึงการให้ส่วนต่างๆ ของงานมีหน้าต่างบริบทแยกกันของตัวเอง
Sub-agents (เอเจนต์ย่อย)
เอเจนต์หลัก (Parent agent) มอบหมายงานย่อยที่เน้นเฉพาะ — "ค้นหาโค้ดเบสเพื่อหาไฟล์ที่เกี่ยวข้องกับการรับรองความถูกต้องทั้งหมด" — ให้กับเอเจนต์ย่อย (Sub-agent)
เอเจนต์ย่อยทำงานในหน้าต่างบริบทที่สะอาดของตัวเอง
เมื่อมันรายงานกลับ มันจะคืนเฉพาะสรุปที่ condensed ( condensed summary)
การดำเนินการค้นหาที่ยุ่งเหยิงทั้งหมดจะถูกแยกไว้ในบริบทของเอเจนต์ย่อยและไม่เคยปนเปื้อนเอเจนต์หลัก
การแยก State schema (State schema isolation) (แนวทางของ LangGraph)
ออกแบบสถานะของเอเจนต์เพื่อให้ฟิลด์ต่างๆ จัดเก็บบริบทประเภทต่างๆ
LLM จะเห็นเฉพาะฟิลด์ที่เกี่ยวข้องกับขั้นตอนปัจจุบัน
ผลลัพธ์ของเครื่องมืออยู่ในฟิลด์ "หลังเวที" (backstage) — มองไม่เห็นโดยโมเดลจนกว่าจะถูกนำขึ้นมาแสดงอย่างชัดเจน
ควบคุมอย่างละเอียดว่าเอเจนต์เห็นอะไรในแต่ละขั้นตอน โดยไม่ต้องสร้างเอเจนต์ย่อยแยกต่างหาก
Isolation (การแยก) คือสิ่งที่ทำให้ขั้นตอนการทำงานหลายขั้นตอนที่ซับซ้อนเชื่อถือได้จริงๆ
งานที่แตกต่าง หน้าต่างบริบทที่แตกต่าง ไม่มีการปนเปื้อน
4 วิธีที่เอเจนต์ล้มเหลว (ระบุความล้มเหลว แก้ไขมัน)
Drew Breunig ระบุรูปแบบความล้มเหลวที่แตกต่างกันสี่รูปแบบเมื่อบริบทของเอเจนต์เติบโตขึ้น
เอเจนต์ที่พังทุกตัวที่คุณเคยเห็นจะตกอยู่ในรูปแบบใดรูปแบบหนึ่งเหล่านี้
ความล้มเหลวที่ 1: Context Poisoning (บริบทเป็นพิษ)
ภาพหลอน (Hallucination) หรือข้อผิดพลาดเข้าสู่บริบท
เอเจนต์อ้างอิงถึงมันซ้ำแล้วซ้ำอีกในขั้นตอนต่อๆ ไป
ข้อมูลที่ไม่ดีจากขั้นตอนที่ 5 ส่งผลต่อทุกขั้นตอนหลังจากนั้น
วิธีแก้ไข: ตรวจสอบความถูกต้องของผลลัพธ์เครื่องมือก่อนที่มันจะเข้าสู่บริบท หลังจากกู้คืนจากข้อผิดพลาดแล้ว ให้บีบอัดประวัติของความพยายามที่ล้มเหลว อย่าปล่อยให้ประวัติการดีบักที่ไปไม่ถึงไหน 10 ขั้นตอนยังคงมองเห็นได้เมื่อมีเพียงวิธีแก้ปัญหาเท่านั้นที่สำคัญ
━━━
ความล้มเหลวที่ 2: Context Distraction (บริบททำให้ไขว้เขว)
บริบทยาวนานจนโมเดลเริ่มพึ่งพาประวัติล่าสุดมากเกินไป
แทนที่จะสังเคราะห์แผนใหม่ มันก็แค่พูดซ้ำสิ่งที่มันเพิ่งทำไป
มันหยุดคิด มันเริ่มทำซ้ำ
วิธีแก้ไข: สรุปและตัดทอนอย่างจริงจัง แม้ว่าคุณจะมีหน้าต่างบริบทขนาดใหญ่ก็ตาม หน้าต่างใหญ่ไม่ได้หมายความว่าจะต้องเติมให้เต็ม
━━━
ความล้มเหลวที่ 3: Context Confusion (บริบททำให้สับสน)
เนื้อหาที่เกินความจำเป็นนำไปสู่การตัดสินใจคุณภาพต่ำของโมเดล
ตัวอย่างคลาสสิก: โมเดลล้มเหลวในการทดสอบเกณฑ์ชี้วัดเมื่อได้รับ 46 เครื่องมือ — ทั้งที่บริบทนั้นอยู่ในขีดจำกัด — แต่ทำงานได้ดีเมื่อมีเพียง 19 เครื่องมือ
เครื่องมือไม่ได้มากเกินไปสำหรับบริบทที่จะเก็บไว้
แต่มันมากเกินไปสำหรับโมเดลที่จะใช้เหตุผลได้อย่างชัดเจน
วิธีแก้ไข: การจัดการเครื่องมือแบบไดนามิก ใช้ RAG-MCP เพื่อแสดงเฉพาะเครื่องมือที่เกี่ยวข้องกับขั้นตอนปัจจุบัน ทำให้ชุดเครื่องมือตรงกับเฟสปัจจุบัน
━━━
ความล้มเหลวที่ 4: Context Clash (บริบทขัดแย้ง)
ข้อมูลใหม่ขัดแย้งกับสิ่งที่มีอยู่ในบริบทแล้ว
System prompt พูดอย่างหนึ่ง เอกสารที่ดึงมาพูดอีกอย่างหนึ่ง
เอเจนต์ไม่สามารถประนีประนอมความขัดแย้งได้ ทำให้เกิดพฤติกรรมที่ไม่สอดคล้องกัน
วิธีแก้ไข: สร้างลำดับอำนาจที่ชัดเจน System prompt > ข้อเท็จจริงที่ดึงมา > ประวัติการสนทนา ตรวจสอบข้อมูลใหม่กับบริบทที่มีอยู่ก่อนที่จะแทรกเข้าไป ใช้แท็ก XML และส่วนหัวที่ชัดเจนเพื่อให้โมเดลรู้ว่าควรเชื่อถือแหล่งข้อมูลใด
วิธีเขียน System Prompts สำหรับเอเจนต์ (ไม่ใช่แชทบอท แต่เป็นเอเจนต์)
System prompt ของแชทบอทกำหนดน้ำเสียง
"คุณคือผู้ช่วยที่มีประโยชน์ จงกระชับและเป็นมิตร"
System prompt ของเอเจนต์กำหนดสถาปัตยกรรม
มันระบุการควบคุมการไหล — วิธีจัดการกับงานประเภทต่างๆ ควรใช้เครื่องมือใดเมื่อไหร่ จะทำอย่างไรเมื่อเกิดข้อผิดพลาด มีแนวป้องกันอะไรบ้าง
มันใกล้เคียงกับการเขียนรายละเอียดงานสำหรับพนักงานอิสระ มากกว่าพรอมต์ที่กำหนดบุคลิก
Anthropic เรียกมันว่าการเขียนใน "ระดับความสูงที่เหมาะสม" (right altitude)
เจาะจงเกินไป: "ถ้าผู้ใช้พูดถึงการเรียกเก็บเงิน และพูดถึงการคืนเงิน และจำนวนเงินมากกว่า $100 ให้เรียกใช้เครื่องมือ X" เปราะบาง พังในทุกกรณีขอบที่คุณไม่ได้คาดคิด
คลุมเครือเกินไป: "จงมีประโยชน์และใช้เครื่องมือที่เหมาะสม" ไม่ได้ให้อะไรกับเอเจนต์เลย มันไม่สามารถตัดสินใจอย่างอิสระที่ดีได้หากไม่มีสัญญาณที่เป็นรูปธรรม
จุดที่ลงตัว: เจาะจงพอที่จะชี้แนะพฤติกรรมอิสระ ยืดหยุ่นพอให้โมเดลใช้ดุลยพินิจในสถานการณ์ใหม่ๆ กฎฮิวริสติกที่แข็งแกร่ง ไม่ใช่กฎที่ตายตัว
เคล็ดลับที่ใช้ได้จริง:
→ จัดระเบียบด้วยแท็ก XML หรือส่วนหัว markdown — Background, Instructions, Tool Guidance
→ เริ่มจากน้อยที่สุดและปรับปรุงจากความล้มเหลว — อย่าพยายามคาดการณ์ทุกกรณีขอบล่วงหน้า
→ น้อยที่สุดไม่ได้แปลว่าสั้น — system prompt ของเอเจนต์ที่ซับซ้อนสามารถมีหลายพันโทเค็น และนั่นก็โอเค ตราบใดที่ทุกโทเค็นสมควรได้รับที่ของมัน
→ ใช้ตัวอย่างแบบ few-shot — แสดงให้เอเจนต์เห็นว่าพฤติกรรมที่ดีเป็นอย่างไร แทนที่จะพยายามอธิบายทุกกฎเป็นคำพูด
KV-Cache: เหตุผล $$$ ที่ต้องใส่ใจลำดับบริบท
ผู้สร้างเอเจนต์ส่วนใหญ่ไม่รู้ว่าสิ่งนี้มีอยู่
เมื่อคุณส่งโทเค็นไปยัง LLM โมเดลจะคำนวณค่า key-value representation สำหรับแต่ละโทเค็น
มีค่าใช้จ่ายในการคำนวณสูง
ดังนั้นผู้ให้บริการ inference จึงแคชค่าเหล่านี้ไว้
ถ้าจุดเริ่มต้นของบริบทของคุณ — คำนำ (prefix) — เหมือนเดิมระหว่างการเรียกใช้ API ผู้ให้บริการจะนำการคำนวณที่แคชไว้กลับมาใช้ใหม่ และประมวลผลเฉพาะโทเค็นใหม่ที่ส่วนท้าย
รวดเร็ว ราคาถูก
แต่ถ้าคุณจัดเรียงหรือเปลี่ยนแปลงส่วนต้นของบริบทระหว่างการเรียกใช้ — คุณจะทำให้แคชใช้ไม่ได้ ผู้ให้บริการจะคำนวณทุกอย่างใหม่ตั้งแต่ต้น
ความแตกต่างของต้นทุนบน Claude Sonnet:
→ โทเค็นอินพุตที่แคชไว้: $0.30 ต่อล้าน
→ โทเค็นอินพุตที่ไม่ได้แคช: $3.00 ต่อล้าน
ต่างกัน 10 เท่า
สำหรับเอเจนต์ที่เรียกใช้ API 30–40 ครั้งต่องาน สิ่งนี้เพิ่มขึ้นอย่างรวดเร็ว
กฎที่ใช้ได้จริงเพื่อประสิทธิภาพของ KV-cache:
→ เนื้อหาที่คงที่ (Stable content) ไปไว้ที่ TOP ของบริบท — system prompt, คำจำกัดความของเครื่องมือ, อะไรก็ตามที่ไม่เปลี่ยนแปลงระหว่างรอบ
→ เนื้อหาแบบไดนามิก (Dynamic content) ไปไว้ที่ BOTTOM — ประวัติการสนทนา, ขั้นตอนปัจจุบัน, สถานะเอเจนต์
→ อย่าเพิ่มและลบเครื่องมือแบบไดนามิกระหว่างการสนทนา — มันทำให้แคชใช้ไม่ได้
→ ใช้ tool masking (การปิดบังเครื่องมือ) แทนการลบเครื่องมือ — เก็บคำจำกัดความของเครื่องมือทั้งหมดให้คงที่ในคำนำ (แคชไว้) เพียงแค่ทำเครื่องหมายว่าอันที่ไม่เกี่ยวข้องว่าไม่พร้อมใช้งานสำหรับเฟสปัจจุบัน
ขั้นตอนการทำงานที่ส่งโค้ด 35,000 บรรทัดใน 7 ชั่วโมง
Dex Horthy (CEO ของ HumanLayer) นำเสนอสิ่งนี้ในงาน AI Engineer Code Summit
ทีมของเขารายงานว่าใช้มันเพื่อส่งโค้ด ~35,000 บรรทัดไปยังโค้ดเบส Rust ขนาดใหญ่ในเซสชัน 7 ชั่วโมงเดียว
วิธีการ: Frequent Intentional Compaction (การบีบอัดโดยตั้งใจบ่อยครั้ง)
จัดโครงสร้างงานของเอเจนต์เป็นเฟส แต่ละเฟสสร้างอาร์ติแฟกต์ที่บีบอัดแล้ว แต่ละเฟสใหม่เริ่มต้นด้วยหน้าต่างบริบทใหม่ที่มีเฉพาะอาร์ติแฟกต์นั้น
คงให้ต่ำกว่า 40–60% ของหน้าต่างบริบทอยู่เสมอ
เฟสที่ 1 — Research (วิจัย)
เอเจนต์ย่อยสำรวจโค้ดเบส อ่านไฟล์ ติดตามการไหลของข้อมูล จัดแผนที่สถาปัตยกรรม
ผลลัพธ์ grep ที่ยุ่งเหยิงและเนื้อหาไฟล์ทั้งหมดจะอยู่ในบริบทของเอเจนต์ย่อย ไม่เคยแตะต้องเอเจนต์หลัก (Isolate / แยก)
ผลลัพธ์: research.md ที่บีบอัด — path ของไฟล์, ลายเซ็นฟังก์ชัน, รูปแบบ, ข้อควรระวัง (Write / เขียน)
รีเซ็ตบริบท: งานวิจัยดิบใช้ 60–80% ของหน้าต่าง อาร์ติแฟกต์การวิจัยบีบอัดมันลงเหลือ 15–20% (Compress / บีบอัด)
เฟสที่ 2 — Planning (วางแผน)
หน้าต่างบริบทใหม่ มีเพียง: เอกสารวิจัย + คำจำกัดความของปัญหา
เอเจนต์สร้างแผนการใช้งานโดยละเอียด
นี่คือจุดตรวจสอบที่สำคัญที่สุดที่มนุษย์ต้องตรวจสอบ
จับข้อผิดพลาดทางตรรกะที่นี่ ซึ่งการแก้ไขทำได้ง่ายและฟรี ภายหลังมันจะเสียเวลาหลายชั่วโมง
เฟสที่ 3 — Implementation (นำไปใช้)
หน้าต่างบริบทใหม่ที่สะอาดอีกอัน มีเพียง: แผนงาน
เอเจนต์ทำตามแผนทีละขั้นตอน
สำหรับงานที่ซับซ้อน: progress.md คอยติดตามสิ่งที่เสร็จแล้วและสิ่งที่เหลืออยู่ (Write / เขียน)
ผลลัพธ์: เอเจนต์ที่สะอาดและมีสมาธิในทุกเฟส ไม่มีการปนเปื้อน ไม่มี context rot ไม่มี "ขั้นตอนที่ 20 ที่สะเพร่า"
วิธีที่แพลตฟอร์มชั้นนำจัดการกับเรื่องนี้แตกต่างกัน
Claude Code
การดึงข้อมูลแบบผสม (Hybrid retrieval) CLAUDE.md โหลดล่วงหน้า เครื่องมืออย่าง glob และ grep จัดการการนำทางโค้ดเบสแบบทันเวลาพอดี (just-in-time)
การบีบอัดอัตโนมัติที่ 95% — รักษาการตัดสินใจทางสถาปัตยกรรมและ 5 ไฟล์ที่เข้าถึงล่าสุด
สามารถสร้างเอเจนต์ย่อยสำหรับงานย่อยที่ซับซ้อน โดยแต่ละตัวมีบริบทที่สะอาดของตัวเอง
ปรัชญา: "ทำสิ่งที่ง่ายที่สุดที่ใช้ได้" ปล่อยให้โมเดลฉลาดเกี่ยวกับสิ่งที่มันต้องการ และให้เครื่องมือแก่มันเพื่อไปค้นหาสิ่งนั้น
Manus
การจัดลำดับบริบทที่คำนึงถึง KV-cache: คำนำที่คงที่, ส่วนต่อท้ายแบบไดนามิก การปิดบังเครื่องมือ (Tool masking) ไม่ใช่การลบ
ไปป์ไลน์การบีบอัดการสังเกต (Observation compression pipeline) — ทุกผลลัพธ์ของเครื่องมือจะถูกประมวลผลก่อนเข้าสู่บริบทของเอเจนต์
รายการสิ่งที่ต้องทำแบบถาวรสำหรับการติดตามสถานะ
ระบบไฟล์เป็นหน่วยความจำล้นสำหรับบริบทที่ถูกย้ายออก
สร้างมาเพื่อขนาด ให้บริการผู้ใช้หลายแสนราย ซึ่งประสิทธิภาพเป็นปัญหาเรื่องต้นทุนทางธุรกิจ
ChatGPT Agent
แนวทางที่เน้นภาพเป็นหลัก (Visual-first) เอเจนต์โต้ตอบกับเบราว์เซอร์ GUI
ภาพหน้าจอถูกเพิ่มเข้าไปในบริบทเป็นภาพรวม (visual snapshots) โมเดลใช้เหตุผลเหนือสิ่งที่มันเห็น
โทเค็นภาพมีราคาแพง ดังนั้นเอเจนต์จึงเลือกสรรเกี่ยวกับจำนวนภาพหน้าจอ
ใช้ RL เพื่อเรียนรู้กลยุทธ์การใช้เครื่องมือที่เหมาะสมที่สุดในเครื่องเสมือนหลายพันเครื่อง แทนที่จะเขียนโปรแกรมอย่างชัดเจน
Google ADK
แนวทางสถาปัตยกรรมที่มีหลักการมากที่สุด
หลักการออกแบบสามข้อ:
- แยกพื้นที่จัดเก็บออกจากการนำเสนอ (Separate storage from presentation) — สถานะถาวรไม่เหมือนกับสิ่งที่ปรากฏในการเรียกใช้ API แต่ละครั้ง
- การแปลงอย่างชัดเจน (Explicit transformations) — โปรเซสเซอร์ที่มีชื่อและเรียงลำดับ ซึ่งแปลงบริบทในขั้นตอนที่ทดสอบได้และประกอบกันได้ (composable)
- กำหนดขอบเขตบริบทตามค่าเริ่มต้น (Scope context by default) — การเรียกใช้โมเดลทุกครั้งจะเห็นเฉพาะข้อมูลขั้นต่ำที่จำเป็น
วินัยทางวิศวกรรม มากกว่าการประดิษฐ์พรอมต์
ไปป์ไลน์การหมุนวนของเอเจนต์สากล
ทุกแพลตฟอร์มที่จริงจังมาบรรจบกันที่วงวน 5 ขั้นตอนเดียวกันต่อการหมุนของเอเจนต์:
→ Collect (รวบรวม) — อินพุตผู้ใช้, ประวัติการสนทนา, ผลลัพธ์เครื่องมือ, เอกสารที่ดึงมา, สถานะเอเจนต์
→ Select (เลือก) — สิ่งที่เกี่ยวข้องสำหรับขั้นตอนนี้ภายในงบประมาณโทเค็นที่เหลือ
→ Compress (บีบอัด) — สรุป, ตัดทอน, หรือจัดโครงสร้างใหม่ให้พอดีกับบริบท
→ Arrange (จัดเรียง) — เนื้อหาที่คงที่ก่อน (แคช), เนื้อหาแบบไดนามิกทีหลัง
→ Assemble + call (ประกอบ + เรียกใช้) — บริบทสุดท้าย → การเรียกใช้ API → รับผลลัพธ์ → วนซ้ำ
นี่คือวงวนที่ทำงานอยู่ภายในทุกเอเจนต์ในระบบการผลิตที่คุณเคยใช้
การเข้าใจมันคือสิ่งที่แยกผู้สร้างที่ส่งมอบเอเจนต์ที่เชื่อถือได้ ออกจากผู้สร้างที่สงสัยว่าทำไมเอเจนต์ของพวกเขาถึงทำงานสะเพร่าในขั้นตอนที่ 15
สรุป
Context rot (บริบทเสื่อม) เป็นเรื่องจริง และเริ่มต้นก่อนขีดจำกัดบริบทของคุณมาก
4 กลยุทธ์ที่แก้ไขมัน:
→ Write (เขียน) — เก็บข้อมูลไว้ภายนอกบริบท เพื่อให้เอเจนต์ไม่ลืม
→ Select (เลือก) — ดึงเข้ามาเฉพาะสิ่งที่จำเป็นสำหรับขั้นตอนนี้
→ Compress (บีบอัด) — ตัดโทเค็น, รักษาความหมาย, ลงมือเชิงรุกไม่ใช่เชิงรับ
→ Isolate (แยก) — บริบทแยกสำหรับงานที่แยก, ไม่มีการปนเปื้อน
4 รูปแบบความล้มเหลวที่ต้องระวัง:
→ Poisoning (เป็นพิษ) — ข้อมูลที่ไม่ดีส่งผลต่อทุกขั้นตอน
→ Distraction (ไขว้เขว) — ประวัติที่ยาวนานทำให้เอเจนต์พูดซ้ำแทนที่จะคิด
→ Confusion (สับสน) — เครื่องมือมากเกินไปทำให้คุณภาพการตัดสินใจลดลง
→ Clash (ขัดแย้ง) — ความขัดแย้งทำให้เกิดพฤติกรรมที่ไม่สอดคล้องกัน
KV-cache คุ้มค่ากับการประหยัดต้นทุน 10 เท่า วางเนื้อหาที่คงที่ไว้ก่อน
ขั้นตอนการทำงานที่ดีที่สุด: วิจัย → บีบอัด → วางแผน → บีบอัด → นำไปใช้ บริบทใหม่ในทุกเฟส
Context engineering ไม่ใช่สิ่งที่ไม่จำเป็นสำหรับงานเอเจนต์ที่จริงจัง
มันคือตัวงาน
ถ้าสิ่งนี้มีประโยชน์:
→ โพสต์ซ้ำเพื่อแชร์กับผู้สร้างเอเจนต์ทุกคนที่คุณรู้จัก
→ ติดตาม @sairahul1 สำหรับระบบอื่นๆ ที่ทำงานในขณะที่คุณหลับ
→ คั่นหน้าไว้ — คุณจะกลับมาที่กรอบแนวคิด 4 กลยุทธ์อีกครั้ง
ฉันเขียนเกี่ยวกับ AI, การสร้างผลิตภัณฑ์, และระบบที่ใช้งานได้จริง
