跳转至

17 企业员工AI助理的架构设计

你好，我是李锟。

在上节课中，我们学习了时间管理方法 GTD，然后基于 GTD 方法讨论了企业员工 AI 助理的需求。在这节课，我们的角色将从 AI 产品经理转换到应用架构师，基于上节课讨论的产品需求，设计这个产品的技术架构。

上节课中我曾经强调过，软件需求文档（主要内容为详细用例描述）是必须认真完成的工作，不可以轻视甚至忽略。因为时间问题，我们暂时不完成详细的软件需求文档，而是假设我们已经有了这样一份需求文档。我可以略过这份需求文档而直接做架构设计，只是因为我对 GTD 的流程以及这个产品要实现的目标非常熟悉，已经胸有成竹。但是这种做法不值得鼓励。在一个团队里面除了开发人员，还有 UED 设计人员、测试人员、运维人员，如果连个高质量的软件需求文档都没有，希望他们高效地开展工作是不可能的。

言归正传，我们马上进入应用的技术架构设计。

应用软件架构设计的内容

设计应用软件的技术架构，通常需要完成以下工作：

确定产品的应用类型：

  • 服务器端应用（在线服务）、客户端应用还是两者都有。
  • B/S 架构还是 C/S 架构，或者 Serverless 架构。
  • 服务器端应用设计成单体还是分布式？

确定应用的技术选型：

  • 服务器端编程语言 + 开发框架、客户端编程语言 + 开发框架。
  • 需要使用什么关系数据库、NoSQL数据库、向量数据库？
  • 需要使用哪些中间件？

编写应用的架构设计文档，其中包括以下内容：

  • 应用的领域模型设计（Domain Model Design）：以 DDD 作为指导，遵循面向对象设计原则。
  • 应用的关系数据库设计（ER Design）：包括 ER 图和数据库 DDL。
  • 应用的对外服务 API 设计：如果应用是一个 Web 服务，对外暴露了一套 API，就需要有专门的服务 API 设计，确保 API 的易用性、松耦合、可伸缩性、安全性。
  • 应用的安全设计：安全性要求很高的应用，需要有专门的安全设计。
  • 应用的高可用性（HA）设计：可用性要求很高的应用，需要有专门的高可用性设计。

上述这些是普通应用软件中需要包括的技术架构设计部分。对于 LLM + AI 类型的应用，如果使用了较为复杂算法或者实现策略，还需要增加这一部分的设计。

需要强调的是，应用的技术架构设计文档不是只写一次就万事大吉了，而是要随着应用开发过程的深入开展而持续更新。架构设计、开发、测试、运维是增量 + 迭代的过程，而不是一次性瀑布式的过程。

接下来我们就按照上述这些部分来设计 企业员工 AI 助理的技术架构。以下还是把这个应用简称为“AI 助理”。

确定 AI 助理的应用类型和技术选型

  1. 确定产品的应用类型

根据上节课讨论的企业员工 AI 助理的需求，这个应用最合适的应用类型是 B/S 架构的应用，也就是一个包括客户端应用的在线服务。这个应用的业务复杂度不高，另外这个应用因为运行在企业私有云或局域网环境，并发访问量也不高，所以根本没有必要设计成分布式应用，设计成单体应用足够了。未来即使需要支持较高的并发访问量，也可以通过“无状态 + Share Nothing 架构 + 负载均衡集群”来轻易解决。

  1. 确定应用的技术选型

首先考虑服务器端应用的技术选型。因为我们最熟悉的编程语言是 Python，这门课使用的编程语言也是 Python，所以很自然我们选择 Python 来开发服务器端应用。Python 性能较差对于这个应用来说不是大问题。

因为这个应用是一个 B/S 应用，所以我们需要选择一个流行的 Web 应用开发框架。流行的 Python Web 开发框架有 Django、Flask、Tornado、FastAPI 等等。此外还有 Streamlit、Gradio 这类开发演示应用的快速开发框架。我的选择是 FastAPI，因为 FastAPI 性能优越，学习门槛较低，而且可以非常好地支持设计开发 RESTful API，以便支持未来客户端应用的开发。Streamlit、Gradio 开发演示应用虽然很高效，用来支持 RESTful API 和客户端应用就比较差了。

