通路接入

智能體介面(Agent-to-Agent)

把你的商家智能體開放給其他智能體。顧客的 AI 助理可以發現它、向它諮詢,並透過 MCP 與 A2A 提交一份結構化、預先填好的請求——而任何不可逆的動作都由真人確認。

智能體介面讓你的智能體不只能被聊天裡的真人接觸到,也能被你顧客的 AI 助理以機器對機器的方式接觸到。助理可以提出有依據的問題,並提交一份結構化、預先填好的請求;你這邊負責前處理,再交回一份供真人確認的摘要。它建立在開放的智能體標準之上——MCP(工具)與 A2A(agent card)——因此沒有任何量身訂製的協定要實作。

agent4.io 是 agent-to-agent 的商家端。你把介面開啟;你既有的、有依據的智能體——同樣的知識、技能與拒答界線——就能被其他智能體接觸到。真人的聊天體驗完全不變。

一次互動的樣貌

發現與連接

有兩個層級,差別在於允許助理做什麼。

讀取層——自動發現,無需設定

助理在一個標準位址找到你智能體的 card,就能立即開始:

  • https://<your-domain>/.well-known/agent.json —— A2A 的 agent card(白牌網域,或你的 agent4.io 網址)。
  • 頁面內:一個 <link rel="agent" href="…"> 標籤與 window.agent4,讓已在你網站上的瀏覽器型助理無需額外跳轉就能找到它。

讀取層是公開且安全的:只有有依據的回答、接單契約與狀態查詢。沒有個人資料,也不能提交請求。

寫入層——一次性配對

要代表某人提交請求,助理必須與該當事人配對一次:

  1. 顧客在你的聊天或小工具中點一下**「用你的 AI 助理使用」**。
  2. 他收到一組一次性代碼(外加一個可複製的連結、一個 QR code 與一個 deep link)——而不是一大段要貼上的文字。
  3. 他的助理拿代碼換取一組受限範圍的 token(一種 OAuth device / authorization-code 式的交換),並自行讀取 agent card。

換來的 token 綁定到那位經過驗證的當事人受限範圍(這家商家、這位顧客、僅限前處理)、短期有效,且顧客可隨時撤銷。這正是把一個聲稱的身分升級為一個有來歷的身分之關鍵。

這些動作

動作層級用途
get_capabilitiesread這個智能體能回答與能做什麼;它的服務與界線
get_requirements(service)read接單契約:必填/選填欄位、型別,以及有依據的政策
ask(question)read一個附引用、有依據的回答,或在超出範圍時移交
status(reference)read某筆先前請求的進度
propose(service, payload)write提交一份結構化請求;回傳一份草稿 + 摘要
handoff_to_human(reference?)write一個由助理交回其主人的接續連結

接單契約

get_requirements 是消除摩擦的關鍵:助理永遠不必去猜你的格式。它回傳某項服務需要的欄位,以及圍繞它的有依據政策(訂金、前置時間、取消),這些皆衍生自你智能體的技能——因此助理會填上它已知的部分,只在真正缺漏之處才向主人詢問。

草稿模型

propose 絕不回傳「完成」。它最強的狀態是 tentative——一份已備妥、正等待確認的請求,而不是一筆已完成的交易:

  • needs_info —— 必填欄位缺漏或含糊;見 open_questions
  • tentative —— 已被接受為草稿,尚待確認。
  • declined —— 無法被接受(超出政策或範圍)。

在真人確認之前,沒有任何東西是 confirmed 的。你的行銷與你的回應都必須反映這一點:一筆 tentative 的預約是一份請求,而不是一張已訂到的桌子。

移交給真人

在任何時點,助理(或你的智能體)都可以請求移交。agent4.io 會鑄造一個限定於該工作階段的接續連結;顧客打開它,看到完整的逐字紀錄,並以真人的身分接續下去——在草稿被確認之前更正或取消它。行為人歸屬會在移交處切換,所以紀錄永遠顯示是誰說了什麼。

稽核

每一次互動都會被記錄,僅可追加,並綁定到請求的 reference:每一筆傳入的主張(歸屬於發出呼叫的助理,以及與它配對的那位當事人)、你回傳的每一個回應,以及每一步的行為人。一筆提交資料的請求絕非匿名——這正是讓你能把顧客的助理視為該顧客授權代表,並在事後確切證明交換了什麼的原因。

一個實作範例

  1. 發現 —— 助理取得你的 agent card。
  2. 配對 —— 顧客點一下用你的 AI 助理使用;助理拿代碼換取一組受限範圍的 token。
  3. get_requirements("reservation") —— 日期/時間範圍、人數、座位、飲食注意事項、姓名、聯絡方式;外加你的訂金與取消政策。
  4. propose("reservation", …){ status: "tentative", summary, reference, open_questions: [] }
  5. 確認 —— 助理把摘要秀給它的主人看;一經確認,你的團隊(或一次可用性檢查)便予以定案。
請求與回應的具體結構會隨平台實作一併定案;本頁描述的是模型與那些保證。另請參閱 白牌與自訂應用紀錄