วิธีใช้ Goals ของ Codex

• Goals คือฟีเจอร์ เป้าหมายแบบคงอยู่ (persistent objective) ที่ทำให้เธรดของ Codex ทำงานต่อเนื่องข้ามหลายเทิร์นไปสู่ผลลัพธ์ที่กำหนดไว้
• เหมาะกับงานอย่าง profiling, patching, benchmarking, การทำซ้ำการทดสอบแบบ flaky, การตรวจสอบเชิงอ้างอิงหลักฐาน ซึ่งจัดการได้ยากด้วยพรอมป์ต์เดียว
• เมื่อกำหนดผลลัพธ์ (outcome), วิธีตรวจยืนยัน (verification surface) และข้อจำกัด (constraints) แล้ว Codex จะ ตัดสินเองได้จากหลักฐานว่าทำเสร็จหรือยัง
• สามารถ ควบคุมวงจรชีวิต ได้ด้วยคำสั่ง /goal, /goal pause, /goal resume, /goal clear โดยรองรับตั้งแต่ Codex 0.128.0
• เป็นโครงสร้าง สัญญาความเสร็จสมบูรณ์ (completion contract) ที่จำกัดในระดับเธรด และหัวใจสำคัญคือ ความต่อเนื่องภายใต้การควบคุมของผู้ใช้ ไม่ใช่การทำงานอัตโนมัติแบบไร้ขีดจำกัด

---

ความหมายของ Goals และที่มาของการนำมาใช้

• Goals เป็นฟีเจอร์ที่ให้ เงื่อนไขความสำเร็จ (completion condition) แก่ Codex โดยกำหนดว่าสิ่งใดต้องเป็นจริง จะตรวจสอบความสำเร็จอย่างไร และต้องรักษาข้อจำกัดใดไว้
• เดิมที Codex ทำงานได้ดีอยู่แล้วกับ งานเขียนโค้ดที่มีขอบเขตชัดเจน เช่น ตรวจรีโพซิทอรี, แก้บั๊ก, เพิ่มเทสต์, อธิบายสาเหตุการล้มเหลว, หรือทำการเปลี่ยนแปลงเฉพาะจุด
• Goals เหมาะกับงานที่ขั้นตอนถัดไปเปลี่ยนไปตามสิ่งที่ Codex เรียนรู้ระหว่างทาง
  • เช่น profiling, patching, benchmarking, การทำซ้ำการทดสอบแบบ flaky, หรือเปลี่ยนคำถามวิจัยให้เป็นการตรวจสอบที่ยึดตามหลักฐาน
• งานลักษณะนี้ไม่ได้ต้องการแค่พรอมป์ต์ที่ยาวขึ้น แต่ต้องการ เป้าหมายแบบคงอยู่
• เมื่อ Goal ถูกเปิดใช้งาน Codex จะคงเป้าหมายไว้ ประเมินว่าทำเสร็จหรือยัง และเลือกการกระทำถัดไปเอง โดยไม่ต้องให้ผู้ใช้พูดเป้าหมายซ้ำทุกครั้งที่มีผลลัพธ์ระหว่างทาง
• Goal ไม่ใช่ความอัตโนมัติแบบทำงานเบื้องหลังโดยไร้ขอบเขต แต่เป็น สัญญาความสำเร็จที่กำหนดขอบเขตและอยู่ภายใต้การควบคุมของผู้ใช้

Quickstart: วิธีใช้ Goals

• ใช้ Goal กับงานที่ปลายทางชัดเจน แต่เส้นทางไปถึงยังไม่แน่นอน
  • ตัวอย่างที่เหมาะ: การเพิ่มประสิทธิภาพ, การสืบสวนเทสต์แบบ flaky, การย้าย dependency, การตามบั๊กที่ต้องทำซ้ำให้ได้, การ refactor หลายขั้น, การจูนบนพื้นฐาน benchmark, งานวิจัยที่ต้องมีผลลัพธ์สุดท้าย
  • งานแก้ไขครั้งเดียวเหมาะกับพรอมป์ต์ปกติ

