Jido 2.0 - เปิดตัวเฟรมเวิร์กเอเจนต์บน Elixir

• เป็น สถาปัตยกรรมเอเจนต์แบบฟังก์ชันล้วน ที่กำหนดสถานะและการกระทำเป็นข้อมูล และแยกผลข้างเคียงออกเป็น directive เชิงคำสั่ง ทำให้การทดสอบและดีบักง่ายขึ้น
• ใช้ API ที่กระชับและการออกแบบที่ยึด BEAM เป็นศูนย์กลาง พร้อมแยกโมดูลอย่าง jido_action, jido_signal เพื่อให้ ระบบ action·signal ที่เป็นมาตรฐาน
• Jido AI ในชั้นบนรองรับกลยุทธ์การให้เหตุผล 6 แบบ เช่น ReAct, Chain-of-Thought และสามารถใช้งานโมเดลจากผู้ให้บริการ 11 ราย รวม 665 โมเดล ผ่าน การเชื่อมต่อ LLM บนพื้นฐาน ReqLLM
• ตอนนี้ Jido กำลังขยายไปเป็น แพลตฟอร์มระบบนิเวศเอเจนต์ และรองรับ การทำให้ CRUD เป็นเครื่องมือที่ AI เรียกใช้ได้ ผ่านการผสานกับ Ash Framework (ash_jido)

---

ภาพรวมของ Jido 2.0

• Jido 2.0 คือ เฟรมเวิร์กเอเจนต์บน Elixir ที่เสร็จสมบูรณ์หลังผ่านการพัฒนาและออกแบบใหม่ตลอด 18 เดือน
  • ในช่วงแรกเริ่มต้นจากแพลตฟอร์มบอตชื่อ BotHive ในปี 2024 และต่อมาได้นำ BEAM runtime มาใช้เป็นรากฐานของระบบเอเจนต์
  • ใช้ ความสามารถด้าน concurrency และความเสถียรของ BEAM เพื่อก้าวข้ามข้อจำกัดของเฟรมเวิร์กที่สร้างบน TypeScript หรือ Python

การเปลี่ยนแปลงจาก 1.0 ไปสู่ 2.0

• Jido 1.0 ใช้งานยากจากการทำ abstraction มากเกินไป แต่ใน 2.0 ได้ปรับปรุงเป็น API ที่เรียบง่ายขึ้นและโครงสร้างที่ยึด BEAM เป็นหลัก
  • นำความคิดเห็นจากผู้ใช้มาปรับ ลดความซับซ้อนที่ไม่จำเป็น และลดแรงเสียดทานในการใช้งานฟังก์ชันพื้นฐานให้น้อยที่สุด
  • สะท้อนความต้องการที่ว่า “อยากสร้างเอเจนต์ ไม่ได้อยากสู้กับเฟรมเวิร์ก”

แกนกลางเอเจนต์ที่ทรงพลังและทนทาน

• หัวใจของ Jido 2.0 คือ สถาปัตยกรรมเอเจนต์แบบฟังก์ชันล้วน
  • เอเจนต์ถูกกำหนดเป็นโครงสร้างข้อมูลง่าย ๆ ที่มีสถานะ (state), การกระทำ (actions) และเครื่องมือ (tools)
  • ทุกการทำงานถูกประมวลผลผ่านฟังก์ชัน cmd/2 และจะคืนค่าเป็น เอเจนต์ที่อัปเดตแล้วพร้อมรายการ directive ตาม action ที่ป้อนเข้าไป
  • ผลข้างเคียงถูกแสดงเป็น directive เพื่อให้ runtime เป็นผู้ดำเนินการ จึงทดสอบและดีบักได้ง่าย
• Jido.AgentServer ห่อเอเจนต์ไว้ใน GenServer ที่มีการกำกับดูแล และรองรับการกำหนดเส้นทางสัญญาณกับลำดับชั้นเอเจนต์แบบพ่อ-ลูก
• strategy เป็นจุดขยาย โดยมี Direct (ทำงานตามลำดับ) และ FSM (state machine) ให้มาเป็นค่าเริ่มต้น
  • กลยุทธ์ AI อย่าง ReAct, Chain-of-Thought ก็ทำงานผ่านอินเทอร์เฟซเดียวกัน

การแยกโมดูล action และ signal

• jido_action: สัญญา action แบบสากล ที่ใช้กำหนดความสามารถทั้งหมดของเอเจนต์
  • มีการตรวจสอบสคีมาระหว่างคอมไพล์, lifecycle hooks และฟังก์ชันแปลงเป็นรูปแบบเครื่องมือของ ReqLLM อัตโนมัติ
  • มีเครื่องมือที่สร้างไว้ล่วงหน้ามากกว่า 25 รายการ และ workflow planner แบบอิง DAG
• jido_signal: ระบบส่งข้อความบนพื้นฐาน CloudEvents v1.0.2
  • มีรูปแบบสัญญาณมาตรฐาน, router แบบ trie, pub/sub bus และ dispatch adapter 9 แบบ
  • สามารถผสานกับระบบต่าง ๆ ได้โดยไม่ต้องพึ่งโปรโตคอลเฉพาะทางที่ไม่เป็นมาตรฐาน

