project-nova · 智能体框架与编排

场景引入：你的 AI 助手，能操控你的 DAW、点灯和知识库吗？

想象这样一个场景：深夜创作时，你随口对 AI 说一句"帮我把客厅灯调暗，顺手把 Ableton 的鼓 rack 换成 808"，然后——它真的做了。

这不是科幻。Project NOVA 正在把这件事变成现实：一个能同时操控 Home Assistant 智能家居、Ableton 音乐工作站、Trilium 知识库和 Gitea 代码仓库的多智能体系统，全部通过自然语言驱动。

背景：从"万能助手"到"专家网络"

2025年5月，开发者 Dujon Walker 在 GitHub 上传了这个项目，定位是"Networked Orchestration of Virtual Agents"——网络化虚拟智能体编排。项目初衷很明确：市面上的 AI 助手要么太通用（什么都能做但都不精），要么太垂直（只能做一件事）。

NOVA 的解法是Hub-and-Spoke 架构：一个中央路由器 Agent 作为入口，理解用户意图后，把请求精准路由到对应的专业子 Agent。每个子 Agent 背后是一个独立的 MCP（Model Context Protocol）服务器，各自负责一个领域。

这个设计理念并非凭空出现。MCP 协议由 Anthropic 在 2024 年末提出，旨在解决 LLM 与外部工具之间的"连接标准化"问题。NOVA 巧妙地利用了这一协议，把原本分散的 AI 能力整合成了协同网络。

Project NOVA 系统架构图

图1：Project NOVA 系统架构图。 中央路由器 Agent 接收用户请求，通过 n8n 工作流引擎路由到 25+ 专属 MCP 服务器，再由各服务执行实际操作（如操控智能家居、查询知识库、驱动 DAW 等）。

类比：给 AI 建一座"指挥中心"

可以把 NOVA 想象成一个五星级酒店的礼宾部：

前台（Router Agent）：理解客人的需求，判断这件事该找哪个部门。
各专业部门（Sub-Agents）：有专门管行李的、管订餐的、管叫车的——每个都把本领域做到极致。
工作流程引擎（n8n）：负责协调各部门之间的信息传递，确保客人的需求完整传递。
统一对话界面（OpenWebUI）：客人只和一个前台打交道，不知道后台有多少部门在协作。

用户不需要知道知识库用什么 API、音乐软件怎么操作——就像住酒店不需要知道厨房怎么运作一样。

核心功能：25个专家 Agent，覆盖五大领域

知识管理与笔记

Agent	对接应用	核心能力
TriliumNext Agent	TriliumNext Notes	层级笔记的增删改查
Blinko Agent	Blinko	快笔记、每日回顾
BookStack Agent	BookStack	文档检索
Memos Agent	Memos	轻量笔记
SiYuan Agent	SiYuan Note	个人知识管理
Karakeep Agent	Karakeep	数字内容收藏与书签
Paperless Agent	Paperless-NGX	文档归档管理
OnlyOffice Agent	ONLYOFFICE DocSpace	协作文档管理

场景示例："帮我找到上周三关于数据库设计的所有笔记"，Router Agent 会自动将请求路由到对应笔记系统的 Agent，跨多个平台搜索后整合结果返回。

开发与仓库管理

Agent	对接应用	核心能力
CLI Server Agent	终端	安全命令行执行
Forgejo Agent	Forgejo	Git 仓库和 Issue 管理
Gitea Agent	Gitea	Git 仓库操作
System Search Agent	本地文件系统	全局文件搜索

场景示例："检查我所有包含 Hetzner 关键字的仓库，看看有没有未合并的 PR"，Gitea Agent 会直接查询你的 Gitea 实例并返回真实数据——不是 AI 编造的答案。

媒体与创意工具

Agent	对接应用	核心能力
Ableton Copilot	Ableton Live	音乐项目创建、乐器加载
OBS Agent	OBS Studio	直播/录制控制
REAPER Agent	REAPER DAW	数字音频工作流
REAPER QA Agent	REAPER	项目分析与问答
YouTube Agent	YouTube	视频转录与内容摘要