• การติดตั้งและตรวจสอบเวอร์ชัน

  • Goals ใช้งานได้ตั้งแต่ Codex 0.128.0
  • npm: npm install -g @openai/codex@latest แล้วตามด้วย codex --version
  • Homebrew: brew update && brew upgrade --cask codex แล้วตามด้วย codex --version

• การตั้ง Goal และคำสั่งวงจรชีวิต

  • ตั้งค่าในรูปแบบ /goal <ผลลัพธ์> เช่น /goal Reduce p95 latency below 120 ms without regressing correctness tests
  • /goal: ดู Goal ปัจจุบัน
  • /goal pause: หยุด Goal ที่กำลังใช้งานชั่วคราว
  • /goal resume: กลับมาทำ Goal ที่พักไว้
  • /goal clear: ลบ Goal ปัจจุบัน

• เงื่อนไขการหยุด (stopping condition)

  • หยุดเมื่อสำเร็จ, ถูกพัก, ถูกลบ, ถูกขัดจังหวะ, ถึงขีดจำกัดงบประมาณ, หรือพบตัวบล็อกที่ต้องการข้อมูลจากผู้ใช้
• ในสถานการณ์ที่ปกติต้องออกคำสั่งซ้ำทุกเทิร์น เช่น "ทำต่อได้เลย", "ลองแก้แบบถัดไปที่เป็นไปได้", "รัน benchmark อีกรอบ", "ตอนนี้เช็กเทสต์" Goal จะช่วยแสดงเจตนานั้นอย่างชัดเจน

Goals เทียบกับพรอมป์ต์

• พรอมป์ต์ทั่วไป: "ทำงานถัดไปนี้"
• Goal: "ทำงานต่อไปจนกว่าผลลัพธ์นี้จะเป็นจริง"

• ความต่างในการทำงาน

  • ในคำขอทั่วไป Codex จะทำตามคำสั่งตรงหน้า รายงานผล แล้วรอ
  • ใน Goal จะมี เป้าหมายถาวร (durable target) ติดอยู่กับเธรด และเมื่อจบเทิร์นจะตรวจสอบหลักฐานปัจจุบันเพื่อดูว่าบรรลุเป้าหมายหรือยัง
  • ถ้ายังไม่บรรลุ และ Goal ยัง active อยู่ รวมถึงยังอยู่ในงบประมาณ Codex ก็สามารถทำงานต่อจากสถานะล่าสุดได้

• ตัวอย่าง: /goal Reduce p95 checkout latency below 120 ms on the checkout benchmark while keeping the correctness suite green

  • ให้ทั้งผลลัพธ์ที่วัดได้ วิธีตรวจยืนยัน และข้อจำกัด
  • Codex จะวนทำ benchmark → ตรวจ hot path → เปลี่ยนจุดที่เกี่ยวข้อง → รัน benchmark ใหม่ → รันชุดความถูกต้อง และถ้าผลยังไม่พอก็จะทำต่อ

• แบบจำลองทางความคิด

  • พรอมป์ต์: ask → work → result → wait
  • Goal: work → check → continue or complete
• Goal ให้เส้นชัย แต่การทำงานยังคงต้อง ถูกตรวจสอบเทียบกับหลักฐาน (audited against evidence)

วิธีเขียน Goal

• Goal ที่ดีไม่ใช่พรอมป์ต์ที่ยาวขึ้น แต่เป็น สัญญาที่กระชับ ว่า Codex ควรทำงานอย่างไร อะไรคือความสำเร็จ และควรทำอย่างไรเมื่อยังไปไม่ถึงความสำเร็จ

