OpenConnector คือเกตเวย์ตัวกลางที่คั่นระหว่างบัญชีออนไลน์ที่ใช้งานจริงกับ AI agent ซึ่งเป็นโปรแกรม AI ที่รับงาน ตัดสินใจ และลงมือทำได้เอง แนวคิดนี้ตั้งต้นจากคำถามเดียวว่า ทำไม agent ต้องถือรหัสของเราไว้เอง

เมื่อเริ่มใช้ agent ทำงานแทนอย่างจริงจัง มันก็ต้องเข้าถึงอีเมล แชท โน้ต ชีต และฐานข้อมูล วิธีที่คนส่วนใหญ่ใช้คือแปะ token ลงในไฟล์ตั้งค่าแล้วปล่อยให้ agent อ่านเอง โดย token นี้เป็นรหัสลับที่ระบบออกให้ใช้แทนการล็อกอิน

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

agent สั่งงานผ่านเกตเวย์ได้เฉพาะ Action

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

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

ตัวเกตเวย์เปิดเป็นโอเพนซอร์ส คือเปิดซอร์สโค้ดให้ทุกคนเอาไปอ่าน แก้ และใช้ต่อได้เอง

ทีมผู้พัฒนา oomol-lab เลือกใช้สัญญาอนุญาต Apache-2.0 ซึ่งเอาไปใช้งานเชิงพาณิชย์ได้

เอกสารของโปรเจกต์ยังระบุไว้ตรง ๆ ว่า OpenConnector เป็นทางเลือกแทน Composio ซึ่งเป็นบริการเชื่อมบัญชีแอปให้ agent และเป็นที่รู้จักกันดีในวงการนี้

ในแคตาล็อกกลางมีอะไรให้ agent เรียกบ้าง

การวางระบบเพิ่มนี้คุ้มค่าเพราะมีแคตาล็อกกลางที่รวมผู้ให้บริการมากกว่า 1,000 เจ้า และ Action สำเร็จรูปมากกว่า 10,000 รายการ ทั้งหมดนี้ติดมากับตัวเกตเวย์เลย ไม่ต้องไล่เขียนโค้ดเชื่อมกับ API ของแต่ละบริการเอง โดย API คือช่องทางที่บริการเปิดไว้ให้โปรแกรมอื่นเรียกใช้ได้

ตัวอย่างที่โปรเจกต์ยกมาล้วนเป็นเครื่องมือที่คนทำงานใช้กันจริง ๆ ทั้ง Gmail · Notion · Slack · Airtable · Supabase · Google Analytics ไปจนถึงคลังข้อมูลอย่าง BigQuery

การต่อบัญชีรองรับหลายแบบ ทั้งแบบ API key ซึ่งเป็นรหัสที่บริการออกให้ใช้เชื่อมต่อ · แบบ OAuth2 ที่กดอนุญาตผ่านหน้าล็อกอินของเจ้าของบริการโดยตรง เหมือนตอนกดล็อกอินด้วยบัญชี Google เข้าเว็บอื่น · แบบกำหนดเอง · และบริการที่ไม่ต้องยืนยันตัวตนเลย

ติดตั้งเกตเวย์เองด้วย Docker Compose

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

ก่อนต่อบัญชีจริง ควรลองยิง Action ที่ไม่ต้องยืนยันตัวตนสักครั้ง เพื่อยืนยันว่าเกตเวย์ทำงานได้โดยไม่ต้องนำบัญชีใดไปเสี่ยง จากนั้นค่อยต่อ GitHub เป็นบริการจริงเจ้าแรก GitHub คือแหล่งเก็บโค้ดที่ทีมพัฒนาทั่วโลกใช้กัน และใช้ personal access token ที่ผู้ใช้สร้างเองได้จากหน้าตั้งค่า จึงไม่ต้องตั้ง OAuth ให้ยุ่ง

# 1 · สั่งรันเกตเวย์ (ดึงอิมเมจ ghcr.io/oomol-lab/open-connector:latest)
docker compose up

# 2 · เปิดคอนโซลที่ http://localhost:3000 และหน้าเอกสาร API ที่ http://localhost:3000/docs

