在優(yōu)化 ArchGuard 的 AI 輔助架構治理工具 Co-mate 的架構時，發(fā)現有一些模式與之前設計 AutoDev、ClickPrompt 等頗為相似。便思考著適合于 ArchGuard Co-mate 的架構設計原則是什么，寫下了初步的三條原則。

而正好要在公司內分享 LLM + 架構，便又整理了適合于更通用的四個架構設計原則。以此作為一個參考的架構原則基礎，方便于我后續(xù)設計其它的 LLM 為核心的軟件架構。

TL；DR 版本：

• 用戶意圖導向設計。設計全新的人機交互體驗，構建領域特定的 AI 角色，以更好地理解用戶的意圖。簡單來說，尋找更適合于理解人類意圖的的交互方式。

• 上下文感知。構建適合于獲取業(yè)務上下文的應用架構，以生成更精準的 prompt，并探索高響應速度的工程化方式。即圍繞高質量上下文的 Prompt 工程。

• 原子能力映射。分析 LLM 所擅長的原子能力，將其與應用所欠缺的能力進行結合，進行能力映射。讓每個 AI 做自己擅長的事，諸如于利用好 AI 的推理能力。

• 語言 API。探索和尋找合適的新一代 API ，以便于 LLM 對服務能力的理解、調度與編排。諸如自然語言作為人機 API，DSL 作為 AI 與機器間的 API 等。

作為一個參考性的架構原則，它在不同的場景之下是需要經過一定裁剪的。以上僅是一些初始想法，還需要進一步的研究和實踐來完善。

引子：ArchGuard Co-mate 的三個設計架構原則

Co-mate 是基于 ArchGuard 的分析能力所構建的，并且是以 DSL、規(guī)范文檔為核心來構建的。所以，我們設計了三條初步的設計原則：

• DSL 作為統(tǒng)一語言。通過使用領域特定語言（DSL）來增強人機交互，實現高效的人機、機機、機人交流。

• 原子化 LLM 以用于編排。利用語言模型（LLM）的原子能力，在 DSL 中構建復雜的行為。即我們在上一篇文章《規(guī)范即治理函數》提到基于 LLM 原子能力的動態(tài)函數生成。

• 精心設計的分層動態(tài)上下文。通過將上下文分為不同的層次，使用 LLM 有效地處理復雜性。

總體關系如下圖所示：

在 Co-mate 中，我們采用了 Kotlin Type-safe Builder 封裝了基礎的函數功能，以讓 LLM 能根據文檔、規(guī)范來編排治理函數。

原規(guī)范如下所示：

- 代碼中的命名均不能以下劃線或美元符號開始，也不能以下劃線或美元符號結束。
- 代碼中的命名嚴禁使用拼音與英文混合的方式，更不允許直接使用中文的方式，正確的英文拼寫和語法可以讓閱讀者易于理解，避免歧義。
- 類名使用 UpperCamelCase 風格，必須遵從駝峰形式。正例: HelloWorld。

示例 DSL 如下所示：

naming {
    class_level {
        style("CamelCase")
        pattern(".*") { name shouldNotBe contains("$") }
    }
    function_level {
        style("CamelCase")
        pattern(".*") { name shouldNotBe contains("$") }
    }
}

中間的文檔轉換 DSL 的過程就交給 LLM 來動態(tài)處理和生成（進行中）。有了這個基礎，我們會發(fā)現它與我們先前開源的基于 LLM 的應用，在架構上并沒有太多的區(qū)別。只是利用的能力有所差異，而又由于交互還沒到我們的核心。所以，我添加了一條：用戶意圖導向設計。

LLM 優(yōu)先的軟件架構設計原則

LLM 對于開發(fā)人員、架構師來說，即充滿了機遇，又充滿了挑戰(zhàn)。諸如于：LLM 如何輔助架構設計、如何構建基于 LLM 的架構、如何讓 LLM 引導架構設計以及如何構建 LLM 為核心的軟件架構。

不同的模式之下，對于現有的流程和軟件都會帶來不少的沖擊?；?Thoughtworks 內部的一系列探索、基于 LLM 的軟件架構和總結，我重新思考了四個原則：

• 用戶意圖導向設計。

• 上下文感知。

• 原子能力映射。

• 語言 API。

詳細展開如下。

1.?用戶意圖導向設計

如我們所熟悉的一樣，現有的應用都以 Chat 方式作為 LLM 的入口之一，而 Chat 的本意是去理解用戶的意圖，諸如于：“幫我寫一篇文章介紹設計原則”。這里的意圖就很直接，而為了讓用戶更好地去表達自己的意圖，就需要有意地去引導用戶的輸入。

