前言

传统电脑管家一般是“按钮驱动”的：用户点击“清理垃圾”“查看进程”“管理启动项”等功能，程序执行对应模块。

而这个项目尝试把传统电脑管家升级为一个 LLM 驱动的系统级智能助手：

用户用自然语言描述问题，LLM 或本地规则助手理解意图，再调用系统工具完成状态查看、垃圾扫描、进程分析、启动项检查和智能诊断。

我对当前项目中的代码做了一次完整阅读，发现它虽然是 MVP 版本，但已经具备了一个“系统 Agent”的基本骨架：前端控制台、桌面端、后端 API、工具注册中心、权限审批、SQLite 记忆、配置持久化以及 LLM 接入能力。

本文将从项目结构、核心模块、Agent 设计、安全机制、前后端交互和可扩展方向几个角度进行分析。
C:\Users\86182\Desktop\电脑管家llm版
在这里插入图片描述

一、项目整体定位

项目名称是 LLM 电脑管家 MVP。

它的核心能力包括：

  • 自然语言助手
  • 系统状态查看
  • 临时文件扫描与清理
  • 进程查看
  • 启动项查看
  • 配置持久化
  • SQLite 操作日志
  • Web 控制台
  • Tkinter 桌面端

项目同时提供两个入口：

main.py              Tkinter 桌面版入口
backend/server.py    FastAPI + Web 控制台入口

也就是说，这不是单纯的命令行工具，而是一个同时支持 桌面 GUI 和 Web 控制台 的本地系统助手。

二、项目目录结构分析

当前项目主要文件可以分为几类。

1. 桌面端入口

main.py

main.py 使用 Tkinter 构建桌面应用，负责：

  • 创建窗口
  • 显示 CPU、内存、磁盘状态
  • 提供聊天输入框
  • 提供快捷按钮
  • 展示操作日志
  • 保存用户设置
  • 调用系统工具

核心类是：

class ManagerApp(tk.Tk)

它是整个桌面端的主窗口类。

2. Web 后端

backend/server.py
backend/api_app.py
backend/services.py

其中：

  • backend/server.py 是 FastAPI 服务启动入口
  • backend/api_app.py 定义 HTTP API
  • backend/services.py 是服务组装层，连接配置、数据库、Agent、工具注册中心和运行时

服务默认运行在：

127.0.0.1:8765

这说明它是一个本地控制台，不是面向公网部署的服务。

3. Web 前端

frontend/index.html
frontend/app.js
frontend/styles.css

前端是原生 HTML + CSS + JavaScript，没有引入 React、Vue 等框架。

页面包含：

  • 左侧导航栏
  • 顶部操作按钮
  • CPU / 内存 / 磁盘指标卡片
  • 自然语言助手聊天框
  • 快捷工具调用区
  • 模型设置区
  • 操作日志区

frontend/app.js 负责调用后端 API，比如：

/api/status
/api/chat
/api/diagnose
/api/tools/run
/api/logs
/api/settings

4. Agent 与模型接入

agent.py
backend/agent/runtime.py

agent.py 中包含三类助手：

LocalAssistant
OpenAICompatibleAssistant
AnthropicMessagesAssistant

其中：

  • LocalAssistant 是本地规则助手
  • OpenAICompatibleAssistant 适配 OpenAI-compatible Chat Completions API
  • AnthropicMessagesAssistant 适配 Anthropic Messages 格式 API

这使得项目既可以在没有 API Key 的情况下本地运行，也可以接入 DeepSeek、OpenAI-compatible 服务或 Anthropic Messages 风格接口。

5. 系统工具层

system_tools.py
backend/tools/registry.py
backend/core/security.py

system_tools.py 是真正和操作系统交互的地方，包含：

  • get_system_status()
  • scan_temp_files()
  • clean_temp_files()
  • list_processes()
  • list_startup_apps()
  • format_bytes()

backend/tools/registry.py 则把这些能力包装成可注册、可查询、可执行的工具。

backend/core/security.py 提供权限判断逻辑。

6. 持久化层

config_store.py
database.py
app_paths.py

这部分负责本地数据保存。

  • config_store.py 保存用户配置到 config.json
  • database.py 使用 SQLite 保存聊天记录、操作日志和扫描结果
  • app_paths.py 处理普通 Python 运行和 PyInstaller 打包后的路径差异

三、核心架构：LLM + 工具调用 + 权限控制

这个项目最值得关注的地方，是它已经形成了一个比较清晰的 Agent 架构。

可以抽象成下面这条链路：

用户输入
   ↓
LLM / 本地规则助手生成计划
   ↓
工具名称规范化
   ↓
权限判断
   ↓
工具注册中心执行函数
   ↓
