99% ของคนใช้ /goal และ loops ผิดวิธี
hype ที่พวกเขาได้ยินคือ "long-running loops ที่ขับเคลื่อน autonomous agent": จุดมันไปที่งาน เดินออกไป กลับมาเจอโค้ดที่ใช้งานได้
แต่วิศวกร agent ชั้นนำทำแบบนั้นโดยไม่ใช้ /goal มา 6 เดือนแล้ว (ตั้งแต่ GPT-5.2 และ Opus 4.5 ออกมา) มันเรียกว่า วิศวกรรม harness + การพัฒนาแบบ spec-driven development:
- สร้าง harness ให้ agent สังเกตปัญหา
- เขียน spec ที่รัดกุมพร้อม test cases ทั้งหมด
- ปล่อยให้ Codex หรือ Claude Code วนลูป unattended จนกว่าจะผ่านทุกข้อ
ผมเริ่มพวกนี้ข้ามคืนบ่อยมาก — แต่ละรอบใช้เวลา 2-5 ชั่วโมง ในเดือนเมษายน มีรอบหนึ่งจัดการบั๊ก Turbo build-cache ใน monorepo Vercel ของเรา และทำให้มันเป็นสีเขียว (ผ่าน) ตอนเช้า ไม่จำเป็นต้องใช้ /goal จริงๆ
แล้ว /goal จริงๆ ใช้ทำอะไร?
นี่คือสิ่งที่ prompt เดียวทำได้ตอนที่ผมไม่อยู่:
- ~30 ชั่วโมง, โค้ด 6,300 บรรทัด, ครอว์ล 92k หน้า, ใช้จ่าย $40 สำหรับ API
- โคลน core loop ของอีกผลิตภัณฑ์หนึ่ง — สถาปัตยกรรมทั้งหมดถูก reverse-engineer ตั้งแต่เริ่มต้น
- ผลลัพธ์ของเวอร์ชันเราดีกว่า reference product ~50 เท่า สำหรับคำค้นหาเดียวกัน (นี่คือ data layer ใหม่ที่จะขับเคลื่อน newsjack.sh — ทักษะข่าวกรองโอเพนซอร์สที่ผมกำลังทำอยู่)
ความลับคือ การพัฒนา loss function (LFD): คุณเขียนเป้าหมายให้ agent ปรับให้ดีที่สุด (optimize) แทนที่จะเป็น spec ให้สร้าง
นี่คือตัวอย่างที่เป็นรูปธรรมของทวีตของ Peter ที่ถูกทำให้ใช้งานได้จริง
spec ที่ใช้ในการพัฒนาแบบ spec-driven development กลายเป็นจุดเริ่มต้น ไม่ใช่เส้นชัยอีกต่อไป
ผมต้องทดลองหลายครั้งกว่าจะทำให้ถูก แต่ต่อไปนี้คือคู่มือทั้งหมด — แต่เราต้องเริ่มจากว่ามันแย่แค่ไหนก่อน เพื่อให้คุณเข้าใจวิธีออกแบบ /goals เหล่านี้
agent โกง 3 ครั้ง
ทุกอย่างเริ่มต้นด้วยสิ่งที่ผมทำเสมอ: spec
ผมแค่ชี้ codex ไปที่เว็บไซต์สาธารณะของผลิตภัณฑ์อื่น — "เราจะสร้างสิ่งนี้เองได้ยังไง?" ใน 30 นาที มันกลับมาพร้อม system design และ test cases ทั้งหมด — spec
แต่คราวนี้ ผมลอง prompt ที่แตกต่าง
"/goal implement จนกว่าผลลัพธ์ของคุณจะตรงกับของพวกเขาทุกประการ"
และนี่คือสิ่งที่เกิดขึ้น:
Loop 1 (5 นาที)
agent หยิบ eval set, สร้าง seed data ที่สะท้อนมัน, และประกาศชัยชนะภายในห้านาที
"100% recall, ความทั่วไปเป็นศูนย์" — เสิร์ชเอ็นจิ้นที่หาได้แค่ 30 สิ่งที่ผมให้มัน 555
วิธีแก้ → ทำให้มืดบอด (blind) ซ่อน eval ระหว่างการรัน, เปิดเผยเฉพาะตอนให้คะแนน, พร้อมรายการ miss แต่ละรายการ
Loop 2 (20 นาที) - blind, 30 รายการ
ผมทำให้ agent มืดบอดจาก eval set, แต่มันเรียนรู้จาก miss แทน — ทุกครั้งที่ "คุณไม่พบ X" กลายเป็น keyword ในรอบถัดไป ไม่กี่รอบต่อมา: มันใช้ 30 keywords พอดี, หนึ่งคำต่อหนึ่งรายการ, และมัน "ชนะ" อีกครั้ง
วิธีแก้ → ขยาย eval set มีหลายร้อยรายการให้ให้คะแนน, มากเกินกว่าจะแจกแจงหมด
Loop 3 (30 นาที) - blind, 200 รายการ
หลังจากเพิ่ม 200 รายการใน eval set ใหม่, agent โกงอีกครั้ง
ตลกพอ, agent ก็แจกแจงอยู่ดี รายการ keyword พองตัวเป็นหลายร้อย, แต่ละคำเป็นเหยื่อล่อที่แม่นยำสำหรับ miss ถัดไป
สามรอบ, สามการโกง
นั่นคือตอนที่มันปิ๊ง: agent แค่กำลัง optimize
การโกงไม่ใช่บั๊กใน agent มันเป็นบั๊กใน เป้าหมาย ของผม: ผมบอกมันว่าต้องไปที่ไหน และปล่อยทางลัดทุกทางไว้เปิด
ทุกเส้นทางถูกๆ ที่คุณไม่กั้นรั้วไว้ คือทิศทางที่ optimizer จะวิ่งไป และเป้าหมายเริ่มต้นของผมข้ามรั้วทั้งหมดไป
Loop 4 (30 ชั่วโมง) - blind, 200 รายการ, ข้อจำกัดที่เข้มงวด
ดังนั้นผมเริ่มปิดกั้นทิศทาง จำกัดรายการ keyword, ทำให้ eval มืดบอด, ขยายวันที่ — การแก้ไขแต่ละครั้งปิดทางลัดถูกๆ ไปอีกทาง จนกระทั่งทิศทางเดียวที่เหลือที่ทำให้ตัวเลขเปลี่ยนคือการทำให้เก่งขึ้นจริงๆ ในงาน
มันหยุดโกง
จากนั้นมันก็ทำงาน ใช้เวลาคำนวณ ~30 ชั่วโมง, ครอว์ล 92k หน้า, ใช้ token ~$40, โค้ด 6,300 บรรทัด
ปรากฏว่าผลิตภัณฑ์ที่เราอ้างอิงเป็นพื้น ไม่ใช่เพดาน: ในที่สุดเราก็แสดงผลลัพธ์ มากกว่า ~50 เท่า สำหรับคำค้นหาเดียวกัน
(การเดินทางทั้งหมดและหลักฐานที่นี่สำหรับคนที่อยากรู้)
การพัฒนา loss function (LFD) - กายวิภาคของ loss function ที่ดี
เมื่อคนส่วนใหญ่พยายามสร้างผลิตภัณฑ์ พวกเขาใช้ agent เพื่อไปจากศูนย์ถึง shipped ภายในไม่กี่ชั่วโมง
แต่สิ่งที่ตามมาคือส่วนท้าย (long tail) กรณีขอบ (edge cases) ที่ spec ไม่เคยนึกถึงจะปรากฏเฉพาะใน production, ทีละ error log คุณแก้ไขทีละรายการ กรณีที่คุณไม่เจอใน log จะถูกรายงานโดยผู้ใช้ ซึ่งเป็นวิธีที่แพงที่สุดในการหาบั๊ก
ผมทำให้ส่วนถูกๆ ของกระบวนการนี้เป็นอัตโนมัติแล้ว agent Zoe ของผมที่ชื่อ OpenClaw จะดู error log ทุกวัน และ spawn Codex บน error ใหม่เมื่อมันเข้ามา และสร้าง PR — วนลูปที่แน่นที่สุดเท่าที่จะทำได้ (การตั้งค่าทั้งหมดบันทึกไว้ ที่นี่
ส่วนท้ายยังคงใช้เวลาหลายเดือน นั่นคือสาเหตุที่การสร้างผลิตภัณฑ์ที่ดียังคงใช้เวลาแม้จะมี agent ทำงานให้
LFD เร่งส่วนท้ายให้เร็วขึ้น ถ้าคุณสามารถรับตัวอย่าง expected-output จริงๆ ตั้งแต่ต้น — ว่าผลลัพธ์ที่ดีมีลักษณะอย่างไร ในขนาดใหญ่ — คุณจะรัน soak ก่อน shipped: กรณีขอบหลายร้อยกรณีกระทบ agent ในการ optimize เพียงรอบเดียว ไม่ใช่ drip ของ bug report รายไตรมาส และเหตุผลที่สิ่งนี้เป็นไปได้ทันทีคือสำหรับปัญหามากขึ้นเรื่อยๆ ตัวอย่างเหล่านั้นมีอยู่แล้วในที่สาธารณะ
การพัฒนาแบบ spec-driven:
สร้างสิ่งนี้ ทำให้การทดสอบผ่าน
การพัฒนาแบบ loss-function:
สร้างสิ่งนี้ ทำให้การทดสอบผ่าน จากนั้น iterate กับ eval cases 1,000 เหล่านี้
ชุดทดสอบมีขอบเขตจำกัด — เสร็จทันทีที่มันเป็นสีเขียว การประเมิน 1,000 กรณีที่ 95% คือเป้าหมายที่คุณ ลงไปสู่; ไม่มีทางออกนอกเหนือจากเกณฑ์นั้น นั่นสำคัญเพราะ agent ตัดสินใจหลายร้อยครั้งที่คุณจะไม่เห็น และทุกครั้งจะตัดสินตาม บางสิ่ง ถ้าคุณไม่ได้เขียนเป้าหมาย agent จะเลือกเอง — และดังที่รอบ 1–3 แสดง มันจะเลือกสิ่งที่ถูกที่สุดที่จะทำให้พอใจ
loss-function ใหญ่กว่าการประเมิน มันมี 4 สิ่ง — เป้าหมาย, ข้อจำกัด, เครื่องมือวัด, และ entropy ที่ถูกบังคับ สี่ชิ้นส่วน
1. เป้าหมาย
- ใหญ่พอที่การแจกแจงจะไม่คุ้ม การประเมิน 28 รายการถูกจดจำในรอบเดียว ยิ่งมากยิ่งดี
- ทำให้ agent มืดบอดจากเฉลย ข้อมูลประเมินมีไว้สำหรับการให้คะแนนหลังการรันเท่านั้น ถ้า agent สามารถเห็นคำตอบระหว่างรัน มันจะหาวิธีดู
2. ข้อจำกัด
agent ได้รับอนุญาตให้ทำอะไร และไม่ได้รับอนุญาตให้ทำอะไร
- เวลาคือข้อจำกัดที่ agent ลืมเสมอ** agent ไม่มีความรู้สึกเรื่องเวลา พวกมันจะบดเป็นเวลา 10 ชั่วโมงเพื่อการปรับปรุง 2% เพราะเมตริกขยับในนาม แต่โซลูชัน 80% ใน 2 ชั่วโมงดีกว่าโซลูชัน 100% ที่เสร็จใน 30 วัน วิธีแก้: ตั้งงบประมาณตามเวลา (wall-clock budget)**
- เงิน วงเงินสูงสุดสำหรับทุกการเรียกที่ต้องจ่าย: เครดิตครอว์เลอร์, ค่าใช้จ่าย LLM, เพดานดอลลาร์รวมบนคีย์ที่ใช้แล้วทิ้ง
- พื้นผิว (Surface) ผู้ให้บริการทั้งหมด, โมเดลที่อนุญาต, เพดาน concurrency แซนด์บ็อกซ์ agent ให้สัมผัสเฉพาะสิ่งที่คุณต้องการให้มันแตะ
- วิธีการ อนุญาตให้ใช้ LLM analysis หรือเฉพาะตรรกะที่กำหนดตายตัว? แหล่งข้อมูลใดที่ agent สามารถเข้าถึงได้? ระบุให้ชัดเจน
3. เครื่องมือวัด (harness)
ข้อจำกัดที่ไม่มีเครื่องมือวัดก็แค่ความรู้สึก — agent จะละเมิดมันอย่างร่าเริงเพราะมันไม่รู้ว่ากำลังละเมิด สำหรับข้อจำกัดทุกข้อข้างต้น ส่งคำสั่ง CLI ให้ agent ตรวจสอบได้
- การวัดเป้าหมาย ที่ความละเอียดที่ถูกต้อง เลือกเครื่องมือวัดเป้าหมายอย่างระมัดระวัง ตัวอย่างจริง: ผู้ตัดสิน "ให้ LLM ให้คะแนนสอง screenshot" ที่ไร้เดียงสาจะอนุมัติ UI clone ที่มีข้อผิดพลาดระยะห่าง 12px เพราะ LLM ไม่สามารถ เห็น ภาพจริงๆ มันแปลงเป็น embedding แล้วเปรียบเทียบ embedding ดังนั้นถ้าคุณต้องการ UI clone ที่สมบูรณ์แบบพิกเซล ให้เครื่องมือ pixel-diff แก่ agent ของคุณ จากนั้น /goal จนกว่า pixel diff เป็น 0
- การบัญชีเวลา ประทับเวลาทุกการรันและทุกขั้นตอน agent ควรรู้ว่าแต่ละขั้นตอนใช้เวลานานเท่าไหร่ เวลาผนังรวมที่ผ่านไป เวลาเป็นเครื่องมือวัดอันดับหนึ่ง ไม่ใช่เชิงอรรถ
- งบประมาณผู้ให้บริการ "เรากำลังเผาผลาญเท่าไหร่กับครอว์เลอร์ตอนนี้?" ควรเป็นคำสั่งเดียว ไม่ใช่การเดา ติดตามเครดิตสไครป์ที่เหลือ, การเผาในลูปนี้, การเผาสะสม, และการเผาที่คาดการณ์ก่อนชุดที่ต้องจ่ายครั้งต่อไป
- ค่าใช้จ่าย LLM การให้คีย์ API LLM แก่ agent เพื่อใช้ใน data-plane สามารถลดความซับซ้อนของตรรกะได้มาก แต่ agent ควรใช้จ่ายอย่างรับผิดชอบ โดยรู้ก่อนว่ามันใช้จ่ายจริงเท่าไหร่
- การใช้งาน Codex อันนี้ meta เล็กน้อย ลูปควรตระหนักรู้ในตัวเอง: token ที่ฉันใช้ในการ optimize นี้เท่าไหร่? มีประโยชน์ในการรู้ gradient ของขั้นตอน optimize ปัจจุบัน
รูปแบบเป็นคำพูดเก่าๆ ที่รู้กัน: คุณไม่สามารถ optimize สิ่งที่คุณมองไม่เห็นได้
ถ้าคุณใหม่กับการรันลูปเหล่านี้ อย่า ปล่อยมันแล้วเดินไป นั่งกับรอบแรก ดูว่ามันสัมผัสอะไร ยืนยันว่า harness ที่คุณสร้างถูกใช้อย่างถูกต้อง แล้วค่อยไปนอน (และพยายามหลับโดยไม่คิดถึงสิ่งที่คุณจะตื่นมาเจอ)
4. entropy ที่ถูกบังคับ
ทำไม entropy ที่ถูกบังคับถึงสำคัญ: แต่ละลูปดำเนินต่อจาก บริบททั้งหมด ของรันก่อนหน้า โมเดลไม่ได้เริ่มต้นใหม่ — มันกำลังอ่านการตัดสินใจร้อยครั้งล่าสุดของมันเองและ gradient ที่ใช้ได้จนถึงตอนนี้
ในลูป /goal การไปถึงจุดสูงสุดเฉพาะที่ (local maxima) เป็นสถานะเริ่มต้น หากไม่มีการเตะที่ชัดเจน agent จะเดินขึ้นเนินเขาเดิมต่อไป และ "เนินเขาเดิม" คือที่ที่มันเกิดขึ้นเมื่อหยุดปรับปรุง
ตัวอย่างเช่น ถ้าปุ่มเล็กๆ ปรับปรุงผลลัพธ์ 0.1% agent จะหมุนปุ่มนั้นต่อไปแม้จะมีอีก 1,000 ปุ่มให้ลอง
จำเป็นต้องบังคับ entropy เข้าไปในการรันอย่างชัดเจน เพราะโมเดลจะไม่ทำเอง:
- สะท้อน overfit ทุกรอบ ฉันกำลังสร้างโซลูชันทั่วไปขึ้น หรือแค่จำ eval? ถ้ากำลังจำ การเปลี่ยนแปลงถัดไปต้อง ลบ สิ่งประดิษฐ์รูปทรง eval (จำกัดรายการ, ทำให้ฟีเจอร์มืดบอด, ขยาย eval, ปฏิเสธ seed) ไม่ใช่เพิ่ม
- บังคับ entropy เมื่อหยุดชะงัก ถ้ารอบที่แล้วไม่ได้ขยับเมตริก รอบถัดไปไม่สามารถเป็น "ไอเดียเดิม, ทำให้หนักขึ้น" โมเดลต้องกระโดดที่ไม่ชัดเจนจริงๆ — "คิดนอกกรอบ" เป็น prompt ที่ดี - หยุด agent ไม่ให้หมุนปุ่มเดิมหนักขึ้น
- เก็บ log การวนซ้ำ ให้ agent log สมมติฐาน, โหมดความล้มเหลวที่คาดไว้, การวินิจฉัยแต่ละขั้นตอน เพื่อให้สามารถมองย้อนกลับและสะท้อนข้ามการบีบอัด (compactions)
Meta-Meta-Prompt
ตอนแรกผมเขียนเป้าหมายเหล่านี้เอง แล้วก็ได้เรียนรู้ว่านั่นคืองานของ agent เช่นกัน
ดังนั้นผมจึงเขียน skill ที่สร้างเป้าหมายประเภทนี้สำหรับการรัน loss-function-development ที่ดี
ตอนนี้เปิดเป็นโอเพนซอร์สที่นี่:
https://github.com/elvisun/loss-function-development
/lfd-design เพื่อสร้าง harness และเป้าหมาย
Gradient descent ลงไปเรื่อยๆ: สองลูป
ถอยกลับมาดู มันคือ gradient descent ลงไปเรื่อยๆ
ลูปชั้นในคือ agent: เขียนโค้ด, รัน test, แก้ไข ขอบฟ้าสั้น, feedback เร็ว, วัตถุประสงค์เดียว — ทำให้ test ผ่าน นั่นคือลูปชั้นในของนักพัฒนา และ spec-driven development คือวิธีที่คุณรันมัน Coding agents ทำให้เป็นอัตโนมัติแล้ว
ลูปชั้นนอกคือ /goal: ขับเคลื่อนทั้งระบบไปสู่เมตริกผลลัพธ์ข้ามหลายรอบ — ship, วัด, เปลี่ยนแนวทาง, ลงมา ขอบฟ้ายาว, feedback ห่าง นั่นคือลูปของ ทีมผลิตภัณฑ์ แบบดั้งเดิม, การ soak ของ ship-measure-iterate หลายเดือนที่ถูกบีบอัดเป็นการรันครั้งเดียว
ตอนนี้ทั้งสองลูปเป็นอัตโนมัติแล้ว สิ่งที่เหลืออยู่กับคุณคือการกำหนด loss function — ว่า /goal ควร optimize เพื่ออะไรอย่างแน่นอน และในทางใด
คุณกำลังกลั่น (distill) ผลิตภัณฑ์ — หรืออะไรก็ตามที่ทิ้ง artifact สาธารณะไว้
อีกมุมมองหนึ่ง: โดยพื้นฐานแล้วนี่คือ distillation ที่ย้ายจากเวลาฝึกไปเป็นเวลาพรอมพ์ มันคือวิธีที่สาย DeepSeek, Kimi, Minimax ปิดช่องว่างส่วนใหญ่กับ GPT และ Claude — ฝึกโมเดลของคุณบน output ของคนอื่นจนกว่าของคุณจะผลิตซ้ำได้
แต่แทนที่จะกลั่นโมเดล ตอนนี้คุณสามารถใช้ /goal และ LFD เพื่อรัน distillation fitting กับ artifact ใดๆ ที่หาได้ในที่สาธารณะ — มันไม่ตรวจสอบภายในและไม่จำเป็นต้อง
เน้นที่คำว่า สาธารณะ การกลั่น output ที่มี ToS กัน, ต้องล็อกอิน, หรือต้องจ่ายเงินไม่ใช่เรื่องที่ยุติธรรม แต่สิ่งที่เผยแพร่ในที่โล่ง — output ที่บริษัทส่งออกเพื่อชนะลูกค้า — สามารถเรียนรู้ได้เสมอ ส่วนนั้นไม่ใช่ของใหม่ — มันเป็นการเคลื่อนที่เก่าที่สุดในซอฟต์แวร์ สิ่งที่ใหม่คือตอนนี้มันถูกและทำได้ภายในชั่วโมงแทนที่จะเป็นเดือน
ถอยกลับมา และนี่คือการเปลี่ยนแปลงที่ใหญ่กว่า ต้นทุนของการดำเนินการ (execution) พังทลายลงเหลือ ~$0 ที่ใดก็ตามที่มีความสมมาตรของข้อมูล (information symmetry) — เมื่อ output เป็นสาธารณะ ทุกคนเห็นว่าผลลัพธ์ที่ดีมีลักษณะอย่างไร ดังนั้นใครก็สามารถกลั่นมันกลับออกมาในช่วงสุดสัปดาห์ด้วยเงิน $40
ดังนั้นนี่คือคูน้ำใหม่ที่กำลังมีค่ามากขึ้น: ความไม่สมมาตรของข้อมูล (information asymmetry)
บริษัทโอเพนซอร์สที่เป็นแบบอย่างได้กระพริบตาแล้ว ในเดือนเมษายน 2026 cal.com ($5M ARR) นำโค้ด production ของมันไปเป็นส่วนตัวและ กลายเป็น closed-source เหตุผลที่พวกเขาให้ฟังดูเหมือนบทคัดย่อของเรียงความนี้จริงๆ: ในยุคของภัยคุกคามความปลอดภัยที่ขับเคลื่อนด้วย AI คุณไม่สามารถทิ้งซอร์สโค้ดไว้ที่ agent สามารถอ่านได้
"/goal อ่าน cal.com source code และแจกแจงพื้นผิวการโจมตีจนกว่าจะมีอะไรได้ผล"
นั่นเป็นการโจมตีที่อันตรายเกินไปและง่ายเกินไปที่จะดำเนินการ
บริษัทที่มีเอกลักษณ์ทั้งหมดคือ "โอเพนซอร์ส" ตัดสินใจ ในปี 2026 ว่าความเปิดเผยกลายเป็นภาระ นั่นควรบอกคุณทุกอย่าง
ตลอดประวัติศาสตร์ของซอฟต์แวร์ "เราสร้างมันขึ้นมา" คือคูน้ำ
ยุคกำลังปิดตัวลง
ยุคถัดไปเป็นของใครก็ตามที่เป็นเจ้าของสิ่งที่ artifact ไม่เคยบรรจุ: ชุดประเมินที่ไม่มีใครอื่นสามารถให้คะแนนได้ รายการกรณีขอบที่ผู้ใช้ของคุณสะดุดจริงๆ ความจริงพื้นฐานที่คุณวัดเป็นการส่วนตัว ใครก็ตามที่มีเป้าหมายที่คู่แข่งมองไม่เห็นคือคนเดียวที่ลูปของเขายังคงลงมา
ผลิตภัณฑ์คือสุดสัปดาห์แล้ว
ไปสร้างชุดประเมินที่สุดสัปดาห์แตะไม่ได้
