Aether Llmops Platform

Aether LLMOps 原生AI 应用开发平台

> 本项目是一个复杂的LLMOps平台开发，通过本项目，你可以全流程打造你自己的 AI 原生应用开发平台，欢迎提issue，参与讨论与贡献。

【注】 本项目已部署在阿里云服务器，该仓库非最终版本。

Aether LLMOps 项目服务架构设计

在整个Aether LLMOps项目中，我使用了多个服务，具体如下：

1. API：基于Flask和LangChain搭建的 LLMOps API 服务。
2. Web：基于Vue.js搭建的 LLMOps前端服务，一个静态html文件服务。
3. 数据库：Postgres数据库，用于存储LLMOps项目的数据信息。
4. 缓存：Redis缓存数据库，用于存储Embeddings缓存、Celery消息代理等信息。
5. 向量数据库：Weaviate向量数据库，用于存储Embeddings向量。
6. 任务队列：Celery任务队列，用于执行异步任务。
7. Nginx反向代理：反向代理连接API和WEB服务，实现域名访问 LLMOps 项目。

为了便于部署和管理，我将这些服务部署到Docker容器中，并使用docker-compose管理多个容 器，同时通过 Nginx 进行反向代理，连接 API 和 web 服务，项目整体服务架构设计图如下：

快速开始

填写docker-compose.yml文件中的环境变量，包括数据库连接信息、缓存数据库连接信息、向量数据库连接信息，各种API密钥等。

cd docker
docker-compose up -d

项目后端模块设计

该项目采用经典的分层架构设计

1. 入口层 app/http/ 负责应用初始化和中间件注册
2. 路由层 handler/ 负责接收请求和参数校验
3. 业务层 service/ 实现核心业务逻辑
4. 数据层 model/ 负责数据库交互
5. 公共组件 pkg/ 提供跨模块复用的通用能力
6. 配置和工具模块分离，便于维护和扩展

核心引擎层internal/core/：

• workflow/ - 完整的工作流引擎，支持多种节点类型（LLM、工具调用、HTTP请求、代码执行等）
• language_model/ - LLM 抽象封装
• embedding/ - 文本向量化
• vector_store/ - 向量数据库管理
• unstructured/ - 非结构化文档解析
• tool/ - 内置工具集
• memory/ - 对话上下文记忆
• agent/ - 智能体管理
• builtin_apps/ 内置应用

API 项目文件结构梳理：

---

