AI應用即智慧體：探索從Composer到Manus下的正規化演進

2025-04-29 05:08 phodal

簡單來說：
AI 應用即智慧體是將多個 AI 功能模組（智慧體）整合起來，透過服務化的方式（如 API）提供給 AI，使其能夠智慧體能夠相關互動一樣， 利用其它 Agent 的能力來完成各種複雜的任務。
在先前的兩個 AutoDev 新功能中，我們引入了兩個新的 AI 功能：AutoDev MCP 和 AutoDev Planner。當我們在探索如何將這兩個功能結合到更多的 階段時，我們發現了一個更大的正規化演進：AI 應用即智慧體。
簡單來說，在兩個場景結合之下，你可以呼叫 AutoDev 上的一系列 AI Agents，然後完成你的任務。哪怕你不會寫程式碼，你也可以呼叫 AI 來生成業務 邏輯、分析歷史需求、生成設計文件等。
我們將在這篇文章中，探索這個正規化演進，並且展示如何將這個正規化應用到更多的場景中。

一個小的嘗試：AutoDev Planner 即服務

在 MCP 模式之下，各類的桌面工具都可以被服務化，IDE 也不例外。基於我們在 AutoDev 提供的 MCP 服務能力，使用者可以透過 MCP API 來呼叫 AutoDev 上的 AI 能力。

一個簡單的 AutoDev MCP 資料庫示例

我們在 AutoDev 中提供了大量的基於 IDE 能力的 API 封裝，除了使用 DevIn 指令來呼叫；這些能力，還可以透過 MCP API 來呼叫。比如， 你透過如下的 MCP API 呼叫，就可以獲取當前資料庫的 schema：
  1. curl -X POST "http://127.0.0.1:63342/api/mcp/get_current_database_schema"
當用戶連線了資料庫之後，就會返回對應的資料庫資訊。如果你需要進一步的操作，比如建立表、插入資料等，未來也可以透過 MCP API 來呼叫。這就意味著， 你可以說一句話，就可以完成一系列的資料庫操作，以及對應的資料庫操作。
這就意味著，我們還可以呼叫 AutoDev 上的一系列的 AI Agent 能力，比如：AutoDev Sketch、AutoDev Bridge 等。

複雜一點的示例：呼叫 AutoDev 上的 AI Agent

考慮一個情景，你作為開發者接到一個新的系統設計需求，比如“設計一個新的使用者登入模組”。你就可以透過以下的 API 呼叫來開始任務拆解，找到關鍵的核心 程式碼，不再需要複雜的、無用的 AI 程式碼 RAG。你可以呼叫 AutoDev Sketch 來幫助實現對應的任務拆解能力。諸如於：
  1. ➜~ curl -X POST "http://127.0.0.1:63342/api/mcp/issue_or_story_evaluate" \
  2. -H "Content-Type: application/json" \
  3. -d '{"issue": "檢索程式碼庫，總結 Sketch 的工作流程"}'
  4. {
  5. "status":"1. 定位核心工作流類\n - [✓] 搜尋包含 \"Workflow\" 和 \"Sketch\" 的類定義\n - [✓] 分析 SketchRunner 的 execute 方法\n2. 解析 AI Flow 執行階段\n - [✓] 識別上下文收集階段\n - [✓] 分析工具呼叫決策模組\n - [✓] 跟蹤程式碼生成流水線\n3. 驗證工作流程完整性\n - [✓] 檢查異常處理機制\n - [✓] 確認版本控制整合點"
  6. }
那麼，你就有了一個初步的如何實現這個任務的思路：
  1. 定位核心工作流類
    • [✓] 搜尋包含 "Workflow" 和 "Sketch" 的類定義
    • [✓] 分析 SketchRunner 的 execute 方法
  2. 解析 AI Flow 執行階段
    • [✓] 識別上下文收集階段
    • [✓] 分析工具呼叫決策模組
    • [✓] 跟蹤程式碼生成流水線
  3. 驗證工作流程完整性
    • [✓] 檢查異常處理機制
    • [✓] 確認版本控制整合點
詳細可以見，我們提供的 AutoDev 示例：https://ide.unitmesh.cc/mcp/mcp-server.html

再向前一步：解決一個更大的問題 – 需求分析