在這里，就會呈現不同的引導方式或者封裝方式，諸如于封裝菜單為指令、封裝指令為 prompt、基于用戶輸入解析成 UI 等等。

為了更好地理解用戶意圖，我們需要考慮：設計全新的人機交互體驗。

總結：通過設計全新的人機交互體驗，構建領域特定的 AI 角色，以更好地理解用戶的意圖。例如，在聊天應用程序中，AI 可以使用自然語言處理來理解用戶的意圖，從而更好地回答用戶的問題。除此之外，還可以探索其他交互方式，如語音識別、手勢識別等，以提高用戶體驗。

2.?上下文感知

在先前的文章里，我們一直在強調上下文工程的重要性。我們原先對其的定義是：上下文工程是一種讓 LLM 更好地解決特定問題的方法。它的核心思想是，通過給 LLM 提供一些有關問題的背景信息，比如指令、示例等，來激發(fā)它生成我們需要的答案或內容。

而在包含了業(yè)務場景的情況下，我們要考慮的是圍繞于上下文工程的軟件架構。諸如于在 ArchGuard Co-mate 里，我們的思路是：通過分層方法來構建動態(tài)的上下文。其原因也主要是：我們對于某個用戶意圖的理解會存在不同的架構層次里，如業(yè)務架構、技術架構、代碼等。

總結：通過構建適合于獲取業(yè)務上下文的應用架構，以生成更精準的 prompt，并探索高響應速度的工程化方式。即圍繞高質量上下文的 Prompt 工程。例如，在一個電商應用程序中，AI 可以了解用戶的購物歷史記錄、瀏覽歷史記錄等上下文信息，以提供更好的購物建議。

3.?原子能力映射

起初，大部分結合 OpenAI 的應用，都是讓 LLM 直接生成 JSON、Yaml 的形式。但是呢，在我們嘗試了 3000 條左右的 PlantUML 生成之后，發(fā)現有 20% 的概率生成的 UML 是錯誤的，不可編譯的。正是這種場景，讓我們思考了 LLM 是否適合去做這樣的事情。

而在架構治理治理之下，我們將其定義為：借助 LLM 原子能力顯性化架構知識，映射和構建治理函數，動態(tài)度量不同場景。

在日常的業(yè)務場景里，對于 LLM 的能力分析也是非常重要的一環(huán)，諸如于我們不應該讓 LLM 進行數學計算，而是通過諸如 Functions Calling 的方式，將意圖與系統(tǒng)的功能相結合。

所以，我們分解了 LLM 的能力，按照不同的方式與系統(tǒng)結合在一起。

總結：我們需要分析 LLM 所擅長的原子能力，將其與應用所欠缺的能力進行結合，進行能力映射。讓每個 AI 做自己擅長的事，諸如于利用好 AI 的推理能力。例如，在一個智能家居應用程序中，AI 可以根據用戶的行為自動調整室內溫度、光線等，以提供更好的家居體驗。

4.?語言 API

在我與諸多架構師討論之后，我們幾乎達到了一個一致意見：我們需要一種新的 API，一種適合于 LLM 的 API。

它或許是一類基于語言的 API。對于人與機器、機器與機器來說，是我們熟悉的諸如于 JSON、YAML 或者其它自定義的 DSL；對于人與機器來說，這個語言 API 是自然語言，又或者是圖形等方式。

當我們可視化了自己的軟件架構之后，你會發(fā)現這一點特別的明顯。

總結：我們需要探索和尋找合適的新一代 API ，以便于 LLM 對服務能力的理解、調度與編排。諸如自然語言作為人機 API，DSL 作為 AI 與機器間的 API 等。例如，在一個在線客服應用程序中，AI 可以使用自然語言處理來理解客戶的問題，并根據問題的類型和緊急程度自動分配給不同的客服代表。

總結

來自不成熟的 Notion AI 的總結：

本文介紹了基于 LLM 的軟件架構設計原則，包括用戶意圖導向設計、上下文感知、原子能力映射和語言 API。通過設計全新的人機交互體驗、構建適合于獲取業(yè)務上下文的應用架構、分析 LLM 所擅長的原子能力和探索和尋找合適的新一代 API，可以更好地利用 LLM 輔助架構設計、構建基于 LLM 的架構、讓 LLM 引導架構設計以及構建 LLM 為核心的軟件架構。文章來源地址http://www.zghlxwxcb.cn/news/detail-483596.html