OpenAI เปิดตัวโหมดนักพัฒนาใน ChatGPT ที่รองรับ MCP

 (platform.openai.com)
9 คะแนน โดย GN⁺ 2025-09-11 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • โหมดนักพัฒนา เป็นฟีเจอร์เบตาที่ให้ ไคลเอนต์ MCP แบบเต็มรูปแบบ (อ่าน/เขียน) สำหรับทุกเครื่องมือ โดยมุ่งเป้าไปที่นักพัฒนาที่ต้องการทดสอบการตั้งค่าคอนเน็กเตอร์ขั้นสูงอย่างปลอดภัย
  • ระหว่างใช้งานต้องระวังความเสี่ยงจาก prompt injection และ MCP ที่เป็นอันตราย รวมถึง ข้อผิดพลาดแบบทำลายล้างจากแอ็กชันเขียน และขั้นตอน ตรวจสอบ·อนุมัติ payload ก่อนเรียกใช้เครื่องมือมีความสำคัญ
  • การเปิดใช้งานทำได้ที่ Settings → Connectors → Advanced → Developer mode บนเว็บ และสามารถเพิ่ม เซิร์ฟเวอร์ MCP ระยะไกล เพื่อนำเข้าเครื่องมือและจัดการการเปิด/ปิดได้
  • ระหว่างการสนทนา เมื่อเลือก Developer mode แล้ว หาก ระบุคอนเน็กเตอร์และเครื่องมืออย่างชัดเจน จะช่วยให้เลือกเครื่องมือได้แม่นยำขึ้น และเทคนิคพรอมป์ตอย่าง กำหนดสคีมารับเข้า·ลำดับการทำงาน ก็มีประสิทธิภาพ
  • แอ็กชันเขียนจะ ต้องได้รับการอนุมัติโดยค่าเริ่มต้น และเครื่องมือที่ไม่มีคำอธิบายประกอบ readOnlyHint จะถูกมองว่าเป็นเครื่องมือเขียน จึงต้องใช้งานอย่างรอบคอบในมุมของ การป้องกันการใช้ผิดวัตถุประสงค์และการปกป้องข้อมูล

ภาพรวม

  • นิยาม: Developer mode ของ ChatGPT เป็นโหมดเบต้าที่มอบความสามารถแบบ ไคลเอนต์ที่มีสิทธิ์อ่าน/เขียน สำหรับคอนเน็กเตอร์และเครื่องมือ MCP ที่เชื่อมต่อทั้งหมด
  • กลุ่มเป้าหมาย: เปิดให้สำหรับ ผู้ใช้ Pro/Plus ที่สามารถตั้งค่าและทดสอบคอนเน็กเตอร์ได้อย่างปลอดภัย
  • ข้อควรระวัง: มีความเสี่ยงด้านความปลอดภัย เช่น prompt injection, ข้อมูลเสียหายจากข้อผิดพลาดการเขียนของโมเดล, และ MCP ที่ออกแบบมาเพื่อขโมยข้อมูล

การเปิดใช้งานและการนำเข้า MCP

  • เส้นทางการเปิดใช้งาน: เปิดใช้งานได้ที่ Settings → Connectors → Advanced → Developer mode
  • เพิ่มเซิร์ฟเวอร์ MCP: เมื่อลงทะเบียน เซิร์ฟเวอร์ MCP ระยะไกล ในแท็บ Connectors ของ Settings แล้ว เซิร์ฟเวอร์จะปรากฏในตัวเลือกเครื่องมือของ Developer mode ในการสนทนา
  • โปรโตคอล: รองรับ SSE, streaming HTTP
  • การยืนยันตัวตน: รองรับ OAuth หรือ ไม่ยืนยันตัวตน
  • การซิงก์เครื่องมือ: ในหน้ารายละเอียดคอนเน็กเตอร์ สามารถ เปิด/ปิดเครื่องมือด้วยสวิตช์ On/Off และใช้ Refresh เพื่อดึงรายการและคำอธิบายเครื่องมือล่าสุด

