核心摘要：過去二十年，我們在談論 UX（用戶體驗）和 DX（開發(fā)者體驗）。但在 Agentic AI（代理型 AI）爆發(fā)的今天，企業(yè)迎來了一批海量的“新員工”——AI 智能體。如果你的企業(yè)系統(tǒng)沒有為它們提供良好的?AX（代理體驗，Agent Experience），你收獲的將不是生產(chǎn)力飛躍，而是系統(tǒng)崩潰、失控的 API 調(diào)用賬單，以及一種全新維度的“影子 IT”。
作為企業(yè)的技術掌舵人（CIO/CDO），你可能剛剛費盡心思為員工部署了各種?AI Agent（AI智能體，以下統(tǒng)稱 AI代理），期待它們能自動編寫代碼、分析數(shù)據(jù)、執(zhí)行業(yè)務審批。
但現(xiàn)實往往是一盆冷水：這些 Agent 經(jīng)?！芭霰凇?，要么找不到正確的系統(tǒng)接口，要么讀不懂內(nèi)部的文檔，甚至因為一個報錯就陷入死循環(huán)，瘋狂向你的服務器發(fā)送請求。
為什么會這樣？因為你現(xiàn)有的 IT 基礎設施，是為“人類（需要圖形界面）”和“傳統(tǒng)軟件（需要硬編碼）”設計的，唯獨沒有為“具有自主推理能力的 AI”進行過設計。
Netlify 的 CEO Mathias Biilmann 提出了一個極具啟發(fā)性的概念：AX（代理體驗，Agent Experience）。就像 UX 決定了用戶是否喜歡用你的產(chǎn)品一樣，AX 決定了 AI Agent 能否在你的企業(yè)系統(tǒng)中順暢、安全、高效地執(zhí)行任務。
在數(shù)據(jù)與 AI 的轉(zhuǎn)型中，CIO 們必須用批判性的眼光重新審視現(xiàn)有的技術棧，并在以下四個維度迅速采取行動：
當員工發(fā)現(xiàn)公司內(nèi)部的 CMS（內(nèi)容管理系統(tǒng)）或 CRM 系統(tǒng)的“代理體驗（AX）”極差，導致他們的 AI 助手無法接入時，他們會怎么做？?他們會拋棄內(nèi)部系統(tǒng)。原文提到了一個真實的案例：一個營銷團隊直接棄用了剛花大價錢買的傳統(tǒng) CMS，轉(zhuǎn)而讓聊天機器人用簡單的 Markdown 格式直接把內(nèi)容更新到網(wǎng)站上。
CIO的批判性思考：如果你不主動改造內(nèi)部系統(tǒng)的接口讓 Agent 容易接入，業(yè)務人員就會繞過 IT 部門，去尋找對 Agent 友好的第三方外部工具。這不僅會讓內(nèi)部投資打水漂，還會引發(fā)災難級的數(shù)據(jù)資產(chǎn)流失。
很多技術團隊以為，只要給現(xiàn)有的 API 糊上一層?MCP（模型上下文協(xié)議），Agent 就能看懂了。這大錯特錯。 AI 基礎設施公司 Jentic 的 CEO 犀利地指出：“AI 需要的是上下文，而不是更多的集成膠水?！?
CIO的批判性思考：一個只會生搬硬套 API 接口的 Agent 是愚蠢的。你需要的是“上下文工程（Context Engineering）”。給 Agent 提供的不僅僅是 API 說明書，更是你們企業(yè)的業(yè)務邏輯、數(shù)據(jù)結構、甚至是過去發(fā)生過的錯誤排查日志。高質(zhì)量的 API 治理、清晰的 OpenAPI 規(guī)范，才是企業(yè) AI 能力真正的護城河。
人類遇到報錯會停下來思考，但 AI Agent 不會。 “它們會不斷嘗試，無所不用其極……它們不會停下來，甚至能讓你的服務不堪重負?！?/span>
CIO的批判性思考：代理型 AI 極度缺乏自我監(jiān)管能力。它們的設計初衷是“達成目標”，而不是“優(yōu)雅地失敗”。因此，IT 基礎架構部門必須在網(wǎng)關層建立強硬的護欄：強制執(zhí)行冪等性、重試限制、Token 消耗配額以及熔斷機制。如果不重視這一點，你月底收到的云服務和 API 調(diào)用賬單將是個天文數(shù)字。
微軟 CVP Amanda Silver 提出了一個極其精彩的理念：你需要一套“代理憲法”。 不要把商業(yè)規(guī)則隱藏在只有人類才懂的口頭默契或晦澀的舊代碼中。你需要用自然語言將企業(yè)的安全底線、審批規(guī)則、數(shù)據(jù)主權要求提取出來，變成 Agent 每次執(zhí)行任務前都必須閱讀的“元提示（Meta prompt）”。
“AI 代理只是一種恰好集成了大模型，并帶有思維鏈的服務……剝?nèi)ネ庖?，它仍然只是軟件?！?/span>
面對這場轟轟烈烈的 AI 革命，CIO 和 CDO 最該做的，不是去盲目追逐最炫酷的智能體，而是靜下心來，像過去二十年做數(shù)據(jù)治理和企業(yè)架構那樣，把系統(tǒng)的?API文檔寫清楚、把數(shù)據(jù)的權限理干凈、把業(yè)務邏輯變成機器可讀的契約。
只有當你的企業(yè)系統(tǒng)具備了頂級的 AX（代理體驗）時，那些聰明的 AI 代理，才能真正成為你麾下不知疲倦的超級員工。
摘要：UX（用戶體驗）和 DX（開發(fā)者體驗）的宗旨是構建符合用戶工作方式的系統(tǒng)和界面，從而提升用戶和開發(fā)者的效率。AX（代理體驗）則是針對 AI 代理的同等概念。
代理型人工智能（Agentic AI-或稱：AI自主智能體）的核心意義在于它能通過編寫代碼、運行腳本、執(zhí)行命令或調(diào)用?API來采取實際行動。如果這些操作從一開始就被設計得易于發(fā)現(xiàn)、文檔齊全、保持一致，并且方便代理使用，那么代理的效率將大幅提升。
AI 代理所需的信息與人類略有不同。雖然兩者都能從完整、準確、最新的文檔或包含正確命令的錯誤信息中獲益，但需求側(cè)重點不同。例如，DevOps 代理需要了解整個 CI/CD 流水線的完整上下文，而人類開發(fā)者通常不需要。
不過，從總體上看，更好地管理業(yè)務邏輯、代碼、數(shù)據(jù)、文檔、API設計、策略和最佳實踐，同樣也會造福你的人類用戶。如果你忽視了這些基礎工作，你將面臨一種全新層面的“影子 IT”風險——你的員工會轉(zhuǎn)而去使用那些他們的 AI 代理能夠順暢配合的第三方服務。
“人們正開始相信并接受代理型 AI，但要真正實現(xiàn)它，還有大量的工作要做，”Forrester 副總裁兼企業(yè)架構首席分析師 Charles Betz 說道。AI 代理需要極其精確、結構化且易于訪問的信息，而 AI 自身會放大系統(tǒng)的優(yōu)點和缺陷?！?/span>如果你的系統(tǒng)難以被理解，你最終會得到一群暈頭轉(zhuǎn)向的 AI 代理，”他補充道。
讓你的現(xiàn)有企業(yè)系統(tǒng)為迎接 AI 代理做好準備，這正是 Netlify 首席執(zhí)行官 Mathias Biilmann 所稱的?“代理體驗 (Agent Experience, AX)”的一部分。AX 指的是 AI 代理作為平臺或產(chǎn)品的“用戶”時所遭遇的體驗。
事實上，每一個產(chǎn)品和工具都已經(jīng)擁有了某種形式的“代理體驗”，因為 AI 代理已經(jīng)在嘗試使用它們?！艾F(xiàn)在的問題僅僅是：這種代理體驗是好還是壞？”Biilmann 說。
如果你希望 AI 代理能夠順暢地使用你所依賴的產(chǎn)品或服務，了解該產(chǎn)品是否具備代理所需的基礎設施至關重要。這包括：結構化且可預測的接口、全面的錯誤處理機制、用于多步驟工作流的會話持久性，以及實時反饋能力。
“代理是如何發(fā)現(xiàn)你的產(chǎn)品的？”Biilmann 問道?！笆怯脩舾嬖V它的，還是它自己推斷出這可能是一個好方案？你該如何幫助代理理解它能用你的產(chǎn)品做什么？理想情況下，你該如何讓代理輕松訪問產(chǎn)品，同時盡量減少對用戶權限的索??？然后，在整個代理的運行循環(huán)中，你該如何為它提供充足的上下文，以確保它能獲得最佳的產(chǎn)品體驗，并以最高效的方式為用戶完成任務？”
“AX”這個術語已經(jīng)在 AI 代碼代理和開發(fā)者工具提供商之間流行起來，Biilmann 預計它將變得更加廣泛適用?！半S著從代碼代理（尤其是 Claude Code）中獲得的經(jīng)驗教訓開始滲透到面向企業(yè)和消費者的代理中，”他說，“我們將看到下一層的工具和服務提供商意識到：如果我們不能與這些代理很好地配合，我們就會開始被邊緣化或繞過。” Akamai 的最新研究表明，這種轉(zhuǎn)變已經(jīng)拉開帷幕。
在企業(yè)內(nèi)部，提升 AX 意味著要打好基礎，以便將代理型 AI 與現(xiàn)有系統(tǒng)有效整合。那么，你是把它們當回事后補救措施（比如像 RPA 那樣從遺留應用程序中硬刮數(shù)據(jù)），還是確保你的工作流和工具從一開始就為?MCP(模型上下文協(xié)議)設定好了接口，從而讓代理能夠更高效地工作？
投資者們甚至已經(jīng)開始談論這些原則，將其作為對企業(yè)進行估值和預測代理主導型增長的依據(jù)。Anthropic 發(fā)布了關于如何編寫能與代理良好協(xié)作的工具的指南；微軟正在 Windows 中為代理構建具有訪問限制的新賬戶，以確保它們安全運行。甚至有一家 AI 代碼工具提供商直接棄用了他們剛花錢搭建好的 CMS（內(nèi)容管理系統(tǒng)），僅僅是因為他們的 Cursor 代碼代理無法輕松訪問它。該公司的營銷團隊發(fā)現(xiàn)，讓聊天機器人以 Markdown 格式將內(nèi)容添加到網(wǎng)站上，比使用傳統(tǒng)的 CMS 界面還要容易得多。
當然，作為一家構建 AI 代碼工具的公司，即使是 Cursor 的非技術員工也具備相當?shù)募夹g背景。在該提供商放棄 CMS 后不久，CMS 供應商就發(fā)布了一個 MCP 服務器，旨在讓代理能夠輕松創(chuàng)建、更新和管理網(wǎng)站，而無需進行如此極端的系統(tǒng)替換。但這生動地展示了 AI 代理對傳統(tǒng)軟件使用方式可能產(chǎn)生的巨大沖擊。
Biilmann 提出了打造良好 AX（代理體驗）的四個核心原則。這些原則基于：
代理是否能以正確的權限訪問系統(tǒng)；
大語言模型（LLM）是否能獲取正確的上下文以有效利用系統(tǒng)；
API、SDK 或命令行界面等工具的設計，是否允許代理將其作為接口來操作；
系統(tǒng)是否能夠輕松觸發(fā)和協(xié)調(diào)用戶偏好的代理。
“現(xiàn)在出現(xiàn)了一個名為‘上下文工程 (Context Engineering)’的全新領域，它涉及 MCP、技能 (skills)、上下文文件，以及對工具響應的微調(diào)，旨在確保代理在使用你的產(chǎn)品時擁有最準確的上下文，”他說。他舉例道，僅僅在 Netlify CLI 命令的錯誤信息中增加了一行輸出，就從根本上改變了 AX——讓代理從“無法使用該工具”變成了“能夠一次性成功部署”。
但僅僅做一個封裝了 API 的 MCP 是不夠的。“你應該把 MCP 看作是代理的 UI（用戶界面），它不僅能進行 API 調(diào)用，還能提供正確的上下文，讓代理利用你的 API 高效完成任務，”他說?！?span style="font-family: 微軟雅黑, "Microsoft YaHei"; font-size: 16px; -webkit-tap-highlight-color: rgba(0, 0, 0, 0); margin: 0px; padding: 0px; outline: 0px; max-width: 100%; color: rgb(172, 1, 249);">給它提供上下文、數(shù)據(jù)結構，以及 API 端點通常是如何組合使用的說明。”
AI 基礎設施公司 Jentic 的首席執(zhí)行官 Sean Blanchfield 也認同這一點，他表示 AI 需要的是上下文，而不是更多的“集成膠水”?！叭绻憬o LLM 提供一份設計良好、文檔清晰的 API 說明，它就已經(jīng)可以直接與之交互了，”他說?！斑@使得高質(zhì)量的 API 管理成為企業(yè) AI 能力的真正基石。現(xiàn)有在 OpenAPI、API 網(wǎng)關、身份驗證和治理方面的投資，將帶來豐厚的 AI 紅利?！?/span>
AI 代理還需要符合其規(guī)范的 API，而目前許多 API 都不符合要求。Jentic 提供的免費工具“AI 準備度記分卡 (AI Readiness Scorecard)”就是檢查這一點的有效方法。
最常見的錯誤包括：引用的鏈接失效、OpenAPI 規(guī)范中的 Schema 格式錯誤、API 沒有指明托管服務器，或者僅僅為人類開發(fā)者編寫了身份驗證信息（但這些信息無法通過 API 直接獲?。?。人類開發(fā)者也許能通過費力的手動操作繞過這些問題，但 AI 代理會因此陷入困境。
SaaS 平臺 APIContext 的首席運營官 David O’Neill 指出，單純的 API 規(guī)范并沒有“操作順序”的概念。因此，你需要使用 OpenAPI 的 Arazzo 工作流標準來對其進行編碼?！巴蝗恢g，OpenAPI 規(guī)范和 Arazzo 工作流變得至關重要，因為 MCP 和代理系統(tǒng)正是通過這些來驗證某個操作是否可行的，”他說。
Forrester 的 Betz 將這類工作稱為?“生成式引擎優(yōu)化 (Generative Engine?Optimization)”，旨在幫助代理獲取有關服務的詳細信息。
“為 API 編寫文檔、對數(shù)據(jù)和信息進行穩(wěn)健的業(yè)務定義、明確無誤地了解這些數(shù)據(jù)的存儲位置以及哪個系統(tǒng)是權威的數(shù)據(jù)源，這些都絕對是至關重要的，”他補充道?！澳銈兊臄?shù)據(jù)架構師和企業(yè)架構師在過去 20 年里一直試圖建立的所有東西，現(xiàn)在正是 AI 完成其工作所急需的素材?！?/span>
博通（Broadcom）的資深技術專家 Michael Coté 表示，大多數(shù)組織都會使用一些老舊的代碼和架構——他們既沒有準備好將其淘汰，也不想再復制它們?！澳惚仨氉屑毷崂?，并標記出哪些是你認為‘表現(xiàn)良好’的數(shù)據(jù)庫和數(shù)據(jù)架構，哪些是雖然能運行但你不喜歡的架構，”他說。
數(shù)據(jù)分析平臺 KNIME 的 IT 總監(jiān) Martin Heyder 補充道，這其中有些屬于基礎的“IT 衛(wèi)生”范疇，但依然至關重要。尤其是當你要自動化那些以前依賴員工手動從多個來源匯總數(shù)據(jù)的跨系統(tǒng)工作流時（這些數(shù)據(jù)以前甚至不需要保持實時更新或高可用性）。“如果系統(tǒng)的清單、日志或文檔本身就不可靠，任何 AI 系統(tǒng)都會毫不留情地將這些錯誤信息自動化，”他說。
此外，AI 代理在初期往往會暴露出組織中依賴“隱性知識”運作的盲區(qū)。因此，跨代碼庫建立標準、強制執(zhí)行代碼審查，并為系統(tǒng)定義和文檔保留單一的參考源，能為 AI 代理提供一個極其友好的操作框架。
微軟負責應用和代理的 CVP（企業(yè)副總裁）Amanda Silver 將其稱為?“代理憲法 (Agentic Constitution)”。這是一種使用自然語言來規(guī)定組織或代碼庫中常見需求或期望的方法?！澳惚仨毚_保 AI 代理始終將這些規(guī)則置于其上下文之中，”她說。
這一概念可以應用得更加廣泛，甚至作為一種“元提示 (Meta prompt)”。它可以在代理需要管理身份權限、創(chuàng)建“人機協(xié)同 (Human-in-the-loop)”界面，或者構建允許你觀察代理操作日志的系統(tǒng)時，為其規(guī)定具體的行為方式。
針對現(xiàn)有基礎設施的身份認證、訪問管理和權限控制是重中之重。大多數(shù)組織可能需要從盤點資產(chǎn)開始，確保他們清楚了解所有希望 AI 代理與之交互的系統(tǒng)，并在必要時能夠?qū)ζ溥M行更新。
這可能意味著企業(yè)需要添加新的 API，甚至替換掉那些核心邏輯和用戶界面嚴重耦合的遺留應用程序。因為對于 AI 代理來說，使用內(nèi)置了 API 或采用了可組合無頭架構（Headless architectures）的 SaaS 應用要容易得多。例如，IDC 接觸的組織中，有近 30% 正在研究如何實現(xiàn)其整個軟件組合的現(xiàn)代化，以便更好地利用 AI 和代理。
“AI 代理能夠?qū)崿F(xiàn)最高投資回報率 (ROI) 的任務是后端工作流的處理，”Silver 說。“你可能會使用像 MCP 這樣的協(xié)議向代理暴露數(shù)據(jù)，但這并不意味著它們就能采取行動。你需要思考：你想要自動化哪些動作？你可以將哪些動作作為工具暴露給代理？它們能調(diào)用哪些接口，從而實現(xiàn)從意圖、到計劃、再到實際執(zhí)行和行動的完整閉環(huán)？”
如果你希望 AI 代理在解決系統(tǒng)故障時發(fā)揮作用，它們就需要訪問 API，以便將信息添加到你們匯總事件詳情的儀表板中。工作流也需要將代理納入其中，以便它們能夠訂閱關鍵事件（比如訂單是否已發(fā)貨、發(fā)票是否存在爭議），并能夠觸發(fā)正確的后續(xù)操作。
此外，現(xiàn)有的業(yè)務政策可能被硬編碼在系統(tǒng)里，而不是以書面形式記錄?，F(xiàn)在需要將它們提取為代理可以訪問的自然語言政策文檔。隨著組織開始使用更多的代理，Silver 認為他們不僅需要覆蓋整個工作流的順序編排（Sequential orchestration），還需要進行“對抗性評估 (Adversarial evaluation)”。因為復雜的工作流可能需要遵循多個相互制約的政策，它們都在試圖實現(xiàn)特定的結果?！盀榱私鉀Q這個問題，你可能會實施帶有政策約束的多代理編排。你可以向多個‘專家代理’進行咨詢，然后讓這些專家代理回來做出最終的判斷，從而滿足用自然語言編碼的多種政策要求?！?/span>
早期的采用者已經(jīng)發(fā)現(xiàn)，AI 代理可能是“無情”的，并且極易發(fā)出海量的并發(fā)查詢?！八鼈儠粩鄧L試，無所不用其極，”Biilmann 說。“它們不知道停下來，甚至可能會讓你的服務不堪重負而崩潰。”如果你無法重新設計 API 讓其返回操作提示（比如因為該 API 是第三方的），你就必須在自己這端實施配額限制或?qū)Σ樵冞M行優(yōu)先級排序。
“我認為未來將會出現(xiàn)大量人工創(chuàng)建的‘場景護欄’，因為代理型 AI 在自我約束方面表現(xiàn)得非常糟糕，”O(jiān)’Neil 說。“它的設計初衷是不達目的誓不罷休，而不是在遇到挫折時自動關閉。”
Betz 補充道，為了防止 API 被失控或重復消耗，必須強制執(zhí)行冪等性（Idempotence）、重試機制、配額和訪問限制?！癆I 代理并不是無限的資源，如果它們無法獲得正確的答案，它們必須知道什么時候該放棄嘗試，”他說。
注：冪等性（Idempotence）
定義：同一操作執(zhí)行 1次或N次，對系統(tǒng)狀態(tài)的影響完全相同（數(shù)學表達：f(f(x)) = f(x)）。
為什么重要：分布式系統(tǒng)中網(wǎng)絡抖動、超時易導致重復請求。若操作非冪等，將引發(fā)數(shù)據(jù)錯亂（如重復扣款、重復創(chuàng)建訂單）。
典型場景：
? 冪等：HTTP GET（查詢）、PUT（用唯一ID更新）、DELETE（刪除已存在資源）
? 非冪等：HTTP POST（每次創(chuàng)建新資源）、計數(shù)器+1
實現(xiàn)方案：
客戶端生成唯一 Request-ID，服務端校驗是否已處理
業(yè)務層加鎖/狀態(tài)機（如“訂單狀態(tài)=已支付”則跳過）
數(shù)據(jù)庫唯一索引（防重復插入）
?? 示例：支付接口以“訂單號+用戶ID"為冪等鍵，重復請求直接返回原結果。
Silver 表示，AI 治理的一部分就是清楚地了解哪些 MCP 是向代理開放的?！澳憧梢噪S時撤銷它們對特定 MCP 的訪問權限，管理其 Token（算力代幣）的消耗，并強制執(zhí)行對你和你的組織有意義的治理策略，”她說。
Biilmann 指出，AX（代理體驗）和 UX（用戶體驗）是一門類似的學科，它同樣是迭代的，核心都在于深刻理解用戶（或代理）到底想要完成什么任務?！澳惚仨毥M建一個專門的團隊來進行研究，找出問題和機遇，”他說。這意味著你需要查看代理的會話回放、識別導致代理失敗的行為，并構建更友好的響應和接口來幫助它們?nèi)〉贸晒Α?/span>
隨著代理底層的 AI 模型不斷進化，Netlify 發(fā)現(xiàn)他們不再需要像以前那樣嚴重依賴添加上下文文件來引導代理訪問最新的 API。但這只意味著問題變成了移動的靶子?！澳惚仨毭鎸σ慌碌拇硎鼙?，不斷地與它們磨合和迭代，”他說。
O’Neill 表示，那些已經(jīng)在使用 MCP 的 APIContext 用戶發(fā)現(xiàn)：事務的數(shù)量、涉及的 API，甚至代理使用的具體服務，都可能發(fā)生出乎意料的變化。“當 MCP 返回的服務發(fā)生了改變，代理就會嘗試用另一種完全不同的方式去創(chuàng)建記錄，而舊的路徑就行不通了，”他說?！斑@不像傳統(tǒng)的 API 網(wǎng)關，所有東西都是你事先定義好的。它更像是一個黑匣子，只是簡單地甩給你一份可用的工具清單。”
一種新型的 MCP 服務器性能監(jiān)控工具可以讓你檢查和設置警報，并基于性能閾值、規(guī)范要求、網(wǎng)絡功能，甚至是為了滿足數(shù)據(jù)主權的數(shù)據(jù)傳輸規(guī)則，來創(chuàng)建治理策略。AI 代理要求我們對 API 管理傾注前所未有的關注?！斑@將迫使人們極其認真地對待 API 治理，”O(jiān)’Neill 補充道。
此外，Betz 建議，除了治理工具、監(jiān)控和可觀測性平臺之外，還要依靠你的 API 網(wǎng)關?！罢f到底，AI 代理只是一種恰好集成了大語言模型（LLM），并帶有一些思維鏈（Chain of Thought）、意圖管理和目標導向行為的服務而已，”他說?！皠?nèi)ネ庖拢匀恢皇擒浖??！?/span>
這意味著企業(yè)的日志記錄基礎設施將承受巨大的壓力?！叭绻闳鎿肀Т硇?AI，并試圖追蹤所有的代理活動，你會發(fā)現(xiàn)這些網(wǎng)絡流量會以某種高度非確定性的方式在系統(tǒng)中瘋狂跳躍，”他說。Silver 表示，歸根結底，衡量 AI 代理是否成功，不僅關乎最終的產(chǎn)出結果，也關乎整個過程的可觀測性（Observability）?！半S著時間的推移，你需要評估代理是否真的按照你的意圖執(zhí)行了操作，同時更要確保它沒有在執(zhí)行過程中完全脫軌，”她說。
微軟已經(jīng)在其站點可靠性工程（SRE）中廣泛使用了 AI 代理，以降低響應線上故障的成本并縮短修復時間。“為了做到這一點，你需要擁有貼好標簽、帶有時間戳、且完全可追溯的數(shù)據(jù)供你審查，”她補充道?！澳氵€需要擁有豐富、結構化的信號，并且從結果導向的視角出發(fā)，極其清晰地界定什么是‘好’、什么是‘壞’。”