结果写入数据库
   ↓
前端或桌面端展示

对应代码主要集中在：

agent.py
backend/services.py
backend/agent/runtime.py
backend/tools/registry.py
backend/core/security.py

四、本地规则助手：没有 LLM 也能跑

项目并不是完全依赖远程大模型。

agent.py 定义了：

class LocalAssistant

它通过关键词匹配生成工具调用计划。

例如用户输入：

帮我清理 C 盘垃圾

LocalAssistant.plan() 会识别到：

  • 清理
  • 垃圾
  • 缓存
  • temp
  • cleanup

然后生成两个步骤：

scan_temp_files
clean_temp_files

如果用户说：

查看 CPU 和内存状态

则会插入：

get_system_status

这个设计有一个很实际的好处：

即使没有配置 API Key，项目仍然可以作为一个本地规则型电脑管家运行。

这对于 MVP 非常重要，因为它降低了运行门槛。

五、远程 LLM 接入：OpenAI-compatible 与 Anthropic Messages

项目也支持远程模型调用。

1. OpenAI-compatible 接口

agent.py 定义了：

class OpenAICompatibleAssistant

它通过 /v1/chat/completions 风格接口请求模型。

在 plan() 方法中，会构造如下 payload：

{
    "model": self.model_name,
    "temperature": 0.2,
    "messages": [
        {"role": "system", "content": planner_system_prompt()},
        {"role": "user", "content": user_input},
    ],
}

系统提示词要求模型只输出 JSON。

这点非常关键，因为系统工具调用不能依赖自然语言模糊解析，必须得到结构化结果。

2. Anthropic Messages 风格接口

agent.py 还定义了：

class AnthropicMessagesAssistant

它使用的是类似 Anthropic Messages 的请求格式：

{
    "model": self.model_name,
    "max_tokens": 2048,
    "temperature": 0.2,
    "system": planner_system_prompt(),
    "messages": [{"role": "user", "content": user_input}],
}

这说明项目在设计上不是绑定某一个模型供应商，而是预留了多模型适配能力。

六、Prompt 设计：让模型成为“规划器”

项目中的 LLM 不是直接操作系统，而是作为 规划器 使用。

planner_system_prompt() 要求模型输出这样的 JSON：

{
  "reply": "给用户的中文说明",
  "steps": [
    {
      "tool": "工具名",
      "args": {},
      "title": "步骤名"
    }
  ],
  "requires_confirmation": false
}

可用工具包括：

system.get_status
cleanup.scan_temp
cleanup.clean_temp
process.list
startup.list

并且明确规定：

cleanup.clean_temp 是写操作，必须让 requires_confirmation 为 true

这个 Prompt 设计体现了一个重要原则：

LLM 只负责理解意图和生成计划，不直接执行危险动作。

这也是系统 Agent 项目必须遵守的安全边界。

七、工具注册中心：把系统能力标准化

backend/tools/registry.py 定义了：

class ToolRegistry

它提供三个核心能力：

register()
get()
run()

每个工具由 ToolDefinition 描述，包含：

name
title
risk
description
handler

例如项目注册了这些典型工具：

system.get_status
cleanup.scan_temp
cleanup.clean_temp
process.list
startup.list

其中 cleanup.clean_temp 的风险等级是：

risk="write"

这意味着它不是普通只读工具，执行前需要权限审批。

这种注册中心设计的好处是：

  1. 工具元数据统一管理
  2. 前端可以通过 API 获取工具列表
  3. Agent 可以只输出工具名
  4. 权限系统可以根据工具风险做判断
  5. 后续扩展新工具比较方便

八、权限系统：读操作放行，写操作审批，高危操作阻断

系统 Agent 最大的风险是“误操作电脑”。

这个项目在 MVP 阶段已经设计了一个简单但清晰的权限模型。

backend/core/security.py 定义了：

class PermissionManager

它根据工具风险等级判断是否允许执行。

当前风险等级包括：

read
write
danger

对应策略是：

风险等级 策略
read 直接允许
write 用户确认后允许
danger 默认阻断

也就是说：

  • read 工具直接通过
  • write 工具如果没有 approved，则返回 approval_required
  • 其他高风险工具默认不执行

这对电脑管家类应用非常重要。

例如“查看 CPU”是安全操作，可以直接运行；但“清理临时文件”涉及删除文件，必须先确认。

九、Agent Runtime：工具真正执行的地方

backend/agent/runtime.py 定义了：

class AgentRuntime

它负责执行工具调用。

执行流程是：

  1. 根据工具名从注册中心获取工具
  2. 调用权限管理器判断是否允许执行
  3. 如果不允许，返回 approval_required 或 blocked
  4. 如果允许，执行工具 handler
  5. 捕获异常并返回统一结果结构