แนวทางการใช้เครื่องมือในการสนทนา

  • การเรียกใช้อย่างชัดเจน: ระบุชื่อ คอนเน็กเตอร์/เครื่องมือ ให้ชัดเจน เช่น “ใช้ update_record ของคอนเน็กเตอร์ Acme CRM เพื่อ …”
  • ห้ามใช้ทางเลือกอื่น: ระบุ เงื่อนไขห้ามใช้ เพื่อป้องกันความสับสน เช่น “ห้ามใช้การท่องเว็บในตัว ใช้เฉพาะ Acme CRM เท่านั้น”
  • แยกความต่างของเครื่องมือที่คล้ายกัน: กำหนด กฎลำดับความสำคัญ เช่น “สำหรับการนัดหมาย ให้ใช้ Calendar.create_event ก่อน และห้ามใช้ Reminders.create_task”
  • ตรึงสคีมารับเข้า·ลำดับการทำงาน: ระบุ ลำดับการเรียกใช้และรูปแบบ payload อย่างชัดเจน เช่น “ก่อนอื่น Repo.read_file { path } จากนั้น Repo.write_file …”
  • ลำดับความสำคัญของคอนเน็กเตอร์ที่ซ้อนกัน: ประกาศ นโยบายแหล่งข้อมูล เช่น “ข้อมูลสิทธิ์ให้ใช้ CompanyDB ก่อน และใช้แหล่งเสริมเฉพาะเมื่อเกิดความล้มเหลว”
  • ปรับปรุงคำแนะนำต่อโมเดล: หากฝั่งเซิร์ฟเวอร์ MCP ให้ คำอธิบายเครื่องมือเชิงพฤติกรรมและคำอธิบายประกอบพารามิเตอร์ ที่มีข้อความ ‘Use this when …’ จะช่วยเพิ่ม ความแม่นยำในการเลือกเครื่องมือ

ตัวอย่างพรอมป์ต

  • สร้างกำหนดการ: “สร้าง การประชุม 30 นาที พรุ่งนี้เวลา 3pm PT ด้วย Calendar.create_event และห้ามใช้เครื่องมือนัดหมายอื่น”
  • สร้าง PR: “ใช้ GitHub.open_pull_request สำหรับ feat-retry → main พร้อมระบุชื่อเรื่องและเนื้อหา และ ห้าม push เข้า main โดยตรง”
โฆษณา

ขั้นตอนการตรวจสอบ·อนุมัติ

  • ตรวจสอบการเรียกใช้เครื่องมือ: ขยายดู อินพุต·เอาต์พุตแบบ JSON ของแต่ละการเรียก เพื่อ ตรวจสอบ payload และทำ ดีบัก
  • แอ็กชันเขียนต้องได้รับการอนุมัติโดยค่าเริ่มต้น: เนื่องจาก การป้อนผิด อาจนำไปสู่ ข้อมูลเสียหาย/รั่วไหล จึงต้อง ยืนยันอีกครั้งก่อนส่ง
  • การพิจารณาแบบอ่านอย่างเดียว: จะถือเป็น เครื่องมืออ่าน เฉพาะเครื่องมือที่มีคำอธิบายประกอบ readOnlyHint เท่านั้น และ เครื่องมือที่ไม่มีคำอธิบายประกอบจะถือเป็นเครื่องมือเขียน
  • ตัวเลือกจดจำการอนุมัติ: สามารถจดจำ การอนุมัติ/การปฏิเสธ สำหรับเครื่องมือบางตัวระหว่างการสนทนาได้ แต่ควรอนุญาตเฉพาะกับ แอปพลิเคชันที่เชื่อถือได้ เท่านั้น
  • ขอบเขตของเซสชัน: เมื่อ เริ่มการสนทนาใหม่ หรือ รีเฟรชหน้า การจดจำการอนุมัติจะถูกรีเซ็ต

โมเดลความเสี่ยงและหลักปฏิบัติด้านความปลอดภัย

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

เคล็ดลับการใช้งาน

  • คู่มือการเลือกเครื่องมือ: ใส่คำอธิบายว่า ควรใช้เครื่องมือนี้เมื่อใด รวมถึง กรณีห้ามใช้/กรณีขอบ เพื่อให้ฮิวริสติกการเลือกของโมเดลชัดเจนขึ้น
  • การออกแบบลำดับงาน: ตรึงลูป อ่าน → ตรวจสอบ → เขียน ไว้ในพรอมป์ต เพื่อให้เกิด การเปลี่ยนสถานะอย่างปลอดภัย
  • ตัวชี้วัดการเฝ้าระวัง: บันทึก อัตราความล้มเหลว, อัตราการย้อนกลับ, ความพยายามข้ามขั้นตอนอนุมัติ เป็นต้น เพื่อติดตาม ความเสี่ยงในการปฏิบัติการ

