ยิ่งเอเจนต์ทำงานเองได้มากขึ้น ราคาของคำแนะนำแบบเก่าก็ยิ่งเห็นชัด AGENTS.md ที่ยาวหลายหน้า skill หลายสิบตัวที่มีคำอธิบายกว้าง ๆ และการบังคับให้อ่านรีโพครึ่งหนึ่ง อาจไม่ได้ทำให้คุณภาพดีขึ้น แต่กลับเปลืองบริบท และทำให้โมเดลเลือกขั้นต่อไปที่ถูกต้องได้ยากขึ้น
พอ GPT-6 Astra ออกมา OpenAI แนะนำให้ทบทวนวิธีเขียน prompt แบบที่เคยชิน: ไม่จำเป็นต้องอธิบายทุกขั้นตอนให้โมเดลที่เก่ง สิ่งที่มันต้องการคือสภาพแวดล้อมที่เข้าใจง่าย ซึ่งในนั้นหาความรู้ที่เกี่ยวข้องได้ง่าย ตัดสินใจได้อย่างปลอดภัย และพางานไปถึงผลลัพธ์ที่ตรวจสอบได้
Skill ควรเป็นตัวชี้ทาง ไม่ใช่สารานุกรม
ปกติ skill เก็บอยู่ในไฟล์ Markdown และอธิบายขั้นตอนการทำงานที่ทำซ้ำ: การ migrate ฐานข้อมูล การ deploy การทำงานกับ API ตัวใดตัวหนึ่ง การเตรียมเอกสาร หรือระเบียบภายใน รูปแบบนี้มีประโยชน์ ตราบใดที่ skill ช่วยในจังหวะที่ต้องใช้ ไม่ใช่ถูกโหลดขึ้นมาทุกครั้งที่มีคำบังเอิญตรงกัน
ปัญหาเริ่มจากคำอธิบายที่พยายามครอบคลุมทุกเรื่องที่อยู่ใกล้ ๆ เช่น ประโยค “ใช้เมื่อทำงานกับฐานข้อมูล คิวรี โมเดล หรือการจัดเก็บข้อมูล” จะดันให้เอเจนต์เปิด skill แม้แต่ตอนแก้คิวรี SQL นิดเดียว สุดท้ายบริบทก็เต็มไปด้วยคำแนะนำที่ไม่เกี่ยวกับงาน
คำอธิบายที่บอกขอบเขตชัด ๆ มีประโยชน์กว่ามาก: “ใช้เมื่อเพิ่มหรือแก้ migration และเมื่อตรวจแผน rollout ของมัน” มันไม่ได้เล่าเนื้อหาของ skill ทั้งหมด แต่ตอบคำถามสำคัญได้ดี: ต้องเปิด skill นี้เมื่อไหร่
นี่คือการเปลี่ยนวิธีคิดที่สำคัญ คำอธิบายของ skill ไม่ควรเป็นข้อความโฆษณาที่อัดคีย์เวิร์ดให้มากที่สุด หน้าที่ของมันคล้ายการทำ routing ที่ดี: พาเอเจนต์ไปหาคำแนะนำที่ใช่ และไม่พาไปถ้าไม่มีเหตุผล
Progressive disclosure เก็บบริบทไว้ให้งานจริง
OpenAI ยกเรื่อง progressive disclosure หรือการเปิดเผยรายละเอียดทีละขั้น ขึ้นมาเป็นพิเศษ skill ใหญ่ ๆ อาจมีสถานการณ์ ข้อยกเว้น คำสั่ง ตัวอย่าง และการตัดสินใจในอดีตอยู่มาก การโหลดทั้งหมดเพื่อแก้จุดเล็ก ๆ จุดเดียวไม่มีประโยชน์อะไร
โครงสร้างที่ใช้งานได้หน้าตาแบบนี้:
SKILL.mdที่ราก อธิบายสั้น ๆ ว่ามีไว้ทำอะไร และเริ่มจากตรงไหน- สถานการณ์เฉพาะแยกไว้ในไฟล์ต่างหาก
- กลไกที่ทำซ้ำย้ายไปอยู่ในสคริปต์
- เอเจนต์อ่านเฉพาะกิ่งที่เกี่ยวกับงานตรงหน้า
วิธีนี้ไม่ได้แปลว่า “ซ่อนความรู้” ตรงกันข้าม ความรู้เข้าถึงง่ายขึ้น เพราะหาเจอและนำไปใช้ได้ง่ายขึ้น โมเดลไม่ต้องเสียสมาธิกับกฎการ deploy ตอนแก้คำพิมพ์ผิด และไม่ต้องอ่านเอกสารฐานข้อมูลตอนเปลี่ยนข้อความในอินเทอร์เฟซ บริบทส่วนเกินมีราคาเท่าไหร่ทั้งในแง่เงินและลิมิต เราเคยแจกแจงไว้ในเช็กลิสต์ประหยัด token
สำหรับทีม นี่ยังเป็นวิธีลดความขัดแย้งกันเองของคำแนะนำด้วย ยิ่งโหลดคำแนะนำพร้อมกันมากเท่าไหร่ ก็ยิ่งมีโอกาสที่สองข้อในนั้นจะบอกลำดับความสำคัญไม่ตรงกัน หรือสั่งให้ทำสิ่งที่ไม่จำเป็น
AGENTS.md ไม่ควรเป็นโกดังเก็บความกังวลเก่า ๆ
AGENTS.md สำคัญเป็นพิเศษ เพราะมีผลกับแทบทุกงานในรีโพ มันจึงมักสะสมร่องรอยของปัญหาในอดีต: ข้อห้าม การอ่านภาคบังคับ เช็กลิสต์ยาว ๆ และ requirement (ข้อกำหนด) ที่เขียนไว้สำหรับโมเดลรุ่นเก่า
ตัวอย่างคลาสสิกของสิ่งที่ไม่ควรทำ: บังคับให้เปิดเอกสารสถาปัตยกรรม คำอธิบายฐานข้อมูล และคู่มือ deploy ก่อนการเปลี่ยนแปลงทุกครั้ง สำหรับการแก้บรรทัดเดียว นี่ทำให้ช้าโดยไม่จำเป็นและกินบริบท ทางที่ดีกว่าคือให้แผนที่นำทาง: เอกสารสถาปัตยกรรมใช้เมื่อเรื่องเกี่ยวกับขอบเขตของ service เอกสารฐานข้อมูลใช้เมื่อเปลี่ยน schema ส่วนกฎการ deploy ใช้ตอนเตรียม release
ความต่างนี้ไม่ใช่แค่เรื่องรูปแบบ แบบแรกบังคับให้เอเจนต์ทำตามสูตรตายตัว แบบที่สองช่วยให้มันแยกได้ว่าอะไรเกี่ยวกับงานตรงหน้าจริง ๆ
โมเดลที่เก่งเข้าใจได้ดีขึ้นแล้วว่าตัวเองต้องการข้อมูลอะไร AGENTS.md ที่ดีในวันนี้จึงควรเป็นแผนที่ของโปรเจกต์และชุดขอบเขตที่ชัดเจน ไม่ใช่ความพยายามจะมาแทนความสามารถในการคิดของโมเดล อะไรควรใส่ในบริบทของเอเจนต์ และอะไรควรกันไว้ข้างนอก อ่านได้ในบทความเรื่อง context engineering
ขอบเขตการตัดสินใจสำคัญกว่าการห้ามทุกอย่าง
เมื่อเอเจนต์เคยทำมากเกินไปโดยไม่ได้รับอนุญาตสักครั้ง ปฏิกิริยาตามธรรมชาติของทีมคือเพิ่มกฎเข้ม ๆ: “ห้ามทำอะไรถ้ายังไม่ได้ยืนยัน” มันอาจกันความเสี่ยงได้ แต่ก็หยุดงานที่ปลอดภัยซึ่งเอเจนต์ทำเองจนเสร็จได้ไปด้วย
แทนที่จะใช้สูตรกว้าง ๆ ที่มาจากความกังวล ควรอธิบาย decision boundaries หรือขอบเขตการตัดสินใจที่มีอยู่จริง:
- การกระทำไหนทำบนเครื่องได้อย่างปลอดภัย
- เมื่อไหร่ต้องขออนุมัติ
- อะไรเกี่ยวกับ production เงิน ข้อมูล หรือการสื่อสารกับภายนอก
- การตรวจแบบไหนที่เอเจนต์รันเองได้
- ตรงไหนที่มันต้องหยุดและเอาผลลัพธ์ให้คนดู
ตัวอย่างเช่น เขียนอนุญาตไว้ตรง ๆ ได้เลยว่าเอเจนต์รันเทสต์บนเครื่องกับ fixture แบบใช้ครั้งเดียวได้ และรันซ้ำได้ ระหว่างที่แก้บั๊กตามงานที่ได้รับ ส่วนการเปลี่ยนข้อมูลบน production การโพสต์ หรือการส่งข้อความหาลูกค้า ยังเป็นการกระทำแยกที่ต้องยืนยันก่อน
วิธีนี้ไม่ได้ทำให้ความปลอดภัยอ่อนลง แต่ทำให้ทั้งโมเดลและคนเข้าใจมันได้: เอเจนต์ไม่ต้องขออนุญาตทุกก้าวที่ไม่มีพิษภัย แต่ก็ไม่ข้ามเส้นในจุดที่ความผิดพลาดมีราคาแพง
กำหนดว่าแค่ไหนคือเสร็จ ก่อนเริ่มงาน
OpenAI ชี้อีกลักษณะหนึ่ง: Astra อาจทำงานละเอียด แต่กลับมาขอรีวิวตั้งแต่ทำเวอร์ชันแรกเสร็จ ถ้างานต้องจบที่ผลลัพธ์ที่ใช้งานได้และตรวจแล้ว ก็ควรบอกให้ชัด
ประโยค “เพิ่มระบบล็อกอิน” เปิดช่องให้ตีความได้มาก เอเจนต์อาจเขียนโค้ดแล้วหยุด ส่วนประโยค “เพิ่มระบบล็อกอิน รันสถานการณ์บนเครื่อง ตรวจ flow หลัก แก้ข้อผิดพลาดที่เจอ และรันเทสต์ที่ได้รับผลกระทบ” กำหนดเส้นชัยที่มีประโยชน์กว่า
ไม่จำเป็นต้องแปลงงานเป็นคำแนะนำทีละขั้นร้อยข้อ ที่สำคัญกว่าคือบอกเกณฑ์ done: อะไรต้องทำงานได้ ตรวจด้วยอะไร และเมื่อไหร่ที่ถึงเวลากลับมาหาคนจริง ๆ
เรื่องนี้มีประโยชน์เป็นพิเศษกับงานของเอเจนต์ที่ “เวอร์ชันแรกที่ใช้ได้” กับ “งานที่เสร็จแล้ว” เป็นคนละสถานะกัน อย่างหลังรวมการรัน การตรวจ การแก้สิ่งที่พัง และรายงานผลที่อ่านเข้าใจ
เช็กอะไรในคำแนะนำของคุณได้ตั้งแต่ตอนนี้
โมเดลใหม่เป็นโอกาสดีที่จะไม่ต้องเขียนทุกอย่างใหม่ตั้งแต่ต้น แต่ตรวจทานสั้น ๆ แทน
- ดู description ของ skill แต่ละตัว อ่านบรรทัดเดียวแล้วเข้าใจไหมว่า skill นี้ต้องใช้ในสถานการณ์ไหน
- แบ่งคำแนะนำก้อนใหญ่เป็นตัวชี้ทางสั้น ๆ กับกิ่งรายละเอียดตามสถานการณ์
- เอาการบังคับอ่านเอกสาร “เผื่อไว้” ออกจาก
AGENTS.md - ทบทวนข้อห้ามที่เกิดขึ้นเพราะนิสัยของโมเดลรุ่นเก่า มันกันความเสี่ยงจริง หรือแค่ทำให้งานหยุด
- สำหรับงานที่ทำเป็นประจำ ให้กำหนดว่าอะไรนับว่าเสร็จ: โค้ด การรัน เทสต์ การตรวจผลลัพธ์ รายงาน
ข้อสรุปหลักไม่ใช่ว่า prompt และ skill ไม่จำเป็นอีกต่อไป มันยังจำเป็น แต่บทบาทเปลี่ยนไป เมื่อก่อนมันมักเป็นไม้ค้ำให้โมเดล ตอนนี้มันคือโครงสร้างพื้นฐานของการตัดสินใจ: ตัวชี้ทางที่กะทัดรัด บริบทที่เกี่ยวข้อง ขอบเขตที่ชัด และการปิดงานที่ตรวจสอบได้
สรุป
เอเจนต์ที่เก่งไม่ได้มีประโยชน์ขึ้นเพราะมีกฎเยอะที่สุด มันมีประโยชน์ขึ้นเมื่อแยกเรื่องสำคัญออกจากเรื่องพื้นหลังได้เร็ว เข้าใจขีดจำกัดของอำนาจตัวเอง และรู้ว่างานยังไม่จบจนกว่าผลลัพธ์จะถูกตรวจ
ดังนั้นเมื่อย้ายไปใช้โมเดลใหม่ ไม่ควรถามแค่ว่า “มันทำอะไรได้บ้าง” คำถามที่สำคัญไม่แพ้กันคือ: เรายังแบกคำแนะนำอะไรติดตัวมาจากสมัยที่ต้องอธิบายให้เอเจนต์ฟังทุกขั้นอยู่บ้าง
