Skip to content
GitHub Agent Finder: ก่อนให้ Agent ใช้ Tool ต้องมีทะเบียนกลาง
GitHub เปิด Agent finder for GitHub Copilot วันที่ 17 มิถุนายน 2026
ถ้าอ่านเร็ว ๆ นี่คือฟีเจอร์ช่วยให้ Copilot หา MCP servers, skills, canvases, agents และ tools ที่เหมาะกับงานได้จาก registry
แต่ถ้ามองในมุม operator เรื่องนี้ใหญ่กว่านั้นครับ
เพราะมันชี้ว่าปัญหาของ AI Agent กำลังเปลี่ยนจาก:
agent ไม่มี tool ใช้
ไปเป็น:
agent มี tool ให้เลือกเยอะเกินไป แล้วองค์กรต้องคุมว่าอะไรใช้ได้จริง
1) เกิดอะไรขึ้น
GitHub ระบุว่า Agent finder ช่วยให้ผู้ใช้บอกงานเป็นภาษาคน จากนั้นระบบจะค้นหา index ของ AI resources ที่มีอยู่ แล้วส่งคืนตัวเลือกที่ ranked ตามความเหมาะสม
resource ที่พูดถึงรวมถึง MCP servers, skills, canvases, agents และ tools
สิ่งที่สำคัญคือ GitHub ไม่ได้วางเรื่องนี้เป็นแค่ search box สำหรับหา tool
เขาผูกเข้ากับแนวคิด registry และ governance:
- องค์กรเลือก registry ได้เอง
- ใช้ curated public catalog หรือ private registry ขององค์กรได้
- managed settings คุมว่า agent เห็นอะไรได้
- Agent finder ไม่ auto-install หรือเชื่อมต่อ resource เอง
- ฟีเจอร์นี้ implement open Agentic Resource Discovery หรือ ARD specification
พูดแบบ operator คือ GitHub กำลังบอกว่า agent discovery ต้องมี control plane ไม่ใช่ให้ agent เดินไปต่อ tool เองแบบไม่มีขอบเขต
2) ทำไมเรื่องนี้สำคัญกว่าที่เห็น
ช่วงแรกของ AI Agent หลายทีมสนใจคำถามว่า:
- จะต่อ MCP server อะไรดี
- จะให้ agent ใช้ CRM ได้ไหม
- จะให้ agent ส่ง email ได้ไหม
- จะให้ agent อ่าน database ได้ไหม
- จะให้ agent deploy หรือแก้ repo ได้ไหม
คำถามเหล่านี้ไม่ผิดครับ
แต่ถ้าข้าม governance เราจะได้ระบบที่ดูฉลาดแต่ audit ยากมาก
ตัวอย่างความเสี่ยง:
- agent เห็น tool ที่ไม่ควรเห็น
- tool อ่านข้อมูลลูกค้าได้โดยไม่มี owner
- tool บางตัวเขียนข้อมูลหรือส่งข้อความออก public channel ได้
- ไม่มีใครรู้ว่า MCP server ตัวนี้มาจากใครและอัปเดตล่าสุดเมื่อไร
- tool ที่เคยทดลองเมื่อสามเดือนก่อนยังเปิดสิทธิ์ค้างอยู่
- ไม่มี log ว่า agent เรียก tool ไหนเพื่อทำงานอะไร
พอ agent ทำงานผิด เราไม่ได้มีปัญหาแค่ prompt ผิด
เรามีปัญหาเรื่อง identity, permission, data boundary และ operational ownership
3) บทเรียน operator: Tool ต้องเข้าทะเบียนก่อนให้ Agent เห็น
สำหรับธุรกิจไทยที่เริ่มใช้ AI Agent ผมคิดว่า Agent finder ให้บทเรียนที่เอาไปใช้ได้ทันที แม้ยังไม่ได้ใช้ GitHub Copilot enterprise stack
บทเรียนคือ:
อย่าให้ agent เห็นทุก tool ที่ทีมเคยทดลอง
ให้เริ่มจากทะเบียนกลางของ capability ก่อน
ทะเบียนนี้ไม่จำเป็นต้องซับซ้อนในวันแรก อาจเป็น GitHub repo, Notion database, Airtable, Google Sheet หรือ internal portal ก็ได้
แต่ทุก tool ที่ agent จะเรียกใช้ควรมี record อย่างน้อย:
- tool นี้ทำอะไร
- ใช้กับ workflow ไหน
- อ่านข้อมูลอะไรได้
- เขียนหรือแก้ข้อมูลอะไรได้
- ใครเป็น owner
- ใคร approve ให้ใช้
- risk level คืออะไร
- มี log หรือ audit trail ไหม
- ถ้าต้องปิดใช้งาน จะปิดตรงไหน
ถ้าไม่มีคำตอบเหล่านี้ อย่าเพิ่งให้ agent ใช้ tool นั้นกับงานจริง
4) ARD คือสัญญาณว่า discovery จะเป็นมาตรฐาน
GitHub ระบุว่า Agent finder implement open Agentic Resource Discovery specification
Google Developers Blog ก็ประกาศ ARD วันที่ 17 มิถุนายน 2026 โดยวาง positioning ว่าเป็น open specification สำหรับ publishing, discovering และ verifying AI capabilities across the web
ประโยคสำคัญคือ agent ต้องตอบได้ว่า:
- capability ที่ต้องใช้ อยู่ที่ไหน
- capability ไหนควรใช้จริง
- จะ verify ได้อย่างไรว่าปลอดภัยพอจะเชื่อมต่อ
นี่คือ missing layer ของ agent ecosystem ครับ
MCP ช่วยให้ agent ต่อกับ tool ได้
แต่พอมี tool จำนวนมาก คำถามถัดมาคือ agent จะค้นหา เลือก และตรวจ tool อย่างไร
ARD และ Agent finder จึงไม่ใช่แค่เรื่อง developer convenience แต่เป็นโครงสร้างพื้นฐานของ agent governance
Operator Kit: Agent Capability Registry Gate
ก่อนอนุญาตให้ AI Agent เห็นหรือเรียกใช้ tool ใหม่ ให้กรอก gate นี้ก่อน
1) Capability record
- ชื่อ tool / MCP server / skill / agent
- source URL หรือ repo
- owner ฝั่ง business
- owner ฝั่ง technical
- version หรือ last reviewed date
2) Permission class
จัด tool เป็น 1 ใน 4 ระดับ:
- Read public: อ่านข้อมูล public หรือเอกสารทั่วไป
- Read internal: อ่านข้อมูลภายใน แต่ไม่แก้ไข
- Write internal: เขียนหรือแก้ข้อมูลในระบบภายใน
- External action: ส่ง email, โพสต์ public, จ่ายเงิน, deploy, ลบข้อมูล หรือแตะลูกค้า
ระดับ 3 และ 4 ต้องมี approval gate เสมอ
3) Data boundary
ตอบให้ชัด:
- tool เห็นข้อมูลลูกค้าหรือ PII ไหม
- tool ส่งข้อมูลออกนอกองค์กรไหม
- tool เก็บ log ที่ไหน
- model หรือ provider ภายนอกเห็น payload หรือไม่
- มีข้อมูลประเภทใดที่ห้ามส่งเข้า tool นี้เด็ดขาด
4) Approval rule
กำหนดก่อนใช้งาน:
- agent แนะนำได้เท่านั้น
- agent draft ได้ แต่คนต้องส่ง
- agent ทำได้อัตโนมัติเฉพาะงาน low-risk
- action ที่กระทบลูกค้า เงิน production หรือ public channel ต้องมี human approval
5) Observability and rollback
ทุก tool ที่ให้ agent ใช้ควรตอบได้ว่า:
- log อยู่ที่ไหน
- trace ได้ไหมว่า agent เรียก tool ด้วย input อะไร
- มี rate limit หรือ cost limit ไหม
- revoke credential ได้เร็วแค่ไหน
- ถ้า tool ทำข้อมูลผิด มี rollback path หรือไม่
6) Retirement rule
ทะเบียนที่ดีไม่ใช่แค่เพิ่ม tool ได้ครับ
ต้องลบ tool ออกได้ด้วย
ตั้ง rule ง่าย ๆ:
- ถ้าไม่ได้ใช้ 60 วัน ให้ review ใหม่
- ถ้า owner ไม่อยู่แล้ว ให้ปิดสิทธิ์ก่อน
- ถ้า source/repo ไม่ active ให้ลด risk class หรือถอดออก
- ถ้าเกิด incident ให้ quarantine tool ทันที
5) Data-Espresso จะเอาไปใช้ยังไง
สำหรับ Data-Espresso และลูกค้าที่เริ่มใช้ AI coworker/agent ผมจะไม่เริ่มจากคำถามว่า “ต่อ tool ให้ครบที่สุดได้ไหม”
ผมจะเริ่มจากคำถามว่า:
agent ควรเห็น capability ไหน ใน workflow ไหน และใครเป็นคนอนุญาต
ตัวอย่าง:
- Marketing agent เห็น campaign brief, asset library และ analytics summary ได้
- Sales agent อ่าน CRM ได้ แต่ส่ง follow-up email ต้องรอ approve
- Ops agent อ่าน ticket และสร้าง draft SOP ได้ แต่ห้ามแก้ production config
- Finance-related action ต้องเป็น recommend-only จนกว่าจะมีเจ้าของ approve
นี่คือวิธีทำให้ agent มีพลังโดยไม่กลายเป็นเงาดำในระบบ
สรุป
GitHub Agent finder เป็นฟีเจอร์เล็กถ้าอ่านจากมุม user convenience
แต่เป็นสัญญาณใหญ่ถ้าอ่านจากมุม operating system ของ AI Agent
โลก agent กำลังต้องการ layer ใหม่ระหว่าง “agent อยากทำงาน” กับ “tool พร้อมให้เรียกใช้”
layer นั้นคือ registry, managed settings, permission, verification และ approval
ธุรกิจที่เริ่มก่อน ไม่จำเป็นต้องมีระบบใหญ่ตั้งแต่วันแรก
แต่ควรเริ่มมีทะเบียนกลางตั้งแต่วันนี้
เพราะเมื่อ agent เริ่มมีสิทธิ์แตะงานจริง สิ่งที่อันตรายที่สุดไม่ใช่ tool น้อยเกินไป
แต่อาจเป็น tool ที่เปิดไว้เยอะเกินไปโดยไม่มีใครรู้ว่าใครอนุญาต