返回结果统一封装成：

ToolRunResult

字段包括：

tool
status
data
message

这种统一返回结构适合前端展示，也方便后续接入更复杂的 Agent 执行链。

十、系统工具层：当前实现了哪些能力？

system_tools.py 是项目的系统能力层。

1. 获取系统状态

get_system_status()

返回：

{
    "cpu_percent": ...,
    "memory": ...,
    "disk": ...
}

CPU 和内存优先使用 psutil，如果没有安装，则退化为基础实现。

2. 扫描临时文件

scan_temp_files(max_items=500)

它扫描系统临时目录：

tempfile.gettempdir()

并统计：

  • 临时文件路径
  • 文件大小
  • 总大小
  • 样本数量

3. 清理临时文件

clean_temp_files(limit=300)

它先调用扫描函数，再删除扫描结果中的普通文件。

值得注意的是，它只处理系统临时目录中的文件，并且最多处理一定数量，这降低了误删风险。

4. 查看进程

list_processes(limit=20)

它使用 psutil.process_iter() 获取进程信息，并按内存占用排序。

返回字段包括：

pid
name
cpu_percent
memory_mb

如果没有安装 psutil，则退化为只返回当前 Python 进程。

5. 查看启动项

list_startup_apps()

它扫描 Windows 常见启动目录：

%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup
%PROGRAMDATA%\Microsoft\Windows\Start Menu\Programs\Startup

这说明当前项目主要面向 Windows 桌面环境。

十一、配置持久化：config.json

config_store.py 负责读写配置。

默认配置包括：

DEFAULT_CONFIG = {
    "theme": "light",
    "llm_provider": "local",
    "api_base": "",
    "api_key": "",
    "model_name": "local-rule-agent",
    "auto_refresh_seconds": 5,
    "confirm_before_clean": True,
    "last_user_input": "",
    "last_quick_action": "",
    "window_geometry": "1080x720",
}

这说明项目会持久化：

  • 主题
  • 模型供应商
  • API 地址
  • API Key
  • 模型名称
  • 清理前确认选项
  • 最近输入
  • 窗口大小

ConfigStore.load() 会将已有配置和默认配置合并，这样以后新增配置项时，旧配置文件也能兼容。

十二、SQLite 数据库：manager.db

database.py 定义了本地 SQLite 数据库。

数据库会创建三张表：

operation_logs
chat_messages
scan_results

1. operation_logs

保存操作日志，例如：

  • 刷新状态
  • 扫描垃圾
  • 清理垃圾
  • 智能诊断
  • 保存设置

2. chat_messages

保存用户与助手的聊天记录。

3. scan_results

保存临时文件扫描结果。

这种设计让项目具备了基本“记忆”能力。

虽然它还不是复杂的长期记忆系统，但已经可以支撑：

  • 历史操作回看
  • 扫描结果复用
  • 用户对话记录保存
  • 后续统计分析

十三、桌面端实现：Tkinter 快速构建 MVP

main.py 是桌面端入口。

ManagerApp 初始化时会创建：

ConfigStore
AppDatabase
LocalAssistant

桌面端布局包括：

  • 顶部标题
  • CPU / 内存 / 磁盘状态卡片
  • 智能助手聊天区
  • 输入框
  • 快捷按钮
  • 设置区域
  • 操作日志列表

用户发送消息时，调用：

handle_user_message()

执行逻辑是：

  1. 获取用户输入
  2. 写入聊天记录
  3. 调用本地助手生成计划
  4. 展示助手回复
  5. 如果不需要确认，则执行计划

清理垃圾时，桌面端会先弹出确认框：

messagebox.askyesno()

这和后端权限系统形成了相同的安全思想：写操作必须确认。

十四、Web API 设计：FastAPI 本地控制台

backend/api_app.py 定义了后端 API。

主要接口包括：

GET  /api/status       获取系统状态
GET  /api/tools        获取工具列表
POST /api/chat         发送自然语言消息
POST /api/diagnose     智能诊断
POST /api/tools/run    执行指定工具
GET  /api/logs         获取操作日志
GET  /api/settings     获取设置
POST /api/settings     保存设置

这些接口基本覆盖了 Web 控制台所需的全部能力。

其中 /api/chat 接收用户消息后调用：

app_services.chat(message)

/api/tools/run 会根据前端传入的 approved 字段决定是否允许执行写操作。

十五、服务组装层：backend/services.py

backend/services.py 是整个 Web 版本的核心胶水层。

它负责：

  • 创建配置存储
  • 初始化数据库
  • 创建工具注册中心
  • 创建权限管理器
  • 创建 Agent Runtime
  • 选择本地助手或远程模型
  • 处理聊天
  • 处理诊断
  • 记录工具执行日志

