讓 agent 也能 onboarding：企業 AI 平台該為人與 agent 各開一扇門
越來越多產品是被 AI agent 先發現、先評估、先接上的。企業 AI 平台需要兩條 onboarding 路徑：給人的承諾與控制，給 agent 的可讀文件與明確的權限邊界。
Agent onboarding 是讓 AI agent 能自行讀懂、評估並接上一個產品的流程：用 llms.txt 與 Markdown 版本讓 agent 讀得到內容，用受限模式或人類核准控制憑證，並讓人看得到 agent 會做什麼、什麼一定先問人。
產品的使用者正在多出一種：替人辦事的 AI agent。AgentMail 的工程團隊在推出 agent.email 時寫道，他們觀察到 agent 會自己發現工具、評估工具並決定採用，因此需要為 agent 設計的註冊路徑，而不是只給開發者的文件。Moltbook 則更直接，首頁只有兩顆按鈕：「I'm a Human」與「I'm an Agent」。對企業 AI 平台來說，這代表 onboarding 至少要服務兩種讀者：評估導入的決策者與開發者，以及被他們派來「幫我接上 X」的 coding agent。
多數網站對 agent 並不友善，而且問題常常不在設計而在結構。單頁應用（SPA）的首頁在伺服器端只回傳一個空的 root 節點，agent 不執行 JavaScript 就讀不到任何文案；找不到的 llms.txt 被 fallback 成首頁 HTML 並回 200，agent 會以為自己讀到了索引；文件寫得再好，agent 拿不到憑證時任務仍然卡死。這些都不是視覺細節，而是 agent 能不能完成任務的差別。
第一扇門是可讀性。llms.txt v2 建議以標準 link relation 讓 agent 找到內容：rel="alternate" type="text/markdown" 指向頁面的 Markdown 版本，rel="describedby" 指向涵蓋該頁的 llms.txt，可以寫在 HTML 的 link 元素，也可以用 HTTP Link header。v2 也明說 agent 的實際用法是先看或搜尋 llms.txt、再跟著連結讀，所以每個連結指到的內容本身都要是乾淨的 Markdown。人看 HTML、agent 讀 Markdown，但兩邊的指令文字必須逐字一致，不能藏只給 agent 看的字。
第二扇門是憑證。agent.email 的做法是讓 agent 用主人的 email 自助註冊、立即拿到 API key，但帳號先進入受限模式，只能寄信給主人；主人用驗證碼認領後才解除限制。企業平台不一定要開放自助註冊，另一種同樣清楚的設計是「人要介入」：agent 可以讀文件、確認能否接上、擬好申請，但 key 只由組織管理員發放。不論選哪一種，都要把「人認領或核准之前，agent 能做什麼」寫成清單，那份清單就是安全邊界。
第三扇門是給人的那一面。人點進寫給 agent 的頁面時，通常是要把網址交給自己的 agent，或想先知道 agent 會被叫去做什麼。這一頁應該依序呈現：要貼給 agent 的一句話、agent 會做的事、取得 key 前能做的事、一定先問人的事、人會收到什麼與去哪裡撤銷，以及可展開的 agent 原文與版本號。HCI 研究支持這個順序：Cai 等人在 CSCW 2019 的研究發現，使用者在開始用 AI 之前最想知道的是它整體的強項與限制；〈Why Johnny Can't Use Agents〉分析 102 個商用 agent、觀察 31 位受試者後指出，agent 常在沒建立可信度的情況下就預設被信任。
可以用五個問題檢查自己的平台：用 curl 抓首頁，讀得到標題與主要文案嗎？/llms.txt 回的是 text/plain 而且第一個連結就是給 agent 的說明嗎？不存在的 .md 會回 404 而不是首頁嗎？人類版與 Markdown 版的指令逐字相同嗎？每一個需要人確認的動作，都同時列在人類版與 agent 版嗎？五題都答得出來，agent onboarding 才算真的可以運作。
X Cube 的 API 已提供 /v1/llms.txt 與 /v1/openapi.json，API key 由組織管理員發放、不開放 agent 自助註冊。我們正把同樣的原則用在 X Cube 網站本身：根目錄 llms.txt、給 agent 的說明頁，以及人能看見 agent 會做什麼的對照頁。
