Composable AI Advisors

可组合AI顾问

一种多代理网格架构系统，将通用人工智能分解为专门推理引擎的服务网格，由模型驱动的编排器通过MCP（模型上下文协议）进行安全上下文交换。

概述

可组合AI顾问 使用多代理网格模式，其中：

• 一 编排器 （受模型约束的通用LLM）分解任务并协调专家
• 领域模型 是静态的、机器可读的模型描述（Turtle/JSON/Markdown），LLM用来承担利益相关者的职位
• MCP上下文和跟踪层 提供安全的上下文交换、来源和审计
• 客户端应用程序 使用编排好的输出

系统执行 三种领结图案:

1. 建筑领结：许多领域模型→ 受约束的编排器→ 许多客户端应用程序
2. 管弦乐室内领结：通用法学硕士→ 受模型约束（Turtle/Markdown）→ 模型驱动行为
3. 域模型内部领结：通用/专用法学硕士→ 受模型约束→ 领域特定行为

核心架构

Modular AI Framework

*从单片LLM到模块化AI——可组合AI系统的现代框架*

flowchart TD
  O["Orchestration\n(General-Purpose LLM)\nConstrained by Turtle/Markdown\n(Bow-Tie Pattern)"]
  D1["Domain Model A\n(Tools + Rules)"]
  D2["Domain Model B\n(Investments + Rules)"]
  D3["Domain Model C\n(Cognition + Rules)"]
  MCP["MCP Context & Trace Layer\n(Secure Context Exchange)"]
  C["Clients:\nMapper, Legal DocBot, OSINT, Guidance, Audit, etc."]

  O --> D1
  O --> D2
  O --> D3
  D1 --> MCP
  D2 --> MCP
  D3 --> MCP
  MCP --> C

关键概念

多代理网格

• 不是单片LLM：系统使用多种专门的推理服务
• 编排：受模型约束的通用LLM（领结模式）将任务和路线分解给专家
• 服务网格：服务使用域模型来提供独立的域特定功能（MaaS模式）
• 领域模型：域的静态、机器可读模型描述（Turtle、JSON或Markdown格式）

- LLM用于担任该领域的利益相关者 - 必须是机器可读的，因为LLM需要读取它 - 格式偏好：Turtle>JSON>Markdown（Markdown是最不受欢迎的）

• 当前状态：多基因法学硕士咨询能力正在发挥作用

MCP（模型上下文协议）

• 目的：用于代理之间上下文交换的安全协议
• 组件：背景、工具、元数据、可追溯性
• 实施：中的配置 .mcp/ 目录（待添加）
• 好处：来源跟踪、审计跟踪、安全上下文共享

孢子

• 上下文：用于代理连续性的可移植上下文包
• PromptSpore：可重复使用的提示逻辑数据包
• 目的：维护代理会话和多代理工作流之间的上下文
• 存储：已跟踪 spore_registry.ttl （RDF/海龟）

本体论（RDF/海龟）

• 格式：语义网标准（RDF/Turtle）
• 目的：结构化、机器可读、可互操作的数据
• 文件:

- caa-glossary.ttl -核心CAA本体 - guidance.ttl -指导登记处 - spore_registry.ttl -配偶追踪 - docs/pod/ -日计划示例

每日计划（PoD）

• 结构：PDCA工作流程（计划-执行-检查-执行）
• 格式：RDF/Turtle文件
• 目的：具有语义关系的结构化日常计划
• 人工智能一代：使用Google Gemini AI进行智能PoD创建

技术栈

后端

• 语言：Python 3.11
• 框架：FastAPI
• RDF处理：RDFLib
• AI集成：谷歌双子座（生成型人工智能）
• 部署：谷歌云运行

前端

• 框架：反应18.2
• HTTP客户端：Axios
• 网络服务器：Nginx
• 部署：谷歌云运行

数据和协议

• 本体：RDF/Tturtle（.ttl文件）
• 上下文协议：MCP（模型上下文协议）
• API格式：JSON（RESTful）

基础设施

• 实验室：公共外部端点位于 observatory.niklon.com （通过Cloudflare提供）
• 多LLM开发：实验室完全连接，用于多LLM开发
• 组件存储库：Niklon组织存储库包含具体的、公开可用的组件
• 包管理：PyPI提供了几个组件
• CI/CD：为组件存储库启用SonarCloud的CI/CD管道

项目结构

flowchart TD
  R["composable-ai-advisors/"]
  R --> backend["backend/ - FastAPI backend service"]
  R --> frontend["frontend/ - React frontend service"]
  R --> docs["docs/ - Documentation"]
  docs --> pod["pod/ - Plans of Day examples"]
  docs --> arch["architecture/ - Architecture diagrams"]
  docs --> arcv["archive/ - Historical/hackathon docs"]
  R --> scripts["scripts/ - Build and deployment scripts"]
  R --> ttl["*.ttl - RDF/Turtle ontology files (root)"]
  R --> agents["agents.md - AI agent guidance"]
  R --> archmd["ARCHITECTURE.md - Architecture documentation"]
  R --> deploymd["DEPLOYMENT.md - Deployment guide"]
  R --> readme["README.md - This file"]

配置文件 （隐藏在视线之外）：

• .cursor/ -游标IDE配置和规则
• .mcp/ -MCP配置（待添加）
• .cursorrules -主要光标规则

入门指南

