1. 项目概述一个将智能与执行分离的本地AI系统如果你和我一样对市面上那些“全能”的AI助手既爱又怕那么NovaLIS的出现可能正好切中了我们的痛点。我们爱它们的智能但怕它们的“自作主张”——一个不小心它可能就帮你把邮件发了、把文件删了或者用你的口吻说了些你并不想说的话。NovaLIS全称Nova Local Intelligence System就是为了解决这个核心矛盾而生的。它不是一个试图变得更“聪明”来接管一切的AI而是一个将“思考”与“行动”进行强制分离的治理框架。简单来说它让AI负责“想”但把“做”的决定权和审计权牢牢地交还给你。这个项目的关键词很能说明问题local-first本地优先、privacy隐私、governed受治理的。它基于ollama这类本地大模型运行默认支持gemma4用python编写本质上是一套platform-engineering平台工程的实践旨在构建一个安全、可控的AI助手环境。它的设计哲学非常鲜明智能可以无限扩展但权限绝不能在没有明确解锁的情况下扩张。这意味着Nova可以和你深入讨论问题、帮你起草邮件、规划工作流但任何涉及真实世界操作的动作——比如发送邮件、修改文件、调用API——都必须经过一道明确的“能力门禁”、策略检查和完整的审计日志记录。2. 核心设计理念为什么需要“分离”智能与执行市面上的主流AI助手无论是云端服务还是某些本地应用大多采用了一种“混合模式”。你问它“帮我给客户张三发封邮件说项目延期了”它可能会直接调用你的邮件客户端或API把邮件发出去。这个过程看似流畅实则黑盒你并不清楚在“思考发什么内容”和“实际点击发送”之间系统内部做了哪些判断、是否有越权行为、是否有完整的操作回溯。2.1 传统AI助手的“权责模糊”困境这种权责模糊的设计带来了几个显著问题安全风险一旦AI模型被诱导Prompt Injection或产生幻觉Hallucination它可能执行危险操作而用户可能事后才察觉。审计困难当出现问题时很难追溯是用户指令不明确、AI理解错误还是系统执行了未授权的操作。日志往往是分散的、不完整的。信任缺失用户无法建立对系统的深度信任因为不清楚它的“行动边界”在哪里总感觉有一个不受控的代理在后台运行。合规挑战在企业或受监管的环境中这种模糊性使得系统很难通过安全审计和合规性检查。2.2 NovaLIS的“职责分离”架构NovaLIS的解决方案是借鉴了计算机系统设计中经典的“权限分离”原则。它将一个AI助手的完整工作流拆解成几个界限分明的职责层对话与推理层这是AI的“大脑”由ollama托管的gemma4这类模型负责。它的工作是理解用户意图、进行逻辑推理、生成计划、撰写文本、回答问题。它只有“建议权”没有“执行权”。例如它可以生成一封完美的邮件草稿甚至生成一个调用发送邮件API的代码片段但它不能自己调用这个API。能力定义层这是一个明确的“白名单”清单。它定义了系统理论上可以做什么比如“读取~/Documents目录”、“调用发送邮件的API”、“执行一个Shell命令”。每个能力都有严格的输入输出规范和元数据描述。这就像给AI一套工具手册告诉它世界上存在这些工具以及工具的规范用法。治理检查层这是最关键的安全阀门。当一个动作请求由对话层提出需要被执行时它不会直接发生。这个请求会先送到治理层。治理层会根据预设的策略例如“工作时段外禁止发送邮件”、“禁止删除.git目录”、上下文用户身份、环境进行实时检查。只有明确通过检查的请求才会被放行。审计记录层所有事情都会被记录在一个不可篡改的审计日志Ledger中。这包括了用户的原始输入、AI的推理过程、生成的行动请求、治理层的检查结果、最终的执行结果成功或失败及原因。这提供了完整的可追溯性。用户最终授权层对于某些高风险或高敏感度的操作项目定义为“敏感操作”治理层不会自动放行而是会生成一个明确的授权请求呈现给用户。用户拥有最后一票否决权。只有用户明确点击“批准”动作才会执行。这种架构使得系统变得不透明的地方更透明该笨拙的地方反而显得可靠。它牺牲了“一气呵成”的炫酷感换来了每一步的可控、可审计与可信任。3. 系统架构深度解析与核心组件要真正理解和使用NovaLIS我们需要深入其架构。根据其文档整个系统是围绕一系列相互协作的微服务或模块构建的我们可以将其核心抽象为以下几个逻辑组件。3.1 核心运行时组件Orchestrator系统的指挥中心。它接收用户输入通过CLI、Web界面等协调整个工作流调用推理引擎、解析AI输出、识别其中的行动意图、将行动请求提交给治理引擎、最终调用执行器并收集审计信息。Reasoning Engine推理引擎。这就是ollamagemma4或其他你配置的模型所在之处。它负责处理自然语言进行规划、总结、草拟等纯智能任务。它的输出被严格限定为“自然语言回答”和“结构化行动请求”。Capability Registry能力注册表。这是一个动态数据库存储所有已声明和已启用的“能力”。每个能力都有唯一的ID、名称、描述、输入模式JSON Schema、输出模式以及关联的执行器。例如“send_email”能力会关联到“EmailClientExecutor”。Governance Engine治理引擎。这是策略执行的核心。它接收来自Orchestrator的行动请求并运行一系列策略检查静态策略基于能力元数据如“该能力是否需要用户确认”。动态策略基于运行时上下文如“当前时间是否在允许的办公时间内”、“请求删除的文件是否在受保护的目录中”。用户确认对于高敏感操作暂停流程向用户界面发送确认请求。Executor Pool执行器池。这是一组具体的、实现某个能力的代码模块。它们是无状态的只负责做一件事。例如FileReadExecutor: 读取文件内容。ShellCommandExecutor: 在安全沙箱中执行限定的Shell命令。HTTPRequestExecutor: 发送HTTP请求到预定义的API端点。 执行器只有在收到Governance Engine明确放行的指令后才会被调用。Audit Ledger审计账本。通常是一个不可变的日志存储如SQLite数据库或专门的日志文件记录所有事件的完整链条。每条记录至少包含时间戳、会话ID、用户ID、原始输入、AI推理输出、请求的能力、治理检查结果、执行结果、错误信息如果有。3.2 数据流与工作流程一个典型的“让Nova总结我上周的工作日志并邮件发给经理”的请求其内部数据流如下用户输入“总结我上周在~/work/logs/下的日志并起草一份邮件发给经理。”Orchestrator收到请求将其连同对话历史一起发送给Reasoning Engine。Reasoning Engine分析请求可能进行多步推理第一步识别出需要“读取文件”的能力来获取日志。第二步调用“文本总结”能力可能是模型自身功能生成摘要。第三步识别出需要“起草邮件”和“发送邮件”的能力。 它最终输出一个结构化的“计划”包含一系列有序的“行动请求”。Orchestrator解析这个计划取出第一个行动请求例如{action: read_file, params: {path: ~/work/logs/week45.md}}并将其提交给Governance Engine。Governance Engine查询Capability Registry确认read_file能力存在且已被启用。然后运行策略检查该路径是否在允许读取的列表内当前用户是否有权假设策略通过。Governance Engine向Orchestrator返回“放行”指令并指明使用哪个执行器FileReadExecutor。Orchestrator调用FileReadExecutor传入路径参数。执行器读取文件内容并返回。Orchestrator将读取到的日志内容作为上下文连同下一步“总结文本”的请求再次发送给Reasoning Engine。循环步骤3-7直到完成“起草邮件”。当进行到“发送邮件”这个行动请求时Governance Engine的策略可能规定此操作需要用户最终确认。Orchestrator暂停自动化流程通过用户界面弹出确认框“即将以您的身份发送主题为‘Week 45 Work Summary’的邮件至managercompany.com是否继续”用户点击“确认”。这个确认信号被记录后流程继续邮件被发送。整个过程中Audit Ledger记录了从步骤1开始的每一个事件形成了完整的溯源链条。注意这个流程揭示了NovaLIS与普通AI助手的本质区别。普通助手可能一步到位内部黑箱操作。NovaLIS则将这一步拆解成了多个可见、可中断、可审计的微步骤每个步骤都经过策略过滤。这虽然增加了延迟但换来了确定性的安全。4. 实操部署与核心配置详解理解了架构我们来动手搭建一个基础的NovaLIS环境。这里假设你是在一个Linux/macOS开发环境上操作并且对命令行和Python有一定了解。4.1 环境准备与依赖安装首先你需要确保核心依赖就位Python环境NovaLIS基于Python建议使用Python 3.10或以上版本。使用pyenv或conda管理版本是个好习惯。python --version # 确认版本Ollama这是运行本地模型的核心。前往Ollama官网下载并安装。安装后拉取一个合适的模型例如Gemma 2B或7B版本作为起步。ollama pull gemma:7b # 拉取gemma 7b模型根据你的硬件选择 ollama run gemma:7b # 测试模型是否运行正常获取NovaLIS代码克隆项目仓库。git clone NovaLIS仓库地址 # 地址请替换为实际地址例如 GitHub 上的地址 cd NovaLIS安装Python依赖项目根目录下应有requirements.txt或pyproject.toml。pip install -r requirements.txt # 或如果是使用 poetry poetry install4.2 初始化配置与核心文件解读NovaLIS的配置是其灵魂主要围绕config/目录下的文件展开。核心配置文件通常是config/default.yaml或config/local.yaml。你需要重点关注以下部分# config/local.yaml 示例 nova: reasoning: engine: ollama # 指定推理引擎 model: gemma:7b # 指定使用的模型 ollama_base_url: http://localhost:11434 # Ollama服务地址 governance: # 策略文件路径 policy_files: - config/policies/builtin.yaml - config/policies/custom.yaml # 是否启用敏感操作的用户确认 require_confirmation_for: [send_email, execute_shell, write_file] capabilities: # 能力定义文件路径 definition_dir: config/capabilities/ # 初始启用的能力列表 enabled: - read_file - list_directory - http_get # - send_email # 默认不启用高风险能力 audit: ledger_type: sqlite # 审计日志存储类型 ledger_path: data/audit.db # SQLite数据库路径这个配置文件定义了系统的行为基线用什么模型、加载哪些策略、默认开放哪些能力、审计日志存到哪里。能力定义文件在config/capabilities/目录下每个能力一个YAML文件。例如read_file.yaml# config/capabilities/read_file.yaml id: read_file name: Read File description: Read the contents of a file from the local filesystem. executor: file_read # 对应执行器的名称 parameters: path: type: string description: Absolute or relative path to the file. required: true returns: content: type: string description: The content of the file. governance: risk_level: low # 风险等级影响策略检查强度 categories: [filesystem] # 可以在这里定义一些内联的简单策略如允许的路径前缀 allowed_path_prefixes: - ${HOME}/Documents/nova_workspace/ - ./data/这个文件告诉系统存在一个叫read_file的能力它需要一个path参数会返回文件content由file_read执行器实现并且它只能读取特定目录下的文件。策略定义文件在config/policies/目录下。策略可以用一种声明式的语言或YAML来编写。例如custom.yaml# config/policies/custom.yaml policies: - id: working_hours_only description: Only allow certain actions during working hours (9 AM to 6 PM). target: action.request # 针对所有行动请求 condition: | action.capability_id in [send_email, execute_shell] and not (datetime.now().hour 9 and datetime.now().hour 18) effect: DENY # 如果条件满足则拒绝 - id: protect_git_dir description: Never allow deletion of .git directories. target: action.request condition: | action.capability_id delete_file and .git in action.parameters.get(path, ) effect: DENY策略引擎会在每个行动请求上评估所有这些策略任何一条策略返回DENY该请求就会被阻断。4.3 启动系统与初步测试配置完成后可以启动NovaLIS服务。通常项目会提供一个主入口脚本比如main.py或通过cli.py。# 方式一以服务模式启动可能会启动一个后台进程和/或一个Web界面 python -m nova serve # 方式二使用CLI交互模式 python -m nova.cli启动后首先进行一个简单的安全测试测试允许的操作在CLI里输入“请列出当前目录下的文件。”。Nova应该会调用list_directory能力经过策略检查通常是允许的然后返回文件列表。测试被禁止的操作输入“删除.git目录。”。根据我们上面的策略这个请求应该会被治理引擎直接拒绝并返回一个清晰的错误信息如“请求被策略‘protect_git_dir’拒绝”。测试需要确认的操作如果你配置并启用了send_email输入“给testexample.com发一封测试邮件。”。流程应该会暂停并在CLI或Web界面上提示你确认。只有在你输入“y”或点击确认后邮件才会发送。这个过程直观地展示了治理在起作用。在部署的初期强烈建议将所有能力的风险等级设为high并全部启用require_confirmation在实战中观察AI会提出哪些请求再逐步细化策略。5. 高级主题构建自定义能力与复杂策略当基础系统运行起来后你会需要扩展它让它真正为你所用。这意味着添加自定义能力和编写更精细的策略。5.1 开发一个自定义执行器假设你想让Nova能查询你内部的项目管理工具比如一个自建的API。你需要创建一个新的能力。创建能力定义文件config/capabilities/query_project_tasks.yamlid: query_project_tasks name: Query Project Tasks description: Fetch tasks from the internal project management API for a given project ID. executor: project_api_query parameters: project_id: type: string description: The unique identifier of the project. required: true status: type: string enum: [open, in_progress, done] description: Filter tasks by status. required: false default: open returns: tasks: type: array items: type: object properties: id: {type: string} title: {type: string} assignee: {type: string} due_date: {type: string, format: date} governance: risk_level: medium categories: [internal_api] # 可以限制只能查询用户自己有权限的项目 allowed_project_ids: [proj_123, proj_456] # 或在策略中动态判断实现执行器代码在项目的执行器模块目录如nova/executors/下创建project_api_query.py。# nova/executors/project_api_query.py import httpx from typing import Dict, Any from .base import BaseExecutor class ProjectApiQueryExecutor(BaseExecutor): 执行器查询内部项目管理API async def execute(self, parameters: Dict[str, Any]) - Dict[str, Any]: project_id parameters[project_id] status parameters.get(status, open) # 1. 从配置或安全存储获取API密钥 api_key self._get_config(internal_api_key) api_base_url self._get_config(internal_api_base_url) # 2. 构造并发送请求 async with httpx.AsyncClient() as client: headers {Authorization: fBearer {api_key}} # 假设API端点格式 url f{api_base_url}/projects/{project_id}/tasks params {status: status} resp await client.get(url, headersheaders, paramsparams) resp.raise_for_status() data resp.json() # 3. 格式化返回数据符合能力定义中声明的schema tasks [] for item in data.get(items, []): tasks.append({ id: item[id], title: item[title], assignee: item.get(assignee, Unassigned), due_date: item.get(due_date) }) return {tasks: tasks} def _get_config(self, key: str): # 从执行器上下文或全局配置中获取敏感信息 # 切勿将密钥硬编码在代码中 return self.context.config.get(key)注册执行器需要在某个地方如executors/__init__.py将这个执行器类注册到系统中使其能被executor: project_api_query这个字符串找到。更新配置在config/local.yaml的capabilities.enabled列表中添加- query_project_tasks。现在你就可以对Nova说“帮我查一下项目proj_123中所有进行中的任务。”它会使用这个新能力经过治理检查后调用你的内部API并返回结果。5.2 编写基于上下文的动态策略静态策略不够用我们需要能根据会话上下文做决定的策略。例如只允许AI修改当前“会话工作区”内的文件。这通常需要策略引擎支持访问“会话上下文”Session Context。假设NovaLIS的治理引擎提供了这样的变量。# config/policies/context_aware.yaml policies: - id: restrict_file_write_to_workspace description: Only allow writing files within the sessions designated workspace. target: action.request condition: | action.capability_id write_file and # 假设会话上下文中有一个workspace_root变量 not action.parameters.path.startswith(session.context.get(workspace_root, /tmp)) effect: DENY message: 文件写入操作被限制在会话工作区‘{{ session.context.workspace_root }}’内。然后在启动会话或用户通过命令指定工作区时Orchestrator需要将这个workspace_root写入会话上下文。这样策略就能动态生效了。实操心得自定义能力开发中最容易出错的地方是参数验证和错误处理。务必在执行器内部对输入参数做严格的二次验证即使能力定义中有Schema。因为AI生成的参数可能格式正确但语义荒谬如路径为/etc/passwd。同时执行器的错误信息应足够清晰以便被审计日志记录并能友好地反馈给用户或AI进行下一步决策。6. 安全模型、审计与故障排查NovaLIS的核心价值在于其安全与审计特性。理解其安全模型和如何利用审计信息至关重要。6.1 深度解析安全模型NovaLIS的安全是一个纵深防御体系最小权限原则每个能力被精确地定义其作用范围。read_file能力可能只被允许读取特定目录。系统默认不启用任何高风险能力如execute_shell,send_email。默认拒绝治理引擎的默认策略是“除非明确允许否则拒绝”。任何未被能力注册表定义、或虽定义但未启用、或未通过策略检查的行动都会被拒绝。显式用户授权对于高风险操作流程在最终执行前强制中断等待用户的显式确认。这是防止AI“自作主张”的最后一道也是最重要的人工防线。不可篡改的审计所有事件从用户输入到最终执行结果都被顺序记录在审计账本中。这个账本最好是只追加append-only的并且可以通过哈希链等方式防止事后篡改。这为事后追溯和责任界定提供了铁证。会话隔离每个用户会话应该有独立的环境和上下文防止会话间意外干扰或信息泄露。6.2 审计日志的分析与应用审计日志data/audit.db如果使用SQLite是一个宝库。你可以直接查询或编写简单脚本进行分析。-- 查看过去24小时内所有被拒绝的行动 SELECT timestamp, session_id, user_input, capability_id, governance_decision, denial_reason FROM audit_events WHERE governance_decision DENIED AND timestamp datetime(now, -1 day) ORDER BY timestamp DESC; -- 查看某个用户的所有敏感操作如发送邮件 SELECT timestamp, action_parameters, executor_result FROM audit_events WHERE capability_id send_email AND user_id alicecompany.com;这些数据可以用于安全监控及时发现异常模式如短时间内大量文件读取请求。使用情况分析了解哪些能力最常用优化系统配置。故障诊断当AI行为不符合预期时通过日志还原完整决策链看是AI推理错误、策略误判还是执行器故障。合规报告生成操作记录报告满足审计要求。6.3 常见问题与排查指南在实际运行中你可能会遇到以下典型问题问题现象可能原因排查步骤AI对用户请求毫无反应或回答“我无法执行此操作”。1. 请求中未识别出任何已定义的能力。2. 相关能力未在配置中启用。1. 检查AI的原始输出审计日志看它是否生成了行动请求。2. 核对config/local.yaml中capabilities.enabled列表。行动被拒绝提示“策略拒绝”。触发了某条治理策略。1. 查看审计日志中该事件的denial_reason或关联的策略ID。2. 检查对应的策略文件如custom.yaml理解策略条件。3. 确认运行时上下文如时间、路径参数是否确实满足了拒绝条件。执行器报错如“Connection refused”。执行器依赖的外部服务如Ollama、内部API未运行或不可达。1. 检查审计日志中的executor_error详细信息。2. 手动测试执行器所需的外部连接如curl http://localhost:11434/api/generate。3. 检查执行器配置中的URL、密钥是否正确。用户确认弹窗未出现高风险操作直接执行或失败。governance.require_confirmation_for配置未包含该能力或配置未生效。1. 确认该能力的risk_level是否为high或在require_confirmation_for列表中。2. 检查配置文件加载顺序确保自定义配置覆盖了默认配置。3. 重启NovaLIS服务使配置生效。系统性能缓慢响应延迟高。1. 本地模型如Gemma 7B推理速度慢。2. 策略检查过于复杂。3. 网络延迟如调用远程API。1. 考虑使用更小的模型如Gemma 2B或量化版本。2. 优化策略条件避免复杂的实时计算或远程调用。3. 对执行器的外部调用设置超时和重试机制。一个关键的排查习惯永远从审计日志开始。它是整个系统运行的“黑匣子”记录了每一个决策点。当行为异常时首先查询相关时间段的日志按照session_id追踪完整的工作流你能快速定位问题是出在推理、治理还是执行阶段。7. 项目现状、许可与未来展望NovaLIS目前处于早期活跃开发阶段early software。根据其文档团队正专注于提升运行时可靠性、路由质量、内存治理、操作员工作流、连接器支持以及公共文档。这意味着它是一个功能可行、理念先进但可能尚不成熟、存在变动的项目。对于生产环境使用需要做好自己深入调试和贡献代码的准备。其采用的Business Source License 1.1是一个需要特别注意的“源码可用”许可证。它允许你查看、修改源代码并用于个人、内部或测试目的。但是如果你计划将其集成到一个面向第三方提供的商业产品或服务中即“生产用途”则需要购买商业许可。这保护了项目的商业可持续性。在决定基于NovaLIS进行深度开发或商业集成前务必仔细阅读LICENSE文件并考虑与项目维护者联系。从我个人的实践来看NovaLIS代表了一种非常重要的AI应用范式转变从追求“全自动”到追求“受控的增强”。它可能不会让你感觉像有一个无所不能的贾维斯但它会给你一个可靠、透明、不会捅娄子的智能副驾。在金融、法律、医疗、 DevOps 等对准确性和安全性要求极高的领域这种“慢就是快可控胜于全能”的思路或许是AI真正融入核心工作流的唯一可行路径。它的架构设计尤其是清晰的职责分离和可插拔的治理层非常值得任何正在构建严肃AI应用的工程师学习和借鉴。你可以从一个小范围、低风险的任务开始比如仅允许它读特定日志目录和总结文本逐步建立信任再谨慎地扩展其能力边界。