Apache Burr: สร้าง AI เอเจนต์และแอปพลิเคชันที่เชื่อถือได้

 (burr.apache.org)
1 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Apache Burr เป็นเฟรมเวิร์กสำหรับสร้างแอปพลิเคชัน AI เชิงการตัดสินใจด้วย Python ตั้งแต่แชตบอตแบบง่ายไปจนถึงระบบมัลติเอเจนต์ที่ซับซ้อน
  • แอปพลิเคชันถูกนิยามเป็นชุดของ แอ็กชันและทรานซิชัน และเขียนด้วยฟังก์ชัน Python กับเดคอเรเตอร์ โดยไม่ต้องใช้ DSL หรือ YAML
  • Burr UI มีความสามารถด้าน มอนิเตอร์ ดีบัก และติดตาม ในแต่ละขั้นตอนการทำงาน พร้อมดูการเปลี่ยนแปลงสถานะแบบเรียลไทม์ได้
  • สามารถบันทึกสถานะลงดิสก์ ฐานข้อมูล หรือแบ็กเอนด์แบบกำหนดเอง และกลับมาทำงานต่อจากจุดที่หยุดไว้ได้ รวมถึงรองรับการรออินพุตจากมนุษย์และการรันแบบขนาน
  • ทำงานร่วมกับเครื่องมือเดิมอย่าง OpenAI, Anthropic, LangChain, FastAPI, PostgreSQL เป็นต้น โดยใช้งานได้โดยไม่เกิด vendor lock-in หรือจำเป็นต้องมี wrapper

สร้าง AI เอเจนต์และแอปพลิเคชันที่เชื่อถือได้

  • Apache Burr เป็น Apache Incubating Project ที่ทำให้การพัฒนาแอปพลิเคชันที่มีการตัดสินใจทำได้ง่ายขึ้น
  • ขอบเขตการใช้งานครอบคลุมตั้งแต่แชตบอตแบบง่ายไปจนถึง ระบบมัลติเอเจนต์ ที่ซับซ้อน
  • แนวทางการพัฒนาเป็น Python ล้วน พร้อมแนวคิด “no magic”
  • ตัวชี้วัดสาธารณะที่แสดงไว้คือ GitHub Stars 1,641, PyPI Downloads 379k+ และ Discord Members 457+

Python API ที่เรียบง่ายและทรงพลัง

  • Burr มี อินเทอร์เฟซแบบประกอบต่อได้ สำหรับสร้างตั้งแต่แชตบอตไปจนถึงระบบมัลติเอเจนต์
  • โค้ดตัวอย่างใช้ burr.core ของ action, State, ApplicationBuilder เพื่อกำหนดแอ็กชัน chat
  • @action(reads=["messages"], writes=["messages"]) ใช้ระบุสถานะที่อ่านและสถานะที่เขียน
  • ApplicationBuilder() ใช้ตั้งค่าแอ็กชัน ทรานซิชัน สถานะเริ่มต้น และ local tracker ก่อนสร้างแอปพลิเคชัน
  • ตัวอย่างการรันอยู่ในรูปแบบ app.run(halt_after=["chat"], inputs={"llm_client": client}) โดยส่ง LLM client เข้าไปเป็นอินพุต

องค์ประกอบที่จำเป็นสำหรับการสร้างแอปพลิเคชัน AI

  • Simple Python API นิยามแอปพลิเคชันเป็นชุดของแอ็กชันและทรานซิชัน โดยใช้เพียงฟังก์ชัน Python และเดคอเรเตอร์ ไม่ต้องพึ่ง DSL หรือ YAML
  • Built-in Observability ช่วยให้สามารถมอนิเตอร์ ดีบัก และติดตามทุกขั้นตอนของแอปพลิเคชันแบบเรียลไทม์ผ่าน Burr UI
  • Persistence & State Management สามารถบันทึกสถานะลงดิสก์ ฐานข้อมูล หรือแบ็กเอนด์แบบกำหนดเองโดยอัตโนมัติ และกลับมาทำงานต่อจากจุดที่หยุดไว้ได้
  • Human-in-the-Loop สามารถหยุดการทำงานในขั้นตอนไหนก็ได้เพื่อรออินพุตจากมนุษย์ จึงเหมาะกับ approval workflow และเอเจนต์แบบโต้ตอบ
  • Branching & Parallelism รองรับการรันแอ็กชันแบบขนาน, fan out / fan in, การสร้าง DAG ที่ซับซ้อน และการประกอบ sub-application
  • Testing & Replay เพิ่มความมั่นใจในระบบ AI ด้วยการ replay การทำงานในอดีต การทดสอบแบบ unit test ในระดับแอ็กชันเดี่ยว และการตรวจสอบ state transition

