เหตุผลที่ควรลองสร้างเอเจนต์ด้วยตัวเอง

 (fly.io)
51 คะแนน โดย GN⁺ 2025-11-07 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • LLM agent เป็นโครงสร้างเทคโนโลยีที่ควรได้ลองลงมือทำเอง มากกว่าจะเข้าใจแค่ในเชิงแนวคิด เพื่อให้สัมผัสกลไกการทำงานได้จริง
  • ใช้โค้ด Python เพียงไม่กี่สิบบรรทัดก็สามารถสร้างเอเจนต์แบบโต้ตอบด้วย OpenAI Responses API ได้ และหากเพิ่มความสามารถ tool call เข้าไป ก็จะทำให้ทำงานแบบอัตโนมัติได้
  • หัวใจของเอเจนต์คือ ลูปการเรียกใช้งานซ้ำกับ LLM ที่ไม่มีสถานะ และการจัดการบริบทการสนทนา (context) ด้วยตนเองเพื่อรองรับการสนทนาหลายรอบ
  • Context Engineering เป็นปัญหาในระดับงานเขียนโปรแกรมจริง ที่ต้องออกแบบการปรับอินพุต เอาต์พุต และคำอธิบายเครื่องมือให้เหมาะสมภายใต้ข้อจำกัดของโทเค็น
  • การออกแบบเอเจนต์ในปัจจุบันยังเป็น พื้นที่ปัญหาด้านวิศวกรรมซอฟต์แวร์แบบเปิด ที่นักพัฒนารายบุคคลก็สามารถลองแนวทางใหม่ ๆ ผ่านการทดลองได้

ความเรียบง่ายของการเขียนเอเจนต์

  • LLM agent สามารถสร้างได้ด้วย OpenAI Responses API เพียงตัวเดียว โดยไม่ต้องมีการตั้งค่าซับซ้อน
    • ในโค้ดตัวอย่างใช้ลิสต์ context สำหรับเก็บบทสนทนาระหว่างผู้ใช้กับโมเดล แล้วเรียกซ้ำเพื่อสร้างคำตอบแบบโต้ตอบคล้าย ChatGPT
  • สามารถสร้างสองบริบทที่มี “บุคลิกดี” และ “บุคลิกแย่” เพื่อจำลอง การสนทนาแบบหลายบุคลิก ได้
    • LLM ไม่มีสถานะ และความต่อเนื่องของบทสนทนาจะคงอยู่ผ่าน อาร์เรย์ของสตริง (context) ที่ผู้ใช้เป็นผู้จัดการเอง
  • เพียงโครงสร้างเรียบง่ายแบบนี้ก็รองรับ การสนทนาหลายรอบ ได้ และช่วยให้เข้าใจหลักการทำงานของ LLM จากการลงมือทำจริง

การผสานเครื่องมือ (tool) และการทำงานแบบอัตโนมัติ

  • เพิ่มฟังก์ชัน ping เป็นเครื่องมือให้เอเจนต์ เพื่อตรวจสอบสถานะการเชื่อมต่อเครือข่าย
    • OpenAI API ต้องการการนิยามเครื่องมือในรูปแบบ JSON และเมื่อ LLM ขอเรียกใช้เครื่องมือ โค้ด Python ก็จะรันเครื่องมือนั้นแล้วส่งผลลัพธ์กลับไป
  • แม้ไม่มีคำสั่งชัดเจน LLM ก็สามารถ ping หลายโฮสต์ (google.com, www.google.com, 8.8.8.8) โดยอัตโนมัติได้
    • สิ่งนี้แสดงให้เห็นว่า เพียงมี “สิทธิ์ใช้เครื่องมือ” LLM ก็สามารถ ตัดสินใจเชิงอัตโนมัติ ได้
  • ลูปทั้งหมดมีโครงสร้างเพียง “ขอเรียกเครื่องมือ → รัน → ส่งผลลัพธ์กลับ” ทำให้สร้าง เอเจนต์อัตโนมัติได้โดยไม่ต้องมีลอจิกควบคุมที่ซับซ้อน

