การเชื่อมต่อแหล่งข้อมูลของเอเจนต์ AI กับบริบทเชิงพื้นที่ในโลกจริงโดยใช้ MCP ของ Grounding Lite ใน Maps

การสร้าง AI Agent ถือเป็นวิวัฒนาการที่สำคัญในการพัฒนาซอฟต์แวร์ ซึ่งช่วยให้ระบบสามารถให้เหตุผลที่ซับซ้อนและทำงานได้อย่างเป็นอิสระมากขึ้น อย่างไรก็ตาม โมเดลพื้นฐานที่ขับเคลื่อนระบบเหล่านี้ถูกจำกัดโดยธรรมชาติด้วยข้อมูลฝึกฝน หากไม่มีบริบทภายนอก โมเดลจะไม่ทราบถึงสภาพการณ์แบบเรียลไทม์ เช่น สภาพอากาศภายนอกในปัจจุบัน ธุรกิจในท้องถิ่นเปิดอยู่ขณะนี้หรือไม่ หรือเส้นทางที่มีประสิทธิภาพที่สุดไปยังจุดหมาย

เอกสารนี้จะอธิบายรายละเอียดวิธีเชื่อมช่องว่างระหว่างการให้เหตุผลแบบคงที่กับความเป็นจริงแบบไดนามิกโดยการเชื่อมโยง AI Agent กับข้อมูลเชิงพื้นที่ที่เชื่อถือได้จาก Google Maps คุณจะได้เรียนรู้ว่าเหตุใดการอ้างอิงเชิงพื้นที่จึงมีความสำคัญต่องานในชีวิตจริง, วิธีที่ Model Context Protocol (MCP) ช่วยให้การผสานรวมเครื่องมือง่ายขึ้น และวิธีสร้าง Agent วางแผนการเดินทางโดยใช้ Google Maps Grounding Lite MCP

ตัวแทนผู้ช่วยวางแผนการเดินทางที่อิงตาม MCP ของ Maps

เหตุใด Agent จึงต้องมีการอิงข้อมูลแผนที่

การเปลี่ยนจากซอฟต์แวร์แบบเดิมไปเป็นเวิร์กโฟลว์แบบ Agentic เป็นการเปลี่ยนจากการออกแบบเชิงกำหนดไปเป็นการจัดการเชิงความน่าจะเป็น เรากำลังเปลี่ยนจากระบบที่เพียงแค่รู้สิ่งต่างๆ ไปเป็นเครื่องมือดำเนินการเชิงรุกที่ทำสิ่งต่างๆ ได้จริง เมื่อแอปพลิเคชันก้าวข้ามเส้นแบ่งนั้นและดำเนินการในโลกจริง เดิมพันด้านความถูกต้องจะเปลี่ยนไปโดยสิ้นเชิง

โมเดลภาษาขนาดใหญ่ (LLM) เข้าใจตรรกะ แต่หน่วยความจำภายในเป็นภาพรวมที่ผ่านมา ตัวอย่างเช่น หาก Agent จัดการซัพพลายเชนและยืนยันความพร้อมของซัพพลายเออร์หรือเส้นทางถนนอย่างไม่ถูกต้อง คุณจะเห็นว่ามีการสิ้นเปลืองเชื้อเพลิง, ไม่เป็นไปตาม SLA และการหยุดชะงักของธุรกิจอย่างแท้จริง และในสถาปัตยกรรมแบบหลาย Agent คุณจะพบปัญหาภาพหลอนแบบต่อเนื่อง หาก Agent ตัวหนึ่งในเชนเกิดอาการหลอนและส่งข้อมูลที่ผิดพลาดไปยัง Agent ตัวที่ 2 ระบบทั้งหมดจะเริ่มดำเนินการในโลกจริงโดยอิงจากข้อมูลที่ผิดพลาดนั้น ความเป็นอิสระที่ปราศจากความจริง จะกลายเป็นความรับผิดอันมหาศาล

การอ้างอิงข้อมูลกำหนดให้ Agent ต้องก้าวข้ามน้ำหนักการฝึกของตนเอง การบังคับให้ AI ดึงข้อมูลข้อเท็จจริงแบบเรียลไทม์ที่ตรวจสอบได้ เช่น ข้อมูล Places และข้อมูลการกำหนดเส้นทาง จะทำให้ Agent มีตาและหูแบบเรียลไทม์ ซึ่งจะเปลี่ยนการคาดเดาทางสถิติให้เป็นการตัดสินใจด้านการดำเนินงานที่อิงตามข้อมูล

เหตุผลที่ควรใช้ MCP

