Google เปิดสเปก ARD: มาตรฐานเปิดให้ Agent ค้นหาและยืนยัน Tool/Skill/Agent ข้ามองค์กรได้

ถ้า A2A คือ “วิธีที่ Agent คุยกัน” และ MCP คือ “วิธีที่ Agent เข้าถึงเครื่องมือ” คำถามที่ยังไม่มีใครตอบให้ชัดคือ — แล้ว Agent จะ หา เครื่องมือ สกิล หรือ Agent ตัวอื่นเจอได้อย่างไรตั้งแต่แรก? วันที่ 17 มิถุนายน 2026 Google for Developers ประกาศ Agentic Resource Discovery (ARD) สเปกเปิดที่พัฒนาร่วมกับพาร์ตเนอร์หลายเจ้าในอุตสาหกรรม เพื่ออุดช่องว่างนี้โดยเฉพาะ

ในโลกที่ Agent พึ่งพา tool, skill และ agent ที่กระจายอยู่คนละทีม คนละองค์กร คนละแพลตฟอร์ม ARD ตั้งใจตอบสามคำถามหลักให้เป็นมาตรฐานเดียว: ความสามารถที่ต้องการอยู่ที่ไหน, ควรเลือกใช้ตัวไหน, และจะยืนยันได้อย่างไรว่าปลอดภัย — ทั้งหมดนี้ทำงานแบบ dynamic ตอน runtime ไม่ใช่ hard-code ไว้ล่วงหน้า

สององค์ประกอบหลัก: Catalog กับ Registry

ARD ออกแบบบนสองพื้นฐานง่าย ๆ แต่ทรงพลัง:

• Catalog — องค์กรเผยแพร่ไฟล์ ai-catalog.json ไว้บนโดเมนของตัวเอง อธิบายว่ามีความสามารถอะไรให้ใช้บ้าง (MCP server, API, agent ฯลฯ) จุดสำคัญคือ การเป็นเจ้าของโดเมนเองคือรากฐานของการยืนยันตัวตน — ใครเผยแพร่ catalog บนโดเมนไหน ก็พิสูจน์ได้ด้วย cryptographic ว่าเป็นเจ้าของจริง คล้ายกับแนวคิด robots.txt หรือ .well-known ของเว็บยุคเดิม แต่สำหรับ Agent

• Registry — ทำหน้าที่เหมือน “search engine ของความสามารถ Agent” คอย crawl และ index catalog ที่เผยแพร่ทั่วเว็บ แล้วเปิดให้ Agent ค้นหาด้วยภาษาธรรมชาติ (“หา tool ที่แปลงไฟล์ PDF เป็นข้อมูล structured”) หรือ fetch ตรงจากโดเมนที่รู้อยู่แล้วก็ได้

Flow การทำงานจึงเป็น: เผยแพร่ → ค้นหา/resolve → ยืนยันตัวตนผู้เผยแพร่ด้วย cryptographic → เชื่อมต่อตรงตอน runtime ผ่าน native protocol เดิม (เช่น MCP หรือ A2A) โดย ARD ไม่ได้มาแทนที่ protocol เหล่านั้น แต่มาเป็น ชั้นค้นหา ที่อยู่ก่อนหน้า

ทำไมเรื่อง “ค้นหา” ถึงสำคัญกว่าที่คิด

ปัญหานี้ฟังดูเล็ก แต่จริง ๆ เป็นคอขวดของ multi-agent system ในระดับ production วันนี้นักพัฒนาส่วนใหญ่ยังต้อง hard-code endpoint ของ MCP server หรือ agent ปลายทางลงไปตรง ๆ ซึ่งใช้ได้ภายในทีมเดียว แต่พังทันทีเมื่อต้องการให้ Agent ทำงานข้ามองค์กร — ไม่มีทางรู้ว่าใครมีเครื่องมืออะไร เวอร์ชันไหน หรือเชื่อถือได้แค่ไหน

ARD เปลี่ยนจาก “รู้จักกันมาก่อน” เป็น “ค้นเจอและยืนยันได้เอง” ซึ่งเป็นเงื่อนไขจำเป็นถ้าเราอยากเห็น agentic web จริง ๆ ที่ Agent จากคนละเจ้าทำงานร่วมกันได้โดยไม่ต้องเซ็น integration กันทีละคู่

ใครอยู่เบื้องหลัง และเริ่มใช้ได้อย่างไร

ARD พัฒนาแบบ collaborative ข้ามอุตสาหกรรมพร้อม launch partner หลายราย ตัวสเปกเปิดภายใต้ license Apache 2.0 อ่านได้ที่ agenticresourcediscovery.org และ repo อยู่ที่ github.com/ards-project/ard-spec ฝั่ง Google เองให้ทางเลือกระดับองค์กรผ่าน Agent Registry ใน Gemini Enterprise Agent Platform สำหรับทีมที่อยากได้ implementation พร้อมใช้

มุมมอง AI Curator

ARD คือชิ้นส่วนที่หายไปของ stack agent ที่หลายคนมองข้าม ปีที่ผ่านมาวงการโฟกัสกับ “Agent คุยกันยังไง” (A2A) และ “Agent ใช้เครื่องมือยังไง” (MCP) จน discovery กลายเป็นเรื่องที่ทุกคนแก้เองแบบ ad-hoc การที่ Google วางมันเป็นสเปกเปิด Apache 2.0 ตั้งแต่วันแรก — ไม่ใช่ผูกกับ Gemini — เป็นสัญญาณว่าพวกเขาเรียนรู้จาก MCP ว่ามาตรฐานเปิดที่เป็นกลางคือสิ่งที่ทำให้ ecosystem โต ไม่ใช่ proprietary lock-in

แต่ความท้าทายจริงไม่ใช่เรื่องเทคนิค มันคือเรื่อง trust และ governance: registry กลางจะกลายเป็นจุดรวมอำนาจไหม, ใครกำหนดว่า catalog ไหน “ปลอดภัย”, และจะกัน spam/poisoning ของ catalog ปลอมอย่างไร — เพราะ Agent ที่ค้นเจอ tool อันตรายแล้วเรียกใช้อัตโนมัติคือ attack surface ใหม่ทั้งก้อน การยึดการยืนยันตัวตนไว้กับ “การเป็นเจ้าของโดเมน” เป็นจุดเริ่มที่ฉลาด เพราะใช้รากฐาน trust ของเว็บที่มีอยู่แล้ว

สำหรับ developer ไทยและ SEA ที่กำลังสร้าง agent platform หรือ marketplace ของ tool/skill ในประเทศ ARD เป็นมาตรฐานที่ควรจับตาตั้งแต่ตอนนี้ ถ้าระบบของคุณ “ค้นหาได้” ตามสเปกกลาง โอกาสที่ tool ของผู้ให้บริการไทยจะถูก agent ทั่วโลกค้นเจอและเรียกใช้ก็เปิดกว้างขึ้น — แทนที่จะถูกขังอยู่ใน ecosystem ปิดของเจ้าใหญ่

แหล่งข่าว

• Announcing the Agentic Resource Discovery specification — Google for Developers Blog
• ARD Specification — agenticresourcediscovery.org
• ard-spec on GitHub