Agentic Resource Discovery คืออะไร: ค้นหาเครื่องมือเอเจนต์โดยไม่สับสนกับสิทธิ์บนมือถือ

ARD แก้ปัญหาอะไรให้เอเจนต์ AI

Agentic Resource Discovery หรือ ARD คือข้อกำหนดสำหรับการเผยแพร่ ค้นหา และตรวจสอบทรัพยากรที่เอเจนต์ AI อาจใช้ได้ เช่น tools, skills และ agents ข้ามโดเมนบนเว็บ ประกาศจาก Google Developers เมื่อวันที่ 17 มิถุนายน 2026 อธิบาย ARD ว่าเป็นข้อกำหนดเปิดสำหรับทำให้เอเจนต์รู้ว่าความสามารถใดมีอยู่ ใครเผยแพร่ และควรเชื่อมต่อผ่านช่องทางใด โดยไม่ต้องพึ่งรายชื่อส่วนตัวที่กระจัดกระจายอยู่ในแต่ละผลิตภัณฑ์

คำว่า ai-catalog.json อยู่ตรงกลางของเรื่องนี้ เพราะเป็นไฟล์แค็ตตาล็อกที่ผู้เผยแพร่ใช้บอกว่าโดเมนของตนมีทรัพยากรอะไรบ้าง แต่ละรายการอาจอธิบายชื่อ ความสามารถ endpoint ประเภทอินเทอร์เฟซ และข้อมูลสำหรับตรวจสอบผู้เผยแพร่ได้ แนวคิดสำคัญคือให้เอเจนต์เริ่มจาก metadata ที่อ่านได้และตรวจได้ ก่อนจะตัดสินใจว่าจะเชื่อมต่อกับทรัพยากรนั้นหรือไม่

ปัญหาที่ ARD แก้ไม่ใช่การทำให้เอเจนต์มีสิทธิ์ลงมือทำทุกอย่างทันที แต่คือการลดความมั่วในการค้นหา capability ถ้าไม่มีมาตรฐาน เอเจนต์อาจต้องเดา endpoint จากเอกสารมนุษย์ อ่าน marketplace ที่ไม่สม่ำเสมอ หรือพึ่ง integration แบบปิดของแต่ละแพลตฟอร์ม ARD ทำให้ขั้นตอนแรกเป็นระบบขึ้น: ใครเผยแพร่ อธิบายความสามารถไว้อย่างไร และควรส่งต่อไปยังโปรโตคอลใด

สำหรับผู้อ่านที่สนใจ phone agent จุดที่ต้องจำตั้งแต่ต้นคือ การค้นพบกับการสั่งงานเป็นคนละชั้นกัน แค็ตตาล็อกช่วยบอกว่าอาจมีทรัพยากรที่เกี่ยวข้อง แต่การแตะโทรศัพท์ ส่งข้อมูล เปลี่ยนสถานะ หรือเรียกใช้ Android action ยังต้องผ่านสิทธิ์และการอนุมัติของ runtime ฝั่งมือถือ

อ่านรายละเอียดจาก ประกาศ Agentic Resource Discovery ของ Google Developers ได้ แต่ในบทความนี้เราจะโฟกัสผลกระทบต่อความเชื่อถือของ phone agent มากกว่าการไล่ schema ทุกช่อง

แค็ตตาล็อกและรีจิสทรีเผยแพร่ความสามารถอย่างไร

เมื่อองค์กรต้องการให้เอเจนต์ค้นพบความสามารถของตน เส้นทางแรกคือการเผยแพร่แค็ตตาล็อกบนโดเมนของตัวเอง เช่น ไฟล์ ai-catalog.json ที่ประกาศว่า provider มี MCP server, A2A agent, OpenAPI tool หรือแค็ตตาล็อกย่อยใดบ้าง ข้อดีของวิธีนี้คือความสัมพันธ์ระหว่างโดเมน ผู้เผยแพร่ และ metadata เริ่มตรวจสอบได้ตั้งแต่ต้นทาง

อีกเส้นทางคือ registry หรือรีจิสทรีที่ crawl และ index แค็ตตาล็อกเหล่านั้น เพื่อให้ client ค้นหาด้วย intent ได้ เช่น “หาเครื่องมือจัดการนัดหมายที่รองรับ API แบบนี้” หรือ “หา agent สำหรับประมวลผลไฟล์ในโดเมนนี้” ตามข้อมูลใน ข้อกำหนด ARD และ repository สาธารณะ แนวทางนี้ทำให้ระบบค้นหาความสามารถได้กว้างขึ้น แต่รีจิสทรีควรถูกมองเป็นตัวช่วยค้นหา ไม่ใช่นายหน้าที่มีอำนาจอนุมัติการทำงานแทนผู้ใช้

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

