5 คะแนน โดย GN⁺ 2025-03-06 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • สเปกแบบเปิดที่นิยามสัญญาที่ชัดเจนระหว่าง LLM และ API โดยอิงจากมาตรฐาน OpenAPI
    • จัดโครงสร้างการเรียก API ให้เป็นเครื่องมือที่ยึดตามวัตถุประสงค์ เพื่อให้ LLM ใช้งานได้ง่าย
  • เอกสาร OpenAPI แบบเดิมเพียงอย่างเดียวทำให้ LLM เลือกและเรียก API ที่เหมาะสมได้ยาก
    • agents.json ช่วยให้กระบวนการเรียก API ยังคงเป็นแบบกำหนดได้แน่นอน ขณะที่ผลลัพธ์ที่ LLM ต้องการบรรลุสามารถดำเนินการได้แบบไม่กำหนดตายตัว

ทำไมจึงจำเป็น?

  • เมื่อต้องการใช้ LLM มักจำเป็นต้องลงมือพัฒนาวิธีเชื่อมต่อกับ API เอง
  • นักพัฒนาจำนวนมากยอมละทิ้งพฤติกรรมแบบไม่กำหนดตายตัวของเอเจนต์ และพยายามให้ได้ผลลัพธ์ที่ต้องการผ่านเวิร์กโฟลว์ที่ฮาร์ดโค้ดไว้
  • หากใช้ agents.json ระหว่างกระบวนการไปสู่ผลลัพธ์ที่ต้องการ LLM สามารถทำงานแบบไม่กำหนดตายตัวได้ ขณะที่การเรียก API เองยังคงทำงานแบบกำหนดได้แน่นอน
  • API แบบเดิมถูกออกแบบโดยยึดนักพัฒนาเป็นศูนย์กลาง จึงใช้งานโดยตรงกับ LLM ได้ยาก
  • ตัวอย่าง Gmail API:
    • จำเป็นต้องผ่านขั้นตอนการค้นหาอีเมล ดึงรายการอีเมลในเธรด และตอบกลับอีเมลฉบับที่ต้องการ
    • หาก LLM อ้างอิงเอกสาร OpenAPI ตรง ๆ ก็มักล้มเหลวในการเลือกการเรียก API ที่เหมาะสม
    • หากใช้ agents.json สามารถกำหนดการเรียก API ล่วงหน้าเพื่อให้ทำงานตามลำดับที่ถูกต้องได้

องค์ประกอบของ agents.json

  • ไฟล์ agents.json
    • ทำหน้าที่นิยามเครื่องมือที่เน้นผลลัพธ์ โดยเชื่อมโยงการเรียก API เข้าด้วยกัน
    • ใช้งานร่วมกับไฟล์ OpenAPI เดิม
  • agents.json SDK
    • ช่วยให้ LLM โหลดเครื่องมือโดยอิงจาก agents.json และรันชุดการเรียก API ต่อเนื่องกันได้

ความแตกต่างจาก OpenAPI เดิม

  • หากใช้เฉพาะ OpenAPI มักมีหลายกรณีที่ LLM เลือกการเรียก API ได้ไม่ถูกต้อง
  • หากใช้ agents.json สามารถทำให้กระบวนการเรียก API เป็นเทมเพลตได้ และมอบโฟลว์การเรียก API ที่เหมาะสมที่สุดเพื่อให้ได้ผลลัพธ์ตามต้องการ

