渐近式 AI 编程架构：Unit Mesh 架构的设计与探索

原副标题：周环式 AI 程式内部结构设计构架：Unit Mesh 构架的内部结构设计与积极探索

Unit Mesh是一类如前所述人工智慧聚合的分布式系统构架，与现代的分布式系统构架相同，Unit Mesh 中的服务项目模块 (Unit) 是由 AI 聚合的，插件中的服务项目和数据概念化为无数个分立的模块，并透过标准化的掌控正方形展开管理和布署。

在上一则该文《今后空间广阔的 AI 程式内部结构设计：究竟是开发人员的毁灭者起义者还是失业者的已经开始？》里，他们如是说了人类文明饮用 AI 程式内部结构设计的考量要素养。在这一则该文里，他们将继续积极探索 AI 程式内部结构设计的几率 —— 一类 AI 程式内部结构设计下的几率：Unit Mesh 构架，大略也是眼下较为可取的形式。

PS：或许叫 Unit Mesh，原因在于他们写了一个下层服务项目叫 UnitServer ，还有参照了 Service Mesh 和 Data Mesh 构架经营理念，所以 AI 取提议他们叫Unit Mesh 。

Unit Mesh Elements TLDR 版

他们先期表述的这个版（0.1 ，称作 UnitGenius）的核心理念四个优点：

词汇与架构的 DSL （应用领域某一词汇）概念化：概念化非的程式内部结构设计词汇和架构优点，以精简手忙脚乱的几率。 REPL 即服务项目：运转 AI 聚合的标识符，并提供相关联的 API 服务项目。 AI 内部结构设计的适应自然环境能力内部结构：人格适应自然环境的 API 服务项目构架，以在相同的自然环境下手动修正和强化。

开发人员能透过与 AI 可视化，聚合一定某种程度的 DSL 概念化化标识符，接着在 REPL 即 Serverless 服务项目上运转和试验那些标识符。开发人员还能将那些标识符递交给 AI进行智能化网络管理，AI 会对标识符展开强化和修正，进而不断提高 API 服务项目的操控性和安全性。

已经开始节录的专业术语版。

Unit Mesh 先期 Demo：DSL + REPL = Unit Server

详尽过程，见责任编辑的后半部分。

后端网页：https://prompt.phodal.com/zh-CN/click-flow/unit-mesh-unit-server/

首先，你需要克隆一下，Unit Server 的标识符：https://github.com/prompt-engineering/unit-server ，接着，选择 kotlin-repl 或者 type-repl 相关联 Kotlin、Type 两种词汇。

接着，按相关联的 README 运转起你的 Unit Server。

接着，在 ChatFlow 里让 ChatGPT 聚合如下的标识符，并点击 Run按钮：

% spring @RestController object Pages { @GetMapping ( “/” ) fun main = “It works!” }

最后，你就能得到一个正在运转的服务项目（该功能还在开发中）：http://localhost:8080/ ，访问该服务项目后，如果的应该是 It works。

PS：这里有一个手动加入调用 Application 类和调用 main 方法的标识符，因为需要做静态分析，才能确定使用的架构，暂时没写在 Unit Server 标识符中。

Unit Mesh 构架

再重复一下表述：

Unit Mesh是一类如前所述人工智慧聚合的分布式系统构架，与现代的分布式系统构架相同，Unit Mesh 中的服务模块 (Unit) 是由 AI 聚合的，插件中的服务项目和数据概念化为无数个分立的模块，并透过标准化的掌控正方形展开管理和布署。

Unit Mesh 核心理念思想：AI 聚合的标识符即 Unit

Unit Mesh 是围绕于 Unit 为核心理念的构架模式。

AI 聚合 Unit。即 AI 应该聚合的标识符都应该是可运转的 Unit ，上到 React 组件、下到后端服务项目都是可运转的。校验 Unit。由人类文明来检查和校验 Unit，如果 AI 聚合的标识符有问题，那么人类文明只需要修复即可。 Unit 自适应自然环境布署构架。在布署时，Unit 能组成 Serverless 构架、微服务项目构架、单体构架、Mesh 构架，而不需要人类文明来干预。

碳基嘛，就适合当一个 Verifier。

Unit Mesh 构架核心理念要素

结合他们内部结构设计的 Unit Server，他们内部结构设计的 Unit Mesh 构架由以下三要素构成。

词汇与架构的 DSL 概念化：封装不稳定的概念化

由于 AI 聚合的标识符会有各种问题，诸如于无法对接内部的云平台、手忙脚乱的 imports 等等，所以他们要内部结构设计应用领域某一词汇来解决这个问题，并封装概念化。

简单来说：他们需要概念化将所有不稳定的元素，便能构建出稳定的元素。

详尽的内部结构设计会在后面的 Unit Server 部分展开。

