Introduction: The Third Stage of Operations

You manage five, ten, or more VPS instances. They run websites, databases, container services, CI/CD pipelines… Every day, you SSH in to check statuses, dig through logs, and handle alerts. Occasionally, you get woken up at midnight — disk full again, CPU spiking, or some service went down.

This isn’t because you’re not working hard enough. It’s because the traditional operations model itself is flawed.

In operations management, there are three stages:

• Stage 1: Manual Operations. Rely on memory, experience, and all-nighters. Only act after problems occur — always one step behind.
• Stage 2: Tool Automation. Use scripts, cron jobs, and Nagios/Zabbix. Rules are explicit and can handle known scenarios, but you’re still helpless when something unexpected happens.
• Stage 3: AI Agent Autonomy. The system has perceive-think-decide-act capabilities, proactively finding, analyzing, and resolving issues — even while you sleep.

Over the past two years, the rapid advancement of Large Language Models (LLMs) has made Stage 3 a reality. This article will walk you through the underlying logic of this paradigm shift and provide a complete, deployable solution for your own VPS.

1. Why Traditional Operations Fall Short

1.1 Monitoring Blind Spots and Alert Fatigue

Traditional monitoring systems have a fundamental flaw: they can only detect pre-defined metrics.

Limitations of threshold-based alerts:
┌──────────────────────────────────────────┐
│  CPU > 90% → Alert                       │
│  Memory > 85% → Alert                    │
│  Disk > 95% → Alert                      │
│  Process missing → Alert                 │
└──────────────────────────────────────────┘

But real-world problems often fall outside these four indicators:
- API latency increasing while CPU is normal (database lock contention)
- Registration rate dropping while traffic is stable (payment gateway silently failing)
- Anomalous patterns in logs that don't trigger any threshold (potential security attack)
- Multi-metric anomalies (each looks fine individually, but together they signal an impending failure)

Even worse is alert fatigue. When you receive 50 alerts a day and 47 are false positives, operators gradually become desensitized — while the real crisis may be hiding in those three genuine alerts.

1.2 Knowledge Silos and Response Delays

Even when an alert fires, the subsequent workflow remains inefficient:

Alert fires → Operator checks → Recalls troubleshooting experience → 
Searches docs/history → Runs diagnostic commands → Analyzes results → 
Forms plan → Executes fix → Verifies recovery

This process averages 15-45 minutes, while business losses accumulate every minute.

The key problem: every operator’s troubleshooting experience lives in their brain. Change the person or the scenario, and you have to rebuild that knowledge from scratch. An AI Agent can固化 this knowledge into reusable assets.

1.3 Non-linear Complexity Scaling

One VPS’s problems can be handled manually, ten start to overwhelm, and a hundred become impossible. Operations complexity grows non-linearly with VPS count — precisely where AI Agents shine brightest.

2. The New AI Agent Operations Paradigm

2.1 Core Architecture: Sense-Think-Decide-Act Closed Loop

The core of an AI Agent operations system is a continuously running loop:

┌─────────────────────────────────────────────────────────────────┐
│                   AI Agent Operations Hub                        │
│                                                                 │
│   ┌─────────────┐    ┌─────────────┐    ┌─────────────┐        │
│   │   Sense     │ →  │   Reason    │ →  │   Decide    │        │
│   │  Collect    │    │  Pattern    │    │  Generate   │        │
│   │  Aggregate  │    │  Detection  │    │  Solutions  │        │
│   │  Fuse       │    │  Root Cause │    │  Risk Assess│        │
│   └─────────────┘    └─────────────┘    └──────┬──────┘        │
│                                         │                       │
│   ┌─────────────┐    ←── Feedback loop   │                       │
│   │   Act       │    │  Continuous       ▼                       │
│   │  Auto-fix   │    │  ┌─────────────┐   │                       │
│   │  Human appr.│    │  │  Knowledge  │   │                       │
│   │  Report gen │    │  │  Base       │   │                       │
│   └──────┬──────┘    │  │  Learn/     │   │                       │
│          │           │  │  Evolve     │   │                       │
│          └─────────────────────────────────┘                       │
└─────────────────────────────────────────────────────────────────┘
                              │
              ┌───────────────┼───────────────┐
              ▼               ▼               ▼
        ┌───────────┐   ┌───────────┐   ┌───────────┐
        │  VPS A    │   │  VPS B    │   │  VPS C    │
        │ Prometheus│   │ Loki      │   │  Exporter │
        │ NodeExp   │   │ Grafana   │   │  Agent    │
        └───────────┘   └───────────┘   └───────────┘

