ساخت کارمند هوش مصنوعی ۲۴ ساعته روی VPS؛ تعریف Role، Routine و Schedule برای اجرای خودکار و گزارش‌دهی واقعی

چرا Chatbot معمولی دیگر برای این سناریو کافی نیست؟

فرض کنید هر روز چند کار مشخص دارید: بررسی وضعیت سایت، خواندن لاگ‌ها، بررسی خطاهای سرویس، تهیه گزارش، بررسی داده‌های فروش یا آماده‌کردن خلاصه فعالیت‌های روزانه. یک Chatbot تا زمانی که شما پیامی برایش نفرستید، معمولاً کاری انجام نمی‌دهد.

اما در مدل AI Employee مسئله متفاوت است. شما یک نقش شغلی تعریف می‌کنید و برای آن مشخص می‌کنید چه چیزی را مالک باشد، چه ابزارهایی در اختیار داشته باشد، چه زمانی اجرا شود و خروجی چگونه گزارش شود.

AI Employee در سال ۲۰۲۶ چه تفاوتی با Agentهای قدیمی دارد؟

در جریان‌های جدید AI، مفهوم «کارمند دیجیتال» بیشتر از یک نام تبلیغاتی به یک معماری عملی تبدیل شده است. پروژه‌هایی مانند OpenCompany روی کارمندانی تمرکز دارند که در پس‌زمینه کار می‌کنند و نقش و وظیفه مشخص دارند. پروژه PlumoAI نیز مفهوم AI Employee خودمیزبان، Agent، Workflow و Schedule را کنار هم قرار می‌دهد.

در همین راستا، سرویس‌های جدید نیز روی اجرای زمان‌بندی‌شده Agentها، اجرای unattended و نگهداری وضعیت کاری تمرکز کرده‌اند. بنابراین زاویه کاربردی این مقاله فقط «نصب یک Chatbot روی VPS» نیست؛ بلکه ساخت یک چرخه کاری دائمی و قابل گزارش است.

معماری یک کارمند هوش مصنوعی ۲۴ ساعته

برای ساخت چنین سیستمی، بهتر است چهار لایه را از هم جدا کنیم. این تفکیک باعث می‌شود بعداً بتوانید همان VPS را برای چند کارمند مختلف نیز استفاده کنید.

چه کارهایی را می‌توان به AI Employee سپرد؟

محدودیتی وجود ندارد که این معماری فقط برای تولید محتوا باشد. هر کاری که ورودی مشخص، مراحل قابل تعریف و خروجی قابل اندازه‌گیری داشته باشد، کاندید مناسبی برای تبدیل‌شدن به Routine است.

پیش‌نیازهای ساخت AI Employee روی VPS

برای نمونه‌ای که در ادامه می‌سازیم، یک VPS لینوکسی با Ubuntu 22.04 یا Ubuntu 24.04 کافی است. اگر Agent قرار است چند ابزار، دیتابیس یا چند Worker را همزمان اجرا کند، بهتر است منابع را بالاتر انتخاب کنید.

نکته: اگر مدل زبانی از API استفاده کند، VPS الزاماً به GPU نیاز ندارد. در این حالت سرور وظیفه اجرای Scheduler، منطق Agent، ابزارها، فایل‌ها و گزارش‌ها را دارد و پردازش مدل در سرویس API انجام می‌شود.

مرحله اول: ساخت محیط اجرای AI Employee

ابتدا به VPS متصل شوید و Python و محیط مجازی را آماده کنید. استفاده از محیط مجازی باعث می‌شود کتابخانه‌های Agent با نرم‌افزارهای دیگر سرور تداخل پیدا نکنند.

sudo apt update
sudo apt install -y python3 python3-venv python3-pip
mkdir -p /opt/ai-employee/{reports,logs,data}
cd /opt/ai-employee
python3 -m venv .venv
source .venv/bin/activate
pip install --upgrade pip
pip install openai python-dotenv

کتابخانه رسمی OpenAI امکان ارسال درخواست به مدل از سمت Python را فراهم می‌کند و در معماری‌های Agent نیز می‌توان ابزارهای مختلف را به مدل متصل کرد. مستندات رسمی API نیز استفاده از SDK و Responses API را برای ساخت برنامه‌های مبتنی بر مدل توضیح می‌دهد.