PS：而由于大词汇模型是有上下文能力限制的，像我这样的、搞不到充值的就只配 4k。因此，我内部结构设计的 Unit 要称作 4k Unit Mesh，我内部结构设计的 DSL 要称作 4k Unit DSL，有的人可能就是 99k DSL。

REPL 即服务项目：AI 标识符修复师的日常

在有了 DSL 之后，他们还需要一个 REPL （Read-Eval-Print Loop）服务项目，能直接运转起 AI 聚合的 Unit，接着让人类文明来试验聚合的标识符是否是正确。如果聚合的 AI 有错误，就需要 AI 标识符修复师来对标识符展开修复。

而对于一个服务项目来，如果他们是一个 API，就需要是 Serverless 服务项目，这就是为什么他们在图里称作：REPL 即 Serverless服务项目。详尽能参见后面内部结构设计的 Unit Server。

AI 内部结构设计的适应自然环境能力内部结构

人类文明内部结构设计系统的一个缺点是，如果内部结构设计时、开发时、运转时的模块不一样，那么就会出现各种疑虑。于是，他们会偏向于内部结构设计成三态一致的构架模式，而这本身对于构架的适应自然环境能力强化就是个问题。

而既然，标识符都是 Unit。那么，内部结构设计时能是微服务项目，开发时能是 Serverless，线上能是单体。正如 Google 的 Service Waver 所做的事情，他们不决定运转时的构架，让你来选择。

所以，AI 怎么运转他们的 Unit，就让 AI 来决定吧。

Adapative Architecture

PS：本来吧，副标题应该是适应自然环境能力构架（Adaptive Architecture），但是我想了想就只是标识符内部结构之类的，又重新考量了一下。

Unit Mesh 内部结构设计心得：反直觉才是出路

在去年年底，研究低延迟构架之时，便被这个应用领域的各种 反直觉构架模式所震撼，诸如于：GC 是问题那就不要 GC。

因此当内部结构设计 Unit Mesh 时，他们的问题依旧是： 如何 Open your mind。即抛开现有的思维模式和固有知识，打破常规思考，所以他们的主要挑战是如何 拓展思维，开放心智。

要点 1：如果分层构架是瓶颈，那么就不要分层构架

在那篇《今后空间广阔的 AI 程式内部结构设计里》分层构架是他们最大的挑战，于是，提出理想的形式就是 Serverless + FaaS 的形式，而这种形式则是如前所述现有的械，又过于理想化。

而随着他们写了 UnitServer 之后，他们发现，还能 Class as a Service 的形式嘛（手动狗头）。

既然他们的标识符运转在云端，由 AI 聚合的，那么人类文明还要看标识符吗？人类文明要在什么时候看标识符？无非就是检入的时候，还有审查构架的时候，所以只需要在审查的时候，聚合构架不就行了。

示例：我想分析 xx 服务项目的调用情况，以及相关联的标识符，请帮我调取出来。

要点 2：如果依赖是问题，那么就不要依赖

他们遇到的第二个挑战是依赖问题，而依赖是两个问题：

项目的库依赖。即类似于 Gradle、Maven、NPM 这一层的库依赖标识符依赖。即标识符源文件的 import

复读机 ChatGPT 并不能很好解决问题，所以就要让 GPT 忘记那些。理想的程式内部结构设计体验，应该是我要用 Spring，智能就会手动分析依赖，如 Intelij IDEA。所以，他们在 UnitServer 中采用了%spring样的 Jupyter magic 语法，以手动解决这两类问题。

要点 3：如果 Serverless 布署是问题，那么就不用 Serverless 布署

起初在 Unit Server 里，他们把 Unit Server 内部结构设计成了一个类 Serverless 构架，所以他们遇到了一个问题：Serverless 构架的成本并非所有的人能接受的。所以，他们只需要在试验 Unit 时，采用 Serverless 作为开发时，在线上合并成一个单体或者微服务项目构架，那么就能完美解决这个问题。

而在这时，还需要突破刚才的分层构架，既然每次标识符是聚合的，那么他们只需要一个包名即可，诸如于： org.clickprompt.unitmesh，所有的标识符都在这个包下；又或者，他们能透过业务进一步划分成相同的包，结合工具来对标识符展开归类。

Unit Mesh 积极探索之路：从 REPL 到 UnitServer

上面讲的太理论了，来看看他们的积极探索之路，一共分为四步：

从最小的 Hello, world 已经开始强化构建一个 REPL 自然环境概念化、精简内部结构设计 ← 重复。接入真实世界的 Prompt。

详尽能查看 Unit Server 和 ChatFlow 的递交纪录。

从最小的 Hello, world 已经开始

首先，让他们看一个 Kotlin 编写的 Spring 的 Hello, World:

