當獨立的API相互連接時，它們變得極為強大。無論是與外部客戶的互動、內部使用還是常規的端到端測試，幾乎所有的在線交互實際上都是由相互連接的API網絡構成的“流程”。這種相互連接是數字產品體驗的核心。

與API的強大能力相提并論，大型語言模型（LLMs） 展現出了令人矚目的推理能力，它們在解決問題時的迭代思維過程與人類非常相似。LLMs在進行重復迭代時展現出的能力，使其成為計算推理中的強大工具，特別是在形成“流程”的重復迭代中。

認識FlowTestAI

FlowTestAI的創新核心是將這兩個強大領域結合起來。FlowTestAI是世界上首個由GenAI驅動的開源集成開發環境（IDE），專為設計、可視化和管理API優先的工作流而設計。它以快速、輕量級和本地操作為特點，在促進API優先工作流的無縫整合的同時，也保護了用戶隱私。

解決測試難題

測試是產品開發中一個至關重要但分散的環節。缺乏全面和強大的端到端測試會嚴重影響產品的質量，并減緩開發速度。

端到端測試本質上是基于API的工作流。理想的框架應該允許快速、直接地生成這些工作流，并能夠高效地管理它們。然而，目前的做法常常因為過多的樣板代碼、繁瑣的管理層次和與實際開發實踐的脫節而受到影響。這導致了緩慢且復雜的端到端測試，嚴重影響了開發速度。

有效的測試還需要安全地訪問和管理敏感信息，比如訪問ID和密鑰。遺憾的是，目前還沒有工具能夠確保這一領域的安全性。使用像Postman這樣的傳統平臺輸入憑據可能會使它們面臨風險。此外，缺乏一個專門的環境讓開發者能夠安全地測試開發中或私有API，將這些API引入常用在線工具可能會無意中導致信息泄露。這一問題凸顯了對一種提供安全、本地沙箱測試解決方案的需求。

FlowTestAI的解決方案

FlowTestAI利用LLMs的推理能力、git（或任何版本控制系統）的組織優勢以及圖數據表示的結構優勢，旨在徹底改變API優先工作流的生成和管理方式。

1. 生成：用自然語言描述你的工作流，我們的平臺會迅速將其轉換成可運行的API工作流。或者，你也可以通過拖放OpenAPI規范中的節點來構建你的工作流。
2. 管理：像傳統的IDE一樣，FlowTestAI在本地文件系統上存儲和管理所有內容。團隊可以使用任何與git兼容的工具或版本控制系統進行協作。
3. 隱私：所有內容都存儲在你的本地文件系統中，FlowTestAI允許你安全地使用私有或開發中的API端點。平臺會在本地安全地存儲憑據，保護它們免受外部威脅。
4. 可視化：FlowTestAI通過提供無代碼的圖形化API優先工作流表示，消除了測試和開發團隊之間的隔閡，為整個組織提供了統一的視角或單一真相來源，有助于加快開發速度。
5. 速度：FlowTestAI輸出的API優先工作流沒有任何樣板或不必要代碼，這使得執行時間更快，從而提高了開發速度。

未來展望

將端到端測試視為API優先的工作流只是開始。這個工具被設計得非常通用，可以創建任何API優先的工作流，并可以設置為定期自動運行。例如，可以創建一個工作流，它檢查JIRA中的前10個客戶支持票據，將其發送給ChatGPT進行總結，并每天自動發布到工程團隊的slack頻道。

由于這個項目是免費和開源的，任何人都可以創建并提交帶有自定義邏輯的自定義節點，并與社區分享。你也可以創建自定義流程并提交給其他人使用。例如，一個自定義流程可以使用LLM的輸出作為輸入，將其發送到AWS或Azure上托管的情感分析工具的API，檢查輸出的正面得分是否大于0.7，然后只有當得分高于0.7時，才將該輸入轉發到圖中的其余部分或最終用戶。

