OpenAI เพิ่มการรองรับ MCP ให้กับ Agents SDK

 (openai.github.io)
8 คะแนน โดย GN⁺ 2025-03-27 | 4 ความคิดเห็น | แชร์ทาง WhatsApp
  • MCP(Model Context Protocol) คือวิธีการแบบมาตรฐานในการมอบเครื่องมือและคอนเท็กซ์ให้กับ LLM
  • ทำหน้าที่เป็นอินเทอร์เฟซมาตรฐานที่เชื่อมโมเดล AI เข้ากับแหล่งข้อมูลหรือเครื่องมือต่าง ๆ ได้ คล้ายกับพอร์ต USB-C
  • OpenAI Agents SDK รองรับ MCP ทำให้สามารถผสานรวมกับเซิร์ฟเวอร์ MCP ได้หลากหลาย

เซิร์ฟเวอร์ MCP

  • ขณะนี้สเปก MCP กำหนดเซิร์ฟเวอร์ไว้ 2 ประเภทตามกลไกการรับส่งข้อมูลที่ใช้:
    1. stdio เซิร์ฟเวอร์จะทำงานเป็นซับโปรเซสของแอปพลิเคชัน และอาจมองได้ว่าเป็นการทำงานแบบ "โลคัล"
    2. HTTP over SSE เซิร์ฟเวอร์จะทำงานจากระยะไกล และเชื่อมต่อผ่าน URL
  • สามารถเชื่อมต่อกับเซิร์ฟเวอร์เหล่านี้ได้โดยใช้คลาส MCPServerStdio และ MCPServerSse
  • ตัวอย่างเช่น วิธีใช้งานเซิร์ฟเวอร์ไฟล์ซิสเต็ม MCP อย่างเป็นทางการมีดังนี้: 
    async with MCPServerStdio(  
    params={  
        "command": "npx",  
        "args": ["-y", "@modelcontextprotocol/server-filesystem", samples_dir],  
    }  
) as server:  
    tools = await server.list_tools()