การตรวจสอบผู้เผยแพร่พิสูจน์อะไร และยังไม่พิสูจน์อะไร

คำถามที่มักตามมาคือ ถ้า ARD มีการตรวจสอบผู้เผยแพร่แล้ว แปลว่า resource นั้นปลอดภัยพอให้เอเจนต์ใช้หรือไม่ คำตอบที่ใช้ได้จริงคือ การตรวจสอบช่วยยืนยันที่มาและความถูกต้องของ metadata แต่ยังไม่ใช่หลักฐานว่าทุก action ปลอดภัย เหมาะกับผู้ใช้ หรือได้รับอนุญาตในบริบทปัจจุบัน

ตามแนวทางที่ประกาศไว้ การค้นพบใน production อาจมี metadata ที่ตรวจสอบได้ทาง cryptographic เพื่อช่วยยืนยัน publisher ก่อน client เชื่อมต่อด้วย native protocol ข้อดีคือ client ไม่ต้องเชื่อแค่ข้อความอธิบายหรือผลค้นหาอย่างเดียว แต่มีหลักฐานว่าทรัพยากรประกาศมาจากผู้เผยแพร่ที่ระบุจริง และ metadata ไม่ถูกสลับระหว่างทาง

อย่างไรก็ตาม publisher identity ไม่ได้ตอบทุกคำถาม Endpoint อาจเป็นของผู้เผยแพร่จริง แต่ capability อาจไม่เหมาะกับข้อมูลของผู้ใช้รายนี้ อาจต้องใช้ scope ที่กว้างเกินงาน อาจมีผลข้างเคียงที่ควรให้มนุษย์อนุมัติ หรืออาจไม่เข้ากับสัญญาเครื่องมือของ runtime ที่กำลังใช้งานอยู่

ดังนั้นแนวคิดที่เหมาะสมคือ verify before connect ไม่ใช่ verify แล้ว execute ทันที การตรวจสอบผู้เผยแพร่เป็นจุดเริ่มต้นของ trust chain แต่ phone agent ต้องมี trust chain ฝั่งอุปกรณ์ต่ออีกชั้นหนึ่ง

ARD ส่งต่อไปยัง MCP, A2A, OpenAPI และสัญญาของแอปอย่างไร

ARD ไม่ได้พยายามแทนที่ MCP, A2A, OpenAPI หรือสัญญาเรียกใช้แอปบนมือถือ บทบาทของมันคือช่วยค้นหาและ resolve metadata แล้วบอกว่า resource นั้นควรเชื่อมต่อผ่านอินเทอร์เฟซใด จากนั้นการสื่อสารจริงต้องกลับไปอยู่กับ native protocol ที่ประกาศไว้

ตัวอย่างเช่น แค็ตตาล็อกอาจบอกว่า capability หนึ่งคือ MCP server สำหรับเครื่องมือไฟล์ อีกรายการเป็น A2A agent สำหรับงานเฉพาะโดเมน และอีกรายการเป็น OpenAPI tool สำหรับระบบองค์กร การเชื่อมต่อแต่ละแบบต้องตรวจ schema, auth, scope, rate limit, error handling และเงื่อนไขผลลัพธ์ของตัวเอง ARD ให้แผนที่ แต่ไม่ได้รวมถนนทุกสายให้กลายเป็นโปรโตคอลเดียว

บนมือถือยังมีสัญญาอีกประเภทหนึ่งคือ app contract หรือความสามารถที่แอปเปิดให้เครื่องเรียกใช้ได้ หากคุณต้องการลงลึกเรื่องการที่แอปมือถือประกาศ action ที่เรียกได้โดยระบบหรือเอเจนต์ บทความ App Intents แอปที่เครื่องเรียกใช้ได้ และ AI agents บนมือถือ จะอธิบายชั้น callable app โดยไม่ทำให้บทความ ARD นี้ยาวเกินจำเป็น

ผลลัพธ์ของการ handoff จึงควรเป็นการเชื่อมต่อที่ตรวจเงื่อนไขครบ ไม่ใช่การกระโดดจาก catalog entry ไปสู่ action จริงทันที ถ้า endpoint ไม่เข้ากับ tool contract ของ runtime หรือ mobile app ไม่เปิดสัญญาเรียกใช้ที่ชัดเจน เอเจนต์ควรหยุด ถามเพิ่ม หรือเลือกเส้นทางที่ปลอดภัยกว่า