مستندات رسمی OpenAI API و Quickstart

مرحله دوم: تعریف Role برای کارمند

مهم‌ترین تفاوت این سیستم با Chatbot همین‌جاست. به‌جای اینکه فقط بنویسیم «یک دستیار هوش مصنوعی باش»، باید نقش را دقیق تعریف کنیم.

در مثال ما یک AI Operations Employee می‌سازیم. مسئولیت آن بررسی وضعیت کاری سرویس‌ها، خلاصه‌سازی داده‌های دریافت‌شده و تولید گزارش است. این کارمند اجازه ندارد بدون تأیید انسان تغییر مخرب روی سرور ایجاد کند.

ROLE = """
You are an AI Operations Employee.

Your responsibilities:
1. Review the supplied operational data.
2. Identify abnormal conditions.
3. Separate facts from assumptions.
4. Produce a concise operational report.
5. Suggest safe next actions.

Rules:
- Never claim an action was completed unless the tool result confirms it.
- Never delete data.
- Never change production configuration automatically.
- Mark uncertain findings as requiring human review.
"""

مرحله سوم: Routine چیست و چرا از Prompt معمولی مهم‌تر است؟

Role می‌گوید کارمند چه کسی است؛ اما Routine می‌گوید دقیقاً چه کاری باید انجام دهد. یک Routine خوب باید ورودی، مراحل و خروجی مشخص داشته باشد.

مرحله چهارم: ساخت فایل تنظیمات کارمند

برای اینکه Role و Schedule داخل کد اصلی دفن نشوند، بهتر است تنظیمات را جدا کنیم. این روش بعداً ساخت چند کارمند مختلف را بسیار ساده‌تر می‌کند.

{
  "employee_name": "Ops Employee",
  "role": "AI Operations Employee",
  "schedule": "06:00,12:00,18:00,23:00",
  "routine": "daily_operations_report",
  "report_dir": "/opt/ai-employee/reports"
}

مزیت این ساختار این است که برای ساخت کارمند دوم لازم نیست کل برنامه را از صفر بنویسید. می‌توانید Role و Routine دیگری بسازید و همان موتور اجرا را دوباره استفاده کنید.

مرحله پنجم: نوشتن Worker اصلی

Worker وظیفه دارد داده را جمع کند، Prompt را بسازد، مدل را فراخوانی کند و گزارش را ذخیره کند. در یک معماری حرفه‌ای‌تر می‌توان ابزارها را نیز به صورت Function Tool یا MCP به Agent اضافه کرد.

import os
from datetime import datetime
from pathlib import Path
from dotenv import load_dotenv
from openai import OpenAI

load_dotenv()

client = OpenAI()
MODEL = os.getenv("AI_MODEL")
REPORT_DIR = Path("/opt/ai-employee/reports")
REPORT_DIR.mkdir(parents=True, exist_ok=True)

ROLE = """
You are an AI Operations Employee.

Review the operational data provided to you.
Return a structured report with:
- Executive summary
- Facts
- Abnormal findings
- Recommended safe actions
- Items requiring human approval

Do not invent measurements.
Do not claim actions were executed unless confirmed.
"""

def collect_data():
    return {
        "timestamp": datetime.now().isoformat(),
        "service_status": "healthy",
        "cpu": "34%",
        "ram": "48%",
        "disk": "41%",
        "notes": "No critical alerts detected."
    }

def run_employee():
    data = collect_data()

    prompt = f"""
{ROLE}

Operational data:
{data}
"""

    response = client.responses.create(
        model=MODEL,
        input=prompt
    )

    report = response.output_text
    filename = REPORT_DIR / f"report-{datetime.now():%Y-%m-%d-%H%M%S}.md"
    filename.write_text(report, encoding="utf-8")

    print(report)
    print(f"Report saved to: {filename}")

if __name__ == "__main__":
    run_employee()

در این نمونه، مدل فقط مسئول تحلیل و تولید گزارش است. جمع‌آوری داده توسط برنامه انجام می‌شود. این جداسازی بسیار مهم است؛ چون نباید به مدل اجازه بدهیم خودش درباره داده‌هایی که وجود ندارند فرض بسازد.

مرحله ششم: اتصال Schedule به کارمند

حالا Worker را دستی آزمایش کنید.