api/
├── config/                     # 配置模块
│   ├── __init__.py
│   ├── config.py               # 配置加载逻辑
│   └── default_config.py       # 默认配置项
├── app/                        # 应用入口层
│   ├── __init__.py
│   └── http/                   # HTTP服务入口
│       ├── __init__.py
│       ├── app.py              # FastAPI 应用实例创建、中间件注册
│       └── module.py           # 依赖注入模块配置
├── internal/                   # 核心业务实现层
│   ├── core/                   # 核心组件（工作流、向量存储、文档处理等）
│   │   ├── agent/              # Agent 相关实现
│   │   │   ├── agent_builder.py
│   │   │   ├── agent_executor.py
│   │   │   └── conversation_agent.py
│   │   ├── builtin_apps/       # 内置应用实现
│   │   │   ├── chat/
│   │   │   ├── completion/
│   │   │   ├── dataset_qa/
│   │   │   └── workflow/
│   │   ├── file_extractor/     # 文件提取工具
│   │   ├── langchain_fix/      # LangChain 补丁/修复
│   │   ├── language_model/     # 语言模型封装
│   │   │   ├── base.py         # LLM 基类
│   │   │   ├── factory.py      # LLM 工厂
│   │   │   ├── openai.py       # OpenAI 模型封装
│   │   │   ├── anthropic.py    # Anthropic 模型封装
│   │   │   └── azure_openai.py # Azure OpenAI 模型封装
│   │   ├── memory/             # 对话记忆管理
│   │   ├── retrievers/         # 检索器实现
│   │   ├── tools/              # 工具集
│   │   │   ├── base_tool.py
│   │   │   ├── builtin_tools/
│   │   │   │   ├── search/
│   │   │   │   ├── calculator/
│   │   │   │   └── web_scraper/
│   │   │   └── api_tools/
│   │   ├── unstructured/       # 非结构化文档处理
│   │   │   ├── document_processor.py
│   │   │   └── nltk_data/      # NLTK 数据文件
│   │   │       ├── punkt/
│   │   │       │   └── ... (18种语言的 punkt 分词数据)
│   │   │       └── punkt_tab/
│   │   │           └── ... (22种语言的 punkt_tab 分词数据，包含 abbrev_types.txt、collocations.tab、ortho_context.tab等)
│   │   ├── vector_store/       # 向量数据库存储
│   │   └── workflow/           # 工作流引擎核心
│   │       ├── workflow.py                  # 工作流引擎主逻辑
│   │       ├── workflow_validate_rule.jpg   # 工作流验证规则图
│   │       ├── entities/                    # 工作流实体定义
│   │       │   ├── node_entity.py           # 节点实体
│   │       │   ├── edge_entity.py           # 边实体
│   │       │   ├── variable_entity.py       # 变量实体
│   │       │   └── workflow_entity.py       # 工作流实体
│   │       ├── nodes/                       # 工作流节点类型实现
│   │       │   ├── base_node.py             # 节点基类
│   │       │   ├── start/                   # 开始节点
│   │       │   ├── end/                     # 结束节点
│   │       │   ├── llm/                     # LLM 调用节点
│   │       │   ├── code/                    # 代码执行节点
│   │       │   ├── tool/                    # 工具调用节点
│   │       │   ├── http_request/            # HTTP 请求节点
│   │       │   ├── dataset_retrieval/       # 数据集检索节点
│   │       │   ├── template_transform/      # 模板转换节点
│   │       │   ├── question_classifier/     # 问题分类节点
│   │       │   └── iteration/               # 循环迭代节点
│   │       └── utils/                       # 工作流工具函数
│   ├── entity/                 # 实体定义
│   ├── exception/              # 自定义异常定义
│   ├── extension/              # 扩展模块
│   ├── handler/                # API 接口处理器（Controller层）
│   ├── lib/                    # 内部工具库
│   ├── middleware/             # HTTP 中间件
│   ├── migration/              # 数据库迁移（Alembic）
│   ├── model/                  # 数据库模型（DAO层）
│   ├── router/                 # 路由配置
│   ├── schema/                 # 请求/响应模型（Pydantic）
│   ├── server/                 # 服务启动配置
│   ├── service/                # 业务逻辑层（Service层）
│   └── task/                   # 异步任务模块
├── pkg/                        # 公共可复用组件
├── storage/                    # 存储相关模块
├── test/                       # 单元测试/集成测试
├── Dockerfile
├── requirements.txt
└── ...

应用编排模块:可视化编排 Agent

在 LLMOps 应用编排页面，应用的配置可以划分成几种，例如：

• 草稿配置：用户在前端编排页面修改Agent配置时，实时存储的就是草稿配置，草稿配置只会在编排页面调试中生效，在开放API 或者 WebApp 中均不会起效果。
• 当前发布的运行配置：即当前 Agent 智能体在开放 API 或者在 WebApp 中使用的配置信息，由草稿配置发布得到。
• 历史发布的运行配置：记录每一次发布的运行配置，便于在编排页面对配置进行回退操作，当执行回退操作时会将对应的运行配置同步到草稿配置中，完成对草稿配置的覆盖。

在 LLMOps 项目中，考虑使用两张表来完成该运行流程，这两张表分别是：

1. app_config：应用运行配置表，用于存储该 Agent 应用实际运行的配置信息（WebApp、开放 API 运行的 Agent 配置）。
2. appconfigversion：应用配置历史版本表，该表用于存储每次发布的配置信息历史+草稿信息，通过 config_type 来标识记录是历史配置还是草稿，通过 version 字段来标识不同的版本。

那么不同的操作执行的逻辑如下：

1. 创建应用：创建应用的同时添加 appconfigversion 记录，并在记录中存储默认草稿配置信息。
2. 更新应用草稿配置：将数据同步到 appconfigversion 的草稿配置记录中。
3. 发布应用：取出应用的 appconfigversion 草稿配置，同步添加到 appconfig 中，同时在appconfig_version 中添加一个历史配置信息记录，并更改应用的状态，从而完成发布应用流程。
4. 更新应用：取出应用的 appconfigversion 草稿配置，并同步更新 appconfig 中的配置，同时在appconfig_version 中添加一条历史配置信息记录，从而完成应用更新流程。
5. 取消发布：删除 app_config 中的配置，并更改应用的状态。

应用配置数据结构设计

在Agent应用编排页面中，为了便于后续的扩展，对于启用类字段，均使用{"enable": true}而非单纯boolean类型的标识来代替，便于后期扩展某项功能，例如 长期记忆是否启用，该字段配置如下：

{ "long_term_memory": { "enable": true } }

后期如果想对长期记忆的内容长度进行配置，只需要在配置中新增字段length_limit即可，例如：