ทำไมการค้นพบจึงไม่ใช่การอนุญาตบนโทรศัพท์

บนโทรศัพท์ การค้นพบทรัพยากรตอบคำถามว่า “มีอะไรให้เชื่อมต่อได้บ้าง” ส่วนการอนุญาตตอบคำถามว่า “ผู้ใช้และอุปกรณ์นี้ยอมให้ทำ action นี้กับเป้าหมายนี้หรือไม่” สองคำถามนี้อยู่คนละชั้นและไม่ควรถูกรวมกัน เพราะผลลัพธ์ของ phone action มักแตะข้อมูลจริง เช่น ข้อความ อีเมล ตำแหน่ง ปฏิทิน การตั้งค่า และแอปที่ผู้ใช้ใช้อยู่ทุกวัน

แนวทาง Android ระบุว่าควรขอ runtime permissions ในบริบทเมื่อ feature ต้องใช้สิทธิ์นั้น และการจัดการกรณีผู้ใช้ปฏิเสธสิทธิ์ยังเป็นความรับผิดชอบของแอป ข้อมูลจาก แนวทางการขอสิทธิ์ runtime ของ Android ช่วยย้ำว่า permission เป็นเรื่องของอุปกรณ์และผู้ใช้ ไม่ใช่สิ่งที่ metadata ภายนอกมอบให้ได้

ถ้าต้องการลงลึกเรื่องการตรวจสิทธิ์ของสกิลโดยเฉพาะ อ่านต่อได้ที่ ความปลอดภัยของสกิล AI agent: ทำไม phone agent ต้องตรวจสิทธิ์ขณะทำงาน ส่วนภาพรวมตัวตน สิทธิ์ และบันทึกกิจกรรมที่กว้างกว่าอยู่ใน ตัวตน สิทธิ์ และบันทึกตรวจสอบของ AI Agent: ชั้นความปลอดภัยที่มือถือ Agent ต้องมี บทความนี้ใช้สองชั้นนั้นเพื่ออธิบายจุดตัดกับ ARD เท่านั้น

เช็กลิสต์ก่อนเชื่อมต่อและก่อนสั่งงานทรัพยากรที่ค้นพบ

เมื่อ phone agent พบ resource จากแค็ตตาล็อกหรือรีจิสทรี ขั้นตอนที่ดีไม่ควรเริ่มจาก action ที่มีผลจริงทันที ให้แยก pre-connect ออกจาก pre-execution เพื่อให้เห็นว่าความเสี่ยงเกิดตรงไหนและหยุดได้ตรงจุด

1. ตรวจผู้เผยแพร่: โดเมน metadata และหลักฐานการตรวจสอบต้องตรงกับแหล่งที่คาดไว้
2. ตรวจความสดของแค็ตตาล็อก: เวอร์ชัน วันที่ และ schema ต้องสอดคล้องกับสิ่งที่ runtime รองรับ
3. ตรวจอินเทอร์เฟซ: resource ประกาศ MCP, A2A, OpenAPI หรือสัญญาแอปแบบใด และ endpoint ตอบตามสัญญาหรือไม่
4. ตรวจ scope และข้อมูลที่ต้องใช้: ถ้า scope กว้างเกินงาน ให้ลดขอบเขตหรือหยุดก่อนเชื่อมต่อ
5. เริ่มจากงานความเสี่ยงต่ำ: อ่าน metadata หรือทดสอบ action ที่ไม่มีผลภายนอกก่อน
6. ตรวจสถานะเปิดใช้เครื่องมือ: resource ที่ค้นพบต้องไม่ถูกถือว่า enabled โดยอัตโนมัติ
7. ตรวจเป้าหมาย action: ผู้รับ บัญชี ไฟล์ ตำแหน่ง หรือแอปปลายทางต้องมองเห็นและแก้ไขได้
8. ใช้การอนุมัติตามความเสี่ยง: งานอ่านทั่วไปอาจใช้ policy หนึ่ง งานส่งข้อมูลหรือเปลี่ยนสถานะต้องใช้ policy ที่เข้มกว่า
9. บันทึกผลลัพธ์และ error: runtime ควรบอกได้ว่าเรียก tool ใด ได้ผลอะไร และล้มเหลวตรงไหน
10. เตรียมการเพิกถอน: ผู้ใช้ต้องปิด tool ถอนสิทธิ์ หรือหยุด plugin ได้โดยไม่ต้องรื้อระบบทั้งหมด

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