ชั้นการผสาน Jido AI

• jido_ai คือชั้นรวมที่เปลี่ยนการเรียก LLM ให้กลายเป็นความฉลาดของเอเจนต์แบบมีโครงสร้าง
  • มีกลยุทธ์การให้เหตุผลในตัว 6 แบบ ได้แก่ ReAct, Chain-of-Thought, Tree-of-Thoughts, Graph-of-Thoughts, TRM และ Adaptive
  • ยังคงใช้สัญญา cmd/2 และระบบ directive เดิม โดยผสานชั้น AI ให้เป็นส่วนขยาย ไม่ใช่โลกแยกต่างหาก
• ทำงานบนพื้นฐาน ReqLLM และรองรับผู้ให้บริการ 11 รายกับโมเดลมากกว่า 665 รุ่น
  • ออกแบบโดยให้ความสำคัญกับสตรีมมิงเป็นหลัก, โครงสร้างหลายผู้ให้บริการ และการมีส่วนร่วมจากชุมชนอย่างต่อเนื่อง

ระบบนิเวศที่กำลังขยายตัว

• Jido กำลังพัฒนาไปไกลกว่าเฟรมเวิร์กธรรมดา สู่ ระบบนิเวศเอเจนต์
  • ชุมชนกำลังสร้าง ผู้ช่วยเขียนโค้ด, workflow orchestrator, research agent, ระบบสนับสนุนการปฏิบัติการ และอื่น ๆ บน BEAM
  • มีแพ็กเกจหลากหลายเกิดขึ้น เช่น browser automation, memory system, evaluation harness และการผสาน MCP
• การผสานกับ Ash Framework (ash_jido)
  • เมื่อเพิ่มบล็อก DSL ของ jido ให้กับทรัพยากรใน Ash ก็จะแปลง action แบบ CRUD ให้เป็น เครื่องมือที่ AI เรียกใช้ได้
  • ยังคงรักษานโยบายสิทธิ์, data layer และ type safety ไว้
  • ash_ai ก็กำลังย้ายไปใช้ ReqLLM เช่นกัน ทำให้เกิด การบรรจบกัน ของทั้งสองระบบนิเวศ

ชุมชนและคำขอบคุณ

• Jido 2.0 ถูกสร้างขึ้นบน ระบบนิเวศของชุมชน Elixir
  • ได้รับการเสริมความแข็งแกร่งจากการมีส่วนร่วมของไลบรารีหลักอย่าง Phoenix, LiveView, Ash, Req, Telemetry, NimbleOptions เป็นต้น

เริ่มต้นใช้งาน

• ติดตั้งได้ผ่านแพ็กเกจ Hex

  {:jido, "~> 2.0"},  
  {:jido_ai, "~> 2.0"}  
  

• เอกสาร: hexdocs.pm/jido
• ระบบนิเวศ: jido.run/ecosystem
• GitHub: github.com/agentjido

[GN⁺]

ความเห็นจาก Hacker News

• ยังไม่เคยใช้ Jido จริง ๆ แต่ก็คอยแวะมาดูประมาณเดือนละครั้ง
  คิดว่า BEAM เหมาะกับเฟรมเวิร์กเอเจนต์แบบสมบูรณ์แบบ แต่ ecosystem ยังจำกัดอยู่ เลยยังไม่ได้ลงลึกมาก
  ตั้งตารอเวอร์ชัน 2.0 อยู่ อีกอย่าง ดูเหมือนว่าตัวอย่างโค้ดบางส่วนจะมีปัญหา entity escape

  • ขอบคุณ! กำลังแก้อยู่ตอนนี้เลย

• ชอบแนวทางที่เน้น “ข้อมูลและฟังก์ชันบริสุทธิ์” มาก ซึ่งถูกย้ำตั้งแต่ต้นบทความ
  เห็นคนพูดกันบ่อยว่าโมเดลการทำงานของ BEAM เหมาะกับ AI แต่ในทางปฏิบัติ เรื่อง ความทนทาน ในสถานการณ์อย่าง node ล่มหรือ rolling deploy กลับถูกมองข้ามบ่อย ๆ
  ยังมีความเข้าใจผิดด้วยว่า Elixir ให้ location transparency แต่จริง ๆ ไม่ใช่แบบนั้น ถ้า node ล่ม process ข้างในก็จบไปด้วย
  ถ้าคงสถานะของเอเจนต์ให้ชัดเจนและบริสุทธิ์ในแต่ละขั้นของการเรียก API ก็แก้ปัญหานี้ได้ เก็บสถานะไว้ใน Mnesia หรือ Redis แล้วให้ node อื่นมารับช่วงต่อ สุดท้ายแล้วหัวใจสำคัญคือ checkpointing

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