选择 Web 开发框架固然很重要，不过对于一个 LLM + AI 应用来说，选择一个 LLM 应用开发框架就更重要了。前面我们已经确定，这个应用是一个 B/S 架构的在线服务，虽然这个应用的 UI 有一半是 NUI（自然语言界面），然而这个应用并非一个以聊天为主的 ChatBot，而是一个 Autonomous Agent（自主型智能体），我们需要选择一个最合适的 Autonomous Agent 开发框架。我们已经学习过 MetaGPT、AutoGPT、Swarm 三个 Autonomous Agent 开发框架，究竟选择哪一个呢？

我思考了较长时间，最后决定还是选择 AutoGPT。有以下原因：

  • AutoGPT 本身就是一个 B/S 架构的在线服务，而且支持高可用性，跟 AI 助理的应用类型一致。
  • AutoGPT 的 Agent Builder 提供了方便易用的图形化开发、测试工具，从概念上支持更为强大的工作流。MetaGPT 当前 0.8.x 版中的工作流支持很笨拙，而 MetaGPT 1.0 版迟迟未发布，其中的全新工作流支持不知道是否真的很强大、很好用。Swarm 虽然支持开发多 Agent 应用，然而完全没有对于复杂工作流的支持，需要完全手工实现。
  • AutoGPT Platform 的开发已经逐渐走入正轨，进度明显加快。Autonomous Agent 开发框架的王者之战，在 2025 年内即将展开。AutoGPT Platform 是有力的竞争者。
  • AutoGPT Platform 提供了一些可重用的 Block，而如果功能无法满足要求，自己基于这些 Block 定制一个 Block 也很容易。在 08 课中我们已经看到过。
  • AutoGPT 团队的响应速度更快，在其 Discord 群里提的问题很快都能得到回复，虽然需要使用英语。

在服务器端我们确实需要有一个关系数据库，否则很多功能实现起来会更麻烦。因为这个应用的并发访问量不大，数据量也不大，我们用普通的 MySQL 数据库就足够了。也可以使用 supabase 安装的 PostgreSQL，和 AutoGPT Platform 使用相同的数据库，这样可以减少一种数据库。此外，对于开发者在开发机上做测试，使用嵌入式数据库 SQLite 会很方便，我们可以通过 O-R Mapping（对象-关系映射）框架，方便地切换 SQLite、MySQL、PostgreSQL。

未来我们可能会实现一些 RAG 相关的功能，例如访问企业的内部知识库，因此我们需要有一个向量数据库。目前向量数据库可选的也非常多，有轻量级的，也有重量级的。我建议先选择一个轻量级、便于开发的向量数据库。未来如果确实无法满足要求，再考虑迁移到重量级向量数据库。我推荐的轻量级向量数据库是 Weaviate，重量级向量数据库是 Milvus，我们可以先使用 Weaviate。

可能用到的中间件方面，通常服务器端应用都需要有一个分布式缓存。Redis 是最流行的分布式缓存中间件，我们选择 Redis 就好了。此外 Redis 还可以作为轻量级的 NoSQL 数据库和消息中间件来使用，可谓是中间件领域的“瑞士军刀”。

我们再来看考虑客户端应用的技术选型。客户端应用我们既可以开发为原生（native）的桌面应用 + 移动应用，也可以开发为一个 PWA 应用（Progressive Web App，渐进式 Web 应用）。

因为我们希望客户端应用具有多端支持和非常高的包围度，需要支持电脑 (台式机 + 笔记本)、智能手机、智能手表。要达到很好的用户体验，还是需要开发原生的应用。但是开发支持多端的原生应用，不同操作系统的应用需要使用不同的编程语言，代码不具有可移植性，开发成本非常高。即使使用了 ReactNative、Flutter、Xamarin 这一类跨平台的原生应用开发框架，开发成本也是比较高的。

