客戶帶 AI agent 上門？三種准入方式與四個控制點
客戶的 AI agent 已經在代替本人上網購物、訂機票、查銀行結餘，甚至在你公司的網站上完成交易。企業要決定的，是讓它進來時用自己的身份、用客戶的登入，還是索性擋在門外。這件事屬於 ai agent development 的另一半：除了寫出 agent，還要決定誰可以代誰在你的系統裏做事。
重點
- 2026 年 10 月出現了三種回應：封鎖、共用客戶登入、給 agent 一個獨立帳戶。三者的代價不同，沒有一種是免費的。
- 對香港商戶來說，關鍵不在選哪一種，而在自家系統能否回答「誰在代誰做」。
- 分清楚「誰在代誰做」，靠的是身份欄位，不是robots.txt，也不是帳號數量。
- 沒有企業網站能單憑自己決定 agent 的身份標準：Personal Agent Protocol 的草稿仍在成形。
- 最實際的下一步，是先寫好一份准入政策，再檢查自家 ERP、CRM 與網站能否回答身份、允許範圍和批准記錄。
十月出現的三種答案
三家企業在 2026 年 10 月分別做了選擇，而每一種選擇都能在公司自己的網站上照樣做一遍，差別在於你打算付出哪種成本。對香港的網店與會員制服務來說，先看清每一種做法的代價，再決定 ai agent development 的重點放在哪一邊，比直接照搬任何一家的做法穩妥。
JPMorgan Chase 選擇封鎖。該公司行政總裁在 2026 年第三季業績電話會議上表明，不會讓任何外來 agent 進入公司內部。The Verge 在 2026 年 10 月的報道補充，Charles Schwab 同樣封鎖 agent 存取帳戶，Delta 則阻止 agent 代客訂票。封鎖的好處是風險可控，代價是客戶用 agent 辦事時會撞牆。
第二種是不做任何事，讓 agent 用客戶的登入簽到。Bank of America 在 2026 年 10 月 27 日向客戶發出電郵，提醒不要與聲稱代辦的 AI agent 分享登入資料，並註明一旦分享，客戶要為由此產生的活動負責。對企業而言，這種默認狀態把責任推回客戶身上，也把 agent 與客戶的活動混在同一本帳裏。
第三種是給 agent 一個獨立帳戶。Walmart 的做法是在客戶帳戶內為每個 agent 開一個專屬檔案，並可為它設定消費上限，例如 50 美元、100 美元或 200 美元。它說明了動手的原因：目前 agent 用客戶帳號簽到，客戶與 agent 的消費全部混在一起，無法區分。同樣的邏輯，換成香港的網店、會員制服務或 B2B 落單系統，都可以複製。
| 准入方式 | 企業要付出的成本 | 適合誰 |
|---|---|---|
| 封鎖 | 客戶用 agent 辦事時失敗，可能流向競爭對手 | 高風險交易、法規約束重的業務 |
| 共用客戶登入 | 責任在客戶，但企業分不清訂單是人是 agent，也無法單獨撤銷 | 尚未出事、想先觀望的中小企 |
| 獨立 agent 檔案 | 要改帳戶模型、加消費上限與審批，工程量最大 | 交易頻密、需要區分來源的商戶 |
為什麼「看得出那是 agent」才是前提
三種做法都建立在同一個能力上：網站要認得來訪的是 agent，並且知道它是誰派來的。如果分不出 agent 與客戶本人，就談不上給予不同待遇。
規模上，這些 agent 仍未主導流量。DoorDash 行政總裁在業績電話會議上說，外部 AI agent 至今合共下了「或許幾百張」訂單，而同一季度公司處理的訂單以億計，每日的訂單以千萬計。兩個數字放在一起，說明企業仍有時間寫政策，但也說明門已經開了。
行業標準則尚未定型。Sierra 與 Meta 正在共同起草 Personal Agent Protocol，參與制定者多達 40 多家公司；新聞作者在 11 月 1 日查看時，協議網站尚未列出任何在客戶場景中使用的企業。草稿在 10 月 30 日加入一項建議，要 agent 用 Web Bot Auth 為請求簽名，用來證明是哪家公司運行這個 agent。Meta 的 Muse 已自 10 月 12 日起用這種方式為部分請求簽名。網絡安全公司 Cloudflare 早在 2025 年便推出過一鍵封鎖 AI 爬蟲的功能，但那解決的是索引層，不是身份層。把 robots 設定當成登入授權，是香港商戶最常見的誤解之一。
換句話說，現階段的「身份」有兩條路：等協議成熟，或自己在帳戶層做分類。前者的好處是統一，壞處是時間不由你控制；後者可以今天就做，但需要自家 ai 系統整合 配合。後一條路的成本落在系統上，可以提早預算。
三個問題，寫成一句話便足夠
企業要寫進政策的，其實只有三個問題的答案；把答案各寫成一句話，就可以交給工程與客服團隊執行。
第一個問題是誰在代誰做。答案要說明 agent 屬於哪個客戶，由哪家公司運行，用甚麼識別。若答不出運行方，就只有「某個 agent」而沒有「誰的 agent」，日後追查無從入手。
第二個問題是可做甚麼。同一個 agent 不應該同時可以查餘額、改地址和確認付款。允許範圍要按動作劃分，而登入成功不代表全部功能已授權。
第三個問題是何時須人批准。金額多少以上、涉及不可逆操作、改動聯絡資料，這些都應停在「待批准」而不是直接執行。
一個實用的做法，是把三個問題的答案寫成觸發條件，直接掛在現有系統上，例如「消費超過某個上限即暫停，等客戶在手機確認」。香港不少公司早已有這類審批流程，只是過去服務的是人類員工，現在要把它延伸到 agent。
在哪裏落地：ERP、CRM 與網站的分工
准入政策能否執行，取決於資料在哪裏。訂單與庫存在 ERP，客戶關係與歷史在 CRM，交易入口在網站或 App；三個地方各自握有部分答案，任何一方單獨缺失，政策都會落空。
這正是 erp 系統 整合 派上用場的地方。當 ERP 的訂單記錄多了一個「來源」欄位，可以分辨是人手輸入、agent 代下還是 batch 匯入，客訴與對帳時就不用再靠猜。CRM 則記錄哪個客戶授權了哪個 agent，撤銷授權時有據可依。
網站一層負責的是入口控制：判斷來訪請求是否來自已登記的 agent，未登記的按政策處理。這一層的判斷要與後台的身份記錄對得上，否則同一件事會在兩個系統寫成兩個版本。
這也解釋了為何准入政策要從開發階段開始寫：執行力取決於有沒有預先留下身份、範圍與批准的接口。同樣的道理適用於 erp 系統 整合：ERP 若只能人手入單，agent 代辦的動作就只能寫進另一個系統，日後對帳要花更多時間。
Boot dev 有沒有用 generative AI：教材無答准入
搜尋「ai agent development」，香港使用者拿到的多半是編程教學。其中一個常被列出的問題是 Boot dev 是否使用生成式 AI。這個問題的答案不在本文明確回答，因為它在准入政策上不構成決策依據。
值得留意的是這類教材共同留下的空白。它們教人用 Python 寫一個會呼叫工具的 agent，卻很少談被呼叫的那一方要如何認證、授權與留痕。企業若照教材的架構自行開發，往往得到一個能做事但說不清責任的系統，而這正是 ai agent development 在企業場景中最容易被忽略的一段。
把這個空白翻過來用，就是本文的判斷標準：一個 agent 值不值得放進業務流程，取決於它每一步能否被識別、被限制、被暫停。做到這三點的系統，即使功能較少，也比功能齊全但無法問責的系統適合企業。
Topkee 的看法：agent 治理要落在四個控制點
Topkee 的 AI Agent 平台服務的是企業自己把工作交給 AI 完成，與本文談的外部 agent 准入方向相反，但應付的是同一套問題。平台把它拆成四個控制點，這套框架同樣可以用來設計准入政策。
身份上，平台以短期租戶 JWT 運行部署實例並自動刷新，不用永久共享密鑰；每個營銷活動實例化為獨立 Agent，擁有專屬工作區與記憶檔，會話彼此隔離。範圍上，能力邊界寫進模板規則，明確指出身份認證不等於全部業務授權。批准上，Approvals 負責批准或拒絕待執行步驟，花費、發布與關鍵變更都要經過它。留痕上，運行記錄與任務清單說明做了甚麼、依據是甚麼，日誌可審計、版本可回滾。
截至 2026 年 10 月，平台目錄共幾十項，包括 Skill、Bot Team 與 Plugin 三類。這些是模板條目數，不代表相等數目的獨立成品，也不代表全部通過業務驗收。若企業要把外部 agent 接到自家系統，ai 系統整合 的能力在於把廣告、落地頁、CRM 與分析平台整合成可被調用的接口，而非讓 agent 只讀網頁。
邊界也要講清楚：這套平台是企業內部的代理工作台，不是「接待外部 agent 的網站網關」，三種准入方案它都沒有提供。它提供的是可以借用的治理樣板，准入決定仍要由網站日誌、SSO 權限與合約條款另作安排。資料接入方面，平台以定製開發與 API 集成把廣告、CRM、分析平台等整合成單一互聯生態；工程化整合一節也提到，客戶既有的 CRM、ERP 與電商商城會被真正接入。這些描述講的是做得到甚麼，並不承諾固定週期或效果。
上線前，平台建議先確認四項：目錄與依賴、業務服務權限、運行環境、發布職責；落地則分四階段，由選場景、接入配置、小範圍試運行到複用擴展。這四階段的順序，同樣可以套用在外部 agent 的准入試點上：先選一個低風險的場景，跑通身份與批准，再逐步放寬。
怎樣判斷貴公司是否已經準備好
以下檢查可以在內部完成，不需要新系統上線。任何一項答不出，就說明接入 agent 之前還要補的正是這一塊。
- 現在打開網站的存取記錄，能否分辨人類與 agent 的請求？
- 當 agent 用客戶帳號下單，訂單記錄有沒有欄位標明來源？
- 撤銷一位客戶的授權時，可否只停用那個 agent 而保留客戶本人的帳戶？
- 超過某個金額的動作，會否自動停在待批准狀態？
- agent 執行過的每個動作，有沒有連到當時的授權與批准記錄？
如果答案多是「不確定」，那麼先做的一步是把三條問題的答案寫下來，拿這份文件去問現有系統的供應商能否配合，採購可以晚一步。香港中小企在此可以參考 不只是代理商 描述的連接方式，先確認數據在哪、誰能取用，再談自動化。
系統層面的準備可以走另一條線：Topkee Cloud 以多租戶隔離配合最小權限與短期作用域令牌，適合用來理解「辨識並授權來訪者」可以在哪一層落實。若企業想先看一個實例怎樣把漏斗數據整理成行動，TTO Funnel Tuning Agent 是一個可參考的起點。
常見問題
客戶的 AI agent 來下單，我們可以拒絕嗎？
可以，封鎖是文中三種准入方式之一，JPMorgan Chase、Charles Schwab 與 Delta 都採取了這類做法。拒絕的代價是客戶改用其他渠道，因此要先分清哪些交易值得封鎖，哪些只需加上限制。
讓 agent 用客戶的登入，責任是不是客戶的？
Bank of America 在電郵中表明，客戶若把登入資料分享給 agent，要為由此產生的活動負責。責任歸客戶，不等於企業沒有風險：訂單分不清來源，退貨與爭議處理仍然要由企業承擔。
獨立 agent 檔案一定要改動整個帳戶系統嗎？
不一定。可以先在訂單或交易記錄加一個來源欄位，再把 agent 的動作與授權記錄連結起來。等到成交量足夠，才需要把它做成一級帳戶結構。
小型企業需要等官方協議定稿才動手嗎？
Personal Agent Protocol 的草稿仍在演變，並未列出任何在客戶場景使用的企業。小型企業可以先用內部政策與記錄欄位做準備，協議成熟後再對接，損失的時間有限。
不寫政策會有甚麼後果？
沒有政策，等於默認接受第二種做法：agent 用客戶登入，活動混在一起。日後要追查一筆訂單由誰促成、由誰批准，只能翻查零散的對話記錄。
Sources
- Businesses Treat Your AI Agent 3 Different Ways, nohacks.co (via Search Engine Journal), 2026-11-05. https://www.searchenginejournal.com/businesses-treat-your-ai-agent-3-different-ways/595483/
- Websites are closing their doors to AI agents, The Verge, 2026-10-17. https://www.theverge.com/ai-artificial-intelligence/1013195/ai-agents-blocked-web
- Bank of America kindly asks that you don't share your banking password with your AI assistant, TechCrunch, 2026-10-27. https://techcrunch.com/2026/10/27/bank-of-america-kindly-asks-that-you-dont-share-your-banking-password-with-your-ai-assistant/
