บทนำ
งาน context engineering ทุกงานคือการหาชุด token ที่เล็กที่สุดซึ่งให้ผลลัพธ์ได้อย่างสม่ำเสมอ context คือข้อมูลทั้งหมดที่เข้าไปในโมเดลก่อนที่มันจะตอบ และนิยามที่ผมชอบที่สุดก็คือ: context engineering ที่ดีคือการหาจำนวนรูปแบบที่น้อยที่สุดเท่าที่เป็นไปได้ของ token ที่มีสัญญาณสูง ซึ่งช่วยเพิ่มความน่าจะเป็นของ outcome ที่เราต้องการให้มากที่สุด ในประโยคนี้ทุกคำมีความหมาย เบื้องหลังแต่ละคำมีเทคโนโลยีกองใหญ่อยู่ ดาวน์โหลดสไลด์
ทำไมยุคของ “prompt วิเศษ” กำลังจะจบ
ก่อนหน้านี้ โดยเฉพาะช่วงปี 2567–2568 ไอเดีย prompt engineering แบบง่าย ๆ ฮิตมาก: แค่หาคำที่ถูกต้องให้เจอก็พอ มีคนขาย “prompt ที่สมบูรณ์แบบ” กันเป็นชุด ๆ รวม prompt ห้าร้อยแบบสำหรับการตลาด การเขียนโปรแกรม การขาย และอะไรก็ได้ คนเชื่อกันว่ามีการผสม token แบบวิเศษอยู่ชุดหนึ่ง ที่จะปลดล็อกโมเดลแล้วบังคับให้มันให้ผลลัพธ์ตามที่ต้องการ
ตอนนี้เรื่องนี้ค่อย ๆ กลายเป็นอดีต คนเริ่มฉลาดขึ้นอีกนิด และเริ่มเข้าใจว่า prompt เป็นแค่ส่วนเล็ก ๆ ของทั้งระบบ โดยเฉพาะถ้าเราไม่ได้พูดถึงแชทธรรมดา แต่พูดถึงโปรเจกต์ที่ซับซ้อน โปรดักต์ งานแบบเอเจนต์ โค้ด เครื่องมือ หน่วยความจำ และอื่น ๆ ระบบของคุณยิ่งซับซ้อน ข้อความชิ้นที่คุณพิมพ์ลงใน input เองกับมือก็ยิ่งมีน้ำหนักน้อยลง
ถ้าพูดแบบหยาบ ๆ ในเซสชันสมัยใหม่ขนาดใหญ่ prompt ที่คุณเขียนเองอาจกินพื้นที่ตั้งแต่ศูนย์ถึงหนึ่งเปอร์เซ็นต์ของ context จริงทั้งหมด การหวังว่าหนึ่งเปอร์เซ็นต์นี้จะเป็นตัวกำหนดผลลัพธ์ทั้งหมดจึงไร้เดียงสาไปแล้ว ดังนั้นทุกวันนี้สิ่งที่สำคัญกว่าการหา “คำที่สมบูรณ์แบบ” คือการเข้าใจว่า context ทั้งหมดที่อยู่รอบคำเหล่านั้นทำงานยังไง
prompt ไม่ใช่ context
เวลาผมพูดว่า “context” ผมไม่ได้หมายถึงแค่คำถามล่าสุดของคุณในแชท context เป็นโครงสร้างที่กว้างกว่านั้นมาก
ถ้าแยกส่วนเซสชันเอเจนต์สมัยใหม่ เช่นใน Claude Code, Codex หรือระบบที่คล้ายกัน จะเห็นว่ามีอยู่หลายชั้น
ชั้นแรกคือ weights ของโมเดล สิ่งที่อบไว้ในตัวโมเดลแล้ว และเราไม่มีทางไปแตะต้องได้
ชั้นที่สองคือ system prompt
ชั้นที่สามคือ memory ชั้นหน่วยความจำที่เพิ่งมีมาไม่นานนี้
ต่อมาคือ tools: โค้ดของคุณ การเชื่อมต่อต่าง ๆ เซิร์ฟเวอร์ MCP กลไกการค้นหา และเครื่องมือที่เอเจนต์ใช้เป็น
จากนั้นคือ skills ถ้าคุณทำไว้
แล้วก็ไฟล์ของโปรเจกต์ ที่โมเดลดึงมาตามความจำเป็น หรือที่เรียกว่า just in time
และท้ายสุดเท่านั้นถึงจะเป็นประวัติบทสนทนาของคุณ ซึ่งคนส่วนใหญ่เข้าใจว่านี่คือ “context ทั้งหมด”
ในความเป็นจริง ส่วนใหญ่ของสิ่งที่มีผลต่อคำตอบจริง ๆ ผู้ใช้มองไม่เห็นเลย และหลายคนก็มองข้ามทุกอย่างที่อยู่เหนือระดับแชทธรรมดาไปเฉย ๆ พวกเขาต่อเซิร์ฟเวอร์เป็นกอง ห้อยการเชื่อมต่อเพิ่ม ติดตั้งทุกอย่างที่เจอ แล้วก็แปลกใจว่าทำไมแค่เริ่มเซสชัน context window ก็เต็มไปครึ่งหนึ่งแล้ว ผมเห็นหลายครั้งที่คนติดตั้งของเยอะจนตอนเริ่มเซสชันก็มี token อัดอยู่แล้วหนึ่งแสนหรือสองแสน นี่คือการใช้เกินแบบมหาศาล
context window ไม่ใช่ “หน่วยความจำ” แต่เป็นพื้นที่ของความสนใจ
ตอนที่ผมพูดเรื่อง context window เมื่อปีก่อน ผมก็อธิบายมันแบบค่อนข้างง่าย: ว่าเป็นสิ่งที่โมเดลมองเห็น ตอนนั้นยังพอรับได้ เพราะ window ยังเล็กกว่านี้ หกหมื่นหรือแสน token และปัญหาความสนใจที่ถูกเกลี่ยจนบางก็ยังไม่ชัดขนาดนี้
ตอนนี้ผมว่ามีประโยชน์กว่ามากถ้าคิดถึง context window ว่าเป็นพื้นที่ของความสนใจ มันคล้ายโต๊ะทำงานของคุณ ถ้าบนโต๊ะมีขยะเยอะ มีเอกสารที่ไม่เกี่ยว แฟ้ม ไฟล์เกินจำเป็น คุณก็จะรู้ยากว่าควรเริ่มจับอะไรก่อน แต่ถ้าบนโต๊ะมีแค่ของที่เกี่ยวกับงานตรงหน้า งานก็ง่ายขึ้น: สัญญาณแรงขึ้น noise น้อยลง
กับโมเดลก็เป็นแบบเดียวกัน ตอนที่มันตอบ token แต่ละตัวจะถูกโยงเข้ากับ token ตัวอื่น ๆ ภายในทรานส์ฟอร์มเมอร์ ทั้งหมดนี้ถูกรวมเป็นเมทริกซ์ attention: อะไรเกี่ยวกับอะไร อะไรมีผลต่ออะไร อะไรควรถูกนับให้หนักขึ้น และอะไรเบาลง และยิ่งคุณโหลดขยะเข้าไปใน window มากเท่าไหร่ ก็ยิ่งแย่ โมเดลถูกบังคับให้เกลี่ยความสนใจที่มีจำกัดไปบน token จำนวนมหาศาล สัญญาณสำคัญก็อ่อนลง noise ก็แรงขึ้น
นี่แหละเหตุผลที่ยิ่งมีองค์ประกอบใน context มาก ก็ยิ่งรักษาสัญญาณไว้ยาก ยิ่งมีขยะจากประวัติเก่าและข้อมูลที่ไม่มีโครงสร้างมาก โอกาสที่โมเดลจะไปผิดทางก็ยิ่งสูง
ทำไม “context มากขึ้น” ไม่ได้แปลว่า “ผลลัพธ์ดีขึ้น”
ตอนนี้หลายคนเห็นว่าโมเดลมี window หลายแสน หรือถึงล้าน token แล้ว ก็คิดว่า: ดีเลย งั้นตอนนี้ก็โยนทุกอย่างลงไปได้เลย แต่ในทางปฏิบัติมันไม่ได้ตรงไปตรงมาแบบนั้น
ในทุกกราฟและทุกการทดลองที่ผมเคยเห็น เทรนด์รวมมีอย่างเดียว: ยิ่งเราโหลด token เข้า context มาก โอกาสที่โมเดลจะเจอข้อเท็จจริงหรือคำตอบที่เราต้องการจริง ๆ ก็ยิ่งต่ำลง
ถ้าคุณแค่เขียนข้อความ อาจจะไม่ค่อยเห็นชัด แต่ถ้าคุณเขียนโค้ด เรื่องนี้จะวิกฤตมาก แค่ฟังก์ชันเดียว คลาสเดียว dependency เดียว หรือความเชื่อมโยงสำคัญจุดเดียวหายไปใน noise โมเดลก็เริ่มทำงานแย่ลงแล้ว คนบ่นกันว่า “โมเดลเขียนโค้ดแย่ลง” แต่พอไปดูโปรเจกต์ของเขา ก็เจอแต่กองขยะ เอกสาร ขยะ ไฟล์เกินจำเป็น คำแนะนำที่ไร้ความหมาย และเศษค้างจากงานเก่าแบบสุ่ม ๆ
ผมมักแนะนำให้ถามตัวเองง่าย ๆ ว่า: ถ้าเป็นคน จะแก้งานนี้ได้ไหมด้วยข้อมูลตั้งต้นที่คุณกำลังให้โมเดลอยู่ตอนนี้ ถ้าคนยังทำได้ยาก โมเดลก็จะทำได้ยากเหมือนกัน แปลว่าปัญหาไม่ได้อยู่ที่โมเดลอย่างเดียว แปลว่าการจัดแพ็กข้อมูลและเอกสารของคุณยังไม่ดีพอ
Attention, reasoning และการเสื่อมสองแบบของ context ยาว
ตอนที่โมเดลทำงาน มันคำนวณใหม่ทุกครั้งว่า token แต่ละตัวสัมพันธ์กับตัวอื่นยังไง ถ้าประมาณแบบหยาบมาก ๆ นี่แหละคือเหตุผลที่ context ยาวทั้งแพง ช้า และคุณภาพไม่ได้ดีเสมอไป
เท่าที่ผมมอง context ยาวมีการเสื่อมหลัก ๆ อยู่สองแบบ
แบบแรกคือ context rot ธรรมดา ยิ่ง token มาก ความสนใจที่แบ่งให้ส่วนที่สำคัญจริง ๆ ได้ก็ยิ่งน้อย
แบบที่สองคือการเสื่อมของ reasoning เวลาโมเดลเปิดโหมด thinking หรือ reasoning มันจะมีงบเพิ่มสำหรับการคิด แต่ยิ่ง input ของคุณใหญ่ งบที่เหลือให้การให้เหตุผลจริง ๆ ก็ยิ่งน้อย พูดง่าย ๆ คือโมเดลใช้ทรัพยากรไปกับการย่อยข้อมูลก้อนใหญ่ทั้งหมดนี้ ไม่ใช่กับการคิดให้ดี
เร็ว ๆ นี้ผมไปเจองานวิจัยชิ้นใหญ่ ที่ผู้เขียนเปรียบเทียบโมเดลปัจจุบันของ Anthropic แล้วสรุปว่าบล็อก reasoning ของมันลดลงอย่างเห็นได้ชัด ในช่วงเวลาประมาณเดียวกับที่เริ่มคุมลิมิตการใช้งานอย่างหนัก ผมรู้สึกว่าเรื่องนี้เกี่ยวกับการที่พวกเขาเทรนโมเดลใหญ่ตัวใหม่ไปพร้อม ๆ กัน และพูดกันตรง ๆ คือทรัพยากรไม่พอ ในสถานการณ์แบบนี้ สิ่งแรกที่จะถูกบีบคือ thinking ดังนั้นเวลาคุณเปิด reasoning ไว้ ถ้าเป็นผม จะจำเรื่องง่าย ๆ ข้อหนึ่งไว้ในหัว: มีโอกาสสูงที่มันก็อาจถูก “บีบคอ” เหมือนกัน และยิ่ง context ของคุณใหญ่ งบจริงสำหรับการคิดนี้ก็ยิ่งน้อย
ที่น่าสนใจกว่านั้นอีก: ตอนที่พวกเขาปล่อยอัปเดตรอบล่าสุด ๆ พวกเขาเข้ารหัสบล็อก thinking ไว้ เหตุผลทางการคือ: เพื่อไม่ให้คนพยายาม inject prompt ของตัวเองเข้าไปในกลไกการคิด แต่ก็มีอีกมุมมองหนึ่ง: ว่าทำแบบนี้เพื่อไม่ให้คนนอกมองเห็นได้ง่าย ๆ ด้วย ว่า thinking ภายในลดลงไปจริง ๆ แค่ไหน เมื่อก่อนเราอ่านการคิดพวกนี้ได้ ตอนนี้ใน Claude Code คุณไม่เห็นมันแล้ว มันถูกเข้ารหัสและผู้ใช้เข้าถึงไม่ได้ ผมว่านี่ไม่ใช่เรื่องบังเอิญ
ทำไมมันถึงคำนวณหนักขนาดนี้
ถ้าพูดแบบง่ายสุด ๆ กลไก attention อาศัยการคูณเมทริกซ์ และตรงนี้แหละที่ต้นทุนการคำนวณพื้นฐานของทุกอย่างเริ่มต้นขึ้น
ตอนที่โมเดลสร้าง token ตัวถัดไป มันจะโยง token เข้าหากัน ถ้าคุณมีร้อย token ที่ input นั่นก็คณิตศาสตร์แบบหนึ่ง ถ้าสี่หมื่น ก็เป็นอีกเรื่องหนึ่งเลย และถ้าล้าน ก็ยิ่งไปกันใหญ่ ปัญหาคือการเติบโตตรงนี้ไม่ได้เป็นเชิงเส้น แต่เป็นกำลังสอง ไม่ใช่ว่าเราขยาย context สิบเท่าแล้วต้นทุนจะเพิ่มสิบเท่า เราได้ n²
นี่แหละเหตุผลที่ผมไม่ค่อยเชื่อเรื่องเล่าทั้งหลายเกี่ยวกับ “ล้าน token ของจริง” ใช่ บนกระดาษคุณอาจมีล้าน token แต่ถ้าคิดต้นทุนการคำนวณจริงอย่างตรงไปตรงมา ก็จะเห็นว่ามันไม่มีทางทำงานได้โดยไม่ต้องแลกอะไรเลย ส่วนใหญ่น่าจะมีการหั่น window เป็นส่วน ๆ ประกอบขึ้นใหม่แบบสังเคราะห์ กระจาย attention ใหม่ด้วยวิธีใดวิธีหนึ่ง ใช้ทริกทางวิศวกรรม พูดง่าย ๆ คือนี่ไม่ใช่ “ล้าน” แบบที่ token ทุกตัวถูกนับด้วยคุณภาพเท่ากัน พอเกินปริมาณหนึ่ง คุณภาพก็จะตกลงอยู่ดี
และในแง่นี้ context engineer คือคนที่จัดการ inference compute ยิ่ง token น้อย การคำนวณก็ยิ่งน้อย คำตอบยิ่งเร็ว ต้นทุนยิ่งต่ำ และความแม่นยำยิ่งสูง นี่แหละเหตุผลที่การเขียนทุกอย่างลงในแชทเดียว ทั้งเรื่องสุขภาพ งาน โค้ด เรื่องส่วนตัว เป็นไอเดียที่ไม่ดี และการกองไฟล์จำนวนมากไว้ในโปรเจกต์เดียว แล้วบอกโมเดลว่า “อ่านทั้งหมด” ก็เป็นไอเดียที่ไม่ดีเหมือนกัน
weights ของโมเดล: ฐานรากที่เราไม่แตะ
ชั้นล่างสุดของ context คือ weights ของโมเดล นี่คือสิ่งที่ถูกเทรนมาแล้วด้วยข้อมูลมหาศาล และถูกแปลงเป็นรูปแบบทางคณิตศาสตร์ พูดง่าย ๆ ก็คืออินเทอร์เน็ตที่อบไว้ล่วงหน้าแล้วแปลงเป็นเวกเตอร์ เพราะแบบนี้โมเดลถึงรู้ว่าหลังคำว่า “สวัสดี” มักตามด้วย “สบายดีไหม” เข้าใจความหมายพื้นฐานของภาษา และมีภาพของโลกอยู่ในหัวบ้าง
ชั้นนี้เราแทบไปเปลี่ยนอะไรไม่ได้เลย ใช่ บางคนชอบเทรนโมเดลของตัวเอง เล่นกับเวอร์ชันทดลองเล็ก ๆ ในระดับพื้นฐานมันก็ไม่ได้ยากขนาดนั้นจริง ๆ แต่ถ้าพูดถึงโมเดลใหญ่เต็มรูปแบบ นั่นคือการเทรนเป็นเดือน ๆ และพลังประมวลผลมหาศาล
บางครั้งโมเดลก็ถูก fine-tune เพิ่มให้เข้ากับภูมิภาค ดังนั้น Yandex GPT, Sber GPT, Mistral โมเดลจีน หรือเวอร์ชันประจำภูมิภาคใด ๆ ก็อาจทำตัวต่างกันเล็กน้อย ผมเคยเจอตัวอย่างขำ ๆ กับ Telegram Translator ถ้าใส่ถ้อยคำทางการเมืองบางแบบเกี่ยวกับไต้หวัน สี จิ้นผิง และจัตุรัสเทียนอันเหมินลงไป แล้วกด Fix จากที่ผมสังเกต มันไม่ได้แค่ “แก้” ข้อความ แต่เริ่มให้เวอร์ชันที่ถูกต้องตามอุดมการณ์ของจีน จากตรงนี้ก็สรุปได้อย่างค่อนข้างมีเหตุผลว่าเบื้องหลังมันใช้โมเดล AI จากจีน
นี่เป็นตัวอย่างที่ดีว่า pre-training และการ fine-tune มีผลต่อพฤติกรรมของโมเดลจริง ๆ ถึงผู้ใช้จะมองไม่เห็นก็ตาม
system prompt และกรอบพฤติกรรม
ชั้นถัดมาคือ system prompt ตรงนี้ไม่ใช่แค่ความรู้เกี่ยวกับโลกแล้ว แต่เป็นคำอธิบายว่าโมเดลคืออะไร ควรทำตัวยังไง ใช้ภาษาอะไร มีบทบาทอะไร กฎอะไร และข้อจำกัดอะไรบ้าง
เช่น ถ้าคุณเปลี่ยน language ในคอนฟิก นั่นไม่ใช่การแฟลชโมเดลใหม่แบบวิเศษอะไร คุณแค่เปลี่ยนข้อความชิ้นหนึ่งใน system prompt ที่บอกว่า: ผู้ใช้คนนี้ชอบภาษานี้ แค่นั้นเอง โมเดลอาจจะดูมัน หรือไม่ดูก็ได้ บางทีมันก็ยังไหลไปเป็นภาษาอังกฤษหรือภาษาอื่นอยู่ดี เพราะนี่คือคำแนะนำ ไม่ใช่สิ่งที่ฝังไว้ตายตัว
คำอธิบายสภาพแวดล้อมทั้งหมดก็เหมือนกัน ในนั้นอาจเขียนว่าคุณคือเอเจนต์ด้านเทคนิค คุณเข้าถึงเครื่องมือพวกนี้ได้ คุณต้องทำแบบนี้ ต้องทำตามข้อจำกัดแบบนี้ ทั้งหมดนี้เป็นแค่ชุดคำแนะนำก้อนใหญ่
ยังมีอีกชั้นหนึ่งแยกออกมา คือกรอบพฤติกรรม บางทีผมเรียกมันเล่น ๆ ว่า “จิตวิญญาณ” ของโมเดล ประเด็นคือสถิติของภาษาอย่างเดียวไม่พอแล้ว ถ้าโมเดลถูก pre-train ด้วยอินเทอร์เน็ต และในอินเทอร์เน็ตมีความก้าวร้าว สงคราม ความรุนแรง และ noise อื่น ๆ มหาศาล ต่อจากนั้นก็ต้องอธิบายแยกให้มันรู้ว่าในโลกของมนุษย์ อะไรถือว่ารับได้ และอะไรรับไม่ได้ นี่ไม่ใช่แค่รายการข้อห้ามแบบ “ห้ามบอกสูตรทำดินปืน” แต่เป็นความพยายามส่งต่อชุดบรรทัดฐานด้านพฤติกรรมให้โมเดลมากกว่า เหมือนพ่อแม่สอนลูก: แบบนี้อย่าทำดีกว่า แบบนี้ทำดีกว่า
Memory: จากการปรับให้เป็นส่วนตัว สู่หน่วยความจำทำงานของโปรเจกต์
ตอนที่ memory เพิ่งมี มันดูเป็นกลไกปรับให้เป็นส่วนตัวที่ยังค่อนข้างดิบ ChatGPT หยิบข้อเท็จจริงบางอย่างเกี่ยวกับคุณมาเก็บไว้ในหน่วยความจำได้ ปัญหาคือขยะมักหลุดเข้าไปในนั้นเยอะเกินไป
ฝั่ง Claude Code เรื่องราวไปไกลกว่านั้นอีกนิด ที่นั่นมีกลไก dreaming และผมว่ามันน่าสนใจมาก เมื่อก่อนหน่วยความจำของมันก็ทำงานคล้าย ๆ กัน: คุณทำอะไรบางอย่าง แล้วบอกระบบผ่าน ๆ ว่าคุณใช้ Linux ว่าคุณอยู่คนละโซนเวลา ว่าใน Safari บางอย่างทำงานแย่กว่า แล้วมันก็กองเก็บไว้เป็น log: วันที่ เวลา รายการ วันที่ เวลา รายการ
ต่อมาพวกเขาเพิ่ม dreaming เข้ามา นี่เป็นโหมดทดลองที่จำลองบางอย่างคล้ายช่วงหลับฝัน (REM) ตอนที่กิจกรรมน้อย เอเจนต์จะหยิบ log นี้มาแพ็กใหม่: อะไรสำคัญ อะไรไม่สำคัญ อะไรควรย้ายไปไว้ในหน่วยความจำที่มีโครงสร้าง และอะไรทิ้งไว้ใน log ดิบได้ สุดท้ายจากกองรายการธรรมดา ๆ ก็กลายเป็นการทำดัชนีที่พอใช้ได้
ผมชอบแบบนี้มากกว่าหน่วยความจำแบบเก่าเยอะ เพราะขยะน้อยลง เอเจนต์ไม่ลาก log ดิบทั้งหมดเข้า context ที่ใช้งานอยู่ มันลากหน่วยความจำที่มีโครงสร้างเข้าไป และถ้าต้องการรายละเอียดจริง ๆ ค่อยลงไปค้นลึกกว่านั้น
แต่ว่ามันตัดสินยังไงว่าอะไรสำคัญหรือไม่สำคัญ ก็ยังไม่โปร่งใสทั้งหมด จากความรู้สึก ความถี่ของการพูดซ้ำมีผล อาจรวมถึงสัญญาณความเครียด และลักษณะพฤติกรรมบางอย่าง ผมเคยเห็นการพูดคุยและงานวิจัยเล็ก ๆ ที่บอกว่าถ้อยคำก้าวร้าวหรือใช้อารมณ์ก็อาจทิ้งร่องรอยไว้ในวิธีที่ระบบจัดลำดับความสำคัญได้ จริงแค่ไหนตามตัวอักษร ผมไม่กล้ายืนยัน แต่ในฐานะสมมติฐาน เรื่องนี้ก็ถูกพูดถึงกันอยู่
Tools: ต้นทุนที่ซ่อนอยู่ของความเป็นเอเจนต์
ตอนที่คนเริ่มทำงานกับเอเจนต์ หลายคนไม่เข้าใจว่า tools เป็นชั้นที่แพงขนาดไหน
tools คือทุกอย่างที่เอเจนต์ต้องทำเป็น: ทำงานกับไฟล์ ค้นในโค้ด เรียก bash ทำ web search, web fetch เริ่ม planning เรียกเอเจนต์ตัวอื่น ค้นข้อความ ส่งคำสั่ง และอื่น ๆ เพื่อให้เอเจนต์ใช้สิ่งเหล่านี้ได้ ต้องอธิบายมันทั้งหมดให้มันรู้
และคำอธิบายพวกนี้กิน context กินเยอะด้วย นี่แหละเหตุผลที่ระบบเอเจนต์แพงกว่าแชทธรรมดาตั้งแต่เริ่ม คุณยังไม่ได้ทำอะไรเป็นชิ้นเป็นอันเลย แต่ token ก็หมดไปกับ system prompt และ definitions ของเครื่องมือพวกนี้แล้ว
จากตรงนี้มีปัญหาแยกอีกเรื่อง คือเซิร์ฟเวอร์ MCP ตัวมันเองมีประโยชน์ แต่เซิร์ฟเวอร์แต่ละตัวก็มีน้ำหนัก ถ้าคุณต่อเซิร์ฟเวอร์ MCP เยอะ โดยเฉพาะตัวที่หนัก ๆ คุณก็แค่กิน context ตัวเอง ผมเคยเห็นการประเมินว่า GitHub MCP ตัวเดียวอาจหนักพอ ๆ กับ tools ในตัวของ Claude Code ทั้งหมดรวมกัน ดังนั้นการจัดการ MCP ไม่ใช่เรื่องเล่น ๆ เลย ถ้าคุณใช้มันบ่อย ก็ควรเปิด context ขึ้นมาดูบ้างเป็นครั้งคราว: ว่าห้อยอะไรไว้เยอะเกินไปหรือเปล่า
Skills: รูปแบบใหม่ของการส่งความรู้ให้เอเจนต์
พูดง่าย ๆ สกิลกลายเป็นรูปแบบใหม่ของการเขียน prompt เมื่อก่อนคุณต้องย้ายความรู้ลง prompt เองทุกครั้ง ตอนนี้คุณห่อมันไว้ใน skill ได้
สกิลมีชื่อ คำอธิบาย รายการเครื่องมือที่ใช้ได้ และกฎการเรียกใช้ และที่สำคัญ: ปกติสิ่งที่ถูกโหลดเข้า context ไม่ใช่สกิลทั้งก้อน แต่เป็น metadata พูดง่าย ๆ คือโมเดลรู้ว่ามีสกิลนี้อยู่ รับผิดชอบเรื่องอะไร ควรเรียกเมื่อไหร่ และใช้อะไรได้บ้าง เพราะแบบนี้คุณถึงมีสกิลเยอะ ๆ ได้โดยไม่ฆ่า context ด้วยเนื้อหาทั้งหมดตั้งแต่แรก
อย่างของ Claude ก็มี Skill Creator และ Evaluator ตัว Creator ช่วยประกอบสกิล ส่วน Evaluator รันการเปรียบเทียบในแซนด์บ็อกซ์ได้ แล้วแสดงว่ามีผลที่มีนัยสำคัญจริงไหม: งานทำได้ดีขึ้นเมื่อมีสกิลเทียบกับไม่มีหรือเปล่า สกิลปรับให้ดีขึ้นได้ไหม และมันช่วยเพิ่มผลได้จริงแค่ไหน
และใช่ ผมเริ่มเห็นแล้วว่าคนเริ่มขายความรู้ในรูปแบบของสกิล นักการตลาดสักคนอาจไม่ได้แค่ให้คำปรึกษาด้วยตัวเอง แต่ห่อแนวทางของตัวเองไว้ใน skill แล้วขายให้บริษัทเป็นโปรดักต์ ในแง่ของการขยายขนาด นี่สมเหตุสมผล: คนที่ให้คำปรึกษาเอเจนต์อาจไม่ใช่คนอีกต่อไป แต่เป็นความรู้ของคนคนนั้นที่ถูกแพ็กไว้แล้ว
คำแนะนำของโปรเจกต์: Claude.md, Agent.md และการซิงค์
ในทุกรีโพของผมมีไฟล์ Claude.md ประจำโปรเจกต์ ในนั้นไม่ใช่ข้อความยาวเหยียด แต่เป็นเหมือนดัชนีมากกว่า: design system อยู่ไหน สถาปัตยกรรมอยู่ไหน คำถามด้านโปรดักต์อยู่ไหน pipeline ทำงานยังไง อะไรต้องไปหาที่ไหน ผมอยากให้มันเป็นจุดอ้างอิงหลักจุดเดียวของโปรเจกต์
มี Claude.md ระดับราก มีระดับโปรเจกต์ และทำไฟล์ในโฟลเดอร์ย่อยได้อีก แต่ปกติผมไม่ทำ ผมไม่ชอบกระจายการควบคุมไปหลายระดับ เพราะหลังจากนั้นจะทำความสะอาดและซิงค์ยากขึ้น
เพราะผมทำงานกับเอเจนต์หลายตัวสลับกันเป็นระยะ ผมเลยมี hook ที่พอ Claude.md เปลี่ยน ก็จะก๊อปการเปลี่ยนแปลงไปที่ Agent.md และไฟล์แบบเดียวกันของระบบอื่น พูดง่าย ๆ คือผมตั้งใจให้คำแนะนำพวกนี้ซิงค์กันอยู่เสมอ ไม่ใช่เพราะมันดูสวย แต่เพราะผมไม่อยากต้องอธิบายเอเจนต์ทุกครั้งว่า: “ช่วยไปอ่านไฟล์โน้นหน่อย” ถ้าทำให้ทุกตัวมีข้อมูลที่ต้องใช้เหมือนกันอยู่แล้วได้ ผมก็ทำแบบนั้น
แก้ด้วย symlink ได้ไหม? อาจจะได้ ผมแค่ยังไม่ได้ขุดลึกพอ และเลยแก้ปัญหาแบบหยาบกว่า: ด้วยสกิล sync แยกต่างหาก ที่ก๊อปการเปลี่ยนแปลงแบบบรรทัดต่อบรรทัด
subagent มีไว้แยก context ไม่ใช่มีไว้ให้ดูสวย
หัวข้อที่สำคัญมากคือ subagent
แต่เดิม subagent ไม่ได้มีไว้สร้างผังองค์กรสวย ๆ จากบทบาทต่าง ๆ แต่มีไว้แยก context เป็นกลไกที่ใช้งานได้จริงมาก แทนที่จะลากทั้งอินเทอร์เน็ตหรือผลค้นโค้ดทั้งหมดเข้า window หลัก คุณสร้างเซสชันแยก ผู้ทำงานแยก ที่วิ่งไปยังจุดที่ต้องการ อ่าน ค้น แล้วเอากลับมาเฉพาะผลลัพธ์ที่มีสัญญาณสูง
ต่อมามันขยายไปเป็นบทบาท ตัวละคร teams เอเจนต์แบบคล้ายสกิล แต่เป้าหมายพื้นฐานนั้นง่ายมาก: อย่าทำ context หลักให้รก นี่แหละเหตุผลที่ผมมี subagent เป็นกองสำหรับงานต่าง ๆ ทั้งหัวหน้าดีไซเนอร์ ผู้ทดสอบ และอื่น ๆ แต่ผมก็ยังมองมันเป็นกลไกสำหรับแยกและกรอง context เป็นอันดับแรก
พูดง่าย ๆ คือ subagent ไม่ใช่แค่ “ผู้ช่วยฉลาดอีกตัว” แต่เป็นวิธีที่ไม่ต้องดันทุกอย่างผ่าน window เดียวกัน
loop ของเอเจนต์ทำงานจริง ๆ ยังไง
แชทธรรมดาจบงานตอนที่ให้คำตอบคุณแล้ว เอเจนต์ไม่ได้ทำงานแบบนั้น
ถ้าคุณให้งาน เช่นหาอะไรบางอย่างในรีโพ โมเดลจะรับ context ทั้งหมดก่อน: system prompt, memory, Claude.md, tools, skills ข้อความ ทุกอย่างที่ต้องใช้ จากนั้นมันเริ่มสร้าง token ของคำตอบ ถ้าระหว่างทางพบว่าต้องใช้ tool ในการแก้งาน มันจะไปที่ definitions ของเครื่องมือ เลือกตัวที่เหมาะ เช่น bash เช็ก permissions เรียกเครื่องมือ รับผลลัพธ์ แล้วก็… ส่งทั้งหมดนี้กลับเข้าโมเดลเพื่อคำนวณใหม่อีกรอบ
นี่แหละคือ loop
เอเจนต์ทำงานเป็นวงรอบ: รับงาน คิด เลือก tool รับผลลัพธ์ ส่งกลับเข้าโมเดลอีกรอบ เช็กอีกครั้งว่ายังต้องใช้ tool อีกไหม แล้วค่อยเรนเดอร์คำตอบสุดท้าย
นี่แหละเหตุผลที่ความเป็นเอเจนต์มีราคาแพง แต่ละรอบไม่ใช่ “การกระทำเล็ก ๆ” แต่คือการรัน context ก้อนใหญ่ผ่านระบบใหม่อีกครั้ง
hook, status line และ compact
อีกส่วนของสถาปัตยกรรมที่คนมักมองข้ามคือ hooks
status line ก็เป็น hook เหมือนกัน มันผูกกับ input และ output อัปเดตตอนที่โมเดลตอบ และช่วยแสดงข้อมูล telemetry ที่มีประโยชน์ได้: ลิมิต, context window, เวลาที่เหลือก่อนชั่วโมงพีก, การเปลี่ยนแปลงที่ยังไม่ได้ commit และอีกหลายอย่าง
memory reload ก็ผูกกับ hook dreaming ก็เหมือนกัน auto-compact ก็ด้วย
compact เป็นของที่สำคัญมาก เมื่อ context เต็มถึงเกณฑ์หนึ่ง hook จะทำงานแล้วบอกว่า: ถึงเวลา compact แล้ว พูดง่าย ๆ คือเอเจนต์หยิบประวัติของเซสชัน ยุบให้เป็นสรุปที่สั้นลงตามกฎของมันเอง แล้วทำงานต่อโดยไม่ได้ใช้ประวัติเต็ม แต่ใช้เวอร์ชันที่ย่อแล้ว
แถม compact ยังเรียกเองด้วยมือได้ และถ้าไม่ได้สั่งแค่คำสั่ง compact เฉย ๆ แต่ใส่คำแนะนำเพิ่มไปด้วย ก็จะมีผลต่อสิ่งที่มันเก็บไว้แบบละเอียดได้ เช่น บอกว่า: ช่วงหลังสุดสำคัญกว่า เก็บส่วนนั้นไว้ให้ละเอียดหน่อย แล้ว compact ที่ได้ก็จะไม่ใช่แบบมาตรฐาน แต่ปรับให้เข้ากับงานของคุณ
ทำไมระบบเอเจนต์ถึงเริ่มแพงเร็วขนาดนี้
ตอนที่บริษัทเปลี่ยนมาใช้เอเจนต์ พวกเขาจะเข้าใจอย่างรวดเร็วว่า คนที่ใช้แชตบอตธรรมดา กับคนที่ใช้เอเจนต์อย่าง Claude Code มีต้นทุนคนละระดับกันเลย
ถ้าเอเจนต์ไม่เข้าใจงาน หรืองานถูกแพ็กมาไม่ดี loop อาจหมุนยี่สิบหรือสามสิบรอบ และทุกรอบก็ส่ง context ทั้งหมดเข้าโมเดลใหม่: system prompt, tools, เซิร์ฟเวอร์, skills, ข้อความ, เอกสาร, ทุกอย่าง
เพราะแบบนี้ เอเจนต์ไม่ได้แค่แพงขึ้น มันยังเริ่มทื่อลงไปเรื่อย ๆ ตามการใช้เกินด้วย โดยเฉพาะถ้าลิมิตและ thinking ถูกบีบไว้แล้ว ดังนั้นบริษัทจึงมีแรงจูงใจชัด ๆ ที่จะทำให้เอเจนต์ขี้เกียจขึ้นอีกนิด และใจกว้างกับความลึกของการคิดน้อยลงอีกหน่อย ถ้าลดคุณภาพคำตอบลงได้โดยไม่ถึงขั้นหายนะ แค่จาก 99% เหลือ 95% สำหรับบริษัทใหญ่ นี่อาจเป็นการประหยัดระดับพันล้านแล้ว
นี่คือความจริงที่ไม่น่าฟัง แต่สำคัญของระบบเอเจนต์
แคชไม่ใช่แค่ตัวเร่งความเร็ว แต่เป็นฐานทางเศรษฐกิจของทั้งระบบ
ถ้าไม่มีแคช การทำงานกับเอเจนต์จะแพงขึ้นหลายเท่า
ทุกครั้งที่คุณเริ่มเซสชันใหม่ context ก้อนใหญ่จะถูกส่งเข้าแคช: system prompt, tools, Claude.md หน่วยความจำ และอื่น ๆ การเขียนลงแคชครั้งแรกแพงกว่า แต่การเรียกข้อมูลชุดเดิมครั้งต่อ ๆ ไปถูกกว่ามาก นี่แหละเหตุผลที่การทำงานต่อในเซสชันเดิมเบากว่าสำหรับทั้งระบบและผู้ให้บริการ เทียบกับการเริ่มทุกอย่างจากศูนย์
แต่แคชจะพังเมื่อมีการเปลี่ยนแปลง ถ้าคุณเปลี่ยนชั้นที่อยู่สูงกว่า เช่น พารามิเตอร์ระบบอย่าง web search true/false แฮชของชุด token ก็จะเปลี่ยน และส่วนที่อยู่ถัดลงมาก็ต้องคำนวณใหม่ทั้งหมด
ดังนั้นต้องเข้าใจว่า: แคชไม่ใช่เรื่องนามธรรม แต่มีผลโดยตรงทั้งกับเงินและลิมิต ถ้าเช้า ๆ คุณเปิดเซสชันยาวมาก ๆ ขึ้นมาทำต่อ คุณอาจเผาลิมิตไปก้อนใหญ่ทันที แค่เพราะต้องยกข้อมูลก้อนเก่าทั้งหมดขึ้นมาใหม่
มือใหม่กับ context engineer คิดกันคนละแบบ
ตอนที่คนเพิ่งเริ่มทำงานกับเอเจนต์ ปกติจะคุยกับมันเหมือนแชทธรรมดา พวกเขาเขียนว่า: “ทำฟังก์ชันให้หน่อย” “เขียนอันนี้ให้หน่อย” “แก้ตรงนี้ให้หน่อย” พวกเขาไม่ได้สร้างระบบรอบตัวเอเจนต์
แต่ context engineer ที่ดีคือคนที่สร้างระบบ เขาคิดถึงหน่วยความจำ แคช skills, subagents, MCP, project docs, hooks, permissions ทีมเอเจนต์ สิ่งที่อยู่ในรากของรีโพ และสิ่งที่ไม่ต้องลากเข้า window เลย
พูดง่าย ๆ นี่คือความต่างระหว่างคนที่แค่คุยกับโมเดล กับคนที่สร้างสภาพแวดล้อมการทำงานให้มันเป็น
ผมชอบนิยามที่คนในห้องเสนอมามาก: นี่คือความสามารถในการลงจากภาพรวมไปสู่รายละเอียด แต่ผมขอเพิ่มว่า: นี่ยังเป็นความสามารถในการรวบรวม context ที่ถูกต้องรอบงาน แทนที่จะแค่หวังว่าเขียนคำขอออกมาแล้วจะเข้าเป้าเอง
สูตรสุดท้าย
ถ้าบีบทั้งหมดนี้ให้เหลือสูตรเดียว มันง่ายมาก:
ผลลัพธ์ที่ดี = token สัญญาณสูงในปริมาณน้อยที่สุดเท่าที่จำเป็น
ดูง่าย เกือบเหมือนสูตรในโรงเรียน แต่ข้างหลังซ่อนความซับซ้อนมหาศาล: จะเลือก token พวกนี้ออกมายังไง จะไม่จมใน noise ยังไง จะไม่ทำให้ context บวมยังไง จะไม่ทำแคชพังยังไง จะไม่เปลือง reasoning ไปกับขยะยังไง จะไม่ทำ loop หลักให้รกด้วยสิ่งที่ย้ายไปไว้ใน subagent, tool, memory หรือ skill ได้ยังไง
และนี่แหละคือไอเดียทั้งหมด context engineering ไม่ใช่การหาวลีวิเศษ แต่คือการจัดการความสนใจของโมเดล สภาพแวดล้อมการทำงาน หน่วยความจำ เครื่องมือ ต้นทุน และความน่าจะเป็นของผลลัพธ์ที่ต้องการ
ถ้าคุณอยากทำงานกับเอเจนต์ให้เป็นจริง ๆ อย่ามองมันเป็นถังขยะที่โยนอะไรลงไปก็ได้ ลองดูว่าในโปรเจกต์ของคุณมีอะไรอยู่บ้าง หน่วยความจำทำงานยังไง มีขยะในคำแนะนำไหม คุณต้องใช้ skills ไหม ใช้ subagent แล้วคุ้มไหม เกิดอะไรขึ้นกับแคช context ประกอบด้วยอะไรบ้าง คนส่วนใหญ่ไปไม่ถึงความเข้าใจชั้นนี้ด้วยซ้ำ
และถ้าไม่มีสิ่งนี้ ก็จะไม่มี context engineering ที่ดี
บทสรุป
ทุกอย่างสุดท้ายแล้วลงเอยที่ความคิดง่าย ๆ ข้อเดียว: อย่าพยายามเอาชนะโมเดลด้วย prompt “อัจฉริยะ” อันเดียว นั่นเกือบทุกครั้งคือภาพลวงตา
ต้องรู้จักประกอบระบบที่ถูกต้องให้มัน: อะไรอยู่ในหัวมันจาก pre-training อะไรอยู่ใน system prompt มันดึงอะไรมาจาก memory คุณห้อย tools และ MCP อะไรไว้ให้มัน skills ไหนเรียกใช้ได้ ไฟล์ของคุณจัดไว้ยังไง ตรงไหนควรใช้ subagent ตรงไหนต้อง compact และตรงไหนเริ่มเซสชันใหม่ไปเลยจะดีกว่า
นี่แหละคือ context engineering
และยิ่งเรื่องนี้เปลี่ยนจากชุด “คำวิเศษ” เป็นศาสตร์ทางวิศวกรรมปกติสำหรับคนทั่วไปได้เร็วเท่าไหร่ ผลลัพธ์ที่แข็งแรงและเสถียรจริง ๆ ก็จะมาเร็วเท่านั้น