场景示例："帮我建一个带 808 鼓机的 Ableton 项目"——Ableton Copilot Agent 接管后，会调用 MCP 工具模拟用户在 Ableton 中的操作流程。这在独立音乐制作人中获得了较高关注。

AI 与自动化

Agent	对接应用	核心能力
Flowise Agent	Flowise	AI 对话流编排
Langfuse Agent	Langfuse	Prompt 版本管理
Puppeteer Agent	浏览器	网页抓取与自动化
RAGFlow Agent	RAGFlow	带溯源的检索增强生成
Fetch Agent	任意 URL	网页内容获取

监控与智能家居

Agent	对接应用	核心能力
Home Assistant Agent	Home Assistant	全屋智能设备控制
Prometheus Agent	Prometheus	时序指标查询与分析

场景示例："过去 24 小时我服务器的 CPU 使用率如何？"——Prometheus Agent 直接查询你的监控数据库，返回真实数据而非大模型的幻觉答案。

技术实现：架构与代码剖析

路由器 Agent（Router Agent）

Router Agent 是整个系统的决策中枢，运行逻辑由 agents/router-agent.md 定义。其 prompt 采用规则优先 + 语义兜底的双层判断：

服务名直连规则（Service-name short-circuit）：用户消息中若明确提到具体服务（如"Blinko"、"OBS"、"REAPER"），直接路由对应 Agent，不做任何语义分析——这是最快路径。
语义分类兜底：无明确服务名时，分析用户意图归类到五大领域（知识管理、开发、媒体、AI自动化、监控家居），再匹配合适的 Sub-Agent。

Router Agent 的输出格式是结构化的：

SELECTED AGENT: <agent_id>
REASON: <一句话解释为什么选这个Agent>
USER_MESSAGE: <原始用户消息>

这种格式设计是为了让 n8n 工作流能直接解析。Router Agent 本身不执行任何工具调用，严格遵循"路由即退出"原则——这避免了越权风险。

n8n 工作流编排层

所有 Agent 的执行流程由 n8n-workflows/ 目录下的 JSON 工作流文件定义。主路由器工作流（router_agent.json，约 111KB）包含多个 LangChain 节点，核心逻辑：

Chat Trigger：接收 OpenWebUI 传来的用户消息
Router Agent Node：调用 LLM（默认 Claude Sonnet 4）执行路由决策
分支节点：根据路由结果分发到对应 Sub-Agent 工作流
结果聚合：将 Sub-Agent 执行结果整合后返回 OpenWebUI

每个 Sub-Agent 也有独立的工作流 JSON（如 gitea_agent.json），定义了各自的 MCP Server 连接和工具调用链。值得注意的是，所有 Agent 工作流都使用 n8n 内置的 MCP Client Tool 节点，无需安装任何社区节点，降低了维护成本。

MCP Server 容器化

每个 Sub-Agent 对应一个 MCP Server，共 25 个，全部容器化在 mcp-server-dockerfiles/ 目录下。以 TriliumNext MCP 为例：

FROM node:20-slim
WORKDIR /app
RUN apt-get update && apt-get install -y git && apt-get clean
RUN git clone https://github.com/tan-yong-sheng/triliumnext-mcp.git /app
RUN npm install && npm run build
RUN npm install -g supergateway   # SSE 网关，用于 MCP 协议通信
COPY start.sh /app/start.sh
CMD ["/app/start.sh"]

对应的 docker-compose.yml 定义了服务发现、网络隔离和环境变量注入。25 个 MCP Server 各自独立部署，按需启动——不需要全部安装，只用 Home Assistant 就只启动 Home Assistant Agent 的容器即可。

OpenWebUI 集成层

OpenWebUI 作为前端对话界面，通过 openwebui-function/n8n_inlet_filter.py 插件接入 n8n 工作流。这是一个 OpenWebUI 过滤器（Filter），在 inlet 阶段拦截用户消息：

class Filter:
    class Valves(BaseModel):
        n8n_url: str = Field(default="http://localhost:5678/webhook/[your-uuid]")
        n8n_bearer_token: str = Field(default="testauth")
        timeout: int = Field(default=30)
        enabled: bool = Field(default=True)

