Agents ต้องการ control flow ไม่ใช่ prompt ที่มากขึ้น

 (bsuh.bearblog.dev)
1 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เอเจนต์ที่ต้องจัดการงานซับซ้อนอย่างเสถียร ไม่ได้ต้องการ prompt chain ที่ประณีตขึ้น แต่ต้องการ deterministic control flow ที่เข้ารหัสไว้ในซอฟต์แวร์
  • หากยังพึ่งพาคำอย่าง MANDATORY หรือ DO NOT SKIP ในพรอมป์ต์ แปลว่าคุณมาถึงขีดจำกัดของการทำ prompting แล้ว
  • ลองจินตนาการถึงภาษาการเขียนโปรแกรมที่ประโยคทำงานเหมือนข้อเสนอแนะ และฟังก์ชันเกิดอาการหลอนแล้วคืนค่า “Success” ยิ่งความซับซ้อนเพิ่มขึ้น ก็ยิ่งไม่สามารถให้เหตุผลกับระบบได้ และความน่าเชื่อถือก็พังทลาย
  • ซอฟต์แวร์ขยายตัวได้ผ่านการประกอบซ้ำแบบเรียกซ้อนของไลบรารี โมดูล และฟังก์ชัน และเพราะมันให้พฤติกรรมที่คาดการณ์ได้ จึงสามารถให้เหตุผลในระดับเฉพาะจุดได้
  • prompt chain มีประโยชน์กับงานที่แคบ แต่ไม่มีคุณสมบัติแบบเดียวกัน เพราะไม่เป็นเชิงกำหนด สเปกอ่อน และตรวจสอบได้ยาก