การผสานรวมกับสแตกเดิม

  • Burr ผสานรวมกับเครื่องมือและเฟรมเวิร์กที่ใช้อยู่แล้วได้ โดยไม่บังคับให้เกิด vendor lock-in หรือใช้ wrapper
  • ในหมวดการผสานรวม LLM มี OpenAI, Anthropic และ Instructor
  • ในหมวดการผสานรวมเฟรมเวิร์กมี LangChain, Hamilton และ Haystack
  • ในหมวด UI และการเสิร์ฟมี Streamlit และ FastAPI
  • ในหมวดการตรวจสอบและสตอเรจมี Pydantic และ PostgreSQL
  • ดูรายการการผสานรวมทั้งหมดได้ในเอกสาร

ประสบการณ์ใช้งานของนักพัฒนาและทีม

  • รีวิวจาก Peanut Robotics ระบุว่าหลังจากประเมินหลายเฟรมเวิร์ก LLM แล้ว การจัดการสถานะ ของ Burr คือคำตอบที่ทรงพลังสำหรับการนำหุ่นยนต์ที่ขับเคลื่อนด้วยการตัดสินใจของ AI ไปใช้งานจริง
  • รีวิวจาก Watto.ai ระบุว่าสร้างแอปพลิเคชัน AI แบบโมดูลาร์ได้ง่าย และ UI ก็ช่วยให้ดีบักได้สะดวก
  • รีวิวจาก Paxton AI เน้นว่ามันไม่ใช้แนวคิดประหลาดและเข้าใจยากเพียงเพราะเป็น AI
  • รีวิวจาก Provectus ระบุว่าการจัดการสถานะของ Burr มีประโยชน์ในการสร้าง state snapshot การดีบัก การ replay และการสร้างเคสสำหรับการประเมิน
  • รีวิวจาก CognitiveGraphs ระบุว่าเมื่อเทียบกับแพลตฟอร์ม agentic LLM หลายตัว เช่น LangChain, CrewAi, AutoGen, Agency Swarm แล้ว Burr มอบเฟรมเวิร์กที่แข็งแรงกว่าสำหรับการออกแบบพฤติกรรมที่ซับซ้อน
  • รีวิวจาก TaskHuman ระบุว่าย้ายจาก LangChain มายัง Burr แล้วเริ่มต้นได้ภายในไม่กี่ชั่วโมง และย้ายโค้ดเบสทั้งหมดมาที่ Burr