消息经过 MD5 去重后转发至 n8n Webhook，n8n 执行工作流并将结果注入到 LLM 响应中。注意：使用语音输入（text-to-speech）功能时，OpenWebUI 要求 HTTPS 环境（自签名证书亦可）。

agent.yaml 规范

项目定义了 agent.yaml 作为 Agent 规范元数据：

模型选择：默认 Claude Sonnet 4，温度 0.3（低随机性，保证路由稳定性）
安全机制：破坏性操作（文件删除、设备控制）需要人工确认（human_in_the_loop）
数据治理：PII 处理采用脱敏模式（redact）
审计日志：所有操作均有记录

上手体验：安装门槛与实际难度

最低门槛（纯 n8n 模式）

如果你只需要通过文字与 NOVA 交互，不需要 OpenWebUI 界面，则只需要：

部署一个 n8n 实例（v1.88.0+）
导入 n8n-workflows/ 下的工作流 JSON
启动需要的 MCP Server 容器（如 Home Assistant Agent）
配置环境变量（各服务 API 地址和 Token）

预计时间：30-60 分钟（取决于需要几个 Agent）

硬件需求

纯容器运行时，无需 GPU，约需 4GB RAM 和 10GB 磁盘。实际需求取决于同时运行的 MCP Server 数量——全部 25 个同时跑在 4GB 内存机器上会比较吃力，建议有 8GB+。

争议与局限

1. MCP 生态的碎片化风险

NOVA 依赖 25 个来自不同开发者的 MCP Server——每个 Server 的维护状态、更新频率和质量标准参差不齐。部分 Server（如 custom-blinko-mcp）使用了自定义实现而非官方 MCP SDK，长期兼容性存疑。

2. LLM 路由决策的质量依赖

Router Agent 的路由准确率完全取决于所用 LLM 的能力。使用 Claude Sonnet 4 效果良好，但切换到普通模型可能导致频繁路由错误。用户需要为 Router Agent 配备足够强的模型。

3. 部分 Agent 功能深度有限

实测发现，部分 Agent（如 REAPER QA Agent）主要功能是"分析 REAPER 项目文件并回答问题"，而非直接操作 DAW。这意味着"帮我加一条鼓轨"这类操作可能仍需 Ableton Copilot 单独处理，QA Agent 只能提供参考信息。

4. 部署复杂度不低

虽然每个 MCP Server 有 docker-compose，但完整搭建 NOVA 仍需要理解 n8n 工作流、OpenWebUI 配置、MCP 协议等多层技术概念。对于非技术用户，上手门槛依然较高。

行业意义：多 Agent 协作的工程范式

Project NOVA 的出现代表了 2025 年 AI Agent 领域的一个重要方向——从单 Agent 到 Agent 网络。

早期的 AI 助手（GPT-4、CClaude 1.x）本质上是"单 Agent"，所有能力都在一个模型里。NOVA 则展示了另一种可能：多个专业化 Agent 通过标准化协议互联，形成能力集群。这个思路与 Anthropic 的 MCP 协议、Google 的 Agent-to-Agent (A2A) 协议方向一致。

从增长曲线看，项目于 2025 年 5 月创建，至分析时（2026年7月）已有 268 Stars、37 Forks、持续活跃的 commits。25 个 MCP Server 的 docker-compose 方案解决了"AI 工具碎片化"的核心痛点——开发者不需要逐个配置每个 Agent 的运行环境。

更值得关注的是GitAgent Protocol的引入（见 SOUL.md）。这是一个让 Agent 能够读写 Git 仓库的标准协议，意味着未来的 NOVA Agent 网络可以自主 Fork、PR、合并其他开源项目的代码——AI 之间互相协作的时代，正在从愿景走向工程实现。

场景引入：你的 AI 助手，能操控你的 DAW、点灯和知识库吗？

想象这样一个场景：深夜创作时，你随口对 AI 说一句"帮我把客厅灯调暗，顺手把 Ableton 的鼓 rack 换成 808"，然后——它真的做了。

背景：从"万能助手"到"专家网络"

Project NOVA 系统架构图

类比：给 AI 建一座"指挥中心"

可以把 NOVA 想象成一个五星级酒店的礼宾部：