FoneClaw แยกการมองเห็นในแค็ตตาล็อกออกจากอำนาจบนโทรศัพท์อย่างไร

ในมุมของ FoneClaw ประเด็น ARD มีประโยชน์เพราะทำให้ทุกคนพูดชัดขึ้นว่า “มองเห็นความสามารถ” ไม่เท่ากับ “ได้รับอำนาจให้ใช้ความสามารถนั้น” FoneClaw เป็น Android phone-agent runtime ที่ให้โมเดลที่ผู้ใช้กำหนดเข้ามาช่วยทำความเข้าใจ เหตุผล และวางแผน ส่วนการลงมือทำเกิดผ่านเครื่องมือ Android ที่รองรับและมี governance ของ runtime

ข้อมูล release ของ FoneClaw วันที่ 1 สิงหาคม 2026 ระบุว่าเวอร์ชัน 0.1.0 เพิ่มการจัดการรายเครื่องมือ การควบคุมการอนุมัติ การกู้คืน permission และสัญญาเครื่องมือที่ปลอดภัยขึ้น พร้อมเส้นทาง plugin ที่ต้องเริ่มจาก proposal ที่มองเห็นได้และ package ที่เชื่อถือได้ผ่านกระบวนการที่กำหนดไว้ ขณะเดียวกัน ข้อมูล release สาธารณะของ FoneClaw และ แค็ตตาล็อกเครื่องมือสาธารณะของ FoneClaw แสดงแนวคิดเรื่อง risk และ approval labels ในเครื่องมือ built-in จำนวนมาก โดยใน copy ที่ต้องทนต่อเวลา เราใช้คำว่า 100+ built-in tools แทนการทำให้ตัวเลข snapshot กลายเป็นคำสัญญาถาวร

ลำดับการทำงานที่ถูกต้องคือ โมเดลวางแผนภายใน FoneClaw จากนั้น FoneClaw เลือกเครื่องมือที่เปิดใช้อยู่ ตรวจ policy ขอ permission เมื่อจำเป็น แสดงผลลัพธ์ และหยุดตามจุดอนุมัติที่เหมาะกับความเสี่ยง นี่ไม่ใช่การอ้างว่า FoneClaw ใช้ ARD หรือเข้าร่วม registry ใด แต่เป็นตัวอย่างของ runtime ที่แยก catalog visibility ออกจาก phone authority อย่างชัดเจน

หากต้องการภาพรวม intent-to-action บน Android ที่กว้างกว่า บทความ ควบคุมโทรศัพท์ด้วย AI Agent: วิธีคิดใหม่ของ phone AI agent บน Android อธิบายว่าคำสั่งของผู้ใช้ถูกเปลี่ยนเป็น action ที่รองรับอย่างไร โดยไม่ต้องซ้ำรายละเอียด ARD ในหน้านี้

ทีมควรทดสอบอะไรก่อนใช้รีจิสทรีทรัพยากรเอเจนต์

ทีมที่กำลังพิจารณา ARD หรือ agent resource registry ควรเริ่มจากการวัด ไม่ใช่ความตื่นเต้นจากมาตรฐานใหม่ คำถามแรกคือ registry ค้นเจอ resource ที่เกี่ยวข้องจริงหรือไม่ และคืนผลลัพธ์ผิดมากน้อยแค่ไหน คำถามที่สองคือแค็ตตาล็อกเก่าหรือเปลี่ยนโดยไม่ทันรู้หรือไม่ คำถามที่สามคือเมื่อ verification ล้มเหลว runtime หยุดอย่างชัดเจนหรือยังพยายามเชื่อมต่อเอง

เกณฑ์สุดท้ายสำหรับ phone agent คือ discovery และ authority ต้องสังเกตแยกกันได้ คุณควรรู้ว่า resource ถูกพบจากไหน เชื่อมต่อด้วยโปรโตคอลใด เครื่องมือใดถูกเปิดใช้ สิทธิ์ Android ใดถูกขอ action ใดได้รับอนุมัติ และผลลัพธ์สุดท้ายคืออะไร เมื่อบันทึกเหล่านี้แยกกันชัด ARD จะเป็นชั้น discovery ที่มีประโยชน์ โดยไม่กลายเป็นทางลัดที่ทำให้สิทธิ์บนมือถือพร่าเลือน