• 6 องค์ประกอบที่ Goal ที่แข็งแรงควรกำหนด

  • Outcome: สิ่งที่ต้องเป็นจริงเมื่อทำงานเสร็จ
  • Verification surface: เทสต์, benchmark, รายงาน, artifact, output ของคำสั่ง, หรือแหล่งข้อมูลที่ใช้พิสูจน์
  • Constraints: สิ่งที่ห้าม regress ระหว่างที่ Codex ทำงาน
  • Boundaries: ไฟล์ เครื่องมือ ข้อมูล รีโพซิทอรี หรือทรัพยากรที่ใช้ได้
  • Iteration policy: วิธีตัดสินใจว่าจะทำอะไรต่อหลังจากแต่ละความพยายาม
  • Blocked stop condition: จุดที่ควรรายงานและหยุดเมื่อไม่มีเส้นทางที่ป้องกันได้ภายใต้ข้อจำกัดปัจจุบันแล้ว

• รูปแบบการเขียน

  • /goal <สถานะสุดท้ายที่ต้องการ> verified by <หลักฐานเฉพาะเจาะจง> while preserving <ข้อจำกัด>. Use <อินพุต/เครื่องมือ/ขอบเขตที่อนุญาต>. Between iterations, <วิธีเลือกการกระทำที่ดีที่สุดถัดไป>. If blocked or no valid paths remain, <สิ่งที่ต้องรายงานและอินพุตที่จำเป็นต่อความคืบหน้า>.

• ตัวอย่างอ่อน vs ตัวอย่างแข็งแรง

  • แบบอ่อน: /goal Reduce p95 checkout latency below 120 ms without regressing correctness tests
  • แบบแข็งแรง: ระบุชัดถึงวิธีตรวจยืนยัน (checkout benchmark), ขอบเขตที่ใช้ได้ (checkout service, benchmark fixtures, เทสต์ที่เกี่ยวข้อง), นโยบายการวนทำ (บันทึกการเปลี่ยนแปลง ผล benchmark และการทดลองถัดไป), รวมถึงเงื่อนไขการรายงานตัวบล็อก

• Goal สำหรับงานวิจัย/สืบสวน

  • หากการพิสูจน์แบบตรงไปตรงมาเป็นไปไม่ได้ ควรกำหนด มาตรฐานหลักฐาน (evidence standard) ก่อนเริ่มงาน
  • ตัวอย่าง: /goal Produce the strongest evidence-backed reproduction of the paper using the available materials and local resources. Attempt the headline results where feasible, verify outputs where possible, and end with a report that separates confirmed findings, approximate reconstructions, blocked claims, and remaining uncertainty.

• มอบหมายให้ Codex ช่วยเขียน Goal

  • แนะนำ workflow 2 ขั้นตอน: อธิบายงานด้วยภาษาทั่วไป → ขอให้ Codex ร่าง Goal → ปรับแต่งเงื่อนไขความสำเร็จ วิธีตรวจยืนยัน ข้อจำกัด และเงื่อนไขหยุดเมื่อถูกบล็อก ก่อนเปิดใช้งานจริง

สิ่งที่เปลี่ยนไปเมื่อเปิด Goal

• เป้าหมายยังคงมองเห็นอยู่เสมอ

  • ต่อให้เทสต์ล้ม เธรดก็ยังคงเป้าหมายเดิมไว้
  • ถ้า benchmark ดีขึ้นแต่ยังไม่ถึงเกณฑ์ Codex ก็จะทำต่อ
  • ถ้าเส้นทางการวิจัยติดข้อจำกัดด้านข้อมูล ก็จะปรับแผนหลักฐานโดยไม่หลุดจากมาตรฐานการวิจัย

• ทำต่อได้ในเธรดที่ว่าง (continuation)

  • จะไม่ทำต่อหากมีเทิร์นอื่นกำลังทำงานอยู่ มีอินพุตจากผู้ใช้รออยู่ในคิว หรือมีงานของเธรดอื่นกำลังรอ
  • จะทำต่อเฉพาะเมื่อเธรดว่าง Goal ยัง active และยังอยู่ในงบประมาณ