1. 工具名兼容

backend/services.py 定义了：

LEGACY_TOOL_MAP

它把旧工具名映射为 Web 架构中的新工具名：

get_system_status  -> system.get_status
scan_temp_files    -> cleanup.scan_temp
clean_temp_files   -> cleanup.clean_temp
list_processes     -> process.list
list_startup_apps  -> startup.list

这说明项目经历过从桌面端到 Web 架构的演进，并通过兼容层保持旧逻辑可用。

2. 智能诊断

collect_diagnostic_snapshot() 会一次性收集：

  • 当前系统状态
  • 启动项
  • 进程列表
  • 临时文件扫描结果

然后 build_diagnostic_prompt() 会把这些数据拼成中文诊断材料。

这就是一个典型的 RAG / Agent 诊断前置步骤：

先收集真实系统数据，再交给模型生成建议，避免模型凭空编造。

3. 模型选择

_select_assistant() 根据配置选择助手：

  • 如果 provider 是 local，则使用本地规则助手
  • 如果是 anthropic 或 API 地址包含 /api/coding，则使用 Anthropic Messages
  • 否则使用 OpenAI-compatible

这使得模型接入更加灵活。

十六、前端控制台：深色科技风 Web UI

Web 前端由三部分组成：

frontend/index.html
frontend/styles.css
frontend/app.js

1. 页面结构

frontend/index.html 定义了一个典型控制台布局：

  • 左侧 sidebar
  • 主工作区 shell
  • metrics 指标卡片
  • assistant-panel 对话面板
  • side-stack 工具与设置面板
  • logs-panel 操作日志

2. JavaScript API 调用

frontend/app.js 定义了统一的 api() 方法：

async function api(path, options = {}) {
  const response = await fetch(path, {
    headers: { "Content-Type": "application/json" },
    ...options,
  });
  return response.json();
}

发送聊天消息时调用 /api/chat。

执行工具时调用 /api/tools/run。

智能诊断调用 /api/diagnose。

3. 安全确认

前端执行清理工具时，会根据按钮上的属性判断是否需要确认：

<button data-tool="cleanup.clean_temp" data-approval="true">清理垃圾</button>

如果需要审批，会弹出浏览器确认框：

confirm("该操作会修改系统临时目录，是否继续？")

这和后端权限系统形成双保险。

十七、一次完整请求的执行流程拆解

为了更直观地理解这个项目，我们可以模拟一次用户请求：

帮我清理电脑垃圾，顺便看看内存占用情况

从代码设计来看，这个请求会经过以下流程。

1. 前端接收用户输入

在 Web 控制台中，用户点击发送按钮后，会执行 frontend/app.js 中的 sendMessage()。

它会把用户输入发送到后端接口：

const result = await api("/api/chat", {
  method: "POST",
  body: JSON.stringify({ message }),
});

2. FastAPI 接收请求

后端在 backend/api_app.py 中定义了 /api/chat：

@app.post("/api/chat")
def chat(payload: dict[str, Any]):
    message = str(payload.get("message", "")).strip()
    if not message:
        return {"reply": "请输入要处理的问题。", "steps": [], "requires_confirmation": False}
    return app_services.chat(message)

API 层本身不处理业务，只做请求接收和参数校验，然后把任务交给 AppServices。

3. 服务层选择助手

在 backend/services.py 的 chat() 方法中，系统会读取配置：

config = self.config_store.load()
planner = self._select_assistant(config)

如果用户配置了远程模型，就使用远程 LLM。

如果没有配置，或者配置不完整，就使用本地规则助手。

这使得系统具备两种运行模式：

无 API Key：本地规则助手
有 API Key：远程 LLM 规划器

4. Agent 生成工具计划

如果使用本地规则助手，LocalAssistant.plan() 会根据关键词生成 steps。

对于“清理垃圾”和“内存占用”，它可能生成类似计划：

{
  "reply": "我会按“查看系统状态、扫描临时文件、清理临时文件”处理你的请求。",
  "steps": [
    {
      "tool": "get_system_status",
      "args": {},
      "title": "查看系统状态"
    },
    {
      "tool": "scan_temp_files",
      "args": {},
      "title": "扫描临时文件"
    },
    {
      "tool": "clean_temp_files",
      "args": {},
      "title": "清理临时文件"
    }
  ],
  "requires_confirmation": true
}

如果使用远程模型，则模型也必须输出类似结构化 JSON。

5. 工具名规范化

由于桌面端早期工具名和 Web 架构中的工具名不完全一致，项目在 backend/services.py 中提供了兼容映射：