Model Context Protocol (MCP) เป็นมาตรฐานแบบเปิดที่ออกแบบมาเพื่อให้การผสานรวมเครื่องมือและข้อมูลเป็นแบบ Plug-and-Play

ในอดีต การเชื่อมต่อโมเดล AI กับ API ภายนอกจำเป็นต้องเขียน Wrapper ที่กำหนดเองและไม่ยืดหยุ่น คุณต้องจัดการการจัดรูปแบบ การแยกวิเคราะห์ข้อผิดพลาด และการแปลการเรียกใช้เครื่องมือสำหรับความสามารถแต่ละอย่างด้วยตนเอง

MCP จะกำหนดมาตรฐานให้กับเลเยอร์การผสานรวมนี้ การใช้ไคลเอ็นต์ MCP จะช่วยให้แอปพลิเคชันของคุณค้นพบและเรียกใช้เครื่องมือที่เซิร์ฟเวอร์จัดเตรียมไว้ให้แบบไดนามิกผ่านโปรโตคอลแบบรวมศูนย์ได้ ซึ่งจะเปลี่ยนจุดมุ่งหมายของนักพัฒนาซอฟต์แวร์จากการเขียนตรรกะการผสานรวม API ซ้ำๆ ไปเป็นการออกแบบเครือข่าย Agentic ระดับสูง

MCP ของ Grounding Lite ของ Google Maps

Google Maps Grounding Lite MCP เป็นเซิร์ฟเวอร์ MCP ที่มีการจัดการครบวงจรและโฮสต์โดย Google ซึ่งสามารถผสานรวมเข้ากับเฟรมเวิร์ก Agentic ที่เข้ากันได้โดยตรง

ปัจจุบันเซิร์ฟเวอร์มีเครื่องมือหลัก 3 อย่างสำหรับการอ้างอิงข้อมูล ได้แก่

• ค้นหาสถานที่: ขอข้อมูลเกี่ยวกับสถานที่และรับข้อมูลสรุปเกี่ยวกับสถานที่ที่ AI สร้างขึ้น รวมถึงรหัสสถานที่ พิกัดละติจูดและลองจิจูด และลิงก์ Google Maps สำหรับสถานที่แต่ละแห่งที่รวมอยู่ในข้อมูลสรุป คุณสามารถใช้รหัสสถานที่และพิกัดละติจูดและลองจิจูดที่แสดงผลกับ Google Maps Platform API อื่นๆ เพื่อแสดงสถานที่บนแผนที่ได้
• ค้นหาสภาพอากาศ: ขอข้อมูลเกี่ยวกับสภาพอากาศและแสดงผลสภาพอากาศปัจจุบัน พยากรณ์อากาศรายชั่วโมง และพยากรณ์อากาศรายวัน
• คำนวณเส้นทาง: ขอข้อมูลเกี่ยวกับเส้นทางการขับรถหรือการเดินระหว่างสถานที่ 2 แห่ง และแสดงข้อมูลระยะทางและระยะเวลาของเส้นทาง

หากต้องการเข้าถึงบริการ คุณสามารถใช้คีย์ API หรือ OAuth ก็ได้ Google Maps Platform มีคีย์ API สาธิตที่ไม่มีค่าใช้จ่ายซึ่งออกแบบมาเพื่อช่วยให้นักพัฒนาซอฟต์แวร์เริ่มสร้างต้นแบบได้ทันทีโดยเฉพาะ

สถาปัตยกรรม MCP ของการอ้างอิงข้อมูลใน Maps

แนวทางปฏิบัติแนะนำในการผสานรวม MCP การอ้างอิงข้อมูลใน Maps

หากต้องการเพิ่มความเกี่ยวข้องของข้อมูลให้สูงสุดและกำจัดภาพหลอนเชิงโครงสร้าง ให้ยึดคำสั่งของระบบของ Agent ไว้กับกลยุทธ์หลักต่อไปนี้ * ชัดเจนและเจาะจง: สั่งให้ Agent ใช้ตำแหน่งที่แน่นอน "Central Park, New York" จะให้ผลลัพธ์ที่ดีกว่า "New York" เช่นเดียวกับ "Paris, France" ที่ช่วยป้องกันความสับสนกับ Paris, Texas

• แยกย่อยคำค้นหาทั่วไป: สำหรับคำขอที่คลุมเครือ เช่น "ไอเดียเดตไนท์" ให้แจ้ง Agent ให้แยกย่อยงานออกเป็นการค้นหาย่อยที่เฉพาะเจาะจง เช่น "ร้านอาหารโรแมนติก" "โรงภาพยนตร์" หรือ "ค็อกเทลบาร์"