为了节省成本，也为了快速迭代，我们可以先把客户端应用开发为一个 PWA 应用。PWA 应用的开发技术和服务器端的 Web 应用基本上是一样的，就是 JS + HTML + CSS，会这些开发的人员有一大把，相关教程、图书也极其丰富。

决定将客户端应用开发为 PWA 应用之后，我们还需要选择一种前端开发框架。前端开发框架可以划分为支持 SPA（单页面）应用的开发框架和不支持 SPA 应用的开发框架。

  • 支持 SPA 开发的开发框架

  • React

  • Vue
  • Angular
  • Svelet & SveletKit

  • 不支持 SPA 开发的开发框架

  • HTMX

这里我罗列的是支持组件化开发的前端开发框架，jQuery 这类古老的开发框架不支持组件化开发，没有列在其中。

选择前端开发框架有很多考虑因素，这方面其实没有特别严格的选择标准。如果我亲自做开发，我倾向于选择最轻量级的 HTMX，虽然这个开发框架比较小众。

最后总结一下 AI 助理的技术选型：

编写 AI 助理的架构设计文档

应用的领域模型设计

应用软件的架构设计包括很多内容，如果一定要说其中哪一部分最重要，在我看来就是领域模型设计了。因为应用的领域模型设计是应用最核心的部分，这一部分没设计好，应用连基本的功能都存在问题，更别提什么用户体验、高可用性了。

目前业界最常用的领域模型设计方法是 DDD（领域驱动设计），我曾经在 15 课中简单介绍过 DDD。在这一课中，我们用 DDD 作为指导来设计 AI 助理的领域模型。

另外 UML 对于设计业务系统来说是非常有用的工具。我推荐一本 UML 入门图书——Martin Fowler 的《UML 精粹》(UML Distilled)。我使用的 UML 设计工具是免费的 Astah 社区版。遗憾的是这个版本官方已经不提供了，我分享在百度网盘，你可以从这里下载安装。

UML 图中最重要的图是用例图、类图、活动图、序列图、状态机图、组件图这 6 种，活动图和用例图在前面的课程中我们已经看到过。

首先我们使用类图来确定应用中存在哪些实体（Entity）。实体就是一些名词性的概念，按照面向对象设计的要求，我们设计一个应用软件应该从名词（系统中的实体）开始，然后再考虑动词（与每个实体有关的动作），而不是反过来，先考虑动词再考虑名词。

与上节课的企业员工相关的 UseCase 图对应的企业员工相关类图如下：

图片

我对上面的类图做一些说明：

  • Employee：企业员工，使用企业员工 AI 助理这个应用的所有用户。其他所有实体都隶属于 Employee。
  • Idea 是与工作时间有关的所有想法。可以把 Idea 放在不同的 Basket 中，并且添加适当的标签。
  • Action 是 Idea 整理之后要做的动作。可以把多个相关的 Action 组织在一个 Project 中，而且一个 Project 可以包括不同 Employee 的 Action。
  • CheckList 可包括多个独立的 Action + Project。按照上节课的介绍，可以划分为 Actionable（可操作）、NonActionable（不可操作）两个大类。而两个大类各自又可划分为三个小类。我们重点关注的是 Actionable 这一类。NextAction 是虽然没有明确时间要求，但已经打算执行的动作。Calendar 是有明确时间要求，必须在某个时间完成的动作。WaitingFor 是等待其他同事完成某个前置动作后，才能完成的动作。
  • RelevantSystem 是与动作执行相关的其他系统。可以划分为企业内部系统 InsideSystem 和企业外部系统 OutsideSystem 两大类。每一个系统都有一些相关的工具 (tool)，ToolConfig 对应这些工具相关的配置，例如访问云端 LLM 的 api_key 等等。ToolInvoke 记录每一次 Tool 调用，包括调用的输入参数、返回的结果等等。
  • ReviewReport 是对系统做回顾生成的报告。可以划分为周期性的报告，周报、月报、季报，也可以不定期。手工生成回顾报告确实相当繁琐，这是 LLM 和 AI 能够唱主角的领域。