2.2 Five Key Capabilities

2.3 Relationship with Existing Tools

AI Agents don’t replace Prometheus, Grafana, Loki, etc. — they create synergy:

Existing Tools          AI Agent Role
──────────────          ─────────────────
Prometheus               Data source — provides time-series metrics
Grafana                  Data source — provides visualization context
Loki                     Data source — provides log semantics
Shell scripts            Execution units — tools the Agent can invoke
Nagios/Zabbix            Alert triggers — feed critical events into Agent
                         Decision hub — integrates all information

3. Implementation: Building from Scratch

3.1 System Components

A complete AI Agent operations system includes:

# docker-compose.agent.yml
services:
  # ── Data Collection Layer ──
  node-exporter:
    image: prom/node-exporter:latest
    # Collects system metrics from all VPS instances

  promtail:
    image: grafana/promtail:latest
    # Collects logs from all VPS and pushes to Loki

  # ── Data Storage Layer ──
  prometheus:
    image: prom/prometheus:latest
    # Stores time-series metrics

  loki:
    image: grafana/loki:latest
    # Stores logs

  grafana:
    image: grafana/grafana:latest
    # Visualization + alerting rules

  # ── AI Agent Core Layer ──
  agent-orchestrator:
    build: ./agent
    # Agent orchestrator — the system brain
    environment:
      - LLM_ENDPOINT=http://ollama:11434
      - KNOWLEDGE_BASE_PATH=/data/knowledge-base
      - DANGER_COMMANDS=rm -rf,shutdown,reboot
      - APPROVAL_REQUIRED=true

  ollama:
    image: ollama/ollama:latest
    # Local LLM inference engine
    volumes:
      - ./models:/models

  # ── Execution Layer ──
  agent-executor:
    build: ./executor
    # Lightweight Agent running on remote VPS
    # Receives instructions and executes safely

3.2 Orchestrator Core Code

# agent/orchestrator.py
import asyncio
import json
from datetime import datetime
from pathlib import Path
from typing import Optional

from prometheus_api_client import PrometheusConnect
from langchain_community.llms.ollama import Ollama
from langchain.prompts import PromptTemplate

class VPSAgentOrchestrator:
    def __init__(self, llm_model="qwen2.5:7b-instruct"):
        self.prom = PrometheusConnect(url="http://prometheus:9090")
        self.llm = Ollama(model=llm_model, base_url="http://ollama:11434")
        self.knowledge_base = Path("/data/knowledge-base")
        self.dangerous_commands = {"rm -rf", "shutdown", "reboot", "dd"}
        self.approval_required = True

    async def run_cycle(self):
        """Main loop: execute one full sense-think-decide-act cycle per iteration"""
        print(f"[{datetime.now()}] Running agent cycle...")

        # ① Sense: collect current status
        status = await self.perceive()

        # ② Reason: analyze for anomalies
        analysis = await self.reason(status)

        if not analysis["has_anomaly"]:
            print("  No anomalies detected.")
            return

        # ③ Decide: generate fix plan
        plan = await self.decide(analysis)

        # ④ Act: execute within safe boundaries
        await self.execute(plan)

    async def perceive(self) -> dict:
        """Collect data from multiple sources"""
        return {
            "metrics": self._fetch_metrics(),
            "logs": self._fetch_recent_logs(),
            "events": self._fetch_alert_events(),
            "timestamp": datetime.now().isoformat(),
        }

    async def reason(self, status: dict) -> dict:
        """LLM analyzes anomalies and identifies root cause"""
        prompt = PromptTemplate.from_template("""
You are a senior SRE engineer. Analyze the following VPS status data
and determine if there are anomalies, what the root cause might be,
and what action should be taken.

Status Data:
{status}

Respond in JSON format:
{{
  "has_anomaly": true/false,
  "severity": "critical/high/medium/low",
  "root_cause": "description of root cause",
  "evidence": ["list of supporting evidence"],
  "recommended_action": "description of recommended action",
  "action_command": "specific command to execute (or null if manual review needed)"
}}
""")

        chain = prompt | self.llm
        response = await chain.ainvoke({"status": json.dumps(status, indent=2)})
        return json.loads(response)

    async def decide(self, analysis: dict) -> dict:
        """Generate an executable fix plan"""
        risk_score = self._calculate_risk(analysis.get("action_command", ""))

        plan = {
            "analysis": analysis,
            "risk_score": risk_score,
            "requires_approval": risk_score >= 7 or self.approval_required,
            "executed_at": None,
        }

        if plan["requires_approval"]:
            await self._send_approval_request(plan)

        return plan

    def _calculate_risk(self, command: str) -> int:
        """Calculate operation risk level (0-10)"""
        if not command:
            return 0
        score = 0
        for dangerous in self.dangerous_commands:
            if dangerous in command:
                score += 5
        if "systemctl restart" in command:
            score += 2
        if "iptables" in command or "firewall" in command:
            score += 3
        return min(score, 10)

    async def execute(self, plan: dict):
        """Execute the fix plan"""
        if plan["requires_approval"]:
            print("  Action requires manual approval. Sent notification.")
            return

        command = plan["analysis"].get("action_command")
        if command:
            print(f"  Executing: {command}")
            result = await self._safe_execute(command)
            plan["executed_at"] = datetime.now().isoformat()
            plan["result"] = result
            await self._record_learning(plan)

    async def _record_learning(self, plan: dict):
        """Record this event to the knowledge base for future reference"""
        record = {
            "timestamp": plan["executed_at"],
            "analysis": plan["analysis"],
            "risk_score": plan["risk_score"],
            "outcome": plan.get("result", "pending"),
        }
        log_file = self.knowledge_base / "events" / f"{datetime.now().strftime('%Y%m%d')}.jsonl"
        log_file.parent.mkdir(parents=True, exist_ok=True)
        with open(log_file, "a") as f:
            f.write(json.dumps(record, ensure_ascii=False) + "\n")