• จังหวะเป๊ะมาก ผมเพิ่งทำเฟรมเวิร์กเอเจนต์เองโดยเอา gen server มาผสมกับ Oban ซึ่งเป็นงานที่ ทรมานมาก
  โปรเจ็กต์นี้น่าจะช่วยลดความเจ็บปวดในการพัฒนาได้เยอะเลย ขอบคุณมากจริง ๆ

  • ❤️

• สงสัยว่านี่คล้ายกับ OpenAI Symphony หรือเปล่า
  ผมตามฝั่ง Elixir มากกว่าฝั่ง AI ก็เลยรู้สึกสดใหม่ดีที่เห็น Elixir กับ BEAM ถูกใช้กับ เวิร์กโหลดแบบ orchestration พวกนี้

  • ดีใจที่เห็น OpenAI ใช้ Elixir ส่วน Symphony ก็เป็นตัวอย่างของการลงมือสร้างสิ่งที่ Jido ทำได้ด้วยตัวเอง

• ตอนนี้เว็บเข้าแทบไม่ได้เพราะทราฟฟิกถล่ม เลยเอา ลิงก์สำรองบน archive.org มาแชร์

  • นี่คงจะเป็น ความอับอายส่วนตัว ของผมไปอีก 2 สัปดาห์ข้างหน้า... ถึงจะเป็นปัญหาที่ดี แต่ก็เตรียมตัวมาไม่พอจริง ๆ
  • ไม่แน่ใจว่าเป็นปัญหาเดียวกันไหม แต่หน้าจะเปิดได้ปกติในตอนแรก แล้วอีกไม่กี่วินาทีก็รีเฟรชเป็น 404 สุดท้ายเลยเลิกอ่าน

• ขอบคุณที่แชร์! เดี๋ยวจะไปลองดูแน่นอน
  ช่วงนี้ผมเพิ่งทำ แพ็กเกจ A2A ด้วย LLM ซึ่งเป็น abstraction คล้าย GenServer
  ก่อนหน้านี้มี A2A implementation อื่นอยู่แล้ว แต่แพ็กเกจของผมมี semantics ต่างออกไป เลยปล่อยออกมาตามนั้น
  คนที่สนใจดูได้ ที่นี่

  • เจ๋งมาก! กด star ให้แล้วทันที

• ผมติดตามโปรเจ็กต์นี้มาหลายเดือนแล้ว และ Elixir/BEAM คือ แพลตฟอร์มที่สมบูรณ์แบบ สำหรับการรันเอเจนต์
  BEAM ทั้งเบาและมีประสิทธิภาพมาก ตามทฤษฎีแล้วน่าจะรันเอเจนต์ได้เป็นพันตัวบนเซิร์ฟเวอร์เดียว
  อยากเห็นจริง ๆ ว่าคนที่เข้าใจสิ่งนี้จะสร้างอะไรออกมาได้บ้างในอนาคต

  • Jido core รันบน Raspberry Pi ได้ด้วย
    แถมยังมีความพยายามจะ deploy BEAM ลงบน bare metal (embedded) แล้วรันเอเจนต์ในนั้นด้วย
    อนาคตน่าจะน่าสนใจมากจริง ๆ

• อยากเห็นสกรีนช็อตของ process tree ตอนที่เอเจนต์กำลังทำงานอยู่ใน ‘observer’
  เผื่อใครไม่รู้ observer คือเครื่องมือสำหรับ visualizing Erlang process ภายใน BEAM VM
  ตัวอย่างสกรีนช็อตดูได้จาก เอกสารของ Fly.io

  • อีกไม่นานจะปล่อย แดชบอร์ด ชื่อ jido_studio ซึ่งใช้แสดงภาพโครงสร้าง process
    ดูทีเซอร์สกรีนช็อตได้ ที่นี่
    เอเจนต์ที่ห่อด้วย AgentRuntime โดยทั่วไปจะทำงานเป็น GenServer process เดียว แต่ก็มีข้อยกเว้นเวลาต้องใช้ topology ที่ใหญ่ขึ้น

• จังหวะสมบูรณ์แบบเลย ผมเองก็กำลังทำ Erlang agent framework อยู่ แต่ตัวนี้ดูดีกว่ามาก

• สงสัยว่าเรื่องความปลอดภัยรับประกันอย่างไร ถ้าไม่มีการแยกแบบคอนเทนเนอร์ก็คงยากที่จะกัน production secret รั่วไหล

  • ถ้าใช้ Signals กับ Plugins ก็สามารถ เข้ารหัส ข้อมูลระหว่างเอเจนต์ได้
    ผมก็เคยเห็นเคส Jido ที่ทำแบบนั้นจริง
    แต่เรื่องนี้ขึ้นอยู่กับ use case และความปลอดภัยก็เป็นประเด็นที่กว้างกว่าปัญหา “เอเจนต์ในคอนเทนเนอร์” มาก
    จุดประสงค์ของ Jido ไม่ใช่การแก้ปัญหาความปลอดภัยให้โดยตรง แต่คือ มอบเครื่องมือให้ผู้ใช้ไปแก้ในแบบที่ต้องการ