เราสร้างตัวเชื่อมต่อ Snowflake สำหรับ AI agent ใน 6 ชั่วโมงได้อย่างไร

เมื่อวานนี้ วิศวกรคนหนึ่งในทีมของเราดู Anthropic นำเสนอ GTM stack ภายในของพวกเขาบนเวที SaaStr ถ่ายภาพสไลด์ไว้ และถาม Zero เพียงคำถามเดียว: เราขาดตัวไหนบ้างในนี้? หกชั่วโมงสิบเก้านาทีต่อมา Snowflake ก็พร้อมใช้งานใน production สำหรับลูกค้า Zero ทุกคน นี่คือตัวเชื่อมต่อที่ 180 ที่เราส่งมอบในรอบปี และยิ่งไปกว่านั้น คนที่เขียนตัวถัดไปมักไม่ใช่วิศวกรอีกต่อไปแล้ว นี่คือกรอบงานและทักษะภายในที่ทำให้สิ่งนี้เป็นไปได้

สิ่งที่ไม่มีใครบอกคุณเกี่ยวกับแพลตฟอร์ม agent

LLM ก็เหมือนสมองในขวดลอยเดี่ยว มันแต่งกลอนเกี่ยวกับ data warehouse ของคุณได้ แต่เปิดมันจริง ๆ ไม่ได้ สิ่งที่เปลี่ยน chatbot ให้กลายเป็น agent และเป็นสิ่งที่ทีมของคุณจ่ายเงินซื้อ คือความสามารถที่ agent จะเข้าถึงเครื่องมือที่คุณใช้อยู่แล้วและ ลงมือทำงาน ในเครื่องมือเหล่านั้น

เราเรียกความสามารถนี้ว่า connector layer หลังจากสร้าง Zero มาหนึ่งปี เราเชื่อว่านี่คือโครงสร้างพื้นฐานที่สำคัญที่สุดในผลิตภัณฑ์ agent ดังนั้นเราจึงสร้างของเราเอง และที่สำคัญกว่านั้น เราสร้างเวิร์กโฟลว์ที่ให้ใครในทีมก็เป็นผู้สร้าง connector ได้

ทำไมไม่ใช้ MCP ทำไมไม่ใช้ Zapier

ทั้งสองถูกถามถึงตั้งแต่แรก ทั้งสองเหมาะกับสิ่งที่เป็น แต่ไม่ใช่สิ่งที่เราต้องการ

MCP เป็นโปรโตคอล ไม่ใช่ผลิตภัณฑ์ เหมาะสำหรับผู้สร้างเครื่องมือที่ต้องการให้บริการของตนเข้าถึงได้โดย LLM ใดก็ได้ แต่ MCP server ที่ใช้งานจริงในปัจจุบันจะให้โมเดลรายชื่อเครื่องมือและเชื่อว่ามันจะเรียกใช้งานได้อย่างปลอดภัย ไม่มี vault เก็บข้อมูลรับรองแยกองค์กร ไม่มีไฟร์วอลล์ควบคุม endpoint ที่เข้าถึงได้ ไม่มี audit log ที่ผูกการเรียกใช้งานกับมนุษย์ที่อนุมัติ สำหรับผลิตภัณฑ์ที่ agent หนึ่งอาจแตะ Stripe production ของลูกค้า และอีก agent อาจร่างอีเมลใน Gmail ของ CEO การ "เชื่อใจโมเดล" ไม่ใช่โมเดลความปลอดภัย

แพลตฟอร์มอินทิเกรชันแบบ Zapier แก้ปัญหาอีกแบบ: เชื่อม trigger แบบกำหนดไว้ล่วงหน้ากับ action แบบกำหนดไว้ล่วงหน้า agent ไม่ทำงานแบบนั้น agent ตัดสินใจระหว่างทางว่าสเต็ปถัดไปคือ query Snowflake แล้วค่อยสร้าง ticket ใน Linear มันต้องการข้อมูลรับรอง, HTTP client ที่กำหนดขอบเขต, และ audit trail ทันที ไม่ใช่สูตรสำเร็จที่เตรียมไว้

