一家公司花心思撰写的開發文檔，下次打開它的可能就是準備替用戶調用接口的智能體了。Mintlify在10月27日發布的[合作公告](https://press.aboutamazon.com /aws/2026/10/mintlify-taps-aws-to-deliver-billions-of-agent-visits-with-99-999-uptime-launches-enterprise-offering-in-aws-marketplace)中稱，其托管的文檔流量已有超過四分之三來自AI智能體；同日，Mintlify Enterprise進入了AWS Marketplace。機器讀者的增加與企業采購入口的落實，被放在同一份發布資料中。

這兩件事連在一起，改變了文檔平台的銷售理由。過去，企業購買文檔工具，主要是為了讓開發者更容易找到答案。現在，文檔還參與到智能體對產品的理解和選擇中。如果參數、權限條件或調用步驟的解釋不清晰，問題可能會在用戶看到產品之前就出現了。

公告披露，過去一年該平台服務了超過3億人類訪客與20億次智能體訪問。這些數字由公司提供，且「訪客」與「訪問」的定義不同，因此無法用來計算人與機器之間的數量比例。超過四分之三的流量佔比，也僅針對 Mintlify 所承載的文檔，無法代表整個互聯網。

採購路徑比另一個編輯按鈕還具體

對於企業買方而言，公告中較容易實現的變化在於採購渠道。通過 AWS Marketplace 購買的 Enterprise 版本可提供 SSO、高級安全控制、自定條款以及私人報價；已與 Mintlify 談判的客戶，可以申請私人報價，並將采購流程完成於自己的 AWS 賬戶之下。

一名業務負責人可能已經確認這個工具很好用，但項目仍需經過合約、安全及賬單流程。這個新的入口將產品帶入了企業熟悉的采購途徑。它沒有公開承諾每家客戶能節省多少時間，也沒有將採用自動化變成批准，但它減少了供應商必須從頭解釋如何成交的部分工作。

平台也将可靠性纳入這筆交易中，宣稱運行在 AWS 上的服務達到99.999%的可用性。這個數字應該被視為供應商公開的運行指標；公告並未提供足夠的信息，讓買方能據此推導出自己的 SLA、故障賠償或單個站點的保證。在購買基礎設施時，將歷史運行表現與合同義務分開，才能比較真實地評估交付情況。

對於采購團隊，Marketplace還改變了誰先參與評估的規則。該工具不再只是由開發團隊試用後再單獨簽約，而是可以融入企業已有的雲支出、供應商審查和預算歸集流程中。SSO解決的是接入條件，而私有報價和自定條款解決的是成交方式，這兩組能力解決的並非同一個問題。只有當技術接入和商業采購都能通過之後，公告中的「企業版本」才會成為客戶可以真正部署的服務。

對於文檔負責人來說，機器流量的上升也帶來了更具體的維護要求。頁面結構、參數名稱、權限前提和示例代碼一旦相互矛盾，智能體就可能將錯誤的步驟帶入後續任務中；這類問題不必然會表現為頁面打不開。因此，可用性指標只能說明服務是否在線，無法替代內容是否準確、版本是否同步以及示例是否仍能執行。公告所披露的只是訪問規模和基礎設施的表現，內容質量仍需產品團隊自己負責。

文件開始參與產品被選擇的過程

文件中的角色變化，已經超出了單純查閱資料的範圍。當人們發現某個示範例子過時之後，可以另尋客戶服務；而被委託完成任務的智能體，則需要從頁面中判斷下一步該如何行動。因此，產品知識的重點也從售後說明，轉移到了使用過程的前端（即用戶界面）。

這是根据使用路徑所作的分析，尚不能推導出文檔訪問量與收入之間的因果關係。機器可能反複抓取同一內容，訪問很多次也未必會購買。Mintlify預計年底智能體流量佔比可達90%，那仍是預測，不能提前寫成結果。

對於軟件企業而言，這次的上線提供了一個可執行的選擇：將文檔平台納入現有的雲采購體系中，再檢查自身的知識是否足以供人和機器共同使用。變化首先發生在接觸點——智能體越來越早地接觸文檔，采購部門也獲得了一個現成的成交渠道。只有當兩端都能順利運作時，文檔才有可能從“發布後再補充”，變成產品交付時必須維護的必要部分。