# 3 · ยิง Action ที่ไม่ต้องยืนยันตัวตน เพื่อเช็กว่าเกตเวย์ตอบกลับมาจริง
curl -s -X POST http://localhost:3000/v1/actions/hackernews.get_top_stories \
  -H 'content-type: application/json' -d '{"input":{}}'

# 4 · ต่อ GitHub ด้วย personal access token
curl -s -X PUT http://localhost:3000/api/connections/github \
  -H 'content-type: application/json' \
  -d '{"authType":"api_key","values":{"apiKey":"github_pat_..."}}'

# 5 · แล้วเรียก Action ของจริงบนบัญชีนั้น
curl -s -X POST http://localhost:3000/v1/actions/github.get_current_user \
  -H 'content-type: application/json' -d '{"input":{}}'

ขั้นที่ 4 คือการส่งรหัสของ GitHub เข้าไปเก็บไว้ที่เกตเวย์ ทำครั้งเดียวจบ ส่วนคำสั่งในขั้นที่ 5 ไม่มีรหัสอยู่ในนั้นเลยแม้แต่ตัวเดียว มีแค่ชื่อ Action กับข้อมูลนำเข้า และนั่นคือคำสั่งหน้าตาเดียวกับที่ agent จะเรียกในภายหลัง

นโยบายราย Action กับบันทึกที่ปิดบังข้อมูลอ่อนไหว

เมื่อรหัสมาอยู่ที่เกตเวย์แล้ว เราก็กำหนดนโยบายเป็นราย Action ได้ว่าอันไหนอนุญาตหรือบล็อก ต่างจากแบบเดิมที่ token เดียวเปิดสิทธิ์ทุกอย่างพร้อมกัน นอกจากนี้ยังกำหนดได้ว่าการเชื่อมต่อแต่ละรายการผูกกับบัญชีไหน · ให้สิทธิ์กว้างแค่ไหน · ใช้ token ของเกตเวย์ตัวไหน · และเก็บไฟล์ที่ส่งผ่านไว้ชั่วคราวนานเท่าไร เรื่องนี้เป็นโจทย์เดียวกับการคุม AI agent ไม่ให้ทำงานหลุดขอบ

อีกเรื่องคือการตรวจสอบย้อนหลัง ทุกครั้งที่เรียก Action เกตเวย์จะบันทึกเป็น log พร้อมปิดบังข้อมูลอ่อนไหว เปิดดูภายหลังได้ว่า agent เรียกบริการไหน กี่ครั้ง และพังตรงไหน ใช้แนวคิดเดียวกับเครื่องมือที่เปิดดูข้างใน agent ว่าพังตรงไหน เพียงแต่ความสามารถนี้ติดมากับเกตเวย์เลย

เชื่อมต่อกับ agent ผ่าน MCP หรือเรียกจากโค้ดด้วย SDK

ช่องทางเรียกเกตเวย์มีให้เลือกตามรูปแบบระบบที่แต่ละคนใช้งานอยู่

• เขียนโค้ดในแอปของตัวเอง เรียกผ่าน SDK ซึ่งเป็นชุดโค้ดสำเร็จสำหรับเชื่อมแอปกับเกตเวย์
• มี agent รันอยู่ในเครื่อง สั่งผ่าน oo CLI ซึ่งเป็นเครื่องมือสำหรับพิมพ์คำสั่งในเทอร์มินัล
• ใช้โปรแกรมที่รัน agent อยู่แล้ว ต่อผ่าน MCP ซึ่งเป็นมาตรฐานกลางที่ให้ AI agent เรียกใช้เครื่องมือภายนอกได้
• อยากเขียนตัวเรียกเอง ก็เรียกผ่าน HTTP ได้โดยตรง HTTP เป็นช่องทางที่เว็บทั่วไปใช้สื่อสารกัน ส่วนวิธีเรียกใช้งานดูได้จากหน้าเอกสาร OpenAPI ที่ระบบสร้างให้อัตโนมัติ
• แค่อยากดูการทำงานและไล่หาข้อผิดพลาด ก็เปิดคอนโซลเว็บ

