การออกแบบเอเจนต์ยังคงยากอยู่

 (lucumr.pocoo.org)
20 คะแนน โดย GN⁺ 2025-11-23 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • กระบวนการสร้างเอเจนต์ ยังคงซับซ้อน และมีปัญหาที่ abstraction ของ SDK มักพังลงในขั้นตอนใช้งานเครื่องมือจริง
  • การจัดการแคช แตกต่างกันไปในแต่ละแพลตฟอร์ม ทำให้การจัดการด้วยตนเองคาดการณ์ได้และมีประสิทธิภาพมากกว่า โดยผู้เขียนชื่นชอบแนวทางกำหนด cache point แบบ explicit ของ Anthropic SDK
  • reinforcement loop มีบทบาทสำคัญต่อการติดตามสถานะงานและการกู้คืนจากความล้มเหลว และควรแยกความล้มเหลวออกต่างหากเพื่อป้องกันไม่ให้ลูปพัง
  • การจัดการสถานะที่ใช้ร่วมกัน ต้องอาศัยลำดับชั้นที่คล้ายระบบไฟล์ ซึ่งใช้เป็นโครงสร้างพื้นฐานสำหรับการแลกเปลี่ยนข้อมูลระหว่างเครื่องมือรันโค้ดและเครื่องมืออนุมาน
  • เครื่องมือเอาต์พุตและการเลือกโมเดล ยังคงเป็นเรื่องยาก โดยมี Haiku, Sonnet และ Gemini เป็นตัวเลือกหลักต่อไป สะท้อนว่า ความซับซ้อนของการออกแบบเอเจนต์ยังคงอยู่

การเลือก Agent SDK

  • เมื่อสร้างเอเจนต์ จำเป็นต้องเลือกระหว่างการใช้ SDK พื้นฐาน อย่าง OpenAI, Anthropic โดยตรง หรือใช้ ชั้น abstraction ระดับสูง อย่าง Vercel AI SDK หรือ Pydantic
    • ผู้เขียนระบุว่าเคยใช้เฉพาะ provider abstraction ของ Vercel AI SDK ในอดีต แต่ตอนนี้คงไม่เลือกแบบนั้นอีก
  • เนื่องจากความแตกต่างระหว่างโมเดลมีมาก จึงต้อง สร้างชั้น abstraction สำหรับเอเจนต์ขึ้นเอง และ abstraction ของ SDK ที่มีอยู่ไม่เหมาะนัก
    • มีความแตกต่างเล็กน้อยในเรื่องการควบคุมแคช ข้อกำหนดด้าน reinforcement และ tool prompt
  • Vercel SDK มีปัญหาในส่วน การจัดการเครื่องมือฝั่ง provider
    • มีกรณีที่เครื่องมือค้นหาเว็บของ Anthropic ทำให้ประวัติข้อความเสียหาย
    • เมื่อใช้ Anthropic SDK โดยตรง ทั้งการจัดการแคชและข้อความผิดพลาดมีความชัดเจนกว่า
  • โดยสรุป ปัจจุบันมองว่าแนวทาง ใช้ SDK โดยตรงโดยไม่มีชั้น abstraction ได้เปรียบกว่า

บทเรียนจากการจัดการแคช

  • แนวทางการทำแคช แตกต่างกันไปตามแพลตฟอร์ม และ Anthropic คิดค่าใช้จ่ายสำหรับแคชพร้อมกำหนดให้ต้องจัดการอย่างชัดเจน
    • การจัดการด้วยตนเองจึงเป็นที่ชื่นชอบ เพราะทำให้คาดการณ์ต้นทุนและการใช้แคชได้
  • แคชแบบ explicit ช่วยให้ทำ การแตกแขนงของบทสนทนา หรือ การแก้ไขคอนเท็กซ์ ได้
    • สามารถตั้ง cache point ได้หลายจุด เช่น หลัง system prompt หรือช่วงต้นของบทสนทนา
  • เพื่อรักษาแคชไว้ system prompt และการเลือกเครื่องมือควรคงที่ ส่วนข้อมูลที่เปลี่ยนแปลงได้ เช่น เวลา ควรส่งเป็นข้อความภายหลัง
  • มีการใช้ reinforcement loop ร่วมกับแคชอย่างจริงจังเพื่อ เพิ่มความสามารถในการคาดการณ์ต้นทุนและการควบคุม