การใช้งานจริงและคำวิจารณ์ต่อ MCP

  • แม้โค้ดตัวอย่างจะเรียบง่าย แต่หากผสาน เครื่องมือเพิ่มเติม (เช่น traceroute) หรือ การเก็บ context บน SQLite ก็สามารถขยายไปใช้งานจริงได้
  • MCP (Multi-Context Protocol) เป็นเพียงอินเทอร์เฟซปลั๊กอินของ Claude Code หรือ Cursor ไม่ใช่เทคโนโลยีที่จำเป็น
    • หากจัดการ API โดยตรง ก็สามารถสร้างฟังก์ชันแบบเดียวกันได้โดยไม่ต้องใช้ MCP
  • MCP มีประโยชน์เฉพาะในสภาพแวดล้อมที่ไม่มีสิทธิ์ควบคุมโค้ด และอาจ จำกัดความยืดหยุ่นของสถาปัตยกรรมเอเจนต์ ได้ด้วยซ้ำ
  • แม้ความปลอดภัยของ LLM จะซับซ้อน แต่ก็สามารถออกแบบโครงสร้างที่ปลอดภัยได้ผ่าน การแยก context และการจำกัดเครื่องมือ

ความสำคัญของ Context Engineering

  • “Prompt Engineering” เป็นแนวคิดที่ถูกพูดเกินจริง แต่ Context Engineering คือปัญหาการเขียนโปรแกรมจริง
    • จำนวนโทเค็นใน context window มีจำกัด และทั้งอินพุต เอาต์พุต และคำอธิบายเครื่องมือล้วนใช้พื้นที่
    • หากเกินขีดจำกัดนี้ คุณภาพคำตอบของโมเดลจะเริ่มไม่เสถียร
  • วิธีแก้คือสร้าง sub-agent ที่มี context และเครื่องมือแตกต่างกัน แล้วออกแบบให้สรุปและแลกเปลี่ยนข้อมูลกัน
    • โครงสร้างลักษณะนี้สามารถขยายเป็นการทดลองได้หลายแบบ เช่น เครือข่ายเอเจนต์แบบต้นไม้ หรือ การบีบอัดด้วยสรุปแบบเรียลไทม์
  • แม้เป็นแนวคิดซับซ้อน แต่ก็ยัง เรียบง่ายพอจะลงมือทำได้ภายใน 30 นาที

ปัญหาวิศวกรรมแบบเปิดและคุณค่าของการทดลอง

  • ปัจจุบันมีสตาร์ตอัปจำนวนมากกำลังพัฒนา เอเจนต์สำหรับตรวจจับช่องโหว่ และนักพัฒนารายบุคคลก็สามารถทดลองแบบเดียวกันได้
  • การออกแบบเอเจนต์ยังมี โจทย์วิศวกรรมที่ยังไม่คลี่คลาย เช่น
    • การหาสมดุลระหว่างความไม่เป็นเชิงกำหนดกับการเขียนโปรแกรมแบบมีโครงสร้าง
    • การยืนยันความจริงของข้อมูล (ground truth) และการป้องกันการจบลูปเร็วเกินไป
    • รูปแบบการแลกเปลี่ยนข้อมูลระหว่างเอเจนต์หลายขั้น (JSON, SQL, Markdown ฯลฯ)
    • การจัดสรรโทเค็นและการควบคุมต้นทุน
  • ปัญหาเหล่านี้ไม่จำเป็นต้องอาศัยงานวิจัยขนาดใหญ่ แต่เป็น พื้นที่ที่แม้แต่การทดลองรายบุคคลก็สำรวจได้ และแต่ละรอบทดลองใช้เวลาเพียงไม่กี่สิบนาที
  • โดยสรุปแล้ว ประสบการณ์จากการลองสร้างเอเจนต์ด้วยตัวเอง คือจุดเริ่มต้นของการเข้าใจเทคโนโลยี LLM

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
2025-11-09
[ความคิดเห็นนี้ถูกซ่อน]
 
GN⁺ 2025-11-07
ความคิดเห็นจาก Hacker News

  • มีหลายอย่างที่อยากทำมาก อยากสร้าง CPU จาก NAND gate บนเบรดบอร์ดด้วยตัวเอง และอยากลองทำ CDN ด้วย Rust แต่ไม่มีเวลา
    เลยลองสร้าง LLM ตามบทสอนของ Karpathy แทน แล้วรู้สึกว่าการค่อย ๆ ทดลอง แบบนี้ค่อนข้างดีทีเดียว

    • มันเหมือนเส้นโค้งที่ไม่มีวันจบ ก่อนหน้านี้เคยสร้างคอมพิวเตอร์ 8 บิตบนเบรดบอร์ด แล้วตอนนี้ก็มาหลงใหลการฝึกบิน (PPL)
      ทุกครั้งที่รู้สึกว่า ‘เสร็จแล้ว’ ก็จะเหมือนว่า เส้นชัยยิ่งถอยห่างออกไป สุดท้ายคนแบบพวกเราคงเป็นพวกที่ไม่เคยพอใจอย่างแท้จริง
    • ช่วงต้นของบทความต้นฉบับอธิบายไว้ว่ามันทำได้ง่ายแค่ไหน และนั่นก็คือประเด็นสำคัญของบทความนี้

  • ในตัวอย่างใช้ GPT-5 แต่ query interface นั้นอยู่ในระดับ มาตรฐานอุตสาหกรรม ไปแล้ว
    เช่น ถ้าเชื่อมกับ OpenRouter.ai ก็สามารถสลับโมเดลและผู้ให้บริการระหว่างรันไทม์ได้ง่าย
    มีโมเดลฟรีให้ใช้ด้วย (เช่น DeepSeek) แม้จะช้าและมีข้อจำกัด แต่ก็ยอดเยี่ยมสำหรับการทดลอง

  • เมื่อไม่กี่เดือนก่อนลองสร้าง เอเจนต์ เองด้วย Ruby สนุกมาก
    ลอจิกหลักมีแค่สี่บรรทัด และในเชิงแนวคิดเรียบง่ายจนน่าทึ่ง

    until mission_accomplished? or given_up? or killed?
  determine_next_command_and_inputs
  run_next_command