先决条件

• Python 3.11+
• Node.js 18+
• Docker（用于容器化部署）
• Google Cloud Platform帐户（用于Cloud Run部署）
• Gemini API密钥（用于AI功能）

本地开发

后端

cd backend
pip install -r requirements.txt
export GEMINI_API_KEY=your-api-key-here
export PORT=8080
python main.py

后端将在 http://localhost:8080

前端

cd frontend
npm install
export REACT_APP_API_URL=http://localhost:8080
npm start

前端将在 http://localhost:3000

部署

看 部署.md 了解详细的部署说明。

建筑原理

1. 多代理网格：将通用AI分解为专业推理引擎的服务网格
2. MaaS（模型即服务）：每个专业推理机都作为自己的服务/API运行
3. 编排：通用LLM协调特定领域的服务
4. 上下文交换：使用MCP实现安全上下文、工具和可追溯性
5. 本体驱动：使用RDF/Turtle进行结构化、可互操作的数据

模块化模式的好处

• 领域准确度：专门的专家模型减少幻觉并加强领域逻辑
• 个性化：上下文层对每个用户和数据源的输出进行个性化设置，而无需重新训练通用模型
• 治理：明确的服务边界使决策可审计和可解释
• 可维护性：每个域的独立升级减少了更改时间
• 成本与性能：按工作量而不是一个巨大的占地面积选择合适大小的模型和基础设施

编排逻辑

编排器使用 三种领结图案 （所有人都出席了）：

1. 建筑领结：许多领域模型→ 受约束的编排器→ 许多客户端应用程序

- 这是整个系统架构模式

1. 管弦乐室内领结：通用法学硕士→ 受模型约束→ 模型驱动行为

- 这就是编排器本身在内部的工作方式

1. 域模型/LLM内部领结：每位参与者法学硕士（通用或专用）→ 受模型约束→ 领域特定行为

- 每个域模型的LLM都以通用或专用LLM开始（例如，为编码任务编码特定的LLM） - 模型约束每个LLM以符合领域要求 - 这就是每个领域模型的推理引擎在内部的工作方式

要点:

• 通用法学硕士：编排器是一个通用的LLM
• 模型约束：模型（RDF/Turtle或Markdown）约束/削弱LLM的行为
• 模型来源：模型可以是RDF/Turtle文件或Markdown文档
• 前景评估：构建编排器模型，以正确评估不同的视角
• 置信度阈值：编排者必须达到置信阈值（通常为90%）
• “热”：置信度基于编排器的构建方式
• 升级：如果置信度\<阈值，则升级为人工智能

开发指南

在后端工作时

1. API终点：遵循FastAPI模式，使用类型提示
2. RDF处理：使用RDFLib，尊重命名空间约定
3. AI集成：用于PoD生成的Google Gemini API
4. 服务边界：设计为独立、协调的服务
5. MCP意识：考虑上下文交换的影响

在前端工作时

1. 反应模式：基于组件的现代挂钩
2. API集成：使用Axios，正确处理async
3. 数据可视化：显示PoD、配偶、关系
4. UI/UX：现代、灵敏的设计
5. 状态管理：考虑上下文/状态模式

使用本体论时

1. 命名空间使用情况：遵循惯例 caa-glossary.ttl
2. SHACL形状：在适当的时候用于验证
3. 关系：维护语义链接（prov:wasGeneratedBy等）
4. 来源：跟踪创建、修改、来源
5. 一致性：使本体文件与代码保持一致

文档

• 特工.md -全面的AI代理指导和开发工作流程
• 建筑.md -详细的架构图和技术栈
• 部署.md -部署说明和配置
• internal lingo-cheatsheet.md -术语表
• docs/BOOTSTRAP.md -项目引导指南
• .游标 -游标IDE规则和指南
• .cursor/规则/ -模块化规则集（架构、本体、MCP、编码标准）

关键术语

看 internal lingo-cheatsheet.md 获取完整的术语表。快速参考：

• LIM42：设计脚手架工作流工具集
• BFG9K：代理编排框架（单独的产品/仓库，不属于此架构）
• Spore/上下文Spore/提示Spore：模块化上下文/提示包
• 主控程序：模型上下文协议
• MaaS：模型即服务
• 网格：多代理服务网络
• 过氧化物酶：日计划（PDCA工作流程）
• PDCA循环：计划-执行-检查-行动循环

贡献

进行更改时：

1. 检查架构：确保更改与多代理网格模式保持一致
2. 更新本体论：如果添加新概念，请更新相关内容 .ttl 文件
3. 保持MCP兼容性：考虑上下文交换的影响
4. 保留配偶模式：维护上下文连续性机制
5. 文档更改：更新相关 .md 文件

状态

• 当前状态：多基因法学硕士咨询能力正在发挥作用
• 基础设施：实验室 observatory.niklon.com 完全连接，用于多LLM开发
• MCP集成：配置待定（请参阅 .mcp/README.md)
• 工具适配器：产品交付要求正在确定中

许可证

看 许可证 文件以获取详细信息。

相关项目

• Niklon组织存储库：混凝土、公开可用的组件（一些在PyPI、SonarCloud CI/CD上）
• Graph RAG聊天应用程序：使用GraphDB和SPARQL进行Graph RAG模式的相关工作

______________________________________________________________________

建于❤️ BeastMost Systems/nkllon天文台