โครงสร้างที่จำเป็นต่อความน่าเชื่อถือของเอเจนต์

  • หากต้องการให้เชื่อถือได้ ต้องย้ายตรรกะออกจากคำอธิบายภาษาธรรมชาติไปไว้ที่ runtime
  • โครงสร้างที่ต้องการคือ deterministic scaffold ที่ปฏิบัติต่อ LLM ในฐานะองค์ประกอบหนึ่ง ไม่ใช่ทั้งระบบ
  • scaffold นี้ต้องมี state transition ที่ชัดเจนและ checkpoint สำหรับการตรวจสอบความถูกต้อง
  • deterministic orchestration เพียงอย่างเดียวยังไม่พอ และระบบที่อาจล้มเหลวแบบเงียบ ๆ จำเป็นต้องมีการตรวจจับข้อผิดพลาดอย่างเข้มข้น
  • หากไม่มีการตรวจสอบความถูกต้องด้วยโปรแกรม ทางเลือกจะเหลือเพียงสามแบบ

    • ผู้เฝ้าดู (Babysitter)

      • มนุษย์ต้องอยู่ในลูปเพื่อจับข้อผิดพลาดก่อนที่มันจะลุกลาม

    • ผู้ตรวจสอบ (Auditor)

      • ต้องตรวจสอบผลลัพธ์ทั้งหมดอย่างละเอียดหลังการทำงานเสร็จสิ้น

    • การภาวนา (Prayer)

      • ต้องพึ่งการยอมรับผลลัพธ์จากความรู้สึกหรือบรรยากาศโดยรวม

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

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

 
GN⁺ 4 시간 전
ความคิดเห็นจาก Hacker News

  • เห็นด้วย 1000% ยิ่งฟัง Anthropic ตีกลองเรื่อง “จงสร้างโดยอิงจากความสามารถของโมเดลในอนาคต เดี๋ยวมันก็ดีขึ้นเอง” บ่อยเท่าไร ก็ยิ่งเชื่อยากขึ้นเรื่อย ๆ
    ผมเคยสร้างเอเจนต์ QA ที่ไล่อ่านไฟล์ Markdown ข้อกำหนด 200 ไฟล์ใน browser session และมันเป็นระบบที่ดีมากซึ่งช่วยเพิ่มประสิทธิภาพทีมได้มาก แต่พอปล่อยให้โมเดลรับผิดชอบ control flow ระดับสูง อย่าง “ดูไฟล์ requirement ในไดเรกทอรีนี้ แล้วสำหรับแต่ละไฟล์ให้สร้างรายการงานเพื่อตรวจว่าแอปทำตาม requirement นั้นหรือไม่” มันก็พังตั้งแต่ราว ๆ 30 ไฟล์
    มันข้ามบางไฟล์ไป หรือไม่ก็ไปทดสอบไฟล์บางชุดซ้ำสามรอบ ทำให้งานที่ควรใช้ 3 นาทีลากเป็น 10 นาที หรือบางครั้งเพราะ error ในไฟล์เดียว มันก็ย้อนกลับไปทดสอบ 4 ไฟล์ก่อนหน้าใหม่ทั้งที่ไม่มีเหตุผล ความสามารถด้าน workflow orchestration ของ Opus 4.6 และ GPT 5.4 รวมถึงที่ลองผ่าน ๆ กับ Opus 4.7 และ GPT 5.5 ก็ไม่สม่ำเสมอ
    สุดท้ายผมเลยสร้าง deterministic harness ที่เรียบง่ายมากมาครอบโมเดล แล้วเรียกโมเดลสำหรับแต่ละ test case เก็บผลลง array แล้วเขียนออกไฟล์ ความน่าเชื่อถือของระบบดีขึ้นแบบถล่มทลาย แต่แพลตฟอร์มเอเจนต์แบบ managed อย่าง Cursor Cloud Agents หรือ Anthropic ดูจะหมกมุ่นกับแนวคิดว่า “เอเจนต์ต้องเป็นคนรันทุกอย่าง” มากเกินไป จนมองไม่เห็นคุณค่าของการใส่ความ deterministic เข้าไปนิดหน่อยในจุดที่เหมาะสม

    • แต่ก่อนผมคิดว่าเหตุผลที่พวกเขาผลักคนให้ไปใช้ workflow แบบมีแต่ prompt ก็เพราะพวกเขาเก็บค่า token ได้ แต่หาเงินจาก scaffolding ที่ผู้ใช้สร้างเองไม่ได้ ตอนนี้ผมกลับคิดว่าพวกเขากลัวมากกว่าว่าจะต้องมีใครสักคนมาออกแบบและทำ scaffolding พวกนั้นจริง ๆ
      เพราะมันทำให้คำกล่าวอ้างว่าเทคโนโลยีนี้จะมาแทนทั้งคน ทั้ง workflow หรือทั้งโปรเจ็กต์ดูแผ่วลง ผมคิดว่ามันยังเพิ่ม productivity ได้มากจนส่งผลเสียอย่างหนักต่อตลาดจ้างนักพัฒนาและค่าจ้างได้ แต่เวอร์ชันปัจจุบันของเทคโนโลยีนี้ไม่น่าจะไปถึงระดับที่พวกเขาพูดกัน ถ้าวางตำแหน่งมันว่าเป็น “เครื่องมือที่มีประโยชน์มากซึ่งช่วยลดงานจุกจิกจำนวนมากของทีมพัฒนาที่เป็นมนุษย์” นักพัฒนาคงอยากได้ แต่ผู้บริหารคงอยากได้น้อยลง และนักลงทุนก็คงไม่ยอมปล่อยผ่าน
      อีกอย่าง ขั้นตอนที่ถูกควบคุมละเอียดและเข้มงวดนั้นเหมาะกับการเอาโมเดลที่เล็กกว่า ถูกกว่า และเชี่ยวชาญเฉพาะทางมาเสียบมากกว่าจะใช้โมเดลยักษ์ที่เอาไปทั้งทำ test automation หรือเขียนแฟนฟิก CSI 5 เล่มรวดเดียวได้
    • เรื่องนี้อาจมาจาก วิธีทำ benchmark เพื่อประเมินโมเดลด้วยก็ได้
      benchmark บางอันไม่ใช่ว่าเปิดให้ลองหลายครั้งกับปัญหาเดียว แล้วไม่สนใจอัตราล้มเหลว ขอแค่มีผลสำเร็จออกมาสักครั้งก็หยิบผลนั้นมาใช่หรือ?
    • เห็นด้วย วิธีเดียวที่จะทำให้ระบบแบบนี้เชื่อถือได้คือการหั่นปัญหาออกเป็น ชิ้นเล็ก ๆ การตรวจความสอดคล้องภายในเองสุดท้ายก็แค่ยืนยันว่า LLM มีความสม่ำเสมอน้อยกว่าที่เราคาดมาก
    • ผมเอา apply_patch ไปรวมกับ check_compilation และ run_unit_tests แล้วประสิทธิภาพดีขึ้นมาก เครื่องมือยังชื่อ apply_patch เหมือนเดิม แต่ตอนนี้ถ้า patch สำเร็จ มันจะคืนข้อมูลเพิ่มเรื่อง build และ test มาด้วย
      อัตราความสำเร็จของเอเจนต์จากราว 80% ขึ้นไปถึงระดับที่จนถึงตอนนี้ดูแทบจะ deterministic แล้ว ทุกวันนี้ไม่จำเป็นต้องอธิบายขั้นตอน compile กับ unit test ใน prompt ด้วยซ้ำ แค่รันตาม dependency ที่กำหนดแล้วส่งผลลัพธ์กลับมาก็พอ
      ช่วงนี้ยังรู้สึกเหมือนตัวเองสวนกระแสด้วย ผมใช้ token แบบจ่ายล่วงหน้าและ custom harness มานานแล้ว และมันก็ใช้ได้ดีจริง ๆ ข่าวส่วนใหญ่เลยมองข้ามได้เลย ในปัญหาที่เล็งไว้ชัดเจน เครื่องมือแนว Copilot ใช้ประโยชน์ไม่ได้อีกต่อไป และในบาง codebase ต่อให้ใช้โมเดลฐาน GPT 5.4 เหมือนกัน ระดับผลงานก็ต่างกันคนละมิติ
    • ความลับคือการ “compile” orchestration prompt นั้น ถ้าเปลี่ยน prompt ให้เป็นโค้ด โค้ดนั้นก็จะไปรันเอเจนต์ หรือรันโค้ด หรือทั้งสองอย่างได้ ทำให้ปัญหาเรื่อง determinism คลี่คลาย
      ทุกคนพลาดแพตเทิร์นนี้ใน skill ถ้ามีโค้ดวางคู่กับ SKILL.md ก็รับประกันพฤติกรรมบางอย่างได้ แต่ทุกคนกลับติดการเขียน prompt กันอย่างประหลาด ไม่ต้องถึงกับสร้าง CLI หรอก แค่มี skill.py ง่าย ๆ ที่มีงานอยู่ข้างในก็พอ จะมี helper สำหรับเรียก claude -p ไว้ด้วยก็ได้

  • อีกไม่กี่ปีข้างหน้า ถ้าผู้คนยังใช้ LLM กันอยู่ แต่สุดท้ายต้องใช้มันผ่าน คำศัพท์และไวยากรณ์ที่ควบคุมได้ ซึ่งทุกคนต้องเรียนรู้ ก็คงน่าขำดี เหมือนเมื่อ 15 ปีก่อนที่ทุกคนย้ายไป NoSQL แล้วอีกไม่นานก็กลับไปสร้าง schema ไว้ใน JSON กันใหม่

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

    • เห็นด้วย 100% เราควรใช้ เครื่องมือที่ไม่ deterministic แต่ถูกต้อง 90% ไปสร้างเครื่องมือ deterministic ที่ถูกต้อง 100% หนึ่งในประโยคสำคัญที่ผมใส่ใน prompt เสมอคือ “ถ้าเจอเคสก้ำกึ่งที่คลุมเครือ ให้มาถามผม”
      การเอา AI ไปผูกเข้ากับ production แล้วให้มันทำอะไรผ่าน API call โดยตรงเป็นความคิดที่ไม่ดี ผมมองว่าหน้าที่เดียวที่ AI ควรทำในแอปคืออ่าน จัดหมวดหมู่ อะไรทำนองนั้น เทียบได้กับการมาแทน “R” ใน CRUD app แบบสมัยก่อน
      ถ้าจะใช้ endpoint “R” ที่ขับด้วย AI แบบเดียวกันมาเติมฟอร์ม “C”, “U”, “D” ให้อัตโนมัติตาม prompt ก็โอเค แต่ห้ามไปเปลี่ยนอะไรให้ลูกค้าก่อนที่คนจะตรวจทาน CRUD app ก็ยังเป็น CRUD app อยู่ดีและจะเป็นแบบนั้นต่อไป เพียงแต่ตอนนี้มี endpoint “R” ที่ฉลาดมาก ซึ่งช่วย autocomplete ฟอร์มหรือเสนอการกระทำให้ลูกค้า เครื่องมือภายใน หรือ Jenkins pipeline ได้ มันเสนอการกระทำได้ แต่ไม่ควรลงมือทำเอง
    • ดูเหมือนในหลายองค์กร flow จะไล่จาก llm -> prompt -> result, ไปเป็น llm -> prompt + prompt encoded as skill -> result, แล้วไปเป็น llm -> prompt + deterministic code encoded as skill -> result
      ช่วงแรกการให้มัน generate โค้ดผ่าน prompt อาจช่วยลัดไปสู่ deterministic code ได้ แต่สุดท้ายก็ยังเป็นการเอา deterministic code ไปห่อไว้ใน wrapper ที่ไม่ deterministic อยู่ดี ถ้าจะทำงานระยะยาวให้สำเร็จ หลายกรณียังต้องมีชั้น determinism ที่ตอนนี้ขาดอยู่
      ต้องวาง deterministic code ไว้นอกขอบเขตที่ไม่ deterministic ผ่าน agent loop หรือ framework แบบนั้นภาพจะกลายเป็น agent flow แบบ deterministic -> การตัดสินใจแบบไม่ deterministic -> เครื่องมือแบบ deterministic คือให้การตัดสินใจที่ไม่ deterministic ถูกคั่นอยู่ระหว่างชั้น deterministic จากการทดลอง มันเป็นแพตเทิร์นที่ทรงพลังมาก และถ้าเอเจนต์สร้าง determinism ให้ตัวเองได้ผ่านเครื่องมืออย่าง auto-researcher มันยิ่งแรงขึ้นไปอีก
    • เราก็เจอเหมือนกัน ตอนแรกเราให้รายการเครื่องมือที่ทำให้เอเจนต์จัดการ data structure ได้ในแบบหนึ่ง แต่วิธีนั้นค่อนข้างเปราะ
      ตอนนี้เราใช้ ภาษาเฉพาะโดเมน ขนาดเล็กกับเครื่องมือเดียว โดยให้เอเจนต์ป้อนสคริปต์ที่เขียนด้วยภาษานั้นเข้ามา มันรองรับ use case ที่ dynamic กว่าได้ และถ้า syntax ผิด parser ก็จับได้ง่ายแล้วส่งกลับไปให้เอเจนต์
    • ปัญหาคือโปรแกรมมักเจอ เคสก้ำกึ่ง ที่ต้องตีความอยู่บ่อย ๆ และพอถึงจุดนั้นเราก็อยากให้ LLM เป็นคนจัดการเคสนั้น แล้วสุดท้ายก็เผลออยากโยนทั้งลูปและการเรียกเครื่องมือทั้งหมดให้ LLM ทำไปเลย
    • ผมทำแบบนี้พอดีในโปรเจ็กต์ล่าสุด ตอนทำระบบอัตโนมัติสำหรับสร้าง interface library ระหว่างเซิร์ฟเวอร์ที่ควบคุมฮาร์ดแวร์กับแอปมือถือ
      ทีมควบคุมฮาร์ดแวร์ส่งสเปกมาเป็นเอกสารกับสเปรดชีต ส่วนทีมมือถือก็ดูจากนั้นแล้วเขียน interface library พร้อมตรวจสอบให้ตรงกับเซิร์ฟเวอร์ ผมแปลงเอกสารเป็น TSV แล้วส่งบางส่วนให้ Claude เพื่อให้มันช่วยเขียน TSV parser ที่ยังรักษาความละเอียดอ่อนของสเปกที่มนุษย์เขียนไว้
      ผมต้องวนซ้ำเกิน 150 รอบกว่าจะจัดการเคสก้ำกึ่งทั้งหมดและสร้างผลลัพธ์ขั้นกลางเป็น JSON ได้ หลังจากนั้น Claude ก็ช่วยเขียน code generator ที่วาง custom glue code บน Apollo เพื่อสร้างโค้ดที่แอปมือถือจะนำไปใช้
      pipeline ทั้งชุดนี้รันเป็นส่วนหนึ่งของ Github Actions และจะเรียก Claude เฉพาะตอนที่ตัวตรวจสอบ library ล้มเหลวเท่านั้น ตอนล้มเหลวจะมีไฟล์ md ที่ใส่ไว้ในคำขอเพื่อให้มันหาว่าอะไรผิด เสนอวิธีแก้ และสร้าง PR หลังจากนั้นมนุษย์จะมาตรวจ แก้ และ merge รวมค่าเครดิตทั้งหมดที่ใช้ไปยังไม่ถึง 350 ดอลลาร์

  • ผมเห็นด้วยกับเจตนา แต่คิดว่าข้อสรุปควรเปลี่ยนไป ถ้าคุณชนเพดานของ prompt แล้ว สิ่งที่ควรทำคือให้ LLM เขียนซอฟต์แวร์ที่จะทำงานนั้น แทนที่จะพยายามให้ LLM มาทำงานนั้นเองตอน runtime
    บทบาทของ LLM ตอน runtime โดยทั่วไปน่าจะเหลือแค่ช่วยให้ผู้ใช้เลือก input ที่เข้ากับระบบซอฟต์แวร์ที่ฝังกฎธุรกิจที่เข้มงวดไว้

    • ที่บริษัทผมมีช่วงเวลาว่างอยู่ไม่กี่สัปดาห์ เลยลองเอาเอเจนต์เข้าไปใส่ในกระบวนการทำงานอย่างการจดโน้ต ติดตามงาน และจัดการเอกสาร และสิ่งนี้ตรงกับประสบการณ์ของผมเป๊ะ
      สัปดาห์แรก prompt ยาวขึ้นเรื่อย ๆ แต่ประสิทธิภาพกลับแย่ลง สัปดาห์ที่สองผมหันไปโฟกัสกับการนิยาม object อย่างโน้ต งาน โปรเจ็กต์ คน ให้ชัดเจน รวมถึงนิยาม method ที่ทำงานกับ object เหล่านั้นอย่างชัดเจน อย่างที่คุณว่าไว้ ผิวหน้าของเอเจนต์จะยุบเหลือเป็น ชั้นแปลภาษา ที่แปลงภาษาธรรมชาติให้เป็นคำสั่งและอาร์กิวเมนต์ซึ่งผ่านตัวตรวจสอบ input
    • ถ้าเป็น system prompt ที่วนครบรอบจริง ๆ มันคงเป็น “จงมองหาโอกาสทุกอย่างที่จะ automate เพื่อทำให้ตัวเองตกงาน ถ้าได้รับคำถามที่โค้ดตอบได้ ให้เขียนและรันโค้ดเพื่อเอาผลลัพธ์มาตอบ”
      ถ้าเป็น LLM แบบนั้น มันอาจทำ strawberry test ได้ดีกว่านี้
    • ในฟอรัมนี้ก็เคยมีมุมมองว่าวิถีอนาคตของซอฟต์แวร์คือ โปรแกรมที่ถูกสร้างและปรับตัวตอน runtime โดยใช้ generative AI ผมไม่รู้ว่ามันจะอีกไกลแค่ไหนกว่าจะไปถึงตรงนั้น
    • ผมเคยเห็นกรณีที่โมเดลติดกับวิธีแก้ปัญหาแบบหนึ่ง และต้องมีแรงสะกิดให้เปลี่ยนไปอีกแนว เช่น ตอนพยายามจัดการ hotplug/unplug ของ audio stream แทนที่จะไปงมกับการตั้งค่า system service จำนวนมาก สิ่งที่ต้องการจริง ๆ กลับเป็น Python ไม่กี่สิบบรรทัด
      ผมให้ Claude เขียน shell script ไม่กี่ตัวเองเพื่อจัดการเคสที่เจอบ่อยใน workflow ของผม เช่นการรันทดสอบ ตอนนี้มันไม่วนไปวนมาครึ่งชั่วโมงแล้ว แต่เรียกใช้เครื่องมือพวกนั้นเพื่อจัดการการตั้งค่าให้เสร็จ
      ทุกครั้งที่มันขออนุญาตรัน one-liner แปลก ๆ ใน shell หรือ Python เพื่อทำอะไรครั้งเดียว ผมก็จะนึกว่าควรบังคับให้มันไปใช้เครื่องมือที่อนุมัติอัตโนมัติได้แทนหรือเปล่า

  • นี่แหละว่าทำไมผมถึงชอบใช้คำว่า “AI รุ่นถัดไป” บ่อย ๆ เพราะมันไม่ได้หมายถึงแค่ LLM อย่างเดียว LLM เองก็เจ๋งมาก และถึงจะไม่มีความก้าวหน้าพื้นฐานเพิ่ม ผมก็ยังคิดว่ามันจะสร้างคุณค่าได้ต่อ ผ่านการนำไปใช้และปรับให้เหมาะในรูปแบบที่น่าสนใจยิ่งขึ้น
    แต่บางส่วนดูเหมือนต้องการ การปรับปรุงพื้นฐานระดับรุ่นถัดไป ไม่ว่าจะออกมาในรูปไหนก็ตาม ปรากฏการณ์ที่ LLM ทำให้คำสั่งอย่าง “ห้ามทำ X เด็ดขาด” เบลอหายไป และหลังทำงานหลายขั้นตอนกลับเหมือนตีความเป็น “ช่วยทำ X ให้ที” ดูจะใกล้เคียงกับข้อจำกัดระดับรากฐานของวิธีทำงานมันมาก เราอยู่ในช่วงตื่นเต้นแรกเริ่มของการค้นหาว่ามันทำอะไรได้บ้าง เลยลืมได้ง่ายว่า LLM ไม่ใช่ทุกอย่างที่เราตามหาใน AI
    ต้องมีโครงสร้างที่จัดการ “ห้ามทำ X เด็ดขาด” ได้แบบเดียวกับมนุษย์ และต้องมีโครงสร้างที่มีลำดับชั้นความจำคล้ายมนุษย์แทน “context window” ด้วย ต่อให้เริ่มจาก AI แบบเดียวกัน ถ้าสองคนคุยกันนานพอ สุดท้าย AI สองตัวนั้นก็ควรกลายเป็นคนละตัวจริง ๆ ไม่ใช่แค่ตัวเดียวกันแต่มี context window ต่างกัน
    แน่นอนว่าไม่มีใครรู้ว่าหน้าตามันจะเป็นอย่างไร แต่ก็ไม่มีเหตุผลจะคิดว่า LLM คือคำตอบสุดท้ายของ AI

    • ผมคิดว่าสิ่งที่ต้องมีคือ memory จริง memory ตอนนี้ถ้ามองกว้าง ๆ มันเหมือนระบบโพสต์อิทที่ AI เขียนเตือนตัวเองแล้วคอยกลับมาเช็กทุกครั้ง มากกว่าจะเป็นระบบรวมศูนย์ที่ทำให้เกิดการเรียนรู้และถูกเรียกใช้ได้ยืดหยุ่นกว่า
    • มีตัวอย่างที่น่าสนใจอยู่ https://www.youtube.com/watch?v=kYkIdXwW2AE&t=315s

  • ในฐานะคนที่วนมาครบรอบจาก prompt enforcement → deterministic flow → prompt enforcement อีกที ผมไม่เห็นด้วย
    เหตุผลที่ “อย่าข้าม” ใช้ไม่ได้ผล ก็เพราะเอเจนต์กำลังแบกงานมากเกินไป และเนื้อหาอื่น ๆ ใน context ก็ดึงความสนใจออกจากคำสั่งนี้
    แต่ก็ไม่มีใครบอกว่าเอเจนต์ที่คอย enforce ต้องเป็นตัวเดียวกับเอเจนต์ที่คอยสร้างอะไรบางอย่าง คุณเข้ารหัสตรรกะการตัดสินใจที่ฉลาดพอสมควรไว้ใน deterministic control flow ได้ แต่ถ้าทำแข็งเกินไปมันก็ทำงานไม่ดี และถ้าทำซับซ้อนเกินไป ต้นทุนการตั้งค่าและบำรุงรักษาก็อาจแพงกว่าการใช้เอเจนต์เสียอีก
    โดยพื้นฐานแล้วสิ่งที่ต้องมีคือเอเจนต์สามประเภท: supervisor ที่ดูแลลูปและคอยเปิดสิ่งที่เหมาะสมเมื่อมีปัญหา, orchestrator ที่มอบหมายให้เอเจนต์ที่เหมาะสมและบังคับใช้ guardrail ในจุดที่จำเป็น, และ worker ที่ลงมือทำงานเป็นหน่วย ๆ

    • ใช่ ก็แค่เพิ่มเอเจนต์เข้าไปอีก

  • จากมุมผม harness ทุกตัวกำลังทำเรื่องนี้ผิด และบางตัวก็ผิดหนักมาก
    ยกตัวอย่างเช่น slash command เป็นฟีเจอร์ที่ผิดทาง เราไม่ควรต้องรอให้แชตบอตจบหนึ่ง turn ก่อน ถึงจะเช็กสถานะ context window หรือดูว่า session นี้ใช้เงินไปเท่าไรได้ การควบคุมควรตั้งฉากกับ chat loop
    มีหลายอย่างที่ไม่เกี่ยวอะไรเลยกับการควบคุม input/output ของ text generator แต่กลับถูกผูกไว้กับพฤติกรรมการแชต เพียงเพราะคิดว่า “ในเมื่อเป็นแชต ก็ทำให้มันเหมือน IRC bot ไปสิ”
    ตอนนี้มี LLM agent เยอะมาก แต่แทบไม่มีตัวไหนแยก control, agent loop และ representation layer ออกจากกันอย่างถูกต้อง มีไม่กี่ตัวที่อย่างน้อยก็มี headless mode ซึ่งก็ยังดี

    • เข้าใจว่าคุณจะสื่ออะไร แต่การสร้างสถาปัตยกรรมที่คุณเสนอจริง ๆ มันยากกว่ามากนะ ลองสร้างเองแล้วไปสมัครงานบริษัทใหญ่ดูไหม?
    • ใน codex CLI ระหว่าง turn ก็ใช้ /status ได้ดีนะ
      อย่างอื่นอาจไม่เป็นแบบนั้น
    • ผมใช้แอปเดสก์ท็อป Codex ใน GUI มันมีตัวบอก context กับสถิติการใช้งานให้ดู
      มันยังสะดวกกว่ามากเวลาสลับไปมาระหว่างบทสนทนาและดูอัปเดตด้วย บางครั้งผมใช้ Claude Code หรือ opencode ในเทอร์มินัล แต่ประสบการณ์เทียบกับแอปเดสก์ท็อป Codex แล้วแย่กว่ามาก

  • คำพูดที่ว่า “ลองจินตนาการถึงภาษาการเขียนโปรแกรมที่ statement เป็นเพียงข้อเสนอ และ function หลอนแล้วคืนค่า ‘Success’ กลับมา การให้เหตุผลจะเป็นไปไม่ได้ และความน่าเชื่อถือจะพังลงตามความซับซ้อนที่เพิ่มขึ้น” โดยแก่นแล้วค่อนข้างใกล้กับ declarative programming
    การเขียนโปรแกรมแบบดั้งเดิมส่วนใหญ่อยู่ในโลก imperative ที่คุ้นมือสำหรับนักพัฒนา คือให้ชุดคำสั่งที่แม่นยำและคาดหวังว่ามันจะทำตามที่เราเขียน เอเจนต์กลับใกล้กับ declarative มากกว่า คือคุณให้ผลลัพธ์มา แล้วมันค่อยทำงานเพื่อไปให้ถึงผลนั้น
    แน่นอนว่าโลก declarative อย่าง SQL มีผลลัพธ์ที่ค่อนข้างสม่ำเสมอและนิยามไว้ชัด แต่ถึงอย่างนั้นคุณก็ยังเชื่อใจ internal engine ว่าจะจัดการอย่างไร การคิดถึงเอเจนต์ในฐานะสิ่ง declarative ช่วยผมมากกว่าการพยายามออกแบบระบบ “ควบคุม” แบบ Rube Goldberg ถ้ามันไม่ตรง ก็แค่ตรวจสอบ รายงานว่าผิด แล้วลองใหม่หรือเปลี่ยนแนวทาง
    ถ้าคุณต้องการ imperative จริง ๆ ก็เขียนแบบ imperative ไปเลย หรือให้เอเจนต์เขียนแบบนั้นให้ก็ได้ มันอ่านแล้วเหมือนกำลังพยายามใช้เครื่องมือผิดงาน

    • ผมว่ามัน abstract กว่า declarative ไปอีกขั้นนะ อาจเรียกว่า “narrative programming” ได้หรือเปล่า? แน่นอนว่าแค่คำว่า “programming” ยังเหมาะอยู่ไหมก็ยังเถียงกันได้
      มันอาจดูเหมือน declarative แต่ก็เป็นแค่ภาพลวงตาภายในนั้น สิ่งที่เราทำจริง ๆ ไม่ใช่อธิบายเป้าหมายให้ AI เข้าใจและตีความ แต่เป็นการมีเอกสารเรื่องเล่าที่ตัวละครตัวแทนมนุษย์คุยกับตัวละครคอมพิวเตอร์ แล้วพวกเราในโลกจริงก็หวังว่า LLM จะเอาเรื่องราวด้านหลังมาปะติดปะต่อให้แน่นพอจนดึงสิ่งที่มีประโยชน์ออกมาได้
      นี่ไม่ใช่แค่การแบ่งประเภทเชิงวิชาการนะ การรู้ว่ามันมีลักษณะเป็นเรื่องเล่าช่วยให้เราเข้าใจความสัมพันธ์ระหว่าง input กับ output และวางกลยุทธ์ได้ดีขึ้น เช่นช่วยให้เข้าใจความเสี่ยงอย่าง prompt injection และยังเป็นแนวทางว่าเราควรใส่หรือไม่ใส่ข้อมูลฝึกแบบไหน
    • ตอนแรกผมนึกถึง declarative เหมือนกัน แต่ไม่ใช่ SQL ผมนึกถึง PROLOG มากกว่า ฝั่งที่มี control flow และความสามารถในการให้เหตุผลจริง ๆ
      ซึ่งพอเป็นแบบนั้นก็เจอปัญหาคล้าย LLM คือถ้าไม่ระวังมาก ๆ ก็จะล้มเหลวแบบเงียบ ๆ วนซ้ำ หรือขัดแย้งกัน แก่นของปัญหาอาจเป็นเรื่องสมมติฐานโลกปิดแบบเดียวกันก็ได้ ใน LLM มันแสดงออกมาเป็นการหลอนแทนที่จะยอมรับว่าไม่รู้
    • เห็นด้วย แต่คุณก็ยังพูดกับเอเจนต์แบบ imperative ได้อยู่ดี ต่อให้บอกว่า “นี่คือขั้นตอนที่ชัดเจน จงทำตาม” มันก็ยังทำพังได้ สิ่งที่เราตามหาไม่ใช่ความเป็น imperative แต่คือ determinism
      และอย่างที่คุณว่า ถ้าสั่ง LLM ที่ไม่ deterministic แบบ declarative ว่า “พาไปสู่สถานะสุดท้ายนี้” โอกาสหลุด轨ก็ยิ่งสูงขึ้น
    • ความเป็น declarative ของ SQL ตั้งอยู่บนคณิตศาสตร์ที่ชื่อว่า relational algebra จึงคืนผลลัพธ์เดิมทุกครั้ง ส่วนจะคืนภายในเวลาเท่าเดิมทุก query หรือไม่ ขึ้นกับ index และขนาดฐานข้อมูล
      แต่ตัว query เองไม่ได้เปลี่ยนไปแบบ LLM

  • ผมคิดเรื่องนี้มาเยอะพอสมควร มันอาจโยงกับเรื่อง specialization ได้ด้วย ยิ่งโมเดลเฉพาะทางมากขึ้นเท่าไร ความสามารถพื้นฐานระดับฐานก็ดูเหมือนยิ่งลดลง แต่ถ้าเล็งไปที่การ abstraction เพิ่มขึ้นแค่นิดเดียว อาจได้ข้อดีของทั้งสองฝั่ง
    เป็นตัวอย่างที่ค่อนข้างเฉพาะ แต่ก็น่าคิด
    สรุป podcast 20 นาที: https://pub-6333550e348d4a5abe6f40ae47d2925c.r2.dev/EP008.ht...
    งานวิจัย: https://arxiv.org/abs/2605.00225

  • เรื่องนี้เห็นกันมาตั้งแต่ยุค Auto-GPT ในปี 2023 แล้ว ผู้คนปล่อยให้ GPT “ขับรถ” แต่ในกรณีส่วนใหญ่ สิ่งที่ต้องการจริง ๆ มีแค่ Python สิบบรรทัดกับการเรียก llm() สักไม่กี่ครั้งเท่านั้น
    ทางเลือกอีกแบบคือรัน Python สิบบรรทัดนั้นด้วยวิธีที่แพงที่สุด ช้าที่สุด และเชื่อถือได้น้อยที่สุดเท่าที่จะเป็นไปได้ ซึ่งแน่นอนว่ามันฮิตมาก
    ตัวอย่างเช่น คนส่วนใหญ่ใช้เอเจนต์ไปทำ internet research มันจะรันอยู่หลายชั่วโมงแล้วค่อย ๆ วอกแวกหรือไม่ก็ลืมสิ่งที่กำลังทำอยู่ตั้งแต่แรก
    ในทางกลับกัน คุณเขียนโค้ดสิบบรรทัดที่ใช้ import duckduckgo กับ import llm เพื่อทำเรื่องเดียวกันให้เสร็จใน 20 วินาทีได้ แถมรันได้แบบ deterministic จริง ๆ และค่าใช้จ่ายน้อยกว่าถึง 50 เท่า
    โมเดลปัจจุบันดีขึ้นมาก และดีพอแล้วที่ Auto-GPT จะเริ่มเป็นจริงได้ แต่การไปรัน control flow ที่สเปกหละหลวม ด้วยวิธีที่แพงที่สุดเท่าที่ทำได้ ก็ยังเป็นความคิดที่แย่อยู่ดี