3.3 Remote Execution Agent

# executor/agent.py
"""
Lightweight Agent running on remote VPS instances.
Receives instructions and executes them safely.
"""
import asyncio
import json
import subprocess
from pathlib import Path
from datetime import datetime

class SafeExecutor:
    DANGEROUS_PATTERNS = [
        "rm -rf /", "mkfs", "dd if=", "chmod 777",
        "> /dev/sda", "wget .* | sh", "curl .* | bash"
    ]

    def __init__(self, max_output_size=10240):
        self.max_output_size = max_output_size
        self.audit_log = Path("/var/log/agent-executor/audit.log")

    async def execute(self, command: str, timeout: int = 30) -> dict:
        """Safely execute a command"""
        # Safety check
        if self._is_dangerous(command):
            return {"error": "Command blocked by safety policy", "command": command}

        # Audit log
        self._audit_log(command)

        try:
            result = await asyncio.create_subprocess_shell(
                command,
                stdout=asyncio.subprocess.PIPE,
                stderr=asyncio.subprocess.PIPE,
                limit=self.max_output_size,
            )
            stdout, stderr = await asyncio.wait_for(result.communicate(), timeout=timeout)

            return {
                "command": command,
                "exit_code": result.returncode,
                "stdout": stdout.decode()[:self.max_output_size],
                "stderr": stderr.decode()[:self.max_output_size],
                "success": result.returncode == 0,
            }
        except asyncio.TimeoutError:
            result.kill()
            return {"error": "Command timed out", "command": command}

    def _is_dangerous(self, command: str) -> bool:
        for pattern in self.DANGEROUS_PATTERNS:
            if pattern in command:
                return True
        return False

    def _audit_log(self, command: str):
        entry = {
            "timestamp": datetime.now().isoformat(),
            "command": command,
            "action": "executing",
        }
        self.audit_log.parent.mkdir(parents=True, exist_ok=True)
        with open(self.audit_log, "a") as f:
            f.write(json.dumps(entry) + "\n")

4. Real-World Scenarios

4.1 Scenario 1: Automatic Disk Cleanup

Problem: A VPS disk usage hits 92%. Traditional approach requires manual SSH login and investigation.

AI Agent workflow:

1. Sense: Prometheus detects node_filesystem_avail_bytes < 2GB
2. Reason: LLM analyzes logs, finds /var/log grew 8GB in 6 hours
3. Decide: Generate plan — clean 7-day-old journalctl logs + compress old logs
4. Execute:
   - Command: journalctl --vacuum-time=7d && gzip /var/log/*.log.1
   - Risk assessment: 2/10 (low risk, auto-execute)
5. Verify: Disk usage drops to 71% after execution
6. Learn: Record event to knowledge base, reducing response time next occurrence

4.2 Scenario 2: API Service Slowing Down

Problem: Users report slow website loading, but CPU and memory metrics look normal.

1. Sense: Prometheus detects increased http_request_duration_seconds percentiles
2. Reason: LLM correlates —
   - Database connections spiked at the same time
   - Logs show大量 "lock wait timeout" errors
   - Conclusion: Slow SQL queries exhausting the connection pool
3. Decide:
   - Short-term: Restart database connection pool (low risk, auto-execute)
   - Long-term: Generate slow query analysis report (needs human review)
4. Execute:
   - systemctl restart mysql
   - Output top 10 slow queries to ops channel
5. Verify: Response time normalizes, P99 < 200ms

4.3 Scenario 3: SSL Certificate Expiry

Problem: Certificate expires in 5 days. Traditional approach relies on calendar reminders, which are easily missed.

1. Sense: Agent scans all VPS certificate expiry dates daily
2. Reason: Finds 3 certificates below the threshold
3. Decide: Auto-generates renewal tickets, pushes to Slack/DingTalk
4. Execute:
   - Low-risk operation (certbot renew) auto-executes
   - High-risk operation (manual DNS validation) notifies for human confirmation
5. Verify: Certificate validity extended 90 days after renewal

5. Quantified Results

5.1 Key Metrics Comparison

5.2 Qualitative Benefits

1. From firefighting to fire prevention: The system intervenes before problems escalate
2. Knowledge never lost: Every incident’s handling process is recorded as a searchable asset
3. Linear scaling: Adding VPS instances doesn’t linearly increase operations workload
4. 7×24不间断守护: No shift schedules needed, the system is always online
5. Continuous self-optimization: As events accumulate, the Agent’s judgment becomes increasingly accurate

6. Deployment Guide: Three Steps to Get Started

Step 1: Prepare Infrastructure

# Deploy the Agent hub on a dedicated VPS (recommended: 4C8G)
git clone https://github.com/selfvps/ai-vps-agent.git
cd ai-vps-agent

# Install dependencies
pip install -r requirements.txt

# Configure Ollama (local LLM)
docker compose up -d ollama prometheus loki grafana
ollama pull qwen2.5:7b-instruct

Step 2: Install Agent on Target VPS

# Run on each VPS you want to manage
curl -sSL https://raw.githubusercontent.com/selfvps/ai-vps-agent/main/install.sh | bash

# Configure connection to the Agent hub
cat > /etc/agent/config.yaml <<EOF
orchestrator:
  host: <your-agent-server-ip>
  port: 8080
  
safety:
  approval_required: true
  dangerous_commands:
    - "rm -rf /"
    - "shutdown"
    - "reboot"
EOF

Step 3: Start and Verify

# Start the Agent
systemctl enable --now vps-agent

# Monitor Agent status
journalctl -u vps-agent -f

# Simulate a problem to verify auto-response
# (e.g., create a large file to simulate disk full)
sudo dd if=/dev/zero of=/tmp/fill_disk bs=1M count=500
# Watch whether the Agent detects and cleans up automatically

7. Safety Boundaries and Considerations

The powerful capabilities of AI Agents also introduce new security responsibilities. These points are critical:

7.1 Essential Protections

7.2 Progressive Deployment Recommendation

Phase 1: Read-only mode (1-2 weeks)
  Agent only collects data and generates reports, no execution
  Goal: Build trust, verify accuracy

Phase 2: Low-risk auto-execution (2-4 weeks)
  Allow read-only and cleanup commands (e.g., log cleanup, cache flush)
  Goal: Accumulate experience, tune strategies

Phase 3: Medium-risk auto-execution (1-2 months)
  Allow service restarts, configuration changes, etc.
  Goal: Full automation

Phase 4: High-risk manual approval (ongoing)
  Deletions, network changes always require human confirmation
  Goal: Maintain last line of defense

Conclusion: The Future of Operations Is Here

AI Agents reshaping VPS operations is fundamentally about liberating productivity. They free operators from repetitive labor, enabling them to focus on higher-value work — architecture design, performance optimization, and business innovation.

This isn’t a distant vision. Today, a single 4GB VPS + open-source tools + a local LLM is enough to build a working AI Agent operations system.

From reactive response to proactive prevention — this is not just a technical upgrade, it’s an evolution of operations philosophy. Teams that embrace this change early are already enjoying the peace of mind that comes from 7×24-hour intelligent guardianship.

Your VPS deserves this kind of Agent.