ArchGuard Co-mate：大語言模型與架構治理、架構設計的探索

在過去的幾個月裡，為了探索了 LLM 結合 SDLC、BizDevOps 的可能性，我們（Thoughtworks 開源社群）建立了 ClickPrompt、 AutoDev、DevTi 等一系列的開源項目。從個人的經驗來看，未來越來越多的應用将圍繞于 LLM@Core 設計，是以我們挖了一個新的坑、新的試驗：ArchGuard Co-mate：https://github.com/archguard/comate，歡迎來入坑一起探索和研究。

Why is Co-mate ？

我們發起 Co-mate 項目的原因，可以歸于：在 LLM 優先的應用開發時代，掌握相關的開發技能。這些相關的技能包含但是不限于：

• 探索是否存在更好的互動模？如基于 Chat 的動态 UI（DSL）生成 等。
• 适用于 JVM 體系下的 LLM 應用開發？如 JVM 版 LangChain、Embedding 等。
• 如何輔助上下文了解、建構的本地小模型？即 Sentence Transformer + ONNX 的本地處理。
• 如何設計新一代、适用于 LLM 的軟體 API？即如何以确定性的方式與 ArchGuard API 互動。
• 如何更好地建構上下文，以工程化的方式建構 AI 應用的上下文（即 prompt）？

而出于架構治理的場景，我們則是想探索：

• 如何讓 LLM 解釋軟體架構給人聽？畢竟，讓人了解建構都是一件費力的事情。
• 如何讓 LLM 基于代碼、分層、依賴關系等，解釋架構、業務？
• 如何讓 LLM 更好地了解規範，從文檔出發，去設計軟體架構？

每個問題都足夠的有意思，并且具備一定的業務和技術複雜度，足以讓我們掌握基于 LLM 的軟體架構所需要考慮的因素。

What is Co-mate ?

作為一個探索性的項目，解釋 Co-mate 的用途并不是一件容易的事情。一個架構師的助手能做到什麼程度，我們還沒有想得足夠的清晰 —— 因為我們還沒對架構的定義達到一緻意見。

但是呢，先讓我們看看 Co-mate 目前的處理流程：

從表面上看，基本上和主流的 AI 應用沒有差別；從實際代碼上來看，和主流的 AI 應用也看不出多大的差別。還是讓我們看看兩個典型的 Co-mate 場景。

示例 1：介紹一下這個系統

當使用者在 Co-mate 中去分析 Co-mate 時，會傳回類似于如下的結果：

Co-mate 項目是一個 AI 助手應用程式，使用了 Jetpack Compose、RxJava、DataStore 等一系列相關的庫來建構設計和治理工具等功能。該應用還使用了一些第三方庫來建構使用者界面，如 Coil-Compose、Voyager Navigator 等，以及進行深度學習推理任務，如 Kotlin Deep Learning API、Inference API 等。該應用需要考慮高效的算法和模型推理能力等非功能需求。

對于這個場景下，其資料處理過程如下：

1. 比對本地相關的指令（如 “分析系統”）
1. 如果比對到，則直接調用 AG API 來建構上下文。
2. 如果沒有比對到，則調用 LLM 進行選擇指令，然後可以調用 AG 原有 API。
2. 調用 AG API 建構上下文（項目資訊、軟體依賴資訊等）。
3. 調用 LLM 進行總結，并傳回給使用者。

是以，我們嘗試建構兩個新的 API：本地語義分析、（動态）上下文收集 API。

示例 2：API 規範性檢查

基于 ArchGuard 的能力，我們挑選的第二個場景是檢查 API 是否規範。當你有一個 Controller 裡的 API 需要檢查是否符合 API 規範時，就可以執行： 檢查 API 規範 。

假設你的 API 是： /api/blog/get ，并且已經通過 spec-partitioner （還沒有實作）轉換了你的 API 規範。

最後，Co-mate 會傳回：

API '/api/blog/get' 不符合 URI 構造規範，Rule: uri construction regex: \/api\/[a-zA-Z0-9]+\/v[0-9]+\/[a-zA-Z0-9\/-]+，建議 API 修改為 '/api/blog/v1/get'。

（PS：垃圾 GPT 3.5 Turbo，居然認可了 /get）

是以，當你有了完整的架構規範時，那麼就可以進入下一代架構生成：

這也是我們想進一步探索的工作。