LEGACY_TOOL_MAP = {
    "get_system_status": "system.get_status",
    "scan_temp_files": "cleanup.scan_temp",
    "clean_temp_files": "cleanup.clean_temp",
    "list_processes": "process.list",
    "list_startup_apps": "startup.list",
}

这样旧格式的工具名会被转换成新工具注册中心中的标准名称。

6. 前端展示计划

后端返回计划后，前端把 reply 展示到聊天框。

如果需要执行具体工具，用户可以点击快捷按钮。

目前项目的 Web 版本更像是：

聊天规划 + 工具按钮执行

还没有完全实现：

聊天后自动执行全部 steps

这一点可以作为后续增强方向。

十八、可以放到博客里的架构图

如果在 CSDN 中想让文章更清晰，可以加入下面这张文本架构图。

┌─────────────────────────────┐
│         用户交互层           │
│  Tkinter 桌面端 / Web 控制台 │
└──────────────┬──────────────┘
               │
               ▼
┌─────────────────────────────┐
│          API 层              │
│       FastAPI Routes         │
│ /api/chat /api/status /tools │
└──────────────┬──────────────┘
               │
               ▼
┌─────────────────────────────┐
│         服务组装层           │
│       AppServices            │
│ 配置 / 数据库 / Agent / 工具 │
└──────────────┬──────────────┘
               │
               ▼
┌─────────────────────────────┐
│        Agent 规划层          │
│ LocalAssistant / Remote LLM  │
│ 输出 reply + steps + confirm │
└──────────────┬──────────────┘
               │
               ▼
┌─────────────────────────────┐
│        工具执行运行时        │
│        AgentRuntime          │
│ 工具查找 / 权限判断 / 执行   │
└──────────────┬──────────────┘
               │
               ▼
┌─────────────────────────────┐
│        系统工具层            │
│ 状态 / 清理 / 进程 / 启动项 │
└──────────────┬──────────────┘
               │
               ▼
┌─────────────────────────────┐
│        本地持久化            │
│ config.json + manager.db     │
└─────────────────────────────┘

这张图能帮助读者快速理解项目不是简单脚本，而是分层设计的 Agent 应用。

十九、核心调用链伪代码

为了让读者更容易理解，也可以把整体逻辑抽象成伪代码：

def handle_user_message(message):
    database.add_chat_message("user", message)
    config = config_store.load()
    assistant = select_assistant(config)
    plan = assistant.plan(message)
    plan = normalize_plan_tools(plan)
    database.add_chat_message("assistant", plan["reply"])
    return plan

工具执行则可以抽象为：

def run_tool(tool_name, args, approved=False):
    tool = registry.get(tool_name)
    decision = permissions.evaluate(tool.name, tool.risk, args, approved)

    if not decision.allowed:
        return approval_required_or_blocked()

    data = registry.run(tool.name, args)
    return ToolRunResult(tool=tool.name, status="ok", data=data)

这两段伪代码可以作为文章中的“核心思想总结”。

二十、测试覆盖分析

项目包含多个测试文件：

tests/test_agent.py
tests/test_web_architecture.py
tests/test_api_assistant.py
tests/test_diagnostics.py
tests/test_config_store.py
tests/test_database.py
tests/test_app_paths.py
tests/test_frontend_settings.py
tests/test_service_llm_selection.py

从测试内容看，项目重点验证了以下能力。

1. 本地助手规划

测试验证：

  • 清理请求会生成扫描和清理步骤
  • 清理请求需要确认
  • 状态请求是只读操作

2. 工具注册与权限审批

测试验证：

  • 工具注册中心能保存元数据
  • 未知工具会报错
  • 写操作没有审批会被阻止
  • 写操作审批后可以执行
  • 旧工具名可以映射到新工具名

3. 远程模型适配

测试验证：

  • OpenAI-compatible 接口 URL 拼接
  • Anthropic Messages 接口 URL 拼接
  • JSON 计划解析
  • 临时 SSL 错误重试

4. 智能诊断

测试验证：

  • 诊断 Prompt 包含 CPU、内存、磁盘、启动项、进程、垃圾扫描数据
  • 诊断服务会调用选定助手
  • 诊断结果会返回 snapshot

这说明项目虽然是 MVP，但测试覆盖的是关键架构点，而不是只测 UI 表层逻辑。

二十一、为什么这个项目适合作为 LLM Agent 入门项目？

很多人学习 Agent 时，一开始会直接接触复杂框架，例如 LangChain、AutoGen、CrewAI 等。

但这个项目反而更适合入门，因为它没有一上来引入过多抽象，而是把 Agent 最核心的几个概念直接写出来了。

1. Planner

对应：

LocalAssistant
OpenAICompatibleAssistant
AnthropicMessagesAssistant

它们负责理解用户意图并生成执行计划。