end

  • เมื่อ 2 ปีก่อนเคยสร้างเอเจนต์ด้วย PHP แค่ 25 บรรทัด ตอนนั้นยังไม่มี tool calling แต่ก็ทำงานได้ดีพอสมควร
    สำหรับฉัน LLM ให้ความรู้สึกเหมือน เครื่องมือจัดการข้อความแบบ UNIX อย่าง sed หรือ awk — คือให้ input กับคำสั่ง แล้วมันก็คืน output ออกมา
    ถ้านำการเรียก LLM แบบนี้มาประกอบกัน แล้วทำเป็นลูปหรือแตกแขนง ก็จะกลายเป็นระบบที่ทรงพลังมาก
    โค้ดที่เกี่ยวข้อง: hubcap, llm

    • ชอบ hubcap มาก ถึงโค้ดจะน้อยแต่ ผลลัพธ์น่าประทับใจ
      ได้แรงบันดาลใจอย่างมากจาก บทความของ Simon Willison

  • ส่วนที่พูดถึงการสร้างทางเลือกแทน Claude Code เองนั้นโดนใจมาก การสร้าง coding agent ที่พัฒนาตัวเองได้ เป็นประสบการณ์ที่แทบเหมือนเวทมนตร์
    สามารถสลับโมเดลได้อย่างอิสระ และถ้าใช้โมเดลเร็วอย่าง Cerebras ก็จะรู้สึกถึงความต่างอย่างชัดเจนแม้แต่ในเครื่องมือเรียกใช้แบบโต้ตอบ
    ถ้าเพิ่มความจำ การรู้จำเสียง ฯลฯ เข้าไป ก็จะยิ่งมีประสิทธิภาพมากขึ้น ใช้เวลาแค่ไม่กี่นาทีก็ทำได้และสนุกมาก

    • อยากรู้ว่าใช้โมเดลรู้จำเสียงตัวไหน Whisper ทั้งช้าและไม่แม่น ส่วนโมเดลเสียงของ GPT ก็มี การตอบปฏิเสธ บ่อย
      โมเดลของ Google คุณภาพต่ำ และโมเดลของ Mistral ถึงจะเร็วแต่บางครั้งกลับไปตอบสนองต่อข้อความ
      เลยมีบางครั้งที่มันถอดสิ่งที่ฉันพูดออกมาเป็น กระแสสำนึก ของ LLM แทน
    • ชอบวลี “build your own lightsaber” มาก
      ตอนแรกสร้างขึ้นมาเพื่อทำความเข้าใจโครงสร้างภายใน แต่พอพบว่ามันเรียบง่ายกว่าที่คิด ตอนนี้ก็เริ่มเพิ่มฟีเจอร์ที่อยากได้เองแล้ว
      ใส่ฟีเจอร์ได้เร็วกว่าโปรดักต์ระดับทีมเสียอีก เอเจนต์มี โครงสร้างที่เรียบง่ายจนน่าทึ่ง
    • ถ้าจะเริ่มต้นก็ยังไม่รู้ว่าควรเริ่มจากตรงไหน และนี่ก็เป็นครั้งแรกที่ได้ยินชื่อ Cerebras ตอนนี้ใช้แค่ Copilot ใน VS Code
      เลยสงสัยว่านี่เป็นแบบใช้โมเดลโลคัลหรือเปล่า
    • ตอนนี้ Cerebras มี glm 4.6 แล้ว ยังเร็วมากเหมือนเดิม และตอนนี้ฉลาดขึ้นมากด้วย

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

    • ในปี 2021 เคยสร้างเอเจนต์สำหรับทดสอบการเชื่อมต่อเครือข่าย แล้วพบว่าถ้าให้เอเจนต์ใช้เครื่องมือพื้นฐานอย่าง ping, dig, traceroute ก็ให้ผลลัพธ์ที่ดีพอควร
      มันอาจไม่สมบูรณ์เท่าระบบ telemetry ที่มนุษย์สร้างขึ้นเอง แต่สามารถไปถึง ระดับการใช้งานได้จริง 90% ได้ง่ายกว่ามาก
    • อาจจินตนาการถึง ชุดเครื่องมือเพื่อวัตถุประสงค์จำกัด ที่เปิดให้มนุษย์ใช้งานโดยตรงก็ได้
    • การจะทำสิ่งเดียวให้ดีต้องใช้เครื่องมือมากขึ้น และนั่นก็หมายถึง ความเข้าใจบริบท ที่มากขึ้นด้วย
      ขนาดที่เหมาะสมที่สุดของ LLM น่าจะอยู่ตรงกลาง ระหว่างนี้กับเครื่องมือ Unix แบบดั้งเดิม

  • มีคำถามว่า “จำเป็นต้องสร้างเอเจนต์จริงหรือ?”
    ในเมื่อผู้ให้บริการ AI แทบทั้งหมดกำลังขาดทุน ก็เลยสงสัยว่าจะมี โมเดลรายได้ที่ยั่งยืน ได้จริงหรือไม่

    • ถ้าลองสร้างเอง จะเข้าใจทั้งหลักการทำงานและข้อจำกัดของเอเจนต์ได้แบบ เป็นสัญชาตญาณ และนั่นคือประเด็นสำคัญ
    • นี่เป็นแค่บทความชวน ทดลองเทคโนโลยีเพื่อความสนุก ไม่เกี่ยวกับการทำเงิน
      ตรรกะก็คล้ายกับการยกเรื่อง Astral ขาดทุนขึ้นมาเพียงเพราะไม่อยากใช้ Python
    • ไม่ใช่ว่าบริษัท AI ทุกแห่งจะขาดทุนกันหมด
      ที่ต้องใช้เงินก็เพราะต้นทุนการฝึกโมเดลถัดไปสูงมาก แต่ ขั้นตอนการอนุมานยังทำกำไรได้
    • คุณอาจเป็น ผู้ให้บริการ AI เองก็ได้
    • ความเห็นนี้ให้ความรู้สึกเหมือนมี ความเหนื่อยล้าทางอารมณ์ อยู่เล็กน้อย เลยอดสงสัยไม่ได้ว่าเป็นนักพัฒนาที่มีประสบการณ์มานานหรือเปล่า

  • ส่วนของ context engineering โดนใจมากเป็นพิเศษ
    ฉันกำลังสร้างผู้ช่วยส่วนตัวอยู่ ซึ่งมี ความจำ การติดตามงาน และความสามารถในการแก้ปัญหา มากกว่าเอเจนต์ทั่วไป
    ออกแบบให้เอเจนต์หลายตัวคุยกันเพื่อแก้ปัญหา โดยเอเจนต์ตัวแรกทำหน้าที่เป็น ผู้กำกับดูแลงานจัดการงาน
    ยิ่งทำลึกลงไปเท่าไร กระบวนการนี้ก็ยิ่งกลายเป็น ปัญหาเชิงวิศวกรรม มากขึ้นเท่านั้น
    รายละเอียดอยู่ใน โพสต์บล็อกของฉัน

    • ฟังดูเป็นโปรเจกต์ที่เจ๋งมาก

  • ทุกคนชอบสร้างเอเจนต์ แต่ ไม่ชอบดีบัก
    ตอนแรกมันทำงานได้เหมือนเวทมนตร์ แต่พอนานไป ความล้มเหลวเชิงความน่าจะเป็น ก็เริ่มสะสมและทำให้เกิดปัญหาที่ทำซ้ำได้ยาก
    แต่ละขั้นใช้เวลา 0.5 วินาที ดังนั้นถ้าจะหาว่าพลาดตรงไหน ก็ต้องรอครั้งละ 10–20 นาที

    • เพราะแบบนี้ฉันเลยสร้าง เครื่องมือรันแบบขนาน ขึ้นมา เพื่อให้ลองรันโค้ดที่แก้แล้วได้หลายร้อยครั้ง
      และยังย้อนกลับไปรันสถานการณ์เก่า ๆ เพื่อยืนยันว่าไม่มีอะไรพังด้วย

  • ลองสร้าง MCP จากโค้ดที่ให้มาแล้ว: gurddy-mcp.fly.dev
    ดูซอร์สโค้ดได้ที่ GitHub repository