• การประกาศว่าสำเร็จต้องอิงหลักฐาน

  • แค่โมเดลเชื่อว่า "น่าจะเสร็จแล้ว" ยังไม่พอสำหรับการปิดงาน
  • ต้องตรวจ Goal กับไฟล์ที่เกี่ยวข้อง เทสต์ ล็อก output ของ benchmark artifact ที่สร้างขึ้น และหลักฐานรูปธรรมอื่น ๆ ก่อนจึงจะถือว่าสำเร็จได้
• หลักสำคัญของการออกแบบคือ Codex อาจทำงานต่อได้ แต่ หลักฐานเป็นผู้ตัดสินว่าทำเสร็จหรือไม่

โครงสร้างการออกแบบ Goals ภายใน Codex

• Goals ถูกสร้างเป็น สถานะคงอยู่ระดับเธรด (persisted thread state) ไม่ใช่ความจำส่วนกลางหรือคำสั่งระดับโปรเจกต์
  • เป้าหมายจะอยู่กับเธรดที่มีบริบทเกี่ยวข้อง เช่น ไฟล์ที่ตรวจ คำสั่งที่รัน diff ที่สร้าง ล็อกที่ดู และร่องรอยการให้เหตุผล

• ชั้นสถาปัตยกรรม

  • บันทึกเป้าหมาย วงจรชีวิต งบประมาณ และบัญชีความคืบหน้าในฐานะสถานะถาวรระดับเธรด
  • สถานะ Goal ได้แก่ active, paused, complete, budget-limited
  • จากสถานะเหล่านี้ Codex จะตัดสินใจว่าจะทำต่อ รอผู้ใช้ หรือสรุปความคืบหน้าแทนการเริ่มงานใหม่

• การทำต่อ (continuation) ขับเคลื่อนด้วยเหตุการณ์

  • ไม่ใช่ลูปธรรมดา และจะตรวจเฉพาะที่ขอบเขตปลอดภัยเท่านั้น: หลังจบเทิร์น เมื่อไม่มีงานค้าง ไม่มีอินพุตจากผู้ใช้ในคิว และเธรดอยู่ในสถานะว่าง
  • ตัว dispatcher ทำงานอย่างระมัดระวัง: งานที่มีแค่การวางแผนจะไม่กระตุ้น continuation, หากถูกขัดจังหวะจะพักเป้าหมาย, เมื่อเธรดกลับมาทำงานจะคืนค่า Goal หากเหมาะสม, และถ้าเทิร์น continuation ไม่ได้เรียกใช้เครื่องมือก็จะยับยั้ง continuation อัตโนมัติครั้งถัดไปเพื่อป้องกันการหมุนเปล่า

• ชั้นการพรอมป์ต์

  • continuation prompt จะจัดแนว Codex ให้ยึด Goal ที่ active เป็นศูนย์กลาง แต่ยังคงบังคับให้ต้องตรวจสอบก่อนประกาศว่าสำเร็จ
  • เปรียบเทียบ Goal กับหลักฐานเฉพาะ เช่น ไฟล์ที่แก้ คำสั่งที่รัน เทสต์ที่ผ่าน output ของ benchmark artifact ที่สร้าง และหลักฐานจากงานวิจัย

• การจัดการงบประมาณ (budget)

  • เมื่อถึงงบประมาณจะหยุดงานที่เป็นสาระสำคัญ สรุปความคืบหน้าและตัวบล็อก และระบุขั้นตอนถัดไปที่ยังมีประโยชน์
  • การถึงขีดจำกัดงบประมาณไม่เท่ากับการทำ Goal สำเร็จ

• สัญญาเครื่องมือ (tool contract)

  • โมเดลสามารถเริ่ม Goal ได้ และจะทำเครื่องหมาย Goal เดิมว่า complete ได้ก็ต่อเมื่อมีหลักฐานรองรับความสำเร็จ
  • การพัก ดำเนินต่อ ลบ หรือเปลี่ยนเป็นสถานะถึงขีดจำกัดงบประมาณ ยังคงอยู่ภายใต้การควบคุมของผู้ใช้หรือระบบ

