从 0 到 1 拆解一个「LLM 电脑管家」项目：Python + FastAPI + 本地 Agent + 系统工具调用

前言

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

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

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

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

本文将从项目结构、核心模块、Agent 设计、安全机制、前后端交互和可扩展方向几个角度进行分析。

C:\Users\86182\Desktop\电脑管家llm版

一、项目整体定位

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

它的核心能力包括：

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

项目同时提供两个入口：

text 复制代码

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

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

二、项目目录结构分析

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

1. 桌面端入口

text 复制代码

main.py

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

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

核心类是：

python 复制代码

class ManagerApp(tk.Tk)

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

2. Web 后端

text 复制代码

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

其中：

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

服务默认运行在：

text 复制代码

127.0.0.1:8765

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

3. Web 前端

text 复制代码

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

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

页面包含：

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

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

text 复制代码

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

4. Agent 与模型接入

text 复制代码

agent.py
backend/agent/runtime.py

agent.py 中包含三类助手：

python 复制代码

LocalAssistant
OpenAICompatibleAssistant
AnthropicMessagesAssistant

其中：

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

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

5. 系统工具层

text 复制代码

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. 持久化层

text 复制代码

config_store.py
database.py
app_paths.py

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

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

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

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

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

text 复制代码

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

对应代码主要集中在：

text 复制代码

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

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

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

agent.py 定义了：

python 复制代码

class LocalAssistant

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

例如用户输入：

text 复制代码

帮我清理 C 盘垃圾

LocalAssistant.plan() 会识别到：

清理
垃圾
缓存
temp
cleanup

然后生成两个步骤：

python 复制代码

scan_temp_files
clean_temp_files

如果用户说：

text 复制代码

查看 CPU 和内存状态

则会插入：

python 复制代码

get_system_status

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

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

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

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

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

1. OpenAI-compatible 接口

agent.py 定义了：

python 复制代码

class OpenAICompatibleAssistant

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

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

python 复制代码

