การออกแบบ Agentic Loop

• เอเจนต์สำหรับงานเขียนโค้ดอย่าง Claude Code ของ Anthropic และ Codex CLI ของ OpenAI ยกระดับประโยชน์ของ LLM ในการสร้างโค้ดที่ใช้งานได้อย่างมีนัยสำคัญ โดยสามารถรันโค้ดเอง แก้ข้อผิดพลาด สำรวจ implementation เดิม และค้นหาโซลูชันที่มีประสิทธิภาพผ่านการทดลองได้
• เทคนิคสำคัญในการดึงศักยภาพของเครื่องมือเหล่านี้ออกมาให้เต็มที่คือ การออกแบบ Agentic Loop โดยหากย่อยปัญหาให้เอเจนต์เขียนโค้ดมีเป้าหมายและชุดเครื่องมือที่ชัดเจน ก็จะมองมันได้ว่าเป็นเครื่องมือที่ค้นหาโซลูชันที่ใช้ได้จริงด้วยแนวทาง brute force
• คำจำกัดความของ LLM agent คือ การรันเครื่องมือภายในลูปเพื่อให้บรรลุเป้าหมาย และทักษะสำคัญในการใช้งานให้ดีคือการออกแบบทั้งเครื่องมือและลูปที่เอเจนต์จะใช้ให้รอบคอบ
• โหมด YOLO (ทุกคำสั่งได้รับการอนุมัติโดยอัตโนมัติเป็นค่าเริ่มต้น) มีความเสี่ยง แต่เป็นกุญแจสำคัญในการได้ผลลัพธ์ที่มีประสิทธิภาพสูงสุดจากการลองผิดลองถูกแบบ brute force และสามารถเลือกรันอย่างปลอดภัยผ่าน Docker sandbox, สภาพแวดล้อมคอมพิวเตอร์อื่นอย่าง GitHub Codespaces หรือยอมรับความเสี่ยงได้
• การเลือกเครื่องมือที่เหมาะสม (คำสั่งเชลล์และแพ็กเกจ), การออก credential ที่จำกัดขอบเขตอย่างเข้มงวด (สภาพแวดล้อมทดสอบ, ขีดจำกัดงบประมาณ), และการนำไปใช้กับปัญหาที่มีเกณฑ์ความสำเร็จชัดเจนและต้องอาศัยการลองผิดลองถูก (debugging, performance optimization, dependency upgrade, container optimization) คือ หลักการสำคัญของการออกแบบ Agentic Loop

---

ความสนุกของโหมด YOLO

• ความเสี่ยงของเอเจนต์

  • เอเจนต์มีความเสี่ยงโดยธรรมชาติ
    • อาจตัดสินใจผิดพลาด หรือเป็นเหยื่อของ การโจมตีแบบ prompt injection
    • อาจก่อให้เกิดผลเสียจากการเรียกใช้เครื่องมือ
  • เพราะเครื่องมือเอเจนต์เขียนโค้ดที่ทรงพลังที่สุดคือ "รันคำสั่งนี้ในเชลล์" เอเจนต์ที่ทำงานผิดพลาดจึงสามารถทำทุกอย่างที่ผู้ใช้ทำได้หากไปรันคำสั่งนั้นเอง
  • คำกล่าวของ Solomon Hykes:

    AI agent คือ LLM ที่ทำลายสภาพแวดล้อมอยู่ในลูป

• ข้อจำกัดของโหมดอนุมัติแบบค่าเริ่มต้น

  • เอเจนต์เขียนโค้ดอย่าง Claude Code จัดการเรื่องนี้โดยตั้งค่าเริ่มต้นให้ขออนุมัติเกือบทุกคำสั่งที่มันจะรัน
  • แม้จะน่าเบื่ออยู่บ้าง แต่ที่สำคัญกว่านั้นคือมัน ลดประสิทธิภาพ ของการแก้ปัญหาด้วยการ brute force ลงอย่างมาก