เหตุผลที่เปิดเป็นโอเพนซอร์ส

  • ในช่วงแรกเป็นไฟล์คอนฟิกที่ใช้ภายใน แต่เมื่อความสามารถค่อย ๆ ขยายมากขึ้น จึงตัดสินใจเปิดเป็นโอเพนซอร์ส
  • Dharmesh CTO ของ HubSpot เป็นผู้เสนอแนวคิดเรื่องสเปกสำหรับแปล API เพื่อใช้กับ LLM และโครงการนี้ก็เปิดเผยสู่สาธารณะโดยได้รับแรงบันดาลใจจากแนวคิดดังกล่าว
  • ขณะนี้มีการผสานรวม API ที่ผ่านการตรวจสอบแล้ว 10 รายการ และมี API ใหม่เพิ่มเข้ามาทุกวัน
  • มีการให้บริการแพลตฟอร์มค้นหาเครื่องมือและคอลเลกชันแบบกำหนดเองฟรี เพื่อให้นักพัฒนาขยายต่อได้ง่าย (https://wild-card.ai)

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

 
GN⁺ 2025-03-06
ความคิดเห็นจาก Hacker News
  • กำลังจับตา agents.json อยู่ และหวังว่าโปรโตคอลนี้จะประสบความสำเร็จ

    • คิดว่า MCP และ agents.json อาจอยู่ร่วมกันได้
    • MCP ครอบคลุมสิ่งต่าง ๆ มากกว่า และการทำให้เป็นโปรโตคอลที่เรียบง่ายอาจเป็นเรื่องยาก
  • หาก agents.json ต้องการการยอมรับในช่วงแรก เอกสารควรเข้าใจได้ง่ายกว่านี้

    • ควรมีตัวอย่างให้เห็นได้ทันที และควรวางสคีมาไว้ใกล้ ๆ
    • คำอธิบายควรกระชับ และฟิลด์ในสคีมาก็ควรชัดเจน
    • อาจต้องมีเครื่องมือที่เมื่อวาง OpenAPI schema แล้วให้ LLM สร้างร่าง agents.json ได้
  • ความเข้ากันได้ระหว่าง OpenAPI และ agents.json นั้นดี แต่ก็อาจมากเกินไป

    • OpenAPI ได้รับความนิยม แต่ยังไม่ได้ครองตลาดทั้งหมด
    • หากสิ่งนี้เพิ่มความซับซ้อนให้ agents.json ก็ยังสงสัยว่าคุ้มค่าที่จะรองรับหรือไม่
    • ถึงจะไม่เข้ากันได้ 100% ก็อาจรองรับบางส่วนผ่านตัวแปลงแบบกำหนดเองได้
  • หลายคนกำลังใช้ agentic IDE อยู่ และคงจะดีถ้า agents.json แชร์สไนเป็ตที่อธิบายวิธีใช้งาน วิธีค้นหาเอกสาร และวิธีค้นหารีจิสทรี

  • คำถามเกี่ยวกับความแตกต่างระหว่าง agents.json กับข้อกำหนด OpenAPI Arazzo

    • สงสัยว่าเหมาะกับการใช้งานกับ LLM มากกว่าหรือไม่
    • จากตัวอย่างดูเหมือนมีแนวคิดที่คล้ายกัน
  • มีความเห็นว่าหาไฟล์ agents.json จริง ๆ ดูได้ยาก

    • ค้นหาในรีจิสทรีอยู่ 10 นาทีก็ยังไม่เจอตัวอย่าง
  • คำถามเกี่ยวกับไลเซนส์ของแพ็กเกจ Python

    • สงสัยว่าเป็น AGPL หรือไม่
  • เป็นไอเดียที่ดี แต่ปัญหาเรื่องไลเซนส์อาจทำให้การนำไปใช้เป็นเรื่องยาก

    • อยากให้ทีมอธิบายว่าทีมงานจะนำแพ็กเกจ AGPL ไปใช้ในผลิตภัณฑ์ได้อย่างไร
  • น่าจะทำให้เรียบง่ายกว่านี้ได้ และนั่นเป็นเรื่องดี

    • อาจพบบั๊กในชื่อพร็อพเพอร์ตีข้อมูลของสเปก
  • การเปรียบเทียบระหว่าง agents.json กับ llms.txt

    • llms.txt ก็กำลังกลายเป็นมาตรฐานที่ช่วยให้ LLM เข้าใจ API เช่นกัน
    • ดูเหมือน agents.json จะเข้าใจโครงสร้างของเอนด์พอยต์ต่าง ๆ ได้ดีกว่า
  • คำถามว่าทำไม agents ถึงใช้ API ที่จัดทำเอกสารด้วย OpenAPI spec ไม่ได้

    • ในการทดสอบส่วนตัวใช้งานได้ดี แต่คงมีบางอย่างที่พลาดไป
  • หวังว่า agents.json และไฟล์ LLM.txt จะกลายเป็นมาตรฐานเรียบง่ายแบบเดียวกับ robot.txt

    • CrewAI, Letta/MemGPT, OpenHands/OpenDevin ต่างก็เกี่ยวข้อง แต่ยังไม่มีอะไรที่ข้ามขอบเขตได้
    • MCP เป็นแนวทางที่ยืดหยุ่นที่สุด และหวังว่าจะเข้ากันได้ดีกับ agents.json
    • ทีม Netlify กำลังคิดสิ่งที่น่าสนใจเกี่ยวกับ Agent Experience (AX) และทีม Anthropic กับ wildcard ควรจับตาดู
  • คำถามเกี่ยวกับความเหมือน/ความต่างกับ MCP

    • ดูเท่มาก