cd /opt/ai-employee
source .venv/bin/activate
export AI_MODEL="YOUR_MODEL"
export OPENAI_API_KEY="YOUR_API_KEY"
python employee.py

اگر گزارش ساخته شد، نوبت Scheduler است. برای کارهای زمان‌بندی‌شده سبک، Cron روی لینوکس انتخاب ساده‌ای است. برای معماری‌های پیچیده‌تر می‌توانید Scheduler را داخل سرویس یا Orchestrator قرار دهید.

crontab -e

برای اجرای چهار Routine در روز می‌توانید زمان‌بندی را به شکل زیر تعریف کنید:

0 6  * * * cd /opt/ai-employee && .venv/bin/python employee.py >> logs/cron.log 2>&1
0 12 * * * cd /opt/ai-employee && .venv/bin/python employee.py >> logs/cron.log 2>&1
0 18 * * * cd /opt/ai-employee && .venv/bin/python employee.py >> logs/cron.log 2>&1
0 23 * * * cd /opt/ai-employee && .venv/bin/python employee.py >> logs/cron.log 2>&1

در این مدل VPS همیشه روشن است، اما مدل فقط در زمان اجرای Routine فراخوانی می‌شود. بنابراین «۲۴ ساعته» بودن سیستم از پایداری زیرساخت و Scheduler می‌آید، نه از اینکه مدل ۲۴ ساعت بدون توقف در حال تولید Token باشد.

چطور کارمند واقعاً شغل داشته باشد، نه فقط چند Prompt؟

یک اشتباه رایج این است که چند Prompt پشت سر هم نوشته شود و اسم آن را «AI Employee» بگذاریم. برای نزدیک‌شدن به یک کارمند واقعی، باید چرخه کاری تعریف شود.

گزارش کار واقعی را چگونه ذخیره کنیم؟

اگر Agent فقط متن را چاپ کند، بعد از چند روز پیدا کردن سابقه کار دشوار می‌شود. هر اجرا باید یک شناسه، زمان اجرا، وضعیت و خروجی داشته باشد.

reports/
├── report-2026-10-03-060000.md
├── report-2026-10-03-120000.md
├── report-2026-10-03-180000.md
└── report-2026-10-03-230000.md

logs/
└── cron.log

در مرحله بعد می‌توان این ساختار را به SQLite یا PostgreSQL منتقل کرد و برای هر اجرا اطلاعاتی مانند زمان شروع، زمان پایان، هزینه API، وضعیت موفق یا ناموفق و خلاصه نتیجه را ذخیره کرد.

ساخت چند کارمند روی یک VPS

وقتی موتور اصلی آماده شد، دیگر لازم نیست برای هر شغل یک سیستم کاملاً جدا بسازید. می‌توانید Roleهای مختلف را در پوشه‌های مستقل قرار دهید.

/opt/ai-employees/
├── seo-employee/
│   ├── employee.py
│   ├── config.json
│   └── reports/
├── operations-employee/
│   ├── employee.py
│   ├── config.json
│   └── reports/
├── content-employee/
│   ├── employee.py
│   ├── config.json
│   └── reports/
└── sales-employee/
    ├── employee.py
    ├── config.json
    └── reports/

در چنین معماری‌ای، VPS تبدیل به یک محیط اجرای چند کارمند دیجیتال می‌شود. هر کارمند Role، Schedule و Routine خودش را دارد و گزارش‌ها نیز جدا نگهداری می‌شوند.

AI Employee چطور ابزار واقعی پیدا می‌کند؟

مدل زبانی به‌تنهایی نمی‌تواند وضعیت واقعی سرور، CRM، ایمیل یا دیتابیس شما را بداند. باید ابزارهای مشخص در اختیار Agent قرار بگیرد. در معماری‌های جدید، Function Calling و MCP از روش‌های رایج اتصال Agent به ابزارهای بیرونی هستند.

مستندات رسمی Responses API نیز Function Calling، File Search، Web Search و MCP را به‌عنوان روش‌هایی برای اتصال مدل به ابزارها و داده‌های خارجی معرفی می‌کند.

مستندات رسمی ابزارها و Function Calling در Responses API

چطور به Agent اجازه اجرای دستور بدهیم بدون اینکه خطرناک شود؟