这个类图只是第一个雏形版本，目的是划分出与企业员工 UseCase 相关的名词性实体。你看到了，图中所有的接口和类都尚未添加属性（attribute）和操作（operation）。不过这个版本的类图已经可以拿出来在开发团队内部讨论了。把这个雏形版本讨论清楚了，大家对于系统中有哪些实体可以达成共识，然后可以为图中的每个实体添加属性，再做一轮讨论。讨论达成一致意见后，名词性的设计就基本上完成了。

接下来进入动词性设计，为图中的每个实体添加操作。但是类图本身是静态的，无法表现出这些操作的整体流程或者时间顺序，因此可以再补充一些活动图（整体流程）、序列图（操作发生的时间顺序），还可以根据需要补充状态机图、组件图。

这个设计过程就是面向对象设计的标准做法，有很多相关的图书。我推荐 Peter Coad 写的一本薄薄的旧书《面向对象的设计》。Peter Coad 是面向对象分析、面向对象设计领域的宗师级人物。他写的所有图书都不厚，言简意赅，值得反复阅读。也非常适合 Sam Altman 近期访谈中强调的“边做边学”。

前面我已经说过，架构设计的各个环节其实也是增量迭代式的，而不是一次性瀑布式的。如果严格按照瀑布式的方式来做领域模型设计，很容易陷入设计瘫痪状态。贪大求全，一味追求完美设计，试图在设计阶段捕捉到所有的细节并且加以考虑，其实没有一个架构师能够做到。我们识别出来上图中的这些实体，其实已经足以展开一轮迭代开发了。然后我们带着开发过程中获得的知识，再继续补充识别出来的其他实体，进入下一轮迭代开发。如此循环往复，步步为营，稳扎稳打。

应用的关系数据库设计

完成了一个阶段的领域模型设计，我们可以基于最终获得的详细类图，来画数据库设计的 ER 图。把类图中的类映射到关系数据库的表中，这个工作叫做 O-R Mapping（对象-关系映射）。有很多映射策略，最简单的映射策略是 ActiveRecord，适用于简单的业务系统。我们这个 AI 助理应用，使用 ActiveRecord 策略就足够了。

此外还有 DataMapper 等更复杂的设计策略，适用于复杂的系统。关于 O-R Mapping 的映射策略，可以参考 Martin Fowler 的名著《企业应用架构模式》(Patterns of Enterprise Application Architecture, PoEAA)。

具体的 ER 图我就不画了。按照 ActiveRecord 策略，将上面的类图映射到数据库设计，会生成 Employee、Idea、Basket、Action、Project、CheckList、RelevantSystsm、ToolConfig、ToolInvoke、ReviewReport、PerformanceSummary 11 张表。

总结时刻

这节课我先介绍了应用软件架构设计包括的工作，然后确定了 AI 助理的应用类型和技术选型，接下来我们介绍了编写 AI 助理的架构设计文档中最重要的两部分：领域模型设计和关系数据库设计。

从这节课中，我们可以看到，即使是设计开发自主型智能体，我们仍然可以沿用 DDD、OOD 等成熟的软件设计方法，这些设计方法与 LLM、AI 并无任何矛盾之处，反而相得益彰。认为学习了 LLM 应用开发就可以完全抛弃 DDD、OOD 的想法是幼稚的。没有 DDD、OOD 的指导，LLM 生成的代码甚至架构设计仍然是低质量的，可能会充满隐患。

下节课中我们将进入开发阶段，来基于 AutoGPT Platform 来实现一些基础 Block，并测试相关的提示词。

思考题

LLM 应用的架构设计文档，应该包括哪些内容？有哪些内容是与 AI 直接相关的？

欢迎你把你的想法分享到留言区，也欢迎你把这节课的内容分享给需要的朋友，我们下节课再见！