智能體卡片、JSON-LD 與 MCP：商家可落地的發布棧

本地商家不必一夜之間變成 API 公司。 但需要一小套連貫棧，讓 ChatGPT、Perplexity、Gemini、DeepSeek 與未來助手能 找到準確事實、核驗身分、並走出下一步。Agent Card、JSON-LD、MCP 聽起來偏工程；落到營運，對應幾週內就能完成的四類發布面。

本指南說明每一層、「足夠好」對餐廳 / 診所 / B2B 供應商意味著什麼，以及準策如何把它們串起來。

總覽

| 層級 | 人讀 URL | 機讀表面 | 作用 |

| --- | --- | --- | --- |

| 經營門面 | `/b/{handle}` | Facade JSON | 營業時間、菜單、預約 / WhatsApp |

| 信任護照 / 智能體卡片 | `/t/{trusgentId}` | Agent Card JSON（`/api/v1/t/...`） | 能力、信任分、認證等級 |

| 官方出處 | `/r/{registryId}` | 登記欄位 | 牌照 / CR 錨點 |

| 工具接入 | 開發者文件 | MCP 工具 + 公開 API | `search_agents`、`get_agent`、`verify_agent`、門面工具 |

官網上的 JSON-LD 仍有助於經典 SEO/AEO。把準策當作 規範的可信層鏡像：即便 CMS 混亂，智能體也能查詢。

第 1 層 — 經營門面（`/b`）：人與智能體共用的行動面

請發布：

•帶時區誠實度的營業時間

•名稱清晰的服務 / 菜單（避免難懂 SKU）

•主聯絡路徑（電話、WhatsApp、預約）

•與真實門店一致的照片

AAO 測試： 助手能否如實說「營業至 22:00；可在此頁預約」，而不編造表單？

`/b` 與 Google 商家資料不一致，是最常見、也最好修的信任洩漏。請每週對齊。

第 2 層 — 智能體卡片（`/t` + JSON）：短名單對象

智能體卡片是助手做短名單時對比的結構化履歷：

•顯示名與多語言變體

•服務地區與類別

•認證等級與信任訊號

•指向經營門面與登記出處的連結

GEO 測試： 兩家都提供「中環午餐」時，你的卡片是否有足夠 消歧事實（菜系、牌照類別、人數、價位）以在重組後仍可區分？

目錄上架（[短名單文章](/blog/agent-directory-ai-shortlist)）會進一步提升偏好「策展庫存」而非純網頁抓取的智能體發現率。

第 3 層 — 登記出處（`/r`）：身分錨點

有香港官方記錄就認領（[認領指南](/blog/how-to-claim-hong-kong-registry-listing-on-trusgent)），並關聯智能體，避免核驗只剩行銷口號。

信任測試： 含「持牌 / licensed / registered」的提示下，公開敘事是否包含 穩定登記標識，而不只是星級？

參見 [官方登記庫 vs Google 商家資料](/blog/official-registry-vs-google-business-profile-for-ai)。

第 4 層 — MCP 與公開 API：智能體如何調用你

Model Context Protocol（MCP）工具讓智能體運行時無需抓 HTML 即可查詢準策：

•搜尋 / 獲取智能體檔案

•核驗信任訊號

•讀取經營門面載荷以支撐預約語境

你不必自建 MCP 也能受益：智能體卡片與經營門面補齊後，已連接準策 MCP 的第三方智能體可以把你當作結構化對象取回。

AAO 測試： 從「短名單項」到「行動載荷」（營業時間、聯絡、預約 URL）是否有文件化路徑？

JSON-LD 放在哪裡（你自己的網站）

繼續在企業站發布 schema：

•`LocalBusiness` / `Restaurant`，營業時間與準策一致

•FAQPage 承接 AEO 摘要

•一致的 `@id`，必要時用 sameAs 指向信任護照與登記頁

JSON-LD 幫搜尋引擎摘取；智能體卡片幫 智能體運行時選擇。有預算就兩者都做；若本月只能優先一面，先完成 `/t` + `/b`。

14 天落地計劃

第 1–3 天： 認領 `/r`（如適用）；統一法定 / 商號名稱。

第 4–7 天： 補齊智能體卡片服務與地區；達到目錄就緒。

第 8–10 天： 發布經營門面營業時間 / 菜單 / 聯絡；與 GBP 同步。

第 11–14 天： 啟動真實性認證；用 [每週 AI 可見性提示詞協議](/blog/ai-visibility-weekly-prompt-protocol-for-merchants) 測量提及。

常見失敗模式

| 失敗 | AI 回答症狀 | 修復 |

| --- | --- | --- |

| 能力集為空 | 「找到列表但沒有細節」 | 添加服務 / 產品 |

| 營業時間衝突 | 含糊或開關店錯誤 | 對齊 GBP 與 `/b` |

| 無出處 | 「持牌」提示被跳過 | 認領 `/r` + 認證 |

| 頁面漂亮但無 JSON | 被提一次卻從不被調用 | 補齊智能體卡片 + 門面 |

| 虛假緊迫 CTA | 助手拒絕推薦 | 改用誠實預約路徑 |

常見問題

用 MCP 需要工程師嗎？

被調用 不需要。補齊準策檔案即可暴露 API/MCP 友好資料。自建 MCP 伺服器對商家通常非必需。

智能體卡片等於 schema.org JSON-LD 嗎？

目標相關，主消費者不同。JSON-LD 面向抓取 / 摘取生態；智能體卡片面向目錄與工具調用。事實重疊是好事；互相矛盾是壞事。

餐廳應先做哪一步？

處處營業時間一致、`/b` 上一條清晰預約 / WhatsApp 路徑，以及 `/r` 上已認領的相關官方登記連結。

結語

把智能體卡片 + 經營門面 + 登記出處當作 最小可信層。網站 JSON-LD 與 MCP 連通性是放大器。做完這套棧，助手更少胡編，更有理由把你 列入短名單並調用。可見性階梯請回顧 [SEO vs AEO vs GEO vs AAO](/blog/seo-aeo-geo-aao-practical-matrix-for-local-merchants)。