前台（Router Agent）：理解客人的需求，判断这件事该找哪个部门。
各专业部门（Sub-Agents）：有专门管行李的、管订餐的、管叫车的——每个都把本领域做到极致。
工作流程引擎（n8n）：负责协调各部门之间的信息传递，确保客人的需求完整传递。
统一对话界面（OpenWebUI）：客人只和一个前台打交道，不知道后台有多少部门在协作。

用户不需要知道知识库用什么 API、音乐软件怎么操作——就像住酒店不需要知道厨房怎么运作一样。

核心功能：25个专家 Agent，覆盖五大领域

知识管理与笔记

Agent	对接应用	核心能力
TriliumNext Agent	TriliumNext Notes	层级笔记的增删改查
Blinko Agent	Blinko	快笔记、每日回顾
BookStack Agent	BookStack	文档检索
Memos Agent	Memos	轻量笔记
SiYuan Agent	SiYuan Note	个人知识管理
Karakeep Agent	Karakeep	数字内容收藏与书签
Paperless Agent	Paperless-NGX	文档归档管理
OnlyOffice Agent	ONLYOFFICE DocSpace	协作文档管理

场景示例："帮我找到上周三关于数据库设计的所有笔记"，Router Agent 会自动将请求路由到对应笔记系统的 Agent，跨多个平台搜索后整合结果返回。

开发与仓库管理

Agent	对接应用	核心能力
CLI Server Agent	终端	安全命令行执行
Forgejo Agent	Forgejo	Git 仓库和 Issue 管理
Gitea Agent	Gitea	Git 仓库操作
System Search Agent	本地文件系统	全局文件搜索

媒体与创意工具

Agent	对接应用	核心能力
Ableton Copilot	Ableton Live	音乐项目创建、乐器加载
OBS Agent	OBS Studio	直播/录制控制
REAPER Agent	REAPER DAW	数字音频工作流
REAPER QA Agent	REAPER	项目分析与问答
YouTube Agent	YouTube	视频转录与内容摘要

AI 与自动化

Agent	对接应用	核心能力
Flowise Agent	Flowise	AI 对话流编排
Langfuse Agent	Langfuse	Prompt 版本管理
Puppeteer Agent	浏览器	网页抓取与自动化
RAGFlow Agent	RAGFlow	带溯源的检索增强生成
Fetch Agent	任意 URL	网页内容获取

监控与智能家居

Agent	对接应用	核心能力
Home Assistant Agent	Home Assistant	全屋智能设备控制
Prometheus Agent	Prometheus	时序指标查询与分析

场景示例："过去 24 小时我服务器的 CPU 使用率如何？"——Prometheus Agent 直接查询你的监控数据库，返回真实数据而非大模型的幻觉答案。

技术实现：架构与代码剖析

路由器 Agent（Router Agent）

Router Agent 是整个系统的决策中枢，运行逻辑由 agents/router-agent.md 定义。其 prompt 采用规则优先 + 语义兜底的双层判断：

服务名直连规则（Service-name short-circuit）：用户消息中若明确提到具体服务（如"Blinko"、"OBS"、"REAPER"），直接路由对应 Agent，不做任何语义分析——这是最快路径。
语义分类兜底：无明确服务名时，分析用户意图归类到五大领域（知识管理、开发、媒体、AI自动化、监控家居），再匹配合适的 Sub-Agent。

Router Agent 的输出格式是结构化的：

SELECTED AGENT: <agent_id>
REASON: <一句话解释为什么选这个Agent>
USER_MESSAGE: <原始用户消息>

这种格式设计是为了让 n8n 工作流能直接解析。Router Agent 本身不执行任何工具调用，严格遵循"路由即退出"原则——这避免了越权风险。

n8n 工作流编排层

所有 Agent 的执行流程由 n8n-workflows/ 目录下的 JSON 工作流文件定义。主路由器工作流（router_agent.json，约 111KB）包含多个 LangChain 节点，核心逻辑：

Chat Trigger：接收 OpenWebUI 传来的用户消息
Router Agent Node：调用 LLM（默认 Claude Sonnet 4）执行路由决策
分支节点：根据路由结果分发到对应 Sub-Agent 工作流
结果聚合：将 Sub-Agent 执行结果整合后返回 OpenWebUI