進一步地，我們不僅可以拆解任務，還能夠依賴智慧體來執行這些任務。例如，當任務拆解之後，我們可以呼叫 AutoDev 中的 AI Agent 來幫助完成具體的開發工作。例如，在上述的任務拆解後，呼叫 AutoDevSketch 來生成設計文件，彙報流程圖。如下是對應的分析示例：
  1. 1.分析部落格建立流程涉及的程式碼元件
  2. -[x]檢視BlogController的POST方法
  3. -[x]分析BlogService的createBlog方法
  4. -[x]確認資料庫表結構（blog表）
  5. 2.設計Mermaid流程圖元素
  6. -[x]使用者請求入口（POST /blog/）
  7. -[x] DTO轉換過程（CreateBlogRequest->BlogPost）
  8. -[x]資料庫儲存操作（BlogRepository.save）
  9. -[x]響應返回流程（BlogPost->CreateBlogResponse）
  10. 3.生成Mermaid程式碼
  11. -[x]按順序連線各元件
  12. -[x]新增關鍵方法呼叫標註
而在現在的 AI IDE 模式之下，你需要：
  • 歷史需求分析：上傳歷史需求文件，結合 RAG 進行分析
  • 獲取程式碼上下文：下載程式碼、開啟專案、開啟聊天輸入內容等，最後總結到相關上下文
  • 生成設計文件：呼叫 AutoDev Sketch，生成設計文件
現在將 AI 應用變成可呼叫的能力之後，這個問題就變得非常簡單。你只需要一個 Agent 的 Agent 就可以了。

Agent 的 Agent：AI 應用即智慧體

在當前主流的模式之下，你會有一個類似於 Manus 這樣的入口，然後透過 Manus 來呼叫各類的 AI Agent。而在我們的正規化之下，作為一個 AI Agent，為了 獲取更好的上下文，你可以呼叫另一個 AI Agent 來獲取上下文，哪怕是 Manus 的 Agent。
AI 應用即智慧體是將多個 AI 功能模組（智慧體）整合起來，透過服務化的方式（如 API）提供給 AI，使其能夠智慧體能夠相關互動一樣， 利用其它 Agent 的能力來完成各種複雜的任務。
在 AutoDev 這一類 AI 輔助研發的場景之下，AI 應用即智慧體的核心特徵包括：
  • AI 能力服務化介面：透過 API 或其他標準化介面，智慧體的能力可以被外部系統或使用者呼叫，實現無縫整合。
  • 內部任務自動化：智慧體能夠根據使用者需求自動拆解任務並執行，例如生成程式碼、分析需求、設計文件等。
  • 協作性：智慧體不僅能夠獨立完成任務，還可以與開發者或其他智慧體協作，共同推動專案進展。
PS：感謝 DeepSeek 幫我總結。

Agent 正規化演進：無處不在 Agent 及其能力邊界

基於這個正規化，我們可以思考如何將 AI 應用的能力無限擴充套件，比如你的 AI Agent 作為死去 “中臺”（過去的熱詞）的延續。

忘記中臺吧，它死了好久了

我們總是需要一個所有的 Agent 能力中心的，它反正叫什麼都行，總不可能叫 Agent 中臺吧。
現在，讓我們討論一下  OpenAPI Agent 正規化演進。

Agent 的語言化 OpenAPI 設計

現在基於 Agent 的 API 還是那麼幾種：Function Calling、MCP 等，其實都大差不差：
  • API 文字描述：name, description
  • 輸入輸出定義（Schema）：parameters, return
和先前各種平臺開放 API 的設計，唯一的區別是多了一個 description 欄位。這個欄位是用來描述這個 API 的功能，以及如何使用的。以讓其它 AI Agent 能夠更好地呼叫。

回憶一下微服務的服務發現

服務發現（Service Discovery）是指在分散式系統中，服務能夠自動地識別和定位到彼此的網路地址（通常是 IP 地址和埠號）的過程。
微 Agent 的 Agent 發現是微 Agent 架構中至關重要的一個環節。在傳統的單體應用中，Agent 之間的呼叫通常是直接的方法呼叫，但在微 Agent 架構中， 不同的服務執行在不同的程序甚至不同的伺服器上，它們需要一種機制來找到彼此的網路地址（Agent 描述和服務地址）才能進行通訊。

許可權控制：Agent 的能力邊界

真是一個頭疼的問題，我的 AI 應該能訪問哪些系統，不應該訪問哪些系統呢？想一想，我們這些帶工號的員工，都有哪些許可權呢？誰來分配這些許可權呢？
所以，你的每個 AI Agent 都是有許可權的“員工”，那麼自然而然問題就會迎刃而解。

忘記新正規化吧，它落地不了

好吧，我們要承認一點，儘管新的技術很好，新的正規化非常好，但是我們還是需要考慮到現實的問題。落地的時候，總是要面臨組織邊界的挑戰。

總結

哦，對了 AutoDev 文件在這裡：https://ide.unitmesh.cc/mcp/mcp-server.html


相關文章