یکی از مهم‌ترین تفاوت‌های یک سیستم حرفه‌ای با یک اسکریپت ساده، کنترل سطح دسترسی است. اگر Agent به Shell دسترسی داشته باشد، نباید صرفاً به مدل بگوییم «مراقب باش». باید محدودیت واقعی در سطح ابزار ایجاد شود.

این مدل مخصوصاً برای سرور Production مهم است. یک AI Employee نباید صرفاً به خاطر یک برداشت اشتباه، فایل مهمی را حذف کند یا تنظیمات سرویس را تغییر دهد.

چطور بفهمیم AI Employee واقعاً کار می‌کند؟

برای این سیستم چند شاخص ساده تعریف کنید. هدف فقط این نیست که «Agent اجرا شد»؛ باید بدانیم چه کاری انجام داد و نتیجه چه بود.

ساخت گزارش روزانه مدیریتی

گزارش خوب نباید خروجی خام مدل باشد. بهتر است قالب ثابتی داشته باشد تا مدیر بتواند در کمتر از یک دقیقه وضعیت را بفهمد.

# Daily AI Employee Report

Date: 2026-10-03
Employee: Operations Employee
Status: HEALTHY

## Summary
No critical operational issue detected.

## Facts
- CPU: 34%
- RAM: 48%
- Disk: 41%
- Services: Healthy

## Findings
No abnormal condition detected.

## Recommended Actions
No immediate action required.

## Human Review
None.

بعداً می‌توانید همین گزارش را به Email، Telegram، Slack، Discord یا داشبورد داخلی منتقل کنید. مهم این است که ابتدا چرخه دریافت داده → تحلیل → گزارش پایدار شود.

چه زمانی VPS برای AI Employee مناسب‌تر است؟

اگر قرار است Agent فقط یک بار آزمایشی اجرا شود، کامپیوتر شخصی می‌تواند کافی باشد. اما وقتی Schedule، Webhook، گزارش شبانه، پردازش فایل یا اجرای چند Routine مطرح می‌شود، VPS مزیت مهمی دارد: سیستم به لپ‌تاپ شما وابسته نیست.

برای یک کسب‌وکار، این موضوع اهمیت زیادی دارد. لپ‌تاپ ممکن است خاموش شود، اینترنت قطع شود یا برنامه بسته شود؛ اما VPS برای اجرای سرویس‌های پس‌زمینه طراحی شده است.

ارتباط این معماری با سرویس‌های ایرانیکاسرور

موضوع این مقاله مستقیماً به سرور مجازی لینوکس و زیرساخت اجرای سرویس‌های دائمی مربوط است. برخلاف هاست اشتراکی، AI Employee ممکن است به Python، Docker، Cron، فایل‌های محلی، Processهای دائمی، API و تنظیمات سطح سیستم نیاز داشته باشد.

به همین دلیل، اگر قصد دارید کارمندهای هوش مصنوعی، Agentهای زمان‌بندی‌شده یا Workflowهای دائمی اجرا کنید، سرور مجازی انتخاب انعطاف‌پذیرتری برای این نوع معماری است.

اگر VPS برای AI Employee آماده نشد چه کنیم؟

خطاهای Python، Cron، Permission، RAM، Disk، Docker، API و شبکه می‌توانند باعث شوند Agent در زمان مقرر اجرا نشود. مهم است که قبل از تغییرات متعدد، ابتدا Log مربوط به Scheduler و برنامه را بررسی کنید.

خطاهای رایج در ساخت AI Employee

از یک Agent ساده تا تیم کامل AI Employees

وقتی اولین کارمند شما پایدار شد، می‌توانید به‌جای بزرگ‌ترکردن یک Agent، چند Role مستقل بسازید. مثلاً کارمند SEO فقط مسئول SEO باشد، کارمند Operations وضعیت زیرساخت را بررسی کند و کارمند Content روی جریان محتوا کار کند.

این تفکیک باعث می‌شود Promptها کوتاه‌تر، دسترسی‌ها محدودتر و گزارش‌ها قابل فهم‌تر باشند. همچنین اگر یکی از کارمندان دچار مشکل شد، کل سیستم از کار نمی‌افتد.

جمع‌بندی؛ کارمند هوش مصنوعی یعنی یک شغل، نه یک چت

سوالات متداول درباره AI Employee روی VPS