{
    "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 还定义了：

python 复制代码

class AnthropicMessagesAssistant

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

python 复制代码

{
    "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：

json 复制代码

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

可用工具包括：

text 复制代码

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

并且明确规定：

text 复制代码

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

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

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

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

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

backend/tools/registry.py 定义了：

python 复制代码

class ToolRegistry

它提供三个核心能力：

python 复制代码

register()
get()
run()

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

python 复制代码

name
title
risk
description
handler

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

text 复制代码

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

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

python 复制代码

risk="write"

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

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

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

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

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

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

backend/core/security.py 定义了：

python 复制代码

class PermissionManager

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

当前风险等级包括：

python 复制代码

read
write
danger

对应策略是：

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

也就是说：

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

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

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

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

backend/agent/runtime.py 定义了：

python 复制代码

class AgentRuntime

它负责执行工具调用。

执行流程是：

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

返回结果统一封装成：

python 复制代码

ToolRunResult

字段包括：

python 复制代码

tool
status
data
message

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

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

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

1. 获取系统状态

python 复制代码

get_system_status()

python 复制代码

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

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

2. 扫描临时文件

python 复制代码

scan_temp_files(max_items=500)

它扫描系统临时目录：

python 复制代码

tempfile.gettempdir()

并统计：

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

3. 清理临时文件

python 复制代码

clean_temp_files(limit=300)

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

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

4. 查看进程

python 复制代码

list_processes(limit=20)

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

返回字段包括：

python 复制代码

pid
name
cpu_percent
memory_mb

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

5. 查看启动项

python 复制代码

list_startup_apps()

它扫描 Windows 常见启动目录：

text 复制代码

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

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

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

config_store.py 负责读写配置。

默认配置包括：

python 复制代码

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 数据库。

数据库会创建三张表：

sql 复制代码

operation_logs
chat_messages
scan_results

1. operation_logs

保存操作日志，例如：

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

2. chat_messages

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

3. scan_results

保存临时文件扫描结果。

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

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

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

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

main.py 是桌面端入口。

ManagerApp 初始化时会创建：

python 复制代码

ConfigStore
AppDatabase
LocalAssistant

桌面端布局包括：

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

用户发送消息时，调用：

python 复制代码

handle_user_message()

执行逻辑是：

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

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

python 复制代码

messagebox.askyesno()

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

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

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

主要接口包括：

text 复制代码

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 接收用户消息后调用：

python 复制代码

app_services.chat(message)

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

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

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

它负责：

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

1. 工具名兼容

backend/services.py 定义了：

python 复制代码

LEGACY_TOOL_MAP

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

python 复制代码

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 前端由三部分组成：

text 复制代码

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() 方法：

javascript 复制代码

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. 安全确认

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

html 复制代码

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

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

javascript 复制代码

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

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

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

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

text 复制代码

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

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

1. 前端接收用户输入

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

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

javascript 复制代码

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

2. FastAPI 接收请求

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

python 复制代码

@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() 方法中，系统会读取配置：

python 复制代码

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

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

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

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

text 复制代码

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

4. Agent 生成工具计划

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

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

json 复制代码

{
  "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 中提供了兼容映射：

python 复制代码

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 版本更像是：

text 复制代码

聊天规划 + 工具按钮执行

还没有完全实现：

text 复制代码

聊天后自动执行全部 steps

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

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

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

text 复制代码

┌─────────────────────────────┐
│         用户交互层           │
│  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 应用。

十九、核心调用链伪代码

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

python 复制代码

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

工具执行则可以抽象为：

python 复制代码

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)

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

二十、测试覆盖分析

项目包含多个测试文件：

text 复制代码

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

对应：

text 复制代码

LocalAssistant
OpenAICompatibleAssistant
AnthropicMessagesAssistant

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

2. Tool

对应：

text 复制代码

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

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

3. Runtime

对应：

text 复制代码

AgentRuntime

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

4. Permission

对应：

text 复制代码

PermissionManager

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

5. Memory

对应：

text 复制代码

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 版本依赖也很少：

text 复制代码

fastapi
uvicorn
psutil

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

2. 本地优先

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

text 复制代码

config.json
manager.db

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

3. 模型可选

用户可以选择：

text 复制代码

local
deepseek
openai-compatible
anthropic

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

4. 风险意识明确

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

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

这其实是一个优点。

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

5. 测试关注关键路径

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

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

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

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

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

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

后续可以实现：

text 复制代码

用户输入
  → 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 执行循环

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

下一版可以实现：

text 复制代码

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

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

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

目前工具参数比较简单。

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

python 复制代码

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

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

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

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

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

text 复制代码

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

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

4. 增加任务状态系统

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

后续可以增加任务表：

text 复制代码

task_id
task_type
status
progress
result
created_at
updated_at

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

5. 增加更细的权限等级

现在权限等级是：

text 复制代码

read
write
danger

后续可以细化成：

text 复制代码

read
write_temp
write_user_file
process_control
registry_modify
network_access
admin_required
danger

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

6. 增加"撤销"能力

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

例如：

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

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

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

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

可以考虑增加以下工具。

1. 磁盘分析插件

text 复制代码

disk.analyze_large_files
disk.find_duplicates
disk.scan_downloads

2. 进程优化插件

text 复制代码

process.analyze_high_usage
process.kill_with_approval
process.explain_process

3. 网络诊断插件

text 复制代码

network.ping
network.dns_check
network.speed_test

4. 安全检查插件

text 复制代码

security.check_startup_risk
security.scan_suspicious_paths
security.check_hosts_file

5. 自动维护插件

text 复制代码

maintenance.weekly_cleanup
maintenance.generate_report
maintenance.performance_baseline

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

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

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

项目名称

text 复制代码

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

项目描述

text 复制代码

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

技术栈

text 复制代码

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

技术亮点

text 复制代码

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

可量化成果

可以这样写：

text 复制代码

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

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

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

标题建议

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

text 复制代码

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

text 复制代码

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

text 复制代码

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

text 复制代码

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

text 复制代码

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

我更推荐：

text 复制代码

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

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

摘要建议

text 复制代码

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

标签建议

text 复制代码

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

如果只能选几个，建议：

text 复制代码

Python
FastAPI
大模型
Agent
源码分析

三十、总结

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

text 复制代码

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

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

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

text 复制代码

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

而 LLM 电脑管家的目标是：

text 复制代码

用户描述问题 → 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`	深色科技风样式

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