เปลี่ยน Goal ที่อ่อนให้เป็น Goal ที่แข็งแรง

• ตัวอย่างการจูนประสิทธิภาพ

  • แบบอ่อน: /goal Improve performance
  • แบบแข็งแรง: /goal Reduce p95 latency below 120 ms on the checkout benchmark while keeping the correctness test suite green
  • เวอร์ชันที่แข็งแรงจะให้ทั้งผลลัพธ์ วิธีตรวจยืนยัน และข้อจำกัด ทำให้รู้ได้ว่าเมื่อใดยังไม่ควรหยุด
    • ถ้า p95 ดีขึ้นจาก 180ms → 135ms ก็ยังถือว่ายังไม่สำเร็จ
    • ถ้า latency ต่ำกว่า 120ms แต่เทสต์ความถูกต้องล้ม ก็ยังไม่สำเร็จ
    • ถ้ารัน benchmark ไม่ได้ ก็ควรเปิดเผยตัวบล็อกแทนที่จะประกาศว่าสำเร็จ

• ขอบเขต Goal ที่เหมาะสม

  • ต้องแคบพอให้ตรวจสอบได้ แต่กว้างพอให้เลือกการกระทำถัดไปได้
  • Fix the failing checkout test แคบเกินไปหากต้นตอจริงคือ dependency ต้นน้ำ
  • Improve the whole system กว้างเกินไปเพราะไม่มีพื้นผิวให้ตรวจสอบ
  • Make the checkout test suite pass on the current branch without changing public API behavior จึงอยู่ในระดับที่เหมาะสม

• ใช้หลักเดียวกันกับ generated artifacts

  • แบบอ่อน: /goal Write docs for this feature
  • แบบแข็งแรง: /goal Produce a docs page for Goals that explains the lifecycle, command surface, and two examples. Verify that the page builds locally and that all referenced commands match the current CLI behavior.
  • เวอร์ชันที่แข็งแรงให้ทั้งหน้าที่ตรวจสอบได้ คำสั่ง build และพฤติกรรมของคำสั่งที่ต้องตรงกัน

• มาตรฐานหลักฐานสำหรับ Goal งานวิจัย

  • ควรกำหนดก่อนเริ่มการสืบสวนว่าอะไรนับเป็นการทำซ้ำอย่างแม่นยำ การสร้างใหม่บางส่วน หลักฐานตัวแทน และสิ่งใดต้องถือเป็นตัวบล็อก
  • Goal งานวิจัยที่แข็งแรงต้องกำหนดให้สร้างคลังข้ออ้าง จับคู่ข้ออ้างกับหลักฐาน ลงมือทำส่วนที่รันได้ ติดป้ายข้ออ้างที่ถูกบล็อก และสร้าง audit ที่แยกข้ออ้างที่ยืนยันได้ หลักฐานที่รองรับเท่านั้น ข้ออ้างที่ติดบล็อก และความไม่แน่นอนที่เหลืออยู่

ใช้ Goals กับงานวิจัยที่ซับซ้อน: กรณีศึกษาการทำซ้ำบทความควอนต์

• ภาพรวมกรณีศึกษา

  • เป้าหมาย: บทความ Deep Hedging ของ Buehler, Gonon, Teichmann, Wood
  • หัวข้อของบทความ: กลยุทธ์การเทรดด้วยโครงข่ายประสาทสามารถทำซ้ำการ hedge แบบอิงโมเดลได้หรือไม่ ภายใต้ risk preference, transaction costs และสภาพตลาดมิติสูง
  • Goal ที่ถูกต้องไม่ใช่แค่ "ทำซ้ำบทความ" แบบนามธรรม แต่ต้องพยายามกับตัวเลขเด่น แยกกลไกที่แม่นยำออกจากตัวแทนการเรียนรู้แบบประมาณ และระบุอย่างชัดเจนว่าส่วนใดทำซ้ำแบบตรงเป๊ะไม่ได้ด้วยวัสดุที่มีอยู่