MCP Server 容器化

每个 Sub-Agent 对应一个 MCP Server，共 25 个，全部容器化在 mcp-server-dockerfiles/ 目录下。以 TriliumNext MCP 为例：

FROM node:20-slim
WORKDIR /app
RUN apt-get update && apt-get install -y git && apt-get clean
RUN git clone https://github.com/tan-yong-sheng/triliumnext-mcp.git /app
RUN npm install && npm run build
RUN npm install -g supergateway   # SSE 网关，用于 MCP 协议通信
COPY start.sh /app/start.sh
CMD ["/app/start.sh"]

OpenWebUI 集成层

OpenWebUI 作为前端对话界面，通过 openwebui-function/n8n_inlet_filter.py 插件接入 n8n 工作流。这是一个 OpenWebUI 过滤器（Filter），在 inlet 阶段拦截用户消息：

class Filter:
    class Valves(BaseModel):
        n8n_url: str = Field(default="http://localhost:5678/webhook/[your-uuid]")
        n8n_bearer_token: str = Field(default="testauth")
        timeout: int = Field(default=30)
        enabled: bool = Field(default=True)

agent.yaml 规范

项目定义了 agent.yaml 作为 Agent 规范元数据：

模型选择：默认 Claude Sonnet 4，温度 0.3（低随机性，保证路由稳定性）
安全机制：破坏性操作（文件删除、设备控制）需要人工确认（human_in_the_loop）
数据治理：PII 处理采用脱敏模式（redact）
审计日志：所有操作均有记录

上手体验：安装门槛与实际难度

最低门槛（纯 n8n 模式）

如果你只需要通过文字与 NOVA 交互，不需要 OpenWebUI 界面，则只需要：

部署一个 n8n 实例（v1.88.0+）
导入 n8n-workflows/ 下的工作流 JSON
启动需要的 MCP Server 容器（如 Home Assistant Agent）
配置环境变量（各服务 API 地址和 Token）

预计时间：30-60 分钟（取决于需要几个 Agent）

硬件需求

争议与局限

1. MCP 生态的碎片化风险

2. LLM 路由决策的质量依赖

3. 部分 Agent 功能深度有限

4. 部署复杂度不低

行业意义：多 Agent 协作的工程范式

Project NOVA 的出现代表了 2025 年 AI Agent 领域的一个重要方向——从单 Agent 到 Agent 网络。

场景引入：你的 AI 助手，能操控你的 DAW、点灯和知识库吗？

背景：从"万能助手"到"专家网络"

类比：给 AI 建一座"指挥中心"

核心功能：25个专家 Agent，覆盖五大领域

知识管理与笔记

开发与仓库管理

媒体与创意工具

AI 与自动化

监控与智能家居

技术实现：架构与代码剖析

路由器 Agent（Router Agent）

n8n 工作流编排层

MCP Server 容器化

OpenWebUI 集成层

agent.yaml 规范

上手体验：安装门槛与实际难度

最低门槛（纯 n8n 模式）

推荐门槛（OpenWebUI + n8n 模式）

硬件需求

争议与局限

1. MCP 生态的碎片化风险

2. LLM 路由决策的质量依赖

3. 部分 Agent 功能深度有限

4. 部署复杂度不低

行业意义：多 Agent 协作的工程范式

场景引入：你的 AI 助手，能操控你的 DAW、点灯和知识库吗？

背景：从"万能助手"到"专家网络"

类比：给 AI 建一座"指挥中心"

核心功能：25个专家 Agent，覆盖五大领域

知识管理与笔记

开发与仓库管理

媒体与创意工具

AI 与自动化

监控与智能家居

技术实现：架构与代码剖析

路由器 Agent（Router Agent）

n8n 工作流编排层

MCP Server 容器化

OpenWebUI 集成层

agent.yaml 规范

上手体验：安装门槛与实际难度

最低门槛（纯 n8n 模式）

推荐门槛（OpenWebUI + n8n 模式）

硬件需求

争议与局限

1. MCP 生态的碎片化风险

2. LLM 路由决策的质量依赖

3. 部分 Agent 功能深度有限

4. 部署复杂度不低

行业意义：多 Agent 协作的工程范式