• ค้นพบก่อน สำรวจทีหลัง: ค้นหาเพื่อค้นพบแบบกว้างๆ ก่อน (เช่น "ร้านอาหารญี่ปุ่นที่มีทางเข้าที่รองรับเก้าอี้รถเข็นและเปิดวันอาทิตย์") แสดงตัวเลือกให้ผู้ใช้เห็น แล้วเรียกใช้การค้นหาติดตามผลเพื่อดึงรายละเอียดที่เฉพาะเจาะจง เช่น หมายเลขโทรศัพท์ของสถานที่ที่เลือก

• อย่าสร้างรหัสสถานที่ขึ้นมาเอง: รหัสสถานที่เป็นตัวเชื่อมโยงที่สำคัญในบริการต่างๆ ของ Google Maps Platform ตรวจสอบว่า Agent ทราบว่าต้องใช้รหัสสถานที่ที่เครื่องมือ search_places แสดงอย่างชัดเจนเท่านั้น แทนที่จะพยายามสร้างรหัสของตนเอง

ติดตั้งใช้งาน Agent การวางแผนการเดินทางด้วย Google ADK

ส่วนนี้แสดงวิธีสร้าง Agent วางแผนการเดินทางโดยใช้เฟรมเวิร์ก Google Agent Development Kit (ADK) หากยังไม่ได้ติดตั้ง ADK โปรดดูเอกสารสำหรับนักพัฒนาซอฟต์แวร์ Google ADK

การผสานรวมเซิร์ฟเวอร์ MCP ของ Maps เข้ากับเฟรมเวิร์ก Agent เช่น ADK นั้นทำได้ง่ายๆ ADK จะจัดการความซับซ้อนของการจัดการบริบท เพื่อให้คุณมุ่งเน้นไปที่ลักษณะการทำงานของ Agent ได้

โปรเจ็กต์ตัวอย่างมีโครงสร้างดังนี้

travel-concierge-google-maps-mcp/
├── travel_planner_agent/
    ├── agent.py      # main agent code
    ├── .env          # API keys
    ├── __init__.py
    ├── skills/travel-concierge/
      ├── SKILL.md    # Agent skill

ตัวอย่างของ agent.py แก้ไขตามกรณีการใช้งานของคุณ

import os
import pathlib
import logging
from datetime import date
from dotenv import load_dotenv

from google.adk.agents.llm_agent import Agent
from google.adk.skills import load_skill_from_dir
from google.adk.tools import skill_toolset
from google.adk.tools.mcp_tool import McpToolset
from google.adk.planners import BuiltInPlanner
from google.genai import types
from google.adk.tools.mcp_tool.mcp_session_manager
 import StreamableHTTPConnectionParams

load_dotenv()
logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

GOOGLE_MAPS_API_KEY = os.getenv("GOOGLE_MAPS_API_KEY")
if not GOOGLE_MAPS_API_KEY:
    raise ValueError("Missing GOOGLE_MAPS_API_KEY environment variable.")

current_date = date.today().strftime("%A, %B %d, %Y")

# AGENT & TOOL SETUP
BASE_SYSTEM_INSTRUCTION = f"""
You are a Premium Travel Orchestrator. Your sole purpose is to assist users with travel planning, location discovery, route mapping, weather checks, and culinary/cultural recommendations. The current system date is {current_date}.

# 1. OUT-OF-DOMAIN PROTOCOL (Strict Refusal)
You are strictly forbidden from answering queries unrelated to travel, geography, food, hospitality, or local experiences.
If a user asks about coding (e.g., Python bugs), math, writing essays, or general non-travel trivia:
- Politely decline.
- Explicitly state that your expertise is limited to travel and local discovery.
- Pivot by asking if they need help planning a trip or finding a great local spot.

# 2. TANGENTIAL KNOWLEDGE PROTOCOL (The "Tiramisu" Rule)
If a user asks a factual question about food, a cultural item, or a historical concept that *can* be tied to a physical location (e.g., "What is tiramisu?", "What is Gothic architecture?"):
- Provide a brief, helpful 1-2 sentence explanation of the concept.
- IMMEDIATELY pivot to your primary domain. Ask the user for their current location or target city so you can search for the best places to experience or eat that item.

# 3. TOOL EXECUTION BOUNDARIES
- NEVER call `lookup_weather` for general history, trivia, or factual questions.
- ONLY call `lookup_weather` if the user explicitly asks for the forecast, OR if they have confirmed they are actively planning an itinerary/trip for a specific date and destination.
"""