How Co-mate works ?

衆所周知 GPT 充滿了各種不确定性，人們對于 GPT 了解的能力也是不同的。是以，從架構設計的角度來說，我們需要分解 GPT 的原子能力，諸如于總結、分類、提取、翻譯、邏輯推理，消除其中的不确定性因素，再由我們的軟體封裝 API 提供動态能力。

分層架構與 ArchGuard 能力映射

在示例 1 中，我們做的第一件是分解架構與資料，按不同的架構元素分析。因為我們對于架構缺乏統一的定義，是以我從 Global 的 slides 找了一個适合于 LLM 了解的分層架構、并且也适用于 ArchGuard 表達。随後，建構了一個不太成功的分層與所需要的上下文資料映射：

于是在示例 1 裡，我們給的 prompt 模闆是：

{xxx} 項目是一個 {channel type} 應用程式，使用了 Jetpack Compose、{xxx} 和一系列相關的庫來建構 {xxx} 等功能。該應用還使用了一些第三方庫來建構使用者界面 {xxx}，以及進行 {xxx} 等任務。該應用需要考慮 {xxx} 等非功能需求。

在這個 prompt 裡，它依賴于兩個主要資料：項目介紹與項目的技術棧（依賴資訊）。技術棧可以直接從 ArchGuard SCA 中擷取，而項目介紹則是從 README.md 中解析得到的。

LLM 與 Co-mate API 的能力映射

在示例 2 中，我們做的第一件事是分解 API 文檔， 按不同 LLM 的原子能力進行分解。建構出四種不同的原子能力：

• 推理出适用于 URI 的正規表達式。
• 推理出一個合理的 example。
• 提取一些 checklist，諸如于狀态碼、HTTP Action 等。
• 将剩下的不确定性内容，扔到一起。

如下圖所示：

在右側，我們則建構了一個 Kotlin Typesafe DSL，以動态的加載到系統中（未來），每一個函數對應到一個 Rule。

rest_api {
    uri_construction {
        rule("/api\\/[a-zA-Z0-9]+\\/v[0-9]+\\/[a-zA-Z0-9\\/\\-]+")
        example("/api/petstore/v1/pets/dogs")
    }

    http_action("GET", "POST", "PUT", "DELETE")
    status_code(200, 201, 202, 204, 400, 401, 403, 404, 500, 502, 503, 504)

    security("""Token Based Authentication (Recommended) Ideally, ...""")

    misc("""....""")
}           

作為一個 demo，這個 DSL 依舊具備很大的完善空間。其中比較有意思的部分在于 security 和 misc 部分，這些不确定性正好适用于 LLM 進行推理。是以，在執行對應的 misc、security 規則檢查時，會再調用 GPT 來檢查：

以将其中的确定性與不确定性更好的結合，進而充分地利用了 LLM 與 ArchGuard 的能力，并減少對 GPT 的消耗。

Welcome join us

下圖是，目前 ArchGuard Co-mate 的所有子產品：

簡單介紹如下：

• Comate-Core 提供了 CLI 和 GUI 所需要的基本能力，
• Meta-Action 則是定義了基本的 Action
• Architecture 定義了什麼是 Co-mate 了解的架構
• LLM-Core 則是對于 LLM 的調用 。
• Spec Partitioner 則是計劃對于規範的提取與自動生成（目前都是手動 prompt）

而我們在采用 JVM 技術棧的時候，遇到了幾個坑 KotlinDL 和 Deep Java Library 都是通過 JNI/Rust 的方式調用了 HuggingFace Tokenizers、ONNX API，導緻了應用在 macOS 下 crash。而一種理想的方式應該是通過 JSON RPC 的方式來調用，是以我們計劃使用 Rust 建構一個新的子產品：Comate Agent。

是以，如果你對使用 JVM 技術棧來開發 AI 應用，對 Rust 技術棧來開發 AI 應用，歡迎來加入我們。

總結

該文介紹了 Thoughtworks 開源社群建立的一系列開源項目，探索了大語言模型與架構治理、架構設計的可能性。其中，ArchGuard Co-mate 是一個探索性的項目，旨在探索架構師助手的能力，包括本地語義分析、動态上下文收集 API、架構規範檢查等。文章還介紹了分層架構與 ArchGuard 能力映射、LLM 與 Co-mate API 的能力映射等内容。