• Goal งานวิจัยแบบอ่อน vs แบบแข็งแรง

  • แบบอ่อน: /goal Reproduce Buehler et al., "Deep Hedging"
    • ไม่ได้กำหนดว่าส่วนไหนสำคัญ อะไรนับว่าเป็นการทำซ้ำ จะจัดการการไม่มีสถานะการฝึกอย่างไร หรือจะแยกความใกล้เคียงจากการทำซ้ำตรงตามต้นฉบับอย่างไร
  • แบบแข็งแรง: /goal Produce the strongest evidence-backed reproduction of Buehler et al., "Deep Hedging," using the available paper materials and local resources. Attempt every headline result, verify the outputs, and end with a report that separates reproduced mechanics, approximate trained results, blocked exact replay, and remaining uncertainty.

• สิ่งที่ Codex ทำจริง

  • แยกข้ออ้างหลักออกจากข้ออ้างสนับสนุน
  • จับคู่ข้ออ้างกับหลักฐานที่มี
  • สร้างใหม่ในส่วนที่ทดสอบได้บนเครื่องโลคัล
  • ติดป้ายข้ออ้างที่ไม่สามารถทำซ้ำได้อย่างแม่นยำจากวัสดุที่มี

• ส่วนที่ทำได้จริง

  • สร้างกลไกการตั้งราคาและการ hedge ขึ้นใหม่
  • ทำซ้ำราคาอ้างอิงแบบ Heston
  • ฝึกนโยบายสำหรับการทดลอง hedge แบบ CVaR
  • สร้าง histogram หลักและ hedge surface ขึ้นใหม่
  • ทำซ้ำความชันของต้นทุนธุรกรรมใน Black-Scholes
  • รันการตรวจสอบแบบฝึกแล้วสำหรับต้นทุนธุรกรรม Heston และตัวอย่างมิติสูง

• ส่วนที่ยังเป็นตัวบล็อก

  • บทความไม่ได้ให้ random seed ที่แน่นอน, เส้นทางการฝึกที่สร้างไว้, TensorFlow graph, optimizer state, checkpoint หรือสถานะ simulation ดั้งเดิมทั้งหมด
  • ดังนั้นผลลัพธ์ที่ซื่อสัตย์ที่สุดคือ การทำซ้ำบางส่วนและเชิงประมาณ ไม่ใช่การสร้างโครงข่ายประสาทเดิมขึ้นมาใหม่แบบตรงเป๊ะ

• รักษาระดับการรองรับเชิงญาณวิทยาไว้ในรายงาน

  • ตัวแทนที่เรียนรู้ขึ้นใหม่อาจช่วยสนับสนุนข้ออ้างได้ ความใกล้เคียงของตัวเลขอาจเพิ่มความน่าเชื่อถือ และรูปที่สร้างใหม่อาจตรวจสอบผลลัพธ์บางส่วนได้ แต่ทั้งหมดนี้ไม่ควรถูกอธิบายว่าเป็นการคืนสภาพการทดลองต้นฉบับอย่างแม่นยำ
  • ตัวอย่าง ledger:
    • Claim: Deep hedging approximates complete-market Heston hedge without transaction costs
    • Route: สร้างกลไกของโมเดลใหม่, เปรียบเทียบกับ reference hedge, ฝึกนโยบายโครงข่ายประสาท
    • Evidence surface: การตรวจสอบราคา, histogram, hedge surface
    • Status: Close approximate reproduction
    • Remaining uncertainty: ไม่สามารถใช้เส้นทางการฝึกเดิม, seed เดิม, หรือ checkpoint เดิมได้
• คุณค่าของ Goals ในงานวิจัยคือช่วยให้งานดำเนินต่อได้แม้อยู่ท่ามกลางความกำกวม พร้อมทั้งป้องกันไม่ให้ผลลัพธ์ที่ดูน่าเชื่อถือกลายเป็นข้อสรุปที่เกินจริง โดยนิยามความหมายของคำว่าเสร็จให้เป็น การตรวจสอบข้ออ้างรายข้อบนพื้นฐานหลักฐาน การระบุความเป็นประมาณอย่างชัดเจน และความซื่อสัตย์ต่อเส้นแบ่งระหว่างการทำซ้ำกับการเล่นซ้ำแบบตรงตัว