2. Tool

对应：

system.get_status
cleanup.scan_temp
cleanup.clean_temp
process.list
startup.list

每个工具本质上都是一个普通 Python 函数，只是被注册到了统一的工具中心。

3. Runtime

对应：

AgentRuntime

它负责真正执行工具，并统一处理异常和返回结果。

4. Permission

对应：

PermissionManager

它决定工具能不能执行，是否需要用户确认。

5. Memory

对应：

config.json
manager.db

虽然还不是复杂的语义记忆，但已经具备配置记忆、聊天记忆和操作日志记忆。

所以这个项目的学习价值在于：

它用非常朴素的 Python 代码，把 Agent 的基本组成部分都展示出来了。

对于刚学习 LLM 应用开发的人来说，这比直接阅读大型框架源码更容易理解。

二十二、与传统电脑管家的区别

可以在博客中加入一个对比表，增强传播性。

对比项 传统电脑管家 LLM 电脑管家
交互方式 点击按钮 自然语言对话
功能组织 一个个独立模块 Agent 统一调度工具
执行逻辑 固定规则 LLM / 规则助手生成计划
用户体验 用户自己判断该点什么 用户描述问题，助手给建议
扩展方式 新增页面和按钮 注册新工具
安全机制 功能内部判断 工具风险分级 + 用户审批
记忆能力 通常较弱 可结合日志和历史对话
智能诊断 依赖固定规则 可结合模型生成分析报告

这个表能很好地说明项目的创新点。

二十三、这个项目的技术亮点

1. LLM 不是“万能执行器”，而是“规划器”

项目没有让模型直接操作系统，而是让模型输出结构化 JSON，再由本地 Runtime 执行。

这是一种更安全、可控的 Agent 设计方式。

2. 工具调用有统一注册中心

所有系统能力都被抽象成工具，并带有：

  • 名称
  • 标题
  • 风险等级
  • 描述
  • handler

这为后续插件化打下了基础。

3. 权限系统前置

读操作、写操作、高危操作分级处理，这是电脑管家类应用非常重要的设计。

尤其是清理文件、结束进程、修改注册表、修改启动项等能力，一旦接入 Agent，就必须有权限边界。

4. 本地规则助手兜底

即使远程 LLM 调用失败，项目也会自动回退到本地规则助手。

这让项目可用性更高。

5. Web 与桌面双入口

Tkinter 适合快速桌面打包，FastAPI + Web 控制台适合继续扩展。

两套入口共享底层配置、数据库、系统工具和 Agent 逻辑，整体复用度比较高。

二十四、从工程角度看，这个项目有哪些好习惯？

1. 依赖少

Tkinter 版本基本只依赖 Python 标准库。

Web 版本依赖也很少：

fastapi
uvicorn
psutil

这降低了部署和打包难度。

2. 本地优先

配置文件和数据库都保存在本地：

config.json
manager.db

这符合电脑管家类应用的特点：不应该默认把系统状态上传到云端。

3. 模型可选

用户可以选择：

local
deepseek
openai-compatible
anthropic

这说明项目没有强绑定某一家模型厂商。

4. 风险意识明确

项目没有在 MVP 中贸然实现：

  • 强制结束进程
  • 修改注册表
  • 删除任意目录
  • 杀毒扫描
  • 系统级优化脚本

这其实是一个优点。

系统工具类项目应该先把安全边界做好，再逐步扩展能力。

5. 测试关注关键路径

测试不是简单测函数返回值，而是覆盖了：

  • 工具计划生成
  • 权限审批
  • 工具执行
  • 模型接口适配
  • 诊断 Prompt 构建
  • 配置和数据库

这说明项目已经开始向工程化方向发展。

二十五、当前项目的不足与可优化方向

1. 工具执行链还没有完全自动化

当前 /api/chat 主要返回计划，并不会自动逐步执行所有计划。

后续可以实现：

用户输入
  → LLM 生成 steps
  → Runtime 顺序执行 read 工具
  → 遇到 write 工具请求确认
  → 汇总执行结果
  → 再让 LLM 生成最终建议

这样会更接近真正的 Agent Loop。

2. 清理能力还比较保守

目前只清理系统临时目录中的普通文件。

后续可以扩展：

  • 浏览器缓存分析
  • Windows 更新缓存分析
  • 日志文件扫描
  • 大文件识别
  • 下载目录重复文件检测

但这些都需要更严格的白名单和确认机制。

3. 启动项管理还只是查看

当前 list_startup_apps() 只扫描常见启动目录。

后续可以增加：

  • 注册表 Run 项读取
  • 任务计划程序读取
  • 禁用启动项
  • 恢复启动项

