用 Gemma 3 4B 构建本地 AI 系统可靠性智能体

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

I built a local AI system reliability agent that monitors a Windows computer, stores system metrics locally, analyzes trends, and uses Gemma 3 4B to provide reliability and maintenance recommendations.

The idea came from a simple problem:
A friend of mine often noticed that their computer would become slow or unresponsive, but figuring out why usually meant opening Task Manager and trying to interpret a long list of numbers.

The problem wasn't a lack of data.

It was understanding the data.

The Purpose

I wanted to build something that could answer a simple question for my friend:

"What's happening with my computer, and what should I check?"

Instead of another monitoring dashboard, I decided to build a local AI System Reliability Agent.

The Solution

The agent turns raw system activity into understandable reliability insights:

🖥️ Friend's Computer
↓
📊 Monitor
CPU • RAM • Disk • Network • Cache • Events
↓
🗄️ Store
Local SQLite History
↓
🔧 Analyze
Reliability & Trend Tools
↓
🤖 Understand
Gemma 3 4B + Ollama
↓
💡 Recommend
Clear Reliability & Maintenance Suggestions

So instead of only seeing:

RAM: 82%

my friend can get context about what the system has been experiencing and what they may want to investigate.

The agent doesn't automatically change the computer. It provides the analysis and recommendations while the user stays in control.

Monitor → Store → Analyze → Recommend.

That's the idea behind the project: make system reliability information easier for a real person to understand, while keeping their data and AI processing local.

Demo

DEMO LINK: AI System Reliability Agent

Dashboard

The dashboard shows the current system state and keeps the monitoring interface compact enough to remain useful while the machine is being used.

AI Reliability Analysis

The AI produces a structured assessment containing:

Overall status
Summary
Reliability findings
Evidence from collected metrics
Recommended ma

Code

The complete project is available on GitHub:

ChallengeOne — Local System Metrics + AI Reliability Assistant #HacktoberFest2026

This version keeps the working v3 monitoring dashboard and adds a fully local AI reliability layer.

Architecture

Tkinter Dashboard
      |
      +---- local SQLite (system_metrics.db)
      |
      +---- FastAPI (127.0.0.1:8000)
                 |
                 +---- reliability tools -> SQLite
                 |
                 +---- Ollama -> Gemma 3 4B (local)

MCP server (stdio) exposes the same read-only reliability tools.

No system metrics are sent to a cloud AI service by this application. Ollama is configured for localhost.

Features retained from v3

• CPU and per-logical-core utilization
• RAM utilization
• Disk utilization
• Network throughput
• Windows cache/temp/Prefetch/browser cache details
• Windows Critical/Error/Warning event counts
• SQLite persistence
• 5-minute automatic collection
• Manual Refresh metrics
• 5:3 responsive Tkinter dashboard
• Compact current-day time graph
• Detailed CPU core table
• Detailed cache path table

New AI features

• Local Ollama + Gemma 3 4B integration (tool-compatible: SQLite/tool calls are executed by Python and supplied as JSON context)
• FastAPI local service…

The repository contains the monitoring application, SQLite data layer, FastAPI service, reliability tools, MCP server and local Ollama/Gemma integration.

How I Built It

The project is built with Python, Tkinter, SQLite, FastAPI, MCP, Ollama, and Gemma 3 4B.

The architecture is intentionally simple:

🖥️ Windows System
↓
📊 Python Monitoring
↓
🗄️ SQLite
↓
🔧 Reliability Tools
↓
⚡ FastAPI + MCP
↓
🦙 Ollama
↓
🤖 Gemma 3 4B
↓
💡 Reliability Recommendations

The application collects CPU, RAM, disk, network, cache, and Windows event data and stores it locally in SQLite. Historical data gives the agent context instead of relying on a single snapshot.

The reliability layer provides read-only tools for retrieving metrics, history, cache information, events, and trends.

Gemma 3 4B runs locally through Ollama and receives the relevant reliability data as structured context. The AI then turns that information into a human-readable reliability assessment and maintenance suggestions.

I also exposed the reliability capabilities through a local MCP server, keeping the tools separate from the model.

Why Does Open Innovation Matter?

For this project, open innovation made it possible to build the reliability agent around the user's machine instead of around a cloud AI service.

CPU, memory, disk, cache and system-event data can reveal information about how a computer is being used.

With local inference, the application doesn't need to send that monitoring history to a third-party AI API just to generate recommendations.

🧩 Control over the AI stack

The AI isn't locked into a single hosted API.

I can change the model, prompts, reliability tools, or inference layer without redesigning the monitoring system.

The project separates data collection → tools → AI reasoning, which makes the system easier to experiment with and extend.

🛠️ Open tools made the architecture possible

Using Python, SQLite, FastAPI, MCP, Ollama and Gemma gave me control over each layer.

For example, when Gemma 3 4B through Ollama didn't support the native tool-calling approach I initially tried, I didn't need to redesign the entire application around a closed API.

I changed the architecture so Python executes the read-only reliability tools and passes their structured results to Gemma:

SQLite
↓
Python Reliability Tools
↓
Structured Context
↓
Gemma 3 4B
↓
Recommendation

That flexibility is what open innovation meant for this project:

I could adapt the system to the model instead of adapting the entire project to a closed AI service.

And because inference runs locally, there is no per-request cloud AI API cost. The trade-off is that the user's computer provides the hardware and electricity needed to run the model.