每個工作流都可以視為一個可以被使用并嵌套在其他工作流中的實用工具。

FlowTestAI如何運作

FlowTestAI主要由以下兩部分組成：

體驗

對于用戶體驗，我們提供了一個集成開發體驗（IDE），類似于VS Code、IntelliJ等，作為一個electron應用程序。所有操作都在本地進行，就像傳統的IDE一樣，實現雙向通信。你在IDE中執行的任何CRUD操作都會實時更新到本地磁盤，反之亦然。

它是這樣工作的

AI

AI管道包含三個主要階段：

預處理

LangChain在這里對我們非常有幫助。首先，我們來理解問題。OpenAPI規范可能非常龐大，包含數千個API（也稱為函數），而現有的LLMs只能處理有限數量的函數作為參考輸入，例如OpenAI GPT 3.5 turbo只能處理128個函數。

我們首先從規范中提取每個API的{API_NAME, API_DESCRIPTION}，構建一個大文檔。然后，使用LangChain的文本分割器，根據LLM的容量將文檔分割成多個小塊。例如，對于GPT 3.5 turbo，我們將文檔分成32個函數的小塊。接著，我們使用LangChain對OPENAI嵌入API的封裝，將每個小塊嵌入并存儲在LangChain提供的內存中向量數據庫中。

通過這種方式，我們實際上是在為結構化函數重構RAG的解決方案，這通常用于文本輸入。

處理

接下來，我們取用戶提示，對LangChain支持的內存向量數據庫進行相似性搜索，提取滿足LLM輸入限制的m個文檔。例如，如果我們以前面的32個函數為例，我們會提取4個文檔，以滿足32 x 4 = 128的限制。

然后，我們將這些函數和用戶指令作為輸入提供給LLM。我們迭代地執行這個過程，直到確定沒有更多的操作要執行。每次迭代都會輸出一個函數調用。

后處理

在前一步輸出的函數調用集上執行后處理。我們設置了適當的護欄，以確保LLM在任何步驟中產生幻覺時，我們會過濾掉這部分輸出，避免誤導用戶。然后，我們將每個有效的函數調用解析并轉換為我們的內部圖節點，為API調用所需的查詢參數、請求體等分配適當的值。最后，我們將它們鏈接起來，形成一個可運行的工作流。

一些關鍵點：

1. Langchain為LLM管道構建提供了廣泛的功能，使得分割、嵌入、存儲和搜索內存向量數據庫中的數據變得簡單，只需幾行代碼即可完成。
2. 我們向LLM傳遞的信息非常有限，但足夠，以避免在用戶不希望過多暴露他們的API規范的情況下，向LLM泄露太多信息。
3. 一旦我們從LLM得到輸出，它就會被解析、鏈接并渲染為可運行的圖，供用戶使用，圖中的每個節點代表一個帶有預填查詢或路徑參數或請求體的API請求，每個邊緣代表下一個操作。用戶現在可以運行、修改并保存它。
4. LLMs有時會產生幻覺，我們已經設置了適當的護欄，以確保如果LLM產生幻覺，我們會過濾掉這部分輸出。
5. 我們正在努力集成其他LLMs，如Gemini等。
6. 我們很快將推出AI驅動的生成日志摘要功能，以便在運行工作流時更容易發現流程中斷的位置。

演示

步驟1：選擇OPENAI模型并添加你的指令

步驟2：點擊生成，一個可運行的圖將輸出，其中API請求被鏈接在一起，每個請求都預填了正確的請求參數和請求體。

步驟3：點擊運行，查看每個請求的日志以及流程結束時的總時間。

步驟4：添加額外的邏輯節點，使圖更加豐富。

結論

FlowTestAI將讓端到端測試進化為可視化API工作流，這些工作流快速生成、無縫管理，并且比傳統測試快得多，從而實現高開發速度。

項目鏈接：??https://github.com/FlowTestAI/FlowTest??

本文轉載自?? AI小智??，作者：