• โหมด YOLO

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

• ความเสี่ยงหลัก 3 ประการของโหมด YOLO แบบไร้คนดูแล

  • 1. คำสั่งเชลล์ที่ไม่ดี: ลบหรือทำลายสิ่งสำคัญ
  • 2. การโจมตีเพื่อขโมยข้อมูล: ขโมยไฟล์หรือข้อมูลที่เอเจนต์มองเห็นได้ (ซอร์สโค้ดหรือความลับที่เก็บไว้ใน environment variable)
  • 3. การโจมตีแบบ proxy: ใช้เครื่องเป็นพร็อกซีเพื่ออำพรางต้นทางของ DDoS หรือการโจมตีแฮ็กอื่นต่อเป้าหมายภายนอก

ตัวเลือกในการรันโหมด YOLO

• ตัวเลือก 1: sandbox ด้านความปลอดภัย

  • รันเอเจนต์ใน sandbox ที่จำกัดไฟล์ ความลับ และการเชื่อมต่อเครือข่ายที่เข้าถึงหรือสร้างได้
  • แม้จะยังมีโอกาส container escape แต่การใช้ Docker หรือเครื่องมือคอนเทนเนอร์ใหม่ของ Apple ก็เป็นความเสี่ยงที่คนส่วนใหญ่น่าจะยอมรับได้
  • เอกสาร Safe YOLO mode ของ Anthropic:
    • ใช้ --dangerously-skip-permissions ภายในคอนเทนเนอร์ที่ไม่มีการเข้าถึงอินเทอร์เน็ต
    • มี reference implementation ที่ใช้ Docker Dev Containers
    • การจำกัดการเข้าถึงอินเทอร์เน็ตให้เหลือเฉพาะรายการโฮสต์ที่เชื่อถือได้ เป็นวิธีที่ดีในการป้องกันการขโมยซอร์สโค้ดส่วนตัว

• ตัวเลือก 2: ใช้คอมพิวเตอร์ของคนอื่น (แนะนำ)

  • ต่อให้เอเจนต์ทำงานผิดพลาด ความเสียหายก็ยังจำกัดอยู่
  • แนะนำให้ใช้ GitHub Codespaces:
    • มีสภาพแวดล้อมคอนเทนเนอร์เต็มรูปแบบแบบ on-demand ที่เข้าถึงผ่านเบราว์เซอร์ได้
    • มี free tier ที่ค่อนข้าง generous
    • หากเกิดปัญหา อย่างมากก็เป็นเครื่อง Microsoft Azure ที่อยู่ที่ไหนสักแห่งซึ่งเปลือง CPU และในกรณีเลวร้ายที่สุด โค้ดที่ checkout ไว้ในสภาพแวดล้อมอาจรั่วไหลไปถึงผู้โจมตี หรือโค้ดอันตรายอาจถูก push ไปยัง GitHub repository ที่เชื่อมต่ออยู่
  • เครื่องมือแนวเอเจนต์อื่นที่รันโค้ดบนคอมพิวเตอร์ของคนอื่น:
    • โหมด Code Interpreter ของ ChatGPT และ Claude
    • Codex Cloud ของ OpenAI

• ตัวเลือก 3: ยอมรับความเสี่ยง

  • พยายามหลีกเลี่ยงการเจอกับแหล่งคำสั่งที่อาจเป็นอันตราย และหวังว่าจะจับความผิดพลาดได้ก่อนเกิดความเสียหาย
  • เป็นตัวเลือกที่คนส่วนใหญ่เลือก

การเลือกเครื่องมือที่เหมาะกับลูป

• หลังทำให้โหมด YOLO ปลอดภัยแล้ว

  • ขั้นต่อไปคือการตัดสินใจว่าควรเปิดให้เอเจนต์เขียนโค้ดใช้เครื่องมืออะไรได้บ้าง