การแคช

  • การเรียก list_tools() จากเซิร์ฟเวอร์ MCP ทุกครั้งที่เอเจนต์ทำงาน อาจทำให้เกิดความหน่วงได้ โดยเฉพาะเมื่อเป็นเซิร์ฟเวอร์ระยะไกล
  • หากต้องการแคชรายการเครื่องมือโดยอัตโนมัติ สามารถส่ง cache_tools_list=True ไปยัง MCPServerStdio และ MCPServerSse ได้ แต่ควรทำเฉพาะเมื่อมั่นใจว่ารายการเครื่องมือจะไม่เปลี่ยนแปลง
  • หากต้องการล้างแคช สามารถเรียก invalidate_tools_cache() จากเซิร์ฟเวอร์ได้

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

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

 
GN⁺ 2025-03-27
ความคิดเห็นบน Hacker News

  • วันนี้ MCP ได้เพิ่ม Streamable HTTP แล้ว ซึ่งถือเป็นความก้าวหน้าครั้งใหญ่เพราะไม่จำเป็นต้องคงการเชื่อมต่อกับเซิร์ฟเวอร์ HTTP ระยะไกลไว้ตลอดเวลา

    • แต่พอดูสเปกแล้ว การนำพาราไดม์สไตล์ LSP มาใช้กับเซิร์ฟเวอร์ HTTP ระยะไกลกลับเพิ่มความซับซ้อนเข้าไปมาก
    • แต่เดิมจะเป็นวิธีส่ง HTTP POST ไปที่ /get_weather พร้อม { "location": "New York" }
    • มีการเสนอให้ลดความซับซ้อนและกลับไปใช้เซิร์ฟเวอร์ HTTP แบบดั้งเดิม โดยเจรจาเซสชันผ่านเฮดเดอร์ Authorization และใช้เอนด์พอยต์แบบดั้งเดิม
    • การสร้างเซิร์ฟเวอร์จะง่ายขึ้นมาก และเว็บเฟรมเวิร์กก็ไม่จำเป็นต้องอัปเดตให้เข้ากับสเปก

  • มีการเปรียบเทียบว่า MCP คือพอร์ต USB-C ของแอปพลิเคชัน AI

    • ในฐานะวิศวกรซอฟต์แวร์ คำเปรียบเทียบนี้ไม่ได้ช่วยอะไรนัก

  • เคยสงสัยว่า OpenAI จะสนับสนุนสิ่งนี้อย่างเป็นทางการหรือไม่ แต่ตอนนี้ได้คำตอบแล้ว

    • MCP ได้กลายเป็นมาตรฐานอุตสาหกรรมสำหรับการเชื่อมต่อ LLM เข้ากับเครื่องมือภายนอก

  • เคยหวังว่าจะรองรับ OpenAPI ฉันสร้าง MCP server มาบ้างสองสามตัว แต่รู้สึกว่ามันเป็น API ที่ยืดหยุ่นน้อยกว่าและมีเอกสารแย่กว่า

    • ยากที่จะหาจุดที่ MCP ดีกว่า OpenAPI โค้ดอาจน้อยลงเล็กน้อย แต่ตัวเลือกกลับลดลงมาก
    • อีกหน่อย Swagger ก็คงจะถูกฝังมาให้เอง

  • เข้าใจได้ยากว่าคุณค่าของ MCP คืออะไร มันให้ความรู้สึกเหมือนเป็นอีกหนึ่งสิ่งรบกวนท่ามกลางความสับสนของเทคโนโลยี AI ยุคใหม่

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

  • ฉันสร้างสถาปัตยกรรมที่ทำให้ AI agent ใช้ "เครื่องมือ" ได้บนเครื่องโลคัล รองรับ LLM และ LLM server ได้หลายประเภท

    • มันทำงานเป็นมิดเดิลแวร์ และทำงานแบบสตรีมระหว่าง LLM server กับแชตไคลเอนต์
    • เป็นโปรเจ็กต์โอเพนซอร์ส แต่ไม่มีคนสนใจโค้ดเลย ทำให้รีโปไม่ได้รับการอัปเดต

  • ยังมีวิดีโอที่แสดงให้เห็นอย่างแท้จริงว่า MCP ใช้งานอย่างไรไม่มากนัก และยังขาดกรณีใช้งานจริงสำหรับโปรแกรมเมอร์

  • มีการเปรียบเทียบว่า MCP คือพอร์ต USB-C ของแอปพลิเคชัน AI

    • แต่เพราะได้ยินเรื่องความเจ็บปวดจากการทำ USB implementation มาเยอะ จึงน่าจะดีกว่าถ้าหาคำเปรียบเทียบอื่น

  • ดูเหมือนว่ากำลังอ้างถึง HTTP+SSE ซึ่งเป็นเวอร์ชันเก่าของ MCP ไม่ใช่เวอร์ชัน Streaming HTTP ใหม่

    • ยังมีการรองรับ OAuth 2.1, JSON-RPC batching เป็นต้น

  • ถ้าอยากลอง MCP แบบง่าย ๆ ฉันทำ <a href="https://skeet.build/mcp" rel="nofollow">skeet.build/mcp</a> ไว้

    • สร้างขึ้นมาเพราะการตั้งค่า MCP ที่ซับซ้อน การรองรับที่ยังไม่ดี และความยากในการสร้างเอง
    • ส่วนใหญ่ใช้กับเวิร์กโฟลว์ประมาณนี้
      • เขียนสรุปตอนเริ่ม PR
      • สรุปลง Slack หรือคอมเมนต์ใน Linear/Jira
      • ดึง issue จาก Sentry มาแล้วแก้ไข
      • สร้าง Linear issue เมื่อพบบั๊ก
      • ดึง Linear issue มาแล้วทำ first pass
      • ดึงเอกสาร Notion และ PRD มาแล้วสร้าง API reference จากฐานโค้ด
      • สคีมา Postgres หรือ MySQL สำหรับการพัฒนาโมเดลอย่างรวดเร็ว
    • มุ่งเน้นที่ความง่ายในการใช้งาน เวิร์กโฟลว์สำหรับนักพัฒนาที่ใช้งานได้จริง และ MCP server คุณภาพสูง
 
samchon 2025-03-27

ผมเองก็รู้สึกว่า OpenAPI function calling น่าจะดีกว่าไม่ใช่เหรอครับ เพราะการต้องมาทำอันนี้ขึ้นใหม่ด้วยโปรโตคอล MCP ก็เป็นงานเหมือนกัน
 
mangoblue 2025-03-28

น่าจะเป็นความต่างระหว่าง push กับ poll ไหมครับ แทนที่จะทำ function calling แยกตามแต่ละโมเดลหรือแต่ละบริการ การโฮสต์สเปก MCP แล้วให้เอเจนต์มาคอย poll ดู น่าจะสะดวกกว่าสำหรับฝั่ง 3rd party