เราจึงสร้างสิ่งที่ดูธรรมดา: registry ของอินทิเกรชันที่แต่ละรายการมีข้อมูลรับรอง, การแมป environment ว่า secret ไหนจะถูก inject เข้า sandbox, ไฟร์วอลล์ควบคุม host ที่อนุญาต, และ handler เล็ก ๆ สำหรับ OAuth หรือ token เฉพาะ นี่คือโครงสร้างพื้นฐาน

แต่โครงสร้างพื้นฐานไม่ใช่ส่วนที่น่าสนใจ ส่วนที่น่าสนใจคือสิ่งที่เกิดขึ้น บน โครงสร้างนี้

ทักษะที่เปลี่ยนทุกคนให้เป็นผู้สร้าง connector

ทุกวันจะมี SaaS ใหม่ ๆ เข้าคิวรออินทิเกรชันใน backlog ของเราประมาณสองรายการ บางอันมาจากคำขอลูกค้า บางอันมาจากเพื่อนร่วมทีมที่เห็นว่า Zero ยังทำสิ่งที่ต้องการไม่ได้ บางอันมาจากการคุย BD ที่ stack ของลูกค้ามีเครื่องมือที่เรายังไม่รู้จัก

ถ้าทุกอันต้องผ่านคิววิศวกร เราคงส่งมอบได้สัปดาห์ละอัน แต่เราส่งมอบได้วันละอัน

เหตุผลคือเครื่องมือภายในที่เราเรียกว่า connector-authoring skill มันคือทักษะของ Zero แบบเดียวกับที่ส่งให้ลูกค้า แต่ชี้เข้าฐานโค้ดของเราเอง เมื่อใครในทีมพูดว่า "อยากเพิ่ม Notion connector" Zero จะพาเดินทีละขั้นตอน:

1. เริ่มจากสถานการณ์ผู้ใช้ ผู้ใช้ต้องการ ทำอะไร กับเครื่องมือนี้? "query ฐานข้อมูล" "สร้างหน้า" "ค้นหาทั่ว workspace" ทักษะนี้จะยืนยันให้ได้ user story ที่ชัดเจนก่อนแตะไฟล์ใด ๆ เป้าหมายของ connector คือเปิดความสามารถ agent ไม่ใช่ห่อ API ทั้งหมด
2. ระบุรูปแบบ auth OAuth, API token หรือทั้งสอง ทักษะนี้รู้ว่ารูปแบบแต่ละแบบต้องทำอะไร: ถ้า OAuth ก็ต้องมี consent UI และ redirect ถ้า API token ก็ต้อง inject secret ต่อองค์กรและบอกผู้ใช้เอา token จากไหน ผู้เขียนเลือกแบบที่ตรงกับเครื่องมือ ทุกอย่างต่อจากนั้นจะไหลตาม
3. แมป endpoint กับสถานการณ์ ไม่ใช่ "ห่อ REST API ทั้งหมด" แต่เลือก endpoint ไม่กี่อันที่ตอบ user story ได้จริง connector ที่เลือก endpoint ได้เหมาะสมสามอัน ดีกว่าที่มีสี่สิบอันแต่ agent ไม่เคยใช้
4. สร้างไฟล์สิบสองไฟล์ รายการใน registry, handler, ไฟร์วอลล์, ไอคอนแพลตฟอร์ม, การแมป environment, ทักษะฝั่ง agent ที่สอน Zero ใช้ connector ทักษะนี้จะสร้างโครง ผู้เขียนเติม intent
5. เปิดสอง PR หนึ่งไปที่ framework ของ connector หนึ่งไปที่ skill library ทั้งสองจะถูกวิศวกรรีวิว แต่รีวิวเน้นความถูกต้อง ไม่ใช่สอน framework

สิ่งที่เคยต้องใช้ความรู้เฉพาะองค์กร (auth แบบไหน endpoint ไหน ไฟล์สิบสองไฟล์ในสอง repo ไหน ไฟร์วอลล์กับ subdomain แบบไดนามิกประกอบกันอย่างไร) ตอนนี้อยู่ในทักษะนี้แล้ว ผู้เขียนนำความเข้าใจผู้ใช้มา ทักษะนำโครงสร้างมา

นี่คือเหตุผลที่ดีไซเนอร์, BD lead หรือ PM สามารถส่งมอบ connector ได้ พวกเขารู้ว่าผู้ใช้ต้องการอะไร ทักษะรู้ทุกอย่างที่เหลือ

