TrendRadar MCP
Горячий помощник, разворачиваемый за 30 секунд — попрощайтесь с бесполезным скроллингом, смотрите только те новости, которые вам действительно интересны
🌐 Официальный сайт · 📖 Официальная документация
中文 | English
Цель этого проекта — лёгкость и простота развёртывания
📑 Быстрая навигация
💡 Нажмите на ссылку ниже, чтобы быстро перейти к соответствующему разделу. Для развёртывания рекомендуется начать с «Быстрого старта», а для детальной настройки — см. «Подробная конфигурация»
Спасибо всем, кто поставил star проекту. fork — то, что вы хотите, star — то, что хочу я. Получить и то, и другое 😍 — лучшая поддержка духа открытого кода
Благодарность ранним сторонникам
💡 Особое примечание:
О списке: в таблице ниже зафиксированы сторонники на начальном этапе проекта (ангельский раунд). Из-за трудоёмкости ручного подсчёта на раннем этапе возможны пропуски или неполные записи. Если кого-то пропустили — это не намеренно, просим снисхождения.
Планы на будущее: чтобы вернуть ограниченные усилия к коду и итерациям функций, с сегодняшнего дня этот список больше не ведётся вручную.
Независимо от того, есть ли ваше имя в списке, каждая ваша поддержка — это фундамент, на котором TrendRadar смог дойти до сегодняшнего дня. 🙏
Поддержка инфраструктуры
Спасибо GitHub за бесплатную инфраструктуру — это главная предпосылка, благодаря которой проект можно развернуть в один клик через fork.
Поддержка данных
Этот проект использует API проекта newsnow для получения данных с нескольких платформ. Особая благодарность автору за предоставленный сервис.
После связи автор сообщил, что беспокоиться о нагрузке на сервер не нужно, но это основано на его доброте и доверии. Просим всех:
Перейдите в проект newsnow и поставьте star в знак поддержки
При развёртывании через Docker, пожалуйста, разумно контролируйте частоту отправки, не истощайте ресурсы
Помощь в продвижении
Спасибо следующим платформам и лицам за рекомендации (в хронологическом порядке)
Нишевое ПО — платформа рекомендаций открытого ПО
Сообщество LinuxDo — место сбора технических энтузиастов
Еженедельник Жуань Ифэна — влиятельный еженедельник в техническом сообществе
Поддержка зрителей
Спасибо друзьям, оказавшим финансовую поддержку. Ваша щедрость превратилась в закуски и напитки рядом с клавиатурой, сопровождая каждую итерацию проекта.
О возвращении «лайка за один юань»: С выходом версии v5.0.0 проект вступил в новый этап. Чтобы покрыть растущие расходы на API и потребление кофеина, канал «лайк за один юань» снова открыт. Каждое ваше участие превратится в Token и движущую силу в мире кода. 🚀 Перейти к поддержке
点赞人 | 金额 | 日期 | 备注 |
D*5 | 1.8 * 3 | 2025.11.24 | |
*鬼 | 1 | 2025.11.17 | |
*超 | 10 | 2025.11.17 | |
R*w | 10 | 2025.11.17 | Крутой агент, брат |
J*o | 1 | 2025.11.17 | Спасибо за открытый код, желаю успехов в делах |
*晨 | 8.88 | 2025.11.16 | Хороший проект, изучаю |
*海 | 1 | 2025.11.15 | |
*德 | 1.99 | 2025.11.15 | |
*疏 | 8.8 | 2025.11.14 | Спасибо за открытый код, отличный проект, поддерживаю |
M*e | 10 | 2025.11.14 | Открытый код — нелёгкий труд, спасибо за работу |
**柯 | 1 | 2025.11.14 | |
*云 | 88 | 2025.11.13 | Отличный проект, спасибо за открытый код |
*W | 6 | 2025.11.13 | |
*凯 | 1 | 2025.11.13 | |
对*. | 1 | 2025.11.13 | Thanks for your TrendRadar |
s*y | 1 | 2025.11.13 | |
**翔 | 10 | 2025.11.13 | Отличный проект, жаль, что не встретил раньше, спасибо за открытый код! |
*韦 | 9.9 | 2025.11.13 | TrendRadar супер, угощаю автора кофе~ |
h*p | 5 | 2025.11.12 | Поддерживаю китайские силы открытого кода, вперёд! |
c*r | 6 | 2025.11.12 | |
a*n | 5 | 2025.11.12 | |
。*c | 1 | 2025.11.12 | Спасибо за открытый код и обмен |
*记 | 1 | 2025.11.11 | |
*主 | 1 | 2025.11.10 | |
*了 | 10 | 2025.11.09 | |
*杰 | 5 | 2025.11.08 | |
*点 | 8.80 | 2025.11.07 | Разработка — нелёгкий труд, поддерживаю. |
Q*Q | 6.66 | 2025.11.07 | Спасибо за открытый код! |
C*e | 1 | 2025.11.05 | |
Peter Fan | 20 | 2025.10.29 | |
M*n | 1 | 2025.10.27 | Спасибо за открытый код |
*许 | 8.88 | 2025.10.23 | Я новичок, несколько дней пытаюсь разобраться, но пока не получилось, прошу совета |
Eason | 1 | 2025.10.22 | Ещё не разобрался, но вы делаете доброе дело |
P*n | 1 | 2025.10.20 | |
*杰 | 1 | 2025.10.19 | |
*徐 | 1 | 2025.10.18 | |
*志 | 1 | 2025.10.17 | |
*😀 | 10 | 2025.10.16 | Лайк |
**杰 | 10 | 2025.10.16 | |
*啸 | 10 | 2025.10.16 | |
*纪 | 5 | 2025.10.14 | TrendRadar |
J*d | 1 | 2025.10.14 | Спасибо за ваш инструмент, очень интересно... |
*H | 1 | 2025.10.14 | |
那*O | 10 | 2025.10.13 | |
*圆 | 1 | 2025.10.13 | |
P*g | 6 | 2025.10.13 | |
Ocean | 20 | 2025.10.12 | ...Это просто потрясающе!!! Даже новичок может сразу использовать... |
**培 | 5.2 | 2025.10.2 | github-yzyf1312: Да здравствует открытый код |
*椿 | 3 | 2025.9.23 | Вперёд, очень хорошо |
*🍍 | 10 | 2025.9.21 | |
E*f | 1 | 2025.9.20 | |
*记 | 1 | 2025.9.20 | |
z*u | 2 | 2025.9.19 | |
**昊 | 5 | 2025.9.17 | |
*号 | 1 | 2025.9.15 | |
T*T | 2 | 2025.9.15 | Лайк |
*家 | 10 | 2025.9.10 | |
*X | 1.11 | 2025.9.3 | |
*飙 | 20 | 2025.8.31 | Спасибо от старого Туна |
*下 | 1 | 2025.8.30 | |
2*D | 88 | 2025.8.13 下午 | |
2*D | 1 | 2025.8.13 上午 | |
S*o | 1 | 2025.8.05 | Поддерживаю |
*侠 | 10 | 2025.8.04 | |
x*x | 2 | 2025.8.03 | trendRadar — хороший проект, лайк |
*远 | 1 | 2025.8.01 | |
*邪 | 5 | 2025.8.01 | |
*梦 | 0.1 | 2025.7.30 | |
**龙 | 10 | 2025.7.29 | Поддерживаю |
Related MCP server: TrendRadar
🪄 Спонсор
Всё в одном месте: собственная модель Doubao от ByteDance и полные версии популярных открытых SOTA-моделей, полностью покрывающие мультимодальные возможности: текст, визуальное понимание (VLM), генерацию изображений и другое. Популярные модели Seed-2.1, Seedream 5.0, GLM-5.2, DeepSeek и другие — всё в одном месте. Не только эффективное программирование, но и сложные длительные агентные задачи.
❤️ Нравится? Поддержите
Если TrendRadar когда-либо принёс вам пользу, вдохните в него энергию, чтобы он продолжал развиваться
Сумма произвольная, даже 1 юань — это поддержка открытого кода. Приветствуются комментарии при поддержке (´▽`ʃ♡ƪ)
微信赞赏 (WeChat Donate) | 支付宝赞赏 (Alipay Donate) |
🤝 Вторичная разработка и использование
Если вы используете или заимствуете идеи и основной код этого проекта в своём проекте, очень приветствуется указание источника в README или документации со ссылкой на этот репозиторий.
Это поможет поддержанию проекта и развитию сообщества. Спасибо за ваше уважение и поддержку! ❤️
💬 Общение и обратная связь
GitHub Issues: подходит для конкретных технических вопросов. При обращении, пожалуйста, предоставляйте полную информацию (скриншоты, логи ошибок и т.д.) — это поможет быстрее найти решение.
Общение через официальный аккаунт: рекомендуется общаться в комментариях под соответствующими статьями. Если нужно задать вопрос через бэкенд, сначала поставьте лайк/рекомендацию статье — это лучший «ключ» к двери, я чувствую эту доброту в бэкенде (´▽`ʃ♡ƪ).
Общение в QQ-группе: подпишитесь на официальный аккаунт и ответьте «交流群» (группа общения), чтобы присоединиться. Независимо от того, новичок вы в AI или опытный разработчик, хотите ли вы задать технический вопрос или поделиться опытом — здесь вам рады. В группе основной упор на взаимопомощь и обмен идеями; при вступлении, пожалуйста, сначала прочитайте объявление группы; при вопросах описывайте проблему чётко и прикрепляйте скриншоты — участники помогут, когда будут свободны, их практический опыт часто быстрее и полнее моего 🤝
Дружеский совет: Этот проект — открытый исходный код для обмена, а не коммерческий продукт. Относитесь к автору как к другу, а не как к службе поддержки — так общение будет эффективнее!
Подписка на официальный аккаунт |
📝 Журнал обновлений
📌 Последние обновления: Журнал обновлений оригинального репозитория :
Подсказка: рекомендуется просматривать 【Историю обновлений】, чтобы уточнить конкретные 【функциональные возможности】
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 для проверки версии: интерфейс проверки версии поддерживает автоматический откат между несколькими CDN-источниками GitHub → jsDelivr → Cloudflare и другими, что обеспечивает стабильное получение уведомлений об обновлениях даже в китайских сетях
Применение переключателей областей отображения: HTML-отчёты и email теперь корректно учитывают переключатели
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 автоматически извлечёт теги и оценит каждую новость, отправляя только действительно релевантный вам контент. Если AI-фильтрация даст сбой, автоматически произойдёт откат к сопоставлению по ключевым словам — рассылка не прервётсяРазные способы фильтрации и направления интересов для каждого временного интервала: каждый временной интервал в Timeline теперь может независимо настраивать способ фильтрации и тип просматриваемых новостей. Например: утром — быстрая фильтрация по «технологическим ключевым словам», вечером — глубокая фильтрация по «описанию интересов в финансовом AI» — одна система, разные интервалы — разный контент
Область 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Гибкая настройка временных интервалов: поддержка различий между рабочими днями и выходными, интервалов через полночь, дедупликации per-period once
Визуальный редактор конфигурации:
Добавлена вкладка редактирования
timeline.yaml, рядом с config.yaml / frequency_words.txtВыбор карточек шаблонов: переключение одним кликом, автоматическая синхронизация с
schedule.presetв config.yamlНедельное представление временной шкалы: горизонтальные полосы 7 дней × 24 часа, цветом различаются статусы отправки/анализа/сбора
Интерактивные элементы управления: переключатели, выпадающие списки, выбор времени; изменения справа синхронизируются с YAML слева в реальном времени
Выпадающий выбор недельного сопоставления: динамическое заполнение на основе дневного плана, перетаскивание и клики для завершения настройки расписания
Оптимизация стабильности AI-промпта (ai_analysis_prompt.txt v2.0.0):
Отдельное описание спецификации формата: правила переносов строк/тегов/нумерации/запретов вынесены из JSON value в отдельный раздел
Упрощён JSON-шаблон: описания полей сокращены до одного предложения + ограничение по количеству символов, уменьшена путаница в формате вывода AI
Убран Markdown-формат из system prompt, согласовано с инструкцией «запрет Markdown»
Все JSON-поля объявлены необязательными; отсутствие любого поля не вызывает ошибку — повышена отказоустойчивость
Новое: сводный AI-анализ отдельных секций отображения (
ai_analysis.include_standalone):Добавлен отдельный переключатель: при включении AI генерирует краткую сводку для каждого standalone-источника
Развязка 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-chatOpenAI:
openai/gpt-4oGemini:
gemini/gemini-2.5-flashAnthropic:
anthropic/claude-3-5-sonnet
2026/01/17 - v5.2.0
В основном см. описание в config.yaml
🌐 Функция AI-перевода
Многоязычный перевод: поддержка перевода содержимого рассылки на любой язык
Пакетный перевод: умная пакетная обработка, уменьшение количества вызовов API
Пользовательские промпты: поддержка настройки стиля перевода
🔧 Оптимизация архитектуры конфигурации
Независимая конфигурация AI-модели: анализ и перевод используют общую конфигурацию модели
Унификация переключателей областей: единое управление отображением областей рассылки
Пользовательская сортировка областей: поддержка настройки порядка отображения областей
✨ Улучшение AI-анализа
Встраивание AI-анализа в HTML: результаты анализа напрямую встраиваются в HTML-отчёт, используются в email-уведомлениях
Богато стилизованный AI-блок: карточная раскладка с градиентным синим фоном, чёткое разделение измерений анализа
Поддержка временной шкалы рейтинга: AI может получать точный рейтинг каждой новости в каждый момент сбора
Реорганизация секций (7→4): объединено в «Основная динамика горячих тем», «Общественное мнение и споры», «Аномалии и слабые сигналы», «Рекомендации по стратегии анализа»
🔧 Адаптация нескольких моделей
Прозрачная передача общих параметров: поддержка передачи любых расширенных параметров в API
Адаптация Gemini: нативная поддержка параметров, встроенное смягчение политик безопасности
🐛 Исправление ошибок
Исправлены некоторые известные проблемы, повышена стабильность системы
2026/01/10 - v5.0.0
Забавный эпизод разработки: Отдаю дань уважения той модели от компании C, которая сопровождала меня более двух лет, но сразу после продления подписки показала
"This organization has been disabled"
✨ Рефакторинг «пяти основных секций» содержимого рассылки
В этом обновлении проведена секционная реструктуризация сообщений рассылки. Теперь содержимое рассылки чётко разделено на пять основных секций:
📊 Горячие новости: агрегированные горячие темы со всей сети, отфильтрованные по вашим ключевым словам.
📰 RSS-подписки: содержимое ваших персонализированных источников подписки, с группировкой по ключевым словам.
🆕 Новое за этот раз: новые горячие темы, обнаруженные в реальном времени с момента последнего запуска (с пометкой 🆕).
📋 Отдельная секция отображения: полный горячий список указанной платформы или RSS-источника, полностью не ограничен фильтрацией по ключевым словам.
✨ Секция 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
🎉 Улучшение основных функций
Поддержка рассылки на несколько аккаунтов
Все каналы рассылки (Feishu, DingTalk, WeCom, Telegram, ntfy, Bark, Slack) поддерживают настройку нескольких аккаунтов
Используйте точку с запятой
;для разделения нескольких аккаунтов, например:FEISHU_WEBHOOK_URL=url1;url2Автоматическая проверка согласованности количества парных конфигураций (например, token и chat_id для Telegram)
Конфигурация областей рассылки
Через
display.region_orderнастраивается порядок отображения областей (в v5.2.0 заменяет прежнийreverse_content_order)Через
display.regionsуправляется отображение каждой области (горячие списки, новые горячие темы, RSS, отдельная секция отображения, AI-анализ)
Глобальные фильтрующие ключевые слова
Добавлена метка области
[GLOBAL_FILTER], поддерживающая глобальную фильтрацию нежелательного контентаСценарии применения: фильтрация рекламы, маркетинга, низкокачественного контента и т.д.
🐳 Оптимизация генерации HTML по двум путям в Docker
Исправление проблемы: решена проблема невозможности синхронизации
index.htmlна хост-машину в среде DockerГенерация по двум путям: ежедневный сводный HTML генерируется в двух местах
index.html(корень проекта): для доступа через GitHub Pagesoutput/index.html: монтируется через Docker Volume, доступен напрямую с хост-машины
Совместимость: обеспечен нормальный доступ к веб-версии отчёта в средах Docker, GitHub Actions и локального запуска
🐳 Поддержка Docker-образа MCP
新增独立的 MCP 服务镜像
wantcat/trendradar-mcp支持 Docker 部署 AI 分析功能,通过 HTTP 接口(端口 3333)提供服务
双容器架构:新闻推送服务与 MCP 服务独立运行,可分别扩展和重启
🌐 支持 Web 服务器
新增内置 Web 服务器,支持通过浏览器访问生成的报告
通过
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
🔧 格式优化
Bark 推送增强
Bark 现支持 Markdown 渲染
启用原生 Markdown 格式:粗体、链接、列表、代码块等
移除纯文本转换,充分利用 Bark 原生渲染能力
Slack 格式精准化
使用专用 mrkdwn 格式处理分批内容
提升字节大小估算准确性(避免消息超限)
优化链接格式:
<url|text>和加粗语法:*text*
性能提升
格式转换在分批过程中完成,避免二次处理
准确估算消息大小,减少发送失败率
🔧 升级说明:
GitHub Fork 用户:更新
main.py,config.yaml
2025/11/25 - v3.4.0
🎉 新增 Slack 推送支持
团队协作推送渠道
支持 Slack Incoming Webhooks(全球流行的团队协作工具)
消息集中管理,适合团队共享热点资讯
支持 mrkdwn 格式(粗体、链接等)
多种部署方式
GitHub Actions:配置
SLACK_WEBHOOK_URLSecretDocker:环境变量
SLACK_WEBHOOK_URL本地运行:
config/config.yaml配置文件
📖 详细配置教程:快速开始 - Slack 推送
优化 setup-windows.bat 和 setup-windows-en.bat 一键安装 MCP 的体验
🔧 升级说明:
GitHub Fork 用户:更新
main.py、config/config.yaml、.github/workflows/crawler.yml
2025/11/24 - v3.3.0
🎉 新增 Bark 推送支持
iOS 专属推送渠道
支持 Bark 推送(基于 APNs,iOS 平台)
免费开源,简洁高效,无广告干扰
支持官方服务器和自建服务器两种方式
多种部署方式
GitHub Actions:配置
BARK_URLSecretDocker:环境变量
BARK_URL本地运行:
config/config.yaml配置文件
📖 详细配置教程:快速开始 - Bark 推送
🐛 Bug 修复
修复
config.yaml中ntfy_server_url配置不生效的问题 (#345)
🔧 升级说明:
GitHub Fork 用户:更新
main.py、config/config.yaml、.github/workflows/crawler.yml
2025/11/23 - v3.2.0
🎯 新增高级定制功能
关键词排序优先级配置
支持两种排序策略:热度优先 vs 配置顺序优先
满足不同使用场景:热点追踪 or 个性化关注
显示数量精准控制
全局配置:统一限制所有关键词显示数量
单独配置:使用
@数字语法为特定关键词设置限制有效控制推送长度,突出重点内容
📖 详细配置教程:关键词配置 - 高级配置
🔧 升级说明:
GitHub Fork 用户:更新
main.py、config/config.yaml
2025/11/18 - mcp-v1.0.2
MCP 模块更新:
优化查询今日新闻却可能错误返回过去日期的情况
2025/11/22 - v3.1.1
修复数据异常导致的崩溃问题:解决部分用户在 GitHub Actions 环境中遇到的
'float' object has no attribute 'lower'错误新增双重防护机制:在数据获取阶段过滤无效标题(None、float、空字符串),同时在函数调用处添加类型检查
提升系统稳定性,确保在数据源返回异常格式时仍能正常运行
升级说明(GitHub Fork 用户):
必须更新:
main.py建议使用小版本升级方式:复制替换上述文件
2025/11/20 - v3.1.0
新增个人微信推送支持:企业微信应用可推送到个人微信,无需安装企业微信 APP
支持两种消息格式:
markdown(企业微信群机器人)和text(个人微信应用)新增
WEWORK_MSG_TYPE环境变量配置,支持 GitHub Actions、Docker、docker compose 等多种部署方式text模式自动清除 Markdown 语法,提供纯文本推送效果详见快速开始中的「个人微信推送」配置说明
升级说明(GitHub Fork 用户):
必须更新:
main.py、config/config.yaml可选更新:
.github/workflows/crawler.yml(如使用 GitHub Actions 部署)建议使用小版本升级方式:复制替换上述文件
2025/11/12 - v3.0.5
修复邮件发送 SSL/TLS 端口配置逻辑错误
优化邮箱服务商(QQ/163/126)默认使用 465 端口(SSL)
新增 Docker 环境变量支持:核心配置项(
enable_crawler、report_mode、push_window等)支持通过环境变量覆盖,解决 NAS 用户修改配置文件不生效的问题(详见 🐳 Docker 部署 章节)
2025/10/26 - mcp-v1.0.1
MCP 模块更新:
修复日期查询参数传递错误
统一所有工具的时间参数格式
2025/10/31 - v3.0.4
解决飞书因推送内容过长而产生的错误,实现了分批推送
2025/10/23 - v3.0.3
扩大 ntfy 错误信息显示范围
2025/10/21 - v3.0.2
修复 ntfy 推送编码问题
2025/10/20 - v3.0.0
重大更新 - AI 分析功能上线 ✨
核心功能:
新增基于 MCP (Model Context Protocol) 的 AI 分析服务器
支持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 识别:自动识别 Gmail、QQ邮箱、Outlook、网易邮箱等 10+ 种邮箱服务商配置
HTML 精美格式:邮件内容采用与网页版相同的 HTML 格式,排版精美,移动端适配
批量发送支持:支持多个收件人,用逗号分隔即可同时发送给多人
自定义 SMTP:可自定义 SMTP 服务器和端口
修复Docker构建网络连接问题
使用说明:
适用场景:适合需要邮件归档、团队分享、定时报告的用户
支持邮箱:Gmail、QQ邮箱、Outlook/Hotmail、163/126邮箱、新浪邮箱、搜狐邮箱等
更新提示:
此次更新的内容比较多,如果想升级,建议采用【大版本升级】
2025/09/17 - v2.2.0
新增一键保存新闻图片功能,让你轻松分享关注的热点
使用说明:
适用场景:当你按照教程开启了网页版功能后(GitHub Pages)
使用方法:用手机或电脑打开该网页链接,点击页面顶部的"保存为图片"按钮
实际效果:系统会自动将当前的新闻报告制作成一张精美图片,保存到你的手机相册或电脑桌面
分享便利:你可以直接把这张图片发给朋友、发到朋友圈,或分享到工作群,让别人也能看到你发现的重要资讯
2025/09/13 - v2.1.2
解决钉钉的推送容量限制导致的新闻推送失败问题(采用分批推送)
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,不要公开,不要公开,不要公开
如果你以 fork 的方式将本项目部署在 GitHub 上,请将 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
修复问题:
docker 的 shell 脚本的换行符为 CRLF 导致的执行异常问题
frequency_words.txt 为空时,导致新闻发送也为空的逻辑问题
修复后,当你选择 frequency_words.txt 为空时,将推送所有新闻,但受限于消息推送大小限制,请做如下调整
方案一:关闭手机推送,只选择 Github Pages 布置(这是能获得最完整信息的方案,将把所有平台的热点按照你自定义的热搜算法进行重新排序)
方案二:减少推送平台,优先选择企业微信或Telegram,这两个推送我做了分批推送功能(因为分批推送影响推送体验,且只有这两个平台只给一点点推送容量,所以才不得已做了分批推送功能,但至少能保证获得的信息完整)
方案三:可与方案二结合,模式选择 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
功能新增:增加增量推送(在 main.py 头部配置 FOCUS_NEW_ONLY),该开关只关心新话题而非持续热度,只在有新内容时才发通知。
修复问题: 某些情况下,由于新闻本身含有特殊符号导致的偶发性排版异常。
2025/06/23 - v1.3.0
企业微信 和 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 ,让我快速完成各平台适配(虽然代码更多冗余了~
支持 telegram ,企业微信,钉钉推送渠道, 支持多渠道配置和同时推送
2025/06/18 - v1.1.0
200 star⭐ 了, 继续给大伙儿助兴~近期,在我的"怂恿"下,挺多人在我公众号点赞分享推荐助力了我,我都在后台看见了具体账号的鼓励数据,很多都成了天使轮老粉(我玩公众号才一个多月,虽然注册是七八年前的事了哈哈,属于上车早,发车晚),但因为你们没有留言或私信我,所以我也无法一一回应并感谢支持,在此一并谢谢!
重要的更新,加了权重,你现在看到的新闻都是最热点最有关注度的出现在最上面
更新文档使用,因为近期更新了很多功能,而且之前的使用文档我偷懒写的简单(见下面的 ⚙️ frequency_words.txt 配置完整教程)
2025/06/16 - v1.0.0
增加了一个项目新版本更新提示,默认打开,如要关掉,可以在 main.py 中把 "FEISHU_SHOW_VERSION_UPDATE": True 中的 True 改成 False 即可
2025/06/13+14
去掉了兼容代码,之前 fork 的同学,直接复制代码会在当天显示异常(第二天会恢复正常)
feishu 和 html 底部增加一个新增新闻显示
2025/06/09
100 star⭐ 了,写个小功能给大伙儿助助兴 frequency_words.txt 文件增加了一个【必须词】功能,使用 + 号
必须词语法如下:
唐僧或者猪八戒必须在标题里同时出现,才会收录到推送新闻中
+唐僧
+猪八戒过滤词的优先级更高:
如果标题中过滤词匹配到唐僧念经,那么即使必须词里有唐僧,也不显示
+唐僧
!唐僧念经2025/06/02
网页和飞书消息支持手机直接跳转详情新闻
优化显示效果 + 1
2025/05/26
飞书消息显示效果优化
✨ 核心功能
全网热点聚合
知乎
抖音
bilibili 热搜
华尔街见闻
贴吧
百度热搜
财联社热门
澎湃新闻
凤凰网
今日头条
微博
默认监控 11 个主流平台,也可自行增加额外的平台
💡 详细配置教程见 配置详解 - 平台配置
RSS 订阅源支持(v4.5.0 新增)
支持 RSS/Atom 订阅源抓取,按关键词分组统计(与热榜格式一致):
统一格式:RSS 与热榜使用相同的关键词匹配和显示格式
简单配置:直接在
config.yaml中添加 RSS 源合并推送:热榜和 RSS 合并为一条消息推送
新鲜度过滤:自动过滤超过指定天数的旧文章,避免重复推送。支持全局默认天数和单源独立设置
💡 RSS 使用与热榜相同的
frequency_words.txt进行关键词过滤
可视化配置编辑器
提供基于 Web 的图形化配置界面,无需手动编辑 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 |
内容顺序配置 | 通过 | 见配置文件 |
显示模式切换 |
| keyword |
精准内容筛选
设置个人关键词(如:AI、比亚迪、教育政策),只推送相关热点,过滤无关信息
💡 基础配置教程:关键词配置 - 基础语法
💡 高级配置教程:关键词配置 - 高级配置
💡 也可以不做筛选,完整推送所有热点(将 frequency_words.txt 留空)
AI 智能筛选新闻(v6.5.0 新增)
用自然语言描述你的兴趣,AI 自动分类新闻,替代传统关键词匹配
Описание интересов на естественном языке: в
ai_interests.txtзапишите интересующие вас направления повседневным языком, без необходимости изучать синтаксис ключевых словДвухэтапная интеллектуальная обработка: ИИ сначала извлекает структурированные теги из описания интересов, затем пакетно классифицирует и оценивает новости по тегам
Управление порогом оценки: с помощью
ai_filter.min_scoreточно контролируйте качество推送,推送 только новости с высокой релевантностьюАвтоматический откат: при сбое ИИ-фильтрации автоматически выполняется откат к сопоставлению по ключевым словам, обеспечивая бесперебойную推送
Интеллектуальное обновление тегов: при изменении интересов ИИ автоматически оценивает масштаб изменений и решает, выполнять инкрементальную или полную переклассификацию
Гибкое переключение:
filter.methodподдерживает два режима —keyword(по умолчанию) иai, Timeline может переопределять по временным интерваламПерсонализация по времени: в разные временные интервалы можно использовать разные файлы ключевых слов или описания интересов для ИИ. Например, утром использовать «технологический словарь» для быстрой фильтрации, а вечером — «финансовые интересы» для глубокой ИИ-фильтрации
# config.yaml 快速启用示例
filter:
method: ai # keyword(默认)| ai
ai_filter:
min_score: 6 # 推送最低分数阈值(1-10)💡 ИИ-фильтрация и ИИ-анализ/перевод используют общую конфигурацию модели, достаточно один раз настроить
ai.api_key
Анализ трендов горячих тем
Отслеживание изменений популярности новостей в реальном времени, чтобы вы знали не только «что в тренде», но и «как развивается тренд»
Отслеживание по временной шкале: запись полного временного интервала от первого появления каждой новости до последнего
Изменение популярности: статистика изменения рейтинга и частоты появления новостей в разные периоды времени
Обнаружение новых тем: выявление новых горячих тем в реальном времени, мгновенное уведомление с пометкой 🆕
Анализ устойчивости: различие между разовыми горячими темами и глубокими новостями, которые продолжают развиваться
Сравнение между платформами: рейтинг одной и той же новости на разных платформах, чтобы увидеть различия во внимании СМИ
💡 Описание формата推送 см. в Описание формата сообщений
Персонализированный алгоритм горячих тем
Больше не нужно следовать за алгоритмами разных платформ — TrendRadar заново систематизирует горячие темы по всему интернету
💡 Три соотношения можно настраивать, подробнее см. Подробная конфигурация — Настройка весов горячих тем
Многоканальная推送 на несколько аккаунтов
Поддержка WeChat Work (+ схема推送 в личный WeChat), Feishu, DingTalk, Telegram, Email, ntfy, Bark, Slack, универсальный Webhook (можно подключить Discord, IFTTT и любые другие платформы) — сообщения доставляются прямо на телефон и почту
💡 Подробные инструкции по настройке см. в 推送 на несколько групп/устройств
ИИ-перевод на несколько языков (новое в v5.2.0)
Перевод推送-контента на любой язык, устраняя языковые барьеры — будь то чтение внутренних горячих тем или подписка на зарубежные новости через RSS, всё доступно на родном языке
Перевод в один клик: установите
ai_translation.enabled: trueи целевой язык вconfig.yamlПоддержка нескольких языков: поддерживаются English, Korean, Japanese, French и любые другие языки
Интеллектуальная пакетная обработка: автоматическая пакетная обработка перевода, сокращение количества вызовов API и экономия средств
Настраиваемый стиль: настройте стиль перевода и терминологию через
ai_translation_prompt.txtОбщая конфигурация модели: использует общие настройки модели из секции
aiс функцией ИИ-анализа
# config.yaml 快速启用示例
ai_translation:
enabled: true
language: "English" # 翻译目标语言💡 Функция перевода и функция ИИ-анализа используют общую конфигурацию модели — достаточно один раз настроить
ai.api_key, чтобы использовать обе функции
Справочник по RSS-источникам: ниже приведены подборки RSS-каналов, которые можно использовать по мере необходимости
awesome-tech-rss — блоги и СМИ о технологиях, стартапах и программировании
awesome-rss-feeds — подборка RSS-каналов ведущих мировых новостных СМИ
⚠️ Некоторые зарубежные материалы могут затрагивать чувствительные темы, и ИИ-модель может отказаться переводить их. Рекомендуется отбирать источники в соответствии с реальными потребностями
Расширение браузера для HTML-отчётов (новое в v6.6.0)
При открытии推送 HTML-отчёта в браузере автоматически активируется расширенный режим (почтовые клиенты не затрагиваются):
Широкоэкранный режим: на десктопе автоматически переключается на макет шириной 1200px, максимально используя пространство экрана
Быстрое переключение вкладок: группы ключевых слов и отдельные секции поддерживают навигацию по вкладкам, избавляя от прокрутки длинных страниц
Тёмный режим: переключение на тёмную тему в один клик, автоматическое запоминание предпочтений
Поиск в реальном времени: нажмите
/для вызова строки поиска, мгновенная фильтрация заголовков новостейКопирование в один клик: наведите курсор на номер новости, чтобы скопировать заголовок и ссылку
Горячие клавиши:
W— широкий экран,D— тёмный режим,/— поиск,?— просмотр всех горячих клавиш
💡 Все расширенные функции основаны на прогрессивном улучшении — почтовые клиенты по-прежнему отображают исходный макет 600px, без регрессий
Гибкая архитектура хранения (крупное обновление v4.0.0)
Поддержка нескольких бэкендов хранения:
Удалённое облачное хранилище: по умолчанию в среде GitHub Actions, поддержка протокола, совместимого с S3 (R2/OSS/COS и т.д.), данные хранятся в облаке, не загрязняя репозиторий
Локальная база данных SQLite: по умолчанию в Docker/локальной среде, полный контроль над данными
Автоматический выбор бэкенда: интеллектуальное переключение способа хранения в зависимости от среды выполнения
💡 Подробное описание см. в Где хранятся данные?
Развёртывание на нескольких платформах
GitHub Actions: автоматический сбор по расписанию + удалённое облачное хранилище (требуется периодическое продление)
Docker: поддержка многоплатформенных контейнеров, локальное хранение данных
Локальный запуск: запуск напрямую на Windows/Mac/Linux
ИИ-анализ и推送 (новое в v5.0.0)
Использование больших ИИ-моделей для глубокого анализа推送-контента, автоматическая генерация отчётов об анализе горячих тем
Интеллектуальный анализ: автоматический анализ трендов горячих тем, популярности ключевых слов, межплатформенных связей, потенциального влияния
Несколько провайдеров: на основе единого интерфейса LiteLLM, поддержка 100+ ИИ-провайдеров (DeepSeek, OpenAI, Gemini, Anthropic, локальный Ollama и т.д.), а также автоматическое переключение на резервные модели
Независимый режим анализа: область анализа ИИ может отличаться от推送 —推送 отправляет только новые сообщения (чтобы не беспокоить), но ИИ может анализировать все новости за день (для полной картины трендов)
Гибкая推送: можно выбрать только исходный контент, только ИИ-анализ или оба варианта
Настраиваемые промпты: настройка угла анализа через
config/ai_analysis_prompt.txt
💡 Подробные инструкции по настройке см. в Позвольте ИИ анализировать горячие темы
Отдельная область отображения (новое в v5.0.0)
Полное отображение горячих рейтингов для указанных платформ, не зависящее от фильтрации по ключевым словам
Полный рейтинг: полное отображение горячих рейтингов указанных платформ, подходит для пользователей, желающих видеть полный рейтинг
Отдельное отображение RSS: контент RSS-источников может отображаться полностью, без ограничений по ключевым словам
Глубокий ИИ-анализ: можно независимо включить ИИ-анализ трендов полного рейтинга, без необходимости отображать его в推送
Гибкая настройка: поддержка настройки отображаемых платформ, RSS-источников, максимального количества записей
💡 Подробные инструкции по настройке см. в Как отображается推送-контент? — Отдельная область отображения
ИИ-интеллектуальный анализ (новое в v3.0.0)
Система диалогового анализа на основе протокола MCP (Model Context Protocol), позволяющая глубоко анализировать новостные данные на естественном языке
💡 Совет по использованию: для ИИ-функций требуются локальные новостные данные
Проект включает тестовые данные, можно сразу опробовать функции
Рекомендуется самостоятельно развернуть и запустить проект для получения более актуальных данных
Подробнее см. ИИ-интеллектуальный анализ
Веб-развёртывание
После запуска в корневом каталоге создаётся 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 (значение) |
| API Token, созданный на предыдущем шаге |
| Ваш Cloudflare Account ID |
| Имя проекта Cloudflare Pages (например, |
После настройки следующий запуск GitHub Actions автоматически выполнит развёртывание, адрес доступа: https://<имя_проекта>.pages.dev.
💡 Примечание: если отсутствует любой из трёх Secrets, развёртывание Cloudflare будет автоматически пропущено, это не повлияет на другие функции, такие как推送 новостей; для привязки собственного домена настройте его в разделе Custom domains проекта Pages.
Снижение зависимости от приложений
Переход от «заложника алгоритмических рекомендаций» к «активному получению нужной информации»
Для кого: инвесторы, блогеры, PR-специалисты компаний, обычные пользователи, интересующиеся текущими событиями
Типичные сценарии: мониторинг фондового рынка, отслеживание репутации бренда, наблюдение за отраслевыми событиями, получение жизненной информации
Веб-эффект (эффект推送 на почту) | Эффект推送 в Feishu | Эффект ИИ-анализа推送 |
|
|
|
🚀 Быстрый старт
Напоминание: рекомендуется сначала просмотреть последнюю официальную документацию, чтобы убедиться, что шаги настройки актуальны.
Выберите подходящий способ развёртывания
Ⓐ Вариант 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, ручная установка Python не требуется
Пользователи Windows также могут дважды щёлкнуть
setup-windows.batдля установки зависимостей в один кликПользователи Mac могут использовать
bash setup-mac.shПеред запуском отредактируйте
config/config.yaml, заполнив каналы推送 и другие настройки, следуя базовому процессу настройки ниже
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 вашего бота WeChat Work
Шаги настройки бота:
Настройка на мобильном устройстве:
Откройте приложение WeChat Work → войдите в целевой внутренний групповой чат
Нажмите кнопку «…» в правом верхнем углу → выберите «推送 сообщений»
Нажмите «Добавить» → введите имя «TrendRadar»
Скопируйте адрес Webhook, нажмите «Сохранить», скопированное содержимое настройте в GitHub Secret выше
Процесс настройки на ПК аналогичен
Поскольку эта схема основана на плагинном механизме WeChat Work, формат推送 — обычный текст (без markdown-форматирования), но сообщения доставляются напрямую в личный WeChat, без установки приложения WeChat Work.
Конфигурация GitHub Secret (⚠️ Name должен строго совпадать):
Name (имя):
WEWORK_WEBHOOK_URL(скопируйте и вставьте это имя, не вводите вручную)Secret (значение): адрес Webhook вашего приложения WeChat Work
Name (имя):
WEWORK_MSG_TYPE(скопируйте и вставьте это имя, не вводите вручную)Secret (значение):
text
Шаги настройки:
Завершите настройку Webhook бота WeChat Work выше
Добавьте Secret
WEWORK_MSG_TYPE, значение —textСледуйте инструкциям на изображении ниже, чтобы привязать личный WeChat
После настройки приложение WeChat Work на телефоне можно удалить
Пояснение:
Используется тот же адрес Webhook, что и для бота WeChat Work
Разница в формате сообщения:
text— обычный текст,markdown— форматированный текст (по умолчанию)Обычный текстовый формат автоматически удаляет весь markdown-синтаксис (жирный шрифт, ссылки и т.д.)
Внимание: прежний «Помощник бота Feishu (BotBuilder)» будет отключён 30 июня 2026 года. Используйте способ настраиваемого бота группы ниже. Существующие webhook-адреса BotBuilder станут недействительными, потребуется перенастройка.
При включённом ИИ-анализе推送 Feishu может иногда (примерно в 5% случаев) задерживаться на несколько минут (предположительно из-за проверки соответствия ИИ-сгенерированного контента платформой).
Конфигурация GitHub Secret (⚠️ Name должен строго совпадать):
Name (имя):
FEISHU_WEBHOOK_URL(скопируйте и вставьте это имя, не вводите вручную)Secret (значение): адрес Webhook вашего настраиваемого бота Feishu (формат:
https://open.feishu.cn/open-apis/bot/v2/hook/xxxxxxxxx)
Шаги настройки:
Войдите в целевую группу, нажмите кнопку Ещё в правом верхнем углу группы и выберите Настройки.

В интерфейсе Настройки справа нажмите Боты группы.

В интерфейсе Боты группы нажмите Добавить бота.
В диалоговом окне Добавить бота найдите и нажмите Настраиваемый бот.

Настройте аватар, имя (например, «TrendRadar мониторинг горячих тем») и описание настраиваемого бота, затем нажмите Добавить.

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

Настройте скопированный Webhook-адрес в
FEISHU_WEBHOOK_URLв GitHub Secrets.
💡 После настройки вы можете нажать на изображение бота справа от имени группы, чтобы перейти на страницу сведений о настраиваемом боте и управлять конфигурацией.
📖 Официальная документация: Руководство по использованию настраиваемого бота
Конфигурация GitHub Secret (⚠️ Name должен строго совпадать):
Name (имя):
DINGTALK_WEBHOOK_URL(скопируйте и вставьте это имя, не вводите вручную)Secret (значение): адрес Webhook вашего бота DingTalk
Шаги настройки бота:
Создание бота (только на ПК):
Откройте клиент DingTalk на ПК, войдите в целевой групповой чат
Нажмите значок настроек группы (⚙️) → прокрутите вниз, найдите «Боты» и нажмите
Выберите «Добавить бота» → «Настраиваемый»
Настройка бота:
Укажите имя бота
Настройки безопасности:
Настраиваемое ключевое слово: укажите «热点»
Завершение настройки:
Отметьте условия обслуживания → нажмите «Готово»
Скопируйте полученный Webhook URL
Настройте URL в
DINGTALK_WEBHOOK_URLв GitHub Secrets
Примечание: на мобильном устройстве можно только получать сообщения, создавать новых ботов нельзя.
Конфигурация GitHub Secret (⚠️ Name должен строго совпадать):
Name (имя):
TELEGRAM_BOT_TOKEN(скопируйте и вставьте это имя, не вводите вручную)Secret (значение): токен вашего Telegram Bot
Name (имя):
TELEGRAM_CHAT_ID(скопируйте и вставьте это имя, не вводите вручную)Secret (значение): ваш Telegram Chat ID
Пояснение: для Telegram необходимо настроить два Secret, добавьте их, нажав кнопку «New repository secret» дважды
Шаги настройки бота:
Создание бота:
В Telegram найдите
@BotFather(обратите внимание на регистр, у официального есть синий значок галочки и надпись типа 37849827 monthly users; существуют поддельные аккаунты, будьте внимательны)Отправьте команду
/newbotдля создания нового ботаУкажите имя бота (должно заканчиваться на «bot», имена часто повторяются, поэтому придётся придумывать разные варианты)
Получите Bot Token (формат:
123456789:AAHfiqksKZ8WmR2zSjiQ7_v4TMAKdiHm9T0)
Получение Chat ID:
Способ 1: через официальный API
Сначала отправьте сообщение своему боту
Перейдите по адресу:
https://api.telegram.org/bot<ваш Bot Token>/getUpdatesВ возвращённом JSON найдите число в
"chat":{"id":число}
Способ 2: с помощью стороннего инструмента
Найдите
@userinfobotи отправьте/startПолучите ваш пользовательский ID в качестве Chat ID
Настройка в GitHub:
TELEGRAM_BOT_TOKEN: укажите Bot Token, полученный на шаге 1TELEGRAM_CHAT_ID: укажите Chat ID, полученный на шаге 2
Примечание: чтобы предотвратить злоупотребление массовой рассылкой, при текущей массовой рассылке все получатели видят адреса электронной почты друг друга.
Если у вас нет опыта настройки подобной отправки с почтового ящика, не рекомендуется пробовать
⚠️ Важная зависимость конфигурации: для推送 на почту требуется HTML-файл отчёта. Убедитесь, что
storage.formats.htmlвconfig/config.yamlустановлен в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 (можно оставить пустым, система определит автоматически)
Пояснение: для推送 на почту необходимо настроить как минимум 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 |
189 Почта | 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 за предоставление конфигурации почты 189.cn и проведение теста отправки/получения (#291)
Благодарим @longzhenren за предоставление конфигурации Alibaba Cloud почты (aliyun.com) и проведение теста (#344)
Благодарим @ACANX за предоставление конфигурации Yandex почты (yandex.com) и проведение теста (#663)
Благодарим @Sleepy-Tianhao за предоставление конфигурации iCloud почты (icloud.com) и проведение теста (#728)
Настройка распространённых почтовых сервисов:
QQ Почта:
Войдите в веб-версию QQ Почты → Настройки → Аккаунт
Включите службу POP3/SMTP
Сгенерируйте код авторизации (16-значный)
В
EMAIL_PASSWORDукажите код авторизации, а не пароль QQ
Gmail:
Включите двухэтапную проверку
Сгенерируйте пароль приложения
В
EMAIL_PASSWORDукажите пароль приложения
163/126 Почта:
Войдите в веб-версию → Настройки → POP3/SMTP/IMAP
Включите службу SMTP
Установите код авторизации клиента
В
EMAIL_PASSWORDукажите код авторизации
Расширенная настройка: Если автоматическое определение не сработало, можно настроить SMTP вручную:
EMAIL_SMTP_SERVER: например, smtp.gmail.comEMAIL_SMTP_PORT: например, 587 (TLS) или 465 (SSL)
Если несколько получателей (обратите внимание: разделяются запятой на английском):
EMAIL_TO="user1@example.com,user2@example.com,user3@example.com"
Два способа использования:
Способ 1: Бесплатное использование (рекомендуется новичкам) 🆓
Особенности:
✅ Без регистрации аккаунта — можно использовать сразу
✅ 250 сообщений в день (достаточно для 90% пользователей)
✅ Название Topic — это и есть «пароль» (нужно выбрать трудноподбираемое название)
⚠️ Сообщения не шифруются, не подходят для конфиденциальной информации, но подходят для нечувствительной информации нашего проекта
Быстрый старт:
Скачайте приложение ntfy:
Android: Google Play / F-Droid
iOS: App Store
Десктоп: посетите ntfy.sh
Подпишитесь на тему (выберите трудноподбираемое название):
建议格式:trendradar-{你的名字缩写}-{随机数字} 不能使用中文 ✅ 好例子:trendradar-zs-8492 ❌ 坏例子:news、alerts(太容易被猜到)Настройте GitHub Secret (⚠️ Имя Name должно строго совпадать):
Name (Имя):
NTFY_TOPIC(скопируйте и вставьте это имя, не вводите вручную)Secret (Значение): укажите название темы, на которую вы подписались
Name (Имя):
NTFY_SERVER_URL(необязательная настройка, скопируйте и вставьте это имя)Secret (Значение): оставьте пустым (по умолчанию используется ntfy.sh)
Name (Имя):
NTFY_TOKEN(необязательная настройка, скопируйте и вставьте это имя)Secret (Значение): оставьте пустым
Пояснение: для ntfy требуется как минимум 1 обязательный Secret (NTFY_TOPIC), последние два — необязательные
Тестирование:
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 уведомлений в день — вполне достаточно.
Если вы выберете случайное, достаточно длинное название (например, 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 уведомления
О Bark:
Bark — это бесплатный инструмент для push-уведомлений с открытым исходным кодом на платформе iOS, отличающийся простотой, скоростью и отсутствием рекламы.
Способы использования:
Способ 1: Использование официального сервера (рекомендуется новичкам) 🆓
Скачайте приложение Bark:
iOS: App Store
Получите URL для push-уведомлений:
Откройте приложение Bark
Скопируйте URL для push-уведомлений, отображаемый на главной странице (формат:
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
Перейдите на страницу Slack API:
Откройте https://api.slack.com/apps?new_app=1
Если вы не вошли в систему, сначала войдите в своё рабочее пространство Slack
Выберите способ создания:
Нажмите «From scratch» (создать с нуля)
Заполните информацию о приложении:
App Name: укажите название приложения (например,
TrendRadarилиМониторинг горячих новостей)Workspace: выберите своё рабочее пространство из выпадающего списка
Нажмите кнопку «Create App»
Шаг 2: Включение Incoming Webhooks
Перейдите к Incoming Webhooks:
В левом меню найдите и нажмите «Incoming Webhooks»
Включите функцию:
Найдите переключатель «Activate Incoming Webhooks»
Переключите его с
OFFнаONСтраница автоматически обновится и отобразит новые параметры конфигурации
Шаг 3: Создание URL Webhook
Добавьте новый Webhook:
Прокрутите страницу вниз
Нажмите кнопку «Add New Webhook to Workspace»
Выберите целевой канал:
Появится страница авторизации
Выберите канал для получения сообщений из выпадающего списка (например,
#горячие_новости)⚠️ Чтобы выбрать приватный канал, сначала необходимо вступить в него
Авторизуйте приложение:
Нажмите кнопку «Allow» для завершения авторизации
Система автоматически вернёт вас на страницу конфигурации
Шаг 4: Скопируйте и сохраните URL Webhook
Просмотрите сгенерированный URL:
В разделе «Webhook URLs for Your Workspace»
Вы увидите только что созданный URL Webhook
Формат:
https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX
Скопируйте URL:
Нажмите кнопку «Copy» справа от URL
Или выделите URL вручную и скопируйте
Настройте в 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
Получите URL Webhook:
Перейдите в настройки сервера Discord → Интеграции → Webhooks
Создайте новый Webhook и скопируйте URL
Настройте шаблон:
{"content": "{content}"}Настройка GitHub Secret:
GENERIC_WEBHOOK_URL: URL Webhook DiscordGENERIC_WEBHOOK_TEMPLATE:{"content": "{content}"}
Пользовательский шаблон
Шаблон поддерживает два плейсхолдера:
{title}— заголовок сообщения{content}— содержимое сообщения
Пример шаблона:
# 默认格式(留空时使用)
{"title": "{title}", "content": "{content}"}
# Discord 格式
{"content": "{content}"}
# 自定义格式
{"text": "{content}", "username": "TrendRadar"}Примечания:
✅ Поддерживается формат Markdown (совместим с форматом WeCom)
✅ Поддерживается автоматическая отправка партиями
✅ Поддерживается настройка нескольких аккаунтов (разделяются символом
;)⚠️ Шаблон должен быть в корректном формате JSON
⚠️ Разные платформы предъявляют разные требования к формату сообщений, обратитесь к документации целевой платформы
3️⃣ Шаг третий: Ручное тестирование отправки новостей
⚠️ Напоминание:
После выполнения шагов 1–2 немедленно проведите тест! После успешного теста при необходимости настройте конфигурацию (шаг 4)
Зайдите в свой собственный проект, а не в этот!
Как найти страницу Actions:
Способ 1: Откройте главную страницу вашего форкнутого проекта и нажмите вкладку Actions вверху
Способ 2: Перейдите напрямую по адресу
https://github.com/ваше_имя_пользователя/TrendRadar/actions
Пример для сравнения:
❌ Проект автора:
https://github.com/sansan0/TrendRadar/actions✅ Ваш проект:
https://github.com/ваше_имя_пользователя/TrendRadar/actions
Шаги тестирования:
Перейдите на страницу Actions вашего проекта
Найдите «Get Hot News» (должно быть именно это название), нажмите на него, затем нажмите кнопку «Run workflow» справа для запуска
Если вы не видите эту надпись, решите проблему согласно #109
Примерно через 3 минуты сообщение будет отправлено на настроенную вами платформу
⚠️ Напоминание:
Не проводите ручное тестирование слишком часто, чтобы не сработали ограничения GitHub Actions
После нажатия Run workflow необходимо обновить страницу браузера, чтобы увидеть новую запись о запуске
4️⃣ Шаг четвёртый: Пояснение к конфигурации (необязательно)
Конфигурация по умолчанию уже работает корректно. Если требуется индивидуальная настройка, достаточно ознакомиться со следующими файлами:
Файл | Назначение |
| Основной файл конфигурации: режим отправки, временное окно, список платформ, веса горячих тем и т.д. |
| Файл ключевых слов: укажите интересующие вас слова для фильтрации содержимого уведомлений |
| Шаблон AI-подсказки: настройте роль и аспекты анализа AI-аналитика |
| Частота выполнения: управление периодичностью запуска (⚠️ изменять с осторожностью) |
👉 Подробное руководство по настройке: Подробности конфигурации
5️⃣ Шаг пятый: Удалённое облачное хранилище и настройка регистрации
Важное изменение в v4.0.0: введён механизм «проверки активности» — GitHub Actions требует периодической регистрации для продолжения работы.
Период работы: срок действия — 7 дней, после окончания обратного отсчёта сервис автоматически приостанавливается.
Способ продления: на странице Actions вручную запустите workflow «Check In», чтобы сбросить 7-дневный срок действия.
Путь действий:
Actions→Check In→Run workflowКонцепция дизайна:
Если вы забыли зарегистрироваться в течение 7 дней, возможно, эта информация для вас не является жизненно необходимой. Своевременная пауза поможет вам отвлечься от информационного потока и дать мозгу передышку.
GitHub Actions — это ценный общедоступный вычислительный ресурс. Введение механизма регистрации направлено на предотвращение неэффективного простоя вычислительных мощностей и обеспечение их распределения действительно активным и нуждающимся пользователям. Благодарим за понимание и поддержку.
О настройке удалённого облачного хранилища (выберите в зависимости от способа развёртывания):
Пользователи GitHub Actions:
Текущее состояние: Actions при каждом запуске создаёт новую среду и не сохраняет файлы. Если не настроить облачное хранилище, проект будет работать в облегчённом режиме (без инкрементальных уведомлений, без отслеживания истории).
Рекомендация: настройте удалённое облачное хранилище для получения полного опыта.
Пользователи Docker / локального развёртывания:
Текущее состояние: данные по умолчанию сохраняются на локальном жёстком диске.
Рекомендация: облачное хранилище необязательно, может использоваться как резервная копия на другом сервере.
⚠️ Предварительные условия (важно):
Согласно правилам платформы Cloudflare, для активации R2 необходимо привязать платёжный метод.
Цель: только для проверки личности (Verify Only), списания не производятся.
Оплата: поддерживаются карты с двумя валютами или PayPal для Китая.
Использование: бесплатного лимита R2 (10 ГБ хранилища/месяц) достаточно для повседневной работы этого проекта, можно не беспокоиться о платежах.
Настройка GitHub Secret (необходимо добавить 4 элемента):
Name (Имя) | Описание Secret (Значение) |
| Название корзины (например, |
| Идентификатор ключа доступа (Access Key ID) |
| Секретный ключ доступа (Secret Access Key) |
| Конечная точка S3 API (например, для R2: |
Необязательная настройка:
Name (Имя) | Описание Secret (Значение) |
| Регион (по умолчанию |
💡 Дополнительные варианты настройки хранилища: см. Где хранятся данные?
Подробные шаги (получение учётных данных):
Перейдите в обзор R2:
Войдите в Cloudflare Dashboard.
В левой боковой панели найдите и нажмите
R2对象存储.
Создайте корзину:
Нажмите
概述Нажмите
创建存储桶(Create bucket) в правом верхнем углу.Введите название (например,
trendradar-data) и нажмите创建存储桶.
Создайте API-токен:
Вернитесь на страницу 概述.
В правом нижнем углу нажмите
Account Details, найдите и нажмитеManage(Manage R2 API Tokens).Также вы увидите
S3 API:https://<account-id>.r2.cloudflarestorage.com(это и есть S3_ENDPOINT_URL)Нажмите
创建 Account APl 令牌.⚠️ Ключевые настройки:
Имя токена: укажите произвольное имя (например,
github-action-write).Права доступа: выберите
管理员读和写.Указание корзины: для безопасности рекомендуется выбрать
仅适用于指定存储桶и выбрать вашу корзину (например,trendradar-data).
Нажмите
创建 API 令牌и немедленно скопируйте отображаемыеAccess Key IDиSecret Access Key(отображаются только один раз!).
6️⃣ Шаг шестой: Включение AI-аналитики в уведомлениях
Это ключевая функция v5.0.0 — AI поможет вам обобщать и анализировать новости, рекомендуем попробовать.
Способ настройки:
Добавьте в GitHub Secrets (или .env / config.yaml):
AI_API_KEY: ваш API-ключ (поддерживаются DeepSeek, OpenAI и др.)AI_PROVIDER: название провайдера (например,deepseek,openai)
Всё, сложное развёртывание не требуется — при следующей отправке вы увидите интеллектуальный аналитический отчёт.
7️⃣ Шаг седьмой: 🎉 Развёртывание успешно!
Поздравляем! Теперь вы можете наслаждаться эффективным информационным потоком TrendRadar.
💬 Присоединяйтесь к сообществу: Подписывайтесь на официальный аккаунт «硅基茶水间», делитесь своим опытом использования и продвинутыми приёмами.
8️⃣ Шаг восьмой: продвинутый уровень: выберите своего AI-ассистента
TrendRadar предлагает два способа использования AI, удовлетворяющих разные потребности:
Характеристика | ✨ AI-анализ и рассылка | 🧠 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 новостей (новое в v3.2.0) |
Глобальный фильтр |
| Глобальное исключение указанного контента | см. пример ниже | Фильтруется в любом случае (новое в v3.5.0) |
Регулярное выражение |
| Точное сопоставление по шаблону |
| Сопоставление с помощью регулярного выражения (новое в v4.7.0) |
Отображаемое имя |
| Пользовательский отображаемый текст |
| Отображается имя примечания в рассылке и 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❌ «广告:最新科技产品发布» ← содержит глобальное слово-фильтр «广告», отклоняется напрямую
✅ «科技公司发布AI新产品» ← не содержит глобальных слов-фильтров, сопоставляется с группой «科技»
✅ «AI技术突破引发关注» ← не содержит глобальных слов-фильтров, сопоставляется с «AI» в группе «科技»
Примечания:
Глобальные слова-фильтры следует использовать с осторожностью, чтобы избежать чрезмерной фильтрации и пропуска ценного контента
Рекомендуется ограничить количество глобальных слов-фильтров 5–15
Для фильтрации в конкретных группах слов предпочтительно использовать слова-фильтры внутри группы (префикс
!)
6. Регулярные выражения /pattern/ — точное сопоставление по шаблону (новое в v4.7.0)
Обычные ключевые слова используют сопоставление по подстроке, что удобно в китайской среде, но в английской среде может приводить к ложным срабатываниям. Например, ai будет сопоставляться с ai в слове training.
Использование синтаксиса регулярных выражений /pattern/ позволяет добиться точного сопоставления:
/(?<![a-z])ai(?![a-z])/
人工智能Назначение: Сопоставление с помощью регулярных выражений, поддерживается весь синтаксис регулярных выражений Python
Часто используемые шаблоны регулярных выражений:
Потребность | Написание регулярного выражения | Пояснение |
Граница английского слова |
| Сопоставление отдельного слова, например, |
Не буква до и после |
| Более мягкая граница, подходит для смешанных китайско-английских сценариев |
Сопоставление с начала |
| Сопоставляет только заголовки, начинающиеся с «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(флаги игнорируются, так как по умолчанию уже включено игнорирование регистра)Некорректный синтаксис регулярных выражений обрабатывается как обычное слово
Регулярные выражения можно использовать для обычных слов, обязательных слов (
+), слов-фильтров (!)
💡 Не умеете писать регулярные выражения? Пусть AI поможет вам их сгенерировать!
Если вы не знакомы с регулярными выражениями, вы можете попросить ChatGPT / Gemini / DeepSeek сгенерировать их для вас. Просто скажите AI:
Мне нужно регулярное выражение Python для сопоставления английского слова «ai», но не «ai» в «training». Пожалуйста, дайте сразу регулярное выражение в формате
/pattern/, без дополнительных объяснений.
AI даст вам примерно такой результат: /(?<![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 |
|
|
|
|
Примечания:
Отображаемое имя нужно указывать только на первом слове группы
Если несколько слов в группе имеют отображаемые имена, используется первое
Если отображаемое имя не задано, автоматически используется объединение всех слов в группе
🔗 Функция групп слов — важная роль разделения пустыми строками
Основное правило: Разделяйте разные группы слов пустыми строками, каждая группа подсчитывается независимо
Пример конфигурации:
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 # 排序优先级配置Значение конфигурации | Правило сортировки | Подходящий сценарий |
| Количество горячих ↓ → Позиция в конфигурации ↑ | Отслеживание трендов популярности |
| Позиция в конфигурации ↑ → Количество горячих ↓ | Приоритет личных предпочтений |
Пример: Порядок конфигурации 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"Детальная сравнительная таблица
Режим | Целевая аудитория | Время рассылки | Отображаемый контент | Типичный сценарий использования |
Дневная сводка | 📋 Руководители предприятий/обычные пользователи | По расписанию (по умолчанию раз в час) | Все сопоставленные новости за день+ область новых новостей | Пример: Просмотр всех важных новостей дня каждый день в 18:00Особенность: Полная картина трендов за день, ничего не пропуститеНапоминание: Будут включены ранее отправленные новости |
Текущий рейтинг | 📰 Медиа-специалисты/создатели контента | По расписанию (по умолчанию раз в час) | Сопоставленные новости текущего рейтинга+ область новых новостей | Пример: Ежечасное отслеживание «какие темы сейчас самые горячие»Особенность: В реальном времени видно изменения в рейтинге популярностиНапоминание: Новости, остающиеся в рейтинге, будут появляться каждый раз |
Инкрементальный мониторинг | 📈 Инвесторы/трейдеры | Рассылка только при появлении нового | Новые новости, сопоставленные с частотными словами | Пример: Мониторинг «特斯拉», уведомление только при появлении новых сообщенийОсобенность: Ноль повторов, видны только впервые появившиеся новостиПодходит для: Высокочастотного мониторинга, избегания информационного шума |
Пример реального эффекта рассылки
Предположим, вы отслеживаете ключевое слово «苹果», выполнение раз в час:
Время | Рассылка в режиме 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: Смените режим рассылки — используйте режим
currentилиdailyдля регулярного получения рассылокРешение 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.0
Что важнее — то и увеличивайте: если важен рейтинг — увеличивайте
rank, если важна устойчивость — увеличивайтеfrequencyРекомендуется менять по 0.1–0.2 за раз, наблюдайте за эффектом
Основная идея: пользователи, которым важны скорость и актуальность, повышают вес рейтинга; пользователи, которым важны глубина и стабильность, повышают вес частоты.
5. Как выглядят мои сообщения?
Пример рассылки
📊 Статистика горячих слов
🔥 [1/3] AI ChatGPT : 2 шт.
[百度热搜] 🆕 ChatGPT-5正式发布 [1] - 09时15分 (1 раз)
[今日头条] AI芯片概念股暴涨 [3] - [08时30分 ~ 10时45分] (3 раза)
━━━━━━━━━━━━━━━━━━━
📈 [2/3] 比亚迪 特斯拉 : 2 шт.
[微博] 🆕 比亚迪月销量破纪录 [2] - 10时20分 (1 раз)
[抖音] 特斯拉降价促销 [4] - [07时45分 ~ 09时15分] (2 раза)
━━━━━━━━━━━━━━━━━━━
📌 [3/3] A股 股市 : 1 шт.
[华尔街见闻] A股午盘点评分析 [5] - [11时30分 ~ 12时00分] (2 раза)
🆕 Новые горячие новости за этот цикл (всего 2 шт.)
百度热搜 (1 шт.):
ChatGPT-5正式发布 [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-образа, можно выбрать развёртывание по потребностям:
Название образа | Назначение | Пояснение |
| Сервис рассылки новостей | Периодический сбор новостей, отправка уведомлений (обязательно) |
| Сервис AI-анализа | Поддержка протокола MCP, диалоговый AI-анализ (опционально) |
💡 Рекомендация:
Нужна только рассылка: разверните только образ
wantcat/trendradarНужна функция AI-анализа: разверните оба образа
Способ 1: Использование docker compose (рекомендуется)
Создайте каталог проекта и конфигурацию:
# 克隆项目到本地 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 编排文件Описание файлов конфигурации:
Принцип разделения конфигурации (оптимизация 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 Key, ключи S3, планировщик задач и т.д., не отслеживается git
💡 Ключевые моменты разделения:
Поведение функций → изменяйте
config.yaml(например, включение/отключение платформы, настройка режима push-уведомлений)Отслеживаемый контент → изменяйте
frequency_words.txt(например, добавление новых ключевых слов)Стиль вывода AI → изменяйте
ai_analysis_prompt.txtилиai_translation_prompt.txtКлючи и учётные данные → изменяйте
docker/.env(API Key, Webhook URL и другая конфиденциальная информация хранится здесь)Персонализированные расширения → используйте каталог
config/custom/, чтобы избежать перезаписи при обновлении
💡 Применение изменений конфигурации: после изменения
config.yamlвыполнитеdocker compose up -dдля перезапуска контейнера⚙️ Механизм переопределения переменными окружения (v3.0.5+)
Переменные окружения из файла
.envпереопределяют соответствующие настройки вconfig.yaml:Переменная окружения
Соответствующая конфигурация
Пример значения
Описание
WEBSERVER_PORT-
8080Порт веб-сервера
FEISHU_WEBHOOK_URLnotification.channels.feishu.webhook_urlhttps://...Webhook Feishu (несколько аккаунтов через
;)AI_ANALYSIS_ENABLEDai_analysis.enabledtrue/falseВключить ли AI-анализ (новое в v5.0.0)
AI_API_KEYai.api_keysk-xxx...AI API Key (общий для ai_analysis и ai_translation)
AI_PROVIDERai.providerdeepseek/openai/geminiПоставщик AI
S3_*storage.remote.*-
Конфигурация удалённого хранилища (5 параметров)
Приоритет конфигурации: переменные окружения > config.yaml
Как использовать:
Измените файл
.env, заполнив необходимые настройкиИли добавьте их напрямую в разделе «Переменные окружения» в интерфейсе управления Docker на NAS/Synology
Применяется после перезапуска контейнера:
docker compose up -d
Запуск сервиса:
Вариант 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-диалогового анализаОба сервиса независимы и могут гибко комбинироваться по необходимости
Проверка статуса работы:
# 查看新闻推送服务日志 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Доступные образы:
Имя образа | Назначение | Описание |
| Сервис push-уведомлений | Периодический сбор новостей, отправка уведомлений |
| 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, данные сохраняются даже после перезапуска или удаления контейнера.
📊 Пути доступа к веб-отчётам:
Сгенерированный TrendRadar ежедневный сводный HTML-отчёт сохраняется в двух местах:
Расположение файла | Способ доступа | Сценарий использования |
| Прямой доступ с хоста | Развёртывание Docker (через монтирование Volume, виден на хосте) |
| Доступ из корневого каталога | GitHub Pages (корневой каталог репозитория, автоматическое распознавание Pages) |
| Доступ к историческим отчётам | Все окружения (архивация по датам) |
Пример локального доступа:
# 方式 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-серверы → Добавить
Тип:
streamableHttpURL:
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-уведомлений |
|
| Определяет время и содержимое push-уведомлений, подробнее в Подробное описание режимов |
Способ группировки |
|
|
|
Выделение важного |
|
| Новости в топ-5 будут выделены жирным шрифтом, сразу видно самое популярное |
Правило сортировки |
|
|
|
Ограничение количества |
|
| Сколько новостей максимум показывать по каждому ключевому слову? |
Порядок отображения |
| см. конфигурацию выше | Изменяя порядок в списке, можно управлять расположением областей |
Сравнение способов группировки (display_mode)
Вы хотите видеть «какие новости по этой теме» или «какие новости на этой платформе»?
Режим | Способ группировки | Префикс заголовка | Сценарий применения |
| Агрегация по ключевым словам |
| Меня интересует «AI», хочу видеть новости об AI со всех платформ |
| Агрегация по платформам |
| Меня интересует «Weibo», хочу видеть новости по моим ключевым словам на Weibo |
Порядок отображения областей (region_order)
Изменяя порядок элементов в списке display.region_order, можно управлять расположением областей в push-сообщении.
Порядок по умолчанию: Новые горячие темы → Горячие списки → RSS → Отдельная область отображения → AI-анализ
Пример настройки: хотите, чтобы AI-анализ был в начале?
display:
region_order:
- ai_analysis # 移到第一行
- new_items
- hotlist
- rss
- standaloneВнимание: область отображается только при выполнении двух условий:
Она есть в списке
region_orderСоответствующий переключатель в
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 分析区域Область | Ключ конфигурации | Значение по умолчанию | Описание |
Горячие списки |
|
| Агрегация горячих новостей по ключевым словам |
Новые горячие темы |
|
| Новые горячие темы за текущий цикл (включая новые в горячих списках + новые в RSS). Примечание: маркер 🆕 в области горячих списков не зависит от этого переключателя |
RSS |
|
| RSS-подписки, соответствующие ключевым словам. При отключении анализ RSS пропускается, но RSS в отдельной области отображения не затрагивается |
Отдельная область отображения |
|
| Полное отображение контента указанных платформ/RSS, не фильтруется по ключевым словам |
AI-анализ |
|
| Сводка анализа горячих тем, сгенерированная AI |
Приоритет сортировки (sort_by_position_first)
Предположим, вы настроили ключевые слова: 1. Tesla, 2. BYD. Фактическая популярность: BYD (10 записей), Tesla (3 записи).
Значение конфигурации | Результат сортировки | Ваша логика |
| BYD (10 записей) → Tesla (3 записи) | «Кто популярнее — тот впереди» |
| Tesla (3 записи) → BYD (10 записей) | «Порядок моей конфигурации — приоритет, независимо от популярности» |
Отдельная область отображения (standalone)
Сценарий: некоторые платформы (например, горячие списки Zhihu, HackerNews) я хочу просматривать полностью, независимо от того, совпадают ли они с моими ключевыми словами.
display:
regions:
standalone: true # 推送中展示独立展示区(关闭不影响 AI 分析)
standalone:
platforms: ["zhihu", "weibo"] # 这些平台的热榜给我完整显示
rss_feeds: ["hacker-news"] # 这些RSS源的内容给我完整显示
max_items: 20 # 最多显示多少条💡 Независимое управление push-отображением и AI-анализом:
regions.standaloneуправляет только отображением отдельной области в push-уведомлениях. Даже если отображение в push отключено, при включенииinclude_standalone: trueв конфигурации AI, AI всё равно будет анализировать полные данные этих платформ. Подходит для пользователей, которые хотят, чтобы AI делал глубокий анализ, но не хотят слишком длинных push-сообщений.
8. Когда мне приходят push-уведомления?
Место настройки: раздел schedule в config/config.yaml + config/timeline.yaml
Быстрый старт
Просто выберите один из предустановленных шаблонов в config.yaml, редактировать timeline.yaml не нужно:
schedule:
enabled: true
preset: "morning_evening" # 改这里就行Доступные предустановленные шаблоны
Имя шаблона | Описание | Поведение push-уведомлений |
| Инкрементально весь день + вечерняя сводка (рекомендуется) | Push при новых событиях в течение дня + вечерняя сводка за день в 19:00-21:00 |
| Круглосуточный мониторинг | Push при новых событиях в течение всего дня, без разделения на временные интервалы |
| Рабочее время | Три периода в рабочие дни (утренний обзор → дневные горячие темы → вечерняя сводка), в выходные свободный push |
| Сова | Дневной обзор + ночная сводка за весь день (22:00-01:00, через полночь) |
| Полностью настраиваемый | Редактирование раздела custom внизу |
Полная настройка
Если ни один из предустановленных шаблонов не подходит, можно отредактировать раздел 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
Я хочу... | Скопируйте эту строку кода | Описание |
Каждый час |
| Конфигурация по умолчанию, запуск в 0-ю минуту |
Каждые 30 минут |
| Запуск каждые 30 минут |
Каждый день в 8:00 |
| ⚠️ Указывается |
Каждые полчаса в рабочее время |
| Соответствует времени Пекина 8:00 - 22:00 |
Три раза в день |
| Соответствует времени Пекина 8:00, 14:00, 20:00 |
⚠️ Два важных напоминания
Разница во времени: серверы GitHub находятся за рубежом и используют время UTC.
Простая арифметика: желаемое время Пекина минус 8 часов = время, которое нужно указать.
Пример: хотите запуск в 20:00 по пекинскому времени, в настройках укажите 12:00
Не слишком часто: рекомендуемый интервал — не менее 30 минут.
Бесплатные ресурсы GitHub ограничены, слишком частые запуски могут привести к ограничению аккаунта.
К тому же запуск Actions имеет задержку в несколько минут, точный контроль не имеет смысла.
Пошаговая инструкция по изменению
В вашем репозитории GitHub найдите файл
.github/workflows/crawler.ymlНажмите кнопку ✏️ (Edit) в правом верхнем углу
Найдите строку
cron: "..."и замените содержимое в кавычках на «код» из таблицы вышеНажмите зелёную кнопку Commit changes в правом верхнем углу для сохранения
10. Push-уведомления в несколько групп/устройств
⚠️ Безопасность прежде всего
Не записывайте пароли/токены напрямую в
config.yaml! Если вы загрузите файл с паролями на GitHub, его увидит весь мир.Правильный подход:
Пользователи GitHub Actions: добавьте в Settings -> Secrets
Пользователи Docker: запишите в файл
.env(этот файл не будет загружен)
Как отправлять push-уведомления в несколько мест одновременно?
Очень просто: при настройке разделите несколько адресов точкой с запятой ;.
Пример: Предположим, у вас есть две группы Feishu, в которые нужно отправлять уведомления:
Адрес группы 1:
https://.../webhook/aaaАдрес группы 2:
https://.../webhook/bbb
При настройке укажите:
https://.../webhook/aaa;https://.../webhook/bbb
Платформы с поддержкой нескольких аккаунтов
Платформа | Способ настройки | Примечания |
Feishu/DingTalk/WeCom | Разделяйте несколько Webhook URL через | Самый простой способ — просто соединить их последовательно |
Bark (iOS) | Разделяйте несколько Key URL через | Отправка на несколько iPhone |
Telegram | Token и ChatID должны разделяться через | ⚠️ Обратите внимание на соответствие порядка:Token1 соответствует ChatID1Token2 соответствует ChatID2 |
ntfy | Topic и Token должны разделяться через | Если для какого-то Topic не нужен Token, оставьте пустым: |
Примеры распространённых конфигураций (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 / Локальный запуск | Локальный диск | Хранятся в папке |
GitHub Actions | Облачное хранилище | Поскольку GitHub Actions уничтожает среду после выполнения, необходимо настроить облачное хранилище (например, Cloudflare R2). |
Как настроить облачное хранилище? (Обязательно для пользователей GitHub Actions)
Если вы используете GitHub Actions, вам понадобится «облачный диск» для хранения данных. Например, Cloudflare R2 (поскольку есть бесплатный тариф).
Добавьте эти 5 переменных в GitHub Secrets:
Имя переменной | Что указать |
|
|
| Имя вашего бакета |
| Ваш Access Key |
| Ваш Secret Key |
| Адрес вашего R2 API |
💡 Подробная инструкция: Как получить 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 будет действовать как профессиональный аналитик. При отправке каждой партии новостей:
Автоматическое чтение: читает все подобранные горячие новости
Глубокий анализ: анализирует связи между изначально разрозненными новостями
Составление отчёта: в конце отправляемого сообщения прикладывает краткий и глубокий «аналитический отчёт»
Содержание: сводка трендов горячих тем, оценка направления общественного мнения, кросс-платформенный анализ связей, оценка потенциального влияния и т.д.
Как включить анализ AI?
Самый простой способ — настроить через переменные окружения (рекомендуется GitHub Secrets или .env).
Обязательные параметры конфигурации:
Имя переменной | Что указать | Описание |
|
| Переключатель включения |
|
| Ваш API Key |
|
| Идентификатор модели (формат: |
Поддерживаемые AI-провайдеры (на основе LiteLLM, поддерживается 100+ провайдеров):
Провайдер | Что указать в AI_MODEL | Описание |
DeepSeek (рекомендуется) |
| Отличное соотношение цены и качества, подходит для частого анализа |
OpenAI |
| Серия GPT-4o |
Google Gemini |
| Серия Gemini |
Пользовательский API | Любой формат | Используется вместе с |
💡 Новая функция: Теперь на основе единого интерфейса LiteLLM, поддерживается 100+ AI-провайдеров, конфигурация проще, обработка ошибок улучшена.
Необязательные параметры конфигурации:
Имя переменной | Значение по умолчанию | Описание |
| (автоматически) | Пользовательский адрес API (например, OneAPI, локальная модель) |
|
| Температура сэмплирования (0-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 добавил функцию анализа AI на основе MCP (Model Context Protocol), которая позволяет вам общаться с новостными данными на естественном языке и проводить углублённый анализ.
⚠️ Обязательно прочитайте перед использованием
Важное примечание: для работы функции AI требуются локальные новостные данные
Функция анализа AI не запрашивает данные в реальном времени из сети напрямую, а анализирует накопленные локально новостные данные (хранящиеся в папке output)
Инструкция по использованию:
Встроенные тестовые данные проекта: каталог
outputпо умолчанию содержит данные горячих новостей за неделю 2025-12-21~2025-12-27, которые можно использовать для быстрого ознакомления с функцией AIОграничения запросов:
✅ Можно запрашивать только данные в пределах существующего диапазона дат (21-27 декабря, всего 7 дней)
❌ Невозможно запрашивать новости в реальном времени или будущие даты
Получение актуальных данных:
Тестовые данные предназначены только для быстрого ознакомления, рекомендуется развернуть проект самостоятельно для получения данных в реальном времени
Следуйте Быстрому старту для развёртывания и запуска проекта
После накопления новостных данных в течение как минимум 1 дня вы сможете запрашивать последние горячие темы
1. Быстрое развёртывание
Cherry Studio предоставляет графический интерфейс конфигурации, быстрое развёртывание за 5 минут, сложные части устанавливаются в один клик.
Пошаговая инструкция с иллюстрациями: уже обновлена в моём публичном аккаунте, ответьте «mcp» для получения
Подробная инструкция по развёртыванию: README-Cherry-Studio.md
Описание режимов развёртывания:
Режим STDIO (рекомендуется): после однократной настройки не требует повторной настройки, в пошаговой инструкции с иллюстрациями приведён пример только этого режима.
Режим HTTP (запасной вариант): если возникли проблемы с настройкой режима STDIO, можно использовать режим HTTP. Способ настройки этого режима в основном такой же, как и STDIO, но копируемый и вставляемый контент — всего одна строка, что снижает вероятность ошибок. Единственное, на что нужно обратить внимание — перед каждым использованием необходимо вручную запустить службу. Подробнее см. описание режима HTTP в конце README-Cherry-Studio.md.
2. Изучаем, как общаться с AI
Подробное руководство по диалогам: README-MCP-FAQ.md
💡 Подсказка: На практике не рекомендуется задавать несколько вопросов одновременно. Если выбранная вами модель AI не может выполнить последовательные вызовы, как на рисунке ниже, рекомендуется сменить модель.
🔌 MCP-клиенты
Служба TrendRadar MCP поддерживает стандартный протокол Model Context Protocol (MCP) и может подключаться к различным AI-клиентам, поддерживающим MCP, для интеллектуального анализа.
Поддерживаемые клиенты
Примечания:
Замените
/path/to/TrendRadarна фактический путь к вашему проектуВ Windows используйте двойные обратные слэши:
C:\\Users\\YourName\\TrendRadarПосле сохранения не забудьте перезапустить
Способ 1: режим HTTP
Запустите HTTP-службу:
# Windows start-http.bat # Mac/Linux ./start-http.shНастройте Cursor:
Конфигурация уровня проекта (рекомендуется): Создайте
.cursor/mcp.jsonв корневом каталоге проекта:{ "mcpServers": { "trendradar": { "url": "http://localhost:3333/mcp", "description": "TrendRadar 新闻热点聚合分析" } } }Глобальная конфигурация: Создайте
~/.cursor/mcp.jsonв домашнем каталоге пользователя (то же содержимое)Шаги использования:
После сохранения файла конфигурации перезапустите Cursor
Просмотрите подключённые инструменты в разделе "Available Tools" в интерфейсе чата
Начните использовать:
найди сегодняшние новости, связанные с "AI"
Способ 2: режим STDIO (рекомендуется)
Создайте .cursor/mcp.json:
{
"mcpServers": {
"trendradar": {
"command": "uv",
"args": [
"--directory",
"/path/to/TrendRadar",
"run",
"python",
"-m",
"mcp_server.server"
]
}
}
}Настройка Cline
Добавьте в настройки MCP в Cline:
Режим 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-подключений:
Шаги использования
Запустите HTTP-службу TrendRadar:
# Windows start-http.bat # Mac/Linux ./start-http.shЗапустите MCP Inspector:
npx @modelcontextprotocol/inspectorПодключитесь в браузере:
Перейдите по адресу:
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)
Часто задаваемые вопросы
Шаги проверки:
Убедитесь, что порт 3333 не занят:
# Windows netstat -ano | findstr :3333 # Mac/Linux lsof -i :3333Проверьте, установлены ли зависимости проекта:
# 重新运行安装脚本 # Windows: setup-windows.bat 或者 setup-windows-en.bat # Mac/Linux: ./setup-mac.shПросмотрите подробные журналы ошибок:
uv run python -m mcp_server.server --transport http --port 3333Попробуйте использовать пользовательский порт:
uv run python -m mcp_server.server --transport http --port 33333
Решения:
Режим STDIO:
Убедитесь, что путь UV указан правильно (выполните
which uvилиwhere uv)Убедитесь, что путь к проекту указан правильно и не содержит китайских символов
Просмотрите журналы ошибок клиента
Режим HTTP:
Убедитесь, что служба запущена (перейдите по адресу
http://localhost:3333/mcp)Проверьте настройки брандмауэра
Попробуйте использовать 127.0.0.1 вместо localhost
Общие проверки:
Перезапустите клиентское приложение
Просмотрите журналы MCP-службы
Используйте MCP Inspector для тестирования подключения
Возможные причины:
Данные отсутствуют:
Убедитесь, что краулер уже запускался (есть данные в каталоге output)
Проверьте, есть ли данные в запрашиваемом диапазоне дат
Просмотрите доступные даты в каталоге output
Ошибка параметров:
Проверьте формат даты:
YYYY-MM-DDУбедитесь, что ID платформы указан правильно:
zhihu,weiboи т.д.Просмотрите описание параметров в документации инструмента
Проблемы с конфигурацией:
Убедитесь, что
config/config.yamlсуществуетУбедитесь, что
config/frequency_words.txtсуществуетПроверьте, правильный ли формат файла конфигурации
📚 О проекте
4 статьи:
Под этой статьёй можно оставить комментарий, чтобы автор проекта мог отвечать на вопросы с телефона
2 месяца до 1000 star, мой практический опыт продвижения GitHub-проекта
На основе этого проекта, как писать статьи для публичного аккаунта или новостных сайтов
AI-разработка:
Если у вас есть нишевые потребности, вы можете разрабатывать на основе моего проекта самостоятельно, даже без опыта программирования
Во всех моих open-source проектах я в той или иной степени использую собственное AI-вспомогательное ПО для повышения эффективности разработки, этот инструмент также open-source
Основная функция: быстрый отбор кода проекта для передачи AI, вам нужно лишь дополнить свои личные требования
Адрес проекта: https://github.com/sansan0/ai-code-context-helper
Другие проекты
📍 Карта следов председателя Мао — интерактивное динамическое отображение полного маршрута 1893-1976 годов. Приглашаем товарищей внести свой вклад в данные
Программное обеспечение для визуализации и анализа данных комментариев Bilibili
📄 Лицензия
GPL-3.0 License
Available Tools
27 toolsaggregate_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)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| platforms | No | ||
| date_range | No | ||
| include_url | No | ||
| similarity_threshold | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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)
| Name | Required | Description | Default |
|---|---|---|---|
| top_n | No | ||
| topic | No | ||
| date_range | No | ||
| insight_type | No | platform_compare | |
| min_frequency | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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"})
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| topic | No | ||
| platforms | No | ||
| date_range | No | ||
| include_url | No | ||
| sort_by_weight | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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")
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | ||
| date_range | No | ||
| granularity | No | day | |
| time_window | No | ||
| analysis_type | No | trend | |
| lookahead_hours | No | ||
| spike_threshold | No | ||
| confidence_threshold | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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")
| Name | Required | Description | Default |
|---|---|---|---|
| proxy_url | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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="人工智能" )
| Name | Required | Description | Default |
|---|---|---|---|
| top_n | No | ||
| topic | No | ||
| period1 | Yes | ||
| period2 | Yes | ||
| platforms | No | ||
| compare_type | No | overview |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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格式内容
| Name | Required | Description | Default |
|---|---|---|---|
| date_range | No | ||
| report_type | No | daily |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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 策略
| Name | Required | Description | Default |
|---|---|---|---|
| channel | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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格式的配置信息
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | all |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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格式的新闻列表
数据展示建议
默认展示全部返回数据,除非用户明确要求总结
用户说"总结"或"挑重点"时才进行筛选
用户问"为什么只显示部分"说明需要完整数据
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| platforms | No | ||
| include_url | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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'])
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| feeds | No | ||
| limit | No | ||
| include_summary | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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格式的新闻列表,包含标题、平台、排名等信息
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| platforms | No | ||
| date_range | No | ||
| include_url | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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()
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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 源状态
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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格式的存储状态信息,包含本地/远程存储状态和拉取配置
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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格式的系统状态信息
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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.
get_trending_topicsA
获取热点话题统计
Args: top_n: 返回TOP N话题,默认10 mode: 时间模式 - "daily": 当日累计数据统计 - "current": 最新一批数据统计(默认) extract_mode: 提取模式 - "keywords": 统计预设关注词(基于 config/frequency_words.txt,默认) - "auto_extract": 自动从新闻标题提取高频词(无需预设,自动发现热点)
Returns: JSON格式的话题频率统计列表
Examples: - 使用预设关注词: get_trending_topics(mode="current") - 自动提取热点: get_trending_topics(extract_mode="auto_extract", top_n=20)
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | current | |
| top_n | No | ||
| extract_mode | No | keywords |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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 the two extraction modes, references the config/frequency_words.txt source, and states that the return is a JSON frequency list. It does not discuss side effects, but for a getter-style statistics tool the disclosed behavior is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args, Returns, and Examples sections. Every sentence adds value, the main purpose is front-loaded, and the examples are concise illustrations rather than repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three optional parameters and no annotations, the description is complete: it defines all parameters, their defaults, mode semantics, extraction sources, return format, and usage examples. Nothing an agent needs to call the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions at all, yet the description documents every parameter: top_n with its default, mode with both allowed values and their meanings, and extract_mode with both options plus the config file dependency. Examples reinforce the parameter combinations, fully compensating for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving hot-topic frequency statistics, and the examples make the purpose concrete. It does not explicitly distinguish itself from siblings such as analyze_topic_trend, so it misses the top score, but the verb+resource combination is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by explaining the mode options and showing concrete examples for preset keywords and auto extraction. It does not explicitly state when not to use this tool or name alternatives, so the guidance is strong but not fully exclusionary.
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")
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | both |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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,自动去除广告、导航栏等噪音内容。 适合用于:阅读新闻正文、获取文章详情、分析文章内容。
典型使用流程:
先用 search_news(include_url=True) 搜索新闻获取链接
再用 read_article(url=链接) 读取正文内容
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 秒(内置速率控制) - 部分付费墙/登录墙页面可能无法完整获取
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| timeout | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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 秒以遵守速率限制。
典型使用流程:
先用 search_news(include_url=True) 搜索新闻获取多个链接
再用 read_articles_batch(urls=[...]) 批量读取正文
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 秒) - 单篇失败不影响其他篇的读取
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | ||
| timeout | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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 模型获得一致的日期范围。
推荐使用流程:
用户说"分析AI本周的情感倾向"
AI 调用 resolve_date_range("本周") → 获取精确日期范围
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"})| Name | Required | Description | Default |
|---|---|---|---|
| expression | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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"})
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| sort_by | No | relevance | |
| platforms | No | ||
| rss_limit | No | ||
| threshold | No | ||
| date_range | No | ||
| include_rss | No | ||
| include_url | No | ||
| search_mode | No | keyword |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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)
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| feeds | No | ||
| limit | No | ||
| keyword | Yes | ||
| include_summary | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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"])
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | TrendRadar 通知 | |
| message | Yes | ||
| channels | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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: 访问密钥
| Name | Required | Description | Default |
|---|---|---|---|
| days | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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)
| Name | Required | Description | Default |
|---|---|---|---|
| platforms | No | ||
| include_url | No | ||
| save_to_local | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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.
27 tool updates
v6.10.0- First observed
aggregate_news - First observed
analyze_data_insights - First observed
analyze_sentiment - First observed
analyze_topic_trend - First observed
check_version - First observed
compare_periods - First observed
find_related_news - First observed
generate_summary_report - First observed
get_channel_format_guide - First observed
get_current_config - First observed
get_latest_news - First observed
get_latest_rss - First observed
get_news_by_date - First observed
get_notification_channels - First observed
get_rss_feeds_status - First observed
get_storage_status - First observed
get_system_status - First observed
get_trending_topics - First observed
list_available_dates - First observed
read_article - First observed
read_articles_batch - First observed
resolve_date_range - First observed
search_news - First observed
search_rss - First observed
send_notification - First observed
sync_from_remote - First observed
trigger_crawl
TDQS
Scored across 27 tools
While many tools have distinct purposes, there are several overlapping search and status tools (search_rss vs search_news with include_rss, get_latest_news vs get_latest_rss vs get_news_by_date, and multiple status tools like get_system_status, get_storage_status, get_rss_feeds_status, get_notification_channels). The detailed descriptions help disambiguate, but the sheer number of similar-sounding tools could cause an agent to select the wrong one.
All 27 tools follow a consistent verb_noun pattern using snake_case (e.g., search_rss, get_system_status, analyze_sentiment, send_notification). There are no deviations in style, and the verbs are descriptive of the action. This is a model example of consistent naming.
With 27 tools, the count is slightly above the 16-25 'heavy' range. However, the server covers a wide domain (news ingestion, analysis, reporting, notifications, configuration, storage, and article reading), so each tool has a place. It feels borderline but not excessive given the comprehensive scope.
The tool surface appears well-rounded for a news monitoring system: fetching (latest, by date, RSS), searching (keyword, fuzzy, entity), analysis (sentiment, trends, insights, comparison), reporting (summary, aggregation), notifications, configuration retrieval, crawling, storage sync, and article reading. Minor gaps exist (e.g., no tool to modify configuration or add feeds), but these are not fatal and are typically managed by admins outside MCP.
Maintenance
Related MCP Connectors
AI-triaged brand, competitor and demand mentions from Reddit, Google News and search.
AI-powered social listening across Twitter, LinkedIn, Reddit, Facebook, and more.
Trending topics, cross-platform sentiment, viral content, community pulse & brand mentions.
- octolensOAuthcom.octolens
Social listening for AI: query brand mentions across 15+ platforms, run analytics, manage keywords.
Related MCP Servers
- AlicenseAqualityNot gradedmaintenanceAn 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.27GPL 3.0
- AlicenseAqualityCmaintenanceEnables AI-driven public opinion monitoring and trend analysis with multi-platform aggregation, smart alerts, and natural language interaction via MCP.27GPL 3.0
- AlicenseAqualityCmaintenanceEnables AI assistants to query aggregated multi-platform hot topics and RSS feeds, filter by keywords, and trigger AI-powered translation, analysis, and channel notifications through natural language.27GPL 3.0
- AlicenseAqualityBmaintenanceProvides an AI-powered news aggregation and trend monitoring service, enabling multi-platform hotspot aggregation, RSS subscriptions, keyword filtering, AI translation, analysis briefs, and smart alerts delivered to various channels, all accessible through natural language via MCP.271GPL 3.0