@file : DependsOn ( “org.springframework.boot:spring-boot-starter-web:2.7.9” ) import … import java . util .* @Controller class HelloController { @GetMapping ( “/hello” ) fun helloKotlin : String { return “hello world” } } @SpringBootApplication open class ReplApplication fun main ( args : Array < String >) { … } main ( arrayOf ( “–server.port=8083” ))

在这个示例里，你会发现一系列的无用标识符，依赖信息、import 信息、main 函数。而作为一个 4k Unit Mesh 的创作者，我必须把那些不稳定的无用信息去掉，才能正确运转，所以它变成了：

% use spring @Controller class HelloController { @GetMapping ( “/hello” ) fun helloKotlin : String { return “hello world” } }

这样一来，我只需要让 ChatGPT 返回 Controller 即可。

构建 REPL 自然环境：WebSocket + %magic

既然，他们已经有了一个精简的 DSL，接下来就是引入 Kotlin 来构建一个 Unit Serverless 服务项目器，也就是他们的： https://github.com/prompt-engineering/unit-server 。

Unit Server 的源码是如前所述 Kotlin Jupyter API 所构建的，而 Kotlin Jupyter 则是封装了 Kotlin 的 REPL 自然环境。他们之所谓如前所述 Kotlin Jupyter 而不是 Kotlin REPL 的主要原因是，能使用 magic 和 DSL 来概念化细节，诸如于：

“spring” to Json . encodeToString ( SimpleLibraryDefinition ( imports = listOf ( “org.springframework.boot.*” , “org.springframework.boot.autoconfigure.*” , “org.springframework.web.bind.annotation.*” , “org.springframework.context.annotation.ComponentScan” , “org.springframework.context.annotation.Configuration” ), dependencies = listOf ( “org.springframework.boot:spring-boot-starter-web:2.7.9” ) ) )

即能手动添加 Spring 的依赖和 Import 信息，就能支持步骤的 Hello, World 形式。除了 Spring，他们还需要其它的库的 magic。

最后，再使用 WebSocket 暴露出这个接口，以提供给 ChatFlow 使用。

概念化、精简内部结构设计 ← 循环

当然了，只是有一个 hello, world 是不够的，所以他们需要更多的例子，诸如于接入数据库。而由于 Spring 的扫描机制影响，外加他们并不想（主要是不会）针对 Spring 做太多的特化，所以他们换成了 Kotlin 里 Kotr 架构。

PS：值得注意的是，他们还需要对架构展开概念化，但是 Ktor 对他们预期的好一点。所以，他们的第二个版来了：

% use kotless % use exposed data class User ( val id : Int , val username : String ) class Server : KotlessAWS { override fun prepare ( app : Application ) { Database . connect ( “jdbc:h2:mem:test” , driver = “org.h2.Driver” ) transaction { SchemaUtils . create ( Users ) } app . routing { post ( “/register” ) { val user = call . receive < User > val id = transaction { // Insert the new user into the database Users . insert { it [ username ] = user . username } get Users . id } val newUser = User ( id , user . username ) call . respond ( newUser ) } } } } object Users : org . jetbrains . exposed . sql . Table ( “users” ) { val id = integer ( “id” ). autoIncrement val username = varchar ( “username” , 50 ). uniqueIndex override val primaryKey = PrimaryKey ( id , name = “PK_User_ID” ) }

在这个版里，他们使用了 Exposed 作为数据库的 ORM，使用 H2 作为数据库。当然，要拿这个标识符作为 Unit 还差了 10% 的距离，不过，基本上已经能解决大部分的 CRUD 场景。

PS 1：这里的 KotlessAWS 只是一个 AWS Serverless 的概念化，并不影响他们的操作，他们能直接封装一个 UnitMesh 的类，就是懒。

PS 2：他们只需要透过静态分析拿出 routing 中的标识符，再强化即可。更多的积极探索过程标识符能见：_samples 。

一个真实世界的 Prompt

现在，让他们来结合 AI 跑一下：

请帮我使用 Ktor + Kotlin + Exposed 实现一个用户注册的 RESTful API ，要求如下： – 涉及到数据库的地方，请直接使用 Database . connect 。 – 只返回核心理念逻辑，并写在 Server 类里，我要布署在 Serverless 服务项目器里。 – 请使用 Kotlin DSL 的形式编写标识符。 – 不返回其它的无关标识符，如：注释、依赖、 import 等。最后，你只返回类的标识符，返回格式如下： class Server : KotlessAWS { override fun prepare ( app : Application ) { Database . connect ( “jdbc:h2:mem:test” , driver = “org.h2.Driver” , user = “root” , password = “” ) transaction { SchemaUtils . create ( Users ) } app . routing { {{{}}} } } }

人生苦短，欢迎加入他们的 Watchlist，一起讨论今后。

## Join Waitlist

狗头，现在 Waitlist 工程师们，你能就加入 Unit Mesh 的 Watchlist：

https://github.com/prompt-engineering/unit-mesh