กรณีศึกษา: Snowflake เมื่อวานนี้

เมื่อวาน Anthropic นำเสนอ GTM stack ภายในบนเวที SaaStr: Salesforce เป็นระบบหลัก, Clay สำหรับ enrichment, LeanData สำหรับ routing, Gong สำหรับโทร, Jira สำหรับ ticket, Intercom (Fin) สำหรับซัพพอร์ต, Ironclad สำหรับสัญญา, Snowflake เป็น data warehouse [ลิงก์ไปยังการพูดคุย]

วิศวกรของเราคนหนึ่งถ่ายภาพสไลด์แล้วโยนเข้า Zero พร้อมคำถามเดียว: "เราขาด connector ตัวไหนในนี้?"

นี่คือไทม์ไลน์จริงที่เกิดขึ้น เวลาทั้งหมดเป็น PDT

16:59. รูปสกรีนช็อตเข้ามา Zero เปรียบเทียบกับแค็ตตาล็อก connector: 7 จาก 10 มีอยู่แล้ว (Salesforce, Gong, Jira, Intercom, Ironclad, Gmail, Slack) ขาดสามตัว (Clay, LeanData, Snowflake) และ Snowflake ถูกจัดว่ามีค่าที่สุดเพราะ data warehouse คือรากฐานของ GTM stack ตอบกลับที่ 17:00

17:01. ถามต่อ: "ตัวไหนทำเป็น api-token connector ได้บ้าง?" Zero ดึงเอกสาร auth: Clay มี API key ส่วนตัว, Snowflake เพิ่งเปิด Programmatic Access Tokens, LeanData มีแต่ OAuth และผูกกับ Salesforce สรุปที่ 17:02: Snowflake ก่อน (ค่ามากสุด, auth สะอาดสุด) แล้วค่อย Clay

17:04. วิศวกรสั่ง "เริ่ม" ทักษะ connector-authoring รับช่วงไป ภายใน 17:07 ได้ตัด Clay ออก (public surface มีแต่ webhook ต่อ table ไม่มี connector จริงให้สร้าง) และยืนยันรูปแบบ Snowflake: SNOWFLAKE_PAT secret + SNOWFLAKE_ACCOUNT ตัวแปร, bearer auth กับ Snowflake REST API และ SQL API v2, ไฟร์วอลล์ subdomain แบบไดนามิกตาม Zendesk

17:35. เปิด PR ทั้งสองในนาทีเดียวกัน:

• vm0-skills#176: ทักษะฝั่ง agent วิธีเขียน Snowflake SQL, จัดรูปผลลัพธ์, retry เมื่อเกิด error ชั่วคราว
• vm0#13356: ตัว connector เอง รายการใน registry, handler PAT, ตัวสร้างไฟร์วอลล์, ไอคอนแพลตฟอร์ม, การแมป environment

18:22. PR ทักษะถูกรวม 18:42. PR connector ถูกรวม 18:52. Release PR เปิดอัตโนมัติ 23:18. [email protected] และ release train ที่เหลือขึ้น production Snowflake พร้อมใช้สำหรับทุกองค์กร

หกชั่วโมงสิบเก้านาที จาก "สกรีนช็อต stack ของ Anthropic" ถึง "Zero query warehouse ของคุณได้" วิศวกรคนเดียว การสนทนาเดียว ไม่มีการส่งต่อให้ "ทีม connector"

ความเร็วนี้ไม่ได้มาจากวิศวกรเร็ว แต่เพราะ connector-authoring skill รับช่วงงานที่เคยต้องใช้ความรู้เฉพาะองค์กร: เลือก auth แบบไหน, endpoint ไหนตรง user scenario, ไฟล์สิบสองไฟล์ต้องลง repo ไหน, ไฟร์วอลล์กับ subdomain แบบไดนามิกประกอบกันอย่างไร ผู้เขียนเติม intent ทักษะเติม โครงสร้าง Production จัดการส่วนที่เหลือ

นี่คือสิ่งที่ framework มอบให้ ไม่ใช่แค่ความเร็ว (แม้ความเร็วจะจริง) แต่คือ ใครก็ทำงานนี้ได้ ผู้สร้าง Snowflake คราวนี้บังเอิญเป็นวิศวกร แต่ไม่จำเป็นต้องเป็น

