Skip to main content
Glama
17191004

TrendRadar MCP Server

by 17191004

🪩 Sponsors

But hmm, if the source text was "## Sponsors" it's Latin already; no translation needed. Fine.

Now "### Bot" section.

Let's continue:

微信赞赏

支付宝赞赏

🤝 Доработка и использование

Если вы используете или заимствуете идеи и основной код этого проекта в своём проекте, будем очень рады, если вы укажете источник и приложите ссылку на этот репозиторий в README или документации.

Это поможет дальнейшему развитию проекта и сообщества. Спасибо за уважение и поддержку! ❤️

💬 Общение и обратная связь

  • GitHub Issues: подходит для конкретных технических вопросов. При обращении, пожалуйста, предоставьте полную информацию (скриншоты, журналы ошибок и т.д.) — это поможет быстрее найти решение.

  • Общение через публичный аккаунт: рекомендуется оставлять комментарии в соответствующих статьях. Если нужно задать вопрос через личные сообщения, лучший «ключ» — сначала поставить лайк/рекомендовать статью. Я чувствую эту благодарность в личных сообщениях (´▽`ʃ♡ƪ).

  • Общение в QQ-группе: подпишитесь на публичный аккаунт и ответьте «交流群», чтобы присоединиться. Независимо от того, новичок вы в ИИ или опытный разработчик, хотите ли вы задать технический вопрос или поделиться опытом — здесь вам рады. В группе приветствуется взаимопомощь и обмен идеями. При вступлении сначала прочитайте объявление группы; при вопросах описывайте проблему чётко и прикладывайте скриншоты. Участники помогут, когда у них будет время — их практический опыт часто быстрее и полнее, чем мой 🤝

Дружеский совет: Этот проект — открытый и бесплатный, а не коммерческий продукт. Относитесь к автору как к другу, а не как к службе поддержки — так общение будет эффективнее!

关注公众号

Related MCP server: TrendRadar

📝 Журнал обновлений

📌 Последние обновления: Журнал обновлений оригинального репозитория :

  • Примечание: рекомендуется просматривать 【Историю обновлений】, чтобы уточнить конкретные 【функциональные возможности】

2026/06/19 - v6.10.0

  • Пакетная обработка AI-перевода: при переводе большого количества заголовков запросы автоматически разбиваются на пакеты, чтобы избежать сбоев перевода из-за превышения лимита одного запроса

  • Рефакторинг модулей: разделены context.py и __main__.py, конвейер AI-фильтрации выделен в отдельный модуль filter_pipeline — обязанности стали яснее, обслуживание проще

  • Исправлено отображение меток источника в Feishu: исправлена проблема, когда метки источника и краткий обзор независимых источников AI в карточках Feishu не отображались из-за CommonMark

2026/02/09 - mcp-v4.0.0

  • 🔥 Прямая отправка AI-сообщений во все каналы: готовый контент от AI одним нажатием отправляется в 9 каналов — Feishu, DingTalk, Telegram, email и другие. Markdown автоматически адаптируется под формат каждой платформы, не нужно беспокоиться о различиях в форматировании

  • Новое руководство по стратегии форматирования: добавлен инструмент get_channel_format_guide, который сообщает AI, какие форматы поддерживает каждый канал и какие есть ограничения — сгенерированный контент выглядит лучше

  • Умная пакетная отправка: сверхдлинные сообщения автоматически разбиваются по байтовым лимитам каждого канала (Feishu 30KB, DingTalk 20KB и т.д.), конфигурация читается из config.yaml

  • Исправлено ошибочное определение каналов: ntfy больше не ошибочно определяется как «настроенный» из-за адреса по умолчанию

  • Оптимизация повторного использования кода: функции пакетной обработки напрямую используют основные модули trendradar, без дублирования

2026/06/02 - v6.9.0

  • Проверка безопасности доменов в топ-списках: добавлен параметр конфигурации expected_domain, проверяющий легальность доменов в возвращаемых данных. При несоответствии данные автоматически отбрасываются с предупреждением — эффективная защита от перехвата ссылок или подмены данных

  • Пользовательский API-адрес для горячих списков: поддержка самостоятельного развёртывания newsnow и настройки api_url для использования собственного источника данных

2026/05/23 - v6.8.0

  • Полное улучшение HTML-отчётов: добавлено отображение метаданных отчёта (время генерации, источник данных, номер версии), автоматическая адаптация тёмного режима, улучшенное взаимодействие с вкладками, визуализация стрелок тренда — читать в браузере стало значительно удобнее

  • Многоисточниковый откат проверки версий: интерфейс проверки версий поддерживает автоматический откат между несколькими CDN-источниками (GitHub → jsDelivr → Cloudflare и др.), что обеспечивает стабильное получение уведомлений об обновлениях даже в сетях с ограниченным доступом

  • Переключатели областей отображения работают: HTML-отчёты и письма теперь корректно учитывают переключатели display.regions.ai_analysis и display.regions.standalone — при выключении они не отображаются

  • Исправлена кнопка экспорта: исправлена проблема с исчезновением иконки выпадающего меню после нажатия кнопки экспорта

  • Исправлен экспорт в Markdown: исправлена ошибка экранирования переносов строк JS при экспорте HTML-отчёта в Markdown

2026/05/15 - v6.7.0

  • Экспорт в Markdown: в выпадающем меню экспорта отчёта добавлен формат Markdown — одним нажатием генерируется структурированный текст со ссылками, удобный для дальнейшей обработки LLM и обмена на разных платформах (#1121)

  • Дедупликация по RSS guid: в хранилище RSS добавлено поле guid, приоритет дедупликации изменён на guid > url — решена проблема повторного добавления одной и той же статьи из-за изменения URL

  • Защита от пустых заголовков: в парсере, слое рендеринга и обратном заполнении перевода добавлена логика резервного поведения для пустых заголовков, чтобы записи без заголовка также корректно отображались

  • Повышение качества перевода: в промпте для перевода требуется сохранять порядок нумерации, пустые результаты перевода больше не перезаписывают исходные заголовки

2026/03/28 - v6.6.0

  • Улучшение HTML-отчётов в браузере: при открытии отчёта в браузере автоматически переключается на широкоэкранный макет, группы ключевых слов и независимые секции поддерживают быстрое переключение вкладок, поле поиска фильтрует заголовки новостей в реальном времени. В почтовых клиентах по-прежнему отображается исходный узкий макет — без регрессий

  • Тёмный режим: переключение на тёмную тему одним нажатием, автоматическое запоминание предпочтений — удобно для чтения ночью

  • Копирование новостей одним нажатием: при наведении курсора на номер новости можно скопировать заголовок и ссылку — удобно для быстрого обмена

  • Оптимизация экспорта: экспорт полной страницы и экспорт фрагментов объединены в выпадающую кнопку экспорта, при создании скриншотов автоматически восстанавливается чистый макет

  • Система горячих клавиш: поддержка W — переключение широкого экрана, D — тёмный режим, / — поиск, ? — просмотр подсказок по горячим клавишам

  • Индикатор прогресса чтения: вверху страницы в реальном времени отображается прогресс чтения

2026/03/12 - v6.5.0

  • Система интеллектуальной AI-фильтрации: больше не нужно вручную задавать ключевые слова! В файле ai_interests.txt опишите свои интересы обычным языком (например, «хочу видеть новости об ИИ и возобновляемой энергетике»), и AI автоматически извлечёт теги и оценит каждую новость, отправляя только действительно релевантный контент. Если AI-фильтрация даст сбой, система автоматически переключится на сопоставление по ключевым словам — доставка не прервётся

  • Разные методы фильтрации и направления интересов для каждого временного интервала: каждый временной интервал в Timeline теперь может независимо настраивать метод фильтрации и тип просматриваемых новостей. Например: утром — быстрая фильтрация по «технологическим ключевым словам», вечером — глубокая фильтрация по «описанию интересов в области финансов и ИИ» — одна система, разные контенты в разное время

  • Область AI-анализа независима от доставки: диапазон данных для AI-анализа может отличаться от отправляемого контента. Например, отправка только новых сообщений (чтобы не беспокоить повторно), но AI анализирует все новости за день (для полной картины трендов). Каждый временный интервал также может иметь свой режим AI-анализа

  • Экономия токенов при AI-фильтрации: уже проанализированные новости не расходуют токены повторно; при изменении описания интересов AI автоматически оценивает масштаб изменений — небольшие правки обновляют только затронутые теги, большие изменения переклассифицируют всё заново

  • Многофайловая конфигурация и изоляция тегов: файлы пользовательских ключевых слов размещаются в config/custom/keyword/, файлы AI-интересов — в config/custom/ai/. Теги из разных файлов независимы и не влияют друг на друга

  • Точное управление AI-переводом: можно отдельно управлять переводом горячих списков, RSS и независимых областей отображения; области, которые не отображаются, автоматически пропускаются — токены не тратятся

  • Пакетная загрузка в удалённое хранилище: несколько операций записи накапливаются и отправляются в облако одним пакетом — уменьшение количества вызовов API

  • Ограничение количества отображаемых элементов для каждой группы ключевых слов/тегов: параметр max_news_per_keyword контролирует максимальное количество новостей в каждой группе, чтобы одна популярная тема не заполняла всю доставку

  • Умное обнаружение конфликтов временных интервалов: если два временных интервала пересекаются, система автоматически сообщает об ошибке и просит изменить конфигурацию — предотвращает непредвиденное поведение из-за конфликтов

  • Исправлены некоторые ошибки

2026/02/09 - v6.0.0

Breaking Change: обновление файла конфигурации (config.yaml 2.0.0), старые параметры push_window и analysis_window больше не поддерживаются. Пожалуйста, перенесите конфигурацию по образцу нового config.yaml

  • Единая система планирования: добавлен timeline.yaml, который одним набором конфигураций управляет «когда собирать / отправлять / анализировать с помощью AI»

  • 5 предустановленных шаблонов: always_on (круглосуточно, по умолчанию), morning_evening (утро/вечер), office_hours (рабочее время), night_owl (ночная сова), custom (пользовательский); также можно добавлять свои шаблоны в разделе presets:, если ключ не повторяется, а затем указать имя шаблона в config.yaml

  • Гибкая настройка временных интервалов: поддержка различий между рабочими днями и выходными, интервалов через полночь, дедупликации once для каждого периода

  • Визуальный редактор конфигурации:

    • Добавлена вкладка редактирования timeline.yaml, рядом с config.yaml / frequency_words.txt

    • Выбор карточек предустановленных режимов: клик — переключение, автоматическая синхронизация с schedule.preset в config.yaml

    • Недельная временная шкала: горизонтальные полосы 7 дней × 24 часа, цветом различаются статусы отправки/анализа/сбора

    • Интерактивные элементы управления: переключатели, выпадающие списки, выбор времени — изменения справа синхронизируются с YAML слева в реальном времени

    • Выпадающий выбор недельного сопоставления: динамическое заполнение на основе дневного плана, перетаскивание и клик для настройки расписания

  • Оптимизация стабильности AI-промптов (ai_analysis_prompt.txt v2.0.0):

    • Отдельное описание правил форматирования: переносы строк/теги/нумерация/запрещённые действия вынесены из JSON-значений в отдельный раздел

    • Упрощён JSON-шаблон: описания полей сокращены до одного предложения + ограничение по количеству символов — меньше путаницы в выводе AI

    • Удалён формат Markdown из system prompt, чтобы соответствовать инструкции «запрещён Markdown»

    • Все JSON-поля объявлены необязательными — отсутствие любого поля не вызывает ошибок, повышена отказоустойчивость

  • Новая сводка AI для независимых областей (ai_analysis.include_standalone):

    • Добавлен отдельный переключатель: при включении AI генерирует краткое резюме для каждого независимого источника

    • Разделение AI-анализа и отображения в доставке: не нужно включать отображение независимых областей в доставке — AI может независимо анализировать полные данные горячих списков

    • Поддержка платформ горячих списков и RSS-источников, включая данные о рейтинге/времени/траектории

    • Анализ траекторий связан с include_rank_timeline: при включении использует данные траекторий для глубокого анализа трендов, при выключении — краткую оценку на основе рейтинга

    • Добавлено JSON-поле standalone_summaries (краткий обзор независимых источников), адаптировано для всех каналов доставки

2026/01/28 - v5.5.0

Как и с функцией mcp, этот маленький инструмент я тоже не буду вести в отдельном репозитории — он чисто фронтенд, так что всё будет вместе

  • Добавлен визуальный редактор конфигурации trendradar

2026/02/02 - mcp-v3.2.0

  • Новый инструмент read_article: чтение полного текста одной статьи через Jina AI Reader (в формате Markdown)

  • Новый инструмент read_articles_batch: пакетное чтение нескольких статей (до 5, с автоматическим ограничением скорости)

  • Рекомендуемый рабочий процесс: search_news(query="ключевое слово", include_url=True) → read_article(url=...) для чтения полного текста

  • Обновление документации: в README-MCP-FAQ.md и README-MCP-FAQ-EN.md добавлены Q19-Q20 с пояснениями по чтению статей

2026/01/10 - mcp-v3.0.0~v3.1.5

  • Breaking Change: возвращаемые значения всех инструментов унифицированы в структуру {success, summary, data, error}

  • Асинхронная согласованность: все 21 инструментальные функции обёрнуты в asyncio.to_thread() для синхронных вызовов

  • MCP Resources: добавлены 4 ресурса (platforms, rss-feeds, available-dates, keywords)

  • Улучшение RSS: get_latest_rss поддерживает запросы за несколько дней (параметр days), дедупликация URL между датами

  • Исправление регулярных выражений: get_trending_topics поддерживает синтаксис /pattern/ и display_name

  • Оптимизация кэша: добавлена функция make_cache_key(), сортировка параметров + MD5-хэш для обеспечения согласованности

  • Новый инструмент check_version: поддержка одновременной проверки обновлений TrendRadar и MCP Server

2026/01/23 - v5.4.0

  • Добавлена независимая настройка режима AI-анализа: follow_report | daily | current | incremental

  • Добавлено управление временным окном AI-анализа, поддержка пользовательских интервалов и ограничения частоты в день

  • Добавлено управление версиями файлов конфигурации

  • Исправлены несколько ошибок

2026/01/19 - v5.3.0

Крупный рефакторинг: миграция AI-модуля на LiteLLM

  • Единый AI-интерфейс: использование LiteLLM вместо ручной реализации, поддержка 100+ AI-провайдеров

  • Упрощение конфигурации: удалено поле provider, вместо него используется формат model: "provider/model_name"

  • Новые функции: автоматические повторы (num_retries), резервные модели (fallback_models)

  • Изменения конфигурации:

    • ai.provider → удалено (объединено с model)

    • ai.base_url → ai.api_base

    • Переменная окружения AI_PROVIDER → удалена

    • Переменная окружения AI_BASE_URL → AI_API_BASE

  • Примеры форматов моделей:

    • DeepSeek: deepseek/deepseek-chat

    • OpenAI: openai/gpt-4o

    • Gemini: gemini/gemini-2.5-flash

    • Anthropic: anthropic/claude-3-5-sonnet

2026/01/17 - v5.2.0

Основное описание см. в config.yaml

🌐 Функция AI-перевода

  • Многоязычный перевод: поддержка перевода содержимого доставки на любой язык

  • Пакетный перевод: умная пакетная обработка, уменьшение количества вызовов API

  • Пользовательские промпты: поддержка настройки стиля перевода

🔧 Оптимизация архитектуры конфигурации

  • Независимая конфигурация AI-моделей: анализ и перевод используют общую конфигурацию моделей

  • Единые переключатели областей: единое управление отображением областей в доставке

  • Пользовательская сортировка областей: настройка порядка отображения каждой области

✨ Улучшение AI-анализа

  • AI-анализ встроен в HTML: результаты анализа напрямую встраиваются в HTML-отчёт, используются в уведомлениях по почте

  • Богато стилизованные AI-блоки: карточный макет с градиентным синим фоном, чёткое разделение измерений анализа

  • Поддержка временной шкалы рейтинга: AI может получать точный рейтинг каждой новости в каждый момент сбора

  • Реорганизация блоков (7→4): объединены в «Основные тенденции», «Общественное мнение и споры», «Аномалии и слабые сигналы», «Рекомендации по стратегии»

🔧 Адаптация нескольких моделей

  • Передача общих параметров: поддержка передачи любых расширенных параметров в API

  • Адаптация Gemini: нативная поддержка параметров, встроенное смягчение политик безопасности

🐛 Исправление ошибок

  • Исправлены несколько известных проблем, повышена стабильность системы

2026/01/10 - v5.0.0

Небольшая история разработки: Отдаю дань уважения той модели от компании C, которая сопровождала меня более двух лет, но сразу после продления подписки показала "This organization has been disabled"

✨ Рефакторинг «пяти основных блоков» содержимого доставки

В этом обновлении содержимое доставки было реорганизовано по областям. Теперь оно чётко разделено на пять основных блоков:

  1. 📊 Новости горячих списков: агрегированные горячие темы со всего интернета, отфильтрованные по вашим ключевым словам.

  2. 📰 RSS-подписки: содержимое ваших персонализированных источников, сгруппированное по ключевым словам.

  3. 🆕 Новое за этот раз: новые горячие темы, обнаруженные в реальном времени с момента последнего запуска (с пометкой 🆕).

  4. 📋 Независимая область отображения: полные горячие списки или RSS-источники указанных платформ, полностью без ограничений фильтрации по ключевым словам.

  5. ✨ Блок AI-анализа: глубокие инсайты от AI, включая обзор трендов, динамику популярности и чрезвычайно важный анализ эмоциональной окраски.

✨ Функция умной AI-доставки

  • Интеграция AI-анализа: использование больших языковых моделей для глубокого анализа содержимого доставки, автоматическая генерация обзора трендов, анализа популярности ключевых слов, межплатформенных связей, оценки потенциального влияния и т.д.

  • Анализ эмоциональной окраски: добавлено глубокое распознавание эмоций, точное улавливание позитивных/негативных, спорных или тревожных настроений в общественном мнении

  • Поддержка нескольких AI-провайдеров: поддержка DeepSeek (по умолчанию, оптимальное соотношение цены и качества), OpenAI, Google Gemini и любых совместимых с OpenAI интерфейсов

  • Два режима доставки: only_analysis (только AI-анализ), both (оба)

  • Пользовательские промпты: настройка роли и формата вывода AI-анализа через файл config/ai_analysis_prompt.txt

  • Многомерный анализ данных: AI может анализировать изменения рейтинга, продолжительность популярности, межплатформенные показатели, прогнозы трендов и т.д.

📋 Функция независимой области отображения

  • Полное отображение горячих списков: полные горячие списки указанных платформ отображаются отдельно, без влияния фильтрации по ключевым словам

  • Независимое отображение RSS: содержимое RSS-источников может отображаться полностью, подходит для источников с небольшим количеством контента

  • Гибкая конфигурация: поддержка настройки списка платформ, списка RSS-источников, максимального количества отображаемых элементов

📊 Рефакторинг опыта доставки

  • Улучшение вёрстки: переработаны и унифицированы статистические заголовки для всех каналов, усилена организация блоков — структура сообщений видна с первого взгляда

  • Упрощение конфигурации: оптимизирована логика настройки каналов уведомлений (например, Feishu) — проще начать

  • Стрелки трендов популярности: добавлены индикаторы 🔺(рост), 🔻(падение), ➖(без изменений) для наглядного отображения изменений популярности

  • Универсальный Webhook: поддержка пользовательских URL-адресов Webhook и JSON-шаблонов, лёгкая адаптация для Discord, Matrix, IFTTT и любых других платформ

🔧 Оптимизация конфигурации

  • Улучшение конфигурации частотных слов: добавлен синтаксис [группа-алиас], поддержка комментариев # — конфигурация стала понятнее (спасибо @songge8 за предложение)

  • Поддержка переменных окружения: конфигурация, связанная с AI-анализом, поддерживает переопределение через переменные окружения (AI_API_KEY, AI_PROVIDER и т.д.)

💡 Подробное руководство по настройке см. в разделе Позвольте AI анализировать горячие темы

2026/01/02 - v4.7.0

  • Исправлено отображение RSS в HTML: исправлена проблема рендеринга из-за несоответствия формата данных RSS, теперь корректно отображается по группам ключевых слов

  • Новый синтаксис регулярных выражений: конфигурация ключевых слов поддерживает синтаксис /pattern/, решающий проблему ложных совпадений английских подстрок (например, ai совпадает с training) 📖 См. подробное описание синтаксиса

  • Новый синтаксис отображаемых имён: использование => примечание для присвоения запоминающегося имени сложным регулярным выражениям — сообщения доставки становятся понятнее (например, /\bai\b/ => AI相关)

  • Не умеете писать регулярные выражения? В README добавлено руководство по генерации регулярных выражений с помощью AI — расскажите ChatGPT/Gemini/DeepSeek, что вы хотите сопоставить, и AI напишет их за вас

2025/12/30 - mcp-v2.0.0

  • Изменение архитектуры: удалена поддержка TXT, унифицировано использование базы данных SQLite

  • Запросы RSS: добавлены get_latest_rss, search_rss, get_rss_feeds_status

  • Единый поиск: search_news поддерживает параметр include_rss для одновременного поиска по горячим спискам и RSS

2026/01/01 - v4.6.0

  • Исправлено отображение RSS в HTML: содержимое RSS объединено в HTML-страницу горячих списков, отображается по группам источников

  • Новая конфигурация display_mode: поддержка keyword (группировка по ключевым словам) и platform (группировка по платформам)

2025/12/30 - v4.5.0

  • Поддержка RSS-источников: добавлен сбор RSS/Atom, статистика по группам ключевых слов (в том же формате, что и горячие списки)

  • Рефакторинг структуры хранения: уплощённая структура каталогов output/{type}/{date}.db

  • Единая конфигурация сортировки: sort_by_position_first влияет и на горячие списки, и на RSS

  • Рефакторинг структуры конфигурации: config.yaml реорганизован в 7 логических групп (app, report, notification, storage, platforms, rss, advanced) — пути конфигурации стали понятнее

2025/12/26 - mcp-v1.2.0

Обновление MCP-модуля — оптимизация набора инструментов, добавлена функция агрегированного сравнения, объединены избыточные инструменты:

  • Новый инструмент aggregate_news — агрегация новостей с дедупликацией по платформам

  • Новый инструмент compare_periods — сравнительный анализ периодов (неделя к неделе/месяц к месяцу)

  • Объединены find_similar_news + search_related_news_history → find_related_news

  • Улучшен get_trending_topics — добавлен режим auto_extract для автоматического извлечения горячих тем

  • Исправлены несколько ошибок

  • Синхронно обновлена документация README-MCP-FAQ.md на китайском и английском (Q1-Q18)

2025/12/20 - v4.0.3

  • Добавлена функция нормализации URL, решающая проблему повторной доставки на таких платформах, как Weibo, из-за динамических параметров (например, band_rank)

  • Исправлена логика обнаружения инкрементального режима, корректное распознавание исторических заголовков

2025/12/17 - v4.0.1

  • StorageManager добавлены прокси-методы для записей доставки

  • S3-клиент переключён на virtual-hosted style для повышения совместимости (поддержка Tencent Cloud COS и других сервисов)

2025/12/13 - mcp-v1.1.0

Обновление MCP-модуля:

  • Адаптация к v4.0.0, также совместимость с данными v3.x

  • Новые инструменты синхронизации хранилища: sync_from_remote, get_storage_status, list_available_dates

2025/12/13 - v4.0.0

🎉 Крупное обновление: полный рефакторинг хранилища и основной архитектуры

  • Поддержка нескольких бэкендов хранилища: внедрён новый модуль хранилища, поддерживающий локальный SQLite и удалённое облачное хранилище (S3-совместимый протокол, например Cloudflare R2), адаптированный для GitHub Actions, Docker и локальной среды.

  • Оптимизация структуры базы данных: рефакторинг структуры таблиц SQLite, повышение эффективности данных и возможностей запросов.

  • Модуляризация основного кода: логика основной программы разделена на несколько модулей пакета trendradar, значительно повышена поддерживаемость кода.

  • Расширенные функции: реализованы стандартизация формата дат, политика хранения данных, поддержка конфигурации часового пояса, оптимизация отображения времени, а также исправлена проблема персистентности данных удалённого хранилища, обеспечивающая точность слияния данных.

  • Очистка и совместимость: удалена большая часть исторического совместимого кода, унифицированы способы хранения и чтения данных.

2025/12/03 - v3.5.0

🎉 Улучшение основных функций

  1. Поддержка нескольких аккаунтов для доставки

    • Все каналы доставки (Feishu, DingTalk, WeChat Work, Telegram, ntfy, Bark, Slack) поддерживают настройку нескольких аккаунтов

    • Разделение нескольких аккаунтов точкой с запятой ;, например: FEISHU_WEBHOOK_URL=url1;url2

    • Автоматическая проверка согласованности количества парных конфигураций (например, token и chat_id для Telegram)

  2. Конфигурация областей доставки

    • Через display.region_order настраивается порядок отображения областей (в v5.2.0 заменяет старый reverse_content_order)

    • Через display.regions управляется отображение областей (горячие списки, новые темы, RSS, независимые области, AI-анализ)

  3. Глобальные фильтрующие ключевые слова

    • Добавлена метка области [GLOBAL_FILTER], поддержка глобальной фильтрации нежелательного контента

    • Сценарии применения: фильтрация рекламы, маркетинга, низкокачественного контента и т.д.

🐳 Оптимизация генерации HTML в Docker (двойной путь)

  • Исправление проблемы: решена проблема невозможности синхронизации index.html с хост-машиной в среде Docker

  • Генерация по двум путям: ежедневный сводный HTML генерируется в двух местах

    • index.html (корень проекта): для доступа через GitHub Pages

    • output/index.html: через Docker Volume, доступен напрямую с хост-машины

  • Совместимость: обеспечение корректного доступа к веб-версии отчёта в Docker, GitHub Actions и локальной среде

🐳 Поддержка Docker MCP-образа

  • Добавлен отдельный образ MCP-сервиса wantcat/trendradar-mcp

  • Поддержка развертывания функции AI-анализа через Docker, предоставление сервиса через HTTP-интерфейс (порт 3333)

  • Двухконтейнерная архитектура: сервис推送 новостей и MCP-сервис работают независимо, могут масштабироваться и перезапускаться по отдельности

  • Подробнее см. Docker-развертывание - MCP-сервис

🌐 Поддержка веб-сервера

  • Добавлен встроенный веб-сервер с поддержкой просмотра сгенерированных отчетов через браузер

  • Управление запуском/остановкой через команду manage.py: docker exec -it trendradar python manage.py start_webserver

  • Адрес доступа: http://localhost:8080 (порт настраивается)

  • Функции безопасности: обслуживание статических файлов, ограничение каталогов, локальный доступ

  • Поддержка двух режимов: автоматический запуск и ручное управление

📖 Оптимизация документации

  • Добавлен раздел Как отображается推送-контент?: настройка стиля и содержимого推送

  • Добавлен раздел Когда мне推送ить?: настройка временных интервалов推送

  • Добавлен раздел Как часто запускать?: настройка частоты автоматического запуска

  • Добавлен раздел 推送 в несколько групп/устройств: одновременная отправка нескольким получателям

  • Оптимизированы разделы конфигурации: единообразно добавлено пояснение "Место настройки"

  • Упрощена инструкция быстрого старта: три основных файла一目了然

  • Оптимизирован раздел Docker-развертывание: добавлено описание образов, рекомендовано развертывание через git clone, реорганизованы способы развертывания

🔧 Инструкция по обновлению:

  • Пользователи GitHub Fork: обновите main.py, config/config.yaml (добавлена поддержка推送 для нескольких аккаунтов, изменение существующей конфигурации не требуется)

  • 推送 для нескольких аккаунтов: новая функция, по умолчанию не включена, существующая конфигурация с одним аккаунтом не затрагивается

2025/11/26 - mcp-v1.0.3

Обновление MCP-модуля:

  • Добавлен инструмент разбора дат resolve_date_range, решающий проблему不一致ности вычисления дат AI-моделями

  • Поддержка разбора выражений дат на естественном языке (эта неделя, последние 7 дней, прошлый месяц и т.д.)

  • Общее количество инструментов увеличено с 13 до 14

2025/11/28 - v3.4.1

🔧 Оптимизация форматов

  1. Улучшение推送 Bark

    • Bark теперь поддерживает рендеринг Markdown

    • Включен нативный формат Markdown: жирный шрифт, ссылки, списки, блоки кода и т.д.

    • Удалено преобразование в обычный текст, полностью используется нативная возможность рендеринга Bark

  2. Точность формата Slack

    • Используется специальный формат mrkdwn для обработки содержимого по частям

    • Повышена точность оценки размера в байтах (предотвращение превышения лимита сообщений)

    • Оптимизирован формат ссылок: <url|text> и синтаксис жирного шрифта: *text*

  3. Повышение производительности

    • Преобразование формата выполняется в процессе разбиения на части, избегая повторной обработки

    • Точная оценка размера сообщения, снижение частоты ошибок отправки

🔧 Инструкция по обновлению:

  • Пользователи GitHub Fork: обновите main.py, config.yaml

2025/11/25 - v3.4.0

🎉 Добавлена поддержка推送 Slack

  1. Канал推送 для командной работы

    • Поддержка Slack Incoming Webhooks (популярный инструмент командной работы по всему миру)

    • Централизованное управление сообщениями, подходит для обмена горячими новостями в команде

    • Поддержка формата mrkdwn (жирный шрифт, ссылки и т.д.)

  2. Несколько способов развертывания

    • GitHub Actions: настройка Secret SLACK_WEBHOOK_URL

    • Docker: переменная окружения SLACK_WEBHOOK_URL

    • Локальный запуск: файл конфигурации config/config.yaml

📖 Подробная инструкция по настройке: Быстрый старт -推送 Slack

  • Оптимизирован опыт установки MCP в один клик через setup-windows.bat и setup-windows-en.bat

🔧 Инструкция по обновлению:

  • Пользователи GitHub Fork: обновите main.py, config/config.yaml, .github/workflows/crawler.yml

2025/11/24 - v3.3.0

🎉 Добавлена поддержка推送 Bark

  1. Эксклюзивный канал推送 для iOS

    • Поддержка推送 Bark (на основе APNs, платформа iOS)

    • Бесплатно и с открытым исходным кодом, просто и эффективно, без рекламы

    • Поддержка как официального сервера, так и собственного сервера

  2. Несколько способов развертывания

    • GitHub Actions: настройка Secret BARK_URL

    • Docker: переменная окружения BARK_URL

    • Локальный запуск: файл конфигурации config/config.yaml

📖 Подробная инструкция по настройке: Быстрый старт -推送 Bark

🐛 Исправление ошибок

  • Исправлена проблема, когда конфигурация ntfy_server_url в config.yaml не применялась (#345)

🔧 Инструкция по обновлению:

  • Пользователи GitHub Fork: обновите main.py, config/config.yaml, .github/workflows/crawler.yml

2025/11/23 - v3.2.0

🎯 Добавлены функции расширенной настройки

  1. Настройка приоритета сортировки ключевых слов

    • Поддержка двух стратегий сортировки: приоритет популярности vs приоритет порядка конфигурации

    • Удовлетворение различных сценариев использования: отслеживание горячих тем или персонализированное внимание

  2. Точное управление количеством отображаемых элементов

    • Глобальная конфигурация: единое ограничение количества отображаемых элементов для всех ключевых слов

    • Индивидуальная конфигурация: использование синтаксиса @数字 для установки ограничений для конкретных ключевых слов

    • Эффективный контроль длины推送, выделение ключевого контента

📖 Подробная инструкция по настройке: Конфигурация ключевых слов - Расширенная конфигурация

🔧 Инструкция по обновлению:

  • Пользователи GitHub Fork: обновите main.py, config/config.yaml

2025/11/18 - mcp-v1.0.2

Обновление MCP-модуля:

  • Оптимизирована ситуация, когда при запросе сегодняшних новостей могли ошибочно возвращаться данные за прошлые даты

2025/11/22 - v3.1.1

  • Исправлена проблема сбоя из-за аномальных данных: решена ошибка 'float' object has no attribute 'lower', с которой сталкивались некоторые пользователи в среде GitHub Actions

  • Добавлен двойной механизм защиты: фильтрация недопустимых заголовков (None, float, пустые строки) на этапе получения данных, а также проверка типов в местах вызова функций

  • Повышена стабильность системы, обеспечена нормальная работа даже при возврате аномальных форматов от источников данных

Инструкция по обновлению (пользователи GitHub Fork):

  • Обязательно обновить: main.py

  • Рекомендуется использовать обновление малой версии: скопировать и заменить указанные файлы

2025/11/20 - v3.1.0

  • Добавлена поддержка推送 в личный WeChat: приложение корпоративного WeChat может推送ить в личный WeChat, без установки приложения корпоративного WeChat

  • Поддержка двух форматов сообщений: markdown (робот группы корпоративного WeChat) и text (приложение личного WeChat)

  • Добавлена переменная окружения WEWORK_MSG_TYPE, поддержка различных способов развертывания: GitHub Actions, Docker, docker compose и др.

  • Режим text автоматически удаляет синтаксис Markdown, обеспечивая推送 в виде обычного текста

  • Подробнее см. описание конфигурации «推送 в личный WeChat» в разделе быстрого старта

Инструкция по обновлению (пользователи GitHub Fork):

  • Обязательно обновить: main.py, config/config.yaml

  • Опционально обновить: .github/workflows/crawler.yml (при развертывании через GitHub Actions)

  • Рекомендуется использовать обновление малой версии: скопировать и заменить указанные файлы

2025/11/12 - v3.0.5

  • Исправлена логическая ошибка конфигурации порта SSL/TLS при отправке почты

  • Оптимизировано использование порта 465 (SSL) по умолчанию для почтовых провайдеров (QQ/163/126)

  • Добавлена поддержка переменных окружения Docker: основные параметры конфигурации (enable_crawler, report_mode, push_window и др.) можно переопределять через переменные окружения, решена проблема, когда изменения файла конфигурации не применялись у пользователей NAS (подробнее см. раздел 🐳 Docker-развертывание)

2025/10/26 - mcp-v1.0.1

Обновление MCP-модуля:

  • Исправлена ошибка передачи параметров даты в запросах

  • Унифицирован формат временных параметров для всех инструментов

2025/10/31 - v3.0.4

  • Решена проблема ошибок推送 Feishu из-за слишком длинного содержимого, реализована отправка по частям

2025/10/23 - v3.0.3

  • Расширена область отображения сообщений об ошибках ntfy

2025/10/21 - v3.0.2

  • Исправлена проблема кодировки при推送 ntfy

2025/10/20 - v3.0.0

Крупное обновление - запуск функции AI-анализа ✨

  • Основные функции:

    • Добавлен сервер AI-анализа на основе MCP (Model Context Protocol)

    • Поддержка 17 инструментов интеллектуального анализа: базовые запросы, интеллектуальный поиск, расширенный анализ, RSS-запросы, управление системой

    • Взаимодействие на естественном языке: запрос и анализ новостных данных через диалог

    • Поддержка нескольких клиентов: Claude Desktop, Cherry Studio, Cursor, Cline и др.

  • Возможности анализа:

    • Анализ трендов тем (отслеживание популярности, жизненный цикл, обнаружение всплесков, прогнозирование трендов)

    • Анализ данных (сравнение платформ, статистика активности, совместное появление ключевых слов)

    • Анализ тональности, поиск похожих новостей, генерация интеллектуальных сводок

    • Поиск исторических релевантных новостей, мультимодальный поиск

  • Примечание по обновлению:

    • Это независимая функция AI-анализа, не влияет на существующую функцию推送

    • Можно использовать по желанию, обновление существующего развертывания не требуется

2025/10/15 - v2.4.4

  • Содержание обновления:

    • Исправлена проблема кодировки при推送 ntfy + 1

    • Исправлена проблема определения временного окна推送

  • Примечание по обновлению:

    • Рекомендуется 【обновление малой версии】

2025/10/10 - v2.4.3

Благодарим nidaye996 за обнаруженные проблемы с удобством использования

  • Содержание обновления:

    • Переработан «режим тихого推送», переименован в «управление временным окном推送», повышена понятность функции

    • Уточнено, что временное окно推送 является опциональной дополнительной функцией, может использоваться с тремя режимами推送

    • Улучшены комментарии и описания в документации, функция стала более понятной

  • Примечание по обновлению:

    • Это только рефакторинг, обновление не обязательно

2025/10/8 - v2.4.2

  • Содержание обновления:

    • Исправлена проблема кодировки при推送 ntfy

    • Исправлена проблема отсутствия файла конфигурации

    • Оптимизирован эффект推送 ntfy

    • Добавлена функция экспорта изображений по частям для github page

  • Примечание по обновлению:

    • Рекомендуется 【крупное обновление версии】

2025/10/2 - v2.4.0

Добавлены уведомления推送 ntfy

  • Основные функции:

    • Поддержка публичного сервиса ntfy.sh и самостоятельно размещенных серверов

  • Сценарии использования:

    • Подходит для пользователей, заботящихся о конфиденциальности (поддержка самостоятельного размещения)

    • Кроссплатформенный推送 (iOS, Android, Desktop, Web)

    • Не требуется регистрация аккаунта (публичный сервер)

    • Открытый исходный код, бесплатно (лицензия MIT)

  • Примечание по обновлению:

    • Рекомендуется 【крупное обновление версии】

2025/09/26 - v2.3.2

  • Исправлена проблема пропущенной проверки конфигурации почтовых уведомлений (#88)

Описание исправления:

  • Решена проблема, когда даже при корректной настройке почтовых уведомлений система сообщала «не настроен ни один webhook»

2025/09/22 - v2.3.1

  • Добавлена функция推送 по электронной почте, поддержка отправки отчетов о горячих новостях на почту

  • Интеллектуальное распознавание SMTP: автоматическое распознавание конфигурации более 10 почтовых провайдеров, включая Gmail, QQ邮箱, Outlook, 网易邮箱 и др.

  • Красивый HTML-формат: содержимое письма использует тот же HTML-формат, что и веб-версия, с красивым оформлением и адаптацией для мобильных устройств

  • Поддержка массовой отправки: поддержка нескольких получателей, разделенных запятыми для одновременной отправки

  • Пользовательский SMTP: возможность настройки собственного SMTP-сервера и порта

  • Исправлена проблема сетевого подключения при сборке Docker

Инструкция по использованию:

  • Сценарии применения: подходит для пользователей, которым нужна архивация почты, обмен в команде, периодические отчеты

  • Поддерживаемые почтовые сервисы: Gmail, QQ邮箱, Outlook/Hotmail, 163/126邮箱, 新浪邮箱, 搜狐邮箱 и др.

Примечание по обновлению:

  • В этом обновлении много изменений, для обновления рекомендуется использовать 【крупное обновление версии】

2025/09/17 - v2.2.0

  • Добавлена функция сохранения новостных изображений в один клик, позволяющая легко делиться интересующими вас горячими темами

Инструкция по использованию:

  • Сценарии применения: после включения веб-версии по инструкции (GitHub Pages)

  • Способ использования: откройте веб-ссылку на телефоне или компьютере, нажмите кнопку «Сохранить как изображение» в верхней части страницы

  • Результат: система автоматически создаст красивое изображение из текущего новостного отчета, которое сохранится в галерею телефона или на рабочий стол компьютера

  • Удобство обмена: вы можете напрямую отправить это изображение друзьям, опубликовать в Moments или поделиться в рабочей группе, чтобы другие тоже увидели важную информацию, которую вы обнаружили

2025/09/13 - v2.1.2

  • Решена проблема сбоя推送 новостей из-за ограничения объема推送 DingTalk (использована отправка по частям)

2025/09/04 - v2.1.1

  • Исправлена проблема невозможности запуска docker на некоторых архитектурах

  • Официально опубликован официальный Docker-образ wantcat/trendradar с поддержкой нескольких архитектур

  • Оптимизирован процесс развертывания Docker, быстрый запуск без локальной сборки

2025/08/30 - v2.1.0

Основные улучшения:

  • Оптимизация логики推送: изменение с «推送 при каждом выполнении» на «управляемый推送 в пределах временного окна»

  • Управление временным окном: возможность установки диапазона времени推送, чтобы не беспокоить в нерабочее время

  • Выбор частоты推送: поддержка однократного или многократного推送 в пределах временного интервала

Примечание по обновлению:

  • Эта функция по умолчанию отключена, необходимо вручную включить управление временным окном推送 в config.yaml

  • Для обновления необходимо обновить оба файла: main.py и config.yaml

2025/08/27 - v2.0.4

  • Эта версия не является исправлением функций, а важным напоминанием

  • Пожалуйста, обязательно храните webhooks в безопасности, не публикуйте их, не публикуйте, не публикуйте

  • Если вы развернули этот проект на GitHub через fork, заполните webhooks в GitHub Secret, а не в config.yaml

  • Если вы уже раскрыли webhooks или заполнили их в config.yaml, рекомендуется удалить и создать заново

2025/08/06 - v2.0.3

  • Оптимизирован эффект веб-версии github page для удобства использования на мобильных устройствах

2025/07/28 - v2.0.2

  • Рефакторинг кода

  • Решена проблема, когда номер версии легко забыть изменить

2025/07/27 - v2.0.1

Исправленные проблемы:

  1. Проблема сбоя выполнения из-за символов перевода строки CRLF в shell-скрипте docker

  2. Логическая проблема, когда при пустом frequency_words.txt новости также отправлялись пустыми

  • После исправления, когда вы выбираете пустой frequency_words.txt, будут推送иться все новости, но из-за ограничений размера сообщений推送, пожалуйста, внесите следующие корректировки

    • Вариант 1: отключите мобильный推送, выберите только развертывание Github Pages (это вариант с наиболее полной информацией, все горячие темы всех платформ будут пересортированы по вашему пользовательскому алгоритму горячих тем)

    • Вариант 2: уменьшите количество платформ推送, отдайте приоритет корпоративному WeChat или Telegram, для этих двух推送 я реализовал функцию отправки по частям (поскольку отправка по частям влияет на опыт推送, и только эти две платформы дают лишь небольшой объем推送, пришлось сделать функцию отправки по частям, но по крайней мере гарантируется полнота получаемой информации)

    • Вариант 3: можно комбинировать с вариантом 2, выбор режима current или incremental позволит эффективно уменьшить объем推送 за один раз

2025/07/17 - v2.0.0

Крупный рефакторинг:

  • Рефакторинг управления конфигурацией: все конфигурации теперь управляются через файл config/config.yaml (main.py я по-прежнему не разделял, чтобы вам было удобно копировать при обновлении)

  • Обновление режимов работы: поддержка трех режимов - daily (сводка за день), current (текущий рейтинг), incremental (инкрементальный мониторинг)

  • Поддержка Docker: полное решение для развертывания Docker, поддержка контейнеризации

Описание файлов конфигурации:

  • config/config.yaml - основной файл конфигурации (настройки приложения, конфигурация краулера, конфигурация уведомлений, конфигурация платформ и т.д.)

  • config/frequency_words.txt - конфигурация ключевых слов (настройка отслеживаемых слов)

2025/07/09 - v1.4.1

Новая функция: добавлен инкрементальный推送 (настройка FOCUS_NEW_ONLY в начале main.py), этот переключатель отслеживает только новые темы, а не постоянную популярность, уведомления отправляются только при появлении нового контента.

Исправленные проблемы: в некоторых случаях возникали случайные проблемы с форматированием из-за специальных символов в самих новостях.

2025/06/23 - v1.3.0

Сообщения推送 корпоративного WeChat и Telegram имеют ограничения по длине, поэтому я реализовал отправку сообщений по частям. Документация для разработчиков: 企业微信 и Telegram

2025/06/21 - v1.2.1

В старых версиях до этой версии требовалось копировать и заменять не только main.py, но и crawler.yml https://github.com/sansan0/TrendRadar/blob/master/.github/workflows/crawler.yml

2025/06/19 - v1.2.0

Благодарю claude research за систематизацию API различных платформ, что позволило мне быстро выполнить адаптацию платформ (хотя кода стало больше и он стал более избыточным~)

  1. Поддержка каналов推送 telegram, корпоративный WeChat, DingTalk, поддержка многоканальной конфигурации и одновременного推送

2025/06/18 - v1.1.0

200 звезд⭐! Продолжаю радовать всех~ В последнее время, по моему «подстрекательству», многие люди ставили лайки, делились и рекомендовали меня в моем публичном аккаунте, я видел в бэкенде конкретные данные поддержки аккаунтов, многие стали старыми фанатами с ангельского раунда (я веду публичный аккаунт чуть больше месяца, хотя зарегистрирован он был 7-8 лет назад, ха-ха, сел в поезд рано, а отправился поздно), но поскольку вы не оставляли комментарии или личные сообщения, я не мог ответить каждому и поблагодарить за поддержку, поэтому благодарю всех здесь!

  1. Важное обновление: добавлены веса, теперь вы видите самые горячие и самые обсуждаемые новости вверху

  2. Обновлена документация по использованию, так как в последнее время добавлено много функций, а предыдущую документацию я написал лениво и просто (см. полную инструкцию по настройке ⚙️ frequency_words.txt ниже)

2025/06/16 - v1.0.0

  1. Добавлено уведомление о новой версии проекта, по умолчанию включено, для отключения измените "FEISHU_SHOW_VERSION_UPDATE": True на False в main.py

2025/06/13+14

  1. Удален код совместимости, у тех, кто форкнул ранее, при прямом копировании кода в день копирования будет отображаться аномалия (на следующий день восстановится)

  2. Внизу feishu и html добавлено отображение новых новостей

2025/06/09

100 звезд⭐! Напишу небольшую функцию для всех В файл frequency_words.txt добавлена функция 【обязательные слова】, используйте знак +

  1. Синтаксис обязательных слов:
    Тан Сэн или Чжу Бацзе должны одновременно присутствовать в заголовке, чтобы новость была включена в推送

+唐僧
+猪八戒
  1. Приоритет фильтрующих слов выше:
    Если в заголовке фильтрующее слово совпадает с «Тан Сэн читает сутры», то даже если в обязательных словах есть Тан Сэн, новость не будет отображаться

+唐僧
!唐僧念经

2025/06/02

  1. Веб-страница и сообщения Feishu поддерживают прямой переход к подробностям новости с телефона

  2. Оптимизирован эффект отображения + 1

2025/05/26

  1. Оптимизирован эффект отображения сообщений Feishu

✨ Основные функции

Агрегация горячих тем со всего интернета

  • 知乎

  • 抖音

  • bilibili 热搜

  • 华尔街见闻

  • 贴吧

  • 百度热搜

  • 财联社热门

  • 澎湃新闻

  • 凤凰网

  • 今日头条

  • 微博

По умолчанию отслеживаются 11 основных платформ, также можно добавить дополнительные платформы самостоятельно

💡 Подробная инструкция по настройке: Подробная конфигурация - Конфигурация платформ

Поддержка RSS-подписок (новая функция v4.5.0)

Поддержка抓取 RSS/Atom-подписок, группировка и статистика по ключевым словам (формат такой же, как у горячих рейтингов):

  • Единый формат: RSS и горячие рейтинги используют одинаковое сопоставление ключевых слов и формат отображения

  • Простая настройка: добавление RSS-источников напрямую в config.yaml

  • Объединенный推送: горячие рейтинги и RSS объединяются в одно сообщение推送

  • Фильтрация по свежести: автоматическая фильтрация старых статей старше указанного количества дней, предотвращение повторного推送. Поддержка глобального значения по умолчанию и индивидуальной настройки для каждого источника

💡 RSS использует тот же frequency_words.txt для фильтрации по ключевым словам, что и горячие рейтинги

Визуальный редактор конфигурации

Предоставляет веб-интерфейс для графической настройки, без необходимости ручного редактирования YAML-файлов, все параметры конфигурации можно изменить и экспортировать через формы.

👉 Онлайн-демо: https://sansan0.github.io/TrendRadar/

Интеллектуальная стратегия推送

Три режима推送:

Режим

Сценарии применения

Особенности推送

Сводка за день (daily)

Руководители предприятий/обычные пользователи

Отправка всех соответствующих новостей за день по расписанию (включая ранее推送енные)

Текущий рейтинг (current)

Самозанятые/создатели контента

Отправка новостей, соответствующих текущему рейтингу, по расписанию (постоянно находящиеся в рейтинге появляются каждый раз)

Инкрементальный мониторинг (incremental)

Инвесторы/трейдеры

Отправка только нового контента, ноль повторов

💡 Краткое руководство по выбору:

  • Не хотите видеть повторяющиеся новости → используйте incremental (инкрементальный мониторинг)

  • Хотите видеть полную тенденцию рейтинга → используйте current (текущий рейтинг)

  • Нужен ежедневный сводный отчет → используйте daily (сводка за день)

Подробное сравнение и инструкция по настройке: Подробная конфигурация - Подробное описание режимов推送

Дополнительные функции (опционально):

Функция

Описание

По умолчанию

Система расписания

Почасовая организация с понедельника по воскресенье: для каждого дня назначаются разные временные интервалы, режимы推送 и стратегии AI-анализа. Для каждого временного интервала можно независимо настроить метод фильтрации (ключевые слова/AI) и направление интересов, что позволяет видеть разные типы новостей в разное время. Встроено 5 пресетов (always_on / morning_evening / office_hours / night_owl / custom), также возможна настройка. Поддержка различий между рабочими и выходными днями, интервалов через полночь, дедупликации per-period, обнаружения конфликтов интервалов (v6.0.0 + v6.5.0)

morning_evening

Настройка порядка контента

Через display.region_order настраивается порядок отображения различных областей (горячие рейтинги, новые горячие темы, RSS, отдельная область отображения, AI-анализ); через display.regions управляется отображение каждой области (v5.2.0)

см. файл конфигурации

Переключение режима отображения

keyword=группировка по ключевым словам, platform=группировка по платформам (новая функция v4.6.0)

keyword

💡 Подробная инструкция по настройке: Как отображается推送-контент? и Когда мне推送ить?

Точная фильтрация контента

Установите персональные ключевые слова (например: AI, BYD, образовательная политика), чтобы推送ить только релевантные горячие темы и отфильтровывать нерелевантную информацию

💡 Инструкция по базовой настройке: Конфигурация ключевых слов - Базовый синтаксис

💡 Инструкция по расширенной настройке: Конфигурация ключевых слов - Расширенная конфигурация

💡 Также можно не выполнять фильтрацию и推送ить все горячие темы полностью (оставьте frequency_words.txt пустым)

Интеллектуальная фильтрация новостей с помощью AI (новая функция v6.5.0)

Опишите свои интересы на естественном языке, AI автоматически классифицирует новости, заменяя традиционное сопоставление по ключевым словам

  • Описание интересов на естественном языке: запишите в ai_interests.txt свои интересы повседневным языком — не нужно изучать синтаксис ключевых слов

  • Двухэтапная интеллектуальная обработка: AI сначала извлекает структурированные теги из описания интересов, затем массово классифицирует и оценивает новости по тегам

  • Контроль порога оценки: через ai_filter.min_score можно точно управлять качеством push-уведомлений — отправляются только новости с высокой релевантностью

  • Автоматический откат: при сбое AI-фильтрации автоматически выполняется откат к сопоставлению по ключевым словам, push не прерывается

  • Умное обновление тегов: при изменении интересов AI сам оценивает масштаб изменений и выбирает инкрементальную или полную переклассификацию

  • Гибкое переключение: filter.method поддерживает два режима — keyword (по умолчанию) и ai; для Timeline можно задавать переопределение по временным периодам

  • Персонализация по периодам: в разные отрезки времени можно использовать разные файлы ключевых слов или AI-описание интересов. Например, утром — быстрая фильтрация по «техническому тезаурусу», вечером — глубокий AI-анализ по «финансовым интересам»

# config.yaml 快速启用示例
filter:
  method: ai          # keyword(默认)| ai
ai_filter:
  min_score: 6         # 推送最低分数阈值(1-10)

💡 AI-фильтрация использует общую конфигурацию моделей с AI-анализом и переводом — достаточно один раз указать ai.api_key

Анализ трендов в реальном времени

Отслеживайте изменения популярности новостей в реальном времени: вы будете знать не только «что в тренде», но и «как развивается тема».

  • Отслеживание по временной шкале: фиксируется полный период от первого появления новости до последнего

  • Изменение популярности: статистика изменения позиций и частоты появления новостей в разные периоды времени

  • Обнаружение нового: мгновенно распознаёт новые горячие темы и сразу помечает их значком 🆕

  • Анализ устойчивости: различает разовые хайпы и глубокие новости, которые продолжают развиваться

  • Сравнение между платформами: показывает рейтинг одной и той же новости на разных платформах, выявляя разницу во внимании СМИ

💡 Описание формата push-уведомлений см. в Как выглядят мои сообщения

Персонализированный алгоритм горячих тем

Больше не нужно плясать под дудку алгоритмов разных платформ — TrendRadar пересобирает горячий поиск по всему интернету.

💡 Три пропорции можно настроить, подробнее в Конфигурация — Настройка весов горячих тем

Мультиканальные push-уведомления и несколько аккаунтов

Поддерживаются 企业微信 (+ схема доставки в WeChat), 飞书, 钉钉, Telegram, электронная почта, ntfy, Bark, Slack, универсальный Webhook (можно подключить Discord, IFTTT и любые другие платформы). Сообщения приходят прямо на телефон и на почту.

💡 Подробная инструкция по настройке — Push в несколько групп/устройств

AI-перевод на разные языки (новое в v5.2.0)

Переводит содержимое push-уведомлений на любой язык, устраняя языковой барьер. Читайте горячие темы внутри страны или зарубежные новости через RSS — всё легко на родном языке.

  • Перевод в один клик: достаточно указать ai_translation.enabled: true и целевой язык в config.yaml

  • Поддержка многих языков: поддерживаются English, Korean, Japanese, French и любые другие языки

  • Умная пакетная обработка: автоматический пакетный перевод сокращает количество API-вызовов и экономит средства

  • Собственный стиль: настройте стиль перевода и терминологию через ai_translation_prompt.txt

  • Общая конфигурация моделей: используются те же настройки моделей из раздела ai, что и для AI-анализа

# config.yaml 快速启用示例
ai_translation:
  enabled: true
  language: "English"  # 翻译目标语言

💡 Перевод и AI-анализ используют общую конфигурацию моделей — достаточно один раз указать ai.api_key, чтобы пользоваться обеими функциями

Источники RSS: ниже приведены подборки RSS-каналов на любой вкус

  • awesome-tech-rss — блоги и СМИ о технологиях, стартапах и программировании

  • awesome-rss-feeds — подборка RSS ведущих мировых новостных СМИ

⚠️ Некоторые зарубежные медиа могут содержать чувствительные темы; AI-модель может отказаться переводить. Рекомендуем отбирать источники по своим потребностям.

Расширения для просмотра HTML-отчёта в браузере (новое в v6.6.0)

При открытии push-уведомления с HTML-отчётом в браузере автоматически включаются расширенные возможности (на почтовые клиенты не влияет):

  • Широкоэкранный режим: на десктопе автоматически включается широкая разметка 1200px — максимально полно используется пространство экрана

  • Быстрое переключение вкладок: группы ключевых слов и отдельные секции поддерживают навигацию по вкладкам — никакого долгого прокручивания

  • Тёмная тема: переключается одним нажатием, выбор запоминается автоматически

  • Живой поиск: нажмите /, чтобы вызвать поиск и мгновенно отфильтровать заголовки новостей

  • Копирование в один клик: наведите на номер новости, чтобы скопировать заголовок и ссылку

  • Горячие клавиши: W — широкий экран, D — тёмная тема, / — поиск, ? — все горячие клавиши

💡 Все улучшения реализованы через прогрессивное улучшение: в почтовых клиентах по-прежнему отображается исходная вёрстка 600px, без регрессий.

Гибкая архитектура хранения (крупное обновление v4.0.0)

Поддержка нескольких бэкендов хранения:

  • Удалённое облачное хранилище: по умолчанию в среде GitHub Actions; поддержка S3-совместимых протоколов (R2/OSS/COS и др.). Данные хранятся в облаке и не засоряют репозиторий

  • Локальная база данных SQLite: по умолчанию в Docker/локальных средах; данные полностью под контролем

  • Автоматический выбор бэкенда: интеллектуальное переключение способа хранения в зависимости от среды выполнения

💡 Подробнее: Где хранятся данные?

Развёртывание на разных платформах

  • GitHub Actions: автоматический сбор по расписанию + удалённое облачное хранилище (требуется периодическое продление)

  • Docker: контейнеризация с поддержкой нескольких архитектур, локальное хранение данных

  • Локальный запуск: работает напрямую на Windows/Mac/Linux

AI-анализ и push-уведомления (новое в v5.0.0)

Глубокий анализ содержимого push-уведомлений с помощью больших языковых моделей и автоматическая генерация отчёта с инсайтами по горячим темам.

  • Интеллектуальный анализ: автоматический анализ трендов, популярности ключевых слов, связей между платформами и потенциального влияния

  • Много провайдеров: единый интерфейс на основе LiteLLM, поддержка 100+ AI-провайдеров (DeepSeek, OpenAI, Gemini, Anthropic, локальный Ollama и др.), а также автоматическое переключение на запасные модели

  • Независимый режим анализа: область анализа AI может отличаться от push — push отправляет только новые сообщения (чтобы не беспокоить), а AI может анализировать все новости за день (для полной картины трендов)

  • Гибкая отправка: можно выбрать только исходный контент, только AI-анализ или оба варианта

  • Собственные промпты: настройте угол анализа через config/ai_analysis_prompt.txt

💡 Подробная инструкция: AI помогает мне анализировать горячие темы

Отдельные секции (новое в v5.0.0)

Полные рейтинги горячих тем для указанных платформ, не зависящие от фильтрации по ключевым словам.

  • Полный топ: полное отображение рейтинга указанных платформ — для тех, кто хочет видеть весь список

  • Отдельный RSS: содержимое RSS-источников отображается полностью, без ограничений по ключевым словам

  • Глубокий AI-анализ: можно отдельно включить AI-анализ трендов по полному рейтингу, не показывая его в push

  • Гибкая настройка: выбор платформ, RSS-источников и максимального количества записей

💡 Подробная инструкция: Как отображается содержимое push? — Отдельные секции

Интеллектуальный AI-анализ (новое в v3.0.0)

Диалоговая система анализа на базе протокола MCP (Model Context Protocol), позволяющая глубоко исследовать новостные данные на естественном языке.

💡 Совет: для работы AI нужны локальные новостные данные

  • В проект встроены тестовые данные — можно сразу попробовать

  • Рекомендуется развернуть и запустить проект самостоятельно для более актуальных данных

Подробнее см. AI-интеллектуальный анализ

Веб-развёртывание

После запуска в корневой папке создаётся index.html — это полноценная страница новостного отчёта.

Способ развёртывания: нажмите Use this template, чтобы создать репозиторий; его можно развернуть на статических хостингах, например Cloudflare Pages или GitHub Pages.

💡 Подсказка: включите GitHub Pages, чтобы получить онлайн-адрес: откройте Settings → Pages в репозитории. Предпросмотр

⚠️ Прежняя функция автоматического хранения в GitHub Actions отключена (из-за этого решения нагрузка на серверы GitHub была слишком высокой и влияла на стабильность платформы).

☁️ Автоматическое развёртывание на Cloudflare Pages (необязательно · быстрее из Китая)

GitHub Pages из Китая открывается медленно, а Cloudflare Pages работает быстрее. После настройки каждый запуск GitHub Actions будет автоматически отправлять свежий index.html на Cloudflare Pages — никаких ручных действий не требуется.

Необходимые условия: вы уже выполнили развёртывание через GitHub Actions и можете нормально генерировать веб-отчёт.

① Создайте проект Cloudflare Pages

Войдите в Cloudflare Dashboard → Workers & Pages → Create → Pages → выберите Upload assets (прямая загрузка), укажите имя проекта (например, trendradar, запомните его), загрузите любой файл для первичного создания (в дальнейшем Actions автоматически заменит его).

② Получите API Token и Account ID

  • API Token: аватар в правом верхнем углу → My Profile → API Tokens → Create Token → Create Custom Token, выберите разрешения Account → Cloudflare Pages → Edit. После создания скопируйте Token (показывается только один раз).

  • Account ID: находится в правой боковой панели страницы Workers & Pages (или в правом нижнем углу страницы Overview любого домена).

③ Добавьте 3 Secrets в репозиторий GitHub

Перейдите в Settings → Secrets and variables → Actions → New repository secret и добавьте по очереди:

Name (имя)

Secret (значение)

CLOUDFLARE_API_TOKEN

API Token, созданный на предыдущем шаге

CLOUDFLARE_ACCOUNT_ID

ваш Cloudflare Account ID

CLOUDFLARE_PROJECT_NAME

имя проекта Cloudflare Pages (например, trendradar)

После настройки следующий запуск GitHub Actions автоматически выполнит развёртывание. Адрес: https://<项目名>.pages.dev.

💡 Примечание: если отсутствует хотя бы один из трёх Secrets, развёртывание Cloudflare автоматически пропускается — это не влияет на другие функции, например на push новостей. Чтобы привязать собственный домен, настройте его в Custom domains проекта Pages.

Меньше зависимости от приложений

Переход от «заложника алгоритмических рекомендаций» к «самостоятельному получению нужной информации».

Кому подходит: инвесторам, контент-мейкерам, PR-специалистам компаний, обычным пользователям, следящим за событиями.

Типичные сценарии: мониторинг биржевых инвестиций, отслеживание репутации бренда, слежение за отраслевыми новостями, получение полезной информации.

Веб-страница (отправка на почту)

Push в 飞书

Push с AI-анализом

Веб-страница

Push в 飞书

Push с AI-анализом

🚀 Быстрый старт

Напоминание: сначала рекомендуется посмотреть последнюю официальную документацию, чтобы убедиться, что шаги настройки актуальны.

Выберите подходящий способ развёртывания

Ⓐ Вариант 1: Docker (рекомендуется 🔥)

  • Особенности: стабильнее, чем GitHub Actions; данные хранятся локально (не нужна настройка облачного хранилища)

  • Для кого: у вас есть свой сервер, NAS или постоянно включённый компьютер

  • Важно: прочитайте и поймите базовую настройку ниже, затем перейдите к инструкции по Docker для развёртывания.

Ⓑ Вариант 2: GitHub Actions (этот раздел ⬇️)

  • Особенности: без своего сервера; данные хранятся в удалённом облачном хранилище (рекомендуемая конфигурация)

  • Для кого: пользователи без сервера, использующие бесплатные ресурсы GitHub

  • Важно: требуется настроить облачное хранилище для полного опыта и регулярно продлевать активность

Ⓒ Вариант 3: локальное развёртывание (uv)

  • Особенности: запуск прямо на своей машине без Docker; подходит для разработки, отладки или пользователей без Docker

  • Для кого: пользователи Windows / Mac / Linux (Python предустанавливать не нужно — uv всё сделает сам)

  • Шаги:

    1. Установите uv (если уже установлен, можно пропустить; Python предустанавливать не нужно)

    # macOS / Linux
    curl -LsSf https://astral.sh/uv/install.sh | sh
    
    # Windows (PowerShell)
    powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

    2. Клонируйте и запустите

    git clone https://github.com/sansan0/TrendRadar.git
    cd TrendRadar
    uv sync          # 自动安装 Python 和项目依赖
    uv run python -m trendradar

    💡 Подсказка:

    • uv сам управляет версией Python, устанавливать его вручную не нужно

    • Пользователи Windows также могут дважды щёлкнуть setup-windows.bat для установки зависимостей

    • Пользователи Mac могут использовать bash setup-mac.sh

    • Перед запуском отредактируйте config/config.yaml, указав каналы push и другие настройки, — см. базовую настройку ниже

1️⃣ Шаг 1: Получите код проекта

Нажмите зелёную кнопку [Use this template] в правом верхнем углу страницы репозитория → выберите «Create a new repository».

⚠️ Напоминание:

  • Все упоминания «Fork» в документации можно понимать как «Use this template»

  • Использование Fork может вызвать сбои в работе; подробнее см. Issue #606

2️⃣ Шаг 2: Настройте GitHub Secrets

В созданном из шаблона репозитории перейдите в Settings > Secrets and variables > Actions > New repository secret.

📌 Важные замечания (пожалуйста, прочитайте внимательно):

  • Одному Name соответствует один Secret: для каждого параметра нажимайте кнопку «New repository secret» и заполняйте пару «Name» и «Secret»

  • То, что значение не видно после сохранения, — нормально: из соображений безопасности при повторном редактировании виден только Name (имя), но не содержимое Secret (значение)

  • Запрещено придумывать свои имена: Name (имя) Secret должно строго соответствовать перечисленным ниже именам (например, WEWORK_WEBHOOK_URL, FEISHU_WEBHOOK_URL и т.д.). Нельзя произвольно менять или создавать новые имена, иначе система их не распознает

  • Можно настроить сразу несколько платформ: система отправит уведомления на все настроенные платформы

Пример настройки:

Как показано выше, каждая строка — один параметр:

  • Name (имя): используйте фиксированные имена из раскрывающегося списка ниже (например, WEWORK_WEBHOOK_URL)

  • Secret (значение): укажите реальные данные, полученные на соответствующей платформе (например, адрес Webhook, Token и т.п.)

Конфигурация GitHub Secret (⚠️ Name должно строго совпадать):

  • Name (имя): WEWORK_WEBHOOK_URL (скопируйте и вставьте это имя, не вводите вручную, чтобы не ошибиться)

  • Secret (значение): адрес Webhook вашего бота 企业微信

Шаги настройки бота:

Настройка на телефоне:

  1. Откройте приложение 企业微信 → войдите в нужную внутреннюю группу

  2. Нажмите кнопку «…» в правом верхнем углу → выберите «Push-уведомления»

  3. Нажмите «Добавить» → в поле имени введите «TrendRadar»

  4. Скопируйте адрес Webhook, нажмите «Сохранить» и вставьте скопированное значение в GitHub Secret выше

На компьютере процесс аналогичен

Так как этот способ основан на плагин-механизме 企业微信, push-сообщения имеют формат простого текста (без markdown), но доставляются напрямую в личный WeChat — устанавливать приложение 企业微信 не нужно.

Конфигурация GitHub Secret (⚠️ Name должно строго совпадать):

  • Name (имя): WEWORK_WEBHOOK_URL (скопируйте и вставьте это имя, не вводите вручную)

  • Secret (значение): адрес Webhook вашего приложения 企业微信

  • Name (имя): WEWORK_MSG_TYPE (скопируйте и вставьте это имя, не вводите вручную)

  • Secret (значение): text

Шаги настройки:

  1. Выполните настройку Webhook бота 企业微信, описанную выше

  2. Добавьте Secret WEWORK_MSG_TYPE, установите значение text

  3. Следуя картинке ниже, привяжите личный WeChat

  4. После настройки приложение 企业微信 на телефоне можно удалить

Примечания:

  • Используется тот же адрес Webhook, что и у бота 企业微信

  • Разница в формате сообщения: text — обычный текст, markdown — расширенное форматирование (по умолчанию)

  • В формате обычного текста автоматически удаляется весь markdown-синтаксис (жирный шрифт, ссылки и т.д.)

Внимание: прежний «飞书机器人助手 (BotBuilder)» будет отключён 30 июня 2026 года. Используйте способ групповой пользовательский бот ниже. Существующие webhook-адреса BotBuilder перестанут работать — их нужно настроить заново.

Если включён AI-анализ, push в 飞书 иногда (примерно в 5% случаев) задерживается на несколько минут (предположительно из-за проверки соответствия AI-контента на платформе).

Конфигурация GitHub Secret (⚠️ Name должно строго совпадать):

  • Name (имя): FEISHU_WEBHOOK_URL (скопируйте и вставьте это имя, не вводите вручную)

  • Secret (значение): адрес Webhook вашего пользовательского бота 飞书 (формат: https://open.feishu.cn/open-apis/bot/v2/hook/xxxxxxxxx)

Шаги настройки:

  1. Зайдите в нужную группу, в правом верхнем углу нажмите кнопку 更多 (Ещё), затем 设置 (Настройки).

Вход в настройки группы

  1. В панели 设置 (Настройки) справа нажмите 群机器人 (Бот группы).

Нажмите «Бот группы»

  1. В интерфейсе 群机器人 (Бот группы) нажмите 添加机器人 (Добавить бота).

  2. В диалоге 添加机器人 (Добавить бота) найдите и нажмите 自定义机器人 (Пользовательский бот).

Выбор пользовательского бота

  1. Задайте аватар, имя (например, «TrendRadar 热点监控») и описание пользовательского бота, нажмите 添加 (Добавить).

Настройка информации о боте

  1. Скопируйте webhook-адрес пользовательского бота и нажмите 完成 (Готово).

⚠️ Сохраняйте этот webhook-адрес в надёжном месте и не публикуйте его на GitHub, в блогах и других общедоступных сайтах — иначе после утечки адрес могут использовать для рассылки спама.

Копирование webhook-адреса

  1. Вставьте скопированный Webhook-адрес в GitHub Secret FEISHU_WEBHOOK_URL.

💡 После настройки вы можете нажать на изображение бота справа от названия группы, чтобы открыть страницу пользовательского бота и управлять конфигурацией.

📖 Официальная документация: Руководство по пользовательскому боту

Конфигурация GitHub Secret (⚠️ Name должно строго совпадать):

  • Name (имя): DINGTALK_WEBHOOK_URL (скопируйте и вставьте это имя, не вводите вручную)

  • Secret (значение): адрес Webhook вашего бота 钉钉

Шаги настройки бота:

  1. Создание бота (только в ПК-версии):

    • Откройте ПК-клиент 钉钉 и войдите в нужную группу

    • Нажмите значок настроек группы (⚙️) → прокрутите вниз, найдите «Бот» и откройте

    • Выберите «Добавить бота» → «Пользовательский»

  2. Настройка бота:

    • Задайте имя бота

    • Настройки безопасности:

      • Пользовательское ключевое слово: укажите «热点»

  3. Завершение настройки:

    • Отметьте соглашение с условиями обслуживания → нажмите «Готово»

    • Скопируйте полученный Webhook URL

    • Вставьте URL в GitHub Secret DINGTALK_WEBHOOK_URL

Примечание: в мобильной версии можно только получать сообщения; создать нового бота нельзя.

Конфигурация GitHub Secret (⚠️ Name должно строго совпадать):

  • Name (имя): TELEGRAM_BOT_TOKEN (скопируйте и вставьте это имя, не вводите вручную)

  • Secret (значение): ваш Telegram Bot Token

  • Name (имя): TELEGRAM_CHAT_ID (скопируйте и вставьте это имя, не вводите вручную)

  • Secret (значение): ваш Telegram Chat ID

Примечание: для Telegram нужно настроить два Secret. Нажмите кнопку «New repository secret» два раза, чтобы добавить их по отдельности.

Шаги настройки бота:

  1. Создание бота:

    • В Telegram найдите @BotFather (обратите внимание на регистр, наличие синей галочки и примерно 37849827 monthly users — это официальный аккаунт; остерегайтесь подделок)

    • Отправьте команду /newbot, чтобы создать нового бота

    • Задайте имя бота (должно заканчиваться на «bot»; имена часто заняты, так что придётся придумывать разные варианты)

    • Получите Bot Token (пример формата: 123456789:AAHfiqksKZ8WmR2zSjiQ7_v4TMAKdiHm9T0)

  2. Получите Chat ID:

    Способ 1: через официальный API

    • Сначала отправьте сообщение своему боту

    • Перейдите по ссылке: https://api.telegram.org/bot<你的Bot Token>/getUpdates

    • В полученном JSON найдите число в "chat":{"id":数字}

    Способ 2: через сторонний инструмент

    • Найдите @userinfobot и отправьте /start

    • Полученный User ID используйте как Chat ID

  3. Настройка на GitHub:

    • TELEGRAM_BOT_TOKEN: укажите Bot Token из шага 1

    • TELEGRAM_CHAT_ID: укажите Chat ID из шага 2

  • Обратите внимание: чтобы предотвратить злоупотребление рассылкой, в текущей версии все получатели видят адреса электронной почты друг друга

  • Если у вас нет опыта настройки отправки почты таким образом, не рекомендуется пробовать

⚠️ Важная зависимость конфигурации: для push по почте требуется файл HTML-отчёта. Убедитесь, что в config/config.yaml параметр storage.formats.html установлен в true:

storage:
  formats:
    sqlite: true
    txt: false
    html: true   # 必须启用,否则邮件推送会失败

Если установлено false, при отправке появится ошибка: 错误:HTML文件不存在或未提供: None

Конфигурация GitHub Secret (⚠️ Name должно строго совпадать):

  • Name (имя): EMAIL_FROM (скопируйте и вставьте это имя, не вводите вручную)

  • Secret (значение): адрес электронной почты отправителя

  • Name (имя): EMAIL_PASSWORD (скопируйте и вставьте это имя, не вводите вручную)

  • Secret (значение): пароль почты или код авторизации

  • Name (имя): EMAIL_TO (скопируйте и вставьте это имя, не вводите вручную)

  • Secret (значение): адрес электронной почты получателя (для нескольких получателей разделите адреса запятыми; можно указать тот же адрес, что и в EMAIL_FROM, чтобы отправить самому себе)

  • Name (имя): EMAIL_SMTP_SERVER (необязательный параметр, скопируйте и вставьте это имя)

  • Secret (значение): адрес SMTP-сервера (можно оставить пустым, система определит автоматически)

  • Name (имя): EMAIL_SMTP_PORT (необязательный параметр, скопируйте и вставьте это имя)

  • Secret (значение): порт SMTP (можно оставить пустым, система определит автоматически)

Примечание: для push по почте нужно указать как минимум 3 обязательных Secret (EMAIL_FROM, EMAIL_PASSWORD, EMAIL_TO); последние два являются необязательными.

Поддерживаемые почтовые сервисы (SMTP-конфигурация определяется автоматически):

Поставщик почты

Домен

SMTP-сервер

Порт

Шифрование

Gmail

gmail.com

smtp.gmail.com

587

TLS

QQ Почта

qq.com

smtp.qq.com

465

SSL

Outlook

outlook.com

smtp-mail.outlook.com

587

TLS

Hotmail

hotmail.com

smtp-mail.outlook.com

587

TLS

Live

live.com

smtp-mail.outlook.com

587

TLS

163 Почта

163.com

smtp.163.com

465

SSL

126 Почта

126.com

smtp.126.com

465

SSL

Sina Почта

sina.com

smtp.sina.com

465

SSL

Sohu Почта

sohu.com

smtp.sohu.com

465

SSL

Tianyi Почта

189.cn

smtp.189.cn

465

SSL

Alibaba Cloud Почта

aliyun.com

smtp.aliyun.com

465

TLS

Yandex Почта

yandex.com

smtp.yandex.com

465

TLS

iCloud Почта

icloud.com

smtp.mail.me.com

587

SSL

Автоматическое определение: при использовании указанных выше почтовых сервисов нет необходимости вручную настраивать EMAIL_SMTP_SERVER и EMAIL_SMTP_PORT — система определит их автоматически.

Обратная связь:

  • Если вы успешно протестировали работу с другим почтовым сервисом, сообщите об этом, открыв Issues, и я добавлю его в список поддержки

  • Если указанная выше конфигурация почты неверна или не работает, также откройте Issues с обратной связью, чтобы помочь улучшить проект

Особая благодарность:

  • Спасибо @DYZYD за добавление конфигурации Tianyi Почты (189.cn) и проведение теста отправки/получения (#291)

  • Спасибо @longzhenren за добавление конфигурации Alibaba Cloud Почты (aliyun.com) и проведение теста (#344)

  • Спасибо @ACANX за добавление конфигурации Yandex Почты (yandex.com) и проведение теста (#663)

  • Спасибо @Sleepy-Tianhao за добавление конфигурации iCloud Почты (icloud.com) и проведение теста (#728)

Настройка распространённых почтовых сервисов:

QQ Почта:

  1. Войдите в веб-версию QQ Почты → Настройки → Аккаунт

  2. Включите службу POP3/SMTP

  3. Сгенерируйте код авторизации (16-значный буквенный)

  4. В EMAIL_PASSWORD укажите код авторизации, а не пароль QQ

Gmail:

  1. Включите двухэтапную проверку

  2. Сгенерируйте пароль приложения

  3. В EMAIL_PASSWORD укажите пароль приложения

163/126 Почта:

  1. Войдите в веб-версию → Настройки → POP3/SMTP/IMAP

  2. Включите службу SMTP

  3. Установите код авторизации клиента

  4. В EMAIL_PASSWORD укажите код авторизации

Расширенная настройка: Если автоматическое определение не сработало, можно настроить SMTP вручную:

  • EMAIL_SMTP_SERVER: например, smtp.gmail.com

  • EMAIL_SMTP_PORT: например, 587 (TLS) или 465 (SSL)

Если несколько получателей (обратите внимание: разделяются запятыми на английском):

Два способа использования:

Способ 1: Бесплатное использование (рекомендуется новичкам) 🆓

Особенности:

  • ✅ Не требуется регистрация аккаунта, можно использовать сразу

  • ✅ 250 сообщений в день (достаточно для 90% пользователей)

  • ✅ Название Topic — это и есть «пароль» (нужно выбрать название, которое сложно угадать)

  • ⚠️ Сообщения не шифруются, не подходят для конфиденциальной информации, но подходят для неконфиденциальной информации этого проекта

Быстрый старт:

  1. Скачайте приложение ntfy:

  2. Подпишитесь на тему (выберите название, которое сложно угадать):

    建议格式:trendradar-{你的名字缩写}-{随机数字}
    
    不能使用中文
    
    ✅ 好例子:trendradar-zs-8492
    ❌ 坏例子:news、alerts(太容易被猜到)
  3. Настройте GitHub Secret (⚠️ Имя (Name) должно строго совпадать):

    • Name (Имя): NTFY_TOPIC (скопируйте и вставьте это имя, не вводите вручную)

    • Secret (Значение): укажите название темы, на которую вы подписались

    • Name (Имя): NTFY_SERVER_URL (необязательная настройка, скопируйте и вставьте это имя)

    • Secret (Значение): оставьте пустым (по умолчанию используется ntfy.sh)

    • Name (Имя): NTFY_TOKEN (необязательная настройка, скопируйте и вставьте это имя)

    • Secret (Значение): оставьте пустым

    Пояснение: для ntfy необходимо настроить как минимум 1 обязательный Secret (NTFY_TOPIC), остальные два — необязательные

  4. Тест:

    curl -d "测试消息" ntfy.sh/你的主题名称

Способ 2: Самостоятельный хостинг (полный контроль над конфиденциальностью) 🔒

Для кого: у кого есть сервер, кто стремится к полной конфиденциальности, обладает техническими навыками

Преимущества:

  • ✅ Полностью открытый исходный код (Apache 2.0 + GPLv2)

  • ✅ Полный контроль над данными

  • ✅ Без каких-либо ограничений

  • ✅ Нулевая стоимость

Развёртывание одной командой через Docker:

docker run -d \
  --name ntfy \
  -p 80:80 \
  -v /var/cache/ntfy:/var/cache/ntfy \
  binwiederhier/ntfy \
  serve --cache-file /var/cache/ntfy/cache.db

Настройка TrendRadar:

NTFY_SERVER_URL: https://ntfy.yourdomain.com
NTFY_TOPIC: trendradar-alerts  # 自托管可用简单名称
NTFY_TOKEN: tk_your_token  # 可选:启用访问控制

Подписка в приложении:

  • Нажмите «Use another server»

  • Введите адрес вашего сервера

  • Введите название темы

  • (Необязательно) введите учётные данные для входа


Часто задаваемые вопросы:

250 сообщений в день достаточно для большинства пользователей. При сборе данных каждые 30 минут это около 48 push-уведомлений в день — вполне достаточно.

Если вы выберете случайное, достаточно длинное название (например, trendradar-zs-8492-news), перебор практически невозможен:

  • У ntfy строгие ограничения скорости (1 запрос в секунду)

  • 64 символа на выбор (A-Z, a-z, 0-9, _, -)

  • 10-значная случайная строка имеет 64^10 возможных комбинаций (потребуются годы для взлома)


Рекомендации по выбору:

Тип пользователя

Рекомендуемый способ

Причина

Обычный пользователь

Способ 1 (бесплатный)

Просто и быстро, достаточно

Технический пользователь

Способ 2 (самостоятельный хостинг)

Полный контроль, без ограничений

Пользователь с высокой частотой

Способ 3 (платный)

Посмотрите на официальном сайте сами

Полезные ссылки:

Настройка GitHub Secret (⚠️ Имя (Name) должно строго совпадать):

  • Name (Имя): BARK_URL (скопируйте и вставьте это имя, не вводите вручную)

  • Secret (Значение): URL вашего Bark push-уведомления

О Bark:

Bark — это бесплатный инструмент push-уведомлений с открытым исходным кодом для платформы iOS, отличающийся простотой, скоростью и отсутствием рекламы.

Способы использования:

Способ 1: Использование официального сервера (рекомендуется новичкам) 🆓

  1. Скачайте приложение Bark:

  2. Получите push-URL:

    • Откройте приложение Bark

    • Скопируйте push-URL, отображаемый на главной странице (формат: https://api.day.app/your_device_key)

    • Настройте URL в GitHub Secrets в поле BARK_URL

Способ 2: Собственный сервер (полный контроль над конфиденциальностью) 🔒

Для кого: у кого есть сервер, кто стремится к полной конфиденциальности, обладает техническими навыками

Развёртывание одной командой через Docker:

docker run -d \
  --name bark-server \
  -p 8080:8080 \
  finab/bark-server

Настройка TrendRadar:

BARK_URL: http://your-server-ip:8080/your_device_key

Примечания:

  • ✅ Bark использует push-уведомления APNs, максимальный размер одного сообщения — 4 КБ

  • ✅ Поддерживается автоматическая отправка по частям, не нужно беспокоиться о слишком длинных сообщениях

  • ✅ Формат push-уведомлений — обычный текст (синтаксис Markdown автоматически удаляется)

  • ⚠️ Поддерживается только платформа iOS

Полезные ссылки:

Настройка GitHub Secret (⚠️ Имя (Name) должно строго совпадать):

  • Name (Имя): SLACK_WEBHOOK_URL (скопируйте и вставьте это имя, не вводите вручную)

  • Secret (Значение): URL вашего Slack Incoming Webhook

О Slack:

Slack — это инструмент для командной работы. Incoming Webhooks позволяет отправлять сообщения в каналы Slack.

Шаги настройки:

Шаг 1: Создание приложения Slack

  1. Перейдите на страницу Slack API:

    • Откройте https://api.slack.com/apps?new_app=1

    • Если вы не вошли в систему, сначала войдите в своё рабочее пространство Slack

  2. Выберите способ создания:

    • Нажмите «From scratch» (создать с нуля)

  3. Заполните информацию о приложении:

    • App Name: укажите название приложения (например, TrendRadar или Мониторинг горячих новостей)

    • Workspace: выберите своё рабочее пространство из выпадающего списка

    • Нажмите кнопку «Create App»

Шаг 2: Включение Incoming Webhooks

  1. Перейдите к Incoming Webhooks:

    • В левом меню найдите и нажмите «Incoming Webhooks»

  2. Включите функцию:

    • Найдите переключатель «Activate Incoming Webhooks»

    • Переключите его с OFF на ON

    • Страница автоматически обновится и отобразит новые параметры конфигурации

Шаг 3: Создание URL Webhook

  1. Добавьте новый Webhook:

    • Прокрутите страницу вниз

    • Нажмите кнопку «Add New Webhook to Workspace»

  2. Выберите целевой канал:

    • Система отобразит страницу авторизации

    • Выберите канал для получения сообщений из выпадающего списка (например, #горячие_новости)

    • ⚠️ Чтобы выбрать приватный канал, сначала необходимо вступить в него

  3. Авторизуйте приложение:

    • Нажмите кнопку «Allow» для завершения авторизации

    • Система автоматически вернёт вас на страницу конфигурации

Шаг 4: Скопируйте и сохраните URL Webhook

  1. Просмотрите сгенерированный URL:

    • В области «Webhook URLs for Your Workspace»

    • Вы увидите только что созданный URL Webhook

    • Формат: https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX

  2. Скопируйте URL:

    • Нажмите кнопку «Copy» справа от URL

    • Или вручную выделите и скопируйте URL

  3. Настройте в TrendRadar:

    • GitHub Actions: добавьте URL в GitHub Secrets в поле SLACK_WEBHOOK_URL

    • Локальное тестирование: укажите URL в поле slack_webhook_url файла config/config.yaml

    • Развёртывание через Docker: добавьте URL в переменную SLACK_WEBHOOK_URL файла docker/.env


Примечания:

  • ✅ Поддерживается формат Markdown (автоматически преобразуется в Slack mrkdwn)

  • ✅ Поддерживается автоматическая отправка по частям (по 4 КБ за раз)

  • ✅ Подходит для командной работы, централизованное управление сообщениями

  • ⚠️ URL Webhook содержит секретный ключ, никогда не публикуйте его

Предпросмотр формата сообщения:

*[第 1/2 批次]*

📊 *热点词汇统计*

🔥 *[1/3] AI ChatGPT* : 2 条

  1. [百度热搜] 🆕 ChatGPT-5正式发布 *[1]* - 09时15分 (1次)

  2. [今日头条] AI芯片概念股暴涨 *[3]* - [08时30分 ~ 10时45分] (3次)

Полезные ссылки:

Настройка GitHub Secret (⚠️ Имя (Name) должно строго совпадать):

  • Name (Имя): GENERIC_WEBHOOK_URL (скопируйте и вставьте это имя, не вводите вручную)

  • Secret (Значение): URL вашего Webhook

  • Name (Имя): GENERIC_WEBHOOK_TEMPLATE (необязательная настройка, скопируйте и вставьте это имя)

  • Secret (Значение): строка JSON-шаблона, поддерживаются плейсхолдеры {title} и {content}

Об универсальных Webhook:

Универсальные Webhook поддерживают любые платформы, принимающие HTTP POST-запросы, включая, но не ограничиваясь:

  • Discord: отправка в канал через Webhook

  • Matrix: отправка через Webhook-мост

  • IFTTT: запуск автоматизированных процессов

  • Собственные сервисы: любые пользовательские сервисы, поддерживающие Webhook

Примеры конфигурации:

Настройка Discord

  1. Получите URL Webhook:

    • Перейдите в настройки сервера Discord → Интеграции → Webhooks

    • Создайте новый Webhook, скопируйте URL

  2. Настройте шаблон:

    {"content": "{content}"}
  3. Настройка GitHub Secret:

    • GENERIC_WEBHOOK_URL: URL Webhook Discord

    • GENERIC_WEBHOOK_TEMPLATE: {"content": "{content}"}

Пользовательский шаблон

Шаблон поддерживает два плейсхолдера:

  • {title} — заголовок сообщения

  • {content} — содержимое сообщения

Пример шаблона:

# 默认格式(留空时使用)
{"title": "{title}", "content": "{content}"}

# Discord 格式
{"content": "{content}"}

# 自定义格式
{"text": "{content}", "username": "TrendRadar"}

Примечания:

  • ✅ Поддерживается формат Markdown (совместим с форматом WeCom)

  • ✅ Поддерживается автоматическая отправка по частям

  • ✅ Поддерживается настройка нескольких аккаунтов (разделяются символом ;)

  • ⚠️ Шаблон должен быть в корректном формате JSON

  • ⚠️ Разные платформы предъявляют разные требования к формату сообщений, обратитесь к документации целевой платформы

3️⃣ Шаг 3: Ручное тестирование push-уведомлений о новостях

⚠️ Напоминание:

  • После выполнения шагов 1–2 немедленно проведите тест! После успешного теста при необходимости настройте конфигурацию (шаг 4)

  • Зайдите в свой собственный проект, а не в этот проект!

Как найти свою страницу Actions:

  • Способ 1: откройте главную страницу вашего форкнутого проекта и нажмите вкладку Actions вверху

  • Способ 2: перейдите напрямую по адресу https://github.com/ваше_имя_пользователя/TrendRadar/actions

Пример для сравнения:

  • ❌ Проект автора: https://github.com/sansan0/TrendRadar/actions

  • ✅ Ваш проект: https://github.com/ваше_имя_пользователя/TrendRadar/actions

Шаги тестирования:

  1. Перейдите на страницу Actions вашего проекта

  2. Найдите «Get Hot News» (должно быть именно это название), нажмите на него, затем нажмите кнопку «Run workflow» справа для запуска

    • Если вы не видите эту надпись, решите проблему согласно #109

  3. Примерно через 3 минуты сообщение будет отправлено на настроенную вами платформу

⚠️ Напоминание:

  • Не запускайте ручное тестирование слишком часто, чтобы не сработали ограничения GitHub Actions

  • После нажатия Run workflow необходимо обновить страницу браузера, чтобы увидеть новую запись о запуске

4️⃣ Шаг 4: Пояснения к конфигурации (необязательно)

Конфигурация по умолчанию уже работает корректно. Если требуется индивидуальная настройка, достаточно разобраться со следующими файлами:

Файл

Назначение

config/config.yaml

Основной файл конфигурации: режим push-уведомлений, временное окно, список платформ, веса горячих тем и т.д.

config/frequency_words.txt

Файл ключевых слов: укажите интересующие вас слова для фильтрации содержимого push-уведомлений

config/ai_analysis_prompt.txt

Шаблон AI-подсказки: настройка роли и аналитических параметров AI-аналитика

.github/workflows/crawler.yml

Частота выполнения: контроль периодичности запуска (⚠️ изменять с осторожностью)

👉 Подробное руководство по настройке: Подробное описание конфигурации

5️⃣ Шаг 5: Удалённое облачное хранилище и настройка регистрации

Важное изменение в v4.0.0: введён механизм «детекции активности» — GitHub Actions требует периодической регистрации для продолжения работы.

  • Период работы: срок действия — 7 дней, после окончания обратного отсчёта сервис автоматически приостанавливается.

  • Способ продления: вручную запустите workflow «Check In» на странице Actions, чтобы сбросить 7-дневный срок действия.

  • Путь действий: Actions → Check In → Run workflow

  • Концепция дизайна:

    • Если вы забыли зарегистрироваться за 7 дней, возможно, эта информация не является для вас критически важной. Своевременная пауза поможет вам отвлечься от информационного потока и дать мозгу передышку.

    • GitHub Actions — это ценный общедоступный вычислительный ресурс. Введение механизма регистрации направлено на предотвращение неэффективного простоя вычислительных мощностей и обеспечение распределения ресурсов действительно активным и нуждающимся пользователям. Благодарим за понимание и поддержку.


О настройке удалённого облачного хранилища (выберите в зависимости от способа развёртывания):

  • Пользователи GitHub Actions:

    • Текущее состояние: Actions при каждом запуске использует новое окружение, файлы не сохраняются. Если не настроить облачное хранилище, проект будет работать в облегчённом режиме (без инкрементальных push-уведомлений, без отслеживания истории).

    • Рекомендация: настройте удалённое облачное хранилище для получения полного опыта.

  • Пользователи Docker / локального развёртывания:

    • Текущее состояние: данные по умолчанию сохраняются на локальном жёстком диске.

    • Рекомендация: облачное хранилище необязательно, может использоваться как резервная копия на другом сервере.

⚠️ Предварительные условия (важно):

Согласно правилам платформы Cloudflare, для активации R2 необходимо привязать платёжный метод.

  • Цель: только для проверки личности (Verify Only), списания средств не происходит.

  • Оплата: поддерживаются карты с двумя валютами или PayPal для Китая.

  • Использование: бесплатного лимита R2 (10 ГБ хранилища/месяц) достаточно для повседневной работы этого проекта, о платной версии можно не беспокоиться.


Настройка GitHub Secret (необходимо добавить 4 пункта):

Name (Имя)

Описание Secret (Значения)

S3_BUCKET_NAME

Название корзины (например, trendradar-data)

S3_ACCESS_KEY_ID

Идентификатор ключа доступа (Access Key ID)

S3_SECRET_ACCESS_KEY

Секретный ключ доступа (Secret Access Key)

S3_ENDPOINT_URL

Конечная точка S3 API (например, для R2: https://<account-id>.r2.cloudflarestorage.com)

Необязательная настройка:

Name (Имя)

Описание Secret (Значения)

S3_REGION

Регион (по умолчанию auto, некоторые провайдеры могут требовать указания)

💡 Дополнительные варианты настройки хранилища: см. Где хранятся данные?

Подробные шаги (получение учётных данных):

  1. Перейдите в обзор R2:

    • Войдите в Cloudflare Dashboard.

    • В левой боковой панели найдите и нажмите R2 объектное хранилище.

  2. Создайте корзину:

    • Нажмите Обзор

    • Нажмите Создать корзину (Create bucket) в правом верхнем углу.

    • Введите название (например, trendradar-data), нажмите Создать корзину.

  3. Создайте API-токен:

    • Вернитесь на страницу Обзор.

    • В правом нижнем углу нажмите Account Details, найдите и нажмите Manage (Manage R2 API Tokens).

    • Также вы увидите S3 API: https://<account-id>.r2.cloudflarestorage.com (это и есть S3_ENDPOINT_URL)

    • Нажмите Создать токен Account API.

    • ⚠️ Ключевые настройки:

      • Имя токена: укажите произвольное имя (например, github-action-write).

      • Права доступа: выберите Администратор: чтение и запись.

      • Указание корзины: для безопасности рекомендуется выбрать Только для указанной корзины и выбрать вашу корзину (например, trendradar-data).

    • Нажмите Создать API-токен, немедленно скопируйте отображаемые Access Key ID и Secret Access Key (отображаются только один раз!).

6️⃣ Шаг 6: Включение AI-аналитики в push-уведомлениях

Это ключевая функция v5.0.0 — AI поможет вам обобщать и анализировать новости, рекомендуем попробовать.

Способ настройки: Добавьте в GitHub Secrets (или .env / config.yaml):

  • AI_API_KEY: ваш API-ключ (поддерживаются DeepSeek, OpenAI и др.)

  • AI_PROVIDER: название провайдера (например, deepseek, openai)

Всё, сложное развёртывание не требуется — при следующем push-уведомлении вы увидите интеллектуальный аналитический отчёт.

7️⃣ Шаг 7: 🎉 Развёртывание успешно!

Поздравляем! Теперь вы можете наслаждаться эффективным информационным потоком TrendRadar.

💬 Присоединяйтесь к сообществу: Подпишитесь на официальный аккаунт «硅基茶水间», делитесь своим опытом использования и продвинутыми приёмами.

8️⃣ Шаг восьмой: Продвинутый уровень: выберите своего AI-ассистента

TrendRadar предлагает два способа использования ИИ, удовлетворяющих разные потребности:

Характеристика

✨ AI-анализ и рассылка

🧠 AI-интеллектуальный анализ

Режим

Пассивное получение (ежедневный дайджест)

Активный диалог (глубокое исследование)

Сценарий

«Что сегодня важного?»

«Проанализируй изменения в ИИ-индустрии за неделю»

Развёртывание

Минимальное (достаточно ввести Key)

Продвинутое (требуется локальный запуск/Docker)

Клиент

Телефон

Компьютер

👉 Вывод: Сначала используйте AI-анализ и рассылку для повседневных нужд; если вы аналитик данных или вам нужно глубокое исследование, попробуйте AI-интеллектуальный анализ.

⚙️ Подробная настройка

📖 Напоминание: В этом разделе приведены подробные инструкции по настройке. Рекомендуется сначала выполнить базовую настройку из Быстрый старт, а затем при необходимости вернуться к подробным параметрам.

1. Какие платформы я хочу отслеживать?

Место настройки: раздел platforms в config/config.yaml

Данные об источниках новостей в этом проекте получены из newsnow. Вы можете перейти на сайт, нажать [Ещё], и посмотреть, есть ли нужная вам платформа.

Конкретные добавления можно посмотреть в исходном коде проекта. В соответствии с именами файлов измените конфигурацию platforms в файле config/config.yaml:

platforms:
  enabled: true                       # 是否启用热榜平台抓取
  sources:
    - id: "toutiao"
      name: "今日头条"
    - id: "baidu"
      name: "百度热搜"
    - id: "wallstreetcn-hot"
      name: "华尔街见闻"
    # 添加更多平台...

💡 Быстрый способ: Если вы не умеете читать исходный код, можно скопировать готовую сводку конфигураций платформ

⚠️ Внимание: Чем больше платформ, тем не всегда лучше. Рекомендуется выбрать 10-15 ключевых платформ. Слишком большое количество платформ приведёт к информационной перегрузке и снизит удобство использования.

2. Что меня интересует?

В файле frequency_words.txt сообщите боту, что вы хотите видеть, и он будет следить за этим. Поддерживаются обычные слова, обязательные слова, слова-фильтры и другие возможности.

Тип синтаксиса

Символ

Назначение

Пример

Логика сопоставления

Обычное слово

нет

Базовое сопоставление

华为

Достаточно любого из них

Обязательное слово

+

Ограничение области

+手机

Должно содержать одновременно

Слово-фильтр

!

Исключение помех

!广告

Исключается при наличии

Ограничение количества

@

Управление количеством отображаемых

@10

Максимум 10 новостей (новое в v3.2.0)

Глобальный фильтр

[GLOBAL_FILTER]

Глобальное исключение указанного содержимого

см. пример ниже

Фильтруется в любом случае (новое в v3.5.0)

Регулярное выражение

/pattern/

Точное сопоставление с шаблоном

/\bai\b/

Сопоставление с помощью регулярного выражения (новое в v4.7.0)

Отображаемое имя

=> 备注

Пользовательский отображаемый текст

/\bai\b/ => AI相关

Отображение имени в рассылке и HTML (новое в v4.7.0)

2.1 Базовый синтаксис

Место настройки: config/frequency_words.txt

1. Обычные ключевые слова - базовое сопоставление
华为
OPPO
苹果

Назначение: Новость будет захвачена, если заголовок содержит любое одно из этих слов

2. Обязательные слова +слово — ограничение диапазона
华为
OPPO
+手机

Назначение: Новость будет захвачена только если она содержит одновременно обычное слово и обязательное слово

3. Слова-фильтры !слово — исключение помех
苹果
华为
!水果
!价格

Назначение: Новости, содержащие слова-фильтры, будут исключены напрямую, даже если они содержат ключевые слова

4. Ограничение количества @число — управление количеством отображаемых (новое в v3.2.0)
特斯拉
马斯克
@5

Назначение: Ограничение максимального количества отображаемых новостей для этой группы ключевых слов

Приоритет настройки: @число > глобальная конфигурация > без ограничений

5. Глобальный фильтр [GLOBAL_FILTER] — глобальное исключение указанного содержимого (новое в v3.5.0)
[GLOBAL_FILTER]
广告
推广
营销
震惊
标题党

[WORD_GROUPS]
科技
AI

华为
鸿蒙
!车

Назначение: Фильтрует новости, содержащие указанные слова, в любом случае, имеет наивысший приоритет

Сценарии использования:

  • Фильтрация низкокачественного контента: сенсации, кликбейт, разоблачения и т.д.

  • Фильтрация маркетингового контента: реклама, продвижение, спонсорство и т.д.

  • Фильтрация конкретных тем: развлечения, сплетни (по необходимости)

Приоритет фильтрации: Глобальный фильтр > Фильтр внутри группы (!) > Сопоставление группы

Описание областей:

  • [GLOBAL_FILTER]: Область глобального фильтра. Слова, включённые в неё, фильтруются в любом случае.

  • [WORD_GROUPS]: Область групп слов, сохраняет существующий синтаксис (!, +, @).

  • Если не использовать маркеры областей, по умолчанию всё обрабатывается как группы слов (обратная совместимость).

Примеры сопоставления:

[GLOBAL_FILTER]
广告

[WORD_GROUPS]
科技
AI
  • ❌ «Реклама: выпуск новейшего технологического продукта» ← содержит глобальное слово-фильтр «реклама», отклонено напрямую

  • ✅ «Технологическая компания выпускает новый ИИ-продукт» ← не содержит глобальных слов-фильтров, сопоставлено с группой «технологии»

  • ✅ «Прорыв в области ИИ привлёк внимание» ← не содержит глобальных слов-фильтров, сопоставлено с «ИИ» в группе «технологии»

Примечания:

  • Глобальные слова-фильтры следует использовать осторожно, чтобы избежать чрезмерной фильтрации и пропуска ценного контента.

  • Рекомендуется ограничить количество глобальных слов-фильтров до 5-15.

  • Для фильтрации конкретных групп слов предпочтительно использовать слова-фильтры внутри группы (префикс !).

6. Регулярные выражения /pattern/ — точное сопоставление с шаблоном (новое в v4.7.0)

Обычные ключевые слова используют сопоставление подстрок, что удобно в китайской среде, но в английской среде может привести к ложным совпадениям. Например, ai будет сопоставлено с ai в training.

Использование синтаксиса регулярных выражений /pattern/ позволяет добиться точного сопоставления:

/(?<![a-z])ai(?![a-z])/
人工智能

Назначение: Сопоставление с помощью регулярных выражений, поддерживается весь синтаксис Python-регулярных выражений

Часто используемые шаблоны регулярных выражений:

Потребность

Написание регулярного выражения

Пояснение

Граница английского слова

/\bword\b/

Сопоставление отдельного слова, например /\bai\b/ сопоставляет «AI», но не «training»

Не буква до и после

/(?<![a-z])ai(?![a-z])/

Более свободная граница, подходит для смешанных китайско-английских сценариев

Сопоставление с начала

/^breaking/

Сопоставление только заголовков, начинающихся с «breaking»

Сопоставление с конца

/发布$/

Сопоставление только заголовков, заканчивающихся на «发布»

Выбор одного из нескольких

/苹果|华为|小米/

Сопоставление любого из них (обратите внимание на экранирование |)

Примеры сопоставления:

# 配置
/(?<![a-z])ai(?![a-z])/
人工智能
  • ✅ «AI is the future» ← сопоставление отдельного «AI»

  • ✅ «你好ai这里» ← с китайскими символами до и после, сопоставление «ai»

  • ✅ «人工智能发展迅速» ← сопоставление «人工智能»

  • ❌ «Resistance training is important» ← «ai» в «training» не сопоставляется

  • ❌ «The maid cleaned the room» ← «ai» в «maid» не сопоставляется

Комбинированное использование:

# 正则 + 普通词 + 过滤词
/\bai\b/
人工智能
机器学习
!广告

Примечания:

  • Регулярные выражения автоматически включают сопоставление без учёта регистра (re.IGNORECASE)

  • Поддерживается JavaScript-стиль записи /pattern/i (флаги игнорируются, так как по умолчанию уже включено игнорирование регистра)

  • Неверный синтаксис регулярного выражения обрабатывается как обычное слово

  • Регулярные выражения можно использовать для обычных слов, обязательных слов (+), слов-фильтров (!)

💡 Не умеете писать регулярные выражения? Пусть ИИ сгенерирует их за вас!

Если вы не знакомы с регулярными выражениями, вы можете попросить ChatGPT / Gemini / DeepSeek сгенерировать их. Просто скажите ИИ:

Мне нужно Python-регулярное выражение для сопоставления английского слова «ai», но не «ai» в «training». Пожалуйста, дайте просто регулярное выражение в формате /pattern/, без дополнительных объяснений.

ИИ даст вам что-то вроде: /(?<![a-zA-Z])ai(?![a-zA-Z])/

7. Отображаемое имя => 备注 — пользовательский отображаемый текст (новое в v4.7.0)

Регулярные выражения могут быть не очень удобны при отображении в push-сообщениях и HTML-страницах. Используйте синтаксис => 备注 для установки отображаемого имени:

/(?<![a-zA-Z])ai(?![a-zA-Z])/ => AI 相关
人工智能

Назначение: В push-сообщениях и HTML-страницах отображается «AI 相关» вместо сложного регулярного выражения

Синтаксический формат:

# 正则 + 显示名称
/pattern/ => 显示名称
/pattern/i => 显示名称    # 支持 flags 写法(flags 被忽略)
/pattern/=>显示名称       # => 两边空格可选

# 普通词 + 显示名称
deepseek => DeepSeek 动态

Примеры сопоставления:

# 配置
/(?<![a-zA-Z])ai(?![a-zA-Z])/ => AI 相关
人工智能

Исходная конфигурация

Отображение в push/HTML

/(?<![a-z])ai(?![a-z])/ + 人工智能

(?<![a-z])ai(?![a-z]) 人工智能

/(?<![a-z])ai(?![a-z])/ => AI 相关 + 人工智能

AI 相关

Примечания:

  • Отображаемое имя нужно писать только на первом слове группы.

  • Если несколько слов в группе имеют отображаемые имена, используется первое.

  • Если отображаемое имя не задано, автоматически используется объединение всех слов в группе.


🔗 Функция групп слов — важная роль разделения пустыми строками

Основное правило: разделяйте разные группы слов пустыми строками, каждая группа считается независимо

Пример конфигурации:
iPhone
华为
OPPO
+发布

A股
上证
深证
+涨跌
!预测

世界杯
欧洲杯
亚洲杯
+比赛
Пояснение групп и эффект сопоставления:

Группа 1 — Новые категории телефонов:

  • Ключевые слова: iPhone、华为、OPPO

  • Обязательное слово: 发布

  • Эффект: должно содержать название бренда телефона и одновременно «发布»

Примеры сопоставления:

  • ✅ «iPhone 15正式发布售价公布» ← есть «iPhone» + «发布»

  • ✅ «华为Mate60系列发布会直播» ← есть «华为» + «发布»

  • ✅ «OPPO Find X7发布时间确定» ← есть «OPPO» + «发布»

  • ❌ «iPhone销量创新高» ← есть «iPhone», но нет «发布»

Группа 2 - Фондовый рынок:

  • Ключевые слова: A股、上证、深证

  • Обязательное слово: 涨跌

  • Слово-фильтр: 预测

  • Эффект: следить за реальной ситуацией на фондовом рынке, исключая прогнозный контент

Примеры сопоставления:

  • ✅ «A股今日大幅涨跌分析» ← есть «A股» + «涨跌»

  • ✅ «上证指数涨跌幅创新高» ← есть «上证» + «涨跌»

  • ❌ «专家预测A股涨跌趋势» ← есть «A股» + «涨跌», но содержит «预测»

Группа 3 - Футбольные турниры:

  • Ключевые слова: 世界杯、欧洲杯、亚洲杯

  • Обязательное слово: 比赛

  • Эффект: следить только за новостями о матчах


📝 Советы по настройке

1. От широкого к строгому
# 第一步:先用宽泛关键词测试
人工智能
AI
ChatGPT

# 第二步:发现误匹配后,加入必须词限定
人工智能
AI
ChatGPT
+技术

# 第三步:发现干扰内容后,加入过滤词
人工智能
AI
ChatGPT
+技术
!广告
!培训
2. Избегайте чрезмерной сложности

❌ Не рекомендуется: одна группа содержит слишком много слов

华为
OPPO
苹果
三星
vivo
一加
魅族
+手机
+发布
+销量
!假货
!维修
!二手

✅ Рекомендуется: разбейте на несколько точных групп

华为
OPPO
+新品

苹果
三星
+发布

手机
销量
+市场

2.2 Расширенная конфигурация (новое в v3.2.0)

Приоритет сортировки ключевых слов

Место настройки: config/config.yaml

report:
  sort_by_position_first: false  # 排序优先级配置

Значение конфигурации

Правило сортировки

Сценарий применения

false (по умолчанию)

Количество горячих ↓ → Позиция в конфигурации ↑

Следить за трендом популярности

true

Позиция в конфигурации ↑ → Количество горячих ↓

Следить за личным приоритетом

Пример: Порядок конфигурации A, B, C, количество горячих A(3), B(10), C(5)

  • false: B(10) → C(5) → A(3)

  • true: A(3) → B(10) → C(5)

Глобальное ограничение количества отображаемых
report:
  max_news_per_keyword: 10  # 每个关键词最多显示10条(0=不限制)

Переменные окружения Docker:

SORT_BY_POSITION_FIRST=true
MAX_NEWS_PER_KEYWORD=10

Комплексный пример:

# config.yaml
report:
  sort_by_position_first: true   # 按配置顺序优先
  max_news_per_keyword: 10       # 全局默认每个关键词最多10条
# frequency_words.txt
特斯拉
马斯克
@20              # 重点关注,显示20条(覆盖全局配置)

华为            # 使用全局配置,显示10条

比亚迪
@5               # 限制5条

Конечный эффект: Отображение в порядке конфигурации: 特斯拉(20) → 华为(10) → 比亚迪(5)

3. Какой режим рассылки выбрать?

Место настройки: report.mode в config/config.yaml

report:
  mode: "daily"  # 可选: "daily" | "incremental" | "current"

Таблица подробного сравнения

Режим

Целевая аудитория

Время рассылки

Отображаемое содержимое

Типичный сценарий использования

Дневная сводкаdaily

📋 Руководители/обычные пользователи

По расписанию (по умолчанию каждый час)

Все сопоставленные новости за день+ Область новых новостей

Пример: Просмотр всех важных новостей сегодня в 18:00Особенность: Полный тренд за день, не пропустите ни одного горячего событияНапоминание: Будут включены ранее отправленные новости

Текущий рейтингcurrent

📰 Блогеры/создатели контента

По расписанию (по умолчанию каждый час)

Новости, сопоставленные с текущим рейтингом+ Область новых новостей

Пример: Отслеживание «какие темы сейчас самые горячие» каждый часОсобенность: В реальном времени видно изменение рейтинга популярностиНапоминание: Постоянно находящиеся в рейтинге новости будут появляться каждый раз

Инкрементальный мониторингincremental

📈 Инвесторы/трейдеры

Только при появлении новых

Новые новости, сопоставленные с частотными словами

Пример: Мониторинг «特斯拉», уведомление только при новых сообщенияхОсобенность: Ноль повторов, только впервые появившиеся новостиПодходит: Высокочастотный мониторинг, избегание информационного шума

Пример фактического эффекта рассылки

Предположим, вы отслеживаете ключевое слово «苹果», выполнение каждый час:

Время

daily режим

current режим

incremental режим

10:00

Новость A, Новость B

Новость A, Новость B

Новость A, Новость B

11:00

Новость A, Новость B, Новость C

Новость B, Новость C, Новость D

Только Новость C

12:00

Новость A, Новость B, Новость C

Новость C, Новость D, Новость E

Только Новость D, Новость E

Пояснение:

  • daily: Накопительное отображение всех новостей за день (A, B, C сохраняются)

  • current: Отображение новостей текущего рейтинга (изменение рейтинга, новость D попала в рейтинг, новость A выпала)

  • incremental: Отправка только новых новостей (избегание повторных помех)

Часто задаваемые вопросы

💡 Столкнулись с этой проблемой? 👉 «Выполняется каждый час, новости, выведенные при первом выполнении, появятся снова при следующем выполнении»

  • Причина: Возможно, вы выбрали режим daily (дневная сводка) или current (текущий рейтинг)

  • Решение: Переключитесь на режим incremental (инкрементальный мониторинг), который отправляет только новый контент

⚠️ Важное примечание для инкрементального режима

Пользователи, выбравшие режим incremental (инкрементальный мониторинг), обратите внимание:

📌 Инкрементальный режим отправляет только при появлении новых сопоставленных новостей

Если вы долго не получаете рассылок, это может быть потому, что:

  1. В текущий период нет новых горячих событий, соответствующих вашим ключевым словам

  2. Конфигурация ключевых слов слишком строгая или слишком широкая

  3. Количество отслеживаемых платформ невелико

Решения:

4. Настройка алгоритма горячих тем

Место настройки: раздел advanced.weight в config/config.yaml

advanced:
  weight:
    rank: 0.6           # 排名权重
    frequency: 0.3      # 频次权重
    hotness: 0.1        # 热度权重

Текущая конфигурация по умолчанию является сбалансированной

Два ключевых сценария

Сценарий «следить за реальным временем»:

advanced:
  weight:
    rank: 0.8           # 主要看排名
    frequency: 0.1      # 不太在乎持续性
    hotness: 0.1

Целевая аудитория: Блогеры, маркетологи, пользователи, желающие быстро узнать самые горячие темы

Сценарий «следить за глубокими темами»:

advanced:
  weight:
    rank: 0.4           # 适度看排名
    frequency: 0.5      # 重视当天内的持续热度
    hotness: 0.1

Целевая аудитория: Инвесторы, исследователи, журналисты, пользователи, нуждающиеся в глубоком анализе трендов

Метод настройки

  1. Сумма трёх чисел должна быть равна 1.0

  2. Что важнее, то и увеличивайте: если важен рейтинг, увеличьте rank; если важна устойчивость, увеличьте frequency

  3. Рекомендуется изменять только на 0.1-0.2 за раз, наблюдайте за эффектом

Основная идея: пользователи, стремящиеся к скорости и актуальности, увеличивают вес рейтинга; пользователи, стремящиеся к глубине и стабильности, увеличивают вес частоты.

5. Как выглядят мои сообщения?

Пример рассылки

📊 Статистика горячих слов

🔥 [1/3] AI ChatGPT : 2 новости

  1. [百度热搜] 🆕 ChatGPT-5正式发布 [1] - 09时15分 (1 раз)

  2. [今日头条] AI芯片概念股暴涨 [3] - [08时30分 ~ 10时45分] (3 раза)

━━━━━━━━━━━━━━━━━━━

📈 [2/3] 比亚迪 特斯拉: 2 новости

  1. [微博] 🆕 比亚迪月销量破纪录 [2] - 10时20分 (1 раз)

  2. [抖音] 特斯拉降价促销 [4] - [07时45分 ~ 09时15分] (2 раза)

━━━━━━━━━━━━━━━━━━━

📌 [3/3] A股 股市: 1 новость

  1. [华尔街见闻] A股午盘点评分析 [5] - [11时30分 ~ 12时00分] (2 раза)

🆕 Новые горячие новости в этом раунде (всего 2)

百度热搜 (1 новость):

  1. ChatGPT-5正式发布 [1]

微博 (1 новость):

  1. 比亚迪月销量破纪录 [2]

Время обновления: 2025-01-15 12:30:15

Пояснение формата сообщений

Элемент формата

Пример

Значение

Пояснение

🔥📈📌

🔥 [1/3] AI ChatGPT

Уровень популярности

🔥высокая (≥10) 📈средняя (5-9) 📌обычная (<5)

[номер/всего]

[1/3]

Позиция сортировки

Ранг текущей группы среди всех сопоставленных групп

Частотная группа

AI ChatGPT

Группа ключевых слов

Группа из конфигурационного файла, заголовок должен содержать одно из слов

: N новостей

: 2 новости

Количество совпадений

Общее количество новостей, сопоставленных с этой группой

[Название платформы]

[百度热搜]

Источник

Название платформы, к которой относится новость

🆕

🆕 ChatGPT-5正式发布

Маркер нового

Впервые появившаяся горячая тема в этом раунде

[число]

[1]

Высокий рейтинг

Горячая тема с рейтингом ≤ порога, выделена жирным красным

[число]

[7]

Обычный рейтинг

Горячая тема с рейтингом > порога, обычное отображение

- время

- 09时15分

Первое время

Время первого обнаружения новости

[время~время]

[08时30分 ~ 10时45分]

Длительность

Диапазон времени от первого появления до последнего

(N раз)

(3 раза)

Частота появления

Общее количество появлений за период мониторинга

Область новых

🆕 Новые горячие новости

Сводка новых тем

Отдельное отображение новых горячих тем, появившихся в этом раунде

6. Развёртывание Docker

Описание образов:

TrendRadar предоставляет два независимых Docker-образа, которые можно выбрать для развёртывания:

Имя образа

Назначение

Пояснение

wantcat/trendradar

Служба рассылки новостей

Периодический сбор новостей, отправка уведомлений (обязательно)

wantcat/trendradar-mcp

Служба ИИ-анализа

Поддержка протокола MCP, диалоговый ИИ-анализ (необязательно)

💡 Рекомендация:

  • Нужна только функция рассылки: разверните только образ wantcat/trendradar

  • Нужна функция ИИ-анализа: разверните оба образа

Способ 1: Использование docker compose (рекомендуется)

  1. Создайте каталог проекта и конфигурацию:

    # 克隆项目到本地
    git clone https://github.com/sansan0/TrendRadar.git
    cd TrendRadar

    💡 Пояснение: Ключевая структура каталогов для Docker-развёртывания выглядит следующим образом:

当前目录/
├── config/
│   ├── config.yaml                 # 核心功能配置(必需)
│   ├── frequency_words.txt         # 关键词配置(必需)
│   ├── timeline.yaml               # 时间线配置
│   ├── ai_analysis_prompt.txt      # AI 分析提示词(可选)
│   ├── ai_translation_prompt.txt   # AI 翻译提示词(可选)
│   ├── ai_interests.txt            # AI 兴趣过滤配置(可选)
│   ├── ai_filter/                  # AI 过滤相关提示词
│   │   ├── prompt.txt
│   │   ├── extract_prompt.txt
│   │   └── update_tags_prompt.txt
│   └── custom/                     # 用户自定义配置(可选)
│       ├── ai/                     # 自定义 AI 提示词
│       └── keyword/                # 自定义关键词文件
└── docker/
    ├── .env                        # 敏感信息 + Docker 特有配置
    └── docker-compose.yml          # Docker Compose 编排文件
  1. Описание файлов конфигурации:

    Принцип разделения конфигурации (оптимизация v4.6.0):

    Файл

    Назначение

    Частота изменения

    Описание

    config/config.yaml

    Основная конфигурация функций

    Низкая

    Режим отчёта, настройки push-уведомлений, формат хранения, окно push-уведомлений, переключатель AI-анализа, включение платформ и другие глобальные параметры поведения

    config/frequency_words.txt

    Конфигурация ключевых слов

    Высокая

    Задайте интересующие вас горячие темы, поддерживается расширенный синтаксис: группы, регулярные выражения, псевдонимы

    config/timeline.yaml

    Конфигурация временной шкалы

    Низкая

    Управляет отображением и правилами фильтрации временной шкалы новостей

    config/ai_analysis_prompt.txt

    Промпт для AI-анализа

    Средняя

    Настройка роли и формата вывода AI-анализа (v5.0.0+)

    config/ai_translation_prompt.txt

    Промпт для AI-перевода

    Низкая

    Шаблон промпта для AI-перевода

    config/ai_interests.txt

    Фильтр интересов AI

    Средняя

    Определяет правила автоматической фильтрации новостей AI на основе интересов

    config/ai_filter/

    Промпты для AI-фильтрации

    Низкая

    Внутренние промпты модуля AI-фильтрации (обычно не требуют изменения)

    config/custom/

    Пользовательские расширения

    По мере необходимости

    custom/ai/ для пользовательских AI-промптов, custom/keyword/ для пользовательских файлов ключевых слов

    docker/.env

    Конфиденциальная информация + конфигурация Docker

    Низкая

    Webhook URL, API-ключи, ключи S3, запланированные задачи и т.д., не отслеживается git

    💡 Ключевые моменты разделения:

    • Поведение функций → измените config.yaml (например, включение/выключение платформы, настройка режима push-уведомлений)

    • Отслеживаемый контент → измените frequency_words.txt (например, добавьте новые ключевые слова)

    • Стиль вывода AI → измените ai_analysis_prompt.txt или ai_translation_prompt.txt

    • Ключи и учётные данные → измените docker/.env (API-ключи, URL Webhook и т.д. — единое место для конфиденциальной информации)

    • Персонализированные расширения → используйте каталог config/custom/, чтобы избежать перезаписи при обновлении

    💡 Применение изменений конфигурации: После изменения config.yaml выполните docker compose up -d для перезапуска контейнера.

    ⚙️ Механизм переопределения переменных окружения (v3.0.5+)

    Переменные окружения в файле .env переопределяют соответствующие настройки в config.yaml:

    Переменная окружения

    Соответствующая конфигурация

    Пример значения

    Описание

    WEBSERVER_PORT

    -

    8080

    Порт веб-сервера

    FEISHU_WEBHOOK_URL

    notification.channels.feishu.webhook_url

    https://...

    Webhook Feishu (несколько аккаунтов разделяются ;)

    AI_ANALYSIS_ENABLED

    ai_analysis.enabled

    true / false

    Включить ли AI-анализ (новое в v5.0.0)

    AI_API_KEY

    ai.api_key

    sk-xxx...

    API-ключ AI (общий для ai_analysis и ai_translation)

    AI_PROVIDER

    ai.provider

    deepseek / openai / gemini

    Поставщик AI

    S3_*

    storage.remote.*

    -

    Конфигурация удалённого хранилища (5 параметров)

    Приоритет конфигурации: переменные окружения > config.yaml

    Как использовать:

    • Измените файл .env, заполните необходимые настройки

    • Или добавьте их непосредственно в разделе "Переменные окружения" в интерфейсе управления Docker на NAS/Synology

    • Перезапустите контейнер для применения: docker compose up -d

  2. Запуск сервиса:

    Вариант A: Запуск всех сервисов (push-уведомления + AI-анализ)

    # 拉取最新镜像
    docker compose pull
    
    # 启动所有服务(trendradar + trendradar-mcp)
    docker compose up -d

    Вариант B: Запуск только сервиса push-уведомлений

    # 只启动 trendradar(定时抓取和推送)
    docker compose pull trendradar
    docker compose up -d trendradar

    Вариант C: Запуск только MCP AI-анализ сервиса

    # 只启动 trendradar-mcp(提供 AI 分析接口)
    docker compose pull trendradar-mcp
    docker compose up -d trendradar-mcp

    💡 Подсказка:

    • Большинству пользователей достаточно запустить trendradar для получения push-уведомлений

    • Запуск trendradar-mcp требуется только при использовании ChatGPT/Gemini для AI-диалогового анализа

    • Оба сервиса независимы и могут гибко комбинироваться по мере необходимости

  3. Проверка статуса работы:

    # 查看新闻推送服务日志
    docker logs -f trendradar
    
    # 查看 MCP AI 分析服务日志
    docker logs -f trendradar-mcp
    
    # 查看所有容器状态
    docker ps | grep trendradar
    
    # 停止特定服务
    docker compose stop trendradar      # 停止推送服务
    docker compose stop trendradar-mcp  # 停止 MCP 服务

Способ 2: Локальная сборка (для разработчиков)

Если вам нужно изменить код или создать собственный образ:

# 克隆项目
git clone https://github.com/sansan0/TrendRadar.git
cd TrendRadar

# 修改配置文件
vim config/config.yaml
vim config/frequency_words.txt

# 使用构建版本的 docker compose
cd docker
cp docker-compose-build.yml docker-compose.yml

Сборка и запуск сервиса:

# 选项 A:构建并启动所有服务
docker compose build
docker compose up -d

# 选项 B:仅构建并启动新闻推送服务
docker compose build trendradar
docker compose up -d trendradar

# 选项 C:仅构建并启动 MCP AI 分析服务
docker compose build trendradar-mcp
docker compose up -d trendradar-mcp

💡 Пояснение параметров архитектуры:

  • По умолчанию собирается образ архитектуры amd64 (подходит для большинства серверов x86_64)

  • Для сборки образа архитектуры arm64 (Apple Silicon, Raspberry Pi и т.д.) установите переменную окружения:

    export DOCKER_ARCH=arm64
    docker compose build

Обновление образа

# 方式一:手动更新(爬虫 + MCP 镜像)
docker pull wantcat/trendradar:latest
docker pull wantcat/trendradar-mcp:latest
docker compose down
docker compose up -d

# 方式二:使用 docker compose 更新
docker compose pull
docker compose up -d

Доступные образы:

Имя образа

Использование

Описание

wantcat/trendradar

Сервис push-уведомлений

Периодический сбор новостей, отправка уведомлений

wantcat/trendradar-mcp

MCP-сервис

Функция AI-анализа (опционально)

Команды управления сервисом

# 查看运行状态
docker exec -it trendradar python manage.py status

# 手动执行一次爬虫
docker exec -it trendradar python manage.py run

# 查看实时日志
docker exec -it trendradar python manage.py logs

# 显示当前配置
docker exec -it trendradar python manage.py config

# 显示输出文件
docker exec -it trendradar python manage.py files

# Web 服务器管理(用于浏览器访问生成的报告)
docker exec -it trendradar python manage.py start_webserver   # 启动 Web 服务器
docker exec -it trendradar python manage.py stop_webserver    # 停止 Web 服务器
docker exec -it trendradar python manage.py webserver_status  # 查看 Web 服务器状态

# 查看帮助信息
docker exec -it trendradar python manage.py help

# 重启容器
docker restart trendradar

# 停止容器
docker stop trendradar

# 删除容器(保留数据)
docker rm trendradar

💡 Описание веб-сервера:

  • Автоматически запускается в режиме cron, доступ через браузер по адресу http://localhost:8080 для просмотра последних отчётов

  • Навигация по каталогам для просмотра исторических отчётов (например: http://localhost:8080/2025-xx-xx/)

  • Порт можно настроить параметром WEBSERVER_PORT в файле .env

  • Ручная остановка: docker exec -it trendradar python manage.py stop_webserver

  • Ручной запуск: docker exec -it trendradar python manage.py start_webserver

  • Совет по безопасности: предоставляет доступ только к статическим файлам, ограничен каталогом output, привязан только к локальному доступу

Постоянное хранение данных

Сгенерированные отчёты и данные по умолчанию сохраняются в каталоге ./output, данные сохраняются даже после перезапуска или удаления контейнера.

📊 Пути доступа к веб-отчётам:

Сгенерированный HTML-отчёт за текущий день сохраняется в двух местах:

Расположение файла

Способ доступа

Сценарий использования

output/index.html

Прямой доступ с хоста

Docker-развертывание (через монтирование Volume, виден на хосте)

index.html

Доступ из корня

GitHub Pages (корень репозитория, Pages автоматически распознаёт)

output/html/YYYY-MM-DD/当日汇总.html

Доступ к историческим отчётам

Все окружения (архив по датам)

Пример локального доступа:

# 方式 1:通过 Web 服务器访问(推荐,Docker 环境)
# 1. 启动 Web 服务器
docker exec -it trendradar python manage.py start_webserver
# 2. 在浏览器访问
http://localhost:8080                           # 访问最新报告(默认 index.html)
http://localhost:8080/html/2025-xx-xx/          # 访问指定日期的报告

# 方式 2:直接打开文件(本地环境)
open ./output/index.html             # macOS
start ./output/index.html            # Windows
xdg-open ./output/index.html         # Linux

# 方式 3:访问历史归档
open ./output/html/2025-xx-xx/当日汇总.html

Почему два файла index.html?

  • output/index.html: монтируется через Docker Volume на хост, можно открыть локально

  • index.html: отправляется в репозиторий через GitHub Actions, автоматически развертывается GitHub Pages

💡 Подсказка: Оба файла идентичны по содержанию, можно использовать любой.

Поиск и устранение неисправностей

# 检查容器状态
docker inspect trendradar

# 查看容器日志
docker logs --tail 100 trendradar

# 进入容器调试
docker exec -it trendradar /bin/bash

# 验证配置文件
docker exec -it trendradar ls -la /app/config/

Развертывание MCP-сервиса (функция AI-анализа)

Если вам нужна функция AI-анализа, вы можете развернуть отдельный контейнер MCP-сервиса.

Описание архитектуры:

flowchart TB
    subgraph trendradar["trendradar"]
        A1[定时抓取新闻]
        A2[推送通知]
    end
    
    subgraph trendradar-mcp["trendradar-mcp"]
        B1[127.0.0.1:3333]
        B2[AI 分析接口]
    end
    
    subgraph shared["共享卷"]
        C1["config/ (ro)"]
        C2["output/ (ro)"]
    end
    
    trendradar --> shared
    trendradar-mcp --> shared

Быстрый запуск:

Если вы уже развернули сервис, следуя Способ 1: Использование docker compose, просто запустите MCP-сервис:

cd TrendRadar/docker
docker compose up -d trendradar-mcp

# 查看运行状态
docker ps | grep trendradar-mcp

Отдельный запуск MCP-сервиса (без docker compose):

# Linux/Mac
docker run -d --name trendradar-mcp \
  -p 127.0.0.1:3333:3333 \
  -v $(pwd)/config:/app/config:ro \
  -v $(pwd)/output:/app/output:ro \
  -e TZ=Asia/Shanghai \
  wantcat/trendradar-mcp:latest

# Windows PowerShell
docker run -d --name trendradar-mcp `
  -p 127.0.0.1:3333:3333 `
  -v ${PWD}/config:/app/config:ro `
  -v ${PWD}/output:/app/output:ro `
  -e TZ=Asia/Shanghai `
  wantcat/trendradar-mcp:latest

⚠️ Внимание: При отдельном запуске убедитесь, что в текущем каталоге есть папки config/ и output/, и они содержат файлы конфигурации и данные новостей.

Проверка сервиса:

# 检查 MCP 服务健康状态
curl http://127.0.0.1:3333/mcp

# 查看 MCP 服务日志
docker logs -f trendradar-mcp

Настройка в AI-клиенте:

После запуска MCP-сервиса настройте его в зависимости от клиента:

Cherry Studio (рекомендуется, настройка через GUI):

  • Настройки → MCP-серверы → Добавить

  • Тип: streamableHttp

  • URL: http://127.0.0.1:3333/mcp

Claude Desktop / Cline (настройка через JSON):

{
  "mcpServers": {
    "trendradar": {
      "url": "http://127.0.0.1:3333/mcp",
      "type": "streamableHttp"
    }
  }
}

💡 Совет: MCP-сервис прослушивает только локальный порт (127.0.0.1) для обеспечения безопасности. Для удалённого доступа настройте обратный прокси и аутентификацию самостоятельно.

7. Как отображается содержимое push-уведомлений?

Место настройки: разделы report и display в config/config.yaml

report:
  mode: "daily"                    # 推送模式
  display_mode: "keyword"          # 显示模式(v4.6.0 新增)
  rank_threshold: 5                # 排名高亮阈值
  sort_by_position_first: false    # 排序优先级
  max_news_per_keyword: 0          # 每个关键词最大显示数量

display:
  region_order:                    # 区域显示顺序(v5.2.0 新增)
    - new_items                    # 新增热点区域
    - hotlist                      # 热榜区域
    - rss                          # RSS 订阅区域
    - standalone                   # 独立展示区
    - ai_analysis                  # AI 分析区域

Описание общих параметров настройки

Что я хочу изменить

Какой параметр изменить

Значение по умолчанию

Описание

Режим push-уведомлений

mode

daily

Определяет время и содержимое push-уведомлений, подробнее см. Подробное описание режимов push-уведомлений

Способ группировки

display_mode

keyword

keyword=группировка по ключевым словам (например, "AI"), platform=группировка по платформам (например, "微博")

Выделение важного

rank_threshold

5

Новости, входящие в топ-5, будут отображаться жирным шрифтом, чтобы сразу видеть самые горячие

Правило сортировки

sort_by_position_first

false

false=более горячие идут первыми, true=ваши настроенные слова идут первыми

Ограничение количества

max_news_per_keyword

0

Сколько новостей максимум показывать по каждому ключевому слову? 0 означает без ограничения

Порядок отображения

display.region_order

см. выше

Изменение порядка списка управляет позицией отображения каждого раздела

Сравнение способов группировки (display_mode)

Вы хотите видеть "какие новости по этой теме" или "какие новости на этой платформе"?

Режим

Способ группировки

Префикс заголовка

Сценарий использования

keyword (по умолчанию)

Агрегация по ключевым словам

[Название платформы]

Меня интересует "AI", хочу видеть новости об AI на всех платформах

platform

Агрегация по платформам

[Ключевое слово]

Меня интересует "微博", хочу видеть новости по моим ключевым словам на 微博

Порядок отображения разделов (region_order)

Изменяя порядок списка display.region_order, можно управлять позицией отображения каждого раздела в push-сообщении.

Порядок по умолчанию: Новые горячие темы → Горячие списки → RSS → Отдельная область отображения → AI-анализ

Пример настройки: Хотите, чтобы AI-анализ был первым?

display:
  region_order:
    - ai_analysis                  # 移到第一行
    - new_items
    - hotlist
    - rss
    - standalone

Внимание: Раздел отображается только при выполнении двух условий:

  1. Он присутствует в списке region_order

  2. Соответствующий переключатель в display.regions установлен в true

Переключатели разделов (regions)

Управление отображением разделов в push-уведомлениях через display.regions:

display:
  regions:
    hotlist: true                    # 热榜区域(关键词匹配的热点新闻)
    new_items: false                 # 新增热点区域(含热榜新增 + RSS 新增)
    rss: true                       # RSS 订阅区域(关键词匹配的 RSS 内容)
    standalone: false                # 独立展示区(完整热榜/RSS,不受关键词过滤)
    ai_analysis: true                # AI 分析区域

Раздел

Ключ конфигурации

Значение по умолчанию

Описание

Горячие списки

hotlist

true

Агрегация горячих новостей по ключевым словам

Новые горячие темы

new_items

false

Новые горячие темы за этот период (включая новые в горячих списках + новые в RSS). Примечание: маркер 🆕 в разделе горячих списков не зависит от этого переключателя

RSS

rss

true

Содержимое RSS-подписок, отфильтрованное по ключевым словам. После отключения RSS-анализ пропускается, но RSS в отдельной области отображения не затрагивается

Отдельная область отображения

standalone

false

Полное отображение содержимого указанных платформ/RSS, без фильтрации по ключевым словам

AI-анализ

ai_analysis

true

Сводка горячих тем, сгенерированная AI

Приоритет сортировки (sort_by_position_first)

Предположим, вы настроили ключевые слова: 1. Tesla, 2. BYD. Фактическая популярность: BYD (10 новостей), Tesla (3 новости).

Значение конфигурации

Результат сортировки

Ваше мнение

false (по умолчанию)

BYD (10 новостей) → Tesla (3 новости)

"Кто горячее, тот и первый"

true

Tesla (3 новости) → BYD (10 новостей)

"Мой порядок настройки — это приоритет, независимо от популярности"

Отдельная область отображения (standalone)

Сценарий: Некоторые платформы (например, 知乎热榜, HackerNews), я хочу просмотреть полностью, независимо от того, соответствуют ли они моим ключевым словам.

display:
  regions:
    standalone: true                  # 推送中展示独立展示区(关闭不影响 AI 分析)

  standalone:
    platforms: ["zhihu", "weibo"]     # 这些平台的热榜给我完整显示
    rss_feeds: ["hacker-news"]        # 这些RSS源的内容给我完整显示
    max_items: 20                     # 最多显示多少条

💡 Независимое управление отображением push-уведомлений и AI-анализом: regions.standalone управляет только отображением отдельной области в push-уведомлениях. Даже если отображение в push-уведомлениях отключено, AI всё равно будет анализировать полные данные этих платформ, если в конфигурации AI включено include_standalone: true. Подходит для пользователей, которые хотят, чтобы AI проводил глубокий анализ, но не хотят слишком длинных push-сообщений.

8. Когда мне приходят push-уведомления?

Место настройки: раздел schedule в config/config.yaml + config/timeline.yaml

Быстрый старт

Просто выберите один из предустановленных шаблонов в config.yaml, редактировать timeline.yaml не нужно:

schedule:
  enabled: true
  preset: "morning_evening"     # 改这里就行

Доступные предустановленные шаблоны

Имя шаблона

Описание

Поведение push-уведомлений

morning_evening

Инкрементально в течение дня + вечерняя сводка (рекомендуется)

Push при новых событиях в течение дня + вечерняя сводка за день с 19:00 до 21:00

always_on

Круглосуточный мониторинг

Push при новых событиях в течение дня, без разделения на временные периоды

office_hours

Рабочее время

Три периода в рабочие дни (утренний обзор → дневные горячие темы → вечерняя сводка), в выходные — свободные push-уведомления

night_owl

Ночная сова

Дневной обзор + ночная сводка за весь день (с 22:00 до 01:00, пересекает полночь)

custom

Полностью настраиваемый

Редактирование раздела custom внизу timeline.yaml

Полная настройка

Если ни один из предустановленных шаблонов не подходит, вы можете отредактировать раздел custom внизу config/timeline.yaml, свободно определяя временные периоды, дневные планы и недельные сопоставления. Подробнее см. комментарии в файле timeline.yaml.

Важные примечания

⚠️ Внимание, пользователи, обновляющиеся со старых версий:

  • В v6.0.0 удалены старые конфигурации notification.push_window и ai_analysis.analysis_window

  • Используйте новую систему планирования schedule + timeline.yaml

  • Старый "ежедневный push-уведомление" можно заменить шаблоном morning_evening

  • Старый "push-уведомление в рабочее время" можно заменить шаблоном office_hours

⚠️ Внимание, пользователи GitHub Actions:

  • Время выполнения GitHub Actions нестабильно, возможна погрешность ±15 минут

  • Рекомендуется оставлять запас по времени не менее 2 часов

  • Для точных запланированных push-уведомлений рекомендуется использовать Docker-развертывание на личном сервере

9. Как часто выполняется?

Место настройки: раздел schedule в .github/workflows/crawler.yml

on:
  schedule:
    - cron: "0 * * * *"  # 每小时运行一次

Как изменить частоту запуска?

GitHub Actions использует формат времени "Cron". Не нужно глубоко разбираться, просто скопируйте нужный код и замените.

Место настройки: раздел schedule в файле .github/workflows/crawler.yml

Я хочу...

Скопируйте эту строку кода

Описание

Каждый час

- cron: "0 * * * *"

Конфигурация по умолчанию, запуск в 0-ю минуту

Каждые 30 минут

- cron: "*/30 * * * *"

Запуск каждые 30 минут

Каждый день в 8:00

- cron: "0 0 * * *"

⚠️ Указано 0, потому что время UTC (0:00) = время по Москве (3:00)

Каждые полчаса в рабочее время

- cron: "*/30 0-14 * * *"

Соответствует времени по Москве 3:00 - 17:00

Три раза в день

- cron: "0 0,6,12 * * *"

Соответствует времени по Москве 3:00, 9:00, 15:00

⚠️ Два важных предупреждения

  1. Разница во времени: Серверы GitHub находятся за границей и используют время UTC.

    • Простая арифметика: желаемое время по Москве минус 3 часа = время, которое нужно указать.

    • Пример: чтобы запуск был в 20:00 по Москве, в настройках нужно указать 17:00

  2. Не слишком часто: Рекомендуемый интервал — не менее 30 минут.

    • Бесплатные ресурсы GitHub ограничены, слишком частый запуск может привести к ограничению аккаунта.

    • К тому же запуск Actions сам по себе имеет задержку в несколько минут, точный контроль не имеет смысла.

Пошаговая инструкция по изменению

  1. В вашем репозитории GitHub найдите файл .github/workflows/crawler.yml

  2. Нажмите кнопку ✏️ (Edit) в правом верхнем углу

  3. Найдите строку cron: "..." и замените содержимое кавычек на "код" из таблицы выше

  4. Нажмите зелёную кнопку Commit changes в правом верхнем углу для сохранения

10. Отправка в несколько групп/устройств

⚠️ Безопасность прежде всего

Не пишите пароли/токены прямо в config.yaml! Если вы загрузите файл с паролями на GitHub, его увидит весь мир.

Правильный подход:

  • Пользователи GitHub Actions: добавьте в Settings -> Secrets

  • Пользователи Docker: запишите в файл .env (этот файл не будет загружен)

Как отправлять в несколько мест одновременно?

Очень просто: разделите несколько адресов точкой с запятой ;.

Пример: Предположим, у вас есть две группы Feishu, и вы хотите получать push-уведомления в обе:

  • Адрес группы 1: https://.../webhook/aaa

  • Адрес группы 2: https://.../webhook/bbb

При настройке укажите: https://.../webhook/aaa;https://.../webhook/bbb

Платформы с поддержкой нескольких аккаунтов

平台

配置方法

注意事项

飞书/钉钉/企微

用 ; 分隔多个 Webhook URL

最简单,直接串起来就行

Bark (iOS)

用 ; 分隔多个 Key URL

推送到多台 iPhone

Telegram

Token 和 ChatID 都要用 ; 分隔

⚠️ 注意顺序要对应:Token1 对应 ChatID1Token2 对应 ChatID2

ntfy

Topic 和 Token 都要用 ; 分隔

如果某个Topic不需要Token,留空即可:token1;;token3 (中间那个是空的)

常用配置示例 (GitHub Secrets / .env)

# 飞书发给 3 个群
FEISHU_WEBHOOK_URL=https://hook1...;https://hook2...;https://hook3...

# 钉钉发给 2 个群
DINGTALK_WEBHOOK_URL=https://oapi...;https://oapi...

# Telegram 发给 2 个人 (注意一一对应)
TELEGRAM_BOT_TOKEN=tokenA;tokenB
TELEGRAM_CHAT_ID=userA;userB

提示:为了防止滥用,默认限制每个平台最多推送到 3 个账号。如果需要更多,可以修改 MAX_ACCOUNTS_PER_CHANNEL 配置。

11. 数据保存在哪里?

数据会存在哪里?

系统会自动帮你选择最合适的地方,你通常不需要操心:

你的运行环境

数据存在哪

说明

Docker / 本地运行

本地硬盘

存在项目目录下的 output/ 文件夹里,随时可以查看。

GitHub Actions

云端存储

因为 GitHub Actions 运行完就会销毁环境,所以必须配置云存储(例如 Cloudflare R2)。

怎么配置云存储?(GitHub Actions 用户必看)

如果你是用 GitHub Actions 运行,你需要一个"云端硬盘"来存数据。例如使用 Cloudflare R2(因为有免费额度)。

在 GitHub Secrets 里添加这 5 个变量:

变量名

填什么

STORAGE_BACKEND

remote

S3_BUCKET_NAME

你的存储桶名字

S3_ACCESS_KEY_ID

你的 Access Key

S3_SECRET_ACCESS_KEY

你的 Secret Key

S3_ENDPOINT_URL

你的 R2 接口地址

💡 详细教程:怎么申请 R2?请看 快速开始 - 远程存储配置

数据会保存多久?

默认情况下,我们不会自动删除你的数据。但如果你觉得数据太多占空间,可以设置"自动清理"。

配置位置:config/config.yaml

storage:
  local:
    retention_days: 30    # 本地数据只保留 30 天 (0 表示永久)
  remote:
    retention_days: 30    # 云端数据只保留 30 天

推送时间不对?(时区设置)

如果你身在海外,或者发现推送时间跟你的本地时间对不上,可以修改时区。

配置位置:config/config.yaml

app:
  timezone: "Asia/Shanghai"  # 默认是中国时间
  • 比如你在美国洛杉矶,改成:America/Los_Angeles

  • 比如你在英国伦敦,改成:Europe/London

12. 让 AI 帮我分析热点

AI 能帮我做什么?

开启这个功能后,AI 会像一个专业的分析师,在推送每一批新闻时:

  1. 自动阅读:阅读所有匹配到的热点新闻

  2. 深度思考:分析原本孤立的新闻之间的关联

  3. 撰写报告:在推送消息的末尾,附上一份简短深刻的"洞察报告"

包含内容:热点趋势总结、舆论风向判断、跨平台关联分析、潜在影响评估等。

怎么开启 AI 分析?

最简单的方法是通过环境变量配置(推荐 GitHub Secrets 或 .env)。

必需的配置项:

变量名

填什么

说明

AI_ANALYSIS_ENABLED

true

开启开关

AI_API_KEY

sk-xxxxxx

你的 API Key

AI_MODEL

deepseek/deepseek-chat

模型标识(格式:provider/model)

支持的 AI 提供商(基于 LiteLLM,支持 100+ 提供商):

提供商

AI_MODEL 填什么

说明

DeepSeek (推荐)

deepseek/deepseek-chat

性价比极高,适合高频分析

OpenAI

openai/gpt-4oopenai/gpt-4o-mini

GPT-4o 系列

Google Gemini

gemini/gemini-1.5-flashgemini/gemini-1.5-pro

Gemini 系列

自定义 API

任意格式

配合 AI_API_BASE 使用

💡 新特性:现已基于 LiteLLM 统一接口,支持 100+ AI 提供商,配置更简单、错误处理更完善。

可选配置项:

变量名

默认值

说明

AI_API_BASE

(自动)

自定义 API 地址(如 OneAPI、本地模型)

AI_TEMPERATURE

1.0

采样温度(0-2,越高越随机)

AI_MAX_TOKENS

5000

最大生成 token 数

AI_TIMEOUT

120

请求超时时间(秒)

AI_NUM_RETRIES

2

失败重试次数

进阶玩法:AI 翻译

如果你关注了国外的 RSS 源(比如 Hacker News),AI 可以帮你把内容翻译成中文推送。

配置位置:config/config.yaml

ai_translation:
  enabled: true          # 开启翻译
  language: "Chinese"    # 翻译成什么语言 (Chinese, English, Japanese...)

进阶玩法:自定义 AI "人设"

觉得 AI 说话太官方?你可以修改它的提示词,让它变成你喜欢的风格(比如"毒舌评论员"、"资深投资顾问")。

  • 修改文件:config/ai_analysis_prompt.txt

  • 修改方法:直接用记事本打开编辑,告诉 AI 你想要什么样的分析风格。

✨ AI 智能分析

TrendRadar v3.0.0 新增了基于 MCP (Model Context Protocol) 的 AI 分析功能,让你可以通过自然语言与新闻数据对话,进行深度分析。

⚠️ 使用前必读

重要提示:AI 功能需要本地新闻数据支持

AI 分析功能不是直接查询网络实时数据,而是分析你本地已积累的新闻数据(存储在 output 文件夹中)

使用说明:

  1. 项目自带测试数据:output 目录默认包含 2025-12-21~2025-12-27 一周的热榜新闻数据,可用于快速体验 AI 功能

  2. 查询限制:

    • ✅ 只能查询已有日期范围内的数据(12月21-27日,共7天)

    • ❌ 无法查询实时新闻或未来日期

  3. 获取最新数据:

    • 测试数据仅供快速体验,建议自行部署项目获取实时数据

    • 按照 快速开始 部署运行项目

    • 等待至少 1 天积累新闻数据后,即可查询最新热点

1. 快速部署

Cherry Studio 提供 GUI 配置界面,5 分钟快速部署,复杂的部分是一键安装的。

图文部署教程:现已更新到我的公众号,回复 "mcp" 即可

详细部署教程:README-Cherry-Studio.md

部署模式说明:

  • STDIO 模式(推荐):一次配置后续无需重复配置,图文部署教程中仅以此模式的配置为例。

  • HTTP 模式(备选):如果 STDIO 模式配置遇到问题,可使用 HTTP 模式。此模式的配置方式与 STDIO 基本一致,但复制粘贴的内容就一行,不易出错。唯一需要注意的是每次使用前都需要手动启动一下服务。详细请参考 README-Cherry-Studio.md 底部的 HTTP 模式说明。

2. 学习与 AI 对话的姿势

详细对话教程:README-MCP-FAQ.md

💡 提示:实际不建议一次性问多个问题。如果你选择的 AI 模型连下图的按顺序调用都无法做到,建议换一个。

🔌 MCP 客户端

TrendRadar MCP 服务支持标准的 Model Context Protocol (MCP) 协议,可以接入各种支持 MCP 的 AI 客户端进行智能分析。

支持的客户端

注意事项:

  • 将 /path/to/TrendRadar 替换为你的项目实际路径

  • Windows 路径使用双反斜杠:C:\\Users\\YourName\\TrendRadar

  • 保存后记得重启

方式一:HTTP 模式

  1. 启动 HTTP 服务:

    # Windows
    start-http.bat
    
    # Mac/Linux
    ./start-http.sh
  2. 配置 Cursor:

    项目级配置(推荐): 在项目根目录创建 .cursor/mcp.json:

    {
      "mcpServers": {
        "trendradar": {
          "url": "http://localhost:3333/mcp",
          "description": "TrendRadar 新闻热点聚合分析"
        }
      }
    }

    全局配置: 在用户目录创建 ~/.cursor/mcp.json(同样内容)

  3. 使用步骤:

    • 保存配置文件后重启 Cursor

    • 在聊天界面的 "Available Tools" 中查看已连接的工具

    • 开始使用:搜索今天的"AI"相关新闻

方式二:STDIO 模式(推荐)

创建 .cursor/mcp.json:

{
  "mcpServers": {
    "trendradar": {
      "command": "uv",
      "args": [
        "--directory",
        "/path/to/TrendRadar",
        "run",
        "python",
        "-m",
        "mcp_server.server"
      ]
    }
  }
}

Cline 配置

在 Cline 的 MCP 设置中添加:

HTTP 模式:

{
  "trendradar": {
    "url": "http://localhost:3333/mcp",
    "type": "streamableHttp",
    "autoApprove": [],
    "disabled": false
  }
}

STDIO 模式(推荐):

{
  "trendradar": {
    "command": "uv",
    "args": [
      "--directory",
      "/path/to/TrendRadar",
      "run",
      "python",
      "-m",
      "mcp_server.server"
    ],
    "type": "stdio",
    "disabled": false
  }
}

Continue 配置

编辑 ~/.continue/config.json:

{
  "experimental": {
    "modelContextProtocolServers": [
      {
        "transport": {
          "type": "stdio",
          "command": "uv",
          "args": [
            "--directory",
            "/path/to/TrendRadar",
            "run",
            "python",
            "-m",
            "mcp_server.server"
          ]
        }
      }
    ]
  }
}

使用示例:

分析最近7天"特斯拉"的热度变化趋势
生成今天的热点摘要报告
搜索"比特币"相关新闻并分析情感倾向

MCP Inspector 是官方调试工具,用于测试 MCP 连接:

使用步骤

  1. 启动 TrendRadar HTTP 服务:

    # Windows
    start-http.bat
    
    # Mac/Linux
    ./start-http.sh
  2. 启动 MCP Inspector:

    npx @modelcontextprotocol/inspector
  3. 在浏览器中连接:

    • 访问:http://localhost:3333/mcp

    • 测试 "Ping Server" 功能验证连接

    • 检查 "List Tools" 是否返回 17 个工具:

      • 基础查询:get_latest_news, get_news_by_date, get_trending_topics

      • 智能检索:search_news, find_related_news

      • 高级分析:analyze_topic_trend, analyze_data_insights, analyze_sentiment, aggregate_news, compare_periods, generate_summary_report

      • RSS 查询:get_latest_rss, search_rss, get_rss_feeds_status

      • 系统管理:get_current_config, get_system_status, resolve_date_range

任何支持 Model Context Protocol 的客户端都可以连接 TrendRadar:

HTTP 模式

服务地址:http://localhost:3333/mcp

基本配置模板:

{
  "name": "trendradar",
  "url": "http://localhost:3333/mcp",
  "type": "http",
  "description": "新闻热点聚合分析"
}

STDIO 模式(推荐)

基本配置模板:

{
  "name": "trendradar",
  "command": "uv",
  "args": [
    "--directory",
    "/path/to/TrendRadar",
    "run",
    "python",
    "-m",
    "mcp_server.server"
  ],
  "type": "stdio"
}

注意事项:

  • 替换 /path/to/TrendRadar 为实际项目路径

  • Windows 路径使用反斜杠转义:C:\\Users\\...

  • 确保已完成项目依赖安装(运行过 setup 脚本)

常见问题

检查步骤:

  1. 确认端口 3333 未被占用:

    # Windows
    netstat -ano | findstr :3333
    
    # Mac/Linux
    lsof -i :3333
  2. 检查项目依赖是否安装:

    # 重新运行安装脚本
    # Windows: setup-windows.bat 或者 setup-windows-en.bat
    # Mac/Linux: ./setup-mac.sh
  3. 查看详细错误日志:

    uv run python -m mcp_server.server --transport http --port 3333
  4. 尝试自定义端口:

    uv run python -m mcp_server.server --transport http --port 33333

解决方案:

  1. STDIO 模式:

    • 确认 UV 路径正确(运行 which uv 或 where uv)

    • 确认项目路径正确且无中文字符

    • 查看客户端错误日志

  2. HTTP 模式:

    • 确认服务已启动(访问 http://localhost:3333/mcp)

    • 检查防火墙设置

    • 尝试使用 127.0.0.1 替代 localhost

  3. 通用检查:

    • 重启客户端应用

    • 查看 MCP 服务日志

    • 使用 MCP Inspector 测试连接

可能原因:

  1. 数据不存在:

    • 确认已运行过爬虫(有 output 目录数据)

    • 检查查询日期范围是否有数据

    • 查看 output 目录的可用日期

  2. 参数错误:

    • 检查日期格式:YYYY-MM-DD

    • 确认平台 ID 正确:zhihu, weibo 等

    • 查看工具文档中的参数说明

  3. 配置问题:

    • 确认 config/config.yaml 存在

    • 确认 config/frequency_words.txt 存在

    • 检查配置文件格式是否正确

📚 项目相关

4 篇文章:

AI 开发:

  • 如果你有小众需求,完全可以基于我的项目自行开发,零编程基础的也可以试试

  • 我所有的开源项目或多或少都使用了自己写的AI辅助软件来提升开发效率,这款工具已开源

  • 核心功能:迅速筛选项目代码喂给AI,你只需要补充个人需求即可

  • 项目地址:https://github.com/sansan0/ai-code-context-helper

其余项目

📍 毛主席足迹地图 - 交互式动态展示1893-1976年完整轨迹。欢迎诸位同志贡献数据

哔哩哔哩(bilibili)评论区数据可视化分析软件

Star History Chart

📄 许可证

GPL-3.0 License


🔝 回到顶部

Available Tools

27 tools
aggregate_newsA

跨平台新闻聚合 - 对相似新闻进行去重合并

将不同平台报道的同一事件合并为一条聚合新闻,显示跨平台覆盖情况和综合热度。

Args: date_range: 日期范围,不指定则查询今天 platforms: 平台ID列表,如 ['zhihu', 'weibo'],不指定则使用所有平台 similarity_threshold: 相似度阈值,0.3-1.0,默认0.7(越高越严格) limit: 返回聚合新闻数量,默认50 include_url: 是否包含URL链接,默认False

Returns: JSON格式的聚合结果,包含去重统计、聚合新闻列表和平台覆盖统计

Examples: - aggregate_news() - aggregate_news(similarity_threshold=0.8)

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
platformsNo
date_rangeNo
include_urlNo
similarity_thresholdNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

无任何注释,描述需承担行为披露责任。描述说明了去重合并行为、返回内容包含去重统计和平台覆盖统计,但未提及是否有副作用(如触发抓取)、是否需要提前抓取数据、是否有速率限制等。对于只读聚合工具,基本行为已透明,但缺少额外细节。

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

描述以标题、Args、Returns、Examples分节,结构清晰,每个句子都有信息量,没有冗余。参数说明采用列表形式,并给出两个示例调用,简洁易读。

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

所有参数均有解释,返回结构有概述,且有示例。存在输出schema,因此无需详述返回字段。唯一小缺失是date_range的具体格式(允许字符串或对象但未举例),但整体信息足够代理正确调用。

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

输入schema的覆盖率为0%,但描述对所有5个参数都做了详细说明,包括类型、默认值、示例和含义(如similarity_threshold范围0.3-1.0,include_url控制是否包含链接)。描述完全补偿了schema的缺失,参数语义非常清晰。

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

描述以明确的动词'聚合'和资源'新闻'开头,说明将相似新闻去重合并,并显示跨平台覆盖和综合热度。与兄弟工具如search_news、get_latest_news相比,功能边界清晰,可直接区分。

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

描述通过功能说明隐含了使用场景(跨平台新闻去重聚合),但未明确说明何时应使用此工具而非其他工具(如search_news或find_related_news),也没有给出排除条件。缺乏显式的when/when-not指引。

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

analyze_data_insightsA

统一数据洞察分析工具 - 整合多种数据分析模式

Args: insight_type: 洞察类型,可选值: - "platform_compare": 平台对比分析(对比不同平台对话题的关注度) - "platform_activity": 平台活跃度统计(统计各平台发布频率和活跃时间) - "keyword_cooccur": 关键词共现分析(分析关键词同时出现的模式) topic: 话题关键词(可选,platform_compare模式适用) date_range: 【对象类型】 日期范围(可选) - 格式: {"start": "YYYY-MM-DD", "end": "YYYY-MM-DD"} - 示例: {"start": "2025-01-01", "end": "2025-01-07"} - 重要: 必须是对象格式,不能传递整数 min_frequency: 最小共现频次(keyword_cooccur模式),默认3 top_n: 返回TOP N结果(keyword_cooccur模式),默认20

Returns: JSON格式的数据洞察分析结果

Examples: - analyze_data_insights(insight_type="platform_compare", topic="人工智能") - analyze_data_insights(insight_type="platform_activity", date_range={"start": "2025-01-01", "end": "2025-01-07"}) - analyze_data_insights(insight_type="keyword_cooccur", min_frequency=5, top_n=15)

ParametersJSON Schema
NameRequiredDescriptionDefault
top_nNo
topicNo
date_rangeNo
insight_typeNoplatform_compare
min_frequencyNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that results are returned as JSON and describes analysis modes, but it never clarifies whether the tool is read-only, whether it triggers expensive computation, whether it depends on external data sources, or whether any state is changed. This leaves a meaningful transparency gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well organized with an intro, Args, Returns, and Examples sections. Every line adds value: mode definitions, parameter constraints, and concrete usage examples are all present without redundant filler. It is long enough to be useful and compact enough to scan quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with three modes, conditional parameters, and subtle date_range typing, the description covers the essential invocation knowledge: which parameters apply to which mode, defaults, formats, and example calls. It does not explicitly explain what happens when irrelevant parameters are passed or describe error cases, but an output schema exists and the provided information is sufficient for basic correct usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description provides rich semantics for all five parameters: allowed insight_type values with mode meanings, optional topic, strict date_range object format with example and a warning against integers, plus defaults for min_frequency and top_n. This is exactly what an agent needs to construct valid calls and goes far beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies an analysis tool for multiple data insight modes, enumerating three specific insight types with plain-language explanations. It does not explicitly differentiate itself from overlapping sibling tools like analyze_topic_trend or analyze_sentiment, so it misses a bit of sibling-targeted clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description shows when to use each mode through the insight_type options and concrete examples, but it never states when not to use the tool or which alternative sibling covers a similar case. Usage guidance is implied rather than explicit, especially given the large sibling set with analysis-related tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

analyze_sentimentA

分析新闻的情感倾向和热度趋势

建议:使用自然语言日期时,先调用 resolve_date_range 获取精确日期范围。

Args: topic: 话题关键词(可选) platforms: 平台ID列表,如 ['zhihu', 'weibo'],不指定则使用所有平台 date_range: 日期范围,格式 {"start": "YYYY-MM-DD", "end": "YYYY-MM-DD"},默认今天 limit: 返回新闻数量,默认50,最大100(会对标题去重) sort_by_weight: 是否按热度权重排序,默认True include_url: 是否包含URL链接,默认False(节省token)

Returns: JSON格式的分析结果,包含情感分布、热度趋势和相关新闻

Examples: - analyze_sentiment(topic="AI", date_range={"start": "2025-01-01", "end": "2025-01-07"})

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
topicNo
platformsNo
date_rangeNo
include_urlNo
sort_by_weightNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does this well by revealing meaningful behaviors: default date range is today, limit defaults to 50 and max 100, titles are deduplicated, platforms default to all, sorting defaults by heat weight, and include_url defaults to false to save tokens. It does not mention error cases or data-freshness limitations, but for a read-style analysis tool this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well structured and front-loaded: purpose, routing advice, parameter list, return summary, and example. It contains no filler or redundant explanation, and every section serves a practical purpose. The format makes it easy for an agent to scan and extract the needed information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given six parameters, no annotations, and an output schema, the description is largely complete: all parameters are documented, return contents are summarized, an example is provided, and sibling routing is mentioned. The output schema exists, so detailed return fields do not need to be enumerated. The main missing element is clearer guidance on when to choose this tool over sibling analysis tools, and the available platform IDs are not listed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must fully document the parameters, and it does. Every argument is explained with concrete details: date_range gets an explicit JSON format, platforms gets a realistic example, limit gets a maximum and deduplication note, and boolean flags get their default behavior. This fully compensates for the schema's lack of descriptive text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: analyze news sentiment and heat trends (分析新闻的情感倾向和热度趋势). It names a specific action and resource, and the parameter list clarifies that it works on a topic/platform/date range. However, it does not explicitly distinguish itself from similar sibling tools like analyze_topic_trend or analyze_data_insights, so it falls just short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides an explicit routing suggestion: if using natural-language dates, call resolve_date_range first. This is direct, actionable guidance for a specific alternative. It does not, however, discuss when this tool should be preferred over the other analysis-oriented siblings, so the usage guidance is clear but not exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

analyze_topic_trendA

统一话题趋势分析工具 - 整合多种趋势分析模式

建议:使用自然语言日期时,先调用 resolve_date_range 获取精确日期范围。

Args: topic: 话题关键词(必需) analysis_type: 分析类型 - "trend": 热度趋势分析(默认) - "lifecycle": 生命周期分析 - "viral": 异常热度检测 - "predict": 话题预测 date_range: 日期范围,格式 {"start": "YYYY-MM-DD", "end": "YYYY-MM-DD"},默认最近7天 granularity: 时间粒度,默认"day" spike_threshold: 热度突增倍数阈值(viral模式),默认3.0 time_window: 检测时间窗口小时数(viral模式),默认24 lookahead_hours: 预测未来小时数(predict模式),默认6 confidence_threshold: 置信度阈值(predict模式),默认0.7

Returns: JSON格式的趋势分析结果

Examples: - analyze_topic_trend(topic="AI", date_range={"start": "2025-01-01", "end": "2025-01-07"}) - analyze_topic_trend(topic="特斯拉", analysis_type="lifecycle")

ParametersJSON Schema
NameRequiredDescriptionDefault
topicYes
date_rangeNo
granularityNoday
time_windowNo
analysis_typeNotrend
lookahead_hoursNo
spike_thresholdNo
confidence_thresholdNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries the full burden. It discloses the JSON return format, the default date range, and mode-specific parameter behavior (viral thresholds, prediction lookahead, confidence). It does not mention rate limits, auth, or side effects, but for an analysis tool this is reasonably transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-organized with a title line, a usage tip, a compact Args block, Returns, and Examples. Every section adds value and the format is easy for an agent to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 8 parameters, 0% schema description coverage, no annotations, and an output schema, the description is largely complete: it explains parameter semantics, defaults, mode-specific options, and gives examples. Minor gaps remain, such as valid granularity values and explicit sibling-tool selection guidance.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, yet the description documents every parameter: topic as required, analysis_type with its four accepted values, date_range format, granularity, spike_threshold, time_window, lookahead_hours, and confidence_threshold. It fully compensates for the schema's lack of descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies it as a topic-trend analysis tool ('统一话题趋势分析工具') and enumerates four analysis modes. It states a specific verb and resource, but it does not explicitly contrast it with sibling analysis tools like analyze_data_insights or analyze_sentiment.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives one practical workflow hint: call resolve_date_range for natural-language dates. However, it does not say when to prefer this tool over its analysis siblings or when not to use it, so the usage guidance is implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_versionA

检查版本更新(同时检查 TrendRadar 和 MCP Server)

比较本地版本与 GitHub 远程版本,判断是否需要更新。

Args: proxy_url: 可选的代理URL,用于访问 GitHub(如 http://127.0.0.1:7890)

Returns: JSON格式的版本检查结果,包含两个组件的版本对比和是否需要更新

Examples: - check_version() - check_version(proxy_url="http://127.0.0.1:7890")

ParametersJSON Schema
NameRequiredDescriptionDefault
proxy_urlNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that the tool compares local and GitHub remote versions, checks both TrendRadar and MCP Server, supports an optional proxy for GitHub access, and returns JSON with comparison and update-needed status. This is reasonably transparent, though it does not explicitly state side-effect-free behavior or network failure characteristics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with Purpose, Args, Returns, and Examples sections. It is compact, front-loaded with the main purpose, and every section contributes useful information without padding or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one optional parameter and an output schema available, the description is complete enough to invoke correctly. It explains the return format, the optional argument, and provides two concrete call examples. Nothing essential is missing for correct usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the description must compensate. The Args section fully explains proxy_url as an optional proxy URL to access GitHub, provides a concrete example, and the schema supplies the default null. This adds clear meaning beyond the bare type definition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb and resource: it checks version updates by comparing local versions with GitHub remote versions, covering both TrendRadar and MCP Server. This makes it immediately distinguishable from sibling tools like sync_from_remote or get_system_status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The intended use is implied by the purpose and examples, but the description does not explicitly state when to prefer this tool over alternatives or when not to use it. There is no mention of sibling tools or exclusion cases, so guidance is only inferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

compare_periodsA

时期对比分析 - 比较两个时间段的新闻数据

对比不同时期的热点话题、平台活跃度、新闻数量等维度。

使用场景:

  • 对比本周和上周的热点变化

  • 分析某个话题在两个时期的热度差异

  • 查看各平台活跃度的周期性变化

Args: period1: 第一个时间段(基准期) - {"start": "YYYY-MM-DD", "end": "YYYY-MM-DD"}: 日期范围 - "today", "yesterday", "this_week", "last_week", "this_month", "last_month": 预设值 period2: 第二个时间段(对比期,格式同 period1) topic: 可选的话题关键词(聚焦特定话题的对比) compare_type: 对比类型 - "overview": 总体概览(默认)- 新闻数量、关键词变化、TOP新闻 - "topic_shift": 话题变化分析 - 上升话题、下降话题、新出现话题 - "platform_activity": 平台活跃度对比 - 各平台新闻数量变化 platforms: 平台过滤列表,如 ['zhihu', 'weibo'] top_n: 返回 TOP N 结果,默认10

Returns: JSON格式的对比分析结果,包含: - periods: 两个时期的日期范围 - compare_type: 对比类型 - overview/topic_shift/platform_comparison: 具体对比结果(根据类型)

Examples: - compare_periods(period1="last_week", period2="this_week") # 周环比 - compare_periods(period1="last_month", period2="this_month", compare_type="topic_shift") - compare_periods( period1={"start": "2025-01-01", "end": "2025-01-07"}, period2={"start": "2025-01-08", "end": "2025-01-14"}, topic="人工智能" )

ParametersJSON Schema
NameRequiredDescriptionDefault
top_nNo
topicNo
period1Yes
period2Yes
platformsNo
compare_typeNooverview

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must carry behavioral disclosure. It explains that compare_type selects different analyses (overview, topic_shift, platform_activity), that platforms filters sources, and that the result is JSON with period and type fields. It stops short of discussing failure modes, rate limits, or explicit read-only guarantees.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is organized with clear sections (purpose, use cases, arguments, returns, examples) and front-loads the core purpose. Despite covering six parameters, every sentence contributes useful information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a six-parameter analytical tool with no annotations but an output schema, the description is complete: all parameters are specified, supported values are listed, return shape is summarized, and three usage examples are provided. Nothing necessary to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must fully document parameters. It does: period1/period2 accept either object ranges or presets, topic is optional, compare_type enumerates all three values with meanings, platforms provides a concrete example, and top_n has its default. Examples reinforce the parameter formats.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with '时期对比分析 - 比较两个时间段的新闻数据', which names a specific verb (compare) and resource (news data across two periods). The use-case bullets further distinguish it from single-period or trend-only siblings by focusing on dual-period comparisons.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

A dedicated '使用场景' section lists concrete scenarios such as comparing this week vs last week and analyzing topic heat differences across periods. It gives clear when-to-use context but does not explicitly name excluded alternatives or when-not-to-use conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_summary_reportA

每日/每周摘要生成器 - 自动生成热点摘要报告

Args: report_type: 报告类型(daily/weekly) date_range: 【对象类型】 自定义日期范围(可选) - 格式: {"start": "YYYY-MM-DD", "end": "YYYY-MM-DD"} - 示例: {"start": "2025-01-01", "end": "2025-01-07"} - 重要: 必须是对象格式,不能传递整数

Returns: JSON格式的摘要报告,包含Markdown格式内容

ParametersJSON Schema
NameRequiredDescriptionDefault
date_rangeNo
report_typeNodaily

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden. It adds useful details: the output is JSON containing Markdown, and date_range must be an object rather than an integer. It does not disclose side effects, permissions, or any processing limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: a one-line purpose, then Args with clear formatting, then Returns. Every line adds value, and the object-format warning is high-signal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with only two optional parameters and an output schema, it covers parameter formats and the return shape well. The main omissions are when-to-use guidance and side-effect/permission hints, which would make it fully self-contained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the schema is under-specified: report_type is a plain string and date_range is a loose anyOf. The description compensates strongly by defining report_type values as daily/weekly and giving the exact date_range object format, an example, and a warning against passing integers.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: it generates daily/weekly hotspot summary reports. The daily/weekly scope is concrete, though it does not explicitly distinguish itself from sibling analysis tools like analyze_topic_trend or aggregate_news.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given for when to use this tool instead of siblings such as analyze_data_insights or aggregate_news. It only lists parameter values, not use conditions, prerequisites, or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_channel_format_guideA

获取通知渠道的格式化策略指南

返回各渠道支持的 Markdown 特性、格式限制和最佳格式化提示词。 在调用 send_notification 之前使用此工具,可以了解目标渠道的格式要求, 从而生成最佳排版效果的消息内容。

各渠道格式差异概览:

  • 飞书:支持 粗体、彩色文本、链接、--- 分割线

  • 钉钉:支持 ### 标题、粗体、> 引用、--- 分割线,不支持颜色

  • 企业微信:仅支持 粗体、链接、> 引用,不支持标题和分割线

  • Telegram:自动转为 HTML,支持粗体/斜体/删除线/代码/链接/引用块

  • ntfy:支持标准 Markdown,不支持颜色

  • Bark:iOS 推送,仅支持粗体和链接,内容需精简

  • Slack:自动转为 mrkdwn,粗体、删除线、<url|链接>

  • 邮件:自动转为完整 HTML 网页,支持标题/样式/分割线

  • 通用 Webhook:标准 Markdown 或自定义模板

Args: channel: 指定渠道 ID(可选),不指定返回所有渠道策略 可选值: feishu, dingtalk, wework, telegram, email, ntfy, bark, slack, generic_webhook

Returns: JSON格式的渠道格式化策略,包含支持特性、限制和格式化提示词

Examples: - get_channel_format_guide() # 获取所有渠道策略 - get_channel_format_guide(channel="feishu") # 获取飞书策略 - get_channel_format_guide(channel="telegram") # 获取 Telegram 策略

ParametersJSON Schema
NameRequiredDescriptionDefault
channelNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the behavioral disclosure burden. It clearly conveys a read-only, informational operation ('获取', '返回'), describes the JSON return format, and enumerates the detailed behavior across channels. It does not explicitly state 'read-only' or discuss side effects, but the non-mutating nature is strongly implied.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but highly structured and information-dense. It front-loads the purpose, then organizes channel differences, arguments, return type, and examples into clearly labeled sections. Every sentence contributes actionable information, and the per-channel breakdown is directly useful for the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, and the description still supplies essential context: optional behavior, valid channel IDs, return format, and usage examples. Given the tool's simple single-parameter interface, nothing an agent needs to select and invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must fully compensate. It defines the channel parameter, lists all valid values (feishu, dingtalk, wework, telegram, email, ntfy, bark, slack, generic_webhook), explains that omitting it returns all channel policies, and gives concrete usage examples. This exceeds what the minimal schema alone would provide.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: '获取通知渠道的格式化策略指南' (get notification channel formatting policy guide), and explicitly states it returns Markdown features, formatting restrictions, and best-practice prompt suggestions per channel. This clearly differentiates it from sibling tools like send_notification and get_notification_channels.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says to use this tool before calling send_notification to understand the target channel's format requirements. It provides clear context for when it is relevant, though it does not explicitly discuss when not to use it or name alternatives beyond its relationship to send_notification.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_current_configA

获取当前系统配置

Args: section: 配置节,可选值: - "all": 所有配置(默认) - "crawler": 爬虫配置 - "push": 推送配置 - "keywords": 关键词配置 - "weights": 权重配置

Returns: JSON格式的配置信息

ParametersJSON Schema
NameRequiredDescriptionDefault
sectionNoall

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the behavioral disclosure burden. It clearly indicates a read-only 'get' operation and mentions the JSON return format, but does not address potential authentication requirements, whether the config reflects live or cached state, or any other side effects. Sufficient for a simple getter, but not richly transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured with a front-loaded purpose and clear Args/Returns sections. It contains no fluff, though it slightly repeats the default value already present in the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one optional parameter and an output schema, the description is nearly complete. It documents all section choices and the return type. The only minor gap is not clarifying what 'current' means (e.g., live system state vs. persisted config), but this is not critical for a config getter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema only provides a default value and type for `section`, while the description adds all valid values: 'all', 'crawler', 'push', 'keywords', and 'weights'. Since schema description coverage is 0%, this description fully compensates by giving the agent the exact enumeration needed to call the tool correctly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool gets the current system configuration, with a specific resource (config) and verb (获取/get). It lists distinct config sections, which helps differentiate it from siblings like get_system_status or get_storage_status, though it does not explicitly name alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains how to use the `section` parameter and its allowed values, but it does not provide guidance on when to use this tool versus the many sibling tools. No exclusions or alternative tool references are given, leaving usage context to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_latest_newsA

获取最新一批爬取的新闻数据,快速了解当前热点

Args: platforms: 平台ID列表,如 ['zhihu', 'weibo'],不指定则使用所有平台 limit: 返回条数限制,默认50,最大1000 include_url: 是否包含URL链接,默认False(节省token)

Returns: JSON格式的新闻列表

数据展示建议

  • 默认展示全部返回数据,除非用户明确要求总结

  • 用户说"总结"或"挑重点"时才进行筛选

  • 用户问"为什么只显示部分"说明需要完整数据

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
platformsNo
include_urlNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden. It discloses return format, default limit, platform handling, include_url token-saving behavior, and explicit display expectations for the agent. It does not cover error behavior or data freshness guarantees, but the read-only nature is clear from the get verb.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with Args, Returns, and display guidance sections. The main purpose is front-loaded, and each section earns its place, though the display-suggestion block is slightly beyond tool invocation semantics.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read tool with three optional parameters and an output schema, the description is largely complete: it covers parameter behavior, defaults, return format, and agent-facing display policy. It could still mention ordering of results or what news fields are returned, but the output schema likely covers those.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description fully compensates by explaining all three parameters: platforms, limit with default and max, and include_url with its token-saving rationale. This is exactly the semantic content the schema lacks.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb and resource: it fetches the latest batch of crawled news data to quickly understand current hotspots. It is distinguishable from siblings like get_latest_rss and get_news_by_date, though it does not explicitly name them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given about when to use this tool versus alternatives such as search_news, get_news_by_date, or get_trending_topics. The only usage-related context is the display suggestion block, which addresses how to present results rather than when to select this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_latest_rssA

获取最新的 RSS 订阅数据(支持多日查询)

RSS 数据与热榜新闻分开存储,按时间流展示,适合获取特定来源的最新内容。

Args: feeds: RSS 源 ID 列表,如 ['hacker-news', '36kr'],不指定则返回所有源 days: 获取最近 N 天的数据,默认 1(仅今天),最大 30 天 limit: 返回条数限制,默认50,最大500 include_summary: 是否包含文章摘要,默认False(节省token)

Returns: JSON格式的 RSS 条目列表

Examples: - get_latest_rss() - get_latest_rss(days=7, feeds=['hacker-news'])

ParametersJSON Schema
NameRequiredDescriptionDefault
daysNo
feedsNo
limitNo
include_summaryNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It discloses storage separation, time-flow display, default/maximum values, and the token-saving effect of include_summary. As a read-only fetch tool, this is adequate, though it does not mention error or authentication behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded, with a clear purpose, structured Args, Returns, and Examples sections. Minor redundancy like 支持多日查询 repeating the days parameter details is acceptable but slightly unnecessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

All four parameters are documented with defaults and limits, return format is specified as JSON, and examples demonstrate typical calls. The presence of an output schema means detailed return-field documentation is unnecessary, making this complete for a read-only RSS fetching tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description fully compensates by explaining every parameter: feeds with ID examples, days with range and default, limit with cap, and include_summary with its purpose. This goes far beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 获取最新的 RSS 订阅数据, and further clarifies that RSS data is stored separately from hot-list news and displayed as a time stream. This makes it easy to distinguish from siblings like get_latest_news and search_rss.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a clear use case: retrieving recent content from specific RSS sources, and notes that RSS data is separate from hot-list news. However, it does not explicitly name alternatives such as search_rss or state when not to use this tool, so exclusions are missing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_news_by_dateA

获取指定日期的新闻数据,用于历史数据分析和对比

Args: date_range: 日期范围,支持多种格式: - 范围对象: {"start": "2025-01-01", "end": "2025-01-07"} - 自然语言: "今天", "昨天", "本周", "最近7天" - 单日字符串: "2025-01-15" - 默认值: "今天" platforms: 平台ID列表,如 ['zhihu', 'weibo'],不指定则使用所有平台 limit: 返回条数限制,默认50,最大1000 include_url: 是否包含URL链接,默认False(节省token)

Returns: JSON格式的新闻列表,包含标题、平台、排名等信息

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
platformsNo
date_rangeNo
include_urlNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the behavioral disclosure burden. It transparently explains date_range formats, platform filtering behavior, limit maximums, and the include_url token-saving default. It does not mention error handling, rate limits, or authentication, but the read-only nature of 'fetch' is clear and the parameter behaviors are well documented.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a concise purpose sentence followed by a clean Args/Returns breakdown. Every argument is explained with practical examples and defaults, with no filler or redundant content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has four optional parameters and an output schema, and the description covers all parameters, defaults, and return fields. It lacks edge-case details such as empty-result behavior or timezone handling, but for a read-only historical query tool, the description provides enough for an agent to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must fully compensate for parameter semantics. It does this excellently: date_range has multiple explicit format examples, platforms has an example list, limit has default and max values, and include_url states its default and rationale. This is more informative than the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool fetches news data for a specified date range for historical analysis and comparison. This is a specific verb+resource pair that distinguishes it from get_latest_news, though it does not explicitly name sibling alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a clear usage context: historical data analysis and comparison. It implies this tool is for date-bound queries rather than real-time or keyword searches, but it does not explicitly state when to prefer alternatives like get_latest_news or search_news.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_notification_channelsB

获取所有已配置的通知渠道及其状态

检测 config.yaml 和 .env 环境变量中的通知渠道配置。 支持 9 个渠道:飞书、钉钉、企业微信、Telegram、邮件、ntfy、Bark、Slack、通用 Webhook。

Returns: JSON格式的渠道状态,包含每个渠道是否已配置及配置来源

Examples: - get_notification_channels()

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the behavioral disclosure burden. It does disclose that the tool reads config.yaml and .env and returns a JSON status with configuration source, which is useful. However, it does not explicitly state that the operation is read-only, makes no external calls, or sends no notifications, which would be valuable given the sibling send_notification.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and key details are front-loaded, with the Returns and Examples sections adding clarity without excessive verbosity. Listing nine channels is necessary context, and the structure is easy to scan. Minor redundancy exists because the return format is already captured by the output schema, but it does not hurt usability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers what the tool returns, which config files are inspected, the list of supported channels, and a usage example. Since the tool has no parameters and an output schema exists, this is nearly complete. The main missing element is explicit guidance about how this tool relates to sibling notification tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero properties and 100% schema coverage, so there is no parameter detail for the description to add. The description includes an example invocation `get_notification_channels()` that confirms no arguments are required, satisfying the baseline for a zero-parameter tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: “获取所有已配置的通知渠道及其状态” (get all configured notification channels and their status). It further clarifies scope by listing 9 supported channels and the config sources checked. It does not explicitly differentiate from sibling tools like get_channel_format_guide, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies a usage context by mentioning config.yaml and .env detection, but it never states when to use this tool versus alternatives such as send_notification or get_channel_format_guide. There are no explicit exclusions or conditions that would help an agent decide between tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_rss_feeds_statusA

获取 RSS 源状态信息

查看当前配置的 RSS 源及其数据统计信息。

Returns: JSON格式的 RSS 源状态,包含: - available_dates: 有 RSS 数据的日期列表 - total_dates: 总日期数 - today_feeds: 今日各 RSS 源的数据统计 - {feed_id}: { name, item_count } - generated_at: 生成时间

Examples: - get_rss_feeds_status() # 查看所有 RSS 源状态

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description conveys that this is a read-only status view through '查看' and details of generated statistics. However, it does not explicitly state side-effect-free behavior, whether data is cached, or how it behaves when no feeds exist, so the burden is only partially met.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is structured and front-loaded with purpose, followed by a compact Returns list and an example. The opening line '获取 RSS 源状态信息' is mildly redundant with the name and second sentence, but overall there is no wasted bulk.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-parameter status tool, the description is largely complete: it states scope, return structure, and an example invocation. It could be more complete by explicitly distinguishing when to use this over sibling tools like get_system_status or list_available_dates.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, and the example get_rss_feeds_status() confirms no arguments are required. With schema coverage at 100% and no params, the description adds no parameter semantics but none are needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a clear verb ('获取/查看') and a specific resource (RSS feeds status and their data statistics), and the Returns section defines exactly what is included. It differentiates from siblings like get_system_status/get_storage_status by scoping to configured RSS sources and their stats.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear context: use this to view currently configured RSS sources and their data statistics. It does not explicitly name alternative tools or provide when-not-to-use conditions, but the context is specific enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_storage_statusA

获取存储配置和状态

查看当前存储后端配置、本地和远程存储的状态信息。

Returns: JSON格式的存储状态信息,包含本地/远程存储状态和拉取配置

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

无注释提供,描述承担了行为披露的负担。描述了返回内容和格式(JSON状态信息),但未明确说明操作是否只读、是否会触发副作用或需要权限。不过“查看”和“获取”暗示了非破坏性,基本行为是清晰的。

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

描述简洁高效,第一句即点明核心功能,随后补充返回内容,每句话都有价值,没有冗余信息。

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

工具无参数、有输出模式,描述已涵盖返回格式和主要内容。对于这种简单查询工具,没有遗漏关键信息,描述足以让代理正确调用。

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

该工具没有参数,输入模式为空,因此描述无需补充参数语义。根据规则,0参数时基线得分为4。

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

描述明确使用了具体动词“获取/查看”,资源是“存储配置和状态”,并具体说明包含本地/远程存储状态和拉取配置。与兄弟工具如get_rss_feeds_status、get_system_status在名称和描述上都能清晰区分。

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

描述隐含了用途(查看存储状态),但没有明确说明何时使用此工具而非其他工具,也没有提及替代方案或排除条件。虽然功能自明,但缺少显式的使用情境指导。

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_system_statusB

获取系统运行状态和健康检查信息

返回系统版本、数据统计、缓存状态等信息

Returns: JSON格式的系统状态信息

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden of explaining behavior. It indicates a read-only operation through '获取' and '返回', and lists what data is returned. However, it does not explicitly state that the operation is non-destructive, or disclose any side effects, auth requirements, or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loaded, but somewhat repetitive: '返回系统版本、数据统计、缓存状态等信息' and 'Returns: JSON格式的系统状态信息' overlap. Given that an output schema exists, the final 'Returns' line adds marginal value and could be trimmed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a simple parameterless status tool with an output schema, and the description covers what the status includes and the return format. However, it lacks guidance on how this tool relates to overlapping siblings and does not compensate for the absence of annotations with additional behavioral context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters and schema coverage is 100%, so no parameter documentation is needed. The description adds no parameter semantics, but the baseline for a parameterless tool is 4, which is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource: '获取系统运行状态和健康检查信息' (get system running status and health check info) and lists concrete contents (system version, data statistics, cache status). This is clear, though it does not explicitly differentiate itself from siblings like get_storage_status or check_version beyond the broad scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance about when to use this tool versus the many related siblings such as get_rss_feeds_status, get_storage_status, get_current_config, or check_version. The description implies general system status retrieval but provides no conditions, exclusions, or alternative suggestions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_available_datesA

列出本地/远程可用的日期范围

查看本地和远程存储中有哪些日期的数据可用。

Args: source: 数据来源 - "local": 仅本地 - "remote": 仅远程 - "both": 同时列出并对比(默认)

Returns: JSON格式的日期列表,包含各来源的日期信息和对比结果

Examples: - list_available_dates() - list_available_dates(source="local")

ParametersJSON Schema
NameRequiredDescriptionDefault
sourceNoboth

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations are absent, so the description carries the behavioral disclosure burden. It discloses that the tool reads local/remote storage, can compare both, and returns JSON date lists, which is adequate for a non-destructive listing tool. However, it does not mention date format, empty-result behavior, or network/error implications.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well structured with summary, Args, Returns, and Examples sections, making it easy to scan. There is minor redundancy between '列出本地/远程可用的日期范围' and '查看本地和远程存储中有哪些日期的数据可用', but no wasteful content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one optional parameter and no required fields, the description covers purpose, source values, return shape, and examples; an output schema also exists. It could add exact date range format or behavior when no data is available, but nothing essential is missing for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema only says source is a string with default 'both' and has 0% description coverage. The description compensates by enumerating valid values local/remote/both, stating the default, and giving examples. There is no ambiguity about how to use the only parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first line names a specific operation (列出) and resource (local/remote available date ranges), and the description expands on distinct scopes. It stands apart from siblings like get_news_by_date or resolve_date_range because it focuses on availability of dates in storage.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains how to use the source parameter and what each value does, but it does not explicitly state when to use this tool instead of siblings such as resolve_date_range or get_news_by_date. Usage is implied through '查看本地和远程存储中有哪些日期的数据可用', but no exclusions or alternatives are named.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read_articleA

读取指定 URL 的文章内容,返回 LLM 友好的 Markdown 格式

通过 Jina AI Reader 将网页转换为干净的 Markdown,自动去除广告、导航栏等噪音内容。 适合用于:阅读新闻正文、获取文章详情、分析文章内容。

典型使用流程:

  1. 先用 search_news(include_url=True) 搜索新闻获取链接

  2. 再用 read_article(url=链接) 读取正文内容

  3. AI 对 Markdown 正文进行分析、摘要、翻译等

Args: url: 文章链接(必需),以 http:// 或 https:// 开头 timeout: 请求超时时间(秒),默认 30,最大 60

Returns: JSON格式的文章内容,包含完整 Markdown 正文

Examples: - read_article(url="https://example.com/news/123")

Note: - 使用 Jina AI Reader 免费服务(100 RPM 限制) - 每次请求间隔 5 秒(内置速率控制) - 部分付费墙/登录墙页面可能无法完整获取

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYes
timeoutNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden, and it does so well. It discloses the underlying Jina AI Reader service, automatic noise removal, the free-tier 100 RPM limit, built-in 5-second rate control, and the fact that paywalled/login-walled pages may not be fully retrievable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well organized with sections for purpose, use cases, workflow, arguments, return format, and limitations. Every section adds practical information for an agent, and the primary purpose is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the core return value (JSON containing Markdown), the expected usage flow, rate limits, and failure caveats. For a small two-parameter tool, this is sufficient for an agent to select and call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description compensates fully. It specifies that url is required and must start with http:// or https://, gives timeout semantics with default 30 and max 60, and includes a concrete example call.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: reading the content of a given URL and converting it to LLM-friendly Markdown. It clearly differentiates from search-oriented siblings by focusing on fetching and cleaning page content rather than discovering or aggregating news.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit context: use after search_news(include_url=True), and for reading news正文, getting article details, or analyzing content. It does not explicitly contrast with read_articles_batch, so it lacks a direct exclusion for multi-URL cases, but the intended workflow is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read_articles_batchA

批量读取多篇文章内容(最多 5 篇,间隔 5 秒)

逐篇请求文章内容,每篇之间自动间隔 5 秒以遵守速率限制。

典型使用流程:

  1. 先用 search_news(include_url=True) 搜索新闻获取多个链接

  2. 再用 read_articles_batch(urls=[...]) 批量读取正文

  3. AI 对多篇文章进行对比分析、综合报告

Args: urls: 文章链接列表(必需),最多处理 5 篇 timeout: 每篇的请求超时时间(秒),默认 30

Returns: JSON格式的批量读取结果,包含每篇的完整内容和状态

Examples: - read_articles_batch(urls=["https://a.com/1", "https://b.com/2"])

Note: - 单次最多读取 5 篇,超出部分会被跳过 - 5 篇约需 25-30 秒(每篇间隔 5 秒) - 单篇失败不影响其他篇的读取

ParametersJSON Schema
NameRequiredDescriptionDefault
urlsYes
timeoutNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations present, the description bears the full burden of behavior disclosure and succeeds: it reveals automatic 5-second spacing for rate-limit compliance, a hard cap of 5 articles with excess skipped, per-article failure isolation, expected duration, and the nature of the JSON return. This is substantial valuable context beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-organized with sections for Args, Returns, Examples, and Notes, making it scannable. It loses a point for redundancy: the 5-article limit and 5-second interval are repeated in the opening sentence, the following paragraph, and the Notes section, but the overall size remains reasonable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity, two parameters, no annotations, and the presence of an output schema, the description covers every practical need: selection workflow, limits, timing, timeout, partial failure behavior, and return shape. An agent can correctly invoke this tool without further information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description fully compensates: urls is explained as a required list of article links with a maximum of 5, and timeout is defined as per-request timeout in seconds with default 30. This adds semantic meaning the bare input schema lacks.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: '批量读取多篇文章内容(最多 5 篇,间隔 5 秒)'. It clearly differentiates from the sibling read_article by emphasizing batch processing, and even provides a workflow where it follows search_news, making its role unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a concrete '典型使用流程' with an explicit before-step: first search_news(include_url=True) to get URLs, then read_articles_batch(urls=[...]). It does not explicitly contrast with read_article or list exclusions, but the workflow and batch scope make the primary use case clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

resolve_date_rangeA

【推荐优先调用】将自然语言日期表达式解析为标准日期范围

为什么需要这个工具? 用户经常使用"本周"、"最近7天"等自然语言表达日期,但 AI 模型自己计算日期 可能导致不一致的结果。此工具在服务器端使用精确的当前时间计算,确保所有 AI 模型获得一致的日期范围。

推荐使用流程:

  1. 用户说"分析AI本周的情感倾向"

  2. AI 调用 resolve_date_range("本周") → 获取精确日期范围

  3. AI 调用 analyze_sentiment(topic="ai", date_range=上一步返回的date_range)

Args: expression: 自然语言日期表达式,支持: - 单日: "今天", "昨天", "today", "yesterday" - 周: "本周", "上周", "this week", "last week" - 月: "本月", "上月", "this month", "last month" - 最近N天: "最近7天", "最近30天", "last 7 days", "last 30 days" - 动态: "最近5天", "last 10 days"(任意天数)

Returns: JSON格式的日期范围,可直接用于其他工具的 date_range 参数: { "success": true, "expression": "本周", "date_range": { "start": "2025-11-18", "end": "2025-11-26" }, "current_date": "2025-11-26", "description": "本周(周一到周日,11-18 至 11-26)" }

Examples: 用户:"分析AI本周的情感倾向" AI调用步骤: 1. resolve_date_range("本周") → {"date_range": {"start": "2025-11-18", "end": "2025-11-26"}, ...} 2. analyze_sentiment(topic="ai", date_range={"start": "2025-11-18", "end": "2025-11-26"})

用户:"看看最近7天的特斯拉新闻"
AI调用步骤:
1. resolve_date_range("最近7天")
   → {"date_range": {"start": "2025-11-20", "end": "2025-11-26"}, ...}
2. search_news(query="特斯拉", date_range={"start": "2025-11-20", "end": "2025-11-26"})
ParametersJSON Schema
NameRequiredDescriptionDefault
expressionYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does well: it discloses server-side computation using precise current time, consistency across AI models, supported expression categories, and the exact return JSON shape. It does not discuss failure behavior or timezone assumptions, but it provides substantial behavioral context beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is longer than minimal, but it is well-structured with headers, bullet lists, and examples, and each section adds value. The workflow and duplicate examples are somewhat repetitive, but the structure is scannable and front-loaded with the recommended-priority guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter helper tool with no annotations but an output schema, the description is complete: it covers why the tool exists, when to call it, how to call it, supported inputs, return format, and worked examples chaining into other tools. Nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must fully explain the parameter, and it does. It documents the single 'expression' parameter with categorized supported formats, examples, and dynamic 'last N days' support, adding clear meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool resolves natural language date expressions into a standard date range using a specific verb and resource. It distinguishes itself by explaining this is the recommended first call before date-consuming tools like analyze_sentiment, and the scope is precise.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly recommends prioritizing this tool when users express dates naturally and provides a step-by-step workflow with concrete examples. It does not explicitly state when not to use it or name alternative date-related tools, but the usage context is strong and unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_newsA

统一搜索接口,支持多种搜索模式,可同时搜索热榜和RSS

建议:使用自然语言日期时,先调用 resolve_date_range 获取精确日期范围。

Args: query: 搜索关键词或内容片段 search_mode: 搜索模式 - "keyword": 精确关键词匹配(默认) - "fuzzy": 模糊内容匹配 - "entity": 实体名称搜索(人物/地点/机构) date_range: 日期范围,格式 {"start": "YYYY-MM-DD", "end": "YYYY-MM-DD"},默认今天 platforms: 平台ID列表,如 ['zhihu', 'weibo'],不指定则使用所有平台 limit: 热榜返回条数限制,默认50 sort_by: 排序方式 - "relevance"(相关度)/ "weight"(权重)/ "date"(日期) threshold: 相似度阈值(仅fuzzy模式),0-1,默认0.6 include_url: 是否包含URL链接,默认False include_rss: 是否同时搜索RSS数据,默认False rss_limit: RSS返回条数限制,默认20

Returns: JSON格式的搜索结果,包含热榜新闻列表和可选的RSS结果

Examples: - search_news(query="AI") - search_news(query="AI", include_rss=True) - search_news(query="特斯拉", date_range={"start": "2025-01-01", "end": "2025-01-07"})

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
queryYes
sort_byNorelevance
platformsNo
rss_limitNo
thresholdNo
date_rangeNo
include_rssNo
include_urlNo
search_modeNokeyword

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full behavioral disclosure burden. It explains that the tool returns JSON with hot searches and optional RSS results, and describes search modes and filtering. It does not disclose potential side effects, rate limits, or result ordering behavior beyond the sort_by parameter, so coverage is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-organized: a purpose statement, a cross-tool suggestion, a parameter reference, return description, and examples. Every section adds value, and the structure makes the long parameter list scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is complex with 10 parameters, but the description covers parameters, defaults, modes, and examples, while an output schema exists for return values. The only meaningful gap is the lack of explicit guidance on when to choose this tool versus closely related sibling tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, but the description fully compensates with a detailed Args block explaining every parameter, including search_mode variants, threshold semantics, date_range format, and default values. This goes well beyond the schema and gives agents actionable parameter guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies this as a unified search interface that searches both hot lists and RSS, with multiple search modes. It is distinguishable from siblings like search_rss and get_latest_news, though it does not explicitly name them or contrast itself against them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a concrete usage suggestion to call resolve_date_range for natural language dates, which gives useful cross-tool guidance. However, it does not explicitly state when to prefer this over sibling tools such as search_rss or get_trending_topics.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_rssA

搜索 RSS 数据

在 RSS 订阅数据中搜索包含指定关键词的文章。

Args: keyword: 搜索关键词(必需) feeds: RSS 源 ID 列表,如 ['hacker-news', '36kr'] - 不指定时:搜索所有 RSS 源 days: 搜索最近 N 天的数据,默认 7 天,最大 30 天 limit: 返回条数限制,默认50 include_summary: 是否包含文章摘要,默认False

Returns: JSON格式的匹配 RSS 条目列表

Examples: - search_rss(keyword="AI") - search_rss(keyword="machine learning", feeds=['hacker-news'], days=14)

ParametersJSON Schema
NameRequiredDescriptionDefault
daysNo
feedsNo
limitNo
keywordYes
include_summaryNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It covers feed scoping behavior, default and maximum days, limit default, include_summary default, and the JSON return format. It does not mention sorting, matching semantics, or error behavior, but these are relatively minor for a search tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a one-line summary, an Args block, Returns, and Examples. Every section earns its place, there is no filler, and the most important scoping information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a five-parameter search tool with no annotations, the description covers parameter semantics, defaults, return type, and provides two concrete invocation examples. It omits details like valid feed identifiers and sort order, but these are largely discoverable from sibling tools and do not prevent correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, and the description fully compensates by explaining every parameter: keyword is required, feeds has an example and default behavior, days has default/max, limit has default, and include_summary has default. This adds significant meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action: searching RSS subscription data for articles containing a keyword. It is unambiguous about the resource (RSS 订阅数据) but does not explicitly distinguish itself from sibling tools like search_news or get_latest_rss, so it stops short of full differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives useful behavioral context such as 'search all RSS feeds when feeds is not specified' and includes examples, which imply typical usage. However, it does not explicitly state when to prefer this tool over alternatives or when not to use it, leaving some routing decisions to the agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

send_notificationA

向已配置的通知渠道发送消息

接受 markdown 格式内容,内部自动适配各渠道的格式要求和限制:

  • 飞书:Markdown 卡片消息(支持 粗体、彩色文本、链接、---)

  • 钉钉:Markdown(自动降级标题为 ###、剥离 标签和删除线)

  • 企业微信:Markdown(自动剥离 # 标题、---、 标签、删除线)

  • Telegram:HTML(自动转换 **→、*→、~~→、>→)

  • Email:HTML 邮件(完整网页样式,支持 # 标题、---、粗体斜体)

  • ntfy:Markdown(自动剥离 标签)

  • Bark:Markdown(自动简化为粗体+链接,适配 iOS 推送)

  • Slack:mrkdwn(自动转换 **→*、~~→~、text→<url|text>)

  • 通用 Webhook:Markdown(支持自定义模板)

提示:发送前可调用 get_channel_format_guide 获取目标渠道的详细格式化策略, 以生成最佳排版效果的消息内容。

Args: message: markdown 格式的消息内容(必需) title: 消息标题,默认 "TrendRadar 通知" channels: 指定发送的渠道列表,不指定则发送到所有已配置渠道 可选值: feishu, dingtalk, wework, telegram, email, ntfy, bark, slack, generic_webhook

Returns: JSON格式的发送结果,包含每个渠道的发送状态

Examples: - send_notification(message="测试消息\n这是一条测试通知") - send_notification(message="紧急通知", title="系统告警", channels=["feishu", "dingtalk"])

ParametersJSON Schema
NameRequiredDescriptionDefault
titleNoTrendRadar 通知
messageYes
channelsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does this well by detailing how markdown is adapted per channel (e.g., Telegram converts ** to <b>, Slack converts ** to *), stating that channels default to all configured channels, and noting that the return is JSON with per-channel status. It could be more transparent about failure behavior and rate limits, but the given detail is substantial.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured with sections: purpose, per-channel formatting details, a helpful tip, args, return value, and examples. Every section earns its place, and the most important information is front-loaded. The per-channel list is dense but directly useful for predicting tool behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of multi-channel formatting and zero schema coverage, the description is remarkably complete. It explains what the tool does, how it transforms content for each channel, what parameters are accepted, what the return value looks like, and gives examples. The mention of get_channel_format_guide also connects it to related tooling. No critical information needed to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for all parameter meaning. It does so thoroughly: message is marked as required markdown content, title has a default of 'TrendRadar 通知', and channels lists all valid values. Examples further clarify usage. This fully bridges the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: '向已配置的通知渠道发送消息' (send messages to configured notification channels). It clearly distinguishes itself from sibling tools like get_channel_format_guide and get_notification_channels by focusing on the sending action rather than retrieval or guidance.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context: it sends markdown-formatted messages to channels, optionally specifying channels, and explicitly recommends calling get_channel_format_guide before sending for optimal formatting. It does not explicitly state when not to use this tool, but the purpose is distinct enough among the sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sync_from_remoteA

从远程存储拉取数据到本地

用于 MCP Server 等场景:爬虫存到远程云存储(如 Cloudflare R2), MCP Server 拉取到本地进行分析查询。

Args: days: 拉取最近 N 天的数据,默认 7 天 - 0: 不拉取 - 7: 拉取最近一周的数据 - 30: 拉取最近一个月的数据

Returns: JSON格式的同步结果,包含: - success: 是否成功 - synced_files: 成功同步的文件数量 - synced_dates: 成功同步的日期列表 - skipped_dates: 跳过的日期(本地已存在) - failed_dates: 失败的日期及错误信息 - message: 操作结果描述

Examples: - sync_from_remote() # 拉取最近7天 - sync_from_remote(days=30) # 拉取最近30天

Note: 需要在 config/config.yaml 中配置远程存储(storage.remote)或设置环境变量: - S3_ENDPOINT_URL: 服务端点 - S3_BUCKET_NAME: 存储桶名称 - S3_ACCESS_KEY_ID: 访问密钥 ID - S3_SECRET_ACCESS_KEY: 访问密钥

ParametersJSON Schema
NameRequiredDescriptionDefault
daysNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must carry the behavioral disclosure burden, and it largely does. It explains that dates already present locally are skipped (skipped_dates), failed dates are reported with errors, and the operation requires specific S3 configuration. It does not explicitly warn about network load or whether it modifies existing files beyond skipping, but the skip behavior implies non-destructive sync.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections: overview, Args, Returns, Examples, and Note. Every section contributes necessary information — parameter semantics, return schema, usage examples, and configuration requirements — with no redundant filler. The purpose sentence is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter tool, the description covers everything needed to invoke it correctly: parameter meaning and default, return format with all fields, configuration requirements, and usage examples. The output schema exists, but the description already details the return structure sufficiently, and the sibling context shows this is a standalone sync operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema only defines 'days' as an integer with default 7 and 0% description coverage. The tool description fully compensates by explaining the meaning ('pull data from the last N days'), enumerating common values (0, 7, 30) with concrete interpretations, and providing examples for both default and explicit usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: '从远程存储拉取数据到本地' (pull data from remote storage to local), making the tool's core action unmistakable. It also situates the tool in the MCP Server workflow (crawlers store to remote cloud storage, server pulls for local analysis), which clearly distinguishes it from siblings like trigger_crawl, get_storage_status, or list_available_dates.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a clear usage context: pulling crawler data from remote cloud storage (e.g., Cloudflare R2) into local for analysis. It does not explicitly name alternative tools or state when-not-to-use conditions, but the scenario and prerequisites (config file or S3 environment variables) are clear enough for an agent to select it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

trigger_crawlA

手动触发一次爬取任务(可选持久化)

Args: platforms: 平台ID列表,如 ['zhihu', 'weibo'],不指定则使用所有平台 save_to_local: 是否保存到本地 output 目录,默认 False include_url: 是否包含URL链接,默认False(节省token)

Returns: JSON格式的任务状态信息,包含成功/失败平台列表和新闻数据

Examples: - trigger_crawl(platforms=['zhihu']) - trigger_crawl(save_to_local=True)

ParametersJSON Schema
NameRequiredDescriptionDefault
platformsNo
include_urlNo
save_to_localNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the disclosure burden and does a good job: it reveals that this is a manual/mutating crawl action, that persistence is optional via save_to_local, that include_url=False saves tokens, and that the return is JSON task status with success/failure platform lists. It does not cover rate limits, duration, or whether the crawl may overwrite existing data, but it provides materially more than a bare mutation label.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-structured: a one-line summary, labeled Args with defaults/meaning, a Returns note, and two concrete examples. No redundant filler appears, and the key scoping behavior (default all platforms) is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a three-parameter tool with an output schema and clear examples, the description covers invocation, defaults, and return shape sufficiently. It could be even more complete by noting whether the crawl runs synchronously/asynchronously and how invalid platform IDs are handled, but nothing an agent strictly needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must document parameters, and it does: platforms is explained with domain examples and a default ('use all platforms'), save_to_local is tied to the output directory, and include_url is explained with a token-saving rationale. This adds real semantic meaning beyond the raw JSON schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening line states a specific verb and resource: '手动触发一次爬取任务' (manually trigger a crawl task), with optional persistence. This clearly identifies it as the direct crawl-trigger action and distinguishes it from the read/analysis tools among its siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by explaining default behavior (all platforms when platforms is unspecified) and providing two examples, but it never explicitly says when to choose this tool over alternatives. No exclusions or 'use X instead' guidance is given, though the manual-trigger wording makes the basic intent reasonably inferable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 27 tool updatesv6.10.0
    • First observedaggregate_news
    • First observedanalyze_data_insights
    • First observedanalyze_sentiment
    • First observedanalyze_topic_trend
    • First observedcheck_version
    • First observedcompare_periods
    • First observedfind_related_news
    • First observedgenerate_summary_report
    • First observedget_channel_format_guide
    • First observedget_current_config
    • First observedget_latest_news
    • First observedget_latest_rss
    • First observedget_news_by_date
    • First observedget_notification_channels
    • First observedget_rss_feeds_status
    • First observedget_storage_status
    • First observedget_system_status
    • First observedget_trending_topics
    • First observedlist_available_dates
    • First observedread_article
    • First observedread_articles_batch
    • First observedresolve_date_range
    • First observedsearch_news
    • First observedsearch_rss
    • First observedsend_notification
    • First observedsync_from_remote
    • First observedtrigger_crawl

TDQS

A3.7/5.0

Scored across 27 tools

Disambiguation3/5

The tools have reasonably distinct purposes, but there is some overlap between search_news, search_rss, and get_news_by_date, as well as between get_latest_news and get_news_by_date. Also, analyze_topic_trend and analyze_data_insights both serve as umbrella analyzers, which could cause misselection despite distinct sub-modes.

Naming Consistency4/5

Most tool names follow a clear verb_noun pattern (get_, search_, analyze_, send_, etc.), with only minor deviations like resolve_date_range (verb_object) or check_version (verb_noun). The naming is generally consistent and intuitive.

Tool Count3/5

With 27 tools, the server covers a wide range of functionality (news retrieval, analysis, configuration, notifications, storage), which is somewhat heavy but justifiable given the broad scope. It is on the upper edge of the acceptable range, but not excessive.

Completeness4/5

The tool surface is quite comprehensive for a news monitoring and analysis server, covering retrieval, search, trend analysis, sentiment, aggregation, comparison, reporting, and notifications. Minor gaps include lack of direct article management or explicit data deletion, but these are not critical for the domain.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    D
    maintenance
    A real-time hotspot monitoring and news aggregation assistant that provides AI-powered analysis of trending topics across multiple platforms via the Model Context Protocol. It enables users to track news and receive automated notifications through various services like Telegram, WeChat, and Slack.
    14
    GPL 3.0
  • A
    license
    A
    quality
    Not graded
    maintenance
    An AI-powered news and trend aggregator that tracks real-time hot topics and RSS feeds with personalized filtering and summaries. It enables users to monitor global trends and receive automated reports across multiple platforms including WeChat, Telegram, and Slack.
    27
    GPL 3.0
  • A
    license
    A
    quality
    D
    maintenance
    An aggregator for real-time hot topics and news from major social and financial platforms like Zhihu, Bilibili, and Wall Street News. It features an MCP server that allows AI models to fetch and analyze trending information for automated insights.
    17
    GPL 3.0