เกตเวย์เปิดช่องทาง MCP ไว้แล้วที่ http://localhost:3000/mcp ตั้งค่าให้โปรแกรมที่รัน agent เชื่อมต่อมาที่นี่ ก็ใช้เครื่องมือหลักหมื่นรายการได้ทันที โดยไม่ต้องเขียนตัวเชื่อมเองสักบรรทัด

ฝั่งโค้ด @oomol-lab/connector เป็นแพ็กเกจหรือชุดโค้ดสำเร็จที่ติดตั้งเข้าโปรเจกต์แล้วเรียกใช้ได้เลย แพ็กเกจนี้มีขนาดเล็กมาก ไม่ต้องลากโค้ดของเจ้าอื่นมาพ่วงเพิ่มเลย โดยทำแค่สองอย่างคือเตรียมคำขอส่งไป แล้วอ่านข้อมูลจากคำตอบที่ได้กลับมา ส่วนการเชื่อมต่อกับบริการปลายทางทั้งหมดเป็นหน้าที่ของเกตเวย์

ติดตั้งด้วย npm install @oomol-lab/connector แล้วเรียกได้สองแบบ คือ oomol.execute("gmail.search_threads", { query }) หรือแบบสั้น oomol.gmail.search_threads({ query }) ใครอยากให้โปรแกรมเขียนโค้ดช่วยแนะนำชื่อ Action และช่องข้อมูลที่ถูกต้องขณะพิมพ์ ก็เสริมด้วย @oomol-lab/connector-types ได้ แต่ไม่ติดตั้งก็เรียกได้ตามปกติ

ในแพ็กเกจเดียวกันนี้มีตัวเรียกแยกกันสามแบบ รูปแบบคีย์ต่างกันชัดเจนเพื่อไม่ให้หยิบสลับกันโดยไม่ตั้งใจ

จะวางระบบไว้ที่ไหนก็เลือกตามความถนัดได้ ไม่ว่าจะรันบนเครื่องตัวเองด้วย Docker หรือ Node.js ซึ่งเป็นเครื่องมือฝั่งนักพัฒนาทั้งคู่ · รันบน Fly.io · รันบน Cloudflare Workers · หรือใช้บริการที่ผู้พัฒนารันเซิร์ฟเวอร์ให้ก็ได้

ข้อจำกัดที่ต้องรู้ก่อนลงมือ

ของแบบนี้ไม่ใช่แอปที่กดติดตั้งแล้วใช้ได้ทันที คนที่จะติดตั้งเกตเวย์เองต้องพอใช้ Docker กับ Node.js เป็น และถ้าจะลงไปแก้ตัวเกตเวย์เองก็ต้องใช้ Node.js เวอร์ชัน 22 ขึ้นไป ส่วนคนที่แค่เรียกใช้ SDK จากแอปของตัวเองใช้เวอร์ชัน 18 ขึ้นไปก็พอ

โปรเจกต์เองก็พูดเรื่องนี้ตรง ๆ ว่าการติดตั้งเองมีไว้สำหรับทีมที่จะเอาตัวเชื่อมไปฝังในผลิตภัณฑ์หรือโครงสร้างพื้นฐานของตัวเอง ใครที่แค่อยากได้การเชื่อมบัญชีไปใช้เฉย ๆ โปรเจกต์แนะนำให้ใช้แอปเดสก์ท็อปอย่าง Wanta แทน เพราะไม่ต้องติดตั้งอะไรเอง

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

ถ้าจะถอนสิทธิ์ ต้องไปแก้กี่ที่

เครื่องมือเชื่อม agent กับบัญชีจะมีออกมาอีกเรื่อย ๆ คำถามที่ควรถามเมื่อเจอเครื่องมือแต่ละตัวคือ ถ้าวันหนึ่งอยากถอนสิทธิ์ agent จะต้องไล่แก้กี่ที่

ที่มา:

• GitHub · oomol-lab/open-connector จาก oomol-lab
• GitHub · oomol-lab/connector-sdk จาก oomol-lab