但修改启动项属于高风险能力，应该放到 danger 或至少 write 等级。

4. 缺少真正的长期记忆

现在 SQLite 保存了聊天记录和操作日志，但 Agent 还没有主动利用历史记录进行个性化判断。

后续可以加入：

  • 设备性能基线
  • 常见高占用进程历史
  • 用户常用软件
  • 每周清理统计
  • 异常启动项变化记录

5. API Key 明文存储问题

当前配置会把 api_key 保存到 config.json。

这是 MVP 常见做法，但正式版本建议使用：

  • Windows Credential Manager
  • 系统密钥环
  • 本地加密存储
  • 环境变量
  • 用户级安全配置文件

二十六、如果我要继续开发，会怎么设计下一版？

如果把这个 MVP 继续往下做，我会优先做以下几个方向。

1. 实现真正的 Agent 执行循环

当前聊天接口返回的是计划。

下一版可以实现：

用户输入
  → 生成计划
  → 自动执行只读工具
  → 遇到写操作暂停
  → 前端展示“需要确认”
  → 用户确认后继续执行
  → 汇总所有工具结果
  → 再交给模型生成最终报告

这样体验会更像真正的智能助手。

2. 给工具增加输入参数校验

目前工具参数比较简单。

后续可以为每个工具定义 schema，例如：

ToolDefinition(
    name="process.list",
    args_schema={
        "limit": {"type": "integer", "minimum": 1, "maximum": 100}
    }
)

这样可以避免模型生成异常参数。

3. 增加工具执行结果摘要

工具返回的数据可能很大，例如进程列表、扫描结果。

后续可以在 Runtime 层增加摘要能力：

原始结果 → 结构化摘要 → 交给 LLM 生成解释

这样可以降低 token 消耗，也能减少模型被大量原始数据干扰。

4. 增加任务状态系统

一些操作可能耗时较长，例如磁盘扫描。

后续可以增加任务表：

task_id
task_type
status
progress
result
created_at
updated_at

前端通过轮询或 WebSocket 查看进度。

5. 增加更细的权限等级

现在权限等级是：

read
write
danger

后续可以细化成：

read
write_temp
write_user_file
process_control
registry_modify
network_access
admin_required
danger

这样能更精准地控制风险。

6. 增加“撤销”能力

凡是执行写操作，都应该尽量支持撤销。

例如：

  • 删除文件前移动到回收站
  • 禁用启动项前记录原始路径
  • 修改配置前备份
  • 结束进程前提示不可恢复

电脑管家类工具尤其需要这种设计。

二十七、适合继续扩展的插件方向

这个项目已经有工具注册中心，因此非常适合继续做插件化。

可以考虑增加以下工具。

1. 磁盘分析插件

disk.analyze_large_files
disk.find_duplicates
disk.scan_downloads

2. 进程优化插件

process.analyze_high_usage
process.kill_with_approval
process.explain_process

3. 网络诊断插件

network.ping
network.dns_check
network.speed_test

4. 安全检查插件

security.check_startup_risk
security.scan_suspicious_paths
security.check_hosts_file

5. 自动维护插件

maintenance.weekly_cleanup
maintenance.generate_report
maintenance.performance_baseline

如果这些工具都遵守统一的 ToolDefinition 和权限等级，就可以比较自然地接入当前架构。

二十八、这个项目可以怎么包装成作品集？

如果想把这个项目作为简历或作品集展示，可以强调下面几点。

项目名称

LLM PC Manager：基于大模型工具调用的本地电脑管家

项目描述

设计并实现一个本地运行的 LLM 电脑管家 MVP，支持自然语言助手、系统状态查看、垃圾扫描清理、进程查看、启动项查看、智能诊断、Web 控制台和桌面端入口。

技术栈

Python, FastAPI, Tkinter, SQLite, JavaScript, HTML, CSS, psutil, LLM API

技术亮点

1. 设计本地规则助手与远程 LLM 双模式规划器
2. 实现工具注册中心，将系统能力抽象为可调用工具
3. 实现 read/write/danger 风险分级和审批机制
4. 使用 SQLite 保存聊天记录、扫描结果和操作日志
5. 使用 FastAPI 提供本地 Web 控制台 API
6. 支持 OpenAI-compatible 与 Anthropic Messages 风格接口
7. 提供 Tkinter 桌面端和 Web 控制台双入口

可量化成果

可以这样写：

实现 5 类系统工具、7 个 Web API、3 张 SQLite 表、2 种前端入口和多模型适配能力。

这比单纯说“做了一个电脑管家”更能体现工程价值。

二十九、CSDN 标题、摘要与标签建议

标题建议

可以选择下面这些标题之一。

从源码拆解一个 LLM 电脑管家：Python + FastAPI 实现系统级 Agent