ทำไม api-token ถึงเป็นพลเมืองชั้นหนึ่ง

หมายเหตุที่ควรแยกออกมา เพราะนี่คือการออกแบบโดยตั้งใจที่หลายคนแปลกใจ

แพลตฟอร์ม agent ส่วนใหญ่ถือว่า OAuth คือ auth ที่แท้จริง api-token เป็นทางเลือกสำหรับเครื่องมือเก่า เราทำตรงข้าม API token เป็นพลเมืองชั้นหนึ่งในโมเดล connector ของเรา มี consent UI, vault ต่อองค์กร, audit trail, enforcement ไฟร์วอลล์เหมือนกัน

มีสองเหตุผล

หนึ่งคือ api-token auth ใช้งานได้เร็วกว่า Snowflake เพิ่งเปิด Programmatic Access Tokens ด้วยเหตุผลนี้: ข้อมูลรับรองที่อยู่นาน, กำหนดขอบเขตได้, เพิกถอนได้ ไม่ต้องเต้น OAuth ผู้ใช้ที่มี PAT ใช้งาน Zero ได้ในไม่ถึงนาที OAuth แม้จะดีแค่ไหนก็ใช้เวลานานกว่าและขอให้ผู้ใช้ทำมากกว่า

สองคือ OAuth ไม่ได้มีเสมอไป บางเครื่องมือองค์กรไม่มี OAuth หรือมีแต่ต้องซื้อแพ็กเกจ enterprise การให้ api-token เทียบเท่า (ไม่ใช่ทางเลือก) ทำให้เรารองรับเครื่องมือเหล่านั้นได้จริง ไม่ต้องทิ้งไว้ใน "coming soon"

Snowflake connector ที่เพิ่งส่งเมื่อวานนี้ใช้ api-token Gmail connector ที่ส่งอีเมลลูกค้าใช้ OAuth ทั้งคู่ผ่าน framework เดียวกัน ทักษะเดียวกัน รีวิวเดียวกัน ผู้เขียนเลือกแบบที่ตรงกับเครื่องมือ framework ทำให้สร้างได้ง่ายทั้งคู่

อินทิเกรชัน 180 ตัวปลดล็อกอะไร

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

เมื่อ Zero มี connector กับ CRM และ data warehouse และ กล่อง support และ เครื่องมือออกแบบ และ repo มันทำสิ่งที่ agent ตัวเดียวไม่มีทางทำได้ มัน query Snowflake, cross-reference กับ ticket Linear ที่เปิดอยู่, แล้วโพสต์สรุปใน Slack ที่ทีม customer-success อยู่ มันอ่าน Gong call, หา feature ที่ prospect ถาม, เช็คว่าอยู่ใน roadmap ไหม, แล้วร่างอีเมล follow-up ทั้งหมดในครั้งเดียว

connector ใหม่แต่ละตัวไม่ได้เพิ่มมูลค่าแบบเส้นตรง แต่มูลค่าเพิ่มแบบผสมผสาน ตัวที่ 180 มีค่ากว่าตัวแรก เพราะมันประกอบกับ 179 ตัวก่อนหน้า

นี่คือเดิมพันของ framework และเดิมพันของทักษะคือ ความเร็วในการผสมผสานขึ้นอยู่กับว่ามีกี่คนในทีมที่เพิ่มกองนี้ได้

ต่อไปคืออะไร

เรากำลังเตรียมเปิด connector-authoring skill ให้ลูกค้าใช้ ถ้าคุณใช้ Zero กับทีมและมีเครื่องมือภายในที่ต้องการอินทิเกรชัน (ระบบบิลลิ่ง, warehouse, admin panel ภายใน) เวิร์กโฟลว์เดียวกับที่ส่ง Snowflake เมื่อวานจะเป็นเวิร์กโฟลว์ที่คุณใช้ส่งของคุณ โครงสร้างเดียวกัน, auth model เดียวกัน, ไฟร์วอลล์เดียวกัน, audit trail เดียวกัน ผู้เขียนต่างกัน

ถ้าคุณสนใจ เรายินดีพูดคุย.