เมื่อใดไม่ควรใช้ Goals

• ไม่เหมาะกับการแก้ไขหนึ่งบรรทัด การอธิบายง่าย ๆ การรีวิวโค้ดสั้น ๆ หรือคำถามที่ต้องการคำตอบครั้งเดียวแล้วหยุด → พรอมป์ต์ Codex ปกติเหมาะกว่า
• ไม่เหมาะเมื่อเส้นชัยยังคลุมเครือ
  • Make this better ไม่ได้ให้เงื่อนไขความสำเร็จที่เชื่อถือได้
  • Refactor this code ก็ยังอ่อนหากไม่ได้กำหนดสถานะปลายทาง เทสต์ และข้อจำกัดที่คาดหวัง
• ห้ามใช้เพื่อซ่อนความไม่แน่นอน
  • ถ้าข้อมูลอาจใช้งานไม่ได้ ต้องระบุไว้ใน Goal
  • ถ้า benchmark อาจ flaky ต้องระบุวิธีจัดการ
  • ถ้าอนุญาตให้ใช้หลักฐานตัวแทน ต้องกำหนดวิธีติดป้ายให้ชัด
• Goals จะแข็งแรงที่สุดเมื่อมี 3 คุณสมบัติร่วมกัน: เป้าหมายต่อเนื่อง เส้นชัยที่อิงหลักฐาน และเส้นทางที่ต้องมีการสืบสวนหลายเทิร์น

บทสรุป: ให้เป้าหมายดำเนินต่อ แต่ให้หลักฐานเป็นผู้ตัดสินความสำเร็จ

• Goals เปลี่ยนโมเดลการทำงานของ Codex โดยเปลี่ยนเธรดจากลำดับของพรอมป์ต์ที่แยกขาดจากกัน ให้กลายเป็น ลูปการทำงานแบบมีสถานะ ที่ยึดผลลัพธ์ที่กำหนดไว้เป็นศูนย์กลาง
• สถาปัตยกรรมถูกออกแบบให้มีขอบเขตอย่างตั้งใจ
  • Goal ถูกจำกัดขอบเขตอยู่ในเธรด มีสถานะวงจรชีวิตและบัญชีงบประมาณ และสามารถถูกพัก ดำเนินต่อ ลบ ทำเสร็จ หรือหยุดเพราะงบประมาณได้
  • Codex อาจทำงานต่อได้ แต่ทำได้เฉพาะภายในสัญญาที่ผู้ใช้กำหนดไว้เท่านั้น
• ฟีเจอร์นี้มีประโยชน์มากกับงานที่ Codex สร้างคุณค่าได้ดีที่สุดอยู่แล้ว นั่นคือ debugging, optimization, migration, testing, research
• ผู้ใช้เป็นผู้กำหนดเป้าหมาย Codex เป็นผู้ติดตามหลักฐาน และ Goal เชื่อมทั้งสองเข้าด้วยกันจนกว่างานจะสำเร็จหรือถูกบล็อกอย่างซื่อสัตย์
• สำหรับงานวิจัยที่ซับซ้อน มันสร้างความแตกต่างระหว่างการสร้างคำตอบ กับการสร้าง audit
• Goal ที่ดีไม่ได้เพียงบอก Codex ให้ทำให้จบ แต่บอกด้วยว่า คำว่าจบหมายถึงอะไร

[hmmhmmhm]

/goal กรุณาตรวจสอบทุกอย่างที่พอจะทำได้จากงานที่ฉันเคยทำไว้ก่อนหน้านี้และดำเนินการต่อให้เสร็จภายในเวลา 12 นาฬิกาช่วงพักกลางวัน ห้ามหยุดงานก่อน 12 นาฬิกา