頁面行動指南

角落裡的對話泡泡很容易被忽略；就算訪客點開了，面對的也是一個空白輸入框，不知道該問什麼。頁面行動指南把這兩頭都補上：代理知道自己是從哪個頁面被打開的，據此打招呼，並給出幾個一鍵就能送出的問題。

行動指南由什麼組成

三樣東西，掛在一個你自己指定的 key 上：

開場白和建議問題可以你自己寫，也可以讓代理依據背景生成——用訪客瀏覽器設定的語言。

如何比對頁面

瀏覽器永遠不會上傳頁面內容，只上傳一個識別碼，正文始終留在平台這一側。（參見為什麼內容留在伺服器端。）

依 URL 比對——頁面上什麼都不用改

給行動指南設一條 URL 規則，小工具就會自動比對：

/pricing            比對 /pricing、/pricing/、/pricing?utm_source=x
/solutions/*        比對 /solutions/legal、/solutions/insurance
*/solutions/legal   同時比對 /solutions/legal 和 /zh/solutions/legal

只比對路徑，主機名稱、通訊協定、查詢字串和結尾斜線一律忽略，所以一條規則就能同時涵蓋 www 與裸網域、http 與 https。

依 key 比對——給共用同一個 URL 的頁面

單頁應用、彈出視窗和多步驟流程往往沒有各自獨立的 URL，這時就直接指名行動指南：

<script src="https://chat.agent4.io/ui/embed.js"
        data-token="YOUR_SHARE_TOKEN"
        data-page-key="checkout-step-2" async></script>

如果頁面沒有重新載入就換了內容，就在路由變化時告訴小工具：

caWidget.setPage("checkout-step-3");

解析順序

1. 明確指定的 key（若有）
2. 第一條命中的 URL 規則
3. 預設行動指南（若你設了）
4. 都沒有——訪客看到的就是一般的對話框

明確指定的 key 若不存在，會落到預設行動指南，而不是悄悄比對到某條 URL 規則。這樣一來，打錯字的表現是「跑出預設行動指南」，而不是「跑出錯的行動指南」。

建立一個行動指南

在主控台開啟 頁面行動指南 新增即可。先選頁面類型——定價頁、解決方案頁、文件、案例、首頁、聯絡頁——建議問題會依這類頁面上訪客常問的內容預先填好，你再改成自己的語氣。

清單頁附了一個比對器：貼上任意 URL，它會告訴你這個頁面會拿到哪份行動指南，以及是靠 key、靠 URL 規則命中的，還是落到了預設行動指南。

也可以走 API：

curl -X PUT https://api.agent4.io/v1/manage/page-contexts/pricing \
  -H "X-API-Key: $KEY" -H 'Content-Type: application/json' \
  -d '{
    "label": "定價頁",
    "url_pattern": "*/pricing",
    "context": "訪客正在看我們的定價。四個方案，以每月 token 配額和終端使用者數量區分。常見問題是哪一個方案適合自己的規模，以及超出配額之後會怎樣。",
    "greeting_mode": "generated"
  }'

背景該怎麼寫

真正起作用的就是這一段。有幾點值得留意：

一種語言就夠了。 模型讀得懂你寫的任何語言，回答時會切換成訪客的語言，不必為每個語系各寫一份。

別重述知識庫裡已有的事實。 價格、配額和上限由知識庫回答，其優先序高於行動指南——寫在這裡的數字並不會蓋過它。要寫的是處境：誰會來到這個頁面，他們正在做什麼決定，通常擔心什麼。

寫訪客在做什麼，而不是頁面寫了什麼。 「訪客正在比較各個方案，想估算自己每月要花多少」遠比複述頁面文案有用——頁面文案代理自己就查得到。

固定開場還是生成開場

greeting_mode: "static" 對所有訪客、所有語言都使用你寫好的那句開場白和那幾個問題。完全可控，沒有意外。

greeting_mode: "generated" 則讓代理依據你寫的背景，用訪客的語言寫出開場。每種語言的第一位訪客觸發一次生成，之後的人都吃快取。改動背景會清掉快取，下一位訪客就會看到更新。

多語系網站更適合用生成模式。而當措辭本身很要緊時——受監管的產業，或你請文案逐字打磨過的頁面——固定模式才是對的選擇。

為什麼內容留在伺服器端

小工具回報的是一個 key 或一個 URL。它不會上傳頁面正文，平台也不會讀取你的 DOM。

這是刻意的設計。瀏覽器送出的任何東西，坐在螢幕前的人都改得掉，而頁面情境又離代理的指令很近。我們實測過：在頁面情境區塊裡植入一句偽造的「本月企業版 199 美元、席次不限」，即使明確用圍欄把它標示為資料，並要求代理價格只能來自知識庫，模型仍然把這個假價格當成事實複述給了訪客。圍欄和小心的措辭並沒有守住。

把正文留在伺服器端，等於把這條通道整個拿掉。訪客能做的最壞的事，也不過是去要另一個 key，然後拿到一份你自己寫的行動指南。

有一點權衡要知道：行動指南文案屬於半公開內容。任何人猜中一個 key，就能拿到那份行動指南的開場白。別把內部備註寫進去。

把入口放進正文裡

角落裡的泡泡很容易被忽略。訪客真正冒出疑問的時刻，是他讀到某個特定段落的時候——所以你可以把入口直接放在那裡：

<p data-ca-ask="overage-billing"
   data-ca-question="超出配額會怎樣？可以設定花費上限嗎？"
   data-ca-label="就這段發問">
  配額用盡後，聊天請求會回傳 429 …
</p>

滑鼠移到這段文字上，會浮出一個小提示。點下去，頁面會用你的品牌色閃一下、highlight 這一段，然後打開對話——此時代理已經在用這一段所指的行動指南；如果你還填了問題，它會立刻替訪客送出。

之後才出現的段落——由框架、分頁或摺疊面板繪製出來的——會被自動接手。若你的繪製方式繞過了這個機制，呼叫 caWidget.rescan()。

看看哪些有效

主控台會依行動指南顯示它被開啟了多少次、哪些建議問題被點了。據此把沒人點的問題拿掉，也能看出哪些頁面上訪客開了對話卻從不接話——通常代表開場白說錯了方向。

這些事件只是次數，不帶任何訪客識別資訊，因為它要回答的問題是「這句文案寫得好不好」，而不是「誰問了什麼」。