一篇大模型Agent工具使用全面研究綜述
由于上面提到的一些問題可能會在短時間內成為現實，因此現在就應該開始準備，其中可能涉及以下主題：
這些步驟做得越多，當出現 API 需求時，實施起來就越快越容易。
理想情況下，這些準備工作應該做到能夠證明潛在的應用程序接口請求是合理的，而不是主動推動應用程序接口的使用。
市場上有各種解決方案，大致可分為以下幾種：
純粹的應用程序接口解決方案不提供經典的集成技術，或僅通過擴展提供這些技術，而 “一體化 “解決方案則將所有技術整合到一個平臺上，實現無縫互動。
而這正是許多公司面臨的最大挑戰。通常情況下，并非所有相關組件（如應用程序）都已與 API 兼容。有些組件由于成本過高或技術上不可行，永遠無法實現 API 兼容。
只能為應用程序接口提供服務的集成解決方案將受到極大限制，甚至對某些任務毫無用處。純粹的 API 解決方案本質上是另一個獨立系統。
而將 API 活動與集成任務相結合的集成解決方案則能為您提供無限的功能。從本質上講，應用程序接口可以被視為一種信封，您可以在其中裝入任何想要的東西。
舉幾個例子：
應用程序接口與非應用程序接口兼容組件的交互提供了許多選擇。同時，還需要考慮一些主題：
非 API 兼容組件的可用性
如果一項服務（如網站或智能手機應用程序）需要全天候可用，那么其底層組件也需要全天候可用。如果無法保證這一點，則應提供適當的錯誤信息（如 “尊敬的用戶，由于維護原因，我們的服務目前不可用”，這比 “500 – 內部服務器錯誤 “等技術信息要好得多）。
非 API 兼容組件的性能
在應用程序接口內進行的任何活動都需要時間。這種時間會增加向應用程序接口發出的任何請求的響應時間。如果期望 API 的響應時間不超過 100 毫秒，而為 API 提供信息的后臺系統的響應時間卻達到 2 秒，那么這種期望就根本無法實現。您還需要檢查多個并行調用是否會進一步減慢響應時間。
到目前為止，還沒有出現從傳統集成或 EDI 向應用程序接口轉變的巨大浪潮。這可能是因為許多正在使用的接口已經非常成熟，而改變總是伴隨著成本和風險。
盡管如此，通過集成和使用應用程序接口來創造價值的趨勢在各個領域都非常明顯，無論是其實時處理能力還是抽象、統一接口層的優勢。
因此，對應用程序接口的明確建議是 “行動 “而不是 “反應”。這樣，您就已經為每個 IT 部門遲早需要考慮的問題做好了準備。
原文鏈接：New best friends: APIs and Integration