ชุมชนและสถานะโครงการ

  • ชุมชนถูกจัดขึ้นเพื่อขอความช่วยเหลือ แชร์โปรเจกต์ และมีส่วนร่วมกับอนาคตของ Burr
  • ช่องทางการเข้าร่วมมี Discord, GitHub, Twitter / X
  • ทรัพยากรของโครงการเชื่อมไปยังเอกสาร ตัวอย่าง YouTube โรดแมป และบันทึกการเปลี่ยนแปลง
  • Apache Burr เป็นโครงการที่อยู่ระหว่างการบ่มเพาะภายใต้ Apache Software Foundation และได้รับการสนับสนุนจาก Apache Incubator
  • สถานะ incubation ไม่ได้สะท้อนความสมบูรณ์หรือเสถียรภาพของโค้ดเสมอไป แต่หมายความว่ายังไม่ได้รับการอนุมัติเต็มรูปแบบจาก ASF

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

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

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

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

    • แก่นสำคัญของระบบแบบเอเจนต์ไม่ใช่การใช้เอเจนต์ แต่คือการใช้มันเฉพาะเมื่อจำเป็นจริง ๆ ระบบที่ใช้งานได้ต้องมี pipeline/recipe สำหรับแสดงลำดับงานหลายขั้น, ระบบปฏิบัติการสำหรับรันโมเดลและขั้นตอนที่มีมนุษย์แทรกแซงอย่างเสถียรบนพูลของเอเจนต์เวิร์กเกอร์หลายตัว, การจัดการ/ดีพลอย/ความปลอดภัย/สิทธิ์ของสกิลแบบหนา ๆ ที่ทำงานให้มากที่สุดเท่าที่เป็นไปได้ด้วยโค้ด, และการจัดการบริบทเพื่อใส่บริบทที่เหมาะสมให้กับเซสชันที่เหมาะสม
      นอกจากนี้ยังต้องมีการจัดการโครงการที่ดูแลตั๋วงาน, dependency, ความคืบหน้า, และการรีสตาร์ตตั๋วที่ค้าง, การเก็บประวัติการสนทนาและความสามารถด้านหน่วยความจำ, การฝัน, การเรียนรู้สะสม, observability สำหรับดูต้นทุนและการใช้งาน, การประเมินพรอมป์ต์และการปรับจูนอัตโนมัติ, การสลับผู้ให้บริการโมเดลและการตรึงเวอร์ชันโมเดล, รวมถึง sandbox สำหรับรันเซสชันจริง
      ไม่จำเป็นต้องได้ทั้งหมดจากผู้ขายรายเดียว แต่ในกรณีส่วนใหญ่ผมคิดว่าไม่ควรถูกล็อกไว้กับผู้ให้บริการโมเดลเพียงรายเดียว และควรเป็นเจ้าของ บริบทของตัวเอง กับ การเรียนรู้สะสม ด้วยตัวเอง
    • จุดที่ร้ายแรงที่สุดของเฟรมเวิร์กเอเจนต์ส่วนใหญ่คือ มันบังตรรกะหลัก เราควรมองเห็นให้ชัดว่าอะไรถูกส่งไปยังโมเดลภาษา และอะไรถูกส่งกลับมา
      ทุกอย่างในแอปพลิเคชันแบบเอเจนต์สุดท้ายแล้วเกิดขึ้นในรูปของลำดับโทเค็นหรือการเรียกผู้ให้บริการ ดังนั้นภาพนี้ควรชัดเจนในแทบทุกชั้นของแอป
    • ผมเคยคิดคล้ายกันกับเฟรมเวิร์กฟรอนต์เอนด์หลายสิบตัว มันเหมือนแบกรับ นามธรรมและความซับซ้อน ขนาดใหญ่เพื่อรอผลตอบแทนที่ดูเหมือนจะมาในอนาคตแต่ไม่เคยมาถึง
      ถึงอย่างนั้นผู้คนก็ต้องการงานทำหรือของเล่นสนุก ๆ และ “คนถัดไป” ก็มักไม่ได้สำคัญอะไรนัก เลยดูเหมือนว่าหลายคนไม่ติดใจที่จะโยนผลงานจากเวลาทดลองเล่นที่มีคนจ่ายเงินให้นี้ต่อไปให้คนอื่นรับช่วง
    • ผมเห็นด้วยพอสมควรกับแนวทางสร้าง โค้ดแบบ 1:1 ให้เหมาะกับเอเจนต์เฉพาะตัว เพียงแต่เมื่อเราคิดค้นเทคนิคหรือวิธีใหม่ในเอเจนต์ตัวใหม่ขึ้นมา ก็จะมีคำถามด้านการบำรุงรักษาว่าจะอัปเดตเอเจนต์เก่าอย่างไร และอยากอัปเดตมันแค่ไหน
      เช่น Apache Burr ดูเหมือนจะรองรับหรือจะรองรับระบบ vector RAG แบบเสียบปลั๊กได้ แต่สิ่งที่ต้องการจริง ๆ คือวิธีเพิ่มเอกสารเข้าไปในบริบทและเก็บมันไว้เป็นส่วนหนึ่งของ system prompt ที่อัปเดตแล้ว พร้อมใส่การปรับแต่งที่เฉพาะเจาะจงมากเข้าไปในกระบวนการนั้น มันเป็นการใช้แนวคิด RAG เดิมในแบบคัสตอม จึงไม่ค่อยเข้ากับเฟรมเวิร์กใดเฟรมเวิร์กหนึ่ง
      สำหรับงานของผม การทำแบบคัสตอมคือคำตอบ แต่ทางเลือกเชิงวิศวกรรมสำหรับการรีเฟรชเอเจนต์เก่าก็ยังคงเป็นประเด็นอยู่
    • ข้อดีของเฟรมเวิร์กไม่ได้อยู่ที่ทำให้การเขียนเอเจนต์จริง ๆ ง่ายขึ้น แต่อยู่ที่เรื่องอย่าง เครื่องมือและ observability มากกว่า LangChain เองก็มีจุดให้วิจารณ์มากมาย แต่เรื่องนี้มันแสดงให้เห็นชัดมากตั้งแต่ช่วงแรก
      การทำแชตบอตขึ้นมาเองตั้งแต่ต้นอาจง่ายหรืออาจง่ายกว่า แต่เมื่อถึงเวลาต้องเพิ่ม observability หรือ tracing เรื่องจะเปลี่ยนไปทันที ถ้าแค่เพิ่ม environment variable ตัวเดียวแล้วสามารถไล่ดูการติดตามทั้งหมดใน UI ได้แทบไม่ต้องทำอะไรเพิ่ม โซลูชันที่ทำเองก็แข่งได้ยาก

  • สงสัยว่าหน้านี้ทำด้วย https://vorpus.github.io/performativeUI/ หรือเปล่า
    มันเหยียบครบแทบทุกคลิเช่ของ หน้าแลนดิ้งเพจที่สร้างด้วย AI เท่าที่จะเป็นไปได้ หรือไม่ก็อาจตั้งใจทำมาเพื่อเสียดสีก็ได้

  • ผมชอบใช้เฟรมเวิร์กนี้ทั้งในโปรเจกต์ส่วนตัวและโปรเจกต์งาน มันดีตรงที่ได้ เวิร์กโฟลว์แบบมีสถานะ ที่เชื่อถือได้สำหรับโมเดล AI พร้อม observability ฟรี
    ผมประกอบเครื่องมือที่เมานต์ state machine ของ Burr เข้ากับ MCP และให้เอเจนต์มีรางให้วิ่งตาม ขณะเดียวกันไม่ว่า state machine จะซับซ้อนแค่ไหน เครื่องมือ MCP ก็ยังถูกจำกัดไว้ที่การสำรวจ state machine: https://github.com/msradam/theodosia
    ตอนนี้กำลังทำงานแปลงสกิลให้เป็น state machine อยู่ สกิลยอดนิยมจำนวนมากถูกเขียนมาเป็นลำดับขั้นตอนที่โมเดล AI ทำตามได้อยู่แล้ว จึงคิดว่าถ้าใช้ความสามารถแบบ explicit ของ Burr น่าจะทำให้เสถียรขึ้นได้

  • อยากรู้ว่าเมื่อเทียบกับ https://strandsagents.com/ แล้วเป็นอย่างไร ผมสนใจเครื่องมือในสายนี้และยังไม่ได้ผูกกับตัวไหนเป็นพิเศษ แต่ Bedrock + Serverless on Agent Core ให้ความรู้สึกเหมือนเป็น “เส้นทางแนะนำที่ง่าย” เพียงแต่ไม่ค่อยชอบการผูกติดกับแพลตฟอร์ม

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

  • ตรงนี้เห็นทั้ง builder pattern และ decorator ใน Python ก็มี decorator เหมือนกัน แต่ผมมองว่ามันเหมาะที่สุดเมื่อใช้เป็น “ตัวกรอง” ที่ครอบฟังก์ชันหรือเมธอด เช่น ฟังก์ชันนี้ให้แคชไว้, เอาต์พุตของฟังก์ชันนี้ให้ serialize เสมอ, หรือเตรียมฟังก์ชันนี้ไว้เป็นเครื่องมือของตัวรันแบบเอเจนต์
    ผมไม่คิดว่ามันควรถูกใช้เพื่อการลงทะเบียนหรือควบคุมโฟลว์ อาจจะไม่เห็นด้วยก็ได้ แต่ต้องมีคนพูดบ้าง FastAPI พาการใช้ decorator แบบสมัยใหม่ออกนอกทางไปมากเกินไป
    builder pattern ใน Rust ใกล้เคียงกับธรรมเนียมที่เกิดขึ้นเพราะไม่มี named keyword arguments ส่วนฟังก์ชัน Python ก็เปิดเผยสัญญาแบบมีชื่ออยู่แล้ว แทบไม่มีเหตุผลเลยที่จะส่งพารามิเตอร์การตั้งค่าแบบเรียงลำดับผ่านการเรียกเมธอดต่อเป็นทอดๆ
    ถ้าต้องเพิ่มสถานะที่ยังไม่มีอยู่ใน constructor หรือ factory นั่นไม่ใช่ builder pattern แต่เป็นการลงทะเบียน จุดเดียวที่ผมพอจะยอมรับ builder pattern ได้คือตัว query builder เพราะมันเป็นการค่อยๆ ประกอบแนวคิดซ้ำๆ และช่อง metadata อย่างชื่อเมธอดกับ keyword arguments ก็มีประโยชน์จริง การใช้เมธอดที่รับพารามิเตอร์ตัวเดียวแทน keyword arguments ผมมองว่าไม่ถูกต้อง

    • ในที่นี้ decorator ใช้เพื่อติด metadata ให้ฟังก์ชันโดยเฉพาะ เพื่อให้กลายเป็น องค์ประกอบที่นำกลับมาใช้ซ้ำได้ และตัว builder ใช้สร้าง workflow ส่วนใน Hamilton นั้นเป็นการประกาศล้วนๆ จึงจัดการทั้งหมดด้วย decorator แต่เรื่องการนำกลับมาใช้ซ้ำจริงๆ แล้วเป็นอีกประเด็นหนึ่ง
    • builder pattern ไม่ได้ใช้แค่ใน Rust แต่ก็เห็นด้วยว่าพอมาใช้ใน Python แล้วมันดูไม่สวย

  • ดูเหมือนเป็นเวอร์ชันที่ค่อนข้างไร้เดียงสาของคำว่า AI agent ที่เชื่อถือได้
    ความน่าเชื่อถือหมายถึง “มันทำงานที่มอบหมายให้เสร็จได้ไหม” ไม่ได้เกี่ยวอะไรกับ state machine เป็นพิเศษ

  • เพิ่งเคยได้ยินชื่อ Burr เลยสงสัยว่าทำไมถึงได้เข้า incubation ของ Apache

    • ไม่มีเหตุผลอะไรที่จะเข้าไม่ได้ ASF มีประวัติยาวนานในการ incubate โปรเจกต์โอเพนซอร์สเสรีใหม่ๆ
      บางส่วนก็จบออกไปกลายเป็นชื่อที่ใครๆ ก็รู้จัก บางส่วนก็ล้มเหลวแล้วไปอยู่ใน attic ของ ASF ให้การสนับสนุนเชิงองค์กรและโดยทั่วไปก็ช่วยสร้างชุมชนที่ดี
    • เพราะผมเป็นคนส่งเข้าไปเอง เป็นกระบวนการที่ช้าเพราะต้องเรียนรู้ขั้นตอนของ Apache และทำงานอย่างอื่นควบคู่กันไป แต่ตอนนี้เริ่มมี แรงส่ง ขึ้นมาบ้างแล้ว และกำลังเริ่มออกรุ่นอย่างสม่ำเสมอมากขึ้น

  • หน้าตาดูเหมือนขยะใช้ครั้งเดียวที่ทำด้วย Claude Code และไม่พยายามเลยแม้แต่นิดเดียวที่จะให้ใช้งานได้โดยไม่ต้องมี JavaScript อย่างน้อยก็มี ความสอดคล้องของแบรนด์

  • หาเหตุผลที่ระบุชัดเจนของชื่อนี้ไม่เจอ แต่เผื่อใครสงสัย นี่คือตัวอย่าง Hamilton: https://github.com/apache/burr/tree/main/examples/multi-agen...

    • Burr ตั้งชื่อตาม Aaron Burr หนึ่งในบิดาผู้ก่อตั้งสหรัฐฯ รองประธานาธิบดีคนที่ 3 และทั้งผู้สังหารกับคู่อริของ Alexander Hamilton
      จุดเชื่อมกับ Hamilton คือมันเป็นไลบรารีโอเพนซอร์สตัวที่สองที่ DAGWorks ปล่อยออกมาต่อจากไลบรารี Hamilton ชื่อนี้มาจากจินตนาการว่า ถ้า Burr กับ Hamilton ประสานกันและก้าวข้ามความต่างเพื่อสร้างสหพันธรัฐที่ดีกว่าเดิมจะเป็นอย่างไร
      เดิมที Burr ถูกสร้างมาเป็นกลไกสำหรับจัดการสถานะระหว่างการรัน Hamilton DAG เพราะ DAG ไม่มีวงจร จากนั้นจึงตระหนักว่ามันใช้ได้กว้างกว่านั้นและเปิดเผยในวงกว้างมากขึ้น
      https://pypi.org/project/burr/

  • อยากรู้ว่ามี เครื่องมือหรือแพลตฟอร์ม orchestration สำหรับ coding agent อะไรที่พอแนะนำได้บ้างไหม อยากรัน จัดการ และมอนิเตอร์เอเจนต์ codex หรือ claude บนหลายเครื่อง
    ถ้าเป็นไปได้อยากได้แบบ self-host ได้หรือเป็นโอเพนซอร์ส claude code เองก็ดูเหมือนมีความสามารถแนวนี้อยู่ภายในเยอะ แต่ผูกกับ claude โดยเฉพาะ

    • จากที่ดูเอกสาร Burr มี agent cookbook ที่ใช้เริ่มต้นเรื่องนี้ได้ และน่าจะจัดการ workflow ข้ามหลายเครื่อง ได้ด้วย เลยสงสัยว่านี่อาจเป็นสิ่งที่คุณกำลังหาอยู่หรือเปล่า
      ยังไม่แน่ใจว่ามันผสานกับพวกสกิลต่างๆ อย่างไร แต่เท่าที่ดูน่าจะใช้งานได้
      https://burr.apache.org/docs/examples/agents/