• ให้ความสำคัญกับคำสั่งเชลล์ก่อน

  • ณ จุดนี้สามารถผสม MCP (Model Context Protocol) เข้าไปได้ แต่โดยทั่วไปการคิดในมุมของคำสั่งเชลล์มักให้ผลดีกว่า
  • เอเจนต์เขียนโค้ด เก่งมาก ในการรันคำสั่งเชลล์
  • ถ้าสภาพแวดล้อมเปิดให้ใช้เครือข่ายที่ต้องการ มันก็สามารถดึงแพ็กเกจเพิ่มเติมจาก NPM, PyPI ฯลฯ ได้ด้วย
  • อีกจุดสำคัญคือควรให้เอเจนต์ทำงานในสภาพแวดล้อมที่การติดตั้งแพ็กเกจสุ่ม ๆ จะไม่ทำให้เครื่องหลักพัง

• ใช้ไฟล์ AGENTS.md

  • แทนที่จะพึ่ง MCP ผู้เขียนชอบสร้างไฟล์ AGENTS.md (หรือไฟล์เทียบเท่า) ที่ใส่รายละเอียดของแพ็กเกจที่คิดว่าควรใช้
  • ตัวอย่าง: สำหรับโปรเจ็กต์ที่ต้องถ่าย screenshot ของหลายเว็บไซต์ ผู้เขียนติดตั้งเครื่องมือ CLI ของตัวเองชื่อ shot-scraper และเพิ่มข้อความต่อไปนี้ลงใน AGENTS.md:

    หากต้องการถ่าย screenshot ให้รัน:  
    
    shot-scraper http://www.example.com/ -w 800 -o example.jpg  
    

  • แค่ตัวอย่างเดียวนี้ก็เพียงพอให้เอเจนต์เดาได้ว่าจะสลับ URL และชื่อไฟล์อย่างไรสำหรับ screenshot อื่น ๆ

• ใช้เครื่องมือที่มีอยู่แล้ว

  • LLM ที่ดีนั้นรู้วิธีใช้ เครื่องมือเดิมที่มีอยู่จำนวนมากจนน่าตกใจ อยู่แล้ว
  • ถ้าบอกว่า "ใช้ playwright python" หรือ "ใช้ ffmpeg" โมเดลส่วนใหญ่ก็จะใช้งานได้อย่างมีประสิทธิภาพ
  • เพราะมันทำงานอยู่ในลูป จึงมักฟื้นตัวจากความผิดพลาดช่วงแรก และหาลำดับคำสั่งที่ถูกต้องได้เองโดยไม่ต้องมีคำแนะนำเพิ่ม

การออก credential ที่จำกัดขอบเขตอย่างเข้มงวด

• ความจำเป็นของ credential

  • นอกจากต้องเปิดเผยคำสั่งที่ถูกต้องแล้ว ยังต้องคิดด้วยว่าควรเปิดเผย credential อะไรให้คำสั่งเหล่านั้นเข้าถึงได้บ้าง
  • ในอุดมคติไม่ควรต้องใช้ credential เลย (หลายงานทำได้โดยไม่ต้องล็อกอินหรือให้ API key) แต่บางปัญหาต้องใช้งานแบบยืนยันตัวตน

• คำแนะนำหลัก 2 ข้อ

  • 1. ให้ credential สำหรับ สภาพแวดล้อมทดสอบหรือ staging
    • เป็นสภาพแวดล้อมที่จำกัดความเสียหายได้ดี
  • 2. ตั้งขีดจำกัดงบประมาณ
    • หาก credential นั้นสามารถใช้จ่ายเงินได้ ควรกำหนดงบประมาณอย่างเข้มงวด