Reinforcement ภายในลูปของเอเจนต์

  • ระหว่างการรันเครื่องมือ นอกจากคืนผลลัพธ์อย่างเดียวแล้ว ยังสามารถส่งข้อมูลอย่าง เป้าหมาย สถานะงาน และสาเหตุของความล้มเหลว กลับเข้าไปในลูปได้
  • เครื่องมือ self-reinforcement อย่าง todo write ของ Claude Code ช่วยให้ลูปเดินหน้าต่อได้ดีขึ้น
  • เมื่อสภาพแวดล้อมเปลี่ยนหรือถึงจุดต้องกู้คืนจากความล้มเหลว สามารถ ใส่ข้อมูลการเปลี่ยนสถานะ เพื่อรักษาเสถียรภาพของลูป
    • ตัวอย่าง: หากลองใหม่โดยอิงข้อมูลที่เสียหาย ก็แทรกข้อความเพื่อให้ย้อนกลับไปยังขั้นตอนก่อนหน้า

การแยกความล้มเหลว (Isolate Failures)

  • งานที่คาดว่าจะล้มเหลวซ้ำได้ ควรถูกแยกไปทำใน subagent แล้วรายงานเฉพาะผลลัพธ์ที่สำเร็จกลับมายังลูประดับบน
    • สรุปความพยายามที่ล้มเหลวสามารถนำไปใช้เป็นข้อมูลเรียนรู้สำหรับงานถัดไปได้
  • ใน Anthropic SDK สามารถลบบันทึกความล้มเหลวได้ด้วยฟีเจอร์ context editing
    • ไม่จำเป็นต้องเก็บข้อมูลความล้มเหลวทั้งหมดไว้ แต่เก็บเฉพาะส่วนที่จำเป็น
    • อย่างไรก็ตาม context editing อาจทำให้แคชใช้งานไม่ได้และเพิ่มต้นทุน

ซับเอเจนต์และระบบไฟล์ที่ใช้ร่วมกัน

  • เอเจนต์ส่วนใหญ่ทำงานบนพื้นฐานของ การรันโค้ดและการสร้างผลลัพธ์ จึงต้องมีที่เก็บข้อมูลส่วนกลาง
    • เพื่อจุดนี้จึงใช้ virtual file system (VFS)
  • เครื่องมือหลากหลายอย่างการสร้างภาพ การบีบอัด และการอนุมาน จำเป็นต้อง ใช้พาธไฟล์เดียวกันร่วมกัน
    • เครื่องมือ ExecuteCode และ RunInference ต้องเข้าถึงระบบไฟล์เดียวกันได้
  • โครงสร้างแบบนี้จำเป็นต่อ การลดคอขวดในการแลกเปลี่ยนข้อมูล และ การจัดการงานต่อเนื่องภายในลูป

เครื่องมือเอาต์พุต (Output Tool)

  • เอเจนต์ไม่ได้ทำงานเป็นแชตเซสชัน แต่ทำงานเป็น ลูปข้อความภายในแบบส่วนตัว และสื่อสารกับภายนอกผ่าน เครื่องมือเอาต์พุต
    • เครื่องมือเอาต์พุตรับหน้าที่การสื่อสารภายนอก เช่น การส่งอีเมล
  • การควบคุม น้ำเสียงและสำนวน ของเครื่องมือเอาต์พุตทำได้ยาก และเมื่อใช้ LLM ผู้ช่วยอย่าง Gemini 2.5 Flash ก็เกิดทั้งคุณภาพที่ลดลงและความหน่วง
    • เพราะเครื่องมือย่อยมีคอนเท็กซ์ไม่เพียงพอ จึงสร้างผลลัพธ์ที่ไม่แม่นยำ
  • หากเมื่อจบลูปแล้วยังไม่ได้เรียกเครื่องมือเอาต์พุต จะใช้ การแทรกข้อความ reinforcement เพื่อกระตุ้นให้มีการเรียกใช้

