vame/LingMind
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

添加设计路思文件

Browse Source
This commit is contained in:
yeww
2026-07-11 17:38:43 +08:00
commit 17d5dca060
3 changed files with 575 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/architecture/企业版.md
+54
View File
@@ -0,0 +1,54 @@
## 产品定位
开箱即用的多功能智能体，通过极简交互和强大自进化能力，成为个人工作生活的全能助手，以及企业智能化转型的统一入口。
强调安全合规，可审计可追溯、权限控制和后台数据整合，适配企业组织架构，支持本地+云混合部署。
## 个人知识库
* 直接多模态文件拖放传放，后台向量化储存；
* 拖放到对话框中，作为此轮对话上下文，同时后台根据文件内容和上下文选择是否存入知识库。
* 用户可以
## 记忆功能
* 根据聊天内容提取和整理记忆。
## 1、企业内部系统整合
## 本地+云混合部署，保证企业数据安全
整体分为 **企业本地层**、**安全传输通道** 与 **云端智能层** 三部分。
**核心原则**：
- 原始文档、明文片段**只存储在企业本地**。
- 本地利用企业算力完成向量化与检索，上下文在本地组装后**经强加密**送往云端推理。
- 云端模型在**机密计算环境（TEE）** 内解密数据并执行推理，全程不落盘、外部无法窥探，解密密钥由企业管理员管控。
```
|-- 客户端管理平台（UI）
|-- 本地数据面
| |-- 文档切片 & 向量化引擎（授权启动）
| |-- 向量数据库（Milvus/Qdrant）
| |-- 用户知识库
| |-- 加密代理模块
|-- 云端控制与推理服务（您方运营）
|-- 许可与授权中心
|-- 机密推理集群（TEE）
|-- 核心算法（重排序、专有大模型、安全策略）
```
```mermaid
sequenceDiagram
participant Client as 客户端(本地加密代理)
participant Cloud as 云端TEE推理引擎
participant DB as 企业数据库
Client->>Cloud: 初始加密请求(问题+上下文)
loop 可能需要多次查询
Cloud-->>Client: 加密查询指令(如SQL模版+参数)
Client->>DB: 解密后执行受限查询
DB-->>Client: 查询结果
Client->>Cloud: 加密查询结果
end
Cloud-->>Client: 加密最终答案
```
docs/architecture/智能家居实现方案.md
+469
View File
@@ -0,0 +1,469 @@
## 方案一：借助成熟的智能家居平台
### 图1：方案架构图（系统分层与组件关系）
此图展示整体软件架构，核心是**“平台适配层”**，用于屏蔽不同第三方平台（涂鸦、米家、华为等）的API差异。
```mermaid
flowchart TB
subgraph 用户层 [用户交互层]
UI[移动端/Web端 APP]
end
subgraph 应用层 [AI APP 核心服务层]
NLP[意图识别与对话管理]
Context[用户上下文/设备状态缓存]
subgraph 集成层 [设备控制抽象层（平台适配器）]
Adapter[统一设备控制接口<br>（开机/关机/调温/调模式）]
Tuya[涂鸦适配器]
Mi[米家适配器]
Huawei[华为智慧生活适配器]
Other[其他平台适配器]
end
end
subgraph 云平台层 [第三方智能家居云平台]
TuyaCloud[涂鸦云 OpenAPI]
MiCloud[米家云 API]
HuaCloud[华为云 API]
end
subgraph 设备层 [物理设备层]
Device1[智能空调]
Device2[智能电视]
Device3[智能灯泡]
Gateway[厂商网关/路由器]
end
UI --> NLP
NLP --> Context
NLP --> Adapter
Adapter -.->|SDK集成/RESTful调用| Tuya
Adapter -.->|SDK集成/RESTful调用| Mi
Adapter -.->|SDK集成/RESTful调用| Huawei
Adapter -.->|...| Other
Tuya --> TuyaCloud
Mi --> MiCloud
Hua --> HuaCloud
TuyaCloud -->|WiFi/Zigbee| Gateway
MiCloud -->|WiFi/蓝牙Mesh| Gateway
HuaCloud -->|WiFi| Gateway
Gateway -->|局域网协议| Device1
Gateway -->|局域网协议| Device2
Gateway -->|局域网协议| Device3
```
---
### 图2：流程图（用户一次完整操作的业务决策流）
此图展示从用户输入到设备响应的完整逻辑判断与处理流程，重点突出**多平台路由选择**和**异常处理**。
```mermaid
flowchart TD
Start([用户发送语音/文本指令]) --> Parse[AI 进行意图识别与实体抽取]
Parse --> Check{是否为设备控制意图?}
Check -->|否| Chat[进入普通聊天/问答模式]
Chat --> End([返回文本回复])
Check -->|是| GetUser[获取用户绑定的第三方平台信息]
GetUser --> CheckBind{用户是否已授权<br>该平台账号?}
CheckBind -->|否| AskAuth[引导用户跳转至平台OAuth授权页]
AskAuth --> WaitAuth[等待回调获取AccessToken]
WaitAuth --> GetUser
CheckBind -->|是| SelectAdapter[根据平台类型选择适配器<br>（如 涂鸦/米家）]
SelectAdapter --> GetDevices[调用平台API获取设备列表<br>并匹配目标设备]
GetDevices --> FindDevice{是否找到目标设备?}
FindDevice -->|否| ErrorDevice[返回错误：<br>未找到对应名称/类型的设备]
ErrorDevice --> End
FindDevice -->|是| BuildCmd[将AI抽取的参数<br>（温度/模式/开关）转为平台标准指令]
BuildCmd --> CallAPI[调用平台控制API<br>发送指令到云端]
CallAPI --> CheckResp{API返回是否成功?}
CheckResp -->|失败（超时/权限/离线）| Retry{是否重试?}
Retry -->|是| CallAPI
Retry -->|否| ErrorCloud[返回错误：<br>设备离线或平台异常]
ErrorCloud --> End
CheckResp -->|成功| SyncCache[更新本地设备状态缓存]
SyncCache --> FormatRes[AI将API返回结果<br>整理为自然语言反馈]
FormatRes --> End([返回语音/文字执行结果给用户])
```
---
### 图3：时序图（核心交互细节与协议流）
此图细化用户、APP、第三方云端、设备之间的时序交互，特别标注了**OAuth 2.0授权流程**和**异步控制响应**。
```mermaid
sequenceDiagram
autonumber
actor User as 用户
participant App as AI APP (前端)
participant Backend as AI APP (后端服务)
participant Adapter as 平台适配器模块
participant Cloud as 第三方云平台 (如涂鸦)
participant Device as 智能设备/网关
Note over User, Device: 阶段一：账号绑定 (首次使用)
User->>App: 点击“绑定涂鸦账号”
App->>Backend: 发起授权请求
Backend->>Cloud: 重定向至OAuth授权页
Cloud-->>User: 弹出登录授权页面
User->>Cloud: 确认授权并输入密码
Cloud-->>Backend: 回调返回 Authorization Code
Backend->>Cloud: Code换取 AccessToken & RefreshToken
Cloud-->>Backend: 返回Token并存储
Note over User, Device: 阶段二：日常控制流程
User->>App: 语音指令：“把客厅空调设为26度制冷”
App->>Backend: 传输音频/文本
activate Backend
Backend->>Backend: 意图识别 (NLP) + 实体抽取<br>(客厅, 空调, 26℃, 制冷)
Backend->>Backend: 根据用户ID查询绑定平台<br>获取AccessToken
Backend->>Adapter: 调用统一控制接口<br>(控制参数)
activate Adapter
Adapter->>Adapter: 将通用参数转换为<br>平台特定指令 (JSON)
Adapter->>Cloud: POST /v1/device/control<br>(携带Token & 设备ID)
deactivate Adapter
activate Cloud
Cloud->>Cloud: 验证Token与设备权限
Cloud-->>Adapter: 返回控制指令ID (异步)
deactivate Cloud
Note over Cloud, Device: 云端下发指令
Cloud->>Device: 通过MQTT/CoAP协议<br>推送控制信令
Device->>Device: 执行动作 (开启空调, 调温)
Device-->>Cloud: 返回执行结果状态
Cloud-->>Backend: 异步回调 / 或APP轮询<br>获取设备最新状态
activate Backend
Backend-->>App: 返回结构化结果 (成功/失败)
deactivate Backend
App-->>User: TTS语音播报:<br>“好的，客厅空调已设置为26度制冷模式”
```
---
### 💡 补充说明
1. **授权机制（OAuth 2.0）**：这是路径一的**核心门槛**。用户必须在APP内授权登录其第三方平台账号（如小米账号），你的APP才能获取`AccessToken`调用平台API。
2. **设备状态同步**：平台API通常采用**异步回调**或**Webhook**通知状态变更。建议在你的后端维护一个**Redis缓存**，减少频繁查询设备状态导致的延迟和API限流风险。
3. **平台差异抽象**：架构图中的“适配器模式”至关重要。不同平台对“26度制冷”的JSON字段定义不同（如米家用`{“temp”:26}`，涂鸦可能用`{“temperature”:26}`），适配层能有效隔离这种差异。
4. **安全风险**：务必在后端安全存储用户的`RefreshToken`，并定期刷新`AccessToken`（通常有效期为2小时）。
### 接收设备状态
用 Webhook 接收设备状态，核心思路是**在云端平台（如涂鸦、米家）和你自己的后端服务器之间，建立一个“主动推送”的通道**。
这样一来，你就不再需要通过APP频繁轮询来查询状态，云端会在设备状态发生变化的**第一时间**，主动将数据推送给你的后端。
这里为你梳理了实现这个通道的通用步骤和针对不同主流平台的具体方案。
#### 📝 通用实现步骤
一个标准的 Webhook 接收流程通常如下：
1. **准备一个接收端**：在你的后端服务器上，开发一个**公网可访问的 HTTPS 接口（URL）** 来接收和解析云端推送的数据。这个接口需要能处理 `POST` 请求。
2. **在云端配置订阅**：登录你选择的智能家居平台（如涂鸦IoT平台），找到 Webhook 或消息推送的设置页面。
3. **填写回调URL**：将第一步准备好的接口 URL 填入平台的设置中。
4. **订阅事件类型**：选择你需要监听的事件，例如“设备上线/下线”、“设备状态变化”（如温度改变、开关动作）等。
5. **编写业务逻辑**：在你的后端接口中，解析平台 POST 过来的 JSON 或 XML 数据，更新你自己的数据库或触发后续的 AI 动作。
#### 🧩 不同主流平台的具体方案
##### 1. 涂鸦智能 (Tuya)
涂鸦提供了非常完善的消息推送机制，是路径一里最容易实现 Webhook 的平台之一。
* **核心机制**：涂鸦通过其 **云云对接 (Cloud-to-Cloud)** 的消息服务（通常是 Pulsar 消息队列）来实现。你需要做的，是在涂鸦IoT平台的“云开发”项目中，**订阅设备状态变化的Topic（主题）**。
* **关键点**：
* 涂鸦建议在生产环境中使用**消息队列**（如Pulsar）来接收设备事件，这比单纯的 HTTP Webhook 更可靠。如果并发量不高，也可以使用涂鸦提供的 **HTTP 回调 URL** 功能。
* 需要处理`AccessToken`的刷新，确保回调接口的认证不会过期。
* **实践参考**：有开发者使用 `n8n` 这类自动化工具配合涂鸦 Webhook，将设备事件转发到 CRM、工单系统或用于 AI 摘要生成。这证明了其对接的灵活性。
##### 2. 米家 (Xiaomi Mi Home)
米家官方对外的 Webhook 支持相对不直接，更多是通过间接方式实现。
* **核心机制**：米家本身是一个封闭的生态，**没有直接对外提供标准的 Webhook 接口**。要将米家设备状态接入，通常需要借助 **Home Assistant (HA)** 这个开源智能家居平台。
* **实践路径**：
1. 通过 `Xiaomi Miot Auto` 等集成，将米家设备接入 Home Assistant。
2. 在 Home Assistant 中，利用其强大的自动化与 Webhook 能力。例如，可以安装 `homeassistant-state-webhook` 这个自定义组件，当 HA 中的米家设备状态变化时，它会自动向你的 Webhook URL 发送 HTTP POST 请求。
3. 你甚至可以通过脚本截留和 Webhook 异步推送的方式，将米家设备状态无缝接入 HA。
##### 3. 华为智慧生活 (Huawei Smart Life)
华为平台也提供了云侧的状态查询和变更通知能力。
* **核心机制**：应用服务器可以在华为物联网平台**订阅“设备属性变化通知”**（资源为 `device.data`，事件为 `update`）。
* **实践路径**：
* 当设备属性数据发生变化时，平台会向你的服务器推送通知消息。
* 你需要提供一个公网可达的 HTTPS 接口来接收这些推送。接口需要能解析华为平台定义的消息格式。
* 通过这种方式，你可以实时获取设备的在线/离线状态、以及各类属性值的变化。
##### 4. Home Assistant (万能中转站)
Home Assistant (HA) 是一个非常强大的“设备状态聚合与转发中心”。如果上述平台的支持都不够理想，HA 可以作为中间层来解决。
* **核心机制**：HA 本身既可以作为**Webhook的发起方**，将内部设备状态变化推送给外部服务；也可以作为**Webhook的接收方**，接收外部设备或服务发来的 HTTP 请求并触发自动化。
* **实践价值**：它就像一个万能翻译官，能把几乎所有主流平台（米家、涂鸦、华为等）的设备状态统一起来，再通过一个标准的 Webhook 推送给你。
#### 💡 安全与测试建议
* **务必使用HTTPS**：确保你的 Webhook URL 是 `https` 开头的，保证数据传输的安全性。
* **进行身份验证**：在接口中验证请求是否来自可信的平台，例如通过验证签名（Sign）或特定的 `Token` 请求头。
* **快速响应**：你的接口应在几秒内返回 `HTTP 200 OK` 状态码，避免平台认为推送失败而进行重试。
* **使用测试工具**：在开发阶段，可以使用 **RequestBin** 这类服务来生成一个临时 URL，用于捕获和查看平台推送的原始数据，方便调试。
## 方案二： 连接标准（MCP）连接
### 图1：方案架构图（系统分层与组件关系）
此图展示MCP协议的完整分层架构，核心是**MCP Server作为标准化“翻译器”** ，将不同厂商设备（涂鸦、米家、Home Assistant等）的控制能力统一封装为AI可调用的“工具（Tools）”。
```mermaid
flowchart TB
subgraph 用户层 [用户交互层]
User[用户]
UI[AI APP 前端<br>（语音/文本输入）]
end
subgraph Host层 [MCP Host层]
Host[AI APP 核心服务<br>（意图识别/对话管理/多Client协调）]
LLM[大语言模型<br>（Claude/GPT/文心等）]
end
subgraph Client层 [MCP Client层]
Client1[MCP Client - 涂鸦]
Client2[MCP Client - 米家]
Client3[MCP Client - Home Assistant]
ClientN[MCP Client - 其他]
end
subgraph Server层 [MCP Server层 - 设备控制抽象]
Server1[涂鸦 MCP Server<br>]
Server2[米家 MCP Server<br>（通过HA桥接）]
Server3[Home Assistant MCP Server<br>]
ServerN[其他 MCP Server<br>（Matter/Shelly等）]
end
subgraph 设备层 [物理设备层]
TuyaCloud[涂鸦云平台]
MiCloud[米家云平台]
HACore[Home Assistant<br>核心服务]
Device1[智能空调]
Device2[智能电视]
Device3[智能灯泡]
Device4[传感器]
end
User -->|语音/文本指令| UI
UI --> Host
Host --> LLM
Host -->|创建并管理| Client1
Host -->|创建并管理| Client2
Host -->|创建并管理| Client3
Host -->|创建并管理| ClientN
Client1 <-->|JSON-RPC over<br>stdio/HTTP/SSE| Server1
Client2 <-->|JSON-RPC| Server2
Client3 <-->|JSON-RPC| Server3
ClientN <-->|JSON-RPC| ServerN
Server1 -->|HTTPS API| TuyaCloud
Server2 -->|HTTPS API| MiCloud
Server3 -->|REST + WebSocket| HACore
TuyaCloud -->|WiFi/Zigbee| Device1
TuyaCloud -->|WiFi/Zigbee| Device2
MiCloud -->|WiFi/蓝牙| Device3
HACore -->|MQTT/CoAP| Device4
style Host fill:#e1f5fe
style Client1 fill:#fff3e0
style Client2 fill:#fff3e0
style Client3 fill:#fff3e0
style ClientN fill:#fff3e0
style Server1 fill:#e8f5e9
style Server2 fill:#e8f5e9
style Server3 fill:#e8f5e9
style ServerN fill:#e8f5e9
```
**关键点说明：**
- **MCP Host**：你的AI APP本身，负责管理多个MCP Client实例，每个Client连接一个MCP Server
- **MCP Client**：协议层面的通信组件，每个Client与对应的Server保持专用连接
- **MCP Server**：将设备控制能力封装为标准化的“工具（Tools）”，如`turn_on_light`、`set_ac_temperature`等
- **传输层**：支持stdio（本地进程通信）、Streamable HTTP（远程服务）等多种传输方式
### 图2：流程图（MCP核心交互流程）
此图展示从用户输入到设备响应的完整MCP协议交互流程，重点突出**工具发现（Tool Discovery）** 和**工具调用（Tool Execution）** 两大阶段。
```mermaid
flowchart TD
Start([用户发送语音/文本指令]) --> Parse[Host: 意图识别与实体抽取]
Parse --> Check{是否为设备控制意图?}
Check -->|否| Chat[进入普通聊天/问答模式]
Chat --> End([返回文本回复])
Check -->|是| CheckInit{MCP Client<br>是否已初始化?}
CheckInit -->|否| Init[阶段一: MCP初始化握手]
Init --> Step1[Client → Server: initialize<br>（协议版本/客户端能力）]
Step1 --> Step2[Server → Client: initialize响应<br>（服务端能力/工具列表）]
Step2 --> Step3[Client → Server: notifications/initialized<br>（初始化完成通知）]
Step3 --> Discover
CheckInit -->|是| Discover[阶段二: 工具发现]
Discover --> List[Client → Server: tools/list<br>请求可用工具列表]
List --> ToolsResp[Server → Client: 返回工具定义<br>（名称/描述/参数Schema）]
ToolsResp --> Cache[Host缓存工具列表<br>并注入LLM系统提示词]
Cache --> Decide{LLM判断<br>是否需要调用工具?}
Decide -->|否| Direct[直接生成文本回复]
Direct --> End
Decide -->|是| Select[LLM选择匹配的工具及参数<br>（如 set_ac_temperature）]
Select --> Call[阶段三: 工具调用]
Call --> Exec[Client → Server: tools/call<br>（工具名+参数）]
Exec --> ServerHandle[MCP Server处理请求]
ServerHandle --> Map[将MCP工具参数<br>转换为设备原生指令]
Map --> DeviceCall[调用设备API<br>（涂鸦云/米家云/HA等）]
DeviceCall --> CheckResp{设备响应成功?}
CheckResp -->|失败| Retry{是否重试?}
Retry -->|是| DeviceCall
Retry -->|否| Error[Server返回错误结果]
Error --> FormatErr[Host格式化为自然语言]
FormatErr --> End
CheckResp -->|成功| Result[Server返回执行结果<br>（JSON-RPC响应）]
Result --> Update[Host更新设备状态缓存]
Update --> Format[Host将结果格式化为自然语言]
Format --> End([返回语音/文字执行结果])
```
### 图3：时序图（MCP协议完整交互细节）
此图细化Host、Client、Server、LLM、设备之间的完整时序交互，包含**初始化握手**、**工具发现**、**工具调用**三个阶段。
```mermaid
sequenceDiagram
autonumber
actor User as 用户
participant Host as MCP Host (AI APP)
participant Client as MCP Client
participant LLM as 大语言模型
participant Server as MCP Server (设备控制)
participant DeviceAPI as 设备云平台/HA
participant Device as 智能设备
Note over User, Device: 阶段一：MCP初始化握手（首次启动或连接新Server）
Host->>+Client: 创建Client实例，准备连接Server [ref:26]
Client->>+Server: 1. initialize (JSON-RPC)\n{protocol_version, client_capabilities} [ref:27]
Note over Client,Server: 能力协商：告知Server支持的工具调用、资源读取等能力
Server-->>-Client: 2. initialize 响应\n{selected_version, server_capabilities} [ref:28]
Note over Client,Server: Server告知支持的功能（tools/resources/prompts）
Client->>Server: 3. notifications/initialized [ref:29]
Note over Client,Server: 握手完成，进入正常通信模式
Client-->>-Host: 初始化成功，Server就绪 [ref:30]
Note over User, Device: 阶段二：工具发现（获取可用设备控制能力）
Host->>+Client: 4. 请求获取工具列表
Client->>+Server: 5. tools/list (JSON-RPC) [ref:31]
Server-->>-Client: 6. 返回工具定义列表\n[{name:"set_ac_temp", ...}, {name:"turn_on_light", ...}] [ref:32]
Client-->>-Host: 7. 返回工具列表 [ref:33]
Host->>Host: 缓存工具定义，构建工具提示词
Host->>LLM: 8. 系统提示词 + 可用工具列表 [ref:34]
Note over Host,LLM: LLM获知可用的设备控制工具及其调用方式
Note over User, Device: 阶段三：工具调用（用户发起控制）
User->>Host: 9. "把客厅空调设为26度制冷"
Host->>LLM: 10. 转发用户指令 + 上下文
LLM->>LLM: 11. 理解意图，选择工具\n→ set_ac_temperature(location:"客厅", temp:26, mode:"cool")
%% 修复：去掉了 -Host，因为此时 Host 并未处于激活状态
LLM-->>Host: 12. 返回工具调用请求
Host->>+Client: 13. 执行工具调用\ntools/call(set_ac_temperature, {...}) [ref:35]
Client->>+Server: 14. tools/call (JSON-RPC)
Server->>Server: 15. 参数验证与映射\n（MCP参数 → 设备原生指令）
Server->>+DeviceAPI: 16. 调用设备控制API\n（HTTPS/MQTT/CoAP）
DeviceAPI->>+Device: 17. 下发控制信令\n（WiFi/Zigbee/蓝牙）
Device->>Device: 18. 执行动作
Device-->>-DeviceAPI: 19. 返回执行结果
DeviceAPI-->>-Server: 20. 返回API响应
Server-->>-Client: 21. 返回工具执行结果（JSON-RPC响应） [ref:36]
Client-->>-Host: 22. 返回执行结果
Host->>Host: 23. 更新设备状态缓存
Host->>LLM: 24. 将执行结果交给LLM生成回复
LLM-->>Host: 25. "好的，客厅空调已设置为26度制冷模式"
Host-->>User: 26. TTS语音播报结果
```
### MCP 接入方案
#### 设备内置 MCP Server（对设备商最友好，无需 APP）
这是对设备商和用户都最理想的方式。**设备本身就运行着一个 MCP Server**，你的 AI APP 直接通过网络（局域网或互联网）与设备通信。
- **如何实现**：设备商在硬件（如 ESP32 微控制器）的固件中，直接实现一个轻量级的 MCP Server。这可以理解为给设备装了一个“AI 能直接对话的接口”。
- **实际案例**：已有为 ESP32 设计的 MCP Server 框架，开发者可以用它在设备上直接定义和注册工具（如 `turn_on_light`），让 AI 通过 HTTP 直接调用。同时，也有将传统串口通信封装为 MCP Server 的方案，让 AI 能直接与嵌入式系统交互。
- **设备商工作**：只需在固件开发中集成 MCP 协议，无需开发和维护任何手机 APP。
- **你的工作**：你的 APP 作为 MCP Client，通过 HTTP 或 WebSocket 直接连接设备的 IP 地址即可[](https://pub.dev/documentation/flutter_mcp_client_lib/1.0.3/)
建议可以分两步走：
1. **优先支持 mDNS / DNS-SD**：这是**局域网**场景下最主流、最便捷的发现方式，能让你的 APP 在家庭等常见环境中自动发现设备。
2. **规划支持 DNS TXT 或 Well-Known URI**：这是**远程访问**场景的未来标准[](https://datatracker.ietf.org/doc/html/draft-morrison-mcp-dns-discovery-01)[](https://datatracker.ietf.org/doc/html/draft-serra-mcp-discovery-uri-04)，能让你的 APP 具备连接广域网上 MCP 设备的能力，更具前瞻性。
### 💡 补充说明
1. **MCP的核心优势**：MCP通过标准化的JSON-RPC 2.0协议，让AI应用与外部工具之间实现**统一接口**，无需为每个设备厂商单独编写适配代码。一个MCP Server代表一个**单一领域或能力域**。
2. **传输方式选择**：
- **stdio**：本地进程通信，适合Claude Desktop等桌面应用
- **Streamable HTTP**：远程服务，适合云端部署的MCP Server
- **SSE（Server-Sent Events）** ：适合需要服务端主动推送的场景
3. **MCP Server的三种核心能力**：
- **Tools（工具）** ：AI可主动调用的函数，如开关灯、调温度——**设备控制主要依赖此能力**
- **Resources（资源）** ：只读数据源，如设备状态、传感器读数
- **Prompts（提示词模板）** ：预定义的交互模板
4. **已有生态案例**：
- **mcp-hass**：将Home Assistant的实体、设备、区域暴露为MCP工具
- **Tuya MCP Service**：涂鸦开源的MCP服务，支持WebSocket + Streamable HTTP双模
- **MCP2MQTT**：桥接MCP协议与MQTT协议，让AI控制MQTT硬件
- **Matter Controller MCP**：通过MCP协议控制Matter兼容设备
5. **安全与权限**：MCP强调**人工监督**，应用可以实现工具执行前的**审批对话框**、**权限预审批**、**操作审计日志**等机制。
docs/architecture/灵迈整体设计思路.md
+52
View File
@@ -0,0 +1,52 @@
# 整体思路
## 1 产品定位
面向大众的开箱即用多功能智能体，通过极简交互和强大自进化能力，成为个人工作生活的全能助手，以及企业智能化转型的统一入口。
## 2 产品架构与版本分支
产品分为 **个人版** 与 **企业版**，共同基于多模态大模型基座和Agent框架。
- **个人版**：强调易用性、低门槛，PC本地部署完全免费，调用云端Token按量付费，提供多种基座模型选择。
- **企业版**：强调安全性、权限控制和后台数据整合，适配企业组织架构，支持本地+云混合部署。
## 3 核心功能矩阵
1. **Agent设计与Skill自进化**：用户可自行设计专属Agent，系统根据使用习惯和反馈自动优化Skill，实现“越用越聪明”。
2. **多模态个人知识库一键搭建**：支持文本、图片、音视频等多模态数据，拖拽上传即可自动构建向量库和知识图谱，实现知识快速检索与问答。
3. **记忆与遗忘机制**：模拟人脑记忆曲线，对聊天记录进行重要性判断、知识提取（形成向量和知识图谱），对低价值信息按策略“遗忘”，形成高效的长期数字记忆。
4. **跨终端无缝连接**：通过云端服务器同步PC端与移动App，实现工作流和记忆体跨设备接续。
5. **实时信息获取**：连接微信、微博、抖音等社交平台，经授权后获取公开实时信息，辅助决策和内容创作。
6. **开放生态与第三方Agent**：提供标准化接口和自建知识库、提示词工具，任何企业或开发者均可创建垂直服务Agent。可与外卖平台、电商平台合作，基于用户画像自动推荐并执行点餐、购物等任务。
## 4 Skills交易市场
围绕赛博生命构建 **Skills交易生态**：
- **Skill开发与上传**：开发者可上传自研Skill，平台自动检测质量与安全性。
- **Skill交易与分成**：明码标价或订阅制，平台抽取技术服务费，鼓励生态繁荣。
- **Skill大赛与孵化**：定期举办开发大赛，联合IP代办机构提供知识产权代办服务，促进高质量Skill产出与保护。
## 5 小程序
开放小程序接口，允许第三方小程序（H5）接入（经过审核），可以在灵迈中直接搜索打开小程序，小程序打开后（移动端的情况下），灵迈以浮动窗口的形式保留在界面中，仍然能提供导航和解答服务。小程序提供商可以设计自己的提示词和知识库供灵迈使用。
应用场景：
场景一：遇到需要心肺复苏的病人，热心群众打开Lingmind APP，他告诉 AI 有一个病人需求急救，AI 根据用户坐标主动打开当地急救APP，联系专家指导用户实施急救。
场景二：你想要看电影，告诉 AI 你想看什么电影，AI 根据这些信息打开小程序定位到相应的电影院购票页面让你选择坐标并完成购票。
## 6 智能设备（智能家居）
详细可参看 [[智能家居实现方案]]
## 5 企业版增值能力
- **垂直行业Agent**：预置法律、金融、制造等领域Agent模板，开箱即用。
- **后台数据整合与孤岛打通**：通过标准化连接器和低代码工具，安全整合企业OA、ERP、CRM等多源异构数据，构建统一数据视图。
- **权限与审计**：细粒度角色控制，全操作日志审计，满足企业合规要求。
# 头脑风暴
1. AI聊天需将时间戳、地址（IP所在区域）、等实时信息作为上下文。对于企业版，还有职位、角色等信息。
2. 在虚拟浏览器端和 Agent 端增加危险操作（如删除数据等）拦截层。
3.