Wymagania wstępne
Działający przepływ pracy MCP, który można wyrazić jako skrypt — skrypt powinien uruchamiać monit MCP, przechwytywać wyniki i je dostarczać. Zobacz jak wysyłać raporty MCP Cryptohopper na Telegram, Discord lub e-mail.
Klucz API Cryptohopper MCP przechowywany jako zmienna środowiskowa lub sekret. Nigdy nie umieszczaj go na stałe w skrypcie — zobacz najlepsze praktyki dotyczące bezpieczeństwa kluczy API.
Podstawowy wzorzec
Wszystkie trzy systemy planowania opakowują ten sam skrypt. Struktura jest zawsze taka sama: uruchom monit MCP → przechwyć wyniki → dostarcz je. Upewnij się, że zmienne środowiskowe są ustawione, a wyniki są przechwytywane do logu.
# /home/you/scripts/daily_digest.py
import os
import requests
API_KEY = os.environ["CRYPTOHOPPER_MCP_KEY"]
TELEGRAM_TOKEN = os.environ["TELEGRAM_BOT_TOKEN"]
TELEGRAM_CHAT_ID = os.environ["TELEGRAM_CHAT_ID"]
def run_mcp_workflow(prompt: str) -> str:
# Tutaj wywołanie biblioteki klienta MCP — generowanie tekstu raportu.
...
def send_telegram(text: str) -> None:
requests.post(
f"https://api.telegram.org/bot{TELEGRAM_TOKEN}/sendMessage",
json={"chat_id": TELEGRAM_CHAT_ID, "text": text, "parse_mode": "Markdown"},
).raise_for_status()
if __name__ == "__main__":
prompt = open("/home/you/prompts/daily_digest.txt").read()
report = run_mcp_workflow(prompt)
send_telegram(report)
Konfiguracja — cron (macOS / Linux)
Najpierw przetestuj skrypt ręcznie
export CRYPTOHOPPER_MCP_KEY="..."
export TELEGRAM_BOT_TOKEN="..."
export TELEGRAM_CHAT_ID="..."
python3 /home/you/scripts/daily_digest.py
2. Edytuj swój crontab
Uruchom crontab -e i dodaj poniższy wpis. Cron nie dziedziczy środowiska twojej powłoki — zadeklaruj zmienne na górze crontab.
CRYPTOHOPPER_MCP_KEY=twoj_klucz
TELEGRAM_BOT_TOKEN=twoj_token
TELEGRAM_CHAT_ID=twoj_czat_id
PATH=/usr/local/bin:/usr/bin:/bin
# Codziennie o 08:00 czasu lokalnego
0 8 * * * /usr/bin/python3 /home/you/scripts/daily_digest.py >> /home/you/logs/daily.log 2>&1
3. Zweryfikuj
Po zaplanowanym czasie sprawdź log. Pusty log oznacza, że cron nie uruchomił skryptu. Błędy w logu oznaczają, że skrypt się uruchomił, ale wystąpił błąd.
bashtail -50 /home/you/logs/daily.log
Konfiguracja — Harmonogram zadań (Windows)
Przetestuj skrypt z poziomu PowerShella
$env:CRYPTOHOPPER_MCP_KEY = "..."
$env:TELEGRAM_BOT_TOKEN = "..."
$env:TELEGRAM_CHAT_ID = "..."
python C:\Users\you\scripts\daily_digest.py
2. Ustaw wyzwalacz
W sekcji Wyzwalacze skonfiguruj harmonogram (codziennie o 08:00, co tydzień itp.).
3. Skonfiguruj akcję
W sekcji Akcje: Program/skrypt → python (lub pełna ścieżka do python.exe). Dodaj argumenty → C:\Users\you\scripts\daily_digest.py. Rozpoczęcie w → C:\Users\you\scripts.
4. Zarządzaj zmiennymi środowiskowymi
Dwie opcje: ustaw je jako zmienne systemowe przez Panel sterowania → System → Zmienne środowiskowe lub załaduj je z pliku .env przy użyciu biblioteki python-dotenv.
5. Zweryfikuj
Sprawdź "Ostatni wynik uruchomienia zadania" w Harmonogramie zadań. 0x0 oznacza sukces; wszystko inne to błąd.
Konfiguracja — GitHub Actions (hostowane w chmurze)
Utwórz repozytorium GitHub dla swoich zaplanowanych przepływów pracy
Dodaj swój skrypt do repozytorium. Nie zatwierdzaj danych poufnych.
Dodaj sekrety repozytorium
Przejdź do Ustawienia → Sekrety i zmienne → Akcje i dodaj:
CRYPTOHOPPER_MCP_KEY,TELEGRAM_BOT_TOKEN,TELEGRAM_CHAT_ID.
Utwórz plik przepływu pracy
# .github/workflows/daily_digest.yml
name: Dzienny raport
on:
schedule:
- cron: "0 7 * * *" # 07:00 UTC codziennie
workflow_dispatch: # pozwala na ręczne wyzwolenie
jobs:
run:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: "3.12"
- run: pip install -r requirements.txt
- name: Uruchom raport
env:
CRYPTOHOPPER_MCP_KEY: ${{ secrets.CRYPTOHOPPER_MCP_KEY }}
TELEGRAM_BOT_TOKEN: ${{ secrets.TELEGRAM_BOT_TOKEN }}
TELEGRAM_CHAT_ID: ${{ secrets.TELEGRAM_CHAT_ID }}
run: python scripts/daily_digest.py
Harmonogramy GitHub Actions używają UTC — odpowiednio przelicz swój czas lokalny. Monitoruj uruchomienia w zakładce Actions repozytorium; GitHub wysyła e-maila po nieudanym zaplanowanym uruchomieniu.
Wybór miejsca planowania
Opcja | Najlepsza dla | Wada |
cron | Przepływy pracy lokalne/osobiste na maszynie, która jest zawsze włączona | Kończy działanie, gdy Twój laptop przechodzi w stan uśpienia |
Harmonogram zadań | Przepływy pracy osobiste na Windows | Niewygodny interfejs użytkownika, niezręczne zarządzanie zmiennymi środowiskowymi |
GitHub Actions | Niezawodne, hostowane w chmurze, darmowe dla większości zastosowań osobistych | Uruchomienia mogą być opóźnione z powodu przeciążenia GitHub |
VPS + systemd/cron | Niezawodność klasy produkcyjnej | Zarządzasz serwerem |
Dla większości użytkowników GitHub Actions jest właściwym domyślnym wyborem: darmowe, niezawodne, a logi są łatwe do odnalezienia, gdy coś się zepsuje.
Rozwiązywanie problemów
Zadanie cron się nie uruchamia
Sprawdź grep CRON /var/log/syslog (Linux) lub log show --predicate 'process == "cron"' (macOS). Najczęstszą przyczyną jest brakujący PATH lub brakujące zmienne środowiskowe — cron działa w minimalnym środowisku.
Cron działa, ale skrypt natychmiast zwraca błąd
Prawie zawsze brakująca zmienna środowiskowa. Niech skrypt wyświetla jasny komunikat o błędzie i zakończy działanie wcześnie, jeśli wymagana zmienna środowiskowa jest nieobecna — nie pozwól mu milcząco zawieść wewnątrz wywołania MCP.
Zaplanowane zadanie uruchamia się o innej godzinie niż oczekiwano
Strefy czasowe. Cron używa lokalnej strefy czasowej maszyny; GitHub Actions używa UTC. Przetestuj harmonogram o przewidywalnej godzinie przed ustaleniem rzeczywistego rytmu.
Plik logu jest pusty, mimo że skrypt się uruchamia
Przekierowanie nie przechwytuje stderr. Użyj >> log 2>&1 — podwójna strzałka dodaje; pojedyncza > nadpisuje każdy uruchomienie i traci poprzednie wyniki.
Harmonogram GitHub Actions jest pomijany
GitHub ogranicza zaplanowane przepływy pracy podczas wysokiego obciążenia i okazjonalnie pomija uruchomienia. W przypadku przepływów pracy, które muszą działać niezawodnie, użyj drugiego mechanizmu planowania jako kopii zapasowej lub zapłać za dedykowany runner. Dla większości przepływów pracy sporadyczne pominięcia są dopuszczalne.
Zaplanowane uruchomienia zużywają twój limit szybciej niż oczekiwano
Każde uruchomienie to koszt. Monitoruj użycie przez: jak monitorować wydatki Cryptohopper MCP. Tygodniowe sprawdzenie sumy z punktu końcowego użycia MCP szybko wyłapuje wymykające się spod kontroli harmonogramy.
Chcesz precyzji planowania poniżej minuty
Żaden z tych planerów nie zapewnia niezawodnej precyzji poniżej minuty, a zazwyczaj jej nie potrzebujesz. Jeśli myślisz, że potrzebujesz, zrób krok wstecz — przepływ pracy jest prawdopodobnie lepiej zaprojektowany jako webhook wyzwalany zdarzeniami.