การเลือกโมเดล

  • Haiku และ Sonnet มีประสิทธิภาพดีในการเรียกใช้เครื่องมือ จึงถูกใช้เป็นโมเดลหลักของลูป
  • Gemini 2.5 เหมาะกับการสรุปเอกสารขนาดใหญ่ การจัดการ PDF และการดึงข้อมูลจากภาพ
    • ข้อเสียของ Sonnet คือมักติดตัวกรองความปลอดภัยบ่อย
  • โมเดลตระกูล GPT ไม่ได้ให้ผลลัพธ์โดดเด่นนักในลูปหลัก
  • ไม่สามารถประเมินต้นทุนรวมจากค่าโทเค็นเพียงอย่างเดียวได้
    • โมเดลที่เรียกใช้เครื่องมือได้ดีกว่าอาจทำงานเดียวกันได้ด้วยโทเค็นน้อยกว่า

การทดสอบและการประเมินผล (Evals)

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

อัปเดตเกี่ยวกับโค้ดดิ้งเอเจนต์

  • ความเปลี่ยนแปลงเกี่ยวกับโค้ดดิ้งเอเจนต์ยังไม่มากนัก
    • ช่วงนี้กำลังทดลองเอเจนต์ Amp และชื่นชม โครงสร้างปฏิสัมพันธ์ระหว่าง Oracle subagent กับลูปหลัก อย่างมาก
  • Amp และ Claude Code ให้ความรู้สึกว่าเป็น การออกแบบที่ยึดนักพัฒนาเป็นศูนย์กลาง โดยผู้สร้างใช้งานเครื่องมือของตนเองจริง

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

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

 
GN⁺ 2025-11-23
ความเห็นจาก Hacker News

  • เมื่อประมาณ 2 ปีก่อน ผมก่อตั้งบริษัทในสายนี้ ตอนนี้ธุรกิจกำลังไปได้ดี
    สิ่งที่ได้เรียนรู้ตลอด 2 ปีที่ผ่านมาคือ เทคนิคหลายอย่างเป็นเพียงการปรับแต่งชั่วคราวเพื่อชดเชยข้อจำกัดปัจจุบันของ LLM เท่านั้น เพราะเทคโนโลยีพัฒนาเร็วมาก ปัญหาวันนี้อาจหายไปพรุ่งนี้ก็ได้
    เมื่อก่อนตอน AWS ยังไม่มีฟีเจอร์เข้ารหัสดิสก์ ทีมของผมใช้เวลา 3 เดือนทำมันขึ้นมาเอง แต่ไม่นาน AWS ก็ออกระบบเข้ารหัสมาตรฐานที่กดปุ่มครั้งเดียวใช้ได้เลย สุดท้ายจึงกลายเป็นการเสียเวลา
    เพราะฉะนั้นสิ่งที่ได้เรียนรู้คือ บางครั้ง การไม่ทำอะไรเลยคือทางเลือกที่ดีที่สุด

    • ผมคิดว่านี่คือข้อสังเกตที่สำคัญมาก ทุกวันนี้เพื่อนร่วมงานในบริษัทชอบจัด AI workshop แล้วบอกว่าค้นพบแพตเทิร์นใหม่ แต่ส่วนใหญ่พอถึงสัปดาห์หน้าก็ล้าสมัยแล้ว
      ยุคที่เราเรียนรู้แพตเทิร์นผ่านภาษากลางแบบเดิมได้จบลงไปแล้ว ตอนนี้ ครึ่งชีวิตของแพตเทิร์น AI น่าจะอยู่ราว ๆ หนึ่งสัปดาห์ แม้แต่ถ้าไปถามผู้เชี่ยวชาญ 10 คนว่า “agent” คืออะไร ก็มักจะได้คำตอบ 10 แบบ
    • ถ้าดูจากความเร็วในการพัฒนา AI ก็เป็นไปได้ว่าถ้ารอนานพอ สุดท้ายทุกอย่างจะลงเอยที่ การใช้ OpenAI โดยตรง
    • อยากรู้ว่าตอนนี้เป็นโครงสร้าง มีกำไรที่รายรับมากกว่าค่าใช้จ่ายในการดำเนินงาน หรือเปล่า เพราะผมเคยมองว่าน่าจะทำเงินจาก agent ได้ยาก อยากรู้ว่าเคล็ดลับคืออะไร
    • การรู้ว่าเมื่อไรควร ‘ไม่ทำอะไร’ เกี่ยวข้องกับ ความสามารถในการประเมินว่าปัญหาที่ทีมกำลังจัดการเป็นเรื่องแกนหลักหรือเป็นเพียงเรื่องปลายทาง
    • เห็นด้วย ทุกวันนี้การรอก็อาจเป็นกลยุทธ์ได้เหมือนกัน แต่ถ้ารอนานเกินไปก็อาจตกหลุมพรางของการ ไม่ทำอะไรเลยจนกว่า AGI จะมาถึง

  • ตลอด 2 ปีที่ผ่านมา ผมลองใช้ agent SDK มาหลายตัว และพอลองทำเองก็พบว่ามันซับซ้อนกว่าที่คิดมาก
    Claude Code SDK (ปัจจุบันคือ Agent SDK) ยอดเยี่ยมมาก แต่ยังไม่แยกออกจาก Claude Code ได้อย่างสมบูรณ์ ตัวอย่างเช่น skills ยังต้องวางลงในไฟล์ซิสเต็มโดยตรง
    OpenAI SDK มีข้อดีตรงที่ผูกกับแพลตฟอร์มแน่น ทำให้ติดตามและประเมินผลอัตโนมัติจากแดชบอร์ดได้ แต่ เชื่อมต่อโมเดลของผู้ให้บริการรายอื่นได้ยาก
    Google Agent Kit ยังไม่มี Typescript SDK ส่วน Mastra ต้องรันเซิร์ฟเวอร์ ทำให้ไม่สะดวก
    ตอนนี้ผมกำลังทดสอบ SmythOS SDK อยู่ ซึ่งให้อิสระสูงทั้งในแง่การเลือกผู้ให้บริการโมเดลและการกำหนดสถาปัตยกรรม
    อยากรู้ว่าโครงสร้างที่คุณใช้อยู่ตอนนี้เป็นแบบ Agent → SubAgents → SubSubAgents หรือเป็นแบบ Planner-Executor

    • SDK ส่วนใหญ่พอใช้เกินความสามารถพื้นฐานไปแล้วจะกลายเป็นฝันร้าย ดังนั้นผมเลยใช้ ไลบรารีไคลเอนต์ OpenRouter แล้วทำเองทั้งหมด
      ปริมาณโค้ดเพิ่มขึ้นก็จริง แต่ mental model เรียบง่ายกว่า เลยเข้าใจง่ายกว่ามาก ผมวนลูปแบบ ReAct เพื่อทำ reasoning และเรียกใช้ tool ซ้ำไปมา
      สุดท้ายแล้ว ต่อให้ไม่มี SDK ก็ยังทำ agent handoff หรือเวิร์กโฟลว์เองได้
    • ผมคิดว่าคำว่า ‘sub-agent’ แทบไม่มีประโยชน์อะไรเลย เพราะสุดท้ายมันก็เป็นแค่ นามธรรมครอบการเรียกใช้เครื่องมือ และนอกลูปหลักแล้ว สิ่งสำคัญมีเพียงสัญญา input/output ที่ชัดเจนเท่านั้น
    • มีคนบอกว่า Claude Code รองรับแค่โมเดลของ Anthropic แต่ถ้าใช้ Claude Code Router ก็ เชื่อมต่อโมเดลอื่นได้เหมือนกัน
    • ผมใช้ Google ADK เวอร์ชัน Go อยู่ แม้จะยังไม่โตเต็มที่ แต่ก็พอใจมากเพราะ จัดองค์ประกอบเวิร์กโฟลว์ได้ดีและเข้ากันได้กับผู้ขายหลายราย
    • ผมก็ลองใช้ Strands Agents SDK ของ AWS มาแล้ว มันรองรับ API ของผู้ขายหลัก ๆ ได้แม้ไม่ใช้ Bedrock และการออกแบบ API ก็ยืดหยุ่นมาก (ผมเป็นพนักงาน AWS แต่นี่เป็นความเห็นส่วนตัว)

  • ขอแชร์ หลักการออกแบบ agent บางข้อที่เราได้เรียนรู้

    1. ถ้ามีงานสร้างโค้ดเยอะ Claude Code / Agent SDK มีประสิทธิภาพที่สุด
    2. ความเสี่ยงที่ใหญ่กว่าการผูกติดกับผู้ขาย คือการสร้างผลิตภัณฑ์ที่แย่กว่า ChatGPT
    3. Claude Code มีความตระหนักรู้ในตัวเองสูงมาก ดังนั้นถ้าถามเรื่องตัวมันเอง มักจะตอบได้ถูกต้องทันที
    4. ถ้าให้คอมพิวเตอร์จริงกับ agent มันจะทรงพลังกว่ามาก เราใช้ e2b.dev แต่ Modal ก็ดีเหมือนกัน
      เผื่อเป็นข้อมูล บริษัทของเรา Definite เป็นแพลตฟอร์มข้อมูล โดยมี AI data engineer ดูแลการทำงานในลักษณะคล้าย Heroku
    • Claude มีความคิดสร้างสรรค์ดี แต่ใน โค้ดเบสที่ซับซ้อนมันอาจตอบมั่วและทำ reward hacking ได้ ในกรณีแบบนี้ Codex จะนิ่งกว่า
    • ผมคิดว่าปัญหาคือมีผลิตภัณฑ์จำนวนมากที่ออกสู่ตลาดด้วยคุณภาพต่ำกว่า ChatGPT บนเว็บเสียอีก
    • แทนที่จะฝืนสร้างระบบ agent ของตัวเอง ควรใช้เครื่องมือสำเร็จรูปอย่าง Claude Code แล้วไปโฟกัสกับการสร้างคุณค่าจริงจะดีกว่า
    • แน่นอนว่าแนวคิดแบบ “ปล่อยให้บิ๊กเทคทำทุกอย่าง” ก็อันตรายเหมือนกัน กระบวนการลงมือสร้าง เรียนรู้ และแบ่งปันด้วยตัวเอง สำคัญมาก ผมเองก็เติบโตเร็วจากการใช้ ADK กับส่วนขยาย VS Code

  • ผมทำ agent มาหลายปีแล้ว และสิ่งที่ดีที่สุดที่ทำคือ สร้างเฟรมเวิร์กขึ้นมาเอง
    ชั้น abstraction แบบโอเพนซอร์สหลายตัวบำรุงรักษาต่อไม่ได้เมื่อ SDK เปลี่ยน สุดท้ายก็พังลง

    • ผมก็คิดเหมือนกัน หัวใจของ Agent คือ input/output แบบมีโครงสร้าง, ลูปสำหรับลงทะเบียนและเรียกใช้ tool, และการส่งต่อภารกิจระหว่าง agent
      ผมสร้าง OpusAgents บน PydanticAI ซึ่งเป็น เฟรมเวิร์กโอเพนซอร์สที่ขยายต่อได้ และเรียบง่ายกว่า MCP server
    • ในฐานะผู้เขียนบทความ ผมเห็นด้วย และได้สรุปความคิดที่เกี่ยวข้องไว้ในโพสต์นี้
    • ตอนเราสร้างแชตบอตสำหรับซัพพอร์ตลูกค้า เราเปลี่ยนจากโครงสร้างเดิมมาใช้ สถาปัตยกรรมแบบ chatroom โดยฝั่งฟรอนต์เอนด์แค่ส่งข้อความเข้าไป แล้วค่อยขยายความสามารถจากฝั่งแบ็กเอนด์แบบค่อยเป็นค่อยไป
    • แต่อย่างไรก็ดี การสร้างเฟรมเวิร์กเต็มรูปแบบเองเป็น งานชิ้นใหญ่ และในระยะยาวก็มีโอกาสที่แพลตฟอร์ม agent จะ กลายเป็นมาตรฐานเหมือน game engine

  • ช่วงนี้มันเหมือนกับยุคแรกของ LangChain/RAG ที่ เต็มไปด้วย abstraction เกินจำเป็นและความซับซ้อน อีกครั้ง
    สุดท้ายแล้ว agent ก็คิดแบบโครงสร้าง REPL ง่าย ๆ ได้เลย (Read, Eval, Print, Loop)
    เวอร์ชันเบาที่ผมทำเองจากแนวคิดนี้ เสถียรกว่า SDK หนัก ๆ มาก

    • แต่ใน use case ที่ซับซ้อนจริง ๆ ก็ยังจำเป็นต้องมี subagent เฉพาะทางและโครงสร้างแชร์ข้อมูล เพราะแค่ลูปง่าย ๆ อย่างเดียวก็มีข้อจำกัด

  • เรื่องที่ยากที่สุดในงานพัฒนา agent คือ การทดสอบและการประเมินผล (evals)
    ถ้าจะให้ระบบภายนอกมาประเมินก็มี input มากเกินไป และยังต้องสังเกตข้อมูลระหว่างการรันด้วย
    ตอนนี้ผมยังไม่มั่นใจว่าแนวทางไหนได้ผลจริง

    • ผมกังวลว่าการ deploy AI agent ส่วนใหญ่ดูเหมือนจะ พึ่งสัญชาตญาณมากกว่าการทดสอบอย่างเป็นระบบ
    • ถ้าดู เอกสารการประเมินของ ADK ของ Google จะเห็นว่าแต่ละรอบรันให้ผลไม่เหมือนกัน จึง กำหนดเกณฑ์ผ่าน/ไม่ผ่านได้ยาก และสุดท้ายก็ต้องให้ LLM อีกตัวมาประเมิน

  • ในการพัฒนา agent แม้แต่เรื่องพื้นฐานก็ยัง ขาดแนวทางที่ชัดเจน
    ตัวอย่างเช่นในการจัดการชนิดข้อมูล input/output ของ function tool ถ้าส่งเลข ID แบบตัวเลข อาจเกิด ข้อผิดพลาดในการ serialize หรือการสูญเสียความแม่นยำ
    สุดท้ายผมแก้ด้วยการแปลงเป็นสตริง
    ถ้าดูเอกสาร OpenAI (ลิงก์) และ issue ของ Google ADK (ลิงก์)
    จะเห็นว่ามีการบอกว่า “ผลลัพธ์ต้องเป็นสตริง” แต่ตัวอย่างจริงกลับคืนค่าเป็น dict หรือตัวเลข ความ ไม่สอดคล้องกันแบบนี้ทำให้เกิดความสับสน

  • ผมกำลังใช้ผลิตภัณฑ์ของ บริษัทด้าน agentic coding เจ้าหนึ่งอยู่ (จะไม่บอกชื่อ)
    พวกเขาดูแลทั้งการออกรีลีสโมเดล การประเมินผล การจัดการ sub-agent การคิดบิล และทุกอย่างให้หมด ผมเลย โฟกัสกับงานได้อย่างเดียว และค่อนข้างพอใจ

    • น่าจะเป็น Amp ของ Sourcegraph มากกว่า ช่วงแรกยังหยาบ ๆ แต่ตอนนี้ค่อนข้างสมบูรณ์ดีแล้ว

  • ตลอดสองเดือนที่ผ่านมา ผมทำ agent สำหรับงานหลายแบบ ตอนแรกใช้ Claude Code แต่เพราะ vendor lock-in และข้อจำกัดการใช้งาน เลยสร้างรันไทม์เองขึ้นมา
    ตอนนี้รองรับแค่ OpenAI แต่ก็ออกแบบให้เพิ่ม Claude หรือ Gemini ได้ในภายหลัง
    ผมเปิดเป็นโอเพนซอร์สไว้แล้ว เผื่ออ้างอิงได้ → agent-composer

  • ทิปของผมง่ายมาก: อย่าใช้ SDK ให้เขียน while loop เองแล้วจัดการ JSON ด้วยตัวเอง
    การควบคุมขนาดคอนเท็กซ์และข้อผิดพลาดได้ด้วยตัวเองเท่านั้น ถึงจะสร้าง agent ที่ยืดหยุ่นได้จริง