• กรณีใช้งานจริง: การสืบค้นบน Fly.io

  • สืบค้นปัญหา cold start ที่ช้าของแอปพลิเคชันแบบ scale-to-zero ที่รันอยู่บน Fly.io
  • เปิดให้ Claude Code แก้ไข Dockerfile โดยตรง, deploy ไปยังบัญชี Fly และวัดเวลาที่ใช้ในการเริ่มต้น

  • การตั้งค่าที่ปลอดภัย

    • บน Fly สามารถสร้าง organization ตั้ง budget limit สำหรับ organization นั้น และออก Fly API key ที่สร้างหรือแก้ไขแอปได้เฉพาะภายใน organization นั้น
    • สร้าง organization แยกเฉพาะสำหรับการสืบค้นครั้งนี้
    • ตั้งงบประมาณไว้ที่ $5
    • ออก API key แล้วปล่อย Claude Code ทำงาน
  • แม้ผลลัพธ์ในกรณีนี้จะไม่ได้มีประโยชน์มากพอ แต่เป็นโปรเจ็กต์แรกที่ทำให้ผู้เขียนตระหนักว่า "การออกแบบ Agentic Loop" คือทักษะสำคัญที่ควรพัฒนา

ควรออกแบบ Agentic Loop เมื่อไร

• รูปแบบปัญหาที่เหมาะสม

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

• ตัวอย่างที่เป็นรูปธรรม

  • การดีบัก

    • เทสต์ล้มเหลวและต้องสืบหาต้นตอของปัญหา
    • เอเจนต์เขียนโค้ดที่รันเทสต์ได้อยู่แล้วสามารถทำสิ่งนี้ได้ทันทีโดยไม่ต้องตั้งค่าเพิ่ม

  • การปรับแต่งประสิทธิภาพ

    • SQL query ช้าเกินไป การเพิ่ม index จะช่วยไหม?
    • เอเจนต์สามารถ benchmark query และ (ในสภาพแวดล้อมพัฒนาแบบแยกส่วน!) เพิ่มหรือลบ index เพื่อวัดผลกระทบได้

  • การอัปเกรด dependency

    • ตามหลัง dependency หลายตัวอยู่มาก
    • หากมี test suite ที่แข็งแรง Agentic Loop สามารถอัปเกรดทั้งหมดและทำการแก้ไขเล็กน้อยที่จำเป็นเพื่อรองรับ breaking change ได้
    • ควรมีสำเนา release note ที่เกี่ยวข้องให้ หรืออย่างน้อยต้องแน่ใจว่าเอเจนต์รู้ว่าจะหาได้จากที่ไหน

  • การปรับขนาดคอนเทนเนอร์

    • Docker container มีขนาดใหญ่เกินกว่าจะยอมรับได้
    • เอเจนต์สามารถลอง base image แบบต่าง ๆ และวนแก้ Dockerfile เพื่อลดขนาดลง โดยยังทำให้เทสต์ผ่านอยู่เสมอ

• ธีมร่วม: automated testing

  • สิ่งที่ทุกกรณีมีร่วมกันคือ automated testing
  • คุณค่าที่ได้จากเอเจนต์เขียนโค้ดและเครื่องมือเขียนโค้ดด้วย LLM อื่น ๆ จะ เพิ่มขึ้นอย่างมาก หากมี test suite ที่ดีและผ่านอย่างสะอาด
  • โชคดีที่ LLM เก่งมากในการเร่งกระบวนการสร้างสิ่งเหล่านี้ หากคุณยังไม่มี

ยังเป็นพื้นที่ใหม่มาก

• การออกแบบ Agentic Loop เป็นทักษะที่ใหม่มาก
  • Claude Code เปิดตัวครั้งแรกในเดือนกุมภาพันธ์ 2025
• ผู้เขียนหวังว่าการตั้งชื่อที่ชัดเจนจะช่วยให้เกิดการพูดคุยเชิงสร้างสรรค์เกี่ยวกับเรื่องนี้ได้
• ยังมีสิ่งที่ต้องเรียนรู้อีก มากมายมหาศาล เกี่ยวกับวิธีใช้เครื่องมือเหล่านี้ให้มีประสิทธิภาพที่สุด