The internet runs on open protocols and open source. So will agentic AI.
ประโยคนี้อยู่บนหน้าแรกของ Agentic AI Foundation (AAIF) ขณะตรวจข้อมูลเมื่อ 25 ตุลาคม 2569 ใจความคือ อินเทอร์เน็ตทำงานอยู่บนโปรโตคอลเปิดและโอเพนซอร์ส และ AAIF เชื่อว่า agentic AI จะเดินไปในทางเดียวกัน
ในบทความชุดนี้ agent หมายถึงแอปพลิเคชัน AI ที่เลือกขั้นตอนและใช้เครื่องมือทำงานตามเป้าหมายที่ได้รับมอบหมาย ภายในขอบเขตสิทธิที่กำหนดให้
ครึ่งหลังของประโยคเป็นวิสัยทัศน์ที่ต้องพิสูจน์ต่อ เรายังสรุปไม่ได้ว่า AI ทุกค่ายจะเปิดเท่ากัน หรือเชื่อมต่อกันได้โดยไม่ต้องปรับอะไร แต่ประโยคนี้ตั้งคำถามที่ดีสำหรับคนซื้อระบบธุรกิจ: ถ้าเปลี่ยนเครื่องมือ AI ในปีหน้า งานที่บริษัทลงทุนทำไว้วันนี้จะย้ายตามไปได้แค่ไหน
ลองสมมติว่าบริษัทขายอุปกรณ์โรงงานต้องการให้ AI ช่วยตอบลูกค้าว่า สินค้าที่สั่งมีของพร้อมส่งหรือไม่ งานดูสั้นเพียงประโยคเดียว แต่เบื้องหลังต้องอ่านใบสั่งซื้อ ตรวจรหัสสินค้า ดูยอดจองใน ERP และทำตามกติกาของฝ่ายขาย บางส่วนเป็นข้อมูล บางส่วนเป็นการเชื่อมระบบ บางส่วนเป็นความรู้ของคนในบริษัท การที่ผู้ขายติดป้ายว่า “open” ยังไม่ตอบว่าส่วนไหนย้ายได้
ตอนแรกของบทความชุดนี้จึงเริ่มจากอินเทอร์เน็ต เว็บ และ Linux เพื่อแยกสิ่งเหล่านี้ให้ชัด ก่อนที่ตอนถัดไปจะลงไปดูการเชื่อม AI กับ ERP และคู่มือทำงานของ agent
อินเทอร์เน็ตทำให้เครื่องต่างชนิดตกลงวิธีสื่อสารกัน
วันที่ 1 มกราคม 1983 เครือข่าย ARPANET เปลี่ยนมาใช้ TCP/IP เป็นเหตุการณ์สำคัญช่วงหนึ่งของการพัฒนาอินเทอร์เน็ต ตามประวัติที่ Internet Society บันทึกไว้ ประเด็นที่ควรจำสำหรับบทความนี้คือ เครื่องและเครือข่ายที่ต่างกันใช้ข้อตกลงร่วมกันในการสื่อสารได้ โดยไม่ต้องเป็นผลิตภัณฑ์ชุดเดียวกันทั้งหมด
โปรโตคอลคือข้อตกลงว่าฝ่ายที่สื่อสารกันต้องส่ง รับ และตีความข้อความอย่างไร เหมือนบริษัทสองแห่งตกลงกันว่าใบสั่งซื้อต้องมีเลขเอกสาร รหัสสินค้า จำนวน และวิธีแจ้งข้อผิดพลาด แต่รายละเอียดจริงของโปรโตคอลย่อมลึกกว่าตัวอย่างเอกสารนี้มาก
ส่วนโปรแกรมที่ทำตามข้อตกลงนั้นคือ implementation หรือซอฟต์แวร์ที่นำข้อกำหนดไปใช้ ผู้พัฒนาสองรายอาจเขียนโปรแกรมต่างกัน ใช้ภาษาต่างกัน และขายบริการต่างรูปแบบกันได้ ถ้าทำตามข้อกำหนดที่ใช้ร่วมกัน ทั้งสองฝั่งก็มีพื้นฐานให้สื่อสารกันได้ การทดสอบยังจำเป็น เพราะการอ้างว่ารองรับข้อกำหนดเดียวกันไม่ได้ยืนยันว่าทำครบทุกส่วนหรือรองรับรุ่นเดียวกัน
อีกเรื่องที่ต้องดูคือ ใครดูแลกติกาและเปิดให้คนอื่นร่วมแก้ไขได้เพียงใด IETF อธิบายกระบวนการของตน ว่าผู้สนใจเข้าร่วมได้ เอกสารและการหารือเปิดเผย และใช้ประสบการณ์จากซอฟต์แวร์ที่นำไปใช้งานจริงประกอบการหาข้อตกลง IETF พัฒนามาตรฐานที่คนเลือกนำไปใช้ ไม่ได้เป็นเจ้าของหรือผู้ควบคุมอินเทอร์เน็ตทั้งหมด
สำหรับธุรกิจ นี่คือเหตุผลที่ควรถามมากกว่าว่า “มีเอกสาร API ไหม” ต้องถามต่อว่าใครเปลี่ยนข้อกำหนดได้ เมื่อเปลี่ยนแล้วแจ้งอย่างไร และบริษัทอื่นนำไปสร้างระบบที่เชื่อมกันได้จริงหรือไม่
เว็บเพิ่มวิธีเข้าถึงข้อมูลบนเครือข่าย
อินเทอร์เน็ตกับเว็บไม่ใช่สิ่งเดียวกัน เว็บเป็นระบบหนึ่งที่ทำงานบนอินเทอร์เน็ต Tim Berners-Lee คิดค้น World Wide Web ที่ CERN ในปี 1989 และวันที่ 30 เมษายน 1993 CERN นำซอฟต์แวร์ World Wide Web ออกสู่สาธารณสมบัติ ต่อมาจึงเผยแพร่รุ่นที่ใช้สัญญาอนุญาตแบบเปิด ตามประวัติของ CERN
เรื่องนี้มีสองส่วนที่มักถูกเล่ารวมกัน ส่วนแรกคือกติกาที่ทำให้ระบบสื่อสารกัน ส่วนที่สองคือสิทธิในการนำซอฟต์แวร์ไปใช้และพัฒนาต่อ ทั้งสองส่วนช่วยกันได้ แต่ทำหน้าที่แทนกันไม่ได้
ยกตัวอย่าง HTTP ซึ่งมีข้อกำหนดความหมายของคำขอ การตอบกลับ และรหัสสถานะอยู่ใน RFC 9110 ข้อกำหนดนี้เป็นเอกสารอธิบายพฤติกรรม ไม่ใช่โปรแกรมเว็บเซิร์ฟเวอร์สำเร็จรูป เมื่อบริษัทเปลี่ยนเว็บเซิร์ฟเวอร์ จึงมีโอกาสใช้เบราว์เซอร์เดิมเข้าถึงเว็บไซต์ได้ต่อ หากระบบยังทำตามข้อตกลงที่เกี่ยวข้อง
แต่ HTTP ไม่ได้รู้ว่า “สินค้าพร้อมส่ง” ของบริษัทหมายถึงอะไร มีของอยู่ในคลังอย่างเดียวพอหรือไม่ ต้องหักยอดจองก่อนหรือยัง ต้องเช็กวงเงินลูกค้าด้วยหรือเปล่า โปรโตคอลช่วยให้ส่งคำถามและรับคำตอบได้ ส่วนความหมายทางธุรกิจยังต้องมีคนกำหนด
นี่เป็นเส้นแบ่งที่สำคัญเมื่อเริ่มให้ AI ทำงานกับระบบจริง การส่งข้อมูลสำเร็จ กับการตีความข้อมูลถูกต้อง เป็นคนละเรื่องที่ต้องตรวจ
Linux เป็นตัวอย่างของสิทธิในการพัฒนาโปรแกรมต่อ
Linux อยู่ในอีกชั้นหนึ่งของเรื่อง มันเป็นเคอร์เนล หรือแกนของระบบปฏิบัติการที่จัดการทรัพยากรเครื่อง ไม่ใช่โปรโตคอลที่กำหนดวิธีคุยกันบนเครือข่าย และไม่ควรเล่าย้อนว่าอินเทอร์เน็ตเกิดจาก Linux เอกสารของ GNU ระบุว่า Linux เริ่มในปี 1991 และเปลี่ยนมาเป็นซอฟต์แวร์เสรีในปี 1992 ซึ่งช้ากว่าจุดเปลี่ยน TCP/IP ข้างต้นหลายปี (GNU/Linux FAQ)
เอกสารโครงการระบุว่า Linux kernel เผยแพร่ภายใต้ GNU GPL version 2 พร้อมข้อยกเว้นที่ระบุไว้ ส่วนระบบปฏิบัติการที่เราเรียกรวม ๆ ว่า Linux ยังมีโปรแกรมอื่นประกอบอยู่ด้วยและต้องดูสัญญาอนุญาตของแต่ละส่วน (Linux kernel licensing rules)
คำว่าโอเพนซอร์สจึงต้องดูสิทธิที่ให้มาด้วย ตาม Open Source Definition ของ OSI การเปิดให้ดูซอร์สโค้ดอย่างเดียวยังไม่พอ เงื่อนไขต้องครอบคลุมเรื่องการแจกจ่าย การแก้ไข และงานที่พัฒนาต่อ รวมถึงเกณฑ์อื่นในนิยามนั้นด้วย
ในมุมคนซื้อซอฟต์แวร์ ข้อดีที่อาจได้คือมีทางตรวจโค้ด แก้ไข หรือหาผู้ดูแลรายอื่นภายใต้เงื่อนไขของสัญญาอนุญาต แต่สิทธินั้นไม่ได้ทำให้งานดูแลหายไป บริษัทต้องมีคนเข้าใจระบบ มีวิธีอัปเดต และมีผู้รับผิดชอบเมื่อเกิดปัญหา การเปิดซอร์สยังไม่ได้แปลว่าข้อมูลของบริษัทเปิดเผยต่อสาธารณะ ข้อมูลลูกค้าและข้อมูลการค้าเป็นอีกเรื่องหนึ่งที่ต้องกำหนดสิทธิแยก
ดังนั้น คำว่าเปิดในโลกซอฟต์แวร์มีหลายมิติ บางระบบเปิดโปรโตคอลแต่ไม่ได้เปิดซอร์สทุกส่วน บางระบบเปิดซอร์สแต่ยังส่งออกข้อมูลได้ยาก การเลือกซื้อควรดูมิติที่เกี่ยวกับงานของบริษัทจริง ๆ
แยกชั้นก่อนอ่านคำว่า open บนข้อเสนอ AI
เราใช้คำว่า “มาตรฐาน” เรียกข้อกำหนดที่ใช้เป็นหลักร่วมกัน ส่วน “โปรโตคอล” เจาะจงกติกาการสื่อสาร มาตรฐานจึงอาจกำหนดเรื่องอื่นได้ เช่น รูปแบบไฟล์ ไม่จำเป็นต้องเป็นโปรโตคอลเสมอไป เอกสารที่ผู้ขายเผยแพร่เองไม่ได้มีความน่าเชื่อถือเท่ากันเพียงเพราะใช้คำว่ามาตรฐาน ต้องดูผู้ดูแล กระบวนการเปลี่ยนแปลง และหลักฐานการใช้ร่วมกันด้วย
ก่อนอ่านตาราง ควรรู้จัก API ด้วย API (Application Programming Interface) คือช่องทางและข้อตกลงที่โปรแกรมเปิดให้โปรแกรมอื่นเรียกใช้ข้อมูลหรือความสามารถ API หนึ่งอาจใช้ HTTP เป็นโปรโตคอลส่งข้อความ และกำหนดชื่อคำสั่งกับช่องข้อมูลเฉพาะของตนเอง คำว่า “มี API” จึงยังไม่ยืนยันว่าเครื่องมืออีกค่ายจะใช้แทนกันได้
ตารางนี้ใช้ช่วยอ่านข้อเสนอ แต่ละระบบอาจจัดองค์ประกอบต่างจากนี้
| สิ่งที่กำลังดู |
ตอบคำถามอะไร |
ยังไม่ตอบเรื่องใด |
| โปรโตคอล เช่น HTTP หรือ MCP |
ระบบคุยกันด้วยรูปแบบและพฤติกรรมแบบใด |
ผลลัพธ์ทางธุรกิจถูกต้องหรือไม่ |
| รูปแบบที่เผยแพร่ เช่น Agent Skills |
จัดชุดคำแนะนำและไฟล์ประกอบอย่างไร |
AI แต่ละตัวทำตามได้ดีเท่ากันหรือไม่ |
| ซอฟต์แวร์และสัญญาอนุญาต |
โปรแกรมทำงานอย่างไร และเรามีสิทธิใช้ แก้ไข หรือแจกจ่ายเพียงใด |
ใครดูแลระบบให้บริษัท และคิดค่าใช้จ่ายอย่างไร |
| ข้อมูลและกติกางานของบริษัท |
ใช้ข้อมูลใด ตีความอย่างไร และใครมีสิทธิทำอะไร |
จะย้ายไปเครื่องมือใหม่ได้ครบแค่ไหนโดยไม่ทดสอบ |
ในโลก agent ข้อกำหนด Model Context Protocol (MCP) รุ่น 2026-07-28 วางกติกาเชื่อมแอปพลิเคชัน AI กับข้อมูลและเครื่องมือภายนอก ส่วน Agent Skills กำหนดรูปแบบชุดคำแนะนำที่มีไฟล์ SKILL.md และอาจมีสคริปต์หรือเอกสารประกอบ ทั้งสองอย่างเกี่ยวข้องกันได้ แต่ตอบคนละคำถาม
เมื่อ 22 ตุลาคม 2569 Anthropic ประกาศมอบ Agent Skills ให้ AAIF ส่วนการย้ายวิธีทำงานของบริษัทแล้วได้ผลเท่าเดิมยังต้องพิสูจน์กับเครื่องมือและงานจริง เราเล่ารายละเอียดข่าวนั้นไว้ในบทความ Agent Skills ในตอนนี้ ประเด็นที่ต้องแยกคือข้อกำหนดการเชื่อมต่อ รูปแบบคำแนะนำ และตัวโปรแกรม
กลับมาที่คำถามว่า “ของพร้อมส่งหรือไม่”
ในบริษัทสมมติของเรา ERP อาจบันทึกสินค้าคงเหลือ 50 ชิ้น และมียอดจอง 40 ชิ้น หากลูกค้าขอ 20 ชิ้น AI ที่อ่านเฉพาะยอดคงเหลืออาจตอบว่าพอขาย ทั้งที่จำนวนซึ่งยังไม่ถูกจองเหลือเพียง 10 ชิ้น ตัวเลขนี้เป็นตัวอย่างเพื่ออธิบายปัญหา ไม่ใช่ผลจากระบบหรือลูกค้าจริง
สมมติจุดเชื่อมต่อส่งข้อมูลถูกทุกช่อง ปัญหาก็ยังเกิดได้ถ้าไม่มีใครบอก AI ว่าต้องหักยอดจอง คำว่า “รองรับโปรโตคอลเปิด” จึงยังรับรองคำตอบนี้ไม่ได้ บริษัทต้องกำหนดความหมายของยอดพร้อมขาย แหล่งข้อมูลที่ใช้ และวิธีจัดการคำขอที่เกินจำนวน ส่วนอำนาจอนุมัติขายเกินยอดต้องตกลงต่างหาก
หากทีมจะเปลี่ยน AI ค่ายใหม่ สิ่งที่อยากเก็บไว้คือข้อมูล ERP และความหมายของแต่ละช่อง จุดเชื่อมต่อที่ทีมตรวจสอบได้ และกติกาตอบลูกค้าที่มีคนดูแล การเก็บแต่ประวัติแชตอาจไม่พอให้เครื่องมือใหม่เข้าใจว่าเหตุใดคำตอบหนึ่งจึงผ่านการอนุมัติ
วิธีทดสอบที่ตรงไปตรงมาคือใช้ข้อมูลจำลองและคำขอเดียวกันกับเครื่องมือทั้งสอง ให้แสดงว่าดึงข้อมูลใด คำนวณยอดอย่างไร และจะส่งเรื่องให้ใครเมื่อของไม่พอ อย่าเพิ่งให้สิทธิจองหรือแก้ข้อมูลจริง การทดลองนี้จะทำให้เห็นว่าส่วนใดย้ายได้แล้ว ส่วนใดต้องปรับ และส่วนใดเป็นกติกาที่ทีมยังไม่เคยเขียนให้ชัด
นี่เป็นข้อเสนอวิธีประเมินของบทความ ไม่ใช่ข้อรับประกันว่ามาตรฐานใดจะลดค่าใช้จ่ายได้เท่าไร
คำถามที่นำเข้าประชุมกับผู้ขายได้
แทนที่จะขอคำตอบรวมว่า “ระบบเปิดหรือไม่” ให้เลือกงานหนึ่งงาน เช่น การตอบยอดพร้อมส่ง แล้วถามเป็นเรื่องที่ตรวจหลักฐานได้
- ระบบรองรับข้อกำหนดชื่ออะไร รุ่นใด และส่วนใดบ้าง มีตัวอย่างเชื่อมกับเครื่องมืออีกค่ายให้ดูหรือไม่
- ถ้าสัญญาสิ้นสุด บริษัทส่งออกข้อมูล คำแนะนำ ไฟล์อ้างอิง และค่าตั้งที่จำเป็นได้ในรูปแบบใด มีข้อจำกัดอะไร
- จุดเชื่อมต่อกับ ERP ใช้บัญชีของใคร ใครเปลี่ยนสิทธิได้ และใครรับงานเมื่อข้อกำหนดหรือ ERP เปลี่ยนรุ่น
- ให้ทดลองเปลี่ยนเครื่องมือ AI โดยใช้ข้อมูลจำลองและเกณฑ์ตรวจเดิมได้หรือไม่ ต้องสร้างส่วนใดใหม่
- ถ้าผู้ดูแลมาตรฐานหรือผู้ขายเปลี่ยนทิศทาง บริษัทมีทางเลือกใด และมีใครดูแลทางเลือกนั้นได้จริง
คำตอบอาจทำให้เรายอมรับระบบที่มีบางส่วนเป็นกรรมสิทธิ์ เพราะบริการและความรับผิดชอบเหมาะกับงาน หรือเลือกโอเพนซอร์สเพราะต้องแก้ไขเอง ทั้งสองทางมีเหตุผลได้ สิ่งที่ควรได้จากการประชุมคือรู้ว่าเรากำลังพึ่งพาใคร เรื่องอะไร และมีหลักฐานใดรองรับคำว่า “ย้ายได้”
บทเรียนจากอินเทอร์เน็ต เว็บ และ Linux ที่นำมาใช้กับ AI ได้วันนี้ จึงอยู่ที่การแยกข้อตกลงร่วมออกจากโปรแกรม และแยกสิทธิใช้โปรแกรมออกจากความรู้งานของบริษัท เมื่อแยกได้ เราจะถามเรื่องการเชื่อมต่อและการย้ายระบบได้ตรงจุดขึ้น โดยไม่ต้องเชื่ออนาคตทั้งหมดตามประโยคเปิด
ตอนถัดไป จะตามคำถาม “ของพร้อมส่งหรือไม่” เข้าไปใน ERP ดูว่า API, tools และ MCP ช่วยกันอย่างไร แล้วตรงไหนยังต้องมีคนกำหนดสิทธิและตรวจผล ตอนที่ 3 จะดู Agent Skills กับการเก็บวิธีทำงานของบริษัท ส่วนตอนที่ 4 จะกลับมาที่การส่งงานระหว่าง agent การควบคุม และการตัดสินใจเริ่มใช้
ข้อมูลและข้อกำหนดตรวจเมื่อ 25 ตุลาคม 2569