用 Python 写一个 LLM 电脑管家：自然语言控制系统工具的 MVP 架构分析

LLM Agent 落地实践：从电脑管家项目看工具调用、权限控制与本地记忆

传统电脑管家如何升级为 LLM Agent？一个 Python MVP 项目的源码分析

手把手拆解 LLM PC Manager：本地规则助手、工具注册中心与 FastAPI 控制台

我更推荐：

LLM Agent 落地实践：从电脑管家项目看工具调用、权限控制与本地记忆

这个标题技术感更强，也更适合 CSDN 搜索。

摘要建议

本文基于一个 Python 实现的 LLM 电脑管家 MVP 项目，系统分析其源码结构和工程设计。项目包含 Tkinter 桌面端、FastAPI Web 控制台、本地规则助手、OpenAI-compatible / Anthropic Messages 模型适配、工具注册中心、权限审批机制、SQLite 操作日志和配置持久化。文章重点拆解其 Agent 架构，包括 Planner、Tool、Runtime、Permission 和 Memory 五个核心模块，并讨论它如何从传统按钮式电脑管家演进为自然语言驱动的系统级智能助手。

标签建议

Python
FastAPI
人工智能
大模型
Agent
SQLite
电脑管家
系统工具
LLM
源码分析

如果只能选几个，建议：

Python
FastAPI
大模型
Agent
源码分析

三十、总结

这个项目虽然是一个 MVP，但已经具备了 LLM 电脑管家的核心雏形：

自然语言输入
  + LLM / 本地规则规划
  + 工具注册中心
  + 权限审批
  + 系统工具调用
  + SQLite 记忆
  + Web / 桌面双入口

它最有价值的地方不只是“能清理垃圾”或“能查看系统状态”，而是已经搭好了一个系统级 Agent 的基础框架。

传统电脑管家是功能集合：

用户点击按钮 → 程序执行固定功能

而 LLM 电脑管家的目标是：

用户描述问题 → Agent 理解意图 → 调用工具 → 汇总诊断 → 给出建议

这正是未来个人电脑助手的发展方向。

从这个项目可以看到，LLM 应用真正有价值的地方，不是让模型“聊天”，而是让模型成为一个能够理解意图、规划步骤、调用工具并遵守安全边界的智能调度器。

电脑管家是一个很适合 Agent 落地的场景，因为它天然包含状态感知、工具调用、风险审批和持续记忆。

这个 MVP 项目虽然功能还不复杂，但已经具备了系统级 Agent 的关键雏形：规划器、工具注册中心、权限系统、运行时和本地记忆。后续如果继续扩展插件系统、长期记忆、自动诊断和任务执行链，它就有机会从一个实验项目成长为真正可用的本地智能运维助手。

附：项目核心文件速览

文件 作用
main.py Tkinter 桌面端入口
backend/server.py FastAPI 服务启动入口
backend/api_app.py Web API 定义
backend/services.py 服务组装层，连接配置、数据库、Agent、工具和运行时
agent.py 本地规则助手和远程 LLM 适配
system_tools.py 系统状态、垃圾扫描、进程、启动项等底层工具
backend/tools/registry.py 工具注册中心
backend/core/security.py 权限审批逻辑
backend/agent/runtime.py 工具执行运行时
database.py SQLite 数据库封装
config_store.py JSON 配置持久化
frontend/index.html Web 控制台页面结构
frontend/app.js 前端 API 调用逻辑
frontend/styles.css 深色科技风样式

本次分析只基于当前项目源码和文档，没有修改项目代码。

# python # fastapi # 火山引擎
Logo
openEuler 社区

openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目，面向数字基础设施四大核心场景（服务器、云计算、边缘计算、嵌入式），全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构

更多推荐

cover

java 7 Java 7被小米彻底抛弃？澎湃OS 4重写内核，性能飙得你尖叫

avatar openEuler 社区
cover

第二十五章WSaiOS 感知系统总体架构与工程集成实现

avatar openEuler 社区

1979年7月26日：当UNIX源码被刻成黑胶唱片——极客们用“工业噪响音乐”破解了版权封锁

### 《1979年7月26日：当UNIX源码被刻成黑胶唱片》摘要1979年7月26日，面对AT&T对UNIX操作系统源码的版权封锁，澳洲新南威尔士大学的极客们巧妙利用法律漏洞，将C语言内核源码通过Modem调制为模拟音频，压制成“前卫摇滚黑胶唱片”公开发行。电台DJ误将其当成工业噪响音乐在黄金时段广播，摇滚乐迷沉浸于电子噪音的同时，计算机系学生则通过录音机抓包解调，成功获取了内核代码。这场奇葩事

avatar openEuler 社区