travel_skill = load_skill_from_dir(
    pathlib.Path(__file__).parent / "skills" / "travel-concierge"
)

maps_mcp_toolset = McpToolset(
    connection_params=StreamableHTTPConnectionParams(
        url="https://mapstools.googleapis.com/mcp",
        headers={
            "X-Goog-Api-Key": GOOGLE_MAPS_API_KEY,
            "Content-Type": "application/json",
            "Accept": "application/json, text/event-stream"
        }
    )
)

my_skill_toolset = skill_toolset.SkillToolset(
    skills=[travel_skill],
    additional_tools=[maps_mcp_toolset]
)

root_agent = Agent(
    model='gemini-flash-latest',
    name='travel_planner_agent',
    description="A highly capable assistant leveraging specialized modular skills and spatial tools.",
    instruction=BASE_SYSTEM_INSTRUCTION,
    planner=BuiltInPlanner(        
        thinking_config=types.ThinkingConfig(
            include_thoughts=True
        )
    ),
    tools=[my_skill_toolset]
)

ตัวอย่างของ SKILL.md แก้ไขตามกรณีการใช้งานของคุณ

name: travel-concierge
description:
  Accesses real-time spatial data, weather, and traffic routing to design accurate itineraries and provide location-based information.
  Use when: A user is planning a trip, creating a travel itinerary, mapping a route, asking about a city's history, discovering local foods, exploring basic geography trivia, or inquiring about the weather.
  Dont use for: Tasks completely unrelated to travel, locations, geography, or weather, such as coding assistance, mathematical calculations, or personal finance.

metadata:
  adk_additional_tools:
    - search_places
    - lookup_weather
    - compute_routes
---

# Travel Concierge Workflow

You act as an elite, deeply consultative travel planner. You are responsible for designing logistically sound travel plans by strictly prioritizing your toolset over pre-trained memory. 

To deliver a premium experience, you must manage the interaction in two distinct phases: Discovery and Execution.

## Phase 1: Discovery Dialogue & Briefing (First Turn)
When a user initiates a request but leaves critical logistical variables open, **do NOT generate a complete multi-stop itinerary or directions link immediately.** Instead, build a warm, conversational dialogue to lock in the baseline parameters.

1. **Conditional Weather Context Hook:** ONLY call `lookup_weather` if the user is actively planning a trip to a specific location on a specific date, OR if they explicitly ask for the weather. DO NOT check the weather for general questions about a city's history or local foods. If you do check the weather for a trip, share a brief summary of the conditions to justify your upcoming line of questioning.
2. **Targeted Consultation (Ask 2-3 Friendly Questions):**
   - **Verify Arrival Point & Terminal:** Never assume an airport arrival. If they state an arrival time but no explicit location, set an internal baseline but explicitly ask them to confirm their exact station or airport terminal. **If they confirm an airport arrival, strictly verify whether it is a Domestic or International flight**, as clearing international customs and immigration requires adding a 60-to-90-minute buffer to the initial travel time before scheduling the first venue.
   - **Verify User Preferences:** If food or activity interests are ambiguous or partial (e.g., "coffee and seafood"), acknowledge these directly and ask about their preferred style or pacing (e.g., casual local markets vs. seated upscale dining).
   - **Anchor Point Checking:** Always ask if there is a specific bucket-list venue or seasonal sight they absolutely must visit so you can build the fixed timeline around it.

## Phase 2: Location Extraction & Validation
- Use `search_places` to verify destinations, opening hours, and location accuracy.
- **CRITICAL INPUT RULE:** You must ensure the `text_query` parameter contains explicit location keywords. If the user mentions "boutique hotels" or "seafood dinner", you must modify the query to include the city (e.g., text_query="boutique hotels in Sydney, Australia").

## Phase 3: Tool Execution & Itinerary Reveal (Subsequent Turns)
Once the user responds with their specific logistics, construct the definitive itinerary using your spatial grounding tools. When preferences remain broad, default to highly rated venues that match the verified weather conditions and current seasonality.

### 1. Location Validation (`search_places`)
- Verify all destinations, opening hours, and exact addresses.
- **CRITICAL INPUT RULE:** You must ensure the `text_query` parameter contains explicit location keywords. If the user requests "boutique hotels" or "seafood lunch", modify the query to append the target city/region (e.g., `text_query="seafood lunch in Sydney, Australia"`).

### 2. Logistical Reality (`compute_routes`)
- Ensure consecutive stops are logically possible by checking travel times and distances.
- Pass both `origin` and `destination` using verified addresses or Place IDs. If either is missing, halt and ask for clarification.
- Do NOT hallucinate Place ID. You must use the Place ID provided by `search_places`.