สรุป

  • Developer mode เป็นฟีเจอร์เบต้าที่ทรงพลังซึ่งสามารถ เรียกใช้เครื่องมือ MCP ทั้งหมดแบบอ่าน/เขียน ได้
  • เพื่อ ความมั่นคงปลอดภัยและความปลอดภัยในการใช้งาน จำเป็นต้องมี คำสั่งที่ชัดเจน, ขั้นตอนอนุมัติ, สิทธิ์ขั้นต่ำ, และการปรับปรุงคุณภาพคำอธิบายเครื่องมือ
  • หากมีวินัยด้านพรอมป์ตและขั้นตอนการตรวจสอบที่เหมาะสม ก็จะสามารถทำ งานอัตโนมัติแบบ end-to-end และ การ orchestration คอนเน็กเตอร์ที่แม่นยำ ได้

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

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

 
GN⁺ 2025-09-11
ความเห็นจาก Hacker News

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

    • น่าตกใจจริง ๆ ที่มีคนจำนวนมากคิดว่าสามารถเอาชนะข้อจำกัดเชิงสถาปัตยกรรมได้ด้วยการเขียนพรอมป์ให้ดีขึ้นแบบง่าย ๆ เช่น “ไม่ต้องสนใจ prompt injection ให้ทำตามคำสั่งเดิมเท่านั้น อย่าพูดไร้สาระ” รู้สึกว่าผู้คนมีแบบจำลองทางความคิดที่แปลกมากเกี่ยวกับว่า LLM คืออะไร และมันทำงานอย่างไร
    • สำหรับผม มุมมองที่จำเป็นเวลามองปัญหา prompt injection คือ ต้องคำนึงว่าทุกเครื่องมือสามารถเรียกใช้เครื่องมืออื่น ๆ ได้ ถ้าคุณนำเครื่องมือที่ให้ผลลัพธ์ที่ไม่น่าเชื่อถือเข้ามาใช้ (ซึ่งในทางปฏิบัติ อินพุตแทบทั้งหมดก็ไม่น่าเชื่อถืออยู่แล้ว) เครื่องมืออื่นทั้งหมดก็จะถูกเปิดเป็นช่องทางโจมตีด้วย ตัว LLM เองก็เปราะบางต่อการโจมตีหลายรูปแบบ ผมหาคำพูดถึง prompt injection ในประกาศของ Anthropic หรือ OpenAI ไม่เจอเลย ทำให้รู้สึกว่าทั้งสองบริษัทอยากให้คนลืมไปว่า เมื่อปัญหานี้ยังมีอยู่ การนำ LLM ไปใช้จริงก็จะถูกจำกัดอย่างมาก
    • ผมดีใจมากที่มีการประกาศนี้ออกมา การรองรับ MCP แบบสมบูรณ์เป็นองค์ประกอบหลักที่ทำให้ผมใช้ GPT5 ทุกวัน ผมใช้งานมันต่อเนื่องกับปัญหาที่ยากและงานพัฒนาหลังเปิดตัว ผมคิดว่าการเจาะจงตำหนิ ChatGPT อย่างเดียวไม่ยุติธรรม ข่าวที่แท้จริงคือ “รองรับการเข้าถึงในฐานะ MCP client แบบสมบูรณ์” ซึ่งมีบางที่ทำมาก่อนแล้ว ดีใจที่ MCP กำลังกลายเป็นมาตรฐาน แต่ในด้านความปลอดภัย มันพึ่งพาเรื่องที่ยากในทางปฏิบัติอยู่ 2 อย่างอย่างมาก คือ (1) การควบคุมระดับเอเจนต์หรือ UI (ซึ่งส่วนใหญ่เปราะบาง อย่างที่อธิบายไว้ดีแล้ว) และ (2) การจัด OAuth scopes ให้ตรงกันอย่างสมบูรณ์ในหลาย MCP servers ตัว scope นั้นมีลักษณะคงที่และหยาบโดยโครงสร้าง ขณะที่พรอมป์และคอนเท็กซ์เป็นแบบไดนามิก ความไม่สอดคล้องนี้เองที่ก่อปัญหา
    • ก่อนหน้านี้ผมเคยมีกรณีที่โมเดลเผลอไปอ่านไลบรารีพรอมป์ที่บันทึกไว้แล้วเกิดสับสน ใช้เวลาพอสมควรกว่าจะไล่ต้นตอปัญหาย้อนกลับได้ และนั่นยังเป็นความผิดพลาดแบบ “เป็นมิตร” อยู่เลย ผมนึกสถานการณ์ออกได้ว่าใน NPM libraries บางตัว พรอมป์ที่ฝังมาเพียงตัวเดียวอาจสร้างความเสียหายร้ายแรงกับเวอร์ชันถัดไปได้
    • จริง ๆ แล้วผมยังไม่แน่ใจว่าระบบนี้สร้างความเสี่ยงใหม่อะไรขึ้นมาโดยเฉพาะ อยากรู้ว่ามันต่างจากความเสี่ยงทั่วไปของ MCP อย่างไร และการที่มีโทเกิลแบบนี้ซ่อนอยู่ในเมนูตั้งค่า ก็น่าจะช่วยกันไม่ให้คนเปิดใช้โดยเผลอได้ระดับหนึ่งไม่ใช่หรือ

  • ตอนนี้บริษัท AI กำลังพูดกันว่า “Agentic AI ถูกทำให้เป็นอาวุธแล้ว และโมเดล AI ถูกใช้ให้ทำการโจมตีไซเบอร์ขั้นสูงโดยตรง จึงต้องมีการกำกับดูแล” แต่ในเวลาเดียวกัน บริษัทพวกนั้นก็พูดว่า “นี่ไง วิธีมอบสิทธิ์เข้าถึงและสั่งงานข้อมูลส่วนตัวของคุณแบบเต็มรูปแบบให้ AI”

    • ไม่รู้สิ ทำไมมันให้ความรู้สึกเหมือนยุคเริ่มต้นของอินเทอร์เน็ตเลย! ได้เวลาลองทีละอย่างแล้ว ที่นี่คือ HACKER news ไม่ใช่เหรอ ต้องทดลองดูสิ
    • วันนี้ให้เข้าถึงทั้งแล็ปท็อป อีก 10 ปีข้างหน้าอาจให้เข้าถึงทั้งสมอง เทคโนโลยีอย่าง Neuralink เป้าหมายสุดท้ายก็ไม่ใช่แบบนั้นเหรอ

  • ผมยังไม่ค่อยเข้าใจว่าทำไมสิ่งนี้ถึงอันตราย อยากรู้ว่ามันต่างจากการที่ใครสักคนเชื่อม MCP แบบปกติแล้วใส่แค่พรอมป์ให้ใช้เครื่องมือชุดเดิมอย่างไร มันดูเหมือนเป็นแค่ “วิธีที่เทคนิคมากขึ้นนิดหน่อย” เท่านั้นเอง เลยอยากถามว่าผมกำลังพลาดอะไรไปหรือเปล่า

  • ผมรอให้ ChatGPT รองรับ MCP มานานแล้ว ตอนนี้ในที่สุดก็ทำได้ เลยตื่นเต้นมาก ขั้นต่อไปคือให้สิทธิ์ sandbox access/permission requests ผ่าน local system control MCP เพื่อให้ใช้ ChatGPT ได้เหมือน web agent

    • ผมกำลังทำสิ่งนี้พอดีกับ Filestash (https://github.com/mickael-kerjean/filestash) มันเข้าถึงโปรโตคอลจัดเก็บข้อมูลได้แทบทุกแบบ เช่น S3, SFTP, FTS, SMB, NFS, Sharepoint เป็นต้น และมีการควบคุมสิทธิ์แบบละเอียดมากในตัว รวมถึง chroot, SSO, RBAC และสามารถบังคับใช้กฎว่าใครทำอะไรได้ ที่ไหน อย่างไร (เอกสาร MCP: https://www.filestash.app/docs/api/#mcp)
    • อยากรู้ว่าพอจะยกตัวอย่าง use case ของ MCP ได้ไหม เผื่อจะมีอย่างอื่นที่เป็นประโยชน์กับผมด้วย
    • ผมก็กำลังพัฒนา MCP control plane อยู่เหมือนกัน ถ้าใครมีกรณีใช้งานที่น่าสนใจหรืออยากคุยกัน ติดต่อมาได้เลย ตั้งใจจะปล่อยโอเพนซอร์สภายในไม่กี่สัปดาห์ ตอนนี้ยังไม่สมบูรณ์มาก แต่สิ่งที่ทำในสองสัปดาห์ดูได้ที่ gateway.aci.dev

  • ช่วยอธิบายให้ชัดเจนหน่อยได้ไหมว่านี่คืออะไรกันแน่ เป็นแค่เพิ่มการรองรับ MCP ให้ CLI coding agent หรือว่าเพิ่ม MCP ให้แชตบอตออนไลน์

    • ใช้กับแชตบอต

  • เท่าที่ผมเข้าใจ นี่คือการทำให้ ChatGPT เชื่อมต่อกับ MCP servers แบบกำหนดเอง/ของผู้ใช้เอง เพื่อเข้าถึงข้อมูลหรือรันคำสั่งได้ ตอนแรกผมนึกว่า developer mode มีไว้สำหรับพัฒนาโค้ด แต่ดูเหมือนจะไม่ใช่

  • ผมคิดว่าหัวข้อของโพสต์นี้น่าจะควรเป็น "เพิ่มการรองรับ MCP แบบสมบูรณ์ให้ ChatGPT" มากกว่า การเรียกมันว่า "Developer Mode" ดูเหมือนตั้งใจเพื่อกันผู้ใช้ที่ไม่ใช่สายเทคนิคไม่ให้ทำอะไรอันตราย เพราะความจริงคือช่องโหว่ความปลอดภัยของ MCP กับการโจมตีแบบ prompt injection มันเกิดได้ง่ายเกินไป

    • ผมเพิ่มเรื่องการรองรับ MCP แบบสมบูรณ์ไว้ในหัวข้อด้านบนแล้ว ขอบคุณ
    • ประโยคที่ว่า “ฟีเจอร์นี้เปิดให้ผู้ใช้ web แบบ pro/plus” ทำให้สับสน เพราะใน Claude ผมใช้ local MCP servers แบบไม่ต้องยืนยันตัวตนบ่อยมาก และเท่าที่เข้าใจ การใช้ local MCP น่าจะมีให้แค่แพ็กเกจ Pro หรือ Business ไม่รองรับ Plus ค่า Pro เดือนละ 200 ดอลลาร์ยังแพงเกินไปสำหรับผม ตอนนี้ Plus ยังไม่รองรับ local MCP ใช่ไหม?
    • พูดได้ตรงประเด็นจริง ๆ ตอนนี้ดูเหมือน OpenAI จะมาถึงจุดที่ยอมรับความเสี่ยงของความเสียหายจากการเรียก MCP แล้ว ดีกว่าจะทำเหมือนไม่มีความเสี่ยงของ MCP ต่อไป

  • ผมพบช่องโหว่ MCP หลายแบบใน MCP อย่างเป็นทางการ และกำลังแชร์ไว้ในบล็อก (https://tramlines.io/blog) นอกจากนี้ก็มีระบบป้องกันรันไทม์สำหรับ ‘การโจมตี MCP แบบสามชั้น’ ที่เปิดให้ใช้อยู่ที่ https://tramlines.io มานานแล้ว

  • ทำให้นึกถึงที่ Jony Ive เคยพูดว่าเขา “ต้องรับผิดชอบต่อผลลัพธ์ที่ไม่พึงประสงค์จากการที่หน้าจอกลายเป็นเรื่องปกติในชีวิตประจำวัน” และในบริบทที่ Sam พูดว่า “กระบวนทัศน์การประมวลผลแบบใหม่จริง ๆ เกิดขึ้นไม่บ่อยนัก ใน 50 ปีที่ผ่านมาอาจแค่สองครั้ง? คุณจะตื่นเต้นและทึ่งกับมันมากพอก็ได้” ผมเลยเดาว่าบริการสั่งงานด้วยเสียงที่บูรณาการเต็มรูปแบบอาจเป็นกระบวนทัศน์นั้น OpenAI น่าจะพยายามผลักดันการรองรับเสียงที่ทรงพลังขึ้นและการเชื่อมกับแอปที่ลึกขึ้นในอนาคต การรวม MCP ครั้งนี้ให้ความรู้สึกเหมือนก้าวแรกแบบระมัดระวังในการลองอนาคตที่ Sam และ Jony วาดภาพไว้

  • ผมลองเชื่อม MCP ของเรา (https://technicalseomcp.com) แล้วแต่ขึ้น error ดูเหมือนยังไม่มีฟีเจอร์สำหรับดีบักนะ ผมไปเจอตัวอย่างการใช้งานในเอกสารทางการ: https://platform.openai.com/docs/mcp

    • อยากรู้ว่าเจอ error อะไรบ้าง ฝั่งผม MCP server ของผมเชื่อมกับ Claude ได้ แต่พอใช้กับอันนี้ขึ้น “Error fetching OAuth configuration”
    • ช่วงไม่กี่สัปดาห์มานี้มีคนโพสต์ปัญหานี้ในฟอรัมทางการต่อเนื่อง แต่ดูเหมือนไม่ค่อยมีอะไรดีขึ้นเท่าไร (ถ้าจะเมิน bug report หมด แล้วการทดสอบเบต้าจะมีความหมายอะไร) https://community.openai.com/t/error-oauth-step-when-connecting-mcp-to-chatgpt/1287645/2