{ "long_term_memory": { "enable": true, "length_limit": 2000 } }

除了上述的特殊部分，在草稿配置以及历史配置中，还会存储存储关联工具列表、关联知识库列表、关联工作流列表，这些数据涉及到跨表的引用，所以考虑使用jsonb列表来存储对应的引用，在每次Agent使用之前均会检测对应数据是否存在，并进行更新。

设计好应用配置结构后，即可考虑完成对应Agent智能体的配置，实现一个 Agent（或者说一个 Class），通过接收不同的config能实现不同的功能，从而完成可视化编排Agent的整个流程。

workflow 工作流模块

实现可视化编排工作流的功能，核心思想就是在前端进行编排的时候，记录对应的数据，涵盖：

1. Node(节点)：包含节点的类型、输入数据结构、输出数据结构、节点额外信息、节点位置(前端坐标)等。
2. Edge(边)：包含边起点、边终点等，在 LangGraph 中，边只是执行顺序的差异，并不代表数据从上一个节点流向下一个节点。

这样后端就可以根据接收的 Nodes(节点列表) 和 Edges(边列表) 构建一个 Graph 图程序，在 Graph 图程序 内部循环遍历所有的节点+边，并在 Graph 图 中添加对应类型的数据，最后完成编译。 在 LLMOps 项目中，我使用 LangGraph 作为后端工作流的实现基础框架，将上述分析转换成流程图后如下：

在该架构中，图结构、节点、边、状态之间的类型的梳理逻辑如下：

1. Workflow 本身是一个 LangChain Tool 组件，在底层通过构建 Graph图结构程序 来完成对应的逻辑。
2. Node节点 本身都是 Runnable 可运行组件，统一实现 invoke 方法，并接收/返回 WorkflowState 的数据。
3. WorkflowState 中会记录 输入数据 以及 每个节点产生的数据，并且能通过标识获取到各个节点生成的数据。
4. Workflow 由于存在并行节点，并且可能存在某个节点需要获取并行节点的数据，所以添加 Edge(边) 时，如果是并行节点，需要等待并行节点执行结束后才可以执行子节点。
5. Graph图程序 返回的是状态，而 工作流 只需要 结束节点 提炼的数据，所以在 Tool组件 内部需要对状态数据进行提取。

知识库模块

一些优化点

• 考虑到处理大量文档分块、嵌入等的长耗时，利用 Celery+Redis 构建异步任务队列处理分块嵌入，用线程池优化向量入库。
• 随着功能迭代，针对检索准确率不够，在 RAG 引入检索前处理+混合检索+重排，在黑神话悟空的自建QA数据下测试，准确率相比语义检索提升近30%，召回率从60%左右提升至80%+。
• 在文档与片段(chunk)的更新与删除时，实现 Redis 缓存锁，保障数据安全。

检索器设计思路

• 在全文检索时，项目考虑的是第一种方案，增删改都要将数据同步到关键词表中，简化全文检索的实现。
• 第二种方法，本项目并未使用，因为其在全文检索时，需要将所有 doc 和 seg 都遍历一遍再过滤，导致查询效率低。

流式输出

考虑在LLMOps项目中，借用队列(Queue)+线程(Thread)的方式来重新实现流式输出这个逻辑，思路如下：

构建一个 队列(Queue)，用于存储数据，队列的数据先进先出，并且是线程安全的，非常适合用于开发。 在LangGraph构建的节点(nodes)中，所有代码都使用stream() 代替invoke()，获取数据的时候，将数据添加到队列(Queue) 中。 创建一条线程，专门用于执行LangGraph图程序，这样不影响主线程。 在主线程监听队列(Queue)里的数据，并逐个取出，然后进行流式事件响应输出，直到取到结果为None结束请求。 基于该思想，在LLMOps项目中实现流式事件响应 + 块内容响应的两种输出响应运行流程如下：

附录

术语表

| 术语 | 定义 | | ---- | ----------------------------------------------- | | LLM | Large Language Model，大语言模型 | | RAG | Retrieval-Augmented Generation，检索增强生成 | | API | Application Programming Interface，应用程序接口 |

贡献

贡献是使开源社区成为学习、激励和创造的惊人之处。非常感谢您所做的任何贡献。如果您有任何建议或功能请求，请先开启一个议题讨论您想要改变的内容。

许可证

该项目根据 MIT 许可证的条款进行许可。详情请参见[LICENSE](LICENSE)文件。

Source & license

This open-source MCP server is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: chyu-wissfi
• Source: chyu-wissfi/aether-llmops-platform
• License: MIT

Install and usage instructions live in the source repository linked above.