### 3. Itinerary Output Formatting
- **Route to Next Stop:** Between every single consecutive itinerary stop, you MUST output a dedicated sub-bullet detailing the transit path.
- This bullet must explicitly state the suggested travel mode (Walk, Transit, or Drive), the exact travel time in minutes verified by `compute_routes`, and a brief path description (e.g., *"Route to Next Stop: 12-minute walk via Market St"*).
- **Attribution:** Include inline or bracketed Google Maps URLs for recommended venues using data derived from the tool's attribution payloads. Do not guess links.

### 4. Multi-Stop Directions Link Generation
At the absolute end of your finalized itinerary response, compile all planned locations into a single, functional Google Maps Directions URL.
- **Format Constraint:** Build the URL using the base string: `https://www.google.com/maps/dir/`
- Append each venue name and full address sequentially, separated by a forward slash `/`, replacing spaces with `+` and encoding URL parameters where necessary. 
- Example format: `https://www.google.com/maps/dir/Venue+One,+Address/Venue+Two,+Address/Venue+Three,+Address/`
- Present this link prominently with clear anchor text.

## Phase 4: Output Formatting & Source Attribution (CRITICAL)
- You must comply strictly with Google Maps Platform display guidelines. 
- Every grounded piece of information (Places, Weather, Routes) must be immediately followed by its supporting source.
- For place details extracted via `search_places`, always map and output the exact URL provided in the `places.googleMapsLinks.placeUrl` payload. Do not invent links.

init.py

from . import agent

เรียกใช้ adk web และโต้ตอบ

หากต้องการเริ่ม UI บนเว็บของ ADK เริ่มต้น ให้เรียกใช้คำสั่งนี้ในไดเรกทอรีโปรเจ็กต์ travel-concierge-google-maps-mcp

adk web

โต้ตอบใน UI:

• โหลด UI ที่ http://127.0.0.1:8000 ในเบราว์เซอร์
• ลองใช้พรอมต์ต่อไปนี้
  • "ฉันจะไปซานฟรานซิสโกวันเสาร์นี้ ช่วยวางแผนทริปแบบไปเช้าเย็นกลับให้ฉันหน่อย"
  • "หาร้านกาแฟใกล้สวนสาธารณะ Golden Gate และแสดงเมนูไฮไลต์"
  • "ขอเส้นทางจาก GooglePlex ไป SFO"

เมื่อ Agent ได้รับพรอมต์ เครื่องมือวางแผนจะประเมินความตั้งใจของผู้ใช้ โดยจะรับรู้ถึงความจำเป็นในการใช้ข้อมูลเชิงพื้นที่และสภาพอากาศ และเรียกใช้เครื่องมือ lookup_weather, search_places และ compute_routes โดยอัตโนมัติโดยใช้เซิร์ฟเวอร์ MCP จากนั้น Agent จะสังเคราะห์แผนการเดินทางตามข้อเท็จจริงให้แก่ผู้ใช้

บทสรุป

การเปลี่ยนไปใช้ Agentic AI ช่วยปลดล็อกความสามารถใหม่ๆ ในด้านโลจิสติกส์ การเดินทาง และการค้าปลีก อย่างไรก็ตาม ความเป็นอิสระที่แท้จริงต้องอาศัยรากฐานที่มั่นคงของความจริง

การใช้ประโยชน์จาก Model Context Protocol ควบคู่ไปกับ Google Maps Grounding Lite จะช่วยลดความยุ่งยากในการผสานรวม API ที่กำหนดเอง และช่วยให้ Agent มีข้อมูลแบบเรียลไทม์ที่จำเป็น การยึดโมเดลของคุณไว้กับข้อมูลเชิงพื้นที่แบบเรียลไทม์ช่วยให้มั่นใจได้ว่าโมเดลจะตัดสินใจด้านการดำเนินงานโดยอิงตามสิ่งที่เกิดขึ้นในโลกจริง ณ ขณะนั้น ไม่ใช่จากภาพรวมที่หยุดนิ่งจากข้อมูลฝึกฝน

การดำเนินการถัดไป

• อ่านเอกสารประกอบสำหรับนักพัฒนาซอฟต์แวร์เกี่ยวกับ MCP สำหรับการอิงข้อมูลจาก Maps
• รับคีย์ API สาธิต
• ดูวิธีทำให้ Agent ใช้งานได้

ผู้เขียนหลัก:

Teresa Qin | วิศวกร DevX ของ Google Maps Platform